Transmisión de ECGs en tiempo real basada en estándares: Armonización de ISO/IEEE 11073-PHD y SCP-ECG.

Transmisión de ECGs en tiempo real basada en estándares: Armonización de ISO/IEEE 11073-PHD y SCP-ECG. J. D. Trigo Vilaseca 1, F. Chiarugi 2, Á. Alesanco Iglesias 1, M. Martínez-Espronceda Cámara 3, L. Serrano Arriezu 3, C. E. Chronaki 2, J. Escayola Calvo 1, I. Martínez Ruiz 1 y J. García Moros 1 1 Univ. Zaragoza/Instituto de Investigación en Ing. Aragón (I3A), c/ María de Luna, 3. 50018 Zaragoza 2 Institute of Computer Science (ICS), Foundation for Research and Technology Hellas (FORTH), Heraklion, Crete, Greece 3 Dep. Ingeniería Eléctrica y Electrónica (Univ. Pública Navarra) - Campus de Arrosadía s/n. 31006 - Pamplona {jtrigo, alesanco, jescayola, imr, jogarmo}@unizar.es, {miguel.martinezdeespronceda, lserrano}@unavarra.es, {chiarugi, chronaki}@ics.forth.gr Resumen Hoy en día, en el diseño de los nuevos sistemas de información aplicados a la salud resultan aspectos clave los paradigmas de interoperabilidad y estandarización. Para los dispositivos médicos, esto puede conseguirse mediante los estándares internacionales de interoperabilidad. En ese campo, la familia de estándares ISO/IEEE 11073 (x73) es un estándar de referencia. Para su versión Personal Health Devices (x73-phd) ya han sido definidos diversos dispositivos, sin embargo, un perfil para el ECG no se encuentra todavía disponible. Por otro lado, el estándar de electrocardiografía SCP-ECG ha sido aprobado como parte del estándar x73-phd. En este artículo se investigan la relación entre un modelo x73-phd propuesto para un electrocardiógrafo y los campos de SCP-ECG. También se presenta una implementación proof-of-concept del modelo propuesto y se identifican puntos abiertos de los estándares. 1. Introducción En el contexto de servicios de esalud integrales, la interoperabilidad posibilita una comunicación versátil, integrada, eficiente y útil [1,2]. En los últimos años han surgido diversas iniciativas para que los dispositivos médicos (Medical Devices, MDs) puedan establecer una comunicación con un servidor de Historia Clínica Electrónica (HCE), con el objetivo de promover la creación de servicios de esalud extremo a extremo basados en estándares. Entre estos esfuerzos, dos de los más destacados son: la familia de estándares ISO/IEEE 11073 (generalmente referenciada como x73), que define la comunicación entre MDs y sistemas externos (llamados Compute Engines, CEs), y EN13606 que posibilita el intercambio interoperable de HCEs. En un ámbito más cercano a la empresa y a los fabricantes, han surgido otras iniciativas como Continua Health Alliance [3] o Integrating the Healthcare Enterprise [4]. En el caso particular de las señales de electrocardiografía (ECG), se han propuesto y estandarizado una amplia variedad de protocolos, como SCP-ECG (estándar europeo EN1064), HL7 aecg (estándar americano, ANSI), MFER (estándar japonés) o el DICOM Waveform Sup 30. El estándar SCP-ECG [5] se ha mostrado como el estándar de referencia en este contexto. Éste estándar fue impulsado por el proyecto europeo OpenECG [6], que tiene la tarea de promover, de una manera coordinada, interdisciplinada, el intercambio y almacenamiento de ECGs short-term. Por otro lado, la familia de estándares x73, inicialmente guiada por el IEEE y posteriormente adoptada por CEN e ISO, emerge de la necesidad de proponer soluciones técnicas robustas, abiertas e interoperables en el ámbito de sistemas y dispositivos para la telemonitorización de pacientes en escenarios domiciliarios o móviles. El estándar ha evolucionado desde el punto de cuidado (Point-of-Care, x73-poc) [7] hacia los nuevos Personal Health Devices (x73-phd) [8]. A día de hoy, solo un reducido grupo de dispositivos médicos ha sido definido para x73-phd (pulsioxímetro, tensiómetro, termómetro o báscula). A pesar de que sí que se definió un perfil para dispositivos ECG en x73-poc [9], la versión para x73- PHD todavía se encuentra en fase de elaboración [10]. Recientemente, la última versión del estándar SCP-ECG ha pasado a formar parte de la familia de estándares x73 [11]. Sin embargo, dicha integración se encuentra en una fase temprana y existen diversos aspectos en el uso coordinado de SCP-ECG y x73-phd que no se han definido o en los que no se ha alcanzado consenso. Este artículo se organiza de la siguiente manera: en la Sección II se presenta el esquema global extremo a extremo basado en estándares. En la Sección III se presentan los estándares x73 y SCP-ECG y el perfil propuesto para ECGs, teniendo en consideración los campos de SCP-ECG. En la Sección IV se analizan diferentes alternativas para el problema de los datos de paciente. La implementación del interfaz Agente/Manager se presenta en la Sección V. En la Sección VI se establecen las conclusiones y las líneas futuras. Adquisidor ECG Agente Adaptador x73 Dispositivo de ECG conforme a x73/scp XML/ SCP x73/ SCP Fichero SCP ECG Manager CE conforme a x73/scp Network EN13606 Servidor HCE Network HCIS/SCP Network HOSPITAL Visor ECG en tiempo real Servidor de Monitorización y Gestión Visor SCP Figura 1. Arquitectura general basada en estándares end-to-end 756

