rss

Artictles

Hi, thanks for visiting this page. Here I write about technology, in-depth analysis of some problems, sport management, among others. If you like these things, you will be glad to read the articles. Also, you can comment or ask questions whenever you want. I will try to respond as soon as possible...

Diseño de un sistema de monitoreo en unidad de cuidados intensivos Bookmark

En este articulo se describe el diseño e implementación de un Sistema de Telemonitoreo en una Intranet conectado a Internet totalmente comunicante. En este proyecto se consideró el monitoreo de señales electrocardiográficas (ECG) dentro de un ambiente clínico como podría ser una Unidad de Cuidados Intensivos (UCI), un consultorio cardiológico, un cuarto en una sala de cuidados generales y una sala de emergencia. Se detalla el diseño de los módulos de adquisición de datos fisiológicos (MAD) y la aplicación de monitoreo para la visualización, almacenamiento, transmisión y manejo de las señales de ECG.

Sistemas Telemédicos de Señales Biomédicas vía Internet

De las diferentes señales fisiológicas posibles dentro de una UCI, se escogió el electrocardiograma (ECG) de 12 derivaciones (8 canales continuos de 100 Hz de ancho de banda) por ser representativo de las prestaciones necesarias para cubrir el caso real de un sistema multiseñal típico. Los MAD se conectan a la Intranet (Ethernet) a través de módulos de Internet Embebido y transmiten los datos hasta aplicaciones cliente /servidor corriendo en PC, que configuran estaciones de monitoreo locales (cerca del paciente) y centrales (para monitorear varios pacientes a la vez). Las aplicaciones poseen una interfaz de usuario que permite interactuar con el MAD de manera de poder determinar variables como la frecuencia de muestreo, ganancia y canales a adquirir. La visualización de los ECG se realiza cumpliendo con los estándares médicos, adaptados a la pantalla de las PC Además, se da la opción de crear, editar y almacenar datos clínicos de pacientes y sus respectivos registros de ECG, para cumplir su función como instrumento clínico versátil.

Descripción del Sistema

En la siguiente figura se tiene un esquema de los diferentes componentes de software, firmware y hardware válidos para las dos versiones que se implementaron: versión para el Internet Embebido emWare y la versión para el Internet embebido de Sena Technologies.

Para el primer caso, emWare, tenemos un módulo de adquisición de datos (MAD) conectado a través de RS232 con una PC configurada como Gateway que habilita el MAD a una red intranet. Para el segundo caso, Sena Technologies, el MAD es habilitado a una intranet a través de un módulo Internet Embebido conectado a través de una DPRAM. Luego tenemos las estaciones local, central y remota; todas implementadas sobre la arquitectura PC.

Los objetivos del proyecto para ambos casos, consisten en desarrollar el hardware para el MAD, el firmware para el mismo, la configuración del firmware del módulo de Internet Embebido y el desarrollo de la aplicación cliente/servidor para la interfaz hombre-máquina de la aplicación telemédica, en nuestro caso el ECG de 12 derivaciones que como se dijo en la introducción, es representativa para evaluar el sistema.

Esquema de los componentes del sistema

Versión con Internet Embebido de emWare (EMIT)

Esta versión comprende el desarrollo de una aplicación capaz de mostrar una señal analógica en un PC remoto a la adquisición de la señal. Es decir, la señal se adquiere desde un MAD basado en el microcontrolador MC68HC908GP32  de Motorola (HC08) que se comunica vía RS232 con una PC que funciona como Gateway y que envía los datos por una red, ya sea Intranet o Internet, hacia una PC remota en donde se visualiza la señal con ayuda de un navegador como el Internet Explorer de Microsoft. También se tiene la posibilidad de variar la frecuencia de muestreo con que se digitaliza la señal en cuestión, junto con la posibilidad de elegir entre ocho señales con una interfaz gráfica amigable. En la siguiente figura se ilustra el funcionamiento del sistema de adquisición implementado.

Esquema de los componentes del sistema con la tecnología de emWare

En primer lugar, el usuario desde el navegador se conecta con emGateway. El navegador envía un localizador de recurso universal (URL) al emGateway, conteniendo información que especifica el Gateway, puerto, dispositivo y documentos de información. En nuestra aplicación, se requiere el archivo tesis.html que se encuentra en emGateway y corresponde al dispositivo, el cual está conectado a una puerto serial RS-232 llamado “portname” de un host llamado “myhost”. Entonces, el URL apropiado es: http:/myhost/portname/tesis.html.

Una vez realizada la conexión, las variables, funciones, eventos y documentos del dispositivo son accedidos y mostrados en el navegador usando los emObjects. Las interacciones del usuario con los emObjets son enviadas al emGateway, y este al emMicro. Los cambios en el dispositivo embebido, es decir, la adquisición y el almacenamiento de los datos, son refrescados en la pantalla.

Al iniciarse el proceso de conexión, los objetos en Java automáticamente llaman a una función de aplicación que está conectada con emMicro. Esta función inicializa el timer del microcontrolador HC08, a la misma frecuencia de adquisición. En la rutina de interrupción del timer se procede a digitalizar el canal previamente configurado a través de unas variables en emMicro como se mencionará mas adelante.

