Specificatie Interfatare SIUI - Aplicatii de Raportare Pentru Furnizori

CASA NAIONAL DE ASIGURRI DE SNTATE DIN ROMNIA SISTEM INFORMATIC UNIC INTEGRAT + PRESCRIPIE ELECTRONIC
Specificaii de interfaare cu SIUI+PE pentru aplicaiile de raportare ale furnizorilor de servicii medicale i farmaceutice
Casa Naional de Asigurri de Sntate din Romnia Specificaii de interfaare cu SIUI+PE pentru aplicaiile de raportare ale furnizorilor de servicii medicale i farmaceutice
ISTORICUL REVIZIILOR DOCUMENTULUI

Versiune 1.0 (PROIECT) 1.0 (PUBLICAT) 1.1 (PUBLICAT) 1.2 (PUBLICAT) 1.3 (PUBLICAT) 2.0 (PUBLICAT) 2.1 (PUBLICAT) 2.2 (PUBLICAT) 3.0 (PROIECT) 3.0 (PUBLICAT) 3.0.1 (PUBLICAT) 3.0.2 (PUBLICAT) 3.0.3 (PUBLICAT) 3.0.4 (PUBLICAT) Data 10.10.2006 30.11.2007 06.05.2008 11.05.2009 06.05.2010 29.11.2010 01.08.2011 12.01.2012 30.04.2012 01.07.2012 04.07.2012 31.07.2012 21.08.2012 26.10.2012 Comentarii Versiune iniial propus Versiune publicat - conform Contract Cadru i Norme 2007 Versiune actualizat - conform Contract Cadru i Norme 2008 Versiune actualizat - conform Contract Cadru i Norme 2009 Versiune actualizat - conform Contract Cadru i Norme 2010 Versiune publicat - SIUI-Actualizat : Centralizare i validare online Versiune actualizat - conform Contract Cadru i Norme 2011 Versiune actualizat includere mape contractare 2012, raportri numerice Versiune propus SIUI extins + Prescripia Electronic Versiune publicat SIUI extins + Prescripia Electronic Versiune actualizat ERAT: Corecie exemplu de cod la paginile 38/39 Versiune actualizat ERAT: Adugare metod de preluare a reetelor eliberate Versiune actualizat ERAT: Detaliere completare cheie de identificare aplicaie Versiune actualizat Descriere metode noi expuse pentru prescripia electronic
Versiune: 3.0.4 din 26.10.2012
Pagina 2 din 80
CUPRINS
Istoricul reviziilor documentului ............................................................................................................................. 2 CUPRINS ......................................................................................................................................................................... 3 TABELA DE FIGURI ........................................................................................................................................................... 7 1. INTRODUCERE .............................................................................................................................................................. 8 2. PREZENTARE GENERAL SIUI+PE ............................................................................................................................... 10 2.1. Descrierea sistemului informatic al asigurrilor de sntate din Romnia ............................................... 10 2.1.1. Nivelul de baz ......................................................................................................................................... 11 2.1.2. Nivelul central .......................................................................................................................................... 12 2.2. Descrierea interfeelor SIUI ........................................................................................................................... 13 2.2.1. Interfeele cu furnizorii de servicii medicale i farmaceutice ............................................................... 13 2.2.2. Interfeele cu alte instituii ...................................................................................................................... 14 2.3. Asigurarea securitii informaiei .................................................................................................................. 14 2.3.1. Autentificarea i autorizarea prin certificate digitale ............................................................................ 16 2.3.2. Semntura digital................................................................................................................................... 18 2.4. Clasificarea transferurilor de date ................................................................................................................ 19 2.4.1. Transfer unilateral - descrcare (download) ......................................................................................... 19 2.4.2. Transfer unilateral - ncrcare (upload) ................................................................................................. 19 2.4.3. Transfer bilateral ..................................................................................................................................... 19 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. Obinerea cheii de activare a aplicaiei informatice de raportare ......................................................... 20 3.1.3. Activarea aplicaiei folosind cheia de activare ....................................................................................... 20 3.1.4. Cheia de identificare a aplicaiei de raportare ....................................................................................... 21 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 ............................................................................................................ 22 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 .......................................................................................................... 24 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 (personalizare).................................................................................... 27 3.5. Funcionaliti specifice prescripiei electronice.......................................................................................... 28
Versiune: 3.0.4 din 26.10.2012
Pagina 3 din 80
3.5.1. Validarea reetelor electronice ............................................................................................................... 29 3.5.2. Anularea reetelor electronice ................................................................................................................ 30 3.5.3. Consultarea reetelor electronice .......................................................................................................... 30 3.5.4. Generarea seriilor de reete electronice ................................................................................................ 31 3.5.5. Tiprirea reetelor electronice ................................................................................................................ 31 3.5.6. Utilizarea DataMatrix pentru tiprirea codului de bare 2D ................................................................... 34 3.5.7. Raportarea reetelor electronice n vederea decontrii ........................................................................ 35 4. PREZENTARE GENERAL A SERVICIILOR WEB ................................................................................................................ 36 4.1. Scurt prezentare ........................................................................................................................................... 36 4.2. Tehnologia serviciului-web ............................................................................................................................ 36 4.3. Arhitectura implementrii serviciului-web SIUI ........................................................................................... 37 5. DESCRIEREA SERVICIILOR WEB EXPUSE ........................................................................................................................ 39 5.1. Serviciul pentru sincronizarea nomenclatoarelor ........................................................................................ 42 5.1.1. Metoda g e t Ca ta l og ue s ......................................................................................................................... 42 5.1.2. Instruciuni de folosire............................................................................................................................. 42 5.1.3. Observaii .................................................................................................................................................. 43 5.2. Serviciul pentru sincronizarea datelor de personalizare ............................................................................. 43 5.2.1. Metoda g e tP r o v id er I nfo ....................................................................................................................... 44 5.2.2. Metoda g e tP a r t n er I nfo ........................................................................................................................ 44 5.2.3. Instruciuni de folosire............................................................................................................................. 45 5.2.4. Observaii .................................................................................................................................................. 46 5.3. Serviciul pentru trimiterea raportrilor periodice ........................................................................................ 46 5.3.1. Metoda s e nd Re po r t ............................................................................................................................... 46 5.3.2. Instruciuni de folosire............................................................................................................................. 46 5.3.3. Observaii .................................................................................................................................................. 47 5.3.4. Raportri speciale .................................................................................................................................... 48 5.4. Serviciul pentru preluarea rezultatelor raportrilor periodice ................................................................... 48 5.4.1. Metoda g e tR epo r tF ee dba c k ............................................................................................................... 48 5.4.2. Instruciuni de folosire............................................................................................................................. 48 5.4.3. Observaii .................................................................................................................................................. 49 5.5. Serviciul pentru preluarea decontului ........................................................................................................... 49 5.5.1. Metoda g e tR ef u nd ................................................................................................................................. 49 5.5.2. Metoda g e tR ef u ndF o rI n vo ic e ............................................................................................................. 50 5.5.3. Metoda g e tR ef u ndF o rP h ys ic ia n ........................................................................................................ 50 5.5.4. Instruciuni de folosire............................................................................................................................. 51 5.5.5. Observaii .................................................................................................................................................. 52 5.6. Serviciul pentru sincronizarea deciziilor de acordare .................................................................................. 52 5.6.1. Metoda g e tD ec i sio n s ............................................................................................................................ 52 5.6.2. Instruciuni de folosire............................................................................................................................. 52 5.6.3. Observaii .................................................................................................................................................. 53 5.7. Serviciul pentru verificarea calitii de asigurat ........................................................................................... 53 5.7.1. Metoda g e tI n s ur ed ................................................................................................................................ 54 5.7.2. Metoda g e tI n s ur ed By C ID .................................................................................................................... 54 5.7.3. Instruciuni de folosire............................................................................................................................. 54 5.7.4. Observaii .................................................................................................................................................. 55 5.8. Serviciul pentru validarea micrilor de capitaie ........................................................................................ 55 5.8.1. Metoda va l i da te E nl is te d ...................................................................................................................... 55 5.8.2. Instruciuni de folosire............................................................................................................................. 56 5.8.3. Observaii .................................................................................................................................................. 56 5.9. Serviciul pentru validarea serviciilor i investigaiilor medicale ................................................................. 56 5.9.1. Metoda va l i da te Re p o r t ......................................................................................................................... 56 5.9.2. Instruciuni de folosire............................................................................................................................. 57 5.9.3. Observaii .................................................................................................................................................. 58 5.10. Serviciul pentru validarea reetelor prescrise ............................................................................................ 58 5.10.1. Metoda va l ida t eP r esc ri p tio n ............................................................................................................ 58 5.10.2. Instruciuni de folosire........................................................................................................................... 59
Versiune: 3.0.4 din 26.10.2012
Pagina 4 din 80
5.10.3. Observaii ................................................................................................................................................ 59 5.11. Serviciul pentru validarea biletelor de trimitere ........................................................................................ 59 5.11.1. Metoda va l ida t e Cl i ni c R efe rr a l ........................................................................................................ 60 5.11.2. Metoda va l ida t e La bR efe r ra l ............................................................................................................ 60 5.11.3. Instruciuni de folosire........................................................................................................................... 60 5.11.4. Observaii ................................................................................................................................................ 60 5.12. Serviciul pentru validarea certificatelor medicale ..................................................................................... 61 5.12.1. Metoda va l ida t e Si c k L ea v e ................................................................................................................ 61 5.12.2. Instruciuni de folosire........................................................................................................................... 61 5.12.3. Observaii ................................................................................................................................................ 61 5.13. Serviciul pentru validarea reetelor emise de farmacii.............................................................................. 62 5.13.1. Metoda va l ida t eF a rm a cy D ru gs ........................................................................................................ 62 5.13.2. Instruciuni de folosire........................................................................................................................... 62 5.13.3. Observaii ................................................................................................................................................ 62 5.14. Serviciul pentru consultarea reetelor prescrise ....................................................................................... 63 5.14.1. Metoda ge tP re sc ri p tio n ..................................................................................................................... 63 5.14.2. Instruciuni de folosire........................................................................................................................... 63 5.14.3. Observaii ................................................................................................................................................ 64 5.15. Serviciul pentru consultarea biletelor de trimitere .................................................................................... 64 5.15.1. Metoda ge t Cl in ic R efe rr a l ................................................................................................................. 64 5.15.2. Metoda ge t La bR ef er ra l ...................................................................................................................... 64 5.15.3. Instruciuni de folosire........................................................................................................................... 65 5.15.4. Observaii ................................................................................................................................................ 65 5.16. Serviciul pentru validarea reetelor electronice ......................................................................................... 65 5.16.1. Metoda processPrescribedPrescription ................................................................................................. 65 5.16.2. Metoda processIssuedPrescription ........................................................................................................ 66 5.16.3. Instruciuni de folosire........................................................................................................................... 66 5.16.4. Observaii ................................................................................................................................................ 67 5.17. Serviciul pentru anularea reetelor electronice ......................................................................................... 67 5.17.1. Metoda cancelPrescribedPrescription.................................................................................................... 68 5.17.2. Metoda cancelReleasedPrescription ...................................................................................................... 69 5.17.3. Instruciuni de folosire........................................................................................................................... 69 5.17.4. Observaii ................................................................................................................................................ 69 5.18. Serviciul pentru consultarea reetelor electronice .................................................................................... 70 5.18.1. Metoda getPrescribedPrescription ......................................................................................................... 70 5.18.2. Metoda getReleasedPrescription ............................................................................................................ 71 5.18.3. Metoda getStatusForPrescriptions ......................................................................................................... 72 5.18.4. Metoda downloadNotReportedPrescriptionsReport ............................................................................... 73 5.18.5. Instruciuni de folosire........................................................................................................................... 73 5.18.6. Observaii ................................................................................................................................................ 73 5.19. Serviciul pentru generarea seriilor de reete electronice.......................................................................... 74 5.19.1. Metoda generatePrescriptionSeries ....................................................................................................... 74 5.19.2. Metoda getPrescriptionSeriesInfo .......................................................................................................... 75 5.19.3. Instruciuni de folosire........................................................................................................................... 75 5.19.4. Observaii ................................................................................................................................................ 75 5.20. Serviciul pentru completarea datelor de facturare .................................................................................... 76 5.20.1. Metoda updateInvoices ........................................................................................................................... 76 5.20.2. Instruciuni de folosire........................................................................................................................... 76 5.20.3. Observaii ................................................................................................................................................ 76 5.21. Serviciul pentru preluarea borderourilor cu valori admise la plat .......................................................... 76 5.21.1. Metoda getRegisterFeedback ................................................................................................................. 77 5.21.2. Metoda getRegisterFeedbackAggregated ............................................................................................... 77 5.21.3. Instruciuni de folosire........................................................................................................................... 77 5.21.4. Observaii ................................................................................................................................................ 78 6. SERVICII OFFLINE DE INTERFAARE CU SIUI .................................................................................................................. 79 6.1. Serviciul pentru preluarea datelor de contractare ....................................................................................... 79 6.1.1. Instruciuni de folosire............................................................................................................................. 79
Versiune: 3.0.4 din 26.10.2012
Pagina 5 din 80
6.1.2. Observaii .................................................................................................................................................. 80
Versiune: 3.0.4 din 26.10.2012
Pagina 6 din 80
TABELA DE FIGURI
FIGURA 1 - ARIA DE ACOPERIRE A SISTEMULUI .................................................................................................................. 11 FIGURA 2 - CONECTAREA APLICAIILOR DE RAPORTARE LA SIUI ......................................................................................... 14 FIGURA 3 - DIAGRAMA SOLUIEI DE ASIGURARE A SECURITII DATELOR .............................................................................. 16 FIGURA 4 - EXEMPLU DE REET COMPONENTA PRECRIERE ............................................................................................. 32 FIGURA 5 - EXEMPLU DE REET ELECTRONIC TIPRIT N FARMACIE COMPONENTA ELIBERARE ........................................ 33 FIGURA 6 - ARHITECTURA SERVICIUL-WEB SIUI ............................................................................................................... 38
Versiune: 3.0.4 din 26.10.2012
Pagina 7 din 80
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 Anexa 002 Anexa 003 Anexa 004 Anexa 005 Descriere_Servicii_WEB.pdf
Pentru aplicaiile de raportare ale tuturor tipurilor de furnizori de servicii

