Facultad de Informática de la Universidad Complutense
Departamento de Ingenieŕıa del Software e Inteligencia Artificial
PROYECTO DE FIN DE CARRERA
CURSO 2011/2012
INGENIERÍA INFORMÁTICA
Procesador automático de informes médicos
Autores:
Enrique Bautista Barahona
Ignacio Salcedo Ramos
Alberto Ureña Herradón
Directores:
Alberto Dı́az Esteban
Laura Plaza Morales
Fecha: 28 de junio de 2012
Enrique Bautista Barahona
Ignacio Salcedo Ramos
Alberto Ureña Herradón
Alumnos de Sistemas Informáticos, autores de este documento y
del proyecto ✭✭Procesador automático de informes médicos✮✮
Ingenieŕıa Informática
Universidad Complutense de Madrid
AUTORIZAN A LA UNIVERSIDAD COMPLUTENSE DE MADRID: A difundir y
utilizar con fines académicos, no comerciales y mencionando expresamente a sus au-
tores, tanto la propia memoria, como el código, los contenidos audiovisuales incluso
si incluyen imágenes de los autores, la documentación y/o el prototipo desarrollado.
En Madrid, a 28 de junio de 2012
Enrique Bautista Barahona Ignacio Salcedo Ramos
Alberto Ureña Herradón
Alberto Dı́az Esteban
Profesor Contratado Doctor
Departamento de Ingenieŕıa del Software e Inteligencia Artificial
Universidad Complutense de Madrid
Laura Plaza Morales
Becaria del programa de Formación de Profesorado Universitario
Departamento de Ingenieŕıa del Software e Inteligencia Artificial
Universidad Complutense de Madrid
CERTIFICAN: Que el proyecto titulado ✭✭Procesador automático de informes médi-
cos✮✮ ha sido realizado por Enrique Bautista Barahona, Ignacio Salcedo
Ramos y Alberto Ureña Herradón bajo nuestra dirección y constituye su
Proyecto de Fin de Carrera de Ingenieŕıa Informática.
En Madrid, a 28 de junio de 2012
Alberto Dı́az Esteban
Director del proyecto
Laura Plaza Morales
Directora del proyecto
Resumen:
El acceso a la información y su intercambio es vital en el ámbito médico, tanto
en la investigación como en la gestión hospitalaria. Gran parte de esta información
está contenida en informes médicos escritos en lenguaje natural y, por tanto, no es
fácilmente tratable por sistemas automáticos.
Esta memoria describe el proyecto de fin de carrera ✭✭Procesador automático de
informes médicos✮✮, cuya finalidad es la creación de un sistema de detección de con-
ceptos y términos médicos, representados mediante SNOMED CT, una terminoloǵıa
cĺınica de referencia. Además, y previamente a dicha extracción de conceptos, se rea-
lizan tareas de corrección ortográfica, detección y desambiguación de acrónimos y
detección de negaciones.
Para la construcción de esta serie de fases, se han aplicado técnicas de procesa-
miento de lenguaje natural a informes médicos en castellano. Esto supone un reto,
dado que la mayoŕıa del trabajo realizado en este campo se ha realizado para lengua
inglesa y los recursos para el español son bastante limitados.
Todo esto se integra en una herramienta que sirve para procesar automáticamente
informes médicos y generar una representación conceptual de su contenido, útil para
la gestión de dichos informes en el ámbito cĺınico-sanitario.
Adicionalmente, se han construido dos sistemas auxiliares para medir la eficacia
de la aplicación que permiten etiquetar manualmente informes para construir un
corpus de informes anotados y usar dicho corpus para evaluar los resultados del
procesamiento automático.
Palabras clave:
procesamiento de lenguaje natural, informes médicos, corrección ortográfica, desam-
biguación de acrónimos, detección de negación, detección de conceptos, SNOMED
CT
Abstract:
Accessing to and exchanging information is vital in medical settings, be it in research
or in healthcare management. Most of this information is contained in clinical reports
written in natural language free text and, therefore, it cannot be easily processed
by automatic systems.
This document describes our final degree project, “Procesador automático de infor-
mes médicos”, and its objective, which is the creation of a medical concept extraction
system that maps texts to SNOMED CT (a standard reference terminology). Moreo-
ver, to prepare the text for the concept detection, several other tasks are performed:
spelling correction, acronym detection and disambiguation, and negation detection.
In order to build the different parts of the application, we have applied natural
language processing techniques to clinical reports in Spanish. This poses a challenge,
given that most of the work done in this field deals with texts in English and the
available resources are rather limited.
The previously described tasks are implemented in a software that automatically
process medical texts, generates a conceptual representation from their contents and
serves as an example of a useful application to manage clinical reports in healthcare
and research settings.
Furthermore, we have built two auxiliary systems to measure the effectiveness of
our tool, which allow to manually tag reports to build an annotated corpus and to
use such corpus to evaluate the results of the automatic processing.
Keywords:
natural language processing, medical reports, spelling correction, acronym expan-
sion, negation detection, concept extraction, SNOMED CT
Índice general
1. Introducción 1
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1. El reto del idioma . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Ejemplo de la tarea . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Estado de la cuestión 7
2.1. Corrección ortográfica . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Correctores ortográficos . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Métricas de comparación de cadenas . . . . . . . . . . . . . . 10
2.1.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Expansión de acrónimos . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1. Sistemas de detección de acrónimos . . . . . . . . . . . . . . . 13
2.2.2. Sistemas de desambiguación de acrónimos . . . . . . . . . . . 16
2.2.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3. Detección de la negación . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1. Algoritmos para la detección de negación . . . . . . . . . . . . 18
2.3.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4. Identificación de conceptos . . . . . . . . . . . . . . . . . . . . . . . . 19
i
Índice general ii
2.4.1. Bases de conocimiento o terminoloǵıas . . . . . . . . . . . . . 19
2.4.2. La herramienta MetaMap . . . . . . . . . . . . . . . . . . . . 20
2.4.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3. Funcionamiento general 23
3.1. Corrección ortográfica . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Expansión de acrónimos . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Detección de negación . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Identificación de conceptos . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5. Anotación y evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.1. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.2. Anotación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4. Fase de corrección ortográfica 33
4.1. Resumen del proceso de corrección . . . . . . . . . . . . . . . . . . . 33
4.2. Detección de errores y creación de sugerencias . . . . . . . . . . . . . 34
4.3. Puntuación de las sugerencias . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1. Distancia de Levenshtein . . . . . . . . . . . . . . . . . . . . . 36
4.3.2. Distancia de teclado . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.3. Distancia fonética . . . . . . . . . . . . . . . . . . . . . . . . . 38
5. Fase de expansión de acrónimos 39
5.1. Detección de acrónimos . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2. Desambiguación de acrónimos . . . . . . . . . . . . . . . . . . . . . . 40
5.2.1. Sistema de reglas . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.2. Sistema de aprendizaje . . . . . . . . . . . . . . . . . . . . . . 42
6. Fase de detección de negación 45
Índice general iii
6.1. El algoritmo NegEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1.1. Descripción del algoritmo . . . . . . . . . . . . . . . . . . . . 47
6.1.2. Expresiones regulares: ventajas e inconvenientes . . . . . . . . 47
7. Fase de identificación de conceptos 49
7.1. La base de conocimiento SNOMED CT . . . . . . . . . . . . . . . . . 49
7.1.1. Tablas de SNOMED CT utilizadas . . . . . . . . . . . . . . . 49
7.1.2. Problemas con SNOMED CT . . . . . . . . . . . . . . . . . . 51
7.2. Procedimiento utilizado . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.2.1. Indexación de descripciones mediante Lucene . . . . . . . . . . 53
7.2.2. Del contenido del informe a búsquedas en Lucene . . . . . . . 54
7.2.3. Procesamiento de los resultados . . . . . . . . . . . . . . . . . 55
8. Evaluación 61
8.1. Método de evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.1.1. Corrección ortográfica y expansión de acrónimos . . . . . . . . 65
8.1.2. Detección de negación . . . . . . . . . . . . . . . . . . . . . . 66
8.1.3. Identificación de conceptos . . . . . . . . . . . . . . . . . . . . 67
8.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.2.1. Fase de corrección ortográfica . . . . . . . . . . . . . . . . . . 67
8.2.2. Fase de expansión de acrónimos . . . . . . . . . . . . . . . . . 69
8.2.3. Fase de detección de negación . . . . . . . . . . . . . . . . . . 70
8.2.4. Fase de identificación de conceptos . . . . . . . . . . . . . . . 71
9. Conclusiones y trabajo futuro 73
9.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
9.2.1. Mejoras del sistema . . . . . . . . . . . . . . . . . . . . . . . . 75
Índice general iv
9.2.2. Ampliaciones de funcionalidad . . . . . . . . . . . . . . . . . . 76
A. Manual de usuario 79
A.1. Arranque y elección de modo . . . . . . . . . . . . . . . . . . . . . . 79
A.2. Modo de procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.3. Modo de anotación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.3.1. Modo de anotación: ortograf́ıa . . . . . . . . . . . . . . . . . . 85
A.3.2. Modo de anotación: acrónimos . . . . . . . . . . . . . . . . . . 86
A.3.3. Modo de anotación: negación . . . . . . . . . . . . . . . . . . 86
A.3.4. Modo de anotación: conceptos . . . . . . . . . . . . . . . . . . 87
A.3.5. Modo de anotación: eliminar anotaciones . . . . . . . . . . . . 87
A.4. Modo de evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.4.1. Medidas empleadas . . . . . . . . . . . . . . . . . . . . . . . . 89
A.4.2. Modo de evaluación: ortograf́ıa . . . . . . . . . . . . . . . . . 90
A.4.3. Modo de evaluación: acrónimos . . . . . . . . . . . . . . . . . 91
A.4.4. Modo de evaluación: negación . . . . . . . . . . . . . . . . . . 91
A.4.5. Modo de evaluación: conceptos . . . . . . . . . . . . . . . . . 93
A.5. Editor de reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B. Configuración de la aplicación 95
B.1. correccion.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
B.2. acronimos.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
B.3. negacion.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.4. conceptos.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
B.5. splitter.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C. Formato de entrada y salida 103
C.1. Formato de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Índice general v
C.2. Formato de salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C.2.1. salida.xsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
C.2.2. schema informe procesado.xsd . . . . . . . . . . . . . . . . . . 106
D. Glosario 111
Índice de figuras
3.1. Aplicación mostrando corrección ortográfica . . . . . . . . . . . . . . 24
3.2. Aplicación mostrando expansión de acrónimos . . . . . . . . . . . . . 25
3.3. Aplicación mostrando detección de negación . . . . . . . . . . . . . . 27
3.4. Aplicación mostrando identificación de conceptos . . . . . . . . . . . 28
3.5. Aplicación mostrando resultados finales . . . . . . . . . . . . . . . . . 30
3.6. Vista del modo evaluador . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7. Detalle del modo anotador . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1. Teclado QWERTY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2. Distancia de teclado . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1. Diagrama de actividad de la desambiguación de acrónimos . . . . . . 40
5.2. Editor de reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.1. Menú principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.2. Resultados de procesamiento . . . . . . . . . . . . . . . . . . . . . . . 81
A.3. Tabla de conceptos resultado . . . . . . . . . . . . . . . . . . . . . . . 82
A.4. Menú para guardar resultados . . . . . . . . . . . . . . . . . . . . . . 83
A.5. Informe sin anotaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.6. Añadiendo una corrección . . . . . . . . . . . . . . . . . . . . . . . . 85
A.7. Selección de cue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
vii
Índice de figuras viii
A.8. Eliminando una anotación . . . . . . . . . . . . . . . . . . . . . . . . 88
A.9. Carga de informes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.10.Lista de informes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.11.Evaluación de corrección . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.12.Evaluación de negación . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.13.Editor de reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Índice de tablas
5.1. Expresiones lógicas a utilizar en las reglas . . . . . . . . . . . . . . . 41
6.1. Ejemplo de detección de negación . . . . . . . . . . . . . . . . . . . . 45
6.2. Triggers de negación . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.1. Ejemplo de las descripciones de SNOMED CT . . . . . . . . . . . . . 50
7.2. Tabla ejemplo de relaciones SNOMED CT . . . . . . . . . . . . . . . 51
7.3. Jerarqúıas de SNOMED CT . . . . . . . . . . . . . . . . . . . . . . . 52
7.4. Ejemplo de conceptos en tabla propia . . . . . . . . . . . . . . . . . . 52
8.1. Tabla de contingencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.2. Resultados de corrección ortográfica . . . . . . . . . . . . . . . . . . . 68
8.3. Leyenda de las tablas de resultados . . . . . . . . . . . . . . . . . . . 69
8.4. Resultados de expansión de acrónimos . . . . . . . . . . . . . . . . . 69
8.5. Resultados de detección de negación . . . . . . . . . . . . . . . . . . 70
8.6. Resultados de identificación de conceptos . . . . . . . . . . . . . . . . 71
ix
Índice de listados de código
3.1. Representación de corrección ortográfica . . . . . . . . . . . . . . . . 24
3.2. Representación de expansión de acrónimos . . . . . . . . . . . . . . . 26
3.3. Representación de detección de negación . . . . . . . . . . . . . . . . 27
3.4. Representación de identificación de conceptos . . . . . . . . . . . . . 29
3.5. Representación de resultados finales . . . . . . . . . . . . . . . . . . . 30
B.1. Configuración de corrección ortográfica . . . . . . . . . . . . . . . . . 95
B.2. Configuración de expansión de acrónimos . . . . . . . . . . . . . . . . 96
B.3. Configuración de detección de negación . . . . . . . . . . . . . . . . . 97
B.4. Configuración de identificación de conceptos . . . . . . . . . . . . . . 98
B.5. Configuración de splitter . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.1. Schema de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
C.2. Schema de informes procesados . . . . . . . . . . . . . . . . . . . . . 106
xi
Caṕıtulo 1
Introducción
1.1. Motivación
La necesidad de tener un buen sistema informático de gestión de informes médicos
está ganando mucha importancia en la actualidad. Los datos contenidos en estos
informes suelen ser de vital importancia y a menudo se comparten entre diferentes
profesionales del sector sanitario.
La información presente en dichos documentos suele ser de muy diversa ı́ndole:
historial del paciente, dosis suministradas, prescripciones de medicamentos, etc. Mu-
chas veces esta información aparece de manera poco estructurada y, en su mayoŕıa,
en forma de texto libre o lenguaje natural. Debido a la complejidad del procesamien-
to del lenguaje natural (PLN), el tratamiento e intercambio de esta información no
es trivial, sobre todo si se consideran grandes cantidades de textos.
Nuestro principal reto, por tanto, es desarrollar técnicas de extracción de informa-
ción y PLN para poder gestionar eficazmente la información contenida en informes
médicos. Consideramos que se trata de un desaf́ıo por la complejidad intŕınseca del
PLN (derivada de la ambiguedad del lenguaje) y, como se detalla en la sección 1.1.1,
también por nuestra decisión de trabajar con informes médicos en español.
Mediante la identificación de conceptos cĺınicos y su traducción a una represen-
tación estructurada y canónica, se facilitaŕıa considerablemente su uso, ya sea por
personal sanitario e investigadores o por sistemas informáticos. Con ello se mejoraŕıa
enormemente la gestión, clasificación y uso de los informes para diversos fines como
1
1.1. Motivación 2
pueden ser su búsqueda y recuperación para comparar diagnósticos y tratamientos o
su clasificación automática de acuerdo a estándares internacionales, como pueden ser
CIE (Clasificación Internacional de Enfermedades) o SNOMED CT (Systematized
Nomenclature of Medicine – Clinical Terms).
En este sentido, cabe destacar una serie de fases de procesamiento concretas que
resultan claves al tratar con informes médicos. Son las siguientes:
Corrección ortográfica del informe
Un informe médico a menudo contiene faltas de ortograf́ıa. Para cualquier
procesado posterior se necesita reducir al mı́nimo posible estas erratas. Al
aparecer en el texto numerosos términos médicos y acrónimos, un corrector
habitual no es capaz de tratarlos.
Desambiguación o expansión de acrónimos
Esta tarea consiste en detectar acrónimos en el texto y encontrar su acepción
o significado, lo cual no es trivial dado que un acrónimo usado por un médico
puede no tener una única acepción. Esta fase es necesaria para poder extraer
posteriormente información semántica del informe.
Identificación de conceptos
En esta fase se materializa el fin último de la aplicación, el cual consiste en
identificar y localizar los conceptos médicos que aparezcan en el informe. Para
que esta información extráıda sea de utilidad, estos conceptos deben perte-
necer a una colección de terminoloǵıa amplia, rigurosa y que pueda servir de
referencia en el ámbito cĺınico y sanitario. Para ello, hemos elegido la base de
conocimiento médico SNOMED CT.
Detección de la negación
Dado que el objetivo último al procesar el informe es detectar conceptos médi-
cos en el mismo, resulta de utilidad saber si dichos conceptos están siendo
afirmados o negados, puesto que no es lo mismo decir ✭✭el paciente no presenta
fiebre✮✮ que ✭✭el paciente presenta fiebre✮✮. Para ello, esta fase se encarga de
detectar en el texto del informe aquellas frases que están negadas y el ámbito
o alcance de la negación.
1.1. Motivación 3
1.1.1. El reto del idioma
Por último, hay que recordar que, aunque actualmente existen algunas herramien-
tas para tratar con informes médicos en inglés (para alguna o varias de las tareas
anteriores), nuestro proyecto se centra en informes médicos en español. Este hecho
aumenta la dificultad e interés del proyecto, ya que en castellano las tecnoloǵıas de
procesamiento del lenguaje natural están menos desarrolladas, existen menos herra-
mientas o éstas deben ser adaptadas. Estas cuestiones se tratarán más a fondo en
las siguientes secciones de la memoria, en especial en el apartado 2 (Estado de la
cuestión).
1.1.2. Ejemplo de la tarea
A continuación se presenta un pequeño ejemplo simplificado para aclarar qué se
quiere conseguir en las diversas fases del procesamiento.
Para el siguiente fragmento de un informe:
✭✭El paciente ingresó con fiebre y signs de deshidratacion. Llega a planta con
REG. ACR : sin arritmias.✮✮
El sistema nos devolveŕıa los siguientes resultados:
Correcciones:
signs → signos;
deshidratacion → deshidratación.
Acrónimos:
REG → ✭✭Regular estado general✮✮;
ACR → ✭✭Auscultación cardiorespiratoria✮✮.
Conceptos:
Hallazgo - Fiebre (afirmado);
Hallazgo - Deshidratación (afirmado);
Condición - Estado general regular (afirmado);
Procedimiento - Auscultación cardiorespiratoria (afirmado);
Hallazgo - Arritmias (negado).
1.2. Objetivos 4
1.2. Objetivos
A continuación se exponen los objetivos del proyecto.
El objetivo principal consiste en el desarrollo de una herramienta para el análisis de
informes médicos y la obtención de una representación conceptual de su contenido,
distinguiendo lo negado de lo afirmado. Esta aplicación deberá constituir también
un ejemplo de herramienta que sea usable en un ámbito médico o administrativo
para la extracción de información de los informes.
El sistema ha de contar con una serie de módulos que respondan a las fases que
se han comentado en al apartado Motivación. Son las siguientes:
Corrección ortográfica.
Expansión y desambiguación de acrónimos.
Identificación de conceptos.
Detección de la negación.
Se concretarán las funcionalidades de dicho sistema en el apartado 3 (Funciona-
miento general).
Adicionalmente, para mejorar la flexibilidad y utilidad del sistema, este deberá ser
configurable en la medida de lo posible, permitiendo trabajar con diferentes recursos
o modificar el comportamiento de los algoritmos.
Para la tarea de construir estos módulos, realizaremos un análisis de las herramien-
tas y algoritmos existentes para el PLN. Esto supone buscar herramientas existentes
y ver cómo se pueden aplicar o adaptar para su uso con textos médicos. Dichas he-
rramientas, además, deben estar hechas para el castellano o, al menos, se deben
poder adaptar a nuestra lengua.
El último objetivo del proyecto consiste en que las herramientas y algoritmos em-
pleados deben ser evaluables, es decir, necesitamos obtener medidas objetivas sobre
su eficacia y corrección. Esto es siempre muy importante a la hora de desarrollar
una herramienta que trabaje sobre algo tan heterogéneo como es el lenguaje natural.
Para esto, la aplicación incluirá un subsistema capaz de anotar informes médicos con
resultados correctos y otro subsistema capaz de comparar los resultados del análisis
con los resultados correctos previamente anotados.
1.3. Estructura de la memoria 5
1.3. Estructura de la memoria
La memoria se estructura como a continuación se detalla. Primero, se hace un repaso
de la tecnoloǵıa existente sobre lenguaje natural en los campos que nos interesan
para el procesamiento de informes. Este será el caṕıtulo 2, Estado de la cuestión.
A continuación, se describen las funcionalidades de la herramienta desarrollada
en el caṕıtulo 3, Funcionamiento general, para posteriormente detallar las fases del
procesamiento en las que se divide la aplicación en los caṕıtulos Fase de corrección
ortográfica, Fase de expansión de acrónimos, Fase de detección de negación y Fase
de identificación de conceptos.
Después, se hará un estudio de la eficacia de la aplicación en el apartado 8, Eva-
luación.
Por último, en el apartado 9, Conclusiones y trabajo futuro, realizaremos una re-
flexión sobre lo conseguido en el proyecto y qué partes seŕıa más interesante mejorar.
Se adjuntan además como anexos un manual de usuario de la aplicación, expli-
caciones sobre los archivos de configuración de la misma, un comentario sobre los
formatos de entrada y salida y un glosario.
Caṕıtulo 2
Estado de la cuestión
Antes de comenzar con el desarrollo de la aplicación se ha procedido a estudiar
el estado de la cuestión que nos ocupa: el procesamiento de lenguaje natural y su
aplicación al ámbito de los informes médicos. Con este estudio se pretende conocer
las técnicas empleadas actualmente en este campo y determinar si alguna de las
herramientas y libreŕıas disponibles en la actualidad pueden ser de utilidad en el
desarrollo del proyecto.
Asimismo, se han examinado dos módulos proporcionados por los directores del
proyecto y desarrollados por el grupo NIL1 de la Universidad Complutense de Ma-
drid, al que pertenecen. Dichos módulos son parte del trabajo realizado en el pro-
yecto AutoIndexer2, que teńıa como objetivo la investigación y el desarrollo de me-
todoloǵıas y recursos para el procesamiento de documentos cĺınicos. El proyecto se
realizó bajo el programa AVANZA I+D del Ministerio de Industria, Comercio y
Turismo, en colaboración con la empresa Indizen.
2.1. Corrección ortográfica
La mayoŕıa de programas de corrección ortográfica analizan el texto a corregir pa-
labra por palabra, sin tener en cuenta el contexto en el que aparece cada vocablo.
Este análisis consiste en una búsqueda en un diccionario. En caso de no encontrar
1http://nil.fdi.ucm.es/
2http://nil.fdi.ucm.es/index.php?q=node/471
7
http://nil.fdi.ucm.es/
http://nil.fdi.ucm.es/index.php?q=node/471
2.1. Corrección ortográfica 8
ninguna coincidencia, el programa considera que la palabra no está escrita correc-
tamente, obtiene una serie de términos similares al analizado y los presenta como
posibles soluciones del error.
La diferencia entre unos correctores ortográficos y otros suele residir en el método
que emplean para decidir qué palabras sugerir como soluciones. Las técnicas usadas
van desde la comparación entre cadenas de caracteres, al uso de reglas gramaticales
más o menos complejas, pasando por comparaciones de la fonética de las palabras
o la distancia en el teclado de las letras utilizadas.
2.1.1. Correctores ortográficos
A continuación, se presenta un resumen de las capacidades de algunas de las he-
rramientas de corrección ortográfica con más difusión en la actualidad. Después, se
concluye explicando cuál de ellas se integrará en la aplicación y por qué.
2.1.1.1. Ispell
Ispell3 es un corrector ortográfico para Unix disponible bajo una licencia propia
de código abierto. Originalmente construido para el inglés, actualmente cuenta con
soporte para la mayoŕıa de idiomas europeos y algunas lenguas del sur de África y
del sureste de Asia.
Es uno de los correctores más antiguos y es la base de la mayoŕıa de correctores
que han surgido después. Todos sus sucesores incorporan su mecanismo de creación
de sugerencias que, pese a ser simple, suele dar resultados razonablemente buenos.
Cuando detecta una palabra mal escrita, solo sugiere términos que se encuentren a
una distancia Damerau-Levenshtein (Damerau [1964]) de 1. Esto quiere decir que
las sugerencias se obtienen realizando una sola operación sobre la palabra original,
siendo las operaciones posibles el borrado, la adición y la modificación de una letra,
el intercambio de dos letras y la adición de un espacio o guión.
3http://www.lasr.cs.ucla.edu/geoff/ispell.html
http://www.lasr.cs.ucla.edu/geoff/ispell.html
2.1. Corrección ortográfica 9
2.1.1.2. GNU Aspell
Aspell4 es un corrector ortográfico basado en Ispell y creado con el propósito de
reemplazarlo. Está escrito en C++ y se puede utilizar bajo la licencia LGPL. Pro-
porciona mejores resultados que Ispell para el inglés gracias a la adición de un siste-
ma de comparación fonética. En el diccionario español, sin embargo, no se adjuntan
las reglas fonéticas necesarias para usar dicho sistema, aunque se pueden añadir.
Además, presenta las siguientes mejoras: uso simultáneo de varios diccionarios, más
facilidad de uso para codificación UTF8 y uso optimizado de diccionarios personales
con varios procesos.
2.1.1.3. MySpell
MySpell5 es un corrector ortográfico similar a Ispell, disponible bajo una licencia
BSD. Fue desarrollado en C++ para ser incluido en la suite ofimática de OpenOffi-
ce.org. En su sitio web se informa expĺıcitamente de que su funcionalidad es inferior
a la de Ispell y Aspell.
También existe una implementación en Java independiente del proyecto original:
JMySpell6.
2.1.1.4. Hunspell
Hunspell7 es un corrector ortográfico y analizador morfológico diseñado para len-
guajes con una morfoloǵıa y composición de palabras complejos (fue creado origi-
nalmente para el húngaro). No obstante, esto no quiere decir que sea utilizado solo
con lenguajes de estas caracteŕısticas. Desarrollado en C++, está disponible bajo
licencias GPL, LGPL y MPL.
Es una herramienta popular, utilizada actualmente en numerosas aplicaciones de
éxito entre las que se encuentran Google Chrome, Mozilla Firefox, Mozilla Thun-
derbird, las suites ofimáticas de OpenOffice.org y LibreOffice y el sistema operativo
4http://aspell.net/
5https://code.google.com/a/apache-extras.org/p/ooo-myspell/
6http://kenai.com/projects/jmyspell
7http://hunspell.sourceforge.net/
http://aspell.net/
https://code.google.com/a/apache-extras.org/p/ooo-myspell/
http://kenai.com/projects/jmyspell
http://hunspell.sourceforge.net/
2.1. Corrección ortográfica 10
Mac OS X de Apple. Es debido a su gran popularidad que existe una gran variedad
de diccionarios disponibles para Hunspell.
Los algoritmos que utiliza están basados en los de Ispell y Aspell y, de nuevo, en
el diccionario español no se adjuntan las reglas fonéticas, pero se pueden añadir.
Además, para mejorar el mecanismo de creación de sugerencias, permite utilizar
reglas y n-gramas.
2.1.2. Métricas de comparación de cadenas
Las métricas de comparación de cadenas son métricas que miden lo parecidas que
son dos cadenas de caracteres (o, en otras palabras, la distancia que hay entre ellas).
Dado el trabajo que se pretende desarrollar en este proyecto, creemos que este
tipo de métricas pueden resultar útiles, por ejemplo, para puntuar las sugerencias
de un corrector ortográfico.
2.1.2.1. Distancia de edición
La distancia de edición es el coste mı́nimo resultante de aplicar las operaciones
necesarias para transformar una cadena en otra, perteneciendo estas operaciones a
un conjunto de operaciones permitidas y teniendo un coste y unos efectos concretos.
Variando las operaciones que forman parte de este conjunto y sus costes, se han
definido varias métricas diferentes.
Distancia de Levenshtein
La distancia de Levenshtein (Levenshtein [1966]) es la distancia de edición más
común. Su conjunto de operaciones válidas está formado por la inserción, el borrado
y la substitución de un carácter. Todas tienen un coste de 1, por lo que el coste total
es igual al número de operaciones aplicadas, p. ej. la distancia de Levenshtein entre
✭✭repostero✮✮ y ✭✭costeras✮✮ es 5, ya que son indispensables al menos 5 operaciones para
transformar una en la otra:
1. repostero - postero (2 borrados)
2. postero - costera (2 sustituciones)
2.1. Corrección ortográfica 11
3. costera - costeras (1 inserción)
Similares a la distancia de Levenshtein, existen otras métricas de coste 1, que se
diferencian simplemente por el conjunto de operaciones que permiten realizar sobre
las cadenas, p. ej.:
La distancia de Hamming (Hamming [1950]), precursora de la de Levenshtein,
únicamente permite la sustitución de caracteres.
La distancia de Damerau-Levenshtein (Damerau [1964]) permite las mismas
operaciones que la de Levenshtein y, además, la trasposición de dos caracteres
adyacentes.
Algoritmo Needleman-Wunsch
El algoritmo Needleman-Wunsch (Needleman and Wunsch [1970]) surgió en el cam-
po de la bioinformática para comparar secuencias de ADN, ARN o protéınas, pero
también es usado en el campo del procesamiento del lenguaje natural.
Trata el problema del alineamiento global de secuencias, que consiste en alinear
cada elemento de una secuencia con el mismo elemento en la otra secuencia, sin
modificar el orden de los elementos. Está permitido añadir elementos vaćıos (huecos)
y alinear elementos que no sean iguales si es preciso, lo que sucederá cuando una
secuencia no sea una subcadena o subsecuencia, respectivamente, de la otra. Ha sido
demostrado que este problema es equivalente a la minimización de la distancia de
edición (Sellers [1974]).
Para calcular la similitud de las secuencias, se hace uso de una matriz de similitud,
que contiene para cada par de elementos alineados una puntuación distinta, y de
una puntuación para los huecos. Por tanto, la diferencia con las distancias de edición
expuestas anteriormente reside en los costes de las operaciones. Concretamente, los
costes de inserción/borrado pueden ser distintos a los de sustitución, y a su vez,
los costes de sustitución de cada par de caracteres del lenguaje considerado pueden
también ser distintos.
2.1. Corrección ortográfica 12
2.1.2.2. Algoritmos fonéticos
Los algoritmos fonéticos son algoritmos que traducen una palabra a un código que
la represente, de acuerdo a ciertas reglas basadas en las normas de pronunciación de
un lenguaje concreto. Después, estos códigos se pueden comparar para determinar
la similitud de las palabras originales.
La mayoŕıa de algoritmos fonéticos se desarrollaron con el propósito de traducir
nombres y apellidos. No obstante, también existe algún algoritmo creado con el ob-
jetivo de traducir cualquier palabra, siendo los más conocidos las diferentes versiones
del algoritmo Metaphone (Philips [1990]).
En cuanto al idioma, originalmente fueron desarrollados para el inglés y, con el
tiempo, fueron mejorados con soporte para extranjerismos. Existen adaptaciones a
otros idiomas, aunque no tienen tanta difusión.
2.1.3. Conclusiones
Antes de continuar, se ha de decir que los textos que se van a tratar provienen de
informes médicos y, por tanto, contienen una alta cantidad de términos espećıficos del
ámbito cĺınico. En general, hacen uso de una jerga y unas expresiones recurrentes y
las faltas de ortograf́ıa presentes en estos textos suelen ser leves. Dicho esto, se podŕıa
considerar que usando un diccionario extenso, con gran cantidad de terminoloǵıa
médica, cualquiera de los correctores analizados proporcionaŕıa resultados decentes.
Finalmente, hemos decidido utilizar Hunspell, dado su diseño enfocado a lenguajes
morfológicamente complejos y su capacidad para trabajar con reglas y n-gramas.
Pese a que ahora no vamos a utilizar todo lo que nos ofrece, consideramos que es
una funcionalidad conveniente para la aplicación, que podŕıa ser utilizada en un
futuro.
Hay pruebas que sugieren que Aspell proporciona mejores resultados para el
inglés8, pero estos resultados no son directamente extrapolables a otros idiomas,
ya que dependen de la calidad de los recursos. En cuanto a las reglas fonéticas,
tanto Aspell como Hunspell son capaces de aplicarlas, pero ninguno de los dos las
8http://aspell.net/test/cur/
http://aspell.net/test/cur/
2.2. Expansión de acrónimos 13
proporcionan con sus diccionarios españoles. Por tanto, en ese aspecto se encuentran
igualados.
Cabe decir que para conectar la libreŕıa Hunspell con la aplicación partimos del
módulo de corrección de AutoIndexer, ya que sirve precisamente de envoltorio de
Hunspell, simplificando el acceso desde código Java a la funcionalidad que este ofrece.
Por último, en cuanto a las métricas de comparación estudiadas, se ha decidido
que se utilizarán para puntuar las sugerencias del corrector. Concretamente, se em-
pleará una combinación de ellas para construir un sistema de puntuación que tenga
en cuenta la fonética y la distancia de los caracteres en el teclado, además de la
distancia de edición.
2.2. Expansión de acrónimos
Los sistemas de expansión automática de acrónimos tratan de resolver dos problemas
diferentes: la detección y la desambiguación de acrónimos.
La detección es el proceso mediante el cual se localizan los acrónimos presentes en
el texto que se está procesando. La desambiguación es el mecanismo que determina
cuál es la expansión adecuada de cada acrónimo detectado según el contexto en el
que se encuentra.
2.2.1. Sistemas de detección de acrónimos
Los sistemas de detección de acrónimos emplean lexicones, métodos basados en
patrones, aprendizaje máquina o combinaciones de estos. A continuación, se presenta
un breve resumen de cada técnica y algún ejemplo de su uso en sistemas reales.
2.2.1.1. Uso de lexicón de acrónimos
Este método es el más sencillo de implementar de todos. Consiste en dividir el texto a
procesar en palabras y buscar cada palabra en un lexicón de acrónimos. Las palabras
2.2. Expansión de acrónimos 14
que estén en el lexicón serán clasificadas como acrónimos. El proyecto AutoIndexer9
utiliza este método.
2.2.1.2. Métodos basados en patrones
Estos métodos detectarán una palabra como acrónimo cuando la palabra cumpla
una serie de patrones (que todas sus letras sean mayúsculas o que su longitud sea
menor de cuatro caracteres, son ejemplos de posibles patrones).
Acronym Finder Program
Es el sistema pionero en la detección automática de siglas (Taghva and Gilbreth
[1999]). Es una herramienta que combina el uso de patrones con el algoritmo de
la mayor subsecuencia común para hallar todas las alineaciones posibles entre cada
candidato a sigla y su forma expandida.
Los patrones que utiliza son los siguientes:
Todas las letras de las palabras son mayúsculas.
Las palabras tienen desde tres hasta diez caracteres.
Cada carácter de la sigla debe coincidir con el primer carácter de cada palabra
de la forma expandida.
Para evaluar la herramienta se utilizó un corpus de 17 documentos. El sistema
identificó de forma correcta 398 siglas, lo que supuso una precisión del 98%.
Three Letter Acronym
Es un sistema que tiene el principio general de que una palabra es una sigla si
cumple con ciertos patrones y además se encuentra cerca de una forma expandida
coincidente con las siglas (Larkey et al. [2000]). El sistema utiliza cuatro algoritmos
diferentes para detectar siglas.
Algunos de los patrones que utiliza son los siguientes:
9http://nil.fdi.ucm.es/index.php?q=node/471
http://nil.fdi.ucm.es/index.php?q=node/471
2.2. Expansión de acrónimos 15
Todas las letras de las palabras son mayúsculas.
La palabra tiene un punto entre cada par de caracteres.
La palabra está compuesta por al menos tres letras mayúsculas seguidas de
una secuencia de letras minúsculas, pudiendo terminar con una o dos letras
mayúsculas (COGSNet o AChemS son ejemplos de siglas que cumplen este
patrón).
La palabra está compuesta por letras mayúsculas y tiene algún d́ıgito en cual-
quier posición de la palabra.
La palabra puede contener algún espacio, siempre que vaya precedido por una
letra mayúscula.
La palabra está compuesta por letras mayúsculas y tiene barras o guiones en
cualquier posición.
Para la evaluación del sistema se utilizó un corpus de 936 550 páginas web de insti-
tuciones militares y gubernamentales de los Estados Unidos. Los cuatro algoritmos
fallaron en la detección de tan solo 16 casos.
2.2.1.3. Métodos basados en algoritmos de aprendizaje máquina
Los algoritmos de aprendizaje máquina permiten al sistema aprender a reconocer y
clasificar acrónimos mediante ejemplos, atributos y valores. Son capaces de mejorar
con la experiencia.
A supervised learning approach to acronym identification
Este sistema propone un sistema de detección de siglas basado en aprendizaje su-
pervisado (Nadeau and Turney [2005]).
El algoritmo que utiliza convierte en vectores los candidatos a sigla detectados.
Cada vector se compone de 17 caracteŕısticas que describen cada palabra. Para
determinar si la palabra es una sigla, el algoritmo la confronta con un corpus anotado
y según el resultado de dicha comparación la palabra será clasificada como sigla o
no.
2.2. Expansión de acrónimos 16
Entre las caracteŕısticas que utiliza para clasificar a los candidatos se encuentran
las siguientes: el número de letras mayúsculas, la longitud, el número de d́ıgitos o el
número de letras.
Los precisión del sistema es de un 92.5% utilizando la técnica de clasificación
Support Vector Machine implementada en la suite de aprendizaje máquina WEKA
con el algoritmo Sequential Minimal Optimization.
Acronym Recognition: Recognizing acronyms in Swedish texts
La finalidad de este sistema es el reconocimiento de siglas en textos biomédicos
escritos en sueco (Dannélls [2006]). Es similar al sistema anterior aunque utiliza tan
solo 10 caracteŕısticas para clasificar cada candidato.
En los mejores resultados obtenidos a la hora de evaluar el sistema se reconocieron
correctamente el 98.9% de las siglas.
2.2.2. Sistemas de desambiguación de acrónimos
Los sistemas de desambiguación de acrónimos suelen utilizar algoritmos de apren-
dizaje máquina.
En primer lugar, buscan cada una de las posibles expansiones en el texto y, en
caso de encontrar una, desambiguan el acrónimo con esa expansión. En caso de no
encontrar ninguna, procesan el contexto del acrónimo comparándolo con los ejemplos
de entrenamiento y, según el resultado obtenido, etiquetan el acrónimo con una u
otra expansión.
Polyfind
Pustejovsky et al. desarrollaron un algoritmo de aprendizaje automático llamado
Polyfind para la desambiguación de siglas (Pustejovsky et al. [2004]).
Para computar la medida de similitud entre los contextos de la búsqueda y cada
uno de los contextos de entrenamiento se utilizó el modelo de espacio vectorial.
En la evaluación que se realizó, Polyfind alcanzó 97.2% de exactitud en la desam-
biguación.
2.3. Detección de la negación 17
Automatic resolution of ambiguous abbreviations in biomedical texts
Yu implementó un sistema para desambiguar las siglas de los abstracts de la base
de datos MEDLINE (Yu [2003]). Este sistema se basa en el uso de Support Vector
Machines y en la hipótesis de que todas las ocurrencias de una misma sigla dentro
de un abstract tienen la misma expansión. Los SVM utilizan un corpus etiquetado
como corpus de entrenamiento en el que cada sigla está representada por un vector.
Los vectores están compuestos por cada una de las palabras presentes en el contexto
de la sigla.
En la evaluación, este sistema alcanzó una precisión del 87%.
2.2.3. Conclusiones
Nuestro sistema parte del proyecto AutoIndexer, en el cual se utiliza un lexicón de
acrónimos para la detección y un sistema de reglas para la desambiguación.
Al disponer de parte de los recursos que utiliza AutoIndexer, decidimos utilizar la
misma técnica y uno de sus lexicones para detectar los acrónimos. Para la tarea de
la desambiguación, decidimos implementar un algoritmo de aprendizaje automático
para utilizarlo junto con el sistema de reglas de AutoIndexer. Dado que no dispo-
nemos de un corpus de informes o art́ıculos médicos anotados donde obtener los
ejemplos de entrenamiento para el algoritmo, decidimos utilizar las descripciones de
SNOMED CT. En estas descripciones aparecen algunas de las formas expandidas
de los acrónimos presentes en los recursos de AutoIndexer. De dichas descripciones
obtendremos los contextos de las formas expandidas, trasformándolos en vectores
para usarlos como ejemplos de entrenamiento.
2.3. Detección de la negación
La tarea de la detección de la negación consiste en detectar qué frases están negadas,
aśı como el alcance o ámbito de la negación, i.e. las partes de estas frases cuyo sentido
o significado está negado.
2.3. Detección de la negación 18
2.3.1. Algoritmos para la detección de negación
Para el análisis de la negación existen diferentes maneras de proceder, pudiendo
distinguir tres tipos principales de algoritmos.
Algoritmos basados en análisis sintáctico
Estos algoritmos procesan las frases mediante un analizador morfo-sintáctico o par-
ser. Después, calculan el ámbito de la negación basándose en las dependencias y fun-
ciones de las partes de la oración (Carrillo de Albornoz et al. [2012], Ballesteros et al.
[2012]).
El problema de este enfoque es que requiere que los parsers estén entrenados para
cierto tipo de textos y, como ya se ha comentado, no disponemos de un corpus de
informes médicos en castellano.
Algoritmos basados en expresiones regulares
Estos son los algoritmos con mayor éxito en la actualidad. Concretamente, NegEx
aparece nombrado en diversos art́ıculos y trabajos sobre procesamiento de informes
médicos (Chapman et al. [2001], Meystre and Haug [2006]). Este ha sido el método
que nosotros hemos elegido como punto de partida, dado que, aunque el algoritmo
original se construyó para el inglés, ya se han hecho adaptaciones a otros idiomas,
como el sueco (Skeppstedt [2011]). En el caṕıtulo 6, Detección de negación, se pro-
fundizará en este algoritmo y cómo se ha adaptado al castellano.
Algoritmos basados en gramáticas independientes del contexto
El principal exponente de estos algoritmos es Negfinder. Dicho algoritmo se vale de
un analizador léxico, aśı como de un analizador sintáctico basado en una gramática
LALR(1) para detectar las negaciones (Cruz Dı́az et al. [2010]). Algunos estudios
dan a este algoritmo una eficacia superior a los basados en expresiones regulares,
pero una vez más, no contamos con una versión para el español, lo cual es una
desventaja considerable que nos hace decantarnos por NegEx.
2.4. Identificación de conceptos 19
2.3.2. Conclusiones
Dada la inexistencia de herramientas disponibles para la detección de la negación en
castellano, sumada al hecho de que solo se puede dedicar parte del esfuerzo a este
módulo, se optó por adaptar NegEx para trabajar con textos en castellano.
Otros algoritmos más sofisticados y costosos de implementar no suponen una gran
diferencia de eficacia con respecto a NegEx. Además, nuestro objetivo final es iden-
tificar qué conceptos aparecen negados en un tipo de texto en particular: informes
médicos. Dada la naturaleza basada en patrones de NegEx, consideramos que éste
es fácilmente adaptable a dicho tipo de textos.
2.4. Identificación de conceptos
Para la construcción de un sistema de identificación de conceptos, es preciso tener
en cuenta tanto los algoritmos a utilizar como la base de conocimiento con la que
trabajará la aplicación.
En esta sección, se presenta en primer lugar un breve resumen de algunas de
las terminoloǵıas médicas más desarrolladas. Después, dado el gran parecido de las
técnicas que usan los sistemas de identificación de conceptos, a modo de ejemplo se
comenta exclusivamente el funcionamiento de la herramienta MetaMap.
2.4.1. Bases de conocimiento o terminoloǵıas
El punto más importante al hablar de la identificación de conceptos son las bases
de conocimiento y colecciones de vocabulario médico que existen en la actualidad.
2.4.1.1. El Metatesauro UMLS
UMLS (Unified Medical Language System) es un compendio de vocabulario biomédi-
co y aplicaciones informáticas. Proporciona una estructura de relaciones entre di-
ferentes terminoloǵıas, de modo que se pueda traducir conceptos de una base de
conocimiento médica a otra.
2.4. Identificación de conceptos 20
Se le llama Metatesauro a la base de conocimiento principal de UMLS. Un tesau-
ro es un conjunto de palabras o términos agrupados, en el que las palabras están
relacionadas por sinónimos. El Metatesauro comprende a su vez varias bases de co-
nocimiento y permite la traducción entre ellas. En total contiene más de un millón de
conceptos biomédicos. A destacar de entre sus vocabularios o terminoloǵıas: CIE-10
y SNOMED CT.
2.4.1.2. SNOMED CT
SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms) es una
colección de términos médicos organizados sistemáticamente. Incluye definiciones,
términos, relaciones y sinónimos sobre enfermedades, procedimientos cĺınicos, mi-
croorganismos, śıntomas, sustancias y otros conceptos.
Existen otras bases de datos sobre conceptos médicos como CIE (Clasificación
internacional de enfermedades), pero SNOMED CT es considerada como la mayor
y más precisa colección de terminoloǵıa (codificada) en la actualidad.
Además, mediante tablas de referencias cruzadas se pueden hallar equivalencias
entre conceptos SNOMED CT y otras colecciones de términos como CIE. SNO-
MED CT incluye diversas tablas y subconjuntos diferentes, aśı como versiones para
diferentes lenguas
Por todos estos motivos, elegimos esta base de conocimiento para la representación
conceptual a obtener como salida de nuestra aplicación. En el caṕıtulo 7, se expli-
cará a detalle el uso que se hace de SNOMED CT por parte de nuestra aplicación.
2.4.2. MetaMap
MetaMap (Aronson [2001]) es una herramienta con funcionalidad muy similar a la
que pretendemos desarrollar en nuestro módulo identificador de conceptos, desa-
rrollada por el Lister Hill National Center for Biomedical Communications de la
National Library of Medicine de Estados Unidos para textos de lengua inglesa.
Dado un texto médico de entrada, MetaMap encuentra y devuelve conceptos per-
tenecientes al Metatesauro UMLS. Para ello, en su primera versión se siguen en
términos generales los siguientes pasos.
2.4. Identificación de conceptos 21
En primer lugar, se utiliza un parser para extraer del texto los sintagmas no-
minales y asignar etiquetas sintácticas (sustantivo, verbo, etc.) a las palabras.
Después, para cada fragmento de texto se obtiene el conjunto de todos los
sinónimos, acrónimos, abreviaturas, palabras de la misma familia y combina-
ciones de estas generadas a partir de las palabras del fragmento original. La
información sobre las variantes está precomputada y almacenada para mejorar
la eficiencia.
A continuación, se buscan en la base de conocimiento las variantes genera-
das. Las búsquedas se realizan a través de ı́ndices creados especialmente para
aumentar el rendimiento.
Por último, se puntúa la similitud del fragmento de texto original con los
conceptos resultado y combinaciones de ellos, eligiendo finalmente el concepto
(o la combinación) con mejor puntuación.
2.4.3. Conclusiones
Para construir el módulo de identificación de conceptos, hemos decidido partir de
cero. La razón es que no hemos encontrado ningún sistema que respete las siguientes
restricciones:
no se puede utilizar un enfoque estad́ıstico o de aprendizaje, ya que el corpus de
informes disponible no sobrepasa los 10 documentos, i.e. es demasiado pequeño.
se debe usar la colección de terminoloǵıa SNOMED CT.
se deben procesar informes en español.
Caṕıtulo 3
Funcionamiento general
El procesamiento de informes médicos es la meta principal de este proyecto y, por
extensión, de la aplicación. El objetivo de este caṕıtulo es proporcionar una visión
general de su funcionamiento que sirva como introducción al contenido presentado en
el resto de este documento. Es decir, no debe verse como una descripción detallada
del procesado que se realiza sobre cada informe, sino como una gúıa de alto nivel
del mismo.
En los siguientes caṕıtulos de este documento se explican con más detenimiento
las particularidades de cada una de las fases del procesamiento.
3.1. Corrección ortográfica
La fase de corrección ortográfica es la primera de las fases del procesado. Su objetivo
es detectar palabras mal escritas en el texto y corregirlas automáticamente.
Al comienzo de la fase de corrección, se recibe una estructura de datos que contiene
todo el texto a procesar, dividido en cuantas secciones tuviera el informe. Este texto
se trocea en tokens y, a continuación, se procesa cada uno de ellos para determinar
si necesita corrección y, en tal caso, corregirlo.
Para realizar la corrección, el sistema produce una serie de sugerencias, que después
puntúa, con el objetivo de determinar cuál es la sugerencia más adecuada. En el
caso de que ninguna de ellas se considere apropiada, se dejan todas como posibles
soluciones, pero no se aplica ninguna de ellas, i.e. se mantiene la palabra mal escrita.
23
3.1. Corrección ortográfica 24
Figura 3.1: Vista de la aplicación tras la corrección ortográfica
En la figura 3.1 se muestra el resultado de aplicar la fase de corrección sobre un
informe. En la parte superior se puede observar un fragmento del texto, donde las
palabras subrayadas son las que se han identificado como faltas de ortograf́ıa. En
la parte inferior se encuentra la lista de errores encontrados y las sugerencias de
corrección. Se adjunta además la puntuación obtenida por cada sugerencia en el
algoritmo de puntuación.
En el listado 3.1 se muestra un detalle de la representación interna del informe,
con una de las anotaciones resultantes de aplicar la corrección ortográfica.
1
2
3 TSH y T4
4
5 nirmales
6 normales
7 0.9
8
9 .
10
Listado de código 3.1: Representación interna de resultados de corrección ortográfica
3.2. Expansión de acrónimos 25
3.2. Expansión de acrónimos
La expansión de un acrónimo es el intercambio de un acrónimo por las palabras que
hacen expĺıcito su significado. Se trata de una tarea compleja, ya que habitualmente
un mismo acrónimo o abreviatura se corresponde con más de una expansión.
El objetivo de esta fase es detectar los acrónimos que hay en el texto y, mediante
un proceso de desambiguación, elegir la expansión más adecuada para cada uno de
ellos según el contexto en el que se encuentren.
Al comienzo de la fase se recibe el texto del informe dividido en secciones y,
además, anotado con el resultado de la fase anterior. Este texto se trocea en tokens
y, a continuación, se procesa cada uno de ellos para determinar si es un acrónimo
y, en tal caso, expandirlo, para lo cual el sistema recupera de su base de datos sus
expansiones conocidas.
Si solo se encuentra una expansión, se aplica y se termina el procesamiento, pero
si se encuentran más es necesario elegir la más adecuada. Para ello, se busca en
primer lugar alguna regla que indique expĺıcitamente la expansión a realizar, dado
el acrónimo y su contexto. En caso de no encontrar ninguna, se elige la expansión
correspondiente al contexto más parecido al del token que está siendo procesado.
Figura 3.2: Vista de la aplicación tras la expansión de acrónimos
En la figura 3.2 se muestra el resultado de aplicar la fase de expansión sobre un
informe. En la parte superior se puede observar un fragmento del texto, donde las
3.3. Detección de negación 26
palabras subrayadas son las que se han identificado como acrónimos. En la parte
inferior se encuentra la lista de acrónimos encontrados y las sugerencias de expansión.
La primera expansión (escrita en un color más claro) es la elegida por la aplicación.
En el listado 3.2 se muestra un detalle de la representación interna del informe,
con las anotaciones resultantes de aplicar la corrección ortográfica y la expansión de
acrónimos.
1
2
3
4 TSH
5
6 y
7
8 T4
9
10
11 nirmales
12 normales
13 0.9
14
15 .
16
Listado de código 3.2: Representación interna de resultados de expansión de
acrónimos
3.3. Detección de negación
Esta fase se encarga de detectar qué frases dentro del texto del informe son negativas
o están negadas. También identifica el conjunto de tokens responsables de la negación
en la frase, además del ámbito o alcance de la misma.
De nuevo, la entrada de la fase es el texto original dividido en secciones y anotado
con los resultados de las fases anteriores. El contenido de cada sección se divide en
frases y para cada una de ellas se comprueba si contiene alguna palabra o expresión
3.3. Detección de negación 27
que denote negación y, por extensión, si la frase está negada o no. El ámbito de la
negación depende de la señal de negación encontrada.
En la figura 3.3 se muestra el resultado de aplicar la detección de negación sobre
un informe. En la parte superior se observa un fragmento del texto, donde las partes
subrayadas son ámbitos de negaciones. En la parte inferior se encuentra la lista de
negaciones encontradas. Para cada una de ellas se muestra el ámbito (scope) y la
señal de negación (cue).
Figura 3.3: Vista de la aplicación tras la detección de negación
En el listado 3.3 se muestra un detalle de la representación interna del informe, con
las anotaciones resultantes de aplicar la detección de negación y las fases anteriores.
1
2
3
4
5 VRS
6
7 :
8
9 negativo .
10
Listado de código 3.3: Representación interna de resultados de detección de negación
3.4. Identificación de conceptos 28
3.4. Identificación de conceptos
En esta última fase el objetivo es detectar y localizar en el texto conceptos o térmi-
nos médicos. Dichos conceptos objetivo están contenidos en la base de datos de la
aplicación. Para aumentar el rendimiento de las consultas se hace uso de la libreŕıa
de recuperación de información Apache Lucene.
De la misma manera que en el resto de partes del procesamiento, se recibe el
informe original dividido en secciones y anotado con los resultados de las fases
anteriores. El contenido de cada sección se divide en frases y estas a su vez se dividen
en unidades más pequeñas, considerando separadores las comas, las disyunciones y
otros nexos.
Para cada una de estas ✭✭subfrases✮✮ se realiza una consulta a través de Lucene, que
devolverá los conceptos para los cuales se han encontrado coincidencias. Finalmente,
estos resultados se puntúan para elegir los conceptos más precisos y coherentes.
Figura 3.4: Vista de la aplicación tras la identificación de conceptos
En la figura 3.4 se muestra el resultado de aplicar la fase de identificación de concep-
tos sobre un informe. En la parte superior se puede observar un fragmento del texto.
En la parte inferior se encuentra la lista de conceptos encontrados, con información
adicional, como el identificador del concepto en la colección de términos SNOMED
CT y si está negado o afirmado.
3.4. Identificación de conceptos 29
En el listado 3.4 se muestra un detalle de la representación interna del informe,
con las anotaciones resultantes de aplicar la identificación de conceptos y las fases
anteriores.
1
2
3
4 En la ecocardiografı́a previa al alta se aprecia
5
6 peque~na fuga ( 2jets ) a través del parche de la
7
8 CIV
9
10 y
11
12 regurgitación
13
14 moderadade
15 moderada de
16 0.9
17
18 la
19
20 valvula
21 vá lvula
22 0.9333333333333333
23
24 del injerto
25
26 .
27
Listado de código 3.4: Representación interna de resultados de identificación de
conceptos
Además de este tipo de representación, se produce también otro tipo de salida que
contiene únicamente información sobre los conceptos. De esta manera se facilita la
3.4. Identificación de conceptos 30
carga de los resultados en otros sistemas, además de omitir los datos de carácter
personal que pueda contener el texto del informe.
En el listado 3.5 se presenta un detalle de la representación interna de los resultados
finales.
1
2 62944002
3 1
4 Virus de la hepatitis C (organismo)
5 antecedentes
6 410607006
7 negado
8
Listado de código 3.5: Representación interna de resultados finales
En la figura 3.5 se muestra la vista de resultados, en la que se presenta la información
obtenida en forma de tabla y se ofrece al usuario la posibilidad de ordenar y filtrar
las filas.
Figura 3.5: Vista de la aplicación mostrando los resultados finales
3.5. Anotación y evaluación 31
3.5. Anotación y evaluación
Para poder evaluar la eficacia de la aplicación se han desarrollado dos modos de uso
adicionales.
3.5.1. Evaluación
El evaluador permite comparar informes anotados por la aplicación con informes
anotados a mano por un usuario experto con el objetivo de dar una medida de la
eficacia del sistema. Para ello se utilizan principalmente las métricas de precision,
recall y F1 score.
En la figura 3.6 se muestra la interfaz del evaluador. En la parte superior se
muestra el texto de los dos informes: el procesado por la aplicación (izquierda) y el
anotado por el usuario (derecha). En la parte inferior se presentan los resultados de
la evaluación.
Figura 3.6: Vista del modo evaluador
3.5. Anotación y evaluación 32
3.5.2. Anotación
El propósito del anotador es facilitar la tarea de anotar informes, permitiendo añadir,
modificar y eliminar anotaciones a través de una interfaz, i.e. sin tener que editar
los ficheros a mano.
En la figura 3.7 se muestra un detalle de la interfaz del anotador. En la parte
superior se muestra el texto del informe, mientras que en la parte inferior se listan
las anotaciones. Clicando sobre palabras del texto, se pueden activar diálogos para
introducir la información de las anotaciones.
Figura 3.7: Detalle del modo anotador
Los detalles sobre el modo de uso del anotador se pueden consultar en la sección
A.3 del apéndice Manual.
Caṕıtulo 4
Fase de corrección ortográfica
La fase de corrección ortográfica es la primera de las fases del procesado. Su ob-
jetivo es detectar palabras mal escritas en el texto y corregirlas automáticamente.
Se trata de una tarea muy importante, ya que de ella depende en parte el correcto
funcionamiento de las siguientes. El resto de los módulos se basan en la búsqueda
de ciertas palabras y patrones en el texto, por lo que las faltas ortográficas pueden
influir negativamente en su eficacia.
La corrección ortográfica es un problema muy común, para el que se han desarro-
llado multitud de libreŕıas y aplicaciones. Tras informarnos acerca de las soluciones
existentes para este problema, decidimos que lo más apropiado era reutilizar alguna
de ellas. En concreto, hemos basado nuestro corrector en el módulo de corrección de
la herramienta AutoIndexer, que a su vez utiliza Hunspell, construido por el grupo
NIL de la Universidad Complutense de Madrid y sobre el que ya se discutió en el
caṕıtulo 2, Estado de la cuestión.
4.1. Resumen del proceso de corrección
Al comienzo de la fase de corrección, se recibe una estructura de datos que contiene
todo el texto a procesar, dividido en cuantas secciones tuviera el informe. Este texto
se trocea en tokens, y para cada uno de ellos se aplica el siguiente proceso:
Se busca el token en el diccionario de la aplicación.
33
4.2. Detección de errores y creación de sugerencias 34
Si se encuentra el token en el diccionario, se considera que la palabra está es-
crita correctamente, y se procede a aplicar el proceso sobre el siguiente token.
Si no se encuentra el token en el diccionario, se considera que la palabra con-
tiene errores de ortograf́ıa. En tal caso, la libreŕıa Hunspell sugiere una serie
de términos corregidos para reemplazar la palabra mal escrita.
Se puntúan las sugerencias obtenidas por Hunspell comparándolas con el token
original.
Si la puntuación de una sugerencia supera o iguala un determinado umbral,
entonces se considera que es la corrección adecuada. En caso de haber varias
sugerencias con puntuaciones superiores o iguales al umbral, se elige la de
mayor puntuación. Si todas las sugerencias tienen la misma puntuación, se
escoge la primera.
Si no existen sugerencias cuyas puntuaciones al menos igualen el umbral, en-
tonces no se descarta ninguna sugerencia como posible. Es decir, se considera
que todas las sugerencias son válidas, y no se realiza corrección automática.
Se añade una anotación en el texto recibido originalmente adjuntando al token
la corrección adecuada, o la lista de correcciones posibles, según el caso.
El valor de puntuación que se utiliza como umbral en el algoritmo se puede modificar
desde uno de los ficheros de configuración de la herramienta (ver apéndice B) y
deberá ser establecido emṕıricamente.
4.2. Detección de errores y creación de sugeren-
cias
Para comprobar qué palabras son incorrectas y obtener las posibles correcciones se
hace uso de parte del corrector ortográfico desarrollado en el proyecto AutoInde-
xer, que se menciona en el comienzo de este caṕıtulo, y del que se dio una breve
explicación en el caṕıtulo 2 (Estado de la cuestión).
4.3. Puntuación de las sugerencias 35
Hunspell hace uso de un diccionario para determinar si una palabra es correcta
o no. El diccionario utilizado en la aplicación es un diccionario común de español,
mejorado con palabras y acrónimos del ámbito médico.
En caso de no encontrar la palabra en el diccionario, se considera que existen
errores en su escritura y se procede a elaborar una lista de sugerencias para la
corrección de la palabra. Para derivar las posibles soluciones a partir del término
original, Hunspell elige aquellos vocablos para los que se minimice la distancia de
Levenshtein (ver caṕıtulo 2). También es capaz de hacer uso de reglas fonéticas y
de n-gramas para elegir las sugerencias, pero en nuestro caso no se utiliza dicha
funcionalidad.
En el caso de los n-gramas, se debe a que no se dispone de un corpus apropiado
del que extraer información estad́ıstica. Por su parte, en el caso de las reglas fonéti-
cas, śı se incluyeron y se pudo comprobar experimentalmente que daban lugar a
sugerencias mucho peores. Pese a la decisión de no tenerlas en cuenta en la creación
de posibles correcciones, las reglas fonéticas śı que son empleadas en el proceso de
puntuación de sugerencias, que se describe en la siguiente sección.
4.3. Puntuación de las sugerencias
Las sugerencias recibidas de la libreŕıa Hunspell no están ordenadas de ninguna ma-
nera, por lo que es necesario determinar su ✭✭calidad✮✮ comparándolas con la palabra
que originalmente se deseaba corregir. Las sugerencias se ordenan entonces de acuer-
do con esa puntuación, que representa el grado de similitud existente entre ellas y
la palabra original. Este grado de similitud se representa con un número del 0 al 1,
indicando una puntuación de 0 que las dos palabras no se parecen absolutamente en
nada y una puntuación de 1 que son el mismo término.
La puntuación de cada una de estas sugerencias del diccionario se calcula a par-
tir de la distancia entre dicha sugerencia y la palabra que se está procesando. En
concreto, consideramos que
si Distancia < 10 entonces Puntuación = 1−Distancia/10
si Distancia ≥ 10 entonces Puntuación = 0
4.3. Puntuación de las sugerencias 36
En cuanto a la distancia, se obtiene sumando tres medidas diferentes de distancia,
que ya fueron introducidas en el caṕıtulo 2. Los pesos que se asigna a cada una de
ellas se pueden modificar en los archivos de configuración de la herramienta (ver
apéndice B).
4.3.1. Distancia de Levenshtein
La distancia de Levenshtein se define como el mı́nimo número de operaciones ne-
cesarias para transformar una cadena en otra, siendo las operaciones posibles la
inserción, el borrado y la sustitución de un carácter. En la aplicación, se ha imple-
mentado mediante el algoritmo Wagner-Fischer (Wagner and Fischer [1974]), que se
basa en el principio de la programación dinámica.
Concretamente, comienza calculando la distancia entre los prefijos de menor lon-
gitud de las palabras, y progresivamente, calcula las distancias entre prefijos más
largos hasta llegar a las palabras completas, usando siempre en los cálculos las dis-
tancias obtenidas previamente.
4.3.2. Distancia de teclado
Denominamos distancia de teclado a la distancia entre los caracteres de la palabra
original y la sugerencia en un teclado con disposición QWERTY. Los teclados de
disposición QWERTY son los más comunes en la actualidad, y se llaman aśı por el
orden en que aparecen las letras en la fila superior: primero Q, luego W, etc. (ver
figura 4.1).
Para calcular esta distancia, es preciso alinear las palabras de tal forma que coin-
cidan el mayor número de caracteres de ambas. Es por ello que se hace uso del
algoritmo Needleman-Wunsch, que ya se introdujo en el caṕıtulo 2. Este algoritmo
maximiza la similitud entre dos secuencias, alineando sus caracteres de tal manera
que coincidan el mayor número de ellos que sean iguales. En caso de que las palabras
a comparar no sean de igual longitud, se introducen huecos.
Una vez que se han alineado las secuencias, se calcula la similitud sumando las
puntuaciones asociadas a cada par de caracteres, además de una penalización por
cada hueco que se haya debido introducir. En nuestro caso, la puntuación de cada
4.3. Puntuación de las sugerencias 37
Figura 4.1: Teclado QWERTY
par de caracteres es la distancia de Manhattan que existe entre ellos tras alinear las
teclas en una cuadŕıcula, y el coste de cada hueco es 1.
Figura 4.2: Distancia de teclado
Por ejemplo, si consideramos el término original ✭✭docio✮✮ y las sugerencias ✭✭socio✮✮
y ✭✭bocio✮✮, tenemos que la distancia de Levenshtein es 1 en ambos casos, por la
sustitución de la ✭✭d✮✮. Si solo se tiene dicha distancia en cuenta, las dos sugerencias
resultan igual de lógicas, o en otras palabras, la probabilidad de que una sea la
correcta es similar en los dos casos. Sin embargo, midiendo la distancia de teclado,
obtenemos 1 en el primer caso y 4 en el segundo (ver figura 4.2). Este resultado
apoya a la intuición de que la sugerencia más lógica es ✭✭socio✮✮, por la proximidad
de la ✭✭d✮✮ y la ✭✭s✮✮.
1Imagenes bajo licencias GNU Free Documentation License, Versión 1.2 o posterior
(http://commons.wikimedia.org/wiki/Commons:GNU_Free_Documentation_License_1.2)
y Creative Commons Attribution-Share Alike 3.0 Unported
(http://creativecommons.org/licenses/by-sa/3.0/deed.en). Basadas en imagen de Si-
mo Kaupinmäki (disponible en
http://commons.wikimedia.org/wiki/File:ISO_keyboard_%28105%29_QWERTY_UK.svg)
http://commons.wikimedia.org/wiki/Commons:GNU_Free_Documentation_License_1.2
http://creativecommons.org/licenses/by-sa/3.0/deed.en
http://commons.wikimedia.org/wiki/File:ISO_keyboard_%28105%29_QWERTY_UK.svg
4.3. Puntuación de las sugerencias 38
4.3.3. Distancia fonética
La distancia fonética entre la palabra original y la sugerencia se calcula comparando
sus pronunciaciones. Más concretamente, en la implementación se hace uso de una
adaptación al español del algoritmo Metaphone, ya mencionado en el caṕıtulo 2.
Este algoritmo utiliza en primer lugar un conjunto de reglas de pronunciación para
traducir las palabras que se desea comparar a otras que las representan fonéticamen-
te. Después, calcula la distancia de Levenshtein entre dichas palabras modificadas
para determinar cuánto difieren los términos en lo que a pronunciación se refiere.
Esta técnica resulta especialmente útil en los casos en los que el término original
es incorrecto pero tiene exactamente la misma pronunciación que la sugerencia.
Para ilustrar esto con un ejemplo, supongamos que se desea comparar las palabras
✭✭agugeta✮✮ y ✭✭agujeta✮✮. Si consideramos la distancia de Levenshtein, la diferencia
entre las dos cadenas es 1, correspondiente a la sustitución de la ✭✭g✮✮ por la ✭✭j✮✮. Sin
embargo, la distancia fonética es 0, ya que las dos se pronuncian de igual manera.
Concretamente, se consideran las siguientes reglas de pronunciación en la imple-
mentación del algoritmo:
C = Z, cuando van seguidas de E o I.
C = K, cuando van seguidas de A, O, U o cualquier otra consonante, menos
la C y la H.
G = J, cuando van seguidas de E o I.
Ll = Y.
B = V.
U = W.
X = S, cuando son la primera letra de la palabra.
QU = K.
Q = K, cuando van seguidas de cualquier letra, menos la U.
la H se omite.
Caṕıtulo 5
Fase de expansión de acrónimos
En el ámbito médico se utilizan gran cantidad de abreviaciones a la hora de redactar
informes. Estas abreviaturas en muchos casos no están homologadas y su significado
(forma expandida) puede variar en función del centro hospitalario donde se redacte
e incluso de las diferentes secciones dentro de un mismo centro.
Las abreviaciones son recursos para ahorrar tiempo y espacio en el lenguaje pero el
uso excesivo de estas genera dificultades a la hora de comprender los textos, siendo
un gran problema para los documentalistas médicos al tener que interpretar los
mismos. Para facilitar la interpretación y comprensión de textos médicos se utilizan
sistemas automáticos de detección y expansión de acrónimos1.
Por tanto, el objetivo de esta fase es detectar los acrónimos que hay en el texto y,
mediante un proceso de desambiguación, elegir la expansión más adecuada de cada
acrónimo según el contexto en el que se encuentre.
5.1. Detección de acrónimos
Para el proceso de detección decidimos emplear el mismo sistema que se utiliza en
AutoIndexer. Se divide el texto en palabras, se busca cada una de ellas en el lexicón
de acrónimos y si se encuentra es clasificada como acrónimo. AutoIndexer hace uso de
varios lexicones pero solamente uno de ellos se restringe al ámbito médico. Por tanto,
decidimos utilizar dicho lexicón de acrónimos médicos para que el resto no produjese
1Para abreviar utilizaremos la palabra acrónimo para referirnos también a siglas y abreviaturas
39
5.2. Desambiguación de acrónimos 40
ruido en el sistema. Este lexicón contaba con aproximadamente 1500 acrónimos pero
lo completamos utilizando el diccionario de siglas médicas del Ministerio de Sanidad
y Consumo2, superando la cifra de 3000 acrónimos.
5.2. Desambiguación de acrónimos
El proceso de desambiguación se presenta como una tarea compleja y costosa de
implementar, dado que ciertos estudios (Hongfang Liu [2002]) demuestran que el
81% de los acrónimos encontrados en los abstracts de MEDLINE son ambiguos,
teniendo una media de 16 posibles expansiones cada uno. Habitualmente, se emplean
algoritmos de aprendizaje máquina para desambiguar acrónimos, mediante los cuales
el sistema aprende los contextos en los que aparece cada expansión dentro de un
corpus (art́ıculos cient́ıficos de MEDLINE, por ejemplo), clasificando cada contexto
por la expansión a la que acompaña.
Figura 5.1: Diagrama de actividad de la desambiguación de acrónimos
Dado que no disponemos de un corpus de informes o art́ıculos médicos anotados
donde obtener los ejemplos de entrenamiento para el algoritmo, decidimos utilizar
como corpus SNOMED CT. En las descripciones de conceptos contenidas en SNO-
MED CT aparecen algunas de las formas expandidas de los acrónimos presentes en
2http://www.msc.es/estadEstudios/estadisticas/docs/diccionarioSiglasMedicas.pdf
http://www.msc.es/estadEstudios/estadisticas/docs/diccionarioSiglasMedicas.pdf
5.2. Desambiguación de acrónimos 41
los recursos de AutoIndexer. De dichas descripciones obtenemos los contextos de las
formas expandidas para usarlos como los ejemplos de entrenamiento del algoritmo.
Además, utilizamos el sistema de reglas de AutoIndexer para apoyar al método
anterior, que permite que un experto inserte reglas de desambiguación, por las cuales
un acrónimo se puede expandir directamente con una expansión concreta.
El proceso de desambiguación se representa en el diagrama de la figura 5.1.
5.2.1. Sistema de reglas
Dado que en las descripciones de SNOMED CT no aparecen muchos acrónimos de
nuestro lexicón, decidimos utilizar un sistema de reglas para apoyar al método de
aprendizaje. Las reglas deben ser establecidas por un experto para mejorar la eficacia
del sistema a la hora de desambiguar los acrónimos detectados.
Las reglas que el sistema utiliza son de la forma
IF AND =
THEN < expansión>
El significado de cada acrónimo suele depender del contexto en el que aparece, por
tanto la condición lógica de la regla se refiere a los contextos de los acrónimos.
Además, para que una regla se aplique, se tiene que cumplir que la sección del
informe en la que se encuentra el acrónimo coincida con la sección especificada en
la regla. En la tabla 5.1 se muestran los tipos de expresiones lógicas que se pueden
utilizar.
El contexto CONTIENE ALGUNA palabra del conjunto {P1... Pn}
El contexto CONTIENE TODAS las palabras del conjunto {P1... Pn}
El contexto NO CONTIENE NINGUNA de las palabras del conjunto {P1... Pn}
Tabla 5.1: Expresiones lógicas a utilizar en las reglas.
Existen acrónimos que suelen ir acompañados por un número. Se puede añadir la
cadena de caracteres [numero] al contexto de la regla para indicar que el acrónimo
5.2. Desambiguación de acrónimos 42
ha de ir acompañado de cualquier número. Aśı, si el número puede tomar una amplio
rango de valores se evita tener que indicar todos los números en la regla.
Las reglas se almacenan en la base de datos de la aplicación y se pueden añadir,
editar y eliminar a través de un editor para facilitar al experto su gestión (ver figura
5.2).
Figura 5.2: Editor de reglas
5.2.2. Sistema de aprendizaje
El objetivo del sistema de aprendizaje consiste en aprender los contextos en los
que aparece cada acrónimo dentro de un corpus (SNOMED CT, en nuestro caso)
para luego, en cada ejecución, comparar el contexto en el que aparece el acrónimo
a desambiguar con los contextos aprendidos para ese acrónimo y elegir la expansión
adecuada.
En primer lugar, el sistema busca el acrónimo en el corpus y aprende el contexto
en el que aparece cada una de sus expansiones. Cabe decir que esta fase solamente
se realiza una vez para un corpus dado, ya que los resultados se almacenan en la
base de datos de la aplicación.
Esta tarea se realiza mediante un módulo espećıfico de aprendizaje. Como en
SNOMED CT no aparecen todos los acrónimos de la base de datos, el módulo de
aprendizaje se ha desarrollado de manera que se permita obtener nuevos contextos
de otros corpus de aprendizaje más completos.
5.2. Desambiguación de acrónimos 43
Una vez que el sistema ha aprendido los contextos, se compara el contexto del
acrónimo a desambiguar con los contextos aprendidos para ese acrónimo y, final-
mente, se selecciona la expansión con el contexto más similar al dado.
En el siguiente cuadro se muestra cual seŕıa el contexto de un acrónimo para una
frase dada.
Texto en el que aparece el acrónimo (PCR):
PCR en sangre para CMV; adenovirus: negativo.
Contexto del acrónimo (solamente palabras importantes):
[sangre, CMV, adenovirus, negativo]
Para realizar las comparaciones entre contextos utilizamos el modelo del espacio
vectorial. Este modelo se basa en la idea de que la relevancia de un conjunto de pa-
labras dentro de un documento puede ser calculada mediante la diferencia de ángulos
(usando el coseno de los ángulos) de los vectores de cada uno de los documentos
respecto del vector del conjunto de palabras inicial.
En nuestro caso, se crea un vector con las palabras de cada contexto aprendido
y otro con el contexto a comparar. Después, se calcula la distancia entre ellos y se
elige el contexto cuya distancia sea menor.
Como ejemplo, calculamos la distancia entre el contexto mostrado en el cuadro
anterior y dos de los contextos aprendidos.
Contexto del acrónimo a desambiguar:
[sangre, CMV, adenovirus, negativo]
Contextos aprendidos:
C1 (correspondiente con la expansión Reacción en cadena de la polime-
rasa”): [fingerprinting, detección, genética, ácido, Pneumocystis, genotipo,
positiva, negativa, humano, ribonucleico, digital, huella, aminotransferasa,
adenovirus, secuencia, detectada, observación, persistente, Dengue]
C2 (correspondiente con la expansión ”Protéına C reactiva”): [sustancia,
plasmática, determinación, normal, función, hallazgo, plasmático, reacción,
observable, medición, nivel]
5.2. Desambiguación de acrónimos 44
Para calcular el ángulo entre cada par de vectores se usa la siguiente ecuación:
cos Θ =
v1 · v2
‖v1‖‖v2‖
En el numerador tendremos el número de elementos comunes (dos palabras se consi-
deran comunes si comparten la misma ráız) en ambos vectores y en el denominador
el producto de las magnitudes de ambos vectores. Por tanto:
Distancia con C1:
cosΘ = 2
76
= 0,0263
Distancia con C2:
cosΘ = 0
44
= 0
Entonces, se seleccionaŕıa la expansión del contexto C2 ya que es la que nos pro-
porciona un valor del coseno del ángulo más cercano a 1 y, por tanto, una distancia
menor. Hay que destacar que, aunque se seleccione la expansión con el contexto
más parecido, decidimos que el sistema devuelva todas las expansiones posibles or-
denadas de menor a mayor distancia ya que el recurso del que fueron obtenidos los
contextos hace que los resultados no sean totalmente fiables.
Caṕıtulo 6
Fase de detección de negación
Esta fase se encarga de identificar qué frases dentro del texto del informe están
negadas. Además, su objetivo es definir el ámbito o alcance de la negación dentro
de cada una de esas frases. Esto se usará posteriormente para poder etiquetar los
conceptos médicos identificados como ✭✭afirmados✮✮ o ✭✭negados✮✮, según corresponda.
En la siguiente tabla se puede ver un ejemplo del resultado esperado de esta fase.
La segunda columna indica el cue, o señal de negación, que indica que la frase
contiene una negación. La tercera columna corresponde al ámbito o alcance de la
negación; es decir, la porción de frase cuyo significado está siendo negado.
Frase Señal de negación Ámbito
El paciente no tiene fiebre no tiene fiebre
Resultado de la prueba negativo negativo Resultado de la prueba
Tabla 6.1: Ejemplo de detección de negación.
6.1. El algoritmo NegEx
Este es el método de detección de negación que se ha adaptado para el proyecto.
NegEx es un algoritmo que fue creado para la detección de la negación en inglés.
Tras estudiarlo y ver que ya hab́ıan sido realizadas adaptaciones a otros idiomas
como el sueco (Skeppstedt [2011]), se decidió adaptarlo al castellano.
45
6.1. El algoritmo NegEx 46
Está basado en la detección de ciertos patrones o triggers mediante expresiones
regulares. Se utilizan cuatro clases de triggers:
Pseudo-negación: Son patrones que parecen de negación, pero que en realidad no
niegan ninguna condición o concepto cĺınico. Cuando el algoritmo los encuen-
tra, salta hasta el siguiente término de negación.
Negación: Son términos que niegan condiciones cĺınicas que aparecen a continua-
ción en la frase.
Post-negación: Términos que indican negación hacia atrás en la frase, i.e. niegan
las palabras que los preceden.
Conjunciones: Conjunciones adversativas o locuciones que pueden anular o cortar
una negación. Se utilizan para acotar el ámbito de la negación dentro de una
frase.
Estos términos de negación se han adaptado al castellano a partir de los originales
en inglés encontrados en un proyecto de código abierto sobre NegEx1.
Algunos de los triggers del inglés no tienen correspondencia directa en castellano
y al contrario, hemos tenido que incluir locuciones habituales en castellano sin equi-
valente anglosajón. Todo este proceso de traducción y adaptación de patrones se ha
realizado mediante la experiencia, hasta conseguir un conjunto de ellos aceptable
en cuanto a resultados del algoritmo. En la siguiente tabla aparecen unos cuantos
ejemplos de los mismos.
Pseudo-negación Negación Post-negación Conjunciones
sin dificultad no presenta es negativo salvo
no solo sin signos dio negativo pero
no se conoce negativo para debe ser excluido como principio de
no aumenta descartando fue descartado/a no obstante
no hay cambios ausencia de es negativo a causa de
Tabla 6.2: Triggers de negación.
1https://code.google.com/p/negex/
https://code.google.com/p/negex/
6.1. El algoritmo NegEx 47
En total hemos obtenido la siguiente cantidad de triggers:
Pseudo-negación: 12.
Negación: 68.
Post-negación: 19.
Conjunciones: 49.
6.1.1. Descripción del algoritmo
Al comienzo de la fase, se recibe una estructura de datos que contiene todo el texto
a procesar, dividido en cuantas secciones tuviera el informe. Este texto se trocea en
frases y, para cada una de ellas, se buscan los triggers que contiene y se aplica el
siguiente proceso:
Ir al siguiente trigger en la frase (Neg1).
• Si Neg1 es de tipo Pseudo-Negación, saltar al siguiente trigger en la frase
• Si Neg1 es de tipo Negación: definir el alcance de Neg1 hacia adelante,
cortando dicho alcance al encontrar alguno de los siguientes:
◦ Un trigger de tipo Conjunción.
◦ Otro trigger de Negación o Pseudo-Negación.
◦ El final de la frase.
• Si Neg1 es un término de Post-Negación: definir el alcance hacia atrás
hasta el inicio de la frase.
Repetir por cada trigger que quede en la frase.
6.1.2. Expresiones regulares: ventajas e inconvenientes
El uso de este algoritmo, totalmente basado en expresiones regulares, comporta tanto
ventajas como inconvenientes.
Entre las primeras se encuentra la rapidez con la que se ejecutan, mayor que en
otras técnicas que acceden a bases de datos o parsean y etiquetan el texto, y que en
6.1. El algoritmo NegEx 48
nuestro caso hace que esta sea la tarea más rápida, en comparación con el resto de
fases.
Otro de los pros de este algoritmo es que se presta a ser mejorado de forma
sencilla mediante el uso de nuevos triggers. En este proyecto se ha construido un
conjunto básico de patrones, pero con tiempo y recursos podŕıa elaborarse una base
de patrones más completa. Concretamente, por estar el registro de los textos bastante
delimitado, se podŕıan añadir triggers espećıficos que proporcionen buenos resultados
para informes médicos.
En cuanto a los inconvenientes, surgen al considerar los errores que se producen en
la detección del ámbito. Por una parte, se ha de tener en cuenta que este algoritmo,
al igual que el resto de técnicas basadas en expresiones regulares, no considera
ni la sintaxis ni la semántica de las oraciones. Por tanto, ciertas construcciones
gramaticales resultan en una detección del ámbito poco precisa o errónea.
Por otra parte, la necesidad de contar con un splitter para obtener las frases que
componen el texto introduce otra posible fuente de errores. Habitualmente, los sen-
tence splitter son sencillos y bastante fiables; pero en ocasiones, como cualquier
herramienta de procesamiento del lenguaje natural, fallan y esto perjudica enorme-
mente el funcionamiento de NegEx al delimitar el ámbito de una negación.
Caṕıtulo 7
Fase de identificación de conceptos
En esta última fase, el objetivo es detectar y localizar en el texto conceptos o térmi-
nos médicos. Dichos conceptos objetivo están contenidos en una base de datos lla-
mada SNOMED CT.
Cabe recordar, que al llegar a este apartado en el procesado del informe, se tienen
ya ciertas anotaciones sobre el mismo, correspondientes a las diferentes salidas de
las anteriores fases.
7.1. La base de conocimiento SNOMED CT
SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms), es una
colección de términos médicos organizados sistemáticamente. Incluye definiciones,
términos, relaciones y sinónimos sobre enfermedades, procedimientos cĺınicos, mi-
croorganismos, śıntomas, sustancias y otros conceptos.
SNOMED CT incluye diversas tablas y subconjuntos diferentes, aśı como versiones
para diferentes lenguas.
7.1.1. Tablas de SNOMED CT utilizadas
Las tablas a continuación descritas corresponden a la Edición en Español de octu-
bre de 2011 y Edición Internacional de enero de 2012 publicadas en la web de la
Biblioteca Nacional de Medicina de EEUU (NLM).
49
7.1. La base de conocimiento SNOMED CT 50
7.1.1.1. Tabla de descripciones
Esta tabla contiene las diferentes descripciones o definiciones (suele haber más de
una) de cada uno de los conceptos médicos de SNOMED CT.
A continuación se muestra un ejemplo de varias entradas y sus campos más rele-
vantes.
ID Descripción Texto ID Concepto
898593010 infarto de miocardio (trastorno) 22298006
898592017 ataque al corazón 22298006
849160018 infarto de miocardio, cicatrizado 1755008
1000794015 angina preinfarto 64333001
Tabla 7.1: Ejemplo de las descripciones de SNOMED CT
ID Descripción: Identificador único asociado a cada entrada de la tabla.
Texto: Frase o enunciado que define el concepto médico identificado por el
contenido del campo ID Concepto.
ID Concepto: Número que identifica un concepto médico. Dicho concepto
puede tener varias descripciones sinónimas, como se puede apreciar en las dos
primeras filas del ejemplo.
7.1.1.2. Tabla de relaciones
Esta otra tabla (7.2) contiene entradas que relacionan pares de conceptos SNOMED
CT tales como los que aparecen en la columna ID Concepto de la tabla de des-
cripciones 7.1. Una columna de la tabla indica además el tipo de relación entre los
conceptos. Los tipos de relaciones son a su vez conceptos SNOMED (marcados como
conceptos especiales). Cabe destacar el concepto más importante, is a, el cual marca
relaciones de ✭✭supertipo-subtipo✮✮ o relaciones ✭✭padre-hijo✮✮, que constituyen la base
de las jerarqúıas de conceptos de SNOMED CT.
7.1. La base de conocimiento SNOMED CT 51
Ejemplo:
Fractura de hueso del tarso (trastorno). Se define como:
es un (is a) → fractura de pie (trastorno)
sitio del hallazgo → estructura ósea del tarso (estructura corporal)
morfoloǵıa asociada → fractura (anomaĺıa morfológica)
ID Rel. ID Concep. 1 Tipo de Rel. ID Concep. 2
85. . .
34. . .
33. . .
Tabla 7.2: Tabla ejemplo de relaciones SNOMED CT
7.1.2. Problemas con SNOMED CT
Además de las tablas descritas, SNOMED CT contiene otros recursos como tablas
espećıficas para las búsquedas y las consultas, tablas de equivalencias entre palabras
y más. Por desgracia, este tipo de recursos de momento solo se hallan disponibles
para el idioma inglés.
Otro de los inconvenientes que surgen al trabajar con SNOMED CT es la enorme
cantidad de ramas y conceptos que engloba (ver tabla 7.3). Todos estos conceptos
pueden ser interesantes al definir un concepto médico, pero a la hora de localizar
conceptos en un informe, es posible que no se desee hallar ciertos términos per-
tenecientes a algunas de estas jerarqúıas (por ejemplo: ✭✭localización geográfica✮✮ o
✭✭animales✮✮).
El filtrado de estos conceptos implica realizar un procesamiento extra, ya que en prin-
cipio hay que recorrer las relaciones hasta alcanzar uno de los conceptos ✭✭ancestros✮✮
que se corresponden con cada una de las jerarqúıas referidas arriba.
Para facilitar dicha tarea, se ha realizado una búsqueda del concepto ✭✭ancestro✮✮
para cada concepto de SNOMED CT, almacenandolo en una nueva base de datos,
en la que a su vez se almacena la descripción canónica en castellano del concepto.
7.2. Procedimiento utilizado 52
Conceptos superiores
Fuerza f́ısica
Procedimiento
Evento
Entidad observable
Ambiente o localización geográfica
Estructura corporal
Contexto social
Organismo
Situación con contexto expĺıcito
Sustancia
Estadificaciones y escalas
Producto farmacéutico/biológico
Objeto f́ısico
Espécimen
Calificador
Concepto especial
Elemento de registro
Hallazgo cĺınico
Concepto de enlace
Tabla 7.3: Jerarqúıas de SNOMED CT
Con esta nueva tabla (7.4) se puede saber a partir de un identificador de concepto,
a qué jerarqúıa pertenece y su descripción textual en castellano.
ID Concep. FSN (Nombre completamente especificado) Tipo (ID de ancestro)
29. . . Bajo peso corporal
34. . . Enalapril
52. . . Intubación
Tabla 7.4: Ejemplo de conceptos en tabla propia
7.2. Procedimiento utilizado
En esta sección se describe el método usado en esta fase del procesado del informe
para conseguir la identificación y localización de los conceptos médicos mencionados
en el texto del documento.
7.2. Procedimiento utilizado 53
El objetivo principal consiste en poder hallar en el texto apariciones de concep-
tos de SNOMED CT, lo más precisos y relevantes que sea posible atendiendo al
contenido del informe. Nuestro enfoque para lograrlo consiste en intentar hacer un
encaje o ✭✭matching✮✮ entre el texto y los conceptos o, más concretamente, las des-
cripciones que conforman la tabla de descripciones de SNOMED CT mencionada
anteriormente (7.1).
Por cuestiones prácticas y de eficiencia, hemos indexado el contenido de la tabla de
descripciones de SNOMED CT mediante la libreŕıa Apache Lucene. En las siguientes
secciones se explica el uso de dicha libreŕıa, los resultados obtenidos y los métodos
y técnicas empleados para mejorar y filtrar dichos resultados.
7.2.1. Indexación de descripciones mediante Lucene
Lucene1 es una libreŕıa de código abierto para la recuperación de información. Su
principal función consiste en estructurar la información a recuperar -normalmente
texto- en forma de documentos indexados para, posteriormente, poder realizar búsque-
das eficientes sobre dicho texto. Cabe decir que, pese a su nombre, Lucene no crea
realmente documentos en el sentido habitual de la palabra, sino estructuras de datos
optimizadas para la recuperación de información.
Para nuestra misión se crea un documento por cada entrada de la tabla de des-
cripciones o, lo que es lo mismo, por cada una de las diferentes definiciones distintas
que existen en SNOMED CT. La creación de los documentos indexados no es direc-
ta: primero es necesario preprocesar estas definiciones, con el propósito de hacerlas
más generales y aumentar las posibilidades de encaje, respetando en lo posible el
contenido original.
En primer lugar, se eliminan las palabras que no aportan significado o son muy
comunes, conocidas en el ámbito del PLN como stop words. La lista de stop words
a eliminar que se ha utilizado se basa casi en su totalidad en la del proyecto open
source Snowball2, dedicado al desarrollo de stemmers.
1http://lucene.apache.org/core/
2http://snowball.tartarus.org/algorithms/spanish/stop.txt
http://lucene.apache.org/core/
http://snowball.tartarus.org/algorithms/spanish/stop.txt
7.2. Procedimiento utilizado 54
Después, se aplica a los términos restantes un stemmer para español, incluido en
la propia libreŕıa Lucene. Un stemmer es un sistema que reduce palabras a su ráız
o lexema, p. ej.: el lexema de ✭✭pato✮✮ es ✭✭pat-✮✮ y el de ✭✭liberación✮✮ es ✭✭liber-✮✮.
De esta manera se reducen las definiciones de los conceptos a una representación
de menor tamaño que descarta lo superfluo y conserva el significado esencial, con lo
que se logra encontrar coincidencias con un mayor número de textos.
7.2.2. Del contenido del informe a búsquedas en Lucene
Una vez creado el ı́ndice de documentos, el siguiente paso es crear una query, i.e.
una consulta, que contiene la información que se desea recuperar, la cual Lucene
interpreta y para la que devuelve ciertos resultados. En nuestro caso dicha query
es puramente textual y Lucene devuelve resultados basándose en la similitud entre
el texto de la query y el texto de los documentos (descripciones de conceptos de
SNOMED CT).
Con la query ya construida, Lucene ejecuta su algoritmo de búsqueda y devuelve
los resultados. Al tratarse de búsquedas basadas en la similitud entre textos, Lucene
puede devolver miles de resultados en la mayoŕıa de los casos. Dichos resultados son
devueltos siempre en orden de relevancia (i.e. similitud).
Ej: Para la query ✭✭El recién nacido fue ingresado✮✮, Lucene puede devolver:
- Recién nacido.
- Recién nacido prematuro.
- Ingreso del paciente.
- . . .
En una primera versión, cada query era creada simplemente a partir de las frases del
informe, utilizando el mismo filtrado de stop words y el stemmer que en la creación
del ı́ndice.
El principal problema de usar frases completas es que estas contienen normalmen-
te más de un término médico. Se observó que con frases largas la mayor cantidad
de palabras empeoraba los resultados de Lucene, devolviendo documentos impreci-
sos o erróneos. Además, atendiendo únicamente al orden devuelto por Lucene, es
imposible saber si hay uno o varios conceptos correctos en la lista de resultados.
7.2. Procedimiento utilizado 55
Por tanto, se decidió a ráız de lo anterior el uso de ciertas palabras como sepa-
radores (nexos, disyunciones, comas. . . ) para dividir las frases en enunciados más
pequeños, aumentando aśı el número de búsquedas en Lucene, pero siendo los re-
sultados devueltos más precisos.
7.2.3. Procesamiento de los resultados
Tal y como se ha dicho, Lucene devuelve N resultados ordenados por relevancia
(siendo N arbitrariamente grande). Esto presenta las siguientes cuestiones.
1. Se obtienen coincidencias con documentos (descripciones de conceptos) erróneas
o imprecisas.
2. En casi la totalidad de los casos se obtiene una gran cantidad de resultados.
Po