Articulo-JornadasUTN2004

•

UBAM

Contenidos Muy Locos

26.12.2022

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Derecho Penal I

149.386 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

Página 1 de 15
HEALTH OVER IP: MODELO CLIENTE – SERVIDOR
PARA LA TRANSMISIÓN Y VISUALIZACIÓN DE
SEÑALES CARDÍACAS A TRAVÉS DE INTERNET
MEDIANTE DISPOSITIVOS EMBEBIDOS Y SOFTWARE
LIBRE

Iniesta, José M., Mercado, Gustavo, Perez, Cristian F., Sturba Leonardo

Grupo de Investigación y Desarrollo CODAREC - Telemedicina
Universidad Tecnológica Nacional - Facultad Regional Mendoza
Coronel Rodríguez 273. 5500 Mendoza.
http://web.frm.utn.edu.ar/codarec/telemedicina.htm
Tel. 0261 4239596. codarec-telemedicina@frm.utn.edu.ar

RESUMEN
En el presente trabajo se describen y detallan las características técnicas de un sistema Health over IP
(Salud sobre Protocolo de Internet) aplicado a la transmisión de señales cardíacas, previamente adquiridas
y digitalizadas, mediante dispositivos embebidos que actúan como clientes, hacia un servidor (Modelo
Cliente – Servidor). En el servidor, un software realiza la administración de la información recibida y la
almacena en bases de datos. El servidor permite el acceso a la información (visualización de señales,
descarga de archivos, etc.) a través de Internet, a personas autorizadas desde un portal Web. De esta
forma, sólo profesionales de la Salud que cuenten con su identificación personal (nombre de usuario y
contraseña) podrán hacer uso de la información del o de los pacientes asignados, desde cualquier parte del
mundo. La descarga de archivos se hace en EDF (European Data Format), formato simple y flexible
diseñado para el almacenamiento de variables físicas. Tanto el uso, ventajas y limitaciones de los
dispositivos embebidos como los aplicativos implementados en el servidor serán objeto de análisis. Cabe
destacar que la mayoría de las herramientas de software utilizadas en el servidor son del tipo código
abierto y software libre, por ejemplo Linux, MySQL, Apache, PHP. Esto implica muchos beneficios
como: 1) menor costo, no se alquila ni se paga licencia propietaria; 2) mayor flexibilidad, posibilidad de
acceso al código; 3) mayor fiabilidad de los productos y estabilidad. Los resultados muestran los alcances
de la tecnología empleada, en Salud, y permiten proponer conceptos y criterios que se deberían incluir en
el paradigma de Health over IP. La conclusión más importante revela que la Telemedicina a través del
uso de la tecnología existente contribuye a la reducción de costos y tiempos, permite la interconsulta y
accesibilidad a zonas remotas.

PALABRAS CLAVE
Modelo Cliente-Servidor, señales cardíacas, Internet, dispositivos embebidos, software libre.

Página 2 de 15
INTRODUCCIÓN
Indicadores de la situación actual de Latinoamérica en general y de nuestro país,
Argentina, revelan condiciones de vida precaria tales como: 1) elevado
empobrecimiento, 2) bajo porcentaje de la población tiene acceso a atención médica
adecuada, 3) sistemas de salud colapsados y desarticulados, 4) ausencia de un registro
adecuado de los eventos y recursos en salud, etc.

Si a estos indicadores sumamos otros factores relacionados con la escasez y
centralización de recursos, la gran extensión territorial e irregular distribución
poblacional, la situación es más grave aún.

Cuando la distancia es uno de los factores críticos para el suministro de atención
sanitaria, zonas rurales, la Telemedicina es una alternativa esencial para combatir dichas
adversidades haciendo uso la tecnología actual en las comunicaciones, soluciones
informáticas, etc. En la actualidad existen, en todo el mundo, muchos proyectos,
aplicaciones y actividades referidas con esta disciplina. Algunos testimonios del estado
del arte son: a) “Programa Mexicano de Tele-salud” (ISSSTE - México, 1998), b)
“Programa de Telemedicina apto para áreas rurales de la República Argentina” (Lamfri,
2000), d) “Desarrollo de Telemedicina en los Hospitales Rurales del Chaco -
Argentina”, f) "PatientNet (Wireless Patient Monitoring)" (GE Medical Systems, 2000),
g) “Plan de Telemedicina del INSALUD” (Ministerio de Sanidad y Consumo, 2000).

En países en desarrollo es necesario generar proyectos que se adapten a los pocos
recursos existentes y a las necesidades imperiosas de suplir. Buscar soluciones viables,
no solamente desde el punto de vista técnico sino también desde el punto de vista de la
salud.

