Specificatie Interfatare DES - Aplicatii de Raportare Pentru Furnizori

CASA NAIONAL DE ASIGURRI DE SNTATE DIN ROMNIA
SISTEMUL INFORMATIC INTEGRAT

SISTEMUL NAIONAL DOSARUL ELECTRONIC DE SNTATE (DES)
Specificaii de interfaare cu DES pentru aplicaiile de raportare ale

furnizorilor de servicii medicale
Casa Naional de Asigurri de Sntate din Romnia
Specificaii de interfaare cu DES pentru aplicaiile de raportare
ale furnizorilor de servicii medicale
ISTORICUL REVIZIILOR DOCUMENTULUI
Versiune Data Comentarii
1.0 (PROIECT) 25.10.2013 Versiune iniial propus
1.0 (FINAL) 31.03.2014 Versiune final actualizat (export nomenclatoare, adrese publice)
Versiune: 1.0 din 31.03.2014 Pagina 2 din 42

CUPRINS
1. INTRODUCERE .............................................................................................................................................................. 6
2. PREZENTARE GENERAL DES ....................................................................................................................................... 7
2.1. Descrierea Sistemului Informatic Integrat pentru Dosarul Electronic De Sntate .................................... 7
2.2. DMR - Date medicale relevante ....................................................................................................................... 7
2.2.1. Datele de identificare ale pacientului ....................................................................................................... 8
2.2.2. Sumar i urgen ....................................................................................................................................... 8
2.2.3. Istoricul antecedentelor medicale ............................................................................................................ 8
2.2.4. Istoricul documentelor medicale .............................................................................................................. 9
2.2.5. Istoricul medical al pacientului ................................................................................................................. 9
2.2.6. DMR i standardul HL7-CDA ................................................................................................................... 10
3. STANDARDUL HL7-CDA ............................................................................................................................................ 11
3.1. Ce este HL7? ................................................................................................................................................... 11
3.2. Ce este un sistem EHR? ................................................................................................................................. 12
3.3. HL7-RIM Modelul Informaional de Referin ............................................................................................ 12
3.3.1. Specificaia HL7-RIM ............................................................................................................................... 13
3.3.2. Modelul abstract HL7-RIM ...................................................................................................................... 13
3.4. HL7-CDA Arhitectura Documentului Clinic ................................................................................................ 14
3.4.1. Structura documentului CDA .................................................................................................................. 15
3.4.2. Extensibilitatea i adaptarea standardului HL7-CDA ............................................................................ 16
3.4.3. Conformitatea cu standardul HL7-CDA .................................................................................................. 17
3.4.4. Afiarea documentelor HL7-CDA............................................................................................................ 17
3.5. Elementele de baz ale documentului CDA .................................................................................................. 18
3.5.1. Antetul documentului CDA ...................................................................................................................... 18
3.5.2. Corpul documentului CDA ....................................................................................................................... 21
3.5.3. Seciunile documentului CDA.................................................................................................................. 21
3.5.4. nregistrri structurate n CDA ............................................................................................................... 22
3.6. Contextul unui document CDA ....................................................................................................................... 23
4. DESCRIEREA SERVICIILOR WEB EXPUSE ........................................................................................................................ 25
4.1. Autorizarea accesului furnizorului de servicii medicale la DES ................................................................. 26
4.1.1. Autentificarea aplicaiei client................................................................................................................. 26
4.2. Serviciul pentru administrarea dosarului electronic de sntate ............................................................... 27
4.2.1. Metoda i n it ia l iz e Me dic a l F il eS iniializare dosar electronic de sntate.................................... 27
4.3. Serviciul pentru transmiterea documentelor medicale ctre DES ............................................................. 28
4.3.1. Metoda s to r eC l i nic a l Do c u me n t transmitere document medical................................................ 28
4.3.2. Metoda removeDocumentSetS t er ge re d oc u men t m ed ic a l ..................................................... 29
4.4. Serviciul pentru consultarea documentelor medicale din DES ................................................................... 30
4.4.1. Metoda g e t Cl i ni c a l Do c u me n t S preluare document medical ...................................................... 30
4.4.2. Metoda g e tP hy si c ia n Cl i n ic a l Do c u me n t s list documente proprii medic .................................. 30
4.4.3. Metoda g e t Me dic a l F il e Ol de rDo c um e n ts list documente vechi pacient ................................. 31
4.4.4. Metoda g e tR el e va n tR eff e ra l s list bilete de trimitere relevante................................................ 32
4.5. Serviciul pentru consultarea datelor medicale relevante din DES .............................................................. 32
4.5.1. Metoda g e t Co nso l id a t edP a t ie n t Id e n ti t y S consultare date identificare pacient ...................... 32
4.5.2. Metoda g e t Co nso l id a t ed S u m ma r y S consultare sumar de urgen ........................................... 33
4.5.3. Metoda g e t Co nso l id a t ed M ed ic a l H is to r y S consultare istoric medical ..................................... 33
4.5.4. Metoda g e t Co nso l id a t ed E ve n t sH is to r yS consultare documente medicale ............................. 34
4.5.5. Metoda g e t Co nso l id a t ed A n tec ed e n ts S consultare antecedente medicale .............................. 34

4.6. Serviciul pentru consultarea matricii de securitate din DES ....................................................................... 35

4.6.1. Metoda s u gg es t Ma t ri xC o o r di na t es sugerare coordonate matrice ............................................ 35
4.7. Serviciul pentru sincronizarea nomeclatoarelor din DES ............................................................................ 35
4.7.1. Metoda e xp o r t S ys t e m Co de s Su m ma ry ex p ort list nomenclatoare ........................................ 35
4.7.2. Metoda e xp o r t Co de S ys t em ex po rt v a l o ri nomenclator ........................................................... 36
5. EXEMPLE DE COD .NET PENTRU INTEGRAREA CU DES ................................................................................................... 37
5.1. Transmitere document medical CDA ctre DES ........................................................................................... 37
5.2. Consultare date medicale relevante din DES ............................................................................................... 38
5.3. Consultare documente medicale emise de medic existente n DES ........................................................... 38
5.4. Preluare nomenclatoare (sisteme de clasificare) n DES .............................................................................. 39
5.5. Clas utilitar pentru autorizarea aplicaiei de raportare ........................................................................... 39
5.6. Clas utilitar pentru co-autentificarea pacientului .................................................................................... 40
5.7. Clas utilitar pentru realizarea semnturii digitale ................................................................................... 41
6. EXEMPLE DE DOCUMENTE MEDICALE CDA PENTRU MF.................................................................................................. 42
6.1. DES_CDA_PCEXAM.xml ................................................................................................................................. 42
6.2. DES_CDA_CLNREF.xml ................................................................................................................................. 42
6.3. DES_CDA_LABREF.xml .................................................................................................................................. 42
6.4. DES_CDA_EPRESC.xml .................................................................................................................................. 42

TABELA DE FIGURI
FIGURA 1 - STRUCTURA DOCUMENTULUI CLINIC ................................................................................................................ 15

1. INTRODUCERE
Acest document descrie din punct de vedere tehnic modalitile de interfaare cu Sistemului
Informatic Integrat pentru Dosarul Electronic de Sntate al Casei Naionale de Asigurri de
Sntate.
Sistemului Informatic Integrat pentru Dosarul Electronic De Sntate (DES) asigur colectarea,
consolidarea i procesarea datelor medicale relevante din ntregul sistem de asigurri sociale
de sntate din Romnia. n acest scop DES prevede o serie de interfee pentru interconectarea
cu aplicaiile medicale ale furnizorilor de servicii medicale care interacioneaz 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 integrrii la nivel
aplicativ i al schimbului electronic de date cu DES pentru transmiterea i consultarea
informaiilor medicale relevante.
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. Acest document este o completare a Specificaiilor de
interfaare cu SIUI+SIPE+CEAS - pentru productorii de aplicaii software, a cror parcurgere
este necesar pentru a nelege contextul sistemului informatic DES.

2. PREZENTARE GENERAL DES
n acest capitol sunt prezentate pe scurt principalele caracteristici ale Sistemului Informatic
Integrat pentru Dosarul Electronic de Sntate.
2.1. DESCRIEREA SISTEMULUI INFORMATIC INTEGRAT PENTRU DOSARUL

ELECTRONIC DE SNTATE
Sistemul Informatic Integrat Sistemul National Dosarul Electronic de Sntate (DES)
reprezint dezvoltarea i implementarea unei aplicatii online, n cadrul creia furnizorii de
servicii medicale vor introduce datele medicale relevante, rezultate n urma procedurilor de
diagnosticare si tratament si vor putea extrage ntregul istoric medical al pacientului utiliznd
aceste informatii ca date de intrare pentru procedurile de diagnosticare, tratament si
monitorizare a strii de sntate a pacientului. Aplicatia va functiona cu o interfata web, fiind
accesibil tuturor actorilor implicati (pacient, medic, etc.) cu ajutorul unei conexiuni Internet,
prin intermediul portalului sau prin intermediul sistemelor IT din cadrul spitalelor, respectiv
aplicatiile specializate pentru medicii de familie.
Sistemul Informatic Integrat Sistemul National Dosarul Electronic de Sntate (DES)
realizeaz o solutie informatic complet si integrat cu sistemele informatice deja existente n
CNAS, numite generic Platforma Informatic a Asigurrilor de Sntate (PIAS) reprezentat
prin sistemele Sistemul Informatic Unic si Integrat (SIUI), Sistemul Informatic Prescriptia
Electronic (SIPE) i Cardul Electronic de Asigurari de Sntate (CEAS), destinate n principal
creterii calittii sistemului de sntate din Romania, construirii tabloului clinic complet si
consistent al pacientului ca suport decizional n diagnosticarea lui si ca suport n stabilirea si
adoptarea politicilor de sntate n Romnia. De asemenea DES va reprezenta un pas important
n creterea interoperabilitii furnizorilor de servicii medicale, prin asigurarea unei platforme
naionale care facilitez schimbul de informaii medicale relevante i transferul de documente
medicale ntre diverse instituii care asigur ngrijirea medical a asigurailor.
Sistemul informatic DES utilizeaz standardul internaional HL7 (Health Level Seven), cel mai
rspndit n momentul de fa pentru schimbul de informaii medicale. Acest document conine
cerinele software aplicabile sistemului DES, cu privire la modalitile de formatare i
codificare a informaiilor electronice transmise ntre DES i aplicaiile informatice ale
furnizorilor de servicii medicale. Aceste cerine sunt specificate utiliznd standardul
internaional HL7, i n mod special specificaia CDA R2 (Clinical Document Architecture /
Arhitectura Documentului Clinic).
2.2. DMR - DATE MEDICALE RELEVANTE

Prin date medicale relevante nelegem, n sensul acceptat de proiectul DES, organizarea
datelor despre pacient, colectate n cadrul sistemului DES, pe criteriul relevanei medicale
astfel nct acestea s poat fi utilizate ct mai eficient n cadrul actului medical. Relevana
datelor medicale a fost stabilit de CNAS cu sprijinul unei comisii de experi n domeniu.