La rutina de interrupción del timer es generalmente muy sencilla. Primero digitaliza la señal con la ayuda del conversor analógico/digital del microcontrolador HC08, luego procede a guardarla en uno de dos buffers de tamaño fijo. La longitud de estos últimos depende del tamaño de memoria del HC08 y de la memoria ocupada por emMicro. Una vez llenado el primer buffer, la aplicación le indica a emMicro por medio de un evento que envíe el buffer al cliente en el navegador. Por otro lado, en el navegador existe un hilo en ejecución (EMITJRI) que se encarga de reconocer los eventos generados desde emMicro, transmitiendo junto con ellos los buffers de adquisición.

Luego que el temporizador está configurado, la página en el navegador se queda visualizando indefinidamente hasta que el usuario cierra el navegador. En este punto, los objetos en Java, automáticamente llaman a una función en el emMicro, que se encarga de detener el temporizador del microcontrolador para así detener la adquisición.

Versión con Internet Embebido de Sena Technologies

El sistema propuesto está formado por tres componentes principales: eMAD (el cual incluye MAD, y el módulo de Internet Embebido), eMonitor (estación local), eMonitorStation (estación central) y eMonitorRemote (estación remota). La siguiente figura presenta como ejemplo el caso de una Unidad de Cuidados Intensivos.

Sistema Telemédico para una Unidad de Cuidados Intensivos

Como se observa en la figura anterior, el eMonitor correspondería al servidor de lo que comúnmente se denomina la red intracama. El eMonitorStation vendría siendo el servidor de la red intercama. Estas redes han sido objeto de una norma conocida como la IEEE P1073, la diferencia en este caso es que todo el manejo de información se hace bajo el esquema de cliente/servidor, lo cual facilita el diseño de interfaces hombre-máquina, aparte que los dispositivos son accesibles para transferencia de datos y para configurarlos desde lugares remotos.

En otras palabras, la información en tiempo real de un paciente en una cama de cuidados coronarios de un hospital podría ser accesada desde cualquier lugar remoto por el médico tratante. No sólo eso, las consultas interhospitalarias para la búsqueda de opinión experta serían sumamente sencillas ya que usando la aplicación eMonitorRemote, los especialistas dispondrían de las señales al instante. El concepto es expandible a otros signos vitales, y a diversos ambientes como salas de emergencia, quirófanos, salas de recuperación, y de allí fuera del ámbito hospitalario.

Inicialmente la señal proveniente del paciente es acondicionada y digitalizada por el módulo de adquisición de datos (MAD). El dispositivo de adquisición cuenta con una etapa de cabecera en la cual se modifica la señal en diferentes aspectos como el ancho de banda, niveles de voltaje y ganancia. Esto se logra con una etapa de amplificación diferencial y filtrado que preparan la señal de manera de poder digitalizarla correctamente. La etapa de digitalización cuenta con hasta dos multiplexores manejados por el microcontrolador (en nuestro caso uno es suficiente), a través del cual se toma secuencialmente muestras de los canales, que equivalen a las derivaciones, y se amplifican para luego digitalizarse a través de un conversor analógico-digital. El microcontrolador se encarga entonces de transmitir los datos adquiridos hacia una DPRAM que se encuentra en el módulo Internet Embebido.

En este módulo, el microcontrolador al otro lado de la DPRAM se encarga entonces de enviar los datos hacia el cliente o estación local eMonitor donde luego se graficará el ECG de 12 derivaciones. La aplicación eMonitor también puede almacenar las señales que componen al ECG en archivos en disco, igualmente perrmite al usuario configurar parámetros de adquisición tales como los canales a adquirir, la frecuencia de muestreo, la ganancia por software y por hardware entre otros.

También se puede acceder al eMAD desde la estación central, eMonitorStation, la cual funciona exactamente como eMonitor, excepto que acepta múltiples pacientes.

Por otra parte, si el doctor se encuentra fuera de la unidad de cuidados intensivos podrá acceder al paciente por medio de la estación remota eMonitorRemote la cual se comunica directamente con la estación central (eMonitorStation) la cual cuenta con opciones como, obtener archivos de ECG de diferentes pacientes y visualizar, en tiempo real o fuera de línea, el ECG de algún paciente, entre otras.

eMAD

El eMAD esta compuesto por el módulo de adquisición de datos (MAD) junto con el módulo Internet Embebido (HD1200). La siguiente figura muestra los componentes en conjunto.

eMAD: módulo de adquisición de datos MAD con Internet Embebido

 

 

MAD

Este módulo lo integran la cabecera y la arquitectura digital.

Cabecera

Esta comprende dos partes mostradas las figuras siguientes. La primera parte corresponde al caso ECG de 12 derivaciones, en donde, los 9 electrodos de entrada se convierten en 8 canales diferenciales independientes. Los circuitos de esta parte (OP484 de Analog Devices) manejan la malla (guard) de los cables de los electrodos y generan el terminal de referencia de Wilson. Luego cada canal diferencial pasa por una etapa igual a la segunda parte, la cual es dividida por bloques.