El objetivo principal de este informe es dejar precedentes del conocimiento y
experiencias obtenidas hasta el momento en el proyecto “Health over IP (Salud sobre
Protocolo de Internet)” (Mercado, et al., 2004) del Grupo de Investigación y Desarrollo
CODAREC-Telemedicina de la Universidad Tecnológica Nacional Regional Mendoza.
Se abordan fundamentalmente las especificaciones técnicas, consideraciones de diseño,
hardware y software utilizados para la transmisión de señales cardíacas a través de
Internet, con dispositivos embebidos, hacia un servidor (Figura N° 1). Finalmente se
proponen conceptos y criterios que creemos debería incluir el paradigma Health over IP.

El sistema fue diseñado bajo el Modelo o Arquitectura Cliente – Servidor. Esta
arquitectura agrupa conjuntos de elementos que efectúan procesos distribuidos de
manera cooperativa (ITLP, s.f.). El cliente representa al proceso que inicia el diálogo o
solicita los recursos y servidor, al proceso que responde a las solicitudes. La mayoría del
software utilizado, especialmente en el servidor, es SL (Software Libre). Esto no sólo
otorga ciertas libertades que luego explicitaremos, sino también reduce de manera
significativa los costos asociados al licenciamiento, mantenimiento y reforma del
mismo.

Página 3 de 15

Es posible identificar dos tipos de clientes: 1) dispositivo embebido que interactúa con
el paciente y transmite las señales cardíacas y 2) médicos o especialistas que acceden a
la información correspondiente a las señales a través de un portal Web. Podrían
considerarse otros clientes, pero por ahora mantendremos esta disposición.

Los médicos o especialistas, no sólo podrán visualizar datos desde el portal Web sino
también descargar la información en formato EDF (European Data Format).

ELEMENTOS Y METODOLOGÍA EMPLEADA
Como habíamos mencionado, el sistema se corresponde con la Arquitectura Cliente-
Servidor. En este modelo las transacciones se dividen en procesos independientes para
intercambiar información, servicios o recursos formando un sistema distribuido. Los
clientes solicitan servicios y el servidor o servidores proporcionan los mismos (Figura
N° 2) (ITLP, s.f.).

Las principales características de esta arquitectura: (INEI, s.f.):
• El servidor brinda una interface única y conocida a cada cliente.
• El cliente sólo necesita conocer la interface externa del servidor.
• El cliente no depende de la ubicación física del servidor, ni del hardware
sobre el que esté montado, ni del sistema operativo.
• Cambios en el servidor no deben implicar necesariamente cambios en el
cliente.

Ventajas más importantes de este esquema:
• Se pueden reducir costos del hardware, llevando las aplicaciones a
plataformas más baratas. También reducir los costos del software, ya que
éste se limita a las necesidades del usuario.
Internet
Dra. V C
Dispositivo embebido
Zona N° 1
Dispositivo embebido
Zona N° 2
Dr. A G
Servidor
Health over IP
Figura N° 1. Participantes del Sistema.
Nivel de aplicación
CLIENTE
Servicios
Hardware
Nivel de aplicación
SERVIDOR
Servicios
Hardware
Petición
Respuesta
Figura N° 2. Modelo Cliente-Servidor
Página 4 de 15
• Al estar centralizada la información, es posible proporcionar una mayor
consistencia y suministro de la información. Se puede acceder a la misma
desde cualquier nodo de la red.
• Habilidad para integrar sistemas heterogéneos, pues los clientes y
servidores pueden existir en múltiples plataformas.
• Adaptable a cambios de la tecnología.
• Favorece a la construcción de interfaces gráficasinteractivas, facilitando el
uso de las aplicaciones a los usuarios.

Inconvenientes:
• Complejidad tecnológica en la integración de productos.
• Requiere rediseño de elementos involucrados en los sistemas de
información (procesos, interfaces, almacenamiento de datos, etc.).
• Por lo general hay que utilizar mecanismos que existan en diferentes
plataformas.
• Se dificulta asegurar un elevado nivel de seguridad.
• Problemas de congestión de red pueden degradar el rendimiento.
• Costos ocultos (uso de nuevas tecnologías, cambios organizativos, etc.).

Ambos para comunicarse necesitan una determinada infraestructura de
comunicaciones, por ejemplo una LAN (Red de Área Local) o una WAN (Red de Área
Mundial), etc. (Vieyra, 2000).

En la figura siguiente (Figura N° 3) puede verse el esquema de todo el sistema. Cada
bloque será a continuación objeto de análisis.

Figura N° 3. Esquema General de Funciones.
� Generador de Señales.
� Recepción RS-232.
� Establecimiento de Conexión a Internet.
� Transmisión de Datos TCP/IP.
B) Cliente
(Dispositivo embebido)
� Recepción de Datos.
� Almacenamiento de Información.
� Soporte de Acceso, Descarga, Visualización desde Internet.
C) Servidor
INTERNET
� Adquisición y
� Digitalización de Señales
� Transmisión RS-232
A) Ente biológico
� Acceso y descarga de
Información.
D) Cliente
(Usuarios externos)
Página 5 de 15
A) Ente biológico

