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

Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
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. Chiarugi2, Á. Alesanco Iglesias1, M. Martínez-Espronceda Cámara3,
L. Serrano Arriezu3, C. E. Chronaki2, J. Escayola Calvo1, I. Martínez Ruiz1 y J. García Moros 1
2
1
Univ. Zaragoza/Instituto de Investigación en Ing. Aragón (I3A), c/ María de Luna, 3. 50018 – Zaragoza
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.
756
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 x73PHD 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.
HOSPITAL
Manager
Agente
x73/
SCP
Network
Adquisidor Adaptador
ECG
x73
Visor ECG
en tiempo real
CE conforme
a x73/SCP
Dispositivo de ECG
conforme a x73/SCP
XML/
SCP
Servidor de
Monitorización y Gestión
Network
HCIS/SCP
Fichero
SCP
ECG
Network
EN13606
Servidor HCE
Visor SCP
Figura 1. Arquitectura general basada en estándares end-to-end
Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
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 x73PHD 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.
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
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.
[2]
5.
[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.
[3]
[4]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
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.
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.
Continua Health Alliance. http://www.continuaalliance.org/
(Consultada: Agosto 2009).
Integrating the Healthcare Enterprise. http://www.ihe.net/
(Consultada: Agosto 2009).
SCP-ECG, Standard Communication Protocol for ComputerAssisted electrocardiography, EN1064:2005+ A1:2007.
OpenECG Project, http://www.openecg.net. (Junio 2009).
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.
ISO/IEEE11073. Health informatics. Personal Health Devices
communication (x73PHD). [P11073-00103. Technical report Overview] [P11073-104xx.Device specializations] [P1107320601.Application
profile-Optimized
exchange
protocol].
http://standards.ieee.org/. Primera edición: 2006.
ISO/IEEE11073-10306 Health informatics. Point-of-care medical
device communication. Device Specialization - ECG.
ISO/IEEE11073-10406 Health informatics. Personal Health
Devices communication. Device Specialization - Basic ECG
ISO/FDIS
11073-91064
Health
informatics.
Standard
communication protocol: Computer-assisted electrocardiography.
Martínez I, Escayola J, Fernández de Bobadilla I, MartínezEspronceda 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
Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
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 Ruiz1, J. D. Trigo Vilaseca1,
P. Muñoz Gargallo1, M. Martínez-Espronceda Cámara2 y J. García Moros 1
2
1
Univ. Zaragoza/Instituto de Investigación en Ing. Aragón (I3A), c/ María de Luna, 3. 50018 – Zaragoza
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.
MDs. En la práctica se tratará de un dispositivo
inalámbrico que llevará consigo el propio usuario que
le indicará al usuario cuándo y cómo debe procederse a
la toma de medidas.
- Management Server (MS). Este servidor se encargará
de gestionar el flujo de información del sistema y el
control de pacientes.
- Servidor de HCE EN13606. Es un contenedor de
información clínica, donde se encuentran las bases de
datos con las HCE de los pacientes. Los datos
provenientes de cada MD son incorporados al HCE del
paciente. Este servidor se comunicará con otros
servidores homólogos siguiendo la norma EN13606.
Agentes
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
Manager
x73
Red
EN13606
Compute Engine
Servidor de Gestión
Servidor de HCE
Figura 1. Esquema de la plataforma de telemonitorización
Para poder llevar a cabo un correcto funcionamiento de
estos servicios es necesario un sistema de supervisión y
gestión de medidas médicas incluyendo los
procedimientos funcionales de uso y toma de decisiones.
Dado que la monitorización de pacientes puede ser
llevada a cabo en diferentes escenarios de aplicación y
para diferentes patologías, los procedimientos serán
distintos según el entorno en el cual nos encontremos.
Por otro lado, los estándares considerados en la
plataforma no tienen en cuenta ciertos parámetros que son
necesarios para una correcta gestión de la
telemonitorización.
Por tanto, es necesario, en primer lugar, un exhaustivo
análisis de los casos de uso, escenarios de aplicación y
dispositivos médicos potencialmente utilizables, en
segundo lugar, el diseño de un modelo de comunicaciones
que basándose en la práctica clínica, permita describir el
comportamiento, los procedimientos y los estados que
atravesará el sistema y, en tercer lugar, incorporar algún
elemento a la plataforma que nos permita contemplar las
particularidades en los procesos de control para diferentes
casos de uso o patologías, que van a regir los
procedimientos a llevar a cabo en la toma de medidas y
decisiones para cada paciente en concreto.
689
Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
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
Manager
x73
datos
x73
Config
Profile
Dispositivos Médicos
Compute Engine
idCE
Otra
info
Red
+
Datos de
paciente
Config
Profile
Servidor de Gestión
Base de
Datos
Datos de
paciente
Servidor de HCE
Figura 3. Papel del Config.Profile en la plataforma
692
MD Table
idMD
MDtype
trademark
model
Measure Table
idMeasure
MeasureType
idMD
MaxFuncThres
MinFuncThres
CE Table
idCE
idUSER
trademark
model
Patient Table
idPAT
name
surname
birthday
sex
Interpers Table
idREL
idCE
idPAT
idDOC
Procedure Table
id
idREL
idMeasure
Date
MaxMedThres
MinMedThres
PATType
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ínezEspronceda 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 Española de Ingenierı́a Biomédica
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. Chiarugi2, Á. Alesanco Iglesias1, M. Martínez-Espronceda Cámara3,
L. Serrano Arriezu3, C. E. Chronaki2, J. Escayola Calvo1, I. Martínez Ruiz1 y J. García Moros 1
2
1
Univ. Zaragoza/Instituto de Investigación en Ing. Aragón (I3A), c/ María de Luna, 3. 50018 – Zaragoza
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 x73PHD 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-andForward [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 SCPECG (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].
[6]
X73-PHD
[7]
SCP-ECG
HL7 aECG
[3]
[4]
[5]
[5]
DICOM
Figura 1. Relación entre diferentes formatos en la literatura
Los estándares SCP-ECG [8] y x73-PHD [9] están
íntimamente relacionados. De hecho, la última versión del
estándar SCP-ECG ha sido aceptada recientemente como
parte de la familia estándares x73 [10]. Varios
dispositivos médicos cuentan ya con un perfil definido en
el estándar x73-PHD, pero todavía no se ha definido un
perfil propio para los dispositivos de ECGs, si bien existe
una línea de trabajo en esa dirección [11]. Resulta patente
que en la definición de ese perfil para ECGs, el estándar
SCP-ECG ha de ser tenido en cuenta.
Sin embargo, el proceso de integración de ambos
estándares se encuentra aún en una fase temprana y, por
tanto, existen todavía varios aspectos que no se han
analizado e investigado adecuadamente en el uso
coordinado de SCP-ECG y x73-PHD, especialmente en
el caso de la transmisión Store-and-Forward de ECGs.
2.
Arquitectura
Como prueba de concepto, se presenta la siguiente
arquitectura de un sistema de e-Salud extremo a extremo
basado en estándares (Fig. 2). En ella, un dispositivo
compatible con x73-PHD y SCP-ECG (llamado Agente)
registra y almacena la señal ECG. Este Agente se
comunica con una entidad también compatible con x73PHD 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 SCPECG. 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 SCPECG podrá ser consultado mediante algún sistema de
información (Healthcare Information System, HIS).
693
Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
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 PMStore se ha organizado de la siguiente manera:
- PM-Store: Contiene todos los ECGs almacenados en el
dispositivo. El atributo Number-Of-Segments especifica
el número de ECGs almacenados.
- PM-Segment: Un ECG. El atributo PM-Seg-Person-Id
identifica al paciente/usuario.
- Entry: Encapsula una derivación (por Entry) en una
estructura RT-SA. Contiene los datos propiamente
dichos, pero también la información relacionada con la
derivación (las especificaciones de la forma de onda).
- Element: Una muestra de una derivación del ECG. Los
primeros Elements en la Entry se corresponden con la
información de la derivación contenida en esa Entry.
Por otro lado, el estándar x73-PHD establece que sólo
entradas completas se han de incluir en un evento
SegmentDataEvent.
Dependiendo
de
diferentes
parámetros (frecuencia de muestreo, tamaño de la muestra
o duración de la señal grabada), la longitud total de una
derivación puede exceder el límite de 63KBytes. Se
pueden considerar varias aproximaciones al problema:
- Dividir las derivaciones en varias Entries/Segments.
Esta aproximación puede ofuscar la organización
jerárquica. Además, se deberían acometer algunas
modificaciones en el estándar x73-PHD para reensamblar las partes del ECG fragmentado.
- Posibilidad de fragmentar las Entries. La idea es
modificar el estándar x73-PHD para que una Entry
pueda ser dividida en SegmentDataEvents que se envíen
secuencialmente. Ésta es la aproximación que se ha
implementado en nuestra plataforma, añadiendo unos
campos que indican el índice del fragmento y el número
total de fragmentos que componen la Entry.
- Limitar el tiempo máximo de ECG. El estándar x73PHD 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.
696
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 SCPECG 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 TIN200800933/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]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
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.
Wootton R, Craig J, Patterson V (Editors). Introduction to telemedicine. 2nd
Ed, pp. 44. Rittenhouse Book Distributors, 2006 (ISBN: 978-1853156779).
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.
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.
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.
Schloegl A, Chiarugi F, Cervesato E, Apostolopoulos E, Chronaki CE. Twoway converter between the HL7 aECG and SCP-ECG data formats using
BioSig. Computers in Cardiology (CinC’07), Durham, 2007, pp. 253-256.
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 SCPECG. Int Conf IEEE Eng in Medicine and Biology Society, 2009.
SCP-ECG, Standard Communication Protocol for Computer-Assisted
electrocardiography, EN1064:2005+ A1:2007.
ISO/IEEE11073, Health informatics, Medical Devices communication
[P11073-20601.Application
profile-Optimized
exchange
protocol].
http://standards.ieee.org/. First edition: 2006.
ISO/FDIS 11073-91064, Health informatics, Standard communication
protocol – Part 91064: Computer-assisted electrocardiography.
ISO/IEEE11073-10406, Health informatics, Personal Health Devices
communication. Device Specialization - Basic ECG (1-3 lead).
Martínez I, Escayola J, Fernández de Bobadilla I, Martínez-Espronceda M,
Serrano L, Trigo JD, Led S, García J. Optimization Proposal of a Standardbased Patient Monitoring Platform for Ubiquitous Environments. Int Conf
IEEE Eng in Medicine and Biology Societ, 2008, pp. 1813-1816.
OpenECG Project, http://www.openecg.net. (Consultada: Agosto 2009).
Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
Interoperabilidad de dispositivos médicos mediante el
estándar ISO/IEEE 11073 sobre tecnología Bluetooth
P. Del Valle García1, J.D. Trigo Vilaseca1, I. Martínez Ruiz1, J. Escayola Calvo1,
M. Martínez-Espronceda Cámara2, L. Serrano Arriezu2, J. García Moros1
1
Univ. Zaragoza/Instituto de Investigación en Ing. Aragón (I3A), c/ María de Luna, 3. 50018 – Zaragoza.
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
2
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
Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
SHOW
DEVICES
INICIO
PROGRAMA
Discover
Devices
CREATE
THREAD
AUDITOR
MANAGER
Get Local
Device
Name
START
Get
Number
Device
RESTART
Comprobación finalizada.
Comprobando...
Open
Server
Connection
Get
Device
Info
(a) BT X73 Manager
(b) Auditor X73
Figura 4. Interfaz gráfico de usuario diseñado
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.
716
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 TIN200800933/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
[2]
[3]
[4]
[5]
[6]
[7]
(X73-PoC).
Personal
Health
Devices
standard
(X73PHD).www.standards.ieee.org/ - www.ieee1073.org. Último acceso: 06/09.
I. Martínez et al., "Implementation of an end-to-end standard-based patient
monitoring solution," IET Commun 2(2):181-191, 2008.
A&D Medical. www.andmedical.com/and_med.nsf/. Último acceso: 06/09.
Nonin Medical. www.nonin.com/. Último acceso: 06/09.
Continua Health Alliance. www.continuaalliance.org/. Último acceso: 06/09.
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.
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.
Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
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
Este artículo presenta una novedosa metodología de
implementación del estándar ISO/IEEE11073 basado en
el paradigma de patrones para uso en plataformas de
monitorización
reales.
Estas
plataformas
de
monitorización incluyen algunos dispositivos médicos
basados en microcontroladores de baja tensión y ultrabajo consumo. Como prueba de concepto, el proyecto
INTENSA cuyo objetivo es desarrollar y evaluar un
sistema interoperable para seguimiento de pacientes con
insuficiencia cardíaca incluyendo báscula, tensiómetro y
dispositivo HOLTIN, es descrito brevemente.
1. Introducción
E
L rápido desarrollo de las Tecnologías de la Información
y de las Comunicaciones (TICs) está impulsando la
transformación de los sistemas de salud tradicionales en
entornos centrados en el paciente. El así llamado
apoderamiento del paciente [1] está cambiando el papel
convencional de pacientes y médicos en una nueva
distribución en donde el paciente toma el control de su salud
y bienestar.
Por otra parte, la monitorización de diferentes constantes
vitales, por ejemplo ECG, peso o presión arterial, es un tema
clave en el seguimiento de algunas enfermedades tales como
insuficiencia cardíaca, enfermedad pulmonar obstructiva
crónica (Chronic Obstructive Pulmonary Disease, COPD),
hipertensión arterial (la cual es uno de los mayores factores
de riesgo para enfermedades del corazón, apoplejías y
también un indicador de pronóstico de fallos renales), o la
obesidad, la cual incrementa la probabilidad de sufrir otras
enfermedades como diabetes, colesterol, hipertensión,
enfermedades en articulaciones, mal función de la vesícula
biliar o complicaciones coronarias y respiratorias entre otras
[2].
Se hace esencial la disponibilidad de dispositivos médicos
(Medial Devices – MDs), también llamados de salud
personal (Pernosal Health Devices), que ayuden a los
pacientes a auto-gestionar el seguimiento de sus
enfermedades. Estos MDs serán de tipo inalámbrico y
llevables de forma que sean lo más útiles y manejables, y
integrarán estándares de comunicaciones para la transmisión
de información biomédica. Como un ejemplo, una
plataforma desarrollada por nuestro grupo es HOLTIN [3] el
cual consiste en un dispositivo llevable e inteligente tipo
holter basado en tecnología inalámbrica Bluetooth que envía,
vía un teléfono móvil, eventos cardíacos a un centro de
salud. Sin embargo en la mayor parte de los casos estos MDs
son cerrados y emplean protocolos propietarios que
imposibilitan o dificultan su extrapolación a otros escenarios.
En este contexto, algunos protocolos han emergido para
cubrir el hueco de interoperabilidad. Uno de los más
ampliamente conocidos es el estándar ISO/IEEE11073
(X73). Inicialmente diseñado para el punto de cuidado del
paciente (Point-of-Care, X73PoC) [4], ha evolucionado
recientemente a dispositivos de salud personal (X73PHD)
[5], para incluir las nuevas tecnologías de transmisión
inalámbrica emergentes (tales como Bluetooth, ZigBee, o
WiFi), y dispositivos llevables de limitadas capacidades. La
topología básica de un sistema de monitorización basado en
X73 comprende tres segmentos: el MD, el dispositivo
pasarela (Compute Engine, CE) y el servidos de
monitorización y gestión (Monitoring System, MS). El MD
(también llamado agente) adquiere la información biomédica
y la envía al CE empleando X73; el CE (también llamado
manager) recoge toda esa información junto con la del resto
de MDs de su red personal (Personal Area Network, PAN) y
la transmite al MS; el MS tiene la tarea de recopilar toda esa
información, realizar diagnósticos (mediante un cribado para
casos triviales y diagnóstico de un especialista para casos
que lo necesiten), enviar alarmas y gestionar la red en línea
de forma global.
Sin embargo X73 tiene algunas debilidades que merece la
pena mencionar y son: la elevada complejidad, el tiempo
necesario para aprenderlo e implementarlo, la integración
con otros estándares, la falta de herramientas de ayuda para
los desarrolladores, o los requerimientos de hardware para
poder ejecutarlo. Estas cuestiones entre otras son el foco de
nuestro trabajo, el cual se está llevando a cabo con la
colaboración del Comité Europeo de Normalización (CEN) y
ha producido sus primeros resultados [6,7] usados como
base para el resto del artículo. El artículo está organizado de
la siguiente forma. La Sección II presenta una explicación
sobre una propuesta de plataforma de salud personal
interoperable basada en X73PHD para seguimiento de
pacientes de insuficiencia cardíaca, mostrando las
principales características y debilidades encontradas. Más
tarde la sección III da un repaso a X73PHD especialmente
planteando los conceptos básicos necesarios para implementar X73 en sistemas basados en microcontroladores, y en
la sección IV se propone una metodología y una arquitectura
que permite la implementación de X73 en sistemas basados
en microcontroladores de recursos limitados. En la sección
V, se presenta una revisión de tendencias futuras.
Finalmente, se muestran las conclusiones en la sección V.
709
Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
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
712
5. Discusión y Tendencias Futuras
Algunos puntos permanecen abiertos y activos en el
momento de escribir este artículo. En la línea de
metodologías de implementación en microcontroladores se
están estudiando alternativas al uso de un RTOS que
posiblemente reduzcan aún más el uso de recursos de
hardware. Estas alternativas incluyen el uso de una máquina
virtual en combinación con autómatas de estados finitos.
Además, dado que la metodología empleada en este artículo
parece adecuada para la automatización se están estudiando
algunos algoritmos para generar automáticamente el código
fuente del dispositivo a partir de la especificación del
estándar definiéndola en un lenguaje procesable (XML, etc.).
6. Conclusiones
El objetivo de INTENSA consiste en desarrollar un
sistema para el seguimiento de pacientes con insuficiencia
cardiaca empleando el estándar X73PHD que sirva para
evaluar sus fortalezas y debilidades. Así aparecen algunos
retos como son la implementación en microcontroladores,
nuevas especializaciones (Simple ECG specialization for
HOLTIN), control remoto, integración con otros estándares
y Historia Clínica Electrónica (HCE), etc. Todas ellas se
están trabajando. En el caso de implementación en
microcontroladores, una primera experiencia (tensiómetro) y
la metodología propuesta basada en patrones para
implementación en dispositivos con capacidades limitadas se
presentan en este artículo. Los resultados han sido
satisfactorios y nos animan a seguir adelante.
Referencias
[1]
J. L. Monteagudo, O. Moreno, “eHealth for Patient Empowerment in
Europe”,http://ec.europa.eu/information_society/newsroom/cf/itemdet
ail.cfm?item_id=3448. Ultimo acceso: 08/09.
[2] World Health Organization. Obesity: preventing and managing the
global epidemic. Report of a WHO consultation on obesity. Ginebra:
World Health Organization, 1998.
[3] S. Led, L. Serrano, M. Galarraga, “Intelligent Holter: A New
Wearable Device for ECG Monitoring Using Bluetooth Technology”,
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]
[P1107320601.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 Española de Ingenierı́a Biomédica
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 eSalud 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
Actas del XXVII Congreso Anual de la Sociedad Española de Ingenierı́a Biomédica
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.
Crea
un
Element
• GenerateElementCluster.
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).
704
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 TIN200800933/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]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
HCE. Historia Clínica. www.seis.es - www.ihe-e.org [07/09].
CEN/TC251.AEN/CTN139. www.cen.eu - www.aenor.es [07/09].
Martinez I. et al. Implementation of an end-to-end standard-based
patient monitoring solution. IET Commun 2(2):181-191, 2008.
EN13606. Health informatics. Electronic Health Record
communication - Parts: 1,2,3,4 y 5. http://isotc.iso.org [07/09].
WS. Web Services. www.w3.org/2002/ws/ [07/09].
XML. eXtensible Markup Language. www.w3.org/XML/ [07/09].
WDSL. WS Description Language. www.w3.org/TR/wsdl [07/09].
C#. http://msdn.microsoft.com/es-es/vcsharp/default.aspx [07/09].
IIS. Internet Information Server. http://msdn.microsoft.com/eses
/library/ms178477(VS.80).aspx [07/09].
JAVA. http://java.sun.com/ [07/09].
Axis2. http://ws.apache.org/axis/ [07/09].
Apache Tomcat. http://tomcat.apache.org [07/09].
JAX-RPC-1. Java API for XML. http://java.sun.com/webservices/
technologies/index.jsp [07/09].
TS14796 Data Types for Use in Health Care Data Interchange.
www.cen.eu - http://isotc.iso.org [07/09].
SNOMED-CT. www.ihtsdo.org/snomed-ct/ [07/09].