Diagrama en bloques de la cabecera: Parte especifica para ECG de 12 derivaciones

Diagrama en bloques de la cabecera: canales diferenciales

El primer bloque de la  muestra la etapa de entrada, compuesta por un amplificador de instrumentación (INA) de dos operacionales integrado. El utilizado fue el AD627 de Analog Devices, el cual provee una salida aproximadamente hasta los rieles de alimentación (rail-to-rail) y tiene un esquema de bajo consumo, lo cual, pese a su CMRR no tan alto hacen que sea una buena opción para el proyecto. A continuación se muestra el AD627 internamente.

Amplificador de instrumentación (INA) de dos operacionales, AD627

Para este caso, la ganancia del INA es:

Ganancia del INA

Si RG=1.05 KW, AV1O= 195.48 @ 200. Esto permite aproximadamente 50 mVDC de señal diferencial sin saturar el INA que está alimentado con ±5V.

Esta expresión es muy semejante en estructura a la del INA de tres operacionales y se puede demostrar que para el caso de que RG se sustituya por ZG , tenemos:

Función de transferencia

Función de transferencia de los filtros pasa alto

También junto con el INA tenemos un integrador (1/4 OP496 de Analog Devices), que va de la salida al terminal (pin) REF del INA. Se puede demostrar que el efecto de esta realimentación es un filtro pasa alto con la siguiente función de transferencia:

Función de transferencia

En nuestro caso se utiliza el segundo pasa alto solamente para acoplar AC el INA. Para el caso de ECG de diagnóstico (fc=0.05 Hz), R7 = 634KW y C7 = 10mF.

Luego del amplificador de instrumentación tenemos una segunda etapa de ganancia conformada por un amplificador no inversor con ganancia 10, que junto con la ganancia del amplificador de instrumentación tenemos un total de 2.000 de ganancia.

Después que la señal ha sido amplificada, es llevada a niveles entre 0 y 4,096 V con un conversor bipolar a unipolar conformado por dos resistencias y un voltaje 2VREF, igual a 4,096 V, que se obtiene con un amplificador no inversor con ganancia 2 junto con un voltaje de referencia VREF igual a 2.048 V que proviene de la arquitectura digital. El operacional que se utiliza es el AD8571 de Analog Devices, rail to rail, bajo error DC (zero-drift) y bajo consumo. Con la señal entre 0 y 4.096 V, la ganancia ahora es 1.000, y a continuación sigue un filtro pasa bajo Bessel de 5to orden, el MAX7409 [38] de Maxim, el cual es de capacitor conmutado, cuya frecuencia de corte depende de un condensador externo Cosc y se calcula como sigue:

Frecuencia de corte

Para señales de ECG de diagnóstico se requiere una frecuencia de corte de 100 Hz, por lo que Cosc resulta ser de 3nF aproximadamente. Luego se coloca un seguidor de tensión (buffer) a la salida del filtro para manejar el A/D del sistema de adquisición. Este buffer debe tener suficiente manejo de corriente y velocidad (slew rate) para soportar la conmutación producida en la entrada del módulo de adquisición por los multiplexores analógicos y por el propio A/D. El operacional utilizado es el MAX4254 de Maxim.

Arquitectura digital

Esta etapa consiste en una arquitectura típica de adquisición usando multiplexer, ganancia, conversor analógico/digital de aproximaciones sucesivas, aislamiento digital y control.

Arquitectura digital

Las ocho señales, luego de ser acondicionadas por la cabecera (fron-tend) pasan por un multiplexor analógico (ADG738 de Analog Devices) que selecciona una de las señales para luego pasar por un amplificador no inversor de ganancia variable, la cual se lleva a cabo, por medio de un segundo multiplexor analógico que cambia la resistencia de realimentación del amplificador. Después de la selección y amplificación de la señal, esta es enviada hacia un conversor analógico/digital ADS7818 de Burr-Brow, de 12 bits de resolución y bajo consumo. Hay que destacar que tanto los multiplexores como el ADC son controlados con un bus SPI, teniendo un total de 5 señales junto con todos los componentes anteriores (las señales son de color azul). En este diseño no se implementó la ganancia variable.

Ahora bien, antes de pasar las señales al microcontrolador, estas son aisladas con cinco aisladores digitales ADuM1100A de Analog Devices, diseñados con tecnología micromachine isolationTM. Soportan hasta 100Mbps y su consumo es proporcional a la velocidad de conmutación digital. Por ejemplo, en operación a 5V consume 6mA @ 25Mbps.

En cuanto al aislamiento de la alimentación, se empleo un DC/DC, DCP010505 de Burr-Brown, cuya barrera de aislamiento llega a los 1000Vrms @ 1W. Este último, posee una salida no regulada de 5V, por lo cual se emplea un regulador integrado de voltaje de bajo consumo y baja diferencia de voltaje entrada /salida (low dropout) como el MAX8868 de Maxim. Para la alimentación negativa, se usó un inversor de voltaje de bajo consumo y con salida regulada de -5V, MAX829 de Maxim. En cuanto al voltaje de referencia del ADC y de la cabecera, se usó una referencia de voltaje integrada, MAX6021 de Maxim, de bajo consumo y low dropout para obtener VREF=2.048 V y con un seguidor (AD8571) se garantiza manejar adecuadamente VREF. Este regulador, como este inversor de voltaje y la referencia son los encargados de alimentar y dar un voltaje de referencia a los componentes de la arquitectura digital y de la cabecera que se encuentran en la parte aislada.

