Sistem Online de Validare a Retelelor Electronice

CUPRINS

1 Introducere

1.1 Necesitatea

1.2 Obiective

2 Sistemul Medical

2.1 SIUI

2.2 SIPE

2.3 Platforma sistemului

2.4 Reteta electronica

2.5 Tranzactii reteta electronica

3. Pregatirea aplicatiei

3.1 Configurare domeniu

3.2 Configurare Windows Server 2012 R2

3.3 Configurare DNS

3.4 Configurare IIS

4. Construire aplicatie

4.1 Module aplicatie

4.1.1 Validare conexiune sipe

4.1.2 Interogare

4.2 Servicii Web

4.3 Tranzactii aplicatie

4.4 Securitate aplicatie

5 Functii aplicatie

5.1 Consultarea retetelor prescrise

5.2 Serviciu pentru validarea retetelor electronice

5.3 Serviciu pentru anularea retetelor

5.4 Serviciul pentru consultarea retetelor electronice

5.5 Testare functii

6 Concluzii

7 Bibliografie

Anexa 1 – Acronime

1 Introducere

În ultimele decenii, firmele farmaceutice au trebuit să facă față unei concurente mai acerbe ca oricand. Acest lucru este perfect realizabil printr-o bună cunoastere și satisfacere a nevoilor consumatorilor.

Servirea promtă a clientului este un factor important în managementul farmaciei având în vedere că prețul real al oricărui lucru este dat de efortul depus pentru obținerea lui.

Firmele care vor sa castige un loc important pe piata trebuie sa analizeze asteptarile clientilor lor si gradul de satisfactie al acestora in raport cu produsele si serviciile oferite folosind metode de analiza si masurare a satisfactiei consumatorilor. O firma farmaceutică poate utiliza anumite metode, începând cu unele mai simple și sfârșind cu cele mai complicate.

Necesitatea

Coruptia din spitale este privita drept cea mai mare problema din sistemul de sanatate din Romania. Romanii sunt nemultumiti de coruptia si capusarea unitatilor sanitare din Romania, precum si de furturile din sistemul sanitar. In plus, pe seama coruptiei din spitale pot fi puse o sumedenie de alte boli ale Sanatatii – numeroase retete false eliberate, certificate ori dotari cu echipamente.

Pentru evitarea falsificarii prescriptiilor medicale, dublei decontari de catre CNAS a medicamentelor sau serviciilor medicale prestate de furnizorii aflati in contract cu CAS dar si a unei eficientizari in managementul platilor si bugetului CNAS a fost nevoie de introducerea unui sistem unic informatizat si integrat ce permite corelarea tuturor entitatilor si beneficiarilor sistemului medical.

Datorita volumului extrem de mare de date pentru prelucrare si decontare, prin eficientizarea sistemului medical a aparut termenul de reteta electronica. Corectitudinea tranzactiilor se face cu ajutorul SIUI dar si a softurilor individuale creeate pentru interfatarea cu sistemul.

1.2 Obiective

In lucrare se prezinta un sistem informatic online, ce permite unui utilzator inregistrat in sistem (in acest caz ne referim la farmacisti), de a verifica existenta unei retete prescrise de medic in sistem, de a valida medicamentatia prescrisa si de a o elibera conform specificatiilor medicului. Totodata se detaliaza pasii de interfatare cu SIUI, specificatiile si functiile Web-Service folosite.

2 Sistemul Medical

În perioada 1990-1998, s-a utilizat un sistem dualist de tipul finantare de la bugetul de stat/finantare complementara – fond special de sanatate (O.G. nr. 22/1992), precum și finantare externa – imprumuturi de la Banca Mondiala (Legea nr. 79/1991), fonduri Phare și donatii.

Principiile de organizare ale sistemului sanitar s-au imbunatatit simtitor prin acces gratuit la serviciile medicale, asistenta medicala cu plata, acoperire nationala, transferul responsabilitatilor – Directiile Sanitare Judetene, Colegiul Medicilor din Romania, alegerea libera a medicului, aparitia notiunii de medic de familie și aparitia sectorului privat.

În iulie 1997, a fost adoptata de Parlamentul Romaniei și promulgata de Presedintele tarii Legea Asigurărilor Sociale de Sănătate – Legea nr. 145/1997. Aceasta a urmarit modelul de asigurări tip Bismark, cu asigurare de sanatate obligatorie, bazat pe principiul solidaritatii și functionand în cadrul unui sistem descentralizat. Ea a intrat în vigoare, cu toate prevederile, incepand cu 1 ianuarie 1999 dar a existat o perioada de tranzitie în anul 1998 în care Directiile Sanitare Judetene și Ministerul Sănătații au administrat fondurile de asigurare. În consecinta, de la 1 ianuarie 1999, conform legii au functionat și casele de asigurări ca institutii publice autonome, conduse de reprezentantii asiguratilor și patronatului prin consiliile de administratie, deci și Casa Națională de Asigurări de Sănătate.

2.1 SIUI

Sistemul Informatic Unic Integrat (SIUI) este considerat cel mai complex sistem informatic care exista in momentul de fata in Romania si care acopera toate fluxurile de la Casa Nationala de Asigurari de Sanatate (CNAS) si are rolul sa deserveasca toate activitatile care tin de sistemul de asigurari de sanatate:

integreaza în rețea furnizorii de servicii de sănătate si de servicii farmaceutice aflați în contract cu CNAS (medicii de familie, spitalele, farmaciile, laboratoarele etc), sub supravegherea CNAS, pe soft-uri unice, individualizate pe tipuri de furnizori;

evidentiaza cheltuielile care se fac din bugetul asigurărilor de sănătate (din FNUASS);

gestioneaza serviciile medicale pe care statul le plateste catre medici, farmacisti, spitale, ingrijiri la domiciliu etc.;

uniformizeaza sistemul de raportare și prelucrare a datelor din sănătate, la nivel național și județean;

are aproximativ 30.000 de beneficiari;

cuprinde toate Casele Județene de Asigurări de Sănătate (CJAS), peste 500 spitale, 50.000 medici, 10.000 furnizori de asistență medicală primară, 95.000 asistenți medicali, peste 4.100 furnizori de servicii farmaceutice si 2.600 furnizori de dispozitive medicale. La acestia se adauga furnizori de servicii de ambulanță, furnizori servicii de îngrijire la domiciliu, aproape 450 furnizori de servicii de recuperare în ambulatorii etc.;

utilizeaza o baza de date de 5,8 terra bytes cu toata populatia Romaniei;

sunt implicati toti actorii din sistemul de sanatate in mod direct;

indirect toata populatia Romaniei este beneficiara a sistemului;

marimea sistemului este data de diversitatea aspectelor pe care le trateaza cat si de multitudinea surselor de date;

permite colaborarea dintre institutii si persoane apartinand domeniului medical dar si din afara acestuia (de ex : Ministerul Finantelor, Registrul Comertului, Evidenta Persoanelor, Ministerul Muncii, unitatile administrativ-teritoriale etc.);

este aliniat la strategia națională de informatizare și se poate alinia ușor la reglementările organismelor internaționale cu care se efectuează schimburi permanente de date;

este proiectat pentru a asigura protectia datelor atat impotriva dezastrelor cat si a accesului neautorizat.

Obiectivele principale ale SIUI sunt:

transparenta privind controlul și gestionarea fondurilor bugetare ale CNAS;

evidenta persoanelor asigurate și a furnizorilor de servicii medicale;

evidentierea și controlul costurilor pentru fiecare asigurat;

eficientizarea raportării datelor de către furnizorii de servicii medicale;

uniformitate în aplicarea normelor și legislatiei la nivel national;

colectarea și gestionarea informatiilor economice si medicale necesare functionării eficiente a Sistemului Asigurărilor de Sănătate;

interfete on-line și off-line pentru interconectarea cu entităti externe sistemului și cu furnizorii de serviciimedicale și farmaceutice

2.2 SIPE

Sistemul Informatic de Prescripție Electronică (SIPE) este o extindere a SIUI, prin adăugarea functionalitătilor specifice Prescriptiei Electronice: o modalitate de evidentă informatizată a prescrierii si eliberării medicamentelor compensate si gratuite, suportate parțial sau integral din Fondul Național al Asigurărilor Sociale de Sănătate (FNUASS).

Conform Ministerul Sanatatii -Ordinul nr. 674/2012:

”Prescripția medicală electronică este un formular utilizat în sistemul de asigurări sociale de sănătate pentru prescrierea de medicamente cu și fără contribuție personală în tratamentul ambulatoriu și poate fi: on –line sau off-line.

Prescripția medicală electronică on-line și off-line are două componente: o componentă care se completează de către medicul prescriptor și o componentă care se completează de către farmacist, denumite componenta prescriere, respectiv componenta eliberare.

Prescripția medicală electronică on-line este formularul de prescripție medicală în format electronic, completat de medic/farmacist folosind o aplicație informatică dedicată, conectată la Sistemul Informatic pentru Prescripția Electronică al Casei Naționale de Asigurări de Sănătate, prescripția fiind validată și înregistrată în formă electronică în sistem înainte de a fi tipărită. Pentru conectarea la SIPE al CNAS, furnizorul de servicii medicale/ medicamente trebuie să utilizeze un certificat digital calificat, iar aplicația trebuie să fie înregistrată în baza unei serii de licențe eliberate prin sistem”.

