Análisis y diseño de un sistema informático de soporte al ...

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


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 .............................................................................................................................................. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(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

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

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

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

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

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

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

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

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

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

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

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.3 Seleccionar síndrome.


RF 4.3.2 Listar síntomas.

RF 4.3.3 Listar signos.

RF 4.4 Seleccionar enfermedades.


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

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

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

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

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

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

Figura 2.4 Diagrama de casos de uso del sistema.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

http://www.openclinical.org/dss.html

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.







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

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

(Marque con una X)


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)


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

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

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







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)


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)


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)


adecuado

No adecuado

x

Análisis y diseño de un sistema informático de soporte al ...

Documents

Transcript of Análisis y diseño de un sistema informático de soporte al ...