4. Discusión: los datos de paciente Hay varios campos de SCP-ECG relativos a información sobre el paciente que son obligatorios o recomendables. Para incluirlos, existirían varias maneras de proceder: - Incluir la clase Patient en el DIM, siguiendo el diagrama propuesto en la Fig. 2. (nótese que la clase Patient está marcada en gris). Esta opción tiene algunas ventajas, puesto que evita la configuración previa del Manager, sin embargo, puede encontrarse en una posición contraria a la filosofía de x73-phd, dado que ninguno de los dispositivos definidos hasta ahora incluye datos de paciente. - Configurar previamente el Manager, de tal manera que asigne los datos de paciente correspondientes al ECG recibido. El atributo Person ID definido en x73- PHD puede ser usado para este propósito. Esta idea nos lleva a un modo útil para organizar y configurar MDs. Un perfil de configuración (Configuration Profile, CP) puede ser generado en el servidor de monitorización y gestión y enviado al CE (ver Fig. 3). Este archivo reuniría toda la información requerida pero no almacenada en el MD como los comentados datos de paciente pero, también, la dirección IP del servidor de telemonitorización u otros parámetros. - Generar el archivo SCP-ECG en el servidor de HCE. Es una opción viable, sin embargo, dado que el Manager va a requerir cierta información extra para la gestión de los servicios (como alarmas médicas o direcciones IP), resulta razonable incluir la información de paciente en este flujo de información. Aparte del problema de configuración, existe una cuestión de armonización en lo referente a los datos de paciente. En SCP-ECG, la etiqueta Patient ID (Sección 1, Etiqueta 2) es un string que se usa como primary key en la base de datos de gestión. En x73-phd, el atributo Person ID es un campo de 2 bytes usado para discriminar diferentes usuarios del mismo MD. Por tanto no pueden ser considerados equivalentes, aunque están relacionados. 5. Implementación Como antecedente, cabe señalar la implementación de una plataforma extremo a extremo basada en estándares que fue desarrollada por nuestro grupo [12]. Esta plataforma fue desarrollada en C++ e incluye todas las clases necesarias para simular Agentes y Manager. Los primeros perfiles que se incluyeron fueron: el pulsioxímetro, el tensiómetro y la báscula. En el contexto de este proyecto, un perfil para ECG que se ha definido siguiendo las directrices y premisas de las secciones anteriores se ha añadido a la plataforma. Para ello, se ha implementado el DIM del dispositivo ECG, añadiendo las clases, atributos y métodos del modelo propuesto. Como proof-of-concept se ha implementado la clase Patient. Posteriormente, el framework preexistente se ha usado para conectar, asociar, configurar y operar (mediante las máquinas de estados finitos) un dispositivo de ECG simulado que sigue el estándar x73-phd. El Manager recibe entonces el ECG y genera un archivo SCP-ECG. Los archivos SCP-ECG generados con nuestra aplicación han sido satisfactoriamente testeados con el servicio de certificación que provee OpenECG [13], que incluye un certificador de contenido y otro de formato. Conviene resaltar que, a partir de este interfaz, el sistema sería compatible con cualquier otro dispositivo conforme al estándar SCP-ECG. 6. Conclusiones y líneas futuras En este artículo se ha analizado e investigado la armonización entre dos estándares cercanos. Se ha descrito la relación entre los campos y atributos de ambos estándares. Este proceso nos ha llevado a veces a situaciones ambiguas y confusas que necesitan ser tomadas en consideración cuando se defina el perfil del ECG. Por otro lado, se ha definido, implementado y simulado un perfil ad-hoc como prueba de concepto. Las principales líneas futuras pasan por la inclusión del monitor en tiempo-real, investigando el protocolo a usar, y la configuración remota de parámetros. Agradecimientos Este trabajo ha sido parcialmente subvencionado por los proyectos TIN2008-00933/TSI y TSI2005-07068-C02-01 de la Comisión Interministerial de Ciencia y Tecnología (CICYT), una beca FPI a M. Martínez-Espronceda (res. 1342/2006 de la Universidad Pública de Navarra), y una beca a J.D. Trigo (ref. IT7/08) de Diputación General de Aragón (DGA), Consejo Asesor de Investigación y Desarrollo (CONAID) y Caja de Ahorros de la Inmaculada (CAI). Referencias [1] Chronaki CE, Chiarugi F. Interoperability as a Quality Label for portable & wearable Health Monitoring Systems. Personalised Health: The Integration of Innovative Sensing, Textile, Information & Communication Technologies, Studies in Health Technology and Informatics, Book Series, IOSPress, 2005. [2] Carroll R, Cnossen R, Schnell M, Simons D. Continua: An Interoperable Personal Healthcare Ecosystem. IEEE Pervasive Computing, doi:10.1109/mprv.2007.72, pp. 90-94, 2007. [3] Continua Health Alliance. http://www.continuaalliance.org/ (Consultada: Agosto 2009). [4] Integrating the Healthcare Enterprise. http://www.ihe.net/ (Consultada: Agosto 2009). [5] SCP-ECG, Standard Communication Protocol for Computer- Assisted electrocardiography, EN1064:2005+ A1:2007. [6] OpenECG Project, http://www.openecg.net. (Junio 2009). [7] ISO/IEEE11073. Health informatics. Point-of-care medical device communication (x73poc-md) [Parte 1. MD Data Language (MDDL)] [Parte 2. MD Application Profiles (MDAP)] [Parte 3. Transport and Physical Layers]. http://www.ieee1073.org. 2004. [8] ISO/IEEE11073. Health informatics. Personal Health Devices communication (x73phd). [P11073-00103. Technical report - Overview] [P11073-104xx.Device specializations] [P11073-20601.Application profile-optimized exchange protocol]. http://standards.ieee.org/. Primera edición: 2006. [9] ISO/IEEE11073-10306 Health informatics. Point-of-care medical device communication. Device Specialization - ECG. [10] ISO/IEEE11073-10406 Health informatics. Personal Health Devices communication. Device Specialization - Basic ECG [11] ISO/FDIS 11073-91064 Health informatics. Standard communication protocol: Computer-assisted electrocardiography. [12] Martínez I, Escayola J, Fernández de Bobadilla I, Martínez- Espronceda M, Serrano L, Trigo JD, Led S, García J. Optimization Proposal of a Standard-based Patient Monitoring Platform for Ubiquitous Environments. Int Conf IEEE Eng in Medicine and Biology Society, 2008, pp. 1813-1816. 759

Configuración remota de perfiles de usuario y casos de uso para una solución ubicua de p-salud. M. Gil Lalaguna 1, I. Martínez Ruiz 1, J. D. Trigo Vilaseca 1, P. Muñoz Gargallo 1, M. Martínez-Espronceda Cámara 2 y J. García Moros 1 1 Univ. Zaragoza/Instituto de Investigación en Ing. Aragón (I3A), c/ María de Luna, 3. 50018 Zaragoza 2 Dep. Ingeniería Eléctrica y Electrónica (Univ. Pública Navarra) - Campus de Arrosadía s/n. 31006 - Pamplona maria9684@gmail.com, {imr, jtrigo, jogarmo}@unizar.es, miguel.martinezdeespronceda@unavarra.es, mugnoz.pilar@gmail.com Resumen La telemonitorización de pacientes es uno de los principales campos de aplicación de los servicios de telemedicina. Un diseño adecuado de estos sistemas pasa por la incorporación de los estándares tales como ISO/IEEE 11073 o EN13606. Sin embargo, estos estándares, y por tanto las plataformas que los incorporan, carecen de ciertos parámetros para una correcta gestión del sistema de telemonitorización. En este artículo se identifican los escenarios y casos de uso en los que potencialmente se pueden aplicar estos sistemas de telemonitorización para, posteriormente, presentar un modelo de comunicaciones extremo a extremo que nos permita gestionar de manera eficiente la telemonitorización. Por otro lado, se presenta el diseño de uno de los elementos claves para incluir dicho modelo en una plataforma de esalud. 1. Introducción Los últimos avances en el ámbito de la ingeniería biomédica así como la modernización de la sociedad han posibilitado una mejora en la calidad de vida de pacientes que han de ser controlados. La monitorización de pacientes, bien sea desde un entorno domiciliario u hospitalario, constituye un nuevo servicio cada vez más importante en estos días. La continua mejora de las tecnologías así como el desarrollo de equipos médicos más manejables hacen posible que el propio paciente o personas no expertas puedan realizar un seguimiento desde sus propios hogares, ampliándose así los casos de uso que pueden ser contemplados. Por otro lado, resulta imprescindible que esos sistemas de esalud incorporen estándares de interoperabilidad, de cara a crear soluciones extremo a extremo basadas en estándares. De los diversos estándares médicos desarrollados, destacan dos: el ISO/IEEE11073 [1] (generalmente llamada x73) para la interoperabilidad de dispositivos médicos y el EN13606 [2] para el gestión del Historial Clínico Electrónico (HCE) del paciente. Basándose en estos estándares, en el seno del grupo se ha desarrollado una plataforma de telemonitorización ubicua [3] que consta de los siguientes elementos (ver Fig. 1): - Medical Devices (MDs) y adaptadores x73. Son los dispositivos médicos. Si el dispositivo no cumple la norma x73, se necesita añadir un adaptador a la norma - Computer Engine (CE). El CE es el elemento concentrador que recoge los datos provenientes de los MDs. En la práctica se tratará de un dispositivo inalámbrico que llevará consigo el propio usuario que le indicará al usuario cuándo y cómo debe procederse a la toma de medidas. - Management Server (MS). Este servidor se encargará de gestionar el flujo de información del sistema y el control de pacientes. - Servidor de HCE EN13606. Es un contenedor de información clínica, donde se encuentran las bases de datos con las HCE de los pacientes. Los datos provenientes de cada MD son incorporados al HCE del paciente. Este servidor se comunicará con otros servidores homólogos siguiendo la norma EN13606. Agentes x73 Manager Red EN13606 Compute Engine Servidor de Gestión Servidor de HCE Figura 1. Esquema de la plataforma de telemonitorización Para poder llevar a cabo un correcto funcionamiento de estos servicios es necesario un sistema de supervisión y gestión de medidas médicas incluyendo los procedimientos funcionales de uso y toma de decisiones. Dado que la monitorización de pacientes puede ser llevada a cabo en diferentes escenarios de aplicación y para diferentes patologías, los procedimientos serán distintos según el entorno en el cual nos encontremos. Por otro lado, los estándares considerados en la plataforma no tienen en cuenta ciertos parámetros que son necesarios para una correcta gestión de la telemonitorización. Por tanto, es necesario, en primer lugar, un exhaustivo análisis de los casos de uso, escenarios de aplicación y dispositivos médicos potencialmente utilizables, en segundo lugar, el diseño de un modelo de comunicaciones que basándose en la práctica clínica, permita describir el comportamiento, los procedimientos y los estados que atravesará el sistema y, en tercer lugar, incorporar algún elemento a la plataforma que nos permita contemplar las particularidades en los procesos de control para diferentes casos de uso o patologías, que van a regir los procedimientos a llevar a cabo en la toma de medidas y decisiones para cada paciente en concreto. 689