Descriere_Structura_FarmaciiCircuitDeschis.pdf
Pentru aplicaiile de raportare ale farmaciilor cu circuit deschis

Descriere_Structura_FarmaciiCircuitInchis.pdf
Pentru aplicaiile de raportare ale farmaciilor cu circuit nchis

Descriere_Structura_Spitale.pdf
Pentru aplicaiile de raportare ale spitalelor

Descriere_Structura_PNS.pdf
Pentru aplicaiile de raportare ale furnizorilor de servicii medicale care deruleaz Programe Naionale de sntate Anexa 006 Anexa 007 Anexa 008 Anexa 009 Anexa 010 Descriere_Structura_MediciFamilie.pdf
Pentru aplicaiile de raportare ale medicilor de familie

Descriere_Structura_Clinice.pdf
Pentru aplicaiile de raportare ale ambulatoriilor clinice

Descriere_Structura_Paraclinice.pdf
Pentru aplicaiile de raportare ale laboratoarelor de analize i cabinetelor de radiologie i imagistic

Descriere_Structura_Stomatologii.pdf
Pentru aplicaiile de raportare ale cabinetelor de medicin dentar

Descriere_Structura_ConcediiMedicale.pdf
Pentru aplicaiile de raportare a concediilor medicale pentru medicii care au convenii cu CAS
Versiune: 3.0.4 din 26.10.2012
Pagina 8 din 80
Anexa 011 Anexa 012 Anexa 013 Anexa 014 Anexa 015 -
Descriere_Structura_RecuperareAmbulatorii.pdf
Pentru aplicaiile de raportare ale ambulatoriilor de recuperare

Descriere_Structura_RecuperareSanatorii.pdf
Pentru aplicaiile de raportare ale sanatoriilor de recuperare i preventoriilor

Descriere_Structura_DispozitiveMedicale.pdf
Pentru aplicaiile de raportare ale furnizorilor de dispozitive medicale

Descriere_Structura_IngrijiriDomiciliu.pdf
Pentru aplicaiile de raportare ale furnizorilor de ngrijiri la domiciliu

Descriere_Structura_Ambulante.pdf
Pentru aplicaiile de raportare ale furnizorilor de asisten medical de urgen prespitaliceasc i transport sanitar Anexa 016 Anexa 017 Descriere_Structura_Dializa.pdf
Pentru aplicaiile de raportare ale unitilor private de hemodializ

Descriere_Structura_PrescriereElectronic.pdf
Pentru aplicaiile de raportare a reetelor electronice pentru medicii care au convenii cu CAS
Acest document i cu 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 9 din 80
2. PREZENTARE GENERAL SIUI+PE
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. Acest sistem este extins prin adugarea funcionalitilor specifice Prescripiei Electronice, o modalitate de eviden informatizat i de automatizare a prescrierii i eliberrii medicamentelor compensate i gratuite. SIUI+PE este proiectat utiliznd o arhitectur centralizat. Colectarea i prelucrarea datelor se realizeaz prin intermediul unei ferme de servere de aplicaie ce acceseaz datele stocate n baza de date central, prezentnd seturi diferite de funcionaliti pentru diferite categorii de utilizatori, i anume: Funcionaliti specifice Casei Naionale de Asigurri de Sntate (CNAS); Funcionaliti specifice Caselor de Asigurri de Sntate (CAS): o 41 de Case de Asigurri de Sntate Judeene o Casa de Asigurri de Sntate a Municipiului Bucureti o Casa Asigurrilor de Sntate a Aprrii, Ordinii Publice, Siguranei Naionale i Autoritii Judectoreti (CASAOPSNAJ) o Casa Asigurrilor de Sntate a Ministerului Transporturilor, Construciilor i Turismului (CASMTCT) Funcionaliti specifice Sistemul Informatic de Prescripie Electronic (PE); 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 10 din 80
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.
Versiune: 3.0.4 din 26.10.2012
Pagina 11 din 80
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.
Versiune: 3.0.4 din 26.10.2012
Pagina 12 din 80
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. SIUI permite validarea online, nainte de raportarea final, a eligibilitii serviciilor declarate de furnizori precum i a calitii de asigurat a beneficiarului 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 13 din 80
Figura 2 - Conectarea aplicaiilor de raportare la SIUI
OBSERVAIE Conexiunea prin Internet la SIUI este 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 este folosit 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 14 din 80
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;
Versiune: 3.0.4 din 26.10.2012
Pagina 15 din 80
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 trebui s i nregistreze n SIUI certificatele digitale care vor fi folosite de operatorii proprii pentru a accesa serviciile SIUI online. n SIUI se vor crea conturi de utilizatori autorizai n SIUI pentru fiecare operator al furnizorului, iar acetia vor putea accesa sistemul online numai pe baza certificatului digital. Certificate digitale sunt gestionate ntr-o baz de date dedicat prin intermediul unei aplicaii de administrare de ctre operatorii de la Casele de Asigurare Judeene. Certificatul digital trebuie instalat pe calculatorul pe care este instalat aplicaia de raportare i trebuie s fie accesibil aplicaiei prin mijloace de interconectare (instalare pe sistemul de operare sau acces prin driver sistem la un eToken). Aplicaia de raportare folosete certificatul
Versiune: 3.0.4 din 26.10.2012
Pagina 16 din 80
pentru autentificarea i autorizarea cererilor online ctre SIUI prin intermediului protocolului HTTPS/SSL. Poarta de intrare n SIUI este securizat prin intermediul unui echipament hardware care joac rolul de firewall, accelerator SSL i load-balancer, n acelai timp realiznd 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 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 verific n baza de date dedicat, dac certificatul digital a fost nregistrat de ctre un utilizator autorizat al sistemului, iar dac este formuleaz o cerere prin protocolul OCSP ctre serviciul pus la dispoziie de STS. Acest serviciu verific 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 trebuie 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 trebuie 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 folosete acest session-id-hash pentru a transmite cererile ulterioare ctre serverele de aplicaie SIUI. Aici hash-ul este 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 este respectat, atunci sistemul 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 trebuie s implementeze un mecanism prin care s menin deschis sesiunea SSL, astfel nct ulterior autentificrii i autorizrii apelurile ctre serviciul Web s poat fi efectuate direct.
Versiune: 3.0.4 din 26.10.2012 Pagina 17 din 80
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 trebuie s fie instalat 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 folosete certificatul pentru a deschide conexiunea online ctre SIUI prin intermediului protocolului HTTPS/SSL. Dup ce sistemul verific certificatele digitale prezentate de aplicaiile de raportare din punct de vedere al integritii i valabilitii la deschiderea unei noi sesiuni SSL prin HTTPS, acesta 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 verific n baza de date tampon, dac certificatul digital a fost nregistrat de ctre un utilizator autorizat al sistemului, iar dac este formuleaz 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 pstreaz 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 serviciulweb, 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
Versiune: 3.0.4 din 26.10.2012
Pagina 19 din 80
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. Obinerea 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 expuse de SIUI, descrise n continuare, 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 ntocmit i 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 introduce ncepnd cu anul 2011 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 20 din 80
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.1.4. Cheia de identificare a aplicaiei de raportare Pentru a putea identifica mai uor sursa fiierelor de raportare fiecare aplicaie de raportare produs de dezvoltatorii de software independeni va trebui s transmit n cererile de validare sau n fiierele de raportare periodic o cheie de identificare a aplicaiei. n structurile fiierelor XML este prevzut opional n nodul rdcin, special pentru acest scop, un atribut care se numete AppKey i poate conine ir de caractere. OBSERVAIE Pentru standardizarea acestor denumiri sugerm folosirea unei combinaii care s conin denumirea companiei productoare a aplicaiei i denumirea comercial a aplicaiei de raportare. Recomandm, de asemenea, ca aceast cheie s nu conin i numrul de versiune pentru a permite identificarea unic a aplicaiei de raportare.
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 recompletnd 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).
Versiune: 3.0.4 din 26.10.2012
Pagina 23 din 80
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.
Versiune: 3.0.4 din 26.10.2012
Pagina 24 din 80
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
Versiune: 3.0.4 din 26.10.2012
Pagina 25 din 80
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 pre-completate 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 26 din 80
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 (personalizare) 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 27 din 80
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.
3.5. FUNCIONALITI SPECIFICE PRESCRIPIEI ELECTRONICE

