Entrades classificades amb: Integració

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)

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)

Jornada de formació de Marcatge CE en Tecnologies Sanitàries i Especial Medical Mobile Apps

Leer en castellano
Read It in English

El passat dia 28 de novembre el Centre de Competències d’Integració (CCI) va participar a la jornada de formació sobre el Marcatge CE , Tecnologies Sanitàries i sobre Aplicacions Mèdiques Mòbils. Els assistents, la gran majoria fabricants de productes sanitaris i metges, van considerar molt útil tota la informació d’actualitat que s’hi va presentar.

La jornada es va dividir en dues parts ben diferenciades, durant el mati es va presentar la nova normativa referent al marcatge CE pel que fa a productes sanitaris i el procés que tots els fabricants han de realitzar per aconseguir l’etiquetatge CE en els seus productes. En segon lloc, durant la tarda es va destinar part de la jornada a parlar sobre l’actual creixent impacte de les aplicacions mòbils al mercat sanitari, un aspecte clau que s’ha de tenir molt en compte a l’hora d’avaluar i certificar la seguretat en totes aquelles aplicacions que es poden trobar avui dia en molts dispositius mòbils. Aquesta segona part de la jornada va comptar amb la participació de dos grans experts amb el tema de eHealth, el Sr. Carlos Gallego, director de l’Oficina d’Estàndards i Interoperabilitat (OFSTI) de la Fundació TicSalut que va presentar un primer avenç de com s’haurien d’homologar les aplicacions mòbils en salut, i el Sr. Miguel Angel Mayer, actual director del Departament de Web Mèdica Acreditada(WMA) del Col·legi Oficial de Metges de Barcelona (COMB) que va presentar quina és la pràctica mèdica actual sobre les apps i també va exposar els perills que aquestes apps poden provocar, i com cal certificar-les i validar-les per garantir la seguretat de tots els ciutadans que les utilitzin.

Marcatge CE en Productes Sanitaris

Actualment els productes sanitaris de la mateixa manera que succeeix amb els medicaments estan subjectes a les reglamentacions de cada país i no són de lliure comercialització. Esta regulat el seu disseny, la seva fabricació, la seva comercialització, distribució i venta, així com la publicitat i les accions en el mercat després de la seva comercialització.

La normativa actual de referència pel nostre país és el Real Decreto 1591/2009 que parla sobre productes sanitaris en general, el Real Decreto 1616/2009 que tracta sobre els implants actius, i el Real Decreto 1662/2000 que està enfocat al diagnòstic in vitro.

Medical Mobile Apps

Entenem doncs, que els producte sanitari no només són els dispositius mèdics, sinó que també ho poden ser les múltiples aplicacions mòbils en salut que actualment es poden trobar al mercat. Per tant , és important tenir en compte i diferenciar què és un producte sanitari del que no ho és. Per exemple, una aplicació que ens indiqui el nostre nivell de glucosa, o ens mostri el resultat d’una radiografia és un producte sanitari, en canvi, una aplicació que ens indiqui les nostres pulsacions quan anem a corre no estaria considerat dins de la legislació vigent com a producte sanitari.

Per tant, tot aquest mercat d’aplicacions que els usuaris poden obtenir a través d’Internet i a través dels seus dispositius mòbils poden resultar un perill si no es manté una regulació per garantir la seguretat, privacitat de la informació introduïda en l’aplicació i un correcte ús funcional i assistencial que les aplicacions poden oferir. Un mal ús de les apps en salut pot donar lloc a resultats no desitjats, com per exemple, causar diagnòstics erronis que poden provocar un efecte nociu en la salut del ciutadà.

És per aquest motiu, que cal obtenir un marc regulatori que identifiqui i certifiqui aquelles apps acceptables d’aquelles que no ho són. Actualment s’està treballant perquè properament sorgeixin regulacions a tal efecte ja que actualment no n’hi ha cap que garanteixi el bon ús de les apps en l’entorn sanitari.

Llegir en català
Read It in English

El pasado día 28 de noviembre el Centro de Competencias de Integración (CCI) participó en la jornada de formación sobre el Marcaje CE, Tecnologías Sanitarias y Aplicaciones Médicas Móviles. Los asistentes, la gran mayoría fabricantes de productos sanitarios y médicos, consideraron muy útil toda la información de actualidad que se presentó.

