Marc d`interoperabilitat

Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
Versió 2.0
Data
24/05/2011
17/06/2011
24/10/2011
01/12/2011
23/02/2012
13/03/2012
16/07/2012
Versió
1.0
1.1
1.2
1.3
1.4
1.5
1.6
23/10/2013 1.7
23/10/2013 1.7.1
06/11/2013 1.8
15/07/2014 1.9
01/10/2014 1.9.1
10/10/2014 1.9.2
24/10/2014 2.0
Descripció
Primera versió oficial presentada a comitè
Missatge inscripció SA perfil comunicació
Actualització del flux d’inscripció al SA
Actualització
Actualització
Actualització perfil comunicació missatges
Actualització post-homologacions
Actualització cas perfil de comunicació,
detall funcionament formulari
d’enregistrament
Revisió actualització 1.7
Actualització accés i registre a una
plataforma externa via firma professional.
Punts 8.2.2 i 8.2.3 actualitzats, 8.2.4 afegit.
Afegir nova modalitat del perfil
d’identificació i modificació dels elements
necessaris per passar de carpeta a canal.
Revisió actualització 1.9
Modificació de la definició del perfil de
comunicació. Incorporació de la nova
modalitat d'accés al canal.
Modificació perfil comunicació
Autor
Rafael Liñan
Matias Lizana
Matias Lizana
Carlos Gallego
Matias Lizana
Matias Lizana
Matias Lizana
Marc Górriz
Manel Domingo
Manel Domingo
Carme Pratdepàdua
Manel Domingo
Carme Pratdepàdua
Carme Pratdepàdua
1 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
Sumari
1.RESUMEXECUTIU
4 2.INTRODUCCIÓ
5 3.OBJECTIU
5 4.DEFINICIÓDELMARCD’INTEROPERABILITATDELMS
6 5.PERFILIDENTIFICACIÓ
7 5.1. Identificació de les plataformes externes 7 5.2. Single sign‐on 8 5.3. Tipus de connectivitat 8 5.4. Tipus d'accés 9 6.PERFILCOMUNICACIÓ
14 6.1. Casos d’ús 14 6.2. Missatgería HL7 intercanviada 16 7.PERFILPUBLICACIÓ
17 7.1. Visualització de continguts a LMS 17 7.2. Publicació externa, accedint a través de LMS 21 7.3. Publicació de components directament a LMS 21 7.4. Camps d’informació 24 7.5. Contingut 24 7.6. Alertes 26 8.PERFILPORTABILITAT
8.1. Flux de treball 32 32 2 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
8.2. Terminologia 33 8.3. Missatgeria HL7 utilitzada 33 9.BIBLIOGRAFIA
34 10.GLOSSARIDETERMES
35 3 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
1. Resum executiu
El marc d’interoperabilitat del Cat@Salut La Meva Salut (LMS) assegura que els sistemes
homologats externs al nucli del Canal amb els quals es comunica compleixen unes
especificacions concretes de identificació, comunicació, publicació i portabilitat.
En aquest sentit s’han definit quatre perfils per cadascuna d’aquestes característiques:




Perfil d’identificació
Perfil de comunicació
Perfil de publicació
Perfil de portabilitat
Aquests perfils queden representats en l’esquema següent:
En aquest document s’expliquen cadascun dels perfils que defineix el marc d’interoperabilitat
de LMS reunint les especificacions i requeriments que han de complir els sistemes externs
per garantir l’interoperabilitat amb LMS.
4 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
El conjunt de requeriments dels diferents perfils que en conjunt conformen el marc
d’interoperabilitat de LMS reuneixen les següents característiques:



Independència tecnològica dels sistemes homologats
Independència dels dispositius d’accés.
Ús d’estàndards. El compliment dels requisits en els diferents perfils comporta l’acreditació dels sistemes a
poder interactuar amb el Cat@Salut La Meva Salut.
2. Introducció
LMS és el punt d’accés als serveis de salut electrònics de que disposa la ciutadania. Aquest
portal està considerat com un sistema totalment modular i basat en serveis, format per un
nucli (nucli LMS) que conté el punt d’accés al sistema, els sistemes de seguretat i facilita la
visualització i integració d’informació que és gestionada pels diferents serveis, aquests
serveis poden ser interns o externs.
Per exemple, considerem com a serveis interns la HC3 i tots els serveis de publicació de
dades que facilita aquesta aplicació a LMS. Altres serveis com SIRE, es consideren
sistemes externs, que són sistemes que donen servei a la ciutadania a través de LMS,
perquè l’informació necessària per donar el servei és gestionada per ells mateixos.
Aquestes aplicacions han de complir una sèrie de requeriments que garanteixen la seguretat
i també l’interoperabilitat entre sistemes. L’interoperabilitat ens dóna la garantia
d’independència tecnològica dels sistemes externs, la connexió amb LMS, així com la
garantia en la bona gestió de les dades.
Per garantir l’interoperabilitat es defineixen un conjunts de requeriments d‘interoperabilitat
que formen part del “Marc d’ interoperabilitat de LMS”. Aquest marc d’interoperabilitat ha de
servir com a base per definir procediments de conformitat i homologació de les aplicacions
externes, facilitant d’aquesta manera la creació d’aplicacions Homologades pe LMS.
3. Objectiu
Definir un marc comú que garanteix que totes les aplicacions i sistemes homologats poden
donar servei a LMS.
Aquest marc comú ha de permetre desenvolupar criteris de conformitat i homologació dels
sistemes homologats, per garantir la integració amb LMS independentment de la tecnologia
dels proveïdors.
5 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
4. Definició del Marc d’ interoperabilitat de LMS
Definim el marc d’ interoperabilitat com el conjunt de requeriments d’interoperabilitat que ha
de tenir el Cat@Salut La Meva Salut i les aplicacions externes per poder oferir serveis al
mateix portal.
Aquests requeriments d’interoperabilitat estan agrupats en “perfils”, aquests perfils
defineixen un conjunts de requeriments que ha de tenir l’aplicació homologada per poder
donar serveis a LMS.
Els perfils definits són:
-
Identificació: Conjunt de requeriments que han de permetre garantir el “single singon” del ciutadà, entre el nucli de LMS i l‘aplicació acreditada. Aquests requeriments
estan alineats amb el Marc de Seguretat de LMS i cobreixen tots els requeriments
d’identificació inequívoca del ciutadà i del sistema homologat.
-
Comunicació: El sistema homologat pot requerir d’informació que resideix al nucli
de LMS, informació com les dades de afiliació del ciutadà o altres dades rellevants
per poder donar el servei definit al sistema homologat. El perfil de comunicació
defineix el conjunt de missatges que existeixen entre el nucli LMS i el sistema
homologat per comunicar aquestes dades.
-
Publicació: El sistema homologat publicarà una sèrie de serveis LMS. El ciutadà
disposarà de l’accés als serveis a través de LMS. El perfil de publicació defineix com
el sistema homologat facilita aquests accessos, per exemple, accedint al sistema
homologat a través d’una URL, o bé el sistema homologat facilita un resultat o
funcionalitat concreta que es pot accedir de manera directa (informe resultat, gràfica,
etc.) aquest perfil també defineix la missatgeria d’alarmes que poden generar els
sistemes homologats i que gestiona el nucli de LMS.
-
Portabilitat: Aquest perfil defineix els requeriments d’interoperabilitat que ha de tenir
un sistema homologat per garantir que l’informació que gestiona és interoperable
amb un altre sistema que dóna el mateix servei, per exemple: defineix els
requeriments d’interoperabiltat que ha de tenir un sistema de gestió de diabetis per
garantir que les dades gestionades per aquest sistema es puguin moure cap un altre
i el ciutadà les pugui utilitzar.
6 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
5. Perfil Identificació
El perfil identificació reuneix tots els requisits que han de complir les plataformes externes
per poder identificar-se al intercanviar informació amb LMS. A més, aquest perfil del marc
d’interoperabilitat també contempla aquells requeriments que permeten realitzar el singlesign-on entre LMS i la plataforma externa, de manera que l’usuari només s’identifiqui una
vegada al portal i pugui accedir a les ofertes disponibles sense necessitat de tornar a
introduir les seves dades. El compliment d’aquests requeriments garanteix la identificació de
la plataforma externa i la possibilitat de realitzar un single-sign-on entre LMS i els portals
externs.
El compliment del perfil d'identificació no requereix implementar cap servei web de
confirmació ni cap altre si únicament desitgem complir amb aquest perfil.
En aquest sentit, aquest perfil defineix un conjunt de requeriments que segueixen les
característiques pròpies del marc d’interoperabilitat del Cat@Salut La Meva Salut:



Independència tecnològica dels sistemes externs.
Independència dels dispositius d’accés.
Ús d’estàndards.
5.1. Identificació de les plataformes externes En aquest apartat es tractaran les diferents formes en què una plataforma externa
s’identifica al intercanviar informació amb LMS.
Primerament, la plataforma externa i/o oferta ha d’estar donada d’alta a LMS, de manera
que LMS ha de disposar d’unes dades bàsiques per realitzar aquesta identificació que
permetran que aquests serveis siguin visibles als usuaris del mateix portal.
En segon lloc, també es fa referència a l’apartat d’aquest marc d’interoperabilitat que facilita
la identificació de las plataformes externes al intercanviar missatges amb LMS, tant en el
perfil comunicació per intercanviar dades dels usuaris com en el intercanvi de continguts per
visualitzar en el perfil publicació.
5.1.1. Dades bàsiques per donar‐se d’alta a LMS Les plataformes externes que es vulguin identificar a LMS i ser visibles als usuaris hauran
de facilitar al servei d’administració de LMS les següents dades bàsiques per donar-se d’alta
i identificar-se al portal.




Nom de l’entitat o centre
Icona representativa l’entitat o centre
Descripció reduïda i detallada en català.
URL logo
7 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)






URL pàgina.
Paràmetres necessaris a la URL.
Descripció reduïda i detallada en castellà.
Informació addicional.
Contacte.
Dispositius d’accés disponibles.
5.1.2. Identificació del sistema extern en l’intercanvi de dades de l’usuari. Aquesta identificació es realitza a través dels missatges ADT i ACK del “Perfil Comunicació”.
S’encarreguen d‘identificar tant el pacient com els sistemes emissor i receptor de les dades.
5.1.3. Identificació del sistema extern en l’intercanvi de contingut a visualitzar. La identificació dels sistemes quan s’intercanvia contingut a visualitzar a LMS s’especifica al
“Perfil Publicació” en el punt 5.4 Camps d’informació.
5.2. Single sign‐on El “single-sign-on” és el procés pel qual és possible que un usuari s’identifiqui únicament a
LMS i quan accedeixi a les diferents ofertes o serveis ja estigui identificat.
D’aquesta manera es millora l’experiència de l’usuari i es facilita l’accés als diferents serveis.
Aquest procediment d’autentificació automàtica requereix d’un nivell d’interoperabilitat entre
LMS i el servei extern que tot seguit definirem.
El nivell d’interoperabilitat entre el servei extern i LMS permet que l’usuari només pugui
accedir al sistema homologat a través del portal, per tant, tot el nivell de seguretat d’accés
l’implementa LMS.
Si no es permet únicament l’accés a través de LMS, el sistema homologat haurà d’assolir el
mateix nivell de seguretat d’identificació que el portal per poder-se integrar. Per tant, és
altament recomanable que el sistema només permeti l’accés a través de LMS per garantir
aquesta seguretat.
5.3. Tipus de connectivitat Per garantir la seguretat de les dades d’identificació del pacient entre LMS i les plataformes
externes, s’utilitzarà el protocol segur https.
8 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
5.4. Tipus d'accés Es proporciona als usuaris la identificació i el registre a les plataformes externes mitjançant
dos mètodes clarament diferenciats:
‐
Identificació a través d’usuari i paraula de pas robusta. Els ciutadans podran
accedir a LMS a través d’un usuari i una paraula de pas robusta que serà facilitada
pels mostradors de les Unitats Proveïdores d’Atenció Primària (UP d’AP).
‐
e-DNI/Certificat digital personal. Si l’usuari utilitza aquest mètode, la plataforma
externa sempre tindrà que esperar que LMS li faci arribar les dades del mateix
(mitjançant el formulari que s’explica en el següent punt d’aquest document), figuri el
certificat digital del usuari en qüestió.
‐
Serveis de firma professional. En cas que l’usuari utilitzi aquests mètode d’accés a
LMS, al mateix moment que l’usuari vulgui enregistrar-se/accedir a una plataforma
externa, pot no facilitar un certificat digital via formulari a la plataforma externa en
qüestió.
5.4.1. Identificació a través d'usuari i paraula de pas robusta. A LMS fins ara els ciutadans i ciutadanes hi accedien si tenien un certificat digital. Aquesta
tipologia d'accés via certificat digital és una de les formes d'accés més segures actualment,
però és un sistema desconegut per a aquells menys habituals a l'ús de les tecnologies. És
per aquest motiu que s'amplia el mètode d'accés, mitjançant codi d'usuari i paraula de
pas, per fer arribar la informació clínica al màxim de ciutadans i ciutadanes possible, tot i
mantenir igualment que l'accés sigui segur.
LMS és accessible pels ciutadans i ciutadanes majors d'edat, amb targeta sanitària
individual (TSI) i un certificat digital, i des del 1 d'octubre de 2014 s'inicia una prova pilot a
34 equips d'atenció primària on es podrà demanar l'accés amb un codi d'usuari i una paraula
de pas. Podeu consultar més informació sobre els centres pilot al web
http://ticsalut.gencat.cat/ca/projectes_estrategics/canal_personal_de_salut .
9 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
Diagrama de flux d’assignació de credencials a LMS a través d’usuari i paraula de
pas:
10 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
11 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
5.4.2. Integració amb plataformes externes via e‐DNI/certificat digital personal El procés d’autenticació des de LMS a una plataforma externa acreditada s’inicia quan
l’usuari escull a quina plataforma vol accedir, aquesta selecció es realitzarà a partir d’una
interfície gràfica que tindrà un aspecte semblant al que es pot apreciar a la següent
il·lustració:
Escollida la plataforma externa acreditada a la que es vol tenir accés, LMS genera una crida
a la plataforma externa acreditada enviant un formulari (com el que es pot apreciar a la
següent il·lustració). En el mateix s’afegeixen els paràmetres CIP, DNI i certificat digital
relacionats amb l’usuari.
<form method="post" name ="formulario" action="${linkBdigital}">
<input type ="hidden" name="CIP"
value=<%=request.getSession().getAttribute("CIP")%>/> --> CIP del pacient
<input type ="hidden" name="DN" --> certificat digital
value=<%=request.getSession().getAttribute("DNI")%> />
</form>
L’esquema a seguir en aquesta integració és el següent:
12 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
LMS crea el formulari internament amb les dades que requereixi el sistema homologat per
identificar als usuaris. Aquestes dades que rebrà el sistema homologat les haurà de validar
amb el repositori “ciutadà amb accés” del que disposi la plataforma i una vegada s’ha validat
l’usuari ja podrà accedir a la plataforma a partir d’un single-sign-on.
L’integració amb LMS d’aquesta forma comporta els següents avantatges:
‐
‐
El nivell de seguretat d’accés i d’identificació als sistemes es realitza per LMS i les
plataformes externes s’estalvien d’haver d’utilitzar certificats electrònics, ja que ho
realitza el mateix portal.
El servei és accessible per a tots els ciutadans que disposin de LMS.
5.4.3. Integració amb plataformes externes via utilització dels serveis de firma professional L’única diferencia de com s’integra a LMS i plataformes externes a traves del edni/certificat digital respecte firma professional, es que a través de firma professional el
formulari que farà arribar LMS a les plataformes externes per identificar un usuari a les
13 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
mateixes, variarà en el fet de que el camp on ve informat el certifical digital (“DN”), pot vindre
buit.
*Cal recordar que el camp certificat digital (“DN”) del formulari pel que fa l’accés i integració
de LMS amb una plataforma externa via e-dni sempre vindrà informat.
6. Perfil Comunicació
Seguint l’esquema general del marc d’interoperabilitat de LMS, en aquest apartat s’explica el
perfil de comunicació, que defineix la missatgeria a través de la qual es transmetran dades
de l’usuari al sistema homologat.
L’objectiu d’aquest perfil és garantir la comunicació de les dades entre LMS i l’aplicació
acreditada, ja que es treballarà amb les dades identificadores de la ciutadania. Aquest perfil
conté tant els casos d’ús existents per aquesta comunicació, com la missatgeria implicada
entre les aplicacions.
A més a més el perfil de comunicació no només és un perfil que valida un intercanvi de
dades entre LMS sinó que preserva la seguretat de les dades clíniques del pacient.
6.1. Casos d’ús 6.1.1. Alta usuari a un sistema homologat La major part de les situacions d’intercanvi de dades tindran lloc perquè l’usuari es vol
registrar per primer cop en algun dels serveis homologats.
L’usuari sol·licita el registre en un servei homologat a través de LMS.
El servei homologat o oferta seleccionada haurà de generar un formulari de registre amb les
dades específiques requerides pel seu sistema, aquest formulari ha de ser mostrat a l’usuari
pel servei.
L’usuari respon a les dades o preguntes que hi hagi en el formulari i l’envia complimentat. El
servei seleccionat ha de validar si el formulari està complimentat correctament, en qualsevol
cas el servei s’haurà d’encarregar de comunicar a LMS el resultat d’aquesta validació.
Si la validació és correcte, a LMS, a part de retornar un missatge a l’usuari per indicar que el
procés s’ha dut a terme correctament, enviarà les dades demogràfiques del pacient al
sistema homologat, com s’indica en el diagrama, a través de missatgeria en HL7, descrit a la
secció següent.
Si les dades rebudes de LMS són correctes, el sistema homologat haurà de registrar l’usuari
al seu sistema i assegurar que quan el mateix usuari vulgui accedir de nou a través de LMS
el servei el pugui reconèixer directament. De la mateixa manera, LMS enregistrarà que
l’usuari té accés a aquella oferta en concret.
14 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
D’altra banda si la validació de les dades introduïdes per l’usuari al formulari és incorrecte, el
servei ho comunicarà a LMS i aquest informarà a l’usuari que el registre no s’ha pogut
completar correctament.
El següent esquema descriu el intercanvi efectuat en aquesta situació:
6.1.2. Alta usuari a una Unitat Proveïdora d'Atenció Primària Per aquelles Unitats Proveïdores d'Atenció Primària (UP d'AP) que desitgin validar un usuari
que es connecta a través de LMS a un servei propi de la UP d'AP no caldrà que generin cap
formulari de registre.
15 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
La primera vegada que un usuari es connecta a un servei d'una UP d'AP caldrà que LMS
validi l'usuari que prèviament haurà estat acceptat per la UP d'AP a la qual es desitja
connectar.
Per tant, LMS només permetrà l'accés al servei a aquells usuaris que pertanyen a la UP
d'AP que li pertoca i no a d'altres.
El següent esquema descriu el intercanvi efectuat en aquesta situació:
6.2. Missatgería HL7 intercanviada ADT : Dades d’informació de l’usuari
16 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
Aquest missatge serveix per transmetre les dades de l’usuari a l’aplicació acreditada, de
manera que pugui obtenir-les i emmagatzemar-ne les necessàries per al seu sistema.
Segment/Capçaleres
Descripció
MSH
PID
Capçalera Missatge
Dades del pacient
Cardinalitat
[1..1]
[1..1]
El segment PID conté les dades del pacient obtingudes del RCA.
ACK : Resposta genèrica
Aquest missatge serveix per respondre a un missatge enviat, confirmant la recepció d’aquest
i podent retornar un codi d’error.
Segment/Capçaleres
Descripció
MSH
MSA
[ERR]
Capçalera Missatge
Segment de resposta
Segment d’error
Cardinalitat
[1..1]
[1..1]
[0..1]
7. Perfil publicació
El perfil publicació reuneix tots els requisits que han de complir els sistemes externs perquè
puguin publicar continguts que es visualitzin directament al Cat@Salut La Meva Salut
o a través d’ell. El compliment d’aquests requeriments garanteix la publicació i l’accés a
l’informació que resideix als sistemes externs.
El conjunt de requisits d’aquest perfil defineix part del marc d’interoperabilitat de LMS i, per
aquest motiu, cal tenir en compte les característiques pròpies d’aquest marc:



Independència tecnològica dels sistemes externs.
Independència dels dispositius d’accés.
Ús d’estàndards.
El perfil publicació defineix el contingut que pot publicar el sistema extern a LMS i de quina
manera s’intercanvia el mateix. També s’inclou en aquest perfil les especificacions perquè
un usuari visualitzi el contingut al sistema extern a través del portal.
7.1. Visualització de continguts a LMS LMS ha de ser la plataforma organitzadora i integradora de les ofertes i/o serveis que
l’usuari fa servir de forma habitual relacionats amb la seva salut. Així, no només podrà
accedir a serveis públics, sinó que qualsevol sistema podrà publicar a LMS o permetre
17 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
l’accés a partir del portal, sempre i quan aquest sistema compleixi uns requeriments
específics i, per tant, es consideri homologat.
En aquest sentit, hi ha dues possibilitats de visualització dels continguts per part de l’usuari:
publicant el contingut al sistema extern o visualitzant components a LMS.
7.1.1 Publicació al sistema extern La publicació del contingut es realitza a la plataforma del sistema extern i l’usuari accedeix a
través de LMS. D’aquesta manera, l’usuari s’identifica a LMS i utilitzant el procés
d’autenticació “single sign-on” no s’ha de tornar a identificar al sistema extern, el que
comporta una interoperabilitat mínima entre sistemes. (Per a informació sobre l’autenticació
“single sign-on” mirar Perfil Identificació)
La situació que es produeix en aquesta forma de publicació es representa amb el següent
esquema:
Accés a l'oferta
a través de LMS
L’usuari accedeix a LMS (1), que valida la seva identificació amb les dades del RCA. Una
vegada identificat, l’usuari pot consultar les seves dades clíniques a través de la Història
Clínica Compartida de Catalunya (2). Quan l’usuari desitja utilitzar un servei hi accedeix a
partir de les diferents ofertes o sistemes homologats que hi ha disponibles. Si l’oferta
requereix d’una personalització segons l’usuari que hi accedeixi, la URL d’accés disposarà
dels paràmetres necessaris per a la identificació (3).
Per últim, la visualització de l’oferta concreta es realitza a la plataforma del sistema
homologat de forma externa a LMS (4). Així, LMS serveix de pont per accedir a l’oferta a
través del mateix.
18 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
En aquest cas, la publicació de continguts es realitza en els sistemes homologats i aquests,
a part de reunir els requisits del perfil publicació, han de complir amb el perfil
d’identificació per permetre l’autentificació “single sign-on”.
Com a exemple, el que visualitzaria l’usuari en un sistema com el de KEITO, que permet
realitzar un seguiment estadístic del pes, seria el següent:
En aquest cas, és necessari que quedi explícit que aquest sistema està connectat amb LMS
a través d’un enllaç amb el logotip del portal al sistema homologat.
7.1.2. Publicació a LMS La publicació del contingut es realitza directament a LMS. En aquest cas, LMS es comunica
de forma transparent amb el sistema extern que li facilita el contingut a visualitzar i LMS el
mostra a l’usuari. L’esquema que representa aquesta situació és el següent:
Visualitzar el
contingut a LMS
19 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
L’usuari accedeix (1) a LMS en la qual pot consultar les seves dades clíniques a través de la
Història Clínica Compartida de Catalunya (2). Quan l’usuari desitja utilitzar un servei hi
accedeix a partir de les diferents ofertes que hi ha disponibles. Si l’oferta requereix d’una
personalització segons l’usuari que hi accedeixi, la URL d’accés disposarà dels paràmetres
necessaris (3).
L’oferta envia a LMS el contingut a visualitzar que pot ser personalitzat o no segons l’usuari
(4). Per últim, LMS mostra a l’usuari el contingut rebut per l’oferta en el moment que aquest
el demana, sense que LMS emmagatzemi res, només mostrant-lo (5).
Si visualitzéssim el contingut que hi ha al sistema de KEITO d’aquesta manera, l’usuari el
veuria a dintre de LMS, com a la següent imatge:
En aquest cas, el sistema extern ha de complir els requeriments del perfil publicació que
faciliten l’intercanvi de continguts a visualitzar a LMS. Les especificacions es defineixen al
punt 2.3 Publicació de components directament a LMS.
20 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
7.2. Publicació externa, accedint a través de LMS En aquest cas, la publicació dels continguts es realitza al sistema extern, però s’accedeix a
través de LMS. Els sistemes externs que vulguin utilitzar aquest sistema de publicació a
LMS han de facilitar al portal les dades bàsiques per a la seva identificació. Aquestes dades
bàsiques es poden trobar al “Perfil Identificació”, al punt 8.1.1 Dades bàsiques per donar-se
d’alta a LMS.
En el cas que el contingut a visualitzar sigui personal i la seva publicació requereixi d’una
autentificació per part de l’usuari, el sistema extern haurà d’integrar-se amb LMS de forma
que permeti el single-sign-on, punt que s’especifica al “Perfil identificació” a l’apartat 8.2
Single sign-on.
7.2.1. Flux de treball El diagrama d’estats que mostra l’activitat quan la publicació es fa de forma externa,
accedint a través de LMS és el següent:
En aquest diagrama s’observa com l’usuari veu un servei o oferta a través de LMS, abans
s’ha de verificar si el sistema extern requereix d’autentificació de l’usuari que es realitzarà
amb el single-sign-on. Si no requerís autentificació, s’accediria directament a la URL del
sistema extern i es visualitzaria el contingut i es tractaria d’una publicació externa sense
requeriments d’autentificació.
7.3. Publicació de components directament a LMS El segon sistema de publicació a LMS és permetre que els sistemes externs puguin publicar
components a LMS i l’usuari els visualitzi directament al portal.
En aquest cas, el contingut que l’oferta o sistema extern pot publicar LMS pot ser en
diferents formats: una imatge, un document pdf, un gràfic interactiu, etc. Per no haver
d’intercanviar contingut en diferents format, s’ha establert el xml com el format estàndard
d’intercanvi, permeten que LMS visualitzi els diferents continguts que els sistemes externs
desitgin publicar.
21 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
El fet d’utilitzar el format xml per definir el contingut que ens faciliten els sistemes
homologats té els següents avantatges:




Independència tecnològica, ja que els sistemes només han d’intercanviar documents
xml i qualsevol tecnologia web permet la generació d’aquest tipus de documents.
Permet que LMS només hagi d’interpretar un únic format amb un esquema
determinat.
Permet definir una visualització dels continguts a LMS pels diferents dispositius
d’accés, el que afegeix la independència dels dispositius d’accés.
Permet afegir meta dades sobre el contingut que s’envia. 7.3.1. Flux de treball El diagrama de seqüència que mostra el flux de treball de la generació del document XML
per part dels sistemes homologats i com LMS el mostra a l’usuari, es pot veure a
continuació:
22 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
És l’usuari qui demana visualitzar una oferta a LMS i aquest fa una petició al sistema extern
perquè li faciliti el contingut a visualitzar. Aquest contingut es fa arribar a LMS mitjançant un
XML que es defineix a continuació. El Canal l’interpreta i mostra el contingut a l’usuari
perquè hi pugui interactuar a través de LMS.
7.3.2. Esquema del document xml d’intercanvi. L’arbre del xml és el següent:
Les etiquetes de l’xml es troben en anglès per a una millor internacionalització.
Un exemple senzill seria:
<?xml version="1.0" encoding="UTF-8"?>
<CPSData>
<emisor id=”idCPSSistema homologat” name=”KEITO” />
<content> <!-- Contingut que s'envia -->
<reference value="graficPes.jpeg" type=”JPEG” titol=”Pes (kg)”/>
<reference value="PesUsuari.pdf" type=”PDF” titol=”Pes de l’usuari”/>
<reference value="xlsPesUsuari.xsl" type=”XSL” titol=”Fulla de càlcul”/>
</content>
</CPSData> Quan LMS rep aquest document xml l’interpreta i a partir de la informació del mateix
realitzarà la visualització al portal, segons el dispositiu d’accés.
Tot seguit definirem cadascun dels camps del xml i els requisits que han de complir els
sistemes externs.
23 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
7.4. Camps d’informació El camp d’informació <emisor> de l’XML és aquell camp que proporciona l’informació
necessària per realitzar l’ identificació del servei extern en l’intercanvi de contingut.
<Emisor>
Aquest camp conté l’informació imprescindible que l’emissor del document xml, és a dir, el
que el servei extern ha de proporcionar per identificar-se a LMS.
Aquest camp permet dos atributs:
‐
‐
id: l’identificador facilitat per LMS al sistema extern una vegada s’ha homologat.
name: el nom llegible del servei o organització.
Exemple:
<emisor id=”idCPSSistemahomologat” name=”KEITO” />
7.5. Contingut El tipus de contingut que LMS pot rebre dels sistemes homologats és limitat i es defineix a
continuació. El camp <content> del XML permet l’intercanvi de continguts.
<content>
Aquest camp permet indicar els diferents continguts que LMS pot visualitzar dels sistemes
externs. Aquest contingut pot ser una referència d’un tipus determinat o bloc d’html
directament per a la seva visualització.
Aquests dos tipus de continguts es facilitaran mitjançant els camps:
‐ reference: permet fer referència a un document d’un tipus concret.
‐ html: facilita l’enviament d’un bloc en HTML directament disponible per ser mostrat.
Exemple:
<content> <!-- Contingut que s'envia -->
<reference value="graficPes.jpeg" type=”JPEG” titol=”Pes (kg)”/>
<reference value="PesUsuari.pdf" type=”PDF” titol=”Pes de l’usuari”/>
<reference value="xlsPesUsuari.xsl" type=”XSL” titol=”Fulla de càlcul”/>
<html><p>Els resultats mostren una recuperació en... </p></html>
</content>
A continuació es detallen els dos tipus de contingut.
24 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
<reference>
Una referència permet enllaçar a un document o imatge de forma externa. De manera que si
es tracta d’un document s’enllaçarà LMS i si és una imatge es mostrarà directament.
Aquest camp conté tres atributs:
‐
‐
‐
value: indica la URL de la referència.
type: indica el tipus de referència.
titol: indica una breu descripció de la referència.
Els diferents tipus de continguts que es permeten a LMS els podeu trobar a la següent taula
a on també s’indica l’acció que realitzarà el portal quan trobi aquesta tipologia de document.
El contingut indicat a “Tipus” es correspon amb el valor de l’atribut “type”.
Tipus
PDF
DOC
XSL
PPT
JPEG
PNG
Acció a LMS
S’enllaçarà a l’apartat de documents a LMS
S’enllaçarà a l’apartat de documents a LMS
S’enllaçarà a l’apartat de documents a LMS
S’enllaçarà a l’apartat de documents a LMS
Es visualitzarà directament a la part central de LMS.
Es visualitzarà directament a la part central de LMS.
Un exemple de l’ús del camp <reference>:
<reference value="graficPes.jpeg" type=”JPEG” titol=”Pes (kg)”/>
<reference value="PesUsuari.pdf" type=”PDF” titol=”Pes de l’usuari”/>
<reference value="xlsPesUsuari.xsl" type=”XSL” titol=”Fulla de càlcul”/>
<html>
En el camp <html> es permet afegir contingut directament en llenguatge HTML que es
mostrarà a l’usuari a LMS.
El contingut d’aquest camp s’incrustarà directament a LMS perquè l’usuari el visualitzi i
pugui interactuar amb el contingut. D’aquesta forma, el sistema homologat podrà generar
formularis o altre tipus de contingut interactiu que a LMS mostrarà.
Per assegurar la visualització correcte del contingut a LMS, aquells sistemes que vulguin
utilitzar aquest camp hauran d’especificar quin contingut enviaran perquè sigui visualitzat i si
fa ús de llibreries externes o javascript també ho haurà d’indicar.
25 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
7.6. Alertes Les alertes també s’intercanvien utilitzant xml. En aquest cas, però, es tractarà de forma
diferent, ja que els sistemes externs generadors d’alertes poden generar dos tipus d’alertes
(alerta i/o notificació). A més, hi ha dues formes de visualització a LMS, de forma síncrona o
asíncrona.
Diferenciem:
-
Les alertes són aquells avisos que es fan al usuari i es veuen a través de LMS i que,
a més a més, requereixen d’una acció per part seva i es gestionen al sistema extern.
Per tant, per eliminar l’alerta s’ha de notificar al sistema extern.
-
Les notificacions, en canvi, són informacions per l’usuari que provenen dels
sistemes externs, però no demanen d’una acció, són més de caire informatiu.
Aquestes notificacions són enviades pels sistemes externs, però la visualització es
gestiona a través de LMS.
7.6.1. Flux de treball El flux de treball pel que fa a la gestió d’alarmes és el següent:
Primerament el SAGA (Sistema Homologat Generador d’Alertes) de forma proactiva es
comunica amb LMS via web service i demana poder enviar una Alerta. Si LMS està
disponible el SAGA haurà de generar el XML corresponent que es defineix a continuació per
26 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
enviar la informació de l’alerta i LMS l’haurà d’emmagatzemar per poder ser gestionada i
mostrada quan l’usuari s’identifiqui.
L’usuari, per tant, quan s’identifiqui a LMS veurà les alarmes que el portal tingui
emmagatzemades al sistema.
7.6.2. Esquema gràfic resumit d’alarmes i notificacions L’esquema en arbre resumit del xml a on es situen les alarmes és el següent:
7.6.3. <Alert> El contingut de les alertes es defineix a dins de l’etiqueta <Alert>. A la jerarquia, l’etiqueta
<Alert> es troba a: /cpsData/Alerts/Alert
La sintaxi xml és:
<Alert>
… contingut de l’alerta.
27 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
</Alert>
Un exemple complet d’una alarma generada es pot veure a continuació:
<Alert>
<DateTime type=”start”>2011-02-07T13:00:00</DateTime>
<DateTime type=”finish”>2011-02-07T20:00:00</DateTime>
<Type>Informativa</Type>
<Description>
<text>Pateix un transtorn alimentari i requereix ajuda per a l'alimentació.</text>
<code>
<value>Requiere ayuda para la alimentación</value>
<codeSystemValue>165223004</codeSystemValue>
<codeSystem>2.16.840.1.113883.6.96</codeSystem>
<codeSystemName>SNOMED CT</codeSystemName>
</code>
</Description>
<Actions>
<Action>
<text>Esborrar</text>
<url>http://www.webServicesXEsborrar.com</url>
<params>
<param name=”idAlarma”> 4526</param>
<param name=”usuari”> d5df13adf8</param>
</params>
<Type>POST</Type>
</Action>
<Action>
<text>Més informació</text>
<url>http://www.webServicesXMes informacio.com</url>
<Type>GET</Type>
</Action>
</Actions>
</Alert>
Els nodes fills aporten la informació necessària perquè LMS pugui gestionar les alarmes i
visualitzar-les. En els següent punts s’expliquen cadascun dels nodes fills i el contingut
permès.
7.6.4. Contingut <Alert>: nodes fills Els nodes per afegir contingut a les alertes generades són els següents:
‐ <DateTime>: indica quan es produeix l’alerta i quan ha de finalitzar.
‐ <Type>: indica de quin tipus d’alerta es tracta
‐ <Description>: el contingut de l’alerta i la seva codificació si existeix.
‐ <Actions>: les accions que es poden realitzar amb l’alerta.
28 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
<DateTime>
Indica en quin moment es produeix l’alerta. Utilitza l’estàndard ISO-8601 per representar el
temps amb el format CCYY-MM-DDThh:mm:ss. S’ha d’indicar de quina data es tracta amb
l’atribut type. Els tipus permesos per alertes i notificacions són:
‐
‐
Start: la data en que s’ha generat l’alerta.
Finish: la data en què l’alerta es deixa de mostrar.
Exemple:
<DateTime type=”start”>2011-02-07T13:00:00</DateTime>
<Type>
L’etiqueta <Type> s’utilitza a diferents llocs. En aquest cas, indica de quin tipus d’alerta es
tracta. Els tipus d’alerta que poden generar-se són els següents:
 Alerta
 Notificació
Exemple:
<Type>Notificació</Type>
<Description>
Indica el contingut a mostrar a l’usuari en l’etiqueta <text>. També utilitza l’etiqueta <code>,
definida al final del document, per codificar el contingut.
Exemple:
<Description>
<text>Pateix un transtorn alimentari i requereix ayuda per a l'alimentació.</text>
<code>
<value>Requiere ayuda para la alimentación</value>
<codeSystem>165223004</codeSystem>
<codeSystemName>SNOMED CT</codeSystemName>
</code>
</Description>
<Actions>
Les accions són les diferents maneres en què l’usuari pot interaccionar amb l’alerta. Una
alerta, en aquest cas, pot generar dos tipus d’accions, esborrar l’alerta o visualitzar més
informació. Aquestes accions són necessàries quan la informació és gestionada pel sistema
extern. S’utilitza l’etiqueta <Action> per definir la url del WebService amb els paràmetres
necessaris.
29 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
Exemple:
<Actions>
<Action>
<text>Esborrar</text>
<url>http://www.webServicesXEsborrar.com</url>
<params>
<param name=”idAlarma”> 4526</param>
<param name=”usuari”> d5df13adf8</param>
</params>
<Type>POST</Type>
</Action>
<Action>
<text>Més informació</text>
<url>http://www.webServicesXMes informacio.com</url>
<Type>GET</Type>
</Action>
</Actions>
7.6.5. Etiquetes útils que s’utilitzen a diferents parts del document. <Type>
Indica de quin tipus es tracta l’etiqueta mare. Un exemple, en el cas de les alarmes:
<Type>Notificació</Type>
<Text>
L’etiqueta <text> s’utilitza per introduir text pla informatiu que en la majoria d’ocasions serà
el que es mostri a l’usuari.
S’utilitza a:
‐
‐
/cpsData/Alerts/Alert/Description
/cpsData/Alerts/Alert/Actions/Action
Exemple:
<text>Pateix un transtorn alimentari i requereix ayuda per a l'alimentació.</text>
<Code>
L’etiqueta <Code> s’utilitza per codificar el contingut. Està composat de <value>,
<codeSystemValue>, <codeSystem> i <codeSystemName> per indicar el valor i el sistema
de codificació utilitzat.
30 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
S’utilitza a:
‐
/cpsData/Alerts/Alert/Description
Exemple:
<code>
<value>Requiere ayuda para la alimentación</value>
<codeSystemValue>165223004</codeSystemValue>
<codeSystem>2.16.840.1.113883.6.96</codeSystem>
<codeSystemName>SNOMED CT</codeSystemName>
</code>
<Action>
L’etiqueta <Action> descriu una acció que es pot realitzar mitjançant webServices. Utilitza
els nodes fills següents:
‐
‐
‐
‐
<text>: per especificar què fa l’acció.
<url>: direcció url del web services
<params>: els paràmetres que requereix el sistema per realitzar l’acció.
<Type>: indica si es tracta d’una acció POST o GET.
S’utilitza a:
‐
/cpsData/Alerts/Alert/Actions
Exemple:
<Action>
<text>Esborrar</text>
<url>http://www.webServicesXEsborrar.com</url>
<params>
<param name=”idAlarma”> 4526</param>
<param name=”usuari”> d5df13adf8</param>
</params>
<Type>POST</Type>
</Action>
31 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
8. Perfil Portabilitat
A LMS és possible que dos sistemes homologats ofereixin el mateix tipus de servei. El perfil
portabilitat garanteix que la informació dels sistemes homologats que el compleixin serà
portable, de manera que l’usuari final podrà copiar les dades d’una oferta i introduir-les a una
altra. L’objectiu d’aquest document referent al perfil de portabilitat només és preveure’l, ja
que la seva definició exhaustiva està prevista més endavant.
8.1. Flux de treball Quan l’usuari final accedeixi a LMS podrà accedir a un apartat de portabilitat on es llistaran
totes les ofertes, agrupades per tipus de serveis que ofereixen. El ciutadà podrà seleccionar
un sistema homologat i moure’n les dades a un altre que ofereixi el mateix tipus de servei.
Quan l’oferta estigui composada per varis elements, l’usuari també podrà especificar de quin
vol traslladar la informació. Aquesta acció només es durà a terme sota petició de l’usuari
final.
Els sistemes homologats que compleixin el perfil de portabilitat hauran d’especificar quina
mena d’ofertes o elements faran portables, de manera que LMS pugui establir grups entre
els quals serà lícit compartir aquesta informació.
Sense tenir en compte l’autenticació de l’usuari final, el procés que es seguirà per traslladar
la informació queda presentat a l’esquema següent:
32 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
(1) L’usuari final ha seleccionat un sistema homologat d’origen, del qual extraure les dades, i
un sistema homologat de destí, al qual importar la informació.
(2) LMS envia al sistema homologat d’origen les dades del pacient i indica quina és la
informació que es demana. El sistema homologat genera un document XML amb les dades
bàsiques per identificar l’usuari final i la informació sol·licitada per LMS.
(3) El sistema homologat d’origen envia el fitxer XML a LMS.
(4) LMS envia el fitxer XML al sistema homologat de destí.
(5) El sistema homologat envia una confirmació notificant que les dades s’han
emmagatzemat correctament. En cas que hi hagi hagut un error, es notificarà a l’usuari, el
qual podrà intentar repetir la operació.
La informació que s’exportarà i importarà entre els sistemes homologats seran les dades de
l’oferta i no l’explotació de les mateixes. Aquest fet implica que no es facilitaran resums,
informes o gràfiques, sinó les dades bàsiques a partir de les quals s’han obtingut aquestes
representacions. També cal destacar que si un sistema homologat compleix el perfil de
portabilitat, ha de complir, com a prerequisit, el perfil d’autenticació i el de comunicació.
8.2. Terminologia L’intercanvi d’informació entre sistemes homologats requereix d’un estàndard semàntic que
garanteixi la interoperabilitat i, per tant, la correcta interpretació de les dades. En funció del
servei que doni la aplicació acreditada es defineix un domini sobre el qual s’ha de identificar
la terminologia internacional a utilitzar (CIM, NANDA, SNOMED, LOINC, ATC, UCUM, etc.)
8.3. Missatgeria HL7 utilitzada Per tal de transmetre l’informació d’un sistema homologat a un altre s’utilitzarà missatgeria
HL7 2.5 XML. Es definirà un únic tipus de missatge que els sistemes homologats hauran de
poder generar i interpretar i que contindrà les dades de l’oferta sol·licitades per LMS.
Els missatges que continguin l’informació a transmetre entre els sistemes homologats també
contindran les dades mínimes del pacient. Aquesta inclusió permetrà a LMS confirmar que la
informació rebuda és la relativa a l’usuari que ha sol·licitat traslladar-la.
33 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
9. Bibliografia

Framework per visualització de components externs a la Carpeta Personal de Salut.
CCI-TCM

Diapositives “Framework interoperabilitat per CPS” de Carlos Gallego (TICSalut)

API de Google Health – Documentació per enviar avisos.
o http://code.google.com/intl/esES/apis/health/docs/2.0/developers_guide_protocol.html#CreatingPosts

API de Google Health – CCRG Reference.
o http://code.google.com/intl/es-ES/apis/health/ccrg_reference.html 
Framework per visualització de components externs a la Carpeta Personal de Salut.
CCI-TCM

Diapositives “Framework interoperabilitat per CPS” de Carlos Gallego (TICSalut)

API de Google Health – Documentació per enviar avisos.
o http://code.google.com/intl/esES/apis/health/docs/2.0/developers_guide_protocol.html#CreatingPosts

API de Google Health – CCRG Reference
o http://code.google.com/intl/es-ES/apis/health/ccrg_reference.html
34 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
10. Glossari de termes
ATC (Anatomical Therapeutic Chemical): És un sistema jeràrquic de classificació de
principis actius. És un vocabulari controlat que s’utilitza com a terminologia d’interfície.
CIM (Classificació Internacional de Malalties): Sistema de classificació jeràrquic de malalties.
La darrera versió (CIM-9 Modificacions Clíniques, 7a revisió) també inclou procediments. És
un vocabulari controlat que s’utilitza com a terminologia d’interfície.
Element: Cadascun dels serveis individuals que conformen l’oferta. Si l’oferta només té un
element, es podrà afirmar que l’oferta és l’element. Una oferta ha d’estar composada de
tants elements com calgui. La diferenciació dels elements d’una oferta només serà
perceptible per l’usuari a la secció de portabilitat, on el trasllat de la informació es durà a
terme entre elements.
HC3: Història Clínica Compartida de Catalunya. És la història electrònica que agrupa el
conjunt de documents que contenen dades i informació rellevant sobre la situació i l’evolució
d’un pacient al llarg del seu procés assistencial.
HL7: Estàndard global per la interoperabilitat tecnològica d'informació, orientada a l'àmbit de
la salut.
Llista de revocats: Un certificat revocat és un certificat que no és vàlid encara que es faci
servir dins del seu període de vigència. Se li assigna la condició de suspès si la seva
vigència pot restablir-se en determinades condicions.
LOINC (Logical Observation Identifiers Names and Codes): És un estàndard que
proporciona una identificació única pels resultats de proves i observacions clíniques i de
laboratori. Es pot utilitzar com a terminologia d'interfase i de referència.
NANDA (North American Nursing Diagnosis Association codes): Classificació jeràrquica de
diagnòstics d’infermeria. És un estàndard que s’utilitza coma a terminologia d’interfase.
Oferta: És el conjunt de serveis o de funcionalitats que ofereix un mateix sistema
homologat. Les ofertes es composen d’elements. Cada sistema homologat estarà
representat al Cat@Salut La Meva Salut a través d’una oferta.
Plataforma externa: és capaç d’oferir un servei relacionat amb la salut personal al
Cat@Salut La Meva Salut. Quan una plataforma externa compleix els requisits establerts en
aquesta guia se la considera un sistema homologat.
Sistema homologat (SH): és aquella plataforma que permet oferir un servei al Cat@Salut
La Meva Salut i compleix la obligatorietat dels requisits que els criteris de conformitat d’
interoperabilitat es defineixen segons el tipus de servei o oferta que ofereixi. Segons la
tipologia del servei que s’ofereix, el sistema haurà de complir uns requeriments concrets dels
perfils del marc d’interoperabilitat i d’aquesta manera s’assolirà un nivell d’acreditació
diferent segons quins requeriments assoleixi.
35 de 36
Marc d’interoperabilitat
Cat@Salut La Meva Salut (LMS)
SIRE: La recepta electrònica a Catalunya (Rec@t) és un sistema que integra els processos
de prescripció i dispensació de la prestació farmacèutica mitjançant les TIC i el treball en
xarxa, i que estableix mecanismes que afavoreixen l'ús racional del medicament.
SNOMED
CT (Systematized Nomenclature
of Medicine-Clinical Terms):
Estàndard
semàntic internacional que consisteix en una terminologia clínica jeràrquica i que cobreix
diferents dominis de l'àmbit sanitari. Es pot utilitzar com a terminologia d'interfase i de
referència.
UCUM (Unified Code for Units of Measure): Sistema de codificació que inclou totes les
unitats de mesura que s’utilitzen a nivell internacional. Té per objectiu comunicar quantitats
amb les corresponents unitats sense ambigüitats. S’utilitza molt en els protocols d’intercanvi
de dades EDI (electronic data interchange).
XML: Tipus de fitxer que permet representar dades, de manera estructurada i relacional, en
forma d'arbre.
36 de 36