Entrades classificades amb: HL7

SNOMED CT in action incorpora l’espai d’experiències de SNOMED CT del CCI

Leer en castellano
Read It in English

L’espai d’experiències de SNOMED CT que vam iniciar l’any passat al bloc del CCI, s’ha afegit al web “SNOMED CT In Action” de l’IHTSDO.

L’IHTSDO és l’entitat d’àmbit internacional i amb seu a Dinamarca que té la propietat i els drets sobre SNOMED CT. Aquesta organització és la responsable de mantenir la terminologia clínica i de distribuir-la a tots els membres que en formen part. Fa uns mesos l’IHTSDO va encetar l’espai “SNOMED CT In Action”, que conté iniciatives d’ús de SNOMED CT d’una desena de països i en diferents etapes de desenvolupament, des de la planificació fins al funcionament en entorns de producció. En aquesta llista es poden trobar projectes de recerca mèdica, de representació de la informació clínica a la Història Clínica Electrònica (HCE), així com de desenvolupament d’eines per treballar amb vocabularis controlats (com servidors terminològics).

Al següent enllaç podeu consultar l’espai d’experiències en SNOMED CT del CCI: http://blocs.tecnocampus.cat/centre-competencies-integracio/experiencies-snomed-ct/.

I el de l’IHTSDO “SNOMED CT In Action“: http://snomedinaction.org/sct-table.html.


Llegir en català
Read It in English

El espacio de experiencias de SNOMED CT que iniciamos el año pasado en el bloc del CCI, se ha añadido a la web “SNOMED CT In Action” de IHTSDO.

IHTSDO es la entidad de ámbito internacional y con sede en Dinamarca que tiene las propiedad y los derechos sobre SNOMED CT. Esta organización es la responsable de mantener la terminología clínica y de distribuirla a todos los miembros que forman parte de ella. Hace unos meses IHTSDO publicó el espacio “SNOMED CT In Action”, que contiene iniciativas de uso de SNOMED CT de una decena de países y en diferentes etapas de desarrollo, desde planificación hasta al funcionamiento en entornos de producción. En esta lista se pueden encontrar proyectos de investigación médica, de representación de la información clínica en la Historia Clínica Electrónica (HCE), así como de desarrollo de herramientas para trabajar con vocabularios controlados (como servidores terminológicos).

En el siguiente enlace podéis consultar el espacio de experiencias en SNOMED CT del CCI: http://blocs.tecnocampus.cat/centre-competencies-integracio/experiencies-snomed-ct/.

Y el de IHTSDO “SNOMED CT In Action“: http://snomedinaction.org/sct-table.html.


Llegir en català
Leer en castellano

The SNOMED CT experiences site that we published last year in the CCI’s blog, has been included in the “SNOMED CT In Action” website of IHTSDO.

IHTSDO is the organisation with an international scope and stablished in Denmark that has the property and the rights of SNOMED CT. This institution is responsible of maintaining the clinical terminology and of distribute it to all its members. Some months ago, IHTSDO published the website “SNOMED CT In Action”, that contains initiatives on the use of SNOMED CT in around ten countries in different stages of development, from planning to implemented and living ones. In this list you can find projects on medical research, representation of the clinical information in Electronic Health Record (EHR), as well as development of tools that allows to work with controlled vocabularies (like terminology servers).

In the next link you can find the SNOMED CT experiences site of CCI: http://blocs.tecnocampus.cat/centre-competencies-integracio/experiencies-snomed-ct/.

And the IHTSDO “SNOMED CT In Action” one: http://snomedinaction.org/sct-table.html.


WiFIS (Workflow en Institucions de Salut)

Leer en castellano
Read It in English
Què és WiFIS?

WiFIS, anomenat en un primer moment WFIS, és el projecte origen del Marc d’Interoperabilitat que neix de la necessitat d’interconnectar diferents centres sanitaris de l’àmbit català per intercanviar informació i realitzar diverses transaccions, d’un mode ràpid i eficient, fent servir estàndards reconeguts internacionalment com és per exemple l’estàndard HL7 per a la missatgeria XML, o SNOMED CT per a la terminologia que es fa servir en els missatges.

En el Marc d’Interoperabilitat de WiFiS es defineix el model amb el qual es pot dur a terme la normalització dels processos i comunicacions entre entitats de salut, i per tant, es defineixen regles, models d’intercanvi d’informació, missatges, terminologia i altre documentació d’interès. Això significa, que tots els centres que implementin aquest Marc d’Interoperabilitat, i per tant, que compleixin amb WiFIS, podran enviar-se informació entre ells i comunicar-se d’un mode interoperable garantint en tot moment la seguretat d’aquesta informació.