� Generador de señales: El corazón humano podría considerarse como una
bomba electromecánica. La actividad bioeléctrica cardíaca tiene su origen en
la actividad bioeléctrica de cada célula muscular cardíaca (necesaria para
contraerse). Esta actividad electromecánica se produce según un orden estricto
en cada latido. Es que las células miocárdicas son excitadas por un estímulo
eléctrico propagado por ciertas vías específicas de conducción que distribuyen
ese impulso eléctrico inicial según una secuencia bien precisa (Del Aguila,
1990). El impulso cardíaco se genera de manera automática y se transmite a
todas las células, y éstas con su contracción o acortamiento impulsan la sangre
para que se distribuya por todo el organismo. Por medio del Electrocardiógrafo
(ECG) se obtiene una representación gráfica de la actividad eléctrica cardíaca
a partir de una serie de terminales o electrodos conectados en la superficie de
cuerpo del paciente. La amplitud de esta señal, es del orden de los [mV] y con
componentes en frecuencias inferiores a los 100 Hz (Díaz Calavia et al.). Para
el médico, la forma y la duración de cada componente del electrocardiograma
representa un significado, pero no es objeto del presente trabajo describir la
anatomía funcional del sistema de conducción cardíaco.

B) Cliente (dispositivo embebido)

Un dispositivo o sistema embebido no necesariamente debe tener una pantalla,
un teclado y un disco rígido. Puede ser solo una parte de todo el conjunto. Los
sistemas embebidos son diseñados con estrictos márgenes de tamaño, peso,
consumo de potencia, vibraciones, humedad, interferencias eléctricas y sobre todo
bajo costo y fiabilidad (Bentham, 2000). Las principales limitaciones del uso de
estos dispositivos radican en la dificultad que tienen para adaptarse a nuevas
necesidades sin requerir grandes reformas de software e incluso hardware. Una de
ellas se refiere a los reducidos recursos de almacenamiento que poseen. La oferta
existente permite seleccionar, previendo algunos de los factores mencionados,
para la aplicación deseada aquél que mejor se adapte.

1) Módulo de adquisición, digitalización y transmisión serie RS-232 de señales
cardíacas:

� Adquisición de señales: se muestran (Figura N° 4) los diferentes procesos a
los que fue sometida la señal cardíaca. En primera instancia son utilizados
electrodos superficiales para obtener los potenciales bioeléctricos del cuerpo
humano. Luego debido a las características propias de la señal y al entorno
en que se desarrolla la adquisición de las mismas, es necesario incorporar
etapas de amplificación y filtrado para su posterior digitalización. Utilizamos
un amplificador de instrumentación con elevada impedancia de entrada, (Zin
≈ 1010 Ohms) y una relación de rechazo en modo común CMRR de ≈ 90dB.
En el filtrado realizó en 2 etapas:
1) Filtro Pasa Alto de 1º orden, para eliminar señales < 0,05Hz.
2) Filtro Pasa Bajo de 1º orden, con fc = 20Hz.

Tanto el amplificador de instrumentación como los filtros, están formado
por una cadena de Amplificadores Operacionales TL082, con tecnología BI-
Página 6 de 15
FET II TM. De esta manera, obtenemos como resultado una señal que
satisface los requerimientos del resto del sistema.

� Digitalización de señales y transmisión RS-232: la señal una vez adecuada a
los niveles de tensión admisibles del conversor A/D (de 0 a +5 V), es
digitalizada a una frecuenta de muestreo de 500 Hz con 8 bits de resolución
mediante un microcontrolador PIC16F877 de MICROCHIP® que cuenta con
un módulo de conversión A/D de hasta 10 bits de resolución y 8 canales.
Con estas especificaciones se consiguió calidad razonable para diagnóstico.
� Una vez digitalizada la señal, a través de la USART (Unidad de
Recepción/Transmisión Sincrónico/Asíncrono) del microcontrolador es
posible transmitir los datos digitales en serie RS-232 hacia cualquier
dispositivo que contenga un puerto de recepción serie.
2) RCM 2110 (Rabbit™1 Core Module):

Este módulo recibe los datos digitalizados del módulo anterior, establece una
conexión a Internet Dial-up2 y transmite los datos hacia un servidor FTP (File
Transfer Protocol) (Postel y Reynols, 1985). Para establecer conexión a Internet
el RCM 2110 se conecta, a través de una interface serie RS-232, con un Módem
(Modulador/Demodulador) externo.

