SISTEMA PROTOTIPO DE TELEMONITOREO … bien, que se vea en ellos el anhelo de buscar la verdad y la...
77
SISTEMA PROTOTIPO DE TELEMONITOREO PARA PACIENTES, USANDO TECNOLOGÍAS INALAMBRICAS SEMIMÓVILES DE COMUNICACIÓN TRABAJO DE GRADO No: T.G. 0427 ALEJANDRO GUTIERREZ MURILLO NELSON HENRIQUEZ COLMENARES WILLIAM RODRIGUEZ CERÓN DIRECTOR: ING. CARLOS EDUARDO GARCIA PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD INGENIERÍA DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA BOGOTA D.C. 1
Transcript of SISTEMA PROTOTIPO DE TELEMONITOREO … bien, que se vea en ellos el anhelo de buscar la verdad y la...
SISTEMA PROTOTIPO DE TELEMONITOREO PARA PACIENTES,
USANDO TECNOLOGÍAS INALAMBRICAS SEMIMÓVILES DE
COMUNICACIÓN
TRABAJO DE GRADO No: T.G. 0427
ALEJANDRO GUTIERREZ MURILLO
NELSON HENRIQUEZ COLMENARES
WILLIAM RODRIGUEZ CERÓN
DIRECTOR: ING. CARLOS EDUARDO GARCIA
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD INGENIERÍA
DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA
BOGOTA D.C.
1
SISTEMA PROTOTIPO DE TELEMONITOREO PARA PACIENTES,
USANDO TECNOLOGÍAS INALAMBRICAS SEMIMÓVILES DE
COMUNICACIÓN
TRABAJO DE GRADO No: T.G.0427
ALEJANDRO GUTIERREZ MURILLO
NELSON HENRIQUEZ COLMENARES
WILLIAM RODRIGUEZ CERÓN
Trabajo de grado presentado como
requisito parcial para optar al título de
Ingeniero Electrónico.
Director:
ING. CARLOS EDUARDO GARCIA
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD INGENIERÍA
DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA
BOGOTA D.C.
2005
PONTIFICIA UNIVERSIDAD JAVERIANA
2
FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA ELECTRONICA
RECTOR MAGNIFICO: R.P. GERARDO REMOLINA S.J.
DECANO ACADÉMICO: Ing. ROBERTO ENRIQUE MONTOYA VILLA
DECANO DEL MEDIO UNIVERSITARIO: R.P. ANTONIO JOSÉ SARMIENTO NOVA S.J.
DIRECTOR DE CARRERA: Ing. JUAN CARLOS GIRALDO CARVAJAL
DIRECTOR DEL PROYECTO: Ing. CARLOS EDUARDO GARCIA LEMUS
3
ARTICULO 23 DE LA RESOLUCIÓN No. 13 DE JUNIO DE 1946
"La universidad no se hace responsable de los conceptos emitidos por sus
alumnos en sus proyectos de grado.
Sólo velará porque no se publique nada contrario al dogma y la moral
católica y porque los trabajos no contengan ataques o polémicas puramente
personales. Antes bien, que se vea en ellos el anhelo de buscar la verdad y
la justicia".
4
Nota de aceptación
______________________________
______________________________
______________________________
______________________________
_________
Presidente del Jurado
______________________________
_________
Jurado
______________________________
_________
Jurado
Bogotá, 03 de Junio de 2005
5
A mi papá y mi mamá y es especialmente
dedicado a tres personitas importantes
en mi vida: Vale, Sofi y Sebas.
6
LISTA DE CONTENIDO
LISTA DE CONTENIDO ..................................................................................................... 7
LISTA DE FIGURAS ........................................................................................................ 10
LISTA DE TABLAS........................................................................................................... 11
SISTEMA PROTOTIPO DE TELEMONITOREO PARA PACIENTES, USANDO
TECNOLOGÍAS INALAMBRICAS SEMIMÓVILES DE COMUNICACIÓN .......................... 12
RESUMEN ....................................................................................................................... 12
1. INTRODUCCION ........................................................................................................ 13
2. MARCO TEORICO ...................................................................................................... 16
2.1. TELEMEDICINA.................................................................................................. 16
2.1.1. Definición...................................................................................................16
2.2. CONCEPTOS MEDICOS....................................................................................... 17
2.2.1. Patología....................................................................................................17
2.2.2. Frecuencia Cardiaca ....................................................................................17
2.2.3. Saturación de oxígeno .................................................................................17
2.2.4. Historia Clínica............................................................................................18
2.3. REDES Y COMUNICACIONES............................................................................... 18
2.3.1. Comunicación Semimóvil .............................................................................18
2.3.2. Red de comunicación LATCOM/CWS S.A. ......................................................19
2.4. HERRAMIENTAS DE DESARROLLO....................................................................... 20
2.4.1. Open CV ....................................................................................................20
2.4.2. GOCR.........................................................................................................21
3. DESCRIPCIÓN DEL SISTEMA ...................................................................................... 22
3.1. ENTRADAS Y SALIDAS DEL SISTEMA PROTOTIPO DE TELEMONITOREO ................ 23
3.2. DESCRIPCIÓN DEL LUGAR REMOTO.................................................................... 24
3.2.1. ELEMENTOS DEL LUGAR REMOTO................................................................25
3.3. DESCRIPCIÓN DE LA RED DE COMUNICACIONES................................................. 28
3.4. DESCRIPCIÓN DEL SERVIDOR CENTRAL.............................................................. 29
3.4.1. Elementos del Servidor Central.....................................................................30
7
4. ESPECIFICACIONES ................................................................................................... 34
4.1. LUGAR REMOTO................................................................................................ 34
4.1.1. Cámara ......................................................................................................34
4.1.2. Equipo de adquisición de imágenes ..............................................................35
4.1.3. Equipo de comunicaciones ...........................................................................35
4.2. RED DE COMUNICACIONES ................................................................................ 36
4.3. SERVIDOR CENTRAL .......................................................................................... 36
5. DESARROLLOS .......................................................................................................... 38
5.1. LUGAR REMOTO................................................................................................ 38
5.2. SISTEMA DE COMUNICACIONES ......................................................................... 41
5.2.1. Criterios de Diseño......................................................................................... 41
5.2.2. Funcionamiento y Características..................................................................... 42
5.3. SERVIDOR CENTRAL .......................................................................................... 44
5.3.1. Conversor de Imágenes.................................................................................. 44
5.3.2. Control.......................................................................................................... 49
5.3.3. Base de Datos ............................................................................................51
5.3.4. Servidor FTP, Servidor Apache y Sitio Web ....................................................52
5.3.5. Problemas Implementación..........................................................................53
6. ANALISIS DE RESULTADOS ........................................................................................ 57
6.1. RESULTADOS OBTENIDOS ETAPA DE INVESTIGACIÓN......................................... 57
6.1.1. Estudio No 1 “Estudio para la definición del Hospital Virtual”...........................57
6.1.2. Estudio No 2 “Estudio de tecnologías de comunicaciones inalámbricas
Semimóviles”..............................................................................................................58
6.1.3. Estudio No 3 “Estudio de las tecnologías disponibles para efectuar medición de
signos vitales partiendo del concepto de Hospital Virtual” ...............................................58
6.1.4. Estudio No 4 “Estudio comparativo Hospital Virtual y otras implementaciones de
monitoreo”.................................................................................................................59
6.2. RESULTADOS OBTENIDOS ETAPA DE IMPLEMENTACIÓN...................................... 59
6.3. Inconvenientes Operacionales ......................................................................63
6.4. POSIBLES MEJORAS........................................................................................... 63
6.5. ANALISIS DE COSTOS........................................................................................ 67
6.5.1. Aproximación costos de desarrollo e implementación .....................................67
8
6.5.2. Aproximación Costos de Producción..............................................................69
7. CONCLUSIONES ........................................................................................................ 73
8. BIBLIOGRAFIA Y FUENTES DE INFORMACIÓN ............................................................. 75
9. ANEXOS.................................................................................................................... 77
9
LISTA DE FIGURAS
Figura 1 - Esquema Red LATCOM/CWS S.A.......................................................................... 20
Figura 2. Diagrama general del SPT .................................................................................... 22
Figura 3. Diagrama de Entradas y Salidas ............................................................................ 23
Figura 4. Diagrama de Bloques Lugar Remoto...................................................................... 24
Figura 5. Diagrama de Entradas y Salidas del....................................................................... 25
Figura 6. Diagrama de Entradas y Salidas de la .................................................................... 26
Figura 7. Diagrama de Entradas y Salidas del....................................................................... 26
Figura 8. Diagrama de Entradas y Salidas del....................................................................... 27
Figura 9. Diagrama de Bloques Sistema de Comunicaciones. ................................................. 28
Figura 10. Diagrama de Bloques Servidor Central ................................................................. 29
Figura 11. Diagrama de Entradas y Salida de la Carpeta de Imágenes.................................... 31
Figura 12. Diagrama de Entradas y Salidas del Control.......................................................... 31
Figura 13. Diagrama de Entradas y Salidas Conversor de Imágenes. ...................................... 32
Figura 14. Diagrama de Entradas y Salidas de Base de Datos. ............................................... 32
Figura 15. Diagrama de Entradas y Salidas .......................................................................... 33
Figura 16. Servidor Central. ................................................................................................ 36
Figura 17. Diagrama de la Red de Comunicaciones. .............................................................. 43
Figura 18. Vectores Imagen................................................................................................ 46
Figura 19. Vector Intensidad............................................................................................... 46
Figura 20. Muestra Base de Datos GOCR. ............................................................................ 48
Figura 21. Diagrama de flujo Bloque de Control función 1. .................................................... 50
Figura 22. Diagrama de flujo Bloque de Control función 2. .................................................... 50
Figura 23. Instrucción CGI.................................................................................................. 52
Figura 24. Imágenes incompletas........................................................................................ 53
Figura 25. Imagen con error de procesamiento. ................................................................... 55
Figura 26. Imágen desincronizada....................................................................................... 56
Figura 27. Gráfica de Oximetría sin suministro de oxigeno..................................................... 60
Figura 28. Gráfica Ritmo Cardiaco sin suministro de oxigeno. ................................................ 61
10
LISTA DE TABLAS
Tabla 1. Distribución Base de Datos GOCR........................................................................... 48
Tabla 2. Datos Oximetría y Ritmo Cardiaco sin suministro de oxigeno. ................................... 61
Tabla 3. Resultados Caso de Estudio. .................................................................................. 62
Tabla 4. Costos Desarrollo Sistema Prototipo. ...................................................................... 67
Tabla 5. Costos Recursos Humanos..................................................................................... 68
Tabla 6. Costos Recursos Físicos. ........................................................................................ 68
Tabla 7. Costos Implementación Sistema Prototipo............................................................... 69
Tabla 8. Resumen Totales. ................................................................................................. 70
Tabla 9. Análisis Ganancias por Lugar Remoto. .................................................................... 70
Tabla 10. Inversión y Ganancias con implementación de 50 Puntos........................................ 71
Tabla 11. Inversión y Ganancias implementación de 250 Lugares Remotos............................. 71
Tabla 12. Resumen Costos Mensuales por Lugar Remoto y Ganancias Netas........................... 71
11
SISTEMA PROTOTIPO DE TELEMONITOREO PARA
PACIENTES, USANDO TECNOLOGÍAS INALAMBRICAS
SEMIMÓVILES DE COMUNICACIÓN
Alejandro Gutiérrez M
Nelson N. Henríquez C
William F. Rodríguez C
Grupo trabajo de grado Sistema Prototipo Telemonitoreo (SPT)
Facultad de Ingeniería Electrónica
Pontificia Universidad Javeriana
RESUMEN Se presenta el informe final que pública los conceptos y teorías más importantes utilizadas para
el desarrollo del proyecto titulado Sistema Prototipo de Telemonitoreo para Pacientes, Usando
Tecnologías Semimóviles Inalámbricas, y muestra el funcionamiento del sistema, las pruebas
realizadas a través de su desarrollo y los resultados completos de la totalidad del proyecto.
12
1. INTRODUCCION
La situación actual del sector salud en Colombia es crítica, existen problemas que causan
ineficiencia en los procesos de atención y mala calidad en la prestación de los servicios de salud.
Algunas de las problemáticas que afectan este sector, se deben a la congestión de pacientes en
clínicas y hospitales, según estadísticas del Organismo Andino de Salud1, en Colombia, el número
de camas hospitalarias por cada mil habitantes esta entre 1.5 y 1.7. Este problema se agrava
cuando la inversión del país, en el sector salud es muy limitada, según estadísticas del DANE2
solamente un 0.38 % del PIB total del país es destinado para mejorar los servicios de asistencia
hospitalaria.
Esta problemática genera la necesidad de mejorar la eficiencia de los servicios médicos en
beneficio de la calidad de atención de los pacientes, focalizando los recursos disponibles. El
desarrollo e implementación de diferentes proyectos tecnológicos, apoyados en el conocimiento
médico pueden contribuir a resolver la problemática del sector salud. Centralización de datos,
digitalización de resultados y monitoreo remoto son algunas de las áreas donde estos desarrollos
pueden ser de vital importancia para generar soluciones y transformar la forma como se
manejan los procesos de atención en clínicas y hospitales, mejorando así la calidad de servicio,
optimizando recursos y reduciendo costos.
Para tratar de solucionar esta problemática desde la perspectiva de la Ingeniería se decidió
utilizar el concepto de monitoreo remoto, que permite extender las funcionalidades y
capacidades del hospital tradicional al hogar de los pacientes. Para hacer esto una realidad era
necesario conocer y familiarizarse con los aspectos médicos que debían tenerse en cuenta, como
son: el conocimiento de la telemedicina, ventajas y desventajas de sistemas de telemonitoreo,
posibles patologías monitoreables remotamente, signos vitales que se deben monitorear. De
manera que se realizó una primera investigación denominada Estudio para la Definición del
Concepto de Hospital Virtual, soportada por entrevistas y encuestas a personas del sector de
1 Para más información Ver anexo A, Titulado Estudio Telemedicina Región Andina. 2 Para ampliar información referirse a Página en Internet del DANE (Departamento Administrativo Nacional de Estadística), www.dane.gov.co.
13
salud3. Con este estudio se obtuvieron modelos de atención que reúnen información acerca de
las patologías monitoreables remotamente, los signos vitales que se deben monitorear, unas
condiciones del estado del paciente (ejemplo: paciente con inmovilidad total) y unos
requerimientos técnicos que se ajusten a estas necesidades.
Al monitorear los datos de forma remota, era necesario ubicarlos en un lugar central, para ello
se requería contar con un sistema de comunicaciones que conectará cada lugar de monitoreo
(hogar del paciente), con la central de datos. A partir de esto se decidió crear un estudio que
permitiera conocer, analizar, describir y comparar las tecnologías de comunicaciones disponibles
en el país, que se adaptaran con los requerimientos técnicos que se describieron en los modelos
de atención del primer estudio4. Para la realización de este segundo estudio, se contó con el
apoyo de la empresa colombiana de telecomunicaciones LATCOM/COMUNICAR S.A.5, que cuenta
con una red de comunicaciones a nivel metropolitano en las principales ciudades del país, y se
enfoca en crear servicios y aplicaciones de valor agregado que aprovechen las ventajas
tecnológicas de su red.
También fue necesario conocer los equipos médicos utilizados en hospitales y clínicas para hacer
mediciones de signos vitales. Se realizó un tercer estudio con el fin de conocer, identificar
características y comparar equipos médicos de medición de signos vitales en algunos hospitales
de Bogota, además de su posibilidad de integración con los requerimientos de los modelos de
atención.
Teniendo los resultados de los tres estudios y con el fin de validarlos, se decidió implementar un
sistema de monitoreo remoto, usando alguno de los modelos de atención, una tecnología de
comunicación en particular y un equipo médico para la medición de los signos vitales. En este
punto se contó con la asesoría del Dr. Juan Manuel Lozano (Director del Centro de Epidemiología
del Hospital San Ignacio), quien tenía una necesidad en particular en su área de especialización,
la cuál se adaptaba a uno de los modelos de atención descritos en el primer estudio. La
necesidad según el Dr. Juan Manuel Lozano era monitorear niños en la ciudad de Bogotá quienes
a menudo presentan problemas respiratorios y pulmonares. La mayoría de estos niños requieren
3 Para información de las encuestas y entrevistas, ver Anexo B, Estudio para la Definición de Hospital Virtual. 4 Para mayor información del Estudio de tecnologías de comunicaciones, Ver Anexo E. 5 Para mayor información consultar en www.latcom.com.co – www.comunicar.com.co.
14
del suministro de oxigeno y de terapias respiratorias para tratar su dolencia. Durante el
tratamiento que se le da a esta patología, el médico pierde cualquier contacto con su paciente y
solo lo vuelve a ver el día del control. La problemática que surge con este tipo de procedimiento
es que el especialista médico, no sabe si al niño se le esta administrando correctamente el
oxigeno o bien el niño se recupera en un tiempo menor a la cita de control, por lo cual se le esta
administrando oxigeno de manera innecesaria, que puede ser perjudicial para su salud. Dado
este hecho, sería muy útil para un pediatra poder monitorear de manera remota y regular a su
paciente con el fin de valorar su estado de salud durante el tratamiento. También este tipo de
solución permite a investigadores como el Doctor Juan Manuel Lozano, realizar análisis y
estudios a partir de la estadísticas obtenidas con el monitoreo.
La implementación de este sistema se realizó mediante el diseño de una solución no invasiva que
permite sin manipular internamente el equipo medico, capturar los datos, a través de la toma de
imágenes de la pantalla de visualización, los cuáles se envían por una red de comunicaciones a
un sistema central que procesa, almacena y presenta la información adquirida.
En una etapa posterior se realizó un estudio comparativo con el fin de identificar las principales
ventajas y desventajas entre algunos proyectos de telemedicina implementados actualmente en
el país y el propuesto en este proyecto.
El presente informe recopila los resultados obtenidos durante el desarrollo del proyecto
denominado “Sistema prototipo de telemonitoreo de pacientes, usando tecnologías inalámbricas
de comunicación semimóvil” (SPT), con el cual se busca demostrar la posibilidad de implementar
y poner en marcha un sistema de telemonitoreo en el área de la salud. Este proyecto ha sido
desarrollado como trabajo de grado por estudiantes de Ingeniería Electrónica de la Pontificia
Universidad Javeriana y con el apoyo económico y tecnológico del Grupo Empresarial
LATCOM/CWS S.A. (Latinoamericana de Comunicaciones/Comunicar Wireless Services), grupo de
empresas colombianas del sector de las telecomunicaciones.
15
2. MARCO TEORICO
A continuación se presentan los conocimientos teóricos básicos necesarios para el entendimiento
de este documento. Algunos de los conceptos serán referenciados a los anexos de este informe.
2.1. TELEMEDICINA
Para familiarizar rápidamente al lector con el concepto global en el cual se enmarca este
trabajo, se han estructurado cuatro conceptos básicos acerca de la telemedicina y su
implementación en el país.
2.1.1. Definición
Mucho se ha dicho sobre lo que es la telemedicina, a continuación se presenta el concepto
expuesto por la Organización Mundial de la Salud (OMS)6, organismo de las naciones unidas
especializado en salud.
“La telemedicina es el suministro de atención sanitaria, en cuanto la distancia constituye un
factor critico, por profesionales que apelan a las tecnologías de la información y de la
comunicación con el objeto de intercambiar datos, para hacer diagnósticos, preconizar
tratamientos y prevenir enfermedades y heridas, así como para la formación permanente de los
profesionales de atención de salud y en actividades de investigación y evaluación, con el fin de
mejorar la salud de las personas y las comunidades en que viven.”7
6 Para mayor información referirse a la Organización Mundial de la Salud en Página de Internet. www.oms.org. 7Definición adoptada por un grupo consultivo internacional reunido por la OMS en Ginebra en diciembre de 1998.[OMS 98]
16
2.2. CONCEPTOS MEDICOS
2.2.1. Patología
Literalmente, patología es el estudio (logos) del sufrimiento (Pathos). De forma mas especifica
es una disciplina que se dedica al estudio de los cambios estructurales y funcionales de las
células, tejidos y órganos que son la base de la enfermedad. Mediante el uso de técnicas
moleculares, microbiológicas, inmunológicas y morfológicas, la anatomía patológica intenta
explicar los por que de los signos y síntomas manifestados por los pacientes, a la vez que
proporciona un fundamento sólido para una asistencia y tratamiento clínico racional.8
2.2.2. Frecuencia Cardiaca
En el intervalo de tiempo de un minuto ocurre un determinado número de latidos y a esto se le
denomina frecuencia cardiaca. El corazón se ajusta a las necesidades del organismo, variando la
frecuencia cardiaca. Es así como en condiciones normales ocurren cambios de la frecuencia
cardiaca en un aumento o decremento según la situación, esta aumenta con el ejercicio físico y
las emociones, y disminuye con el reposo.
Los latidos del corazón se generan espontáneamente y de manera automática en una estructura
cardiaca denominada nodo sinusal, que se encuentra en la aurícula derecha. Este es el
marcapasos natural del corazón y rige o comanda el ritmo cardiaco;9 Los valores normales de
frecuencia cardiaca dependen de la edad.10
2.2.3. Saturación de oxígeno
Este es un parámetro que expresa la cantidad de oxigeno que se combina, en el sentido químico,
con la hemoglobina, para formar la oxihemoglobina que es la que transporta el oxígeno en
sangre hacia los tejidos. Al medir la saturación de oxigeno estamos midiendo la cantidad de
oxigeno que se encuentra combinada con la hemoglobina, es por eso que esta medida es una 8 Robines, Patología estructural y funcional. Cotran, Ramzi Md. Kumar, Vinay Md., Collins, Tucker Md. Sexta Edición. McGraw Hill. 9 Tomado de la pagina de Internet http://www.suarritmia.com/ 10 Para mayor información consultar, Anexo D.
17
medida relativa y no absoluta ya que no indica la cantidad de oxigeno en sangre que llega a los
tejidos, sino la relación que hay entre la cantidad de hemoglobina presente y la cantidad de
hemoglobina combinada con oxigeno. Este parámetro se puede sensar, dado que la cantidad de
oxihemoglobina esta relacionada con la coloración roja de la sangre, siendo esta mas fuerte
cuanto más oxihemoglobina contiene la sangre y mas tenue cuanta menos oxihemoglobina hay
presente.11
Los valores típicos de la saturación de oxigeno generalmente oscilan entre 95% y 97% y sobre
este valor varían en un rango del 2%; se considera una medición por debajo del 90% asociada a
una patología de insuficiencia respiratoria.
2.2.4. Historia Clínica
Es un proceso de recolección de datos de forma ordenada y clara acerca del estado actual del
paciente, y de su estado pasado, así como sus antecedentes personales de otras enfermedades,
antecedentes familiares (presencia de enfermedades hereditarias), aspectos sociales, síquicos.
Esta fuente de información permite en ocasiones el diagnostico de enfermedades además de
elementos de juicio para la toma de decisiones y la ejecución de acciones sobre una enfermedad
o patología. Es un documento privado sometido a reserva, que únicamente puede ser conocido
por el medico, o por terceros, previa autorización del paciente.12
2.3. REDES Y COMUNICACIONES
2.3.1. Comunicación Semimóvil
Se considera una tecnología de comunicación semimóvil aquella con la cual se puede establecer
un enlace inalámbrico de comunicación con protocolo IP (Punto a punto o punto multipunto) con
procesos de logística y operación reducidos. Es decir, los tiempos de instalación y de puesta a
puntos son mucho menores frente a otros sistemas de comunicación (Ej.: Enlace en fibra
óptica). Además de estas características tienen la propiedad de proveer al usuario final un enlace
de comunicación en sitios donde las tecnologías tradicionales no se encuentran presentes.
11 Para mayor información consultar, Anexo C. 12 Tomado de la pagina de Internet http://www.sccot.org.co
18
2.3.2. Red de comunicación LATCOM/CWS S.A.
Este es el sistema que permite la comunicación entre el lugar remoto y la central de monitoreo.
Para este trabajo de grado se cuenta con la red de la empresa colombiana de
telecomunicaciones LATCOM/CWS S.A., que tiene un cubrimiento total del área metropolitana de
Bogotá, ya que dispone de once nodos distribuidos estratégicamente en la ciudad y de un nodo
central ubicado en las instalaciones de la empresa. LATCOM actualmente es una red de
protocolo IP de nivel 2 y 3, que maneja tecnologías de comunicación alambrada e inalámbrica.
Entre las alambradas cuenta con fibra óptica y ADSL, y entre la inalámbricas con GPRS, CDMA
1x, CDPD, GSM, WiPLL, Vía Radio, enlace satelital; con conexiones punto a punto y punto-
multipunto, ofreciendo servicios de banda ancha en las soluciones que lo requieren. Como se
muestra en la figura 1, LATCOM/CWS posee una red inalámbrica de banda ancha en la ciudad de
Bogotá constituida por siete nodos estratégicamente distribuidos.
Los nodos de la red LATCOM están estructurados de tal forma que pueden soportar la migración
a nuevas tecnologías como WiMAX y LMDS que son tecnologías que requieren de una
modulación especial.
En la actualidad la red de LATCOM13 presta servicios de comunicación con diferentes soluciones
a empresas como SERVIBANCA, VISA, REDEBAN, TRASMILENIO, SUPERVIEW, entre otras.
13 Para mayor información consultar Pagina de Internet www.latcom.com.co – www.comunicar.com.co.
19
Figura 1 - Esquema Red LATCOM/CWS S.A.
2.4. HERRAMIENTAS DE DESARROLLO
2.4.1. Open CV
Open CV es una librería para C++ de código abierto, creada por Intel Corporation, como parte
de su producto Intel Performance Primitives, esta librería esta orientada hacia desarrollos con
imágenes en tiempo real y esta constituida por una serie de funciones para el manejo de
imágenes. Entre algunas de las áreas donde esta librería puede ser útil son HCI (Human
Computer Interphase), reconocimiento de objetos, reconocimiento de movimiento etc. Esta
librería cuenta con funciones que van desde el manejo básico de ventanas para realizar
20
interfases con el usuario hasta complejas funciones que manejan estructuras para el
reconocimiento de patrones14.
2.4.2. GOCR
GOCR es un programa de OCR (Optical Character Recognition) de fuente abierta, cuyo núcleo ha
sido desarrollado por Joerg Schulenburg bajo licencia pública (GNU Public License, GPL) y ahora
es mejorado día a día por un equipo de desarrolladores liderado por el mismo. GOCR permite el
reconocimiento de caracteres a partir de imágenes escaneadas en blanco y negro. GOCR puede
ser compilado para ser utilizado con diferentes sistemas operativos, está en capacidad de
analizar diferentes formatos de imágenes y cuenta con una gran variedad de extensiones entre
las que se encuentra la posibilidad de generar una base de datos a partir de series de imágenes
para mejorar su desempeño15.
14 Para mayor información consultar bibliografía acerca del tema de OPEN CV. 15 Para mayor información consultar bibliografía acerca del tema de GOCR.
21
3. DESCRIPCIÓN DEL SISTEMA
Se implementó un sistema de monitoreo remoto constituido por tres bloques principales,
denominados lugar remoto, sistema de comunicaciones y servidor central16 , interconectados
entre sí como se muestra en la figura 2. La idea principal es capturar los datos del equipo
médico que se conecta al paciente que se encuentra bajo monitoreo y esta ubicado en su hogar
(lugar remoto), transportar dichos datos mediante un sistema de comunicaciones y procesarlos,
almacenarlos y organizarlos en un sistema central (Servidor Central). El sistema central cuenta
con una conexión hacia Internet que le permite al médico, la creación de historias clínicas,
configuración de toma de horarios de muestras, configuración del tipo de suministro de oxigeno
y la consulta por medio de tablas y gráficas de los datos de monitoreo de su paciente. Cada uno
de los pacientes ubicados en diversos lugares remotos, cuenta con el monitoreo de las
mediciones que efectúen los equipos médicos que los están sensando, de acuerdo a un horario
especifico configurado por el médico. A estas horas especificas, se tomarán las mediciones que
actualizarán la base de datos del servidor central, permitiendo así la consulta de dichas muestras
por clientes Web autorizados (médico especialista encargado).
LUGAR REMOTO
RED DE COMUNICACIONES
SERVIDOR CENTRAL
MEDICOCliente Web
PACIENTE
Figura 2. Diagrama general del SPT
16 Para información respecto a los criterios de diseño de los bloques del sistema ver en Sección 6. Desarrollos.
22
La captura de la medición de los equipos médicos, se realiza mediante la toma de imágenes de
los “display” de dichos equipos17, que indican con números digitales el comportamiento de cierto
signo vital. Estas imágenes son analizadas mediante un tipo de tratamiento de imágenes18, que
permite la interpretación digital de las mismas.
3.1. ENTRADAS Y SALIDAS DEL SISTEMA PROTOTIPO DE
TELEMONITOREO
Las señales de entrada y salida del sistema prototipo de telemonitoreo (SPT), se muestran en la
figura 3 y se enuncian a continuación:
Las entradas del sistema son:
Señales de signos vitales.
Configuración Lugares Remotos.
Solicitud de Información por parte del Usuario.
Las salidas de sistema son:
Información Signos Vitales.
Alarmas que anuncian anomalías en los niveles normales de los signos medidos.
SISTEMA PROTOTIPO DE TELEMONITOREO
Señales de signos vitales
Configuración Lugares Remotos
Solicitud de información por parte del usuario
InformaciónSignos Vitales
Alarmas que anuncian anomalías en los niveles normales de los signos
Figura 3. Diagrama de Entradas y Salidas
17 El criterio de toma de imágenes se encuentra en Sección 6. Desarrollos. 18 Para información respecto al tratamiento de imágenes ver Sección 6. Desarrollos.
23
A continuación se hace una descripción de los tres bloques que componen el sistema
implementado.
3.2. DESCRIPCIÓN DEL LUGAR REMOTO
El lugar remoto, cuyo diagrama de bloques se muestra en la figura 4, es la estación que
generalmente se encuentra ubicada en el hogar del paciente o en donde se quiere extender las
capacidades del hospital. Con esta estación se busca cumplir las siguientes funciones:
Medir los signos vitales del paciente.
Capturar y digitalizar los datos medidos en el paciente.
Transmitir los datos medidos en el paciente.
RED DE
COMUNICACIONES
PACIENTEEquipo Médico de
Medición(Pulsioximetro)
Display(Pantalla de
Visualización)
Cámara análoga
Equipo adquisiciónImágenes
Sistemas de Comunicaciones
Entrada
Salida
Signos Médicos en Pantalla de
Visualización
Imagen comprimida con
encabezados GPRS
EntradaInstrucciones
Servidor Central con encabezados
GPRS
Figura 4. Diagrama de Bloques Lugar Remoto.
24
3.2.1. ELEMENTOS DEL LUGAR REMOTO
Para cumplir con estos requerimientos se utilizaron los siguientes elementos en el lugar remoto.
3.2.1.1. Equipo Médico
Para la solución en particular se utilizó un oximetro de pulso Palco 30019, que mide la
saturación de oxigeno y la frecuencia cardiaca, estos los muestra por medio de una
pantalla de visualización. El diagrama de entradas y salidas del equipo médico se
muestra en la figura 5, que aparece a continuación.
Equipo Médico de Medición
(Pulsioximetro)
Display(Pantalla de
Visualización)Entrada SalidaSignos Vitales
Medidos* Oximetria de Pulso
* Frecuencia Cardiaca
Signos Médicos en Pantalla de
Visualización
Figura 5. Diagrama de Entradas y Salidas del
Equipo Médico.
3.2.1.2. Cámara Análoga
Para capturar los datos que mide el equipo médico, se eligió un método no invasivo de
captura de datos20, adquiriendo imágenes de la pantalla de visualización del oximetro
por medio de una cámara análoga convencional21, el diagrama de entradas y salidas de
la cámara análoga se presenta en la figura 6.
19 Para las especificaciones del equipo médico se puede consultar en Anexo J. Lugar Remoto descripción y especificaciones equipos. 20 Para información de los métodos y criterios de diseño de captura de datos ver Sección 6. Desarrollo. 21 Las especificaciones de la cámara análoga se pueden consultar en Anexo J. Lugar Remoto descripción y especificaciones equipos.
25
Cámara análogaEntrada
Signos Médicos en Pantalla de
VisualizaciónSalida
Imágen digitalizada
EntradaInstrucciones de
Equipo de Adquisición
Figura 6. Diagrama de Entradas y Salidas de la
Cámara Análoga.
3.2.1.3. Equipo de adquisición de Imágenes
La cámara análoga se acopla al equipo de adquisición de imágenes 22 , que es el
encargado de ordenar la toma de la imagen en cierto instante y comprimirla en el
formato JPEG. Este equipo de adquisición también cumple la función de convertir las
imágenes al protocolo IP. A continuación en la figura 7, se tiene el diagrama de entradas
y salidas del equipo de adquisición de imágenes.
Equipo Adquisición
ImágenesEntrada
Salida
Imágen Digitalizada
Instrucción de toma de
Imagen
SalidaImágen
comprimida en puerto Ethernet
10-100
EntradaInstrucciones
Servidor Central
Figura 7. Diagrama de Entradas y Salidas del
Adquisición de Imágenes.
22 Las especificaciones del equipo de adquisición de imágenes se encuentran en Anexo J. Lugar Remoto y descripción y especificaciones equipos.
26
3.2.1.4. Sistemas de Comunicaciones
El medio de comunicaciones se conecta directamente al equipo de adquisición de
imágenes. Para la implementación del sistema prototipo se utilizó un modem de
comunicaciones23 GPRS, por el cual se hace el transporte de las imágenes empaquetadas
bajo protocolo IP24 y con encabezados GPRS25. Este sistema de comunicaciones también
recibe las instrucciones desde el servidor central, referente a configuración de horarios
de tomas26. A continuación en la figura 8, se presenta el diagrama de entradas y salidas
del Sistema de Comunicaciones
Sistemas de Comunicaciones
EntradaImágen
comprimida en puerto Ethernet
10-100
SalidaImágen
comprimida con encabezados
GPRS
EntradaInstrucciones
Servidor Central con encabezados
GPRS
SalidaInstrucciones
Servidor Central
Figura 8. Diagrama de Entradas y Salidas del
Sistema de Comunicaciones.
23 Los criterios de elección del sistema de comunicaciones se encuentran explicados en la Sección 6. Desarrollos. 24 Para información referente a protocolo IP, referirse a Anexo I. Marco Teórico (Ampliación). 25 Para información referente a tecnología de comunicaciones GPRS, referirse a Anexo E. “Estudio de Tecnologías de Comunicaciones Inalámbricas”. 26 Los horarios de tomas se explican en Anexo H, Manuales y Procedimientos.
27
3.3. DESCRIPCIÓN DE LA RED DE COMUNICACIONES
INTERNET
RED GPRS
ROUTER DE ENTRADA
SWITCH CONCENTRADOR
ROUTER SALIDA
Lugar Remoto1
Cliente WEB 1
SERVIDOR CENTRAL
EntradaImágen Comprimida con
encabezados GPRS
SalidaInstrucción Servidor
Central con encabezados GPRS
SalidaImágen Comprimida
Entrada
Entrada
Instrucción Servidor Central
Consulta Sitio Web
EntradaRequerimiento
Cliente Web
SalidaConsulta Sitio Web
SalidaRequerimiento Cliente
Web
Figura 9. Diagrama de Bloques Sistema de Comunicaciones.
La red de comunicaciones, cuyo diagrama de Bloques se muestra en la figura 9, es la encargada
de conectar los posibles Lugares Remotos con el Servidor Central, para ello se diseñó e
implementó una red de conexión que cumpliera con los requerimientos de conectividad del
Sistema Prototipo de Telemonitoreo, que se definen en la Sección de desarrollos. Con este
sistema se busca cumplir las siguientes funciones:
Transporte de Imágenes desde los Lugares Remotos hacia el Servidor Central.
Transporte de Instrucciones desde el Servidor Central a cada uno de los Lugares
Remotos.
Conexión entre los clientes Web y el servidor central para consulta de información y
configuración de horarios de toma de datos.
28
3.4. DESCRIPCIÓN DEL SERVIDOR CENTRAL
RED DE
COMUNICACIONES
CONTROL
BASEDE
DATOS
CONVERSIONDE
IMAGENES
CARPETA DE IMAGENES
SISTEMAS DERECEPCION YTRANSMISION
APLICACIONWEB SERVIDOR
WEB
EntradaSalidaImágen Comprimida Instrucciones
Servidor Central
Figura 10. Diagrama de Bloques Servidor Central
29
El Servidor Central, cuyo diagrama de Bloques se muestra en la figura 10, es el sistema que
procesa, almacena y pública a clientes Web la información capturada en los lugares remotos de
cada uno de los pacientes. En términos generales las imágenes, de la pantalla de visualización
proveniente del lugar remoto, son almacenadas y procesadas mediante un tratamiento de
imágenes que se explicará en la Sección de desarrollos. Con el procesamiento se obtiene la
información de los signos vitales del paciente en código ASCII (que viene en las imágenes), los
cuáles se colocan en un registro que tiene una correspondencia con el paciente monitoreado.
Con estos datos se generan tablas y gráficas que muestran los niveles de la saturación de
oxígeno y la frecuencia cardiaca.
Con este sistema se busca cumplir las siguientes funciones:
Almacenar las Imágenes de la pantalla de visualización del equipo médico ubicado en el
lugar remoto.
Aplicar un tratamiento de conversión de imágenes.
Almacenar los resultados de la conversión de imágenes.
Generación de tablas y gráficos mostrando los resultados obtenidos de la conversión de
imágenes.
Publicación de los datos a través del servidor Web.
3.4.1. Elementos del Servidor Central
Para cumplir con los requerimientos del servidor central se utilizaron los siguientes bloques
específicos.
3.4.1.1. Carpeta de Imágenes.
En la carpeta de Imágenes se almacenan en primera instancia las imágenes que vienen
del lugar remoto, mediante el protocolo FTP 27 . Continuamente el control revisa la
existencia de Imágenes en esta carpeta, con el fin de ejecutar el proceso de conversión
de imágenes sobre estas, este procedimiento esta explicado en la sección de desarrollos.
El diagrama de entradas y salidas se muestra a continuación en la figura 11.
27 Para información referente al protocolo FTP, consultar Anexo I. Marco Teórico (Ampliación).
30
CARPETA DE IMAGENES
Entrada
Entrada
Imágen comprimida
Revision por parte del control
SalidaImágen comprimida
Figura 11. Diagrama de Entradas y Salida de la Carpeta de Imágenes.
3.4.1.2. Control.
El control es un programa que se encarga de las siguientes funciones:
Revisa periódicamente en la carpeta de imágenes las imágenes a ser procesadas
por el conversor.
Ejecuta el proceso de conversión de imágenes.
Envía las instrucciones de configuración28 hacia los lugares remotos.
El diagrama de entradas y salidas del control, se muestra en la figura 12.
CONTROL
SalidaRevisión Carpeta
de Imágenes
SalidaRevisión Base
de Datos
SalidaInstrucción hacia
Lugar Remoto
EntradaInformación Base de datos Horarios
de Toma
SalidaInstrucción Conversor
de Imágenes
Figura 12. Diagrama de Entradas y Salidas del Control.
28 Las instrucciones de configuración se explican en la Sección 6, Desarrollos.
31
3.4.1.3. Conversor de Imágenes.
Es un modulo encargado de convertir las imágenes provenientes de los lugares remotos
a código ASCII, para su posterior análisis y manipulación. Este proceso se ejecuta
periódicamente según instrucciones del control central. La figura 13 muestra el diagrama
de entradas y salidas del conversor de imágenes.
CONVERSORDE
IMAGENES
EntradaInstrucción del control
con imagen comprimida
SalidaDatos ASCII
Obtenidos de Imágen
Figura 13. Diagrama de Entradas y Salidas Conversor de Imágenes.
3.4.1.4. Base de Datos.
Es el lugar donde se alojan las diferentes tablas y registros de la aplicación desarrollada
en MySQL. Su función es almacenar bajo reglas de relación, información referente a las
historias clínicas, datos de medición, horarios de monitoreo, información del personal
médico. La figura 14 muestra el diagrama de entradas y salidas de la base de datos.
BASEDE
DATOS
EntradaRevisión por
parte del control
EntradaDatos ASCII
Obtenido de Imágen
SalidaDatos hacia
aplicación Web
Figura 14. Diagrama de Entradas y Salidas de Base de Datos.
32
3.4.1.5. Aplicación y Servidor Web.
Es un programa de aplicación29 que cumple con los requerimientos realizados por los
clientes Web. Este servidor tiene salida a Internet con una IP pública, continuamente
intercambia datos con los clientes que hacen solicitudes a la aplicación. La figura 15
muestra el diagrama de entradas y salidas de la aplicación
APLICACIÓNY
SERVIDOR WEB
EntradaConsultas
Cliente Web
EntradaDatos válidos de Base de Datos
SalidaRespuesta
Clientes Web
SalidaRequerimieto aBase de Datos
Figura 15. Diagrama de Entradas y Salidas Aplicación y Servidor Web.
29 Aplicación se refiere al sitio Web.
33
4. ESPECIFICACIONES
A continuación se presentan las especificaciones mínimas que deben cumplir los equipos que
conforman el sistema para garantizar su funcionamiento.
4.1. LUGAR REMOTO
4.1.1. Cámara
• Resolución mínima 320x240 píxeles.
• Cámara a todo color (full color).
• La distancia a la pantalla de visualización debe estar entre 10 y 13 cm.
El sistema fue diseñado teniendo en cuenta que la mínima resolución de las cámaras
convencionales es 320x240 píxeles; el aumento de la resolución para esta aplicación no
implica una mejora en términos de reconocimiento de caracteres, por el contrario si
implica mayores costos en la transmisión de datos. La distancia de la cámara a la
pantalla de visualización debe ser controlada y cumplir con los límites establecidos, para
que el conversor pueda funcionar correctamente.
34
4.1.2. Equipo de adquisición de imágenes
• Soporte para conexión de cámaras (RCA, BNC, SVIDEO).
• Soporte para imágenes JPEG.
• Soporte de instrucciones remotas tipo CGI30.
• Salida de puerto de datos RS-232 o Ethernet 10/100.
• Soporte protocolos FTP y http.
Este equipo debe tener algún tipo de entrada para cámaras convencionales. El conversor
de imágenes puede procesar imágenes en cualquier formato de compresión, sin
embargo con el formato JPEG se garantiza un tamaño mínimo de la imagen. El servidor
central envía los comandos de configuración mediante “scripts” CGI. Este equipo debe
tener puertos de comunicación, para conectar con el medio. Debe tener también
capacidad de transferir las imágenes capturadas mediante protocolo FTP.
4.1.3. Equipo de comunicaciones
• Homologado para funcionar en la red GSM/GPRS de Comcel.
• Modo de conexión PPP.
• Soporte de protocolo TCP/IP.
De acuerdo a la red de comunicaciones implementada, se tiene una conexión con el
proveedor celular Comcel, sobres su plataforma de datos GPRS. Se debe tener una
conexión de tipo “Dial Up” PPP, además que los datos deben estar sobre protocolo TCP.
Aunque GPRS es una tecnología que presenta tiempos de retardo promedios de 800 ms,
estos no afectan el transporte de las imágenes y se garantiza unas perdidas de
imágenes mínimas31.
30 CGI de las siglas Common Gateway Interface. 31 Las estadísticas del error por perdida de información se muestran en la sección de resultados.
35
4.2. RED DE COMUNICACIONES
La red de comunicaciones solamente esta limitada en tres parámetros concretos:
• Soporte protocolo TCP/IP.
• El ancho de banda del canal entre la red GPRS y el servidor debe de ser igual o
mayor a la ofrecida por GPRS.
• El ancho de banda del canal de Internet, limita la velocidad de consulta de la
aplicación Web.
4.3. SERVIDOR CENTRAL
Figura 16. Servidor Central.
• Procesador Pentium II de 400 MHz o compatible.
Aunque las anteriores son las especificaciones mínimas para instalar y ejecutar los
• Disco duro de mínimo 10 GB.
• Memoría de mínimo 192 MB.
programas utilizados en el desarrollo (Linux Fedora Core 3, Apache Web Server, PHP
4.0.3, MySQL), es recomendable utilizar un equipo de características superiores a las
mínimas. Además teniendo en cuenta que este servidor va a funcionar manejando una
operación crítica, elementos redundantes como fuente de poder, procesador, discos de
almacenamiento, memoria RAM son de gran valor para la protección e integridad de los
36
datos. Teniendo en cuenta estas recomendaciones el equipo (figura 16) implementado
en la solución, tiene características muy superiores a las mínimas32.
32 Para información de las especificaciones del equipo servidor central, ver Anexo J.
37
5. DESARROLLOS
A partir de los resultados obtenidos de los tres estudios iniciales, unas necesidades ya
establecidas por el especialista médico (Dr. Juan Manuel Lozano) y un interés por parte de
LATCOM/COMUNICAR S.A. se inició el planteamiento de una solución de Ingeniería. Esta se
trabajó como una etapa preliminar de un posible sistema de telemonitoreo, de manera que la
solución que aquí se plantea solo busca arrojar resultados que comprueben y validen el concepto
general del monitoreo remoto de signos vitales.
Se tienen inicialmente el planteamiento de unos modelos de atención del primer estudio,
comparando estos con la patología sugerida por el Dr. Juan Manuel Lozano, se puede observar
que su necesidad particular, se encuentra enmarcada dentro del modelo de atención 1 del
estudio33. Este modelo sugiere básicamente el monitoreo de signos vitales como la saturación de
oxigeno, frecuencia respiratoria y frecuencia cardiaca. Para este caso especifico era necesario
medir la saturación de oxigeno. También el modelo muestra que el paciente puede ser
monitoreado regularmente (no continuo) y puede tener movilidad, lo que se adapta a las
necesidades. A nivel de requerimientos técnicos, la tecnología debe cumplir con características
como mínimo ancho de banda y tecnología con posibilidad de interrupciones.
5.1. LUGAR REMOTO
Como se explicó en la Sección de descripción, en el lugar remoto se adquieren los datos que
contienen la información de la oximetría de pulso y frecuencia cardiaca del paciente, para esto se
capturaron imágenes sobre la pantalla de visualización del equipo medico que mide estos signos,
con el fin de obtener la información. Esta decisión se tomó después de analizar los resultados
obtenidos del estudio de tecnologías de equipos médicos de medición34, con los cuales se pudo
concluir cómo la mayoría de Hospitales colombianos cuentan con equipos médicos de medición
de signos vitales que no tienen un sistema de comunicación de datos. Además que por factores
económicos no son fácilmente reemplazables. Estos dos factores llevaron a implementar una
solución donde se optimizaran recursos, en este caso, donde se pudieran utilizar los equipos
médicos con los que cuenta cualquier hospital.
33 Para información respecto al modelo de atención ver “Estudio definición Hospital Virtual” en Anexo B. 34 Para información referente al Estudio de tecnologías médicas de medición, ver en Anexo F.
38
Para poder implementar una solución de este tipo se contaba con dos opciones
1. A través de un método invasivo: Solución en la cual es necesario adaptar un mecanismo
de captura tipo hardware que permita digitalizar la información del formato nativo del
equipo médico para poder introducirla en el sistema de computo, el cual estará
conectado a un sistema de comunicaciones para transferir la información. En este tipo
de método es necesario manipular físicamente el equipo medico (abrir el equipo,
estudiar el de protocolo de información).
2. A través de un método no invasivo: Solución de captura de datos mediante la cual no se
interfiere al equipo medico, es decir, no es necesario manipularlo físicamente (Abrir el
equipo, estudiar el protocolo de información).
Como se mencionó con anterioridad, la manera como el sistema prototipo de telemonitoreo
adquiere los datos es por medio de captura de imágenes, que claramente es un método no
invasivo, y que permite acoplarse de una mejor manera a diferentes equipos de medición, sin
necesidad de conocer el protocolo propietario de cada uno. Esto daba al proyecto cierto grado de
universalidad, que mediante el método invasivo no se puede dar. Además, si se tiene en cuenta,
que según el estudio de tecnologías de medición de signos vitales, la mayoría de los equipos
médicos de medición tienen una pantalla de visualización, se puede decir que esta solución se
ajusta perfectamente.
La imagen que es capturada no tiene ningún pre-procesamiento, lo que implica que se envía la
totalidad de la imagen; sin embargo como la red de comunicaciones que se utiliza, GPRS, posee
planes de datos fijos (limitados por consumo), y teniendo en cuenta que en promedio se
consumen 13MB por semana35, en un mes se consumen aproximadamente 50MB por Lugar
Remoto. Este consumo de datos se ajusta al plan corporativo de datos que maneja un consumo
máximo de 80MB, con un costo de cuarenta mil pesos (40.000). 36
35 Ver estadísticas prueba en Sección 7, Resultados. 36 Para referencia de costo de planes de datos GPRS vigentes, contactar a www.latcom.com.co.
39
Como tal las imágenes son enviadas a través de una red de comunicaciones al servidor central
donde se realiza el procesamiento de imágenes. Se optó por esta solución teniendo en cuenta
que con esta implementación se buscaba centralizar los procesos.
En el desarrollo del lugar remoto se integraron diferentes equipos con funciones específicas, y se
instalaron en una estación. Esta decisión se tomó de acuerdo a las especificaciones del sistema,
en el cual, las tomas de datos no se realizan constantemente sino de forma regular; por esto, a
la hora de toma de medida es mejor para el paciente acercarse y conectarse a la estación, que
tener conectado todo el tiempo el sistema de telemonitoreo.
Como se explicó anteriormente, la forma como captura los datos el sistema prototipo de
telemonitoreo es a través de imágenes. Esto indica, que de alguna forma se debían tomar fotos
de la pantalla de visualización del equipo medico. Para esto se acopló físicamente al equipo
medico una cámara análoga a color, mediante una estructura de acrílico que la mantiene en una
única posición, garantizando la misma condición de captura de imagen.
La cámara análoga por si sola no puede tomar las imágenes, para eso se le debe adaptar un
equipo que manejara y controlara las tomas de imágenes, y que además pudiese ser configurado
remotamente por medio del servidor central para cargar los horarios de toma. Para el caso de
este proyecto se escogió un servidor Web de video marca LINUDIX con dos puertos para cámara,
que gracias a sus características de diseño, puede ser configurado de forma remota a través de
códigos CGI. Así pues este equipo debido a su tamaño y la opción de ser programado
remotamente, se ajustaba de manera optima a los requerimientos del proyecto.
Dentro de las características propias de este dispositivo se tenia que las imágenes tomadas eran
de una resolución mínima de 320x240 píxeles con formato de compresión JPEG, condiciones
que limitaban las especificaciones técnicas del proyecto. El Servidor de Video se configura a
través de cualquier navegador, en el esquema de cliente WEB37.
37 La configuración del servidor Web se presenta en Anexo J, equipos lugar remoto.
40
5.2. SISTEMA DE COMUNICACIONES
5.2.1. Criterios de Diseño
Como se ha explicado a lo largo de este libro, en el sistema prototipo de telemonitoreo, los datos
tomados a un paciente ubicado en el lugar remoto, deben ser enviados al servidor central para
realizar allí el procesamiento de las imágenes; además este servidor central debe ser consultado
por el médico encargado del paciente para que pueda mantenerse al tanto de de los niveles
tomados de sus signos vitales y así tomar decisiones.
Es decir, sobre la red de comunicaciones se tienen dos requerimientos:
Debe conectar el lugar remoto con el servidor central
El servidor central debe ser consultado por un usuario publico (Medico)
Para desarrollar esta red se tenían como opciones: Diseñar toda la red sobre una red publica
como INTERNET o diseñar una red privada entre el lugar remoto y el servidor central, y que la
consulta por parte del medico al servidor central se realzara a través de INTERNET.
En la primera opción, tanto el lugar remoto como el servidor central se conectan a INTERNET,
esto hace que la implementación sea sencilla, ya que solo es necesario tener una dirección
pública tanto en el lugar remoto como en el servidor central. Sin embargo, esta solución
presenta inconvenientes de seguridad por ser una red pública, así como el hecho de que el canal
en muchos casos es compartido.
En la segunda opción, el lugar remoto se conecta al servidor central a través de una red privada
y el servidor así mismo debe ser capaz de ser consultado por el medico a través de una red
publica. Esta opción hace que se conserve un nivel de seguridad mayor que en la primera, al
tenerse un canal dedicado y privado entre los sitios. Además, debido a que la consulta por parte
del medico se realiza por INTERNET, se puede tener una solución de consulta mas flexible ya
que solo es necesario que el usuario tenga una conexión a la red publica de INTERNET.
41
Al comparar estas dos opciones se decidió implementar la segunda, teniendo en cuenta que ésta
nos generaba un nivel de seguridad mayor, además de un canal dedicado con mayor
disponibilidad.
La siguiente fase después de decidir el tipo de conexión que debía tener el sistema prototipo de
telemonitoreo, era elegir el tipo de tecnología inalámbrica semimóvil. Para esto se hizo referencia
al estudio de tecnologías semimóviles, gracias al cual se pudo tener un acercamiento a
diferentes tecnologías inalámbricas implementadas en el país. Para escoger la tecnología
semimóvil, se tuvo en cuenta los requerimientos técnicos mostrados por el Modelo de Atención
No 1, en el cual se mostraba que la tecnología de comunicaciones debía cumplir características
como: el no requerimiento de banda ancha y que la disponibilidad del canal no debía ser alta.
Siguiendo estos dos lineamientos, se escogió la tecnología celular de datos GPRS, como la
tecnología semimóvil de comunicaciones que se implementaría en el proyecto, que además de
cumplir con las dos características antes expuestas, brindaba un buen cubrimiento.
Ya teniendo el tipo de conexión y la tecnología semimóvil para el Sistema Prototipo de
Telemonitoreo, se inicio la etapa de diseño de la red. Para esto se contó con el apoyo
LATCOM/COMUNICAR, que nos brindo su red metropolitana, para sobre ella realizar la red de
comunicaciones que debía tener el proyecto.
5.2.2. Funcionamiento y Características
Para poder cumplir con las características que requería tener la red de comunicaciones, y
teniendo en cuenta que el servidor central debía tener una comunicación tanto con la Red de
GPRS como con INTERNET, el diseño de la red se basó en políticas de enrutamiento IP,
mediante las cuales se podía decidir hacia que red, GPRS o INTERNET, debían ser enrutados los
datos. La idea principal de estas políticas de enrutamiento, era identificar los paquetes
provenientes de GPRS ( Datos referentes a la imagen con información de los signos médicos)
para trasportarlos hacia el servidor central y los paquetes provenientes de la red publica
(Requerimiento Cliente Web) para trasportarlos al servidor Web alojado en el servidor central. En
la figura 17, se muestra el diagrama de como fue implementada la red.
42
Figura 17. Diagrama de la Red de Comunicaciones.
Los lugares remotos están ubicados en cualquier parte donde el operador GPRS, para el caso de
este proyecto Comcel, tiene cubrimiento GPRS. De modo que al iniciar sesión con este operador,
se encuentran conectados directamente con esta red de datos. Todo el tráfico de esta red llega a
un “Router”, ubicado en las instalaciones de Comcel Bogotá, que direcciona el tráfico hacia su
destino final. Después de tener el tráfico en Comcel Bogotá, de acuerdo a políticas de
enrutamiento pasan las direcciones autorizadas a la red de LATCOM/CWS S.A. con sede en
Bogotá, a través de una conexión en fibra óptica multimodo entre ambas empresas, denominado
Túnel de Fibra, que se encuentra identificado por el APN (Access Point Name). La fibra se
conecta directamente a un “router” de entrada ubicado en las instalaciones de LATCOM/CWS y
este equipo a su vez se encuentra conectado a un “switch”, que provee el puerto para conectar
el Servidor Central.
43
A través de una VLAN (Red Virtual de Area Local) asignada a Internet, el Servidor Central se
puede conectar a dicha red. Este proceso lo hace mediante otro router interno de la red de
LATCOM/CWS; este proceso permite la salida del servidor a Internet con una dirección pública.
El servidor Central se encuentra conectado a dos redes diferentes, sin embargo el tráfico siempre
llega al “router” denominado Cisco CWS que aparece en la figura 18. En este “router” se
configura una política de enrutamiento en la cual si se detectan peticiones provenientes de
direcciones válidas de la red GPRS es capaz de redireccionarlas hacia el router denominado Cisco
400 CWS de la figura 18; con este proceso se garantiza que dichos datos sean enviados a la red
GPRS de Comcel.
De acuerdo al diagrama de red que se muestra en la figura 18, las direcciones IP de los equipos
del Sistema Prototipo de Telemonitoreo son:
Dirección Pública Servidor: 200.31.83.11
Dirección Local Servidor: 78.110.64.15/24
Puerta de Enlace: 78.110.64.10/24
Servidor DNS: 200.31.83.5/24
Dirección Lugar Remoto 1: 172.30.144.162/36*
Dirección Lugar Remoto 2: No asignada.
*La dirección GPRS es asignada por Comcel mediante la SIMCARD que se le coloca al MODEM
GPRS. Estas direcciones pueden cambiar de acuerdo a la disponibilidad de SIMCARD
5.3. SERVIDOR CENTRAL
5.3.1. Conversor de Imágenes
A partir de la solución planteada, se puede notar que esta implementación es una integración de
equipos ya existentes que aunque no han sido diseñados específicamente para este tipo de
aplicación, con algunos desarrollos tanto en hardware como software pueden llegar a ser una
solución de bajo costo, realizable para satisfacer la necesidad puntual del proyecto y probar
entonces la validez y funcionalidad del concepto general.
44
Uno de los desarrollos más importantes aunque no es el centro del proyecto, es la identificación
de los datos que se encuentran en las imágenes.
En un principio se intento utilizar algoritmos de identificación de objetos utilizando la teoría de
Haar Features y sus clasificadores en cascada, pero esta solución fue descartada pues los
resultados obtenidos no fueron satisfactorios además el entrenamiento de estos clasificadores es
complejo y lento para llegar a unos resultados aceptables, se opto entonces por buscar otra
solución un poco mas fácil de implementar pues como se menciono anteriormente este trabajo
de grado no se centra en el reconocimiento de objetos o caracteres ni en el procesamiento de
imágenes, esto es solo una parte de toda la solución.
Para descifrar esta información fue necesario recurrir a herramientas de procesamiento de
imágenes. Se desarrollo una aplicación escrita en lenguaje C++ apoyado por OpenCV (librería
para C++ con funciones para el análisis y la manipulación de imágenes) así como también un
software de reconocimiento de caracteres (GOCR) pues finalmente este tipo de información era
la que se necesitaba identificar en cada una de las imágenes. Esta aplicación se alojo en el
servidor central y es ejecutada periódicamente.
Cabe notar que la identificación de los datos incluidos en cada imagen depende de que equipo
médico se este utilizando en cada lugar remoto, es decir, si se tienen diferentes equipos
midiendo los signos vitales, es necesario utilizar un desarrollo independiente por equipo, la
ubicación espacial de la información no necesariamente es igual o parecida, así como la calidad
de la pantalla, tipo de fuente, entre otras.
Se desarrollo entonces una primera aplicación puntual para el oxímetro de pulso Palco 300; se
especifico con anterioridad que las imágenes a transportar estaban en un espacio de color RGB y
eran de tamaño 320x240, la mayoría de cámaras y sistemas de captura de este tipo disponibles
hoy en día funcionan bajo estas características. También se fijo la distancia entre la cámara y el
display del equipo medico mediante una estructura en acrílico.
El procesamiento de imágenes se llevo a cabo en dos etapas, la primera adecua la imagen para
ser procesada por el GOCR, pues esta aplicación fue diseñada para reconocer caracteres en
imágenes adquiridas de documentos reales tales como fotocopias, fax. Este procesamiento se
lleva a cabo de la siguiente manera:
45
La imagen es convertida al espacio de color HSV (Hue, Saturación, Intensidad). Analizando cada
uno de estos planos para saber donde se encuentra la información relevante en la imagen y se
verificó que esta se encuentra en el plano de intensidad. Como se muestra en la figura 18.
Vector Hue Vector Saturación Vector Intensidad
Figura 18. Vectores Imagen.
Una vez descompuesta la imagen en estos tres vectores, el vector intensidad es analizado según
su distribución, a continuación en la figura 19, se muestra la distribución de intensidad en este
vector.
Figura 19. Vector Intensidad
46
La figura 19 corresponde al histograma de intensidad de la imagen. Claramente se pueden
identificar dos clases que corresponden a las regiones de la imagen donde se encuentran los
caracteres y el fondo respectivamente, muestra niveles de intensidad (eje x) contra numero de
píxeles (eje y). Claramente se pueden identificar dos grupos. Uno entre los índices 0 y 0.5
(fondo) y otro grupo de 0.5 hasta 1 (digitos) donde se encuentra la mayor intensidad. Se
establece un umbral con la función OTSU de OpenCV que binariza la imagen según estos dos
grupos. Lo que nos da como resultado una imagen blanca y negro solo con la información
requerida. Implementando una negación de la imagen se obtiene como resultado una imagen
muy parecida a una fotocopia o a un fax. Esto permite utilizar la herramienta GOCR para
identificar los caracteres y poder almacenarlos en la base de datos.
GOCR es un programa bastante flexible, es de código abierto y de licencia libre, ofrece la
posibilidad de crear una base de datos propia para el reconocimiento de caracteres, además,
puede manejar ruido alrededor de la información requerida entre otras características. En un
principio, se buscó desarrollar una aplicación parecida o que cumpliera la misma función, pero se
decidió aprovechar los desarrollos ya existentes y la experiencia de otros grupos de
desarrolladores a nivel mundial pues este tampoco era el tema central de nuestro proyecto.
Para generar la base de datos de caracteres a reconocer por el GOCR, se utilizó una base de
1000 imágenes. Se simularon 10 tipos de condiciones y por cada condición se tomaron 100
imágenes. Las condiciones fueron basadas en el modelo de uso que se le llegaría a dar al
sistema, 10 habitaciones diferentes, con diferentes tipos de iluminación, 5 condiciones diurnas, 5
condiciones nocturnas incluyendo luces típicas de vivienda, tanto blancas como amarillas. Las
pruebas aunque no fueron muy extensas si nos permitieron generar una base de datos en el
GOCR lo suficientemente robusta para garantizar el funcionamiento del sistema bajo condiciones
normales de uso. También fue posible notar que con tan solo 20 muestras por condición, se
alcanzaba un nivel donde todos los caracteres podían ser reconocidos, las siguientes 80
muestras se continuaron realizando como medida preventiva y de prueba adicional.
En total, la base de datos para reconocimiento de caracteres, cuenta con un total de 782 dígitos
diferentes, distribuidos como se muestra en la tabla 1.
47
DIGITO NUMERO DE MUESTRAS
0 83
1 64
2 97
3 84
4 72
5 49
6 102
7 61
8 67
9 103
TOTAL MUESTRAS EN BASE DE DATOS 782
Tabla 1. Distribución Base de Datos GOCR.
Figura 20. Muestra Base de Datos GOCR.
Finalmente estos resultados generados tanto por el procesamiento digital de imágenes y por el
reconocimiento de caracteres son almacenados en la base de datos en formato ASCII y pueden
ser manipulados, presentados en tablas y analizados.
48
5.3.2. Control
Se implementó un control central dentro de la aplicación, encargado de administrar en tiempo
toda la operación, capaz de coordinar tanto los elementos en el lugar remoto, como los
elementos y datos dentro del servidor central. Este control puntualmente se encarga de:
Verificar que procesos existentes en el momento han tenido cambios en los horarios o
que procesos son nuevos y, envía comandos de configuración a los respectivos lugares
remotos, específicamente a los equipos LINUDIX, para actualizar las horas en las cuales
se deben adquirir los datos.
Verificar la existencia de imágenes provenientes del lugar remoto, convertir estas
imágenes en datos según el equipo al que pertenezcan, utilizando el conversor adecuado
para su posterior almacenamiento en la base de datos.
Generar reportes (logs del sistema), para su posterior análisis y seguimiento por parte
del equipo desarrollador.
Este control fue implementado utilizando dos herramientas; una primera herramienta encargada
de lanzar tareas periódicamente, disponible desde el sistema operativo llamada CRON TABS y,
una segunda desarrollada bajo “scripts” en PHP, los cuales generan las dos rutinas necesarias
para el funcionamiento del sistema y verificación de los datos. Para ilustrar de una mejor manera
el funcionamiento de esta parte del desarrollo se exponen los siguientes diagramas de flujo en
las figuras 21 y 22.
49
Consulta DB
Inicio
50
Cambio de
Horario
Ping a Linudix
Correspondiente
Fin
Fin
Envío de Nueva Config.
A Linudix
Ping
ok?
Log
NO
SI
NO
Fin SI
Figura 21. Diagrama de flujo Bloque de Control función 1.
Consulta
Directorios Inicio
Nuevas Imagenes
?
Consulta BDID Equipo
Conversion Ok?
Conversion Imagen
Fin
Fin Log
Cargar dato En BD
Fin
NO SI
NO
SI
Figura 22. Diagrama de flujo Bloque de Control función 2.
5.3.3. Base de Datos
El Servidor Central contiene una base de datos general conformada por múltiples tablas
desarrolladas mediante el lenguaje de programación MySQL. Las tablas implementadas son
las siguientes.
5.3.3.1. Tabla Personal Médico
Contiene toda la información del profesional médico, asociada a los pacientes que están
bajo su responsabilidad, de manera que solamente el médico autorizado puede tener
acceso a la información de los pacientes a su cargo, mediante un sistema de
autentificación por nombre y contraseña. Esto garantiza la confidencialidad de los datos
de cada uno de los pacientes.
5.3.3.2. Tabla Personal Técnico
Contiene la información del personal técnico responsable de la asignación de los
parámetros necesarios para el correcto funcionamiento de los distintos lugares remotos.
Los parámetros más relevantes de dicha configuración, son la dirección IP estática
asignada por el dispositivo de protocolización ubicado en cada lugar remoto, los nombres
de las carpetas destino en el servidor central, el número de monitoreo válido.
5.3.3.3. Tabla Historia Clínica del Paciente
Contiene información del paciente, que conforma la historia clínica del mismo utilizada
en el Hospital para facilitar la identificación, ubicación y tratamiento médico del
individuo. Esta base de datos se crea al momento de ingresar un paciente a la
hospitalización.
5.3.3.4. Tabla Caso de Monitoreo
Contiene la información relacionada con el monitoreo del paciente que están
relacionados con la base de datos de la historia clínica previamente creada. Esta
información solo esta disponible cuando el médico responsable establece una sesión
monitoreo remoto, donde se pueden consultar datos específicos como condiciones de
administración, horarios de monitoreo.
51
5.3.3.5. Tabla Mediciones del Paciente
Contiene todas las mediciones del monitoreo asignado para cada paciente, que pueden
consultarse desde cualquier acceso a Internet, únicamente por el personal autorizado.
Estos datos se consultan por medio de gráficos, que mostrarán con detalle el
comportamiento del paciente en diferentes momentos del monitoreo remoto, de acuerdo
a los horarios establecidos.
5.3.3.6. Instrucción CGI
La instrucción CGI (figura 23) contiene datos que hacen referencia a los siguientes
parámetros:
• Dirección IP del servidor de Video.
• Tipo de configuración del servidor DVR (Digital Video Recorder).
• Horarios de inicio y finalización de toma de video (hora y fecha).
A continuación se presenta la línea de texto (strip http), que es enviada al Linudix.
Figura 23. Instrucción CGI
5.3.4. Servidor FTP, Servidor Apache y Sitio Web
Con está aplicación se transfieren las imágenes desde el lugar remoto hacia el Servidor
Central, que tienen por destino una carpeta especifica dentro del sistema. Ya con las
imágenes almacenadas en un determinado archivo, el control puede consultarlas y tomar las
decisiones propias de su función (Tomar las imágenes). Es pertinente aclarar, que para que
las imágenes puedan transferirse desde el Lugar Remoto hacia el servidor FTP, es necesario
configurar cada uno de los servidores de video localmente, con la dirección IP específica
donde se encuentra alojado el servidor FTP, sus respectivas claves de acceso y la extensión
del archivo donde deben ser almacenadas las imágenes. También está aplicación permite
mover la información de y hacia el servidor y cliente WEB respectivamente. De igual manera
para poder acceder a la información fue necesario implementar un sitio web desarrollado en
52
PHP, este sitio web cuenta con todas las herramientas necesarios para manejar y consultar
tanto los datos como el sistema por el personal medico38.
5.3.5. Problemas Implementación
Durante el transcurso de la etapa de pruebas se pudieron identificar 3 fuentes de error:
1.) Error en la malla de comunicaciones (GPRS, FTP, RED)
2.) Error en la conversión de la imagen (Aplicación en C++ +OpenCV + GOCR)
3.) Error en la toma de la imagen por desincronización con dispositivo.
Estos errores no son relevantes en la implementación, debido que para el sistema solo es
necesario capturar una imagen en la sesión de toma de signos vitales. Sin embargo, con el fin de
detectar dichos errores se decidió implementar un log de eventos cuya finalidad es mostrar de
forma explicita cuando ocurre un error y su fuente de origen.
Error en malla de comunicaciones (GPRS, FTP, RED)
Fallos en la comunicación de los equipos, ya sea por congestión en la red de datos,
disponibilidad de la red, calidad de recepción o errores en los protocolos de transmisión generan
errores en el sistema que pueden terminar en transmisión de las imágenes incompletas o
simplemente en la perdida total de los datos, a continuación en la figura 24, se muestran
algunos ejemplos de imágenes afectadas por este tipo de error.
Figura 24. Imágenes incompletas.
38 Para conocer con mayor profundidad información acerca del sitio web, referirse al anexo J
53
Otras imágenes aunque logran ser transmitidas contienen datos corruptos y muestran tamaños
anormales como 0kb y son imposibles de abrir en el servidor central.
35_20050312080000010000 0kb JPG Image
Se creo un log (historial de funcionamiento) en el sistema (logctrl2.txt) para identificar las
imágenes con estos tipos de problemas generando el siguiente resultado:
<br> Warning: copy(/usr/local/apache/includesHospital/fotos/fotos/35_20050312080000010000.jpg): failed to open stream: No such file or directory in /usr/local/apache/htdocs/hospital/control/ctrl2_1.php on line 46 Warning: unlink(): No such file or directory in /usr/local/apache/htdocs/hospital/control/ctrl2_1.php on line 180 9566 35_20050312080000010000.jpg<br> 2005-03-12 8:00<br>
Error en la conversión de la imagen
En algunos casos aunque la transmisión de datos entre el lugar remoto y el servidor central se
efectuó con éxito, el sistema presentó fallos en la conversión de las imágenes.
La forma de constatar este tipo de errores también se puede observar en el log del sistema
(logctrl2.txt), pues este nos indica que dato en particular es el que se intentará ingresar a la
base de datos. La base de datos filtra los datos que son inválidos y estas muestras las desecha,
por lo tanto no aparecen en los registros causando así perdidas de muestras.
El log del sistema se muestra a continuación para un caso en particular a manera de ejemplo:
------------------------------------------------------- -_--_- Dato No Valido 35_2005031201801000.jpg 2005-03-12: 18:01 -------------------------------------------------------
54
Este tipo de fallos generados en la conversión de las imágenes es causado principalmente por
ruido en la imagen, generado por diferentes fuentes como exceso de luminosidad, sombras o
reflejos de objetos externos que causan contrastes de color y terminan en el fallo de
reconocimiento de algunos dígitos. A continuación en la figura 25, se presenta una imagen
donde se puede observar el problema mencionado.
Figura 25. Imagen con error de procesamiento.
Este tipo de error se puede llegar a minimizar, adquiriendo más imágenes e incluyéndolas en la
base de datos del GOCR.
Error en la toma de la imagen por desincronización con dispositivo.
Otro tipo de error encontrado en esta prueba realizada, es debido a desincronización en el
momento de adquirir la imagen por parte de la cámara digital. En algunos momentos el
pulsioximetro se encuentra analizando la información que viene del paciente y apaga su display
por unos instantes de tiempo muy cortos. En algunos casos, la toma de la imagen se efectúa en
este preciso momento, terminando entonces en la toma de una imagen vacía. Una vez esta
imagen llega al sistema central y es analizado por la aplicación conversora de imágenes, reporta
un error que aparece de nuevo en el log del sistema lo cual facilita su identificación. Como los
datos adquiridos son vacíos, la base de datos desecha esta muestra.
55
A continuación se presenta el log del sistema en este tipo de casos y una imagen (figura 26)
generada en el instante preciso de un caso de desincronización.
Figura 26. Imágen desincronizada.
------------------------------------------------------- Err Dato No Valido 35_2005031000810000.jpg 2005-03-10 : 08:10 -------------------------------------------------------
56
6. ANALISIS DE RESULTADOS
Teniendo en cuenta que el trabajo de grado SPT se divide en dos partes, en esta sección, se
presentarán los resultados más importantes obtenidos tanto de la etapa de investigación como
de la etapa de implementación de la solución.
6.1. RESULTADOS OBTENIDOS ETAPA DE INVESTIGACIÓN
A continuación se presentan los resultados y conclusiones, más importantes de cada uno de los
estudios realizados como parte del trabajo de grado SPT, que fueron aplicados en el diseño de la
implementación. Los documentos de los estudios se encuentran en la sección 9 Anexos.
6.1.1. Estudio No 1 “Estudio para la definición del Hospital Virtual”
Este estudio busca principalmente construir el concepto de Hospital Virtual con apoyo de
profesionales Médicos y conocedores del área de la telemedicina, realizando encuestas y
entrevistas, permitiendo con este tener unas bases sólidas bajo el esquema interdisciplinario
que se está proponiendo39.
Este estudio es la base conceptual del trabajo de grado SPT, con este se obtuvieron como
resultados: un concepto de hospital virtual y 10 modelos de atención40.
Es importante aclarar que la creación de los modelos de atención es necesaria, teniendo en
cuenta que en el sector salud a nivel internacional y nivel nacional, no existen estándares de
atención, solamente se maneja algún tipo de modelos en el interior de las organizaciones
(EPS, POS, etc.)
39 Para mayor información respecto al Estudio de Definición del Hospital Virtual, referirse a Anexo B. 40 La definición del Hospital Virtual y los modelos de atención se encuentran en el documento del Estudio en Anexo B.
57
6.1.2. Estudio No 2 “Estudio de tecnologías de comunicaciones
inalámbricas Semimóviles”
Con este estudio se obtuvo un cuadro comparativo41 entre tres tecnologías de comunicación
inalámbrica semimóvil. Se excluyeron otras tecnologías que por sus características, actualmente
no son utilizadas de forma masiva. El cuadro comparativo obtenido, clasifica las características
de cada una de estas tres tecnologías y las relaciona con los requerimientos técnicos de los
diferentes modelos de atención, del primer estudio.
De esta manera al momento de implementar un sistema de monitoreo, basado en un modelo de
atención ya se cuenta con la solución de comunicaciones adecuada.
6.1.3. Estudio No 3 “Estudio de las tecnologías disponibles para
efectuar medición de signos vitales partiendo del concepto de
Hospital Virtual”
Se recopiló información de las características de equipos médicos, disponibles en algunos
hospitales convencionales de Bogotá y algunos otros publicados en Internet, para efectuar la
medición de signos vitales definidos según las especificaciones de los modelos de atención
sugeridos por el Estudio acerca de la definición del Hospital Virtual42. De manera que con este
estudio se cuenta con una aproximación a los equipos médicos más apropiados para integrar a la
solución a diseñar.
A partir de este estudio se pudo identificar una serie de características comunes que poseen la
mayoría de equipos médicos de medición de signos vitales 43 , de algunos hospitales
convencionales. Teniendo en cuenta la característica común de la pantalla de visualización, se
llego a la solución de implementación para el sistema de monitoreo SPT, usando métodos no
invasivos.
41 Para mayor información sobre el Estudio y su cuadro comparativo, ver Anexo B 42 Para mayor información respecto al Estudio, ver Anexo B. 43 Se refiere a los signos vitales que se presentan en los modelos de atención del primer estudio.
58
6.1.4. Estudio No 4 “Estudio comparativo Hospital Virtual y otras
implementaciones de monitoreo”
Por medio de este estudio se mostraron las características principales de tres proyectos de
Telemedicina implementados y desarrollados en Colombia, que han tenido cierto impacto en el
país44.
Los resultados muestran los beneficios y problemas de la implementación de soluciones de
proyectos de telemedicina. Además la tabla comparativa relaciona las características técnicas,
operacionales y de funcionamiento de estos sistemas en concreto.
Este estudio es una fase posterior de la implementación desarrollada y hace parte de la etapa de
conclusiones.
6.2. RESULTADOS OBTENIDOS ETAPA DE
IMPLEMENTACIÓN
Durante el desarrollo de la implementación del SPT se probaron todos los elementos de los
diferentes bloques, garantizando las funciones de cada uno mencionadas en la sección de
descripción. Además se comprobó la interconexión de todos los bloques, que conforman el
sistema.
Para analizar el funcionamiento total del sistema y verificar su correcto desempeño, se simuló un
caso de prueba en un ambiente real durante siete días (marzo 7 de 2005 a marzo 13 de 2005).
Durante este tiempo, el sistema funcionó completo a nivel de comunicaciones y análisis de datos.
Las muestras fueron tomadas en dos horarios establecidos (8:00 a.m. y 6:00 p.m.), siguiendo el
procedimiento establecido para toma de datos45 . El lugar remoto fue ubicado en la Carrera 7 #
45 – 48 Apto 1204 de la ciudad de Bogota (Zona con cobertura por parte de la red de Comcel
S.A.). En esta prueba se simularon también casos extremos para comprobar el módulo de
44 Para mayor información respecto al Estudio, ver Anexo G. 45 Los procedimientos del sistema se definen en el Anexo H, Manuales y Procedimientos.
59
alarmas, garantizando niveles anormales46 de ritmo cardiaco (haciendo ejercicio mientras las
tomas ocurrían) y de esta manera generar diversas muestras en el equipo médico.
Se lograron conformar las gráficas de Saturación de Oxigeno y Frecuencia Cardiaca durante los
siete días del procedimiento, permitiendo analizar el funcionamiento del sistema. La figura 27
muestra la gráfica de oximetría sin suministro de oxigeno, que presenta 14 muestras puntuales
(eje X) y la medida del signo (eje Y). De igual forma la figura 28 presenta las 14 medidas del
ritmo cardiaco sin suministro de oxigeno, donde se puede verificar los cambios bruscos en la
medida del signo vital, debido a las condiciones con que se tomaron.
Figura 27. Gráfica de Oximetría sin suministro de oxigeno.
46 Información referente a niveles normales y anormales de los signos medidos, consultar Anexo H, Manuales y Procedimientos.
60
Figura 28. Gráfica Ritmo Cardiaco sin suministro de oxigeno.
La tabla 2, presenta los datos obtenidos, tanto de oximetría y ritmo cardiaco para el caso
concreto en que no se tiene suministro de oxigeno. En esta se cuenta con registro de fecha y
hora de la medición.
Fecha y hora Oximetría Ritmo cardiaco
1 Mar 7 / 07:55 98 71
2 Mar 7 / 17:55 95 65
3 Mar 8 / 08:00 95 67
4 Mar 8 / 18:00 95 93
5 Mar 9 / 08:00 93 118
6 Mar 9 / 18:00 94 94
7 Mar 10 / 08:00 95 81
8 Mar 10 / 18:00 94 121
9 Mar 11 / 08:00 93 92
10 Mar 11 / 18:00 95 80
11 Mar 12 / 08:00 93 92
12 Mar 12 / 18:00 95 79
13 Mar 13 / 08:00 95 80
14 Mar 13 / 18:00 95 80
Tabla 2. Datos Oximetría y Ritmo Cardiaco sin suministro de oxigeno.
61
En la prueba realizada fueron tomadas y procesadas 560 imágenes, teniendo en cuenta el
proceso normal del sistema en la adquisición de imágenes. Este número de imágenes es posible
calcularlo de la siguiente forma:
2 x 20 x 2 x 7 = 560
Tomas al día x minutos en cada ventana de tiempo x ventanas de tiempo (1 con oxigeno, 1 sin
oxigeno) x días totales = Número total de fotos en el procedimiento.
Revisando la base de datos se verificó que se generaron 520 registros totales, de manera que 40
imágenes fueron desechadas por el sistema.
En la tabla 3, se resumen las estadísticas obtenidas en las pruebas mencionadas, donde se
muestra el error del sistema. Este error del 8.2% se refiere a problemas concretos en la
adquisición de la imagen, es decir que este no se refiere a confusión de datos, al momento de
realizar la comparación con la base de datos para reconocimiento de caracteres.
ESTADISTICAS PRUEBA
Imágenes del proceso de monitoreo en condiciones ideales 560
Imágenes recibidas en el servidor central 520
Errores debidos a transmisión de datos 12 (2.1%)
Errores debidos a conversión de imágenes 21 (3.75%)
Errores por desincronización de dispositivos 7 (1.25%)
Bytes totales transmitidos 13Mbytes
% de error de adquisición 8.2%
Efectividad del sistema 92.8%
Tabla 3. Resultados Caso de Estudio.
62
6.3. Inconvenientes Operacionales
En el transcurso del desarrollo del trabajo de grado SPT, se experimentaron inconvenientes de
tipo operacional que afectan de forma directa los objetivos del proyecto en mención,
concretamente la implementación de dos lugares remotos. A continuación se presentan las
causas que generaron estos problemas y las soluciones que se implementaron.
6.3.1. Adquisición Equipos Médicos y de Comunicaciones
A pesar de que se interactuó con equipos médicos, como lo muestra el tercer estudio
enfocado sobre las tecnologías de medición de signos, fue complicado contar con más
de dos equipos para el desarrollo. De igual forma se tuvo una nueva limitante en la
adquisición de los equipos de comunicaciones, que fueron aportados por la empresa
LATCOM/COMUNICAR S.A.; estos dos inconvenientes operacionales, no permitieron la
implementación de otro lugar remoto, que buscaba verificar las capacidades del sistema,
para manejo de múltiples pacientes.
Con el fin de comprobar esta capacidad, se decidió simular el segundo lugar remoto,
para ello se omitió el proceso de adquisición y de transmisión de las imágenes, de modo
que se automatizó un proceso que colocaba imágenes aleatorias, con la etiqueta de este
segundo lugar remoto, con el fin de aplicarles el proceso de identificación e inclusión en
la base de datos.
6.4. POSIBLES MEJORAS
Se analizaron posibles mejoras, teniendo en cuenta las limitantes y problemas identificados;
estas propuestas podrían ser ejecutadas en una etapa posterior a la de esta implementación y
dividirse en diferentes líneas de investigación, teniendo en cuenta las múltiples áreas que
maneja el proyecto. Estas mejoras buscan mejorar el desempeño, la calidad y el funcionamiento
de la implementación, teniendo en cuenta que este sistema prototipo se realizó con el propósito
de comprobar la posibilidad de implementación y funcionamiento del mismo.
6.4.1. Software de Procesamiento de Imágenes
La aplicación desarrollada para el reconocimiento de imágenes aunque en las pruebas
realizadas muestra una efectividad del 96.2%, en el total de los errores representa un
63
47.5%, es decir casi la mitad de los errores en la aplicación provienen del
reconocimiento de la imagen. Estos errores como se comento anteriormente, son
debidos a niveles de luminosidad y reflejos no deseados en la pantalla del display, como
una primera línea para enfrentar el problema se genero una base de datos de dígitos,
incluyendo reflejos que se podrían generar bajo condiciones normales. Esta base de
datos funciono para los propósitos de este trabajo, pero se plantea como una posible
mejora al sistema, retomar los estudios acerca de Haar Features y sus clasificadores
para implementarlos en el reconocimiento de dígitos, de esta forma podría generarse
una solución mas robusta que flexibilice el sistema y no sea tan vulnerable a este tipo de
situaciones, también podría eliminarse el requerimiento de tener una distancia fija entre
la cámara y el equipo medico.
6.4.2. Procesamiento de Imágenes en el Lugar Remoto
Es posible implementar un bloque adicional de software y hardware en el lugar remoto,
que permita hacer un pre-procesamiento de la imagen adquirida e identifique los
caracteres correspondientes en el lugar remoto. De esta manera se podría reducir la
cantidad de información transmitida por la red. Aunque es una solución que
incrementaría tanto en equipo como en costos al lugar remoto, podría llegar a ser una
solución viable para aquellos casos donde los planes de transmisión de datos via GPRS
sean demasiado costosos o no se adecuen al esquema de precios propuesto.
6.4.3. Implementación de Correos electrónicos y Mensajes de Texto
La implementación en el proceso de información de alarmas de alerta, se puede mejorar
mediante el envió de correos electrónicos y mensajes de texto, al especialista médico.
Con esta extensión de la aplicación, el médico puede conocer niveles anormales en las
mediciones de los signos de sus pacientes (alertas), en la comodidad de su celular o en
su correo personal; esta herramienta permite tener información importante de su
paciente, sin ingresar a la página Web de la aplicación en el preciso momento en que
estas se generan. La implementación de esta solución es bastante sencilla, basta con
utilizar algunas librerías ya disponibles en PHP para hacerla realidad. En este trabajo no
fue implementada aunque se pensó en algún momento, pero como el objetivo era
64
simplemente probar el concepto no se vio necesario, para un sistema con enfoque un
poco mas comercial se deja abierta la posibilidad.
6.4.4. Mejora entorno gráfico
El sistema prototipo de telemonitoreo (SPT), cuenta con un entorno gráfico para los
médicos especialista y los técnicos del sistema 47 ; este entorno cumple con las
condiciones mínimas necesarias, para la presentación organizada y estructurada de la
información referente a la aplicación en general. Sin embargo es muy importante diseñar
un entorno gráfico para el sitio Web de la aplicación, que ofrezca ambientes más
versátiles y funcionales así como también mas agradables visualmente para los usuarios.
Algunos cambios que pueden implementarse, podrían ser vínculos entre pantallas,
múltiples presentaciones estadísticas, menús desplegables, ambientes amigables y
configurables bajo perfiles de usuario de acuerdo a las necesidades especificas de cada
uno de ellos.
6.4.5. Clasificación de pacientes
El sistema prototipo maneja información global de pacientes; de manera que todos los
especialistas médicos creados como usuarios del sistema, pueden acceder a la
información total de los pacientes registrados en el sistema de telemonitoreo. Esto
significa que los pacientes no se clasifican de acuerdo al especialista médico encargado.
Para que la información este segmentada y organizada se debe asociar cada paciente
con su respectivo médico. Esto evitaría que la información de cada paciente pudiera ser
acezada por cualquier usuario que tenga acceso a la herramienta.
6.4.6. Vínculos con Bases Médicas
Teniendo en cuenta que hospitales y clínicas manejan historias clínicas y en general
información de sus pacientes mediante aplicaciones informáticas, es posible crear
vínculos con estas bases de datos, para incorporar el sistema prototipo dentro del
estándar que maneja e interpreta cierto hospital.
47 El sistema gráfico por completo del sitio Web se encuentra en el Anexo H, Manuales y Procedimientos.
65
6.4.7. Simplificación Lugar Remoto
El Lugar Remoto en el sistema prototipo de telemonitoreo cuenta con equipos de
adquisición de imágenes, compresión de imágenes, comunicaciones que garantiza su
funcionamiento de acuerdo a la descripción realizada del mismo. En el mercado existen
equipos que integran muchos de estos dispositivos en un solo elemento, lo que haría del
Lugar Remoto un sistema más versátil, económico, práctico de implementar y con
posibilidad de movilidad.
66
6.5. ANALISIS DE COSTOS
6.5.1. Aproximación costos de desarrollo e implementación
En la fase de desarrollo e implementación del “Sistema Prototipo de Telemonitoreo para
Pacientes, Usando Tecnologías Inalámbricas Semimóviles”, se generaron una serie de
costos asociados a su elaboración, investigación y demás recursos empleados (tabla 4).
Los costos se presentan en las siguientes tablas, donde se muestran específicamente: 1.
Costo desarrollo Sistema Prototipo. 2. Costos recursos humanos. 3. Costos recursos
físicos.
COSTOS DESARROLLO SISTEMA PROTOTIPO
Item Descripción Cantidad Costo Unidad $US
Lugar Remoto
1 Router Cisco 1 800
2 Modem GPRS 1 200
3 Servidor de Video 1 300
4 Cámara Análoga 1 40
5 Soporte Acrílico 1 10
6 Caja Acrílico 1 25
7 Cables de Conexión --- 30
8 SIM CARD 1 15
Servidor Central
9 Servidor 1 3000
10 Software y Aplicaciones 1 1000
10 Instalación Ultima Milla 1 400
TOTAL
5720
Tabla 4. Costos Desarrollo Sistema Prototipo.
67
COSTOS RECURSOS HUMANOS
Item Descripción Cantidad (horas)
Costo Unidad $US
Costo Total $US
1 Director de Proyecto Ing. Carlos Eduardo García L. 40 100 4000
2 Asesor del Proyecto Ing. German Yamhure K. 20 40 800
3
Investigadores Alejandro Gutiérrez M. William Rodríguez Ceron. Nelson Henríquez C.
1200 1200 1200
5 18000
TOTAL
22800
Tabla 5. Costos Recursos Humanos.
COSTOS RECURSOS FISICOS
Item Descripción Cantidad (meses)
Costo Unidad $US
Costo Total $US
1 Renta Laboratorio Desarrollo 6 200 1200
2 Servicios (Agua, luz, teléfono, Internet) 6 150 900
3 Renta de 3 Computadores 6 150 900
4 Alquiler Equipo Laboratorio 6 100 600
5 Papelería, CD’s, etc. Bloque 100 600
TOTAL
4200
Tabla 6. Costos Recursos Físicos.
Las tablas 5 y 6 muestran los costos asociados al desarrollo del proyecto que suman un
total de US 32720. Esto es suponiendo que la implementación del sistema tuviera
asociados costos de salarios por parte del director del proyecto, asesores e
investigadores.
68
6.5.2. Aproximación Costos de Producción
En el caso que se desee implementar y producir el Sistema Prototipo de Telemonitoreo
en el ambiente colombiano es indispensable realizar consideraciones relacionadas con
recuperación de inversión a un periodo fijo; es decir el sistema requiere una serie de
equipos que tienen un valor de inversión inmediata y mensual (tabla 7), por lo tanto se
debe calcular el tiempo de recuperación de inversión. Es importante considerar que el
modelo económico planteado para la comercialización de este producto (sistema
prototipo de telemonitoreo), se encuentra basado en un esquema de arrendamiento, por
lo tanto el cliente final alquila el sistema.
COSTOS IMPLEMENTACIÓN SISTEMA PROTOTIPO
Descripción Cantidad Inversión Inicial $US
Costos Mensuales $US
Costos Anuales $US
Lugar Remoto
Router Cisco 1 800 0 0
Modem GPRS 1 200 0 0
Servidor de Video 1 300 0 0
Cámara Análoga 1 40 0 0
Soporte Acrílico 1 12 0 0
Caja Acrílico 1 25 0 0
Cables de Conexión --- 30 0 0
SIM CARD 1 15 80 960
Instalaciones y Desinstalaciones 2 0 20 480
Servidor Central
Servidor 1 3000 0 0
Software 1 1000 0 0
Mantenimiento 12 0 20 240
Ultima Milla 1 400 300 3600
Tabla 7. Costos Implementación Sistema Prototipo
69
RESUMEN TOTALES
Descripción Lugar Remoto Servidor Central
Total Inversión Inicial $US 1422 4400
Total Costos Mensuales $US 120 320
Total Costos Administrativos, Publicidad y Otros (Mensuales) $US 200
Recuperación Inversión Inicial a 12 meses 119 367
Tabla 8. Resumen Totales.
En la tabla 9 se muestran el análisis de las posibles ganancias, en el caso de que se
asociaran a los gastos mensuales por lugar remoto, solamente los costos de
recuperación de inversión inicial a 12 meses y las mensualidades de servicios
(mantenimiento y comunicaciones).
ANALISIS GANANCIAS POR CADA LUGAR REMOTO
Gastos por Lugar Remoto (mensualmente) $US Margen de Ganancia Mensualidad por
Punto $US Ganancia Mensual
por Punto $US
15% 281 42
20% 298 59 239
30% 341 102
Tabla 9. Análisis Ganancias por Lugar Remoto.
Finalmente las siguientes tablas de costos, muestran todos los aspectos suponiendo que
este producto se comercializara y que la cantidad de lugares remotos implementados
fueran de 50 y de 250, teniendo en cuenta los datos mostrados en la tabla 10 y
variables tales como margen de ganancia, ajustes gastos mensuales y deudas.
70
IMPLEMENTANDO 50 LUGARES REMOTOS
Inversión Inicial Lugares Remotos
$US
Margen de Ganancia Ganancias $US Ajuste Gastos
Mensuales $US
Ganancia Mensual Neta $US
15% 2108 887 1221
20% 2987 887 2100 11950
30% 5121 887 4234
Tabla 10. Inversión y Ganancias con implementación de 50 Puntos
IMPLEMENTANDO 250 LUGARES REMOTOS
Inversión Inicial Lugares Remotos
$US
Margen de Ganancia Ganancias $US Abono Gastos
Servidor $US
Ganancia Mensual Neta $US
15% 10544 887 9657
20% 14937 887 14050 59750
30% 25607 887 24720
Tabla 11. Inversión y Ganancias implementación de 250 Lugares Remotos.
RESUMEN COSTOS MENSUALES POR PUNTO Y GANANCIAS NETAS
Margen de Ganancia
Mensualidad por Punto $US
Ganancia Neta Mensual con 50
puntos $US
Ganancia Neta Mensual con 250
puntos $US
15% 281 1221 9657
20% 298 2100 14050
30% 341 4234 24720
Tabla 12. Resumen Costos Mensuales por Lugar Remoto y Ganancias Netas.
El costo total de inversión inicial para 50 lugares remotos es de $ US 11950 y para 250
lugares remotos es de $ US 59750, esto sin tener en cuenta la inversión inicial del
servidor inicial. La mensualidad por lugar remoto teniendo un margen de ganancia de
71
15% es de $ US 281, con 20% es de $ US 298 y con 30% es de $ US 341. La columna
de la ganancia neta mensual de la tabla 12, muestra la utilidad de acuerdo al número de
lugares remotos implementados.
Es importante aclarar que en este análisis de costos no se tienen en cuenta variables
tales como intereses asociados a costos de inversión inicial, porque no era relevante
para este tipo de análisis de costos.
72
7. CONCLUSIONES
El desarrollo e implementación de proyectos tecnológicos, apoyados en el conocimiento médico
contribuyen en el mejoramiento de algunos de los problemas que afectan constantemente el
sistema hospitalario Colombiano.
El Sistema Prototipo de Telemonitoreo (SPT) aunque se encuentra enmarcado en el monitoreo
remoto de signos vitales básicos, utiliza conceptos de centralización de datos y digitalización de
resultados, permitiendo el tratamiento de una patología en particular (Insuficiencia Respiratoria)
y es extendible a otro tipo de patologías48.
Existen ventajas específicas que caracterizan el sistema prototipo de telemonitoreo entre las que
vale la pena mencionar:
• El sistema permite el manejo de la información de forma centralizada.
• Es posible consultar de forma remota la información de monitoreo.
• Permite extender funcionalidades de observación de pacientes al lugar donde habita.
• El sistema se caracteriza por utilizar equipos de fácil integración y adquisición.
• La forma como esta implementado el sistema permite que el lugar remoto, pueda ser
instalado y desinstalado de forma sencilla.
• El sistema permite la integración de diferentes equipos médicos, que cumplan con las
características especificas de los equipos de monitoreo.
• El sistema genera alarmas cuando detecta información de signos médicos irregulares,
para mantener informado al medico sobre la condición actual de su paciente.
El sistema prototipo de telemonitoreo (SPT), potencialmente podría escalarse a otros modelos de
atención, a diferentes patologías e integrarse de igual manera con tecnologías que permitan
transmisión de otro tipo de datos, como imágenes radiológicas, tac (tomografía axial
computarizada) cerebrales, resultados de laboratorio, entre otros. Este tipo de implementación
podría extenderse además a procesos administrativos, permitiendo procedimientos más ágiles y
eficientes. Es posible también integrar un sistema de este tipo en el sistema hospitalario, de
modo que exista la posibilidad de interacción entre entidades hospitalarias, laboratorios, centros
especializados.
48 Para ampliar la información sobre otras patologías monitoreables, referirse al anexo A
73
El Sistema Prototipo de Telemonitoreo (SPT), es una primera aproximación, ya que podría
extenderse a una solución de tipo comercial, implementada en el ambiente de atención médica
real. En general los sistemas médicos, que manejan información clínica, deben ser validados y
aprobados por distintas organizaciones médicas. Este prototipo también nos brinda la
experiencia necesaria para conocer y darnos cuenta que la implementación de sistemas de este
tipo pueden ser diseñados y puestos a punto a un costo relativamente bajo, contrario a lo que
generalmente se piensa en sistemas de telemedicina, gracias a que fue posible probar que con
los equipos actualmente utilizados y con algunos desarrollos no tan complejos e inversiones
relativamente bajas se pueden generar soluciones puntuales. Generalmente los altos costos
están asociados a la problemática en la cual los sistemas tradicionales de telemedicina, utilizan
equipos que no cumplen con una estandarización especifica, impidiendo la posibilidad de
escalabilidad e integración sobre otros componentes comerciales. Con el sistema prototipo de
telemonitoreo se hizo uso de dispositivos cuya aplicación de diseño no es la telemedicina; pero
bajo un esquema de integración de equipos y sistemas fue posible desarrollar la solución puntual
para la necesidad del doctor Juan Manuel Lozano.
Con este proyecto, se pudo demostrar la implementación y puesta en funcionamiento de un
sistema de telemonitoreo para la adquisición, procesamiento y almacenamiento de los datos
referentes a los signos vitales de pacientes en ubicaciones remotas y con patologías definidas.
74
8. BIBLIOGRAFIA Y FUENTES DE INFORMACIÓN
Libros y artículos
• OMS 98. Informe al Director General de la OMS a la 99.s reunión del Consejo
Ejecutivo, 6 de enero de 1998.
• CISCO SYSTEMS, Networking Basics Simple Solutions for Small Networks. 1998.
• TELECOMUNICATIONS INTERNATIONAL, Data, Image, Network, 2 de Junio de 2001.
• CONTRAN, Ranzi. Patología Estructural y Funcional, McGraw Hill.
• TANENHAUM, Andrew. Computer Networks, Prentice Hall.
• GIL, Javier. Creación de Sitios Web con PHP4, McGraw Hill.
• CASTILLO, Edgar. Las Telecomunicaciones y la Salud (Telemedicina), Universidad
del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones, 2002.
• APARICIO E, Fundamentos para desarrollo de Telemedicina, Universidad Distrital de
Colombia, 2001.
• CABRAL J. Kim Y. Multimedia Systems for Telemedicine of Their Communications
Requirements, IEEE, Communications Magazine, Jul. 1996.
• SALYER W. J. Neonatal and Pediatric Pulse Oximetry, Respiratory Care, 2003.
• CISCO SYSTEMS. Cisco Mobile Exchange, 2000.
• ISOARD S. Implementation of an Analysing and Modeling Tool of the
GSM/GPRS/EDGE. Design of a Demodulator Adapted to the Specificity of a Network
Simulator, Royal Institute of technology, 2004.
• USHA COMUNICATION TECHNOLOGY. GPRS General Packets Radio Service, 2000
• MELLBERG J. GPRS Overview Applications over GPRS. Ericsson. 2003.
• HENG Foh C, MEINI B. Modeling and Performance Evaluation of GPRS, The
University of Melbourne and Universita di Pasa. 2003.
• DELGADO Adriana, FALLA Clara, PORRAS Clara. Sistema de Monitoreo para Redes de
Banda Ancha HFC, Pontificia Universidad Javeriana, Departamento Ingeniería
Electrónica.
• WULLFFERT Alejandro, WULLFFERT Kyra. Estructuración de una Red LAN/WAN,
Pontificia Universidad Javeriana, Departamento Ingeniería Electrónica.
75
Tomado de Internet
• BENFANTE, Lucio. SQL. www.htmlpoint.com
• World Health Organization. Health Topics. 2005 www.oms.org
• LATCOM/COMUNICAR S.A. Redes metropolitana de comunicaciones. 2005
www.latcom.com.co www.comunicar.com.co
• COMCEL S.A. Tecnología GSM/GPRS. 2005 www.comcel.com
• CISCO SYSTEMS. Manuales Enrutadores. 2005. www.cisco.com
• ENFORA. Manuales técnicos modem Spyder GPRS. 2004. www.enfora.com
• DANE. Estadísticas PIB de Colombia. www.dane.gov.co
• CORTIJO, Carlos. Comportamiento del Corazón. www.suarritmia.com
• SOCIEDAD COLOMBIANA DE CIRUGÍA ORTOPEDÍA Y TRAUMATOLOGÍA.
Procedimientos Historias Clínicas. www.sccot.org.co
76
9. ANEXOS
Los anexos se encuentran en el CD adjunto a este libro y contienen la siguiente información:
• Anexo A. Estudio estado de la Telemedicina en la Región Andina.
• Anexo B. Estudio para la implementación de la definición del concepto del Hospital
virtual.
• Anexo C. Saturación del Oxigeno en la sangre.
• Anexo D. Control de Signos Vitales.
• Anexo E. Estudio de tecnologías inalámbricas semimóviles.
• Anexo F. Estudio de tecnologías médicas de medición de signos vitales.
• Anexo G. Estudio de comparación implementaciones telemonitoreo.
• Anexo H. Manuales y Procedimientos Sistema Prototipo de Telemonitoreo.
• Anexo I. Marco Teórico ampliación.
• Anexo J. Equipos Lugar Remoto y Servidor Central.
77