SIUI-PE este proiectat utilizând o arhitectură centralizată. Colectarea si prelucrarea datelor se realizează prin intermediul unei ferme de servere de aplicatie ce accesează datele stocate în baza de date centrală, prezentând seturi diferite de functionalităti in functie de diferiti utilizatori (functionalităti specifice CNAS sau CJAS)

2.3 Platforma sistemului

Conform (SPEC), SIUI are o structură ierarhică distribuită pe 3 niveluri reprezentate de: CNAS (nivel 2), CJAS (nivel 1) și furnizorii de servicii medicale și farmaceutice (nivelul de baza) reprezentata in Figura 1.

Pentru toate categoriile de furnizori există aplicatii informatice specifice prin care acestia raporteaza către nivelul central serviciile prestate sau produsele furnizate si aplicatii cu ajutorul carora pot prelua de la nivelul central informatiile necesare înregistrării datelor primare si efectuării raportărilor.

La nivelul de bază se află diversii furnizori cu care sistemul (SIUI) operează schimburi de date (furnizorii de servicii medicale, de dispozitive medicale, furnizorii de medicamente si servicii farmaceutice).

Fig. 1.Flux informational al sistemului CNAS

SIUI oferă furnizorilor de la nivelul de baza interfete programatice de colectare și validare a datelor, prin intermediul datele despre serviciile prestate de fiecare furnizor de servicii medicale si farmaceutice se se inregistreaza în format electronic în sistem. Inregistrarea poate fi făcuta on-line, prin comunicatie electronică directă securizată, sau off-line, pe un suport de stocare mobil. De asemenea există posibilitatea interogării sistemului de către furnizorii de servicii medicale si farmaceutice pentru a sincroniza datele din aplicatia de raportare cu rezultatele prelucrării acestor raportări la nivel CJAS, prin transmiterea erorilor detectate către fiecare furnizor de servicii medicale si farmaceutice.

La nivelul urmator, al CJAS, se consolideaza informatiile de interes pentru SIPE de la nivel judetean. Majoritatea functionalitătilor sunt implementate la acest nivel judetean- acesta fiind nivelul în care informatiile sunt prelucrate, iar în urma prelucrăriilor sunt obtinutute datele de iesire din sistem către nivelul inferior. Acest nivel este responsabil cu gestionarea comunicării cu partenerii de la nivelul de baza, deoarece nivelul de baza nu are acces direct la nivel CNAS. Aceste informatii se obtin fie pe un flux informational prestabilit (transfer de date în format electronic), fie se pot opera cu ajutorul interfetelor puse la dispozitie de sistem.

Fiecare proces identificat la nivel CJAS are un corespondent la nivel CNAS, sistemul consolidând la nivel CNAS toate informatiile provenite de la casele judetene, stabilindu-se astfel un flux informatic care propagă informatiile de la nivelul 1 la nivelul 2 (CNAS).

Nivelul CNAS- are doua mari categorii de functionalităti cu flux de date distinct pentru fiecare functionalitate.

Prima o constituie elaborarea normelor care guvernează sistemul . La acest nivel se stabilesc criteriile de evalua nivelul de baza, deoarece nivelul de baza nu are acces direct la nivel CNAS. Aceste informatii se obtin fie pe un flux informational prestabilit (transfer de date în format electronic), fie se pot opera cu ajutorul interfetelor puse la dispozitie de sistem.

Fiecare proces identificat la nivel CJAS are un corespondent la nivel CNAS, sistemul consolidând la nivel CNAS toate informatiile provenite de la casele judetene, stabilindu-se astfel un flux informatic care propagă informatiile de la nivelul 1 la nivelul 2 (CNAS).

Nivelul CNAS- are doua mari categorii de functionalităti cu flux de date distinct pentru fiecare functionalitate.

Prima o constituie elaborarea normelor care guvernează sistemul . La acest nivel se stabilesc criteriile de evaluare a furnizorilor de servicii medicale si farmaceutice, contractele cadru conform cărora se vor presta si deconta serviciile medicale si farmaceutice precum si care sunt aceste servicii. Toate aceste elemente constituie o parte din regulile de functionare a SIUI. Aceste informatii sunt transmise prin intermediul unui flux informational către nivelul CJAS care, la rândul său, prin intermediul altui flux informational va transmite datele de interes la nivelul furnizorilor de servicii medicale si farmaceutice.

A doua categorie de functionalităti ale acestui nivel o constituie functionalitătile de prelucrare a informatiilor de la nivel national, fie în vederea validării informatiilor de la nivel judetean, fie în vederea prelucrării statistice a informatiilor din sistem. Fluxul informational care deserveste aceste functionalităti pleacă de la nivel CJAS si se caracterizează prin transmiterea la nivel CNAS a tuturor informatiilor de interes în vederea prelucrării lor centralizat, la nivel national.

2.4 Reteta electronica

Conform Ordinul Ministerului Sănătății nr. 674 din 29 iunie 2012, de la 1 ianuarie 2013, a intrat în vigoare obligativitatea emiterii rețetelor medicale în format electronic, utilizând un certificat digital calificat.

Rețeta electronica este un formular electronic utilizat în sistemul de asigurări sociale de sănătate pentru prescrierea medicamentelor si poate fi online sau offline avand o componentă de prescriere (pe care o completează medicul –A-) și o componentă de eliberare (pe care o completează farmacistul -B-), prezentata in Figura 2.

Pentru prescrierea rețetelor electronice, medicii au nevoie de o imprimantă, un calculator pe care să aibă instalată o aplicație informatică dedicată care permite crearea rețetei și înregistrarea datelor în sistemul informatic pentru prescripția electronică (SIPE) al CNAS, la care se conecteaza folosind un certificat digital calificat emis de un furnizor acreditat de servicii de certificare.

Certificatul digital garantează identitatea electronică a utilizatorului si ii permite furnizorului de servicii medicale sa se poate conecta la sistemul central și sa poata emite rețete electronice, sa confirme retetele emise de medici, sa elibereze prescriptia si sa finalizeze eliberarea retetelor si raportarea acestora in vederea decontarii.

Fig. 2. Reteta electornica

Componenta prescriere Componenta eliberare

2.5 Tranzactii reteta electronica

Pentru ca o reteta electronica sa fie utilizata cu succes se executa minim 7 pasi, asa cum sunt prezentati in Figura 3. Pacientul se prezinta la medic, pentru consultatie. In functie de diagnostic, medicul ii emite o reteta in format tiparit si o inregistreaza in format electronic in sistem. Pacientul merge cu reteta tiparita si cu actul de identitate la farmacie pentru a ridica medicatia.Farmacistul scaneaza codul de bare 2D de pe retata si verifica validitatea acesteia in sistem. Dupa verificarea retetei, calculeaza prescriptia conform nomenclatorului de medicamente si cantitatii solicitate de pacient (dar nu mai mare decat cantitatea prescrisa de medic) si in urma acceptului pacientului o inregistreaza in sistem ca fiind eliberata, astfel incat pacientul sa nu poate ridica medicatia aceleasi retete din mai multe farmacii.

Figura 3. Tranzactii reteta electronica

Retetele electronice vor fi însotite de un formular tipărit ce va contine un cod de bare 2D care va reprezenta într-o formă codificată si comprimată toate informatiile înscrise pe retetă, atât de către medic cât si de către farmacist.

Pasii ce pot fi efectuati pentru o reteta electronica, de catre utilizator sunt urmatorii :

– consultarea retetei, serviciu ce este apelat de aplicatiile de raportare ale farmacistilor după identificarea pacientului si a retetei (prin scanarea codului de bare 2D) pentru a asigura autenticitatea retetei, iar pentru a nu se permite interogarea abuzivă a bazei de date se folosesc datele de identificare precum sunt: seria si numărul retetei, parafa medicului prescriptor si CUI-ul unitătii emitente;

– validarea retetelor electronice, prescrise de medici sau eliberate de farmacii, unde farmacistii vor completa în aplicatiile specifice datele necesare, iar aplicatiile vor transmite către sistemul central aceste date, iar în urma validării vor afisa medicului sau farmacistului mesaje de avertizare cu privire la corectitudinea datelor din punct de vedere al respectării normelor cu privire la retetele compensate si gratuite, dar si o serie de reguli cu caracter medical referitoare la interactiuni adverse între medicamentele prescrise sau între medicamente si diversele diagnostice cronice sau cu risc vital ale pacientului, în măsura în care aceste informatii sunt cunoscute de către sistem;

– anularea retetelor electronice, permite medicului să anuleze o retetă pe care a lansat-o deja în sistem (a marcat-o ca tipărită) în cazul în care acesta constată ulterior o greseală de întocmire sau o schimbare în starea de sănătate a pacientului, ceea ce necesită emiterea unei noi retete în conditiile prevăzute de normele CNAS; o retetă poate fi anulată doar de medicul care a prescris-o, el trebuind să prescrie o retetă nouă în cazul în care a anulat o retetă. Pacientul trebuie să se întoarcă la medic pentru ca acesta să îi elibereze o nouă retetă. O retetă prescrisă nu mai poate fi anulată de către medic după ce aceasta a fost eliberată într-o farmacie total sau partial.

