Entrades classificades amb: CDA

Formació de la línea EI que el CCI ofereix

Leer en castellano
Read It in English

Des de la línia d’Entorns d’Interoperabilitat (EI) el Centre de Competències d’Integració (CCI) ofereix un ventall de cursos per a tothom que estigui interessat en introduir-se o ampliar els seus coneixements en la integració i la interoperabilitat de sistemes així com també l’ús d’estàndards dins del sector salut. Els cursos que actualment està oferint el CCI són:

HL7 (Health Level Seven)

 

 

 

Fundada a l’any 1987, HL7 és una de les organitzacions més importants d’estàndards en missatgeria d’informàtica mèdica. La seva missió és proveir un marc complert d’estàndards relacionats per l’intercanvi, la integració, i la recuperació d’informació electrònica de salut que suporti la pràctica i la gestió clínica. Per tant, HL7 intervé específicament creant estàndards, guies i metodologies flexibles, cost-efectives que permetin la interoperabilitat entre els sistemes d’informació i l’intercanvi de registres de salut electrònics.

En aquest curs oferim introducció a l’estàndard, expliquem quines son les regles generals per definir un missatge HL7, veiem els tipus de dades intercanviades, així com els elements dels missatges, les regles de processament, etc. Oferim des de cursos introductoris a l’’estàndard fins a cursos més avançats per aprofundir en el seu ús.

CDA (Clinical Document Architecture)

El CDA és una especificació per intercanvi de documents utilitzant XML, el model d’informació de HL7 (RIM), la metodologia de HL7 V3 i vocabularis controlats (SNOMED, CIE-9-MC, LOINC, etc.). El CDA estandarditza l’estructura i la semàntica necessària per l’intercanvi de documents. Es pot utilitzar de manera simple o complexa en funció del que es requereixi, des d’enviar un document amb mínima informació contextual, fins a enviar-lo completament codificat.

En el curs es descriu el que és el CDA, quina és la seva estructura , com crear un CDA, com es valida, etc.

IHE (Integrating The Healthcare Enterprise)

IHE és una iniciativa de professionals del àmbit sanitari i de la indústria per millorar la forma en que els sistemes informàtics sanitaris comparteixen informació. IHE promou l’ús coordinat d’estàndards establerts com DICOM o HL7 per aconseguir una cura òptima del pacient.

Els sistemes desenvolupats complint IHE es comuniquen millor, són més fàcils de desenvolupar i permeten un ús més efectiu de la informació. Metges, especialistes, infermeres i administradors, entre altres, visualitzen un sistema amb el que poden transmetre informació contínuament dins d’un departament o entre ells i que permet una fàcil disponibilitat d’estar en el punt d’atenció al pacient. IHE està dissenyat per poder dur a terme aquesta visió millorant l’estat de les integracions i eliminant els impediments per una millor atenció al pacient.

El curs consisteix en una introducció del IHE, mostrar i explicar quins són els dominis i perfils que més es fan servir, així com veure com validar aplicacions a través del IHE, veure de quins recursos disposa i realitzar varis casos d’ús que ajudin a entendre l’aplicació del marc de IHE en un entorn real per integrar dispositius mèdics.

DICOM (Digital Imaging and Communications in Medicine)

DICOM és l’estàndard reconegut mundialment per l’intercanvi, maneig, emmagatzemament, impressió i transmissió d’imatges mèdiques. Una de les principals característiques, és que agrupa en un únic fitxer tota la informació. Tots els sistemes moderns de diagnòstic d’imatge (modalitat d’imatge), equips com els raigs X, ultrasons, tomografies computeritzada(CT) i MRI (Imatge magnètica de ressonància) suporten DICOM. De la mateixa manera que tots els navegadors web poden visualitzar imatge JPEG emmagatzemades en servidors llunyans, els sistemes mèdics que utilitzen DICOM poden enviar i rebre imatges DICOM i buscar-les en altres sistemes mèdics. L’èxit d’aquest estàndard es basa en la capacitat d’integrar els sistemes mèdics fabricats per diferents proveïdors.

En el curs es defineix com és l’estàndard i les parts per les quals està format, quines són les diferents classes d’informació d’objectes, quins són els seus tipus de dades, quins serveis o llibreries disposa, i veure un cas d’ús d’integració d’un dispositiu aplicant l’estàndard DICOM.

MIRTH CONNECT

És un motor d’interfície HL7 multiplataforma dissenyat especialment per permetre l’enviament bidireccional de missatges HL7 entre sistemes i aplicacions a través de múltiples mitjans de transport disponibles. Mirth Connect utilitza una arquitectura basada en canals per connectar els sistemes de HIT (Health Information Technology) i permet que els missatges es filtrin, es transformin, i s’encaminin basant-se en regles definides per l’usuari.

L’objectiu d’aquest curs és familiaritzar-se i conèixer les funcionalitats del Mirth Connect i obtenir els coneixements necessaris per poder realitzar integracions amb aquesta plataforma.

CURS D’INTEGRACIÓ DE DISPOSITIUS MÈDICS

Els dispositius mèdics han de ser capaços d’integrar-se correctament amb el HIS d’un hospital, siguin quins siguin els dispositius i els HIS a connectar. Per poder fer això, s’ha de definir un procediment estàndard, que serveixi per tots els casos. Utilitzant l’estàndard HL7 es defineix el procediment, des de que es demana la comanda per part del centre peticionari per utilitzar el dispositiu, fins que el dispositiu realitza la prova i envia els resultats al repositori.

Els objectius d’aquest curs són analitzar la problemàtica actual en la integració de dispositius mèdics, veure quins recursos existeixen i quins són més adients per resoldre aquesta problemàtica, aprendre el concepte d’interoperabilitat i saber utilitzar els diferents marcs d’interoperabilitat que existeixen, conèixer Mirth Connect a nivell d’usuari i finalment realitzar la integració d’un dispositiu mèdic.

A banda d’aquest ventall de cursos, el CCI també pot oferir cursos a mida en funció de les necessitats i objectius que es plantegin, així doncs, per rebre més informació sobre un dels cursos exposats o bé per ajustar algun curs a les seves necessitats pot posar-se en contacte al següent e-mail: mdomingo@tecnocampus.cat

Llegir en català
Read It in English

Desde la línea de Entornos de Interoperabilidad (EI) del Centro de Competencias de Integración (CCI) se ofrece un abanico de cursos para todo el mundo que esté interesado en introducirse o ampliar sus conocimientos en la integración y la interoperabilidad de sistemas así como también el uso de estándares dentro del sector salud. Los cursos que actualmente está ofreciendo el CCI son los siguientes:

HL7 (Health Level Seven)

 

 

 

Fundada el año 1987, HL7 es una de las organizaciones más importantes de estándares en mensajería de información médica. Su misión es proporcionar un marco completo de estándares relacionados por el intercambio, la integración y la recuperación de información electrónica de salud que soporte la práctica y la gestión clínica. Por lo tanto, HL7 interviene específicamente creando estándares, guías y metodologías flexibles, coste-efectivas que permitan la interoperabilidad entre los sistemas de información y el intercambio de registros de salud electrónicos.

En este curso ofrecemos una introducción al estándar, explicamos cuales son las reglas generales para definir un mensaje HL7, vemos los tipos de datos intercambiados, así como los elementos de los mensajes, las reglas de procesamiento, etc. Ofrecemos des de cursos introductorios al estándar hasta cursos más avanzados para profundizar en su uso.

CDA (Clinical Document Architecture)

El CDA es una especificación para intercambio de documentos utilizando XML, el modelo de información de HL7 (RIM), la metodología de HL7 V3 y vocabularios controlados o locales (SNOMED, ICD, LOINC, etc.). El CDA estandariza la estructura y la semántica necesaria para el intercambio de documentos. Se puede utilizar de manera simple o compleja en función de lo que se requiera, des de enviar un documento con la mínima información contextual, hasta enviarlo completamente codificado.

En el curso se describe qué es el CDA, qué es su estructura, como crear un CDA, como se valida, etc.

IHE (Integrating The Healthcare Enterprise)

IHE es una iniciativa de profesionales del ámbito sanitario y de la industria para mejorar la forma en que los sistemas informáticos sanitarios compartan información. IHE promueve el uso cordinado de estándares establecidos como DICOM o HL7 para conseguir una cura óptima del paciente.

Los sistemas desarrolados cumpliendo HE se comunican mejor, son más fáciles de desenvolupar y permiten un uso más efectivo de la información. Médicos, especialistas, infermeras y administradores, entre otros, visualizan un sistema con el que puedan transmitir información continuamente dentro de un departamento o entre ellos y que permita una fácil disponibilidad de estar en el punto de atención al paciente. IHE esta diseñado para poder llevar a cabo ésta visión mejorando el estado de las integraciones y eliminando los impedimentos para una mejor atención al paciente.

El curso consiste en una introducción del IHE, mostrar y explicar cuales son los dominios y perfiles que más se utilizan, así como ver como validar aplicaciones a través del IHE, ver de que recursos dispone y realizar varios casos de uso que ayuden a entender mejor la aplicación del marco de IHE en un entorno real para integrar dispositivos médicos.

DICOM (Digital Imaging and Communications in Medicine)

DICOM és l’estàndard reconegut mundialment per l’intercanvi, maneig, emmagatzemament, impresió i transmissió d’imatges mèdiques. Una de les principals característiques, és que agrupa en un únic fitxer tota la informació. Tots els sistemes moderns de diagnòstic d’imatge (modalitat d’imatge), equips com els rajos X, ultrasons, tomografies computeritzada(CT) i MRI (Imatge magnètica de resonància) soporten DICOM. De la mateixa manera que tots els navegadors web poden visualitzar imatge JPEG emmagatzemades en servidors llunyans, els sistemes mèdics que utilitzen DICOM poden enviar i rebre imatges DICOM i buscar-les en altres sistemes mèdics. L’èxit d’aquest estàndar es basa en la capacitat d’integrar els sistemes mèdics fabricats per diferents proveïdors.

En el curs es defineix com és l’estàndard i les parts per les quals està format, quines són les diferents classes d’informació d’objectes, quins són els seus tipus de dades, quins serveis o llibreries disposa, i veure un cas d’ús d’integració d’un dispositiu aplicant l’estàndard DICOM.

MIRTH CONNECT

Es un motor de interfaz HL7 multiplataforma diseñado especialmente para permitir el envío bidireccional de mensajes HL7 entre sistemas y aplicaciones a través de múltiples medios de transporte disponibles. Mirth Connect utiliza una arquitectura basada en canales para conectar los sistemas de HIT (Health Information Technology) y permite que los mensajes se filtren, se transformen, y se encaminen basándose en reglas definidas por el usuario.

El objetivo de este curso es familiarizarse y conocer las funcionalidades del Mirth Connect y obtener los conocimientos necesarios para poder realizar integraciones con esta plataforma.

CURSO DE INTEGRACIÓN DE DISPOSITIVOS MÉDICOS

Los dispositivos médicos han de ser capaces de integrarse correctamente con el HIS de un hospital, sean cuales sean los dispositivos y los HIS a conectar. Para poder realizar esto, se ha definido un procedimiento estándar, que sirve para todos los casos. Utilizando el estándar HL7 se define el procedimiento, des de que se pide una comanda por parte del centro peticionario para utilizar el dispositivo, hasta que el dispositivo realiza la prueba y envía los resultados al repositorio.

Los objetivos consisten en analizar la problemática actual en la integración de dispositivos médicos, ver que recursos existen y cuales son más adecuados para solventar dicha problemática, aprender el concepto de interoperabilidad y saber utilizar los diferentes marcos de interoperabilidad que existen, conocer Mirth Connect a nivel de usuario y finalmente realizar la integración de un dispositivo médico.

Dejando a lado este abanico de cursos, el CCI també ofrece cursos a medida en función de las necesidades y objetivos que se planteen. Para recibir más información sobre uno de los cursos expuestos o bien para ajustar algún curso a sus necesidades puede ponerse en contacto con el siguiente e-mail: mdomingo@tecnocampus.cat

Llegir en català
Leer en castellano

From Interoperability Environment (IE) line the Integration and Competency Centre (ICC) offers a big spectrum training courses for everybody interested in deepening or enlarging their knowledge in the integration and interoperability systems or using standards within healthcare sector. CCI is currently offering the following training courses:

HL7 (Health Level Seven)

 

 

 

Founded in 1987, HL7 is one of the most main organizations of standard in medical information messaging. Its mission is to provide a complete framework of standards related to exchange, integrate and the electronic healthcare information recovering that supports the practice and clinical management. Therefore HL7 specifically involves creating standards, guidelines and flexible methodologies, cost-effectives that enable to the interoperability between the information systems and electronic health records exchanging.

This course offers an introduction of standard, we explain which rules define a HL7 message, and we’ll see which kind of exchanging data and either the message elements or procedures rules. We offer several training courses from introductory courses to more developed courses.

CDA (Clinical Document Architecture)

CDA is an specification to exchange reports using XML, HL7 (RIM) information model, HL7 V3 methodology and controlled or local vocabularies (SNOMED, ICD, LOINC,…). The CDA standardizes the structure and semantic needed to exchange reports. It could be used in a simple or complex way; it depends on what one want, from sending a report with the minimum contextual information since sending it completely codified.

