Facultad de Informática Departamento de Informática y...

UNIVERSIDAD DE MURCIA

Facultad de Informática

Departamento de Informática y Sistemas

TESIS DOCTORAL

Aplicación de tecnologías semánticas para la creación de sistemas inteligentes de

diagnóstico diferencial de alta sensibilidad en medicina

Alejandro Rodríguez González

Dirigida por:

Dr. D. Rafael Valencia Garcia

Dr. D. Angel García Crespo

Dr. D. Juan Miguel Gomez Berbis

2012

I

Una vez terminado el juego, el rey y el peón vuelven a la misma caja.

Proverbio italiano.

III

A mi familia.

V

AGRADECIMIENTOS

He escrito estos agradecimientos al menos una docena de veces, debido

fundamentalmente a las nuevas personas que han aparecido en mi vida y me han aportado

algo que pueda ser relacionado con esta tesis, o debido, sobre todo, a la evolución que esta

ha sufrido, y aquí, la palabra sufrido, nunca ha tomado tanto sentido.

Empezar en primer lugar por los directores. A Rafael Valencia porque sin el, esta tesis

habría tenido lugar en circunstancias muy distintas. A Angel García por la infinita

paciencia con mis correos, llamadas, y un largo etc. A Juanmi por el apoyo, los consejos, y

dejarse utilizar de punching ball moral en muchas ocasiones de frustración y odio.

A todos mis compañeros, sobre todo a Enrique, Gandhi, Miki, Jose, Isra, Paniagua (hasta

que se fué) y Belén. Muy especialmente a esta última por todo su apoyo y ayuda en los

dificiles momentos que esta tesis lamentablemente ha tenido que sufrir. A Ricardo

también por toda la ayuda prestada en mil y unas cosas, ya que también sin su inestimable

ayuda, esta tesis podría haber tomado otros derroteros en varios aspectos.

Un aparte para Javier Torres, sin el cual, una parte tan importante de esta tesis como es la

evaluación hubiera tomado muchísimo más tiempo.

A todos mis colegas de “profesión” con su apoyo y trabajo: Chema (Universidad de

Oviedo), Giner (ITO), y muchos más que seguro que me dejo en el tintero.

A todos los expertos que han participado en la evaluación: Nieves Ortíz-Roldan, Nuria

Ovalle, Cristina Maza, Manuel Iglesias, Carmen Olmos, María Teresa Fábregas y Miguel

Angel Mayer. En especial al Dr. Mayer, al que también soy consciente de que he debido

llegar a crispar sus nervios con tanto correo y cambio.

A Jose Emilio Labra Gayo por la ayuda en muchas de las partes de Description Logics, así

como también su inestimable apoyo.

A David Rios Insua por su ayuda y recomendaciones sobre las formas de evaluación, que al

final permitieron establecer la metodología usada.

Para finalizar, a todos mis colegas (no académicos) por su apoyo, los buenos momentos y

por todo en general.

A mi familia política y en especial a Jessica por aguantarme en los días malos (que

lamentablemente fueron muchos).

Y para finalizar los agradecimientos: A mi familia: A mis padres, hermanos, abuelos, tíos,

etc… esta tesis es por y para vosotros. Os quiero.

VII

RESUMEN Las tecnologías semánticas, junto con algunas técnicas pertenecientes a la

inteligencia artificial, abarcan un conjunto de tecnologías punteras que facilitan entre otras cosas la compartición del conocimiento y el diseño y desarrollo de algoritmos que permitan dotar de cierta inteligencia a una máquina.

El presente trabajo hace uso de estas técnicas y tecnologías para demostrar que la aplicación de estas al campo de la medicina, y más concretamente al campo del diagnóstico diferencial, es ampliamente aplicable y además su aplicación permite la generación de sistemas de diagnóstico exactos y eficientes.

En este trabajo se realiza por lo tanto una retrospectiva muy amplia sobre los sistemas de soporte a la decisión de diagnóstico desde principios de los años 70, centrándose en aquellos cuyo campo de diagnóstico es el mismo que el presentado en esta tesis. Además de este estudio en profundidad del estado del arte, se plantean las hipótesis a verificar, que se resumen en demostrar la capacidad de las Tecnologías Semánticas y de ciertas técnicas de Inteligencia Artificial para la implementación de sistemas de soporte a la decisión de diagnóstico de alta sensibilidad que sean exactos y eficientes y que puedan solventar el problema de diagnóstico mediante inferencia multinivel, que es explicado con detalle a lo largo del presente documento. Así mismo, esta tesis también postula que la creación de procesos de diagnóstico alternativos a través de la ingesta de fármacos es una herramienta que pueda ser útil para la creación de sistemas de diagnósticos más efectivos en el futuro.

VIII

ABSTRACT Semantic Technologies and some artificial intelligence techniques cover a set of

leading technologies which facilitate knowledge sharing and the design and development of algorithms which allows giving some sort of intelligence to machines.

This work makes use of these techniques and technologies to demonstrate that the application of these to medicine field, and concretely, to differential diagnosis field, is widely appliable. Furthermore, this thesis also remarks that the application of these techniques and technologies allows the creation of efficient and precise high sensitivity differential diagnosis systems.

Hence, in this work, a broad retrospective about decision support systems from earlier 70s is introduced, focusing on those whose diagnostic area is the same than the once presented in this thesis. Besides this study of the state of the art, a number of hypothesis this thesis aims at verifing are settled. These hypotheses can be summarized in the heroic attempt of verifying the capability of Semantic Technologies and some Artificial Intelligence techniques to develop high sensitivity diagnositc decision support systems, both precise and efficient which could solve the problem of diagnosis through multilevel inference (which is explained in detail in the thesis). This thesis also postulates that the creation of alternative diagnosis process through the conssumption of medicines is a tool which could leverage the creation of more efficient diagnosis systems.

ii

I ND ICE DE C O N TE N ID O

1. INTRODUCCIÓN ............................................................................................................................................... 1

1.1. PRELIMINARES ................................................................................................................................................ 1

1.2. MOTIVACIÓN DE LA INVESTIGACIÓN ...................................................................................................... 2

1.3. CONCEPTOS MÉDICOS ................................................................................................................................... 3

1.3.1. DIAGNÓSTICO DIFERENCIAL .......................................................................................................................................... 3

1.3.2. SÍNTOMAS Y SIGNOS ........................................................................................................................................................ 4

1.3.3. PATOGNÓMICO ................................................................................................................................................................ 4

1.3.4. ENFERMEDAD .................................................................................................................................................................. 5

1.3.5. PRUEBAS DIAGNÓSTICAS................................................................................................................................................ 5

1.3.6. MEDICAMENTOS O FÁRMACOS ...................................................................................................................................... 6

1.3.7. CRITERIO DIAGNÓSTICO ................................................................................................................................................. 7

2. ESTADO DEL ARTE ......................................................................................................................................... 8

2.1. TRABAJOS RELACIONADOS ......................................................................................................................... 8

2.1.1. SISTEMAS DE SOPORTE A LA DECISIÓN CLÍNICA (CDSS) .......................................................................................... 8

2.1.2. SISTEMAS DE SOPORTE LA DECISIÓN DE DIAGNÓSTICO (DDSS) .......................................................................... 10

2.1.2.1. Diagnóstico General .................................................................................................................................... 10

2.1.2.2. Diagnóstico Específico ............................................................................................................................... 31

2.1.3. CONCLUSIONES ............................................................................................................................................................. 40

2.2. ESTADO DEL ARTE DE LAS TECNOLOGÍAS ......................................................................................... 40

2.2.1. TECNOLOGÍAS SEMÁNTICAS ....................................................................................................................................... 43

2.2.1.1. Ontologías ....................................................................................................................................................... 46

2.2.1.2. Representación de conocimiento mediante Descripciones lógicas ......................................... 48

2.2.1.3. ABox y TBox .................................................................................................................................................... 50

2.2.1.4. Reglas. Especificación de reglas Jena Rules ...................................................................................... 55

2.2.1.5. SPARQL ............................................................................................................................................................. 59

2.2.2. SISTEMAS BASADOS EN REGLAS ................................................................................................................................. 60

2.2.3. SISTEMAS DE INFERENCIA LÓGICA ............................................................................................................................. 61

2.2.4. TECNOLOGÍAS DE SOPORTE A LA DECISIÓN (DSS) ................................................................................................. 62

2.2.5. CONCLUSIONES ............................................................................................................................................................. 66

3. PLANTEAMIENTO DE LA HIPÓTESIS A VERIFICAR Y RESOLUCIÓN .......................................... 67

3.1. PLANTEAMIENTO DE LAS HIPÓTESIS .................................................................................................. 68

3.2. PLANTEAMIENTO DE VERIFICACIÓN DE LAS HIPÓTESIS ............................................................. 69

4. REPRESENTACIÓN DEL CONOCIMIENTO ............................................................................................ 70

4.1. INTRODUCCIÓN ............................................................................................................................................ 70

4.2. TERMINOLOGÍAS ......................................................................................................................................... 71

4.2.1. UMLS/SNOMED-CT .............................................................................................................................................. 71

4.2.1.1. Análisis de SNOMED-CT............................................................................................................................. 72

iii

4.2.1.2. Descripción de SNOMED-CT .................................................................................................................... 74

4.2.2. GALEN ......................................................................................................................................................................... 75

4.2.3. DISEASE ONTOLOGY (DO) ......................................................................................................................................... 76

4.2.4. OTRAS ............................................................................................................................................................................ 77

4.3. REPRESENTACION INFORMACIÓN MÉDICA ....................................................................................... 79

4.4. ONTOLOGÍA. VERSIÓN INICIAL ............................................................................................................... 83

4.4.1. DISEÑO .......................................................................................................................................................................... 84

4.4.1.1. Clases ................................................................................................................................................................. 84

4.4.1.2. Relaciones ........................................................................................................................................................ 86

4.4.1.3. Propiedades de datos .................................................................................................................................. 89

4.5. ONTOLOGÍA. VERSIÓN FINAL BASADA EN SNOMED-CT ................................................................ 92

4.5.1. SOLUCIÓN PROPUESTA ................................................................................................................................................ 92

4.5.1.1. Descarte de terminologías ....................................................................................................................... 93

4.5.1.2. Planteamiento de la solución .................................................................................................................. 98

4.5.2. REDEFINICIÓN DE LA ONTOLOGÍA ............................................................................................................................. 99

4.5.3. REESTRUCTURACIÓN DE LA ONTOLOGÍA EN SUB DOMINIOS .................................................................................. 99

4.5.3.1. Ontología Indicios Clínicos (CFO) ........................................................................................................ 103

4.5.3.2. Ontología Medicinas (DRO) ................................................................................................................... 106

4.5.4. RELACIONES DE LAS ONTOLOGÍAS DE CADA SUBDOMINIO .................................................................................. 107

4.5.5. BASE DE DATOS CONTENEDORA DE CÓDIGOS DE OTRAS TERMINOLOGÍAS ....................................................... 110

4.5.6. PROCESO DE POBLACIÓN DE LA ONTOLOGÍA ......................................................................................................... 110

4.5.6.1. Búsqueda y extracción del conocimiento médico ......................................................................... 110

4.5.6.2. Población de la ontología ....................................................................................................................... 113

4.6. CONCLUSIONES ........................................................................................................................................... 118

5. ODDIN ............................................................................................................................................................ 120

5.1. SUBSISTEMA PROBABILÍSTICO ............................................................................................................ 121

5.2. SUBSISTEMA DE CARGA DE DATOS .................................................................................................... 124

5.3. SUBSISTEMA COMBINATORIO .............................................................................................................. 125

5.4. SUBSISTEMA DE INFERENCIA ............................................................................................................... 130

5.5. SUBSISTEMA DE BÚSQUEDA.................................................................................................................. 131

5.6. DESCRIPCIONES LÓGICAS ASOCIADAS AL SISTEMA ..................................................................... 132

5.7. DISEÑO DE LAS REGLAS .......................................................................................................................... 135

5.8. CONCLUSIONES ........................................................................................................................................... 138

6. ADONIS Y SEDELO ...................................................................................................................................... 139

6.1. DESCRIPCIÓN DEL PROBLEMA A SOLUCIONAR .............................................................................. 139

6.2. ADONIS .......................................................................................................................................................... 139

6.2.1. SOLUCIÓN BASADA EN LÓGICA DESCRIPTIVA ........................................................................................................ 140

iv

6.2.2. SOLUCIÓN ALGORÍTMICA ......................................................................................................................................... 141

6.2.3. CONCLUSIONES .......................................................................................................................................................... 142

6.3. SEDELO .......................................................................................................................................................... 143

6.4. CONCLUSIONES ........................................................................................................................................... 144

7. MDDS-OPM ................................................................................................................................................... 146

7.1. GENERACIÓN DE REGLAS DE INFERENCIA ADAPTADAS A LAS NUEVAS ONTOLOGÍAS ... 146

7.1.1. REDEFINICIÓN DEL PROBLEMA ............................................................................................................................... 147

7.1.2. DISEÑO DE LAS REGLAS ............................................................................................................................................ 148

7.1.3. IMPLEMENTACIÓN DE LAS REGLAS ......................................................................................................................... 152

7.1.4. EXPLICACIÓN DEL RAZONAMIENTO ........................................................................................................................ 153

7.1.5. CONCLUSIONES .......................................................................................................................................................... 155

7.2. MODELO PROBABILÍSTICO EPIDEMIOLÓGICO ............................................................................... 158

7.2.1. INTRODUCCIÓN.......................................................................................................................................................... 158

7.2.2. EPIDEMIOLOGÍA ........................................................................................................................................................ 158

7.2.3. SOLUCIÓN PROPUESTA ............................................................................................................................................. 159

7.2.4. EJEMPLO DE USO ....................................................................................................................................................... 163

7.3. CONCLUSIONES ........................................................................................................................................... 167

8. EVALUACIÓN ............................................................................................................................................... 169

8.1. ENFOQUES DE EVALUACIÓN .................................................................................................................. 169

8.1.1. EVALUACIÓN DE LA EXACTITUD DE DIAGNÓSTICO DEL SISTEMA ....................................................................... 169

8.1.2. EVALUACIÓN DE LA COMPLEJIDAD COMPUTACIONAL. RENDIMIENTO .............................................................. 171

8.1.3. EVALUACIÓN DE LAS TÉCNICAS EMPLEADAS......................................................................................................... 172

8.2. METODOLOGÍA DE EVALUACIÓN ......................................................................................................... 172

8.2.1. EVALUACIÓN DE LA EXACTITUD .............................................................................................................................. 173

8.2.1.1. Fase de evaluación. Diseño del experimento .................................................................................. 174

8.2.1.2. Fase de análisis de resultados ............................................................................................................... 178

8.2.2. EVALUACIÓN DE LA COMPLEJIDAD COMPUTACIONAL. RENDIMIENTO .............................................................. 184



8.2.3. EVALUACIÓN DE LAS TECNOLOGÍAS ....................................................................................................................... 185



8.3. RESULTADOS EVALUACIÓN ................................................................................................................... 186

8.3.1. EVALUACIÓN DIAGNÓSTICA ..................................................................................................................................... 186

8.3.1.1. Expertos .......................................................................................................................................................... 186

8.3.1.2. Resultados ..................................................................................................................................................... 187

8.3.1.3. Conclusiones ................................................................................................................................................. 193

8.3.2. EVALUACIÓN COMPUTACIONAL .............................................................................................................................. 197

v

8.3.2.1. Conclusiones ................................................................................................................................................. 200

8.3.3. EVALUACIÓN TECNOLÓGICA .................................................................................................................................... 201

8.3.3.1. Conclusiones ................................................................................................................................................. 203

9. VERIFICACIÓN ............................................................................................................................................. 204

9.1. METODOLOGÍA DE VERIFICACIÓN ...................................................................................................... 204

9.2. VERIFICACIÓN DE LA EXACTITUD DIAGNÓSTICA (HIPÓTESIS H1.1) .................................... 205

9.2.1. CONCLUSIONES .......................................................................................................................................................... 207

9.3. VERIFICACIÓN DE LA EFICIENCIA COMPUTACIONAL (HIPÓTESIS H1.2) .............................. 207

9.3.1. CONCLUSIONES .......................................................................................................................................................... 209

9.4. VERIFICACIÓN DE LAS HIPÓTESIS H1 Y H2 ..................................................................................... 209

9.4.1. VERIFICACIÓN DE LA HIPÓTESIS H1 ...................................................................................................................... 209

9.4.2. VERIFICACIÓN DE LA HIPÓTESIS H2 ...................................................................................................................... 210

9.4.3. CONCLUSIONES .......................................................................................................................................................... 212

9.5. VERIFICACIÓN DE LA HIPÓTESIS H3 .................................................................................................. 213

9.5.1. CONCLUSIONES .......................................................................................................................................................... 215

10. CONCLUSIONES ........................................................................................................................................... 217

11. FUTURAS LÍNEAS DE INVESTIGACIÓN ............................................................................................... 219

12. SUMMARY ..................................................................................................................................................... 220

12.1. STATE OF THE ART ................................................................................................................................... 220

12.2. HYPOTHESIS ................................................................................................................................................ 220

12.3. KNOWLEDGE REPRESENTATION ......................................................................................................... 221

12.4. ODDIN, ADONIS AND SEDELO ............................................................................................................... 221

12.5. MDSS-OPM .................................................................................................................................................... 222

12.6. EVALUATION ............................................................................................................................................... 222

12.7. VERIFICATION ............................................................................................................................................ 223

12.8. CONCLUSIONS ............................................................................................................................................. 223

13. BIBLIOGRAFÍA ............................................................................................................................................ 225

14. ANEXOS.......................................................................................................................................................... 249

14.1. TABLAS DE VALORACIÓN MULTINIVEL ............................................................................................ 250

14.2. TABLAS DE RESULTADOS DIAGNÓSTICOS ....................................................................................... 253

14.2.1. ARBITRAJE AR-XF31 .......................................................................................................................................... 253

14.2.2. ARBITRAJE AR-TD46 .......................................................................................................................................... 259

14.2.3. ARBITRAJE UNIÓN (AR-XF31 ⋃ AR-TD46) ................................................................................................ 265

14.2.4. ARBITRAJE INTERSECCIÓN (AR-XF31 ⋂ AR-TD46) .................................................................................. 271

vi

14.3. TABLAS DE TIEMPOS ................................................................................................................................ 277

14.3.1. MOTOR DE INFERENCIA INICIALIZADO ............................................................................................................... 277

14.3.2. MOTOR DE INFERENCIA NO INICIALIZADO ......................................................................................................... 278

14.4. TABLAS DE CONSUMOS DE MEMORIA ............................................................................................... 279

14.4.1. MOTOR DE INFERENCIA INICIALIZADO ............................................................................................................... 279

14.4.2. MOTOR DE INFERENCIA NO INICIALIZADO ......................................................................................................... 280

14.5. PUBLICACIONES ......................................................................................................................................... 281

14.5.1. PUBLICACIONES EN CONGRESOS .......................................................................................................................... 281

14.5.2. PUBLICACIONES EN REVISTAS NO INDEXADAS .................................................................................................. 282

14.5.3. PUBLICACIONES EN REVISTAS INDEXADAS EN JCR .......................................................................................... 282

vii

I ND ICE DE F I GU R AS

FIGURA 1. CAPTURA DE PANTALLA DE DXPLAIN .................................................................................................................... 12

FIGURA 2. CAPTURA DE PANTALLA DE DIAGNOSISPRO .......................................................................................................... 14

FIGURA 3. MOTOR DE INFERENCIA DE DIAGNOSMD .............................................................................................................. 14

FIGURA 4. CAPTURA DE PANTALLA DE DIAGNOSMD .............................................................................................................. 16

FIGURA 5. EJEMPLO DE DIÁLOGO DEL SISTEMA VISUALDX .................................................................................................... 21

FIGURA 6. CAPTURA DE PANTALLA DE EMEDICINE ................................................................................................................. 22

FIGURA 7. CAPTURA DE PANTALLA DE PAIRS ......................................................................................................................... 23

FIGURA 8. DIAGRAMA DE LENGUAJES DE LA WEB SEMÁNTICA ............................................................................................. 43

FIGURA 9. MOTOR DE REGLAS HÍBRIDO DE JENA ..................................................................................................................... 57

FIGURA 10. ESTRUCTURA MESH ............................................................................................................................................... 78

FIGURA 11. EDICIÓN DE SIGNO EN OBO-EDIT ........................................................................................................................ 79

FIGURA 12. EJEMPLO DE REPRESENTACIÓN DE ENFERMEDADES USADO EN ODDIN ....................................................... 80

FIGURA 13. DEFINICIÓN DE ENFERMEDADES CON ENTIDAD ENFERMEDAD ACTUANDO COMO SIGNO/SÍNTOMA ......... 81

FIGURA 14. REPRESENTACIÓN DE LA ENFERMEDAD Y ........................................................................................................... 82

FIGURA 15. REPRESENTACIÓN DE LA RELACIÓN ENTRE ENFERMEDADES Y SÍNTOMAS .................................................... 86

FIGURA 16. EJEMPLO DE RELACIÓN DE UNA ENFERMEDAD ................................................................................................... 88

FIGURA 17. REPRESENTACIÓN DE ENFERMEDAD EN PROTÉGÉ ............................................................................................ 89

FIGURA 18. PROTÉGÉ EDITANDO DO ........................................................................................................................................ 94

FIGURA 19. RELACIONES ENFERMEDAD DE HUNTINGTON .................................................................................................... 95

FIGURA 20. CONCEPTO EN SNOMED-CT ............................................................................................................................... 97

FIGURA 21. ENFERMEDAD DE HUNTINGTON EN GALEN ...................................................................................................... 97

FIGURA 22. REPRESENTACIÓN DE LA ONTOLOGÍA ............................................................................................................... 102

FIGURA 23. REPRESENTACIÓN ONTOLOGÍA CFO ................................................................................................................. 103

FIGURA 24. REPRESENTACIÓN ONTOLOGÍA SO .................................................................................................................... 104

FIGURA 25. REPRESENTACIÓN ONTOLOGÍA DTO ................................................................................................................ 105

FIGURA 26. REPRESENTACIÓN ONTOLOGÍA DO ................................................................................................................... 106

FIGURA 27. REPRESENTACIÓN ONTOLOGÍA DRONT .......................................................................................................... 107

FIGURA 28. SNOMED: INDICIOS RELACIONADOS CON FUNCIÓN RENAL ......................................................................... 112

FIGURA 29. BÚSQUEDA CON SNOB (I) .................................................................................................................................. 114

FIGURA 30. BÚSQUEDA CON SNOB (II) ................................................................................................................................ 115

FIGURA 31. SNOMED BROWSER ........................................................................................................................................... 115

FIGURA 32. BÚSQUEDA EN SNOMED BROWSER ................................................................................................................ 116

FIGURA 33. ARQUITECTURA GENERAL DE ODDIN .............................................................................................................. 121

FIGURA 34. SITUACIÓN INICIAL DE LA INTERACCIÓN DE MEDICAMENTOS ....................................................................... 127

FIGURA 35. ETAPA 1 DE LA INTERACCIÓN DE MEDICAMENTOS ......................................................................................... 127




viii

FIGURA 39. ARQUITECTURA DEL SISTEMA ODDIN (II) ..................................................................................................... 131

FIGURA 40. ESQUEMA DE NIVELES DISEÑADO PARA MDSS-OPM.................................................................................... 157

FIGURA 41. MODELO PROBABILÍSTICO ................................................................................................................................... 160

FIGURA 42. MODELO PROBABILÍSTICO DEL ICTUS REDUCIDO .......................................................................................... 164

FIGURA 43. PROBABILIDADES EN GENIE .............................................................................................................................. 165

FIGURA 44. REPRESENTACIÓN DEL MODELO EN GENIE ..................................................................................................... 165

FIGURA 45. RESULTADO OBTENIDO TRAS PREGUNTAR A GENIE SOBRE UNA DETERMINADA PROBABILIDAD .......... 166

FIGURA 46. SISTEMA VS EXPERTOS. ARBITRAJE (AR-XF31) ........................................................................................... 188

FIGURA 47. SISTEMA VS EXPERTOS SELECCIONADOS. ARBITRAJE (AR-XF31) ............................................................. 188

FIGURA 48. SISTEMA VS EXPERTOS. ARBITRAJE (AR-TD46) ........................................................................................... 189

FIGURA 49. SISTEMA VS EXPERTOS SELECCIONADOS. ARBITRAJE (AR-TD46) ............................................................ 189

FIGURA 50. SISTEMA VS EXPERTOS. UNIÓN DE ARBITRAJES .............................................................................................. 190

FIGURA 51. SISTEMA VS EXPERTOS SELECCIONADOS. UNIÓN DE ARBITRAJES ................................................................ 190

FIGURA 52. SISTEMA VS EXPERTOS. INTERSECCIÓN DE ARBITRAJES ................................................................................ 191

FIGURA 53. SISTEMA VS EXPERTOS SELECCIONADOS. INTERSECCIÓN DE ARBITRAJES .................................................. 191

FIGURA 54. NIVEL DE CORRELACIÓN ENTRE ÁRBITROS. CASO DEL 1 AL 10 .................................................................... 192

FIGURA 55. NIVEL DE CORRELACIÓN ENTRE ÁRBITROS. CASO DEL 11 AL 20 ................................................................. 193

FIGURA 56. MEDIA DE TIEMPO DE RESOLUCIÓN DE LOS CASOS POR EXPERTO ................................................................ 198

FIGURA 57. TIEMPOS DE RESOLUCIÓN DE SISTEMA Y EXPERTOS ....................................................................................... 199

FIGURA 58. GRÁFICO DE CONSUMO DE MEMORIA DEL SISTEMA POR CASO CLÍNICO ....................................................... 199

FIGURA 59. VERIFICACIÓN EFICIENCIA (ÁRBITROS – INDIVIDUAL) .................................................................................. 206

FIGURA 60. VERIFICACIÓN EFICIENCIA (ÁRBITROS – CONJUNTOS) .................................................................................. 207

FIGURA 61. TIEMPO MEDIO DE RESOLUCIÓN DE CASOS ....................................................................................................... 209

x

I ND ICE DE TA BLA S

TABLA 1. SINÓNIMOS ENTRE OWL Y DL .................................................................................................................................. 49

TABLA 2. SEMÁNTICA PARA LAS EXPRESIONES DE DESCRIPCIÓN LÓGICA ............................................................................ 53

TABLA 3. BUILTINS DE JENA RULES ........................................................................................................................................... 59

TABLA 4. RELACIONES ONTOLOGÍA DO .................................................................................................................................... 76

TABLA 5. TABLA DE RELACIONES DEL SISTEMA ODDIN ....................................................................................................... 87

TABLA 6. PROPIEDADES DATATYPE DE ODDIN..................................................................................................................... 90

TABLA 7. RESUMEN INSTANCIAS ENFERMEDAD DE HUNTINGTON ....................................................................................... 95

TABLA 8. PREFIJOS ONTOLOGÍA ............................................................................................................................................... 107

TABLA 9. RELACIONES DE LA ONTOLOGÍA ............................................................................................................................. 108

TABLA 10. EXPRESIVIDAD DE LAS ONTOLOGÍAS ................................................................................................................... 108

TABLA 11. DISEÑO DE LA BASE DE DATOS ............................................................................................................................. 110

TABLA 12. TABLA DE EJEMPLO DEL CÁLCULO DE INTERACCIONES .................................................................................... 129

TABLA 13. PROBABILIDADES ASOCIADAS AL MODELO PROBABILÍSTICO .......................................................................... 164

TABLA 14. PROBABILIDADES CALCULADAS PARA EL MODELO PROBABILÍSTICO ............................................................. 164

TABLA 15. TABLA DE MUESTRA PARA EL CÁLCULO DE LAS MÉTRICAS (SISTEMA) ......................................................... 180

TABLA 16. TABLA DE MUESTRA PARA EL CÁLCULO DE LAS MÉTRICAS (EXPERTOS) ...................................................... 181

TABLA 17. EVALUADORES ........................................................................................................................................................ 187

TABLA 18. ÁRBITROS ................................................................................................................................................................ 187

TABLA 19. RESULTADOS DEL ANÁLISIS ESTADÍSTICO DE PRECISION ................................................................................ 194

TABLA 20. RESULTADOS DEL ANÁLISIS ESTADÍSTICO DE RECALL ..................................................................................... 195

TABLA 21. RESULTADOS DEL ANÁLISIS ESTADÍSTICO DE ACCURACY ................................................................................ 195

TABLA 22. RESULTADOS DEL ANÁLISIS ESTADÍSTICO DE SPECIFITY ................................................................................. 195

TABLA 23. RESULTADOS DEL ANÁLISIS ESTADÍSTICO DE MCC .......................................................................................... 195

TABLA 24. ENFERMEDADES DONDE EL SISTEMA PIERDE EN ALGUNA MÉTRICA (INTERSECCIÓN DE ARBITRAJES) ... 197

TABLA 25. RELACIÓN DE TIEMPOS DE RESOLUCIÓN POR EXPERTO (EN MINUTOS) ........................................................ 198

TABLA 26. TABLA EVALUACIÓN TECNOLÓGICA: REDES BAYESIANAS ............................................................................... 201

TABLA 27. TABLA EVALUACIÓN TECNOLÓGICA: REDES NEURONALES ............................................................................. 202

TABLA 28. TABLA EVALUACIÓN TECNOLÓGICA: ALGORITMOS GENÉTICOS ..................................................................... 202

TABLA 29. TABLA EVALUACIÓN TECNOLÓGICA: SISTEMAS BASADOS EN REGLAS ........................................................... 203

TABLA 30. TABLA EVALUACIÓN TECNOLÓGICA: TECNOLOGÍAS SEMÁNTICAS ................................................................. 203

TABLA 31. RESUMEN DE LOS RESULTADOS DE INFERENCIA MULTINIVEL ........................................................................ 211

TABLA 32. TABLA DE PREGUNTAS PARA VERIFICACIÓN DE HIPÓTESIS H3 ...................................................................... 214

TABLA 33. RESPUESTAS A PREGUNTAS PARA LA VERIFICACIÓN DE H3 ............................................................................ 214

TABLA 34. OBSERVACIONES A LAS PREGUNTAS PARA LA VERIFICACIÓN DE H3 ............................................................. 215

TABLA 35. TABLA DE VALORACIÓN DE INFERENCIA MULTINIVEL: FIEBRE TIFOIDEA (I) ............................................. 250

TABLA 36. TABLA DE VALORACIÓN DE INFERENCIA MULTINIVEL: FIEBRE TIFOIDEA (II) ............................................ 250

TABLA 37. TABLA DE VALORACIÓN DE INFERENCIA MULTINIVEL: LARINGITIS .............................................................. 251

TABLA 38. TABLA DE VALORACIÓN DE INFERENCIA MULTINIVEL: BRONQUITIS (I) ...................................................... 251

xi

TABLA 39. TABLA DE VALORACIÓN DE INFERENCIA MULTINIVEL: BRONQUITIS (II) ..................................................... 251

TABLA 40. TABLA DE VALORACIÓN DE INFERENCIA MULTINIVEL: BRUCELOSIS (I) ....................................................... 252

TABLA 41. TABLA DE VALORACIÓN DE INFERENCIA MULTINIVEL: BRUCELOSIS (II) ..................................................... 252

TABLA 42. RESULTADOS ARBITRAJE AR-XF31. ENFERMEDAD 1-12. EXPERTOS EX-KS0L Y EX-SK4V............... 253

TABLA 43. RESULTADOS ARBITRAJE AR-XF31. ENFERMEDAD 13-24. EXPERTOS EX-KS0L Y EX-SK4V ............ 254

TABLA 44. RESULTADOS ARBITRAJE AR-XF31. ENFERMEDAD 1-12. EXPERTOS EX-KV8H Y EX-VH7Q ............ 255

TABLA 45. RESULTADOS ARBITRAJE AR-XF31. ENFERMEDAD 13-24. EXPERTOS EX-KV8H Y EX-VH7Q.......... 256

TABLA 46. RESULTADOS ARBITRAJE AR-XF31. ENFERMEDAD 1-12. EXPERTOS EX-HQ3T Y SISTEMA ................ 257

TABLA 47. RESULTADOS ARBITRAJE AR-XF31. ENFERMEDAD 13-24. EXPERTOS EX-HQ3T Y SISTEMA ............. 258

TABLA 48. RESULTADOS ARBITRAJE AR-TD46. ENFERMEDAD 1-12. EXPERTOS EX-KS0L Y EX-SK4V .............. 259

TABLA 49. RESULTADOS ARBITRAJE AR-TD46. ENFERMEDAD 13-24. EXPERTOS EX-KS0L Y EX-SK4V ........... 260

TABLA 50. RESULTADOS ARBITRAJE AR-TD46. ENFERMEDAD 1-12. EXPERTOS EX-KV8H Y EX-VH7Q............ 261

TABLA 51. RESULTADOS ARBITRAJE AR-TD46. ENFERMEDAD 13-24. EXPERTOS EX-KV8H Y EX-VH7Q ......... 262

TABLA 52. RESULTADOS ARBITRAJE AR-TD46. ENFERMEDAD 1-12. EXPERTOS EX-HQ3T Y SISTEMA ............... 263

TABLA 53. RESULTADOS ARBITRAJE AR-TD46. ENFERMEDAD 13-24. EXPERTOS EX-HQ3T Y SISTEMA ............ 264

TABLA 54. RESULTADOS ARBITRAJE AR-XF31 ⋃ AR-TD46. ENF 1-12. EXP EX-KS0L Y EX-SK4V ................... 265

TABLA 55. RESULTADOS ARBITRAJE AR-XF31 ⋃ AR-TD46. ENF 13-24. EXP EX-KS0L Y EX-SK4V ................ 266

TABLA 56. RESULTADOS ARBITRAJE AR-XF31 ⋃ AR-TD46. ENF 1-12. EXP EX-KV8H Y EX-VH7Q ................. 267

TABLA 57. RESULTADOS ARBITRAJE AR-XF31 ⋃ AR-TD46. ENF 13-24. EXP EX-KV8H Y EX-VH7Q .............. 268

TABLA 58. RESULTADOS ARBITRAJE AR-XF31 ⋃ AR-TD46. ENF 1-12. EXP EX-HQ3T Y SISTEMA .................... 269

TABLA 59. RESULTADOS ARBITRAJE AR-XF31 ⋃ AR-TD46. ENF 13-24. EXP EX-HQ3T Y SISTEMA.................. 270

TABLA 60. RESULTADOS ARBITRAJE AR-XF31 ⋂ AR-TD46. ENF 1-12. EXP EX-KS0L Y EX-SK4V ................... 271

TABLA 61. RESULTADOS ARBITRAJE AR-XF31 ⋂ AR-TD46. ENF 13-24. EXP EX-KS0L Y EX-SK4V ................ 272

TABLA 62. RESULTADOS ARBITRAJE AR-XF31 ⋂ AR-TD46. ENF 1-12. EXP EX-KV8H Y EX-VH7Q ................. 273

TABLA 63. RESULTADOS ARBITRAJE AR-XF31 ⋂ AR-TD46. ENF 13-24. EXP EX-KV8H Y EX-VH7Q .............. 274

TABLA 64. RESULTADOS ARBITRAJE AR-XF31 ⋂ AR-TD46. ENF 1-12. EXP EX-HQ3T Y SISTEMA .................... 275

TABLA 65. RESULTADOS ARBITRAJE AR-XF31 ⋂ AR-TD46. ENF 13-24. EXP EX-HQ3T Y SISTEMA.................. 276

TABLA 66. TABLA DE TIEMPOS (EN MS, EXCEPTO MEDIA (M)) CON MOTOR DE INF INICIALIZADO ............................. 277

TABLA 67. TABLA DE TIEMPOS (EN MS, EXCEPTO MEDIA (M)) CON MOTOR DE INF NO INICIALIZADO ....................... 278

TABLA 68. TABLA CONSUMO DE MEMORIA (EN BYTES, EXCEPTO MEDIA) CON MOTOR DE INF INICIALIZADO .......... 279

TABLA 69. TABLA CONSUMO DE MEMORIA (EN BYTES, EXCEPTO MEDIA) CON MOTOR DE INF NO INICIALIZADO .... 280

xii

AC R O NI M OS

2D - Dos Dimensiones ABox - Assertion Box ADN - Acido Desoxirribonucleico AG - Algoritmos genéticos AI – Artificial Intelligence AL - Attributive Language ANFIS - Analysis of Neuro Fuzzy Inference System API – Application Programming Interface ATC - Anatomical, Therapeutic, Chemical classification system CAP - College of American Pathologists CBR - Case-based reasoning CDSS - Clinical Decision Support System CE - Casos por Experto CFO - Clinical Findings Ontology CIE – Clasificación Internacional de Enfermedades CLFNN - Complementary Learning Fuzzy Neural Network CPG - Clinical Practice Guidelines CTV3 - Clinical Terms Version 3 CWA - Closed World Assumption DDSS - Diagnosis Decision Support System DI - Diabetes DL - Description Logics DO - Disease Ontology DRO - Drugs Ontology DSS - Decision Support System DTO - Diagnostic Test Ontology EC - Ensayo Clínico EC - Expertos por Caso ECA - Ensayo Clínico Aleatorizado EIS - Executive Information System FAF - Fuzzy Activation Function FALCON-AART - Fuzzy Adaptive Learning Control Network with Adaptive Resonance Theory FN - False Negative FOAF – Friend of a friend FP - False Positive FSN - Fully Specified Name FVP - Fracción de Verdaderos Positivos GATE - Gate Assignment Display System GDMF - Gaussian Distributed Modified Function GDSS - Group Decision Support System GRAIL - GALEN Representation And Integration Language IA - Inteligencia Artificial ICD – International Classification of Diseases ICF - International Classification of Functioning, Disability and Health IDO - Infectious Disease Ontology ILFN - Incremental Learning Fuzzy Network IT - Information technologies LISP - LISt Processing (Lenguaje de programación) LOGIC - Logical Observation Identifers, Names and Codes LPO - Lógica de Primer Orden

xiii

LRU - Least Recent Used LVH - Left Ventricular Hypertrophy MBR - Model-based reasoning MCC - Matthews Correlation Coefficient MCRDR - Multiple Classification Ripple Down Rules MDB - Microsoft Access Database MDSS - Medical Decision Support System MesH - Medical Subject Headings MII - Motor de Inferencia Inicializado MIMO – Multiple Inputs Multiple Outputs MINI - Motor de Inferencia No Inicializado MIR - Medico Interino Residente MIT - Massachussets Institute of Technology MLFDA - Modification of Fisher Linear Discriminant Analysis MLP - Multilayer Perceptron MPANN - Memetic Pareto Artificial Neural Network MRU - Most Recente Used NA - No Aplicable NCC - Número de Casos Clínicos NCD - Not CIE Disease NCL - Not CIE Laboratory Test NCS - Not CIE Symptom NE - Número de Expertos NHS - National Health Service NLP - Natural Language Processing NPU - Nomenclature, Properties and Units NS - Namespace ODSS - Organizational Decision Support System OMS – Organización Mundial de la Salud OV - Overweight OWA - Open World Assumption OWL - Ontology Web Language PCA - Principal Component Analysis PRAS - Precision, Recall, Accuracy and Specifity QMR - Quick Medical Reference RAM - Reacción Adversa a un Medicamento RBS - Rule Based System RCT – Randomized Controlled Trial RDF - Resource Description Framework RDFS - Resource Description Framework Schema RDR - Ripple Down Rules RNA – Redes de Neuronas Artificiales SLD - Selective Linear Definite SNOMED-CT - Systemized Nomenclature of Medicine - Clinical Terms SNOMED-RT - Snomed Reference Terminology SO - Signs Ontology SOA - Service Oriented Architecture SPARQL - SPARQL Protocol and RDF Query Language SQL – Simple Query Language SWRL - Semantic Web Rule Language TBox - Terminology Box TI – Tecnologías de la Información TN - True Negative TP - True Positive

xiv

UCI - Unidad de Cuidados Intensivos UMLS - Unified Medical Language System UoD – Universe of Discourse URI - Universal Resource Identifier VIH – Virus de Inmunodeficiencia Humana VMP - Virtual Medicine Product VN – Verdaderos Negativos VP – Verdaderos Positivos VTM - Virtual Therapeutic Moiety W3C - World Wide Web Consortium XML - eXtensible Markup Language

1

1. INTRODUCCIO N El primer capítulo de la presente tesis pretende mostrar un pequeño texto

introductorio (englobado en la siguiente sección) donde se hablará del impacto de las nuevas tecnologías en el área de las biociencias y más concretamente en el área que se pretende cubrir con esta tesis: el diagnóstico diferencial en medicina.

Tras esta primera sección introductoria se procederá a argumentar la motivación existente para llevar a cabo la investigación que ha conducido a esta tesis.

1.1. PRELIMINARES

El uso de nuevas tecnologías ha causado una dramática transformación en la práctica de la investigación relacionada con las biociencias. Por lo tanto, el rápido crecimiento de la investigación y desarrollo usando Inteligencia Artificial en los sistemas de información relacionados con la biología y la medicina ha desatado una atención a nivel mundial en la administración y manejo del conocimiento médico (Liu et al., 2009).

El desarrollo de sistemas de diagnóstico diferencial médico y sistemas de terapia usando inteligencia computacional y tecnologías de redes distribuidas ha ganado importancia los últimos años (Zhao et al., 2005). En Cohen (2004), las ciencias de la biología y medicina están consideradas como uno de los campos más prometedores de la ciencia en el siglo veintiuno, y estos avances se espera que tengan un tremendo impacto en el dominio de las tecnologías de la información (TI). Sin embargo, el aprovechamiento máximo del potencial de las aplicaciones de conocimiento intensivo en diagnóstico diferencial médico es un problema crítico a tratar para obtener buenos resultados de eficiencia y precisión de diagnóstico o de sistemas terapéuticos.

Las Tecnologías Semánticas, que hacen referencia al previamente concepto conocido como Web Semántica (Berners-Lee et al., 2001) han emergido como un intento para proveer de metadatos procesables de forma automática por máquinas para la, cada vez mayor, cantidad de información disponible en los recursos de la Web. Estos estándares software y metodologías pueden ser aplicadas a ciertos dominios particulares para ser capaces de realizar un amplio uso de las especificaciones de la Web Semántica como RDF (W3C, 2004), (W3C, 2006). Estas especificaciones pueden definir la terminología de un dominio científico como una ontología que puede interpretarse por una máquina usando XML como sintaxis de intercambio de datos. Estas han sido desarrolladas y mejoradas a lo largo del avance de la Web Semántica y pueden explotarse para revelar relaciones latentes que a su vez puedan ser leídas automáticamente por máquinas y que contengan información de diagnóstico específica en la disciplina de la medicina, donde la homogeneidad de la terminología es particularmente problemática (Fuentes-Lorenzo et al., 2009).

Las ontologías se han desarrollado en el campo de la Inteligencia Artificial para facilitar la compartición de conocimiento y la reusabilidad. Estas son las piedras angulares de las Tecnologías Semánticas, porque proporcionan vocabularios estructurados que describen una especificación formal de un concepto compartido (Fensel, 2002). Los framework de las Tecnologías Semánticas activan la integración de datos, compartición y reutilización a partir de varias fuentes. El gran avance consistente en añadir metadatos semánticos a las aplicaciones médicas está proporcionando un nuevo nivel de datos e integración de procesos que puede ser usado para el desarrollo de sistemas de

2

mantenimiento y procesamiento de datos. Este nuevo nivel de eficiencia permite a las máquinas tener semántica formal para soportar razonamiento. Desde varios enfoques de la Inteligencia Artificial se ha trabajado con el problema de diagnósticos y su aplicación en entornos complejos como los del dominio médico (Juárez et al., 2007). Las tecnologías semánticas pueden proporcionar una base consistente para los sistemas de diagnóstico médico orientados hacia el conocimiento.

Las ontologías proporcionan uno de los mejores enfoques existentes para tratar el problema mencionado. El uso de las estas tiene la función, en primer lugar, de permitir a los humanos comprender el significado de cualquier elemento teniendo un vocabulario bien definido, y en segundo lugar, de tener soporte para razonamiento bajo semántica formal. Usar las tecnologías semánticas como clave tecnológica permite el mantenimiento de la gran cantidad de datos médicos existentes (ver por ejemplo, García-Sánchez et al., 2008 y Gómez et al., 2008).

La construcción de un sistema de diagnóstico diferencial en medicina implica usar un número de tecnologías basadas en el conocimiento que permitan combatir la ambigüedad, tal como las ontologías representan información específica de forma estructurada, pero también las estrategias como la computación de probabilidades de varios factores y la inferencia lógica, cuya combinación supera propuestas similares (García-Crespo et al., 2010).

Sin embargo, la eficiencia y solidez de las descripciones semánticas debe ser apoyada por su lógica subyacente. El entramado de los lenguajes lógicos y formalismos no es un problema trivial. Por lo tanto, una ontología debe definirse perfectamente y debe ser explicada para servir como base para aplicaciones médicas del mundo real. Por esta razón, debe definirse una ontología validada y exacta para crear una base para los sistemas de diagnóstico médico. También, la descripción de las enfermedades, síntomas, pruebas diagnósticas y otros parámetros clínicos deben ser definidos con rigor y comprobados por médicos. Esta descripción es uno de los problemas que están presentes en la mayoría de los sistemas de diagnóstico clínico que existen en la actualidad, donde no se tienen en cuenta todas las posibilidades, porque en algunos casos estos sistemas no son capaces de realizar la inferencia de la enfermedad correcta.

Dadas las exigencias o requisitos tanto tecnológicos como de rendimiento que son necesarios a la hora de desarrollar sistemas de diagnóstico médicos es necesario revisar un amplio número de tecnologías que pueden contribuir aportando solidez y calidad en el diseño e implementación de este tipo de sistemas. Por este motivo, en la presente tesis se realiza una amplia revisión de las principales tecnologías que se han ido utilizando durante varias décadas para el desarrollo de este tipo de sistemas para centrarse finalmente en aquellas que el doctorando ha considerado como más interesantes o con más posibilidades de cumplir con las exigencias o requisitos mencionados anteriormente.

1.2. MOTIVACIÓN DE LA INVESTIGACIÓN

La motivación para la realización de esta tesis nace con la intención de estudiar la aplicación de las diversas técnicas de la Inteligencia Artificial en la creación de los sistemas de diagnóstico médico. Hacia principios de los 70 del pasado siglo empezaron a surgir las primeras iniciativas en el diseño y desarrollo de este tipo de sistemas, los cuales fueron implementados utilizando diversas técnicas de Inteligencia Artificial que en su momento fueron consideradas técnicas de última generación.

Sin embargo, la creación de aplicaciones de diagnóstico médico, aunque no causó un gran impacto en lo referido a su adopción en entornos clínicos reales, sí que permitió que

3

se dieran grandes pasos en el surgimiento de nuevos campos de la informática relacionadas con la medicina, naciendo ramas como la bioinformática.

Las posibilidades que brindan este tipo de sistemas es otro de los motivos fundamentales que argumentan el inicio de esta investigación. La aplicabilidad de este sistema en entornos reales va más allá del mero diagnóstico en determinadas áreas concretas.

En esta tesis se pretende, una vez revisada la extensa literatura actual relacionada con los sistemas de diagnóstico médico, conseguir una mejora en la implementación de estos sistemas mediante la introducción de técnicas relacionadas con la Inteligencia Artificial y las Tecnologías Semánticas, destacando entre estas mejoras nuevas alternativas de representación del conocimiento.

Actualmente, el hecho de tener Sistemas Inteligentes (incompletos: sistemas expertos o similares) que sean capaz de proporcionar un diagnóstico fiable en función de una serie de parámetros de entrada como son los signos, síntomas, pruebas diagnósticas y otros, proporciona a los profesionales de la medicina un amplio espectro de posibilidades, al podérsele plantear opciones que en principio se podrían considerar poco probables, pero que un sistema automatizado debidamente entrenado y diseñado será capaz de tener en cuenta y por lo tanto mostrar al usuario final con la intención de que dicho diagnóstico sea tomado en cuenta.

1.3. CONCEPTOS MÉDICOS

En la presente sección se enumeran los conceptos de carácter médico que serán tratados con mayor o menor frecuencia a lo largo de toda la tesis. Estos conceptos son fundamentales para un entendimiento correcto de la tesis, puesto que a lo largo de la misma, en los diferentes capítulos se mencionaran muchos de ellos de forma rutinaria.

1.3.1. DIAGNÓSTICO DIFERENCIAL

El proceso de diagnóstico diferencial, se define como “el procedimiento por el cual se identifica una determinada enfermedad, entidad nosológica, síndrome, o cualquier condición de salud-enfermedad mediante la exclusión de otras posibles causas que presenten un cuadro clínico semejante al que el paciente padece” (Bruce, 2010). El diagnóstico diferencial además se caracteriza por proponer, por lo general, una serie de posibles diagnósticos (el conocido como diagnóstico, a secas, se consideraría como la conclusión final a la que el experto médico ha llegado tras desestimar otras posibles opciones mediante la información de la que se disponga), con el objetivo de llegar al mencionado diagnóstico final.

Las principales entidades involucradas y de las que en esta tesis se hará uso son las siguientes:

Signos/Síntomas Enfermedades Pruebas diagnósticas Medicinas o fármacos

Como se mencionará en los siguientes capítulos de la tesis, estas son las principales entidades que están involucradas en un proceso diagnóstico y por lo tanto son aquellas que se deben de tener en cuenta principalmente a la hora de modelar sistemas diagnósticos.

4

1.3.2. SÍNTOMAS Y SIGNOS

En este diseño se realiza una asunción de igualdad entre los términos signos y síntomas a pesar de no ser lo mismo, pero si estar íntimamente relacionados, definiéndose un síntoma como "la referencia subjetiva que da un enfermo por la percepción o cambio que reconoce como anómalo, o causado por un estado patológico o enfermedad" (Liddell & Scott, 2010) y signo como la "manifestación objetivable consecuente a una enfermedad o alteración de la salud, y que se hace evidente en la biología del enfermo" (eMedicine, 2010).

El hecho de realizar esta asunción de igualdad entre ámbos términos viene dado fundamentalmente por dos aspectos: La representación de estos términos, en SNOMED-CT, viene englobada dentro de lo que se denominan “findings”, y no se hace separación entre ellos. Por otra parte, el hecho de utilizar una equivalencia permite que a la hora de buscar un indicio (síntoma o signo), sea más sencilla su búsqueda al no hacerse distinción entre ambos términos.

Los signos o síntomas, actúan como entidad propia en este dominio, y además tienen una serie de características, entre las cuales la más destacable y que es la que se ha modelado en este sistema es la virulencia que pueden presentar. Esta virulencia viene medida por una medida subjetiva según el punto de vista del paciente, y más objetiva desde el punto de vista del experto médico. Un ejemplo que ilustra esta clasificación de virulencia la podemos encontrar en el síntoma/signo de la fiebre. Dependiendo de la temperatura corporal que se observe en el paciente (partiendo de la base de que lo normal es 37ºC) se podría definir en un sistema de clasificación de cinco niveles (que es el sistema propuesto) para clasificar la intensidad o capacidad con la que el signo está afectando al paciente. Este sistema de clasificación se divide en los siguientes niveles:

Muy bajo Bajo Medio Alto Muy alto

En el caso de la fiebre, esta clasificación en realidad se reduce a tres niveles, pero fácilmente puede ser asociado a los cinco anteriores (se utilizan cinco por generalización):

Febrícula: Si la temperatura axilar es mayor de 37ºC y menor de 38. Se podría asociar con el nivel bajo o muy bajo.

Fiebre: Si la temperatura axilar es mayor o igual a 38 y menor de 40ºC. Se podría asociar con el nivel medio.

Hiperpirexia: Si la temperatura es mayor o igual a 40ºC. Se podría asociar con el nivel alto o muy alto.

Sea como sea, la asociación de la virulencia o intensidad de un signo a un determinado nivel siempre vendría determinado por la valoración que el profesional haga del estado del paciente.

1.3.3. PATOGNÓMICO

El término patognomónico se utiliza para denominar aquellos signos (manifestaciones visibles), síntomas (manifestaciones no visibles, subjetivas) o pruebas diagnósticas que, si están presentes, confirman que el sujeto padece un determinado trastorno.

5

1.3.4. ENFERMEDAD

El concepto de enfermedad permite establecer las relaciones entre parte de los conceptos que han sido enumerados. Siendo la enfermedad un proceso y el estatus consecuente de afección de un ser vivo, caracterizado por una alteración de su estado ontológico de salud, se conoce como cuadro clínico o manifestaciones clínicas, a la relación entre los signos y síntomas que se presentan en una determinada enfermedad (en realidad, se presentan en el enfermo). Debido a este concepto de cuadro clínico, es posible definir por lo tanto las relaciones intrínsecas que existen entre los conceptos de enfermedad y síntomas y signos.

1.3.5. PRUEBAS DIAGNÓSTICAS

Otro concepto es el de las pruebas diagnósticas, que cuando hacen referencia a pruebas de laboratorio son conocidas también como análisis clínico, y que hace referencia comúnmente a "la exploración complementaria solicitada a un laboratorio clínico por un médico para confirmar o descartar un posible diagnóstico" (Jacobs et al., 1990). Este elemento, que forma parte como se menciona del proceso de diagnóstico, en determinadas situaciones es clave para confirmar o desmentir un determinado diagnóstico.

Entrando en detalle en las pruebas de laboratorio, dentro de este concepto, existen dos valores que en este caso se asocian de forma simplificada para relacionar el resultado de la prueba con la conclusión que ella arroja. En el caso de los síntomas, se ha visto que, como entidad propia que es, posee una serie de características como el peso, virulencia o intensidad de la misma. En el caso de las pruebas de laboratorio, la principal característica que se considera en estas entidades es el hecho de que esta prueba esté confirmando o no un determinado hecho, es decir, que su valor sea positivo o negativo. Esta es una simplificación demasiado general, pero necesaria para la conceptualización del dominio a diseñar.

Las pruebas de laboratorio pueden ofrecer valores más amplios que el simple “positivo” o “negativo” (valores numéricos fundamentalmente) (Pita & Pértegas, 2003). Sin embargo, en ciertos casos se puede asumir la posibilidad de asociar un determinado valor numérico de una prueba de laboratorio a una conclusión positiva o negativa, que en este caso el experto ha de tener presente. Un ejemplo de esta asunción es la siguiente:

Supongamos que para un paciente varón adulto se pide una prueba de laboratorio llamada Velocidad de sedimentación globular (Plebani & Piva, 2002), que es una prueba diagnóstica cuyo objetivo es medir la velocidad con la que sedimentan (decantan, caen) los glóbulos rojos o eritrocitos de la sangre, provenientes de una muestra de plasma sanguíneo, en un periodo determinado de tiempo.

Los valores que esta prueba remita, permiten obtener posibles diagnósticos que están asociados a los resultados de la misma. Partiendo de la situación anterior, suponiendo que estamos buscando unos valores de sedimentación altos o bajos (puesto que los normales, indicarían que la prueba de diagnóstico, la única información que está proporcionando es que no hay valores atípicos en esta prueba, descartándola como indicio de diagnóstico), podemos asumir el valor positivo a valores altos, y el valor negativo a valores bajos, sabiendo que el hecho de que la prueba de valores anormales es un probable indicativo de enfermedad.

Si el resultado de la prueba es positivo (valores altos, por encima de 15mm/h en el caso que contemplamos), esta prueba por si sola podría dar como resultado un posible diagnóstico diferencial de anemia, neoplasias, insuficiencia renal, etc. El resultado de esta prueba en conjunción con el resto de síntomas o pruebas introducidas, dará como

6

resultado un conjunto probablemente más limitado de resultados, ya que el resto de valores introducidos serán discriminantes para reducir las combinaciones de diagnóstico.

1.3.6. MEDICAMENTOS O FÁRMACOS

Los medicamentos o fármacos son “aquellas sustancias químicas purificadas que son usadas en la prevención, diagnóstico, tratamiento, mitigación y cura de una enfermedad; para evitar la aparición de un proceso fisiológico no deseado: o para modificar condiciones fisiológicas con fines específicos” (US-Government, 2008).

En el sistema actual, la medicina interviene como parte del proceso de diagnóstico debido a los posibles efectos secundarios que un fármaco puede provocar sobre un determinado paciente.

En medicina, se define el efecto secundario o reacción adversa a un medicamento (RAM), como "cualquier respuesta a un medicamento que sea nociva y no intencionada, y que tenga lugar a dosis que se apliquen normalmente en el ser humano para la profilaxis, el diagnóstico o el tratamiento de enfermedades, o para la restauración, corrección o modificación de funciones fisiológicas" (AEMPS, 2007).

En el concepto de RAM existen varios conceptos con cierta similitud, relativos a las reacciones adversas que pueda producir un fármaco. Sin embargo, dado el ámbito de aplicación de las reacciones adversas de los fármacos en el dominio a modelar, a continuación se indican solamente aquellos efectos que tengan relación alguna con la tesis.

Efecto primario: Es el efecto fundamental terapeútico deseado del fármaco. Efecto indeseado: Cuando el medicamento produce otros efectos que

pueden resultar indeseados con las mismas dosis que se produce el efecto terapeútico. Destacaremos dos:

o Efecto colateral: Tipo de efecto indeseado consecuencia directa de la acción principal del medicamento.

o Efecto secundario: Efectos adversos independientes de la acción principal del fármaco.

Los efectos primarios, son los que se espera que el tratamiento efectue, y para lo que ha sido diseñado el tratamiento. El efecto indeseado es aquel que en la presente tesis se modelará (con el nombre de efecto adverso, para generalizar), e incluye el efecto colateral y efecto secundario como uno solo (simplificación). La simplificación se produce dado que lo que realmente interesa en el dominio es saber si ha habido algún efecto indeseado, independientemente de que sea colateral, o secundario. Otros efectos indeseados como efectos tóxicos o letales no son contemplados por no ser necesarios en el dominio.

Para ilustrar los conceptos mencionados, se exponen dos ejemplos con un fármaco concreto, para poder ver los tipos de efectos:

Supongamos un paciente que ingiere un antihistamínico para prevenir el mareo durante un viaje. Los distintos efectos que pueden darse son:

Efecto primario: Evitar el mareo. Efecto colateral: Somnolencia.

o Si, por ejemplo, conduce: Posible Efecto secundario (Negativo): Accidente (efecto secundario del efecto colateral).

o Si, por ejemplo, duerme: Posible efecto secundario (Positivo): Dormir con mayor facilidad (efecto secundario del efecto colateral)

7

Supongamos ahora un paciente al que se le administra un antibiótico por via oral.

Efecto primario: Destrucción de un foco infeccioso. Efecto colateral: Alteración del equilibrio de la flora intestinal. Efecto secundario: Diarrea, pues es consecuencia indirecta, tras la alteración

producida por el efecto colateral.

1.3.7. CRITERIO DIAGNÓSTICO

El término criterio diagnóstico1 hace referencia al conjunto de entidades (signos, síntomas, pruebas diagnósticas) que permiten con su presencia establecer si una determinada enfermedad debe ser tomada en cuenta a la hora de realizar un diagnóstico (Bertaud-Gounot et al., 2011).

Este término es quizás más conocido dentro del dominio de la psicología, donde suelen ser identificados de forma más clara los elementos que dan forma a una determinada conducta psicológico, y por lo tanto facilitan su diagnóstico. Sin embargo, no solamente en psicología existen los criterios diagnósticos, ya que en la medicina más clásica este concepto también es aplicable. Así mismo, existen diversas investigaciones orientadas a la determinación de estos criterios como parte importante de un diagnóstico, como puede ser en el caso de la esclerosis múltiple (Poser et al., 1984; McDonald et al., 2001), espondilitis anquilosante (Der-Liden & Valkenburg, 1984), síndrome de Guillain-Barré (Asbury & Comblath, 1990), artritis reumatoide (Ropes et al., 1959) o enfermedad de Parkinson (Gelb et al., 1999) entre muchos otros.

Este concepto, como se ha demostrado previamente (Peelen et al., 2007; Bertaud-Gounot et al., 2011) es muy útil a la hora de definir conocimiento relativo a los elementos que toman parte en el proceso de diagnóstico diferencial y de ahí la importancia que este concepto toma en la presente investigación.

La identificación de los indicios que pertenecen a un determinado síndrome o entidad patológica y su interpretación, entre otras tareas, pertenece a la rama de la semiología clínica.

1 En el artículo de Bertaud-Gounot et al., el concepto criterio diagnóstico solo hace referencia a signos y síntomas. Sin embargo, la literatura médica revisada y citada posteriormente añade como parte de estos criterios otras entidades como las pruebas diagnósticas fundamentalmente.

8

2. ESTADO DEL ARTE En el dominio presentado en esta tesis existe una gran cantidad de literatura

referente a los sistemas de diagnóstico clínico. Se debe tener en cuenta que son un tipo específico de los conocidos como sistemas de soporte a la decisión. Debido a esto, en este capítulo, se presentan varios enfoques relacionados todos íntimamente con el estado del arte de las tecnologías y trabajos que tienen que ver con la tesis. Esto incluye, en primer lugar, una presentación de los principales trabajos que han sido desarrollados desde 1970 en los ámbitos de sistemas de soporte a la decisión clínica y sus principales tipos, centrándose principalmente en los sistemas de soporte a la decisión de diagnóstico. Todos estos trabajos son presentados en detalle en la sección 2.1 de la presente tesis.

Una vez estos trabajos han sido introducidos y conocemos con un alto grado de detalle los trabajos existentes relacionados con la temática de la tesis, se presenta un estado actual de las tecnologías que se han visto involucradas en el desarrollo de esta tesis en la sección 2.2.

2.1. TRABAJOS RELACIONADOS

En la presente sección se mencionan algunos de los trabajos más relevantes relacionados con el dominio presentado en la tesis, empezando por los sistemas de soporte a la decisión clínica, que es el pilar fundamental sobre el que se sustenta el tipo de sistemas que se pretenden analizar.

2.1.1. SISTEMAS DE SOPORTE A LA DECISIÓN CLÍNICA (CDSS)

Los sistemas de soporte a la decisión clínica (CDSS) son sistemas informáticos diseñados para asistir a los médicos y otros profesionales de la salud con la tarea de tomar decisiones (Trowbridge & Weingarten, 2001). Una definición en uso ha sido propuesta por el Dr. Robert Hayward del centro de evidencias de la salud: "Los sistemas de soporte a la decisión clínica vinculan las observaciones de la salud con el conocimiento clínico para influenciar en las decisiones relacionadas con temas clínicos realizadas por los profesionales del sector para mejorar el cuidado de la salud" (Hayward et al., 2006). Esta definición tiene la ventaja de simplificar soporte de decisión clínico a un concepto funcional.

Los sistemas de soporte a la decisión constituyen una clase de sistemas de información computarizados entre los que se incluyen sistemas basados en el conocimiento (también llamados sistemas expertos) (Waterman, 1986; Hayes-Roth et al, 1983; Durkin & Durkin, 1998) que soportan actividades de toma de decisiones (Klein et al., 1993). El objetivo de estos sistemas es ayudar a tomar decisiones compilando información útil a partir de una combinación de datos sin tratar, documentos, conocimiento personal o modelos de negocio para identificar y resolver problemas y tomar decisiones.

La mayoría de los trabajos existentes que se autodenominan como CDSS en realidad deberían ser englobados como DDSS dado que su principal objetivo es el de proporcionar un sistema de soporte a la decisión para la realización de diagnósticos (de tipo general, o específico).

Sin embargo, existen ciertos trabajos que se consideran dentro del ámbito de los CDSS o que tienen una relación directa con ellos.

Sea como sea, uno de los objetivos principales de los sistemas automatizados usados en medicina es el de reducir o prevenir la mayoría de los errores que se cometen en medicina usando las tecnologías de la información (Bates et al., 2001).

9

Cabe destacar por ejemplo aquellos en los que se trata de prevenir las posibles interacciones farmacológicas que puedan darse entre varios medicamentos, tratando de prevenir posibles problemas asociados a dichas interacciones. Una interacción farmacológica ocurre cuando los efectos de un fármaco se modifican por la presencia de otro (Bottorf, 2006). Las consecuencias pueden ser perjudiciales si la interacción causa un aumento de la toxicidad del fármaco o la disminución de su efecto, pudiendo provocar incluso la muerte del paciente, en los peores casos. En la actualidad existen bases de datos para comprobar posibles interacciones entre los fármacos administrados al paciente, pero el principal problema es que muchas de ellas tienen periodos de actualización de hasta tres años. Tratando de resolver este problema cabe destacar interesantes trabajos para obtener a través de técnicas de técnicas de minería de datos de forma automatizada aquella información que relacione interacciones farmacológicas como el desarrollado por Segura-Bedmar et al. (2010), basándose en otros trabajos como los de Rindflesch et al. (2000), Fickett & Hayes (2004) o Kolarik et al. (2007).

Sin embargo, el objetivo principal de los trabajos arriba mencionados es el de recopilar de forma automática aquellas interacciones farmacológicas existentes en la literatura médica, para modelar de esa forma una base de conocimiento que pueda ser usada más adelante en un sistema que pueda prevenir esas interacciones y así evitar los errores médicos que se producen durante la prescripción de medicamentos (Dean et al, 2002; Ammenwerth et al., 2008). En este aspecto, cabe destacar el trabajo realizado por Rodríguez et al. (2009) donde se describe un sistema de prescripción de medicinas basándose en Tecnologías Semánticas. El sistema es un CDSS donde el objetivo es tratar el problema de la recomendación de medicinas a un paciente basándose en tres criterios fundamentales: (1) medicamentos que se están consumiendo en la actualidad o que se han consumido en el pasado pero aún pueden estar presentes en el organismo del paciente, (2) alergias a fármacos o principios activos, (3) enfermedad a tratar.

En la misma rama de trabajos de relacionados con las medicinas cabe destacar también los análisis realizados sobre este tipo de sistemas como el realizado por Eslami et al. (2008) donde se analiza el efecto de los sistemas computarizados para la entrada de fármacos en sistemas hospitalarios o el realizado por Martens et al. (2008) donde se hace una revisión a los problemas encontrados por los médicos de medicina general a la hora de usar recordatorios automatizados para la recomendación de medicinas. Otro interesante artículo relacionado con esta parte de los medicamentos es el que fue llevado a cabo por Ess et al. (2003) sobre las políticas europeas a tener en cuenta a la hora de controlar la expedición de medicamentos, algo que debe ser extrapolado a los sistemas automáticos de recomendación.

En la misma temática de los medicamentos existen otros trabajos donde su principal objetivo es el manejo de las bases de datos de estos englobándolo en un CDSS. Ejemplos de estos trabajos son por ejemplo el de Bennet & Glasziou (2003) donde se hace una revisión sistemática de los sistemas informáticos para recordatorios y manejo de fármacos en entornos hospitalarios, o el realizado por Kilbridge & Classen (2001) donde se realiza un análisis de un modelo de procesos para el manejo de la medicación en entornos clínicos con el objetivo de mejorar la seguridad del paciente. Otro trabajo interesante es el desarrollado por Lai et al. (2007) donde se habla de un sistema usado para manejar las dosis de los medicamentos en pacientes con enfermedades crónicas.

También se deben destacar otros trabajos como el realizado por Weber et al. (2006) donde se realiza un estudio de la viabilidad de generar sistemas CDSS en arquitecturas SOA (Service Oriented Architecture). Otros trabajos, como el realizado por Wright & Stting (2008), hablan de un modelo en 4 fases en el que se pretende evolucionar las arquitecturas de los sistemas CDSS. Goud et al. (2008) desarrollan una guía sobre sistemas

10

de decisión donde se intenta explicar fácilmente los motivos de los razonamientos llevados a cabo por el mismo en la terapia de pacientes.

En otros trabajos el objetivo principal es el de mostrar aquellos retos que se plantean en estos sistemas, así como revisiones y evaluaciones de los mismos. En primer lugar se destaca el trabajo realizado por Broverman (1999) donde se desarrollan una serie de estándares a seguir en el desarrollo de sistemas CDSS. Algunos de los principales retos que existen en estos sistemas son descritos por Sittig et al. (2008). Kawamoto et al. (2005) realizan una revisión de los sistemas CDSS para identificar factores críticos que lleven a la consecución positiva a la hora de mejorar estos sistemas. Ruland & Bakken (2002) realizaron un trabajo donde se estudiaba el desarrollo, implementación y evaluación de los CDSS para toma de decisiones compartida en cuidados de pacientes. Finalmente, se destaca el trabajo de Miller (1994) donde se realiza una retrospección de los sistemas de diagnóstico médico, o el trabajo de Jhonston et al. (1994) donde se analizan los efectos de los CDSS en el personal clínico.

2.1.2. SISTEMAS DE SOPORTE LA DECISIÓN DE DIAGNÓSTICO (DDSS)

En la sección actual del presente documento se realiza un análisis de los sistemas de soporte a la decisión del diagnóstico (DDSS). En esta sección se muestran las referencias más importantes en la bibliografía técnica y médica. Dada la amplia variedad de sistemas de diagnóstico existentes, se realiza una división de la sección en dos partes. En primer lugar se tratarán los sistemas de diagnóstico de propósito general, los cuales no se centran en el diagnóstico de una enfermedad o conjunto de enfermedades concreto. En segundo lugar, se realiza un análisis de aquellos sistemas de diagnóstico específico, centrándose en los trabajos más relevantes sobre la temática citada.

2.1.2.1. DIAGNÓSTICO GENERAL

Existen diversos sistemas de diagnóstico de propósito general. Sin embargo, muchos trabajos realizados en esta disciplina se basan única y exclusivamente en aproximaciones o trabajos de investigación cuyo desarrollo, o bien no se ha llevado a cabo, o si se ha llevado no han tenido gran relevancia más allá de la publicación de la especificación del sistema.

En las siguientes líneas se van a mostrar en primer lugar aquellos sistemas que si han tenido un desarrollo real. Herramientas cuyo desarrollo, si bien en algunos casos ya ha cesado, en otros continua y es usado en entornos clínicos reales.

En segundo lugar se hablará de aquellos sistemas de diagnóstico que en la gran mayoría de los casos simplemente ha supuesto un trabajo de investigación concreto, no centrándose en el desarrollo del sistema con propósitos comerciales o de uso en entornos reales.

Dado que la temática principal de la presente tesis es hablar sobre la aplicación de estos sistemas de diagnóstico basados en Tecnologías Semánticas, e incluyendo la Inteligencia Artificial y algunas de sus técnicas como parte fundamental, también se va a realizar una retrospectiva de los principales trabajos de investigación sobre sistemas de diagnóstico diferencial en medicina (sistemas de diagnóstico de propósito general) dividiéndolos en diferentes áreas de Inteligencia Artificial, ya que generalmente se hace referencia a las Tecnologías Semánticas (concretamente a la Web Semántica) como una de estas tecnologías que se engloban dentro de la Inteligencia Artificial.

11

DXPlain

DXplain (Hupp et al., 1986; Barnett et al., 1987; Barnett et al., 1987; Cimino et al., 1987; Cimino et al., 1987; Packer et al., 1988; Elkin et al., 1989; Packer et al., 1989; Feldman et al., 1990; Feldman et al., 1990; Barnett et al., 1990; Barnett et al., 1991; Barnett et al., 1992; Hoffer, 1992; Barnett et al., 1996; Barnett et al., 1998; Bauer et al., 2002; Lasko et al., 2002) es un sistema de soporte a la decisión desarrollado en el Laboratorio de Informática en el Hospital General de Massachusetts. Tiene las características de un libro de texto electrónico de medicina y un sistema de referencia médico. En su modo de referencia o de análisis de casos, DXplain acepta un conjunto de indicios clínicos (signos, síntomas, datos de laboratorio) para producir una lista ordenada de diagnósticos los cuales pueden explicar (o ser asociados con) las manifestaciones clínicas. DXplain proporciona justificación de por qué las enfermedades son consideradas, y sugiere que información clínica adicional puede ser útil para cada enfermedad, mostrando una lista de manifestaciones clínicas (si existen) que suelen ser inusuales o atípicas para cada una de las enfermedades.

En el rol de libro de texto médico, DXplain puede proporcionar una descripción de alrededor de 2300 enfermedades distintas, haciendo énfasis en signos y síntomas que dan lugar a cada enfermedad, la etiología, la patología y la prognosis de cada una. DXplain también proporciona más de 10 referencias médicas relacionadas con la enfermedad. Además, DXplain puede devolver una lista de enfermedades las cuales deben ser consideradas para cada una de las cerca de 4900 manifestaciones clínicas diferentes existentes en el sistema (signos, síntomas y pruebas de laboratorio).

DXplain ha sido ampliamente usado desde aproximadamente 1993 y ha ido creciendo y evolucionando en este tiempo. Su desarrollo comenzó en 1984, y la primera versión, con información de aproximadamente 500 enfermedades fue lanzada en 1986. La distribución a nivel nacional del sistema con una base de datos de aproximadamente unas 2000 enfermedades comenzó en el año 1987 sobre la red AMANET. Después de que AMANET cerrase en 1990, DXplain continuó siendo distribuida sobre redes telefónicas hasta 1995. Entre 1991 y 1996 DXplain también se distribuyó como una versión autónoma que podía ser cargada en un ordenador personal. Desde 1996, gracias a la red Internet, DXplain ha reemplazado todos sus métodos previos de distribución por un servicio basado en Web.

La base de conocimiento actual de DXplain incluye alrededor de 2300 enfermedades y unos 4900 indicios clínicos (síntomas, signos, datos epidemiológicos y de laboratorio, e indicios radiológicos y endoscópicos). Las descripciones medias de enfermedades incluyen 53 indicios. Cada par "enfermedad-indicio" tiene dos números describiendo la relación: uno representando la frecuencia con la cual el indicio ocurre en la enfermedad, y el otro con el grado con el cual la presencia del indicio sugiere consideración de la enfermedad. Existen cerca de 230.000 pares de datos en la base de conocimiento que representan las relaciones enfermedad-indicio. Además, cada indicio tiene un término independiente asociado a la enfermedad para indicar como de importante es explicar la presencia del indicio. Cada enfermedad también tiene asociados dos valores: uno que es una aproximación de su prevalencia (muy común, común, raro o muy raro) y otro con su importancia ordenada entre 1 y 5 y que trata de reflejar el impacto de no considerar la enfermedad si está presente.

DXplain usa un formato interactivo para coleccionar la información clínica y hace uso de una forma modificada de la lógica bayesiana para dar lugar a las interpretaciones clínicas.

12

El sistema genera diagnósticos diferenciales ordenados usando un algoritmo pseudo-probabilístico. Cada indicio clínico introducido es evaluado determinando la importancia del indicio y como de fuerte es la representación del indicio de cara a realizar un diagnóstico para cada enfermedad en la base de conocimiento. Usando este criterio, DXplain genera diagnóstico ordenados con las enfermedades más probables. Además, con la información almacenada en el sistema acerca de la prevalencia y significancia de cada enfermedad, el sistema diferencia entre enfermedades comunes y raras.

En lo referido a la exactitud, en una investigación preliminar de 46 casos de benchmark con una variedad de enfermedades y manifestaciones clínicas, los diagnósticos generados por DXplain resultaron coincidir con los resultados provistos por cinco médicos (Feldman & Barnett, 1991). En otro estudio se investigó cómo de bien funcionaría el sistema de soporte a la decisión ante respuesta a un ataque de bioterrorismo. La evaluación de 103 casos consecutivos de medicina interna mostró que DXplain identificada el diagnóstico correcto en el 73% de los casos (Bravata et al., 2004).

A continuación se muestra una captura de pantalla del sistema en la Figura 1.

Figura 1. Captura de pantalla de DXPlain

El sistema ha sido usado por cientos de médicos y estudiantes de medicina desde que se publicó su primera versión. La base de datos y el sistema están siendo mejorados continuamente y adaptados como resultado de los comentarios de los usuarios. Actualmente, DXplain se usa rutinariamente en un determinado número de hospitales y escuelas médicas para educación clínica y como soporte educacional para solución de problemas clínicos.

Isabel

Isabel (Graber & Mathew, 2008) es un sistema de soporte a la decisión creado por la empresa Isabel Healthcare Inc., USA. Se trata de una aplicación Web encargada de generar posibles diagnósticos diferenciales en casos complejos de diagnóstico en adultos. En este caso, no hay demasiada información acerca de este software ya que no existe ninguna versión de prueba debido a que es una aplicación Web creada para uso interno de ciertos

13

centros médicos. Sin embargo, los pocos datos que se han podido recopilar muestran ciertas informaciones bastante interesantes, destacando el siguiente experimento:

Se realizó un experimento realizando 50 casos de prueba consecutivos donde cada caso consistía en introducir de 3 a 6 palabras clave de los indicios del caso, o pegar el historial clínico completo en el sistema. El investigador que introducía los datos en el sistema era consciente del diagnóstico correcto y cotejaba los datos mostrados por el sistema (una lista de 30 resultados posibles).

Los resultados obtenidos era que el sistema sugería un diagnóstico correcto en 48 de cada 50 casos (96%) introduciendo las palabras clave de los indicios encontrados y en 37 de cada 50 casos (74%) al introducir la historia clínica completa. Hablando de tiempos, el hecho de pegar la historia completa llevaba menos de un minuto (puesto que había que seleccionar las palabras clave) mientras que la introducción de las palabras clave llevaba apenas unos segundos. Con estos tiempos, luego, el sistema apenas tomaba en torno a 2-3 segundos con cada aproximación.

Acerca de su funcionamiento interno, como sistema de representación de la base de conocimiento o posibles sistemas de inferencia (si usa alguno) no hay ninguna información disponible.

DiagnosisPro

DiagnosisPro (Aronson, 1997) es sin duda uno de los software más completos de esta categoría de aplicaciones. Dicho software está desarrollado para ser utilizado en varios tipos de plataformas (Windows, Pocket PC y Web). Teniendo en cuenta esto se puede presuponer que su base de conocimiento a pesar de lo grande que debería ser para ser capaz de tratar los ámbitos de diagnóstico de medicina general no debe ser muy grande en tamaño (por ej., véase el caso de uso en PDAs, sistema que lleva ofreciendo desde hace varios años, incluso cuando las capacidades de estas eran más bien limitadas). Por otra parte, la velocidad a la que es capaz de obtener un diagnóstico es bastante alta, sobre todo en la versión testeada (Versión para Windows de DiagnosisPro 5.0).

En lo referido al almacenamiento de la base de conocimiento y su capacidad para llegar a un diagnóstico, no hay demasiada información al respecto de su funcionamiento, sin embargo, tras observar la versión que se ha podido testear se ha comprobado que simplemente parece tratarse de una aplicación la cual usa una base de datos en formato Access (MDB) donde almacena todos los indicios y relaciones entre ellos para mediante consultas en formato SQL poder llegar a arrojar un diagnóstico, dando a entender que no se utiliza ninguna técnica de Inteligencia Artificial concreta para la generación del mismo.

Una faceta importante de este software y que es diferenciadora y clave es el del uso del estándar ICD9 (ICD9, 2010) establecido por la OMS como sistema de representación del conocimiento.

Otro aspecto a tener en cuenta de este software es que la usabilidad de la interfaz, al menos en la versión testeada es bastante precaria, debido a que no es nada intuitiva ni atractiva para el usuario, como se puede ver en la Figura 2.

14

Figura 2. Captura de pantalla de DiagnosisPro

DiagnosMD

DiagnosMD es un software español cuyo objetivo es facilitar información útil de aplicación inmediata en la práctica clínica debido a que el caudal de conocimientos que genera la medicina resulta prácticamente imposible de mantener y manejar en la memoria humana.

La Figura 3 muestra la arquitectura del sistema:

Figura 3. Motor de inferencia de DiagnosMD

Según la información disponible, el borrosificador hace uso de funciones de pertenencia de varios tipos (singleton, triangulares, gaussianas, trapezoides y trapezoides extendidas), todas las funciones son normalizadas en los dos ejes.

En DiagnosMD están definidas variables lingüísticas con valores posibles de nulo, muy bajo, bajo o leve, normal, ligeramente alto, alto y muy alto, así como variables numéricas (especialmente para resultados analíticos; si bien pueden expresarse estos como ausencia, muy bajo, bajo, normal, alto o muy alto).

15

La base de conocimientos consta de 1.390.000 reglas (IF-THEN) donde la mayoría son paralelas (no encadenadas) con implicaciones, siguiendo un formato de reglas clásico.

El motor de inferencia ejerce las acciones con reglas difusas multiantecedente usando funciones de t-norma, implicaciones y operadores de agregación (especialmente WOWA ya que pondera tanto las variables como los valores de datos, sobre todo los resultados numéricos analíticos, aunque también es usado el WOWA lingüístico). Es de destacar que el peso de las variables del caso introducido puede ser variado por el usuario para cada dato clínico que introduzca (valor normal, poco relevante, relevante o que debe estar definido [debe cumplirse]).

El desborrosificador presenta varios resultados:

Enfermedades posibles con una aproximación del valor difuso de pertenencia del caso clínico introducido y calculado por el motor de inferencia con el uso de la base de conocimiento. Existe una discriminación en el desborrosificador que mejora los resultados presentados.

Petición de nuevas variables, tanto para descartar (eliminando enfermedades), como para aumentar el grado de pertenencia. DiagnosMD da a elegir al clínico alguna de las nuevas entradas (según el caso, una vez conectada el sistema vuelve al motor de inferencia ofreciendo nuevos resultados por lo que es realmente un sistema interactivo que presenta preguntas distintas según cada caso).

Elección de peticiones de interés (analíticos, Rx,..) para ayudar en el diagnóstico.

El universo que trata es el conjunto de todas las enfermedades.

Como todo sistema experto, DiagnosMD tiene sus restricciones, y sólo sirve para pacientes que presentan una enfermedad, y no sirve para ayudar a diagnosticar varias enfermedades a la vez, de todas formas el clínico puede introducir solo los datos relevantes de la enfermedad que pretende diagnosticar, basándose en su intuición.

Tampoco son incluidos en el motor de inferencia los efectos secundarios de los fármacos, si bien son manejados en la base de conocimientos de DiagnosMD en la consulta de fármacos.

En DiagnosMD se están aumentando el número de reglas de la base de conocimientos, así como la elección cada vez más refinada de las reglas utilizadas en el motor de inferencia (es un sistema actualizable).

La Figura 4 muestra la interfaz del sistema cuando se va a realizar un diagnóstico diferencial:

16

Figura 4. Captura de pantalla de DiagnosMD

Otras de las utilidades de DiagnosMD que caben destacar son las siguientes:

Consulta de enfermedades Consulta de dietas Consulta de protocolos de urgencias Alertas de fármacos Informes de toxicología Consulta de plantas medicinales Influencia de fármacos en clínica

Uno de los aspectos más a tener en cuenta de dicho software es que parece resolver la hipótesis H2 planteada en la presente tesis, la cual permite realizar diagnóstico de enfermedades cuya entidad está formada por signos/síntomas y otras enfermedades. Sin embargo, los autores afirman que aunque solventa este problema, existen ciertos diagnósticos (como por ejemplo el del Cólera) que solo son mostrados cuando se introduce que se ha estado en un país endémico de la enfermedad, de lo contrario, no son mostrados. Esto supone una pequeña falla en el sistema de diagnóstico, dado que, si bien es cierto que existen enfermedades que son endémicas de una zona y por lo tanto más probables de adquirirlas si se ha estado en dicha zona, también se puede dar casos de contagios de personas que no han estado en dichas zonas, pero si pueden haber estado directa o indirectamente con personas que si hayan estado, y por lo tanto hayan adquirido la enfermedad.

MYCIN

MYCIN fue uno de los primeros sistemas expertos desarrollado a principios de los años 70 en la Universidad de Stanford, con una duración estimada de su desarrollo de entre 5 y 6 años. Fue escrito en el lenguaje de programación LISP como la tesis doctoral de Edward Shortliffe bajo la dirección de Buchanan, Cohen y otros. Surgió en el laboratorio que había creado el sistema experto Dendral (Lederberg, 1987; Robert et al., 1980; Robert et al., 1993), pero centrándose en el uso de reglas críticas que tenían elementos de

17

incertidumbre (conocidas como factores de certidumbre) asociados con las reglas. Este sistema experto fue diseñado para identificar las bacterias que causaban diversas infecciones, como la bacteriemia y la meningitis y recomendar antibióticos con la dosis ajustada al peso del paciente. El nombre del sistema deriva de los antibióticos en sí mismo, debido a que muchos antibióticos tienen el sufijo "-mycin". El sistema MYCIN también fue usado para el diagnóstico de enfermedades relacionadas con la coagulación de la sangre.

MYCIN funcionaba usando un motor de inferencia bastante simple y una base de conocimiento de aproximadamente 600 reglas. El sistema realizaba preguntas al médico a través de una larga serie de preguntas simples cuya respuesta era sí o no. Al final de la ejecución, el sistema devolvía una posible lista de bacterias "culpables" ordenadas de mayor a menor basándose en la probabilidad de cada diagnóstico, la confianza de probabilidad de cada diagnóstico, el razonamiento que estaba detrás de cada diagnóstico y la recomendación de medicinas asociada.

A pesar del éxito de MYCIN, este hizo que estallara el debate acerca de su uso para el problema al que fue diseñado (diagnóstico) debido a los factores de incertidumbre. Los desarrolladores crearon estudios mostrando que el rendimiento de MYCIN era mínimamente afectado por las perturbaciones que surgían de la incertidumbre asociadas con las reglas, sugiriendo que el poder del sistema estaba más relacionado con su representación del conocimiento y esquema de razonamiento, en vez de con los detalles de su modelo de incertidumbre. Algunos observadores afirmaban que debería haber sido posible usar estadística bayesiana, aunque los desarrolladores de MYCIN argumentaron este problema en detalle en su artículo donde introducían los factores de certidumbre (Shortliffe & Buchanan, 1975), y nuevamente de forma extensa en su libro basado en MYCIN y experimentos relacionados (Shortliffe, 1984).

En lo referido a su exactitud, la investigación llevada a cabo en la escuela médica de Stanford reveló que MYCIN proponía una terapia aceptable en aproximadamente el 69% de los casos, porcentaje que fue mejor que el rendimiento que los expertos que lo juzgaron obtuvieron usando el mismo criterio. Este estudio es a menudo citado para mostrar el potencial de desacuerdo acerca de los sistemas terapéuticos de decisión, incluso entre expertos, cuando no hay un estándar para el tratamiento correcto (Yu et al., 1979).

A pesar de la gran investigación proporcionada por MYCIN, nunca fue usado en la práctica. El motivo no fue por ninguna debilidad en su rendimiento, como se ha mencionado en los test realizados por los miembros de la escuela médica de Stanford. Algunos observadores argumentaron problemas éticos y legales relacionados con el uso de ordenadores en la medicina (si un programa proporciona un diagnóstico incorrecto o recomienda una terapia incorrecta, ¿quién sería responsable?). Sin embargo, el mayor problema, y la razón por la que MYCIN no ha sido usado en la práctica clínica rutinaria, fue el estado de las tecnologías para la integración del sistema, especialmente en la época en la que fue desarrollado. MYCIN era un sistema autónomo que requería de un usuario que introdujera toda la información relevante sobre un paciente respondiendo a preguntas que el propio sistema realizaría al usuario. El programa corría en un gran sistema de tiempo compartido, el cual estaba disponible a través de lo que era la reciente Internet (ARPANet), antes de que los ordenadores personales fueran desarrollados. En la era moderna, un sistema como este podría ser integrado con sistemas de datos médicos de forma que extrajera las respuestas a sus preguntas a partir de bases de datos de pacientes y sería mucho más dependiente de la entrada de información que debía proporcionar el médico. En los años 70, una sesión con MYCIN podía consumir fácilmente 30 minutos o más, un tiempo inadmisible.

La mayor influencia de MYCIN fue por consiguiente su demostración del poder de su representación y razonamiento. Varios sistemas basados en reglas fueron desarrollados en

18

dominios no relacionados con la medicina en los siguientes años desde la introducción de MYCIN.

Caduceus

CADUCEUS (Banks, 1986; First et al., 1985) fue un sistema experto médico finalizado hacia la mitad de los años 80 (se comenzó su desarrollo en los años 70 pero llevo una gran cantidad de tiempo construir su base de conocimiento). Su creador fue Harry Pople de la universidad de Pittsburgh y fue construido tras varios años realizando entrevistas con el Dr. Jack Meyers, uno de los mejores médicos especialista en diagnóstico y profesor en la universidad de Pittsburgh. Su motivación fue un intento de mejorar MYCIN, el cual se centraba en el diagnóstico de enfermedades de transmisión sanguínea causadas por bacterias, para centrarse en problemas más exhaustivos que un campo como el del envenenamiento sanguíneo.

Mientras que CADUCEUS trabajaba usando un motor de inferencia similar al de MYCIN, este realizaba una serie de cambios (como incorporar razonamiento abductivo) para tratar con la complejidad adicional de los diagnósticos en medicina interna, donde puede haber un gran número de enfermedades simultaneas y los datos son generalmente defectuosos y escasos.

CADUCEUS ha sido descrito como el sistema experto con más conocimiento intensivo existente (Feigenbaum & McCorduck, 1984).

Internist-I

Internist-I (Pople, 1976; Myers et al., 1982; Miller, 1982; Myers, 1990) fue una amplia herramienta de diagnóstico asistida por ordenador desarrollada a principio de los años 70 en la universidad de Pittsburgh como un experimento educacional. El sistema, relacionado con CADUCEUS, fue diseñado para capturar el expertise nuevamente del Dr. Jack D. Myers, médico y presidente de medicina interna en la escuela de medicina de la universidad de Pittsburgh. La división de recursos de investigación y la librería nacional de medicina fundaron Internist-I. Otros grandes colaboradores del proyecto incluyen Randolph A. Miller, Harry E. Pople y Victor Yu.

Internist-I es el sucesor del sistema DIALOG. Durante diez años, Internist-I fue la pieza central de un curso de la universidad de Pittsburgh llamado "La lógica de solventar problemas en diagnóstico clínico". En consulta a expertos facultativos, la alta responsabilidad de entrada y actualización de datos del sistema recayó sobre los alumnos de cuarto año de medicina matriculados en el curso. Dichos estudiantes codificaban los indicios de informes estándar clinicopatológicos. En 1982, el proyecto Internist-I abarcaba 15 personas por año de trabajo, y alguno de sus informes abarcaba en torno a un 70-80% de todos los posibles diagnósticos en medicina interna.

Los datos de entrada del sistema a través de operadores incluían signos y síntomas, resultados de laboratorio y otros elementos de la historia del paciente. Los principales investigadores de Internist-I no siguieron los diseños de otros sistemas expertos médicos, no adoptando modelos de estadística bayesiana o reconocimiento de patrones. Esto fue porque, como Myers explicó: "El método usado por los médicos para llegar al diagnóstico requiere procesamiento de información compleja la cual tiene poco parecido con las manipulaciones estadísticas de la mayoría de los sistemas informáticos". Internist-I por el contrario usaba un poderoso algoritmo de clasificación para llegar a diagnósticos en el dominio de medicina interna. Las reglas heurísticas que manejaban Internist-I confiaban en un algoritmo de particionamiento para crear áreas de problemas y funciones de exclusión para eliminar posibilidades de diagnóstico.

19

A finales de los años 70, Internist-I fue usado experimentalmente como programa de consultas y generador de preguntas con propósito educacional en el hospital presbiteriano universitario de Pittsburgh. Los diseñadores de Internist-I esperaban que el sistema pudiera llegar algún día a ser útil en entornos remotos (áreas rurales, fuera del espacio o en bases militares extranjeras, por ejemplo), donde se careciera de expertos.

Una consulta media al sistema Internist-I requería entre 30 y noventa minutos, lo cual era demasiado tiempo para la mayoría de los clínicos. Para solventar este problema, los investigadores de la universidad de Carnegie-Mellon escribieron un programa llamado ZOG que permitía a aquellos que no estaban familiarizados con el sistema, aprender a usarlo más rápidamente.

En la primera versión de Internist-I (completada en 1974) el programa de ordenador trataba al médico como incapaz de resolver un problema de diagnóstico o como un observador pasivo que únicamente realizaba entrada de datos. Miller y sus colaboradores vieron esta función como una responsabilidad en los años 80, refiriéndose a Internist-I con sorna como un ejemplo desfasado del modelo "Greek Oracle" para sistemas expertos médicos. A mitad de los años 80 se finalizó el desarrollo de Internist-I como un poderoso consultorio basado en computadores en la Universidad de Pittsburgh llamado Quick Medical Reference (QMR). QMR, con la intención de corregir las deficiencias tecnologías y filosóficas de Internist-I, aún sigue dependiendo de muchos de los algoritmos desarrollados para Internist-I, y a menudo se refieren a ambos sistemas como Internist-I/QMR. Los principales competidores de este sistema incluyen a CASNET, MYCIN y PIP.

QMR

QMR (Miller, 1986a; Miller, 1986b; Miller, 1989; De Bliek, 1990; Linton, 1993) son las siglas de Quick Medical Reference. Proyecto nacido a partir de INTERNIST-I, pero desarrollado fuera de su ámbito, es un recurso de información en profundidad que ayuda a los médicos a diagnosticar enfermedades de adultos. Provee acceso electrónico a más de 750 enfermedades que representan la gran mayoría de los desórdenes que suelen ver los médicos internos en su práctica diaria, así como un compendio de las enfermedades menos comunes.

QMR usa más de 5000 indicios clínicos para describir las características de las enfermedades en la base de conocimiento del sistema. Los indicios incluyen historial médico, síntomas, signos físicos y resultados de pruebas de laboratorio. Los resultados de las pruebas de laboratorio se dividen en tres categorías basándose en los niveles de dificultad de la misma y lo invasivos que son. Los indicios de QMR representan situaciones anormales, como por ejemplo "Dolor abdominal severo" o "Virus de la Hepatitis B por reacción en cadena de la polimerasa".

Cada perfil de la enfermedad incluido en la base de conocimiento es el resultado de una extensa revisión de la literatura médica primaria. Las consultas con expertos son usadas para resolver cualquier inconsistencia o deficiencias encontradas en los informes publicados. QMR es usado en la práctica en hospitales y oficinas.

Iliad

Iliad (Warner et al., 1988; Diamond, 1991; Bergeron, 1992) es un sistema experto médico usado por especialistas de la salud para proporcionar consultas expertas sobre diagnóstico y simulación de pacientes. Su desarrollo comenzó en la escuela de medicina, en el departamento de informática médica de la universidad de Utah. La versión 4.5 cubre más de 930 enfermedades y 1500 síndromes y proporciona protocolos de tratamiento para cada una (aunque las versiones más recientes se afirma que cubre más de 1.500

20

enfermedades). Además, el sistema de codificación usado es el estándar ICD-9 de la OMS. Existen más de 13.900 manifestaciones de enfermedades cubriendo temas en medicina interna, medicina deportiva, pediatría, dermatología, psiquiatría, ginecología/obstetricia, enfermedades vasculares periféricos y trastornos del sueño. Iliad actúa como un consultorio experto que proporciona un diagnóstico diferencial, o actúa como una segunda opinión, para criticar un supuesto diagnóstico. El programa también incluye 90 casos de pacientes simulados que pueden ser usados para realizar pruebas de diagnóstico.

En lo referido a su representación del conocimiento o inferencia, Iliad usa razonamiento bayesiano para calcular las probabilidades posteriores de varios diagnósticos que estén bajo consideración dependiendo de los indicios implicados.

El principal propósito de dicho software sin embargo parece estar más destinado al entrenamiento de los futuros médicos mediante la simulación de enfermedades para que los alumnos puedan tratar de resolver el problema de diagnóstico (Cundick et al., 1989; Lincoln et al., 1991).

VisualDx

VisualDx (Goldsmith, 2005; Tleyjeh et al., 2006) es un sistema que hoy en día se utiliza fundamentalmente para el diagnóstico de casos dermatológicos. Sin embargo, dada la gran cantidad de módulos que se han ido incorporando y opciones que baraja se le incluye dentro de los sistemas cuyo propósito es el diagnóstico general.

VisualDx basa su funcionamiento en la argumentación de que los sistemas de soporte a la decisión clínicos típicos requieren que el usuario use campos de texto para escribir síntomas o indicios de los pacientes. Los propios autores argumentan, que esto puede crear problemas si los usuarios no están familiarizados con la terminología correcta que se use dentro del software y por lo tanto, VisualDx resuelve este problema creando una interfaz gráfica donde se introducen los síntomas de forma visual y por lo tanto ayudando a los usuarios de forma rápida a responder la pregunta “¿Qué es esto?”.

Este sistema fue desarrollado en un principio por imágenes para condiciones dermatológicas tipo pediátrico, adulto, y geriátrico, las cuales pueden ser notoriamente difíciles de diagnosticar para aquellos que no sean especialistas en dermatología.

Un artículo encontrado en 1999 encontró diferencias significativas en los problemas de diagnóstico de los dermatólogos (93% correctas), comparadas con los diagnósticos realizados por los médicos de atención primaria (52% correctas), cuando veían imágenes de las enfermedades de piel más comunes en dermatología (Federman et al., 1999). VisualDx por lo tanto fue diseñado para reunir las necesidades de los usuarios que no están acostumbrados a ver manifestaciones dermatológicas a diario: médicos de atención primaria, médicos de urgencias, dentistas, especialistas en enfermedades infecciosas y trabajadores sanitarios.

Desde entonces, el producto se ha expandido para incluir módulos en lesiones orales (Torres-Urquidy & Collins, 2006), infecciones pulmonares y reconocimiento de terrorismo entre otros. En total, la base de conocimiento se compone de 21 módulos que contienen más de 14.000 imágenes que se relacionan con cerca de 800 enfermedades. Esto incluye más de 1.700 imágenes de recursos dermatológicos de enfermedades en personas de piel oscura. Las imágenes provienen de variedad de fuentes, incluyendo archivos de universidades e industrias. Además, cada condición tiene asociado un monográfico que incluye pruebas y tratamientos. Estos textos sin referencias provienen de libros de texto, artículos de revistas y expertos médicos.

21

En lo que se refiere a su acceso, VisualDx es una aplicación basada en Java y se puede acceder a ella a través de una aplicación Web. La elección de acceso dependerá de las necesidades de la institución y de sus recursos.

Desde el punto de vista de su funcionamiento, cuando un usuario se conecta por primera vez al sistema, este le mostrará la pantalla introductoria donde podrá ver la lista de los módulos existentes. Estos módulos simplifican el proceso de navegación de la base de datos ofrece opciones de búsqueda personalizada según el contenido. La interfaz de búsqueda gráfica puede ser omitida si se conoce el diagnóstico introduciéndolo directamente en el campo de texto de búsqueda. Si no, el módulo adecuado lo elegirá basándose en los indicios encontrados en el paciente. En las situaciones en las que la elección del módulo no sea clara, existe una utilidad para ayudar a seleccionar aquel que el sistema considere más oportuno.

En el ejemplo al que se ha podido acceder para la realización de esta tesis (Skhal & Koffel, 2007), se parte de un paciente de piel clara, mujer, y adulta, que presenta pápulas suaves y eritema en cara y manos y además ha perdido peso. Después de seleccionar un módulo (en este caso sarpullidos de adulto), el primer paso es indicar el tipo de lesión. En vez de usar simplemente un texto descriptivo, VisualDx ofrece una imagen con varias ilustraciones de diferentes tipos de lesión (ver Figura 5). En este caso, se escoge pápula suave y eritema (smooth papule and erythema).

Figura 5. Ejemplo de diálogo del sistema VisualDx

El siguiente paso es seleccionar la distribución del sarpullido. Justo igual que con el tipo de lesión, VisualDx muestra imágenes de diferentes patrones de distribución y permite al usuario seleccionar entre patrones extensivos y limitados. Desafortunadamente, el esquema de color escogido para mostrar esta información puede hacer que el patrón sea difícil de distinguir en algunos monitores (problemas de usabilidad).

El paso final es introducir cualquier otro indicio o síntoma. Estos pueden ser seleccionados de una lista jerárquica en el menú de indicios o tecleados en el campo

22

llamado "Introduzca indicios". Las opciones aquí son extensas e incluyen historias médicas, de medicinas e históricas, así como indicios físicos, de laboratorio, o de imágenes.

Una vez el tipo de lesión, distribución e indicios han sido introducidos en el sistema, VisualDx muestra imágenes de diagnósticos potenciales ordenados según el número de criterios que coinciden.

eMedicine

La página Web eMedicine (eMedicine, 2011) ofrece como servicio la posibilidad de realizar diagnósticos diferenciales sencillos. La interfaz ofrece una serie de campos de texto donde se pueden introducir palabras clave que se refieran a indicios médicos y unirlos mediante conectivas AND u OR para obtener un diagnóstico.

Es una herramienta la cual, por la forma en la que se introducen los datos, parece que su funcionamiento se basa en una consulta en SQL contra una base de datos en busca de las tuplas resultantes. Es una herramienta muy rudimentaria ya que solo permite dos parámetros clínicos como son los signos/síntomas y las pruebas de laboratorio, si bien es cierto que estos dos parámetros son los más importantes.

La Figura 6 se muestra una captura de pantalla del sistema:

Figura 6. Captura de pantalla de eMedicine

PAIRS

PAIRS (Physician assistant Artificial Intelligence System) es un sistema de diagnóstico diferencial diseñado para ayudar a los médicos en el diagnóstico de casos difíciles. En Octubre de 2003 se empezó a testear en la práctica clínica en Hyderabad (India) con la intención de realizar su lanzamiento comercial en Enero de 2004. Sin

23

embargo, no existen referencias algunas a que el proyecto fuera lanzado en esa fecha o esté actualmente en uso.

El sistema PAIRS está basado en los métodos variacionales de inferencia eficiente en modelos probabilísticos a gran escala desarrollados por Jaakkola & Jordan (1999). PAIRS trabaja con una gran base de datos con más de 30.000 características de enfermedades y 620 enfermedades de medicina interna. Cada característica está cuantificada en base a su fisiología, incidencia de la enfermedad y posibilidad de que sea causada por otra enfermedad que no esté en la lista. PAIRS incluye una lista de 7282 enfermedades, alrededor de 10.000 características y 415.000 enlaces a dichas características. La base de conocimiento clínica ha sido creada a partir de textos estándar y revisiones de revistas durante los últimos años, desde 1995 hasta 2003. El sistema permite acceder a las características de las enfermedades, enfermedades, enlaces o realizar un diagnóstico desde la interfaz.

Una característica importante del sistema es que puede proporcionar un diagnóstico para datos de pacientes que incluyan alrededor de 50 indicios. La exactitud de PAIRS se comprobó a partir de los datos de pacientes de los 340 casos del hospital general de Massachusetts publicados en el New England Journal of Medicine. Algunos de los casos de prueba tienen un gran número de características, lo que es un factor limitante para los sistemas de Inteligencia Artificial basados en redes probabilísticas bayesianas. Sin embargo, PAIRS puede lidiar con datos de pacientes de gran tamaño realizando inferencias parciales. Un diccionario personalizado y una interfaz de procesamiento de lenguaje natural hacen la entrada de datos del paciente totalmente compatible con la base de datos del sistema. Esta interfaz genera un conjunto de palabras a partir de traducciones de los términos médicos procedentes del griego y el latín y encuentra sus sinónimos y antónimos equivalentes antes de buscar en la base de datos.

La Figura 7 muestra una captura de pantalla del sistema:

Figura 7. Captura de pantalla de PAIRS

CADIAG

CADIAG-2 (Adlassnig et al., 1985) es un sistema experto médico basado en la representación lógica simbólica de las relaciones médicas. Las relaciones fuertes como las de confirmación, exclusión u obligatoriedad de ocurrencia son aplicadas para confirmar o excluir diagnósticos. CADIAG-2, se basaba en teoría de conjuntos difusos y lógica difusa, la

24

cual permitía una especificación detallada de las relaciones médicas. En este sistema el proceso de diagnóstico también permitía confirmar y excluir diagnósticos así como hipótesis de diagnóstico. Las hipótesis son calculadas considerando las relaciones difusas entre las entidades médicas. Se probaron 426 casos con enfermedades reumáticas y 47 con enfermedades pancreáticas. Para el sistema CADIAG-2 la eficiencia/exactitud general del sistema para confirmación y generación de hipótesis daba como resultado un 91.1% para las enfermedades reumáticas y 100% para las pancreáticas. CADIAG-2 obtenía una exactitud del 93.7% para las enfermedades reumáticas y 91.5% para las pancreáticas. Un interesante artículo sobre este sistema es el realizado por Klinov et al. (2010), donde se realiza una evaluación de la consistencia de su motor probabilístico interno.

MDX

El sistema de soporte a la decisión de diagnóstico MDX (Grams et al., 1996) contiene multitud de hechos clínicos que han sido reportados en variedad de libros de texto médicos y revistas médicas de carácter internacional. La base de datos fue diseñada a medida para el proceso de diagnóstico médico y esta consistía en enfermedades, condiciones, sustancias químicas, medicinas y toxinas que eran conocidas como causa de enfermedades. Cada elemento causal tenía asociado un fichero para signos, síntomas e indicios. Esta fuente de conocimiento médico usada en MDX provenía del mundo de los expertos de la misma forma en la que ellos transmitían su experiencia en la palabra escrita a través de de libros y revistas.

GIDEON

GIDEON (Berger, 2000) es un programa de ordenador para diagnóstico y referencia en el campo de enfermedades infecciosas tropicales, epidemiología, microbiología y terapia farmacéutica antimicrobial. A pesar de no ser un sistema de propósito general puro, al englobar enfermedades infecciosas nada más, es incluido en este apartado dado que su especificad aun así abarca un gran abanico de enfermedades. El sistema fue diseñado para diagnosticar todas las enfermedades infecciosas basándose en síntomas, signos, pruebas de laboratorio y perfiles dermatológicos. La red (de tipo bayesiano) de enfermedades infecciosas de GIDEON centra una especial atención al país de origen. La base de datos incluye 327 enfermedades, 205 países, 806 taxones bacteriológicos y 185 agentes antibacterianos. GIDEON se compone de cuatro módulos básicos:

1. Diagnóstico: El módulo de diagnóstico de GIDEON permite al usuario acceder a todos los parámetros epidemiológicos, indicios clínicos, pruebas de diagnóstico y terapias. El módulo controla datos en condiciones totalmente desconocidas para la mayoría de los médicos que no pertenezcan al país donde la enfermedad pueda ser endémica. Después de especificar el país donde se sospecha que se pudo contraer la enfermedad y la lista de signos y síntomas del paciente, el sistema GIDEON proporciona una lista de diagnósticos ordenada según su probabilidad. Para cada enfermedad de la lista, el usuario puede obtener hechos importantes como sus perfiles clínicos y epidemiológicos, su estado en el país, etc.

2. Módulo epidemiológico: Con el módulo epidemiológico de GIDEON el usuario puede obtener una serie de parámetros epidemiológicos de enfermedades, acceder al estado de cualquier enfermedad en el país actual, obtener una lista de la distribución alrededor del mundo, revisar el estado de la enfermedad actual en cualquier país y la posibilidad de acceder a una lista de nombres alternativos para una enfermedad dada.

3. Módulo terapéutico: Este módulo proporciona información detallado acerca de las posibles elecciones en la terapia con medicamentos,

25

incluyendo susceptibilidad, toxicidad y datos de interacción entre medicamentos, no solo en los antimicrobiales comunes, sino también en algunos más atípicos.

4. Módulo de microbiología: Con propósitos de identificación y caracterización, el módulo microbiológico proporciona una lista completa de características de laboratorio que incluye resultados a pruebas bioquímicas y características culturales para al menos 900 organismos. Con este módulo, el usuario puede identificar y comparar organismos a través de una enciclopedia de información, toda ella integrada en una sola fuente.

Otros DDSS Aplicando Inteligencia Artificial

En las secciones previas se han definido una serie de sistemas de tipo DDSS donde la aplicación de técnicas de Inteligencia Artificial resultaba patente. El hecho de que estos sistemas hayan sido mencionados dedicándoles su propia subsección se debe fundamentalmente a la repercusión de los mismos. Mientras que los sistemas que se definirán a continuación apenas han tenido una repercusión académica o investigadora, los mencionados previamente han sido en más de un caso los pilares fundamentales de este tipo de sistemas, y de ahí que se les haya dedicado una subsección a cada uno de ellos.

Por lo tanto en los siguientes párrafos se definen otros sistemas del mismo tipo que también aplican técnicas de Inteligencia Artificial pero donde su impacto ha sido de menor envergadura.

Redes Probabilísticas

A continuación se van a mencionar los diversos trabajos relacionados con la temática de la tesis que usen estas técnicas. Algunos de ellos hacen estudios sobre varias técnicas de ingeniería del conocimiento para la construcción de este tipo de sistemas cuando la información numérica disponible es incompleta o parcialmente correcta, situación la cual a menudo ocurre cuando los estudios epidemiológicos publican solamente estadísticas indirectas y cuando las dependencias condicionales existen en el dominio del problema (Nikovski, 2000).

También existen artículos que se centran en mostrar las objeciones que suelen aparecer con más frecuencia en la comunidad relacionada con la Inteligencia Artificial en medicina. En particular, se centran en mostrar que las asunciones de independencia requeridas para realizar estadística bayesiana computacional fiable no están tan cercanas de dañar como se ha intentado reclamar. Además, argumentan que la estadística bayesiana es perfectamente compatible con las soluciones heurísticas para problemas de múltiples enfermedades (Charnaik, 1983).

Existen trabajos donde se muestran propuestas basadas en redes bayesianas como el introducido por Arroyo-Figueroa & Sucar (2005) donde se introduce el concepto de representación llamado redes bayesianas de nodos temporales. En este tipo de redes cada nodo representa un evento o cambio de estado debido a una relación casual-temporal. El intervalo temporal puede diferir en número y tamaño para cada nodo temporal, permitiendo de esta forma granularidad múltiple. Esta aproximación es contrastada contra una red bayesiana dinámica para un ejemplo médico simple.

Ganeshan et al. (2000) presentaron una aproximación para la solución de tutorizar problemas de diagnóstico que usa conocimiento sobre relaciones casuales entre síntomas y estados de enfermedades para conducir un dialogo pedagógico con el estudiante. Un agente pedagógico animado llamado Adele usaba el conocimiento causal representado como una red bayesiana para generar de forma dinámica un proceso de diagnóstico que es

26

consistente. Usando una combinación de pistas y otras interacciones basadas en preguntas de respuesta múltiple, Adele guía al estudiante a través del proceso de razonamiento que existe bajo su conocimiento subyacente.

En el trabajo realizado por Kononenko (1993) se realizan dos aproximaciones de aprendizaje inductivo y bayesiano para el diagnóstico en medicina. Se parte del hecho de que a pesar del gran éxito de los sistemas de solución a los problemas de diagnóstico médico, los sistemas de aprendizaje inductivo no han sido ampliamente aceptados en la práctica médica. En este trabajo se comparan dos aproximaciones diferentes de aprendizaje automático en aplicaciones médicas: el sistema de aprendizaje inductivo de asistente de árboles de decisión y el clasificador bayesiano simple. Ambas metodologías fueron testeadas en cuatro problemas de diagnóstico médico: localización de un tumor primario, pronóstico de cáncer de mama recurrente y diagnóstico de enfermedades de la tiroides y reumatología. La eficiencia del conocimiento de diagnóstico adquirido automáticamente a partir de datos ya existentes en registros es comparada, y la interpretación del conocimiento y la habilidad del proceso de clasificación de cada proceso son discutidas. Los resultados a los que se llega sorprenden al autor, ya que el clasificador bayesiano simple es superior al asistente en eficacia de clasificación y habilidad para explicar los resultados, mientras que la interpretación del conocimiento adquirido parece ser similar. Además, se describen brevemente dos extensiones del clasificador bayesiano: trabajando con atributos continuos y descubriendo dependencia entre atributos.

Lógica Fuzzy

La lógica fuzzy o lógica difusa es una de las técnicas de Inteligencia Artificial que está abarcando una gran cantidad de campos de aplicación en los últimos años. Dada su capacidad para modelar aquellos aspectos de la lógica que no se definen entre dos únicos valores como verdadero y falso, abre un amplio abanico de posibilidades, y más en el campo del diagnóstico diferencial donde en ocasiones la incertidumbre sobre un determinado diagnóstico es patente.

En el trabajo presentado por Chen (1994), se presenta un algoritmo de razonamiento difuso basado en pesos para manejar los problemas de diagnóstico médico, donde la teoría de conjuntos difusos y reglas de producción difusas son usadas para la representación del conocimiento. El algoritmo puede realizar correspondencias difusas entre las manifestaciones de síntomas del paciente y las partes de antecedente de las reglas de producción difusas para determinar la presencia de enfermedades, donde el resultado es interpretado con un determinado nivel indicando el grado de seguridad de la presencia de la enfermedad. Dado que el algoritmo permite a cada síntoma en el diagnóstico médico tener un diferente grado de importancia, es más flexible que otras soluciones. Por otra parte, el algoritmo propuesto por Chen afirma poder ser ejecutado de forma muy eficiente. Si la base de conocimiento contiene n reglas de producción difusas y existen p síntomas, la complejidad temporal del algoritmo pasa a ser O(np).

Un trabajo más reciente lo podemos encontrar en el trabajo de De Maio et al. (2011) con la aplicación de conocimiento difuso para diagnóstico automático de enfermedades.

Algoritmos Genéticos

Otro de los campos más interesantes de la Inteligencia Artificial, dentro de su rama de computación biológica o evolutiva es el de los algoritmos genéticos. Este tipo de técnica es muy útil en gran variedad de problemas de todo tipo. Sin embargo, debe tenerse en cuenta que dada la problemática de la eficiencia y precisión de los datos, este tipo de técnicas no suelen ser muy populares y usadas, dado que es difícil que puedan generar resultados con la suficiente fiabilidad. Es por eso que los trabajos en esta rama sean más

27

bien escasos (véase Anastasio et al. (1998); Vinterbo & Ohno-Machado (2000); Garrell i Guiu et al. (1999)) y estén muy orientados a problemas concretos y no existan esfuerzos por la generación de sistemas de propósito general que hagan uso de estas técnicas.

Redes Neuronales

Las redes de neuronas son consideradas otro de los grandes pilares de la Inteligencia Artificial junto con los algoritmos genéticos, englobadas también dentro del mismo grupo que estos últimos (evolutivos). Debido nuevamente al igual que los algoritmos genéticos a la problemática de la eficiencia y precisión de los datos, este tipo de técnicas no suelen ser muy populares y usadas, dado que es difícil que puedan generar resultados con la suficiente fiabilidad, y es por lo tanto difícil encontrar estudios. Sin embargo, existen algunas aproximaciones, sobre todo basadas en el aprendizaje de las redes para poder realizar aprendizaje automático (machine learning) y así ser capaces de generar reglas de inferencia o conocimiento.

El trabajo desarrollado por Alves et al. (2001), se habla de la importancia y el interés creciente en el campo de la medicina, particularmente en la creación de sistemas de diagnóstico inteligente con funciones incorporadas para descubrimiento de conocimiento o data mining, las cuales permitan extraer y abstraer reglas útiles a partir de grandes repositorios de datos. Características que se están volviendo cada vez más importantes para ofrecer mejores servicios o cuidados, u obtener ventajas competitivas sobre diferentes estrategias o metodologías de resolución de problemas (Agrawal et al., 1995). En particular, los sistemas de aprendizaje automático embebidos en estos sistemas de diagnóstico inteligente parecen ser bien recibidos en los dominios de medicina más especializados, principalmente debido al hecho de que generan reglas de diagnóstico de forma automática superando ligeramente la eficacia de diagnóstico de los especialistas cuando estos tienen disponible la misma información que la máquina.

Otro interesante trabajo es el descrito por Brause (2001). En este trabajo, en primer lugar, se hace una revisión acerca del uso de redes de neuronas a problemas médicos. Algunos ejemplos exitosos muestran que las capacidades de diagnóstico en las personas son significativamente peor que los diagnósticos que realizan los sistemas basados en redes de neuronas. Teniendo en cuenta esto, se realiza una breve introducción al paradigma de las redes de neuronas y al principal problema de las bases de datos médicas y las características básicas de entrenamiento y prueba de una red de neuronas aplicada a este ámbito. Además, se presenta el problema de realizar interfaces de acceso a las redes de neuronas y los resultados obtenidos, junto con la presentación de un esquema de una red difusa. Finalmente, se describe el caso de estudio de una red neuronal basada en reglas para el diagnóstico de shock séptico, evaluando por una parte la red de neuronas y por otra el sistema basado en reglas.

También cabe mencionar el trabajo realizado por Scott (1993), donde se menciona que se han estado realizando gran cantidad de trabajos para refinar o incrementar de forma explícita el proceso de diagnóstico. Generalmente, los principios de diagnóstico envuelven el proceso de colección, análisis, reconocimiento y clasificación de los datos. Los datos de los pacientes son obtenidos a partir de entrevistas, observaciones y exámenes. El médico, usando su conocimiento y experiencia, transforma los datos en un diagnóstico. Si tratáramos de ver al médico como un sistema, los datos coleccionados deberían proporcionar las entradas y el diagnóstico las salidas. El campo de la Inteligencia Artificial ha proporcionado varias aproximaciones para definir los sistemas que podrían ser útiles para el diagnóstico médico. Los sistemas expertos están basados en reglas para definir de forma explícita los pasos que transforman un conjunto de inputs en outputs. La transformación aparece como una progresión a través de un número de reglas de tipo IF-THEN construidas con la ayuda de expertos en el dominio como los médicos

28

experimentados en el área de diagnóstico que nos ocupe. Si el conocimiento del dominio requerido para el diagnóstico puede ser claramente definido por dichas reglas, los sistemas expertos tendrán éxito. Las reglas deben ser estructuradas e implementadas a través del uso de un motor de inferencia, el cual, cuando se reciba un patrón de elementos de entrada, un diagnóstico u otra forma de respuesta va a ser producida como salida. Este conjunto de reglas completadas lógicamente serán usadas para generar la transformación, en contraste con las redes de neuronas artificiales (RNA). Mientas se procesan datos en un sistema experto, este toma una serie de progresiones secuenciales a través de un número de reglas de tipo IF-THEN, el procesamiento usado por la RNA es paralelo, análogamente al que lleva a cabo el cerebro, adaptativo y no limitado por reglas fijas.

Los especialistas en los campos de medicina nuclear, radiología y otras disciplinas en las cuales la evaluación de los datos incluye la interpretación visual de patrones se pueden beneficiar de las aplicaciones de las tecnologías de las RNA. Al contrario que en los ordenadores de serie convencionales, el procesamiento paralelo de las RNA exhibe un mejor comportamiento, como el del cerebro. Si contrastamos dos tipos de problemas que los humanos puedan resolver, como reconocer un patrón visual familiar y resolver un problema matemático, se ilustra la dicotomía del paralelismo frente a realizarlo en serie.

Tecnologías Semánticas

Una de las tecnologías más importantes, la cual por algunos autores es considerada parte de la Inteligencia Artificial (Berners-Lee, 2006), que se debe considerar en esta tesis son las Tecnologías Semánticas. En este aspecto, existen gran cantidad de trabajos sobre gestión del conocimiento clínico o médico, con iniciativas como Open-Galen (Rector et al., 2003) u OBO-Foundry (Smith et al., 2007). Sin embargo, sistemas de diagnóstico de propósito general que hayan sido generados y probados, como tal, usando estas técnicas, no parece haber demasiados en la literatura actual.

A pesar de ello, cabe destacar artículos que se pueden considerar de gran interés para la temática de la presente tesis.

En el primero de ellos, desarrollado por Djedidi & Aufaure (2007) se presenta una propuesta para la construcción de ontologías de dominio médico como base para un sistema de soporte la decisión centrado en el conocimiento. La fase de adquisición del conocimiento está basada en fuentes de datos heterogéneas incluyendo corpus textuales, guías prácticas, bases de datos, fuentes de términos así como ontologías existentes y estándares médicos. Más allá del proceso de modelización del conocimiento, los autores proponen una fase de meta-conceptualización y formalización que constituya una ontología médica que sirva de núcleo para ser establecida a un alto nivel de abstracción y que guíe las fases de operacionalidad y explotación. El proceso de operacionalización instancia la referencia a una ontología del dominio médico y la integra en el sistema de la base de conocimiento permitiendo razonamiento e inferencia del conocimiento, y por lo tanto, preparando las bases para el sistema de soporte médico.

Podgorelec et al. (2009) realizan un estudio de la optimización en el proceso de diagnóstico desde el punto de vista de acceso a datos. De acuerdo con varios estudios los cuales muestran que el proceso de diagnóstico optimizado puede mejorar su eficiencia considerablemente en la industria de la salud, se presenta un nuevo enfoque para la integración de datos dentro del proceso de diagnóstico. En él se describe que un acceso unificado a los recursos de datos durante todo el proceso de diagnóstico que mejora considerablemente la eficiencia del proceso en sí mismo. Cuando se combina el acceso a los datos de forma optimizada con un método de optimización, se puede lograr que se tenga en cuenta la calidad de un diagnóstico, las necesidades individuales de cada paciente, los costes asociados y la utilización del personal y equipo.

29

Para lograr un manejo eficiente de los datos, el artículo muestra el desarrollo de un sistema basado en Tecnologías Semánticas para la integración de recursos de datos dentro del proceso de diagnóstico médico. El proceso se basa en la combinación del acceso a datos unificado con su propio framework para el proceso de diagnóstico, el cual incluye técnicas de aprendizaje automático y algoritmos evolutivos. El nuevo framework de proceso de diagnóstico que queda definido es usado finalmente en un caso de estudio para optimizar el diagnóstico del síndrome de prolapso de la válvula mitral.

Otros trabajos más recientes e íntimamente relacionados con el de esta tesis son los de Bucci et al. (2011) donde se propone un nexo entre las tecnologías semánticas (concretamente las ontologías) y las redes bayesianas para la realización de diagnóstico médico. Así mismo, el trabajo propuesto por Bertaud-Gounot et al. (2011) proporcionan un enfoque muy interesante relacionado con el concepto de los criterios de diagnóstico así como la descripción de enfermedades usando Description Logics, pero basándose en el modelado único de determinadas dolencias.

Otras Técnicas de Inteligencia Artificial

Para finalizar con el estudio de los trabajos donde se realizan sistemas de diagnóstico diferencial de propósito general utilizando técnicas de Inteligencia Artificial, se incluyen en esta sección todas aquellas técnicas no tratadas previamente.

Comenzaremos el análisis de los trabajos realizados, con el desarrollado por Chandrasekaran et al. (1979) a finales de los años 70, donde se realizaba una propuesta de un esquema de representación del conocimiento llamado estructuras conceptuales, el cual organiza el conocimiento en forma de reglas de producción o procedimientos más complejos, de tal forma que son accedidos y usados según se necesitan. La estructura es dominantemente jerárquica, de tal forma que los sucesores de un nodo conceptual se quedan de lado ante los subconceptos que pueden refinar el propio concepto. Asociado con cada concepto está un conjunto de procedimientos (expertos) los cuales intentan aplicar el conocimiento relevante al caso tratado.

En el trabajo realizado por Hsu & Ho (2004) proponen una arquitectura híbrida basada en casos, la cual soporta diagnóstico de múltiples enfermedades y el aprendizaje de nuevo conocimiento de forma adaptativa. La arquitectura combina razonamiento basado en casos (CBR - Case-Based Reasoning), redes de neuronas, teoría difusa, inducción, teoría de utilidad y tecnologías de planificación basadas en el conocimiento de forma conjunta para facilitar el diagnóstico médico. El mecanismo básico se basa en CBR, donde a su vez una red de neuronas difusa distribuida es empleada para realizar aproximaciones de correspondencia y por lo tanto tolerar ruido potencial a la hora de obtener los casos. La tecnología de inducción, junto con la teoría de utilidad, es usada para seleccionar aquellas características válidas del caso objetivo y reducir el espacio de búsqueda. La planificación basada en el conocimiento es un mecanismo de propósito general para la adaptación de casos. Este sistema crea un plan de adaptación al caso a partir de un árbol de adaptación el cual contiene todas las características de los problemas relevantes, que satisfagan todas las limitaciones relevantes y contiene todos los casos los cuales se espera que sus utilidades sean mayores que el umbral. La ejecución del plan de adaptación de casos guía al diagnóstico de múltiples enfermedades. El árbol de adaptación facilita el reúso de casos y el aprendizaje de varios tipos de conocimiento, incluyendo las relaciones entre tipos de enfermedades y características, verificación específica de casos del conocimiento, y reglas de diagnóstico diferencial. Integrando todas estas técnicas en el paradigma de CBR se puede producir de forma efectiva un diagnóstico de alta calidad para una consulta médica dada.

30

Otro sistema híbrido es el presentado por Meesad & Yen (2001), donde propone un sistema híbrido inteligente que es una combinación de representación del conocimiento numérica y lingüística. El sistema propuesto es una integración jerárquica de una red neuronal de aprendizaje difuso (ILFN - Incremental Learning Fuzzy Network) y un modelo difuso lingüístico optimizado mediante un algoritmo genético. El ILFN es una red auto organizada con la capacidad de aprendizaje incremental rápido. El modelo lingüístico es construido basado en el conocimiento embebido en la red ILFN entrenada. El conocimiento capturado desde la ILFN puede ser mapeado al modelo lingüístico y viceversa. El algoritmo genético es aplicado para optimizar el modelo lingüístico y mantener una alta efectividad y comprensibilidad. El resultado es que el sistema es capaz de trabajar con la computación numérica de bajo nivel y la computación lingüística de alto nivel. Una vez el sistema está completamente estructurado, puede aprender nueva información de forma incremental en ambas estructuras (numérica y lingüística). Para evaluar el rendimiento del sistema se utilizaron los datos del benchmark que ofrece el informe Wisconsin de cáncer de mama como aplicación de diagnóstico clínico. Los resultados de la simulación mostraron que el sistema propuesto mostraba mejores resultados que otros sistemas.

Juárez et al. (2008) realizan una propuesta donde argumentan que el razonamiento basado en modelos (MBR - Model-Based Reasoning) es uno de los métodos que tradicionalmente han tratado de resolver el problema del diagnóstico en entornos médicos gracias a su capacidad para modelar y razonar. La consideración de la dimensión temporal en estos dominios es un tema desafiante en MBR, especialmente si se tiene en cuenta la imprecisión temporal. Desafortunadamente, a pesar de haberse desarrollado varios sistemas basados en MBR con éxito, existen aún dos problemas fundamentales en su desarrollo en los dominios mencionados: (1) el grado de dependencia entre el modelo usado y el dominio; y (2) la reutilización de los sistemas cuando el dominio cambia. En este trabajo se propone un conjunto de requerimientos básicos para el diseño de los sistemas basados en el conocimiento que va a ayudar a resolver el problema del diagnóstico temporal para entornos con complejidad conceptual alta. A partir de esos principios y a través de un profundo análisis de varias propuestas presentes en la Inteligencia Artificial se establece un framework genérico que se encarga de ambos objetivos integrando MBR y ontologías para la representación del conocimiento del dominio para describir un modelo intermedio de representación que facilite baja dependencia entre el modelo y el dominio de la aplicación.

Además, se realiza un caso de prueba del uso del framework para desarrollar un sistema de diagnóstico en un entorno médico real (Unidad de cuidados intensivos) con una descripción paso a paso del proceso, desde la arquitectura, hasta la implementación.

Otro planteamiento similar donde también se usan sistemas basados razonamiento de modelos es presentado por Lucas (1997).

Otra técnica usada es la denominada “escenarios de prueba” realizada por Larsson et al. (1997). En este trabajo se describe un método informal, pero sistemático, de cómo probar y verificar un sistema basado en el conocimiento en varios dominios médicos. El sistema usado recibe el nombre de Guardian, un sistema inteligente para monitorizar y diagnosticar cirugía en pacientes en una unidad de cuidados intensivos. La base de conocimiento es probada y verificada ejecutando en el sistema una serie de escenarios de prueba realistas, ambos con un simulador embebido y con sistema de simulación externo. Los mismos escenarios son presentados a humanos, haciendo posible la comparación y analizando la efectividad del sistema de la base de conocimiento con los humanos. El uso de simuladores en vez de datos clínicos también significa que es posible probar escenarios cruciales los cuales ocurren pocas veces en la práctica médica. En sus resultados muestran que un sistema como Guardian puede ser útil en la práctica de la medicina.

31

El trabajo realizado por Tan et al. (2002) se propone una técnica híbrida de clasificación evolutiva en dos fases para extraer reglas de clasificación que puedan ser usadas en la práctica clínica para un mejor entendimiento y prevención de eventos médicos no deseados. En la primera fase, un algoritmo evolutivo híbrido es utilizado para confinar el espacio de búsqueda evolucionando un conjunto de reglas candidatas. Técnicas de programación genética son usadas para evolucionar los atributos nominales en reglas de estructuración libre y los algoritmos genéticos son usados para optimizar los atributos numéricos para una clasificación de las reglas de forma concisa sin la necesidad de discretizar. Estas reglas candidatas son usadas entonces en la segunda fase para optimizar el orden y número de reglas en la evaluación para formar conjuntos de reglas eficaces y de fácil entendimiento. El clasificador evolutivo propuesto es validado usando conjuntos de datos de hepatitis y cáncer de mama obtenidos de repositorios de aprendizaje automático de la UCI. Los resultados de simulación mostraron que el clasificador evolutivo producía reglas comprensivas y buenos resultados de clasificación para los conjuntos de datos médicos. Los resultados obtenidos se comprueban a través de T-student que justifican aún más su robustez e invariancia para particiones de conjuntos de datos aleatorios.

En el trabajo realizado por Tsumoto (1998) se discuten las características del razonamiento médico y muestra la representación de estos modelos de diagnóstico mediante el uso de teoría de rough sets. La idea clave es una precisión variable de los modelos de rough sets, los cuales corresponden a un razonamiento ordinal positivo, y una aproximación del concepto objetivo, el cual corresponde a la focalización de un procedimiento. La representación adquirida sugiere que los modelos basados en rough set deberían estar muy relacionados con el diagnóstico médico.

En Zhou & Jiang (2003), se presenta un sistema donde se usa el algoritmo C4.5, el cual combina redes de neuronas artificiales con inducción de reglas. En el proceso, al principio, una red de neuronas artificiales es entrenada. Entonces, un nuevo conjunto de datos de entrenamiento es generado alimentando los vectores de características del conjunto original de entrenamiento. Un conjunto de entrenamiento adicional también será añadido generando vectores de características aleatorios y combinándolos con sus correspondientes clases. Finalmente, una propuesta de inducción de reglas como C4.5 Rule, es usado para aprender reglas a partir del nuevo conjunto de datos. Los casos de estudio se basan en el diagnóstico de la diabetes, hepatitis y cáncer de mama.

2.1.2.2. DIAGNÓSTICO ESPECÍFICO

En la siguiente sección se pretende hacer un análisis sobre los diversos trabajos existentes relacionados con el diagnóstico específico de un determinado tipo de dolencias o enfermedades en vez de estar destinados al propósito del diagnóstico de ámbito general. Existen multitud de trabajos sobre varios tipos de diagnóstico clínico, sin embargo, a pesar de ello, las siguientes secciones se van a centrar principalmente en aquellas dolencias o enfermedades de las que más literatura existe, dejando una última sub sección para comentar algunos de los trabajos más relevantes existentes sobre otras dolencias.

Diagnóstico de cáncer de mama

El cáncer de mama es el crecimiento desordenado y no controlado de células con genes mutados, los cuales actúan normalmente suprimiendo o estimulando la continuidad del ciclo celular pertenecientes a distintos tejidos de una glándula mamaria. En medicina el cáncer de mama se conoce con el nombre de carcinoma de mama. Es una neoplasia maligna que tiene su origen en la proliferación acelerada e incontrolada de células que tapizan, en el 90% de los casos, el interior de los conductos que durante la lactancia, llevan la leche desde los acinos glandulares, donde se produce, hasta los conductos galactóforos,

32

situados detrás de la areola y el pezón, donde se acumula en espera de salir al exterior. Este cáncer de mama se conoce como carcinoma ductal. En el 10% de los casos restantes el cáncer tiene su origen en los propios acinos glandulares y se le llama carcinoma lobulillar. El carcinoma ductal puede extenderse por el interior de la luz ductal e invadir el interior de los acinos en lo que se conoce como fenómeno de cancerización lobular.

En el trabajo realizado por Abbas (2002) se presenta una propuesta de una red de neuronas basada en el algoritmo de evolución diferencial de Pareto incrementado con búsqueda local para la predicción del cáncer de mama. El enfoque es llamado red neuronal artificial memética de Pareto (MPANN por sus siglas en inglés). Las redes de neuronas artificiales pueden ser usadas para mejorar el trabajo de los médicos en el diagnóstico del cáncer de mama. Sus características para aproximar funciones no lineales y capturar relaciones complejas en los datos son grandes instrumentos que pueden ser usados en el dominio médico. En este trabajo se comparan sus resultados contra un enfoque de programación evolutiva donde se usan técnicas de propagación hacia atrás y se muestra que experimentalmente, las MPANN tienen mejor generalización y un coste computacional mucho menor.

Otra técnica evolutiva es la usada por Guo & Nandi (2006), donde en su trabajo proponen un nuevo método para el diagnóstico de cáncer de mama usando programación genética. Dichos investigadores desarrollaron una nueva característica de extracción de medidas (una modificación del análisis discriminante lineal de Fisher (MFLDA)) para superar las limitaciones del criterio de Fisher. Para ello se desarrolló una modificación del criterio de Fisher para ayudar al algoritmo de programación genética a optimizar las características que permiten a los vectores de patrones pertenecer a distintas categorías para distribuirse de forma compacta en regiones disjuntas. En primer lugar, el MFLDA es comparado de forma experimental con algunos métodos clásicos de extracción de características. En segundo lugar, la característica generada por el algoritmo de programación genética basada en el criterio modificado de Fisher se compara con las características generadas por el algoritmo de programación genética usando el criterio de Fisher (sin modificar) y un criterio de Fisher alternativo en términos de clasificación de rendimiento. Esta clasificación es llevada a cabo por un clasificador simple (clasificador de mínima distancia). Finalmente, la misma característica generada por el algoritmo de programación genética es comparada con el conjunto de características originales como entradas para perceptrones multi capa y máquinas de vectores de soporte.

En la misma línea del uso de algoritmos evolutivos es el trabajo desarrollado por Lisboa & Taktak (2006). En este trabajo se realiza una revisión sistemática para evaluar los beneficios de las redes de neuronas artificiales como herramientas de toma de decisiones en el campo del cáncer. El número de ensayos clínicos (EC) y ensayos clínicos aleatorizados (ECA) en los cuales se usaron redes de neuronas artificiales en el diagnóstico y pronóstico se incrementó de 1 a 38 en la última década. Sin embargo, de los 396 estudios que usaron redes de neuronas en cáncer, solo 27 fueron EC o ECA. De estos ensayos, 21 mostraron un incremento beneficioso en la predicción, y 6 no. Ninguno de estos estudios sin embargo ha mostrado un decremento de los beneficios.

Otro trabajo es el de Übeyli (2007) donde este artículo tiene como intención mostrar una vista integrada sobre la implementación del diagnóstico automático de cáncer de mama. El principal objetivo del artículo es establecer una guía para los lectores, para aquellos que quieran desarrollar un sistema de soporte a la decisión automático para la detección del cáncer de mama. Dada la importancia de tomar la decisión correcta, se han buscado los mejores procedimientos para la clasificación de este cáncer. Las precisiones de clasificación de varios clasificadores fueron comparadas en este artículo. Estos clasificadores incluían perceptrones multicapa, redes de neuronas combinadas, redes de neuronas recurrentes, y máquinas de vectores de soporte. La base de datos usada fue la de

33

cáncer de mama de Wisconsin (Wolberg et al., 2010). El propósito era determinar un esquema de clasificación óptimo con gran eficacia a la hora del diagnóstico de este problema. La investigación de este trabajo demostró que las máquinas de vectores de soporte obtienen mejores resultados que el resto.

Otro tipo de técnica usada es la presentada por Ahn & Kim (2009), donde argumentan que el razonamiento basado en casos (CBR) es una de las técnicas de predicción más populares en los dominios médicos debido a que es fácil de aplicar, no tiene posibilidad de sobreajuste y proporciona una buena explicación para la salida. Sin embargo, tiene una limitación crítica, y es que su rendimiento de predicción es generalmente menor que otras técnicas de Inteligencia Artificial como las redes de neuronas artificiales. En este estudio, se propone un nuevo enfoque para realzar el rendimiento de la predicción de los sistemas CBR. La sugerencia de este trabajo es la optimización simultanea de las características de los pesos, selección de instancias y el número de vecinos a combinar usando algoritmos genéticos. En este modelo se mejora el rendimiento de predicción de tres formas: (1) midiendo la similitud entre los casos de forma más exacta considerando la importancia relativa de cada característica, (2) eliminando los casos de referencia no útiles, y (3) combinando varios casos similares que representan patrones significativos. Para validar la eficacia de su modelo, este estudio lo aplica al caso de uso real para evaluar características citológicas derivadas directamente de un escaneo digital de transparencias de una biopsia de mama con aguja fina. Los resultados experimentales mostraron que la eficacia de predicción de los sistemas CBR convencionales puede ser mejorada significativamente usando este modelo.

En el trabajo realizado por Guiu et al. (1999) se propone un caso similar al expuesto en trabajos anteriores. En este caso se describe la aplicación de técnicas de aprendizaje automático para el diagnóstico automático (clasificación en este caso) de imágenes de biopsias de mama. Las técnicas aplicadas en este caso son algoritmos genéticos y razonamiento basado en casos. El artículo compara sus resultados con resultados previos obtenidos usando redes de neuronas artificiales. Los principales objetivos son: resolver de forma eficiente los problemas de clasificación de un determinado tipo y comparar las diferentes alternativas de aprendizaje automático. Este artículo también introduce los sistemas que estos investigadores desarrollaron para este tipo de problemas de clasificación: Un sistema llamado GeB-CS usando algoritmos genéticos, y un sistema llamado CaB-CS usando razonamiento basado en casos.

Las técnicas de redes bayesianas fueron usadas en este dominio entre otros por Kahn Jr. et al. (1997). Las redes bayesianas usan técnicas de teoría probabilística para razonar bajo incertidumbre y han ganado importancia dentro de los sistemas de soporte a la decisión médicos. En este artículo se describe el desarrollo y validación de una red bayesiana (MammoNet) para asistir en el diagnóstico mamográfico del cáncer de mama. MammoNet integra cinco características de la historia del paciente, dos indicios físicos, y 15 características mamográficas extraídas por radiólogos experimentados para determinar la probabilidad de malignidad. En este artículo se discuten los métodos y problemas de diseño, implementación y evaluación del sistema. Las redes bayesianas proporcionan una herramienta potencialmente útil para soporte a la decisión de mamografías.

Hu et al. (2003) presentan un sistema para anotación formalizada de imágenes médicas para ayudar en el diagnóstico y mantenimiento del cáncer de mama.

Hussain et al. (2007) presentan un framework basado en Tecnologías Semánticas para modelar y ejecutar el conocimiento dentro de un sistema donde se definen guías prácticas clínicas para desarrollar un sistema de soporte la decisión clínico. El enfoque propuesto implica el modelado del conocimiento a través de una sinergia entre múltiples

34

ontologías (por ejemplo una ontología del dominio, una ontología sobre guías de prácticas clínicas (CPG) y una ontología de pacientes).

Diagnóstico psiquiátrico

Los sistemas de diagnóstico diferencial de trastornos mentales son ampliamente usados en el campo de la psiquiatría. En el artículo redactado a finales de los 80 por Morelli et al. (1987) se realiza una revisión de los sistemas expertos existentes en psiquiatría así como los paradigmas de toma de decisión usados con más frecuencia en este tipo de sistemas.

Entrando más en detalle sobre algunos de los trabajos más relevantes en este campo se podría comenzar destacando uno de los trabajos más tempranos desarrollados en este campo realizado por Spitzer & Endicott (1968) donde se describe el creciente interés en los últimos años en el uso de ordenadores para llegar a un diagnóstico clínico. Parte del presente problema del diagnóstico psiquiátrico reside en la variabilidad en las operaciones, las cuales los médicos utilizan en el análisis de datos sin procesar para realizar un diagnóstico. Esta fuente es completamente eliminada con el uso de programas informáticos, los cuales siempre llegarán a los mismos diagnósticos dados los mismos datos. La disponibilidad de un programa de ordenador para diagnóstico psiquiátrico con validez demostrada haría posible comparaciones con sentido en la composición de un diagnóstico de variedad de poblaciones.

Un año más tarde, en 1969, los mismos autores, Spitzer & Endicott (1969) establecían las bases para lo que sería uno de los primeros programas de ordenador para diagnóstico de enfermedades psiquiátricas. El sistema, llamado DIAGNO II, está basado en un modelo de árbol de decisión lógica similar al proceso de diagnóstico diferencial usado en medicina clínica. En la validación del estudio aquí descrito, el programa producía diagnóstico para 100 pacientes, los cuales se confirmaban con los diagnósticos proporcionados por los médicos.

Años más tarde, First et al. (1988) publicaban un artículo sobre un sistema llamado DTREE. En él se exponía que el sistema DTREE había sido desarrollado para proporcionar a los nuevos médicos una herramienta asistida por ordenador para la enseñanza de diagnósticos psiquiátricos de acuerdo con la tercera edición revisada del manual estadístico de desórdenes mentales de la asociación americana de diagnóstico psiquiátrico. En el núcleo del sistema DTREE se encontraba un sistema experto que guiaba al usuario a través del proceso de realizar un diagnóstico. El modelo utilizado se basaba en el diseño de un árbol de decisión que se iba completando a medida que se iban respondiendo a preguntas acerca de un determinado caso, determinando en cada respuesta cual sería la siguiente pregunta. El objetivo principal de un sistema experto usado para enseñanza es ser capaz de proporcionar explicaciones sobre que está haciendo, la anotación de comentarios y textos explicativos adicionales disponibles para cada pregunta que es realizada.

Diagnóstico de lumbalgia

La lumbalgia es un término para el dolor de espalda baja, en la zona lumbar, causado por un síndrome músculo esquelético, es decir, trastornos relacionados con las vértebras lumbares y las estructuras de los tejidos blandos como músculos, ligamentos, nervios y discos intervertebrales. Se origina por distintas causas y formas, siendo las más comunes el estrés, el sobreesfuerzo físico y las malas posturas. En su presentación clínica puede ser aguda si dura menos de 4 semanas, subaguda entre 1 y 3 meses o crónica si dura más de 12 semanas. Cuando es aguda lo normal es tener reposo en cama y la mayoría de las veces,

35

los síntomas de dolor lumbar muestran una mejora significativa a partir de unos días a unas semanas desde su inicio.

En un número significativo de personas, el dolor lumbar puede ser recurrente, mejorando y empeorando con cada ciclo. En una pequeña proporción de personas esta condición puede volverse crónica. Estudios poblacionales muestran que el dolor de espalda afecta a la mayoría de los adultos en algún momento en su vida y representa más casos de permisos laborales por enfermedad y de discapacidad que cualquier otra condición médica.

En el temprano trabajo realizado por Fathi-Torbaghan & Meyer (1994) se presenta una propuesta donde se menciona que el diagnóstico de la lumbalgia representa un problema clínico muy serio. El conocimiento médico en este campo está caracterizado por incertidumbre, imprecisión y vaguedad de los datos. Esta situación puede ser resuelta especialmente con la aplicación de lógica difusa. En este artículo se presenta un sistema experto basado en lógica difusa para el diagnóstico llamado MEDUSA. La representación y aplicación de conocimiento impreciso y con incertidumbre es realizado usando conjuntos y relaciones difusas. El concepto híbrido del sistema permite la integración de razonamiento basado en reglas, en heurísticas y en casos. La idea central de la integración es usar razonamiento basado en casos para el manejo de los casos especiales, y razonamiento basado en reglas para la representación de los casos normales. El principio de la heurística está situado de forma idónea para realizar inferencia hipotética en la base de los datos y relaciones difusos.

Por otra parte, otro trabajo temprano es el realizado por Bounds et al. (1988). En él se describe el entrenamiento de un perceptrón multicapa (MLP - Multilayer Perceptron) para el diagnóstico de lumbalgia y ciática. El rendimiento del sistema es comparado con tres grupos de médicos y con otro software (Norris, 1986) basado en ideas de lógica difusa. Aunque se necesitan datos clínicos de un gran número de pacientes antes de que este enfoque sea completamente validado, los resultados iniciales eran muy prometedores. Para la categoría de diagnóstico, que es la más crucial de obtener información correcta, el MLP produce clasificaciones correctas más a menudo que ninguno de los tres grupos de médicos o el sistema de lógica difusa. La media de efectividad de diagnóstico sobre todos los posibles diagnósticos es también mayor que la de los médicos, pero ligeramente peor que la del sistema de lógica difusa.

Diagnóstico de enfermedades cardiacas

Se entiende como enfermedad cardiaca o cardiopatía a cualquier trastorno que afecta a la capacidad del corazón para funcionar normalmente. Algunas formas de cardiopatía comprenden las arritmias, shock cardiógeno, endocarditis, ataque cardiaco, etc. La causa más común de cardiopatía es un estrechamiento o un bloqueo en las arterias coronarias que suministran la sangre al músculo cardíaco (arteriopatía coronaria). Algunas cardiopatías están presentes al nacer (cardiopatía congénita). Otro nombre que recibe este tipo de enfermedades es el de trastorno cardiovascular.

En este aspecto, existen multitud de técnicas de Inteligencia Artificial que pueden ser aplicadas en el diagnóstico de este tipo de patologías.

Un interesante trabajo es el realizado por Yan et al. (2008). En él se argumenta, que en el campo clínico existen gran cantidad de características de diagnóstico que son obtenidas a partir de un paciente para una determinada enfermedad, lo cual es beneficioso para el correcto diagnóstico de la enfermedad, seleccionando las características importantes y relevantes y descartando aquellas redundantes e irrelevantes. En este trabajo se utiliza un sistema basado en un algoritmo genético para seleccionar las

36

características clínicas críticas esenciales para el diagnóstico de enfermedades del corazón. La base de datos de enfermedades del corazón usada en este estudio incluye 352 casos, y 40 características fueron obtenidas para cada caso. Usando el algoritmo genético propuesto, se identificaron 24 características críticas, y se determinaron sus correspondientes pesos de diagnóstico para cada enfermedad cardiaca de interés.

Otra propuesta basada en algoritmos genéticos es la de Tsai et al. (2008). En este trabajo se presenta un enfoque de lógica difusa basado en algoritmos genéticos para ayudar al diagnóstico usando imágenes médicas. Este esquema es aplicado para discriminar enfermedades de miocardio a partir de imágenes eco cardiográficas y para detectar y clasificar grupos de micro calcificaciones a partir de mamografías. A diferencia de los tipos convencionales de funciones miembros como la trapezoide, triángulo, curva S y singleton usadas en razonamiento difuso, se usan funciones Gaussianas distribuidas difusas (GDMFs). Las GDMFs son generadas inicialmente usando varias características basadas en texturas obtenidas a partir de imágenes de referencia. Subsecuentemente, las formas de los GDMFs son optimizadas por un procedimiento de aprendizaje basado en algoritmos genéticos. Después de la optimización, se usa el clasificador para discriminar enfermedades. Los resultados de los experimentos propuestos en este trabajo son muy prometedores, puesto que han conseguido una eficiencia media del 96% para enfermedades de miocardio y una eficiencia del 88.5% con una sensibilidad del 100% para la microcalcificación de mamografías. Los resultados demostraron que el algoritmo de lógica difusa basado en algoritmos genéticos es un método efectivo para el diagnóstico de enfermedades por clasificación.

Otra técnica ampliamente utilizada en el diagnóstico de este tipo de enfermedades son las redes bayesianas o probabilísticas. En el trabajo desarrollado por Díez et al. (1997) se propone un sistema experto llamado DIAVAL para el diagnóstico de enfermedades cardiacas, entre las que se incluyen varios tipos de datos, principalmente procedentes de eco cardiografías. La primera parte del trabajo está unida al modelo casual probabilístico el cual constituye la base de conocimiento del sistema experto en forma de una red bayesiana, enfatizando la importancia de las puertas OR. La segunda parte se centra en el proceso de diagnóstico, el cual consiste en calcular las probabilidades a posteriori, seleccionando el diagnóstico más relevante y más probable y generando un informe.

En el artículo escrito por Long (1989) se relata la experiencia en el desarrollo de un mecanismo de diagnóstico diferencial en los casos donde se ven involucrados síntomas de fallos cardiacos usando un modelo casual de hemodinámica cardiovascular con probabilidades que relacionan causa y efecto.

También es interesante el trabajo desarrollado por Colantonio et al. (2007), donde se argumenta que las enfermedades crónicas cardiacas son un síndrome con una prevalencia de mortalidad muy alta en los países del oeste de Europa. En este marco se desarrolla el proyecto europeo HEARTFAID el cual ayuda a la realización de una innovadora plataforma de servicios la cual tenía como objetivo mejorar el proceso de diagnóstico, pronóstico y terapias en el dominio cardiaco. El núcleo de la plataforma inteligente es un sistema de soporte a la decisión clínico, diseñado para integrar técnicas innovadoras de representación del conocimiento y modelos de razonamiento híbridos, e incluyendo avanzadas herramientas para el análisis de los datos diagnosticados. En este artículo se discute también como se están utilizando las Tecnologías Semánticas para implementar un escenario clínico real, que cubra todo el proceso clínico de un fallo cardiaco en un paciente.

37

Otros diagnósticos

En la siguiente sección se establecen otros sistemas de diagnóstico diferencial de propósito específico.

Con técnicas de algoritmos evolutivos cabe destacar el trabajo de Tsakonas et al. (2004), en el que se demuestra y compara la aplicación de diferentes metodologías inteligentes basadas en programación genética para la construcción de sistemas basados en reglas en dos dominios médicos: el diagnóstico de los subtipos de afasia y la clasificación de exámenes de Papanicolaou.

Otros ejemplos, usando redes de neuronas, incluyen el diagnóstico de apendicitis (Eberhart et al., 1991; Pesonen et al., 1996), dolor de espalda o lumbalgia (Bounds et al, 1998), infarto de miocardio, emergencias psiquiátricas (Baxt, 1991; Baxt & Skora, 1996; Heden et al., 1997) y problemas de la piel. Las predicciones de diagnóstico basadas en redes de neuronas de embolias pulmonares fueron en algunas ocasiones incluso mejor que las predicciones de los médicos (Tourassi et al., 1993; Tourassi et al., 1995; Holst et al., 2000). Además, las aplicaciones basadas en este tipo de sistema han sido útiles en los análisis de ondas ECG (Heden et al., 1995).

En el trabajo realizado por Cooper (1984) como tesis doctoral se discute el desarrollo de un programa llamado NESTOR el cual fue desarrollado para ayudar a los médicos a determinar la mejor hipótesis de diagnóstico a partir de un grupo de indicios de un paciente. En este caso, el dominio de los desórdenes hipercalcémicos es usado para probar los métodos de solución que deberían ser aplicables a otras áreas de la medicina. Un factor clave en el diseño de NESTOR es que los médicos deben tener el control de la interacción con la máquina para determinar que se debe hacer y cuando. La filosofía unificadora en el desarrollo de este sistema es el uso de métodos basados en el conocimiento con un framework teórico de probabilidades formales. Un módulo de interfaz de usuario proporciona al médico control sobre cuando y como estas tareas son usadas para ayudar en el diagnóstico de las condiciones de un paciente.

En el trabajo de Povalej et al. (2007) se trata el tema del alcoholismo como un problema difícil de diagnosticar desde que ninguno de los marcadores de laboratorio tiene suficiente especificidad y sensibilidad. Por lo tanto, el objetivo de este estudio fue encontrar los mejores marcadores de laboratorio y/o sus combinaciones. Para este propósito se utilizó un método de árbol de decisión de inducción para el análisis inteligente de los datos. Los resultados mostraron que la combinación de tres, o incluso dos marcadores pueden probar una dependencia del alcohol con al menos el 85% de efectividad.

Tan et al. (2008) argumentan en su trabajo que la detección temprana es primordial para reducir el alto índice de mortalidad por cáncer de ovarios. Desafortunadamente, las herramientas de detección actuales no abarcan correctamente este problema. Nuevas técnicas como el micro array del Ácido desoxirribonucleico (ADN) y datos proteómicos son difíciles de analizar debido a la alta dimensionalidad, donde los métodos convencionales como los análisis de sangre no son suficientemente específicos. Por lo tanto, en este trabajo proponen un modelo funcional para reconocimiento de patrones humanos conocido como red neuronal de aprendizaje difuso complementario (CLFNN por sus siglas en inglés) para ayudar a los métodos de diagnóstico existentes. En contraste con los métodos inteligentes convencionales, CLFNN explota la inhibición lateral entre las muestras positivas y negativas. Además, está equipado con una utilidad autónoma de generación de reglas. Un ejemplo llamado red de control de aprendizaje adaptativo difuso con teoría de resonancia adaptativa (FALCON-AART por sus siglas en inglés) es usada para ilustrar el rendimiento del CFLNN. La confluencia del CFLNN-micro-array, CLFNN-análisis

38

de sangre y CLFNN-proteómico demuestran buenos resultados y especificidad en los experimentos. La decisión de diagnóstico es eficaz y consistente.

En el trabajo desarrollado por Magoulas et al. (2004) se investiga el entrenamiento online de redes de neuronas en el contexto de diagnóstico colonoscópico asistido por ordenador. Una adaptación basada en memoria de la tasa de aprendizaje para el algoritmo de propagación hacia atrás es propuesto y usado para alimentar un proceso evolutivo online que aplica una estrategia de evolución diferencial para adaptar o readaptar la red de neuronas a las condiciones de entorno modificadas. En su enfoque, se observa el entrenamiento online desde la perspectiva de rastrear la localización cambiante de una solución aproximada basada en patrones, y, por lo tanto, cambiar de forma dinámica la función de error. La estrategia de tipo híbrida propuesta es comparada con otros métodos de entrenamiento estándar que han sido usado tradicionalmente para el entrenamiento de redes de neuronas de forma offline. Los resultados interpretando las imágenes de la colonoscopia y frames de secuencias de vídeo son prometedores y sugieren que las redes entrenadas con esta estrategia detectan las regiones de interés malignas con eficacia.

En el área cerebral cabe destacar el artículo desarrollado por Alayón et al. (2007). Las malformaciones del córtex cerebral son reconocidas como una causa común de retraso en el desarrollo, problemas neurológicos, retraso mental y epilepsia. Actualmente, el diagnóstico de las malformaciones del córtex cerebral está basado en una interpretación subjetiva de características de imágenes neurológicas de la materia gris y materia blanca cerebral. No existe un sistema automático para ayudar al observador a hacer un diagnóstico de las malformaciones corticales. En este artículo se propone por lo tanto un sistema basado en reglas difusas como solución a este problema. El sistema colecciona la información disponible en un experto sobre malformaciones corticales y asiste al observador médico para llegar a un diagnóstico correcto. Además, el sistema permite el estudio de la influencia de varios factores que toman parte en la decisión. La evaluación del sistema ha sido llevada a cabo comparando el algoritmo de diagnóstico automático con varios casos de ejemplo conocidos de varias malformaciones anormales en la organización cortical.

Trastornos como el de la diabetes, los cuales ocurren cuando un cuerpo es incapaz de producir o responder de forma adecuada a la insulina, la cual es necesitada para regular la glucosa (azúcar), son tratados por investigadores como Polat & Günes (2007). La diabetes, además de contribuir a los problemas de corazón, también incrementan los riesgos de desarrollar enfermedades de riñón, ceguera, daño nervioso, y daño en los vasos sanguíneos. En este trabajo, se trata el problema de la diabetes, el cual es un problema muy común, usando análisis de componentes principales (PCA por sus singlas en inglés) y un sistema de inferencia neuro difuso (ANFIS por sus siglas en inglés). El objetivo de este estudio era mejorar la eficiencia de diagnóstico de la enfermedad combinando PCA y ANFIS. El sistema propuesto se basa en dos estados. En el primer estado, el conjunto de datos que marca la dimensión de la enfermedad de la diabetes tiene 8 características que se reducen a cuatro usando PCA. En el segundo, el diagnóstico es conducido a través del clasificador del sistema ANFIS. En este caso el conjunto de datos usado en su estudio procede de la UCI (a partir del departamento de informática de la Universidad de California). La eficacia de clasificación del sistema es de un 89.47%.

Otro interesante trabajo es el desarrollado por Brause et al. (2001) para el diagnóstico de shock séptico. En su trabajo se basan en dos tipos de redes de neuronas aplicadas a los datos de dos estudios clínicos. En el incluyen los pasos necesarios para realizar minería de datos para construir una base de datos, limpiar y pre procesar los datos, y finalmente conseguir un análisis adecuado para los datos médicos del paciente. Se escogen dos arquitecturas basadas en redes de neuronas supervisadas.

39

En el trabajo desarrollado por Pang et al. (2004) se trata el importante método de diagnóstico en la medicina china tradicional llamado "diagnóstico de lengua". Sin embargo, debido a su calidad, subjetividad y naturaleza basada en la experiencia, el diagnóstico de lengua tradicional tiene una aplicación muy limitada en medicina clínica. Además, el diagnóstico de lengua tradicional está siempre más relacionado con la identificación de síndromes que con la conexión entre apariciones anormales en la lengua y enfermedades, algo que no se comprende muy bien en la medicina occidental, y por esto se obstruye su uso de forma más amplia en el resto del mundo. En este artículo se presenta un método de inspección de la lengua basada en sistemas informáticos con la intención de ayudar en estos problemas. En primer lugar, dos tipos de características cuantitativas, como las mediciones cromáticas y de textura son extraídas de imágenes de la lengua usando técnicas de procesamiento digital de imágenes. A partir de ese momento, se usan redes bayesianas para modelar las relaciones entre esas características cuantitativas y enfermedades. La efectividad del método fue probada en un grupo de 455 pacientes afectados por 13 enfermedades comunes así como en otros 70 voluntarios con buena salud.

Handels et al. (1999) proponen un nuevo enfoque para diagnóstico de tumores de la piel en dermatología. Los perfiles de alta resolución de la superficie de la piel son analizados para reconocer melanomas malignos y lesiones de la piel de forma automática. En un primer paso, varios tipos de características son extraídas por métodos de análisis de imágenes en 2D caracterizando la estructura de los perfiles de la superficie de la piel: características de texturas basadas en matrices de concurrencia. A partir de entonces, los algoritmos de selección de características son aplicados para determinar los subconjuntos de características que mejor encajen en el proceso de reconocimiento. La selección de características se describe como un problema de optimización y varios enfoques entre los que se incluyen estrategias de heurísticas, algoritmos de poda y genéticos son comparados. Como medida de calidad para subconjuntos de características, se usa el método de tasa de clasificación del vecino más cercano con otras técnicas. Los algoritmos genéticos sin embargo muestran los mejores resultados. Finalmente, el uso de redes de neuronas de propagación hacia atrás como paradigma de aprendizaje y algoritmos de poda son investigados para optimizar el rendimiento de clasificación de los clasificadores neuronales. Con el sistema de reconocimiento optimizado se consigue una efectividad en el sistema de clasificación del 97.7%.

En el trabajo realizado por Lim et al. (2006) se presenta un enfoque neuro difuso para el diagnóstico del síndrome de deficiencia de anticuerpos, donde un nuevo tipo de red neuro difusa con funciones de activación difusas (FAFs por su nombre en inglés) en la capa oculta es usado. Los FAFs capturan información esencial en la distribución de patrones. Para mejorar la capacidad de generalización y reducir la complejidad del modelo, un método heurístico para la selección de características es propuesto midiendo el tamaño de aquellas áreas del FAF que no presentan solapamiento. La efectividad de las técnicas propuestas es investigada a través de un conjunto de datos clínicos de inmunología obtenidos por el laboratorio de inmunología de la Universidad de California.

En el trabajo desarrollado por Xiang et al. (1993) se presenta un prototipo de un sistema de diagnóstico de problemas neuromusculares llamado PAINULIM encargado del diagnóstico de dolor o daño en miembros superiores, basándose en redes bayesianas. Este artículo presenta de forma no matemática los mayores problemas de representación del conocimiento que surgen en el desarrollo de PAINULIM.

El problema de reconocer sonidos pulmonares es un objetivo importante en medicina pulmonar. En el trabajo realizado por Güler et al. (2005) se presenta un estudio basado en redes de neuronas y algoritmos genéticos cuya intención es ayudar en la clasificación de sonidos pulmonares. Los sonidos pulmonares son capturados a través del

40

pecho y permiten identificar diferentes tipos de enfermedades pulmonares o problemas de salud. Intervalos de sonido con duración de 15 a 20 segundos fueron grabados en varios sujetos de pruebas. Dado cada intervalo, se seleccionaron varios ciclos de respiración completa, para cada ciclo de respiración completa, un espectro de poder de densidad de Fourier de 256 puntos (PSD por sus siglas en inglés) fue calculado. Un total de 129 datos calculados por el análisis espectral son seleccionados por el algoritmo genético y aplicados a la red de neuronas. Un perceptrón multicapa que emplea un algoritmo de entrenamiento de propagación hacia atrás fue usado para predecir la presencia o ausencia de sonidos extraños (respiración sibilante o crujidos). También se usaron algoritmos genéticos para buscar la estructura y parámetros de entrenamiento óptimos de la red de neuronas para una mejor predicción de los sonidos pulmonares.

Übeyli & Güler (2005) ilustran en su trabajo el uso de modelos de redes de neuronas combinadas para guiar en la selección de un modelo para el diagnóstico de desórdenes de la arteria carótida interna y desordenes oftálmicos. Las señales Doppler oftálmicas y de arteria carótida interna fueron descompuestas en representaciones de tipo tiempo-frecuencia usando transformación discreta de ondas y características estadísticas. El primer nivel de las redes fue implementado para el diagnóstico de las dolencias descritas anteriormente. Para mejorar la eficiencia de diagnóstico, el segundo nivel de redes fue entrenado usando las salidas de las redes de primer nivel como datos de entrada. Los modelos de redes de neuronas combinadas consiguieron tasas de éxito que fueron mayores que las de los modelos de redes autónomos.

2.1.3. CONCLUSIONES

En la presente sección se ha hecho una revisión de los principales sistemas de tipo CDSS o DDSS que se han realizado desde principios de aproximadamente 1960. Esta revisión, como se puede observar, incluye una serie de sistemas que han tenido un auge muy importante tanto en el mundo académico, de cara a la investigación de ciertas tecnologías aplicadas al campo médico, como en el propio mundo médico, donde algunos sistemas han sido adoptados para su uso en entornos clínicos reales.

Las principales conclusiones que se extraen de esta revisión hacen referencia a las tecnologías. Existen una gran cantidad de tecnologías aplicadas a la creación de los sistemas de diagnóstico en el ámbito clínico. De todas ellas, aquellas relacionadas con el almacenamiento del conocimiento son las piedras angulares a la hora de diseñar e implementar este tipo de aplicaciones debido precisamente a la gran cantidad de información que se debe tener en cuenta.

Así mismo, otras tecnologías de suma importancia, dentro del ámbito de la Inteligencia Artificial, son aquellas que permiten precisamente realizar razonamiento o inferencia sobre los datos o información almacenada usando las tecnologías de representación del conocimiento mencionadas anteriormente, y que serán también estudiadas en la siguiente sección.

2.2. ESTADO DEL ARTE DE LAS TECNOLOGÍAS

Una vez han sido presentados los trabajos más relevantes dentro del dominio de la tesis se realiza un recorrido a través de las tecnologías que juegan un rol para el desarrollo de la presente tesis.

La elección de estas tecnologías se ha basado en un análisis exhaustivo de los trabajos más relevantes (Trabajos relacionados, presentados en la sección 2.1). En esta sección se han analizado un amplio abanico de tecnologías que han servido a lo largo de

41

los años para desarrollar aplicaciones o sistemas como en el que, debido a la resolución de las hipótesis planteadas en esta tesis, han tenido que plantearse en este documento.

Todas las tecnologías analizadas, sin embargo, son dependientes de la Inteligencia Artificial, excepto lo referido a las tecnologías de soporte a la decisión, que se consideran una entidad diferente donde la Inteligencia Artificial puede, pero no tiene por qué estar involucrada. Debido a esto, este capítulo comienza con una introducción genérica al concepto de Inteligencia Artificial para después ahondar en las distintas tecnologías (que como se ha dicho, todas excepto las relacionadas a los sistemas de soporte a la decisión forman parte del concepto de IA) que se utilizarán para el desarrollo de esta tesis. La información proporcionada aquí proviene (con algunos cambios según se ha considerado su adaptación) de la monografía de Cepeda-Diaz, L.M. et al. (2010).

La inteligencia artificial (AI en inglés) se describe como la inteligencia de las máquinas y la rama de la informática cuyo objetivo es crear este tipo de máquinas. Los libros de texto la definen como el campo de "estudio y diseño de agentes inteligentes" (Poole et al., 1998) donde un agente inteligente es un sistema que percibe su entorno y toma acciones las cuales maximizan sus oportunidades de éxito (Russell & Norvig, 2003). John McCarthy, quien acuñó el término en 1956 (Crevier, 1993), lo define como "la ciencia e ingeniería de crear máquinas inteligentes” (McCarthy, 2007).

El campo fue fundado como reivindicación de que una propiedad intrínseca de los humanos, la inteligencia (la sapiencia en el Homo Sapiens), puede ser descrita tan precisamente que puede ser simulada por una máquina. Esto aumenta problemas filosóficos sobre la naturaleza de la mente, problemas que han sido usados en los mitos, ficción y filosofía desde la antigüedad (McCorduck, 2004). La Inteligencia Artificial ha sido el sujeto de optimismo, pero también ha sufrido retrasos y, hoy, ha sido una parte esencial en la tecnología industrial.

La investigación en Inteligencia Artificial es altamente técnica y especializada, profundamente dividida en áreas que generalmente fallan al comunicarse con otras (McCorduck, 2004). Estas áreas han crecido alrededor de instituciones particulares. Los problemas centrales de la Inteligencia Artificial incluyen algunas como razonamiento, conocimiento, planificación, aprendizaje, comunicación, percepción y la habilidad para mover y manipular objetos (Nilsson, 1998).

El término "Inteligencia Artificial" (IA) se acuño de manera formal en el año 1956 en la conferencia que tuvo lugar en el Darmoouth College, en Nuevo Hampshire, Estados Unidos (Crevier, 1993; Russel & Norvig, 2003; McCorduck, 2004). A pesar de que la literatura cita que el concepto se definición formalmente aquí, ya para entonces se había trabajado en ello durante al menos cinco años, en los cuales se propusieron muchas definiciones diferentes pero que en ningún caso habían logrado ser aceptadas por la comunidad investigadora de forma unánime.

Una definición que se proporcionó para la definición de la IA es la que la sitúa como una disciplina relacionada con las ciencias de la computación con el fin de dotar a las computadoras de inteligencia. De esta definición encontramos que una la técnica de IA es aquella la cual se usa con el fin de lograr que un determinado programa trate de comportarse de forma “inteligente” sin tener en cuenta la "forma de razonamiento" empleada.

Cuando se aplican algoritmos a la solución de los problemas aunque no se está actuando inteligentemente, estos surgen de reglas que tratan de orientarnos hacia las soluciones llamadas heurísticas (Pearl, 1984), las cuales nunca nos garantizan que la aplicación de una de estas reglas nos acerque a la solución.

42

Algunas definiciones no tan formales emitidas por diferentes investigadores de la IA que consideran otros puntos de vista son:

La IA es el arte de crear maquinas con capacidad de realizar funciones que realizadas por personas requieren de inteligencia. (Kurzweil, 1990)

La IA es el estudio de cómo lograr que las computadoras realicen tareas que, por el momento, los humanos hacen mejor. (Rich & Knight, 1991).

La IA es la rama de la ciencia de la computación que se ocupa de la automatización de la conducta inteligente. (Lugar & Stubblefied, 1993).

La IA es el campo de estudio que se enfoca a la explicación y emulación de la conducta inteligente en función de procesos computacionales. (Schalkoff, 1990).

En la IA se puede observar dos enfoques diferentes:

La IA concebida como el intento por desarrollar una tecnología capaz de proporcionar al ordenador capacidades de razonamiento similares a los de la inteligencia humana.

La IA en su concepción como investigación relativa a los mecanismos de la inteligencia humana que se emplean en la simulación de validación de teorías.

El primer enfoque se centra en la utilidad y no en el método como veíamos anteriormente con los algoritmos. Los temas claves de este enfoque son la representación y gestión de conocimiento y sus autores más representativos son McCarthy y Minsky.

En el segundo enfoque encontramos que este se orienta a la creación de un sistema artificial capaz de realizar procesos cognitivos humanos haciendo importante ya no la utilidad como el método. Los aspectos fundamentales de este enfoque se refieren al aprendizaje y adaptabilidad y sus autores son Newell y Simon de la Universidad Carnegie Mellon.

La IA al tratar de construir máquinas que se comporten aparentemente como seres humanos han dado lugar al surgimiento de dos bloques enfrentados: el enfoque simbólico o top-down, conocido como la IA clásica y el enfoque subsimbólico llamado a veces conexionista.

Los simbólicos simulan directamente las características inteligentes que se pretenden conseguir o imitar. Para los constructores de los sistemas expertos resulta fundamental la representación del conocimiento humano donde gracias a estos avances se han encontrado dos tipos de conocimiento: conocimiento acerca del problema particular y conocimiento acerca de cómo obtener más conocimiento a partir del que ya tenemos. El ejemplo más representativo de esta corriente es el proyecto Cyc de Douglas B. Lenat (Lenat, 1995) sobre un sistema que posee en su memoria millones de hechos interconectados.

Dentro de la otra corriente: la subsimbólica; sus esfuerzos se orientan a la simulación de los elementos de más bajo nivel dentro de los procesos inteligentes con la esperanza de que estos al combinarse permitan que espontáneamente surja el comportamiento inteligente. Los ejemplos más claros que trabajan con este tipo de orientación son las redes neuronales y los algoritmos genéticos donde estos sistemas trabajan bajo la autonomía, el aprendizaje y la adaptación, conceptos fuertemente relacionados.

43

Existen muchos trabajos relacionados con la Inteligencia Artificial en la medicina. Multitud de revistas y conferencias están especializadas en esta especialización de la Inteligencia Artificial, dando lugar a multitud de artículos referentes a esta disciplina (Szolovits, 1982). En lo referido a los trabajos relacionados con el diagnóstico diferencial existen multitud de trabajos también. Algunos de los primeros trabajos hablando de modo general de esta disciplina fue por ejemplo el de Szolovits et al. (1988). Los trabajos relacionados con esta temática, donde se trata directamente el diagnóstico clínico, son mostrados en el apartado relacionado con los sistemas de soporte a la decisión de diagnóstico.

2.2.1. TECNOLOGÍAS SEMÁNTICAS

El término Tecnologías semánticas, para hacer referencia a la popularmente conocida como Web Semántica, es un término que ha sido acuñado recientemente para designar una Web de nueva generación en la que los contenidos sean algo más que una gran suma de información y servicios escasamente estructurados. Como se ha comentado previamente, este enfoque tecnológico es considerado una de las ramas de la Inteligencia Artificial (Berners-Lee, 2006), pero en esta sección se comentará como un enfoque tecnológico independiente dada la gran cantidad de información que se debe mencionar de esta tecnología. La Web Semántica se basa en reestructurar y enriquecer los documentos y componentes Web con información semántica explícita, independiente de la presentación al usuario, y susceptible de ser procesada de forma automática por un programa. Se considera que la Web Semántica añadirá la estructura al contenido semántico de los documentos electrónicos, creando un entorno donde los agentes software podrán realizar tareas de manera eficiente (Berners-Lee et al., 2001). La Web Semántica es una visión: la idea de tener los datos en la Web definidos y enlazados de manera que puedan ser empleados por las máquinas, no sólo con propósito de visualización, sino para ser usado en varias aplicaciones. La Web Semántica cambiará la forma de trabajar. Por ejemplo, el desarrollo de un software se basará en la búsqueda de los componentes adecuados en la Web y en un documento de especificación que enlace esos componentes.

La Web Semántica, por lo tanto, viene a ser una extensión de la Web actual donde se la dota de significado, esto es, un espacio donde la información tendría un significado bien definido, de manera que pueda ser interpretada tanto por agentes humanos como por agentes automáticos.

Según Berners-Lee, la arquitectura de la Web Semántica se podría representar de la siguiente forma que indica la Figura 8:

Figura 8. Diagrama de lenguajes de la Web Semántica

44

Para que todo esto se haga realidad, se precisa de un lenguaje, una estructura formal para representar el conocimiento asociado a los datos. En la actualidad, se ha acuñado la tecnología ontológica como el método estándar para representar este conocimiento.

Dentro del campo de ingeniería del conocimiento, existen tecnologías que no sólo facilitan la representación del conocimiento, sino que también permiten la reutilización y la compartición de componentes del conocimiento. Una de estas tecnologías son las ontologías (uno de los principales componentes de las Tecnologías Semánticas), que dan cuenta del conocimiento del dominio en términos estáticos y puede definirse como una descripción explícita y formal de una conceptualización. Dicha tecnología se ha utilizado ya para representar conocimiento en distintos tipos de dominios, como los clínicos (Shahar & Musen, 1996; Schulz et al., 1999), las memorias organizacionales (Dieng et al., 1999; Schwartz, 1999), la gestión del conocimiento (Fernandez-Breis, 2003; Sure & Studer, 2003), bioinformática (Stevens et al., 2003) e incluso e-learning (Brase & Nejdl, 2003).

Las ontologías permiten que el conocimiento que éstas contienen pueda reutilizarse y compartirse, por lo que su uso conlleva una reducción del esfuerzo necesario para implementar sistemas expertos. Las ontologías son un concepto clave para las Tecnologías Semánticas (Davies et al., 2003), ya que unen la comprensión simbólica humana con el procesamiento por ordenador. Las ontologías se desarrollaron en Inteligencia Artificial para facilitar la compartición y la reusabilidad. Desde los años 90 ha sido un tema puntero de investigación, y han sido estudiadas en varias comunidades científicas como ingeniería del conocimiento, procesamiento de lenguaje natural o representación de conocimiento.

El motivo de su creciente popularidad es principalmente lo que prometen: una comprensión compartida y común de un dominio que puede ser comunicado entre personas y aplicaciones informáticas. Como tales, el uso de las ontologías ofrece una oportunidad de mejorar las posibilidades de realizar cualquier tarea relacionada con la gestión de información y conocimiento. La mayor parte del trabajo hasta la fecha relacionado con herramientas de ingeniería ontológica se ha centrado (casi exclusivamente) en el uso de ontologías taxonómicas y sólo unos pocos enfoques tienen módulos adicionales. Centrándonos en el problema de la representación de conocimiento, algunos trabajos, que tratan únicamente con taxonomías, han violado algunas reglas taxonómicas fundamentales (Guarino & Welty, 2004).

Las limitaciones en la representación del conocimiento tienen también consecuencias en el diseño de lenguajes ontológicos. De esta forma, en el caso específico de las Tecnologías Semánticas, todo lo hecho hasta el momento para facilitar la interoperabilidad ha sido un mark-up taxonómico. Además, los lenguajes para el intercambio de ontologías más conocidos han sido encontrados restrictivos en aspectos técnicos clave (Fensel et al., 2000). Las ontologías hacen posible el intercambio de semántica (y no sólo sintaxis), de forma que el hecho de que la construcción de ontologías (del dominio) sea rápida y poco costosa es de vital importancia para el éxito y la promoción de las Tecnologías Semánticas (Maedche & Staab, 2001). Sin embargo, el proceso de construcción ontológica es problemático en sí mismo. Diferentes enfoques han intentado especificar y construir ontologías (p.ej., descripciones basadas en lógica, basadas en frames, etc.), aunque ninguna de ellas puede ser considerada realmente como metodología estándar.

Existen diferentes sistemas que permiten la construcción cooperativa de ontologías. En la mayoría de ellos, los usuarios trabajan en la misma ontología, de forma que cuando uno la está modificando, la ontología queda bloqueada para el resto de usuarios, por lo que éstos no pueden acceder a ella. Existen otros sistemas y algoritmos tales como PROMPT (Noy & Musen, 2003) u ODE-Merge, que mezclan ontologías de manera interactiva. Diferentes sistemas de gestión ontológica han sido desarrollados o están siendo

45

desarrollados en la actualidad. Uno de los más completos es el presentado por Das et al. (2001).

En lo referido a los lenguajes utilizados por la Web Semántica para la representación del conocimiento existen diversos modelos que han sido planteados y han ido creciendo a lo largo de los años.

RDF (Klyne & Carrol, 2004) es el primer lenguaje desarrollado específicamente para la Web Semántica. Fue desarrollado como lenguaje para añadir metadatos legibles para la máquina a datos existentes en la web. RDF usa XML para su serialización de modo que se haga uso de las capas definidas con anterioridad. RDF Schema (Brickley & Guha, 2004) extiende RDF con algunas características básicas de modelado ontológico. Existen primitivas tales como clases, propiedades e instancias. El modelo de datos básico de RDF son las tripletas Sujeto-Predicado-Objeto. Un objeto de una tripleta puede funcionar como el sujeto de otra tripleta, cediendo un grafo etiquetado dirigido, donde los recursos (sujetos y objetos) se corresponden con nodos, y los predicados se corresponden con las aristas. Además, RDF permite una forma de reificación (una declaración de una declaración), que significa que cualquier declaración de RDF puede ser usada como sujeto en una tripleta.

RDF Schema (RDFS) es un lenguaje de ontologías ligero usado para definir vocabularios para RDF. Al contrario que XML Schema, que prescribe el orden y combinación de etiquetas (la estructura) en un documento XML, RDF Schema sólo ofrece información sobre la interpretación de las declaraciones dadas en un modelo de datos RDF. RDFS no dice nada sobre la apariencia sintáctica de la descripción de RDF. De hecho, RDFS se puede entender como una extensión de RDF con un vocabulario para definir clases, jerarquías de clases, propiedades (relaciones binarias), jerarquías de propiedades, y restricciones de propiedades. Las clases y propiedades pueden ser instanciadas en RDF. Para una comparación más detallada entre XML Schema y RDF Schema dirigimos al lector al artículo de Klein et al., (2003).

Ontology Web Language (OWL), (Dean & Schreiber, 2004) es un lenguaje de ontologías expresivo que extiende RDFS. OWL está compuesto de tres sublenguajes de expresividad creciente:

OWL Lite: El sublenguaje menos expresivo. Comparado con RDFS, añade restricciones de rango local, restricciones existenciales, restricciones de cardinalidad simple y varios tipos de propiedades (inversa, transitiva y simétrica).

OWL DL: Comparada con OWL Lite, añade soporte total a la negación, disyunción, restricciones de cardinalidad, enumeraciones y restricciones de valor. El elemento “DL” viene por su semejanza a un lenguaje expresivo de lógica de descripciones (Baader et al., 2003).

OWL Full: Mientras que OWL Lite y OWL DL imponen restricciones al uso de vocabulario y el uso de declaraciones RDF, OWL Full no tiene tales restricciones. Por ello, OWL Full permite tanto la especificación de clases como instancias.

Para OWL Lite, aunque tiene muchas restricciones sintácticas, su expresividad actual es muy cercana a la de OWL DL (Horrocks et al., 2003). OWL Full es un lenguaje muy expresivo, y debido a la libertad sintáctica que ofrece, supone que su capacidad de inferencia sea indecidible.

El problema principal para conseguir la interoperabilidad en la Web es el reconocer cuando dos fragmentos de datos se refieren a lo mismo, incluso cuando la terminología

46

usada es distinta. OWL podría ser usado para hacer de puente en el “hueco terminológico”. Específicamente, una ontología incluye cuatro conceptos que forman la base de un documento OWL: clases, relaciones entre clases, propiedades de clases y restricciones en las relaciones entre clases y propiedades de clase. Como resultado, un documento OWL identifica jerarquías de clase, sinónimos, asociaciones de clases, metadatos de propiedades y definiciones de clase, que facilitan los procesos de mapeo de conocimiento almacenado en la web.

SWRL (O'Connor et al., 2005) es una extensión de OWL DL que añade el poder expresivo de las reglas. Mientras que con las ontologías, se podía expresar conocimiento sobre clases, jerarquías de clases, propiedades, etc., las reglas añaden una expresividad complementaria.

Las construcciones básicas de SWRL son reglas Horn. Sin embargo, mientras que las reglas Horn (Horn, 1951) tienen una conjunción de fórmulas atómicas en el antecedente (cuerpo) de la regla y una formula atómica sencilla en el consecuente de la regla, SWRL permite cualquier afirmación sobre la descripción de clase, propiedad o individuo en OWL tanto en el antecedente como el consecuente de la regla. De este modo, SWRL diverge de los sistemas de reglas tradicionales que están basados en la programación lógica o bases de datos deductivas. Debido a la combinación del poder de expresividad total de lógica Horn con un lenguaje de lógica de descripciones, las tareas principales de inferencia (satisfacibilidad o vinculación) son en general no decidibles en SWRL (Motik et al., 2004).

El uso de las Tecnologías Semánticas ha tenido una gran aplicación en ámbitos clínicos. Cabe destacar grandes iniciativas como OBO Foundry (Smith et al., 2007) donde se pretende soportar la integración de datos médicos mediante el uso de ontologías u OpenGalen (Rector et al., 2003) con la creación de terminología médica y herramientas para su uso. Sin embargo, estas no son las únicas iniciativas dentro de las Tecnologías Semánticas y de las técnicas de la Inteligencia Artificial que han surgido a lo largo de los años. Una introspección más detallada se realizará a lo largo del presente documento.

2.2.1.1. ONTOLOGÍAS

Aparte de lo mencionado sobre ontologías y sus principales lenguajes de representación dentro de las Tecnologías Semánticas, a continuación se ofrece una visión más amplia de este término así como una pequeña clasificación del mismo según sus propósitos de uso.

La definición clásica de diccionario del término ontología, identifica a esta como "la rama de la metafísica que estudia la naturaleza de la existencia”. En las aplicaciones del mundo real, sin embargo, la ontología es una entidad de tipo computacional y no debe ser considerado como una entidad natural que se descubre, si no como un recurso artificial que se crea (Mahesh, 1996). Una ontología debe entenderse como un entendimiento común y compartido de un determinado dominio, el cual puede comunicarse entre científicos y sistemas de tipo computacional. Esta última característica, el hecho de que puedan compartirse y reutilizarse en aplicaciones distintas, explica en gran parte el interés que ha suscitado en los últimos años la creación e integración de ontologías (Steve et al., 1998a, b).

El sinónimo más habitual de ontología es el de "conceptualización". Según la definición que proporciona Gruber (1993), una ontología constituye "una especificación formal y explicita de una conceptualización compartida". En esta definición, la cual se ha convertido ya en un estándar, la conceptualización se refiere a un modelo abstracto de algún fenómeno del mundo del que se identifican los conceptos que son relevantes. La palabra "explícita" hace referencia a la necesidad de especificar de forma consciente los

47

distintos conceptos que conforman una ontología. Formal indica que la especificación debe representarse por medio de un lenguaje de representación formalizado y "compartida" refleja que una ontología debe, en el mejor de los casos, dar cuenta de conocimiento aceptado (como mínimo, por el grupo de personas que deba usarla).

Otra definición, más concreta, del término ontología es la ofrecida por Weigand (1997):

An ontology is a database describing the concepts in the world or some domain, some of their properties and how the concepts relate to each other.

Por lo tanto, aunque en filosofía una ontología es una explicación sistemática de la existencia, en los sistemas basados en el conocimiento, lo que existe es exactamente lo que se puede representar, y lo que se representa, mediante un formalismo declarativo, se conoce, con el nombre de Universo de Discurso. El UoD de una ontología por lo tanto es el conjunto de objetos que están representados en ella y sobre los cuales se puede hablar y razonar.

Cuando hablamos de ontologías como "sistemas de representación de conocimiento", se debe especificar a qué tipo de sistemas se está haciendo referencia. En realidad, las ontologías se emplean en todo tipo de aplicaciones informáticas en las que sea necesario definir concretamente el conjunto de entidades relevantes en el campo de aplicación determinado, así como las interacciones entre las mismas. Algunas ontologías se crean con el mero objetivo de alcanzar una comprensión del UoD pertinente, ya que su creación impone una especificación muy detallada. Otras ontologías han sido creadas con un propósito general, como por ejemplo el proyecto CyC (Guha & Lenat, 1990), el cual está orientado a la construcción de una base de conocimiento que contenga el conocimiento humano necesario para hacer inferencias.

Steve et al. (1998) distinguen tres tipos fundamentales de ontologías:

Ontologías de un dominio: Son aquellas en las que se representa el conocimiento especializado pertinente de un dominio o subdominio, como la medicina, las aplicaciones militares, la cardiología, etc.

Ontologías genéricas: Son aquellas en las que se representan conceptos generales y fundacionales del conocimiento como las estructuras parte/todo, la cuantificación, los procesos o los tipos de objetos.

Ontologías representacionales: Son aquellas en las que se especifican las conceptualizaciones que subyacen a los formalismos de representación del conocimiento, por lo que también se denominan meta-ontologías (meta-level o top-level ontologies).

A estos tres tipos, Guarino (1998) añade las ontologías que han sido creadas para una actividad o tarea específica (denominadas task ontologies), como por ejemplo la venta de productos o el diagnóstico de una enfermedad y las ontologías creadas para una aplicación específica.

Dado que el núcleo principal de la tesis se basa en el uso de las Tecnologías Semánticas, y concretamente, las ontologías y sus formas de representación para la generación de sistemas médicos de diagnóstico diferencial en medicina, en esta sección también se va a realizar una breve introducción a los principales conceptos de carácter técnico relacionados con estas tecnologías, que servirán como base para comprender en las subsiguientes secciones los términos que se vayan utilizando.

48

Representación de los datos en ontologías: Lenguaje OWL

El lenguaje de Ontologías Web (OWL) ha sido diseñado con el objetivo de ser utilizado en aplicaciones que necesiten procesar el contenido de la información en lugar de únicamente representar información para el ser humano. Este lenguaje facilita un mejor mecanismo de interpretabilidad de contenido Web que los mecanismos que admiten XML, RDF, y RDF esquema (RDF-S), proporcionando vocabulario adicional junto con una semántica formal.

Para entender en que se basa OWL, se necesita hacer una pequeña descripción de otros lenguajes de la familia de XML, viendo así la necesidad por la que surge OWL y la necesidad que soluciona.

XML: Proporciona una sintaxis superficial para documentos estructurados, pero no impone restricciones semánticas en el significado de los documentos.

XML Schema: Se utiliza para restringir la estructura de los documentos XML, además de ampliar XML con otros tipos de datos.

RDF: Es un modelo de datos para objetos (recursos) y relaciones entre ellos, proporcionando una semántica simple para éste. Este tipo de modelo de datos se puede representar mediante una sintaxis XML.

RDF Schema: Es un vocabulario usado para describir propiedades y clases de recursos RDF, con una semántica para la generalización y jerarquización tanto de propiedades como de clases.

OWL: OWL añade más vocabulario para describir propiedades y clases: entre otros, relaciones entre clases (por ejemplo, desunión), cardinalidad (por ejemplo: "uno exacto"), igualdad, más tipos de propiedades, características de propiedades (por ejemplo, simetría), y clases enumeradas.

En el diseño de las ontologías existen varios elementos principales como son las clases (que permiten especificar y definir los elementos o entidades básicos en las ontologías) y las relaciones, que definen los vínculos entre las entidades.

Por otra parte, los axiomas, que son elementos fundamentales que se usan en los lenguajes como RDF o RDFS entre otros, son fórmulas bien formadas de un lenguaje formal que se acepta sin demostración, como punto de partida para demostrar otras fórmulas. En el caso de las definiciones dentro de las ontologías, los axiomas proporcionan semántica permitiendo a los sistemas la capacidad de inferir información adicional o nueva basada en los datos que se tienen.

2.2.1.2. REPRESENTACIÓN DE CONOCIMIENTO MEDIANTE DESCRIPCIONES LÓGICAS

Se define como descripciones lógicas (DL) a la familia de lenguajes de representación del conocimiento formal. Estos lenguajes son más expresivos que la lógica proposicional, pero tienen problemas de decisión más eficientes que la lógica de primer orden.

El objetivo de las descripciones lógicas en las ontologías y las Tecnologías Semánticas es de proporcionar un formalismo lógico, y más concretamente en el caso de la bioinformática tienen una gran aplicación en la codificación de conocimiento de tipo médico.

49

En las descripciones lógicas se modelan conceptos, roles e instancias y sus relaciones. El concepto fundamental a la hora de modelar una descripción lógica es el axioma (una sentencia lógica que relaciona roles y/o conceptos (Cuenca-Grau et al., 2008)).

A diferencia de los demás sistemas de representación (redes semánticas y frames), estas lógicas están dotadas con una semántica formal basada en lógica y tienen características muy importantes como son:

Un formalismo descriptivo: conceptos, roles, individuos y constructores.

Un formalismo terminológico: axiomas terminológicos que introducen descripciones complejas y propiedades de la terminología descriptiva.

Un formalismo asertivo: que introduce propiedades de individuos. Son capaces de inferir nuevo conocimiento a partir de conocimiento

dado; tienen por tanto, algoritmos de razonamiento que son decidibles.

Los elementos centrales del alfabeto del lenguaje de las lógicas de descripción son:

Nombres de concepto (concept name): Asignan un nombre a un grupo de objetos.

Nombres de rol (role name): Asigna un nombre a una relación entre objetos.

Nombres de individuos (u objetos): Los individuos son instancias de los conceptos y también se pueden relacionar por medio de un rol.

Constructores (constructor): Relaciona nombres de conceptos y nombres de roles, y también crea conceptos complejos a partir de los atómicos (complex concepts).

Definiciones de conceptos complejos: Usa los símbolos para declarar conjunto de igualdades y conjuntos de inclusiones.

La Tabla 1 muestra una representación de los sinónimos entre OWL y DL.

OWL DL Class Concept

Property Role Object Individual

Tabla 1. Sinónimos entre OWL y DL

Existen diversas variedades de descripciones lógicas y existe una convención de tipo informal para llamarlas, fundamentalmente basándose en los operadores permitidos. La expresividad es codificada en la etiqueta para una lógica concreta usando las siguientes letras:

: Propiedades funcionales. : Cualificación de existencial completo. : Unión de conceptos. : Negación de conceptos compleja. : Abreviación para con roles transitivos. : Jerarquía de roles. : Axiomas de inclusión de roles complejos limitados; reflexividad

e irreflexibilidad; disyunción de roles. : Nominales. : Propiedades inversas.

50

: Restricciones de cardinalidad.

: Restricciones de cardinalidad cualificadas. : Uso de propiedades de tipo DataType.

2.2.1.3. ABOX Y TBOX

En descripciones lógicas existe una distinción entre la llamada TBox (Caja de términos o terminológica) y la ABox (Caja de aserciones). En general la TBox contiene sentencias que describen conceptos jerárquicos (por ejemplo: relaciones entre conceptos) mientras que la ABox contiene sentencias de tipo "ground" que indican a donde pertenecen los individuos dentro de la jerarquía (por ejemplo: relaciones entre individuos y conceptos). Como ejemplo, la sentencia:

(1) Cada empleado es una persona

Pertenece a la caja terminológica (TBox), mientras que la sentencia:

(2) Bob es un empleado

Pertenece a la caja de aserciones (ABox). Nótese que la distinción entre TBox y ABox no es significativo en el mismo sentido que en la lógica de primer orden (la cual subsume la mayoría de las DL). Los dos tipos de sentencias se tratan de la misma forma. Cuando se traduce a lógica de primer orden, un axioma de subsunción como el que representa (1), se trata simplemente de un condicional restringido a predicados de tipo unario (conceptos), donde sólo aparecen variables. Una sentencia con esta forma no recibe un tratamiento distinto de las sentencias donde únicamente aparecen constantes (valores "ground") como en (2).

La principal razón para hacer esta distinción es que puede ser útil para describir y formular procedimientos de decisión para varias DL. Por ejemplo, un razonador podría procesar tanto la TBox como la ABox por separado. Ciertos problemas claves en términos de inferencia están ligados a una pero no a la otra (el proceso de clasificación está relacionado con la TBox y el de chequeo de instancia con la ABox). Además, la complejidad de la TBox puede afectar considerablemente al rendimiento de un procedimiento de decisión para una cierta DL, independientemente de la ABox.

Otro motivo de esta distinción es que tenga sentido desde el punto de vista del que se modela la base de conocimiento. Es conveniente poder distinguir entre los conceptos en el mundo (axiomas de clase en la TBox) y las manifestaciones particulares de esos conceptos (aserciones de instancia en la ABox).

Lógica

Las lógicas (AL por attributive language) constituyen una familia de lógicas populares. Cada una agrega letras a su nombre para indicar su poder expresivo. Una lógica popular es la lógica , la cual utiliza una notación estándar, comúnmente conocida como sintaxis alemana debido a la nacionalidad de sus creadores, que se ha adoptado ampliamente para la discusión teórica sobre DL. Esta notación usa los siguientes símbolos:

y para operadores de conjunción y disyunción, reflejando su interpretación del modelo teórico como el conjunto de intersección y unión.

y como cuantificadores lógicos estándar, símbolos para restricción de valor y restricción existencial.

como complemento.

51

Los símbolos de relación y se usan en axiomas y reflejan su interpretación en el modelo teórico como conjunto de igualdad y conjunto de inclusión.

La sintaxis de estas lógicas soportan la descripción lógica de conceptos, roles (relaciones) e individuos, donde los conceptos y roles pueden ser combinados, usando una variedad de operadores, para formar expresiones más complejas. Los operadores soportados por las lógicas de descripción, normalmente incluyen algunas o todas las conectivas lógicas estándares junto con uno o ambos operadores relacionales (cuantificadores universales y existenciales llamados restricciones de valor y restricciones existenciales).

Formalmente una terminología en está definida por la siguiente formación de reglas:

Los axiomas son de la forma donde C y D son las expresiones de concepto.

Las expresiones de concepto de la forma:

donde CN es un nombre de concepto (conceptos atómicos) y R es una expresión de rol.

El nombre de concepto (top) representa el concepto más general. El nombre de concepto (bottom) representa el concepto menos general.

La Semántica busca explicar la relación que existe entre la sintaxis del lenguaje y los modelos previstos del dominio, dando significado a las expresiones, el cual es dado por el modelo teórico semántico. Este modelo teórico fue propuesto por Tarski, donde los conceptos y roles se refieren a conjuntos de objetos en el dominio de interés y las

relaciones entre ellos. Formalmente el modelo teórico se da por: , el cual

consta de un conjunto no vacío , llamado el dominio de , y una función (la

función de interpretación de ), que asigna a cada concepto un subconjunto de , cada

rol a un subconjunto de y a cada individuo un elemento de , de tal manera que:

Es decir:

Un concepto es interpretado como un conjunto de individuos Los roles son interpretados como conjuntos de pares de individuos. Los conceptos atómicos se interpretan como subconjuntos del

dominio de la interpretación.

La semántica de los constructores son entonces especificados por definiciones de conjunto de individuos denotados por cada constructor. Por ejemplo:

52

es el conjunto de individuos obtenidos por la intersección de conjuntos de individuos denotados por C y D, respectivamente.

es el conjunto de individuos que están en la relación R con los individuos que pertenecen al conjunto denotado por el concepto C.

El poder expresivo de una lógica de descripción es la capacidad para representar “conocimiento” acerca del dominio y depende de la riqueza de su lenguaje.

El lenguaje de la lógica no es muy expresivo. Para comprobarlo basta ver estos ejemplos de “información” básica sobre un dominio sencillo no expresable en :

“Una mujer que tiene exactamente dos hijos” (no es posible expresar restricciones numéricas).

“Todo hombre es hijo de una mujer” (no es posible expresar el inverso de un rol).

“La madre del padre es la abuela” (no es posible expresar composición de roles).

Es necesario extender el lenguaje de , pero añadiendo los elementos necesarios de forma que la complejidad computacional no sea intratable, ya que queremos poder razonar con esa lógica y, en particular, disponer de los algoritmos mínimos de satisfacibilidad, subsumición y consistencia. Veamos los constructores más importantes utilizados para extender el lenguaje y también algunos de los sistemas obtenidos extendiéndola.

Restricciones numéricas : Restricciones numéricas

cualificadas :

Restricciones Funcionales :

Nominales : Dominios concretos: Un dominio concreto D es un conjunto Δ(D) (el

dominio) más un conjunto pred(D) de los nombres de predicado de D. Cada nombre de predicado P de D se asocia con una aridad n y un predicado n-ario de Δ(D).

Ejemplo: El dominio concreto , tiene como dominio el conjunto de los números naturales y pred( ) el conjunto de los predicados binarios <, ≤, >, y ≥ .

Las lógicas de descripción mucho más expresivas también emplean constructores de roles, dado que los roles se interpretan como relaciones binarias; esto implica definir constructores cuya semántica es la de las operaciones sobre relaciones. Dónde: si R y S son descripciones de rol (atómico) también lo son:

Unión de roles: Intersección de roles: Complemento de rol: Composición de roles:

Rol inverso : R − Rol transitivo: R +

La terminología también permite incluir jerarquía de roles donde los axiomas son de la forma:

53

La semántica para las expresiones de descripción lógicas expuestas anteriormente se da; según reza la Tabla 2:

Axiomas Semántica Ejemplo { | { | { | { |

{ | { | { | { | {

{

| { | { | ⋃

Tabla 2. Semántica para las expresiones de descripción lógica

Inferencia

Las lógicas de descripción son algo más que lenguajes para formalizar conceptos: Deben representar la ontología de un dominio de aplicación y permitir razonar sobre él. Para ello se introducen nuevos elementos en el lenguaje y la semántica necesaria para formalizar las propiedades de los individuos del dominio y de las relaciones entre conceptos y roles.

Base de conocimiento

La base de conocimiento está formada por los componentes TBox y ABox.

El TBox, como se ha comentado previamente, contempla toda la terminología, o sea, el vocabulario de un dominio de aplicación en función de:

Conceptos: denotan clases o conjunto de individuos. Roles: denotan relaciones binarias entre los individuos. Un conjunto de descripciones complejas sobre este vocabulario

(restringidos, por supuesto, por el lenguaje de descripción).

El ABox contiene aserciones acerca de individuos nombrados en términos de vocabulario.

Una base de conocimiento (TBox y ABox) es equivalente a un conjunto de axiomas de la LPO (Lógica de primer orden), y por tanto se puede definir un cálculo o sistema de inferencia que permite derivar “conocimiento” implícito a partir del “explícito” de la base de conocimiento.

Razonamiento con conceptos (TBox)

Supongamos que tenemos un lenguaje descriptivo para un dominio, por ejemplo , y que se ha definido una TBox (axiomas terminológicos) para modelar un dominio. Si se define un nuevo concepto es importante saber si es consistente o

54

contradictorio con el TBox. Esta propiedad se conoce como el concepto satisfacible (o respectivamente insatisfacible) con respecto al TBox. También puede ser necesario saber si un concepto es más general que otro, si son equivalentes o si son disjuntos. La formalización de estas propiedades es la siguiente:

Supongamos que es un TBox, C y D conceptos:

C es satisfacible con respecto a si existe un modelo tal

que . C es subsumido por D con respecto a si para todo

modelo de , tenemos que . Esto se

escribe: .

Razonamiento con individuos (ABox)

Una vez definida una TBox, al definir el ABox, las propiedades más importantes que habrá que verificar son las de la consistencia del Abox y el TBox , y la derivación de una instanciación a partir del ABox. Veamos formalmente estos conceptos:

Supongamos que es un TBox, A es un ABox, C un concepto y/o nombre de individuo:

A es consistente con respecto a si existe una interpretación que es modelo de y de A.

o:C se deriva de y A si todo

modelo de cumple . esto es: .

Sistema

Esta es otra notación muy utilizada por algunos sistemas de lógicas de descripción. La importancia de esta lógica, radica en que es la que actualmente se está implementando para las ontologías dependiendo de las necesidades del programador. El sistema se da de la siguiente manera:

es + roles transitivos + inclusión

roles. es + nominales. Se demuestra también

que es extendida con restricciones

cualificadas. es + nominales + dominios concretos ( ).

Aunque extender una lógica con dominios concretos la dota de una expresividad muy valorada para representar ontologías, fácilmente puede llevar a la indecidibilidad.

Veremos, sin embargo, que es decidible y es base para el lenguaje de ontología actualmente más aceptado.

Las lógicas de descripción fueron pensadas como sistemas formales para representar conocimiento, y esto significa ir más allá de almacenar terminologías y descripciones. En particular, significa poder derivar hechos implícitos a partir de los dados. Por este motivo la implementación de procesos de inferencia debe tener en cuenta la posibilidad de usar algoritmos de inferencia óptimos. En el estudio de tales algoritmos el punto de partida es conocer su complejidad computacional (por ejemplo la complejidad EXPTIME y PSPACE).

55

Encontrar algoritmos de decisión para los problemas de inferencia como satisfacibilidad, subsumición y consistencia en ABoxes para lógicas de descripción expresivas y con la menor complejidad posible, de forma que la implementación computacional sea afrontable, es todo un reto.

La búsqueda de estos procedimientos de decisión ha sido uno de los objetivos fundamentales en el desarrollo de las lógicas de descripción. Una de las maneras de obtenerlos es estudiando la conexión de las lógicas de descripción con otras lógicas conocidas. Es el caso de la decidibilidad en todas sus extensiones que se obtienen añadiendo constructores que en la lógica de primer orden (LPO) se pueden expresar con dos variables. Sin embargo, la complejidad del procedimiento de decisión obtenido de esta manera es normalmente mayor del que realmente se necesita; por ejemplo el problema de satisfacibilidad para la LPO con dos variables es NEXPTIME (que es una complejidad muy grande, aunque todavía es decidible) mientras que en es PSPACE-hard (es una complejidad menor). Otra manera de estudiar la complejidad es usando la conexión con las lógicas modales proposicionales.

2.2.1.4. REGLAS. ESPECIFICACIÓN DE REGLAS JENA RULES

El motor de inferencia basado en reglas de la API de Jena juega un papel fundamental en el desarrollo de la presente tesis.

El motor de reglas de Jena soporta inferencia basada en reglas sobre grafos RDF y proporciona modelos de ejecución basados en forward chaining (encadenamiento hacia adelante), backward chaining (encadenamiento hacia atrás) e híbridos. Para ser más exactos, existen dos motores de reglas internos, uno basado en el algoritmo RETE (Forgy, 1974; Forgy, 1979; Forgy, 1982) para forward chaining y otro basado en un motor basado en Datalog (Gallaire & Minker, 1977).

Estructura y sintaxis de las reglas

Las reglas son definidas como objetos de reglas de Java con una lista de términos en el cuerpo (premisas), una lista de términos en la cabeza (conclusiones) y un nombre y dirección opcional. Cada término es un patrón de tripletas, un patrón extendido de tripletas o una llamada a una primitiva de tipo built-in. Un conjunto de reglas es simplemente una lista de reglas.

El motor de reglas de Jena utiliza por conveniencia un parser de reglas, que permite que las reglas sean especificadas en un compacto razonable en ficheros de texto. Sin embargo, también se permite la especificación de definir parsers alternativos que sean capaces de manejar reglas utilizando otro tipo de formatos, como XML o RDF y generar objetos de tipo regla como salida.

Motor Forward Chaining

El funcionamiento del motor de razonamiento en modo forward chaining depende de que este esté configurado para tal opción. La primera vez que el modelo de inferencia se consulta (o cuando se hace una llamada al método prepare()), entonces todos los datos relevantes que se encuentren en el modelo serán enviados al motor de reglas.

Una vez la fase de preparación esté completada, el grafo de inferencia actuará como si se hubiera generado una unión de todas las sentencias del modelo original con las sentencias de las deducciones internas generadas por el disparo de las reglas.

56

Las reglas en formato forward funcionan de forma incremental, y solo se explorarán las consecuencias de las tripletas añadidas o borradas. El motor de reglas por defecto está basado en el algoritmo RETE, el cual está optimizado para estos cambios incrementales.

Cuando se ejecuta el motor en modo forward, todas las reglas son tratadas como forward incluso aunque se hayan escrito en formato backward (<-). Esto permite que el mismo conjunto de reglas pueda ser usado en diferentes modelos.

Motor Backward Chaining

Si el razonador de reglas está ejecutándose en modo backward, se utilizará un motor de programación lógica con una estrategia de ejecución similar a la de los motores de Prolog. Cuando se consulta el modelo de inferencia, entonces la consulta se traduce en un objetivo, y el motor trata de satisfacerlo correspondiéndolo con cualquier tripleta almacenada y mediante resolución de objetivos contra las reglas.

Excepto en el caso que se muestra más abajo, las reglas serán ejecutadas de arriba hacia abajo y de izquierda a derecha con backtracking, como en una resolución SLD (Selective Linear Definite) (Kowalski, 1973; Kowalski & Kuehner, 1971). De hecho, el lenguaje de reglas es esencialmente Datalog en vez de Prolog, mientras que la sintaxis del functor dentro de las reglas permite la creación de algunas estructuras de datos anidadas.

Como un lenguaje Datalog, la sintaxis de las reglas es sorprendente dado que restringe que todas las propiedades sean binarias (como en RDF) y permite a las variables estar en cualquier posición (incluida la posición de las propiedades).

Por otra parte, la programación lógica soporta tabling. Cuando un objetivo es presentado, entonces todas las coincidencias que fueron computadas previamente para un determinado objetivo son guardadas (memorizadas) y usadas cuando satisfagan futuros objetivos similares. Cuando un objetivo que ha sido presentado es llamado y todas las respuestas conocidas han sido consumidas, entonces el objetivo se suspenderá hasta que alguna otra rama de la ejecución haya generado nuevos resultados. Esto permite que la ejecución de reglas de forma recursiva sin caer en un bucle infinitico como pasaría en SLD de Prolog. Esta estrategia de ejecución, SLG, es básicamente la misma que la que es usada en el sistema XSB (Sagonas et al., 1994; Rao et al., 1997).

En el sistema de reglas de Jena los objetivos a los que se realizará tabling son identificados por la propiedad 'campo' de la tripleta. Se puede solicitar que todos los objetivos sean tableados llamando a la primitiva tableAll() o que todos los objetivos que estén envueltos mediante una propiedad P sean tableados mediante una llamada a table(P). Se debe tener en cuenta que si cualquier propiedad es tableada, entonces los objetivos del tipo (A, ?P, ?X) serán tableados también debido a que la variable propiedad debe coincidir con una de las propiedades tableadas.

Los resultados de aplicar tabling en cada consulta se guardan de forma indefinida. Esto significa que las consultas pueden explotar todos los resultados de los sub objetivos envueltos en las consultas previas. En esencia, se genera un cierre del conjunto de datos como respuesta a las consultas posteriores. La operación reset() en el modelo de inferencia forzará a que esos resultados a los que se ha realizado tabling se descarten, y por lo tanto se guardará memoria y se ahorrará tiempo de respuesta en consultas futuras.

Cuando el modelo de inferencia es actualizado mediante añadir o borrar sentencias, todos los resultados tableados son descartados mediante un reset() interno, y la siguiente consulta se encargará de reconstruir los resultados tableados desde cero.

57

Se debe tener en cuenta que las reglas backward solo pueden tener un consecuente, por lo tanto, si se escriben reglas que se pretendan que funcionen en ambos modos (backward o forward), se debe limitar cada una a un solo consecuente.

Motor de reglas híbrido

El razonador de reglas tiene la opción de emplear ambos motores de reglas de forma conjunta. Cuando se ejecuta en este modo híbrido, el flujo de datos es similar a lo que representa la Figura 9:

Figura 9. Motor de reglas híbrido de Jena

El motor de reglas forward funciona como se ha descrito anteriormente manteniendo un conjunto de sentencias inferidas en el almacén de deducciones. Cualquier regla de tipo forward que afirme nuevas reglas en formato backward instanciará dichas reglas de acuerdo a los enlaces de las variables forward y pasará las reglas instanciadas al motor de reglas backward.

Las consultas son respondidas usando el motor de programación lógica backward chaining, empleando la fusión de las reglas proporcionadas y generadas aplicadas a la fusión de los datos deducidos y en bruto.

La separación permite al desarrollador del conjunto de reglas obtener mejor rendimiento mediante la inclusión únicamente de reglas en formato backward, las cuales son relevantes para el conjunto de datos tratado. En particular, se pueden usar las reglas de tipo forward para compilar un conjunto de reglas backward a partir de la información de la ontología en el conjunto de datos.

Primitivas Builtin

Los procedimientos primitivos que pueden ser llamados por las reglas están implementados como un objeto Java almacenado en un registro. De forma adicional, las primitivas pueden ser creadas y registradas.

Cada primitiva puede ser usada de forma opcional tanto en el cuerpo de la regla, como en la cabeza, como en ambos. Si se usa en el cuerpo de la regla, la primitiva puede actuar como una prueba (si devuelve false la regla no coincidirá). Las primitivas que se usan en la cabeza de la regla solo tienen como objetivo actuar en los efectos de la regla.

A continuación se muestra la Tabla 3, que muestra el conjunto de primitivas builtin de las que dispone el motor de reglas.

58

Builtin Operaciones sLiteral(?x) notLiteral(?x) isFunctor(?x) notFunctor(?x) isBNode(?x) notBNode(?x)

Se encarga de comprobar si el argumento recibido es o no un litera, un literal functor o un nodo en blanco respectivamente.

bound(?x...) unbound(?x..) Comprueba si los argumentos son variables ligadas o no. equal(?x,?y) notEqual(?x,?y) Comprueba si x = y (o x != y). La igualdad es igualdad

semántica, por lo tanto, por ejemplo, xsd:int 1 y xsd:decimal 1 serían iguales.

lessThan(?x, ?y), greaterThan(?x, ?y)

le(?x, ?y), ge(?x, ?y)

Comprueba si x es <, >, <= o >= y. Devolverá true solo en el caso de que x e y sean números o instantes de tiempo (pueden ser enteros, flotantes o XSDDateTime).

sum(?a, ?b, ?c) addOne(?a, ?c) difference(?a, ?b, ?c) min(?a, ?b, ?c) max(?a, ?b, ?c) product(?a, ?b, ?c) quotient(?a, ?b, ?c)

Establece c como la suma (a+b), el incremento (a+1), la resta (a-b), el mínimo (min(a,b,)), el máximo (max(a,b)), la multiplicación (a*b) o la división (a/b). Téngase en cuenta que no funciona en modo backward, si en una suma a y c son variables ligadas y b no es ligada, entonces el resultado fallará.

strConcat(?a1, .. ?an, ?t) uriConcat(?a1, .. ?an, ?t)

Concatena la forma léxica de todos los argumentos excepto el último, para enlazar este último argumento con un literal plano/vacío (strConcat) o un nodo URI (uriConcat).

regex(?t, ?p) regex(?t, ?p, ?m1, .. ?mn)

Compara la forma léxica de un literal (?t) contra un patrón de expresión regular proporcionado por otro literal (?p). Si hay coincidencia, y si existen argumentos adicionales entonces enlazará los primeros "n" grupos con los argumentos de ?m1 a ?mn. La sintaxis de expresiones regulares es la que proporciona java.util.regex.

now(?x) Enlaza ?x con un valor de xsd:dateTime que corresponda a la hora actual.

makeTemp(?x) Genera un nodo en blanco y lo enlaza con ?x. makeInstance(?x, ?p, ?v) makeInstance(?x, ?p, ?t, ?v)

Genera una instancia que será almacenada en ?v de tal forma que se enlace la propiedad ?p con el recurso ?x y que opcionalmente tenga el tipo ?t.

makeSkolem(?x, ?v1, ... ?vn) Genera un nodo en blanco en ?x basándose en los valores del resto de los ?vi argumentos, de tal forma que la misma combinación de argumentos siempre generaría el mismo bNode.

noValue(?x, ?p) noValue(?x ?p ?v)

Devuelve verdadero si no existe una tripleta (x,p,*) o (x,p,v) en el modelo o en las deducciones forward explicitas.

remove(n, ...) drop(n, ...)

Borra la sentencia (tripleta) que causó que el enésimo término del cuerpo (solo en modo forward) de la regla coincida. La primitiva remove se propagará para cambiar otras reglas de forma consecuente incluyendo la regla de disparo. La primitiva drop borrará de forma silenciosa las tripletas del grafo, pero no disparará ninguna regla como consecuencia.

isDType(?l, ?t) notDType(?l, ?t) Comprueba si un literal ?l es (o no) una instancia de tipo de datos definida por el recurso ?t.

print(?x, ...) Imprime (a la salida estándar) la representación de cada argumento. Esta primitiva es útil para depurar.

listContains(?l, ?x) listNotContains(?l, ?x)

Primitiva usada para comprobar si una lista determinada contiene o no un elemento.

listEntry(?list, ?index, ?val) Enlaza ?val con la entrada en la posición ?index de la lista en RDF ?list.

listLength(?l, ?len) Añade el tamaño proporcionado (?len) a la lista (?l)

59

listEqual(?la, ?lb) listNotEqual(?la, ?lb)

listEqual comprueba si los dos argumentos son ambos listas y contienen los mismos elementos. La igualdad es igualdad semántica sobre los literales (sameValueAs) pero no tendrá en cuenta los alias owl:sameAs. listNotEqual es la negación.

listMapAsObject(?s, ?p ?l) listMapAsSubject(?l, ?p, ?o)

Estas primitivas solo pueden ser usadas como acciones en la cabeza de la regla. Están diseñadas para deducir un conjunto de tripletas derivadas de la lista de argumentos ?l: listMapAsObject declara tripletas (?s ?p ?x) para cada ?x en la lista ?l. listMapAsSubject declara tripletas (?x ?p ?o).

table(?p) tableAll() Declara que todos los objetivos que hagan uso de la propiedad ?p (o todos los objetivos: tableAll()) deberían ser tableados para el motor backward.

hide(p) Declara que las sentencias que estén involucradas con el predicado p deben ser ocultadas. Las consultas por lo tanto que se hagan al modelo no devolverán dichas sentencias. Esto es útil para activar reglas de tipo forward no monótonas.

Tabla 3. Builtins de Jena Rules

2.2.1.5. SPARQL

SPARQL es un lenguaje de consulta en formato muy similar a SQL. Al contrario de los lenguajes vistos hasta ahora, SPARQL no busca la representación de ontologías y recursos, sino la consulta de datos Web; precisamente, se trata de un lenguaje de consulta para RDF (SPARQL, 2005). Para entender SPARQL, la visión de los recursos RDF como redes semánticas ayuda. SPARQL puede ser usada para:

Extraer información de grafos RDF en la forma de URIs, Nodos en blanco, y literales.

Extraer subgrafos RDF. Construir nuevos grafos RDF basados en la información consultada

en grafos.

Las consultas SPARQL hacen corresponder patrones de grafos contra el grafo objetivo de la consulta. Los patrones son como grafos RDF, pero pueden contener variables nombradas en vez de alguno de los nodos (recursos) o enlaces/predicados (ej. propiedades).

SPARQL permite a los usuarios escribir consultas de forma global sin ambigüedad. Por ejemplo, la siguiente consulta devuelve los nombres y los emails de cada persona en el mundo:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

SELECT ?name ?email

WHERE {

?person a foaf:Person.

?person foaf:name ?name.

?person foaf:mbox ?email.

}

Snippet 1. Ejemplo de SPARQL

Asumiendo que las ontologías en uso para describir a una persona de forma eventual convergen a FOAF (Kruk, 2001; Brickley & Miller, 2005; Ding et al., 2005). Este

60

ejemplo ilustra la visión de la Web Semántica de tratar a la web como una gran base de datos.

El siguiente ejemplo de consulta de SPARQL modela la pregunta: ¿Cuales son todos los países de África?

PREFIX abc: <http://example.com/exampleOntology#>

SELECT ?capital ?country

WHERE {

?x abc:cityname ?capital ;

abc:isCapitalOf ?y .

?y abc:countryname ?country ;

abc:isInContinent abc:Africa .

}

Snippet 2. Ejemplo concreto de SPARQL

Las variables se indican mediante el prefijo "?" o "$". Los resultados devueltos son las referencias para las variables ?capital y ?country.

El procesador de consultas de SPARQL buscará aquellas tripletas que coinciden con los cuatro patrones de tripletas, enlazando las variables de la consulta con las partes correspondientes de cada tripleta. Es importante recalcar la "orientación de propiedades" (las coincidencias de clases puede llevarse a cabo solamente a través de los atributos de clase / propiedades).

Para hacer una consulta concisa, SPARQL permite la definición de prefijos y URIs base de forma similar a Turtle (Becket & Berners-Lee, 2008). En esta consulta de ejemplo el prefijo abc hace referencia a http://example.com/exampleOntology#.

2.2.2. SISTEMAS BASADOS EN REGLAS

Los sistemas basados en conocimiento con grandes estructuras de conceptos y reglas están siendo utilizados de forma extensiva en una gran cantidad de aplicaciones. Sin embargo, los problemas asociados con el desarrollo y mantenimiento de grandes sistemas basados en reglas son un impedimento que está limitando las posibilidades de este tipo de herramientas. Una de las soluciones aportadas a este problema ha sido el diseño de estructuras basadas en conocimiento que reducen las interacciones entre las reglas. Por ejemplo, Ripple Down Rules (RDR) es una técnica de adquisición de conocimiento desarrollada a partir de la experiencia en el mantenimiento de un sistema experto (Compton et al., 1989). La principal motivación para desarrollar RDR fue el hecho de que los expertos encontraban muy complicado explicar cómo habían alcanzado unas determinadas conclusiones. Sin embargo, eran capaces de justificar la corrección de estas conclusiones considerando el contexto en que estas conclusiones habían sido extraídas. RDR usa únicamente el conocimiento proporcionado por los expertos en el contexto en el que éste fue proporcionado, esto es, siguiendo la secuencia de reglas evaluadas. Además, si el experto no está de acuerdo con una conclusión, se puede añadir conocimiento nuevo en forma de una regla nueva. De este modo, las reglas no se corrigen o eliminan, sólo se añaden.

Se han elaborado tres aproximaciones para sistemas basados en RDR. La más destacada es, sin duda, Múltiple Classification Ripple Down Rules (MCRDR) (Kang et al., 1994). MCRDR es una extensión de los aspectos básicos de RDR para conseguir múltiples conclusiones independientes. Con MCRDR es posible obtener conclusiones más generales que la clasificación simple que utiliza RDR. Cuando los expertos mantienen un sistema

http://example.com/exampleOntology

61

MCRDR deben desarrollar una regla que contenga las diferencias entre el caso introducido en el sistema y el caso asociado a la última regla verdadera en la base de conocimiento. Este proceso se repetirá hasta que no haya ningún caso (asociado a ninguna regla) que satisfaga la regla.

La lógica fuzzy ha sido ampliamente utilizada en el campo de la Inteligencia Artificial para interpretar los casos ambiguos e incompletos asociados a las bases de reglas. Como consecuencia, la lógica fuzzy es aplicable al campo de los sistemas basados en el conocimiento con el propósito de hacer este tipo de herramientas más flexibles. En particular, la lógica fuzzy es una aproximación útil para el modelado de bases de reglas. De este modo, las opiniones de los expertos podrían ser modeladas en consonancia con la ambigüedad intrínseca en el lenguaje humano a través de lógica fuzzy. Actualmente, la tecnología fuzzy está siendo empleada para generar, mantener y mejorar bases de conocimiento (Pham & Chen, 2002; Boegl et al., 2004). Sin embargo, en estas aproximaciones no se contempla la filosofía incremental asociada a RDR. En particular, cuando una nueva regla se añade a esas bases de conocimiento, no existe un mecanismo que permita unir esas reglas a las ya existentes en la base de conocimiento. Con el fin de solucionar esta limitación, se han propuesto diferentes sistemas que hacen uso de métodos de aprendizaje automático (machine learning) a partir de un conjunto de ejemplos del dominio de aplicación (Castro et al., 2001; Beynon et al., 2004; Castro-Sánchez et al., 2004).

Una de las motivaciones fundamentales de esta tesis está basada en el uso y mejora de los actuales sistemas de reglas (Hayes-Roth, 1985), en los cuales están basados la mayoría de los sistemas de soporte a la decisión (Watson-Sprague, 1990). El objetivo es dar una nueva perspectiva al uso de los sistemas basados en reglas, con las nuevas tecnologías de la información, en este caso, nuevamente aprovechando las capacidades que las Tecnologías Semánticas ofrecen de cara a la inferencia lógica, la cual permite la construcción de sistemas basados en reglas adaptados a estas tecnologías (Boley et al., 2003), (O’Connor et al., 2005).

Existen muchos trabajos en los que se usan los sistemas de reglas para la generación de sistemas basados en reglas para el diagnóstico médico. Algunos trabajos como el de Rotshtein (1999), se centran en el diseño y afinamiento de sistemas basados en reglas fuzzy para sistemas de diagnóstico médico. En Binaghi (1990), ya se plantean algunos de los primeros modelos para sistemas basados en reglas con inferencia lógica difusa para la generación de sistemas de diagnóstico.

Otras iniciativas como la expuesta por Tsumoto (1998), tratan de solventar el problema de la adquisición del conocimiento automático de reglas a partir de bases de datos clínicos mediante rough sets.

Una de las iniciativas más populares de diagnóstico clínico a partir de un sistema basado en reglas fue el ya mencionado MYCIN (Shortliffe et al., 1976; Shortliffe, 1975). Otras proponen la creación de este tipo de sistemas utilizando estas tecnologías como técnicas de aprendizaje (Michalowski et al., 1993).

2.2.3. SISTEMAS DE INFERENCIA LÓGICA

La inferencia es el proceso de llegar a una conclusión aplicando reglas (o lógica, estadística, etc.) a observaciones o hipótesis, o interpolando el siguiente paso lógico en un patrón intuitivo. La conclusión arrojada también es llamada inferencia. El razonamiento, asociado también al concepto de inferencia, es un término más general que se aplica a alguna forma de sacar conclusiones nuevas a partir de un conjunto de premisas, habiendo tres categorías principales de razonamiento: deductivo, inductivo y abductivo. Se podría

62

considera que el razonamiento es el objetivo mientras que la inferencia es la implementación para conseguir este objetivo.

En este aspecto, la lógica estudia las leyes de inferencia válidas, y la estadística por ejemplo han desarrollado reglas formales para la inferencia a partir de datos cuantitativos.

El proceso por el cual una conclusión es lógicamente inferida a partir de ciertas premisas se llama razonamiento deductivo o lógica deductiva (Johnson-Laird, 1999). Este proceso es un proceso de razonamiento en el cual se construye o evalúa argumentos deductivos. En lógica, un argumento se dice que es deductivo cuando la veracidad de la conclusión pretende seguir o ser necesariamente una consecuencia lógica de la veracidad de las premisas, y, consecuentemente su condicional correspondiente es una verdad necesaria.

Por otra parte, el proceso por el cual una conclusión se infiere a partir de múltiples observaciones se llama razonamiento inductivo, inducción, o lógica inductiva (Pellegrino & Glaser, 1980). Es un tipo de razonamiento que implica moverse a partir de un conjunto de hechos específicos a una conclusión general. La conclusión puede ser correcta o incorrecta, o correcta con un determinado grado de veracidad, o correcta en ciertas situaciones. Las conclusiones inferidas a partir de múltiples observaciones deben ser comprobadas por observaciones adicionales.

Finalmente, el razonamiento abductivo, es un tipo de razonamiento en el que se opera con una especie de silogismo en donde la premisa mayor es considerada cierta mientras que la premisa menor es solo probable, por este motivo la conclusión a la que se puede llegar tiene el mismo grado de probabilidad que la premisa menor.

Los sistemas de Inteligencia Artificial en primer lugar proporcionaron inferencia lógica automática, y estos se volvieron extremamente populares en ámbitos de investigación, guiando a las aplicaciones industriales bajo la forma de sistemas expertos y después como motores de reglas de negocio.

El trabajo de un sistema de inferencia es extender la base de conocimiento de forma automática. La base de conocimiento es un conjunto de proposiciones que representan lo que el sistema sabe acerca del mundo. Varias técnicas pueden ser usadas por el sistema para extender las bases de conocimiento a través de inferencia válida.

2.2.4. TECNOLOGÍAS DE SOPORTE A LA DECISIÓN (DSS)

De acuerdo con Keen (1978), el concepto de soporte a la decisión ha evolucionado a partir de dos áreas de investigación principales: Los estudios teóricos de toma de decisiones en organizaciones hechos en el instituto tecnológico Carnegie durante los últimos años de 1950 y principio de 1960, y los trabajos técnicos en sistemas informáticos interactivos, principalmente realizados en el instituto tecnológico de Massachusetts. Está considerado que el concepto de sistema de soporte a la decisión (DSS) se convirtió en un área de investigación por sí mismo a mitad de los años 70, antes de ganar en intensidad durante los años 80. En la mitad y al final de los 80, los sistemas de información ejecutiva (EIS - Executive Information System) (Thierauf, 1991; Watson & Walls, 1993; Watson et al., 1991; Wang et al., 2008; Tiomothy, 1998; Omar, 1992; Leidner & Elam, 1993), los sistemas de soporte a la decisión de grupos (GDSS - Group Decision Support System) (Gray, 1987; Aikem et al., 1995; Nour & Yen, 1992) y los sistemas de soporte a la decisión organizacionales (ODSS - Organizational Decision Support System) (Varghese & Pirkul, 1991), han evolucionado a partir de un usuario único y los DSS orientados a modelos.

63

De acuerdo a Sol (1987), la definición y objetivo de los DSS ha estado cambiando a través de los años. En los años 70, los DSS eran descritos como "un sistema informático para ayudar a la toma de decisiones". A finales de los años 70, el movimiento de los DSS empezó a focalizarse en "sistemas informáticos interactivos los cuales ayudan a tomar decisiones usando bases de datos y modelos para solventar problemas no estructurados". En los años 80, los DSS debían proveer de sistemas que "usaran tecnologías disponibles y adecuadas para mejorar la efectividad de dirección y de actividades profesionales", y finalmente en los años 80 los DSS se volvieron un nuevo desafío a través del diseño de estaciones de trabajo inteligentes.

En lo referido a la clasificación de los DSS existen varias formas de realizar esta tarea.

Holsapple y Whinston (Holsapple et al., 1996) clasifican los DSS en los siguientes seis framework: DSS orientados al texto, DSS orientados a las bases de datos, DSS orientados a las hojas de cálculo, DSS orientados a la resolución, DSS orientados a las reglas, y DSS compuestos. Un DSS compuesto es la definición más popular para un DSS. Es un sistema híbrido que incluye dos o más de las cinco estructuras básicas descritas por Holsapple y Whinston.

El soporte ofrecido por los DSS pueden ser separados en tres categorías distintas y estrechamente relacionadas: Soporte personal, Soporte de grupos y Soporte organizacional.

Los componentes de los DSS pueden ser clasificados como:

Entradas: Factores, números y características a analizar. Conocimiento y expertise del usuario: Entradas que requieren

análisis manual por el usuario. Salidas: Datos transformados a partir de los cuales se generan las

decisiones del DSS. Decisiones: Los resultados generados por el DSS basados en el

criterio del usuario.

Las aplicaciones de los DSS pueden ser de lo más variadas. Aparte de los CDSS (Clinical Decision Support System) existen otras aplicaciones. Los DSS son usados habitualmente en negocios y dirección. Los cuadros de mando y otros software de representación de negocios permiten tomar decisiones más rápidamente, identificar tendencias negativas y una mejor asignación de los recursos de negocios.

Un área creciente de las aplicaciones, conceptos, principios y técnicas de los DSS es en la producción agrícola. Por ejemplo, el paquete DSSAT4 (Jones et al., 1998), desarrollado durante los años 80 y 90 a través de soporte financiero de USAID, ha permitido una rápida evaluación de varios sistemas de producción agrícola alrededor del mundo para facilitar la toma de decisiones. Existen, sin embargo, muchas limitaciones para la adopción adecuada de los DSS en la agricultura (Stephens & Middleton, 2002).

Los DSS también prevalecen en la gestión de bosques donde la planificación a largo plazo demanda requerimientos específicos. Todos los aspectos del manejo de bosques, desde transporte de registros hasta planificación de cosechas para la protección y sostenibilidad del ecosistema han sido tratados por los más modernos DSS.

Hablando ya del término concreto que se utilizará con más frecuencia en esta tesis (CDSS), podemos usar la definición básica de un CDSS en su forma más simple, y es que es un DSS usado en el ámbito clínico. A menudo, los sistemas de soporte a la decisión de diagnóstico (DDSS) se asumen como equivalentes de los CDSS y se usan indistintamente.

64

Sin embargo, existen ligeras diferencias ya que los DDSS se usan única y exclusivamente como herramientas de diagnóstico, mientras que los CDSS pueden tener también otros usos.

El término CDSS ha sido acuñado como un "sistema de conocimiento activo que usa dos o más ítems de datos de pacientes para generar un consejo específico para cada caso" (Johnston et al., 1994). Esto implica que un CDSS es simplemente un DSS que se centra en usar administración del conocimiento de manera que se puedan lograr consejos médicos para los pacientes basados en un determinado número de ítems.

El principal objetivo de los CDSS modernos es asistir al personal relacionado con la salud (clínico) en el punto de cuidado o atención del paciente. Esto significa que el clínico va a interactuar con un CDSS para determinar diagnósticos, análisis, etc. a partir de los datos del paciente. Teorías previas de los CDSS han sido usadas para definirlo literalmente como un sistema para tomar decisiones por el clínico. El clínico debe introducir la información de entrada y esperar a que el CDSS devuelva una salida con la respuesta correcta y actuar en consecuencia. La nueva metodología de usar CDSS como asistencia fuerza a los clínicos a interactuar con el CDSS usando el conocimiento tanto del CDSS como del propio clínico para realizar un mejor análisis de los datos del paciente del que tanto el humano como el CDSS podrían hacer por sí mismos. Típicamente, los CDSS deberían hacer sugerencias de salidas o un conjunto de salidas para que el clínico oficialmente escoja la información útil y elimine las sugerencias erróneas realizadas por el sistema (Berner, 2007).

Otra importante clasificación de los CDSS está basada en el tiempo de uso. El doctor emplea este sistema en el punto de cuidados para ayudarse a medida que están tratando al paciente, tanto en la parte de pre diagnóstico, durante el diagnóstico, o después del diagnóstico (fase de prognosis). Los CDSS de pre diagnóstico son usados para ayudar al doctor a preparar el diagnóstico. Los CDSS usados durante el diagnóstico ayudan a revisar y filtrar las elecciones del diagnóstico preliminar para mejorar los resultados finales. Finalmente, los CDSS de post diagnóstico son usados para extraer datos para derivar las conexiones entre pacientes y su historial médico pasado e investigación clínica para predecir eventos futuros.

Teniendo en cuenta todo esto, existen dos tipos básicos de CDSS (Kuperman et al., 1999):

Basados en el conocimiento No basados en el conocimiento

Características de los CDSS basados en el conocimiento:

La mayoría de los CDSS consisten en tres partes: (1) la base de conocimiento, (2) el motor de inferencia, y (3) los mecanismos de comunicación. La base de conocimiento contiene las reglas y asociaciones de los datos compilados, los cuales la mayoría está en forma de reglas IF-THEN. Si por ejemplo el CDSS fuera un sistema para determinar interacciones de medicamentos, entonces una regla podría ser: "Si el medicamento X es tomado y el medicamento Y es tomado ENTONCES alerta al usuario". Usando otra interfaz, un usuario avanzado podría editar la base de conocimiento para mantenerla al día con nuevos medicamentos. El motor de inferencia combina las reglas a partir de la base de conocimiento con los datos del paciente. Los mecanismos de comunicación permitirán al sistema mostrar los resultados al usuario así como tomar los datos de entrada (Courtney et al., 2007).

65

Características de los CDSS no basado en el conocimiento:

Los CDSS que no usan una base de conocimiento usan una forma de Inteligencia Artificial llamada aprendizaje automático, que permite a las máquinas aprender de experiencias pasadas y/o buscar patrones en datos clínicos. Dos tipos de tecnologías no basadas en el conocimiento son las redes de neuronas y los algoritmos genéticos. Las redes de neuronas usan nodos y conexiones con pesos entre ellos para analizar los patrones encontrados en los datos del paciente para derivar asociaciones entre los síntomas y un diagnóstico (en los DDSS, por ejemplo). Esto elimina la necesidad de escribir las reglas. Sin embargo, dado que el sistema no puede explicar la razón por la cual llegan a una determinada conclusión, la mayoría del personal clínico no los usa por cuestiones de fiabilidad y responsabilidad.

Los algoritmos genéticos están basados en un proceso de evolución simplificado usando selección directa para lograr resultados óptimos en el CDSS. Los algoritmos de selección evalúan componentes de conjuntos aleatorios de soluciones de un problema. Las mejores soluciones obtenidas son entonces recombinadas y mutadas repitiendo el proceso de nuevo. Esto sucede durante varias iteraciones hasta que se encuentra una solución adecuada. Son iguales que las redes neuronales en el sentido de que derivan su conocimiento a partir de los datos del paciente. Las redes no basadas en el conocimiento generalmente se centran en una estrecha lista de síntomas.

En lo referido a la efectividad de estos sistemas cabe destacar un revisión sistemática realizada en 2005, la cual concluyó que los CDSS actuales mejoran el rendimiento del personal clínico dadas las decisiones tomadas, pero sin embargo no existen evidencias suficientes para determinar los efectos en los resultados de los pacientes (Garg et al., 2005).

Por este motivo existen una serie de desafíos que los CDSS deben superar para lograr una mayor integración en el mundo de la medicina. En lo referido a los desafíos clínicos se debe destacar que se han realizado muchos esfuerzos conjuntos entre las instituciones médicas y las empresas software para producir CDSS viables que cubrieran todos los aspectos de las tareas clínicas. Sin embargo, con la complejidad de los flujos de trabajo clínicos y las demandas del personal médico, el cuidado de la salud debe ser tomado muy en cuenta por la institución desarrolladora del sistema para asegurarse que el sistema llega a ser una parte fluida e integrada del flujo de trabajo (Sim et al., 2001).

Dos sectores del dominio del cuidado de la salud donde los CDSS han tenido un gran impacto son los sectores de farmacia y facturación. Las farmacias y los sistemas de prescripción de fármacos, hoy en día realizan controles para comprobar interacciones negativas de medicamentos y lanzar alertas al profesional que va a prescribirla. Estos sistemas generalmente existen tanto en los ámbitos clínicos como en ámbitos más comerciales como por ejemplo el software usado por una farmacia o almacén de fármacos a nivel local. Otro sector de éxito de los CDSS es en facturación y gestión de reclamaciones.

A pesar del gran esfuerzo realizado por las instituciones para producir y usar estos sistemas, la adopción y aceptación a gran nivel de estos sistemas no ha llegado aún. Un gran punto a superar para la aceptación de estos sistemas es la integración de los mismos en los flujos de trabajo ya establecido.

En lo referido a los desafíos técnicos, los CDSS deben enfrentarse a estos desafíos en un gran número de áreas. Los sistemas biológicos son tremendamente complicados, y una decisión clínica puede utilizar un enorme rango de datos potencialmente relevantes. Por ejemplo, un sistema electrónico de medicina basada en la evidencia debe considerar potencialmente los síntomas del paciente, la historia médica, historia familiar y genética,

66

así como las tendencias históricas y geográficas de una determinada enfermedad, y los datos médicos en términos de efectividad médica cuando se recomienda a un paciente un tratamiento determinado. Además, se publican constantemente nuevos datos, lo que debería ser integrado dentro del sistema para mantener su relevancia (Sim et al., 2001).

Uno de los desafíos clave a los que se enfrentan los CDSS es la dificultad para incorporar la extensa cantidad de investigación clínica que se va publicando. En un determinado año, decenas de cientos de artículos son publicados (Zwi, 1991). Actualmente, cada uno de esos estudios debe ser leído manualmente, evaluado su legitimidad científica, e incorporado al CDSS de forma adecuada.

Además de ser laborioso, la integración de nuevos datos puede en ocasiones ser difícil de cuantificar o incorporar al esquema de soporte a la decisión existente, particularmente en instancias donde los diferentes artículos clínicos puedan parecer conflictivos. La manera adecuada de solventar estas discrepancias es a menudo el sujeto de los artículos clínicos en sí mismo, lo cual a menudo toma meses en poder completarse.

Un primer ejemplo de un proyecto que intentaba incorporar nuevos datos clínicos dinámicamente fue Isabel (Isabel Healthcare, 2009).

Por otra parte, para que un CDSS ofrezca una respuesta, debe demostrar una mejora en la eficiencia del proceso clínico o en las salidas. La evaluación de un CDSS es el proceso de cuantificar su valor para mejorar la calidad del sistema y medir su efectividad. Dado que los diferentes CDSS sirven para diferentes propósitos no existe una métrica genérica la cual aplicar a todos los sistemas, sin embargo, atributos como la consistencia (consigo mismo y con los expertos) a menudo se aplica a través de un amplio espectro de sistemas.

La evaluación de rendimiento de un CDSS depende del objetivo del sistema. Por ejemplo, un sistema de soporte a la decisión de diagnóstico debe ser evaluado en base a la consistencia y efectividad a la hora de clasificar las enfermedades (comparándolo con médicos o con otros DSS) (Kaplan, 2001).

En cuanto a las bases metodológicas de los CDSS se deben destacar diferentes metodologías que pueden ser usadas por un CDSS en orden de proporcionar soporte a los profesionales de la medicina.

Los componentes básicos de un CDSS incluyen una base de conocimiento dinámica de dominio médico y un mecanismo de inferencia (generalmente un conjunto de reglas derivadas a partir de expertos y medicina basada en la evidencia) (Turban & Watkins, 1986).

2.2.5. CONCLUSIONES

Todas las tecnologías que han sido mencionadas son aquellas que juegan un papel importante en la presente tesis. Por una parte, se han planteado los sistemas de soporte a la decisión clínicos desde un punto de vista tecnológico ya que al fin y al cabo la tecnología subyacente en todo sistema de esta tesis es la de un CDSS. Además de esto, se han mencionado los otros dos pilares fundamentales en el desarrollo de esta tesis: Las técnicas de Inteligencia Artificial como los sistemas de inferencia lógica o los sistemas basados en reglas y las Tecnologías Semánticas, que a pesar de ser considerada una técnica de IA ha sido estudiada de forma separada dada la gran cantidad de información que requería ser presentada.

67

3. PLANTEAMIENTO DE LA HIPO TESIS A VERIFICAR Y RESOLUCIO N

La creación o construcción de sistemas de soporte a la decisión en ámbitos clínicos (conocidos como CDSS o MDSS) no es un problema que tenga una solución trivial ni sencilla. En concreto, la creación y desarrollo de los llamados sistemas de soporte a la decisión de diagnóstico ha sido uno de los problemas más codiciados por los desarrolladores que se han introducido en los campos de la medicina debido al gran potencial que podría suponer la generación de un sistema común, el cual podría ayudar en las decisiones de diagnóstico que se llevan a cabo cada día en todo el mundo. Como se ha ido comentando en las secciones anteriores existen muchos sistemas que se han ido desarrollando a lo largo de los años desde los tempranos años 70.

Estos sistemas han hecho uso en su gran mayoría de las tecnologías basadas en los sistemas basados en reglas al ser una de las tecnologías pertenecientes a la Inteligencia Artificial que más efectividad da debido a varios parámetros entre los que cabe destacar la relativa sencillez en algunos casos de codificación de las mismas, la posibilidad de explicación de los resultados proporcionados por el sistema al seguir unos patrones o reglas concretas y sobre todo la eficiencia y seguridad de los resultados, la cual dependerá directamente de la codificación realizada en las reglas. Esta codificación sin embargo plantea un problema de gran envergadura, y es que la enorme cantidad de datos existentes en medicina y posibles variaciones no siempre da como resultado esa sencillez en la codificación al tener que tener en cuenta una gran cantidad de variables que se pueden interrelacionar entre sí.

La gran cantidad de datos existente también implica la problemática de la generación de las reglas, ya que esa gran cantidad de datos debe ser generada de alguna forma. En este aspecto, los sistemas automáticos que utilizan técnicas de aprendizaje automático son capaces de analizar informes, literatura médica, y otros datos utilizando técnicas de Data Mining para realizar un aprendizaje sobre los datos analizados, y así poder ser capaces de generar reglas, las cuales sin embargo no siempre son correctas.

Esto plantea el problema de que aunque los sistemas de aprendizaje automático realizan este aprendizaje, precisamente como su nombre indica, de forma automática, al final se va a necesitar una supervisión sobre estos datos para asegurar la veracidad y calidad de los mismos. Esto no es nada comparado con la posibilidad de por ejemplo tener que recurrir a la población manual de los datos mediante el uso de expertos, la tarea quizás más preocupante y ardua de estos sistemas, no solo por la posible complejidad asociada a la tarea como se ha comentado previamente, sino por la como se ha mencionado anteriormente la gran cantidad de datos que se necesitan manejar, y por lo tanto la gran cantidad de profesionales (ya que esta tarea debe ser realizada por profesionales o expertos del sector) necesaria.

Teniendo en cuenta lo mencionado anteriormente, las tecnologías aquí comentadas juegan un papel muy importante en la creación de este tipo de sistemas. Por una parte ha quedado demostrado en los trabajos estudiados que diversas técnicas de Inteligencia Artificial son capaces de proporcionar buenos resultados a la hora de crear sistemas inteligentes de diagnóstico diferencial en medicina. Por otra parte, el gran auge de las Tecnologías Semánticas establece un marco ideal para la representación del amplio conocimiento existente en la medicina además de realizar una especificación de las relaciones entre términos médicos que permitirán generar las futuras reglas de inferencia a través de las descripciones lógicas. Iniciativas como las llevadas a cabo por la Open-

68

Galen (Rector et al., 2003) u OBO-Foundry (Smith et al., 2007) dejan patente la gran capacidad de estas tecnologías en este aspecto.

3.1. PLANTEAMIENTO DE LAS HIPÓTESIS

Teniendo en cuenta el planteamiento expuesto, en esta tesis, aparte de realizar una revisión detallada de los sistemas de diagnóstico diferencial creados desde principios de los años 70 hasta la actualidad y las técnicas de Inteligencia Artificial usadas, plantea las siguientes hipótesis a resolver:

Hipótesis H1: El uso de técnicas pertenecientes a las Tecnologías Semánticas principalmente, y de ciertas técnicas de Inteligencia Artificial en segundo lugar, permiten la creación de sistemas de diagnóstico diferencial de alta sensibilidad en medicina que proporcionen resultados con alto grado de exactitud (siendo exactitud en entornos diagnósticos, la capacidad para clasificar a los pacientes en categorías o estados en relación con la enfermedad (López de Ullibarri-Galparsoso & Pita-Fernandez, 1998)) de forma eficiente.

o Hipótesis H1.1: La exactitud diagnóstica de los resultados vendrá dada por las capacidades de inferencia del sistema, la cual provee resultados, en los cuales se establece que su correctitud esté dentro de unos umbrales preestablecidos por expertos.

o Hipótesis H1.2: La eficiencia del sistema vendrá medida en términos de tiempos de ejecución dentro de unos umbrales preestablecidos.

Hipótesis H2: El problema de diagnóstico mediante inferencia multinivel, puede ser modelado y solventado usando técnicas asociadas a la Tecnologías Semánticas tales como las descripciones lógicas o los sistemas basados en reglas.

Hipótesis H3: Es posible la realización de un proceso que permita calcular alternativas de diagnóstico dado el planteamiento en el que los síntomas de una enfermedad (un caso clínico concreto), hayan sido inducidos por la ingesta de fármacos, y por lo tanto, su presencia no sea un indicio de la patología a diagnosticar.

El diagnóstico mediante inferencia multinivel es ampliamente comentado en el capítulo 6 de la presente tesis, donde se define con suficiente detalle. Una primera definición sin embargo de este es la siguiente:

Se denomina diagnóstico mediante inferencia multinivel al proceso de diagnóstico diferencial con capacidad para diagnosticar una entidad enfermedad (E1) en cuya definición, sus indicios (signos o síntomas principalmente), contienen a otra entidad de tipo enfermedad (E2), de tal forma que el proceso de inferencia permita diagnosticar E1 cuando se han introducido como entradas de este proceso los indicios que forman E2, en vez de E2 como entidad propia.

La alta sensibilidad en un diagnóstico, en el entorno descrito en esta tesis, hace referencia a aquellos procesos que a la hora de detectar una posible patología o entidad nosológica que está involucrada en un proceso de diagnóstico, pueden hacerlo con poca información, y por lo tanto son altamente sensibles. Los procesos diagnósticos de alta sensibilidad son de gran ayuda en ciertos entornos críticos donde se pretende que estos procesos puedan proporcionar resultados incluso cuando la probabilidad de estos es ínfima como en los entornos de triaje de los hospitales, donde los profesionales encargados de evaluar la posible patología de un paciente que ingresa en urgencias no siempre son médicos, y por lo tanto, el descarte de patologías es más frecuente con el

69

riesgo que eso conlleva. El objetivo de estos diagnósticos de alta sensibilidad es informar al facultativo de que ciertas patologías pueden estar presentes en un paciente incluso aunque esta probabilidad sea baja. Estos diagnósticos son de gran utilidad en entornos médicos críticos

3.2. PLANTEAMIENTO DE VERIFICACIÓN DE LAS HIPÓTESIS

La verificación de las hipótesis que han sido definidas en la sección 3.1 de la presente tesis se ha planteado mediante el diseño y desarrollo de un sistema software que permita verificar dichas hipótesis.

La creación de este sistema se ha planteado siguiendo un ciclo de vida en cascada incremental, generando una primera versión del software inicial donde se verificaron varias de las hipótesis para proceder a la generación de nuevas versiones donde se han añadido funcionalidades que permiten la verificación de las sucesivas hipótesis.

La primera de las hipótesis a verificar (H1) define que el uso de técnicas pertenecientes a la rama de la Inteligencia Artificial como son los Sistemas Basados en Reglas y las Descripciones Lógicas de las Tecnologías Semánticas, permiten, la creación de sistemas de diagnóstico diferencial en medicina que proporcionen resultados exactos de forma eficiente.

Partiendo de esta premisa, se diseña y desarrolla el sistema expuesto en el capítulo 5. Este sistema plantea un diseño y desarrollo software que permite verificar tanto la hipótesis H1 ya mencionada, como la hipótesis H3, donde se plantea que es posible la realización de un proceso que permita calcular alternativas de diagnóstico dado el planteamiento en el que los síntomas de una enfermedad (un caso clínico concreto), hayan sido inducidos por la ingesta de fármacos.

Este capítulo además plantea tanto la definición de exactitud en los resultados (para la hipótesis H1) como la definición de eficiencia.

En el capítulo 6 se presentan dos evoluciones del sistema ODDIN, presentado en el capítulo 5. En esta evolución se han generado dos sistemas que ofrecen una primera solución para verificar la hipótesis H2 (el primer sistema (ADONIS) lo resuelve de forma parcial, mientras que el segundo (SEDELO) lo resuelve de forma total como se verá en el capítulo citado), que establece que el problema de diagnóstico mediante inferencia multinivel, puede ser modelado y solventado con efectividad y exactitud usando técnicas asociadas a las Tecnologías Semánticas tales como las descripciones lógicas y las reglas semánticas.

Para finalizar, el capítulo 7 presenta la última de las evoluciones del sistema original. El sistema MDDS-OPM plantea la solución más óptima a las soluciones de las secciones mencionadas anteriormente donde, por una parte se divide la ontología generada en los sistemas mencionados anteriormente en varias partes con el objetivo de incrementar el rendimiento del sistema y la reusabilidad del conocimiento que almacenan.

Por otra parte, se incluye dentro del modelado de esta evolución del sistema, el uso de términos externos pertenecientes a vocabularios de carácter médico ampliamente usado y estandarizado además de plantear una solución a los problemas del sistema utilizando reglas en vez de descripciones lógicas.

Finalmente en este capítulo se plantea un nuevo modelo probabilístico que ayudará a mejorar el establecimiento de probabilidades en cada posibilidad de diagnóstico diferencial.

70

4. REPRESENTACIO N DEL CONOCIMIENTO

En el presente capítulo se va a tratar el problema de la representación del conocimiento del dominio planteado en esta tesis. Aparte de una introducción al campo de las terminologías de carácter médico, que se realizará en primer lugar, en este capítulo se planteará un análisis de estas terminologías, para discernir si podrían ser usadas como parte de esta tesis.

Por otra parte se mostrará la representación del conocimiento médico usado (las entidades existentes y sus relaciones, basándose en el modelo de criterios diagnósticos), para a continuación realizar un análisis detallado de las dos ontologías que se desarrollaron y que sirvieron como base de conocimiento para representar los elementos médicos y las relaciones descritas.

El hecho de realizar dos ontologías se ha basado en una cuestión de mejora de diversas características de las ontologías. En las conclusiones de este capítulo se realiza una discusión a este respecto.

4.1. INTRODUCCIÓN

Existen varios tipos de sistemas de terminología médica para satisfacer diferentes necesidades relacionadas con la representación del conocimiento en medicina. Con la intención de satisfacer más necesidades de las cuales existen hoy en día, tanto Mori et al. (1998) como Cimino (1998), se preguntan por una evolución de los sistemas de terminología médica para mayor flexibilidad.

En el artículo de Mori et al. (1998) se describen tres generaciones de sistemas de terminología médica. La primera generación comprende sistemas de terminología tradicional. Esta incluye vocabularios controlados, nomenclaturas, taxonomías y sistemas de codificación que satisfacen la mayoría de las necesidades que planteaban los sistemas de información basados en papel. En esta generación, los sistemas típicamente consisten en una lista de frases, una lista de códigos, un esquema de codificación y una jerarquía. El rol del esquema de codificación es realizar un mapeo entre los términos y códigos. Ejemplos de terminologías de primera generación son ICD-10, KSH97-P y la International Classification of Functioning, Disability and Health (ICF).

La segunda generación son los sistemas compuestos. Estos sistemas tienen una estructura categórica, un cross-tesauro, una lista de términos estructurada y una base de conocimiento de disecciones. La estructura categórica proporciona una descripción del contenido de alto nivel, que tipo de conceptos están incluidos y como se relacionan unos con otros. Esto puede ser visto como un framework para los cuales el cross-tesauro proporciona un conjunto de etiquetas para ser insertadas cuando el contenido es modelado. En el cross-tesauro, cada elemento en la lista de términos estructurada es representado de acuerdo a su estructura categórica; estas descripciones constituyen la base de conocimiento de las disecciones. Ejemplos de esta segunda generación son Nomenclature, Properties and Units (NPU), Logical Observation Identifiers, Names and Codes (LOINC) and SNOMED International.

La tercera generación consiste en los sistemas formales. En esta generación, los sistemas tienen un conjunto de símbolos y un conjunto de reglas formales para manipular los símbolos y estos conjuntos pueden ser vistos como un conjunto de conceptos y un conjunto de relaciones entre los conceptos. Es posible representar cada concepto en una

71

única forma canónica y las expresiones no canónicas se convertirían de forma automática usando un motor. Un ejemplo de los sistemas de tercera generación son GALEN-IN-USE (Rector et al., 2003).

A partir de estas tres generaciones, Cimino (1998) propone doce características sobre la estructura y el contenido en los sistemas de terminología médica. A continuación se describen dos de estas características que se plantean como las más interesantes para el objetivo de la presente tesis:

Poli-Jerarquía: Los sistemas necesitan cambiar su mono-jerarquía estricta (taxonomía) a poli-jerarquía. Es imposible representar de forma apropiada el mundo real en una mono-jerarquía estricta donde cada categoría tiene un solo padre. Las categorías en el mundo real pueden pertenecer a más de un padre (Cimino, 1998; Cimino et al., 1989; Cimino et al., 1994; Cimino, 1996).

Definición formal: Los sistemas necesitan una definición formal expresada como una colección de los diferentes tipos de relaciones entre los conceptos (Cimino, 1998). Las manipulaciones pretenden ayudar al usuario a localizar una categoría específica en un sistema terminológico (Cimino et al., 1989).

Otros autores como Straub et al. (2006) tienen diferente opinión que Rossi Mori et al. y Cimino. Ellos argumentan que los diferentes tipos de terminología médica tienen diferentes propósitos y necesitan coexistir. Los sistemas de terminología médica con menos categorías y un modelo semántico con más restricciones, como un árbol jerárquico, proporcionan información útil para la reducción o simplificación de los casos donde una terminología médica más rica proporciona demasiada información.

El uso de vocabularios estandarizados es algo muy común en la literatura biomédica. El objetivo de utilizar este tipo de vocabularios es permitir el intercambio de información entre distintos tipos de entidades de la forma más automática posible. Diversos trabajos han trabajado en este campo, tanto dentro de la adopción de este tipo de vocabularios como parte de sus investigaciones (Osborne et al., 2006; Merrill et al., 2008), como generando modelos de representación de datos usando este tipo de terminologías (Lee et al., 2010; Markwell et al., 2008).

4.2. TERMINOLOGÍAS

A continuación se exponen las principales terminologías o vocabularios existentes en la actualidad y que deben ser tenidas en cuenta a la hora de escoger, o bien una de estas terminologías para ser adaptada dentro del dominio del sistema, o bien para utilizarlas como referencia o base.

4.2.1. UMLS/SNOMED-CT

SNOMED-CT (Systemized Nomenclature of Medicine – Clinical Terms) es la terminología integral, multilingüe y codificada de mayor amplitud, precisión e importancia desarrollada en el mundo.

Forma parte del compendio Unified Medical Language System (UMLS), el cual se conforma de una serie de vocabularios controlados sobre ciencias biomédicas (Bodenreider, 2004). UMLS proporciona una estructura de mapeo entre los vocabularios que lo conforman, permitiendo la traducción entre varios sistemas de terminologías. También puede ser visto como un tesauro global u ontología de conceptos biomédicos. Además, UMLS facilita el uso de procesamiento del lenguaje natural. Su principal uso está

72

orientado por desarrolladores de sistemas en informática médica. UMLS se compone de los siguientes componentes:

Meta tesauros: El núcleo de bases de datos de UMLS. Una colección de conceptos y términos obtenidos a partir de varios vocabularios controlados y sus relaciones.

Red Semántica: Un conjunto de categorías y relaciones que se usan para clasificar y relacionar las entradas del meta tesauro.

Léxico especializado: Una base de datos de información lexicográfica para su uso en lenguaje de procesamiento natural.

Una serie de herramientas de soporte.

UMLS ha sido diseñado y es mantenido actualmente por la Biblioteca nacional de medicina estadounidense y es actualizada cada cuatro meses.

En lo referido a SNOMED-CT, este es un producto que nace de la fusión entre SNOMED RT (Snomed Reference Terminology), creada por el College of American Pathologists (CAP) y el Clinical Terms Version 3 (CTV3), desarrollada por la National Health Service (NHS) del Reino Unido. Esta fusión ha permitido la combinación de los términos en los ámbitos de las ciencias básicas, la bioquímica y las especialidades médicas de SNOMED RT con los contenidos de la atención primaria del CTV3, dando lugar a una terminología de referencia que permite a los profesionales de la salud de todo el mundo representar la información clínica de forma precisa e inequívoca, en formato multilingüe.

Su objetivo es, por una parte el de dar soporte a la hora de grabar información clínica usando vocabulario controlado que permita la interpretación de máquinas para simplificar el intercambio de información entre éstas, permitiendo soporte a decisiones, agregación y análisis, y por otra la documentación clínica y la generación de informes (IHTSDO, 2008). En otras palabras, SNOMED-CT cubre tanto abstracción como representación (Cimino, 1996) y es útil para proporcionar un recurso común que active la interoperabilidad de los sistemas de información clínicos (Héja et al., 2006).

4.2.1.1. ANÁLISIS DE SNOMED-CT

El soporte de la interoperabilidad semántica (Straub et al., 2006) requiere una terminología común detallada (u ontología). Los sistemas de información clínicos y los estándares de comunicación generalmente usan listas pre coordinadas, lo cual debería cubrir cualquier dominio del conocimiento médico. Estos conceptos que son usados por los sistemas de información, necesitan ser mapeados a una terminología común y viceversa. Este mapeo requiere una ontología que sea común, consistente, detallada y decidible.

El detalle y la computabilidad (por ejemplo: que sea decidible en un tiempo razonable) son dos requisitos necesarios, pero contradictorios.

Una ontología consistente debería insistir en la separación de la inclusión (is a) de otras relaciones (por ejemplo: part of, acts on) y confiar en las definiciones formales además de las jerarquías taxonómicas de subclases, problema que actualmente ocurre con la clasificación ICD-10.

El razonamiento automático es una tarea que requiere tiempo exponencial. Por lo tanto, el razonamiento sobre un sistema que contiene alrededor de 400.000 conceptos es un problema no resuelto aún (Héja et al., 2006).

73

En el análisis de SNOMED-CT desde un punto de vista ontológico se observan varias violaciones en lo referido a conocimiento biomédico. Las enfermedades (Diseases), observaciones (Observations) e indicios (Findings) están incluidos dentro de "Indicio clínico" (Clinical Findings), lo cual es erróneo incluso desde un punto de vista médico. Las enfermedades, indicios, observaciones y dolencias son conceptos médicos mutuamente disjuntos, y consecuentemente ninguno de ellos debe estar incluido dentro de otro.

Otros errores identificados son por ejemplo el uso común de herencia múltiple, con varios errores de inclusión. Por ejemplo, bebida alcohólica (alcoholic beverage), el cual su padre es alcohol ingerible (ingestible alcohol) es incluido por depresor central (central depressant), alcohol etílico (ethyl alcohol) y abuso de sustancias psicoactivas no farmacéuticas (psychoactive substance of abuse - non-pharmaceutical). Desde un punto de vista filosófico ninguna de estas inclusiones es cierta. Las bebidas alcohólicas contiene alcohol etílico que juega el rol de depresivo y sustancia de abuso. Este tipo de poli jerarquías es muy común en SNOMED-CT.

Por otra parte, la experiencia usando terminologías médicas ha mostrado que un médico necesita introducir entre 2 y 15 términos por cada 10 minutos de consulta con un paciente. Considerando que pueden disponer de alrededor de un millón de términos para escoger y que estos a menudo son términos largos, existe una cierta dificultad a la hora de escribir ciertos términos.

Una aplicación que proporcione una lista de elementos siempre será demasiado grande para usarla de forma sencilla, pero demasiado corta para incluir los términos requeridos del millón disponibles. Una caja de búsqueda es la mejor solución como se avala en la mayoría de los motores de búsqueda Web. Sin embargo, en este caso, estamos proporcionando una búsqueda sobre frases pequeñas en vez de sobre frases en documentos Web completos, y por lo tanto, estas estrategias de búsqueda no son aplicables.

Cuando se realiza una búsqueda por términos debemos asegurarnos que los usuarios encuentran todos los términos relevantes a su búsqueda (estrategia de búsqueda sensitiva) y solo los términos relevantes a su búsqueda (estrategia de búsqueda específica). Incrementar la sensibilidad decrementa la especificidad, y por lo tanto se tiene que buscar un balance entre ambas. Si buscamos frases completas, los resultados relevantes son omitidos debido a que pueda existir un orden diferente de las palabras. Por ejemplo, una búsqueda de alergia a la fresa (strawberry allergy) no encontraría ningún término, pero "allergy to strawberries" si devolvería resultados. Si les pedimos a los usuarios que introduzcan palabras completas para buscar, esto llevaría demasiado tiempo y además el usuario podría ser propenso a cometer errores de ortografía. Por ejemplo, no podemos esperar que el usuario escriba de forma completamente correcta pancreotomía (pancreatoduodenectomy).

Si permitimos a los usuarios introducir texto que pueda aparecer en cualquier parte de una palabra, la aplicación a menudo devolverá resultados no esperados. Por ejemplo, un usuario que introduzca como búsqueda "straw all" con la intención de buscar alergia a las fresas (allergy to strawberry), le devolvería el resultado inesperado de colesterol de la vesícula biliar (strawberry gallbladder). Una búsqueda por palabras en cualquier orden usando la estrategia de buscar cadenas que empiecen por el término introducido es la mejor opción.

Para finalizar, se debe tener en cuenta que SNOMED-CT tiene alrededor de un millón de términos como resultado de que su objetivo es ser una referencia exhaustiva como terminología médica. Existen una gran variedad de aplicaciones médicas en varios contextos, las cuales son diseñadas con diversos fines y cuyo objetivo es usar SNOMED-CT

74

como un punto de referencia común cuando se usa vocabulario médico. Sin embargo, para un determinado contexto solo una pequeña fracción de los términos de la taxonomía son necesarios y relevantes (Wroe, 2006) y esto debe tenerse en cuenta a la hora de utilizar este tipo de terminologías.

4.2.1.2. DESCRIPCIÓN DE SNOMED-CT

La terminología cuenta con cerca de un millón de términos asociados con unos 400.000 conceptos. Esto implica que es muchísimo más grande que la mayoría de las ontologías OWL disponibles y por lo tanto representa problemas de escalabilidad para las herramientas software de OWL.

SNOMED-CT se basa en conceptos, en donde un concepto puede estar representado por más de un término. Por ejemplo, el término pancreatoduodenectomy y Whipples procedure representan el mismo concepto médico. También algunos términos representados como cadenas pueden representar más de un concepto. Por ejemplo, el término cold puede hacer referencia al concepto de sensación de frio o a resfriado común. Es posible representar conceptos de SNOMED-CT en lenguaje OWL como clases OWL. Además, varios de los términos usados para denotar estas clases pueden ser representados usando etiquetas de RDF Schema si es necesario. No existe nada en SNOMED-CT que equivalga a las instancias de OWL (Wroe, 2006).

Cada concepto es ubicado utilizando una determinada jerarquía dentro de SNOMED-CT dependiendo de sus relaciones. Por ejemplo, si un concepto tiene una relación “is-a” con un concepto más general (asthma is a respiratory disorder), todos los datos anotados con el concepto más específico (asthma), implicarán una anotación con el concepto más general (respiratory disorder). La semántica de la relación “is-a” es equivalente al axioma subClassOf de OWL. Se expone este mismo ejemplo usando sintaxis abstracta de OWL:

SubClassOf(Asthma Respiratory_disorder)

Snippet 3. Ejemplo de relación is-a

Cada concepto debería tener además una relación no taxonómica con otros conceptos que proporcionan más información sobre dicho concepto, y deben de hecho definir completamente al concepto. Por ejemplo, “appendicectomy” tiene una relación de método con “excision”, una relación de lugar de procedimiento con “appendix structure” y está definida completamente. Esto permite a las aplicaciones inferir que cualquier procedimiento que incluye estas dos relaciones debe ser una apendicetomía (appendicectomy). La mayoría de estas relaciones no taxonómicas pueden ser consideradas como restricciones existencias en una ontología OWL. Ejemplo usando sintaxis abstracta de OWL:

Class(Appendicectomy defined intersectionOf (

Surgical_procedure

restriction(method someValuesFrom Excision

restriction(procedure_site someValuesFrom Appendix_structure))

Snippet 4. Ejemplo de relación en SNOMED

SNOMED-CT es extensible en lo referido a la entrada de datos a través del uso de un elemento llamado “post coordinación”. Por ejemplo, no existen términos en SNOMED-CT para “left kidney excision”, algo que es muy usado en la práctica médica. Sin embargo, términos para “kidney excision” y “left” existen con una serie de reglas que especifican como de adecuado es combinarlos entre ellos. En una ontología OWL esto se

75

correspondería con expresiones de clases anónimas definidas en términos de un número de clases padre y restricciones existenciales. Ejemplo en sintaxis abstracta de OWL:

intersectionOf(Excision

restriction(procedure-site someValuesFrom

intersectionOf(kidney

restriction(laterality someValuesFrom left))))

Snippet 5. Ejemplo relación SNOMED (Clases anónimas)

Sin embargo, la mayor deficiencia para el uso de SNOMED-CT directamente en un dominio como el definido en esta tesis es que no define las enfermedades a partir de sus signos biológicos (Bertaud-Gounot et al., 2005). Teniendo en cuenta que los criterios de elegibilidad2 (Burgun et al., 2005) son más útiles que las definiciones de tipo aristotélicas (Burgun et al., 2005) que son las que actualmente usa SNOMED para definir relaciones entre las enfermedades y otros conceptos que puedan estar relacionados con la misma (como los vistos anteriormente) sin ser estos sus criterios diagnósticos.

4.2.2. GALEN

GALEN (Rector et al., 2003) es el nombre dado a la tecnología diseñada para representar información clínica de una nueva forma. GALEN produce un sistema de codificación médica multilingüe usando un enfoque diferente respecto a otros usados en el pasado. El programa GALEN representa sobre todo el desarrollo de la tecnología, la cual ha incluido varios proyectos europeos financiados.

El objetivo de GALEN es hacer más fácil la construcción y uso de aplicaciones clínicas, para ayudar a los médicos en su trabajo diario. Los desarrolladores de GALEN han identificado que uno de los factores que hace más duro el desarrollo e integración de este tipo de aplicaciones es la necesidad de la representación de los conceptos médicos para que estas aplicaciones las almacenen y manipulen.

Por lo tanto, el programa GALEN se encarga del desarrollo de una terminología clínica (llamada Modelo Común de Referencia GALEN) en el cual se puede presentar todos aquellos conceptos médicos que presentan cierta sensibilidad. Los conceptos médicos representados usando este esquema deben ser accesibles y manipulables por máquinas, así como ser accesibles para los médicos. El esquema de representación que se usa para generar este modelo es conocido como GRAIL (GALEN Representation And Integration Lenguage). El modelo es enviado y usado a través de un dispositivo software denominado Servidor de Terminología GALEN. Una de las ideas principales de GALEN es que las terminologías médicas tienen que ser más software que conjuntos de datos.

La tecnología GALEN (el modelo común de referencia GALEN, escrito en GRAIL, y enviado a través de los servidores de terminología GALEN), tienen como objetivo soportar los requisitos de las aplicaciones que requieren terminologías clínicas multilingüe para mediar entre los sistemas existentes así como los nuevos.

La diferencia con UMLS se basa en que UMLS ha producido un meta tesauro, cuyo uso primario es el de realizar conversiones entre sistemas de codificación. Sin embargo,

2 En este contexto el término criterio de elegibilidad es sinónimo del concepto criterio de diagnóstico.

76

los desarrolladores de GALEN afirman que la conversión entre sistemas de codificación es una función importante en GALEN, pero no la única.

Por ejemplo, aunque el meta tesauro hacen referencia cruzada a los códigos en cada sistema, estos no representan su significado ni proporcionan un significado para extender el sistema entero.

UMLS también proporciona una red semántica que clasifica cada concepto en un número determinado de categorías. Sin embargo, donde el modelo GALEN proporciona taxonomías que contienen miles de categorías en una compleja jerarquía, UMLS proporciona una red relativamente sencilla con menos de 200 categorías, apenas equivalente a las capas más altas de las jerarquías de GALEN.

4.2.3. DISEASE ONTOLOGY (DO)

La ontología Disease Ontology (DO) tiene como objetivo proporcionar una ontología para la integración de datos biomédicos asociados con enfermedades humanas. DO se define bajo un formalismo correcto (en el sentido ontológico) con una estructura semánticamente computable. Los términos en DO están correctamente definidos usando referencias estándar. Estos términos están enlazados con terminologías ya establecidas y adaptadas que contienen conceptos de enfermedades y relacionados como SNOMED (Actualmente se está trabajando con SNOMED para comprobar si se puede lanzar una versión de los códigos SNOMED enlazados a través de UMLS), ICD-9, ICD-10, MeSH y UMLS.

La combinación de una estructura semánticamente computable y referencias externas a estas terminologías permitirá realizar inferencias útiles entre datasets externos usando uno o más de estas terminologías estándar para codificar enfermedades. La ontología de enfermedades pretende ser al final del proyecto en el que se encuentra englobada, una ontología de enfermedades aceptada y conducida por la comunidad para investigación clínica y medicina, incluyendo enfermedades genéticas (Osborne et al., 2009; Du et al., 2009), del entorno e infecciosas.

La ontología de enfermedades pretende encapsular, por lo tanto, un conjunto completo de enfermedades. El diseño de la ontología de enfermedades permitirá generar un mayor entendimiento de los estados de las enfermedades a través de la ubicación de desórdenes hereditarios en el contexto de otras enfermedades infecciosas y relacionadas.

La estructura de esta ontología y las referencias externas a otras terminologías permitirá la integración de conjuntos de datos dispares a través del concepto de enfermedad.

La Tabla 4 muestra las relaciones existentes en la actualidad:

Relaciones composed_of has_agent

located_in results_in derives_from results_in_formation_of has_symptom transmitted_by

effects - Tabla 4. Relaciones ontología DO

A continuación se muestran unos ejemplos de cómo se componen los elementos usando estas relaciones:

77

disease term: Kaposi's sarcoma

sarcoma [primary parent] that is_a AIDS-related opportunistic

infectious disease [secondary parent] has_agent human herpesviris

8 (HHV8). [pathogen]

Snippet 6. Ejemplo relaciones DO (I)

disease term: Kaposi's sarcoma of the lung

A Kaposi's sarcoma [primary parent] that is located_in lung.

[anatomy]

Snippet 7. Ejemplo relaciones DO (II)

disease term: lymphoid cancer

A hematologic cancer that is located_in lymphocytes which is

composed_of white blood cell.

Snippet 8. Ejemplo relaciones DO (III)

4.2.4. OTRAS

Existen otras terminologías o clasificaciones menos conocidas pero que también tienen un gran interés en la presente tesis y por lo tanto merecen al menos ser mencionadas.

En primer lugar, cabe destacar Medical Subject Headings (MeSH). MeSH (Lipscomb, 2000) es un amplio vocabulario terminológico controlado para publicaciones de artículos y libros de ciencia. MeSH permite su consulta y descarga de forma gratuita en la red. Cabe destacar que originalmente MeSH se publicaba en inglés, pero que en la actualidad ha sido traducida a varios idiomas y permite la recuperación de documentos en varios idiomas.

La versión de 2.008 contenía un total de 24.767 títulos de material, también conocidos como descriptores, la mayor parte de los cuales son acompañados generalmente por una breve descripción o definición, enlaces a los descriptores relacionados, y una lista de sinónimos o términos muy similares (conocidos con el nombre de términos de entrada).

Los descriptores o encabezamientos de materia se organizan de manera jerárquica. Un descriptor dado puede aparecer en varios lugares en el árbol jerárquico. Las ubicaciones árbol llevan etiquetas de manera sistemática, conocidas como número de árboles y, por consiguiente, un descriptor puede llevar varios números de árbol. El número de árboles de un descriptor dado está sujeto a los constantes cambios en la actualización del MeSH. Cada descriptor también lleva un número de identificación alfanumérico único, que no varía.

La Figura 10 muestra un ejemplo de esta estructura.

78

Figura 10. Estructura MeSH

A pesar del aparente potencial que podría generar este vocabulario, no es muy usado en sistemas informáticos orientados a la medicina, quizás debido a que su principal propósito está más focalizado a proporcionar un vocabulario estándar para publicaciones científicas como se ha mencionado anteriormente. A pesar de ello existen diversos trabajos, sobre todo orientados a recuperación de la información o búsqueda que hacen uso de dicho vocabulario (Sewell, 1964; Camps et al., 2006; Lowe & Barnett, 1987; Coletti & Bleich, 2001).

Otro interesante esfuerzo es IDO (Infectious Disease Ontology). Las ontologías IDO (Cowell & Smith, 2010) son un conjunto de ontologías interoperables que en conjunto proporcionan cobertura para el dominio de las enfermedades infecciosas. En el núcleo del conjunto existe una ontología IDO con entidades relevantes tanto a aspectos biomédicos como clínicos de las enfermedades infecciosas en general. Las extensiones específicas del subdominio del núcleo de IDO completan el conjunto proporcionando cobertura de entidades relevantes para los sub dominios específicos del campo de uno determinado conjunto de enfermedades infecciosas, como enfermedades concretas o áreas de investigación específicas.

Las extensiones que actualmente están bajo desarrollo como sub dominios de IDO son:

IDO - Brucelosis IDO - Fiebre Dengue IDO - Endocarditis infecciosa IDO - Gripe IDO - Malaria y otras enfermedades vectoriales/infecciosas. IDO - Bacteriemia por Staphylococcus aureus IDO - Tuberculosis IDO - Vacunas

Para finalizar, se expone otra propuesta de ontología llamada Symptoms Ontology.

Esta ontología ha sido diseñada siguiendo la definición del concepto de síntoma: Un cambio percibido en función de una sensación o aparición denotado por un paciente que es indicativo de una enfermedad.

79

Partiendo de la cercana relación existente entre signos y síntomas, donde los signos son la observación objetiva de una patología, la ontología de síntomas trabaja teniendo en cuenta este aspecto para capturar y documentar de una forma más robusta estos dos conjuntos de términos.

La Figura 11 muestra un ejemplo de un signo en el editor OBO-Edit de esta terminología.

Figura 11. Edición de signo en OBO-Edit

Sin embargo, esta ontología aún se encuentra en un desarrollo muy temprano, aunque parece una de las soluciones más sólidas en este tipo de vocabularios.

4.3. REPRESENTACION INFORMACIÓN MÉDICA

La forma en la que la información médica relativa al dominio de diagnóstico es modelada puede seguir varias pautas o modelos. Sin embargo, la mayoría de los sistemas estudiados en el estado del arte, demuestran que el modelo más clásico para representar la información entre una entidad enfermedad y los componentes que pueden afectar a la hora de diagnosticarla, es aquel en el que se establece una relación entre la propia enfermedad y estos componentes. En el ámbito médico, este tipo de modelado que permite conducir a un diagnóstico determinado es conocido como diagnóstico por criterios.

Debido a ello, tal y como se ha comentado previamente se deben aislar cuales son estos elementos o componentes constitutivos de una enfermedad, con el objetivo de generar un modelo de representación del conocimiento que sea aplicable al campo tratado.

Teniendo en cuenta que las entidades principales involucradas han cambiado en las distintas versiones de la base de conocimiento generada, a continuación se expondrá el modelo, así como sus elementos, y a medida que se avance en la lectura de la tesis se podrán comprobar los cambios básicos realizados.

Por último, se debe matizar que el modelo representacional utilizado es un modelo muy básico y simple. El motivo de utilizar un modelo de estas características se debe a dos aspectos fundamentales: El hecho de querer proporcionar un sistema de alta sensibilidad exige que las relaciones entre una enfermedad y otros elementos no involucren relaciones

80

complejas o restricciones en estas relaciones, pues eso implicaría un descenso en la sensibilidad. Por otra parte, este modelo representacional, es el más extenso y usado a la hora de diseñar este tipo de sistemas, con lo que puede considerarse como un estándar de facto a la hora de modelar bases de conocimiento de sistemas de diagnóstico.

La representación más básica del conocimiento relativo a los indicadores que tienen lugar en el sistema (enfermedades, síntomas/signos y pruebas de laboratorio3) sigue el esquema representado en la Figura 12:

Figura 12. Ejemplo de representación de enfermedades usado en ODDIN

En referencia a los síntomas o signos asociados a una determinada enfermedad pueden tener una serie de valores que indican el peso o la gravedad con la que se presenta el síntoma o signo. Estos posibles valores son los siguientes:

Muy bajo Bajo Medio Alto Muy alto

Asimismo, en el caso de las pruebas diagnósticas, los dos posibles pesos asociados son los siguientes valores:

Positivo Negativo

Esta representación de la información médica (referida a los signos y pruebas diagnósticas) solo ha sido utilizada en el primer sistema que se desarrolló para la verificación de las hipótesis (ODDIN) y que será comentado con detalle en posteriores capítulos. Debe destacarse que los pesos asociados a los signos o síntomas son elementos puramente probabilísticos que no interfieren en el proceso de inferencia.

3 En las primeras versiones de la base de conocimiento se hablaba del término pruebas de laboratorio. Sin embargo, en las versiones finales y más avanzadas se hablará del término pruebas diagnósticas, por ser este más correcto.

81

Aparte de la representación básica de las enfermedades, y sus relaciones con signos/síntomas y pruebas de diagnóstico existe otra forma de representar este conocimiento cuando un signo/síntoma de una enfermedad es otra enfermedad.

Para describir con más claridad este fenómeno, supongamos que tenemos dos enfermedades (X e Y) que se describen de la siguiente forma:

Figura 13. Definición de enfermedades con entidad enfermedad actuando como signo/síntoma

El citado ejemplo representa que la enfermedad llamada Disease X está compuesta de tres indicios (signos/síntomas o pruebas diagnósticas): SymC, SymD y SymE. Por otra parte, la enfermedad Disease Y está compuesta por el indicio SymA, SymB y la enfermedad Dis X (Abreviatura de Disease X).

Como se puede observar, la representación de la enfermedad Disease Y, también podría verse desde la siguiente perspectiva:

82

Figura 14. Representación de la enfermedad Y

El objetivo de esta representación es dar a entender que en la enfermedad Disease Y, el síntoma o signo Disease X puede ser sustituido por aquellos síntomas o signos que componen la propia Disease X.

Para comprender este concepto más claramente se dispone de un ejemplo real:

Supongamos la enfermedad del Cólera. Esta enfermedad tiene varios síntomas y signos asociados, entre los que podemos destacar algunos (no están todos):

Diarrea Vómito y náuseas Apatía Boca seca Debilidad Deshidratación

Por otra parte, la Deshidratación además de ser un síntoma/signo dentro del Cólera, también representa una entidad enfermedad por sí misma, y como tal, la Deshidratación tiene una serie de síntomas/signos asociados, entre los que a continuación se citan algunos:

Bajo nivel sanguíneo Taquicardia Piel fría Turgencia cutánea disminuida Confusión Delirios Oliguria Boca seca Ritmo cardiaco bajo Pulso lento

El problema que se plantea en la hipótesis H2, y que se trata de resolver con nuestro sistema es si tuviéramos la siguiente consulta:

83

Diarrea – (C) Vómito y náuseas – (C) Apatía – (C) Boca seca – (C) Debilidad – (C) Bajo nivel sanguíneo – (D) Taquicardia – (D) Piel fría – (D) Turgencia cutánea disminuida – (D) Confusión – (D) Delirios – (D) Oliguria – (D) Ritmo cardiaco bajo – (D) Pulso lento – (D)

Aquellos que están marcados con la indicación (C) representan los síntomas/signos asociados al cólera pero que no forman parte de la deshidratación, mientras que los marcados con la indicación (D) representan a la propia deshidratación.

Con este esquema, los sistemas clásicos no serían capaces de realizar un diagnóstico del cólera puesto que no podrían inferir que los elementos marcados en azul representan una entidad que está asociada al propio Cólera. Este diagnóstico, nombrado diagnóstico multinivel, o diagnóstico mediante inferencia multinivel es muy útil en ciertos casos donde como el que se ha expuesto existen ciertas patologías que forman parte de otra.

Para finalizar, se debe volver a destacar la importancia del modelo de representación del conocimiento presentado, donde uno de sus parámetros más importantes es precisamente esta sencillez en la codificación del conocimiento del dominio. Esta sencillez es importante para poder garantizar ciertos parámetros que el sistema pretende obtener, como su alta sensibilidad y su exactitud.

4.4. ONTOLOGÍA. VERSIÓN INICIAL

La primera ontología desarrollada para verificar las hipótesis planteadas en esta tesis, es descrita en esta sección.

La ontología desarrollada ha sido creada basándose en el conocimiento de expertos en medicina con el objetivo de generar una especificación válida del dominio concreto que se pretendía modelar: diagnóstico diferencial en medicina. Aunque existen diversas metodologías que se pueden aplicar dentro del mundo de la biomedicina para el diseño y construcción de ontologías médicas pero con objetivos ligeramente distintos, como la construcción de ontologías para la migración de datos biomédicos a partir de historias clínicas electrónicas (Smith & Ceusters, 2005) o generación de ontologías médicas a partir de recursos de texto (Baneyx et al., 2006), entre otros, en esta tesis se ha decidido crear la ontología siguiendo metodologías para la creación de ontologías más tradicionales (Noy & McGuinness, 2001) debido a que las metodologías expuestas anteriormente se centran más en otro tipo de datos biomédicos.

Esta primera ontología no hace uso de las terminologías más comunes como las descritas en las secciones anteriores, excepto por el uso de la Clasificación Internacional de Enfermedades v10 (CIE-10).

El uso de estas terminologías, queda reflejado en la versión final.

84

4.4.1. DISEÑO

La ontología diseñada viene fuertemente marcada por las relaciones existentes entre las principales entidades médicas propuestas. Estas relaciones, en el diseño de ontologías se establecen mediante el uso del elemento ObjectProperty, que establece una relación binaria para relacionar instancias de dos clases. Además de estas relaciones, existen las relaciones entre instancias y lo que se podría considerar tipos de valores típicos mediante las relaciones de tipo DataProperty.

En lo referido a las entidades, estas se representan en la ontología mediante el uso de clases, que sirven para definir en este caso cada una de las entidades y subelementos de estas (subentidades). Las clases de las entidades que han sido mencionadas anteriormente representan las raíces de varios árboles taxonómicos.

4.4.1.1. CLASES

En el diseño original de la ontología, se establece una jerarquía básica de clases que contiene los elementos que son parte del diagnóstico. Las clases que representarán a las distintas entidades son por lo tanto las siguientes:

Diseases Symptoms Labtests Medicines Consult LabTestContainer SymptomContainer MedicineContainer

Las clases marcadas en negrita son aquellas que representan a las entidades principales.

Estas clases principales, que representan las entidades descritas anteriormente, son a la vez el nivel raíz de una jerarquía que se encarga de representar los distintos tipos de enfermedades, síntomas o pruebas de laboratorio que se pretenden almacenar en la base de conocimiento. La representación y jerarquía usada está basada en la Clasificación Internacional de Enfermedades versión 10 (CIE 10) (WHO, 2010), la cual representa un sistema de clasificación de información clínica (principalmente enfermedades, síntomas y signos, y pruebas de laboratorio). Este estándar ha sido desarrollado por la Organización Mundial de la Salud (OMS) y es un referente internacional para la clasificación de enfermedades.

El primer nivel de clases contempla la clasificación inicial de diversos tipos de enfermedades, síntomas o pruebas de laboratorio. En el caso de enfermedades, por ejemplo, estas serían: Infecciosas, neoplasias, enfermedades del aparato respiratorio, enfermedades del aparato circulatorio, etc. A su vez, dentro de estos grupos se van estableciendo más subniveles hasta que se llega a una enfermedad, síntoma o prueba de laboratorio concreto sin subtipos o variedades. Las hojas del árbol de representación identificarían estos elementos.

En este caso, una vez se llega a un nivel hoja, se asume que estamos en un elemento concreto y es por ello que se genera dentro una instancia (Individual en el argot de Ontology Web Language (OWL)), que no es más que un elemento que permite describir a una clase. Las instancias son las que contienen generalmente la información concreta y

85

detallada del elemento que representan. En este caso, la enfermedad, síntoma, prueba de laboratorio, etc.

El hecho de seguir la estructura que proporciona la CIE se debía fundamentalmente a una mayor claridad en la ordenación de los indicios que toman parte en el proceso de diagnóstico, siendo más sencilla su visualización y edición.

Es importante recalcar que cada indicio concreto debe estar representado por una instancia, ya que la instancia es la que juega el papel primordial cuando se establezcan las relaciones entre unas y otras.

Aparte de las clases principales, existen otras clases en la ontología diseñada. Una de ellas es por ejemplo la clase "Consult", cuyo objetivo es el almacenamiento en la propia ontología (que está actuando al fin y al cabo como base de conocimiento) de las instancias que son generadas cuando se crea una "query de diagnóstico". El objetivo de este almacenamiento es el de hacer uso del razonamiento incremental, que es explicado más adelante.

Además de esta clase, se han modelado tres clases más que actúan de contenedores (LabTestContainer, SymptomContainer, MedicineContainer).

El objetivo de estas clases es poder establecer relaciones entre indicios y ciertas propiedades asociadas a estos. Si por ejemplo queremos establecer unas aclaraciones referidas a "un cierto síntoma" en "una cierta enfermedad" con una configuración de relación binaria (que es la que se establece en las relaciones de OWL) es imposible, dado que si se establece, por ejemplo, directamente en el síntoma, esta "aclaración" afectaría a todas las enfermedades las cuales tuvieran a dicho síntoma como indicio.

Un ejemplo directo es el siguiente:

Supongamos que queremos indicar en la base de conocimiento ciertas "observaciones" relativas o dependientes entre un síntoma y una enfermedad. El ejemplo que actualmente está codificado son observaciones de tipo texto, donde se indica por ejemplo que el síntoma "fiebre" en la enfermedad "Cólera" es un indicio grave. Dado que hace referencia a un síntoma que puede estar presente en muchas otras enfermedades, se establece por lo tanto este contenedor, que está vinculando por una parte al propio contenedor con el síntoma, y por otra al propio contenedor con la enfermedad, estableciendo determinadas características o atributos como parte del contenedor para poder acceder a esa información.

Otro ejemplo es el de los síntomas patognómicos. El término patognomónico se utiliza para denominar "aquellos signos (manifestaciones visibles) o síntomas (manifestaciones no visibles, subjetivas) que, si están presentes, aseguran que el sujeto padece un determinado trastorno" (Carpenter et al., 1973). Aunque estas manifestaciones se relacionan en pares, debido a que cuando están presentes aseguramos una enfermedad, y por lo tanto no deberían ser indicio de ninguna otra, en nuestro sistema se representan mediante una característica binaria que permite indicar que la relación entre una enfermedad y un signo implica que el signo es patognómico. Un ejemplo concreto es el del signo de las Manchas de Koplik (Koplik, 1896) que establecen una relación directa con el Sarampión (WHO Measles, 2010).

La Figura 15 muestra la relación que se representa mediante el uso de los contenedores:

86

Figura 15. Representación de la relación entre enfermedades y síntomas

Los elementos son los datos que se guardan para establecer la relación entre ambos elementos pero que solo existen en dicha relación (entre una enfermedad concreta y un síntoma concreto, no de forma genérica).

Así mismo se ve que existe una relación entre enfermedad y síntoma. Esta relación es directa debido a que, de cara al sistema de inferencia es necesario establecer las relaciones entre síntomas y enfermedades, pero sin intermediarios, dado que eso dificultaría las tareas de razonamiento al tener de cruzar a través de una relación intermedia, mientras que de la forma mencionada arriba la relación es directa.

Esta relación directa sin embargo genera un duplicado de información, dado que la relación Enfermedad – Síntoma está implícita a través del contenedor.

Esta relación es exactamente la misma con el resto de elementos (pruebas de laboratorio y medicinas). El caso de los indicios patognómicos solo existe en la relación síntomas – enfermedades.

4.4.1.2. RELACIONES

Como se ha recalcado anteriormente, las relaciones juegan, probablemente, el papel más importante dentro del sistema al definir precisamente el vínculo existente entre las diversas entidades que se han mencionado anteriormente, siendo las relaciones entre enfermedades y síntomas y pruebas de laboratorio las relaciones principales, pues definen la esencia de la enfermedad y por lo tanto dicha relación permite establecer la posibilidad de inferencia de diagnóstico.

La Tabla 5 muestra las relaciones que se han establecido en la ontología del sistema. Toda relación se establece entre dos extremos, que son las clases a las cuales hace referencia dicha relación. Estos extremos se denominan dominio y rango.

87

Nombre Dominio Rango isUsingMedicine Consult Medicines

isLabTestOf Labtests Diseases isSymptomOf Diseases

Symptoms Consult Diseases

Medicines hasLabTest Diseases Labtests

hasSymptom Consult Diseases

Medicines

Diseases Symptoms

containsSymptomOrDisease SymptomContainer Diseases Symptoms

containsLabTest LabTestContainer LabTests containesMedicine MedicineContainer Medicines

hasSymptomContainer Diseases Medicines

SymptomContainer

Tabla 5. Tabla de relaciones del sistema ODDIN

A continuación se realiza una descripción en detalle de las propiedades usadas así como los dominios y rangos que intervienen en las mismas.

isUsingMedicine: La relación isUsingMedicine se utiliza para especificar si el paciente sobre el que se está realizando la consulta está tomando algún tipo de fármaco o medicina. La relación por lo tanto se realiza en la clase Consult, que es donde se almacenará toda la información de la consulta y la clase Medicines, que contendrá las subclases e instancias de las posibles medicinas o fármacos que el paciente esté consumiendo.

isLabTestOf: La relación isLabTestOf se utiliza para relacionar las pruebas de laboratorio con las posibles enfermedades. La idea es que la relación se define de la forma "prueba de laboratorio 1 isLabTestOf enfermedad X". De esa forma, se sabría que la prueba "prueba de laboratorio 1" es una de las pruebas que se realizan para el diagnóstico de la "enfermedad X".

isSymptomOf: La propiedad isSymptomOf se utiliza con el objetivo de relacionar los síntomas que son característicos de una determinada enfermedad con dicha enfermedad. Por ejemplo, se podría establecer la relación "fiebre isSymptomOf Colera".

hasLabTest: La propiedad hasLabTest es la propiedad inversa a "isLabTestOf" y permite relacionar las pruebas de laboratorio con las enfermedades del mismo modo que lo hace isLabTestOf.

hasSymptom: La propiedad hasSymptom es la propiedad inversa a "isSymptomOf" y permite relacionar los síntomas con las enfermedades del mismo modo que lo hace isSymptomOf.

containsSymptomOrDisease: La propiedad containsSymptomOrDisease permite relacionar a un contenedor de síntomas con un determinado síntoma o enfermedad. El objetivo de relacionarlo con síntomas o enfermedades se debe a que se permite que una determinada enfermedad sea síntoma de otra (este concepto se definirá más adelante con el concepto de síndrome cuando se realice el diagnóstico por niveles dentro de los sistemas ADONIS y SEDELO).

containsLabTest: La propiedad containsLabTest sirve para relacionar a un contenedor de pruebas de laboratorio con una determinada prueba de laboratorio.

88

containsMedicine: La propiedad containsMedicine sirve para relacionar a un contenedor de medicinas con una determinada medicina o fármaco.

El hecho de tener relaciones que se podrían considerar “duplicadas” (hasLabTest / isLabTestOf), donde se intercambian la una con la otra el dominio y el rango se debe a que las relaciones “is” se utilizan para la carga de datos en el sistema. Mediante estas propiedades, se permite consultar al sistema y por ejemplo extraer todas las pruebas de laboratorio asociadas a una determinada enfermedad. Sin embargo, la relación hasLabTest que relaciona a la enfermedad con las pruebas de laboratorio es la que se utilizará durante el proceso de inferencia.

Las relaciones que hacen referencia a los contenedores (contains) son relaciones funcionales, lo que quiere decir que no pueden tener más de un valor asociado tanto en el dominio como en el rango. Esto es una limitación para que cada posible relación entre dos entidades deba hacerse a través de un contenedor distinto, y así en caso de querer introducir información adicional, se sabrá siempre que esa información hace referencia al par de elementos al que está vinculando el contenedor.

En la Figura 16 se muestra un ejemplo de una posible relación entre una determinada enfermedad y dos síntomas y una prueba de laboratorio.

Figura 16. Ejemplo de relación de una enfermedad

Las relaciones por lo tanto que se supone que debería tener esta enfermedad (Disease P) en el modelo diseñado para la ontología del sistema y que acaba de ser expuesto serían las siguientes:

hasSymptom SYM A SYM E

hasLabTest LT 1

hasLabTestContainer DIS_P_CONTAINER_LT_1

hasSymptomContainer DIS_P_CONTAINER_SYM_A DIS_P_CONTAINER_SYM_E

La Figura 17 muestra una captura de pantalla del software de edición de ontologías Protégé donde se edita la enfermedad “Disease P” según a lo dispuesto anteriormente.

89

Figura 17. Representación de enfermedad en Protégé

A continuación se muestra una representación en código OWL de la situación anteriormente expuesta.

<rdf:Description rdf:about="http://a.c/h.owl#DIS_P">

<hasLabTestContainer rdf:resource="http://a.c/h.owl#DIS_P_Container_LT_1"/>

<hasLabTest rdf:resource="http://a.c/h.owl#LT_1"/>

<hasSymptom rdf:resource="http://a.c/h.owl#SYM_E"/>

<hasSymptom rdf:resource="http://a.c/h.owl#SYM_A"/>

<rdf:type rdf:resource="http://a.c/h.owl#DIS_P_Class"/>

<hasSymptomContainer rdf:resource="http://a.c/h.owl "/>

<hasSymptomContainer rdf:resource="http://a.c/h.owl#DIS_P_Container_A"/>

</rdf:Description>

Snippet 9. Representación de enfermedad en OWL

4.4.1.3. PROPIEDADES DE DATOS

En el diseño de la ontología se han incluido varias propiedades de tipo DataType” en las cuales se representan datos que no indican relaciones. Este tipo de datos pueden ser valores nominales, numéricos, etc. El objetivo de introducir este tipo de campos era poder identificar mediante datos como por ejemplo el nombre, o código CIE de las entidades, así como poder introducir información adicional sobre las mismas como observaciones, enlaces, nombres alternativos, etc.

90

A continuación, se muestra en la Tabla 6 con las propiedades que han sido introducidas, y se mostrará una pequeña explicación de las mismas.

Nombre Dominio Rango ageRank Diseases String

code All (Excepto Contenedores) String countriesWithMoreIncidence Diseases String

description All (Excepto Contenedores) String isCIE All (Excepto Contenedores) Boolean

isPatognomic SymptomContainer Boolean links All (Excepto Contenedores) String

names All (Excepto Contenedores) String observations All String operations Diseases Boolean

sex Diseases String (Nominal) tags All (Excepto Contenedores) String

transfusions Diseases Boolean weight SymptomContainer Integer

Tabla 6. Propiedades DataType de ODDIN

Aquellas propiedades marcadas en subrayado son propiedades funcionales y por lo tanto solo admiten un solo valor.

Cuando en el dominio se especifica All, se refiere a las clases que representan a las distintas entidades (Medicines, Symptoms, Labtests, Diseases y todos los posibles contenedores: LabTestContainer, MedicineContainer y SymptomContainer). Cuando se especifica “Excepto Contenedores” solo hace referencia a las clases de las entidades.

Se debe tener en cuenta que las propiedades se heredan en la jerarquía de clases, y por eso solo se aplica a los nodos raíz (entidades).

A continuación se ofrece en detalle la descripción de todas las propiedades.

ageRank: Representa los rangos de edad posibles para una determinada enfermedad. Con esto se calculará una probabilidad final dependiendo si hubiera enfermedades que en un rango de edad tuvieran más probabilidades de ser padecidas y el paciente estuviera en dicho rango. En la interfaz del sistema estos se presentan como unos valores predeterminados. En la versión que se desarrolló del sistema no aparecía reflejado de esta forma, aunque lo más coherente sería establecer unos determinados valores (hacer que la propiedad o variable pasara a ser de tipo nominal), restringiendo de esta forma los posibles valores que la variable podría determinar.

code: El código sirve para identificar el indicio o entidad tratada. Generalmente el código debería ser el código CIE que represente a la enfermedad, prueba de laboratorio o síntoma en el sistema de Clasificación Internacional de Enfermedades.

Se establece que la propiedad código sea de tipo funcional, para que no se pueda introducir más de un código asociado a un determinado indicio. Esto podría ser sin embargo discutible ya que existen diversas clasificaciones y podría ser interesante el introducir nuevos tipos de clasificación, y por lo tanto, sus códigos asociados. Sin embargo, la versión actual del sistema, al estar basada en un sistema de codificación concreto, se sabe que no habrá duplicados, y por esa razón no se permite introducir múltiples valores.

En esta versión no se consideró por ejemplo los códigos de las medicinas como parte del CIE ya que las medicinas se rigen por otras clasificaciones como la ATC (Anatomical,

91

Therapeutic, Chemical classification system). En el caso de que no exista o no se encontrara un código CIE válido para un indicio se introduciría un código que el experto propondría basándose en su criterio. En este caso se indicaron como posibles prefijos para códigos, los siguientes:

NCD: Acrónimo de Not CIE Disease. El objetivo sería crear identificadores de tipo NCD00001, NCD00002, etc.

NCS: Acrónimo de Not CIE Symptom. El objetivo sería crear identificadores de tipo NCS00001, NCS00002, etc.

NCL: Acrónimo de Not CIE Laboratory test. El objetivo sería crear identificadores de tipo NCL00001, NCL00002, etc.

countriesWithMoreIncidence: Esta propiedad representa una posible lista de países donde la enfermedad a la que hace referencia tiene una mayor incidencia.

description: Esta propiedad se utiliza para proporcionar una descripción de alguna de las entidades involucradas en el sistema.

isCIE: Propiedad usada para establecer si la entidad a la que está representando está codificada en el sistema CIE.

isPatognomic: Propiedad usada para establecer si el contenedor de síntomas que está representando está indicando que el síntoma al que enlaza es un síntoma patognómico de la enfermedad a la que enlaza. Como se ha comentado previamente en principio se supone que los síntomas patognómicos ya son únicos de un único proceso patológico o enfermedad. Aun así se decidió realizar esta representación debido al sistema combinatorio implementado en el sistema.

names: Propiedad para describir los posibles nombres de una determinada entidad. Se establece que pueda existir más de un nombre. Por ejemplo: Cefalea, dolor de cabeza

observations: Propiedad para establecer algún tipo de observación sobre alguna entidad concreta. También se utiliza sobre los contenedores debido a que es posible que se quiera indicar una observación concreta sobre una relación.

operations: Propiedad para indicar si la enfermedad puede haber sido provocada o haber nacido a causa de una operación.

sex: Propiedad para indicar si la enfermedad es más sensible o está identificada en un género concreto. Es una propiedad de tipo nominal ya que solo se permiten tres opciones:

Male Female Indifferent

tags: Propiedad para indicar posibles tags de búsqueda de las distintas entidades.

transfusions: Propiedad para indicar si la enfermedad es más sensible o pudo ser provocada debido a una transfusión.

weight: Propiedad que está relacionada únicamente con el contenedor de síntomas y cuyo objetivo es establecer el peso del síntoma. Se utiliza un entero para indicar la virulencia de menos (1) a más (5), adaptándose a los valores desde muy bajo hasta muy alto.

92

4.5. ONTOLOGÍA. VERSIÓN FINAL BASADA EN SNOMED-CT

La adaptación de la ontología inicial que ha sido descrita en la sección anterior requirió en primer lugar una reestructuración interna de los elementos que la conforman para intentar adaptarse a ciertos estándares o metodologías de definición de ontologías. En el artículo de Hadzic & Chang (2005), uno de los más interesantes para el caso de estudio tratado en esta tesis, y concretamente en este capítulo, se propone la generación de una ontología de tipo genérico llamada "Generic Human Disease Ontology" donde se represente la información en cuatro dimensiones fundamentales:

Tipos de enfermedades Fenotipos o síntomas Causas relacionadas con la enfermedad (principalmente causas

genéticas y medioambientales) Tratamientos para la enfermedad

En esta ontología también se pretende además dar soporte al estudio de desórdenes complejos causados por varios factores, como el desorden maniaco depresivos.

En este artículo se mencionan además varias ontologías (TAMBIS (Stevens et al., 1999), GO), las cuales se encargan de ciertas partes de representación del conocimiento en bioinformática, pero que sin embargo estas ontologías no guardan relación con las enfermedades humanas.

De este artículo se extraen interesantes conclusiones, dado que aparte del hecho de no usar un vocabulario estandarizado, la ontología definida previamente no se diferencia demasiado en otras propuestas aparentemente más aceptadas dentro de la comunidad científica. Los únicos cambios aparentemente significativos son por ejemplo el cambio de nombre en las relaciones para adaptarse a unos determinados estándar, pero al fin y al cabo las relaciones tratan de representar en esencia la misma información que en la ontología ya desarrollada. Como posible ventaja se denota que quizás la relación parece estar ligeramente mejor establecida, dado que se habla de la división de una enfermedad en tipos, y esta a su vez en subtipos.

Teniendo en cuenta los aspectos mencionados en los párrafos anteriores, se va a realizar una adaptación del sistema actual a un tipo de taxonomía estandarizada, con el objetivo de que la ontología final sea reutilizable y se permita la futura interoperabilidad del sistema propuesto con otros sistemas al utilizar un vocabulario común.

4.5.1. SOLUCIÓN PROPUESTA

Como se ha podido observar en las secciones anteriores, actualmente existen varias terminologías, vocabularios o sistemas de clasificación en el ámbito médico que pueden y se deben tener en cuenta cuando se realiza algún tipo de sistema clínico. La mayoría de estos vocabularios o terminologías basan su ámbito de existencia en ser útiles a la hora de ser utilizados, sobre todo, en historias clínicas, como es por ejemplo el caso de SNOMED-CT. A pesar de eso, su único caso de uso no es este, pues todo aquel sistema que requiera ser interoperable con otro, necesita utilizar alguna terminología estándar para que sea capaz de comunicarse.

La interoperabilidad por lo tanto es uno de los puntos clave también a la hora de desarrollar este tipo de terminologías. El hecho de que dos máquinas sean capaces de entenderse e intercambiar información médica de forma precisa es uno de los primeros pasos que se tienen conseguir si queremos conseguir que exista un intercambio de

93

información entre máquinas que permita la generación de sistemas clínicos con más capacidades.

Sin embargo, a pesar de esto, siguen existiendo demasiadas terminologías, aunque haya algunas que ya sean tomadas como "el estándar", como es el caso de SNOMED-CT.

4.5.1.1. DESCARTE DE TERMINOLOGÍAS

El problema que se plantea en el caso de uso concreto que se muestra en esta tesis, que es el de, dotar a nuestra base de conocimiento (representada por una ontología), de unas ciertas características que le permitan estar envuelta en una determinada terminología estándar, no es fácil de resolver a pesar de todas las herramientas existentes. En esta sección por lo tanto, se pretende analizar las ontologías que han sido estudiadas anteriormente, con el objetivo de descartar aquellas que no sean válidas para el propósito que se pretende solventar en este capítulo.

El sistema actual es un sistema de soporte al diagnóstico, y como tal, su campo o dominio concreto es el del diagnóstico diferencial. En este dominio a su vez se pueden observar distintos subdominios, siendo principalmente los siguientes:

Enfermedades Síntomas/Signos Pruebas diagnósticas Fármacos

Para dos de los elementos tenemos dos soluciones que podrían, dado un cierto momento, llegar a ser útiles. Es el caso de las enfermedades y síntomas/signos. Sin embargo, no existen para el resto de elementos (pruebas diagnósticas y fármacos) terminologías concretas que representen estas entidades.

Aun teniendo en cuenta que, para dos de los elementos existen terminologías concretas, si se analizan con detalle se puede observar, que dado el dominio actual que se está manejando, y dada la estructura interna que estas terminologías tienen, estas no son válidas.

Se debe tener en cuenta que el dominio que se quiere modelar es el de diagnóstico diferencial, donde intervienen los cuatro elementos citados anteriormente. Esto implica que todas aquellas relaciones o definiciones adicionales sobre cualquiera de estos elementos no implican ningún tipo de utilidad. La carencia de utilidad, en este caso concreto, conlleva además la generación de problemas asociados, dado que al existir elementos que no van a ser utilizados ni considerados en cuenta, esto implica que el sistema encargado de gestionar la base de conocimiento va a necesitar procesar términos que no va a utilizar, dando esto como lugar a un consumo de memoria innecesario, así como un retraso temporal en el manejo de los datos o en el proceso de razonamiento.

Existen además otros motivos de exclusión de las terminologías más específicas que podrían servir en el propósito de modelado actual.

94

Disease Ontology (DO)

El primer descarte se centra en la Disease Ontology (DO). La Figura 18 muestra la aplicación Protégé editando la ontología DO. Se puede observar como al editar una determinada instancia, la cual hace referencia a la Enfermedad de Huntington.

Figura 18. Protégé editando DO

Como se puede observar, se establecen tres superclases antes de esta enfermedad concreta:

La primera superclase hace referencia al ID 0050177 de la DO: Enfermedad genética simple.

La segunda superclase hace referencia al ID 1307 de la DO: Demencia.

La tercera superclase hace referencia al ID 679 de la DO: Enfermedades de los ganglios basales.

Estas superclases están por lo tanto para indicar, dada una enfermedad concreta, a que categorías pertenece dicha enfermedad. En este caso, dadas las características de la enfermedad de Huntington se establecen esas tres superclases, al ser una enfermedad genética (la categorización de simple viene dada por denominadores genéticos), que provoca demencia y que la enfermedad de Huntington, junto con otras patologías neurológicas de orden subcortical como por ejemplo el Parkinson representa un importante modelo humano de la disfunción cognitiva de los ganglios basales.

En la imagen anterior también se pueden observar una serie de relaciones llamadas hasExactSynonym para hacer referencia a los sinónimos de la enfermedad, siendo estos otros nombres que puede adquirir o referencias de otro tipo pero que relacionan exactamente esa enfermedad (por ejemplo, referencias genéticas como pueda ser la secuencia de la enfermedad).

95

Como se puede observar, se hace referencia a cinco instancias concretas:

genid29871: HD genid29873: Huntington's chorea genid29875: Huntington's chorea (disorder) genid29877: Huntington's disease genid29879: Huntington's disease pathway

La Figura 19, sigue haciendo referencia a la enfermedad de Huntington. En este caso se muestran las relaciones dbxref. Estas relaciones sirven para relacionar el término concreto de la ontología con su equivalente en otras terminologías estandarizadas (mapeo), y si es posible, una URI para hacer referencia a ellas directamente:

Figura 19. Relaciones enfermedad de Huntington

En este caso, se hace referencia a 6 instancias, las cuales proporcionan una etiqueta la identificación del término en la terminología y una URI si es posible realizar una asociación directa. Se resume en la Tabla 7:

Instancia Código Terminología

URI

genid29881 ICD9CM_2010:333.4 http://purl.org/obo/owl/ICD9CM_2010#ICD9CM_2010_333.4 genid29882 MSH2010_2010_02_2

2:D006816 http://purl.org/obo/owl/MSH2010_2010_0_2_22#MSH2010_2

010_02_22_D006816 genid29883 NCI2009_04D:C38825 http://purl.org/obo/owl/NCI2009_04D_C38825 genid29884 SNOMEDCT_2010_1_3

1:155006000 http://purl.org/obo/owl/SNOMEDCT_2010_1_31#SNOMEDCT_

2010_1_31_155006000 genid29885 SNOMEDCT_2010_1_3

1: 58756001 http://purl.org/obo/owl/SNOMEDCT_2010_1_31#SNOMEDCT_

2010_1_31_58756001 genid29886 UMLS_CUI:C0020179 http://purl.org/obo/owl/UMLS_CUI#UMLS_CUI_C0020179

Tabla 7. Resumen instancias enfermedad de Huntington

Hasta aquí, todo parece más o menos correcto (aunque se anotaran ciertas particularidades al final que hacen también que se deseche esta terminología).

Sin embargo, el formato utilizado para la representación del conocimiento no es del todo correcto para el dominio presentado. A pesar de tener una característica fundamental, que es el uso de la relación has_symptom para relacionar síntomas con enfermedades, si analizamos detenidamente la ontología podemos observar que esta relación no es usada de una forma que permita la asignación de síntomas a enfermedades

96

de forma directa. En las imágenes anteriores la relación has_symptom no aparece por ningún lado (si bien está modelada de una forma un tanto particular mediante anotaciones).

Si se analiza la ontología con un editor, en busca de referencias a has_symptom, podemos observar que si existen referencias, pero no en el sentido estricto que se establece al relacionar términos en una ontología. Por ejemplo, el siguiente snippet muestra una de estas referencias dentro de una label:

<rdfs:label xml:lang="en">A Pneumocystis infectious disease and

is_a pneumonia that is located_in lungs, has_agent Pneumocystis

jirovecii that effects interstitial and alveolar tissues and

has_symptom nonproductive cough, has_symptom shortness of breath,

and has_symptom fever.</rdfs:label>

En este caso, vemos que la label define la enfermedad Neumocistitis (Pneumocystis infectious), donde define que es un tipo de neumonía (is_a pneumonia) que está localizada en los pulmones (located_in lungs) y que tiene un agente patógeno concreto (has_agent Pneumocystis jirovecii) que tiene efectos entre los tejidos alveolares (effects interstitial and alveolar tissues) y que tiene asociados como síntomas tos, dificultad para respirar y fiebre (has_symptom nonproductive cough, has_symptom shortness of breath, and has_symptom fever).

El hecho de que esta definición, y sobre todo, su asociación con los síntomas concretos sea hecha por medio de una etiqueta deshecha por completo la ontología para ser usada (íntegramente) como parte de la nueva ontología que se pretende generar, dado que las relaciones necesitan ser establecidas de forma directa, y no a través de etiquetas, para dar soporte al proceso de inferencia.

Otra característica que se tiene que tener en cuenta para la exclusión de esta ontología es el hecho de las referencias que hace a los códigos de otras terminologías mediante la relación dbxref. Desde un punto de vista de interoperabilidad, se puede entender el hecho de incluir estos datos, pero también se podría plantear la inclusión de un solo código (el propio de la DO), y buscar el resto de términos, por ejemplo, en una base de datos.

Esto tendría dos ventajas principalmente:

Rapidez en la consulta de términos incluso cuando la ontología sea demasiado grande, dado que una consulta SQL llevará menos tiempo que una consulta SPARQL donde se ha de consultar un modelo en memoria que no está preparado para ser optimizado igual que una base de datos.

Disminución del tamaño de la ontología, dado que al hacer referencia a un único código, se prescindirían de ciertos datos que no siempre van a ser usados, y que, al introducirlos en una base de datos externa siempre estarían disponibles.

El único inconveniente asociado a esta solución sería la creación de una base de datos para guardar las referencias a las otras terminologías, siendo esta una cuestión relativamente sencilla de resolver.

UMLS/SNOMED-CT y GALEN

SNOMED-CT, como terminología preparada para ser un estándar a la hora de dotar de interoperabilidad a los sistemas que hagan uso de ella tiene ciertos problemas para su uso en el contexto actual. El primero y más claro se basa en la relación entre los términos y

97

conceptos que comprenden la misma. Dado el esquema que se pretende presentar en esta tesis, donde el objetivo es la creación de un sistema de diagnóstico diferencial, las relaciones establecidas dentro de la terminología de SNOMED-CT carecen de utilidad. El principal escollo se plantea en la carencia de relaciones que definan como se relacionan las enfermedades con los síntomas o signos.

A continuación podemos ver una captura de pantalla en la Figura 20 de un navegador en el que hemos buscado el término de enfermedad de Huntington para ver los valores mostrados en SNOMED-CT.

Figura 20. Concepto en SNOMED-CT

En el caso de GALEN, se presenta el mismo problema, al carecer de ciertas relaciones fundamentales cuando se está diseñando un sistema de diagnóstico, donde lo principal es poder tener las relaciones entre enfermedades y otras entidades, haciendo que esta terminología deba ser también desechada.

Sin embargo, teniendo en cuenta que SNOMED-CT es la principal terminología utilizada en entornos clínicos no se debe desechar por completo su uso. En concreto, el uso de SNOMED-CT en este caso concreto se basará en utilizar principalmente sus códigos como identificadores principales de los conceptos que se establezcan en la ontología final que será desarrollada para soportar la base de conocimiento del sistema sobre el que se descarga la tesis.

Así mismo, también los códigos que representen los elementos en GALEN serán usados, aunque estos, fuera de la ontología, en un soporte de base de datos. La Figura 21 muestra la representación nuevamente de la enfermedad de Huntington en GALEN.

Figura 21. Enfermedad de Huntington en GALEN

98

Symptoms Ontology

La ontología de síntomas era la principal candidata a ser usada durante el desarrollo de esta tesis. La razón fundamental para utilizar esta ontología era principalmente su sencillez, dado que las relaciones usadas en dicha ontología no eran para nada complejas como sucede en otras como GALEN o SNOMED, y la jerarquía seguida para su construcción tenía hasta cierto punto lógica.

Sin embargo, los problemas que planteaba, lo que hacía que se la descartara como ontología a usar son los siguientes:

El formato principal de desarrollo es el formato OBO. Esto, que en principio es salvable dadas las características de ciertos editores como Protégé de editarla y salvarla en formato OWL, puede acarrear ciertos problemas debido al funcionamiento inestable de las APIs utilizadas para la carga de la base de conocimiento en aquellos ficheros que no han sido OWL siempre, dado que el método de exportación a estos formatos de los editores en ocasiones falla.

Otro problema bastante importante se basa en la aparente descontinuación del proyecto. El Wiki en donde se puede encontrar toda la información sobre la ontología argumentaba futuros cambios en la misma como la introducción de nuevas relaciones que relacionaran indicios con enfermedades, sin embargo, estas relaciones en la última versión son inexistentes.

Para finalizar, la principal carencia de esta terminología es precisamente la ausencia de mapeado a terminologías más estándar como SNOMED-CT, lo que supone un fallo realmente importante, ya que estos códigos son necesarios según el nuevo esquema que se pretende generar.

Otras

El resto de terminologías mencionadas como MeSH o IDO nuevamente tienen los mismos problemas que las anteriores donde carecen de las relaciones que son necesarias dentro del dominio que presenta la tesis.

4.5.1.2. PLANTEAMIENTO DE LA SOLUCIÓN

El diseño de la solución propuesta para utilizar terminologías estándar se basará en utilizar SNOMED-CT como base para representar los códigos de todos los conceptos que aparezcan en la ontología a diseñar.

La idea es que el código SNOMED-CT asociado a cada concepto sea el código principal a través del cual se podría obtener toda la información asociada al concepto mediante el uso de una base de datos, en vez de almacenar toda la información en la ontología.

Esta solución se basa en tratar de hacer lo más ligera posible la ontología que será utilizada para el razonamiento e inferencia de las posibles enfermedades dentro del diagnóstico diferencial. La idea es que esta ontología solo contendrá las relaciones, así como un código identificador (en formato de SNOMED-CT) y el nombre del concepto en inglés. En caso de que, se quiera obtener información adicional (nombre en otro idioma, sinónimos, código de otra terminología, enlaces de interés sobre el concepto (Medline, Wikipedia,…) etc.) se accederá a una base de datos que contendrá todos estos datos.

99

Con la solución propuesta, se solucionan varios problemas que habían sido identificados en la primera versión de la ontología y que las terminologías estudiadas sin embargo no permitían solucionar:

Interoperabilidad a través de estándar: Al utilizar una codificación estándar (concretamente, SNOMED-CT por ser la más utilizada a nivel global) se permite que la aplicación pueda ser interoperable e intercambiar datos con otras aplicaciones si fuera necesario en un futuro.

Mapeo entre terminologías: Se realiza un mapeo entre las principales terminologías existentes con el objetivo de que, en caso de que se quiera obtener información adicional existente en otra terminología, esta pueda ser consultada a través del mapeo que se realizará entre la terminología principal (SNOMED-CT) y el resto de terminologías tomadas en cuenta.

Acceso multiterminología: El hecho de, como se ha comentado en el punto anterior, se realice un mapeo entre la codificación de SNOMED-CT y otras codificaciones como ICD, MeSH, GALEN, permite además que la interoperabilidad mencionada en el punto anterior se expanda a más sistemas que por ejemplo no soporte SNOMED-CT pero sí que soporten alguna de las otras terminologías mapeadas.

Estos problemas permiten que la propuesta de ontología basada en la terminología SNOMED-CT disponga de un gran potencial, tanto dentro del dominio establecido (diagnóstico diferencial en medicina), como fuera, al permitir acceder a otras terminologías u ontologías que contengan información adicional sobre los términos que la ontología implementada almacene.

El diseño final de la ontología se plantea de forma completa en la siguiente subsección (Redefinición de la ontología).

4.5.2. REDEFINICIÓN DE LA ONTOLOGÍA

El planteamiento de utilizar terminologías estándar en la ontología del dominio desarrollado hace necesario que además se pretenda realizar una redefinición de la ontología descrita en la sección 4.4 con el objetivo de mejorar el entendimiento de la misma, así como su semántica e interoperabilidad.

Este planteamiento se basa en dos fases: Por un lado, generación de diversas ontologías aplicadas a dominios muy concretos, pero todos ellos dependientes del dominio que la tesis plantea (diagnóstico diferencial), y por otra parte, establecimiento de nuevas propiedades y relaciones, así como el rango y dominio de estas relaciones para que se siga cumpliendo el objetivo principal de la ontología planteada, de forma que continúe siendo útil para efectuar razonamiento sobre ella, tanto en formato de Jena Rules como con Descripciones Lógicas (DL).

A continuación se exponen estas dos fases por separado. En primer lugar, la reestructuración que se pretende hacer para que la ontología sea modular y se pueda dividir en varios subdominios, y a continuación, la definición de las propiedades y relaciones que atañen a cada ontología así como su rol dentro de la ontología general.

4.5.3. REESTRUCTURACIÓN DE LA ONTOLOGÍA EN SUB DOMINIOS

La reestructuración de la ontología utilizada definida en la sección 4.4 plantea varias tareas que se deben realizar de forma ordenada para conseguir el objetivo final de obtener una serie de sub ontologías, que sean, independientes entre sí, pero que dentro de la

100

ontología general que serán utilizadas jueguen un rol en el que puedan compartir información y relacionar sus términos entre sí.

La primera tarea que se debe realizar es tratar de analizar los elementos de las distintas terminologías u ontologías estandarizadas que se han tenido en cuenta anteriormente con el objetivo de identificar aquellos términos o elementos significativos para el dominio actual.

Teniendo en cuenta como referencia principal, tanto para usar sus códigos de cara a interoperabilidad como para seguir algunas de sus características principales como su jerarquía, se consulta el documento donde se definen las jerarquías de SNOMED-CT (IHTSDO, 2010) con el objetivo de identificar los principales elementos existentes en dicha terminología.

Dentro de esta jerarquía, se hace especial énfasis en la sección "Clinical Finding" (Indicios Clínicos), donde se indica lo siguiente:

"Los conceptos en esta jerarquía representan el resultado de una observación clínica, valoración o juicio, e incluye tanto estados clínicos normales como anormales."

Algunos ejemplos que cita como indicios son los siguientes:

Clear sputum (finding) Normal breath sounds (finding) Poor posture (finding)

La jerarquía de "Clinical finding" contiene la sub jerarquía de Disease (Enfermedad). Los conceptos que son descendientes de Disease o Disorder (Desorden) son siempre, necesariamente, estados clínicos anormales. Los subtipos de jerarquía multi axial permiten a las enfermedades ser subtipos de otros desordenes así como subtipos de indicios. Ejemplos de conceptos enfermedad:

Tuberculosis (disorder) Non-Hodking's lymphoma (disorder)

Esto, permite indicar la naturaleza principal y el papel que juega el elemento “Clinical findings”. Los indicios clínicos son por lo tanto aquellos elementos, dentro del dominio presentado en la tesis, que nos permitirán arrojar un diagnóstico determinado basándose en la presencia o ausencia de ciertos indicios. Por lo tanto, estos elementos principales que siempre toman parte directa en el proceso de diagnóstico son los siguientes:

Signos/Síntomas Pruebas diagnósticas Enfermedades

Como es bien sabido y ha sido explicado previamente, los síntomas y los signos son reducidos a términos equivalentes dentro del dominio actual. Sin embargo, a partir de ahora, para dar más veracidad al término y a las futuras relaciones que tienen que ver con el término, se considerará que el sistema maneja “signos”, al ser esto la percepción objetiva que tendrá el médico cuando realice un diagnóstico, y por lo tanto, podrá o tratará de convertir lo que antes eran síntomas, al ser percepciones subjetivas del paciente, a signos, mediante la percepción objetiva del experto, si es posible esta conversión. En caso de no serlo, nuevamente, por simplificación, se indica que los síntomas también estarán contemplados al ser parte del proceso de diagnóstico.

101

Las pruebas diagnósticas son indicios clínicos que también toman parte en el proceso de diagnóstico diferencial, pudiendo principalmente confirmar o rechazar un determinado diagnóstico a través de los resultados que este obtenga. Es por eso que nuevamente se consideran un tipo de indicio clínico y por lo tanto estará representado dentro de esta categoría.

Tras el análisis proporcionado por el contenido de la sub jerarquía de indicios clínicos propuesta por SNOMED-CT se puede observar que tres de los cuatro conceptos principales que se han ido exponiendo a lo largo de la presente tesis en diferentes secciones han sido identificados y catalogados como parte del conjunto de indicios clínicos.

El elemento restante son los fármacos o medicinas. Este elemento, se podría corresponder con dos elementos de la jerarquía de SNOMED-CT:

Substance (Sustancia): La jerarquía de sustancias contiene conceptos que pueden ser usados para registrar los principios activos en los proyectos donde se trata con medicinas, comida y alérgenos químicos, reacciones adversas, toxicidad o información sobre envenenamiento, y sistemas de pedidos para enfermeros y médicos. Los conceptos de esta jerarquía representan sustancias "generales" y principios activos de la jerarquía Pharmaceutical/biologic product (Productos farmacéuticos o biológicos) que están separados de esta jerarquía. Sin embargo, las sub jerarquías de Sustancia también incluyen, pero no está limitada a: Body substance (sustancias del cuerpo) (Conceptos para representar sustancias del cuerpo); Dietary substance (Sustancias dietarias) o Diagnostic substance (Sustancias de diagnóstico). Algunos ejemplos de conceptos representados en esta jerarquía son:

Insulin (Insulina) Methane (Metano) Chromatim (Cromatina) Dental porcelain material (Material dental de porcelana) Albumin (Albumina) Endorphin (Endorfinas) Acetaminophen (Acetaminofén - Paracetamol)

Pharmaceutical/biologic product (Productos farmacológicos o biológicos): La jerarquía Pharmaceutical/biologic product está separada de la jerarquía de sustancias (Substance) como se ha explicado anteriormente. Esta jerarquía fue introducida como una jerarquía de alto nivel para distinguir de forma clara los productos farmacológicos de sus principios activos (Substances).

Esta jerarquía contiene conceptos que representan los múltiples niveles de granularidad requeridos para soportar una variedad de casos de uso como el uso de sistemas computarizados de cuidado de pacientes, prescripciones de medicamentos electrónicas (e-prescribing) u otros. Los niveles de los productos farmacéuticos representados en la release internacional de SNOMED-CT incluyen Virtual Medicine Product (VMP), Virtual Therapeutic Moiety (VTM) y Product Category.

El análisis de estas dos jerarquías plantea la problemática de qué tipo de jerarquía utilizar dentro del dominio. Por un lado, se plantearía la opción de introducir directamente la jerarquía de sustancias, pero esto plantearía la problemática cuando un fármaco se compusiera de varios principios activos, no sabiendo en realidad cual puede haber provocado una determinada reacción o efecto secundario. Sin embargo, el hecho de introducir directamente productos farmacológicos o biológicos permite establecer directamente cual es el producto que puede estar afectando al organismo del paciente.

102

Debido a eso, se toma como modelo de referencia la jerarquía de productos farmacéuticos de SNOMED-CT como base de representación para el dominio de los fármacos que será utilizado dentro de la ontología final del dominio de diagnóstico.

A continuación, la Figura 22 muestra como sería el diagrama de la nueva ontología a generar, basándose en las distinciones realizadas anteriormente, generando por lo tanto un total de seis ontologías que serán explicadas a continuación. Las relaciones serán explicadas en la sección correspondiente.

Figura 22. Representación de la ontología

En la representación actual se pueden observar seis ontologías diferentes que representan los seis dominios que se pueden representar dentro del esquema de la presente tesis.

La ontología DDx Ont representa a la ontología general que engloba dentro de sí al resto de ontologías que han sido representadas. El nombre DDx Ont hace referencia a Ontología de diagnóstico (DDx es el acrónimo de diagnóstico). Esta ontología se compone por lo tanto de cinco sub ontologías, representando una estructura modular, permitiendo que las sub ontologías utilizadas puedan representar una entidad por sí misma y puedan ser utilizadas con propósitos distintos al que se presenta en la actual tesis, permitiendo además la posible futura interoperabilidad tanto del sistema actual (representado por la base de conocimiento que constituirá la ontología DDx Ont), como del resto de ontologías utilizadas, al hacer uso todas ellas de una codificación estándar y común.

La jerarquía a utilizar se basa en la jerarquía principal utilizada en SNOMED. A pesar de que SNOMED es poli jerárquica, la visualización de la terminología de SNOMED a través de varios navegadores refleja una jerarquía principal. Esta jerarquía es la que es usada a la hora de representar los datos en las ontologías.

A continuación se describen el resto de sub ontologías que formarán parte de la ontología DDx Ont.

103

4.5.3.1. ONTOLOGÍA INDICIOS CLÍNICOS (CFO)

La ontología Clinical Findings (CFO) es una ontología envoltorio de tres ontologías que, nuevamente, por si mismas, representan una entidad concreta. El objetivo de esta ontología es crear un envoltorio que permita hacer referencia a lo que dentro del dominio actual se consideran los tres principales elementos envueltos en el proceso de diagnóstico diferencial de una enfermedad. Elementos, que por sí solos son definidos como indicios clínicos tal como se establece en las jerarquías presentadas por SNOMED-CT (IHTSDO, 2010).

Esta ontología establece una serie de relaciones y propiedades que serán detalladas más adelante. La Figura 23 muestra una representación de la ontología resultante:

Figura 23. Representación ontología CFO

Las sub ontologías que se presentan dentro de esta ontología envoltorio son las siguientes.

Ontología de Signos (SO)

La ontología de signos pretende almacenar todas aquellas manifestaciones objetivables consecuentes a una enfermedad o alteración de la salud. Además de contener este tipo de manifestaciones objetivables, también hace referencia a aquellas manifestaciones subjetivas, que bien pueden convertirse en manifestaciones objetivas a través del análisis realizado por el médico sobre el paciente (por ejemplo: fiebre una vez medida y contrastada que es fiebre), o seguir siendo manifestaciones subjetivas del paciente: síntomas (dolor, mareos, etc...).

El diseño seguido en esta ontología concreta está basado en la ontología de síntomas mencionada anteriormente, dado que, a pesar de ser descartada para su uso directo por las razones comentadas anteriormente, su estructura y parte de las relaciones introducidas dentro de la misma son útiles de cara a la representación del conocimiento del dominio a modelar.

Concretamente, la estructura que se seguirá se basa en generar una clase raíz llamada SO (Signs Ontology) sobre la cual se podrán establecer directamente las relaciones que sean convenientes. La creación de esta clase principal (por debajo de owl:Thing) radica en que a la hora de realizar las importaciones necesarias en la ontología de indicios clínicos (Clinical Findings), todas las clases serán importadas a la raíz de esta tal y como aparezcan en la ontología de síntomas. Para favorecer la interpretación de la ontología desde un punto de vista de edición de la misma, se pretende que exista una relación jerárquica que sea sencilla de interpretar de cada a su visualización o modificación mediante algún tipo de software de edición de ontologías.

Además de esta clase, las subclases dependientes de esta siguen una jerarquía determinada basándose en codificaciones estándar, haciendo referencia el nombre de la

104

clase al tipo de signos que estarán dentro de esta o al tipo de sub tipos. La definición final de un signo determinado viene dado por una instancia cuyo nombre, así como su etiqueta identificativa, vendrá dado por el código SNOMED del mismo.

La Figura 24 muestra una representación de esta ontología:

Figura 24. Representación ontología SO

Ontología de pruebas complementarias (DTO)

La ontología de pruebas complementarias (DTO – Diagnostic Test Ontology) almacenará todas aquellas pruebas clínicas que se puedan realizar para confirmar o rechazar un determinado diagnóstico o para ayudar en el proceso de identificarlo.

El diseño seguido en esta ontología concreta, al igual que en la ontología de signos, se ha basado en generar una estructura con una clase raíz llamada DTO, sobre la cual se establecieron directamente las relaciones necesarias. La creación de esta clase principal, al igual que en la ontología de signos, tiene como objetivo el establecer una jerarquía que permita la visualización y modificación de la misma sin dificultades con editores de ontologías, teniendo una estructura ordenada y fácil de visualizar.

Nuevamente, las subclases dependientes de esta siguen una jerarquía determinada basándose en codificaciones estándar, haciendo referencia el nombre de la clase al tipo de pruebas de laboratorio que pertenece. La instancia es el último escalón en la jerarquía, representando una prueba concreta.

105

En este caso, nuevamente se identificaran los elementos mediante el código SNOMED de cada prueba. Las pruebas se obtendrán a partir de la jerarquía Procedures de SNOMED.

La Figura 25 muestra una representación de esta ontología.

Figura 25. Representación ontología DTO

Ontología de enfermedades (DO)

La ontología de enfermedades almacenará las enfermedades que se tendrán en cuenta en la base de conocimiento para diagnóstico de las mismas.

Al igual que en las otras dos ontologías pertenecientes a la ontología de indicios clínicos, el diseño seguido en la construcción de esta ontología se ha basado en la generación de una estructura con una clase raíz llamada DO (Disease Ontology), sobre la cual se establecieron directamente las relaciones necesarias. La creación de esta clase principal, al igual que en las otras dos ontologías mencionadas, tiene como objetivo el establecer una jerarquía que permita la visualización y modificación de la misma sin dificultades con editores de ontologías, teniendo una estructura ordenada y fácil de visualizar.

De nuevo, las subclases dependientes de esta siguen una jerarquía determinada basándose en codificaciones estándar, haciendo referencia el nombre de la clase al tipo de enfermedades que representa. La instancia es el último escalón en la jerarquía, representando a una enfermedad concreta.


106

Figura 26. Representación ontología DO

4.5.3.2. ONTOLOGÍA MEDICINAS (DRO)

La ontología de medicamentos (DRO – Drugs Ontology) es una ontología cuyo objetivo es el de almacenar la totalidad de fármacos que pueden ser ingeridos como resultado de un tratamiento de una determinada enfermedad o signo. Estos elementos son utilizados por el sistema con el objetivo de obtener otras combinaciones de diagnóstico partiendo de la base de que un determinado fármaco pudo generar una serie de signos o síntomas como parte del efecto secundario del mismo.

Al igual que en las otras ontologías pertenecientes a la ontología de indicios clínicos, el diseño seguido en la construcción de esta ontología se ha basado en la generación de una estructura con una clase raíz llamada DRO (Drugs Ontology), sobre la cual se establecieron directamente las relaciones necesarias. La creación de esta clase principal, al igual que en las otras dos ontologías mencionadas, tiene como objetivo el establecer una jerarquía que permita la visualización y modificación de la misma sin dificultades con editores de ontologías, teniendo una estructura ordenada y fácil de visualizar.

Esta ontología, como se ha descrito anteriormente al mencionar las jerarquías de SNOMED-CT que hacen referencia a sustancias y productos farmacéuticos se basará en la inclusión de estos últimos (productos) en vez de las sustancias (o principios activos) que las componen.


107

Figura 27. Representación ontología DRONT

4.5.4. RELACIONES DE LAS ON TOLOGÍAS DE CADA SUBDOMINIO

En la sección anterior se han descrito las ontologías que forman parte del sistema que se plantea. Como se puede observar el diseño es modular, dividiéndose la ontología principal en varias sub ontologías, representando cada una de ellas un módulo que puede ser usado de forma independiente en futuros proyectos.

Aparte de la jerarquía utilizada así como las clases que se describen en la misma y la interoperabilidad ofrecida dentro de esta se deben describir las relaciones que afectarán a los elementos de la ontología, para ofrecer las futuras capacidades tanto de razonamiento como de búsqueda de las que se pretende dotar a la ontología principal.

El diseño de la ontología general, así como de las diversas ontologías modulares carece de ningún tipo de propiedades de datos. El motivo de la omisión de este tipo de propiedades se basa en que para el dominio específico que se ha modelado la ontología no es necesario ningún tipo de datos de forma directa. La manera en la que se procederá a obtener datos como nombres, enlaces, o referencias a otras ontologías mediante URI se basará a través de consultar una base de datos auxiliar donde estos datos estarán contenidos, generando así una disminución del tamaño de la ontología y mejorando el proceso de carga e inferencia de datos al tener que mantener en memoria menos datos.

Las relaciones existentes en la ontología tienen como objetivo establecer las relaciones básicas entre los distintos elementos contenidos en la ontología. Estas relaciones han sido creadas siguiendo la convención de nombres establecida por la OBO-Foundry (Smith et al., 2005).

En primer lugar, se muestra la Tabla 8 con los prefijos utilizados para hacer referencia a las diversas ontologías que forman parte de la ontología de diagnóstico diferencial. Estos prefijos permiten reconocer entonces a que ontología se está haciendo referencia en un determinado momento y a que clase dentro de esta.

Ontología Prefijo Diagnosis Ontology ddxont Clinical Findings Ontology clinicalfindings Diseases Ontology disont Signs Ontology signs Diagnostic Test Ontology dto Drugs Ontology dro

Tabla 8. Prefijos ontología

A continuación se muestra una tabla donde vienen indicadas todas las relaciones establecidas, y su dominio y rango.

108

Relación Dominio Rango has_sign disont:DO

ddxont:QUERY signs:SO

has_disorder disont:DO ddxont:QUERY

disont:DO

is_patognomic signs:SO dto:DTO

disont:DO

has_diagnostic_test disont:DO ddxont:QUERY

dto:DTO

can_occurr_with signs:SO dront:DRO Tabla 9. Relaciones de la ontología

Las relaciones indicadas en la Tabla 9 son las mínimas y necesarias para el diseño correcto del dominio modelado.

Como información adicional, se muestra en la Tabla 10 la expresividad de las diferentes ontologías así como el número de clases e instancias que contiene:

Ontología Relaciones Clases Instancias Expresividad DDxOnt (Diagnosis

Ontology) 5 1 0

Clinical Findings Ont 0 0 0

DisOnt (Diseases Ontology)

0 277 90

DTOnt (Diagnostic Test Ontology)

0 84 27

SignsOnt (Signs Ontology)

0 356 127

Drugs Ont (Drugs Ontology)

0 19 4

Tabla 10. Expresividad de las ontologías

Se debe mencionar que existe una clase adicional que puede observarse en la tabla que no ha sido mencionada previamente. La clase QUERY, perteneciente al dominio representado por la ontología de diagnóstico diferencial (ddxont) es una clase que sirve para generar instancias de consultas. La idea es que, cuando se crea una consulta que se envía al sistema, esta consulta tiene formato de instancia (Individual), y esta instancia debe pertenecer a una determinada clase. La clase más alejada de la estructura del dominio modelado sería owl:Thing, pero esta clase no está afectada por las relaciones, ya que las relaciones deben aplicarse única y exclusivamente a aquellas clases en las que la relación toma parte.

Las relaciones hacen referencia a la definición de relaciones que se pueden generar entre las instancias, no a las propias relaciones existentes finalmente entre instancias.

La solución por tanto pasaba por dos opciones:

1. Generación de las instancias dentro de las propias clases que representan a los elementos usados (básicamente, las enfermedades (disont:DO)).

2. Creación de una clase auxiliar que permita el almacenamiento temporal (durante el proceso de creación de consulta y razonamiento) de las instancias que contienen las consultas de diagnóstico que se van a realizar sobre el sistema.

109

La primera solución se podría descartar casi de forma automática por el mismo motivo que ha sido expuesto en párrafos anteriores. El hecho de permitir generar consultas dentro de una de las subclases que contienen datos de la base de conocimiento representaría una violación en el diseño expuesto, donde se define que dentro de dichas clases solo deben estar los elementos adecuados, siendo las instancias de las consultas elementos no adecuados.

Debido a esto se decide la generación de la clase auxiliar QUERY, la cual permite que a sus instancias se les pueda aplicar las propiedades citadas en la tabla (has_sign y has_disorder), que son las propiedades básicas necesarias para poder llevar a cabo el proceso de inferencia.

Nota: Como se verá más adelante en realidad la única relación requerida al 100% sería has_sign, ya que la propiedad has_disorder, procederá a la descomposición de los términos en los que apunta en varios “has_sign”. Sin embargo, semánticamente esta relación debe existir, ya que además, en un futuro se podría modificar el sistema de reglas para permitir esta relación sin descomposición alguna.

A continuación se realiza un detalle de las relaciones establecidas:

has_sign: La relación has_sign se encarga de relacionar las entidades enfermedad (representadas en la clase disont:DO) con las entidades signo (representadas en la clase signs:SO). Como previamente se ha establecido, proponemos que la representación básica de la entidad enfermedad consista en su formación de varios elementos adicionales, entre ellos, los signos o síntomas. De esta manera se establece que el dominio al que afecta la relación sea la clase que contiene las enfermedades y el rango la clase que contiene los signos. Adicionalmente se ha incluido la clase ddxont:QUERY como parte del dominio de aplicación, para que al generar una consulta se pueda hacer referencia a esta clase.

has_disorder: La relación has_disorder se encarga de relacionar las entidades enfermedad consigo mismas. El objetivo es permitir modelar el hecho de que una determinada enfermedad puede tener una enfermedad actuando como síntoma.

is_patognomic: La relación is_patognomic permite establecer la relación entre un signo o prueba de diagnóstico y una enfermedad, produciendo por lo tanto una situación en la que el diagnóstico de la enfermedad devolvería una probabilidad de 100% de acierto, dado que las entradas consideradas patognómicas (bien sean signos o pruebas de diagnóstico con un determinado resultado), son pruebas que pueden confirmar plenamente un determinado diagnóstico. Debido a esto se realiza la relación descrita.

has_diagnostic_test: La relación has_diagnostic_test permite establecer una relación entre las entidades que representan a las pruebas diagnósticas y las enfermedades. Estas relaciones permiten implicar los resultados de una determinada prueba diagnóstica (ya que, generalmente, lo ideal es establecer la relación entre una enfermedad y un resultado concreto de la prueba, no la prueba en si misma) para permitir realizar un determinado diagnóstico.

can_occurr_with: La relación can_occurr_with permite establecer una relación entre las entidades que representan a los signos y los fármacos. Esto permite establecer si un fármaco está provocando algún tipo de efecto secundario y actuar consecuentemente en el futuro para generar nuevas opciones de diagnóstico.

110

4.5.5. BASE DE DATOS CONTENEDORA DE CÓDIGOS DE OTRAS TERMINOLOGÍAS

La base de datos contenedora de códigos de otras terminologías pretende poder almacenar aquellos códigos pertenecientes a otras terminologías que puedan ser ampliamente usadas, así como, si es posible, sus URI, con el objetivo de permitir una mayor interoperabilidad entre los elementos de las ontologías definidas en la presente tesis y otras ontologías.

La base de datos definida consta fundamentalmente de las columnas que se indican en la Tabla 11. Una posible ampliación podría generarse para permitir almacenar otros datos como nombres alternativos de una entidad o enlaces.

Columna Descripción Tipo Otros snomed_id Código SNOMED VARCHAR Primary Key

type Terminología VARCHAR code Código Terminología VARCHAR - snomed_uri URI a SNOMED (OWL) VARCHAR - term_uri URI a Terminología VARCHAR -

Tabla 11. Diseño de la base de datos

A continuación se detalla la explicación de cada columna:

snomed_id: Representa junto con la columna type la clave primaria de la base de datos. Esta columna contiene el código SNOMED de la entidad sobre la cual se quieren obtener los datos.

type: Indica la terminología concreta sobre la cual se está consultando la información (por ejemplo: IDO, MeSH, GALEN, ICD, etc.).

code: Indica el código del elemento consultado en la terminología asociada.

snomed_uri: Indica la URI del elemento en la terminología SNOMED en OWL (si estuviera disponible).

term_uri: Indica la URI del elemento en la terminología a la que hace referencia en OWL (si está disponible).

El diseño de esta base de datos permite la interoperabilidad de este sistema con otros posibles futuros sistemas así como la extracción de futuros datos adicionales.

4.5.6. PROCESO DE POBLACIÓN DE LA ONTOLOGÍA

El proceso de población de la ontología consta de dos partes: Búsqueda y extracción del conocimiento médico y Población de la ontología. A continuación se describen ambos procesos.

4.5.6.1. BÚSQUEDA Y EXTRACCIÓN DEL CONOCIMIENTO MÉDICO

La búsqueda y extracción del conocimiento médico es uno de los procesos más delicados e importantes en la generación de sistemas como el expuesto en la presente tesis. Existen diversas formas de obtener la información médica asociada a la base de conocimiento que se pretende generar, siendo la más común para este tipo de sistemas el adquirir la información mediante la captura de conocimiento de un experto concreto, dando el matiz de convertir al sistema generado por lo tanto en un sistema experto.

111

Además de las consideraciones sobre el tipo de sistema final según el modelado de la base de conocimiento realizado se deben tener en cuenta otros aspectos a la hora de desarrollar un sistema de estas características. Fundamentalmente existen dos tipos de enfoques a la hora de obtener la información que formará la base de conocimiento de estos sistemas: automáticamente o manual.

El enfoque automático de extracción de conocimiento clínico es uno de los campos de investigación más extendidos. Existen trabajos basados en la extracción de conocimiento automática a través de las citas de MEDLINE (Mendonça & Cimino, 2000), técnicas probabilísticas sobre CBR (Park et al., 2006), uso de técnicas NLP sobre terminologías médicas como Open GALEN (Amaral et al., 2000) o UMLS (Zeng & Cimino, 1998) u otras clasificaciones (Baud et al., 1998).

Este tipo de enfoques permiten la extracción de conocimiento a partir de terminologías, literatura u otras fuentes de datos estructurados, ofreciendo la posibilidad de generar la base de conocimiento de una forma automática. Sin embargo, esta automaticidad plantea un problema debido a que la generación de este conocimiento no puede plantear un 100% de exactitud sobre los términos catalogados. Este tipo de exactitud es básico a la hora de generar la base de conocimiento de estos sistemas dado que son sistemas en su mayoría críticos.

En la presente tesis se ha optado por un método de extracción del conocimiento manual, que permita examinar los textos y obtener aquellos datos que se consideren relevantes para la población de la base de conocimiento actual. El hecho de usar un procedimiento manual se debe a que para la experimentación que permitirá verificar la tesis es suficiente con una población limitada, no existiendo la necesidad de generar una base de conocimiento completa. Debido a esto el proceso de población y generación del conocimiento manual es más preciso y exacto.

Las fuentes de información usadas para obtener el conocimiento relativo a las enfermedades y sus relaciones con otras entidades (signos/síntomas y pruebas diagnósticas) han sido principalmente dos:

Libro "Harrison: Principios de medicina interna. 17ª edición" (Harrison, 2009)

Medline Plus (NHL, 2010)

El proceso de extracción del conocimiento de estas fuentes se ha basado principalmente en la búsqueda de las entidades enfermedad en estas fuentes (principalmente se ha consultado el libro Harrison y cuando la información de este resultaba no lo suficientemente detallada o demasiado extensa se recurría a Medline) y obtener la información asociada a esta enfermedad.

A partir de la obtención de esta información, se procede a realizar un análisis de la misma con el objetivo de resaltar aquella relevante como por ejemplo los signos/síntomas que se mencionen que están asociados a la enfermedad o las pruebas de diagnóstico y sus resultados para confirmar el diagnóstico.

Los siguientes párrafos ilustran esta tarea de extracción del conocimiento. Se muestra un párrafo extraído del libro Harrison sobre la enfermedad Pielonefritis.

Por lo general, los síntomas de pielonefritis aguda se desarrollan con rapidez, en unas horas o un día, y comprenden fiebre, escalofríos, náusea, vómito y diarrea. A veces se detectan síntomas de cistitis. Además de fiebre, taquicardia y dolorimiento muscular generalizado, la exploración física revela dolor notable a la presión en una o ambas

112

fosas lumbares o a la palpación abdominal profunda. La gravedad de la enfermedad es muy variable.

Algunas personas tienen la forma leve o benigna, en tanto que en otras predominan los signos y los síntomas de sepsis por gramnegativos. Casi todos los enfermos sufren leucocitosis notable y presentan bacterias que se detectan en la orina sin centrifugar teñida con técnica de Gram. La orina de algunos pacientes contiene cilindros leucocíticos, cuya detección es patognomónica. A veces se demuestra hematuria durante la fase aguda de la enfermedad; si persiste cuando remiten las manifestaciones agudas de la infección, se considerará la posibilidad de litiasis, un tumor o tuberculosis.

Como se puede observar, estos párrafos indican los elementos asociados a la enfermedad citada. Se pueden observar diversos síntomas/signos como la fiebre, escalofríos, náusea, etc. Así mismo en el segundo párrafo se pueden observar otros datos interesantes relacionados con las pruebas diagnósticas como el contenido de cilindros leucocíticos en la orina, donde su detección es patognómica.

Una vez se analizan los textos asociados a las enfermedades de la base de conocimiento el siguiente proceso se basa en realizar una lista con los indicios encontrados y encontrar su elemento asociado en la terminología SNOMED.

Tras conseguir estos datos, se forma una lista donde se representan tanto las enfermedades como sus indicios asociados (síntomas/signos y pruebas de diagnóstico) para proceder a la población de la ontología.

Debe tenerse en cuenta sin embargo que no siempre es posible encontrar los datos que se precisan en la terminología SNOMED. Un ejemplo claro de esta situación es precisamente el caso anterior.

En el texto podemos leer que una de las pruebas diagnósticas es la presencia de cilindros leucocíticos en la orina. Sin embargo, esta prueba no aparece clasificada en SNOMED. Esto genera un problema bastante importante, más aún si cabe teniendo en cuenta que es una prueba patognómica, que permite asegurar al 100% que la enfermedad sufrida es la Pielonefritis.

Otro ejemplo por ejemplo es el relacionado con las pruebas de la meningitis, que tampoco vienen establecidas dentro de SNOMED.

Además de este tipo de problemas donde el hecho de que un término no aparezca a veces se pueden encontrar otros como una incorrecta clasificación de términos. En la Figura 28 podemos observar una serie de indicios relacionados con la función renal.

Figura 28. SNOMED: Indicios relacionados con función renal

Podemos observar como los elementos “Increased renal clearance” e “Increased renin secretion” son subclases de “Increased renal function”. Sin embargo, en la parte superior de

113

la imagen, sus antónimos (Decreased renal clearance y Decreased renin secretion) son directamente elementos que no están dentro de ninguna clase cuando deberían estar en una super clase llamada “Decreased renal function”.

Este tipo de situaciones plantean un problema a la hora de generar las bases de conocimiento ya que si la propia terminología contiene incoherencias esto se traduce directamente a la posibilidad de generar bases de conocimiento que hereden estos problemas.

4.5.6.2. POBLACIÓN DE LA ONTOLOGÍA

Una vez que la ontología ha sido diseñada y los datos médicos han sido recopilados es necesario proceder a su población. Aparte de definir las clases principales y relaciones es necesaria la creación de todas las subclases, con su jerarquía, y todas las instancias y relaciones.

Clases

El aspecto menos importante de esta población es el de la generación de las clases debido en este caso al tipo de modelaje hecho, donde no se establecen restricciones de ningún tipo a nivel de clase. Las clases no dejan de ser una representación abstracta de alto nivel de la entidad a la que están representando. Esto quiere decir que una clase realmente nunca va a actuar como la entidad a la que representa, si no que esto, lo hará la instancia, que es el elemento en sí. Esto permite que exista una cierta relajación a la hora de poblar la ontología con estos elementos, con las clases, no siendo su diseño el aspecto clave.

Sin embargo, a pesar de esto, en la población de la ontología se ha tratado de generar una jerarquía de clases adecuada a los elementos que contenga, con el objetivo de facilitar su edición en el futuro principalmente.

Este proceso de generación de clases es un proceso que podría realizarse de forma automática, pero que su implementación para realizar esta generación automática sería una tarea más que ardua. La dificultad de implementación de este tipo de software se basa fundamentalmente en las fuentes de información de las que sacar los códigos de SNOMED. Como se ha descrito anteriormente, las clases, que representan a entidades concretas (por ejemplo, enfermedades concretas) tienen como nombre de clase el código SNOMED de la entidad a la que están representando. Por lo tanto, suponiendo que queremos generar la base de conocimiento para unas determinadas enfermedades (supongamos, 30 enfermedades), con 150 signos/síntomas asociados, 25 pruebas diagnósticas y 30 fármacos, necesitamos una fuente de información de la que podamos sacar, sabiendo el código de cada uno de esos elementos, las superclases que están por encima de ellos, para poder establecer la jerarquía.

En el caso de que quisiéramos generar una “base de conocimiento completa”, donde estuvieran presentes todas las enfermedades, signos/síntomas, pruebas diagnósticas y fármacos, el problema se reduciría en el sentido de que ya no necesitamos códigos de elementos concretos, ya que ahora procederíamos a obtener “todos” los elementos de un determinado tipo.

Sea como sea, el problema principal sigue siendo el mismo: ¿Existe una fuente de información pública, a la que podamos consultar y pedir “superclase de un elemento” o “elementos de una categoría” y por lo tanto generar un software que permita mediante APIs de manejo de ontologías como Jena pueda ir generando las clases? La respuesta más directa es: NO.

114

Actualmente existen diversos navegadores o browsers que permiten recorrer o consultar datos de SNOMED (Rogers & Bodenreider, 2009). El problema, es que estos navegadores suelen ser o navegadores Web (que puede que internamente consulten a un Servicio Web que si permita hacer lo que buscamos, pero que no sabemos cómo lo hacen realmente), o software que se encargan de generar un modelo en memoria de toda la terminología de SNOMED-CT a partir de cargarla de sus ficheros fuente.

Una opción, podría ser generar un sistema como el de SNOB (Eggbird, 2010) y generar una mini API que permita extraer el conocimiento de SNOMED de acuerdo a como lo necesitemos, aunque esta tarea podría representar una tesis casi por misma.

Debido por lo tanto a estas limitaciones se decide proceder a la generación de los elementos de forma manual. La generación manual implica fundamentalmente que, una vez se han obtenido los datos médicos, identificar las entidades existentes en dichos datos médicos y obtener su codificación SNOMED. Una vez se tiene esta codificación, se procede a la creación de las clases siguiendo la estructura jerárquica que deben seguir.

Nota: La estructura jerárquica de SNOMED se basa en poli-jerarquías. Esto implica que un determinado elemento puede pertenecer a varias categorías o clases. Sin embargo, por simplificación, en el diseño de la ontología actual se ha optado por obtener una de las categorías (la que los browsers de SNOMED nos han proporcionado) como superclase de una determinada entidad.

La primera parte del proceso como se ha comentado es obtener la codificación SNOMED de un concepto. Para ello, se ha usado el browser SNOB. Supongamos que tenemos el elemento síntoma “Tos” y queremos obtener su código SNOMED para poder generar luego en la ontología dicho elemento. El proceso más sencillo es buscar la traducción del español al inglés de “Tos” (Cough) y buscarlo en SNOB. La búsqueda en SNOB devolvería los siguientes resultados:

Figura 29. Búsqueda con SNOB (I)

Dado que en este caso sabemos que estamos buscando un Clinical Finding (es un síntoma/signo), expandimos la categoría hasta encontrar el término requerido:

115

Figura 30. Búsqueda con SNOB (II)

Una vez tenemos el término, procedemos a anotar los datos necesarios (principalmente el código SNOMED (49727002), así como el FSN (Fully Specified Name): Cough (finding)).

Para la búsqueda de la jerarquía en la que se encontraría el término utilizamos otro tipo de browser online: SNOMED Browser (NPEX, 2010).

El hecho de usar este browser en vez de SNOB es que este browser facilita el encontrar la categoría o superclase a la que pertenece un elemento, mientras que en SNOB esta tarea es relativamente difícil.

Supongamos el mismo ejemplo anterior: Tos. Queremos generar la jerarquía de clases correspondiente hasta llegar al nivel más alto para clasificar la Tos. Para ello usaremos el buscador Snomed Browser:

Figura 31. SNOMED Browser

Este buscador nos permite buscar según el tipo de concepto, lo cual simplifica las búsquedas. En nuestro caso sabemos que estamos buscando un Clinical Finding, así que

116

podemos buscar el término seleccionando “Clinical Finding” e introduciendo el nombre (Cough) o bien directamente introduciendo el código SNOMED.

Una primera búsqueda en el navegador Snomed Browser nos devuelve el siguiente resultado para el elemento Tos (Cough) a partir del ID de SNOMED:

Figura 32. Búsqueda en SNOMED Browser

Como se puede observar, directamente la búsqueda devuelve el concepto, sus subclases y la superclase más directa (Functional finding of respiratory tract (finding)). A partir de esta súper clase, podemos ir subiendo en la jerarquía hasta llegar a la clase principal (Clinical Findings) y por lo tanto ir formando la estructura completa de las entidades del sistema.

Como se ha comentado y viendo la situación actual para completar la ontología, la población manual de la misma es una tarea ardua, dado que para la generación de las clases es necesario repetir este proceso de forma manual para todas las entidades. En el hipotético caso de que tengamos una base de conocimiento relativamente pequeña, este proceso es plausible de forma manual (como ha sido el caso actual). Sin embargo, en el caso de que la base de conocimiento creciera demasiado, el realizar manualmente este proceso probablemente traería como consecuencia que existirían errores a la hora de poblarla.

Instancias y relaciones

El siguiente aspecto a la hora de poblar la ontología una vez se han definido las clases son las instancias que representan a las propias entidades y que permitirán el establecimiento de relaciones entre individuos.

Para esto por lo tanto se vuelve a plantear una solución software que permita la población automática del sistema. Sin embargo, debe especificarse claramente en que consiste la población, para diferenciar que tareas se realizan de forma manual y que tareas se realizan de forma automática. Por lo tanto, se establecen como tareas automáticas del proceso de población, las siguientes:

Generación de todas las instancias existentes en el sistema (cada una perteneciente a su clase/ontología).

Establecimiento de las relaciones existentes entre las instancias de la ontología, dando lugar al conocimiento deseado.

117

Como se puede observar, este proceso excluye la generación de las clases que contienen información acerca de las diversas entidades existentes y que ya ha sido abordado en la sección anterior.

Generación de instancias:

La generación de las instancias es un proceso relativamente sencillo. En el sistema desarrollado actualmente, lo que se ha realizado, es generar una serie de ficheros que contendrían la información (códigos SNOMED) de las instancias a generar. Por ejemplo, supongamos que queremos generar todas las instancias de todos los signos de la base de conocimiento (en nuestro caso actual, unos 150). Este proceso, de forma manual sería bastante tedioso, pues habría que crear 150 instancias y establecer el nombre que les corresponde.

El sistema generado para hacerlo de forma automática se basa en un fichero de texto plano cuyo contenido son simplemente los códigos de las instancias. El contenido de este fichero seguiría el siguiente formato:

3723001

127086001

82272006

44808001

14760008

Snippet 10. Formato fichero de generación de instancias

El sistema se encarga de leer cada línea y generar en la clase (y ontología) que corresponda una instancia cuyo nombre será el código que ha leído más el prefijo “I”. Dado el ejemplo anterior generaría las siguientes instancias: I3723001, I127086001, I82272006, I44808001, I14760008.

Este proceso se repetiría con todos aquellos ficheros que contengan instancias de los diversos tipos de entidades existentes. De esta forma el proceso de instancias se puede realizar en apenas unos segundos.

Establecimiento de relaciones:

El establecimiento de relaciones es un proceso ligeramente más complejo pero que sigue la misma dinámica que la generación de las instancias. Este proceso, que es ejecutado una vez las instancias han sido generadas, también se apoya en la lectura de ficheros de texto. El flujo de ejecución de este proceso es el siguiente:

1. En primer lugar se deben generar una serie de ficheros de texto que contengan los códigos de los elementos que toman parte en este proceso. Por cada enfermedad que queramos establecer las relaciones (supongamos la enfermedad X con el código 123) generaremos dos ficheros de texto:

a. El primer fichero contendrá los códigos de los signos/síntomas asociados a dicha enfermedad X. El formato del fichero será un fichero de texto plano como el expuesto para generar las instancias. El único formato a seguir es que el nombre del fichero debe ser <Código>_SAS.txt. El acrónimo SAS hace referencia a Signs And Symptoms. En nuestro caso, el fichero de la enfermedad X sería 123_SAS.txt.

b. El segundo fichero contendrá los códigos de las pruebas de diagnóstico asociadas a la enfermedad X. El formato será el mismo que el descrito anteriormente, y en este caso el nombre será <Código>_DT.txt. El

118

acrónimo DT hace referencia a Diagnostic Tests. En nuestro caso, el fichero de la enfermedad X sería 123_DT.txt. 2. En segundo lugar, el sistema obtiene todas las instancias que la

ontología de las enfermedades (disont) contiene. El objetivo es establecer las relaciones entre enfermedades y otras entidades (signos/pruebas diagnósticas), por lo tanto, obtiene las enfermedades en primer lugar.

3. Por cada instancia, sabemos el nombre de la instancia (I<Código>). De dicha instancia nos quedamos solamente con el código y cargamos los códigos síntomas y pruebas de diagnóstico en unas listas a través de la lectura de los ficheros mencionados anteriormente. En este proceso de lectura además se aprovecha para obtener el objeto de “instancia” de la ontología correspondiente a los códigos leídos (tras introducir el prefijo “I”). De esta forma ya tenemos la instancia de la enfermedad y las instancias de sus elementos asociados.

4. Una vez tenemos estos elementos, procedemos en primer lugar a establecer la relación has_diagnostic_test entre la enfermedad y los elementos contenidos en la lista que ha cargado los test de diagnóstico.

5. El siguiente paso es establecer la relación entre enfermedad y signos/síntomas. Este proceso no es tan automático como el del paso anterior ya que existen signos que en realidad pueden ser de tipo enfermedad y por lo tanto la relación que se debe asociar no es “has_sign” sino “has_disorder”, y dado que el fichero SAS solo contenía códigos y no especificaba de que tipo es cada uno, debe buscarse manualmente. Lo que se hace entonces es recorrer la lista SAS y comprobar si el elemento que se haya obtenido en cada momento, su instancia, pertenece a la ontología de enfermedades o a la de signos. Si pertenece a la de signos, se establece la relación “has_sign”. Si pertenece a la de enfermedades, se establece la relación “has_disorder”.

Una vez este proceso ha finalizado la ontología ya es completa, pues contiene todas las clases que representan a sus elementos, sus instancias que permiten guardar las relaciones entre elementos y estas relaciones.

El hecho de utilizar un sistema automático que permita esta generación reduce drásticamente el tiempo de población asociado ya que tanto el proceso de generación de instancias como el de establecimiento de relaciones es un proceso lento y tedioso en el que es fácil que ocurran fallos. Sin embargo, con este proceso de población automático los únicos fallos pueden ser del sistema (fácilmente salvables a priori) o a la hora de codificar los ficheros de las relaciones (que es solucionable volviendo a ejecutar el sistema sobre la ontología vacía original).

4.6. CONCLUSIONES

La representación del conocimiento es uno de los principales problemas que deben

ser satisfechos en la presente tesis para poder realizar una verificación de las hipótesis descritas anteriormente y que se ha conseguido mediante la definición de esta nueva ontología (Rodríguez-González et al., 2011b).

Una correcta representación de este conocimiento permite la generación de bases de conocimiento (en este caso, ontologías), donde se pueden definir de forma adecuada tanto los términos médicos del dominio, como las relaciones entre dichos términos.

Así mismo, el uso de terminologías estandarizadas como SNOMED, permite, como se ha descrito, una creación de un entorno interoperable. Este entorno está respaldado con la creación de una base de datos que permita almacenar precisamente los códigos o URIs que

119

hagan referencia a los términos en otras terminologías, proporcionando ontologías más ligeras al no tener que almacenar códigos que a priori no tienen por qué ser necesarios.

Debe puntualizarse que tanto la ontología descrita en la sección 4.4 (versión inicial), como la versión final, descrita en la 4.5 son ontologías que no alcanzan el nivel máximo de completitud. En este caso, la completitud hace referencia al máximo conocimiento que se podría describir para dotar a la ontología, y por lo tanto a su conocimiento implícito, de la máxima expresividad representacional. Este aspecto es fácilmente discernible al analizar detalladamente las ontologías, donde no existen restricciones o axiomas para definir plenamente el conocimiento. Este factor viene dado fundamentalmente por dos hechos: En primer lugar, no es necesario el establecimiento de restricciones o axiomas que definan aún más el conocimiento, ya que con el modelado actual se consiguen los objetivos planteados. En segundo lugar, el hecho de diseñar un sistema de alta sensibilidad exige que ciertas restricciones no puedan ser planteadas con el objetivo de no interferir en ese objetivo. No obstante, esta ausencia de restricciones solo se plantea en los modelos ontológicos donde el sistema va a funcionar a través de un motor de inferencia con reglas, ya que el modelo basado en Descripciones Lógicas, si posee algunas estas restricciones y axiomas.

Para finalizar, cabe destacar que la población de la base de conocimiento se desarrolla de forma manual, tal y como se ha comentado, para evitar posibles problemas mediante el uso de técnicas automáticas ya que estas técnicas no pueden garantizar que el conocimiento adquirido sea correcto.

120

5. ODDIN La primera de las hipótesis planteadas en la presente tesis, H1, propone que el uso

de las técnicas pertenecientes a la rama de la Inteligencia Artificial como son los Sistemas Basados en Reglas y las Descripciones Lógicas de las Tecnologías Semánticas, permiten, la creación de sistemas de diagnóstico diferencial en medicina que proporcionen resultados precisos de forma eficiente.

Así mismo, dentro de esta hipótesis se definen dos subhipótesis relativas a la eficiencia y la exactitud del sistema que sea capaz de verificar H1. En estas, se definen cuáles son los términos medibles que se utilizarán para alcanzar a verificar estas medidas de exactitud y eficiencia dentro del sistema que pueda verificar la hipótesis ya planteada.

De esta forma, en este capítulo, se muestra el desarrollo de un sistema, el cual, haciendo uso precisamente de las técnicas pertenecientes a la citada rama de la Inteligencia Artificial, permite obtener como resultado un elemento software que es capaz de proporcionar resultados que permitan la verificación de la hipótesis H1 y las subhipótesis H1.1 y H1.2.

ODDIN (García-Crespo et al., 2010) es por tanto el sistema que se ha generado para la verificación de las hipótesis. El objetivo de esta herramienta es proporcionar al usuario de un sistema experto el cual permita generar un diagnóstico clínico a partir de una serie de indicios, basándose su funcionamiento interno en tecnologías de Inteligencia Artificial, y concretamente, en las tecnologías citadas en la hipótesis H1. Los diagnóstico producidos por el sistema no pueden ser un factor de decisión directa (la decisión que propone el sistema debe ser valorada por el experto o profesional que use el sistema), si no que el objetivo de la herramienta es guiar al médico con una serie de posibles opciones a la hora de realizar un diagnóstico final, con lo que la decisión clínica debe ser supervisada por un experto. La herramienta ha sido desarrollada como un sistema de soporte médico, el cual sugiere un conjunto de diagnósticos al usuario.

El objetivo de la aplicación proporcionada por ODDIN es construir un conjunto de componentes los cuales realizarían el proceso de diagnóstico como un grupo de módulos o motores, los cuales, una vez integrados permitieran mediante su combinación inferir nuevo conocimiento y realizar el diagnóstico. La Figura 33 muestra la arquitectura del sistema ODDIN.

121

Figura 33. Arquitectura general de ODDIN

La parte izquierda del diagrama muestra la interfaz, la cual permite acceder al sistema. Detrás de la interfaz, se pueden observar los diferentes motores o sistemas que ODDIN usa para el correcto funcionamiento de la aplicación. Cada componente se explica en detalle en las siguientes subsecciones de este capítulo.

5.1. SUBSISTEMA PROBABILÍSTICO

El componente probabilístico es el módulo encargado de manejar y calcular las probabilidades de cada diagnóstico inferido. Cada enfermedad que es diagnosticada (una o varias) a partir de un grupo de indicios tiene su propia probabilidad de ser el diagnóstico cierto o no. Esta probabilidad, y un desglose detallado de la misma (probabilidades individuales asignadas a los indicios, los cuales resultan en un diagnóstico), se calculan a través de este sistema.

El funcionamiento interno del motor probabilístico se basa en el teorema de Bayes (Smets, 1987) con ciertas modificaciones con el objetivo de adaptarlo a los requisitos computacionales del sistema. La adaptación de este teorema fue realizada basándose en las indicaciones del artículo de Martin & Del Castillo (2004). Para realizar el análisis probabilístico, se necesita establecer un peso para cada variable de diagnóstico. Este peso indica la importancia de cada variable en el diagnóstico final. En el caso actual, se han considerado las siguientes variables:

Síntomas/Signos Pruebas de Laboratorio Sexo Edad Países visitados Transfusiones Operaciones.

122

En este caso las medicinas no se introducen como variables, dado que la interacción de medicinas es procesada de forma diferente dentro del sistema. Todas las variables deben tener un peso entre 0 y 1, y de forma análoga al modelo proporcionado por el teorema de Bayes y otros modelos probabilísticos, la suma total de los pesos debe ser 1. A continuación se muestra un ejemplo del funcionamiento del motor probabilístico, donde se asumen los siguientes pesos:

Síntomas: 0.3–30%

Pruebas de laboratorio: 0.5–50%

Sexo: 0.035–3.5%

Edad: 0.035–3.5%

Países visitados: 0.1–10%

Transfusiones: 0.015–1.5%

Operaciones: 0.015–1.5%

Snippet 11. Esquema de asignación de pesos en el sistema probabilístico

En la implementación actual del sistema, estos valores se guardan en un fichero de configuración el cual permite al usuario obtener los valores mediante una serie de cómputos probabilísticos sencillos. En el siguiente caso se expone un ejemplo donde se supone un caso de diagnóstico concreto y como se realizaría el cálculo de las probabilidades.

Se tienen los siguientes síntomas con los siguientes pesos asociados:

Síntoma A - Peso: Medio Síntoma B - Peso: Alto Síntoma C - Peso: Muy alto

Asumamos que con esa configuración de síntomas el sistema infiere que las posibles enfermedades son la enfermedad "X" e "Y". Se debe tener en cuenta que sistema infiere las enfermedades en función de sus síntomas, usando la ontología del sistema. Los pesos se usan para establecer las probabilidades.

Para calcular la probabilidad de la enfermedad "X" se realizan los cálculos que se detallan a continuación. Debe tenerse en cuenta que se consideran todos los síntomas que permiten inferir la enfermedad X (estos síntomas son los indicados anteriormente: A, B, C). La probabilidad de cada uno de estos síntomas para la enfermedad X tienen que ser establecidos, y se asume que cada síntoma va a ser procesado de forma separada, y por lo tanto, se tendrían que obtener los siguientes valores:

Probabilidad del "Síntoma A" con peso "Medio" en la "Enfermedad X".

Probabilidad del "Síntoma B" con peso "Alto" en la "Enfermedad X". Probabilidad del "Síntoma C" con peso "Muy alto" en la "Enfermedad

X".

La razón para realizar estos cálculos es debido a que, por ejemplo, la probabilidad de Fiebre Alta en la Gripe no es la misma que en el Cólera, por lo tanto se debe realizar una distinción entre síntomas y enfermedades. La solución proporcionada para poder implementar esta opción en el sistema se basa en la lectura de un fichero de configuración que conecta cada enfermedad con sus síntomas y pesos asociados.

Cada enfermedad se representa mediante un directorio cuyo nombre es un código que identifica a cada enfermedad concreta. Supongamos que en el ejemplo anterior, el

123

código para la enfermedad "X" es "CDX". Por lo tanto, existirá un directorio en el sistema llamado "CDX". Dentro del directorio de la enfermedad existirá un determinado número de ficheros con los síntomas y pruebas de laboratorio asociados a esta enfermedad, cada uno determinado por un código.

Continuando con el ejemplo anterior, la enfermedad "X" que fue inferida debido a la existencia de los síntomas "A", "B" y “C" tendrá los ficheros de probabilidad "CDA.prob", "CDB.prob" y "CDC.prob".

La estructura de los ficheros de probabilidad de un determinado síntoma o prueba de laboratorio para cada enfermedad contiene claves que representan los posibles valores que pueden tomar los respectivos síntomas o pruebas de laboratorio. En el caso de síntomas para una determinada enfermedad, la estructura de los datos de estos ficheros es como se expone:

VERY_LOW = 0.63

LOW = 0.25

MEDIUM = 0.32

HIGH = 0.175

VERY_HIGH = 0.115

Snippet 12. Asignación de pesos en el sistema probabilístico

Por lo tanto, si por ejemplo, este es el contenido del fichero "CDA.prob", se puede determinar que "La probabilidad de que la enfermedad 'X' tenga el síntoma 'A' con peso 'Medio' es de 0.32". En este caso, se puede observar que la suma de todas las probabilidades no tiene por qué ser 1. Esto se debe a que en este caso solo se selecciona una opción. Solo se establece la probabilidad de un síntoma concreto con un peso concreto en una enfermedad concreta. Las otras opciones no son usadas. Además, la suma de probabilidades se dividirá entre el número de síntomas, por lo tanto el máximo valor posible será 1, y este será multiplicado (como se puede ver en las siguientes líneas) por el peso que representan los síntomas, por lo tanto la máxima probabilidad posible será la máxima posible para los síntomas. En lo que respecta al resto de síntomas, se obtienen los mismos resultados. Supongamos ahora que se obtienen los siguientes resultados para la enfermedad X con los síntomas A, B y C:

Enfermedad X: o A [ Peso: Medio ]⟹ Probabilidad: 0.32 o B [ Peso: Alto ] ⟹ Probabilidad: 0.57 o C [ Peso: Muy alto ] ⟹ Probabilidad: 0.98

Si se suman las probabilidades, y se dividen entre el número de síntomas obtenemos la probabilidad parcial, antes de aplicar el peso asociado a los síntomas:

Este porcentaje es el porcentaje de los síntomas en la enfermedad, pero se debe considerar que los síntomas tienen un determinado peso con respecto al resultado final. Dado que como se comentó previamente, los síntomas representan el 30% del total, el cómputo final es el siguiente:

El resultado final de la operación es que en la enfermedad "X" los síntomas representan el 18.69% del diagnóstico final. El funcionamiento es exactamente el mismo

124

para el parámetro de las pruebas de laboratorio, pero este factor solo tiene dos pesos: Positivo y Negativo. En lo referido al procesado del parámetro de países visitados, es similar al proceso descrito anteriormente, pero con ligeras modificaciones menores. En este caso se requiere observar la probabilidad de una determinada enfermedad en un país concreto (por ejemplo: y ). Esto se debe a que la probabilidad de, por ejemplo, el Cólera, no es la misma en España que en Nigeria. Debido a esto, la probabilidad de que la enfermedad "X" exista en el país necesita ser establecida. Estas probabilidades se sumarían y el resultado se dividiría entre el número de países para finalmente ser multiplicado por el peso asociado a los países. La implementación es similar a la realizada con los síntomas. Cuando se establece una enfermedad, nuevamente a partir del código se accede al directorio correspondiente a la enfermedad. Sin embargo, en el caso actual, se accede al fichero "countries.prob", el cual tiene un formato como el siguiente:

AFG = 0.1239

ALA = 0.5534

ALB = 0.7953

ANT = 0.6508

…

Etc.

Snippet 13. Contenido del fichero de probabilidades por países

Este fichero contiene los códigos de todos los países del mundo y la probabilidad (incidencia) de que se haya contraído la enfermedad dada dentro de un país concreto.

En lo referido a otras variables como el sexo, edad, transfusiones y operaciones, solo admiten un valor de tipo booleano. La edad, por ejemplo, puede estar dentro del rango o no. En el caso de la edad se verifica si la enfermedad que el sistema ha inferido permite el rango de edad introducido por el usuario (dentro de la descripción de la enfermedad se puede indicar si es una enfermedad que se dé o suela dar en un rango de edad determinado). En el caso de que sea así, se asume una probabilidad de que la edad esté influyendo del 100% (al que luego se debe aplicar el peso correspondiente a la edad). En el caso de que la edad no esté dentro del rango, se aplicaría el valor 0, con lo que se inferiría una probabilidad del 0% para el parámetro de la edad. El mismo proceso se realiza con el resto de variables.

Existe un parámetro final dentro del sistema probabilístico que en la configuración del sistema se refleja mediante la clave "ADD_PROBABILITY_BY_DEFAULT". En el caso de que este parámetro esté activado (valor true), el sistema añade una probabilidad por defecto si un determinado parámetro no es encontrado. Si por ejemplo, el valor sexo no ha sido introducido en una consulta, o no existe un valor predefinido para el sexo (indiferente), si esta opción está activado el sistema añade la probabilidad por defecto asociada: 0.035.

5.2. SUBSISTEMA DE CARGA DE DATOS

El módulo de carga de datos es el motor que se encarga de realizar la carga de la información disponible en la ontología. Se utiliza la API de Jena, que es un framework de programación en Java de tipo Open Source para aplicaciones de la Web Semántica, para leer el fichero de la ontología en este módulo. La API de Jena soporta varios tipos de lenguajes como Resource Description Framework (RDF), Resource Description Framework Schema (RDFS), Ontology Web Language (OWL) y Query Language for RDF (SPARQL). El fichero de la ontología contiene todos los datos necesarios para realizar el diagnóstico, como las enfermedades, síntomas y medicinas. Estos datos deben ser cargados en memoria para que el usuario pueda interactuar de forma sencilla con la aplicación. El

125

desarrollo de la ontología fue desarrollado tras la consulta de varias fuentes de información médica (Ausina Ruiz & Moreno Guillén, 2006; Hoeprich et al., 1994; Kasper et al., 2004) y tras haber realizado varias entrevistas con profesionales y estudiantes de medicina.

5.3. SUBSISTEMA COMBINATORIO

La hipótesis H3, la cual define que es posible la realización de un proceso que permita calcular alternativas de diagnóstico dado el planteamiento en el que los indicios de una enfermedad (un caso clínico concreto), hayan sido inducidos por la ingesta de fármacos, y por lo tanto, esta situación pueda ser utilizada para calcular alternativas de diagnóstico.

Hay que tener muy presente que la verificación de esta hipótesis se plantea para que este conocimiento pueda ser un posible trabajo futuro, dado que la creación de sistemas que puedan ofrecer múltiples diagnósticos, o diagnósticos basados en la interacción de fármacos ante ciertas indicios en un caso de diagnóstico, implicaría una complejidad bastante más alta que la expuesta en esta tesis.

La definición de esta hipótesis está basada en las limitadas capacidades de la mayoría de los sistemas de diagnóstico existentes en la actualidad y que han sido analizados previamente en el estado del arte. De todos los sistemas analizados, solo en uno de ellos se conoce la capacidad de la realización del proceso mencionado en la hipótesis.

Se debe tener en cuenta que la verificación de esta hipótesis, aparte de ser uno de los problemas abordados en esta tesis, implica una serie de ventajas enormes para los sistemas de soporte a la decisión clínica. El hecho de que un proceso de diagnóstico pueda arrojar más resultados debido a que se tengan en cuenta a la hora de diagnosticar una patología de un paciente los fármacos consumidos y las posibles interacciones o efectos adversos de estos es de suma importancia.

Por ese motivo, dentro del sistema propuesto para verificar la hipótesis H1, se introduce el concepto de subsistema combinatorio, siendo este módulo el encargado de realizar las posibles combinaciones de signos con el objetivo de crear subconjuntos en función de la presencia o ausencia de un determinado signo, siendo el causante de esta presencia o ausencia producto de un efecto secundario de un determinado fármaco.

Para describir el funcionamiento, se ilustra el siguiente ejemplo. Supongamos que tenemos un paciente que presenta aparentemente los siguientes indicios:

Cefalea Nauseas Fiebre

A su vez, el paciente informa, que debido a un problema de hipertensión, se le ha prescrito el uso de Hidralazina para tratar esta patología. Este medicamento, la Hidralazina, tiene varios posibles efectos secundarios entre los que destacamos a modo de ejemplo los siguientes:

Deshidratación Náusea Anuria Cefalea

126

De los posibles signos/síntomas que puede producir la Hidralazina como efecto secundario, los que están marcados en negrita (Cefalea y Náusea), son aquellos que como se puede observar son comunes a los indicios que el paciente presenta y que por lo tanto, podrían estar provocados por el consumo del fármaco. La probabilidad de que estos fármacos estén provocando dichos indicios no está reflejada en este sistema, si bien en las futuras secciones se puede ver el tratamiento que tiene la probabilidad asociada a este factor. Se debe tener en cuenta que el hecho de poder ser provocado, como se refleja más adelante, no implica que necesariamente los indicios hayan sido todos provocados como efecto secundario o adverso del fármaco, si no que puede darse el caso de que ninguno, uno o más de uno hayan sean consecuencia de los efectos secundarios o adversos, o no.

Las combinaciones de diagnóstico que por lo tanto se pueden generar dados los elementos mencionados en el ejemplo anterior son las siguientes:

Cefalea, Nausea, Fiebre Hidralazina no tiene efecto Cefalea, Nausea Hidralazina provoca Fiebre Cefalea, Fiebre Hidralazina provoca Nausea Fiebre Hidralazina provoca Cefalea y Nausea

El funcionamiento interno de este módulo se basa en la realización del conjunto final de diagnósticos mediante etapas. Cada una de las etapas se encarga de ir creando subconjuntos de indicios en función de los parámetros de entrada (indicios para el diagnóstico y fármaco(s)), con el objetivo de finalmente crear el subconjunto final de posibles entradas de diagnóstico, siendo cada entrada de diagnóstico un conjunto de indicios. En primer lugar, mencionamos los conjuntos que tenemos disponibles al comienzo del algoritmo combinatorio:

SYM_DDX: Indicios que tiene la consulta del diagnóstico. SYM_MEDS: Indicios que son producto de los efectos secundarios de

los fármacos que intervienen en el diagnóstico (evitando duplicado de estos: Si dos fármacos producen Cefalea, solo aparece una vez).

Teniendo en cuenta que estos son los conjuntos iniciales que intervienen en este proceso, las etapas que se realizan son las siguientes:

1. Etapa 1: Generación de los indicios que son comunes al diagnóstico y a las medicinas: SYM_DDX SYM_MEDS

2. Etapa 2: Generación de los indicios que no son comunes. Esto se traduce como la siguiente operación en teoría de conjuntos: SYM_DDX - (SYM_DDX SYM_MEDS)

3. Etapa 3: Generación de las combinaciones de indicios comunes (los que estaban involucrados en la primera etapa).

4. Etapa 4: Adición de las combinaciones anteriores a los indicios no comunes generados en la segunda etapa, obteniendo por lo tanto el resultado final.

A continuación, se muestra una representación gráfica mediante diagramas de Venn de la situación anterior en las siguientes figuras:

127

Situación inicial:

Figura 34. Situación inicial de la interacción de medicamentos

Etapa 1:

Figura 35. Etapa 1 de la interacción de medicamentos

Etapa 2:


128

Etapa 3:


Etapa 4:


La etapa 3, donde se procede a la generación de las combinaciones de indicios comunes, se lleva a cabo utilizando el algoritmo que se detalla a continuación.

El algoritmo de generación de combinaciones se basa en el uso de números en base binaria para poder generar todas las posibles combinaciones de una serie de elementos. El número de combinaciones a generar depende del número de elementos que queramos combinar, siendo la relación entre ambas la siguiente:

En este caso, se utiliza esta fórmula debido a que las combinaciones que queremos generar representan un estado de tipo booleano (presencia o no presencia), de ahí que se utilice el sistema binario como base. También se debe tener en cuenta que el orden de los elementos no influye.

El hecho de introducir la resta de 1 en la fórmula se debe a que estamos excluyendo la combinación vacía (donde se denota la ausencia de todos los elementos). A continuación se muestra un ejemplo del funcionamiento de este sistema combinatorio usando el ejemplo anterior, pero para simplificación, se asigna a cada indicio un identificador, quedando de la siguiente manera:

C1

C2

…

CN

129

A: Deshidratación B: Náusea C: Anuria D: Cefalea

Las combinaciones posibles, por lo tanto, son:

ABCD ABC ABD ACD BCD AB AC AD BC BD CD A B C D

Siguiendo el esquema planteado, esto es fácilmente representable usando un

sistema binario. Dado que en este caso el número de elementos a generar es , deberemos generar una representación binaria de los valores del 1 al 15. Esta representación binaria, al tener que utilizar forzadamente cuatro valores binarios dado que es el mínimo exigido para poder alcanzar dicho valor en este sistema, permitirá que, si se asigna a cada “posición”, uno de los valores (A, B, C, D), dependiendo del valor que se tenga (0 o 1) se supondrá la presencia o ausencia por lo tanto del valor. A continuación se muestra la Tabla 12 donde se representa este ejemplo:

Representación Binaria

Decimal A B C D Salida Salida Real

1 0 0 0 1 D Cefalea

2 0 0 1 0 C Anuria

3 0 0 1 1 CD Anuria, Cefalea

4 0 1 0 0 B Náusea

5 0 1 0 1 BD Náusea, Cefalea

6 0 1 1 0 BC Náusea, Anuria

7 0 1 1 1 BCD Náusea, Anuria, Cefalea

8 1 0 0 0 A Deshidratación

9 1 0 0 1 AD Deshidratación, Cefalea

10 1 0 1 0 AC Deshidratación, Anuria

11 1 0 1 1 ACD Deshidratación, Anuria, Cefalea

12 1 1 0 0 AB Deshidratación, Náusea

13 1 1 0 1 ABD Deshidratación, Náusea, Cefalea

14 1 1 1 0 ABC Deshidratación, Náusea, Anuria

15 1 1 1 1 ABCD Deshidratación, Náusea, Anuria, Cefalea

Tabla 12. Tabla de ejemplo del cálculo de interacciones

130

Como se puede observar, este sistema de generación, dadas las características actuales, nos permite generar las posibles combinaciones de indicios que le propongamos al sistema, ayudando en la generación de diagnósticos alternativos.

5.4. SUBSISTEMA DE INFERENCIA

El motor de inferencia es el módulo principal que realmente permite la generación de diagnósticos. Este módulo requiere de acceso a la base de conocimiento que contienen las enfermedades, síntomas, etc. Al mismo tiempo también requiere acceso a una base de conocimiento adicional donde se guardan las reglas que permiten esta inferencia de conocimiento. Con la unión de estos elementos y la API de Jena, el sistema ODDIN realiza una inferencia sobre las bases de conocimiento, dando lugar a un diagnóstico como resultado. Debido a esto, se puede considerar que el sistema actúa como un sistema experto basado en reglas. El sistema también es capaz de adquirir nuevo conocimiento e incrementar la velocidad de razonamiento usando técnicas de razonamiento incremental (Parsia et al., 2006).

El rendimiento real de ODDIN recae como se ha mencionado previamente sobre la capacidad de razonamiento e inferencia que ofrecen las ontologías. Los elementos principales de este sistema, como se han mencionado previamente, se pueden dividir en dos elementos fundamentales:

Una ontología diseñada con el objetivo específico de almacenar información de carácter médico, y más concretamente con información sobre las relaciones existentes entre los elementos que toman parte en el diagnóstico diferencial en medicina.

Un conjunto de reglas de inferencia, las cuales permiten generar razonamiento para ser capaz de inferir el conocimiento correcto.

Concretamente, las reglas de inferencia han sido creadas usando "Jena Rules" como lenguaje de reglas. La decisión de usar Jena Rules como lenguaje para este propósito se debe fundamentalmente, a que el otro candidato posible (SWRL), a pesar de ser quizás el estándar más utilizado, plantea como problema principal su incapacidad para diseñar una regla donde se quiera establecer una negación. Esto genera un problema dado el dominio actual, donde el diseño y la creación de las reglas requieren de esta capacidad. A pesar de ello, no se descarta que se pueda realizar una conversión entre las reglas actuales en este formato a otros formatos (incluido SWRL) aunque para ello requiera que las reglas desarrolladas tengan una complejidad mayor.

La Figura 39 muestra el funcionamiento principal de los componentes que están involucrados en el sistema ODDIN y la forma en que estos trabajan para poder llegar a un diagnóstico determinado.

131

Figura 39. Arquitectura del sistema ODDIN (II)

En esta figura se puede observar el flujo que el sistema genera para la realización del diagnóstico. La consulta es enviada al sistema ODDIN, el cual interactúa con la API de Jena enviándole la consulta de diagnóstico que el usuario haya introducido. La API de Jena carga en memoria tanto el fichero de la ontología, para generar en memoria el modelo de base de conocimiento (tanto para las reglas como para la ontología), que establece las relaciones entre los datos médicos existentes, como las reglas de inferencia, que serán las que en conjunción con la ontología permite inferir el conocimiento resultante en forma de diagnóstico. Estas dos bases de conocimiento trabajan entre ellas para inferir el diagnóstico.

El razonamiento incremental que se menciona anteriormente se basa en el uso de dos características concretas del motor de reglas: en primer lugar, el primer uso que se hace del sistema, y concretamente de la base de conocimiento en cada ejecución del sistema. La mayor carga temporal del sistema se sostiene sobre la primera ejecución, pues es donde se debe generar el modelo en memoria para preparar las capacidades de inferencia del motor de reglas. El hecho de realizar una primera consulta, prepara al sistema para ser capaz de generar nuevas consultas contra las bases de conocimiento de una forma más eficiente.

El segundo punto del razonamiento incremental se basa fundamentalmente en reutilizar el conocimiento que previamente ha sido adquirido o consultado. La idea se basa en que, una vez se genere una determinada consulta, se compare con las consultas existentes en el sistema (que han sido almacenadas previamente) y en caso de existir coincidencia en los términos de comparación (comparar elementos: síntomas y pruebas de laboratorio que son las que definen la inferencia) utilizar la consulta almacenada, donde el modelo de la consulta ya ha sido generado previamente en memoria y se permite acceder más rápido a los resultados.

5.5. SUBSISTEMA DE BÚSQUEDA

El sistema ODDIN incorpora un subsistema de búsqueda basado en consultas SPARQL. El objetivo es realizar consultas SPARQL contra la ontología con el objetivo de consultar ciertos datos que han sido introducidos en la ontología para poder mostrarlos a través de la interfaz de usuario. El hecho de utilizar SPARQL como sistema de búsqueda se debe a la rapidez que el lenguaje proporciona.

132

5.6. DESCRIPCIONES LÓGICAS ASOCIADAS AL SISTEMA

El uso de descripciones lógicas (DL) para inferir razonamiento se basa en usar las descripciones adecuadas para que un determinado razonador consiga llegar a las conclusiones pretendidas.

La técnica que se pretende desarrollar en este sistema se basa en la definición de una determinada DL para cada instancia que queramos que pueda ser razonada. En este caso, dado que el objetivo es el de inferir enfermedades, cada instancia de una enfermedad tendría una serie de DLs asociadas. Más concretamente, en realidad, la DL se definirá a nivel de clase, pero en nuestro esquema se recuerda que cada instancia está asociada a una clase concreta, que es donde se definirá la citada DL.

La ontología donde se describen las relaciones a utilizar y donde estas DLs son codificadas es la descrita en la sección 4.4.

A continuación, se muestra un ejemplo de la DL para una enfermedad concreta (Disease P):

(hasSymptom some SYM_E_Class) or (hasSymptom some SYM_A_Class)

or (hasLabTest some LT_1_Class)

Snippet 14. Descripción lógica de una enfermedad

Una representación más formal, en lógica proposicional de este mismo esquema es la siguiente:

Snippet 15. Descripción en lógica proposicional de una enfermedad

En este caso, se define que la enfermedad Disease P se compone de dos síntomas (SYM_E y SYM_A) de una prueba de laboratorio (LT_1).

La DL citada se encarga de especificar que se inferirá dicha enfermedad cuando se cumpla que la propiedad hasSymptom enlaza con alguna instancia perteneciente a la clase del síntoma E (SYM_E_Class) o con alguna instancia de SYM_A_Class o de LT_1_Class (Unión de indicios).

De esta forma, se está especificando los únicos y posibles valores de Disease P. Por lo tanto, cualquier otro valor no sería considerado a efectos de razonamiento, y como consecuencia, al no cumplirse la primera premisa ya no se llegaría a la conclusión de que es la enfermedad Disease P.

Por otra parte tenemos la siguiente DL:

(hasLabTest only LT_1_Class)

Snippet 16. Descripción lógica de restricción de pruebas de laboratorio

Esta DL sirve para especificar, que, de todas las opciones disponibles, solo son posibles como pruebas de laboratorio todas las que provengan de la clase LT1, y por lo tanto, establecemos una restricción al proceso de inferencia a todas aquellas instancias que no pertenezcan a dicha clase.

133

(hasSymptom only (SYM_A_Class or SYM_E_Class))

Snippet 17. Descripción lógica de restricción de síntomas

En esta DL se especifica lo mismo que en la anterior, pero en este caso se establece la delimitación mediante síntomas. Se establece que los síntomas asociados sólo pueden pertenecer a la clase SYM_A o SYM_E, que son los dos únicos síntomas posibles.

Por lo tanto, las DL a especificar son, para n síntomas y m pruebas de laboratorio:

(hasSymptom some <Nombre clase síntoma 1>) or (hasSymptom some

<Nombre clase síntoma 2>) or ...... (hasSymptom some <Nombre

clase síntoma n> or

(hasLabTest some <Nombre clase prueba 1>) or (hasLabTest some

<Nombre clase prueba 2>) or …. (hasLabTest some <Nombre clase

prueba m>)

(hasLabTest only (<Nombre clase prueba 1> or <Nombre clase

prueba 2> or … <Nombre clase prueba m>))

(hasSymptom only (<Nombre clase síntoma 1> or <Nombre clase

síntoma 2> or … <Nombre clase síntoma n>))

Snippet 18. Esquema de las DL a especificar para una enfermedad

En el caso de que una determinada enfermedad se defina sin pruebas de laboratorio o sin síntomas, se debe reemplazar la segunda y tercera DL de las descritas anteriormente por las siguientes:

Para ausencia de síntomas:

(hasSymptom only owl:Nothing)

Snippet 19. Descripción de ausencia de síntomas

Para ausencia de pruebas de laboratorio:

(hasLabTest only owl:Nothing)

Snippet 20. Descripción de ausencia de pruebas de laboratorio

Con estas DL se deben definir todas aquellas enfermedades que queramos que se infieran dentro del esquema propuesto.

A continuación se muestra un esquema en formato OWL de cómo quedaría la clase definida tras establecer las descripciones lógicas:

<owl:Class rdf:about="#DIS_P_Class">

<rdfs:subClassOf rdf:resource="#TESTS_DIS"/>

<owl:intersectionOf rdf:parseType="Collection">

<owl:Restriction>

<owl:allValuesFrom rdf:resource="#LT_1_Class"/>

<owl:onProperty rdf:resource="#hasLabTest"/>

</owl:Restriction>

<owl:Restriction>

<owl:allValuesFrom>

<owl:Class>

134

<owl:unionOf rdf:parseType="Collection">

<rdf:Description rdf:about="#SYM_A_Class"/>

<rdf:Description rdf:about="#SYM_E_Class"/>

</owl:unionOf>

</owl:Class>

</owl:allValuesFrom>

<owl:onProperty rdf:resource="#hasSymptom"/>

</owl:Restriction>

<owl:Class>


<owl:Restriction>


<owl:someValuesFrom rdf:resource="#SYM_E_Class"/>

</owl:Restriction>

<owl:Restriction>


<owl:someValuesFrom rdf:resource="#SYM_A_Class"/>

</owl:Restriction>

<owl:Restriction>


<owl:someValuesFrom rdf:resource="#LT_1_Class"/>

</owl:Restriction>

</owl:unionOf>

</owl:Class>

</owl:intersectionOf>

</owl:Class>

Snippet 21. Definición en OWL de las DL

Sin embargo, si probáramos a realizar inferencia con este esquema, veríamos que obtendríamos resultados incorrectos.

Esto se debe a la asunción de mundo abierto (OWA: Open World Assumption) (Drummond & Shearer, 2006). En las descripciones lógicas mostradas anteriormente se está especificando que tenemos unos determinados síntomas, pero debido a que RDF/OWL hace uso de la asunción de mundo abierto, esto no implica que pueda haber otros síntomas/pruebas no mencionados en la descripción.

La solución de este problema se plantea mediante un forzado de asunción de mundo cerrado (CWA: Closed World Assumption) (Cadoli & Lenzerini, 1994), estableciendo cardinalidades a las instancias encargadas de realizar la consulta.

A la hora de realizar la consulta, debemos por lo tanto especificar el número exacto de parámetros de cada uno de los indicios, para poder hacer uso de la asunción de mundo cerrado, estableciendo que los parámetros pasados son los únicos posibles.

Por lo tanto, el formato de la instancia de una consulta, debería ser el siguiente:

135

hasSymptom <Instancia síntoma 1>

hasSymptom <Instancia síntoma 2>

…

hasSymptom <Instancia síntoma n>

hasLabTest <Instancia prueba 1>

hasLabTest <Instancia prueba 2>

…

hasLabTest <Instancia prueba m>

hasSymptom exactly n

hasLabTest exactly m

Snippet 22. Formato de instancia de consulta en DL

Con estas líneas, en las que se establece el número de síntomas/pruebas de laboratorio exactas que tiene la consulta, se establece la asunción de mundo cerrado, solucionándose así los problemas de razonamiento.

Se debe tener en cuenta, que en caso de ausencia bien sea de pruebas o de síntomas, se debe establecer de todas formas la cardinalidad a 0, para que se siga formando la asunción de mundo cerrado, y por lo tanto no existan problemas de inferencia.

A continuación podemos ver cómo quedaría el código en OWL de una determinada consulta, donde se establece que tenemos dos síntomas (A y B) y no hay pruebas de laboratorio.

<humandisease:Consult rdf:about="#TC1">

<humandisease:hasSymptom rdf:resource="#SYM_A"/>

<humandisease:hasSymptom rdf:resource="#SYM_B"/>

<rdf:type>

<owl:Restriction rdf:nodeID="b31">

<owl:cardinality

rdf:datatype="&xsd;nonNegativeInteger">2</owl:cardinality>


</owl:Restriction>

</rdf:type>

<rdf:type>

<owl:Restriction rdf:nodeID="b47">

<owl:cardinality

rdf:datatype="&xsd;nonNegativeInteger">0</owl:cardinality>


</owl:Restriction>

</rdf:type>

</humandisease:Consult>

Snippet 23. Código OWL de una consulta

5.7. DISEÑO DE LAS REGLAS

Las reglas utilizadas por el sistema ODDIN han sido generadas siguiendo el formato Jena Rules, debido a que el motor de inferencia de reglas usado ha sido el de la propia API de Jena, de ahí que se necesite utilizar un formato concreto. La principal razón de escoger este motor de inferencia, y por lo tanto su lenguaje de reglas asociado, como se ha mencionado previamente, es la capacidad que tiene este para poder hacer negación de

136

términos, algo que en otros lenguajes de reglas más populares y estandarizados dentro de la Web Semántica como es SWRL no es posible.

El hecho de usar reglas de inferencia en vez de descripciones lógicas se basa en que estas nos permiten, en este caso, dada la expresividad necesaria y restricciones necesarias para el dominio, generar las mismas condiciones lógicas que con DL, pero con una serie de ventajas respecto a estas, como es fundamentalmente la facilidad de escritura de las reglas y que puede ser realizado por un proceso automático que genere las reglas en función de las relaciones existentes en la ontología y lo escriba en un fichero de texto. En el caso de las DL, su escritura dentro de la ontología (que es donde se realiza su interpretación, es sin embargo más ardua, dificultando que un proceso automático lo haga). Además, se tiene que tener en cuenta la eficiencia del sistema, donde el uso de reglas es muy superior.

En el caso del sistema basado en reglas, al igual que con las DL, se deben establecer una serie de condiciones para cada enfermedad que queramos que sea inferida. Sin embargo, al contrario que en las descripciones lógicas, estas no tienen por qué ser establecidas dentro del fichero OWL de la ontología, si no que pueden establecerse al margen y cargarlas de forma separada por el razonador. Este punto es bastante importante, dado que permite que se apliquen estrategias de caching de forma más sencilla para mejorar la eficiencia del razonador (Rodríguez et al., 2009).

Las reglas que se deben generar para cada enfermedad del sistema dependen del número de síntomas y pruebas de laboratorio. En este caso, para una enfermedad concreta:

Dónde:

n: Representa al número de síntomas que están asociados a la enfermedad para la que vamos a generar la regla.

m: Representa al número de pruebas de laboratorio que están asociadas a la enfermedad para la que vamos a generar la regla.

t: Es un parámetro que vale 1 en caso de que la enfermedad solamente vaya a ser representada con signos/síntomas. En caso de que también se vayan a incluir pruebas de diagnóstico el valor del parámetro t pasará a ser 2, para indicar que existen dos reglas de exclusión: Una correspondiente a los signos y otra a las pruebas de diagnóstico.

El formato de las reglas es el siguiente:

@prefix ont: <URI_ONTOLOGIA#>.

@include <RDFS>.

[rule_DIS_P_NOT_REST_SYMPTOMS:

(?i ont:hasSymptom ?x) notEqual(?x, ont:SYM_A) notEqual(?x,

ont:SYM_E)

-> (?i ont:hasNegSymptom ont:DIS_DIS_P_NOT_SYM) ]

Snippet 24. Formato de definición de enfermedades con reglas

En este caso, se define una regla que establece como premisas que se defina la propiedad hasNegSymptom para aquellos síntomas que no sean los válidos, en este caso, se considera como síntomas válidos SYM_A y SYM_E, siendo el resto posible de síntomas (aquellos que están enlazados mediante la propiedad hasSymptom) no válidos. Se considera esta regla como la regla discriminante (regla discriminante de síntomas).

137

@prefix ont: <URI_ONTOLOGIA#>.

@include <RDFS>.



ont:SYM_E)


Snippet 25. Formato de definición de enfermedades con reglas. Definición de síntomas no válidos

En este caso, esta regla hace prácticamente lo mismo que la que se ha mencionado anteriormente, pero con la diferencia de que en este caso se genera un discriminante de pruebas de laboratorio, aquellas que no están definidas para la enfermedad (todas aquellas que no sean LT_1).

[rule_DIS_DIS_P_SYM_A:

(?i ont:diagnosis ont:DIS_P)

<- (?i ont:hasSymptom ont:SYM_A)

noValue(?i, ont:hasNegSymptom ont:DIS_DIS_P_NOT_SYM)

noValue(?i, ont:hasNegLabTest ont:DIS_DIS_P_NOT_LABT)]

Snippet 26. Formato de definición de enfermedades con reglas. Definición de reglas de laboratorio no válidas

La regla rule_DIS_DIS_P_SYM_A, la cual se define en formato backward, permite que se infiera la enfermedad para la que estamos diseñando las reglas (DIS_P) en el caso de que se especifique que se ha establecido como posible síntoma de la enfermedad en la consulta el síntoma SYM_A pero ninguno de los "no permitidos" (Tanto síntomas no permitidos como pruebas de laboratorio). Esto se consigue como se puede observar al introducir la primitiva noValue con las propiedades hasNegSymptom y hasNegLabTest a los recursos DIS_DIS_P_NOT_SYM y DIS_DIS_P_NOT_LAB respectivamente, que son los recursos que hacen referencias a todos aquellos síntomas y pruebas de laboratorio no válidos.

[rule_DIS_DIS_P_SYM_E:


<- (?i ont:hasSymptom ont:SYM_E)



Snippet 27. Definición de diagnóstico para un síntoma determinado (SYM_E)

La regla rule_DIS_DIS_P_SYM_E, tiene el mismo objetivo que la regla anterior, pero en este caso estableciendo como síntoma SYM_E.

[rule_DIS_DIS_P_LT_1:


<- (?i ont:hasLabTest ont:LT_1)



Snippet 28. Definición de diagnóstico para una prueba de laboratorio (LT 1)

La regla rule_DIS_DIS_P_LT_1, tiene el mismo objetivo que la regla anterior, pero en este caso estableciendo como prueba de laboratorio LT_1.

Como se puede observar, es necesario definir una regla por cada indicio asociado a la enfermedad (síntoma y prueba de laboratorio) y dos más adicionales para definir

138

aquellos síntomas y pruebas de laboratorio que no deben ser tenidos en cuenta durante el proceso de inferencia y que por lo tanto permita su exclusión.

Esta definición de exclusión se utiliza igual que cuando se codificaban las restricciones en descripciones lógicas para hacer una asunción de mundo cerrado (CWA) y que por lo tanto el proceso de inferencia sea correcto teniendo en cuenta los requisitos.

5.8. CONCLUSIONES

El sistema ODDIN, que se ha generado con el objetivo de verificar la validez de las hipótesis presentadas en esta tesis (H1, H2 y H3) arroja unos resultados bastante interesantes. En primer lugar, se puede observar como la primera de las hipótesis (H1) puede ser verificada dada la situación en la que el sistema ha podido ser generado aplicando las tecnologías mencionadas (en el capítulo de Verificación se hará más hincapié a esta verificación).

En lo referido a las subhipótesis H1.1 y H1.2, estas serán verificadas en la correspondiente sección, dado que la hipótesis H1.1, que se encarga de definir que existe una exactitud diagnóstica del sistema suficientemente alta, necesita de una evaluación muy concreta que permita asegurar, y por lo tanto, verificar que los datos que el sistema arroja son lo suficientemente correctos como para que al sistema se le pueda considerar como preciso.

Así mismo, en el caso de la subhipótesis H1.2, también es necesario realizar una serie de comprobaciones que permitan definir si efectivamente el sistema es eficiente desde un punto de vista computacional. Esta medida de eficiencia es nuevamente realizada en el capítulo de evaluación, donde se realizan una serie de mediciones que permiten asegurar que el sistema resultante final, sí que verifica la hipótesis planteada.

Así mismo, el sistema desarrollado permite también la verificación de la hipótesis H3, a través del sistema combinatorio del sistema.

Sin embargo, el sistema que se ha generado para la verificación de las hipótesis muestra que los resultados obtenidos para la hipótesis H2 no son los esperados. El diseño concreto que se ha generado tanto de las descripciones lógicas como de las reglas de inferencia asociadas al sistema no permiten la verificación de la hipótesis H2.

El hecho de no poder realizar una verificación de esta hipótesis implica que el sistema generado no tiene la suficiente capacidad expresiva dentro de su base de conocimiento y de sus elementos de inferencia como para ser capaz de realizar un razonamiento del tipo que se menciona en dicha hipótesis.

El hecho de no poder verificar por lo tanto la segunda hipótesis en el diseño propuesto actualmente implica que se necesitan generar nuevas evoluciones del sistema, en el cual se diseñen una serie de cambios que permitan por lo tanto verificar esta hipótesis sin que estos cambios afecten a la verificación de las hipótesis que ya pueden ser verificadas (H1 y H3).

Debido a esto, en el siguiente capítulo se procede a realizar una modificación parcial del sistema para que este permita verificar la segunda de las hipótesis.

Se debe mencionar de todas formas, que la verificación de todas las hipótesis será ampliamente comentada en el capítulo de verificación.

139

6. ADONIS Y SEDELO La hipótesis H2 define que el problema de diagnóstico mediante inferencia

multinivel (definido previamente en el capítulo 3 y explicado con detalle a continuación) puede ser modelado y solventado con efectividad y exactitud usando elementos asociadas a las Tecnologías Semánticas tales como las descripciones lógicas y las reglas.

Esta definición permite dotar a los sistemas de diagnóstico de un valor añadido que gran parte de los sistemas analizados en el estado del arte no son capaces de resolver. El hecho de ser capaces de razonar a distintos niveles permite devolver resultados complejos donde la patología diagnosticada está compuesta por otras patologías.

Para ser capaz por lo tanto de verificar la hipótesis H2 es necesario hacer uso del conocimiento definido previamente y establecer una serie de descripciones lógicas asociadas a este conocimiento de tal forma que sea posible el diagnóstico mediante inferencia multinivel.

En este capítulo, la solución que permitirá la verificación de la hipótesis H2 se realizó en dos partes, dando lugar a ADONIS (Rodríguez, 2009b; Rodríguez et al., 2011) y SEDELO (Rodríguez-González et al., 2011a)) con el objetivo de permitir verificar la hipótesis ya mencionada.

A continuación por lo tanto se plantea la solución definida para la verificación de la hipótesis H2 mediante los componentes descritos.

6.1. DESCRIPCIÓN DEL PROBLEMA A SOLUCIONAR

Como se ha comentado, el objetivo de ADONIS y SEDELO es tratar de verificar la hipótesis anteriormente nombrada como H2. El problema que plantea dicha hipótesis se basa en que la gran mayoría de los sistemas de diagnóstico clínico existentes en la actualidad no son capaces de realizar un diagnóstico correcto cuando se sustituye un síntoma o signo, el cual, en realidad es una enfermedad, por el conjunto de síntomas que comprenden dicha enfermedad.

En este caso, por ejemplo, aquellos sistemas que han definido el cólera como un conjunto de síntomas/signos, donde sólo se llega a conclusión de diagnóstico cuando uno de ellos es la deshidratación, en vez de la propia deshidratación o sus síntomas/signos asociados, no son capaces de llegar a inferir el cólera como enfermedad posible ante los síntomas presentados.

6.2. ADONIS

La verificación de la hipótesis H2, como se ha comentado previamente, requiere de un remodelado de varios de los aspectos de la tesis expuestos previamente en lo relativo a la base de conocimiento, y sobre todo, al diseño de las reglas asociadas de tal forma que mediante el motor de razonamiento usado se pueda realizar el diagnóstico mediante inferencia multinivel.

Para ello, partiendo de la base de conocimiento descrita previamente y de los resultados obtenidos anteriormente, es necesario redefinir parte de este conocimiento para permitir que la hipótesis H2 sea verificada.

Por lo tanto, se genera una evolución de ODDIN, que en este caso se llamará ADONIS (Automated Diagnosis System Based on Sound and Precise Logical Descriptions) y que

140

permitirá plantear una posible verificación de la hipótesis H2 a través de las nuevas definiciones que plantean en la base de conocimiento y en los componentes relacionados.

ADONIS (Rodríguez-González et al., 2009; Rodríguez-González et al., 2011) desarrolló las descripciones lógicas, partiendo de las definidas en ODDIN, de tal forma que solventaba parte del problema. El diseño usado permitía diagnosticar enfermedades que estuvieran planteadas en la forma que establecía la hipótesis H2, pero sin embargo, en el funcionamiento normal (suponiendo que se estableciera un diagnóstico donde uno de los síntomas/signos fuera la propia enfermedad) el sistema no es capaz de inferir correctamente.

Además, por otra parte, se proporciona una solución meramente algorítmica para el problema.

6.2.1. SOLUCIÓN BASADA EN LÓGICA DESCRIPTIVA

La solución basada en lógica descriptiva es en realidad relativamente sencilla. Esta se basa en la definición de nuevas clases en las cuales se introducen como miembros de dicha clase los indicios asociados a la enfermedad que va a actuar en este caso como indicio de otra patología. En el ejemplo que viene reflejado en la Figura 13 y Figura 14, la enfermedad X, que se compone de los indicios C, D y E es la que actúa como indicio de la enfermedad Y. Por lo tanto, nosotros definiríamos una nueva clase llamada “SymptomsX” de la siguiente forma:

SymptomsX = oneOf { SymC, SymD, SymE }

Snippet 29. Definición del conjunto de síntomas de la enfermedad X

De esta forma, definimos un elemento de tipo oneOf (enumeración) que contiene una lista de objetos (instancias). En este caso, las instancias concretas que contiene son las representaciones de los síntomas C, D y E.

El siguiente paso, sería declarar la clase HasDiagnosisX, que representaría si sería posible definir el diagnóstico de la enfermedad X de la siguiente forma:

Snippet 30. Definición del elemento HasDiagnosisX

De esta forma, se define la forma de inferir el diagnóstico para la enfermedad Disease X definiendo que se infiera si se produce que tiene los indicios contenidos en el conjunto SymptomsX y definiendo que el número de indicios es 3 para asegurarse CWA.

Por lo tanto, el conjunto de indicios de la enfermedad Y, se podría definir de la siguiente forma:

SymptomsY = oneOf { SymA, SymB } SymptomsX

Snippet 31. Definición de los elementos de SymptomsY

En este caso, se define el conjunto de indicios de la enfermedad Y como los característicos de la propia enfermedad (A y B) y los asociados a la enfermedad X a través del conjunto SymptomsX.

La clase correspondiente al diagnóstico de la enfermedad Y, se definiría de la siguiente forma:

141

Snippet 32. Definición del elemento HasDiagnosisY

En este caso, la definición es la misma que para la enfermedad X, pero asociando como conjunto de diagnóstico el generado en Y, que contiene a sus propios elementos más los del conjunto de diagnóstico de la enfermedad X. También establece el cierre mediante la asignación de cardinalidad a 5.

A partir por lo tanto de esta definición, se podría inferir con este conocimiento, que un paciente con el siguiente conjunto de indicios:

{ SymA, SymB, SymC, SymD and SymE }

Snippet 33. Consulta para la nueva base de conocimiento

Sería diagnosticado con la enfermedad Disease Y, que es el objetivo que se perseguía con la definición de estos conceptos.

La notación del conjunto de indicios de la enfermedad Y (SymptomsY) en formato OWL sería la siguiente:

<owl:Class rdf:about="#SymptomsY">

<owl:equivalentClass>

<owl:Class>


<rdf:Description rdf:about="#SymptomsX"/>

<owl:Class>

<owl:oneOf rdf:parseType="Collection">

<rdf:Description rdf:about="#symB"/>

<rdf:Description rdf:about="#symA"/>

</owl:oneOf>

</owl:Class>

</owl:unionOf>

</owl:Class>

</owl:equivalentClass>

</owl:Class>

Snippet 34. Declaración de SymptomsY mediante OWL

6.2.2. SOLUCIÓN ALGORÍTMICA

Existe una posible alternativa para el diagnóstico con inferencia multinivel que se basa en la generación de un determinado algoritmo que permitiría realizar este diagnóstico.

La idea de esta solución algorítmica se basa en tratar de obtener a partir de los indicios de entrada, las posibles enfermedades que puedan ser formadas con dichos indicios, y utilizar esas enfermedades para hacer nuevas inferencias. El proceso se entiende de forma sencilla utilizando un ejemplo. Consideremos nuevamente las enfermedades representadas en las Figura 13 y Figura 14. Supongamos que tenemos el conjunto de síntomas expuesto en el Snippet 33 para realizar el diagnóstico (SymA, SymB, SymC, SymD y SymE).

142

El objetivo de la solución algorítmica es generar todas las posibles combinaciones de los indicios de entrada que puedan inferir una sola enfermedad (es decir, el resultado de la inferencia sería un diagnóstico en vez de un diagnóstico diferencial). Por lo tanto, los posibles conjuntos para realizar inferencia, serían:

Con dos indicios:

{SymA, SymB},{SymA, SymC},{SymA, SymD},{SymA, SymE}

{SymB, SymC},{SymB, SymD},{SymB, SymE}

{SymC, SymD},{SymC, SymE}

{SymD, SymE}

Snippet 35. Posibles conjuntos de dos síntomas

Con tres indicios:

{SymA, SymB, SymC},{SymA, SymB, SymD},{SymA, SymB, SymE}

{SymB, SymC, SymD},{SymB, SymC, SymE}

{SymC, SymD, SymE}

Snippet 36. Posibles conjuntos de tres síntomas

Con cuatro indicios:

{SymA, SymB, SymC, SymD},{SymB, SymC, SymD, SymE}

Snippet 37. Posibles conjuntos de cuatro síntomas

Nota: El conjunto de 5 indicios no es generado debido a que es el conjunto entero, y se necesita inferir con subconjuntos del conjunto original.

Aquellos subconjuntos que devuelven un solo resultado como parte del proceso de diagnóstico son candidatos para ser reusados en el diagnóstico final. En este caso, el único conjunto que devuelve un diagnóstico, y único, sería el que tiene los indicios { SymC, SymD, SymE }, que devuelve como diagnóstico la enfermedad Disease X (DisX). Por lo tanto, el algoritmo, se encargaría de borrar dichos síntomas (SymC, SymD, SymE) del conjunto original de indicios y sustituirlos por la enfermedad inferida (DisX). Por lo tanto, el conjunto final que sería enviado finalmente al sistema para realizar un diagnóstico sería el siguiente:

{SymA, SymB, DisX}

Snippet 38. Conjunto final tras aplicar el algoritmo

El problema de esta solución algorítmica es que, en la teoría su funcionamiento sería sencillo de implementar y aplicable, pero en la práctica sería muy difícil, debido a que, a no ser que los subconjuntos fueran muy grandes, la mayoría de los subconjuntos que tuvieran pocos elementos siempre devolverían como resultado del diagnóstico varios elementos.

6.2.3. CONCLUSIONES

La solución planteada en ADONIS permite que se pueda proceder a verificar la hipótesis H2, dado que la definición de las descripciones lógicas asociadas a las entidades involucradas permite el diagnóstico en los casos que precisamente esta hipótesis definía.

Sin embargo, las descripciones lógicas que han sido diseñadas, aunque permiten verificar H2, hacen que H1 deje de ser verificable. Esto se debe al diseño proporcionado, donde las descripciones lógicas implementadas hacen que en caso de que se quiera inferir una enfermedad a través de introducir otra entidad enfermedad en un caso clínico el

143

diagnóstico no pueda ser llevado a cabo. Esto se traduce en que, efectivamente hemos conseguido que si metemos los indicios de una enfermedad concreta, el sistema es capaz de “detectarla” y usarla como si fuera un indicio de entrada para obtener otra patología que pueda tener relación con la mencionada. Sin embargo, el haber conseguido esto ha deteriorado las descripciones lógicas de tal manera que si queremos obtener el efecto deseado en un principio, y que la hipótesis H1 verificaba con ODDIN, ahora no es verificable. En caso de meter directamente la enfermedad (y no sus indicios asociados), es incapaz de llegar a un diagnóstico concreto.

Por otro lado, la solución algorítmica, es una solución parcial e inviable. Es parcial porque solamente sirve como prueba de concepto que desde un punto de vista algorítmico podría llevarse a cabo. Sin embargo, es inviable debido a que las complejidades computacionales asociadas a esta solución serían muy altas en caso de ser implantado en un sistema de uso real, donde el número de indicios puede ser tan alto que los tiempos asociados a computar las opciones de diagnóstico serían demasiado altos, dando lugar a varios problemas de rendimiento.

Debido a esto, en el siguiente subcapítulo se trata de presentar una nueva solución, basada en lógica descriptiva, que siga manteniendo la verificación de la hipótesis H2, pero sin que esto suponga que la hipótesis H1 deje de ser verificable.

6.3. SEDELO

Tras los resultados obtenidos en ADONIS, surgió la necesidad de generar una nueva evolución de lo planteado previamente para que la verificación de la hipótesis H2 no implicara que la hipótesis H1 dejara de ser verificable.

SEDELO (Rodríguez-González et al., 2011b), por lo tanto, es una mera evolución de ADONIS. En este caso se plantea reconstruir las descripciones lógicas que se habían presentado en ADONIS con el fin de dar solución a la hipótesis H2 sin perder ningún tipo de eficiencia, dado que la solución que se planteó en ADONIS, aunque solventaba el problema que permitía verificar la hipótesis H2, introducía como problema que la hipótesis H1 dejaba de ser verificable.

Los diagramas y ejemplos que se han establecido en ADONIS son exactamente los mismos que los establecidos en SEDELO.

El problema de la solución presentada en ADONIS es que no puede resolver un caso compuesto como el siguiente. Supongamos que sabemos que un paciente tiene la enfermedad Disease X y los síntomas SymA y SymB. El sistema, por lo tanto, debería descartar Disease X e inferir Disease Y.

En la lógica monótona (Reiter et al., 1993; Brewka, 1991; Horty, 2001), la relación de consecuencia lógica es monotónica, es decir, que al agregar una fórmula a una teoría nunca se produce una reducción de su conjunto de consecuencias. Dado que las descripciones lógicas empleadas por OWL siguen este tipo de lógica, no es posible descartar implicaciones hasta que hayan sido inferidas. De esta forma, es necesario separar las implicaciones de las cuales los indicios pertenecen a una determinada enfermedad de las implicaciones a través de las cuales una enfermedad puede ser diagnosticada para un determinado paciente. En general, para una determinada enfermedad D, definimos la clase HasSymptomsD la cual acumula todos los indicios que pueden ser asociados con dicha enfermedad.

Sin embargo, una vez que sabemos que un determinado paciente tiene todos los indicios de la enfermedad D, aún no podemos diagnosticar dicha enfermedad D, debido a

144

que el paciente aún podría tener otros indicios relacionados con otra enfermedad (E), la cual debería ser inferida en vez de inferir D. Es necesario ayudar al razonador declarando que el paciente tiene todos los indicios de D y solo esos indicios. Una solución simple es contar el número de indicios que un paciente tiene y comparar dicho número con el número de indicios de la enfermedad concreta. Este proceso, se puede generar de forma automática y es la solución actual que el sistema usa. En el caso del ejemplo que estamos utilizando, debemos declarar una clase llamada HasSymptomsX de la siguiente forma:

Snippet 39. Definición de la clase HasSymptomsX

La definición previa utiliza restricciones de cardinalidad cualificada (qualified cardinality) (Rector & Schreiber, 2005), las cuales fueron introducidas en OWL2 (Motik et al., 2009) y permite establecer que el conjunto HasSymptomsX es equivalente a aquellos elementos los cuales tienen tres indicios del conjunto SymptomsX. Teniendo en cuenta que la cardinalidad seleccionada es 3, un miembro de HasSymptomsX tendrá todos los indicios de Disease X. En el caso de un paciente con los indicios A y B, y los indicios de Disease X, la consulta sería:

hasSymptom symA ^

hasSymptom symB ^

rdf:type HasSymptomsX ^

hasSymptoms = 5 ^

hasLabTest = 0

Snippet 40. Ejemplo de consulta en SEDELO

En este caso, se puede observar que la solución pasa por establecer en la consulta de entrada que uno de los parámetros de entrada es el conjunto que envuelve a los indicios de la enfermedad X. Esto es fácilmente solventable de forma algorítmica, dado que cuando se introducen los indicios totales en el sistema, este se encargaría de calcular si los posibles subconjuntos que se podrían generar, estarían asociados a una determinada enfermedad (HasSymptomsX al fin y al cabo representaría a una determinado enfermedad), y si es así, sustituiría los indicios por el conjunto de la enfermedad.

Se debe tener en cuenta que también es necesario declarar el número total de indicios del paciente (en este caso, 5), para poder restringir el número de indicios posibles del paciente y para establecer ante el razonador la inferencia de la enfermedad correcta. Este cálculo sería realizado automáticamente por el sistema cuando sustituya los indicios por la enfermedad. Existe un enfoque más eficiente basado en producto de conceptos (Rudolph et al., 2008), el cual no requiere contar el número de indicios de cada enfermedad. Mediante el uso de sintaxis de descripciones lógicas, podríamos afirmar:

Snippet 41. Definición mediante producto de conceptos

La solución basada en reglas, tal como se definía inicialmente el sistema en ODDIN es mostrada en el capítulo 7.

6.4. CONCLUSIONES

Las definiciones proporcionadas en el capítulo actual permiten generar una solución para la hipótesis H2. En el caso de ADONIS, la solución planteada es parcial, dado que las descripciones lógicas diseñadas permiten por una parte plantear una solución al problema definido en la hipótesis, pero sin embargo, dicha solución tiene como efecto colateral que

145

un proceso de diagnóstico donde se introdujera la patología en vez de sus signos asociados no sería funcional, haciendo que la hipótesis H1 dejara de ser verificable.

La alternativa proporcionada por SEDELO, que es una mera evolución de ADONIS sí que plantea una solución válida para la resolución de la hipótesis H2. Esta solución, basada íntegramente en definiciones de elementos lógicos permite que el proceso de diagnóstico pueda ser llevado a cabo tanto si se introducen como elementos de entrada patologías, como sus signos asociados.

El problema sin embargo que presentan tanto ADONIS como SEDELO es la imposibilidad de verificar al 100% la hipótesis H1.2. La verificabilidad completa de esta hipótesis se dará solo en el caso de que los tiempos de ejecución y los consumos de memoria del sistema planteado sean lo suficientemente buenos como para ser ejecutado en un entorno real. Un entorno real implica también que aunque la base de conocimiento que se está empleando en esta tesis es limitada (debido a la dificultad de poblar una base de conocimiento que comprenda todo el dominio médico tratado), se debe asegurar que la solución proporcionada pueda ser usada en un entorno donde esta base de conocimiento crezca, y por lo tanto, el número de elementos de la misma sean equivalentes a los elementos que se tendría en caso de que el sistema fuera usado en un entorno completamente real, donde todas las patologías, signos, síntomas y pruebas diagnósticas existentes formen parte de la base de conocimiento.

El diseño por lo tanto de ADONIS y SEDELO no permite verificar esta hipótesis debido a que los tiempos de inferencia en un entorno pequeño (bases de conocimiento con pocos elementos) son aceptables, pero en cuanto crece la base de conocimiento los tiempos se disparan a límites inaceptables. Debido a esto, es necesario por lo tanto una nueva evolución que permita verificar la hipótesis H1.2 tomando como punto de partida a SEDELO, el cual actualmente permite la verificación de todas las hipótesis excepto precisamente la H1.2 (la H1.1 será verificada más adelante).

En el siguiente capítulo se introduce por lo tanto la última de las evoluciones, que dará lugar a la verificación total de todas las hipótesis, así como a un rediseño de varios de los componentes citados previamente.

146

7. MDDS-OPM La medicina, y concretamente la informática médica, y todas sus aplicaciones es un

campo que crece con una rapidez inmensa debido a que es un area en franca expansión. Esto implica que cada día, miles de investigadores en el mundo realizan nuevos aportes que generan que el conocimiento de esta ciencia, se modifique prácticamente a diario, dando lugar a que en muchos casos ciertas investigaciones que se podían creer punteras o pioneras pasen a estar desfasadas en cuestión de muy poco tiempo, dado que el trabajo sobre el que se están centrando los grupos de investigación no está distribuido, y por lo tanto, unos no saben que otros ya están trabajando en lo mismo, dando lugar a esta situación.

Esta situación se ha dado por ejemplo en el uso de las taxonomías o vocabularios estandarizados para medicina. Cuando esta tesis nació, aún no existían taxonomías estandarizadas que fueran un referente mundial como lo son ahora mismo. Esto no quita que estas taxonomías no existieran (que existían), ni que no fueran fuertes (que lo eran). Esto significa que el consenso sobre su uso y su “requerimiento” para usarlas no era ni mucho menos tan fuerte como lo es en la actualidad, donde, si desarrollas un sistema que necesite hacer uso de terminología médica estás “obligado” a utilizar este tipo de taxonomías si quieres que tu trabajo sea tomado tan siquiera en consideración.

Debido a esto, en este capítulo por lo tanto, se plantea una modificación de los elementos definidos previamente (ODDIN, ADONIS y SEDELO) con el objetivo de mejorar fundamentalmente tres aspectos: representación del conocimiento, mejora de los tiempos de inferencia y una propuesta de nuevo modelo probabilístico más completo.

La propuesta relativa a la representación del conocimiento puede ser consultada en la sección 4.5, donde se define la modificación de la ontología usada en los sistemas anteriores para adaptarla a las terminologías más usadas.

La mejora de los tiempos de inferencia se basa en la generación de reglas de inferencia que permitan el diagnóstico mediante inferencia multinivel tal y como ADONIS y SEDELO lo permitían mediante el uso de DLs, con el objetivo por lo tanto de poder verificar la hipótesis H1.2 al realizar una mejora en el tiempo de inferencia.

Para finalizar, el modelo probabilístico que actualmente utilizaba ODDIN es un modelo bastante simplista, sobre todo en lo referido al cálculo de las probabilidades individuales de las enfermedades (el de las pruebas diagnósticas es ligeramente más sofisticado). Por ese motivo, en este apartado se propone un nuevo sistema probabilístico basado en datos epidemiológicos para el cálculo de las probabilidades individuales asociadas a cada patología.

7.1. GENERACIÓN DE REGLAS DE INFERENCIA ADAPTADAS A LAS NUEVAS ONTOLOGÍAS

En el capítulo 6, donde se presentaba ADONIS y SEDELO, se introdujo como base de razonamiento para el sistema el concepto de las descripciones lógicas. Sin embargo, es bien conocido que el desarrollo de sistemas basados en descripciones lógicas suelen presentar problemas de escalabilidad (Rodríguez-González et al., 2011a) y que generalmente, dependiendo de la expresividad de la lógica subyacente pueden existir problemas incluso de memoria en determinadas máquinas con pocos recursos, teniendo que tratar de aplicar métodos de optimización (Horrocks et al., 2000), dependiendo de la expresividad, para conseguir mejores resultados. Otros problemas asociados a las

147

descripciones lógicas son sus dudosas capacidades de representación en el entorno médico (Ceusters et al., 2003).

Debido a esta limitación, tal y como se propuso en ODDIN, se ha procedido a la generación de reglas de inferencia en formato Jena Rules aplicando inferendia deductiva fundamentalmente que permitan por una parte seguir dando solución al problema que planteaba ODDIN, así como mantener la solución propuesta por ADONIS y SEDELO (principalmente SEDELO, siendo este el componente que daba una solución completa al problema del diagnóstico mediante inferencia multinivel), pero aplicando un entorno computacional más relajado como el que plantea el uso de un sistema basado en reglas, donde la complejidad computacional es menor que en los sistemas basados en descripciones lógicas.

Los siguientes párrafos mostrarán el desarrollo llevado a cabo para el diseño de las reglas de inferencia que permitan solucionar los problemas descritos.

En primer lugar, es necesario volver a plantear el problema existente del diagnóstico mediante inferencia multinivel, ya descrito previamente, para comprender de forma adecuada la solución que se va a plantear.

7.1.1. REDEFINICIÓN DEL PROBLEMA

El diagnóstico mediante inferencia multinivel se basa en la certeza de que existen ciertas patologías (enfermedades), donde sus indicios o conjunto de indicios pueden representar a una entidad más compleja y completa (enfermedad). En estos casos, se necesita que el sistema sea capaz de realizar el diagnóstico correcto no solo cuando se introduce esa entidad más compleja, si no, cuando se introducen parte de estos elementos que conforman la entidad.

Para solventar este problema, cuando se propuso el diseño basado en descripciones lógicas, se desarrolló la siguiente solución:

Supongamos que tenemos una enfermedad llamada E1 que está definida por los síntomas S1, S2, S3 (E1 = {S1, S2, S3}). Por otra parte, tenemos otra enfermedad E2, que está compuesta por los síntomas S4, S5 y la enfermedad E1 (E2 = {S4, S5, E1}). La enfermedad E2, podría definirse descomponiendo E1 en sus elementos base, quedando finalmente E2 como sigue:

E2 = {S4, S5, S1, S2, S3}

Los elementos marcados en negrita forman E1.

En la solución basada en descripciones lógicas, la solución pasaba por generar un conjunto que contuviera a los elementos de E1, pero que no fuera la propia entidad de E1. Esto, se diseñaba creando un “clon” de E1 llamado E ’ de tal forma que [ ] [ ].

A la hora de definir la enfermedad E2, lo que se hace es, definir a la enfermedad E2 tal y como fue definida en un principio (E2 = {S4, S5, E1}) añadiéndole la definición de que E2 también se formará como E2 = {S4, S5, E ’}.

La diferencia entre estas dos definiciones:

E2 = {S4, S5, E ’} E2 = {S4, S5, E1}

148

Es que en la segunda estamos haciendo referencia directa a E1, algo que no va a permitir al sistema inferir E2 cuando metamos los elementos de E1 (S1, S2, S3). Sin embargo, en la primera definición, E ’ realmente no es una entidad igual que E1, es una entidad donde solamente se están definiendo un conjunto de elementos, pero E ’ no conforma una “entidad enfermedad” por si sola.

De esa forma, primera definición tiene la siguiente equivalencia:

{ {

Con esta definición, el sistema podía inferir ambas enfermedades, ya que luego paralelamente seguiría existiendo la definición más antigua (E2 = {S4, S5, E1}) en la que se permitiría inferir E2 también si se introdujera directamente como síntoma la entidad E1, y no sus elementos.

7.1.2. DISEÑO DE LAS REGLAS

Partiendo por lo tanto de la base explicada en la sección anterior donde se vuelve a introducir la particularidad del problema a resolver, se puede tratar de buscar una solución basada en reglas que permita seguir dotando al sistema de la misma eficiencia a la hora de inferir resultados, pero que añada además una eficiencia computacional extra.

La idea a seguir para el diseño de estas reglas se basa en la misma desarrollada a la hora de crear las descripciones lógicas: Dado que no es posible introducir como síntoma/signo una enfermedad directamente y que el sistema automáticamente cuando recibe un conjunto de signos sepa si esos signos pueden ser asociados (diagnosticados en cierto modo) a una determinada enfermedad, se debe buscar la forma de despiezar dicha enfermedad y permitir que sus elementos sí que formen parte del proceso de diagnóstico.

Para explicar el proceso de diseño se va a exponer un caso real donde tendremos dos enfermedades, en las que una depende de la otra al actuar una de ellas como síntoma/signo de la otra.

Supongamos la primera enfermedad: Bronquitis (Código SNOMED 32398004)

La bronquitis tiene un conjunto de signos/síntomas bastante variados, entre los cuales vamos a destacar unos pocos para ilustrar el ejemplo. De esta forma, definiremos que la Bronquitis (simplificando) tiene los siguientes síntomas/signos:

Tos (Código SNOMED 49727002) Debilidad (Código SNOMED 271795006) Fiebre (Código SNOMED 386661006) Disnea (Código SNOMED 162890008) Sinusitis (Código SNOMED 36971009) Dolor de garganta (Código SNOMED 162397003)

El elemento marcado en negrita (Sinusitis) no está clasificado como signo. Es una enfermedad, y como enfermedad tiene asociados una serie de síntomas característicos de la misma, que entre otros (simplificando), son los siguientes:

Secreción Nasal (Código SNOMED 64531003) Congestión Nasal (Código SNOMED 68235000) Dolor de cabeza (Código SNOMED 25064002)

149

Si simplificamos (la simplificación/reducción de términos de cada enfermedad se realiza para poder ilustrar el ejemplo), podemos entonces definir estas enfermedades de la siguiente forma:

Bronquitis = { Tos, Debilidad, Fiebre, Disnea, Sinusitis, Dolor de garganta }

Sinusitis = { Secreción Nasal, Congestión Nasal, Dolor de cabeza }

Nuestra idea se trata de que, por ejemplo, si el paciente presenta Secreción Nasal y Congestión Nasal, el sistema debería ser capaz de diagnosticar, por una parte la Sinusitis (pues son síntomas directos de esta enfermedad) y por otra la Bronquitis (ya que a primera instancia diagnosticaría una posible Sinusitis debido a esos síntomas, pero en un segundo nivel, diagnosticaría la Bronquitis por haber diagnosticado previamente la Sinusitis).

Así mismo, cuando se introdujeran por ejemplo síntomas de la Sinusitis, y síntomas de la Bronquitis, el sistema solamente debe diagnosticar esta última, ya que debería descartar la Sinusitis, porque tiene, o más síntomas de los que son específicos de esta, u otros síntomas que a la Sinusitis no atañen.

Para conseguir este comportamiento lo que se debe hacer es por lo tanto descomponer aquella enfermedad que forma parte de la otra (en este caso la Sinusitis al formar parte de la Bronquitis) y generar unas reglas que permitan generar una entidad que haga que sea “síntoma” de la enfermedad que está a un nivel superior (en este caso, Bronquitis).

De forma similar al caso ilustrado anteriormente con las entidades E1 y E2, el objetivo es generar un E ’ que contenga los elementos de E1 pero que no sea el propio E1.

Para ello, se deben modificar las reglas que se explicaban en la sección 5.7, donde se implementaban las reglas de inferencia para el sistema ODDIN. La dinámica de las reglas es exactamente la misma que para este sistema, solo que en este caso, requiere una modificación de las reglas anteriormente creadas para que permita el nuevo tipo de inferencia que estamos desarrollando.

A continuación se irán mostrando las diversas reglas desarrolladas para el sistema ODDIN y su nueva versión para el sistema actual haciendo énfasis en los cambios necesarios para su adaptación al sistema actual.

Nota: Es importante recalcar que las instancias utilizadas en el nuevo sistema son identificadas mediante el código SNOMED del elemento al que representan, introduciendo la letra “I” delante. Por ejemplo, el Dolor de cabeza, cuyo código SNOMED es 25064002, se representará mediante la instancia I25064002.

La primera regla necesaria es aquella que se encarga de gestionar la exclusión de todos aquellos signos/síntomas que no pertenecen a la entidad a diagnosticar.

Inicialmente, en ODDIN, esta regla tenía el siguiente formato:



ont:SYM_E)


Snippet 42. Reglas iniciales de ODDIN

150

En la nueva generación de reglas, el formato sería el siguiente (esta es la regla para definir los síntomas no permitidos a la hora de definir la enfermedad Bronquitos (véase código SNOMED 32398004):

[rule_I32398004_NOT_REST_SIGNS:

(?i ont:has_sign ?x) notEqual(?x, signs:I49727002)

notEqual(?x, signs:I271795006) notEqual(?x, signs:I386661006)

notEqual(?x, ont:I36971009DISORDER) notEqual(?x,

signs:I64531003) notEqual(?x, signs:I68235000) notEqual(?x,

signs:I25064002) -> (?i ont:hasNegSign ont:I32398004_NOT_SIGNS)

]

Snippet 43. Formato Reglas MDSS-OPM

Existen múltiples diferencias que se deben recalcar:

Uso de has_sign: La primera diferencia clara es que en el sistema de ODDIN todavía se utilizaba la relación hasSymptom. En este caso, debemos adaptarlos al uso de has_sign, que es la nueva relación entre signos y enfermedades.

Uso de prefijos específicos para cada categoría: Se puede observar que en la regla actual utilizamos dos prefijos: signs y ont. En este caso, signs es el prefijo para hacer referencia a la ontología de síntomas, y ont es el prefijo para hacer referencia a la ontología principal (la ontología de diagnóstico).

Introducción de elemento discriminante nuevo: Se puede observar que existe un elemento discriminante nuevo: notEqual(?x, ont:I36971009DISORDER). Este discriminante, lo primero que llama la atención es que a diferencia del resto de elementos de la regla, hace referencia a la ontología ont en vez de a signs (notEqual(?x, signs:I271795006) notEqual(?x, signs:I386661006) …). Lo segundo es que la nomenclatura del término al que hace referencia difiere de lo habitual (coletilla DISORDER). Esto se introduce para decirle a la regla que el “signo” I36971009DISORDER es uno de los posibles signos a la hora de diagnosticar la Bronquitis, y que por lo tanto, debe ser tenido en cuenta junto con el resto que se han especificado. Todo signo no especificado en esta regla, se omite. Nótese también que el código que identifica este signo (36971009) hace referencia precisamente a la entidad Sinusitis. Más adelante se explicará cómo se crea este “signo” virtual (es virtual ya que no existe en la propia ontología, se crea en la regla).

Introducción de signos adicionales: Además del signo comentado en el punto anterior se puede observar que se introducen signos adicionales de los de la Bronquitis. Los signos de la Bronquitis son aquellos con los siguientes códigos SNOMED: 49727002, 271795006, 386661006, 162890008, 36971009, 162397003. Sin embargo, se han añadido tres más: 64531003, 68235000, 25064002. Estos tres corresponden a los signos de la Sinusitis. En resumen: Todos los signos (tanto de la propia patología como de las que dependen de él) deben estar en esta regla.

Como se puede observar, existen varias modificaciones importantes en esta regla que deben ser realizadas. En el caso de la regla de exclusión de las pruebas complementarias, el procedimiento es exactamente el mismo y por lo tanto no será explicado para evitar repetir código.

Básicamente esta es la única modificación que se debe realizar en el nuevo diseño de las reglas para que permita el nuevo funcionamiento. Sin embargo, aparte de dicha modificación, es necesario introducir una serie de reglas nuevas (el resto de reglas que ODDIN usaba, se mantienen tal y como están).

151

Estas reglas nuevas son aquellas que permiten la creación del signo virtual que va a representar a la enfermedad dependiente de la enfermedad de la que depende (en este caso, la enfermedad dependiente es la Sinusitis y la enfermedad de la que depende la Bronquitis).

Estas reglas se basan en el mismo principio que las reglas de los signos de ODDIN: Se debe generar una regla por cada síntoma/signo que compone la enfermedad dependiente (en este caso la Sinusitis) para que permita la generación virtual del signo. En el caso de ODDIN estas reglas individuales se usaban directamente para diagnosticar (establecían la relación “diagnosis”). Sin embargo, en este caso, estas reglas se usan para establecer una relación has_sign. En los siguientes Snippets se ilustra este funcionamiento.

[rule_I32398004_I36971009DISORDER:

(?i ont:has_sign ont:I36971009DISORDER) <- (?i ont:has_sign

signs:I64531003) noValue(?i, ont:hasNegSign

ont:I32398004_NOT_SIGNS) noValue(?i, ont:hasNegDT

ont:I32398004_NOT_DT) ]

Snippet 44. Regla MDSS-OPM para signos (I)





ont:I32398004_NOT_DT) ]

Snippet 45. Regla MDSS-OPM para signos (II)





ont:I32398004_NOT_DT) ]

Snippet 46. Regla MDSS-OPM para signos (III)

Analicemos detenidamente este último Snippet (los dos anteriores representan exactamente lo mismo, pero para otros síntomas).

Como se puede observar, esta regla al ser disparada lo que hace es establecer la siguiente relación:

(?i ont:has_sign ont:I36971009DISORDER)

Esta relación indica que si se cumple la premisa (que será explicada ahora), la conclusión de la regla será establecer que existe la relación “has_sign” entre la patología a diagnosticar (la Bronquitis) y el signo “I36971009DISORDER” de la ontología representada por el prefijo ont (Ontología de diagnóstico). Dado que realmente el signo I36971009DISORDER no existe, lo que realmente hace esta regla es “generar” dicho signo de forma virtual en la ontología.

Esta regla será ejecutada si se cumple la premisa:

(?i ont:has_sign signs:I25064002) noValue(?i, ont:hasNegSign ont:I32398004_NOT_SIGNS) noValue(?i, ont:hasNegDT ont:I32398004_NOT_DT)

La premisa, que es igual que la que usa el sistema ODDIN, establece que se dispare la regla en caso de que el síntoma que ha recibido sea el indicado (I25064002 / Dolor de cabeza) y que no sea ninguno de los excluidos.

152

Esta regla se repite con las otras dos anteriores, pero para los dos síntomas de la Sinusitis restantes (Secreción Nasal y Congestión Nasal).

Finalmente, existe una última regla que en ODDIN en este caso sí que estaba presente, pero donde el formato cambiaba.

Las reglas anteriores nos permitían definir la instancia I36971009DISORDER para representar a la enfermedad dependiente (Sinusitis). Además, se habían definido los síntomas válidos y no válidos en la primera regla analizada en esta sección. Sin embargo, las reglas de diagnóstico aún no han sido generadas para la Sinusitis. La siguiente regla se ocupa de esto:

[rule_I32398004_SIGN:36971009:

(?i ont:diagnosis disont:I32398004) <- (?i ont:has_sign

ont:I36971009DISORDER) noValue(?i, ont:hasNegSign


ont:I32398004_NOT_DT) ]

Snippet 47. Regla de diagnóstico para entidades enfermedad que actúan como síntomas

En este caso podemos observar como esta regla permite establecer la propiedad de diagnóstico de la Bronquitis (I32398004) cuando reciba como signo la instancia I36971009DISORDER (la cual, nótese, pertenece realmente a la ontología de diagnóstico, pues el prefijo es ont), la cual ha sido definida (de forma virtual) anteriormente, mediante la aparición de los signos correspondiente a la entidad que representa (Sinusitis).

Al margen de esta regla, evidentemente deben generarse todas aquellas correspondientes a los signos de la sinusitis de la misma forma que se generaban en el sistema de ODDIN. El siguiente ejemplo ilustra una de estas reglas (regla para la Tos (32398004)), que ya han sido mencionadas previamente.

[rule_I32398004_SIGN:I49727002:

(?i ont:diagnosis disont:I32398004) <- (?i ont:has_sign



ont:I32398004_NOT_DT) ]

Snippet 48. Reglas de los signos de la entidad enfermedad que actúan como síntomas

7.1.3. IMPLEMENTACIÓN DE LAS REGLAS

El proceso de implementación de las reglas de inferencia de las que hace uso el sistema no es una tarea trivial. El principal problema a la hora de codificar estas reglas se basa en que existen una gran cantidad de identificadores que representan a las diversas entidades existentes y esto puede provocar errores a la hora de codificar las reglas.

La idea por lo tanto para solucionar este problema es aprovechar precisamente las relaciones existentes en las ontologías, donde uno de los primeros pasos cuando se procede a la población de la ontología consiste en el establecimiento de las relaciones que involucran a las diversas entidades con el objetivo de completar el conocimiento que la ontología va a almacenar.

Aprovechando por lo tanto cuando la ontología está completamente poblada (todas las instancias han sido generadas) y las relaciones han sido establecidas, se puede proceder a la generación de un software que se encargue de generar las reglas de inferencia que serán utilizadas.

153

Partiendo de la base de que tenemos la ontología plenamente poblada (ver sección 4.5.6 para ver el proceso de población de la ontología), el funcionamiento del software de generación de reglas se sustenta en el siguiente número de pasos:

1. El software procesa la ontología para buscar todas aquellas entidades “enfermedad” del sistema.

2. Por cada entidad enfermedad, obtiene sus signos y pruebas de laboratorio asociadas.

3. En caso de que uno (o varios) de los signos sea una entidad enfermedad, obtiene sus signos asociados. En este punto, el software solo penetra un nivel dentro de la estructura de la entidad enfermedad para obtener los signos asociados (Ver conclusiones en la sección 7.1.5 para un detalle sobre los niveles de las enfermedades).

4. Una vez el software ha recopilado todas las entidades asociadas a cada enfermedad, genera las reglas para cada enfermedad.

El hecho de que el software sea capaz de generar las reglas de forma automática plantea una serie de ventajas bastante importantes:

En primer lugar, cada vez que sea necesaria la modificación de una entidad enfermedad, se puede lanzar nuevamente el software para que vuelva a generar todas las reglas. Esto tiene un impacto directo en el mantenimiento del sistema, ya que no es necesaria la edición de los ficheros de reglas y buscar que regla es la que hay que cambiar, ya que el software vuelve a regenerar todas las reglas sin necesidad de preocuparse de esto.

En segundo lugar, la principal ventaja frente a realizar este proceso de forma manual se basa en la eficiencia. En términos temporales, el sistema es capaz de generar todas las reglas de la base de conocimiento (dependerá muchos del número de elementos de esta) en apenas unos segundos. De forma manual, este proceso podría llevar varios días.

El otro aspecto importante se basa en la robustez de las reglas. La generación manual implicaría principalmente que el experto fuera quien codificara estas reglas, y se asegurara de que no existe ningún tipo de error a la hora de codificar las reglas. En el caso del sistema automático, no necesariamente tiene que ser el usuario experto quien proceda a ejecutar el sistema de creación de reglas, y además en caso de un error en la generación de las reglas el problema debería ser más fácil de encontrar, ya que si existe un error concreto, este debería darse en todas las reglas, y no solo en una.

7.1.4. EXPLICACIÓN DEL RAZONAMIENTO

Dada la tecnología principal subyacente en el sistema desarrollado es posible proporcionar como salida alternativa del sistema una explicación de las conclusiones que el sistema ha inferido. Dado que internamente el sistema basado en reglas tiene una cierta complejidad, analizar estas salidas donde se explica el proceso de razonamiento puede llegar a resultar ligeramente costoso. A continuación se expone un caso de uso concreto y sencillo que permita explicar, partiendo de las entradas que el sistema ha recibido, la conclusión a la que ha llegado a través del proceso de inferencia y la explicación de cómo se ha llegado a esta conclusión.

Para ilustrar el ejemplo partimos de una base de conocimiento donde tenemos únicamente dos enfermedades codificadas: Bronquitis y Sinusitis. Supongamos que los signos/síntomas asociados a cada una de las enfermedades son los siguientes:

154

Bronquitis: (Código SNOMED 32398004)

Tos (Código SNOMED 49727002) Debilidad (Código SNOMED 271795006) Fiebre (Código SNOMED 386661006) Disnea (Código SNOMED 162890008) Sinusitis (Código SNOMED 36971009) Dolor de garganta (Código SNOMED 162397003)

Sinusitis: (Código SNOMED 36971009)


Imaginemos que la consulta que queremos hacer al sistema se basa en introducir como signos/síntomas de entrada los siguientes elementos:


El sistema devuelve como posibles resultados ambas enfermedades (Bronquitis y Sinusitis). El proceso de razonamiento ha sido el siguiente (explicación de las derivaciones del sistema de reglas):

Rule rule_I36971009_SIGN:I25064002 <-

Fact

(http://nadir.uc3m.es/alejandro/phd/ddxont.owl#c2.consult

http://nadir.uc3m.es/alejandro/phd/ddxont.owl#has_sign

http://nadir.uc3m.es/alejandro/phd/signs.owl#I25064002)

Rule rule_I36971009_SIGN:I68235000 <-

Fact




Rule rule_I36971009_SIGN:I64531003 <-

Fact




Snippet 49. Derivación del proceso de razonamiento (I)

La primera derivación podemos observar que implica que se han disparado tres reglas. Las tres reglas disparadas se corresponden a las reglas que relacionan la Sinusitis con las tres entradas del sistema, proporcionando por lo tanto en primer lugar el diagnóstico de la Sinusitis.

155

A continuación se muestra la segunda derivación:

Rule rule_I32398004_I36971009DISORDER_SIGN_I25064002 <-

Fact





Fact





Fact




Snippet 50. . Derivación del proceso de razonamiento (II)

La segunda derivación corresponde a las reglas que permiten generar la instancia virtual que representa en este caso la Sinusitis (I36971009) en el proceso de diagnóstico de la Bronquitis (I32398004).

A continuación se muestra la tercera y última derivación:

Rule rule_I32398004_SIGN:I36971009 <-


Fact




Snippet 51. . Derivación del proceso de razonamiento (III)

En la tercera y última derivación podemos observar como primera regla hace referencia a la regla que permite diagnosticar la Bronquitis (I32398004) debido a la presencia del signo asociado a la Sinusitis (I36971009). Esta regla es ejecutada dado que se cumple el hecho de que se ejecutó la regla que permite la existencia del signo virtual de la Sinusitis (Rule rule_I32398004_I36971009DISORDER_SIGN_I25064002) ya que se encontró al menos un síntoma de la Sinusitis: Dolor de Cabeza (I25064002).

Nótese que también existían otros síntomas de la Sinusitis presentes, pero este es un ejemplo de cómo derivando hacia atrás las reglas se obtiene el origen.

Como se ha podido observar las derivaciones de las reglas de inferencia permiten proporcionar una explicación sobre el razonamiento realizado, dándole al sistema un valor añadido donde toda inferencia o razonamiento realizado tiene un soporte lógico detrás.

7.1.5. CONCLUSIONES

El sistema actual de generación de reglas permite realizar el diagnóstico mediante síndromes de la misma forma que lo permitían las descripciones lógicas establecidas anteriormente.

156

El único problema que presenta el modelo actual de generación de reglas, fundamentalmente, se basa en que el número de reglas crece de forma bastante más intensa que el modelo anterior.

En el modelo anterior, el número de reglas a generar era el siguiente:

Donde n representaba el número de signos de la enfermedad, m el número de pruebas de diagnóstico y t un valor que era 1 en caso de existir solo signos asociados a la enfermedad y 2 en caso de existir pruebas de diagnóstico. El parámetro t representaba la regla o reglas adicionales de exclusión de signos y pruebas diagnósticas.

Sin embargo, el esquema actual es bastante más complejo y el número de reglas que deberían generarse para este esquema es el siguiente:

∑

Dónde:

t: Representa las reglas de exclusión de pruebas diagnósticas y signos. Si solo hay signos, t vale 1. Si hay pruebas, t vale 2.

n: Representa el número total de signos de la enfermedad principal (incluyendo a aquellos que son realmente enfermedades).

m: Representa el número total de pruebas de diagnóstico de la enfermedad principal.

k: Representa el número de enfermedades que están actuando como síntomas.

: Representa el número de elementos (signos y pruebas diagnósticas) de la enfermedad .

Por ejemplo, en el caso expuesto en la sección anterior, teníamos los siguientes datos:

t: 1 n: 6 m: 0 k: 1 : 3

El número total de reglas por lo tanto es de 11.

Nota: Es importante recalcar que aunque haya signos comunes a varias de las entidades enfermedad que intervengan en el proceso de diseño de una regla estos no se pueden omitir aunque hayan aparecido. En la única regla donde se puede hacer esto es en la regla que establece los síntomas excluidos. En el resto, no se puede dado que aunque sea el mismo síntoma, este afectará de forma independiente a cada entidad.

La limitación más evidente de este modelo de reglase viene dada por la profundidad a la que se puedan presentar enfermedades como síntomas. El diseño actual solamente permite que este nivel sea 1, es decir, que la enfermedad principal ocuparía el nivel 0, y la enfermedad que actúa como síntoma, ocuparía el 1. En caso de que hubiera más niveles el diseño actual tendría que modificarse. A continuación se ilustra un ejemplo de cómo funcionan los niveles en este diseño.

157

Anteriormente se definió la Bronquitis como una enfermedad de la que depende otra enfermedad (Sinusitis). Esto representa que en nuestro esquema, la enfermedad más externa (la que nos proponemos crear su regla de inferencia) ocupa el nivel 0, al estar alejada en el proceso de inferencia.

La Sinusitis ocuparía el nivel 1 (en este caso solamente: cuando la Sinusitis sea una entidad independiente, ocupará el nivel 0, pero en este caso es una entidad dependiente), dado que en este caso está actuando como un signo.

En caso de que la Sinusitis tuviera asociada otra enfermedad como signo, esta ocuparía el nivel 2. Supongamos que el resfriado común es un síntoma de la Sinusitis. El Resfriado común (que es una enfermedad), estaría ocupando el nivel 2.

La Figura 40 representa este esquema:

Figura 40. Esquema de niveles diseñado para MDSS-OPM

El diseño actual del sistema sin embargo no soporta este tipo de casos. Esto se debe a que en general la gran mayoría de las enfermedades, tal como vienen descritas en la literatura médica no llegan a alcanzar este nivel 2. Sin embargo, si una enfermedad lo alcanzara, el único problema sería tratarla como si estuviera en un nivel menos del que está. Suponiendo el caso anterior, lo que se trataría de hacer sería tratar a la Sinusitis como nivel 0 (en vez de 1) y al Resfriado común como nivel 1 (en vez de 2) y aplicar la generación de reglas.

El único problema se daría en la generación de las reglas de síntomas y pruebas de diagnóstico excluyente, donde esta regla tiene que ser común independientemente del número de niveles existente. Así mismo, la fórmula que permite calcular el número de reglas de una entidad, también cambiaría.

158

7.2. MODELO PROBABILÍSTICO EPIDEMIOLÓGICO

7.2.1. INTRODUCCIÓN

El hecho de proporcionar datos probabilísticos que estén asociados a los diagnósticos proporcionados por un sistema de tipo DDSS es clave. Cuando se realiza un diagnóstico diferencial en el ámbito de la medicina no todas las posibles respuestas tienen la misma probabilidad. Esta probabilidad puede cambiar dependiendo de las entradas que reciba el sistema, y el hecho de que esta probabilidad cambie permite que los resultados obtenidos puedan ser ordenados teniendo en cuenta la mayor o menor probabilidad que exista de que se produzca una determinada patología.

En el sistema propuesto en el capítulo donde se presentaba ODDIN (García-Crespo et al., 2010) se presentaba un módulo probabilístico que permitía establecer una determinada probabilidad para cada resultado del diagnóstico diferencial que el sistema proveía. Sin embargo, este motor probabilístico a pesar de tener una base teórica sólida era demasiado simple.

Debido a esto, se pretendió generar una alternativa donde se pudiera calcular una probabilidad donde los resultados de esta probabilidad estuvieran más asociados al hecho de la entrada de los propios síntomas así como de la epidemiología asociada a la patología y a sus elementos (signos/síntomas y pruebas diagnósticas) que permitan de esa forma generar una probabilidad asociada a los elementos de la patología más correcta.

El objetivo de esta sección por lo tanto es introducir una modificación en el sistema propuesto en el capítulo 6, para que una parte de la probabilidad (la que se corresponde fundamentalmente a la presencia de los signos/síntomas y pruebas de laboratorio), sea calculada usando un elemento probabilístico más conciso.

Esta modificación sin embargo solamente propone el sistema así como su posible implementación. Esto implica que el sistema en si (dicha parte probabilística) no será tenida en cuenta a la hora de la evaluación. El motivo fundamental se basa en que aunque el sistema propuesto tiene una gran solidez teórica, su aplicación práctica es más complicada debido a la carencia existente de datos. Los estudios epidemiológicos generalmente son creados en enfermedades o patologías más concretas (enfermedades raras o con una prevalencia alta), dando como lugar la problemática de conseguir datos reales para la base de conocimiento que ha sido generada.

7.2.2. EPIDEMIOLOGÍA

La epidemiología es la disciplina científica que estudia la distribución, frecuencia, determinantes, relaciones, predicciones y control de los factores relacionados con la salud y enfermedad en poblaciones humanas (Nutter, 1999). La epidemiología en sentido estricto, que podría denominarse humana, ocupa un lugar especial en la intersección entre las ciencias biomédicas y las ciencias sociales y aplica los métodos y principios de estas ciencias al estudio de la salud y la enfermedad en poblaciones humanas determinadas.

Aunque esta disciplina es considerada como una ciencia básica en la medicina preventiva y una gran fuente de información para la salud pública, dado que las muestras que generalmente se usan (como se ha denominado antes en la epidemiología humana), hacen referencia precisamente a los seres humanos, puede considerarse como una excelente fuente de información sobre las relaciones entre los indicios que atañen a una enfermedad y la propia enfermedad. Estas relaciones, medibles en términos por ejemplo de porcentajes, proporcionan información sumamente útil que puede ser aplicada para la generación de modelos probabilísticos que ayuden a determinar, a través del estudio y

159

observación de los factores implicados, la probabilidad de sufrir una determinada patología.

7.2.3. SOLUCIÓN PROPUESTA

Existen gran variedad de estudios que reportan informes sobre diagnósticos de una determinada patología y su epidemiología (Mulsant & Ganguli, 1999; Lipton et al., 1994;). Sin embargo, la aplicación de los datos epidemiológicos para la generación de datos probabilísticos no es muy común, a pesar de que se puede observar que dichos datos contienen un gran potencial para precisamente obtener probabilidades bastante reales de padecer una enfermedad.

El modelo probabilístico empleado en este sistema se basa en la probabilidad Bayesiana (Cheeseman, 1983). Concretamente, el modelo utilizado (que más adelante se explicará concretamente en que se basa) es el modelo de Näive Bayes (Rish, 2000).

En teoría de la probabilidad, un clasificador Bayesiano ingenuo (Naive Bayes) es un tipo de clasificador probabilístico basado en el teorema de Bayes y ciertas hipótesis de simplificación adicionales. Debido a estas simplificaciones, que generalmente se suelen resumir en la hipótesis de independencia entre las variables predictorias, por lo que recibe el apelativo de ingenuo.

En los artículos de Lauritzen & Spiegelhalter (1988) y Cowell et al. (1999) existe una amplia documentación acerca de la aplicación de este tipo de redes (y otros tipos) a la construcción de sistemas expertos.

El modelo probabilístico Naive Bayes es ampliamente usado para aprendizaje automático (Lewis, 1998) dada su optimalidad en ciertos escenarios (Zhang, 2004). La razón de su éxito se basa en la independencia de las características manejadas (Rish, 2001). La clasificación es otro de los campos principales donde es usado este algoritmo como en la detección de SPAM (Provost, 1999; Schneider, 2003; Seewald, 2007), reconocimiento de emociones (Sebe et al., 2002), o clasificación de textos (Chai et al. 2004; Peng et al. 2003; Rennie, 2001). Sin embargo, no es frecuente ver trabajos usando este modelo para estimar probabilidades (Lowd & Domingos, 2005).

El diseño del modelo probabilístico que se pretende usar en este enfoque se basa en un trabajo previo realizado por el autor de la tesis donde se utilizaba este tipo de modelos para realizar un diagnóstico preventivo de accidente cerebrovascular (Rodríguez et al. 2010). En este trabajo, se asume independencia entre los factores de riesgo que son usados en el modelo y por lo tanto, el principal argumento para asumir esta independencia entre los factores de riesgo se basa en dos razones fundamentales:

1. La naturaleza de los datos epidemiológicos usados para generar el modelo probabilístico suelen provenir de diferentes fuentes (diferentes estudios), implicando por lo tanto que la muestra contendrá individuos diferentes y que como consecuencia no podría existir dependencia entre los individuos de la muestra, y por lo tanto, entre los factores que afectan a dichos individuos.

2. En el caso del sistema expuesto anteriormente (Rodríguez et al. 2010), la asunción de independencia también se debe realizar debido a que existen diversos factores de riesgo que pueden tener una dependencia directa entre ellos (por ejemplo: diabetes y sobrepeso). Si no omitimos este hecho, el modelo sería más complejo, y además, esta dependencia entre indicios no puede ser demostrada en todos los casos (dando como resultado la imposibilidad de obtener los valores probabilísticos).

160

En el sistema propuesto, se reemplazan los factores de riesgo por indicios médicos (en este caso, como caso mínimo de uso se considera como indicios médicos síntomas y signos (de ahora en adelante nuevamente se mencionará uno de los dos términos indistintamente para referirse a ambos)). La idea es generar un modelo probabilístico que permite consultar la probabilidad de sufrir una determinada enfermedad dando como entradas la presencia (o ausencia) y el nivel (en el caso de síntomas que tengan una cierta intensidad) de un indicio concreto.

En el caso en el que estamos trabajando es necesario la generación de un modelo por cada enfermedad, dado que el modelo es explícito de la enfermedad, y para cada una se necesita un modelo distinto (dado que los datos probabilísticos, aunque se compartan por ejemplo signos, serán distintos).

La arquitectura genérica del modelo es la que se muestra en la Figura 41.

Figura 41. Modelo probabilístico

El número de posibles valores para cada indicio depende de sí mismo. Por ejemplo, un indicio que representa un síntoma concreto donde solo necesitamos saber si está presente o no para confirmar o rechazar un diagnóstico solo puede tomar dos valores posibles (presente o no). Sin embargo, un síntoma como la fiebre puede tomar tres valores dependiendo de su virulencia o intensidad (febrícula, fiebre, hiperpirexia).

Este modelo permite calcular la probabilidad final de sufrir una enfermedad concreta tomando como parámetros del modelo los indicios que normalmente están asociados a la enfermedad. Con este modelo, es posible consultarlo dándole como parámetro la presencia o ausencia de un indicio concreto, y en el caso de que este indicio pueda tomar varios valores, el grado.

El modelo probabilístico asociado al modelo gráfico representado en la figura anterior es el siguiente (notación: Indicio n = , Enfermedad = D):

|

Se puede observar que existen varias diferencias de este modelo probabilístico comparado con el usado en el artículo del ictus. La principal diferencia se puede observar en la representación gráfica del modelo, dado que en el modelo del ictus existen algunos indicios que tienen dependencias, debido a que dependen de otras variables. Sin embargo,

161

en este modelo se asume que esa peculiaridad no existe, y por lo tanto, se simplifica el modelo probabilístico representado en la fórmula anterior.

A continuación se mostrarán los principales datos que el modelo necesita. Estos datos, como se ha mencionado anteriormente, serán extraídos por lo general de estudios epidemiológicos.

Los primeros valores que el modelo necesita son aquellos que hacen referencia a la distribución o incidencia de los indicios usados en el modelo. Esta incidencia se representa mediante donde 'n' hace referencia al indicio enésimo del modelo.

Los valores de incidencia solo representan como está distribuido el indicio (por ejemplo, fiebre) en la muestra usada como referencia. Estos datos pueden ser difíciles de obtener, sobre todo, teniendo en cuenta que normalmente los indicios son síntomas o signos y no enfermedades concretas y por lo tanto puede ser difícil llegar a establecer la incidencia de un síntoma en una muestra concreta (la incidencia de una enfermedad es más fácil de saber en muestras grandes). Por esta razón, la muestra usada se corresponde a los datos de la enfermedad concreta sobre la que se va a generar el modelo.

Los segundos valores necesarios por el modelo son la probabilidad de sufrir la enfermedad si estamos padeciendo algún síntoma concreto (indicio) el cual solo puede tomar dos valores (presencia o ausencia). Esta probabilidad se representa mediante | y se toma valor de referencia la probabilidad de la presencia.

Si se considera el caso en el que los indicios puedan tomar más de dos valores, la probabilidad se representa mediante | donde V representa el valor posible que el indicio I puede tomar.

Como se ha mencionado anteriormente, los datos normalmente provienen de diferentes estudios y normalmente es difícil establecer la dependencia entre los indicios. Por esta razón, se asume la restricción de asumir la independencia entre los factores (indicios) para generar el modelo probabilístico final.

Como se puede observar en la fórmula del modelo probabilístico, todos los valores de los factores están disponibles gracias a la investigación de la incidencia de cada factor en la muestra usada. Sin embargo, la parte de la fórmula del modelo donde es necesario obtener la probabilidad | es la que genera problemas. Para solventar el problema que genera esta parte del modelo probabilístico, se crea una hipótesis donde se asume la independencia de los indicios.

| | | | (1)

( )

Esta asunción fuerte implica independencia entre los factores usados. Por lo tanto, el modelo presentado antes basado en este tipo de asunción, representa un modelo probabilístico de tipo Naive Bayes (Rish, 2000).

Esta asunción, permite que, la probabilidad | pueda ser calculada de forma sencilla. A continuación se muestra la explicación de los cálculos realizados suponiendo que tenemos únicamente dos indicios (a y b).

|

|

162

Con este desarrollo, el factor de la ecuación que está generando problemas | , es fácil de calcular después de asumir independencia entre las variables. El factor representa la incidencia global de la enfermedad en la muestra.

Si se desarrolla esta última fórmula, con las fórmulas existentes en la asunción de independencia realizada anteriormente, obtenemos lo siguiente:

|

|

| |

Reordenando esta última parte de la fórmula y dividiéndolo en dos productos, tenemos:

|

|

Por otra parte, supongamos el siguiente producto y su desarrollo:

| |

|

|

De este desarrollo, podemos obtener que el resultado de | | es muy similar al resultado del desarrollo de | . De hecho, en el desarrollo de | | , se obtiene un P(D) adicional, que para poder igualar ambas partes, quedaría de la siguiente forma:

| | |

Por lo tanto, se puede hacer la siguiente afirmación tras despejar | :

| | |

Una vez tenemos una forma sencilla de obtener la probabilidad de la enfermedad condicionada a diversos factores, debemos generar la fórmula que nos permita generar las tablas de probabilidades asociadas al modelo probabilístico diseñado. Para ello, realizaremos un pequeño ejemplo del cálculo de la tabla de probabilidades de la enfermedad condicionado a 3 síntomas o signos (a, b, c) para generar un productorio que nos permita establecer un pseudo algoritmo de generación de valores. Antes de realizar los cálculos, establecemos ciertas fórmulas básicas de la teoría de probabilidad que permitan comprender el concepto plenamente:

Dados dos sucesos dependientes (A y B), la probabilidad | se define como:

|

Así mismo, la probabilidad de la intersección, , se define como:

|

Una vez definidos estos conceptos, trataremos de desarrollar el cálculo de la probabilidad de la enfermedad condicionada a tres factores de riesgo: |

| |

| | |

163

El último término, puede desglosarse como:

( |

) (

|

) (

|

)

Del primer término se puede hacer una correspondencia directa mediante las fórmulas de probabilidades condicionadas:

|

|

El segundo y tercer término también tienen una correspondencia relativamente directa:

| |

Al pasar P(D) al denominador, obtenemos el equivalente al segundo factor (y al tercero, cambiando las variables):

|

|

De esta forma, se hace la siguiente equivalencia:

( |

) (

|

) (

|

) |

|

|

Como se puede ver, de tres factores, el elemento P(D) está dividiendo en dos. Así pues, podemos generar el siguiente productorio:

| ∏ |

Otra fórmula que se debe tener en cuenta es el cálculo de la negación del factor de riesgo respecto a la enfermedad: |

| |

7.2.4. EJEMPLO DE USO

Dado que como se ha comentado en la introducción la obtención de datos epidemiológicos es una tarea difícil se decide mostrar cómo caso de uso del sistema el mismo caso de uso presentado en el artículo escrito por Rodríguez et al. (2010) donde se plantea este mismo modelo probabilístico para el diagnóstico preventivo del accidente cerebrovascular de tipo isquémico (ictus).

En el caso de uso planteado en dicho artículo se hace una simplificación de los elementos incidentes en el modelo probabilístico y se reducen a tres. El motivo argumentado es fundamentalmente el tamaño de la tabla probabilística a generar, que en el caso de utilizar todos los factores de riesgo propuestos inicialmente en el artículo supondría generar más de un millón de combinaciones probabilísticas.

Los factores de riesgo a usar son: Diabetes, Hipertrofia Ventricular Izquierda y Sobrepeso.

164

A continuación, se muestra un diagrama representativo de cómo sería el modelo probabilístico asociado a estos tres factores de riesgo:

Figura 42. Modelo probabilístico del ICTUS reducido

A partir de este modelo probabilístico debemos tener presentes para realizar los cálculos una serie de probabilidades:

Factor Probabilidad

P(OV) 0.15

P(LVH) 0.15

P(DI) 0.028

P(I) 0.00322

P(I|OV) 0.0195

P(I|LVH) 0.0179

P(I|DI) 0.019

Tabla 13. Probabilidades asociadas al modelo probabilístico

A continuación, se plantean las probabilidades que se deben calcular para los 3 factores de riesgo existentes ( probabilidades). La notación indica la negación de la variable X, y por lo tanto está indicando que se debe obtener la probabilidad negada siguiendo las fórmulas indicadas anteriormente.

Factor Probabilidad

| 0.6396

| 0.0908

| 0.022

| 0.025

| 0.00138

| 0.001962

| 0.000485

| 0.00006895

Tabla 14. Probabilidades calculadas para el modelo probabilístico

El cálculo de estas probabilidades se realiza siguiendo el diseño planteado anteriormente. Concretamente, usando la siguiente fórmula:

| ∏ |

165

Para ilustrar el funcionamiento, se expone como ejemplo el siguiente cálculo:

| | | |

Para realizar dicho cálculo se debe obtener la probabilidad | , la cual fue obtenida aplicando la fórmula VIII como se expone a continuación:

| |

Una vez obtenidos todos los valores, se deberán introducir en el software probabilístico a usar, con el objetivo de que este sea capaz de calcular las probabilidades finales en función de los factores de riesgo que conozcamos (esto se considerará como una consulta contra el modelo probabilístico).

A continuación, se muestra, para el modelo del ejemplo que se está tratando, como quedarían los datos introducidos en el modelo probabilístico que ha sido generado con el software GeNIe:

Figura 43. Probabilidades en GeNIe

Supongamos que tenemos ahora el siguiente caso:

Un paciente del cual se quiere obtener la probabilidad de que pueda padecer ictus, teniendo en cuenta que los datos que tenemos es que padece hipertrofia ventricular izquierda (LVH) y no padece sobrepeso (OV). No tenemos información alguna de si padece diabetes (DI).

La consulta que se debe hacer contra el modelo es la siguiente: | .

En GeNIe, lo que haremos es establecer que no existe ningún tipo de evidencia para la diabetes (DI), y que el factor hipertrofia ventricular izquierda (LVH) está presente (Valor Yes) y el factor sobrepeso no lo está (Valor No). La Figura 44 muestra esta situación en GeNIe:

Figura 44. Representación del modelo en GeNIe

Una vez indicado al software que calcule esta consulta, obtenemos el siguiente resultado:

166

Figura 45. Resultado obtenido tras preguntar a GeNIe sobre una determinada probabilidad

Por lo tanto, el paciente tendría un 0.19% de probabilidades de padecer un ictus dados los datos introducidos.

Como consideración final, se muestra el desarrollo realizado para calcular este resultado:

|

∑ |

∑ ∑ |

∑ |

∑ ∑ |

∑ |

∑ ∑ |

∑ |

∑ ∑ |

Los factores que se marcan en negrita, son aquellos que, en sus respectivos sumatorios se debe ir cambiando su valor con las alternativas que ofrece. En concreto, las alternativas que ofrecen estos factores (DI e ICTUS) son los valores de estar presente o no.

El desarrollo final, con los valores reales, se muestra a continuación. Para simplificación, se van a realizar por una parte las operaciones correspondientes al sumatorio del numerador, y por otra, las del denominador.

El numerador es un sumador que se puede dividir en dos factores (cuando DI está presente (lo llamaremos S1) y cuando no (lo llamaremos S2)):

S1: DI presente: |

S2: DI no presente: |

El numerador por lo tanto se representa como S1 + S2:

El denominador es un sumador que se puede dividir en cuatro factores. Con ICTUS presente: DI presente y DI no presente. Con ICTUS no presente: DI presente y DI no presente.

S3: ICTUS presente, DI presente. Es equivalente a S1.

S4: ICTUS presente, DI no presente. Es equivalente a S2.

S5: ICTUS no presente, DI presente:

|

167

S6: ICTUS no presente, DI no presente:

|

El denominador por lo tanto se representa como S3 + S4 + S5 + S6:

La probabilidad final, por lo tanto es:

|

En este caso, el porcentaje obtenido, difiere un poco del que ha dado GeNIe. Los motivos se deben fundamentalmente al sistema de representación que pueda usar GeNIe, donde el número de decimales a usar cambie, dando lugar a ligeras diferencias.

7.3. CONCLUSIONES

El presente capítulo presenta una evolución de algunos de los aspectos que han sido presentados en los capítulos anteriores, donde se definían ODDIN, ADONIS y SEDELO y donde se proponían mecanismos de verificación para las diferentes hipótesis que han sido planteadas en la presente tesis, dando lugar a una solución verificable.

Sin embargo, a pesar de la que las hipótesis puedan ser verificadas en función de los sistemas diseñados y desarrollados, existen ciertos elementos que se ha considerado que podían ser mejorados con el objetivo de incrementar la utilidad tanto parcial como global de los sistemas y elementos diseñados y desarrollados en la presente tesis.

Con dicho objetivo, en este capítulo de la tesis se ha presentado MDDS-OPM, como una evolución de ODDIN, ADONIS y SEDELO. MDDS-OPM se basa en la mejora de ODDIN, ADONIS y SEDELO desde tres puntos de vista:

1. Mejora de la base de conocimiento 2. Mejora del sistema de inferencia 3. Mejora del modelo probabilístico

En primer lugar, la mejora de la base de conocimiento viene dada por una adaptación de la ontología que ODDIN, ADONIS y SEDELO han utilizado, para ser convertida en una ontología adaptada a los distintos estándares de terminología clínicos. Esta adaptación tiene como consecuencia principal, la dotación de capacidad de reutilización directa en otro tipo de entornos, ya que, al usar un estándar concreto, es posible reutilizar todo el conocimiento almacenado en otro tipo de sistemas.

Desde el punto de vista de redefinición, se propone una nueva arquitectura modular para la ontología del sistema, de tal forma que los distintos módulos que la conforman puedan ser hasta cierto punto independientes, dando lugar a una reusabilidad directa de las distintas sub ontologías que conforman la ontología principal. Además de esto, se ha introducido una propuesta de arquitectura que se base en obtener ciertos datos pertenecientes al dominio a través de una base de datos, dotando al sistema de una capacidad para obtener información no relevante de forma más eficiente que si se almacenara en la propia ontología.

168

La mejora del sistema de inferencia viene dada por la generación de un conjunto de reglas que permitan mejorar la solución propuesta para la hipótesis H2 por SEDELO. En SEDELO, la propuesta se basaba principalmente en el uso de descripciones lógicas para definir las entidades enfermedad y sus elementos asociados, así como las posibles relaciones entre estas para dar lugar a una verificación de esta hipótesis. Sin embargo, desde un punto de vista de diseño, y sobre todo, de eficiencia, la solución planteada en términos de descripciones lógicas no es demasiado factible. Hablando de diseño, esta solución es problemática porque la capacidad de generar las descripciones asociadas a las enfermedades implica una modificación directa de la ontología, mientras que en la propuesta de MDDS-OPM la solución se basa en ficheros de reglas ajenos a la base de conocimiento que representa la ontología, dando esto lugar a una eficiencia mucho mayor, y por lo tanto siendo verificable la hipótesis H1.2 que planteaba problemas. Por otra parte, desde el punto de vista de eficiencia (temporal), la capacidad de razonamiento que proporciona el motor de inferencia de Jena Rules es superior a la eficiencia que se obtenía mediante el uso de DL en SEDELO.

Para finalizar, el presente capítulo ofrece un nuevo motor de cálculo de probabilidades asociados a los diversos diagnósticos que el sistema pueda devolver. Este sistema, basado en un modelo Naive Bayes, permite calcular una probabilidad de una determinada patología teniendo en cuenta datos epidemiológicos sobre una población concreta, superando con creces a los datos devueltos por ODDIN.

169

8. EVALUACIO N La evaluación de los sistemas de diagnóstico diferencial no es una tarea trivial.

Existen diversos enfoques de evaluación dependiendo de que se quiera valorar o evaluar, y donde se debe dar un determinado peso a cada uno de los enfoques para que la evaluación sea lo más completa posible. En las siguientes páginas se definirán los enfoques de evaluación en los que se centrará esta tesis, así como en la presentación de la metodología de evaluación que se realizará para la presente tesis.

8.1. ENFOQUES DE EVALUACIÓN

La evaluación de un sistema CDSS puede ser abordada desde diversos puntos de vista o enfoques. En nuestro caso concreto, siendo el CDSS a analizar y evaluar en realidad un DDSS (CDSS orientado hacia el diagnóstico) existe un enfoque primordial, y este es la evaluación de la eficiencia a la hora de realizar un determinado diagnóstico diferencial. Es importante saber que el sistema que se ha diseñado y construido para verificar las hipótesis cumple con una serie de especificaciones, con una serie de requisitos que permitan asegurar que los resultados que el sistema va a arrojar cuando se le realice una nueva consulta son adecuados.

8.1.1. EVALUACIÓN DE LA EXACTITUD DE DIAGNÓSTICO DEL SISTEMA

En 1990 se generó un informe en el que las decisiones que ayudan en medicina normalmente son evaluadas midiendo la estructura de la ayuda, la función de la ayuda, o el impacto de la ayuda en usuarios impacientes. Refiriéndose "impacto en usuarios y pacientes" a los efectos del sistema en los procesos de medición como eficacia, tiempo y confidencia de las decisiones; o efectos del sistema en las mediciones de los resultados, como mortalidad de pacientes o coste de los procedimientos (Wyatt & Spiegelhalter, 1990).

En general, la literatura acerca de la evaluación de los CDSS se centra en el rendimiento o cambios específicos en los patrones de la práctica clínica bajo condiciones predefinidas, pero parece existir una carencia en los estudios que utilizan una metodología que podría indicar las razones por las cual los clínicos deben o no deben usar los CDSS o cambiar sus comportamientos en la práctica. Algunos de los artículos más relevantes en este campo son los que se citan a continuación.

En el trabajo de Reggia (1985), se identifican los conceptos envueltos en la evaluación de la eficiencia de un sistema de soporte a la decisión clínica de pacientes que sufran ataques isquémicos transitorios. Dos factores se identificaron como cruciales en el desarrollo y prueba de este sistema: la disponibilidad de un sistema generador de expertos independiente del dominio y la existencia de una base de datos con historiales relevantes de los pacientes.

En 1987, Lusdsgaarde (1987), identificó los principales métodos utilizados para evaluar la eficiencia de los sistemas expertos médicos en entornos clínicos y de laboratorio. Este trabajo también describe las diferentes estrategias de investigación usadas en la evaluación de sistemas expertos de tipo médico en diferentes fases de desarrollo y discute los trabajos de evaluación pasados presentados por otros autores.

Kulikowsk (1988) enfatiza que la validación y evaluación del conocimiento médico plantea una serie de preguntas fundamentales sobre la naturaleza del conocimiento médico práctico y como es aplicado. Entre las principales cuestiones planteadas tenemos: 1) ¿Que criterios deben usarse para establecer la veracidad de las afirmaciones y modelos

170

usados en una base de conocimiento?; 2) ¿Que criterios deben ser usados para establecer la autoridad con la que el conocimiento crícito debe ser validado?

En el artículo de Adlassnig et al. (1989) se presenta una evaluación de la exactitud diagnóstica del sistema experto CADIAG-Z/PANCREAS. La evaluación mostró que la lista de hipótesis iniciales de CADIAG-2, basada en la historia del paciente, exámenes físicos y pruebas de laboratorio básicas, normalmente, ya ha incluido el diagnóstico estándar de oro y por lo tanto la aplicación de CADIAG-2 en una parte muy temprana del proceso de diagnóstico parece ser util.

Grogono et al. (1993) han estado investigando técnicas para la evaluación de sistemas expertos desde 1898. Ellos desarrollaron una metodología sistemática para el diseño e implementación de sistemas expertos de diversos tipos. El método comienza con la preparación de una especificación que captura las necesidades de la aplicación. Durante la implementación del sistema experto, los autores recomiendan la verificación, para detectar inconsistencias internas en la base de conocimiento, y validación, para comprobar que el sistema se está comportando de acuerdo a la especificación realizada.

Georgakis et al. (1991) desarrollaron una metodología de evaluación estadística para medir la eficiencia de sistemas expertos médicos, incluyendo MEDAS (Medical Emergency Decision Assistance System). Las mediciones de la eficiencia fueren seleccionadas para tener una interpertación operacional y también reflejar la capacidad predictiva de diagnóstico de un sistema experto. Ciertas medidas resumen son usadas para repersentar la sensibilidad, especificidad y respuesta de un sistema experto. Medidas de acuerdo como el índice kappa y la medición de acuerdo condicional fueron usadas para medir el nivel de acuerdo entre el sistema experto y el médico. Las medidas Goodman y Kruskal's de predición de asociaciones fueron itnroducidos para evaluar la capacidad predictiva de un sistema médico experto.

Arocha et al. (2005) presentan un método formal para un análisis cognitivo-semántico para la identificación y caracterización de estrategias de razonamiento realizadas en tareas médicas y demuestra su uso a través de ejemplos específicos. Aunque el análisis semántico fue desarrollado originalmente en la investigación de estructuras de conocimiento, también puede ser aplicado para identificar los procesos de razonamiento y decisión usados por los médicos en tareas clínicas.

En el artículo de West et al. (2005) se investiga el potencial de varias estrategias de selección a partir de una población de 24 modelos de clasificación para formar conjuntos con el objetivo de incrementar la exactitud de los sistemas de soporte a la decisión en la detección y diagnóstico temprano de cancer de mama. Los resultados sugieren que los conjuntos formados a partir de una colección diversa de modelos son generalmente más exactos que otro tipo de conjuntos basados en la selección de un único modelo. Los conjuntos efectivos son formados a partir de subconjuntos pequeños y selectivos de la población de modelos disponible con candidatos potenciales identificados a través de un proceso multi-criterio que considera diversas propiedades de los modelos.

En general, como se puede ver en la literatura existente en lo referido a la evaluación de este tipo de sistemas, se observa que en los CDSS tienden a valorar más la eficiencia de estos sistemas en vez de la de los médicos usando estos sistemas, o el impacto del uso del sistema en los cuidados clínicos (Friedman et al., 1999; Berner et al., 1999; Berner, 1999; Nøhr, 1994).

Un importante estudio es el de Tierney et al. (2004) en la editorial de la American Informatics Association donde los autores hacen la siguiente reflexión: "Sólo a través de la realización de rigurosos estudios clínicos se puede definir si un nuevo sistema informático va

171

a ayudar, dejar la situación como estaba o empeorar el problema". Además, se debe tener en cuenta que aproximadamente el 90% de todos los sistemas expertos médicos no han sido evaluados en entornos clínicos (Lundsgaarde, 1987).

El enfoque principalmente usado para evaluar la efectividad de un CDSS se basa en la cotejar los resultados del MDSS a analizar con especialistas en medicina o comparar sus resultados con otros DSS (Kaplan, 2001).

En este enfoque propuesto por Kaplan (2001) se considera que la mayoría de los estudios usan pruebas controladas aleatorias (RCT - Randomized Controlled Trials) para evaluar el rendimiento del sistema o centrarse en los cambios del rendimiento clínico que podría afectar al cuidado del paciente. La mayoría de estas evaluaciones usan diseños basados en experimentos de laboratorio para establecer lo bien que el sistema o los profesionales que usan el sistema trabajan en condiciones controladas.

Existen ciertas revisiones de sistemas que se tratan de focalizar en la funcionalidad del sistema (Shiffman et al., 1999a; Shiffman et al., 1999b). Algunos estudios de sistemas de soporte a la decisión tienden a puntuar la validación de la base de conocimiento, por ejemplo, midiendo su eficiencia y comparándola con algún estándar de oro (Nøhr, 1994; Karlsson et al., 1997; Clarke et al. 1994).

Algunos autores recomiendan un proceso de evaluación en varios escenarios, evaluando la funcionalidad en situaciones de la vida real y evaluando el impacto del sistema en dichos escenarios (Clarke et al. 1994).

Como se puede observar, la mayoría de los autores coinciden en que la herramienta más importante a la hora de evaluar un sistema de tipo CDSS es la evaluación de la eficiencia del mismo.

La evaluación por lo tanto de la eficiencia del sistema se basará en medir mediante una serie de métricas (explicadas en la metodología) para saber cuan bueno es el sistema a la hora de diagnosticar patologías.

8.1.2. EVALUACIÓN DE LA COMPLEJIDAD COMPUTACIONAL. RENDIMIENTO

La teoría de la complejidad computacional es la rama de la teoría de la computación que estudia, de manera teórica, la complejidad inherente a la resolución de un problema computable. Los recursos comúnmente estudiados son el tiempo (mediante una aproximación al número y tipo de pasos de ejecución de un algoritmo para resolver un problema) y el espacio (a través de la aproximación a la cantidad de memoria que será necesaria para la resolución de un problema).

La evaluación de la complejidad computacional en un sistema CDSS es uno de los enfoques que dependiendo de la orientación del sistema CDSS a desarrollar debe tenerse en cuenta o no. En nuestro caso, dado que el sistema es un sistema que podría considerarse dependiendo de la situación como un sistema crítico (pues su tiempo de respuesta, dependiendo del campo de la medicina donde se usara podría ser necesario de forma inmediata y sin dilaciones) se trataría de optimizar la complejidad computacional del sistema.

Esta complejidad, como se ha definido anteriormente, se puede medir en dos conceptos básicos: Temporal y Espacial.

Basándose en las características ideales de un sistema crítico, se debe anteponer una complejidad a otra, si bien se trataría de optimizar ambas. Aun así, está claro que la complejidad temporal de los algoritmos usados siempre será mucho más importante que

172

la complejidad espacial, siempre y cuando, esta complejidad espacial no sea tan alta que implicara una posible caída del sistema por falta de memoria.

Tratando de contemplar un caso en el que la gestión de la memoria fuera lo suficientemente eficiente como para dejar de lado posibles caídas del sistema por falta de memoria, algo que en la actualidad es tecnológicamente posible para sistemas de este tipo, la evaluación debe centrarse por lo tanto la evaluación computacional principal en la complejidad de tipo temporal, dejando en segundo plano la complejidad espacial.

8.1.3. EVALUACIÓN DE LAS TÉCNICAS EMPLEADAS

La evaluación tecnológica de un sistema es una medida cualitativa sobre la calidad de los métodos o técnicas empleados para el diseño y desarrollo de un sistema concreto. Esta evaluación es importante dado que permite comparar las técnicas que se utilizan en otros sistemas similares al que estamos evaluando y comparar, junto con el resto de evaluaciones, los resultados.

Esto permitiría, en futuras evaluaciones de este tipo de sistemas, asociar eficiencia con las tecnologías implicadas (aunque realmente, los factores que influyan por debajo sean de lo más variados y en realidad esta evaluación debería ser bastante más amplia).

La literatura actual generalmente no refleja este tipo de evaluaciones. Existen algunos artículos como el Chandrasekaran (1983) o el de Miller (1986), donde se discuten los problemas que se encuentran en la evaluación de sistemas computarizados que aplican la Inteligencia Artificial en la medicina. Esta evaluación se basa en tres niveles distintos: La evaluación subjetiva de la contribución investigadora en el desarrollo de un prototipo, la validación del conocimiento del sistema y su eficiencia, y la evaluación de la eficacia clínica en un sistema operacional.

Se aplicará por lo tanto una metodología específica para la evaluación de este tipo de sistemas basándose en un análisis cualitativo de las técnicas empleadas.

8.2. METODOLOGÍA DE EVALUACIÓN

El término metodología, hace referencia al conjunto de procedimientos basados en principios lógicos, utilizados para alcanzar una gama de objetivos que rigen en una investigación científica o en una exposición doctrinal (Eyssautier, 2006).

En esta sección, se pretende por lo tanto generar una metodología muy concreta, focalizada en solventar el proceso de evaluación de un sistema de diagnóstico diferencial en medicina. Para la generación de esta evaluación, se utilizarán como principales referencias algunos de los términos y artículos que se han ido citando en este capítulo con el objetivo de formar una serie de métodos que permitan generar un criterio de evaluación adecuado al objetivo mencionado.

La razón por la que se necesita generar una metodología de evaluación específica se debe a que, como se ha citado anteriormente, la mayoría de los sistemas cuyo objetivo es similar al que se ha presentado en esta tesis, basan la inmensa mayoría de su evaluación únicamente en el proceso de diagnóstico y sus resultados. Aunque este proceso, como se comenta más adelante, es uno de los pilares básicos a la hora de evaluar este tipo de sistemas, no es el único, dado que hay otros factores que influyen y que se deben de tener en cuenta cuando estamos validando sistemas de este tipo.

173

Por lo tanto, la evaluación de este tipo de sistemas, como se ha mencionado anteriormente se basa en ciertos pilares fundamentales que son los que conformarán en general la validez del sistema estudiado.

La exactitud del sistema es el primero de los pilares que deben ser evaluados, pues sin este tipo de evaluación, la validación del sistema carecería completamente de sentido, ya que, de hecho, no podría realizarse una valoración objetiva. La exactitud de diagnóstico permite afirmar si el sistema va a ser adecuado para su uso en entornos clínicos o educacionales, y si su uso va a repercutir positivamente en el entorno donde se utilice, ya que si el sistema proporciona resultados poco fiables o exactos, la repercusión será negativa, mientras que si los resultados son fiables y aceptados por la comunidad donde se va a utilizar, el sistema reflejará que es útil. Dentro de esta exactitud del sistema, el diseño de un procedimiento de ensayo que permita obtener resultados válidos y significativos estadísticamente es uno de los requisitos más importantes cuando se está valorando la exactitud diagnóstica y por eso en nuestro caso se generarán una serie de métodos concretos para realizar esta evaluación.

La eficiencia temporal del sistema es el segundo de los pilares que se tiene que tener en cuenta a la hora de valorar estos sistemas. Los primeros sistemas expertos con objetivos de diagnóstico, realizados a principios de los 70 eran en muchas ocasiones desechados para su uso en la práctica clínica debido a la gran cantidad de recursos temporales que consumían (un claro ejemplo es por ejemplo MYCIN, mencionado anteriormente, donde varios autores argumentaron que su uso en entornos reales era inviable debido a que cada consulta contra el sistema tomaba una media de 30 minutos y dependía completamente del experto que introdujera los datos). Esta complejidad temporal, aunque con el uso de los ordenadores actuales y las nuevas técnicas de programación y sistemas operativos ha descendido de manera asombrosa, aún necesita ser medible, ya que en este tipo de sistemas donde las bases de conocimiento se pueden hacer realmente grandes es necesario comprobar que los tiempos que van a tomar las ejecuciones del sistema son aceptables.

La eficiencia espacial del sistema es también otro de los elementos que se necesitan evaluar. En este caso, este es quizás uno de los aspectos que han sido más difíciles de mejorar a lo largo de los años, y es que, aunque las capacidades computacionales y de capacidad de las máquinas hayan mejorado, la información sigue siendo la misma. Lo único que cambian son los formatos o la forma en la que se almacena, tratando de reducir el tamaño (y por lo tanto su complejidad espacial). Aun así, este es un elemento difícilmente mejorable.

Finalmente, el tercer pilar que conforma la metodología de evaluación hace referencia al uso de las tecnologías que han sido empleadas para desarrollar el sistema. Las tecnologías (bien sean de Inteligencia Artificial o de otra disciplina) necesitan ser evaluadas, sobre todo, de forma cualitativa más que cuantitativa.

La metodología por lo tanto que se va a usar se expone a continuación en las siguientes subsecciones. Por cada objeto de evaluación de los tres posibles: eficiencia, complejidad y tecnologías se generará una serie de procedimientos que definirán como se debe realizar la evaluación de cada uno de ellos.

8.2.1. EVALUACIÓN DE LA EXACTITUD

La evaluación de la exactitud se basa en medir cuantitativamente la exactitud del sistema que se va a evaluar a la hora de hacer diagnósticos diferenciales. Para ello, la metodología que se va a emplear se basa en la generación de un conjunto de casos clínicos que serán evaluados desde distintos puntos de vista por expertos en medicina.

174

8.2.1.1. FASE DE EVALUACIÓN. DISEÑO DEL EXPERIMENTO

El diseño del experimento para la evaluación de la exactitud del sistema se basa en una serie de procesos que deben llevarse a cabo de forma secuencial para garantizar la correctitud de los resultados.

A modo de resumen, el proceso de evaluación se divide en dos partes: creación del experimento y análisis de los resultados.

La creación del experimento así mismo consiste en los siguientes pasos:

Creación de casos clínicos a evaluar y su validación (en la utilización de jerga médica) por un experto. Alguno de estos casos estará diseñado para ser capaz de realizar diagnósticos mediante inferencia multinivel.

Asociación de casos clínicos a expertos mediante uso de un proceso similar a RCT para su procesado

Recolección de datos de evaluadores y sistemas Arbitraje de los resultados de evaluadores y sistema

A continuación se definen cada uno de los pasos mencionados en el párrafo

anterior:

Creación de los casos clínicos

La creación de los casos clínicos consiste en diseñar una serie de enunciados que definan unos hipotéticos casos clínicos que podrían darse en una situación real en un consultorio de medicina.

La creación de estos enunciados se debe basar en observar las enfermedades existentes en la base de conocimiento, con el objetivo de crear casos que a priori puedan diagnosticar, al menos, una gran parte de las enfermedades contenidas en la base de conocimiento. El hecho de usar como referencia las enfermedades de la base de conocimiento tiene su motivación en que se pretende conseguir que tanto los expertos como el sistema puedan diagnosticar enfermedades que están contenidas en esta base de conocimiento para que la evaluación permita arrojar resultados acerca del diagnóstico de estas patologías.

Asociación de casos clínicos a expertos

El proceso de asociar los casos clínicos a los expertos se basa en definir que expertos deben resolver que casos clínicos. Para ello se hace uso del concepto de Prueba controlada aleatoria, adaptado a este dominio.

En primer lugar, se hace una definición de este concepto para comprender su objetivo.

En segundo lugar se hace un análisis de los factores que influyen para esta asociación y las relaciones entre estos.

Finalmente, se muestra como se hace la asignación siguiendo un proceso similar a RCT y la metodología propuesta.

175

Prueba controlada aleatoria (RCT):

Como parte de la metodología propuesta para la evaluación del sistema se introduce el concepto de prueba controlada aleatoria (RCT – Randomized Controlled Trial) (Chalmers et al., 1981).

Una prueba controlada aleatoria es un procedimiento científico que se usa normalmente en la prueba de medicinas o procedimientos de carácter médico. Es una prueba que utiliza un control de tipo aleatorio. Es considerada como la forma más fiable de evidencia científica debido a que elimina todas las formas de sesgo cognitivo.

La idea básica que persigue este tipo de prueba es que los tratamientos (en el caso de prueba de medicinas) deben ser asignados aleatoriamente a los sujetos de investigación, asegurando esto, que los diferentes grupos de tratamiento son estadísticamente equivalentes.

En la evaluación actual, se intercambia el tratamiento por un caso clínico y a los sujetos de investigación por expertos en el dominio que se está usando.

Dentro de, generalmente, este tipo de pruebas, entra en juego el concepto de prueba de ciego (único, doble, triple) para establecer, dentro del proceso de evaluación quienes son los elementos que desconocen datos de la propia evaluación.

En el caso actual, se trataría de una modificación de prueba de ciego único, dado que los sujetos de prueba (los expertos) en todos los casos desconocen los resultados de los datos, siendo el investigador el que evaluará la exactitud en función a los resultados correctos que devuelvan los expertos.

En la siguientes sección se explica el procedimiento realizado para realizar la distribución de los casos clínicos a los expertos, asegurando así la idea principal de los RCT (aleatorizar los casos).

Análisis de la distribución:

A continuación se detalla los factores que se tienen que tener en cuenta a la hora de asignar a los expertos los casos clínicos a resolver y como estos factores dependen unos de otros. Así mismo se hace referencia al uso de RCT para la asignación de estos casos.

La distribución de los casos clínicos dependerá de cuatro factores:

Número de casos clínicos disponibles (NCC): Representa el total de casos que vamos a enviar a los expertos.

Casos por experto (CE): Representa el número de casos que se va a enviar a cada experto. Este es el único valor que se calculará.

Número de expertos (NE): Representa el número total de expertos que están dispuestos a evaluar el sistema.

Número de expertos por caso (EC): Representa el número de expertos que se desearía que evaluaran cada caso, como mínimo. Este valor es importante para poder realizar una distribución de los casos.

Los factores más importantes son el número de expertos (NE), el número de expertos por caso (EC) y el número de casos clínicos disponibles (NCC) dado que son valores fijos. El valor que se calculará será el CE, para saber cuántos casos debe evaluar cada experto.

176

En el caso actual, queremos que, como mínimo, cada caso clínico sea evaluado por tres expertos, para poder cotejar los resultados con una mayor precisión (con dos, se quedaría corto). No obstante, lo ideal sería que se evaluara cada caso por más expertos, intentando también que la carga de casos por experto no sea muy elevada, pero para ello se necesitaría también por lo tanto disponer de un mayor número de expertos.

Suponiendo entonces como valores fijos el número de expertos (NE), el número de expertos por caso (EC) y el número de casos clínicos (NCC) podemos calcular el número de casos por experto con la siguiente expresión:

Las restricciones que se deben de cumplir es que el producto de NCC * EC ha de ser un múltiplo de NE, para que el cociente que da como resultado CE de un número entero.

Se recuerda que estos coeficientes son aplicables solamente a una etapa, lo que quiere decir que para la segunda etapa se debe aplicar de nuevo la fórmula.

En nuestro caso concreto, los parámetros de los que disponemos son:

o NE: 5 o EC: 3 o NCC: 20 o CE: 12

Asignación de casos a expertos:

El proceso de asignación de casos a expertos es un proceso realizado utilizando un algoritmo que permite generar esta asignación de forma aleatoria y garantizando la anonimidad de cada uno de los expertos involucrados en el proceso.

A cada experto se le asigna un ID ( que identifica al experto y a cada caso clínico, nuevamente se le asigna otro ID para identificar al propio caso ( ).

El algoritmo, dispone de los siguientes elementos:

Vector de casos clínicos: CC Vector de expertos: E

El funcionamiento del algoritmo es el siguiente:

El algoritmo, por cada caso clínico disponible en el vector CC realizará las siguientes operaciones, tres veces (debido a que EC = 3). (i = 1, i = 2, i = 3):

1. Se genera un número aleatorio (x) entre 1 y length(E) (Siendo length(E) el número de elementos del vector E).

2. Se comprueba el número de casos (E[x].numCases) que tiene asociados el elemento que se corresponde con la posición x del vector E (E[x]). Si el número de casos es mayor o igual al valor CE (que define el número máximo de casos por experto) se vuelve al paso 1. Si no lo es, se comprueba si el caso clínico actual que estamos procesando (CC[i]), ya tiene como experto asignado a E[x] (CC[i].contains(E[x]). Si lo tiene, se vuelve al paso 1, si no, continuamos al paso 3.

3. En caso de que no lo sea, significa que todavía podemos asignar a ese experto a un caso clínico concreto, por lo tanto:

a. Incrementamos el valor que nos dice el número de casos clínicos que tiene asignado dicho experto (E[x].numCases++).

177

b. Asignamos al caso clínico actual, el experto (CC[i].add(E[x])). 4. Incrementamos el contador EC (i++).

Este algoritmo, garantiza la asignación aleatoria de casos clínicos a expertos, pilar fundamental de los RCT, garantizando así la eliminación de sesgos cognitivos.

La fase de evaluación se basará en dos etapas. La primera etapa se encarga de la recolección de datos de los expertos y del sistema, y la segunda en el análisis de los resultados obtenidos por ambas partes por una serie de expertos adicionales (árbitros) que se encargan de arbitrar los resultados y establecer si, tanto los resultados de los expertos como del sistema, son correctos desde un punto de vista clínico.

Recolección de datos de evaluadores y sistema

Una vez han sido asignados los casos clínicos a los evaluadores se deben obtener estos resultados junto con los que el sistema proporcionará para todos los casos diseñados.

En primer lugar nos vamos a centrar en la recolección de datos de los evaluadores.

En esta etapa el objetivo es que el evaluador médico realice una serie de diagnósticos diferenciales y devuelva los resultados de los mismos. Los pasos a realizar son los siguientes:

1. El evaluador recibirá una serie de casos clínicos (el número dependerá de los evaluadores disponibles, del número de casos clínicos disponibles y de cuantos expertos se establezca que deben evaluar un caso clínico). Un caso clínico se compone de la presentación de una serie de síntomas o signos y de los resultados de unas pruebas diagnósticas. Algunos casos pueden tener algún tipo de información adicional.

2. El evaluador, deberá realizar el diagnóstico diferencial según la información recibida en cada caso y no se dispondrá de más información que la presentada en cada caso sobre un supuesto paciente.

3. Una vez realizado el diagnóstico para cada caso presentado, debe devolver una lista de posibles enfermedades que puedan casar con el cuadro clínico presentado en el caso. Es importante que el evaluador, basándose en sus conocimientos y experiencia médicos, realice el diagnóstico como si se encontrara frente a un paciente real en una consulta. Para poder obtener información sobre la validez del sistema que se pone a prueba por parte del evaluador, éste no debe consultar fuentes adicionales. Los resultados de dicha evaluación serán anónimos.

4. El evaluador puede realizar las anotaciones adicionales que considere sobre cada caso. Se valorarán aquellas anotaciones relacionadas con el proceso de diagnóstico.

Aparte de los evaluadores, se realizará el diagnóstico diferencial de todos los casos clínicos realizados a los evaluadores usando el sistema que trata de resolver las hipótesis planteadas en la tesis, para contrastar resultados.

Los evaluadores también indicarán la media de tiempo que les llevó la resolución de cada caso clínico planteado con el objetivo de luego comparar tiempos con el sistema.

178

Arbitraje de los resultados de evaluadores y sistema

En esta etapa, el objetivo se basa en que los expertos que actúan como árbitros, reciban un documento donde se plantea el caso clínico, y los resultados que ha arrojado tanto el sistema, como los evaluadores a los que les haya tocado diagnosticar dicho caso.

Los árbitros deberán por lo tanto, para cada resultado arrojado por los expertos o el sistema decidir si es válido o no dado el caso clínico presentado. Una vez estos documentos estén completamente rellenados, se procederá al análisis estadístico de los datos.

Como parte de la metodología se propone que el envío de los resultados a los árbitros se realice en un documento donde se muestren los resultados obtenidos para cada caso clínico sin indicar si el resultado ha sido obtenido por el sistema o por los expertos para evitar posibles sesgos.

8.2.1.2. FASE DE ANÁLISIS DE RESULTADOS

Introducción:

La fase de análisis de los resultados se centra en analizar los resultados devueltos en la fase anterior en cada una de las etapas con el objetivo de realizar los cálculos que sean necesarios y presentar los resultados finales de la evaluación.

El hecho de obtener unos determinados porcentajes que permitan identificar cuan bueno es el sistema, no tienen valor alguno si estos porcentajes no pueden ser comparados con otra serie de valores que permitan establecer si el sistema es bueno o malo. El hecho de obtener una exactitud, de, por ejemplo, un 60% no sirve de mucho si no puede compararse dicha exactitud con lo que se considerarían resultados que permitan verificar las hipótesis. ¿Es un 60% mucho? ¿Es poco?

Debido a esto es necesario por lo tanto obtener datos para el sistema, y datos con los que comparar el sistema. Estos datos con los que se comparará el sistema vienen datos por los valores de los expertos. Es por lo tanto importante recalcar que se obtendrán, por una parte, datos para los expertos y por otra, para el sistema.

Técnicas de medición y análisis:

Para la evaluación del sistema se hará uso de técnicas de evaluación de clasificadores binarios, ya que, internamente el sistema se podría considerar como un clasificador de este tipo, dado que si consideramos cada enfermedad de forma independiente, el sistema trata de establecer si esa enfermedad es un diagnóstico válido para el caso o no (clasificación binaria).

Otra razón para considerar cada enfermedad individualmente es que cada enfermedad es muy compleja y pueden tener distintos valores de las métricas, tanto para los expertos como para el sistema, debido a lo específico de los síntomas de la enfermedad, etc.

Además, dada la naturaleza del dominio establecido, el tipo de técnica estadística a utilizar encaja perfectamente con los distintos valores que se obtienen de la extracción de resultados devueltos por los evaluadores.

La evaluación por lo tanto de la exactitud diagnóstica del sistema será medida usando como métricas de medición fundamentalmente Precision and Recall (Makhoul et

179

al., 1999), Specifity y Accuracy, y por último, el coeficiente de correlación de Matthews (Matthews, 1975; Baldi et al., 2000).

Estas métricas, ampliamente usadas en las biociencias (Jensen & Nielsen, 2007; Riffenburgh, 2006), sirven para evaluar distintos aspectos sobre la precisión diagnóstica del sistema propuesto.

Precision y Recall son métricas extendidas que pueden ser vistas como extensiones de otra de las métricas propuestas: accuracy. La métrica Accuracy es una métrica simple que calcula la fracción de instancias para las cuales se ha devuelto el resultado correcto.

En el uso de Precision y Recall el conjunto de etiquetas posibles para una instancia dada se dividen en dos subconjuntos, uno de los cuales es considerado relevante para los objetivos de la métrica. Recall se calcula como la fracción de instancias correctas entre todas las instancias que de hecho pertenecen al conjunto relevante, mientras que la precisión es la fracción de instancias correctas entre aquellas que el algoritmo cree que pertenecen al conjunto relevante.

En resumen, el parámetro Precision se puede ver como una medida de la exactitud o fidelidad, mientras que Recall es una medida de completitud.

Por otra parte, la especificidad permite observar como de bueno (específico) es el clasificador para la enfermedad que se está midiendo.

Finalmente, el uso del coeficiente de correlación de Matthews (MCC), es un coeficiente que mediante la aplicación de una media armónica entre varios de los parámetros que permiten obtener las métricas de Precision, Recall, Accuracy y Specifity (PRAS), da un resultado que permite establecer la exactitud del sistema de forma más global, sin necesidad de centrarse en uno de los factores de PRAS.

MCC es usado generalmente en aprendizaje automático como una medida de la calidad de un clasificador binario. Toma en cuenta los valores positivos verdaderos y positivos falsos y los negativos, y es considerado generalmente como una medida balanceada que puede ser usada incluso si las clases tienen tamaños muy diferentes. El coeficiente MCC es en esencia un coeficiente de correlación entre las clasificaciones binarias observadas y predichas.

El valor que devuelve MCC es un valor entre -1 y 1, donde el valor 1 representa una predicción perfecta, 0 una predicción aleatoria y -1 una predicción inversa.

El uso de MCC en la metodología actual ha sido transformado para devolver valores en términos de tanto por ciento, considerando como valores que tengan sentido aquellos superiores al 50%, dado que el 50% es el punto donde el coeficiente MCC da 0 y por lo tanto todos los porcentajes que estén en ese valor o por debajo serán considerados inexactos.

Aplicación de las técnicas:

La aplicación de las métricas comentadas al dominio presentado en esta tesis para obtener una evaluación de la exactitud del sistema se tiene que plantear desde el punto de vista de las enfermedades, tratando de obtener los parámetros de Precision, Recall, Accuracy, Specifity (PRAS) y MCC para cada enfermedad. Esta aplicación se hará, por cada enfermedad, para el sistema, y para los expertos, para determinar como de bueno es el sistema al clasificar la enfermedad, y como de bueno es el experto al clasificarla.

180

Una vez obtenidos los valores para todas las enfermedades que conforman la base de conocimiento del sistema, se realizarán una serie de cálculos adicionales para establecer la exactitud final del sistema, y de los expertos, al completo. Concretamente, estos cálculos serán tanto la media global del sistema o los expertos (usando como elementos de la población las enfermedades).

A continuación se plantea de forma genérica el proceso que se llevará a cabo para analizar estos resultados, planteando los componentes estadísticos concretos así como estableciendo como se calculan las distintas métricas.

Planteamiento del análisis

El análisis que se plantea para medir la exactitud del sistema se basa en utilizar las métricas de evaluación de clasificadores binarios (PRAS y MCC) citadas anteriormente aplicadas a cada enfermedad de la base de conocimiento, para finalmente obtener una media, dando lugar así a la exactitud final del sistema y de los expertos.

La aplicación de PRAS y MCC a cada enfermedad de la base de conocimiento permite obtener una serie de datos que nos dicen como de bueno es el sistema o el experto a la hora de diagnosticar cada una de las enfermedades, pudiendo calcularse una media para la exactitud global en función de la exactitud de cada enfermedad.

A continuación se va a plantear como se hará el cálculo, por enfermedad, de PRAS para el sistema, y el cálculo de PRAS para cada par enfermedad-experto.

Cálculo de PRAS para cada par sistema-enfermedad:

El cálculo de los valores PRAS para el sistema se realizan tomando como referencia, por una parte los valores del sistema, por otro los valores de los resultados de los expertos y el sistema tras el arbitraje (resultados que se consideran verificados).

Para cada enfermedad de la base de conocimiento se debe generar una matriz de confusión como la de la Tabla 15. Esta tabla permite agrupar los datos específicos de las diferentes métricas que se van a aplicar para obtener la exactitud del sistema (Precision, Recall, Specifity y Accuracy).

Sistema Positivo Negativo

Expertos Positivo A (TP) B (FN) Negativo C (FP) D (TN)

Tabla 15. Tabla de muestra para el cálculo de las métricas (Sistema)

Cada uno de los valores especificados en esta tabla se obtiene de la siguiente forma:

A (TP: True Positive): Valores comunes al sistema y los expertos. Es la intersección del conjunto de enfermedades diagnosticadas por el sistema y los resultados del proceso de arbitraje. Implica que el sistema ha diagnosticado la enfermedad y el arbitraje lo corrobora.

B (FN: False Negative): Valores que el sistema no ha predicho corretamente. Es la diferencia entre los conjuntos de arbitraje y sistema. Implica que el sistema no ha predicho la enfermedad cuando el arbitraje corrobora que si que era.

C (FP: False Positive): Valores incorrectamente predichos por el sistema. Es la diferencia entre los conjuntos de sistema y arbitraje. Implica que el sistema ha diagnosticado la enfermedad pero el arbitraje no lo ha corroborado.

181

D (TN: True Negative): Enfermedades de la base de conocimiento que no han sido diagnosticadas ni por el sistema ni por el arbitraje. Es la diferencia entre el conjunto que representa a la base de conocimiento en su totalidad y la unión de los conjuntos de arbitraje y sistema.

Los elementos de la tabla también se pueden representar mediante teoría de conjuntos. Supongamos el conjunto SIS que contiene los casos clínicos donde el sistema ha diagnosticado la enfermedad y el conjunto ARB donde los expertos la han diagnosticado (tras arbitraje). El conjunto TOT representa el total de los casos clínicos. Cada valor se obtendría de la siguiente forma:

A: SIS ∩ ARB C: SIS – ARB B: ARB – SIS D: TOT – (SIS ∪ ARB)

A partir de estos valores podemos calcular los valores finales de Precision, Recall, Specifity y Accuracy:

Una vez calculados dichos valores para todas las enfermedades, se puede calcular una media que nos dará una idea de la exactitud global del sistema.

Cálculo de PRAS para cada par experto-enfermedad:

Para cada enfermedad, se debe calcular la exactitud que ha tenido cada experto que haya participado en la evaluación a la hora de diagnosticar dicha enfermedad. Esto permite saber cómo de buenos son los expertos a la hora de diagnosticar cada enfermedad, y por lo tanto, poder comparar a los expertos (por separado, la media, el mejor y el peor) con el sistema, pudiendo permitir esto verificar las hipótesis de exactitud diagnostica.

El cálculo de los valores PRAS para cada experto se realiza tomando por una parte los resultados de dicho experto como referencia, y por otra el arbitraje sobre estos resultados de los expertos y el sistema (la verificación de sus resultados).

Las métricas usadas, siguen siendo las mismas (PRAS). En este caso la tabla que permite calcular estos valores es la que se presenta en la Tabla 16.

Experto Positivo Negativo

Arbitraje Positivo A (TP) B (FN) Negativo C (FP) D (TN)

Tabla 16. Tabla de muestra para el cálculo de las métricas (Expertos)

Expresándolo mediante teoría de conjuntos tendríamos las siguientes operaciones para calcular los valores de la tabla, que dan lugar a los valores PRAS siguiendo el mismo esquema expuesto antes. Los conjuntos posibles son CPE (Casos donde el experto ha diagnosticado la enfermedad), ARB (Casos donde el arbitraje ha señalado que los diagnósticos del experto son correctos) y CC (Casos donde el experto ha participado). Se

182

debe tener en cuenta que CC es un subconjunto de TOT, ya que el sistema ha participado en todos los casos clínicos, y el experto, no necesariamente. Para finalizar, cabe destacar que ARB es equivalente a EXP cuando se mide la exactitud del sistema, ya que representa los resultados arbitrados (tanto los del sistema como los de los expertos).

A: CPE ∩ ARB B: CPE – ARB C: ARB – CPE D: CC – (CPE ∪ ARB)

Cálculo de MCC:

El parámetro MCC es calculado en los dos casos anteriores al igual que PRAS, pero se comenta su cálculo de forma separada para evitar repeticiones.

El cálculo de MCC se basa en la utilización de los parámetros de la matriz de confusión para calcular el coeficiente que permitirá obtener una medida más centralizada de los parámetros anteriores. El cálculo de MCC, como se ha comentado previamente, proporciona valores entre -1 y 1, y la forma de calcularlo se basa en el uso de los valores de la matriz de confusión (ver Tabla 15 o Tabla 16).

La fórmula para el cálculo del MCC es:

El valor, entre -1 y 1 será adaptado a una escala de 0 a 100% como se ha comentado previamente.

Aplicación del arbitraje:

Dependiendo del número de árbitros que se encarguen de comprobar los resultados de los expertos se debe plantear un análisis de la siguiente forma:

Análisis de resultados de cada árbitro por separado Análisis de resultados de unión de arbitrajes Análisis de resultados de intersección de arbitrajes

Dado que el arbitraje es realizado con el objetivo de validar, tanto los resultados proporcionados por los expertos como los resultados proporcionados por el sistema, se debe tener en cuenta a la hora de realizar el análisis de los resultados.

Por una parte, se deben medir los parámetros PRAS por separado según los resultados de cada arbitraje, obteniendo una medida de Precision, Recall, Accuracy y Specifity para cada árbitro. Esto permitirá analizar, según el arbitraje realizado, los resultados obtenidos para cada medida.

Aparte del arbitraje individual, se deben medir los parámetros PRAS usando la unión de los resultados de todos los arbitrajes. La unión de los arbitrajes permite establecer el marco menos restrictivo de análisis de resultados, dado que los resultados considerados como válidos se incrementarán al realizar la unión de los distintos arbitrajes, dando lugar a una evaluación de cuan bueno es el sistema (y los expertos), en el mejor de los casos posibles.

Por otra parte, al contrario que en la unión, se debe hacer la intersección de los arbitrajes para poder medir nuevamente los parámetros PRAS. La intersección permite definir un conjunto de resultados muy restringido, ya que solo se considerarán como

183

posibles aquellos donde todos los árbitros hayan estado de acuerdo, dando lugar a una evaluación de cuan bueno es el sistema (y los expertos), en el que se podría considerar el “peor caso posible”, o más estricto.

Análisis de correlación entre árbitros:

El hecho de utilizar más de un árbitro para medir la exactitud del sistema según varios puntos de vista garantiza precisamente unas medidas más fiables ya que utilizando un solo árbitro no podríamos estar seguros de si su criterio es correcto o no, y la utilización de varios permite obtener un criterio más equilibrado.

Sin embargo, se debe también analizar cuál es la correlación existente entre los árbitros, con el objetivo de poder medir si sus criterios de diagnóstico son similares o no (¿Han dado como válidas o inválidas las mismas enfermedades?).

Por ello se plantea una medida de correlación entre los árbitros, que permitirá responder a estas preguntas.

El cálculo de la correlación se basa en, para cada caso clínico arbitrado, obtener los conjuntos de enfermedades que ambos han dado como válidas e inválidas. Esto permitirá establecer el nivel de acuerdo entre los árbitros, tanto para las respuestas que han dado como válidas como las que no.

Interpretación de resultados:

Una vez las distintas métricas han sido calculadas, cada una ofrece una interpretación, que nos permite obtener información sobre el sistema o los expertos, según el valor que haya tomado dicha métrica.

A continuación se ofrece una breve explicación sobre cada una de ellas, y la interpretación que ofrece.

Precision: Mide la proporción en los que los resultados aportados por el sistema son validados por el arbitraje, es decir, el porcentaje de predicciones positivas realizadas por el sistema que son correctas. Es útil para comprobar que los resultados positivos por el sistema son correctos, pero no para saber si lo son los negativos, ya que no tiene en cuenta los diagnósticos no emitidos (considerados negativos) por el sistema.

Recall (Sensitivity): Mide la proporción de casos positivos diagnosticados por el sistema, o lo que es lo mismo, el porcentaje de pacientes enfermos que serán diagnosticados correctamente por el sistema. Un valor alto en esta métrica indica que la falta de diagnóstico del sistema para esta enfermedad puede utilizarse como criterio para descartarla como diagnóstico. El parámetro Recall también puede ser llamado Sensitivity. Recall hace referencia generalmente a la métrica usada en industria para productos defectuosos (Recall rate ~= ratio de devolución), mientras que en el campo médico sería más correcto hablar de sensibilidad.

Accuracy: Mide la proporción total de aciertos del sistema, tanto de diagnósticos positivos como negativos. Es similar a la precisión, pero más completa, ya que incluye también los resultados negativos (enfermedades no predichas por el sistema). Es útil como métrica sencilla del funcionamiento general del sistema, pero no indica qué tipo de fallos son más comunes (falsos positivos o falsos negativos), por lo que se completa con el resto de medidas.

Specifity: La métrica complementaria a la sensibilidad, mide la proporción de casos en los que el diagnóstico no es correcto cuando el sistema no ha diagnosticado la enfermedad, es decir, el porcentaje de pacientes sanos

184

correctamente diagnosticados por el sistema. Un valor alto en esta métrica hace que el sistema sea bueno para confirmar un diagnóstico, ya que en pocos casos se predirá estando el paciente sano.

MCC: El valor de MCC permite obtener una medida más balanceada basada en los parámetros de PRAS. Esta medida nos permite hacernos una idea de lo que se conocería como “exactitud global” del sistema o de los expertos.

Además del análisis de estos parámetros, se procederá a estudiar la significancia estadística de los resultados entre los expertos y el sistema con el objetivo de validar desde un punto de vista estadístico que los resultados proporcionados son válidos. Para ello se utilizará la T-Student con el objetivo de comparar grupos independientes de observaciones y ver si existen estas diferencias significativas (Pértega & Pita, 2001).

8.2.2. EVALUACIÓN DE LA COMPLEJIDAD COMPUTACIONAL. RENDIMIENTO

La evaluación de la complejidad temporal y espacial del sistema (rendimiento) se centra en medir los tiempos de ejecución y consumos de memoria del sistema. El objetivo es determinar el tiempo o consumo de memoria que el sistema emplea para resolver un caso clínico, y poder comparar por lo tanto estos valores con otros de referencia, pudiendo así verificar o no las hipótesis planteadas.

A continuación se describirán los pasos a realizar para la toma de medidas, así como “que medir”.


El experimento a llevar a cabo para evaluar la complejidad computacional del sistema se basa en medir, para los distintos casos clínicos presentados en la metodología de evaluación de la eficiencia diagnóstica, el tiempo y consumo de memoria del sistema.

Dado que el sistema, en función de que haya habido ejecuciones previas o no (motor de inferencia inicializado o no inicializado), arroja resultados en términos computacionales distintos, se establecen que todas las medidas deban ser tomadas tanto cuando el motor de inferencia ha sido inicializado (medida MII) como cuando no (medida MINI).

Por lo tanto, para cada caso clínico que el sistema deba resolver, se deberán tomar medidas de los tiempos de ejecución y consumo de memoria en los dos casos descritos anteriormente (MII y MINI).

Así mismo, para garantizar que los datos sean lo más precisos posible, se establece como métrica de medida adicional, que cada medida, ha de tomarse un mínimo de 10 veces, para evitar posibles valores atípicos, siendo usadas las medias como medidas a la hora de realizar posibles comparaciones o representaciones gráficas.

De esta forma, se establece que se deben tomar las siguientes medidas: Supongamos que el sistema debe ejecutar un número “C” de casos clínicos. Las medidas a tomar, son:

Siendo, como se ha comentado, C, el número de casos a ejecutar. El 10 representa las 10 medidas para cada caso que se deben tomar para evitar valores atípicos, y el 2 representa el hecho de que las medidas han de tomarse tanto con el motor de inferencia inicializado (MII) como con el motor de inferencia no inicializado (MINI).

185


El proceso de análisis de resultados consiste fundamentalmente en comparar las medidas obtenidas del sistema con las medidas obtenidas por los expertos. Esto solo es aplicable para los tiempos de resolución de los casos clínicos, ya que el consumo de memoria no es comparable.

El análisis de los tiempos de resolución de los casos comprende:

Comparación entre los tiempos de resolución de los expertos. Comparación del sistema (MII y MINI), por cada caso clínico, con los

expertos que hayan resuelto dicho caso (sin identificar a los expertos). Comparación del sistema (MII y MINI), por cada caso clínico, con los

expertos que hayan resuelto dicho caso (identificando a los expertos). Comparación entre las medidas MII y MINI desde el punto de vista

de consumo de memoria del sistema Análisis cualitativo del consumo de memoria tanto en modalidad

MII como MINI.

8.2.3. EVALUACIÓN DE LAS TECNOLOGÍAS

Como se ha mencionado anteriormente, la evaluación tecnológica de un sistema es una medida cualitativa sobre la calidad de los métodos o técnicas empleados para el diseño y desarrollo de un sistema concreto. La dimensión cualitativa y no cuantitativa de esta evaluación viene dada por la dificultad de establecer un sistema que permita evaluar mediante puntos, probabilidades o pesos una tecnología concreta, incluso aunque esta sea aplicada a un dominio determinado.

Es por eso, que esta evaluación debe basarse en un análisis de las técnicas más empleadas para el diseño y desarrollo de los sistemas iguales o similares al que se plantean, para extraer como conclusiones de ese análisis una serie de ventajas y desventajas de cada una de las tecnologías, y de esa forma ser capaz de realizar una valoración objetiva sobre la eficiencia tecnológica de la tecnología que ha sido escogida para el desarrollo del sistema.

Es por eso, que esta evaluación se debe realizar siguiendo los pasos o procedimientos qu0e se detallan a continuación en las siguientes subsecciones.


El experimento a realizar para evaluar las capacidades tecnológicas de las tecnologías aplicadas al diseño y desarrollo del sistema se basa en la búsqueda de referencias de sistemas que hayan sido diseñados o desarrollados en el pasado y que tengan relación con el dominio tratado, se enumeren las principales técnicas o tecnologías empleadas.

Una vez realizada la enumeración, se debe hacer un análisis a partir de las mismas fuentes consultadas previamente, para establecer las características positivas que hacen que dichas tecnologías sean útiles a la hora de ser aplicadas para el desarrollo de los sistemas, y las características negativas por las que sin embargo, no se recomienda su uso. Se recomienda la generación de una tabla que indiquen las características positivas y negativas de forma resumida.

186


La fase de análisis de resultados consistirá en realizar una tabla donde se compare la tecnología empleada con las tecnologías analizadas, tratando de concluir la evaluación con los principales aspectos, positivos y negativos de la tecnología empleada en comparación con otras.

8.3. RESULTADOS EVALUACIÓN

En las siguientes secciones se realiza una evaluación del sistema MDSS-OPM, el cual ha sido desarrollado para permitir la verificación de la presente tesis. MDSS-OPM pretende, con los resultados que arroje, permitir la verificación de todas las hipótesis planteadas. A continuación por lo tanto se evaluarán los aspectos mencionados previamente: eficiencia diagnóstica, computacional, y análisis de técnicas empleadas).

8.3.1. EVALUACIÓN DIAGNÓSTICA

Tal y como se ha comentado previamente en la metodología de la evaluación diagnóstica, el proceso de evaluación del sistema generado para la verificación de las hipótesis planteadas en esta tesis, consiste en la generación de una serie de casos clínicos, su resolución por parte de unos evaluadores expertos en el dominio médico, y un arbitraje posterior que garantiza la validez de los resultados tanto del sistema, como de los evaluadores.

En este caso, siguiendo los principios establecidos por la metodología descrita previamente, se han utilizado un total de cinco evaluadores (como evaluadores de los casos clínicos) y dos árbitros para el proceso de arbitraje. Se considera experto por lo tanto a cualquier médico que haya participado, bien sea en el proceso de evaluación, o en el proceso de arbitraje.

Se han generado además un total de 20 casos clínicos para ser resueltos por los expertos (NCC: Número de casos clínicos: 20), asegurándose de que cada caso clínico fuera resuelto por al menos, tres expertos (valor de EC: Expertos por caso: 3).

Esto implica que cada uno de los cinco expertos (NE: Número de expertos: 5), le corresponden un total de 12 casos (CE: Casos por experto: 12).

Los casos clínicos generados pueden ser consultados en los Anexos, en la sección de Evaluación diagnóstica, subsección de Enunciados de casos clínicos. Estos casos clínicos han sido generados por el doctorando y validados por el Dr. Miguel Ángel Mayer.

8.3.1.1. EXPERTOS

A continuación, se muestra la información referente a los evaluadores y árbitros que han participado en el proceso. Cada uno de estos expertos está representado por un código en los documentos referentes a las soluciones que han proporcionado a los casos clínicos. Este código ha sido utilizado para representar la información de la resolución (o arbitraje) que han proporcionado a los casos clínicos, garantizando así su anonimato, siendo cada experto el único que conoce su código, aparte del propio doctorando.

Tanto los evaluadores como los árbitros ejercen la profesión de medicina en distintos servicios o institutos de salud de tres comunidades autónomas (Cantabria, Cataluña y Andalucía), siendo la especialidad común a todos los expertos “Medicina Familiar y Comunitaria”, excepto en el caso de la Dra. María Teresa Fábregas Ruano cuya especialidad es “Hematología y Hemoterapia”.

187

En la Tabla 17 se muestran los diversos datos de los evaluadores, y en la Tabla 18 los datos de los árbitros.

ID Profesional Nombre Apellidos Institución y Puesto Edad Sexo

6157 Nieves Ortíz-Roldan

Rodríguez Servicio Cántabro de Salud 28 F

39/06033 Nuria Ovalle Residente de 4º Año en Hospital Valdecilla

(Santander) 28 F

39/6030-3 Cristina Maza Anillo Residente de 4º año HUMV 30 F

08/19060 Manuel Iglesias Institut Català de la Salut. CAP El Carmel. Barcelona 51 M

24878 Barcelona Carmen Olmos Domínguez Institut Català de la Salut 51 F

Tabla 17. Evaluadores

ID Profesional Nombre Apellidos Institución y Puesto Edad Sexo

24433 Miguel Ángel Mayer Pujadas

Director de Web Médica Acreditada. Colegio Oficial de Médicos de Barcelona. 50 M

CNP 00195805432

María Teresa Fábregas Ruano MIR 1 en el Hospital Universitario Virgen Macarena 26 F

Tabla 18. Árbitros

Cada uno de estos expertos, como se ha comentado previamente, está identificado con un código que no será revelado para mantener el anonimato en lo referente a las soluciones que cada experto proporcione a la hora de evaluar los casos clínicos o de arbitrarlos.

8.3.1.2. RESULTADOS

A continuación se muestran los resultados obtenidos de aplicar las métricas PRAS y MCC tal y como se han definido en la metodología.

Se mostrarán las gráficas que reflejan el resumen del total de resultados tras aplicar la métrica PRAS y MCC por cada arbitraje (arbitrajes individuales, unión e intersección). Las tablas que contienen los datos, y que permiten analizar a cada experto por cada enfermedad son mostradas en los anexos.

Los valores NA que se encuentren en las distintas tablas de la evaluación hacen referencia a “No Aplicable”. En determinadas circunstancias, hay enfermedades que debido a que no han sido diagnosticadas nunca por expertos o sistema, es necesario reflejar este estado mediante este código.

Resultados arbitraje (Árbitro AR-XF31):

Los resultados completos del arbitraje correspondiente al árbitro cuyo código es AR-XF31 pueden ser consultados en los anexos (Tabla 42 a Tabla 47).

De los datos expuestos, correspondientes al primer arbitraje, se pueden extraer varias gráficas significativas. La Figura 46 muestra una gráfica donde se compara la media de los datos obtenidos para el sistema (media de todas las enfermedades) con las medias para cada experto.

188

Figura 46. Sistema vs Expertos. Arbitraje (AR-XF31)

Por otra parte, la Figura 47 muestra una gráfica donde se compara a la media obtenida para el sistema con la media del experto con mayor y menor equilibrio, y la media de todos los expertos. El criterio para discernir cual tiene mejor o peor equilibrio se basa en la medición de su MCC comparándolo con el MCC medio de cada experto.

Figura 47. Sistema vs Expertos Seleccionados. Arbitraje (AR-XF31)

Resultados arbitraje (AR-TD46):

Los resultados completos del arbitraje correspondiente al árbitro cuyo código es AR-XF31 pueden ser consultados en los anexos (Tabla 48 a Tabla 53).

De los datos expuestos, correspondientes al segundo arbitraje, se pueden extraer varias gráficas significativas. La Figura 48 muestra una gráfica donde se compara la media

Sistema EX-KS0L EX-SK4V EX-KV8H EX-VH7Q EX-HQ3T

Precision 84,33% 68,26% 65,63% 65,63% 70,83% 66,94%

Recall 96,60% 74,37% 67,01% 65,90% 65,97% 70,69%

Accuracy 95,63% 90,63% 93,40% 93,75% 93,40% 90,63%

Specifity 95,89% 94,97% 98,84% 99,19% 100,00% 95,27%

MCC 94,29% 67,54% 57,61% 55,70% 60,93% 64,41%

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema vs Expertos (AR-XF31)

SistemaExperto mayorequilibrio (EX-

KS0L)

Experto menorequilibrio (EX-

KV8H)Media expertos

Precision 84,33% 68,26% 65,63% 67,46%

Recall 96,60% 74,37% 65,90% 68,79%

Accuracy 95,63% 90,63% 93,75% 92,36%

Specifity 95,89% 94,97% 99,19% 97,65%

MCC 94,29% 67,54% 55,70% 61,24%

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema vs Expertos Seleccionados (AR-XF31)

189

de los datos obtenidos para el sistema (media de todas las enfermedades) con las medias para cada experto.

Figura 48. Sistema vs Expertos. Arbitraje (AR-TD46)

Por otra parte, la Figura 49 muestra una gráfica donde se compara a la media obtenida para el sistema con la media del experto más y menos equilibrado, y la media de todos los expertos.

Figura 49. Sistema vs Expertos Seleccionados. Arbitraje (AR-TD46)

Resultados arbitraje (Unión arbitrajes):

Los resultados completos del arbitraje correspondiente a la unión de árbitros pueden ser consultados en los anexos (Tabla 54 a Tabla 59).


Precision 87,28% 67,08% 66,32% 65,63% 64,58% 56,53%

Recall 95,65% 72,22% 67,36% 67,01% 61,46% 61,11%

Accuracy 95,42% 91,32% 93,06% 95,14% 93,06% 88,89%

Specifity 95,58% 95,46% 98,25% 99,19% 99,62% 94,80%

MCC 93,88% 66,52% 59,03% 56,42% 56,99% 56,60%

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema vs Expertos (AR-TD46)


KS0L)


KV8H)Media expertos

Precision 87,28% 67,08% 65,63% 64,03%

Recall 95,65% 72,22% 67,01% 65,83%

Accuracy 95,42% 91,32% 95,14% 92,29%

Specifity 95,58% 95,46% 99,19% 97,46%

MCC 93,88% 66,52% 56,42% 59,11%

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema vs Expertos Seleccionados (AR-TD46)

190

De los datos expuestos, correspondientes a la unión de arbitrajes, se pueden extraer varias gráficas significativas. La Figura 50 muestra una gráfica donde se compara la media de los datos obtenidos para el sistema (media de todas las enfermedades) con las medias para cada experto.

Figura 50. Sistema vs Expertos. Unión de arbitrajes


Figura 51. Sistema vs Expertos Seleccionados. Unión de arbitrajes

Resultados arbitraje (Intersección de arbitrajes):

Los resultados completos del arbitraje correspondiente a la unión de árbitros pueden ser consultados en los anexos (Tabla 60 a Tabla 65).


Precision 90,90% 68,61% 69,79% 65,63% 66,67% 59,44%

Recall 94,49% 69,50% 65,35% 65,90% 60,76% 60,39%

Accuracy 95,83% 90,28% 92,36% 93,75% 92,71% 88,89%

Specifity 96,86% 95,97% 99,13% 99,19% 100,00% 95,55%

MCC 94,60% 65,48% 59,14% 55,70% 57,43% 57,29%

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema vs Expertos (Unión)


KS0L)


KV8H)Media expertos

Precision 90,90% 68,61% 65,63% 66,03%

Recall 94,49% 69,50% 65,90% 64,38%

Accuracy 95,83% 90,28% 93,75% 91,60%

Specifity 96,86% 95,97% 99,19% 97,97%

MCC 94,60% 65,48% 55,70% 59,01%

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema vs Expertos Seleccionados (Unión)

191

De los datos expuestos, correspondientes a la intersección de arbitrajes, se pueden extraer gráficas significativas. La Figura 46 muestra una gráfica donde se compara la media de los datos obtenidos para el sistema (media de todas las enfermedades) con las medias para cada experto.

Figura 52. Sistema vs Expertos. Intersección de arbitrajes


Figura 53. Sistema vs Expertos Seleccionados. Intersección de arbitrajes


Precision 80,71% 66,74% 62,15% 65,63% 68,75% 64,03%

Recall 97,92% 77,43% 69,44% 67,01% 66,67% 71,32%

Accuracy 95,21% 91,67% 94,10% 95,14% 93,75% 90,63%

Specifity 94,65% 94,43% 97,96% 99,19% 99,62% 94,62%

MCC 93,59% 68,82% 57,64% 56,42% 60,48% 63,64%

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema vs Expertos (Intersección)


KS0L)


KV8H)Media expertos

Precision 80,71% 66,74% 65,63% 65,46%

Recall 97,92% 77,43% 67,01% 70,38%

Accuracy 95,21% 91,67% 95,14% 93,06%

Specifity 94,65% 94,43% 99,19% 97,16%

MCC 93,59% 68,82% 56,42% 61,40%

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema vs Expertos Seleccionados (Intersección)

192

Resultados correlación árbitros:

El nivel de correlación entre los árbitros permite establecer el grado de acuerdo entre estos que se hayan encargado de validar tanto los resultados de los expertos como los del sistema. Este grado de acuerdo se basará tanto en los resultados que los árbitros consideran correctos, como en aquellos que consideran incorrectos.

Un alto porcentaje de correlación es indispensable para permitir asegurar que por lo tanto sus arbitrajes tienen un cierto sentido. Un nivel de correlación bajo (consideramos un nivel de correlación bajo aquel por debajo de 2/3 (66%) donde implicaría que por cada tres casos, en dos están en acuerdo por uno en desacuerdo) daría lugar a resultados con cierta incoherencia en la evaluación final del sistema.

A continuación, se muestran los resultados que se han obtenido de las medidas de correlación para cada caso clínico de los 20 resueltos, indicando así mismo cual ha sido la media final. La Figura 54 muestra el gráfico de los niveles correspondientes a los casos del 1 al 10 y la Figura 55 de los casos del 11 al 20.

Figura 54. Nivel de correlación entre árbitros. Caso del 1 al 10

66

%

80

%

10

0%

83

%

10

0%

10

0%

10

0%

88

%

10

0%

10

0%

88,35%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 2 3 4 5 6 7 8 9 10

Nivel de Correlación (Caso 1 a 10)

Nivel Correlación Media

193

Figura 55. Nivel de correlación entre árbitros. Caso del 11 al 20

Como se puede observar en los gráficos, se obtiene un nivel de correlación medio del 88.35%, el cual es superior al 66% que establecimos como margen inferior. Esto permite establecer que el nivel de correlación de los árbitros es suficientemente alto para permitir que los datos obtenidos en el proceso de evaluación puedan ser utilizados directamente.

8.3.1.3. CONCLUSIONES

Existen diversas conclusiones que se pueden extraer de los datos mostrados previamente. En primer lugar se debe destacar que el análisis y la validación de los datos de la evaluación son posibles gracias al nivel de correlación existente entre los árbitros, donde se ha obtenido un 88.35% de correlación.

Gracias a este dato, se procederá a realizar un análisis (que dará lugar a las conclusiones), sobre los resultados globales obtenidos. A continuación se realizará, una serie de análisis a nivel de enfermedad (a través de las tablas de datos al completo), para ser capaz de discernir que enfermedades son aquellas que han destacado a nivel de resultados, y porque.

Se comienza por lo tanto con el análisis de los resultados "globales".

Analizando los resultados de los arbitrajes realizados por los árbitros AR-XF31 y AR-TD46 (tanto por separado, como en la unión y en la intersección) vemos que el sistema consigue vencer a todos los expertos en las métricas de Precision, Recall, Accuracy y MCC. Esto implica que el sistema es globalmente mejor (dado que tanto el MCC como el Accuracy definen la “globalidad”, si bien el MCC es una medida balanceada).

En lo referido a la métrica "Precision", esta nos indica que a pesar de que el sistema proporcione muchos resultados con probabilidad baja, estos, podrían ser correctos (los indicios permiten explicar las enfermedades propuestas). Además, dado que tiene un

87

%

90

%

10

0%

50

%

10

0%

10

0%

66

%

10

0%

57

%

10

0%

88,35%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

11 12 13 14 15 16 17 18 19 20

Nivel de Correlación (Caso 11 a 20)

Nivel Correlación Media

194

Recall alto, es especialmente bueno en lo que se refiere a la sensibilidad, que era el objeto principal del sistema (proporcionar listas grandes de diagnósticos posibles, aunque estos tengan una probabilidad realmente baja). La única métrica donde el sistema pierde respecto a los expertos es en Specifity, dado que pierde en la media de todos los expertos, y más concretamente, en los expertos EX-SK4V, EX-KV8H y EX-VH7Q. Esto implica que los expertos son más selectivos a la hora de proporcionar diagnósticos con una probabilidad más alta de que acierten (algo lógico dado que sensibilidad es bastante menor). Estos resultados son aplicables a ambos árbitros (y a su unión e intersección), si bien, los valores difieren ligeramente de un árbitro a otro y a sus combinaciones.

Desde un punto de vista más estadístico es necesario analizar estos resultados globales. Para ello, se ha realizado una T-Student para las distintas métricas medidas (MCC, Precision, Recall, Accuracy y Specifity) con el objetivo de verificar si existen diferencias significativas para cada métrica entre los resultados arrojados por el sistema que permitirá verificar las hipótesis y la media de los expertos.

Dado que se tenían varios esquemas (arbitrajes) posibles sobre los que realizar la T-Student, se ha optado por escoger el arbitraje intersección, ya que este es el que proporciona un mejor resultado a los expertos respecto al sistema, y por lo tanto, el hecho de que existieran diferencias significativas en este esquema, al ser el más restrictivo, hará que automáticamente estas diferencias se mantengan o mejoren los resultados positivos del sistema en el resto de esquemas (menos restrictivos).

El análisis de los datos utilizando la distribución T-Student permitirá como se ha comentado ver si existen diferencias significativas. Por convenio, se usará una confianza del 95% (0.05). Las dos hipótesis que se establecen para verificar las diferencias significativas son la hipótesis nula (no existen diferencias significativas) y la hipótesis experimental (si existen diferencias significativas) siendo verificable únicamente una de ellas con una confianza o probabilidad del 95% (para la verificación) y del 5% (para el rechazo) respectivamente

A continuación se exponen los resultados obtenidos para cada métrica.

Precision:

El estudio de diferencias significativas en la métrica Precision mediante T-Student ofrece los resultados expuestos en la Tabla 19:

Media ( )

Desviación Estándar ( )

T-Student Diferencias Significativas

Sistema 0,8071 0,29042 (t(46) = -1,850, p < 0.05)

Media Expertos 0,6546 0,28082 Tabla 19. Resultados del análisis estadístico de Precision

Como se puede observar en la tabla anterior, con una probabilidad del 95% se rechaza la hipótesis experimental, verificando la hipótesis nula: No existen diferencias significativas.

195

Recall:

El estudio de diferencias significativas en la métrica Recall mediante T-Student ofrece los resultados expuestos en la Tabla 20:

Media ( )



Sistema 0,9792 0,31920 (t(46) = -4,127, p < 0.05)

Media Expertos 0,7038 0,07058 Tabla 20. Resultados del análisis estadístico de Recall

En este caso, en Recall, tal y como se muestra en la tabla anterior, con una probabilidad del 95% se rechaza la hipótesis nula, verificando la hipótesis experimental: Existen diferencias significativas.

Accuracy:

El estudio de diferencias significativas en la métrica Accuracy mediante T-Student ofrece los resultados expuestos en la Tabla 21:

Media ( )



Sistema 0,9521 0,06997 (t(46) = -1,078, p < 0.05)

Media Expertos 0,9306 0,06833 Tabla 21. Resultados del análisis estadístico de Accuracy

En la medida de Accuracy, con una probabilidad del 95% se rechaza la hipótesis experimental, verificando la hipótesis nula: No existen diferencias significativas.

Specifity:

El estudio de diferencias significativas en la métrica Specifity mediante T-Student ofrece los resultados expuestos en la Tabla 22:

Media ( )



Sistema 0,9465 0,08515 (t(46) = 1,331, p < 0.05)

Media Expertos 0,9716 0,03590 Tabla 22. Resultados del análisis estadístico de Specifity

En el caso de Specifity, con una probabilidad del 95% se rechaza la hipótesis experimental, verificando la hipótesis nula: No existen diferencias significativas.

MCC:

El estudio de diferencias significativas en la métrica MCC mediante T-Student ofrece los resultados expuestos en la Tabla 23:

Media ( )



Sistema 0,9359 0,36329 (t(46) = -4,065, p < 0.05)

Media Expertos 0,6187 0,08975 Tabla 23. Resultados del análisis estadístico de MCC

196

En la tabla anterior se comprueba como en el caso del MCC, con una probabilidad del 95% se rechaza la hipótesis nula, verificando la hipótesis experimental: Existen diferencias significativas.

Como se puede observar en los resultados de las T-Student, solo los parámetros de Recall y MCC muestran diferencias significativas. Dado que MCC es el parámetro que mide la globalidad, esto nos permite por lo tanto saber que, dado que el MCC del sistema es mayor que la media de los expertos y que estadísticamente tiene significado, el sistema proporciona resultados buenos de forma global.

El principal parámetro a estudiar era la sensibilidad (Recall), dado que estudia como de sensible es el sistema y si hay diferencias significativas entre la sensibilidad de este y los expertos, obteniendo mediante el análisis estadístico que sí que hay diferencias entre ambos.

Si se realiza un análisis detallado, a nivel de enfermedad, se puede obtener una serie de datos que permiten ver el comportamiento tanto del sistema como de los expertos por cada enfermedad diagnosticada.

El sistema es capaz de obtener resultados de todas las métricas prácticamente perfectos en casi todas las enfermedades. Debido a estos resultados, es más sencillo hablar de aquellas enfermedades donde el sistema no ha ganado a los expertos (a su media, por simplificación), e indicar en qué casos esta media de los expertos lo han superado, y en que métricas, analizando que implicaciones tiene el hecho de que la media de los expertos hayan superado al sistema en estas métricas. Dado que nuevamente se podrían usar varios esquemas (arbitrajes individuales, unión e intersección), se ha decidido utilizar como valor comparativo la intersección, dado que como se ha comentado previamente es el esquema que más penaliza al sistema y más premia a los expertos, siendo por lo tanto el peor de los casos y sobre el que más interés existe al realizar el análisis.

La Tabla 24 muestra por lo tanto un resumen, indicando las enfermedades donde el sistema ha obtenido resultados peores en al menos una de las métricas con respecto a la media de los expertos (en el esquema de intersección arbitrajes), y la implicación/explicación asociada a cada caso. En la tabla, las métricas afectadas se indicarán por sus respectivas letras (P: Precision, R: Recall, A: Accuracy, S: Specifity, M: MCC).

Como se puede observar en dicha tabla, existen un total de 8 enfermedades de las 24 posibles sobre las que se han realizado mediciones en las que los expertos son capaces de superar al sistema en al menos una de las métricas propuestas (esto supone que el sistema gana en todas las métricas en al menos un 66% de los casos).

Las implicaciones a nivel de cada enfermedad son mostradas en la tabla, aunque se debe destacar que siendo la métrica MCC la que mide “el global” sobre el que se está rigiendo esta evaluación, esto implica que la media de los expertos solo habría conseguido vencer (de forma individual) al sistema en 2 (Faringitis y Sinusitis) casos de los 24 posibles, representando que el sistema ha obtenido un 91.66% de aciertos en el total de las enfermedades tomando el MCC como indicador global.

Debe además destacarse nuevamente que estos resultados se corresponden a los datos extrapolados de la intersección de arbitrajes, la cual representa el peor de los casos posibles para el sistema y el mejor para los expertos, con lo cual, este mismo análisis en cualquier de los otros casos (arbitrajes individuales y unión) mostrará resultados iguales o mejores.

197

Enfermedad Métricas Afectadas

Implicaciones/Consideraciones

Pielonefritis S Implica que los diagnósticos de los expertos de Pielonefritis, han sido validados por correctos más que los que ha arrojado el sistema. Puede deberse a que los expertos lo hayan diagnosticado en pocas ocasiones o a una mayor certeza a la hora de dar el diagnóstico.

Sinusitis P, A, S, M La medida de Precision indica que el experto ha proporcionado la Sinusitis como resultado que los árbitros han considerado válidos en más ocasiones que el sistema. Accuracy indica que los expertos han acertado en más ocasiones al incluir (o no incluir) la Sinusitis en sus diagnósticos que el sistema. Respecto a la Specifity: Ver Pielonefritis. En el caso de MCC, los expertos han obtenido un mejor resultado global que el sistema.

Faringitis P, A, S, M Ver argumentación Faringitis. Brucelosis S Ver argumentación Pielonefritis.

Gastroenteritis R Implica que los diagnósticos de Gastroenteritis proporcionados por los expertos han sido dados en más casos que finalmente eran correctos. Por lo tanto, los expertos los han proporcionado, mientras que el sistema no.

Fiebre Tifoidea S Ver argumentación Pielonefritis. Bronquitis P, A, S Ver argumentaciones de Precision, Accuracy y Specifity de casos

anteriores (Sinusitis por ejemplo). Laringitis P, A, S Ver argumentaciones de Precision, Accuracy y Specifity de casos

anteriores (Sinusitis por ejemplo). Tabla 24. Enfermedades donde el sistema pierde en alguna métrica (intersección de arbitrajes)

Para finalizar, a modo de resumen, podemos afirmar que el sistema que permite la verificación de las hipótesis planteadas proporciona un alto rendimiento diagnóstico. Dado que el objetivo principal era que el sistema proporcionara resultados, incluso aunque estos fueran poco probables (gran sensibilidad), este objetivo se ha visto cumplido si observamos los valores obtenidos, tanto de forma global, como individual.

8.3.2. EVALUACIÓN COMPUTACIONAL

La evaluación de carácter computacional en la presente tesis se ha realizado tomando medidas tanto de tiempos como de consumos de memoria a la ejecución de 20 casos clínicos, tal y como se ha presentado en el apartado de evaluación diagnóstica. Estos 20 casos, fueron repartidos entre cinco expertos, de manera que cada caso era obligatorio que fuera evaluado por tres expertos. Esto genera que cada experto tiene asignados un total de 12 casos.

A continuación se irán mostrando las diferentes tablas y gráficos que permiten analizar el comportamiento del sistema en el área de eficiencia computacional, así como de los expertos.

La Tabla 25 muestra una relación de tiempos por cada uno de los 12 casos clínicos que los expertos han tenido que resolver. Se indica, por lo tanto, por cada caso clínico, los tiempos que los expertos tomaron en resolverlo. Los valores de la tabla vienen expresados en minutos.

198

Caso Clínico / Experto EX-KS0L EX-SK4V EX-KV8H EX-VH7Q EX-HQ3T

1 2 4 5 2 2

2 3 15 10 2 4

3 6.5 15 10 3 4

4 4 5 5 2 2.5

5 4 5 6 3 2

6 6 15 5 3 1.5

7 3 5 5 2 2

8 4 5 10 2 2

9 2 5 5 2 1.5

10 7.5 5 17.5 2 1.5

11 5 15 5 2 0.5

12 4 10 10 2 2

Media 3,7 ± 1,25 8,67 ± 4,91 6,91 ± 2,47 2,25 ± 0,45 2,57 ± 0,98

Tabla 25. Relación de tiempos de resolución por experto (en minutos)

De esta tabla, se puede obtener la Figura 56, que nos permite comparar la media de cada experto de forma global.

Figura 56. Media de tiempo de resolución de los casos por experto

La Figura 57 muestra una gráfica y una tabla, donde viene representado por cada caso clínico que el sistema o los expertos (sin importar que experto) han resuelto, los tiempos de resolución. Por parte del sistema se incluyen los tiempos cuando el motor de inferencia está inicializado (MII) y cuando no lo está (MINI).

EX-KS0L EX-SK4V EX-KV8H EX-VH7Q EX-HQ3T

Tiempo (Media) 3,7 8,67 6,91 2,25 2,57

0

1

2

3

4

5

6

7

8

9

10

Tie

mp

o (

Min

uto

s)

Media Expertos

199

Figura 57. Tiempos de resolución de sistema y expertos

Los tiempos de ejecución del sistema, tanto en la modalidad MII como MINI representados en la tabla, son las medidas de cada caso tras 10 ejecuciones.

En lo referido a los consumos de memoria, dado que dentro de los humanos esta medida no es aplicable, se muestra en la Figura 58 una tabla que representa los consumos de memoria obtenidos en el sistema en las dos modalidades de ejecución por cada caso clínico.

Figura 58. Gráfico de consumo de memoria del sistema por caso clínico

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Experto 1 2 2 15 4 10 4 2 5 2 5 3 2 5 2 5 7,5 2 15 0,5 10

Experto 2 4 2 10 6,5 3 5 2,5 6 6 3 5 2 10 2 2 5 1,5 5 4 2

Experto 3 5 3 2 15 4 5 4 3 15 1,5 5 4 2 5 1,5 18 5 2 10 2

Sistema (MII) 0 0 0,1 0,1 0 0 0 0 0 0 0 0 0,1 0 0 0 0 0 0 0

Sistema (MINI) 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1 0,1

1

3

5

7

9

11

13

15

17T

iem

po

(M

inu

tos)

Sistema vs Expertos

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Sistema (MII) 162 35 56 206 197 137 157 136 137 136 136 95 186 161 134 171 140 135 127 116

Sistema (MINI) 134 92 159 136 57 76 49 134 139 45 131 88 39 112 100 56 101 111 133 113

0

50

100

150

200

250

Co

nsu

mo

Me

mo

ria

(M

B)

Consumo de memoria

200

Un análisis estadístico más detallado de estos datos permite obtener las siguientes conclusiones:

Existen diferencias significativas entre los tiempos del sistema en los dos casos posibles de ejecución (MII, MINI): (t(38) = 12,664, p < 0.05)

Existen diferencias significativas entre los consumos de memoria del sistema de los dos casos de ejecución posibles: (t(38) = -3,063, p < 0.05)

Existen diferencias significativas entre el peor tiempo del sistema (MINI) y la media de tiempos de los expertos: (t(38) = 9,457, p < 0.05)

En los anexos se muestran las tablas completas de tiempos. Con el motor de inferencia inicializado (Tabla 66) y con el motor no inicializado (Tabla 67). También las tablas completas de consumo de memoria aparecen para el motor de inferencia inicializado (Tabla 68) y no inicializado (Tabla 69).


La evaluación computacional muestra de forma global, la eficiencia del proceso de razonamiento del sistema. La evaluación realizada se encarga de medir por una parte los tiempos de ejecución del sistema por cada caso clínico (se ha realizado una medición consistente en la ejecución del sistema, al menos, 10 veces por caso clínico, para evitar posibles valores atípicos). Así mismo, esta medición, se ha realizado en dos supuestos: motor de inferencia inicializado y no inicializado. Por otra parte, se realizan medidas también del coste de memoria asociado a la resolución del caso clínico.

El hecho de tomar la medida en estos dos supuestos se basa en tratar de demostrar que el sistema es suficientemente bueno incluso cuando este no está inicializado, que es, el peor de los casos, como se puede observar.

Entrando ya en detalle en los resultados obtenidos, podemos analizar en primer lugar la Tabla 25, que muestra la relación de tiempos de resolución por cada experto, y su media. Esto permite saber, para cada caso clínico que el experto ha ejecutado, cuanto ha tardado, y sobre todo, tal y como se refleja en la Figura 56, cual ha sido la media de tiempo de cada experto a la hora de resolver un caso clínico.

La Figura 57 muestra una gráfica y tabla que representa, por cada caso clínico, los resultados de tiempos de resolución del caso clínico tanto para el sistema en las dos modalidades de ejecución como para los expertos, sin necesidad de definir que experto realiza que tarea.

Se puede observar por ejemplo, en el caso de la ejecución cuando el motor de inferencia está inicializado que el tiempo es de 0 minutos. Esto se debe a que solo se están utilizando dos decimales, y los tiempos son muy bajos, razón por la que únicamente se muestran ceros.

En el caso del motor de inferencia no inicializado, los tiempos están siempre en el orden de 0,1 a 0,2 minutos.

También se puede ver en la gráfica correspondiente al sistema, que debido a los valores tan pequeños que tiene asociados, su barra asociada no aparece representada. Además, se puede ver, por cada caso clínico que hay grandes diferencias de un experto a otro en varios casos (por ejemplo: casos 3, 4, 5, 9, 13, 16, 18, 19, 20).

Las conclusiones por lo tanto que podemos extraer por lo tanto de las gráficas mostradas anteriormente es que el sistema tiene unos tiempos de resolución de los casos

201

muy inferior a cualquiera de los expertos, incluso, en el peor de los casos de ejecución del sistema (con el motor de inferencia no inicializado).

Así mismo, entre los propios expertos vemos que hay grandes diferencias a la hora de solventar los casos, ya que sus medias, son bastante diferentes en general.

En el ámbito de consumo de memoria, un análisis de la Figura 58 muestra que el mayor consumo de memoria se encuentra en torno a los 205 MB de memoria, para la base de conocimiento usada y en un caso clínico concreto. La mayoría de los casos muestra un consumo de memoria mayor con el motor de inferencia inicializado, posiblemente debido a la carga de memoria asociada en la base de conocimiento al hecho de tener que mantener las relaciones de inferencia que se han ido ejecutando a lo largo de los distintos procesos de diagnóstico. En el caso del motor no inicializado, estos valores generalmente son menores ya que aunque en el campo temporal conlleva más tiempo hacer la inferencia, en el campo espacial no se debe guardar constancia en memoria de las inferencias previas, suponiendo esto un decremento en la memoria utilizada.

La conclusión fundamental que se extrapola es que como se ha comentado el máximo de memoria usado para la base de conocimiento actual es ínfima si se tienen en cuenta las capacidades de memoria de los ordenadores actuales.

8.3.3. EVALUACIÓN TECNOLÓGICA

Tal y como se establece en la metodología a emplear para la evaluación de las tecnologías involucradas en el diseño y desarrollo del sistema. A continuación se ofrecen una serie de tablas donde se mencionan las principales ventajas e inconvenientes de las tecnologías que generalmente han sido más usadas para el desarrollo de este tipo de sistemas y que han sido mencionadas durante los capítulos 2 y 3.

La Tabla 26 muestra las ventajas e inconvenientes encontrados a la hora de utilizar Redes Bayesianas para el diseño y desarrollo de este tipo de sistemas.

Redes Bayesianas Ventajas Inconvenientes

Representación gráfica del conocimiento que muestra un conjunto de variables y sus relaciones probabilísticas entre enfermedades y síntomas (Nikovski, 2000).

Dificultad de obtener la probabilidad de conocimiento para posibles diagnósticos.

Cálculo sencillo de la probabilidad de la presencia de posibles enfermedades a partir de los síntomas.

No es práctico para sistemas complejos muy grandes donde haya múltiples síntomas.

Conocimiento y conclusiones de expertos se pueden representar en forma de probabilidades.

Dificultad para representar la información de forma óptima debido al gran número de nodos que pueden existir.

Posibilidad de explicar el razonamiento. Depende del modelo de red, puede haber un gran número de valores a calcular.

Tabla 26. Tabla evaluación tecnológica: Redes Bayesianas

La Tabla 27 muestra las ventajas e inconvenientes encontrados a la hora de utilizar Redes de Neuronas Artificiales para el diseño y desarrollo de este tipo de sistemas.

202

Redes de Neuronas Artificiales Ventajas Inconvenientes

Permite al sistema aprender de experiencias pasadas o ejemplos y reconocer patrones en la información clínica.

Se requieren probar muchas configuraciones de redes para evaluar cuál podría ser la óptima.

Pueden procesar datos incompletos tratando de hacer averiguaciones acerca de los datos que faltan y mejorar con cada caso de uso debido a su aprendizaje.

El proceso de entrenamiento podría llevar mucho tiempo y necesita alimentarse con gran cantidad de datos para empezar a generalizar correctamente.

No requieren grandes bases de datos para almacenar los datos de salida con sus probabilidades asociadas.

No es posible explicar el motivo por el cual han llegado a una determinada conclusión al tratarse de un sistema que su interior actúa de caja negra.

En algunos casos este enfoque obtiene incluso mejores resultados que los propios médicos (Tourassi et al., 1993; Tourassi et al., 1995; Holst et al., 2000).

La selección de características (elemento relacionado con la prueba de configuraciones) puede ser un elemento bastante influyente de forma negativa para generar este tipo de sistemas.

Tabla 27. Tabla evaluación tecnológica: Redes Neuronales

La Tabla 28 muestra las ventajas e inconvenientes encontrados a la hora de utilizar Algoritmos Genéticos para el diseño y desarrollo de este tipo de sistemas.

Algoritmos Genéticos Ventajas Inconvenientes

Los sistemas se ejecutan a través de un proceso iterativo para producir una solución "óptima".

Falta de transparencia en el razonamiento envuelto, con lo que no es posible explicar sus razonamientos de forma adecuada al verse implicado un proceso aleatorio en la generación de resultados.

En ciertos dominios como el de la incontinencia urinaria se han obtenido buenos resultados con este enfoque (Laurikkala & Juhola, 1998; Laurikkala et al., 2009).

El criterio de fitness que permita alcanzar la optimalidad puede ser muy difícil de definir según el caso.

Tabla 28. Tabla evaluación tecnológica: Algoritmos Genéticos

La Tabla 29 muestra las ventajas e inconvenientes encontrados a la hora de utilizar Sistemas Basados en Reglas para el diseño y desarrollo de este tipo de sistemas.

Sistemas Basados en Reglas Ventajas Inconvenientes

Facilidad de codificación de las reglas en determinados casos.

Tamaño de la base de conocimiento que almacene las reglas.

Es posible explicar el proceso de razonamiento.

No es posible realizar razonamiento bajo incertidumbre en el sentido clásico. Se pueden realizar cálculos sobre la incertidumbre de los elementos de forma separada.

Rapidez en el proceso de inferencia según el motor usado.

Se necesita capturar el dominio del experto y transcribirlo a formato reglas, lo cual es una tarea tediosa.

La codificación de las reglas por lo general Un error en la codificación de las reglas

203

permite un entendimiento sencillo de las mismas.

implica un error en el razonamiento.

En los casos donde las reglas tienen como subyacente lógica no monotónica es posible crear sistemas para mejorar el rendimiento a través de técnicas de caching (Rodríguez et al., 2009).

Tabla 29. Tabla evaluación tecnológica: Sistemas basados en reglas

La Tabla 30 muestra las ventajas e inconvenientes encontrados a la hora de utilizar Tecnologías Semánticas para el diseño y desarrollo de este tipo de sistemas.

Tecnologías Semánticas Ventajas Inconvenientes

Representación del conocimiento mediante el uso de ontologías.

Incapacidad de realizar cálculo probabilístico dentro del propio sistema.

Representación del conocimiento mediante descripciones lógicas y reglas.

Velocidad de razonamiento con el uso de reglas.

Tabla 30. Tabla evaluación tecnológica: Tecnologías Semánticas


En la presente tesis, las técnicas utilizadas para el desarrollo de este sistema es un compendio entre los, sistemas basados en reglas y las Tecnologías Semánticas.

Las Tecnologías Semánticas establecen el marco idóneo de representación del conocimiento, permitiendo además la posibilidad de generar bases de conocimiento a partir de reglas o de descripciones lógicas, algo que permite dar solución a las principales hipótesis planteadas.

Para finalizar, el último pilar, el de los sistemas basados en reglas, proporcionan la que claramente es la mayor ventaja a la hora de desarrollar este tipo de sistemas, y es la posibilidad de explicación de los hechos que conducen a un razonamiento concreto. Esta característica, si bien es posible también en otras técnicas como las probabilísticas, en este caso aporta ciertas ventajas respecto a este enfoque como la sencillez de la codificación de las reglas de inferencia o la velocidad de este tipo de sistemas, además de ser capaces de incluso incrementar aún más esta eficiencia gracias a la lógica no monotónica subyacente de la que se hace uso en este caso concreto.

204

9. VERIFICACIO N En este capítulo se describe el proceso de verificación que se ha llevado a cabo a

partir de las hipótesis planteadas. Para realizar la verificación se ha utilizado el sistema MDSS-OPM definido previamente en el capítulo 7. La implementación de este sistema ha permitido la verificación de las hipótesis definidas.

9.1. METODOLOGÍA DE VERIFICACIÓN

Las hipótesis planteadas al comienzo de la investigación de esta tesis planteaban la posibilidad de diseño de una plataforma o sistema que permitiera la realización de diagnósticos diferenciales en el campo de la medicina, cumpliendo con una serie de requisitos básicos acerca de su eficiencia (tanto diagnóstica como computacional), estableciendo además una serie de requerimientos sobre la capacidad diagnóstica y sus elementos asociados. Concretamente, las hipótesis planteadas eran las siguientes:

Hipótesis H1: El uso de técnicas pertenecientes a las Tecnologías Semánticas principalmente, y de ciertas técnicas de Inteligencia Artificial en segundo lugar, permiten la creación de sistemas de diagnóstico diferencial de alta sensibilidad en medicina que proporcionen resultados con alto grado de exactitud (siendo exactitud en entornos diagnósticos, la capacidad para clasificar a los pacientes en categorías o estados en relación con la enfermedad (López de Ullibarri Galparsoso & Pita Fernandez, 1998)) de forma eficiente.

o Hipótesis H1.1: La exactitud diagnóstica de los resultados vendrá dada por las capacidades de inferencia del sistema, la cual provee resultados, en los cuales se establece que su correctitud esté dentro de unos umbrales preestablecidos por expertos.

o Hipótesis H1.2: La eficiencia del sistema vendrá medida en términos de tiempos de ejecución dentro de unos umbrales preestablecidos.

Hipótesis H2: El problema de diagnóstico mediante inferencia multinivel, puede ser modelado y solventado usando técnicas asociadas a la Tecnologías Semánticas tales como las descripciones lógicas o los sistemas basados en reglas.

Hipótesis H3: Es posible la realización de un proceso que permita calcular alternativas de diagnóstico dado el planteamiento en el que los síntomas de una enfermedad (un caso clínico concreto), hayan sido inducidos por la ingesta de fármacos, y por lo tanto, su presencia no sea un indicio de la patología a diagnosticar.

La verificación de las hipótesis presentadas en esta tesis depende, en ciertos casos, de la verificación de sus subhipótesis principalmente (en el caso de tener subhipótesis, como es el caso de H1 y H2).

¿Cómo es posible verificar, por ejemplo, la hipótesis H1 que define que “el uso de técnicas pertenecientes a las Tecnologías Semánticas principalmente, y de ciertas técnicas de Inteligencia Artificial en segundo lugar, permiten la creación de sistemas de diagnóstico diferencial de alta sensibilidad en medicina que proporcionen resultados con alto grado de exactitud de forma eficiente.”?. Dado que como se indica en esta hipótesis, se precisa que el sistema debe proporcionar resultados exactos de forma eficiente, para poder verificar esta hipótesis es necesario verificar primeramente sus subhipótesis, pues estas definen las métricas de exactitud y eficiencia. Igualmente, ocurre con la hipótesis H2. Así mismo,

205

otro requisito implícito para esta verificación es la aplicación o uso de las tecnologías definidas.

Debido por lo tanto a que la verificación de las hipótesis depende de las subhipótesis en determinados casos, se va a realizar una verificación bottom-up, donde en primer lugar se verificarán las subhipótesis para a continuación proceder a verificar de forma prácticamente automática las hipótesis.

Se definen por lo tanto cinco fases de verificación:

1. Verificación de la subhipótesis H1.1. Dado que esta subhipótesis define la exactitud de los resultados, se procederá a verificarla a través del sistema realizado en el capítulo 7 (MDSS-OPM) y la evaluación realizada (donde se contrasta el sistema con los expertos que han proporcionado datos para la evaluación). La verificación se realizará de forma conjunta, tal y como se explicará en su correspondiente sección.

2. Verificación de las subhipótesis H1.2. Esta subhipótesis define la eficiencia a la hora de obtener los resultados (desde un punto de vista computacional) y se volverá a verificar de forma conjunta con MDSS-OPM y los expertos.

3. Verificación de las hipótesis H1 a partir de los resultados obtenidos en los pasos anteriores.

4. Verificación de la hipótesis H2 mediante un análisis de los resultados devueltos por los sistemas propuestos.

5. Verificación de la hipótesis H3.

9.2. VERIFICACIÓN DE LA EXACTITUD DIAGNÓSTICA (HIPÓTESIS H1.1)

Como se ha comentado en la sección 8.1.1, la evaluación de la eficiencia diagnóstica de un sistema que presente diagnósticos diferenciales suele realizarse a través de la comparación del sistema con expertos o con otros sistemas de características similares. Debido a esto, es necesario preguntarse, ¿Cómo se puede verificar una hipótesis que define que un sistema determinado es suficientemente preciso o eficiente (entendiendo ambos términos como sinónimos dentro de esta área concreta)?

En el caso de la presente tesis, para realizar una evaluación del sistema, que es la que permite realmente verificar esta hipótesis, se optó por la opción de comparar el sistema desarrollado, que es un elemento software creado con el único objetivo de verificar las hipótesis, con una serie de expertos.

Los expertos son, como su nombre indica, los que teóricamente tienen el conocimiento absoluto del dominio sobre el que se está trabajando. A la hora de evaluar como de buena es una determinada herramienta debemos compararla contra un "estándar de oro" que permita definir la exactitud del dominio, y en este caso, dicho estándar de oro, son los expertos.

Para evitar posibles sesgos a la hora de evaluar los resultados, y por lo tanto, ser capaz de verificar las hipótesis, se ha proporcionado, tal y como se ha definido previamente, una metodología suficientemente adecuada que mediante el uso de varios expertos, permita eliminar todo tipo de sesgos y tener la certeza de que los resultados serán correctos.

Además de los expertos que se encargaron de proporcionar diagnósticos para cada caso clínico planteado, de cara a compararlos con el sistema, se contó con dos árbitros que

206

permitían verificar los resultados que estos expertos proporcionaron, y que el sistema proporcionó. Nuevamente el uso de dos expertos en vez de uno ha tenido el objetivo de evitar sesgos.

La verificación por lo tanto de la exactitud diagnóstica del sistema se ha realizado en cuatro etapas posibles, si bien, la etapa más importante, al ser la que más penalizaba al sistema y ayudaba a los expertos, y siendo por lo tanto el peor de los casos, es la cuarta opción:

1. Verificación de la hipótesis con los resultados del primer árbitro 2. Verificación de la hipótesis con los resultados del segundo árbitro 3. Verificación de la hipótesis con los resultados de la unión de

árbitros 4. Verificación de la hipótesis con los resultados de la intersección de

árbitros

Así mismo, dado que como se definió previamente, el indicador global de la eficiencia del sistema y de los expertos era el MCC, este será el que servirá como medida de contraste.

En la Figura 59 se muestra un gráfico donde se compara la eficiencia del sistema contra la media de los expertos para los arbitrajes de forma individual.

Figura 59. Verificación eficiencia (Árbitros – Individual)

En esta figura se puede observar los resultados de forma individual de los arbitrajes realizados por los dos árbitros (AR-TD46 y AR-XF31). Estos resultados hacen referencia a los valores medios de la métrica MCC obtenidos para el sistema y para los expertos. Se debe recordar, que como se comentó en el capítulo 8, el valor del MCC es el valor de referencia general para la medición de la eficiencia del sistema y los expertos.

Los valores obtenidos para el sistema son claramente superiores que los obtenidos para los expertos.

Igualmente, la Figura 60 muestra un gráfico donde se compara nuevamente la eficiencia del sistema contra la media de los expertos para los arbitrajes usando conjuntos (unión e intersección).

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema [AR-TD46]

Expertos [AR-TD46]

Sistema [AR-XF31]

Expertos [AR-XF31]

MCC 93,88% 59,11% 94,29% 61,24%

Efi

cie

nci

a/

Pre

cisi

ón

Dia

gn

óst

ica

Validación Eficiencia (Árbitros - Individual)

207

Figura 60. Verificación eficiencia (Árbitros – Conjuntos)

En este caso, la información de este gráfico es similar a la del anterior, solo que en este caso estamos observando los valores medios del MCC para la unión e intersección de arbitrajes, y nuevamente podemos observar como el sistema, incluso en el peor de los casos (intersección), sigue superando a los expertos.

9.2.1. CONCLUSIONES

Tras observar las figuras previas, se puede observar como por lo tanto, como cuantitativamente se produce la verificación de la hipótesis que define que el sistema desarrollado es eficiente/preciso en lo referido a su capacidad diagnóstica, en los cuatro posibles casos presentados (arbitrajes individuales, unión e intersección).

Es importante además destacar como en el caso más desfavorable para el sistema y más favorable para los expertos (intersección), el sistema sigue obteniendo una eficiencia cuya diferencia respecto a los expertos es del 32.19%. Así mismo, es importante destacar que tal y como se ha detallado en la sección 8.3.1, estos resultados son significativos desde el punto de vista estadístico, dando un valor añadido a la verificación de la hipótesis.

Este resultado es aplicable para la hipótesis H1.1 que venía dentro de la definición de la capacidad de crear un sistema que aplique las tecnologías mencionadas, tal y como se verificará más adelante.

9.3. VERIFICACIÓN DE LA EFICIENCIA COMPUTACIONAL (HIPÓTESIS H1.2)

En la sección 8.1.2 se menciona el aspecto de evaluación de la eficiencia computacional, haciendo especial hincapié en que en la actualidad el requisito quizás más importante a la hora de evaluar los sistemas de diagnóstico diferencial desde una perspectiva computacional es el de la eficiencia de tipo temporal, dejando en un segundo plano la eficiencia espacial.

La argumentación de dejar de lado la eficiencia espacial se basa en los grandes avances tecnológicos que se han producido en los elementos hardware en los últimos años. Estos avances permiten que las bases de conocimiento que estén en soportes de almacenamiento como grandes servidores de datos permitan que la información

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

Sistema [AR-TD46 ∪ AR-

XF31]

Expertos [AR-TD46 ∪ AR-

XF31]

Sistema [AR-TD46 ∩ AR-

XF31]

Expertos [AR-TD46 ∩ AR-

XF31]

MCC 94,60% 59,01% 93,59% 61,40%

Efi

cie

nci

a/

Pre

cisi

ón

Dia

gn

óst

ica

Validación Eficiencia (Árbitros - Conjuntos)

208

almacenada pueda crecer casi sin control. Aún así, debe entenderse que la información referida al diagnóstico diferencial es limitada, ya que no estamos hablando de información que crezca rápidamente, de hecho, esta información actualmente podría considerarse como estancada, entendiendo que los cambios que se producen en este tipo de información no suponen la necesidad de nuevas fuentes de almacenamiento para atender las demandas de nueva información que puedan surgir, como podría ser en el caso de otras plataformas como redes sociales, servidores de correo, etc.

Debido a esto, es importante centrarse en las capacidades temporales. Aunque las máquinas de hoy en día tienen una velocidad muy superior a las de hace, por ejemplo, 20 años, existen otros factores de tipo software que son importantes y que se tienen que considerar a la hora de medir la eficiencia de tipo temporal de un sistema. Aún así, en la sección 8.3.2, donde se analiza la evaluación desde un punto de vista computacional, se pueden observar los resultados de consumos de memoria en las dos posibles situaciones del sistema, si bien, estos datos no serán utilizados en la verificación de las hipótesis aquí presentadas por los motivos establecidos.

Dado que la subhipótesis H1.2 define que el sistema debe ser eficiente desde un punto de vista computacional, y dado que previamente se ha establecido que las consideraciones computacionales en la presente tesis harán referencia fundamentalmente a aspectos relacionados con la complejidad temporal, la verificación de las mismas se realizará mediante una comparación entre el tiempo de resolución de los casos clínicos que conforman la evaluación por parte del sistema y por parte de los expertos.

En la evaluación computacional, presentada en la sección 8.3.2, se realizaba una comparativa entre el tiempo de resolución del sistema una vez conoce la información y los expertos, una vez también son conscientes de ella. Por parte del sistema, se utilizaban dos posibles casos: 1) MINI: El motor de inferencia no estaba inicializado (peor caso dado que supone una inicialización del mismo, siendo este el proceso más costoso computacionalmente), 2) MII: El motor de inferencia estaba inicializado.

A continuación, la Figura 61 expone un gráfico resumen de los resultados obtenidos (se tienen en cuenta los tiempos medios de resolución de los 20 casos clínicos presentados). Debe tenerse en cuenta que la toma de medidas por parte del sistema se realizó tras varias ejecuciones con el objetivo de no obtener posibles ejecuciones anómalas con datos incorrectos.

209

Figura 61. Tiempo medio de resolución de casos

Este gráfico muestra como la media de tiempo en minutos que toma a los expertos la resolución de un caso es mucho mayor que el tiempo que le lleva la resolución al sistema (del orden de 125 veces mayor para el sistema en modo MII y 58 para el sistema en modo MINI).

9.3.1. CONCLUSIONES

Tras el gráfico mostrado, se puede observar como el tiempo medio de realización de un diagnóstico por parte del sistema (incluso en el peor de los casos: MINI), toma un tiempo mucho menor de lo que llevaría a un experto (habiendo además diferencias significativas desde el punto de vista estadístico tal y como se mostró en la evaluación computacional).

Esto, unido a la hipótesis ya verificada (H1.1) que define la exactitud del mismo, hace que el sistema posea una categoría que le permita su utilización en entornos reales.

Es importante destacar que incluso aunque el sistema no fuera capaz de superar a los expertos, rechazar las hipótesis que aquí se pretenden verificar debería ser objeto de un estudio más profundo. Está claro que en cuanto el tiempo medio supera al que se está considerando como estándar de oro (los expertos), la verificación de la hipótesis se realiza de forma automática. Sin embargo, el no superarlos no implicaría un rechazo de la hipótesis, ya que tendría que valorarse, de forma estadística si hay diferencias significativas entre los tiempos, o de forma cualitativa (mediante un comité de expertos que tome una decisión al respecto), si el tiempo obtenido es adecuado.

9.4. VERIFICACIÓN DE LAS HIPÓTESIS H1 Y H2

9.4.1. VERIFICACIÓN DE LA HIPÓTESIS H1

La hipótesis H1 define la posibilidad de la creación de un sistema de diagnóstico diferencial mediante la aplicación de tecnologías relacionadas con las Tecnologías Semánticas y ciertas técnicas de Inteligencia Artificial.

0

1

2

3

4

5

6

Expertos Sistema (MII) Sistema (MINI)

Tiempo (minutos) 5,016666667 0,04057 0,08604

Tie

mp

o

Tiempo Medio Resolución Casos

210

Dicha hipótesis pone como condiciones dos subhipótesis donde se establece que el producto resultante que permita verificar esta hipótesis debe ser eficiente en términos computacionales y preciso en términos diagnósticos.

La verificación de estas subhipótesis (H1.1, H1.2) ha sido realizada en las secciones previas gracias a los resultados arrojados en la evaluación.

Esta evaluación, se ha centrado en el análisis de los resultados devueltos por el sistema que ha sido desarrollado para permitir verificar las hipótesis de investigación planteadas: MDSS-OPM, el cual es descrito en detalle en el capítulo 7.

La verificación por lo tanto de las hipótesis H1 y H2 se tiene que plantear desde un punto de vista más cualitativo, ya que la “pregunta” que podemos reformular a partir de estas hipótesis sería:

¿El aplicar Tecnologías Semánticas y las técnicas de Inteligencia Artificial vistas (Sistemas basados en reglas fundamentalmente) permite la creación de sistemas de diagnóstico diferencial en medicina precisos y eficientes?

Partiendo de la base de que hemos verificado la parte que define la exactitud y la eficiencia, las pregunta que nos queda es:

¿El aplicar Tecnologías Semánticas y las técnicas de Inteligencia Artificial vistas (Sistemas basados en reglas fundamentalmente) permite la creación de sistemas de diagnóstico diferencial en medicina?

La respuesta a esta pregunta es trivial y directa: Si.

Como se ha podido comprobar a lo largo de toda la presente tesis, las técnicas y tecnologías utilizadas para el desarrollo de los sistemas que debían verificar las hipótesis de investigación establecidas, son técnicas y tecnologías pertenecientes a la Inteligencia Artificial. Concretamente, podemos desglosar las técnicas utilizadas para verificar las hipótesis en las siguientes:

Técnicas relativas a la Inteligencia Artificial o Sistemas basados en reglas

Tecnologías Semánticas o Descripciones lógicas (podría ser clasificado como perteneciente a

la IA, si bien, su mayor uso ha sido dentro de las tecnologías semánticas).

o Uso de ontologías como representación del conocimiento.

Partiendo por lo tanto de la justificación realizada previamente, donde la verificación de las hipótesis H1.1 y H1.2 ha sido satisfactoria, podemos verificar directamente la hipótesis H1, al haber aplicado las técnicas propuestas en la hipótesis.

9.4.2. VERIFICACIÓN DE LA HIPÓTESIS H2

La verificación de la hipótesis H2 depende en parte de la verificación de H1. En H1 se demuestra que la aplicación de las tecnologías mencionadas permite la generación de sistemas de diagnóstico diferencial de alta sensibilidad en medicina con un alto grado de exactitud y eficiencia. Sin embargo, la verificación de H2 no es directa.

H2 postula que aplicando estas tecnologías el problema de diagnóstico mediante inferencia multinivel sigue siendo solventable. Partiendo de la base de haber verificado

211

H1, y dando por hecho la aplicación de las tecnologías, se va a mostrar más información relativa al proceso de diagnóstico aplicando inferencia multinivel.

De las 24 enfermedades que componen la base de conocimiento utilizada en el desarrollo de los sistemas utilizados en esta tesis, un total de cuatro enfermedades han sido diseñadas de tal forma que alguno de sus criterios de diagnóstico era otra enfermedad. Así mismo, de los 20 casos clínicos generados para la evaluación de los sistemas presentados en esta tesis, las cuatro enfermedades han sido diagnosticadas por el sistema en un total de 13 casos clínicos de los 20 propuestos para la evaluación.

El procedimiento de verificación de la hipótesis se complementa por lo tanto con el proceso que se describirá a continuación. Debe tenerse en cuenta que este procedimiento se realiza única y exclusivamente para proporcionar información adicional sobre la solución, ya que el mero hecho de haber diseñado la base de conocimiento para trabajar en modo multinivel, y el haber podido verificar la exactitud global de este sistema en la hipótesis H1 y sus respectivas subhipótesis, permite verificar por si sola la hipótesis H2.

La Tabla 31 muestra un resumen de los resultados obtenidos (ver Tabla 35 a Tabla 41 de los anexos para resultados completos). Se incluyen las cuatro enfermedades con capacidades de inferencia multinivel y los resultados obtenidos. A continuación se realiza una explicación de cada resultado:

Correctos: Indica cuando la inferencia multinivel para alguna de las enfermedades que forman parte del criterio diagnóstico de enfermedad se ha activado (se ha realizado diagnóstico mediante inferencia multinivel) y el resultado de la inferencia era considerado correcto por el arbitraje.

Incorrectos: Indica cuando la inferencia multinivel para alguna de las enfermedades que forman parte del criterio diagnóstico de enfermedad se ha activado (se ha realizado diagnóstico mediante inferencia multinivel) y el resultado de la inferencia no era considerado correcto por el arbitraje.

Correctos parciales: Indica cuando la enfermedad ha sido diagnosticada y dada por correcta por el arbitraje, pero no se puede garantizar que haya sido por el diagnóstico multinivel o porque el caso clínico contenía los propios criterios de la enfermedad.

Incorrectos parciales: Indica cuando la enfermedad ha sido diagnosticada y dada por incorrecta por el arbitraje, pero no se puede garantizar que haya sido por el diagnóstico multinivel o porque el caso clínico contenía los propios criterios de la enfermedad.

Correctos Incorrectos Correctos Parciales

Incorrectos Parciales

Fiebre Tifoidea 2 2 5 0 Laringitis 1 4 0 0

Bronquitis 2 3 1 0 Brucelosis 5 1 1 0

Total 10 10 7 0

Tabla 31. Resumen de los resultados de inferencia multinivel

Se puede observar que el diagnóstico de inferencia multinivel ofrece resultados mejores en unas enfermedaes que en otras (por ejemplo, en la Brucelosis la inferencia multinivel parece ofrecer resultados buenos mientras que en la Laringitis ofrece resultados malos). Las razones de esto se deben a la complejidad de las enfermedades puente, que son las que proporcionan esta inferencia multinivel. La laringitis se diagnóstica mediante el proceso multinivel a través de un posible diagnóstico previo de la

212

faringitis. La brucelosis sin embargo se diagnostica a través de diagnósticos previos de enfermedades ligeramente más complejas como son la neumonía y la pielonefritis. La complejidad de las enfermedades que permiten este diagnóstico multinivel puede ser una de las razones, en este caso. Sin embargo, en la Fiebre Tifoidea obtenemos resultados iguales (2 correctos y 2 incorrectos), siendo las enfermedades puente entidades bastante complejas como las propias pielonefritis y neumonía, y otras como la orquitis, meningitis y pancreatitis.

El hecho de que el diagnóstico sea de alta sensibilidad podría ser una de las razones de los problemas del diagnóstico multinivel, ya que aunque los signos no pertenecientes a las enfermedades puente actúan de discriminantes de estas, esto no implica que la enfermedad pueda seguir actuando de puente para el diagnóstico de otras enfermedades, pudiendo generar que pocos inputs de entrada o inputs muy comunes generen estos diagnósticos.

Si tomamos únicamente como medida los resultados correctos e incorrectos obtenemos un porcentaje de acierto del sistema de alrededor del 50% en lo que se refiere al diagnóstico multinivel (midiéndolo de forma sencilla, sin aplicar las métricas de PRAS-M vistas anteriormente y que no son necesarias en este caso). En el caso de usar los resultados parciales correctos como resultados positivos obtenemos una tasa de acierto de en torno al 63% teniendo en cuenta su aplicación únicamente en 13 de los 20 casos posibles.

Los resultados obtenidos en la evaluación global de los desarrollos realizados muestran unos niveles de exactitud que permiten validar la utilización del diagnóstico multinivel como un sistema apto para los procesos de diagnóstico. Sin embargo, el análisis independiente realizado en esta parte de la tesis demuestran que una futura mejora debería ser realizada con el objetivo de evitar que el proceso multinivel sea menos sensible, con el fin de evitar diagnósticos erróneos.

9.4.3. CONCLUSIONES

La verificación de las hipótesis H1 y H2 se basan fundamentalmente en una mera formalidad. La hipótesis H1 como se ha comentado previamente dependía directamente de la verificación de sus subhipótesis para demostrar que los sistemas desarrollados eran exactos y eficientes. Por lo tanto, el hecho de haber utilizado las tecnologías mencionadas permite automáticamente la verificación de la hipótesis padre, H1.

En el caso de la hipótesis H2 el procedimiento es similar. Partimos de la base de proponer una solución para el problema de diagnóstico mediante inferencia multinivel mediante la aplicación de unas determinadas tecnologías. El hecho de haber aplicado esta inferencia multinivel en un total de 13 de los 20 casos clínicos y haber obtenido los resultados de exactitud que se han mostrado previamente, permiten realizar una verificación automática de la hipótesis H2.

Sin embargo, tal y como se ha mostrado en la sección 9.4.2, un análisis en detalle del procedimiento de inferencia multinivel muestra una serie de deficiencias que tienen su origen principalmente en el hecho de que el proceso de diagnóstico modelado sea de alta sensibilidad. Esta alta sensibilidad genera una problemática en el diagnóstico de alta sensibilidad, ya que las enfermedades puente son usadas incluso cuando hay pocos indicios.

213

9.5. VERIFICACIÓN DE LA HIPÓTESIS H3

Como se ha mencionado previamente, el enunciado de la hipótesis H3 dice lo siguiente:

Es posible la realización de un proceso que permita calcular alternativas de diagnóstico dado el planteamiento en el que los síntomas/signos de una enfermedad (un caso clínico concreto), hayan sido inducidos por la ingesta de fármacos, y por lo tanto, su presencia pueda no ser un indicio directo de la patología a diagnosticar.

Es importante destacar que dentro de este enunciado se hace uso del término posibilidad, dando a entender que el proceso es realizable, si bien su eficiencia no es considerada dentro de la hipótesis. El objetivo de este proceso se podría plantear como la primera piedra de un edificio: es el primer paso, o uno de los primeros pasos, que se deben tomar para establecer procesos más complejos que permitan solventar problemas concretos.

La presencia de fármacos en un caso clínico debe ser considerado a la hora de realizar un diagnóstico, tal y como se demostrará posteriormente en el proceso de verificación de esta hipótesis. Siendo así esta situación, es necesaria la generación de procesos, o algoritmos que permitan usar esta información (la presencia o ingesta de fármacos) para generar sistemas de diagnóstico más completos.

El diagnóstico múltiple se define como aquel tipo de diagnóstico diferencial en el que el experto médico identifica más de una patología como elemento causal de la condición actual del enfermo. Este diagnóstico múltiple es un proceso harto complicado, donde influyen diversos factores, como el aislamiento de los indicios de entrada en conjuntos para poder tratarlos como elementos separados, la exclusión de resultados repetidos, la probabilidad de coexistencia de patologías, etc.

Tanto en este proceso, como en el proceso de diagnóstico diferencial que se ha definido y utilizado previamente en esta tesis, tienen que hacer uso del conocimiento que poseen para poder proporcionar la solución más factible, incluyendo en este conocimiento un posible consumo de fármacos que pueda estar afectando a los inputs.

El proceso por lo tanto que se define en la hipótesis H3, es un proceso que ha sido creado con el objetivo de ayudar a establecer algunos pasos que podrían ser tomados en cuenta para la creación de sistemas que consideren el diagnóstico múltiple como resultado. El hecho de poder calcular conjuntos, o alternativas de diagnóstico, puede ayudar en la resolución de este problema, dado que permite la generación de subconjuntos que el experto clínico podría no tener en cuenta a priori. La información almacenada en la base de conocimiento permite además que las relaciones entre indicios y fármacos puedan ser fácilmente consultadas, dando lugar a una rápida generación del conocimiento necesario para crear los subconjuntos mencionados.

Para la verificación de que esta hipótesis es cierta, el enfoque utilizado previamente, de tipo cuantitativo, no es viable. La evaluación cuantitativa realizada previamente permitía medir la eficiencia de un proceso que se ha generado. Sin embargo, dado que en este caso se habla de que es posible generar un determinado proceso que ayude en una tarea, es difícil establecer de forma cuantitativa un determinado valor o peso.

Debido a esto, para la verificación de esta hipótesis se plantea una verificación cualitativa. Dado que los expertos del dominio en este caso, son los médicos, se ha escogido a los dos expertos que se pueden observar en la tabla Tabla 18. Estos expertos,

214

que previamente han ayudado en el proceso de arbitraje, permitirán discernir desde un punto de vista cualitativo, a través de sus respuestas a una serie de preguntas (de respuesta dicotómica) enfocadas a la verificación de la hipótesis, si dicha hipótesis es verificable.

Las preguntas han sido realizadas teniendo en cuenta el objetivo del proceso y sus implicaciones. El conjunto de verificación está formado por un total de 5 preguntas y un campo de observaciones. De las 5 preguntas, cuatro pretenden ayudar a obtener más información acerca del proceso realizado, y por lo tanto sacar conclusiones acerca de como de bueno ha sido el planteamiento y el proceso realizado. La quinta pregunta, pretende establecer si el experto, conocedor del proceso, y del planteamiento de la hipótesis, puede asegurar que desde un punto de vista clínico que la hipótesis es verificable.

A continuación, se exponen las respuestas y observaciones de cada experto. En el siguiente apartado se obtendrán las conclusiones relativas a las respuestas dadas por ambos expertos para cada pregunta y en función a sus observaciones se procederá a la verificación de la hipótesis.

En primer lugar, se muestra la Tabla 32, donde se muestran las preguntas realizadas, y un código que identifica para cada pregunta para en la tabla de resultados poder asociar la pregunta a su código.

Pregunta ID ¿Considera que la interacción de fármacos es un elemento que se debe tener en cuenta a la hora de realizar un diagnóstico?

P1

¿Considera que puede excluirse de forma “temporal” (como se muestra en el proceso) un signo si se argumenta que esta exclusión es debida a que estamos asumiendo que este signo ha sido producido por un fármaco? (Teniendo en cuenta que una de las combinaciones posible (la vacía, donde no se excluye ningún signo) se tendrá en cuenta para realizar el diagnóstico?

P2

¿Considera que el proceso mencionado podría ser útil (aunque deba ser ampliado y mejorado) para ser usado en entornos médicos?

P3

¿Considera que el proceso podría ser usado para generar, junto con más técnicas, diagnósticos múltiples?

P4

¿Considera finalmente que la hipótesis planteada en relación al proceso es verificable desde un punto de vista médico, aunque este proceso deba ser ampliado y mejorado?

P5

Tabla 32. Tabla de preguntas para verificación de hipótesis H3

A continuación, en la Tabla 33, se muestran los resultados de cada experto para las preguntas.

Pregunta Respuesta AR-TD46 Respuesta AR-XF31 P1 S S P2 N S* P3 S S P4 S S P5 S S

Tabla 33. Respuestas a preguntas para la verificación de H3

215

La Tabla 34, muestra las observaciones realizadas por cada experto:

Observaciones AR-TD46 En muchas ocasiones me encuentro en Urgencias con personas que iniciaron un tratamiento recientemente, menos de una semana de duración, y presentan signos y síntomas atribuibles a ello. Incluir esa reacción adversa medicamentosa es importante para un buen diagnóstico. Te pongo un ejemplo reciente: un paciente que llega con fiebre de 38ºC (termometrado) que a veces llega a 40ºC, malestar general, dolor de garganta, sudoración. Se le da amoxicilina-clavulánico al 6º día de comenzar con los síntomas por sospecharse una faringitis y el paciente desarrolla un exantema macular generalizado. Al llegar a Urgencias, el que está en Urgencias se plantea como diagnóstico principal un sarampión…a menos que le dé por pensar en la mononucleosis infecciosa, que se caracteriza entre otras cosas porque si le das ese antibiótico, la amoxicilina-clavulánico, sufre esa reacción exantemática. Quizás además de hablar de interacción de fármacos sería interesante recurrir a la definición de reacción adversa medicamentosa; en el primer caso hablamos de dos fármacos que interaccionan entre sí con resultados malos, mientras que en una reacción adversa medicamentosa ese medicamento le sienta mal al paciente y desencadena una sintomatología que, de no tener en cuenta este detalle, se puede confundir con otros procesos patológicos. Otro ejemplo que te puedo poner es la diarrea secundaria a la amoxicilina-clavulánico, o las reacciones extrapiramidales del famoso Primperam.

Observaciones AR-XF31 * La exclusión temporal podría tener el inconveniente de no tener en cuenta que un fármaco no sólo puede producir un síntoma sino incrementar otro de la enfermedad incluso atenuarlo o producir el efecto contrario. Sin embargo en un sistema altamente elaborado este aspecto podría considerarse en los algoritmos y no constituir un inconveniente sino una ventaja.

Tabla 34. Observaciones a las preguntas para la verificación de H3

A continuación, en las conclusiones se procede a analizar los resultados para la verificación de la hipótesis.

9.5.1. CONCLUSIONES

Como se puede observar en los datos mostrados en la Tabla 33, los dos expertos consultados para la verificación de la hipótesis H3 coinciden en tres de las cuatro preguntas sobre los elementos que influyen en la verificación de la hipótesis H3 (preguntas P1-P4). Existe aparentemente un desacuerdo en la pregunta P2, la cual plantea si sería posible la exclusión de forma temporal de un signo argumentando que esta exclusión es producida por un fármaco que el paciente ha ingerido. Sin embargo, esta pregunta es la única que ha planteado observaciones al respecto, no habiendo acuerdo en su respuesta.

De los comentarios mostrados por los expertos, se puede observar que el proceso de exclusión temporal es un elemento que debe tomarse con mucha precaución, y debe plantearse que la exclusión debe formar parte de un proceso mucho más completo y complejo, donde estas exclusiones puedan ser una de las muchas posibilidades que plantea la interacción de un fármaco, tal y como apunta el experto AR-XF31 en sus observaciones, apuntando a que esta interacción no solamente puede producir un síntoma, sino incrementar otro de la enfermedad, u otros efectos.

El resto de las preguntas de la P1 a la P4 en las que coinciden, permiten confirmar en primer lugar la utilidad del proceso que se ha desarrollado en la presente tesis (P1) y su

216

aplicación en entornos médicos (P3), así como que este proceso podría ser utilizado para generar procesos más complejos que entre otras tareaspermitan generar diagnósticos múltiples (P4).

Para finalizar, y dar por concluida esta sección, la verificación final y total de la hipótesis H3 viene dada por la pregunta P5, la cual viene a ser un resumen a nivel global de las preguntas anteriores, donde ambos expertos coinciden en que la hipótesis propuesta puede ser verificada desde el punto de vista cualitativo presentado.

217

10. CONCLUSIONES La presente tesis doctoral se ha centrado en un exhaustivo análisis de la literatura

actual sobre los diversos aspectos que se tratan en esta tesis. Dada la temática sobre la que la esta versa (Informática Médica) es muy amplia la investigación sobre este campo y la gran cantidad de literatura que se ha tenido que revisar y valorar.

Este campo además está en constante crecimiento, lo que hace aún más difícil si cabe la tarea de recabar información actualizada y que esta no se quede obsoleta en apenas unos meses.

La investigación sobre la que se ha centrado esta tesis ha permitido demostrar que las Tecnologías Semánticas, las cuales generalmente se creen que solo son aplicables a la Web (probablemente por su nombre original: Web Semántica) y las técnicas de Inteligencia Artificial como los sistemas basados en reglas o las descripciones lógicas, también asociadas a las Tecnologías Semánticas, permiten crear sistemas de diagnóstico clínico que cumplan con unos requisitos básicos entre los que se destacan exactitud y eficiencia, destacando además el concepto de alta sensibilidad que se ha pretendido imprimir a esta investigación.

La representación del conocimiento es uno de los temas que esta tesis ha tratado, centrándose en la representación del conocimiento de tipo médico. Este conocimiento, sin embargo, como se ha visto, ya tiene actualmente diversos medios para ser representado y utilizado: terminologías, taxonomías y otros elementos similares donde dicho conocimiento es representado permitiendo que además pueda ser usado por sistemas de diversa índole. Sin embargo, dado que el conocimiento médico concreto que en esta tesis se ha tratado ha sido el relativo al del diagnóstico diferencial, era necesaria una redefinición de los actuales elementos de representación del conocimiento existentes. La motivación de esta redefinición, expuesta previamente, estaba basada en la gran cantidad de términos que las terminologías médicas estudiadas poseían, siendo gran cantidad de los términos de las mismas completamente innecesarios para un entorno de sistemas de diagnóstico clínico, donde solo unos determinados tipos de conceptos intervienen a la hora de realizar un diagnóstico.

Aparte de la representación del conocimiento usado en el proceso del diagnóstico diferencial, era necesaria la generación de una serie de elementos de inferencia cuyo objetivo era tratar verificar las hipótesis planteadas. La primera solución aplicada, basada en Descripciones Lógicas, permitió observar como el uso de este elemento permitía verificar parcialmente las hipótesis, pero sin embargo generaba una serie de problemas referidos al rendimiento. Por este motivo se decidió la aplicación de reglas, en formato Jena Rules, las cuales permiten realizar una “emulación” del concepto de negación, necesario para establecer asunción de mundo cerrado (CWA) que permite la generación de diagnósticos que cumplan las condiciones de exactitud necesarias, así como la faceta de la alta sensibilidad expuesta. Estas mismas reglas fueron aplicadas para generar la solución que permitiera verificar la hipótesis del diagnóstico mediante inferencia multinivel, la cual era una de las hipótesis en la que recae una gran importancia en el desarrollo de esta tesis, y sobre la cual se ha planteado una solución que ha sido verificado mediante la generación de casos clínicos donde esta faceta pudiera ser aplicada.

La implementación de los sistemas, creados con el objetivo de verificación de las hipótesis planteadas, solo permitían verificar parte de estas (la capacidad de generar un proceso de inferencia multinivel, de un proceso de alternativas de diagnóstico y la aplicación de las tecnologías semánticas y de Inteligencia Artificial). Debido a esto, era necesaria la generación de un proceso de evaluación que permitiera verificar las

218

subhipótesis relacionadas con la exactitud y la eficiencia de los sistemas. Para ello, el proceso de evaluación, basado en técnicas de clasificadores, donde se añadió un coeficiente adicional (MCC) permitió obtener datos muy interesantes sobre el comportamiento del sistema a la hora de diagnosticar cada enfermedad de la base de conocimiento, así como el comportamiento general del mismo e incluso de los expertos que apoyaron esta evaluación.

De esta evaluación se pudieron extraer conclusiones muy interesantes, ya que a pesar de que en este documento solo se muestra un resumen de los resultados obtenidos a nivel global de la base de conocimiento, en los datos obtenidos originalmente se podía consultar mucha más información referida a, por ejemplo, el comportamiento de los expertos o del sistema generado para cada enfermedad, analizando además cada parámetro medido por separado. De estos resultados también se obtuvieron muy interesantes en lo que respecta a la capacidad de alta sensibilidad del sistema. Esta capacidad, que vista de forma externa podría ser tachada de poseer “extrema sensibilidad” ha demostrado sin embargo con los resultados obtenidos ser una característica muy interesante para ser aplicada en entornos reales, ya que a pesar de que, diciéndolo de una forma más mundana, el sistema “pueda saltar” con muy poca información, la evaluación ha demostrado que esto es un hecho positivo ya que los resultados proporcionados en el fondo, son correctos.

Cabe destacar además de esta evaluación otra conclusión bastante interesante, relativa a la simplificación del conocimiento médico. Este conocimiento, es altamente complejo y es muy difícil establecer relaciones que generen reglas que den lugar a un sistema que pueda proporcionar unos resultados que se consideren “correctos” desde el punto de vista médico. Sin embargo, en el desarrollo de la tesis ciertas asunciones y simplificaciones han tenido que ser realizadas con el objetivo de permitir un modelado simple con respecto al conocimiento médico del doctorando. Inicialmente se podría estimar que estas simplificaciones darían lugar a posibles errores o fallos en el diagnóstico. Sin embargo, la evaluación ha demostrado que, lejos de ser el sistema perfecto (obtener un 100% de exactitud en las principles métricas como Accuracy sería dicha perfección) obtiene resultados lo suficientemente buenos y coherentes para ser tenidos en cuenta, ya que en muchas de las métricas (incluida Accuracy) el sistema ha sido capaz de obtener incluso mejores resultados que los expertos. De esto se extrae que esta simplificación realizada en el modelaje del conocimiento al final ha resultado positiva y podrían por lo tanto en el futuro aplicarse estas simplificaciones.

A modo de resumen, las conclusiones finales que se obtienen de esta investigación son que la aplicación de las Tecnologías Semánticas permite la generación de sistemas exactos y eficientes en el campo del diagnóstico diferencial en medicina, generando sobre todo elementos de representación del conocimiento en el dominio del diagnóstico diferencial reutilizables e interoperables.

219

11. FUTURAS LI NEAS DE INVESTIGACIO N La investigación realizada ha lanzado una serie de posibles líneas de investigación

futuras a lo largo de todo el proceso de creación de esta tesis. En primer lugar, un detalle a tener en cuenta durante la realización de la misma, es que los inputs que recibe el sistema que permite verificar las hipótesis se asume que son interpretados por el médico e introducidos directamente. Una de las posibleas líneas futuras por lo tanto que se podrían abordar para la mejora del proceso de toma de datos es una extracción automática de términos que permitan, a partir de un caso clínico, aislar aquellos elementos de carácter clínico que puedan ser relevantes como entradas del sistema de diagnóstico propuesto.

Asimismo, otra línea futura que debería ser tomada en cuenta es la referida a la población automática de la ontología que contiene el conocimiento. Este aspecto como se ha comentado previamente es bastante delicado dado que se requiere que el conocimiento que el sistema maneje debe ser validado por un experto. Sin embargo, existen ciertas bases de conocimiento existentes que permiten obtener información sobre las relaciones entre las entidades médicas participantes en el proceso de diagnóstico diferencial. Esta información podría ser útil para la generación de un proceso automático o semi-automático que permitiera poblar la ontología que contiene la base de conocimiento, con el objetivo fundamental de expandirla de forma fácil y rápida.

La aplicación vista en ADONIS y SEDELO de las descripciones lógicas a la hora de definir las relaciones existentes entre los conceptos del diagnóstico diferencial planteó una serie de cuestiones en lo que se refiere a la eficiencia de los sistemas que hagan uso de este tipo de técnicas. Un posible enfoque futuro que se debería investigar es el de generar sistemas que permitan el diagnóstico distribuido como el generado en trabajos previos (Rodríguez-González et al., 2011c), permitiendo la generación de un proceso de diagnóstico más eficiente usando las tecnologías ya mencionadas.

Otro trabajo que se tiene que tener en cuenta para aplicaciones futuras y que es de vital importancia es el que se menciona en la verificación de la hipótesis H3, donde el proceso de alternativas de diagnóstico que permita, un diagnóstico múltiple, o asociar posibles reacciones a fármacos con un diagnóstico es indispensable.

Para finalizar, uno de los aspectos más importantes que se debe establecer como líneas futuras es el relacionado con la mejora del proceso de diagnóstico. Actualmente, el proceso de diagnóstico implementado mediante el uso de relaciones entre conceptos y el uso de reglas permite la generación de un sistema con alta sensibilidad, algo que era uno de los objetivos principales que se pretendía conseguir. Dado que la mayoría de los casos clínicos que se presentan hoy en día en una consulta se suelen componer de un conjunto de indicios relativamente grande, la alta sensibilidad del sistema no se ve afectada de forma negativa por este número de indicios. Sin embargo, en el hipotético caso de que se presentaran casos clínicos donde el número de indicios que el sistema debiera considerar fuera demasiado bajo, esta sensibilidad del sistema podría traducirse en resultados que si bien desde un punto de vista clínico, basándose en la literatura y en la lógica empleada, serían correctos, podrían plantear dudas sobre la eficiencia real del sistema. Debido a esto, una de las futuras líneas de investigación que se deberían seguir sería la de mejorar algunos de estos aspectos, de tal forma que se establecieran restricciones diagnósticas dependiendo del número de inputs (ciertas enfermedades solo se diagnosticarán si se establece un número determinado de inputs que coincidan con la patología), o del contenido de estos inputs (patologías que solo se mostrarían como resultado de un diagnóstico en el caso de que se asegure la presencia de determinados indicios que se podrían considerar inherentes a la enfermedad).

220

12. SUMMARY The presented thesis, entitled “Application of semantic technologies for the creation

of high sensitivity medical differential diagnosis intelligent systems”, has been developed with the aim of demonstrating that the application of semantic technologies allows the creation of high sensitivity medical differential diagnosis systems.

In order to provide a better understanding of this summary, this chapter will be divided in several sections which will represent the main chapters that have been presented before.

12.1. STATE OF THE ART

The state of the art of this thesis has been divided in two main parts. In the first part, a wide analysis of the research and the systems related to the main topic of the thesis was presented, focusing on these systems, which have been developed with the aim of providing differential diagnosis systems with a general purpose. Among these main researches we can enhance some works such as MYCIN (Shortliffe & Buchanan, 1975), DXPlain (Hupp et al., 1986), Isabel (Graber & Mathew, 2008) and DiagnosisPro (Aronson, 1997).

In the second part of the state of the art a brief analysis of the main technologies which has been used to verify the thesis hypothesis was presented. Between these technologies we should mention the Semantic Technologies as part of Artificial Intelligence (Berners-Lee, 2006), Rule-based systems, logic-based inference, and decision support systems technologies.

12.2. HYPOTHESIS

As discussed above, the main research done could be summarized as a research based on demonstrating the use of semantic technologies for developing medical differential diagnosis systems.

The research has been specifically focused on verifying if these technologies represent a good technological support for developing high sensitivity diagnosis systems. However, apart from this main hypothesis, other research hypotheses were defined in order to provide an accurate research definition.

Basically, three hypotheses were defined:

1. The use of semantic technologies allows the creation of high sensitivity medical differential diagnosis with accuracy and efficiency. The concept high sensitivity makes reference to the ability of a system to provide results even when the number of inputs is too low.

2. It is possible to solve the multilevel diagnosis applying these technologies. Multilevel diagnosis makes reference to the ability of determining a disease even when the diagnosis criterion of the disease is formed by other diseases.

3. It is possible to create a process which calculates diagnosis alternatives in the approach in which the signs or symptoms of a disease were induced by drug consumption, and for hence, its presence is not a finding of the pathology to diagnose.

221

12.3. KNOWLEDGE REPRESENTATION

The representation of the knowledge was one of the main problems which were set out at the beginning of this thesis. An extended analysis of the situation was done in order to achieve the best solution. The solution which was finally chosen was the use of diagnostic criteria as representation model. In the analysis performed to check the different terminologies or ontologies which nowadays exist in healthcare domain we have included SNOMED-CT (Rogers & Bodenreider, 2009), Open GALEN (Amaral et al., 2000) and OBO-Foundry (Smith et al., 2005) among others.

After a painstaking analysis of these systems and models, a new ontological model was developed in order to achieve the necessities to verify the hypotheses. The model was developed using SNOMED-CT as a terminology model. A new ontology architecture model was developed using root ontology as meta-ontology to define the relations which exist between the diseases and the findings (signs, symptoms and other diseases).

Another important factor in the knowledge representation process is the information source. In this chapter, where the information comes from is explained. In this case, given that we are working with very sensitive information (medical information, and more concretely, diagnosis information, it should come from reliable sources which allow the validity of the data to be guaranteed), the information source used was medical books which include titles such as Harrisons (Harrison, 2009). A deep research was done with these books as medical reference to extract the information related to the disease, in order to generate the necessary knowledge which will be used in the inference process. It is important to highlight that the use of automatic process shouldn’t be followed because the reliability of the information provided by automatic process is very low. The medical information should be contrasted by experts.

The knowledge representation chapter also includes information about how the ontology population process was done. This process includes the generation of the instances which the diseases and findings represent, the relations between these instances and the generation of the rules.

12.4. ODDIN, ADONIS AND SEDELO

Chapters 5 and 6 show information about the first version of the systems developed to verify the hypotheses of the thesis.

ODDIN (García-Crespo et al., 2010), was the first developed thesis version. This system was developed using a legacy representation knowledge model to the one presented in the representation knowledge chapter. In ODDIN, a first version of the representation model was developed using description logics. The preliminary results of this development show that the appliance of description logics to this field provides very poor results regarding the temporal efficiency of the system. However, also a first version using Jena Rules was developed, providing much better results than the previous approach. Nevertheless, the main lack of ODDIN system was in the fact that the system was not able to deal with multilevel diagnosis problem. The system was able to perform simple and complex diagnosis, but it was not ready to perform multilevel diagnosis.

One important factor that was also developed in the ODDIN system is the ability to generate multiple alternative diagnosis results depending on the drugs which the patient is taking; this factor will be used for the verification of hypotheses H3.

ADONIS (Rodríguez, 2009b; Rodríguez et al., 2011) and SEDELO (Rodríguez-González et al., 2011a) systems suppose an improvement to the previous ones (ODDIN).

222

The systems were developed based on the description logics of ODDIN. A new version of these description logics was developed in order to allow these systems to perform multilevel diagnosis. ADONIS system solves the multilevel diagnosis problem partially, adding the problematic of making normal inference impossible in some contexts.

In SEDELO, a new improvement to the description logics developed in ADONIS was done in order to solve the problems introduced in this system. However, the efficiency problem arose once again, making the use of the system in real environments impossible.

12.5. MDSS-OPM

MDSS-OPM is the final version of the systems developed in this thesis. The main difference between this system and the previous ones is the ability to perform multilevel diagnosis with efficiency. Basically, the new model of rules which allows the performance of the multilevel diagnosis is presented in this chapter. The rule language used, as in ODDIN, is Jena Rules language. The reason to use this language is based on the capacity of this language to implement a negation process, which is not possible to do with other semantic rule languages like SWRL, for example. This chapter also includes an interesting approach to understand the inference process which is behind the Jena rules engine and the new ontology design based (Rodríguez-González et al., 2012).

Another important aspect which is presented in this chapter is a probabilistic model based on epidemiological data. This model is presented as a proof-of-concept model for calculating the probability of diagnosing a disease based on epidemiological data.

12.6. EVALUATION

The evaluation chapter shows the main aspects of the evaluation process followed in this thesis.

In the evaluation of a Diagnosis Decision Support System (DDSS) several approaches could be followed. In this chapter, an analysis of the main tools which are normally used for the evaluation of this kind of tools is done. The evaluation of this type of systems is normally done following three main approaches: evaluation of diagnosis accuracy, evaluation of temporal and spatial complexity and evaluation of the techniques employed.

The analysis of the state of the art reveals that there is an important lack of standard methodologies to measure these approaches. Within the context of this thesis, the most important factors to measure are accuracy and temporal complexity. For this reason, given this lack, a standard methodology for the measurement of the accuracy and temporal complexity of the approach developed has been created.

The methodology created is based on the work done by Kaplan (2001). Kaplan states that the measurement of DDSS accuracy should be done following one of these three approaches: 1) comparison of the system with other systems; 2) comparison of the system with a gold standard; or 3) comparison of the system with experts.

Given that the comparison with other systems is not applicable (different knowledge bases and different evaluation approaches) and there is not current gold standard to compare the results, the option which will be followed is the comparison of the system with experts.

For this, a methodology based on the creation of clinical cases to be solved by both experts and the system was developed. Once the results are provided by experts

223

(assessors) and the system, an arbitration process is made to confirm the results provided (using other experts (referees) for this purpose). Once the arbitration process is finished, binary classifier metrics (Precision and Recall (Sensitivity) (Makhoul et al., 1999), Accuracy and Specifity - PRAS) are used to measure the accuracy of the system. Apart from these basic metrics, a Matthews Correlation Coefficient (MCC (Matthews, 1975; Baldi et al., 2000)) is used. MCC metric provides balanced results of PRAS metrics, allowing us to have a single result of the comparison between system and assessors.

This methodology includes the analysis of temporal efficiency of the system and the assessors and the correlation which exists among the referees that participate in the arbitration process.

Finally, in this section, an analysis of the techniques used in the development of the thesis compared with other techniques was done.

12.7. VERIFICATION

The verification of the hypothesis set previously is done by using the results of the evaluation. The first hypothesis, which states that “The application of semantic technologies allows the creation of high sensitivity medical differential diagnosis with accuracy and efficiency”, was verified using the results provided by the evaluation.

Concretely, the verification was based on the premise that we know that the developed systems for the verification of the hypotheses used semantic technologies. Based on this, we only need to verify that the developed system is a high sensitivity system (high recall rate) which is accurate (high MCC rate) and efficient. Once we check the results of the evaluation, we can see that the recall rate of the system is 97.92 against 70.38% of the assessors. In the case of MCC rate we obtain a 93.59% for the system and a 61.40% for the assessors. In both cases, a statistical analysis using a T-Student confirms that there are significant differences between system and assessors, confirming this part of the hypothesis from a statistical point of view. In the case of the efficiency, both the tables showed in this part of the evaluation and the T-Student performed again show significant differences between system and assessors.

In the case of the second hypothesis, which states that “It is possible to solve the multilevel diagnosis applying these technologies”, it was verified by using the results provided in Verification section. In fact, this hypothesis could be automatically verified when hypothesis H1 was verified, given that the system was developed to perform multilevel diagnosis. However, to provide a better understanding of this hypothesis and how it was verified, the verification chapter shows more information about this verification.

Finally, the third hypothesis, which states that “It is possible to create a process which calculates diagnosis alternatives in the approach in which the signs or symptoms of a disease were induced by drug consumption, and for hence, its presence it is not a finding of the pathology to diagnose”, was verified by a qualitative evaluation using referees.

12.8. CONCLUSIONS

The research of this thesis was focused on demonstrating the application of semantic technologies for the creation of high sensitivity diagnosis decision support systems.

In this development, the requirements of accuracy and efficiency to the developed systems are included.

224

Knowledge representation is one of the topics which this thesis has dealt with, focusing on medical knowledge representation. However, this knowledge, as seen before, has several ways to be represented and used, using terminologies, taxonomies and similar elements. However, given that the concrete medical knowledge which this thesis makes use of is the one that depends on the differential diagnosis domain, a redefinition of the current knowledge representation elements was necessary.

Apart from the knowledge representation used in the diagnosis process, the generation of a set of inference elements with the aim of verifying the hypotheses set out was also necessary. The first solution which was applied, allows the verification of these hypotheses partially, however, it generates a set of problems refereed to the efficiency. For this reason, using rule-based systems in Jena Rules format instead of description logics was agreed. The reason to use Jena Rules was that this rule language allows emulating the negation concept, necessary to establish a close world assumption (CWA) which allows the generation of diagnosis which fulfill with the requirements of high sensitivity, accuracy and efficiency. These rules were also applied to generate the solution which allows performing multilevel diagnosis.

The implementations of the systems created with the aim of verifying the hypotheses also need an evaluation process to confirm this verification. For this reason, an evaluation methodology was created to evaluate the accuracy and efficiency of the systems created. In this context, binary classifier metrics where used, including Precision, Recall (Sensitivity), Accuracy and Specifity, and adding a final summary metric: Matthews Correlation Coefficient (MCC).

In this document, in the evaluation and verification chapters only summary results were showed. However, the evaluation performed reveals very interesting results like the behavior of the assessors in the diagnosis of each of the diseases which are included in the knowledge base or the reason behind the high sensitivity results among several others.

To sum up in only one sentence, the final conclusion from this research is that the application of semantic technologies allows the creation of accurate and efficient high sensitivity diagnosis systems, which perform multilevel diagnosis using ontologies as knowledge representation model.

225

13. BIBLIOGRAFI A Abbass, H. (2002). An Evolutionary Artificial Neural Networks Approach for Breast

Cancer Diagnosis. Artificial Intelligence in Medicine 25(3), 265-281.

Adlassnig, K., Kolarz, G., Scheithauer, W., Effenberger, H. & Grabner, G. (1985).

CADIAG: approaches to computer-assisted medical diagnosis. Computers in biology and

medicine 15(5), 315-335.

Adlassnig K.P., Scheithauer, W. (1989). Performance Evaluation of Medical Expert

Systems Using ROC Curves. Computers and Biomedical Research, 297-313.

AEMPS (2007). Real Decreto 1344/2007, de 11 de Octubre, por el que se regula la

farmacovigilancia de medicamentos de uso humano. Agencia española de medicamentos y

productos sanitarios.

Agrawal, R., Mannila, H., Srikant, R., Toivonem, H. & Verkamo, A. (1995). Fast

Discovery of Association Rules. Advances in Knowledge Discovery and Data Mining, 307-328.

Ahn, H. & Kim, K. (2009). Global optimization of case-based reasoning for breast

cytology diagnosis. Expert Systems With Applications 36, 724-734.

Aikem, M., Vanjami, M. & Krosp, J. (1995). Group Decision Support Systems. Review

of Business 16.

Alayón, S., Robertson, R., Warfield, S. & Ruiz-Alzola, J. (2007). A fuzzy system for

helping medical diagnosis of malformations of cortical development. Journal of Biomedical

Informatics 40, 221-235.

Altman, D. & Bland, J. (1994b). Statistics Notes: Diagnostic tests 3: receiver operating

characteristic plots. British Medical Journal 309, 188.

Altman, D. & Bland, J. (1994a). Statistics Notes: Diagnostic tests 1: sensitivity and

specificity. British Medical Journal 308, 1552.

Altman, D. & Bland, J. (1999). Statistics Notes: Diagnostic tests 2: predictive values.

British Medical Journal 309, 102.

Alves, V., Neves, J., Maia, M. & Nelas, L. (2001). A Computational Environment for

Medical Diagnosis Support Systems. Medical Data Analysis 2199, 42-47.

Amaral, M., Roberts, A. & Rector, A. (2000). NLP techniques associated with the

OpenGALEN ontology for semi-automatic textual extraction of medical knowledge: abstracting

and mapping equivalent linguistic and logical constructs. Proceeding of AMIA Annual

Symposium, 76-80.

Ammenwerth, E., Schnell-Inderst, P., Machan, C. & Siebert, J. (2008). The Effect of

Electronic Prescribing on Medication Errors and Adverse Drug Events: A Systematic Review.

Am. Med. Inform. Assoc 15, 585-600.

Anastasio, M., Yoshida, H., Nagel, R., Nishikawa, R. & Doi, K. (1998). A genetic

algorithm-based method for optimizing the performance of a computer-aided diagnosis scheme

for detection of clustered microcalcifications in mammograms. Medical Physics 25(9).

Argimon Pallás, J. & Jiménez Villa, J. (2000). Métodos de investigación clínica y

epidemiológica. Harcourt.

226

Arocha, J.F., Dongwen, W., Vimla L.P. (2005). Identifying reasoning strategies in

medical decision making: A methodological guide. Journal of Biomedical Informatics 38, 154–

171.

Aronson, A. (1997). DiagnosisPro: The Ultimate Differential Diagnosis Assistant.

Journal Of the American Medical Association 277(5), 426.

Asbury, A.K. and Comblath, D.R. (1990). Assessment of current diagnostic criteria for

Guillain-Barré syndrome. Annals of Neurology 27(S1), S21-S24

Arroyo-Figueroa, G. & Sucar, L. (2005). A temporal bayesian network for diagnosis

and prediction. Applied Intelligence 23(29), 77-86.

Ausina-Ruiz, V. & Moreno-Guillén, S. (2006). Tratado SEIMC de Enfermedades

Infecciosas y Microbiología Clínica. SEIMC treatise of Infectious Diseases and clinic

microbiology. Médica Panamericana.

Baader, F., Calvanese, D., McGuiness, D., Nardi, D. & Patel-Schneider, P. (2003). The

Description Logic Handbook. Cambridge University Press.

Baldi, P., Brunak, S., Chauvin, Y., Andersen, C. A. F. & Nielsen, H. (2000). Assessing

the accuracy of prediction algorithms for classification: an overview. Bioinformatics 16, 412-

424.

Baneyx, A., Charlet, J. & M.C., J. (2006). Methodology to Build Medical Ontology

from Textual Resources. AMIA Annual Symposium, 21-25.

Banks, G. (1986). Artificial intelligence in medical diagnosis: the

INTERNIST/CADUCEUS approach. Critical Reviews in Medical Informatics 1(1), 23-54.

Barnett, G., Cimino, J., Hupp, J. & Hoffer, E. (1987). DXplain - an interactive

diagnostic knowledge base: experience with knowledge acquisition and program evaluation.

Proc. of Eleventh SCAMC, 150-154.

Barnett, G., Cimino, J., Hupp, J. & Hoffer, E. (1987). DXplain. An evolving diagnostic

decision-support system. Journal of the American Medical Association.

Barnett, G., Famiglietti, K., Kim, R., Hoffer, E. & Feldman, M. (1998). DXplain on the

Internet. Proceedings of the AMIA Annual Symposium, 607-611.

Barnett, G., Hoffer, E., Kim, R. & Famiglietti, K. (1996). Dxplain on the World Wide

Web. American Medical Informatics Association, 988.

Barnett, G., Hoffer, E., Packer, M., Famiglietti, K., Kim, R., Cimino, C., Elkin, P.,

Feldman, M., Forman, B., Oliver, D. & Kahn, J. (1990). DXPLAIN - Important issues in the

development of a computer-based decision support system. Proc. of Fourteenth SCAMC, 1013.

Barnett, G., Hoffer, E., Packer, M., Famiglietti, K., Kim, R., Cimino, C., Feldman, M.,

Oliver, D., Kahn, J., Jenders, R. & Gnassi, J. (1992). DXplain - a demonstration and discussion

of a diagnostic decision support system. Proc. of 16th SCAMC, 822.

Barnett, G., Hoffer, E., Packer, M., Famiglietti, K., Kim, R., Feldman, M., Forman, B.

& Oliver, D. (1991). DXplain - demonstration and discussion of a diagnostic clinical support

system. Proc. of The Fifteenth SCAMC, 878.

Bates, D., Cohen, M., Leape, L., Marc, J., Shabot, M. & Sheridan, T. (2001). Reducing

the frequency of errors in medicine using information technology. The Journal of the American

Informatics Medical Association 8(4), 299-308.

227

Baud, R., Lovis, C., Rassinoux, A., Michel, P. & Scherrer, J. (1998). Automatic

extraction of linguistic knowledge from an international classification. Studies in health

technology and informatics 52, 581-5.

Bauer, B., Lee, M., Bergstrom, L., Wahner-Roedler, D., Bundrick, J., Litin, S., Hoffer,

E., Kim, R., Famiglietti, K., Barnett, G. & Elkin, P. (2002). Internal Medicine Resident

Satisfaction with a Diagnostic Decision Support System (Dxplain) Introduced on a Teaching

Hospital Service. Journal Of the American Medical Informatics Association, 31-35.

Baxt, W. (1991). Use of an Artificial Neural Network for the Diagnosis of Myocardial

Infarction. Annals of Internal Medicine 115(11), 843-848.

Baxt, W. & Skora, R. (1996). Prospective validation of artificial neural network trained

to identify acute myocardial infarction. The Lancet 347(8993), 12-15.

Beckett, D. & Berners-Lee, T. (2008). Turtle - Terse RDF Triple Language. W3C.

Bennett, J. & Glasziou, P. (2003). Computerised reminders and feedback in medication

management: a systematic review of randomised controlled trials. Medical Journal of Australia

178(5), 217-222.

Berger, A. (2000). GIDEON: A Computer Program for Diagnosis, Simulation, and

Informatics in the Fields of Geographic Medicine and Emerging Diseases. Emerging Infectious

Diseases Conference, 7(3), 550.

Bergeron, B. (1992). Iliad: a diagnostic consultant and patient simulator. M.D.

computing: computers in medical practice 9(2), 76-78.

Berner, E. (1999). Testing system accuracy. Clinical decision support systems: theory

and practice., 61-74.

Berner, E., Maisiak, R., Cobbs, G. & Taunton, O. (1999). Effects of a decision support

system on physicians’ diagnostic performance. Journal Of the American Medical Association

6(5), 420-427.

Berner, E. S. (2007). Clinical Decision Support Systems. Springer, New York.

Berners-Lee, T. (2006). Artificial Intelligence and the Semantic Web. W3C Talk.

Berners-Lee, T., Hendler, J. & Lassila, O. (2001). The Semantic Web. Scientific

American 284(5), 34-44.

Bertaud-Gounot, V. and Duvauferrier, R. and Burgun, A. (2011). Ontology and medical

diagnosis. Informatics for Health and Social Care 0(0), 1-11

Beynon, M., Buchanan, K. & Tang, Y. (2001). The application of a fuzzy-rule-based

system in an exposition of the antecedents of sedge warbler song flight. Expert Systems. The

journal of knowledge engineering 21(1), 1-10.

Binaghi, E. (1990). A fuzzy logic inference model for a rule-based system in medical

diagnosis. Expert Systems 7(3), 134-141.

Bodenreider, O. (2004). The Unified Medical Language System (UMLS): integrating

biomedical terminology. Nucleic Acids Research 32, D267-D270.

Boegl, K., Adlassing, K., Hayashi, Y., Rothenfluh, T. & Leitich, H. (2004). Knowledge

acquisition in the fuzzy knowledge representation framework of a medical consultation system.

Artificial Intelligence in Medicine 30, 1-26.

228

Boley, H., Tabet, S. & Wagner, G. (2003). Design Rationale of RuleML: A Markup

Language for Semantic Web Rules. Proceedings of International Semantic Web Conference,

381-401.

Bottorff, M. (2006). Statin safety and drug interactions: clinical implications. American

Journal Of Cardiology 97, 27-31.

Bounds, D., Lloyd, P., Mathew, B. & Waddel, G. (1988). A Multi Layer Perceptron

Network for the Diagnosis of Low Back Pain. Neural Networks 2, 481-489.

Brase, J. & Nejdl, W. (2004). Ontologies and Metadata for eLearning. Handbook on

Ontologies. Springer-Verlag.

Brause, R., Hamker, F. & Paetz, J. (2001). Septic Shock Diagnosis by Neural Networks

and Rule Based Systems. Computational Intelligence Techniques in Medical Diagnosis and

Prognosis.

Brause, W. (2001). Medical Analysis and Diagnosis by Neural Networks. Medical Data

Analysis 2199, 1-13.

Bravata, D., Sundaram, V., McDonald, K., Smith, W., Szeto, H. & Schleinitz, M.

(2004). Evaluationg Detection and diagnostic decision support systems for bioterrorism

response. Emerging infectious diseases, 10(1).

Brewka, G. (1991). Nonmonotonic Reasoning: Logical Foundations of Commonsense.

Cambridge Tracts in Theoretical Computer Science.

Brickley, D. & Guha, R. (2004). RDF Vocabulary Description Language 1.0: RDF

Schema. W3C.

Brickley, D. & Miller, L. (2005). FOAF Vocabulary Specification. XMLNS.

Broverman, C. (1999). Standards for clinical decision support systems. Journal of

Healthcare Information Management 13(2), 23-31.

Bruce, V. (2010). MMR Risks, Autism & Finding Balance.

Bucci, G. and Sandrucci, V. and Vicario, E. (2011). Ontologies and Bayesian Networks

in Medical Diagnosis. Proceedings of the 44th Hawaii International Conference on System

Sciences.

Burgueño, M., García Bastos, J. & González Buitrago, J. (1995). Las curvas ROC en la

evaluación de las pruebas diagnósticas. Med Clin (Barc) 104, 661-670.

Burgun, A. and Bodenreider, O. and Jacquelinet, C. (2005). Issues in the classification

of disease instances with ontologies. Studies in Health Technology and Informatics 116, 695-

700

Cabello López, J. & Pozo Rodríguez, F. (1997). Estudios de evaluación de las pruebas

diagnósticas en cardiología. Revista española de Cardiología 50, 507-519.

Cadoli, M. & Lenzerini, M. (1994). The complexity of propositional closed world

reasoning and circumscription. Journal of Computer and System Sciences 48, 255-310.

Camps, D., Recuero, Y., Avila, R. & Samar, M. (2006). Herramientas para la

recuperación de la información: Los términos MeSH (Medical Subject Headings). MedUNAB

9(1).

229

Carpenter, W., Strauss, J. & Muleh, S. (1973). Are There Pathognomonic Symptoms in

Schizophrenia? An Empiric Investigation of Schneider's First-Rank Symptoms. Archives of

General Psychiatry 28(6), 847-852.

Castro, J., Castro-Sánchez, J. & Zurita, J. (2001). Use of a fuzzy machine learning

technique in the knowledge acquisition process. Fuzzy Sets and Systems 123, 207-320.

Castro-Sanchez, J., Jennings, N., Luo, X. & Shadbolt, N. (2004). Acquiring domain

knowledge for negotiating agents: a case of study. International Journal of Human-Capturer

Studies 61, 3-31.

Cepeda-Diaz, L.M. et al. (2010). Monografía sobre Inteligencia Artificial. Disponible

en: http://www.monografias.com/trabajos16/la-inteligencia-artificial/la-inteligencia-

artificial.shtml . Última verificación: 9 de Noviembre de 2011.

Ceusters, W., Smith, B. & Flanagan, J. (2003). Ontology and Medical Terminology:

Why Description Logics Are Not Enough. Proceedings of TEPR.

Chai, X., Deng, L., Yang, Q. & Ling, C. (2004). Test-Cost Sensitive Naive Bayes

Classification. Fourth IEEE International Conference on Data Mining (ICDM’04), 51-58.

Chalmers, T., Smith, H., Blackburn, B., Silverman, B., Schroeder, B., Reitman, D. &

Ambroz, A. (1981). A method for assessing the quality of a randomized control trial. Controlled

Clinical Trials 2(1), 31-49.

Chandrasekaran, B. (1983). On Evaluating Artificial Intelligence Systems for Medical

Diagnosis. AI Magazine 4(2).

Chandrasekaran, B., Gomez, F., Mittal, S. & Smith, J. (1979). An approach to medical

diagnosis based on conceptual structures. International Joint Conference On Artificial

Intelligence, 134-142.

Charnaik, E. (1983). The Bayesian Basis of Common Sense Medical Diagnosis.

Proceedings of the National Conference on Artificial Intelligence, AAAI, 70-73.

Cheeseman, P. (1983). A method of computing generalized Bayesian probability values

for expert systems. Proceedings of the Eighth international joint conference on Artificial

intelligence 1.

Chen, S. (1994). A weighted fuzzy reasoning algorithm for medical diagnosis. Decision

Support Systems 11(1), 37-43.

Cimino, J. (1998). Desiderata for controlled medical vocabularies in the twenty-first

century. Methods of information in medicine 37, 394-403.

Cimino, J. (1996). Review paper: coding systems in health care. Methods of information

in medicine 35, 273-284.

Cimino, J., Clayton, P., Hripcsak, G. & Johson, S. (1994). Knowledge-based

approaches to the maintenance of a large controlled medical terminology. Journal Of the

American Medical Informatics Association 1, 35-50.

Cimino, J., Hripcsak, G., Johnson, S. & Clayton, P. (1989). Designing an introspective

multipurpose, controlled medical vocabulary. Thirteenth Annual Symposium on Computer

Applications in Medical Care (SMAC), 512-518.

Cimino, J., Hupp, J., Hoffer, E. & Barnett, G. (1987). Demonstration of Dxplain - an

interactive diagnostic knowledge base. Proc. of Eleventh SCAMC.

http://www.monografias.com/trabajos16/la-inteligencia-artificial/la-inteligencia-artificial.shtml

http://www.monografias.com/trabajos16/la-inteligencia-artificial/la-inteligencia-artificial.shtml

230

Cimino, J., Hupp, J., Hoffer, E., Famiglietti, K. & Barnett, G. (1987). DXplain: an

interactive knowledge base for assistance in medical diagnostic decisions. Proc. of Ninth

Annual Conference of the Engineering in Medicine and Biology Society, 1528-1529.

Clarke, K. e. a. (1994). Methodology for evaluation of knowledge-based systems in

medicine. Artificial Intelligence in Medicine 6(2), 107-121.

Cleverdon, C. W., Mills, J. & Keen, E. M.of Aeronautics, C., (ed.). (1966). Factors

determining the performance of indexing systems. Cranfield, U.K.

Cohen, J. (2004). Bioinformatics - An Introduction for Computer Scientists. ACM

Computing Surveys 36(2), 122-158.

Colantonio, S., Martinelli, M., Morono, D., Salvetti, O., Perticone, F., Sciacqua, A.,

Conforti, D. & Gualtieri, A. (2007). An Approach to Decision Support in Heart Failure.

Semantic Web Applications and Perspectives 314(46).

Coletti, M. & Bleich, H. (2001). Medical Subject Headings Used to Search the

Biomedical Literature. Journal Of the American Medical Informatics Association 8(4), 317-323.

Compton, P., Horn, R., Quinlan, R. & Lazarus, L. (1989). Maintaining an expert

system. Applications of Experts Systems, 366-385.

Cooper, G. (1984). NESTOR: A Computer-Based Medical Diagnostic Aid That

Integrates Causal and Probabilistic Knowledge. Unpublished doctoral disseration, University of

Stanford.

Courtney, J., Paradice, D. & Nassar, M. (2007). A knowledge-based dss for managerial

problem diagnosis. Decision Sciences 18(3), 273-299.

Cowell, L. & Smith, B. (2010). Infectious Disease Ontology. Infectious Disease

Informatics, 373-395.

Cowell, R. G., Dawid, A. P., Lauritzen, S. L. & Spiegelhalter, D. J.Harrisonburg, V.,

(ed.). (1999). Probabilistic networks and expert systems. Springer.

Crevier, D. (1993). AI: The Tumultuous Search for Artificial Intelligence. BasicBooks.

Cuenca-Grau, B., Horrocks, I., Motik, B., Parsia, B., Patel-Schneider, P. & Sattler, U.

(2008). OWL 2: The next step for OWL. Journal of Web Semantics 6(4), 309-322.

Cundick, R., Turner, C., Lincoln, M., Buchanan, J., Anderson, C. & Warner, H.R.Jr.

Bouhaddou, O. (1989). ILIAD as a Patient Case Simulator to Teach Medical Problem Solving.

Proceedings of the Annual Symposium on Computer Application in Medical Care 8, 902-906.

Das, A., Wu, W. & McGuiness, D. (2001). Industrial Strength Ontology Management.

Proceedings of Semantic Web Workshop, 17-38.

Davies, J., Fensel, D. & van Harmelen, F. (2003). Introduction, Towards the Semantic

Web. John Wiley and Sons.

De Bliek, R. (1990). Qmr: Quick medical reference. Teaching and Learning in

Medicine 2(1), 48-49.

De Maio, C., Loia, V., Fenza, G., Gallo, M.C., Linciano, R., Morrone, A. (2011). Fuzzy

Knowledge Approach to Automatic Disease Diagnosis. IEEE International Conferences on

Fuzzy Systems.

231

Dean, B., Schachter, M., Vincent, C. & Barber, N. (2002). Causes of prescribing errors

in hospital inpatients: a prospective study. The Lancet 359(9315), 1373-1378.

Dean, M. & Schreiber, G. (2004). OWL Web Ontology Language Reference. W3C.

Der-Liden, S.V. and Valkenburg, H.A. (1984). Evaluation of Diagnostic Criteria for

Ankylosing Spondylitis. Arthritis & Rheumatism 27(4), 361-368

Diamond, L. (1991). A different view of Iliad. M.D. computing: computers in medical

practice 8(1), 46-53.

Dieng, R., Corby, O., Giboin, A. & Ribieres, M. (1999). Methods and tools for

corporate knowledge management. International Journal of Human-Computer Studies 51, 567-

598.

Ding, L., Zhou, L., Finin, T. & Joshi, A. (2005). How the Semantic Web is Being Used:

An Analysis of FOAF Documents. Proceedings of the 38th Annual Hawaii International

Conference on System Sciences, 113.

Djedidi, R. & Aufaure, M. (2007). Medical Domain Ontology Construction Approach:

A Basis for Medical Decision Support. Computer-Based Medical Systems, 509-511.

Drummond, N. & Shearer, R. (2006). The Open World Assumption. University of

Manchester.

Du, P., Feng, G., Flatow, J., Song, J., Holko, M., Kibbe, W. & Lin, S. (2009). From

disease ontology to disease-ontology lite: statistical methods to adapt a general-purpose

ontology for the test of gene-ontology associations. Bioinformatics 25.

Dujardin, B., Van der Ende, J., Van Gompel, A., Unger, J. & Van der Stuyft, P. (1994).

Likelihood ratios: a real improvement for clinical decisión making?. European Journal of

Epidemiology 10, 29-36.

Durkin, J. & Durkin, J. (1999). Expert Systems: Design and Development. Prentice Hall.

Díez, F., Mira, J., Iturralde, E. & Zubillaga, S. (1997). DIAVAL, a Bayesian expert

system for echocardiography. Artificial Intelligence in Medicine 10, 59-73.

E.C., K. J., Roberts, M., Shaffer, A. & Haddawy, P. (1997). Construction of a bayesian

network for mammographic diagnosis of breast cancer. Computers in Biology and Medicine

27(1), 19-29.

Eberhart, R., Dobbins, R. & Hutton, L. (1991). Neural network paradigm comparisons

for appendicitis diagnoses. Proceedings of the Fourth Annual Computer-Based Medical

Systems, 298-394.

Eggbird (2010). SNOB - A SNOMED Browser. Eggbird.

Elhanan, G., Socratous, S. & Cimino, J. (1996). Integrating DXplain into a clinical

information system using the World Wide Web. Proceedings of the AMIA Annual Symposium.

Elkin, P., McLatchey, J., Packer, M., Hoffer, E., Cimino, C., Studney, D. & Barnett, G.

(1989). Automated batch searching of MEDLINE for DXplain. Proc. of Thirteenth SCAMC,

436-440.

eMedicine (2011). eMedicine. http://emedicine.medscape.com/. eMedicine.

eMedicine (2010). Sign definition. Stedman Medical Dictionary Lookup!.

232

Eslami, S., De Keizer, N. & Abu-Hanna, A. (2008). The impact of computerized

physician medication order entry in hospitalized patients—A systematic review. International

Journal of Medical Informatics 77(6), 365-376.

Ess, S. M., Schneeweiss, S. & Szucs, T. D. (2003). European healthcare policies for

controlling drug expenditure. PharmacoEconomics 21(2), 89-103.

Eyssautier, M. (2006). Metodología de la investigación: desarrollo de la inteligencia.

Thomson.

Fathi-Torbaghan, M. & Meyer, D. (1994). MEDUSA: a fuzzy expert system for medical

diagnosis of acute abdominal pain. Methods of information in medicine 33(5), 522-529.

Federman, D., Concato, J. & Kirsner, R. (1999). Comparison of dermatologic diagnoses

by primary care practitioners and dermatologists. A review of the literature. Archives of family

medicine 8(2), 170-172.

Feigenbaum, E. & McCorduck, P.Addison-Wesley, (ed.). (1984). The Fifth Generation.

Feldman, M. & Barnett, G. (1991). An approach to evaluating the accuracy of DXplain.

Comput Methods Programs Biomed 35(4).

Feldman, M., Cimino, C., Hoffer, E., Packer, M., Elkin, P., Forman, B., Oliver, D.,

Bhave, S. & Barnett, G. (1990). A strategy to assess the performance of DXplain. Proc. of

American Medical Informatics Association First Annual Educational and Research Conference,

71.

Fensel, D., Horrocks, I., Van Harmelen, F., Decker, S., Erdmann, M. & Klein, M.

(2000). OIL in a Nutshell. Proceedings of the 12th International Conference on Knowledge

Engineering and Knowledge Management, 1-16.

Fensel, D., Van Harmelen, F., Horrocks, I., McGuinness, D. & Patel-Schneider, P.

(2001). OIL: An ontology infrastructure for the semantic web. IEEE Intelligent Systems 16(2),

38-45.

Fernandez-Breis, J. (2003). Un Entorno para la Integración de Ontologías para el

Desarrollo de Sistemas para la Gestión de Conocimiento. Unpublished doctoral disseration,

Universidad de Murcia.

Fickett, J. & Hayes, W. (2004). Text mining for drug discovery. European

Pharmaceutical Contractor.

First, B., Williams, B. & Spitzer, R. (1988). DTREE: Microcomputer-Assisted

Teaching of Psychiatric Diagnosis Using a Decision Tree Model. Proceedings of the Annual

Symposium on Computer Application in Medical Care 9, 377-381.

First, M., Soffer, L. & Miller, R. (1985). QUICK (QUick Index to Caduceus

Knowledge): using the INTERNIST-1/CADUCEUS knowledge base as an electronic textbook

of medicine. Computers and biomedical research 18(2), 65-137.

Fletcher, R., Fletcher, S. & Wagner, E. (1996). Clinical epidemiology: the essentials.

Baltimore: Williams and Wilkins.

Forgy, C. (1982). Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern

Match Problem. Artificial Intelligence 19, 17-37.

Forgy, C. (1979). On the efficient implementation of production systems. Unpublished

doctoral disseration, Carnegie-Mellon University.

233

Forgy, C. (1974). A network match routine for production systems. Working paper.

Friedman, C., Elstein, A. & Wolf, F. (1999). Enhancement of clinicians’ diagnostic

reasoning by computer-based consultation: a multisite study of 2 systems. Journal Of the

American Medical Association 282(19), 1851-1855.

Fuentes-Lorenzo, D., Morato, J. & Gómez, J. (2009). Knowledge Management in

Biomedical Libraries: A Semantic Web Approach. Information Systems Frontiers, 11(4), 471-

480.

Gallaire, H. & Minker, J. (1977). Logic and Data Bases, Symposium on Logic and Data

Bases. Plenum Press, New York.

Ganeshan, R., Johnson, W., Shaw, E. & Wood, B. (2000). Tutoring Diagnostic Problem

Solving. Intelligent Tutoring Systems 1839, 33-42.

García Crespo, A., Rodríguez Gonzalez, A., Mencke, M., Gómez Berbís, J. & Colomo

Palacios, R. (2010). ODDIN: Ontology-driven Differential Diagnosis based on Logical

Inference and Probabilistic Refinements. Expert Systems with Applications, 37(3), 2621-2628.

García Sanchez, F., Fernandez Breis, J., Valencia García, R., Gómez, J. & Martínez

Bejar, R. (2008). Combining Semantic Web Technologies with Multi-Agent Systems for

Integrated Access to Biological Resources. Journal of Biomedical Informatics 41(5), 848-859.

Garg, A., Adhikari, N., McDonald, H., Rosas-Arellano, M., Devereaux, P., Beyene, J.,

Sam, J. & Haynes, R. (2005). Effects of computerized clinical decision support systems on

practitioner performance and patient outcomes: a systematic review. Journal Of the American

Medical Association 293(10), 1223-1238.

Garrell i Guiu, J., Golobardes i Ribé, E., Bernardó i Mansilla, E. & Llorá i Fábrega, X.

(1999). Automatic diagnosis with genetic algorithms and case-based reasoning. Artificial

Intelligence in Engineering 13(4), 367-372.

Gelb, D.J. and Oliver, E. and Gilman, S. (1999). Diagnostic Criteria for Parkinson

Disease. Archives of Neurology 56, 33-39.

Georgakis D.C., Evens, M., Naeymi-Rad, F. Trace, D.A. (1991). Performance

Evaluation of Medical Expert Systems. Lecture Notes in Computer Science, 507, 70-76.

Goldsmith, L. (2005). VisualDx: Point of Care Visual Diagnostic Clinical Decision

Support. American Medical Informatics Association, 1177.

Gomez Berbis, J. M., Colomo Palacios, R., Mayoral, M. R. & Garcia Crespo, A. (2008).

Micro-array Information and Data Integration using SAMIDI. Encyclopedia of Artificial

Intelligence. Hershey, PA: IGI Global.

Goud, R., Hasman, A. & Peek, N. (2008). Development of a guideline-based decision

support system with explanation facilities for outpatient therapy. Computer methods and

programs in biomedicine 91(2), 145-153.

Graber, M. & Mathew, A. (2008). Performance of a Web-Based Clinical Diagnosis

Support System for Internists. Journal of General Internal Medicine 23(1), 37-40.

Grams, R., Zhang, D. & Yue, B. (1996). MDX–a medical diagnostic decision support

system. Journal of medical systems 20(3), 129-140.

Gray, P. (1987). Group decision support systems. Decision Support Systems 3(3), 233-

242.

234

Greenhalgh, T. (1997). How to read a paper: papers that report diagnostic or screening

tests. British Medical Journal 315, 540-543.

Grogono, P.D, Preece, A.D., Shinghal, R. Suen, C.Y. (1993). A Review of Expert

Systems Evaluation Techniques. AAAI Technical Report WS-93-05.

Gruber, T. (1993). A Translation Approach to Portable Ontologies. Knowledge

Acquisition 5(2), 199-220.

Gruber, T. R. (1995). Toward Principles for the Design of Ontologies used for

Knowledge Sharing. International Journal of Human-Computer Studies 43, 907-928.

Guarino, N. (1998). Formal Ontologies and Information Systems. Amsterdam: IOS

Press.

Guarino, N. & Welty, C. (2004). An overview of OntoClean. Handbook on Ontologies.

Springer Verlag.

Guha, R. V. & Lenat, D. (1990). CyC: a Midterm Report. Artificial Intelligence 11, 32-

59.

Guiu, J., Ribé, E., Mansilla, B. & Fábrega, X. (1999). Automatic diagnosis with genetic

algorithms and case-based reasoning. Artificial Intelligence in Engineering 13, 367-372.

Guo, H. & Nandi, K. (2006). Breast cancer diagnosis using genetic programming

generated feature. Pattern Recognition 39, 980-987.

Güler, I., Polat, H. & Ergün, U. (2005). Combining Neural Network and Genetic

Algorithm for Prediction of Lung Sounds. Journal of Medical Systems 29(3).

Hadzic, M. & Chang, E. (2005). Ontology-Based Support for Human Disease Study.

Proceedings of the Proceedings of the 38th Annual Hawaii International Conference on System

Sciences (HICSS'05) 6, 143.

Handels, H., Rob, T., Kreusch, J., Wolff, H. & Pöppl, S. (1999). Feature selection for

optimized skin tumor recognition using genetic algorithms. Artificial Intelligence in Medicine

16, 283-297.

Harrison, T. & Anthony, S.Fauci, A., (ed.). (2009). Harrison: Principios de medicina

interna. McGraw-Hill.

Hayes-Roth, F. (1985). Rule-based Systems. Communications of the ACM 28(9), 921-

932.

Hayes-Roth, F., Waterman, D. & Lenat, D. (1983). Building expert systems. Addison-

Wesley publishing company.

Hayward, R., El-Hajj, M., Voth, T. & Deis, K. (2006). Patterns of Use of Decision

Support Tools by Clinicians. Proceedings of AMIA Annual Symposium, 329-333.

Healthcare, I. (2009). Isabel Healthcare. Isabel Healthcare.

Heden, B., Ohlsson, M., Edenbrandt, L., Rittner, R., Pahlm, O. & Peterson, C. (1995).

Artificial neural networks for recognition of electrocardiographic lead reversal. The American

Journal of Cardiology 75(14), 929-933.

Heden, B., Öhlin, H., Rittner, R. & Edenbrandt, L. (1997). Acute Myocardial Infarction

Detected in the 12-Lead ECG by Artificial Neural Networks. Ammerical Heart Association 96,

1798-1802.

235

Henk, G. S., Cees, A. & Pieter, F. (1987). Expert systems and artificial intelligence in

decision support systems. Proceedings of the Second Mini Euroconference, 1-2.

Hoeprich, P., Jordan, M. & Ronald, A. (1994). Infectious diseases: a treatise of

infectious processes. J.B. Lippincott Co.

Hoffer, E. (1992). Dxplain: diagnostic consultation by computer for the practicing

physician. Journal of Medical Practice Management 7, 271-276.

Holsapple, C. & Whinston, A. (1996). Decision Support Systems: A Knowledge-Based

Approach. St. Paul: West Publishing.

Holst, H., Aström, K., Järund, A., Palmer, J., Heyden, A., Kahl, F., Trägil, K., Evander,

E., Sparr, G. & Edenbrandt, L. (2000). Automated interpretation of ventilation-perfusion lung

scintigrams for the diagnosis of pulmonary embolism using artificial neural networks. European

Journal of Nuclear Medicine and Molecular Imaging 27(4), 400-406.

Horn, A. (1951). On sentences which are true of direct unions of algebras. Journal of

Symbolic Logic 16, 14-21.

Horrocks, I., Patel-Schneider, P. & Van Harmelen, F. (2003). From SHIQ and RDF to

OWL: The making of a web ontology language. Journal of Web Semantics 1(1), 7-26.

Horrocks, I., Sattler, U. & Tobies, S. (2000). Practical reasoning for very expressive

description logics. Logic Journal of the IGPL 8(3), 239-263.

Horty, J. (2001). Nonmonotonic Logic. Technical Report.

Hsu, C. & Ho, C. (2004). A new hybrid case-based architecture for medical diagnosis.

Information Sciences 166, 231-247.

Hu, B., Dasmahapatra, S., Lewis, P. & Shadbolt, N. (2003). Ontology-based Medical

Image Annotation with Description Logics. IEEE International Conference on Tools with

Artificial Intelligence, 77-82.

Hupp, J., Cimino, J., Hoffer, E., Lowe, H. & Barnett, G. (1986). DXPlain: a computer-

based diagnostic knowledge base. Proc. of Fifth World Congress on Medical Informatics.

Hussain, S., Abidi, R. & Abidi, R. (2007). Semantic Web Framework for Knowledge-

Centric Clinical Decision Support Systems. Artificial Intelligence in Medicine 4594, 451-455.

Héja, G., Surján, G. & Varga, P. (2006). Ontological Analysis of SNOMED CT. BMC

Medical Informatics and Decision Making, 8(1), S8.

IHTSDO (2010). SNOMED CT Hierarchies . (http://www.ihtsdo.org/snomed-

ct/snomed-ct0/snomed-ct-hierarchies/. Last accessed, November 8, 2010.)

IHTSDO (2008). SNOMED Clinical Terms User Guide. International Health

Terminology Standards Development Organisation.

Jaakkola, T. & Jordan, M. (1999). Variational Probabilistic Inference and the QMR-DT

Network. Journal of Artificial Intelligence Research 10, 291-322.

Jacobs, D., Kasten, B., Demott, W. & Wolfson, W. (1990). Laboratory Test Handbook.

Jensen, F. & Nielsen, T. (2007). Bayesian Networks and Decision Graphs. Information

Science & Statistics.

Johnson-Laird, P. (1999). Deductive reasoning. Annual Review of Psychology.

236

Johnston, M., Karl, B., Haynes, B. & Mathieu, A. (1994). Effects of Computer-based

Clinical Decision Support Systems on Clinician Performance and Patient Outcome: A Critical

Appraisal of Research. Annals of Internal Medicine 120(2), 135-142.

Jones, J., Tsuji, G. & Hoogenboom, L. (1998). Decision support system for

agrotechnology transfer: DSSAT v3. Understanding options for agricultural production.

Juarez, J., Campos, J., Palma, J. & Marin, R. (2008). Computing context-dependent

temporal diagnosis in complex domains. Expert Systems with Applications 35, 991-1010.

Kang, B. H., Compton, P. & Preston, P. (1994). Multiple classification ripple down

rules. Third Japanise Knowledge Acquisition for Knowledge-Based Systems Workshop.

Kaplan, B. (2001). Evaluating informatics applications—clinical decision support

systems literature review. International Journal of Medical informatics 64(1), 15-37.

Karlsson, D., Ekdahl, C., Wigertz, O. & Forsum, U. (1997). A qualitative study of

clinicians ways of using a decision-support system. Proceedings of American Medical

Informatics Association, 268-272.

Kasper, D., Braunwald, E., Fauci, A., Hauser, S., Longo, D. & Jameson, J. (2004).

Harrison's Principles of Internal Medicine (16th ed.). McGraw-Hill.

Kawamoto, K., Houlihan, C., Balas, E. & Lobach, D. (2005). Improving clinical

practice using clinical decision support systems: a systematic review of trials to identify features

critical to success. British Medical Journal 330, 765-768.

Keen, P. G. W. (1978). Decision support systems: an organizational perspective.

Reading, Mass., Addison-Wesley Pub. Co.

Kilbridge, P. & Classen, D. (2001). A process model of inpatient medication

management and information technology interventions to improve patient safety. VHA’s

research series.

Klein, G., Oranasu, J., Calderwood, R. & Zsambok, C. (1993). Decision Making in

Action: Models and Methods. Greenwood publishing group.

Klein, M., Broekstra, J., Fensel, D., Van Harmelen, F. & Horrocks, I. (2004).

Ontologies and schema languages on the web. Spinning the Semantic Web: Bridging the World

Wide Web to Its Full Potential. MIT Press.

Klinov, P., Parsia, B. & Picado, D. (2010). The consistency of the medical expert

system CADIAG-2: A probabilistic approach. Journal of Information Technology Research

(JITR), 4(1), 1-20.

Klyne, G. & Carrol, J. (2004). Resource Description Framework (RDF): Concepts and

Abstract Syntax. W3C.

Kolarik, C., Hoffman-Apitius, M., Zimmermann, M. & Fluck, J. (2007). Identification

of new drug classification terms in textual resources. Bioinformatics 23, 264-272.

Kononenko, I. (1993). Inductive and Bayesian Learning in Medical Diagnosis. Applied

Artificial Intelligence. 313-337.

Koplik, H. (1896). The diagnosis of the invasion of measles from a study of the

exanthema as it appears on the buccal mucous membrane. Archives of Pediatrics 13, 918-922.

237

Kowalski, R. (1974). Predicate Logic as a Programming Language. Proceedings IFIP

Congress, 569-574.

Kowalski, R. & Kuehner, D. (1971). Linear Resolution with Selection Function.

Artificial Intelligence 2, 227-260.

Kruk, S. (2001). FOAF-Realm - control your friends' access to resources. FOAF

Workshop Proceedings.

Kulikowsk C.A. (1988). Medical Expert Systems: Issues of Validation, Evaluation and

Judgment. Policy Issues in Information and Communication Technologies in Medical

Applications, Symposium Record. 45 – 56.

Kuperman, G., Sitting, D., Shabot, M. & Teich, J. (1999). Clinical decision support for

hospital and critical care. Journal of Healthcare Information.

Kurzweil, R. (1990). The age of intelligent machines. MIT Press.

Lai, J., Hou, T., Yeh, C. & Chao, C. (2007). Using Healthcare IC Cards to manage the

drug doses of chronic disease patients. Computers in Biology and Medicine 37(2), 206-213.

Larsson, J., Hayes-Roth, B., Gaba, D. & Smith, B. (1997). Evaluation of a medical

diagnosis system using simulator test scenarios. Artificial Intelligence in Medicine 11, 119-149.

Lasko, T., Feldman, M. & Barnett, G. (2002). Dxplain Evoking Strength: Clinician

Interpretation and Consistency. American Medical Informatics Association, 1073.

Laurikkala, J. & Juhola, M. (1998). A genetic-based machine learning system to

discover the diagnostic rules for female urinary incontinence. Computer Methods and Programs

in Biomedicine 55(13), 217-228.

Laurikkala, J., Juhola, M., Lammi, S. & Viikki, K. (2009). Comparison of Genetic

Algorithms and Other Classification Methods in the Diagnosis of Female Urinary Incontinence.

Journal of Mehods of Information in Medicine 48(6), 125-131.

Lauritzen, S. & Spiegelhalter, D. (1988). Local Computations with Probabilities on

Graphical Structures and Their Application to Expert Systems. Journal of the Royal Statistical

Society Series B, 50(2), 157-224.

Lederberg, J. (1987). How Dendral Was Conceived and Born. ACM Symposium on the

History of Medical Informatics.

Lee, D., Lau, F. & Quan, H. (2010). A method for encoding clinical datasets with

SNOMED CT. BMC Medical Informatics and Decision Making 10:53.

Leidner, D. & Elam, J. (1993). Executive information systems: their impact on

executive decision making. Journal of Management Information Systems 10(3), 139-155.

Lenat, B. (1995). CYC: a large-scale investment in knowledge infrastructure.

Communications of the ACM, 38(11)

Lewis, D. (1998). Naive (Bayes) at forty: The independence assumption in information

retrieval. ECML-98, 1398/1998, 4-5

Liddell, H. & Scott, R. (2010). Sumptoma. A Greek-English Lexicon, at Pursues.

Lim, S.J.and Wang, D., Kim, Y.-S. & Gupta, S. (2006). A neuro-fuzzy approach for

diagnosis of antibody deficiency syndrome. Neurocomputing 69, 969-974.

238

Lincoln, M., Turner, C., Haug, P., Warner, H., Williamson, J., Bouhaddou, O., Jessen,

S., Sorenson, D., Cundick, R. & Grant, M. (1991). Iliad training enhances medical students'

diagnostic skills. Journal of Medical Systems 15(1), 93-110.

Linton, A. (1993). QMR (Quick Medical Reference). Bulletin of Medical

LibraryAssociation 81(3), 347-349.

Lipscomb, C. (2000). Medical Subject Headings (MeSH). Bulletin of The Medical

Library Association 88(3), 265-266.

Lipton, R., Silberstein, S. & Stewart, W. (1994). An Update of the Epidemiology of

Migraine. Headache: The Journal of Head and Face Pain 34(6), 319-328.

Lisboa, P. & Taktak, F. (2006). The use of artificial neural networks in decision support

in cancer: A systematic review. Neural Networks 19, 408-415.

Liu, Y., Wing-Chi Chan, L., Shyu, C. & Liu, Y. (2009). Editorial for the special issue of

knowledge discovery and management in biomedical information systems. Information Systems

Frontiers 11(4), 345-347.

Long, W. (1989). Medical Diagnosis Using a Probabilistic Causal Network. Applied

Artificial Intelligence, 3, 367-383.

Lopez de Ullibarri Galparsoro, I. & Pita Fernández, S. (1998). Curvas ROC. Cad Aten

Primaria 5(4), 229-235.

Lowd, D. & Domingos, P. (2005). Naive Bayes models for probability estimation.

Proceedings of the 22nd international conference on Machine learning.

Lowe, H. & Barnett, G. (1987). MicroMeSH: A Microcomputer System for Searching

and Exploring the National Library of Medicine's Medical Subject Headings (MeSH)

Vocabulary. Proceedings of the Annual Symposium on Computer Application in Medical Care

4, 717-720.

Lucas, P. (1997). Model-based diagnosis in medicine. Artificial Intelligence in Medicine

10, 201-208.

Lugar, G. & Stubblefield, W. (1993). Artificial intelligence: Structures and strategies

for complex problem solving. Addison-Wesley.

Lundsgaarde, H. (1987). Evaluating medical expert systems. Social Science and

Medicine 24(10), 805-819.

Maedche, A. & Staab, S. (2001). Ontology Learning for the Semantic Web. IEEE

Intelligent Systems 16(2), 72-79.

Magoulas, D., Plagianakos, P. & Vrahatis, N. (2004). Neural network-based

colonoscopic diagnosis using on-line learning and differential evolution. Applied Soft

Computing, 4(4), 369-379

Mahesh, K. (1996). Ontology Development for Machine Translation: Ideology and

Methodology. Computing Research Laboratory. New Mexico.

Makhoul, J., Kubala, F., Schwartz, R. & Weischedel, R. (1999). Performance measures

for information extraction. Proceedings of DARPA Broadcast News Workshop.

239

Markwell, D., Sato, L. & Cheetham, E. (2008). Representing clinical information using

SNOMED Clinical Terms with different structural information models. Proceedings of the 3rd

International Conference on Knowledge Representation in Medicine (KR-MED 2008).

Martens, J., Van Der Weijden, T., Severens, J., De Clercq, P., De Bruijn, D., Kester, A.

& Winkens, R. (2007). The effect of computer reminders on GPs’ prescribing behaviour: A

cluster-randomised trial. International Journal of Medical Informatics 76(3), S403-S416.

Martin, A. & Del Castillo, J. D. (2004). Bioestadística para las Ciencias de la Salud

(Science health biostatistics). Ediciones Norma.

Matthews, B. (1975). Comparison of the predicted and observed secondary structure of

T4 phage lysozyme. Biochim. Biophys. Acta 405, 442-451.

McCarthy, J. (2007). What is artificial intelligence?. Report. Standford University.

McCorduck, P. (2004). Machines Who Think. Natick, MA: A. K. Peters, Ltd.

McDonald, W.I., Compston, A., Edan, G., Goodkin, D., Hartung, H.P. et al. (2001).

Recommended diagnostic criteria for multiple sclerosis: Guidelines from the international panel

on the diagnosis of multiple sclerosis. Annals of Neurology 50(1), 121-127

Measles, W. (2010). WHO-recommended surveillance standard of measles. WHO.

Meesad, P. & Yen, G. (2001). A hybrid intelligent system for medical diagnosis.

International Joint Conference on Neural Networks 4, 2558-2563.

Mendonça, E. & Cimino, J. (2000). Automated knowledge extraction from MEDLINE

citations. Proceeding of AMIA Annual Symposium, 575-579.

Merrill, G., Ryan, P. & Painter, J. (2008). Construction and Annotation of a

UMLS/SNOMED-based Drug Ontology for Observational Pharmacovigilance. IDAMAP

(Intelligent Data Analysis for bioMedicine and Pharmacology).

Michalowski, W., Rubin, S. & Aggarwal, H. (1993). Teaching medical diagnosis: a

rule-based approach. Medical Teacher 15(4), 309-319.

Miller, P. (1986). The evaluation of artificial intelligence systems in medicine.

Computer Methods and Programs in Biomedicine 22(1), 3-11.

Miller, R. (1994). Medical diagnostic decision support systems – past, present, and

future: a threaded bibliography and brief commentary. Journal of the American Medical

Informatics Association 1(1), 8-27.

Miller, R. (1982). INTERNIST-1: An Experimental Computer-Based Diagnostic

Consultant for General Internal Medicine. New England Journal of Medicine 307, 468-476.

Miller, R. & Masarie, F. (1989). Use of the Quick Medical Reference (QMR) program

as a tool for medical education. Methods of information in medicine 28(4), 340-345.

Miller, R., Masarie, F. & Myers, J. (1986). Quick Medical Reference (QMR) for

diagnostic assistance. MD computing: computers in medical practice 3(5), 34-48.

Miller, R., McNeal, M., Challinor, S., Masarie, F. & Myers, J. (1986). The

INTERNIST-1/QUICK MEDICAL REFERENCE Project. The Western Journal of Medicine

145(6), 816-822.

Morelli, R., Bronzino, J. & Goethe, J. (1987). Expert systems in psychiatry. A review.

Journal of medical systems 11(2-3), 157-168.

240

Mori, R., Consorti, F. & Galeazzi, E. (1998). Standards to support development of

terminological systems for healthcare telematics. Methods of information in medicine 37, 551-

563.

Morrison, A.1992, (ed.). Screnning in Chronic disease. Oxford University Press.

Motik, B., Patel-schneider, P. & Parsia, B. (2009). OWL 2 Web Ontology Language,

Structural specification and functional syntax. W3C.

Motik, B., Sattler, U. & Studer, R. (2004). Query Answering for OWL-DL with Rules.

Proceedings of the 3rd International Semantic Web Conference.

Mulsant, B. & Ganguli, M. (1999). Epidemiology and diagnosis of depression in late

life. Journal of clinical psychiatry 60(20), 51.

Myers, J. (1990). The Background of INTERNIST-I and QMR. A History of Medical

Informatics. ACM Press.

Myers, J., Pople, H. & Miler, R. (1982). INTERNIST: Can Artificial Intelligence Help?.

Clinical Decisions and Laboratory Use. University of Minnesota Press.

NHL (2010). Medline Plus. National Health Library of Medicine.

Nikovski, D. (2000). Constructing Bayesian Networks for Medical Diagnosis from

Incomplete and Partially Correct Statistics. IEEE Transactions on Knowledge and Data

Engineering 12(4), 509-516.

Nikovski, D. (2000). Constructing Bayesian Networks for Medical Diagnosis from

Incomplete and Partially Correct Statistics. IEEE Transactions on Knowledge and data

engineering 12(4), 509-516.

Nilsson, N. (1998). Artificial Intelligence: A New Synthesis. Morgan Kaufmann

Publishers.

Norris, D. (1986). Machine Learning Using Fuzzy Logic with Applications in Medicine.

Unpublished doctoral disseration, University of Bristol, U.K.

Nour, M. & Yen, D. (1992). Group decision support system. Journal of Information &

Managment 23(2), 55-64.

Noy, N. & McGuinness, D. (2011). Ontology Development 101: A Guide to Creating

Your First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and

Stanford Medical Informatics Technical Report SMI-2001-0880.

Noy, N. & Musen, M. (2003). The PROMPT Suite: interactive tools for ontology

merging and mapping. International Journal of Human-Computer Studies 59, 983-1024.

NPEX (2010). Snomed Browser. National Pathology Exchange.

NRC (1999). Developments in Artificial Intelligence. Funding a Revolution:

Government Support for Computing Research. NRC (United States National Research Council).

Nutter, F. (1999). Understanding the interrelationships between botanical, human, and

veterinary epidemiology: the Ys and Rs of it all. Ecosys Health 5(3), 131-140.

Nøhr, C. (1994). The evaluation of expert diagnostic systems— How to assess

outcomes and quality parameters?. Artificial Intelligence in Medicine 6(2), 123-135.

241

O'Connr, M., Knublauch, H., Tu, S., Grosof, B., Dean, M., Grosso, W. & Musen, M.

(2005). Supporting Rule System Interoperability on the Semantic Web with SWRL.

Proceedings of International Semantic Web Conference.

Omar, M. (1992). Executive information systems. Journal of Executive Development

5(2), 13-16.

Osborne, J., Flatow, J., Holko, M., Lin, S., Kibbe, W., Zhu, L., Danila, M., Feng, G. &

Chisholm, R. (2009). Annotating the human genome with Disease Ontology. BMC Genomics

10.

Osborne, J., Lin, S., Kibbe, W., Zhu, L., Danila, M. & Chisholm, R. (2006). GeneRIF is

a more comprehensive, current and computationally tractable source of gene-disease

relationships than OMIM. Northwestern University.

Packer, M., Cimino, J., Kim, R., Hoffer, E., Barnett, G. & Zatz, S. (1988). Updating the

DXplain database. Proc. of Twelfth SCAMC, 96-100.

Packer, M., Hoffer, E., Barnett, G., Famiglietti, K., Kim, R., McLatchey, J., Elkin, P.,

Cimino, C. & Studney, D. (1989). Evolution of DXplain: A Decision Support System.

Proceedings of the AMIA Annual Symposium.

Pang, B., Zhang, D., Li, N. & Wang, K. (2004). Computerized Tongue Diagnosis Based

on Bayesian Networks. Transactions on Biomedical Engineering 10(51).

Park, Y., Kim, B. & Chun, S. (2006). New knowledge extraction technique using

probability for case-based reasoning: application to medical diagnosis. Expert Systems 23(1), 2-

20.

Parsia, B., Halaschek-Wiener, C. & Sirin, E. (2006). Towards incremental reasoning

through updates in OWL-DL. Proceedings of the Workshop at 15th International World Wide

Web Confence on Reasoning on the Web.

Pearl, J. (1984). Heuristics: Intelligent search strategies for computer problem solving.

Addison-Wesley.

Peelen, L., Klein, M.C.A., Schlobach, S., De-Keizer, N.F., Peek, N. (2007). Analyzing

Differences in Operational Disease Definitions Using Ontological Modeling. AIME '07

Proceedings of the 11th conference on Artificial Intelligence in Medicine.

Pellegrino, J. & Glaser, R. (1980). Components of inductive reasoning. Aptitude,

learning, and instruction: cognitive process analysis. Hillsdale.

Peng, F., Schuurmans, D. & Wang, S. (2003). Combining Naive Bayes and n -Gram

Language Models for Text Classification. Advances in Information Retrieval.

Pértega-Diaz, S., Pita-Fernandez, S. (2001). Métodos paramétricos para la comparación

de dos medias. t de Student. CAD ATEN PRIMARIA 8, 37-41

Pesonen, E., Eskelinen, M. & Juhola, M. (1996). Comparison of different neural

network algorithms in the diagnosis of acute appendicitis. International Journal of Bio-Medical

Computing 40(3), 227-233.

Pham, T. & Chen, G. (2002). Some applications of fuzzy logic in rule-based expert

systems. Expert Systems, The journal of knowledge engineering 19(4), 208-223.

Pita, S. & Pértegas, S. (2003). Pruebas diagnósticas: Sensibilidad y especificidad. Cad

Aten Primaria 10, 120-124.

242

Plebani, M. & Piva, E. (2002). Erythrocyte Sedimentation Rate Use of Fresh Blood for

Quality Control. American Journal of Clinical Pathology 117, 621-626.

Podgorelec, V., Grasic, B. & Pavlic, L. (2009). Medical diagnostic process optimization

through the semantic integration of data resources. Computer methods and programs in

biomedicine 95(2), S55-S67.

Polat, K. & Günes, S. (2007). An expert system approach based on principal component

analysis and adaptive neuro-fuzzy inference system to diagnosis of diabetes disease. Digital

Signal Processing 17(4), 702-710.

Poole, D., Mackworth, A. & Goebel, R. (1998). Computational Intelligence: A Logical

Approach. Oxford University Press.

Pople, H. (1976). Presentation of the INTERNIST System. Proceedings of the AIM

Workshop.

Poser, C.M., Paty, D.W., Scheinberg, L., McDonald, W.I., et al. (1984). New diagnostic

criteria for multiple sclerosis: Guidelines for research protocols. Annals of Neurology 13(1),

227-231

Povalej, P., Kravos, M. & Kokol, P. (2007). Intelligent data analysis for diagnostics of

alcohol dependency. Proceedings of the Twentieth IEEE International Symposium on

Computer-Based Medical Systems, 445-450.

Provost, J. (1999). Naïve-Bayes vs Rule-Learning in Classification of E-mail. ( ).

University of Texas. Technical Report AI-TR-99-284.

Rao, P., Sagonas, K., Swift, T., Warren, D. & Freire, J. (1997). XSB: A system for

efficiently computing well-founded semantics. Logic Programming and Nonmonotonic

Reasoning 1265(1997), 430-440.

Rector, A., Rogers, J., Zanstra P.E. & Van der Haring, E. (2003). OpenGALEN: Open

Source Medical Terminology and Tools. Proceedings of AMIA Symposium.

Rector, A. & Schreiber, G. (2005). Qualified cardinality restrictions (QCRs):

Constraining the number of values of a particular type for a property. W3C.

Reiter, R., Marek, V. & Truszczynski, M. (1993). Nonmonotonic Logic: Context-

Dependent Reasoning (Artificial Intelligence). Springer-Verlag.

Reggia, J.A. (1985). Evaluation of Medical Expert Systems: A Case Study in

Performance Assessment. In Proceedings of the Annual Symposium on Computer Application in

Medical Care, 287–291.

Rennie, J. (2001). Improving Multi-class Text Classification with Naive Bayes. MIT.

Rich, E. & Knight, K. (1991). Artificial Intelligence. McGraw-Hill.

Riffenburgh, R. H. (2006). Statistics in Medicine. Elsevier.

Rindflesch, T., Tanabe, L., Weinstein, J. & Hunter, L. (2000). EDGAR: extraction of

drugs, genes and relations from the biomedical literature. Pac. Symp. Biocomput 5, 517-528.

Rish, I. (2001). An empirical study of the naive Bayes classifier. IJCAI-01 workshop on

"Empirical Methods in AI".

243

Robert, L., Buchanan, B., Feigenbaum, E. & Lederberg, J. (1993). DENDRAL: A Case

Study of the First Expert System for Scientific Hypothesis Formation. Artificial Intelligence

61(2), 209-261.

Robert, L., Buchanan, B., Feigenbaum, E. & Lederberg, J. (1980). Applications of

Artificial Intelligence for Organic Chemistry: The Dendral Project. McGraw-Hill Book

Company.

Rodriguez-Gonzalez, A., García Crespo, A., Colomo Palacios, R., Gomez Berbis, J. &

Jiménez Domingo, E. (2009). Using Ontologies in Drug Prescription: The SemMed Approach.

International Journal of Knowledge-Based Organizations, 1(4), 1-15

Rodriguez-Gonzalez, A. (2007). ODDx - Online Differential Diagnosis System.

Unpublished capstone disseration, Universidad de Oviedo.

Rodríguez-Gonzalez, A., Garcia Crespo, A. & Colomo Palacios, R., Labra-Gayo, J.E.,

Gomez-Berbis, J.M., Alor-Hernandez, G. (2011). Automated Diagnosis through Ontologies and

Logical Descriptions: the ADONIS approach, International Journal of Decision Support System

Technology (IJDSST), 3(2), 21-39

Rodríguez-Gonzalez, A., Labra-Gayo, J., Colomo-Palacios, R., Mayer, M., Gomez-

Berbis, J. & García-Crespo, A. (2011a). SeDeLo: Using Semantics and Description Logics to

support aided clinical diagnosis. Journal of Medical Systems.

Rodríguez-González, A., Jimenez, E., Radzimski, M., Gomez, J., Alor, G., Posada, R. &

Gayo, J. (2009). Applying Caching Capabilities to Inference Applications Based on Semantic

Web. New Challenges in Computational Collective Intelligence 244, 27-37.

Rodríguez-González, A., Labra, J., Alor-Hernandez, G., Gomez, J. & Posada-Gomez,

R. (2009b). ADONIS: Automated diagnosis system based on sound and precise logical

descriptions. Computer-Based Medical Systems, 2009. CBMS 2009, 1-8.

Rodríguez-González, A., Mayer, M., Alor-Hernandez, G., Gomez, J. & Lagares, A.

(2010). Using Ontologies and Probabilistic Networks to Develop a Preventive Stroke Diagnosis

System (PSDS). The 23RD IEEE International Symposium on Computer-Based Medical

Systems (CBMS 2010).

Rodríguez-González, A. et al. (2011b). Towards an Ontology to support semantics

enabled Diagnostic Decision Support Systems. Current Bioinformatics (Special Issue on

Semantic Web and Healthcare) (to appear).

Rodríguez-González, A., Torres-Niño, J., Hernandez-Chan, G., Jimenez-Domingo, E. &

García-Crespo, A. (2011c). Using Agents to Parallelize a Reasoning System Based on

Ontologies and Description Logics. Computing and informatics (Submitted).

Rogers, J. & Bodenreider, O. (2009). SNOMED CT: Browsing the Browsers.

Ropes, M.W. and Bennet, G.A. and Cobb, S. and Jacox, R. and Jessar, R.A. (1959).

1958 Revision of diagnostic criteria for rheumatoid arthritis. Arthritis & Rheumatism 2(1), 16-

20

Rotshtein, A. (1999). Design and tunning of fuzzy rule-based systems for medical

diagnosis. Fuzzy and Neuro-Fuzzy Systems in Medicine.

Rudolph, S., Krötzsch, M. & Hitzler, P. (2008). All Elephants are Bigger than All Mice.

Proceedings of the 21st International Workshop on Description Logics (DL-08). CEUR

Workshop Proceedings 2008.

244

Ruland, C. M. & Bakken, S. (2002). Developing, implementing, and evaluating decision

support systems for shared decision making in patient care: A conceptual model and case

illustration. Journal of Biomedical Informatics 35(5-6), 313-321.

Russell, S. J. & Norvig, P. (2003). Artificial Intelligence: A Modern Approach. Upper

Saddle River, NJ: Prentice Hall.

Sagonas, K., Swift, T. & Warren, D. (1994). XSB as an efficient deductive database

engine. ACM SIGMOD Record 23(2), 442-453.

Schalkoff, R. (1990). Artificial intelligence: an engineering approach. McGraw-Hill

College.

Schneider, K. (2003). A comparison of event models for Naive Bayes anti-spam e-mail

filtering. Proceedings of the tenth conference on European chapter of the Association for

Computational Linguistics.

Schulz, S., Romacker, M., Faggioli, G. & Hahn, U. (1999). From knowledge import to

knowledge finishing automatic acquisition and semi-automatic refinement of medical

knowledge. Proceedings of Knowledge Acquisition, Modeling and Management.

Schwartz, D. (1999). When email meets organizational memories: Addressing threats to

communication in a learning organization. International Journal of Human-Computer Studies

51, 599-614.

Scott, R. (1993). Artificial Intelligence: Its Use in Medical Diagnosis. The Journal of

Nuclear Medicine 34(3), 510-514.

Sebe, N., Lew, M., Cohen, I., Garg, A. & Huang, T. (2002). Emotion Recognition

Using a Cauchy Naive Bayes Classifier. 16th International Conference on Pattern Recognition

(ICPR'02).

Seewald, A. (2007). An evaluation of Naive Bayes variants in content-based learning

for spam filtering. Intelligent Data Analysis.

Segura-Bedmar, I., Crespo, M., Pablo-Sanchez, C. & Martinez, P. (2010). Resolving

anaphoras for the extraction of drug-drug interactions in pharmacological documents. BMC

Bioinformatics 11(1).

Sewell, W. (1964). Medical Subject Headings in MEDLARS. Bulletin of Medical

Library Association 52(1), 164-170.

Shahar, Y. & Musen, M. (1996). Knowledge-Based Temporal Abstraction in Clinical

Domains. Artificial Intelligence in Medicine 8(3), 267-298.

Shiffman, R., Brandt, C., Liaw, Y. & Corb, G. (1999a). A design model for computer-

based guideline implementation based on information management services. Journal Of the


Shiffman, R., Liaw, Y., Brandt, C. & Corb, G. (1999b). Computer-based guideline

implementation systems: a systematic review of functionality and effectiveness. Journal Of the


Shortliffe, E. (1984). Rule Based Expert Systems: The MYCIN Experiments of the

Stanford Heuristic Programming Project. Addison-Wesley.

Shortliffe, E. (1976). Computer-based medical consultations, MYCIN. Elsevier

Publishing Company.

245

Shortliffe, E. & Buchanan, B. (1975). A model of inexact reasoning in medicine.

Mathematical Biosciences 23, 351-379.

Shortliffe, E., Davis, R., Axline, S., Buchanan, B., Green, C. & Cohen, S. (1975).

Computer-based consultations in clinical therapeutics: Explanation and rule acquisition

capabilities of the MYCIN system. Computers and biomedical research 8.

Shortliffe, E., Scott, A., Bischoff, M., Campbell, A., Melle, V. & Jacobs, C. (1981).

ONCOCIN: An expert system for oncology protocol management. Seventh International Joint

Conference on Artificial Intelligence.

Sim, I., Gorman, P., Greenes, R., Haynes, R., Kaplan, B., Lehmann, H. & Tang, P.

(2001). Clinical Decision Support Systems for the Practice of Evidence-based Medicine.

Journal of the American Medical Informatics Association 8(6), 527-534.

Sittig, D., Wright, A., Osheroff, J., Middleton, B., Teich, J., Ash, J., Campbell, E. &

Bates, D. (2008). Grand challenges in clinical decision support. Journal of Biomedical

Informatics 41(2), 387-392.

Skhal, K. & Koffel, J. (2007). VisualDX. Journal of the Medical Library Association

95(4), 470-471.

Smets, P. (1987). Belief functions: The disjunctive rule of combination and the

generalized Bayesian theorem. International Journal of Approximate Reasoning 9(1), 1-35.

Smith, B., Ashburner, M., Rosse, C., Bard, J., Bug, W., Ceusters, W., Goldberg, L.,

Eilbeck, K., Ireland, A., Mungall, C., OBI Consortium, Leontis, N., Rocca-Serra, P.,

Ruttenberg, A., Sansone, S., Scheuermann, R., Shah, N., Whetzel, P. & Lewis, S. (2007). The

OBO Foundry: coordinated evolution of ontologies to support biomedical data integration.

Nature Biotechnology 25, 251-1255.

Smith, B. & Ceusters, W. (2005). An Ontology-Based Methodology for the Migration

of Biomedical Terminologies to Electronic Health Records. AMIA Annual Symposium, 704-708.

Smith, B., Ceusters, W., Klagges, B., Köhler, J., Kumar, A., Lomax, J., Mungall, C.,

Neuhaus, F., Rector, A. & Rosse, C. (2005). Relations in biomedical ontologies. Genome

Biology 6.

Sol, H.Sol, H., (ed.). (1986). Expert systems and artificial intelligence in decision

support systems. Kluwer.

SPARQL (2005). SPARQL Query Language for RDF. W3C.

Spitzer, L. & Endicott, J. (1969). DIAGNO II: Further developments in a computer

program for psychiatric diagnosis. The American Journal of Psychiatry 125(7), 12-21.

Spitzer, L. & Endicott, J. (1968). A Computer Program for Psychiatric Diagnosis

Utilizing the Differential Diagnostic Procedure. Archives of General Psychiatry 18(6), 746-756.

Stephens, W. & Middleton, T. (2002). Why has the uptake of Decision Support Systems

been so poor?. Crop-soil simulation models in developing countries, 129-148.

Steve, G, A., Gangemi, D. & Pisanelli (1998b). Ontology Integration: Experiences with

Medical Ontologies.

Steve, G, A., Gangemi, D. & Pisanelli (1998a). Integrating Medical Terminologies with

ONIONS Methodology.

246

Stevens, R., Baker, P., Bechhofer, S., Ng, G., Jacoby, A., Paton, N., Goble, C. & Brass,

A. (1999). TAMBIS: Transparent Access to Multiple Bioinformatics Information Sources.

Bioinformatics 16(2), 184-186.

Stevens, R., Wroe, C., Lord, P. & Goble, C. (2003). Ontologies in bioinformatics.

Handbook on Ontologies. Springer.

Straub, H., Duellt, M., Norbert, F., Mosimann, H. & Ulrich, A. (2006). From

Terminologies to Classifications - the Challenge of Information Reduction. Integrating

Biomedical Information: From E-cell to E-patient - Proceedings of the European Federation

for Medical Informatics, 341-352.

Sure, Y. & Studer, R. (2003). A Methodology for Ontology-based Knowledge

Management. Towards the Semantic Web. John Wiley and Sons, Ltd.

Szolovits, P. (1982). Artificial intelligence in medicine. Westview Pr.

Szolovits, P., Patil, R. & Schwartz, W. (1988). Artificial Intelligence in Medical

Diagnosis. Annals of internal medicine.

Tan, K., Yu, Q., Heng, C. & Lee, T. (2003). Evolutionary computing for knowledge

discovery in medical diagnosis. Artificial Intelligence in Medicine 27, 129-154.

Tan, Z., Quek, C., Ng, S. & Razvi, K. (2008). Ovarian cancer diagnosis with

complementary learning fuzzy neural network. Artificial Intelligence in Medicine 43, 207-222.

Thierauf, R. (1991). Executive Information System: A Guide for Senior Management

and MIS Professionals. Quorum Books.

Tierney, W., Overhage, J. & McDonald, C. (1994). An plea for controlled trials in

medical informatics. Journal of Medical Informatics Association 1(4), 353-355.

Tiomothy, J. (1989). Executive Information Systems. Information Systems Management

6(2), 34-41.

Tleyjeh, I., Nada, H. & Baddour, L. (2006). VisualDx: Decision?Support Software for

the Diagnosis and Management of Dermatologic Disorders. Clinical Infectious Diseases 43,

1177-1184.

Torres-Urquidy, M. & Collins, B. (2006). VisualDx Clinical Decision Support

Software. Journal of Dental Education 70(8), 892-894.

Tourassi, G., Floyd, C., Sostman, H. & Coleman, R. (1995). Artificial neural network

for diagnosis of acute pulmonary embolism: Effect of case and observer selection. ACC Current

Journal Review 4(6), 74.

Tourassi, G., Floyd, C., Sostman, H. & Coleman, R. (1993). Acute pulmonary

embolism: artificial neural network approach for diagnosis. Radiology 189(2), 555-558.

Trowbridge, R. & Weingarten, S. (2001). Clinical decision support systems. Making

health care safer: a critical analysis of patient safety practices. Agency for Healthcare Research

and Quality.

Tsai, D., Lee, Y., Sekiya, M. & Ohkubo, M. (2004). Medical image classification using

geneticalgorithm based fuzzy-logic approach. Journal of Electronic Imaging 13(4), 780-788.

247

Tsakonas, A., Dounias, G., Jantzen, J., Axer, H., Bjerregaard, B. & von Keyserlingk, D.

(2004). Evolving rule-based systems in two medical domains using genetic programming.

Artificial Intelligence in Medicine 32, 195-216.

Tsumoto, S. (1998). Modelling Medical Diagnostic Rules Based on Rough Sets.

Proceedings of the First International Conference on Rough Sets and Current Trends in

Computing. LNCS, 475-482.

Turban, E., Aronson, J. & Liang, T. (2008). Decision Support Systems and Intelligent

Systems. N/A.

Turban, E. & Watkins, P. (1986). Integrating Expert Systems and Decision Support

Systems. MIS Quarterly 10(2), 121-136.

US-Government (2008). Federal Food, Drug, and Cosmetic Act (FD&C Act). About

This Reference Edition of the FD&C Act. US Federal Food, Drug, and Cosmetic Act.

Van Rijsbergen, C.Butterworth-Heinemann, (ed.). (1979). Information Retrieval.

Newton, M.A.

Varghese, S. & Pirkul, H. (1991). Organizational decision support systems.

International Journal of Man-Machine Studies 36(6), 817-832.

Vinterbo, S. & Ohno-Machado, L. (2000). A genetic algorithm approach to multi-

disorder diagnosis. Artificial Intelligence in Medicine 18, 117-132.

W3C (2006). Resource Description Framework (RDF). W3C.

W3C (2004). RDF Vocabulary Description Language 1.0: RDF Schema. W3C.

W3C-Qname (2004). Using Qualified Names (QNames) as Identifiers in XML Content.

W3C.

Wang, J., Xing, R. & Yao, J. (2008). Executive information systems. Encyclopedia of

Information Technology Curriculum Integration.

Warner, H., Haug, P., Bouhaddou, O., Lincoln, M., Warner, H., Sorenson, D.,

Williamson, J. & Fan, C. (1988). ILIAD as an Expert Consultant to Teach Differential

Diagnosis. Proceedings of the Annual Symposium on Computer Application in Medical Care 9,

371-376.

Waterman, D. (1986). A guide to expert systems. Addison-Wesley.

Watson, H. & Walls, J. (1993). Executive information systems. Proceeding of the

Twenty-Sixth Hawaii International Conference on System and Sciences.

Watson-Sprague, R. (1990). Decision Support Systems. Prentice Hall.

Weber Jahnke, J., McCallum, G. & Price, M. (2006). Making available Clinical

Decision Support in Service-Oriented Architectures. International Conference on Information

Technology and Communication in Health.

Weigand, H. (1997). Multilingual Ontology-Based Lexicon for News Filtering .The

TREVI Project. Technical Report.

West, D., Mangiameli, P., Rohit, R., West, V. (2005). Ensemble strategies for a medical

diagnostic decision support system: A breast cancer diagnosis application. Computing, Artificial

Intelligence and Information Technology. European Journal of Operational Research 162,

532–551.

248

WHO (2010). International Classification of Diseases. World Health Organization.

http://www.who.int/classifications/icd/en/.

Wolberg, W., Street, N. & Mangasarian, L. (2010). Breast Cancer Wisconsin

(Diagnostic) Data Set. University of Wisconsin.

Wright, A. & Sittig, D. (2008). A four-phase model of the evolution of clinical decision

support architectures. International journal of medical informatics 77(10), 641-649.

Wroe, C. (2006). Is Semantic Web technology ready for healthcare?. European

Semantic Web Conference 2006 (ESWC 06).

Wyatt, J. & Spiegelhalter, D. (1990). Evaluating medical expert systems: what to test

and how?. Medical Informatics 15(3), 205-217.

Xiang, Y., Pant, B., Eisen, A., Beddoes, M. & Poole, D. (1993). Multiply sectioned

bayesian networks for neuromuscular diagnosis. Artificial Intelligence in medicine 5(4), 293-

314.

Yan, H., Zheng, J., Jiang, Y., Peng, C. & Xiao, S. (2008). Selecting critical clinical

features for heart diseases diagnosis with a real-coded genetic algorithm. Applied Soft

Computing 8(2), 1105-1111.

Yu, V., Fagan, L.M., W. S., Clancey, W.J., Scott, A., Hannigan, J., Blum, R.,

Buchanan, B. & Cohen, S. (1979). Antimicrobial selection by a computer - a blinded evaluation

by infectious disease experts. Journal of the American Medical Association 242, 1279-1282.

Zeng, Q. & Cimino, J. (1998). Automated knowledge extraction from the UMLS.

Proceeding of AMIA Annual Symposium, 569-572.

Zhang, H. (2004). The Optimality of Naive Bayes. The FLARS Conference.

Zhao, W., Yanxiang, H. & Hui, J. (2005). A Model of Intelligent Distributed Diagnosis

and Therapy System Based on Mobile Agent and Ontology. Proceedings of the 8th

International Conference on High-Performance Computing in the Asia-Pacific Region.

Zhou, Z. & Jiang, Y. (2003). Medical Diagnosis with C4.5 Rule Preceded by Artificial

Neural Network Ensemble. IEEE Transactions on Information Technology in Biomedicine 7(1),

37-42.

Zweig, M. & Campbell, G. (1993). Receiver-operating characteristics (ROC) plots: a

fundamental evaluation tool in clinical medicine. Clinical Chemistry 39, 561-577.

Zwi, A. (1991). Militarism, militarization, health and the Third World. Medical

Wilderness Adventure Race.

Übeylin, D. (2007). Implementing automated diagnostic systems for breast cancer

detection. Expert Systems with Applications 33, 1054-1062.

Übeylin, D. & Güler, I. (2005). Improving medical diagnostic accuracy of ultrasound

Doppler signals by combining neural network models. Computers in Biology and Medicine 35,

533-554.

249

14. ANEXOS En la presente sección se muestran los diversos anexos que componen la

información adicional presentada en esta tesis.

Fundamentalmente, se encuentran los siguientes elementos:

Tablas de las valoraciones multinivel Tablas resumen de los resultados diagnósticos Tablas de tiempos de ejecución Tablas de consumos de memoria en ejecución Publicaciones relacionadas con la tesis

250

14.1. TABLAS DE VALORACIÓN MULTINIVEL

Caso Respuesta Caso Respuesta Caso Respuesta Caso Respuesta Caso Respuesta

2 4 6 8 10

Fiebre Tifoidea Inferencia Inferencia Inferencia Inferencia Inferencia

Meningitis - Parcial - Parcial

Pancreatitis

Orquitis

Pielonefritis - Parcial - Parcial

Neumonía - Parcial - Parcial - Parcial

Tabla 35. Tabla de valoración de inferencia multinivel: Fiebre Tifoidea (I)


12 14 17 19 20

Fiebre Tifoidea Inferencia Inferencia Inferencia Inferencia Inferencia

Meningitis

Pancreatitis - Parcial

Orquitis

Pielonefritis - Parcial

Neumonía - Parcial - Parcial

Tabla 36. Tabla de valoración de inferencia multinivel: Fiebre Tifoidea (II)

251


1 2 7 11 12

Laringitis Inferencia Inferencia Inferencia Inferencia Inferencia

Faringitis

Tabla 37. Tabla de valoración de inferencia multinivel: Laringitis

Caso Respuesta Caso Respuesta Caso Respuesta Caso Respuesta

1 2 6 8

Bronquitis Inferencia Inferencia Inferencia Inferencia

Sinusitis

Gripe

Resfriado común

Tabla 38. Tabla de valoración de inferencia multinivel: Bronquitis (I)


10 11 12 14

Bronquitis Inferencia Inferencia Inferencia Inferencia

Sinusitis

Gripe - Parcial

Resfriado común - Parcial

Tabla 39. Tabla de valoración de inferencia multinivel: Bronquitis (II)

252


2 6 8 10

Brucelosis Inferencia Inferencia Inferencia Inferencia

Neumonía

Pielonefritis

Tabla 40. Tabla de valoración de inferencia multinivel: Brucelosis (I)

Caso Respuesta Caso Respuesta Caso Respuesta

12 14 19

Brucelosis Inferencia Inferencia Inferencia

Neumonía - Parcial

Pielonefritis

Tabla 41. Tabla de valoración de inferencia multinivel: Brucelosis (II)

253

14.2. TABLAS DE RESULTADOS DIAGNÓSTICOS

14.2.1. ARBITRAJE AR-XF31

EX-KS0L EX-SK4V

Precision Recall Accuracy Specifity MCC Precision Recall Accuracy Specifity MCC

Faringitis 33,33% 100,00% 83,33% 81,82% 76,11% 0,00% 100,00% 91,67% 91,67% NA

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Pericarditis 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Enfermedad De Addison 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Neumonía 83,33% 71,43% 75,00% 80,00% 75,35% 100,00% 50,00% 75,00% 100,00% 78,87%

Difteria 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% NA

Pielonefritis 100,00% 33,33% 83,33% 100,00% 76,11% 100,00% 66,67% 91,67% 100,00% 88,73%

Diabetes Tipo 2 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% NA

Aspergiloma Pulmonar 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% NA

Asma 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Resfriado Común 80,00% 100,00% 91,67% 87,50% 91,83% 100,00% 50,00% 91,67% 100,00% 83,71%

Gripe 75,00% 60,00% 75,00% 85,71% 73,90% 100,00% 75,00% 91,67% 100,00% 90,82%

Tabla 42. Resultados Arbitraje AR-XF31. Enfermedad 1-12. Expertos EX-KS0L y EX-SK4V

254

EX-KS0L EX-SK4V


Meningitis 0,00% 100,00% 83,33% 83,33% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Fiebre Reumática 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% NA

Sinusitis 66,67% 100,00% 91,67% 90,00% 88,73% 100,00% 100,00% 100,00% 100,00% 100,00%

Orquitis 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Brucelosis 0,00% 0,00% 75,00% 100,00% 0,00% 0,00% 0,00% 83,33% 100,00% 0,00%

Parkinson 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Gastroenteritis 50,00% 100,00% 83,33% 80,00% 81,62% 75,00% 100,00% 91,67% 88,89% 90,82%

Pancreatitis 100,00% 100,00% 100,00% 100,00% NA 0,00% 100,00% 91,67% 91,67% NA

Fiebre Tifoidea 100,00% 40,00% 75,00% 100,00% 76,46% 0,00% 0,00% 75,00% 100,00% 0,00%

Bronquitis 100,00% 80,00% 91,67% 100,00% 91,83% 100,00% 66,67% 91,67% 100,00% 88,73%

Laringitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% NA

Colera 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Tabla 43. Resultados Arbitraje AR-XF31. Enfermedad 13-24. Expertos EX-KS0L y EX-SK4V

255

EX-KV8H EX-VH7Q


Faringitis 0,00% 100,00% 91,67% 91,67% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 0,00% 0,00% 83,33% 100,00% 0,00%

Pericarditis 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% NA

Enfermedad De Addison 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Neumonía 100,00% 40,00% 75,00% 100,00% 76,46% 100,00% 50,00% 83,33% 100,00% 81,62%

Difteria 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Pielonefritis 0,00% 0,00% 83,33% 100,00% 0,00% 100,00% 33,33% 83,33% 100,00% 76,11%

Diabetes Tipo 2 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Aspergiloma Pulmonar 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Asma 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Resfriado Común 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Gripe 100,00% 75,00% 91,67% 100,00% 90,82% 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 44. Resultados Arbitraje AR-XF31. Enfermedad 1-12. Expertos EX-KV8H y EX-VH7Q

256

EX-KV8H EX-VH7Q


Meningitis 75,00% 100,00% 91,67% 88,89% 90,82% 100,00% 100,00% 100,00% 100,00% 100,00%

Fiebre Reumática 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Sinusitis 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Orquitis 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Brucelosis 0,00% 0,00% 83,33% 100,00% 0,00% 0,00% 0,00% 66,67% 100,00% 0,00%

Parkinson 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%



Fiebre Tifoidea 0,00% 0,00% 83,33% 100,00% 0,00% 0,00% 0,00% 58,33% 100,00% 0,00%

Bronquitis 0,00% 0,00% 83,33% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Laringitis 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Colera 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% NA

Tabla 45. Resultados Arbitraje AR-XF31. Enfermedad 13-24. Expertos EX-KV8H y EX-VH7Q

257

EX-HQ3T Sistema


Faringitis 50,00% 100,00% 91,67% 90,91% 83,71% 33,33% 100,00% 90,00% 89,47% 77,31%

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Pericarditis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Neumonía 80,00% 80,00% 83,33% 85,71% 82,86% 100,00% 77,78% 90,00% 100,00% 90,56%

Difteria 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Pielonefritis 75,00% 75,00% 83,33% 87,50% 81,25% 100,00% 80,00% 95,00% 100,00% 93,30%

Diabetes Tipo 2 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Aspergiloma Pulmonar 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Asma 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Resfriado Común 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Gripe 60,00% 75,00% 75,00% 75,00% 73,90% 100,00% 85,71% 95,00% 100,00% 94,61%

Tabla 46. Resultados Arbitraje AR-XF31. Enfermedad 1-12. Expertos EX-HQ3T y Sistema

258

EX-HQ3T Sistema


Meningitis 50,00% 50,00% 83,33% 90,00% 70,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Sinusitis 100,00% 100,00% 100,00% 100,00% NA 66,67% 100,00% 95,00% 94,44% 89,67%

Orquitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% 100,00%

Brucelosis 0,00% 0,00% 58,33% 87,50% 39,34% 71,43% 100,00% 90,00% 86,67% 89,34%

Parkinson 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%



Fiebre Tifoidea 100,00% 16,67% 58,33% 100,00% 65,08% 70,00% 100,00% 85,00% 76,92% 86,69%

Bronquitis 75,00% 100,00% 91,67% 88,89% 90,82% 62,50% 100,00% 85,00% 80,00% 85,36%

Laringitis 100,00% 100,00% 100,00% 100,00% 100,00% 20,00% 100,00% 80,00% 78,95% 69,87%

Colera 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 47. Resultados Arbitraje AR-XF31. Enfermedad 13-24. Expertos EX-HQ3T y Sistema

259

14.2.2. ARBITRAJE AR-TD46

EX-KS0L EX-SK4V


Faringitis 33,33% 100,00% 83,33% 81,82% 76,11% 0,00% 100,00% 91,67% 91,67% NA

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Pericarditis 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%


Neumonía 66,67% 100,00% 83,33% 75,00% 85,36% 66,67% 66,67% 83,33% 88,89% 77,78%

Difteria 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% NA

Pielonefritis 100,00% 33,33% 83,33% 100,00% 76,11% 100,00% 100,00% 100,00% 100,00% 100,00%



Asma 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Resfriado Común 60,00% 100,00% 83,33% 77,78% 84,16% 100,00% 50,00% 91,67% 100,00% 83,71%

Gripe 75,00% 60,00% 75,00% 85,71% 73,90% 100,00% 75,00% 91,67% 100,00% 90,82%

Tabla 48. Resultados Arbitraje AR-TD46. Enfermedad 1-12. Expertos EX-KS0L y EX-SK4V

260

EX-KS0L EX-SK4V


Meningitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% 100,00%


Sinusitis 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Orquitis 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Brucelosis 0,00% 0,00% 66,67% 100,00% 0,00% 0,00% 0,00% 75,00% 100,00% 0,00%

Parkinson 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%


Pancreatitis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Fiebre Tifoidea 100,00% 40,00% 75,00% 100,00% 76,46% 0,00% 0,00% 66,67% 100,00% 0,00%

Bronquitis 100,00% 100,00% 100,00% 100,00% 100,00% 50,00% 50,00% 83,33% 90,00% 70,00%

Laringitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% NA

Colera 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Tabla 49. Resultados Arbitraje AR-TD46. Enfermedad 13-24. Expertos EX-KS0L y EX-SK4V

261

EX-KV8H EX-VH7Q


Faringitis 0,00% 100,00% 91,67% 91,67% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 0,00% 0,00% 83,33% 100,00% 0,00%



Neumonía 100,00% 66,67% 91,67% 100,00% 88,73% 100,00% 50,00% 83,33% 100,00% 81,62%

Difteria 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Pielonefritis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 50,00% 91,67% 100,00% 83,71%

Diabetes Tipo 2 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Asma 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Resfriado Común 100,00% 100,00% 100,00% 100,00% 100,00% 50,00% 100,00% 91,67% 90,91% 83,71%

Gripe 100,00% 75,00% 91,67% 100,00% 90,82% 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 50. Resultados Arbitraje AR-TD46. Enfermedad 1-12. Expertos EX-KV8H y EX-VH7Q

262

EX-KV8H EX-VH7Q


Meningitis 75,00% 100,00% 91,67% 88,89% 90,82% 100,00% 75,00% 91,67% 100,00% 90,82%


Sinusitis 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Orquitis 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Brucelosis 0,00% 0,00% 83,33% 100,00% 0,00% 0,00% 0,00% 66,67% 100,00% 0,00%

Parkinson 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%



Fiebre Tifoidea 0,00% 0,00% 83,33% 100,00% 0,00% 0,00% 0,00% 66,67% 100,00% 0,00%

Bronquitis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Laringitis 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Colera 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% NA

Tabla 51. Resultados Arbitraje AR-TD46. Enfermedad 13-24. Expertos EX-KV8H y EX-VH7Q

263

EX-HQ3T Sistema


Faringitis 50,00% 100,00% 91,67% 90,91% 83,71% 33,33% 100,00% 90,00% 89,47% 77,31%

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Pericarditis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Neumonía 80,00% 100,00% 91,67% 87,50% 91,83% 85,71% 100,00% 95,00% 92,86% 94,61%

Difteria 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Pielonefritis 75,00% 75,00% 83,33% 87,50% 81,25% 75,00% 75,00% 90,00% 93,75% 84,38%

Diabetes Tipo 2 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Asma 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Resfriado Común 50,00% 100,00% 91,67% 90,91% 83,71% 75,00% 100,00% 95,00% 94,12% 92,01%

Gripe 60,00% 75,00% 75,00% 75,00% 73,90% 100,00% 85,71% 95,00% 100,00% 94,61%

Tabla 52. Resultados Arbitraje AR-TD46. Enfermedad 1-12. Expertos EX-HQ3T y Sistema

264

EX-HQ3T Sistema


Meningitis 50,00% 33,33% 75,00% 88,89% 62,91% 100,00% 75,00% 95,00% 100,00% 92,01%


Sinusitis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Orquitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% 100,00%

Brucelosis 0,00% 0,00% 50,00% 85,71% 37,26% 85,71% 100,00% 95,00% 92,86% 94,61%

Parkinson 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%


Pancreatitis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Fiebre Tifoidea 100,00% 16,67% 58,33% 100,00% 65,08% 70,00% 100,00% 85,00% 76,92% 86,69%

Bronquitis 75,00% 100,00% 91,67% 88,89% 90,82% 50,00% 100,00% 80,00% 75,00% 80,62%

Laringitis 100,00% 100,00% 100,00% 100,00% 100,00% 20,00% 100,00% 80,00% 78,95% 69,87%

Colera 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 53. Resultados Arbitraje AR-TD46. Enfermedad 13-24. Expertos EX-HQ3T y Sistema

265

14.2.3. ARBITRAJE UNIÓN (AR-XF31 ⋃ AR-TD46)

EX-KS0L EX-SK4V


Faringitis 33,33% 100,00% 83,33% 81,82% 76,11% 0,00% 100,00% 91,67% 91,67% NA

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Pericarditis 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%


Neumonía 83,33% 71,43% 75,00% 80,00% 75,35% 100,00% 50,00% 75,00% 100,00% 78,87%

Difteria 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% NA

Pielonefritis 100,00% 33,33% 83,33% 100,00% 76,11% 100,00% 66,67% 91,67% 100,00% 88,73%



Asma 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Resfriado Común 80,00% 100,00% 91,67% 87,50% 91,83% 100,00% 50,00% 91,67% 100,00% 83,71%

Gripe 75,00% 50,00% 66,67% 83,33% 67,68% 100,00% 60,00% 83,33% 100,00% 84,16%

Tabla 54. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 1-12. Exp EX-KS0L y EX-SK4V

266

EX-KS0L EX-SK4V


Meningitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% 100,00%


Sinusitis 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Orquitis 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Brucelosis 0,00% 0,00% 66,67% 100,00% 0,00% 0,00% 0,00% 75,00% 100,00% 0,00%

Parkinson 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%


Pancreatitis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Fiebre Tifoidea 100,00% 33,33% 66,67% 100,00% 72,36% 0,00% 0,00% 66,67% 100,00% 0,00%

Bronquitis 100,00% 80,00% 91,67% 100,00% 91,83% 100,00% 66,67% 91,67% 100,00% 88,73%

Laringitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% NA

Colera 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Tabla 55. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 13-24. Exp EX-KS0L y EX-SK4V

267

EX-KV8H EX-VH7Q


Faringitis 0,00% 100,00% 91,67% 91,67% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 0,00% 0,00% 83,33% 100,00% 0,00%



Neumonía 100,00% 40,00% 75,00% 100,00% 76,46% 100,00% 50,00% 83,33% 100,00% 81,62%

Difteria 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Pielonefritis 0,00% 0,00% 83,33% 100,00% 0,00% 100,00% 33,33% 83,33% 100,00% 76,11%

Diabetes Tipo 2 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Asma 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Resfriado Común 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Gripe 100,00% 75,00% 91,67% 100,00% 90,82% 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 56. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 1-12. Exp EX-KV8H y EX-VH7Q

268

EX-KV8H EX-VH7Q


Meningitis 75,00% 100,00% 91,67% 88,89% 90,82% 100,00% 75,00% 91,67% 100,00% 90,82%


Sinusitis 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Orquitis 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Brucelosis 0,00% 0,00% 83,33% 100,00% 0,00% 0,00% 0,00% 66,67% 100,00% 0,00%

Parkinson 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%



Fiebre Tifoidea 0,00% 0,00% 83,33% 100,00% 0,00% 0,00% 0,00% 58,33% 100,00% 0,00%

Bronquitis 0,00% 0,00% 83,33% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Laringitis 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Colera 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% NA

Tabla 57. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 13-24. Exp EX-KV8H y EX-VH7Q

269

EX-HQ3T Sistema


Faringitis 50,00% 100,00% 91,67% 90,91% 83,71% 33,33% 100,00% 90,00% 89,47% 77,31%

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Pericarditis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Neumonía 80,00% 80,00% 83,33% 85,71% 82,86% 100,00% 77,78% 90,00% 100,00% 90,56%

Difteria 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Pielonefritis 75,00% 75,00% 83,33% 87,50% 81,25% 100,00% 80,00% 95,00% 100,00% 93,30%

Diabetes Tipo 2 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Asma 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Resfriado Común 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Gripe 80,00% 80,00% 83,33% 85,71% 82,86% 100,00% 75,00% 90,00% 100,00% 90,09%

Tabla 58. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 1-12. Exp EX-HQ3T y Sistema

270

EX-HQ3T Sistema


Meningitis 50,00% 33,33% 75,00% 88,89% 62,91% 100,00% 75,00% 95,00% 100,00% 92,01%


Sinusitis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Orquitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% 100,00%

Brucelosis 0,00% 0,00% 50,00% 85,71% 37,26% 85,71% 100,00% 95,00% 92,86% 94,61%

Parkinson 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%


Pancreatitis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Fiebre Tifoidea 100,00% 14,29% 50,00% 100,00% 62,74% 80,00% 100,00% 90,00% 83,33% 90,82%

Bronquitis 75,00% 100,00% 91,67% 88,89% 90,82% 62,50% 100,00% 85,00% 80,00% 85,36%

Laringitis 100,00% 100,00% 100,00% 100,00% 100,00% 20,00% 100,00% 80,00% 78,95% 69,87%

Colera 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 59. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 13-24. Exp EX-HQ3T y Sistema

271

14.2.4. ARBITRAJE INTERSECCIÓN (AR-XF31 ⋂ AR-TD46)

EX-KS0L EX-SK4V


Faringitis 33,33% 100,00% 83,33% 81,82% 76,11% 0,00% 100,00% 91,67% 91,67% NA

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Pericarditis 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%


Neumonía 66,67% 100,00% 83,33% 75,00% 85,36% 66,67% 66,67% 83,33% 88,89% 77,78%

Difteria 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% NA

Pielonefritis 100,00% 33,33% 83,33% 100,00% 76,11% 100,00% 100,00% 100,00% 100,00% 100,00%



Asma 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Resfriado Común 60,00% 100,00% 83,33% 77,78% 84,16% 100,00% 50,00% 91,67% 100,00% 83,71%

Gripe 75,00% 75,00% 83,33% 87,50% 81,25% 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 60. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 1-12. Exp EX-KS0L y EX-SK4V

272

EX-KS0L EX-SK4V


Meningitis 0,00% 100,00% 83,33% 83,33% NA 100,00% 100,00% 100,00% 100,00% 100,00%


Sinusitis 66,67% 100,00% 91,67% 90,00% 88,73% 100,00% 100,00% 100,00% 100,00% 100,00%

Orquitis 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Brucelosis 0,00% 0,00% 75,00% 100,00% 0,00% 0,00% 0,00% 83,33% 100,00% 0,00%

Parkinson 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%



Fiebre Tifoidea 100,00% 50,00% 83,33% 100,00% 81,62% 0,00% 0,00% 75,00% 100,00% 0,00%

Bronquitis 100,00% 100,00% 100,00% 100,00% 100,00% 50,00% 50,00% 83,33% 90,00% 70,00%

Laringitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% NA

Colera 100,00% 100,00% 100,00% 100,00% 100,00% 0,00% 0,00% 91,67% 100,00% 0,00%

Tabla 61. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 13-24. Exp EX-KS0L y EX-SK4V

273

EX-KV8H EX-VH7Q


Faringitis 0,00% 100,00% 91,67% 91,67% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 0,00% 0,00% 83,33% 100,00% 0,00%



Neumonía 100,00% 66,67% 91,67% 100,00% 88,73% 100,00% 50,00% 83,33% 100,00% 81,62%

Difteria 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Pielonefritis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 50,00% 91,67% 100,00% 83,71%

Diabetes Tipo 2 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Asma 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Resfriado Común 100,00% 100,00% 100,00% 100,00% 100,00% 50,00% 100,00% 91,67% 90,91% 83,71%

Gripe 100,00% 75,00% 91,67% 100,00% 90,82% 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 62. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 1-12. Exp EX-KV8H y EX-VH7Q

274

EX-KV8H EX-VH7Q


Meningitis 75,00% 100,00% 91,67% 88,89% 90,82% 100,00% 100,00% 100,00% 100,00% 100,00%


Sinusitis 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% NA

Orquitis 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Brucelosis 0,00% 0,00% 83,33% 100,00% 0,00% 0,00% 0,00% 66,67% 100,00% 0,00%

Parkinson 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%



Fiebre Tifoidea 0,00% 0,00% 83,33% 100,00% 0,00% 0,00% 0,00% 66,67% 100,00% 0,00%

Bronquitis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Laringitis 100,00% 100,00% 100,00% 100,00% NA 0,00% 0,00% 91,67% 100,00% 0,00%

Colera 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% NA

Tabla 63. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 13-24. Exp EX-KV8H y EX-VH7Q

275

EX-HQ3T Sistema


Faringitis 50,00% 100,00% 91,67% 90,91% 83,71% 33,33% 100,00% 90,00% 89,47% 77,31%

Sarcoidosis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Pericarditis 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Neumonía 80,00% 100,00% 91,67% 87,50% 91,83% 85,71% 100,00% 95,00% 92,86% 94,61%

Difteria 0,00% 0,00% 91,67% 100,00% 0,00% 100,00% 100,00% 100,00% 100,00% 100,00%

Pielonefritis 75,00% 75,00% 83,33% 87,50% 81,25% 75,00% 75,00% 90,00% 93,75% 84,38%

Diabetes Tipo 2 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Asma 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Resfriado Común 50,00% 100,00% 91,67% 90,91% 83,71% 75,00% 100,00% 95,00% 94,12% 92,01%

Gripe 40,00% 66,67% 66,67% 66,67% 64,64% 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 64. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 1-12. Exp EX-HQ3T y Sistema

276

EX-HQ3T Sistema


Meningitis 50,00% 50,00% 83,33% 90,00% 70,00% 100,00% 100,00% 100,00% 100,00% 100,00%


Sinusitis 100,00% 100,00% 100,00% 100,00% NA 66,67% 100,00% 95,00% 94,44% 89,67%

Orquitis 50,00% 100,00% 91,67% 90,91% 83,71% 100,00% 100,00% 100,00% 100,00% 100,00%

Brucelosis 0,00% 0,00% 58,33% 87,50% 39,34% 71,43% 100,00% 90,00% 86,67% 89,34%

Parkinson 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%



Fiebre Tifoidea 100,00% 20,00% 66,67% 100,00% 67,84% 60,00% 100,00% 80,00% 71,43% 82,73%

Bronquitis 75,00% 100,00% 91,67% 88,89% 90,82% 50,00% 100,00% 80,00% 75,00% 80,62%

Laringitis 100,00% 100,00% 100,00% 100,00% 100,00% 20,00% 100,00% 80,00% 78,95% 69,87%

Colera 100,00% 100,00% 100,00% 100,00% NA 100,00% 100,00% 100,00% 100,00% 100,00%

Tabla 65. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 13-24. Exp EX-HQ3T y Sistema

277

14.3. TABLAS DE TIEMPOS

14.3.1. MOTOR DE INFERENCIA INICIALIZADO

Caso/Ejecución 1 2 3 4 5 6 7 8 9 10 Media (ms) Media (m)

1 2217 2107 1877 2550 1906 1893 2127 1934 2522 1810 2094,3 ± 265,96 0,0349

2 2579 2141 1993 2498 2580 2098 1909 2334 2548 1824 2250,4 ± 293,12 0,0375

3 5030 3644 4203 4616 5392 5392 3856 3635 3974 5168 4491 ± 714,27 0,0749

4 3767 3536 4083 2937 4170 3273 3256 3672 3585 3147 3542,6 ± 398,98 0,059

5 2135 2575 1935 2663 2428 2011 2531 2176 2594 2694 2374,2 ± 283,45 0,0396

6 1822 1509 1801 1716 1608 1599 1636 1600 1412 1656 1635,9 ± 124 0,0273

7 2348 2189 2859 2430 2310 2419 2700 2590 1981 2628 2445,4 ± 258,26 0,0408

8 1664 2399 1983 2024 1948 2123 1957 1921 2155 2163 2033,7 ± 193,83 0,0339

9 2429 2594 2493 2506 2501 2355 1990 2663 2630 1967 2412,8 ± 246,44 0,0402

10 1835 1975 2618 2008 1860 2492 2130 2499 2567 2350 2233,4 ± 304,89 0,0372

11 2628 2371 2196 2084 2119 2526 1889 2178 2414 2638 2304,3 ± 250,51 0,0384

12 2097 1839 1918 1920 2042 1738 1682 1914 2325 1690 1916,5 ± 199,83 0,0319

13 3042 3567 2987 3232 3554 2764 3674 3585 3733 3680 3381,8 ± 346,14 0,0564

14 2145 2400 1951 1964 2219 1803 2224 2042 1981 2505 2123,4 ± 217,7 0,0354

15 2173 1784 2327 2470 1852 2029 1752 2290 1863 2023 2056,3 ± 249,52 0,0343

16 2287 2823 2833 2690 2985 3008 2569 3081 2652 2227 2715,5 ± 291,65 0,0453

17 2258 2156 1812 2145 2026 1873 1715 2339 2356 1833 2051,3 ± 232,98 0,0342

18 2378 2442 1794 2307 2356 2399 1907 1845 1910 1969 2130,7 ± 264,95 0,0355

19 1982 2139 1899 2553 2449 1818 2600 2522 1994 2103 2205,9 ± 296,19 0,0368

20 2017 2670 2302 2697 2140 2208 1856 1844 2395 2605 2273,4 ± 317,75 0,0379

Tabla 66. Tabla de tiempos (en ms, excepto Media (m)) con motor de Inf inicializado

278

14.3.2. MOTOR DE INFERENCIA NO INICIALIZADO

Caso/Ejecución 1 2 3 4 5 6 7 8 9 10 Media (ms) Media (m)

1 4466 6060 5447 6401 4561 4945 6068 4890 5574 6603 5501,5 ± 767,67 0,0917

2 4286 4953 4276 5370 5831 4860 5231 4234 5492 5421 4995,4 ± 571,79 0,0833

3 4994 5000 5954 5541 5172 6236 6664 6226 5943 6631 5836,1 ± 631,65 0,0973

4 7720 7832 6628 5876 5500 7214 6157 6706 5511 5889 6503,3 ± 862,14 0,1084

5 6214 5239 7231 6166 5557 6733 5465 6499 6623 5354 6108,1 ± 677,02 0,1018

6 3752 5066 3774 5101 4615 4800 4862 4376 4781 4430 4555,7 ± 479,65 0,0759

7 7407 5778 5632 6132 5486 6462 7468 6110 6193 6410 6307,8 ± 673,67 0,1051

8 4840 4434 4456 4073 5331 4079 4217 4675 5287 5133 4652,5 ± 479,61 0,0775

9 4688 5044 4675 5290 5287 5581 5371 5779 4330 4300 5034,5 ± 514,29 0,0839

10 6085 5466 5840 5038 5045 5465 6851 6566 6145 5529 5803 ± 609,28 0,0967

11 5460 4356 4988 3817 4207 4214 5198 3981 4482 4506 4520,9 ± 534,08 0,0753

12 3845 5275 4531 3717 3760 5267 5182 3853 3629 4496 4355,5 ± 684,2 0,0726

13 6197 4808 5713 5453 5121 5318 5941 5005 6144 5985 5568,5 ± 497,95 0,0928

14 5438 4593 4573 4552 4968 4379 4821 4502 4247 4128 4620,1 ± 378,8 0,077

15 4245 4670 5366 4343 4370 3927 4391 3883 3725 3800 4272 ± 491,83 0,0712

16 5960 5111 5881 5600 6128 4999 6351 5047 5243 6225 5654,5 ± 521,31 0,0942

17 4808 3412 3962 4287 4468 4032 4453 3960 4645 4424 4245,1 ± 408,84 0,0708

18 5532 5923 5086 5314 5056 4684 4113 4467 4624 4699 4949,8 ± 539,71 0,0825

19 5148 3854 5255 4298 4728 3826 4494 5309 4871 4553 4633,6 ± 534,46 0,0772

20 5448 3900 4335 5123 5797 5771 5771 5564 3978 5681 5136,8 ± 769,66 0,0856

Tabla 67. Tabla de tiempos (en ms, excepto Media (m)) con motor de Inf no inicializado

279

14.4. TABLAS DE CONSUMOS DE MEMORIA

14.4.1. MOTOR DE INFERENCIA INICIALIZADO

Caso/Ejecución 1 2 3 4 5 6 7 8 9 10 Media (MB)

1 155608524 157577836 188026999 172364012 168437108 167736226 183002086 162918738 174663610 166866130 161,86

2 38971379 35101452 40851932 34572558 35385893 36394775 38500041 35731044 36127432 36032308 35,06

3 59508798 56077602 64840992 54335933 64814624 55009708 54722838 60810766 54254960 60626185 55,79

4 229068203 204525134 211793352 197936334 226968093 201985523 221948162 229206751 217796108 218324408 205,95

5 218596808 209516761 199442163 192846942 195434267 221871101 203412893 224787533 208642999 190396218 196,93

6 134925215 150434837 148453655 149805284 139937649 158951702 131232313 130716564 156916052 133654450 136,85

7 164461640 178415780 156029756 176528521 167158543 167563568 155502308 168574405 151062858 157737211 156,69

8 138259193 143683819 138939943 151492529 136501333 127821795 151783554 151165810 135102432 147303649 135,62

9 145558289 157000627 139370259 140928879 148113632 138487325 136613192 138163233 143762433 145444732 136,7

10 133031575 142047416 149845974 153459539 128751239 139618558 132350834 152727112 140449801 149032649 135,55

11 141516387 150866758 144876437 138660985 135187562 146832965 140181381 147089888 135555603 148221074 136,28

12 98833212 100292560 99284796 98005404 92037359 102310996 94892218 105001271 94629983 106235598 94,56

13 185652939 201156393 207647851 189149077 192218667 200299429 197381924 209757029 180504192 182005127 185,56

14 172286839 176430003 183677492 163471002 153240496 182827580 160834603 157142534 153992578 186164740 161,18

15 151618639 143973675 141845811 152855036 130252633 129607037 133400614 139553977 147639592 138419543 134,39

16 164311990 171061780 189061926 179188844 189557729 189337121 166956542 173101433 181274275 184558178 170,56

17 136928769 164491175 138656637 140332473 156092257 139016238 144352526 159394569 136468586 148165348 139,61

18 140993678 142721284 150141588 146805189 128515228 127209642 137429873 150962588 150452441 141936862 135,15

19 127251538 126174828 126146073 143895891 139009703 126468432 143109078 123003820 134865339 142186791 127,04

20 111814243 120921334 112999288 119977536 122638540 127634298 128971206 119517128 121020728 132866281 116,19

Tabla 68. Tabla consumo de memoria (en bytes, excepto Media) con motor de Inf inicializado

280

14.4.2. MOTOR DE INFERENCIA NO INICIALIZADO

Caso/Ejecución 1 2 3 4 5 6 7 8 9 10 Media (MB)

1 147161414 131656212 126641042 144355242 125301094 123236349 143444988 141867058 144138982 143007198 133,87

2 101046975 97035130 97730965 100035906 95251464 93525052 91585795 86006087 85590903 93535292 91,93

3 148689532 169406362 154632905 152548579 175342469 172096685 169939070 147131987 164836622 172281137 158,88

4 135141663 129173121 147051926 141309209 132518581 143990182 148806128 138857672 132124173 138865699 135,53

5 56819478 55871388 61434431 61954733 53924193 61203631 61251567 62163323 55088366 54632860 57,06

6 71895766 79090962 82791594 77842922 80078356 80341016 69707594 82055675 71510652 78598062 75,58

7 45674426 52794492 50710377 52072120 48548804 50388187 54323557 51444137 47637524 49310882 49,11

8 138255782 141128654 150917785 142119605 141070387 128754681 137279316 128593930 128898737 130282478 133,53

9 147991599 147911217 145459678 132108853 138767705 139812883 149415092 138161456 134873561 151743022 139,28

10 46944614 44790494 47689356 47901824 46428319 45176477 46227015 47855502 46281027 45368862 45,38

11 144426530 125235978 142166895 127039522 130275461 136072821 132756388 130413108 126112933 147291985 131,03

12 94540630 88372030 84888625 88340584 95991702 88712296 89651872 86717579 99058854 88336392 88,34

13 42825693 38276478 38559674 41842155 42285824 36155946 42120247 42570160 36060638 36523533 38,79

14 115714184 110325958 105612288 105147731 108944654 125090294 115783951 122230693 119110751 115237798 111,64

15 94588437 95157246 103398526 112039345 94929250 110070697 98328783 93336920 110428977 107485235 99,59

16 60955384 60915953 53797827 58155774 54101216 57971160 56916901 56384243 61870446 56559020 56,41

17 103995143 99015595 110292847 98033599 106247394 108993647 110935415 102081074 101490472 91047118 100,79

18 119264621 102823782 112755830 114390903 116959392 122750011 104513297 118234029 106898125 114452516 110,65

19 139843412 135466568 130895387 143115445 141144611 134634469 138756377 138069219 138825698 123096749 133,19

20 112797274 124434564 113006992 117082526 123403176 109793631 107239812 117701012 106344144 120860340 112,56

Tabla 69. Tabla consumo de memoria (en bytes, excepto Media) con motor de Inf no inicializado

281

14.5. PUBLICACIONES

14.5.1. PUBLICACIONES EN CONGRESOS

Rodríguez-González, A., Jimenez-Domingo, E., García-Crespo, A., Alor-

Hernandez, G., Gomez-Berbis, J.M., Posada-Gomez, R. (2011). Designing an

Ontology to Support the Creation of Diagnostic Decision Support System.

First International Workshop on Semantic Applied Technologies on

Biomedical Informatics (SATBI 2011), In conjunction with ACM

International Conference on Bioinformatics and Computational Biology

(ACM-BCB 2011).

Rodríguez-González, A., Mayer, M.A., Alor-Hernandez, J.M., Cortes-Robles,

G., Lagares-Lemos, A. (2010). Using Ontologies and Probabilistic Networks

to Develop a Preventive Stroke Diagnosis System (PSDS). The 23RD IEEE

International Symposium on Computer-Based Medical Systems, 2010.

CBMS 2010.

Rodríguez-González, A., Jimenez-Domingo, E., Radzimski, M., Gomez-Berbis,

J.M., Alor-Hernandez, G., Posada-Gomez, R., Labra-Gayo, J.E. (2009).

Applying Caching Capabilities to Inference Applications based on Semantic

Web. International Conference on Computational Collective

Intelligence, 2009. ICCCI 09. Vol. 244/2009, 27-37.

http://dx.doi.org/10.1007/978-3-642-03958-4_3

Rodríguez-González, A., Labra-Gayo, J.E., Alor-Hernandez, G., Gomez-Berbis,

J.M., Posada-Gomez, R. (2009). ADONIS: Automated Diagnosis System

based on Sound and Precise Logical Descriptions. 22nd IEEE International

Symposium on Computer-Based Medical Systems, 2009. CBMS 2009.

http://dx.doi.org/10.1109/CBMS.2009.5255449

Rodríguez-González, A., Jimenez-Domingo, E., Fernandez, J., Eccius, M.,

Gomez-Berbis, J.M., Alor-Hernandez, G., Posada-Gomez, R., Laufer, C.

(2009). SemMed: Applying Semantic Web to Medical Recommendation

Systems. First International Conference on Intensive Applications and

Services, 2009. INTENSIVE '09.

http://dx.doi.org/10.1109/INTENSIVE.2009.12

Rodríguez-González, A., Fernandez, J., Jimenez-Domingo, E., Mencke, M.,

Radzimski, M., Gomez-Berbis, J.M. (2009). MEDFINDER: Using Semantic

Web, Web 2.0 and Geolocation methods to develop a Decision Support

http://dx.doi.org/10.1007/978-3-642-03958-4_3

http://dx.doi.org/10.1109/CBMS.2009.5255449

http://dx.doi.org/10.1109/INTENSIVE.2009.12

282

System to locate doctors. Fifth International Conference on Web

Information Systems and Technologies (WEBIST).

Rodríguez-González, A., Mencke, M., Alor-Hernandez, G., Posada-Gomez. R.,

Gomez-Berbis, J.M., Aguilar-Lasserre, A. (2009). MEDBOLI: Medical

Diagnosis Based on Ontologies and Logical Inference. International

Conference on eHealth, Telemedicine, and Social Medicine, 2009.

eTELEMED '09. http://dx.doi.org/10.1109/eTELEMED.2009.43

14.5.2. PUBLICACIONES EN REVISTAS NO INDEXADAS

Rodríguez-González, A., García-Crespo, A., Colomo-Palacios, R., Labra-Gayo,

J.E., Gomez-Berbis, J.M., Alor-Hernandez, G. (2011). Automated Diagnosis

through Ontologies and Logical Descriptions: the ADONIS approach.

International Journal of Decision Support System Technology (IJDSST),

3(1), 21-39. http://dx.doi.org/10.4018/jdsst.2011010102

14.5.3. PUBLICACIONES EN REVISTAS INDEXADAS EN JCR

García-Crespo, A., Rodríguez, A., Mencke, M., Gómez-Berbís, J.M., & Colomo-

Palacios, R., (2010). ODDIN: Ontology-driven differential diagnosis based

on logical inference and probabilistic refinements. Expert Systems with

Applications, 37 (3), 2621-2628. .

http://dx.doi.org/10.1016/j.eswa.2009.08.016 (Impact factor 2010: 1.924 -

Q1 in OPERATIONS RESEARCH & MANAGEMENT SCIENCE)

Rodríguez-González, A., Labra-Gayo, J.E., Colomo-Palacios, R., Mayer M.A.,

Gomez-Berbis, J.M., García-Crespo, A. (2011) SeDeLo: Using Semantics and

Description Logics to support aided clinical diagnosis. Journal of Medical

Systems. http://dx.doi.org/10.1007/s10916-011-9714-1 (Impact factor

2010: 1.064 – Q3 in MEDICAL INFORMATICS)

Rodríguez-González, A., Hernandez-Chan, G., Colomo-Palacios, R., Gomez-

Berbis, J.M., García-Crespo, A., Alor-Hernandez, G., Valencia-Garcia, R.

(2011). Towards an Ontology to support semantics enabled Diagnostic

Decision Support Systems. Special issue on Semantic Web and

Healthcare. Current Bioinformatics. (Impact Factor 2010: 0.976 - Q4 in

BIOCHEMICAL RESEARCH METHODS)

http://dx.doi.org/10.1109/eTELEMED.2009.43

http://dx.doi.org/10.4018/jdsst.2011010102

http://dx.doi.org/10.1016/j.eswa.2009.08.016

http://dx.doi.org/10.1007/s10916-011-9714-1

Facultad de Informática Departamento de Informática y...

Documents

Transcript of Facultad de Informática Departamento de Informática y...