– confirmare reteta, incheie procedura de eliberare prin valizarea retetei in sistem; in cazul retetei fractionate farmacistul inmineaza pacientului un exemplar al formularului de eliberare de medicamente cu care pacientul poate sa se adreseze altei farmacii de unde va ridica si restul de medicamente; se verifică dacă rețeta este corectă prin validarea în sistemul central dacă medicul prescrie on-line, iar dacă nu este conectat cu sistemul, deci în starea off-line, validarea se face local și parțial în cadrul aplicației proprii (odată validate nu mai pot fi modificate/corectate ulterior) cu precizarea ca rețetele emise off-line trebuie transmise ulterior în sistem, la o eventuală conectare la internet (la sistem) printr-o sincronizare automată sau odată cu raportarea periodică a serviciilor la CAS. În acest caz CAS-ul va prelua automat în sistem urcarea rețetele din raportarea medicului.

Din punct de vedere al aplicatiei, pentru simplificarea si eficientizarea corectitudinii datelor, dupa deschidere aplicatie pentru eliberarea de medicamente:

– automat se incarca datele de identificare ale farmaciei: nume unitate, CUI, nr.contract cu CAS, data eliberarii, date despre persoana care elibereaza (nume/prenume);

– inscriere date persoana care ridica medicatia daca este asiguratul pe numele caruia a fost facuta prescrierea ; nume/prenume/ CI/CNP/CE/PASS sau manual daca este un imputernicit;

– inscrie codul W specific pentru fiecare denumire comerciala (pe formularul printat va aparea denumirea comerciala in clar), %pret referinta, lista de incadrare a medicamentului, codul de boala, cantitatea eliberata (UT), pret cu amanuntul, pretul de referinta, valoarea cu amanuntul, valoare compensare;

– calculeaza (daca este cazul) suma pe care trebuie pacientul sa o plateasca suplimentar (contributia asiguratului); reteta se poate elibera si fractionat (numai pentru retetele prescrise ''on-line'' si semnate electronic); se elibereaza numai anumite medicamente(solicitate de pacient) dar nu se elibereaza fractionat pe unitati, cantitati dintr-un medicament caz in care pacientul se poate duce sa-si ridice restul de medicamente nepreluate din farmacie la alta farmacie, dar din acelasi judet cu care medicul are contrac cu CAS;

– valideaza reteta in sistem;

– printeaza reteta; se printeaza automat codul de bare care contine toate datele inscrise in reteta, toate medicamentele eliberate;

– semneaza, parafeaza si stampileaza formularul de eliberare medicamente

3. Pregatirea aplicatiei

Implica configurarea mediului de dezvoltare si rulare al aplicatiei si presupune:

– achizitia unui domeniu de la un provider acreditat ( se va achizitiona domeniul phdresearch.ro de la providerul rotld.ro);

– configurarea domeniului pentru a accepta un DNS privat (serverul utilizat pentru aplicatie);

– instalarea de Windows Server 2012 R2 si configurarea acestuia pentru a putea utiliza DNS si IIS;

– dezvoltarea aplicatiei in Visual Studio 2013 folosind ASP.NET.

Configurare domeniu

Se completeaza nameserverele adaugand numele calculatorului (Computer Name) urmat de adresa domeniului. In cazul nostru avem nume calculator “NS” si domeniul “phdresearch.ro”. Obtinem numele nameserverului “ns.phdresearch.ro”asa cum este prezentat in Figura 4.

Figura 4. Configurare name server pentru domeniu.

De mentionat faptul ca avem nevoie de un IP fix, deoarece acesta va face legatura dintre numele domeniului si calculatorul unde se face hosting pentru domeniu. In cazul in care IP-ul ar fi variabil (se schimba la fiecare reconectare la providerul de internet) ar trebui sa se faca reconfiguarea name-serverului pe portarul rotld.ro ca in Figura 4.

Dupa adaugarea nameserverului pe TLD-ul “.RO” prin portalul rotld.ro, in momentul cautarii “phdresearch.ro”, prin http, providerul (rotld) va redirectiona traficul catre ip-ul definit, in cazul nostru: 86.124.64.19. Pentru traficul de dns este necesar ca portul 53 sa fie deschis si sa nu fie blocat de firewall. In cazul in care IP-ul serverului utilizat nu este legat direct la internet, sa aiba IP extern (lucru intalnit in mai putin de 0.1 % din cazuri), este necesar ca portul 53 sa fie fowardat din rooter pe ip-ul intern (de retea) al serverului ca in cazul nostru, asa cum este prezentat in Figura 5.

Figura 5. Accesare pagina web.

3.2 Configurare Windows Server 2012 R2

Se instaleaza Windows Server 2012 R2 Essentials. Dupa instalare, in Server Manager se adauga Rolurile de DNS si IIS. Ca si configurare specificatii server se foloseste un server cu procesor Intel Celeron E3400 Dual Core si 4 GB RAM. Server manager este prezentat in Figura 6.

Figura 6. Server Manager pe Windows Server 2012 R2.

3.3 Configurare DNS

Se face in 2 pasi. Primul reprezinta configurarea serverului DNS pentru a accepta domeniul, iar al doilea se refera la configurarea domeniului.

Pentru a configura serverul se executa urmatorii pasi:

Din DNS Manager se apasa pe Configure a DNS server (adauga domeniul ca si ramura)