4. El elemento Config.Profile El Config.Profile es un elemento clave para que el funcionamiento de la solución que se está diseñando sea el adecuado. Es el archivo que va a contener toda la información asociada a los procedimientos que deben seguir los pacientes que gestiona un mismo CE. Este elemento es generado en el servidor de gestión, MS (Management Server). La información que contiene procede de una base de datos que es completada por un operario a partir de dos fuentes de información distintas. Por un lado se obtienen los datos necesarios de la historia clínica electrónica de cada paciente y por otro lado se introduce información adicional al caso de uso de cada paciente manualmente. Una vez completa la información que debe contener Config.Profile se genera un archivo XML que es el que se envía a CE para que el proceso de monitorización sea correcto (ver Fig. 3). El Config.Profile es en definitiva un archivo XML que se genera en el MS y que es único por cada CE. Se generará uno distinto para cada uno de los CEs que conste que se están utilizando y da toda la información necesaria para poder personalizar la aplicación para cada paciente. La información necesaria para rellenar Config.Profile estaría contenida en una base de datos que sigue el modelo de la Fig. 4. Para su diseño, resultan de vital importancia los análisis detallados en la Sección 2. La base de datos consta de las siguientes tablas de relaciones: - Tabla MD. Contiene información muy genérica relativa a los dispositivos médicos tales como tipo, marca o modelo. - Tabla CE. En esta tabla quedarán registrados todos los CEs que se están utilizando para llevar a cabo la monitorización de pacientes. - Tabla Patient. Aquí estarán recogidos todos los pacientes que de una forma u otra están siendo controlados y que tendrán un único identificador. - Tabla Doctor. En la presente tabla quedarán registrados todos los médicos o enfermeros que estén realizando el seguimiento de algún paciente. - Tabla Measure. Debido a que con cada MD pueden tomarse diferentes tipos de medidas, esta tabla se ha diseñado de forma que tenga listadas todas las medidas que pueden tomarse. - Tabla Interpers. Recoge las relaciones que se establecen entre algunas de las tablas. - Tabla Procedure. Esta es la tabla final en la quedarán asociados todos los procedimientos a llevar a cabo para cada paciente. Agentes Dispositivos Médicos x73 Manager datos x73 Config Profile idce Red Otra info + Datos de paciente Base de Datos Datos de paciente Compute Engine Servidor de Gestión Servidor de HCE Figura 3. Papel del Config.Profile en la plataforma Config Profile MD Table idmd MDtype trademark model CE Table idce iduser trademark model Measure Table idmeasure MeasureType idmd MaxFuncThres MinFuncThres Procedure Table id idrel idmeasure Date MaxMedThres MinMedThres Patient Table Interpers Table PATType idpat idrel name idce surname idpat birthday iddoc sex Doctor Table iddoc name surname idrol Figura 4. Modelo de la base de datos 5. Conclusiones y líneas futuras Por un lado, se ha diseñado un modelo de comunicaciones para una plataforma ubicua de p-salud. Por otro lado, se ha diseñado un elemento (el Config.Profile) que se integra en dicha plataforma para cumplir con el modelo de comunicaciones propuesto. De este modo, se ha cubierto un espacio que actualmente dejan vacío los estándares existentes. La principal línea futura abarca las fases de implementación y pruebas tanto del Config.Profile como del diseño funcional propuesto. Otras líneas que se contemplan son: el rediseño del archivo Config.Profile siguiendo un modelo dual de referencia y de conocimiento y la gestión remota de MDs (umbrales de funcionamiento, identificadores de paciente, etc.). Agradecimientos Este trabajo ha sido parcialmente subvencionado por los proyectos TIN2008-00933/TSI y TSI2005-07068-C02-01 de la Comisión Interministerial de Ciencia y Tecnología (CICYT) y Fondos Europeos para el Desarrollo Regional (FEDER), una beca FPI a M. Martínez-Espronceda (res. 1342/2006 de la Universidad Pública de Navarra), y una beca a J.D. Trigo (ref. IT7/08) de Diputación General de Aragón (DGA), Consejo Asesor de Investigación y Desarrollo (CONAID) y Caja de Ahorros de la Inmaculada (CAI). Referencias [1] ISO/IEEE11073. Health informatics. Personal Health Devices communication (x73phd). [P11073-00103. Technical report - Overview] [P11073-104xx.Device specializations] [P11073-20601. Optimized exchange protocol]. http://standards.ieee.org/, 2006. [2] EN13606. Health informatics. Electronic Health Record communication - Parts: 1, 2, 3, 4 y 5. http://isotc.iso.org, 2007/2009. [3] Martínez I, Escayola J, Fernández de Bobadilla I, Martínez- Espronceda M, Serrano L, Trigo JD, Led S, García J. Optimization Proposal of a Standard-based Patient Monitoring Platform for Ubiquitous Environments. Conf. IEEE Eng in Medicine and Biology Society, pp. 1813-1816. 692

El estándar SCP-ECG en el entorno ISO/IEEE 11073-PHD: Transmisión Store-and-Forward e intercambio de mensajes. J. D. Trigo Vilaseca 1, F. Chiarugi 2, Á. Alesanco Iglesias 1, M. Martínez-Espronceda Cámara 3, L. Serrano Arriezu 3, C. E. Chronaki 2, J. Escayola Calvo 1, I. Martínez Ruiz 1 y J. García Moros 1 1 Univ. Zaragoza/Instituto de Investigación en Ing. Aragón (I3A), c/ María de Luna, 3. 50018 Zaragoza 2 Institute of Computer Science (ICS), Foundation for Research and Technology Hellas (FORTH), Heraklion, Crete, Greece 3 Dep. Ingeniería Eléctrica y Electrónica (Univ. Pública Navarra) - Campus de Arrosadía s/n. 31006 - Pamplona {jtrigo, alesanco, jescayola, imr, jogarmo}@unizar.es, {miguel.martinezdeespronceda, lserrano}@unavarra.es, {chiarugi, chronaki}@ics.forth.gr Resumen Durante las últimas décadas se han desarrollado y estandarizado una amplia variedad de protocolos de almacenamiento y transmisión de señales electrocardiográficas. El estándar SCP-ECG, que representa uno de los esfuerzos más importantes en este ámbito, ha sido incorporado recientemente a la familia de estándares ISO/IEEE 11073 (x73), estándar de referencia en el marco de la interoperabilidad de dispositivos médicos. Sin embargo, dicha integración se encuentra aún en sus primeras etapas. En este artículo se investigan y discuten las relaciones entre los campos y mensajes del estándar SCP-ECG y el procedimiento específico del estándar x73-phd para gestionar los datos almacenados en los dispositivos médicos. Asimismo, se presenta una implementación del método del x73- PHD aplicado al caso particular de los ECGs que sirve tanto de prueba de concepto como para identificar puntos abiertos y potenciales modificaciones del estándar. 1. Introducción Un gran número de aplicaciones de Telemedicina, como por ejemplo las consultas de dermatología o radiología, no requieren una respuesta inmediata. Debido a sus características, la técnica Store-and-Forward es el procedimiento que mejor encaja en este tipo de situaciones. Además, el futuro de la Telemedicina apunta a un crecimiento significativo del uso de esta técnica en muchas áreas de los servicios de salud [1]. Desde un punto de vista técnico, la señal electrocardiográfica (ECG) resulta particularmente adecuada para el uso del procedimiento Store-and- Forward [2]. Por ello, durante los últimos años ha proliferado la definición de protocolos y estándares en este contexto. Algunos de los más conocidos son: el SCP- ECG (estándar europeo EN1064), el HL7 aecg (estándar americano, ANSI) o el DICOM Waveform Sup 30. En un futuro cercano, el estándar de interoperabilidad ISO/IEEE 11073-PHD (x73-phd) también será capaz de gestionar la transmisión de ECGs mediante la técnica de Store-and Forward. En la literatura se pueden encontrar una amplia variedad de proyectos que muestran las relaciones entre dos o más de estos estándares (Fig. 1). Algunos ejemplos de esas relaciones son: SCP-ECG con DICOM [3,4]; SCP-ECG y HL7 aecg con DICOM [5]; SCP-ECG con HL7 aecg [6]; o SCP-ECG con x73-phd [7]. X73-PHD [7] [6] SCP-ECG HL7 aecg [3] [4] [5] [5] DICOM Figura 1. Relación entre diferentes formatos en la literatura Los estándares SCP-ECG [8] y x73-phd [9] están íntimamente relacionados. De hecho, la última versión del estándar SCP-ECG ha sido aceptada recientemente como parte de la familia estándares x73 [10]. Varios dispositivos médicos cuentan ya con un perfil definido en el estándar x73-phd, pero todavía no se ha definido un perfil propio para los dispositivos de ECGs, si bien existe una línea de trabajo en esa dirección [11]. Resulta patente que en la definición de ese perfil para ECGs, el estándar SCP-ECG ha de ser tenido en cuenta. Sin embargo, el proceso de integración de ambos estándares se encuentra aún en una fase temprana y, por tanto, existen todavía varios aspectos que no se han analizado e investigado adecuadamente en el uso coordinado de SCP-ECG y x73-phd, especialmente en el caso de la transmisión Store-and-Forward de ECGs. 2. Arquitectura Como prueba de concepto, se presenta la siguiente arquitectura de un sistema de e-salud extremo a extremo basado en estándares (Fig. 2). En ella, un dispositivo compatible con x73-phd y SCP-ECG (llamado Agente) registra y almacena la señal ECG. Este Agente se comunica con una entidad también compatible con x73- PHD y SCP-ECG (llamada Manager) y le informa de que existen datos almacenados en el Agente que todavía no han sido enviados. El Manager reenviaría este mensaje a un Servidor de Gestión que, entre otras tareas, se encargaría de decidir si recuperar o no esa información. Si la decisión que se toma es la de recuperar los datos, el Agente le enviará al Manager esa información (haciendo uso del procedimiento de x73-phd) y así reunirá todos los datos necesarios para la generación de archivo SCP- ECG. Posteriormente, el archivo sería enviado, mediante el uso de extensible Markup Language (XML) a un servidor de Historia Clínica Electrónica (HCE). A este servidor se conectarán otras entidades para consultas compatibles con el estándar EN13606. El archivo SCP- ECG podrá ser consultado mediante algún sistema de información (Healthcare Information System, HIS). 693

