Metodología de Implementación de Sistemas Médicos en Software: Sistema de Análisis de Electrocardiogramas

FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA
SISTEMA PARA REALIZAR EL DIAGNÓSTICO DE PATOLOGÍAS

CARDIOVASCULARES UTILIZANDO ELECTROCARDIOGRAMAS
IMPRESOS
TRABAJO ESPECIAL DE GRADO

Presentado ante la
UNIVERSIDAD CATÓLICA ANDRÉS BELLO
Como parte de los requisitos para optar al título de
INGENIERO EN INFORMÁTICA
REALIZADO POR VILLEGAS SAN MIGUEL, Samuel G.
PROFESOR GUÍA MAGURNO CORRO, Carlo
FECHA OCTUBRE de 2016
1
AGRADECIMIENTOS
A la Dra. Katherine Tovar, por ser la precursora de la idea que originó tema de este
trabajo.
A mi Padre y a mi Madre, por su apoyo incondicional.
Al Dr. Baltasar Saturno, por el apoyo en la investigación realizada en este trabajo.
Al Dr. Juan Carlos Belandría, por su apoyo en la realización de los diagnósticos de
prueba.
A mis amigos médicos cirujanos, sin ellos no hubiera podido encontrar la motivación
para continuar con esta investigación.
A todos aquellos que me ayudaron en mi formación académica.
2
INDICE DE CONTENIDOS
AGRADECIMIENTOS .......................................................................................................... 2
INDICE DE CONTENIDOS................................................................................................... 3
SINOPSIS ............................................................................................................................ 7
INTRODUCCIÓN ................................................................................................................. 8
CAPÍTULO I ......................................................................................................................... 9
PLANTEAMIENTO DEL PROBLEMA ............................................................................... 9
OBJETIVOS.................................................................................................................... 12
ALCANCE Y LIMITACIONES.......................................................................................... 13
JUSTIFICACIÓN ............................................................................................................. 17
CAPÍTULO II ...................................................................................................................... 18
MARCO REFERENCIAL................................................................................................. 18
II.1. Cardiología ....................................................................................................... 18
II.1.1 Electrocardiograma ..................................................................................... 18
II.1.2 Electrocardiógrafo ....................................................................................... 18
II.1.3 Aurículas ..................................................................................................... 18
II.1.4 Ventrículos .................................................................................................. 18
II.1.5 Nodo Sinusal ............................................................................................... 19
II.1.6 Nodo Atrio-Ventricular (AV) ......................................................................... 19
II.1.7 Haz de His ................................................................................................... 19
II.1.8 Despolarización Cardíaca ............................................................................ 19
II.1.9 Repolarización Cardíaca ............................................................................. 19
II.1.10 Ondas y Segmentos P-Q, Q-R-S, S-T ....................................................... 20
II.1.11 Hipertrofia Ventricular ................................................................................ 21
II.1.12 Arritmia ...................................................................................................... 22
II.1.13 Fibrilación Auricular ................................................................................... 22
II.1.14 Fibrilación ventricular ................................................................................. 22
II.2 Procesamiento Digital de Imágenes ................................................................... 23
II.2.1 OPENCV (Opensource Computer Vision) ................................................... 23
II.2.2 Coordenada Cilíndrica HSV (Hue, Saturation, Value) .................................. 23
II.2.3 Dilatación y Erosión Morfológica .................................................................. 23
II.3 Android .............................................................................................................. 24
II.3.1 AsyncHttpClient ........................................................................................... 24
II.3.2 Camera 2 API .............................................................................................. 25
II.4 C++ .................................................................................................................... 25
3
II.4.1 LibFFI .......................................................................................................... 25
II.5 Ruby On Rails .................................................................................................... 26
II.6 RubyFFI ............................................................................................................. 26
II.7 PaperClip ........................................................................................................... 26
II.8 Active Model Serializers ..................................................................................... 27
II.9 Base de Datos ................................................................................................... 27
II.10 MySQL ............................................................................................................. 27
II.11 HTTP ............................................................................................................... 27
II.12 Application Program Interface (API) ................................................................. 28
II.13 Representational State Transfer (REST) .......................................................... 28
II.14 Servicios Web .................................................................................................. 28
II.15 Metodologías de desarrollo de software Ágiles ................................................ 29
II.16 Java ................................................................................................................. 29
II.17 Distancia Euclidiana ......................................................................................... 29
II.18 Inteligencia Artificial ......................................................................................... 29
II.19 Reconocimiento de Patrones ........................................................................... 30
II.20 Red Neuronal Artificial ..................................................................................... 30
CAPÍTULO III ..................................................................................................................... 33
MARCO METODOLÓGICO ............................................................................................ 33
CAPITULO IV ..................................................................................................................... 40
DESARROLLO ............................................................................................................... 40
1. Fase Investigación v1: .......................................................................................... 40
1.1 Realizar Investigación Primaria: ......................................................................... 40
1.2 Construir base empírica: .................................................................................... 41
1.3 Validar los resultados de la investigación: .......................................................... 41
1.4 ¿Existe un patrón?: ............................................................................................ 42
2. Fase Análisis v1: .................................................................................................. 43
2.1 Seleccionar información de la investigación: ................................................. 43
2.2 Discusión de los materiales seleccionados:................................................... 43
2.3 Derivar Perspectivas e Hipótesis Clave: ........................................................ 43
2.4 Validar distintas perspectivas y opciones ..................................................... 44
2.4.1 Iteración XP 1 (Construcción Librería) .................................................... 44
2.5 ¿Las perspectivas claves llevan a una conclusión?....................................... 49
3. Fase Investigación v2: .......................................................................................... 51
3.1 Discusión del Capítulo teórico: ..................................................................... 51
3.2 Realizar Investigación Primaria: .................................................................... 52
3.3 Construir base empírica: ............................................................................... 52
4
3.4 Validar los resultados de la investigación: ..................................................... 53
3.5 ¿Existe un patrón? ........................................................................................ 53
4. Fase Análisis v2: .................................................................................................. 54
4.1 Seleccionar información de la investigación: ................................................ 54
4.2 Discusión de los materiales seleccionados:................................................... 54
4.3 Derivar perspectivas e Hipótesis Clave: ........................................................ 55
4.4 Validar distintas perspectivas e hipótesis: ..................................................... 55
4.4.1 Iteración XP 2(Construcción Servidor): .................................................. 57
4.4.2 Iteración XP 3(Construcción App): ........................................................ 60
4.4.3 Iteración XP 4(Construcción App 2):...................................................... 64
4.4.4 Iteración XP 5(Integración Servidor, App, Librería): ............................... 68
4.4.5 Iteración XP 6 (Herramienta de reportes): ............................................. 71
4.5 ¿Las perspectivas claves llevan a una conclusión?....................................... 74
5. Fase Conclusión v2: ............................................................................................. 76
5.1 Discutir sobre las perspectivas clave: ............................................................ 76
5.2 Seleccionar Material que Lleva a la Conclusión ............................................ 76
5.3 Escribir conclusión ........................................................................................ 76
5.4 Validar conclusión con perspectivas clave .................................................... 77
5.5 ¿Las conclusiones responden las preguntas de la investigación? ................. 78
CAPÍTULO V ...................................................................................................................... 80
RESULTADOS ............................................................................................................... 80
CAPITULO VI ..................................................................................................................... 84
CONCLUSIONES Y RECOMENDACIONES .................................................................. 84
CONCLUSIONES ........................................................................................................ 84
RECOMENDACIONES ............................................................................................... 87
REFERENCIAS BIBLIOGRÁFICAS ................................................................................... 88
5
INDICE DE TABLAS, FIGURAS Y ECUACIONES
Figura 1- Segmentos de un electrocardiograma [Fuente: 4.] ..................................................... 20
Ecuación 1- Teorema de Pitágoras [Fuente: 29.] ……………………………...……….……………28
Figura 2 - Metodología Implementada [Fuente Propia] ............................................................... 33
Tabla 1-Diseño de respuesta por Patología [Fuente propia]……………………….....……..……67
6
SINOPSIS
El presente trabajo especial de Grado está orientado a diseñar e implementar un sistema
informático que apoye a los profesionales de la salud, automatizando el proceso para
diagnosticar electrocardiogramas impresos. El sistema permite al usuario tomar una foto a la
señal impresa, interpretar la señal y diagnosticar la presencia de las siguientes patologías:
hipertrofia ventricular, fibrilación auricular y fibrilación ventricular.
Para satisfacer los requerimientos del sistema, se diseñaron e implementaron dos
algoritmos capaces de interpretar y diagnosticar imágenes de electrocardiogramas,
apoyados por la librería OpenCV para la interpretación de imágenes. Dichos algoritmos se
implementaron en una librería compartida, permitiendo ejecutar las funciones y métodos de
la librería sin necesidad de compilar el código.
Se desarrolló una aplicación móvil que permite al usuario gestionar la información
relacionada a los pacientes, diagnósticos y electrocardiogramas.
El diseño del sistema incluye una aplicación de servidor que utilizando servicios web
implementados utilizando un patrón de arquitectura REST, a través de la aplicación móvil se
consumen dichos servicios, permitiendo la comunicación entre la aplicación móvil y la
aplicación de servidor, además ésta aplicación de servidor se integra con la librería que
contiene la implementación de los algoritmos que realizan los diagnósticos.
El trabajo fue realizado utilizando una mezcla entre una metodología de investigación y la
metodología XP para desarrollo ágil, la librería que implementa los algoritmos diseñados fue
construida utilizando el lenguaje C++, la aplicación de servidor y la herramienta de reportes
fueron construidos utilizando el lenguaje Ruby On Rails y la aplicación móvil fue construida
utilizando el lenguaje Java para Android.
7
INTRODUCCIÓN
La medicina es una ciencia que exige a sus practicantes, consultar y actualizar sus
conocimientos constantemente, pues su objetivo principal es utilizar todos los aprendizajes
médicos comprobados en virtud de mejorar la calidad de vida de los humanos. En este
sentido los avances médicos aseguran que el objetivo de esta ciencia se alcance
satisfactoriamente.
La cardiología es la rama de la medicina que se encarga de estudiar, diagnosticar y tratar,

todo lo relacionado al corazón y el aparato circulatorio. Es evidente que la cardiología es muy
importante, pues es este órgano el encargado de dar la vida al cuerpo humano, por esto los
avances tecnológicos en esta especialidad suelen ser de los más buscados. El
electrocardiograma es la herramienta capaz de traducir el comportamiento eléctrico del
corazón, a una señal impresa que permite estudiar y diagnosticar el corazón sin intervenir al
paciente.
Los avances en la medicina se pueden alcanzar integrando tecnologías de otras ciencias,

por ejemplo, la unificación con la ingeniería informática, generalmente busca el desarrollo de
sistemas que sean capaces de automatizar los procesos de estudio, tratamiento y diagnóstico
médico.
La visión de las computadoras, es la herramienta que permite realizar procesamiento e

interpretación de imágenes. A través de esta herramienta las computadoras son capaces de
automatizar la toma decisiones, basadas en características de las imágenes; por ejemplo, los
vehículos que se manejan solos, toman las decisiones utilizando un sistema de visión de
computadoras. Esta puede utilizarse también para apoyar la medicina, pues la práctica
médica utiliza la observación e interpretación de distintos aspectos del humano para generar
diagnósticos y luego tratamientos.
El presente Trabajo Especial de Grado busca resolver las incógnitas sobre la posibilidad
de facilitar la interpretación y diagnóstico de los electrocardiogramas, a través de la
implementación de una herramienta informática, que utiliza la visión de computadoras para
detectar patrones y arrojar resultados que apoyen la práctica médica.
8
CAPÍTULO I
PLANTEAMIENTO DEL PROBLEMA
Según la Organización mundial de la salud la causa principal de muerte en el mundo son
las enfermedades cardiovasculares (ECV), un estimado de 17.5 millones de personas
murieron en el 2012 por ECV, muchas de estas muertes pueden ser evitadas disminuyendo
algunos factores que aumenten el riesgo, pero el diagnóstico de las mismas es crucial para
tomar decisiones correctas a la hora de salvar la vida del paciente.
La herramienta más utilizada para diagnosticar las patologías cardiovasculares es el
electrocardiograma que consiste en la representación gráfica de las señales eléctricas del
corazón, se obtiene utilizando un electrocardiógrafo y su interpretación tiene la capacidad de
diagnosticar infartos, arritmias, fibrilaciones, braquicardias, entre otras patologías
cardiovasculares.
El diagnóstico rápido y exacto de los pacientes que llegan a las salas de emergencia, es
crucial para poder atender sus necesidades y hacer todo lo posible para resolver la patología
que presentan. Muchas veces el personal de la salud doctores, enfermeras, entre otros, se
encuentran en la necesidad de administrar medicamentos a los pacientes sin tener certeza
total del diagnóstico, pues muchas veces conocer el diagnóstico exacto puede tardar más
tiempo que el que dispone la vida del paciente.
Si bien es cierto que el examen de electrocardiograma se realiza en pocos minutos y los
resultados del electrocardiógrafo se imprimen casi inmediatamente, la interpretación y
diagnóstico exacto del electrocardiograma, depende de la experiencia de la persona que lo
está leyendo. Incluso existe personal de la salud que no está capacitado para la lectura de
los electrocardiogramas por lo que deben esperar a que alguien capacitado lo realice.
El electrocardiograma está compuesto de varias ondas generadas por las señales
eléctricas producidas por el corazón, estas ondas forman segmentos que se utilizan para
generar los diagnósticos. Las ondas que conforman un electrocardiograma son denominadas
9
P, Q, R, S y T, cada una de ellas es una elevación o una depresión en la onda debido a la
polarización y despolarización de las células del corazón, que hacen que ocurra la
contracción y relajación de los músculos del corazón.
El segmento o la onda P es la representación de la actividad eléctrica detectada en la
superficie del cuerpo cuando ocurre la despolarización miocardial auricular, el segmento Q-
R-S representa la actividad eléctrica en el cuerpo cuando ocurre la despolarización ventricular
miocardial, y por último, la onda o segmento T es la representación eléctrica cuando ocurre
la repolarización miocardial ventricular.
“Estas ondas en condiciones normales generan los segmentos P-Q, Q-R-S y S-T, si este
orden está presente en el electrocardiograma se puede decir que existe un ritmo sinusal que
indica un estado normal del corazón.” [1]
El electrocardiograma utilizado hoy en día es un electrocardiograma de doce derivaciones,
cada una analiza eléctricamente el corazón desde un ángulo del cuerpo; éstas derivaciones
nos presentarán los segmentos y las ondas P, Q, R, S y T, utilizando estas derivaciones en
conjunto con los patrones de orden de éstas ondas y segmentos se podrá entonces observar
el ritmo cardíaco del paciente y diagnosticar las patologías cardiovasculares. [1]
Para identificar cambios en el ritmo del corazón y diagnosticar arritmias es necesario
analizar las distancias entre los segmentos Q-R-S, si estas distancias permanecen dentro de
un rango, entonces existe un ritmo regular, pero si la distancia entre los segmentos Q-R-S
varía notablemente puede existir una arritmia.
Al momento de identificar un infarto en el corazón se analiza el comportamiento de la onda
Q, se buscan elevaciones o depresiones en el segmento S-T y se buscan ondas T invertidas,
utilizando las diferentes derivaciones entonces se puede realizar un diagnóstico sobre qué
parte del corazón ha ocurrido el infarto.
Cuando se busca identificar y diagnosticar una fibrilación se debe analizar la ausencia de
las ondas P y T, también se puede encontrar un patrón errático que da a conocer una
10
fibrilación ventricular, el paciente que presenta esta patología debe ser atendido
inmediatamente.
Debido a lo expuesto se puede concluir que existe la necesidad de una herramienta
tecnológica, que ayude a realizar un diagnóstico y una interpretación de electrocardiogramas;
por lo que se plantea la realización de una herramienta que corra en dispositivos móviles,
apoyada por una aplicación de servidor, en la cual se ejecute un algoritmo de procesamiento
de imágenes y un algoritmo de diagnóstico de patologías para identificar las patologías
cardiovasculares presentes en el electrocardiograma y así ayudar al personal de la salud a
obtener un diagnóstico del paciente.
11
OBJETIVOS
OBJETIVO GENERAL
Desarrollar un sistema informático que ayude a interpretar electrocardiogramas de
doce derivaciones, para identificar las patologías cardiovasculares más comunes
diagnosticadas a través de los electrocardiogramas.
OBJETIVOS ESPECÍFICOS
Diseñar e implementar una aplicación móvil capaz de recopilar y enviar la información
necesaria para realizar la interpretación de electrocardiogramas.
Diseñar e implementar un algoritmo de procesamiento de imágenes para
electrocardiogramas.
Diseñar e implementar un algoritmo de reconocimiento de patrones que con ciertos niveles
de tolerancia pueda diagnosticar patologías en los electrocardiogramas.
Diseñar e implementar una aplicación de servidor que, utilizando los algoritmos planteados,
reciba las imágenes de los electrocardiogramas, las interprete y diagnostique; para enviar la
respuesta a la aplicación móvil.
Diseñar e implementar una aplicación web, que sea capaz de generar reportes sobre las
patologías identificadas, filtradas por la información básica del paciente.
Realizar las pruebas necesarias en conjunto con un médico especialista para analizar y
verificar el nivel de confianza de los diagnósticos generados por el sistema.
12
ALCANCE Y LIMITACIONES
ALCANCE
A continuación, se detalla el alcance por cada uno de los objetivos específicos
planteados.
Diseñar e implementar una aplicación móvil capaz de recopilar y enviar la información
necesaria para realizar la interpretación de electrocardiogramas.
o Diseñar e implementar un módulo que gestione el dispositivo de cámara trasera para la
captura y enviado de las imágenes con un apoyo visual para alinear el
electrocardiograma con la aplicación y la selección de la derivación relacionada a la
imagen.
o Definir escala de pixeles por centímetros para realizar los cálculos necesarios a la hora
de diagnosticar patologías que requieran de cálculos de distancia en centímetros.
o Diseñar e implementar las funcionalidades para gestionar los pacientes en el servidor
con las operaciones de agregar y consultar.
o Diseñar e implementar las funcionalidades para gestionar las consultas de los
electrocardiogramas y el diagnóstico de los electrocardiogramas por paciente.
o Diseñar e implementar las vistas para el uso de las distintas funcionalidades
desarrolladas.
Diseñar e implementar un algoritmo de procesamiento de imágenes para
o Definir rango de colores en HSV para extraer de la imagen solamente la gráfica que
describe el electrocardiograma.
o Definir parámetros de erosión y dilatación para disminuir la cantidad de ruido en la
imagen obtenida.
o Diseñar e implementar el algoritmo de extracción y reducción de ruido de la señal en la
imagen utilizando las herramientas de la OpenCV cuya salida sea un vector de
coordenadas X y Y que describa la señal del electrocardiograma.