Los módulos de microprocesamiento Core fueron diseñados para agilizar el
desarrollo y la implementación de sistemas dedicados con conectividad Ethernet
integrada. El RabbitCore se monta y actúa como el procesador central del
sistema diseñado por el usuario. Posee tamaño reducido y ofrece un paquete
completo para el control y la comunicación, ya que trae implementados los
protocolos de las diferentes capas del modelo híbrido de 5 capas (Tanenbaum,
1997). Se programan con Dynamic C® (lenguaje C) provisto por ZWorld. Las
librerías de este entorno de programación contienen todo lo necesario para
controlar al procesador Rabbit. La versión utilizada fue Dynamic C 8.3 (Rabbit
Semiconductor, 2000).

El módulo utilizado es el RCM 2110 (Figura N° 5), cuyas especificaciones
generales son las siguientes:

1 El procesador Rabbit® comparte una arquitectura similar y alto grado de compatibilidad con los procesadores Z80,
Z180 y HD64180, pero tiene importantes mejoras. Este procesador se ha diseñado con estrecha cooperación de Z-
World Inc., fabricante desde hace mucho tiempo de procesadores de bajo costo.
2 Infraestructura necesaria para proveer acceso a Internet por discado telefónico.

AMPLIFICADOR
DIFERENCIAL

FILTROS
PIC16F877
CONVERSOR
A/D – USART
Figura N° 4. Amplificación y Digitalización de la señal cardíaca
Página 7 de 15

� Recepción RS-232: los datos digitalizados provenientes de las etapas
anteriores son recibidos en uno de los puertos serie del RCM 2110 y se
almacenan en el buffer del mismo.

� Establecimiento de conexión a Internet: la conexión es del tipo Dial-Up y se
realiza mediante un Módem externo Us Robotics Sporster Voice 33.6
Faxmodem. El uso del protocolo PPP (Point to Point Protocol) nos permitió
la negociación de direcciones de IP (Internet Protocol) con un ISP (Internet
Server Provider).

� Transmisión de datos sobre Internet: a nivel de la capa de red y transporte se
utilizó el protocolo TCP/IP (Transmission Control Protocol/Internet
Protocol).A nivel de aplicación, se optó por FTP (Z-World, 2001). Los
datos obtenidos de la digitalización de las señales son almacenados en
archivos y luego transferidos mediante este protocolo a un servidor FTP.
Aunque este protocolo tiene serias desventajas en lo que a seguridad
respecta, ya que tanto contraseñas como el contenido de los archivos es
transferido en texto puro, por el momento, en etapas de ensayo, se seguirá
utilizando. Será un tema de discusión.

C) Servidor

Como lo indica el diagrama en bloques general, las funciones principales que el
sistema servidor debe desempeñar son: 1) recepción de la información enviada por
los sistemas clientes; 2) almacenamiento de la misma en bases de datos; 3) soporte
de acceso a la información.

La mayoría de las herramientas de software utilizadas en este nivel pertenecen al
movimiento código abierto y software libre. Bajo licenciamientos GNU y GPL.

Este tipo de software otorga ciertas libertades (Menini, s.f.):
1) Usar el programa con cualquier propósito.
2) Estudiar el funcionamiento del programa y adaptarlo a las necesidades propias.
3) Distribuir copias, pudiendo ayudar a la comunidad.
4) Mejorar el programa y hacer publicas esas mejoras, para beneficio de la
comunidad.

Modelo: RCM2110
Tamaño: 51mm × 89mm × 20 mm
Alimentación: 5V
Frecuencia: 22MHz
Memoria Flash de programa: 1 × 256K flash
memory
Memoria RAM: 128K SRAM

Figura N° 5. RCM 2110
Página 8 de 15
Estas libertades le facilitan al usuario salir del simple rol de consumidor de
tecnología para pasar a formar parte activa en la sociedad del conocimiento.

El sistema operativo utilizado fue Linux Red Hat 9 kernel (2.4.20-8). Excelente
plataforma servidora de una intranet o de Internet. Proporciona clientes y
servidores para todos los protocolos esenciales (FTP, HTTP, PPP, SMTP, etc.).
Cuenta además con varios lenguajes de programación, compiladores y
herramientas de desarrollo Web asociadas, tales como C++, Expect, Lenguajes de
shell, Perl, Java de Sun Microsystems, etc.

El resto de aplicativos instalados y utilizados fueron los siguientes:

a) Lenguaje de shell (bash): se desarrolló un script que opera de forma
residente en el servidor. Se encarga de gestionar los datos correspondientes a
las señales transmitidas desde los sistemas clientes. Una vez clasificada la
información, a través de sentencias SQL, es almacenada en bases de datos.

b) Servidor FTP: como el monitoreo de las señales transmitidas es realizado en
tiempo diferido, este protocolo es utilizado para recepción de la información
en forma de archivos. El servidor deberá tener habilitados tantos usuarios
como sistemas clientes se encuentren en funcionamiento. Se utilizó Vsftpd
de Red Hat Linux 9.