Create a forward and reverse lookup zone (exista 3 variante: adaugare de forward lookup zone care se refera la traducerea adresei domeniului din nume in IP (phdresearch.ro = 86.124.64.19); adaugarea de forward and reverse lookup zone care este folosita atunci cand pe baza ip-ului se afla numele domeniului (86.124.64.19 = phdresearch.ro) si root hints only care reprezinta o configurare mai robusta.

This server maintains the zone ( exista 2 variante, prima in care serverul actual mentine toate datele de configurare a domeniului si a doua in care serverul actual este o replica a serverului principal)

Zone name: numele domeniului (phdresearch.ro)

Allow only secure dynamic updates (exista 3 variante, prima, fiind si cea folosita in cazul nostru, ce permite update doar securizat (in cazul unui lant de servere DNS, multiple name-servere) , updateul putandu-se face doar din alte nameservere; both secure and nonsecure updates ce permite updatarea nameserverului nostru din servere externe si neacceptarea de updateuri)

Yes it should forward queryes : se completeaza FQDN cu ip-ul fix

Figura 7. Parametrii server DNS.

Pentru configurarea domeniului se executa urmatorii pasi:

New Host A: same as parent (face tranzitia dintre ip si nume)

New Host A: www (pentru a putea accesa subdomeniul www -> in cazul nostru va fi acelasi cu domeniul)

New Host A: service ( subdomeniul unde va fi aplicatia)

Name server NS : ns.phdresearch.ro

Mail exchange MX : phdresearch.ro (pentru a folosi un client de e-mail)

Figura 8. Parametrii domeniu DNS.

Start of Authority (SOA): serial number unic format din an,luna,zi,cod domeniu si datele pentru updatare server asa cum sunt prezentati in Figura 9.

Figura 9. SOA pentru domeniu.

Reverse lookup zones: pentru tranzitarea din ip in nume asa cum se arata in Figura 10.

Figura 10. Reverse Lookup Zones

3.4 Configurare IIS

Se realizeaza prin adaugarea domeniului, setarea application pool (frameworkul de rulare) asa cum se arata in Figura 11, ip-ul si portul pentru fiecare adresa in parte (domeniu, subdomeniu) si directorul unde este instalata aplicatia, precum si pagina de rulare asa cum apar in Figura 12.

Figura 11. IIS Manager.

Figura 12. IIS configurare domeniu.

4. Construire aplicatie

Stabilirea algoritmului de lucru

– va contine o pagina de login (autentificare) pentru ca aplicatia sa fie utilizata doar pe persoanele abilitate

– pagina principala ce va contine meniul, si date despre aplicatie plus mainframeul pentru restul paginilor

– pagina pentru preluare date reteta electronica ( se completeaza de catre utilizator )

– pagina pentru afisarea retetei

Ca si module:

Modul de login ce va salva in cookie userul logat

Modul de conectare la o baza de date locala (SQL Server 2014) ce contine userii acreditati + pagina de creare,stergere,modificare user

Modul de conectare la SIUI, ce va folosi https si un token conform specificatiilor

Modul descarcare reteta electronica : folosind WSDL-ul si functiile aferente serverului SIUI

Modul de prelucrare reteta electronica : conversie xml si prelucrare date inainte de afisare

4.1 Module aplicatie

4.1.1 Validare conexiune SIPE

Pentru a putea accesa SIUI este nevoie de un certificat digital emis de o autoritate publică de certificare recunoscută de STS. Certificatul digital trebuie să fie înregistrat în SIUI pentru a putea accesa serviciile online ale sistemului. În SIUI se vor crea conturi de utilizatori autorizati în sistem pentru fiecare operator, iar conexiunea se va putea efectua numai pe baza certificatului digital. Certificate digitale sunt gestionate într-o bază de date dedicată prin intermediul unei aplicatii de administrare de către operatorii de la CJAS.

Certificatul digital trebuie instalat pe calculatorul pe care este instalată aplicatia de conectare la sistem și este accesibil aplicatiei prin mijloace de interconectare, instalare pe sistemul de operare sau acces prin driver sistem la un eToken.

Un model de certificat digital utilizat este Alladin de la autoritatea Certsign cum se arata si in Figura 13. Pentru a putea folosi certificatul se instaleaza driverul SafeNet Authentification Client 8.2_01 de la provider.

Inainte de utilizarea certificatului, se instaleaza “lantul de incredere” tot de la producator ce ajuta la certificarea autenticitatii tokenului.

Figura 13. Certificat digital.

Aplicatia de conectare si verificare reteta foloseste certificatul pentru autentificarea și autorizarea cererilor online către SIUI prin intermediului protocolului HTTPS/SSL.

Conform (SPEC), poarta de intrare în SIUI este securizată prin intermediul unui echipament hardware care joacă rolul de firewall, accelerator SSL si load-balancer, în acelasi timp realizând și verificarea certificatelor digitale prezentate de aplicatiile de raportare din punct de vedere al integritătii și valabilitătii la deschiderea unei noi sesiuni SSL prin HTTPS.

În urma verificării integritătii și valabilitătii certificatului, acceleratorul SSL transmite mai departe cererea prin protocol HTTP către un server de autentificare și autorizare, parte integrantă a SIUI, înglobând în header-ul HTTP și informatiile din certificatul digital necesare pentru verificarea prin OCSP a stării de revocare certificatului digital.

Acest server verifică în baza de date dedicată, dacă certificatul digital a fost înregistrat de către un utilizator autorizat al sistemului, iar dacă este, formulează o cerere prin protocolul OCSP către serviciul pus la dispozitie de STS. Acest serviciu verifică autenticitatea certificatului prin interogarea serviciilor similare ale autoritătilor de certificare publice cu care STS are protocoale de comunicare.

Serviciul de Telecomunicatii Speciale oferă ca parte a acestui sistem o componentă care permite interogarea simultană a tuturor Autoritătilor de Certificare publice din România, realizând astfel izolarea sistemului de eventuale modificări ale structurii sau componentei acestor autorităti. Această componentă trebuie să respecte, la rândul 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 aplicatiei de raportare un token software (session-id-hash) care trebuie folosit de aceasta la apelurile următoare pe sesiunea SSL curentă la sfârsitul URL-ului de apel, pentru a indica sistemului că sesiunea a fost deja autorizată, evitând astfel verificarea excesivă a certificatului care ar putea introduce penalizări de performantă semnificative.

Acceleratorul SSL foloseste acest session-id-hash pentru a transmite cererile ulterioare către serverele de aplicatie SIUI. Aici hash-ul este verificat si în functie de drepturile de acces se va acorda accesul către 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 corespunzător:

– 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 farmaciștilor.

În acest context prin autentificare se întelege confirmarea identitătii declarate a unui utilizator, iar prin autorizare se întelege procesul de acordare a accesului la resursele informationale din sistem numai utilizatorilor, aplicatiilor, proceselor si altor sisteme care detin credentialele necesare. Practic la autentificare se verifică identitatea initiatorului unei cereri de acces, iar la autorizare se verifică existenta unor drepturi pe baza cărora se permite sau nu accesul la resursele cerute.

Figura 13. Autentificare in SIUI

Pentru a evita verificarea certificatului digital la fiecare apel aplicatia de conectare si interogare trebuie să implementeze un mecanism prin care să mentină deschisă sesiunea SSL, astfel încât ulterior autentificării si autorizării apelurile către serviciul Web să poată fi efectuate direct.

Codul pentru conectare la sistem este atasat in Anexa 2 si diagrama de conectare in Figura 13.

4.1.2 Interogare

Pentru interogarea retetelor prescrise de medici sau eliberate de farmacisti, utilizatorul va completa în aplicatie datele necesare pentru interogare, iar aplicatia va transmite către sistemul central aceste date, iar în urma validării se va afisa utilizatorului mesaj de avertizare cu privire la corectitudinea datelor din punct de vedere al respectării normelor cu privire la retetele compensate si gratuite si daca reteta a fost deja eliberata total sau partial. In cazul confirmarii retetei in sistem se afiseaza si o serie de reguli cu caracter medical referitoare la interactiuni adverse între medicamentele prescrise sau între medicamente si diversele diagnostice cronice sau cu risc vital ale pacientului, în măsura în care aceste informatii sunt cunoscute de către sistem.

Retetele electronice vor fi însotite de un formular tipărit ce va contine un cod de bare 2D care va reprezenta într-o formă codificată si comprimată ce cuprunde toate informatiile înscrise pe retetă, atât de către medic in cazul prescrierii cât si de către farmacist in cazul finalizarii si confirmarii retetei.

Pentru codul de bare 2D se respecta urmatorii pasi:

1. Aplicatia de raportare generează un fisier XML cu informatiile existente de pe retetă pe care îl validează cu schema PEBarcode.xsd.

2. Aplicatia serializează XML-ul ca un array de bytes codificat UTF-8 pe care îl comprimă utilizând algoritmul portabil ZIP.

3. Informatia comprimată este stocata tot într-un array de bytes care este apoi codificat folosind algoritmul Base256 (care reprezintă un mod optim de stocare a informatiei 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 este tipărit pe retetă, asa cum apare în exemplele prezentate mai sus la Figura 2.

Pentru a putea interoga o reteta, folosind aplicatia, aceasta trebuie sa fie incarcata de medic in sistem sau sa avem formatul tiparit al acesteia. Pentru ca medicul sa incarce reteta in sistem trebuie sa execute urmatorii pasi:

– se autentifică în aplicatia de medici, iar aceasta stabileste conexiunea cu sistemul SIUI folosind certificatul digital înregistrat în sistem si cu seria de licentă (user/pass obtinut de la CJAS cu care are contract);

– identifică pacientul pe baza unui act de identitate sau a cardului de asigurat (platforma CEAS ce va fi disponibila sistemului CAS la finalul anului 2014), determină categoria de asigurat a acestuia si înregistrează datele necesare pentru întocmirea retetei electronice;

– softul utilizat de medic preia automat unele informatii despre pacient din sistemul central sau de pe cardul de asigurat;

– in SIUI se aloca un numar de reteta automat (din cele generate pentru medicul respectiv ) pentru a evita ca doi medici sa aiba aceeasi serie si numar de reteta;

– se completează mai întâi diagnosticele pacientului începând cu cel principal, apoi medicamentele prescrise, pozitie cu pozitie, precizând substanta activă, concentratia, forma farmaceutică, cantitatea si modul de administrare;

– reteta se transmite spre validare către sistemul central; medicul poate corecta reteta în cazul în care există nereguli de conformitate cu normele în vigoare, dar în cazul validărilor medicale poate să îsi asume răspunderea actului medical si să treacă peste avertizările emise de sistem, cu precizarea motivelor;

– tipăreste reteta si o înmânează pacientului, spre a-i servi la farmacie.

De specificat faptul că medicul poate folosi în situatii exceptionale aplicatia de emis retete în regim offline (fără o conexiune cu sistemul central), caz în care nu va beneficia de validările de conformitate cu actele normative si nici de cele de natură medicală. În acest caz reteta va fi marcată ca atare si va urma un flux distinct la farmacie (nu va fi semnata electronic de catre medic, adica nu va putea fi eliberata fractionat). Pentru aceste retete se va putea scana codul de bare ca si în cazul retetelor 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 iar in cazul in care exista erori si neconcordante pentru medicamentele prescrise iar farmacistul o valideaza in sistem, medicul este direct respunzator

De asemenea, pentru a permite medicilor de familie să acorde servicii medicale la domiciliul pacientului, unde nu va putea accesa aplicatia de raportare, nici măcar în regim offline, dar si pentru situatii de calamităti naturale când medicul nu va putea utiliza aplicatia, este prevăzut un flux de lucru paralel, cu calupuri de retete care vor fi controlate separat, ce va permite medicului să-si tipărească în prealabil un set de retete în alb (care vor contine un cod de bare 2D ce va servi doar la identificarea medicului si a exemplarului de retetă) pe care le va completa manual ca si în prezent. Aceste retete vor fi tratate la farmacie ca si retetele prescrise offline din aplicatia medicului, cu deosebirea că farmacistul va trebui sa introducă în aplicatia proprie medicamentele prescrise de medic pe care doreste să le elibereze (aceste informatii nefiind cuprinse în codul de bare), asa cum se procedează si în prezent in cazul retetelor emise online sau offline in sistem.

Pentru ca utilizatorul sa interogheze reteta in aplicatie trebuie sa urmeze pasii, conform Figura 14:

– se autentifică în aplicatie pe baza de username si parola (sunt stocate in SQL local), iar aceasta stabileste conexiunea cu sistemul central folosind certificatul digital înregistrat în SIUI si cu seria de licentă obtinuta de la CJAS;

– se identifică pacientul sau împuternicitul pe baza unui act de identitate sau a cardului de asigurat;

– exista trei variante de a introduce datele in aplicatie: a) se scanează codul de bare 2D de pe retetă pentru a prelua informatiile prescrise de medic si se interogheaza sistemul pentru a downloada reteta incarcata de medic in sistem in cazul retetelor eliberate online, b) se scanează codul de bare 2D de pe retetă pentru a prelua informatiile prescrise de medic si se completează medicamentele din codul de bare pentru a fi eliberate si c) se introduc manual toate datele;