Luego que las cinco señales de control son pasadas por una etapa de aislamiento estas son enviadas a un microcontrolador SX48BD de Ubicom, cuyos rasgos principales son: arquitectura RISC, velocidad de reloj hasta 100 MHz, 4096 palabras de memoria de programa EE/Flash, 262x8 bits SRAM para variables, cuatro puertos de 8 bits y un puerto de 4 bits, I/O configurables, entre otros. También posee un pipeline de 4 instrucciones, con lo cual podemos tener hasta una instrucción por cada ciclo de reloj y un salto en tres ciclos. En la figura 3.10 se muestra la arquitectura del microcontrolador.

Arquitectura del SX48BD

Finalmente se usa un regulador de low droput para alimentar la parte no-aislada (MAX8860 [38] de Maxim).

HD1200

Después que el microcontrolador anterior adquiere las señales, estas son enviadas al dispositivo Internet Embebido (HD1200). La comunicación con el HD1200 es realizada a través de una Dual Port Static RAM CY7C136-55  de Cypress Semiconductor Corporation, de 2 Kbytes, de bajo consumo (90 mA máx), acceso rápido (55 ns) y que se encuentra en la tarjeta del HD1200. En el microcontrolador del MAD, se implemento un bus de datos de 8 bits y un bus de direcciones de 11 bits (con lo cual llegamos a direccionar 2Kbytes) para comunicarse con la DPRAM. También se incluyeron unos bits de control como, CE (chip enable), R/W (read/write) para escribir o leer del DPRAM, OE (output enable) para habilitar la salida del bus de datos del DPRAM como salida, BUSY para indicarnos una operación correcta o incorrecta, cuando coloquemos una dirección en el bus de direcciones cuyo dato no esté disponible para la operación que previamente hayamos configurado por medio del pin R/W, ya sea para escribir o para leer, y la señal IRQ para indicarnos que ha habido un cambio en los datos de la DPRAM. Para saber cuál espacio de memoria fue modificado, se leen dos registros de la DPRAM, de dirección y longitud respectivamente. Tanto la memoria como estos últimos registros, son modificados por el HD1200.

De igual forma como el microcontrolador SX48BD del MAD se comunica con la DPRAM, existe un microcontrolador SX52BD de Ubicom en el HD1200, que se comunica a través de un bus de datos, un bus de direcciones, y las señales de control discutidas anteriormente; CE, OE, R/W, BUSY e IRQ. En este microcontrolador reside el stack TCP/IP, el cual se comunica con el controlador de Ethernet RTL8019 de Realtek Semi-Conductor Co. Este posee 16Kbytes de SRAM y es PNP (plug and play), entre otras caracteríisticas. Antes de conectarse a una Intranet las señales provenientes del controlador de Ethernet, TPOUT+/- y TPIN+/-, son aisladas con el 20F001N de YCL diseñado para IEEE802.3, con 1500 Vrms de aislamiento. También se dispone de tres señales para alimentar tres leds que indican el estatus del controlador de red. Estos leds son colocados en modo ánodo común fuera del HD1200 e indican los paquetes de capa física recibidos (RX), enviados (TX), y por último un led para indicar que hubo una colisión en el medio (COL).

Intenet Embebido HD1200 de Sena Technologies

Firmware del eMAD

En el eMAD existen dos microcontroladores, uno que tiene el stack TCP/IP (HD1200) y otro que contiene el firmware necesario para adquirir las señales y comunicarse con el HD1200 para enviar estas señales adquiridas a la estación local o central, eMonitor o eMonitorStation respectivamente.

Cuando eMonitor o eMonitorStation desean adquirir el ECG de cualquier paciente, se conectan con el eMAD respectivo del paciente a través de una dirección IP como se mencionará más adelante. Luego que la conexión ha tenido éxito eMonitor procede a configurar el eMAD escribiendo en la DPRAM a través de los comandos descritos en el marco teórico. Esta primera escritura en la DPRAM saca al SX48BD del estado dormido (sleep), y lee la configuración del DPRAM para empezar la adquisición. Se procede a programar el temporizador a una frecuencia fmáximo, la cual es fija e igual a 1KHz. Para muestrear a diferentes frecuencias se basó en trabajos de tesis anteriores en donde se usó una tabla de configuración. Esta tabla, que esta compuesta de 16 filas y 16 columnas de un bit, nos indica en la rutina del temporizador del microcontrolador del MAD (SX48BD) cuando debemos convertir un canal y que canal se debe muestrear, entre 16 canales posibles. De esta forma podemos tener frecuencias distintas de muestreo, en diferentes canales si así lo deseamos.

