Arxius de l'autor: Manel Domingo

Manel Domingo

Sobre Manel Domingo

Enginyer Tècnic en Informàtica de Gestió, certificat en HL7 v2.6 i especialitzat en entorns d’integració orientats a la salut. Responsable tècnic de la línia de treball Entorns d’Interoperabilitat, on es duen a terme projectes d’integració per facilitar la interoperabilitat entre sistemes, utilitzant estàndards.

Pàgina web:

Jornada d’Interoperabilitat IHE – ForumCis

Llegir en català

El pasado 18 de abril, el CCI-TCM participó en la Jornada de Interoperabilidad de IHE, englobada dentro de los diferentes eventos organizados por el ForumCis.

La jornada cubrió diferentes aspectos englobados siempre dentro del marco de interoperabilidad de IHE, como por ejemplo los perfiles de integración existentes en el mismo. En nuestro bloc ya hicimos una introducción por lo que se refiere a este ámbito

Las temáticas tratadas durante la jornada se englobaron en:

–  ¿Qué es IHE?: Donde se explicó cual es el objetivo de la utilización de un marco de interoperabilidad como IHE.

–  ¿Qué problemas resuelve IHE?: Que especificó para que problemas de interoperabilidad e integración esta diseñado y preparado IHE.

–   ¿Cómo utilizar IHE? Interoperabilidad en:

    • Radiología: Experiencia en la digitalización de la imagen medica con IHE, tanto a nivel de PACS como de otras transacciones contempladas en el marco de interoperabilidad.
    • Laboratorio: Explicación de los casos de uso y transacciones que cubre IHE orientados a laboratorio.
    • Dispositivos de monitorización de pacientes: Especificación de cómo llevar a cabo integraciones de dispositivos médicos con sistemas de información, a través del dominio “Patient Care Device” del marco de interoperabilidad.

–  Interoperabilidad transfronteriza : Donde se entró a explicar de forma funcional el proyecto Epsos

–  ¿Cómo moverse por IHE y que recursos nos puede proporcionar?: Explicación de todos aquellos artefactos que nos proporciona IHE para realizar integraciones y como utilizarlos.

Para obtener información sobre el programa realizado haz clic aquí

Entrando mas en detalle de la ponencia realizada por el CCI-TCM, orientada a explicar la utilidad del dominio “Patient Care Device” de IHE para la integración de dispositivos médicos, se inició especificando la problemática principal de la integración de los dispositivos médicos en un sistema de información, explicando los diferentes tipos de dispositivos médicos existentes, así cono formatos de información clínica que proporcionan, además, se hizo especial hincapié en las malas practicas de integración que se llevan a cabo en la actualidad.

Seguidamente, se especificaron los conceptos clave de una integración, como son los estándares y la interoperabilidad, para a partir de aquí, explicar en que escenarios se debe de utilizar el dominio “Patient Care Device”,  contra que sistemas se puede integrar y que información gestiona.

A continuación y profundizando en la utilización del dominio “Pantient Care Device”, se trataron los perfiles, así  como sus correspondientes actores y transacciones, que proporciona dicho dominio para llevar a cabo las integraciones entre los dispositivos de monitorización de pacientes y los sistemas de información, como por ejemplo:

–   Perfil “Device Enterprise Communication”. Orientado a facilitar la interoperabilidad entre un dispositivo medico y un sistema de información, a través de mensajería HL7 y con la ayuda de un actor con el rol de “Middleware” o normalizador de la información.

    • Actores:
      • Device Observation Consumer (DOC). Responsable de consumir la información que le proviene del  DOR (dispositivo medico/”middleware”)
      • Device Observation Reporter (DOR). El dispositivo medico, encargado de transmitir la información clínica de la prueba al actor DOC (“middlware”/sistema de información de destino).
    • Transacciones:
      • Comunication Device Data. Mensaje normalizado en HL7 (ORU), que nace del actor DOR para ser consumido por el actor DOC.