In this training course we describe what CDA is and which structure it have and how we can create and validate CDA.

IHE (Integrating The Healthcare Enterprise)

IHE is a professional initiative in the healthcare and industry sector to enhance the way in which informatic health systems share the information. IHE promotes using standards that are stablished as DICOm or HL7 to achieve an optimal cure of the patient.

The developed systems fulfilling IHE are communicated better, they are easier to develop and they enable more effective use of information. Phisicians, specialists, nurses and administrators, inter alia, they displayed a system that can broadcast information continuously within a department or between them and it enable an easy availabililty to be at the point of patient care. IHE are designed to carry out this vision enhancing, the integration state and deleting impediments to better patient care.

This training course consists with introduction of IHE, show and explain which domains and profiles most commonly used, as well as viewing how validate the application through IHE and which resources are available and performing use cases to aid understand better the IHE applications in a real environment to integrate medical devices.

DICOM (Digital Imaging and Communications in Medicine)

DICOM is a standards that is world-renowned for exchange, management, store, print and broadcast medical images. One of the main features it is joins in a unique file all the information. All currently systems of diagnostic imaging, equipment such as X-ray, ultrasound, CT and MRI (Medical Resonance Imaging) support DICOM. In the same way all web navegators can display JPEG imatge, the medical systems use DICOM to send and recive DICOM images. The success of this standard is based on the capacity to integrate the medical manufactured systems in differents suppliers.

This course defines how is the standard and in which parts is composed, which kind of information objects has and which kind of data is, which services and libraries has and finaly, we’ll see several use cases regarding integration of diveces using the DICOM standard.

MIRTH CONNECT

Is an interface engine HL7 multiplatform specially designed to enable sending bidirectional HL7 message between systems and applications through multiple transportation available. Mirth Connect uses an architecture based on channels to connect the HIT (Health Information Technology) systems and allows messages to be filtered, transformed and routed based on user-defined rules.

The aim of this training course is familiarize and know the functionalities of Mirth Connect and to obtain the knowledge needed to perform integration on this platform.

COURSE OF MEDICAL DEVICE INTEGRATION

The medical devices must be able to integrate properly the HIS from a hospital, regardless of the devices and connecting HIS . To do this, we have defined a standard procedure, used for all cases. Using the HL7 standard defines the procedure, they seeks commands from the petitioner to use the device until the device performs the test and send the results to the repository.

The objectives are to analyze the current problems in the integration of medical devices, see what resources are available and which are best suited to solve this problem, learning the concept of interoperability and how to use the different interoperability frameworks that exist, meet at Mirth Connect user and finally perform the integration of a medical device.

Leaving aside this range of courses, ITC offers courses as a function of the needs and goals that arise. For more information on one of these courses you can contact us in the following e- mail: mdomingo@tecnocampus.cat

Jornada LOINC

Leer en castellano

El passat dia 11 de juny es va realitzar la jornada sobre la terminologia de laboratori LOINC (Logical Observation Identifiers Names and Codes) a Barcelona (auditori edifici França al Passeig de la Circumval·lació). La sessió començà amb una benvinguda a càrrec d’en Francesc García Cuyàs (Coordinador General de les TIC del Departament de Salut i Director de la Fundació TicSalut), qui va donar pas a la intervenció de Carlos Gallego (Responsable de l’Oficina d’Estàndards i Interoperabilitat de la Fundació TicSalut) i Elisenda Carrau (Responsable de l’Àrea Funcional de l’iSalut). En aquesta primera part de l’esdeveniment es va fer una introducció a l’estàndard internacional LOINC i al seu ús a l’HC3 (Història Clínica Compartida de Catalunya):

LOINC és un vocabulari controlat amb més de 71.000 elements que s’utilitza principalment en l’àmbit de laboratori, però que a més de les proves també conté altres observacions clíniques, tipologies de documents, noms de seccions d’informes, etc. A l’HC3 s’ha contemplat l’ús de 280 proves comparables de laboratori amb les quals es cobreix la major part de l’activitat. Els informes de laboratori a HC3 s’han de començar a publicar de manera estructurada, utilitzant l’estàndard d’HL7 (Health Level Seven) CDA (Clinical Document Architecture) i la terminologia LOINC. Aquest requeriment permetrà desplegar el servei de proves comparables, gràcies al qual es poden consultar els resultats de laboratori d’un ciutadà per veure’n l’evolució d’una manera ràpida i directa. La imatge següent mostra una captura del visor d’HC3 on es poden veure els resultats de varis informes de laboratori i com es mostren els valors de les diferents proves comparables:

La publicació estructurada també permet consultar l’informe en format pdf, però afegeix la capacitat de comparar els resultats directament i agrupats per proves, garantint l’intercanvi coherent entre sistemes d’informació a diferents nivells assistencials. L’objectiu fixat per aquest 2013 és que s’arribin a publicar el 80% dels informes de laboratori en el nou format estructurat. L’HC3 ja està preparada per incorporar aquests informes i mostrar els resultats comparables.
També es requereix la publicació estructurada dels informes d’Anatomia Patològica i d’espirometria (utilitzant com a vocabulari SNOMED CT). Per transmetre les unitats de mesura es va indicar que l’estàndard a utilitzar és UCUM (Unified Code for Units of Measure).
La documentació sobre els informes estructurats i els serveis web de l’HC3 es poden consultar al portal web de documentació de l’HC3.
El catàleg amb les 280 proves comparables que s’utilitzen a l’HC3 es pot trobar al web de l’OFSTI, a la plana de recursos LOINC: http://www.ticsalut.cat/estandards/terminologia/recursos/loinc/, és el catàleg reduït de proves de Laboratori, LOINC (Catàleg HC3), versió del 26/10/2011.

La segona part de la sessió es va iniciar amb la participació de Ginger A. Baker (Chief of US Business Development de BITAC als EEUU) que realitzà una intervenció sobre LOINC a l’entorn del Meaningful Use. En aquest sentit es va explicar que el cost de la sanitat ha augmentat molt als EEUU degut, en bona part, a la manca d’informació que implica duplicitat de proves, actuacions innecessàries o inadequades, pràctiques obsoletes, etc. Per resoldre aquesta situació s’han emprès varies accions legislatives, entre elles les relatives a la interoperabilitat semàntica i a l’ús de la informació de manera que esdevingui realment útil i estigui disponible en temps real. Aquesta visió és el que es coneix com a Meaningful Use, en la qual els proveïdors de salut que reben pagaments del govern han de complir una sèrie de requeriments. En l’àmbit del laboratori, la terminologia de referència a utilitzar és LOINC. Malgrat fa varis anys que es va iniciar el procés de transformació descrit, encara queda molta feina per fer. Cal seguir treballant per fer entendre la importància de la interoperabilitat semàntica en general i el paper que hi juguen estàndards com LOINC o SNOMED CT. Un altre repte que es va destacar és aconseguir la implicació dels professionals assistencials i fer-los veure el valor afegit de la integració dels sistemes i de la interoperabilitat de la informació, tant en l’atenció als pacients com en la gestió dels serveis.

La jornada finalitzà amb el bloc d’experiències, format per les intervencions de Toni Mas (CEO de BITAC) i Gloria Soria (Adjunta a gerència del Laboratori de Referència de Catalunya, LRC):

Per presentar en més detall la terminologia LOINC es van explicar els sis eixos que la composen i que, combinats, descriuen cada prova de laboratori: component, propietat, temps, sistema, escala i mètode. També es va destacar que LOINC té varies jerarquies (o classes), perfils i que dels més de 71.000 elements que el composen i que estan identificats de manera única, uns 47.000 són de laboratori, la resta corresponen a altres àmbits complementaris. La presentació de BITAC finalitzà amb algunes recomanacions alhora de fer el mapeig entre catàlegs locals i LOINC, servei que l’empresa ofereix:

  • El mapeig per proximitat és un error, si un element no existeix a LOINC es pot sol·licitar la seva inclusió, però no s’aconsella mapejar-lo amb el que més se li assembla.
  • És imprescindible comptar amb la participació d’experts en el domini per fer el mapeig, ja que hi ha elements que semblen iguals però no ho són.
  • Els mapejos s’han de fer sempre a l’últim nivell de granularitat. És possible escalar de més nivell a menys però no a la inversa.
  • Sovint s’utilitza SNOMED CT per complementar LOINC (p.ex. prova de laboratori en LOINC i diagnòstic associat en SNOMED CT).
  • Quan es fa el mapeig del catàleg local a LOINC es solen descobrir proves duplicades, obsoletes, incongruents, etc. de manera que és una bona oportunitat per millorar el catàleg.

El bloc acabà amb l’experiència d’implantació de LOINC al LRC, des d’on, amb la participació de BITAC, es va mapejar el catàleg local a LOINC i es va implantar al seu sistema d’informació. En aquesta experiència es van reafirmar les recomanacions prèviament vistes i es va destacar l’ús de SNOMED CT en combinació amb LOINC. El manteniment del mapeig es du a terme des del LRC i actualment poden representar la major part de les proves que fan.

La clausura de la jornada es va realitzar per part de Maria Rovira (Oficina d’Estàndards i Interoperabilitat de la Fundació TicSalut, iSalut).

Al següent enllaç es pot consultar l’agenda de la sessió: programa.

Llegir en català

El pasado día 11 de junio se realizó la jornada sobre la terminología de laboratorio LOINC (Logical Observation Identifiers Names and Codes) en Barcelona (auditorio edificio França en el Passeig de la Circumval·lació). La sesión empezó con una bienvenida a cargo de Francesc García Cuyàs (Coordinador General de les TIC del Dpt. Salut i Director Fundació TicSalut), quin dio paso a la intervención de Carlos Gallego (Responsable de la Oficina d’Estàndards i Interoperabilitat de la Fundació TicSalut) y Elisenda Carrau (Responsable del Área Funcional del iSalut). En esta primera parte del evento se hizo una introducción al estándar internacional LOINC y su uso en la HC3 (Historia Clínica Compartida de Catalunya):

LOINC es un vocabulario controlado con más de 71.000 elementos que se utiliza principalmente para el ámbito de laboratorio, pero que además de las pruebas también contiene otras observaciones clínicas, tipologías de documentos, nombres de secciones de informes, etc. En la HC3 se ha contemplado el uso de 280 pruebas comparables de laboratorio con las que se cubre la mayor parte de la actividad. Los informes de laboratorio en HC3 se tienen que empezar a publicar de manera estructurada, utilizando el estándar de HL7 (Health Level Seven) CDA (Clinical Document Architecture) y la terminología LOINC. Este requerimiento permitirá desplegar el servicio de pruebas comparables, gracias al cual se pueden consultar los resultados de laboratorio de un ciudadano para ver su evolución de una manera rápida y directa. La imagen siguiente muestra una captura del visor de HC3 donde se pueden ver los resultados de varios informes de laboratorio y cómo se muestran los valores de las diferentes pruebas comparables:

La publicación estructurada también permite consultar el informe en formato pdf, pero añade la capacidad de comparar los resultados directamente y agrupados por pruebas, garantizando el intercambio coherente entre sistemas de información a diferentes niveles asistenciales. El objetivo fijado para este 2013 es que se lleguen a publicar el 80% de los informes de laboratorio en el nuevo formato estructurado. La HC3 ya está preparada para incorporar estos informes y mostrar los resultados comparables.
También se requiere la publicación estructurada de los informes de Anatomía Patológica y de espirometría (usando el vocabulario SNOMED CT). Para transmitir las unidades de medida se indicó que el estándar a utilizar es UCUM (Unified Code for Units of Measure).
La documentación sobre los informes estructurados y los servicios web de HC3 se pueden consultar en el portal web de documentación de la HC3.
El catálogo con las 280 pruebas comparables que se usan en HC3 se puede encontrar en la web de la OFSTI, en la página de recursos LOINC: http://www.ticsalut.cat/estandards/terminologia/recursos/loinc/, es el catálogo reducido de pruebas de laboratorio LOINC (Catálogo HC3), versión del 26/10/2011.

La segunda parte de la sesión se inició con la participación de Ginger A. Baker (Chief of US Business Development de BITAC en los EEUU), que realizó una intervención sobre LOINC en el entorno del Meaningful Use. En este sentido se explicó que el coste de la sanidad en los EEUU ha aumentado mucho, debido en parte a la falta de información, que implica duplicidad de pruebas, actuaciones innecesarias o inadecuadas, prácticas obsoletas, etc. Para resolver esta situación se han emprendido varias acciones legislativas, entre ellas las relativas a la interoperabilidad semánticas i al uso de la información de manera que sea verdaderamente útil y esté disponible en tiempo real. Esta visión es la que se conoce como Meaningful Use, en la cual los proveedores de salud que reciben pagos del gobierno tienen que cumplir una serie de requisitos. En el ámbito del laboratorio, la terminología de referencia a utilizar es LOINC. A pesar de que hace varios años que se inició el proceso de transformación descrito, aún queda mucho trabajo por hacer. Es necesario seguir trabajando para hacer entender la importancia de la interoperabilidad semántica en general, y el papel que juegan estándares como SNOMED CT o LOINC. Otro reto que se destacó es conseguir la implicación de los profesionales asistenciales y hacerles ver el valor añadido de la integración de los sistemas y la interoperabilidad de la información, tanto en la atención a los pacientes como en la gestión de los servicios.