Organizarea datelor n funcie de relevana medical, aduce n prim plan date de tip sumar, pe
care medicul trebuie sa le vad imediat. Pornind de la acest sumar de maxim relevan,
medicul va putea accesa date din ce n ce mai detaliate ajungnd pn la a consulta efectiv
forma electronica a documentului medical care sta la baza acestora.
2.2.1. Datele de identificare ale pacientului

n aceast seciune vor fi grupare datele de identificare ale pacientului. La aceste date vor avea
acces toi medicii, indiferent de drepturile de vizualizare setate n prealabil de ctre pacient.
n cadrul sumarului DES vor fi afiate utilizatorilor date cu privire la:
Grupa sanguin
Informaii deces
Informatii asigurare medical
Stratificarea pe seciuni a datelor de identificare ale pacientului este prezentat n Ghidul de

implementare date medicale relevante.
2.2.2. Sumar i urgen
Sumarul DES reprezint acele date medicale cu cea mai mare relevan. Acestea se vor afia
cu prioritate fa de alte date. Informaiile din sumarul de urgen se pot regsi i n alte
seciuni.
n cadrul sumarului DES vor fi afiate utilizatorilor date cu privire la:
Grupa sanguin
Informaii pentru situaii de urgen
Informatii furnizate de pacient
La datele din seciunea Sumar i urgen vor avea acces, n situaii de urgen, toi medicii
indiferent de drepturile de vizualizare setate n prealabil de ctre pacient.
Stratificarea pe seciuni a sumarului DES este prezentat n Ghidul de implementare date
medicale relevante.
2.2.3. Istoricul antecedentelor medicale

Istoricul antecedentelor medicale ale pacientului reprezint informaii relevante despre modul
de via, precum i enumerarea antecedentelor personale fiziologice, patologice sau heredo-
colaterale, care au afectat starea de sntate a pacientului.
n cadrul seciunii de antecedente medicale al pacientului vor fi afiate utilizatorilor date cu
privire la:
Mod de via
Antecedente personale fiziologice (adult-femei sau copii, dup caz)
Antecedente heredo-colaterale
Antecedente personale patologice
La datele din seciunea Istoricul antecedentelor medicale vor avea acces doar medicii pentru
care pacientul acord drepturile de vizualizare, drepturi care pof fi setate n prealabil de ctre
pacient sau pot fi acordate pe loc pe baza cardului electronic de asigurat sau pe baza matricii
de securitate, ca metod alternativ.

Stratificarea pe seciuni a istoricului antecedentelor medicale este prezentat n Ghidul de

2.2.4. Istoricul documentelor medicale

Istoricul documentelor medicale ale pacientului reprezint enumerarea documentelor
medicale raportate de furnizorii de servicii medicale n trecutul apropiat (6 luni).
Documentele medicale istorice mai vechi de 6 luni nu sunt incluse n DMR, pentru ele fiind
expuse metode dedicate de acces.
n cadrul seciunii de documente medicale al pacientului vor fi afiate utilizatorilor date cu
privire la:
Istoric internari
Istoric consultatii la MF
Istoric consultatii de specialitate
Istoric trimiteri
Istoric retete
La datele din seciunea Istoricul documentelor medicale vor avea acces doar medicii pentru
care pacientul acord drepturile de vizualizare, drepturi care pof fi setate n prealabil de ctre
Stratificarea pe seciuni a istoricului documentelor medicale este prezentat n Ghidul de
2.2.5. Istoricul medical al pacientului

Istoricul medical al pacientului reprezint acele date medicale care prezint importan din
punct de vedere medical, oferind o vedere de ansamblu asupra strii de sntate a pacientului
prin enumerarea evenimentelor medicale care au afectat starea de sntate a pacientului.
n cadrul seciunii de istoric medical al pacientului vor fi afiate utilizatorilor date cu privire la:
Istoric boli i diagnistice
Boli cronice
Istoric alergii
Istoric imunizri
Intervenii i proceduri efectuate
Servicii clinice, paraclinice i spitaliceti
Tratamente n cadrul studiilor clinice
La datele din seciunea Istoricul medical al pacientului vor avea acces doar medicii pentru care
pacientul acord drepturile de vizualizare, drepturi care pof fi setate n prealabil de ctre
Stratificarea pe seciuni a istoricului medical al pacientului este prezentat n Ghidul de

2.2.6. DMR i standardul HL7-CDA
Aplicarea standardului HL7-CDA (Arhitectura Documentului Clinic) pentru formatarea i

codificarea documentelor medicale electronice transmise n cadrul sistemului DES, ntre
sistemul central i aplicaiile furnizorilor de servicii medicale se va implementa conform
recomandrilor de implementare ale organizaiei HL7 descrise n capitolul anterior.
Documentele electronice vor fi formatate utiliznd standardul W3C-XML, la care se aplic
schema de validare HL7-CDA Release 2 definit conform standardului HL7v3-RIM (Modelul
Informaional de Referin).
Toate documentele CDA transferate ctre DES vor conine un antet, conform cu recomandrile
HL7, care cuprinde informaiile de identificare ale participanilor la actul medical, i aici ne
referim n mod special la pacient (asigurat), la medic i la furnizorul de servicii medicale.
Datele medicale vor fi structurate n seciuni grupate logic, conform cu recomandrile HL7,
care vor conine informaii completate de operatori i autentificate de ctre medici.
Specificarea fiecrui tip de document medical, precum i stratificarea i structura seciunilor
componente ale acestora, este prezentat n Ghidul de implementare documente medicale
electronice
Sistemul DES va consolida aceste informaii referitoare la pacieni pe baza unor criterii
medicale stabilite de experi i va constitui o serie de documente supuse aceluiai standard
HL7-CDA. Aceste documente vor fi grupate conform criteriilor definite n seciunile anterioare.

3. STANDARDUL HL7-CDA
n acest capitol sunt prezentate cteva aspecte importante legate de standardul HL7 i modul
n care acesta afecteaz proiectarea sistemului informatic al DES, n mod special zona de
interaciune cu aplicaiile medicale externe de la nivelul spitalelor i medicilor de familie, iar n
legtur cu aceasta, vom prezenta HL7-CDA Arhitectura Documentului Clinic.
3.1. CE ESTE HL7?

Health Level Seven International (HL7) este o organizaie non-profit care are ca obiect de
activitate dezvoltarea de standarde dedicate pentru a oferi un cadru de lucru cuprinztor i
acoperitor pentru schimbul, integrarea, partajarea i regsirea informaiilor medicale
electronice care sprijin activitile de practic i administrare medical, dar i cele de
prestarea i evaluare a serviciilor medicale.
HL7 ofer standarde de interoperabilitate care creeaz premizele pentru mbuntirea calitii
serviciilor medicale oferite, pentru optimizarea fluxurilor de documente i de informaii i
pentru consolidarea transferului de cunotine ntre participanii la actul medical, incluznd
furnizori de servicii medicale, agenii guvernamentale, comunitatea productorilor de
medicamente i dispozitive medicale, precum i pacienii. Aceste standarde definesc modul n
care informaia este mpachetat i transferat de la un participant la altul, specificnd
limbajul, structura i tipurile de date necesare pentru o integrare facil ntre sistemele
informatice.
HL7 dezvolt, n acelai timp, standarde conceptuale (HL7-RIM), standarde de documente
(HL7-CDA), standarde de aplicaii (HHL7-CCOW), precum i standarde de mesaje (HL7 v2.x i
v3.0). Dintre acestea, standardele de mesaje sunt foarte importante datorit faptului c
definesc modul n care informaia este definit i comunicat ntre participani.
Exist dou versiuni majore ale standardelor de baz HL7, Versiunea 2 i Versiunea 3.
Versiunea 2 reprezint unul dintre cele mai rspndite standarde aplicate la nivel mondial. Cu
toate acestea, aderena la standardele Versiunii 2 nu implic interoperabilitatea direct ntre
sisteme. Acest lucru deriv din faptul c mesajele conforme Versiunii 2 nu au un mod precis de
definire a modelului informaional al datelor, definiiile multor cmpuri fiind destul de vagi i
existnd o multitudine de cmpuri opionale.
Pentru a rezolva aceste probleme a fost dezvoltat Versiunea 3 a standardelor HL7, care este
bazat pe un model informaional orientat pe obiecte, denumit Modelul Informaional de
Referin (RIM - Reference Information Model). Datorit acestor considerente i pentru a fi mai
bine pregtit pentru extinderi viitoare, sistemul informatic al DES va utiliza HL7 v3.
n continuare vom prezenta cteva concepte generale legate de sistemele EHR, iar apoi vom
detalia standardele HL7-RIM (Modelul Informaional de Referin) i HL7-CDA (Arhitectura
Documentului Clinic) care au aplicabilitate direct n cadrul DES.

3.2. CE ESTE UN SISTEM EHR?

Un sistem EHR/DES (Electronic Health Records/Dosarul Electronic de Sntate) este un
concept evolutiv, definit ca o colecie sistematic de informaii electronice medicale despre un
pacieni individuali sau despre populaii. Este o nregistrare n format digital care este teoretic
capabil de a fi partajat ntre diferite instituii care ofer servicii medicale.
Un sistem EHR/DES poate fi format dintr-un set de date care include date demografice,
istoricul medical, medicaia i alergiile, istoricul imunizrilor, rezultatele investigaiilor de
laborator, imagini radiologice, semne vitale i date personale precum vrsta sau greutatea, sau
chiar informaii de decontare a serviciilor.
Beneficiile pe care un sistem EHR/DES le poate aduce organizaiilor care ofer servicii
medicale care l implementeaz sunt:
Informaie clinic de calitate i accesibil Furnizorii de servicii medicale pot fi
informai cu uurin asupra istoricul medical al unei persoane, sau a familiei sale,
dar i asupra informaiilor de actualitate, cum ar fi rezultatele testelor, medicaia
curent sau cronic, sau alergii i efecte adverse, informaii care pot fi cruciale
pentru luarea unei decizii medicale informate.
Sigurana pacientului Informaia din fia medical electronic a pacientului devine
clar i lizibil, eliminnd problemele cauzate de citirea notelor scrise de mn.
Rapoartele i scrisorile medicale ctre ali specialiti devin astfel adecvate,
cuprinztoare i uor de creat din punct de vedere informatic.
ngrijire medical mbuntit Datorit faptului c furnizorii de servicii medicale
primesc alerte sau notificri asupra ghidurilor de bune practici, pacienii primesc
ngrijiri conform ultimelor standarde n mod consistent. Majoritatea sistemelor EHR
ofer protocoale de tratament i recomandri de teste care pot oferi informaii
adecvate medicului.
Eficien i costuri reduse O economie evident este eliminarea fielor de hrtie,
mpreun cu costurile de stocare i arhivare asociate cu acestea De asemenea,
sistemele EHR permit o comunicare mai rapid ntre participani, ceea ce reduce
timpul de acordare a ngrijirii medicale pentru un pacient, crescnd astfel eficiena
serviciilor.
3.3. HL7-RIM MODELUL INFORMAIONAL DE REFERIN