Los demás perfiles que se trataron fueron, el “Patient Infusión Verification”, orientado a la  integración de las bombas de infusión a pie de cama, el “Implantable Device Cardiac Observation”, perfil que permite que los dispositivos cardiacos puedan hacer llegar la información clínica de las pruebas  a los sistemas de información, y por ultimo el “Rossetta Terminology Mapping”, perfil con la finalidad de normalizar la información clínica que proporcionan los dispositivos médicos, con tal de conseguir una interoperabilidad semántica entre los mismos y los sistemas de información.

Antes de finalizar la comunicación, se explicó la utilidad de un entorno de integración como herramienta para facilitar la interoperabilidad (utilizando los perfiles de IHE), entre los dispositivos médicos con los sistemas de información. Por ultimo, se informo de la existencia de una página web de IHE donde poder consultar aquellos dispositivos médicos, que cumplen con los perfiles del dominio “Pantient Care Device”.

A continuación se pueden visualizar tanto la presentación expuesta durante la jornada, como la grabación de la ponencia relacionada con el post actual.



YouTube Preview Image
Leer en castellano

El passat 18 d’abril, el CCI-TCM va participar a la Jornada d’Interoperabilitat de IHE, englobada dins dels diferents esdeveniments organitzats pel ForumCis.

La jornada va cobrir diferents aspectes englobats sempre dintre del marc d’interoperabilitat de IHE, com per exemple perfils d’integració existents en el mateix. En el nostre bloc ja vam fer una introducció pel que es refereix a aquest àmbit

Les temàtiques tractades durant la jornada en van englobar en:

–  Que es IHE?: On es va explicar quin era el objectiu de la utilització d’un marc d’interoperabilitat com IHE.

–  Que problemes resol IHE?: Que especifica per a que problemes d’interoperabilitat i integració esta dissenyat i preparat IHE.

–  Com utilitzar IHE?: Interoperabilitat en:

    • Radiologia: Experiència en la digitalització de la imatge medica amb IHE, tant a nivell de PACS com d’altres transaccions contemplades en el marc d’interoperabilitat.
    • Laboratori: Explicació dels casos d’us i transaccions que cobreix IHE orientats a laboratori.
    • Dispositius de monitorització de pacients: Especificació de com duu a terme integracions de dispositius mèdics amb sistemes d’informació, a traves del domini “Patient Care Device” del marc d’interoperabilitat.

–  Interoperabilitat transfronterera: On s’entra a explicar de forma funcional el projecte Epsos.

–  Com moures per IHE i que recursos ens pot proporcionar?: Explicació de tots aquells artefactes que ens proporciona IHE per a realitzar integracions i com utilitzar-los.

Per obtenir informació sobre el programa realitzat fes clic aquí

Entrant més en detall de la ponència realitzada pel CCI-TCM, orientada a explicar la utilitat del domini  “Patient Care Device” de IHE per a la integració de dispositius mèdics, es va començar especificant la problemàtica principal de l’integració dels dispositius mèdics en un sistema de d’informació, explicant els diferents tipus de dispositius mèdics existents, així com els formats d’informació clínica que proporcionen, a més, es va realitzar especial incís en les males practiques d’integració que duen a terme a la actualitat.

Seguidament, es van especificar els conceptes clau d’una integració, com son els estàndards i la interoperabilitat, per a partir d’aquí, explicar en quins escenaris s’ha d’utilitzar el domini “Patient Care Device”, contra quins sistemes en pot integrar i que informació gestiona.

A continuació i profunditzant en la utilització del domini “Patient Care Device”, es van tractar els perfils, així com els seus corresponents actors i transaccions, que proporciona l’esmentat domini per dur a terme les integracions entre els dispositius de monitorització de pacients i els sistemes d’informació, com per exemple:

–  Perfil “Device Enterprise Communication”. Orientat a facilitar la interoperabilitat entre un dispositiu mèdic i un sistema d’informació, a traves de missatgeria HL7 i amb l’ajuda d’un actor amb el rol de “Middleware” o normalitzador de la informació.

    • Actors:
      • Device Observation Consumer (DOC). Responsable de consumir la informació que li proveeix del  DOR (dispositiu mèdic/”middleware”)
      • Device Observation Reporter (DOR). El dispositiu mèdic, encarregat de transmetre la informació clínica de la prova al actor DOC(“middlware”/sistema d’informació de desti.
    • Transacciones:
      • Comunication Device Data. Missatge normalitzat en HL7 (ORU), que neix de l’actor DOR per ser consumit per l’actor DOC.

Els demes perfils que es van tractar van ser, el “Patient Infusión Verification”, orientat a la integració de les bombes d’infusió a peu de llit, el “Implantable Device Cardiac Observation”, perfil que permet que els dispositius cardíacs puguin fer arribar la informació clínica de les proves als sistemes d’informació, i per últim el “Rossetta Terminology Mapping”, perfil amb la finalitat de normalitzar la informació clínica que proporcionen els dispositius mèdics, amb l’objectiu d’aconseguir una interoperabilitat semàntica entre els mateixos i els sistemes d’informació.

Abans de finalitzar la comunicació, es va explicar la utilitat d’un entorn d’integració com eina per facilitar la interoperabilitat (utilitzant els perfils de IHE), entre els dispositius mèdics amb els sistemes d’informació. Per últim, es va informar de la existència d’una pagina web de IHE on poder consultar aquells dispositius mèdics, que compleixen amb els perfils del domini “Patient Care Device”.

A continuació es pot visualitzar tant la presentació exposada durant la jornada, com la gravació de la ponència relacionada amb el post actual.



YouTube Preview Image

Continua Alliance: Ecosistema de Interoperabilitat per sistemes i dispositius medics (I)

Leer en castellano

Aquest post és l’inici d’una sèrie on parlarem sobre Contínua Alliance, un marc de treball per facilitar la interoperabilitat entre dispositius i sistemes d’informació mèdics, per tal de propiciar entre altres aspectes, un augment en la qualitat assistencial cap als pacients, a través de la integració de la informació clínica amb els diferents agents que participen en l’àmbit sanitari.

Missió de Continua Alliance

Establir un ecosistema d’interoperabilitat per als sistemes de salut personals,permetent a les persones i organitzacions gestionar millor la seva

salut i benestar. Aquesta missió es basa en la interoperabilitat entre els components, sistemes i subsistemes incorporats dins dels sistemes de salut. Es pretén realitzar una selecció de normes i especificacions (necessàries per complir amb aquesta missió), tot definint les pautes de disseny, aclarint d’aquesta manera encara més les normes i especificacions, per tal de que aquestes garanteixin una perfecta interoperabilitat

Objectiu / Àmbit de l’aplicació de Continua Alliance

Aquest post conté referències als estàndards i especificacions que Continua selecciona per garantir la interoperabilitat entre dispositius. També conté directrius addicionals de disseny per a la interoperabilitat, aclarint encara més aquests estàndards i especificacions, mitjançant la reducció d’opcions en la norma o especificació de base o també, mitjançant l’addició d’una característica que falta en la norma o especificació subjacent.

Les directrius que Continua mostra es centren en les interfícies següents:

  • PAN-IF – Connexió a dispositius de xarxa en l’àrea personal de salut
  • LAN-IF – Interfície entre dispositius de xarxa d’àrea local i dispositius d’allotjament d’aplicacions
  • WAN-IF – Interfície entre dispositius d’allotjament d’aplicacions i sistemes “back-end”, com ara serveis de monitorització remot o proveïdors de serveis de gestió de malalties
  • HRN-IF – Interfície entre dispositius WAN i altres dispositius WAN o dispositius de la Història Clínica Electrònica (EHR)

Figura 1. Classes de dispositius de referencia

Visió general de Continua Alliance

Arquitectura E2E (End-to-End)

A continuació definirem l’arquitectura d’extrem a extrem (E2E) de Continua Alliance. L’arquitectura Continua  Alliance s’utilitza per a diversos propòsits:

  • Definició de conceptes comuns
  • Definició de restriccions de topologia per a l’arquitectura Continua
  • Servir com a base per al marc de les directrius, proporcionant una estructura bàsica que estableix normes per al refinament i l’extensió d’aquesta estructura, facilitant l’associació de guies amb els elements d’aquesta estructura

Classificació de dispositius i topologia del sistema Continua Alliance

Els dispositius són entitats físiques que poden contenir un o més nombre de components. L’arquitectura E2E (d’extrem a extrem) de Continua, distingeix diferents classes de dispositius basant-se en les classes de components allotjats al dispositiu.

Les classes de dispositius, s’utilitzen per definir les restriccions de topologia per a l’arquitectura Continua i formen la base d’un marc de directrius. Les restriccions de topologia es defineixen per a l’ arquitectura Continua però algunes de les mateixes no son viables.

L’actual arquitectura E2E de Continua distingeix les següents classes de dispositius de referència:

  • Dispositiu PAN: Dispositiu que desplega com a mínim un component de servei PAN-IF. Els components de servei  PAN-IF són els components de serveis amb sensors, d’emmagatzematge, etc.
  • Dispositiu de LAN: Dispositiu que desplega com a mínim un component de servei LAN. A més, aquests components del servei poden ser instàncies de les subclasses dels components del servei LAN-IF.
  • Dispositiu d’emmagatzematge d’aplicacions: Dispositiu que desplega com a mínim un component client PAN-IF, un component de client LAN-IF, o un component  WAN-IF.
  • Dispositiu WAN: Dispositiu que desplega com a mínim un component de servei WAN-IF o un component client HRN-IF.
  • Dispositiu HRN: Dispositiu que desplega un o més components de servei HRN-IF.

Figura 2. Definicions i notació gràfica



Extret del document “Continua Design Guidelines 2010”, Autors: David Rodríguez i Manel Domingo

Llegir en català

Este post es el inicio de una serie donde hablaremos sobre Continua Alliance, un marco de trabajo para facilitar la interoperabilidad entre dispositivos y sistemas de información médicos, a fin de propiciar entre otros aspectos, un aumento en la calidad asistencial hacia los pacientes , a través de la integración de la información clínica con los diferentes agentes que participan en el ámbito sanitario.

Misión de Continua Alliance

Establecer un ecosistema de interoperabilidad para los sistemas de salud personales, permitiendo a las personas y organizaciones gestionar mejor su

salud y bienestar. Esta misión se basa en la interoperabilidad entre los componentes, sistemas y subsistemas incorporados dentro de los sistemas de salud. Se pretende realizar una selección de normas y especificaciones (necesarias para cumplir con esta misión), definiendo las pautas de diseño, aclarando de este modo aún más las normas y especificaciones, para que estas garanticen una perfecta interoperabilidad

Objetivo / Ámbito de la aplicación de Continúa Alliance

Este post contiene referencias a los estándares y especificaciones que Continúa selecciona para garantizar la interoperabilidad entre dispositivos. También contiene directrices adicionales de diseño para la interoperabilidad, aclarando aún más estos estándares y especificaciones, mediante la reducción de opciones en la norma o especificación de base o también, mediante la adición de una característica que falta en la norma o especificación subyacente.

Las directrices que Continúa muestra se centran en las interfaces siguientes:

  • PAN-IF – Conexión a dispositivos de red en el área personal de salud
  • LAN-IF – Interfaz entre dispositivos de red de área local y dispositivos de alojamiento de aplicaciones
  • WAN-IF – Interfaz entre dispositivos de alojamiento de aplicaciones y sistemas “back-end”, como servicios de monitoreo remoto o proveedores de servicios de gestión de enfermedades
  • HRN-IF – Interfaz entre dispositivos WAN y otros dispositivos WAN o dispositivos de la Historia Clínica Electrónica (EHR)

Figura 1. Clases de dispositivos de referencia

Visión general de Continua Alliance

Arquitectura E2E (End-to-End)

A continuación definiremos la arquitectura de extremo a extremo (E2E) de Continúa Alliance. La arquitectura Continúa Alliance utiliza para varios propósitos:

  • Definición de conceptos comunes
  • Definición de restricciones de topología para la arquitectura Continúa
  • Servir como base para el marco de las directrices, proporcionando una estructura básica que establece normas para el refinamiento y la extensión de esta estructura, facilitando la asociación de guías con los elementos de esta estructura

Clasificación de dispositivos y topología del sistema Continúa Alliance
Los dispositivos son entidades físicas que pueden contener uno o más número de componentes. La arquitectura E2E (de extremo a extremo) de Continua, distingue diferentes clases de dispositivos basándose en las clases de componentes alojados en el dispositivo.

Las clases de dispositivos, se utilizan para definir las restricciones de topología para la arquitectura Continua y forman la base de un marco de directrices. Las restricciones de topología se definen para la arquitectura Continúa pero algunas de las mismas no son viables.

La actual arquitectura E2E de Continúa distingue las siguientes clases de dispositivos de referencia:

  • DispositivoPAN: Dispositivo que desarrolla como mínimo un componente de servicio PAN-IF. Los componentes de servicio PAN-IFson los componentes de servicios con sensores, de almacenamiento, etc.
  • Dispositivo de LAN: Dispositivo que desarrolla como mínimo un componente de servicio LAN. Además, estos componentes del servicio pueden ser instancias de las subclases de los componentes del servicio LAN-IF.
  • Dispositivo de almacenaje de aplicaciones: Dispositivo que despliega como mínimo un componente cliente PAN-IF, un componente de cliente LAN-IF, o un componente  WAN-IF.
  • DispositivoWAN: Dispositivo que despliega com a mínimo un componente de servicio WAN-IF o un componente cliente HRN-IF.
  • DispositivoHRN: Dispositivo que despliega uno o mas componentes de servicio HRN-IF.

Figura 2. Definicions i notació gràfica

Extraido del documento “Continua Design Guidelines 2010”, Autores: David Rodríguez i Manel Domingo

Interoperabilitat de la prova d’espirometria forçada

En aquesta entrada explicarem un dels treballs que hem realitzat al CCI en quan a l’àmbit d’integració i interoperabilitat amb estàndards, la integració de la prova d’espirometria forçada.

Per tal d’implantar l’estàndard CDA R2 homologat per la Oficina d’Estàndards i Interoperabilitat de la Fundació TicSalut del Departament de Salut de la Generalitat de Catalunya, des del Pla Director de Malalties de l’Aparell Respiratori (PDMAR) encapçalat pel Dr. Joan Escarrabill, s’ha decidit realitzar projectes pilot per a donar una empenta a la integració i interoperabilitat de la prova d’espirometria forçada, tot utilitzant l’estàndard HL7-CDA R2.

A través de la nostra expertesa en estàndards i en integració de sistemes i dispositius mèdics, hem proporcionat suport tècnic a nivell de consultoria al Institut Català de la Salut, per facilitar la implantació de l’estàndard en aquells centres participants en els projectes pilot.

Des del CCI (a traves del treball realitzat), s’han gestionat i normalitzat els resultats d’una prova d’espirometria forçada, i s’ha desenvolupat una integració d’aquesta prova, creant una producció sota la plataforma d’integració, Ensemble d’Intersystems.La producció reuneix tots els fluxos necessaris per poder dur a terme l’integració de la prova, des de la gestió de la demanda (enviada pel centre peticionari), la gestió dels resultats de l’espiròmetre, i la generació final d’un informe detallat amb: l’informació personal del pacient, els resultats clínics de la prova i una interpretació gràfica dels mateixos.

El procés intern que es duu a terme en la producció desenvolupada es divideix en les següents etapes:

Etapa 1 – Gestió demanda:

La demanda d’espirometria, es duu a terme ha partir d’una petició d’un metge desde el servei de pneumologia d’un centre hospitalari, cap a la llista de treball (cua de pacients que s’han de dur a terme proves clíniques en el centre), del sistema d’informació centralitzat del centre. Rebuda la demanda d’espirometria en la llista de treball, és processada pel sistema d’informació centralitzat del centre i emmagatzemada en una base de dades, a l’espera dels resultats de la prova d’aquest pacient.

La producció desenvolupada és adaptable, a rebre la missatgeria de la demanda(prominent del sistema d’Informació centralitzat del centre), en format “propietari” però es aconsellable per manegar aquesta informació utilitzar l’estàndard de missatgeria medica HL7.

Etapa 2 – Gestió prova:

Un cop emmagatzemada la demanda a la base de dades de la producció, el pacient arriba al centre transcorregut un cert temps i es realitza la prova. El dispositiu mèdic en qüestió (espiròmetre), genera una sèrie de dades clíniques relacionades amb la respiració del pacient (FVC, FEF, etc. ), aquestes dades quedaran emmagatzemades físicament en un fitxer.

Aquest fitxer com el missatge de demanda, sol ser format propietari, tot i que desde diferents organismes i proveïdors de dispositius mèdics, s’està treballant per aconseguir que aquestes ambos informacions es rebin i es generin al dispositiu mèdic en format estàndard HL7.

El següent pas d’aquesta etapa del procés, es llegir els resultats clínics generats durant la prova d’espirometria i intentar lligar la mateixa amb la demanda corresponent. El procés de “lligar” es fa a través del codi identificador de la prova, així com el nom i l’edat del pacient (com a dades addicionals per reafirmar aquest identificador). Si es troba una demanda relacionada amb la prova, la producció generarà l’informe corresponent a la prova realitzada, incloent un documento clínic CDA R2 (representant l’informe d’espirometria com a estàndard de text amb entrades codificades), un XSL (per poder visualitzar el CDA R2 en un navegador) i les gràfiques corresponents a les dades clíniques de la prova, com a informació de suport per el metge.

En cas contrari el sistema emmagatzemarà la prova d’espirometria. Aquests resultats quedaran emmagatzemats sense processar, degut a que l’etapa de lligar la demanda no ha finalitzat amb èxit. Les proves no “lligades”, són comprovades cada un determinat període de temps en el cas de que la demanda no hagués arribat correctament.Si en una comprovació s’aconsegueix lligar la prova, es processa normalment seguint el procés anteriorment explicat.

Per evitar que una prova quedi en el sistema de manera permanent, quan ja s’han dut a terme diversos intents, i no s’ha aconseguit lligar amb la demanda, aquest fitxer és emmagatzemat de forma separada dels altres, per a que sigui comprovat manualment per la persona responsable que a realitzat la prova al pacient.

Quan el procés finalitza satisfactòriament es generarà, com ja s’ha esmentat anteriorment,tres fitxers:

CDA R2: Arquitectura estàndard per a documents clínics basada en el model UML R-MIM. Aquest document contindrà la informació del pacient i les dades clíniques de la prova d’espirometria, de manera estructurada (XML) i codificada a traves de la terminologia clínica SNOMED-CT.

XSL: Permet visualitzar el CDA R2 en un navegador com si es tractés d’una plana web qualsevol.

Gràfics: Conjunt de dos gràfics (Flux-Volum i Volum-Temps), que representen els resultats clínics de la prova. Aquests gràfics apareixen incrustats al final del CDA R2.

A continuació podreu visualitzar la producció d’espirometria que hem desenvolupat, sota l’entorn d’integració Ensemble d’Intersystems.

YouTube Preview Image