c) Servidor HTTP (Hyper-Text Transfer Protocol) (Fielding, 1999): El acceso e
interacción con los datos almacenados en el servidor, desde Internet, se
realiza a través de un portal Web. Siguiendo la filosofía código abierto y
software libre, se utilizó el servidor Apache HTTP (ver. 2.0.40) que además
de ser uno de los más utilizados en el mundo cuenta con altos niveles de
prestación, fiabilidad y estabilidad. También incluye una gran cantidad de
módulos para ser utilizados según la aplicación a desarrollar. Entre los
usados PHP (Hypertext Preprocessor) y MySQL.

d) MySQL (ver. 3.23.54): es el sistema de administración de bases de datos
SQL de código abierto y licencia pública más popular. Algunas
características son: a) servidor multiprocesos, esto lo hace rápido; b) fiable y
fácil de usar; c) sistema de administración de bases de datos relacionales; d)
portable; e) funciona en sistemas embebidos o sistemas cliente/servidor; f)
sistema de seguridad muy flexible y diferentes niveles de acceso a usuarios
(Maslakowski, 2000).
La información fue almacenada en bases de datos relacionadas entre sí. Hay
bases de datos de pacientes, de señales de ECG (electrocardiográficas), de
médicos o especialistas con sus pacientes a cargo, etc.

e) PHP (ver. 4.2.2): utilizado para la programación de las páginas dinámicas del
sitio Web del servidor. Las secuencias de comandos PHP se pueden embeber
en los archivos HTML (Lenguaje de Etiquetas por HiperTexto), incluyendo
instrucciones para actualizar archivos, información almacenada, acceder a
base de datos, generar gráficos, etc.

Página 9 de 15
El servidor necesitará una dirección de IP fija o una dirección de DNS, tanto
para el FTP como para la página Web. En esta fase del proyecto, generación de
un prototipo, como servidor se utilizó una PC. Pero para la prestación de
servicios el hardware del mismo se deberá caracterizar por incorporar unidades
de almacenamiento masivo que eviten la pérdida de datos y elementos que
permitan los accesos simultáneos (alta velocidad, niveles RAID, etc.). Además
tener un acho de banda suficiente para la carga y descarga de información,
considerando la cantidad de clientes, el ancho de banda de las señales, las
consultas Web, etc.

D) Cliente (usuario externo)

Como se indicó en la introducción, es posible identificar varios clientes en el
sistema planteado. Por un lado él o los dispositivos embebidos que interactúan con
pacientes y por otro los médicos o especialistas que acceden al portal Web del
servidor a través de Internet. Estos últimos, usuarios externos, también se
comportan como clientes para el servidor.

Para acceder a la información almacenada en el servidor, los médicos o
especialistas deberán estar previamente registrados y poseer un nombre de usuario
y clave correspondiente. Cada vez que un usuario se conecta, se genera un proceso
de autentificación. Desde MySQL es posible restringir el acceso a ciertos datos
almacenados en las bases de datos, así como también asignar permisos de lectura,
escritura a cada usuario en particular.

Los médicos o especialistas podrán no solo visualizar las señales sino también
descargar archivos que contengan los datos correspondientes a las mismas. El
portal Web programado con PHP accede a la base de datos correspondiente, y los
grafica en formato de imagen (“bmp”, “jpeg”, etc.). El formato de los archivos
generados para la descarga es EDF (European Data Format)3. Este es un formato
simple y estándar para el intercambio y almacenamiento de señales físicas
grabadas simultáneamente (Kemp, s. f.). Actualmente existen muchas aplicaciones
relacionadas con este formato. Sus principales falencias radican en la falta de
compresión y encriptado de información.

Los datos que se manipulan, en la mayoría de las transacciones, corresponden a datos
médicos. De manera general se definen como todo dato personal relativo a la salud de
un individuo y son datos de carácter personal. A nivel seguridad, en el marco de la
LOPD4 (Ley Orgánica de Protección de Datos Personales) se establecen una serie de
medidas y controles al respecto. Podemos mencionar: a) control de entrada a las
instalaciones, b) control del soporte de los datos, c) control de memoria, d) control de
utilización, e) control de acceso, f) control de comunicación, g) control de introducción
de datos, h) control de transporte (Verdú Pascual, s.f.). Health over IP, creemos, deberá
considerar tales medidas. Pues, dicha denominación simboliza la fusión entre la red
Internet y el tratamiento de información sanitaria (Mercado et al., 2004). Health over IP
no es un protocolo de transmisión datos, al contrario utiliza los protocolos estándares e
incluso dependiendo de la aplicación puede contemplar la utilización de nuevos

3 Fue diseñado por ingenieros europeos en 1991 que trabajaban en ambientes médicos.
4 La LOPD es de aplicación a los datos de carácter personal registrados en soporte físico, que los haga susceptibles de
tratamiento, y a toda modalidad de uso posterior de estos datos por los sectores público y privado.
Página 10 de 15
protocolos quesurjan de la misma. Health over IP tiene como base a IP (Protocolo de
Internet). El alcance lo podríamos plasmar de la siguiente manera (Figura N° 6):