5. Implementación Como antecedente, cabe señalar la implementación de una plataforma extremo a extremo basada en estándares que fue desarrollada por nuestro grupo [12]. Esta plataforma fue desarrollada en C++ e incluye todas las clases necesarias para simular Agentes y Manager. Los primeros perfiles que se incluyeron fueron: el pulsioxímetro, el tensiómetro y la báscula. Posteriormente se incorporó un perfil para simular ECGs, que contemplara el envío en tiempo real del ECG y el estándar SCP-ECG [7]. En el proyecto descrito en este artículo, y como valor añadido a anteriores publicaciones, ese perfil para ECGs fue mejorado, posibilitando la trasmisión Store-and-Forward de ECGs, haciendo uso del concepto de métrica persistente de x73-phd. En nuestra aplicación, el PM- Store se ha organizado de la siguiente manera: - PM-Store: Contiene todos los ECGs almacenados en el dispositivo. El atributo Number-Of-Segments especifica el número de ECGs almacenados. - PM-Segment: Un ECG. El atributo PM-Seg-Person-Id identifica al paciente/usuario. - Entry: Encapsula una derivación (por Entry) en una estructura RT-SA. Contiene los datos propiamente dichos, pero también la información relacionada con la derivación (las especificaciones de la forma de onda). - Element: Una muestra de una derivación del ECG. Los primeros Elements en la Entry se corresponden con la información de la derivación contenida en esa Entry. Por otro lado, el estándar x73-phd establece que sólo entradas completas se han de incluir en un evento SegmentDataEvent. Dependiendo de diferentes parámetros (frecuencia de muestreo, tamaño de la muestra o duración de la señal grabada), la longitud total de una derivación puede exceder el límite de 63KBytes. Se pueden considerar varias aproximaciones al problema: - Dividir las derivaciones en varias Entries/Segments. Esta aproximación puede ofuscar la organización jerárquica. Además, se deberían acometer algunas modificaciones en el estándar x73-phd para reensamblar las partes del ECG fragmentado. - Posibilidad de fragmentar las Entries. La idea es modificar el estándar x73-phd para que una Entry pueda ser dividida en SegmentDataEvents que se envíen secuencialmente. Ésta es la aproximación que se ha implementado en nuestra plataforma, añadiendo unos campos que indican el índice del fragmento y el número total de fragmentos que componen la Entry. - Limitar el tiempo máximo de ECG. El estándar x73- PHD podría decidir limitar el tiempo máximo que un dispositivo ECG es capaz de almacenar en función de la frecuencia de muestreo, el tamaño de la muestra y el máximo tamaño de trama (considerando las cabeceras) para que se ajusten a una única Entry. Por último, resaltar que los archivos SCP-ECG generados con nuestra aplicación han sido satisfactoriamente testeados y chequeados con el servicio de certificación que provee el portal OpenECG portal [13]. Este servicio incluye un certificador de contenido y otro de formato. 6. Conclusiones y líneas futuras A una plataforma extremo a extremo basada en estándares que ya incluía un perfil x73-phd diseñado ad-hoc para ECGs, se le ha añadido la posibilidad de transmisión Store-and-Forward. Se ha incluido también una mejora para que cubra la transmisión Store-and-Forward de ECGs de larga duración. Se han estudiado y discutido las posibles aplicaciones de la parte de mensajería de SCP- ECG en un entorno x73-phd. Por último, se han descrito y analizado las relaciones entre los diferentes mensajes y tramas de ambos estándares. Este proceso ha culminado con la constatación de que el concepto PM-Store de x73-phd es una idea bien definida y diseñada para manejar los datos almacenados en los dispositivos médicos, incluyendo ECGs. Si bien es cierto que los mensajes de SCP-ECG son cubiertos en su práctica totalidad por la aproximación de x73-phd, algunas de estas ideas, que pierden su sentido en un interfaz x73-phd, podrían aplicarse al interfaz Manager/Servidor de Gestión. La principal línea futura de investigación es la implementación del Servidor de Gestión, que cubriría no solo la gestión médica sino también la gestión técnica, incluyendo así a Managers y Agentes en la red de gestión. Agradecimientos Este trabajo ha sido parcialmente subvencionado por los proyectos TIN2008-00933/TSI y TSI2005-07068-C02-01 de la Comisión Interministerial de Ciencia y Tecnología (CICYT), una beca FPI a M. Martínez-Espronceda (res. 1342/2006 de la Universidad Pública de Navarra), y una beca a J.D. Trigo (ref. IT7/08) de Diputación General de Aragón (DGA), Consejo Asesor de Investigación y Desarrollo (CONAID) y Caja de Ahorros de la Inmaculada (CAI). Referencias [1] Reimer L, Liu L, Henderson I. Beyond videoconference: A literature review of store-and-forward applications in Telehealth. Proceedings of the Second International Conference on Telehealt, 2006, pp. 125-130. [2] Wootton R, Craig J, Patterson V (Editors). Introduction to telemedicine. 2nd Ed, pp. 44. Rittenhouse Book Distributors, 2006 (ISBN: 978-1853156779). [3] Sakkalis V, Chiarugi F, Kostomanolakis S, Chronaki CE, Tsiknakis M, Orphanoudakis SC. A gateway between the SCP-ECG and the DICOM supplement 30 waveform. Computers in Cardiology, 2005, pp. 25-28. [4] Ling-ling W, Ni-ni R, Li-xi P, Gang W. Developing a DICOM Middleware to Implement ECG Conversion and Viewing. Int Conf IEEE Eng in Medicine and Biology Society (EMBS 05), Shangai, 2005, pp. 6953-6956. [5] van Ettinger MJB, Lipton JA, de Wijs MCJ, van der Putten N, Nelwan SP. An open source ECG toolkit with DICOM. Computers in Cardiology (CinC 08), Bologna, 2008, pp. 441-444. [6] Schloegl A, Chiarugi F, Cervesato E, Apostolopoulos E, Chronaki CE. Twoway converter between the HL7 aecg and SCP-ECG data formats using BioSig. Computers in Cardiology (CinC 07), Durham, 2007, pp. 253-256. [7] Trigo JD, Chiarugi F, Alesanco Á, Martínez-Espronceda M, Chronaki CE, Escayola J, Martínez I, García J. Standard-Compliant Real-Time Transmission of ECGs: Harmonization of ISO/IEEE 11073-PHD and SCP- ECG. Int Conf IEEE Eng in Medicine and Biology Society, 2009. [8] SCP-ECG, Standard Communication Protocol for Computer-Assisted electrocardiography, EN1064:2005+ A1:2007. [9] ISO/IEEE11073, Health informatics, Medical Devices communication [P11073-20601.Application profile-optimized exchange protocol]. http://standards.ieee.org/. First edition: 2006. [10] ISO/FDIS 11073-91064, Health informatics, Standard communication protocol Part 91064: Computer-assisted electrocardiography. [11] ISO/IEEE11073-10406, Health informatics, Personal Health Devices communication. Device Specialization - Basic ECG (1-3 lead). [12] Martínez I, Escayola J, Fernández de Bobadilla I, Martínez-Espronceda M, Serrano L, Trigo JD, Led S, García J. Optimization Proposal of a Standardbased Patient Monitoring Platform for Ubiquitous Environments. Int Conf IEEE Eng in Medicine and Biology Societ, 2008, pp. 1813-1816. [13] OpenECG Project, http://www.openecg.net. (Consultada: Agosto 2009). 696