Tabla de conversión

La tabla de conversión consiste en un arreglo de 32 bytes que nos indican cuando debemos muestrear un canal y que canales debemos muestrear. Cuando sucede una rutina de interrupción del timer, lo primero que se hace es leer una fila de la tabla. Esta fila nos indica que canales debemos convertir en ese momento, dependiendo de si el bit esta en “1” (convertir) o en “0” (no realizar la conversión). Como la fila es de 16 bits, el bit #16 (MSB) nos indica el canal 16, el bit # 15 el canal 15 y así sucesivamente hasta llegar al bit #1 el cual nos indica el canal #1. Una vez que recorrimos la fila en cuestión pasamos a la próxima fila de la tabla, la cual se leerá en la próxima rutina de interrupción del temporizador. A continuación se presenta un diagrama explicando la tabla de conversión.

Ejemplo de los posibles valores que puede contener la tabla de conversión

Luego que se recorren las 16 filas, se verifica si hay una interrupción pendiente del HD1200, ya sea para parar la conversión o configurar la tabla de conversión. Esto último dependerá de unas localidades de memoria especifica de la DPRAM en donde, eMonitor guarda todos los parámetros para la configuración.

Uso óptimo de la DPRAM

El stack TCP/IP del HD1200 tiene limitaciones de memoria, debido a esto, la ventana TCP del mismo es de apenas 256 bytes. Esto último trae como consecuencia que el HD1200 no pueda enviar dos paquetes TCP/IP consecutivos sin recibir antes el reconocimiento (ACK) correspondiente al paquete previo. Esto limita la velocidad de transmisión (performace) ya que hay que esperar después de enviar un buffer de datos, que recibamos su respectivo ACK.

En cuanto a la distribución de la memoria disponible para la adquisición en la DPRAM (sin incluir la memoria del SX48BD, que es de 262 bytes), se implementó una estructura multibuffers para mejorar la transmisión debido a las limitaciones del stack TCP/IP del HD1200. También se reservó un bloque de memoria exclusivo para la configuración del MAD. La distribución de la DPRAM se muestra a continuación.

Distribución de la DPRAM

En el bloque de la configuración se guarda la tabla de conversión de los canales, la tabla de ganancia por hardware de cada canal (no implementada), el número de buffers del multibuffers, el número de líneas de la tabla de conversión por cada buffer. Esto último, es equivalente al número de muestras por buffer. Otro parámetro importante que se encuentra en el bloque de configuración, es el tiempo en el cual deseamos que el microcontrolador entre en estado dormido (sleep) en caso de no recibir ningún ACK desde el eMonitor.

Por ejemplo, podemos tener una tabla de conversión que nos indique 8 canales a 500 Hz. Si configuramos el multibuffers con N igual a 6 buffers de 20 líneas de la tabla de conversión cada uno, es equivalente a 20 muestras de 8 canales a 2 bytes cada muestra, dando un total de 320 bytes por buffer. Sí tenemos 6 buffers de 320 bytes cada uno, nos da un total de 1920 bytes, cubriendo toda la DPRAM disponible para el multibuffers. También podríamos configurar que los 6 buffers fueran de 160 bytes cada uno, por ejemplo, ocupando así, la mitad de la capacidad del multibuffers en la DPRAM (situación que no se debería implementar ya que no haríamos un uso óptimo de la DPRAM).

En la siguiente figura, se muestra el ejemplo anterior en un ambiente de poco tráfico en la Intranet. En el firmware del MAD se tienen dos hilos corriendo. Estos hilos proceden a ejecutarse cada milisegundo. Este tiempo corresponde al periodo de la frecuencia máxima de la tabla de conversión (1KHz). La suma del tiempo de duración de ambos hilos debe ser menor a un milisegundo. El hilo de mayor prioridad, o el que se ejecuta primero, es el de adquisición, el cual se encarga de llenar los buffers del multibuffers e indicar en las variables que describen la ventana (ó estado) del multibuffers, el buffer que se ha llenado, sin importar los buffers previamente llenados. Este hilo se basa en la tabla de conversión para adquirir las muestras de los canales, y escribirlas en la DPRAM, indicando a su vez en la ventana del multibuffers, los buffers que se han llenado y están listos para ser enviados.

Ejemplo del funcionamiento del firmware del MAD (tráfico de red favorable)

Ahora bien, el segundo hilo en ejecutarse es el que se encarga de chequear cuando puede enviar otra trama (frame) hacia la Intranet y enviar los buffers disponibles a eMonitor. Cuando se llena el primer buffer, este hilo chequea sí se puede enviar una trama hacia eMonitor, chequeando el registro de control de la DPRAM (INTR_R), el cual al ser igual a 0x00, nos indica que podemos enviar una trama, y que la trama previamente enviada ya llegó a su destino, ya que su respectivo ACK ya arribó al HD1200.