– se completează medicamentele (denumire comercială), cantitătile eliberate si preturile conform listelor de compensare în vigoare, dar si o serie de informatii financiar-contabile cum ar fi contravaloare suportată de pacient si numărul bonului fiscal prin care acesta a achitat suma;

– pentru finalizarea retetei se transmite spre validare către sistemul central si se afisează utilizatorului mesajele de validare primite de la sistem;

– se poate corecta reteta în cazul în care există nereguli de conformitate cu normele în vigoare; dacă este cazul se retransmite spre validare rereta;

– se tipăreste pentru a-i servi la decontarea contravalorii compensate de Casa de Asigurări.

Figura 14. Pasi pentru interogare sistem.

Pentru a citi codul de bare 2D se executa urmatorii pasi :

1. Aplicatia deschide portul de comunicatii serial (fizic sau virtual) specificat de utilizator (de ex. “COM1”), iar optional se poate configura viteza de comunicatie (de ex. “9600 baud”) conform cu capabilitătile cititorului.

2. Aplicatia stochează într-o memorie tampon datele primite prin portul serial si la intâlnitea unui terminator de comunicatie închide portul.

3. Dacă citirea a fost realizată cu success:

– cititorul va furniza aplicatiei un array de bytes;

– altfel aplicatia va afisa un mesaj de eroare corespunzător.

4. Aplicatia decodifică sirul de bytes realizând în sens invers pasii de la tipărire:

– decomprimare folosind algoritmul ZIP ;

– deserializare array de bytes codificat UTF-8 reprezentând XML-ul original.

5. XML-ul este validat cu schema PEBarcode.xsd, iar dacă se termină cu succes:

– atunci aplicatia va genera o nouă retetă, completată cu datele preluate, pe care farmacitul o poate edita pentru a preciza medicamentele eliberate;

– altfel aplicatia va afisa un mesaj de eroare de validare.

In cazul in care se constata o functionare necorespuzatoare procedeul de citire se opreste automat deblocand astfel portul serial sau, in cazuri exceptionale, utilizator poate anula procedeul de citire oprind rularea programului.

4.2 Servicii WEB

Conform (SPEC), un serviciu Web este o colectie de protocoale si standarde folosite pentru schimbul de date între aplicatii sau sisteme. Aplicatii software scrise în limbaje de programare diferite si care rulează pe diverse platforme pot folosi serviciile Web pentru a face schimb de date pe retea, pe Internet, într-o manieră asemănătoare comunicării inter-procese pe un singur calculator. Interoperabilitatea se datorează standardelor publice folosite.

Serviciile WEB sunt utilizate pentru comunicarea între ele si cu clientii si permit organizatiilor să comunice între ele fără a avea cunostinte despre sistemele IT ale fiecăreia.

Spre deosebire de modelele client/server, asemenea sistemului server Web/pagină Web, serviciile Web nu furnizează utilizatorilor o interfată grafică (GUI). În schimb, serviciile Web împart logică, date si procese de business prin intermediul unei interfete programatice, printro retea. Interfatarea se face direct în cadrul aplicatiilor, si 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 functionalitate specifică utilizatorilor.

Serviciile Web permit diferitelor aplicatii de pe diferite surse să comunice unele cu altele fără consum de timp, si pentru că toate comunicatiile 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 si nu sunt principii noi în lumea Internetului. Mai întâi furnizorul de serviciu Web defineste un format pentru cererile către serviciul său si pentru răspunsurile care vor fi generate de către acesta. După care, un program de calculator face o cerere către un serviciu Web prin retea si apoi într-un final, serviciul Web realizează anumite actiuni, după care trimite înapoi un răspuns.

Termenul de serviciu-web descrie o modalitate standardizată de integrare a aplicatiilor bazate pe Web folosind XML (Extensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) si UDDI (Universal Description, Discovery and Integration).

Dacă SOAP reprezintă mijlocul de comunicare dintre solicitant si furnizorul serviciului, cu ajutorul WSDL-ului este efectuată „descrierea” serviciului oferit. Această descriere se face folosind limbajul XML si oferă, practic, documentatia necesară aplicatiilor 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 si cum poate fi invocat. În fapt, descrierea unui serviciu Web se face printr-un document XML în a cărui structură pot fi incluse sase tipuri de elemente ce pot fi divizate in două grupuri: definitiile abstracte – care includ informatii despre tipurile de date folosite de serviciu (întreg, sir de caractere, etc.), mesajele pe care serviciul le poate accepta si portType-urile – care sunt metodele si procedurile serviciului; si definitiile concrete, care specifică prin legături tipul de accesare pe care serviciul îl acceptă (de exemplu, SOAP) si serviciul, care nu este altceva decât o „publicare” a porturilor definite anterior.

Pentru a avea valoare practică, un serviciu Web trebuie să fie cunoscut eventualilor săi utilizatori. UDDI este un standard al cărui rol este de a oferi un director, o carte de „telefoane” cu serviciile disponibile, astfel încât orice aplicatie să poată găsi serviciul adecvat necesitătilorsale. În fapt, acest director oferă informatii despre localizarea geografică, categorizarea industrială, informatii de contact, precum si informatii tehnice despre serviciile Web oferite.

Pe scurt, XML este folosit pentru a eticheta datele, SOAP la transferul de date, WSDL pentru descrierea disponibilitătii serviciului si UDDI este folosit pentru a lista serviciile disponibile.

Principale avantaje ale utilizării serviciilor Web sunt:

– folosesc protocoale standardizate (HTTP, SOAP, WSDL);

– nu generează dependentă de un anumit limbaj de programare sau platformă pentru aplicatiile client;

– vechile metode de comunicare (RPC, CORBA, RMI si DCOM) generau o interdependenta între aplicatia client si aplicatia server. Utilizând serviciile Web aceasta dependentă este eliminată, serverul poate fi modificat fără modificarea clientului (atât timp cât interfata expusă nu este modificată);

– accesul la serviciile Web poate fi securizat, ca în orice altă aplicatie Web.

Pentru a asigura securitatea comunicatiei este recomandată utilizarea HTTPS, un protocol de comunicatie destinat transferului de informatie criptată prin intermediul internetului, care nu este altceva decât protocolul HTTP încapsulat într-un flux SSL/TLS. Astfel datele sunt criptate la server înainte de a fi trimise clientului, astfel încât simpla interceptare a acestora pe traseu să nu mai fie suficientă pentru a avea acces la informatii.

4.3 Tranzactii aplicatie

Conform (SPEC), SIUI expune mai multe servicii Web cu ajutorul pachetului AXIS pus la dispozitie de Apache Software Foundation, o implementare a protocolului SOAP publicat de W3C (WWW-Consortium). Pachetul AXIS a fost conceput pentru a fi utilizat in cadrul unui container Web, acesta fiind în cazul SIUI serverul Tomcat

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. Serviciul de autentificare transmite aplicatiei client un jeton de sesiune care trebui adăugat de către aplicatie î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.

De notat că acest jeton are o perioadă de valabilitate limitată, după care expiră, fiind necesară obtinerea unui nou jeton.

Figura 15. Tranzactii aplicatie SIUI.

4.4 Securitate aplicatie

Conform (SPEC), pentru asigurarea securităii informaiilor transferate între aplicatie si SIUI este folosită o solutie bazată pe o infrastructură cu chei publice (PKI), care utilizează criptografia asimetrica oferind cadrul si serviciile ce pun la dispozitia utilizatorului metode pentru a genera, distribui, controla, contoriza si revoca certificate cu chei publice.

Într-un sens mai larg, se poate spune ca PKI integrează certificatele digitale, criptografia cu cheie publica si notiunea de autoritate de certificare într-o arhitectura de securitate a retelei.

Infrastructura cu chei publice (PKI) – arhitectura, tehnicile, practicile si procedurile care contribuie în mod colectiv la implementarea si functionarea sistemelor criptografice cu chei publice, bazate pe certificate; PKI constă în hardware si software, baze de date, resurse de retea, proceduri de securitate si obligatii legale, legate împreună si care colaborează pentru a furniza si implementa atât serviciile de certificare cât si alte servicii asociate infrastructurii (de ex. marca temporală).

Cheia privată – este una dintre cheile asimetrice apartinând unui utilizator si 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 cheia al cărei scop este decriptarea sau crearea de semnătură pentru uzul exclusiv al proprietarului sau 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ă defineste transformarea de verificare a semnăturii. În cazul criptării asimetrice, cheia publică defineste transformarea de criptare a mesajelor. Un exemplu de cheie publica este prezentata in Figura 20.

Lista de Certificate Revocate (CRL) – listă emisă periodic sau imediat, semnată electronic de către o autoritate, permi ând identificarea certificatelor care au fost revocate sau suspendate înainte de expirarea perioadei de validitate. CRL contine numele emitentului său, data publicării, data următoarei actualizări, numerele seriale ale certificatelor revocate sau suspendate si datele si motivele revocării sau suspendării lor.

Semnătură electronică – transformarea criptografică a datelor pentru a permite atât verificarea originii si integrită ii datelor de către destinatarul acestora cât si protejarea expeditorului si a destinatarului împotriva falsificării de către primitor; semnăturile electronice asimetrice pot fi generate de către o entitate prin folosirea unei chei private si a unui algoritm asimetric, ex. RSA.