Interoperabilidad de dispositivos médicos mediante el estándar ISO/IEEE 11073 sobre tecnología Bluetooth P. Del Valle García 1, J.D. Trigo Vilaseca 1, I. Martínez Ruiz 1, J. Escayola Calvo 1, M. Martínez-Espronceda Cámara 2, L. Serrano Arriezu 2, J. García Moros 1 1 Univ. Zaragoza/Instituto de Investigación en Ing. Aragón (I3A), c/ María de Luna, 3. 50018 Zaragoza. 2 Dep. Ingeniería Eléctrica y Electrónica (Univ. Pública Navarra) - Campus de Arrosadía s/n. 31006 - Pamplona pdelvallegarcia@gmail.com, {jtrigo, imr, jescayola, jogarmo}@unizar.es, {miguel.martinezdeespronceda, lserrano}@unavarra.es Resumen El estándar ISO/IEEE11073 permite proporcionar interoperabilidad ubicua y en tiempo real para los diferentes dispositivos médicos que necesite el paciente y facilita el intercambio eficiente de los signos vitales y de la información asociada a los dispositivos en diferentes entornos clínicos. Este trabajo da una solución para la capa de transporte integrada en el estándar, proporcionando una comunicación entre agente y manager sobre tecnología Bluetooth. El agente implementado es un tensiómetro que se simulará a través de un dispositivo móvil con puerto Bluetooth y el manager es un dispositivo SmartPhone HTC-3G. Ambos incluyen la implementación integra de la última versión del estándar ISO/IEEE11073 para dispositivos de salud personal X73PHD y constituyen un completo entorno de pruebas para demostrar la eficacia del estándar e incorporar nuevas evoluciones futuras. 1. Introducción El intercambio interoperable de información se puede entender como una serie de enormes beneficios para los sistemas sanitarios y los programas de telemedicina: los pacientes tendrán una mejor información sobre su estado de salud y los médicos tendrán la capacidad de controlar los signos vitales con mucha más facilidad. Así, la interoperabilidad de equipos médicos de distintos fabricantes a través de la estandarización se plantea como un requisito básico en las nuevas soluciones de e-salud. Este contexto presenta dificultades de integración debido a que los dispositivos médicos no suelen incorporar interfaces de comunicación estándar (USB, Bluetooth, etc.) y, aún así, los que los incorporan no garantizan intercomunicación homogénea ya que no cumplen con ningún estándar En este contexto, la vía europea de estandarización propone ISO/IEEE11073 (X73) [1]. X73 es una familia de estándares para interoperabilidad de dispositivos médicos que abarca los siete niveles de la pila de protocolos y proporciona la versatilidad suficiente para intercambiar datos médicos entre un dispositivo de salud personal (Medical Device (MD), que actúa como agente) y un sistema central de registro (Compute Engine (CE), que actúa como manager). Estos datos pueden ser enviados a un centro remoto de control para su almacenamiento en el Historial Clínico Electrónico (HCE) y su posterior consulta (conforme al estándar EN13606). Así, se permite construir soluciones globales basadas en estándares extremo-a-extremo [2]. El estándar X73 nació enfocado a su implantación en Unidades de Cuidados Intensivos (Point-of-Care, X73PoC) y, en los últimos años, ha experimentado diversas evoluciones no contempladas inicialmente (nuevos casos de uso, nuevos perfiles, etc.). En esta línea, el Comité Europeo de Normalización se ha adaptado a esta realidad tecnológica con una la versión para entornos de salud personal (Personal Health Device, X73PHD). La nueva versión incluye interfaz wireless, para avanzar hacia soluciones en entornos ubicuos. La tecnología de la que se hace uso en esta comunicación agente-manager es Bluetooth que es una especificación industrial para Redes Inalámbricas de Área Personal (Wireless Personal Area Networks, WPANs) que posibilita la comunicación entre diferentes dispositivos mediante un enlace por radiofrecuencia segura y globalmente libre (2,4 GHz). Actualmente existen muchos fabricantes que ya incorporan en el diseño de sus dispositivos médicos la tecnología Bluetooth. La empresa A&D Medical [3] posee, por ejemplo, el monitor UA-767PBT que puede enviar en tiempo real las medidas de presión sanguínea realizadas a un punto de acceso, o almacenarlas y posteriormente enviarlas a través de tecnología Bluetooth. Nonin Medical [4] ofrece soluciones de vigilancia de oximetría para simplificar el intercambio de información segura. La integración de la interoperabilidad y la tecnología inalámbrica Bluetooth permite a los pacientes, junto con sus médicos, realizar una monitorización de los signos vitales. El Onyx II 9560 permite supervisar a distancia pacientes con enfermedades crónicas como la Enfermedad Pulmonar Obstructiva Crónica (EPOC), Insuficiencia Cardíaca Congestiva (ICC) o el asma. También proporciona una conexión Bluetooth 2.0 segura para el intercambio de información vital lo que le profiere alta versatilidad, ya que se conecta fácilmente a diferentes dispositivos como teléfonos móviles, PDAs, smartphones, etc. En Marzo de 2009, Continua Health Alliance [5] publicó el lanzamiento del primer producto Certificado Continua en el mercado mundial: un pulsioxímetro portátil Continua certificado con puerto USB, 2500 PalmSAT. En este contexto, este artículo abarca la implementación del estándar X73PHD en dispositivos personales sobre tecnología Bluetooth partiendo de las una plataforma previa basada en estándares extremo-a-extremo. El artículo se organiza de la siguiente manera: en la Sección II se presenta la última evolución de la plataforma sobre tecnología Bluetooth. En la Sección III se describe el diseño de la solución propuesta, detallando sus características técnicas y los aspectos claves del diseño y la implementación. En la Sección IV se exponen los resultados obtenidos con un tensiómetro sobre tecnología Bluetooth y un manager wireless sobre SmartPhone HTC-3G. Las conclusiones y las líneas futuras globales del trabajo se discuten en la Sección V. 713

