tesis doctoral - Integration of Business Information Systems (IBIS)
Anuncio
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
2
Una vez terminado el juego, el rey y el peón vuelven a la misma caja.
Proverbio italiano.
I
II
A mi familia.
III
IV
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.
V
VI
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.
VII
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.
VIII
I ND ICE D E C O N T E 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.
2.2.
CONCLUSIONES ............................................................................................................................................................. 40
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.
ii
Análisis de SNOMED-CT............................................................................................................................. 72
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.
4.5.
DISEÑO .......................................................................................................................................................................... 84
4.4.1.1.
Clases ................................................................................................................................................................. 84
4.4.1.2.
Relaciones ........................................................................................................................................................ 86
4.4.1.3.
Propiedades de datos.................................................................................................................................. 89
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
iii
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.
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.
Fase de evaluación. Diseño del experimento .................................................................................. 184
8.2.2.2.
Fase de análisis de resultados ............................................................................................................... 185
EVALUACIÓN DE LAS TECNOLOGÍAS ....................................................................................................................... 185
8.2.3.1.
Fase de evaluación. Diseño del experimento .................................................................................. 185
8.2.3.2.
Fase de análisis de resultados ............................................................................................................... 186
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.
iv
EVALUACIÓN DE LA COMPLEJIDAD COMPUTACIONAL. RENDIMIENTO .............................................................. 184
8.2.2.1.
8.2.3.
8.3.
EVALUACIÓN DE LA EXACTITUD .............................................................................................................................. 173
EVALUACIÓN COMPUTACIONAL .............................................................................................................................. 197
8.3.2.1.
8.3.3.
Conclusiones ................................................................................................................................................. 200
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.
9.3.
VERIFICACIÓN DE LA EFICIENCIA COMPUTACIONAL (HIPÓTESIS H1.2) ..............................207
9.3.1.
9.4.
CONCLUSIONES .......................................................................................................................................................... 207
CONCLUSIONES .......................................................................................................................................................... 209
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
v
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
vi
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
I ND ICE D E F I GU R A S
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
FIGURA 36. ETAPA 2 DE LA INTERACCIÓN DE MEDICAMENTOS ......................................................................................... 127
FIGURA 37. ETAPA 3 DE LA INTERACCIÓN DE MEDICAMENTOS ......................................................................................... 128
FIGURA 38. ETAPA 4 DE LA INTERACCIÓN DE MEDICAMENTOS ......................................................................................... 128
vii
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
viii
ix
I ND ICE D E T A B L A 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
x
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
xi
A C 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
xii
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
xiii
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
xiv
ii
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
1
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
2
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.
3
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 SNOMEDCT, 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.
4
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
5
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)
6
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 GuillainBarré (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; BertaudGounot 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.
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.
1
7
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ÍNIC A (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).
8
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
9
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.
10
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.
11
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
12
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.
13
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).
14
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:
15
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
16
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
17
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.
18
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 InternistI/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
19
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.
20
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
21
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
22
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
23
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,
24
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
25
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
26
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 IFTHEN construidas con la ayuda de expertos en el dominio como los médicos
27
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.
28
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.
29
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.
30
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,
31
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
32
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
33
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,
34
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
35
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.
36
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
37
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.
38
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
39
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 tiempofrecuencia 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
40
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.
41
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.
42
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
43
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
44
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
45
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
46
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 metaontologí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.
47
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
DESCRIPCIONES LÓGICAS
CONOCIMIENTO
MEDIANTE
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.
48
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
Class
Property
Object
DL
Concept
Role
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.
49
2.2.1.3.
: Restricciones de cardinalidad.
: Restricciones de cardinalidad cualificadas.
: Uso de propiedades de tipo DataType.
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.
50
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
de reglas:
está definida por la siguiente formación
Los axiomas son de la forma
las expresiones de concepto.
Las
expresiones
de
donde C y D son
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:
51
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.
cualificadas
Restricciones numéricas
Restricciones
:
numéricas
:
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
naturales y pred( ) el conjunto de los predicados binarios <, ≤, >, y ≥ .
de los números
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
son de la forma:
52
donde los axiomas
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
53
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
C es
modelo
de
que
si existe un modelo
tal
.
subsumido
,
escribe:
por D con
tenemos
respecto
que
a
si
para
.
todo
Esto
se
.
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
individuo:
es un TBox, A es un ABox, C un concepto y/o nombre de
A es consistente con respecto a
es modelo de
y de A.
o:C se
deriva
de
modelo
de
cumple
si existe una interpretación que
. esto es:
y A si
todo
.
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.
que
+
+
es
es
cualificadas.
es
roles
transitivos
+
inclusión
nominales.
Se
demuestra
también
extendida
con
restricciones
+ 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
ontología actualmente más aceptado.
es decidible y es base para el lenguaje de
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).
54
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.
55
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.
56
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.
57
Builtin
sLiteral(?x) notLiteral(?x)
isFunctor(?x) notFunctor(?x)
isBNode(?x) notBNode(?x)
bound(?x...) unbound(?x..)
equal(?x,?y) notEqual(?x,?y)
lessThan(?x,
greaterThan(?x, ?y)
le(?x, ?y), ge(?x, ?y)
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)
strConcat(?a1, .. ?an, ?t)
uriConcat(?a1, .. ?an, ?t)
Operaciones
Se encarga de comprobar si el argumento recibido es o no
un litera, un literal functor o un nodo en blanco
respectivamente.
Comprueba si los argumentos son variables ligadas o no.
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.
?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).
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á.
regex(?t, ?p)
regex(?t, ?p, ?m1, .. ?mn)
now(?x)
makeTemp(?x)
makeInstance(?x, ?p, ?v)
makeInstance(?x, ?p, ?t, ?v)
makeSkolem(?x, ?v1, ... ?vn)
noValue(?x, ?p)
noValue(?x ?p ?v)
remove(n, ...)
drop(n, ...)
isDType(?l, ?t) notDType(?l, ?t)
print(?x, ...)
listContains(?l, ?x)
listNotContains(?l, ?x)
listEntry(?list, ?index, ?val)
listLength(?l, ?len)
58
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).
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.
Enlaza ?x con un valor de xsd:dateTime que corresponda a
la hora actual.
Genera un nodo en blanco y lo enlaza con ?x.
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.
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.
Devuelve verdadero si no existe una tripleta (x,p,*) o
(x,p,v) en el modelo o en las deducciones forward explicitas.
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.
Comprueba si un literal ?l es (o no) una instancia de tipo
de datos definida por el recurso ?t.
Imprime (a la salida estándar) la representación de cada
argumento. Esta primitiva es útil para depurar.
Primitiva usada para comprobar si una lista determinada
contiene o no un elemento.
Enlaza ?val con la entrada en la posición ?index de la lista
en RDF ?list.
Añade el tamaño proporcionado (?len) a la lista (?l)
listEqual(?la, ?lb)
listNotEqual(?la, ?lb)
listMapAsObject(?s, ?p ?l)
listMapAsSubject(?l, ?p, ?o)
table(?p) tableAll()
hide(p)
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.
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).
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.
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
59
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
60
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; CastroSá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 INFERENC IA 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
61
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 DECI SIÓ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.
62
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.
tarea.
En lo referido a la clasificación de los DSS existen varias formas de realizar esta
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.
63
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).
64
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,
65
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.
66
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-
67
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
68
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.
69
4.
REPRESENTACIO N
CONOCIMIENTO
DEL
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
70
ú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á
71
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).
72
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
73
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 SNOMEDCT 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
74
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,
En este contexto el término criterio de elegibilidad es sinónimo del concepto
criterio de diagnóstico.
2
75
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
located_in
derives_from
has_symptom
effects
has_agent
results_in
results_in_formation_of
transmitted_by
-
Tabla 4. Relaciones ontología DO
A continuación se muestran unos ejemplos de cómo se componen los elementos
usando estas relaciones:
76
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
[anatomy]
is
located_in
lung.
Snippet 7. Ejemplo relaciones DO (II)
disease term: lymphoid cancer
A hematologic cancer that is
composed_of white blood cell.
located_in
lymphocytes
which
is
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.
77
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.
78
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
79
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.
80
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:
81
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:
82
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.
83
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
84
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:
85
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.
86
Nombre
isUsingMedicine
isLabTestOf
isSymptomOf
Dominio
Consult
Labtests
Diseases
Symptoms
hasLabTest
hasSymptom
Diseases
Consult
Diseases
Medicines
SymptomContainer
containsSymptomOrDisease
containsLabTest
containesMedicine
hasSymptomContainer
LabTestContainer
MedicineContainer
Diseases
Medicines
Rango
Medicines
Diseases
Consult
Diseases
Medicines
Labtests
Diseases
Symptoms
Diseases
Symptoms
LabTests
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.
87
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.
88
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.
89
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
ageRank
code
countriesWithMoreIncidence
description
isCIE
isPatognomic
links
names
observations
operations
sex
tags
transfusions
weight
Dominio
Diseases
All (Excepto Contenedores)
Diseases
All (Excepto Contenedores)
All (Excepto Contenedores)
SymptomContainer
All (Excepto Contenedores)
All (Excepto Contenedores)
All
Diseases
Diseases
All (Excepto Contenedores)
Diseases
SymptomContainer
Rango
String
String
String
String
Boolean
Boolean
String
String
String
Boolean
String (Nominal)
String
Boolean
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,
90
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.
91
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 SNOMEDCT. 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
92
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.
93
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).
94
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
genid29881
genid29882
genid29883
genid29884
genid29885
genid29886
Código
Terminología
ICD9CM_2010:333.4
MSH2010_2010_02_2
2:D006816
NCI2009_04D:C38825
SNOMEDCT_2010_1_3
1:155006000
SNOMEDCT_2010_1_3
1: 58756001
UMLS_CUI:C0020179
URI
http://purl.org/obo/owl/ICD9CM_2010#ICD9CM_2010_333.4
http://purl.org/obo/owl/MSH2010_2010_0_2_22#MSH2010_2
010_02_22_D006816
http://purl.org/obo/owl/NCI2009_04D_C38825
http://purl.org/obo/owl/SNOMEDCT_2010_1_31#SNOMEDCT_
2010_1_31_155006000
http://purl.org/obo/owl/SNOMEDCT_2010_1_31#SNOMEDCT_
2010_1_31_58756001
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
95
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
96
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
97
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.
98
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 O NTOLOGÍ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
99
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.
100
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.
101
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.
102
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
103
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.
104
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.
La Figura 26 muestra una representación de esta ontología.
105
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.
La Figura 27 muestra una representación de esta ontología.
106
Figura 27. Representación ontología DRONT
4.5.4. RELACIONES DE LAS ON TOLOGÍAS DE CADA SUB DOMINIO
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 OBOFoundry (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
Diagnosis Ontology
Clinical Findings Ontology
Diseases Ontology
Signs Ontology
Diagnostic Test Ontology
Drugs Ontology
Prefijo
ddxont
clinicalfindings
disont
signs
dto
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.
107
Relación
has_sign
has_disorder
is_patognomic
has_diagnostic_test
can_occurr_with
Dominio
disont:DO
ddxont:QUERY
disont:DO
ddxont:QUERY
signs:SO
dto:DTO
disont:DO
ddxont:QUERY
signs:SO
Rango
signs:SO
disont:DO
disont:DO
dto:DTO
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
DDxOnt (Diagnosis
Ontology)
Clinical Findings Ont
Relaciones
5
Clases
1
Instancias
0
0
0
0
DisOnt (Diseases
Ontology)
DTOnt (Diagnostic
Test Ontology)
SignsOnt (Signs
Ontology)
Drugs Ont (Drugs
Ontology)
0
277
90
0
84
27
0
356
127
0
19
4
Expresividad
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.
108
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.
109
4.5.5. BASE DE DATOS
TERMINOLOGÍAS
CONTENEDORA
DE
CÓDIGOS
DE
OTRAS
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
snomed_id
type
code
snomed_uri
term_uri
Descripción
Código SNOMED
Terminología
Código Terminología
URI a SNOMED (OWL)
URI a Terminología
Tipo
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
Otros
Primary Key
-
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.
110
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
111
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
112
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.
113
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:
114
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
115
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.
116
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
117
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
118
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.
119
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.
120
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.
121
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:
X".
Probabilidad del "Síntoma A" con peso "Medio" en la "Enfermedad
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
122
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
123
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
124
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
125
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:
126
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:
Figura 36. Etapa 2 de la interacción de medicamentos
127
Etapa 3:
C1
C2
…
CN
Figura 37. Etapa 3 de la interacción de medicamentos
Etapa 4:
Figura 38. Etapa 4 de la interacción de medicamentos
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:
128
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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
A
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
B
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
C
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
D
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
Salida
D
C
CD
B
BD
BC
BCD
A
AD
AC
ACD
AB
ABD
ABC
ABCD
Salida Real
Cefalea
Anuria
Anuria, Cefalea
Náusea
Náusea, Cefalea
Náusea, Anuria
Náusea, Anuria, Cefalea
Deshidratación
Deshidratación, Cefalea
Deshidratación, Anuria
Deshidratación, Anuria, Cefalea
Deshidratación, Náusea
Deshidratación, Náusea, Cefalea
Deshidratación, Náusea, Anuria
Deshidratación, Náusea, Anuria, Cefalea
Tabla 12. Tabla de ejemplo del cálculo de interacciones
129
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.
130
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.
131
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.
132
(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>
133
<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:unionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#hasSymptom"/>
<owl:someValuesFrom rdf:resource="#SYM_E_Class"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasSymptom"/>
<owl:someValuesFrom rdf:resource="#SYM_A_Class"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasLabTest"/>
<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:
134
hasSymptom
hasSymptom
…
hasSymptom
hasLabTest
hasLabTest
…
hasLabTest
<Instancia síntoma 1>
<Instancia síntoma 2>
<Instancia síntoma n>
<Instancia prueba 1>
<Instancia prueba 2>
<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:onProperty rdf:resource="#hasSymptom"/>
</owl:Restriction>
</rdf:type>
<rdf:type>
<owl:Restriction rdf:nodeID="b47">
<owl:cardinality
rdf:datatype="&xsd;nonNegativeInteger">0</owl:cardinality>
<owl:onProperty rdf:resource="#hasLabTest"/>
</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
135
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).
136
@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 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:diagnosis ont:DIS_P)
<- (?i ont:hasSymptom ont:SYM_E)
noValue(?i, ont:hasNegSymptom ont:DIS_DIS_P_NOT_SYM)
noValue(?i, ont:hasNegLabTest ont:DIS_DIS_P_NOT_LABT)]
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:diagnosis ont:DIS_P)
<- (?i ont:hasLabTest ont:LT_1)
noValue(?i, ont:hasNegSymptom ont:DIS_DIS_P_NOT_SYM)
noValue(?i, ont:hasNegLabTest ont:DIS_DIS_P_NOT_LABT)]
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
137
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.
138
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
139
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:
140
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>
<owl:unionOf rdf:parseType="Collection">
<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).
141
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,
{SymC,
{SymD,
SymB},{SymA, SymC},{SymA, SymD},{SymA, SymE}
SymC},{SymB, SymD},{SymB, SymE}
SymD},{SymC, SymE}
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
142
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
143
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
144
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.
145
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
146
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 PRO BLEMA
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}
147
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:
148
Secreción Nasal (Código SNOMED 64531003)
Congestión Nasal (Código SNOMED 68235000)
Dolor de cabeza (Código SNOMED 25064002)
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:
garganta }
Bronquitis = { Tos, Debilidad, Fiebre, Disnea, Sinusitis, Dolor de
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:
[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 42. Reglas iniciales de ODDIN
149
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).
150
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)
[rule_I32398004_I36971009DISORDER:
(?i ont:has_sign ont:I36971009DISORDER) <- (?i ont:has_sign
signs:I68235000) noValue(?i, ont:hasNegSign
ont:I32398004_NOT_SIGNS) noValue(?i, ont:hasNegDT
ont:I32398004_NOT_DT) ]
Snippet 45. Regla MDSS-OPM para signos (II)
[rule_I32398004_I36971009DISORDER:
(?i ont:has_sign ont:I36971009DISORDER) <- (?i ont:has_sign
signs:I25064002) noValue(?i, ont:hasNegSign
ont:I32398004_NOT_SIGNS) noValue(?i, ont:hasNegDT
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.
151
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_SIGNS) noValue(?i, ont:hasNegDT
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
signs:I49727002) noValue(?i, ont:hasNegSign
ont:I32398004_NOT_SIGNS) noValue(?i, ont:hasNegDT
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.
152
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:
153
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)
Secreción Nasal (Código SNOMED 64531003)
Congestión Nasal (Código SNOMED 68235000)
Dolor de cabeza (Código SNOMED 25064002)
Imaginemos que la consulta que queremos hacer al sistema se basa en introducir
como signos/síntomas de entrada los siguientes elementos:
Secreción Nasal (Código SNOMED 64531003)
Congestión Nasal (Código SNOMED 68235000)
Dolor de cabeza (Código SNOMED 25064002)
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
(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#I68235000)
Rule rule_I36971009_SIGN:I64531003 <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#I64531003)
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.
154
A continuación se muestra la segunda derivación:
Rule rule_I32398004_I36971009DISORDER_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_I32398004_I36971009DISORDER_SIGN_I68235000 <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#I68235000)
Rule rule_I32398004_I36971009DISORDER_SIGN_I64531003 <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#I64531003)
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 <Rule rule_I32398004_I36971009DISORDER_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)
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.
155
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.
156
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.
157
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
158
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).
159
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,
160
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).
|
|
161
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:
|
|
162
|
|
|
|
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.
163
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
P(OV)
P(LVH)
P(DI)
P(I)
P(I|OV)
P(I|LVH)
P(I|DI)
Probabilidad
0.15
0.15
0.028
0.00322
0.0195
0.0179
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:
|
164
∏
|
Para ilustrar el funcionamiento, se expone como ejemplo el siguiente cálculo:
|
̅̅̅̅̅̅
|̅̅̅̅̅̅
|
|
Para realizar dicho cálculo se debe obtener la probabilidad
obtenida aplicando la fórmula VIII como se expone a continuación:
|̅̅̅̅̅̅
|̅̅̅̅̅̅ , la cual fue
|
̅̅̅̅̅̅
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:
165
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:
̅̅̅̅̅̅̅̅̅|
166
̅̅̅̅
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.
2.
3.
Mejora de la base de conocimiento
Mejora del sistema de inferencia
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.
167
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.
168
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
169
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 cognitivosemá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
170
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
171
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.
172
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.
173
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.
174
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.
175
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
o
o
o
NE: 5
EC: 3
NCC: 20
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++).
176
4.
b.
Asignamos al caso clínico actual, el experto (CC[i].add(E[x])).
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.
177
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
178
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.
179
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).
Expertos
Positivo
Negativo
Sistema
Positivo
Negativo
A (TP)
B (FN)
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.
180
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.
Arbitraje
Positivo
Negativo
Experto
Positivo
Negativo
A (TP)
B (FN)
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
181
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
182
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
183
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”.
8.2.2.1.
FASE DE EVALUACIÓN. DISEÑO DEL EXPERIMENTO
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).
184
8.2.2.2.
FASE DE ANÁLISIS DE RESULTADOS
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.
8.2.3.1.
FASE DE EVALUACIÓN. DISEÑO DEL EXPERIMENTO
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.
185
8.2.3.2.
FASE DE ANÁLISIS DE RESULTADOS
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”.
186
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
6157
Nieves
Apellidos
Ortíz-Roldan
Rodríguez
39/06033
39/6030-3
08/19060
24878
Barcelona
Nuria
Cristina
Manuel
Carmen
Institución y Puesto
Edad Sexo
28
F
Ovalle
Maza Anillo
Iglesias
Servicio Cántabro de Salud
Residente de 4º Año en Hospital Valdecilla
(Santander)
Residente de 4º año HUMV
Institut Català de la Salut. CAP El Carmel. Barcelona
28
30
51
F
F
M
Olmos Domínguez
Institut Català de la Salut
51
F
Tabla 17. Evaluadores
ID Profesional Nombre
Miguel
24433
Ángel
CNP
María
00195805432 Teresa
Apellidos
Mayer Pujadas
Institución y Puesto
Director de Web Médica Acreditada. Colegio Oficial
de Médicos de Barcelona.
Fábregas Ruano
MIR 1 en el Hospital Universitario Virgen Macarena
Edad Sexo
50
M
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 ARXF31 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.
187
Sistema vs Expertos (AR-XF31)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
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%
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.
Sistema vs Expertos Seleccionados (AR-XF31)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
Sistema
Experto mayor
equilibrio (EXKS0L)
Experto menor
equilibrio (EXKV8H)
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%
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 ARXF31 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
188
de los datos obtenidos para el sistema (media de todas las enfermedades) con las medias
para cada experto.
Sistema vs Expertos (AR-TD46)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
Sistema
EX-KS0L
EX-SK4V
EX-KV8H
EX-VH7Q
EX-HQ3T
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%
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.
Sistema vs Expertos Seleccionados (AR-TD46)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
Sistema
Experto mayor
equilibrio (EXKS0L)
Experto menor
equilibrio (EXKV8H)
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%
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).
189
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.
Sistema vs Expertos (Unión)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
Sistema
EX-KS0L
EX-SK4V
EX-KV8H
EX-VH7Q
EX-HQ3T
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%
Figura 50. Sistema vs Expertos. Unión de arbitrajes
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 más y menos equilibrado, y la media de
todos los expertos.
Sistema vs Expertos Seleccionados (Unión)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
Sistema
Experto mayor
equilibrio (EXKS0L)
Experto menor
equilibrio (EXKV8H)
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%
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).
190
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.
Sistema vs Expertos (Intersección)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
Sistema
EX-KS0L
EX-SK4V
EX-KV8H
EX-VH7Q
EX-HQ3T
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%
Figura 52. Sistema vs Expertos. Intersección de arbitrajes
Por otra parte, la Figura 53 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.
Sistema vs Expertos Seleccionados
(Intersección)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
Sistema
Experto mayor
equilibrio (EXKS0L)
Experto menor
equilibrio (EXKV8H)
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%
Figura 53. Sistema vs Expertos Seleccionados. Intersección de arbitrajes
191
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.
Nivel de Correlación (Caso 1 a 10)
100%
88,35%
7
100%
6
100%
5
88%
100%
50%
9
10
66%
60%
100%
80%
70%
100%
80%
83%
100%
90%
40%
30%
20%
10%
0%
1
2
3
4
Nivel Correlación
Media
Figura 54. Nivel de correlación entre árbitros. Caso del 1 al 10
192
8
Nivel de Correlación (Caso 11 a 20)
100%
60%
57%
50%
50%
40%
100%
16
100%
15
66%
13
100%
12
100%
100%
70%
87%
80%
88,35%
90%
90%
30%
20%
10%
0%
11
14
Nivel Correlación
17
18
19
20
Media
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 ARTD46 (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
193
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 TStudent, 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:
Sistema
Media Expertos
Media
(̅)
0,8071
0,6546
Desviación
Estándar ( )
0,29042
0,28082
T-Student
Diferencias
Significativas
(t(46) = -1,850, p < 0.05)
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.
194
Recall:
El estudio de diferencias significativas en la métrica Recall mediante T-Student
ofrece los resultados expuestos en la Tabla 20:
Sistema
Media Expertos
Media
(̅)
0,9792
0,7038
Desviación
Estándar ( )
0,31920
0,07058
T-Student
Diferencias
Significativas
(t(46) = -4,127, p < 0.05)
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:
Sistema
Media Expertos
Media
(̅)
0,9521
0,9306
Desviación
Estándar ( )
0,06997
0,06833
T-Student
Diferencias
Significativas
(t(46) = -1,078, p < 0.05)
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:
Sistema
Media Expertos
Media
(̅)
0,9465
0,9716
Desviación
Estándar ( )
0,08515
0,03590
T-Student
Diferencias
Significativas
(t(46) = 1,331, p < 0.05)
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:
Sistema
Media Expertos
Media
(̅)
0,9359
0,6187
Desviación
Estándar ( )
0,36329
0,08975
T-Student
Diferencias
Significativas
(t(46) = -4,065, p < 0.05)
Tabla 23. Resultados del análisis estadístico de MCC
195
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.
196
Enfermedad
Pielonefritis
Métricas
Afectadas
S
Sinusitis
P, A, S, M
Faringitis
Brucelosis
Gastroenteritis
P, A, S, M
S
R
Fiebre Tifoidea
Bronquitis
S
P, A, S
Laringitis
P, A, S
Implicaciones/Consideraciones
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.
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.
Ver argumentación Faringitis.
Ver argumentación Pielonefritis.
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.
Ver argumentación Pielonefritis.
Ver argumentaciones de Precision, Accuracy y Specifity de casos
anteriores (Sinusitis por ejemplo).
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.
197
Caso Clínico / Experto
1
2
3
4
5
6
7
8
9
10
11
12
Media
EX-KS0L
2
3
6.5
4
4
6
3
4
2
7.5
5
4
EX-SK4V
4
15
15
5
5
15
5
5
5
5
15
10
EX-KV8H
5
10
10
5
6
5
5
10
5
17.5
5
10
EX-VH7Q
2
2
3
2
3
3
2
2
2
2
2
2
EX-HQ3T
2
4
4
2.5
2
1.5
2
2
1.5
1.5
0.5
2
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.
Tiempo (Minutos)
Media Expertos
10
9
8
7
6
5
4
3
2
1
0
Tiempo (Media)
EX-KS0L
EX-SK4V
EX-KV8H
EX-VH7Q
EX-HQ3T
3,7
8,67
6,91
2,25
2,57
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).
198
Sistema vs Expertos
17
Tiempo (Minutos)
15
13
11
9
7
5
3
1
1
2
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20
Experto 1
2
2 15 4 10 4
3
4
5
2
5
2
5
3
2
Experto 2
4
2 10 6,5 3
5 2,5 6
6
3
5
2 10 2
Experto 3
5
3
2 15 4
5
4
3 15 1,5 5
4
Sistema (MII)
0
0 0,1 0,1 0
0
0
0
0 0,1 0
0
0
0
5
2
2
5 7,5 2 15 0,5 10
2
5 1,5 5
5 1,5 18 5
0
0
0
4
2
2 10 2
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
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.
Consumo de memoria
Consumo Memoria (MB)
250
200
150
100
50
0
Sistema (MII)
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20
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
Figura 58. Gráfico de consumo de memoria del sistema por caso clínico
199
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).
8.3.2.1.
CONCLUSIONES
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
200
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
Representación gráfica del conocimiento
que muestra un conjunto de variables y sus
relaciones
probabilísticas
entre
enfermedades y síntomas (Nikovski, 2000).
Cálculo sencillo de la probabilidad de la
presencia de posibles enfermedades a
partir de los síntomas.
Conocimiento y conclusiones de expertos
se pueden representar en forma de
probabilidades.
Posibilidad de explicar el razonamiento.
Inconvenientes
Dificultad de obtener la probabilidad de
conocimiento para posibles diagnósticos.
No es práctico para sistemas complejos
muy grandes donde haya múltiples
síntomas.
Dificultad para representar la información
de forma óptima debido al gran número de
nodos que pueden existir.
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.
201
Redes de Neuronas Artificiales
Ventajas
Inconvenientes
Permite
al
sistema
aprender
de Se
requieren
probar
muchas
experiencias pasadas o ejemplos y configuraciones de redes para evaluar cuál
reconocer patrones en la información podría ser la óptima.
clínica.
Pueden procesar datos incompletos El proceso de entrenamiento podría llevar
tratando de hacer averiguaciones acerca de mucho tiempo y necesita alimentarse con
los datos que faltan y mejorar con cada gran cantidad de datos para empezar a
caso de uso debido a su aprendizaje.
generalizar correctamente.
No requieren grandes bases de datos para No es posible explicar el motivo por el cual
almacenar los datos de salida con sus han llegado a una determinada conclusión
probabilidades asociadas.
al tratarse de un sistema que su interior
actúa de caja negra.
En algunos casos este enfoque obtiene La selección de características (elemento
incluso mejores resultados que los propios relacionado
con
la
prueba
de
médicos (Tourassi et al., 1993; Tourassi et configuraciones) puede ser un elemento
al., 1995; Holst et al., 2000).
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 Falta de transparencia en el razonamiento
proceso iterativo para producir una envuelto, con lo que no es posible explicar
solución "óptima".
sus razonamientos de forma adecuada al
verse implicado un proceso aleatorio en la
generación de resultados.
En ciertos dominios como el de la El criterio de fitness que permita alcanzar
incontinencia urinaria se han obtenido la optimalidad puede ser muy difícil de
buenos resultados con este enfoque definir según el caso.
(Laurikkala & Juhola, 1998; Laurikkala et
al., 2009).
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 Tamaño de la base de conocimiento que
determinados casos.
almacene las reglas.
Es posible explicar el proceso de No es posible realizar razonamiento bajo
razonamiento.
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 Se necesita capturar el dominio del experto
el motor usado.
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
202
permite un entendimiento sencillo de las implica un error en el razonamiento.
mismas.
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 Incapacidad
de
realizar
cálculo
el uso de ontologías.
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
8.3.3.1.
CONCLUSIONES
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.
203
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,
204
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
205
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.
2.
3.
árbitros
4.
árbitros
Verificación de la hipótesis con los resultados del primer árbitro
Verificación de la hipótesis con los resultados del segundo árbitro
Verificación de la hipótesis con los resultados de la unión de
Verificación de la hipótesis con los resultados de la intersección de
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.
Eficiencia/Precisión Diagnóstica
Validación Eficiencia (Árbitros - Individual)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
MCC
Sistema [ARTD46]
93,88%
Expertos [ARTD46]
59,11%
Sistema [ARXF31]
94,29%
Expertos [ARXF31]
61,24%
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).
206
Eficiencia/Precisión Diagnóstica
Validación Eficiencia (Árbitros - Conjuntos)
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
MCC
Sistema [ARTD46 ∪ ARXF31]
94,60%
Expertos [ARTD46 ∪ ARXF31]
59,01%
Sistema [ARTD46 ∩ ARXF31]
93,59%
Expertos [ARTD46 ∩ ARXF31]
61,40%
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
(HIPÓTESIS H1.2)
LA
EFICIENCIA
COMPUTACIONAL
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
207
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.
208
Tiempo Medio Resolución Casos
6
Tiempo
5
4
3
2
1
0
Tiempo (minutos)
Expertos
5,016666667
Sistema (MII)
0,04057
Sistema (MINI)
0,08604
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.
209
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
210
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.
Fiebre Tifoidea
Laringitis
Bronquitis
Brucelosis
Total
Correctos
Incorrectos
2
4
3
1
Correctos
Parciales
5
0
1
1
Incorrectos
Parciales
0
0
0
0
2
1
2
5
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
211
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.
212
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
realizar un diagnóstico, tal y como se demostrará posteriormente en el proceso
verificación de esta hipótesis. Siendo así esta situación, es necesaria la generación
procesos, o algoritmos que permitan usar esta información (la presencia o ingesta
fármacos) para generar sistemas de diagnóstico más completos.
de
de
de
de
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,
213
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
¿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?
¿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?
¿Considera que el proceso mencionado podría ser útil (aunque deba ser ampliado y
mejorado) para ser usado en entornos médicos?
¿Considera que el proceso podría ser usado para generar, junto con más técnicas,
diagnósticos múltiples?
¿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?
ID
P1
P2
P3
P4
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
P1
P2
P3
P4
P5
Respuesta AR-TD46
S
N
S
S
S
Respuesta AR-XF31
S
S*
S
S
S
Tabla 33. Respuestas a preguntas para la verificación de H3
214
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
215
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.
216
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
217
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.
218
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 semiautomá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).
219
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.
220
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íguezGonzález et al., 2011a) systems suppose an improvement to the previous ones (ODDIN).
221
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
222
(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.
223
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.
224
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.
225
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, 412424.
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:
INTERNIST/CADUCEUS approach. Critical Reviews in Medical Informatics 1(1), 23-54.
the
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.
226
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.
227
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, 695700
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).
228
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-inteligenciaartificial.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.
229
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.
230
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, 567598.
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!.
231
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.
232
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), 471480.
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), 233242.
233
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, 3259.
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), 921932.
Hayes-Roth, F., Waterman, D. & Lenat, D. (1983). Building expert systems. AddisonWesley 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.
234
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 computerbased diagnostic knowledge base. Proc. of Fifth World Congress on Medical Informatics.
Hussain, S., Abidi, R. & Abidi, R. (2007). Semantic Web Framework for KnowledgeCentric 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/snomedct/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.
235
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.
236
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.
237
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.
238
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.
239
Mori, R., Consorti, F. & Galeazzi, E. (1998). Standards to support development of
terminological systems for healthcare telematics. Methods of information in medicine 37, 551563.
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.
240
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), 220.
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.
241
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: ContextDependent 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".
242
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., GomezBerbis, 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), 1620
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.
243
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 computerbased guideline implementation based on information management services. Journal Of the
American Medical Association 6(2), 99-103.
Shiffman, R., Liaw, Y., Brandt, C. & Corb, G. (1999b). Computer-based guideline
implementation systems: a systematic review of functionality and effectiveness. Journal Of the
American Medical Association 6(2), 104-114.
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.
244
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.
245
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.
246
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 multidisorder 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.
247
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), 293314.
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.
248
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
249
14.1. TABLAS DE VALORACIÓN MULTINIVEL
Caso
Respuesta
2
Fiebre Tifoidea
Meningitis
Pancreatitis
Orquitis
Pielonefritis
Neumonía
Inferencia
Caso
Respuesta
4
Inferencia
- Parcial
Caso
Respuesta
Caso
6
8
Inferencia
Respuesta
Inferencia
- Parcial
- Parcial
- Parcial
Caso
Respuesta
10
Inferencia
- Parcial
- Parcial
- Parcial
Tabla 35. Tabla de valoración de inferencia multinivel: Fiebre Tifoidea (I)
Caso
Respuesta
12
Fiebre Tifoidea
Meningitis
Pancreatitis
Orquitis
Pielonefritis
Neumonía
Inferencia
Caso
Respuesta
14
Inferencia
- Parcial
Caso
Respuesta
Caso
17
Inferencia
Respuesta
19
Inferencia
- Parcial
- Parcial
- Parcial
Caso
Respuesta
20
Inferencia
Tabla 36. Tabla de valoración de inferencia multinivel: Fiebre Tifoidea (II)
250
Caso
Respuesta
1
Laringitis
Caso
Caso
2
Inferencia
Faringitis
Respuesta
Caso
7
Inferencia
Respuesta
Caso
11
Inferencia
Respuesta
12
Inferencia
Respuesta
Inferencia
Tabla 37. Tabla de valoración de inferencia multinivel: Laringitis
Caso
Respuesta
1
Bronquitis
Sinusitis
Gripe
Resfriado común
Inferencia
Caso
Respuesta
2
Inferencia
Caso
Respuesta
6
Inferencia
Caso
Respuesta
8
Inferencia
Tabla 38. Tabla de valoración de inferencia multinivel: Bronquitis (I)
Caso
Respuesta
10
Bronquitis
Sinusitis
Gripe
Resfriado común
Inferencia
Caso
Respuesta
11
Inferencia
Caso
Respuesta
12
Inferencia
- Parcial
- Parcial
Caso
Respuesta
14
Inferencia
Tabla 39. Tabla de valoración de inferencia multinivel: Bronquitis (II)
251
Caso
Respuesta
2
Brucelosis
Caso
Caso
6
Inferencia
Respuesta
Caso
8
Inferencia
Neumonía
Pielonefritis
Respuesta
10
Inferencia
Respuesta
Inferencia
Tabla 40. Tabla de valoración de inferencia multinivel: Brucelosis (I)
Caso
Respuesta
12
Brucelosis
Neumonía
Pielonefritis
Inferencia
- Parcial
Caso
Respuesta
14
Inferencia
Tabla 41. Tabla de valoración de inferencia multinivel: Brucelosis (II)
252
Caso
Respuesta
19
Inferencia
14.2. TABLAS DE RESULTADOS DIAGNÓSTICOS
14.2.1. ARBITRAJE AR-XF31
EX-KS0L
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
33,33%
0,00%
100,00%
100,00%
83,33%
0,00%
100,00%
100,00%
0,00%
100,00%
80,00%
75,00%
Recall
100,00%
0,00%
100,00%
100,00%
71,43%
0,00%
33,33%
100,00%
0,00%
100,00%
100,00%
60,00%
Accuracy
83,33%
91,67%
100,00%
100,00%
75,00%
91,67%
83,33%
100,00%
91,67%
100,00%
91,67%
75,00%
EX-SK4V
Specifity
MCC
81,82%
76,11%
100,00%
0,00%
100,00% 100,00%
100,00%
NA
80,00%
75,35%
100,00%
0,00%
100,00% 76,11%
100,00%
NA
100,00%
0,00%
100,00% 100,00%
87,50%
91,83%
85,71%
73,90%
Precision
0,00%
0,00%
0,00%
0,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Recall
100,00%
0,00%
0,00%
0,00%
50,00%
100,00%
66,67%
100,00%
100,00%
100,00%
50,00%
75,00%
Accuracy
91,67%
91,67%
91,67%
91,67%
75,00%
100,00%
91,67%
100,00%
100,00%
100,00%
91,67%
91,67%
Specifity
MCC
91,67%
NA
100,00%
0,00%
100,00%
0,00%
100,00%
0,00%
100,00% 78,87%
100,00%
NA
100,00% 88,73%
100,00%
NA
100,00%
NA
100,00% 100,00%
100,00% 83,71%
100,00% 90,82%
Tabla 42. Resultados Arbitraje AR-XF31. Enfermedad 1-12. Expertos EX-KS0L y EX-SK4V
253
EX-KS0L
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
0,00%
100,00%
66,67%
100,00%
0,00%
100,00%
50,00%
100,00%
100,00%
100,00%
50,00%
100,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
40,00%
80,00%
100,00%
100,00%
Accuracy
83,33%
100,00%
91,67%
100,00%
75,00%
100,00%
83,33%
100,00%
75,00%
91,67%
91,67%
100,00%
EX-SK4V
Specifity
MCC
83,33%
NA
100,00%
NA
90,00%
88,73%
100,00% 100,00%
100,00%
0,00%
100,00%
NA
80,00%
81,62%
100,00%
NA
100,00% 76,46%
100,00% 91,83%
90,91%
83,71%
100,00% 100,00%
Precision
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
75,00%
0,00%
0,00%
100,00%
100,00%
0,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
66,67%
100,00%
0,00%
Tabla 43. Resultados Arbitraje AR-XF31. Enfermedad 13-24. Expertos EX-KS0L y EX-SK4V
254
Accuracy
100,00%
100,00%
100,00%
100,00%
83,33%
100,00%
91,67%
91,67%
75,00%
91,67%
100,00%
91,67%
Specifity
MCC
100,00% 100,00%
100,00%
NA
100,00% 100,00%
100,00%
NA
100,00%
0,00%
100,00% 100,00%
88,89%
90,82%
91,67%
NA
100,00%
0,00%
100,00% 88,73%
100,00%
NA
100,00%
0,00%
EX-KV8H
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
0,00%
0,00%
100,00%
0,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Recall
100,00%
0,00%
100,00%
0,00%
40,00%
100,00%
0,00%
100,00%
100,00%
100,00%
100,00%
75,00%
Accuracy
91,67%
91,67%
100,00%
91,67%
75,00%
100,00%
83,33%
100,00%
100,00%
100,00%
100,00%
91,67%
EX-VH7Q
Specifity
MCC
Precision Recall Accuracy Specifity
MCC
91,67%
NA
100,00% 100,00% 100,00% 100,00% 100,00%
100,00%
0,00%
0,00%
0,00%
83,33% 100,00% 0,00%
100,00%
NA
100,00% 100,00% 100,00% 100,00%
NA
100,00%
0,00%
100,00% 100,00% 100,00% 100,00% 100,00%
100,00% 76,46% 100,00% 50,00% 83,33% 100,00% 81,62%
100,00%
NA
0,00%
0,00%
91,67% 100,00% 0,00%
100,00%
0,00%
100,00% 33,33% 83,33% 100,00% 76,11%
100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%
100,00%
NA
0,00%
0,00%
91,67% 100,00% 0,00%
100,00% 100,00% 100,00% 100,00% 100,00% 100,00%
NA
100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%
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
255
EX-KV8H
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
75,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
0,00%
100,00%
0,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
66,67%
100,00%
0,00%
0,00%
100,00%
0,00%
Accuracy
91,67%
100,00%
100,00%
100,00%
83,33%
100,00%
91,67%
100,00%
83,33%
83,33%
100,00%
91,67%
EX-VH7Q
Specifity
MCC
Precision Recall Accuracy Specifity
MCC
88,89%
90,82% 100,00% 100,00% 100,00% 100,00% 100,00%
100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%
100,00% 100,00% 100,00% 100,00% 100,00% 100,00%
NA
100,00%
NA
0,00%
0,00%
91,67% 100,00% 0,00%
100,00%
0,00%
0,00%
0,00%
66,67% 100,00% 0,00%
100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%
100,00% 88,73% 100,00% 100,00% 100,00% 100,00% 100,00%
100,00%
NA
100,00% 100,00% 100,00% 100,00%
NA
100,00%
0,00%
0,00%
0,00%
58,33% 100,00% 0,00%
100,00%
0,00%
100,00% 100,00% 100,00% 100,00% 100,00%
100,00%
NA
0,00%
0,00%
91,67% 100,00% 0,00%
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
256
Sistema
EX-HQ3T
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
50,00%
0,00%
0,00%
100,00%
80,00%
0,00%
75,00%
100,00%
0,00%
100,00%
100,00%
60,00%
Recall
100,00%
0,00%
0,00%
100,00%
80,00%
0,00%
75,00%
100,00%
0,00%
100,00%
100,00%
75,00%
Accuracy
91,67%
91,67%
91,67%
100,00%
83,33%
91,67%
83,33%
100,00%
91,67%
100,00%
100,00%
75,00%
Specifity
MCC
Precision Recall Accuracy Specifity
90,91% 83,71% 33,33% 100,00% 90,00% 89,47%
100,00% 0,00% 100,00% 100,00% 100,00% 100,00%
100,00% 0,00% 100,00% 100,00% 100,00% 100,00%
100,00%
NA
100,00% 100,00% 100,00% 100,00%
85,71% 82,86% 100,00% 77,78% 90,00% 100,00%
100,00% 0,00% 100,00% 100,00% 100,00% 100,00%
87,50% 81,25% 100,00% 80,00% 95,00% 100,00%
100,00% 100,00% 100,00% 100,00% 100,00% 100,00%
100,00% 0,00% 100,00% 100,00% 100,00% 100,00%
100,00%
NA
100,00% 100,00% 100,00% 100,00%
100,00% 100,00% 100,00% 100,00% 100,00% 100,00%
75,00% 73,90% 100,00% 85,71% 95,00% 100,00%
MCC
77,31%
100,00%
100,00%
100,00%
90,56%
100,00%
93,30%
100,00%
100,00%
100,00%
100,00%
94,61%
Tabla 46. Resultados Arbitraje AR-XF31. Enfermedad 1-12. Expertos EX-HQ3T y Sistema
257
Sistema
EX-HQ3T
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
50,00%
100,00%
100,00%
50,00%
0,00%
100,00%
66,67%
100,00%
100,00%
75,00%
100,00%
100,00%
Recall
50,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
16,67%
100,00%
100,00%
100,00%
Accuracy
83,33%
100,00%
100,00%
91,67%
58,33%
100,00%
91,67%
100,00%
58,33%
91,67%
100,00%
100,00%
Specifity
MCC
Precision Recall Accuracy Specifity
MCC
90,00% 70,00% 100,00% 100,00% 100,00% 100,00% 100,00%
100,00% 100,00% 100,00% 100,00% 100,00% 100,00% 100,00%
100,00%
NA
66,67% 100,00% 95,00% 94,44% 89,67%
90,91% 83,71% 100,00% 100,00% 100,00% 100,00% 100,00%
87,50% 39,34% 71,43% 100,00% 90,00% 86,67% 89,34%
100,00%
NA
100,00% 100,00% 100,00% 100,00% 100,00%
90,00% 88,73% 100,00% 75,00% 95,00% 100,00% 92,01%
100,00%
NA
0,00% 100,00% 95,00% 95,00%
NA
100,00% 65,08% 70,00% 100,00% 85,00% 76,92% 86,69%
88,89% 90,82% 62,50% 100,00% 85,00% 80,00% 85,36%
100,00% 100,00% 20,00% 100,00% 80,00% 78,95% 69,87%
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
258
14.2.2. ARBITRAJE AR-TD46
EX-KS0L
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
EX-SK4V
Precision
Recall
Accuracy
Specifity
MCC
Precision
Recall
Accuracy
Specifity
MCC
33,33%
0,00%
100,00%
100,00%
66,67%
0,00%
100,00%
100,00%
0,00%
100,00%
60,00%
75,00%
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
33,33%
100,00%
0,00%
100,00%
100,00%
60,00%
83,33%
91,67%
100,00%
100,00%
83,33%
91,67%
83,33%
100,00%
91,67%
100,00%
83,33%
75,00%
81,82%
100,00%
100,00%
100,00%
75,00%
100,00%
100,00%
100,00%
100,00%
100,00%
77,78%
85,71%
76,11%
0,00%
100,00%
NA
85,36%
0,00%
76,11%
NA
0,00%
100,00%
84,16%
73,90%
0,00%
0,00%
0,00%
0,00%
66,67%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
0,00%
0,00%
0,00%
66,67%
100,00%
100,00%
100,00%
100,00%
100,00%
50,00%
75,00%
91,67%
91,67%
91,67%
91,67%
83,33%
100,00%
100,00%
100,00%
100,00%
100,00%
91,67%
91,67%
91,67%
100,00%
100,00%
100,00%
88,89%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
NA
0,00%
0,00%
0,00%
77,78%
NA
100,00%
NA
NA
100,00%
83,71%
90,82%
Tabla 48. Resultados Arbitraje AR-TD46. Enfermedad 1-12. Expertos EX-KS0L y EX-SK4V
259
EX-KS0L
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
50,00%
100,00%
100,00%
100,00%
0,00%
100,00%
75,00%
0,00%
100,00%
100,00%
50,00%
100,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
0,00%
40,00%
100,00%
100,00%
100,00%
Accuracy
91,67%
100,00%
100,00%
100,00%
66,67%
100,00%
91,67%
91,67%
75,00%
100,00%
91,67%
100,00%
EX-SK4V
Specifity
90,91%
100,00%
100,00%
100,00%
100,00%
100,00%
88,89%
100,00%
100,00%
100,00%
90,91%
100,00%
MCC
83,71%
NA
100,00%
100,00%
0,00%
NA
90,82%
0,00%
76,46%
100,00%
83,71%
100,00%
Precision
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
75,00%
100,00%
0,00%
50,00%
100,00%
0,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
75,00%
100,00%
0,00%
50,00%
100,00%
0,00%
Tabla 49. Resultados Arbitraje AR-TD46. Enfermedad 13-24. Expertos EX-KS0L y EX-SK4V
260
Accuracy
100,00%
100,00%
100,00%
100,00%
75,00%
100,00%
83,33%
100,00%
66,67%
83,33%
100,00%
91,67%
Specifity
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
87,50%
100,00%
100,00%
90,00%
100,00%
100,00%
MCC
100,00%
NA
100,00%
NA
0,00%
100,00%
81,25%
100,00%
0,00%
70,00%
NA
0,00%
EX-KV8H
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
0,00%
0,00%
100,00%
0,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Recall
100,00%
0,00%
100,00%
0,00%
66,67%
100,00%
0,00%
100,00%
100,00%
100,00%
100,00%
75,00%
Accuracy
91,67%
91,67%
100,00%
91,67%
91,67%
100,00%
91,67%
100,00%
100,00%
100,00%
100,00%
91,67%
EX-VH7Q
Specifity
MCC
91,67%
NA
100,00%
0,00%
100,00%
NA
100,00%
0,00%
100,00% 88,73%
100,00%
NA
100,00%
0,00%
100,00% 100,00%
100,00%
NA
100,00% 100,00%
100,00% 100,00%
100,00% 90,82%
Precision
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
0,00%
100,00%
50,00%
100,00%
Recall
100,00%
0,00%
100,00%
100,00%
50,00%
0,00%
50,00%
100,00%
0,00%
100,00%
100,00%
100,00%
Accuracy
100,00%
83,33%
100,00%
100,00%
83,33%
91,67%
91,67%
100,00%
91,67%
100,00%
91,67%
100,00%
Specifity
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
90,91%
100,00%
MCC
100,00%
0,00%
NA
100,00%
81,62%
0,00%
83,71%
100,00%
0,00%
NA
83,71%
100,00%
Tabla 50. Resultados Arbitraje AR-TD46. Enfermedad 1-12. Expertos EX-KV8H y EX-VH7Q
261
EX-KV8H
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
75,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
0,00%
100,00%
0,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
66,67%
100,00%
0,00%
0,00%
100,00%
0,00%
Accuracy
91,67%
100,00%
100,00%
100,00%
83,33%
100,00%
91,67%
100,00%
83,33%
91,67%
100,00%
91,67%
EX-VH7Q
Specifity
MCC
88,89%
90,82%
100,00% 100,00%
100,00% 100,00%
100,00%
NA
100,00%
0,00%
100,00% 100,00%
100,00% 88,73%
100,00%
NA
100,00%
0,00%
100,00%
0,00%
100,00%
NA
100,00%
0,00%
Precision
100,00%
100,00%
0,00%
0,00%
0,00%
100,00%
100,00%
100,00%
0,00%
100,00%
0,00%
100,00%
Recall
75,00%
100,00%
0,00%
0,00%
0,00%
100,00%
100,00%
100,00%
0,00%
100,00%
0,00%
100,00%
Tabla 51. Resultados Arbitraje AR-TD46. Enfermedad 13-24. Expertos EX-KV8H y EX-VH7Q
262
Accuracy
91,67%
100,00%
91,67%
91,67%
66,67%
100,00%
100,00%
100,00%
66,67%
100,00%
91,67%
100,00%
Specifity
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
MCC
90,82%
100,00%
0,00%
0,00%
0,00%
100,00%
100,00%
NA
0,00%
100,00%
0,00%
NA
Sistema
EX-HQ3T
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
50,00%
0,00%
0,00%
100,00%
80,00%
0,00%
75,00%
100,00%
0,00%
100,00%
50,00%
60,00%
Recall
100,00%
0,00%
0,00%
100,00%
100,00%
0,00%
75,00%
100,00%
0,00%
100,00%
100,00%
75,00%
Accuracy
91,67%
91,67%
91,67%
100,00%
91,67%
91,67%
83,33%
100,00%
91,67%
100,00%
91,67%
75,00%
Specifity
MCC
90,91%
83,71%
100,00%
0,00%
100,00%
0,00%
100,00%
NA
87,50%
91,83%
100,00%
0,00%
87,50%
81,25%
100,00% 100,00%
100,00%
0,00%
100,00%
NA
90,91%
83,71%
75,00%
73,90%
Precision
33,33%
100,00%
100,00%
100,00%
85,71%
100,00%
75,00%
100,00%
100,00%
100,00%
75,00%
100,00%
Recall
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
75,00%
100,00%
100,00%
100,00%
100,00%
85,71%
Accuracy
90,00%
100,00%
100,00%
100,00%
95,00%
100,00%
90,00%
100,00%
100,00%
100,00%
95,00%
95,00%
Specifity
89,47%
100,00%
100,00%
100,00%
92,86%
100,00%
93,75%
100,00%
100,00%
100,00%
94,12%
100,00%
MCC
77,31%
100,00%
100,00%
100,00%
94,61%
100,00%
84,38%
100,00%
100,00%
100,00%
92,01%
94,61%
Tabla 52. Resultados Arbitraje AR-TD46. Enfermedad 1-12. Expertos EX-HQ3T y Sistema
263
Sistema
EX-HQ3T
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
50,00%
100,00%
0,00%
50,00%
0,00%
100,00%
66,67%
0,00%
100,00%
75,00%
100,00%
100,00%
Recall
33,33%
100,00%
0,00%
100,00%
0,00%
100,00%
66,67%
0,00%
16,67%
100,00%
100,00%
100,00%
Accuracy
75,00%
100,00%
91,67%
91,67%
50,00%
100,00%
83,33%
91,67%
58,33%
91,67%
100,00%
100,00%
Specifity
MCC
88,89%
62,91%
100,00% 100,00%
100,00%
0,00%
90,91%
83,71%
85,71%
37,26%
100,00%
NA
88,89%
77,78%
100,00%
0,00%
100,00% 65,08%
88,89%
90,82%
100,00% 100,00%
100,00%
NA
Precision
100,00%
100,00%
100,00%
100,00%
85,71%
100,00%
100,00%
100,00%
70,00%
50,00%
20,00%
100,00%
Recall
75,00%
100,00%
100,00%
100,00%
100,00%
100,00%
60,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Tabla 53. Resultados Arbitraje AR-TD46. Enfermedad 13-24. Expertos EX-HQ3T y Sistema
264
Accuracy
95,00%
100,00%
100,00%
100,00%
95,00%
100,00%
90,00%
100,00%
85,00%
80,00%
80,00%
100,00%
Specifity
100,00%
100,00%
100,00%
100,00%
92,86%
100,00%
100,00%
100,00%
76,92%
75,00%
78,95%
100,00%
MCC
92,01%
100,00%
100,00%
100,00%
94,61%
100,00%
86,38%
100,00%
86,69%
80,62%
69,87%
100,00%
14.2.3. ARBITRAJE UNIÓN (AR-XF31 ⋃ AR-TD46)
EX-KS0L
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
33,33%
0,00%
100,00%
100,00%
83,33%
0,00%
100,00%
100,00%
0,00%
100,00%
80,00%
75,00%
Recall
100,00%
0,00%
100,00%
100,00%
71,43%
0,00%
33,33%
100,00%
0,00%
100,00%
100,00%
50,00%
Accuracy
83,33%
91,67%
100,00%
100,00%
75,00%
91,67%
83,33%
100,00%
91,67%
100,00%
91,67%
66,67%
EX-SK4V
Specifity
81,82%
100,00%
100,00%
100,00%
80,00%
100,00%
100,00%
100,00%
100,00%
100,00%
87,50%
83,33%
MCC
76,11%
0,00%
100,00%
NA
75,35%
0,00%
76,11%
NA
0,00%
100,00%
91,83%
67,68%
Precision
0,00%
0,00%
0,00%
0,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Recall
100,00%
0,00%
0,00%
0,00%
50,00%
100,00%
66,67%
100,00%
100,00%
100,00%
50,00%
60,00%
Accuracy
91,67%
91,67%
91,67%
91,67%
75,00%
100,00%
91,67%
100,00%
100,00%
100,00%
91,67%
83,33%
Specifity
MCC
91,67%
NA
100,00%
0,00%
100,00%
0,00%
100,00%
0,00%
100,00% 78,87%
100,00%
NA
100,00% 88,73%
100,00%
NA
100,00%
NA
100,00% 100,00%
100,00% 83,71%
100,00% 84,16%
Tabla 54. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 1-12. Exp EX-KS0L y EX-SK4V
265
EX-KS0L
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
50,00%
100,00%
100,00%
100,00%
0,00%
100,00%
75,00%
0,00%
100,00%
100,00%
50,00%
100,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
0,00%
33,33%
80,00%
100,00%
100,00%
Accuracy
91,67%
100,00%
100,00%
100,00%
66,67%
100,00%
91,67%
91,67%
66,67%
91,67%
91,67%
100,00%
EX-SK4V
Specifity
90,91%
100,00%
100,00%
100,00%
100,00%
100,00%
88,89%
100,00%
100,00%
100,00%
90,91%
100,00%
MCC
83,71%
NA
100,00%
100,00%
0,00%
NA
90,82%
0,00%
72,36%
91,83%
83,71%
100,00%
Precision
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
75,00%
100,00%
0,00%
100,00%
100,00%
0,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
75,00%
100,00%
0,00%
66,67%
100,00%
0,00%
Tabla 55. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 13-24. Exp EX-KS0L y EX-SK4V
266
Accuracy
100,00%
100,00%
100,00%
100,00%
75,00%
100,00%
83,33%
100,00%
66,67%
91,67%
100,00%
91,67%
Specifity
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
87,50%
100,00%
100,00%
100,00%
100,00%
100,00%
MCC
100,00%
NA
100,00%
NA
0,00%
100,00%
81,25%
100,00%
0,00%
88,73%
NA
0,00%
EX-KV8H
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
0,00%
0,00%
100,00%
0,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Recall
100,00%
0,00%
100,00%
0,00%
40,00%
100,00%
0,00%
100,00%
100,00%
100,00%
100,00%
75,00%
Accuracy
91,67%
91,67%
100,00%
91,67%
75,00%
100,00%
83,33%
100,00%
100,00%
100,00%
100,00%
91,67%
EX-VH7Q
Specifity
91,67%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
MCC
NA
0,00%
NA
0,00%
76,46%
NA
0,00%
100,00%
NA
100,00%
100,00%
90,82%
Precision
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
Recall
100,00%
0,00%
100,00%
100,00%
50,00%
0,00%
33,33%
100,00%
0,00%
100,00%
100,00%
100,00%
Accuracy
100,00%
83,33%
100,00%
100,00%
83,33%
91,67%
83,33%
100,00%
91,67%
100,00%
100,00%
100,00%
Specifity
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
MCC
100,00%
0,00%
NA
100,00%
81,62%
0,00%
76,11%
100,00%
0,00%
NA
100,00%
100,00%
Tabla 56. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 1-12. Exp EX-KV8H y EX-VH7Q
267
EX-KV8H
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
75,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
0,00%
100,00%
0,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
66,67%
100,00%
0,00%
0,00%
100,00%
0,00%
Accuracy
91,67%
100,00%
100,00%
100,00%
83,33%
100,00%
91,67%
100,00%
83,33%
83,33%
100,00%
91,67%
EX-VH7Q
Specifity
88,89%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
MCC
90,82%
100,00%
100,00%
NA
0,00%
100,00%
88,73%
NA
0,00%
0,00%
NA
0,00%
Precision
100,00%
100,00%
0,00%
0,00%
0,00%
100,00%
100,00%
100,00%
0,00%
100,00%
0,00%
100,00%
Recall
75,00%
100,00%
0,00%
0,00%
0,00%
100,00%
100,00%
100,00%
0,00%
100,00%
0,00%
100,00%
Tabla 57. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 13-24. Exp EX-KV8H y EX-VH7Q
268
Accuracy
91,67%
100,00%
91,67%
91,67%
66,67%
100,00%
100,00%
100,00%
58,33%
100,00%
91,67%
100,00%
Specifity
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
MCC
90,82%
100,00%
0,00%
0,00%
0,00%
100,00%
100,00%
NA
0,00%
100,00%
0,00%
NA
Sistema
EX-HQ3T
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
50,00%
0,00%
0,00%
100,00%
80,00%
0,00%
75,00%
100,00%
0,00%
100,00%
100,00%
80,00%
Recall
100,00%
0,00%
0,00%
100,00%
80,00%
0,00%
75,00%
100,00%
0,00%
100,00%
100,00%
80,00%
Accuracy
91,67%
91,67%
91,67%
100,00%
83,33%
91,67%
83,33%
100,00%
91,67%
100,00%
100,00%
83,33%
Specifity
90,91%
100,00%
100,00%
100,00%
85,71%
100,00%
87,50%
100,00%
100,00%
100,00%
100,00%
85,71%
MCC
83,71%
0,00%
0,00%
NA
82,86%
0,00%
81,25%
100,00%
0,00%
NA
100,00%
82,86%
Precision
33,33%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Recall
100,00%
100,00%
100,00%
100,00%
77,78%
100,00%
80,00%
100,00%
100,00%
100,00%
100,00%
75,00%
Accuracy
90,00%
100,00%
100,00%
100,00%
90,00%
100,00%
95,00%
100,00%
100,00%
100,00%
100,00%
90,00%
Specifity
89,47%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
MCC
77,31%
100,00%
100,00%
100,00%
90,56%
100,00%
93,30%
100,00%
100,00%
100,00%
100,00%
90,09%
Tabla 58. Resultados Arbitraje AR-XF31 ⋃ AR-TD46. Enf 1-12. Exp EX-HQ3T y Sistema
269
Sistema
EX-HQ3T
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
50,00%
100,00%
0,00%
50,00%
0,00%
100,00%
66,67%
0,00%
100,00%
75,00%
100,00%
100,00%
Recall
33,33%
100,00%
0,00%
100,00%
0,00%
100,00%
66,67%
0,00%
14,29%
100,00%
100,00%
100,00%
Accuracy
75,00%
100,00%
91,67%
91,67%
50,00%
100,00%
83,33%
91,67%
50,00%
91,67%
100,00%
100,00%
Specifity
88,89%
100,00%
100,00%
90,91%
85,71%
100,00%
88,89%
100,00%
100,00%
88,89%
100,00%
100,00%
MCC
62,91%
100,00%
0,00%
83,71%
37,26%
NA
77,78%
0,00%
62,74%
90,82%
100,00%
NA
Precision
100,00%
100,00%
100,00%
100,00%
85,71%
100,00%
100,00%
100,00%
80,00%
62,50%
20,00%
100,00%
Recall
75,00%
100,00%
100,00%
100,00%
100,00%
100,00%
60,00%
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
270
Accuracy
95,00%
100,00%
100,00%
100,00%
95,00%
100,00%
90,00%
100,00%
90,00%
85,00%
80,00%
100,00%
Specifity
100,00%
100,00%
100,00%
100,00%
92,86%
100,00%
100,00%
100,00%
83,33%
80,00%
78,95%
100,00%
MCC
92,01%
100,00%
100,00%
100,00%
94,61%
100,00%
86,38%
100,00%
90,82%
85,36%
69,87%
100,00%
14.2.4. ARBITRAJE INTERSECCI ÓN (AR-XF31 ⋂ AR-TD46)
EX-KS0L
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
33,33%
0,00%
100,00%
100,00%
66,67%
0,00%
100,00%
100,00%
0,00%
100,00%
60,00%
75,00%
Recall
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
33,33%
100,00%
0,00%
100,00%
100,00%
75,00%
Accuracy
83,33%
91,67%
100,00%
100,00%
83,33%
91,67%
83,33%
100,00%
91,67%
100,00%
83,33%
83,33%
EX-SK4V
Specifity
MCC
81,82%
76,11%
100,00%
0,00%
100,00% 100,00%
100,00%
NA
75,00%
85,36%
100,00%
0,00%
100,00% 76,11%
100,00%
NA
100,00%
0,00%
100,00% 100,00%
77,78%
84,16%
87,50%
81,25%
Precision
0,00%
0,00%
0,00%
0,00%
66,67%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Recall
100,00%
0,00%
0,00%
0,00%
66,67%
100,00%
100,00%
100,00%
100,00%
100,00%
50,00%
100,00%
Accuracy
91,67%
91,67%
91,67%
91,67%
83,33%
100,00%
100,00%
100,00%
100,00%
100,00%
91,67%
100,00%
Specifity
MCC
91,67%
NA
100,00%
0,00%
100,00%
0,00%
100,00%
0,00%
88,89%
77,78%
100,00%
NA
100,00% 100,00%
100,00%
NA
100,00%
NA
100,00% 100,00%
100,00% 83,71%
100,00% 100,00%
Tabla 60. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 1-12. Exp EX-KS0L y EX-SK4V
271
EX-KS0L
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
0,00%
100,00%
66,67%
100,00%
0,00%
100,00%
50,00%
100,00%
100,00%
100,00%
50,00%
100,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
50,00%
100,00%
100,00%
100,00%
Accuracy
83,33%
100,00%
91,67%
100,00%
75,00%
100,00%
83,33%
100,00%
83,33%
100,00%
91,67%
100,00%
EX-SK4V
Specifity
MCC
83,33%
NA
100,00%
NA
90,00%
88,73%
100,00% 100,00%
100,00%
0,00%
100,00%
NA
80,00%
81,62%
100,00%
NA
100,00% 81,62%
100,00% 100,00%
90,91%
83,71%
100,00% 100,00%
Precision
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
75,00%
0,00%
0,00%
50,00%
100,00%
0,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
50,00%
100,00%
0,00%
Tabla 61. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 13-24. Exp EX-KS0L y EX-SK4V
272
Accuracy
100,00%
100,00%
100,00%
100,00%
83,33%
100,00%
91,67%
91,67%
75,00%
83,33%
100,00%
91,67%
Specifity
MCC
100,00% 100,00%
100,00%
NA
100,00% 100,00%
100,00%
NA
100,00%
0,00%
100,00% 100,00%
88,89%
90,82%
91,67%
NA
100,00%
0,00%
90,00%
70,00%
100,00%
NA
100,00%
0,00%
EX-KV8H
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
0,00%
0,00%
100,00%
0,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Recall
100,00%
0,00%
100,00%
0,00%
66,67%
100,00%
0,00%
100,00%
100,00%
100,00%
100,00%
75,00%
Accuracy
91,67%
91,67%
100,00%
91,67%
91,67%
100,00%
91,67%
100,00%
100,00%
100,00%
100,00%
91,67%
EX-VH7Q
Specifity
MCC
91,67%
NA
100,00%
0,00%
100,00%
NA
100,00%
0,00%
100,00% 88,73%
100,00%
NA
100,00%
0,00%
100,00% 100,00%
100,00%
NA
100,00% 100,00%
100,00% 100,00%
100,00% 90,82%
Precision
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
0,00%
100,00%
50,00%
100,00%
Recall
100,00%
0,00%
100,00%
100,00%
50,00%
0,00%
50,00%
100,00%
0,00%
100,00%
100,00%
100,00%
Accuracy
100,00%
83,33%
100,00%
100,00%
83,33%
91,67%
91,67%
100,00%
91,67%
100,00%
91,67%
100,00%
Specifity
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
90,91%
100,00%
MCC
100,00%
0,00%
NA
100,00%
81,62%
0,00%
83,71%
100,00%
0,00%
NA
83,71%
100,00%
Tabla 62. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 1-12. Exp EX-KV8H y EX-VH7Q
273
EX-KV8H
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
75,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
0,00%
0,00%
100,00%
0,00%
Recall
100,00%
100,00%
100,00%
100,00%
0,00%
100,00%
66,67%
100,00%
0,00%
0,00%
100,00%
0,00%
Accuracy
91,67%
100,00%
100,00%
100,00%
83,33%
100,00%
91,67%
100,00%
83,33%
91,67%
100,00%
91,67%
EX-VH7Q
Specifity
MCC
88,89%
90,82%
100,00% 100,00%
100,00% 100,00%
100,00%
NA
100,00%
0,00%
100,00% 100,00%
100,00% 88,73%
100,00%
NA
100,00%
0,00%
100,00%
0,00%
100,00%
NA
100,00%
0,00%
Precision
100,00%
100,00%
100,00%
0,00%
0,00%
100,00%
100,00%
100,00%
0,00%
100,00%
0,00%
100,00%
Recall
100,00%
100,00%
100,00%
0,00%
0,00%
100,00%
100,00%
100,00%
0,00%
100,00%
0,00%
100,00%
Tabla 63. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 13-24. Exp EX-KV8H y EX-VH7Q
274
Accuracy
100,00%
100,00%
100,00%
91,67%
66,67%
100,00%
100,00%
100,00%
66,67%
100,00%
91,67%
100,00%
Specifity
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
MCC
100,00%
100,00%
NA
0,00%
0,00%
100,00%
100,00%
NA
0,00%
100,00%
0,00%
NA
Sistema
EX-HQ3T
Faringitis
Sarcoidosis
Pericarditis
Enfermedad De Addison
Neumonía
Difteria
Pielonefritis
Diabetes Tipo 2
Aspergiloma Pulmonar
Asma
Resfriado Común
Gripe
Precision
50,00%
0,00%
0,00%
100,00%
80,00%
0,00%
75,00%
100,00%
0,00%
100,00%
50,00%
40,00%
Recall
100,00%
0,00%
0,00%
100,00%
100,00%
0,00%
75,00%
100,00%
0,00%
100,00%
100,00%
66,67%
Accuracy
91,67%
91,67%
91,67%
100,00%
91,67%
91,67%
83,33%
100,00%
91,67%
100,00%
91,67%
66,67%
Specifity
MCC
90,91%
83,71%
100,00%
0,00%
100,00%
0,00%
100,00%
NA
87,50%
91,83%
100,00%
0,00%
87,50%
81,25%
100,00% 100,00%
100,00%
0,00%
100,00%
NA
90,91%
83,71%
66,67%
64,64%
Precision
33,33%
100,00%
100,00%
100,00%
85,71%
100,00%
75,00%
100,00%
100,00%
100,00%
75,00%
100,00%
Recall
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
75,00%
100,00%
100,00%
100,00%
100,00%
100,00%
Accuracy
90,00%
100,00%
100,00%
100,00%
95,00%
100,00%
90,00%
100,00%
100,00%
100,00%
95,00%
100,00%
Specifity
89,47%
100,00%
100,00%
100,00%
92,86%
100,00%
93,75%
100,00%
100,00%
100,00%
94,12%
100,00%
MCC
77,31%
100,00%
100,00%
100,00%
94,61%
100,00%
84,38%
100,00%
100,00%
100,00%
92,01%
100,00%
Tabla 64. Resultados Arbitraje AR-XF31 ⋂ AR-TD46. Enf 1-12. Exp EX-HQ3T y Sistema
275
Sistema
EX-HQ3T
Meningitis
Fiebre Reumática
Sinusitis
Orquitis
Brucelosis
Parkinson
Gastroenteritis
Pancreatitis
Fiebre Tifoidea
Bronquitis
Laringitis
Colera
Precision
50,00%
100,00%
100,00%
50,00%
0,00%
100,00%
66,67%
100,00%
100,00%
75,00%
100,00%
100,00%
Recall
50,00%
100,00%
100,00%
100,00%
0,00%
100,00%
100,00%
100,00%
20,00%
100,00%
100,00%
100,00%
Accuracy
83,33%
100,00%
100,00%
91,67%
58,33%
100,00%
91,67%
100,00%
66,67%
91,67%
100,00%
100,00%
Specifity
MCC
90,00%
70,00%
100,00% 100,00%
100,00%
NA
90,91%
83,71%
87,50%
39,34%
100,00%
NA
90,00%
88,73%
100,00%
NA
100,00% 67,84%
88,89%
90,82%
100,00% 100,00%
100,00%
NA
Precision
100,00%
100,00%
66,67%
100,00%
71,43%
100,00%
100,00%
0,00%
60,00%
50,00%
20,00%
100,00%
Recall
100,00%
100,00%
100,00%
100,00%
100,00%
100,00%
75,00%
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
276
Accuracy
100,00%
100,00%
95,00%
100,00%
90,00%
100,00%
95,00%
95,00%
80,00%
80,00%
80,00%
100,00%
Specifity
100,00%
100,00%
94,44%
100,00%
86,67%
100,00%
100,00%
95,00%
71,43%
75,00%
78,95%
100,00%
MCC
100,00%
100,00%
89,67%
100,00%
89,34%
100,00%
92,01%
NA
82,73%
80,62%
69,87%
100,00%
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
11
12
13
14
15
16
17
18
19
20
1
2217
2579
5030
3767
2135
1822
2348
1664
2429
1835
2628
2097
3042
2145
2173
2287
2258
2378
1982
2017
2
2107
2141
3644
3536
2575
1509
2189
2399
2594
1975
2371
1839
3567
2400
1784
2823
2156
2442
2139
2670
3
1877
1993
4203
4083
1935
1801
2859
1983
2493
2618
2196
1918
2987
1951
2327
2833
1812
1794
1899
2302
4
2550
2498
4616
2937
2663
1716
2430
2024
2506
2008
2084
1920
3232
1964
2470
2690
2145
2307
2553
2697
5
1906
2580
5392
4170
2428
1608
2310
1948
2501
1860
2119
2042
3554
2219
1852
2985
2026
2356
2449
2140
6
1893
2098
5392
3273
2011
1599
2419
2123
2355
2492
2526
1738
2764
1803
2029
3008
1873
2399
1818
2208
7
2127
1909
3856
3256
2531
1636
2700
1957
1990
2130
1889
1682
3674
2224
1752
2569
1715
1907
2600
1856
8
1934
2334
3635
3672
2176
1600
2590
1921
2663
2499
2178
1914
3585
2042
2290
3081
2339
1845
2522
1844
9
2522
2548
3974
3585
2594
1412
1981
2155
2630
2567
2414
2325
3733
1981
1863
2652
2356
1910
1994
2395
10
1810
1824
5168
3147
2694
1656
2628
2163
1967
2350
2638
1690
3680
2505
2023
2227
1833
1969
2103
2605
Media (ms)
2094,3 ± 265,96
2250,4 ± 293,12
4491 ± 714,27
3542,6 ± 398,98
2374,2 ± 283,45
1635,9 ± 124
2445,4 ± 258,26
2033,7 ± 193,83
2412,8 ± 246,44
2233,4 ± 304,89
2304,3 ± 250,51
1916,5 ± 199,83
3381,8 ± 346,14
2123,4 ± 217,7
2056,3 ± 249,52
2715,5 ± 291,65
2051,3 ± 232,98
2130,7 ± 264,95
2205,9 ± 296,19
2273,4 ± 317,75
Media (m)
0,0349
0,0375
0,0749
0,059
0,0396
0,0273
0,0408
0,0339
0,0402
0,0372
0,0384
0,0319
0,0564
0,0354
0,0343
0,0453
0,0342
0,0355
0,0368
0,0379
Tabla 66. Tabla de tiempos (en ms, excepto Media (m)) con motor de Inf inicializado
277
14.3.2. MOTOR DE INFERENCIA NO INICIALIZADO
Caso/Ejecución
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1
4466
4286
4994
7720
6214
3752
7407
4840
4688
6085
5460
3845
6197
5438
4245
5960
4808
5532
5148
5448
2
6060
4953
5000
7832
5239
5066
5778
4434
5044
5466
4356
5275
4808
4593
4670
5111
3412
5923
3854
3900
3
5447
4276
5954
6628
7231
3774
5632
4456
4675
5840
4988
4531
5713
4573
5366
5881
3962
5086
5255
4335
4
6401
5370
5541
5876
6166
5101
6132
4073
5290
5038
3817
3717
5453
4552
4343
5600
4287
5314
4298
5123
5
4561
5831
5172
5500
5557
4615
5486
5331
5287
5045
4207
3760
5121
4968
4370
6128
4468
5056
4728
5797
6
4945
4860
6236
7214
6733
4800
6462
4079
5581
5465
4214
5267
5318
4379
3927
4999
4032
4684
3826
5771
7
6068
5231
6664
6157
5465
4862
7468
4217
5371
6851
5198
5182
5941
4821
4391
6351
4453
4113
4494
5771
8
4890
4234
6226
6706
6499
4376
6110
4675
5779
6566
3981
3853
5005
4502
3883
5047
3960
4467
5309
5564
9
5574
5492
5943
5511
6623
4781
6193
5287
4330
6145
4482
3629
6144
4247
3725
5243
4645
4624
4871
3978
10
6603
5421
6631
5889
5354
4430
6410
5133
4300
5529
4506
4496
5985
4128
3800
6225
4424
4699
4553
5681
Media (ms)
5501,5 ± 767,67
4995,4 ± 571,79
5836,1 ± 631,65
6503,3 ± 862,14
6108,1 ± 677,02
4555,7 ± 479,65
6307,8 ± 673,67
4652,5 ± 479,61
5034,5 ± 514,29
5803 ± 609,28
4520,9 ± 534,08
4355,5 ± 684,2
5568,5 ± 497,95
4620,1 ± 378,8
4272 ± 491,83
5654,5 ± 521,31
4245,1 ± 408,84
4949,8 ± 539,71
4633,6 ± 534,46
5136,8 ± 769,66
Tabla 67. Tabla de tiempos (en ms, excepto Media (m)) con motor de Inf no inicializado
278
Media (m)
0,0917
0,0833
0,0973
0,1084
0,1018
0,0759
0,1051
0,0775
0,0839
0,0967
0,0753
0,0726
0,0928
0,077
0,0712
0,0942
0,0708
0,0825
0,0772
0,0856
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
11
12
13
14
15
16
17
18
19
20
1
155608524
38971379
59508798
229068203
218596808
134925215
164461640
138259193
145558289
133031575
141516387
98833212
185652939
172286839
151618639
164311990
136928769
140993678
127251538
111814243
2
157577836
35101452
56077602
204525134
209516761
150434837
178415780
143683819
157000627
142047416
150866758
100292560
201156393
176430003
143973675
171061780
164491175
142721284
126174828
120921334
3
188026999
40851932
64840992
211793352
199442163
148453655
156029756
138939943
139370259
149845974
144876437
99284796
207647851
183677492
141845811
189061926
138656637
150141588
126146073
112999288
4
172364012
34572558
54335933
197936334
192846942
149805284
176528521
151492529
140928879
153459539
138660985
98005404
189149077
163471002
152855036
179188844
140332473
146805189
143895891
119977536
5
168437108
35385893
64814624
226968093
195434267
139937649
167158543
136501333
148113632
128751239
135187562
92037359
192218667
153240496
130252633
189557729
156092257
128515228
139009703
122638540
6
167736226
36394775
55009708
201985523
221871101
158951702
167563568
127821795
138487325
139618558
146832965
102310996
200299429
182827580
129607037
189337121
139016238
127209642
126468432
127634298
7
183002086
38500041
54722838
221948162
203412893
131232313
155502308
151783554
136613192
132350834
140181381
94892218
197381924
160834603
133400614
166956542
144352526
137429873
143109078
128971206
8
162918738
35731044
60810766
229206751
224787533
130716564
168574405
151165810
138163233
152727112
147089888
105001271
209757029
157142534
139553977
173101433
159394569
150962588
123003820
119517128
9
174663610
36127432
54254960
217796108
208642999
156916052
151062858
135102432
143762433
140449801
135555603
94629983
180504192
153992578
147639592
181274275
136468586
150452441
134865339
121020728
10
Media (MB)
166866130
161,86
36032308
35,06
60626185
55,79
218324408
205,95
190396218
196,93
133654450
136,85
157737211
156,69
147303649
135,62
145444732
136,7
149032649
135,55
148221074
136,28
106235598
94,56
182005127
185,56
186164740
161,18
138419543
134,39
184558178
170,56
148165348
139,61
141936862
135,15
142186791
127,04
132866281
116,19
Tabla 68. Tabla consumo de memoria (en bytes, excepto Media) con motor de Inf inicializado
279
14.4.2. MOTOR DE INFERENCIA NO INICIALIZADO
Caso/Ejecución
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1
147161414
101046975
148689532
135141663
56819478
71895766
45674426
138255782
147991599
46944614
144426530
94540630
42825693
115714184
94588437
60955384
103995143
119264621
139843412
112797274
2
131656212
97035130
169406362
129173121
55871388
79090962
52794492
141128654
147911217
44790494
125235978
88372030
38276478
110325958
95157246
60915953
99015595
102823782
135466568
124434564
3
126641042
97730965
154632905
147051926
61434431
82791594
50710377
150917785
145459678
47689356
142166895
84888625
38559674
105612288
103398526
53797827
110292847
112755830
130895387
113006992
4
144355242
100035906
152548579
141309209
61954733
77842922
52072120
142119605
132108853
47901824
127039522
88340584
41842155
105147731
112039345
58155774
98033599
114390903
143115445
117082526
5
125301094
95251464
175342469
132518581
53924193
80078356
48548804
141070387
138767705
46428319
130275461
95991702
42285824
108944654
94929250
54101216
106247394
116959392
141144611
123403176
6
123236349
93525052
172096685
143990182
61203631
80341016
50388187
128754681
139812883
45176477
136072821
88712296
36155946
125090294
110070697
57971160
108993647
122750011
134634469
109793631
7
143444988
91585795
169939070
148806128
61251567
69707594
54323557
137279316
149415092
46227015
132756388
89651872
42120247
115783951
98328783
56916901
110935415
104513297
138756377
107239812
8
141867058
86006087
147131987
138857672
62163323
82055675
51444137
128593930
138161456
47855502
130413108
86717579
42570160
122230693
93336920
56384243
102081074
118234029
138069219
117701012
Tabla 69. Tabla consumo de memoria (en bytes, excepto Media) con motor de Inf no inicializado
280
9
144138982
85590903
164836622
132124173
55088366
71510652
47637524
128898737
134873561
46281027
126112933
99058854
36060638
119110751
110428977
61870446
101490472
106898125
138825698
106344144
10
Media (MB)
143007198
133,87
93535292
91,93
172281137
158,88
138865699
135,53
54632860
57,06
78598062
75,58
49310882
49,11
130282478
133,53
151743022
139,28
45368862
45,38
147291985
131,03
88336392
88,34
36523533
38,79
115237798
111,64
107485235
99,59
56559020
56,41
91047118
100,79
114452516
110,65
123096749
133,19
120860340
112,56
14.5. PUBLICACIONES
14.5.1. PUBLICACIONES EN CONGRESOS
Rodríguez-González, A., Jimenez-Domingo, E., García-Crespo, A., AlorHernandez, 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
Intelligence,
2009.
Conference
ICCCI
on
09.
Computational
Vol.
244/2009,
Collective
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
281
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 REV ISTAS 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 REV ISTAS INDEXADAS EN JCR
García-Crespo, A., Rodríguez, A., Mencke, M., Gómez-Berbís, J.M., & ColomoPalacios, 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., GomezBerbis, 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)
282
283