La jornada se dividió en dos partes claramente diferenciadas, durante la mañana se presentó la nueva normativa de referencia de marcaje CE en productos sanitarios y el proceso que todos los fabricantes deben realizar para conseguir el etiquetado CE en sus productos sanitarios. En segundo lugar, durante la tarde se destinó parte de la jornada a hablar sobre el actual crecimiento e impacto de las aplicaciones móviles en el mercado sanitario, un aspecto clave que se tiene que tener muy en cuenta a la hora de evaluar y certificar la seguridad en todas aquellas aplicaciones que se pueden encontrar hoy en día en muchos de los dispositivos móviles. Ésta segunda parte de la jornada, contó con la participación de dos grandes expertos en el tema de eHealth, el Sr. Carlos Gallego, director de la Oficina de Estándares e Interoperabilidad (OFSTI) de la Fundación TicSalut que presentó un primer avance de cómo se deberían homologar las aplicaciones móviles en salud, y el Sr. Miquel Angel Mayer, actual director del Departamento de Web Médica Acreditada (WMA) del Colegio Oficial de Médicos de Barcelona (COMB) que presentó cual es la práctica médica actual sobre las apps y también expuso los peligros que estas apps pueden provocar, y como hace falta certificarlas y validarlas para garantizar la seguridad de todos los ciudadanos que las utilicen.

Marcaje CE en Productos Sanitarios

Actualmente los productos sanitarios al igual que sucede con los medicamentos están sujetos a las reglamentaciones de cada país y no son de libre comercialización. Está regulado su diseño, su fabricación, comercialización, distribución y venta, así como, la publicidad y las acciones en el mercado después de su comercialización.

La normativa actual de referencia para nuestro país es el Real Decreto 1591/2009 que habla sobre los productos sanitarios en general, el Real Decreto 1616/2009 que trata sobre los implantes activos, y el Real Decreto 1662/2000 que está enfocado al diagnóstico in vitro.

Medical Mobile Apps

Entendemos entonces, que un producto sanitario no sólo son los dispositivos médicos, sino también pueden serlo las múltiples aplicaciones móviles en salud que actualmente se pueden encontrar en el mercado. Por lo tanto, es importante tener en cuenta y diferenciar qué es un producto sanitario del que no lo es. Por ejemplo, una aplicación que nos indique nuestro nivel de glucosa, o nos muestre el resultado de una radiografía es un producto sanitario, en cambio, una aplicación que nos indique nuestras pulsaciones cuando vamos a correr no estaría considerado dentro de la legislación vigente como un producto sanitario.

Por lo tanto, todo este mercado de aplicaciones que el usuario puede obtener a través de Internet y a través de sus dispositivos móviles pude ser un peligro si no se mantiene una regulación para garantizar la seguridad, privacidad de la información introducida en la aplicación y garantizar también el correcto uso funcional y asistencial que dichas aplicaciones pueden ofrecer. Un mal uso de las apps en salud puede dar lugar a resultados no deseados, como por ejemplo, causar diagnósticos erróneos que pueden provocar un efecto nocivo en la salud del ciudadano.

Por éste motivo, se debe obtener un marco regulatorio que identifique y certifique aquellas apps aceptables de aquellas que no lo son. Actualmente, se está trabajando para que próximamente surjan regulaciones a tal efecto, ya que actualmente no hay ninguna que garantice el buen uso de las apps en el entorno sanitario.

Llegir en català
Leer en castellano

On 28th of November, the Integrated and Competency Centre (ICC) participated in the training day of CE marking in health technology and special medical mobile apps. The attendees, the vast majority manufactures of medical devices and physicians, considered really useful the whole current information presented.

The training day was divided into two parts, during the morning it was treated which new rules are on CE marking in medical products and which is the process that every manufacture of medical devices has to perform to achieve the CE labelling in their products. Secondly, during the afternoon, it spent part of the day to talk about the current increase and impact of medical applications in healthcare sector, an important aspect that it should take into account when evaluating and certificating the security in whole applications that could be found at the moment in many mobile.
The conference was attended by two experts of eHealht, Mr. Carlos Gallego, director of Interoperability and Standards Office of Fundació TicSalut who presented a first step of how it could approve the medical application, and Mr. Miquel Angel Mayer, currently director of Departamento de Web Médica Acreditada (WMA) of Colegio Oficial de Médicos de Barcelona (COMB) who presented which is the medical practice about apps and he also exposed the apps dangers, and how it’s necessary to analyze and certificate it to guarantee the security of every citizen that use them.

CE labelling for medical devices

Currently every medical product the same as succeed with meds have to fulfil regulations of each country and they aren’t free marketing. It is regulated their design, manufacture, marketing, distribution and sale, as well as, advertising and the actions in the market after marketing them.

The current reference standards for our country is the Real Decreto 1591/2009 that talks about medical devices in general, Real Decreto 1616/2009 which deals with active implants, and the Real Decreto 1662/2000 that it is focussed on the diagnosis in vitro.

Medical Mobile Apps