Aceast seciune prezint noile servicii expuse de extensia SIUI pentru Prescripia Electronic. Aceste servicii permit transmiterea n sistemul central a reetelor electronice prescrise de medici pentru validarea conform regulilor impuse de normativele n vigoare, dar i spre a fi consultate de farmaciti n momentul eliberrii medicamentelor. Acest lucru va permite un control mai eficient i n timp real al medicamentelor eliberate n sistemul de asigurri sociale de sntate. Prescripia medical electronic este un formular utilizat n sistemul de asigurri sociale de sntate pentru prescrierea de medicamente compensate, cu i fr contribuie personal n tratamentul ambulatoriu. Exst dou moduri de completare a reetei electronice: online sau offline Prin prescripia medical electronic online se nelege prescripia n format electronic care este completat folosind o aplicaie informatic dedicat care este conectat la Sistemul Informatic pentru Prescripia Electronic al CNAS, iar prescripia este validat i nregistrat n form electronic n sistem nainte de a fi tiprit. Pentru conectarea la sistemul informatic al CNAS, furnizorul trebui s utilizeze un certificat digital calificat, iar aplicaia trebuie s fie nregistrat n baza unei serii de licene eliberate din sistem.
Versiune: 3.0.4 din 26.10.2012
Pagina 28 din 80
Prin prescripia medical electronic offline se nelege - prescripia n format electronic care este completat folosind o aplicaie informatic dedicat care nu este conectat la Sistemul Informatic pentru Prescripia Electronic al CNAS i este tiprit fr a fi validat i nregistrat n sistem, sau prescripia completat manual pe hrtie, respectnd formularul specific prevazut in normele CNAS. Doar medicii prescriptori pot utiliza prescripia n regim offline. 3.5.1. Validarea reetelor electronice Pentru validarea reetelor prescrise de medici sau eliberate de farmaciti acetia vor completa n aplicaiile specifice datele necesare, iar aplicaiile vor transmite ctre sistemul central aceste date, iar n urma validrii vor afia medicului sau farmacistului mesaje de avertizare cu privire la corectitudinea datelor din punct de vedere al respectrii normelor cu privire la reetele compensate i gratuite, dar i o serie de reguli cu caracter medical referitoare la interaciuni adverse ntre medicamentele prescrise sau ntre medicamente i diversele diagnostice cronice sau cu risc vital ale pacientului, n msura n care aceste informaii sunt cunoscute de ctre sistem. Reetele electronice vor fi nsoite de un formular tiprit ce va conine un cod de bare 2D care va reprezenta ntr-o form codificat i comprimat (descris ntr-un document separat) toate informaiile nscrise pe reet, att de ctre medic ct i de ctre farmacist. Modul de apelare a metodelor de validare specifice medicilor i farmacitilor este descris n detaliu n continuare, n cadrul acestui document. Un flux tipic de validare a unei reete prescrise de medic este propus mai jos.
Utilizatorul (medic) se autentific n aplicaie, iar aceasta stabilete conexiunea cu sistemul central (dac a fost activat n prealabil cu certificatul digital nregistrat n SIUI i cu seria de licen). Medicul identific pacientul pe baza unui act de identitate sau a cardului de asigurat (cnd acesta va fi disponibil), determin categoria de asigurat a acestuia i nregistreaz datele necesare pentru ntocmirea reetei electronice: - Aplicaia de raportare asist medicul prin preluarea automat a unor informaii despre pacient din sistemul central sau de pe cardul de asigurat. - Aplicaia de raportare utilizeaz un cod (la rnd) din calupul alocat pentru reetele emise online. - Medicul completeaz mai nti diagnosticele pacientului ncepnd cu cel principal, apoi medicamentele prescrise, poziie cu poziie, preciznd substana activ, concentraia, forma farmaceutic, cantitatea i modul de administrare. - La finalizarea reetei electronice (nainte de tiprire) aplicaia o transmite spre validare ctre sistemul central i afieaz utilizatorului mesajele de validare primite de la sistem. - Medicul poate corecta reeta n cazul n care exist nereguli de conformitate cu normele n vigoare, dar n cazul validrilor medicale poate s i asume rspunderea actului medical i s treac peste avertizrile emise de sistem, cu precizarea motivelor (sic volo). - Dac este cazul retransmite spre validare reeta, iar apoi o tiprete i o nmneaz pacientului, spre a-i servi la farmacie. Utilizatorul nchide ecranul de editare a reetei electronice sau aplicaia.
De notat c medicul poate folosi n situaii excepionale aplicaia de raportare n regim offline (fr o conexiune cu sistemul central), caz n care nu va beneficia de validrile de conformitate cu actele normative i nici de cele de natur medical. n acest caz reeta va fi marcat ca atare i va urma un flux distinct la farmacie. Pentru aceste reete se va putea scana codul de bare ca i n cazul reetelor online, dar la prezentarea pacientului la farmacie ele nu vor fi disponibile n sistemul central (dac medicul nu le-a raportat ntre timp), motiv pentru care farmacistul va
trebui s apeleze serviciul de validare online a datelor medicale, n locul medicului, iar apoi s urmeze fluxul propriu de eliberare. De asemenea, pentru a permite medicilor de familie s acorde servicii medicale la domiciliul pacientului, unde nu va putea accesa aplicaia de raportare, nici mcar n regim offline, dar i pentru situaii de calamiti naturale cnd medicul nu va putea utiliza aplicaia, este prevzut un flux de lucru paralel, cu calupuri de reete care vor fi controlate separat, ce va permite medicului s-i tipreasc n prealabil un set de reete n alb (care vor conine un cod de bare 2D ce va servi doar la identificarea medicului i a exemplarului de reet) pe care le va completa manual ca i n prezent. Aceste reete vor fi tratate la farmacie ca i reetele prescrise offline din aplicaia medicului, cu deosebirea c farmacistul va trebui sa introduc n aplicaia proprie medicamentele prescrise de medic pe care dorete s le elibereze (aceste informaii nefiind cuprinse n codul de bare), aa cum se procedeaz i n prezent. Prezentm n continuare un flux tipic de validare a unei reete eliberate n farmacie:
Utilizatorul (farmacist) se autentific n aplicaie, iar aceasta stabilete conexiunea cu sistemul central (dac a fost activat n prealabil cu certificatul digital nregistrat n SIUI i cu seria de licen). Farmacistul identific pacientul sau mputernicitul pe baza unui act de identitate sau a cardului de asigurat (cnd acesta va fi disponibil), apoi scaneaz codul de bare 2D de pe reet pentru a prelua informaiile prescrise de medic i completeaz medicamentele eliberate: - Aplicaia completeaz automat toate datele coninute de codul de bare; - Farmacistul completeaz medicamentele (denumire comercial), cantitile eliberate i preurile conform listelor de compensare n vigoare, dar i o serie de informaii financiar-contabile cum ar fi contravaloare suportat de pacient i numrul bonului fiscal prin care acesta a achitat suma; - La finalizarea reetei (nainte de tiprire) aplicaia o transmite spre validare ctre sistemul central i afieaz utilizatorului mesajele de validare primite de la sistem; - Farmacistul poate corecta reeta n cazul n care exist nereguli de conformitate cu normele n vigoare - Dac este cazul retransmite spre validare reeta, iar apoi o tiprete pentru a-i servi la decontarea contravalorii compensate de Casa de Asigurri. Utilizatorul nchide ecranul de editare a reetei electronice sau aplicaia.
3.5.2. Anularea reetelor electronice Acest serviciu permite medicului s anuleze o reet pe care a lansat-o deja n sistem (a marcat-o ca tiprit) n cazul n care acesta constat ulterior o greeal de ntocmire sau o schimbare n starea de sntate a pacientului, ceea ce necesit emiterea unei noi reete n condiiile prevzute de normele CNAS. O reet poate fi anulat doar de medicul care a prescris-o, el trebuind s prescrie o reet nou n cazul n care a anulatp o reet. Pacientul trebuie s se ntoarc la medic pentru ca acesta s i elibereze o nou reet. O reet prescris nu mai poate fi anulat de ctre medic dup ce aceasta a fost eliberat ntr-o farmacie total sau parial. 3.5.3. Consultarea reetelor electronice Acest serviciu permite farmacistului s consulte o reet existent n sistemul central, pe baza unor date de identificare a acesteia, cum ar fi seria i numrul dar i parafa medicului prescriptor i CUI-ul unitii emitente, pentru a nu permite interogarea abuziv a bazei de date.
Versiune: 3.0.4 din 26.10.2012
Pagina 30 din 80
Acest serviciu trebuie apelat de aplicaiile de raportare ale farmacitilor dup identificarea pacientului i a reetei (prin scanarea codului de bare 2D) pentru a asigura autenticitatea reetei, lucru garantat doar de prezena ei n sistemul central, n urma raportrii de ctre medicul prescriptor. 3.5.4. Generarea seriilor de reete electronice Acest serviciu permite medicului prescriptor s genereze online calupuri noi de reete n cazul epuizrii stocului existent. Exist dou categorii de calupuri de serii: Una pentru reetele prescrise n mod curent att n regim online ct i offline prin intermediul aplicaiei informatice; A doua pentru reete pre-tiprite i completate manual, categorie care se dorete a fi controlat mai strict.
Seriile reetelor electronice nu se vor suprapune cu cele are reetelor tipizate existente i vor avea urmtoarea structur: Seria: 6 caractere alphabetice (litere); Numrul: 10 caractere numerice (cifre).
3.5.5. Tiprirea reetelor electronice Atunci cnd medicul prescriptor nu se poate conecta la sistemul central PE, atunci aplicaia de raportare trebuie s ofere posibilitatea tipririi unui formular pe hrtie, pe acest formular fiind tiprit un cod de bare 2D (DataMatrix) care va stoca n format electronic coninutul prescripiei. La rndul ei, aplicaia de raportare pentru farmacii trebuie s poat prelua automat, prin intermediul unui dispozitiv specializat (cititor de coduri de bare) informaia stocat pe reeta tiprit, uurnd astfel activitatea de preluare a informaiilor de pe hrtie pentru farmacist. Prescripia medical electronic online i offline are dou componente: componenta prescriere, care se completeaz de ctre medicul prescriptor; componenta eliberare, care se completeaz de ctre farmacist.
Prezentm n continuare cteva exemple de astfel de documente tiprite de medici. OBSERVAIE Exist prevzut i un caz de utilizare n care medicul nu poate avea acces la aplicaia de raportare i astfel nu poate prescrie electronic propriu-zis. n aceast situaie medicul va trebui s prescrie manual (cu pixul) pe o hrtie tiprit anterior din aplicaie care va asemntoare formularulului tipizat actual, i va conine n codul de bare doar cmpurile pre-tiprite pe reet pentru identificare (serie i numr reet, numr contract, CUI cabinet).
Versiune: 3.0.4 din 26.10.2012
Pagina 31 din 80
Figura 4 - Exemplu de reet componenta precriere
Farmacitii, la rndul lor pot tipri, pentru cazul n care reeta este eliberat parial un formular similar ce va conine un cod de bare care va stoca medicamentele eliberate deja pentru reeta respectiv, formular care i va folosi pacientului la a doua farmacie Aceste formulare vor putea servi i n cazul decontrii valorilor de ctre Casa de Asigurri. Formularul de la medic poart semnturi i tampila acestuia, iar cel de la farmacie poart semntura i tampila farmacistului, dar i semntura asiguratului sau a unui mputernicit care a ridicat medicamentele.
Pentru utilizarea semnturii digitale, medicii i farmacitii vor trebui s dein i ei un certificat digital calificat. Acest certificat ar putea fi acelai cu cel folosit la conectarea la sistem pentru medicii cu cabinete medicale individuale, cu condiia ca aceste certificate s fie emise pe numele medicului (cum ar putea fi n cazul unui Cabinet Medicical Individual), ns medicii i farmacitii care lucreaz la furnizori unde certificatul este emis i nregistrat pe numele reprezentantului legal vor trebui s-i achiziioneze certificate digitale n nume propriu.
Figura 5 - Exemplu de reet electronic tiprit n farmacie componenta eliberare
Versiune: 3.0.4 din 26.10.2012
Pagina 33 din 80
NOT Cmpul prin care primitorul renun la anumite poziii se completeaz doar n cazul eliberrii incomplete dintr-un singur pas (dar nu fracionate), sau la ultima fracie a unei reete dac i n acel moment rmn medicamente prescise i ne-eliberate. 3.5.6. Utilizarea DataMatrix pentru tiprirea codului de bare 2D Prezentm n continuare cteva detalii tehnice despre modalitatea de codificare a datelor folosind standardul DataMatrix, acesta oferind urmtoarele avantajele: densitate mare a informaiei pe suprafaa ocupat, recuperarea consistent n urma degradrii pariale, citire rapid indiferent de orientare, scalabilitate i extensibilitate n funcie de suprafaa ocupat. Reetele se pot imprima att la medicul prescriptor ct i la farmacie (pentru cazul eliberrii fracionate). Medicul poate tipri dou tipuri de reete: o completat asistat de calculator (online sau offline) reet electronic propriu-zis o pre-tiprit i completat de mn de medicul prescriptor, neasistat de calculator, introdus i raportat ulterior n aplicaie Ambele tipuri de reete tiprite de medic vor avea tiprit un cod de bare 2D (DataMatrix) care va reprezenta un fiier XML (conform schemei de validare PEBarcode.xsd publicat n anexele corespunztoare tipurilor de furnizori care utilizeaz prescripia electronic) codificat dup cum urmeaz. Procedura de tiprire a codului de bare
1. Aplicaia de raportare genereaz un fiier XML cu informaiile existente de pe reet pe care l valideaz cu schema PEBarcode.xsd. 2. Aplicaia serializeaz XML-ul ca un array de bytes codificat UTF-8 pe care l comprim utiliznd algoritmul portabil ZIP (JavaZip). 3. Informaia comprimat este stocata tot ntr-un array de bytes care este apoi codificat folosind algoritmul Base256 (care reprezint un mod optim de stocare a informaiei de tip binar (non-alfanumeric/non-ASCII)cu o rat de 1-la-1. 4. Se genereaz o imagine (bitmap) codificat conform standardului DataMatrix, care poate fi inclus ntr-un raport pentru a fi tiprit pe reet, aa cum apare n exemplele prezentate mai sus.
Codificarea Base256 asigur o rat de conversie de 1-la-1 pentru date binare de tip array de bytes cu valori ntre (0 255). Mai mult, aceasta codificare asigur evitarea zonelor albe din codul de bare DataMatrix ceea ce poate duce la desincronizarea procesului de citire, prin modificarea informaiei cu o valoarea pseudo-aleatoare. Aplicaia de raportare din farmacie trebuie s poat citi acest cod pentru a permite farmacistului s preia automat informaia stocat n codul de bare. Pentru realizarea acestui lucru este necesar un cititor de coduri de bare 2D, care este compatibil cu standardul DataMatrix. OBSERVAIE Pentru a putea fi utilizat de aplicaiile de raportare oferite gratuit de CNAS, acest cititor de coduri de bare 2D trebuie s permit comunicaia serial (direct pe un port serial al terminalului PC sau emulat pe un port USB prin intermediul unui driver i a unor configurri specifice).
Versiune: 3.0.4 din 26.10.2012
Pagina 34 din 80
Procedura de citire a codului de bare

1. Aplicaia deschide portul de comunicaii serial (fizic sau virtual) specificat de utilizator (de ex. COM1), iar opional se poate configura viteza de comunicaie (de ex. 9600 baud) conform cu capabilitile cititorului. 2. Aplicaia stocheaz ntr-o memorie tampon datele primite prin portul serial i la intlnitea unui terminator de comunicaie nchide portul. 3. Dac citirea a fost realizat cu success: - cititorul va furniza aplicatiei un array de bytes; - altfel aplicaia va afia un mesaj de eroare corespunztor. 4. Aplicaia decodific irul de bytes realiznd n sens invers paii de la tiprire: - decomprimare folosind algoritmul ZIP (JavaZip); - deserializare array de bytes codificat UTF-8 reprezentnd XML-ul original. 5. XML-ul este validat cu schema PEBarcode.xsd, iar dac se termin cu succes: - atunci aplicaia va genera o nou reet, completat cu datele preluate, pe care farmacitul o poate edita pentru a preciza medicamentele eliberate; - altfel aplicaia va afia un mesaj de eroare de validare.
Obs.: Utilizatorul trebuie s poat anula procedul de citire (deblocnd astfel portul serial) n cazul n care constat o funcionare necorespunztoare.
3.5.7. Raportarea reetelor electronice n vederea decontrii Colectarea reetelor electronice se realizeaz n SIPE (Sistemul Informatic pentru Prescripia Electronic). Decontarea reetelor electronice, dar i a celor cu regim special pn la eliminarea complet a acestora, se realizeaz din SIUI. Pentru transferul reetelor electronice n SIUI se apeleaz metoda sendReport expus de serviciile-web al SIUI, trimind o cerere de raportare special coninnd un fiier XML validat cu schema ImportElectronicPrescription.xsd, iar parametrul reportType care specific tipul de raportare va avea valoarea FARME. De asemenea i prefixul fiierului va fi FARME. De notat c se vor transfera toate reetele dintr-o perioad specificat prin cerere. Sunt permise i perioade mai scurte, dar incluse n luna curent de raportare aa cum este definit n calendarele de raportare din SIUI. Sunt considerate transferabile reetele electronice eliberare total sau parial, care nu sunt anulate, au flagul isReleased setat pe true i au cel puin un medicament n starea eliberat, iar n acelai timp au fost completate datele de facturare folosind metoda web dedicat, i anume seria i numrul facturii i numrul de ordine din borderou, conform normelor n vigoare. Aceast raportare respect aceleai reguli ca raportarea reetelor cu regim special, n acest sens fiind fcute raportri distincte pentru fiecare contract n parte, n cazul n care farmacia are att contact simplu ct i contract pentru PNS-uri.
Versiune: 3.0.4 din 26.10.2012
Pagina 35 din 80
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, printro 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:
Versiune: 3.0.4 din 26.10.2012
Pagina 37 din 80
Figura 6 - Arhitectura Serviciul-web SIUI
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.
Versiune: 3.0.4 din 26.10.2012
Pagina 38 din 80
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 ce conine o 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: Parol: 123456789_CAS-XY AB012-C345-D678-E910
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 expus de SIUI ncepnd cu anul 2011. SiuiValidateWS.wsdl pentru serviciile-web de pre-validare online a eligibilitii la decontare a serviciilor prestate de furnizori. Acest serviciu este o funcionalitate nou introdus n SIUI ncepnd cu anul 2011.
Sistemul PE (Prescripia Electronic) folosete un singur fiier WSDL care expune funcionalitile specifice:
EPrescriptionWS.wsdl pentru serviciile-web de procesare online a eligibilitii la decontare a serviciilor prestate de furnizori. Acest serviciu este o funcionalitate nou introdus n SIUI ncepnd cu anul 2012.
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 serviciilor-web expuse de Sistemul Informatic pentru Prescripia Electronic:

https://sipe.siui.ro/svapntws/services/EPrescriptionWS
Adresa serviciului de autentificare i validare OCSP a certificatelor digitale este urmtoarea:

https://www.siui.ro/OCSP/validator
A se nota c adresa pentru OCSP corespunde serviciilor expuse de SIUI; accesul la serviciile expuse de Prescripia Electronic fiind realizat folosind aceleai certificate digitale i credeniale de acces (utilizator/parol) ca i pentru SIUI. 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 accesul. 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 ServicePointManager.Expect100Continue = false; // evita 505: HTTP version not supported // 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.KeepAlive = false; request.AllowAutoRedirect = false; request.ProtocolVersion = HttpVersion.Version10; // pentru Axis WS - basic authentication // preluare setare proxy din sistemul de operare (Internet Explorer) request.Proxy = WebProxy.GetDefaultProxy(); request.CachePolicy = new RequestCachePolicy( RequestCacheLevel.NoCacheNoStore ); // 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;
Versiune: 3.0.4 din 26.10.2012
Pagina 40 din 80
// suprasciere CookieContainer pentru a pstra cookie-urile request.CookieContainer = CookieJar; // CookieJar este un CookieContainer static global // 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 opiuni generale http ServicePointManager.ServerCertificateValidationCallback = ServerCertificateBypass; ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls; // default in .NET ServicePointManager.Expect100Continue = false; // evita 505: HTTP version not supported // configurare cerere web request.KeepAlive = false; request.AllowAutoRedirect = false; request.ProtocolVersion = HttpVersion.Version10; // pentru Axis WS - basic authentication // preluare setare proxy din sistemul de operare (Internet Explorer) request.Proxy = WebProxy.GetDefaultProxy(); request.CachePolicy = new RequestCachePolicy( RequestCacheLevel.NoCacheNoStore ); // 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 global // 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 categoriei 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 s nu 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 parametru MF PHM CLIN PARA STOM AMB MD HC REC SPT NHP DIA SICK EMP CBRET Tip de furnizor corespunztor Medicin primar i de familie Farmacii (circuit deschis / circuit nchis) Specialiti clinice Specialiti paraclinice Specialiti stomatologice Ambulane Dispozitive medicale ngrijire la domiciliu Recuperare - ambulatoriu i sanatorii Spitale P.N.S. Hemodializ Raportri concedii medicale Raportri angajatori (nu se mai folosete) Convenii pentru prescriere reete
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. Serviciul expune dou metode, prima destinat furnizorilor care au contract cu Casa de Asigurri, iar a doua medicilor care au ncheiat convenii de prescriere a reetelor compensate i activeaz n instituii care nu au contract direct cu Casa de Asigurri.
Versiune: 3.0.4 din 26.10.2012
Pagina 43 din 80
5.2.1. Metoda getProviderInfo String[] getProviderInfo ( String partnerCategory , DateTime start , DateTime stop , String uic ) Metoda are patru parametri de intrare : parametrul partnerCategory de tip ir de caractere reprezint codul categoriei de furnizor, lista valorilor permise fiind prezentat mai jos; parametrul start de tip dat calendaristic reprezint data de nceput a perioadei pentru care se caut datele furnizorului n sistem; parametrul stop de tip dat calendaristic reprezint data de sfrit a perioadei pentru care se caut datele furnizorului n sistem; parametrul uic de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului de personalizare, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. URL-ul va fi generat pentru fiecare cerere i are 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 memorat. 5.2.2. Metoda getPartnerInfo String[] getPartnerInfo ( String partnerCategory , DateTime start , DateTime stop , String uic, String subUnitCode ) Metoda are patru parametri de intrare : parametrul partnerCategory de tip ir de caractere reprezint codul categoriei 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; parametrul subUnitCode de tip ir de caractere reprezint codul unic de identificare al subunitii n sistem (valoarea partnerCode din fiierul de personalizare).
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului de personalizare, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat.
URL-ul va fi generat pentru fiecare cerere i are 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 memorat. Parametrul subUnitCode se transmite cu valoarea null pentru cazul n care contractul se realizeaz direct cu o unitate medical cu personalitate juridic, dar trebuie transmis pentru cazul unitilor medicale care activeaz n instituii colare sau instituii de ngrijire a btrnilor, care nu au contract direct cu Casa de Asigurri ci ntocmesc convenii de eliberare a reetelor compensate. 5.2.3. Instruciuni de folosire 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. Prezentm n continuare lista de valori admise pentru parametrul partnerCategory:
Valoare parametru MF FARMD FARMI CLIN PARA STOM AMB MD HC RECA RECS SPT NHP DIA FSD SICK EMP CBRET Tip de furnizor corespunztor Medicin primar i de familie Farmacii (circuit deschis) Farmacii (circuit nchis) Specialiti clinice Specialiti paraclinice Specialiti stomatologice Ambulane Dispozitive medicale ngrijire la domiciliu Recuperare - ambulatoriu Recuperare - sanatorii Spitale P.N.S. P.N.S. / Dializ public Dializ privat Raportri concedii medicale Raportri angajatori (* nu se mai folosete) Convenii pentru prescriere reete (* nou)
Un exemplu tipic de algoritm pentru actualizarea datelor de contract este:

Se apeleaz metoda getProviderInfo cu parametrii corespunztori. 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 datele de contractare 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 45 din 80
5.2.4. 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. 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 s nu permit importul unui fiier de personalizare mai vechi dect cel deja ncrcat n aplicaie.
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 raportare, 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. 5.3.2. Instruciuni de folosire Numele fiierului XML de raportare trebuie sa respecte formatul:
{Prefix} + "_" + {Cod} + "_" + {Data} + "_" + {Ora} + ".xml"
{Prefix} reprezint un cod de identificare pentru tipul de furnizor, lista complet a acestor coduri fiind prezentat n tabelul de mai jos. {Cod} reprezint codul unic de identificare al furnizorului n sistem, codul fiscal, CUI sau CNP, dup caz. Parametrii {Data} i {Ora} reprezint data i ora la care a fost efectuat raportarea i trebuie s apar n formatul "AAAALLZZ" pentru dat i "OOMM", fr nici un separator.
Versiune: 3.0.4 din 26.10.2012
Pagina 46 din 80
Schema de validare pentru acest fiier este detaliat n anexele corespunztoare fiecrui tip de furnizor. Prezentm n continuare lista de valori admise pentru parametrul reportType:
Valoare parametru MF PRM FARMD FARME FARMI CLIN PARA STOM AMB MD HC RECA RECS SICK FSD NHPDIA NHPREP NHPCJ SPT_ACUT SPT_CHR SPT_DRG SPT_SPZ SPT_PAL Valoare prefix fiier MF PRM FARMD FARME FARMI CLIN PARA STOM AMB MD HC RECA RECS SICK DIA DIA NHPREP NHPCJ SPT_ACUT SPT_CHR SPT_DRG SPT_SPZ SPT_PAL Tip de furnizor corespunztor / Tip de raportare Medicin primar i de familie Centre de permanen Farmacii (circuit deschis) reete cu regim special (tipizate) Farmacii (circuit deschis) reete electronice (online i offline) Farmacii (circuit nchis) Specialiti clinice Specialiti paraclinice Specialiti stomatologice Ambulane Dispozitive medicale ngrijire la domiciliu Recuperare - ambulatoriu Recuperare - sanatorii Certificate de concediu medicale Dializ privat P.N.S. / Dializ public P.N.S. / Raportare de indicatori P.N.S. P.N.S. / Cereri justificative (facturi i ordine de plat) Spitale / Raportare de cazuri acute (internri) Spitale / Raportare de cazuri cronice Spitale / Raportare D.R.G. Spitale / Raportare spitalizare de zi 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 valideaz fiierul XML cu schema de validare XSD corespunztoare. - 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. Altfel se afieaz un mesaj de eroare de comunicaie.
5.3.3. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 47 din 80
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 prefix fiier RECAMB_OFFER MEDDEV_OFFER PARA_OFFER SPT_E SPT_I HBDG Tip de furnizor corespunztor / Tip de raportare Recuperare - ambulatoriu / Ofert de preuri pentru servicii Dispozitive medicale / Ofert de preuri pentru dispozitive medicale Paraclinice (Laboratoare) / Ofert de preuri pentru servicii Spitale / Structura organizatoric (departamente, secii, angajai) Spitale / Raportare indicatori statistici Spitale / Structur i indicatori bugetari
Valoare parametru RECA_OFFER MD_OFFER PARA_OFFER SPT_E SPT_I HBDG
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.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. Dac nu exist un fiier de raportare procesat cu numele dat, metoda ntoarce null. 5.4.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
Versiune: 3.0.4 din 26.10.2012
Pagina 48 din 80
fiierului descrcat. Fiierul descrcat este o arhiv ZIP care conine un fiier XML cu rezultatul procesrii raportrii n SIUI. Schema de validare pentru acest fiier este detaliat n anexele corespunztoare fiecrui tip de furnizor. Un exemplu tipic de algoritm pentru actualizarea nomenclatoarelor este:
Se apeleaz metoda getReportFeedback cu parametrii corespunztori. 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 fiierul ZIP 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 tabela de erori 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.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. n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie).
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 ( String partnerCategory , DateTime start , DateTime stop , String uic ) Metoda are patru parametri de intrare: parametrul partnerCategory de tip ir de caractere reprezint codul categoriei de furnizor, lista valorilor permise fiind prezentat mai jos;
Pagina 49 din 80
Versiune: 3.0.4 din 26.10.2012
parametrul start de tip dat calendaristic reprezint data de nceput a perioadei pentru care se dorete fiierul de decont; parametrul stop de tip dat calendaristic reprezint data de sfrit a perioadei pentru care se dorete fiierul de decont; parametrul uic de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului de decont, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. Dac nu exist un fiier de decont generat pentru furnizorul respectiv, metoda ntoarce null. 5.5.2. Metoda getRefundForInvoice String[] getRefundForInvoice ( String partnerCategory , String invoiceNumber , DateTime invoiceDate , String uic ) Metoda are patru parametri de intrare: parametrul partnerCategory de tip ir de caractere reprezint codul tipului de furnizor, 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; parametrul uic de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului de decont, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. Dac nu exist un fiier de decont generat pentru furnizorul respectiv, metoda ntoarce null. 5.5.3. Metoda getRefundForPhysician String[] getRefundForPhysician ( String partnerCategory , DateTime start , DateTime stop , String uic String stencil ) Metoda are cinci parametri de intrare: parametrul partnerCategory de tip ir de caractere reprezint codul tipului de furnizor, lista valorilor permise fiind prezentat mai jos; parametrul start de tip dat calendaristic reprezint data de nceput a perioadei pentru care se dorete fiierul de decont;
Pagina 50 din 80
Versiune: 3.0.4 din 26.10.2012
parametrul stop de tip dat calendaristic reprezint data de sfrit a perioadei pentru care se dorete fiierul de decont; parametrul uic de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz. 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.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului de decont, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. Dac nu exist un fiier de decont generat pentru furnizorul respectiv, metoda ntoarce null. 5.5.4. Instruciuni de folosire 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. Prezentm n continuare lista de valori admise pentru parametrul partnerCategory:
Valoare parametru MF PRM FARM CLIN PARA STOM AMB MD HC RECA RECS SPT NHP DIA FSD Tip de furnizor corespunztor Medicin primar i de familie Centre de permanen Farmacii (circuit deschis) Specialiti clinice Specialiti paraclinice Specialiti stomatologice Ambulane Dispozitive medicale ngrijire la domiciliu Recuperare - ambulatoriu Recuperare - sanatorii Spitale P.N.S. P.N.S. / Dializ public 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 51 din 80
Un exemplu tipic de algoritm pentru preluarea fiierului de decont este:

Se apeleaz metoda getRefund cu parametrii corespunztori. 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 PDF. - Se afieaz coninutul fiierului PDF folosind aplicaia de vizualizare instalat. - Altfel se afieaz mesaj de eroare de comunicaie. Altfel se afieaz un mesaj de eroare de comunicaie.
5.5.5. 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.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 partnerCategory , String requestXml ) Metoda are doi parametri de intrare: parametrul partnerCategory de tip ir de caractere reprezint codul categoriei de furnizor, lista valorilor permise fiind prezentat mai jos; parametrul requestXml de tip ir de caractere reprezint coninutul fiierului de cerere arhivat n formatul ZIP (JavaZip) i codat ulterior n formatul Base64.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului de rspuns, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. Dac nu exist un fiier de raportare procesat cu numele dat, metoda ntoarce null. 5.6.2. Instruciuni de folosire Aplicaia client trebuie s foloseasc URL-ul rezultat pentru a descrca fiierul de rspuns. Dimensiunea fiierului poate fi folosit pentru a verifica completitudinea fiierului descrcat. Fiierul descrcat este o arhiv ZIP care conine un fiier XML cu datele referitoare la deciziile cerute din SIUI. Numele fiierului XML de cerere trebuie sa respecte formatul:
Versiune: 3.0.4 din 26.10.2012
Pagina 52 din 80
{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 parametru MD HC Valoare prefix fiier MD_SYNC HC_SYNC Tip de furnizor corespunztor Dispozitive medicale 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 valideaz fiierul XML cu schema de validare XSD corespunztoare. - Se arhiveaz fiierul XML folosind algoritmul ZIP. - Se codific coninutul arhivei folosind codarea Base64. Se apeleaz metoda getDecisions cu parametrii corespunztori. 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 tabela de decizii 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.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. 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.
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 recompletnd 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 ) Metoda are doi parametri de intrare: parametrul pid de tip ir de caractere reprezint CNP-ul unui beneficiar; parametrul requestDate de tip dat calendaristic reprezint data la care se dorete verificarea calitii de asigurat, de exemplu data curent sau data efecturii serviciului.
Metoda ntoarce ca rspuns un ir de caractere reprezentnd coninutul unui fiier n format XML care conine urmtoarele informaii: Un cod numeric de rspuns indicnd dac beneficiarul este asigurat sau nu, dac figureaz ca decedat n sistem, dac nu este nregistrat n sistem sau dac CNP-ul nu este corect. Lista categoriilor active la data interogrii
Observaie: n cazul unei erori ntlnite n sistem la procesarea cererii se va ntoarce un cod numeric de rspuns (-1) precum i o descriere a erorii. 5.7.2. Metoda getInsuredByCID String getInsuredByCID ( String cid, Date requestDate) Metoda are doi parametri de intrare: parametrul cid de tip ir de caractere reprezint codul de asigurat al 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. 5.7.3. Instruciuni de folosire Aplicaia de raportare trebuie s proceseze fiierul de rspuns i s afieze un mesaj sugestiv pentru utilizator cu privire la starea de asigurat a persoanei respective. Dac este cazul aplicaia va pre-completa 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 54 din 80
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 valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se parcurge fiierul i se afieaz un mesaj corespunztor strii de asigurat. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz un mesaj de eroare de comunicaie.
5.7.4. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). 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 a unui pacient pe lista unui medic de familie, nsoit de motivaia operaiei. 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
Versiune: 3.0.4 din 26.10.2012
Pagina 55 din 80
5.8.2. Instruciuni de folosire 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. - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. Aplicaia apeleaz metoda validateEnlisted trimind coninutul fiierului. Dac SIUI ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se parcurge fiierul i se afieaz un mesaj corespunztor rezultatului validrii. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz un mesaj de eroare de comunicaie.
5.8.3. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie).
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 ) Metoda are trei parametri de intrare: parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n format XML. parametrul reportType de tip ir de caractere reprezint codul tipului de furnizor, lista valorilor permise fiind prezentat mai jos; parametrul requestType de tip ir de caractere reprezint codul tipului de cerere de validare transmis, lista valorilor permise fiind prezentat mai jos;
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care conine urmtoarele informaii: O structur similar cu cea raportat, coninnd fiecare identificator de nregistrare transmis nsoit de starea validrii (validat/nevalidat) Lista erorilor sau avertizrilor pentru fiecare nregistrare raportat, n caz c acestea au fost depistate tampila de timp la momentul emiterii rspunsului
Coninutul i formatul datelor transmise este specific fiecrui tip de furnizor i va fi descris n detaliu n anexele care nsoesc acest document. Ca regul general, datele transmise din
aplicaia de raportare ctre SIUI vor fi validate iar serviciul Web va ntoarce un rspuns cu privire la rezultatul validrii serviciului medical raportat. 5.9.2. Instruciuni de folosire Un exemplu tipic de algoritm pentru validarea unei reete este:
Utilizatorul adaug o reet n baza de date: - Aplicaia genereaz fiierul cerere n format XML coninnd informaiile referitoare la reet i medicamentele prescrise. - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. Aplicaia apeleaz metoda validateReport trimind coninutul fiierului nsoit de tipul raportrii. Dac SIUI ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul XML i se afieaz un mesaj corespunztor rezultatului validrii. - Aplicaia asociaz i pstreaz rezultatul validrii, afind nregistrarea respectiv n mod distinct. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
Prezentm n continuare lista de valori admise pentru parametrul reportType:

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