Standardul HL7-RIM (Modelul Informaional de Referin) este o component critic n procesul
de dezvoltare i particularizare a sistemelor bazate de HL7 v3, constituind rdcina comun a
tuturor modelelor i structurilor informaionale dezvoltate de organizaia HL7 ca parte a
Versiunii 3 de standarde.
HL7-RIM ofer o viziune static a nevoilor de informaii pentru celelalte standarde din familia
HL7 v3, incluznd diagrame de clase i de stri, acompaniate de scenarii (story-boards), modele
de interaciune, modele de tipuri de date, modele de terminologie i alte tipuri de modele
pentru a crea o viziune complet a cerinelor i construciei standardelor HL7. Clasele,
atributele, strile i relaiile din RIM sunt utilizate pentru a defini modele de informaii specifice
anumitor domenii, care sunt apoi transformate printr-un proces de rafinare i constrngere n
modele concrete de coninut informaional conform standardului HL7.

Procesul de dezvoltare a standardului HL7 v3 definete regulile ce guverneaz derivarea

modelelor informaionale din RIM i modalitile de rafinare a acestor model n specificaii HL7.
Aceste reguli cer ca toate structurile de informaii din modelele derivate s fie trasabile napoi
ctre RIM i ca regulile proprii de procesare i de structur s nu intre n conflict cu cele
impuse de RIM. Astfel RIM devine sursa de baz pentru coninut informaional n standardele
HL7 v3.
HL7-RIM este utilizat de organizaiile afiliate la HL7 pentru a extinde standardul n scopul de a
fi adaptat cerinelor locale i regionale, printr-un proces denumit localizare, care permite
detalierea specificaiei standard HL7 prin utilizarea RIM ca surs pentru coninutul
informaional adugat la standard. Orice coninut informaional trebuie definit n aceeai
manier utilizat de HL7 pentru a crea specificaiile originale.
3.3.1. Specificaia HL7-RIM
Specificaia HL7-RIM este exprimat utiliznd limbajul UML (Unified Modeling Language)
folosind adnotri specifice n modelul elementelor de meta-date. RIM utilizeaz un stil de
modelare foarte abstract, avnd la baz ase clase nucleu, mpreun cu specializrile (sub-
clasele) i atributele structurale care codific definiiile tipurilor derivate neincluse n
diagramele de structur ale RIM. Clasele constituente ale RIM sunt mprite n mai multe
pachete legate de anumite subiecte de interes, mpreun cu atributele, relaiile i strile
asociate.
Fiecare clas din RIM reprezint informaii despre un concept care trebuie documentat i
comunicat n mediul de lucru al furnizorilor de servicii medicale. Numele atribuite acestor
clase sunt preluate din limbajul normal de specialitate, dar utilizarea acestor nume capt
semnificaia dorit doar n cadrul spaiului de lucru (namespace) al RIM. Semnificaia acestor
clase este n ntregime ncorporat n definiia clasei i n definiiile proprietilor acesteia
(atribute sau asocieri).
RIM utilizeaz termeni specifici HL7, definii n Specificaia Vocabularelor HL7 v3, care este un
document distinct al standardului HL7. Un subset al acestei specificaii este inclus i n
specificaiilor normative ale RIM, n mod special fiecare atribut RIM care are asociat un cod de
tip de date, are definit ca o constrngere un Domeniu Conceptual, parte a RIM.
3.3.2. Modelul abstract HL7-RIM
HL7-RIM definete ase clase de baz (nucleu) care sunt utilizate pentru a exprima coninutul
clinic i administrativ al serviciilor de ngrijire medicale, i anume:
Act (Aciune/Act medical) care reprezint o aciune care este executat i care trebuie
documentat n legtur cu un serviciu de ngrijire medical acordat sau gestionat de
unitatea medical;
Participation (Participare) care exprim contextul unei aciuni relativ la cine a efectuat-
o, pentru cine a fost efectuat, unde a fost efectuat, etc.;
Entity (Entitate) care reprezint lucruri fizice sau fiine care prezint interes sau care
particip la actul de ngrijire medical;
Role (Rol) care stabilete rolurile pe care le ndeplinesc entitile n timp ce particip la
actul de ngrijire medical;

ActRelationship (ActRelaie) care reprezint legtura dintre dou acte medicale, cum ar
fi relaia dintre o trimitere la specialist i observaiile medicale ale acestuia, atunci cnd
acestea au loc;
RoleLink (RolLegtur) care reprezint relaii ntre anumite roluri n cadrul unui act
medical.
3.4. HL7-CDA ARHITECTURA DOCUMENTULUI CLINIC

HL7-CDA (Clinical Document Architecture / Arhitectura Documentului Clinic) este un standard
de marcaje pentru documente care specific structura i semantica documentelor clinice
pentru scopul schimbului de informaie ntre sisteme.
Un document clinic este o reprezentare a observaiilor i serviciilor clinice, care ndeplinete
urmtoarele caracteristici:
Persisten Un document clinic continu s existe ntr-o form nemodificat
pentru o perioad de timp definit de reglementrile locale. (NOT: Noiunea de
persisten a unui document clinic nu trebuie confundat cu cea de persisten a
unei instane oarecare a unui document CDA codificat XML).
Guvernare Un document clinic este ntreinut de o organizaie ncredinat cu
aceast responsabilitate.
Potenial pentru autentificare - Un document clinic este o asamblare de informaii
care poate fi autentificat din punct de vedere legal.
Context - Un document clinic stabilete un context implicit pentru propriul coninut.
Completitudine Autentificarea unui document clinic se aplic la ntreg documentul
i nu se aplic unor poriuni ale documentului n afara ntregului context al
documentului.
Lizibil pentru oameni Un document clinic trebuie s fie lizibil pentru oameni.
Un document CDA este o entitate de informaie definit i complet care poate include text,
imagini, sunete i alte tipuri de coninut multimedia. Documentele CDA trebuie s fie lizibile
pentru oameni i, n acelai timp, procesabile pentru maini n limita pn la care au fost
adugate marcaje.
Prezentm n continuare cteva aspecte cheie ale HL7-CDA:
Documentele CDA sunt codificate folosind XML (Extensible Markup Language).
Documentele CDA devin procesabile prin utilizarea noiunilor din HL7-RIM i a
vocabularelor i tipurilor de date definite de HL7 v3.
Specificaia CDA este bogat, expresiv i flexibil, coninnd abloane la nivel de
document, nivel i seciune care pot fi utilizate pentru a defini constrngeri speficice
fiecrui tip de document, extinznd astfel specificaia generic.
Exemple de documente CDA:

Fi de externare
Fi de consultaie
Trimitere

Prescripie medical
Raport de sntate public
3.4.1. Structura documentului CDA
Un document CDA este alctuit dintr-un antet (header) i un corp (body). Antetul identific
pacientul, furnizorul, tipul documentul, etc. Corpul conine o parte obligatorie care poate fi
citit de oameni (human-readable) i o parte opional codificat procesabil (machine-
procesable). La rndul lui corpul este compus din una sau mai multe seciuni (Sections), care
conin un bloc narativ (Narrative Block)i nregistrri opionale (Entries).
Partea lizibil pentru oameni (blocul narativ) trebuie obligatorie i conine informaia complet,
nefracionat, fie ca XML sau TEXT, fie ca un obiect binar (BLOB) codificat MIME (Multipurpose
Internet Mail Extensions), cum ar fi *.doc, *.pdf, *.tif.
Partea codificat pentru maini, dac este prezent, poate fi ignorat de destinatarii care nu au
capacitatea de a o procesa.
Imaginea urmtoare prezint un exemplu parial de document CDA formatat ca XML, pentru a
evidenia principalele elemente structurale.
Figura 1 - Structura documentului clinic

Pentru a sumariza, structura documentului CDA este urmtoarea:
[1..1] Antet (Header)
[1..1] Corp (Body)
[1..*] Seciuni (Sections)
[1..1] Bloc Narativ (Narrative Block)
[0..*] nregistrri (Entries)

Un document CDA este ncadrat de un element denumit <ClinicalDocument> care conine

antetul i corpul.
Nu exist un element anume care conine antetul, acesta fiind constituit de toate elementele
care apar n interiorul elementului <ClinicalDocument> i n afara elementelor <structuredBody>
sau <nonXMLBody>, dup caz. Antetul identific i clasific documentul i ofer informaii
despre autenticitate, pacient, incidentul documentat i despre furnizorii implicai.
Corpul conine raportul clinic i poate fi constituit fie dint-un obiect binar nestructurat, fie din
marcaje structurate. Exemplul de mai sus prezint un corp structurat, ncadrat de un element
<structuredBody>, care este divizat n elemente imbricate de tip seciune: <section>.
O seciune a documentului CDA este ncadrat de un element <section>, iar fiecare seciune
trebuie s conin un singur bloc narativ i poate conine oricte nregistrri i referine
externe. Blocul narativ CDA este ncadrat de un element <text> i trebuie s conin coninutul
lizibil pentru oameni a documentului care va fi afiat.
n cadrul unei seciuni a documentului, blocul narativ reprezint coninutul care trebuie afiat,
n timp ce nregistrrile reprezint coninut structurat utilizat pentru procesarea n aplicaii
informatice (de exemplu n aplicaii pentru suport decizional). nregistrrile CDA codific n mod
obinuit coninutul prezent n blocul narativ al aceleiai seciuni. n exemplu se prezint, printre
altele, dou nregistrri CDA de tip observaie: <observation> i o nregistrare de tip
administrare de substane: <substanceAdministration> care conine, la rndul ei o nregistrare
imbricat de tip <supply>.
nregistrrile CDA pot conine alte nregistrri la rndul lor, iar referinele externe pot aprea
doar n contextul unei nregistrri CDA. Referinele externe pot trimite ctre coninut care
exist n afara documentului CDA cum ar fi un fiier de tip imagine, sau o procedur sau
observaie dintr-un alt document CDA. O not important trebuie fcut n legtur cu
materiale referite extern, care nu sunt acoperite de autenticitatea documentului care le refer.
3.4.2. Extensibilitatea i adaptarea standardului HL7-CDA
Fiind derivat din RIM, standardul CDA este extensibil la rndul lui, n baza metodologiei stabilit
de RIM.
n cazul n care nu exist o reprezentare specific pentru un anumit concept local, atunci se pot
utiliza marcaje definite local. CDA urmrete standardizarea nivelului cel mai nalt al
semnificaiei unui concept, oferind n acelai timp un mecanism curat i standard pentru a
marca semnificaii care nu sunt partajate.
n scopul de a sprijini cerinele de extensibilitate local, este permis includerea unor elemente
i atribute XML adiionale care nu sunt definite n schema CDA oficial. Aceste extensii nu
trebuie s modifice semnificaiile niciunui concept definit de standard, ar destinatarii trebuie s
aib libertatea de a ignora n siguran noile elemente n procesri, i n acelai timp s poat
afia cu ncredere coninutul documentului CDA ignornd elementele de extensie.
Extensiile pot fi incluse ntr-o instan de document CDA ntr-un namespace, altul dect cel
oficial, i anume HL7v3, cu restricia c nu se pot include extensii n interiorul unor elemente de
tip ED (ex. element <text> ntr-un element <procedure>) deoarece coninutul uni tip de dat ED
ntr-un document conform poate fi dintr-un alt namespace. Astfel, deoarece tot coninutul
conform (n afara elementelor de tip ED) aparine namespace-ului HL7v3, emitentul poate
introduce orice coninut de extensie ntr-un namespace strin (altul dect HL7v3). Sistemele
care primesc i proceseaz aceste documente nu trebuie s raporteze erori dac ntlnesc
astfel de extensii.