SHOW DEVICES Discover Devices CREATE THREAD Get Local Device Name START AUDITOR MANAGER Comprobación finalizada. INICIO PROGRAMA Get Number Device RESTART Comprobando... Open Server Connection Get Device Info Figura 3. Esquema de funcionamiento de la comunicación Bluetooth Una vez realizada ShowDevice, se ejecuta la siguiente función CreateThread, que en uno de sus campos posee el resultado obtenido de ShowDevice. Esta función crea un hilo de ejecución, con las funciones GetLocalDeviceName, que devuelve el nombre del dispositivo, y OpenServerConnection que abre un socket y crea otro hilo de ejecución, para escuchar los mensajes entrantes. 4. Resultados Como resultado del diseño e implementación anterior, se ha desarrollado un entorno real de comunicación X73PHD entre un agente X73 (implementado sobre el tensiómetro A&D Medical UA-767PBT y simulando su FSM conforme a X73PHD a través de un dispositivo móvil con puerto Bluetooth) y un manager X73 (implementado sobre un dispositivo Smartphone HTC-3G). La Figura 4(a), muestra los mensajes aparecidos en la pantalla de CE y da ejemplo de la comunicación X73PHD con un tensiómetro. En primer lugar, mediante la fase de conexión, se realiza únicamente la búsqueda de la dirección Bluetooth asociada a dicho tensiómetro. El CE transmite entonces el aviso: manager a la escucha y, una vez completado el envío de tramas que determina el estándar, el programa le da la bienvenida. Al mismo tiempo, se recibe este mensaje en el MD y es entonces cuando finaliza la fase de conexión, que termina con Conexión X73 completada. Para la fase de Envío de Datos Médicos se ha elaborado dentro del código el envío de datos de prueba: Medical Data: SYS 128, DIA 78. Después de recibir esta trama de ejemplo, ya se podría proceder a desconectar el tensiómetro. Entonces, hay que esperar hasta que, tras el envío de las tramas que marca el estándar, se haya desconectado finalmente el MD. Para ello, según X73PHD, es necesario realizar un envío de tramas de release request y después será cuando esté totalmente desconectado y listo para una próxima conexión. Previamente, se ha de establecer con el médico cuál ha de ser la periodicidad de las medidas. Así, la HCE del paciente ha tenido que ser actualizada para establecer una serie de alarmas que se activarán en su CE. Por último, cabe destacar que se han realizado una serie de pruebas en un entorno cerrado con el objetivo de estudiar la fiabilidad del sistema desarrollado. El resultado de dichas pruebas ha sido altamente satisfactorio, si bien debería ser tomado con cautela a la hora de extrapolarlo a un entorno real. (a) BT X73 Manager (b) Auditor X73 Figura 4. Interfaz gráfico de usuario diseñado 5. Conclusiones y líneas futuras En este artículo se ha propuesto una solución que proporciona ubicuidad a un plataforma preexistente basada en estándares extremo a extremo. Gracias al sistema desarrollado, podrán realizar la toma de medidas desde su casa, oficina o lugar de ocio sin necesidad de desplazarse a un centro médico, con la comodidad de dispositivos pequeños e inalámbricos y cumpliendo con X73PHD que permite interoperabilidad de los dispositivos independientemente del fabricante. En este contexto, y a partir de los resultados obtenidos, las principales líneas abiertas para futuros trabajos implicarían desarrollar tres nuevos sistemas a integrar en la plataforma: DEMOSTRADOR X73PHD, entorno que servirá para rescatar las funciones X73PHD puras y de C++ core, y poder permitir una descarga didáctica de qué es el estándar, mostrar cómo funciona y qué aplicabilidad tiene. TESTER X73PHD, aplicación que permitirá servir de demostrador del correcto funcionamiento del estándar X73PHD para nuevos dispositivos MDs y con interfaz de customizada dependiendo del escenario de aplicación. AUDITOR X73, ver Figura 4(b), sistema que permitirá realizar una auditoría técnica. El sistema CE realizará un envío de tramas X73PHD para realizar una comprobación de si los MDs cumplen o no cumplen los requisitos del estándar y devolver un report que confirmaría el buen funcionamiento del sistema o mostraría la lista de errores sucedidos para no cumplir con los requisitos. Agradecimientos Este trabajo ha sido parcialmente subvencionado por los proyectos TIN2008-00933/TSI y TSI2005-07068-C02-01 de la Comisión Interministerial de Ciencia y Tecnología (CICYT) y Fondos Europeos para el Desarrollo Regional (FEDER), una beca FPI a M. Martínez-Espronceda (res. 1342/2006 de la Universidad Pública de Navarra), y una beca a J.D. Trigo (ref. IT7/08) de Diputación General de Aragón (DGA), Consejo Asesor de Investigación y Desarrollo (CONAID) y Caja de Ahorros de la Inmaculada (CAI). Referencias [1] ISO/IEEE11073. CEN/TC251. Point-of-Care MD Communication standard (X73-PoC). Personal Health Devices standard (X73- PHD).www.standards.ieee.org/ - www.ieee1073.org. Último acceso: 06/09. [2] I. Martínez et al., "Implementation of an end-to-end standard-based patient monitoring solution," IET Commun 2(2):181-191, 2008. [3] A&D Medical. www.andmedical.com/and_med.nsf/. Último acceso: 06/09. [4] Nonin Medical. www.nonin.com/. Último acceso: 06/09. [5] Continua Health Alliance. www.continuaalliance.org/. Último acceso: 06/09. [6] I. Martínez et al. Propuesta de plataforma de telemonitorización según X73 y su adecuación a casos de uso habituales. XXV CASEIB, pp. 330-383, 2007. [7] J.Escayola et al. Implementación de una plataforma ubicua de Monitorización de pacientes basada en el estándar X73. XXV CASEIB, pp. 273-276, 2008. 716

INTENSA: Sistema de monitorización de pacientes con insuficiencia cardíaca basado en el estándar ISO/IEEE11073 M. Martínez-Espronceda 1, I. Martínez 2, S. Led 1, J. D. Trigo 2, I. Osés 1, J. Escayola 2, L. Serrano 1, J. García 2, y A. García 3 1 Dep. Ingeniería Eléctrica y Electrónica (Univ. Pública de Navarra) - Campus de Arrosadía s/n. 31006 - Pamplona 2 Univ. Zaragoza/Instituto de Investigación en Ing. Aragón (I3A), c/ María de Luna, 3. 50018 Zaragoza 3 Hospital Universitario Doctor Negrín, c/ Barranco de la Ballena, s/n. 35010 Las Palmas de Gran Canaria Este artículo presenta una novedosa metodología de implementación del estándar ISO/IEEE11073 basado en el paradigma de patrones para uso en plataformas de monitorización reales. Estas plataformas de monitorización incluyen algunos dispositivos médicos basados en microcontroladores de baja tensión y ultrabajo consumo. Como prueba de concepto, el proyecto INTENSA cuyo objetivo es desarrollar y evaluar un sistema interoperable para seguimiento de pacientes con insuficiencia cardíaca incluyendo báscula, tensiómetro y dispositivo HOLTIN, es descrito brevemente. 1. Introducción E L rápido desarrollo de las Tecnologías de la Información y de las Comunicaciones (TICs) está impulsando la transformación de los sistemas de salud tradicionales en entornos centrados en el paciente. El así llamado apoderamiento del paciente [1] está cambiando el papel convencional de pacientes y médicos en una nueva distribución en donde el paciente toma el control de su salud y bienestar. Por otra parte, la monitorización de diferentes constantes vitales, por ejemplo ECG, peso o presión arterial, es un tema clave en el seguimiento de algunas enfermedades tales como insuficiencia cardíaca, enfermedad pulmonar obstructiva crónica (Chronic Obstructive Pulmonary Disease, COPD), hipertensión arterial (la cual es uno de los mayores factores de riesgo para enfermedades del corazón, apoplejías y también un indicador de pronóstico de fallos renales), o la obesidad, la cual incrementa la probabilidad de sufrir otras enfermedades como diabetes, colesterol, hipertensión, enfermedades en articulaciones, mal función de la vesícula biliar o complicaciones coronarias y respiratorias entre otras [2]. Se hace esencial la disponibilidad de dispositivos médicos (Medial Devices MDs), también llamados de salud personal (Pernosal Health Devices), que ayuden a los pacientes a auto-gestionar el seguimiento de sus enfermedades. Estos MDs serán de tipo inalámbrico y llevables de forma que sean lo más útiles y manejables, y integrarán estándares de comunicaciones para la transmisión de información biomédica. Como un ejemplo, una plataforma desarrollada por nuestro grupo es HOLTIN [3] el cual consiste en un dispositivo llevable e inteligente tipo holter basado en tecnología inalámbrica Bluetooth que envía, vía un teléfono móvil, eventos cardíacos a un centro de salud. Sin embargo en la mayor parte de los casos estos MDs son cerrados y emplean protocolos propietarios que imposibilitan o dificultan su extrapolación a otros escenarios. En este contexto, algunos protocolos han emergido para cubrir el hueco de interoperabilidad. Uno de los más ampliamente conocidos es el estándar ISO/IEEE11073 (X73). Inicialmente diseñado para el punto de cuidado del paciente (Point-of-Care, X73PoC) [4], ha evolucionado recientemente a dispositivos de salud personal (X73PHD) [5], para incluir las nuevas tecnologías de transmisión inalámbrica emergentes (tales como Bluetooth, ZigBee, o WiFi), y dispositivos llevables de limitadas capacidades. La topología básica de un sistema de monitorización basado en X73 comprende tres segmentos: el MD, el dispositivo pasarela (Compute Engine, CE) y el servidos de monitorización y gestión (Monitoring System, MS). El MD (también llamado agente) adquiere la información biomédica y la envía al CE empleando X73; el CE (también llamado manager) recoge toda esa información junto con la del resto de MDs de su red personal (Personal Area Network, PAN) y la transmite al MS; el MS tiene la tarea de recopilar toda esa información, realizar diagnósticos (mediante un cribado para casos triviales y diagnóstico de un especialista para casos que lo necesiten), enviar alarmas y gestionar la red en línea de forma global. Sin embargo X73 tiene algunas debilidades que merece la pena mencionar y son: la elevada complejidad, el tiempo necesario para aprenderlo e implementarlo, la integración con otros estándares, la falta de herramientas de ayuda para los desarrolladores, o los requerimientos de hardware para poder ejecutarlo. Estas cuestiones entre otras son el foco de nuestro trabajo, el cual se está llevando a cabo con la colaboración del Comité Europeo de Normalización (CEN) y ha producido sus primeros resultados [6,7] usados como base para el resto del artículo. El artículo está organizado de la siguiente forma. La Sección II presenta una explicación sobre una propuesta de plataforma de salud personal interoperable basada en X73PHD para seguimiento de pacientes de insuficiencia cardíaca, mostrando las principales características y debilidades encontradas. Más tarde la sección III da un repaso a X73PHD especialmente planteando los conceptos básicos necesarios para implementar X73 en sistemas basados en microcontroladores, y en la sección IV se propone una metodología y una arquitectura que permite la implementación de X73 en sistemas basados en microcontroladores de recursos limitados. En la sección V, se presenta una revisión de tendencias futuras. Finalmente, se muestran las conclusiones en la sección V. 709