Hay otra serie de aspectos (Del Peso y Ramos, 1997) que el paradigma Health over IP
debería incluir y tener en cuenta:

� Confidencialidad: solo las personas autorizadas deben tener acceso a la
información almacenada.
� Integridad: esto tiene dos connotaciones, por un lado la integridad necesaria
en el momento de la transmisión de señales o datos. Para esto deberán
considerarse que las especificaciones de los canales de comunicación
superen los requerimientos del flujo de los datos para que lleguen todos los
datos. Por ejemplo deberán preverse memorias caché que impidan la pérdida
de información ante disminuciones del ancho de banda disponible o cortes
del canal de comunicación (pérdida no contemplada de la información). La
otra connotación se refiere a que sólo personas autorizadas podrían modificar
o borrar datos, para impedirse la alteración mal o no intencionada.
� Disponibilidad: significa poder disponer de la información cuando es
necesaria. Ya que el contar con la misma después del momento necesario
puede implicar la no disponibilidad.

RESULTADOS
Si bien este proyecto aún continúa en desarrollo y constante modificación, los
resultados obtenidos hasta el momento han sido satisfactorios. Muchos de ellos
sirvieron para plantear cambios y temas de discusión.

Algunos resultados:

• Transferencia de archivos, entre Cliente/Servidor, de forma confiable ya sea
dentro de una Intranet o en Internet.
• Envío de e-mails con el módulo RCM 2110, útil para implementar avisos de
emergencia.
• Desarrollo de un canal de adquisición y digitalización de señales cardíacas.
Si bien será necesario realizar ajustes en la adquisición de la señal, se obtuvo
en general una calidad razonable de la misma suficiente para continuar con
pruebas de campo.
• Detección de limitaciones en la transmisión.
• Acceso a bases de datos MySQL y visualización de señales en páginas
dinámicas programadas con PHP.
Figura N° 6. Alcance de Health over IP en el modelo de híbrido (5 capas) de interconexión de sistemas
Capa Física
Capa de enlace de datos
Capa de red
Capa de transporte
Capa de aplicación
1
2
3
4
5 Health over IP
IP
Página 11 de 15
• Administración de la información entrante en el servidor con un script.
• El software libre se adaptó en todos los casos a las necesidades. El material
de apoyo y foros de discusión hoy existentes nos permitieron utilizar dichas
herramientas de software sin desventaja alguna.

Otros se corresponden con el “Programa de desarrollo de Unidades de Cuidados
Coronarios a distancia – Telemedicina”, proyecto en desarrollo en conjunto con el IRB
(Instituto Regional de Bioingeniería) de la Universidad Tecnológica Nacional Regional
Mendoza. Cuyo objetivo principal es el desarrollo de un sistema cliente-servidor que
permita transmitir datos de señales cardíacas desde una PC, situada en zonas rurales de
la provincia de Mendoza, a un servidor colocado en zona urbana. Si bien este proyecto
en particular cuenta con plataforma de hardware y software es diferente, el esquema del
sistema es básicamente el mismo. Se han adquirido, digitalizado y visualizado señales
para finalmente transmitirlas a distancia.

DISCUSIÓN
En el proceso de diseño, desarrollo e implementación de diferentes etapas del
proyecto, surgieron alternativas y consideraciones a discutir y tener en cuenta:

� Ampliar el alcance de las señales transmitidas. Actualmente, por encontrarse el
proyecto en etapa de desarrollo, se acotaron muchas variables (número de señales
transmitidas, bits de resolución de las mismas, almacenamiento de la información en
el RCM2110, etc.).
� Nuevos enlaces de comunicación entre el dispositivo cliente y ISP. Tales como
enlaces de radio, telefonía celular, redes wireless, GSM (Global System Mobile),
etc.
� Cambios estructurales ante la existencia de un número importante de clientes
funcionando simultáneamente. Plantear soluciones al respecto.
� Utilización del protocolo SFTP (Secure File Transfer Protocol), en el cual los datos
transferidos entre un host remoto y un servidor e incluso las contraseñas son
encriptadas proveyendo mayor seguridad.
� Hacer uso de algoritmos de análisis de señales que permitan la detección de
anomalías en las señales y generen acuses de emergencias.

CONCLUSIONES
Nosotros hemos utilizado líneas telefónicas, módems, sistemas embebidos, PC's,
Internet, etc. Algunos de estos servicios y dispositivos se encuentran actualmente
disponibles en cualquier región, otros están en permanente expansión. Esto hace viable
desde el punto de vista técnico el planteo y desarrollo de proyectos tales como este.

Los dispositivos embebidos ofrecen una solución de menor costo, tamaño y por ende
mayor beneficio siempre y cuando se tengan en cuenta las limitaciones que los mismos
presentan a la hora de seleccionar el más adecuado para una aplicación determinada.