3.4.3. Conformitatea cu standardul HL7-CDA
Un document CDA este considerat conform standardul HL7-CDA dac trece cu succes de
minim verificarea cu schema XSD definit de standard i dac restricioneaz utilizarea
codurilor la vocabularele domeniilor specificate. Cu toate acestea o aplicaie informatic nu
poate verifica toate aspectele conformitii cu standardul, n mod special cele privind cerinele
de lizibilitate pentru oameni a documentului CDA.
Un emitent de documente clinice este o aplicaie care creeaz un document CDA, fiind adeseori
responsabil de transferul acestuia ntr-o locaie de stocare persistent, dar i de asigurarea
conformitii depline a documentului generat cu specificaiile standardului.
Un destinatar de documente clinice este o aplicaie care primete documente i actualizri de
stare de la un emitent de documente sau de la un sistem de gestiune a documentelor.
Destinatarul este responsabil de asigurarea faptului c documentul primit este afiat n
concordan cu specificaia standardului.
Deoarece HL7-CDA este un standard de schimb de informaii, iar documentul poate fi
reprezentat ntr-o form care nu este identic cu a documentului original, nu sunt specificate
cerine de stocare persistent pentru documentele CDA. Cu toate acestea, cum s-a menionat
i mai sus, gestiunea documentelor este interdependent n mod critic de specificaia CDA.
Custodele documentului, n sens HL7 (custodian), identificat n antetul acestuia este
participantul nsrcinat cu ntreinerea documentul original, care poate fi ntr-o alt form
dect CDA.
3.4.4. Afiarea documentelor HL7-CDA
Standardul HL7-CDA garanteaz faptul c un destinatar al unui document CDA poate afia n
baza unui algoritm coninutul clinic narativ ntr-un web-browser standard.
HL7-CDA Release 2, prin amestecul de pri narative i nregistrri, prezint o serie de
provocri noi proiectanilor de sisteme conforme cu standardul. Printre acestea enumerm:
Pentru un destinatar trebuie s existe un mod determinist de afiare a coninutului
atestat al unui document CDA arbitrar.
Lizibilitatea pentru oameni nu trebuie s solicite emitentului s transmit o fi de stil

(style-sheet) special alturi de documentul CDA pentru a se afia extensiile. Trebuie s
fie posibil afiarea tuturor seciunilor narative ale documentului utiliznd foaia de stil
standard i unelte de afiare generale.
Lizibilitatea pentru oameni se aplic coninutului autentificat. Poate exista informaie

adiional inclus n document n principal pentru procesri ulterioare care nu este
autentificat, i deci nu este necesar a fi afiat.
Atunci cnd coninutul structurat este derivat din cel narativ, trebuie s existe un
mecanism de descriere a procesului (ex. de ctre autor, de ctre un programator, de
ctre un algoritm de procesare a limbajului natural, sau de ctre un software specific)
prin care poriunea procesabil a fost derivat din blocul narativ.
Atunci cnd coninutul narativ este derivat din cel structurat, trebuie s existe un
mecanism de identificarea a procesului prin care textul a fost generat din datele
structurate.

3.5. ELEMENTELE DE BAZ ALE DOCUMENTULUI CDA

Exemplul urmtor reprezint un extras parial dintr-un document CDA generic care evideniaz
elementele obligatorii de structur ale acestuia pentru a se constitui ca un document XML
valid, i anume:
- Declaraia XML, conform W3C
- Importul foii de stil CDA, definit de standard, folosit pentru afiarea lizibil n
browser
- Elementul XML rdcin <ClinicalDocument>, care ncadreaz coninutul
documentului CDA
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="CDA.xsl"?>
<ClinicalDocument
xmlns="urn:hl7-org:v3
xmlns:voc="urn:hl7-org:v3/voc
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">




</ClinicalDocument>
n exemplu sunt evideniate i dou poziii necompletate unde ar trebui s apar informaiile
legate de antetul (header) i corpul (body) documentului.
Din punct de vedere funcional, antetul identific i clasific documentul, coninnd informaii
despre episodul medical, despre pacient, despre furnizor, dar i legate de autentificarea
coninutului. La rndul su, corpul documentului conine raportul clinic, fiind divizat din punct
de vedere structural i conceptual n mai multe seciuni, fiecare coninnd un bloc narativ
pentru afiare lizibil, dar i o parte opional de informaie structurat sub form de
nregistrri sau referine externe ctre alte documente clinice.
+ Clinical Document
+ Header
+ Header Attributes
+ Header Participants
+ Header Relationships
+ Body
+ Body Choice
+ Section Attributes
+ Section Participants
+ Section Relationships
+ Section Narrative Block
+ Entry Acts
+ Entry Participants
+ Entry Relationships
3.5.1. Antetul documentului CDA
Scopul antetului documentului CDA este de a permite schimbul de informaie medical ntre
instituiile implicate n ngrijirea sntii unui pacient, facilitnd gestiunea documentelor
clinice i compilarea dosarului medical electronic al pacientului din mai multe surse.

Prezentm n continuare atributele i clasele de tip Participare i Relaie care pot aprea a
nivelul antetului documentului medical CDA.
Header Attributes (descrie atributele clasei rdcin ClinicalDocument)
ClinicalDocument.id reprezint identificatorul unic al instanei curente de

document clinic CDA.
ClinicalDocument.code specific tipul particular al documentului CDA curent (ex:

Observaie clinic, Fi de externare, Fi de consultaie). Valoare codului este
preluat din LOINC.
ClinicalDocument.title reprezint titlul documentului CDA.
ClinicalDocument.effectiveTime reprezint timpul de creare a documentul

original, reprezentat electronic de documentul CDA.
ClinicalDocument.confidentialityCode este o component contextual obligatorie,

unde valoarea exprimat la acest nivel (n antet) este valabil n ntreg
documentul, dac nu a fost suprascris.
ClinicalDocument.languageCode specific limba n care este scris documentul.
ClinicalDocument.setId reprezint un identificator comun valabil n toate

versiunile revizuite ale unui document.
Header Participants (descrie clasele legate de clasa rdcin ClinicalDocument prin

intermediul unei relaii de participare)
authenticator reprezint un participant care atest acurateea coninutului

documentului, dar nu are privilegii de autentificare a documentului din punct de
vedere legal.
author reprezint persoanele sau mainile care au creat documentul CDA.
custodian reprezint organizaia care este responsabil de ntreinerea

documentului.
dataEnterer reprezint participantul care a introdus textului dup dictare, sau

prin copiere de pe hrtie.
encounterParticipant reprezint membrii personalului clinic care au participat

direct la actul medical.
informant este o persoan care ofer informaii relevante despre pacient, cum ar
fi o rud apropiat a unui pacient n com care descrie comportamentul anterior
al acestuia.
informationRecipient reprezint un destinatar al informaiei, care ar trebui s

primeasc o copie a documentului.

legalAuthenticator reprezint un participant care autentific din punct de vedere

legal documentul.
participant reprezint orice alt participant care nu este menionat explicit de

clasele definite de CDA, care a fost implicat ntr-un fel n actul medical
documentat.
performer reprezint medicul care a efectuat propriu-zis actul medical, care

poate diferi de autorul documentului.
recordTarget reprezint nregistrarea medical creia n aparine prezentul

document, n cazul unei internri n spital, de exemplu.
responsibleParty reprezint participantul care are responsabilitatea legal n

legtur cu rezultatul actului medical, care este de regul furnizorul de servicii
medicale.
Header Relationships (descrie clasele legate de clasa rdcin ClinicalDocument print-o

relaie de tip ActRelationship)
ParentDocument reprezint sursa unei revizii de document, a unei anexe sau

transformri. (Un document clinic poate fi nlocuit de un nou document sau poate fi
completat printr-o anex.)
ServiceEvent reprezint actul medical (Act) care este documentat ca CDA (ex: o
apendectomie). n unele cazuri, valoarea lui ServiceEvent este inerent tipul de
document ClinicalDocument.code, spre exemplu pentru un cod cu valoarea "History
and Physical Report", procedura documentat va fi un act medical de tip "History and
Physical". n acelai timp, un ServiceEvent poate detalia suplimentar actul medical
inerent pentru ClinicalDocument.code, spre exemplu un ClinicalDocument.code
descris simplu ca "Procedure Report" se poate detalia cu o "colonoscopy". n
exemplele anterioare au fost folosite coduri specifice LOINC.
Order reprezint trimiterea sau recomandarea care a fost ndeplinit de acest

document (ex: o trimitere la radiologie).
Consent refer o aprobare asociat cu documentul CDA curent. (Tipul aprobrii

este dat de atributul Consent.code. Acordurile referite n antetul CDA care au fost
finalizate (Consent.statusCode este egal cu "completed") trebuie s fie la dosar.)
EncompassingEncounter (Optional) reprezint locul n care actul medical a avut

loc documentat sau unde a fost efectuat serviciul de tip ServiceEvent. (De notat c
documentele nu sunt generate n mod obligatoriu n timpul actului medical, spre
exemplu n cazul unor analize de laborator, unde rezultatele pot fi consemnate la un
anumit timp dup prelevarea probelor biologice).

3.5.2. Corpul documentului CDA
Corpul documentului CDA poate fi constituit, fie din text sau coninut binar nestructurat, fie din
marcaje structurate. Fiecare document CDA are un singur corp asociat cu clasa
ClinicalDocument din CDA printr-o relaie de compunere, n sensul UML:
Body Choice (elementul de tip corp (body) asociat printr-o relaie de compoziie cu
documentul)
NonXMLBody reprezint un corp de document CDA care este ntr-un alt format
dect XML. Atributul NonXMLBody.text este utlizat pentru a referi informaii stocate
n afara documentului CDA sau pentru a codifica informaii direct n cadrul
documentului. Afiarea coninutului corpului non-XML necesit unelte sau aplicaii
software care pot interpreta tipul media MIME al fiierului respectiv.
StructuredBody reprezint un corp de document CDA care este alctuit din una
sau mai multe seciuni. (Clasa StructuredBody este asociat n diagrama UML a
CDA cu una sau mai multe clase de tip Section prin intermediul unor relaii de
compoziie).
3.5.3. Seciunile documentului CDA
Prezentm n continuare atributele i clasele de tip Participare i Relaie care pot aprea a
nivelul unei seciuni a documentului medical CDA.
Section Attributes (Seciunile unui document pot fi imbricate i pot suprascrie contextul
propagat din antet sau din seciunile printe, coninnd blocuri narative i nregistrri
CDA)
Section.id reprezint identificatorul unic de instan al unei seciuni de document

CDA.
Section.code specific tipul particular de seciune. Valoare este preluat din