Plataforma central

Per aconseguir aquesta interoperabilitat entre els centres sanitaris que compleixin amb el Marc d’Interoperabilitat de WiFIS, hi haurà una plataforma única central que farà d’enrutament de tota la missatgeria que s’intercanviïn els centres.

Si be, a data de publicació d’aquest post, la plataforma central encara no està disponible pels centres, sí que és veritat que ja hi ha centres (i alguns, des de fa més de dos anys) que fan servir el protocol WiFIS per comunicar-se entre ells fent servir altres plataformes que han desenvolupat ells mateixos o contractant una plataforma que han desenvolupat uns altres.

Els processos

En el Marc d’Interoperabilitat de WiFiS es defineixen actualment 5 processos que es divideixen segons les àrees funcionals.

Aquests processos són:

  • Derivacions de proves, el principal procés d’un centre, permet a un centre derivar a un pacient a un altre centre per demanar fer-li algun tipus de prova concret.
  • eConsultes, és un procés que es realitza per obtenir un diagnòstic sobre una prova concreta sense haver d’enviar-hi el pacient com a les derivacions.
  • Cites, és el procés que permet demanar cita per el pacient quan aquest es deriva d’un centre a un altre.
  • Consulta Dades, conté les consultes que es poden fer entre centres per obtenir dades addicionals per realitzar els processos desitjats.
  • Laboratori, conté tot el que fa referència a gestionar peticions de laboratori.

Actualment s’està definint un nou procés, anomenat “Notificacions”, que agruparà els casos d’ús que serveixen per enviar qualsevol tipus de notificació, i que no van lligats a cap derivació.

Cadascun d’aquests processos abasteix una sèrie de casos d’ús que permet realitzar les transaccions necessàries per complir amb les necessitats dels centres, i cadascun dels casos d’ús està format pels missatges que s’utilitzen per intercanviar la informació entre un centre peticionari i un centre proveïdor.

Els missatges que s’han definit pels casos d’ús estan basats en l’estàndard HL7, però s’han simplificat (sempre complint amb l’estàndard) per tal de facilitar l’adaptació dels centres al Marc d’Interoperabilitat de WiFIS.

Plataforma de validació

Els centres que vulguin demostrar aquest 2014 any que compleixen amb el protocol de WiFIS, i que per tant, tenen intenció d’integrar-se amb la plataforma central de WiFIS quan aquesta estigui llesta, podran connectar-se aviat amb l’anomenada “Plataforma de validació”, que permet realitzar un conjunt de validacions en una mostra de missatges de WiFIS dels processos de Derivacions de proves i de Cites procedents dels centres externs, i poder així dictaminar si compleixen les especificacions WiFIS.

La documentació

Tota la documentació referent al projecte WiFIS es pot trobar en el següent enllaç:

http://www.ticsalut.cat/estandards/interoperabilitat/wifis/

En la pàgina es pot descarregar la Guia bàsica de WiFIS, pensat pels que no estiguin familiaritzats amb WiFIS, i que conté informació bàsica per entendre el projecte i tenir una visió general.

A la mateixa pàgina es poden trobar dos enllaços diferenciats:

  • Documentació del Marc D’interoperabilitat de WiFIS
  • Reunions del grup de treball

En el primer enllaç porta a una altra pàgina on es pot descarregar tot el material que hi ha actualment publicat de WiFIS. Aquest es troba dividit pels diferents processos o dominis, com són Derivacions, Cites o Laboratori, a més d’un paquet anomenat “General”, que conté documentació comuna a tots els processos, com són el document que parla del Marc d’Interoperabilitat, el document que conté totes les taules HL7 i d’usuari que es fan servir en els missatges, o els esquemes .xsd per validar els missatges XML.

Les reunions del grup de WiFIS

Prement l’enllaç de “Reunions del grup de treball”, es mostra una pàgina amb el llistat de reunions que s’han realitzat amb el grup de treball de WiFIS, la data que es van realitzar, la ubicació, i l’acta en format pdf per descarregar on es descriu tot el parlat i acordat en dites reunions. Aquestes reunions, de moment, són de caràcter obert, i per tant, qualsevol interessat en el projecte WiFIS pot assistir.

L’objectiu d’aquest grup de treball és debatre sobre propostes que un o varis dels participants del grup considerin que ha de ser contemplat i recollit dins del projecte WiFIS. Poden ser, o bé perquè es vol afegir un nou cas d’ús o nous camps en els missatges, o bé per acordar nous canvis a l’actual guia de WiFIS.