13
Diseñar e implementar un algoritmo de reconocimiento de patrones que con ciertos niveles
de tolerancia pueda diagnosticar patologías en los electrocardiogramas.
o Diseñar e implementar un método para identificar los distintos segmentos y ondas P-
Q-R-S-T existentes en un electrocardiograma.
o Definir los patrones y condiciones bajo las cuales se basa el diagnóstico de las
patologías en los electrocardiogramas.
o Implementar un método para detectar patrones y condiciones con niveles de tolerancia
en cada uno de los segmentos y ondas P-Q-R-S-T, que sea capaz de determinar si se
cumplen las condiciones y patrones para diagnosticar las distintas patologías en los
electrocardiogramas
o Diseñar e implementar un método para mostrar los resultados de los diagnósticos de
manera simple.
Diseñar e implementar una aplicación de servidor que, utilizando los algoritmos planteados,
reciba las imágenes de los electrocardiogramas, las interprete y diagnostique; para enviar la
respuesta a la aplicación móvil.
o Diseñar patrones, estándares y protocolos de comunicación entre el servidor y los
dispositivos clientes.
o Implementar un servidor con servicios web consumibles bajo los estándares web
actualizados que sea capaz de gestionar la información y archivos relacionados a
pacientes, electrocardiogramas y diagnósticos.
o Diseñar e implementar una arquitectura de base de datos que soporte las necesidades
del proyecto.
o Implementar una librería de diagnóstico con los algoritmos planteados en los objetivos
anteriores que sea capaz de arrojar un diagnóstico de la imagen de una derivación
perteneciente a un electrocardiograma.
o Integrar la librería de diagnóstico con la aplicación de servidor para gestionar los
diagnósticos de las imágenes que describen las derivaciones en los
14
Diseñar e implementar una aplicación web, que sea capaz de generar reportes sobre las
patologías identificadas, filtradas por la información básica del paciente.
o Diseñar e implementar las consultas sobre los elementos existentes en la base de datos
que satisfagan los reportes necesarios.
o Diseñar e implementar los reportes sobre las patologías identificadas utilizando las
consultas desarrolladas.
o Diseñar e implementar las vistas para la gestión de los filtros y visualización de los
reportes utilizando algunos criterios de usabilidad.
Realizar las pruebas necesarias en conjunto con un médico especialista para analizar y
verificar el nivel de confianza de los diagnósticos generados por el sistema.
o Investigar y recopilar un conjunto de distintas imágenes que describan derivaciones de
o Analizar y diagnosticar en conjunto con un médico especialista las distintas
derivaciones con la finalidad de categorizar los electrocardiogramas y obtener una
muestra de derivaciones que no presenten ninguna patología, una muestra de
derivaciones que presenten Hipertrofia Ventricular, una muestra de derivaciones que
presenten Fibrilación Auricular y una muestra de derivaciones que presenten Fibrilación
Ventricular.
o Analizar y diagnosticar las distintas derivaciones utilizando el sistema desarrollado.
o Analizar y comparar los resultados obtenidos en ambos experimentos para concluir el
porcentaje de aciertos del sistema.
15
LIMITACIONES
A continuación, se listan las limitaciones del alcance en este proyecto:
El sistema solo será capaz de diagnosticar tres patologías, Hipertrofia Ventricular,
Fibrilación Ventricular y Fibrilación Auricular
El sistema solo funcionará en dispositivos móviles Android que dispongan de una cámara
y conexión a internet.
El usuario deberá alinear la línea base del electrocardiograma y la longitud del
electrocardiograma con la ayuda visual en la aplicación para el correcto funcionamiento
del diagnóstico.
Las imágenes deben ser capturadas sin el uso del Flash y con buena iluminación para
su interpretación.
El sistema solo diagnosticará electrocardiogramas que estén impresos en la velocidad
25mm/s.
El sistema de reportes filtrará las patologías por: Edad y Género.
La librería de diagnóstico será compilada en el sistema operativo MAC OSX limitando el
uso de la misma a este sistema operativo.
16
JUSTIFICACIÓN
Tal como se adelantó en el Planteamiento del Problema, en los últimos años en el área
de la medicina se han realizado grandes avances tecnológicos, buscando integrar las
herramientas tecnológicas con el conocimiento de la medicina para crear herramientas que
puedan dar apoyo a los profesionales de la salud a realizar un mejor trabajo.
En la actualidad no existe una herramienta de fácil acceso, que ayude a diagnosticar
patologías cardiovasculares interpretando electrocardiogramas. Existen algunos grupos de
investigación que se encuentran en este momento desarrollando sistemas para identificación
de electrocardiogramas, pero estos sistemas requieren de grandes capacidades de
procesamiento y software especializado.
Es necesario que existan algoritmos para el procesamiento de las imágenes que capturan
las derivaciones de los electrocardiogramas y algoritmos de reconocimiento de patrones para
la interpretación de los electrocardiogramas; que utilizando la capacidad de procesamiento
de un computador e implementados en una herramienta, que se encuentre al alcance de los
especialistas de la salud, pueda brindarles un apoyo para realizar un diagnóstico.
Se plantea entonces una herramienta utilizada en dispositivos móviles de fácil distribución,
que, apoyada por un algoritmo de procesamiento digital de imágenes, identifique la y extraiga
la señal de la imagen de un electrocardiograma, para luego apoyarse en un algoritmo de
reconocimiento de patrones que sea capaz de dar una interpretación y finalmente un
diagnóstico de patologías cardiovasculares presentes en el electrocardiograma.
17
CAPÍTULO II
MARCO REFERENCIAL
El siguiente capítulo expone los conceptos teóricos necesarios para el entendimiento del
proyecto desarrollado.
II.1. Cardiología
II.1.1 Electrocardiograma
“El electrocardiograma (ECG) es el registro gráfico de la actividad eléctrica del corazón,
detectada a través de una serie de electrodos, colocados en la superficie corporal y
conectados a un electrocardiógrafo.” [1]
II.1.2 Electrocardiógrafo
“El electrocardiógrafo es un aparato electrónico que capta y amplía la actividad eléctrica
del corazón a través de electrodos colocados en el cuerpo. El resultado de la actividad
eléctrica se capta en un Electrocardiograma.” [1]
II.1.3 Aurículas
Las aurículas son las dos cavidades superiores del corazón separadas por un tabique y
situadas encima de los ventrículos, con los que se comunican a través de sendos orificios
atrio-ventriculares dotados de válvulas para el bombeo de la sangre. [2]
II.1.4 Ventrículos
Los ventrículos son las dos cavidades inferiores del corazón, situados debajo de las
aurículas, estos reciben la sangre de las cavidades superiores y gracias a que sus paredes
están compuestas de células musculares permiten la contracción y relajación de estas
paredes para el bombeo de la sangre a todo el cuerpo. [2]
18
II.1.5 Nodo Sinusal
El Nodo Sinusal (SA) o Nodo de Keith y Flack es una de las estructuras que compone el
Sistema de conducción del corazón, recibe el nombre común de marcapasos del corazón.
En este nodo es donde se origina el impulso eléctrico que da origen al latido del corazón. Se
encuentra en la parte superior de la aurícula derecha, bajo la desembocadura de la vena
cava superior. [3]
II.1.6 Nodo Atrio-Ventricular (AV)
El nodo Atrio-ventricular o de Aschoff-Tawara es otra de las estructuras que compone el
Sistema de conducción en el corazón, está encargado de coordinar la parte superior del
corazón y conecta eléctricamente las cámaras auriculares y ventriculares. [3]
II.1.7 Haz de His
El Haz de His es una formación intracardiaca que también forma parte del sistema de
conducción del corazón, consiste en un fino cordón muscular que transmite el impulso
eléctrico desde el nodo atrio-ventricular hacia las ramas facisculares, estas ramas luego
transmiten el impulso eléctrico a las fibras de Purkinje, causando la contracción muscular de
los ventrículos y produciendo el latido. [3]
II.1.8 Despolarización Cardíaca
La despolarización cardíaca es el cambio de carga eléctrica negativa a positiva en las
membranas musculares del corazón, cuando el impulso eléctrico pasa por dichas membranas
para que ocurra la contracción del miocardio. [1]
II.1.9 Repolarización Cardíaca
La repolarización cardíaca es el cambio de carga eléctrica positiva a negativa, en las
membranas musculares del corazón, cuando el impulso eléctrico ya pasó por las membranas
y ocurre la relajación del miocardio. [1]
19
II.1.10 Ondas y Segmentos P-Q, Q-R-S, S-T
Los electrocardiogramas se dividen en distintas ondas y segmentos, utilizados para
identificar los cambios de voltaje en los distintos momentos de un latido, cada latido en un
electrocardiograma, como se menciona en el Manual AMIR [4], está compuesto por los
siguientes elementos:
- Onda P: “Es la representación
electrocardiográfica de la despolarización de
ambas aurículas. El estímulo normal originado a
nivel sinusal se propaga inicialmente a la aurícula
derecha y posteriormente a la izquierda, siendo la
onda P el resultado final de la transmisión del
impulso eléctrico a ambas.” [4.]
- Intervalo PR: “Es la representación del

Figura 1- Segmentos de un
tiempo de conducción aurículo-ventricular. Se electrocardiograma [Fuente: 4.]
mide desde el inicio de la onda P hasta el comienzo del segmento QRS. Incluye la
despolarización auricular y posterior paso del impulso por el nodo AV, Haz de His y sus dos
ramas, hasta los ventrículos.” [4]
- Complejo QRS: “Este complejo o segmento corresponde a la despolarización
ventricular, fundamentalmente del ventrículo izquierdo por su mayor masa respecto al resto
del corazón.” [4]
Dentro de este complejo se encuentran las ondas Q, R y S, cada onda se identifica en
función de:
- Si el inicio del QRS es negativo, esa onda se llama onda Q (o la onda negativa que
precede a la onda R).
20
- Todas las ondas positivas se llaman R. Si se observa más de una onda R en un mismo
complejo se denominarán sucesivamente R y R'.
- Las ondas negativas que aparecen tras una onda R, se llaman S.
- Punto J: “El punto J es aquel punto de deflexión que marca el final del complejo QRS e
inicio del trazado del segmento ST.” [4]
- Segmento ST: “Segmento normalmente isoeléctrico con respecto al segmento PR o el
segmento TP, que comienza en el punto J y finaliza en el comienzo de la onda T.” [4]
- Onda T: “Esta onda es originada por la repolarización de los ventrículos.” [4]
II.1.11 Hipertrofia Ventricular
La hipertrofia ventricular es una patología que consiste en el ensanchamiento del grosor
en las paredes del musculo cardiaco que conforman los ventrículos tanto derecho como
izquierdo, esta patología causa que el ventrículo debe realizar un mayor esfuerzo para
contraerse. [5]
Para diagnosticar esta patología se puede utilizar el electrocardiograma aplicando los
criterios de Sokolow-Lyon, que se divide en dos criterios a su vez o el criterio de voltaje de
Cornell. Cuando alguno de estos criterios se cumple se puede decir que existe presencia de
la patología.
El primero consiste en sumar el tamaño en milímetros de la onda S en V1 más el tamaño
de la onda R en V5 o en V6 y si el resultado es mayor a 35mm se cumple el criterio y el
segundo consiste en que si el tamaño de la onda R en la derivación aVL es mayor a 11mm
se cumple el criterio, o el criterio de voltaje de Cornell, que consiste en sumar la onda R en
la derivación aVL mas la onda S en la derivación V3 y si el resultado en mujeres es mayor a
20mm o 28 en hombres el criterio se cumple. [6]
21
II.1.12 Arritmia
“Una arritmia es cualquier trastorno en los latidos o el ritmo del corazón. Significa que, si
el corazón late demasiado rápido, demasiado lento o tiene un patrón irregular existe una
arritmia. Cuando el corazón late más rápido de lo normal se denomina taquicardia y cuando
late demasiado lento se llama braquicardia.“ [7]
II.1.13 Fibrilación Auricular
“La arritmia crónica más común es la fibrilación auricular causada por un problema en el
sistema eléctrico en el corazón, esta patología es extremadamente frecuente en la práctica
diaria y que por tanto hay que saber reconocer rápidamente.” [4]
Para diagnosticar esta patología utilizando un electrocardiograma hay que fijarse en los
siguientes elementos:
- “No existen ondas P. La línea basal se sustituye por una ondulación sutil, irregular y
rápida conocida como ondas “f”. Esto ocurre porque en presencia de esta patología no existe
un foco concreto de descarga, si no que el impulso eléctrico se genera por la presencia de
múltiples frentes simultáneos que causan circuitos de reentrada diversos, los cuales chocan
e interfieren entre si provocando esa activación irregular y caótica de las aurículas.” [4]
- “Esta patología se caracteriza por ser una arritmia “irregularmente irregular”. Es decir,
no solo observaremos que los intervalos RR son variables si no que dicha irregularidad no
sigue un patrón concreto, es completamente aleatorio.” [4]
II.1.14 Fibrilación ventricular
Esta patología consiste en una fibrilación que es una contracción o temblor incontrolable
de las fibras musculares (fibrillas), cuando dicha fibrilación ocurre en las fibras musculares
que forman parte de los ventrículos se denomina fibrilación ventricular. Durante la fibrilación
ventricular, la sangre no se bombea desde el corazón, lo que da como resultado la muerte
cardíaca súbita. [7]
22
La causa más común de fibrilación ventricular es un ataque cardíaco; sin embargo, esta
fibrilación puede ocurrir en cualquier momento en el que el miocardio no reciba suficiente
oxigeno por cualquier razón.
Para diagnosticar esta patología utilizando un electrocardiograma observaremos actividad
ventricular absolutamente irregular y desordenada, sin un patrón fijo. Podemos también
visualizar bandas anchas, irregulares, aberrantes y polimórficas, u ondas de bajo voltaje
irregulares entre las cuales no es posible identificar los complejos Q-R-S normales. [7]
II.2 Procesamiento Digital de Imágenes
II.2.1 OPENCV (Opensource Computer Vision)
Es una librería de código abierto de visión digital, desarrollada en C y C++, adaptada para
ser utilizada en distintos sistemas operativos. Principalmente fue creada para maximizar la
eficiencia en procesamiento de imágenes en tiempo real. [8].
II.2.2 Coordenada Cilíndrica HSV (Hue, Saturation, Value)
La coordenada cilíndrica HSV (Matiz, Saturación, Valor), es una forma de representación
de los colores que conforman una imagen. Dicha matriz divide en tres canales la
representación de los colores que son:
- Matiz: Representa los colores de la imagen y puede tener un valor numérico
entre 0 y 360.
- Saturación: Representa el porcentaje de tonalidad grisácea que existe en la
imagen y naturalmente puede tomar un valor numérico entre 0 y 100.
- Valor: Representa el porcentaje de luminosidad o brillo de la imagen y al igual
que la saturación puede tomar un valor entre 0 y 100. [9].
II.2.3 Dilatación y Erosión Morfológica
- Dilatación de una imagen: representa uno de los dos operadores básicos en el área
de la matemática morfológica. Típicamente se aplica a imágenes binarias, pero existen

