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.
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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
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
[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.
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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
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.
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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
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].
[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).
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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.
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. 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).
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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, I. Martínez Ruiz
1, J. Escayola Calvo
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.
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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
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.
INICIO PROGRAMA
Get Local Device Name
Open Server
Connection
Discover Devices
Get Number Device
Get Device
Info
SHOW DEVICES
CREATE THREAD
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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.
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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.
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
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].
Actas del XXVII Congreso Anual de la Sociedad Espanola de Ingenierıa Biomedica
704
Top Related