Les convocatòries a les reunions es publiquen en la secció de notícies (http://www.ticsalut.cat/estandards/interoperabilitat/noticies/ ), i per tant, les persones que es volen inscriure per assistir a les reunions, han d’omplir un petit formulari, el qual es troba en un mateix enllaç dins de la mateixa noticia.

A més, qualsevol usuari es pot subscriure a les publicacions de notícies RSS de la web de TicSalut, per saber quan es publiquen notícies relacionades amb el projecte WiFIS, agregant l’enllaç següent: http://feeds.feedburner.com/interoperabilitat-ticsalut

Llegir en català
Read It in English
¿Qué es WiFIS?

WiFIS, denominado en un primer momento WFIS, es el proyecto origen de Marco de Interoperabilidad que nace de la necesidad de interconectar diferentes centros sanitarios del ámbito catalán para intercambiar información y realizar varias transacciones, de un modo rápido y eficiente, usando estándares reconocidos internacionalmente cómo es por ejemplo el estándar HL7 para la mensajería XML, o SNOMED CT para la terminología que se usa en los mensajes.

En el Marco de Interoperabilidad de WiFiS se define el modelo con el cual se puede llevar a cabo la normalización de los procesos y comunicaciones entre entidades de salud, y por lo tanto, se definen las reglas, modelos de intercambio de información, mensajes, terminología y otra documentación de interés. Esto significa, que todos los centros que implementen este Marco de Interoperabilidad, y por lo tanto, que cumplan con WiFIS, podrán enviarse información entre ellos y comunicarse de un modo interoperable garantizando en todo momento la seguridad de esta información.

Plataforma central

Para conseguir esta interoperabilidad entre los centros sanitarios que cumplan con el Marco de Interoperabilidad de WiFIS, habrá una plataforma única central que hará de enrutamiento de toda la mensajería que se intercambien los centros.

Si bien, a fecha de publicación de este post, la plataforma central todavía no está disponible para los centros, sí que es verdad que ya hay centros (y algunos, desde hace más de dos años) que usan el protocolo WiFIS para comunicarse entre ellos usando otras plataformas que han desarrollado ellos mismos o contratando una plataforma que han desarrollado otros.

Los procesos

En el Marc de Interoperabilidad de WiFiS se definen actualmente 5 procesos que se dividen según las áreas funcionales.
Estos procesos son:

  • Derivaciones de pruebas, el principal proceso de un centro, permite en un centro derivar a un paciente a otro centro para pedir hacerle algún tipo de prueba concreto.
  • eConsultas, es un proceso que se realiza para obtener un diagnóstico sobre una prueba concreta sin tener que enviar el paciente como en las derivaciones.
  • Citas, es el proceso que permite pedir cita por el paciente cuando este se deriva de un centro a otro.
  • Consulta Datos, contiene las consultas que se pueden hacer entre centros para obtener datos adicionales para realizar los procesos deseados.
  • Laboratorio, contiene todo el que hace referencia a gestionar peticiones de laboratorio.

Actualmente se está definiendo un nuevo proceso, denominado “Notificaciones”, que agrupará los casos de uso que sirven para enviar cualquier tipo de notificación, y que no van ligados a ninguna derivación.

Cada uno de estos procesos alcanza una serie de casos de uso que permite realizar las transacciones necesarias para cumplir con las necesidades de los centros, y cada uno de los casos de uso está formado por los mensajes que se utilizan para intercambiar la información entre un centro peticionario y un centro proveedor.

Los mensajes que se han definido para los casos de uso están basados en el estándar HL7, pero se han simplificado (siempre cumpliendo con el estándar) para facilitar la adaptación de los centros al Marco de Interoperabilidad de WiFIS.

Plataforma de validación

Los centros que quieran demostrar este 2014 año que cumplen con el protocolo de WiFIS, y que por lo tanto, tienen intención de integrarse con la plataforma central de WiFIS cuando esta esté disponible, podrán conectarse pronto con la llamada “Plataforma de validación”, que permite realizar un conjunto de validaciones en una muestra de mensajes de WiFIS de los procesos de Derivaciones de pruebas y de Citas procedentes de los centros externos, y poder así dictaminar si cumplen las especificaciones WiFIS.

La documentación

Toda la documentación en lo referente al proyecto WiFIS se puede encontrar en el siguiente enlace:
http://www.ticsalut.cat/estandards/interoperabilitat/wifis/

En la página se puede descargar la Guía básica de WiFIS, pensado para los que no estén familiarizados con WiFIS, y que contiene información básica para entender el proyecto y tener una visión general.

En la misma página se pueden encontrar dos enlaces diferenciados:

  • Documentación del Marco de interoperabilidad de WiFIS
  • Reuniones del grupo de trabajo

En el primer enlace lleva a otra página donde se puede descargar todo el material que hay actualmente publicado de WiFIS. Este se encuentra dividido por los diferentes procesos o dominios, como son Derivaciones, Citas o Laboratorio, además de un paquete llamado “General”, que contiene documentación común a todos los procesos, como son el documento que habla del Marco de Interoperabilidad, el documento que contiene todas las tablas HL7 y de usuario que se usan en los mensajes, o los esquemas .xsd para validar los mensajes XML.

Las reuniones del grupo de WiFIS

Pulsando en el enlace de “Reuniones del grupo de trabajo”, se muestra una página con el listado de reuniones que se han realizado con el grupo de trabajo de WiFIS, la fecha que se realizaron, la ubicación, y el acta en formato pdf para descargar donde se describe todo lo hablado y acordado en dichas reuniones. Estas reuniones, de momento, son de carácter abierto, y por lo tanto, cualquier interesado en el proyecto WiFIS puede asistir.

El objetivo de este grupo de trabajo es debatir sobre propuestas que uno o varios de los participantes del grupo consideren que tiene que ser contemplado y recogido dentro del proyecto WiFIS. Pueden ser, o bien porque se quiere añadir un nuevo caso de uso o nuevos campos en los mensajes, o bien para acordar nuevos cambios a la actual guía de WiFIS.

Las convocatorias a las reuniones se publican en la sección de noticias (http://www.ticsalut.cat/estandards/interoperabilitat/noticies/), y por lo tanto, las personas que quieran inscribirse para asistir a las reuniones, tienen que rellenar un pequeño formulario, el cual se encuentra en un mismo enlace dentro de la misma noticia.

Además, cualquier usuario se puede subscribir a las publicaciones de noticias RSS de la web de TicSalut, para saber cuándo se publican noticias relacionadas con el proyecto WiFIS, agregando el enlace siguiente: http://feeds.feedburner.com/interoperabilitat-ticsalut

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

Formació línia terminologia del CCI

Leer en castellano

Des de la línia de terminologia del CCI i en col·laboració amb altres entitats com HL7Spain i TicSalut, oferim formació en interoperabilitat semàntica tant per professionals amb perfil assistencial com tècnic:

Taller presencial de SNOMED CT i vocabularis clínics controlats
Taller de 10 hores organitzades en dos matins que té per objectiu realitzar una introducció als tipus de vocabularis que s’utilitzen a l’entorn salut i aprofundir en la terminologia clínica SNOMED CT. S’hi expliquen els components bàsics i avançats de SNOMED CT, es mostra com crear expressions clíniques usant l’estàndard i com utilitzar-les a documents estructurats CDA.
Els conceptes teòrics es complementen amb exercicis i un cas d’ús basat en l’experiència real del Sistema Sanitari Català.

Els passats dies 30 i 31 de maig se’n va realitzar una edició a Barcelona organitzada per HL7Spain, CCI i TicSalut, amb 9 alumnes de diferents regions d’Espanya.

Taller virtual d’introducció a SNOMED CT
Aquest taller és la versió virtual de l’anterior, organitzada en 5 setmanes i completament online. Cada setmana els alumnes treballen una unitat didàctica, sobre la qual responen un qüestionari d’autoavaluació i en fan un exercici pràctic.

A principis d’any es va realitzar la segona edició del taller virtual d’introducció a SNOMED CT organitzada per HL7Spain, CCI i TicSalut. L’acció formativa va comptar amb la participació de 34 alumnes de diferents regions d’Espanya, Mèxic i Argentina.

El proper dia 16 de gener arrenca la tercera edició d’aquest taller que encara té inscripció oberta.

 

Taller virtual de serveis de terminologia clínica
Aquest taller online també està organitzat en 5 setmanes i combina els coneixements teòrics de cada unitat didàctica amb qüestionaris i casos pràctics.
Al llarg del curs es posa el focus en l’ús que es pot fer de la terminologia amb eines de suport i a través de serveis, de manera que permet explorar des dels vocabularis controlats fins a la seva explotació als sistemes d’informació sanitaris. El pla d’actuació del taller està format pels següents blocs:

  • Introducció a SNOMED CT i altres terminologies clíniques. Catàleg de vocabularis controlats.
  • Serveis de terminologia clínica. Eines, estratègies i estàndards d’informació.
  • Guia d’implementació de SNOMED CT. Especificació, escenaris i optimització de serveis.
  • Definició de “Clinical Statements” amb HL7 RIM i SNOMED CT. La base per emmagatzemar i compartir coneixement clínic.
  • Generació de documents clínics HL7 CDA amb el suport de serveis de terminologia. Explotació d’un repositori de documents amb XML i estàndards internacionals.

Al setembre passat es va realitzar la primera edició del taller virtual de serveis de terminologia clínica amb 21 alumnes de diferents regions d’Espanya i Xile i organitzat per HL7Sapin, CCI, BITAC i TicSalut.

Llegir en català

Desde la línea de terminología del CCI y en colaboración con otras entidades como HL7Sapin y TicSalut, ofrecemos formación en interoperabilidad semántica tanto para profesionales con perfil asistencial como técnico:

Taller presencial de SNOMED CT y vocabularios clínicos controlados
Taller de 10 horas organizadas en dos mañanas que tienen por objetivo realizar una introducción a los tipos de vocabularios que se utilizan en el entorno salud y profundizar en la terminología clínica SNOMED CT. Se explican los componentes básicos y avanzados de SNOMED CT, se muestra cómo crear expresiones clínicas usando el estándar y cómo utilizarlas en documentos estructurados CDA.
Los conceptos teóricos se complementan con ejercicios y un caso de uso basado en la experiencia real del Sistema Sanitario Catalán.

Los pasados días 30 y 31 de Mayo se realizó una edición en Barcelona organizada por HL7Spain, CCI y TicSalut, con 9 alumnos de diferentes regiones de España.

Taller virtual de introducción a SNOMED CT
Este taller es la versión virtual de la anterior, organizada en 5 semanas y completamente online. Cada semana los alumnos trabajan una unidad didáctica, sobre la cual responden un cuestionario de autoevaluación y resuelven un ejercicio práctico.

A principios de este año se realizó la segunda edición del taller virtual de introducción a SNOMED CT organizada por HL7Sapin, CCI y TicSalut. La acción formativa contó con la participación de 34 alumnos de diferentes regiones de España, Méjico y Argentina.

El próximo día 16 de Enero empieza la tercera edición de este taller que aún tiene inscripción abierta.

 

Taller virtual de servicios de terminología clínica
Este taller online también está organizado en 5 semanas y combina los conocimientos teóricos de cada unidad didáctica con cuestionarios y casos prácticos.
El curso se centra en el uso que se puede hacer de la terminología con herramientas de soporte y a través de servicios, de manera que permite explorar des de los vocabularios controlados hasta su explotación en los sistemas de información sanitarios. El plan de actuación del taller está formado por los siguientes bloques:

  • Introducción a SNOMED CT y otras terminologías clínicas. Catálogo de vocabularios clínicos controlados.
  • Servicios de terminología clínica. Herramientas, estrategias y estándares de información.
  • Guía de implementación de SNOMED CT. Especificación, escenarios y optimización de servicios.
  • Definición de “Clinical Statements” con HL7 RIM y SNOMED CT. La base para almacenar y compartir conocimiento clínico.
  • Generación de documentos clínicos HL7 CDA con el soporte de servicios de terminología. Explotación de un repositorio de documentos con XML y estándares internacionales.

La primera edición del taller virtual de servicios de terminología clínica arrancó en Septiembre con 21 alumnos de distintas regiones de España y Chile, y organizado por Hl7Sapin, CCI, BITAC y TicSalut.

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

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

Leer en castellano

El passat dia 12 de novembre es va celebrar la jornada tècnica “Interoperabilidad, la base para una atención integrada del paciente crónico” a Madrid, organitzada per HL7Spain, IHE España  i HIMSS Europe CIO Summit: CIO of the Future.

La jornada tenia per objectiu presentar els avenços en interoperabilitat, examinar l’impacte dels estàndards en el domini de l’atenció integrada del pacient crònic i obrir un espai de debat i reflexió per part dels professionals del sector TIC en salut.

Des del Centre de Competències d’Integració es va presentar l’estàndard d’HL7 CCS (Care Coordination Service), que defineix les funcionalitats necessàries per assolir una gestió coordinada dels pacients a través del continu assistencial:

CCS és una iniciativa oberta de desenvolupament d’estàndard/especificació d’HL7  del projecte Coordination of Care Services Specification, sobre la qual està planificat definir també una especificació SOA per part d’OMG (Object Management Group). El programa HSSP (Healthcare Services Specification Program) engloba la col·laboració d’HL7 (que desenvolupa el model funcional) i OMG (qui en fa la corresponent especificació tècnica) per completar varis estàndards. CCS està format per tres elements:

  • Capacitats: Habilitats d’organitzacions, sistemes o persones a partir de les quals es defineixen les funcionalitats i que seran els requeriments per a l’especificació tècnica. Es la part que està més desenvolupada i es correspon amb el nucli del contingut normatiu.
  • Perfils funcionals: Paquets de funcionalitats. Actualment en definició.
  • Escenaris de negoci: Context principal i secundaris en els quals s’apliquen les funcionalitats. Actualment en definició.

El CCI i l’OFSTI (Oficina d’Estàndards i interoperabilitat) de la fundació TicSalut han publicat recentment un informe resum sobre l’estàndard que es pot trobar al web de l’OFSTI: Notícia publicació informe CCS.

La jornada també va comptar amb la participació de l’OFSTI en una ponència sobre la integració de dispositius de mobilitat mHealth, així com de varis representants de la indústria, proveïdors assistencials i administracions públiques.

Llegir en català

El pasado día 12 de Noviembre se celebró la jornada técnica “Interoperabilidad, la base para una atención integrada del paciente crónico” en Madrid, organizada por HL7Spain, IHE España  y HIMSS Europe CIO Summit: CIO of the Future.

La jornada tenía por objetivo presentar los avances en interoperabilidad, examinar el impacto de los estándares en el dominio de la atención integrada del paciente crónico y abrir un espacio de debate y reflexión por parte de los profesionales del sector TIC en salud.

Des del Centre de Competències d’Integració se presentó el estándar de HL7 CCS (Care Coordination Service), que define las funcionalidades necesarias para alcanzar una gestión coordinada de los pacientes a través del continuo asistencial:

CCS es una iniciativa abierta de desarrollo de estándar/especificación de HL7 del proyecto Coordination of Care Services Specification, sobre la cual está planificado definir también una especificación SOA por parte de OMG (Object Management Group). El programa HSSP (Healthcare Services Specification Program) engloba la colaboración de HL7 (que desarrolla el modelo funcional) y OMG (quien realiza la correspondiente especificación técnica) para completar varios estándares. CCS está formado por tres elementos:

  • Capacidades: Habilidades de organizaciones, sistemas o personas a partir de las cuales se definen las funcionalidades y que serán los requerimientos para la especificación técnica. Es la parte que está más desarrollada y se corresponde con el núcleo del contenido normativo.
  • Perfiles funcionales: paquetes de funcionalidades. Actualmente en definición.
  • Escenarios de negocio: Contexto principal y secundarios en los cuales se aplican las funcionalidades. Actualmente en definición.

CCI y la OFSTI (Oficina d’Estàndards i interoperabilitat) de la fundación TICSalut han publicado recientemente un informe resumen sobre el estándar que se puede encontrar en la web de la OFSTI: Noticia publicación informe CCS.

La jornada también contó con la participación de la OFSTI en una ponencia sobre la integración de dispositivos de movilidad mHealth, así como de varios representantes de la industria, proveedores asistenciales y administraciones públicas.

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

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

3a reunió de Foro de Interoperabilidad en Salud

Leer en castellano

El CCI-OFSTI va participar els dies 7 i 8 de maig a la tercera reunió del Fòrum d’Interoperabilitat en Salut, organitzat per la SEIS (Sociedad Española de Informática de la Salud), que es va celebrar a La Granja San Ildefonso. L’edició d’enguany es va centrar en la innovació entorn de les TIC aplicades a l’àmbit sanitari, la interoperabilitat organitzativa i les plataformes de telesalut i teleassistència.

A les dues primeres sessions “Plataformas de Interoperabilidad” i “Interoperabilidad organizativa”, es van presentar els avenços dels respectius grups de treball d’AENOR (comitè tècnic 139 de TIC per salut al qual participa l’OFSTI). Al grup de plataformes de telesalut i teleassistència s’està treballant en una taxonomia que permeti classificar les plataformes existents en dimensions amb nivells. Al d’interoperabilitat organitzativa s’ha revisat la norma ISO/DIS 13940 (també coneguda com a CONTSYS), aplicant-la a casos d’ús reals, per a la votació de pas a normativa ISO.

Des del CCI-OFSTI es va realitzar una presentació a la sessió de plataformes d’Interoperabilitat, sobre el model d’assistència no presencial i l’estat de les plataformes de telesalut i teleassistència al Sistema Sanitari Català:

Al primer bloc també es va exposar l’ús d’una plataforma d’interoperabilitat d’HCE pel suport a la recerca i que permet l’intercanviar d’extractes clínics anonimitzats. La sessió va finalitzar amb una intervenció sobre l’evolució del punt de cura, i les necessitats d’interoperabilitat dels dispositius mèdics derivades, l’estat de l’art dels estàndards a utilitzar i lliçons apreses en la seva aplicació.

La segona sessió va començar amb una presentació sobre l’aplicació de la norma CONTSYS, aportant experiències reals tant a nivell nacional com internacional. La següent intervenció es va centrar en la dificultat d’assolir la interoperabilitat organitzativa i la seva importància a l’HCDSNS (Historia Clínica Digital del Sistema Nacional de Salud). Per últim s’explicà com les solucions basades en models poden potenciar l’interoperabilitat organitzativa.

Al tercer bloc “Actividades de I+D+I en Interoperabilidad” es van exposar iniciatives relatives al perfil XDS (Cross-Enterprise Document Sharing) d’IHE, la definició de guies clíniques amb llenguatge GDL (Guide Definition Language), la combinació d’estàndards d’HCE i tecnologies semàntiques i a les activitats de la Universitat de Sevilla. En la mateixa línia, a la quarta sessió “Potencial de Innovación tecnológica para la Interoperabilidad” des de la indústria es van presentar innovacions en la creació i gestió de repositoris de dades clíniques normalitzades, l’evolució cap a una HEI (Història Electrònica d’Imatge), l’impacte de la interoperabilitat en la continuïtat assistencial i l’oficina d’integració a València.

A la darrera sessió del fòrum “Normalización e Innovación en TICs en los Servicios de Salud”, representants dels serveis de Salud de Madrid, Castilla La Mancha, Castilla y León i Andalusia van aportar una visió general de l’estat del Servei en quant a normalització i iniciatives d’innovació i investigació.

Al següent enllaç es pot consultar el programa del congrés.

Llegir en català

El CCI-OFSTI participó los días 7 y 8 de Mayo en la tercera reunión del Foro de Interoperabilidad, organizado por la SEIS (Sociedad Española de Informática de la Salud), que se celebró en La Granja San Ildefonso. La edición de este año se centró en la innovación entorno de las TIC aplicadas al ámbito de la salud, la interoperabilidad organizativa y las plataformas de telesalud y teleasistencia.

En las dos primeras sesiones “Plataformas de Interoperabilidad” y “Interoperabilidad organizativa” se presentaron los avances de los respectivos grupos de trabajo de AENOR (comité técnico 139 de TIC para la salud en el cual participa la OFSTI). En el grupo de plataformas de telesalud y teleasistencia se está trabajando en una taxonomía que permita clasificar las plataformas existentes en dimensiones con niveles. En el de interoperabilidad organizativa se ha revisado la norma ISO/DIS 13940 (también conocida como CONTSYS), aplicándola a casos de uso reales, para la votación de paso a normativa ISO.

Des del CCI-OFSTI se realizó una presentación en la sesión de plataformas de Interoperabilidad sobre el modelo asistencial no presencial y el estado de las plataformas de telesalud y teleasistencia en el Sistema Sanitario Catalán:

En el primer bloque también se expuso el uso de una plataforma de interoperabilidad de HCE para el soporte a la investigación que permite el intercambio de extractos clínicos anonimizados. La sesión finalizó con una intervención sobre la evolución del punto de atención, y las necesidades de interoperabilidad de los dispositivos médicos derivadas, el estado del arte de los estándares a utilizar y lecciones aprendidas en su aplicación.

La segunda sesión comenzó con una presentación sobre la aplicación de la norma CONTSYS, aportando experiencias reales tanto a nivel nacional como internacional. La siguiente intervención se centró en la dificultad de alcanzar la interoperabilidad organizativa y su importancia en la HCDSNS (Historia Clínica Digital del Sistema Nacional de Salud). Por último se explicó cómo las soluciones basadas en modelos pueden potenciar la interoperabilidad organizativa.

En el tercer bloque “Actividades de I+D+I en Interoperabilidad” se expusieron iniciativas relativas al perfil XDS (Cross-Enterprise Document Sharing) de IHE, la definición de guías clínicas con lenguaje GDL (Guide Definition Language), la combinación de estándares de HCE y tecnologías semánticas y las actividades de la Universidad de Sevilla. Siguiendo la misma línea, en la cuarta sesión “Potencial de Innovación tecnológica para la Interoperabilidad”, desde la industria se presentaron innovaciones en la creación y gestión de repositorios de datos clínicos normalizados, la evolución hacia una HEI (Historia Electrónica de Imagen), el impacto de la interoperabilidad en la continuidad asistencial y la oficina de integración en Valencia.

En la última sesión del foro “Normalización e Innovación en TICs en los Servicios de Salud”, representantes de los servicios de Salud de Madrid, Castilla La Mancha, Castilla y León y Andalucía aportaron una visión general del estado del Servicio en cuanto a normalización e iniciativas de innovación e investigación.

En el siguiente enlace se puede consultar el programa del congreso.

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

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)

Review de Messaging Workbench

Leer en castellano
 

L’entorn de treball de missatgeria Messagging Workbench (MWB) és una eina de productivitat polivalent destinada a implementadors d’HL7 v2.x. Aquesta eina vol facilitar el ràpid desenvolupament d’especificacions i informes. MWB també incorpora un servei de validació de missatges en línia i un generador de missatges per utilitzar en proves. MWB permet la documentació dels missatges/perfils HL7 que un equip de desenvolupament en farà ús i provarà aquestes definicions per tenir consistència amb HL7 i els altres estàndards locals.

Els missatges poden ser creats sobre la base dels arxius de llibreria que representen en cada versió de l’estàndard HL7, per l’entrada inversa o a través d’entrada manual. A més es poden desenvolupar biblioteques addicionals per a convencions implementades a nivell local. L’eina també inclou un banc de diagrames MWB per facilitar una major varietat de formes redimensionables i configurables per així crear múltiples diagrames de forma lliure per a cada perfil. Els diagrames també poden ser importats d’altres eines que produeixen sortides BMP o JPG tal com pot ser Visio.

Amb Messaging Workbench es poden generar, imprimir i exportar una àmplia gamma d’informes. L’eina també pot generar missatges de prova per als perfils dissenyats i capturar les transaccions que es poden validar contra perfils dissenyats. També es pot utilitzar per registrar els comentaris sobre els perfils.

Resumint, MWB es una bona eina molt polivalent per definir, generar i validar perfils de missatges HL7, així com la creació de llibreries personalitzades a partir de ja existents, definició de tipus de dades que contindrà el perfil, i també la generació de fitxers XML amb els perfils de missatges creats, entre d’altres funcions. Com a punts negatius cal destacar que la eina només es pot executar des d’un entorn Windows i el seu ús es pot fer una mica difícil i enrevessat degut a la gran quantitat de funcionalitats i opcions que disposa la eina.

 


Llegir en català

 

El entorno de trabajo de mensajería Messagging Workbench (MWB) es una herramienta de productividad polivalente destinada a implementadores de HL7 v2.x. Esta herramienta pretende facilitar el rápido desarrollo de especificaciones e informes. MWB también incorpora un servicio de validación de mensajes en línea y un generador de mensajes para utilizar en pruebas. MWB permite la documentación de los mensajes/perfiles HL7 que un equipo de desarrollo hará uso y probará estas definiciones para tener consistencia con HL7 y los otros estándares locales.

Los mensajes pueden ser creados sobre la base de los archivos de librería que representan en cada versión del estándar HL7, por la entrada inversa o através de entrada manual. Además se pueden desarrollar bibliotecas adicionales para convenciones implementadas a nivel local. La herramienta también incluye un banco de diagramas MWB para facilitar una mayor variedad de formas redimensionables y configurables para así crear múltiples diagramas de forma libre para cada perfil. Los diagramas también pueden ser importados de otras herramientas que producen salidas BMP o JPG tal como puede ser Visio.

Con Messaging Workbench se pueden generar, imprimir y exportar una amplia gama de informes. La herramienta también puede generar mensajes de prueba para los perfiles diseñados y capturar las transacciones que se pueden validar contra perfiles diseñados. También se puede utilizar para registrar los comentarios sobre los perfiles.

Resumiendo, MWB es una buena herramienta muy polivalente para definir, generar y validar perfiles de mensajes HL7, así como la creación de librerías personalizadas a partir de ya existentes, definición de tipo de datos que contendrá el perfil, y también la generación de ficheros XML con los perfiles de mensajes creados, entre otras funciones. Como puntos negativos cabe destacar que la herramienta sólo se puede ejecutar desde un entorno Windows y su uso se puede hacer un poco difícil y lioso debido a la gran cantidad de funcionalidades y opciones que dispone la herramienta.

 



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.