Valoare parametru RQ_PRESCRIPTION RQ_REFERRAL RQ_CHRONICS RQ_MF_ENLISTED RQ_MF_SERVICES RQ_SPT_ACUTE RQ_SPT_CHRONIC
Versiune: 3.0.4 din 26.10.2012
Tip de cerere de validare Cerere de validare reet prescris de medic Cerere de validare bilet de trimitere emis Cerere de validare a bolnavilor cronici aflai n eviden Cerere de validare a micrii nscriilor pe listele medicilor de familie Cerere de validare a serviciilor prestate de medicii de familie Cerere de validare a cazurilor acute de spitalizare Cerere de validare a cazurilor cronice de spitalizare
Pagina 57 din 80
Valoare parametru RQ_SPT_ANALYTIC RQ_SPT_DRG RQ_SPT_HC_REC RQ_SPT_MD_REC RQ_SPT_PAL RQ_PHM_PRESCRIPTION RQ_PHM_HR RQ_PRM RQ_MD RQ_HC RQ_AMB_SRV RQ_AMB_WT RQ_DIA_SRV RQ_NHP_DIA_SRV RQ_RECA_SRV RQ_RECS_SRV RQ_CLIN_SRV RQ_PARA_SRV RQ_STOM_SRV RQ_NHP_GC RQ_NHP_IND RQ_NHP_TS RQ_NHP_INV RQ_NHP_OP RC_CM
Tip de cerere de validare Cerere de validare a raportrii analitice a spitalelor Cerere de validare a raportrii DRG a spitalelor Cerere de validare a recomandrilor de servicii de ngrijire la domiciliu Cerere de validare a recomandrilor de acordare de dispozitive medicale Cerere de validare a cazurilor paliative de spitalizare Cerere de validare a unei reete eliberate n farmacie Cerere de validare a unei foi de condic din farmacii cu circuit nchis Cerere de validare a serviciilor prestate n centre de permanen Cerere de validare a dispozitive medicale acordate Cerere de validare a servicii de ngrijire la domiciliu Cerere de validare a servicii de urgen sau transport cu ambulana Cerere de validare/raportare a timpilor de ateptare a ambulanelor Cerere de validare a serviciilor de dializ privat Cerere de validare a serviciilor de dializ public Cerere de validare a serviciilor de recuperare ambulatorie Cerere de validare a serviciilor de recuperare n sanatorii Cerere de validare a serviciilor clinice de specialitate Cerere de validare a serviciilor paraclinice (investigaii de laborator) Cerere de validare a serviciilor stomatologice i dentare Cerere de validare a consumului de materiale decontate din PNS Cerere de validare/raportare a indicatorilor PNS Cerere de validare a schemelor terapeutice recomandate n cadrul PNS Cerere de validare a facturilor decontate din PNS Cerere de validare a plilor decontate din PNS Cerere de validare certificat medical prescris de medic
5.9.3. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). 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 reetei se va apela serviciul Web prin care se va transmite pentru validare ctre SIUI reeta. NOT Acest serviciu este destinat validrii reetelor clasice pe formulare cu regim special i va fi pstrat pentru compatibilitate pn la eliminarea complet a acestor reete. Pentru reetele electronice trebuie folosite serviciile specifice expuse de SIUI+PE. 5.10.1. Metoda validatePrescription String validatePrescription ( String reportXml , String reportType )
Metoda are doi parametri de intrare: parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n format XML; parametrul reportType de tip ir de caractere reprezint codul tipului de furnizor, lista valorilor permise fiind prezentat mai jos.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care conine rezultatul operaiunii de validare. 5.10.2. Instruciuni de folosire Un exemplu tipic de algoritm pentru validarea unei reete prescrise de medic este:
Utilizatorul adaug o reet n baza de date: - Aplicaia genereaz fiierul cerere n format XML coninnd informaiile referitoare la reet i medicamentele prescrise. - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. Aplicaia apeleaz metoda validatePrescription trimind coninutul fiierului generat. Dac SIUI ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul XML i se afieaz un mesaj corespunztor rezultatului validrii. - Aplicaia asociaz i pstreaz rezultatul validrii, afind nregistrarea respectiv n mod distinct. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
5.10.3. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). Structura fiierul permite transmiterea mai multor nregistrri simultan, de exemplul la cerea utilizatorului, dup ce acesta a finalizat operarea mai multor reete, 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 59 din 80
5.11.1. Metoda validateClinicReferral String validateClinicReferral ( String reportXml , String reportType ) Metoda are doi parametri de intrare: parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n format XML; parametrul reportType de tip ir de caractere reprezint codul tipului de furnizor, lista valorilor permise fiind prezentat mai jos.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care conine rezultatul operaiunii de validare. 5.11.2. Metoda validateLabReferral String validateLabReferral ( String reportXml , String reportType ) Metoda are doi parametri de intrare: parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n format XML; parametrul reportType de tip ir de caractere reprezint codul tipului de furnizor, lista valorilor permise fiind prezentat mai jos.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care conine rezultatul operaiunii de validare. 5.11.3. Instruciuni de folosire Un exemplu tipic de algoritm pentru validarea unui bilet de trimitere este:
Utilizatorul adaug un bilet de trimitere n baza de date: - Aplicaia genereaz fiierul cerere n format XML coninnd informaiile referitoare la biletul de trimitere i diagnosticul prezumtiv. - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. Aplicaia apeleaz metoda validateClinicReferral sau validateLabReferral, dup caz, trimind ca parametru coninutul fiierului generat. Dac SIUI ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul XML i se afieaz un mesaj corespunztor rezultatului validrii. - Aplicaia asociaz i pstreaz rezultatul validrii, afind nregistrarea respectiv n mod distinct. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
Versiune: 3.0.4 din 26.10.2012
Pagina 60 din 80
Structura fiierul permite transmiterea mai multor nregistrri simultan, de exemplul la cerea 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 corespunztori, rezultatul validrii fiind acelai.
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 ) Metoda are un singur parametru de intrare: parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n format XML.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care conine rezultatul operaiunii de validare. 5.12.2. Instruciuni de folosire Un exemplu tipic de algoritm pentru validarea unui certificat medicale este:
Utilizatorul adaug un certificat medical n baza de date: - Aplicaia genereaz fiierul cerere n format XML coninnd informaiile referitoare la certificatul medical, perioad i diagnostic. - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. Aplicaia apeleaz metoda validateSickLeave trimind ca parametru coninutul fiierului generat. Dac SIUI ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul XML i se afieaz un mesaj corespunztor rezultatului validrii. - Aplicaia asociaz i pstreaz rezultatul validrii, afind nregistrarea respectiv n mod distinct. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
5.12.3. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). Structura fiierul permite transmiterea mai multor nregistrri simultan, de exemplul la cerea utilizatorului, dup ce acesta a finalizat operarea mai multor certificate medicale, sau n mod automat la revenirea conexiunii online dup o perioad de lucru offline.
Versiune: 3.0.4 din 26.10.2012
Pagina 61 din 80
Metoda validareReport se poate folosi n locul aceste metode, dac se utilizeaz parametrii corespunztori, rezultatul validrii fiind acelai.
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. NOT Acest serviciu este destinat validrii reetelor clasice pe formulare cu regim special i va fi pstrat pentru compatibilitate pn la eliminarea complet a acestor reete. Pentru reetele electronice trebuie folosite serviciile specifice expuse de SIUI+PE. 5.13.1. Metoda validateFarmacyDrugs String validateFarmacyDrugs ( String reportXml ) Metoda are un singur parametru de intrare: parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n format XML.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML. 5.13.2. Instruciuni de folosire Un exemplu tipic de algoritm pentru validarea unei reete eliberate n farmacie este:
Utilizatorul adaug un certificat medical n baza de date: - Aplicaia genereaz fiierul cerere n format XML coninnd informaiile referitoare la reet, pacient i medicamentele eliberate. - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. Aplicaia apeleaz metoda validateFarmacyDrugs trimind ca parametru coninutul fiierului generat. Dac SIUI ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul XML i se afieaz un mesaj corespunztor rezultatului validrii. - Aplicaia asociaz i pstreaz rezultatul validrii, afind nregistrarea respectiv n mod distinct. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
5.13.3. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). Structura fiierul permite transmiterea mai multor nregistrri simultan, de exemplul la cerea utilizatorului, dup ce acesta a finalizat operarea mai multor reete eliberate, sau n mod automat la revenirea conexiunii online dup o perioad de lucru offline.
Versiune: 3.0.4 din 26.10.2012
Pagina 62 din 80
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. NOT Acest serviciu este destinat validrii reetelor clasice pe formulare cu regim special i va fi pstrat pentru compatibilitate pn la eliminarea complet a acestor reete. Pentru reetele electronice trebuie folosite serviciile specifice expuse de SIUI+PE. 5.14.1. Metoda getPrescription String getPrescription ( String serial , String number , String pid , String stencil ) Metoda are patru parametri de intrare: parametrul serial de tip ir de caractere reprezint seria reetei; parametrul number de tip ir de caractere reprezint numrul reetei; parametrul pid de tip ir de caractere reprezint CNP-ul beneficiarului reetei; parametrul stencil de tip ir de caractere reprezint numrul de paraf al medicului emitent;
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns n format XML. Aplicaiile de raportare vor avea posibilitatea de implementare a unor funcionaliti de preluare automat a coninutului acestor documente n format electronic ctre SIUI. Astfel o farmacie poate apela serviciul Web pentru a descrca o reet prescris n scopul de a elibera medicamentele aferente. 5.14.2. Instruciuni de folosire 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. Dac SIUI ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul XML i se afieaz coninutul reetei cerute, eventual se precompleteaz datele n ecranul de introducere reete. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
Versiune: 3.0.4 din 26.10.2012
Pagina 63 din 80
5.14.3. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). 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 ) Metoda are patru parametri de intrare: parametrul serial de tip ir de caractere reprezint seria biletului de trimitere; parametrul number de tip ir de caractere reprezint numrul biletului de trimitere; parametrul pid de tip ir de caractere reprezint CNP-ul beneficiarului biletului de trimitere; parametrul stencil de tip ir de caractere reprezint numrul de paraf al medicului emitent;
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns n format XML. 5.15.2. Metoda getLabReferral String getLabReferral ( String serial , String number , String pid , String stencil ) Metoda are patru parametri de intrare: parametrul serial de tip ir de caractere reprezint seria biletului de trimitere; parametrul number de tip ir de caractere reprezint numrul biletului de trimitere; parametrul pid de tip ir de caractere reprezint CNP-ul beneficiarului biletului de trimitere; parametrul stencil de tip ir de caractere reprezint numrul de paraf al medicului emitent;
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns n format XML.