Then we understand that a medical product not only are medical devices, but they could be multiple mobile health applications that at the moment we can find in healthcare market. Thus, it’s important to consider and differentiate what is a medical product and which it is not. For instance, an application that tells us our level of glucose, or show us the result of an X-ray is a medical device, however, application that tells us when we go to our presses run would not be considered within the current law as a medical device.

Therefore, the whole market applications that the user can get on Internet and through their mobile devices could be a hazard if regulation is not maintained to ensure the safety and privacy of information entered in the application and also guarantee the correct functional and welfare use these applications can offer. Misuse of medical apps can lead to erroneous results, such as misdiagnosis that can cause a harmful effect on the health of citizens.

For this reason, we must obtain a regulatory framework that identifies and certifies those acceptable apps from those that are not. Currently, it is working on regulations that will soon take effect, since there is currently no guarantee that the proper use of the apps in the healthcare environment.

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

El valor de la interoperabilitat

Leer en castellano
Read It in English

Fa dies que vull escriure al bloc, i finalment avui se m’ha presentat la excusa perfecta: he llegit un article sobre interoperabilitat estratègica, al següent enllaç i el volia comentar. Aquests mesos que porto involucrat amb el meu equip del CCI en la definició, desenvolupament i lliurament de solucions d’integració i interoperabilitat en diferents entorns (públic-privat i diferents sistemes de salut) he reflexionat en diferents aspectes, i aquest article gira entorn a la mateixa realitat: quin és el valor real dels entorn d’interoperabilitat? Des de un punt de vista de sistemes, la interoperabilitat ha de ser la base per poder connectar sistemes i dispositius diversos i poder compartir informació: els professionals i els usuaris podrem, cadascú des del nostre àmbit, tenir accés a una mateixa font d’informació on trobarem tota la informació relacionada d’un pacient (no la duplicarem –unicitat- i sempre la podrem consultar –disponibilitat- des de una diversitat de punts –ubiqüitat de la informació-, i això permetrà redefinir els fluixes dels processos de salut). Magnífic! Però com bé es diu en l’article d’en Nelson, la clau està en la vinculació d’aquestes característiques pròpies de la interoperabilitat de sistemes amb els criteris rellevants d’un servei, … en el nostre cas, el servei de salut: Qualitat amb eficiència! Com hi arribem? Amb criteris de qualitat i no amb criteris de quantitat. Tenint la informació adequada, no només la informació… habilitant la continuïtat assistencial d’una forma real (al final tots estem al servei de la persona, una persona, un sistema, un servei…. i així ha de poder ser apercebut per tots). Estem en un entorn de població que envelleix acceleradament i que comporta un increment important (en Nelson parla del 75% de casos) de la població amb situacions d’atenció en cronicitat. Hem de ser eficients en el seu tractament per la qualitat de vida de les persones i per la sostenibilitat del sistema: la reducció de situacions de reingrés n’és la clau, i és aquí on la interoperabilitat ens permetrà guanyar la partida: disponibilitat de la informació rellevant per el professional adequat en un model de sostenibilitat i eficàcia. Catalunya està fent la feina, en aquest sentit. Per assolir els nostres objectius, la participació de tots és fonamental: les persones, la tecnologia, la assistència sanitària, la gestió de processos, les gerències i les diverses direccions, i les administracions dels sistemes de salut.