La jornada finalizó con el bloque de experiencias, formado por las intervenciones de Toni Mas (CEO de BITAC) y Gloria Soria (Adjunta a gerència del Laboratori de Referència de Catalunya, LRC):
Para presentar en más detalle la terminología LOINC se explicaron los seis ejes que la componen y que, combinados, describen cada prueba de laboratorio: componente, propiedad, tiempo, sistema, escala y método. También se destacó que LOINC tiene varias jerarquías (o clases), perfiles y que de los más de 71.000 elementos que lo componen y que están identificados de manera única, unos 47.000 son de laboratorio, el resto corresponden a otros ámbitos complementarios. La presentación de BITAC finalizó con algunas recomendaciones a la hora de hacer el mapeo entre catálogos locales y LOINC, servicio que la empresa ofrece:

  • El mapeo por proximidad es un error, si un elemento no existe en LOINC se puede solicitar su inclusión pero no se aconseja mapearlo al que parezca más similar.
  • Es imprescindible contar con la participación de expertos en el dominio para realizar el mapeo, ya que hay elementos que se parecen mucho pero son distintos.
  • Los mapeos de tienen que hacer siempre al último nivel de granularidad. Es posible escalar de más nivel de detalle a menos, pero no al revés.
  • Frecuentemente se utiliza SNOMED CT para complementar LOINC (p.ej. prueba de laboratorio con LOINC y diagnóstico asociado en SNOMED CT).
  • Cuando se hace el mapeo del catálogo local a LOINC se suelen descubrir pruebas duplicadas, incongruentes, obsoletas, etc. de manera que es una buena oportunidad para mejorar el catálogo.

El bloque acabó con la experiencia de implantación de LOINC en el LRC, desde el cual, con la participación de BITAC, se mapeó el catálogo local a LOINC y se implantó en su sistema de información. En esta experiencia se reafirmaron las recomendaciones previamente vistas y se destacó el uso de SNOMED CT en combinación con LOINC. El mantenimiento del mapeo se lleva a cabo des del LRC y actualmente pueden representar la mayor parte de las pruebas que realizan.

La clausura de la jornada se realizó por parte de Maria Rovira (Oficina d’Estàndards i Interoperabilitat de la Fundación TicSalut, iSalut).

En el siguiente enlace se puede consultar la agenda de la sesión: programa.

This post is only available in Catalan and Spanish:
Llegir en català (Read it in Catalan)
Leer en castellano (Read it in Spanish)

FHIR, la nova especificació HL7 (Part IV)

Leer en castellano 

Des del CCI varem començar parlant sobre la nova especificació FHIR, ara seguirem amb la continuació en aquesta quarta i última entrega la qual parlarem sobre les extensions, les decripcions narratives i les referències internes dels recursos.

Extensions
Aquesta especificació d’intercanvi com es FHIR es basa en els requisits comuns d’acceptació general a tot l’àmbit de la salut – que abasta moltes jurisdiccions, dominis i diferents enfocaments funcionals. Com a tal, és comú per les implementacions específiques que tinguin requisits vàlids no s’incloguin directament en aquesta memòria descriptiva. La incorporació de tots aquests requisits faria de FHIR una especificació molt molesta i difícil d’implementar. En canvi, aquesta especificació espera que aquests diferents requisits addicionals s’implementin com a extensions.

Com a tal, és l’extensibilitat una part fonamental del disseny d’aquesta especificació. Cada element en un recurs pot tenir elements secundaris d’extensió per representar la informació addicional que no és part de la definició bàsica del recurs. Aplicacions compatibles no se’ls permet rebutjar els recursos, ja que contenen extensions, encara que puguin necessitar haver de rebutjar-los a causa dels continguts específics de les extensions.

Cal tenir en compte que, a diferència de moltes altres especificacions, no pot haver-hi un estigma associat amb l’ús d’extensions per qualsevol aplicació, projecte o estàndard – sense importar la institució o la jurisdicció que utilitza o defineix les extensions. L’ús d’extensions és el que permet a l’especificació FHIR retenir un nucli de simplicitat per a tothom.

Per tal de fer que l’ús d’extensions sigui segur i manejable, hi ha una legislació estricta aplicada a la definició i l’ús de les extensions. Encara que qualsevol implementador se li permet definir una extensió, hi ha una sèrie de requisits que s’han de complir en el marc de la definició de l’extensió.

Extensions a un element
Cada element en un recurs inclou un element opcional “extensió” que es pot presentar qualsevol nombre de vegades en l’element. L’element d’extensió apareix com el primer fill, abans de qualsevol altre element secundari definit. Aquest és el model de contingut de l’extensió que apareix en cada recurs:

<[name] xmlns=”http://hl7.org/fhir”>
<url value=”[uri]”/><!– 1..1 Identifica el significat de l’extensió –>
<isModifier value=”[boolean]”/><!– 0..1 Si l’extensió modifica altres elements/extensions –>
<value[x]><!– 0..1 Valor de la extensió –></value[x]>
<extension><!– 0..* Extension Valors niats per l’extensió  –></extension>
</[name]>

Exemple, extensió d’un pacient amb un opt-in-status d’un assaig clínic amb 3 camps: estat, data de l’enregistrament i la persona que va fer el registre.

<Patient>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status” />
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-code” />
<valueCode value=”unsure” />
</extension>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-date” />
<valueDate value=”2009-03-14″ />
</extension>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-who” />
<valueResourceReference>
<type value=”Practitioner” />
<reference value=”../Practitioner/@example” />
</valueResourceReference>
</extension>
</extension>
<!– other data for patient –>
</Patient>

Descripció Narrativa
A cada recurs s’inclourà una descripció llegible que contindrà un resum del mateix recurs, i pot ser usat per representar el contingut del recurs a un ésser humà. La narració no necessita codificar totes les dades estructurades, però és necessària per contenir el detall suficient perquè sigui “clínicament segura” per a un ésser humà que acaba de llegir la descripció. Les definicions de recursos poden definir quin serà el contingut que ha de ser representat en la descripció narrativa per garantir la seguretat clínica.
A la descripció narrativa per un recurs s’hi permet que hi contingui informació addicional que no estigui a les dades estructurades prèviament definides, incloent el contingut editat per una persona. Aquesta informació addicional per això ha d’estar en l’àmbit de la definició del recurs. En entorns petits i tancats de socis comercials, poder no hi necessitat d’un text narratiu. En aquests casos, la implementació es permesa omplint la descripció amb el text equivalent a “[Nom de recurs] No hi ha text llegible proporcionat per aquest recurs” – en l’idioma apropiat. Els implementadors han de tenir en compte que es molt probable que els entorns petits i tancats de socis comercials els obrin durant la vida útil dels recursos que ells defineixen.

La narració és un fragment xhtml, que també inclou les imatges en el seu cas:

<[name] xmlns=”http://hl7.org/fhir”>
<status value=”[code]”/><!– 1..1 generated | extensions | additional –>
<div xmlns=”http://www.w3.org/1999/xhtml”< <!– Limited xhtml content< –> </div>
<blob>  <!– 0..* Binary content referenced in xhtml –>
<mimeType value=”[code]”/><!– 1..1 Mime type of binary attachment –>
<content value=”[base64Binary]”/><!– 1..1 base64 data for attachment –>
</blob>
</[name]>

El contingut de l’element div és un fragment d’XHTML que conté només els elements de format HTML bàsics descrits en els capítols 7-11 (excepte la secció 4 del capítol 9) i 15 de la norma HTML 4.0, els elements <a> (nom o href), les imatges i els atributs d’estil que conté internament. El contingut XHTML no ha de contenir un head, un element body, les referències externes de fulls d’estil, scripts, formularis, base / enllaç / XLink, frames, iframes i objectes. L’element div ha de tenir algun contingut que no estigui en blanc.

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>Aquest es un exemple amb només text pla</div>
</narrative>

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>
<p>
Aquest es un <i>exemple</i> amb algun <b>xhtml</b> format.
</p>
</div>
</narrative>

La porció interna del contingut div s’utilitza sovint per a la propietat innerHTML en un navegador. Per tal de simplificar el processament, la narració es codificarà de manera que el contingut entre el primer “>” i l’últim “<” caràcters és el contingut de l’element <div>.
Cal tenir en compte que l’XHTML es troba contingut en un XML, per la qual cosa no hi ha suport per a les entitats en HTML com per exemple &nbsp; o &copy; etc. Per arreglar-ho es farà servir caràcters Unicode al seu lloc. A l’exemple anterior &#160; substituiria &nbsp;
El contingut narratiu ha d’estar en l’idioma del recurs, però no hi ha raó per esperar que aquest tipus d’eines HTML entenguin l’element de llenguatge del recurs. Per aquesta raó, també s’ha d’utilitzar un atribut lang al <div> (i veure la nota en l’especificació d’HTML 5 sobre l’ús de la llengua).

Les referències “image source” poden ser una referència local dins del recurs:
<img src=”#a5″/>

Aquesta és una referència interna a un atribut id d’un element al mateix recurs, ja sigui en els arxius adjunts binaris en l’element de text directament, o un element de tipus “Annex”.

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>
<p>
<img src=”#a1″/>.
</p>
</div>
<blob id=”a1″>
<mimeType value=”image/png” />
<content value=”MEKH….SD/Z” />
</blob>
</narrative>

Atès que la presència de les imatges que no formen part dels recursos no està garantit, imatges que són una part essencial de la narració sempre han de ser incorporades com aquest.
El fragment XHTML en la descripció narrativa pot ser d’estil usant CSS de forma normal, amb una barreja de classes, identificadors i elements d’estil en línia. S’aplicaran fulls d’estil CSS específics  al XHTML quan s’extregui aquesta narració des del recurs de què es mostrarà a un ésser humà per crear la presentació desitjada en el context d’ús.

Els autors poden fixar els següents aspectes d’estil del contingut:
negreta, cursiva, subratllat, ratllat, color de la font, família, la mida, color de fons, alineació del text,  interpretació dels espais en blanc, llista de format de número ordenat (ja que pot ser contemplada en el text).
Aquestes propietats d’estil s’especifiquen en línia utilitzant l’atribut d’estil. Si hi ha un element HTML equivalent, com “i”, o “pre”, es poden utilitzar en el seu lloc però cal tenir en compte que alguns d’aquests elements s’han desaprovat (estan en estat deprecated) en HTML 4 i no han de ser utilitzats en la descripció narrativa XHTML (com “o”, i “font”).
Es requereixen sistemes de representació per respectar qualsevol d’aquests estils de reproducció quan s’especifiquen a XHTML, encara que es permet la interpretació apropiada (per exemple, una pantalla de baix contrast per diferents contextos, com una cambra fosca, o en una pantalla d’alt contrast per als discapacitats visuals poden ajustar els colors en conseqüència) .
Els autors poden especificar estils addicionals i les propietats d’estil com s’especifica en l’especificació CSS, però aquestes són extensions d’aquesta especificació i aquests no estan obligats a complir amb ells. Cal tenir en compte, però, les normes addicionals de l’estil que s’apliquen en el context dels documents.

Referències internes
Hi ha 4 casos on els elements dins d’un recurs fan referència a un altre:

  • Dins d’un tipus de dades “CodeableConcept” per identificar la codificació primària.
  • Una referència <img src = “”/> dins la descripció narrativa, en referència a una imatge que es troba en el recurs.
  • Entre els elements de la narrativa i elements de dades estructurades.
  • Entre un ResourceReference i un recurs contingut.

Aquestes referències es fan usant un enfoc basat en un id/idRef, on un element d’origen indica que té el mateix contingut que l’element de destinació. L’element de destinació té un atribut “id” que ha de tenir un valor únic en el recurs respecte a qualsevol altre atribut id. L’atribut “id” no es troba en cap espai de noms (namespace). La referència de l’element d’origen ha de fer referència a un atribut en el mateix recurs (o, per a un CodeableConcept, dins del mateix tipus de dades).

<example>
<target id=”a1″>
<child>…</child>
</target>
<– other stuff –>
<source idref=”a1″>
</example>

En un sol recurs, això funciona com xml: id/idRef, però hi ha una diferència important: la singularitat i l’abast de la resolució d’aquestes referències d’identificació és en el recurs que els conté. Si múltiples recursos es combinen en una sola peça XML, com ara un àtom d’alimentació, valors duplicats poden ocórrer entre els recursos. Això ha de ser gestionat per aplicacions que llegeixen els recursos.
Cal destacar que totes les referències entre els elements XHTML i els elements de dades s’han d’entendre per establir una “deriva de” relació, on el contingut derivat (ja sigui text o dades) es refereixi al contingut d’origen. S’ha de tenir en compte que això significa que algunes referències poden ser referències a termini (referències a elements definides més endavant a la instancia).

Fins aqui la última entrega del post sobre FHIR.

Llegir en català 