codurile LOINC.
Section.title reprezint eticheta seciunii.
Section.text conine blocul narativ care se afieaz, i este obligatoriu de

completat.
Section.confidentialityCode poate suprascrie valoarea propagat din

StructuredBody.
Section.languageCode specific limba n care a fost scris seciunea.
Section Participants
author reprezint persoana sau aplicaia care a creat seciunea (suprascrie

valoarea propagat din antetul CDA).
informant reprezint o persoan care ofer informaii relevante despre subiect

(suprascrie valoarea propagat din antetul CDA).

subject reprezint inta primar a nregistrrilor documentate n seciune. (De

cele mai multe ori este aceeai ca i recordTarget. Se propag ctre seciunile
dependente, dac nu este suprascris. Subiectul este presupus a fi pacientul.)
Section Relationships
component reprezint relaia prin care o seciune se poate imbrica n alt

seciune.
entry reprezint relaia prin care o nregistrare CDA este inclus prin
apartenen ntr-o seciune.
Section Narrative Block (reprezint blocul narativ al unei seciuni)
Section.text este utilizat pentru a stoca blocul narativ care va fi afiat.

Schema modelului de coninut al unui bloc narativ CDA este creat n mod special
pentru a ndeplini cerinele subliniate mai sus (a se vedea Afiarea documentelor
HL7-CDA). Schema este specificat ca un tip de date MIME (text/x-hl7-text+xml),
care reprezint tipul fixat pentru atributul Section.text.
3.5.4. nregistrri structurate n CDA
nregistrrile CDA reprezint componentele unei seciuni ale documentului care sunt
procesabile de ctre aplicaie. nregistrrile sunt derivate din modelul partajat al HL7 Clinical
Statement. Fiecare seciune poate conine zero sau mai multe nregistrri.
Prezentm n continuare clasele de tip Activitate/Act medical, precum i clasele de tip
Participare i Relaie care pot aprea a nivelul unei nregistrri structurate CDA.
Entry Acts acte medicale la nivel de nregistrare
Act o clas derivat din clasa Act din RIM, care poate fi utilizat generic atunci
cnd nicio alt clas particular nu este potrivit;
Encounter o clas derivat din clasa PatientEncounter din RIM, utilizat pentru a
reprezenta acte medicale relaionate, cum ar fi consultaii de urmrire, sau
consultaii medicale anterioare de referin.
Observation - o clas derivat din clasa Observation din RIM, utilizat pentru
reprezentarea observaiilor medicale.
ObservationMedia - o clas derivat din clasa Observation din RIM care reprezint
obiecte multimedia care fac parte din punct de vedere logic din documentul
curent.
Organizer - o clas derivat din clasa Act din RIM, care poate fi utilizat pentru a
crea grupri arbitrare a altor nregistrri CDA care partajeaz un context comun.
Procedure - o clas derivat din clasa Procedure din RIM, utilizat pentru
reprezentarea procedurile medicale.

RegionOfInterest - o clas derivat din clasa Observation din RIM care reprezint
o regiune de interes n cadrul unei imagini, i care este afiat ca form de
suprapunere pentru a evidenia regiunea respectiv.
SubstanceAdministration - o clas derivat din clasa SubstanceAdministration din

RIM, utilizat pentru reprezentarea evenimentelor legate de medicaie, cum ar fi
istoricul medical, sau prescripiile de administrare de medicamente.
Supply - o clas derivat din clasa Supply din RIM, utilizat pentru reprezentarea
produselor i materialelor sanitare utilizate n cadrul actului medical.
Entry Participants Participani la nivel de nregistrare (acetia pot aprea i n antetul

documentului CDA, dar se pot specifica la nivel de nregistrare n cazul n care difer de cei
din antet)
author (autorul documentului medical care descrie un act de ngrijire a sntii)
consumable (substan sau produs consumat n timpul actului medical)
informant (persoan care ofer informaii despre subiectul actului medical)
participant (persoana care a participat la actul medical)
performer (persoana care a efectuat actul medical)
product (produs medical)
specimen (specimen ntr-un act medical)
subject (subiect al actului medical) identific de regul pacientul
Entry Relationships Relaii la nivel de nregistrare
component (component)
precondition (precondiie)
referenceRange (domeniu de referin)
entryRelationship (relaie cu o alt ntregistrare)
reference (referin)
3.6. CONTEXTUL UNUI DOCUMENT CDA

Fiecare element al unui document CDA are un context n care are semnificaie. Contextul
general al unui document CDA este specificat de elementele din antet, a cror semnificaie se
aplic i la nivelul corpului documentului, al seciunilor i al nregistrrilor CDA.
Un document CDA este un nveli conceptual al propriului coninut. Afirmaiile din antetul
documentului sunt aplicabile, de regul, i asupra informaiilor din corpul documentului, att
timp ct nu sunt suprascrise. n acest sens standardul HL7 specific un set de reguli ale

contextului unui document CDA, n relaia cu RIM, cu scopul de a explicita modul n care o
aplicaie trebuie s interpreteze coninutul documentului sau contextul unei pri a sa n acelai
mod ca i o fiin uman.
Cu toate acestea nu se poate garanta faptul c o procesare automat va identifica o aplicare
greit a regulilor de context. Dac un medic nregistreaz un diagnostic extern n blocul
narativ, dar omite s anuleze contextul unui informator, procesarea automat nu va identifica
corect sursa informaiei respective.
Specificaia HL7-RIM definete contextul unei activiti ca fiind acei participani la respectivul
act care pot fi propagai n cadrul actelor imbricate. Specificaia HL7-CDA constrnge acest
mecanism astfel nct contextul se propag ntotdeauna pn la nivelul la care este suprascris.

4. DESCRIEREA SERVICIILOR WEB EXPUSE
n acest capitol sunt prezentate pe larg metodele expuse de interfaa servicilor-web ale
sistemului DES. 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 DES 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: 1234567_CODCAS
- Parol: ABC12-DE34-FG56-H789
Sistemul DES (Dosarul Electronic de Sntate) expune urmtoarele fiiere WSDL care specific
funcionalitile destinate iniializrii i consultrii dosarului electronic de sntate al unui
pacient, precum i transmiterii i consultrii documentelor medicale care stau la baza obinerii
i consolidrii datelor medicale relevante din dosar:
- ManageMedicalFile.wsdl pentru serviciul-web de administrare a dosarului electronic de
sntate, care permite iniializarea dosarului unui pacient.
- StoreClinicalDocument.wsdl pentru serviciul-web de procesare a cererilor de
transmitere a documentelor medicale din DES.
- ClinicalDocument.wsdl pentru serviciul-web de procesare a cererilor de consultare a
documentelor medicale din DES.
- ConsolidatedClinicalDocument.wsdl pentru serviciul-web de procesare a cererilor de
consultare a datelor medicale relevante din DES, care permite consultarea seciunilor
DMR ale dosaului unui pacient.
- SecurityMatrix.wsdl pentru serviciul-web de procesare a cererilor de autorizare pe baza
matricii de securitate a pacientului.

Pentru fiecare serviciu Web sunt definite structurile de date acceptate de metodele expuse n
cadrul unor fiiere XSD (XML Schema Definition), corespunztoare fiecrui serviciu-Web n
parte, denumite astfel: [NumeFiierWsdl]_schema1.xsd.
Adresa serviciilor-web expuse de Sistemul Informatic pentru Cardul Electronic de Asigurri de
Sntate este:
https://ws.des-cnas.ro/desws/ManageMedicalFile
https://ws.des-cnas.ro/desws/StoreClinicalDocument
https://ws.des-cnas.ro/desws/ClinicalDocument
https://ws.des-cnas.ro/desws/ConsolidatedClinicalDocument
https://ws.des-cnas.ro/desws/SecurityMatrix
https://ws.des-cnas.ro/desws/ExportCodingSystem
4.1. AUTORIZAREA ACCESULUI FURNIZORULUI DE SERVICII MEDICALE LA DES

Autorizarea i controlul accesului la serviciile-web exspunde ed DES se realizeaza prin
transmiterea unui mesaj de login la un modul OCSP ce contine certificatul electronic, numele
utilizatorului i parola.
Ulterior aplicaia client va furniza credentialele asociate furnizorului de servicii medicale (user
si parola) precum si token-ul obtinut de la OCSP la fiecare apel al serviciilor-web expuse de
DES n antetul de transport HTTP, similar cu sistemele existente SIUI, SIPE i CEAS.
Adresa serviciului de autentificare i validare OCSP a certificatelor digitale este urmtoarea:
https://ws.des-cnas.ro/OCSP/validator
De observat c adresa pentru OCSP corespunde serviciilor expuse de SIUI; accesul la serviciile
expuse de sistemul DES fiind realizat folosind aceleai certificate digitale i credeniale de
acces (utilizator/parol) ca i pentru SIUI, SIPE i CEAS.
Serviciul de autentificare transmite aplicaiei client un jeton de sesiune care trebui adugat de
ctre aplicaie n antetul cererii HTTP(S) 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 obinerea jetonul de sesiune serviciul de autentificare necesit transmiterea
ca parametru a numelui contului de utilizator, ca n exemplul urmtor:
https://ws.des-cnas.ro/OCSP/validator?username=1234567_CODCAS.
De notat c acest jeton are o perioad de valabilitate limitat, dup care expir, fiind necesar
obinerea unui nou jeton.
4.1.1. Autentificarea aplicaiei client

Sistemul Informatic introduce conceptul de autentificare a aplicaiei client. Acest lucru permite
accesul controlat la sistem al aplicaiilor client, pe baza unor chei de autentificare secrete.
Acest lucru se realizeaz prin transmiterea unui codului de furnizor i al unei valori hash
obinute prin aplicarea algoritmului AES cu o cheie specific furnizorului asupra unui token cu
valabilitate limitat. Tokenul este format din codul operaiei SOAP i data curenta (cu informaie
de timp). Exemplu de token valid pentru operatia de preluare a unui document:

getClinicalDocument#2013-11-23T12:34:23
NOT
Un exeplu de cod pentru autentificarea aplicaiei client este prezentat n seciunea
5.45.5 - Clas utilitar pentru autorizarea aplicaiei de raportare
Documentul de mai jos reprezinta descrierea caracteristicilor de interfatare cu SDK-ul

implementat in cadrul CEAS pentru cititoarele de smart-card:
o http://siui.casan.ro/cnas/siui_3.5/docs/specificatii/Specificatie%20Interfatare%20SIUI%
20-%20Anexa%20102%20-%20Specificatii_eCard_SDK.pdf
Operatia de semnare electronic se poate realiza numai cu un card activ si se face numai prin
apelul metodei ComputeHash expusa de SDK.
Metoda are urmatoare definitie:
byte[] ComputeHash( byte[] buffer )
// buffer - byte array to compute
// returns - computed hash code
Scenariul de utilizare este urmtorul:

1. Se primete token software ( session-id-hash ) de la serverul de autentificare OCSP
denumit in continuare ocspToken
2. Se formeaz un ir de caractere de forma:
cid|cardNo|evidenceDate|ocspToken, unde evidenceDate este in format XmlDateTime.
3. irul de caractere se transform ntr-un array de bytes.
4. Se apeleaz metoda computeHash expus de SDK, iar rezultatul n format base64 se
completeaz n atributul evidenceHash la apelul ctre DES.
NOT
Un exeplu de cod pentru scenariul de mai sus este prezentat n seciunea 5.6 - Clas
utilitar pentru co-autentificarea pacientului.
4.2. SERVICIUL PENTRU ADMINISTRAREA DOSARULUI ELECTRONIC DE SNTATE

Acest serviciu se folosete pentru administrarea dosarului electronic de sntate. Suplimentar,
acest serviciu permite asocierea unui reprezentant legal la dosarul de sntate al unui pacient
pentru cazurile n care pacienii nu i pot exercita direct drepturile, cum ar fi cazurile minorilor
sau persoanelor aflate n ntreinere.
Nume implementare serviciu: ManageMedicalFile, descris n fiierul WDSL cu acelai nume.
4.2.1. Metoda initializeMedicalFileS iniializare dosar electronic de sntate

Metoda creeaz dosarul electronic de sntate al pacientului i completeaz date iniiale.
Astfel, dac pacientul nu are deja un dosar, serviciul iniializeaz i pre-populeaz dosarul cu
date medicale din celelalte sistemele compoenente ale PIAS. Dac dosarul exist deja, atunci
se adaug relaia de reprezentant legal pentru acel dosar.
Metoda utilizeaz urmtoarele mesaje:
o Mesajul de intrare initializeMedicalFileS conine un obiect de tipul
secureInitMedicalFileRequest care include dou atribute de tip binar codificate Base64:
archivedDocumentField, coninnd un fiier XML arhivat ZIP (deflate-only) i, respectiv

pkcs7signature, coninnd semntura digital detaat a acestuia realizat conform
exemplului din seciunea 5.7 - Clas utilitar pentru realizarea semnturii digitale;
o Mesajul de rspuns este de tipul initializeMedicalFileSResponse i nu conine date.
Fiierul XML conine urmtoarele informaii ntr-un nod rdcin initMedicalFileRequest:
1. Medicul care solicit operaia
<physician>
<fullName>Georgescu Ion</fullName> <!nume complet -->
<stencilNo>424334</stencilNo> <!numr paraf -->
</physician>
2. Persoana ce solicita cererea (solicitant):

<requestPerson>
<icExpiration>2014-01-31</icExpiration> <!data expirrii CI -->
<icNumber>24534323</icNumber> 
<icSeries>rt</icSeries> 
<personData>
<birthDate>2012-11-06</birthDate> 
<cid>4012345678987654321</cid> 
<firstName>Ion</firstName> 
<lastName>Popescu</lastName> <!nume de familie -->
</personData>
</requestPerson>
3. Tipul de relatie dintre solicitant i pacient (opional, dac solicitantul difer de pacient):
<relationType>CARER</relationType> 
sau
<relationType>CHILD</relationType> 
4. Persoana pentru care se face cererea (pacient) (opional, dac difer de solicitant)
<subject>
<birthDate>2014-01-31</birthDate> 
<cid>4098765432123456789</cid> 
<firstName>Vasile</firstName> 
<lastName>Ionescu</lastName> <!nume de familie -->
</subject>
4.3. SERVICIUL PENTRU TRANSMITEREA DOCUMENTELOR MEDICALE CTRE DES

Acest serviciu se folosete pentru consulatrea documentelor medicale din DES, permind
operaii de preluare a documentelor medicale electronice din sistemul DES (acele documente
de baz care, prin consolidare, au dus la crearea unui document medical relevant).
Nume implementare serviciu: StoreClinicalDocument, descris n fiierul WDSL cu acelai nume.
4.3.1. Metoda storeClinicalDocument transmitere document medical

Metoda adaug sau modifica un document clinic (CDA) la dosarul unui pacient. O aplicaie client
poate folosi aceast metod pentru a trimite versiunea iniial a unui document, dar i pentru a
retrimite un document care exist deja n sistem cu acelai identificator unic, caz n care
operaia devine de modificare, versiunea anterioar a documentului fiind nlocuit.
o Mesajul de intrare storeClinicalDocumentS conine un obiect de tipul

storeClinicalDocumentRequest care include dou atribute de tip binar codificate Base64:
archivedDocumentField, reprezentnd un fiier XML n format HL7-CDA arhivat ZIP
(deflate-only) i, respectiv pkcs7signature, coninnd semntura digital detaat a
acestuia realizat conform exemplului din seciunea 5.7 - Clas utilitar pentru realizarea
semnturii digitale;
o Mesajul de rspuns este de tipul storeClinicalDocumentSResponse care conine un
atribut warnings de tip string cu avertizri emise de sistem la procesarea cererii de
transmitere a documentului medical.
Structura documentului clinic n format HL7-CDA este prezentat n Ghidul de implementare
documente medicale electronice.
Sunt acceptate urmtoarele tipuri de documente clinice:
- Fi de consultaie de specialitate
- Fi de consultaie de medicin primar
- Fi de internare n spital
- Fi de externare din spitale
- Bilet de trimire ctre specialist
- Bilet de trimire ctre laborator
- Recomandare medical pentru dispozitive medicale
- Recomandare medical pentru ngrijire la domiciliu
- Prescripie medical compensat sau gratuit
4.3.2. Metoda removeDocumentSetS tergere document medical

Metoda anuleaz un document clinic (CDA) din dosarul unui pacient. O aplicaie client poate
folosi aceast metod pentru a trimite o cerere de anulare a unui document care exist deja n
sistem pe baza identificatorului unic al acestuia.
o Mesajul de intrare removeDocumentSetS conine un obiect de tipul
secureRemoveClinicalDocumentRequest care include dou atribute de tip binar codificate
Base64: archivedDocumentField, reprezentnd un fiier XML arhivat ZIP (deflate-only) i,
respectiv pkcs7signature, coninnd semntura digital detaat a acestuia realizat
conform exemplului din seciunea 5.7 - Clas utilitar pentru realizarea semnturii
digitale;
o Mesajul de rspuns este de tipul removeClinicalDocumentResponse i nu conine date.
Fiierul XML conine urmtoarele informaii:
<removeClinicalDocumentRequest>
<authorName>Popescu Ion</authorName> 
<authorStencilCode>424334</authorStencilCode> 
<dateTime>2014-01-31</dateTime> 
<documentType>57133-2</documentType> 
<patientCID>424334</patientCID> 
<removedDocumentID>424334</removedDocumentID> 
<uicMedicalServiceProvider>424334</uicMedicalServiceProvider> 
</removeClinicalDocumentRequest>

4.4. SERVICIUL PENTRU CONSULTAREA DOCUMENTELOR MEDICALE DIN DES

Acest serviciu se folosete pentru consulatrea documentelor medicale din DES, permind
operaii de preluare a documentelor medicale electronice din sistemul DES (acele documente
de baz care, prin consolidare, au dus la crearea unui document medical relevant).
Nume implementare serviciu: ClinicalDocument, descris n fiierul WDSL cu acelai nume.
4.4.1. Metoda getClinicalDocumentS preluare document medical

Metoda permite interogarea de ctre aplicaiile informatice ale furnizorilor de servicii medicale
a sistemului DES pentru obinerea documentelor medicale electronice care au stat la baza
datelor medicale consolidate din DMR.
o Mesajul de intrare getClinicalDocumentS conine un obiect de tipul
getClinicalDocumentRequest care include cteva atribute de tip string, i anume:
- desDocumentUUID, reprezentnd identificatorul unic al documentului n DES;
- documentType, reprezentnd tipul documentului (conform cu enumerarea
DocumentType definit n fiierul WSDL);
- patientCid, reprezentnd CID-ul pacientului la care se refer documentul;
- physicianStencilNo, reprezentnd parafa medicului care solicit documentul.
pe lg aceste atribute exist i un atribut opional de tip patientCoAuthentication folosit
pentru co-autentificarea pacientului, realizat conform exemplului din seciunea 4.6,
respectiv: 5.3 - Consultare documente medicale emise de medic existente n DES i 5.6 -
Clas utilitar pentru co-autentificarea pacientului;
o Mesajul de rspuns getClinicalDocumentSResponse, trimis de server i conine un atribut
return, de tip clinicalDocumentResponse (o clas cu un atribut de tip binar:
archivedDocument) reprezentnd coninutul arhivat ZIP (inflate-only) al documentului
medical n format CDA, aa cum a fost transmis de originator n DES.
4.4.2. Metoda getPhysicianClinicalDocuments list documente proprii medic

a sistemului DES pentru obinerea listei de documente medicale electronice care au fost
transmise de un medic.
Sistemul efeactueaz validarea faptului c medicul autentificat este acelai cu medicul care a
emis documentele, ceea ce nu permite interogarea directp a documentelor emise de ali
medici.
o Mesajul de intrare getPhysicianClinicalDocuments conine un obiect de tipul
getClinicalDocumentsRequest care include urmtoarele atribute, consituind parametri de
cutare/filtrare pentru documentele din sistem:
- documentType, de tip string reprezentnd tipul documentului (conform cu
enumerarea DocumentType definit n fiierul WSDL);
- patientCid, de tip string reprezentnd CID-ul pacientului la care se refer
documentul;

- physicianStencilNo, de tip string reprezentnd parafa medicului emitent al

documentului;
- startDate, de tip DateTime reprezentnd data de nceput a intervalului de cutare;
- endDate, de tip DateTime reprezentnd data de sfrit a intervalului de cutare.
o Mesajul de rspuns getPhysicianClinicalDocumentsResponse, trimis de server i conine
un atribut return, de tip vector de obiecte de tip documentMetadata reprezentnd
documentele specifice, clas care conine la rndul ei urmtoarele atribute de tip string:
- documentUUID, reprezentnd identificatorul unic al documentului n DES;
- effectiveTime, reprezentnd data la care a fost creat documentul;
- patientCid, reprezentnd CID-ul pacientului la care se refer documentul.
4.4.3. Metoda getMedicalFileOlderDocuments list documente vechi pacient

a sistemului DES pentru obinerea listei de documente medicale ale unui pacient mai vechi de 6
luni, limita de retenie n DMR.
o Mesajul de intrare getMedicalFileOlderDocuments conine un obiect de tipul
olderDocumentsRequest care include urmtoarele atribute, consituind parametri de
cutare/filtrare pentru documentele din sistem:
- documentType, de tip string reprezentnd tipul documentului (conform cu
enumerarea DocumentType definit n fiierul WSDL);
- patientCid, de tip string reprezentnd CID-ul pacientului la care se refer
documentul;
- physicianStencilNo, de tip string reprezentnd parafa medicului care solicit lista
de documente a pacientului;
- startDate, de tip DateTime reprezentnd data de nceput a intervalului de cutare;
- endDate, de tip DateTime reprezentnd data de sfrit a intervalului de cutare.
o Mesajul de rspuns getMedicalFileOlderDocumentsResponse, trimis de server i conine
un atribut return, de tip vector de obiecte de tip documentMetadata reprezentnd
- documentUUID, reprezentnd identificatorul unic al documentului n DES;
- patientCid, reprezentnd CID-ul pacientului la care se refer documentul.