Llegir en català
Read It in English
Hace días que quiero escribir en el blog , y finalmente hoy se me ha presentado la excusa perfecta : he leído un artículo sobre interoperabilidad estratégica , en el siguiente enlace y lo quería comentar . Estos meses que llevo involucrado con mi equipo del CCI en la definición , desarrollo y entrega de soluciones de integración e interoperabilidad en diferentes entornos ( público -privado y diferentes sistemas de salud ) he reflexionado sobre diferentes aspectos , y este artículo gira en torno a la misma realidad : ¿cuál es el valor real de los entornos de interoperabilidad ? Desde un punto de vista de sistemas, la interoperabilidad debe ser la base para poder conectar sistemas y dispositivos diversos y poder compartir información : los profesionales y los usuarios podremos , cada uno desde nuestro ámbito, tener acceso a una misma fuente de información donde encontraremos toda la información relacionada de un paciente ( no la duplicaremos -unicidad – y siempre la podremos consultar -disponibilidad- desde una diversidad de puntos – ubicuidad de la información- , lo que permitirá redefinir los flujos de los procesos de salud) . Magnífico ! Pero como bien se dice en el artículo de Nelson , la clave está en la vinculación de estas características propias de la interoperabilidad de sistemas con los criterios relevantes de un servicio , … en nuestro caso , el servicio de salud : Calidad con eficiencia ! Cómo logramos nuestra meta? Con criterios de calidad y no con criterios de cantidad. Teniendo la información adecuada , no sólo la información … habilitando la continuidad asistencial de una forma real (al final todos estamos al servicio de la persona , una persona , un sistema , un servicio …. y así debe poder ser percibido por todos) . Estamos en un entorno de población que envejece aceleradamente y que conlleva un incremento importante (Nelson habla del 75% de casos) de la población con situaciones de atención en cronicidad . Debemos ser eficientes en su tratamiento por la calidad de vida de las personas y por la sostenibilidad del sistema : la reducción de situaciones de reingreso es la clave , y es aquí donde la interoperabilidad nos permitirá ganar la partida: disponibilidad de la información relevante para el profesional adecuado en un modelo de sostenibilidad y eficacia. Cataluña está haciendo el trabajo, en esta dirección. Para lograr nuestros objetivos, la participación de todos es fundamental : las personas , la tecnología, la asistencia sanitaria , la gestión de procesos , las gerencias y las diversas direcciones , y las administraciones de los sistemas de salud .
Llegir en català
Leer en castellano
So many days trying to find the point for writing on the blog…. and, at last, today I found the perfect excuse: I read an article on strategic interoperability, at the following link and I would like to comment on the article. Those last months that I’ve been involved with my team at the CCI on the definition , development and delivery of real interoperable solutions in different environments (public – private, a variability of National health systems ) I ‘ve been reflecting in different ways, and this article focuses most on the same points: which is the real value of interoperability? From a System based perspective , interoperability should be the basis for various devices and systems to be connected and to be able to share information: professionals and users, each one from our perspective , can have access to the same source of information where all the information related to a patient will be in place (the information will not be duplicated –uniqueness- , and it would always be ready – availability-, from a wide subset of places- ubiquity of information- , conducting us to a redefinition of the healthcare system processes) . Great! But as it is written in the article by Nelson , the key is the linking of these characteristics of interoperability on systems with the relevant criteria for a service … In our case , the healthcare service : Quality but efficiently! How do we get there? With quality based criteria and not criteria based on quantity. It is a matter of having the right information , not just information … enabling a true care continuum ( at the end we are all at the service of the person , one person, one healthcare system , a unique service …. and so should be perceived by everyone) . We are in an environment of rapidly aging population that entails a significant increase ( Nelson says 75% of cases) of the population in chronic care situations . We have to be efficient in its treatment for a better quality of life of people and the sustainability of the system : reducing readmission situations is the key, and here is where interoperability and integration will allow us to win the game: full availability of the relevant information to the appropriate professional in a sustainable and efficient model. Catalonia is doing work in this regard . To achieve our goals, it is essential everyone participation’s : people , technology, health care, process management , management units, and healthcare systems administration.

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)

FHIR, la nova especificació HL7 (Part IV)

Leer en castellano 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fins aqui la última entrega del post sobre FHIR.

Llegir en català 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hasta aqui la última entrega del post sobre FHIR.

FHIR, la nova especificació HL7 (Part III)

Leer en castellano

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

Formats dels recursos

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

Representació XML

La sintaxis XML presenta la següent anotació:

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

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

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

Representació UML

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

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

Tipus de dades dels recursos

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

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

Tipus Primitius:

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

Exemple:

data (per exemple, data de naixement):

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

En JSON:

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

O bé:

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

Tipus Complexos:

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

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

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

Llegir en català

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

Formatos de los recursos

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

Representación XML

La sintaxis XML presenta la siguiente anotación:

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

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

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

Representación UML

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

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

Tipos de datos de los recursos

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

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

Tipos Primitivos:

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

Ejemplo:

fecha (por ejemplo, fecha de nacimiento):

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

En JSON:

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

O bien:

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

Tipos Complejos:

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

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

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

FHIR, la nova especificació HL7 (Part II)

Leer en castellano

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

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

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

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

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

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

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

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

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

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

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

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

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

Un exemple d’un recurs contingut:

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

El mateix exemple escrit amb JSON:

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

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

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

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

Llegir en català

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

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

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

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

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

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

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

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

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

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

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

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

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

Un ejemplo de un recurso contenido:

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

El mismo ejemplo escrito con JSON:

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

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

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

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

FHIR, la nova especificació HL7 (Part I)

Leer en castellano

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

Perquè es fa necessari?

FHIR es fa necessari perquè:

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

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

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

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

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

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

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

Un recurs és una entitat que:

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

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

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

Tots els recursos estan formats pels següents elements:

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

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

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

Llegir en català

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

¿Por qué se hace necesario?

FHIR se hace necesario porque:

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

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

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

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

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

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

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

Un recurso es una entitad que:

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

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

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

Todos los recursos estan formados por los siguientes elementos:

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

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

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