Desde el CCI empezamos hablando sobre la nueva especificación FHIR, ahora vamos a seguir con la continuación en esta cuarta y última entrega en la que hablaremos sobre las extensiones, las decripciones narrativas y las referencias internas de los recursos.

Extensiones
Esta especificación de intercambio como es FHIR se basa en los requisitos comunes de aceptación general en todo el ámbito de la salud – que abarca muchas jurisdicciones, dominios y diferentes enfoques funcionales. Como tal, es común para las implementaciones específicas que tengan requisitos válidos no se incluyan directamente en esta memoria descriptiva. La incorporación de todos estos requisitos haría de FHIR una especificación muy molesta y difícil de implementar. En cambio, esta especificación espera que estos diferentes requisitos adicionales se implementen como extensiones.

Como tal, es la extensibilidad una parte fundamental del diseño de esta especificación. Cada elemento en un recurso puede tener elementos secundarios de extensión para representar la información adicional que no es parte de la definición básica del recurso. Aplicaciones compatibles no se les permite rechazar los recursos, ya que contienen extensiones, aunque puedan necesitar tener que rechazarlos debido a los contenidos específicos de las extensiones.

Hay que tener en cuenta que, a diferencia de muchas otras especificaciones, no puede haber un estigma asociado con el uso de extensiones para cualquier aplicación, proyecto o estándar – sin importar la institución o la jurisdicción que utiliza o define las extensiones. El uso de extensiones es el que permite la especificación FHIR retener un núcleo de simplicidad para todos.

Para hacer que el uso de extensiones sea seguro y manejable, hay una legislación estricta aplicada a la definición y el uso de las extensiones. Aunque cualquier implementador se le permite definir una extensión, hay una serie de requisitos que se deben cumplir en el marco de la definición de la extensión.

Extensiones a un elemento
Cada elemento en un recurso incluye un elemento opcional “extensión” que se puede presentar cualquier número de veces en el elemento. El elemento de extensión aparece como el primer hijo, antes de cualquier otro elemento secundario definido. Este es el modelo de contenido de la extensión que aparece en cada recurso:

<[name] xmlns=”http://hl7.org/fhir”>
<url value=”[uri]”/><!– 1..1 Identifica el significado de la extensión –>
<isModifier value=”[boolean]”/><!– 0..1 Indica si la extensión modifica otros elementos/extensiones –>
<value[x]><!– 0..1 Valor de la extensión –></value[x]>
<extension><!– 0..* Extension Valores anidados por la extensión –></extension>
</[name]>

Ejemplo, extensión de un paciente con un opt-in-status de un ensayo clínico con 3 campos: estado, fecha del registro y la persona que hizo el registro.

<Patient>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status” />
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-code” />
<valueCode value=”unsure” />
</extension>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-date” />
<valueDate value=”2009-03-14″ />
</extension>
<extension>
<url value=”http://acme.org/fhir/profiles/@main#trial-status-who” />
<valueResourceReference>
<type value=”Practitioner” />
<reference value=”../Practitioner/@example” />
</valueResourceReference>
</extension>
</extension>
<!– other data for patient –>
</Patient>

Descripción Narrativa
En cada recurso se incluirá una descripción legible que contendrá un resumen del mismo recurso, y puede ser usado para representar el contenido del recurso a un ser humano. La narración no necesita codificar todos los datos estructurados, pero es necesaria para contener el detalle suficiente para que sea “clínicamente segura” para un ser humano que acaba de leer la descripción. Las definiciones de recursos pueden definir cuál será el contenido que debe ser representado en la descripción narrativa para garantizar la seguridad clínica.
En la descripción narrativa para un recurso se permite que contenga información adicional que no esté en los datos estructurados previamente definidos, incluyendo el contenido editado por una persona. Esta información adicional para ello debe estar en el ámbito de la definición del recurso. En entornos pequeños y cerrados de socios comerciales, quizá no hay necesidad de un texto narrativo. En estos casos, la implementación se permite llenando la descripción con el texto equivalente a “[Nombre de recurso] No hay texto legible proporcionado por este recurso” – en el idioma apropiado. Los implementadores deben tener en cuenta que es muy probable que los entornos pequeños y cerrados de socios comerciales les abran durante la vida útil de los recursos que ellos definen.

La narración es un fragmento xhtml, que también incluye las imágenes en su caso:

<[name] xmlns=”http://hl7.org/fhir”>
<status value=”[code]”/><!– 1..1 generated | extensions | additional –>
<div xmlns=”http://www.w3.org/1999/xhtml”< <!– Limited xhtml content< –> </div>
<blob> <!– 0..* Binary content referenced in xhtml –>
<mimeType value=”[code]”/><!– 1..1 Mime type of binary attachment –>
<content value=”[base64Binary]”/><!– 1..1 base64 data for attachment –>
</blob>
</[name]>

El contenido del elemento div es un fragmento de XHTML que contiene sólo los elementos de formato HTML básicos descritos en los capítulos 7-11 (excepto la sección 4 del capítulo 9) y 15 de la norma HTML 4.0, los elementos <a> (nombre o href), las imágenes y los atributos de estilo que contiene internamente. El contenido XHTML no debe contener un head, un elemento body, las referencias externas de hojas de estilo, scripts, formularios, base / enlace / XLink, frames, iframes y objetos. El elemento div debe tener algún contenido que no esté en blanco.

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>Este es un ejemplo solo con texto plano</div>
</narrative>

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>
<p>
Este es un <i>ejemplo</i> con algun <b>xhtml</b> formato.
</p>
</div>
</narrative>

La porción interna del contenido div se utiliza a menudo para la propiedad innerHTML en un navegador. Para simplificar el procesamiento, la narración se codificará de manera que el contenido entre el primero “>” y el último “<” carácteres es el contenido del elemento <div>.
Hay que tener en cuenta que el XHTML se encuentra contenido en un XML, por lo que no hay apoyo para las entidades en HTML como por ejemplo &nbsp; o &copy; etc. Para arreglarlo se utilizará caracteres Unicode en su lugar. En el ejemplo anterior &#160; substituiria &nbsp;
El contenido narrativo debe estar en el idioma del recurso, pero no hay razón para esperar que este tipo de herramientas HTML entiendan el elemento de lenguaje del recurso. Por esta razón, también se debe utilizar un atributo lang al <div> (y ver la nota en la especificación HTML 5 sobre el uso de la lengua).

Las referencias “image source” pueden ser una referencia local dentro del recurso:
<img src=”#a5″/>

Esta es una referencia interna a un atributo id de un elemento al mismo recurso, ya sea en los archivos adjuntos binarios en el elemento de texto directamente, o un elemento de tipo “Anexo”.

<narrative>
<div xmlns=”http://www.w3.org/1999/xhtml”>
<p>
<img src=”#a1″/>.
</p>
</div>
<blob id=”a1″>
<mimeType value=”image/png” />
<content value=”MEKH….SD/Z” />
</blob>
</narrative>

Dado que la presencia de las imágenes que no forman parte de los recursos no está garantizado, imágenes que son una parte esencial de la narración siempre deben ser incorporadas como este.
El fragmento XHTML en la descripción narrativa puede ser de estilo usando CSS de forma normal, con una mezcla de clases, identificadores y elementos de estilo en línea. Se aplicarán hojas de estilo CSS específicas al XHTML cuando se extraiga esta narración desde el recurso de que se mostrará a un ser humano para crear la presentación deseada en el contexto de uso.

Los autores pueden fijar los siguientes aspectos de estilo del contenido:
negrita, cursiva, subratllado, rallado, color de la fuente, família, el tamaño, color de fondo, alineación del texto, interpretación de los espacios en blanco, lista de formato de número ordenado (ya que puede ser contemplada en el texto).
Estas propiedades de estilo se especifican en línea utilizando el atributo de estilo. Si hay un elemento HTML equivalente, como “i”, o “pre”, se pueden utilizar en su lugar pero hay que tener en cuenta que algunos de estos elementos se han desaprobado (están en estado deprecated) en HTML 4 y no deben ser utilizados en la descripción narrativa XHTML (como “o”, y “fuente”).
Se requieren sistemas de representación para respetar cualquiera de estos estilos de reproducción cuando se especifican en XHTML, aunque se permite la interpretación apropiada (por ejemplo, una pantalla de bajo contraste para diferentes contextos, como un cuarto oscuro, o en una pantalla de alto contraste para los discapacitados visuales pueden ajustar los colores en consecuencia).
Los autores pueden especificar estilos adicionales y las propiedades de estilo como se especifica en la especificación CSS, pero estas son extensiones de esta especificación y éstos no están obligados a cumplir con ellos. Hay que tener en cuenta, sin embargo, las normas adicionales del estilo que se aplican en el contexto de los documentos.

Referencias internas
Hay 4 casos donde los elementos dentro de un recurso hacen referencia a otro:

  • Dentro de un tipo de datos “CodeableConcept” para identificar la codificación primaria.
  • Una referencia <img src = “”/> dentro de la descripción narrativa, en referencia a una imagen que se encuentra en el recurso.
  • Entre los elementos de la narrativa y elementos de datos estructurados.
  • Entre un ResourceReference y un recurso contenido.

Estas referencias se hacen usando un enfoque basado en un id / idRef, donde un elemento de origen indica que tiene el mismo contenido que el elemento de destino. El elemento de destino tiene un atributo “id” que debe tener un valor único en el recurso respecto a cualquier otro atributo id. El atributo “id” no se encuentra en ningún espacio de nombres (namespace). La referencia del elemento de origen debe hacer referencia a un atributo en el mismo recurso (o, para un CodeableConcept, dentro del mismo tipo de datos).

<example>
<target id=”a1″>
<child>…</child>
</target>
<– other stuff –>
<source idref=”a1″>
</example>

En un solo recurso, esto funciona como xml: id / idRef, pero hay una diferencia importante: la singularidad y el alcance de la resolución de estas referencias de identificación es en el recurso que los contiene. Si múltiples recursos se combinan en una sola pieza XML, como un átomo de alimentación, valores duplicados pueden ocurrir entre los recursos. Esto debe ser gestionado por aplicaciones que leen los recursos.
Cabe destacar que todas las referencias entre los elementos XHTML y los elementos de datos deben entenderse para establecer una “deriva de” relación, donde el contenido derivado (ya sea texto o datos) se refiera al contenido de origen. Hay que tener en cuenta que esto significa que algunas referencias pueden ser referencias a plazo (referencias a elementos definidas más adelante en la instancia).

Hasta aqui la última entrega del post sobre FHIR.

FHIR, la nova especificació HL7 (Part III)

Leer en castellano

Des del CCI varem començar parlant sobre la nova especificació FHIR, ara seguirem amb la continuació en aquesta tercera entrega la qual parlarem sobre els diferents formats en que es poden representar els recursos i els tipus de dades que els composen.

Formats dels recursos

Els recursos es poden descriure de dues formes diferents: un diagrama UML que resumeixi el contingut del recurs i una sintaxi pseudo-XML que proporciona una sensació visual de que les instàncies de recursos finals es veuran com en XML. Cal tenir en compte que encara que la descripció dels recursos es basa en la seva representació XML, altres representacions (com la ja esmentada en parts anteriors del post JSON) són igualment vàlides.

Representació XML

La sintaxis XML presenta la següent anotació:

<name xmlns=”http://hl7.org/fhir” (attrA=”value”)>
<nameA><!– 1..1 type descripció de contingut –><nameA>
<nameB[x]><!– 0..1 type1|type1 descripció –></nameB>
<nameC> <!–  1..* –>
<nameD><!– 1..1 type>Relevant records –></nameD>
</nameC>
<name>

Notes sobre els formats i la instanciació de recursos en XML:

  • Per construir una instància de XML vàlida d’un recurs, simplement cal substituir el contingut dels elements i atributs amb contingut vàlid tal com es descriu, per la cardinalitat, les regles del tipus i la descripció del contingut que es troba en el comentari a cada element.
  • S’ha de tenir en compte que les úniques propietats que representen com a atributs són els definits en les especificacions subjacents com ara xml: lang i Atom (veure més a baix), que s’utilitzen com la representació XML per paquets.
  • Tots els elements que tenen un tipus primitiu tindran un atribut per contenir el valor real de l’element.
  • Als elements se’ls assigna una cardinalitat que especifica quantes vegades es pot o ha d’aparèixer l’element. Si la cardinalitat es mostra en rosa llavors hi ha una condició addicional que impacta en la cardinalitat permesa.
  • Als elements a més se’ls assigna un o més tipus. Tots els tipus son definits en els tipus de dades a excepció de “recursos” i “descripció narrativa” que es documenten més endavant. Els noms dels tipus tenen hipervincles.
  • Quan un element lògic pot tenir més d’un tipus, el seu nom pren la forma xxx[y]. La part de “xxx” del nom és constant, i la [y] es reemplaça amb el nom del tipus que s’utilitza realment.
  • Cada nom d’un element en la pseudo-sintaxi també és un hipervincle a la definició formal de l’element en el diccionari de dades que està subjacent als formats d’intercanvi.
  • Si el nom està subratllat, es requereixen aplicacions de suport i/o enteniment.
  • El joc de caràcters per a un recurs és sempre Unicode, codificat en format UTF-8.
  • Especificació de la codificació de caràcters en XML és opcional però recomanat.
  • Elements FHIR estan sempre a l’espai de noms (namespace) http://hl7.org/fhir. Això s’especifica com l’espai de noms per defecte en l’element arrel. Els únics altres espais de noms que es produeixen en els recursos són FHIR on alguns model de contingut extern s’introdueix explícitament en el model de contingut de recursos. Per exemple, XHTML es troba en tots els recursos.
  • Qualsevol dels elements XML poden tenir un atribut “id” per servir com a destinació d’una referència interna. L’atribut “id” no es mostra en aquest format.
  • Elements FHIR mai estan buits. Si un element està present en el recurs, ha de tenir ja sigui un atribut de valor, elements secundaris com es defineix pel seu tipus, un atribut “id” que és la destinació de l’enllaç de la narrativa, o 1 o més extensions.
  • Els atributs no poden estar buits. O estan absents, o presents però amb almenys un caràcter de contingut (no en blanc).
  • L’atribut xml: lang pot aparèixer en l’element arrel, on s’especifica l’idioma base del recurs. També pot aparèixer en els arxius adjunts i en el contingut XHTML, però en cap altre lloc.
  • El tipus MIME formal de recursos FHIR representats en XML és definit com application/FHIR + xml.