5.15.3. Instruciuni de folosire 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. Dac SIUI ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul XML i se afieaz coninutul biletului de trimitere cerut, eventual se precompleteaza datele n ecranul de introducere servicii. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
5.16. SERVICIUL PENTRU VALIDAREA REETELOR ELECTRONICE

Acest serviciu este folosit pentru validarea reetelor electronice prescrise de medici sau eliberate de farmaciti. Utilizatorul (medic sau farmacist) va completa datele referitoare la reeta electronic n aplicaia de raportare, la salvarea reetei aplicaia va apela serviciul Web prin care se va transmite pentru validare ctre sistemul central reeta reprezentat n format XML. Serviciul expune dou metode, una specific medicului, iar cealalt farmacistului. Ambele metode valideaz reeta din punct de vedere medical pentru ca pacientul s poat beneficia n acest fel de eventualele avertizri pe care sistemul le-ar putea emite cu privire la interaciuni ntre medicamentele prescrise sau ntre acestea i anumite alergii sau boli cronice ale pacientului. n acest mod, chiar dac medicul a prescris reeta offline, farmacistul va avea acces la setul de reguli specific medicului pentru a informa pacientul despre posibile contraindicaii. 5.16.1. Metoda processPrescribedPrescription String processPrescribedPrescription ( String reportXml ) Metoda are un singur parametru de intrare: parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n format XML, care se valideaz cu schema PhysicianDrugPERequest.xsd.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care conine rezultatul operaiunii de validare online, i se valideaz cu schema PhysicianDrugPEResponse.xsd. Fiierul are un coninut similar celui trimis de aplicaie, dar conine la nivel de reet (date pacient) dar i la nivel de detalii (medicamente) eventuale avertizri emise de sistem n cazul nerespectrii unor norme de prescriere.
Versiune: 3.0.4 din 26.10.2012
Pagina 65 din 80
5.16.2. Metoda processIssuedPrescription String processIssuedPrescription ( String reportXml ) Metoda are un singur parametru de intrare: parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n format XML, care se valideaz cu schema PharmacyDrugsPERequest.xsd.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care conine rezultatul operaiunii de validare online, i se valideaz cu schema PharmacyDrugsPEResponse.xsd. Fiierul are un coninut similar celui trimis de aplicaie, dar conine la nivel de reet (date pacient) dar i la nivel de detalii (medicamente) eventuale avertizri emise de sistem n cazul nerespectrii unor norme de eliberare. 5.16.3. Instruciuni de folosire Un exemplu tipic de algoritm pentru validarea unei reete electronice prescrise de medic este:
Utilizatorul (medic) adaug o reet n baza de date: - Aplicaia genereaz fiierul cerere n format XML coninnd informaiile referitoare la reet i medicamentele prescrise. - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. Dac medicul are semntur electronic extins (certificat digital calificat): - Se semneaz electronic fiierul XML, folosind standardul CMS (RFC5652). - Se codific rezultatul folosind codarea Base64. Se apeleaz metoda processPrescribedPrescription trimind coninutul fiierului generat. Dac sistemul ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul XML i se afieaz un mesaj corespunztor rezultatului validrii. - Aplicaia asociaz i pstreaz rezultatul validrii, afind nregistrarea respectiv n mod distinct. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
Un exemplu tipic de algoritm pentru validarea unei reete electronice eliberate n farmacie este:
Utilizatorul (farmacist) adaug o reet n baza de date, prin scanarea codului de bare 2D sau prin completare manual: - Aplicaia genereaz fiierul cerere n format XML coninnd informaiile referitoare la reet, pacient i medicamentele eliberate. - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. Dac medicul are semntur electronic extins (certificat digital calificat): - Se semneaz electronic fiierul XML, folosind standardul CMS (RFC5652). - Se codific rezultatul folosind codarea Base64. Se apeleaz metoda processIssuedPrescription trimind ca parametru coninutul fiierului generat. Dac sistemul ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul XML i se afieaz un mesaj corespunztor rezultatului validrii.
Versiune: 3.0.4 din 26.10.2012
Pagina 66 din 80
- Aplicaia asociaz i pstreaz rezultatul validrii, afind nregistrarea respectiv n mod distinct. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
5.16.4. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). 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. Semnarea electronic a fiierului XML este necesar doar n cazul transmiterii electronice online a acestuia ctre SIUI, i este opional n prima faz de implementare a Sistemului Informatic pentru Prescripia Electronic, aa cum este prevzut n normele metodologice ale CNAS. NOT Reetele offline se transmit spre procesare folosind aceleai metode, dar completnd atributul reportedOnline="0", cu semnificaia "OFFLINE: Prescris offline de ctre medic. Validat online de farmacie". Modificarea unei reete prescrise se poate face doar de ctre medicul prescriptor att timp ct reeta nu a fost nc tiprit de acesta, ulterior ea poate fi anulat, dar nu i dup ce 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. O reet electronic poate fi eliberat, total sau parial, de una sau mai multe farmacii. Dup eliberarea complet reeta trece n starea eliberat i nu mai este disponibil pentru alte farmacii. Dac reeta nu a fost eliberat complet atunci ea trece n starea eliberat parial, medicamentele neeliberate nc fiind disponibile pentru alte farmacii, cu condiia ca pacientul s se prezinte la aceste farmacii pentru a ridica medicamentele. NOT Nu se poate elibera parial un anumit medicament, ci doar medicamente diferite (poziii diferite de pe reet). Eliberarea parial este valabil doar pentru reetele electronice prescrise online care poart semntur electronic.
5.17. SERVICIUL PENTRU ANULAREA REETELOR ELECTRONICE

Acest serviciu este folosit pentru anularea reetelor electronice prescrise de medici, n cazul n care se constat ulterior o greeal de ntocmire sau o schimbare n starea de sntate a pacientului, ceea ce necesit emiterea unei noi reete.
Versiune: 3.0.4 din 26.10.2012
Pagina 67 din 80
Este permis anularea unei reete doar de ctre medicul care a prescris-o, acesta selectnd reeta electronic introdus anterior n aplicaia de raportare iar apoi opiunea de anulare. Aplicaia transmite ctre sistemul central cererea de anulare. n cazul n care medicul a prescris reeta electronic offline, iar farmacistul constat la raportarea n sistem o neregul care poate duce la anularea reetei, atunci va contacta medicul sau l va ndruma pe pacient ctre acesta, deoarece nu va putea elibera medicamente n baza reetei respective. Serviciul poate fi utilizat prin apelarea metodelor cancelPrescribedPrescription sau cancelReleasedPrescription specifice medicilor, respectiv farmaciilor, aa cum este descris n continuare: 5.17.1. Metoda cancelPrescribedPrescription Integer cancelPrescribedPrescription ( String providerCode , String physicianStencilNo , String contractNo , String contractType , String insuranceHouseCode , String series , String no , Date prescriptionDate , String cancellationReason ) Metoda are nou parametri de intrare: parametrul providerCode de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz; parametrul physicianStencilNo de tip ir de caractere reprezint numrul de paraf al medicului emitent; parametrul contractNo de tip ir de caractere reprezint numrul contractului dintre furnizor i Casa de Asigurri; parametrul contractType de tip ir de caractere reprezint codul tipului de contract, lista valorilor permise fiind prezentat mai jos; parametrul insuranceHouseCode de tip ir de caractere reprezint codul casei de asigurri cu care furnizorul are contract, valoare din nomenclatorul de case de asigurri. parametrul series de tip ir de caractere reprezint seria reetei; parametrul no de tip ir de caractere reprezint numrul reetei; parametrul prescriptionDate de tip dat calendaristic reprezint data la care reeta a fost prescris de medic; parametrul cancellationReason de tip ir de caractere reprezint motivaia anulrii (text liber).
Metoda ntoarce o valoare ntreag indicnd dac cererea a fost procesat cu succes, caz n care valoarea este 1, altfel apelul ntorcndu-se cu eroare.
Versiune: 3.0.4 din 26.10.2012
Pagina 68 din 80
5.17.2. Metoda cancelReleasedPrescription Integer cancelReleasePrescription ( String providerCode , String workplaceCode , String insuranceHouseCode , String series , String no , Integer fractionNo , String cancellationReason ) Metoda are opt parametri de intrare: parametrul providerCode de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz; parametrul workplaceCode de tip ir de caractere reprezint codul punctului de lucru al farmaciei (acest parametru trebuie sa aib valoarea din contractul ncheiat cu CAS, iar dac farmacia nu are punct de lucru se va trimite string vid ); parametrul insuranceHouseCode de tip ir de caractere reprezint codul casei de asigurri cu care furnizorul are contract, valoare din nomenclatorul de case de asigurri. parametrul series de tip ir de caractere reprezint seria reetei; parametrul no de tip ir de caractere reprezint numrul reetei; parametrul fractionNo de tip numr ntreg reprezint numrul de ordine al fraciei, n cazul reetelor eliberate fracionat farmacia/punctul de lucru (pentru o eliberare integral acest parametru va avea valoarea 1); parametrul cancellationReason de tip ir de caractere reprezint motivaia anulrii (text liber).
Metoda ntoarce o valoare ntreag indicnd dac cererea a fost procesat cu succes, caz n care valoarea este 1, altfel apelul ntorcndu-se cu eroare. 5.17.3. Instruciuni de folosire Un exemplu tipic de algoritm pentru consultarea unei reete prescrise este:
Utilizatorul (medic sau farmacist) dorete s anuleze o reet electronic: Aplicaia apeleaz metoda cancelPrescribedPrescription, respectiv cancelReleasedPrescription cu parametrii corespunztori (vezi lista de mai sus). Sistemul central valideaz cererea i ntoarce un ir de caractere ca rspuns. - Dac cererea a fost procesat cu succes (valoarea ntoars este 1): - atunci aplicaia afieaz un mesaj care indic succesul operaiei; - Altfel se afieaz un mesaj de eroare de comunicaie sau mesajul de eroare transmis de sistemul central cu privire la motivul din care anularea nu a reuit.
Versiune: 3.0.4 din 26.10.2012
Pagina 69 din 80
5.18. SERVICIUL PENTRU CONSULTAREA REETELOR ELECTRONICE