comunicación X73PHD pueden obtenerse enlazando únicamente una serie de bloques de bytes constantes (que por tanto pueden ser almacenados en flash) y unas pocas variables de programa (ver Fig 2). Los bloques son llamados patrones y se agrupan en una librería que llamamos librería de patrones. Esto es similar a la idea de mensajes enlatados (canned messages) pero usa un algoritmo generalizado. Esta idea puede llevar a una implementación altamente optimizada cuando se aplica a los agentes X73PHD. Una vez se ha seleccionado una especialización concreta, el rango de los patrones que un agente necesita para procesar un mensaje X73PHD se reduce considerablemente. La arquitectura propuesta para un agente genérico se muestra en Fig 3. Los componentes básicos son: la librería de patrones (mencionada arriba) y el núcleo X73. El núcleo X73 es la tarea que se encarga del ensamblado, procesado, comparación y transmisión de los patrones. Además gestiona el estado de la FSM, de los objetos en el DIM y de algunas señales que incluyen datos recibidos o enviados, conexión establecida, conexión perdida, señales de timer para los escáneres (tales como PeriCfgScanner), etc. Hay también otros dos componentes importantes en esta arquitectura: Los driver específicos dependientes de la especialización, que proveen funciones básicas al núcleo para permitirle manipular el hardware; y la capa de adaptación pone en contacto al núcleo con la pila del protocolo de transporte. El núcleo X73 y la librería de patrones son independientes de la capa de transporte y por tanto una misma implementación puede ser compartida por varias plataformas de una misma especialización aunque usen diferentes tecnologías de comunicación. El componente más complejo en la arquitectura es el núcleo X73PHD ya que está a cargo del correcto funcionamiento global del stack X73PHD. Como prueba de concepto se ha realizado una implementación de un tensiómetro. Para agilizar su desarrollo se ha usado un sistema operativo en tiempo real que proporciona utilidades comunes de programación y depuración (FreeRTOS) aunque no es necesario su uso en una plataforma final. Fig. 3. Architecture proposed for MDs implementation supported by pattern-based design and X73-compliant 5. Discusión y Tendencias Futuras Algunos puntos permanecen abiertos y activos en el momento de escribir este artículo. En la línea de metodologías de implementación en microcontroladores se están estudiando alternativas al uso de un RTOS que posiblemente reduzcan aún más el uso de recursos de hardware. Estas alternativas incluyen el uso de una máquina virtual en combinación con autómatas de estados finitos. Además, dado que la metodología empleada en este artículo parece adecuada para la automatización se están estudiando algunos algoritmos para generar automáticamente el código fuente del dispositivo a partir de la especificación del estándar definiéndola en un lenguaje procesable (XML, etc.). 6. Conclusiones El objetivo de INTENSA consiste en desarrollar un sistema para el seguimiento de pacientes con insuficiencia cardiaca empleando el estándar X73PHD que sirva para evaluar sus fortalezas y debilidades. Así aparecen algunos retos como son la implementación en microcontroladores, nuevas especializaciones (Simple ECG specialization for HOLTIN), control remoto, integración con otros estándares y Historia Clínica Electrónica (HCE), etc. Todas ellas se están trabajando. En el caso de implementación en microcontroladores, una primera experiencia (tensiómetro) y la metodología propuesta basada en patrones para implementación en dispositivos con capacidades limitadas se presentan en este artículo. Los resultados han sido satisfactorios y nos animan a seguir adelante. Referencias [1] J. L. Monteagudo, O. Moreno, ehealth for Patient Empowerment in Europe,http://ec.europa.eu/information_society/newsroom/cf/itemdet ail.cfm?item_id=3448. Ultimo acceso: 08/09. [2] World Health Organization. Obesity: preventing and managing the global epidemic. Report of a WHO consultation on obesity. Ginebra: World Health Organization, 1998. [3] S. Led, L. Serrano, M. Galarraga, Intelligent Holter: A New Wearable Device for ECG Monitoring Using Bluetooth Technology, 3 rd EMBEC, Prague, IFMBE Proceedings, Volumen 11, 2005. [4] ISO/IEEE11073. Health informatics. Point-of-care medical device communication (x73poc-md) [Part 1. MD Data Language (MDDL)] [Part 2. MD Application Profiles (MDAP)] [Part 3. Transport and Physical Layers]. http://www.ieee1073.org. Primera edición: 2004. [5] ISO/IEEE11073. Health informatics. Personal Health Devices communication (x73phd). [P11073-00103. Technical report - Overview] [P11073-104xx.Device specializations] [P11073-20601.Application profile-optimized exchange protocol]. http://standards.ieee.org/. Primera edición: 2006. [6] M. Martínez-Espronceda, L. Serrano, I. Martínez, J. Escayola, S. Led, J. D. Trigo and J. García, Implementing ISO/IEEE 11073: Proposal of two different strategic approaches, 30 th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, EMBC 2008, Pages 1805-1808. Digital Object Identifier 10.1109/IEMBS.2008.4649529. [7] M. Martínez-Espronceda, I. Martínez, J. Escayola, L. Serrano, J. D. Trigo, S. Led and J. García, Standard-based Digital Homecare Challenge: Advances of ISO/IEEE11073 for u-health, ICMCC Digital Homecare Book. En proceso de publicación. [8] ISO/IEEE11073. Health informatics. Personal Health Devices communication (x73phd). Part 10407. Blood Pressure. 2008 [9] ISO/IEEE11073. Health informatics. Personal Health Devices communication (x73phd). Part 10415. Weighting Scale. 2008 [10] Continua Health Alliance. http://www.continuaalliance.org/. Accedida en Agosto 2009. 712

