transmisión de ecgs en tiempo real basada en estándares...

Transmisión de ECGs en tiempo real basada en estándares:

Armonización de ISO/IEEE 11073-PHD y SCP-ECG.

J. D. Trigo Vilaseca1, F. Chiarugi

2, Á. Alesanco Iglesias

1, M. Martínez-Espronceda Cámara

3,

L. Serrano Arriezu3, 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.

Network

Network

EN13606Servidor HCE

Visor SCP

HOSPITAL

Dispositivo de ECG conforme a x73/SCP

Network

CE conforme a x73/SCP

Servidor de Monitorización y Gestión

Visor ECG en tiempo real

x73/

SCP

Fichero SCPECG

XML/

SCP

HCIS/SCP

Agente Manager

Adquisidor ECG

Adaptador x73

Figura 1. Arquitectura general basada en estándares end-to-end

Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica

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 Lalaguna1, I. Martínez Ruiz

1, J. D. Trigo Vilaseca

1,

P. Muñoz Gargallo1, M. Martínez-Espronceda Cámara


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

[email protected], {imr, jtrigo, jogarmo}@unizar.es, [email protected], [email protected]

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.

EN13606

Agentes

x73

Manager

Compute Engine Servidor de Gestión Servidor de HCE

Red

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

Compute Engine Servidor de Gestión Servidor de HCE

Red

datos

x73

Datos de

paciente

Base de

Datos

Datos de

paciente

Config

Profile

Otra

info

+

idCE

Config

Profile

Figura 3. Papel del Config.Profile en la plataforma

MD Table Measure Table

idMD idMeasure

MDtype MeasureType

trademark idMD

model MaxFuncThres

MinFuncThres Procedure Table

CE Table id

idCE idREL

idUSER idMeasure

trademark Date

model 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


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 Vilaseca1, F. Chiarugi

2, Á. Alesanco Iglesias

1, M. Martínez-Espronceda Cámara

3,

L. Serrano Arriezu3, C. E. Chronaki




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].

[7]

[6]

[4]

[5]

X73-PHD

HL7 aECG

[5]

[3] DICOMSCP-ECG

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 re-

ensamblar 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.


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. Two-

way 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 Standard-

based 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ía1, J.D. Trigo Vilaseca



1,

M. Martínez-Espronceda Cámara2, 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 [email protected], {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

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.

AUDITOR

MANAGER

START

RESTART

Comprobación finalizada.

Comprobando...

(a) BT X73 Manager (b) Auditor X73

Figura 4. Interfaz gráfico de usuario diseñado


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.

INICIO PROGRAMA

Get Local Device Name

Open Server

Connection

Discover Devices

Get Number Device

Get Device

Info

SHOW DEVICES

CREATE THREAD


716

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 ultra-bajo 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

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 imple-mentar 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.

INTENSA: Sistema de monitorización de pacientes con insuficiencia cardíaca basado en el estándar ISO/IEEE11073

M. Martínez-Espronceda1, I. Martínez2, S. Led1, J. D. Trigo2, I. Osés1, J. Escayola2, L. Serrano1, J. García2, y A. García3

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

E


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/itemdetail.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”, 3rd 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”, 30th 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ñoz1, I. Martínez1, A. Muñoz3, J. D. Trigo1, M. Martínez-Espronceda2, J. García1 1 I3A, Universidad de Zaragoza, Zaragoza, España, [email protected],{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

transmisión de ecgs en tiempo real basada en estándares...

Documents