Representació UML

Els diagrames UML representen el mateix contingut que una sèrie de classes que representen elements XML. Els elements es marquen amb una “R” per al recurs, o una “D” per a un tipus de dades. Classes sense etiqueta són classes normals que són només una part del contingut d’un recurs o d’un tipus de dades.

Quan un element pot tenir una varietat de tipus de dades, aquestes es representen en la elecció utilitzant la mateixa sintaxi que la sintaxi XML. A causa de la forma de treballar en UML, l’ordre real dels elements no es pot determinar a partir del diagrama, ni és visible si una propietat és un element o un atribut. Aquests diagrames, principalment el que pretenen es informar sobre el contingut del recurs a les persones.

Tipus de dades dels recursos

L’especificació FHIR defineix un conjunt de tipus que s’utilitzen per als elements dels recursos. Hi ha dues categories de tipus de dades: tipus simples/primitius, importats d’esquema XML i tipus complexos, que són grups reutilitzables dels elements.

(A la imatge es pot veure com s’estructuren els tipus de dades que poden contenir els recursos)

Tipus Primitius:

Aquests tipus es representen com a elements XML amb el valor del tipus en el text de l’element. El nom de l’element es definit allà on s’utilitza el tipus. Els elements XML poden tenir un atribut id. En format JSON, el tipus de dades està representat per un objecte amb dues propietats: “_id” per a l’atribut id, i “valor” per al valor del tipus.

Exemple:

data (per exemple, data de naixement):

<date value=”1951-06-04″ />
<date id=”a1″ value=”1951-06-04″ />

En JSON:

date : {
value : “1951-06-04”
}

O bé:

date : {
_id : “a1”,
value : “1951-06-04”
}

Tipus Complexos:

Aquests tipus es representen com a elements XML, amb elements fills amb el nom dels elements definits del tipus. El nom de l’element es definit allà on s’utilitza el tipus. Qualsevol dels elements XML poden tenir un atribut id. En JSON, el tipus de dades està representat per un objecte amb les propietats amb nom igual que els elements amb format XML. La representació JSON és gairebé exactament igual, de manera que només el primer exemple té una representació addicional JSON.

(A la imatge superior e inferior es pot veure els diferents tipus complexos i els diferents atributs que els composen)

Fins aqui la tercera part del post sobre FHIR en una propera entrega acabarem de parlar sobre aquesta nova especificació.

Llegir en català

Desde el CCI empezamos hablando sobre la nueva especificación FHIR, ahora seguiremos con la continuación en esta tercera entrega la que hablaremos sobre los diferentes formatos en que se pueden representar los recursos y los tipos de datos que los componen.

Formatos de los recursos

Los recursos se pueden describir de dos formas diferentes: un diagrama UML que resuma el contenido del recurso y una sintaxis pseudo-XML que proporciona una sensación visual de que las instancias de recursos finales se verán como en XML. Hay que tener en cuenta que aunque la descripción de los recursos se basa en su representación XML, otras representaciones (como la ya mencionada en partes anteriores del post JSON) son igualmente válidas.

Representación XML

La sintaxis XML presenta la siguiente anotación:

<name xmlns=”http://hl7.org/fhir” (attrA=”value”)>
<nameA><!– 1..1 type descripción del contenido –><nameA>
<nameB[x]><!– 0..1 type1|type1 descripción –></nameB>
<nameC> <!– 1..* –>
<nameD><!– 1..1 type>Relevant records –></nameD>
</nameC>
<name>

Notas sobre los formatos y la instanciación de recursos en XML:

  • Para construir una instancia de XML válida de un recurso, simplemente hay que sustituir el contenido de los elementos y atributos con contenido válido tal como se describe, por la cardinalidad, las reglas del tipo y la descripción del contenido que se encuentra en el comentario a cada elemento.
  • Hay que tener en cuenta que las únicas propiedades que representan como atributos son los definidos en las especificaciones subyacentes tales como xml: lang y Atom (ver más abajo), que se utilizan como la representación XML para paquetes.
  • Todos los elementos que tienen un tipo primitivo tendrán un atributo para contener el valor real del elemento.
  • A los elementos se les asigna una cardinalidad que especifica cuántas veces se puede o debe aparecer el elemento. Si la cardinalidad se muestra en rosa entonces hay una condición adicional que impacta en la cardinalidad permitida.
  • A los elementos además se les asigna uno o más tipos. Todos los tipos son definidos en los tipos de datos a excepción de “recursos” y “descripción narrativa” que se documentan más adelante. Los nombres de los tipos tienen hipervínculos.
  • Cuando un elemento lógico puede tener más de un tipo, su nombre toma la forma xxx [y]. La parte de “xxx” del nombre es constante, y la [y] se reemplaza con el nombre del tipo que se utiliza realmente.
  • Cada nombre de un elemento en la pseudo-sintaxis también es un hipervínculo a la definición formal del elemento en el diccionario de datos que subyace a los formatos de intercambio.
  • Si el nombre está subrayado, se requieren aplicaciones de soporte y / o entendimiento.
  • El juego de caracteres para un recurso es siempre Unicode, codificado en formato UTF-8.
  • Especificación de la codificación de caracteres en XML es opcional pero recomendado.
  • Elementos FHIR están siempre en el espacio de nombres (namespace) http://hl7.org/fhir. Esto se especifica como el espacio de nombres por defecto en el elemento raíz. Los únicos otros espacios de nombres que se producen en los recursos son FHIR donde algunos modelos de contenido externo se introduce explícitamente en el modelo de contenido de recursos. Por ejemplo, XHTML se encuentra en todos los recursos.
  • Cualquiera de los elementos XML pueden tener un atributo “id” para servir como destino de una referencia interna. El atributo “id” no se muestra en este formato.
  • Elementos FHIR nunca están vacíos. Si un elemento está presente en el recurso, debe tener ya sea un atributo de valor, elementos secundarios como se define por su tipo, un atributo “id” que es el destino del enlace de la narrativa, o 1 o más extensiones.
  • Los atributos no pueden estar vacíos. O están ausentes, o presentes pero con al menos un carácter de contenido (no en blanco).
  • El atributo xml: lang puede aparecer en el elemento raíz, donde se especifica el idioma base del recurso. También puede aparecer en los archivos adjuntos y en el contenido XHTML, pero en ningún otro lugar.
  • El tipo MIME formal de recursos FHIR representados en XML es definido como application / FHIR + xml.

Representación UML

Los diagramas UML representan el mismo contenido que una serie de clases que representan elementos XML. Los elementos se marcan con una “R” para el recurso, o una “D” para un tipo de datos. Clases sin etiqueta son clases normales que son sólo una parte del contenido de un recurso o de un tipo de datos.

Cuando un elemento puede tener una variedad de tipos de datos, éstas se representan en la elección utilizando la misma sintaxis que la sintaxis XML. Debido a la forma de trabajar en UML, el orden real de los elementos no se puede determinar a partir del diagrama, ni es visible si una propiedad es un elemento o un atributo. Estos diagramas, principalmente el que pretenden es informar sobre el contenido del recurso a las personas.

Tipos de datos de los recursos

La especificación FHIR define un conjunto de tipos que se utilizan para los elementos de los recursos. Hay dos categorías de tipos de datos: tipos simples/primitivos, importados de esquema XML y tipos complejos, que son grupos reutilizables de los elementos.

(En la imagen se puede ver cómo se estructuran los tipos de datos que pueden contener los recursos)

Tipos Primitivos:

Estos tipos se representan como elementos XML con el valor del tipo en el texto del elemento. El nombre del elemento se definió allí donde se utiliza el tipo. Los elementos XML pueden tener un atributo id. En formato JSON, el tipo de datos está representado por un objeto con dos propiedades: “_id” para el atributo id, y “valor” para el valor del tipo.

Ejemplo:

fecha (por ejemplo, fecha de nacimiento):

<date value=”1951-06-04″ />
<date id=”a1″ value=”1951-06-04″ />

En JSON:

date : {
value : “1951-06-04”
}

O bien:

date : {
_id : “a1”,
value : “1951-06-04”
}

Tipos Complejos:

Estos tipos se representan como elementos XML con el valor del tipo en el texto del elemento. El nombre del elemento se definió allí donde se utiliza el tipo. Los elementos XML pueden tener un atributo id. En formato JSON, el tipo de datos está representado por un objeto con dos propiedades: “_id” para el atributo id, y “valor” para el valor del tipo.

(En la imagen superior e inferior se puede ver los diferentes tipos complejos y los diferentes atributos que los componen)

Hasta aquí la tercera parte del post sobre FHIR en una próxima entrega terminaremos de hablar sobre esta nueva especificación.

FHIR, la nova especificació HL7 (Part II)

Leer en castellano

Des del CCI varem començar parlant sobre la nova especificació FHIR, ara seguirem amb la continuació en aquesta segona part la qual parlarem sobre algunes particularitats dels recursos com son els paquets, les referencies entre recursos i els recursos continguts.

Paquets de recursos:
Una operació comú que es realitza amb els recursos és reunir una col•lecció de recursos en una sola instància. El paquet de recursos no és només una llista de referències als recursos, sinó que inclou tot el contingut (un tipus, una URL i una descripció de text). Aquests paquets de recursos són útils per a una varietat de raons diferents, entre les quals hi ha les següents:

  • Es pot retornar un conjunt de recursos que compleixin alguns criteris com a part d’una operació del servidor.
  • Es pot retornar un conjunt de versions dels recursos, com a part de l’operació de la història al servidor.
  • Emmagatzematge d’una col•lecció de recursos.
  • L’intercanvi d’un conjunt de recursos, com a part d’una transacció de missatge.
  • Agrupació d’un conjunt autònom de recursos per actuar com un grup intercanviable i persistent amb integritat clínica (és a dir, un document clínic).

Conceptualment, un paquet té un identificador (URL), una data d’actualització, i una llista de recursos. Per a cada recurs a la llista, el paquet té els recursos i també les meta-dades com s’ha indicat anteriorment. Cada entrada al conjunt conserva el seu identificador original. Això significa que les aplicacions que llegeixen el paquet sempre han de buscar un recurs per la seva identitat (després de la conversió de URL relativa a URL absoluta) en el paquet primer abans d’intentar accedir-hi per la seva URL.

Cardinalitat de recursos:
Tots els elements definits en FHIR tenen una cardinalitat com a part de la seva definició – un nombre mínim d’aparicions requerides, i un nombre màxim permès. Aquest número indica el nombre de vegades que l’element pot aparèixer en la instància. En l’especificació, el nombre mínim està sempre entre 0 o 1, i el nombre màxim està sempre entre 1 o *, vol dir que no hi ha límit. Els perfils poden utilitzar qualsevol nombre enter de cardinalitat tant mínima i màxima, sempre que mínim sigui menor o igual a màxim.
Per als elements que tenen cardinalitat superior a 1, l’ordre en què apareixen pot tenir significat. Llevat que la definició de l’element (ja sigui en aquesta memòria descriptiva o l’extensió) defineix un significat a l’ordre explícitament, el significat de l’ordre no es defineix, i les implementacions se’ls permet canviar l’ordre dels elements. Cal tenir en compte que no es pot definir un significat per a l’ordre dels elements d’un perfil. Quan no hi ha definició del significat de l’ordre, les implementacions que han de triar un sol element d’una llista d’elements per a algun ús han de fer basats en la semàntica del contingut dels elements que es repeteix. Perfils i guies d’implementació sovint poden fer regles sobre aquest procés de selecció.

Referències entre recursos:
Els elements definits en un recurs poden incloure moltes referències a altres recursos. Els recursos es combinen per construir una xarxa d’informació sobre la salut. En un recurs, les referències estan representades amb un tipus, una referència, i una descripció de text. La propietat clau de la referència és la referència que conté – els recursos són identificats i adreçats per la seva URL. La referència real té un aspecte com aquest:

<[name] xmlns=”http://hl7.org/fhir”>
<type value=”[code]”/><!– 0..1 Tipus de recurs –>
<reference value=”[string]”/><!– 0..1 Relativa, interna o absoluta URL de referència –>
<display value=”[string]”/><!– 0..1 Text alternatiu del recurs –>
</[name]>

El type ha d’especificar el tipus de recurs, si el tipus de referència de recursos és fixa per l’element de la definició dels recursos.
L’element de referència conté una adreça URL que és o bé una URL absoluta, o una adreça relativa a l’URL base de servei, o un fragment intern de referència.
Utilitzant URL absolutes es proporciona un enfocament escalable i estable adequat per a un context de núvol/web, mentre que l’ús de referències relatives/lògiques proporciona un enfocament flexible adequat per utilitzar quan es realitzin a través dels límits de l’ecosistema tancat.
Les URL absolutes no han d’apuntar a un servidor RESTful FHIR, encara que aquest és l’enfocament preferit. Si la cua de la URL s’ajusta a l’estructura “/ [tipus] / @ [id]” o “/ [tipus] / @ [id] / history / @ [id]”, aleshores cal suposar que la referència és a un servidor RESTful FHIR. Independentment de si la referència és a un servidor RESTful FHIR, la referència ha d’apuntar a un recurs com es defineix en aquesta especificació
Les URL sempre son sensibles al tipus de lletra (majúscula-minuscula) i es prefereix en minúscules.

Exemple d’una referència relativa al pacient “034AB16” d’un element anomenat “context” al servidor REST FHIR:

<context>
<type value=”Patient” />
<reference value=”patient/@034AB16″ />
</context>

Exemple d’una referència absoluta al perfil d’un recurs en un element anomenat “profile”:

<profile>
<type value=”Profile” />
<reference value=”http://fhir.hl7.org/svc/profile/@c8973a22-2b5b-4e76-9c66-00639c99e61b” />
</profile>

Recursos continguts:
En algunes circumstàncies, el contingut esmentat en la referència del recurs no té una existència independent a part del recurs que el conté – no pot ser identificat de forma independent, i no pot tenir el seu propi àmbit de transacció independent. Típicament, tals circumstàncies sorgeixen on el recurs està sent assemblat per un usuari secundari de les dades origen, com un motor de middleware.
Si les dades disponibles quan es construeix el recurs no inclou claus de registre o informació d’identificació absoluta, llavors un recurs identificat correctament no es pot muntar, i fins i tot si una identificació arbitrària es va associar amb ell, el recurs no pot ser l’objecte d’una operació fora del context del recurs al que es refereix.
En aquestes circumstàncies, el recurs es col•loca directament en línia a la referència. Això mai s’ha de fer quan el contingut pot ser identificat correctament, ja que un cop es perd la identificació, és extremadament difícil (i depenent del context) tornar a restaurar-lo de nou.

Un exemple d’un recurs contingut:

<Document xmlns=”http://hl7.org/fhir”>
<extension>…</extension>
<text>…</text>
<contained>
<Organization id=”org1″>
<!– whatever information is available –>
</Organization>
</contained>
<information>
<!– other attributes –>
<custodian>
<type value=”Organization” />
<reference value=”#org1″ />
</custodian>
<!– other attributes –>
<information>
</Document>

El mateix exemple escrit amb JSON:

{ “Document” : {
“extension” : { … },
“text” : { .. },
“contained: [
{“Organization” : {
“_id” : “org1”,
.. whatever information is available …
}}
]
“information: {
… other attributes …
“custodian” : {
“type” : { “value” : “Organization” },
“url” : { “value” : “#org1” }
}
… other attributes …
}
}}

Algunes notes sobre l’ús i la interpretació dels recursos continguts:

  • Els recursos continguts comparteixen el mateix identificador d’espai intern de resolució com el recurs pare.
  • Els recursos continguts no contenen recursos continguts addicionals.
  • Els recursos continguts no és necessari  que continguin cap text narratiu.

Fins aqui la segona part del post sobre FHIR en una propera entrega continuarem parlant sobre aquesta nova especificació.

Llegir en català

Desde el CCI empezamos hablando sobre la nueva especificación FHIR, ahora seguiremos con la continuación en esta segunda parte la que hablaremos sobre algunas particularidades de los recursos como son los paquetes, las referencias entre recursos y los recursos contenidos.

Paquetes de recursos:
Una operación común que se realiza con los recursos es reunir una colección de recursos en una sola instancia. El paquete de recursos no es sólo una lista de referencias a los recursos, sino que incluye todo el contenido (un tipo, una URL y una descripción de texto). Estos paquetes de recursos son útiles para una variedad de razones diferentes, entre las que se encuentran las siguientes:

  • Se puede devolver un conjunto de recursos que cumplan algunos criterios como parte de una operación del servidor.
  • Se puede devolver un conjunto de versiones de los recursos, como parte de la operación de la historia en el servidor.
  • Almacenamiento de una colección de recursos.
  • El intercambio de un conjunto de recursos, como parte de una transacción de mensaje.
  • Agrupación de un conjunto autónomo de recursos para actuar como un grupo intercambiable y persistente con integridad clínica (es decir, un documento clínico).

Conceptualmente, un paquete tiene un identificador (URL), una fecha de actualización, y una lista de recursos. Para cada recurso en la lista, el paquete tiene los recursos y también los meta-datos como se ha indicado anteriormente. Cada entrada en el conjunto conserva su identificador original. Esto significa que las aplicaciones que leen el paquete siempre deben buscar un recurso para su identidad (después de la conversión de URL relativa URL absoluta) en el paquete primero antes de intentar acceder por su URL.

Cardinalidad de recursos:
Todos los elementos definidos en FHIR tienen una cardinalidad como parte de su definición – un número mínimo de apariciones requeridas, y un número máximo permitido. Este número indica el número de veces que el elemento puede aparecer en la instancia. En la especificación, el número mínimo está siempre entre 0 o 1, y el número máximo está siempre entre 1 o *, significa que no hay límite. Los perfiles pueden utilizar cualquier número entero de cardinalidad tanto mínima y máxima, siempre que el mínimo sea menor o igual al máximo.
Para los elementos que tienen cardinalidad superior a 1, el orden en que aparecen puede tener significado. Salvo que la definición del elemento (ya sea en esta memoria descriptiva o la extensión) define un significado al orden explícitamente, el significado de la orden no se define, y las implementaciones se les permite cambiar el orden los elementos. Hay que tener en cuenta que no se puede definir un significado para el orden de los elementos de un perfil. Cuando no hay definición del significado de la orden, las implementaciones que tienen que elegir un solo elemento de una lista de elementos para algún uso deben hacer basados ​​en la semántica del contenido de los elementos que se repite. Perfiles y guías de implementación a menudo pueden hacer reglas sobre este proceso de selección.

Referencias entre recursos:
Los elementos definidos en un recurso pueden incluir muchas referencias a otros recursos. Los recursos se combinan para construir una red de información sobre la salud. En un recurso, las referencias están representadas con un tipo, una referencia, y una descripción de texto. La propiedad clave de la referencia es la referencia que contiene – los recursos son identificados y dirigidos por su URL. La referencia real tiene un aspecto como éste:

<[name] xmlns=”http://hl7.org/fhir”>
<type value=”[code]”/><!– 0..1 Tipo de recurso –>
<reference value=”[string]”/><!– 0..1 Relativa, interna o absoluta URL de referencia –>
<display value=”[string]”/><!– 0..1 Texto alternativo del recurso –>
</[name]>

El type debe especificar el tipo de recurso, si el tipo de referencia de recursos es fija para el elemento de la definición de los recursos.
El elemento de referencia contiene una dirección URL que es o bien una URL absoluta, o una dirección relativa a la URL base de servicio, o un fragmento interno de referencia.
Utilizando URL absolutas se proporciona un enfoque escalable y estable adecuado para un contexto de nube/web, mientras que el uso de referencias relativas/lógicas proporciona un enfoque flexible adecuado para utilizar cuando se realicen a través de los límites del ecosistema cerrado.
Las URL absolutas no deben apuntar a un servidor RESTful FHIR, aunque este es el enfoque preferido. Si la cola de la URL ajusta a la estructura “/ [tipo] / @ [id]” o “/ [tipo] / @ [id] / history / @ [id]”, entonces hay que suponer que la referencia es un servidor RESTful FHIR. Independientemente de si la referencia es a un servidor RESTful FHIR, la referencia debe apuntar a un recurso como se define en esta especificación
Las URL siempre son sensibles al tipo de letra (mayúscula-minuscula) y se prefiere en minúsculas.

Ejemplo de una referencia relativa al paciente “034AB16” de un elemento llamado “context” al servidor REST FHIR:

<context>
<type value=”Patient” />
<reference value=”patient/@034AB16″ />
</context>

Ejemplo de una referencia absoluta al perfil de un recurso en un elemento llamado “profile”:

<profile>
<type value=”Profile” />
<reference value=”http://fhir.hl7.org/svc/profile/@c8973a22-2b5b-4e76-9c66-00639c99e61b” />
</profile>

Recursos contenidos:
En algunas circunstancias, el contenido mencionado en la referencia del recurso no tiene una existencia independiente a parte del recurso que lo contiene – no puede ser identificado de forma independiente, y no puede tener su propio ámbito de transacción independiente. Típicamente, tales circunstancias surgen donde el recurso está siendo ensamblado por un usuario secundario de los datos origen, como un motor de middleware.
Si los datos disponibles cuando se construye el recurso no incluye claves de registro o información de identificación absoluta, entonces un recurso identificado correctamente no se puede montar, e incluso si una identificación arbitraria se asoció con él, el recurso no puede ser el objeto de una operación fuera del contexto del recurso al que se refiere.
En estas circunstancias, el recurso se coloca directamente en línea en la referencia. Esto nunca debe hacerse cuando el contenido puede ser identificado correctamente, ya que una vez se pierde la identificación, es extremadamente difícil (y dependiendo del contexto) volver a restaurarlo de nuevo.

Un ejemplo de un recurso contenido:

<Document xmlns=”http://hl7.org/fhir”>
<extension>…</extension>
<text>…</text>
<contained>
<Organization id=”org1″>
<!– whatever information is available –>
</Organization>
</contained>
<information>
<!– other attributes –>
<custodian>
<type value=”Organization” />
<reference value=”#org1″ />
</custodian>
<!– other attributes –>
<information>
</Document>

El mismo ejemplo escrito con JSON:

{ “Document” : {
“extension” : { … },
“text” : { .. },
“contained: [
{“Organization” : {
“_id” : “org1”,
.. whatever information is available …
}}
]
“information: {
… other attributes …
“custodian” : {
“type” : { “value” : “Organization” },
“url” : { “value” : “#org1” }
}
… other attributes …
}
}}

Algunas notas sobre el uso y la interpretación de los recursos contenidos:

  • Los recursos contenidos comparten el mismo identificador de espacio interno de resolución como el recurso padre.
  • Los recursos contenidos no contienen recursos contenidos adicionales.
  • Los recursos contenidos no es necesario que contengan ningún texto narrativo.

Hasta aquí la segunda parte del post sobre FHIR en una próxima entrega continuaremos hablando sobre esta nueva especificación.

Nova edició del taller d’Introducció a SNOMED CT i Vocabularis Clínics Controlats

Leer en castellano

Els passats dies 30 i 31 de maig es va dur a terme el taller presencial d’introducció a SNOMED CT i Vocabularis Clínics Controlats, organitzat des del CCI, HL7 Spain i TicSalut. El curs de 10 hores es va fer a Barcelona i va comptar amb la participació de 9 alumnes de diferents regions d’Espanya.

Al taller es va realitzar una introducció a la terminologia biomèdica i a l’estàndard semàntic SNOMED CT. Es van descriure els components bàsics (conceptes, descripcions, relacions i historial) i avançats (mapejos, subconjunts i extensions) de SNOMED CT i es va explicar com crear Clinical Statements amb expressions post-coordinades. L’edició d’enguany també va incloure una presentació sobre serveis de terminologia i l’estàndard d’HL7 CTS2 (Common Terminology Services Release 2). El taller va finalitzar amb un repàs pels estàndards d’HL7, detallant com utilitzar CDA en combinació amb SNOMED CT per representar documents clínics i el significat del seu contingut, d’una manera inequívoca.

Els coneixements teòrics es van complementar amb exercicis pràctics i un cas d’ús de SNOMED CT pel domini d’al·lèrgies basat en l’experiència real del Sistema Sanitari Català. Els alumnes van instal·lar i utilitzar el navegador de SNOMED CT ClíniClue Xplore i el servidor de Terminologia ITS (Integrated Terminology System) d’Indizen per dur a terme les parts pràctiques.

Al següent enllaç es pot consultar el tríptic del taller: Taller presencial introducció a SNOMED CT i Vocabularis Clínics Controlats, edició Barcelona.

Llegir en català

Los pasados días 30 y 31 de mayo se realizó el taller presencial de introducción a SNOMED CT y Vocabularios Clínicos Controlados, organizado des del CCI, HL7 Spain y TicSalut. El curso de 10 horas tuvo lugar en Barcelona y contó con la participación de 9 alumnos de diferentes regiones de España.

En el taller se hizo una introducción a la terminología biomédica i al estándar semántico SNOMED CT. Se describieron los componentes básicos (conceptos, descripciones, relaciones e historial) y avanzados (subconjuntos, mapeos y extensiones) de SNOMED CT y se explicó cómo crear Clinical Statements con expresiones post-coordinadas. La edición de este año también incluyó una presentación sobre servicios de terminología y el estándar de HL7 CTS2 (Common Terminology Services Release 2). El taller finalizó con un repaso por los estándares de HL7, detallando como utilizar CDA en combinación con SNOMED CT para representar documentos clínicos y el significado de su contenido, de una manera inequívoca.

Los conocimientos teóricos se complementaron con ejercicios prácticos y un caso de uso de SNOMED CT para el dominio de alergias basado en la experiencia real del Sistema Sanitario Catalán. Los alumnos instalaron y utilizaron el navegador de SNOMED CT ClíniClue Xplore y el servidor de Terminología ITS (Integrated Terminology System) de Indizen para realizar las partes prácticas.

En el siguiente enlace se puede consultar el tríptico del taller: Taller presencial de introducción a SNOMED CT y Vocabularios Clínicos Controlados, edición Barcelona.

FHIR, la nova especificació HL7 (Part I)

Leer en castellano

Al llarg dels darrers anys, dins l’àmbit de la interoperabilitat entre sistemes al sector sanitari, des de la creació de HL7 i les seves posteriors versions com la actual V3 i altres estàndards com CDA, sempre s’ha intentat buscar una eficient i rapida integració de la informació encapsulada dins aquests missatges i documents mèdics que ajudessin a fer del sistema sanitari mundial alguna cosa que sigui el més beneficiós possible per tothom. FHIR intenta anar més enllà i vol aconseguir una major eficiència en interoperabilitat adaptant les necessitats tecnològiques que hi ha en els temps actuals. Des del CCI explicarem una mica de que tracta aquesta nova especificació.

Perquè es fa necessari?

FHIR es fa necessari perquè:

  • Tot i ser més robust i menys ambigu, HL7 V3 es massa dur, sever i difícil d’aprendre degut a la seva rigidesa i poca flexibilitat i això el fa més lent.
  • Els Documents Clínics CDA no son suficients ja que si bé ofereixen més flexibilitat en estructuració i continguts per altra banda es perd en les avantatges que ofereix HL7 V3.
  • HL7 V2 necessita alguna nova eina pels executors que permeti un camí de transició òptim ja que V2 no proporciona una plataforma moderna pel processament intern i la manipulació de les dades sanitàries.
  • Hi ha nous mercats emergents, com per exemple el de la telefonia mòbil, i si surten noves eines com aplicacions per dispositius cel•lulars HL7 necessita alguna cosa més que oferir.
  • El mon està en constant evolució i la tecnologia i l’enfoc dins l’àmbit de la interoperabilitat també han canviat.

Però…Que és FHIR? Per a què serveix? Quins avantatges ofereix?

FHIR (Recursos d’Interoperabilitat Ràpids en Salut) és un nou projecte estàndard HL7 per a l’intercanvi de dades en l’assistència sanitària que es basa en els principis actuals de la indústria, incloent el núvol, la Web 2.0 i els principis REST. Aquesta especificació HL7 es basa en la definició d’un conjunt de recursos que representen conceptes clínics granulars que es poden gestionar de forma aïllada, o agregats en documents complexos. Aquesta flexibilitat ofereix solucions coherents per a una àmplia gamma de problemes d’interoperabilitat.

Aquests recursos cobreixen els elements bàsics de cobertura sanitària de pacients, admissions, informes de diagnòstic, medicacions i llistes de problemes -amb els seus elements de dada típics- i també permeten donar suport a una gamma de models clínics més ric i complex. Les senzilles i directes definicions d’aquests recursos es basen en la recopilació dels requisits de fonts, anàlisi formal i del mapeig encreuat extensiu de dades a través d’altres estàndards pertinents.

FHIR destaca per reduir la rigidesa dels sistemes (punt dèbil HL7 V3) i treu la necessitat de tractar ineficiències burocràtiques que els sistemes podrien haver arrossegat en casos anteriors. Aquest és un dels beneficis de la integració amb FHIR.

Un dels principals avantatges que també ofereix es que combina les millors característiques d’HL7 V2, HL7 V3 i CDA (Clinical Document Architecture), alhora que aprofita les últimes tecnologies de serveis web.

Com bé diu la definició de l’acrònim FHIR, aquesta especificació com s’ha dit està definida mitjançant l’ús de recursos… però com venen definits i que caracteritza aquests recursos?

Un recurs és una entitat que:

  • Té una identitat coneguda la qual pot ser adreçada.
  • S’identifica com un dels tipus de recursos definits en aquesta especificació.
  • Conté un conjunt d’elements de dades estructurades com descripció per la definició dels recursos.
  • Conté una representació XHTML llegible del contingut del recurs.
  • Pot canviar amb el temps.

Els recursos tenen múltiples representacions. Un recurs és vàlid si compleix les normes anteriors i està representat en XML o JSON (JavaScript Object Notation, format lleuger per l’intercanvi de dades el qual destaca per la seva simplicitat i per ser una alternativa a XML), d’acord amb les regles definides en aquesta especificació. Es permeten altres representacions, però no es descriuen en el present document.

(La imatge mostra com els recursos es combinen per construir una xarxa d’informació sobre l’entorn sanitari).

Tots els recursos estan formats pels següents elements:

  • Un conjunt bàsic d’estructures de dades definides (definició del recurs) mitjançant l’ús de diferents tipus de dades que composen aquestes estructures.
  • Extensions (elements de dades opcionals) addicionals afegides per implementacions. La seva funció es representar aquella informació extra que no forma part de la definició bàsica del recurs.
  • Una descripció narrativa llegible que contindrà un resum del mateix recurs, la seva funció es per representar el contingut del recurs a una persona.
  • Recursos continguts – Recursos addicionals que són part de la identificació i l’espai de transacció d’aquest recurs.
  • Les meta dades (informació important sobre el recurs que no és part del model de contingut del recurs).

Aquests elements han d’aparèixer sempre en aquest ordre. Els elements bàsics comuns a tots els recursos estan en primer lloc per tal de donar suport a definicions consistents per l’esquema i el codi derivat UML.

Fins aqui la primera part del post sobre FHIR. En una propera entrega continuarem parlant sobre aquesta nova especificació.

Llegir en català

Durante los últimos años, en el ámbito de la interoperabilidad entre sistemas en el sector sanitario, desde la creación de HL7 y sus posteriores versiones como la actual V3 y otros estándares como CDA, siempre se ha tratado de buscar una eficiente y rápida integración de la información encapsulada dentro de estos mensajes y documentos médicos que ayuden a hacer del sistema sanitario mundial algo que sea lo más beneficioso posible para todo el mundo. FHIR intenta ir más allá y quiere conseguir una mayor eficiencia en interoperabilidad adaptando las necesidades tecnológicas que hay en los tiempos actuales. Des del CCI explicaremos un poco de que trata esta nueva especificación.

¿Por qué se hace necesario?

FHIR se hace necesario porque:

  • A pesar de ser más robusto y menos ambiguo, HL7 V3 es demasiado duro, severo y difícil de aprender debido a su rigidez y poca flexibilidad y esto lo hace más lento.
  • Los Documentos Clínicos CDA no son suficientes ya que si bien ofrecen más flexibilidad en estructuración y contenidos por otro lado se pierde en las ventajas que ofrece HL7 V3.
  • HL7 V2 necesita alguna nueva herramienta para los ejecutores que permita un camino de transición óptimo ya que V2 no proporciona una plataforma moderna para el procesamiento interno y la manipulación de los datos sanitarios.
  • Hay nuevos mercados emergentes, como por ejemplo el de la telefonía móvil, y si salen nuevas herramientas y aplicaciones para dispositivos celulares HL7 necesita algo más que ofrecer.
  • El mundo está en constante evolución y la tecnología y el enfoque en el ámbito de la interoperabilidad también han cambiado.

Pero… ¿Qué es FHIR? ¿Para qué sirve? ¿Qué ventajas ofrece?

FHIR (Recursos de Interoperabilidad Ràpidos en Salud) es un nuevo proyecto estándar HL7 para el intercambio de datos en la asistencia sanitaria que se basa en los principios actuales de la industria, incluyendo la nube, la Web 2.0 y los principios REST. Esta especificación HL7 se basa en la definición de un conjunto de recursos que representan conceptos clínicos granulares que se pueden gestionar de forma aislada, o agregados en documentos complejos. Esta flexibilidad ofrece soluciones coherentes para una amplia gama de problemas de interoperabilidad.

Estos recursos cubren los elementos básicos de cobertura sanitaria de pacientes, admisiones, informes de diagnóstico, medicaciones y listas de problemas -con sus elementos de datos típicos- y también permiten apoyar una gama de modelos clínicos más rico y complejo. Las sencillas y directas definiciones de estos recursos se basan en la recopilación de los requisitos de fuentes, análisis formal y de mapeo cruzado extensivo de datos a través de otros estándares pertinentes.

FHIR destaca por reducir la rigidez de los sistemas (punto débil de HL7 V3) y saca la necesidad de tratar ineficiencias burocráticas que los sistemas podrían haber arrastrado en casos anteriores. Este es uno de los beneficios de la integración con FHIR.

Una de las principales ventajas que ofrece es que combina las mejores características de HL7 V2, HL7 V3 y CDA (Clinical Document Architecture), al tiempo que aprovecha las últimas tecnologías de servicios web.

Como bien dice la definición del acrónimo FHIR, esta especificación como se ha dicho está definida mediante el uso de recursos… pero ¿como vienen definidos y que caracteriza a estos recursos?

Un recurso es una entitad que:

  • Tiene una identidad conocida la cual puede ser direccionada.
  • Se identifica como uno de los tipos de recursos definidos en esta especificación.
  • Contiene un conjunto de elementos de datos estructuradas como descripción para la definición de los recursos.
  • Contiene una representación XHTML legible del contenido del recurso.
  • Puede cambiar con el tiempo.

Los recursos tienen múltiples representaciones. Un recurso es válido si cumple las normas anteriores y está representado en XML o JSON (JavaScript Object Notation, formato ligero para el intercambio de datos el cual destaca por su simplicidad y por ser una alternativa a XML), de acuerdo con las reglas definidas en esta especificación. Se permiten otras representaciones, pero no se describen en el presente documento.

(La imagen muestra como los recursos se combinan para construir una red de información sobre el entorno sanitario).

Todos los recursos estan formados por los siguientes elementos:

  • Un conjunto básico de estructuras de datos definidas (definición del recurso) mediante el uso de diferentes tipos de datos que componen estas estructuras.
  • Extensiones (Elementos de datos opcionales) adicionales añadidas por implementaciones. Su función es representar aquella información extra que no forma parte de la definición básica del recurso.
  • Una descripción narrativa legible que contendrá un resumen del mismo recurso, su función es para representar el contenido del recurso a una persona para que pueda leerlo con facilidad.
  • Recursos contenidos. Recursos adicionales que son parte de la identificación y el espacio de transacción de este recurso.
  • Los meta datos (información importante sobre el recurso que no es parte del modelo de contenido del recurso).

Estos elementos deben aparecer siempre en este orden. Los elementos básicos comunes a todos los recursos están en primer lugar para dar apoyo a definiciones consistentes para el esquema y el código derivado UML.

Hasta aquí la primera parte del post sobre FHIR. En una próxima entrega seguiremos hablando sobre esta nueva especificación.

Interoperabilidad, la base para una atención integrada del paciente crónico

Leer en castellano

El CCI va participar els passats dies 19 i 20 de març a la Jornada tècnica d’interoperabilitat organitzada pel Servei Andalús de Salut, IHE Espanya i HL7 Spain que tenia per títol “Interoperabilidad, la base para una atención integrada del paciente crónico”.
Al primer dia de la jornada es van realitzar les tres sessions següents:

  • Reunió del comitè tècnic d’HL7 Spain, en la qual es van repassar les principals novetats i avenços més rellevants des de l’última reunió. Destacar que s’ha començat a treballar en les derivacions de proves diagnòstiques, tant des del punt de vista funcional com de missatgeria i informes associats.
  • Presentació “Últimos avances en los estándares de documentación clínica”, orientada a acostar els estàndards al perfil documentalista.
  • Sessió IHE centrada en la implantació de XDS a Espanya.

Al segon dia es van realitzar diferents intervencions sobre la interoperabilitat entre sistemes i la integració de dispositius, presentant estàndards i sistemes que permeten garantir la continuïtat assistencial a diferents nivells. Es van destacar els nous reptes que tenen els CIOs en quant a la interoperabilitat i a l’atenció dels pacients crònics, així com a la importància de la capacitació del ciutadà de manera que formi part activa de la seva salut. Aquestes ponències es van complementar explicant el paper dels perfils IHE, de la norma CONTSYS (ISO/DIS 13940) i dels estàndards d’HL7, incloent els d’àmbit semàntic com CTS2 (Common Terminology Services Release 2). L’esdeveniment va finalitzar amb la compartició d’experiències i la presentació de diferents eines. Des del CCI-OFSTI es va realitzar una ponència sobre serveis terminològics avançats:

A la presentació es va explicar la necessitat d’aquesta mena de serveis, així com les funcionalitats que poden cobrir les eines que els ofereixen. També es va presentar l’estàndard CTS2, que defineix, a nivell funcional, una interfície estàndard per l’ús i la gestió de terminologies. Per acabar la intervenció, es va resumir la participació del CCI al grup de serveis semàntics del projecte europeu epSOS, en el qual es treballa amb l’estàndard CTS2.

Llegir en català

El CCI participó los pasados 19 y 20 de marzo en la Jornada técnica organizada por el Servicio Andaluz de Salud, IHE España y HL7 Spain que tenía por título “Interoperabilidad, la base para una atención integrada del paciente crónico”.
En el primer día de la jornada se realizaron las tres sesiones siguientes:

  • Reunión del comité técnico de HL7 Spain, en la cual se repasaron las principales novedades y avances des de la última reunión. Destacar que se ha empezado a trabajar en las derivaciones de pruebas diagnósticas, tanto a nivel funcional como de mensajería y informes asociados.
  • Presentación “Últimos avances en los estándares de documentación clínica”, orientada a acercar los estándares al perfil documentalista.
  • Sesión IHE centrada en la implantación de XDS en España.

En el segundo día se realizaron distintas intervenciones sobre la interoperabilidad entre sistemas y la integración de dispositivos, presentando diferentes estándares y sistemas que permiten garantizar la continuidad asistencial a distintos niveles. Se destacaron los nuevos retos que tienen los CIOs en cuanto a la interoperabilidad y a la atención de los pacientes crónicos, así como la importancia de la capacitación del ciudadano de manera que forme parte activa de su salud. Estas ponencias se complementaron explicando el papel de los perfiles IHE, de la norma CONTSYS (ISO/DIS 13940) y de los estándares de HL7, incluyendo los de ámbito semántico como CTS2 (Common Terminology Services Release 2). El evento finalizó con la compartición de experiencias y la presentación de distintas herramientas. Des de CCI-OFSTI se realizó una ponencia sobre servicios terminológicos avanzados:

En la presentación se explicó la necesidad de este tipo de servicios, así como las funcionalidades que pueden cubrir las herramientas que los ofrecen. También se presentó el estándar CTS2 que define, a nivel funcional, una interface estándar para el uso y la gestión de terminologías. Para acabar la intervención se resumió la participación del CCI-OFSTI en el grupo de servicios semánticos del proyecto europeo epSOS, en el cual se trabaja con el estándar CTS2.

CCI participa en la impartició del taller d’introducció a SNOMED CT i vocabularis clínics controlats

Leer en castellano

El Centre de Competències d’Integració va participar en la impartició del taller d’introducció a SNOMED CT i vocabularis clínics controlats, organitzat per HL7 Spain. La sessió es va realitzar a Barcelona, els passats dies 15 i 16 de novembre, i també va comptar amb una ponència de l’Oficina d’Estàndards i Interoperabilitat.

El taller va començar amb una presentació de tots els assistents i un repàs als estàndards d’HL7. Es va realitzar una introducció a la terminologia biomèdica i es van explicar els components bàsics i avançats de SNOMED CT. També es va presentar una guia de la gramàtica de l’estàndard, per construir expressions clíniques a través de la post-coordinació. Aquests coneixements es van compaginar amb exercicis pràctics i un cas d’ús basat en l’experiència real del Sistema Sanitari Català. Per acabar, es va introduir l’estàndard CDA R2 i es van presentar les estratègies i eines necessàries per desplegar SNOMED CT a una xarxa assistencial.

L’assistència al taller va ser de 9 alumnes, 4 d’ells de Navarra:

Es pot consultar més informació sobre la formació que el CCI ofereix a través del web: Formació i jornades.

Llegir en català

El Centre de Competències d’Integració participó en la impartición del taller de introducción a SNOMED CT y vocabularios clínicos controlados, organizado por HL7 Spain. La sesión se realizó en Barcelona, los días 15 y 16 de Noviembre y también contó con una ponencia de la Oficina d’Estàndards i Interoperabilitat.

El taller empezó con una presentación de todos los asistentes y un repaso a los estándares de HL7. Se realizó una introducción a la terminología biomédica y se explicaron los componentes básicos y avanzados de SNOMED CT. También se presentó una guía de la gramática del estándar, para construir expresiones clínicas a través de la post-coordinación. Estos conocimientos se compaginaron con ejercicios prácticos y un caso de uso basado en la experiencia real del Sistema Sanitario Catalán. Para acabar, se introdujo el estándar CDA R2 y se presentaron las estrategias y herramientas necesarias para desplegar SNOMED CT en una red asistencial.

La asistencia al taller fue de 9 alumnos, 4 de ellos de Navarra:

Se puede consultar más información sobre la formación que ofrece CCI a través de la web: Formación y jornadas.

Formació SNOMED CT

Leer en castellano

El CCI-TCM (Centre de Competències d’Integració de la fundació Tecnocampus Mataró-Maresme) ofereix serveis de formació en l’àmbit dels Entorns d’Interoperabilitat i el de la Terminologia. Aquesta entrada té per objectiu presentar i explicar en detall les diferents modalitats i tipologies de formació relacionada amb SNOMED CT:

Tallers d’interoperabilitat semàntica al TCM
Aquesta mena de tallers s’organitzen des del CCI-TCM i es realitzen al Tecnocampus Mataró-Maresme, amb la col·laboració de la fundació TicSalut. S’han realitzat dues edicions i la tercera, la inscripció de la qual ja està oberta, està programada pels dies 3 i 4 d’octubre del 2012. La informació sobre aquesta 3a edició es pot consultar a l’enllaç següent: tríptic. A aquesta mena de formació s’expliquen els diferents tipus de llenguatges i vocabularis controlats, es fa una introducció a SNOMED CT i s’aprofundeix en els mecanismes de conjunts de referències creuades (mapejos), subconjunts i extensions. També s’ofereix una visió general del procés de gestió de SNOMED CT a Catalunya i en línia amb el MSSSI (Ministerio de Sanidad, Servicios Sociales e Igualdad) i epSOS (projecte europeu de compartició d’informació clínica), i es fa un repàs a les eines existents que permeten treballar amb la terminologia. Les explicacions teòriques d’aquests conceptes es combinen amb exercicis pràctics de navegació i codificació amb SNOMED CT i de creació de components. El taller d’enguany compta amb varies novetats:

  • Presentació dels subconjunts de SNOMED CT creats per l’HC3 i pautes d’implantació i ús.
  • Cas pràctic de creació de components basat en l’experiència real del Sistema Sanitari Català.
  • Presentació i pràctica del navegador SNOB a més a més de CliniClue Xplore.
  • Cas real de navegació i codificació a partir de l’experiència real de l’Hospital Clínic de Barcelona.

Tallers de SNOMED CT amb HL7
El CCI-TCM ha col·laborat amb HL7 en la impartició de varis tallers sobre SNOMED CT i vocabularis clínics controlats, a diferents Comunitats Autònomes. Aquestes modalitats solen ser més concentrades que els tallers d’interoperabilitat semàntica i inclouen una part d’HL7 i CDA que permet obtenir una visió general de com transmetre i compartir la informació codificada en SNOMED CT.
El dia 18 de juny va començar la primera edició online d’aquesta mena de cursos amb el taller virtual d’introducció a SNOMED CT. L’edició e-learning, programada en 5 setmanes, ha permès augmentar el nivell de detall amb el qual es tracta cada part de SNOMED CT i maximitzar la part pràctica dels tallers. Cada setmana es lliura una unitat teòrica als alumnes, sobre la qual han de realitzar un qüestionari i una pràctica. La informació sobre aquesta primera edició online es pot consultar al següent enllaç: tríptic.

Jornades tècniques i altres accions de difusió
El CCI-TCM també ha participat en les dues edicions de la jornada tècnica de SNOMED CT que s’ha organitzat des de la fundació Doctor Robert, UAB. L’esdeveniment d’enguany va tenir molt d’èxit i va oferir una visió general de l’evolució de SNOMED CT al Sistema Sanitari Català orientada a experts en documentació clínica. El grup també ha participat en altres congressos i jornades que tenen per objectiu potenciar l’ús de les TIC al sector salut, com InforSalut, InforMed, FòrumCis, la segona reunió del foro de Interoperabilidad, etc. amb ponències sobre SNOMED CT.

La informació sobre els cursos, tallers, congressos, etc. en els quals està involucrat el CCI-TCM es pot trobar al web del grup:

La propera entrada tractarà sobre la formació que ofereix el CCI-TCM en l’àmbit dels EI (Entorns d’Interoperabilitat). Avançar que ja està oberta la inscripció per la segona edició del taller d’integració de dispositius mèdics amb Mirth Connect, els dies 26 i 27 de setembre del 2012. La informació relacionada i el formulari d’inscripció es poden consultar a l’enllaç que es presenta a continuació: tríptic.

Llegir en català

CCI-TCM (Centre de Competències d’Integració de la fundación Tecnocampus Mataró-Maresme) ofrece servicios de formación en el ámbito de los Entornos de Interoperabilidad y el de la Terminología. Esta entrada tiene por objetivo presentar y explicar en detalle las diferentes modalidades y tipologías de formación relacionada con SNOMED CT:

Talleres de interoperabilidad semántica en TCM
Este tipo de talleres se organizan des del CCI-TCM y se llevan a cabo en el Tecnocampus Mataró-Maresme, con la colaboración de la fundación TicSalut. Se han realizado dos ediciones y la tercera, cuya inscripción ya está abierta, está programada para los días 3 y 4 de Octubre del 2012. La información sobre esta 3a edición se puede consultar en el enlace siguiente: tríptico. En este tipo de formación se explican los diferentes tipos de lenguajes y de vocabularios controlados, se hace una introducción a SNOMED CT y se profundiza en los mecanismos de conjuntos de referencias cruzadas (mapeos), subconjuntos y extensiones. También se ofrece una visión general del proceso de gestión de SNOMED CT en Catalunya y en línea con el MSSSI (Ministerio de Sanidad, Servicios Sociales e Igualdad) y epSOS (proyecto europeo de compartición de información clínica), y se hace un repaso de las herramientas existentes que permiten trabajar con la terminología. Las explicaciones teóricas de estos conceptos se combinan con ejercicios prácticos de navegación y codificación con SNOMED CT, y de creación de componentes. El taller de este año cuenta con diversas novedades:

  • Presentación de los subconjuntos de SNOMED CT creados para HC3 y pautas de implantación y uso.
  • Caso práctico de creación de componentes basado en la experiencia real del  Sistema Sanitario Catalán.
  • Presentación y práctica del navegador SNOB, a demás de CliniClue Xplore.
  • Caso real de navegación y codificación a partir de la experiencia real del Hospital Clínic de Barcelona.

Talleres de SNOMED CT con HL7
CCI-TCM ha colaborado con HL7 en la impartición de varios talleres sobre SNOMED CT y vocabularios clínicos controlados, en diferentes Comunidades Autónomas. Estas modalidades suelen ser más concentradas que los talleres de interoperabilidad semántica y incluyen una parte de HL7 y CDA, que permite obtener una visión general sobre cómo transmitir y compartir la información codificada con SNOMED CT.
El día 18 de Junio empezó la primera edición online de este tipo de cursos, con el taller virtual de introducción a SNOMED CT. La edición e-learning, programada en 5 semanas, ha permitido aumentar el nivel de detalle con el que se trata cada parte de SNOMED CT y maximizar la parte práctica. Cada semana se entrega a los alumnos una unidad teórica, sobre la cual tienen que realizar un cuestionario y una práctica. La información sobre esta primera edición online se puede consultar en el siguiente enlace: tríptico.

Jornadas técnicas y otras acciones de difusión
CCI-TCM también ha participado en las dos ediciones de la jornada técnica de SNOMED CT, organizada des de la fundación Doctor Robert, UAB. El evento de este año ha tenido un gran éxito y ofreció una visión general de la evolución de SNOMED CT en el Sistema Sanitario Catalán orientada a expertos en documentación clínica. El grupo también ha participado en otros congresos y jornadas que tienen por objetivo potenciar el uso de la TIC en el sector salid, como InforSalut, InforMed, FòrumCis, la segunda reunión del foro de Interoperabilidad, etc. con ponencias sobre SNOMED CT.

La información sobre los cursos, talleres, congresos, etc. en los que está involucrado el CCI-TCM se pueden encontrar en la web del grupo:

La siguiente entrada tratará sobre la formación que ofrece CCI-TCM en el ámbito de los EI (Entornos de Interoperabilidad). Adelantar que ya está abierta la inscripción para la segunda edición del taller de integración de dispositivos médicos con Mirth Connect, los días 26 y 27 de Setiembre del 2012. La información relacionada y el formulario de inscripción se pueden consultar en el enlace que se presenta a continuación: tríptico.