La Telemedicina haciendo uso de la tecnología existente contribuye entre otras a la
reducción de costos de transporte y disminución en tiempos de atención. También
posibilita la interconsulta y el acceso a zonas inhóspitas.

Página 12 de 15
AGRADECIMIENTOS

Grupo de Investigación CODAREC - Universidad Tecnológica Nacional F.R.M.

Instituto Regional de Bioingeniería - Universidad Tecnológica Nacional F.R.M.

REFERENCIAS Y BIBLIOGRAFÍA
Axmark, David et al. (2004). MySQL Reference Manual for version 5.0.0-alpha [en
línea]. © Copyright 1995-2004 - MySQL AB. [Disponible en
http://dev.mysql.com/doc/ formato HTML - 4,08M].

Bakken, Stig S. et al. (2002). PHP Manual [en línea]. The PHP Group. © Copyright
2001-2003 The PHP Documentation Group . [Disponible en
http://www.php.net/docs.php - 2,88M].

Bentham, Jeremey (2000). TCP/IP Lean: Web Servers for Embedded Systems. CMP
Books - CMP Media.

Biosemi (2003). Which file format does Biosemi use? [en línea]. Amsterdam.
[Disponible en http://www.biosemi.com/faq/file_format.htm - 58,2k].

Castaño, Juan. A. et al. (2001). Curso práctico de Cekit sobre Microcontroladores -
Teoría, Programación, Diseño, Prácticas y Proyectos completos. USA, Cono Sur.

Comer, Douglas E. Interworking with TCP/IP, Vol. I: Principles, Protocols and
Architecture. USA, Pretince-Hall. (Trad. cast. Redes Globales de Información con
Internet y TCP/IP: Principios básicos, protocolos y arquitectura, Tercera Edición.
México: Pretince Hall Hispanoamericana, 1996).

Cromwell, Leslie et al. (1973). Biomedical Instrumentation and Measurements. USA,
Pretince-Hall. (Trad. cast. Instrumentación y Medidas Biomédicas, España:
Marcombo, 1980).

Del Aguila, Carlos (1990). Electromedicina - 2da edición Ampliada y revisada,
Argentina: Hispano Americana - HASA, 1994.

Del Peso Navarro, Emilio y Ramos, Miguel A. (1997). La información como activo
estratégico: Seguridad y Protección [en línea]. Contract Sofá Onnet. España.
[Actualización octubre de 1997]. [Disponible en http://www.onnet.es/index.html -
50,6k].

Díaz Calavia, Emilio J. et al. Limpieza de la función ECG. Biofísica - Dpto. Física y
Matemática Aplicada Clínica Universitaria de Navarra. Universidad de Navarra.
España.

Fielding, R. (1999). Hypertext Transfer Protocol (HTTP/1.1) - Request for Comment
Nro: 2616. The Internet Society, June 1999.

Página 13 de 15
GE Medical Systems - Information Technologies (2000). PatientNet (Wireless Patient
Monitoring) [en línea]. GE Medical Systems. USA. © Copyright 1997 - 2004 General
Electric Company. [Disponible en
http://www.gehealthcare.com/monitor/images/pdfs/patientnet.pdf - 411k].

Grupo BioLinux (s.f.). GNU Salud [e-línea]. Grupo BioLinux. Argentina. [Disponible
en http://www.sis.org.ar/sis2004/index.html - 530k].

INEI (s.f.). SistemasDistribuidos [en línea]. Instituto Nacional de Estadística e
Informática. Perú. [Disponible en
http://www.inei.gob.pe/web/metodologias/attach/lib616/INDEX.HTM - 10,4k].

ITLP (s.f.). Tutorial de Sistemas Distribuidos I [en línea]. Instituto Tecnológico de la
Paz. México [Disponible en
www.itlp.edu.mx/publica/tutoriales/sistsdist1/u1parte6.htm - 15,2k].

Kemp, Bob (s. f.). European Data Format: EDF and EDF+ [en línea]. [Disponible en
http://www.hsr.nl/edf/index.htm - 6,64k].

Kemp, Bob et al. (2001). Some standard texts for EDF and EDF+ [en línea].
[Disponible en http://www.hsr.nl/edf/standard_text.htm - 33,8k].

Kernighan, Brian W. - Pike, Rob. The UNIX Programming Environment (Trad. cast. El
entorno de programación UNIX. México: Pretince Hall Hispanoamericana, 1987).

Lamfri, M. A. et al. (2000). Programa de Telemedicina apto para áreas rurales de la
República Argentina [en línea]. CONAE - Universidad Nacional de Córdoba.
Argentina. [Disponible en http://www.sis.org.ar/sis2000/telemedicina_rural.pdf -
261k].

Luraschi, Roberto G. M. (2000). Sistema de Monitorización a Distancia de Señales
Biológicas Vitales a través de Radio [en línea]. Siemens - División Electromedicina.
Argentina. [Disponible en http://www.sis.org.ar/sis2000/red_imagenes_cba.pdf -
235k].

Martínez Barco, Patricio (s.f.). Sistemas Informáticos Distribuidos [en línea].
Departamento de Lenguajes y Sistemas Informáticos. España. [Actualización 15 de
octubre de 2002]. [Disponible en http://www.dlsi.ua.es/asignaturas/sid/sid2001-t4.ppt
- 115k].

Maslakowski, Mark (2000). Teach Yourself MySQL in 21 Days. USA, SAMS
Publishing. (Trad. cast. Aprendiendo MySQL en 21 Días, México: Pearson Educación,
2001).

Menini, Alberto (s.f.). Software Libre en el Área Salud [en línea]. Grupo BioLinux.
Argentina. [Disponible en
http://www.sis.org.ar/sis2004/Presentaciones/diapos_pdf/opensource-Menini.pdf -
251k].

Página 14 de 15
Mercado, Gustavo et al. (2004). Health over IP (Salud sobre Protocolo de Internet) [en
línea]. Grupo CODAREC – Telemedicina. Universidad Tecnológica Nacional
Facultad Regional Mendoza. Argentina. [Disponible en
http://www.sis.org.ar/sis2004/index.html - 258k].

Postel, J - J. Reynols, J. (1985). File Transfer Protocol (FTP) - Request for Comment
Nro: 959. ISI, October 1985.

Simpson, W. (1994). The Point to Point Protocol (PPP) - Request for Comment Nro:
1661. Daydreamer, July 1994.

Tanenbaum, Andrew. Computer Networks, Third Ed. USA, Pretince-Hall. (Trad. cast.
Redes de Computadoras, Tercera Ed. México: Pretince Hall Hispanoamericana,
1997).

Tenza Pérez, Tomás (2000). Plan de Telemedicina del Insalud [en línea]. Ministerio de
Sanidad y Consumo - Instituto Nacional de la Salud - Dirección General de
Organización y Planificación Sanitaria. Madrid, España. [Disponible en
http://ww1.msc.es/insalud/docpub/internet/telemedicina/telemedicina.pdf - 648k].

The Apache Software Foundation (s.f.). Documentation of Apache HTTP Server
Version 1.3 [en línea]. [Disponible en http://httpd.apache.org/docs/ - (s. d.)].

Tocci, Ronald J. Digital system principles. USA, Pretince-Hall. (Trad. cast. Sistemas
digitales - Principios y aplicaciones, México: Pretince Hall Hispanoamericana, 1993).

Tomasi, Wayne. Electronic Communications System Fundamentals Through Advanced.
USA, Pretince-Hall. (Trad. cast. Sistemas de Comunicaciones Electrónicas,
México: Pretince Hall Hispanoamericana, 1996).

Verdú Pascual, Fernando A. (s.f.). Recomendación n. R (97) 5, de 13 de febrero de
1997, del Comité de Ministros del Consejo de Europa a los Estados miembros sobre
Protección de Datos Médicos [en línea]. Master en Medicina Forense - Universidad de
Valencia. España. [Disponible en http://www.uv.es - 54,3k].

Vieyra, Guadalupe Elizalde (2000). Modelo Cliente – Servidor [en línea]. Facultad de
Ciencias Físico Matemáticas. México. [Disponible en
http://www.fismat.umich.mx/~elizalde/tesis/node19.html - 14,4k].

Página 15 de 15
ABSTRACT
The present work describes in detail the technical characteristics of Health over IP (Health over Internet
Protocol) system. This system is applied to the transmission of cardiac signals previously acquired and
digitalized by means of embedded devices that act like clients toward a server (Model Client – Server). In
the server, the software manages the received information and stores it in databases. The server only
allows authorized people from a webpage to access the information (visualization of signals, file
downloading, etc.) through Internet. In such a way, only health professionals who posses their personal
identification (username and password) will be able to make use of their patient information from any
part of the world. File downloading is made in EDF (European Data Format). This format is simple and
flexible for storing physical variables. The usage of embedded devices, their advantages and limitations,
and implemented applications in the server will be analyzed. It is important to emphasize that most of the
software tools used in the server are open source and free software, for example Linux, MySQL, Apache,
and PHP. This implies many benefits like: 1) lower costs, since software licenses are not paid or rented;
2) greater flexibility to access the code; 3) greater reliability and stability of products. The obtained
results show scopes of the technology used in Health. In addition, they allow us to establish concepts and
criteria that should be included in Health over IP paradigm. The most important conclusion reveals that
the Telemedicine contributes to the reduction of costs and times, and this discipline permits simultaneous
consultations and accessibility to remote zones too, through the usage of existent technology.