Universidad Central “Marta Abreu” de las Villas.
Facultad Matemática, Física y Computación
Licenciatura en Ciencia de la Computación
Análisis y diseño de un sistema informático de soporte al diagnóstico clínico
Propuesta para Trabajo de Diploma de
Licenciatura en Ciencia de la Computación
Curso 2012-2013
Autor:
Frey Eduardo Alvarez González
Tutores:
MSc. Mario Pupo Meriño
MSc. Lianny O’Farrill Fernández
I Dictamen
I
Dictamen
Hago Constar
Hago constar que el presente trabajo fue realizado en la Universidad Central Marta Abreu de Las
Villas como parte de la culminación de los estudios de la especialidad de Ciencia de la
Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que
estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en
eventos ni publicado sin la autorización de la Universidad.
______________________________________________
Firma del autor
Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la
dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de
esta envergadura referido a la temática señalada.
___________________ _______________________
Firma del tutor Firma del jefe del
Laboratorio.
II Dedicatoria
II
Dedicatoria
A mis padres Frey y Grisel, a ellos les debo todo lo que soy.
A mi abuela Roselia, que la llevo en mi corazón aunque no esté con nosotros.
A Luis Manuel, mi amigo, que la vida le negó esta oportunidad, este trabajo es para él también.
III Agradecimientos
III
Agradecimientos
A mis padres que lo han dado todo por mí, que han hecho realidad mi sueño, han sido la luz de
mi vida en los momentos más oscuros y cada día hacen de mí una mejor persona.
A mi tutor Mario Pupo, por su ayuda infinita e incondicional, por estar ahí en todo momento.
A mi tutora Lianny, por ayudarme y asesorarme cada vez que la necesité.
A mi novia Arlettis, por su paciencia y comprensión en todos estos años.
A mis suegros Julio y Marieta, que me trataron como un hijo desde el primer día.
A mi abuela Lupe, por su cariño y preocupación por mi bienestar.
A mi hermano Lester, por escucharme y aconsejarme siempre que me hizo falta.
A toda mi familia, por apoyarme siempre, por no dejar de creer en mí.
A todos mis amigos y compañeros de la UCLV, que gracias a ellos nunca me sentí solo.
A todas esas personas que siempre esperaron lo mejor de mí.
IV Pensamiento
IV
Pensamiento
La imaginación es más importante que el conocimiento.
El conocimiento es limitado. La imaginación circunda al mundo.
Albert Einstein.
V Resumen
V
Resumen
En la presente investigación se realiza un estudio del proceso de diagnóstico clínico con el
objetivo de diseñar un Sistema de Soporte al Diagnóstico Clínico sustentado en Web Service,
que permita introducir los resultados obtenidos en la UCLV con Clasificadores Bayesianos de
utilidad en el dominio Biomédico; dentro del flujo de trabajo del Sistema de Salud Pública
Cubana. La metodología de desarrollo de software seleccionada fue RUP, y como parte de la
captación de los requisitos se utilizaron técnicas de la Ingeniería del Conocimiento. Tanto los
requisitos previos levantados como el diseño, fueron validados desde el punto de vista
informático y médico.
VI Abstract
VI
Abstract
In this investigation a study of the clinical diagnostic process was carried out, with the aim of
designing a Clinical Decision Support System based in Web Service, which will enable the
introduction of the Bayesian classifiers developed in the UCLV with usefulness in the
biomedical domain, within workflow of Cuban Public Health System. As software development
methodology was selected RUP, and as part of the requirements capture process, Knowledge
Engineering’s techniques were used. Both prerequisites raised as design, were validated from the
IT perspective and from a medical standpoint.
VII TABLA DE CONTENIDOS
VII
TABLA DE CONTENIDOS
DICTAMEN .......................................................................................................................................................... I
DEDICATORIA .................................................................................................................................................. II
AGRADECIMIENTOS ..................................................................................................................................... III
PENSAMIENTO ................................................................................................................................................ IV
RESUMEN ........................................................................................................................................................... V
ABSTRACT ........................................................................................................................................................ VI
TABLA DE CONTENIDOS ............................................................................................................................ VII
LISTA DE FIGURAS ......................................................................................................................................... IX
LISTA DE TABLAS ............................................................................................................................................ X
INTRODUCCIÓN ................................................................................................................................................ 1
CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA ....................................................................................... 8
1.1. SISTEMAS INFORMÁTICOS DE SOPORTE A LA DECISIÓN CLÍNICA .................................................................... 9
1.1.1. Diagnóstico clínico .............................................................................................................................. 9
1.1.2. Generalidades de los SSDC ............................................................................................................... 12
1.2. MODELOS DE REDES BAYESIANAS PARA PROBLEMAS BIOMÉDICOS DESARROLLADOS EN LA UCLV ........... 15
1.2.1. Técnicas de Clasificación .................................................................................................................. 15
1.2.2. Clasificadores bayesianos................................................................................................................. 17
1.2.3. Potencialidad de uso de las herramientas desarrolladas en la UCLV para su uso en SSDC ........... 19
1.3. METODOLOGÍAS DE DESARROLLO DE SOFTWARE ....................................................................................... 21
1.3.1. Rational Unified Process (RUP) ....................................................................................................... 22
1.3.2. Extreme Programing (XP) ................................................................................................................. 25
1.4. INGENIERÍA DEL CONOCIMIENTO ................................................................................................................. 28
1.4.1. Modos de adquisición del conocimiento ........................................................................................... 29
1.4.2. Métodos de adquisición del conocimiento ......................................................................................... 29
1.4.3. Automatización de la adquisición del conocimiento ......................................................................... 31
CONCLUSIONES PARCIALES ...................................................................................................................... 32
CAPÍTULO 2. MODELACIÓN DEL DOMINIO ...................................................................................... 33
2.1. SELECCIÓN DE LA METODOLOGÍA DE DESARROLLO .................................................................................... 34
2.2. ARQUITECTURA DEL SISTEMA ..................................................................................................................... 36
2.3. REQUISITOS DEL SISTEMA ........................................................................................................................... 38
VIII TABLA DE CONTENIDOS
VIII
2.3.1. Captación inicial de requisitos .......................................................................................................... 39
2.3.2. Requisitos funcionales ....................................................................................................................... 40
2.3.3. Requisitos no funcionales .................................................................................................................. 44
2.4. DOMINIO DEL PROBLEMA ............................................................................................................................ 45
2.4.1. Modelo de dominio ............................................................................................................................ 46
2.4.2. Actores del sistema ............................................................................................................................ 48
2.4.3. Diagrama de casos de uso ................................................................................................................. 48
2.4.4. Nombre y descripción de los casos de uso del sistema. ..................................................................... 49
2.5. VALIDACIÓN DE LOS REQUISITOS FUNCIONALES A TRAVÉS DE LOS CASOS DE USO ...................................... 55
CONCLUSIONES PARCIALES ...................................................................................................................... 56
CAPÍTULO 3. DISEÑO DE LA APLICACIÓN ......................................................................................... 58
3.1. DIAGRAMAS DE ACTIVIDADES..................................................................................................................... 58
3.1.1. Actividad de Diagnosticar Paciente .................................................................................................. 58
3.1.2. Actividad de Generar Estructura en la Base de Casos ..................................................................... 60
3.1.3. Actividad Poblar Base de Casos ....................................................................................................... 61
3.2. DIAGRAMAS DE CLASES DEL DISEÑO ........................................................................................................... 63
3.3. DIAGRAMAS DE SECUENCIAS ...................................................................................................................... 64
3.4. DIAGRAMA DE COMPONENTES .................................................................................................................... 66
3.5. DIAGRAMA DE DESPLIEGUE ........................................................................................................................ 67
3.6. DIAGRAMA ENTIDAD-RELACIÓN O MODELO CONCEPTUAL ......................................................................... 68
3.7. VALIDACIÓN DEL DISEÑO ............................................................................................................................ 69
CONCLUSIONES PARCIALES ...................................................................................................................... 70
CONCLUSIONES .............................................................................................................................................. 71
RECOMENDACIONES .................................................................................................................................... 72
REFERENCIAS BIBLIOGRÁFICAS .............................................................................................................. 73
ANEXO I PRIMERA ENCUESTA PARA LA CAPTACIÓN DE CONOCIMIENTOS EN EL
DIAGNÓSTICO CLÍNICO ............................................................................................................................... 75
ANEXO II SEGUNDA ENCUESTA. REALIZADA PARA VALIDAR LOS REQUERIMIENTOS
FUNCIONALES. ................................................................................................................................................ 77
ANEXO III DIAGRAMAS DE CLASES DEL DISEÑO. .......................................................................... 80
ANEXO IV DIAGRAMAS DE SECUENCIA. ........................................................................................... 82
ANEXO V ENCUESTA PARA LA VALIDACIÓN DEL DISEÑO ....................................................... 85
IX LISTA DE FIGURAS
IX
LISTA DE FIGURAS
FIGURA 1.1 FASES E ITERACIONES DE LA METODOLOGÍA RUP ................................................................................................... 25
FIGURA 1.2 METODOLOGÍA EXTREME PROGRAMING .............................................................................................................. 26
FIGURA 2.1 FASES DE LA METODOLOGÍA RUP (QUISPE CARITA ET AL., 2011). ......................................................................... 35
FIGURA 2.2 ARQUITECTURA DEL SISTEMA. ............................................................................................................................. 38
FIGURA 2.3 MODELO DE DOMINIO. ..................................................................................................................................... 46
FIGURA 2.4 DIAGRAMA DE CASOS DE USO DEL SISTEMA. .......................................................................................................... 50
FIGURA 2.5 RESULTADOS DE LA VALIDACIÓN DE LOS REQUERIMIENTOS A PARTIR DE LOS CASOS DE USO PARA EL ACTOR MÉDICO. SE
GRAFICAN LOS NIVELES DE RESPUESTA POR PREGUNTA. ................................................................................................... 56
FIGURA 3.1 DIAGRAMA DE LA ACTIVIDAD «DIAGNOSTICAR PACIENTE» ........................................................................................ 59
FIGURA 3.2 DIAGRAMA DE LA ACTIVIDAD «GENERAR ESTRUCTURA» ........................................................................................... 61
FIGURA 3.3 DIAGRAMA DE LA ACTIVIDAD «POBLAR BASE DE CASOS» .......................................................................................... 62
FIGURA 3.4 DIAGRAMA DE CLASES DEL DISEÑO CORRESPONDIENTE AL CASO DE USO «OBTENER POSIBLES ENFERMEDADES» .................. 63
FIGURA 3.5 DIAGRAMA DE CLASES DEL DISEÑO CORRESPONDIENTE AL CASO DE USO «GENERAR ESTRUCTURA» ................................... 64
FIGURA 3.6 DIAGRAMA DE CLASES DEL DISEÑO CORRESPONDIENTE AL CASO DE USO «GENERAR MODELOS» ....................................... 64
FIGURA 3.7 DIAGRAMA DE SECUENCIA CORRESPONDIENTE AL CASO DE USO «OBTENER POSIBLES ENFERMEDADES» ............................. 65
FIGURA 3.8 DIAGRAMA DE SECUENCIA CORRESPONDIENTE AL CASO DE USO «GENERAR ESTRUCTURA» .............................................. 66
FIGURA 3.9 DIAGRAMA DE SECUENCIA CORRESPONDIENTE AL CASO DE USO «GENERAR MODELOS» .................................................. 66
FIGURA 3.10 DIAGRAMA DE COMPONENTES. ......................................................................................................................... 67
FIGURA 3.11 DIAGRAMA DE DESPLIEGUE DEL SISTEMA. ............................................................................................................ 68
FIGURA 3.12 DIAGRAMA ENTIDAD-RELACIÓN PARA LAS BASES DE CASOS. .................................................................................... 68
FIGURA 3.13 VALIDACIÓN DEL DISEÑO. SE MUESTRAN LOS RESULTADOS POR PREGUNTA. ............................................................... 70
X LISTA DE TABLAS
X
LISTA DE TABLAS
TABLA 1.1 DIFERENCIAS ENTRE METODOLOGÍAS ÁGILES Y TRADICIONALES .................................................................................... 23
TABLA 2.1 DEFINICIONES DEL DOMINIO. ............................................................................................................................... 47
TABLA 2.2 DEFINICIÓN DE LOS ACTORES. ............................................................................................................................... 48
TABLA 2.3 DESCRIPCIÓN DEL CASO DE USO: VERIFICAR DIAGNÓSTICO. ........................................................................................ 51
TABLA 2.4 DESCRIPCIÓN DEL CASO DE USO: OBTENER POSIBLES ENFERMEDADES. ......................................................................... 51
TABLA 2.5 DESCRIPCIÓN DEL CASO DE USO: OBTENER DIAGNÓSTICO. ......................................................................................... 52
TABLA 2.6 DESCRIPCIÓN DEL CASO DE USO: SUGERIR ACTUALIZACIÓN DE LA BASE DE CASOS. .......................................................... 52
TABLA 2.7 DESCRIPCIÓN DEL CASO DE USO: GENERAR ESTRUCTURA. .......................................................................................... 53
TABLA 2.8 DESCRIPCIÓN DEL CASO DE USO: POBLAR BASE DE CASOS. ......................................................................................... 53
TABLA 2.9 DESCRIPCIÓN DEL CASO DE USO: GENERAR ARCHIVO .ARFF. ....................................................................................... 54
TABLA 2.10 DESCRIPCIÓN DEL CASO DE USO: GENERAR MODELOS. ............................................................................................ 54
1
1
INTRODUCCIÓN
2 INTRODUCCIÓN
2
INTRODUCCIÓN
La praxis médica indica que las decisiones clínicas pueden tomarse mediante razonamiento
deductivo a partir del conocimiento de la fisiopatología humana. Sin embargo, sucede que, con
mayor frecuencia, las decisiones médicas se toman sobre la base de datos inciertos, o mediante
procesos no enteramente conscientes, carentes de sistematicidad y frecuentemente acríticos con
la información a emplear, en los cuales la estimación de probabilidades se realiza de manera no
formal.
La toma de decisiones es un proceso complejo que requiere el manejo de mucha información. La
tasa de errores en la toma de decisiones clínicas es lo suficientemente elevada como para ser
objeto de preocupación. Algunas investigaciones han puesto de manifiesto que un alto porcentaje
de las decisiones médicas no tienen un fundamento científico sólido y solo el 20 % de la práctica
médica está avalada por una buena efectividad (Kohn et al., 1999).
En los momentos actuales, se requiere la implantación de metodologías que ayuden a la toma de
decisiones clínicas, sobre todo en los entornos donde la carga de trabajo es muy grande, como los
grandes hospitales públicos y el área rural donde los médicos, muchos de ellos sin experiencia,
se ven inmersos en las primeras decisiones clínicas gravitantes.
Por otro lado, el campo de la Ingeniería del Conocimiento (IC) se ha volcado en tratar de
comprender y simular en el ordenador algunas tareas cognitivas, entre ellas, la diagnosis médica.
La conclusión de todos los estudios realizados es que la IC puede proporcionar herramientas para
analizar las estructuras conceptuales y de razonamiento del conocimiento usado en la diagnosis
médica. Sin embargo, las diferencias existentes, en cuanto a la terminología, el conocimiento
subyacente y las formas de razonamiento, entre la IC y la medicina hace que, en la práctica, la
interacción entre ambos dominios sea compleja y que la primera tenga que seguir avanzando en
la búsqueda de herramientas que se adapten mejor al entorno clínico. Los llamados sistemas de
ayuda al diagnóstico, también conocidos como Sistemas de Soporte a la Decisión Clínica
(SSDC), surgieron con este fin.
3 INTRODUCCIÓN
3
Además del caudal de información proveniente de la práctica médica en hospitales y otros
centros asistenciales, las investigaciones en el campo de la salud proveen una gran cantidad de
datos. Dentro de este grupo de investigaciones surgen con mucha frecuencia estudios en los
cuales se quiere conocer el efecto de un conjunto de variables discretas sobre una variable que
identifica la pertenencia a un grupo y que es supuestamente dependiente de ellas, teniendo por
objetivo establecer una clasificación a determinada entidad definida por dichas variables. Por
ejemplo, suele presentarse el caso en que a partir del conocimiento de los datos de un paciente,
es necesario predecir su condición, estableciendo una clasificación, que puede ser enfermo o
sano, siendo esta variable (condición del paciente) supuestamente dependiente de un grupo de
características (variables discretas predictoras) que pueden representar los riesgos o síntomas.
Este tipo de estudios se caracteriza por la existencia de fuentes masivas de datos, cuyo análisis
completo resulta insostenible desde el punto de vista humano, y donde el porcentaje de
redundancia y de datos ruidosos o sujetos a errores es muy elevado, lo cual ha obligado al uso de
técnicas de análisis automatizadas que aprovechan las capacidades de cómputo del ordenador
para obtener patrones o modelos a partir de los datos recopilados.
Dentro de las técnicas automatizadas de clasificación, se encuentran los Clasificadores
Bayesianos. Estos permiten generar un modelo probabilístico que describe el dominio de estudio
a partir de una fuente de datos de entrenamiento, teniendo en cuenta la incertidumbre presente en
los mismos, y brindando la posibilidad de ser aplicados en la predicción de las probabilidades del
número de miembros de clase, como la probabilidad de que una muestra dada pertenezca a una
clase particular.
En el Grupo de Bioinformática de la Universidad Central “Marta Abreu” de Las Villas (UCLV),
se definieron y validaron tres nuevos algoritmos de aprendizaje estructural de Redes Bayesianas:
ByNet, BayesChaid, BayesPSO (Chávez, 2008), demostrándose su efectividad en dominios
bioinformáticos y médicos.
Si bien lo anterior es cierto, las herramientas computacionales derivadas no son usables de
manera intuitiva por especialistas en Medicina: carecen de una interfaz amigable, los procesos se
encuentran dispersos, se requiere especialización en Clasificadores Bayesianos para su uso, no se
vinculan con sistemas de bases de datos y se requiere entrar los datos en un formato de Weka.
4 INTRODUCCIÓN
4
Como parte de la colaboración entre el Grupo de Bioinformática de la UCLV y el Departamento
de Bioinformática de la Universidad de las Ciencias Informáticas(Molina, 2011), se desarrolló
una herramienta en la cual se integran las funcionalidades de generación de modelos, evaluación
y comparación de los mismos, así como su uso en un determinado dominio de aplicación. No
obstante, esta herramienta es una aplicación de escritorio, la cual todavía requiere especialización
en Clasificadores Bayesianos para su uso, no se vincula con sistemas de bases de datos y
requiere la entrada de datos en formato de Weka.
Estas herramientas, o bien son el resultado de investigaciones realizadas en el marco de
ejercicios académicos o de obtención de grados científicos, o han sido diseñados e
implementados por una sola persona, o son el resultado de un proceso de desarrollo progresivo
no asociado a una metodología definida de desarrollo de software.
En general, todavía no se ha logrado desarrollar una herramienta que pueda ser utilizada como un
SSDC. Hasta el momento las existentes, como resultado de las investigaciones mencionadas,
permiten el uso de la información proveniente de las pesquisas en el campo de la medicina para
la obtención de nuevo conocimiento, e incluso, a partir de la información de un nuevo paciente,
proponer un diagnóstico. Sin embargo, su inserción en el flujo de trabajo del Sistema de Salud
Pública todavía requiere de un proceso de desarrollo que involucre Ingeniería del Conocimiento
para determinar la forma en que estos métodos de clasificación puedan tributar en la práctica al
diagnóstico clínico. Estos factores, en gran medida, han determinado la no generalización de los
resultados obtenidos y han impedido su introducción práctica.
Ha de tenerse en cuenta, además, el hecho de la inexistencia, como parte de la práctica médica
cubana, de una cultura de uso de SSDC, lo cual dificulta cualquier proceso de desarrollo de
software orientado en ese sentido, pues no existe un cliente en su concepción tradicional, sino un
posible cliente cuyas necesidades deben ser capturadas, y al que habrá de convencer
posteriormente, de la utilidad práctica de las herramientas. Esto implica que no se conocen a
priori los requisitos funcionales específicos que debe tener la aplicación.
Por lo tanto, se hace necesaria la concepción de un SSDC que permita la utilización de estos
resultados a gran escala y su inserción en el Sistema de Salud Pública Cubano. Este sistema no
sería el resultado de la acción de una persona, sino de un equipo de trabajo y, partiendo de la
5 INTRODUCCIÓN
5
necesidad de captar los requisitos a partir de un posible cliente no convencido de sus
necesidades; se impone un proceso previo de modelado del mismo, que sirva como punto de
partida para el trabajo que realizará el equipo de desarrollo.
A partir de lo anterior, se propone el siguiente Problema de investigación:
¿Cómo realizar el diseño de un SSDC que utilice los algoritmos de clasificación bayesiana
desarrollados en la UCLV para su posible inserción en el Sistema de Salud Cubano, partiendo de
la no existencia de un cliente convencido de sus necesidades?
Objeto de estudio:
Análisis y diseño de SSDC.
Campo de acción
Análisis y diseño de SSDC basados en Redes Bayesianas.
Objetivo general:
Diseñar un Sistema Informático sustentado en Web Service, que permita el uso de Clasificadores
Bayesianos como herramienta apoyo al diagnóstico clínico y se ajuste a los requerimientos del
flujo organizacional del Sistema de Salud Pública Cubano.
Objetivos específicos:
Proponer una metodología de desarrollo de software apropiada para las fases posteriores
de desarrollo del SSDC.
Captación, mediante la Ingeniería del Conocimiento, de los procesos asociados al
diagnóstico clínico en el flujo de trabajo del Sistema de Salud.
Elaboración de los requisitos funcionales que debe tener el SSDC.
Modelar el SSDC.
Validación de resultados, desde el punto de vista informático y médico.
6 INTRODUCCIÓN
6
Métodos de la investigación científica utilizados
En el transcurso de esta investigación, se utilizaron varios métodos teóricos y empíricos.
Métodos teóricos:
El método analítico-sintético se aplicó en:
- Estudio de la bibliografía relacionada e interpretación de los conceptos teóricos y prácticos
afines a los clasificadores bayesianos.
-Descomposición del problema de investigación en el estudio independiente y generación de
requisitos funcionales referidos a los procesos de generación, evaluación y uso de los
clasificadores bayesianos, permitiendo a través de la síntesis, establecer las relaciones esenciales
que vinculan a estos procesos.
-Análisis, interpretación y reutilización de las clases y componentes brindados por la librería
Weka, y de las implementadas como parte de las investigaciones anteriores, para sintetizarlos en
la solución general del problema planteado.
- Arribar a conclusiones de acuerdo a la investigación.
La inducción y deducción posibilitaron, en primer lugar, a partir del estudio de varios software
existentes para el trabajo con Clasificadores Bayesianos, generalizar los aspectos más relevantes
que determinan su valor de uso. Además, a partir de los parámetros ya sistematizados y
publicados que deben ser cumplidos por los softwares que trabajen con Redes Bayesianas,
además de los SSDC, se pudieron decidir las prestaciones a incluir en este nuevo sistema.
La modelación, con el auxilio de los restantes métodos, permitió proponer una representación de
las posibles modificaciones que se producirían en los procesos de generación, evaluación y uso
de Clasificadores Bayesianos por parte de los usuarios, al hacerlo desde la aplicación propuesta.
Todos estos procesos fueron acompañados por el enfoque de sistema, teniéndose presentes en
cada momento la concatenación y nexos entre los componentes estructurales de la aplicación.
7 INTRODUCCIÓN
7
Métodos empíricos:
Se usó la entrevista a especialistas en Medicina Interna y desarrolladores de software en una
primera fase. Posteriormente, se usó la encuesta a especialistas en Medicina Interna para validar
desde el punto de vista médico los requisitos funcionales del sistema, y a desarrolladores de
software para la validación del diseño propuesto.
Novedad y aporte práctico:
El diseño de un SSDC que emplea los algoritmos de Clasificación Bayesiana desarrollados en la
UCLV, el cual puede ser utilizado en fases posteriores del desarrollo de la aplicación,
estableciendo un punto de partida para la generalización e introducción práctica de los resultados
investigativos del Grupo de Bioinformática de la UCLV.
El documento está estructurado en tres capítulos.
El Capítulo 1. Fundamentación teórica, brinda los conceptos fundamentales que se requiere
conocer para la presente investigación. Se define el diagnóstico clínico como proceso. Se definen
y describen los SSDC. El Capítulo incluye además, información sobre la clasificación bayesiana,
las metodologías de desarrollo de software y la ingeniería del conocimiento.
En el Capítulo 2. Modelación del dominio, se justifica la selección de la metodología de
desarrollo, se expone la línea base de la arquitectura establecida, se justifica la captación de los
requisitos funcionales y no funcionales de la aplicación. Además, se explica el modelado del
dominio y la definición de los actores y casos de uso del sistema.
Por su parte, en el Capítulo 3. Diseño de la aplicación, se describen los principales procesos de
la fase de la elaboración, mediante la realización de la documentación pertinente. Además, se
muestra el resultado de la validación del diseño.
8
8
1. FUNDAMENTACIÓN TEÓRICA
9 FUNDAMENTACIÓN TEÓRICA
9
CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
En este capítulo se desarrollan los principales conceptos relacionados con la investigación y con
el estado del arte en el campo de acción establecido. Aquí se define el diagnóstico clínico como
proceso. Se definen y describen los SSDC. El Capítulo incluye además, información sobre la
clasificación bayesiana, las metodologías de desarrollo de software y la ingeniería del
conocimiento.
1.1. Sistemas informáticos de soporte a la decisión clínica
Los sistemas de soporte a la decisión clínica (SSDC), también llamados Clinical Decision
Support Systems (CDSS), según (Bonis et al., 2004) pueden definirse como cualquier sistema o
programa informático diseñado para ayudar a los profesionales sanitarios a tomar decisiones
clínicas, ya sean preventivas, diagnósticas o terapéuticas. Por su parte, en (Wyatt 1991) estos se
definen como “sistemas de conocimiento activos que utilizan dos o más elementos de los datos
del paciente para generar asesoramiento específico para cada caso”.
Para ofrecer una mejor visión sobre la funcionalidad de estos sistemas y su alcance, es preciso
definir primeramente, y aportar elementos, sobre lo que se conoce como diagnóstico clínico.
1.1.1. Diagnóstico clínico
El diagnóstico, según (Sacket, 1994) es un “proceso que define pacientes y clasifica su
enfermedad, que identifica su probable destino o pronóstico y que nos induce a tratamientos
específicos con la confianza de que serán más beneficiosos que perjudiciales”. Se entiende por
diagnóstico al “conjunto de signos que sirven para fijar el carácter peculiar de una enfermedad y
también es la calificación que da el médico a la misma, según los signos que advierte”, de
acuerdo al Diccionario de la lengua española (Real Academia Española, 2001).
Existen varios tipos de diagnóstico médico: diagnóstico de la enfermedad sintomática,
diagnóstico temprano o de la enfermedad asintomática, diagnóstico de la gravedad, de la
evolución y diagnóstico del probable pronóstico (Mézquita, 2006).
En el proceso de diagnóstico, se distinguen los llamados “elementos del padecer”, esto es
(Sacket, 1994, Mézquita, 2006):
10 FUNDAMENTACIÓN TEÓRICA
10
Enfermedad o alteración blanco: modelo teórico o enfermedad abstracta que existe ante
todo en los libros de texto. Son los trastornos anatómicos, bioquímicos, fisiológicos o
psicológicos, cuyo origen, mecanismos de inadaptación, manifestación, pronóstico y
seguimiento se lee en los libros de texto.
Síndrome o padecimiento: es lo que en realidad tiene el paciente. Es el conjunto de
síntomas percibidos por el paciente y de signos percibidos por el médico.
Situación: circunstancia social, psicológica y económica en la que se halla el paciente
respecto de su medio.
En el proceso de diagnóstico se distinguen varias etapas (a modo de generalización, por
supuesto, pues cada especialista sigue sus propios procedimientos). Entre ellas se encuentran1
(Mézquita, 2006):
Conocimiento inicial del caso, con la investigación del síntoma o síntomas principales
mediante la historia clínica: anamnesis (o interrogatorio al paciente) y examen físico (el
médico observa los signos).
Solicitud o no de pruebas complementarias.
Generación de hipótesis inespecíficas:
o se depuran y se generan hipótesis cada vez más específicas (agrupa los signos y
descarta los inválidos).
Integración de datos clínicos y de resultados de pruebas:
o se hace una representación interna del caso (se forma un modelo sindromático)
Se evalúan probabilidades diagnósticas (interpretación con el código clínico).
Aplicación de pruebas para sustentar hipótesis.
Modelo de padecimiento del enfermo.
Decisión clínica.
De esta forma, partiendo de la información inicial obtenida del interrogatorio al paciente y de su
examen físico, el clínico (médico) agrupa los signos y síntomas en forma de síndrome, y se
plantea varias hipótesis clínicas entre las cuales debe decidir para establecer un diagnóstico.
Kassirer y Kopelman (Kassirer, 1991) consideran tres formas de razonamiento para la
elaboración de las hipótesis diagnósticas:
1 Se reproducen solo los pasos de interés para la presente investigación.
11 FUNDAMENTACIÓN TEÓRICA
11
Probabilístico: Basado en la frecuencia de la enfermedad en una población dada, una
determinada edad, sexo o raza, o en la frecuencia de asociación de determinados signos y
síntomas con dicha afección.
Causal: Deriva su poder diagnóstico de la capacidad de explicar el cuadro clínico del
paciente, utiliza relaciones de causa a efecto entre datos clínicos o de otro tipo. Tiene un
gran poder explicativo y se basa en conocimientos generados por las ciencias básicas de
la medicina. Aquí se escoge el diagnóstico después del análisis de su posibilidad de
producir las manifestaciones del paciente.
Determinístico: En él se aplican reglas predeterminadas en el proceso del diagnóstico,
que es realizado analizando los elementos en conjunto como una regla: “En presencia de
tales síntomas y signos, piensen en tal diagnóstico”.
Partiendo de estos modos de razonamiento, se derivan también las estrategias diagnósticas
(secuencia de actividades que se realizan con el propósito de identificar qué ocurre en un
determinado paciente). Según (Mézquita, 2006), se pueden resumir como:
a) por analogía: (método Gestalt o de la tía Minnie) se basa en el reconocimiento de un
patrón conocido. Es la comprensión inmediata de que la presentación del paciente
corresponde a una descripción (o patrón) previamente aprendida de la enfermedad. El
reconocimiento puede ser visual (imagen), auditivo (ruidos cardiacos o respiratorios),
olfativo (hedor urémico) o táctil (enfisema subcutáneo).
b) exhaustiva: consiste en la investigación concienzuda e invariable (sin prestarles atención
inmediata) de todos los hechos médicos del paciente, seguida por la selección de los
datos útiles para el diagnóstico. Tiene dos etapas: recopilación de datos y etapa
diagnóstica.
c) secuencial o algorítmica: En la estrategia algorítmica, de arborización o ramificaciones,
el proceso diagnóstico evoluciona a lo largo de una de varias ramas posibles, de manera
que la respuesta a cada pregunta determina la conducta que debe seguirse, hasta llegar al
diagnóstico correcto. Es de utilidad cuando necesita delegarse el diagnóstico al personal
paramédico, en la resolución de problemas raros y con fines de selección.
12 FUNDAMENTACIÓN TEÓRICA
12
d) hipotético-deductiva: consiste en la formulación, a partir de los primeros datos acerca
del paciente, de una lista breve de diagnósticos posibles o acciones potenciales, seguida
de la realización de las conductas clínicas (historia y examen físico) y paraclínicas que
reducirán la longitud de la lista.
e) Bayesiana: es la utilización de las herramientas estadísticas para concluir un diagnóstico.
Se basa en el teorema de Bayes (López and García, 2008) e incluye el uso de la
prevalencia, frecuencia de los síntomas, cálculos de la especificidad y de la sensibilidad y
otras herramientas estadísticas.
f) por exclusión: consiste en aceptar como posible un determinado diagnóstico, mediante
la eliminación, razonablemente probada, de las hipótesis diagnósticas restantes. Se utiliza
cuando es difícil probar de manera directa una hipótesis, según las características del
paciente o de otras situaciones más que de la enfermedad en sí.
g) ex-adjuvantibus (tratamiento de prueba): consiste en establecer el diagnóstico con
base en la observación de la eficacia de un tratamiento (tratamiento de prueba o prueba
terapéutica) o, bien, se dice que se confirmó el diagnóstico al observar la evolución
clínica del padecimiento (período de vigilancia).
Como se ha mencionado y se puede ver a partir de esta descripción, la toma de decisiones en el
diagnóstico clínico es un proceso complejo que requiere el manejo de mucha información. En la
introducción se mencionaba que, a pesar de su reconocida importancia, a menudo las decisiones
clínicas, que debieran basarse en el razonamiento deductivo a partir del conocimiento de la
fisiopatología humana, no son tomadas de una forma consciente y algunas investigaciones han
puesto de manifiesto que un alto porcentaje de las decisiones médicas no tienen un fundamento
científico sólido (Kohn et al., 1999). Es en este marco que los SSDC pudieran cobrar importancia
dentro del proceso de toma de decisiones en el diagnóstico clínico.
1.1.2. Generalidades de los SSDC
La toma de decisiones para el cuidado de los pacientes, es el acto médico que tiene mayor
responsabilidad en la práctica asistencial. De una correcta toma de decisiones depende la
seguridad del paciente, tema que se ha convertido en una verdadera prioridad para la salud
mundial (Soler, 2012).
13 FUNDAMENTACIÓN TEÓRICA
13
Una pretendida solución a este problema fue la aplicación de la inteligencia artificial. Dentro de
esta tendencia fueron creados los "sistemas expertos", con la intención de reproducir el
razonamiento humano de forma simbólica. Estos sistemas, creados ante la necesidad de aliviar al
médico en este proceso, finalmente fracasaron a pesar de su complejidad, ya que hasta el
presente sus resultados no son comparables con el pensamiento inteligente verdaderamente
auténtico (Bonis et al., 2004). Actualmente, los SSDC son menos ambiciosos, pero más
efectivos.
Los SSDC suelen estar diseñados para integrar una base de conocimiento médico, los datos del
paciente y un motor de inferencia. La forma de representar el conocimiento y de trabajar el
motor de inferencia, determinan en gran medida la clasificación de los SSDC.
De acuerdo a (Bonis et al., 2004), los SSDC pueden caracterizarse de acuerdo con múltiples
dimensiones, tales como: a) el objetivo que persigue el sistema, b) la forma en que se ofrece la
ayuda, o c) el mecanismo de toma de decisión subyacente.
Según su objetivo, los SSDC pueden clasificarse en dos grupos: los que ayudan en decisiones
diagnósticas (¿qué tiene el paciente?) y los que ofrecen soporte a decisiones sobre actividades
preventivas, diagnósticas (solicitud de pruebas) o terapéuticas que responden a la pregunta «¿qué
hacer con el paciente?». En el segundo grupo se debe valorar el coste/beneficio (ídem).
Según la forma en que los sistemas ofrecen su ayuda, pueden clasificarse en pasivos o activos.
En los sistemas pasivos el médico debe reconocer en algún momento que el SSDC le puede ser
útil y consultarlo. Los SSDC más avanzados toman un papel proactivo. Sin necesidad de ser
requeridos, detectan determinadas condiciones en un paciente y alertan al clínico.
Según el método de razonamiento subyacente, en general los SSDC se pueden clasificar en los
siguientes grupos:
SSDC basados en algoritmos o en lógica categórica: Consisten en trasladar a un
programa informático un algoritmo de decisión categórico previamente diseñado por
clínicos. Muchos de los SSDC que han demostrado su eficacia en entornos clínicos reales
se basan en este modelo. En general son adecuados cuando se trata de abordar un
problema muy concreto y donde la toma de decisiones es esencialmente categórica. El
14 FUNDAMENTACIÓN TEÓRICA
14
sistema puede hacerse tan complejo como se desee, dependiendo del grado de detalle con
el que se desarrolle (en (Bonis et al., 2004) se incluye además, una discusión sobre el
carácter simplista de estos sistemas y la utilidad real de automatizar esta clase de
conocimientos).
SSDC basados en modelos bayesianos simples: al igual que en las estrategias diagnósticas
basadas en razonamiento Bayesiano, estos sistemas se basan en la formulación básica del
teorema de Bayes (ver epígrafe 1.2.2.1.1)
SSDC basados en redes bayesianas y árboles de decisión: Para superar algunas de las
limitaciones de los modelos bayesianos simples, en los años ochenta se trabajó en
modelos que combinaban la teoría de probabilidades junto con la teoría de grafos. En el
epígrafe 1.2.2.1.1se realiza una descripción más detallada de estos métodos.
SSDC basados en redes neuronales: Las redes neuronales son sistemas de cálculo
basados en arquitecturas modulares, organizadas en redes de numerosos procesadores
elementales interconectados, que evalúan localmente una función no lineal. Las redes
neuronales disponen de algoritmos de aprendizaje que modifican el valor de sus
parámetros (pesos) con el fin de ajustarse lo mejor posible a un conjunto de casos
(training set). Las redes neuronales deben siempre probarse sobre un conjunto de casos
distinto del anterior (test set). Resultan apropiadas para la resolución de problemas en los
que subyacen interacciones entre los factores que permanecen ocultas al observador y que
son difíciles de modelizar. Las redes neuronales actúan como cajas negras, es decir,
ningún observador externo puede comprender intrínsecamente cómo una red neuronal
llega a una conclusión determinada. Esto ha limitado enormemente la aceptación por
parte de los clínicos del uso de redes neuronales en los SSDC.
SSDC basados en conocimiento o representación simbólica: Estos sistemas no trabajan
exclusivamente con valores cuantitativos, como en el caso de los sistemas probabilísticos,
sino que codifican simbólicamente los conocimientos de expertos mediante reglas.
En el sitio web de Open Clinical (Open Clinical, 2013), se puede encontrar una revisión muy
exhaustiva del la evolución del los SSDC desde su surgimiento hasta la fecha, enfatizando en el
tipo de solución propuesto en cada sistema.
15 FUNDAMENTACIÓN TEÓRICA
15
Una parte fundamental en el desarrollo e implantación de SSCD es su evaluación. Aún no existe
una metodología de evaluación universalmente aceptada y el tema es objeto de investigación y
debate académico (ver (Heathfield, 1998), citado en (Bonis et al., 2004)).
Existen múltiples aspectos de los SSCD que pueden ser objeto de evaluación. La metodología
ideal debería abarcar aspectos tales como: la verificación de los algoritmos y del correspondiente
código informático (analiza la consistencia interna del SSDC), la validación de los resultados
generados por el sistema (análisis del funcionamiento del sistema centrándose en la calidad de
los resultados que genera), la usabilidad y aceptación por parte de los usuarios. Otros aspectos a
considerar son el impacto clínico, social y económico, y el análisis de las consecuencias ético-
legales del uso de los SSDC.
Es importante tener en cuenta, además de la verificación y la validación, la usabilidad, pues
según (Eccles et al., 2002) frecuentemente el fracaso de los SSDC reside en problemas de
usabilidad.
1.2. Modelos de redes bayesianas para problemas biomédicos
desarrollados en la UCLV
En el marco de las investigaciones vigentes en Cuba, se llevan a cabo estudios para potenciar las
técnicas de Clasificación, especialmente la Clasificación Bayesiana. Este es el caso específico
del Grupo de Bioinformática de la Universidad Central “Marta Abreu” de Las Villas (UCLV),
donde se definieron y validaron tres nuevos algoritmos de aprendizaje estructural: ByNet,
BayesChaid, BayesPSO (Chávez, 2008), demostrándose la efectividad de los modelos obtenidos
mediante su uso, en dominios Bioinformáticos y médicos.
A continuación se abordan brevemente los conceptos asociados a estos modelos, para
posteriormente describir su uso potencial en el desarrollo de SSDC.
1.2.1. Técnicas de Clasificación
La clasificación de datos es una operación estadística que permite el agrupamiento de las
unidades de observación en clases (categorías, intervalos numéricos, modalidades). Se basa en
la comprensión del dominio de aplicación y el establecimiento de patrones expresados en las
relaciones existentes entre los atributos que definen las entidades, permitiendo sintetizar
16 FUNDAMENTACIÓN TEÓRICA
16
características comunes para definir, por ejemplo, funcionalidad y aplicación de las entidades
que pertenecen a una misma clase.
Esta técnica ha sido aplicada en todas las ramas de la ciencia para la comprensión de las
diferentes entidades que la componen y su planteamiento empírico, aproximadamente data del
año 350 a.C. donde se registra que Aristóteles realiza la primera clasificación de plantas y
animales. Actualmente, su valor práctico se evidencia en un amplio rango de aplicaciones, entre
las que se encuentran: diagnóstico médico y psicológico, aplicaciones en economía, supervisión
y diagnóstico de fallas en sistemas automáticos complejos, entre otros (Molina, 2011).
El problema de clasificación se basa en agrupar y discriminar objetos, descritos mediante un
conjunto de atributos, ya sea construyendo las clases o asignando los objetos a clases
previamente definidas. Para el mismo, se establece que las clases deben ser mutuamente
excluyentes, o sea, una unidad de observación no puede ser clasificada simultáneamente en dos
clases, con la misma escala, y a su vez, el conjunto de clases debe ser exhaustivo, no pudiendo
ninguna unidad de observación quedarse sin tener una clase donde pueda ser clasificada.
Comúnmente este tipo de estudios se aplica en análisis multivariado, donde surgen con mucha
frecuencia exploraciones en las cuales se quiere conocer el efecto de un conjunto de variables
discretas denominadas variables independientes o predictoras, sobre una variable que identifica
la pertenencia a un grupo y que es supuestamente dependiente de ellas, denominada, variable
clase o dependiente, con el objetivo de obtener una clasificación. A pesar de que esta variable
dependiente o clase, sea el blanco del estudio, las inferencias pueden ser no solo sobre la misma,
sino sobre cualquiera de las variables independientes cuya información se desconozca a partir de
evidencias de otras variables.
Las técnicas de clasificación se utilizan comúnmente en situaciones donde están presentes:
1. Una población de datos que se dividen en dos o más clases de acuerdo con una taxonomía
determinada.
2. Un grupo de datos de los cuales se conoce a priori la clase a la que pertenecen.
3. Un conjunto de datos de los cuales se desea saber a qué clase pertenecen.
17 FUNDAMENTACIÓN TEÓRICA
17
El desarrollo tecnológico de los últimos años ha potenciado a las investigaciones científicas con
mecanismos automatizados de recolección y almacenamiento de datos, permitiendo que este
aspecto pase a un segundo plano.
Hoy el problema consiste en cómo obtener información a partir de estas fuentes masivas de datos
caracterizadas por un alto porcentaje de redundancia y de datos ruidosos o sujetos a errores,
insostenibles de analizar desde el punto de vista humano.
Esto ha generado un avance en el diseño de técnicas de análisis automatizadas que aprovechan
las capacidades de cómputo del ordenador con el fin de obtener patrones o modelos a partir de
los datos recopilados. Es así como surgen las principales técnicas de clasificación dentro de los
algoritmos de aprendizaje automático que permiten generar clasificadores para su uso posterior.
La generación de un clasificador consiste en construir criterios para determinar el valor del
atributo clase en un ejemplo cualquiera del dominio a partir de un conjunto de ejemplos,
denominado conjunto de entrenamiento, de un cierto dominio D, aplicando un algoritmo de
aprendizaje. Esos criterios están basados en los valores de uno o varios de los pares (atributo;
valor) que intervienen en la definición de los ejemplos. El uso de un modelo clasificador estará
determinado por su capacidad para predecir o inferir la clase a la que pertenece una nueva
entidad correspondiente al dominio de estudio (Molina, 2011).
Entre las principales técnicas automatizadas de clasificación se encuentran los clasificadores
bayesianos.
1.2.2. Clasificadores bayesianos
Los clasificadores bayesianos (Duda and Hart, 1973) son clasificadores estadísticos, que pueden
predecir tanto las probabilidades del número de miembros de clase, como la probabilidad de que
una muestra dada pertenezca a una clase particular. Este tipo de clasificador utiliza como modelo
matemático una Red Bayesiana conjuntamente con el Teorema de Bayes.
1.2.2.1.1 Redes bayesianas
Las RB (también conocidas como redes causales probabilísticas, redes causales, sistemas
expertos bayesianos, redes de creencia, sistemas expertos probabilísticas o diagramas de
influencia) son una representación gráfica de dependencias para razonamiento probabilístico,
18 FUNDAMENTACIÓN TEÓRICA
18
combinando la potencia del Teorema de Bayes con la expresividad semántica de los grafos
dirigidos, permitiendo expresar un modelo causal de las independencias/dependencias entre las
variables que forman parte del dominio de aplicación (Pearl, 1988). De forma resumida se puede
decir que una RB es un conjunto de variables, una estructura gráfica conectando estas variables y
un conjunto de distribuciones de probabilidad condicional. Codifica incertidumbre asociada a
cada variable por medio de probabilidades y, gracias al Teorema de Bayes(RF), esta
incertidumbre es susceptible de ser modificada sobre la base de observaciones (o evidencias) en
el modelo. Estas constituyen una representación del conocimiento que tiene en cuenta las
relaciones entre las variables y hacen una selección de las más importantes por su propia
caracterización, a la vez que permiten hacer inferencias sobre las mismas y en particular pueden
ser usadas para tareas de clasificación (Chávez, 2008).
Formalmente se define un modelo de Red Bayesiana, como un par (G, P), donde G es un grafo
acíclico dirigido (GDA), y P una distribución de probabilidad conjunta (DPC). P= {p(X1|τ1),
p(X2|τ2), …, p(Xn|τn)} es un conjunto de n distribuciones de probabilidad condicionales, una por
cada variable Xi (nodos del grafo), y τi es el conjunto de padres del nodo Xi en G.
La definición de una RB está determinada por dos tareas. La primera, denominada aprendizaje
estructural, consiste en obtener la estructura de grafo a partir de las relaciones de dependencia
condicional entre las variables. La segunda tarea, caracterizada por calcular la distribución de
probabilidades (parámetros) que permitirá hacer inferencias, se denomina, aprendizaje
paramétrico.
Existen distintos enfoques para obtener la estructura de la red bayesiana, ya sea porque la red se
conoce de antemano o porque se infiere de los datos de entrenamiento, y por otro lado, si todas
las variables que intervienen en la red son observables o si bien hay algunas que no lo son
(Beltrán and Roche, 2002). Las técnicas de aprendizaje estructural son diversas y dependen del
tipo de estructura de red (Chávez, 2008).
Una vez conocida la estructura del grafo, se pasa a la tarea de obtener las probabilidades
(parámetros) correspondientes a cada nodo de la red bayesiana, las probabilidades a priori de los
nodos raíz y las probabilidades condicionales de las demás variables, dados sus padres.
19 FUNDAMENTACIÓN TEÓRICA
19
Cuando se tienen datos completos y suficientes para todas las variables en el modelo, es
relativamente fácil obtener los parámetros, asumiendo que la estructura está dada. El método más
común es el llamado estimador de máxima verosimilitud (Molina, 2011).
Por otro lado, la inferencia se refiere a la obtención de conclusiones basadas en premisas o
evidencias, permitiendo realizar predicciones en base a las nuevas probabilidades.
La propagación de evidencias en la red, se realiza si se tienen en cuenta un conjunto de variables
evidenciales E ⊆ D con valor evidencial E = e (e representa uno de los posibles valores de la
variable de evidencia) y el conjunto de variables no evidenciales D | E para las cuales se
calculan las probabilidades condicionales P(Xi | e) (Chávez, 2008).
Son diversas las ventajas referidas a las RB como modelo matemático para la representación de
diferentes dominios de estudio. Entre ellas, se puede mencionar que las RB proveen una
representación gráfica de las relaciones explícitas de dependencia del dominio, de manera que
permiten descubrir la estructura causal subyacente en un conjunto de datos a partir de una base
de datos que contenga un conjunto de observaciones sobre un conjunto de variables, realizando
el modelado de sistemas complejos y visualizando las relaciones causales por medio del grafo
(Silva and Muñoz, 2000).
1.2.3. Potencialidad de uso de las herramientas desarrolladas en la UCLV para su
uso en SSDC
Independientemente de las ventajas del uso de un clasificador bayesiano partiendo de las
ventajas presentes en una RB, no es evidente el alivio en la solución de los problemas médicos y
bioinformáticos si la estructura de la red exige el cálculo de un gran número de probabilidades
condicionales o parámetros, como es usual.
Partiendo del análisis anterior y las bondades que presentan las RB, los tres nuevos algoritmos
desarrollados en la UCLV se centran en el aprendizaje estructural desde los datos, y su principal
objetivo es simplificar la estructura de la red, tomando como apoyo otros modelos gráficos
probabilísticos o de optimización, así como teniendo en cuenta características concretas del
dominio de aplicación, para aliviar el cálculo de probabilidades, facilitar inferencias y reducir
20 FUNDAMENTACIÓN TEÓRICA
20
complejidad computacional, siendo particularmente aplicables en estudios bioinformáticos y
biomédicos y con eficiencia similar o superior a los algoritmos ya existentes (Chávez, 2008).
Dos de estos algoritmos obtienen la estructura de dependencias basándose en la detección de
interacciones al estilo del algoritmo CHAID (Chi-square Automatic Interaction Detector). El
tercero de estos algoritmos se basa en un método de optimización bioinspirado, concretamente la
optimización basada en enjambres de partículas (Particle Swarm Optimization, PSO) para
contribuir a la reducción de atributos.
Todos estos algoritmos fueron programados e incorporados a la plataforma Weka (Witten and
Frank, 2005). Posteriormente, como parte de la colaboración entre el Grupo de Bioinformática de
la UCLV y el Departamento de Bioinformática de la Universidad de las Ciencias Informáticas,
se desarrolló una herramienta en la cual se integran las siguientes funcionalidades (Molina,
2011):
o Generación de clasificadores bayesianos a partir de una base de datos de
entrenamiento, incluyendo nuevos algoritmos de aprendizaje estructural (ByNet,
BayesCHAID, BayesPSO) optimizados para dominios bioinformáticos y médicos.
o Evaluación y comparación de clasificadores bayesianos a partir de la selección de
los métodos y métricas, además de la prueba no paramétrica de Friedman para la
comparación de modelos, que permita tener una visión integral y simple para el
especialista (gráficos, ordenar de mayor a menor, etcétera).
o Uso del modelo generado, evaluado y seleccionado como óptimo para el dominio
de investigación, permitiendo la clasificación de nuevos casos y la inclusión de
los mismos en el conjunto de estudio.
Esta capacidad desarrollada para la generación de modelos basados en redes bayesianas para el
dominio biomédico, hace pensar en la potencialidad de su uso en el desarrollo de un SSDC. La
experiencia acumulada en el Sistema de Salud Pública Cubano en la atención primaria de salud,
no solamente en nuestro país sino en varios países del área, respaldan la factibilidad de su
realización. A esto se suma un número importante de pesquisas a pequeña y gran escala
realizadas por el MINSAP o por varios de los centros hospitalarios de nuestro país para
21 FUNDAMENTACIÓN TEÓRICA
21
investigar las enfermedades de aparición más frecuentes en el territorio nacional y otros, bajo la
observación de médicos cubanos, los cuales aportan un amplio caudal de información, una parte
de esta almacenada en bases de datos.
Para que el desarrollo de un SSDC sea posible en nuestro contexto, se hace imprescindible un
estudio que permita capturar el funcionamiento del proceso de diagnóstico clínico dentro del
flujo de trabajo del Sistema de Salud Pública Cubano, así como la selección adecuada de una
metodología de desarrollo de software que se ajuste a las condiciones reales en las cuales éste se
realizaría.
1.3. Metodologías de Desarrollo de Software
Las Metodologías de Desarrollo de Software surgen ante la necesidad de utilizar una serie de
procedimientos, técnicas, herramientas y soporte documental a la hora de desarrollar un producto
(software).
En general, una metodología está compuesta por:
Cómo dividir un proyecto en etapas.
Qué tareas se llevan a cabo en cada etapa.
Qué restricciones deben aplicarse.
Qué técnicas y herramientas se emplean.
Cómo se controla y gestiona un proyecto.
Esto se puede resumir en:
Un enfoque del proceso de desarrollo de software.
Herramientas, modelos y métodos para asistir al proceso de desarrollo de software.
A lo largo del tiempo una gran cantidad de métodos han sido desarrollados, cada uno con su
propio enfoque, diferenciándose por su fortaleza y debilidad. Por una parte, tenemos aquellas
propuestas más tradicionales que se centran especialmente en el control del proceso,
estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y
22 FUNDAMENTACIÓN TEÓRICA
22
las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y
necesarias en un gran número de proyectos, pero también han presentado problemas en muchos
otros.
Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y
más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final
sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del
equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones,
como por ejemplo el factor humano o el producto software. Esta es la filosofía de las
metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al
desarrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su
efectividad en proyectos con requisitos muy cambiantes, cuando se exige reducir drásticamente
los tiempos de desarrollo, pero manteniendo una alta calidad (Canós et al., 2003).
En la Tabla 1.1 se muestran las diferencias generales que se presentan entre las llamadas
metodologías tradicionales y las metodologías ágiles.
Para brindar una idea concreta de lo ofrecido en esta comparación, se mencionan las
características de dos metodologías: RUP y XP, una correspondiente a las metodologías
tradicionales, y la otra, a una metodología ágil.
1.3.1. Rational Unified Process (RUP)
La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide en
cuatro fases el desarrollo del software:
Inicio: El objetivo en esta etapa es determinar la visión del proyecto.
Elaboración: En esta etapa el objetivo es determinar la arquitectura óptima.
Construcción: En esta etapa el objetivo es llevar a obtener la capacidad operacional
inicial.
Transmisión: El objetivo es llegar a obtener la liberación (release) del proyecto.
23 FUNDAMENTACIÓN TEÓRICA
23
Tabla 1.1 Diferencias entre metodologías ágiles y tradicionales
Metodologías Tradicionales Metodologías Ágiles
Basadas en normas provenientes de
estándares seguidos por el entorno de
desarrollo.
Basadas en heurísticas provenientes de
prácticas de producción de código.
Cierta resistencia a los cambios. Especialmente preparados para cambios
durante el proyecto.
Impuestas externamente. Impuestas internamente (por el equipo).
Proceso mucho más controlado, con
numerosas políticas/normas.
Proceso menos controlado, con pocos
principios.
El cliente interactúa con el equipo de
desarrollo mediante reuniones.
El cliente es parte del equipo de desarrollo
Más artefactos. Pocos artefactos.
Más roles. Pocos roles.
Grupos grandes y posiblemente
distribuidos.
Grupos pequeños (<10 integrantes) y
trabajando en el mismo sitio.
La arquitectura del software es esencial y se
expresa mediante modelos.
Menos énfasis en la arquitectura del
software.
Existe un contrato prefijado. No existe contrato tradicional o al menos es
bastante flexible.
Cada una de estas etapas se desarrolla mediante el ciclo de iteraciones, el cual consiste en
reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteración se
establecen en función de la evaluación de las iteraciones precedentes.
24 FUNDAMENTACIÓN TEÓRICA
24
Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos
disciplinas:
Disciplina de Desarrollo
Ingeniería de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.
Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.
Implementación: Creando software que se ajuste a la arquitectura y que tenga el
comportamiento deseado.
Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo lo
solicitado está presente.
Disciplina de Soporte
Configuración y administración del cambio: Guardando todas las versiones del proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Distribución: Hacer todo lo necesario para la salida del proyecto.
25 FUNDAMENTACIÓN TEÓRICA
25
Figura 1.1 Fases e Iteraciones de la Metodología RUP
Es recomendable que a cada una de estas iteraciones se les clasifique y ordene según su
prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio
la retroalimentación que se tendría en cada entregable o en cada iteración.
Los elementos del RUP son:
Actividades: Son los procesos que se llegan a determinar en cada iteración.
Trabajadores: Son las personas o entes involucrados en cada proceso.
Artefactos: Un artefacto puede ser un documento, un modelo, o un elemento de modelo.
Una particularidad de esta metodología es que, en cada ciclo de iteración, se exige el uso de
artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un
grado de certificación en el desarrollo del software.
1.3.2. Extreme Programing (XP)
Es una de las metodologías de desarrollo de software más exitosas en la actualidad, utilizada para
proyectos de corto plazo. La metodología consiste en una programación rápida o extrema, cuya
26 FUNDAMENTACIÓN TEÓRICA
26
particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para
llegar al éxito del proyecto.
Figura 1.2 Metodología Extreme Programing
Características de XP, la metodología se basa en:
Pruebas Unitarias: Se basa en las pruebas realizadas a los principales procesos, de tal
manera que adelantándonos en algo hacia el futuro, podamos hacer pruebas de las fallas que
pudieran ocurrir. Es como si nos adelantáramos a obtener los posibles errores.
Refabricación: Se basa en la reutilización de código, para lo cual se crean patrones o
modelos estándares, siendo más flexible al cambio.
Programación en pares: Una particularidad de esta metodología es que propone la
programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto en
una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo
en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el
mapa.
¿Qué es lo que propone XP?
Empieza en pequeño y añade funcionalidad con retroalimentación continua.
El manejo del cambio se convierte en parte sustantiva del proceso.
27 FUNDAMENTACIÓN TEÓRICA
27
El costo del cambio no depende de la fase o etapa.
No introduce funcionalidades antes que sean necesarias.
El cliente o el usuario se convierte en miembro del equipo.
Derechos del Cliente
Decidir que se implementa.
Saber el estado real y el progreso del proyecto.
Añadir, cambiar o quitar requerimientos en cualquier momento.
Obtener lo máximo de cada semana de trabajo.
Obtener un sistema funcionando cada 3 o 4 meses.
Derechos del Desarrollador
Decidir cómo se implementan los procesos.
Crear el sistema con la mejor calidad posible.
Pedir al cliente, en cualquier momento, aclaraciones de los requerimientos.
Estimar el esfuerzo para implementar el sistema.
Cambiar los requerimientos en base a nuevos descubrimientos.
Lo fundamental en este tipo de metodología es:
La comunicación, entre los usuarios y los desarrolladores.
La simplicidad, al desarrollar y codificar los módulos del sistema.
La retroalimentación, concreta y frecuente del equipo de desarrollo, el cliente y los
usuarios finales.
A modo de conclusión, vale mencionar que no existe una metodología universal para enfrentar
con éxito cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al
contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.).
Históricamente, las metodologías tradicionales han intentado abordar la mayor cantidad de
situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas,
sobre todo en proyectos pequeños y con requisitos muy cambiantes.
28 FUNDAMENTACIÓN TEÓRICA
28
La metodología RUP es más adaptable para proyectos de largo plazo. La metodología XP en
cambio, se recomienda para proyectos de corto plazo. La metodología MSF se adapta a
proyectos de cualquier dimensión y de cualquier tecnología.
Lo más importante antes de elegir la metodología a usar para la implementación de un software,
es determinar el alcance que tendrá y luego decidir cuál es la que más se acomoda a la
aplicación.
Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos
que tienen estas características. Una de las cualidades más destacables en una metodología ágil
es su sencillez, tanto en su aprendizaje como en su aplicación, reduciéndose así los costos de
implantación en un equipo de desarrollo. Esto ha llevado hacia un interés creciente en las
metodologías ágiles. Sin embargo, hay que tener presente una serie de inconvenientes y
restricciones para su aplicación, tales como: están dirigidas a equipos pequeños o medianos ( el
tamaño de los equipos se limita de 3 a 20 como máximo, otros dicen no más de 10 participantes),
el entorno físico debe ser un ambiente que permita la comunicación y colaboración entre todos
los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de
desarrollo hacia las prácticas y principios puede llevar el proceso al fracaso (el clima de trabajo,
la colaboración y la relación contractual son claves), el uso de tecnologías que no tengan un ciclo
rápido de realimentación o que no soporten fácilmente el cambio, etc. (Canós et al., 2003).
1.4. Ingeniería del conocimiento
Uno de los cuellos de botella más importantes en el proceso de construcción de un SSDC es el de
la adquisición de conocimiento. En forma más sencilla, esta cuestión consiste en el problema de
hacer que el experto diga lo que sabe y un problema complementario es darle forma
automáticamente manipulable. Dentro de los métodos de adquisición de conocimiento se pueden
citar los métodos basados en interacción humana, tales como: tareas familiares, entrevistas,
tareas de proceso restringido y tareas de información limitada y los basados en técnicas de
aprendizaje automático. Aparejado al problema de adquisición de conocimiento se encuentra el
de la validación y chequeo del conocimiento adquirido. El chequeo del conocimiento puede
hacerse mediante la validación de los rangos de respuestas que debe dar al sistema experto que
está siendo desarrollado y la verificación se logra haciendo interactuar el experto de campo con
29 FUNDAMENTACIÓN TEÓRICA
29
el prototipo del sistema experto para registrar sus impresiones y haciendo las modificaciones
pertinentes. Se puede definir la verificación como un proceso incremental de mejoramiento que
se detiene cuando se obtiene un comportamiento aceptable del sistema experto.
1.4.1. Modos de adquisición del conocimiento
El experto interactúa con el Ingeniero del Conocimiento para construir la Base de Conocimiento.
Experto Ingeniero del Conocimiento Base de Conocimiento
El experto puede interactuar más directamente con el SE, a través de un programa editor
inteligente, capacitado con diálogos sofisticados y un conocimiento acerca de la estructura de la
Base de Conocimiento (Nápoles Ruiz, 2011).
Experto Programa Editor Inteligente Base de Conocimiento
Las Bases de Conocimiento pueden ser construidas parcialmente por un programa de inducción a
partir de casos descritos en libros y experiencias pasadas.
Libros Programa de Inducción Base de Conocimiento
Un método de adquisición del conocimiento más avanzado es el aprendizaje directo desde libros.
Libros Procesamiento de Datos Base de Conocimiento
1.4.2. Métodos de adquisición del conocimiento
Los pasos iniciales en la adquisición de conocimiento, involucran identificar, estructurar y
recolectar conocimiento. Existe la concepción (a nuestro entender errada) que la adquisición de
conocimiento es simplemente un problema de entrevistas informales entre el ingeniero del
conocimiento y el experto del dominio. Sin embargo, en el interés de la eficiencia de la
adquisición de conocimientos, deben ser desarrollados métodos explícitos con propósitos
específicos.
Mientras los métodos de adquisición de conocimientos deben ser adaptables a las demandas, los
conocimientos deben ser adaptables a las demandas únicas de un proyecto de sistema experto
dado, los siguientes objetivos parecen ser universalmente aplicables.
30 FUNDAMENTACIÓN TEÓRICA
30
(1) El ingeniero del conocimiento debe ser capaz de estructurar inicialmente y definir la base de
conocimiento usando solamente interacción mínima con el experto del dominio.
(2) La estructura organizacional aplicada a la base de conocimientos debe reflejar el
acercamiento al dominio natural del experto al problema.
(3) El conocimiento reunido por el ingeniero del conocimiento debe ser exacto y completo tanto
como sea posible. Aunque la base de conocimiento siempre necesitará ser revisada y actualizada,
el sistema será únicamente tan bueno como el conocimiento que incorpore.
(4) Las interacciones del experto en el dominio / ingeniero del conocimiento deberán ser
dirigidas y organizadas para producir la máxima información en menor tiempo de interacción.
1.4.2.1. Técnicas de adquisición de conocimiento generales
A continuación se detallan cuáles son las técnicas más generalizadas para la adquisición de
conocimiento.
1.4.2.1.1 Entrevistas
La entrevista es el método más familiar de adquisición del conocimiento. De una manera muy
simple se genera rápidamente una gran cantidad de conocimiento sobre la terminología y los
principales componentes del dominio.
Esto juega un importante papel en los primeros estadios del proceso de adquisición del
conocimiento, en orden a conseguir algunos conceptos básicos y establecer una información
como marco para lo que vendrá posteriormente. Las entrevistas pueden estructurarse en varios
grados y de distintas maneras. Una de las más sencillas es pedir al experto que prepare una
exposición de una hora de duración acerca de los principales temas e ideas concernientes al
dominio. Posteriormente, una interacción sistemática puede proporcionar información sobre
aspectos relevantes con mayor profundidad. Entre las técnicas más utilizadas para realizar
entrevistas se pueden destacar las listas generalizadas, los incidentes críticos, y los
procedimientos para memorias autobiográficas.
Las entrevistas tienen serias limitaciones. Estas aparecen cuando son utilizadas para refinar las
versiones preliminares del SE, en un intento de extraer la experiencia esencial que diferencia al
experto humano de un programa con un rendimiento inferior.
31 FUNDAMENTACIÓN TEÓRICA
31
Un aspecto de este problema es intentar representar en forma de reglas, un conocimiento que no
es tratable con esas técnicas. Esto no es un mero problema de representación del conocimiento,
sino que tiene implicaciones en la adquisición del mismo.
Aunque el experto posee claramente el conocimiento, éste puede no ser directamente
comunicable en una entrevista y debe ser inferido utilizando otras técnicas. Las entrevistas
pueden clasificarse en: desestructuradas, semi-estructuradas y estructuradas. Las
desestructuradas realizan preguntas genéricas con la esperanza de obtener la mayor cantidad de
información posible. Las semi-estructuradas consisten en una entrevista con una serie de
preguntas abiertas y puntos que necesitan ser cubiertos. Las estructuradas consisten en una
agenda muy formal que comprende preguntas específicas relacionadas con las características del
sistema. La Entrevista Tutorial consiste en que el experto le dé una lectura sobre la información
relevante como respuesta a una sesión de pregunta-respuesta. Esto le otorga al experto una gran
libertad de expresión y le permite ser el conductor. Sin embargo, la entrevista corre el riesgo de
consumir mucho tiempo y ser irrelevante en varios aspectos.
1.4.3. Automatización de la adquisición del conocimiento
Existen requerimientos generales para la automatización de la adquisición de conocimientos que
deben ser considerados antes de intentar dicha automatización, tales como (Nápoles Ruiz, 2011):
Independencia del dominio.
Uso directo de los expertos sin intermediarios.
Múltiple acceso a fuentes de conocimientos tales como: texto, entrevistas con expertos y
observaciones de los expertos.
Apoyo a diversidad de perspectivas incluyendo la de otros expertos.
Apoyo a diversidad de tipos de conocimientos y relaciones entre los conocimientos.
Apoyo a la presentación de conocimientos de diversas fuentes con claridad, en lo que se
refiere a su derivación, consecuencias y relaciones estructurales.
32 Conclusiones Parciales
32
Apoyo a que los usuarios apliquen los conocimientos a una variedad de dominio y que
experimenten con sus aplicaciones.
Apoyo a estudios de validación.
Los métodos automatizados para la adquisición del conocimiento pueden incluir:
Analogía, aprendizaje (simulando un aprendiz), aprendizaje basado en casos, inducción y
análisis de árboles de decisión, descubrimiento, aprendizaje basado en explicaciones,
redes neuronales, e inducción y modificación de reglas.
Herramientas y ayuda para la modelación y adquisición de conocimientos que han tenido
éxito. Estas parecen depender de representaciones intermediarias que constituyen
lenguajes de modelación de problemas, que ayudan a llenar el vacío entre el experto y
las implementaciones de programas de computación.
Conclusiones Parciales
A partir de lo encontrado en la bibliografía, se puede concluir que la toma de decisiones en el
diagnóstico clínico, al ser un proceso complejo que requiere el manejo de mucha información,
puede ser favorecida por el empleo de los SSDC. Estos últimos se han desarrollado desde varios
enfoques, entre ellos destacan los que se basan en el empleo de las Redes Bayesianas. Los
modelos de clasificación basados en RB que se desarrollaron en la UCLV, presentan
características que potenciarían su uso, con un diseño apropiado, en un SSDC. Para el desarrollo
correcto de un sistema como este, además de la utilización de una metodología de desarrollo de
software adecuado, se necesitan métodos eficientes para la captación del conocimiento en el
dominio del diagnóstico clínico.
33
33
2. MODELACIÓN DEL DOMINIO
34 MODELACIÓN DEL DOMINIO
34
CAPÍTULO 2. MODELACIÓN DEL DOMINIO
En el presente capítulo se justifica la selección de la metodología de desarrollo, se expone la
línea base de la arquitectura establecida, se justifica la captación de los requisitos funcionales y
no funcionales de la aplicación y se explica el modelado del dominio y la definición de los
actores y casos de uso del sistema.
2.1. Selección de la metodología de desarrollo
Para la selección de la metodología de desarrollo a utilizar para el diseño del SSDC se tuvieron
en cuenta tres aspectos fundamentales:
La dimensión del sistema: todo sistema pensado para el apoyo al diagnóstico clínico debe
ser capaz de gestionar un volumen grande de información (en su base de conocimientos se
almacenan cientos de enfermedades, y miles de variables). A esto se suman las
funcionalidades que de entrada (aún cuando no se haya realizado el diseño se conocen grosso
modo) se deben considerar, como son la gestión de la base de conocimientos, la gestión de la
información del paciente, el funcionamiento del motor de inferencia, etc.
La intención de que el sistema sea insertado en el flujo de trabajo del Sistema de Salud
Pública Cubana: esto obliga a la selección de una metodología iterativa, que responda a una
retroalimentación permanente donde los requisitos cambien a partir de los requisitos iniciales
con regularidad, en la medida que los usuarios finales comprendan la utilidad del sistema y
sistematicen su uso.
No se tiene un levantamiento previo de requisitos del sistema: el desarrollo del sistema no
parte de una necesidad preconcebida por parte del usuario final (o cliente), sino de la
necesidad de darle uso a una herramienta previamente diseñada. Es necesario detenerse en la
captación de requisitos y en el diseño inicial para garantizar que el producto primario
resultante capte la atención del cliente.
Después de analizar las cuestiones expresadas anteriormente se decidió usar para el diseño y
posterior desarrollo del sistema la metodología de desarrollo Rational Unified Process (RUP).
Esta selección se basa en las facilidades que brinda RUP y teniendo en cuenta que la misma
cumple con las fases necesarias para llevar a cabo un modelado satisfactorio del SSDC.
35 MODELACIÓN DEL DOMINIO
35
El ciclo de vida del software en RUP se descompone en cuatro fases secuenciales, dentro de las
cuales se realizan varias iteraciones en número variable, en cada extremo de una fase se realiza
una evaluación para determinar si los objetivos de la fase se han cumplido. Una evaluación
satisfactoria permite que el proyecto se mueva a la próxima fase.
Figura 2.1 Fases de la metodología RUP (QUISPE CARITA et al., 2011).
A continuación se definen las tareas que se pretenden llevar a cabo para la realización de las
fases de inicio y elaboración respectivamente.
Fase de inicio.
En esta fase se pretende llevar a cabo un análisis del dominio del sistema, la definición de los
actores que interactúan con el mismo y la descripción de los casos de uso del sistema. El objetivo
en esta etapa es determinar la visión del proyecto.
Fase de elaboración.
En la fase de elaboración se definirán los casos de uso del sistema y la descripción de los
mismos. Además planificar las actividades necesarias y los recursos requeridos, especificando
las características y el diseño de la arquitectura. En esta etapa el objetivo es determinar la
arquitectura Óptima.
En el cuerpo de este trabajo se llevaron a cabo las fases de inicio y elaboración (en su parte más
temprana) debido a la dimensión del sistema así como la complejidad del mismo (lo que impide
que se lleve a cabo por un único desarrollador). Se decidió dejar para posteriores trabajos una
36 MODELACIÓN DEL DOMINIO
36
posible implementación en la etapa de elaboración, más las etapas de construcción y transición
para la primera iteración.
2.2. Arquitectura del sistema
En el diseño de sistemas informáticos modernos se suelen usar las arquitecturas multinivel o
programación por capas. En estas arquitecturas se le asigna a cada nivel una misión simple, lo
que permite el diseño de arquitecturas que pueden ampliarse con facilidad en caso de que las
necesidades aumenten. (Tesoriero et al.).
Para este caso en particular se cuenta con una misma aplicación publicada en dos servidores,
donde en un servidor se publicará la aplicación así como los métodos del negocio de la
aplicación, que serán consumidos por la aplicación publicada en el otro servidor. Por el hecho de
que hay dos servidores con la misma aplicación, es inaceptable llevar el mantenimiento por
separado de ambas instalaciones. Se decidió definir la arquitectura general del sistema a partir
del patrón arquitectónico en niveles y capas, lo cual permite mostrar la lógica del sistema en la
forma siguiente:
Nivel de clientes: En este nivel esta la capa de presentación, esta constituye la interfaz para
los tres usuarios del sistema, esta capa, presenta el sistema al usuario, le comunica la
información y captura la información del usuario dando un mínimo de proceso. Este se
comunica únicamente con el nivel de servicios.
Nivel de servicios: Contiene la capa de servicios publicados, la capa de lógica de negocio y
la capa de acceso a datos, aquí residen los programas que ejecutan las funcionalidades y
reglas que debe cumplir el negocio, recibiendo las peticiones del usuario y enviando las
respuestas tras el proceso. Este nivel se comunica con el de clientes, para recibir las
solicitudes y presentar los resultados, y con el nivel de datos, para solicitar al sistema gestor
de base de datos almacenar o recuperar datos.
Nivel de datos: Contiene la capa de datos donde residen los datos. La capa de datos puede
estar formada por uno o más sistemas administradores de bases de datos que permiten
37 MODELACIÓN DEL DOMINIO
37
obtener la información del sistema, realizan el almacenamiento de datos, reciben solicitudes
de almacenamiento o recuperación de información desde la capa de negocio.
Todas estas capas pueden residir en una o varias computadoras, en este caso particular se tienen
el servidor de aplicaciones web y el servidor de base de datos en computadoras separadas, se
decidió esto pensando en el crecimiento de las necesidades. De esta forma, si aumentara el
tamaño o la complejidad de la base de datos, se podrían separar en varias computadoras las
cuales recibirían las peticiones de la computadora en que resida la capa de negocio.
Por otra parte, si fuese la complejidad en la capa de negocio lo que obligase a la separación, esta
capa de negocio podría residir en una o más computadoras que realizarían solicitudes a una única
base de datos. En sistemas muy complejos se llega a tener una serie de computadoras sobre las
cuales corre la capa de datos, y otra serie de computadoras sobre los cuales corre la base de
datos.
En la Figura 2.2 se muestra un diagrama que representa la arquitectura requerida para el sistema.
38 MODELACIÓN DEL DOMINIO
38
Figura 2.2 Arquitectura del sistema.
2.3. Requisitos del sistema
La identificación de los requisitos como parte del proceso del desarrollo de Software es de gran
importancia; los requerimientos se dividen en funcionales y los no funcionales. Constituyen las
características que hacen al producto atractivo, usable, rápido y confiable. Son fundamentales en
el éxito del producto.
39 MODELACIÓN DEL DOMINIO
39
Booch y colaboradores, en el libro El proceso Unificado de Desarrollo de Software definen el
requisito funcional como el «requisito que especifica una acción que debe ser capaz de realizar el
sistema, sin considerar restricciones físicas; especifica comportamiento de entrada/salida de un
sistema» (Booch et al., 2000b). Por otra parte, definen el no funcional como el requisito que
«especifica propiedades del sistema, como restricciones del entorno o de implementación,
rendimiento, dependencias de la plataforma, mantenibilidad, extensibilidad o fiabilidad.
Requisito que especifica restricciones físicas sobre un requisito funcional» (Ídem cit.).
2.3.1. Captación inicial de requisitos
Los clientes y los usuarios finales tienen objetivos (también conocidos como necesidades) y
quieren sistemas informáticos que les ayuden a conseguirlos (Larman, 2003). En el caso que se
presenta, tal y como se ha planteado, ni los potenciales clientes (dígase MINSAP) ni los usuarios
finales del SSDC (los médicos) conscientes de la utilidad de un sistema como este insertado
dentro de su flujo de trabajo, por lo tanto no tienen objetivos planteados en un inicio.
En un proceso de captación de requisitos desarrollado en condiciones normales, el cliente o el
usuario tienen una idea de lo que quieren, y aunque sea de modo ambiguo son capaces de
expresarlo. Por lo tanto la primera tarea consiste en capturar el conocimiento asociado a las
actividades y procesos que se relacionan con el diagnóstico clínico para a partir de estos elaborar
los requisitos funcionales del sistema. De esta forma, la captación de los requisitos pasa por un
proceso de adquisición previa del conocimiento.
Como modos de adquisición del conocimiento se usaron la interacción del IC con los expertos y
con la bibliografía, para obtener la base de casos (en este contexto, realmente los casos son
equivalentes a casos de uso frente a escenarios).
Las técnicas empleadas fueron, en el primer caso, la entrevista y la encuesta. En el segundo caso
la técnica consistió en la revisión bibliográfica simple (sin minería de datos textual).
Los resultados de la revisión bibliográfica se detallaron en el epígrafe 1.1.1.
El Anexo I muestra la encuesta aplicada a especialistas en Medicina Interna (médicos clínicos)
con el objetivo de realizar la primera captación de procesos (la idea era contrastar los
procedimientos más habituales un nuestro país en relación a los registrados en la bibliografía).
En la encuesta participaron 11 especialistas, y el nivel de competencia de evaluó siguiendo las
normas del método Delphi (Ruiz Olabuénaga and Ispizua, 1989). Del total de especialistas
40 MODELACIÓN DEL DOMINIO
40
aproximadamente el 45% (5)resultó de competencia alta, y tanto los de competencia media como
baja constituyeron un 27% (3) aproximadamente. Existió una elevada coincidencia con lo
referido en la literatura, indicándose los pasos más comunes como (respuestas a la pregunta
«¿Pudiera usted describir el procedimiento que se sigue a la hora de realizar el diagnóstico de un
paciente en la consulta? »):
Realizar interrogatorio al paciente
Examen físico
Examen de laboratorio e imagenología (variables clínicas)
o Química clínica
o Si es necesario pruebas de rayos X
o Tomografía y resonancia magnética
Resultó llamativa la no mención de estrategias diagnósticas para establecer las hipótesis, por lo
que se realizó un segundo ciclo de entrevistas.
En cuanto a la pregunta final « ¿Qué funcionalidades le interesaría a usted que tuviese una
aplicación informática destinada a apoyarlo en la toma de decisiones durante el diagnóstico
clínico?», tampoco se hizo referencia a nada parecido a los SSDC. Las respuestas más generales
fueron:
accesibilidad (acceso a información sobre los avances tecnológicos a nivel nacional y
mundial)
plataforma de comunicaciones (posibilidad de video-conferencias, intercambio de
opiniones entre especialistas cubanos y foráneos)
A partir del estudio del dominio realizado, se seleccionaron los procesos de interés desde el
punto de vista del objetivo que dirige la presente investigación. Con estos se realizó la
formulación de los requisitos funcionales para la aplicación.
2.3.2. Requisitos funcionales
RF 1 Generación de Base de Conocimiento
RF 1.1 Generar la estructura.
41 MODELACIÓN DEL DOMINIO
41
RF 1.1.1 Introducir enfermedades y sus campos asociados.
RF 1.1.2 Introducir síndromes y sus campos asociados.
RF 1.2 Añadir casos.
RF 2 Generar ficheros .arff para Weka.
RF 3 Generar modelo.
Para este requisito funcional se utilizan los requerimientos ya implementados en (Molina, 2011).
RF 1. Realizar el aprendizaje estructural de clasificadores bayesianos.
RF 1.1 Realizar el aprendizaje estructural de clasificadores bayesianos
incluyendo los algoritmos de aprendizaje estructural optimizados para
ambientes Bioinformáticos y biomédicos ByNet, BayesChaid y BayesPSO.
RF 1.2 Permitir seleccionar los parámetros de entrada de los algoritmos
incluyendo el estadígrafo Chi cuadrado a utilizar (Pearson, Corregido de Yates, y
Mantel y Haenszel) para los algoritmos ByNet y BayesChaid.
RF 2. Realizar el aprendizaje paramétrico partiendo del aprendizaje estructural de los
clasificadores bayesianos generados.
RF 3 Mostrar gráficamente la red bayesiana generada.
RF 3.1 Permitir mover los nodos de la red bayesiana generada.
RF 3.2 Permitir organizar los nodos de la red bayesiana generada aplicando
varias estrategias.
RF 3.3 Mostrar la tabla de probabilidad condicional de un nodo de la red
bayesiana.
RF 3.4 Mostrar gráficamente los conglomerados de la red para la aplicación
del algoritmo de inferencia de árboles de unión.
RF 4. Evaluar los clasificadores generados.
42 MODELACIÓN DEL DOMINIO
42
RF 4.1 Permitir registrar los parámetros de evaluación para su posterior uso en
la comparación y selección del clasificador que más se ajuste al dominio de
estudio.
RF 4.2 Seleccionar los parámetros de evaluación a aplicar. Entre los mismos
se debe encontrar: rFN, rFT, rTP, rTN, ROC, Matthews CC, Exactitud,
Precisión.
RF 4.3 Evaluar el clasificador utilizando el mismo fichero de entrenamiento
como de prueba.
RF 4.4 Evaluar el clasificador utilizando un fichero de entrenamiento y uno de
prueba.
RF 4.5 Evaluar el clasificador utilizando un porciento del fichero de
entrenamiento como datos de prueba.
RF 4.6 Evaluar el clasificador a través de la operación de validación cruzada
tanto en un entorno centrado como en un ambiente distribuido (T-Arenal).
RF 5 Comparar varios clasificadores.
RF 5.1 Mostrar los resultados de la evaluación de varios clasificadores en
forma de tabla que permita resumir los parámetros y ordenarlos de acuerdo a la
selección del usuario.
RF 5.2 Mostrar los resultados de la evaluación de varios clasificadores a través
de gráficos.
RF 5.3 Aplicar la prueba de Friedman a varios experimentos.
RF 5.3.1 Seleccionar los experimentos a aplicar la prueba de Friedman.
RF 5.3.2 Seleccionar el parámetro de evaluación que se quiere
comparar en la prueba de Friedman.
RF 6 Realizar inferencias con un clasificador bayesiano generado.
43 MODELACIÓN DEL DOMINIO
43
RF 6.1 Seleccionar un clasificador bayesiano para realizar inferencias a partir
de los generados y disponibles por la aplicación.
RF 6.2 Cargar un clasificador bayesiano desde un fichero para utilizarlo en la
clasificación de nuevos datos.
RF 6.3 Cargar una estructura de datos vacía relacionada con el clasificador
bayesiano seleccionado para realizar inferencias.
RF 6.4 Cargar un fichero con datos como estructura de datos relacionada con
el clasificador bayesiano seleccionado para realizar inferencias.
RF 6.5 Editar la estructura de datos cargada permitiendo insertar nuevos valores
para las entidades a clasificar.
RF 6.6 Seleccionar la variable a clasificar.
RF 6.7 Clasificar las nuevas instancias a partir de los valores entrados
utilizando el algoritmo de árboles de unión.
RF 6.8 Salvar la estructura de datos con los valores de las nuevas instancias
clasificadas.
RF 7 Salvar en un fichero el clasificador bayesiano generado.
RF 8 Salvar el experimento realizado.
RF 9 Cargar un experimento desde un fichero.
RF 10 Visualizar y editar un conjunto de datos.
RF 10.1 Abrir fichero en formato ARFF.
RF 10.2 Insertar nuevas instancias y sus correspondientes valores.
RF 10.3 Adicionar nuevas instancias y sus correspondientes valores.
RF 10.4 Eliminar instancias y sus correspondientes valores.
44 MODELACIÓN DEL DOMINIO
44
RF 10.5 Eliminar atributos y sus correspondientes valores.
RF 4 Diagnosticar caso.
RF 4 .1 Seleccionar síntoma.
RF 4.1.1 Listar enfermedades.
RF 4.1.2 Listar síndromes.
RF 4.2 Seleccionar signos.
RF 4.2.1 Listar enfermedades.
RF 4.2.2 Listar síndromes.
RF 4.3 Seleccionar síndrome.
RF 4.3.1 Listar enfermedades.
RF 4.3.2 Listar síntomas.
RF 4.3.3 Listar signos.
RF 4.4 Seleccionar enfermedades.
RF 4.4.1 Listar síndromes.
RF 4.4.2 Listar síntomas.
RF 4.4.3 Listar signos.
RF 4.4.4 Listar modelos disponibles.
RF 4.4.5 Seleccionar modelo.
RF 4.4.5.1 Visualizar evaluación del modelo.
RF 4.5 Proponer diagnóstico.
RF 4.5.1 Introducir síntomas y signos.
RF 4.5.2 Ejecutar modelo.
RF 4.5.3 Visualizar diagnostico posible.
RF 4.5.4 Propagar la red.
RF 4.5.4.1 Visualizar probabilidad del resto de variables.
RF 4.5.4.2 Sugerir nueva variable a medir.
2.3.3. Requisitos no funcionales
Los requisitos no funcionales sirven de apoyo a los usuarios del sistema para valorar el mismo,
ya que un producto seguro, usable, agradable y conveniente será más usado y empleado.
Los requisitos no funcionales para el sistema se relacionan a continuación:
45 MODELACIÓN DEL DOMINIO
45
Interfaz del sistema: La aplicación informática que se diseñó será usada por profesionales que
no necesariamente tienen habilidades en el trabajo con la computadora, por lo que la interfaz del
sistema debe ser amigable y fácil de usar, de manera que no sea difícil la interacción con ella.
Usabilidad: Debe ser de fácil uso y manejo, con opciones claras que le permitan al médico
interactuar con el sistema, y llevar a cabo la realización de las operaciones de forma similar al
diagnóstico tradicional.
Rendimiento: El sistema debe estar disponible para los usuarios las 24h, para garantizar de esta
forma el acceso al sitio en distintos horarios.
Soporte: El sistema cuenta con una base de datos y una aplicación Web que se sirve de la base
de datos y que además cuenta con los módulos implementados en (Molina, 2011). El sistema
brinda la posibilidad de hacer cambios en dependencia de los clientes que interactúen con él.
Seguridad: Para garantizar un control sobre la información, se cuenta con una interfaz definida
para cada rol de usuario, o sea, una para el médico, una para el ingeniero del conocimiento y una
última para el especialista en estadística, sin comunicación entre las mismas.
2.4. Dominio del problema
Sintetizando lo planteado los epígrafes 1.1.1 y 2.3.1, luego de realizar el interrogatorio y el
examen físico, los médicos siguen las siguientes estrategias:
Estrategia Hipotético – Deductiva: Formar una lista de los diagnósticos potenciales a
partir de los datos de interrogatorios, más la exploración física y los datos paraclínicos,
teniendo en cuenta los conocimientos explicativos y la experiencia del médico.
Estrategia Exhaustiva: Se realiza una investigación concientizada e invariable de todos
los hechos médicos.
Estrategia de Arborización: Mediante múltiples vías preestablecidas de preguntas y
respuestas se llega al diagnóstico correcto. Este sistema es rápido, efectivo, eficiente y
lógico.
Estrategia Gestalt/Tía Minnie: Se realiza una identificación inmediata de la
presentación de la enfermedad en el paciente por un patrón previamente aprendido. Esta
46 MODELACIÓN DEL DOMINIO
46
estrategia es no reflexiva, conduce a diagnósticos posibles y no necesariamente al
diagnóstico cierto.
El sistema diseñado cuenta con las características y herramientas necesarias para apoyar el
diagnóstico clínico de enfermedades en tres de las cuatro estrategias de diagnóstico previamente
explicadas, estas son las estrategias: hipotético – deductiva, exhaustiva y gestalt/Tía Minnie.
2.4.1. Modelo de dominio
En la Figura 2.3 Modelo de Dominio.Figura 2.3 se expone el diagrama del dominio y sus
definiciones.
Figura 2.3 Modelo de Dominio.
47 MODELACIÓN DEL DOMINIO
47
Tabla 2.1 Definiciones del dominio.
Nombre Definición
Médico Realiza la gestión del diagnóstico médico, obtiene las variables necesarias
para que el sistema pueda llevar a cabo la clasificación y sugerencia del
posible diagnóstico.
Ingeniero del
conocimiento
Encargado de la gestión de las enfermedades, así como actualizar y poblar
las bases de casos a partir del conocimiento obtenido.
Especialista en
estadística
A partir de los datos contenidos en la base de datos realiza inferencia
estadística y generar modelos.
Paciente El paciente brinda al médico ya sea de forma directa o indirecta los síntomas
y signos necesarios para el sistema de diagnóstico.
Enfermedad La enfermedad es la causa de todo el proceso, tiene síntomas, signos,
variables clínicas y variables ambientales asociadas.
Modelos Se encargan de llevar a cabo la clasificación de las enfermedades, de esta
forma el sistema es capaz de obtener un diagnóstico posible.
Diagnóstico Se obtiene a partir de los síntomas y signos presentados en el paciente, se
tienen en cuenta las demás variables asociadas, se clasifica mediante
modelos.
Variables
asociadas
Se clasifican en variables clínicas, el resultado de estas es obtenido mediante
pruebas de laboratorio, imagenología, etc., también existen variables
ambientales que están relacionada con los aspectos de vida del paciente, por
ejemplo, si el paciente fuma, consume bebidas alcohólicas, si se ejercita de
forma regular, etc.
48 MODELACIÓN DEL DOMINIO
48
2.4.2. Actores del sistema
El sistema cuenta con tres actores que serán los encargados de llevar a cabo todo el proceso del
diagnóstico, tanto la tradicional consulta médica al paciente, como la gestión de enfermedades y
demás variables asociadas a estas y la gestión de modelos que permitan una clasificación
eficiente de padecimiento y enfermedades. En la Tabla 2.2 se definen los diferentes actores del
sistema.
2.4.3. Diagrama de casos de uso
Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y
sus relaciones. Los diagramas de casos de uso se emplean para visualizar el comportamiento de
un sistema, un subsistema o una clase, de forma que los usuarios puedan comprender cómo
utilizar ese elemento y de forma que los desarrolladores puedan implementarlo (Booch et al.,
2000a).
En otras palabras, los casos de uso enlazan todas las actividades del desarrollo y dirigen el
proceso de desarrollo, este es quizá el beneficio más importante de la aproximación dirigida por
los casos de uso. La Figura 2.4 muestra el diagrama de casos de uso del sistema.
Tabla 2.2 Definición de los actores.
Nombre Definición
Médico Realiza la gestión del diagnóstico médico, provee al sistema de las variables
necesarias para que el mismo pueda llevar a cabo la clasificación y
sugerencia del posible diagnóstico y se encarga de elegir el modelo de
clasificación a utilizar, tiene la opción de rechazar el diagnostico sugerido
por el sistema.
Ingeniero del
conocimiento
Encargado obtener y administrar el conocimiento de las bases de casos,
responsable de la gestión de las enfermedades, de obtener el conocimiento
sin procesar, así como actualizar y poblar las bases de casos a partir del
conocimiento obtenido.
49 MODELACIÓN DEL DOMINIO
49
Especialista en
estadística
Tiene como tarea realizar inferencia estadística y generar modelos a partir de
los datos contenidos en la base de datos
2.4.4. Nombre y descripción de los casos de uso del sistema.
La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un
requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a
entidades externas tales como usuarios humanos u otros sistemas.
Los casos de uso son un mecanismo para ayudar a mantener simple y entendible el hilo
conductor del sistema (objetivos del cliente y requerimientos del sistema) para todo el personal
involucrado. De manera informal, son historias del uso de un sistema para alcanzar los objetivos.
Los casos de uso son descritos desde la Tabla 2.3 hasta la Tabla 2.10.
50 MODELACIÓN DEL DOMINIO
50
Figura 2.4 Diagrama de casos de uso del sistema.
51 MODELACIÓN DEL DOMINIO
51
Tabla 2.3 Descripción del caso de uso: Verificar Diagnóstico.
Caso de Uso: Verificar Diagnóstico
Actores: Médico
Propósito: Realizar búsqueda.
Resumen: El médico después de obtener la lista de enfermedades relacionada con los
síntomas y signos que introdujo en el sistema puede elegir la enfermedad que
según su criterio es de la que padece el paciente, para así entonces correr los
modelos de clasificación solamente para esa enfermedad seleccionada.
Tabla 2.4 Descripción del caso de uso: Obtener Posibles Enfermedades.
Caso de Uso: Obtener Posibles Enfermedades
Actores: Médico
Propósito: Realizar búsqueda.
Resumen: El proceso de obtener posibles enfermedades comienza cuando el médico
realiza el análisis tradicional llevado a cabo con el paciente para obtener los
síntomas y signos que presenta el mismo, seguido de este paso el médico
inserta en el sistema los síntomas y signos detectados en el paciente, así
como el síndrome (en caso de que lo identifique) con el que debe estar
relacionada la enfermedad que padece dicho paciente. Luego de esto, el
sistema devuelve un listado con todas las enfermedades que presentan esos
síntomas y signos y que pertenecen al síndrome dado (en caso de que se haya
identificado el síndrome).
52 MODELACIÓN DEL DOMINIO
52
Tabla 2.5 Descripción del caso de uso: Obtener Diagnóstico.
Caso de Uso: Obtener Diagnóstico
Actores: Médico
Propósito: Realizar búsqueda y clasificar.
Resumen: Después de que el médico obtiene la lista de enfermedades asociadas a los
síntomas y signos introducidos en el sistema, o la enfermedad en particular
que él decida que puede tener el paciente el sistema brinda una lista de los
modelos de clasificación que hay disponibles para ejecutar, el medico
selecciona uno de estos modelos, teniendo la opción de que el sistema le
muestre o no una caracterización del modelo, que consiste en una vista del
panel con la comparación de los parámetros registrados por la ejecución de
los algoritmos ByNet, BayesChaid, TAN y K2, luego se aplica el modelo, el
cual devuelve la enfermedad de mayor probabilidad, o simplemente la
probabilidad de la enfermedad seleccionada, el médico tiene la opción de
aceptar el diagnóstico recomendado o de mandar a aplicar otro modelo de
clasificación.
Tabla 2.6 Descripción del caso de uso: Sugerir Actualización de la Base de Casos.
Caso de Uso: Sugerir Actualización de la Base de Casos
Actores: Médico
Propósito: Inserción o actualización tablas en las bases de datos.
Resumen: Cuando el médico acepta el posible diagnóstico recomendado por el sistema
este tiene la posibilidad de solicitar una actualización en la base de casos, ya
sea con un nuevo caso, o con la actualización de nuevos síntomas y/o signos
en un caso existente.
53 MODELACIÓN DEL DOMINIO
53
Tabla 2.7 Descripción del caso de uso: Generar Estructura.
Caso de Uso: Generar Estructura
Actores: Ingeniero del Conocimiento
Propósito: Adicionar tablas en las bases de datos.
Resumen: El ingeniero del conocimiento obtiene el conocimiento sin procesar, esta
información es validada por una comisión de especialistas médicos, se
procesa la información, de la que se obtienen la enfermedad, variables
necesarias como son los síntomas, signos, variables ambientales y clínicas,
por último se obtiene el síndrome al que pertenece dicha enfermedad.
El ingeniero del conocimiento obtiene mediante una consulta al sistema la
lista de las enfermedades registradas en la base de casos, si la enfermedad no
está registrada, genera nueva tabla, lo que se traduce como introducir en la
base de casos la nueva enfermedad con todas sus variables asociadas, así
como el síndrome que la caracteriza, termina la operación y sale del sistema.
Tabla 2.8 Descripción del caso de uso: Poblar Base de Casos.
Caso de Uso: Poblar Base de Casos
Actores: Ingeniero del Conocimiento
Propósito: Actualizar tablas en las bases de datos.
Resumen: El ingeniero del conocimiento analiza la base de casos sin procesar, evalúa
las respuestas dadas por el conjunto de expertos, si hay concordancia en los
datos se actualiza la base de casos, se limpia la base de casos no procesados
y se termina. Si no existe concordancia se valora la necesidad de una nueva
iteración, en caso de que esta no sea necesaria se termina, si hay necesidad
de una nueva iteración se genera y aplica la iteración de la encuesta a partir
de los nuevos datos obtenidos, el conjunto de expertos responde la nueva
54 MODELACIÓN DEL DOMINIO
54
encuesta, se vuelven a evaluar los casos, y continua el ciclo hasta que haya
concordancia en los datos o el ingeniero del conocimiento decida que no hay
necesidad de una nueva iteración.
Tabla 2.9 Descripción del caso de uso: Generar Archivo .arff.
Caso de Uso: Generar Archivo .arff
Actores: Especialista en Estadística.
Propósito: Dar formato a los datos.
Resumen: La aplicación gestiona los diferentes estudios como experimentos. Cada
experimento se relaciona directamente con un conjunto de datos, por lo tanto
el primer paso al crear un Experimento es seleccionar y editar los datos
correspondientes al estudio. El conjunto de datos pueden cambiarse y
permanecerán mostrándose mientras el usuario lo determine conveniente, de
forma que puedan estar accesibles mientras se evalúan los clasificadores
generados a partir de los mismos. Con los datos se pueden realizar varias
operaciones como la inserción o eliminación de instancias, eliminación de
atributos, reemplazo de valores, etc., antes de ser procesados.
Tabla 2.10 Descripción del caso de uso: Generar Modelos.
Caso de Uso: Generar Modelos
Actores: Especialista en Estadística.
Propósito: Generar modelos de clasificación.
Resumen: Para la generación de nuevos modelos, es posible crear uno o tantos
escenarios como el especialista estime conveniente. En cada escenario, se
definen las opciones de evaluación, se registran y seleccionan los parámetros
55 MODELACIÓN DEL DOMINIO
55
de comparación que luego podrán ser vistos, se selecciona el algoritmo de
aprendizaje estructural a utilizar (ByNet y BayesChaid y BayesPSO) y se
definen los parámetros del mismo para generar el nuevo clasificador a partir
de los datos de entrada y la especificación de las opciones anteriores.
2.5. Validación de los requisitos funcionales a través de los casos de uso
Los casos de uso son requisitos; ante todo son requisitos funcionales que indican qué hará el
sistema (Larman, 2003). El objetivo de la validación por parte de los especialistas médicos de los
requisitos funcionales para el actor médico, fue realizado partiendo de los casos de uso descritos
en un leguaje cercano al médico (en el Anexo II se puede observar que la descripción no se
corresponde exactamente al modo en que fueron escritos en este capítulo). En esta ocasión se
contó solamente con ocho especialistas para aplicar la encuesta, de los cuales existe un 27% (2)
de especialistas con competencia alta y baja, respectivamente, mientras el restante 18% (3) tenía
competencia media.
En la Figura 2.5 se pueden observar los resultados para cada pregunta. Si bien se observa que el
100% de los encuestados evalúa con las categorías superiores el caso de uso «Obtener Posibles
Enfermedades», para el caso los requisitos «Verificar Diagnostico» y «Obtener Diagnóstico» se
observa una tendencia progresiva a evaluarlos hacia la categoría media.
Este resultado pudiera explicarse teniendo en cuenta, en primer lugar, que los casos de uso
fueron ordenados en orden de complejidad del escenario, y si se observa, se ve determinada
correlación entre la complejidad del caso de uso y la tendencia a votar por las categorías más
bajas. En segundo lugar, y a partir de la interpretación del resultado de la primera encuesta,
todavía pudiera no existir en el médico la comprensión de la utilidad de un SSDC como
herramienta de ayuda en la toma de la decisión clínica. Esto debe tenerse en cuenta para los
pasos posteriores de la metodología (posiblemente hasta la primera iteración y uso por parte de
los médicos, difícilmente se llegue a algún grado de entendimiento). Estos factores pudiesen ir en
contra de la usabilidad y aceptación del SSDC.
56 Conclusiones parciales
56
Figura 2.5 Resultados de la validación de los requerimientos a partir de los casos de uso para el actor médico.
Se grafican los niveles de respuesta por pregunta.
Conclusiones parciales
En este capítulo se argumenta la selección de la metodología de desarrollo RUP para la
elaboración del SSDC. Partiendo de los pasos establecidos para esta metodología, se realizó la
captación inicial de los requisitos del sistema usando técnicas de la IC. Estos requisitos fueron
validados y se comprobó que todavía pudiera persistir en los especialistas en medicina clínica la
duda sobre la utilidad de un SSDC. Partiendo de la modelación del dominio del problema, se
llegó al modelo del dominio, definiéndose sus actores y casos de uso.
57
57
3. DISEÑO DE LA APLICACIÓN
58 DISEÑO DE LA APLICACIÓN
58
CAPÍTULO 3. DISEÑO DE LA APLICACIÓN
En este capítulo se describen los principales procesos de la fase de la elaboración, mediante la
realización de los diagramas de: actividades, clases, secuencias, componentes y despliegue.
Además se muestran los resultados de la validación del diseño.
3.1. Diagramas de actividades
Un diagrama de actividades es una notación para un grafo de actividades donde se muestra el
flujo de actividad a actividad y trata la vista dinámica de un sistema, es un caso especial de
diagrama de estado en el cual todos o casi todos los estados son estados de acción y en el cual
casi todas o todas las transiciones son disparadas por la terminación de las acciones en los
estados origen. (Booch et al., 2000a).
3.1.1. Actividad de Diagnosticar Paciente
El proceso comienza cuando el médico realiza el análisis tradicional llevado a cabo con el
paciente para obtener los síntomas y signos que presenta el mismo, seguido de este paso el
médico inserta en el sistema los síntomas y signos detectados en el paciente, así como el
síndrome (en caso de que lo identifique) con el que debe estar relacionada la enfermedad que
padece dicho paciente. Luego de esto, el sistema devuelve un listado con todas las enfermedades
que presentan esos síntomas y signos y que pertenecen al síndrome dado (en caso de que se haya
identificado el síndrome). Después de obtener la lista de enfermedades relacionada con los
síntomas y signos que introdujo en el sistema puede elegir la enfermedad que según su criterio es
la que padece el paciente, para así entonces correr los modelos de clasificación solamente para
esa enfermedad seleccionada. A partir de esa lista de enfermedades asociadas a los síntomas y
signos introducidos en el sistema, o la enfermedad en particular que él decida que puede tener el
paciente el sistema brinda una lista de los modelos de clasificación que hay disponibles para
ejecutar, el medico selecciona uno de estos modelos, teniendo la opción de que el sistema le
muestre o no una caracterización del modelo, que consiste en una vista del panel con la
comparación de los parámetros registrados por la ejecución de los algoritmos ByNet,
BayesChaid, TAN y K2, luego se aplica el modelo, el cual devuelve la enfermedad de mayor
probabilidad, o simplemente la probabilidad de la enfermedad seleccionada, el médico tiene la
opción de aceptar el diagnóstico recomendado o de mandar a aplicar otro modelo de
59 DISEÑO DE LA APLICACIÓN
59
clasificación. Cuando el médico acepta el posible diagnóstico recomendado por el sistema este
tiene la posibilidad de solicitar una actualización en la base de casos, ya sea con un nuevo caso, o
con la actualización de nuevos síntomas y/o signos en un caso existente. La Figura 3.1 muestra el
diagrama de la actividad «diagnosticar Paciente».
Figura 3.1 Diagrama de la actividad «diagnosticar Paciente»
60 DISEÑO DE LA APLICACIÓN
60
3.1.2. Actividad de Generar Estructura en la Base de Casos
El ingeniero del conocimiento llega a obtener el conocimiento todavía sin procesar por dos
formas, una es mediante el análisis de libros o bibliografía en general, y el otro a través de la
aplicación de encuestas, las cuales son respondidas por una comisión de especialistas médicos.
Después de llevadas a cabo estas dos tareas, se procesa la información, de la que se obtienen la
enfermedad, variables necesarias como son los síntomas, signos, variables ambientales y
clínicas, por último se obtiene el síndrome al que pertenece dicha enfermedad.
El ingeniero del conocimiento obtiene mediante una consulta al sistema la lista de las
enfermedades registradas en la base de casos, el sistema decide si la enfermedad no está
registrada, genera nueva tabla, lo que se traduce como introducir en la base de casos la nueva
enfermedad con todas sus variables asociadas, así como el síndrome que la caracteriza, luego de
esto termina la operación y sale del sistema. En caso de que la enfermedad si este registrada en la
base de casos el ingeniero del conocimiento consulta al sistema una lista de campos asociados a
la enfermedad, en estos campos se encuentran todas las variables asociadas a la misma, en caso
de que falte alguna variable de las obtenidas recientemente el ingeniero del conocimiento
actualiza los campos, luego pide al sistema una lista de las referencias de la enfermedad, las
cuales son los síndromes que caracterizan la enfermedad, en caso de que no sea necesario
actualizar los campos se procede a la misma acción de listar las referencias asociadas a la
enfermedad , si no es necesario modificar las relaciones el sistema termina, en caso de que sea
necesario se actualiza la tabla de referencias y se termina igualmente. En la Figura 3.2 se puede
ver el diagrama de la actividad «generar estructura», donde interviene el actor Ingeniero del
conocimiento.
61 DISEÑO DE LA APLICACIÓN
61
Figura 3.2 Diagrama de la actividad «generar estructura»
3.1.3. Actividad Poblar Base de Casos
El ingeniero del conocimiento analiza la base de casos sin procesar, genera y aplica la encuesta
que luego responderán el conjunto de expertos, los cuales a partir de la respuesta dada proceden
a la evaluación de los casos, luego el ingeniero de conocimiento evalúa las respuestas dadas por
62 DISEÑO DE LA APLICACIÓN
62
el conjunto de expertos, si hay concordancia en los datos se actualiza la base de casos, se limpia
la base de casos no procesados y se termina. Si no existe concordancia se valora la necesidad de
una nueva iteración, en caso de que esta no sea necesaria se termina, si hay necesidad de una
nueva iteración se genera y aplica la iteración de la encuesta a partir de los nuevos datos
obtenidos, el conjunto de expertos responde la nueva encuesta, evalúa los casos, y continua el
ciclo hasta que haya concordancia en los datos o el ingeniero del conocimiento decida que no
hay necesidad de una nueva iteración. A continuación, en la Figura 3.3 se muestra el diagrama
para esta actividad.
Figura 3.3 Diagrama de la actividad «poblar base de casos»
63 DISEÑO DE LA APLICACIÓN
63
3.2. Diagramas de clases del diseño
Utilizando la extensión de UML para el modelado de aplicaciones WEB, cada fichero script
interpretable puede modelarse a partir de varias clases de UML, una clase representa el código
servidor, una clase representa el código cliente, y una clase representa los formularios presentes
en el código cliente. Así de tienen como elementos más significativos a 3 clases de UML con los
siguientes estereotipos “Server Page”, “Client Page” y “Form”, empleados para el código
servidor, código cliente y formularios respectivamente.
El código servidor es el encargado de construir o generar el resultado html que se traduce en el
código cliente (build), los formularios envían sus datos al código servidor para que sean
procesados los pedidos (submit), y además forman parte del código cliente o resultado html, es
por esto que la relación entre la clase empleada para el código cliente y la clase empleada para el
formulario es de agregación. Entre páginas clientes pueden existir vínculos (link). (Franco
Navarro).
A continuación se muestra los diagramas de clases del diseño correspondiente a los casos de uso
Obtener Posibles Enfermedades, Generar Estructura y Generar Modelos, el resto se encuentra en
el Anexo III.
Figura 3.4 Diagrama de clases del diseño correspondiente al caso de uso «obtener posibles enfermedades»
64 DISEÑO DE LA APLICACIÓN
64
Figura 3.5 Diagrama de clases del diseño correspondiente al caso de uso «generar estructura»
Figura 3.6 Diagrama de clases del diseño correspondiente al caso de uso «generar modelos»
3.3. Diagramas de secuencias
Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia
temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes
intercambiados entre ellos para llevar a cabo la funcionalidad descrita por el escenario. En
aplicaciones grandes además de los objetos se muestran también los componentes y casos de uso.
(Booch et al., 2000b).
En los diagramas de secuencia para aplicaciones Web, existe una consideración que se debe
hacer no importa cuál sea el enfoque empleado, y guarda relación con los mensajes. En las
aplicaciones OO tradicionales un mensaje suele resultar en un método brindado por la clase que
recibe el mensaje, pero en las aplicaciones Web, hay mensajes que son empleados
simbólicamente para reflejar interacciones propias de la tecnología, tal es el caso de los vínculos,
navegaciones, redireccionamientos, envíos de formulario y construcción de páginas (link,
navigate, redirect, submit, build). Cuando un actor interactúa con una aplicación Web, muchas de
65 DISEÑO DE LA APLICACIÓN
65
estas interacciones tienen lugar, entre los distintos elementos que la componen; representarlos en
un diagrama de secuencia ayuda a entender mejor su funcionamiento, colaborando con el
objetivo de documentar la solución. El segundo elemento que aparece en las aplicaciones
estructuradas son las llamadas a funciones, tanto ejecutadas en el cliente como el servidor, y
como las clases empleadas para representar dichos códigos, (client page y server page) tendrían
dichas funciones como métodos, entonces no hay problema en modelar la ejecución de las
mismas como mensajes en el Diagrama de Secuencia. (Franco Navarro)
Las de la Figura 3.7 a la Figura 3.10 se muestran los diagramas de secuencias asociados a los
casos de uso Obtener Posibles Enfermedades, Generar Estructura y Generar Modelos, el resto se
encuentra en el Anexo IV.
Figura 3.7 Diagrama de secuencia correspondiente al caso de uso «obtener posibles enfermedades»
66 DISEÑO DE LA APLICACIÓN
66
Figura 3.8 Diagrama de secuencia correspondiente al caso de uso «generar estructura»
Figura 3.9 Diagrama de secuencia correspondiente al caso de uso «generar modelos»
3.4. Diagrama de componentes
Los diagramas de componentes muestran la organización y las dependencias entre un conjunto
de componentes. Se utilizan para modelar la vista de implementación estática de un sistema.
Esto implica modelar los elementos físicos que residen en un nodo, tales como ejecutables,
bibliotecas, tablas, archivos y documentos. La Figura 3.10 muestra el diagrama de componentes.
67 DISEÑO DE LA APLICACIÓN
67
Figura 3.10 Diagrama de componentes.
3.5. Diagrama de despliegue
Los diagramas de despliegue muestran la configuración de los nodos que participan en la
ejecución y de los componentes que residen en ellos. Se utilizan para modelar la vista de
despliegue estática de un sistema. Esto implica modelar la topología del hardware sobre el que se
ejecuta el sistema (Booch et al., 2000a). A continuación se muestra el diagrama de despliegue de
la aplicación.
68 DISEÑO DE LA APLICACIÓN
68
Figura 3.11 Diagrama de despliegue del sistema.
3.6. Diagrama Entidad-Relación o modelo conceptual
El SSDC dispone de dos bases de casos, una para los casos reales y otra para almacenar los casos
no validados aún por los especialistas. Existe la necesidad dentro del sistema de agregar un
módulo que gestione enfermedades, síndromes y variables asociadas a cada enfermedad, además
de guardar los modelos generados para cada enfermedad. Para el modelado de la misma se
utilizó la herramienta ERECASE (García et al., 2008), la cual ofrece entre sus funcionalidades la
creación, edición, y el almacenamiento de diagramas Entidad-Relación. En la Figura 3.12 se
indica el modelo de entidad-relación que se presupone para la base de casos del SSDC.
Figura 3.12 Diagrama entidad-relación para las bases de casos.
69 DISEÑO DE LA APLICACIÓN
69
3.7. Validación del diseño
En el Anexo V se puede revisar el cuestionario de la encuesta aplicada para validar el presente
diseño.
La selección de los encuestados en este caso fue intencionada, y sin evaluación previa de las
competencias. Para ello se escogió a un grupo de cuatro desarrolladores que trabajan en la
producción como parte del Proyecto UCLV-FAR, que radica en el Centro de Estudios de
Informática, de la UCLV.
El tamaño de muestra pudiera ser cuestionable desde el punto de vista estadístico, pero en la
práctica el interés actual es evaluar qué tan esclarecedor sería el diseño realizado para el
desarrollador, partiendo de los aspectos que se reflejan en la encuesta. Por lo tanto más que una
validación estricta se realizó una evaluación del mismo.
Téngase también en cuenta que para las fases de la metodología RUP en la que se ubica este
diseño. A decir de (Larman, 2003), no se entendió bien el sentido del Unified Process, cuando,
entre otros:
Se piensa que el objetivo de la elaboración es definir modelos de manera completa
y cuidadosa, los cuales se traducen a código durante la construcción.
Se intenta definir la mayoría de los requisitos antes de comenzar el diseño o la
implementación.
Se intenta definir la mayoría del diseño antes de comenzar a implementar; se
intenta definir completamente y acordar una arquitectura antes de programar y
probar iterativamente.
Se dedica mucho tiempo a realizar trabajo sobre los requisitos y el diseño antes de
comenzar a programar.
En la Figura 3.13 a continuación, se observa el resumen de las valoraciones de estos
desarrolladores. En general, se aprecia que la opinión es buena, con un valor modal (valor más
frecuente) entre Muy Adecuado y Adecuado en todas las preguntas. Los criterios más
pobremente evaluados son los relativos a la posibilidad de formarse una idea general a partir del
70 Conclusiones parciales
70
diseño (pregunta a.) y a la flexibilidad del mismo (pregunta d.). No obstante, ninguna de ellas es
evaluada con criterios negativos.
Figura 3.13 Validación del diseño. Se muestran los resultados por pregunta.
Conclusiones parciales
Se realizó un diseño inicial del SSDC siguiendo los primeros pasos de la metodología RUP con
todos los artefactos correspondientes a la misma. La evaluación preliminar del diseño por un
conjunto de desarrolladores arrojó resultados positivos en los indicadores evaluados.
71 CONCLUSIONES
71
CONCLUSIONES
En el presente trabajo, se obtuvieron los siguientes resultados:
Partiendo de un estudio del dominio del problema, se fundamentó como metodología de
desarrollo del SSDC la RUP.
Mediante técnicas de la IC, se obtuvo un conjunto de requisitos funcionales para el SSDC
que sirven de partida para su desarrollo. Estos requisitos fueron validados por expertos en
el dominio de aplicación, aunque se pudo constatar que todavía no existe la comprensión
por parte de estos especialistas, como usuarios potenciales, de la posible utilidad del
SSDC dentro del proceso de diagnóstico.
Siguiendo los pasos de la metodología RUP realizó la modelación del domino de
aplicación de un SSDC basado en los Clasificadores Bayesianos que se desarrollaron en
la UCLV, y su posterior diseño sustentado en Web Service, el cual será un punto de
partida para la introducción de estos resultados como herramienta de apoyo al diagnóstico
clínico dentro del flujo organizacional del Sistema de Salud Pública Cubano.
La evaluación preliminar del diseño del SSDC por un grupo de desarrolladores ofreció en
general una valoración favorable del mismo.
72 RECOMENDACIONES
72
RECOMENDACIONES
Planificar, siguiendo la metodología RUP el ciclo completo de la primera iteración,
teniendo en cuenta los resultados obtenidos en la interacción con el posible cliente y las
valoraciones del diseño realizadas por los desarrolladores.
Incorporar al análisis los estudios de riesgos y factibilidad, los cuales no se tuvieron en
cuenta en la primera fase del diseño.
Complementar el diseño desde la perspectiva de sustituir al IC humano por un ingeniero
automatizado del conocimiento.
73 REFERENCIAS BIBLIOGRÁFICAS
73
REFERENCIAS BIBLIOGRÁFICAS
1. BELTRÁN, D. & ROCHE, F. 2002. METODOS PARA OBTENER CONOCIMIENTO UTILIZANDO REDES BAYESIANAS Y PROCESOS DE APRENDIZAJE CON ALGORITMOS EVOLUTIVOS. Tesis Doctoral. Sevilla: Universidad de Sevilla, Departamento de Lenguajes y Sistemas Informáticos.
2. BONIS, J., SANCHO, J. J. & SANZ, F. 2004. Sistemas informáticos de soporte a la decisión clínica. Medicina Clinica. Barcelona.
3. BOOCH, G., RUMBAUGH, J. & JACOBSON, I. 2000a. El lenguaje unificado de modelado. Manual de referencia., Madrid, Pearson Educación.
4. BOOCH, G., RUMBAUGH, J. & JACOBSON, I. 2000b. El proceso Unificado de Desarrollo de Software, Madrid, Pearson Educación.
5. CANÓS, J. H., LETELIER, P. & PENADÉS, M. C. 2003. Métodologías Ágiles en el Desarrollo de Software. In: TORRES, P. L. & LÓPEZ, E. A. S. (eds.) Metodologías Ágiles en el Desarrollo de Software. Alicante-España: Grupo ISSI.
6. CHÁVEZ, M. D. C. 2008. Modelos de redes bayesianas en el estudio de secuencias genómicas y otros problemas biomédicos. Tesis para obtener el Grado de Doctor en Ciencias Técnicas, Universidad Central ¨Marta Abreu¨ de Las Villas.
7. DUDA, R. & HART, P. 1973. “Pattern Classification and Scene Analysis”. 8. ECCLES, M., MCCOLL, E., STEEN, N., ROUSSEAU, N., GRIMSHAW , J., PARKIN, D.
& PURVES, I. 2002. Effect of computerised evidence based guidelines on management of asthma and angina in adults in primary care: cluster randomised controlled trial. BJM, 325.
9. FRANCO NAVARRO, J. A. UML en acción. Modelando Aplicaciones Web. Ciudad de la Habana. Cuba: CUJAE.
10. GARCÍA, C., RODRÍGUEZ , A. & GONZÁLEZ, L. 2008. Consideraciones acerca de la abstracción de agregación en la herramienta ERECASE. Revista Avances en Sistemas e Informática, 5, 21-25,.
11. HEATHFIELD, H. A. P., D. & HANKA, R. 1998. Evaluating information technology in healthcare: barriers and challenges. British MedicalJournal, 316, 1959-1961.
12. KASSIRER, J. K. R. 1991. Learning clinical reasoning, Baltimore, Williams and Wilkins. 13. KOHN, L. T., CORRIGAN, J. M. & DONALDSON, M. S. 1999. To Err is Human: Building
a Safer Health. . National Academy Press. Washington. 14. LARMAN, C. (ed.) 2003. UML y patrones. Una introducción al análisis y diseño
orientado a objetos y al proceso unificado. 15. LÓPEZ, J. & GARCÍA, J. 2008. Revista Electrónica de Metodología Aplicada. Sistemas
de Tutorización Inteligente Basados en Redes Bayesianas. Vol. 13 16. MÉZQUITA, J. F. 2006. El arte del diagnóstico. Med Int Mex, 22, 246-252. 17. MOLINA, E. 2011. Aplicación informática que integra los procesos de generación,
evaluación y uso de Clasificadores Bayesianos para dominios Bioinformáticos y Médicos., Universidad de las Ciencias Informáticas.
18. NÁPOLES RUIZ, G. 2011. Adquisición automática de conocimiento y aprendizaje basado en inteligencia colectiva para mapas cognitivos difusos aplicados a un problema de comportamiento de viajes., UCLV.
19. OPEN CLINICAL. 2013. Decision support systems [Online]. Available: http://www.openclinical.org/dss.html [Accessed 13 mayo 2013].
20. PEARL, J. Year. Probabilistic reasoning in intelligent systems: networks of plausible inference. In, 1988 San Mateo, California.
21. QUISPE, C., SOLORZANO, V. H., HARRY, D. & VARGAS YUPANQUI, J. L. 2011. Metodología RUP (Rational Unified Process) Universidad Nacional del Altiplano.
74 REFERENCIAS BIBLIOGRÁFICAS
74
22. REAL ACADEMIA ESPAÑOLA 2001. Diccionario de la lengua española. 22 ed. Madrid, España: Real Academia Española.
23. RUIZ OLABUÉNAGA, J. I. & ISPIZUA, Y. M. A. 1989. La descodificación de la vida cotidiana. Métodos de investigación cualitativa.
24. , Bilbao, Universidad de Deusto. 25. SACKET, D., ET AL. 1994. Estrategias para el diagnóstico clínico en epidemiología
clínica. Ciencia básica para la medicina clínica., Buenos Aires, Médica Panamericana. 26. SILVA, L. C. & MUÑOZ, A. 2000. Debate sobre métodos frecuentistas vs bayesianos.
Gaceta Sanitaria, 14, 482-494. 27. SOLER, M., CARIDAD; LOMBARDO VAILLANT, ARIEL 2012. Artículo especial en
apoyo al método clínico. Revista Cubana de Medicina. La Habana. 28. TESORIERO, R., GALLUD, J. A., LOZANO, M. D. & PENICHET, V. M. R. 2010.
CAUCE: Model-driven Development of Context-aware Applications for Ubiquitous Computing Environments. Journal of Universal Computer Science, 16, 2111-2138.
29. WITTEN, I. H. & FRANK, E. 2005. Data Mining: Practical Machine Learning Tools and Techniques.
30. WYATT , J. D. S. 1991. Field trials of medical decision-aids: potential problems and solutions. Proc Annu Symp Comput Appl Med Care, 3-7.
75 Primera encuesta para la captación de conocimientos en el diagnóstico clínico
75
Anexo I Primera encuesta para la captación de conocimientos en
el diagnóstico clínico
Estimado (a) especialista:
En sus manos tiene un instrumento destinado a la obtención de información relevante para la
futura elaboración de un Sistema Informático de Apoyo al Diagnóstico Clínico y forma parte de
una investigación que se realiza en la Facultad de Matemática, Física y Computación de la
Universidad Central “Marta Abreu” de Las Villas. Le agradecemos de antemano su disposición
para brindarnos parte de su conocimiento y de su tiempo.
Preguntas
1. ¿En qué nivel de la siguiente escala valora usted su conocimiento o información respecto
al diagnóstico clínico? (marque con una X)
2. Para responder preguntas realizadas a usted sobre diagnóstico clínico, se basa en (marque
con una X en la casilla que indica el nivel de influencia en cada fuente):
3. ¿Pudiera usted describir el procedimiento que se sigue a la hora de realizar el diagnóstico
de un paciente en la consulta? (Para responder esta pregunta puede basarse tanto en
esquemas en esquemas como en sentencias, o sencillamente redactar un párrafo) [Nota:
nuestro interés fundamental es conocer cuáles son los pasos que se siguen, además de
determinar cuáles son las variables clínicas o de laboratorio que se usan con mayor
1 2 3 4 5 6 7 8 9 10
FUENTES DE ARGUMENTACION
Grado de influencia de cada una de
las fuentes en sus criterios.
A
(alto) M
(medio) B
(bajo)
Análisis teóricos realizados por usted
Su experiencia obtenida
Trabajos de autores nacionales
Trabajos de autores extranjeros
Su propio conocimiento del estado del
problema en el extranjero
Su intuición
76 Primera encuesta para la captación de conocimientos en el diagnóstico clínico
76
frecuencia para sustentar el diagnóstico diferencial
___________________________________________________________________________
___________________________________________________________________________
________________________________________________________________________
4. ¿Qué funcionalidades le interesaría a usted que tuviese una aplicación informática
destinada a apoyarlo en la toma de decisiones durante el diagnóstico clínico?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
______________________________________________________________
77 Segunda encuesta. Realizada para validar los requerimientos funcionales.
77
Anexo II Segunda encuesta. Realizada para validar los
requerimientos funcionales.
Estimado (a) especialista:
En sus manos tiene un instrumento destinado a la obtención de información relevante para la
futura elaboración de un Sistema Informático de Apoyo al Diagnóstico Clínico y forma parte de
una investigación que se realiza en la Facultad de Matemática, Física y Computación de la
Universidad Central “Marta Abreu” de Las Villas. Le agradecemos de antemano su disposición
para brindarnos parte de su conocimiento y de su tiempo.
Preguntas
1. ¿En qué nivel de la siguiente escala valora usted su conocimiento o información respecto
al diagnóstico clínico? (marque con una X)
2. Para responder preguntas realizadas a usted sobre diagnóstico clínico, se basa en (marque
con una X en la casilla que indica el nivel de influencia en cada fuente):
3. A continuación serán descritas las formas en la que usted como especialista pudiera
utilizar el Sistema Informático de Apoyo al Diagnóstico Clínico que se encuentra en
proceso de diseño, en aras de que nos ofrezca su valoración sobre la pertinencia del
mismo. Le pedimos que evalúe cada caso de uso de acuerdo a la escala que se propone.
1 2 3 4 5 6 7 8 9 10
FUENTES DE ARGUMENTACION
Grado de influencia de cada una de
las fuentes en sus criterios.
A
(alto) M
(medio) B
(bajo)
Análisis teóricos realizados por usted
Su experiencia obtenida
Trabajos de autores nacionales
Trabajos de autores extranjeros
Su propio conocimiento del estado del
problema en el extranjero
Su intuición
78 Segunda encuesta. Realizada para validar los requerimientos funcionales.
78
Casos de uso para el actor ¨Médico¨
Usted realiza la anamnesis y el examen físico del paciente. Obtiene un conjunto de
síntomas y signos que presenta el mismo. A partir de estos:
a. Proceso de “Obtener Posibles Enfermedades”.
i. Usted presenta dificultades para establecer las hipótesis diagnósticas.
Utiliza nuestro Sistema Informático para introducir los síntomas y signos
detectados en el paciente y el sistema devuelve un listado con todas las
enfermedades o alteraciones blanco que presentan esos síntomas y signos.
ii. Usted ha sido capaz de identificar un síndrome. Introduce en el sistema el
nombre del síndrome y el sistema devuelve un listado con todas las
enfermedades o alteraciones blanco asociadas al síndrome.
(Marque con una X)
Muy adecuado Adecuado Medianamente
adecuado
Poco adecuado No adecuado
b. Proceso de “Verificar Diagnóstico”
Usted, a partir de un conjunto de hipótesis diagnósticas, se ha decidido por una
enfermedad. El sistema le permite:
i. Obtener todos los posibles síntomas y signos asociados a esa enfermedad o
alteración blanco.
ii. Introducir los síntomas y signos observados. Mediante la utilización de
modelos estadísticos que el sistema posee (basados en Redes Bayesianas),
éste le devuelve la probabilidad de padecer esa enfermedad dado el
conjunto de síntomas y signos presentados.
iii. El sistema le da la posibilidad de escoger una nueva variable a medir
(pueden ser nuevos síntomas o signos, variables clínicas de laboratorio o
de imagenología, o variables ambientales) mediante varios criterios de
selección (basados en cómo mejoraría la probabilidad del diagnóstico al
conocerse el valor de esa variable).
79 Segunda encuesta. Realizada para validar los requerimientos funcionales.
79
(Marque con una X)
Muy adecuado Adecuado Medianamente
adecuado
Poco adecuado No adecuado
c. Proceso de “Obtener Diagnóstico”.
Usted maneja un conjunto de hipótesis diagnósticas. El sistema le permite:
i. Obtener todos los posibles síntomas y signos asociados a cada una de las
enfermedades o alteraciones blanco.
ii. Introducir los síntomas y signos observados. Mediante la utilización de
modelos estadísticos que el sistema posee (basados en Redes Bayesianas),
éste le devuelve la probabilidad de padecer cada una de las enfermedades
que forman parte de las hipótesis diagnósticas dado el conjunto de
síntomas y signos presentados.
iii. El sistema le da la posibilidad de escoger una nueva variable a medir
(pueden ser nuevos síntomas o signos, variables clínicas de laboratorio o
de imagenología, o variables ambientales) mediante varios criterios de
selección (basados en cómo mejoraría la probabilidad de cada una de las
enfermedades o alteraciones blanco al conocerse el valor de esa variable).
.
(Marque con una X)
Muy adecuado Adecuado Medianamente
adecuado
Poco adecuado No adecuado
80 Diagramas de clases del diseño.
80
Anexo III Diagramas de clases del diseño.
Figura Anexo III.1 Diagrama de clases del diseño correspondiente al caso de uso «verificar diagnóstico»
Figura Anexo III.2 Diagrama de clases del diseño correspondiente al caso de uso «obtener diagnóstico»
81 Diagramas de clases del diseño.
81
Figura Anexo III.3 Diagrama de clases del diseño correspondiente al caso de uso «sugerir actualización de la
base de casos»
Figura Anexo III.4 Diagrama de clases del diseño correspondiente al caso de uso «poblar base de casos»
Figura Anexo III.5 Diagrama de clases del diseño correspondiente al caso de uso «generar archivo .arff»
82 Diagramas de secuencia.
82
Anexo IV Diagramas de secuencia.
Figura Anexo IV.1 Diagrama de secuencia correspondiente al caso de uso «verificar diagnóstico»
Figura Anexo IV.2 Diagrama de secuencia correspondiente al caso de uso «obtener diagnóstico»
83 Diagramas de secuencia.
83
Figura Anexo IV.3 Diagrama de secuencia correspondiente al caso de uso «sugerir actualización de la base de
casos»
Figura Anexo IV.4 Diagrama de secuencia correspondiente al caso de uso «poblar base de casos»
84 Diagramas de secuencia.
84
Figura Anexo IV.5 Diagrama de secuencia correspondiente al caso de uso «generar archivo .arff»
85 Encuesta para la validación del diseño
85
Anexo V Encuesta para la validación del diseño
Estimado (a) especialista:
En sus manos tiene un instrumento destinado a la obtención de información relevante para la
futura elaboración de un Sistema Informático de Apoyo al Diagnóstico Clínico y forma parte de
una investigación que se realiza en la Facultad de Matemática, Física y Computación de la
Universidad Central “Marta Abreu” de Las Villas. Le agradecemos de antemano su disposición
para brindarnos parte de su conocimiento y de su tiempo.
Preguntas A usted se le ha entregado una documentación correspondiente al diseño de un Sistema
Informático de Apoyo al Diagnóstico Clínico. A continuación le pediremos que brinde sus
valoraciones sobre el referido diseño. Tenga en cuenta que esta documentación se corresponde
con la Metodología de Desarrollo de software RUP (Rational Unified Process). Se le ofrecerán
enunciados, los cuales usted debe evaluar en correspondencia con su adecuación al criterio que
usted tiene sobre el referido diseño.
a) La documentación presentada permite al desarrollador formarse una idea general del
dominio del problema y de la forma en la que debe funcionar el sistema
(Marque con una
X)
Muy adecuado Adecuado Medianamente adecuado Poco
adecuado
No adecuado
x
b) La documentación brinda los elementos necesarios para realizar una primera
implementación del sistema en la fase de elaboración
(Marque con una
X)
Muy adecuado Adecuado Medianamente adecuado Poco
adecuado
No adecuado
x
86 Encuesta para la validación del diseño
86
c) El diseño es compresible, claro, sin ambigüedades
(Marque con una
X)
Muy adecuado Adecuado Medianamente adecuado Poco
adecuado
No adecuado
x
d) El diseño presenta la flexibilidad requerida para una primera iteración dentro de la
metodología RUP (adaptabilidad frente a retroalimentación)
(Marque con una
X)
Muy adecuado Adecuado Medianamente adecuado Poco
adecuado
No adecuado
x