Figura 16. Cheie publica.

Jeton (token) – structura de date folosita pentru schimbul dintre entităti si care contine informatii transformate prin tehnici criptografice. Jetonul este semnat de operatorul unei Autorităti de Înregistrare si poate fi folosit pentru autentificarea detinătorului său în relatia sa cu Autoritatea de Certificare.

Validarea certificatelor de cheie publică – verificarea stării 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, aplica iile nu trebuie sa consulte o lista mare (si uneori neactualizata) de certificate (CRL), ci doar sa trimită o cerere către un serviciu bazat pe protocolul OCSP (conform RFC-2560) pentru verificarea stării 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 având acces sigur din diverse locatii la informatiile sale; utilizatorii sistemului vor beneficia de comunicatii sigure și secrete cu ajutorul capacitătilor de criptare;

– sistemul permite atât separarea operatiei de identificare și autentificare de operatia de autorizare, cât și faptul că actele în forma lor clasică (pe suport de hârtie) pot fi înlocuite cu documente în format electronic.

Procesul de adaptare a unor aplicatii existente si de integrare a acestora într-o infrastructură cu chei publice nu reprezintă o operatie banală. Aceasta presupune că aplicatiile sau mediul în care rulează ele să poată: să manipuleze cheile si certificatele în mod sigur; să accepte si să proceseze certificatele valide; să fie capabile să obtină date relevante pentru certificate si pentru revocarea acestora. Trebuie subliniată diferenta dintre o infrastructură cu chei publice si o aplicatie care este doar capabilă să folosească serviciile de securitate puse la dispozi tie de aceasta.

Pentru a putea folosi certificatul digital se foloseste urmatoarea functie:

Private Function gaseste_certificat(ByVal serial As String) As X509Certificate2

Dim store As New X509Store(StoreName.My, StoreLocation.CurrentUser)

store.Open(OpenFlags.ReadOnly)

Dim certs = New ArrayList(store.Certificates)

Dim amgasit As X509Certificate2

For Each amgasit In certs

If amgasit.SerialNumber = zaserial Then

Return amgasit

Exit For

End If

Next

store.Close()

Return Nothing

End Function

5 Functii aplicatie

5.1 Consultarea retetelor prescrise clasice

Acest serviciu este folosit pentru a permite unei farmacii să vizualizeze retetele prescrise de medici si să elibereze medicamentele aferente retetei.

Metoda getPrescription (serial, number, pid, stencil)

Acest serviciu este destinat validării retetelor clasice pe formulare cu regim special si va fi păstrat pentru compatibilitate până la eliminarea completă a acestor retete

Metoda are patru parametri de intrare:

– parametrul serial de tip sir de caractere reprezintă seria retetei;

– parametrul number de tip sir de caractere reprezintă numărul retetei;

– parametrul pid de tip sir de caractere reprezintă CNP-ul beneficiarului retetei;

– parametrul stencil de tip sir de caractere reprezintă numărul de parafă al medicului emitent;

Metoda întoarce sir de caractere reprezentând fisierul de răspuns în format XML.

Utilizatorul introduce datele necesare, aplicatia apelează metoda trimitând ca parametri datele introduse de utilizator.

Dacă se primeste ca raspuns un sir de caractere, acesta se salvează într-un fisier XML si se valideaza cu schema de validare XSD corespunzătoare. Dacă fisierul este valid atunci se procesează fisierul XML si se afisează continutul retetei cerute, eventual se precompletează datele în ecranul de introducere retete altfel se afisează mesaj de eroare cu fisierul este corupt. Daca nu se primeste raspuns un sir de caractere, atunci se afisează exceptia returnată sau un mesaj de eroare de comunicatie.

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

Numai retetele raportate ca validate de SIUI vor fi disponibile pentru interogare de către furnizorii de servicii farmaceutice, acestia vor identifica retetele prescrise în vederea eliberării medicatiei după combinatia de câmpuri: serie si număr retetă, CNP pacient si parafă medic prescriptor.

5.2 Serviciul pentru validarea retetelor

Acest serviciu este folosit pentru validarea retetelor electronice prescrise de medici sau eliberate de farmacisti.

Utilizatorul va completa datele referitoare la reteta electronică în aplicatie care va apela serviciul Web prin care se va transmite pentru validare către sistemul central reteta reprezentată în format XML.

Serviciul expune două metode, una specifică medicului, iar cealaltă farmacistului. Ambele metode validează reteta din punct de vedere medical pentru ca pacientul să poată beneficia în acest fel de eventualele avertizări pe care sistemul le-ar putea emite cu privire la interactiuni între medicamentele prescrise sau între acestea si anumite alergii sau boli cronice ale pacientului. În acest mod, chiar dacă medicul a prescris reteta offline, farmacistul va avea acces la setul de reguli specific medicului pentru a informa pacientul despre posibile contraindicatii.

Metoda processPrescribedPrescription (reportXml )

Metoda are un singur parametru de intrare:

– parametrul reportXml de tip sir de caractere reprezintă continutul fisierului de raportare în format XML, care se validează cu schema PhysicianDrugPERequest.xsd.

Metoda este destinată procesării retetelor prescrise de medici si întoarce un sir de caractere reprezentând fisierul de răspuns în format XML care contine rezultatul operatiunii de validare online, si se validează cu schema PhysicianDrugPEResponse.xsd. Fisierul are un continut similar celui trimis de aplica ie spre procesare, dar contine la nivel de retetă (date pacient) dar si la nivel de detalii (medicamente) eventuale avertizări emise de sistem în cazul nerespectării unor norme de prescriere.

Metoda processIssuedPrescription (String reportXml )

Metoda are un singur parametru de intrare:

– parametrul reportXml de tip sir de caractere reprezintă continutul fisierului de raportare în format XML, care se validează cu schema PharmacyDrugsPERequest.xsd.

Metoda este destinată procesării retetelor eliberate de farmaciile cu circuit deschis si întoarce un sir de caractere reprezentând fisierul de răspuns în format XML care contine rezultatul operatiunii de validare online, si se validează cu schema PharmacyDrugsPEResponse.xsd.

Fisierul are un continut similar celui trimis de aplica ie spre procesare, dar contine la nivel de retetă (date pacient) dar si la nivel de detalii (medicamente) eventuale avertizări emise de sistem în cazul nerespectării unor norme de eliberare.

5.3 Serviciul pentru anularea retetelor

Acest serviciu este folosit pentru anularea re etelor electronice prescrise de medici, în cazul în care se constată ulterior o greseală de întocmire sau o schimbare în starea de sănătate a pacientului, ceea ce necesită emiterea unei noi retete. Este permisă anularea unei retete doar de către medicul care a prescris-o, acesta selectând reteta electronică introdusă anterior în aplicatia de raportare iar apoi optiunea de anulare.

Aplicatia transmite către sistemul central cererea de anulare.

În cazul în care medicul a prescris reteta electronică offline, iar farmacistul constată la

raportarea în sistem o neregulă care poate duce la anularea retetei, atunci va contacta medicul sau îl va îndruma pe pacient către acesta, deoarece nu va putea elibera medicamente în baza retetei respective.

Serviciul poate fi utilizat prin apelarea metodelor cancelPrescribedPrescription, cancelReleasedPrescription sau cancelReleasedHospitalPrescription specifice medicilor, respectiv farmaciilor cu circuit deschis si cu circuit închis, asa cum este descris în continuare:

Metoda cancelPrescribedPrescription (providerCode, physicianStencilNo, contractNo, contractType, insuranceHouseCode, series, no, prescriptionDate, cancelationReason)

Metoda are nouă parametri de intrare:

– parametrul providerCode de tip sir de caractere reprezintă codul unic de identificare al furnizorului în sistem, CUI (cod fiscal) sau CNP, după caz;

– parametrul physicianStencilNo de tip sir de caractere reprezintă numărul de parafă al medicului emitent;

– parametrul contractNo de tip sir de caractere reprezintă numărul contractului dintre furnizor si Casa de Asigurări;

– parametrul contractType de tip sir de caractere reprezintă codul tipului de contract;

– parametrul insuranceHouseCode de tip sir de caractere reprezintă codul casei de asigurări cu care furnizorul are contract, valoare din nomenclatorul de case de asigurări.

– parametrul series de tip sir de caractere reprezintă seria retetei;

– parametrul no de tip sir de caractere reprezintă numărul retetei;

– parametrul prescriptionDate de tip dată calendaristică reprezintă data la care reteta a fost prescrisă de medic;

– parametrul cancellationReason de tip sir de caractere reprezintă motivatia anulării (text liber).

Metoda întoarce o valoare întreagă indicând dacă cererea a fost procesată cu succes, caz în care valoarea este 1, altfel apelul întorcându-se cu eroare.

De precizat faptul ca apar urmatoarele restrictii:

Medicul nu mai poate anula o reteta prescrisa daca aceasta a fost eliberata de farmacist

Farmacistul nu mai poate anula o reteta eliberata daca aceasta a fost raportata in sistem pentru decontare

5.3 Serviciul pentru consultarea retetelor electronice

Acest serviciu este folosit pentru a permite medicilor si farmaciilor să consulte retetele electronice prescrise sa eliberate pentru verificarea datelor transferate în sistemul centaral sau pentru a elibera medicamentele prescrise de medic către pacient, verificând în acelasi timp autenticitatea retetei respective.