Integración de datos ISO/IEEE11073 provenientes de Dispositivos Médicos en un Servidor de HCE según el estándar EN13606 P. Muñoz 1, I. Martínez 1, A. Muñoz 3, J. D. Trigo 1, M. Martínez-Espronceda 2, J. García 1 1 I3A, Universidad de Zaragoza, Zaragoza, España, mugnoz.pilar@gmail.com,{imr,jtrigo,jogarmo}@unizar.es 2 Departamento, Universidad de Navarra, Pamplona, España, {miguel.martinezdeespronceda}@unavarra.es 3 Instituto de Salud Carlos III, Madrid, España {adolfo.munoz}@isciii.es Resumen En este artículo se aborda la integración de datos vitales, obtenidos de equipos médicos que implementen la norma ISO/IEEE11073 para interoperabilidad entre dispositivos médicos, sobre un servidor de Historias Clínicas Electrónicas (HCE) que permita su posterior extracción según la norma EN13606, que marca las directrices de interoperabilidad entre sistemas de HCE. El sistema se ha implementado sobre tecnologías que permiten la interacción máquina-a-máquina independientemente de su lenguaje nativo, como Web Services, utilizando plataformas emergentes de desarrollo, como dotnet, lo que constituye una propuesta integrada de solución de e- Salud extremo-a-extremo y basada en estándares. 1. Introducción. La herramienta utilizada por cualquier profesional médico para conocer la evolución de la salud de un paciente es consultar su historia clínica. La historia clínica contiene todos los documentos, escritos ó gráficos, que contienen datos, valoraciones e informaciones sobre la situación y evolución clínica de un paciente y hacen referencia a los episodios de salud y enfermedad de una persona, y a la actividad sanitaria que se genera con motivo de esos episodios. La historia clínica electrónica (HCE) supone incorporar las Tecnologías de la Información y de las Comunicaciones (TIC) en la actividad sanitaria pasando a formar parte de un sistema integrado de información clínica. El problema surge al enviar esa información clínica de un sistema sanitario a otro, conservando la integridad semántica de los datos clínicos, lo que hace necesaria una estandarización en dicho proceso [1]. Actualmente existen varias organizaciones dedicadas a la estandarización como Health Level 7 (HL7) u OpenEHR, pero el Comité Europeo de Estandarización (CEN/TC251) junto con la Asociación Española de Normalización (AENOR/CTN139), grupos con los que colaboramos activamente) [2], son quienes están impulsando los dos estándares principales en este contexto: ISO/IEEE11073 (X73) para interoperabilidad de dispositivos médicos y EN13606 para almacenamiento e intercambio de HCE. X73 [3] se ha consolidado en la actualidad como la vía europea de estandarización que provee interoperabilidad y conexión plug-and-play entre dispositivos médicos asignados a un paciente. Con este estándar el personal sanitario podría conectar y desconectar los equipos médicos sin efectuar actualizaciones de software ni configuraciones manuales. Otro objetivo es normalizar la obtención de datos vitales procedentes de los dispositivos médicos situados tanto en el punto de cuidado (Point-of-Care, PoC) como en el entorno personal del paciente (Personal Health Devices, PHD). Para ello, X73 define una base de datos de nomenclaturas que posibilita el intercambio de datos médicos sin ambigüedades. Así, posibilita a cualquier fabricante la implementación de funcionalidades no contempladas en el estándar, impulsando el progreso de los sistemas informáticos médicos. Hasta la fecha se ha aprobado un subconjunto de las normas, que incluyen la especificación de la pila de protocolos, el procedimiento de comunicaciones, y la nomenclatura de diversos dispositivos médicos. Además desde CEN/TC251 y AEN/CTN139 se trata de adaptar las nuevas tecnologías con nuevos contenidos y propuestas dirigidas a comunicación IP, conectividad wireless, etc. EN13606 [4] está desarrollado para la representación de cualquier información incluida en la HCE de una persona así como para su comunicación entre centros o servicios de salud, consiguiendo la interoperabilidad semántica de la información transmitida. Se basa en un modelo dual: el modelo de arquetipos (que define el conocimiento) y el modelo de referencia (que da soporte a la información). Así, si el conocimiento varía, solo variará el arquetipo bajo el que se esté transmitiendo. El estándar no pretende definir la manera en la que la información relativa a un paciente debe ser almacenada para ser consultada en un centro u hospital, sino que hace referencia a la manera en la que la información debe ser transmitida. En este artículo se propone una solución integrada para generación de extractos conforme a EN13606, provenientes de datos clínicos obtenidos mediante X73. En la Sección 2 se realiza un estudio del problema donde se incluye un análisis de los continuos avances tecnológicos experimentados en los últimos años por el estándar EN13606 y se describen los objetivos específicos del trabajo haciendo mención a ciertos requerimientos y consideraciones previas. El diseño de la solución se presenta en la Sección 3 y la implementación de la solución se detalla en la Sección 4. Las conclusiones globales del trabajo y las líneas futuras se discuten en la Sección 5. 701

La implementación de la solución se divide en dos partes: La lógica de acceso a datos, que contiene los mecanismos de comunicación con la base de datos. El núcleo de funcionamiento, donde a partir de los datos proporcionados por la primera capa es la encargada de construir el extracto a partir de técnicas iterativas. Dentro de esta capa, podemos representar la cadena de acontecimientos lógicos como mostramos en la siguiente figura. El esquema global de la implementación se muestra en la Figura 3. A partir de una petición EN13606 de HCE desde el cliente con una serie de parámetros elegidos, el servidor obtiene dichos parámetros y, en función de ellos, identifica las Compositions que cumplen los requisitos de la petición. Una vez determinadas, y tras completar la cabecera (GenerateHeaderEHR), se añaden dichas Compositions (GenerateComposition) para generar el extracto HCE (GenerateExtract) que será devuelto al cliente. Las funciones que realizan este proceso son: ProcessAdditionalInputParameters. Encargado de procesar los posibles datos de entrada que aumenten / limiten el numero de compositions solicitadas en la petición (EN13606 request). IIFiller. Genera un Instance Identifier (tipo de datos perteneciente al conjunto de datos propuesto por CEN (CEN data types) para el intercambio de Datos Clínicos según la especificación TS14796 [13]). GenerateComposition. Crea una Composition. GenerateEntry. Crea un Entry. GenerateQuantityElement. Crea un elemento, en cuya propiedad value contiene un dato del tipo Physical Quantity (PQ), de CEN data types. GenerateEncapsulatedElement. Crea un elemento, en cuya propiedad value contiene un dato del tipo Encapsulated Data (ED), de CEN data types. GenerateCluster. Crea un Cluster. GenerateElementCluster. Crea un Element perteneciente a un Cluster. GenerateClinicMeaning. Obtiene un Coded Value (CV) que permite realizar una asociación entre los términos que se transmiten con repositorios de terminología clínica (SNOMED-CT, Thesaurus) [14]. GenerateMediaTypeCode. Obtiene un CV que permite determinar el tipo de datos que contiene el dato encapsulado. GenerateCompressionCode. Obtiene un CV que permite saber bajo qué código de compresión están los datos almacenados. GenerateInteriryAlgorithmCode. Obtiene un CV que permite identificar el algoritmo utilizado al generar la firma de dato encapsulado para comprobar la integridad de este en la transmisión. Así mismo, en un plano más semántico, y mediante el uso de un editor, se han desarrollado arquetipos específicos para envío de datos médicos X73, obtenidos remotamente, al centro sanitario que facilitan la interpretación de la información. Dichos arquetipos han sido desarrollados en inglés y español, y presentan enlaces a terminología clínica como puede ser SNOMED-CT (ver Figura 4). Figura 4. Ejemplo de un extracto HCE conforme a EN13606. 5. Conclusiones y líneas futuras Se ha implementado un sistema cliente-servidor con arquitectura WS que permite almacenar datos médicos X73 para su posterior intercambio desde un servidor de HCE conforme a EN13606, lo que garantiza transmisión estandarizada end-to-end, al completar la implementación de E2ESHP. Además, el modelo según el que se generan las entradas del extracto se define mediante arquetipos creados ad-hoc para datos clínicos obtenidos remotamente. Como líneas futuras se plantea avanzar en el diseño de arquetipos (contando para su definición con expertos sanitarios), integrar el sistema con otros ya existentes en el Hospital Universitario Puerta de Hierro y sobre otros entornos de investigación como HL7 y openehr. También se prevén las modificaciones necesarias en la definición de tipo de datos tras la aparición de un nuevo conjunto unificado para salud común a ISO, CEN y HL7. Por último, se plantea la creación de otro WS que permita la consulta de arquetipos como recoge EN13606-5. Agradecimientos Este trabajo ha sido parcialmente subvencionado por los proyectos TIN2008-00933/TSI y TSI2005-07068-C02-01 de la Comisión Interministerial de Ciencia y Tecnología (CICYT) y Fondos Europeos para el Desarrollo Regional (FEDER), una beca FPI a M. Martínez-Espronceda (res. 1342/2006 de la Universidad Pública de Navarra), y una beca a J.D. Trigo (ref. IT7/08) de Diputación General de Aragón (DGA), Consejo Asesor de Investigación y Desarrollo (CONAID) y Caja de Ahorros de la Inmaculada (CAI). Referencias [1] HCE. Historia Clínica. www.seis.es - www.ihe-e.org [07/09]. [2] CEN/TC251.AEN/CTN139. www.cen.eu - www.aenor.es [07/09]. [3] Martinez I. et al. Implementation of an end-to-end standard-based patient monitoring solution. IET Commun 2(2):181-191, 2008. [4] EN13606. Health informatics. Electronic Health Record communication - Parts: 1,2,3,4 y 5. http://isotc.iso.org [07/09]. [5] WS. Web Services. www.w3.org/2002/ws/ [07/09]. [6] XML. extensible Markup Language. www.w3.org/xml/ [07/09]. WDSL. WS Description Language. www.w3.org/tr/wsdl [07/09]. [7] C#. http://msdn.microsoft.com/es-es/vcsharp/default.aspx [07/09]. [8] IIS. Internet Information Server. http://msdn.microsoft.com/eses /library/ms178477(vs.80).aspx [07/09]. [9] JAVA. http://java.sun.com/ [07/09]. [10] Axis2. http://ws.apache.org/axis/ [07/09]. [11] Apache Tomcat. http://tomcat.apache.org [07/09]. [12] JAX-RPC-1. Java API for XML. http://java.sun.com/webservices/ technologies/index.jsp [07/09]. [13] TS14796 Data Types for Use in Health Care Data Interchange. www.cen.eu - http://isotc.iso.org [07/09]. [14] SNOMED-CT. www.ihtsdo.org/snomed-ct/ [07/09]. 704