4.4.4. Metoda getRelevantRefferals list bilete de trimitere relevante

a sistemului DES pentru obinerea listei de bilete de trimitere relevante pentru un pacient, care
poate fi utilizat atunci cnd un pacient se prezint la o consultaie de specialitate.
o Mesajul de intrare getRelevantRefferals conine un obiect de tipul
relevantReferralsRequest care include urmtoarele atribute de tip string, consituind
parametri de cutare/filtrare pentru documentele din sistem:
- patientCid, reprezentnd CID-ul pacientului pentru care se caut trimiteri;
- physicianStencilNo, reprezentnd parafa medicului care solicit lista de trimiteri a
pacientului;
- physicianSpecialtyCode, reprezentnd codul de specialitate al medicului care
solicit lista de trimiteri.
o Mesajul de rspuns getRelevantRefferalsResponse, trimis de server i conine un atribut
return, de tip vector de obiecte de tip documentReferralMetadata reprezentnd
- desDocumentUUID, reprezentnd identificatorul unic al documentului n DES;
- patientCid, reprezentnd CID-ul pacientului la care se refer documentul;
- custodianCui, reprezentnd CUI-ul furnizorului de servicii medicale care a emis
documentul;
- authorStencilNo, reprezentnd numrul de paraf al medicului care a creat
documentul;
- legalAuthenticatorStencilNo, reprezentnd numrul de paraf al medicului care a
autentificat legal documentul.
4.5. SERVICIUL PENTRU CONSULTAREA DATELOR MEDICALE RELEVANTE DIN DES

Acest serviciu se folosete pentru consultarea din aplicaiile informatice ale furnizorilor de
servicii medicale a datelor medicale relevante consolidate din sistemul DES.
Nume implementare serviciu: ConsolidatedClinicalDocument, descris n fiierul WDSL cu
acelai nume.
4.5.1. Metoda getConsolidatedPatientIdentityS consultare date identificare pacient

Metoda permite consultarea seciunii de date de identificare a pacientului din DMR.
o Mesajul de intrare getConsolidatedPatientIdentityS conine un obiect de tipul
getConsolidatedPatientIdentityRequest care include urmtoarele atribute de tip string,
consituind parametri de cutare/filtrare pentru documentele din sistem:


pacientului.
o Mesajul de rspuns este de tipul getConsolidatedPatientIdentitySResponse i conine un
atribut return, de tip clinicalDocumentResponse (o clas cu un atribut de tip binar:
archivedDocument) reprezentnd coninutul arhivat ZIP (inflate-only) al seciunii DMR n
format CDA consolidat i generat de sistemul DES.
Un exemplu generic de utilizare al acestei metode poate fi adaptat dup cel din seciunea 5.2 -
Consultare date medicale relevante din DES.
4.5.2. Metoda getConsolidatedSummaryS consultare sumar de urgen

Metoda permite consultarea sumarului dosarului medical i a informaiilor n situaii de
urgen din DMR.
o Mesajul de intrare getConsolidatedSummaryS conine un obiect de tipul
getConsolidatedSummaryRequest care include urmtoarele atribute de tip string,
pacientului.
o Mesajul de rspuns este de tipul getConsolidatedSummarySResponse i conine un
Un exemplu generic de utilizare al acestei metode se gsete n seciunea 5.2 - Consultare date
medicale relevante din DES.
4.5.3. Metoda getConsolidatedMedicalHistoryS consultare istoric medical

Metoda permite consultarea seciunii de istoric medical al pacientului din DMR.
o Mesajul de intrare getConsolidatedMedicalHistoryS conine un obiect de tipul
getConsolidatedMedicalHistoryRequest care include urmtoarele atribute de tip string,
pacientului.


o Mesajul de rspuns este de tipul getConsolidatedMedicalHistorySResponse i conine un
4.5.4. Metoda getConsolidatedEventsHistoryS consultare documente medicale

Metoda permite consultarea seciunii de evenimente medicale ale pacientului din DMR.
o Mesajul de intrare getConsolidatedEventsHistoryS conine un obiect de tipul
getConsolidatedEventsHistoryRequest care include urmtoarele atribute de tip string,
pacientului.
o Mesajul de rspuns este de tipul getConsolidatedEventsHistorySResponse i conine un
4.5.5. Metoda getConsolidatedAntecedentsS consultare antecedente medicale

Metoda permite consultarea seciunii de antecedente medicale a pacientului din DMR.
o Mesajul de intrare getConsolidatedAntecedentsS conine un obiect de tipul
getConsolidatedAntecedentsRequest care include urmtoarele atribute de tip string,
pacientului.

o Mesajul de rspuns este de tipul getConsolidatedAntecedentsSResponse i conine un

4.6. SERVICIUL PENTRU CONSULTAREA MATRICII DE SECURITATE DIN DES

Acest serviciu se folosete pentru consulatrea matricii de securitate corespunztoare unui
pacient, permind operaia de propunere a unei poziii utilizabile de pe matricea curent
asociat n sistemul DES unui pacient, dac aceast exist i are poziii valabile.
Nume implementare serviciu: SecurityMatrix, descris n fiierul WDSL cu acelai nume.
4.6.1. Metoda suggestMatrixCoordinates sugerare coordonate matrice

Metoda permite interogarea de ctre aplicaiile informatice ale furnizorilor de medicale a
sistemului DES pentru obinerea unei poziii utilizabile de pe matricea de securitate curent a
unui pacient, pentru utilizarea n cadrul procesului de co-autentificare a pacientului.
o Mesajul de intrare este de tipul suggestMatrixCoordinates care include dou atribute de
tip string: patientCid, reprezentnd CID-ul pacientului pentru care se face cererea i,
respectiv physicianStencilNo, reprezentnd numrul de paraf al medicului care face
cererea.
o Mesajul de rspuns este de tipul suggestMatrixCoordinatesResponse i conine un atribut
return, de tip matrixPos (o clas cu dou atribute de tip ntreg: XCoord i ZCoord)
reprezentnd coordonatele libere propuse pentru co-autentificarea pacientului.
4.7. SERVICIUL PENTRU SINCRONIZAREA NOMECLATOARELOR DIN DES

Acest serviciu se folosete pentru preluarea i sincronizarea setului de nomenclatoare
specifice utilizate de sistemul DES, altele dect cele gestionate de SIUI.
Nume implementare serviciu: ExportCodingSystem, descris n fiierul WDSL cu acelai nume.
4.7.1. Metoda exportSystemCodesSummary export list nomenclatoare

sistemului DES pentru obinerea de unei liste de nomenclatoare, precum i a datei ultimei
actualizri pentru fiecare n parte.
o Mesajul de intrare este de tipul exportSystemCodesSummary care nu are atribute.
o Mesajul de rspuns este de tipul exportSystemCodesSummaryResponse i conine un
atribut return, de tip exportCatalogsSummaryResponse (o clas cu un atribut de tip
catalogsSummary, care conine o list de tip catalogMetadata, cu urmtoarele atribute:
codeSystem codul nomenclatorului, codeSystemName denumirea nomenclatorului,
lastModifyDate data ultimulei actualizri) reprezentnd lista nomenclatoarelor
disponibile n sistem, care pot fi preluate folosind metoda urmtoare.

4.7.2. Metoda exportCodeSystem export valori nomenclator

sistemului DES pentru obinerea de listei de valori corespunztoare unui nomenclator.
o Mesajul de intrare este de tipul exportCatalogRequest care include un atribut de tip ir de
caractere: codeSystemName, reprezentnd denumirea nomenclatorului pentru care face
cererea de export i descrcare.
o Mesajul de rspuns este de tipul exportCodeSystemResponse i conine un atribut return,
de tip exportCatalogsResponse (o clas cu un atribut de tip binar: archivedFile)
reprezentnd coninutul arhivat ZIP (inflate-only) ce conine setul de valori ale
nomenclatorului specificat n cerere.

5. EXEMPLE DE COD .NET PENTRU INTEGRAREA CU DES
n continuare prezentm cteva exemple cod surs .NET/C# pentru conectarea la DES i
transmiterea ctre acesta a documentelor medicale, dar i pentru consultarea datelor
medicale relevante din dosarul unui pacient.
Exemplele folosesc tipurile de date definile n WSDL-urile publice ale DES, mapate automat n
clase .NET de utilitarele specifice acestei platforme.
La sfritul seciuni sunt prezentate cteva exemple de clase utilitare i cod ajuttor pentru
realizarea unor operaii specifice, cum ar fi semnarea electronic a documentului medical,
obinerea codului de autorizare a aplicaiei i al challange-ului de autorizare a aplicaiei, dar i
pentru co-autentificarea pacientului folosind matricea de securitate generar n portalul public
al DES sau cu cardul electronic de asigurri de sntate al CNAS (CEAS).
5.1. TRANSMITERE DOCUMENT MEDICAL CDA CTRE DES

string CallWebServiceMethod( StoreClinicalDocument webService,
string cdaFilePath,
X509Certificate2 certificate )
{
// set auth header
webService.desClientSoftwareAuthenticationValue = new desClientSoftwareAuthentication
{
clientCode = DesKeyGen.AppKey(),
challengeResponse = DesKeyGen.ComputeAuth( "storeClinicalDocument" )
};
// prepare method params
var zipBuffer = ZipArchive.ZipBuffer( File.ReadAllBytes( cdaFilePath ) );
var signBuffer = DigitalSignature ComputeSignature( certificate, zipBuffer );
// init method params
var storeClinicalData = new storeClinicalDocumentS
{
storeClinicalDocument = new storeClinicalDocumentRequest
{
archivedDocument = zipBuffer,
pkcs7signature = signBuffer
}
};
// call ws method
var response = webService.storeClinicalDocumentS( storeClinicalData );
// return warnings, if any
return response.@return.warnings;
}

5.2. CONSULTARE DATE MEDICALE RELEVANTE DIN DES

string CallWebServiceMethod( ConsolidatedClinicalDocument webService, string dmrFilePath )
{
// set auth header
{
challengeResponse = DesKeyGen.ComputeAuth( "getConsolidatedSummary" )
};
// init method params (you can use either matrix or ceas co-authentication here)
var webServiceInput = new getConsolidatedSummaryS
{
consolidatedSummaryRequest = new getConsolidatedSummaryRequest
{
physicianStencilNo = 123456, // id of physician
patientCid = 40123456789876543210, // id of patient
patientCoAuthentication = PatientSecurity.GetMatixCoAuthentication()
}
};
// call ws method
var response = webService.getConsolidatedSummaryS( webServiceInput );
// process response
var response = ZipArchive.UnzipBuffer( response.@return.archivedDocument );
File.WriteAllBytes( dmrFilePath, response );
// return contents
return Encoding.UTF8.GetString( response );
}
5.3. CONSULTARE DOCUMENTE MEDICALE EMISE DE MEDIC EXISTENTE N DES