Consultarea sistemului este obligatorie înainte de eliberarea medicamentelor pentru ca

farmacistul să se asigure că reteta este valabilă si este înregistrată în sitemul central, iar medicamentele prescrise nu au fost deja eliberate integral sau partial de altă farmacie.

Metoda getPrescribedPrescription (providerCode, physicianStencilNo, contractNo, contractType, insuranceHouseCode, series, no, prescriptionDate )

Metoda are opt parametri de intrare:

– parametrul providerCode de tip sir de caractere reprezintă codul unic de identificare al furnizorului în sistem, CUI (cod fiscal) sau CNP, după caz;

– parametrul physicianStencilNo de tip sir de caractere reprezintă numărul de parafă al medicului emitent;

– parametrul contractNo de tip sir de caractere reprezintă numărul contractului dintre furnizor si Casa de Asigurări;

– parametrul contractType de tip sir de caractere reprezintă codul tipului de contract (acest parametru este optional); parametrul insuranceHouseCode de tip sir de caractere reprezintă codul casei de asigurări cu care furnizorul are contract, valoare din nomenclatorul de case de

asigurări;

– parametrul series de tip sir de caractere reprezintă seria retetei;

– parametrul no de tip sir de caractere reprezintă numărul retetei;

– parametrul prescriptionDate de tip dată calendaristică reprezintă data la care reteta a fost prescrisă de medic.

Metoda întoarce sir de caractere reprezentând fisierul de răspuns în format XML, care se validează cu schema PhysicianDrugPEResponse.xsd

Fisierul de răspuns respectă schema de validare PhysicianDrugPEResponse.xsd, având aceeasi structură ca fisierul de răspuns primit de medic la cererea de validare a unei retete prescrise, deoarece contine practic acelasi set de informatii transmise de către sistem medicului pentru validare, bineînteles, cu conditia ce reteta prescrisă de către medic să fi fost validată cu succes si în starea emisă (tipărită).

Această metodă permite aplicatiei sa preia automat continutul retetelor electronice în format electronic din sistemul central. Astfel o farmacie poate descărca o retetă prescrisă de un medic în scopul de a elibera medicamentele corespunzătoare.

Metoda getReleasedPrescription (providerCode, workplaceCode, insuranceHouseCode, series, no, fractionNo )

Metoda are sase parametri de intrare:

– parametrul providerCode de tip sir de caractere reprezintă codul unic de identificare al furnizorului în sistem, CUI (cod fiscal) sau CNP, după caz;