En el ejemplo anterior consideramos que el tráfico era favorable en la red Ethernet para la adquisición. Ahora bien, si consideramos que hay mucho tráfico, o uno desfavorable para la adquisición, debemos tomar en cuenta cuando la ventana del multibuffers se llene, es decir, que estén, por ejemplo, los 6 buffers llenos y que no se haya recibido aún el ACK del buffer número 1. El hilo de chequeo y envío, siempre esta verificando el estado de la ventana del multibuffers, de modo que cuando ratifique que se ha llenado la ventana, o que hay cantidad (definida en la configuración) de buffers llenos que no han sido recibidos por eMonitor (en el ejemplo, el número máximo de buffers es de 3, el hilo automáticamente desecha el primer buffers que estaba esperando por ser enviado, para así llegar a tener un número de buffers activos (o llenos) en la ventana menor al definido en la configuración. En la figura siguiente se muestra el ejemplo anterior. Podemos observar de la figura, como el buffer 4 se desecha ya que el número máximo de buffers llenos en la ventana es de 2, el hilo de chequeo y envío automáticamente lo desecha para poder reducir el número de buffers activos en la ventana.

Ejemplo del funcionamiento del firmware del MAD (tráfico de red desfavorable)

eMonitor

eMonitor es el nombre que lleva la estación local (PC) de visualización y almacenamiento de las señales electrocardiográficas de un paciente en la UCI. La armazón de nuestra aplicación está compuesta por las siguientes clases principales (heredadas de las clases correspondientes de MFC):

  • CeMonitorApp
  • CeMonitorDoc
  • CMainFrame
  • CeMonitorChannelsScrollView

Se diseñaron clases para la comunicación con eMAD vía Internet y para la comunicación serial RS232 con un MAD compatible. También se diseñaron todas las clases necesarias para los cuadros de diálogos de Windows, para la configuración del eMAD y de la aplicación en sí, entre otras. Algunas de estas clases se mencionan a continuación:

  • CDualPortRAM
  • CSerialPort
  • CCardSetup
  • CUtilitySetup

Vale la pena destacar que el código fuente esta escrito en el idioma inglés, ya que todas los nombres y comentarios de las clases de MFC están escritas en ese idioma. Las clases implementadas en este proyecto también fueron escritas en el idioma inglés, para llevar un buen aspecto con las clases de la MFC, y que sean de fácil entendimiento.

eMonitor, una aplicación multihilo en Windows

La aplicación, además de centrarse en el uso de la armazón de la MFC, se basa en una aplicación multihilo, en donde en el mismo proceso (aplicación) tenemos diferentes hilos desempeñando funciones diferentes y bien definidas. Estos hilos, usan objetos de exclusión mutua para compartir recursos y comunicarse entre ellos.

La aplicación posee cinco hilos fundamentales sin los cuales no pudiera realizarse ninguna tarea útil. Dichos hilos son funciones globales que corren sincronizadamente mediante objetos de exclusión mutua y que son iniciadas desde comandos desde el menú de opciones o de la barra de herramientas de la aplicación. Estas funciones se mencionan a continuación:

  • UINT ThreadFuncConnect(LPVOID pParam)
  • UINT ThreadFuncAcquisition(LPVOID pParam)
  • UINT ThreadFuncAcquisitionSave(LPVOID pParam)
  • UINT ThreadFuncAcquisitionOpen(LPVOID pParam)
  • UINT ThreadFuncChannelsView(LPVOID pParam)

Al iniciar cualquiera de los hilos o funciones anteriores, se les da como parámetro el apuntador de una estructura de datos definida y cargada previamente, para que la función tenga conocimiento de la tarea que debe realizar.

En primer lugar, tenemos a la función encargada de establecer la comunicación con el eMAD: ThreadFuncConnect. Se implementó el establecimiento de la conexión en un hilo, para hacer más flexible la interfaz hacia el usuario. De forma tal este usuario pudiera cancelar una posible conexión y no esperar un fin de espera (timeout) para que la aplicación avise que no se pudo establecer la conexión. Cuando el usuario desea establecer la comunicación con el eMAD, presiona un botón en la barra de herramientas o se dirige al menú de opciones eMAD - Conectar, y automáticamente se inicia el hilo de conexión, y a su vez se presenta un cuadro de diálogo con una animación y una barra de progreso en donde indica el estado de la conexión, pudiendo cancelarla antes del establecimiento. También se posee un timeout en caso de una conexión fallida.

Una vez que se realiza la conexión el usuario puede elegir entre tres opciones de visualización. Estas opciones se presentan a continuación:

  • Adquirir del eMAD y visualizar en tiempo real.
  • Adquirir del eMAD, visualizar en tiempo real y guardar en un archivo en disco los datos adquiridos.
  • Visualizar los datos desde un archivo. Estos datos fueron adquiridos previamente con la opción anterior.

Para seleccionar una de estas tres opciones el usuario puede presionar un botón en la barra de herramientas o en el menú de opciones. Cada una de estas opciones corresponde con la activación o inicio de los siguientes hilos o funciones:

  • ThreadFuncAcquisition: se inicia para adquirir las señales del eMAD y visualizarlas sin guardar.
  • ThreadFuncAcquisitionSave: se inicia para adquirir las señales del eMAD, visualizarlas y guardarlas en un archivo en disco especificado por el usuario previamente a inicio de la adquisición.
  • ThreadFuncAcquisitionOpen: se inicia para adquirir las señales desde un archivo en disco seleccionado por el usuario, para luego visualizarlas.

Ahora bien, las tres funciones o hilos mencionados anteriormente, poseen muchas cosas en común, pero la más importante es la comunicación e intercambio de datos con el hilo que se encarga de la visualización: ThreadFuncChannelsView.

La función o hilo ThreadFuncChannelsView se encarga de graficar la señal de ECG en la pantalla de la aplicación. La comunicación de este hilo con los hilos de adquisición, ya sea desde archivo o desde el eMAD (guardando o no en disco) se realiza de la misma manera, o sea a través de arreglos de memoria que pueden acceder todos los hilos. Ahora bien, al igual que en el firmware del MAD, aquí se aplicó el concepto de doble buffer para compartir la información entre los hilos.

Supongamos que estamos adquiriendo las señales sin guardar en disco. En este caso, los hilos ThreadFuncAcquisition y ThreadFuncChannelsView estarían corriendo. El flujo de información entre ambos hilos se explica en los siguientes pasos:

  • El hilo de adquisición configura al eMAD dependiendo de la configuración realizada previamente por el usuario (frecuencia de muestreo, canales a muestrear, entre otros).
  • Según el paso anterior, el hilo de adquisición crea dos buffers dinámicos en memoria cuyos tamaños dependen de la configuración, (básicamente de la frecuencia de muestreo y del número de buffers del multibuffers en el eMAD).
  • Creado los arreglos, el hilo de visualización espera el llenado de los buffers.
  • Cuando se llena el primer buffer, el hilo de adquisición le indica al hilo de visualización que el buffer en cuestión esta listo, mediante objetos de exclusión mutua de Windows como Event y CriticalSection, los cuales son los objetos exclusión mutua más rápidos y efectivos para compartir recursos en una aplicación en Windows en el mismo proceso (o aplicación). Es decir, los recursos no se compartirán con otras aplicaciones, sino en la misma aplicación eMonitor.
  • Una vez que el hilo de visualización está usando el primer buffer de los datos de la adquisición, el hilo de adquisición se encuentra llenando el segundo buffer con los datos que le están llegando, desde el eMAD.
  • El hilo de visualización termina de presentar el ECG en la pantalla antes de que el hilo de adquisición termine de llenar el segundo buffer.
  • Luego, el hilo de adquisición le avisa al hilo de visualización que el segundo buffer está listo para la presentación. Entonces se empieza a llenar el primer buffer con datos nuevos provenientes del eMAD, y a partir de aquí, se repiten los pasos anteriores.

Flujo entre los hilos ThreadFuncAcquisition y ThreadFuncChannelsView

 

En segundo lugar, tenemos la opción de adquirir las señales del eMAD y guardarlas en disco para una futura visualización. Aquí se utilizan los hilos ThreadFuncAcquisitionSave y ThreadFuncChannelsView. Esta opción es muy similar a la anterior excepto que se realizan algunos pasos previos:

  • Se le pide al usuario mediante un cuadro de dialogo “guardar como..’ el nombre y directorio del archivo en donde desea que se guarde el ECG del paciente, y se crea dicho archivo con los encabezados (headers) necesarios para la configuración, como por ejemplo, la tabla de conversión, la ganancia de hardware, entre otros.
  • Una vez creado y obtenido la localización (path) del archivo en disco, se le pasa este último a la estructura de datos de entrada del hilo de adquisición ThreadFuncAcquisitionSave.
  • El hilo de adquisición procede a abrir el archivo en modo exclusivo de escritura y no compartido. Luego realiza la configuración del eMAD, y desarrolla los mismos pasos de la opción anterior.
  • Una vez que el hilo de adquisición le lleguen los datos del eMAD, este los coloca en los buffers para el intercambiarlos con el hilo de visualización, y a su vez los envía al archivo en disco antes de ofrecerlos al hilo de adquisición.
  • A partir de aquí, los pasos son similares a la opción anterior.

. Flujo de información entre los hilos ThreadFuncAcquisitionSave y ThreadFuncChannelsView

Como tercera opción, deseamos visualizar un ECG del paciente desde un archivo en disco. ThreadFuncAcquisitionOpen y ThreadFuncChannelsView. son los hilos o funciones que comprende esta opción.

Esta alternativa es muy similar a la primera y segunda opción, excepto que no hay que establecer comunicación con el eMAD y por ende ThreadFuncConnect no se utiliza. A continuación se explica los pasos a seguir para satisfacer esta opción:

  • Se le pide al usuario el directorio y nombre del archivo en disco a través de un cuadro de dialogo similar al de la opción descrita anteriormente “abrir...”.
  • Luego de tener la localización (path) del archivo que se desea visualizar, este se incluye en la estructura de datos de entrada al hilo ThreadFuncAcquisitionOpen.
  • El hilo de adquisición procede entonces, a adquirir los datos del archivo de la misma forma como los adquiría del eMAD, para luego enviarlos a los buffers para el intercambio con el hilo de visualización.
  • Los pasos siguientes, son similares al de las opciones anteriores.

Flujo de información entre los hilos ThreadFuncAcquisitionOpen y ThreadFuncChannelsView

Ahora bien, un aspecto de suma importancia con respecto a la tercera opción, es que el acceso a disco es mucho más rápido que la adquisición de los datos con el eMAD, ya que éste, último lo define la frecuencia de muestreo y el número de canales. En cambio, el acceso a disco lo define el mismo disco. Para utilizar el mismo hilo de visualización se implementó una modificación en el hilo ThreadFuncAcquisitionOpen, de adquisición.

Cuando el hilo adquiere los datos del archivo en disco, procede a colocarlos en los buffers de intercambio, y luego dependiendo de la configuración que está al inicio del archivo en donde se guarda la tabla de conversión y la ganancia, entre otros parámetros, procede a realizar retardos necesarios para simular la adquisición en tiempo real entre cada llenado de los buffers de intercambio.

Sistema de archivos de eMonitor

La aplicación contiene un sistema de archivos en los cuales, se diferencian cada paciente por medio de archivos “.pac” en donde se guardan parámetros de configuración, datos del paciente, dirección IP del eMAD, entre otros. A su vez, cada paciente tiene un subdirectorio en donde guarda los archivos de ECG adquiridos “.dat”. Estos últimos guardan los parámetros de la adquisición en un encabezado, para luego visualizarlos correctamente.

eMonitor y los registros de Windows

La aplicación es capaz de guardar las configuraciones de su entorno, como tamaño, color de las grillas de visualización del ECG, etc. en los registros de Windows bajo la clave “GBBA, Software / eMonitor...”. De esta forma, conseguimos que la interfaz con el usuario sea lo más intuitiva posible, como por ejemplo, que al iniciar la aplicación el usuario se encuentre con los últimos parámetros que haya configurado.

eMonitor y la barra de tareas de Windows

eMonitor tiene la capacidad de “esconderse” en el escritorio de Windows y presentar un icono en la barra de tareas de Windows que le indique al usuario que está trabajando. Por ejemplo, el usuario puede colocar la opción de adquirir guardando en disco, y al minimizar la ventana de aplicación, ésta automáticamente se desaparecerá y colocará un ícono en la barra de tareas. Aunque la aplicación no aparezca en el escritorio de Windows, ésta seguirá adquiriendo y guardando en disco. Luego que el usuario decida regresar a la aplicación, solo debe hacer “doble clik” en el icono del programa en la barra de tarea para que la ventana aparezca en su ultimo estado.

eMonitor y el motor de ayuda de WinHelp incluido con Microsoft Windows

eMonitor tiene la capacidad de activar WinHelp junto con identificadores de contexto, derivados de identificadores de ordenes y pantalla.

En otras palabras, el usuario puede presionar un botón en la barra de herramientas (?), luego utilizando el ratón se mueve al sitio del cual necesita la ayuda, y presiona de nuevo el ratón en el sitio, para que se abra inmediatamente una ventana de ayuda correspondiente a la zona señalada con el ratón.

También posee un índice de ayuda, el cual, se consigue en el menú de opciones. En este, el usuario podrá conseguir todos los temas de ayuda en bloques bien estructurados.

eMonitorStation

eMonitorStation es el nombre que lleva la estación central de visualización y almacenamiento de las señales electrocardiográficas de todos los pacientes de la UCI.

Al igual que eMonitor, esta aplicación fue realizada con programación orientada a objetos en C++. A diferencia de eMonitor, esta aplicación posee las siguientes clases bases heredadas de la MFC:

  • CeMonitorApp
  • CeMonitorDoc
  • CChildFrame
  • CMainFrame
  • CeMonitorChannelsScrollView

También existe la clase de comunicación con los MAD través de Internet.

El usuario puede tener abiertos varios pacientes (.pac), cada uno en una ventana hija distinta, aunque solo una de las ventanas hija esta activa. La aplicación sólo tiene un menú y una barra de herramientas, y todas la ordenes se encaminan a la ventana hija activa. La barra de título de la ventana principal muestra el nombre del paciente (archivo .pac) de la ventana hija activa.

El cuadro de minimización de la ventana hija (paciente) permite que el usuario reduzca dicha ventana a un icono en la ventana principal. El menú Ventana de la eMonitorStation permite que el usuario controle su presentación mediante los elementos siguientes:

  • Cascada: organiza las ventanas existentes mediante un patrón de ventanas solapadas.
  • Mosaico: organiza las ventanas existentes mediante un patrón no solapado, tipo mosaico.
  • Organizar iconos: organiza las ventanas minimizadas en la ventana de marco.
  • Nombre de los pacientes (archivos .pac): selecciona la ventana hija correspondiente y la muestra por encima de las demás.

Esta aplicación trabaja con las siguientes características similares a eMonitor:

  • Sistema de archivos.
  • Los registros de Windows.
  • La barra de tareas de Windows.
  • El motor de ayuda de WinHelp incluido con Microsoft Windows.
blog comments powered by Disqus