documentMetadata[] CallWebServiceMethod( ClinicalDocument webService )
{
// set auth header
{
challengeResponse = DesKeyGen.ComputeAuth( "getPhysicianClinicalDocuments" )
};
var clinicalDocumentsRequest = new getPhysicianClinicalDocuments
{
clinicalDocumentRequest = new getClinicalDocumentsRequest
{
physicianStencilNo = 123456,
uicMedicalServiceProvider = 987654321,
startDate = new DateTime( 2014, 1, 1 ),
startDateSpecified = true,
endDate = new DateTime( 2014, 1, 31 ),,
endDateSpecified = true,
}
};
// call ws method & return documents array
var result = webService.getPhysicianClinicalDocuments( clinicalDocumentsRequest );
return result.@return.clinicalDocuments;
}

5.4. PRELUARE NOMENCLATOARE (SISTEME DE CLASIFICARE) N DES

catalogMetadata[] CallWebServiceMethod(ExportCodingSystem webService )
{
// set auth header
{
challengeResponse = DesKeyGen.ComputeAuth( "exportSystemCodesSummary" )
};
var exportSystemCodesSummaryParam = new exportSystemCodesSummary();
// call ws method & return available catalogues array
var result = webService. exportSystemCodesSummary( exportSystemCodesSummaryParam );
return result.@return.systemCodesSummary.systemCodes;
}
Apoi se apleaz metoda urmtoare pentru fiecare nomenclator disponibil:

catalogMetadata[] CallWebServiceMethod(ExportCodingSystem webService )
{
// set auth header
{
challengeResponse = DesKeyGen.ComputeAuth( "exportCodeSystem" )
};
var exportCodeSystemParam = new exportCodeSystem
{
exportCodeSystemRequest = new exportCatalogRequest
{
codeSystemName = parameters.CodeSystemName
}
};
// call ws method & return catalogue archive
var result = webService.exportCodeSystem( exportCodeSystemParam );
return result.@return.archivedFile;
}
5.5. CLAS UTILITAR PENTRU AUTORIZAREA APLICAIEI DE RAPORTARE

public static class DesKeyGen
{
public static string AppKey()
{
return SIUIMF; // se completeaz cu valoarea specific fiecrei aplicaii
}
public static byte[] ComputeAuth( string methodName )

{
string seed = string.Format( "{0}#{1:yyyy-MM-ddTHH:mm:ss}", methodName, DateTime.Now );
return EncryptDataAES( Encoding.UTF8.GetBytes( seed ) );
}
private static byte[] EncryptDataAES( byte[] toEncrypt )

{
using( var aes = SymmetricAlgorithm.Create() )

{
aes.Mode = CipherMode.CBC;
aes.Key = Convert.FromBase64String( key ); // key este o constant de tip string
aes.IV = Convert.FromBase64String( iv ); //iv este o constant de tip string
aes.Padding = PaddingMode.PKCS7;
using( var mStream = new MemoryStream() )
{
using( var cStream = new CryptoStream( mStream, aes.CreateEncryptor(),
CryptoStreamMode.Write ) )
{
cStream.Write( toEncrypt, 0, toEncrypt.Length );
cStream.FlushFinalBlock();
return mStream.ToArray();
}
}
}
}
}
5.6. CLAS UTILITAR PENTRU CO-AUTENTIFICAREA PACIENTULUI

public static class PatientSecurity
{
public string ServerToken = ABCDEFGHIJKLMNOPQRSTUVWXYZ12345567890;
public static patientCoAuthentication GetMatixCoAuthentication()

{
// return patient co-authentication matrix challenge
return new patientCoAuthentication
{
coAuthenticatorCID = 40123456789876543210,
Item = new matrixChallenge
{
x = 1,
y = 1,
value = A1B
}
};
}
public static patientCoAuthentication GetCeasCoAuthentication()

{
// set evidence date
var evidenceDate = DateTime.Now;
// read card data using Novensys SDK
var cardData = NovensysSDK.ReadCardData( Fields.A1_CARD_NO | Fields.C1_CID );
// compute evidence seed
string evidenceSeed = string.Format( {0}|{1}|{2}|{3},
cardData.PersonCid,
cardData.CardNo,
evidenceDate,
ServerToken );
// compute card hash using Novensys SDK
byte[] evidenceHash = NovensysSDK.ComputeHash( evidenceSeed );
// return patient co-authentication CEAS challenge
return new patientCoAuthentication
{
coAuthenticatorCID = cardData.personCid,

Item = new ceasChallenge

{
cardNo = cardData.CardNo,
evidenceDate = evidenceDate,
evidenceHash = Convert.ToBase64String( evidenceHash )
}
};
}
}
5.7. CLAS UTILITAR PENTRU REALIZAREA SEMNTURII DIGITALE

public static class DigitalSignature
{
public static byte[] ComputeSignature( X509Certificate2 certificate, byte[] message )
{
// create content info wrapper
var contentInfo = new ContentInfo( message );
// create non-detached CMS signed message (to include original content)
var signedCms = new SignedCms( contentInfo, true );
// create CMS signer, using certificate issuer and serial number
var signer = new CmsSigner( SubjectIdentifierType.IssuerAndSerialNumber, certificate );
// include only subject certificate info (not the whole trust chain)
signer.IncludeOption = X509IncludeOption.EndCertOnly;
signer.SignedAttributes.Add( new Pkcs9SigningTime() );
// sign message with certificate / silent-mode false, to allow propt for password
signedCms.ComputeSignature( signer, false );
// encode the CMS message, original content is included in this byte array
return signedCms.Encode();
}
}

6. EXEMPLE DE DOCUMENTE MEDICALE CDA PENTRU MF
n anexa Specificatie Interfatare DES - Anexa Documente Clinice CDA - SIVECO.zip se gsesc
urmtoarele exemple de documente medicale CDA pentru MF:
6.1. DES_CDA_PCEXAM.XML
Acest fiier este un document medical electronic reprezentnd o fi de consultaie completat
de medicul de familie n timpul unei consultaii acordate unui pacient.
6.2. DES_CDA_CLNREF.XML
Acest fiier este un document medical electronic reprezentnd o trimitere ctre un medic
specialist completat de medicul de familie n timpul unei consultaii acordate unui pacient.
6.3. DES_CDA_LABREF.XML
Acest fiier este un document medical electronic reprezentnd o trimitere pentru analize i
investigaii de laborator completat de medicul de familie n timpul unei consultaii acordate
unui pacient.
6.4. DES_CDA_EPRESC.XML
Acest fiier este un document medical electronic reprezentnd o prescripie medical
completat de medicul de familie n timpul unei consultaii acordate unui pacient. Documentul
poate reprezenta att o prescripie electronic ct i una compensat tipizat pentru
medicamente psihotrope sau stupefiante.

Specificatie Interfatare DES - 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 DES - Aplicatii de Raportare Pentru Furnizori

Încărcat de

Drepturi de autor:

Formate disponibile

CASA NAIONAL DE ASIGURRI DE SNTATE DIN ROMNIA

SISTEMUL INFORMATIC INTEGRAT

Specificaii de interfaare cu DES pentru aplicaiile de raportare ale

ISTORICUL REVIZIILOR DOCUMENTULUI

Versiune Data Comentarii

1.0 (PROIECT) 25.10.2013 Versiune iniial propus

Versiune: 1.0 din 31.03.2014 Pagina 2 din 42

Versiune: 1.0 din 31.03.2014 Pagina 3 din 42

4.6. Serviciul pentru consultarea matricii de securitate din DES ....................................................................... 35

Versiune: 1.0 din 31.03.2014 Pagina 4 din 42

FIGURA 1 - STRUCTURA DOCUMENTULUI CLINIC ................................................................................................................ 15

Versiune: 1.0 din 31.03.2014 Pagina 5 din 42

Versiune: 1.0 din 31.03.2014 Pagina 6 din 42

2. PREZENTARE GENERAL DES

2.1. DESCRIEREA SISTEMULUI INFORMATIC INTEGRAT PENTRU DOSARUL

2.2. DMR - DATE MEDICALE RELEVANTE

Versiune: 1.0 din 31.03.2014 Pagina 7 din 42

2.2.1. Datele de identificare ale pacientului

Stratificarea pe seciuni a datelor de identificare ale pacientului este prezentat n Ghidul de

2.2.2. Sumar i urgen

2.2.3. Istoricul antecedentelor medicale

Versiune: 1.0 din 31.03.2014 Pagina 8 din 42

Stratificarea pe seciuni a istoricului antecedentelor medicale este prezentat n Ghidul de

2.2.4. Istoricul documentelor medicale

2.2.5. Istoricul medical al pacientului

Versiune: 1.0 din 31.03.2014 Pagina 9 din 42

2.2.6. DMR i standardul HL7-CDA

Aplicarea standardului HL7-CDA (Arhitectura Documentului Clinic) pentru formatarea i

Versiune: 1.0 din 31.03.2014 Pagina 10 din 42

3.1. CE ESTE HL7?

Versiune: 1.0 din 31.03.2014 Pagina 11 din 42

3.2. CE ESTE UN SISTEM EHR?

3.3. HL7-RIM MODELUL INFORMAIONAL DE REFERIN

Versiune: 1.0 din 31.03.2014 Pagina 12 din 42

Procesul de dezvoltare a standardului HL7 v3 definete regulile ce guverneaz derivarea

3.3.1. Specificaia HL7-RIM

3.3.2. Modelul abstract HL7-RIM

Versiune: 1.0 din 31.03.2014 Pagina 13 din 42

3.4. HL7-CDA ARHITECTURA DOCUMENTULUI CLINIC

Exemple de documente CDA:

Versiune: 1.0 din 31.03.2014 Pagina 14 din 42

3.4.1. Structura documentului CDA

Figura 1 - Structura documentului clinic

Versiune: 1.0 din 31.03.2014 Pagina 15 din 42

Un document CDA este ncadrat de un element denumit <ClinicalDocument> care conine

3.4.2. Extensibilitatea i adaptarea standardului HL7-CDA

Versiune: 1.0 din 31.03.2014 Pagina 16 din 42

3.4.3. Conformitatea cu standardul HL7-CDA

3.4.4. Afiarea documentelor HL7-CDA

Lizibilitatea pentru oameni nu trebuie s solicite emitentului s transmit o fi de stil

Lizibilitatea pentru oameni se aplic coninutului autentificat. Poate exista informaie

Versiune: 1.0 din 31.03.2014 Pagina 17 din 42

3.5. ELEMENTELE DE BAZ ALE DOCUMENTULUI CDA

3.5.1. Antetul documentului CDA

Versiune: 1.0 din 31.03.2014 Pagina 18 din 42

ClinicalDocument.id reprezint identificatorul unic al instanei curente de

ClinicalDocument.code specific tipul particular al documentului CDA curent (ex:

ClinicalDocument.title reprezint titlul documentului CDA.

ClinicalDocument.effectiveTime reprezint timpul de creare a documentul

ClinicalDocument.confidentialityCode este o component contextual obligatorie,

ClinicalDocument.languageCode specific limba n care este scris documentul.

ClinicalDocument.setId reprezint un identificator comun valabil n toate

Header Participants (descrie clasele legate de clasa rdcin ClinicalDocument prin

authenticator reprezint un participant care atest acurateea coninutului