– parametrul workplaceCode de tip sir de caractere reprezintă codul punctului de lucru care a raportat reteta (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 sir de caractere reprezintă codul casei de asigurări cu care furnizorul are contract, valoare din nomenclatorul de case de asigurări;

– parametrul series de tip sir de caractere reprezintă seria retetei;

– parametrul no de tip sir de caractere reprezintă numărul retetei;

– parametrul fractionNo de tip număr întreg reprezintă numărul de ordine al fractiei, în cazul retetelor eliberate fractionat farmacia/punctul de lucru (pentru o eliberare integrală acest parametru va avea valoarea 1).

Metoda întoarce sir de caractere reprezentând fisierul de răspuns în format XML, care se validează cu schema PharmacyDrugsPEResponse.xsd.

Fisierul de răspuns respectă schema de validare PharmacyDrugsPEResponse.xsd, având aceeasi structură ca fisierul de răspuns primit de farmacie la cererea de validare a unei retete eliberate, deoarece setul de informaii transmise din sistem este practic acelasi, bineînteles, cu conditia ce reteta eliberată de către farmacie să fi fost validată cu succes si în starea finalizată (tipărită).

Această metodă permite aplicatiei sa descarce o retetă transmisă anterior în sistem, dar pentru care nu a putut prelua din motive tehnice rezultatul validării.

Metoda getStatusForPrescriptions (insuranceHouseCode, providerCode, contractNo, contractType, startFrom, endTo, workPlaceCode )

Metoda are sapte parametri de intrare, fiind destinată în exclusivitate farmaciilor:

– parametrul insuranceHouseCode de tip sir de caractere reprezintă codul casei de asigurări cu care furnizorul are contract, valoare din nomenclatorul de case de asigurări;

– parametrul providerCode de tip sir de caractere reprezintă codul unic de identificare al furnizorului în sistem, CUI (cod fiscal) sau CNP, după caz;

parametrul contractNo de tip sir de caractere reprezintă numărul contractului dintre furnizor si Casa de Asigurări;

– parametrul contractType de tip sir de caractere reprezintă codul tipului de contract (acest parametru este optional);

– parametrul startFrom de tip dată calendaristică reprezintă data de început a intervalului în care se caută retetele în sistem;

– parametrul endTo de tip dată calendaristică reprezintă data de sfârsit a intervalului în care se caută retetele în sistem;

– parametrul workplaceCode de tip sir de caractere reprezintă codul punctului de lucru care a raportat reteta (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 sir de caractere reprezentând fisierul de răspuns în format XML, care se validează cu schema ImportPrescriptionStatusResponse.xsd.

Fisierul de răspuns este conform structurii definită de schema de validare ImportPrescriptionStatusResponse.xsd, si contine informatii despre datele de facturare, numărul de referintă sau stări asociate (finalizată, transmisă în SIUI, eliberare partială/integrală) pentru retetele transmise în sistem de către farmacie pentru perioada de interogare specificată, identificate unic prin serie si număr.

Această metodă permite aplicatiei să implementeze functionalităti de preluare automată a informatiilor despre starea retetele transmise în sistemul central SIPE întru-un anumit interval. Aceste informatii pot fi utilizate pentru verificarea acuratetii datelor transmise si, eventual, pentru retransmiterea corectă a acestora, pregătind astfel datele pentru a înlesni procesul de raportare în vederea decontării în SIUI.

Pentru consultarea unei retete prescrise aplicatia apelează metoda getPrescribedPrescription, respectiv metoda getReleasedPrescription, cu parametrii corespunzători cum au fost definiti anterior. Sistemul central validează cererea si întoarce un sir de caractere ca răspuns, pe care aplicatia îl salvează într-un fisier XML. Se validează fisierul XML cu schema de validare XSD corespunzătoare si dacă fisierul este valid atunci se procesează fisierul si se afisează reteta electronică altfel se afisează mesaj de eroare cu fisierul este corupt. Daca nu se primeste un sir de caractere (Byte Array), atunci se afisează un mesaj de eroare de comunicatie sau mesajul de eroare transmis de sistemul central.

5.5 Testare functii

Metodele apelate si pasii pentru o reteta electronica sunt urmatorii:

– utilizatorul medic adaugă o retetă în baza de date;

– aplicatia medicului generează fisierul cerere în format XML continând informatiile referitoare la retetă si medicamentele prescrise;

– se validează fisierul XML cu schema de validare XSD corespunzătoare;

– utilizand semnătură electronică extinsă (certificat digital calificat), medicul semnează electronic fisierul XML, folosind standardul CMS (RFC5652);

– se codifică rezultatul folosind codarea Base64;

– se apelează metoda processPrescribedPrescription trimitând continutul fisierului generat;

– sirul de caractere obtinut ca raspuns se salveaza intr-un fisier XML;

– se validează fisierul XML cu schema de validare XSD corespunzătoare;

– se procesează fisierul XML si se afisează un mesaj corespunzător rezultatului validării;

– se printeaza reteta cu codul de bare 2D aferent;

– utilizatorul farmacist adaugă o retetă în baza de date, prin scanarea codului de bare 2D sau prin completare manuală;

– se apeleaza getReleasedPrescription pentru a vedea daca reteta este deja validata sau nu in sistem;

– se apeleaza getPrescribedPrescription pentru a prelua datele incarcate de medic in sistem;

– se compara informatiile din codul de bare cu cele din sistem pentru a nu exista discordante;

– utilizatorul farmacist completeaza eliberarea;

– aplicatia generează fisierul cerere în format XML continând informatiile referitoare la retetă, pacient si medicamentele eliberate;

– se validează fisierul XML cu schema de validare XSD corespunzătoare;

– se apeleaza metoda processIssuedPrescription pentru validarea retetei in sistem;

– la final de luna se face raportarea retetelor in vederea decontarii;

– dupa raportare se apealeaza getStatusForPrescriptions pentru a verifica statusul retetelor, daca au fost acceptate in sistem si vor fi decontate.

Fluxul metodelor este prezentat in Figura 17.

BIBLIOGRAFIE

1. SPEC – http://siui.casan.ro/cnas/siui_3.7/specificatii

2. Liviu Adrian Stoica – Transaction flow analysis in IT application in the store, Proceedings of the 12th International Conference on Informatics in Economy- IE2013, Ed. ASE, Bucharest, 2013, pages 414-420, ISSN 2284-7472, ISSN-L 2247-1480

3. Liviu Adrian Stoica – Security in IT Application in the Store, Economy Informatics, vol. 13, no. 1, Ed. ASE, Bucharest, 2013, pages 91-104, ISSN 1582-7941, EISSN 2247-8523

ANEXA 1 – ACRONIME

ANEXA 2. Cod Autentificare

Imports System.Net

Imports System.Net.Security

Imports System.Net.Cache

Imports System.IO

Imports System.Security.Cryptography.X509Certificates

Imports System.Threading

Imports Connectivity.EPrescriptionWS

Public Class Conectare_SIPE

Implements IDisposable

Public zawpe As EPrescriptionWSService

Public Property wpe_service As EPrescriptionWSService

Get

Return zawpe

End Get

Set(ByVal value As EPrescriptionWSService)

zawpe = value

End Set

End Property

Public zastatus As Boolean

Private cale_eroare As String = cale_local + "cnas_eroare_tok.txt"

Private zausername As String

Private zauserpass As String

Private zaocsp As String

Private zalink As String

Private zausercert As X509Certificate2

Public readThread As Thread

Sub New(ByVal mzaocsp As String, ByVal mzalink As String, ByVal mzausername As String, ByVal mzauserpass As String, ByVal mzausercert As X509Certificate2)

zawpe = New EPrescriptionWSService

zastatus = True

zaocsp = mzaocsp

zalink = mzalink

zausercert = mzausercert

zausername = mzausername

zauserpass = mzauserpass

readThread = New Thread(AddressOf conectare_servicii)

readThread.IsBackground = True

readThread.Start()

End Sub

Public Sub conectare_servicii()

Try

Dim uri = New Uri(zaocsp + zausername)

Dim request = CType(WebRequest.Create(uri), HttpWebRequest)

Dim zacookiejar2 = New CookieContainer

request.ClientCertificates.Add(zausercert)

ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf ServerCertificateBypass)

ServicePointManager.SecurityProtocol = (SecurityProtocolType.Tls Or SecurityProtocolType.Ssl3)

ServicePointManager.Expect100Continue = False

request.CachePolicy = New RequestCachePolicy(RequestCacheLevel.NoCacheNoStore)

request.AllowAutoRedirect = False

request.KeepAlive = False

request.ProtocolVersion = HttpVersion.Version10

Dim proxy As WebProxy = WebProxy.GetDefaultProxy()

proxy.UseDefaultCredentials = True

request.Proxy = proxy

request.CookieContainer = zacookiejar2

Dim response As WebResponse = request.GetResponse()

conectare_sistem(zacookiejar2, response.Headers("OSCP_RESPONSE"))

Catch ex As Exception

File.AppendAllText(cale_eroare, "GET TOKEN " + zausername + " _ " + ex.ToString)

zastatus = False

End Try

End Sub

Private Function ServerCertificateBypass(ByVal sender As Object, ByVal certificate As X509Certificate2, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean

Return True

End Function

Public Sub conectare_sistem(ByVal zacookiejar As CookieContainer, ByVal zausertoken As String)

Try

Dim zauri As New Uri(zalink)

Dim zacredentials As New CredentialCache

zacredentials.Add(zauri, "Basic", New NetworkCredential(zausername, zauserpass))

zacredentials.Add(zauri, "Digest", New NetworkCredential(zausername, zauserpass))

zawpe.Url = zalink

zawpe.Credentials = zacredentials

zawpe.CookieContainer = zacookiejar

zawpe.ClientCertificates.Add(zausercert)

zawpe.Timeout = 300000

Dim zarequest As HttpWebRequest

zarequest = DirectCast(WebRequest.Create(zalink), HttpWebRequest)

ServicePointManager.Expect100Continue = False

zarequest.Accept = "*/*"

zarequest.KeepAlive = False

zarequest.AllowAutoRedirect = False

zarequest.PreAuthenticate = True

zarequest.ProtocolVersion = HttpVersion.Version10

zarequest.Timeout = 900000

zarequest.ReadWriteTimeout = 7200000

zarequest.ClientCertificates.Add(zausercert)

zarequest.Credentials = zacredentials

zarequest.CachePolicy = New RequestCachePolicy(RequestCacheLevel.NoCacheNoStore)

zarequest.Proxy = WebRequest.GetSystemWebProxy

zarequest.CookieContainer = zacookiejar

zarequest.Headers.Add("OSCP_RESPONSE", zausertoken)

Dim stream As Stream

stream = zarequest.GetResponse.GetResponseStream

stream.Dispose()

Catch ex As Exception

File.AppendAllText(cale_eroare, "CONECTARE " + zausername + " : " + ex.Message.ToString)

zastatus = False

End Try

End Sub

End Class

BIBLIOGRAFIE

1. SPEC – http://siui.casan.ro/cnas/siui_3.7/specificatii

2. Liviu Adrian Stoica – Transaction flow analysis in IT application in the store, Proceedings of the 12th International Conference on Informatics in Economy- IE2013, Ed. ASE, Bucharest, 2013, pages 414-420, ISSN 2284-7472, ISSN-L 2247-1480

3. Liviu Adrian Stoica – Security in IT Application in the Store, Economy Informatics, vol. 13, no. 1, Ed. ASE, Bucharest, 2013, pages 91-104, ISSN 1582-7941, EISSN 2247-8523

ANEXA 1 – ACRONIME

ANEXA 2. Cod Autentificare

Imports System.Net

Imports System.Net.Security

Imports System.Net.Cache

Imports System.IO

Imports System.Security.Cryptography.X509Certificates

Imports System.Threading

Imports Connectivity.EPrescriptionWS

Public Class Conectare_SIPE

Implements IDisposable

Public zawpe As EPrescriptionWSService

Public Property wpe_service As EPrescriptionWSService

Get

Return zawpe

End Get

Set(ByVal value As EPrescriptionWSService)

zawpe = value

End Set

End Property

Public zastatus As Boolean

Private cale_eroare As String = cale_local + "cnas_eroare_tok.txt"

Private zausername As String

Private zauserpass As String

Private zaocsp As String

Private zalink As String

Private zausercert As X509Certificate2

Public readThread As Thread

Sub New(ByVal mzaocsp As String, ByVal mzalink As String, ByVal mzausername As String, ByVal mzauserpass As String, ByVal mzausercert As X509Certificate2)

zawpe = New EPrescriptionWSService

zastatus = True

zaocsp = mzaocsp

zalink = mzalink

zausercert = mzausercert

zausername = mzausername

zauserpass = mzauserpass

readThread = New Thread(AddressOf conectare_servicii)

readThread.IsBackground = True

readThread.Start()

End Sub

Public Sub conectare_servicii()

Try

Dim uri = New Uri(zaocsp + zausername)

Dim request = CType(WebRequest.Create(uri), HttpWebRequest)

Dim zacookiejar2 = New CookieContainer

request.ClientCertificates.Add(zausercert)

ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf ServerCertificateBypass)

ServicePointManager.SecurityProtocol = (SecurityProtocolType.Tls Or SecurityProtocolType.Ssl3)

ServicePointManager.Expect100Continue = False

request.CachePolicy = New RequestCachePolicy(RequestCacheLevel.NoCacheNoStore)

request.AllowAutoRedirect = False

request.KeepAlive = False

request.ProtocolVersion = HttpVersion.Version10

Dim proxy As WebProxy = WebProxy.GetDefaultProxy()

proxy.UseDefaultCredentials = True

request.Proxy = proxy

request.CookieContainer = zacookiejar2

Dim response As WebResponse = request.GetResponse()

conectare_sistem(zacookiejar2, response.Headers("OSCP_RESPONSE"))

Catch ex As Exception

File.AppendAllText(cale_eroare, "GET TOKEN " + zausername + " _ " + ex.ToString)

zastatus = False

End Try

End Sub

Private Function ServerCertificateBypass(ByVal sender As Object, ByVal certificate As X509Certificate2, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean

Return True

End Function

Public Sub conectare_sistem(ByVal zacookiejar As CookieContainer, ByVal zausertoken As String)

Try

Dim zauri As New Uri(zalink)

Dim zacredentials As New CredentialCache

zacredentials.Add(zauri, "Basic", New NetworkCredential(zausername, zauserpass))

zacredentials.Add(zauri, "Digest", New NetworkCredential(zausername, zauserpass))

zawpe.Url = zalink

zawpe.Credentials = zacredentials

zawpe.CookieContainer = zacookiejar

zawpe.ClientCertificates.Add(zausercert)

zawpe.Timeout = 300000

Dim zarequest As HttpWebRequest

zarequest = DirectCast(WebRequest.Create(zalink), HttpWebRequest)

ServicePointManager.Expect100Continue = False

zarequest.Accept = "*/*"

zarequest.KeepAlive = False

zarequest.AllowAutoRedirect = False

zarequest.PreAuthenticate = True

zarequest.ProtocolVersion = HttpVersion.Version10

zarequest.Timeout = 900000

zarequest.ReadWriteTimeout = 7200000

zarequest.ClientCertificates.Add(zausercert)

zarequest.Credentials = zacredentials

zarequest.CachePolicy = New RequestCachePolicy(RequestCacheLevel.NoCacheNoStore)

zarequest.Proxy = WebRequest.GetSystemWebProxy

zarequest.CookieContainer = zacookiejar

zarequest.Headers.Add("OSCP_RESPONSE", zausertoken)

Dim stream As Stream

stream = zarequest.GetResponse.GetResponseStream

stream.Dispose()

Catch ex As Exception

File.AppendAllText(cale_eroare, "CONECTARE " + zausername + " : " + ex.Message.ToString)

zastatus = False

End Try

End Sub

End Class