Acest serviciu este folosit pentru a permite medicilor i farmaciilor s consulte reetele electronice prescrise pentru verificarea datelor transferate n sistemul centaral sau pentru a elibera medicamentele prescrise de medic ctre pacient, verificnd n acelai timp autenticitatea reetei respective. Consultarea sistemului este obligatorie nainte de eliberarea medicamentelor pentru ca farmacistul s se asigure c reeta este valabil i este nregistrat n sitemul central, iar medicamentele prescrise nu au fost deja eliberate integral sau parial de alt farmacie. 5.18.1. Metoda getPrescribedPrescription String getPrescribedPrescription ( String providerCode , String physicianStencilNo , String contractNo , String contractType , String insuranceHouseCode , String series , String no , Date prescriptionDate ) Metoda are opt parametri de intrare: parametrul providerCode de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz; parametrul physicianStencilNo de tip ir de caractere reprezint numrul de paraf al medicului emitent; parametrul contractNo de tip ir de caractere reprezint numrul contractului dintre furnizor i Casa de Asigurri; parametrul contractType de tip ir de caractere reprezint codul tipului de contract (acest parametru este opional); parametrul insuranceHouseCode de tip ir de caractere reprezint codul casei de asigurri cu care furnizorul are contract, valoare din nomenclatorul de case de asigurri; parametrul series de tip ir de caractere reprezint seria reetei; parametrul no de tip ir de caractere reprezint numrul reetei; parametrul prescriptionDate de tip dat calendaristic reprezint data la care reeta a fost prescris de medic.
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns n format XML, care se valideaz cu schema PhysicianDrugPEResponse.xsd. NOT Fiierul de rspuns respect schema de validare PhysicianDrugPEResponse.xsd, avnd aceeai structur ca fiierul de rspuns primit de medic la cererea de validare a unei reete prescrise, deoarece conine practic acelai set de informaii transmise de ctre sistem medicului pentru validare, bineneles, cu condiia ce reeta prescris de ctre medic s fi fost validat cu succes i n starea emis (tiprit).
Aceast metod permite aplicaiilor de raportare s implementeze funcionaliti de preluare automat a coninutului reetelor electronice n format electronic din SIUI+PE. Astfel o farmacie poate descrca o reet prescris de un medic n scopul de a elibera medicamentele corespunztoare. 5.18.2. Metoda getReleasedPrescription String getReleasedPrescription ( String providerCode , String workplaceCode , String insuranceHouseCode , String series , String no , Integer fractionNo ) Metoda are ase parametri de intrare: parametrul providerCode de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz; parametrul workplaceCode de tip ir de caractere reprezint codul punctului de lucru care a raportat reeta (acest parametru trebuie sa aib valoarea din contractul ncheiat cu CAS, iar dac farmacia nu are punct de lucru se va trimite string vid ); parametrul insuranceHouseCode de tip ir de caractere reprezint codul casei de asigurri cu care furnizorul are contract, valoare din nomenclatorul de case de asigurri; parametrul series de tip ir de caractere reprezint seria reetei; parametrul no de tip ir de caractere reprezint numrul reetei; parametrul prescriptionDate de tip dat calendaristic reprezint data la care reeta a fost prescris de medic. parametrul fractionNo de tip numr ntreg reprezint numrul de ordine al fraciei, n cazul reetelor eliberate fracionat farmacia/punctul de lucru (pentru o eliberare integral acest parametru va avea valoarea 1).
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns n format XML, care se valideaz cu schema PharmacyDrugsPEResponse.xsd. NOT Fiierul de rspuns respect schema de validare PharmacyDrugsPEResponse.xsd, avnd aceeai structur ca fiierul de rspuns primit de farmacie la cererea de validare a unei reete eliberate, deoarece setul de informaii transmise din sistem este practic acelai, bineneles, cu condiia ce reeta eliberat de ctre farmacie s fi fost validat cu succes i n starea finalizat (tiprit). Aceast metod permite aplicaiilor de raportare s implementeze funcionaliti de preluare automat a coninutului reetelor electronice n format electronic din SIUI+PE. Astfel o farmacie poate descrca o reet transmis anterior n sistem, dar pentru care nu a putut prelua din motive tehnice rezultatul validrii. De asemenea, o aplicaie pentru medici, poate prelua informaiile referitoare la eliberarea medicamentelor ctre pacient la farmacie.
Versiune: 3.0.4 din 26.10.2012
Pagina 71 din 80
5.18.3. Metoda getStatusForPrescriptions String getStatusForPrescriptions ( String insuranceHouseCode , String providerCode , String contractNo , String contractType , Date startFrom, Date endTo, String workPlaceCode ) Metoda are apte parametri de intrare, fiind destinat n exclusivitate farmaciilor: parametrul insuranceHouseCode de tip ir de caractere reprezint codul casei de asigurri cu care furnizorul are contract, valoare din nomenclatorul de case de asigurri; parametrul providerCode de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz; parametrul contractNo de tip ir de caractere reprezint numrul contractului dintre furnizor i Casa de Asigurri; parametrul contractType de tip ir de caractere reprezint codul tipului de contract (acest parametru este opional); parametrul startFrom de tip dat calendaristic reprezint data de nceput a intervalului n care se caut reetele n sistem; parametrul endTo de tip dat calendaristic reprezint data de sfrit a intervalului n care se caut reetele n sistem; parametrul workplaceCode de tip ir de caractere reprezint codul punctului de lucru care a raportat reeta (acest parametru trebuie sa aib valoarea din contractul ncheiat cu CAS, iar dac farmacia nu are punct de lucru se va trimite string vid ).
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns n format XML, care se valideaz cu schema ImportPrescriptionStatusResponse.xsd. NOT Fiierul de rspuns este conform structurii definit de schema de validare ImportPrescriptionStatusResponse.xsd, i conine informaii despre datele de facturare, numrul de referin sau stri asociate (finalizat, transmis n SIUI, eliberare parial/integral) pentru reetele transmise n sistem de ctre farmacie pentru perioada de interogare specificat, identificate unic prin serie i numr. Aceast metod permite aplicaiilor de raportare pentru farmacii s implementeze funcionaliti de preluare automat a informaiilor despre starea reetele transmise n sistemul central SIPE ntru-un anumit interval. Aceste informaii pot fi utilizate pentru verificarea acurateii datelor transmise i, eventual, pentru retransmiterea corect a acestora, pregtind astfel datele pentru a nlesni procesul de raportare n vederea decontrii n SIUI.
Versiune: 3.0.4 din 26.10.2012
Pagina 72 din 80
5.18.4. Metoda downloadNotReportedPrescriptionsReport String downloadNotReportedPrescriptionsReport ( String insuranceHouseCode , Date startFrom, Date endTo, String providerCode , String workPlaceCode ) Metoda are cinci parametri de intrare, fiind destinat n exclusivitate medicilor: parametrul insuranceHouseCode de tip ir de caractere reprezint codul casei de asigurri cu care furnizorul are contract, valoare din nomenclatorul de case de asigurri; parametrul startFrom de tip dat calendaristic reprezint data de nceput a intervalului n care se caut reetele n sistem; parametrul endTo de tip dat calendaristic reprezint data de sfrit a intervalului n care se caut reetele n sistem; parametrul providerCode de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz; parametrul workplaceCode de tip ir de caractere reprezint codul punctului de lucru care a raportat reeta (acest parametru trebuie sa aib valoarea din contractul ncheiat cu CAS, iar dac farmacia nu are punct de lucru se va trimite string vid ).
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns n format PDF, arhivat utiliznd algoritmul JavaZIP i codificat base64, care poate fi salvat local i afiat cu un utilitar specializat. Fiierul PDF conine un raport desfurtogenerat de sistemul central SIPE. Aceast metod permite aplicaiilor de raportare pentru medici s implementeze funcionaliti de preluare i prezentare a raportului de reete netransmise online, pentru consultare i verificare a datelor introduse n aplicaie, n vederea respectrii obligaiilor contractuale de transmitere n sistemul central a reetelor electronice. 5.18.5. Instruciuni de folosire Un exemplu tipic de algoritm pentru consultarea unei reete prescrise este:
Utilizatorul (medic sau farmacist) dorete s consulte starea unei reete prescrise anterior de medic sau eliberate anterior de farmacie: Aplicaia apeleaz metoda getPrescribedPrescription, respectiv metoda getReleasedPrescription, cu parametrii corespunztori (vezi lista de mai sus). Sistemul central valideaz cererea i ntoarce un ir de caractere ca rspuns, pe care aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se proceseaz fiierul i se afieaz reeta electronic. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz un mesaj de eroare de comunicaie sau mesajul de eroare transmis de sistemul central.
Versiune: 3.0.4 din 26.10.2012
Pagina 73 din 80
Metoda de consultarea a raportului face excepie de la fluxul prezentat anterior, fiierul PDF nefiind verificat cu schema de validare XSD, ci fiind afiat direct, prin intermediului unei aplicaii utilizatare specializate. Numai reetele raportate online ca tiprite/finalizate 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, paraf medic prescriptor i CUI unitate emitent.
5.19. SERVICIUL PENTRU GENERAREA SERIILOR DE REETE ELECTRONICE