23
versiones que funcionan con imágenes en escala de grises. El efecto básico del operador
en una imagen binaria es gradualmente agrandar los límites de las regiones en los
pixeles de primer plano, por lo tanto, agranda el área de los pixeles y achica los huecos
existentes. [10].
- Erosión de una imagen: representa el segundo operador básico en el área de la
matemática morfológica. Típicamente se aplica a imágenes binarias, pero también puede
ser aplicado a imágenes en escala de grises al igual que la dilatación. Su efecto básico
en una imagen binaria es el de erosionar los límites de los pixeles de primer plano con
la finalidad de achicar el área de los pixeles y agranda el área de los huecos existentes
en la región aplicada. [10].
La combinación y aplicación de estos dos operadores matemáticos sobre las imágenes
resulta en la reducción de los ruidos e imperfectos que una imagen pueda tener, facilitando
su posterior análisis.
II.3 Android
Android es una pila de software abierto creado para una gran amplia gama de dispositivos
con distintos factores de forma. Los principios principales de Android son crear una
plataforma disponible para portadores, productores de equipos originales u OEMs por sus
siglas en inglés y desarrolladores para que puedan hacer sus ideas innovadoras realidad, e
introducir un producto exitoso del mundo real que mejora la experiencia de los usuarios en
los dispositivos móviles. [11]
II.3.1 AsyncHttpClient
AsyncHTTPClient es una librería desarrollada en Java cuyo propósito es permitir, en las
aplicaciones donde sea utilizada, la ejecución de peticiones HTTP y el procesamiento de las
respuestas HTTP de manera asíncrona.
24
Aquellas aplicaciones que se ejecutan en dispositivos con recursos limitados, por ejemplo,
en los dispositivos móviles, la ejecución y procesamiento de las peticiones HTTP debería
manejarse de manera asíncrona.
Debido a la naturaleza de Android, las aplicaciones que realicen estas tareas en el hilo
principal del programa generaran un error evitando el uso adecuado de la aplicación. [12].
II.3.2 Camera 2 API
El paquete android.hardware.camera2 provee una interfaz para utilizar los dispositivos de
cámara individuales conectados a un dispositivo Android, en la implementación de
aplicaciones y reemplaza la clase obsoleta Camera.
Este paquete modela un dispositivo de cámara como un pipe, que acepta solicitudes de
entrada de la cámara para capturar una sola imagen por solicitud y luego arroja de salida un
resultado de la captura como un paquete de metadata. [13].
II.4 C++
C++ es un lenguaje de programación de propósito general, diseñado para hacer la
programación mucho más agradable para los programadores serios. A excepción de algunos
pequeños detalles, C++ es un superconjunto del lenguaje de programación C.
Adicionalmente a las facilidades provistas por C, C++ proporciona métodos flexibles y
eficientes para definir nuevos tipos. [14].
II.4.1 LibFFI
LibFFI es una librería escrita en C y C++ que provee una interfaz portatil de alto nivel de
programación a varias convenciones para realizar llamadas a las funciones entre distintos
lenguajes. Esto permite a los programadores llamar cualquier función especificada en una
interfaz de función foránea en tiempo de ejecución.
25
Una interfaz de función foránea o FFI es el nombre popular para la interfaz que permite
que código implementado en algún lenguaje de programación pueda utilizar código
implementado en un lenguaje distinto. [15].
II.5 Ruby On Rails
Rails es un framework para desarrollo web escrito en el lenguaje de programación Ruby.
Está diseñado para hacer la programación de aplicaciones web más sencilla, tomando
asunciones acerca de que es lo que todo desarrollador necesita para empezar. Permite
reducir significativamente la cantidad de código escrito en comparación con cualquier otro
lenguaje o framework. Desarrolladores experimentados en este framework reportan que
también hacen la programación web más divertida. [17]
Además, la comunidad de Rails ofrece una gran cantidad de gemas bien mantenidos,
éstas son paquetes instalables con funcionalidades ya implementadas facilitando el trabajo
de los desarrolladores.
II.6 RubyFFI
RubyFFI es una gema que permite la posibilidad de cargar librerías dinámicas, enlazar
funciones entre ellas y llamar las distintas funciones desde el código de Ruby. Esta gema
brinda a los desarrolladores de Ruby, acceso a librerías desarrolladas en distintos lenguajes
generando la posibilidad de extender este lenguaje para su uso en distintos campos. [19]
II.7 PaperClip
PaperClip es una gema que funciona como un plugin para las clases de Ruby on Rails
que permite trabajar los archivos como cualquier otro atributo, facilitando así el trabajo a los
desarrolladores al momento de utilizar imágenes o archivos, brindándoles la posibilidad de
utilizar, referenciar, mostrar y modificar estos archivos como cualquier atributo de tipo String,
int, etc. [20]
26
II.8 Active Model Serializers
Active Model Serializers es una gema que habilita la convención sobre la configuración
planteada en Rails a la generación de archivos JSON, estableciendo estándares web para la
generación de dichos archivos y asegurándose que se cumplan en cualquier momento. Esta
gema funciona utilizando dos componentes: serializadores y adaptadores.
Los serializadores describen cuales atributos y relaciones deberían ser serializadas y los
adaptadores describen como los atributos y las relaciones deben ser serializadas. [21].
II.9 Base de Datos
Una base de datos en informática es usualmente una colección de datos o partes de
información organizada especialmente para su búsqueda y acceso rápido, a través de una
computadora. [22]
II.10 MySQL
MySQL es un sistema para el manejo de base de datos o DBMS por sus siglas en ingles.
Para gestionar las operaciones de agregar, acceder y procesar datos en una base de datos
se necesita un DBMS y como las computadoras están preparadas para manejar grandes
cantidades de datos, estos sistemas DBMS juegan un rol importante en la computación como
utilidades autónomas o como partes de otras aplicaciones. [23].
II.11 HTTP
El Protocolo de Transferencia de Hipertexto o HTTP por sus siglas en ingles es un
protocolo de aplicación para sistemas de información con hipermedia colaborativa y
distribuida. HTTP es el pilar de la comunicación de datos para la World Wide Web. Es un
protocolo genérico que puede ser utilizado para otras tareas a través de la extensión de sus
métodos de petición, códigos de error y encabezados. [24].
27
Dicho protocolo ofrece cinco métodos principales para gestionar información, siendo
estos: GET, POST, PUT, PATCH y DELETE cada uno de ellos corresponde a las actividades
de creación, consulta, modificación y eliminación de entidades en los sistemas.
II.12 Application Program Interface (API)
Una Interfaz de Aplicación de Programa o API por sus siglas en inglés, es esencialmente
un contrato, en el cual los desarrolladores que utilicen las mismas pueden confiar,
aumentando la facilidad de uso. El contrato también permite una conexión entre el proveedor
y el consumidor de una manera mucho más eficiente ya que las interfaces son
documentadas, consistentes y predecibles. [25]
II.13 Representational State Transfer (REST)
Representational State Transfer o REST es un estilo arquitectónico que consiste en un
conjunto coordinado de componentes, conectores y elementos de datos en un sistema de
distribución de hipermedia, donde el foco se encuentra en los roles de componentes y el
conjunto especifico de interacciones entre elementos de datos en vez de en detalles de
implementación. Su propósito es introducir rendimiento, escalabilidad, simplicidad,
mutabilidad, visibilidad, portabilidad y confiabilidad. REST es el estilo arquitectónico de
software de la World Wide Web. [25]
II.14 Servicios Web
Un servicio web es un sistema de software diseñado para apoyar la interacción
interoperable de máquina a máquina a través de una red. Para lograr esto tiene una interfaz
descrita en un formato procesable por máquinas. [25
Esto permite realizar conexiones entre distintos dispositivos a través de la red permitiendo
la integración de distintos componentes para formar un sistema completo que satisfaga.
28
II.15 Metodologías de desarrollo de software Ágiles
“El desarrollo ágil de software, no es más que una metodología de gestión de proyectos
adaptativa, que permite realizar, proyectos de desarrollo de software, adaptándote a los
cambios y evolucionando en forma conjunta” [26.p13]
Estas metodologías utilizan métodos de ingeniería basados en el desarrollo iterativo e
incremental. Estos métodos minimizan los posibles riesgos que se pueden presentar a la
hora del desarrollo de proyectos de software, atacando los problemas planteados en periodos
de tiempo cortos y generando resultados para su rápida validación y en caso de ser necesario
corrección.
II.16 Java
Java es un lenguaje de programación orientado a objetos, “Sun caracteriza a Java como
un lenguaje sencillo, orientado a objetos, distribuido, interpretado, robusto, seguro,
independiente de las arquitecturas, portable, eficaz, multihilo y dinámico”. [28]
Este lenguaje tiene la característica de ejecutarse sobre una máquina virtual
especialmente dedicada a esto, convirtiéndolo en un lenguaje multiplataforma sin necesidad
de recompilar los códigos.
II.17 Distancia Euclidiana
La distancia entre dos puntos es la longitud del camino que los conecta. En el plano la
distancia entre los puntos (x1, y1) y (x2, y2) está dada por el teorema de Pitágoras: [30]
𝑑 = √(𝑥2 − 𝑥1)2 + (𝑦2 − 𝑦1)2
Ecuación 2- Teorema de Pitágoras [Fuente: 29.]
II.18 Inteligencia Artificial
“La inteligencia artificial es una de las ramas de la Informática que posee fuertes raíces en
otras áreas como la lógica humana y las ciencias cognitivas. Nace como un estudio filosófico
29
del razonamiento humano mezclado con el interés del hombre de querer imitarse a sí mismo,
buscando la necesidad de emular y generar comportamientos humanos en máquinas
creadas por el hombre.” [30]
II.19 Reconocimiento de Patrones
“El reconocimiento de patrones es una técnica utilizada en la informática que tiene como
objetivo clasificar un conjunto de elementos (u objetos) mediante la asociación de sus
características y propiedades.“ [31]
II.20 Red Neuronal Artificial
Una red neuronal artificial (RNA) es una de las técnicas inspiradas en la naturaleza
humana, que son utilizadas en la implementación de la inteligencia artificial. Es un paradigma
que está planteado para emular la forma en la que el cerebro humano procesa la información.
Entre todas las implementaciones de estas redes una de las más comunes es el
reconocimiento de patrones a través de un proceso de aprendizaje [32].
II.21 Estándares de las Arquitecturas basadas en REST
Los estándares que aseguran las mejores prácticas las encontramos en RESTFul Web
Services de L. Richardson & S. Ruby [36] donde expresa que dichos estándares son:
- Orientación hacia los recursos:
Como se menciona en el libro RESTFul Web Services [35], toda cosa interesante que la
aplicación maneje debe ser expuesta como un recurso, es decir las entidades o modelos
que componen el proyecto deben ser un recurso.
Todo recurso debe tener al menos un nombre y ser único para identificar dicho recurso,
de esta manera se puede referenciar los distintos recursos desde diferentes contextos.
El cliente no debe acceder a los recursos, se necesita un servicio web como
representación de dichos recursos una especie de documento en formato específico que
contiene la información del recurso.
30
El acceso a los recursos debe ser manejado por la interfaz del protocolo HTTP y la
implementación de sus métodos básicos (GET, POST, PUT y DELETE).
- Adressability (Capacidad de Direccionamiento):
Un servicio web tiene capacidad de direccionamiento si expone los aspectos interesantes
del conjunto de datos, a través de recursos.
Las representaciones deben por lo tanto ser también direccionables por lo tanto un
identificador no debe nunca representar más de un recurso. [35]
- State and Statelessness (Estado y Falta de Estado):
Existen dos tipos de estado en un servicio REST, el estado del recurso que es la
información acerca de los recursos y el estado de la aplicación, que es información acerca
de la ruta que el cliente ha tomado a través de la aplicación.
El estado del recurso debe permanecer en el servidor y solamente se envía al cliente a
través de representaciones y el estado de aplicación permanece del lado del cliente hasta
que pueda ser utilizado para crear, modificar o eliminar algún recurso; cuando es utilizado
se envía al servidor como parte de una petición HTTP.
Un servicio REST es “stateless” o no tiene estado si el servidor nunca almacena el estado
de la aplicación, en una aplicación sin estado, el servidor considera cada petición de
cliente de manera aislada y en términos del estado actual del recurso. [35]
- Connectedness (Conectividad):
El servidor puede guiar al cliente de un estado de aplicación a otro estado de aplicación
enviando links y formularios en sus representaciones, esto se llama conectividad porque
los links y los formularios conectan los recursos entre ellos.
En un servicio bien conectado, el cliente puede tomar una ruta a través de la aplicación
siguiendo links y llenando formularios, por el contrario, un servicio que no está bien
conectado el cliente debe usar reglas predefinidas para construir los links que quiere
visitar. [35.]
31
- The Uniform Interface (Interface Uniforme):
Toda la interacción entre los clientes y los recursos es mediada a través de los cuatro
métodos básicos del protocolo HTTP. Cualquier recurso expone varios o todos los
métodos, y un método hace lo mismo en cada recurso que lo soporta.
Esto quiere decir que para todos los recursos los métodos GET, POST, PUT y DELETE,
deben realizar exactamente la misma acción sobre los recursos que lo habilitan y se debe
mantener uniforme, si se requiere de algún método especial adicional se recomienda
realizar una sobrecarga de memoria en el método POST. [35]
- Safety and Idempotence (Seguridad e Idempotencia)
Una petición del método GET debería ser segura: un cliente que realiza una petición
GET no requiere de ningún cambio al estado del servidor. El servidor decide si debe o no
cambiar su estado, pero no debe responsabilizar al cliente por esos cambios.
Además, los métodos GET, PUT y DELETE deben ser idempotentes, esto significa que
realizar cualquier número de peticiones con estos métodos debería tener el mismo efecto
que realizar uno solo.
Se considera una mala práctica, por ejemplo, implementar un método PUT que ejecute
alguna acción como “incrementar valor por 5”, hacer 10 peticiones PUT como esa es muy
diferente que hacer solo una. Por lo tanto, las peticiones PUT deberían utilizar valores
específicos en los elementos de los recursos. [35]
32
CAPÍTULO III
MARCO METODOLÓGICO
El Trabajo Especial de Grado (TEG) realizado se planificó y desarrolló bajo una
combinación de dos metodologías. Una metodología de estudio para la realización de la
investigación y una metodología ágil para el desarrollo de los instrumentos utilizados.
El siguiente grafico expone la mezcla de ambas metodologías y cómo se integran para
estructurar el presente trabajo.
Figura 2 Metodología Implementada [Fuente Propia]

El primer caso, la metodología para realizar una investigación, se basa en un modelo
iterativo conceptual de investigación planteado en Accelerating Success: A Study of Seed
Accelerators and Their Defining Characteristics [33.], que permite adaptar la estructura del
trabajo dependiendo de los resultados obtenidos en el proceso.
Esta metodología se enfoca en apoyar aquellas investigaciones sobre temas de los cuales
existan pocas tesis académicas y permite generar conclusiones sobre los resultados
generados en la fase de análisis, sobre distintas las perspectivas planteadas en el desarrollo
de la investigación y se basa en un modelo iterativo que habilita la adaptabilidad del trabajo.

33
Como mencionan L. Barrehag y V. Mårdström [33.] la metodología se divide en tres
grandes fases por las cuales se itera suficientes veces hasta llegar a una conclusión. Las
fases son las siguientes:
- Investigación:
En esta fase se enfoca en recopilar suficiente cantidad de información y analizarla para
construir una base empírica sobre la teoría analizada y el posible comportamiento de
los experimentos a realizarse. Posteriormente utilizando esta base empírica se deben
analizar los resultados obtenidos y compararlos con soportes teóricos con la finalidad
de darle validez a los resultados de la investigación.
Posteriormente a validar los resultados de la investigación con soportes teóricos, se
debe realizar la pregunta de si existe un patrón en el material empírico para continuar
a la siguiente fase de la metodología, en este punto se debe identificar si la
investigación presenta patrones evidenciables como afirmaciones validadas o
repeticiones de los distintos planteamientos.
En caso de no encontrar un patrón en el material empírico, la metodología propone
permanecer en la fase de investigación y trabajar en el capítulo teórico de la tesis, para
luego discutir sobre el estado de la información que pueda existir en este capítulo, se
debe analizar si se ha realizado suficiente investigación o si existe alguna la brecha
informativa que se deba cubrir con una fuente adicional, para luego comenzar
nuevamente con el primer paso de esta fase que es la realización de la investigación
primaria.
En caso de encontrar un patrón en el material empírico la metodología indica que se
debe continuar con la siguiente fase. [33]
34
- Análisis:
En esta segunda fase de la metodología se debe primero seleccionar la información
obtenida en los resultados de la investigación, se debe filtrar y descartar toda aquella
información que no aporte significativamente a llegar a una conclusión relacionada al
planteamiento con el que se está trabajando.
Una vez la información ha sido seleccionada, se debe discutir sobre el material
seleccionado con la finalidad de validar si existe información que se haya filtrado
incorrectamente o si existe alguna carencia en la información obtenida para realizar un
análisis completo.
Cuando se validen los puntos anteriores entonces se deben proponer y derivar las
distintas perspectivas u opciones clave que ayuden a llegar a la conclusión, esto quiere
decir que en esta fase se plantean las distintas hipótesis para la resolución del
planteamiento.
Luego se deben validar estas hipótesis en comparación con el material obtenido en los
resultados de la investigación.
Debido a la naturaleza del trabajo que se realizó, esta actividad de validación de
hipótesis se debió realizar utilizando herramientas que debían ser desarrolladas, por lo
cual se realizó la combinación de esta metodología con la metodología de desarrollo
de software ágil XP, de esta manera la validación de resultados está apoyada por los
entregables generados en las primeras iteraciones de la metodología XP.
Una vez se realicen las validaciones y experimentos necesarios sobre las hipótesis, se
debe preguntar si las perspectivas claves o hipótesis llevan a una conclusión validada.
En caso que las perspectivas clave no lleven a una conclusión validada, se plantea que
hace falta más investigación y se debe iterar sobre la metodología volviendo a la fase
35
anterior específicamente en el paso de discusión del capítulo teórico y continuar
nuevamente con el flujo de la investigación.
En caso de una respuesta positiva a la pregunta realizada, se debe avanzar a la
siguiente fase de la metodología. [33]
- Conclusión:
En esta última fase de la metodología, se debe primero discutir sobre las hipótesis para
validar sus soportes y analizar cómo éstas pueden llevar a una conclusión sobre el
planteamiento.
Luego se debe seleccionar el material que lleva a la conclusión, filtrando nuevamente
aquella información que no aporte significativamente a realizar una conclusión sobre el
planteamiento.
En este momento se debe entonces escribir la conclusión planteada para luego
validarla con las perspectivas claves y si realmente las perspectivas claves soportan la
conclusión planteada.
Cuando la conclusión se haya validado con las perspectivas clave, se debe preguntar
si la conclusión responde a la pregunta o planteamiento de la investigación.
En caso de obtener una respuesta negativa se debe realizar más análisis, por lo que
iteramos nuevamente sobre la metodología, pero esta vez volveremos a la primera
actividad de la fase de Análisis.
En caso de obtener una respuesta positiva se plantea que la tesis se ha completado.
[33]
Como se puede observar el enfoque de esta metodología, radica en realizar suficientes
iteraciones sobres las distintas fases y actividades para alcanzar una conclusión que pueda
responder al planteamiento de la tesis, convirtiéndola en una metodología muy eficaz para
alcanzar resultados en temas con poco soporte académico.

36
En el segundo caso, la metodología de programación, es la metodología eXtreme
Programming (XP), centrada en realizar iteraciones incrementales y enfatizar el trabajo en
equipo.
Wells [34.] propone que los proyectos que utilicen la metodología XP, los gerentes de
proyecto, clientes y desarrolladores están en el mismo nivel de colaboración y comunicación,
generando un ambiente simple que aumenta el rendimiento del equipo.
Wells también propone en Extreme Programming: A gentle introduction [34], que las fases
en cada iteración de la metodología XP se pueden evidenciar en el Apéndice A y son:
1. Planificación:
1.1. Planificación de autorización: Según Wells [35] esta planificación está basada en
definir que requerimientos se incluyen en los distintos entregables a corto plazo y cuando
deben ser entregados, a su vez se divide en:
o Exploración:
En la fase de exploración se proporciona y analiza una lista de todos los requerimientos
funcionales planteados en el proyecto con mayor prioridad y alto valor para el sistema.
o Compromiso:
Una vez se listen los requerimientos los desarrolladores deben comprometerse a la
funcionalidad que se desarrollara y las fechas de los entregables.
o Dirección:
Por último, se puede ajustar la planificación para agregar nuevos requisitos y/o modificar
o eliminar requisitos existentes.
1.2. Planificación de la iteración: Wells [35] estableció que en esta fase se planifican las
actividades y tareas de los desarrolladores, esta fase no debe incluir al cliente. Para
completar esta planificación se deben realizar las siguientes actividades:
o Explotación: En esta actividad los requerimientos se traducen y dividen en distintas
tareas que los desarrollares deben realizar.
37
o Compromiso: Luego los desarrolladores deben comprometerse a realizar estas
tareas en las fechas establecidas.
o Dirigir: Por último, las tareas se llevan a cabo y deberían dirigirse a corresponder las
historias de usuario planteadas.
2. Diseño:
En la segunda fase principal de la metodología XP, se busca realizar el diseño y estructura
de los distintos componentes que conforman el sistema. Dependiendo de las necesidades
del proyecto el diseño puede abarcar arquitecturas de bases de datos, arquitecturas de
aplicación, protocolos de comunicación, estandarización de nombres, flujo de las
funcionalidades. La metodología plantea el uso de glosarios de términos para
especificación de los nombres de los métodos y clases que serán parte del proyecto. Un
buen diseño habilitará la adaptabilidad y escalabilidad de los proyectos. [35]
3. Desarrollo:
En esta fase se realizará la implementación de las funcionalidades que satisfacen los
requerimientos planteados en las primeras fases, utilizando el diseño planteado.
La metodología XP indica que la presencia de los involucrados en el proyecto es muy
importante y esta fase requiere aún más de dicha presencia. Esto es debido a que antes
de comenzar el desarrollo se debe especificar detalladamente cada historia de usuario
evitando las ambigüedades, luego el equipo debe generar los entregables de tal manera
que satisfagan los requerimientos planteados.
Al finalizar la fase de Desarrollo se valida que los entregables cumplan con la funcionalidad
especificada. [34]
4. Pruebas:
Wells [34] plantea que en la última fase de la metodología se debe validar el nivel de
satisfacción de los requerimientos, esto se logra utilizando dos tipos de pruebas:
38
- Pruebas Unitarias: Las pruebas unitarias son utilizadas para validar la exactitud y
determinar si una característica funciona como debe. El desarrollador debe generar tantas
pruebas automatizadas como crea para romper el código. Una vez que las pruebas corran
de manera satisfactoria la codificación habrá finalizado.
- Pruebas de Aceptación: Las pruebas de aceptación se realizan enfocadas a verificar
si los entregables desarrollados cumplen y satisfacen los requerimientos del cliente.
Estas pruebas generan resultados que permiten a los desarrolladores corregir los
cambios detectados.
En el momento en el que se finalicen todas las fases, se debe iniciar nuevamente con
la fase de planificación, el propósito de la metodología es dividir el trabajo en tantas
iteraciones sea necesario considerando que una iteración no debe durar largos periodos de
tiempo y al final de toda iteración debe haberse generado uno o varios entregables que
generen valor al proyecto.
En el caso específico de este proyecto se desarrollará sin implementar la
programación en parejas que plantea la metodología XP, porque solamente una persona
desarrollo el proyecto.
El uso de ambas metodologías combinadas permitió el desarrollo de este trabajo,
pues la naturaleza del planteamiento requiere el uso de una ciencia aplicada para generar
una nueva tecnología e innovación, la utilizada es la ingeniería biomédica, esta ciencia
aplicada es el resultado de la integración de dos ciencias la medicina y la ingeniería.
39
CAPITULO IV
DESARROLLO
En este capítulo se detallarán las actividades y tareas realizadas siguiendo las
metodologías planteadas, para resolver las incógnitas principales que se derivan del proyecto
y desarrollar los objetivos que lo componen.
En este proyecto se derivan las siguientes dos incógnitas principales a resolver:
Utilizando procesamiento digital de imágenes ¿Es posible diseñar e implementar un
algoritmo que interprete imágenes de electrocardiogramas y sus derivaciones? y ¿Es
posible diseñar e implementar un algoritmo que diagnostique patologías en las
derivaciones?
Se plantea que para la resolución de estas incógnitas se debe implementar un sistema
informático que apoyado en las distintas teorías médicas sea capaz de gestionar imágenes
de electrocardiogramas para realizar su diagnóstico.
Fases e Iteraciones:
1. Fase Investigación v1:
1.1 Realizar Investigación Primaria:
Las actividades de esta primera fase están enfocadas en realizar la recopilación de
materiales, que sirvan para generar un marco teórico suficientemente robusto que apoye la
construcción de una base empírica, luego dicha base será validada con la finalidad de
conseguir uno o varios patrones en la investigación.
En primer lugar, se consultó la bibliografía relacionada a los electrocardiogramas, se
recopiló suficiente información para generar la base empírica, luego se consultó con distintos
profesionales de la salud incluyendo una comunicación directa con el Profesor Baltazar
Saturno, médico especializado en medicina interna de la Universidad Central de Venezuela.
40
Posteriormente se consultaron las distintas opciones de lenguajes y librerías para realizar
la interpretación de las imágenes, tomando en cuenta que el objetivo sería diseñar dos
algoritmos que plantearán la solución a las incógnitas.
1.2 Construir base empírica:
Realizando la investigación se encontró que, para el diagnóstico de las patologías
presentes en una derivación de un electrocardiograma, el análisis debe enfocarse en los
segmentos P-Q-R-S-T, pues el comportamiento de estas ondas y segmentos son la función
base para la detección de patologías.
La investigación relacionada a las distintas opciones de lenguajes y librerías para realizar
la codificación de los algoritmos, arrojó como resultado que las herramientas que mejor
satisfacen los requerimientos son el lenguaje C++ y la librería OpenCV.
Esto se debe a que OpenCV, es la librería de procesamiento digital de imágenes más
utilizada, mejor mantenida y con la mayor cantidad de métodos implementados para la
gestión de las imágenes. La última versión publicada está implementada en C++ y a pesar
de existir distintas implementaciones de la librería en lenguajes de alto nivel como Python o
Ruby, se escogió utilizar C++ para asegurar que el proceso de integración con la librería
desarrollada se facilitará.
La combinación de estos resultados permitió plantear que una buena aproximación a
resolver las incógnitas de este proyecto, es diseñar uno o varios algoritmos que deberán
estar en capacidad de detectar las distintas ondas y segmentos P-Q-R-S-T en el vector X Y,
para luego realizar distintas comparaciones y arrojar un resultado.
1.3 Validar los resultados de la investigación:
Nuevamente se consultó con los profesionales de la salud y se validó que el planteamiento
expuesto anteriormente sobre el enfoque en los segmentos nombrados era el correcto.
41
Adicionalmente se validó que el diagnóstico realizado sobre las distintas derivaciones,
está basado en cálculos matemáticos cuyos resultados deben compararse con límites
establecidos y dependiendo del resultado de estas comparaciones se puede afirmar que
existe alguna patología en dicha derivación.
Con respecto a la validación de las herramientas se consultaron distintas fuentes
bibliográficas y a los ingenieros Ramón Porras y Carlo Magurno, profesores de la Universidad
Católica Andrés, se validó que la elección de las herramientas planteadas para el desarrollo
de la librería eran las correctas y permitirían satisfacer los objetivos planteados.
1.4 ¿Existe un patrón?:
Para encontrar un patrón en las investigaciones realizadas se analizó nuevamente el
material empírico y se encontró que los electrocardiogramas deben diagnosticarse
identificando las distintas ondas y segmentos para luego comparar su comportamiento,
además se encontró que el uso de la librería OpenCV para extraer la señal de la imagen y
obtener un vector X Y, se ajustaba perfectamente a los cálculos matemáticos que podrían
generar el diagnóstico.
Solo quedaría definir cuales patologías serían las más adecuadas para el proyecto
realizado y automatizar el proceso de los cálculos matemáticos que diagnostican las
patologías seleccionadas.
En conversación con el Médico B. Saturno se concluyó que las patologías que debían ser
diagnosticadas serían la Hipertrofia Ventricular, Fibrilación Auricular y Fibrilación Ventricular.
Se realizó la pregunta que permite avanzar a la siguiente iteración: ¿Existe un patrón en
el material empírico?
El patrón en la investigación es evidente por lo que la respuesta a la pregunta es afirmativa
y permite avanzar a la siguiente fase de la metodología.
42
2. Fase Análisis v1:
2.1 Seleccionar información de la investigación:
Los patrones encontrados en el material de investigación permiten generar una base
empírica, se debe entonces seleccionar de dicha base la información que será utilizada para
derivar las perspectivas e hipótesis clave de la fase de análisis.
Se escogió de la base empírica la información relacionada a cómo se realiza el diagnóstico
de los electrocardiogramas y la información relacionada a la librería OpenCV y sus métodos.
2.2 Discusión de los materiales seleccionados:
Se realizó una consulta nuevamente con el Ing. Magurno, basado en la información
seleccionada y se discutió sobre las distintas posibilidades de cómo diseñar dos algoritmos
que respondan las incógnitas del proyecto.
Se concluyó luego de esta discusión que una buena aproximación sería utilizar los
métodos de la librería OpenCV en la implementación de los algoritmos.
Estos métodos son capaces entre otras cosas de extraer de una imagen un rango de
colores, erosionar y dilatar una imagen; estas funcionalidades habilitarían la extracción de la
señal de la imagen, para luego utilizar operaciones matemáticas sobre la señal obtenida y
comparar los resultados con los criterios que diagnostican cada patología.
De esta manera se pueden diagnosticar las distintas patologías en los
electrocardiogramas utilizando procesamiento digital de imágenes.
2.3 Derivar Perspectivas e Hipótesis Clave:
Utilizando la información seleccionada de la investigación se derivan entonces las
siguientes posibles perspectivas o hipótesis a validar:
- El diseño del Algoritmo que interprete la imagen de una derivación debe ejecutar la
tarea de extracción del color que representa la señal en el papel impreso
43
- El diseño del Algoritmo que interprete la imagen de una derivación debe aplicar
métodos para la reducción de ruido para disminuir la posibilidad de errores
- El diseño del algoritmo que diagnostique la señal de la imagen debe analizar el vector
X y Y para detectar los patrones de las distintas ondas y segmentos
- Debido a que el punto más alto en el vector X y Y debe pertenecer al pico de una
onda R se puede utilizar este punto de partida para detectar las distintas ondas y los
distintos segmentos.
2.4 Validar distintas perspectivas y opciones
Utilizando las hipótesis planteadas anteriormente y los resultados de la investigación se
procedió a realizar el desarrollo de las herramientas que permitieron la validación de las
hipótesis o perspectivas planteadas.
2.4.1 Iteración XP 1 (Construcción Librería)
La primera iteración se enfocó en desarrollar los requerimientos funcionales que
permitieran validar los planteamientos realizados.
2.4.1.1 Planificación:
Partiendo de la premisa mencionada se escogió desarrollar aquellos requerimientos
relacionados específicamente a las funcionalidades que soportarían las actividades de los
algoritmos planteados.
En la lista de los requerimientos APENDICE C, se escogió desarrollar las historias de
usuario relacionadas al requerimiento RF_ECGI_4.
Las tareas que se derivan de estos requerimientos se basan en la implementación de los
distintos métodos de la librería OpenCV por lo que se investigó a fondo la documentación de
dicha librería.
44
2.4.1.2 Diseño:
Entendiendo que la dirección del proyecto apunta a la necesidad de una arquitectura de
software cliente-servidor como se muestra en el Diagrama de Arquitectura (Apéndice D), la
implementación de estos algoritmos debería ocurrir afuera del tiempo de ejecución, por esta
razón se planteó que se debían implementar en una librería escrita en C++.
La librería debe contener una interfaz para su interpretación y extensión, que contenga las
firmas de los métodos que implementa, para que las distintas aplicaciones que consuman la
librería puedan utilizar dichos métodos.
Los métodos desarrollados en esta librería son los siguientes:
- Extraer señal de derivación
- FiltrarImagen
- BuscarPuntosR
- DiagnosticarHipertrofiaVentricular
- DiagnosticarFibrilacionVentricular
- DiagnosticarFibrilacionAuricular
2.4.1.3 Desarrollo:
Se desarrolló la historia de usuario HU_ECGI_12 (Apéndice C) relacionadas al
requerimiento RF_ECGI_4.
En el proceso de desarrollo se agregaron ventanas de imágenes con las señales extraídas
(Apéndice E) de cada derivación interpretada, además de figuras geométricas que
permitieran visualizar el proceso de interpretación y diagnóstico que se realiza a la imagen.
A continuación, se detalla el diseño e implementación de los algoritmos.
Algoritmo de Interpretación de Imágenes de Electrocardiogramas:
Paso 1: Convertir el archivo de imagen en un objeto de tipo Mat que representa una
matriz de bits de colores.
45
Utilizando el método imread() de la librería OpenCV y el directorio de la imagen, este paso
se encarga de convertir la imagen en una matriz de bits que representan los valores de color
y la ubicación de los pixeles de la imagen.
Paso 2: Aplicar el método inRange a la matriz obtenida.
Este método recibe de parámetros de entrada, una matriz de bits de colores y un rango
de valores en la escala HSV que representan los colores de los pixeles, generando como
resultado una matriz de bits con la información de la ubicación de los pixeles en la imagen,
cuyo valor se encuentre en el rango de valores en la escala HSV.
El resultado es un vector X Y que representa la ubicación de los pixeles que describen la
señal de los electrocardiogramas.
Paso 3: Aplicar la erosión y dilación.
Utilizando los métodos de la librería OpenCV de erosión y dilación, que reciben como
entrada una matriz de bits y generan como salida otra matriz de bits con ciertas
modificaciones que reducen el ruido en la señal.
El resultado es ahora un vector X Y que representa la ubicación de los pixeles que
describen la señal, pero con reducción de posible ruido en la extracción de los colores.
Algoritmo de Diagnóstico de la Señal de Electrocardiogramas
Paso 1: Buscar el punto más Alto
Utilizando la función minMaxLoc() de la librería OpenCV, que recibe como parámetro una
matriz de bits y devuelve el punto que representa la ubicación del pixel más alto en la imagen,
con la matriz resultante del algoritmo de interpretación se encuentra el punto más alto de la
señal de un electrocardiograma.
Según los resultados de la investigación realizada se asigna este punto como el punto que
representa la onda R.
46
Paso 2: Buscar otros Puntos R
Utilizando como punto de referencia el punto R encontrado y partiendo de la premisa que
los puntos R se encuentran generalmente a una misma altura en una derivación, se realizan
iteraciones sobre el vector X Y, específicamente sobre el eje X, buscando todos los puntos
que se encuentren a la misma altura o a una altura con un máximo error de 5 pixeles de
diferencia en el eje Y.
Una vez se encuentra el primer conjunto de puntos se deja de iterar sobre el eje X y se
busca el punto máximo de este conjunto encontrado.
Este punto se identifica como una onda R y continúa el proceso de iteración sobre el eje
X, con la finalidad de recorrer todo el eje Y encontrar los puntos máximos e identificarlos
como ondas o puntos R.
Paso 3: Calcular Distancia Entre Puntos R y Línea base.
Para facilitar este proceso se debe obligar al usuario a alinear la línea base del
electrocardiograma que desea diagnosticar con la mitad vertical de la imagen capturada. Es
necesario entonces que se agregue un apoyo visual a la captura de la imagen para satisfacer
este requerimiento.
Utilizando la fórmula de la distancia euclidiana se calcula y se almacena la distancia entre
los puntos R encontrados y la mitad del eje Y.
Paso 4: Calcular la Distancia entre los puntos R
Utilizando la fórmula de la distancia euclidiana se calcula la distancia entre los puntos R
encontrados y se almacenan los resultados para su posterior consulta.
47
Diagnóstico de Hipertrofia Ventricular:
Paso 5: Aplicar Criterio de Sokolow-Lyon
Utilizando la distancia entre la línea base y los puntos R obtenida en el Paso 4, se
comparan cada uno utilizando los criterios de Sokolow-Lyon que indica que debemos
comparar esta distancia con 56mm y si es mayor de esta entonces el diagnóstico de la
hipertrofia ventricular es positivo en esta señal.
Diagnóstico de Fibrilación Ventricular:
Paso 6: Contar Cantidad de Puntos R
En la presencia de la fibrilación ventricular, la existencia de los puntos R es difícil de
identificar, por lo que en este paso se realiza el análisis de la cantidad de puntos R
encontrados en el Paso 2. Una derivación impresa en su versión corta, suele presentar no
más de cuatro puntos R, por lo que podemos afirmar que si esta cantidad supera cuatro
puntos en la señal analizada entonces se puede diagnosticar la fibrilación ventricular.
Diagnóstico de Fibrilación Auricular:
Paso 7: Comparar Distancias entre Puntos R
La presencia de una arritmia es fácilmente identificable, aplicando el criterio que indica
que las distancias entre los puntos R deben seguir un patrón constante, se puede
diagnosticar una arritmia.
Por lo tanto, en este paso se comparan estas distancias obtenidas en el Paso 4, y luego
se analiza la variación de estas distancias, en caso de variar en más de 5% su tamaño se
concluye que el diagnóstico es positivo y existe una arritmia en dicha derivación.
El entregable generado de esta fase fue una librería llamada ecgilib.so que contiene la
implementación de los métodos y pasos que realizan las tareas de los algoritmos planteados.
48
En el Apéndice F y el Apéndice G se presentan los diagramas de flujo de los algoritmos
diseñados.
2.4.1.4 Pruebas:
Para realizar las distintas pruebas sobre los entregables desarrollados se utilizaron
imágenes de distintas derivaciones que permitieron entender si el procedimiento y los
resultados arrojarían una conclusión válida para diagnosticar electrocardiogramas.
Utilizando imágenes de distintas derivaciones, se compiló la librería como una aplicación
ejecutable y se realizó el diagnóstico de las distintas derivaciones. En el Apéndice E se
encuentran las imágenes obtenidas en las pruebas, dónde se pueden evidenciar los
resultados de los algoritmos implementados.
Hito: Fin Iteración XP 1
El entregable de la iteración permitió la validación de las hipótesis planteadas para luego
continuar a la siguiente actividad de la fase de análisis en la que se cuestiona si las hipótesis
y las perspectivas claves llevan a la conclusión apoyadas por los resultados de la
experimentación.
2.5 ¿Las perspectivas claves llevan a una conclusión?
La metodología utilizada plantea que para avanzar hacia la siguiente fase, se debe
responder de manera afirmativa la pregunta enunciada. A continuación, para responder
correctamente la pregunta, se analizan los resultados obtenidos en la fase anterior,
relacionados a las distintas perspectivas e hipótesis planteadas.
- El diseño del Algoritmo que interprete la imagen de una derivación debe ejecutar la
tarea de extracción del color que representa la señal en el papel impreso
Utilizando la herramienta desarrollada, se obtuvo la extracción correcta de la señal, se
realizaron varias pruebas sobre el rango de color especificado y se recomienda desarrollar
una herramienta, que permita modificar el rango de color utilizado para la extracción de la
49
señal, ajustando dicho proceso a los posibles colores existentes en los electrocardiogramas
que se deseen interpretar.
- El diseño del Algoritmo que interprete la imagen de una derivación debe aplicar
métodos para la reducción de ruido para disminuir la posibilidad de errores.
Luego de realizar las pruebas utilizando la herramienta, se encontró que los métodos de
erosión y dilación de la imagen facilitan la interpretación correcta de la señal.
- El diseño del algoritmo que diagnostique la señal de la imagen debe analizar el vector
X Y para detectar los patrones de las distintas ondas y segmentos.
Analizando el resultado que se obtiene al extraer de la imagen la señal, un vector X Y que
representa la función de la señal, se concluyó que el análisis de este vector permite la
detección de los patrones que describen las distintas ondas y segmentos.
- Debido a que el punto más alto en el vector X Y debe pertenecer al pico de una onda R
se puede utilizar éste, como punto de partida para detectar las distintas ondas y los
distintos segmentos.
Si bien en la teoría, los puntos más altos de un electrocardiograma suelen ser los puntos
R, existen casos en lo cual esto no es cierto. Adicionalmente asumiendo que siempre se
cumpliera dicha premisa, conocer los puntos R y su ubicación no es suficiente para detectar
los otros puntos o segmentos de un electrocardiograma por lo que esta perspectiva queda
invalidada.
La última perspectiva de la lista apoya el primer paso del algoritmo de diagnóstico pues
como se expone, éste realiza la búsqueda de los puntos R en la señal utilizando la búsqueda
del punto más alto de la función, automáticamente al invalidar la perspectiva, este algoritmo
se invalida para su uso como solución a las incógnitas planteadas.
Luego de realizar el análisis anterior la respuesta a la pregunta realizada en esta actividad
fue negativa, pues si bien tres de las hipótesis y perspectivas clave apoyan la conclusión, la
50
perspectiva que apoya el algoritmo diseñado fue invalidada, se concluyó que era necesario
realizar más investigación y siguiendo la metodología utilizada se debía volver a la Fase de
Investigación.
3. Fase Investigación v2:
3.1 Discusión del Capítulo teórico:
Para la discusión del capítulo teórico además de la investigación realizada, se utilizaron
los resultados obtenidos en la fase anterior para encontrar el origen de la respuesta negativa.
Se encontró entonces que las señales de los electrocardiogramas no siguen siempre el
patrón planteado; por lo tanto, la perspectiva bajo la cual se diseñó el algoritmo se invalidó.
En su desarrollo solamente se tomaron en cuenta electrocardiogramas teóricos y no reales.
En la realidad los electrocardiogramas, siguen estos patrones explicados en la medicina,
pero de una manera bastante irregular, suficiente como para afirmar que automatizar el
proceso de detección de estos patrones, requiere de intervención humana u otra herramienta
adicional.
En el momento en el que se alcanza esta conclusión, se generan distintas opciones para
solucionar el problema encontrado, sobre las cuales se realizó más investigación.
Las opciones encontradas para la resolución del problema identificado fueron las
siguientes:
- Desarrollar una fórmula matemática que, utilizando las herramientas existentes, pueda
generalizar la detección de patrones de curvas en un vector de coordenadas X Y, para
categorizar e identificar los distintos segmentos de un electrocardiograma.
- Utilizar una herramienta informática ya existente que pueda realizar identificación de
patrones y arrojar resultados basados en la detección e identificación de dichos patrones.
51
- No existe solución para automatizar el proceso de realizar el diagnóstico en
electrocardiogramas, es decir, se requiere de la intervención humana especializada para
ejecutar este proceso.
3.2 Realizar Investigación Primaria:
Los planteamientos generados de la discusión anterior, sirvieron de punto de partida para
realizar las investigaciones que ayudaron a desarrollar la solución.
Se realizó la consulta con los especialistas involucrados sobre el primer planteamiento para
desarrollar una fórmula matemática generalizada.
Se encontró que existen distintas propiedades matemáticas que analizan el
comportamiento de una curva en el plano cartesiano, por ejemplo, en calculo la segunda
derivada afirma que si el resultado de esta segunda derivada es negativo entonces existe un
cambio de dirección de la función por lo tanto debe existir un punto de inflexión [35.]
En el caso del proyecto cada punto de inflexión de la curva que describe la señal, describe
las distintas ondas y los segmentos en el electrocardiograma.
Adicionalmente se investigó sobre la posibilidad de conseguir una herramienta que
utilizando un sistema informático automatice la detección de patrones; se encontraron
distintas posibilidades de las cuales se determinó, que las Redes Neuronales son la
herramienta que mejor se ajusta a resolver las necesidades de detección de patrones.
3.3 Construir base empírica:
Los resultados de la investigación realizada permitieron generar distintos planteamientos
que apoyaron la construcción de una solución para resolver las incógnitas del proyecto.
Se concluyó que el Paso 1 del Algoritmo de Diagnóstico, se debe ajustar la detección de
los segmentos P-Q-R-S-T, esto se puede lograr utilizando las propiedades de la segunda
derivada matemática, sobre la curva que describe la señal del electrocardiograma.
52
Una alternativa al uso de las matemáticas, derivada de la investigación es el uso de una
Red Neuronal entrenada para tomar la decisión de si un registro nuevo en el sistema cumple
con las características de los patrones bajo las cuales la red se entrenó.
Ambos planteamientos descartan la perspectiva que afirma la necesidad de intervención
humana para la ejecución del proceso de diagnóstico.
3.4 Validar los resultados de la investigación:
Los planteamientos generados en la base empírica fueron validados con especialistas en
las distintas áreas planteadas. En este proceso se compararon distintas soluciones
informáticas que implementaban las redes neuronales y las derivadas matemáticas.
Se analizó el funcionamiento y se llegó a la conclusión que las herramientas apoyaban y
habilitaban la creación de ambos escenarios planteados anteriormente.
3.5 ¿Existe un patrón?
Se puede encontrar un patrón en el resultado de la investigación que guía a realizar el
análisis sobre el uso de los escenarios planteados como solución al problema encontrado en
la validación de las hipótesis.
Por lo que se planteó que la solución al problema encontrado en el Paso 1 del algoritmo
de diagnóstico tiene dos posibilidades, la primera es utilizar las librerías matemáticas
existentes y con el cálculo de la segunda derivada, realizar una identificación de los puntos
de inflexión en la curva para luego detectar los distintos segmentos del electrocardiograma y
continuar con los siguientes pasos del algoritmo.
La segunda posibilidad se enfoca en cambiar completamente el algoritmo de diagnóstico
y en vez apoyarse en comparaciones y cálculos matemáticos para realizar el diagnóstico de
las curvas, utilizar las redes neuronales para generar el diagnóstico de las distintas
patologías, este se determinará por aproximación de patrones. Es decir, la Red Neuronal
53
está entrenada para detectar si hay dos objetos que se parecen en un gran porcentaje basada
en patrones establecidos en el entrenamiento.
4. Fase Análisis v2:
4.1 Seleccionar información de la investigación:
Los patrones encontrados en el nuevo material de investigación, generaron una base de
la cual se seleccionó la información necesaria para construir las perspectivas clave.
Se escogió de la base la información relacionada a la implementación de las redes
neuronales y como deben entrenarse, además de la información relacionada a los cálculos
matemáticos y sus características.
4.2 Discusión de los materiales seleccionados:
Se realizó una consulta adicional con el Prof. Magurno; en conjunto utilizando los
resultados obtenidos de la fase de análisis, se encontró que la implementación de una red
neuronal entrenada o el diseño e implementación de una fórmula matemática generalizada,
son buenas aproximaciones a la solución de los problemas encontrados.
En este caso una fórmula matemática apoyada por el cálculo de la segunda derivada de
una función puede apoyar en la detección de puntos de inflexión de una curva, que en un
electrocardiograma representan las ondas y segmentos.
Por otro lado, una red neuronal entrenada para detectar los patrones de las distintas
patologías, emula de alguna manera el comportamiento humano utilizado en el diagnóstico
de los electrocardiogramas, por lo que también representa una opción viable para solucionar
las incógnitas.
54
4.3 Derivar perspectivas e Hipótesis Clave:
Las perspectivas e hipótesis de la primera iteración, se validaron a través de distintos
experimentos utilizando las herramientas planteadas, los resultados obtenidos permitieron
derivar una segunda serie de perspectivas e hipótesis a validar en la fase de análisis.
En esta segunda iteración apoyada en la investigación, se plantearon las siguientes
hipótesis o perspectivas:
- La implementación de las funciones matemáticas para la detección de los puntos de
inflexión en la curva y utilizando estos puntos para detectar e identificar los distintos
segmentos, es una aproximación teórica a la solución del problema encontrado en el
Paso 1 del Algoritmo de Diagnostico.
- La solución de este problema en el Paso 1, permitiría mantener el mismo flujo de
pasos planteados en el Algoritmo.
- Una Red Neuronal es capaz de aprender y detectar los distintos patrones existentes
en los electrocardiogramas para generar un diagnostico confiable.
- El desarrollo de un algoritmo completamente distinto apoyado por la implementación
de una red neural entrenada para la detección de las patologías en los
electrocardiogramas es una aproximación a la solución del problema encontrado en la
fase de análisis anterior.
4.4 Validar distintas perspectivas e hipótesis:
Para la validación de estas perspectivas se utilizaron los resultados de las investigaciones
y las herramientas desarrolladas.
En el proceso de validación se encontró que las implementaciones existentes de los
cálculos de la segunda derivada, pueden resolver el problema de la detección de segmentos
siempre y cuando los cambios en los puntos de inflexión estén claramente marcados por un
cambio de dirección en la función.
55
Los resultados obtenidos en el proceso de validación de las perspectivas anteriores,
concluyeron que los puntos de inflexión en una señal de electrocardiogramas no están
claramente identificados. Dificultando la detección de los mismos con este método.
Por otro lado, se observa que la perspectiva que afirma que se requiere de intervención
humana en el proceso de diagnóstico apoya el uso de las Redes Neuronales, éstas emulan
el comportamiento humano y son capaces de tomar decisiones basadas en detección de
patrones.
En conclusión, la mejor aproximación a solucionar el problema encontrado es la
implementación de una red neuronal que apoye al sistema. La implementación de una Red
Neuronal se encuentra fuera del alcance de este proyecto, pero derivando de las distintas
hipótesis planteadas a lo largo del proyecto y los resultados obtenidos, se puede concluir que
muchos componentes de este proyecto son reutilizables en la implementación de una Red
Neuronal como solución al planteamiento.
Por esto se enfocó el diseño e implementación de todos los componentes del sistema, en
satisfacer la característica del software de adaptabilidad, buscando habilitar la integración de
una solución que implemente una red neuronal.
Adicionalmente para reforzar la validación de las perspectivas planteadas se desarrollaron
los siguientes componentes del sistema informático:
- Aplicación de Servidor
- App Móvil
- Herramienta de Reportes
A continuación, se detalla el proceso de desarrollo de los componentes del sistema
utilizando la metodología XP.
56
4.4.1 Iteración XP 2 (Construcción Servidor):
La segunda iteración de la metodología XP se centró en el diseño e implementación de
una aplicación de servidor que fuera capaz de gestionar peticiones de distintos clientes
móviles y utilizar la librería desarrollada para realizar un diagnóstico sobre las imágenes.
Según la premisa planteada se escogió desarrollar aquellos requerimientos, relacionados
específicamente a las funcionalidades que soportarían las necesidades de la aplicación
servidor.
De la lista de los requerimientos Apéndice B se escogió desarrollar las historias de usuario
asociadas a los requerimientos RF_ECGI_1, RF_ECGI_2, RF_ECGI_3.
Las tareas que se derivan de estos requerimientos se planificaron utilizando el Framework
Ruby On Rails que facilita la implementación de las funcionalidades.
Los servicios web de esta aplicación servidor, se implementarán utilizando la arquitectura
REST.
4.4.1.2 Diseño:
El framework escogido utiliza el patrón MVC que plantea el diseño del software en tres
capas (Modelo, Vista, Controlador), esta aplicación está enfocada en solamente habilitar
integraciones con dispositivos móviles por lo que la capa de vista no se desarrollará.
El diseño de esta aplicación de servidor debe seguir los estándares que permitan habilitar
las mejores prácticas de las arquitecturas basadas en REST, por lo tanto la implementación
de los servicios web desarrollados en esta iteración cumple con todos los criterios y mejores
prácticas expuestas en el marco referencial.
Adicionalmente esta aplicación está diseñada para permitir la integración con la librería
implementada, por lo que requiere el uso de una herramienta que habilite la integración entre
57
librerías implementadas en un lenguaje de programación y aplicaciones desarrolladas en un
lenguaje de programación diferente.
El diagrama de modelos de la aplicación (Apéndice H), describe también los modelos de
la aplicación pues el framework, utilizando el Object Relational Mapping (ORM), crea las
tablas que almacenan los modelos, con los atributos de cada modelo diseñado en el
framework.
La documentación de los servicios REST con los detalles de los estándares establecidos
se encuentra en el Apéndice M.
4.4.1.3 Desarrollo:
Se desarrollaron las historias de usuario HU_ECGI_1, HU_ECGI_2, HU_ECGI_3,
HU_ECGI_4, HU_ECGI_5, HU_ECGI_6 (Apéndice C) relacionadas a los requerimientos
escogidos en la planificación.
A continuación, se detalla cómo se realizó la implementación de la aplicación servidor.
El framework Ruby on Rails facilita la creación de aplicaciones web, a través de métodos
ejecutados a través de comandos, que utilizando el pluralizador y el ORM, crean los archivos
necesarios para gestionar una entidad en el sistema bajo el patrón MVC.
Además, permite la creación de aplicaciones web de tipo API, especialmente diseñadas
para la construcción de servicios web REST. Este tipo de aplicaciones no requiere de la capa
de vistas, pues sus servicios web serán consumidos solamente por un dispositivo que se
encargara de generar las vistas al usuario.
Utilizando el comando scaffold se generaron los archivos relacionados a los pacientes,
electrocardiogramas y diagnósticos. Por cada uno de ellos se generaron un archivo que
describe el controlador, un archivo que describe el modelo y un archivo de migración que se
encarga de crear la entidad en la base de datos.
58
Luego de crear todas las entidades, se ejecutó el comando rake db:migrate, que realiza la
migración de las entidades a la base de datos, utilizando los archivos generados por el
comando scaffold y el ORM.
El comando genera un archivo controlador, que contiene los cuatro métodos del protocolo
HTTP implementados por la convención del framework. Se realizaron ajustes necesarios en
los distintos métodos para lograr el comportamiento deseado en el sistema.
El framework utiliza un archivo de rutas para saber que método debe llamar dependiendo
de la petición que reciba de los clientes, el comando scaffold genera también las rutas a los
distintos métodos, agilizando el desarrollo de las funcionalidades que satisfacen los
requerimientos del sistema. En el caso de este trabajo se ajustaron las rutas para satisfacer
las necesidades del sistema.
A través de las mejores prácticas, se instaló en la aplicación una gema llamada
JsonSerializer, que facilita el manejo del formato JSON que se envía de respuesta a las
peticiones haciendo uso del protocolo HTTP, estandarizando el formato de los archivos y la
distribución de la información.
Para lograr esto se debe crear un objeto serializer de JSON, que da formato al mensaje
de respuesta y un objeto serializer por cada entidad del sistema, dicho objeto indica cómo se
debe mostrar en el mensaje de respuesta, la información de los atributos que describen las
entidades.
La funcionalidad que permite gestionar archivos de imágenes, se desarrolló utilizando una
gema llamada PaperClip, que permite gestionar imágenes a través de servicios web REST y
almacenarlas en el sistema.
La entidad electrocardiograma en el sistema, contiene un atributo de imagen que es de
tipo FileImage, la gema PaperClip interpreta el mensaje de la petición y lo convierte en este
tipo de objeto FileImage, luego almacena esta imagen en disco duro y registra en la base de
datos la dirección donde fue guardada la imagen.
59
Para la integración de las librerías externas se instaló la gema libFFI que permite la
integración de la aplicación con librerías desarrolladas en lenguaje C o C++.
El entregable generado de esta fase fue una aplicación de servidor llamada EKGAPI que
implementa los servicios web que soportan las funcionalidades del sistema y habilita la
integración con la librería ecgi.so para realizar el diagnóstico de las imágenes de
4.4.1.4 Pruebas:
Para realizar las distintas pruebas sobre los entregables desarrollados se utilizó la
herramienta de pruebas del IDE RubyMine que facilita la prueba de los servicios web Rest,
generando las peticiones dependiendo del caso y mostrando los mensajes de los resultados.
Se utilizaron distintas entidades de prueba incluyendo imágenes para corroborar el
correcto funcionamiento del servidor implementado en el Apéndice I se evidencian los
resultados de las pruebas.
4.4.2 Iteración XP 3(Construcción App):
La tercera iteración se enfocó en desarrollar aquellos requerimientos funcionales que
permitieran realizar la captura de las imágenes utilizando la cámara del dispositivo móvil y
aquellos que habilitaran el envío de dichas imágenes a la aplicación servidor.
Según la premisa planteada en esta iteración se desarrollaron las historias de usuario
relacionadas al requerimiento RF_ECGI_5.
Las tareas que derivan de estos requerimientos se deben desarrollar utilizando el lenguaje
Java apoyado por el kit de desarrollo para aplicaciones móviles nativas Android.
60
Para el desarrollo de aplicaciones móviles que utilicen las cámaras de los dispositivos,
existen en Android dos posibilidades que habilitan el uso de las cámaras.
La primera es utilizar el software de captura de fotos desarrollado por la empresa que
produjo el dispositivo, normalmente esta es una buena opción, siempre y cuando los
requerimientos y necesidades de la aplicación no necesiten de una gran interacción del
usuario con la cámara distinta de la que ofrece el software ya implementado. Por ejemplo, si
las necesidades de la aplicación requieren de filtros, modificación de la imagen en el proceso
de captura, selección de opciones específicas adicionales o apoyos visuales, la posibilidad
queda invalidada.
La segunda posibilidad es utilizar las funciones nativas de Android para utilizar las
cámaras de los dispositivos; en esta segunda opción hay que realizar un mayor trabajo pues
hay que desarrollar el equivalente al software ya desarrollado por las empresas, más las
funcionalidades adicionales requeridas en cada proyecto.
Debido a la naturaleza de las necesidades de la aplicación, la opción que implementa las
funciones nativas de Android, habilita la facilidad de integrar el uso de la cámara con distintas
funcionalidades como la selección de la derivación, mostrar en pantalla la línea base para
alinear y la calibración las distancias en los electrocardiogramas, es por esto que se decidió
realizar la aplicación utilizando esta opción.
4.4.2.2 Diseño:
Debido a la decisión tomada en la fase de planificación, el diseño de la aplicación debe
contener una actividad que maneje las funcionalidades de la cámara y el envío de las
imágenes, dichas funcionalidades implementan las mejores prácticas sobre manejo de
recursos en aplicaciones móviles, utilizando las tareas asíncronas para evitar interrumpir el
flujo principal de la aplicación.
Utilizando los servicios REST desarrollados en la iteración anterior y siguiendo los
lineamientos expuestos sobre las mejores prácticas de servicios web de arquitectura REST;
61
se diseñó el envío de las imágenes a través el método POST de electrocardiogramas,
enviando en el mensaje la imagen codificada en Base64, el formato de la imagen y la
información sobre la derivación capturada.
El kit de desarrollo de Android utiliza una estructura en la cual las vistas con las que
interactúa el usuario se implementan utilizando archivos XML y el manejo de las
funcionalidades utilizando clases de Java, por lo tanto, las aplicaciones móviles Android
deben estar diseñadas utilizando esta estructura.
4.4.2.3 Desarrollo:
Se desarrollaron en esta iteración las historias de usuario (Apéndice C) relacionadas al
requerimiento RF_ECG_5.
Como se explica en el diseño de esta iteración, se deben implementar las vistas en
archivos XML y las clases en Java que habiliten las funcionalidades requeridas.
A continuación, se detalla cómo se realizó la implementación del software que utiliza la
cámara y envía las imágenes al servidor.
Para el desarrollo de esta iteración se utilizó el paquete de Camera2 API que provee
distintas funcionalidades las cuales habilitan el uso de la cámara, utilizando el objeto
Actividad de Android creamos una clase llamada CameraIntentActivity.java que hereda del
objeto Actividad y contiene los siguientes atributos:
- CameraDevice:mCameraDevice: Para la implementación de las funcionalidades de
la cámara debe existir un objeto que referencie al dispositivo de la cámara.
- CaptureRequest:mCaptureRequest: La documentación de dicho paquete requiere de
la creación de un objeto que gestione las peticiones a la cámara de realizar las capturas
- CameraCaptureSession: Adicionalmente se necesita utilizar una sesión de captura
que permite la interacción con la cámara, ésta a través de su callback permite la
sobrecarga de memoria en los métodos que soportan el proceso de captura como
62
onCaptureStarted, onCaptureCompleted y onCaptureFailed, para asegurarse que el
manejo de esta sesión se realice correctamente.
- File:mImageFile: Se requiere también de un objeto que almacene la imagen para
enviarla, guardarla y hacer todas las operaciones necesarias.
- HandlerThread:mBackgroundThread: Las mejores prácticas en desarrollo de
aplicaciones móviles afirman que el uso de diferentes hilos para actividades que
consuman mucha capacidad de procesamiento es la manera para realizar actividades
simultaneas sin interrumpir el proceso principal de la aplicación.
La vista que permite el uso de los métodos desarrollados, se construyó utilizando un
elemento de las vistas de Android llamado TextureView, este elemento es capaz de mostrar
la información que la cámara envía al dispositivo móvil mostrando en pantalla lo que la
cámara ve. Sobre este elemento de vista el usuario debe seleccionar el tipo de derivación
que se está capturando, por lo que esta vista también contiene un elemento spinner (conocido
como combobox) con todas las posibles derivaciones existentes, por último, se agregó una
línea horizontal en el medio de la pantalla, con marcadores de centímetros, que permiten
alinear la línea base del electrocardiograma y los cuadros del papel, para calibrar la cantidad
de pixeles por centímetro.
El entregable generado en esta fase es una aplicación móvil que, utilizando las mejores
prácticas sobre las distintas funcionalidades implementadas, permite la captura de imágenes
identificadas con la derivación correspondiente y el envío de dichas imágenes al servidor
desarrollado.
4.4.2.4 Pruebas:
Para realizar las distintas pruebas sobre el entregable generado se utilizaron el emulador
de Android corriendo la versión de Android 5.0 Lollipop, dos dispositivos móviles Android un
Samsung S4 y un Samsung S5 corriendo las versiones de Android 5.0 Lollipop y Android 6.0
Marshmallow respectivamente.
63
En el proceso de pruebas se detectaron comportamientos distintos en las interfaces
visuales, dichos comportamientos requirieron realizar ajustes a estas interfaces, luego se
realizaron las pruebas para asegurar que las interfaces en los distintos dispositivos
cumplieran los criterios de usabilidad básicos.
También utilizando la aplicación de servidor en equipos bajo una misma red WLAN, se
comprobó el envío y recepción de las imágenes, en el Apéndice J se encuentran los
resultados de las pruebas.
4.4.3 Iteración XP 4(Construcción App 2):
La cuarta iteración se enfocó en el desarrollo de los requerimientos funcionales, que
habilitan la gestión de las diferentes entidades del sistema como los pacientes, los
diagnósticos y los electrocardiogramas.
Analizando que el sistema debe ser capaz de gestionar las operaciones de consulta y
creación en las distintas entidades adicionales que componen el sistema, a través de la
aplicación móvil.
Se planteó que el usuario a través de la aplicación móvil, sería capaz de gestionar la
consulta de los pacientes, electrocardiogramas y diagnósticos; y la creación de pacientes y
El sistema no permite al usuario realizar la eliminación o modificación de las entidades, de
esta manera se evita la alteración en los resultados diagnósticos y reportes del sistema.
Se planificó en esta iteración el desarrollo de las historias de usuario relacionadas a los
requerimientos encontrados en el Apéndice B, RF_ECGI_1, RF_ECGI_2, RF_ECGI_3, que
satisfacen las necesidades expuestas.
64
4.4.3.2 Diseño:
La gestión de las entidades que componen el sistema, se realizó consumiendo los
servicios web diseñados e implementados en la segunda iteración XP de este proyecto, por
lo que en esta fase de la iteración se diseñaron las diferentes peticiones HTTP basados en
la documentación de los servicios REST (Apéndice M) implementados.
Adicionalmente se diseñaron las vistas necesarias para permitir al usuario gestionar las
distintas operaciones y se diseñaron para su implementación las siguientes vistas de usuario:
- Vista Consultar todos los pacientes:
La Vista Consultar pacientes, está compuesta por un elemento ListView, que muestra una
lista con los detalles de todos los pacientes registrados en el sistema, además permite al
usuario seleccionar un paciente y ver el detalle de su información.
- Vista Consultar un solo paciente:
La Vista Consultar un paciente, muestra la información específica del paciente
seleccionado y lista de los electrocardiogramas que le pertenecen. Permite a los usuarios
ver el detalle de un electrocardiograma y agregar un nuevo electrocardiograma.
- Vista Consultar el diagnóstico de un electrocardiograma:
La Vista Consultar el diagnostico de un electrocardiograma, muestra la información sobre
el diagnóstico de el electrocardiograma seleccionado.
- Vista Agregar un paciente
La Vista Agregar un paciente permite a los usuarios a través de un formulario agregar al
sistema la información de un paciente.
- Vista Agregar un electrocardiograma
La vista Agregar un electrocardiograma fue se implementó en la iteración de XP anterior
y permite a los usuarios tomar la foto de una derivación, seleccionar la derivación y enviar
la foto al servidor.
La última en la lista se implementó en la iteración anterior de XP.
65
En el Apéndice K se observan las pantallas de la aplicación.
Para el diseño de estas vistas, consultas y peticiones generadas se utilizaron las mejores
prácticas expuestas en el libro RESTFul Web Services [36.].
4.4.3.3 Desarrollo:
El desarrollo de una aplicación Android requiere la codificación de las vistas y de las
funcionalidades en archivos separados con distintos formatos, por lo tanto, en esta fase se
desarrollaron las vistas utilizando los componentes de vistas que ofrece Android y las
actividades que soportan las funcionalidades de la aplicación.
La vista que permite la creación de un paciente, necesita componentes que permitan al
usuario ingresar información, para esto se utilizaron los componentes EditText, DateChooser
y Spinner, que permiten el input de texto, la selección de una fecha y la selección única sobre
una lista, respectivamente.
Adicionalmente para las operaciones de consulta de varios elementos o de una lista de
elementos se implementó el componente de vista ListView, que apoyado por un objeto
ArrayAdapter, permite mostrar en la vista la información que contiene un arreglo.
El ArrayAdapter permite actualizar el componente de vista ListView inmediatamente exista
algún cambio en el arreglo. El uso de un ArrayAdapter asegura la optimización del manejo
de memoria en el dispositivo, éste carga en memoria solamente los registros que son
necesarios para una transición suave entre los elementos. Es decir, solamente carga la
cantidad de elementos que caben en la pantalla del dispositivo, más dos elementos
adicionales: el elemento que antecede al primer elemento que se muestra en la lista y el
elemento que sucede al último elemento de la lista.
Naturalmente cuando el usuario interactúa con la lista y requiere de más registros el
ArrayAdapter actúa utilizando la misma práctica, asegurando que la cantidad de memoria
necesaria esta optimizada sin sacrificar experiencia de usuario.
La implementación del consumo de los servicios web en dispositivos móviles, exige el uso
de buenas prácticas. Utilizando las tareas asíncronas en actividades que requieren el uso de
66
la red, se asegura que el hilo principal de ejecución de la aplicación se mantiene sin
interrupciones, mientras se realizan las peticiones necesarias.
El equipo de desarrollo de Android utilizando estas prácticas, diseñó e implementó un
objeto llamado AsyncTask, cuyo propósito es crear un hilo de ejecución de la aplicación
diferente al hilo de ejecución principal. Los procesos que corren en este hilo no interfieren
con el funcionamiento de la aplicación, por ejemplo, las peticiones HTTP deben
obligatoriamente implementarse en una tarea asíncrona o AsyncTask, de lo contrario la
aplicación no funcionará correctamente.
Se utilizó la librería llamada AsyncHttpClient, que implementa las funcionalidades de
peticiones HTTP de un cliente, utilizando el objeto AsyncTask asegurando que dichas
peticiones no interfieran con el hilo principal de ejecución de la aplicación, mejorando la
experiencia de usuarios con un flujo continuo en todas las actividades que realiza en la
aplicación.
El entregable generado en esta fase es una aplicación Android, capaz de integrarse con
la aplicación de servidor y gestionar la información necesaria para realizar el diagnostico de
los electrocardiogramas.
4.4.3.4 Pruebas:
Para realizar las distintas pruebas sobre el entregable generado de esta iteración se
utilizaron también como en la iteración anterior, el emulador de Android utilizando la versión
de Android 5.0 Lollipop, dos dispositivos móviles Android un Samsung S4 y un Samsung S5
utilizando las versiones de Android 5.0 Lollipop y Android 6.0 Marshmallow respectivamente.
Nuevamente se detectaron comportamientos distintos en las interfaces visuales que
interferían con la usabilidad de la aplicación. Se realizaron ajustes necesarios a las interfaces
para su correcto uso en los distintos dispositivos y tamaños de pantalla.
67
Bajo una misma red WLAN se comprobó que el servidor recibía y respondía las peticiones
de manera correcta, realizando el funcionamiento planificado y diseñado en esta iteración.
4.4.4 Iteración XP 5(Integración Servidor, App, Librería):
La quinta iteración se decidió enfocar en realizar la integración de la aplicación móvil, el
servidor y la librería.
El desarrollo de los distintos componentes del sistema explicados anteriormente se realizó
analizando los requerimientos del sistema diseñado, el sistema requiere la integración entre
sus componentes, por lo que se diseñaron pensando que se debía facilitar la integración y la
comunicación entre ellos.
Para la integración de la aplicación móvil con el servidor se utilizaron los servicios web
REST y las peticiones HTTP del cliente móvil, habilitando de esta manera las mejores
prácticas de adaptabilidad, escalabilidad, seguridad y robustez del sistema.
En el caso de la integración entre la librería y la aplicación de servidor se planificó el uso
de una librería llamada libFFI, que permite la comunicación entre aplicaciones
implementadas en lenguajes de alto nivel como Ruby y aplicaciones implementadas en
lenguaje C o C++. Los distintos lenguajes y frameworks escogidos facilitaron esta integración.
4.4.4.2 Diseño:
Partiendo de la base expuesta en la planificación, la integración de los componentes del
sistema se desarrolló en dos partes los servicios web y la librería libFFI.
En el caso de los servicios web se utilizaron claves de autenticación para asegurar que
las peticiones que el servidor recibe, se originan desde clientes confiables y no de cualquier
68
cliente, así las peticiones de los clientes deben contener en su mensaje una APIKey o clave
de API que los autentica.
En el caso de la librería libFFI, existen varias posibilidades para compilar las librerías y
cada una habilita distintas características que facilitan la integración. Se escogió en este caso
utilizar una librería dinámica compartida, éste tipo de librerías habilitan el uso de sus
funcionalidades, sin necesidad de compilar el código cuando se requiere su ejecución,
aumentando significativamente la velocidad de procesamiento de las funciones.
Tomando en cuenta que la interpretación digital de imágenes consume grandes
cantidades de procesamiento y memoria en el sistema, esta decisión de integración
disminuye el consumo de recursos, por lo tanto, la velocidad de respuesta aumenta sin la
necesidad de un servidor con mayor capacidad de procesamiento y/o memoria, permitiendo
la ejecución de la aplicación de servidor y la interpretación de las imágenes casi a tiempo.
4.4.4.3 Desarrollo:
El desarrollo de esta iteración se enfocó en la codificación e integración de distintas
librerías y gemas para asegurar la integración necesaria.
Para realizar la integración entre la aplicación de servidor y la librería que realiza la
interpretación de las imágenes se instaló la gema ffi.gem, ésta permite crear un módulo que
inicia cuando la aplicación se ejecuta e interpreta una interfaz o archivo header del lenguaje
C++. El archivo extension.rb utiliza un método que extiende la librería ecgi.dylib y agrega las
funciones y métodos de la librería, creando una instancia de un objeto wrapper que contiene
dichas funciones y métodos declarados en el archivo de interfaz de la librería.
El objeto EcgiWrapper permite utilizar la función diagnose de la librería implementada, el
framework Ruby on Rails, permite el uso de distintos Callbacks sobre las entidades del
sistema. Los ApplicationRecordCallbacks son estados del proceso de gestión de las
entidades, que habilitan la programación de ciertas tareas en dichos estados. Los distintos
estados que existen son por ejemplo before_save, after_save, before_commit, etc. Por lo
69
tanto, si se desea implementar la ejecución de alguna función en el momento que representa
cada estado, el uso de los Callbacks es la manera correcta.
En el flujo del sistema, la entidad Electrocardiograma ejecuta la función diagnose después
que el sistema realizó el commit de la transacción en la base de datos, utilizando el callback
after_commit se llama a la función diagnose. Esta función utiliza el objeto EcgiWrapper para
ejecutar la función diagnose de la librería de diagnóstico, pasando como parámetro la ruta
de donde se encuentra la imagen.
La librería recibe la ruta de la imagen, realiza la interpretación y el diagnóstico y regresa
un número entero que corresponde cada uno al diagnóstico de alguna patología encontrada
en la imagen de la derivación. La siguiente tabla representa la correspondencia de los
números con el diagnóstico.
Número entero Diagnóstico
1 Electrocardiograma no presenta ninguna de las patologías planteadas
2 Electrocardiograma presenta la patología Hipertrofia Ventricular
3 El electrocardiograma presenta la patología Fibrilación Auricular
4 El electrocardiograma presenta la patología Fibrilación Ventricular
Tabla 1-Diseño de respuesta por Patología [Fuente propia]
Utilizando la tabla anterior la función crea una instancia de la entidad Diagnostic con la
información del electrocardiograma y el diagnóstico de las patologías encontradas, para su
posterior consulta.
Para realizar la integración de los servicios web con la aplicación móvil se utilizó un objeto
api_key que se encarga de generar un token de autenticación, los controladores de cada
entidad utilizan el callback before_filter y validan la existencia de dicha clave en los registros
de la aplicación, en caso de existir, continúa procesando los requerimientos de la petición
recibida. En caso contrario, el controlador retorna en el header de la respuesta el mensaje:
unauthorized.
70
4.4.4.4 Pruebas:
Para realizar las pruebas de esta iteración se instaló la aplicación móvil en los dispositivos
móviles Android Samsung S5 y Samsung S4, se inició en una computadora con sistema
operativo MacOSX, la base de datos con el manejador MySQL y el servidor rails, luego se
agregó al directorio la librería ecgilib.dylib.
Se conectaron todos los dispositivos a una misma red WLAN y se realizaron las pruebas
sobre todo el flujo del sistema, verificando en los logs de la aplicación y la librería la recepción
y respuesta de las peticiones, la interpretación de las imágenes y la ruta en donde se
encuentran las mismas.
Todas las pruebas pasaron sin complicación, comprobando la correcta funcionalidad del
sistema implementado, en el Apéndice N se evidencian los resultados de estas pruebas.
4.4.5 Iteración XP 6 (Herramienta de reportes):
La sexta iteración se enfocó en desarrollar los requerimientos funcionales que satisfacen
las necesidades de la herramienta de reportes del proyecto.
La herramienta de reportes se encargará de mostrar la información del sistema de manera
organizada y fácil de entender. Se utilizarán distintos parámetros sobre los reportes para
clasificar y mostrar los resultados de los diagnósticos realizados sobre los pacientes.
En esta iteración se desarrollarán las historias de usuario HU_ECGI_7, HU_ECGI_8,
HU_ECGI_9 (Apéndice C) relacionadas al requerimiento funcional RF_ECGI_5.
Las historias de usuario en esta iteración, se implementarán a través de un sistema web
que consultará la base de datos del sistema y generará los elementos necesarios.
71
4.4.5.2 Diseño:
La herramienta de reportes forma parte de la aplicación de servidor, permitiéndole
consultar la base de datos sin comprometer la seguridad del sistema desarrollado.
Los reportes diseñados son:
- Reporte de cantidad de los diagnósticos por patología, filtrado por rango de edad y
género del paciente.
- Reporte de cantidad de diagnósticos de fibrilación ventricular, filtrado por rango de
edad y por género del paciente.
- Reporte de cantidad de diagnósticos de fibrilación auricular, filtrado por rango de edad
y por género del paciente.
- Reporte de cantidad de diagnósticos de hipertrofia ventricular, filtrado por rango de
edad y por género del paciente.
La interfaz web de la herramienta debe permitir al usuario seleccionar entre los distintos
filtros y visualizar la cantidad de casos reportados de manera sencilla por lo que se decidió
implementar el uso de gráficos de torta en la presentación de la información.
Para el diseño de la interfaz web, se utilizó una plantilla realizada con Bootstrap llamada
AdminLTE, que contiene elementos gráficos prediseñados para su uso en el diseño de la
interfaz. El uso de esta plantilla asegura las mejores prácticas de usabilidad, manteniendo
los elementos gráficos bajo los mismos estándares establecidos en la plantilla.
4.4.5.3 Desarrollo:
El desarrollo de esta iteración se centró en la implementación de los requerimientos que
satisfacen las necesidades de la herramienta de reportes.
Utilizando las convenciones de Ruby on Rails, se crearon los archivos html.erb (html
embedded ruby) y se le asignó una ruta que llama a dos métodos: filter y report. Estos
métodos se encuentran en el controlador de los diagnósticos y se encargan de capturar la

72
información de los filtros y luego realizar la consulta en la base de datos para obtener el
reporte que el usuario especifique.
El archivo filter.html.erb, permite al usuario a través de dos seleccionadores, escoger el
rango de edades que desea filtrar para el reporte, también permite seleccionar el género de
los pacientes que se deseen filtrar.
Utilizando esta información se realiza la consulta a la base de datos, la cual se encarga
de unir las tablas de pacientes, electrocardiogramas y diagnósticos para contar las
ocurrencias de las distintas patologías en los diagnósticos de los electrocardiogramas,
pertenecientes a los pacientes que cumplan con los criterios seleccionados por el usuario.
La gema llamada ChartKicks, permite mostrar los resultados obtenidos en las consultas
utilizando gráficos.
4.4.5.4 Pruebas:
Para realizar pruebas sobre la herramienta de reportes se utilizó el archivo seed.rb. Rails
utiliza este archivo para insertar información en la base de datos, de esta manera se pueden
insertar masivamente, datos de prueba o registros necesarios en la base de datos antes de
iniciar la aplicación.
El archivo seed.rb contiene datos de prueba conocidos y controlados que con el comando
rake db:seed se insertaron en la base de datos, posteriormente se realizaron consultas de
prueba sobre la base de datos para corroborar su exactitud.
Nuevamente se inició la aplicación de servidor y el manejador de base de datos en una
computadora, para probar si el acceso desde el navegador mostraba la información que
satisface los reportes diseñados.
73
El sistema pasó todas las pruebas probando la correctitud de su funcionalidad.
Hito: Fin construcción Sistema.
El sistema desarrollado es una herramienta de apoyo para la investigación realizada en el
proyecto, permitiendo realizar pruebas sobre las perspectivas e hipótesis planteadas en la
actividad anterior. Posteriormente se analizaron los resultados y se derivó una conclusión,
apoyada por los resultados obtenidos en el proceso de investigación y validación a través de
la experimentación.
4.5 ¿Las perspectivas claves llevan a una conclusión?
Continuando con las actividades que propone la metodología se debe analizar en este
momento, apoyados por las herramientas desarrolladas en la fase anterior, si las
perspectivas o hipótesis claves permiten llegar a una conclusión.
En esta segunda iteración utilizando la investigación realizada, se plantearon las
siguientes hipótesis o perspectivas:
- La implementación de las funciones matemáticas para la detección de los
puntos de inflexión en la curva y utilizando estos puntos para detectar e identificar
los distintos segmentos, es una aproximación teórica a la solución del problema
encontrado en el Paso 1 del Algoritmo de Diagnóstico.
En el proceso de validación se encontró que las implementaciones de la segunda derivada
matemática, están enfocadas a detectar cambios bruscos en las curvas, identificando un
claro cambio de dirección de la curva. Por ejemplo, la libería OpenCV utiliza este método
para la detección de los cambios de intensidad en los colores, permitiendo identificar por
ejemplo donde terminan y donde comienzan los objetos en una imagen.
Realizando pruebas con electrocardiogramas reales, se concluyó que esta vía no asegura
la correcta identificación de los segmentos P-Q-R-S-T, porque los cambios de inflexión en

74
la curva de los electrocardiogramas reales, no son tan fáciles de notar como, por ejemplo,
los cambios de color entre el cielo y un edificio en una imagen. Este resultado obtenido
invalida esta perspectiva pues ésta no satisface las necesidades del proyecto.
- La solución de este problema en el Paso 1, permitiría mantener el mismo flujo
de pasos planteados en el Algoritmo.
Como se explica anteriormente el Algoritmo planteado no satisface las necesidades del
proyecto, por lo que se debe implementar un algoritmo diferente que aumente la capacidad
de acierto en la detección de los segmentos P-Q-R-S-T.
- Una Red Neuronal es capaz de aprender y detectar los distintos patrones
existentes en los electrocardiogramas para generar un diagnostico confiable.
Apoyado por la conclusión de la perspectiva anterior, el uso de una tecnología distinta que
permita emular el comportamiento de la mente humana en el proceso de detectar
patrones, refuerza que esta perspectiva apoyada por Redes Neuronales, es la mejor
aproximación para la detección de los patrones que describen las distintas patologías.
La implementación de dichas redes permite la construcción de sistemas capaces de tomar
decisiones basadas en detección de patrones, por ejemplo, se podría entrenar una red
con señales de electrocardiogramas que presenten distintas patologías y señales que no
presenten ninguna patología, indicando en cada caso la presencia o ausencia de las
patologías; al finalizar el entrenamiento la Red Neuronal sería capaz de recibir como
entrada una nueva señal e indicar con cual patología presenta mayor similitud permitiendo
generar un diagnóstico.
- El desarrollo de un algoritmo completamente distinto apoyado por la
implementación de una red neural entrenada para la detección de las patologías en
los electrocardiogramas es una aproximación a la solución del problema
encontrado en la fase de análisis anterior.
75
Según la conclusión anterior, un algoritmo apoyado en la implementación de una red
neuronal, entrenada para recibir señales de distintas derivaciones y diagnosticar
diferentes patologías, plantea una solución viable a la incógnita del proyecto.
Dicho Algoritmo recibiría de entrada las imágenes de las señales extraídas de las
imágenes procesadas por el Algoritmo de Interpretación de Electrocardiogramas diseñado
e implementado en el proyecto y sería capaz de generar un diagnóstico, que utilizando las
herramientas implementadas aumentarían la cantidad de aciertos del sistema.
Luego de realizar el análisis anterior la respuesta que se obtiene a partir de dicho análisis
es que sí es posible llegar a una conclusión utilizando las perspectivas clave planteadas en
esta fase de la iteración, por lo que se puede continuar con la siguiente fase de la
metodología.
5. Fase Conclusión v2:
5.1 Discutir sobre las perspectivas clave:
Continuando el flujo de las actividades en la metodología para el desarrollo de una
conclusión se discutieron las perspectivas clave, los resultados de la investigación y los
resultados de los experimentos realizados con la herramienta desarrollada.
5.2 Seleccionar Material que Lleva a la Conclusión
El material seleccionado que aporta el desarrollo de las conclusiones es en conjunto con
la investigación, el resultado obtenido en la fase de análisis, específicamente en la fase de
validación de las perspectivas clave.
En dicha fase se encontró, el origen del problema que presenta el algoritmo diseñado y
también una solución viable para resolverlo, ambos hallazgos se apoyan por los resultados
obtenidos en este trabajo, por lo tanto, este es el material que aporta la mayor cantidad de
información, para generar una conclusión.
5.3 Escribir conclusión

76
Apoyados por las perspectivas clave seleccionadas en la actividad anterior se llegó a las
siguientes conclusiones:
- El algoritmo de interpretación de imágenes de electrocardiogramas satisface las
necesidades del sistema
- El algoritmo de diagnóstico de las señales planteado no satisface las necesidades
del sistema por lo que se debe plantear un algoritmo diferente que satisfaga con mayor
cantidad de acierto las necesidades del sistema.
- El diseño e implementación de un algoritmo de diagnóstico utilizando una Red
Neuronal entrenada para la detección de los patrones que presentan las patologías,
satisface las necesidades del sistema.
- Las herramientas desarrolladas habilitan la facilidad de la modificación de dicho
algoritmo, pues el proceso de captura de imágenes y gestión de los pacientes y
diagnósticos, no se ve afectado por el problema que presenta el algoritmo de diagnóstico
planteado.
5.4 Validar conclusión con perspectivas clave
Apoyadas por las hipótesis y perspectivas claves derivadas en las distintas fases
anteriores, las conclusiones se validan automáticamente pues se derivan de los resultados
obtenidos sobre las distintas perspectivas. Adicionalmente se debe respaldar las distintas
conclusiones con el material investigado y con pruebas realizadas con expertos.
En el material investigado se encontró que las redes neuronales habilitan la
implementación de funcionalidades para la detección de patrones, bajo un comportamiento
muy parecido a la mente humana, por lo que respalda la conclusión que plantea que la
aproximación correcta a solucionar el problema presentado en el algoritmo diseñado, es
utilizar un algoritmo apoyado por una red neuronal entrenada.
Adicionalmente para respaldar la conclusión que afirma que el algoritmo planteado en este
proyecto no satisface las necesidades del sistema, se contactó un médico cirujano Dr. Juan
77
Carlos Belandría, con su apoyo se realizó una comparación de los diagnósticos que generan
la herramienta sobre las patologías seleccionadas y los diagnósticos que él realizó utilizando
sus conocimientos médicos.
El porcentaje de aciertos encontrado en esta comparación fue del 0%. Analizando con
detalle los planteamientos anteriores, se puede concluir que esto se debe al problema que
presenta la detección acertada de los segmentos P-Q-R-S-T. En el algoritmo de diagnóstico
que se diseñó, se detectó que la raíz del problema fue que el diseño del algoritmo se basó
en el uso de electrocardiogramas teóricos muy diferentes a los electrocardiogramas reales
impresos por un electrocardiógrafo. Estas pruebas se encuentran en el Apéndice L.
5.5 ¿Las conclusiones responden las preguntas de la investigación?
¿Es posible diseñar e implementar un algoritmo que interprete imágenes de
electrocardiogramas y sus derivaciones?
Analizando las conclusiones expuestas y su validación en las actividades anteriores se
puede concluir que sí es posible diseñar e implementar un algoritmo que interprete imágenes
de electrocardiogramas y sus derivaciones.
Siguiendo los pasos expuestos en el Algoritmo de Interpretación diseñado se asegura que
la interpretación de las imágenes de electrocardiogramas y sus derivaciones se realiza de
manera correcta.
¿Es posible diseñar e implementar un algoritmo que diagnostique patologías en las
derivaciones?
La respuesta a esta pregunta se encuentra en las conclusiones obtenidas luego de
analizar los resultados de los experimentos realizados.
Sí, es posible diseñar e implementar un algoritmo que diagnostique patologías en las
distintas derivaciones obtenidas, siempre y cuando éste se apoye en una Red Neural
entrenada para detectar los patrones de las distintas patologías en las derivaciones.
78
Siguiendo las actividades de la metodología, las conclusiones derivadas sí responden las
preguntas de la investigación, por lo que se puede afirmar que el proyecto de tesis ha sido
completado.
79
CAPÍTULO V
RESULTADOS
La metodología utilizada permite claramente identificar los resultados obtenidos en el
desarrollo
A continuación, se detallan los resultados obtenidos por cada uno de los objetivos
específicos de este trabajo especial de grado.
- Diseñar e implementar una aplicación móvil capaz de recopilar y enviar la
información necesaria para realizar la interpretación de electrocardiogramas.
La investigación realizada permitió analizar todas las posibilidades para la implementación
de una aplicación móvil capaz de satisfacer las necesidades de este objetivo.
Para satisfacer las necesidades se concluyó que dicha aplicación debería ser capaz de
gestionar las distintas entidades existentes en el sistema, por lo tanto, la aplicación debe,
además de enviar información ingresada por el usuario, capturar imágenes utilizando la
cámara de los dispositivos y enviar dichas imágenes a un servidor.
La mejor manera de implementar dicha aplicación es utilizar las funciones nativas de
Android, que permiten la interacción directa con la cámara del dispositivo. Utilizando dichas
funciones en conjunto con la implementación de funcionalidades que habiliten el consumo de
servicios web REST, aseguramos que la aplicación satisface las necesidades de este
objetivo.
El resultado de este objetivo es una aplicación móvil para sistemas Android, que
consumiendo los servicios de un servidor y utilizando la cámara de los dispositivos es capaz
de gestionar la información necesaria para realizar la interpretación de los
- Diseñar e implementar un algoritmo de procesamiento de imágenes para
En el proceso de investigación realizado se concluyó que para el procesamiento y la
interpretación de imágenes, la librería OpenCV ofrece las mejores herramientas que facilitan
80
la manipulación de las imágenes.
Dicha librería contiene métodos de extracción de colores, métodos para disminuir la
cantidad de ruido en una imagen y métodos que permiten convertir las imágenes en matrices
compuestas de vectores que describen las imágenes, entre otros.
El análisis realizado sobre los electrocardiogramas y sus características, permitió diseñar
un algoritmo apoyado en los métodos de dicha librería, que sea capaz de interpretar la
imagen y extraer la señal de una derivación, pues la señal de un electrocardiograma está
representada generalmente, por una curva de color negro impresa en un papel cuadriculado
de colores pasteles.
El resultado de este objetivo es el diseño de un algoritmo capaz de interpretar y extraer
de una imagen, la señal de un electrocardiograma. Adicionalmente se realizó la
implementación de dicho algoritmo, en una librería compartida que utilizando las
herramientas de OpenCV, recibe de entrada la imagen de un electrocardiograma y genera
de salida un vector X Y que representa la señal del electrocardiograma.
- Diseñar e implementar un algoritmo de reconocimiento de patrones que con ciertos
niveles de tolerancia pueda diagnosticar patologías en los electrocardiogramas.
Utilizando los resultados obtenidos en el proceso de investigación, relacionados al proceso
de diagnóstico de un electrocardiograma y utilizando las herramientas de la librería OpenCV,
se diseñó un algoritmo cuyo propósito es identificar en las señales de electrocardiogramas,
patrones que permitirían diagnosticar distintas patologías presentes en la señal. Para probar
el correcto funcionamiento de dicho algoritmo, se implementó en la librería compartida, los
métodos que ejecutan el algoritmo diseñado.
El proceso de análisis y validación de las hipótesis planteadas, permitió realizar distintas
pruebas de dicho algoritmo que apoyarían que el algoritmo diseñado e implementado, cumple
con los objetivos de manera satisfactoria. Se encontró que dicho algoritmo no satisface los
requerimientos de los objetivos, pues no es capaz de identificar patrones en los
electrocardiogramas para luego diagnosticar patologías.
81
Este hallazgo obligó a realizar una iteración sobre la metodología e investigar
nuevamente, para encontrar el origen del problema y una solución capaz de satisfacer los
requerimientos de dicho objetivo.
El nuevo proceso de investigación, permitió concluir que el origen del problema
encontrado en el algoritmo de diagnóstico, es que su diseño se realizó utilizando solamente
información sobre los electrocardiogramas teóricos y no reales, pues el análisis de los
electrocardiogramas reales suele ser menos matemático.
Además, en esta nueva iteración se generaron dos alternativas, una capaz de solucionar
el problema encontrado en el algoritmo, satisfaciendo las necesidades del objetivo y otra
alternativa capaz de satisfacer las necesidades de dicho objetivo, a través del diseño e
implementación de un nuevo algoritmo, que incluya el uso de las Redes Neuronales para
detectar patrones y tomar decisiones
El resultado de este objetivo luego de analizar las distintas alternativas, es que la mejor
manera de diseñar un algoritmo capaz de reconocer patrones y con ciertos niveles de
tolerancia diagnosticar las distintas patologías en las señales de los electrocardiogramas, es
a través de la implementación de una Red Neuronal.
- Diseñar e implementar una aplicación de servidor que utilizando los algoritmos
planteados, reciba las imágenes de los electrocardiogramas, las interprete y
diagnostique; para enviar la respuesta a la aplicación móvil.
Analizando los resultados encontrados en el objetivo anterior, se planteó que el diseño de
dicho sistema debería ser capaz de adaptarse a cambios enfocados en satisfacer los
requerimientos planteados sobre el diagnostico de los electrocardiogramas.
Por lo tanto, la aplicación de servidor fue diseñada de tal manera que su funcionamiento
es independiente a la implementación de los algoritmos diseñados. La aplicación se integra
con la librería compartida para ejecutar las actividades de los algoritmos diseñados, por lo
tanto, si se modifica la librería la aplicación de servidor no debe modificarse y satisfacer las
necesidades del proyecto.
82
El resultado de este objetivo es una aplicación de servidor implementada en Ruby On
Rails, que a través de servicios web REST y la extensión de la librería propia, es capaz de
procesar la información enviada por la aplicación Android, relacionada a los pacientes,
electrocardiogramas y diagnósticos.
- Diseñar e implementar una aplicación web, que sea capaz de generar reportes sobre
las patologías identificadas, filtradas por la información básica del paciente.
La medicina es una ciencia que utiliza mucho las estadísticas para generar conclusiones,
por lo tanto, una herramienta capaz de gestionar la información sobre casos médicos
clasificados y filtrados para su fácil entendimiento, apoyaría la investigación en los estudios
de la medicina.
Una herramienta de reportes sobre los registros del sistema implementado, habilitaría a
los médicos especialistas una fuente de información para realizar investigaciones sobre los
diagnósticos de las patologías.
El resultado de este objetivo es una aplicación de reportes que permite a los usuarios
visualizar los resultados de los diagnósticos realizados por el sistema, filtrados por edad y
género de los pacientes.
- Realizar las pruebas necesarias en conjunto con un médico especialista para
analizar y verificar el nivel de confianza de los diagnósticos generados por el
sistema.
Los resultados que arrojan los sistemas médicos se deben verificar con un especialista
para comprobar su confiabilidad, para esto se realizaron diagnósticos sobre distintas
derivaciones que presentaban las patologías a diagnosticar. Dicho diagnóstico se realizó por
un médico cirujano y por el sistema, para buscar la cantidad de aciertos del sistema en
comparación con los resultados del médico.
Luego de realizar las pruebas se encontró que el porcentaje de aciertos es de 0% pues el
problema presente en el algoritmo diseñado evita que la aplicación genere diagnósticos
correctos.
83
CAPITULO VI
CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
- Diseñar e implementar una aplicación móvil capaz de recopilar y enviar la
información necesaria para realizar la interpretación de electrocardiogramas.
Los resultados obtenidos en el desarrollo de este objetivo, permitieron concluir que
una aplicación móvil capaz de gestionar la información necesaria para la interpretación
de electrocardiogramas, es un gran aporte a los avances de la medicina, pues además
de apoyar a los especialistas a tomar las decisiones, permite recopilar fácilmente, gran
cantidad de información útil para realizar estudios médicos.
- Diseñar e implementar un algoritmo de procesamiento de imágenes para
El algoritmo diseñado e implementado, capaz de procesar e interpretar las imágenes
de electrocardiogramas, permitió concluir que el uso de la visión de computadora, habilita
una nueva posibilidad para automatizar procesos de observación y análisis, normalmente
realizados por un ser humano.
La librería OpenCV es hoy la mejor alternativa para implementar las funciones que
permiten a las computadoras “ver”, pues implementa gran cantidad de métodos que
facilitan la interpretación de imágenes.
El algoritmo diseñado e implementado utilizando estas herramientas es capaz de
correctamente extraer de una imagen la señal de un electrocardiograma.
- Diseñar e implementar un algoritmo de reconocimiento de patrones que con ciertos
niveles de tolerancia pueda diagnosticar patologías en los electrocardiogramas.
Si bien se menciona que la visión de computadora permite interpretar las señales de
los electrocardiogramas, ésta requiere de un sistema más completo para realizar el
diagnóstico de los electrocardiogramas, esto se debe a que el proceso de diagnóstico de
electrocardiogramas reales, requiere de un comportamiento parecido a la mente humana.
84
Esto se concluyó apoyado por los resultados encontrados en el desarrollo de este
trabajo, los cuales permitieron reconocer el origen de los problemas en el diseño del
algoritmo y encontrar una solución que satisface los requerimientos de este objetivo.
Se encontró que la implementación de una Red Neuronal entrenada para detectar los
patrones en las señales extraídas de las imágenes, es la manera correcta de satisfacer y
cumplir los requerimientos de este objetivo.
- Diseñar e implementar una aplicación de servidor que, utilizando los algoritmos
planteados, reciba las imágenes de los electrocardiogramas, las interprete y
diagnostique; para enviar la respuesta a la aplicación móvil.
La implementación de las mejores prácticas, enfocadas en habilitar las características
de adaptabilidad del software, permite reutilizar las herramientas implementadas en este
trabajo, con la finalidad de facilitar la solución del problema encontrado.
Utilizando los resultados obtenidos, se concluyó también que es de gran importancia
implementar las mejores prácticas en el desarrollo de los servicios REST, pues a pesar
de ser muy útiles para realizar integraciones, exponen vulnerabilidades que deben ser
eliminadas para evitar la corrupción del sistema.
- Diseñar e implementar una aplicación web, que sea capaz de generar reportes
estadísticos de las patologías identificadas, segmentadas por la información básica
del paciente.
El valor que agrega una herramienta de reportes sobre los resultados obtenidos es de
gran aporte a la medicina, permitiendo a los investigadores estudiar y analizar grandes
cantidades información valiosa para sus hallazgos.
- Realizar las pruebas necesarias en conjunto con un médico especialista en el área
de cardiología para analizar y verificar el nivel de confianza de los diagnósticos
generados por el sistema.
La evaluación de los sistemas que automatizan procesos médicos, debe realizarse
tomando en cuenta que los resultados de estos procesos impactan sobre la vida de los
85
pacientes, por lo tanto, un equipo de médicos debe validar si los resultados que arroja el
sistema son suficientemente confiables.
86
RECOMENDACIONES
A continuación, se mencionan algunos aspectos que no forman parte del alcance de este
trabajo, pero mejoran los resultados y permiten realizar futuras investigaciones.
- Implementar e integrar al sistema desarrollado en este trabajo, una red neuronal
entrenada para detectar los distintos patrones que describen las patologías.
- Utilizar la metodología diseñada para el desarrollo de trabajos que requieran la
integración de la ingeniería informática con alguna otra ciencia, asegurando la correcta
ejecución del proceso de investigación y desarrollo de la solución.
- Ampliar el alcance del sistema desarrollando una versión de la aplicación cliente que
pueda ejecutarse en otros sistemas operativos como iOS o en otros sistemas
operativos como iOS.
- Implementar e integrar al sistema, una herramienta que permita cambiar y calibrar el
color utilizado para extraer la señal, ajustado a los distintos electrocardiogramas
impresos, ampliando la variedad de electrocardiogramas que el sistema puede
diagnosticar.
- Diseñar e implementar algoritmos que permitan diagnosticar patologías presentes en
los electrocardiogramas, distintas a las analizadas en el presente trabajo, ampliando
el uso de la aplicación.
- Diseñar e implementar una interfaz que permita integrar el sistema desarrollado con
distintos electrocardiógrafos digitales, habilitando la posibilidad de realizar el
diagnóstico de señales no impresas.
- Integrar el sistema con bases de datos de electrocardiogramas diagnosticados como
PhysioNet y MIT-BIH, para en el caso de la red neuronal, aumentar los porcentajes de
acierto de los diagnósticos.
- Publicar los servicios web API REST, para permitir a distintos desarrolladores consumir
los servicios y ampliar las funcionalidades de los sistemas que requieran de realizar
diagnósticos.
87
REFERENCIAS BIBLIOGRÁFICAS
[1.] Dale Dubin, MD. (2000) Rapid Interpretation of EKG’s 6th Edition.
[2.] Diccionario de términos médicos. Real Academia Nacional de Medicina. 2012.
[3.] Terminología anatómica: Terminología anatómica internacional. 2001. Editorial
Médica Panamericana.
[4.] Manual de Electrocardiografía AMIR. (3era ed.) (2015). Academia MIR
[5.] Verdecchia P, Angeli F, Reboldi G, Carluccio E, Benemio G, Gattobigio R, et al. (2003)
Improved cardiovascular risk stratification by a simple ECG index in hypertension. Am J
Hypertens.
[6.] Levy D, Garrison RJ, Savage DD, Kannel WB, Castelli WP.(1990) .Prognostic
implications of echocardiographically determined left ventricular mass in the Framingham
Heart Study. N Engl J Med.
[7.] Epstein AE, DiMarco JP, Ellenbogen KA, et al. (2012) ACCF/AHA/HRS focused
update incorporated into the ACCF/AHA/HRS 2008 guidelines for device-based therapy of
cardiac rhythm abnormalities: a report of the American College of Cardiology
Foundation/American Heart Association Task Force on Practice Guidelines and the Heart
Rhythm Society. J Am Coll Cardiol. [en línea]. Disponible en:
www.ncbi.nlm.nih.gov/pubmed/23265327 [2016,10 Agosto].
[8.] OpenCV Documentation. [en línea]. OpenCV Developers Team. Disponible en :
http://opencv.org/documentation.html [2016, Febrero 15]
[9.] Foley J. y Van Dam A. (1982) .Fundamentals of Interactive Computer Graphics.
EEUU: George Washington University, Brown University.
[10.] Gonzalez R. y Woods R. (2007), Digital Image Processing 3rd Edition. EEUU:
University of Tenessee
[11.] Android Google Team. Android Open Source Project,[en línea]. Disponible en :
Source.android.com[2016, Agosto 20]
88
[12.] AsyncHTTPClient, Async Http Client , Repositorio de Github [en línea] Disponible en:
https://github.com/AsyncHttpClient/async-http-client [2016, Agosto 20]
[13.] Android Google Team , android.hardware.camera2 Documentation [en línea] Disponible
en:https://developer.android.com/reference/android/hardware/camera2/package-summary.html
[2016, Agosto 20]
[14.] Stroustrup, Bjarne (1997). The C++ Programming Language (3era ed.)
[15.] Green A. Foreign Function Interface Library Documentation [en línea]. Disponible en:
https://sourceware.org/libffi/ [2016, Agosto 16 ]
[16.] Matsumoto Y.(2001). Ruby in a Nutshell. EEUU: O´Reilly
[17.] Rails Development Team. Getting Started with Rails. [en línea] Disponible en:
http://guides.rubyonrails.org/getting_started.htm [2016 , Agosto 15]
[18.] RubyGems Documentation [en línea] Disponible en :http://guides.rubygems.org/
[2016, Agosto 16]
[19.] FFI, Ruby Foreign Function Interface ruby-ffi,[en línea] Repositorio de Github,
Disponible en: https://github.com/ffi/ffi [2016, Agosto 30]
[20.] ThoughtBot, PaperClip Ruby Gem paperclip, [en línea], Repositorio de Github,
Disponible en: https://github.com/thoughtbot/paperclip/wiki [2016, Agosto 30]
[21.] Rails-Api, Active Model Serializers active-model-serializers,[en línea], Repositorio de
Github, https://github.com/rails-api/active_model_serializers[2016, Agosto 30]
[22.] Merriam Webster Dictionary. EEUU: Merrian-Webster
[23.] Oracle. MySQL 5.1 Reference Manual. Retrieved 17 September 2012.[en línea]
Disponible en http://dev.mysql.com/doc/refman/5.7/en/what-is-mysql.html [2016, Agosto 25]
[24.] Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter,
Larry; Leach, Paul J.; Berners-Lee, Tim (1999). Hypertext Transfer Protocol -- HTTP/1.1.
IETF. RFC 261[en línea] Disponible en: https://tools.ietf.org/html/rfc2616 [2016, Agosto 24]
[25.] Richardson L. y Ruby S. (2007). RESTful Web Services.REF OREILY API. EEUU:
O´Reilly
89
[26.] Bahit E. 2011. Scrum y eXtreme Programming. Buenos Aires.
[27.] Groussard T. (2012), Java 7: Fundamentos del Lenguaje Java. Barcelona España:
Ediciones ENI.
[28.] Barile, Margherita. Cartesian Plane. From MathWorld--A Wolfram Web Resource,[en
línea]. Disponible en: http://mathworld.wolfram.com/CartesianPlane.html [2016 Julio 30]
[29.] Weisstein, Eric W. Distance. From MathWorld--A Wolfram Web Resource.[en línea]
Disponible en: http://mathworld.wolfram.com/Distance.html [2016 Julio 30]
[30.] Vasquez, S. (2010). Inteligencia Artificial.. Disponible en:
https://solvasquez.wordpress.com/2010/08/15/inteligencia-artificial [ 2016, Septiembre 15]
[31.] Universidad Rey Juan Carlos. Reconocimiento de Patrones. España: Universidad Rey
Juan Carlos
[32.] Stergiou C., Siganos D. Neural Networks.
[33.] Lisa Barrehag, Viktor Mårdström (2012). Accelerating Success: A study of seed
Accelerators and their Defining characteristics. Tesis de Grado, University of Technology,
Gothenburg, Suecia. Disponible en: http://acceleratorstudy.com/Accelerating-Success.pdf
[2015, Octubre 10]
[34.] Wells, D. (2013). Extreme Programming: A gentle introduction [En Linea]. Disponible
en http://www.extremeprogramming.org
[35.] Weisstein, Eric W. "Derivative." From MathWorld--A Wolfram Web Resource.[en
[36.] L. Richardson & S. Ruby, RESTFul Web Services
90

Metodología de Implementación de Sistemas Médicos en Software: Sistema de Análisis de Electrocardiogramas

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Metodología de Implementación de Sistemas Médicos en Software: Sistema de Análisis de Electrocardiogramas

Caricato da

Copyright:

Formati disponibili

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA INFORMÁTICA

SISTEMA PARA REALIZAR EL DIAGNÓSTICO DE PATOLOGÍAS

TRABAJO ESPECIAL DE GRADO

REALIZADO POR VILLEGAS SAN MIGUEL, Samuel G.

PROFESOR GUÍA MAGURNO CORRO, Carlo

FECHA OCTUBRE de 2016

A mi Padre y a mi Madre, por su apoyo incondicional.

Al Dr. Baltasar Saturno, por el apoyo en la investigación realizada en este trabajo.

Al Dr. Juan Carlos Belandría, por su apoyo en la realización de los diagnósticos de

para continuar con esta investigación.

A todos aquellos que me ayudaron en mi formación académica.

Figura 1- Segmentos de un electrocardiograma [Fuente: 4.] ..................................................... 20

Ecuación 1- Teorema de Pitágoras [Fuente: 29.] ……………………………...……….……………28

Figura 2 - Metodología Implementada [Fuente Propia] ............................................................... 33

Tabla 1-Diseño de respuesta por Patología [Fuente propia]……………………….....……..……67

El presente trabajo especial de Grado está orientado a diseñar e implementar un sistema

informático que apoye a los profesionales de la salud, automatizando el proceso para

diagnosticar electrocardiogramas impresos. El sistema permite al usuario tomar una foto a la

señal impresa, interpretar la señal y diagnosticar la presencia de las siguientes patologías:

hipertrofia ventricular, fibrilación auricular y fibrilación ventricular.

Para satisfacer los requerimientos del sistema, se diseñaron e implementaron dos

algoritmos capaces de interpretar y diagnosticar imágenes de electrocardiogramas,

apoyados por la librería OpenCV para la interpretación de imágenes. Dichos algoritmos se

implementaron en una librería compartida, permitiendo ejecutar las funciones y métodos de

la librería sin necesidad de compilar el código.

Se desarrolló una aplicación móvil que permite al usuario gestionar la información

relacionada a los pacientes, diagnósticos y electrocardiogramas.

implementados utilizando un patrón de arquitectura REST, a través de la aplicación móvil se

consumen dichos servicios, permitiendo la comunicación entre la aplicación móvil y la

contiene la implementación de los algoritmos que realizan los diagnósticos.

construida utilizando el lenguaje C++, la aplicación de servidor y la herramienta de reportes

utilizando el lenguaje Java para Android.

La cardiología es la rama de la medicina que se encarga de estudiar, diagnosticar y tratar,

Los avances en la medicina se pueden alcanzar integrando tecnologías de otras ciencias,

La visión de las computadoras, es la herramienta que permite realizar procesamiento e

PLANTEAMIENTO DEL PROBLEMA

Según la Organización mundial de la salud la causa principal de muerte en el mundo son

las enfermedades cardiovasculares (ECV), un estimado de 17.5 millones de personas

tomar decisiones correctas a la hora de salvar la vida del paciente.

La herramienta más utilizada para diagnosticar las patologías cardiovasculares es el

electrocardiograma que consiste en la representación gráfica de las señales eléctricas del

corazón, se obtiene utilizando un electrocardiógrafo y su interpretación tiene la capacidad de

diagnosticar infartos, arritmias, fibrilaciones, braquicardias, entre otras patologías

encuentran en la necesidad de administrar medicamentos a los pacientes sin tener certeza

tiempo que el que dispone la vida del paciente.

Si bien es cierto que el examen de electrocardiograma se realiza en pocos minutos y los

resultados del electrocardiógrafo se imprimen casi inmediatamente, la interpretación y

diagnóstico exacto del electrocardiograma, depende de la experiencia de la persona que lo

El electrocardiograma está compuesto de varias ondas generadas por las señales

contracción y relajación de los músculos del corazón.

El segmento o la onda P es la representación de la actividad eléctrica detectada en la

superficie del cuerpo cuando ocurre la despolarización miocardial auricular, el segmento Q-

R-S representa la actividad eléctrica en el cuerpo cuando ocurre la despolarización ventricular

miocardial, y por último, la onda o segmento T es la representación eléctrica cuando ocurre

la repolarización miocardial ventricular.

indica un estado normal del corazón.” [1]

El electrocardiograma utilizado hoy en día es un electrocardiograma de doce derivaciones,

nos presentarán los segmentos y las ondas P, Q, R, S y T, utilizando estas derivaciones en

el ritmo cardíaco del paciente y diagnosticar las patologías cardiovasculares. [1]

Para identificar cambios en el ritmo del corazón y diagnosticar arritmias es necesario

varía notablemente puede existir una arritmia.

Al momento de identificar un infarto en el corazón se analiza el comportamiento de la onda