Tesis Doctoral - Universidad Europea
Anuncio
TESIS DOCTORAL
SERIE INGENIERÍA
Sistema Inteligente para la
Extracción de Conceptos e
Integración de Información
aplicadas al Aprendizaje en
Biomedicina
Programa de Doctorado en Ingeniería Multidisciplinar
Escuela Politécnica
Fernando Aparicio Galisteo
Dirigido por:
Dr. Manuel de Buenaga Rodríguez
Madrid, 2012
INFORME Y AUTORIZACIÓN DEL DIRECTOR PARA PRESENTAR LA
TESIS DOCTORAL
El gran desarrollo de las técnicas y algoritmos aplicados en áreas de
conocimiento como la linguística computacional, la minería de texto o el
procesamiento del lenguaje natural, ha permitido en los últimos años la
implementación de sistemas avanzados para la extracción de información y
la manipulación de los datos lingüísticos. Estos avances pueden servir para
cubrir necesidades en otras áreas de conocimiento, tal y como demuestra el
modelo arquitectónico presentado en esta tesis, aplicado al dominio
particular biomédico en el contexto educativo del EEES.
En el presente trabajo se afrontan problemáticas técnicas de interés
reciente, como la extracción multilingüe de conceptos a partir de textos
escritos en lenguaje natural, la recuperación de información cross-lingüe y la
capacidad de dar respuesta en línea a los usuarios. Además, la evaluación es
realizada en base a la utilidad del sistema para dar soporte a una tarea
llevada a cabo en el aula con estudiantes, lo que constituye un marco
innovador con un elevado potencial para la evaluación de otros sistemas
inteligentes con gran variedad de perfiles de usuario.
La investigación propuesta se ha desarrollado en el marco de las líneas de
investigación del Grupo de Investigación en Sistemas Inteligentes de la UEM,
y especialmente de forma relacionada con el proyecto Medical-Miner:
Integración de conocimiento textual explícito en técnicas de minería de
datos para la creación de herramientas traslacionales en medicina, TIN2009-14057-C03(-01,02,03). Las aportaciones de esta tesis han sido objeto
de presentaciones en revistas y congresos científicos, entre los que destaca
la publicación “An Intelligent Information Access system assisting a Case
Based Learning methodology evaluated in higher education with medical
students” en Computers and Education, de Elsevier (Factor de Impacto:
2.617; Q1 14/97 en Computer Science, Interdisciplinary Applications).
El Profesor de la Universidad Europea de Madrid, Dr. D. MANUEL DE
BUENAGA RODRÍGUEZ. Director de la Tesis Doctoral SISTEMA INTELIGENTE
PARA LA EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
APLICADAS AL APRENDIZAJE EN BIOMEDICINA, de la que es autor D.
FERNANDO APARICIO GALISTEO, AUTORIZA la presentación de la referida
Tesis para su defensa y mantenimiento, en cumplimiento del artículo 21 del
Real Decreto 1393/2007, de 29 de Octubre, por el que se establece la
ordenación de las enseñanzas universitarias oficiales y de acuerdo a las
normas reguladoras de estudios de postgrado de la Universidad Europea de
Madrid.
28 DE MAYO DE 2012
AGRADECIMIENTOS
A mi familia, que mucho ha tenido que ver en todos mis enfoques vitales y
modos de afrontar los diferentes retos que me he ido encontrando, con
especial mención al apoyo constante de mis padres. A Macu, cuya
generosidad y compañerismo me ha permitido tener en el momento
adecuado el material que necesitaba para la fabricación y entrega del
documento definitivo. A Diego, por su amistad y por estar siempre
pendiente de las cosas verdaderamente importantes. A Manolo, ya que
gracias a su apoyo, carácter bondadoso, calmado y tranquilizador ha sido
posible llevar a buen puerto este proyecto.
Esta investigación tampoco podría haber sido desarrollada sin el aporte
fundamental de las profesoras de Ciencias Biomédicas Margarita y Asunción,
cuyo papel ha sido trascendental durante todo el desarrollo y sobremanera
en la fase experimental.
Ya por último, dar las gracias a todos los compañeros del Grupo de Sistemas
Inteligentes así como al resto del Departamento de Informática, Automática
y Comunicaciones de la Escuela Politécnica de la UEM, que forman un grupo
de personas con un ambiente de trabajo excelente y altamente motivador.
ÍNDICE
RESUMEN / ABSTRACT ............................................................................................1
CAPÍTULO 1. INTRODUCCIÓN. .................................................................................7
1.
INVESTIGACIÓN TRASLACIONAL Y MEDICINA TRASLACIONAL ........................................ 10
Bioinformática traslacional............................................................................... 11
Relación con la Web semántica ........................................................................ 12
2.
FUENTES DE INFORMACIÓN BIOMÉDICA ................................................................. 13
Problemas generales de los usuarios ................................................................ 14
Bases de conocimiento disponibles ................................................................... 15
3.
DESARROLLO DE ACTIVIDADES DE APRENDIZAJE ACTIVO ............................................. 17
Contexto............................................................................................................ 18
Aprendizaje activo y percepción de los alumnos .............................................. 19
Sistemas inteligentes en educación .................................................................. 21
4.
ESTRUCTURA DE LA TESIS .................................................................................... 23
CAPÍTULO 2. MODELO DE SISTEMA INTELIGENTE.................................................. 27
1.
DESCRIPCIÓN DEL PROBLEMA ............................................................................... 27
Anotación basada en conceptos ....................................................................... 27
Sistemas para el acceso inteligente a la información ....................................... 29
Ontologías......................................................................................................... 29
2.
SITUACIÓN ACTUAL ............................................................................................ 31
Sistemas para el reconocimiento de conceptos ................................................ 31
Acceso a recursos ontológicos a través de servicios ......................................... 34
Reconocimiento cross lingüe de términos y conceptos ..................................... 40
3.
VISIÓN GENERAL DEL MODELO DE SISTEMA PROPUESTO............................................. 43
Motivación ........................................................................................................ 43
Objetivos............................................................................................................46
Arquitectura del modelo ....................................................................................50
Elementos de los módulos .................................................................................54
CAPÍTULO 3. EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA. ......................................................................................................... 57
1.
RECONOCIMIENTO DE ENTIDADES MÉDICAS .............................................................57
Anotación con GATE ..........................................................................................58
Extracción de la terminología bilingüe desde Freebase ....................................59
Extracción de la terminología bilingüe de MelinePlus .......................................65
Extracción de la terminología bilingüe de SNOMED CT .....................................67
Anotación con ontologías biomédicas remotas ................................................69
2.
INFORMACIÓN ENRIQUECIDA DE LOS CONCEPTOS......................................................72
Información enriquecida desde Freebase ..........................................................73
Información enriquecida bilingüe desde MedlinePlus .......................................74
Acceso a información bibliográfica de MEDLINE/PubMed ................................78
3.
ELEMENTOS DEL INTERFAZ Y MÉTODOS DE ACCESO AL SISTEMA....................................83
Aplicación de acceso Web .................................................................................84
Servicio de acceso en formato XML ...................................................................94
CAPÍTULO 4. DESARROLLO DEL SISTEMA BIOMÉDICO. ......................................... 99
1.
PREPROCESADO Y RECUPERACIÓN DE INFORMACIÓN .................................................99
Freebase ............................................................................................................99
MedlinePlus .....................................................................................................104
SNOMED CT .....................................................................................................106
2.
ANOTACIÓN E INTEGRACIÓN DE FUENTES ..............................................................110
Integración con GATE ......................................................................................110
Integración de los servicios de anotación remota ...........................................117
Integración de las anotaciones locales y remotas ...........................................121
3.
BÚSQUEDA DE INFORMACIÓN .............................................................................131
Búsquedas en Freebase .................................................................................. 132
Búsquedas en MedlinePlus ............................................................................. 136
Búsquedas en MEDLINE/PubMed ................................................................... 140
4.
MECANISMOS DE ACCESO AL SISTEMA ................................................................. 142
Acceso a través del navegador ....................................................................... 143
Acceso a través del servicio Web .................................................................... 149
CAPÍTULO 5. EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA................................. 151
1.
CASOS DE PRUEBA ANALIZADOS .......................................................................... 152
2.
TEXTOS DE ENTRADA ........................................................................................ 154
3.
MONTAJE EXPERIMENTAL.................................................................................. 156
4.
RESULTADOS .................................................................................................. 158
CAPÍTULO 6. ESCENARIOS DE APLICACIÓN. ......................................................... 167
1.
METODOLOGÍA DE APRENDIZAJE......................................................................... 167
Casos clínicos analizados ................................................................................ 169
Fuentes de conocimiento seleccionadas y sistema inteligente ....................... 170
Cuestionario para la evaluación objetiva de la actividad ............................... 173
Diseño de la actividad en el aula .................................................................... 173
2.
METODOLOGÍA DE EVALUACIÓN ......................................................................... 173
3.
DESCRIPCIÓN DEL EXPERIMENTO......................................................................... 175
4.
RESULTADOS Y DISCUSIÓN ................................................................................. 176
Resultados de la prueba objetiva de conocimientos ....................................... 176
Resultados de las encuestas de percepción .................................................... 178
CAPÍTULO 7. CONCLUSIONES. ............................................................................. 185
1.
MODELO Y HERRAMIENTA BIOINFORMÁTICA CROSS-LINGÜE ..................................... 185
2.
ESCALABILIDAD ............................................................................................... 186
3.
EVALUACIÓN CON USUARIOS.............................................................................. 187
4.
RESUMEN DE CONTRIBUCIONES DEL SISTEMA BIOMÉDICO ........................................ 188
CAPÍTULO 8. TRABAJO FUTURO. ........................................................................ 191
BIBLIOGRAFÍA .................................................................................................... 195
APÉNDICE 1 RESULTADOS DEL SERVICIO WEB UTILIZANDO DIFERENTES FUENTES.
........................................................................................................................... 213
APÉNDICE 2 PRUEBAS DE EFICIENCIA. ................................................................ 223
APÉNDICE 3 EXAMEN DE TIPO TEST.................................................................... 232
APÉNDICE 4 RESULTADOS DE LA EVALUACIÓN CON ALUMNOS.......................... 234
ÍNDICE DE FIGURAS ............................................................................................ 237
ÍNDICE DE TABLAS .............................................................................................. 241
RESUMEN / ABSTRACT
RESUMEN
En esta tesis se propone el desarrollo, la utilización y la evaluación de un
modelo de sistema de acceso inteligente a información biomédica
empleando actividades de aprendizaje con estudiantes de educación
superior en el área de conocimiento de las ciencias biomédicas.
El modelo de sistema en cuestión tendrá la capacidad de extraer términos y
conceptos de un texto introducido en el sistema, a través de técnicas de PLN
(Procesamiento de Lenguaje Natural), y mostrar información integrada
desde diferentes fuentes para estas entidades extraídas. El texto introducido
en el sistema podrá estar escrito en inglés o en español, devolviéndose
como resultado el conjunto de términos y conceptos biomédicos
detectados, en ambos idiomas, y un conjunto de fuentes de información que
pueden estar tanto en un idioma como en otro independientemente del
idioma en el que la entidad fue reconocida a partir del texto original.
Este tipo de sistemas pueden formar parte de otros sistemas de extracción
de información, resolviendo una determinada tarea en el proceso global, o
bien ser directamente utilizados por usuarios humanos para resolver alguna
tarea. Dado que la evaluación tradicional basada en mediciones de
precisión, cobertura y medida-F, habitualmente efectuada sobre este tipo
de sistemas para evaluar su eficacia como componente de otro sistema
automático, no asegura la utilidad de los mismos para usuarios humanos de hecho, una alta cobertura puede estar asociada con un exceso de
información que podría llegar a dificultar las aplicaciones para este tipo de
usuarios -, en esta tesis se empleará una metodología de evaluación basada
en la realización de una actividad de aprendizaje con alumnos. Teniendo en
1
RESUMEN / ABSTRACT
cuenta las consideraciones del profesorado en medicina, la utilización del
sistema en la actividad de aprendizaje permitirá evaluar: (i) los resultados
objetivos obtenidos por los alumnos en un examen tipo test tradicional; (ii)
la percepción de los alumnos sobre el soporte ofrecido por el sistema al
realizar la actividad; (iii) la percepción de los alumnos en cuanto a la
usabilidad del interfaz.
En los entornos educativos existe una demanda creciente de actividades de
aprendizaje activo que faciliten la participación a los alumnos durante el
proceso de adquisición de conocimientos. Estas estrategias de aprendizaje
están fundamentalmente orientadas a mejorar la comprensión y la
memorización de los conocimientos por los estudiantes. Además, con las
metodologías de aprendizaje activo es posible mejorar la percepción
subjetiva de los alumnos en relación con el proceso de aprendizaje, con
todas las implicaciones positivas que esto supone para las dinámicas de
adquisición de conocimientos. Por ello, este tipo de actividades presentan
características suficientemente interesantes como para considerarlas de
utilidad en el aprendizaje a largo plazo, más allá de los resultados obtenidos
en el corto plazo.
Los sistemas informáticos y la red de Internet han demostrado, en multitud
de estudios, ser un soporte de utilidad para llevar a cabo de forma efectiva
diferentes tipos de actividades de aprendizaje, tales como son las
denominadas computer-based learning (aprendizaje basado en sistemas
informáticos), internet-based learning (aprendizaje basado en internet),
case-based learning (aprendizaje basado en casos) o concept-based learning
(aprendizaje basado en conceptos). Valorando las características de estas
metodologías de aprendizaje, se propone el nuevo modelo de sistema
informático avanzado para realizar una actividad de aprendizaje en la que
2
RESUMEN / ABSTRACT
confluyen diferentes características de las que se han mencionado. La
metodología de aprendizaje diseñada seguirá los siguientes pasos:
1. Selección de un caso clínico acorde con el nivel de conocimientos de
los alumnos.
2. Selección de las fuentes de conocimiento con las que se van a
extraer los conceptos de interés y desde las que se va a mostrar la
información a los alumnos.
3. Diseño de un cuestionario de preguntas de tipo test, íntimamente
relacionadas con el caso clínico seleccionado.
4. La utilización del sistema inteligente, desde el que se integran las
fuentes de conocimiento, o de la información disponible en
Internet.
El sistema se evaluará sobre usuarios en escenarios de aplicación utilizando
esta metodología, siendo preciso el diseño de cuestionarios de percepción
subjetiva que serán cumplimentados por los usuarios tras llevar a cabo la
experiencia haciendo uso del sistema inteligente.
3
RESUMEN / ABSTRACT
ABSTRACT
This thesis proposes the development, application and evaluation of a
system model of intelligent access to biomedical information using learning
activities with students of higher education in the knowledge area of
biomedical science.
The system model concerned will be able to extract terms and concepts
from a text entered into the system, through techniques from NLP (Natural
Language Processing), and will show integrated information from various
sources for these extracted entities. The text entered into the system can be
in English or Spanish, returning as result the set of biomedical terms and
concepts found, in both languages, and a set of information sources that can
be in both languages regardless of the language in which the entity was
discovered from the original text.
This type of systems can be a part of other information retrieval systems,
solving a particular task in the overall process, or be directly used by human
users to solve some task. Since traditional evaluation based on
measurements of precision, recall and F-measure, usually carried on this
type of systems to assess their efficacy as a component of another
automatic system does not ensure their usefulness for human users - in fact,
a high recall value may be associated with an excess of information that
could hinder the practical applications for these users -, in this thesis will be
used an evaluation methodology based on the performance of a learning
activity with students. Taking into account the considerations of the
medicine teachers, the use of the system in a learning activity will allow to
assess: (i) the objective results obtained by students in a traditional
multiple-choice test, (ii) the perception of students on the support offered
4
RESUMEN / ABSTRACT
by the system to perform the activity, (iii) the perception of students
regarding the usability of the interface.
In educational settings there is an increasing demand for active learning
activities that facilitate the students' participation in the process of
knowledge acquisition. These learning strategies are mainly aimed at
improving the understanding and memorization of knowledge by students.
Furthermore, with active learning methodologies it is possible to improve
the subjective perception of students regarding the learning process, with
all the positive implications that this entails for the dynamics of knowledge
acquisition. Therefore, these activities have features interesting enough to
be considered useful in the long-term learning, beyond the results obtained
in the short term.
Computer systems and the Internet have shown, in many studies, to be a
useful support to carry out effectively different types of learning activities,
such as are those known as computer-based learning, internet-based
learning, case-based learning or concept-based learning. Considering the
characteristics of these learning methodologies, it is proposed a new model
of advanced computer system to perform a learning activity in which merge
different features of those. The learning methodology designed will include
the following steps:
1. A clinical case selection in keeping with the knowledge level of
students.
2. Selection of the knowledge sources with which the concepts of
interest are going to be extracted and from which information
related to these concepts is going to be showed to the students.
3. A design for a multiple-choice questionnaire, which questions are
closely related to the clinical case selected.
5
RESUMEN / ABSTRACT
4. The use of the intelligent system, from which knowledge sources are
integrated, or information available on Internet.
The system will be assessed on users in application scenarios using this
methodology, and it will be necessary the design of subjective perception
questionnaires that the users will complete after conducting the activity
using the intelligent system.
6
INTRODUCCIÓN
CAPÍTULO 1. INTRODUCCIÓN.
El hilo conductor que ha dado lugar al desarrollo de la presente investigación
es la problemática del traslado de conocimiento desde las ciencias básicas a las
ciencias aplicadas en el ámbito biomédico, que está siendo estudiada de forma
general desde la denominada investigación traslacional y, de forma particular
en medicina, desde la medicina traslacional. Este intento de generación de
nuevas herramientas bioinformáticas que aporten soluciones a determinados
problemas de este vasto campo de estudio, tales como el soporte a la toma de
decisiones en el estudio de casos clínicos (Bellazzi, Larizza, Gabetta, Milani,
Nuzzo, Favalli, & Arbustini, 2010) o la mejora en el intercambio de conceptos
entre los especialistas de diferentes disciplinas (Sarkar, 2010), ha derivado
hacia otras áreas de conocimiento en las que ha abierto, incluso, la posibilidad
de evolución hacia nuevas líneas de investigación que van más allá del ámbito
del presente trabajo. El interés por el desarrollo de herramientas
bioinformáticas que faciliten la toma de decisiones, ha dirigido esta
investigación hacia el desarrollo de sistemas inteligentes capaces de analizar
de forma automática textos médicos escritos en lenguaje natural, para lo que
ha sido necesaria la construcción de un modelo arquitectónico que sustente la
implementación realizada. La creación de este modelo ha puesto de relieve la
posible aplicación a otros dominios de conocimiento, así como otras
cuestiones relacionadas con la escalabilidad o la facilidad proporcionada por la
arquitectura para la ampliación de las funcionalidades finalmente incorporadas
para el dominio biomédico (como por ejemplo, las fuentes de conocimiento
utilizadas o las técnicas de análisis automático aplicadas). Por otro lado, la
generación de herramientas bioinformáticas que procesen textos biomédicos
destinadas a facilitar la comprensión de diferentes tipos de usuarios, ha sido
7
INTRODUCCIÓN
determinante en la decisión del tipo de estrategia computacional adoptada, es
decir, la construcción de un sistema que sea capaz de extraer conceptos de
interés a partir de textos escritos en lenguaje natural y que proporcione
información ampliada a partir de fuentes de información que se ajusten a los
conocimientos de los diferentes tipos de usuario. Para lograrlo, ha sido
necesario profundizar en diferentes técnicas de anotación, extracción y
provisión de información a partir de diferentes recursos y fuentes de
conocimiento, sin perder de vista el objetivo de ofrecer un sistema capaz de
dar respuesta a los usuarios finales y sobre los que, posteriormente, será
necesario evaluar el sistema desarrollado. La orientación del modelo de
sistema a usuarios finales ha influido notablemente en que buena parte del
esfuerzo de desarrollo se haya dedicado al estudio de sistemas, de
procesamiento de texto en lenguaje natural, capaces de dar respuesta en línea
sobre la información extraída a partir del texto introducido por dichos
usuarios. Finalmente, la selección de un conjunto de individuos apropiados
para efectuar el proceso de evaluación, así como la asignación de una tarea
concreta a resolver por los mismos, ha conducido la experiencia de uso hacia el
marco de educación superior en medicina y el conjunto de posibles actividades
de aprendizaje acordes con los nuevos métodos de enseñanza. Todas estas
ramificaciones de interés relacionadas con el presente trabajo pueden
resumirse esquemáticamente del siguiente modo:
Soporte para la toma de decisiones con textos médicos.
o
Sistemas inteligentes para el análisis automático de textos
médicos.
o
Arquitectura para el modelado de estos sistemas.
Escalabilidad y aplicación a otros dominios de
conocimiento.
8
INTRODUCCIÓN
Implementación en el dominio biomédico.
Intercambio de conceptos entre diferentes especialistas.
o
Extracción de información relevante de textos médicos y
provisión de fuentes de información adecuada.
Técnicas de reconocimiento, anotación y extracción de
conceptos.
Selección
e
integración
de
información
desde
diferentes fuentes de conocimiento.
o
Herramientas orientadas a usuarios finales.
Diferentes tipos de usuarios.
Información en línea.
Estrategias para la evaluación con usuarios.
Resolución de una tarea asignada a estudiantes de
medicina.
De modo trasversal a todas estas cuestiones se afronta también la
problemática que se presenta al procesar textos en diferentes idiomas, muy
relacionada con el origen multilingüe de las fuentes de conocimiento en las
que se encuentra alojada la información. La incorporación de componentes
multilingües y cross-lingües, en todas las tareas relacionadas con el
procesamiento de información, es de máxima actualidad y está provocando
que se reabran muchas líneas clásicas de investigación con enfoques
novedosos que afronten los desafíos de esta, cada vez más, realidad
multicultural de la sociedad y, en consecuencia, de los sistemas de
información.
En este contexto de desarrollo multidisciplinar en el que se ha consumado la
investigación, es necesario repasar algunas cuestiones clave que impregnan
9
INTRODUCCIÓN
cada uno de los objetivos alcanzados, más allá del desarrollo técnico y la
aplicación al dominio biomédico, que también se tratará en profundidad a lo
largo de la memoria. Este capítulo introductorio tiene la finalidad de
proporcionar información suficiente al lector sobre los conceptos clave que
forman los fundamentos sobre los que se cimientan el resto de capítulos de
este trabajo de tesis, necesarios para comprender en mayor medida los
objetivos
principales,
resultados,
aportaciones
y
nuevos
horizontes
investigadores planteados. En concreto, se describe con mayor detalle el
marco general de la medicina traslacional, mencionado anteriormente, en el
que se desarrolla la investigación. A continuación se repasan las principales
fuentes
de
información
biomédicas
existentes,
utilizadas
para
la
implementación en el dominio biomédico a partir del modelo arquitectónico
planteado. En la siguiente sección se explica el contexto educativo en el que se
realiza la evaluación sobre el que, por otro lado, los sistemas inteligentes
pueden aportar un gran valor. Y, finalmente, se describe la estructura de la
tesis realizándose un repaso de los siguientes capítulos incluidos en la
memoria.
1. Investigación traslacional y medicina traslacional
La investigación traslacional es un término que define todo un nuevo
paradigma y un modo de proceder en relación a la gestión del conocimiento
científico. El conocimiento obtenido a partir de las investigaciones llevadas a
cabo en diferentes disciplinas científicas no se ve reflejado, eficazmente y en
tiempos razonables, en resultados aplicables y de utilidad para las personas.
Este distanciamiento pone de relieve la distinción tradicional entre los
términos de ciencia básica y ciencia aplicada, tratando de unificarlas en un
10
INTRODUCCIÓN
único proceso que permita el intercambio del conocimiento entre las personas
involucradas en ambos.
La distinción existente entre el conocimiento teórico y su aplicación se
presenta como un aspecto especialmente crítico en ámbitos como el de la
medicina, ya que de la eficiencia del proceso de traslación de los
conocimientos dependen en muchas ocasiones la salud y, en última instancia,
la vida de las personas. Nótese que los tiempos medios de aplicación de los
resultados clínicos se van hasta casi dos décadas y los cuidados recomendados
para los pacientes se aplican en porcentajes que están lejanos del deseado
100% (Kawamoto, Lobach, Willard, & Ginsburg, 2009). En este sentido, el
término acuñado para este importante campo de conocimiento es el de
medicina traslacional, en el que se pretende aplicar a las ciencias biomédicas la
idea de hacer llegar eficientemente hasta los pacientes el conocimiento
obtenido a partir de la investigación básica, facilitando la creación de nuevos
tratamientos, mecanismos de diagnóstico y prevención, ayudando a generar
herramientas para el soporte a la decisión así como la mejora del sistema de
salud y de las relaciones entre médico y paciente (Woolf, 2008).
Bioinformática traslacional
Se están desarrollando estudios, desde diferentes puntos de vista, en los que
se pretende dilucidar la importancia de la informática en relación a diferentes
aspectos vinculados con esta traslación del conocimiento. Por ejemplo, en
Sarkar, (2010) se estudian las diferentes barreras que debe superar la
investigación traslacional y el importante papel que puede adquirir la
bioinformática para facilitar el intercambio de conceptos entre los especialistas
de las diferentes disciplinas involucradas. Estas barreras se encuentran en las
transiciones de las fases por las que atraviesa la transferencia de
11
INTRODUCCIÓN
conocimiento, denominándose T1 a aquella que va desde la fase de
experimentación en el laboratorio hasta la de ensayos clínicos, T2 a la que va
desde esta última hasta la de adopción por las comunidades y, finalmente, T3 a
la que conduce al establecimiento de políticas adecuadas que permitan su
acceso a toda la población. En este contexto traslacional, la importancia de la
bioinformática radica en las grandes posibilidades de aplicación de los
diferentes avances que se van produciendo a cada una de las problemáticas
asociadas con la transferencia multidisciplinar del conocimiento, más que en la
creación de nuevas técnicas computacionales. Otro ejemplo se puede
encontrar en Bellazzi et al. (2010), donde se subraya este papel refiriéndose a
la bioinformática traslacional y su aportación para la práctica de la medicina
personalizada, a través de sistemas de ayuda a la decisión trabajando sobre
casos clínicos. La medicina personalizada es uno de los objetivos últimos de
este proceso de mejora continua de la medicina aplicada, aunque todavía se
encuentra en un estado incipiente y aún será necesario superar gran cantidad
de dificultades hasta lograr su aplicación generalizada (Hamburg, & Collins,
2010).
Relación con la Web semántica
En los últimos años, se ha venido produciendo un gran desarrollo de las
interfaces de usuario para el acceso a la información de forma amigable y con
contenido semántico a través de la Web, técnicas que quedan recogidas en el
concepto de Web semántica. Existe una relación entre los objetivos de
personalización y recopilación de datos procedentes de diferentes fuentes,
inherentes a la investigación traslacional, y los correspondientes en el ámbito
de la Web semántica. Esta relación está provocando que se realicen diferentes
valoraciones de la utilidad de esta última en relación a los objetivos de la
12
INTRODUCCIÓN
primera (e.g. Ruttenberg et al., 2007; Ruttenberg, Rees, Samwald, & Marshall,
2009), así como creado grupos de trabajo que estudian campos de aplicación
(tal como el HCLSIG, Semantic Web for Health Care and Life Sciences Interest
Group). La utilidad de los recursos semánticos aplicados al dominio biomédico
está quedando reflejada en el desarrollo de muchas plataformas orientadas a
solventar problemas traslacionales (e.g. Mirhaji, Zhu, Vagnoni, Bernstam,
Zhang, & Smith, 2009; Lowe, Ferris, Hernandez, & Weber, 2009; Luciano et al.,
2011).
Uno de los retos en el desarrollo de la Web semántica, y de la computación en
general desde hace décadas, consiste en el aprovechamiento de la descomunal
cantidad de información en formatos estructurado y desestructurado
disponible en Internet, asegurando la fiabilidad de los contenidos. Para
lograrlo, se están desarrollando multitud de sistemas encargados del
procesado y filtrado de los datos almacenados en fuentes heterogéneas (entre
las que destaca la utilización de la Wikipedia), transformándolos a formatos
estándar como RDF (Resource Description Framework) ó OWL (Web Ontology
Language) que permiten el enriquecimiento semántico de los contenidos a
través de la incorporación de metadatos (e.g. Suchanek, Kasneci, & Weikum,
2007; Auer, Bizer, Kobilarov, Lehmann, Cyganiak, & Ives, 2007; Bizer, Lehmann,
Kobilarov, Auer, Becker, Cyganiak, & Hellmann, 2009; Varde, Suchanek, Nayak,
& Senellart, 2009; Wang, Zhu, Qu, Spaniol, & Weikum, 2010) y, de este modo,
su aprovechamiento desde la Web semántica.
2. Fuentes de información biomédica
El acceso a información médica a través de Internet es cada vez más
demandado por diferentes tipos de usuario. Sin embargo, la cantidad de
recursos disponibles hace que las búsquedas llevadas a cabo por estos usuarios
13
INTRODUCCIÓN
lleguen a ser poco efectivas. Localizar una información adecuada para el nivel
de conocimientos de un usuario determinado, que además contenga una
información fiable, no es una tarea sencilla y puede conducir a resultados
contradictorios (Sommerhalder, Abraham, Zufferey, Barth, & Abel, 2009;
Honekamp, & Ostermann, 2010; Scullard, Peacock, & Davies, 2010; Adams,
2010).
Problemas generales de los usuarios
Las búsquedas de determinados conceptos médicos como son, por ejemplo,
una enfermedad o un síntoma, pueden dar lugar a una cantidad de resultados
prácticamente inmanejable, con resultados que contienen tanto información
fiable como no fiable, orientados a expertos, investigadores o al público en
general. Tanto si se trata de usuarios con unos conocimientos más profundos
de la terminología biomédica (como sería el caso de un médico, un
investigador o un estudiante avanzado de medicina) como si se trata de
usuarios con menos conocimientos de la terminología, para localizar la
información deseada será necesario superar un conjunto importante de
dificultades. Ejemplo de este segundo tipo de usuarios son los propios
pacientes que quieren informarse mejor de alguna enfermedad que se les ha
diagnosticado, familiares de estos pacientes, médicos en las primeras fases de
su educación o simplemente usuarios en búsqueda de síntomas que se les
están presentando. Tal y como se observa en Kienhues, Stadtler, & Bromme,
(2011), las personas que buscan ampliar información en Internet sobre temas
médicos (como por ejemplo, enfermedades o tratamientos) pertenecen
mayoritariamente a este segundo perfil. Cuando estos individuos, que no
pertenecen a la profesión médica, desean averiguar más información sobre
una posible enfermedad, un conjunto de síntomas o un tratamiento, se
14
INTRODUCCIÓN
encuentran con diversas dificultades entre las que se pueden destacar (Luo y
Tang, 2008): (i) la falta de experiencia y conocimiento del dominio para realizar
una búsqueda adecuada, (ii) falta de comprensión de la terminología médica
encontrada. Por otro lado, cuando un usuario con conocimientos médicos (un
profesional del área de la salud, un investigador en biomedicina, un estudiante
en las últimas etapas de su educación, etc.) trata de encontrar información
sobre un caso clínico, por ejemplo, se encuentra con una gran diversidad de
herramientas de búsqueda que dan acceso a diferentes fuentes de
información (Trivedi, 2009). Esta variabilidad dificulta el proceso de
comprensión, generando una dispersión del proceso y entorpeciendo la
recopilación de información concreta que facilite la resolución del caso de
estudio.
Bases de conocimiento disponibles
Las fuentes de información biomédica que dan lugar a todo este conjunto de
recursos ofrecidos a través de Internet, mantienen bases de conocimiento
tanto en formato estructurado (como por ejemplo bases de datos relacionales
y no relacionales, diccionarios de conceptos, ontologías, etc.) como en formato
no estructurado (tales como publicaciones científicas, historiales médicos,
notas clínicas, casos clínicos, etc.), almacenando, además, todos sus datos en
un único idioma o en diferentes idiomas. Esta heterogeneidad es la que
ensalza el papel adquirido por las tareas de procesamiento de lenguaje natural
y la importancia del desarrollo de sistemas inteligentes que realicen
adecuadamente la integración de la información biomédica, poniéndola a
disposición de los distintos tipos de usuario de un modo adecuado.
15
INTRODUCCIÓN
Para solventar algunas de las dificultades en la búsqueda de información
biomédica fiable y de calidad, cabe destacar los recursos ofrecidos por el NIH1
(National Institute of Health), iniciativa perteneciente al HHS2 de Estados
Unidos (Department of Health & Human Services). Como parte del NIH, y
fundada ya en el año 1836, destaca el papel del NLM (the National Library of
Medicine) que se encarga de proveer recursos y servicios a diferentes perfiles
de usuario tales como los científicos, los profesionales de la salud y el público
en general (tal y como explicita en su hoja informativa3). Un listado completo
de todos estos recursos se puede encontrar en su buscador de recursos y
bases de datos4. Algunos ejemplos de recursos facilitados para el público en
general son los buscadores de temas relacionados con la salud Healthfinder5
(ofrecida por el NIH y mantenida directamente por el HHS), MedlinePlus6 y el
portal de salud adaptado para personas mayores NIHSeniorHealth7. Tanto
Healthfinder como MedlinePlus ofrecen sus contenidos tanto en inglés como
en español, estando su información orientada a toda la población, con un
lenguaje fácil de entender sin perder por ello rigurosidad y fiabilidad. Algunos
ejemplos de recursos de la NLM dirigidos a los profesionales de la salud son: el
buscador gratuito de artículos científicos biomédicos denominado PubMed
1
http://www.nih.gov
2
http://www.hhs.gov
3
http://www.nlm.nih.gov/pubs/factsheets/nlm.html
4
http://www.nlm.nih.gov/databases
5
http://www.healthfinder.gov
6
http://www.nlm.nih.gov/medlineplus
7
http://nihseniorhealth.gov
16
INTRODUCCIÓN
Central8;
la
base
de
datos
pública
para
búsquedas
bibliográficas
MEDLINE/PubMed9. Estos dos últimos servicios están desarrollados y
mantenidos por el NCBI10 (National Center for Biotechnology Information),
formando parte de la red de centros denominada NCBC11 (National Centers for
Biomedical Computing), de la que también forma parte el NCBO12 (National
Center for Biomedical Ontology) cuyos servicios han sido especialmente
relevantes en el desarrollo de esta investigación. Otras bases de datos más
orientadas a la investigación biomédica, sobre las que el NLM proporciona
servicios de acceso, son por ejemplo: el tesauro de vocabulario médico MeSH13
(Medical Subject Headings); el conjunto de recursos médicos UMLS14 (Unified
Medical Language System).
3. Desarrollo de actividades de aprendizaje activo
La tendencia actual en educación está orientándose, cada vez más, hacia
modelos de aprendizaje en los que se miden los resultados progresivamente,
en lugar de basar estos resultados exclusivamente en pruebas de evaluación
de grandes bloques de contenidos. Tal y como se menciona en Altbach,
Reisberg, & Rumbley (2009), factores como un interés creciente en la
formación continua (orientada a una educación global que se adapte al ámbito
8
http://www.ncbi.nlm.nih.gov/pmc
9
http://www.ncbi.nlm.nih.gov/pubmed
10
http://www.ncbi.nlm.nih.gov
11
http://www.ncbcs.org
12
http://www.bioontology.org
13
http://www.nlm.nih.gov/mesh/meshhome.html
14
http://www.nlm.nih.gov/research/umls/
17
INTRODUCCIÓN
profesional) están forzando cambios en los modelos educativos y en los
mecanismos de evaluación. Anteriormente, la educación se centraba
exclusivamente en el conocimiento adquirido de las diferentes materias,
considerándose que las carencias en el aprendizaje de los alumnos se debían
fundamentalmente a factores como la falta de interés, esfuerzo o talento de
los mismos. Progresivamente se fue adoptando un modelo centrado en el
profesor, en el que predominaban las clases magistrales y las evaluaciones se
basaban principalmente en exámenes relacionados con el material impartido
en las clases. En los nuevos modelos educativos, centrados en el aprendizaje
de los alumnos, los estudiantes adoptan un papel más activo en el proceso de
aprendizaje y se investiga más acerca del modo en el que el profesorado
enfoca sus métodos de enseñanza, así como el modo en el que se evalúan los
resultados del aprendizaje.
Contexto
El Espacio Europeo de Educación Superior (EEES15, EHEA16) tiene su origen en
una Declaración firmada en el año 1998, en la Sorbona, por las instituciones
educativas de Francia, Alemania, Reino Unido e Italia, que se traduciría al año
siguiente en la Declaración de Bolonia (con la participación de 30 países
europeos). Actualmente (Mayo 2012) el proceso cuenta con la participación de
47 países. Para el seguimiento de los objetivos planteados y de los mecanismos
necesarios para lograrlos, en este denominado ‘proceso de Bolonia’, se han ido
realizando una serie de conferencias bianuales, cuyo objetivo general ha sido
el de conseguir la convergencia en el año 2010. Entre los temas del programa
15
http://www.eees.es
16
http://www.ehea.info
18
INTRODUCCIÓN
de trabajo del proceso de Bolonia, para lograr la conversión al EEES, se
encuentran la formación continua (incorporada en la conferencia de Praga en
el año 2001) y el aprendizaje centrado en el alumno (cuya incorporación en el
proceso se produce más recientemente en la conferencia de Leuven/Louvainla-Neuve en el año 2009). Tanto la formación continua (lifelong learning) como
el aprendizaje centrado en el alumno (student-centred learning) ocupan un
papel central en el informe de tendencias realizado para la conferencia
aniversario del año 2010 (Sursock & Smidt, 2010).
La formación continua promueve una educación que sea útil para afrontar los
retos del mercado laboral a lo largo de toda la vida, alejándose del paradigma
en el que lo prioritario es transmitir a los estudiantes un conjunto de paquetes
estanco de conocimientos. Para lograr este objetivo y promover un
aprendizaje a largo plazo, es fundamental una transición en los planes
educativos que vaya transformando lo que anteriormente eran el conjunto de
conocimientos que se deseaban transmitir, en dinámicas educativas con un
número mayor de actividades de aprendizaje que faciliten el desarrollo y la
adquisición de estos conocimientos. Este tipo de actividades ayudará a los
estudiantes a afrontar y desarrollar mejor las habilidades necesarias para
enfrentarse a los problemas del mundo real, cuando tengan que llevar a cabo
tareas como profesionales. Entre este tipo de nuevos recursos en los planes de
estudio, destaca la definición de actividades de aprendizaje basadas en casos
(Guerrero, Minguillón, Guàrdia, & Sangrà, 2009; Graf, Kinshuk, & Holzinger,
2010).
Aprendizaje activo y percepción de los alumnos
En la aproximación del nuevo paradigma de aprendizaje, centrado en el
estudiante, se considera que: (i) el conocimiento es adquirido por los alumnos
19
INTRODUCCIÓN
a través de diferentes tipos de actividades de aprendizaje en lugar de ser
directamente transmitido por el profesorado; (ii) los resultados están
alineados con los métodos de enseñanza y con la evaluación; (iii) los posibles
resultados deben estar definidos de antemano (Altbach et al. 2009). Por tanto,
la aproximación de enseñanza centrada en el estudiante trata de enfocarse
hacia las necesidades de los mismos, en lugar de prestar tanta atención a la
transmisión directa de información por parte del profesorado. Tal y como se
menciona en Baeten, Kyndt, Struyven, and Dochy (2010), los métodos
desarrollados para promover la participación del alumno en el aprendizaje
(e.g. las actividades basadas en casos, las basadas en problemas, etc.) ponen
de manifiesto que, a pesar de que la efectividad de la evaluación de los
entornos de aprendizaje centrados en los estudiantes es complejo y depende
de multitud de factores (como la involucración del profesor, la disciplina, la
edad, el sexo, etc.), sí parecen influir de forma determinante la percepción que
los alumnos tienen sobre el contexto de aprendizaje, más allá de lo innovador
que sea el tipo de evaluación (que incluso puede llegar a ser un factor
contraproducente).
Estas cuestiones ponen de manifiesto la importancia que tienen los procesos
en los que el profesorado selecciona y organiza la información y los recursos
ofrecidos a sus estudiantes, para posteriormente medir la percepción
individual generada sobre el aprendizaje obtenido a partir de estos recursos.
Para la puesta en marcha y la aplicación del aprendizaje centrado en el
alumno, los profesores pueden apoyarse y aprovechar el desarrollo de las
teorías de la cognición situada, en las que los factores culturales y contextuales
son considerados factores clave (ver por ejemplo, Wertsch, 1985),
adoptándolas desde un enfoque complementario y no en contraposición a
otras teorías educativas (Aparicio, & Moneo, 2005). Además, en este sentido
20
INTRODUCCIÓN
también existen actividades como las basadas en casos mejoradas con la Web
(Kim, & Hannafin, 2011) con un gran potencial aún sin explorar, o algunas de
las técnicas relacionadas con la Web semántica, mencionada anteriormente,
que pueden resultar muy útiles como plataforma para el diseño de las
actividades de aprendizaje activo, mejorando la experiencia de los alumnos
(Sherimon, Vinu, & Krishnan, 2011).
Sistemas inteligentes en educación
El uso de sistemas inteligentes en el ámbito educativo es una práctica
empleada cada vez más como estrategia para conseguir una mejora tanto en
los procesos de enseñanza como en los de aprendizaje (e.g. Huang, Liu, Chu, &
Cheng, 2007; Stankov, Rosic, Zitko, & Grubisic, 2008; Holzinger, Kickmeierrust,
Wassertheurer, & Hessinger, 2009; Holzinger, Emberger, Wassertheurer, &
Neal, 2008).
Además, existen una gran cantidad de propuestas investigadoras en las que se
emplean actividades de aprendizaje activo basadas en el uso de sistemas
informáticos, haciendo uso del soporte digital, tales como las basadas en
computadoras (computer-based learning, que se refieren a todas aquellas
actividades en las que son usados sistemas informáticos en el aula), las
basadas en Web (web-based learning), basadas en Internet (internet-based
learning), las de aprendizaje en línea (online learning), el aprendizaje
electrónico (e-learning), etc. Sin embargo, en relación a las actividades de
aprendizaje en las que se utiliza la información procedente de Internet, poner
a disposición de los estudiantes toda esta información puede no ser suficiente
para promover adecuadamente su aprendizaje al formular este tipo de
metodologías activas (Brand-Gruwel, & Stadtler, 2011; Cook, Levinson,
Garside, Dupras, Erwin, & Montori, 2008; Wong, Greenhalgh, & Pawson, 2010),
21
INTRODUCCIÓN
mostrándose como necesidades adicionales en el proceso de diseño
cuestiones como: una selección previa de las fuentes de conocimiento
utilizadas para mostrar el contenido, realizada por expertos; una
contextualización de la información coherente con el nivel de conocimiento de
los estudiantes con los que se va a llevar a cabo la actividad; y el análisis de los
resultados comparándolos con un método de aprendizaje tradicional o, en el
caso de haber realizado un filtrado de los contenidos accesibles,
comparándolos con una búsqueda tradicional en Internet en la que se ponen a
disposición de los estudiantes todos los recursos disponibles.
La educación médica es un área de la enseñanza muy apropiada para la
aplicación de diferentes estrategias de enseñanza y aprendizaje, tales como las
basadas en casos o las basadas en problemas. Estas actividades,
conjuntamente con otras que se llevan a cabo haciendo uso de los mapas
conceptuales o los mapas mentales, están principalmente fundamentadas en
el desarrollo de la las teorías de aprendizaje constructivista, que pueden
considerarse, desde diferentes puntos de vista, como parte de la evolución
cognitivista (ver e.g. Gijbels, & Loyens, 2009). Cuando se crea una actividad de
aprendizaje en educación superior y, en concreto, en los estudios de medicina,
es importante tener en consideración esta evolución desde el positivismo
tradicional - en el que la comprensión de la realidad es considerado como algo
que debe ser adquirido objetivamente, visión que está íntimamente ligada a la
consideración de los alumnos como recipientes pasivos en los que se va
almacenando la información -, hacia las visiones constructivistas - que tienden
hacia esquemas de aprendizaje más centrados en los alumnos, en los que
éstos adoptan un papel más activo y son considerados como generadores del
conocimiento - y, más aún, hacia las teorías post-estructuralistas - en las que
22
INTRODUCCIÓN
se tiene en cuenta la complejidad de la realidad y el hecho de que ésta puede
estar sujeta a múltiples interpretaciones (Mann, 2011).
Existen multitud de ejemplos de la investigación y la aplicación de los métodos
constructivistas en el ámbito de la educación médica. Algunos ejemplos,
directamente relacionados con la propuesta de evaluación llevada a cabo en
esta investigación, se pueden encontrar en: la rúbrica de evaluación para una
actividad basada en los mapas mentales estudiada en D’Antoni, Zipp, Olson,
and Cahill, (2010), o en D’Antoni, Zipp, and Olson, (2011); la investigación, en
un entorno de aprendizaje basado en Web, con dos ejemplos basados en casos
(un caso de hipertensión atrial y otro de hipertiroidismo) diseñado en Stark,
Kopp, and Fischer, (2011); o el desarrollo de sistemas de entrenamiento
construidos con mundos virtuales analizado en Chodos et al. (2010). Sin
embargo, también es importante tener en cuenta que a pesar de lo
prometedor de todas estas metodologías, dada la gran complejidad de la
educación médica y el gran número de factores que inciden en el proceso
(Dolmans, & Vleuten, 2010), es crucial el diseñar cuidadosamente las
actividades y medir adecuadamente los resultados.
4. Estructura de la tesis
En este trabajo de tesis se presenta un modelo de arquitectura de sistema
inteligente para la extracción de entidades (términos, que aparecen
explícitamente en el texto, y conceptos, que no tienen por qué aparecer de
forma explícita) y el acceso a información cross-lingüe, implementado para un
dominio particular como es el biomédico. Esta implementación permite, entre
otros, el acceso en línea a los usuarios finales que, utilizando un texto digital
con contenido médico escrito en inglés o en español, pueden procesarlo
automáticamente obteniendo entidades nombradas de interés extraídas del
23
INTRODUCCIÓN
texto y un conjunto de fuentes de información en ambos idiomas (fiables y de
calidad) con las que obtener más información sobre los términos, así como
sobre otros conceptos relacionados semánticamente. El sistema está provisto,
además, de un servicio Web que puede ser explotado por otros sistemas
informáticos.
La evaluación por usuarios de este sistema biomédico se ha consumado en el
contexto educativo de educación superior con estudiantes del grado de
Medicina, a través de una actividad de aprendizaje activo en la que concurren
características de metodologías de aprendizaje como las basadas en casos, en
problemas, en computadoras, en Internet y en Web. La actividad de
aprendizaje se ha diseñado teniendo en cuenta los factores clave mencionados
para conducir este tipo de metodologías activas, es decir, el proceso previo de
selección de fuentes de conocimiento por expertos, la adecuación de la
información al nivel de conocimientos de los estudiantes y la comparación con
los resultados de la misma actividad utilizando una búsqueda tradicional en
Internet. Por otro lado, ha sido necesario valorar la elección de los procesos
computacionales incluidos en el sistema, así como una interfaz apropiada, para
asegurar la usabilidad durante el transcurso de la actividad.
Tras esta introducción a los contenidos generales de la memoria, en el capítulo
2 se da una visión general del modelo de sistema propuesto, previa descripción
del problema que se pretende resolver y de la situación actual, las principales
motivaciones para su creación y los objetivos que se persiguen. El capítulo 3
está centrado en las estrategias utilizadas para la fusión de las diferentes
fuentes de información biomédica, bajo la arquitectura general diseñada,
destacándose tres grandes bloques directamente relacionados con la
estructura modular del diseño: el primer bloque está dedicado al
reconocimiento de entidades, que engloba dos de los módulos (dedicados al
24
INTRODUCCIÓN
preprocesado y la aplicación de técnicas de PLN); el segundo está relacionado
con los métodos que se han empleado para proporcionar información sobre
las entidades reconocidas en el texto; mientras que el tercer bloque describe
el diseño de los mecanismos de acceso al sistema. El desarrollo técnico de cada
uno de los componentes y elementos del sistema biomédico se muestra en el
capítulo 4, que contiene un apartado por cada uno de los módulos de la
arquitectura. En el capítulo 5 se realiza un análisis de un conjunto de casos de
prueba que permiten conocer la respuesta del sistema biomédico al integrar
diferentes fuentes de información y procesar diferentes textos de entrada,
conocimiento que es necesario para valorar las debilidades y fortalezas del
software en función de varios parámetros: las dimensiones de las
terminologías utilizadas para reconocer las entidades; pros y contras de la
integración de los procesos remotos incorporados; las capacidades para el
preprocesado en tiempo real (en línea) de textos de diferentes longitudes. En
el capítulo 6 se describe la experiencia de aprendizaje puesta en práctica con
los estudiantes, analizándose en detalle todos los resultados obtenidos. El
capítulo 7 está dedicado a la recopilación de cada una de las aportaciones
realizadas y el cumplimiento de los objetivos planteados inicialmente. Por
último, en el capítulo 8 se lleva a cabo una revisión de las posibles líneas de
investigación futuras.
25
INTRODUCCIÓN
26
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
CAPÍTULO 2. MODELO DE SISTEMA INTELIGENTE.
1. Descripción del problema
Tal y como se menciona en Feldman, & Sanger, (2007), de las cuatro
estructuras de texto más utilizadas para caracterizar los documentos en los
algoritmos de minería de texto (i.e. caracteres, palabras, términos y
conceptos), destacan las basadas en términos y en conceptos, tanto por su
capacidad para representar el contenido semántico como por la capacidad
de hacerlo con un número menor de características, respecto a otras
representaciones como las que se basan en caracteres o palabras. La
diferencia fundamental entre la representación basada en términos y la
basada en conceptos, radica en que en la primera los términos extraídos
están compuestos de palabras que aparecen en el documento (lo que
facilita las técnicas de extracción automáticas), mientras que, en la segunda,
los conceptos extraídos no tienen por qué estar presentes de forma explícita
(implicando mayor complejidad en las técnicas necesarias para su
extracción).
Anotación basada en conceptos
Esta caracterización se lleva a cabo a través de anotaciones que son
agregadas a los documentos, incluyendo meta-información que puede ser
explotada por sistemas de PLN, extracción de información, recuperación de
información, categorización de textos, etc. - ver, por ejemplo, en el dominio
de la biología molecular Krallinger, & Valencia, (2005) o Wilbur, Rzhetsky, &
Shatkay, (2006). Dado el ritmo actual de producción de nuevo conocimiento,
la anotación manual de textos se está haciendo inviable, convirtiendo a las
tareas de anotación automáticas en un elemento esencial para llevar a cabo
27
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
este tipo de procesos, tal y como se menciona en Baumgartner, Cohen, Fox,
Acquaah-Mensah, & Hunter, (2007).
En particular, las tareas de anotación usando conceptos son utilizadas e
investigadas en multitud de aplicaciones (Karimi, Zobel, & Scholer, 2012),
estando incorporadas en diferentes subtareas de los procesos para la
extracción y la recuperación de información. Por ejemplo: para dar soporte
a sistemas de detección de enfermedades a partir de informes electrónicos
de salud (Xu, Fu, Shah, Chen, Peterson, Chen, Mani, et al. 2011); en
Thompson, Iqbal, McNaught, & Ananiadou, (2009) se utiliza información
sobre los conceptos biológicos para generar un corpus con información
enriquecida; en Liu, Lu, Hao, & Liu, (2011) se utilizan conceptos de Wordnet
y de la ontología Tagger para anotar textos cortos procedentes de sistemas
que tratan de dar respuesta a consultas de usuarios; el sistema Essie
(empleado en los motores de búsqueda de algunos de los sitios Web de la
NLM), presentado en Ide, Loane, & Demner-Fushman, (2007), se utiliza para
la expansión de los términos de las consultas, o, con un enfoque similar en
Matos, Arrais, Maia-Rodrigues, & Oliveira, (2010) donde se expanden las
consultas utilizando conceptos relacionados con los genes que aparecen en
el texto introducido por el usuario; en Baldoni, Baroglio, Patti, & Rena,
(2011) se emplea la idea de conceptos emocionales para dar soporte al
análisis de sentimientos y la minería de opiniones; en Embley, &
Zitzelberger, (2010) se propone el enriquecimiento de los contenidos Web
con metadatos relacionados con conceptos incluidos en ontologías; o en
Trieschnigg, Pezik, Lee, De Jong, Kraaij, & Rebholz-Schuhmann, (2009) donde
se estudian diferentes mecanismos para la mejora de la clasificación de
documentos utilizando la anotación automática con conceptos de MeSH.
28
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
Sistemas para el acceso inteligente a la información
Las investigaciones en el campo de estudio del acceso inteligente a la
información están muy relacionadas con todas estas tareas que se acaban
de esbozar en torno al procesamiento del lenguaje natural, la extracción de
información, la recuperación de información y la minería de textos, entre
otras (Armano, Gemmis, Semerano, & Vargiu, 2010). De forma general, este
campo de estudio se refiere a aquellos desarrollos en los que se integran y
hace uso de recursos implementados por otros grupos (Chen, & Li, 2010),
dando lugar a utilidades que, basándose en las tecnologías semánticas,
facilitan procesos como los llevados a cabo para el reconocimiento de
conceptos o la anotación, agregando meta-información a partir de
información desestructurada, así como en la aplicación de técnicas de
procesamiento de lenguaje natural tales como el reconocimiento de
entidades nombradas (Davies, Grobelnik, & Mladenić, 2009).
Ontologías
Las ontologías tienen un papel muy relevante en Inteligencia Artificial y en
las ciencias de la computación en general con diferentes propósitos, tales
como la gestión del conocimiento, la integración de datos y el soporte a la
decisión (Bodenreider, 2008; Abecker, & Elst, 2009). Muchos de los
sistemas, mencionados en el apartado anterior, utilizan ontologías como
base de conocimiento del que extraer y sobre el que almacenar la
información relacionada con el contenido semántico de los conceptos,
convirtiéndose en un componente clave en los procesos de acceso a la
información semántica de la Web y, más específicamente, en los procesos
de anotación de los contenidos con meta-datos basados en ontologías, cuyo
29
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
uso está cada vez más extendido en el contexto de la Web semántica
(Motik, Maedche, & Volz, 2002). Además, la incorporación de las ontologías
en los sistemas de extracción de información facilita la actualización del
conocimiento, al disgregarlo de otros componentes del sistema y
actualizarse conjuntamente con la ontología, así como la portabilidad a
otros dominios de conocimiento (Karkaletsis, Fragkou, Petasis, & Iosif,
2011).
Las ontologías biomédicas, tal y como se menciona en (Jonquet, Musen y
Shah, 2010), son un elemento cada vez más utilizado a la hora de afrontar
tareas de anotación en las investigaciones de biomedicina, permitiendo así
una mejor integración de los datos y favoreciendo los descubrimientos
traslacionales. Sin embargo, debido a la gran cantidad de ontologías y la
heterogeneidad de formatos disponibles, cuando se desea hacer uso de los
datos almacenados en las ontologías se encuentran dificultades cuya
resolución normalmente requiere el consumo de mucho tiempo y recursos,
como por ejemplo: decidir qué ontologías utilizar; seleccionar el modo en el
que ensayar con las seleccionadas; el desarrollo o la selección de las
herramientas necesarias para procesar los datos.
Gran parte del trabajo orientado a la generación de bases de conocimiento
ontológico puede ser extremadamente útil para cubrir necesidades en el
dominio biomédico. Gracias a la creciente proliferación de ontologías
biomédicas y sin dominio específico, así como la existencia de servicios que
permiten el acceso a la información que contienen, es posible crear sistemas
de acceso inteligente a la información que integren conocimiento con el
objetivo de facilitar y mejorar la comprensión de textos a los usuarios.
Algunos ejemplos de ontologías utilizadas en el dominio biomédico son GO
(Gene Ontology), MeSH (Medical Subject Headings), GALEN, UMLS (Unified
30
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
Medical Language System), SNOMED CT, ON9 y muchas otras (Gómez-Pérez,
Fernández-López, & Corcho, 2004; Rubin, Shah, & Noy, 2008). Estas
ontologías incluyen un amplio número de datos básicos sobre los conceptos
médicos, tales como el tipo o la clase a la que pertenecen y cómo se
relacionan (e.g. síntoma, enfermedad, tratamiento). Una descripción formal
de la estructura interna de las ontologías se puede encontrar en Gruber,
(1993) donde se identifican los siguientes elementos constituyentes: Clases
(conceptos abstractos o concretos), Relaciones (asociaciones entre
conceptos), Funciones (relaciones que admiten parámetros en su
definición), Instancias (tópicos) y Axiomas formales (sentencias que siempre
son ciertas).
2. Situación actual
Sistemas para el reconocimiento de conceptos
Existen algunos sistemas que reconocen conceptos a partir de textos
médicos, como por ejemplo CONNAN (Reeve, & Han, 2007; Reeve, Han, &
Brooks, 2008), donde se utiliza UMLS para localizar el concepto que mejor se
ajusta a una frase de entrada en tiempos de ejecución tales que permiten su
aplicación a sistemas en línea (consiguen anotar frases, en promedio, en
tiempos de 9-10 milisegundos, frente al promedio de MetaMap17 que se
sitúa en torno a los 200 milisegundos, tiempo al que hay que sumar el
tiempo de inicialización -carga de los conceptos en memoria- que se va a un
rango de entre 14,5-16,5 segundos, mientras que MetaMap está en el rango
de 1,3-1,6 minutos). Este tipo de sistemas son muy útiles en aquellas
17
http://metamap.nlm.nih.gov
31
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
aplicaciones donde se utilizan textos de entrada que no han sido procesados
previamente (es decir, son desconocidos por el sistema) y, dadas sus
capacidades para dar respuesta en línea, ofrecer un servicio a aquellos
clientes con la necesidad de ejecutar el análisis en tiempos cortos (utilidades
de servidor u otras aplicaciones a través de un API que dan acceso a otros
servicios en línea, usuarios finales a través de un interfaz de aplicación, etc.).
MetaMap (Aronson, 2001; Aronson, & Lang, 2010) es uno de los sistemas de
referencia en la tarea de reconocimiento de conceptos haciendo uso de
UMLS, desarrollado por la NLM. Está orientado a obtener el concepto que
mejor se ajusta a una frase determinada, situándose su origen en un intento
de mejorar la recuperación de texto biomédico referenciado en
MEDLINE/PubMed. Otros sistemas que también utilizan UMLS, en cambio,
persiguen simplemente obtener todos los conceptos encontrados
reduciendo la complejidad del procesado, en un esfuerzo por ofrecer
soluciones que den respuesta en tiempos aptos para aplicaciones Web, tal y
como por ejemplo IndexFinder (Zou, Chu, Morioka, Leazer, & Kangarloo,
2003). MetaMap es un software con muchas fortalezas, tales como la
potencia de los análisis lingüísticos, su alta versatilidad (los léxicos y
vocabularios utilizados pueden llegar a ser reemplazados por los de otros
dominios), la cantidad de algoritmos con los que se puede realizar el
procesado, etc. Aún así, tal y como se menciona en Aronson, & Lang, (2010),
tiene también algunas debilidades, como por ejemplo: los algoritmos y la
implementación de MetaMap están centrados en el procesamiento de
textos en inglés; la complejidad algorítmica que posee causa que los
tiempos de análisis no sean adecuados para respuestas en tiempo real,
aunque la resolución del análisis de referencias bibliográficas de MEDLINE se
resuelva (en las versiones actuales) en menos de un minuto (sin embargo, el
32
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
tratamiento de algunas frases complejas puede llegar a tardar horas de
computación, como por ejemplo, con la frase utilizada en el artículo
mencionado: 'from filamentous bacteriophage f1 PCR polymerase-chain
reaction PDB Protein Data Bank PSTI human pancreatic secretory trypsin
inhibitor RBP retinol-binding protein SPR surface plasmon resonance TrxA E.
coli thioredoxin').
Otro posible enfoque de los sistemas de reconocimiento de conceptos es el
mencionado en Shah, Bhatia, Jonquet, Rubin, Chiang, & Musen, (2009), en
relación a los trabajos del NCBO. En concreto, se trata de un servicio, creado
por esta institución, cuyo objetivo es el de ofrecer recursos (tales como
Array Express, Gene Expression Omnibus -GEO-, Goldminer, Medline, etc.)
en los que se reconocen conceptos (localizados a partir del conocimiento
almacenado en alguna ontología) indexándose con ellos el contenido textual
de los metadatos pertenecientes a estos recursos. Para llevarlo a cabo
integran el reconocedor de conceptos Mgrep (Jonquet, LePendu, Falconer,
Coulet, Noy, Musen, & Shah, 2011) y llevan a cabo una comparativa entre el
sistema de referencia MetaMap y Mgrep (desarrollado por la Universidad de
Michigan), seleccionando Mgrep por su rapidez, escalabilidad y niveles de
customización de los diccionarios y recursos. Evalúan el rendimiento de
ambos sistemas basándose en métricas para el cálculo de la precisión y la
cobertura, por un lado, y en otros elementos más subjetivos tales como
facilidad de uso, capacidades de personalización (o customización) y
escalabilidad. Mgrep también es utilizado desde un anotador que han
denominado NCBO Annotator u OBA (Open Biomedical Annotator), descrito
en Jonquet, Shah, & Musen, (2009) y del que también se pueden encontrar
algunos datos sobre las capacidades de anotación con Mgrep en Jonquet,
Musen, & Shah, (2008).
33
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
Algunos sistemas que realizan tareas de anotación con ontologías similares
al OBA, aunque con un número notablemente menor de funcionalidades y
recursos integrados, son: el Terminizer (Hancock, Morrison, Velarde, & Field,
2009), que utiliza ontologías OBO para reconocer los conceptos; Whatizit
(Rebholz-Schuhmann, Arregui, Gaudan, Kirsch, & Jimeno, 2008) que ofrece
un conjunto de servicios Web para identificar, entre otros, enfermedades
extraídas de MedlinePlus (con el módulo whatizitDisease) o acceder a
MetaMap (con el módulo whatizitDiseaseUMLS); o Reflect (Pafilis,
O’Donoghue, Jensen, Horn, Kuhn, Brown, & Schneider, 2009) con el que los
autores anotan (a través de un plugin que se instala en el navegador) genes,
proteínas y nombres de pequeñas moléculas.
Sin embargo, la cantidad de ontologías y los datos que ofrece el NCBO a
través de sus servicios Web (Whetzel, Noy, Shah, Alexander, Nyulas,
Tudorache, & Musen, 2011), son de magnitudes difícilmente alcanzables por
otros sistemas: han pasado en 3 años (desde 2008 hasta 2011) de 72
ontologías a 260 biomédicas, además de estar integrando datos de
ontologías de otros dominios (en ámbitos que necesitan mantener la
privacidad), y en el año 2010 contabilizó casi 36.000 usuarios que
accedieron a 35 millones de páginas. Hasta el momento, el sistema
únicamente trabaja con textos en inglés y sus evaluaciones están
fundamentalmente basadas en las capacidades del procesado.
Acceso a recursos ontológicos a través de servicios
El NCBO está construyendo herramientas y servicios de acceso libre (previa
alta en el sistema) para dar soporte al trabajo de la comunidad biomédica
34
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
con ontologías. Uno de estos recursos es el denominado BioPortal18 (Musen
et al., 2008; Noy et al., 2009), un repositorio de ontologías biomédicas en
diferentes formatos, que ofrece la posibilidad de acceso a través de servicios
o directamente a través de un interfaz Web. Estos servicios permiten
focalizar el esfuerzo de la investigación biomédica sobre los datos haciendo
uso de multitud de ontologías, con estructuras complejas, en tareas
relacionadas con el procesamiento del lenguaje natural. Además del acceso
unificado a una gran variedad de ontologías, dispone de un conjunto de
recursos indexados de forma automática a partir de dichas ontologías, tal y
como se mencionaba en la sección anterior. Estos recursos se denominan
OBR (Open Biomedical Resources) y también poseen las mismas facilidades
de acceso por medio de un interfaz de usuario19 o servicios Web20. En Abril
de 2012 el número de recursos indexados es de 2321. Otro servicio publicado
recientemente es el Recommender (Jonquet, Musen, & Shah, 2010), que
propone una clasificación de ontologías con las que anotar el texto, basada
en criterios de cobertura, conectividad y número de apariciones del
concepto en cada ontología. Estos servicios están siendo utilizados desde
diferentes tipos de sistemas, como son los mencionados en Dowell,
McAndrews-Hill, Hill, Drabkin, & Blake, (2009), donde se realiza la
evaluación de varias de las ontologías para su integración con un desarrollo
18
http://bioportal.bioontology.org
19
http://bioportal.bioontology.org/resources
20
http://www.bioontology.org/wiki/index.php/Resource_Index_REST_Web_Service_
User_Guide
21
http://rest.bioontology.org/resource_index/resources/list/
35
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
de los autores, en Twigger, Geiger, & Smith, (2009), donde se utiliza el OBA
para la anotación de registros del repositorio de datos Gene Expression
Omnibus, o en Jiang, Solbrig, & Chute, (2011), donde se utilizan SNOMED CT
y MedDRA para anotar datos relacionados con los efectos adversos de los
medicamentos en un proceso de construcción de una base de conocimiento
para los mismos.
Uno de los servicios Web de reciente creación, que hace viable la
incorporación de información de salud desde desarrollos propios, es el
desarrollado por la NLM en Septiembre de 2010 para dar acceso a
búsquedas sobre los tópicos de MedlinePlus22. Precisamente una de las
ontologías integradas bajo el OBA es una versión de los tópicos de
MedlinePlus (de Junio del 2008) denominada MedlinePlus Health Topics.
Otro de los servicios Web para desarrolladores que la NLM ofrece
gratuitamente, también publicado como una aplicación Web, es el
denominado MedlinePlus Connect23, que es capaz de devolver información
de salud al hacer consultas a través de los identificadores de SNOMED CT
correspondientes a los términos.
Una fuente de conocimiento general de interés creada recientemente,
accesible a través de servicios, es Freebase24. Freebase aglutina gran
cantidad de información a través de una estructura colaborativa en la que
hay contenidos introducidos por los usuarios que se van normalizando hacia
un estándar, a medida que van cumpliendo algunos requisitos, y otra parte
de los datos almacenados son procesados desde un gran número de
22
http://www.nlm.nih.gov/medlineplus/webservices.html
23
http://www.nlm.nih.gov/medlineplus/connect/overview.html
24
http://www.freebase.com
36
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
fuentes, entre las que se encuentra la Wikipedia o, en el dominio biomédico,
PubMed Central y Medpedia (Rethlefsen, 2009). A pesar de no ser una
ontología formal de conocimiento, la calidad de la información es alta
precisamente por la introducción manual, tal y como se menciona en Han, &
Zhao, (2009), donde se utiliza Freebase para desambiguar nombres por sus
profesiones. Por otro lado, cabe destacar el potencial de la información de la
Wikipedia en el dominio médico, como demuestran proyectos emergentes
como el portal y el Wikiproyecto de Medicina (Heilman et al., 2011).
Freebase está siendo utilizado ampliamente en multitud de aplicaciones,
algunos ejemplos se pueden encontrar en los trabajos relacionados con
utilidades en el marco de la Web semántica, tal y como por ejemplo la
DBpedia de Auer y Bizer (Auer et al., 2007; Bizer et al., 2009), en problemas
de clasificación de consultas (Brenes, Avello, & González, 2009), como
extensiones al geo-etiquetado (Weichselbraun, 2009) o, más recientemente,
para la generación de información que ayude a la interpretación de vídeos
etiquetados (Hildebrand, & van Ossenbruggen, 2012), como base de
conocimiento para un sistema de recomendación (Plumbaum, Lommatzsch,
De Luca, & Albayrak, 2012) o para un almacén de datos moleculares (CruzToledo et al., 2012), entre otros muchos.
Los contenidos de esta base de conocimiento se estructuran basándose en
los denominados Tópicos (Topics), Tipos (Types), Dominios (Domains) y
Propiedades (Properties). Los Tópicos son los que contienen la información
descriptiva asociada a lo que en PLN sería una entidad nombrada, o lo que
se conoce en Wikipedia como un artículo. Parte de la información que
contienen los Tópicos procede, como ya se ha indicado, del procesado de la
información incluida en Wikipedia. La estructura de la ontología
(denominada Schema) se mantiene a través de relaciones semánticas,
37
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
siendo esta una forma adecuada de entender el significado tanto de los
Tipos como de las Propiedades. Los Tópicos mantienen una relación
semántica con los Tipos del modo "es_un" y una relación semántica con las
Propiedades del modo "tiene_una". Estas relaciones permiten que un
mismo Tópico pueda pertenecer a dos Tipos distintos, como sucede por
ejemplo con cáncer. Este tópico puede pertenecer tanto al Tipo enfermedad
(disease) como al Tipo constelación (constellation) o al Tipo signo del
zodiaco (zodiac sign), dado que con los tres Tipos mantiene la relación "el
cáncer es un...". Por otro lado, en Freebase los Tipos se agrupan en
Dominios, representando éstos ámbitos de conocimiento más generales,
tales como serían (siguiendo con el ejemplo anterior) la medicina (Dominio
medicine), la astronomía (Dominio astronomy) o la astrología (Dominio
western astrology). Aquellos dominios que siguen ciertos estándares se
almacenan como los Commons de Freebase, mientras que el resto se
almacenan como Bases. Para el caso del cáncer, cuando se busca la
información asociada para el Tipo enfermedad se encuentra bajo el Dominio
medicina, cuando se busca información asociada con el Tipo constelación
entonces se encontrará bajo el Dominio astronomía, mientras que cuando
se busque información para el Tipo signo del zodiaco se localizará agrupada
en el Dominio astrología. Los dos primeros dominios son clasificados como
Common y el tercero es clasificado como Base. Para localizar la información
concreta de un Tópico, perteneciente a un Tipo que está agrupado en un
determinado Dominio, se utilizan los identificadores correspondientes al
Dominio, seguido del identificador del Tipo. Por ejemplo, el identificador del
Dominio medicina es "/medicine", el de astronomía es "/astronomy" y el de
astrología es "/base/wastrology" (el identificador de los Dominios Common
comienza en el raíz, mientras que el de los Base comienza en /base). De
38
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
manera que el identificador para el Tipo enfermedad del Dominio medicina
es "/medicine/disease", el del Tipo constelación del Dominio astronomía es
"/astronomy/constellation" y el del Tipo signo del zodiaco del Dominio
astrología quedaría "/base/wastrology/astrological_sign". Para recuperar la
información de otros Tópicos relacionados con el que estamos estudiando,
se puede conseguir a partir de las Propiedades agrupadas por cada Tipo. Si,
por ejemplo, se quisiese obtener más información sobre la enfermedad
cáncer, se pueden estudiar las Propiedades agrupadas en el Tipo
enfermedad del Dominio medicina, encontrándose entre ellas los síntomas
(Propiedad symptoms), tratamientos (Propiedad treatments), factores de
riesgo (Propiedad risk factors), causas (Propiedad causes) y otros.
Análogamente se podría hacer para el Tipo constelación del Dominio
astronomía, donde se encuentran Propiedades como estrellas (stars),
constelaciones limítrofes (bordering constellations), lluvias de meteoritos
(meteor showers) o galaxias observadas en esta constelación (galaxies
observed within this constellation). Ya por último, en relación con el estudio
realizado en este trabajo, es interesante mencionar que pueden obtenerse
relaciones asociadas con las Propiedades, dado que la información que
muchas de ellas proporcionan se encuentra alojada bajo uno de los Tipos del
mismo Dominio. Por ejemplo, la Propiedad síntomas asociada al Tipo
enfermedad en el Dominio medicina, se localiza también como un Tipo del
Dominio medicina, disponiendo en consecuencia de su propio identificador
(que es "/medicine/symptom") y poseyendo, a su vez, sus propias
Propiedades, tales como: efecto secundario de (side effect of), síntoma de
(symptom of), incluye síntomas (includes symptoms) y otras.
Uno de los métodos de acceso a la información que provee esta fuente de
información es lo que se denomina MQL - Metaweb Query Language -
39
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
(Meyer, Degener, Giannandrea, & Michener, 2010), disponiéndose para ello
de diferentes APIs de acceso dependiendo del tipo de lenguaje de
programación utilizado. Como herramienta para probar las consultas MQL
Freebase ofrece un editor público25.
Reconocimiento cross lingüe de términos y conceptos
Un tópico que se está investigando recientemente, dentro de las tareas
relacionadas con la recuperación de información cross-lingüe (Federico,
2011), es la utilización de ontologías para, a través de la representación de
los conceptos, poder ofrecer información a los usuarios en diferentes
idiomas. Este tipo de sistemas multilingües y cross-lingües utilizando
ontologías tienen campos de aplicación muy variados, como por ejemplo:
para construir sistemas de consultas en los que los usuarios utilizan un
idioma y el buscador devuelve los resultados, obtenidos en otros idiomas,
en el idioma del usuario (Embley, Liddle, Lonsdale, & Tijerino, 2011); como
elemento clave para la clasificación multilingüe de textos (Melo, &
Siersdorfer, 2007); en el proceso de expansión de consultas (ver, por
ejemplo, Bhogal, Macfarlane, & Smith, 2007); para facilitar la evolución de la
Web semántica hacia un escenario multicultural y multilingüe (Gracia,
Montiel-Ponsoda, Cimiano, Gómez-Pérez, Buitelaar, & McCrae, 2012).
Uno de los aspectos más importantes a resolver a la hora de generar
ontologías monolingües y multilingües, es el alto coste de desarrollo que
requieren. Esta tarea se está afrontando desde diferentes puntos de vista,
como son la traducción automática de la ontología en otros idiomas para
posteriormente hacer un mapeo entre ellas (analizada en Fu, Brennan, &
25
http://www.freebase.com/queryeditor
40
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
O’Sullivan, 2009), usando métodos estadísticos (aplicados a las relaciones
entre los conceptos y sus propiedades) que tienen como objetivo mejorar la
traducción automática (McCrae, Espinoza, Montiel-Ponsoda, Aguado-deCea, & Cimiano, 2011), simplificando el modelo estructural de las ontologías
con nuevos elementos que faciliten la extensión a otros idiomas (Segev, &
Gal, 2008), a través de la creación de algoritmos que permitan la extracción
automática de relaciones entre entidades desde documentos de un
determinado dominio (e.g. Choi, Rho, Jeong, & Kim, 2011), o generando
herramientas que faciliten la creación y modificación de las ontologías
(Sellami, Camps, Aussenac-Gilles, & Rougemaille, 2011) y la inclusión de
contenido multilingüe a partir de datos monolingües (Espinoza, GómezPérez, & Mena, 2008).
Otro tópico que ha emergido recientemente, directamente relacionado con
el reconocimiento cross-lingüe de entidades nombradas, es el denominado
enlazado cross-lingüe de entidades (cross-language entity linking). El
objetivo principal de este tipo de tareas es el de localizar la información más
adecuada sobre un conjunto de entidades presentes en una fuente de
conocimiento, permitiendo así realizar automáticamente operaciones como
el enriquecimiento de datos de las entidades que aparecen en las fuentes de
conocimiento. El planteamiento que se está haciendo en diferentes
iniciativas que están abordando la tarea a través de competiciones (como
por ejemplo, desde el 2009 las conferencias de análisis de texto del NIST,
TAC26) es el siguiente: dados un conjunto de entidades en una determinada
fuente de conocimiento (en el TAC del año 2011, KBP2011, la fuente de
conocimiento es una ontología y las entidades son personas, organizaciones
26
http://www.nist.gov/tac/
41
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
y lugares) y dados un conjunto de documentos de texto, se deben crear y
rellenar con contenidos nuevos los nodos de estas entidades a partir de la
información que aparece en el texto desestructurado de los documentos.
Este enfoque es muy similar al objetivo del NCBO mencionado
anteriormente (Shah, Bhatia, Jonquet, Rubin, Chiang, & Musen, 2009). La
creación de corpus cross-lingües para la evaluación de estos sistemas es
realmente reciente. En Mayfield, Lawrie, McNamee, & Oard, (2011), por
ejemplo, se genera una colección en 21 idiomas en un proceso que reconoce
los nombres de personas y los anota con un sistema de enlazado de
entidades en inglés que, apoyado en la intervención humana y un proceso
de crowd-sourcing, proyecta estos nombres a otros idiomas. Tal y como se
menciona en McNamee, Mayfield, Lawrie, Oard, & Doermann, (2011), el
enlazado de entidades se puede comprender como un método para la
resolución de entidades nombradas híbrida de otras dos tareas: la
resolución de identidades (identity resolution) y la resolución de
correferencias
(correference
resolution).
La
primera
se
encarga
principalmente de localizar registros estructurados o semi-estructurados
que se refieren a la misma entidad, mientras que la segunda se encarga de
hacerlo a partir de descripciones desestructuradas que aparecen en el
mismo texto o en textos distintos (cross-document reference resolution). En
esta misma publicación se presenta una aproximación para llevar a cabo el
enlazado cross-lingüe de entidades, que se divide en dos fases
fundamentales: la identificación de candidatos y la clasificación de los
mismos (fase en la que se realiza la diferenciación para los diferentes
idiomas). Otras aproximaciones para resolver el problema, obteniéndose
buenos resultados, están basadas en diccionarios estáticos que asocian a
diferentes tópicos la misma URL (Spitkovsky, & Chang, 2011). Este enfoque
42
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
es muy similar al seguido por el sistema biomédico implementado en esta
tesis donde, a partir de un conjunto de listas en diferentes idiomas el
sistema es capaz de proponer la misma URL para diferentes tópicos en dos
idiomas distintos. Sin ser el objetivo del modelo el abordar el problema del
enriquecimiento de datos de las fuentes de conocimiento, sí que se
considera que su estructura es apta para dar soporte a este tipo de tareas.
Además, experiencias próximas en el ámbito educativo utilizando escenarios
de aplicación bilingües (Clark, Touchman, Martinez-Garza, Ramirez-Marin, &
Skjerping Drews, 2012), parecen plantear un horizonte interesante y poco
explorado para facilitar la comprensión de la materia estudiada y, al mismo
tiempo, mejorar el idioma no nativo de los estudiantes.
3. Visión general del modelo de sistema propuesto
Motivación
En la primera sección del capítulo 1, se ha revisado la problemática del
distanciamiento entre los conocimientos teóricos y las aplicaciones prácticas
en el conocimiento humano, en general, y en las ciencias de la salud, en
particular, que pone de relieve la necesidad de desarrollo de nuevas
herramientas bioinformáticas que simplifiquen y faciliten la obtención de
información a la comunidad biomédica, a partir de las ingentes cantidades
de información (tanto fiables como no fiables) disponibles en Internet.
Estructurar toda esta información de manera que se pueda consultar a
través del lenguaje natural, asegurando la fiabilidad del contenido, es uno
de los esfuerzos principales en computación desde hace varias décadas. Sin
embargo, más que la creación de nuevas técnicas de PLN, minería de texto,
extracción o recuperación de información, uno de los papeles principales de
43
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
la bioinformática, en su objetivo de mejorar la traslación multidisciplinar del
conocimiento, consiste en ir aplicando las técnicas disponibles, derivadas de
los avances computacionales que se van produciendo, en sistemas de ayuda
a la decisión sobre casos clínicos y otras tareas que tiendan a proporcionar
el marco adecuado para conseguir una práctica médica de máxima calidad,
tendiendo cada vez más hacia una medicina personalizada. En este esfuerzo
por extraer y personalizar los diferentes tipos de información heterogéneas
disponibles en Internet, se pueden aprovechar los avances producidos en el
desarrollo de la Web semántica y de las estructuras estándar generadas
para almacenar y reutilizar computacionalmente los datos y su contenido
semántico.
El desarrollo de sistemas de acceso inteligente a la información que,
empleando diferentes técnicas de PLN y minería de texto, hagan uso de las
fuentes de conocimiento biomédico disponibles a través de servicios Web,
aprovechando la disponibilidad de información orientada a dar respuesta a
usuarios con diferentes perfiles (tal y como se menciona en la segunda
sección del capítulo 1), puede ayudar a solventar las principales dificultades
con las que se encuentran estos usuarios al afrontar búsquedas complejas
de información en el ámbito de la salud (más allá de una búsqueda por
término).
A pesar de que las disciplinas de PLN y minería de textos están siendo
ampliamente estudiadas y desarrolladas desde hace varias décadas, dando
lugar a gran cantidad de aplicaciones exitosas que dan solución a problemas
computacionalmente cada vez más complejos, existen todavía retos
importantes por superar.
Por un lado, una de las grandes limitaciones de estos sistemas de
procesamiento automático consiste en que, a pesar de sus evolucionadas
44
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
capacidades lingüísticas (o precisamente por ellas), no se utilizan y evalúan
con usuarios finales de forma sistemática. Un ejemplo de referencia a lo
largo de esta investigación son las extraordinarias herramientas
desarrolladas por el NCBO, analizadas en los dos primeros apartados de la
segunda sección de este segundo capítulo, en los que uno de los focos de la
investigación se pone en los tiempos de respuesta (prioritarios para la
construcción de sistemas orientados a usuarios finales) y en evaluaciones
que miden los valores clásicos de precisión y la cobertura. Esta carencia ha
dirigido esta investigación hacia el estudio de un contexto novedoso de
evaluación con usuarios para este tipo de sistemas, tal y como es el marco
educativo y las actividades de aprendizaje activo en educación superior que
se describen en la tercera sección del capítulo 1. La puesta en marcha del
proceso de evaluación ha motivado no sólo el desarrollo de un método para
la valoración cuantitativa del sistema biomédico implementado, sino
también el diseño de una experiencia de aprendizaje adecuada para
estudiantes y profesores.
Por otro lado, la especificidad de muchas de las herramientas existentes en
cuanto a los idiomas con los que se procesa la información, está tratándose
de superar a través de mecanismos de almacenamiento adaptados a la
realidad global en la que nos encontramos, cuestión que se ha analizado en
el tercer apartado de la segunda sección de este capítulo 2. Esto ha
provocado un interés creciente en tareas de procesamiento clásicas sobre
las que incorporar escenarios de aplicación multilingües y cross-lingües,
abriéndose también nuevos horizontes en el marco de evaluación con
estudiantes.
45
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
Objetivos
El modelo de sistema propuesto en esta tesis no tiene como objetivos
iniciales el competir en cuestiones como la complejidad computacional de
los algoritmos lingüísticos, la cantidad de ontologías, dominios e
información preprocesados, en relación a los sistemas presentados para
reconocer y extraer conceptos en la sección anterior. Precisamente se ha
considerado que la complejidad computacional de estos sistemas, la
cantidad de resultados y recursos ofrecidos, además del aumento
progresivo de los tiempos de respuesta (al ir incrementando el
conocimiento incorporado desde diferentes dominios), es un problema a
resolver cuando se desea que el sistema sea utilizado por diferentes tipos de
usuarios. Más allá del aumento en precisión y cobertura, cuestión que van
resolviendo estas potentes herramientas de gran complejidad algorítmica
con el paso del tiempo, hay otros factores fundamentales que deberían
tenerse en cuenta, tales como por ejemplo: (i) la percepción que tienen los
usuarios del sistema para mejorar la compresión del texto sobre el que se
encuentran trabajando; (ii) la percepción sobre aspectos clave en relación a
la usabilidad de la herramienta; (iii) la aplicabilidad a actividades concretas
del sistema, que permitan disponer de un marco adecuado para el
desarrollo
de
otros
sistemas
que
vayan
incluyendo
los
logros
computacionales, manteniendo su aplicabilidad; (iv) las posibilidades de
modificar el dominio de aplicación; (v) o las capacidades de procesamiento
de recursos multilingües, además de la creación de herramientas crosslingües que intercalen el conocimiento procedente de fuentes de
conocimiento en diferentes idiomas, utilizando otros criterios más allá del
lenguaje en el que se hayan escrito.
46
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
El objetivo general de este trabajo es el de desarrollar un modelo con el
potencial de dar soporte a un amplio espectro de tareas de procesamiento
ofreciendo estos servicios a clientes. Por ello, se ha puesto especial énfasis
en la construcción de un modelo de arquitectura de software escalable, en
relación a varios aspectos fundamentales:
i.
La aplicabilidad del modelo a otros dominios de conocimiento.
ii.
Una escalabilidad relacionada con los mecanismos de acceso al
sistema, es decir, se ha creado un esquema modular que permite
albergar:
a. Por un lado, componentes que posibiliten el acceso desde
diferentes clientes, tales como serían aplicaciones de
escritorio, servicios Web para la interacción máquinamáquina, interfaces Web orientadas a usuarios o acceso
desde otros dispositivos.
b. Por otro lado, la incorporación de nuevas fuentes de
información con las que enriquecer el soporte a diferentes
perfiles de usuario.
iii.
Una escalabilidad relacionada con las técnicas de preprocesado,
facilitando la integración de nuevas fuentes para la extracción de
conocimiento en los documentos procesados.
iv.
La incorporación de nuevas técnicas o librerías para el
procesamiento del texto.
Para demostrar la aplicabilidad del modelo, se cristalizará en el desarrollo de
un sistema inteligente aplicado a un dominio particular, como es el dominio
biomédico, dando servicio a dos tipos de clientes:
47
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
1. Usuarios finales: El objetivo de este interfaz es el de proporcionar
información sobre algunos tipos de conceptos médicos presentes en
un texto clínico de entrada, ayudando a los usuarios a profundizar
en la comprensión de su contenido a través de la integración de
fuentes cuyos datos están orientados a diferentes perfiles,
utilizando un lenguaje más divulgativo y fácil de entender (como es
el caso de la información procedente de Freebase o MedlinePlus) o
más orientado a expertos (tal y como sucede con las publicaciones
científicas obtenidas de PubMed). Para lograrlo, inicialmente se
extraen del texto un conjunto de términos a partir de las fuentes de
conocimiento
previamente
preprocesadas
(i.e.
Freebase,
MedlinePlus y SNOMED-CT, en español y en inglés) y de otras
integradas a través de servicios (con el servicio OBA), eliminándose
información redundante y simplificándose la complejidad de los
resultados obtenidos a partir de la tarea de reconocimiento,
ofreciéndolos en un formato unificado. A continuación el usuario
puede emplear un conjunto de enlaces proporcionados para cada
uno de los términos, recuperando información sobre otros
conceptos semánticamente relacionados e información descriptiva
tanto de los extraídos inicialmente como los semánticamente
relacionados.
2. Otras utilidades informáticas: El objetivo de este interfaz es el de
proveer de toda la información extraída del texto en un formato
unificado y tratable desde otras utilidades informáticas. Para ello, se
proporcionan un número mayor de opciones de procesado, más
ontologías y alternativas más avanzadas en cuanto a la detección de
conceptos, sin eliminar ninguna de las anotaciones (que para un
48
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
usuario final sería información redundante), dado que podrían ser
de interés para, por ejemplo, un sistema de anotación que
pretendiese ubicar en el texto origen cada uno de los conceptos.
El esfuerzo de desarrollo se concentra, por tanto, en cuestiones como la
integración, la usabilidad, la respuesta en línea del sistema y la posibilidad
de tratamiento de textos multilingües proporcionando fuentes de
información cross-lingüe. Esto dirige el objetivo de evaluación del modelo
hacia usuarios finales y la medición de los tiempos de respuesta, más que en
otras métricas como la precisión o la cobertura, que pueden ser resueltas a
través del proceso de integración.
Para cubrir los objetivos de evaluación se llevarán a cabo, por un lado, un
conjunto de pruebas sistemáticas sobre los tiempos de respuesta y, por otro
lado, una experiencia de evaluación con estudiantes de medicina sobre los
que se valorarán diferentes aspectos de la herramienta en cuanto a su
usabilidad y, dado el ámbito educativo para el que se ha preparado el
interfaz, en cuanto a su soporte al poner en práctica actividades de
aprendizaje en el aula. La preparación de la actividad de aprendizaje
conllevará simplificaciones adicionales que mejoren la facilidad de uso para
los estudiantes, de acuerdo con las indicaciones proporcionadas por los
profesores de medicina encargados de conducir la experiencia con los
estudiantes: la extracción de conceptos se realiza a partir de la fuente
preprocesada Freebase y del servicio integrado OBA con la ontología
MedlinePlus Health Topics, mostrándose al usuario el conjunto de términos
que aparecen explícitamente en el texto indicándose su origen (la fuente de
conocimiento a partir de la que han sido detectados) y el tipo de concepto
49
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
(i.e., enfermedad, síntoma, tratamiento o concepto de MedlinePlus),
manteniéndose el resto de funcionalidades.
Arquitectura del modelo
De forma general, las tareas llevadas a cabo por los sistemas de minería de
textos se pueden dividir según un esquema general (Feldman, & Sanger,
2007) en el que el sistema realiza operaciones bien distinguibles, tales como
son: aquellas relacionadas con el preprocesado de los datos (donde se
prepara la información original antes de aplicar los algoritmos de
extracción); las relacionadas con el núcleo de las tareas de minería de textos
y procesamiento del lenguaje natural (descubrimiento y comparación de
patrones, agrupamiento, integración con otras fuentes de conocimiento,
etc.); las encargadas de mostrar la información y permitir las búsquedas
(dando acceso a través de un GUI); y, por último, las técnicas de posprocesado (que eliminan información redundante, agrupan resultados
relacionados, etc.).
En el modelo de sistema propuesto, existe un paralelismo entre cada uno de
estos elementos y las funcionalidades asociadas con los módulos en los que
se divide su arquitectura. Cada módulo aglutina un conjunto de
componentes, que son los encargados de asegurar la escalabilidad de las
funcionalidades asignadas a cada uno de los módulos. Así mismo, el sistema
completo podría formar parte de una arquitectura mayor en la que, a través
de los mecanismos de acceso, diese soporte como un módulo desde el que
se realizaría alguna tarea concreta.
La implementación del modelo en un caso particular de dominio, tal y como
es el dominio biomédico, y su evaluación, a través de las experiencias de
aprendizaje con usuarios del dominio, han permitido comprobar las
50
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
bondades de este método para el desarrollo de nuevos sistemas inteligentes
que sigan este mismo modelo o la ampliación de funcionalidades de otros ya
existentes.
La arquitectura del modelo propuesto se apoya en el diseño de un conjunto
de módulos cuyo objetivo principal es el de facilitar la integración de
distintos componentes, que permitan la escalabilidad del sistema (una vez
desarrollado para el dominio particular) en todos los niveles ya
mencionados, así como su integración con otros sistemas. Para lograrlo, se
han definido los siguientes módulos:
a. Módulo de Recuperación y Preprocesado de Datos (RPD): Es un
módulo pensado para realizar las tareas de recuperación de datos y
el preprocesado de la información a partir de diferentes fuentes de
conocimiento. Este tipo de tareas se llevarán a cabo en un hilo de
ejecución diferente al resto de los módulos, que funcionarán en
tiempo de ejecución haciendo uso de la información recuperada.
Cada uno de sus componentes asume la gestión de recuperación,
preprocesado y almacenamiento a partir de una determinada
fuente de conocimiento.
b. Módulo de Procesamiento de Lenguaje Natural (PLN): Es el módulo
dedicado a procesar los textos en lenguaje natural enviados al
sistema. En él se aplican, a través de cada uno de sus componentes,
las diferentes técnicas y algoritmos de minería de texto haciendo
uso de la información recuperada por el módulo RPD, se llevan a
cabo las comunicaciones con servicios externos de procesado
(reconocimiento, extracción y anotación de conceptos) y la
integración de toda la información recopilada. Este módulo, por
tanto, se nutre de los datos preprocesados y los datos
51
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
proporcionados por los servicios Web externos para dar servicio en
línea (es decir, en el mismo hilo de ejecución que utiliza el usuario),
a través del módulo de acceso, que se explica en el punto d.
c. Módulo de Búsqueda y Enlace de Entidades (BEE): Está compuesto
por el conjunto de componentes que permiten al sistema dar acceso
a información relacionada con los diferentes términos y conceptos
extraídos, a través del módulo PLN, procedente de las diferentes
fuentes de conocimiento integradas con este fin. Cada uno de sus
componentes se encarga, en consecuencia, de gestionar la
búsqueda de conceptos relacionados con los términos y conceptos
extraídos desde una fuente de conocimiento, así como de ofrecer
información enriquecida de los mismos. La información enriquecida
permite, por ejemplo, hacer uso de la información semántica para la
localización de conceptos que no están explícitamente en el texto
procesado, constituyendo así un elemento híbrido (ya que se lleva a
cabo a través de la interacción del cliente) con el que extraer
conocimiento no explícito del texto, siendo posible, al mismo
tiempo, dar este servicio a los usuarios en línea. Este módulo puede
jugar el papel de puente entre la extracción directa de términos y la
extracción de conceptos, ayudando a que el proceso sea
suficientemente eficiente como para ofrecer el servicio en línea, en
caso de ser necesario.
d. Capa de Acceso a la Información (CAI): Agrupa todo el conjunto de
elementos o mecanismos que ofrecen acceso al sistema a los
diferentes clientes, ya sea para dar servicio a usuarios humanos
como a utilidades que procesen la información de forma
automática. Cada uno de sus componentes constituye un interfaz
52
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
entre el exterior del sistema y los módulos de PLN y BEE, como
serían, por ejemplo, el acceso para usuarios finales a las
funcionalidades del sistema a través de un navegador Web, el
acceso a usuarios finales a través de una aplicación de escritorio, el
acceso a usuarios finales a través de un dispositivo móvil o el acceso
al sistema a través de un servicio Web para su uso desde una
utilidad instalada en otro servidor.
F.C. 1
F.C. 2
...
F.C. N
S.E. 1
S.E. 2
...
S.E. N
F.C. 1'
F.C. 2'
C. 1
C. 2
...
C. N
C. 1'
C. 2'
...
C. N'
C. 1
C. 2
... F.C. N'
...
C. N
...
C. N'
C. 1
MÓDULO RPD
MÓDULOS
C. 2
MÓDULO PLN
MÓDULO BEE
...
C.I.I.
C. 1'
C. N
MÓDULO CAI
C. 1
C. 2
C. N
C. 1'
C. 2'
...
C. N'
EXTRACCIÓN
INFORMACIÓN
ENVIADO AL
DE
SEMÁNTICA Y
SISTEMA
CONCEPTOS
DETALLADA
TEXTO
FLUJO DE USUARIO
...
C. 2'
Figura 1 Arquitectura del modelo de sistema.
Siendo: {C. 1.,..., C. N, C. 1',..., C. N'} = Componentes constituyentes de los módulos; C.I.I. =
Componente de Integración de Información; F.C. = Fuente de conocimiento; S.E. = Servicio
Externo
53
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
Elementos de los módulos
En la Fig. 1 se puede encontrar el esquema general de la arquitectura del
modelo propuesto, así como los flujos de información generados al
producirse la interacción con el usuario, ya sea un sistema automático o un
usuario humano. Los elementos {C. 1.,..., C. N, C. 1',..., C. N'} representan los
diferentes componentes constituyentes de cada uno de los módulos del
sistema. En el caso del módulo RPD, cada uno de los componentes del
módulo representa un algoritmo capaz de conectarse con una determinada
fuente de conocimiento {F.C. 1,..., F.C. N}, para preprocesar los datos en el
formato que requiera el módulo PLN. Los componentes {C. 1,..., C. N} del
módulo PLN representan aquellos que se encargan precisamente de hacer
esta tarea, es decir, utilizar los datos preprocesados por el módulo RPD para
aplicar los diferentes algoritmos de procesamiento sobre el texto
introducido en el sistema a través del módulo CAI. Los componentes {C.
1',..., C. N'} del módulo PLN tienen otra finalidad, esto es, con ellos se
pretende disponer de un conjunto de elementos que sean capaces de
utilizar los servicios externos {S.E. 1,..., S.E. N} que realicen operaciones
algorítmicas similares (i.e. extracción de conceptos a partir de texto en
lenguaje natural), utilizándose el componente de integración de información
C.I.I. para fusionar los resultados procedentes del procesado de cada uno de
los componentes (tanto de los que acceden al módulo RPD como de los que
acceden a los servicios externos). Este componente C.I.I. es el elemento
encargado de la comunicación con las diferentes interfaces desarrolladas en
el módulo CAI, cuyo objetivo es el de proveer a los potenciales clientes de
un interfaz desde el que introducir el texto que se desea procesar,
habiéndoseles denominado componentes {C. 1,..., C. N}. Los componentes
54
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
{C. 1,..., C. N} en el módulo BEE tienen como objetivo la comunicación con
las fuentes de conocimiento {F.C. 1',..., F.C. N'} utilizadas para realizar las
búsquedas sobre los términos y conceptos extraídos por el módulo PLN,
siendo también las encargadas de gestionar la recuperación de información
ampliada sobre los mismos (incluyendo información detallada y otros
conceptos relacionados semánticamente). El otro conjunto de componentes
de este módulo BEE, denominados {C. 1',..., C. N'}, sirven de interfaz de
acceso con el módulo CAI, a través de los componentes con el mismo
nombre y que son utilizados para proveer, a los diferentes tipos de usuario,
del interfaz de búsqueda adecuado (por ejemplo, para un servicio Web el
usuario sería un cliente que necesitaría un formato apropiado para el
tratamiento automático de los resultados, tal y como sería el formato XML o
el JSON, mientras que para mostrar los resultados en un navegador el
formato apropiado sería HTML).
En la parte inferior de la Fig. 1 se muestra el flujo de interacción del usuario
con el sistema. En primer lugar, es necesario que el usuario o cliente del
sistema envíe el texto para su procesado. Esta petición será recogida,
procesada y resuelta por el módulo PLN, a través del ya mencionado C.I.I.,
que proporcionará al cliente los resultados fusionados resultantes del
procesado tanto de los servicios externos como de los componentes que
hacen uso de los datos preprocesados. A continuación, el cliente puede
obtener información de conceptos resultantes de las búsquedas en las
diferentes fuentes, haciendo peticiones al módulo BEE a través del módulo
CAI, en las que se identifica adecuadamente el concepto por el que se
consulta. Además, a través de estas búsquedas el cliente puede obtener
información detallada sobre los conceptos extraídos y sobre otros
relacionados semánticamente, sobre los que podrá volver a consultar al
55
MODELO PARA LA EXTRACCIÓN DE CONCEPTOS
sistema para obtener más información. En cualquiera de los pasos, el
sistema puede devolver al cliente enlaces a diferentes fuentes de
conocimiento externo, que le permitirían ampliar la información sobre los
conceptos obtenidos.
56
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
CAPÍTULO 3. EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE
INFORMACIÓN BIOMÉDICA.
El sistema biomédico desarrollado utiliza el software GATE27 (General
Architecture for Text Engineering) para reconocer las entidades médicas
nombradas en el texto, tras ser introducido en el sistema por el cliente.
Además, se ha integrado el servicio externo de anotación con ontologías
biomédicas del NCBO (OBA) descrito en el capítulo anterior. La utilización de
GATE requiere el preprocesado de información procedente de fuentes de
conocimiento externo, almacenándose esta información en el entorno local
del sistema, mientras que el procesado con el servicio externo necesita la
interacción a través del protocolo HTTP. Tanto el preprocesado de la
información desde las fuentes Freebase, MedlinePlus y SNOMED CT, como
el proceso de anotación remoto se describen en la primera sección de este
capítulo. En la segunda sección, se describirán los mecanismos empleados
para vincular las entidades nombradas extraídas con contenidos
informativos y otros conceptos relacionados semánticamente, procedentes
en este caso de Freebase, MedlinePlus y PubMed. En la tercera sección del
capítulo se describen los dos mecanismos de acceso incluidos en el sistema.
1. Reconocimiento de entidades médicas
Para el reconocimiento de las entidades médicas nombradas en el texto
introducido en el sistema, se han utilizado dos mecanismos:
i.
El componente Gazetteer del sistema ANNIE que viene incluido
en la distribución de GATE. El uso de este módulo requiere el
27
http://gate.ac.uk
57
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
pre-procesado de los términos (formados por una o varias
palabras) que se desean utilizar para realizar la tarea de
reconocimiento de entidades. El componente Gazetteer utiliza
estos términos para anotar el texto de entrada, haciendo uso de
ellos a partir de listas que previamente han tenido que ser
definidas y generadas.
ii.
El servicio de anotación con ontologías del NCBO.
Anotación con GATE
El software GATE permite la utilización de su propio GUI (instalada como
una aplicación de escritorio), para posteriormente almacenar el proceso
generado (denominado Pipeline) en un fichero de aplicación (cuya extensión
es gapp), que puede utilizarse desde un programa Java y ser ejecutado a
través de un servidor Web, tras instalar adecuadamente todas las librerías
requeridas. Este procedimiento favorece la versatilidad del proceso de
desarrollo, ya que antes de ejecutar la aplicación a través del navegador o
de la aplicación Java, es posible comprobar los resultados del proceso
elaborado desde el GUI con listas de conceptos y los corpus de documentos.
Tal y como se ha mencionado anteriormente, es necesario definir las listas
de términos que van a ser utilizadas por el módulo Gazetteer. Para ello se
crea un fichero con extensión “.def”, que se ha denominado “medicine.def”.
Este fichero hace referencia a las diferentes listas de conceptos, con el
formato que se presenta a continuación:
diseaseen.lst:Freebase:disease:en
symptomen.lst:Freebase:symptom:en
treatmenten.lst:Freebase:treatment:en
mlpen.lst:MedlinePlus:medlineplus:en
scten.lst:Snomed:snomed:en
diseasesp.lst:Freebase:disease:sp
58
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
symptomsp.lst:Freebase:symptom:sp
treatmentsp.lst:Freebase:treatment:sp
mlpsp.lst:MedlinePlus:medlineplus:sp
sctsp.lst:Snomed:snomed:sp
Cada línea del fichero se refiere a una lista de términos. El separador “:”
identifica, como primer dato, el nombre del fichero que contiene la lista de
términos pre-procesada. Los dos datos siguientes son propiedades
denominadas “mayor” (major) y “menor” (minor), que se pueden utilizar
para almacenar información sobre diferentes características que aparecerán
posteriormente en la anotación generada. El último dato es el idioma,
también utilizado como característica de la anotación.
El formato de los ficheros que contienen las listas de términos es como se
explica a continuación. Una vez elegido un carácter separador (como por
ejemplo “&”, que es el que se ha utilizado) cada fila representa los datos
relacionados con un término, almacenándose en cada una de las filas tanto
el término como todas aquellas características de las que se desee poseer
información tras el proceso de anotación (utilizando el separador para
diferenciarlas). Cada una de las características se representa igualando el
nombre de la característica al valor, agregándose a las generales major,
minor e idioma.
Para la obtención de los conceptos que forman las listas se han utilizado las
fuentes Freebase, MedlinePlus y SNOMED-CT.
Extracción de la terminología bilingüe desde Freebase
Para usar la información contenida en esta base de conocimiento, se ha
comenzado por localizar el Dominio de interés: medicine. Una forma de
59
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
obtener con una consulta MQL todos los Dominios de Freebase se muestra
en la Tabla 1.
Tabla 1. Consultas MQL para la recuperación de los Dominios de Freebase.
COMMONS
[{
"id": null, "name": null, "type": "/type/domain",
"key": [{ "namespace": "/" }]
}]
BASE
[{
"id": null, "name": null, "type": "/type/domain",
"key": [{ "namespace": "/base" }]
}]
A continuación se han estudiado los Tipos que podrían agrupar los tópicos
de interés para la anotación del sistema, siempre teniendo en cuenta la
relación que mantienen los Tipos y los Tópicos: "el Tópico es_un Tipo". Para
analizar la estructura de los datos de Freebase de este modo, existe la vista
denominada Schema28 (es decir, la vista de la estructura que tiene la
ontología), donde se puede localizar fácilmente el Dominio y visualizar los
Tipos que agrupa. En la Tabla 2 se muestran los Tipos agrupados bajo el
Dominio medicine (a fecha de Enero 2012), ordenados por el número de
Tópicos incluidos en cada Tipo.
Tabla 2. Tipos de Freebase pertenecientes al Dominio medicine y número de Tópicos
asociados a estos Tipos, ordenados de mayor a menor.
TIPOS
ICD-9-CM Classification
Disease or medical condition
Hospital
Drug
Medical Treatment
Anatomical structure
Physician
Symptom
Risk Factor
Public figure with medical condition
Disease cause
Surgeon
28
TÓPICOS
10.152
9.471
5.022
3.918
3.727
2.908
2.209
1.446
1.037
1.034
673
357
http://www.freebase.com/schema
60
TIPOS
Cancer Center
Hormone
Bone
Ligament
Condition prevention factors
Medical trial
Drug legal status
Biofluid
Drug administration route
Medical trial sponsor
Vaccine
Medical trial design
TÓPICOS
64
63
56
55
53
38
34
33
23
22
19
17
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Diagnostic Test
Infectious Disease
Muscle
Artery
Nerve
Brain Structure
Disease Stage
Cancer Center Constituent
Vein
Drug class
Medical specialty
Drug brand
Cranial nerve
268
256
252
237
205
204
186
147
133
110
109
84
83
Contraindication
Drug pregnancy category
Medical device
Route of infection transmission
Disease vector
Medical trial health authority
Type of infectious agent
Vaccine Developer
Hospital Ownership Status
Medical trial phase
Diagnostic Sign
Cancer Center Type
Medical trial type
13
11
8
8
8
6
5
5
4
4
3
2
2
A continuación se ha revisado la información semántica de los Tipos con
mayor número de instancias y de interés para esta investigación, siempre
teniendo en cuenta la relación de los Tópicos con las Propiedades: "el
Tópico tiene_un/a Propiedad".
Tabla 3. Información semántica asociada a los Tipos de Freebase más apropiados y con
mayor número de Tópicos.
TIPO
ICD-9-CM
Classification
Disease or medical
condition
PROPIEDADES
TIPO
Code
Includes classifications
Parent Classification
Risk Factors
Symptoms
Treatments
Causes
Stages
Survival Rates
ICD-9
ICD-10
ICD-O
DiseasesDB
Medline plus
eMedicine
MeSH ID
OMIM
Affiliated diseases
Prevention factors
Trials
Includes Diseases
Parent Disease
Associated medical
specialties
Drug
Medical
Treatment
PROPIEDADES
Pronunciation
ATC Code
Drugbank
Pubchem
CAS Number
Drug class
Brands
Route of administration
Pregnancy category
Legal status
Side effects
Contraindications
Trials
Used To Treat
Anatomical
structure
-
Symptom
ICD-9
ICD-10
DiseasesDB
Medline plus
eMedicine
MeSH ID
Symptom of
Side effect of
Includes symptoms
61
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Notable people with this
condition
Tests
Parent Symptom
Risk Factor
Diseases with this Risk
Factor
En la Tabla 3 se muestran las Propiedades asociadas a los 7 Tipos más
poblados del Dominio médico, a excepción de Hospital y Physician dado que
la información que contienen no es de interés para este estudio.
De estos Tipos finalmente se han descartado ICD-9-CM Classification, Drug y
Anatomical structure tras el análisis de la información semántica asociada a
través de sus Propiedades, ya que es a través de este tipo de datos y del
artículo de Wikipedia vinculado al Tópico con los que se forma la
información detallada sobre el término extraído del texto. Además, se ha
tenido en cuenta que, a pesar de que cualquiera de estos siete Tipos puede
considerarse de interés para un etiquetado que permita mejorar la
comprensión de un caso clínico, sólo Disease or medical condition, Medical
Treatment y Symptom poseen una relación circular a través de las
Propiedades Treatment y Symptoms de la primera (relacionándola con la
segunda y la tercera, respectivamente), a través de Side effect y Used to
treat de la segunda (relacionándola con la tercera y la primera,
respectivamente) o a través de Symptom of y Side effect of (relacionándola
con la primera y la segunda, respectivamente). La relación circular entre los
Tipos y las Propiedades permite que, por un lado, la presentación de todos
los contenidos semánticos se pueda centralizar a través del sistema (sin
necesidad de enlazar con contenidos externos) y, por otro lado, limitar la
cantidad de relaciones a manejar por el usuario. El Tipo Risk Factor carece
62
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
de información semántica salvo la que lo relaciona con la enfermedad, por
lo que se selecciona como Tipo de interés para dar información adicional
pero no para el etiquetado.
Tabla 4. Tipos, Propiedades e Identificadores de Freebase seleccionados.
TIPOS
PROPIEDADES
Risk Factors
Disease or medical condition Symptoms
Medical treatment
Symptom
Risk factor
FREEBASE_TYPE_ID
/medicine/risk_factors
/medicine/symptom
Treatments
/medicine/medical_treatment
Side effects
/medicine/symptom
Used To Treat
/medicine/disease
Symptom of
/medicine/disease
Side effect of
/medicine/medical_treatment
Diseases with this Risk Factor /medicine/disease
En la Tabla 4 se muestran los identificadores de Freebase asociados con los
Tipos a los que corresponden cada una de las Propiedades (columna de la
derecha), así como los tipos a los que pertenecen estas Propiedades
(columna de la izquierda). Estos identificadores se utilizarán para la
recuperación de los nombres de los Tópicos. En concreto, para la obtención
de los nombres de los Tópicos pertenecientes a los Tipos Disease or medical
condition, Treatment y Symptom, se han construido consultas MQL que
siguen el patrón mostrado en la Tabla 5.
Tabla 5. Patrón de consulta MQL utilizada para la recuperación de los tópicos.
CUERPO
ENVOLTORIO
[{
"type": FREEBASE_TYPE_ID, "name~=":"*",
"id":null, "name":null, "optional":false, "sort":"name", "limit": LÍMITE
}]
"page": PÁGINA,"cursor": true, "lang": "/lang/LANG"
En estas consultas se hace uso de los identificadores de Freebase
(FREEBASE_TYPE_ID):
63
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
1. Para el Tipo Disease or medical condition el identificador es
"/medicine/disease".
2. Para
el
Tipo
Medical
Treatment
el
identificador
es
"/medicine/medical_treatment".
3. Para el Tipo Symptom el identificador es "/medicine/symptom".
Para la obtener la totalidad de Tópicos de cada uno de los Tipos, se
parametriza el límite de resultados y se van obteniendo todas las páginas
(haciéndose uso del envoltorio de la consulta, ver Tabla 5). Además, se ha
agregado una cláusula para recogerlos ordenados alfabéticamente. Para
averiguar el número de términos (nombres de tópicos) de un determinado
Tipo existentes en un momento determinado en Freebase, se puede utilizar
una consulta MQL que sigue el patrón mostrado en la Tabla 6. Este patrón
permite hacer el recuento de aquellos conceptos que contengan un artículo
de la Wikipedia asociado (cambiando la cláusula "optional":true a
"optional":false). Por ejemplo, el 16 de febrero de 2012, el número de
conceptos cambia significativamente si sólo se recogen aquellos nombres
que contengan un artículo (de 9.478 a 5.653). Esto mismo se puede aplicar a
la imagen asociada (utilizando el identificador "/common/topic/image" de
modo análogo al identificador del artículo "/common/topic/article").
Tabla 6. Patrón de consulta MQL utilizada para el recuento de tópicos agrupados en un
determinado Tipo.
[{
"type": FREEBASE_TYPE_ID, "name~=":"*", "return" : "count",
"/common/topic/article": { "guid": null, "limit": 1, "optional": true }
}]
Puesto que este proceso de recuperación de términos puede tardar varios
minutos, además de ser susceptible de un número mayor de errores de
64
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
comunicación con el servidor HTTP que sirve estos datos desde Freebase, se
ha decidido obtener este tipo de información periódicamente y controlando
los errores de comunicación para repetir el proceso en caso de fallo,
lanzándose en un hilo de ejecución diferente al utilizado por el usuario.
Además del cuerpo de la consulta MQL, se pueden enviar otros parámetros
en el envoltorio de la misma (el denominado envelope), tales como el cursor
y la página (útiles para paginar los resultados haciendo uso de la cláusula
"limit" en el cuerpo de la consulta) o el idioma (parámetro "lang").
Manteniendo la consulta que se muestra en la Tabla 5 y modificando el
parámetro "lang" al valor "/lang/es", es posible recuperar los conceptos en
español y utilizarlos para anotar el texto introducido por el usuario. En este
punto es interesante advertir lo fácil que resultaría recuperar listados en
cualquiera de los idiomas de Google disponibles, siempre y cuando el
número de Tópicos fuese significativo.
Extracción de la terminología bilingüe de MelinePlus
Se han investigado dos formas distinas para utilizar los términos de
MedlinePlus en tareas de anotación:
1. La NLM ofrece los ficheros de datos de MedlinePlus (términos y
descripciones de los mismos) en ficheros con formato XML que
actualiza semanalmente29. El preprocesado de estos ficheros, en el
formato adecuado para su utilización con el módulo Gazetteer de
GATE, permite la anotación del texto introducido por el usuario
tanto en inglés como en español, ya que esto ficheros XML incluyen
los tópicos en ambos idiomas.
29
http://www.nlm.nih.gov/medlineplus/xml.html
65
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
2. El servicio Web OBA del NCBO a través de la ontología Medlineplus
Health Topics. A pesar de que se ha realizado la integración de este
servicio para la anotación, tiene algunas desventajas importantes en
relación con el primer método: i) no permite la anotación bilingüe;
ii) la última actualización de la ontología es del año 2008; iii) la
dependencia de la conexión HTTP; iv) los tiempos de respuesta son
en torno a dos órdenes de magnitud mayores que los del procesado
a través de GATE.
Por tanto, para la anotación bilingüe de los términos médicos procedentes
de MedlinePlus se han utilizado los XML ofrecidos por la NLM. Estos ficheros
contienen, por cada tópico, la siguiente información:
Idioma.
Nombre del tópico en el idioma correspondiente.
URL de MedlinePlus donde se encuentra publicada la información
sobre el tópico.
Información detallada del tópico.
Fecha de creación.
Sinónimos y otros tópicos relacionados.
Grupos de MedlinePlus bajo los que se agrupa el tópico (los grupos
son ofrecidos en otro fichero XML, actualizado con la misma
frecuencia).
El dato del idioma es utilizado para la creación de una lista con los tópicos
en inglés y otra con los tópicos en español. Además, se ha hecho uso de los
sinónimos asociando a cada uno de ellos la misma URL de MedlinePlus que
66
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
la del concepto original, consiguiéndose (aproximadamente) duplicar la lista
de términos con los que anotar a partir de esta fuente.
Extracción de la terminología bilingüe de SNOMED CT
SNOMED CT30 (Systematized Nomenclature of Medicine, Clinical Terms)
tiene su origen en la fusión de dos importantes diccionarios de conceptos
médicos, el SNOMED RT (Reference Terminology) creado por el colegio de
patólogos americanos (CAP) y los Read Codes generados por el servicio
nacional de salud del Reino Unido (NHS). Se trata, por tanto, de una gran
base de datos de conocimiento de la terminología clínica. Identifica los
términos unívocamente a través de un identificador posibilitando su uso
multilingüe. Existen varias formas de obtener los ficheros de datos de
SNOMED CT para investigar, tras aceptar las licencias correspondientes,
como por ejemplo a través del Ministerio de Sanidad, Servicios Sociales e
Igualdad o desde el conjunto de herramientas UMLS de la NLM. Ambas
distribuciones proporcionan los ficheros en texto plano de las tres tablas de
SNOMED CT (terminología, descripciones y relaciones). Sin embargo, la
terminología no está traducida, únicamente proveen la traducción de las
descripciones (como por ejemplo la distribución del 17 de Noviembre del
2011, denominada 2011AB, de la distribución del Metathesaurus de
UMLS31). Para hacer uso de esta terminología se pueden emplear diferentes
aproximaciones, tales como: (i) el software Java de código libre
30
http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html
31
http://www.nlm.nih.gov/research/umls/licensedcontent/umlsknowledgesources.ht
ml
67
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
MetamorphoSys32 incluido en la misma distribución de las fuentes de
conocimiento de UMLS, que permite la extracción de subconjuntos de
conceptos de SNOMED CT; (ii) El programa MetaMap (la versión actual, que
sustituye al anterior programa Java MMTx, es el 2011 Release) que permite
descubrir los conceptos del diccionario de UMLS que aparecen en un texto
aplicando diferentes estrategias de PLN y LC (Lingüística Computacional); (iii)
Usando el recurso específico del dominio biomédico que incluye GATE para
anotar con MetaMap33.
Dado que MedlinePlus ofrece un servicio basado en el subconjunto
denominado CORE Problem List34 de la distribución (MedlinePlus Connect),
el preprocesado de este subconjunto de datos adquiere una relevancia
especial respecto al resto de conceptos de SNOMED CT, al disponerse de un
mecanismo directo para la obtención de información enriquecida de datos
sobre los conceptos anotados, tal y como es MedlinePlus Connect. No
obstante, desde el punto de vista de la anotación del máximo número de
conceptos, también se ha preprocesado la terminología completa en inglés
y, a partir de la tabla de descripciones, la terminología médica completa en
español.
32
http://www.nlm.nih.gov/research/umls/implementation_resources/metamorphosy
s/index.html
33
http://gate.ac.uk/sale/tao/splitch16.html#sec:misc-creole:metamap
34
http://www.nlm.nih.gov/research/umls/Snomed/core_subset.html
68
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Anotación con ontologías biomédicas remotas
Los servicios Web desarrollados por el NCBO35 permiten el acceso a una gran
cantidad de recursos relacionados con las ontologías integradas: acceso y
descarga de datos de las ontologías, búsquedas por término, extracción de
las estructuras jerárquicas dada una ontología y una rama de la misma,
búsqueda de recursos indexados36 o anotación de textos37. Este último
servicio es el que se ha integrado en el sistema biomédico. Para el acceso al
servicio a través del navegador, el NCBO ha desarrollado una interfaz38 que
permite introducir un texto, procesarlo y obtener el conjunto de resultados
de los términos anotados, tras la selección de las ontologías con las que se
quiere llevar a cabo la anotación, los tipos semánticos de UMLS con los que
se quieren filtrar los resultados, los mapeos y el nivel de los conceptos
jerárquicamente relacionados con los términos anotados que se quieren
obtener (Fig. 2).
35
http://www.bioontology.org/wiki/index.php/BioPortal_REST_services
36
http://www.bioontology.org/wiki/index.php/Resource_Index
37
http://bioontology.org/wiki/index.php/Annotator_Web_service
38
http://bioportal.bioontology.org/annotator
69
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Figura 2 Interfaz Web del OBA.
(Accedido el 06 de Marzo de 2012)
Una de las limitaciones del portal, en cuanto a las dimensiones del texto, es
que no permite procesar más de 500 palabras, cosa que no sucede al
procesar el texto haciendo uso del servicio Web.
El servicio OBA dispone de una amplia parametrización, algunos de ellos
tienen la finalidad de controlar las características de los términos anotados similares a los valores configurables en el Gazetteer de GATE, tales como
longestOnly, utilizado para anotar únicamente las frases más largas, o
wholeWordOnly, utilizado para anotar solamente palabras completas - y
otros están orientados a la gestión de las ontologías utilizadas y al nivel de
profundización
en
la
jerarquía
de
las
mismas
-
tales
como
ontologiesToKeepInResult, correspodiente al conjunto de identificadores de
las ontologías separados por comas con las que se desea realizar la
70
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
anotación, o levelMax, con el que se puede indicar el número de niveles
jerárquicos en los que se realizará la expansión semántica "is_a".
Para disponer de un mecanismo que recupere los identificadores asignados
a las ontologías con las que se puede anotar a través del OBA, se ha
implementado un cliente (Fig. 3) con el que se pueden filtrar las ontologías
por su estado (únicamente se pueden emplear para la anotación aquellas
con un estado "28") o su nombre.
Figura 3 Cliente Web desarrollado para facilitar el acceso a las ontologías disponibles en el
OBA.
Página ncbolist.jsp
A través de este cliente se puede comprobar que el identificador
correspondiente a la ontología MedlinePlus Health Topics es el 40397, o que
el de SNOMED Clinical Terms es el 46116. Concatenando adecuadamente
estos identificadores es posible llevar a cabo la petición al servicio de
anotación OBA, cuyos resultados pueden obtenerse en diferentes formatos
71
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
como, por ejemplo, en XML. Algunos de los datos resultantes incluidos en el
documento XML resultante son los siguientes:
El identificador de la ontología con la que ha sido anotado el
concepto.
El nombre preferido y sinónimos relacionados.
El nivel o contexto del concepto, que tendrá el valor MGREP si es
una anotación directa realizada con la herramienta Mgrep (el
concepto que aparece explícitamente en el texto o un sinónimo),
ISA_CLOSURE si es una anotación indirecta (encontrada a través de
la relación parental "es_un"), o MAPPING si se trata de una
anotación relacionada semánticamente en otra ontología.
Los índices que indican el comienzo y el final del término dentro de
toda la cadena de texto.
2. Información enriquecida de los conceptos
Puesto que uno de los objetivos del sistema es proporcionar al cliente datos
que permitan facilitar la comprensión del texto médico que introduce en la
herramienta, se han implementado diferentes estrategias para ofrecer
información sobre las entidades tras haberlas extraído. Tanto si han sido
detectadas a partir de las listas de términos recuperadas desde Freebase, de
las listas preprocesadas a partir de los ficheros de MedlinePlus, de las listas
procedentes de los datos de SNOMED CT, o han sido anotados a través del
servicio remoto del NCBO, se han desarrollado mecanismos para enlazar
estas entidades con contenidos descriptivos y con otros conceptos
semánticamente relacionados, para los que también es posible obtener
72
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
información enriquecida. Estos mecanismos son los que se explican a
continuación.
Información enriquecida desde Freebase
Una vez se han reconocido las entidades a partir de las listas de Freebase, se
ha valorado la generación de consultas MQL para obtener dos tipos de
resultados:
1. Consultas MQL para obtener un listado de conceptos similares al
anotado, antes de ofrecer la información de detalle, tal y como las
que se muestran en el patrón de la Tabla 7.
2. Consultas MQL para obtener la información descriptiva de un
determinado concepto (artículo de Wikipedia y una imagen) y la
información semántica relacionada (Propiedades), tal y como las
que se muestran en la Tabla 8.
Tabla 7. Patrón de consulta MQL utilizada para la búsqueda de conceptos similares en
Freebase.
BÚSQUEDA DE CONCEPTOS CON EL PATRÓN "*CONCEPTO*"
[{
"type": FREEBASE_TYPE_ID, "name~=":"*CONCEPTO*",
"id":null, "name":null, "limit": 10,
"/common/topic/article":[{"guid":null, "limit":1, "optional":true}],
"/common/topic/image":[{"id":null, "limit":1, "optional":true}]
}]
Tabla 8. Consulta MQL utilizada para la búsqueda de los datos descriptivos y la información
semántica de un determinado concepto.
DETALLE PARA CADA CONCEPTO RESULTANTE
ENFERMEDADES
[{
"type": "/medicine/disease", "id": FREEBASE_TOPIC_ID, "name":null,
"/common/topic/article": [{"guid":null, "limit": 1, "optional":true}],
"/common/topic/image": [{"id":null, "limit": 1, "optional":true}],
"symptoms":[{"id":null, "index":null, "name":null,
73
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
"optional":true, "sort":"index", "type":"/medicine/symptom"}],
"treatments":[{"id":null, "index":null, "name":null,
"optional":true, "sort":"index", "type":"/medicine/medical_treatment"}],
"risk_factors":[{"id":null, "index":null, "name":null,
"optional":true, "sort":"index", "type":"/medicine/risk_factor"}]
}]
TRATAMIENTOS
[{
"type": "/medicine/medical_treatment", "id": FREEBASE_TOPIC_ID, "name":null,
"/common/topic/article": [{"guid":null, "limit": 1, "optional":true}],
"/common/topic/image": [{"id":null, "limit": 1, "optional":true}],
"side_effects":[{"id":null, "index":null, "name":null,
"optional":true, "sort":"index", "type":"/medicine/symptom"}],
"used_to_treat":[{"id":null, "index":null, "name":null,
"optional":true, "sort":"index", "type":"/medicine/disease"}]
}]
SÍNTOMAS
[{
"type": "/medicine/symptom", "id": FREEBASE_TOPIC_ID, "name":null,
"/common/topic/article": [{"guid":null, "limit": 1, "optional":true}],
"/common/topic/image": [{"id":null, "limit": 1, "optional":true}],
"side_effect_of":[{"id":null, "index":null, "name":null,
"optional":true, "sort":"index", "type":"/medicine/medical_treatment"}],
"symptom_of ":[{"id":null, "index":null, "name":null,
"optional":true, "sort":"index", "type":"/medicine/disease"}]
}]
En las consultas que siguen el patrón de la Tabla 7 se incluyen también los
parámetros del envoltorio de la consulta page y cursor, que posibilitan la
paginación de los resultados en caso de ser necesario.
Información enriquecida bilingüe desde MedlinePlus
Los servicios proporcionados por MedlinePlus, tanto los publicados en HTML
para los usuarios finales como los servicios Web preparados para la
recuperación de datos desde otros sistemas informáticos, son los que han
facilitado el acceso a la información descriptiva sobre las entidades anotadas
por varias de las fuentes utilizadas, tal y como se describe a continuación.
En primer lugar, el preprocesado de la información contenida en los ficheros
XML de MedlinePlus para generar las listas de términos, permite al mismo
tiempo almacenar la URL del servicio que MedlinePlus ofrece a los usuarios,
74
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
tanto en español como en inglés. Esto ha posibilitado agregar un enlace a
estos contenidos junto con la entidad. Si la entidad es reconocida en inglés,
se proporcionan al usuario los enlaces al contenido en inglés y en español
publicados por MedlinePlus en su sitio Web. Del mismo modo, si la entidad
es reconocida en español se ofrecen los enlaces al contenido de MedlinePlus
en orden inverso. Tanto en un caso como en otro, MedlinePlus facilita la
visualización del contenido de la información en el otro idioma (en español
si estamos viendo la página en inglés y viceversa) a través de un botón (tal y
como se muestra en la imagen de la Fig. 4).
Figura 4 Visualización de información bilingüe en el sitio Web de MedlinePlus.
Enmarcado en rojo el botón que permite esta acción (accedido el 18 Febrero 2012).
En segundo lugar, uno de los servicios Web de MedlinePlus que la NLM
mantiene para el acceso a sus datos a través de sistemas de software,
consiste en un buscador que proporciona información sobre los tópicos de
salud que más se aproximan al término buscado, ordenando los resultados
por criterios de relevancia. Estos criterios de relevancia internos de
75
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
MedlinePlus pueden verse alterados por la coincidencia del término
buscado, es decir, si el término tiene una coincidencia exacta con alguno de
los tópicos entonces lo situará en la primera posición a pesar de no ser
considerado de máxima relevancia. En cualquier caso, uno de los datos que
devuelve el servicio es el valor de relevancia asignado al término (rank), que
puede ser recuperado por el sistema para alterar el orden al mostrar los
resultados por pantalla o, como es el caso, para mostrarlo como parte de la
información ofrecida al usuario. Además del listado de tópicos, a través del
servicio se pueden obtener otros datos relacionados con cada uno de ellos,
tales como la URL a la página Web del tópico, la descripción completa, los
términos MeSH asociados al tópico o los grupos de MedlinePlus a los que
pertenece (de los que está publicada una lista completa39). Una vez que una
entidad ha sido extraída con el listado de términos obtenidos a partir de los
nombres de los tópicos de MedlinePlus, este servicio Web ha permitido
generar un cliente para mostrar la información asociada a través de un
interfaz propio, sin necesidad de que el usuario visite el sitio Web de
MedlinePlus. Un ejemplo de la salida en formato HTML de este cliente, que
se explicará con más detalle en el siguiente capítulo, se muestra en la Fig. 5.
39
http://www.nlm.nih.gov/medlineplus/healthtopics.html
76
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Figura 5 Resultados en HTML del cliente Web desarrollado para el servicio de MedlinePlus.
Tras realizar la búsqueda "breast cancer". URL: medlineplus.jsp?term=breast cancer
Una de las principales limitaciones de este servicio es que únicamente
funciona con la información en inglés, cuestión que se ha tratado de superar
incorporando la URL al tópico en español. Las ventajas más destacables,
frente al preprocesado de la información procedente de los ficheros XML
(que contienen una información muy similar), son: que el servicio Web
responde con un conjunto de resultados que consiste en una lista ordenada
por ranking y similitud de la búsqueda (que habría que implementar si se
deseara mostrar este listado a partir de los ficheros XML, en lugar de ofrecer
directamente la información sobre el concepto anotado); la frecuencia de
actualización de los datos (que la llevan a cabo diariamente); la inclusión de
los grupos a los que pertenece cada tópico (evitando así el esfuerzo que
preprocesar también el fichero XML de grupos).
Por otro lado se dispone del servicio MedlinePlus Connect40 mencionado
anteriormente, que responde a consultas por identificador de SNOMED CT.
40
http://www.nlm.nih.gov/medlineplus/connect/overview.html
77
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
La característica más interesante desde el punto de vista de la construcción
de un sistema cross lingüe consiste en que proporciona la información tanto
en español como en inglés, haciendo uso de un parámetro con el que se le
indica el idioma, de manera que dado un término detectado en cualquiera
de los idiomas, el usuario puede enlazar directamente con el contenido en
ambos idiomas. Desde el punto de vista de la cobertura de términos, la
principal limitación de este servicio es que no trabaja con la terminología
completa de SNOMED CT, sino con el subconjunto también mencionado
CORE Problem List. Este subconjunto procede a su vez de una selección de
los términos de UMLS, considerados como los más relevantes para la
codificación de los historiales clínicos, gestionándose a partir de los datos
manejados por 7 instituciones de salud.
Acceso a información bibliográfica de MEDLINE/PubMed
La biología molecular ha generado a partir de la última década cantidades
ingentes
de
información
procedente
de
diversos
proyectos
de
secuenciación. El NCBI (National Center for Biotechnology Information),
fundado en 1988, es el organismo encargado de la creación de bases de
datos públicas, realización de investigaciones en biología computacional y
desarrollo de herramientas software para el análisis del genoma humano,
que tienen como finalidad la puesta en común y propagación del
conocimiento biomédico existente. Actualmente, el NCBI posee, junto con
sus colaboradores EMBL (European Molecular Biology Laboratory) y DNA
Data Bank of Japan, bases de datos con información de unos 165.000
organismos diferentes.
78
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
MEDLINE es una de las base de datos bibliográfica más importante y
consultada en el dominio biomédico, almacena referencias a artículos de
revistas desde 1950 hasta la actualidad. En el año 2011 el número de
referencias indexadas41 supera la cifra de 19 millones, habiéndose producido
un incremento aproximado del 4% en dicho año (724.831 nuevas
referencias) lo que implica un crecimiento aproximado de 2.000 referencias
diarias. MEDLINE es el componente más importante de PubMed, un motor
de búsqueda gratuito que además de las referencias incluidas en MEDLINE
también incluye otras referencias, como por ejemplo: aquéllas que se
encuentran en progreso de ser indexadas, referencias anteriores a la fecha
en la que comienzan a ser indexadas, referencias a algunas revistas
adicionales de PubMed Central revisadas por la NLM, etc.
El NCBI ofrece un conjunto de utilidades de servidor (ocho programas en la
última fecha de acceso, Febrero de 2012) denominadas E-utilities42, que dan
acceso al sistema de bases de datos y consultas denominado Entrez43. El
sistema ofrece acceso a bases de datos biomédicas, especializadas en áreas
de conocimiento como la genómica (e.g. Nucleotide, Genome, Gene) o la
proteómica (e.g. CDD, protein), además del acceso a los recursos
bibliográficos (e.g. PubMed, PubMed Central). Para acceder a todas las
utilidades se puede usar una URL base44, a la que se le concatena el nombre
de la utilidad con la extensión "fcgi" (einfo, esearch, epost, esummary,
efetch, elink, egquery y espell), además de los parámetros correspondientes
41
http://www.nlm.nih.gov/bsd/pmresources.html#statistics
42
http://www.ncbi.nlm.nih.gov/books/NBK25501/
43
http://www.ncbi.nlm.nih.gov/gquery/
44
http://eutils.ncbi.nlm.nih.gov/entrez/eutils/
79
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
a cada utilidad. El número de bases de datos incorporadas al sistema45 va
aumentando con el tiempo. A través de la utilidad einfo se puede obtener
un listado de todas las bases de datos incorporadas, haciendo la petición sin
parámetros, obteniendo los identificadores de las diferentes bases de datos.
Agregando este identificador como parámetro a la misma utilidad
(db=[identificador]) permite obtener más detalles sobre esta base de datos
en concreto. Sin embargo, es preciso consultar la documentación para
averiguar si la base de datos está habilitada para su uso con la utilidad
efetch (que sirve para recuperar los registros de datos correspondientes a
los identificadores resultantes de la utilidad de búsqueda esearch), o hacer
una petición y comprobar el resultado. Por ejemplo, si se realiza la petición a
la utilidad einfo y se adquiere el identificador de la base de datos
pubmedhealth, éste puede emplearse para ejecutar una búsqueda. Para
obtener los resultados de una búsqueda en esta base de datos utilizando el
término de búsqueda "prostate cancer", es necesario hacer una petición a la
utilidad esearch, esearch.fcgi?db=pubmedhealth&term=prostate+cancer,
obteniéndose un conjunto de identificadores de documentos que es posible
consultar (Fig. 6), en principio, con la utilidad efetch. Sin embargo, para esta
base de datos se puede comprobar que (a fecha de 29 de Febrero de 2012)
el sistema efetch no la tiene incorporada, ya que si se utilizan los dos
primeros identificadores (por ejemplo) para hacer la petición a esta utilidad,
efetch.fcgi?db=pubmedhealth&id=1418,9311, el resultado del sistema es el
texto "Database: pubmedhealth - is not supported".
45
http://www.ncbi.nlm.nih.gov/books/NBK3837/
80
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Figura 6 Identificadores resultantes al utilizar la utilidad esearch del sistema Entrez.
Resulados para la búsqueda del término "prostate cancer" en la base de datos pubmedhealth.
Los identificadores pueden ser utilizados desde la utilidad esummary, que
proporciona un resumen de los documentos consultados. Procediendo de
un modo similar con la base de datos pubmed, haciendo uso de la utilidad
esearch (imagen izquierda de la Fig. 7) y después de la utilidad esummary
(imagen derecha de la Fig. 7), usando uno de los identificadores resultantes
(pudiéndose utilizar más de uno concatenándolos a través del carácter ','),
permite recuperar datos como: la fecha de publicación, la lista de autores, el
identificador digital del documento, etc.
81
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Figura 7 Consultas a la base de datos pubmed para el término "prostate cancer" haciendo
uso de la utilidad esearch (imagen de la izquierda) y con la utilidad esummary (imagen de
la derecha) usando el primer identificador resultante.
La utilidad efetch se puede emplear para capturar el abstract de los artículos
resultantes de la búsqueda, de uno en uno o en grupo (concatenando los
identificadores del mismo modo que para la utilidad esummary). Un ejemplo
de la consulta del abstract (parámetro rettype=abstract) para el primer
identificador resultante de la búsqueda anterior, en formato texto
(parámetro retmode=text), se muestra en la Fig. 8.
82
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Figura 8 Consulta a la base de datos pubmed con la utilidad efetch para obtener el abstract
en formato texto.
A partir del primer identificador resultante tras realizar la búsqueda con la utilidad esearch
usando el término "prostate cancer".
Además de estas utilidades, el sistema Entrez dispone de un servicio de
acceso SOAP para facilitar el acceso a las utilidades a través de clientes
desarrollados en otro servidor. Para la integración de las búsquedas en los
recursos bibliográficos de la base de datos PubMed (db=pubmed), se hará
uso de las librerías Axis2 de Apache46 para generar un cliente al servicio, que
servirá para ofrecer esta información a los usuarios del sistema. Este cliente
se explicará con mayor detalle en el siguiente capítulo.
3. Elementos del interfaz y métodos de acceso al sistema
46
http://www.ncbi.nlm.nih.gov/books/NBK55696/
83
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
En el módulo CAI se han desarrollado dos mecanismos de acceso al sistema,
ambos basados en el protocolo HTTP. Uno de ellos es una aplicación Web
que permite al usuario final interaccionar con los componentes de los
módulos PLN y BEE, haciendo uso de las diferentes funcionalidades a través
del navegador. El otro mecanismo es un servicio que devuelve la respuesta
en formato XML, preparado para su acceso y tratamiento automático a
través de otros sistemas o aplicaciones informáticas. A continuación se
describirán con algo más de detalle los fundamentos en los que se basa el
desarrollo de ambos componentes.
Aplicación de acceso Web
Para lograr un interfaz fácil de utilizar, se ha llevado a cabo un modelo de
pantallas que van profundizando progresivamente en los contenidos
seleccionados por los usuarios, intentando evitar en todo momento la
sobrecarga de información al que podría dar lugar, sobre todo, el procesado
de textos con muchas palabras o textos con muchos conceptos médicos
detectables. Por otro lado, para conseguir que el interfaz sea, no sólo de
fácil uso, sino también agradable y tratar de mejorar de este modo la
percepción de los usuarios al interaccionar, se ha hecho uso de la librería de
JavaScript jQuery47, así como algunos de sus plugins.
La sobrecarga de información en la pantalla del navegador se ha tratado de
superar utilizando diferentes estrategias:
La pantalla principal, desde la que el usuario introduce inicialmente
el texto y acciona el proceso de extracción de entidades, se ha
47
http://jquery.com/
84
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
reducido hasta contener el número mínimo de opciones necesarias
(Fig. 9, izquierda). Estas opciones incluyen:
1) Las
diferentes
combinaciones
de
las
fuentes
de
conocimiento con las que se puede realizar el proceso de
extracción (Annotate with Ontologies), que son: LOCAL (el
reconocimiento se lleva a cabo con la terminología
preprocesada seleccionada para los usuarios, es decir, la
seleccionada entre las fuentes Freebase, MedlinePlus y
SNOMED CT, tanto en inglés como en español); REMOTE
MEDLINEPLUS (reconocimiento realizado con la ontología
remota MedlinePlus Health Topics del OBA); REMOTE
SNOMED (reconocimiento realizado con la ontología remota
SNOMED CT del OBA); REMOTE ALL (reconocimiento
realizado con las dos ontologías remotas integradas); ALL
(reconocimiento utilizando todas las fuentes de anotación
integradas).
2) Un cajón de texto redimensionable desde el que el usuario
introducirá el texto a procesar, permitiéndole adaptarlo a la
longitud del texto introducido.
3) Un botón para iniciar el análisis automático del texto.
Puesto que los tiempos de respuesta pueden llegar a ser superiores
a 30 segundos, dependiendo principalmente de las dimensiones de
las listas integradas en el procesado local y de la longitud del texto
en el procesado remoto, mientras el texto se procesa se muestra un
mensaje de espera al usuario (Fig. 9, derecha).
85
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Figura 9 A la izquierda, pantalla principal del componente de acceso Web. A la derecha,
mensaje de espera tras el inicio del procesado.
La respuesta del sistema es una tabla en la que es posible aplicar
filtros lógicos para cada campo (enmarcados en rojo en la imagen
superior de la Fig. 10), habiéndose eliminado todas las entidades
reconocidas varias veces por la misma lista de términos o por la
misma ontología remota. Los filtros son construidos con el plugin
PicNet Table Filter48 de jQuery, que permite los filtros lógicos AND,
OR, NOT, agrupamientos, expresiones textuales (entre comillas) y
comparaciones numéricas (=, !=, >, <, >=, <=). Un ejemplo se
muestra en la imagen intermedia de la Fig. 10. Además, a través del
plugin tablesorter49, es posible ordenar los resultados utilizando
múltiples campos, seleccionándolos en el orden deseado con el
48
http://www.picnet.com.au/picnet-table-filter.html
49
http://tablesorter.com
86
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
botón izquierdo del ratón (sobre las cabeceras) y manteniendo
pulsada la tecla shift (imagen inferior de la Fig. 10).
Figura 10 Arriba, resultados de la extracción LOCAL tras procesar texto con conceptos
repetidos (los cajones de texto para los filtros lógicos están enmarcados en rojo). En medio,
87
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
resultado tras aplicar un filtro lógico sobre el concepto (campo CONCEPT). Abajo, pantalla
resultante tras ordenar por los campos idioma (LAN) y, después, fuente (SOURCE).
A nivel de procesamiento de conceptos, una de las mayores
simplificaciones que se ha llevado a cabo para el usuario final es la
de mantener entre los resultados únicamente el reconocimiento de
los términos que aparecen explícitamente en el texto introducido,
traduciéndose en una mayor simplicidad de la pantalla principal. En
la Fig. 11 se muestra una interfaz Web aparentemente similar a la
ofrecida para los usuarios finales, pero conteniendo un número
mayor de funcionalidades y, en consecuencia, empeorando la
claridad de los resultados mostrados en la pantalla principal. En esta
interfaz se ha agregado una opción que permite seleccionar el nivel
de profundidad de búsqueda en las ontologías remotas (enmarcado
en rojo), otra para introducir los identificadores de aquellas
ontologías remotas con las que procesar el texto (enmarcado en
azul) - llevándose a cabo con todas las disponibles en el OBA si se
deja vacío - y otra para seleccionar cada una de las fuentes locales y
los idiomas (enmarcado en verde). A mayor nivel de profundidad,
mayor es el número de conceptos implícitamente localizados
(relacionados parentalmente en la jerarquía de la ontología como
"es_un"). Al realizar la anotación remota desde esta interfaz, no sólo
se muestran los conceptos que aparecen explícitamente sino
también aquéllos encontrados en la ontología a partir de los
mismos. La salida construida es mucho más compleja por dos
motivos fundamentales:
1) En primer lugar, refleja el hecho de si la anotación es directa
(es decir, cuando se anula el nivel de profundidad de
88
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
búsqueda en la jerarquía de la ontología y sólo se localizan
los conceptos directamente relacionados con los que
aparecen explícitamente en el texto de entrada) o no lo es,
por el sentido de la flecha. El término que aparece a la
izquierda de la flecha, para la columna CONCEPT, se refiere
al concepto localizado en la ontología (nombre preferido),
mientras que el término que aparece a la derecha de la
flecha se refiere al término que aparece en el texto de
entrada. Si la flecha va desde el término original del texto
hacia el concepto de la ontología (<-) quiere decir que la
anotación es directa. Sin embargo, esto no implica que el
concepto sea anotado una sola vez, ya que puede tener
varios nombres preferidos (sinónimos), manteniéndose en
este
interfaz
todos
los
conceptos
encontrados
(eliminándose únicamente aquellos valores repetidos para
los nombres preferidos, en lugar de eliminarse los valores
repetidos para los términos del texto, tal y como se hace
desde el interfaz para usuarios).
2) En segundo lugar, si la anotación no es directa se indica con
la flecha desde el nombre preferido hacia el concepto (->),
lo que da lugar a una gran cantidad de resultados por
concepto a medida que aumentamos el nivel de
profundidad (tal y como se puede comprobar en la Fig. 11,
donde remotamente se está anotando tan solo una frase
que contiene "prostate cancer, asthma" con la ontología
89
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
MedlinePlus Health Topics, ya que los otros dos términos en
español sólo dan resultados al procesarlos localmente).
Figura 11 Resultados de la extracción tras procesar remotamente el texto con un nivel de
profundidad 1 en la ontología MedlinePlus Health Topics y localmente con las terminologías
preprocesadas de Freebase y MedlinePlus en inglés y en español.
Estas opciones locales no se ofrecen a los usuarios finales por el aumento de la complejidad.
Página: admin.html
Tanto el cajón de texto redimensionable para la introducción del
texto a procesar como la tabla de resultados, se encuentran
embebidos en una tabla redimensionable, lo que permite una mejor
adaptación a las diferentes configuraciones de pantalla.
La información que se puede obtener del módulo BEE se ha incluido
en pantallas distintas a la inicial, que se abren en una nueva pestaña
del navegador al utilizar los enlaces situados sobre las entidades.
Estos enlaces son ejecutados, por tanto, bajo el servidor Web local
(URL's locales), que dependerán de la fuente y, en el caso de ser
anotadas por Freebase, también del grupo. Esta distinción está
motivada por el hecho de que un Tópico de Freebase puede
90
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
disponer de distintos tipos de información semántica dependiendo
del Tipo al que pertenezca. Véase, por ejemplo, en la Fig. 12 la
búsqueda de "asthma" como síntoma (arriba) o como enfermedad
(abajo), donde, aunque la descripción y la imagen coincidan, cuando
el término se busca como un síntoma se pueden obtener las
enfermedades que lo producen (symptom of) o los tratamientos que
pueden provocarlo (side effect of), mientras que cuando se busca
como una enfermedad se pueden obtener sus síntomas (symptoms),
sus tratamientos (treatments) o los factores de riesgo (risk factors).
Figura 12 Con el término "asthma", arriba se muestra uno de los resultados del módulo BEE
proporcionado por el componente de acceso a síntomas de Freebase, abajo se muestra uno
de los resultados proporcionado por el componente de acceso a enfermedades de
Freebase.
Los resultados del módulo BEE a través de los enlaces localizados sobre los
conceptos reconocidos, proporcionan búsquedas en las diferentes fuentes
de conocimiento, así como la posibilidad de enlazar nuevos conceptos
resultantes de estas búsquedas, tanto localmente como a páginas Web
91
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
externas (la casuística aportada por este módulo se presenta en la Tabla 9).
Esta opción únicamente es ofrecida para las entidades reconocidas en
inglés, aunque es posible enlazar directamente a la información de los
conceptos resultantes también en español, en el caso del componente de
MedlinePlus. Este componente es el enlazado tanto para los conceptos
extraídos a partir de esta misma fuente como para los extraídos con
SNOMED CT, ya sea a través de las listas de términos locales o de las
anotaciones remotas.
Tabla 9. Casuística proporcionada por el módulo BEE en función de la fuente y el grupo al
que pertenece el concepto reconocido en el texto de entrada.
Fuente (Grupo)
Página de búsqueda
local
1)
Freebase (Disease)
Enfermedades de
Freebase
2)
3)
1)
Freebase (Symptom)
Síntomas de
Freebase
2)
3)
1)
Freebase
(Treatment)
Tratamientos de
Freebase
2)
3)
MedlinePlus local o Conceptos de
remoto (-)
MedlinePlus
Snomed ct local o
Conceptos de
remoto (-)
MedlinePlus
- cualesquiera que sea el Grupo
Enlaces locales disponibles
(componente de BEE)
Síntoma (síntomas de
Freebase)
Tratamiento (tratamientos
de Freebase)
Concepto (PubMed)
Síntoma de (enfermedad de
Freebase)
Efecto de (tratamiento de
Freebase)
Concepto (PubMed)
Usado para tratar
(enfermedad de Freebase)
Efecto secundario (síntoma
de Freebase)
Concepto (PubMed)
Enlaces externos
disponibles
1)
2)
Concepto (Freebase)
Concepto (Freebase)
1)
1)
2)
Concepto (PubMed)
MeSH (PubMed)
Factor de riesgo
(Freebase)
Concepto (Freebase)
2)
Concepto en inglés
(MedlinePlus)
Concepto en español
(MedlinePlus)
También se ofrece, desde la pantalla inicial, la posibilidad de visitar páginas
Web externas sobre las entidades reconocidas en el texto. Estos enlaces
proveerán al usuario información en inglés o en español, en función de la
disponibilidad de la fuente y de la información adquirida tras el proceso de
anotación (por ejemplo, cuando la anotación se realiza con la ontología
92
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
remota MedlinePlus Health Topics, no se dispone de la URL al tópico en el
sitio Web, por lo que se enlaza directamente la URL disponible a la ontología
en el sitio Web del NCBO).
Tabla 10. Enlaces externos incluidos para los conceptos reconocidos en la página inicial,
dependiendo de la fuente y del idioma con el que han sido detectados.
Idioma de
extracción
Inglés
Español
Tópico en Freebase
Tópico en Freebase
Inglés
Tópico en MedlinePlus
Español
Tópico en MedlinePlus
Inglés
MedlinePlus CONNECT
Español
MedlinePlus CONNECT
MedlinePlus remoto
Inglés
Ontología en NCBO
SNOMED remoto
Inglés
MedlinePlus CONNECT
Fuente
Freebase
Enlace externo
MedlinePlus local
SNOMED local
Idioma de la información
enlazada
Inglés
Inglés
Inglés
Español
Español
Inglés
Inglés
Español
Español
Inglés
Inglés
Inglés
Español
Ya por último, queda mencionar el interfaz que provee este componente
para el acceso al cliente de PubMed del módulo BEE, enlazado desde las
diferentes páginas de búsqueda en Freebase y MedlinePlus para los
conceptos resultantes (Fig. 13).
93
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Figura 13 Interfaz Web que proporciona el componente para el acceso al cliente de
PubMed.
Enmarcado en rojo, el enlace al abstract del artículo en formato texto. Página: pmresult.jsp.
Servicio de acceso en formato XML
Este servicio Web da acceso a las funcionalidades del módulo PLN,
posibilitando una parametrización más amplia que la permitida a través de
la aplicación Web orientada a usuarios finales. De este modo, el cliente del
servicio puede utilizar un conjunto más amplio de datos para adaptarlos a
sus necesidades particulares. El documento XML resultante se genera
utilizando el componente estándar de Java JAXP (Java Api for XML
Processing), incorporado a través del componente de integración de
información del módulo PLN.
94
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
Figura 14 Cliente Web del componente de acceso XML.
Página: service.html
El servicio está preparado para dar resultados ante multitud de
configuraciones, que pueden ser exploradas a través de un cliente de
ejemplo desarrollado como una página HTML (Fig. 14). La respuesta incluye
los datos de entrada, en un nodo denominado input, y todas las entidades
reconocidas en el texto enviado al sistema para su procesado, a través de los
nodos annotation. A continuación se explican con mayor detalle las
opciones del servicio más relevantes:
Se puede procesar el texto seleccionando cada una de las fuentes de
conocimiento
locales
y
remotas
que
se
desean
utilizar,
obteniéndose para cada una de ellas el total de entidades
localizadas incluyendo los valores repetidos en diferentes posiciones
del texto por cada fuente. Esta funcionalidad dependerá
fundamentalmente de los parámetros src y onts (Tabla 11), aunque
95
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
también dependerá de los parámetros establecidos para la
utilización de las listas de términos locales (ver el caso src=1 en la
Tabla 11), dando respuesta a cualquier conjunto de ontologías
remotas integradas bajo el servicio Web del OBA (que, como se
mencionó en el capítulo anterior, pueden verse en el cliente
ncbolist.jsp).
Tabla 11. Proceso de reconocimiento llevado a cabo por el componente de acceso XML en
función de los parámetros src y onts.
Parámetros
src
Fuentes de conocimiento utilizadas
onts
Locales, indicadas en los parámetros: cksrcfb (Freebase), cksrcmp
1
(No afecta)
(MedlinePlus), cksrcsc (SNOMED CT). En combinación con los
parámetros: cklanen (Inglés), cklansp (Español)
2
(No afecta)
Remota con MedlinePlus Health Topics
3
(No afecta)
Remota con SNOMED CT
4
Listado de identificadores
separados por "," o vacío
-1
Remota con las ontologías indicadas en el parámetro onts, o con
todas si va vacío
Local (igual que el caso src=1) y Remota (igual que en el caso src=4)
Permite seleccionar el nivel de profundidad de búsqueda en las
ontologías remotas a través del parámetro lev. Tal y como se
explicaba en la sección anterior, un valor 0 para este parámetro
limita la búsqueda en las ontologías remotas a las anotaciones
directas, mientras que el aumento de su valor aumenta la búsqueda
a través de las ramas parentales de las diferentes ontologías, dando
lugar a un número mayor de conceptos reconocidos.
Los datos devueltos por el servicio incluyen el idioma de la fuente
con la que se ha reconocido el concepto, el término reconocido en
el texto, su nombre preferido (en el caso de las anotaciones locales
96
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
será el mismo que el concepto reconocido, mientras que en las
anotaciones remotas se corresponderá con el concepto localizado
en la ontología) y si este nombre es obtenido de forma directa, los
índices que delimitan el posicionamiento del término en el texto de
entrada, la URL del componente Web local (del módulo CAI) que da
acceso a los componentes del módulo BEE (si es que existe), la URL
remota en inglés y en español (si es que se dispone de ellas) y los
grupos a los que pertenece el concepto.
Además, el XML está preparado para albergar algún algoritmo de detección
de la negación y/o especulación, aunque no se ha llegado a integrar en el
sistema implementado ninguno (esto se incluye como un atributo de cada
nodo concept, denominado neg).
97
EXTRACCIÓN DE CONCEPTOS E INTEGRACIÓN DE INFORMACIÓN
BIOMÉDICA
98
DESARROLLO DEL SISTEMA BIOMÉDICO
CAPÍTULO 4. DESARROLLO DEL SISTEMA BIOMÉDICO.
En este capítulo se mostrarán los detalles de la implementación del sistema
biomédico CLEiM50 (Cross Lingual Education in Medicine), que ha dado lugar
al sistema MedicalFace51, utilizado en la experiencia de evaluación con
estudiantes, y a la versión de código libre publicada en el portal
sourceforge52 (CLEiMSf).
1. Preprocesado y recuperación de información
Freebase
La recuperación de la información sobre los conceptos de Freebase
utilizados en el sistema se realiza a partir de la ejecución de las consultas
MQL desde una clase Java, haciendo uso de una de las librerías de acceso
enlazadas en el sitio Web de Freebase53. En particular, se ha incluido como
API de acceso la librería denominada freebase-java54, que permite la
ejecución de todas las consultas MQL necesarias y la recuperación de los
datos que serán preprocesados. Para esto último también se ha incorporado
una librería especializada en el tratamiento del formato JSON55, que es el
formato de la respuesta devuelta tras realizar las consultas MQL a través del
API de acceso.
50
http://www.medicalminer.org/CLEiM
51
http://www.medicalminer.org/MedicalFace/mt.html
52
http://cleim.sourceforge.net
53
http://wiki.freebase.com/wiki/Java
54
http://code.google.com/p/freebase-java/
55
https://sourceforge.net/projects/json-lib
99
DESARROLLO DEL SISTEMA BIOMÉDICO
La clase Java desarrollada se ha denominado CallFBToFile y su
funcionamiento se explica a continuación con más detalle a través de las
propiedades y los métodos que contiene, que son los siguientes:
1) Se han incluido las siguientes propiedades:
a. query: Representa el objeto array de tipo JSON que contiene
la consulta MQL en el formato del API utilizado. Almacena
tanto la consulta para la obtención de todas las
enfermedades como la de todos los síntomas o todos los
tratamientos que se desean recuperar desde Freebase.
Estos valores se asignan en diferentes métodos, que se
explicarán más abajo, permitiendo así diferenciar, en caso
de que se deseara, el tipo de extracción llevada a cabo para
cada uno de los Tipos de Freebase. Las consultas en el
formato JSON construidas desde el código Java son las que
se muestran en la Tabla 12.
Tabla 12. Consultas MQL implementadas en la clase para la recuperación de información de
Freebase a través del API.
EXTRACCIÓN DEL ARRAY DE DATOS DE ENFERMEDADES
a(o("type", "/medicine/disease", "name~=", "*"+this.fbparam+"*",
"id",null,"name",null,"optional",false,"limit",this.limit, "sort","name",
"/common/topic/article",o("guid",null,"limit",1,"optional",true)));
EXTRACCIÓN DEL ARRAY DE DATOS DE SÍNTOMAS
a(o("type", "/medicine/symptom", "name~=", "*"+this.fbparam+"*",
"id",null,"name",null,"optional",false,"limit",this.limit, "sort","name",
"/common/topic/article",o("guid",null,"limit",1,"optional",true)));
EXTRACCIÓN DEL ARRAY DE DATOS DE TRATAMIENTOS
a(o("type", "/medicine/medical_treatment", "name~=", "*"+this.fbparam+"*",
"id",null,"name",null,"optional",false,"limit",this.limit, "sort","name",
"/common/topic/article",o("guid",null,"limit",1,"optional",true)));
100
DESARROLLO DEL SISTEMA BIOMÉDICO
b. envelope: Representa el objeto en formato JSON del
envoltorio aplicado a la consulta MQL. Este envoltorio sirve
fundamentalmente para, por un lado, fraccionar la consulta
de los conceptos en varias partes (evitando así problemas
de timeout en la conexión con el servidor de Freebase en
caso de respuestas demasiado largas) y, por otro lado,
permitir la consulta a los conceptos en diferentes idiomas.
Para fragmentar la consulta se hace uso de dos parámetros
en el envoltorio (cursor y page) y uno en la consulta MQL
(limit): cursor devuelve un valor false en caso de no existir
más páginas, en page se indica el número de página que se
desea obtener (comenzando en 0) y limit, en el cuerpo de la
consulta MQL, indica el número de resultados que se
desean obtener por página. El envoltorio es el mismo para
las tres consultas MQL, tal y como se muestra en la Tabla
13.
Tabla 13. Envoltorio para las consultas MQL implementadas en la clase para la recuperación
de información de Freebase a través del API.
ENVOLTORIO DE LAS CONSULTAS
o("page", this.page,"cursor", true, "lang", "/lang/"+this.lan);
c.
fbparam: Representa el filtro aplicado en el nombre de la
enfermedad, el síntoma o el tratamiento, dependiendo de la
query con la que se esté trabajando. Para recuperar todos
los valores se le asignará la cadena vacía ("").
101
DESARROLLO DEL SISTEMA BIOMÉDICO
d. limit: Se utiliza para limitar el número de resultados por
página. Si el número máximo de resultados es superior a
este límite, la consulta se irá obteniendo hasta que el
parámetro cursor, incluido en el envoltorio de la consulta,
devuelva false.
e. page: Empleado para la paginación de los resultados,
incrementándose en el método correspondiente hasta que
el valor cursor sea false.
2) Los
métodos
queryFBDisease(),
queryFBSymptom()
y
queryFBTreatment(): construyen las diferentes consultas MQL para
obtener los nombres de los tópicos correspondientes a las
enfermedades, los síntomas y los tratamientos (tal y como se
indican en la Tabla 12), así como los envoltorios correspondientes
(indicado en la Tabla 13).
3) El método doQuery(String fbtype): es el encargado de ejecutar la
consulta correspondiente y devolver la respuesta en forma de
cadena (String). En función del parámetro fbtype (que puede tomar
los valores "Disease", "Symptom" o "Treatment") ejecuta cada una
de las consultas haciendo uso del API.
4) El método loadListFile(String filePath, JSONArray jsonres, String
group, boolean append): utilizado para guardar la información,
obtenida en el array de datos resultante tras ejecutar la consulta a
través del API (enviada en el parámetro jsonres), en el formato
adecuado para su procesado desde el Gazetteer. El fichero en el que
se guarda la información (con extensión "lst") se indica en el
parámetro filePath. El parámetro group se corresponde con la
característica de anotación "groups". El último parámetro, append,
102
DESARROLLO DEL SISTEMA BIOMÉDICO
se utiliza para ir agregando (si corresponde) los resultados de las
diferentes páginas para la misma consulta en el mismo fichero, en
caso de que tenga más de una página (es decir, en el caso de que el
número de resultados supere el parámetro limit establecido, para
un determinado Tipo).
5) El método loadResults(String fbpath, String fbtype): este método
genera el conjunto necesario de consultas, para el Tipo enviado por
parámetro en fbtype, recuperando la totalidad de los resultados y
llamando al método loadFileList con los parámetros adecuados para
insertar los resultados iniciales y agregarlos mientras queden
páginas de resultados. Dispone de un mecanismo de contingencia
ante fallos de comunicación, repitiendo la consulta en caso de fallo.
6) El método principal main: lleva a cabo las llamadas al método
loadResults, tras establecer adecuadamente el idioma de la
consulta, el Tipo y los ficheros con extensión "lst" en los que se han
de almacenar los resultados.
A diferencia del preprocesado con otras fuentes, en las que se ha generado
una única lista para los conceptos en inglés y otra para los conceptos en
español, al hacer uso de Freebase se han decidido generar tres ficheros
distintos para cada idioma, uno por cada Tipo semántico (para las
enfermedades se han denominado diseaseen.lst y diseasesp.lst; para los
síntomas se han denominado symptomen.lst y symptomsp.lst; mientras que
para
los
tratamientos
se
han
denominado
treatmenten.lst
y
treatmentsp.lst). Esta decisión se debe a que las consultas, para la obtención
de los términos similares de cada uno de los Tipos, requieren la
103
DESARROLLO DEL SISTEMA BIOMÉDICO
recuperación de Propiedades distintas en Freebase, tal y como se explicará
con más detalle en la tercera sección de este capítulo.
MedlinePlus
Para recuperar la información de MedlinePlus a partir de los ficheros XML,
se ha creado una clase Java que se encarga de capturar el fichero XML,
accesible a través del protocolo HTTP, y extraer la información que formará
parte de la lista de conceptos para la anotación con el Gazetteer. Esta clase
se ha denominado MPLXMLToFile y está compuesta por los siguientes
métodos:
1) xmlToList(). Se encarga de procesar el XML y almacenar en memoria
los listados de términos y las características extraídas para cada
término. En concreto, para cada nodo MedicalTopic del XML, se
almacenan:
a. El valor del atributo langcode del tópico, que servirá para
discernir si el concepto está en español o en inglés. Este
atributo puede tomar los valores "English" o "Spanish".
b. El valor del nodo MedicalTopicName, que es el nombre del
tópico con el que se realizará la anotación.
c. El valor del nodo URL, que es la dirección de la página Web
de MedlinePlus donde está publicada la información sobre
el tópico.
d. El listado de valores del nodo Groups, donde cada uno de
sus hijos representa uno de los grupos de MedlinePlus a los
que pertenece el tópico.
104
DESARROLLO DEL SISTEMA BIOMÉDICO
e. El listado de valores del nodo Synonyms, donde cada uno de
sus hijos representa los sinónimos del concepto asociados
por MedlinePlus.
2) loadListFileLan(String filePath,String lan). Se encarga de almacenar
en el fichero, indicado en el parámetro filePath, los términos del
idioma indicado en el parámetro lan (que puede tener los valores
"English" o "Spanish"). Los términos son almacenados en el formato
de las listas utilizadas por el Gazetteer de GATE, incluyendo la
cadena para la anotación y las características "url" y "groups".
También agrega los sinónimos de los términos con los mismos
valores de las características "url" y "groups" del término.
3) main. Desde el método principal se realiza la llamada a ambos
métodos, imprimiendo por pantalla varios datos de interés: Un
recuento del total de tópicos, el número de tópicos en inglés y el
número de tópicos en español (capturado desde el nodo principal
MedicalTopics por el método xmlToList()). Esto permite fácilmente
saber no sólo el número de tópicos disponibles en cada idioma para
un determinado fichero XML, sino también la expansión de términos
que se consigue al ampliar el listado con los sinónimos. Por ejemplo,
en el caso del fichero del 18/02/2012 (mplus_vocab_2012-0218.xml), el total de tópicos de MedlinePlus en inglés es de 921,
mientras que en español es de 896. Sin embargo, al procesar los
sinónimos, el total de términos incluidos en el listado en inglés es de
1.645 y en español es de 1.716. Esto supone una ampliación del 79%
en el caso del listado en inglés y del 92% del listado en español.
105
DESARROLLO DEL SISTEMA BIOMÉDICO
SNOMED CT
Para llevar a cabo el preprocesado de la información de esta fuente de
términos, el primer requisito es obtener la distribución en español de la
terminología. Esta distribución, tal y como ya se indicaba en el tercer
apartado de la primera sección del capítulo anterior, contiene la lista de
términos en inglés y la lista de descripciones en español, ambos en un
formato de texto tabulado. Tras el análisis de los datos contenidos en estos
ficheros se ha desarrollado un procedimiento, basado en el reemplazo de
patrones (haciendo uso de la herramienta notepad++, aunque fácilmente
implementable en Java), con el que es posible obtener las dos listas de
conceptos en el formato para el Gazetteer de GATE. A continuación se
describen los pasos seguidos en el procedimiento desarrollado para el
conseguir preprocesado final de los datos:
1) Primer paso. En ambos ficheros hay que reemplazar todos los
caracteres "&" por otro carácter, ya que se ha utilizado este símbolo
para delimitar las características utilizadas por el Gazetteer en el
proceso de anotación del texto. Además, este carácter no es común
utilizarlo en la redacción de textos. El reemplazo en este primer
paso consiste en sustituir todos los & que aparecen en los ficheros
por el texto "and", en el caso del fichero en inglés, y por el texto "y"
en el caso del fichero de descripciones en español.
2) Segundo paso. En este segundo paso se procede a la eliminación de
los conceptos que no forman parte de la versión actual de la
terminología, en el caso del fichero de términos, y los conceptos que
además no se refieren al nombre completo correspondiente, en el
caso del fichero de descripciones en español. Al finalizar el
106
DESARROLLO DEL SISTEMA BIOMÉDICO
procedimiento indicado en este segundo paso se obtendrán el
número total de términos con los que funcionará finalmente el
sistema (que es de 295.542 en la versión seleccionada). Puesto que
el formato de ficheros es distinto, para llevar a cabo este segundo
paso hay que proceder de manera distinta al trabajar con el fichero
de términos y con el fichero de descripciones.
a. En el fichero de términos es necesario eliminar aquellos
registros cuyo CONCEPTSTATUS es distinto de 0, ya que es
éste el valor que indica que el concepto pertenece a la
versión actual. Para eliminar estos registros se hace uso del
patrón ([0-9]+)\t0\t(.*)\t.*, que permite localizar los
registros con el valor 0 en el campo indicado. Con la utilidad
de marcar las líneas del programa notepad++, se procede a
marcar siguiendo este patrón y después a eliminar las líneas
no marcadas (con la opción buscar->marcador->borrar no
marcadas).
b. En el fichero de descripciones es necesario eliminar aquellos
registros cuyo DESCRIPTIONTYPE sea distinto de 3 (que se
refiere al valor FullySpecifiedName), lo que directamente
tiene el mismo efecto que el filtro aplicado al fichero de
términos. Para eliminar estos registros se utiliza el patrón
([0-9]+)\t0\t([0-9]+)\t(.*\))\t.*[0-9]\t3\t.*,
que
localiza
todos los registros con el valor 3 en el campo indicado. A
continuación se procede como en el caso del fichero de
términos, marcando las líneas y borrando las no marcadas.
3) Tercer paso. En este paso se mueve el CONCEPTID (identificador de
SNOMED CT) al final, agregándolo como la característica "url" para
107
DESARROLLO DEL SISTEMA BIOMÉDICO
la anotación. Basta utilizar los patrones del paso dos e indicar
adecuadamente los valores por los que se quiere reemplazar en
cada caso.
a. En el fichero de términos se reemplaza el patrón del paso
anterior, ([0-9]+)\t0\t(.*)\t.*, por \2&url=\1, dando como
resultado un fichero con todos los conceptos seguidos de la
característica "url".
b. En el fichero de descripciones se reemplaza el patrón del
paso
anterior,
([0-9]+)\t0\t([0-9]+)\t(.*\))\t.*[0-9]\t3\t.*,
por \3&url=\2, dando como resultado un fichero análogo al
resultante del fichero de términos.
4) Cuarto paso. En este paso se situará la clasificación del término que
se hace en SNOMED CT como la característica de anotación
"groups". Esta característica viene indicada entre paréntesis justo en
la zona derecha del término, por lo que habrá que buscar el último
valor entre paréntesis que aparezca para cada registro (hay registros
que contienen más de un dato entre paréntesis). Para mover el
dato,
se
utiliza
el
patrón
\s*\(([^\)\(]*?)\)&url=([0-9]+),
reemplazándolo por el valor &url=\2&groups=\1.
Si en el procedimiento existiese algún problema con la codificación de los
ficheros (si se usa UTF-8 esto no debería ser un problema en el
procedimiento indicado, siempre y cuando se mantenga esta codificación en
el Gazetteer), el propio notepad++ dispone de conversiones entre las
diferentes codificaciones.
108
DESARROLLO DEL SISTEMA BIOMÉDICO
También se han preprocesado las listas de términos correspondientes al
subconjunto CORE, aunque el procedimiento es distinto. En primer lugar se
han cargado los datos del subconjunto en inglés y de todas las descripciones
en español en tablas de una base de datos MySql:
LOAD DATA LOCAL INFILE
'SNOMEDCT_CORE_SUBSET_201202.txt'
INTO TABLE snomed.coresubset
CHARACTER SET 'latin1'
FIELDS TERMINATED BY '|'
LINES TERMINATED BY '\n'
IGNORE 1 LINES;
LOAD DATA LOCAL INFILE
'sct1_Descriptions_es_INT_20111031.txt'
INTO TABLE snomed.descripciones
CHARACTER SET 'UTF8'
FIELDS TERMINATED BY '\t'
LINES TERMINATED BY '\n'
IGNORE 1 LINES;
En segundo lugar se ha creado un script para cargar estos datos en 2
ficheros, uno conteniendo los términos en inglés y otro en español:
SELECT
SNOMED_FSN,
snomed.descripciones
SNOMED_CID
where
FROM
SNOMED_CID
snomed.coresubset,
=
CONCEPTID
and
DESCRIPTIONTYPE = 3 and LANGUAGECODE = "es"
INTO OUTFILE 'sctcoreen_temp.lst'
FIELDS TERMINATED BY '&'
LINES TERMINATED BY '\n';
SELECT
TERM,
SNOMED_CID
snomed.descripciones
where
FROM
SNOMED_CID
snomed.coresubset,
=
CONCEPTID
and
DESCRIPTIONTYPE = 3 and LANGUAGECODE = "es"
INTO OUTFILE 'sctcoresp_temp.lst'
109
DESARROLLO DEL SISTEMA BIOMÉDICO
FIELDS TERMINATED BY '&'
LINES TERMINATED BY '\n';
Y, por último, se ejecuta el proceso de reemplazo de la cadena
(.*)\s*\((.*)\)&(.*) por la expresión \1&url=\3&groups=\2.
2. Anotación e integración de fuentes
Integración con GATE
Tal y como se describió en el primer apartado de la primera sección del
capítulo anterior, la integración de los ficheros preprocesados, a partir de las
diferentes fuentes de conocimiento, está fundamentalmente basada en la
versatilidad de la arquitectura de GATE. Por un lado, GATE permite la
generación de un flujo de procesado desde su aplicación de escritorio y el
almacenamiento de este flujo en un fichero de aplicación con extensión
"gapp". Por otro lado, incluyendo las librerías necesarias (las incluidas en los
directorios bin y lib de la distribución de GATE), los plugins de GATE
utilizados y algunos ficheros de aplicación (gate.xml y user-gate.xml), es
posible trabajar desde el lenguaje de programación Java (instanciando la
aplicación "gapp" generada), para después ejecutarlo como una aplicación
independiente o como una aplicación Web instalada bajo un servidor Web.
La creación del flujo de aplicación "gapp", que se ejecutará desde el código
Java desarrollado, se puede llevar a cabo desde el GUI de aplicación de
GATE, aunque dado que el fichero "gapp" está en formato XML, también es
posible trabajar directamente con él sin utilizar el GUI. No obstante, la
utilización del GUI reduce notablemente la complejidad al ir añadiendo
diferentes recursos, siendo también un soporte muy cómodo para agregar
diferentes corpus y ejecutar las pruebas que se consideren oportunas sin
110
DESARROLLO DEL SISTEMA BIOMÉDICO
necesidad de desarrollo alguno. El flujo de aplicación se puede crear como
un Corpus Pipeline, que se diferencia del Pipeline en que proporciona la
posibilidad de probar sobre conjuntos de documentos (imagen superior de
la Fig. 15).
Figura 15 Procedimiento para la creación del flujo de aplicación desde el GUI de GATE.
111
DESARROLLO DEL SISTEMA BIOMÉDICO
Para nuestros propósitos particulares se ha generado un Corpus Pipeline con
el nombre CLEiM y se han cargado los recursos del sistema ANNIE
(enmarcado en rojo en la imagen superior de la Fig. 15). A continuación se
genera un nuevo recurso basado en el Gazetteer del sistema ANNIE (imagen
intermedia de la Fig. 15), estableciéndose el nombre del mismo, la detección
independiente de mayúsculas o minúsculas (caseSensitive = false), el
separador de características (&) y el fichero en el que se definen las listas
que se han preprocesado (denominado medicine.def). El total de conceptos
incluidos en las listas referenciadas en el fichero medicine.def es de 312.348
en inglés, y de 299.992 en español, para el preprocesado realizado a fecha
de 25 de Febrero de 2012. El total de conceptos para cada fuente e idioma
es el que se muestra en la Tabla 14.
Tabla 14. Total de conceptos para cada una de las fuentes de conocimiento preprocesadas.
FUENTE
FICHERO
IDIOMA TOTAL CONCEPTOS
Freebase
diseaseen.lst
Inglés
9.478
Freebase
symptomen.lst
Inglés
1.850
Freebase
treatmenten.lst
Inglés
3.833
MedlinePlus
mlpen.lst
Inglés
1.645
SNOMED CT
scten.lst
Inglés
295.542
Freebase
diseasesp.lst
Español
1.482
Freebase
symptomsp.lst
Español
471
Freebase
treatmentsp.lst
Español
781
MedlinePlus
mlpsp.lst
Español
1.716
SNOMED CT
sctsp.lst
Español
295.542
A continuación, desde el menú de recursos de lenguaje (Language
Resources) se crea un corpus vacío (al que se le ha denominado MIMIC-II).
Este corpus se puebla agregando el directorio en el que se encuentran los
ficheros de texto que se desean procesar, como podría ser, por ejemplo, el
112
DESARROLLO DEL SISTEMA BIOMÉDICO
caso de los informes médicos y las notas clínicas adquiridos con los datos
restringidos del proyecto MIMIC-II56. Por último, se agrega el Gazetteer
generado, y previamente configurado, a la aplicación CLEiM (imagen inferior
de la Fig. 15), se asigna un nombre a las anotaciones (Medicine) y se
establecen los parámetros longestMatchOnly a false (que provocará la
detección de más de una entidad sobre un conjunto común de palabras, si
es que se da el caso) y wholeWordsOnly a true (que adopta como unidad
mínima la palabra, no detectando entidades menores que coincidan con los
términos de las listas). Esto permite ejecutar el proceso sobre el corpus
MIMIC-II. La aplicación se puede almacenar utilizando la opción Save
Application State, disponible con el botón derecho sobre el nombre de la
misma.
Una vez guardado el flujo de aplicación, al que se le ha denominado
CLEiM.gapp, ya se dispone de todo lo necesario para implementar la clase
Java desde la que se recogerán, procesarán y, posteriormente, permitirá la
fusión las entidades médicas reconocidas de este modo. La clase Java
desarrollada para tal fin se ha denominado GateGazMed y contiene las
siguientes propiedades y métodos:
1) La propiedad annotTypesToWrite es la lista de cadenas (List<String>)
en la que se almacenan los nombres de las anotaciones que se
desean extraer. Ya que únicamente se ha generado un tipo de
anotación llamada Medicine, esta lista sólo extraerá estas
anotaciones. Si se agregaran anotaciones de otros dominios o se
hicieran anotaciones más específicas dentro del dominio médico,
56
http://mimic.physionet.org/
113
DESARROLLO DEL SISTEMA BIOMÉDICO
por ejemplo, esta lista se ampliaría para contener los nombres
asignados a estas otras anotaciones.
2) La
propiedad
vAnnotListMinor
es
un
vector
de
cadenas
(Vector<String>) que sirve para almacenar la propiedad minor de
aquellas listas que se desean utilizar (incluido en el fichero
medicine.def). Es decir, en el constructor de la clase se inicializará
agregándole los siguientes valores:
a. Los correspondientes a los listados en inglés y en español
recuperados desde Freebase: "disease", "symptom" y
"treatment".
b. El correspondiente a los listados en inglés y en español
recuperados desde MedlinePlus: "medlineplus".
c. El valor correspondiente a los listados en inglés y en español
recuperados desde SNOMED CT: "snomed".
Estos valores se han hecho coincidir con las páginas jsp encargadas
de recuperar más información desde el sistema utilizando la fuente
original, si es que es el caso. En concreto, las anotaciones a las que
se les ha asociado esta dirección URL local son las realizadas con
Freebase en inglés (disponiéndose de las páginas disease.jsp,
symptom.jsp y treatment.jsp), MedlinePlus en inglés (disponiéndose
de la página medlineplus.jsp) y SNOMED CT en inglés (disponiéndose
de la página snomed.jsp, que en este caso es una réplica de la
página de búsqueda de MedlinePlus: medlineplus.jsp).
3) Las propiedades vAnnotList, vAnnotListLan, vAnnotListSource,
vAnnotListGroup, vAnnotListFrom, vAnnotListTo y vAnnotListUrl, son
los vectores de listas de cadenas (Vector<List<String>>) utilizados
para almacenar las listas de datos asociados con cada uno de los
114
DESARROLLO DEL SISTEMA BIOMÉDICO
valores del vector vAnnotListMinor. Siguiendo el orden en el que
están puestos, almacenan: el texto que ha sido anotado, el idioma,
la fuente de conocimiento que ha permitido la detección (obtenido
a partir de la propiedad major incluida para cada lista en el fichero
medicine.def), el grupo al que pertenece el concepto según su
fuente de conocimiento, la posición inicial del texto detectado en el
conjunto del texto procesado, la posición final del texto detectado
en el conjunto del texto procesado y la URL externa a través de la
que se puede acceder a más información. Las dimensiones de estos
vectores, por tanto, depende de la dimensión establecida para el
vector vAnnotListMinor.
4) El método initGate() se encarga de configurar las rutas a los ficheros
que necesita GATE para ser inicializado, así como su inicialización. En
primer lugar, configura como directorio raíz de GATE (home) el
directorio de aplicación web WEB-INF (de este modo GATE puede
cargar el fichero gate.xml y el directorio plugins, que deben estar
situados en este directorio). En segundo lugar, configura el fichero
de configuración de usuario (user-gate.xml), haciendo uso del
directorio raíz establecido. En tercer lugar, inicializa GATE. También
se encarga de comprobar si el directorio raíz está ya establecido o
de si GATE ya ha sido inicializado, para no repetir la operación de
nuevo.
5) El método runGazetteer(String sDocText, String sGapp) es el
responsable del procesado del texto enviado en el parámetro
sDocText. Para llevar a cabo la tarea de procesado sigue los
siguientes pasos:
a. Llama al método initGate().
115
DESARROLLO DEL SISTEMA BIOMÉDICO
b. Carga la aplicación "gapp" indicada en el parámetro sGapp
(que debe estar situada también en el directorio WEB-INF).
La parametrización de este dato hace posible utilizar
estáticamente todas las listas incluidas en el fichero
medicine.def, que es llamado desde el fichero de aplicación
CLEiM.gapp, o la generación dinámica de las listas en un
fichero temporal que es definido como una constante y
llamado desde un fichero de aplicación alternativo
denominado CLEiMtmp.gapp.
c. Crea un corpus con el documento en cuestión, lo procesa y
limpia el corpus de la memoria, dejando el documento
anotado en memoria.
d. Itera por cada uno de los valores de la propiedad
annotTypesToWrite, que tal y como se mencionaba
anteriormente sólo contendrá el valor "Medicine".
e. Para cada una de las anotaciones examina el índice
correspondiente a su característica minorType dentro de la
lista vAnnotListMinor, agregando los valores en el índice
correspondiente para cada una de las listas incluidas a
través de las propiedades explicadas en el punto 3).
6) Los
métodos
getMinor(),
getAnnot(),
getAnnotLan(),
getAnnotSource(), getAnnotGroup(), getAnnotFrom(), getAnnotTo()
y getAnnotUrl(): son utilizados para obtener los vectores ó vectores
lista de las propiedades, mencionadas en los puntos 2) y 3), desde
otra clase Java.
116
DESARROLLO DEL SISTEMA BIOMÉDICO
Una vez extraídos los datos de las anotaciones realizadas sobre el texto
haciendo uso de los métodos get de la clase GateGazMed, es posible
preparar un interfaz en el que se fusione toda esta información. Un ejemplo
para llevar a cabo este proceso en la salida estándar se muestra en la Fig. 16,
donde se da por hecho que las variables path (ruta del directorio WEB-INF),
text (el texto que se desea procesar) y sGapp (la ruta al fichero de aplicación
"gapp") están ya definidas y asignadas.
Figura 16 Ejemplo de código Java que utiliza las anotaciones realizadas por la clase
GateGazMed, a partir de las diferentes fuentes, para integrar la información en la salida
estándar.
Integración de los servicios de anotación remota
Para la elaboración de las clases Java que dan acceso a los servicios Web
(REST) del NCBO, se ha utilizado la librería HttpClient (desarrollada por la
comunidad Apache Software Foundation57). Desde Junio de 2011, el acceso
57
http://hc.apache.org/httpcomponents-client-ga/
117
DESARROLLO DEL SISTEMA BIOMÉDICO
a estos servicios requiere la obtención de una clave, que ha de incluirse en
las peticiones HTTP, y del email del desarrollador, que se han incorporado a
través de los parámetros correspondientes (key y email, respectivamente).
Tanto el servicio Web que proporciona información sobre el conjunto total
de ontologías con las que se puede anotar, como el servicio de anotación
OBA, poseen la siguiente URL base: http://rest.bioontology.org/obs/.
Agregando a esta URL base el valor "ontologies" es posible obtener el listado
completo de ontologías mencionado, en formato XML, y es precisamente
este servicio Web el utilizado en el cliente, desarrollado en la página jsp
ncbolist.jsp, que permite filtrar por los campos ID (identificador asignado por
el NCBO para la ontología), NAME (nombre de la ontología), VERSION
(versión o fecha del conjunto de datos original integrado bajo el servicio),
STATUS (para poder filtrar aquellas integradas en el OBA, cuyo valor es 28) y
FORMAT (el formato original de la ontología integrada).
Agregando a la URL base el valor " annotator" se obtiene acceso al servicio
OBA, habiéndose codificado en dos clases Java. En una de las clases
(denominada CallNCBO) se gestiona la petición HTTP al servicio Web, toda la
parametrización y la recogida de la cadena resultante. La otra clase Java es
semejante a la clase encargada del proceso de anotación con GATE
(GateGazMed), procesando la salida de la clase CallNCBO e incorporando los
resultados en listas de cadenas, que serán fácilmente utilizables desde otras
clases o desde una página jsp. A esta clase se le ha denominado NCBOAnnot.
Las propiedades y métodos implementados en la clase CallNCBO son los
siguientes:
1) Las
propiedades
longestOnly,
text,
ontologiesToKeepInResult,
wholeWordOnly,
filterNumber,
levelMax,
stopWords,
withDefaultStopWords, withSynonyms, scored, ontologiesToExpand,
118
DESARROLLO DEL SISTEMA BIOMÉDICO
semanticTypes y format, permiten la parametrización de la petición
a través de los métodos set correspondientes (que en el mismo
orden son: setText, setOntInRes, setLevelMax, setLongestOnly,
setWholeWordOnly,
setWithDefaultStopWords,
setOntologiesToExpand,
setFilterNumber,
setStopWords,
setWithSynonyms,
setSemanticTypes
y
setScored,
setFormat).
El
significado de estos parámetros es el siguiente, siguiendo el orden
en el que se muestran: el texto a procesar (es necesario inicializar),
los identificadores concatenados con el carácter ',' de las ontologías
con las que se desea anotar (es necesario inicializar), la profundidad
de las relaciones jerárquicas parentales que se desean utilizar en el
proceso de anotación (inicializado a 0, indicando que únicamente se
desean las extracciones directas), la anotación de los conceptos más
largos únicamente (inicializado a false, indicando que no se haga de
este modo), la anotación de las palabras completas únicamente
(inicializado a true, indicando que se lleve a cabo de este modo), el
filtro numérico en el procesado del texto (inicializado a false,
indicando que no se filtren los números), el conjunto de palabras
vacías, seguido de la utilización de la lista de palabras vacías
establecido por defecto (inicializados a null y true, que indica que se
utilicen las establecidas por defecto), la obtención de sinónimos
para los conceptos anotados (inicializado a true, indicando que se
muestren estos sinónimos), la exactitud de la anotación (inicializado
a true, que quiere decir que se devuelva este valor de exactitud
calculado por el servicio), las ontologías con las que expandir las
anotaciones, seguido de los tipos semánticos con los llevar a cabo la
expansión (inicializados a vacío, es necesario inicializar con los
119
DESARROLLO DEL SISTEMA BIOMÉDICO
listados, tanto de ontologías como de tipos semánticos, para poder
obtener resultados relacionados semánticamente con los conceptos
anotados) y, por último, el formato de salida (inicializado a XML).
2) El método doRESTQuery: es el responsable de hacer la petición al
servicio con la parametrización seleccionada y recuperar los
resultados en una cadena de texto.
Las propiedades y métodos más relevantes que constituyen la clase
NCBOAnnot son los siguientes:
1) Las propiedades lConcept, lGroup, lLocalOntologyId, lFullId, lIsDirect,
lFrom, lTo y lPreferredName: son las listas de cadenas (List<String>)
en las que se almacenan los valores de interés para cada una de las
anotaciones. Estas propiedades guardan los valores resultantes de la
petición al servicio OBA, que en el orden de aparición se
corresponden con: el término anotado en el texto (según los índices
de posicionamiento from y to), el tipo semántico asignado, el
identificador de la ontología con la que ha sido anotado el concepto,
la URL al árbol jerárquico de la ontología integrada por el servicio
OBA, un indicador de si se trata de una anotación directa (true, si es
directa, false si es encontrada a través de relaciones parentales en la
jerarquía de la ontología), el índice del texto en el que comienza el
texto anotado y el índice del texto en el que finaliza el texto anotado
y, por último, el nombre del concepto reconocido en la ontología.
2) Los métodos get desarrollados para recuperar las listas de datos
desde una clase externa, nombrados del siguiente modo:
getConcept, getGroup, getLocalOntologyId, getFullId, getIsDirect,
getFrom, getTo y getPreferredName.
120
DESARROLLO DEL SISTEMA BIOMÉDICO
3) El método runNCBOAnnot (String text, String onts, String lev): realiza
la llamada a la clase CallNCBO, estableciendo, a través de los
métodos set de ésta, el texto a anotar (recibido a través del
parámetro text), las ontologías con las que llevar a cabo la anotación
(identificadores separados por el carácter ',' enviadas en el
parámetro onts) y el nivel de profundización en la jerarquía de las
ontologías (a través del parámetro lev, que si vale 0 sólo obtiene
anotaciones directas, pero para valores mayores es capaz de
localizar conceptos relacionados con otros conceptos, de forma
indirecta). A continuación procesa el XML resultante de la petición,
recogiendo: (a) del nodo con la etiqueta concept los valores de los
hijos correspondientes a los valores para las listas lLocalOntologyId
(del nodo con la etiqueta localOntologyId), lFullId (del nodo con la
etiqueta fullId) y lPreferredName (del nodo preferredName); (b) de
este mismo nodo, recorre el nodo hijo con la etiqueta
semanticTypes hasta localizar el texto correspodiente a la
descripción (etiqueta description), que es empleado para almacenar
el valor de la lista lGroup; (c) del nodo con la etiqueta context
recupera los valores para las listas lIsDirect (del nodo con la etiqueta
isDirect), lFrom y lTo (de los nodos etiquetados como from y to).
Finalmente, extrae el concepto anotado del texto original haciendo
uso de los valores lFrom y lTo, insertándolo en la lista lConcept.
Integración de las anotaciones locales y remotas
Una vez son realizadas las anotaciones locales, a través de la librería
proporcionada por el software GATE, y las remotas, a través de las
peticiones al servicio OBA del NCBO, se ha desarrollado un componente de
121
DESARROLLO DEL SISTEMA BIOMÉDICO
integración para unificar todas estas anotaciones locales y remotas. Este
elemento permite encapsular la integración de información para,
posteriormente, hacer uso desde los componentes correspondientes del
módulo CAI, sin necesidad de repetir la operación para cada uno de los
clientes de acceso desarrollados.
Este componente de integración perteneciente al módulo PLN ha quedado
sintetizado en la clase Java IntegrateAnnot. Para comprender mejor el
proceso llevado a cabo, es necesario entender el paralelismo existente entre
las listas de datos recuperados a partir de las anotaciones locales y las listas
de datos recuperados de las anotaciones remotas (Tabla 15).
Tabla 15. Paralelismo entre los datos de las anotaciones locales y los procedentes de las
anotaciones remotas.
Vector de la clase GateGazMed
Lista de la clase NCBOAnnot
vAnnotList
lConcept / lPreferredName
vAnnotListLan
"en"
vAnnotListSource
lLocalOntologyId
vAnnotListGroup
lGroup
vAnnotListFrom
lFrom
vAnnotListTo
lTo
vAnnotListUrl
lFullId / lConcept
"true"
lIsDirect
Cuando la anotación remota conlleva únicamente anotaciones directas
(indicado esto a través del parámetro lev con valor 0), entonces el concepto
anotado tiene una correspondencia inmediata en ambos casos: se toma el
texto delimitado por los índices de las listas correspondientes a los valores
from y to que también tienen una correspondencia directa (aunque esto es
tan solo una simplificación y no tiene por qué ser necesariamente así, ya que
122
DESARROLLO DEL SISTEMA BIOMÉDICO
la anotación remota podría darnos también sinónimos). Sin embargo,
cuando en el proceso de anotación remota se indica un nivel de profundidad
(lev mayor que 0), entonces se diferenciará entre el término que aparece en
el texto y el concepto localizado en la ontología (obtenido de la lista
lPreferredName). Por otro lado, debido a que, hasta el momento, el servicio
OBA únicamente procesa textos en inglés, no existe una lista que tenga una
correspondencia con la almacenada en el vector vAnnotListLan, que
almacena el identificador del idioma. Cuando se realiza la anotación con el
sistema GATE, las listas se almacenan en vectores debido a que se utilizan
varias fuentes (utilizándose una lista para cada una de ellas), mientras que
cuando se realizan las anotaciones remotas la identificación de la fuente con
la que se anota viene determinada por el identificador de la ontología. De
manera que la lista resultante de la anotación remota, que se corresponde
con la lista almacenada en el vector vAnnotListSource, es la que indica la
ontología. En el caso de la lista que almacena la dirección URL remota en la
que obtener más información sobre el concepto anotado (el vector
vAnnotListUrl para la anotación local con GATE), se utilizan diferentes
estrategias para construirla en el caso de la anotación remota. Si la entidad
anotada procede de la ontología MedlinePlus Health Topics, la dirección URL
se compone de la llamada al sitio Web de MedlinePlus concatenándole el
concepto anotado. Sin embargo, si la anotación se realiza a través de la
ontología SNOMED CT, entonces se compone concatenándole el
identificador de esta fuente, que viene incluido como parte de la dirección
URL obtenida a través del fullId.
Siguiendo la nomenclatura del OBA, se puede decir que las anotaciones
locales son todas directas, ya que no se hace un reconocimiento de
conceptos en ninguna ontología. Sin embargo, las anotaciones remotas
123
DESARROLLO DEL SISTEMA BIOMÉDICO
pueden ser indirectas cuando el parámetro de profundidad ya mencionado
(lev) es mayor que 0. En este caso se construye el concepto anotado a través
de ambos valores: el nombre preferido a la izquierda (nombre del concepto
reconocido en la ontología) y el término del texto a la derecha, indicándose
con una flecha que va desde el concepto hacia el nombre preferido el caso
de anotación directa, o con una flecha que va desde el nombre preferido
hacia el concepto el caso de anotación indirecta. El enlace para obtener
información más detallada utiliza el concepto reconocido en la ontología
como término de búsqueda.
A continuación se describe con mayor detalle el proceso de integración
llevado a cabo con la clase IntegrateAnnot, a través de sus propiedades y
métodos:
1) Las propiedades text, gatePath, onts, lev, localSrc y localLan:
almacenan, respectivamente, el texto objeto de la anotación, la
ruta relativa de GATE (que se enviará de forma dinámica desde los
servlets del módulo CAI), los identificadores de las ontologías del
NCBO con las que llevar a cabo la anotación, el nivel de profundidad
deseado para la búsqueda en la jerarquía de las mismas, las fuentes
locales con las que anotar y los idiomas aplicados a las fuentes
locales. Estos parámetros se establecen en el constructor de la
clase, que requerirá estos seis parámetros.
2) Las propiedades document y root: representan el documento XML y
su nodo raíz, utilizado para dar la respuesta de todas las
anotaciones fusionadas en este formato.
3) El método remRepeated(List<String> lOrig): dada una lista de
cadenas (parámetro lOrig), devuelve una lista de enteros
(List<Integer>) que se corresponde con los elementos de la lista que
124
DESARROLLO DEL SISTEMA BIOMÉDICO
no están repetidos. Este método será utilizado cuando resulte de
interés eliminar los conceptos anotados varias veces por la misma
fuente, como, por ejemplo, cuando se extraen los resultados en
formato HTML.
4) El método compoundNCBOData (String concept, String localOnt,
String fullId): construye los datos de la fuente (source), la dirección
URL local (localUrl) y la dirección URL externa (url) para las
anotaciones devueltas por el servicio OBA, haciendo uso del
concepto (parámetro concept), el identificador de la ontología
(parámetro localOnt) y la dirección URL al árbol jerárquico de la
ontología en el BioPortal (parámetro fullId). Estos datos los
devuelve en un array de cadena (String []). La fuente se construye
con el texto "OBA" y "MedlinePlus" o bien "Snomed" seguidos del
identificador de la ontología entre paréntesis, dependiendo del
identificador de ambas, o bien directamente el identificador de la
ontología entre paréntesis, para el resto de casos. La dirección URL
local se construye enlazando la página jsp medlineplus.jsp y usando
el concepto como término para la búsqueda. La dirección URL
externa se construye, en el caso de las anotaciones con la ontología
SNOMED CT, usando el identificador de esta ontología (que se
puede extraer del parámetro fullId) y, en el caso de la ontología
MedlinePlus Health Topics, enlazando el árbol jerárquico del
BioPortal.
5) Los métodos gateWithoutFormat y ncboWithoutFormat: crean los
objetos GateGazMed y NCBOAnnot, ejecutando el proceso de
anotación para devolver el objeto al ser instanciados (por los
métodos explicados en el punto siguiente). El primero de ellos
125
DESARROLLO DEL SISTEMA BIOMÉDICO
controla la ejecución del método runGazetteer empleando el
fichero CLEiM.gapp, con todas las fuentes locales, o el fichero
CLEiMtmp.gapp, con las fuentes locales y los idiomas indicados
desde el cliente (enviados en los parámetros localSrc y localLan del
constructor). El segundo ejecuta el método runNCBOAnnot
utilizando los parámetros de la anotación remota (onts y lev).
6) Los métodos htmlGateTree y htmlNCBOTree: recorren cada uno de
los elementos de las anotaciones realizadas por GATE y por el
NCBO, respectivamente, fusionando la información extraída del
proceso de anotación en una cadena compuesta de etiquetas en
formato HTML. Esto lo llevan a cabo llamando, para cada elemento
no repetido (previa llamada al método remRepeated), a los
métodos insertHtmlItem e insertXmlItem, que se explican más
adelante. El método htmlNCBOTree realiza, además, acciones
adicionales: por un lado, utiliza el método compoundNCBOData
para componer los datos ya mencionados: source, localUrl y Url; por
otro lado, comprueba que el valor de profundidad de búsqueda en
las ontologías antes de eliminar los repetidos, ya que si es 0 el
procedimiento de eliminación de repetidos se realiza sobre los
nombres de los conceptos que se corresponden con los datos
almacenados en la lista obtenida a partir del método getConcept
del objeto NCBOAnnot, mientras que si es distinto de 0 entonces el
proceso de eliminación de repetidos se hace a partir de los valores
obtenidos por el método getPreferredName (y el tratamiento del
nombre del concepto detectado es más complejo, tal y como se ha
explicado anteriormente).
126
DESARROLLO DEL SISTEMA BIOMÉDICO
7) Método insertHtmlItem (String name, String lan, String src, String
group, String from, String to, String url, String localUrl): genera un
una fila, de una tabla en formato HTML, cada vez que se instancia.
Las columnas que contienen estas filas son las correspondientes a
los siguientes datos:
a. Idioma. Es el valor del parámetro lan, que indica el idioma
de la fuente de conocimiento con la que se ha llevado la
anotación. Puede contener los valores en, para las
anotaciones en inglés, o sp, para las anotaciones en
español.
b. Concepto. El texto anotado, que se obtiene a partir del
valor del parámetro name. Además, a este dato se le agrega
un hipervínculo a la dirección URL local (parámetro
localUrl), pero sólo en los casos de detección en inglés y
que cuya fuente de conocimiento no sea Snomed
(comprobando los parámetros lan y source). Los valores de
las páginas que pueden estar enlazadas a los conceptos
son: disease.jsp (para los conceptos detectados como
enfermedades de Freebase), symptom.jsp (para los
conceptos detectados como síntomas de Freebase),
treatment.jsp (para aquellos conceptos detectados como
tratamientos de Freebase), medlineplus.jsp (para los
conceptos
detectados
con
las
listas
extraídas
de
MedlinePlus) y snomed.jsp (para los conceptos detectados
con las listas preprocesadas de Snomed, que es una réplica
de la página medlineplus.jsp).
127
DESARROLLO DEL SISTEMA BIOMÉDICO
c. Fuente. Es la fuente de conocimiento que ha permitido la
anotación, ya sea a través de anotación local (en cuyo caso
los valores integrados son "Freebase", "MedlinePlus" y
"Snomed") o de la anotación remota (siendo los posibles
valores "OBA Snomed (46116)", "OBA Medlineplus (40397)"
o "OBA ([identificador de la ontología])").
d. Grupo. Es el valor que en cada uno de los casos se haya
enviado en el parámetro group.
e. URL. La dirección o direcciones URL externas a través de las
que se puede obtener más información de estos conceptos.
Para preparar estos hipervínculos se tiene en cuenta la
siguiente casuística: si la fuente es Snomed (tanto para
anotaciones locales como remotas) se enlaza al servicio
Web MedlinePlus CONNECT en español y en inglés; si la
fuente es MedlinePlus (únicamente para anotaciones
locales) y el idioma es el inglés, se enlazan la página Web de
MedlinePlus en inglés y en español (en este orden), y si el
idioma es el español se enlazan las mismas páginas pero en
orden inverso; en el resto de casos se enlaza directamente
el parámetro url.
8) Métodos initXmlDocument y getNormalizedXml: son los que
preparan el formato adecuado del documento XML que resultará
de la llamada al servicio Web generado, desde el componente
perteneciente al módulo CAI, para dar respuesta a los clientes que
requieran este tipo de datos. Estos métodos deben ser llamados
antes y después, respectivamente, de generar los árboles de datos
correspondientes, que se explican en el siguiente punto. La llamada
128
DESARROLLO DEL SISTEMA BIOMÉDICO
al primero inicializa el nodo raíz del XML (propiedad root) y crea el
nodo "input" con los parámetros de entrada recibidos desde el
cliente (Tabla 16). Tras la llamada al método getNormalizedXml,
que devuelve una cadena de texto, se dispondrá del documento
XML completo.
9) Métodos xmlGateTree y xmlNCBOTree: están provistos de
funcionalidades muy similares a los que generan el árbol en
formato HTML (htmlGateTree y htmlNCBOTree) y serían fácilmente
parametrizables (con un parámetro que indicara el formato, por
ejemplo) para hacer dos métodos únicos con los que procesar los
árboles en los diferentes formatos. Sin embargo, como estos
métodos son instanciados por clientes diferentes, incluir varias
condiciones en su interior iría en contra de la eficiencia de los
mismos, motivo por el que se ha decidido mantener cada uno de
ellos por separado. Las diferencias fundamentales en relación a los
anteriores son: la inclusión de todos los elementos (no se eliminan
los repetidos por cada una de las fuentes) y la llamada al método de
inserción de elementos, que en este caso pasa a ser insertXmlItem,
que se describe a continuación.
10) Método insertXmlItem (String annotType, String concept, String
preferred, String direct, String groups, String lan, String from, String
to, String url, String localUrl): inserta cada uno de los elementos
enviados como parámetros en el documento XML. Haciendo uso
del documento XML, que ha tenido que ser previamente inicializado
con el método initXmlDocument, va agregando un nodo etiquetado
como annotation con estos valores (Tabla 16): la fuente (parámetro
annotType), el concepto reconocido en el texto de entrada
129
DESARROLLO DEL SISTEMA BIOMÉDICO
(parámetro concept), el concepto reconocido en la ontología
remota -o el propio concepto para la anotación local- (parámetro
preferred), un valor para indicar si la anotación es directa o no
(parámetro direct), los grupos a los que pertenece (parámetro
group), el idioma (parámetro lan), los índices que delimitan la
posición del concepto en el texto (parámetros from y to), la
dirección URL externa (parámetro url, que será procesado en
función de la fuente para obtener las direcciones URL con
información en español y en inglés, con un procedimiento muy
parecido al explicado para el método insertHtmlItem) y la dirección
URL local (parámetro localUrl).
Tabla 16. Formato del documento XML construido por el componente de integración de
información del módulo PLN.
ETIQUETA XML
<cleim>
DESCRIPCIÓN
Cuerpo
Parámetros enviados (generados por el método
initXmlDocument)
<input>
<text></text>
Texto enviado para su procesado
<remoteonts>
</remoteonts>
Identificadores de las ontologías remotas con
las que se está procesando el texto
Nivel de profundidad en la búsqueda de las
ontologías remotas
<lev></lev>
<localSrc></localSrc>
Fuentes locales utilizadas para la anotar
<localLan></localLan>
Idiomas locales seleccionados
</input>
<annotation
language
source>
<concept neg>
</concept>
<from></from>
130
Cada una de las anotaciones. Los atributos son:
language = en / sp
source = Freebase / MedlinePlus / Snomed
/ OBA Medlineplus (40397) / OBA Snomed
(46116) / OBA ([identificador])
Concepto reconocido en el texto. Dispone de un
atributo para incluir detección de la negación:
neg = 0 / 1
<to></to>
Índices que delimitan la posición del concepto
en el texto
<preferred direct>
</preferred>
Nombre del concepto reconocido en la
ontología remota. En el reconocimiento local es
DESARROLLO DEL SISTEMA BIOMÉDICO
igual que el concepto. Contiene un atributo que
indica si la anotación es directa o no:
direct = true / false
<localurl></localurl>
Dirección URL local de acceso al módulo BEE
<urlen></urlen>
Dirección URL externa con información en inglés
<urlsp></urlsp>
Dirección URL externa con información en
español
<groups></groups>
Grupos a los que pertenece el concepto
</annotation>
</cleim>
Los métodos de la clase IntegrateAnnot están directamente relacionados
con los componentes del módulo CAI desarrollados, que son explicados con
más detalles en la cuarta sección de este capítulo. Cada elemento del
módulo CAI que accede a la clase IntegrateAnnot se ha implementado con
un servlet y, opcionalmente, una página jsp, siendo el servlet la vía de
acceso a los diferentes métodos que dan el formato adecuado a la respuesta
final. Nótese que para replicar la salida en otro formato (distinto de los ya
existentes en HTML o XML) sería necesario desarrollar, además de los
elementos del módulo CAI correspondientes, nuevos métodos en esta clase:
generar el método equivalente a los ya desarrollados htmlGateTree y
htmlNCBOTree, o xmlGateTree y xmlNCBOTree (y los métodos auxiliares
necesarios para dar formato, como el método compoundNCBOData para dar
formato algunos datos del NCBO, o los métodos para dar formato al XML
denominados initXmlDocument y getNormalizedXml); y, por último, los
métodos
equivalentes
a
los
ya
desarrollados
insertHtmlItem
e
insertXmlItem.
3. Búsqueda de información
131
DESARROLLO DEL SISTEMA BIOMÉDICO
Búsquedas en Freebase
Los primeros servicios de búsqueda sobre la ontología Freebase para los
conceptos han sido creados usando Javascript y AJAX, generándose de este
modo tres clientes de acceso para hacer las consultas a partir de una cadena
de texto de entrada: uno para enfermedades58, otro para síntomas59 y otro
para tratamientos60. A estos clientes se les ha dotado de la funcionalidad de
traducción de google, cuando todavía era un producto de acceso libre
(actualmente las consultas al servicio son de pago). Tras la búsqueda por
término siguiendo el patrón *término*, ofrecen la posibilidad al usuario de
obtener la información semántica relacionada con el Tópico (a través de las
Propiedades de Freebase) o visitar el Tópico en el sitio Web de Freebase.
También incluyen un cliente de búsqueda de artículos en MELINE/PubMed
relacionados con el término, que, en un primer paso, muestra algunos de los
datos necesarios para identificar el artículo (título, autor/es, fecha de
publicación, etc.) y, en un segundo paso, permite visualizar el resumen del
mismo.
Posteriormente estos clientes de búsqueda de información en Freebase se
han integrado como un módulo más desarrollado en Java, principalmente
por dos motivos: uniformizar el desarrollo de todos los módulos del sistema
y aumentar la estabilidad del cliente (ver los problemas de usabilidad
mencionados, por ejemplo, en Holzinger, Mayr, Slany, & Debevc, 2010).
58
http://orion.esp.uem.es:8080/MedicalFace/medicaldisease.html
59
http://orion.esp.uem.es:8080/MedicalFace/medicalsymptom.html
60
http://orion.esp.uem.es:8080/MedicalFace/medicaltreatment.html
132
DESARROLLO DEL SISTEMA BIOMÉDICO
El módulo de búsqueda BEE desarrollado finalmente en Java, en el que se
incluye el componente de acceso a Freebase, sigue una lógica muy similar a
la desarrollada desde los clientes en AJAX, aunque también incorpora otras
funcionalidades. Para cada uno de los Tipos de Freebase se ha creado una
clase que es instanciada desde la página jsp (coincidiendo el nombre de la
página con la propiedad minor definida en el fichero de anotación
medicine.def). La estructura de las tres clases (CallFBDis, para las
enfermedades, CallFBSym, para los síntomas, y CallFBTre, para los
tratamientos) es similar, siendo las propiedades y métodos más destacables
los que se explican a continuación:
1) Propiedades limit, page, count y totalpage: con las que se controla
el número de resultados por página, la página actual, el número
total de resultados y el número total de páginas, respectivamente.
Se utilizan de un modo análogo a como se hace en el módulo de
recuperación de información, modificándose únicamente el valor de
la página actual con la interacción del usuario desde la página Web,
haciendo uso de un método setPage.
2) Propiedades del tipo lista de cadena (List<String>) que contienen la
siguiente información sobre los Tópicos resultantes de la búsqueda:
el identificador del Tópico en Freebase (lIDList), el concepto o
nombre del Tópico (lConcept), el texto del artículo de Wikipedia (si
lo hubiese) obtenido desde Freebase (lArticle), la URL a la imagen (si
la hubiese) asociada con el concepto o Tópico (lImage), la URL de
Freebase con la información sobre el Tópico (lFBUrl) y la
información semántica vinculada al Tópico a través de las
Propiedades de Freebase, que han sido previamente seleccionadas
para cada uno de los Tipos. Esta información semántica se
133
DESARROLLO DEL SISTEMA BIOMÉDICO
corresponde con los datos seleccionados que ya se han desarrollado
con más amplitud en el primer apartado de la segunda sección del
capítulo 3, enlazándose internamente a través de las direcciones
URL locales correspondientes (Tabla 12).
Tabla 17. Páginas enlazadas para ofrecer la información al usuario sobre los diferentes
conceptos semánticamente relacionados, en función del Tipo de concepto.
PÁGINA
JSP
CLASE
TIPO DE
FREEBASE
CallFBDis
disease.jsp
Enfermedades
CallFBSym
symptom.jsp
Síntomas
CallFBTre
treatment.jsp
Tratamientos
PROPIEDAD
SEMÁNTICA
Síntomas
Tratamientos
Factores de riesgo
Efecto secundario de
Síntoma de
Efectos secundarios
Usado para tratar
PÁGINA LOCAL
ENLAZADA
symptom.jsp
treatment.jsp
treatment.jsp
disease.jsp
symptom.jsp
disease.jsp
3) El método queryFBDetail(String pid): construye la consulta MQL, con
el formato del API utilizado, con el objetivo de obtener los datos
semánticos para cada uno de los Tópicos resultantes de la
búsqueda, utilizando el identificador de la lista lIDList a través del
parámetro pid (Tabla 13).
Tabla 18. Consultas MQL en el formato del API utilizadas para obtener la información de
detalle y semántica sobre los Tópicos, identificados por su Identificador en Freebase (pid),
en función de cada Tipo.
CONSULTA PARA EL TIPO ENFERMEDADES
o("type", "/medicine/disease","id", pid,"name", null,
"symptoms",a(o("id", null,"index", null,"name", null,"optional", true,"sort", "index","type",
"/medicine/symptom")),
"treatments",a(o("id", null,"index", null,"name", null,"optional", true,"sort", "index","type",
"/medicine/medical_treatment")),
"risk_factors",a(o("id", null,"index", null,"name", null,"optional", true,"sort", "index","type",
"/medicine/risk_factor")));
CONSULTA PARA EL TIPO SÍNTOMAS
o("type", "/medicine/symptom","id", pid,"name", null,
"side_effect_of", a(o("id", null,"index", null,"name", null,"optional", true,"sort", "index","type",
"/medicine/medical_treatment")),
"symptom_of", a(o("id", null,"index", null,"name", null,"optional", true,"sort", "index","type",
"/medicine/disease")));
CONSULTA PARA EL TIPO TRATAMIENTOS
o("type", "/medicine/medical_treatment","id", pid,"name", null,
"side_effects", a(o("id", null,"index", null,"name", null,"optional", true,"sort", "index","type",
134
DESARROLLO DEL SISTEMA BIOMÉDICO
"/medicine/symptom")),
"used_to_treat", a(o("id", null,"index", null,"name", null,"optional", true,"sort", "index","type",
"/medicine/disease")));
4) El método queryFB(): es con el que se construyen las consultas MQL
para obtener el total de resultados de la búsqueda siguiendo el
patrón seleccionado (*término*), los nombres de los Tópicos, sus
identificadores en Freebase, los artículos de Wikipedia
y una
imagen, asociados con cada uno de los resultados. Además, agrega
todos estos datos a las listas correspondientes y se encarga de
llamar al método queryFBDetail, recuperando la información
semántica de cada Tópico, agregándola también a las listas definidas
con este fin.
5) Se ha implementado un método doRawQuery(String url) que
recupera la información textual de la URL en la que se encuentra el
texto de Wikipedia proporcionado por Freebase, a través de una
petición usando el protocolo HTTP.
6) Los métodos get permiten recuperar las listas de datos resultantes
de la búsqueda desde la página jsp: getConcepts para recuperar los
nombres de los tópicos; getArticles para recuperar los artículos de
Wikipedia; getImages para recuperar las imágenes; getFBUrls para
recuperar las direcciones URL de cada tópico en el sitio Web de
Freebase; y los métodos correspondientes a las listas de cada uno
de los tipos, esto es, getSymtoms, getTreatments, getRisks en el
caso del Tipo enfermedades, getSideEfs, getSympOfs en el caso del
Tipo síntomas, y getSideEf, getUsedTo en el caso del Tipo
tratamientos.
135
DESARROLLO DEL SISTEMA BIOMÉDICO
Búsquedas en MedlinePlus
El componente de búsqueda de información en MedlinePlus, ubicado como
parte del módulo de búsqueda, se ha desarrollado como un cliente Java que
recupera información a partir del servicio Web mantenido por la NLM61. Una
de las limitaciones más importantes de este servicio Web, desde el punto de
vista idiomático, es que sólo ofrece la posibilidad de consultar la
información de MedlinePlus en inglés. Las consultas a este servicio se
realizan a través de peticiones con el protocolo HTTP, en las que se envía el
valor de dos parámetros: la base de datos de búsqueda (parámetro db), que
hay que dejarlo fijado con el valor "healthTopics", y el valor del término o
frase de búsqueda (parámetro term), que debe estar codificado como una
URL (esto se ha implementado con Java haciendo uso de la ya mencionada
librería HttpClient). También se pueden utilizar un conjunto de parámetros
para paginar los resultados (que no han llegado a ser utilizados) y un
parámetro para indicar el máximo de resultados por consulta que se desean
obtener, que se corresponderán con los resultados mostrados por pantalla a
través del sistema (el parámetro retmax, que se ha establecido en 100). La
respuesta del servicio es un XML con los resultados coincidentes en
MedlinePlus organizados del modo que ya se comentaba en capítulo
anterior, conteniendo una información, para cada Tópico de salud, muy
parecida a la proporcionada desde los ficheros de datos en formato XML
utilizados para el preprocesado, desde el módulo RPD, de la terminología
con la que llevar a cabo las anotaciones, desde el módulo PLN (en la imagen
superior de la Fig. 17 se muestra un ejemplo de la respuesta del servicio
61
http://www.nlm.nih.gov/medlineplus/webservices.html
136
DESARROLLO DEL SISTEMA BIOMÉDICO
Web). El servicio también ofrece una utilidad de corrección de errores, tal y
como se muestra en la imagen inferior de la Fig. 17.
Figura 17 En la imagen superior se muestran los primeros resultados devueltos por el
servicio Web de MedlinePlus, en formato XML, al realizar la consulta por el término
"cancer"; en la imagen inferior se muestra el resultado al realizar la consulta errónea
"prostate cacer".
Otras cuestiones de interés relacionadas con las consultas a este servicio
Web, son las posibilidades que ofrece para realizar las operaciones lógicas
AND (concatenando los términos de búsqueda con el carácter '+') y OR
(concatenando los términos de búsqueda con '+OR+').
La gestión de las peticiones HTTP a este servicio se han programado en dos
clases, la clase CallMLP, que se encarga de la hacer la petición y obtener el
los resultados del servicio, y la clase MLPSearch, en la que se procesa el XML
resultante almacenando los datos de interés en listas que pueden ser
utilizadas desde la página jsp desarrollada para mostrar los resultados
137
DESARROLLO DEL SISTEMA BIOMÉDICO
(medlineplus.jsp y su equivalente snomed.jsp). La clase CallMLP incluye los
siguientes métodos:
1) setTerm(String pterm): con el que se establece el término o frase de
búsqueda enviado al servicio Web, a través del parámetro pterm.
2) setLogic(String plogic): utilizado para establecer la lógica aplicable a
las diferentes palabras de la frase de búsqueda, a través del
parámetro plogic. Por defecto el valor es de '+' (AND), siendo el otro
valor admisible '+OR+'.
3) setRetmax(String pretmax): sirve para establecer el número máximo
de resultados, a través del parámetro pretmax.
4) doMLPQuery(): Este método codifica la URL y ejecuta la petición al
servicio, recuperando la cadena de texto que contiene el XML
resultante.
La lógica de la clase MLPSearch es similar a la de las clases desarrolladas
para el componente de búsqueda en Freebase, es decir, tras procesar el
XML se almacenan los datos en un conjunto de listas que se pueden
recuperar con los métodos get implementados. En concreto, las
propiedades y métodos más destacables son los siguientes:
1) Las propiedades lRank, lUrl, lTitle, lFullSummary, lMesh y
lGroupName: son las listas de cadenas (List<String>) en las que se
almacenan -para cada uno de los resultados- la clasificación según
MedlinePlus, la URL del sitio Web de MedlinePlus en la que está
publicada la información sobre el tópico, el nombre de la página en
MedlinePlus para este tópico, el texto explicativo asociado,
términos MeSH asociados por MedlinePlus al tópico (estos términos
se enlazan al componente de búsqueda de MEDLINE/PubMed del
138
DESARROLLO DEL SISTEMA BIOMÉDICO
sistema, que se explicará en la siguiente sección, y se concatenan
para un mismo tópico a través del carácter "|") y los grupos de
MedlinePlus a los que pertenece (los diferentes grupos a los que
pertenece cada tópico se concatenan a través del carácter ",").
2) El método runMPLSearch(String term): es el responsable de
instanciar a la clase CallMLP, recuperar el XML resultante de la
búsqueda haciendo uso del término o frase enviada en el
parámetro term. En concreto, se encarga de extraer los atributos
rank y url del elemento etiquetado como document, para cada
resultado. Dentro de este elemento, toda la información sobre el
Tópico se incluye en elementos etiquetados como content, que
incluyen un atributo name con el que se puede identificar el tipo de
contenido. De manera que este método recorre cada uno de los
elementos content para cada uno de los elementos document,
diferenciando la lista de cadena en la que incluir cada uno de los
datos a partir del valor del atributo name. Antes de almacenar
algunos de estos valores, es necesario utilizar algunos patrones
para reemplazar texto que viene en formato HTML, obteniendo así
texto plano que poder formatear adecuadamente desde la página
jsp. Esto se da con los valores de las listas lTitle y lMesh, que
requieren eliminar el patrón <span class=\"qt[0-9]\"> y la cadena
</span> (reemplazándolos por una cadena vacía).
3) Los métodos getRank(), getUrl(), getTitles(), getFullSummary(),
getMesh() y getGroupName(): permiten la recuperación de las listas
de datos almacenadas en el procesado del XML, desde la página jsp
o cualquier otra clase Java.
139
DESARROLLO DEL SISTEMA BIOMÉDICO
Búsquedas en MEDLINE/PubMed
El sistema desarrollado ofrece la posibilidad a los usuarios de acceder a
enlaces, incluidos desde varias páginas HTML, con información bibliográfica
relacionada con las entidades extraídas o con los conceptos resultantes de
las búsquedas. Estas consultas bibliográficas a la base de datos de
MEDLINE/PubMed se llevan a cabo a través de la utilidad de búsqueda y
consulta del sistema Entrez a la base de datos pubmed. Para la integración
del sistema de consultas que proporciona el sistema Entrez a través de sus
utilidades, se ha incorporado la librería proporcionada por la NLM62,
incluyéndose una clase Java en el módulo de búsqueda para gestionar las
peticiones al servicio Web y recuperar los resultados, que se mostrarán al
usuario a través de la página jsp denominada pmresult.jsp. La utilización del
servicio, según sus políticas de uso63, requiere hacer todas las peticiones
incluyendo el nombre de la herramienta y el email del desarrollador, que
pueden ser dadas de alta por correo electrónico.
El componente del módulo BEE implementado para enviar las peticiones
SOAP al servicio Web, así como procesar los resultados y almacenarlos en
listas, está compuesto por la clase Java CallPMSoap. Las propiedades y los
métodos más relevantes de esta clase son los siguientes:
1) La propiedad term: En la que se almacena el término de la
búsqueda. Debe estar con codificación URL y sin espacios, que
tienen que ser reemplazados por el símbolo '+'.
62
http://www.ncbi.nlm.nih.gov/books/NBK55696/#apache_java.Using_Eclipse_for_de
velopmen
63
http://www.ncbi.nlm.nih.gov/books/NBK25497/
140
DESARROLLO DEL SISTEMA BIOMÉDICO
2) La propiedad lan: Posibilita que se agrege al término de búsqueda la
condición del idioma de la publicación, siendo este uno de los
campos (fields) que permite las consultas a la base de datos pubmed
a través del sistema Entrez. Para verificarlo, basta hacer la petición a
la utilidad einfo.fcgi con el parámetro db=pubmed y localizar el
campo cuyo nombre completo es Language. La forma de concatenar
esta condición es utilizando la cadena +(spa[LANG]).
3) La propiedad logic: Es utilizada para reemplazar los espacios entre
las distintas palabras de la cadena de búsqueda. Por defecto se
establece a '+', que equivale a la condición lógica AND aplicada a
cada una de las palabras que aparecen en el término. El otro valor
posible sería '+OR+'.
4) Las propiedades limit, pmPage, count y totalpages: están
directamente relacionadas con la paginación. Permiten establecer el
número de resultados por página, la página actual, almacenar el
total
de
resultados
y
almacenar
el
total
de
páginas,
respectivamente.
5) Las propiedades lIDList, lTitle, lPubDate, lAuthors y lAbstractUrl: Son
las listas de cadena (List<String>) utilizadas para almacenar los datos
de los resultados de las búsquedas. La primera sirve para guardar el
listado de identificadores obtenidos tras realizar la búsqueda con la
utilidad esearch. Las siguientes sirven para almacenar los títulos
correspondientes a cada uno de los resultados, las fechas de
publicación, los autores y las direcciones URL a los resúmenes,
obtenida con la utilidad esummary.
6) El método queryPMID(): Realiza la búsqueda en pubmed con la
utilidad esearch. Gestiona la codificación del término de búsqueda,
141
DESARROLLO DEL SISTEMA BIOMÉDICO
el reemplazo de los espacios por la lógica establecida en la
propiedad logic y la concatenación de la propiedad de idioma (lan).
Además, se encarga de establecer el criterio de ordenación (que se
ha fijado con el valor correspondiente a la fecha de publicación,
PublicationDate), paginar los resultados y recuperar el listado de
identificadores resultantes de la búsqueda.
7) El método queryPMInit(): Ejecuta la llamada al método queryPMID y
realiza la llamada a la utilidad esummary agregando todos los
identificadores obtenidos. A continuación recorre los resultados
devueltos por la utilidad agregando los valores a las listas de datos
lTitle, lPubdate, la URL del resumen (si es que existe) en lAbstractUrl
y la lista de autores (separados por el carácter '.') en lAuthors.
8) Los métodos setTerm(String pterm), setLanSpa(), setLogic(String
plogic), setLimit(int plimit) y setPage(int pPage), permiten establecer
el término de búsqueda y modificar el valor por defecto de las
propiedades lan, logic, limit y page.
9) Los métodos getCount(), getTotalPages(), getTitles(), getPubDates(),
getAuthors() y getAbstractUrl(), sirven para recuperar los datos de
recuento total de resultados, el total de páginas y las listas de
títulos, fechas de publicación, autores y las direcciones URL de los
resúmenes de cada resultado, respectivamente. Las direcciones URL
de los resúmenes, obtenidos con la utilidad efetch (agregando el
parámetro rettype=abstract), se construyen enlazando la utilidad
directamente desde la página Web en formato de texto (agregando
el parámetro retmode=text).
4. Mecanismos de acceso al sistema
142
DESARROLLO DEL SISTEMA BIOMÉDICO
Los dos mecanismos de acceso del módulo CAI, descritos en el tercer
apartado del capítulo anterior, utilizan tecnologías Java para su acceso a
través del protocolo HTTP. Sus componentes están desarrollados con
servlets, que se encargan de la comunicación con el componente de
integración del módulo PLN, y páginas jsp (en caso de ser necesario) que
muestran el resultado al usuario final a través del navegador, así como de la
comunicación con los componentes del módulo BEE.
Acceso a través del navegador
La aplicación de acceso a la información que se ha preparado para los
usuarios finales está basada en Web y contiene los siguientes componentes:
Componente para la comunicación con el módulo PLN (Fig. 18):
a. Un servlet Java denominado NLPServ, encargado de la
comunicación con el componente CII del módulo PLN. Este
servlet acepta tanto peticiones de tipo POST como GET.
b. Una página jsp denominada nlpresult.jsp con la que se
imprimen los resultados procesados por el elemento
NLPServ. Tanto en el servlet como en la jsp ha sido
necesario unificar el criterio de codificación de caracteres
establecido para el procesado con GATE (UTF-8), evitando
este tipo de problemas en el envío del texto en la petición
HTTP y durante el procesado.
c. Página inicial ofrecida al usuario final, desde la que puede
insertar el texto y comenzar el procesado a través del
elemento NLPServ: index.html.
143
DESARROLLO DEL SISTEMA BIOMÉDICO
d. Página de acceso a funcionalidades más avanzadas del
procesado, haciendo uso igualmente del elemento NLPServ:
admin.html.
Componentes para la comunicación con el módulo BEE:
a. Componente de acceso a Freebase. Búsqueda, obtención
información detallada e información semántica desde
Freebase, compuesto por los siguientes elementos:
i. disease.jsp para la comunicación con el elemento de
búsqueda de enfermedades, a través de la clase
CallFBDis.
ii. symptom.jsp para la obtención de información
sobre síntomas, a través de la clase CallFBSym.
iii. treatment.jsp para la recuperación de información
sobre tratamientos, a través de la clase CallFBTre.
b. Componente de acceso a MedlinePlus. La comunicación con
el elemento de búsqueda en MedlinePlus se lleva a cabo
desde las páginas medlineplus.jsp y snomed.jsp, haciendo
uso de la clase MLPSearch.
c. Componente de acceso a PubMed. La recuperación de las
publicaciones científicas de PubMed se ha incorporado en la
página pmresult.jsp, que se comunica con la clase
CallPMSoap.
144
DESARROLLO DEL SISTEMA BIOMÉDICO
Aplicación Web
Componente Acceso PLN
index.html
NLPServ
nlpresults.html
Pantalla principal
Módulo PLN
Componente C.I.I
IntegrateAnnot
Módulo BEE
Componente Acceso Freebase
disease.jsp
Componente Freebase
CallFBDis
symptom.jsp
CallFBSym
A partir del primer
treatment.jsp
CallFBTre
nivel de navegación
Componente Acceso
MedlinePlus
medlineplus.jsp
Componente
MedlinePlus
MPLSearch
snomed.jsp
CallFBSym
A partir del segundo
nivel de navegación
Componente Acceso PubMed
Componente PubMed
pmresult.jsp
CallPMSoap
Figura 18 Niveles de navegación y comunicación detallada de los elementos de la aplicación
Web.
A continuación
se
describen las funcionalidades
más relevantes
desarrolladas para cada uno de estos elementos.
index.html / admin.html: estas páginas son semejantes en su
funcionamiento interno. La diferencia es únicamente el número
mayor de opciones que permite la segunda en relación a la
primera, motivo por el que, por otro lado, no es adecuada para
usuarios finales dada la complejidad de los resultados. Las
funciones más destacadas son:
o
A nivel de interfaz, incorporan funcionalidades de jQuery
UI, que son empleadas en la construcción de los
145
DESARROLLO DEL SISTEMA BIOMÉDICO
desplegables, el botón de procesado y el cajón de texto
redimensionable.
o
La petición al elemento NLPServ, que se lleva a cabo como
una petición HTTP utilizando AJAX, envía los datos del
formulario por POST tras establecer la codificación a UTF-8
y, finalmente, imprime por pantalla (en un elemento div)
la respuesta del servlet, que es formateada por la página
nlpresult.jsp.
NLPServ / nlpresult.jsp: el servlet NLPServ es el elemento
encargado de gestionar la comunicación con el componente C.I.I.
(la clase IntegrateAnnot), solicitándole las acciones de procesado
según sean los parámetros enviados desde el cliente. Finalmente
envía la información a la página jsp nlpresult.jsp, que es la
responsable de incluir las librerías correspondientes a los plugins
de jQuery (PicNet Table Filter y tablesorter). Las funciones más
relevantes del servlet son las siguientes:
o
Establecer dinámicamente la ruta al directorio WEB-INF
con el método init (ServletConfig servletConfig) utilizando
servletConfig.getServletContext().getRealPath("/WEBINF"). Esta ruta será necesaria para cargar los archivos de
GATE desde la clase GateGazMed del módulo PLN,
llegándole el parámetro desde el componente C.I.I., que lo
recibirá, a su vez, desde el servlet. Por otro lado, el
componente C.I.I. también utiliza esta ruta para guardar el
fichero temporal CLEiMtmp.gapp si fuese el caso.
o
Los métodos doGet y doPost reciben los siguientes
parámetros de la petición: text (texto a procesar), src
146
DESARROLLO DEL SISTEMA BIOMÉDICO
(parámetro que indica las fuentes de conocimiento), onts
(identificadores de las ontologías remotas del NCBO), lev
(nivel de profundidad de búsqueda en las ontologías
remotas), cksrcfb, cksrcmp, cksrcsc (que se almacenan en
un array localSrc conteniendo las fuentes locales con las
que realizar la anotación, con los valores Freebase,
MedlinePlus y Snomed), cklanen y cklansp (que se
almacenan en un array localLan conteniendo los idiomas
locales con los que anotar, cuyos valores son en y sp). Sólo
se procesa el texto si no es vacío, haciéndolo en función
del parámetro src. La anotación local (utilizando el método
htmlGateTree() de la clase IntegrateAnnots) la lleva a cabo
únicamente cuando src tiene valor -1 (correspondiente a
anotar con todas las fuentes) o valor 1 (correspondiente a
anotar con las fuentes locales), mientras que la anotación
remota la ejecuta en los casos en los que src es distinto de
1. Los valores de src 2 y 3 implican la anotación remota
con las ontologías MedlinePlus Health Topics y SNOMED CT
respectivamente. Si el valor de src es 4, entonces la
anotación se lleva a cabo con las ontologías definidas por
el parámetro onts. Las opciones para gestionar las fuentes
y los idiomas locales, así como las ontologías remotas con
las que anotar y el nivel de profundidad de búsqueda sólo
se han habilitado desde el interfaz proporcionado desde la
página admin.html.
disease.jsp / symptom.jsp / treatment.jsp: son los elementos
encargados de dar formato a las listas de resultados del
147
DESARROLLO DEL SISTEMA BIOMÉDICO
componente de búsqueda en Freebase del módulo BEE, utilizando
la librería de jQuery tablesorter. Reciben por parámetro el término
de búsqueda (term) y la página (pg), y generan un objeto de la
clase correspondiente para recuperar los listados de datos, es
decir, CallFBDis, CallFBSym o CallFBTre. A través de los métodos
setPage y getTotalPages de estas clases llevan a cabo la paginación
y la generación de los listados correspondientes a cada página. El
enlace a estas páginas es generado dinámicamente desde la
propiedad minor del fichero medicine.def.
medlineplus.jsp / snomed.jsp: ambas son interfaces idénticas para
el acceso al cliente de búsqueda en MedlinePlus, aunque
permitiría generar fácilmente un nuevo cliente de búsqueda para
el caso de los conceptos anotados con la terminología de SNOMED
CT. Su funcionamiento es similar al de las páginas del punto
anterior. En este caso se crea el contenido a partir de un objeto de
la clase MLPSearch.
pmresult.jsp: página similar a nivel funcional a las explicadas en los
dos puntos anteriores. Crea el formato de salida a partir de los
datos obtenidos de un objeto de la clase CallPMSoap. Su enlace,
en este caso, no es generado a partir de ningún atributo sino
dinámicamente sobre los conceptos resultantes de las búsquedas,
encontrándose siempre a partir del segundo nivel de navegación,
en lugar del primer nivel como sucedía con las páginas de los
puntos anteriores.
148
DESARROLLO DEL SISTEMA BIOMÉDICO
Acceso a través del servicio Web
Este componente está formado por un único servlet, denominado XMLServ,
que responde a la petición del cliente en formato XML. Para probar su
funcionamiento se ha desarrollado un cliente, consistente en una página
HTML semejante a la mencionada en el apartado anterior (admin.html),
adaptada en este caso para mostrar la respuesta del servicio en un
elemento iframe. Este cliente se puede encontrar en la página service.html.
El servlet XMLServ procesa la petición HTTP de un modo muy similar al
servlet desarrollado en la aplicación Web para el acceso al módulo PLN
(NLPServ). En este caso, en lugar de realizar llamadas a los métodos
htmlGateTree y htmlNCBOTree de la clase IntegrateAnnot en función del
parámetro src, realiza llamadas a los métodos xmlGateTree y xmlNCBOTree.
Antes de instanciar estos métodos de la clase IntegrateAnnot, el servlet
inicializa el XML a través del método initXmlDocument y, tras realizar la
llamada a dichos métodos, lo normaliza y obtiene el documento resultante
llamando al método getNormalizedXml.
El XML resultante proporciona para cada entidad anotada la información
descrita en el capítulo anterior, delegando las funcionalidades de
comunicación con el módulo BEE a través de los componentes desarrollados
para
la
aplicación
Web,
proporcionando
los
enlaces
locales
correspondientes. Además, devuelve las direcciones URL externas en las que
se puede encontrar más información sobre los conceptos (Fig. 19).
149
DESARROLLO DEL SISTEMA BIOMÉDICO
Servicio Web
Módulo PLN
Componente Acceso PLN
Componente C.I.I
XMLServ
IntegrateAnnot
CLIENTE
Freebase
MedlinePlus
Componente
Componente
Acceso Freebase
Acceso MedlinePlus
Aplicación Web
NCBO
Sitios Web Externos
Figura 19 Interacción del cliente del servicio Web y conjunto de enlaces proporcionados
para cada concepto reconocido.
En el Apéndice 1 se muestran algunos ejemplos resumidos en tablas de la
respuesta proporcionada por el servicio ante una misma cadena de
búsqueda.
150
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
CAPÍTULO 5. EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA.
Para la evaluación del rendimiento se ha tomado como referencia el servicio
de anotación remoto OBA integrado en la herramienta. Las motivaciones
para tomar como referencia este servicio integrado son las siguientes:
Dado que el sistema utiliza ambos procesos, estas pruebas
permitirán valorar la complementariedad de los servicios local y
remoto, detectando las fortalezas y debilidades de cada uno de
ellos.
Se dispone ya de mediciones de precisión y cobertura del sistema
OBA que están, a su vez, comparadas con los resultados del sistema
de referencia MetaMap. Esto permite enfocar el esfuerzo de
evaluación hacia la percepción de los usuarios al resolver una tarea
concreta, haciendo uso de un conjunto eficiente de fuentes.
La similitud entre los procesos a través de los cuales ambos sistemas
reconocen los términos ya que, a pesar de que el servicio OBA
dispone de un diccionario de términos mucho mayor que el utilizado
localmente (un diccionario de 3.200.654 términos en inglés64, frente
a los 612.234 términos en inglés y en español preprocesados por el
módulo PRD), como contrapartida el proceso de anotación local
ofrece la posibilidad de procesar textos en español.
La integración del servicio OBA realiza en un único paso el
reconocimiento de conceptos en las ontologías, mientras que
cuando la extracción es local el reconocimiento de conceptos
implícitos se realiza a través de la interacción del usuario, a partir
64
http://www.bioontology.org/wiki/index.php/Annotator_User_Guide
151
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
del primer nivel de navegación. Sin embargo, el enfoque es muy
similar, no realizándose el tipo de reconocimiento que hace, por
ejemplo, MetaMap. Al anotar los términos localmente bien es cierto
que el procedimiento es más sencillo, pero el sistema aporta otro
tipo de relaciones que van más allá de los sinónimos, las relaciones
"es_un" o la funcionalidad (que no se ha integrado en el interfaz) de
expansión semántica con los tipos de UMLS, a través de las
Propiedades de Freebase; además, existe la posibilidad de integrar
fácilmente nuevos elementos en el Pipeline desarrollado localmente
con GATE e, incluso, otras librerías para realizar un procesado más
complejo del texto.
1. Casos de prueba analizados
Las mediciones se han desplazado a lo largo de dos dimensiones, que dan
lugar a diferentes casos de prueba (que se denominarán Pi, siendo i el
número de la prueba): (i) una dimensión tiene en cuenta las diferentes
fuentes de conocimiento con las que se realizan las anotaciones locales y
remotas; (ii) la otra dimensión tiene en cuenta la longitud de los textos
objeto del procesado. Estas dos dimensiones han dado lugar a los siguientes
casos de prueba:
1. Dados un conjunto de textos, en los que no se tiene en cuenta la
longitud, se han medido los tiempos medios de:
1.1. Anotando con la fuente de conocimiento MedlinePlus en inglés,
mediciones del procesado local sin formatear la salida (P1),
formateando la salida en HTML (P2) y formateándola en XML (P3).
Realizando esto mismo para el procesado remoto (P4, P5, P6).
152
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
1.2. Anotando con la fuente de conocimiento SNOMED CT en inglés,
procesando del mismo modo los ficheros con el proceso local (P7,
P8, P9) y con el servicio remoto (P10, P11, P12).
1.3. Anotando con ambas fuente de conocimiento en inglés, repitiendo
el mismo procedimiento se obtienen los casos de prueba P13, P14,
P15 para el proceso local, y P16, P17, P18 para el servicio remoto.
1.4. Anotando con la fuente de conocimiento MedlinePlus, mediciones
del procesado local bilingüe sin formato, con formato HTML y con
formato XML (P19, P20, P21).
1.5. Anotando con la fuente de conocimiento SNOMED CT, mediciones
del procesado local en los tres formatos (P22, P23, P24).
1.6. Anotando localmente con las dos fuentes de conocimiento en los
dos idiomas y realizando mediciones en las tres modalidades
anteriores (P25, P26, P27).
2. Dados un conjunto de textos de longitudes variables, medición de los
tiempos empleados para los distintos tipos de formato de salida,
tomando como fuentes de anotación:
2.1. Con todas las fuentes locales bilingües excepto SNOMED CT (casos
de prueba P28, P29, P30) y con la ontología MedlinePlus Health Topics
del servicio OBA (P31, P32, P33), para comprobar los efectos al
suprimir la terminología más numerosa.
2.2. Utilizando SNOMED CT bilingüe desde el proceso local (P34, P35, P36)
y la equivalente monolingüe desde el servicio remoto (P37, P38, P39).
2.3. Utilizando todas las locales disponibles (P40, P41, P42) y las remotas
integradas (P43, P44, P45). Esto último implica el uso, desde el fichero
medicine.def, de todas las listas: diseaseen.lst, symptomen.lst,
153
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
treatmenten.lst, mlpen.lst, scten.lst, diseasesp.lst, symptomsp.lst,
treatmentsp.lst, mlpsp.lst, sctsp.lst.
El conjunto de casos de prueba que se desplazan por la dimensión de las
diferentes fuentes de conocimiento {Pi, i=1,...,27}, se sintetizarán en tres
gráficas en las que se comparan los resultados remotos utilizando cada
combinación de fuentes con los resultados locales usando la misma
combinación en inglés y en inglés/español. Los casos de prueba que se
desplazan por la dimensión de longitud del texto {Pi, i=28,...,45}, quedarán
condensados en una gráfica para cada uno de los ficheros de longitud
variable, comparándose el procesado local frente al remoto con cada
combinación de fuentes en cada una de ellas.
2. Textos de entrada
Los textos seleccionados para las pruebas son los casos clínicos del año 2012
(accedidos el 8 de Marzo de 2012) del Departamento de Patología
perteneciente a la Escuela de Medicina de la Universidad de Pittsburgh65
(UPMC). Estos casos están numerados secuencialmente desde el 715 hasta
el 726, es decir, hacen un total de 12 casos clínicos. Se han almacenado en
archivos de texto plano nombrados con el número correspondiente a cada
caso, que contienen: todo el texto incluido en la página Web del caso
(path.upmc.edu/cases/case[NÚMERO DE CASO].html) y el contenido de la
página enlazada, si existe, para el apartado del diagnóstico final del caso
(path.upmc.edu/cases/case[NÚMERO DE CASO]/dx.html), excluyendo en el
texto de la primera página aquel en el que aparece el nombre del caso y los
65
http://path.upmc.edu/cases/Chronicle/index-histo-2012.htm
154
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
nombres de los autores, e incluyendo de la segunda página sólo el texto
situado entre el título (FINAL DIAGNOSIS o, simplemente, DIAGNOSIS) y las
referencias (REFERENCES). Algunas de las características de los ficheros en
texto plano se muestran en la Tabla 19.
Tabla 19. Características de los textos recuperados del UPMC.
PALABRAS
CARACTERES
(SIN CONTAR LOS
ESPACIOS)
CARACTERES
(CONTANDO LOS
ESPACIOS)
CASO 715
685
4.254
4.935
CASO 716
1.922
10.839
12.762
CASO 717
1.302
7.563
8.844
CASO 718
473
2.709
3.171
CASO 719
962
5.394
6.342
CASO 720
562
3.231
3.783
CASO 721
1.237
7.873
9.098
CASO 722
722
4.477
5.189
CASO 723
696
4.120
4.807
CASO 724
1.080
6.353
7.418
CASO 725
738
4.340
5.057
CASO 726
1.516
9.308
10.763
PROMEDIO
991,25
5.871,75
6.847,42
DESV.EST
434,61
2.536,29
2.963,87
TOTAL
11.895
70.461
82.169
MÍNIMO
473
2.709
3.171
MÁXIMO
1.922
10.839
12.762
En promedio, estos casos tienen 991 palabras, 5.872 caracteres sin contar
los espacios y 6.847 caracteres contando los espacios, oscilando entre los
valores mínimos del caso 718 (con 473 palabras, 2.709 caracteres sin contar
los espacios y 3.171 caracteres contando los espacios) y los valores máximos
155
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
del caso 716 (con 1.922 palabras, 10.839 caracteres sin contar los espacios y
12.762 caracteres contando los espacios).
Para llevar a cabo las pruebas con ficheros de longitud variable, se han
generado tres ficheros a partir de los textos de los 12 casos clínicos
seleccionados. El primer fichero está compuesto por el texto fusionado de
los 12 casos, conteniendo en consecuencia un total de 11.895 palabras. El
segundo fichero consiste en este texto total duplicado, incluyendo 23.790
palabras. El tercer fichero es este último nuevamente duplicado, quedando
con un total de 47.580 palabras.
3. Montaje experimental
Para comparar los resultados de eficiencia de los procesos de anotación
local con los procesos de anotación remota, se ha desarrollado una clase
Java denominada TestAnnotations, que mide los tiempos de ejecución
necesarios para los diferentes casos de prueba. El funcionamiento de la
clase se basa en los siguientes métodos:
1) El constructor TestAnnotations(String ptext, String ponts, String plev,
String[] localSrc, String[] localLan): inicializa el objeto global
IntegrateAnnot usando todos los parámetros.
2) takeTime(): devuelve un long con el tiempo actual, permitiendo
cambiar fácilmente la unidad de tiempo entre milisegundos y
nanosegundos. Finalmente las medidas se han tomado usando
milisegundos.
3) avoidInitialization(): evita la inclusión del tiempo utilizado por GATE
para su inicialización en la primera ejecución.
4) testGate(String formatType), testOba(String formatType): en función
del valor del parámetro formatType ("", "html" o "xml") miden el
156
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
tiempo que tarda el proceso de anotación sin formatear, extrayendo
los términos en formato HTML o extrayéndolos en formato XML,
realizado a través de GATE (imagen superior de la Fig. 20) y del
servicio OBA (imagen inferior de la Fig. 20), respectivamente.
5) main: desde el método principal se discrimina entre los diferentes
casos de prueba, almacenando los resultados de cada uno de ellos
en un fichero de texto cuyos valores están separados por ";",
facilitando su importación desde una hoja excel. En primer lugar
ejecuta el conjunto de pruebas {Pi, i=1,...,27}, dividiéndolas en los
subconjuntos {Pi, i=1,...,6}, {Pi, i=7,...,12}, {Pi, i=13,...,18}, {Pi,
i=19,...,21}, {Pi, i=22,...,24} y {Pi, i=25,...,27}, estableciendo las
parametrizaciones local y remota adecuadas para cada subconjunto.
A continuación, recorre para cada subconjunto todos los casos
clínicos, ejecutando las pruebas utilizando los diferentes formatos
tantas veces como se le indique. En segundo lugar, ejecuta el
conjunto de pruebas {Pi, i=28,...,45} dividiéndolas en los
subconjuntos {Pi, i=28,...,33}, {Pi, i=34,...,39} y {Pi, i=40,...,45},
estableciendo nuevamente las parametrizaciones para cada
subconjunto e iterando entre los textos de diferentes longitudes
usando los diferentes formatos. Cada vez que recorre cualquiera de
los subconjuntos, antes de pasar al siguiente, almacena en un
fichero los resultados obtenidos, disponiéndose finalmente de 6
ficheros para el primer conjunto de pruebas y 3 para el segundo.
157
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
Figura 20 Llamadas de los métodos testGate (arriba) y testOba (abajo) de la clase
TestAnnotations para la ejecución de las pruebas.
La computadora en la que se han ejecutado los casos de prueba tiene
instalado un sistema operativo Windows 7 Ultimate de 64 bits y está
equipada con un procesador intel core i7. Dispone de 8 GB de memoria
RAM, habiéndose reservado 1,5 GB para la ejecución de la clase Java de
pruebas (empleando los parámetros -Xms y -Xmx).
4. Resultados
Los resultados de todas las pruebas se han agregado en el Apéndice 2. Los
valores medios de los tiempos resultantes al procesar los diferentes casos
clínicos con el conjunto de pruebas {Pi, i=1,...,27} están representados en las
158
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
Figuras 21, 22 y 23. Los datos presentados en la Fig. 21 se corresponden con
los resultados para el procesado de los textos utilizando la fuente
MedlinePlus, pudiéndose observar que el procesado local con listados del
orden de 103 conceptos, es dos órdenes de magnitud más rápido que el
procesado remoto: haciendo el promedio para los tres formatos el resultado
es de 22,13 ms (SD = 3,15) con la terminología monolingüe, o de 38,29 ms
(SD = 1,78) con la terminología bilingüe, frente a los 3.260,63 ms (SD =
1.191,57) obtenidos con el servicio remoto.
Figura 21 Tiempos medios de respuesta obtenidos para el reconocimiento de términos con
la fuente MedlinePlus sin formato, tras formatear en HTML y tras formatear en XML,
usando el sistema CLEiM con la terminología en inglés (P1, P2 y P3), usando el servicio OBA
(P4, P5 y P6) y el sistema CLEiM con la terminología bilingüe (P19, P20 y P21).
Además, es muy significativa la poca incidencia del tratamiento con los
diferentes formatos en ambos casos (en torno a 3 ms localmente
comparándolo con los valores obtenidos sin formatear la salida, no
llegándose a apreciar remotamente), cuestión que se acentúa con el
159
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
aumento de las terminologías locales o el aumento del texto de entrada en
el procesado remoto. La incorporación de la terminología de SNOMED CT
localmente provoca que ambos métodos se sitúen en el mismo orden de
magnitud (Fig. 22), con la terminología monolingüe el tiempo medio del
sistema local para todos los casos clínicos - promediando de nuevo los
tiempos obtenidos para las diferentes opciones de formato - es de 8.232,32
ms (SD = 58,72) frente a los 18.503,11 ms (SD = 7.506,31) del procesado
remoto. Al duplicar esta terminología incluyendo la lista de SNOMED CT en
español el sistema local se aproxima a los 30 segundos, en concreto hasta
27.520,19 ms (SD = 378,87), siendo un indicador de la gran dependencia del
procesado local respecto al número de términos incluidos en las listas,
incidiendo también en la cantidad de memoria que es necesario reservar
para la ejecución.
Figura 22 Tiempos medios de respuesta obtenidos para el reconocimiento de términos con
la fuente SNOMED CT sin formato, tras formatear en HTML y tras formatear en XML,
usando el sistema CLEiM con la terminología en inglés (P7, P8 y P9), usando el servicio OBA
(P10, P11 y P12) y el sistema CLEiM con la terminología bilingüe (P22, P23 y P24).
160
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
De nuevo se puede apreciar la poca incidencia que tiene el tratamiento del
formato,
obteniéndose
tiempos
menores
o
mayores
de
forma
independiente al formato de salida utilizado, tal y como reflejan los valores
medios obtenidos tras formatear el resultado local en HTML, de 8.229,97 ms
(SD = 35,12), o en XML, de 8.221,42 (SD = 94,29), frente al valor sin
formatear, de 8.245,58 ms (SD = 22,77); o el resultado remoto tras
formatear la salida en HTML, de 18.251,75 ms (SD = 7.151,55), frente al
valor sin formatear, de 18.260,89 ms (SD = 6.664,85). Este hecho se vuelve a
repetir cuando se llevan a cabo las pruebas con ambas terminologías (Fig.
23).
Figura 23 Tiempos medios de respuesta obtenidos para el reconocimiento de términos con
las fuentes MedlinePlus y SNOMED CT sin formato, tras formatear en HTML y tras
formatear en XML, usando el sistema CLEiM con la terminología en inglés (P13, P14 y P15),
usando el servicio OBA (P16, P17 y P18) y el sistema CLEiM con la terminología bilingüe
(P25, P26 y P27).
161
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
La inclusión de las diferentes listas locales no incide prácticamente en los
tiempos siempre que el número de términos sea del orden de 103, tal y
como se puede comprobar con los resultados del procesado local usando la
terminología bilingüe con ambas fuentes frente a los resultados usando
únicamente la terminología bilingüe de SNOMED, que da un tiempo de
respuesta medio para los tres formatos de 27.264,63 ms (SD = 330,09),
menor que el obtenido únicamente con SNOMED CT, de 27.520,19 ms (SD =
378,87).
A medida que la longitud de los textos se va haciendo mayor las diferencias
entre el procesado bilingüe local frente al monolingüe remoto se atenúan,
tal y como se puede observar a partir de los resultados obtenidos con los
casos clínicos (en orden creciente de palabras) 724, 721, 717, 726 y 716,
todos ellos con más de 1.000 palabras (Tabla 20).
Tabla 20. Promedio de los valores obtenidos remotamente con las terminologías
MedlinePlus y SNOMED CT y localmente con las equivalentes bilingües, para los casos con
mayor número de palabras.
CASO CLÍNICO
P16,P17,P18
P25,P26,P27
724
721
717
726
716
24.829
23.762
18.814
28.779
24.646
7.873,44
2.721,14
2.167,75
3.942,99
2.460,25
PROMEDIO
27.329
27.008
27.051
27.985
27.304
DESV. EST.
361,89
219,39
267,31
345,97
233,99
PROMEDIO (ms)
DESV. EST.
Se vislumbra en estos resultados locales una tendencia a estabilizarse los
tiempos en torno a 30 segundos, de forma cuasi independiente de la
longitud del texto procesado, mientras que los tiempos remotos se
incrementan notablemente. Esta tendencia se confirma al realizar el
conjunto de pruebas
{Pi, i=28,...,45}. Al eliminar la terminología más
numerosa (imagen superior de la Fig. 24) el procesado local está en torno a
162
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
los 300 ms mientras que el procesado remoto va en aumento, dando como
resultado: para el procesado sin formato (por ejemplo) del fichero de 11.895
palabras los valores de 276,30 ms (SD = 11,03) frente a 17.691,10 ms (SD =
1.559,19); para el fichero de 23.790 palabras el tiempo de 310,80 ms (SD =
9,43) frente a 34.572,10 ms (SD = 9.631,89); y para el fichero de 47.580, el
tiempo local de 353,80 ms (SD = 10,39) frente al tiempo remoto de
61.532,60 ms (SD = 18.964,60). Los tiempos medios locales al utilizar sólo la
fuente SNOMED CT bilingüe (imagen intermedia de la Fig. 24) son mayores
que los tiempos utilizando todas las fuentes (imagen inferior de la Fig. 24),
que tiene lógica porque al incluir todas las fuentes se evita la necesidad de
generar dinámicamente el fichero medicine.def. Los tiempos medios locales
de respuesta al incluir todas las fuentes se sitúan en torno a los 28
segundos, mientras que los tiempos remotos se disparan hasta varios
minutos. En concreto, el tratamiento sin formato para el primer fichero
localmente tarda 27.893,60 ms (SD = 479,56) frente a los 214.619,90 ms (SD
= 63.952,14) que tarda remotamente, el tiempo medio para el segundo
fichero es de 28.273,80 ms (SD = 595,65) frente a 359.817,30 ms (SD =
79.228,87), o para el tercer fichero el tiempo medio local es de 28.265,80
ms (SD = 587,60) frente al tiempo medio remoto que es de 680.625,00 ms
(SD = 166.203,70).
163
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
Figura 24 Tiempos medios de respuesta obtenidos para el reconocimiento los ficheros de
11.895 palabras (arriba), 23.790 (en medio) y 47.580 (abajo), representándose las
164
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
terminologías locales bilingües menos pobladas (Freebase y MedlinePlus) frente a
MedlinePlus en remoto en los tres formatos (P28-P31, P29-P32 y P30-P33), la local bilingüe
más poblada (SNOMED CT) frente a la equivalente remota en los tres formatos (P34-P37,
P35-P38 y P36-P39) y todas las locales frente a todas las remotas en los tres formatos (P40P43, P41-P44 y P42-P45).
165
EVALUACIÓN DE LA EFICIENCIA DEL SISTEMA
166
ESCENARIOS DE APLICACIÓN
CAPÍTULO 6. ESCENARIOS DE APLICACIÓN.
El principal escenario de aplicación, tal y como se ha mencionado
anteriormente, ha sido implementado en el contexto del EEES. Los
resultados de la investigación llevada a cabo en este contexto, que son
analizados en profundidad en este capítulo, han sido publicados en
Aparicio, De Buenaga, Rubio, & Hernando, (2012). Para desarrollar la
actividad de aprendizaje con estudiantes de medicina, con la que conducir la
experiencia de evaluación del sistema biomédico implementado, se ha
trabajado estrechamente con el personal docente de la Facultad de Ciencias
Biomédicas de la Universidad Europea de Madrid, dentro del Departamento
de Especialidades Médicas. Esta colaboración ha permitido definir el marco
idóneo en el que llevar a cabo la prueba, ayudando a establecer dos
metodologías bien diferenciadas:
Por un lado, se ha desarrollado una metodología que permite
construir una actividad de aprendizaje, enmarcada en la filosofía de
trabajo del EEES, haciendo uso de un sistema inteligente que
reconoce conceptos en casos clínicos y posibilita el acceso a
diferentes recursos, previamente definidos, que sirven para
profundizar en el significado de los mismos.
Por otro lado, se ha desarrollado una metodología de evaluación
con usuarios para este tipo de sistemas, que podría extenderse a
otras herramientas informáticas y a otras áreas de conocimiento
dentro del ámbito educativo.
1. Metodología de aprendizaje
167
ESCENARIOS DE APLICACIÓN
Para la evaluación del sistema inteligente se ha diseñado una metodología
de aprendizaje que, aplicándola a un grupo de estudiantes de segundo curso
del grado en medicina, ha servido para cuantificar los resultados tanto
objetivos como de percepciones subjetivas sobre el sistema inteligente. La
metodología de aprendizaje persigue que los estudiantes profundicen en el
significado de términos de interés que aparecen en un caso clínico, así como
interrelacionarlos entre ellos y con otros conceptos que no aparecen
explícitamente en el caso. El diseño de la metodología se fundamenta en
cuatro estadios bien diferenciados:
1. En el primer estadio, el conjunto de profesores que pondrán en
práctica la metodología en el aula, seleccionan un caso clínico
acorde con el nivel de conocimientos de los alumnos objeto de la
experiencia.
2. En el segundo estadio, son definidas las fuentes de conocimiento
disponibles desde las que es más adecuado extraer información
detallada sobre los conceptos reconocidos por el sistema. Este
proceso es un trabajo conjunto entre los docentes que llevarán a
cabo la prueba en el aula y el equipo de desarrollo del sistema
informático.
3. En el tercer estadio se diseña el cuestionario de preguntas de tipo
test, íntimamente relacionadas con el caso clínico seleccionado, por
parte del profesorado que ejecutarán la metodología. Este
cuestionario
servirá
para
medir
cuantitativamente
los
conocimientos adquiridos por los estudiantes tras realizar la
actividad.
168
ESCENARIOS DE APLICACIÓN
4. En el cuarto estadio es diseñada la actividad en el aula: duración de
la actividad, tipo de aula, participantes, división de los mismos en
diferentes grupos y tipo de participación (voluntaria u obligatoria).
Casos clínicos analizados
Algunos de los casos clínicos analizados para llevar a cabo la experiencia de
aprendizaje son: los casos de estudio publicados por el Departamento de
Patología de la Facultad de Medicina de la Universidad de Pittsburgh
(University of Pittsburgh Medical College, UPMC66); la colección de casos
publicados por Centro Nacional para la enseñanza de Casos de Estudio en
ciencias de la Universidad de Buffalo (National Center for Case Study
Teaching in Science at Buffalo University, NCCSTS67); los casos, actualmente
no disponibles, de la Facultad de Medicina de Penn State68. También se han
estudiado los informes médicos y las notas clínicas procedentes de la base
de datos restringida del proyecto MIMIC-II.
Finalmente se han seleccionado los casos publicados por la UPMC, por
varios motivos: (i) no presentan restricciones de acceso y utilización de los
contenidos, tal y como sucede con los procedentes del MIMIC-II, o, de un
modo menos restrictivo, con los casos del NCCSTS; (ii) el formato es
bastante uniforme para los diferentes casos, dividiendo básicamente su
contenido en un apartado dedicado al historial del paciente, otro para los
hallazgos patológicos y, en último lugar, otro para el diagnóstico final; (iii)
están clasificados por diferentes criterios (e.g. por año, por el índice
66
http://path.upmc.edu/cases.html
67
http://sciencecases.lib.buffalo.edu/cs/collection
68
http://www.pennstatehershey.org/web/college/home
169
ESCENARIOS DE APLICACIÓN
asignado o, incluso, pueden ser recuperados a través de una búsqueda de
palabras clave), facilitando el acceso y la búsqueda de los casos de interés;
(iv) la gran estabilidad de la base de datos de casos, que es mantenida desde
el año 1995 y aloja casos editados desde el año 1994; (v) son ampliamente
utilizados en medicina y otros dominios (e.g. Watson, Smith y Watter, 2005;
Ruiz-Rico, Vicedo y Rubio-Sánchez, 2008), formando parte de las referencias
manejadas por los docentes de la Facultad de Ciencias Biomédicas de
nuestra Universidad.
Algunos de los casos mejor analizados de esta fuente han sido los indexados
como 223, 410, 474, 564, 565 y 616, que fueron elegidos al azar y
seleccionados por obtenerse un conjunto amplio de conceptos reconocidos
a través del sistema. De entre este subconjunto, el que se consideró más
adecuado para llevar a cabo la actividad es el 22369. Este es el caso de una
mujer de 37 años con un diagnóstico de miocardiopatía arritmogénica del
ventrículo derecho, con muchos indicios debido a la gran cantidad de
patologías relacionadas en su familia.
Fuentes de conocimiento seleccionadas y sistema inteligente
La aplicación informática con la que se realiza la experiencia es una versión
monolingüe del sistema CLEiM denominada MedicalFace70, que preprocesa
el texto utilizando como fuentes de conocimiento Freebase y MedlinePlus en
inglés, siendo posible utilizar la primera de ellas a través de la anotación
local y la segunda a través del sistema remoto OBA. El resto de
funcionalidades son semejantes a las desarrolladas para el sistema CLEiM, es
69
path.upmc.edu/cases/case223.html
70
La aplicación está disponible en http://orion.esp.uem.es:8080/MedicalFace/
170
ESCENARIOS DE APLICACIÓN
decir, las búsquedas y el enlazado de conceptos a través de las relaciones
semánticas de los Tipos de Freebase y de los sinónimos MeSH en
MedlinePlus, así como las búsquedas bibliográficas en PubMed. En la Fig. 25
se muestra la interfaz Web tras procesar la historia clínica de la paciente del
caso clínico seleccionado.
Figura 25 Interfaz de usuario proporcionado a los estudiantes tras procesar el historial del
paciente del caso clínico 223 obtenido del UPMC.
Tras el procesado los alumnos obtienen como resultado un amplio conjunto
de términos de interés (a partir de las entidades reconocidas en el texto),
que proporcionan una idea previa del problema o del diagnóstico, dado que
muchos de ellos están relacionados con las patologías cardiacas. Cada uno
de estos términos está enlazado con la página asociada a la fuente (campo
SOURCE), que nos muestra los conceptos relacionados y la información
obtenida a partir de los servicios ofrecidos por la propia fuente de
conocimiento. Por ejemplo, el término "atrial fibrillation" es anotado con la
fuente Freebase, como enfermedad y como síntoma, y también con la
171
ESCENARIOS DE APLICACIÓN
fuente MedlinePlus (que nos indica que es una anotación realizada a través
la ontología MedlinePlus Health Topics del NCBO). Esto permite obtener una
descripción y relaciones semánticas del término tratándolo como un tipo de
enfermedad o como un tipo de síntoma en Freebase, así como una
descripción de los tópicos resultantes en MedlinePlus al hacer una búsqueda
por este término, que incluye un conjunto de conceptos MeSH para cada
tópico. Profundizando en la información de enfermedades de Freebase se
puede obtener, además de una descripción, un conjunto de síntomas,
factores de riesgo y tratamientos asociados a la enfermedad. Cada uno de
estos términos relacionados semánticamente se encuentra también
enlazado al tópico de la fuente. En caso de profundizar en el contenido del
Tipo síntoma, se puede obtener información semántica a través de las
Propiedades "efecto secundario de" (del Tipo tratamiento) y "síntoma de"
(del Tipo enfermedad). Si el Tipo seleccionado es un tratamiento, la
información relacionada se obtiene a través de las Propiedades "usado para
tratar" (del Tipo enfermedad) y "efecto secundario" (del Tipo síntoma). Si se
selecciona la fuente MedlinePlus, además de la descripción se obtienen
otros resultados relacionados con la búsqueda - tal y como son Arrhythmia,
Blood Thinners, entre otros - y los sinónimos de MeSH para cada uno de
ellos (los términos MeSH para Arrhythmia son Arrhythmias y Cardiac,
mientras que para Blood Thinners son Heparin, Platelet Aggregation
Inhibitors, Warfarin y Anticoagulants). Ya por último, existe la posibilidad de
capturar el listado de publicaciones científicas en PubMed, a partir de la
información resultante en las búsquedas sobre Freebase y sobre
MedlinePlus. En el primer caso, se enlazan los conceptos para la búsqueda
de publicaciones relacionadas, mientras que en el segundo caso se enlazan
tanto los conceptos como los sinónimos MeSH.
172
ESCENARIOS DE APLICACIÓN
Cuestionario para la evaluación objetiva de la actividad
El examen objetivo está compuesto por un cuestionario tipo test de
preguntas, todas basadas en la información que es posible obtener a partir
de los conceptos reconocidos por el sistema MedicalFace tras procesar el
caso clínico de la paciente, ampliamente estudiado por el conjunto de
profesores que han participado en la experiencia. Este cuestionario se
encuentra en el Apéndice 3. Aunque estas preguntas no se ajustan de forma
exacta a una categorización concreta, de forma aproximada sí que se
pueden agrupar según los siguientes tipos: epidemiología presentada por la
paciente (pregunta 2), factores de riesgo (pregunta 3), manifestaciones
clínicas (preguntas 1 y 9), tratamiento (preguntas 4, 5 ,6 ,7 y 10) y evolución
(pregunta 8). Estos tipos servirán para analizar algunas posibles diferencias
según el tipo de pregunta en los resultados de la prueba.
Diseño de la actividad en el aula
La actividad se plantea como una actividad a realizar voluntariamente,
aunque influyente en la nota de la asignatura. Se lleva a cabo en un
laboratorio en el que cada alumno dispone de una computadora con
conexión a internet para realizar el examen. La duración de la prueba se
establece en 90 minutos. A los alumnos participantes se les divide
aleatoriamente en dos grupos que realizan la prueba durante sesiones
distintas. Los alumnos pueden indicar su sexo y edad voluntariamente.
2. Metodología de evaluación
Para la evaluación del sistema inteligente a partir de la realización de la
actividad de aprendizaje en el aula, se ha procedido del siguiente modo:
173
ESCENARIOS DE APLICACIÓN
Se ha diseñado un cuestionario compuesto por 7 preguntas sobre el
sistema inteligente, dividido en dos partes (Tabla 21). La primera
parte, compuesta por 2 preguntas, está relacionada con la
percepción que tienen los estudiantes (después de la experiencia)
sobre el soporte al aprendizaje proporcionado por el sistema. La
segunda parte, compuesta de 5 preguntas, está orientada a medir la
percepción de los estudiantes en relación a la usabilidad del
sistema. Todas las preguntas son de tipo Likert (Likert, 1932),
utilizándose una escala de 1 a 5 (1 = Totalmente en desacuerdo, 2 =
En desacuerdo, 3 = Neutral, 4 = De acuerdo, 5 = Totalmente de
acuerdo).
Tras ofrecer la posibilidad de participación voluntaria al conjunto de
alumnos, se dividen aleatoriamente en dos grupos. Estos grupos se
denominarán Grupo A y Grupo B. Con el objetivo de medir las
diferencias que pudieran derivarse de la realización del examen de
conocimientos cuando los alumnos utilizan libremente todos los
recursos disponibles en Internet frente a los alumnos que utilizan el
sistema inteligente, a los alumnos del Grupo A se les permite libre
acceso a Internet, mientras que a los del Grupo B se les limita a la
información obtenida a partir del sistema inteligente.
A ninguno de los grupos se les proporciona ninguna orientación ni
formación previa, aunque todos los estudiantes del curso habían
realizado previamente un seminario sobre búsqueda de información
en ciencias de la salud.
Tras finalizar la experiencia de aprendizaje y completar el
cuestionario objetivo de preguntas tipo test, a los alumnos del
174
ESCENARIOS DE APLICACIÓN
Grupo B se les proporciona el cuestionario de preguntas de tipo
Likert, para que lo rellenen de forma anónima. Además el
profesorado recoge los comentarios realizados por los alumnos.
Tabla 21. Cuestionario Likert para la valoración de la percepción sobre el aprendizaje y la
usabilidad.
APRENDIZAJE
SUBJETIVO
USABILIDAD
SUBJETIVA
El sistema me ha ayudado a extraer información relevante sobre el caso
El sistema me ha ayudado a reducir el tiempo usado para comprenderlo respecto
a una búsqueda tradicional en internet
El interfaz es agradable
Es fácil de encontrar la información que necesito
Me siento cómodo utilizando el sistema
La velocidad es razonable
Es fácil de aprender a usar
3. Descripción del experimento
Tras ofrecer la posibilidad de participar voluntariamente en la experiencia
de aprendizaje a un total de 101 alumnos que, en el año académico 20102011 se encuentran cursando una asignatura de segundo curso del grado en
Medicina, deciden participar 60 de ellos.
Los 60 alumnos participantes se dividen aleatoriamente en los dos grupos A
y B. De los 60 alumnos participantes, 26 se agruparon en el Grupo A y 34 en
el Grupo B, el 63.3% eran mujeres (38 en total, 17 en el Grupo A y 21 en el
Grupo B), el 28.3% eran hombres (17 en total, 8 en el Grupo A y 9 en el
Grupo B) y el otro 8.3% no indicaron el sexo (5 en total, 1 en el Grupo A y 4
en el Grupo B). La edad media de los participantes era de 20.51 años (SD =
3.67) con un rango que iba desde los 19 hasta los 37 años.
A ambos grupos se les explica que la actividad consiste en la lectura del caso
clínico, proporcionado por los docentes en formato electrónico, y en
responder adecuadamente a las preguntas planteadas en el cuestionario
objetivo. Se les informa sobre el tiempo límite para acabar la prueba,
establecido en 90 minutos y, al finalizarla, los profesores toman nota del
175
ESCENARIOS DE APLICACIÓN
tiempo empleado por cada alumno. A los alumnos del Grupo B se les
proporciona, además, la dirección URL del sistema, indicándoseles que
utilicen únicamente la información obtenida a partir del mismo.
4. Resultados y discusión
Todos los resultados se encuentran en el Apéndice 4. El tiempo medio
consumido por los alumnos del Grupo A fue de 40.80 min (SD = 9.54)
mientras que por los del Grupo B fue 45.09 min (SD = 12.70), que es un
resultado coherente al tener en cuenta que los alumnos del Grupo B
tuvieron que rellenar adicionalmente el cuestionario de percepción
subjetiva.
Resultados de la prueba objetiva de conocimientos
Los resultados de esta prueba son muy prometedores, en cuanto a la
utilización de este tipo de sistemas informáticos en actividades educativas.
Mientras que los alumnos del Grupo A tienen acceso a toda la información
disponible en Internet, con toda la gama de recursos médicos que pueden
ser obtenidos de infinidad de sitios Web, los alumnos del Grupo B se ven
ciertamente limitados a muy pocas fuentes de conocimiento y a únicamente
un par de sitios Web: MedlinePlus y Freebase. Sin embargo, es precisamente
el hecho de permitir al profesor definir los caminos a través de los cuales los
alumnos acceden a la información, uno de los puntos fuertes de la
metodología de aprendizaje propuesta. Antes de realizar la prueba, el
profesor ya conoce los posibles mecanismos que alumno puede utilizar para
acceder a la información de interés, teniendo además el control de selección
de la misma, utilizando criterios de idoneidad de acuerdo con los alumnos a
los que está orientada la prueba, calidad y fiabilidad de los datos, claridad
176
ESCENARIOS DE APLICACIÓN
del contenido, etc. La nota media obtenida en esta prueba para los alumnos
del Grupo A es de 7,69 (SD = 1,38), que es ligeramente inferior a la nota
media obtenida por los alumnos del Grupo B, que es de 7,85 (SD = 1,62). El
porcentaje medio de preguntas resueltas correctamente por cada uno de los
grupos se muestra en la Fig. 26. Todos los alumnos obtienen una calificación
superior a 5.
Las diferencias más acentuadas, entre los resultados de uno y otro grupo,
están localizadas en las siguientes preguntas: en la número 8 (sobre la
evolución de la paciente) el 88,46 % de los estudiantes que usaron
libremente los recursos de Internet acertaron la respuesta, mientras que la
cifra se reduce al 50 % para los estudiantes que usaron MedicalFace; en la
número 2 (sobre epidemiología) el 85,29 % de los estudiantes que usan
MedicalFace aciertan la respuesta en contraste con el 57,69 % que la
aciertan usando Internet sin restricciones; en la número 6 (sobre el
tratamiento de la arritmia) el 73,53 % de los estudiantes que utilizan
MedicalFace dan la respuesta correcta frente al 50 % que lo hace usando
Internet. Estas diferencias pueden estar relacionadas con la longitud del
camino de búsqueda hacia la solución utilizando el sistema MedicalFace,
que es más largo para la primera de las preguntas (la número 8) mientras
que se acorta notablemente en las dos segundas (2 y 6).
177
ESCENARIOS DE APLICACIÓN
Figura 26 Porcentaje de respuestas del examen de conocimientos resueltas correctamente
por los estudiantes.
Resultados de las encuestas de percepción
Para el análisis de los resultados a las preguntas de percepción
proporcionadas a los alumnos del Grupo B, se han utilizado la mediana, la
moda y el recuento total de cada categoría (Tabla 22), en lugar de utilizar
medidas como la media y la desviación estándar que son más adecuadas
para aquellos tipos de datos en los que el intervalo entre los diferentes
valores es objetivamente igual (cuestión que no tiene por qué darse al
utilizar este tipo de escalas Likert, donde hay que tener en cuenta la
percepción subjetiva entre un valor y otro de cada sujeto), tal y como se
menciona en Jamieson (2004).
Tabla 22. Conteo de respuestas para cada pregunta subjetiva de aprendizaje (PA) y
usabilidad (PU), mediana y moda.
178
ESCENARIOS DE APLICACIÓN
PREGUNTA
NÚMERO DE RESPUESTAS PARA CADA VALOR
LIKERT
MODA
MEDIANA
6
4
4
15
7
4
4
12
18
3
4
4
8
15
8
4
4
1
8
16
7
4
4
1
5
19
7
4
4
1
1
9
23
5
5
1
2
3
4
5
PA 1
2
2
10
14
PA 2
3
1
8
PU 1
1
0
PU 2
1
2
PU 3
2
PU 4
2
PU 5
0
PA 1 = El sistema me ha ayudado a extraer información relevante sobre el caso
PA 2 = El sistema me ha ayudado a reducir el tiempo usado para comprenderlo respecto a una búsqueda
tradicional en internet
PU 1 = El interfaz es agradable
PU 2 = Es fácil de encontrar la información que necesito
PU 3 = Me siento cómodo utilizando el sistema
PU 4 = La velocidad es razonable
PU 5 = Es fácil de aprender a usar
La percepción de los estudiantes, tanto en relación con el soporte ofrecido
por la herramienta informática para el aprendizaje como en los aspectos de
usabilidad de la misma, es muy positiva, situándose el valor umbral mínimo
de la mediana y de la moda en 4. Es decir, la mayoría de los estudiantes han
percibido que el sistema les ha ayudado a extraer información relevante
sobre el caso (PA 1) y les ha ayudado a reducir el tiempo usado para
comprenderlo respecto a una búsqueda tradicional en Internet (PA 2).
Además, la mayoría han considerado que: el interfaz del sistema es
agradable (PU 1), es fácil encontrar la información que se necesita (PU 2), se
han sentido cómodos utilizando el sistema (PU 3), la velocidad les parece
razonable (PU 4) y es fácil aprender a utilizarlo (PU 5).
En concreto, en las preguntas de aprendizaje (Fig. 27): el 58,82 % (20
alumnos) están de acuerdo (41,18 %) o totalmente de acuerdo (17,65 %) en
relación a la primera pregunta, frente al 11,76 % (4 alumnos) que están en
desacuerdo (5,88 %) o totalmente en desacuerdo (5,88 %); el 64,71 % (22
179
ESCENARIOS DE APLICACIÓN
alumnos) están de acuerdo (44,12 %) o totalmente de acuerdo (20,59 %) en
relación a la segunda pregunta, frente al 11,76 % (4 alumnos) que están en
desacuerdo (2,94 %) o totalmente en desacuerdo (8,82 %).
Figura 27 Porcentaje de respuestas en la escala Likert en las dos preguntas sobre la ayuda
ofrecida por sistema al aprendizaje (PA).
Mientras que en las preguntas sobre usabilidad (Fig. 28) se obtiene que: el
61,76 % (21 alumnos) están de acuerdo (52,94 %) o totalmente de acuerdo
(8,82 %) con PU 1, frente al 2,94 % (1 alumno) que está totalmente en
desacuerdo; el 67,65 % (23 alumnos) están de acuerdo (44,12 %) o
totalmente de acuerdo (23,53 %) con PU 2, frente al 8,82 % (3 alumnos) que
está en desacuerdo (5,88 %) o totalmente en desacuerdo (2,94 %); el 67,65
180
ESCENARIOS DE APLICACIÓN
% (23 alumnos) están de acuerdo (47,06 %) o totalmente de acuerdo (20,59
%) con PU 3, frente al 8,82 % (3 alumnos) que está en desacuerdo (2,94 %) o
totalmente en desacuerdo (5,88 %); el 76,47 % (26 alumnos) están de
acuerdo (55,88 %) o totalmente de acuerdo (20,59 %) con PU 4, frente al
8,82 % (3 alumnos) que está en desacuerdo (2,94 %) o totalmente en
desacuerdo (5,88 %); el 94,12 % (32 alumnos) están de acuerdo (26,47 %) o
totalmente de acuerdo (67,65 %) con PU 5, frente al 2,94 % (1 alumno) que
está en desacuerdo (2,94 %).
Figura 28 Porcentaje de respuestas en la escala Likert en las cinco preguntas sobre la
usabilidad del sistema (PU).
181
ESCENARIOS DE APLICACIÓN
Esta percepción en general tan positiva sobre las 5 preguntas de usabilidad,
queda reflejada en los valores de la mediana y la moda de las encuestas
Likert realizadas por cada usuario (Fig. 29). Observando la mediana por
usuario, se puede concluir que el 79,41 % de los estudiantes (27 alumnos)
están mayoritariamente de acuerdo (64,71 %, 22 alumnos) o totalmente de
acuerdo (14,71 %, 5 alumnos) con las preguntas de usabilidad planteadas,
frente al 5,88 % (únicamente 2 alumnos) que están mayoritariamente en
desacuerdo (1 alumno) o totalmente en desacuerdo (1 alumno).
Observando la moda, se puede concluir que el 73,53 % de los estudiantes
(25 alumnos) indican con mayor frecuencia que están de acuerdo (55,88 %,
19 alumnos) o totalmente de acuerdo (17,65 %, 6 alumnos) con las
preguntas, frente al 5,88 % (2 alumnos) que indican con mayor frecuencia
estar en desacuerdo (1 alumno) o totalmente en desacuerdo (1 alumno) con
la usabilidad.
Figura 29 Recuento de la mediana y la moda por usuario para las preguntas de usabilidad.
182
ESCENARIOS DE APLICACIÓN
Al finalizar las sesiones de evaluación con los alumnos del Grupo B, los
profesores de medicina que dirigieron la experiencia en el aula tomaron
nota de los comentarios realizados verbalmente por los estudiantes, en
relación al empleo de la herramienta MedicalFace. Los comentarios más
relevantes, desde el punto de vista de los docentes, estaban relacionados
con las limitaciones de la herramienta en relación a la gran cantidad de
información ofrecida por Internet, con el idioma utilizado (íntegramente en
inglés), con las limitaciones de las búsquedas en PubMed, con la cantidad de
información irrelevante que aparecían en el sitio Web de Freebase y con la
velocidad de las anotaciones (fundamentalmente relacionado con las
anotaciones remotas a través del OBA, que posteriormente ha mejorado su
eficiencia notablemente respecto al momento de realización de la
experiencia). Sin embargo, a pesar de estos comentarios verbales, no se
encuentra un reflejo claro a estas problemáticas en los resultados obtenidos
por los estudiantes en la prueba. Por ejemplo, las preguntas relacionadas
con las búsquedas bibliográficas en PubMed eran la 4 y la 5. En la pregunta 4
se obtuvieron resultados marginalmente mejores utilizando libremente
Internet (92,31 % frente a 88,24 % de aciertos), pero en la pregunta 5 se
obtuvo un porcentaje de aciertos claramente superior en los alumnos que
utilizaron MedicalFace (82,35 % frente al 65,38 %).
183
ESCENARIOS DE APLICACIÓN
184
CONCLUSIONES
CAPÍTULO 7. CONCLUSIONES.
A continuación se hará una recapitulación de las principales aportaciones de
este trabajo de investigación y las conclusiones fundamentales, en relación
con los objetivos planteados en el capítulo 2.
1. Modelo y herramienta bioinformática cross-lingüe
Tal y como se mencionaba en el capítulo 1, existe una necesidad de afrontar
el desarrollo de nuevas herramientas bioinformáticas que faciliten, a los
diferentes especialistas involucrados en las etapas del proceso de traslación
de conocimientos en las ciencias de la salud, el acceso a las fuentes de
información existentes. Además, el desarrollo de estas herramientas puede
estar basado en las diferentes estrategias computacionales ya existentes,
pero aplicadas adecuadamente al contexto biomédico. El control de la
información integrada a través de estas herramientas permite, por un lado,
asegurar la calidad y la fiabilidad de los datos y, por otro lado, la adaptación
de los contenidos a diferentes perfiles de usuario.
La tarea emergente de reconocimiento cross-lingüe de conceptos tiene una
amplia variedad de aplicaciones en diferentes dominios, pero la complejidad
de los algoritmos computacionales requeridos dificulta el uso de las técnicas
desarrolladas para resolver esta tarea desde sistemas online. Por otro lado,
debido fundamentalmente a que los resultados de la tarea se orientan a la
resolución de otro tipo de problemas de PLN y minería de texto, los sistemas
desarrollados para abordar estas tareas de reconocimiento no se suelen
orientar a los usuarios finales humanos y, en particular, a usuarios que no
sean expertos en el estas áreas de conocimiento.
185
CONCLUSIONES
El modelo de software presentado en esta investigación y su
implementación en el dominio biomédico muestran algunas de las
posibilidades que tienen estos sistemas de extracción de información, no
sólo para dar soporte en la resolución de otros problemas más complejos
sino también como utilidad orientada a un conjunto de usuarios finales, que
tienen como objetivo la resolución de una prueba en el ámbito educativo.
En los capítulos 3 y 4 se ha descrito el proceso de selección de fuentes de
conocimiento y el desarrollo del sistema para el reconocimiento de
conceptos en inglés y español, que son preprocesados para su posterior
procesamiento local de forma online. Además, se ha mostrado cómo este
proceso se puede integrar con otros servicios de anotación, como es el
extraordinario servicio OBA. Como resultado de estos procesos, se consigue
proveer a los clientes del sistema de información cross-lingüe sobre
conceptos de interés localizados en el texto enviado al sistema, siendo esta
información obtenida desde diferentes enlaces a sitios Web externos.
Asimismo, el sistema proporciona un conjunto de enlaces para navegar a
través del mismo y obtener información detallada en inglés relacionada con
los conceptos extraídos y otros conceptos relacionados semánticamente.
2. Escalabilidad
La necesidad de integrar fuentes en diferentes idiomas cuyos contenidos se
adapten a diferentes perfiles de usuario en el dominio biomédico, la
posibilidad de aplicar el mismo modelo a otros dominios, la capacidad de la
herramienta desarrollada para integrar otras técnicas de procesamiento o
para dar respuesta a otros clientes, son aspectos planteados como objetivos
de escalabilidad del modelo.
186
CONCLUSIONES
En el segundo capítulo de esta memoria se ha expuesto el modelo
arquitectónico en el que se basa el desarrollo del sistema biomédico CLEiM,
que lo hace escalable en varias direcciones, tales como: fuentes de
anotación, fuentes de información detallada y semántica, fuentes de
conocimiento cross-lingüe, servicios externos para el procesamiento del
texto, incorporación de otros sistemas o herramientas (e.g. Villa, Aparicio,
Maña, & Buenaga, 2012; Gachet, Aparicio, Buenaga, & Padrón, 2012) y
aplicación a diferentes dominios de conocimiento (e.g. Muñoz, Aparicio,
Buenaga, Gachet, Puertas, Giráldez, & Gaya, 2011).
3. Evaluación con usuarios
El proceso de evaluación con estudiantes, a través de una experiencia de
aprendizaje activo en el aula, ha dado lugar al desarrollo de dos
metodologías: por un lado, la metodología de aprendizaje activo usando
sistemas de extracción de conceptos (sobre la que no se pueden sacar
conclusiones de aprendizaje largo plazo) y, por otro lado, una metodología
de evaluación de sistemas inteligentes basada en la experiencia de los
usuarios al resolver una tarea concreta.
Tras los resultados obtenidos en esta experiencia educativa, se ha
demostrado que la herramienta utilizada permite al profesorado controlar
las fuentes de conocimiento, conociendo por adelantado los diferentes
caminos utilizados por los estudiantes para resolver un conjunto de
preguntas, sin empeorar por ello los resultados respecto a una actividad
equivalente ofreciéndoles a los alumnos un acceso sin restricciones a
Internet. Además, teniendo en cuenta la importancia que tiene la
motivación y la percepción de los sujetos en el proceso de adquisición de
conocimientos en el reciente modelo de educación centrada en el alumno,
187
CONCLUSIONES
los resultados en este sentido se pueden considerar muy destacados. Los
estudiantes han considerado mayoritariamente que la herramienta es útil
en el proceso de aprendizaje, además de ser un sistema usable. Por tanto, la
realización de esta actividad ha demostrado el gran potencial que sistemas,
como el desarrollado en esta tesis, pueden tener cuando son orientados a
los usuarios finales y, más aún, en el ámbito educativo.
4. Resumen de contribuciones del sistema biomédico
A continuación se muestra un listado con las cuestiones más importantes
que han sido afrontadas al desarrollar el sistema biomédico:
Extracción bilingüe de términos para su utilización en tareas de
reconocimiento de entidades.
Integración de servicios remotos para el procesado de textos con
técnicas desarrolladas por terceros, sin depender su funcionamiento
exclusivamente de los mismos gracias a los procesos de anotación
locales.
Proporcionar
un
conjunto
de
conceptos
relacionados
semánticamente: sinónimos (MeSH a partir de MedlinePlus),
sinónimos obtenidos por el OBA (anotaciones directas), relaciones
"es_un" obtenidas por el OBA (a través del nivel de profundidad en
las búsquedas de las ontologías), relaciones del tipo "tiene un" de
Freebase (dando lugar a toda una gama de relaciones a partir del
término original).
Información cross-lingüe para las entidades reconocidas y otros
conceptos relacionados.
188
CONCLUSIONES
Capacidad para procesar en línea textos largos (a partir de 2 órdenes
de magnitud superiores a los permitidos por el servicio OBA, cuyo
máximo de 500 palabras ya ha sido mencionado) en tiempos
razonables.
Aplicación de la herramienta al ámbito educativo con el desarrollo
de una actividad de aprendizaje en el aula.
Resultados cualitativos en formato estructurado, que han permitido
cuantificar la percepción de los usuarios del sistema en relación a
dos aspectos: el soporte ofrecido por la herramienta para la tarea
educativa y la usabilidad.
Escalabilidad del modelo subyacente: Aplicabilidad a otros dominios
e idiomas, a otro tipo de tareas de procesamiento del texto, a otras
fuentes de extracción de términos, a otras fuentes de información
semántica y descriptiva y a otros servicios remotos para el
procesamiento del texto.
189
CONCLUSIONES
190
TRABAJO FUTURO
CAPÍTULO 8. TRABAJO FUTURO.
Dado que la investigación llevada a cabo ha abierto nuevas líneas de
investigación, serán precisamente estas nuevas líneas las que constituirán el
trabajo futuro sobre el que se pueden centrar los esfuerzos más
importantes. Estas nuevas líneas son las siguientes:
Desarrollo de nuevas experiencias de evaluación utilizando:
o
Sistemas de extracción de conceptos cross-lingüe.
o
Sistemas de anotación que permitan la gestión y
reutilización de corpus anotados, para perfiles de usuario
con intereses investigadores o alumnos de los últimos
cursos.
o
Sistemas que construyan mapas mentales y conceptuales
aprovechando las relaciones semánticas entre las entidades.
Análisis cuantitativos y cualitativos con otros actores en el mismo
contexto educativo:
o
Con el profesorado médico, para la selección de las
aplicaciones informáticas consideradas más adecuadas a la
hora de preparar y realizar en el aula actividades de
aprendizaje, así como posibles mejoras de los sistemas que
están siendo desarrollados.
o
Con alumnos de diferentes cursos.
o
Con personal investigador y docente de otras áreas de
conocimiento.
Extensión de la experiencia de evaluación a otras herramientas,
aprovechando la variedad de usuarios disponibles en la universidad,
y a otros contextos más allá del universitario.
191
TRABAJO FUTURO
Aplicación de la herramienta a procesos de clasificación automática
y agrupamiento del dominio biomédico u otros dominios, utilizando
la anotación enriquecida con información semántica.
También hay algunos aspectos de la herramienta bioinformática y de la
evaluación, presentadas en esta tesis, sobre las que podría ser muy
interesante seguir trabajando, tales como:
Mediciones a largo plazo sobre el conocimiento adquirido por los
alumnos al realizar actividades de aprendizaje como la llevada a
cabo, para poder valorar en qué medida este tipo de actividad
puede ayudar a fijar los conocimientos en los estudiantes.
Explotar otras funcionalidades ofrecidas por el servicio OBA, tal y
como son las expansiones de búsqueda de conceptos por los tipos
semánticos de UMLS, o por otros servicios como el OBR para la
integración de otros recursos.
Incorporación de otros elementos de GATE en el pipeline de
aplicación, tales como: el componente de anotación de GATE con
MetaMap y otros Gazetteer (LKB, extendido, etc.).
Valorar el desarrollo de los servicios utilizando recursos como las
librerías Jersey orientadas a la construcción de servicios Web
RESTful71.
Inclusión de algoritmos para la detección de la negación y/o
especulación que, en el caso del procesado de casos clínicos,
indicarían si los conceptos detectados forman parte de la
71
http://jersey.java.net/
192
TRABAJO FUTURO
sintomatología clínica o realmente aparecen en el texto tras haberse
descartado.
193
TRABAJO FUTURO
194
BIBLIOGRAFÍA
BIBLIOGRAFÍA
Abecker, A., & Elst, L. (2009). Ontologies for Knowledge Management. In S.
Staab & R. Studer (Eds.), Handbook on Ontologies (pp. 713-734).
Berlin, Heidelberg: Springer Berlin Heidelberg.
Adams, S. A. (2010). Revisiting the online health information reliability
debate in the wake of «web 2.0»: An inter-disciplinary literature and
website review. International Journal of Medical Informatics, 79(6),
391–400.
Altbach, P. G., Reisberg, L., & Rumbley, L. (2009). Trends in global higher
education: tracking an academic revolution. Report for the UNESCO
2009 World Conference on Higher Education, pp. 111-121.
Aparicio, F., Buenaga, M., Rubio, M., & Hernando, A. (2012). An intelligent
information access system assisting a case based learning
methodology evaluated in higher education with medical students.
Computers & Education, 58(4), 1282–1295.
Aparicio, F., Buenaga, M., Rubio, M., Hernando, M. A., Gachet, D., Puertas,
E., & Giráldez, I. (2011). TMT: A scalable platform to enrich
translational
medicine
environments.
Proc.
of
the
IADIS
International Conference e-Society 2011 (pp. 401-405), Avila, Spain.
Aparicio, F., Buenaga, M., Rubio, M., Hernando, M. A., Gachet, D., Puertas,
E., & Giráldez, I. (2011). TMT: A tool to guide users in finding
information on clinical texts. Revista de la Sociedad Española de
Procesamiento de Lenguaje Natural, 46, 27-34
Aparicio, J. J., & Moneo, M. R. (2005). Constructivism, the So-Called
Semantic Learning Theories, and Situated Cognition versus the
195
BIBLIOGRAFÍA
Psychological Learning Theories. The Spanish Journal of Psychology,
(002), 180–198.
Armano, G., Gemmis, M., Semerano, G., & Vargiu, E. (2010). Intelligent
Information Access. Springer.
Aronson, A. R. (2001). Effective mapping of biomedical text to the UMLS
Metathesaurus: the MetaMap program. Proceedings AMIA Annual
Symposium, 17–21.
Aronson, A. R., & Lang, F. M. (2010). An overview of MetaMap: historical
perspective and recent advances. Journal of the American Medical
Informatics Association, 17(3), 229–236.
Auer, S., Bizer, C., Kobilarov, G., Lehmann, J., Cyganiak, R., & Ives, Z. (2007).
DBpedia: A Nucleus for a Web of Open Data. En K. Aberer, K.-S. Choi,
N. Noy, D. Allemang, K.-I. Lee, L. Nixon, J. Golbeck, et al. (Eds.), The
Semantic Web, Lecture Notes in Computer Science (Vol. 4825, pp.
722–735). Springer Berlin / Heidelberg.
Baeten, M., Kyndt, E., Struyven, K., & Dochy, F. (2010). Using studentcentred learning environments to stimulate deep approaches to
learning: Factors encouraging or discouraging their effectiveness.
Educational Research Review, 5(3), 243-260.
Baldoni, M., Baroglio, C., Patti, V., & Rena, P. (2011). ArsEmotica: emotions
in the social semantic web. Proceedings of the 7th International
Conference on Semantic Systems, I-Semantics’11 (pp. 171–174).
New York, NY, USA: ACM.
Baumgartner, W. A., Cohen, K. B., Fox, L. M., Acquaah-Mensah, G., &
Hunter, L. (2007). Manual curation is not sufficient for annotation of
genomic databases. Bioinformatics, 23(13), i41–i48.
196
BIBLIOGRAFÍA
Bellazzi R., C. Larizza, M. Gabetta, G. Milani, A. Nuzzo, V. Favalli y E.
Arbustini. 2010. Translational Bioinformatics: Challenges and
Opportunities for Case-Based Reasoning and Decision Support.
LNCS: Case-Based Reasoning, Vol. 6176, pp. 1-11.
Bizer, C., Lehmann, J., Kobilarov, G., Auer, S., Becker, C., Cyganiak, R., &
Hellmann, S. (2009). DBpedia - A crystallization point for the Web of
Data. Web Semantics: Science, Services and Agents on the World
Wide Web, 7(3), 154-165.
Bhogal, J., Macfarlane, A., & Smith, P. (2007). A review of ontology based
query expansion. Information Processing & Management, 43(4),
866–886.
Bodenreider, O. (2008). Biomedical ontologies in action: role in knowledge
management, data integration and decision support. Yearbook of
Medical Informatics, 67–79.
Bollacker, K., Evans, C., Paritosh, P., Sturge, T., & Taylor, J. (2008). Freebase:
a collaboratively created graph database for structuring human
knowledge. Proceedings of the 2008 ACM SIGMOD international
conference on Management of data, SIGMOD’08 (pp. 1247–1250).
New York, NY, USA: ACM.
Brand-Gruwel, S., & Stadtler, M. (2011). Solving information-based
problems: Evaluating sources and information. Learning and
Instruction, 21(2), 175-179.
Brenes, D. J., Gayo-Avello, D., & Pérez-González, K. (2009). Survey and
evaluation of query intent detection methods. Proceedings of the
2009 workshop on Web Search Click Data, WSCD’09 (pp. 1–7). New
York, NY, USA: ACM.
197
BIBLIOGRAFÍA
Chen, J., & Li, F. (2010). Resource acquisition, sharing, and use in intelligent
information access: An investigation of the researchers. Proceedings
of the American Society for Information Science and Technology,
47(1), 1-10.
Chodos, D., Stroulia, E., Boechler, P., King, S., Kuras, P., Carbonaro, M., & de
Jong, E. (2010). Healthcare education with virtual-world simulations.
Proceedings of the 2010 ICSE Workshop on Software Engineering in
Health Care, SEHC’10 (pp. 89-99). Cape Town, South Africa.
Choi, I., Rho, S., Jeong, Y. S., & Kim, M. (2011). Relation Extraction from
Documents for the Automatic Construction of Ontologies. En J. J.
Park, L. T. Yang, & C. Lee (Eds.), Future Information Technology (Vol.
184, pp. 21–28). Berlin, Heidelberg: Springer Berlin Heidelberg.
Clark, D. B., Touchman, S., Martinez-Garza, M., Ramirez-Marin, F., &
Skjerping Drews, T. (2012). Bilingual language supports in online
science inquiry environments. Comput. Educ., 58(4), 1207–1224.
Cook, D. A., Levinson, A. J., Garside, S., Dupras, D. M., Erwin, P. J., &
Montori, V. M. (2008). Internet-Based Learning in the Health
Professions. JAMA: The Journal of the American Medical Association,
300(10), 1181 -1196.
Cruz-Toledo, J., McKeague, M., Zhang, X., Giamberardino, A., McConnell, E.,
Francis, T., DeRosa, M. C., et al. (2012). Aptamer base: a
collaborative knowledge base to describe aptamers and SELEX
experiments. Database: The Journal of Biological Databases and
Curation, 2012.
Davies, J., Grobelnik, M., & Mladenić, D. (2009). Semantic Knowledge
Management: Integrating Ontology Management, Knowledge
Discovery, and Human Language Technologies. Springer.
198
BIBLIOGRAFÍA
D’Antoni, A., Zipp, G., Olson, V., & Cahill, T. (2010). Does the mind map
learning strategy facilitate information retrieval and critical thinking
in medical students? BMC Medical Education, 10(1), 61.
D’Antoni, A., Zipp, G., & Olson, V. (2011). Interrater reliability of the mind
map assessment rubric in a cohort of medical students. BMC
Medical Education, 9, 19-19.
De la Villa, M., Aparicio, F., Maña, M., & Buenaga, M. (2012). A learning
support tool with clinical cases based on concept maps and medical
entity recognition. Proceedings of the 2012 ACM international
conference on Intelligent User Interfaces, IUI’12 (pp. 61–70). New
York, NY, USA: ACM.
Dolmans, D. H. J. M., & van der Vleuten, C. P. M. (2010). Research in medical
education: pratical impact on medical training and future
challenges. GMS Zeitschrift für medizinische Ausbildung, 27(2).
Dowell, K. G., McAndrews-Hill, M. S., Hill, D. P., Drabkin, H. J., & Blake, J. A.
(2009). Integrating text mining into the MGI biocuration workflow.
Database: The Journal of Biological Databases and Curation, 2009.
Embley, D., & Zitzelberger, A. (2010). Theoretical Foundations for Enabling a
Web of Knowledge. En S. Link & H. Prade (Eds.), Foundations of
Information and Knowledge Systems, Lecture Notes in Computer
Science (Vol. 5956, pp. 211–229). Springer Berlin / Heidelberg.
Embley, D. W., Liddle, S. W., Lonsdale, D. W., & Tijerino, Y. (2011).
Multilingual Ontologies for Cross-Language Information Extraction
and Semantic Search. En M. Jeusfeld, L. Delcambre, & T.-W. Ling
(Eds.), Conceptual Modeling – ER 2011 (Vol. 6998, pp. 147–160).
Berlin, Heidelberg: Springer Berlin Heidelberg.
199
BIBLIOGRAFÍA
Espinoza, M., Gómez-Pérez, A., & Mena, E. (2008). Enriching an Ontology
with Multilingual Information. En S. Bechhofer, M. Hauswirth, J.
Hoffmann, & M. Koubarakis (Eds.), The Semantic Web: Research and
Applications (Vol. 5021, pp. 333–347). Berlin, Heidelberg: Springer
Berlin Heidelberg.
Federico, M. (2011). Cross-Language Information Retrieval Jian-Yun Nie
(University of Montreal) San Rafael, CA: Morgan & Claypool
(Synthesis Lectures on Human Language Technologies, edited by
Graeme Hirst, volume 8), 2010. Computational Linguistics, 37(2),
411–412.
Feldman, R., & Sanger, J. (2007). The Text Mining Handbook: Advanced
Approaches in Analyzing Unstructured Data. Cambridge University
Press.
Fu, B., Brennan, R., & O’Sullivan, D. (2009). Cross-Lingual Ontology Mapping
– An Investigation of the Impact of Machine Translation. En A.
Gómez-Pérez, Y. Yu, & Y. Ding (Eds.), The Semantic Web (Vol. 5926,
pp. 1–15). Berlin, Heidelberg: Springer Berlin Heidelberg.
Gachet, D., Aparicio, F., Buenaga, M., & Padrón, V. (2012). Personalized
Health Care System with Virtual Reality Rehabilitation and
Appropriate Information for Seniors. Sensors, 12(5), 5502–5516.
Gijbels, D., & Loyens, S. M. M. (2009). Constructivist learning (environments)
and how to avoid another tower of Babel: reply to Renkl.
Instructional Science, 37(5), 499-502.
Gómez-Pérez, A., Fernández-López, M., & Corcho, O. (2004). Ontological
engineering : with examples from the areas of knowledge
management, e-commerce and the semantic web. London: SpringerVerlag.
200
BIBLIOGRAFÍA
Gracia, J., Montiel-Ponsoda, E., Cimiano, P., Gómez-Pérez, A., Buitelaar, P., &
McCrae, J. (2012). Challenges for the multilingual Web of Data. Web
Semantics: Science, Services and Agents on the World Wide Web,
11(0), 63–71.
Graf, S., Kinshuk, & Holzinger, A. (2010). International Workshop on Enabling
User Experience with Future Interactive Learning Systems (UXFUL
2010). In G. Leitner, M. Hitz, & A. Holzinger (Eds.), HCI in Work and
Learning, Life and Leisure (Vol. 6389, pp. 318-321). Berlin,
Heidelberg: Springer Berlin Heidelberg.
Gruber, T. R. (1993). A translation approach to portable ontology
specifications. Knowl. Acquis., 5(2), 199–220.
Guerrero, A. E., Minguillón, J., Guàrdia, L., & Sangrà, A. (2009). Metadata for
describing learning scenarios under the European Higher Education
Area paradigm. In M.-A. Sicilia & M. D. Lytras (Eds.), Metadata and
Semantics (pp. 69-79). Boston, MA: Springer US.
Hamburg, M. A., & Collins, F. S. (2010). The Path to Personalized Medicine.
New England Journal of Medicine, 363(4), 301–304.
Han, X., & Zhao, J. (2009). CASIANED: Web Personal Name Disambiguation
Based on Professional Categorization. Proceedings of 2nd Web
People Search Evaluation Workshop (WePS2) 2009, Madrid, Spain.
Hancock, D., Morrison, N., Velarde, G., & Field, D. (2009). Terminizer Assisting Mark-Up of Text Using Ontological Terms. Nature
Precedings.
Heilman, J. M., Kemmann, E., Bonert, M., Chatterjee, A., Ragar, B., Beards,
G. M., Iberri, D. J., et al. (2011). Wikipedia: A Key Tool for Global
Public Health Promotion. Journal of Medical Internet Research,
13(1).
201
BIBLIOGRAFÍA
Hildebrand, M., & van Ossenbruggen, J. (2012). Linking User Generated
Video Annotations to the Web of Data. En K. Schoeffmann, B.
Merialdo, A. Hauptmann, C.-W. Ngo, Y. Andreopoulos, & C.
Breiteneder (Eds.), Advances in Multimedia Modeling, Lecture Notes
in Computer Science (Vol. 7131, pp. 693–704). Springer Berlin /
Heidelberg.
Holzinger, A., Emberger, W., Wassertheurer, S., & Neal, L. (2008). Design,
development and evaluation of online interactive simulation
software for learning human genetics. Springer e & i Elektrotechnik
und Informationstechnik, 125, 190-196.
Holzinger, A., Kickmeierrust, M., Wassertheurer, S., & Hessinger, M. (2009).
Learning performance with interactive simulations in medical
education: Lessons learned from results of learning complex
physiological
models
with
the
HAEMOdynamics
SIMulator.
Computers & Education, 52, 292-301.
Holzinger, A., Mayr, S., Slany, W., & Debevc, M. (2010). The influence of
AJAX on Web usability. Proceedings of the 2010 International
Conference on e-Business (ICE-B) (pp. 1-4). Presented at the
Proceedings of the 2010 International Conference on e-Business
(ICE-B), IEEE.
Honekamp, W., & Ostermann, H. (2010). Anamneses-Based Internet
Information Supply: Can a Combination of an Expert System and
Meta-Search Engine Help Consumers find the Health Information
they Require? The Open Medical Informatics Journal, 4, 12–20.
Huang, C. J., Liu, M. C., Chu, S. S., & Cheng, C. L. (2007). An intelligent
learning diagnosis system for Web-based thematic learning
platform. Computers & Education, 48(4), 658–679.
202
BIBLIOGRAFÍA
Ide, N. C., Loane, R. F., & Demner-Fushman, D. (2007). Essie: A ConceptBased Search Engine for Structured Biomedical Text. Journal of the
American Medical Informatics Association, 14(3), 253–263.
Jamieson, S. (2004). Likert scales: how to (ab)use them. Medical Education,
38(12), 1217-1218.
Jiang, G., Solbrig, H. R., & Chute, C. G. (2011). ADEpedia: A Scalable and
Standardized Knowledge Base of Adverse Drug Events Using
Semantic Web Technology. AMIA Annual Symposium Proceedings,
2011, 607–616.
Jonquet, C., Musen, M. A., & Shah, N. (2008). A System for Ontology-Based
Annotation of Biomedical Data. En A. Bairoch, S. Cohen-Boulakia, &
C. Froidevaux (Eds.), Data Integration in the Life Sciences (Vol. 5109,
pp. 144–152). Berlin, Heidelberg: Springer Berlin Heidelberg.
Jonquet, C., Shah, N. H., & Musen, M. A. (2009). The Open Biomedical
Annotator. AMIA Summit on Translational Bioinformatics, 2009 (pp.
56-60). San Francisco, CA, USA.
Jonquet, C., Musen, M. A., & Shah, N. H. (2010). Building a biomedical
ontology recommender web service. Journal of Biomedical
Semantics, 1(Suppl 1), S1.
Jonquet, C., LePendu, P., Falconer, S., Coulet, A., Noy, N. F., Musen, M. A., &
Shah, N. H. (2011). NCBO Resource Index: Ontology-based search
and mining of biomedical resources. Web Semantics: Science,
Services and Agents on the World Wide Web, 9(3), 316–324.
Karimi, S., Zobel, J., & Scholer, F. (2012). Quantifying the impact of concept
recognition on biomedical information retrieval. Information
Processing & Management, 48(1), 94–106.
203
BIBLIOGRAFÍA
Karkaletsis, V., Fragkou, P., Petasis, G., & Iosif, E. (2011). Ontology Based
Information Extraction from Text. En G. Paliouras, C. D. Spyropoulos,
& G. Tsatsaronis (Eds.), Knowledge-Driven Multimedia Information
Extraction and Ontology Evolution (Vol. 6050, pp. 89–109). Berlin,
Heidelberg: Springer Berlin Heidelberg.
Kawamoto, K., Lobach, D. F., Willard, H. F., & Ginsburg, G. S. (2009). A
national clinical decision support infrastructure to enable the
widespread and consistent practice of genomic and personalized
medicine. BMC Medical Informatics and Decision Making, 9, 17.
Kienhues, D., Stadtler, M., & Bromme, R. (2011). Dealing with conflicting or
consistent medical information on the web: When expert
information breeds laypersons’ doubts about experts. Learning and
Instruction, 21(2), 193-204.
Kim, H., & Hannafin, M. J. (2011). Developing situated knowledge about
teaching with technology via Web-enhanced Case-based activity.
Computers & Education, 57(1), 1378-1388.
Krallinger, M., & Valencia, A. (2005). Text-mining and information-retrieval
services for molecular biology. Genome Biology, 6(7), 224.
Likert, R. (1932). A technique for the measurement of attitudes. Archives of
Psychology, 22(140), 1-55.
Liu, G., Lu, Z., Hao, T., & Liu, W. (2011). Automatic Short Text Annotation for
Question Answering System. En J. Filipe, J. Cordeiro, W. Aalst, J.
Mylopoulos, M. Rosemann, M. J. Shaw, & C. Szyperski (Eds.), Web
Information Systems and Technologies, Lecture Notes in Business
Information Processing (Vol. 75, pp. 245–258). Springer Berlin
Heidelberg.
204
BIBLIOGRAFÍA
Lowe, H. J., Ferris, T. A., Hernandez, P. M., & Weber, S. C. (2009). STRIDE –
An Integrated Standards-Based Translational Research Informatics
Platform. AMIA Annual Symposium Proceedings, 2009, 391–395.
Luciano, J. S., Andersson, B., Batchelor, C., Bodenreider, O., Clark, T.,
Denney, C. K., Domarew, C., et al. (2011). The Translational
Medicine Ontology and Knowledge Base: driving personalized
medicine by bridging the gap between bench and bedside. Journal
of Biomedical Semantics, 2(Suppl 2), S1.
Luo, G., & Tang, C. (2008). On iterative intelligent medical search.
Proceedings of the 31st annual international ACM SIGIR conference
on Research and development in information retrieval, SIGIR’08 (pp.
3–10). New York, NY, USA: ACM.
McCrae, J., Espinoza, M., Montiel-Ponsoda, E., Aguado-de-Cea, G., &
Cimiano, P. (2011). Combining statistical and semantic approaches
to the translation of ontologies and taxonomies. Proceedings of the
Fifth Workshop on Syntax, Semantics and Structure in Statistical
Translation,
SSST-5
(pp.
116–125).
Stroudsburg,
PA,
USA:
Association for Computational Linguistics.
McNamee, P., Mayfield, J., Lawrie, D., Oard, D., & Doermann, D. (2011).
Cross-Language Entity Linking. Proceedings of 5th International Joint
Conference on Natural Language Processing (pp. 255–263). Chiang
Mai, Thailand: Asian Federation of Natural Language Processing.
Mann, K. V. (2011). Theoretical perspectives in medical education: past
experience and future possibilities. Medical Education, 45(1), 60-68.
Matos, S., Arrais, J. P., Maia-Rodrigues, J., & Oliveira, J. (2010). Conceptbased query expansion for retrieving gene related publications from
MEDLINE. BMC Bioinformatics, 11(1), 212.
205
BIBLIOGRAFÍA
Mayfield, J., Lawrie, D., McNamee, P., & Oard, D. W. (2011). Building a
Cross-Language Entity Linking Collection in Twenty-One Languages.
En P. Forner, J. Gonzalo, J. Kekäläinen, M. Lalmas, & M. Rijke (Eds.),
Multilingual and Multimodal Information Access Evaluation (Vol.
6941, pp. 3–13). Berlin, Heidelberg: Springer Berlin Heidelberg.
Melo, G., & Siersdorfer, S. (2007). Multilingual Text Classification Using
Ontologies. En G. Amati, C. Carpineto, & G. Romano (Eds.), Advances
in Information Retrieval (Vol. 4425, pp. 541–548). Berlin, Heidelberg:
Springer Berlin Heidelberg.
Meyer, S. M., Degener, J., Giannandrea, J., & Michener, B. (2010).
Optimizing schema-last tuple-store queries in graphd. Proceedings
of the 2010 international conference on Management of data,
SIGMOD’10 (pp. 1047–1056). New York, NY, USA: ACM.
Mirhaji, P., Zhu, M., Vagnoni, M., Bernstam, E. V., Zhang, J., & Smith, J. W.
(2009). Ontology driven integration platform for clinical and
translational research. BMC Bioinformatics, 10(Suppl 2), S2.
Motik, B., Maedche, A., & Volz, R. (2002). A Conceptual Modeling Approach
for Semantics-Driven Enterprise Applications. In R. Meersman & Z.
Tari (Eds.), On the Move to Meaningful Internet Systems 2002:
CoopIS, DOA, and ODBASE (Vol. 2519, pp. 1082-1099). Berlin,
Heidelberg: Springer Berlin Heidelberg.
Muñoz, R., Aparicio, F., Buenaga, M., Gachet, D., Puertas, E., Giráldez, I., &
Gaya, M. C. (2011). Tourist Face: A Contents System Based on
Concepts of Freebase for Access to the Cultural-Tourist Information.
In R. Muñoz, A. Montoyo, & E. Métais (Eds.), Natural Language
Processing and Information Systems (Vol. 6716, pp. 300-304). Berlin,
Heidelberg: Springer Berlin Heidelberg.
206
BIBLIOGRAFÍA
Musen, M. A., Shah, N. H., Noy, N. F., Dai, B. Y., Dorf, M., Griffith, N.,
Buntrok, J., Jonquet, C., Montegut, M. J., & Rubin, D. L. (2008).
BioPortal: ontologies and data resources with the click of a mouse.
Annual Symposium Proceedings / AMIA Symposium, 1223-1224.
Noy, N. F., Shah, N. H., Whetzel, P. L., Dai, B., Dorf, M., Griffith, N., Jonquet,
C., Rubin, D. L., Storey, M. A., Chute, C. G., & Musen, M. A. (2009).
BioPortal: ontologies and integrated data resources at the click of a
mouse. Nucleic Acids Research, 37(Web Server issue), W170-173.
Pafilis, E., O’Donoghue, S. I., Jensen, L. J., Horn, H., Kuhn, M., Brown, N. P., &
Schneider, R. (2009). Reflect: augmented browsing for the life
scientist. Nature Biotechnology, 27(6), 508–510.
Plumbaum, T., Lommatzsch, A., De Luca, E., & Albayrak, S. (2012). SERUM:
Collecting
Semantic
User
Behavior
for
Improved
News
Recommendations. En L. Ardissono & T. Kuflik (Eds.), Advances in
User Modeling, Lecture Notes in Computer Science (Vol. 7138, pp.
402–405). Springer Berlin / Heidelberg.
Rebholz-Schuhmann, D., Arregui, M., Gaudan, S., Kirsch, H., & Jimeno, A.
(2008). Text processing through Web services: calling Whatizit.
Bioinformatics, 24(2), 296–298.
Reeve, L. H., & Han, H. (2007). CONANN: An Online Biomedical Concept
Annotator. En S. Cohen-Boulakia & V. Tannen (Eds.), Data
Integration in the Life Sciences (Vol. 4544, pp. 264–279). Berlin,
Heidelberg: Springer Berlin Heidelberg.
Reeve, L. H., Han, H., & Brooks, A. D. (2008). Online Biomedical Concept
Annotation Using Language Model Mapping. Bioinformatics and
Biomedicine, 2008. BIBM’08. IEEE International Conference on (pp.
453–456).
207
BIBLIOGRAFÍA
Rethlefsen, M. L. (2009). Medpedia. Journal of the Medical Library
Association : JMLA, 97(4), 325–326.
Rubin, D. L., Shah, N. H., & Noy, N. F. (2008). Biomedical Ontologies: A
Functional Perspective. Briefings in Bioinformatics, 9(1), 75–90.
Ruiz-Rico, F., Vicedo, J. L., & Rubio-Sánchez, M. C. (2008). Multilingual
assistant for medical diagnosing and drug prescription based on
category ranking. 22nd International Conference on Computational
Linguistics: Demonstration Papers, COLING’08, 169–172.
Ruttenberg, A., Clark, T., Bug, W., Samwald, M., Bodenreider, O., Chen, H.,
Doherty, D., et al. (2007). Advancing translational research with the
Semantic Web. BMC Bioinformatics, 8(Suppl 3), S2.
Ruttenberg, A., Rees, J. A., Samwald, M., & Marshall, M. S. (2009). Life
Sciences on the Semantic Web: The Neurocommons and Beyond.
Briefings in Bioinformatics, 10(2), 193–204.
Sarkar, I. 2010. Biomedical informatics and translational medicine.
Translational medicine, 8(1):22+.
Scullard, P., Peacock, C., & Davies, P. (2010). Googling Children’s Health:
Reliability of Medical Advice on the Internet. Archives of Disease in
Childhood, 95(8), 580–582.
Segev, A., & Gal, A. (2008). Enhancing portability with multilingual ontologybased knowledge management. Decision Support Systems, 45(3),
567–584.
Sellami, Z., Camps, V., Aussenac-Gilles, N., & Rougemaille, S. (2011).
Ontology Co-construction with an Adaptive Multi-Agent System:
Principles and Case-Study. En A. Fred, J. L. G. Dietz, K. Liu, & J. Filipe
(Eds.), Knowledge Discovery, Knowlege Engineering and Knowledge
208
BIBLIOGRAFÍA
Management (Vol. 128, pp. 237–248). Berlin, Heidelberg: Springer
Berlin Heidelberg.
Shah, N. H., Bhatia, N., Jonquet, C., Rubin, D., Chiang, A. P., & Musen, M. A.
(2009). Comparison of concept recognizers for building the Open
Biomedical Annotator. BMC Bioinformatics, 10(Suppl 9), S14.
Sherimon, P. C., Vinu, P. V., & Krishnan, R. (2011). Enhancing the learning
experience in blended learning systems. Proceedings of the 2011
International Conference on Communication, Computing & Security ICCCS’11 (pp. 449). Presented at the 2011 International Conference,
Rourkela, Odisha, India.
Sommerhalder, K., Abraham, A., Zufferey, M. C., Barth, J., & Abel, T. (2009).
Internet information and medical consultations: Experiences from
patients’ and physicians’ perspectives. Patient Education and
Counseling, 77(2), 266–271.
Spitkovsky, V. I., & Chang, A. X. (2011). Strong Baselines for Cross-Lingual
Entity Linking. Proceedings of the Fourth Text Analysis Conference
(TAC 2011). Gaithersburg, Maryland, USA.
Stankov, S., Rosic, M., Zitko, B., & Grubisic, A. (2008). TEx-Sys model for
building intelligent tutoring systems. Computers & Education, 51(3),
1017-1036.
Stark, R., Kopp, V., & Fischer, M. R. (2011). Case-based learning with worked
examples in complex domains: Two experimental studies in
undergraduate medical education. Learning and Instruction, 21(1),
22-33.
Suchanek, F. M., Kasneci, G., & Weikum, G. (2007). Yago: a core of semantic
knowledge. Proceedings of the 16th international conference on
209
BIBLIOGRAFÍA
World Wide Web, WWW’07 (pp. 697–706). New York, NY, USA:
ACM.
Sursock, A., & Smidt, H. (2010). Trends 2010: A decade of change in
European Higher Education. European University Association,
Available
at
http://www.ond.vlaanderen.be/hogeronderwijs/bologna/2010_con
ference/, (accessed 23 Jan 2012).
Thompson, P., Iqbal, S. A., McNaught, J., & Ananiadou, S. (2009).
Construction of an annotated corpus to support biomedical
information extraction. BMC Bioinformatics, 10, 349.
Trieschnigg, D., Pezik, P., Lee, V., De Jong, F., Kraaij, W., & RebholzSchuhmann, D. (2009). MeSH Up: Effective MeSH Text Classification
for Improved Document Retrieval. Bioinformatics, 25(11), 1412–
1418.
Trivedi, M. (2009). A study of search engines for health sciences. Library and
Information Science, 1(5), 069-073
Twigger, S., Geiger, J., & Smith, J. (2009). Using the NCBO Web Services for
Concept Recognition and Ontology Annotation of Expression
Datasets. Proceedings of the Workshop on Semantic Web
Applications and Tools for Life Sciences, SWAT4LS’09. Amsterdam,
The Netherlands.
Varde, A., Suchanek, F., Nayak, R., & Senellart, P. (2009). Knowledge
Discovery over the Deep Web, Semantic Web and XML. En X. Zhou,
H. Yokota, K. Deng, & Q. Liu (Eds.), Database Systems for Advanced
Applications, Lecture Notes in Computer Science (Vol. 5463, pp.
784–788). Springer Berlin / Heidelberg.
210
BIBLIOGRAFÍA
Wang, Y., Zhu, M., Qu, L., Spaniol, M., & Weikum, G. (2010). Timely YAGO:
harvesting, querying, and visualizing temporal knowledge from
Wikipedia. Proceedings of the 13th International Conference on
Extending Database Technology, EDBT’10 (pp. 697–700). New York,
NY, USA: ACM.
Watson, M., Smith, A., & Watter, S. (2005). Leximancer Concept Mapping of
Patient Case Studies. In R. Khosla, R. J. Howlett, & L. C. Jain (Eds.),
Knowledge-Based Intelligent Information and Engineering Systems
(Vol. 3683, pp. 1232-1238). Berlin, Heidelberg: Springer Berlin
Heidelberg.
Weichselbraun, A. (2009). A Utility Centered Approach for Evaluating and
Optimizing
Geo-tagging.
First
International
Conference
on
Knowledge Discovery and Information Retrieval (pp 134-139).
Madeira, Portugal.
Wertsch, J. V. (1985). Vygotsky and the Social Formation of Mind. Harvard
University Press.
Whetzel, P. L., Noy, N. F., Shah, N. H., Alexander, P. R., Nyulas, C.,
Tudorache, T., & Musen, M. A. (2011). BioPortal: enhanced
functionality via new Web services from the National Center for
Biomedical Ontology to access and use ontologies in software
applications. Nucleic Acids Research, 39 (Web Server), W541–W545.
Wilbur, W. J., Rzhetsky, A., & Shatkay, H. (2006). New directions in
biomedical text annotation: definitions, guidelines and corpus
construction. BMC Bioinformatics, 7, 356.
Wong, G., Greenhalgh, T., & Pawson, R. (2010). Internet-based medical
education: a realist review of what works, for whom and in what
circumstances. BMC Medical Education, 10(1), 12.
211
BIBLIOGRAFÍA
Woolf, S. H. 2008. The Meaning of Translational Research and Why It
Matters. JAMA 299(2):211-213.
Xu, H., Fu, Z., Shah, A., Chen, Y., Peterson, N. B., Chen, Q., Mani, S., et al.
(2011). Extracting and Integrating Data from Entire Electronic Health
Records for Detecting Colorectal Cancer Cases. AMIA Annual
Symposium Proceedings, 2011, 1564–1572.
Zou, Q., Chu, W. W., Morioka, C., Leazer, G. H., & Kangarloo, H. (2003).
IndexFinder: A Method of Extracting Key Concepts from Clinical
Texts for Indexing. AMIA Annual Symposium Proceedings, 2003,
763–767.
212
APÉNDICES
APÉNDICE 1 RESULTADOS DEL SERVICIO WEB UTILIZANDO DIFERENTES FUENTES.
Tabla 23. Resumen de la respuesta del servicio XML al procesar el texto "this patient has asthma and presents symptoms of CRPS" con las
fuentes locales.
lang
source
en
Freebase
ASTHMA
17
23 ASTHMA true
en
Freebase
ASTHMA
17
23 ASTHMA true
en
MedlinePlus
ASTHMA
17
23 ASTHMA true
en
MedlinePlus
concept from to preferred direct
CRPS
49
53
CRPS
true
localurl
urlen
disease.jsp?term=ASTHM http://www.freebase.com/vie
A
urlsp
Disease
w/en/asthma
symptom.jsp?term=ASTH http://www.freebase.com/vie
MA
THMA
medlineplus.jsp?term=CR
PS
Symptom
w/en/asthma
medlineplus.jsp?term=AS http://www.nlm.nih.gov/med
lineplus/asthma.html
groups
http://www.nlm.nih.gov/m
Lungs and
edlineplus/spanish/asthma.
Breathing |
html
Immune System
http://www.nlm.nih.gov/med http://www.nlm.nih.gov/m
lineplus/complexregionalpain edlineplus/spanish/complex Brain and Nerves
syndrome.html
regionalpainsyndrome.html
http://apps.nlm.nih.gov/medl http://apps.nlm.nih.gov/me
ineplus/services/mpconnect.c dlineplus/services/mpconn
en
SnomedCore
ASTHMA
17
23 ASTHMA true
snomed.jsp?term=ASTH
MA
fm?mainSearchCriteria.v.cs=2 ect.cfm?mainSearchCriteria
.16.840.1.113883.6.96&mainS .v.cs=2.16.840.1.113883.6.9
earchCriteria.v.c=195967001 6&mainSearchCriteria.v.c=1
&informationRecipient.langua 95967001&informationReci
geCode.c=en
213
pient.languageCode.c=sp
disorder
APÉNDICES
Tabla 24. Resumen de la respuesta del servicio XML al procesar el texto "this patient has asthma and presents symptoms of CRPS" con la fuente
remota MedlinePlus y el nivel de profundidad 0.
lang
source
OBA
en
Medlineplus
concept from
to
preferred
direct
localurl
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
37
45
SYMPTOMS
true
medlineplus.jsp?term=SYMPTOMS
49
53
urlen
http://purl.bioontology.org/ontology/M NCBO BioPortal
EDLINEPLUS/T2
(40397)
OBA
en
Medlineplus
(40397)
SYMPTOM
S
OBA
en
Medlineplus
COMPLEX
CRPS
(40397)
REGIONAL PAIN true
medlineplus.jsp?term=COMPLEX
concept
http://purl.bioontology.org/ontology/M NCBO BioPortal
EDLINEPLUS/31
concept
http://purl.bioontology.org/ontology/M NCBO BioPortal
REGIONAL PAIN SYNDROME
SYNDROME
groups
EDLINEPLUS/T382
concept
Tabla 25. Resumen de la respuesta del servicio XML al procesar el texto "this patient has asthma and presents symptoms of CRPS" con la fuente
remota MedlinePlus y el nivel de profundidad 1.
lang
source
concept from to
OBA
en Medlineplus ASTHMA
17 23
(40397)
OBA
en Medlineplus SYMPTOMS 37 45
(40397)
OBA
en
CRPS
49 53
Medlineplus
214
preferred
direct
localurl
ASTHMA
true
medlineplus.jsp?term=ASTHMA
SYMPTOMS
BRAIN AND NERVES
true medlineplus.jsp?term=SYMPTOMS
false
urlen
groups
http://purl.bioontology.org/ontolog NCBO BioPortal
y/MEDLINEPLUS/T2
concept
http://purl.bioontology.org/ontolog NCBO BioPortal
y/MEDLINEPLUS/31
concept
medlineplus.jsp?term=BRAIN AND http://purl.bioontology.org/ontolog NCBO BioPortal
NERVES
y/MEDLINEPLUS/14
concept
APÉNDICES
(40397)
OBA
en Medlineplus SYMPTOMS
(40397)
OBA
en Medlineplus
CRPS
(40397)
OBA
en Medlineplus ASTHMA
(40397)
OBA
en Medlineplus ASTHMA
(40397)
OBA
en Medlineplus
CRPS
(40397)
MEDLINEPLUS HEALTH
medlineplus.jsp?term=MEDLINEPL http://purl.bioontology.org/ontolog NCBO BioPortal
false
TOPICS
US HEALTH TOPICS
y/MEDLINEPLUS/MTHU000001
concept
37
45
49
53 NEUROLOGIC DISEASES false
17
23
IMMUNE SYSTEM
false
17
23
LUNGS AND
BREATHING
false
49
53
COMPLEX REGIONAL
PAIN SYNDROME
true
medlineplus.jsp?term=NEUROLOG http://purl.bioontology.org/ontolog NCBO BioPortal
IC DISEASES
y/MEDLINEPLUS/T341
concept
medlineplus.jsp?term=IMMUNE http://purl.bioontology.org/ontolog NCBO BioPortal
SYSTEM
y/MEDLINEPLUS/22
concept
medlineplus.jsp?term=LUNGS
AND BREATHING
http://purl.bioontology.org/ontolog NCBO BioPortal
y/MEDLINEPLUS/15
concept
medlineplus.jsp?term=COMPLEX http://purl.bioontology.org/ontolog NCBO BioPortal
REGIONAL PAIN SYNDROME
y/MEDLINEPLUS/T382
concept
Tabla 26. Resumen de la respuesta del servicio XML al procesar el texto "this patient has asthma and presents symptoms of CRPS" con todas las
fuentes remotas y el nivel de profundidad 1.
source
concept
from to
preferred
direct
localurl
groups
OBA (46462)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (46317)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (40393)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (46442)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA (44302)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (42297)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (46302)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
215
APÉNDICES
OBA (44302)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (45824)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (42295)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (40390) SYMPTOMS
37
45
SYMPTOMS
true
medlineplus.jsp?term=SYMPTOMS
Sign or Symptom
OBA (44686)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA (46432)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA Snomed
(46116)
OBA Snomed
(46116)
216
OBA (45776)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA (44776)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (44774)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (44774)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
Patient or Disabled
Group
OBA (46453)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (46355)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (45766)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA Snomed
(46116)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
Patient or Disabled
Group
OBA (46442)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA (46449)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA Snomed
(46116)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (45221)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
APÉNDICES
OBA (46442)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA (42835)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA (45553)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (44432)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (4525)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (44774) SYMPTOMS
37
45
SYMPTOMS
true
medlineplus.jsp?term=SYMPTOMS
Sign or Symptom
OBA (46316)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (40404)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (42280)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (40390)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA (39343) SYMPTOMS
37
45
SYMPTOMS
true
medlineplus.jsp?term=SYMPTOMS
Finding
OBA (45298)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
Sign or Symptom
OBA (44103)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (44774) SYMPTOMS
37
45
SYMPTOMS
true
medlineplus.jsp?term=SYMPTOMS
NCBO BioPortal concept
OBA (40402)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Disease or Syndrome
OBA Snomed
(46116)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
Sign or Symptom
OBA (38631)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (39734)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
Disease or Syndrome
OBA (46317)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA (45221) SYMPTOMS
37
45
SYMPTOMS
true
medlineplus.jsp?term=SYMPTOMS
NCBO BioPortal concept
OBA
Medlineplus
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
ASTHMA
217
APÉNDICES
(40397)
218
OBA (44774)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
Sign or Symptom
OBA (44774)
ASTHMA
17
23
ASTHMA
true
medlineplus.jsp?term=ASTHMA
NCBO BioPortal concept
OBA (46054)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
Patient or Disabled
Group
OBA (39343)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
Disease or Syndrome
OBA (4525)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA
Medlineplus SYMPTOMS
(40397)
37
45
SYMPTOMS
true
medlineplus.jsp?term=SYMPTOMS
NCBO BioPortal concept
OBA (46442)
PATIENT
5
12
PATIENT
true
medlineplus.jsp?term=PATIENT
NCBO BioPortal concept
OBA
Medlineplus
(40397)
ASTHMA
17
23
LUNGS AND BREATHING
false
medlineplus.jsp?term=LUNGS AND BREATHING
NCBO BioPortal concept
OBA (46462)
ASTHMA
17
23
ABNORMALITY OF THE LUNG
false
medlineplus.jsp?term=ABNORMALITY OF THE LUNG NCBO BioPortal concept
OBA (45824)
ASTHMA
17
23
OBSTRUCTIVE LUNG DISEASE
false
medlineplus.jsp?term=OBSTRUCTIVE LUNG DISEASE NCBO BioPortal concept
OBA (45553)
ASTHMA
17
23
IMMUNOLOGY
false
medlineplus.jsp?term=IMMUNOLOGY
NCBO BioPortal concept
OBA (45298)
PATIENT
5
12
ENTITY_CONCEPTS
false
medlineplus.jsp?term=ENTITY_CONCEPTS
NCBO BioPortal concept
OBA (45553)
ASTHMA
17
23
RESPIRATORY
false
medlineplus.jsp?term=RESPIRATORY
Biomedical Occupation
or Discipline
OBA (46449)
PATIENT
5
12
PERSON
false
medlineplus.jsp?term=PERSON
NCBO BioPortal concept
OBA (46442)
PATIENT
5
12
ROLECODE
false
medlineplus.jsp?term=ROLECODE
Functional Concept
OBA (45766)
PATIENT
5
12
INDIVIDUAL
false
medlineplus.jsp?term=INDIVIDUAL
NCBO BioPortal concept
OBA
Medlineplus
(40397)
CRPS
49
53
NEUROLOGIC DISEASES
false
medlineplus.jsp?term=NEUROLOGIC DISEASES
NCBO BioPortal concept
APÉNDICES
OBA (42295)
ASTHMA
17
23
RESPIRATORY DISORDER
false
medlineplus.jsp?term=RESPIRATORY DISORDER
NCBO BioPortal concept
OBA (46453)
ASTHMA
17
23
BRONCHIAL DISEASE
false
medlineplus.jsp?term=BRONCHIAL DISEASE
NCBO BioPortal concept
OBA (4525)
ASTHMA
17
23
NAMEDSYSTEMICDISEASE
false
medlineplus.jsp?term=NAMEDSYSTEMICDISEASE
Disease or Syndrome
OBA (45776)
PATIENT
5
12
PERSON
false
medlineplus.jsp?term=PERSON
NCBO BioPortal concept
NCBO BioPortal concept
OBA (40402)
ASTHMA
17
23
RESPIRATORY HYPERSENSITIVITY
false
medlineplus.jsp?term=RESPIRATORY
HYPERSENSITIVITY
OBA (45553)
ASTHMA
17
23
LUNG
false
medlineplus.jsp?term=LUNG
NCBO BioPortal concept
OBA (45553)
ASTHMA
17
23
AIRWAYS
false
medlineplus.jsp?term=AIRWAYS
NCBO BioPortal concept
OBA (40404)
ASTHMA
17
23
THYROID ADENOMA
false
medlineplus.jsp?term=THYROID ADENOMA
OBA (46089)
PATIENT
5
12
ROLE
false
medlineplus.jsp?term=ROLE
OBA
Medlineplus SYMPTOMS
(40397)
37
45
MEDLINEPLUS HEALTH TOPICS
false medlineplus.jsp?term=MEDLINEPLUS HEALTH TOPICS NCBO BioPortal concept
OBA (46302)
ASTHMA
17
23
CHRONIC LOWER RESPIRATORY
DISEASES (J40-J47)
false
OBA (40402)
ASTHMA
17
23
LUNG DISEASES, OBSTRUCTIVE
false medlineplus.jsp?term=LUNG DISEASES, OBSTRUCTIVE NCBO BioPortal concept
OBA (46355)
ASTHMA
17
23
RESPIRATORY DISORDER
false
medlineplus.jsp?term=RESPIRATORY DISORDER
Disease or Syndrome
OBA (46054)
PATIENT
5
12
HUMAN / PERSON
false
medlineplus.jsp?term=HUMAN / PERSON
NCBO BioPortal concept
OBA (38631)
ASTHMA
17
23
DIAGNOSIS
false
medlineplus.jsp?term=DIAGNOSIS
NCBO BioPortal concept
OBA (46432)
ASTHMA
17
23
LUNG DISEASE
false
medlineplus.jsp?term=LUNG DISEASE
NCBO BioPortal concept
OBA (44432)
ASTHMA
17
23
OBA (45221)
ASTHMA
17
23
OBA (44302)
ASTHMA
17
23
RESPIRATORY HYPERSENSITIVITY
false
CHRONIC OBSTRUCTIVE PULMONARY
false
DISEASE AND ALLIED CONDITIONS
DISEASE STATE
false
Body Part, Organ, or
Organ Component
Body Part, Organ, or
Organ Component
medlineplus.jsp?term=CHRONIC LOWER RESPIRATORY
NCBO BioPortal concept
DISEASES (J40-J47)
medlineplus.jsp?term=RESPIRATORY
HYPERSENSITIVITY
medlineplus.jsp?term=CHRONIC OBSTRUCTIVE
PULMONARY DISEASE AND ALLIED CONDITIONS
medlineplus.jsp?term=DISEASE STATE
219
NCBO BioPortal concept
NCBO BioPortal concept
Pathologic Function
APÉNDICES
OBA (46442)
PATIENT
5
12
SPECIMENROLETYPE
false
OBA (40390)
ASTHMA
17
23
ALLERGIC/HYPERSENSITIVITY
false
OBA (40390)
ASTHMA
17
23
BRONCHUS AND BRONCHIOLE
false medlineplus.jsp?term=BRONCHUS AND BRONCHIOLE NCBO BioPortal concept
OBA (46316)
ASTHMA
17
23
ABNORMALITY OF THE LUNG
false
37
45
NONSPECIFIC DISORDERS
false
OBA (39343) SYMPTOMS
37
SYMPTOMS, SIGNS, AND ILL-DEFINED
45
false
CONDITIONS
OBA (44432)
ASTHMA
17
23
OBA (40402)
ASTHMA
17
OBA (44302)
ASTHMA
17
OBA (44686)
PATIENT
OBA (39343)
PATIENT
OBA (40390) SYMPTOMS
220
ATOPY
false
23
BRONCHIAL DISEASES
23
INFLAMMATORY DISORDERS
5
12
5
medlineplus.jsp?term=SPECIMENROLETYPE
Disease or Syndrome
medlineplus.jsp?term=ALLERGIC/HYPERSENSITIVITY NCBO BioPortal concept
medlineplus.jsp?term=ABNORMALITY OF THE LUNG
Pathologic Function
medlineplus.jsp?term=NONSPECIFIC DISORDERS
Disease or Syndrome
medlineplus.jsp?term=SYMPTOMS, SIGNS, AND ILLNCBO BioPortal concept
DEFINED CONDITIONS
medlineplus.jsp?term=ATOPY
Disease or Syndrome
false
medlineplus.jsp?term=BRONCHIAL DISEASES
NCBO BioPortal concept
false
medlineplus.jsp?term=INFLAMMATORY DISORDERS
Pathologic Function
ROLE
false
medlineplus.jsp?term=ROLE
NCBO BioPortal concept
12
PERSON
false
medlineplus.jsp?term=PERSON
NCBO BioPortal concept
OBA (44103)
ASTHMA
17
23
CHRONIC LOWER RESPIRATORY
DISEASES
medlineplus.jsp?term=CHRONIC LOWER RESPIRATORY
false
NCBO BioPortal concept
DISEASES
OBA (45138)
PATIENT
5
12
PHARE:HOMOSAPIENS
OBA (45221) SYMPTOMS
37
SYMPTOMS, SIGNS, AND ILL-DEFINED
45
false
CONDITIONS
OBA
Medlineplus
(40397)
CRPS
49
53
BRAIN AND NERVES
OBA (46442)
PATIENT
5
12
OBA (42280)
ASTHMA
17
OBA (4525)
PATIENT
OBA Snomed
(46116)
ASTHMA
false
medlineplus.jsp?term=PHARE:HOMOSAPIENS
NCBO BioPortal concept
medlineplus.jsp?term=SYMPTOMS, SIGNS, AND ILLDEFINED CONDITIONS
Disease or Syndrome
false
medlineplus.jsp?term=BRAIN AND NERVES
NCBO BioPortal concept
ROLECLASSRELATIONSHIPFORMAL
false
medlineplus.jsp?term=ROLECLASSRELATIONSHIPFORM
AL
Sign or Symptom
23
ALLERGIC CONDITIONS NEC
false
medlineplus.jsp?term=ALLERGIC CONDITIONS NEC
NCBO BioPortal concept
5
12
HUMAN
false
medlineplus.jsp?term=HUMAN
NCBO BioPortal concept
17
23 DISORDER OF RESPIRATORY SYSTEM false
medlineplus.jsp?term=DISORDER OF RESPIRATORY
SYSTEM
Disease or Syndrome
APÉNDICES
medlineplus.jsp?term=BRONCHOSPASM AND
OBSTRUCTION
NCBO BioPortal concept
false
medlineplus.jsp?term=AIRWAYS DISEASE
Disease or Syndrome
DIAGNOSIS/DISEASES COMPONENT
false
medlineplus.jsp?term=DIAGNOSIS/DISEASES
COMPONENT
Disease or Syndrome
HUMAN / PERSON
false
medlineplus.jsp?term=HUMAN / PERSON
Disease or Syndrome
NCBO BioPortal concept
OBA (42280)
ASTHMA
17
23 BRONCHOSPASM AND OBSTRUCTION false
OBA (40390)
ASTHMA
17
23
AIRWAYS DISEASE
OBA (40393)
ASTHMA
17
23
OBA (39734)
PATIENT
5
12
OBA (46316)
ASTHMA
17
23
IMMUNOLOGIC HYPERSENSITIVITY
false
medlineplus.jsp?term=IMMUNOLOGIC
HYPERSENSITIVITY
OBA (46317)
ASTHMA
17
23
DISEASE PATHWAY
false
medlineplus.jsp?term=DISEASE PATHWAY
NCBO BioPortal concept
OBA (40393)
ASTHMA
17
23
RESPIRATORY
false
medlineplus.jsp?term=RESPIRATORY
NCBO BioPortal concept
OBA (45824)
ASTHMA
17
23
BRONCHIAL DISEASE
false
medlineplus.jsp?term=BRONCHIAL DISEASE
NCBO BioPortal concept
OBA (46442)
PATIENT
5
12
SPECIMENENTITYTYPE
false
medlineplus.jsp?term=SPECIMENENTITYTYPE
NCBO BioPortal concept
ASTHMA
17
23
IMMUNE SYSTEM
false
medlineplus.jsp?term=IMMUNE SYSTEM
NCBO BioPortal concept
PATIENT
5
12
PERSON IN THE HEALTHCARE
ENVIRONMENT
false
OBA (46462)
ASTHMA
17
23
IMMUNOLOGIC HYPERSENSITIVITY
false
OBA
Medlineplus
(40397)
OBA Snomed
(46116)
medlineplus.jsp?term=PERSON IN THE HEALTHCARE
NCBO BioPortal concept
ENVIRONMENT
medlineplus.jsp?term=IMMUNOLOGIC
Population Group
HYPERSENSITIVITY
OBA (46453)
ASTHMA
17
23
OBSTRUCTIVE LUNG DISEASE
false
medlineplus.jsp?term=OBSTRUCTIVE LUNG DISEASE
Functional Concept
OBA Snomed
(46116)
ASTHMA
17
23
ASTHMATIC BRONCHITIS
true
medlineplus.jsp?term=ASTHMATIC BRONCHITIS
NCBO BioPortal concept
OBA (46317)
PATIENT
5
12
VETERINARY PATIENT
true
medlineplus.jsp?term=VETERINARY PATIENT
NCBO BioPortal concept
OBA (44776) SYMPTOMS
37
45
DIAGNOSIS
true
medlineplus.jsp?term=DIAGNOSIS
Disease or Syndrome
OBA (45138)
PATIENT
5
12
PHARE:PATIENT
true
medlineplus.jsp?term=PHARE:PATIENT
NCBO BioPortal concept
OBA (44776)
PATIENT
5
12
PATIENTS
true
medlineplus.jsp?term=PATIENTS
Qualitative Concept
OBA (46089)
PATIENT
5
12
PATIENT ROLE
true
medlineplus.jsp?term=PATIENT ROLE
Functional Concept
221
APÉNDICES
222
OBA
Medlineplus
(40397)
CRPS
49
53 COMPLEX REGIONAL PAIN SYNDROME true
OBA (46317)
ASTHMA
17
23
ASTHMA PATHWAY
true
medlineplus.jsp?term=COMPLEX REGIONAL PAIN
SYNDROME
NCBO BioPortal concept
medlineplus.jsp?term=ASTHMA PATHWAY
Patient or Disabled
Group
APÉNDICES
APÉNDICE 2 PRUEBAS DE EFICIENCIA.
Tabla 27. Resultados de todas las pruebas para cada uno de los 12 casos clínicos del UPMC.
PRUEBA
P1
P2
P3
P4
P5
P6
P7
715
716
28
23
23
27
24
22
42
28
28
2127
2191
2423
2163
2188
2090
2114
2121
2142
8170
8308
8202
23
23
23
24
30
24
38
28
28
3924
5771
7521
6279
5619
6144
6037
5584
5262
8252
8302
8193
RESULTADOS (ms) PARA CADA UNO DE LOS CASOS CLÍNICOS
717
718
719
720
721
722
723
724
22
21
22
22
22
22
25
27
25
3037
3119
3638
3125
3068
3018
3539
3018
3225
8295
8206
8231
20
20
19
20
20
19
23
28
21
1945
1961
2053
2014
1900
1917
1997
1935
2116
8188
8255
8201
21
20
21
19
20
23
22
22
26
2850
3119
2810
3641
3803
3650
2839
2879
3096
8208
8280
8245
18
19
19
19
21
19
21
22
21
2965
3187
2657
2616
2605
2615
2621
3081
2523
8317
8306
8178
20
23
20
21
19
20
25
23
24
3542
3390
4171
4424
3497
3503
3754
3810
3406
8196
8235
8351
19
20
20
19
20
19
22
22
23
2137
2341
2054
2131
2237
2187
2580
2523
2156
8192
8263
8311
19
20
21
19
19
22
22
21
24
2625
3155
2738
3223
2640
2738
2952
2814
2810
8210
8195
8256
223
19
19
20
20
21
20
23
26
23
3313
3891
3502
3380
3827
3504
4311
3487
4981
8197
8424
8269
725
726
19
19
19
20
19
20
22
21
21
2198
2151
2261
2104
2427
2133
2253
2139
2096
8223
8206
8254
19
20
20
25
21
21
24
23
23
4218
5183
6269
6271
4183
6803
5911
4023
3909
8231
8243
8248
APÉNDICES
P8
P9
P10
P11
P12
P13
P14
P15
P16
224
8262
8358
8254
8246
8210
8213
9849
10946
16037
10209
12558
9616
10196
8629
10254
8207
8346
8248
8182
8191
8188
8173
8196
8156
12290
14450
11623
8275
8224
8155
8175
8222
8121
30204
27982
27902
25295
27128
27078
24843
24729
32354
8131
8228
8213
8217
8201
8208
8237
8211
8240
24609
28398
23890
8243
8187
8207
8183
8140
8161
17930
20509
19984
16611
19636
22794
17748
19705
20805
8167
8234
8164
8189
8276
8199
8188
8196
8192
16644
19022
21147
8248
8164
8193
8189
8172
8179
17500
10150
7439
9334
8344
12479
7854
10537
8615
8207
8183
8214
8220
8168
8275
8239
8182
8163
9178
9472
11346
8237
8403
8265
8212
8271
8193
18954
21460
17404
16978
18243
17750
18643
16859
19664
8241
8236
8229
8191
8276
8227
8180
8204
8228
22325
19072
21415
8193
8213
8209
8188
8250
8144
11186
14408
10758
13005
15199
13875
12526
14734
11739
8175
8195
8240
8175
8109
8290
8154
8174
8268
15104
18538
12875
8172
8132
8352
9136
8197
8208
26565
26906
22163
22531
27417
20339
29979
22300
24713
8219
8294
8265
8248
8213
8223
8192
8213
8217
24691
26268
19153
8128
8234
8192
8181
8239
8244
9213
14901
16481
10658
10698
11289
10512
10519
12535
8143
8191
8180
8129
8157
8211
8231
8232
8189
19124
15235
9906
8169
8171
8329
8189
8176
8176
10455
14853
19793
12128
15516
55627
10711
12742
87531
8165
8216
8193
8209
8172
8199
8158
8164
8196
12289
11302
13001
8235
8258
8239
8208
8216
8191
20382
22187
22786
21409
22927
17486
19522
17555
17712
8199
8244
8219
8293
8228
8265
8230
8121
8221
23303
45334
21393
8274
8172
8203
8224
8166
8174
11568
11310
10265
9483
9036
9968
9063
9751
10199
8168
8203
8203
8198
8231
8202
8143
8190
8158
12913
7635
10852
8230
8248
8251
8203
8142
8232
29876
24201
32885
23625
27090
33704
34769
22690
30644
8193
8219
8230
8231
8260
8182
8192
8189
8170
29927
24524
26360
APÉNDICES
P17
P18
P19
P20
P21
P22
P23
P24
P25
8829
11136
11358
14177
10256
11019
38
36
37
36
38
37
42
40
38
26904
26651
27232
26856
26923
26750
27372
26684
26484
27374
27633
27493
22795
21961
27113
24282
27279
21486
38
39
37
41
40
38
45
42
43
27340
27243
27331
27048
27310
26893
27334
26855
28217
27446
27463
27315
15525
19934
17224
22155
17935
19743
37
37
38
38
37
37
42
41
42
27715
28400
27594
29076
27576
27424
28085
27691
27937
26945
27577
27051
9391
8815
7750
8484
8079
13917
38
35
37
39
38
36
40
39
38
27741
28396
27343
28607
27409
27607
27514
27397
27586
26718
27543
27376
17242
19905
23331
18701
21255
15968
37
36
37
37
36
37
41
39
40
27078
28857
27821
27395
27199
27355
28332
27217
27984
26797
26891
27497
12654
12815
13738
14752
14122
11620
39
37
35
38
37
35
41
39
38
27820
28071
27731
27175
27604
27228
27930
27258
28046
27537
28090
27611
25497
25676
26626
20064
23634
22251
41
36
38
51
39
36
40
39
40
27058
27716
27127
27099
27255
27577
26865
26912
27169
26689
27392
26941
11271
11445
11913
8421
8500
10263
39
36
35
38
37
37
38
38
38
26758
27785
27714
27503
27430
27538
26886
27643
26965
27029
27659
27522
11837
11901
8833
10516
10936
9955
38
36
36
37
38
35
40
39
38
27312
27320
27526
27437
27437
28054
27041
26921
27395
26809
26995
27300
225
21053
20472
20066
22518
24582
24736
38
36
36
37
39
37
39
39
39
27707
27933
28135
28535
27735
27652
30336
27410
27885
27637
27451
27452
8265
11287
10298
13721
11121
9777
37
37
36
38
36
37
41
38
39
27091
27973
27217
27569
27460
26914
27385
27553
27441
26895
27806
26864
29432
29833
27548
36519
23401
31466
37
37
37
38
38
38
41
40
44
27184
28200
27768
28001
26847
27915
27277
27708
27281
28017
28431
28671
APÉNDICES
P26
P27
27323
27163
26858
27292
26796
26942
26862
27395
27424
27343
26955
27530
26908
26782
27183
26857
26821
27339
27385
26872
27377
27025
27544
27136
26804
27140
26807
26960
26858
26725
27771
27450
27298
28587
27267
27788
26856
27050
27208
27106
26774
27054
27438
26960
27430
26888
27328
26795
27104
26774
27054
26880
27054
27022
26914
27502
26826
27654
26841
27681
26836
26886
27346
26858
27014
28215
27806
27691
27838
27630
27933
27850
Tabla 28. Valores medios y desviaciones estándar obtenidos para cada uno de los 12 casos clínicos del UPMC.
PRUEBA
715
VALOR MEDIO (ms) Y DESVIACIÓN ESTÁNDAR PARA CADA UNO DE LOS CASOS CLÍNICOS
716
717
718
719
720
721
722
723
724
725
726
23,00
0,00
21,67
0,58
19,67
0,58
20,67
0,58
18,67
0,58
21,00
1,73
19,67
0,58
20,00
1,00
19,33
0,58
19,00
0,00
19,67
0,58
26,00
3,46
22,00
0,00
19,67
0,58
20,67
2,08
19,67
1,15
20,00
1,00
19,33
0,58
20,00
1,73
20,33
0,58
19,67
0,58
22,33
2,31
31,33
5,77
25,67
1,15
24,00
3,61
23,33
2,31
21,33
0,58
24,00
1,00
22,33
0,58
22,33
1,53
24,00
1,73
21,33
0,58
23,33
0,58
5.738,67
1.798,72
3.264,67
325,91
1.986,33
58,29
2.926,33
168,05
2.936,33
266,16
3.701,00
414,07
2.177,33
147,69
2.839,33
279,15
3.568,67
294,71
2.203,33
55,19
5.223,33
1.026,09
6.014,00
348,68
3.070,33
53,54
1.943,67
61,50
3.698,00
91,04
2.612,00
6,08
3.808,00
533,48
2.185,00
53,03
2.867,00
312,17
3.570,33
230,76
2.221,33
178,70
5.752,33
1.384,87
5.627,67
389,34
3.260,67
262,32
2.016,00
91,98
2.938,00
138,29
2.741,67
297,93
3.656,67
218,88
2.419,67
230,11
2.858,67
80,85
4.259,67
748,32
2.162,67
81,13
4.614,33
1.124,39
P1
Media 24,67
2,89
Desv. Est.
P2
Media 24,33
2,52
Desv. Est.
P3
Media 32,67
8,08
Desv. Est.
P4
Media 2.247,00
Desv. Est. 155,74
P5
Media 2.147,00
Desv. Est. 50,92
P6
Media 2.125,67
Desv. Est. 14,57
226
APÉNDICES
P7
Media
Desv. Est.
P8
Media
Desv. Est.
P9
Media
Desv. Est.
P10
Media
Desv. Est.
P11
Media
Desv. Est.
P12
Media
Desv. Est.
P13
Media
Desv. Est.
P14
Media
Desv. Est.
P15
Media
Desv. Est.
P16
Media
Desv. Est.
8.226,67
72,23
8.249,00
54,56
8.244,00
45,90
8.214,67
35,53
8.244,33
36,00
8.267,00
77,27
8.260,67
80,62
8.255,33
59,87
8.220,33
31,79
8.296,67
116,00
8.227,67
24,34
8.240,67
8,74
8.291,33
57,87
8.218,00
60,22
8.212,33
28,38
8.201,67
42,67
8.301,67
88,87
8.205,00
10,58
8.218,67
117,19
8.184,67
53,38
8.223,00
91,80
8.244,00
12,29
8.216,33
52,29
8.243,00
11,36
8.223,00
19,97
8.172,67
50,54
8.161,33
21,50
8.180,00
8,54
8.225,33
40,67
8.194,00
53,25
8.513,67
538,98
8.221,33
35,02
8.180,33
7,51
8.205,00
12,77
8.188,00
31,43
8.192,33
45,94
12.277,33 28.696,00 19.474,33 11.696,33 19.272,67 12.117,33 25.211,33 13.531,67 15.033,67 21.785,00 11.047,67 28.987,33
3.301,84 1.306,58 1.362,95 5.205,70 2.046,69 1.995,28 2.645,43 3.822,60 4.671,62 1.251,40
689,98
4.409,68
10.794,33 26.500,33 19.680,33 10.052,33 17.657,00 14.026,33 23.429,00 10.881,67 27.757,00 20.607,33
1.555,89 1.044,15 3.091,74 2.159,06
637,61
1.104,80 3.623,44
353,33
24.195,50 2.807,69
9.495,67
466,13
28.139,67
5.120,83
9.693,00
921,91
27.308,67 19.419,33
4.369,76 1.548,39
9.002,00
1.382,73
18.388,67 12.999,67 25.664,00 11.188,67 36.994,67 18.263,00
1.419,69 1.552,67 3.926,84 1.165,96 43.777,53 1.093,15
9.671,00
572,21
29.367,67
6.139,82
8.267,00
71,42
8.190,67
52,21
8.188,33
39,58
8.201,33
16,26
8.235,33
6,03
8.203,33
33,29
8.259,33
37,82
8.171,33
25,15
8.191,33
25,54
8.220,67
22,55
8.191,33
20,21
8.214,00
19,00
8.187,00
4,58
8.208,67
8,02
8.221,33
47,61
8.221,00
53,51
8.231,33
42,67
8.191,33
91,60
8.228,00
18,03
8.165,67
41,68
8.193,33
19,14
8.262,00
32,60
8.210,33
18,01
8.224,33
39,43
8.175,00
20,07
8.229,33
15,95
8.192,00
4,00
8.194,67
39,55
8.204,00
24,00
8.198,67
60,87
8.207,33
13,43
8.217,33
24,54
8.172,67
20,43
8.190,67
60,50
8.163,67
24,01
8.183,67
11,93
12.787,67 25.632,33 18.937,67
1.477,75 2.421,97 2.252,68
9.998,67
1.176,05
20.937,33 15.505,67 23.370,67 14.755,00 12.197,33 30.010,00 10.466,67 26.937,00
1.678,28 2.852,79 3.736,75 4.627,71
853,20
13.305,29 2.660,02 2.747,33
227
APÉNDICES
P17
Media
Desv. Est.
P18
Media
Desv. Est.
P19
Media
Desv. Est.
P20
Media
Desv. Est.
P21
Media
Desv. Est.
P22
Media
Desv. Est.
P23
Media
Desv. Est.
P24
Media
Desv. Est.
P25
Media
Desv. Est.
P26
Media
Desv. Est.
228
10.441,00 23.956,33 17.561,00
1.400,44 2.765,37 2.223,73
8.652,00
832,55
20.159,33 13.069,00 25.933,00 11.543,00 10.857,00 20.530,33
3.052,46
584,94
606,79
332,03
1.753,13
496,08
11.817,33 24.349,00 19.944,33 10.160,00 18.641,33 13.498,00 21.983,00
2.078,84 2.897,08 2.117,19 3.259,95 2.644,00 1.656,62 1.800,03
9.061,33
1.041,42
9.950,00
1.540,76
28.937,67
1.220,07
10.469,00 23.945,33 11.539,67 30.462,00
492,19
1.238,50 2.005,05 6.616,38
37,00
1,00
38,00
1,00
37,33
0,58
36,67
1,53
36,67
0,58
37,00
2,00
38,33
2,52
36,67
2,08
36,67
1,15
36,67
1,15
36,67
0,58
37,00
0,00
37,00
1,00
39,67
1,53
37,33
0,58
37,67
1,53
36,67
0,58
36,67
1,53
42,00
7,94
37,33
0,58
36,67
1,53
37,67
1,15
37,00
1,00
38,00
0,00
40,00
2,00
43,33
1,53
41,67
0,58
39,00
1,00
40,00
1,00
39,33
1,53
39,67
0,58
38,00
0,00
39,00
1,00
39,00
0,00
39,33
1,53
41,67
2,08
26.929,00 27.304,67 27.903,00 27.826,67 27.918,67 27.874,00 27.300,33 27.419,00 27.386,00 27.925,00 27.427,00 27.717,33
291,31
53,59
434,65
531,70
893,51
176,32
361,63
573,54
121,31
214,11
477,03
509,89
26.843,00 27.083,67 28.025,33 27.874,33 27.316,33 27.335,67 27.310,33 27.490,33 27.642,67 27.974,00 27.314,33 27.587,67
87,23
210,78
913,07
642,18
103,56
233,89
243,76
55,10
356,23
487,61
350,96
642,88
26.846,67 27.468,67 27.904,33 27.499,00 27.844,33 27.744,67 26.982,00 27.164,67 27.119,00 28.543,67 27.459,67 27.422,00
465,81
690,91
199,02
95,39
570,47
425,44
163,64
416,13
246,44
1.570,27
85,54
247,69
27.500,00 27.408,00 27.191,00 27.212,33 27.061,67 27.746,00 27.007,33 27.403,33 27.034,67 27.513,33 27.188,33 28.373,00
129,64
80,99
338,46
436,17
379,93
300,20
356,16
331,34
247,89
107,10
535,14
330,84
27.114,67 27.227,00 26.957,67 27.211,33 26.917,00 27.506,33 27.038,00 27.276,00 26.977,33 27.080,67 27.022,67 27.778,33
236,24
316,43
205,06
293,90
193,13
241,48
176,31
273,69
177,86
367,53
281,13
77,31
APÉNDICES
P27
Media 27.010,00 27.276,00 27.005,67 27.235,00 26.847,67 27.880,67 26.978,00 27.003,67 26.985,33 27.392,00 27.362,33 27.804,33
293,30
289,24
273,30
117,84
664,86
178,57
284,70
92,61
477,37
742,54
156,58
Desv. Est. 254,90
Tabla 29. Valores medios y desviación estándar resultante del procesado de los 12 casos clínicos del UPMC.
PRUEBA
VALOR
MEDIO (ms)
DESVIACIÓN
ESTÁNDAR
P1
P2
P3
P4
P5
P6
P7
P8
P9
P10
P11
P12
P13
P14
P15
P16
P17
P18
P19
P20
20,58
21,17
24,64
3.234,36
3.324,08
3.223,44
8.245,58
8.229,97
8.221,42
18.260,89
18.251,75
18.996,69
8.211,17
8.212,03
8.194,08
18.461,33
16.799,14
17.155,86
37,06
37,81
1,77
2,12
3,66
1.191,28
1.353,50
1.122,44
22,77
35,12
94,29
6.664,85
7.151,55
9.127,70
29,53
25,25
18,95
6.852,49
6.995,79
7.011,51
0,57
1,56
POR FUENTE
VALOR
DESVIACIÓN
MEDIO (ms)
ESTÁNDAR
22,13
3,15
3.260,63
1.191,57
8.232,32
58,72
18.503,11
7.506,31
8.205,76
25,64
17.472,11
6.790,81
38,29
1,78
229
APÉNDICES
P21
P22
P23
P24
P25
P26
P27
40,00
27.577,56
27.483,14
27.499,89
27.386,58
27.175,58
27.231,72
1,50
325,98
356,97
466,38
382,94
251,43
332,84
27.520,19
378,87
27.264,63
330,09
Tabla 30. Resultados, valores medios y desviación estándar resultante del procesado de las pruebas con los ficheros de longitud variable.
P28
LONGITUD 1
P29 P30 P31
P32
P33
TIEMPOS DE RESPUESTA (ms)
LONGITUD 2
P28 P29 P30 P31
P32
P33
287
297
274
270
269
274
270
290
268
264
336
326
296
298
297
299
299
292
293
293
386
326
293
290
290
291
289
285
286
285
19.475
19.199
19.785
15.933
17.953
16.326
16.837
17.894
15.256
18.253
18.612
18.720
15.897
16.746
16.787
17.070
25.170
18.613
17.910
16.280
20.180
18.856
17.815
17.027
19.051
17.177
30.265
19.607
18.744
20.431
298
318
307
303
304
306
322
314
328
308
319
307
311
306
312
310
318
319
322
315
276,30
302,90
302,10
17.691,10
18.180,50
19.915,30
310,80
313,90
329
323
327
325
321
329
342
332
334
328
26.943
24.591
27.762
29.409
34.045
46.516
45.513
49.043
38.223
23.676
24.540
29.804
25.410
38.869
43.492
48.259
33.201
47.495
47.646
30.173
LONGITUD 3
P30 P31
P32
P28
P29
25.428
24.838
22.965
29.841
51.182
44.756
50.397
30.236
38.839
41.646
348
347
334
354
356
353
355
360
356
375
362
363
355
363
358
349
359
370
351
358
425
425
405
439
409
403
402
413
405
421
101.637
63.126
56.546
46.009
88.240
61.333
52.464
44.007
46.810
55.154
105.198
60.410
62.940
45.013
62.386
48.274
58.239
48.870
58.504
48.082
79.134
62.233
51.969
62.448
58.692
66.053
43.513
46.671
62.820
49.260
P33
36.012,80
353,80
358,80
414,70
61.532,60
59.791,60
58.279,30
18.964,60 17.289,35
VALOR MEDIO (ms)
329,00
34.572,10
36.888,90
DESVIACIÓN ESTÁNDAR
230
11,03
15,21
31,84
9,43
5,51
6,00
9.631,89
9.417,28
10.707,19
10,39
6,18
12,31
P34
P35
P36
1.559,19 2.659,36 3.815,76
P37
P38
P39
P34
P35
P36
P37
P38
P39
P34
P35
P36
P37
P38
10.662,03
P39
28.008
28.426
28.776
28.360
28.541
28.954
29.458
31.180
33.043
28.973
27.697
28.341
30.955
32.444
28.295
253.488
235.685
215.571
174.486
204.933
183.152
217.468
250.799
233.545
170.433
198.874
239.533
227.653
194.518
181.910
28.337
28.267
27.849
27.777
28.231
28.910
29.209
29.025
28.925
29.114
28.322
28.501
28.480
28.465
28.539
353.999
392.222
455.643
375.700
365.826
387.848
413.082
454.980
402.244
406.175
360.984
417.418
386.981
362.410
408.748
27.557
27.704
27.532
29.518
28.978
29.011
30.826
30.800
30.258
30.733
28.083
30.192
30.027
30.326
30.076
750.942
634.661
537.191
724.331
526.889
635.629
543.982
535.596
565.240
520.425
535.512
540.215
619.945
527.908
516.980
APÉNDICES
28.322
28.405
28.245
28.330
28.647
29.251
28.661
29.381
28.890
29.404
28.425
28.096
28.134
28.037
28.277
181.600
240.184
174.984
188.405
197.027
173.984
159.234
199.069
170.511
181.820
200.922
197.057
231.154
168.479
188.252
27.747
27.635
27.393
27.376
27.396
28.772
28.641
28.364
28.524
28.396
28.725
27.989
28.033
27.874
28.033
372.879
309.759
295.263
304.032
303.163
485.393
316.729
311.716
301.781
306.451
320.146
309.195
299.672
316.404
281.418
29.600
29.572
30.042
29.683
29.455
30.398
31.583
31.393
30.409
30.292
29.988
31.187
30.455
29.999
30.222
541.078
536.347
528.364
538.258
548.668
540.048
597.760
529.038
551.316
923.124
531.039
557.018
541.195
558.239
1.123.982
594.215,80
605.203,30
VALOR MEDIO (ms)
28.406,00 29.719,50 28.870,10 206.636,30 194.001,50 202.835,20 27.800,80 28.788,00 28.296,10 352.848,60 378.639,90
346.337,60 28.964,10 30.570,30 30.055,50 586.672,90
DESVIACIÓN ESTÁNDAR
214,19 1.359,43 1.545,30 28.546,52 30.457,36 22.894,45 370,26
297,83
290,38 50.809,70 66.030,90 47.639,89
978,62
707,82
778,83
P40
P41
P42
P43
P44
P45
P40
P41
P42
P43
P44
P45
P40
P41
P42
28.450
28.816
28.099
27.473
28.054
27.234
27.951
27.619
27.597
27.643
29.658
29.951
28.862
28.729
28.326
29.247
29.065
28.918
28.820
28.750
28.483
28.933
27.657
27.798
27.628
28.075
27.875
28.036
27.646
28.299
316.448
297.543
252.210
247.383
193.980
172.771
147.111
147.601
231.204
139.948
315.024
255.171
265.389
238.544
143.953
143.336
141.604
143.156
156.774
140.036
253.466
237.805
247.279
230.054
159.720
141.175
144.970
185.532
147.281
139.011
27.562
27.771
28.303
28.425
28.999
29.187
28.860
28.270
27.716
27.645
28.748
28.970
29.057
28.564
30.397
32.246
30.442
28.759
29.239
29.229
27.863
28.010
27.806
28.430
29.726
29.592
28.831
28.201
27.947
27.939
278.249
385.971
488.794
407.270
477.827
366.163
299.509
326.680
287.630
280.080
347.094
416.129
790.898
500.880
612.522
363.749
287.880
316.145
291.336
289.556
318.620
749.294
728.140
786.261
454.225
502.456
300.461
365.519
285.902
277.268
27.517
28.613
28.686
28.186
28.475
27.854
28.976
28.397
27.158
28.796
28.956
30.412
30.061
29.392
28.611
29.815
30.259
28.697
29.439
29.928
29.364
30.408
29.893
29.329
29.302
29.721
29.954
29.656
29.578
30.232
85.673,42 120.727,10 184.484,81
P43
P44
674.461 1.501.846
632.989 1.176.685
922.809
704.976
1.040.495 688.191
594.596
586.784
554.671
551.989
662.613
551.135
596.362
547.728
569.920
578.920
557.334
577.170
P45
824.067
893.612
1.248.127
566.571
559.963
630.276
562.098
571.444
566.459
601.308
VALOR MEDIO (ms)
27.893,60 29.032,60 28.043,00 214.619,90 194.298,70 188.629,30 28.273,80 29.565,10 28.434,50 359.817,30 421.618,90
476.814,60 28.265,80 29.557,00 29.743,70 680.625,00
746.542,40
702.392,50
DESVIACIÓN ESTÁNDAR
479,56
476,14
424,18 63.952,14 66.806,73 48.250,37 595,65 1.145,01 715,27 79.228,87 167.149,79 205.240,68 587,60
231
642,82
379,06 166.203,70 326.344,76 225.747,21
APÉNDICES
APÉNDICE 3 EXAMEN DE TIPO TEST.
Tabla 31. Preguntas del examen tipo test con el que se examinó a los alumnos.
Pregunta
Respuesta tipo test a seleccionar
1.-Señala la respuesta FALSA c
a.-Todos los pacientes con fibrilación auricular presentan síntomas
b.-La fibrilación auricular es el tipo de arritmia más frecuente
c.-Un paciente con fibrilación auricular puede presentar dolor torácico y astenia
d.-La fibrilación auricular aumenta el riesgo de accidente cerebrovascular
a.-Es la valvulopatía menos frecuente en la población general
b.-No tiene relación con el problema cardíaco que presenta nuestra paciente
c.-Puede justificar la regurgitación mitral
d.-Tiene una prevalencia mayor en mujeres que en varones
a.-La hipertensión arterial
b.-Tener entre 30 y 40 años
c.-El hipertiroidismo
d.-El consumo excesivo de alcohol
a.-El cateterismo cardíaco sólo está indicado para el tratamiento de la enfermedad coronaria pero no se realiza con
fines diagnósticos
b.-En un estudio publicado en enero de 2011 por Tumbarello et al. se demuestra que el cateterismo cardíaco es un
factor de riesgo de bacteriemia por Pseudomonas aeruginosa.
c.-En el caso clínico el cateterismo cardíaco se realiza para revertir la fibrilación auricular que presenta la paciente.
d.-Todas son falsas
a.-En un estudio publicado en enero de 2011 por Freemantle et al. en el que revisan los resultados de ensayos clínicos
publicados sobre diferentes antiarrítmicos, llegan a la conclusión de que la amiodarona es el más efectivo en el
mantenimiento del ritmo sinusal pero también el que con más frecuencia produce efectos adversos graves
b.-Es un antiarrítmico que actúa aumentando la diuresis
c.-Se clasifica como antiarrítmico de clase II porque su principal efecto es beta-bloqueante
d.-Se utiliza exclusivamente en el tratamiento de arritmias supraventriculares
a.-Los antiarrítmicos que se utilizan no interactúan con ningún otro fármaco
b.-Algunos antiarrítmicos producen fotosensibilidad con aparición de reacciones cutáneas tras exposición a luz solar.
c.-Todos los antiarrítmicos tienen el mismo mecanismo de acción
2.-La insuficiencia mitral a
3.-Señala cuál de los siguientes no se
considera factor de riesgo de fibrilación
auricular b
4.-En relación al cateterismo cardíaco d
5.- Señala la correcta en relación con la
amiodarona d
6.-En el tratamiento de una arritmia d
232
APÉNDICES
d.- La ablación con radiofrecuencia es una posibilidad terapéutica cuando la arritmia no puede ser controlada con
fármacos
7.-La digoxina d
a.-Aumenta la contractilidad del músculo cardíaco
b.-Acelera el ritmo cardíaco
c.-Actúa exclusivamente sobre el miocardio y no produce ningún efecto adverso
d.-Todas son correctas
8.-La taquicardia ventricular en esta
a.-Al recibir tratamiento se estabilizó en un ritmo de 100 latidos por minuto
paciente e
b.-Pudo ser consecuencia del tratamiento con digoxina y de la alteración valvular.
c.-Aunque no se hubiera tratado no habría tenido consecuencias importantes
d.-Nunca se hubiera presentado sin una enfermedad cardíaca de base
9.-¿Qué es “anasarca” y por qué crees
a.-Se trata de un edema generalizado que en el caso de esta paciente se debe al fallo multiorgánico que desarrolla
que esta paciente presenta esta
como consecuencia del fallo cardíaco
manifestación clínica? c
b.-Se trata de un edema localizado en cabeza y cuello que en esta paciente se deba a la administración de fármacos
antiarrítmicos
c.-Se trata de una edema localizado en el abdomen que en el caso de esta paciente es consecuencia del shock séptico
que presenta
d.-Todas son falsas
10.- La paciente tiene antecedentes
a.-A los 10 años del trasplante cardíaco sobreviven aproximadamente el 50% de los pacientes
familiares de enfermedad cardíaca y una
b.-Habitualmente el corazón que se trasplanta procede de cadáver humano pero se investiga para que la posibilidad
de sus hermanas tuvo que someterse a
de trasplantes procedentes de otras especies o de corazones artificiales sea cada vez más una realidad.
un trasplante de corazón. Señala la
c.- El trasplante es la última opción para pacientes con miocardiopatía, alteraciones valvulares o defectos cardíacos
FALSA respecto al trasplante d
congénitos cuando otras alternativas terapéuticas no tienen efecto
d.- Las complicaciones del trasplante (rechazo, alteración de la función renal por fármacos, infecciones….) son
excepcionales y no aparecen antes de los 5 años desde el trasplante
a
Epidemiología; b Factores de riesgo; c Manifestaciones clínicas; d Tratamiento; e Evolución
233
APÉNDICES
APÉNDICE 4 RESULTADOS DE LA EVALUACIÓN CON ALUMNOS.
Tabla 32. Datos de los alumnos, resultados del examen tipo test y de los cuestionarios Likert.
GRUPO
A
234
DATOS GENERALES
SEXO
V
M
V
M
M
M
M
M
M
NA
M
M
M
M
V
V
V
M
V
M
M
V
V
EDAD
21
19
19
19
19
19
19
19
19
20
21
19
20
20
20
19
21
20
19
19
19
19
T(min)
50
40
25
25
30
30
35
45
50
35
50
55
55
40
30
30
35
35
45
45
50
50
1
1
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
1
1
1
0
0
0
0
1
1
1
1
0
0
1
1
1
1
1
0
0
0
1
1
PUNTUACIÓN EN LA PRUEBA OBJETIVA DE
CONOCIMIENTOS DE TIPO TEST
3
4
5
6
7
8
9
10
TOTAL
1
1
0
1
1
1
1
1
9
1
1
0
1
1
1
1
0
7
1
1
0
1
1
1
1
0
7
1
1
1
1
1
1
1
0
8
1
1
1
1
1
1
1
1
9
1
1
1
1
1
1
1
1
9
1
1
1
1
1
1
1
1
9
1
1
1
1
1
1
1
1
10
1
1
0
1
0
1
0
1
7
1
1
1
1
1
0
1
1
9
1
1
1
0
1
1
1
0
8
1
1
0
0
0
1
1
0
5
1
1
0
0
1
0
0
1
5
1
1
1
0
0
1
0
1
7
1
1
1
1
0
0
0
0
6
0
1
1
1
1
1
1
1
9
0
1
1
1
1
1
1
1
9
0
1
0
0
0
1
1
1
6
1
1
0
0
0
1
1
1
6
1
1
0
0
1
1
1
1
7
1
1
1
0
1
1
1
1
8
1
1
1
0
1
1
1
1
9
1
1
1
0
1
1
1
1
9
PERCEPCIÓN DE
APRENDIZAJE
1
2
-
1
-
PERCEPCIÓN DE
USABILIDAD
2
3
4
-
5
-
APÉNDICES
B
M
M
M
V
V
M
V
M
M
M
NA
V
M
V
M
V
V
V
M
M
M
M
M
M
M
M
NA
M
M
NA
19
19
21
21
19
28
23
20
21
19
20
19
27
19
20
20
20
22
19
19
19
19
19
19
19
19
37
50
50
35
40
40
20
41
60
42
55
45
45
40
40
90
70
60
60
55
55
50
50
50
35
35
35
40
40
40
35
1
1
1
1
1
1
1
1
1
1
0
0
1
1
1
1
1
1
1
0
1
1
1
0
1
0
1
1
1
1
0
0
1
1
1
1
1
1
1
1
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
0
0
1
1
1
0
1
1
1
0
1
1
1
1
1
1
1
1
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
0
1
1
1
1
1
1
1
1
1
1
1
1
0
0
0
0
1
1
1
1
1
1
0
0
0
1
1
1
1
1
1
0
1
1
1
1
1
0
1
1
1
1
0
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
0
0
1
1
1
1
1
1
1
1
0
1
0
1
0
1
0
0
1
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
1
0
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
1
1
0
1
0
0
1
1
0
0
0
1
0
1
1
1
1
1
0
7
7
8
10
9
7
10
10
10
8
7
7
10
8
9
6
7
10
7
7
8
8
10
5
8
6
9
9
9
7
-
4
3
5
4
3
4
4
3
5
4
5
2
3
4
1
4
4
4
4
3
3
5
2
3
3
1
3
235
3
3
5
4
3
4
4
3
4
3
4
1
1
3
1
4
5
4
5
3
4
5
4
4
3
2
4
4
4
5
4
3
4
4
4
4
3
3
3
3
4
1
3
4
4
4
3
3
3
4
3
4
3
4
4
4
4
4
5
5
3
3
5
4
3
2
3
3
1
4
5
4
4
3
3
4
2
4
4
4
5
5
4
5
3
3
4
4
4
4
4
4
1
2
3
1
4
5
4
4
3
3
4
3
3
4
3
4
4
3
4
4
3
4
5
4
4
4
4
2
3
4
1
3
5
4
5
3
4
5
5
1
4
5
4
5
4
5
4
5
5
5
5
4
4
4
2
5
5
3
5
5
5
5
4
5
5
5
5
4
5
5
APÉNDICES
M
M
M
V
M
NA
M
236
37
19
19
19
19
20
35
35
40
40
40
40
35
1
1
0
1
0
1
0
1
1
0
1
1
1
0
1
1
1
1
1
1
0
1
1
1
1
1
1
1
1
0
0
1
0
1
1
1
0
0
1
0
1
1
1
1
1
1
1
1
0
0
1
1
0
0
1
0
0
1
1
0
1
1
1
0
0
0
1
0
0
1
7
7
5
8
5
9
5
4
3
5
4
5
4
4
5
4
4
5
5
4
4
4
4
4
5
5
3
4
4
5
4
5
5
4
3
5
5
4
5
5
4
4
4
4
4
4
5
4
4
5
5
4
5
5
4
5
ÍNDICE DE FIGURAS
Figura 1 Arquitectura del modelo de sistema. .............................................. 53
Figura 2 Interfaz Web del OBA. ..................................................................... 70
Figura 3 Cliente Web desarrollado para facilitar el acceso a las ontologías
disponibles en el OBA.................................................................................... 71
Figura 4 Visualización de información bilingüe en el sitio Web de
MedlinePlus. .................................................................................................. 75
Figura 5 Resultados en HTML del cliente Web desarrollado para el servicio
de MedlinePlus. ............................................................................................. 77
Figura 6 Identificadores resultantes al utilizar la utilidad esearch del sistema
Entrez. ........................................................................................................... 81
Figura 7 Consultas a la base de datos pubmed para el término "prostate
cancer" haciendo uso de la utilidad esearch (imagen de la izquierda) y con la
utilidad esummary (imagen de la derecha) usando el primer identificador
resultante. ..................................................................................................... 82
Figura 8 Consulta a la base de datos pubmed con la utilidad efetch para
obtener el abstract en formato texto. .......................................................... 83
Figura 9 A la izquierda, pantalla principal del componente de acceso Web. A
la derecha, mensaje de espera tras el inicio del procesado. ........................ 86
Figura 10 Arriba, resultados de la extracción LOCAL tras procesar texto con
conceptos repetidos (los cajones de texto para los filtros lógicos están
enmarcados en rojo). En medio, resultado tras aplicar un filtro lógico sobre
el concepto (campo CONCEPT). Abajo, pantalla resultante tras ordenar por
los campos idioma (LAN) y, después, fuente (SOURCE). ............................... 87
Figura 11 Resultados de la extracción tras procesar remotamente el texto
con un nivel de profundidad 1 en la ontología MedlinePlus Health Topics y
237
localmente con las terminologías preprocesadas de Freebase y MedlinePlus
en inglés y en español. .................................................................................. 90
Figura 12 Con el término "asthma", arriba se muestra uno de los resultados
del módulo BEE proporcionado por el componente de acceso a síntomas de
Freebase, abajo se muestra uno de los resultados proporcionado por el
componente de acceso a enfermedades de Freebase.................................. 91
Figura 13 Interfaz Web que proporciona el componente para el acceso al
cliente de PubMed. ....................................................................................... 94
Figura 14 Cliente Web del componente de acceso XML. .............................. 95
Figura 15 Procedimiento para la creación del flujo de aplicación desde el GUI
de GATE. ...................................................................................................... 111
Figura 16 Ejemplo de código Java que utiliza las anotaciones realizadas por la
clase GateGazMed, a partir de las diferentes fuentes, para integrar la
información en la salida estándar. .............................................................. 117
Figura 17 En la imagen superior se muestran los primeros resultados
devueltos por el servicio Web de MedlinePlus, en formato XML, al realizar la
consulta por el término "cancer"; en la imagen inferior se muestra el
resultado al realizar la consulta errónea "prostate cacer". ........................ 137
Figura 18 Niveles de navegación y comunicación detallada de los elementos
de la aplicación Web. .................................................................................. 145
Figura 19 Interacción del cliente del servicio Web y conjunto de enlaces
proporcionados para cada concepto reconocido. ...................................... 150
Figura 20 Llamadas de los métodos testGate (arriba) y testOba (abajo) de la
clase TestAnnotations para la ejecución de las pruebas. ............................ 158
Figura 21 Tiempos medios de respuesta obtenidos para el reconocimiento
de términos con la fuente MedlinePlus sin formato, tras formatear en HTML
y tras formatear en XML, usando el sistema CLEiM con la terminología en
238
inglés (P1, P2 y P3), usando el servicio OBA (P4, P5 y P6) y el sistema CLEiM
con la terminología bilingüe (P19, P20 y P21)............................................. 159
Figura 22 Tiempos medios de respuesta obtenidos para el reconocimiento
de términos con la fuente SNOMED CT sin formato, tras formatear en HTML
y tras formatear en XML, usando el sistema CLEiM con la terminología en
inglés (P7, P8 y P9), usando el servicio OBA (P10, P11 y P12) y el sistema
CLEiM con la terminología bilingüe (P22, P23 y P24).................................. 160
Figura 23 Tiempos medios de respuesta obtenidos para el reconocimiento
de términos con las fuentes MedlinePlus y SNOMED CT sin formato, tras
formatear en HTML y tras formatear en XML, usando el sistema CLEiM con
la terminología en inglés (P13, P14 y P15), usando el servicio OBA (P16, P17
y P18) y el sistema CLEiM con la terminología bilingüe (P25, P26 y P27). .. 161
Figura 24 Tiempos medios de respuesta obtenidos para el reconocimiento
los ficheros de 11.895 palabras (arriba), 23.790 (en medio) y 47.580 (abajo),
representándose las terminologías locales bilingües menos pobladas
(Freebase y MedlinePlus) frente a MedlinePlus en remoto en los tres
formatos (P28-P31, P29-P32 y P30-P33), la local bilingüe más poblada
(SNOMED CT) frente a la equivalente remota en los tres formatos (P34-P37,
P35-P38 y P36-P39) y todas las locales frente a todas las remotas en los tres
formatos (P40-P43, P41-P44 y P42-P45). .................................................... 164
Figura 25 Interfaz de usuario proporcionado a los estudiantes tras procesar
el historial del paciente del caso clínico 223 obtenido del UPMC. ............. 171
Figura 26 Porcentaje de respuestas del examen de conocimientos resueltas
correctamente por los estudiantes. ............................................................ 178
Figura 27 Porcentaje de respuestas en la escala Likert en las dos preguntas
sobre la ayuda ofrecida por sistema al aprendizaje (PA). ........................... 180
239
Figura 28 Porcentaje de respuestas en la escala Likert en las cinco preguntas
sobre la usabilidad del sistema (PU). .......................................................... 181
Figura 29 Recuento de la mediana y la moda por usuario para las preguntas
de usabilidad. .............................................................................................. 182
240
ÍNDICE DE TABLAS
Tabla 1. Consultas MQL para la recuperación de los Dominios de Freebase.
....................................................................................................................... 60
Tabla 2. Tipos de Freebase pertenecientes al Dominio medicine y número de
Tópicos asociados a estos Tipos, ordenados de mayor a menor. ................. 60
Tabla 3. Información semántica asociada a los Tipos de Freebase más
apropiados y con mayor número de Tópicos. ............................................... 61
Tabla 4. Tipos, Propiedades e Identificadores de Freebase seleccionados. . 63
Tabla 5. Patrón de consulta MQL utilizada para la recuperación de los
tópicos. .......................................................................................................... 63
Tabla 6. Patrón de consulta MQL utilizada para el recuento de tópicos
agrupados en un determinado Tipo. ............................................................. 64
Tabla 7. Patrón de consulta MQL utilizada para la búsqueda de conceptos
similares en Freebase. ................................................................................... 73
Tabla 8. Consulta MQL utilizada para la búsqueda de los datos descriptivos y
la información semántica de un determinado concepto. ............................. 73
Tabla 9. Casuística proporcionada por el módulo BEE en función de la fuente
y el grupo al que pertenece el concepto reconocido en el texto de entrada.
....................................................................................................................... 92
Tabla 10. Enlaces externos incluidos para los conceptos reconocidos en la
página inicial, dependiendo de la fuente y del idioma con el que han sido
detectados..................................................................................................... 93
Tabla 11. Proceso de reconocimiento llevado a cabo por el componente de
acceso XML en función de los parámetros src y onts. .................................. 96
Tabla 12. Consultas MQL implementadas en la clase para la recuperación de
información de Freebase a través del API................................................... 100
241
Tabla 13. Envoltorio para las consultas MQL implementadas en la clase para
la recuperación de información de Freebase a través del API. ................... 101
Tabla 14. Total de conceptos para cada una de las fuentes de conocimiento
preprocesadas. ............................................................................................ 112
Tabla 15. Paralelismo entre los datos de las anotaciones locales y los
procedentes de las anotaciones remotas. .................................................. 122
Tabla 16. Formato del documento XML construido por el componente de
integración de información del módulo PLN............................................... 130
Tabla 17. Páginas enlazadas para ofrecer la información al usuario sobre los
diferentes conceptos semánticamente relacionados, en función del Tipo de
concepto. ..................................................................................................... 134
Tabla 18. Consultas MQL en el formato del API utilizadas para obtener la
información de detalle y semántica sobre los Tópicos, identificados por su
Identificador en Freebase (pid), en función de cada Tipo........................... 134
Tabla 19. Características de los textos recuperados del UPMC. ................. 155
Tabla 20. Promedio de los valores obtenidos remotamente con las
terminologías MedlinePlus y SNOMED CT y localmente con las equivalentes
bilingües, para los casos con mayor número de palabras........................... 162
Tabla 21. Cuestionario Likert para la valoración de la percepción sobre el
aprendizaje y la usabilidad. ......................................................................... 175
Tabla 22. Conteo de respuestas para cada pregunta subjetiva de aprendizaje
(PA) y usabilidad (PU), mediana y moda. .................................................... 178
Tabla 23. Resumen de la respuesta del servicio XML al procesar el texto "this
patient has asthma and presents symptoms of CRPS" con las fuentes locales.
..................................................................................................................... 213
242
Tabla 24. Resumen de la respuesta del servicio XML al procesar el texto "this
patient has asthma and presents symptoms of CRPS" con la fuente remota
MedlinePlus y el nivel de profundidad 0. .................................................... 214
Tabla 25. Resumen de la respuesta del servicio XML al procesar el texto "this
patient has asthma and presents symptoms of CRPS" con la fuente remota
MedlinePlus y el nivel de profundidad 1. .................................................... 214
Tabla 26. Resumen de la respuesta del servicio XML al procesar el texto "this
patient has asthma and presents symptoms of CRPS" con todas las fuentes
remotas y el nivel de profundidad 1. .......................................................... 215
Tabla 27. Resultados de todas las pruebas para cada uno de los 12 casos
clínicos del UPMC. ....................................................................................... 223
Tabla 28. Valores medios y desviaciones estándar obtenidos para cada uno
de los 12 casos clínicos del UPMC. .............................................................. 226
Tabla 29. Valores medios y desviación estándar resultante del procesado de
los 12 casos clínicos del UPMC. ................................................................... 229
Tabla 30. Resultados, valores medios y desviación estándar resultante del
procesado de las pruebas con los ficheros de longitud variable. ............... 230
Tabla 31. Preguntas del examen tipo test con el que se examinó a los
alumnos. ...................................................................................................... 232
Tabla 32. Datos de los alumnos, resultados del examen tipo test y de los
cuestionarios Likert. .................................................................................... 234
243