Prin intermediul acestui serviciu medicului prescriptor poate genera online calupuri noi de reete n cazul epuizrii stocului existent. Serviciul expune dou metode complementare, una pentru generarea unui calup nou, iar cealalt pentru descrcarea calupurilor generate anterior. 5.19.1. Metoda generatePrescriptionSeries String[] generatePrescriptionSeries ( String categoryCode , String orgUnitCode , String uic , String subUnitCode , Date validFrom , Boolean isOnLine , Integer quantity ) Metoda are apte parametri de intrare : parametrul categoryCode de tip ir de caractere reprezint codul categoriei de furnizor, lista valorilor permise fiind prezentat mai jos; parametrul orgUnitCode de tip ir de caractere reprezint codul casei de asigurri cu care furnizorul are contract, valoare din nomenclatorul de case de asigurri. parametrul uic de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz; parametrul subUnitCode de tip ir de caractere reprezint codul unic de identificare al subunitii n sistem (valoarea partnerCode din fiierul de personalizare); parametrul validFrom de tip dat calendaristic reprezint data de la care seriile vor valabile; parametrul isOnLine de tip boolean (true/false) indic dac seriile generate sunt pentru modul de lucru online sau offline (reete pre-tiprite); parametrul quantity de tip numr ntreg reprezint numrul de reete din calup.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului de rspuns, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. URL-ul va fi generat pentru fiecare cerere i are 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 mai vechi folosind un URL memorat.
Versiune: 3.0.4 din 26.10.2012
Pagina 74 din 80
5.19.2. Metoda getPrescriptionSeriesInfo String[] getPrescriptionSeriesInfo ( String categoryCode , String orgUnitCode , String uic , String subUnitCode ) Metoda are patru parametri de intrare: parametrul categoryCode de tip ir de caractere reprezint codul categoriei de furnizor, lista valorilor permise fiind prezentat mai jos; parametrul orgUnitCode de tip ir de caractere reprezint codul casei de asigurri cu care furnizorul are contract, valoare din nomenclatorul de case de asigurri. parametrul uic de tip ir de caractere reprezint codul unic de identificare al furnizorului n sistem, CUI (cod fiscal) sau CNP, dup caz; parametrul subUnitCode de tip ir de caractere reprezint codul unic de identificare al subunitii n sistem (valoarea partnerCode din fiierul de personalizare).
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului de rspuns, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. URL-ul va fi generat pentru fiecare cerere i are 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 mai vechi folosind un URL memorat. 5.19.3. Instruciuni de folosire Un exemplu tipic de algoritm pentru generarea seriilor de reete electronice este:
Utilizatorul dorete s genereze un nou calup de reete: Aplicaia apeleaz metoda generatePrescriptionSeries cu parametrii corespunztori (vezi lista de mai sus). Sistemul central valideaz cererea i ntoarce un ir de caractere ca rspuns, pe care aplicaia l salveaz ntr-un fiier XML: - Se valideaz fiierul XML cu schema de validare XSD corespunztoare. - Dac fiierul este valid atunci: - Se parcurge fiierul i se import seria generat. - Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid". Altfel se afieaz un mesaj de eroare de comunicaie sau mesajul de eroare transmis de sistemul central.
5.19.4. Observaii n cazul n care conexiunea nu a putut fi efectuat sau parametrii nu ntrunesc condiiile necesare pentru procesare, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). Parametrul subUnitCode se transmite cu valoarea null pentru cazul n care contractul se realizeaz direct cu o unitate medical cu personalitate juridic, dar trebuie transmis pentru cazul unitilor medicale care activeaz n instituii colare sau instituii de ngrijire a btrnilor, care nu au contract direct cu Casa de Asigurri ci ntocmesc convenii de eliberare a reetelor compensate.
Versiune: 3.0.4 din 26.10.2012
Pagina 75 din 80
5.20. SERVICIUL PENTRU COMPLETAREA DATELOR DE FACTURARE

Acest serviciu este folosit pentru a permite unei farmacii s completeze datele de facturare aferente unei reete electronice eliberate anterior. Completarea detelor de facturare este necesar nainte de raportarea periodic pentru a putea fi transferate reetele electronice n SIUI pentru decontare. Astfel aplicaiile de raportare ale farmacitilor trebuie s apeleze aceast metod pentru a transmite n sistem seria i numrul facturii, precum i poziia de pe borderoul de reete eliberate. 5.20.1. Metoda updateInvoices Integer updateInvoices ( String requestXml ) Metoda are un parametru de intrare: parametrul requestXml de tip ir de caractere reprezint coninutul fiierului de cerere n format XML.
Metoda ntoarce o valoare ntreag indicnd faptul dac cererea a fost procesat cu succes, caz n care valoarea este 1, altfel se ntoarce valoarea 0, iar pentru a se determina eroarea se consult excepiile returnate. Fiierul de cerere n format XML, care se valideaz cu schema UpdateInvoicesPERequest.xsd. 5.20.2. Instruciuni de folosire Un exemplu tipic de algoritm pentru consultarea unei reete prescrise este:
Utilizatorul (farmacist) dorete s transmit datele de facturare pentru reetele electronice nainte de raportarea periodic pentru decontare: Aplicaia apeleaz metoda updateInvoices cu parametrii corespunztori (vezi lista de mai sus). Sistemul central valideaz cererea i ntoarce o valoare ntreag ca rspuns. - Dac cererea a fost procesat cu succes (valoarea ntoars este 1): - atunci aplicaia afieaz un mesaj care indic succesul operaiei; - Altfel se afieaz un mesaj de eroare de comunicaie sau mesajul de eroare transmis de sistemul central cu privire la motivul din care anularea nu a reuit.
5.20.3. Observaii n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepie). Numai pentru reetele raportate online ca validate i tiprite, iar pentru reetele eliberate parial doar pentru medicamentele eliberate, vor putea fi completate datele de facturare.
5.21. SERVICIUL PENTRU PRELUAREA BORDEROURILOR CU VALORI ADMISE LA PLAT

Acest serviciu este folosit pentru a permite unei farmacii s preia din sistemul central valorile acceptate i respinse la plat corespunztoare uneia sau mai multor raportri. n baza valorilor preluate i prin asocierea acestora cu reetele de pe care au provenit o farmacie poate emite factura/facturile de decontare ctre Casa de Asigurri, mpreun cu borderourile nsoitoare.
Versiune: 3.0.4 din 26.10.2012
Pagina 76 din 80
5.21.1. Metoda getRegisterFeedback String[] getRegisterFeedback ( String filename ) Metoda are un parametru de intrare: parametrul fileName de tip ir de caractere reprezent numele fiierului de raportare trimis de aplicaie pentru care se cere borderoul de decontare.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. Dac nu exist un fiier de raportare procesat cu numele dat, metoda ntoarce null. 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 borderourile corespunztoare acestor fiiere. 5.21.2. Metoda getRegisterFeedbackAggregated String[] getRegisterFeedbackAggregated ( String partnerUic , String partnerWorkplace , DateTime start , DateTime stop ) Metoda are patru parametri de intrare: parametrul partnerUic de tip ir de caractere reprezint codul unic de identificare fiscal al furnizorului (farmaciei); parametrul partnerWorkplace de tip ir de caractere reprezint codul punctului de lucru al farmaciei (acest parametru trebuie sa aib valoarea din contractul ncheiat cu CAS, iar dac farmacia nu are punct de lucru se va trimite string vid ). parametrul start de tip dat calendaristic reprezint data de nceput a perioadei pe care se face agregarea borderourilor; parametrul stop de tip dat calendaristic reprezint data de sfrit a perioadei pe care se face agregarea borderourilor.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector reprezint URL-ul de la care se face descrcarea fiierului, iar cel de-al doilea ir reprezint dimensiunea fiierului care trebuie descrcat. Dac nu exist un fiier de raportare procesat cu numele dat, metoda ntoarce null. Aceast metod permite preluarea datelor de pe mai multe raportri dintr-o perioad calendaristic i agregarea borerourilor pentru reetele de pe toate aceste raportatri, spre deosebire de prima metod care permite prealuare borderourilor pentru o singur raportare. 5.21.3. 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 cu rezultatul procesrii raportrii n SIUI.
Schema de validare pentru fiierul transmis din sistemul central este prezentat n anexa corespunztoare furnizorilor se servicii farmaceutice cu circuit deschis, i se numete ExportPharmacyInv.xsd. Un exemplu tipic de algoritm pentru actualizarea nomenclatoarelor este:
Se apeleaz metoda getRegisterFeedback cu parametrii corespunztori. 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 fiierul ZIP 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 tabela de erori 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.
Versiune: 3.0.4 din 26.10.2012
Pagina 78 din 80
6. SERVICII OFFLINE DE INTERFAARE CU SIUI

Pe lng serviciile Web expuse online, exist i o alt categorie de servicii prin care furnizorii pot schimba date cu SIUI. Aceste servicii sunt disponibile doar offline, i permit importul n SIUI a unor date care nu privesc direct fluxul de raportare periodic.
6.1. SERVICIUL PENTRU PRELUAREA DATELOR DE CONTRACTARE

Acest serviciu este folosit pentru completarea datelor din mapele de contractare ale furnizorilor de servicii medicale n relaii contractuale cu CASAOPSNAJ. Acest serviciu nu este disponibil online, ci doar offline, el permind importul de ctre operatorii CAS prin intermediul interfeei cu utilizatorul a SIUI a unui fiier XML care conine datele cerute de SIUI pentru ncheierea sau prelungirea unui contract de prestare servicii. 6.1.1. Instruciuni de folosire Numele fiierului XML cu datele necesare pentru contractare trebuie sa respecte formatul:
{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. Prezentm n continuare lista de valori admise pentru prefix, n funcie de tipul de furnizor:
Valoare prefix fiier MF_S FARMD_S CLIN_S PARA_S STOM_S AMB_S MD_S HC_S SPT_S RECA_S RECS_S Tip de furnizor corespunztor Medicin primar i de familie Farmacii (circuit deschis) Specialiti clinice Specialiti paraclinice Specialiti stomatologice Ambulane Dispozitive medicale ngrijire la domiciliu Spitale Recuperare - ambulatoriu Recuperare - sanatorii
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 valideaz fiierul XML cu schema de validare XSD corespunztoare. Se salveaz fiierul pe un suport de stocare mobil care se prezint la CAS.
Versiune: 3.0.4 din 26.10.2012
Pagina 79 din 80
Schema de validare pentru aceste fiiere este detaliat n anexele corespunztoare fiecrui tip de furnizor.
6.1.2. Observaii Acest serviciu este disponibil doar pentru furnizorii aflai n relaii contractuale cu CASAOPSNAJ, sau care doresc s ncheie un contract cu aceast cas.
Versiune: 3.0.4 din 26.10.2012
Pagina 80 din 80

Specificatie Interfatare SIUI - Aplicatii de Raportare Pentru Furnizori

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Specificatie Interfatare SIUI - Aplicatii de Raportare Pentru Furnizori

Încărcat de

Drepturi de autor:

Formate disponibile

CASA NAIONAL DE ASIGURRI DE SNTATE DIN ROMNIA SISTEM INFORMATIC UNIC INTEGRAT + PRESCRIPIE ELECTRONIC

ISTORICUL REVIZIILOR DOCUMENTULUI

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

6.1.2. Observaii .................................................................................................................................................. 80

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

Pentru aplicaiile de raportare ale tuturor tipurilor de furnizori de servicii

Pentru aplicaiile de raportare ale farmaciilor cu circuit deschis

Pentru aplicaiile de raportare ale farmaciilor cu circuit nchis

Pentru aplicaiile de raportare ale spitalelor

Pentru aplicaiile de raportare ale medicilor de familie

Pentru aplicaiile de raportare ale ambulatoriilor clinice

Pentru aplicaiile de raportare ale laboratoarelor de analize i cabinetelor de radiologie i imagistic

Pentru aplicaiile de raportare ale cabinetelor de medicin dentar

Versiune: 3.0.4 din 26.10.2012

Pentru aplicaiile de raportare ale ambulatoriilor de recuperare

Pentru aplicaiile de raportare ale sanatoriilor de recuperare i preventoriilor

Pentru aplicaiile de raportare ale furnizorilor de dispozitive medicale

Pentru aplicaiile de raportare ale furnizorilor de ngrijiri la domiciliu

Pentru aplicaiile de raportare ale unitilor private de hemodializ

Versiune: 3.0.4 din 26.10.2012

2. PREZENTARE GENERAL SIUI+PE

2.1. DESCRIEREA SISTEMULUI INFORMATIC AL ASIGURRILOR DE SNTATE DIN ROMNIA

Versiune: 3.0.4 din 26.10.2012

n Figura 1 este prezentat structura i aria de acoperire a sistemului informatic.

Figura 1 - Aria de acoperire a sistemului

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

2.2. DESCRIEREA INTERFEELOR SIUI

Versiune: 3.0.4 din 26.10.2012

Figura 2 - Conectarea aplicaiilor de raportare la SIUI

2.3. ASIGURAREA SECURITII INFORMAIEI

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

Figura 3 - Diagrama soluiei de asigurare a securitii datelor

Versiune: 3.0.4 din 26.10.2012

2.4. CLASIFICAREA TRANSFERURILOR DE DATE

Versiune: 3.0.4 din 26.10.2012

3. DESCRIEREA FLUXULUI DE LUCRU

3.1. PERSONALIZAREA I ACTIVAREA APLICAIEI

Versiune: 3.0.4 din 26.10.2012

3.2. FLUXUL DE RAPORTARE PERIODIC

3.3. FUNCIONALITI DE VALIDARE ONLINE

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

3.4. ACTUALIZRI CARE PRIVESC APLICAIILE DE RAPORTARE

Versiune: 3.0.4 din 26.10.2012

Un flux de actualizare a nomenclatoarelor este propus mai jos.

Versiune: 3.0.4 din 26.10.2012

Un flux de actualizare a datelor de contract este propus mai jos.

3.5. FUNCIONALITI SPECIFICE PRESCRIPIEI ELECTRONICE

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

Figura 4 - Exemplu de reet componenta precriere

Figura 5 - Exemplu de reet electronic tiprit n farmacie componenta eliberare

Versiune: 3.0.4 din 26.10.2012

Versiune: 3.0.4 din 26.10.2012

Procedura de citire a codului de bare

Versiune: 3.0.4 din 26.10.2012