graduado en ingeniería informáticaoa.upm.es/43499/1/tfg_jorge_gonzalez_valencia_a.pdfrequeriría...

MADRID, JUNIO 2016

Graduado en Ingeniería Informática

Universidad Politécnica de Madrid

Escuela Técnica Superior de Ingenieros Informáticos

TRABAJO FIN DE GRADO

Normalización de conceptos clínicos presentes en criterios de elegibilidad de ensayos clínicos

Autor: Jorge González Valencia

Director: David Pérez del Rey


i Escuela Técnica Superior de Ingenieros Informáticos. Universidad Politécnica de Madrid


ii Escuela Técnica Superior de Ingenieros Informáticos. Universidad Politécnica de Madrid

Resumen Para el avance en la práctica clínica, la realización de ensayos clínicos para comprobar la eficacia

de nuevos fármacos y procedimientos terapéuticos resulta fundamental. La selección de pacientes es un proceso costoso en tiempo y esfuerzo, dada la necesidad de comprobar detalladamente las características de los pacientes y las condiciones de realización de los ensayos clínicos. Estas condiciones, conocidas también como criterios de elegibilidad, se expresan como datos desestructurados en forma de lenguaje natural. Automatizar este proceso de selección de pacientes requeriría estructurar la información contenida en los criterios y hacerla manejable para las máquinas. Para ello se utilizan técnicas de procesamiento de lenguaje natural y terminologías clínicas estándar que expresan la semántica de los criterios en un formato estructurado a través de códigos.

En este trabajo se realiza un estudio del impacto del mecanismo de normalización de la terminología clínica SNOMED-CT sobre la información contenida en los criterios de elegibilidad de ensayos clínicos publicados en clinicaltrials.gov. Para ello se desarrolla una herramienta que identifica y extrae un subconjunto de la semántica contenida en los criterios de elegibilidad de estos ensayos clínicos, asociandola a conceptos de la terminología clínica SNOMED-CT. Junto a esta herramienta, también se implementa una aplicación web para visualizar la información resultante del procesamiento de los ensayos. Realizando un análisis de los resultados del procesamiento de un conjunto de 300 ensayos clínicos sobre cáncer de mama, se ha observado como el proceso de normalización tiene un impacto en la cantidad y variedad de conceptos que representan parte de la información de los criterios. A la vista de estos resultados, aplicando el mecanismo de normalización se aumentaría la eficiencia en la comprobación automática de las características de un paciente y los criterios de elegibilidad, expresados como información estructurada en forma de expresiones de SNOMED-CT.


iii Escuela Técnica Superior de Ingenieros Informáticos. Universidad Politécnica de Madrid

Abstract To advance in the clinical practice, conducting clinical trials is essential to test the efficacy of

new drugs and therapeutic procedures. The patient selection process is costly in time and effort, given the need to check in detail the characteristics of patients and the clinical trial conditions. These conditions, also known as eligibility criteria, are expressed as unstructured data in natural language. Therefore, automation of this patient selection process would require to structure the information present in the criteria and making this information manageable by computers. Natural language processing techniques and standardized clinical terminologies are used to express the semantics of the criteria in a structured format using codes.

In this bachelor’s final dissertation, a study of the impact of the clinical terminology SNOMED-CT normalization mechanism applied over the information present in the eligibility criteria of clinical trials, which are published in the clinicaltrials.gov platform, is performed. In order to achieve that goal, a tool was developed to identify and extract a subset of the semantics present in the eligibility criteria of these clinical trials, associating it to concepts of the SNOMED-CT terminology. Along with this tool, a web application is also implemented to display the results of the clinical trials processing. Conducting an analysis of the results generated at the processing of a set of 300 clinical trials related to breast cancer, an impact on the quantity and diversity of the concepts that represent a subset of the information present in the eligibility criteria can be observed after performing the normalization process. In the view of these results, applying the normalization mechanism would increase efficiency in automatic checking of the characteristics of a patient and the eligibility criteria, both expressed as structured information in the form of SNOMED-CT expressions.


iv Escuela Técnica Superior de Ingenieros Informáticos. Universidad Politécnica de Madrid

Índice de contenidos 1. Introducción ............................................................................................................................... 8

1.1. Contexto del trabajo .............................................................................................................................................................. 8

1.2. Objetivos .......................................................................................................................................................................................... 9

1.3. Solución propuesta................................................................................................................................................................. 9

2. Estado de la cuestión ........................................................................................................... 10

2.1. Terminologías clínicas ..................................................................................................................................................... 10 2.1.1. Systematized Nomenclature of Medicine - Clinical Terms ......................................................................................... 11 2.1.2. UMLS Metathesaurus ................................................................................................................................................................................... 17

2.2. ClinicalTrials.gov................................................................................................................................................................... 19 2.2.1. Acceso programático y formatos disponibles ........................................................................................................................ 20

2.3. Procesamiento de Lenguaje Natural y Extracción de Información .......................................... 22 2.3.1. Natural Language Processing ............................................................................................................................................................... 22 2.3.2. Extracción de información....................................................................................................................................................................... 22

2.4. Anotadores de textos clínicos .................................................................................................................................... 23

3. Desarrollo ................................................................................................................................. 25

3.1. Descripción del sistema .................................................................................................................................................. 25

3.2. Diseño e implementación del sistema ............................................................................................................... 26 3.2.1. Eligibility Criteria Concepts Extraction Tool (ECCET) .................................................................................................... 26 3.2.2. Aplicación web para visualización y análisis de los datos............................................................................................ 39 3.2.3. Modelo de datos ................................................................................................................................................................................................ 55 3.2.4. Tecnologías y herramientas empleadas ..................................................................................................................................... 56

3.3. Evaluación del impacto de la normalización sobre los conceptos extraídos ................... 59 3.3.1. Conjunto de datos seleccionado ......................................................................................................................................................... 59 3.3.2. Resultados de la evaluación .................................................................................................................................................................... 59

4. Conclusiones y líneas futuras .......................................................................................... 62

4.1. Conclusiones ............................................................................................................................................................................ 62

4.2. Líneas futuras ......................................................................................................................................................................... 63

Anexos ............................................................................................................................................ 64

A. Despliegue de la aplicación y requisitos del entorno ................................................................................ 64


v Escuela Técnica Superior de Ingenieros Informáticos. Universidad Politécnica de Madrid

B. Conceptos filtrados manualmente ........................................................................................................................... 67

Bibliografía ................................................................................................................................... 68


vi Escuela Técnica Superior de Ingenieros Informáticos. Universidad Politécnica de Madrid

Índice de Figuras Figura 1 - Metodología a seguir .................................................................................................................................................................................................. 9 Figura 2 - Ejemplo de conceptos ............................................................................................................................................................................................ 12 Figura 3 - Ejemplo de descripciones asociadas a un concepto ................................................................................................................... 12 Figura 4 - Ejemplo que ilustra la estructura jerárquica de SNOMED CT ........................................................................................... 12 Figura 5 - Ejemplo de relación de subtipo ..................................................................................................................................................................... 13 Figura 6 - Ejemplo de relación de atributo .................................................................................................................................................................... 13 Figura 7 - Ejemplo de relaciones no válidas ................................................................................................................................................................. 13 Figura 8 - Ejemplo de concepto totalmente definido .......................................................................................................................................... 14 Figura 9 - Ejemplo de concepto subtipo de un concepto totalmente definido ............................................................................. 14 Figura 10 - Ejemplo de conceptos primitivos ............................................................................................................................................................. 15 Figura 11 - Ejemplo de expresión pre-coordinada ............................................................................................................................................... 15 Figura 12 - Ejemplo de expresión post-coordinada ............................................................................................................................................. 15 Figura 13 - Forma normal de SNOMED CT .................................................................................................................................................................. 16 Figura 14 - Ejemplo de la forma normal larga (izq.) y corta (der.) ........................................................................................................... 17 Figura 15 - Ejemplo de concepto del Metathesaurus .......................................................................................................................................... 18 Figura 16 - Ensayo clínico de CT.gov .................................................................................................................................................................................. 19 Figura 17 - Criterios de elegibilidad ..................................................................................................................................................................................... 20 Figura 18 - Formato XML ............................................................................................................................................................................................................. 21 Figura 19 - Formato HTML ......................................................................................................................................................................................................... 21 Figura 20 - Arquitectura de ECCET ..................................................................................................................................................................................... 26 Figura 21 - Flujo de ejecución ................................................................................................................................................................................................... 27 Figura 22 - Módulo de descarga ............................................................................................................................................................................................. 28 Figura 23 - Módulo de pre-procesamiento .................................................................................................................................................................. 29 Figura 24 - Módulo de extracción ......................................................................................................................................................................................... 30 Figura 25 - Módulo de persistencia ..................................................................................................................................................................................... 31 Figura 26 - Flujo de ejecución de MetaMap.................................................................................................................................................................. 33 Figura 27 - Ejemplo de output de MetaMap ................................................................................................................................................................ 34 Figura 28 – Formato de líneas de configuración del fichero ......................................................................................................................... 35 Figura 29 - Diagrama de Pareto .............................................................................................................................................................................................. 35 Figura 30 - Formato del mensaje XML de petición ................................................................................................................................................ 37 Figura 31 - Ejemplo de respuesta del servicio ........................................................................................................................................................... 37 Figura 32 - Fichero de configuración ................................................................................................................................................................................. 38 Figura 33 - Arquitectura de la aplicación web ........................................................................................................................................................... 39 Figura 34 - Pantalla principal .................................................................................................................................................................................................... 49 Figura 35 – Sección de procesamiento de varios ensayos .............................................................................................................................. 49 Figura 36 - Pantalla de listado de ensayos ..................................................................................................................................................................... 50


vii Escuela Técnica Superior de Ingenieros Informáticos. Universidad Politécnica de Madrid

Figura 37 - Detalle de un ensayo ............................................................................................................................................................................................ 51 Figura 38 - Pantalla del listado de conceptos .............................................................................................................................................................. 52 Figura 39 - Pantalla de informe de frecuencias de aparición ....................................................................................................................... 53 Figura 40 - Detalle de las apariciones de un concepto ........................................................................................................................................ 54 Figura 41 - Modelo de datos del sistema ........................................................................................................................................................................ 55 Figura 42 - Distribución de las jerarquías de SNOMED-CT de conceptos no normalizados ........................................... 59 Figura 43 - Frecuencia de los conceptos no normalizados ............................................................................................................................ 60 Figura 44 - Distribución de las jerarquías de SNOMED-CT de conceptos normalizados ................................................... 60 Figura 45 - Frecuencia de los conceptos normalizados .................................................................................................................................... 61 Figura 46 - Estructura de directorios de la aplicación......................................................................................................................................... 64


8 Escuela Técnica Superior de Ingenieros Informáticos. Universidad Politécnica de Madrid

1. INTRODUCCIÓN En este capítulo se pretende hacer una breve introducción a la temática y contenido del trabajo, los objetivos propuestos para el mismo y la solución propuesta a la problemática planteada.

1.1. Contexto del trabajo Los ensayos clínicos son evaluaciones experimentales que tienen como propósito comprobar la

validez de nuevos fármacos y técnicas terapéuticas sobre pacientes voluntarios. Para cumplir con los requisitos de los experimentos y que éstos se ajusten a las hipótesis que tratan de demostrar, los pacientes deben de cumplir una serie de condiciones conocidas como criterios de elegibilidad. Dichos criterios vienen expresados en formato de lenguaje natural, provocando que la evaluación del cumplimiento de los mismos en los procesos de selección de pacientes tenga que hacerse de manera manual por parte de personal clínico especializado.

El presente trabajo fin de grado se enmarca dentro de la necesidad de analizar la información presente en los criterios de elegibilidad de ensayos clínicos publicados en la plataforma clinicaltrials.gov, con el objetivo de poder desarrollar aplicaciones que permitan reducir la carga manual a través de la automatización del proceso de selección de pacientes. A través del uso de herramientas y técnicas de procesamiento de lenguaje natural, en conjunción con terminologías clínicas estándar para codificar la información clínica presente en los criterios, se pretende hacer una primera aproximación a la formalización de manera automática de parte de la información contenida en ellos, codificándola en forma de conceptos y normalizándolos para facilitar su análisis.

Este trabajo parte del desarrollo previo llevado a cabo en la asignatura de Practicum en el Grupo de Informática Biomédica de la Universidad Politécnica de Madrid, perteneciente al Departamento de Inteligencia Artificial de la Escuela Técnica Superior de Ingenieros Informáticos. En dicho trabajo se planteó una solución para facilitar el análisis de la información presente en los criterios de elegibilidad de ensayos clínicos publicados en la plataforma clinicaltrials.gov. Más concretamente, se comenzó el desarrollo de una primera versión de una herramienta, a la que nos referiremos por el nombre de ECCET (Eligibility Criteria Concepts Extractor Tool), cuya función principal es automatizar la extracción de la información presente en los criterios de elegibilidad, codificarla en forma de conceptos de una ontología, y almacenarlos para poder realizar análisis posteriores.



1.2. Objetivos Los objetivos de este proyecto de fin de grado se centran en la continuación de este trabajo

previo. En concreto, los objetivos del trabajo se pueden detallar en los siguientes puntos:

1. Mejorar el proceso de extracción de conceptos clínicos de la herramienta ECCET, aplicando un refinamiento sobre los conceptos devueltos por la misma.

2. Integrar el mecanismo de normalización de la terminología clínica SNOMED-CT en la herramienta ECCET.

3. Seleccionar y procesar un conjunto de datos (ensayos clínicos) con la herramienta ECCET, y evaluar el desempeño de la herramienta en dicho proceso, realizando un análisis del impacto de la normalización en los conceptos devueltos.

4. Adicionalmente, integrar la herramienta ECCET con una aplicación web que ofrezca una interfaz para poder procesar ensayos clínicos de clinicaltrials.gov específicos y facilitar la visualización y análisis de los mismos.

En definitiva, estos objetivos están orientados a finalizar el desarrollo de la herramienta ECCET dotándole de nueva funcionalidad, a proporcionar una interfaz que permita realizar consultas sobre la información extraída de los criterios de elegibilidad y a realizar una evaluación del impacto del mecanismo de normalización de SNOMED-CT sobre esta información.

1.3. Solución propuesta Para cumplir con los objetivos generales del trabajo, se propone la siguiente metodología:

Figura 1 - Metodología a seguir

Selección y procesamiento de un conjunto

de ensayos

Análisis y filtrado manual

Integración de normalización

Desarrollo de la aplicación

de visualización

Procesamiento de ensayos

con normalización

Evaluación del impacto de la normalización



2. ESTADO DE LA CUESTIÓN En este segundo capítulo se describe el estado del arte de la temática en la que se enmarca el trabajo.

A lo largo de los últimos años, los avances en la informática han facilitado la adquisición y recopilación de grandes cantidades de datos [1]. Explotarlos y utilizarlos es sin embargo una labor compleja. Su naturaleza comúnmente heterogénea, compleja y desestructurada supone grandes retos a la hora de exprimir todo su potencial, dada la dificultad de procesarlos y analizarlos.

El análisis de datos es la disciplina que se dedica a desarrollar técnicas para lidiar con esta problemática en los ámbitos de la ciencia, los negocios y las ciencias sociales. Múltiples campos de las ciencias de la información como el procesamiento de lenguaje natural, la minería de datos, la extracción de información, el aprendizaje automático, el análisis estadístico… constituyen la base de sus avances. Profesionales de varias áreas del conocimiento (informáticos, matemáticos, lingüistas, etc…) están implicados en desarrollar nuevas técnicas que permitan transformar, procesar y analizar estas grandes masas de datos, lo que a veces dificulta la consecución de grandes avances, dadas las líneas de investigación independientes que acaban surgiendo [1].

En el área de la asistencia sanitaria, hospitales e instituciones implicadas en la provisión de cuidados clínicos han aprovechado estos avances para recopilar todo tipo de datos clínicos sobre pacientes desde diversas fuentes (notas clínicas, registros electrónicos, sensores, imágenes…) [1]. Lograr comprender y utilizar el conocimiento implícito en estos grandes conjuntos de datos puede dar cabida a nuevas aplicaciones (sistemas de monitorización continua de pacientes, modelos predictivos para detectar enfermedades anticipadamente, sistemas de soporte en el diagnóstico, etc.) que repercutan en una mejora significativa en la calidad de la sanidad.

2.1. Terminologías clínicas Las terminologías clínicas son estándares que agrupan un conjunto de términos estructurados y

normalizados, y que busca servir de instrumento para el registro de datos clínicos en formato electrónico. Las terminologías proporcionan precisión y consistencia en la representación de los datos clínicos y facilitan la interoperabilidad entre sistemas clínicos heterogéneos. Realizar esta codificación de los datos sirve por tanto para homogeneizar su interpretación, mejorar su disponibilidad, facilitar el intercambio de información clínica entre profesionales de la disciplina y, en definitiva, servir como base para desarrollar nuevas aplicaciones que mejoren su explotación, con el objetivo final de mejorar la calidad de los cuidados clínicos.



Existen multitud de terminologías, específicas para determinados dominios o con propósitos más genéricos. Algunas terminologías que cabe mencionar son ICD (International Classification of Diseases) para representación y clasificación de enfermedades; LOINC (Logical Observation Identifiers Names and Codes) para observaciones, pruebas y resultados de laboratorio; NCI Thesaurus (National Cancer Institute Thesaurus) para cuidados clínicos, labores de investigación y actividades administrativas; y SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms), de propósito general para codificar información clínica de múltiples dominios.

Para la realización de este trabajo se ha escogido utilizar SNOMED CT por su carácter genérico, la amplitud de conceptos que recoge, la expresividad que proporciona y su estructura formal. SNOMED CT es utilizado en más de 50 países y se encuentra disponible en múltiples idiomas, entre los que se encuentra el español.

2.1.1. Systematized Nomenclature of Medicine - Clinical Terms Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) es una terminología

clínica desarrollada, mantenida y promovida por la Internation Health Terminology Standards Develoment Organisation (IHTSDO). Su principal función es, como en todas las terminologías clínicas, proveer un mecanismo de representación de información clínica de forma estructurada y consistente a través de códigos. Con ello es posible capturar y almacenar información clínica automáticamente procesable y de mayor calidad, facilitando su manejo e interpretación [3] [4].

El contenido de SNOMED CT se presenta en forma de ontología, basándose en tres tipos de componentes principales: los conceptos, las descripciones y las relaciones [3].

Los componentes principales de SNOMED CT son los conceptos. Éstos están organizados en una estructura jerárquica a través de relaciones entre ellos, lo que proporciona un mecanismo de definición formal de los conceptos. Es decir, la semántica de los conceptos está definida por las relaciones que posee. Los conceptos se organizan de menor a mayor especificidad, partiendo de los “Top Level Hierarchy”, que constituyen las principales ramas de la taxonomía. Todos los conceptos están identificados por un código único y no reutilizable (en caso de la deprecación de un concepto, este se marca como no activo).



Figura 2 - Ejemplo de conceptos

Las descripciones son los componentes que proporcionan el significado de los conceptos en un lenguaje entendible por los seres humanos. Los conceptos se describen como códigos numéricos, por lo que es necesario dotarles de una descripción textual y entendible para poder trabajar con ellos. El desacoplamiento de las descripciones respecto a los conceptos permite asociar a cada uno de ellos múltiples descripciones (sinónimos) y poder expresar unívocamente una idea a través de distintas expresiones (e idiomas). Al igual que los conceptos, todas las descripciones tienen un identificador único asociado.

Figura 3 - Ejemplo de descripciones asociadas a un concepto

Por último, las relaciones representan el enlace entre dos conceptos. Estos componentes definen de una forma lógica la semántica de los conceptos, estructurándolos en una jerarquía en forma de árbol.

Figura 4 - Ejemplo que ilustra la estructura jerárquica de SNOMED CT



Las relaciones son unidireccionales y se dividen en dos tipos: relaciones de subtipo y relaciones de atributo.

Las relaciones de subtipo se representan con el concepto |is a| y enlazan los conceptos dentro de una misma jerarquía.

Figura 5 - Ejemplo de relación de subtipo

Las relaciones de atributo enlazan conceptos entre distintas ramas y se representan con conceptos específicos (llamados atributos) de acuerdo a la característica que se defina. Por ejemplo, para expresar que una patología se ha producido en un lugar específico del cuerpo se utilizaría el atributo |finding site|:

Figura 6 - Ejemplo de relación de atributo

Un punto a tener en cuenta es que un atributo puede enlazar conceptos de jerarquías concretas. El conjunto de conceptos que pueden servir como fuente de una relación se conoce como dominio, mientras que el conjunto de conceptos que pueden servir como valor de una relación se conoce como rango. Estas restricciones permiten asegurar la consistencia semántica en las definiciones de relaciones.

Figura 7 - Ejemplo de relaciones no válidas

Las relaciones juegan un papel fundamental en SNOMED CT. Dependiendo de las relaciones que tengan los conceptos se clasifican en dos tipos:



1. Conceptos totalmente definidos (fully defined). Estos conceptos se caracterizan por tener un conjunto de relaciones que permiten distinguir su significado de conceptos similares. Esto quiere decir que no hay ningún concepto que posea la misma combinación de relaciones.

Figura 8 - Ejemplo de concepto totalmente definido

Figura 9 - Ejemplo de concepto subtipo de un concepto totalmente definido

El concepto “malignant tumor of breast” (figura 6) es un concepto totalmente definido ya que no existe otro concepto en la taxonomía que posea la misma combinación de características. Los conceptos que compartan las mismas características como subconjunto de sus características serán subtipos de este concepto (figura 7).



2. Conceptos primitivos. Los conceptos primitivos, al contrario que los totalmente definidos, no se pueden diferenciar de otros conceptos similares únicamente a partir de sus relaciones.

Figura 10 - Ejemplo de conceptos primitivos

En el ejemplo de la figura 8, ambos conceptos son primitivos ya que no poseen un conjunto de características definitorias que distingan su significado de otros conceptos.

2.1.1.1. Expresiones La terminología de SNOMED CT proporciona a través de una gramática composicional de

expresiones una herramienta potente para representar frases clínicas, incluso cuando no existe un concepto definido en la taxonomía que exprese la misma información [3] [5].

Las expresiones de SNOMED CT se dividen en dos tipos: las expresiones pre-coordinadas, representadas con los conceptos predefinidos en el propio vocabulario; y las expresiones post-coordinadas, que son las aquellas que incluyen más de un concepto predefinido.

Figura 11 - Ejemplo de expresión pre-coordinada

Figura 12 - Ejemplo de expresión post-coordinada



Una característica importante de las expresiones es que es posible representar el mismo conocimiento de diferentes formas. Por ejemplo, para la información expresada en la expresión de la figura 11 existe una expresión pre-coordinada (5913000| fracture of neck of femur |).

2.1.1.2. Forma normal de SNOMED CT Si bien las expresiones permiten procesar e interpretar la información clínica, la posibilidad de

representar la misma información de maneras distintas puede generar ambigüedad a la hora de interpretar consultas en sistemas que trabajen con información de registros clínicos. Para facilitar la tarea y mejorar la precisión con la que se trabaja con las expresiones, SNOMED CT provee de un mecanismo para transformar las expresiones a una forma normalizada denominada Normal Form o forma normal [5].

La forma normal se puede describir como la descomposición de un concepto en sus relaciones definitorias o de atributo, excluyendo las relaciones de subtipo (|is a|).

Figura 13 - Forma normal de SNOMED CT

La forma normal se genera de forma recursiva, aplicando el algoritmo de normalización a cada uno de los conceptos que constituyen la expresión. Existen dos modos de representar la forma normal: una manera larga (Long Normal Form) y una manera corta (Short Normal Form). La diferencia entre ambas es que la segunda forma sólo incluye las relaciones diferenciales del concepto, es decir, las relaciones que diferencian al concepto de otros conceptos similares.

Fully defined

Neoplasm of breast

126926005

Finding site 363698007

Breast structure 76752003

Primitive

Clinical stage finding

80631005 Associated

Morphology 116676008

Neoplasm 208369006



Figura 14 - Ejemplo de la forma normal larga (izq.) y corta (der.)

La Normal Form permite operar con las expresiones y la jerarquía de SNOMED CT, pudiendo comprobar si una expresión está contenida o no dentro de otra aplicando una serie de reglas.

2.1.2. UMLS Metathesaurus El Unified Medical Language System (UMLS) reúne un conjunto de recursos relacionados con

la salud y la biomedicina en forma de archivos y software. En ellos se proporcionan vocabularios, herramientas y estándares que buscan la interoperabilidad entre sistemas informáticos que trabajen con información sanitaria [6] [7].

Uno de los componentes que ofrece el UMLS es el Metathesaurus, una terminología que agrega términos, sinónimos, relaciones y códigos de múltiples vocabularios estándar como ICD-10, LOINC, MeSH o SNOMED CT. El Metathesaurus ofrece una estructura de mapping entre estos vocabularios, lo que permite traducir términos entre las distintas terminologías.

Los conceptos en el Metathesaurus están estructurados en cuatro niveles de especificación.

Primitive

Ibuprofen 800mg tablet

329708004

Has active ingredient 127489000

Ibuprofen 387207008

Primitive


329708004 Has dose form 411116001

Oral tablet 421026006

Primitive


329654002

Has active ingredient 127489000

Ibuprofen 387207008

Has dose form 411116001

Oral tablet 421026006

Primitive


329654002



Figura 15 - Ejemplo de concepto del Metathesaurus

Todos los conceptos se identifican por un código denominado CUI (Concept Unique Identifier). Cada concepto puede tener asignados múltiples términos provenientes de distintos vocabularios. Para agrupar todas las variaciones léxicas de un mismo término se utiliza un identificador LUI (Lexical term Unique Identifier). Cada variación léxica tiene a su vez un identificador SUI (String Unique Identifier). Por último, a cada ocurrencia de un concepto en uno de los vocabularios fuente se le asigna un AUI (Atom Unique Identifier) [8].

A1412439 headaches (BI) S1459113 headaches

A2882189 Headache (SNOMED) A0066000 Headache (MeSH)

S0046854 Headache

C0018681 Headache

A1641293 Cranial Pain (MeSH) S1680378 Cranial Pain

A0418053 HEAD PAIN CEPHALGIA (DxP) S0375902 HEAD PAIN CEPHALGIA

L1406212 cranial pain

L0290366 cephalgia head pain

L0018681 headache



2.2. ClinicalTrials.gov ClinicalTrials.gov es un repositorio web de ensayos clínicos mantenido por la National Library

of Medicine de Estados Unidos, en National Institutes of Health. Se trata de la mayor base de datos de estudios clínicos existente, albergando más de 200.000 estudios en la actualidad.

Un ensayo clínico es una evaluación experimental de un producto, sustancia, medicamento, técnica diagnóstica o terapéutica que, en su aplicación a seres humanos, pretende valorar su eficacia y seguridad.

Figura 16 - Ensayo clínico de CT.gov

Los criterios de elegibilidad de los ensayos clínicos de clinicaltrials.gov se presentan en formato de texto libre:



Figura 17 - Criterios de elegibilidad

Los criterios de elegibilidad se dividen en dos tipos: los criterios de inclusión, que son las condiciones que el paciente debe de cumplir para poder participar en el ensayo; y los criterios de exclusión, que son las condiciones que el paciente no debe de cumplir.

2.2.1. Acceso programático y formatos disponibles Dado que clinicaltrials.gov no ofrece una API para acceder a los datos de los ensayos de manera

programática, el acceso al contenido de estos criterios de elegibilidad está limitado a dos formas:

1. A través del fichero XML del ensayo clínico:



Figura 18 - Formato XML

2. A través del contenido del DOM del HTML de la página del ensayo.

Figura 19 - Formato HTML



En ambos casos, cada alternativa ofrece una serie de ventajas e inconvenientes a la hora de extraer la información y procesarla. En el caso del formato XML, los criterios de elegibilidad se presentan en un único párrafo, lo que complica la identificación y separación de cada criterio. Por otro lado, en el formato HTML los criterios aparecen bien delimitados por sus etiquetas. Sin embargo, la falta de semántica y estructura definida del HTML hace difícil parsear de una manera genérica cualquier ensayo del repositorio.

2.3. Procesamiento de Lenguaje Natural y Extracción de Información

2.3.1. Natural Language Processing El procesamiento de lenguaje natural (en inglés Natural Language Processing, o más

comúnmente abreviado como NLP) es un área que emerge de las disciplinas de la lingüística y de las ciencias de la información, y que está dedicada al desarrollo y estudio de modelos matemáticos y computacionales que tratan de manejar y comprender el lenguaje humano [11]. Los objetivos generales del NLP se centran en la investigación de modelos teóricos del lenguaje humano para comprender de la forma más completa posible los detalles del lenguaje y así poder desarrollar soluciones desde un punto de vista computacional [2].

El área de NLP tiene gran influencia en distintas disciplinas, siendo la disciplina de medicina una de las que mayor beneficio obtiene, gracias al desarrollo de nuevas aplicaciones que automatizan la gestión de la información clínica o proporcionan apoyo en la toma de decisiones, entre otras. Uno de los mayores retos del procesamiento de información clínica es lidiar con el gran aumento de conocimiento disponible en los registros de salud electrónicos.

La investigación en el área de NLP para el dominio médico busca hacer a los ordenadores capaces de comprender texto clínico en formato libre para la extracción de información clínica [2]. Para lidiar con la naturaleza compleja del texto clínico, las técnicas existentes llevan a cabo un proceso de análisis en varias fases, donde se intenta manejar cada uno distintos niveles del lenguaje (léxico, sintáctico, semántico…) de manera independiente, integrando las distintas soluciones que atajan los problemas que emergen en cada nivel. Las fases más comunes son el análisis morfológico, análisis léxico, análisis sintáctico, análisis semántico y codificación de los datos [2].

2.3.2. Extracción de información La extracción de información (Information Extraction en inglés, IE abreviado) es un campo

especializado del NLP para la extracción de tipos de información predefinidos en textos escritos en lenguaje natural [2]. La IE se define como el proceso de descubrir y extraer conocimiento de texto desestructurado. Un sistema de extracción de información suele constar de distintas etapas de procesamiento que aplican distintas técnicas de NLP: tokenización, detección de límites de oraciones, análisis sintácticos, detección de entidades nombradas…, donde cada una de ellas se centra en resolver los problemas de cada nivel del lenguaje [12].



En el dominio médico la extracción de información implica resolver tareas como la identificación de términos médicos, la negación, presencia y severidad de los mismos, las relaciones entre las entidades y la codificación y asociación de estas entidades a ontologías específicas de términos clínicos [15]. Entre las técnicas utilizadas para la comprensión del lenguaje natural en este dominio, la extracción de entidades nombradas (Named Entity Recognition) es la más representativa.

2.3.2.1. Extracción de conceptos La extracción de conceptos de textos clínicos es un proceso que posibilita la compresión de la

información contenida en ellos. Mediante técnicas de NLP es posible, aunque complejo, reconocer y capturar la semántica contenida en los términos y frases dentro del texto, codificándola en forma de conceptos de una terminología. Automatizar el acceso a esta información adecuadamente estructurada y codificada posibilita el desarrollo de una amplia variedad de aplicaciones más precisas, eficaces e inteligentes, capaces de revolucionar los cuidados clínicos actuales al apoyar a los profesionales del dominio en sus necesidades de información y conocimiento.

Existen distintas aproximaciones para el reconocimiento de conceptos presentes en un texto clínico: búsqueda basada en diccionario, detección basada en reglas, métodos estadísticos, aprendizaje automático o por combinaciones de éstas. La identificación precisa de los conceptos requiere sin embargo comprender bien el contexto en el que se encuentra. Temporalidad, negación o el sujeto al que se aplica el concepto son algunas de las consideraciones a tener en cuenta para asegurar la identificación de la semántica correcta. Detectar y procesar toda esta información es uno de los grandes retos en el área de extracción de información de textos clínicos [12].

2.4. Anotadores de textos clínicos Para desarrollar nuevas técnicas en el campo de la minería de textos clínicos, disponer de textos

previamente anotados (corpus) que sirvan como base de entrenamiento para algoritmos de aprendizaje automático supone una labor costosa, tanto en tiempo como en esfuerzo. La obtención de textos clínicos adecuadamente anotados depende de que profesionales del dominio de la biomedicina apliquen sus conocimientos en la temática del texto e inviertan su tiempo en anotarlos de manera manual, muchas veces sin poseer de los conocimientos necesarios en cuanto a esquemas de anotación o de las herramientas informáticas implicadas.

Las herramientas anotadoras de textos clínicos son aquellas que buscan facilitar este proceso reduciendo la carga de trabajo a los profesionales del dominio, obteniendo anotaciones con un grado de fidelidad similar al obtenido en el proceso manual y ofreciendo un amplio abanico de opciones en cuanto a los formatos de los textos y anotaciones.

Dos ejemplos representativos de anotadores de textos clínicos son BioPortal [13] y MetaMap [14]:



1. BioPortal es un repositorio web que ofrece acceso a diferentes ontologías biomédicas a través de diversas herramientas en forma de servicios (búsqueda sobre ontologías, mapping entre conceptos, anotación de texto biomédico…).

2. MetaMap es una herramienta anotadora de textos clínicos desarrollada por Alan R. Aronson, de la National Library of Medicine de Estados Unidos. Se trata de un anotador altamente configurable, guiado por un algoritmo que aplica varias técnicas de procesamiento de lenguaje natural en conjunción con una gran base de datos de conceptos de los vocabularios del UMLS Metathesaurus para identificar conceptos biomédicos presentes en el texto de entrada.

Para llevar a cabo el proceso de anotación, estas herramientas tienen que solventar ciertos retos presentes en los textos clínicos que procesan [15]:

Documentos no estructurados ni estandarizados. La falta de una estructura fija en determinado tipo de documentos dificulta el análisis automático de los mismos, al tener cada uno distintas particularidades.

Vocabulario específico del dominio. Esto provoca que las técnicas de NLP tengan que ser adaptadas a este tipo de vocabulario, ya que las soluciones genéricas proporcionan poca eficacia.

Lenguaje agramatical. Gran parte del texto clínico proviene de anotaciones manuales del personal médico o de sistemas de reconocimiento de voz. Este tipo de fuentes suele proveer de faltas gramaticales por ausencia de completitud de las frases al ser acortadas.

Abreviaciones. La utilización de abreviaciones puede generar ambigüedad si se pueden expandir a diferentes términos, por lo que es necesario determinar el contexto para determinar el término correcto.

Polisemia y sinonimia. Es posible que haya determinados términos que puedan resolverse con distintos significados o que hayan ideas se puedan representar con distintos términos.



3. DESARROLLO En este capítulo se describe el sistema desarrollado, su arquitectura, la metodología seguida y las tecnologías utilizadas para su implementación.

3.1. Descripción del sistema El sistema desarrollado en el presente trabajo de fin de grado tiene como propósito principal

facilitar la labor de análisis de la información contenida en los criterios de elegibilidad de los ensayos clínicos publicados en la plataforma clinicaltrials.gov y facilitar la labor de evaluación del impacto de la normalización de SNOMED-CT sobre esta información.

La utilización de la herramienta se enmarca en el ámbito de la investigación en la disciplina de la bioinformática, más concretamente en la minería de datos y la extracción de información de textos clínicos. La herramienta está destinada por tanto a facilitar el análisis de la información presente en estos textos y a la generación de conocimiento útil que pueda ser utilizado para desarrollar aplicaciones que mejoren los procesos de selección de pacientes, entre otros.

El sistema está divido en dos componentes principales, cada uno de los cuales busca dar solución a un subconjunto de los requisitos planteados por el mismo. El primer componente se centra en el proceso de extracción de la información de los ensayos, mientras que el segundo componente está orientado a la representación gráfica de los datos extraídos.

El sistema debe cumplir con los siguientes requisitos generales:

a) Automatizar el acceso a los ensayos clínicos y a sus criterios de elegibilidad, además de otra información relevante del ensayo.

b) Detectar y extraer la información clínica contenida en el texto de los criterios de elegibilidad.

c) Asociar esta información a conceptos de la terminología clínica SNOMED-CT.

d) Normalizar los conceptos de SNOMED-CT extraídos de los criterios de elegibilidad.

e) Proporcionar una interfaz de visualización de los datos resultantes.

f) Proporcionar una interfaz que permita aplicar el proceso de extracción a ensayos clínicos arbitrarios y especificados por el usuario.

En las siguientes secciones se presenta la arquitectura de estos dos componentes que conforman el sistema y los requisitos que se encargan de implementar.



3.2. Diseño e implementación del sistema

3.2.1. Eligibility Criteria Concepts Extraction Tool (ECCET) La Eligibility Criteria Concepts Extraction Tool (de aquí en adelante ECCET) es una

herramienta o utilidad desarrollada en el Grupo de Informática Biomédica de la UPM. La herramienta ECCET constituye el primer componente del sistema y su función principal es automatizar la extracción de la información presente en los criterios de elegibilidad de ensayos clínicos alojados en la plataforma clinicaltrials.gov, codificarla en forma de conceptos de la ontología SNOMED CT, y almacenarlos para poder realizar análisis posteriores de esta información.

3.2.1.1. Arquitectura de la herramienta ECCET La arquitectura de la herramienta ECCET se divide en distintos módulos, como se muestra en la

Figura 20 - Arquitectura de ECCET.

Figura 20 - Arquitectura de ECCET

Módulo de descarga de ensayos clínicos

clinicaltrials.gov Ensayos

clínicos en XML

Módulo de pre-procesamiento

Módulo de extracción

Anotador

Desambiguador

MetaMap Server

Servidores auxiliares

Metamap API

Módulo de persistencia

CoreDataset SOAP Web Service

Eligibility Criteria Concepts Extraction Tool

BBDD de resultados



Los módulos que constituyen ECCET se detallan a continuación:

Módulo de descarga de los ensayos clínicos. Este primer módulo es el encargado de descargar los ensayos especificados por el usuario en formato XML de la plataforma clinicaltrials.gov.

Módulo de pre-procesamiento. Este segundo módulo se encarga de analizar y parsear la información contenida en los ficheros XML de los ensayos clínicos, estandarizar el formato de los datos y modelar los objetos necesarios a partir de esta información.

Módulo de extracción. El módulo de extracción constituye el componente central de la herramienta, y su función principal es la de procesar cada uno de los criterios de elegibilidad de los ensayos para reconocer e identificar las entidades presentes en el texto, para posteriormente mappear dichas entidades en conceptos clínicos de la terminología SNOMED-CT. Este módulo utiliza el anotador MetaMap para identificar y mappear los conceptos del texto.

Módulo de persistencia de los resultados. Este módulo es el encargado de almacenar las distintas entidades resultantes del proceso de extracción en una base de datos para su posterior consulta y análisis.

Figura 21 - Flujo de ejecución

1. Descarga del ensayo

2. Preprocesamiento y modelado a objetos

3. Extracción de conceptos4. Normalización

5. Persistencia



El flujo de ejecución de la herramienta ECCET es el descrito en la figura Figura 21 - Flujo de ejecución. En primer lugar se realiza la descarga de los ensayos a procesar en formato XML. Posteriormente se realiza un pre-procesamiento de los criterios de elegibilidad y se modela la información de los ensayos en objetos. A continuación, utilizando el anotador MetaMap, se extraen los conceptos del UMLS Metathesarus con sus respectivos CUI’s. Por último, se realiza un proceso de traducción de los CUI’s del Metathesaurus a los SCTID’s de SNOMED CT y se almacenan los conceptos y sus formas normales en una base de datos.

3.2.1.2. Diagramas de clases de ECCET Dada la magnitud de la herramienta, se procese a presentar el diagrama de clases fragmentado y

clasificado en los módulos descritos previamente.

3.2.1.2.1. Módulo de descarga de los ensayos clínicos

Figura 22 - Módulo de descarga

El módulo de descarga de ensayos se basa en 3 clases:

La clase CTManager es la encargada de realizar las peticiones contra la API de clinicaltrials.gov para realizar la descarga. Es también la clase encargada de almacenar los ficheros XML localmente en un directorio temporal.

Las clases SearchOptions y SearchOptionsBuilder son clases de utilidad que sirven para filtrar los ensayos clínicos a descargar en base a los parámetros que se especifiquen.



3.2.1.2.2. Módulo de pre-procesamiento

Figura 23 - Módulo de pre-procesamiento

El módulo de pre-procesamiento utiliza las clases ClinicalTrial, CriteriaSet y EligibilityCriteria para representar la información y modelar los ensayos y los criterios de elegibilidad. La clase Preprocessor es la encargada de estandarizar en medida de lo posible el bloque de texto que conforman los criterios de elegibilidad para posteriormente fragmentarlo en cada una de las frases que representan cada criterio. Por último, la clase ProcessingUnit es la encargada de construir el conjunto de objetos que representan cada criterio de elegibilidad a partir del objeto del ensayo clínico y servir de unidad principal del módulo de extracción.



3.2.1.2.3. Módulo de procesamiento, extracción y normalización

Figura 24 - Módulo de extracción

El proceso de extracción es llevado a cabo principalmente por las clases ProcessingUnit, ConceptExtractor y Match. Cada criterio de elegibilidad es procesado por el anotador de MetaMap, al que se le realizan las consultas a través de su API. El anotador genera un listado de coincidencias de los conceptos presentes en el texto de cada criterio, y cada una de estas coincidencias es modelada en objetos de la clase Match y Concept. Por último, la clase CoreDatasetServiceClient proporciona una interfaz del servicio web CoreDataset que es utilizado para llevar a cabo el proceso de normalización de cada concepto.



3.2.1.2.4. Módulo de persistencia

Figura 25 - Módulo de persistencia

Por último, en el módulo de persistencia, la clase principal DBManager es la encargada de gestionar el acceso a las diferentes bases de datos utilizadas por la herramienta (una base de datos del UMLS Metathesaurus, una base de datos de SNOMED-CT y la base de datos propia del sistema).



3.2.1.3. Interfaz de línea de comandos La herramienta ECCET ofrece una interfaz de línea de comandos para poder realizar distintas

operaciones. Las opciones disponibles son las siguientes:

Procesar un ensayo clínico, especificado por su identificador de clinicaltrials.gov:

o Ejemplo: ECCET –t NCT03201002

Procesar varios ensayos clínicos, especificados por sus identificadores separados por espacios:

o Ejemplo: ECCET –tl NCT03201002 NCT03206502 NCT01671002

Procesar los ensayos clínicos presentes en un directorio especificado (en formato XML)

o Ejemplo: ECCET –f /directorio/con/ensayos –o 0 –l 100

o Donde –f es el directorio, -o es el offset del directorio desde donde se comienzan a procesar los ensayos y –l es el límite máximo de ensayos a procesar.

3.2.1.4. Refinamiento de conceptos extraídos por ECCET Uno de los problemas que arrastraba la herramienta ECCET previo al comienzo del trabajo de

fin de grado era la calidad de los conceptos extraídos por la misma. Las razones eran principalmente dos: la capacidad del algoritmo utilizado por el anotador MetaMap y la falta de estandarización de los criterios de elegibilidad de los ensayos clínicos de clinicaltrials.gov

El anotador MetaMap es el principal encargado de realizar el proceso de detección y asociación de las entidades del texto a los conceptos clínicos de la terminología SNOMED-CT. El algoritmo en el que se basa MetaMap utiliza técnicas de procesamiento de lenguaje natural (segmentación y tokenización de las frases del texto, anotación con etiquetas semánticas sobre funciones del discurso, generación de variantes léxicas…) para seleccionar los conceptos candidatos presentes en el texto. Cada candidato es posteriormente evaluado a través de una función heurística que calcula un valor numérico, utilizado para determinar la fortaleza de los mapping generados.



Figura 26 - Flujo de ejecución de MetaMap

Si bien el algoritmo de MetaMap es capaz de detectar gran cantidad de conceptos con una precisión razonable, este presenta algunos problemas a la hora de anotar la información presente en una cadena de texto de entrada. Estos problemas son debidos principalmente a la complejidad asociada del área del procesamiento de lenguaje natural y a las técnicas utilizadas por la herramienta, que están fundamentalmente basadas en búsqueda por coincidencia de las variantes generadas de los términos en tablas ya generadas con las asociaciones palabra-concepto.

Por ejemplo, existen ocasiones en las que el anotador no es capaz de anotar correctamente conceptos con cierto grado de especificidad, dividiendo el concepto en múltiples subconceptos más genéricos. Si las descripciones de los conceptos de SNOMED-CT poseen diferencias con la expresión del concepto que aparece en el texto (orden de las palabras, palabras intercaladas…) el algoritmo de MetaMap no es capaz de asociar las palabras del texto con el concepto adecuado.

En otros casos, el anotador asocia conceptos correctamente pero estos proporcionan información poco útil o difícil de clasificar e interpretar, como es el caso de marcadores temporales o conectores semánticos.

Text: Histologically confirmed ductal carcinoma in situ (DCIS) or stage I breast cancer by stereotactic core or incisional biopsy Phrase: Histologically 1000 C0205462:Histologic [Functional Concept] Phrase: confirmed 1000 C0521093:Confirmed by [Qualitative Concept]



Phrase: ductal carcinoma in situ 1000 C0007124:Intraductal carcinoma, noninfiltrating (Noninfiltrating Intraductal Carcinoma) [Neoplastic Process] Phrase: or Phrase: stage I breast cancer by stereotactic core 612 C0441766:Stage level 1 [Intellectual Product] 778 C0678222:Carcinoma of breast NOS (Breast Carcinoma) [Neoplastic Process] 581 C0006539:Belorussia (Belarus) [Geographic Area] 581 C0729296:Stereotactic [Spatial Concept] 581 C0444669:Core [Spatial Concept] Phrase: or Phrase: incisional biopsy 1000 C0184922:Incisional biopsy - action [Diagnostic Procedure]

Figura 27 - Ejemplo de output de MetaMap

Por otro lado, la falta de estandarización de los criterios de elegibilidad se debe fundamentalmente a los siguientes casos:

Frases que comienzan por minúscula. Frases que no finalizan con un signo de puntuación adecuado. Símbolos como ≤ o ≥ que vienen ocasionalmente representados como imágenes. Expresiones matemáticas formuladas de manera informal e incorrecta. Utilización variante de índices numéricos, alfabéticos o viñetas para estructurar los

criterios. Categorización arbitraria de las secciones de los criterios de elegibilidad.

La carencia de homogeneidad en el formato en el que se presentan los criterios en cada ensayo no es el único problema. Los ficheros XML que contienen los datos de los ensayos clínicos presentan los criterios de elegibilidad como un bloque de texto único. Esto supone una dificultad añadida a la hora de segmentar el texto y analizarlo.

Dado que MetaMap supone una parte integral de la herramienta ECCET y el desarrollo de un algoritmo capaz de mejorar el comportamiento del utilizado por MetaMap no entraba dentro del ámbito del trabajo de fin de grado, las opciones para mejorar la calidad de los conceptos se reducían a dos: (1) pre-procesar el texto de entrada del anotador para mejorar su precisión y (2) filtrar los conceptos devueltos en la salida del anotador.

Por tanto, en primer lugar se procedió a realizar una labor de pre-procesamiento que preparase el texto que recibe como entrada el anotador. Para ello se utilizan expresiones regulares que tratan de solventar algunos de los problemas de estandarización presentados con anterioridad. Una vez realizadas estas transformaciones, utilizando la librería apache openNLP y su módulo de detección de oraciones, se intenta segmentar el bloque de texto de los criterios de elegibilidad en las oraciones que sirven de entrada para el anotador.



Por último, quedaba realizar un filtro de los conceptos devueltos, para lo que se siguieron varias alternativas que se detallan en las siguientes secciones.

3.2.1.4.1. Exclusiones Ad-hoc de MetaMap

A partir de la última versión publicada de MetaMap a fecha de hoy, MetaMap2016, se incluye una funcionalidad que permite excluir conceptos del proceso de mapping a través de un fichero de configuración, evitando tener que hacer tareas adicionales de post-procesamiento para eliminar conceptos de la salida de la herramienta. El fichero de configuración es un fichero de texto plano que con un formato simple, donde se especifican los códigos del Metathesaurus de los conceptos que se quieren excluir, y las cadenas de texto que pueden mappear a dicho concepto.

C0596170|BED C0270724|PLAN

Figura 28 – Formato de líneas de configuración del fichero

Como parte del proceso de filtrado, se utiliza esta funcionalidad de MetaMap con conceptos extraídos en la ejecución sobre los ensayos de prueba. Los conceptos resultantes más frecuentes fueron analizados manualmente para determinar qué conceptos eliminar. Para ello se realizó un análisis con el principio y diagrama de Pareto [16] para detectar los conceptos más representativos, y así poder reducir el conjunto de datos a analizar.

Figura 29 - Diagrama de Pareto

020406080100120

050

100150200250300350400450

Mal

igna

nt tu

mor

of…

Opr

elve

kin

(pro

duct

)Ev

alua

tion

proc

edur

e…O

ncog

ene

prot

ein…

Diag

nost

ic pr

oced

ure…

Cont

race

ptio

n (fi

ndin

g)In

fect

ious

dise

ase…

Imm

une…

Endo

crin

e th

erap

y…Un

ders

tand

ing,

…Bi

opsy

(pro

cedu

re)

Men

tal d

isord

er…

Hem

oglo

bin

(sub

stan

ce)

Prov

idin

g pr

esen

ce…

Seco

ndar

y m

alig

nant

…Al

l bon

e m

arro

w…

Rena

l fun

ctio

n…An

gina

dec

ubitu

s…Pl

atel

et (c

ell s

truc

ture

)Tr

achi

notu

s fal

catu

s…Ca

rcin

oma

of b

reas

t…Fa

mily

Urs

idae

…Liv

er fu

nctio

n…Ad

min

istra

tion…

Gene

tic m

utat

ion…

Cerv

ix u

teri

stru

ctur

e…Br

east

fed

(find

ing)

Non-

smal

l cel

l lun

g…Hy

pert

ensiv

e…O

ld-a

ge (f

indi

ng)

Tras

tuzu

mab

…W

ritin

g (o

bser

vabl

e…Co

nduc

tion

diso

rder

…Ec

hoca

rdio

grap

hy…

Análisis de frecuencias

FRECUENCY ACUMULATED %



3.2.1.4.2. Exclusión de jerarquías de SNOMED CT

Siguiendo la línea del proceso de filtrado para eliminar conceptos no válidos (en el sentido de la utilidad que proporcionan en el análisis), se decidió excluir determinadas ramas de la ontología de SNOMED-CT para poder abarcar mayor número de conceptos. Las ramas eliminadas son:

Attribute Contextual qualifier Qualifier value Environment Geographic location Person Severity modifier Core metadata concept Ethnic group Foundation metadata concept

La decisión de eliminar estas ramas de SNOMED-CT se justifica en un análisis manual de los conceptos más frecuentes, donde los conceptos pertenecientes a estas jerarquías se identificaban como conceptos no válidos o poco útiles para describir la información contenida en un criterio de elegibilidad.

Por otro lado, a través de un fichero de configuración es posible modificar estas ramas para ajustar el comportamiento de la herramienta a la hora de establecer los conceptos válidos o inválidos.

3.2.1.5. Integración del mecanismo de normalización Uno de los objetivos del trabajo era integrar el mecanismo de normalización de SNOMED-CT en

la herramienta para obtener la forma normal de los conceptos extraídos de los criterios de elegibilidad. Para ello existían varias posibilidades: implementar el algoritmo descrito en la especificación técnica del mecanismo de normalización de SNOMED-CT [5] publicada por la IHTSDO o utilizar algún servicio existente que implementase dicho algoritmo.

Dado que el foco del trabajo no era realizar una implementación del algoritmo, que sería capaz de abarcar la dedicación de otro trabajo de fin de grado, se decidió en última instancia utilizar un servicio web externo que ya implementase el algoritmo.

El servicio finalmente escogido fue CoreDatasetService, un servicio web SOAP perteneciente al Grupo de Informática Biomédica, Este servicio se aloja en uno de los servidores del grupo de investigación y ofrece, entre otras operaciones, la posibilidad de obtener la forma normal corta de un concepto especificando su código de SNOMED-CT.



Figura 30 - Formato del mensaje XML de petición

Figura 31 - Ejemplo de respuesta del servicio



Para la implementación del cliente del servicio web se utilizó la librería estándar JAX-WS y la herramienta wsimport para generar los ficheros necesarios para interactuar con el servicio.

3.2.1.6. Fichero de configuración Para modificar el comportamiento de la herramienta se pueden establecer distintos parámetros

en un fichero de configuración que sigue el formato estándar de los ficheros properties de Java [10]. Dicho fichero contiene los siguientes parámetros:

jdbc.driverClassName = com.mysql.jdbc.Driver jdbc.url = jdbc:mysql://localhost:3306/normdb jdbc.username = user jdbc.password = pass jdbc.snomedct = jdbc:mysql://localhost:3306/snomedct jdbc.snomedctuser = user jdbc.snomdectpass = pass jdbc.kandel = jdbc:mysql://kandel.dia.fi.upm.es:3306/metathesaurus jdbc.kandeluser = user jdbc.kandelpass = pass MetaMap.host = 127.0.0.1 MetaMap.options =- y -l -i --negex -R SNOMEDCT_US excluded.snomed.hierarchies # opcional trials.path # opcional

Figura 32 - Fichero de configuración

Los parámetros con el prefijo jdbc son los encargados de configurar las conexiones con las distintas bases de datos que se utilizan.

Los parámetros con el prefijo MetaMap configuran la dirección en la que se aloja el servidor de MetaMap y las opciones de procesamiento de la herramienta.

Los parámetros excluded.snomed.hierarchies y trials.path configuran las ramas de SNOMED-CT a excluir y el directorio en el que alojar los ficheros XML descargados por la herramienta.



3.2.2. Aplicación web para visualización y análisis de los datos

3.2.2.1. Motivación Previa a la toma de la decisión de desarrollar una aplicación web para la visualización de los

resultados se planteó una solución basada en generar informes en formato de hojas de cálculo Excel utilizando la librería Apache POI. Si bien esta opción resultaba válida para revisar datos estáticos, realizar análisis sobre estos documentos dificultaba la navegación entre las distintas posibles consultas que podían surgir a la hora del análisis. Adicionalmente, la generación de nuevos informes o la modificación de los ya existentes resultaban tareas tediosas por la limitación de tener que establecer el contenido de las celdas de manera secuencial, fila por fila. Sumado a todo esto, conseguir generar de manera automática determinadas gráficas o incluir estilos y fórmulas suponía demasiado esfuerzo en comparativa con la modificación manual desde una aplicación de edición de hojas de cálculo.

El desarrollo de la aplicación web viene por tanto motivado por la necesidad de ofrecer una alternativa a las hojas de cálculo para poder visualizar los datos a través de una interfaz amigable y más dinámica, capaz de soportar distintos tipos de consultas sobre los datos de manera sencilla y navegable.

3.2.2.2. Arquitectura de la aplicación web La aplicación desarrollada sigue la arquitectura habitual de una aplicación web común, con un

cliente, ejecutado en el navegador del usuario; y un servidor, encargado de servir los ficheros del cliente y atender las peticiones realizadas por el mismo. Adicionalmente, el servidor también es el encargado de interactuar con el otro componente del sistema, ECCET, para lanzar las peticiones de procesamiento de ensayos clínicos.

Figura 33 - Arquitectura de la aplicación web

Cliente Web

Servidor Web

ECCET

API REST



3.2.2.3. Diseño de la API REST El servidor web implementa una API REST para dar servicio a las peticiones lanzadas desde el

cliente de la aplicación. A continuación se muestra el listado de las operaciones de la API y algunas de sus características.

Descripción Procesar un ensayo Verbo POST URI /api/process/trial Parámetros trial Identificador del ensayo de clinicaltrials.gov

Respuesta

200 OK {"message":"OK"}

404 Not Found { message: 'Trial doesn't match NCTID format'}

Descripción Procesar múltiples ensayos Verbo POST URI /api/process/trials Parámetros trials Listado de identificadores de ensayos de clinicaltrials.gov

Respuesta

200 OK {"message":"OK"} 404 Not Found { message: 'Trial list can't be empty'}

Descripción Obtener el listado de ensayos procesados Verbo GET URI /api/trials

Parámetros limit Límite de resultados a devolver offset Desplazamiento inicial sobre los resultados de la búsqueda topic Temática de los ensayos a devolver

Respuesta

200 OK { "trials": [{ "nctid": "NCT02474251", "title": "Brain Sleep Clearance of Amyloid-Beta Peptides", "topic": "Obstructive Sleep Apnea, Alzheimer's Disease" }] } 400 Bad Request { error: Mensaje de error }



Descripción Obtener el número de ensayos procesados Verbo GET URI /api/trials/count Parámetros topic Temática de los ensayos a devolver

Respuesta

200 OK { "trials": 305 }

Descripción Obtener el detalle de un ensayo Verbo GET URI /api/trials/:trialid Parámetros trialid Identificador del ensayo de clinicaltrials.gov

Respuesta

200 OK { "trial": { "brief_summary": "...", "gender": "Female", "lastchanged_date": "February 4, 2016", "overall_status": "Recruiting", "start_date": "April 2015", "study_type": "Interventional", "url": "https://clinicaltrials.gov/show/NCT02479997", "topic": "Breast Cancer", "title": "Clinical Application of Dual Sentinel Lymph Node

Staining Method in Breast Cancer Patients" } } 400 Bad Request { error: Mensaje de error }

Descripción Obtener el listado de conceptos identificados Verbo GET URI /api/concepts

Parámetros limit Límite de resultados a devolver offset Desplazamiento inicial sobre los resultados de la búsqueda



Respuesta

200 OK { "concepts": [{ "sctid": "423740007", "cui": "C1520224", "fsn": "Eastern Cooperative Oncology Group performance status

(observable entity)", "hierarchy": "observable entity", "normalform": "423740007|Eastern Cooperative Oncology Group

performance status (observable entity)|", "active": 1, "focus_concept": "423740007", "focus_concept_fsn": "Eastern Cooperative Oncology Group

performance status (observable entity)", "focus_concept_hierarchy": "observable entity" }] } 400 Bad Request { error: Mensaje de error }

Descripción Obtener el número de conceptos identificados Verbo GET URI /api/concepts/count Parámetros -

Respuesta

200 OK { "concepts": 2106 }

Descripción Obtener el listado de criterios de elegibilidad Verbo GET URI /api/criteria




Respuesta

200 OK { "ec": [{ "number": 2, "trial": "NCT02530008", "utterance": "Recurrent breast cancer (local, regional, or

distant disease) - as determined by either clinical,radiological, or pathological evaluation.",

"inc_exc": 1 }] }

400 Bad Request { error: Mensaje de error }

Descripción Obtener el número de criterios de elegibilidad Verbo GET URI /api/criteria/count Parámetros -

Respuesta

200 OK { "criteria": 45203 }

Descripción Obtener el listado de coincidencias Verbo GET URI /api/match


Respuesta

200 OK { "matches": [{ "number": 0, "trial": "NCT02481128", "sctid": "254838004", "phrase": "invasive mamma carcinoma", "synonym": "Carcinoma of breast NOS", "prefered_name": "Breast Carcinoma", "matched_words": "[ mammary , carcinoma ]", "semantic_types": "[ neop ]", "negated": 0 }] } 400 Bad Request



{ error: Mensaje de error }

Descripción Obtener el número de coincidencias Verbo GET URI /api/match/count Parámetros -

Respuesta

200 OK { "match": 2106 }

Descripción Obtener los criterios de elegibilidad de un ensayo Verbo GET URI /api/criteria/:trialid

Parámetros limit Límite de resultados a devolver offset Desplazamiento inicial sobre los resultados de la búsqueda trialid

Respuesta

200 OK { "ec": [{ "number": 0, "trial": "NCT02479997", "utterance": "Inclusion Criteria: - breast cancer patients who

receive neoadjuvant therapy (chemotherapy,hormonal therapy, targeted therapy) - cN1-cN2 or cN3( but must be complete response status)on tumor lymphnode metastasis classification( TNM) after neoadjuvant therapy.",

"inc_exc": 1 }, { "number": 1, "trial": "NCT02479997", "utterance": "ECOG Performance status 0 or 1 - consented

patients with more than 20 years, less than 70 years.", "inc_exc": 1 }, { "number": 2, "trial": "NCT02479997", "utterance": "Exclusion Criteria: - history of breast cancer -

early stage breast cancer - history of excisional or incisional biopsy or axillary dissection - inflammatory breast carcinoma - cN3 on tumor lymphnode metastasis classification(TNM) - stage 4 breast cancer - pregnancy",

"inc_exc": 2 }] }



400 Bad Request { error: Mensaje de error }

Descripción Obtener los conceptos de un criterio de elegibilidad Verbo GET URI /api/trials/:trialid/criteria/:ecid/concepts

Parámetros ecid Número del criterio de elegibilidad dentro del ensayo trialid Identificador del ensayo de clinicaltrials.gov

Respuesta

200 OK { "concepts": [{ "phrase": "ECOG Performance status 0", "term": "Eastern Cooperative Oncology Group performance status

(observable entity)", "sctid": "423740007", "hierarchy": "observable entity" }, …] }

Descripción Obtener un listado de los conceptos más frecuentes Verbo GET URI /api/reports/frecuency

Parámetros limit Límite de resultados a devolver offset Desplazamiento inicial sobre los resultados de la búsqueda topic Temática de los ensayos a devolver



Respuesta

200 OK { "concepts": [{ "cui": "C0006142", "sctid": "254837009", "frecuency": 284, "concept": "Malignant tumor of breast (disorder)", "hierarchy": "disorder", "normalform": "…" }, { "cui": "C0392920", "sctid": "69960004", "frecuency": 273, "concept": "Antineoplastic chemotherapy regimen (procedure)", "hierarchy": "procedure", "normalform": "69960004|Antineoplastic chemotherapy regimen

(procedure)|" }, …] } 400 Bad Request { error: Mensaje de error }

Descripción Obtener las frases de los criterios de elegibilidad en las que aparece determinado concepto

Verbo GET URI /api/reports/frecuency/detail/:conceptid

Parámetros

limit Límite de resultados a devolver offset Desplazamiento inicial sobre los resultados de la búsqueda conceptid

Código de SNOMED-CT del concepto



Respuesta

200 OK { "matches": [{ "fsn": "Malignant tumor of breast (disorder)", "trial": "NCT02479230", "phrase": "Histologically confirmed breast cancer.", "synonym": "Breast cancer", "matched_words": "[ breast , cancer ]", "number": 2, "utterance": "Histologically confirmed breast cancer." }, { "fsn": "Malignant tumor of breast (disorder)", "trial": "NCT02479607", "phrase": "of breast cancer.", "synonym": "Breast cancer", "matched_words": "[ breast , cancer ]", "number": 1, "utterance": "The diagnosis of breast cancer." }, …] } 400 Bad Request { error: Mensaje de error }

Descripción Obtener un listado de los conceptos normalizados más frecuentes Verbo GET URI /api/reports/normalform




Respuesta

200 OK { "concepts": [{ "sctid": "64572001", "concept": "Disease (disorder)", "hierarchy": "disorder", "frecuency": 2616 }, { "sctid": "71388002", "concept": "Procedure (procedure)", "hierarchy": "procedure", "frecuency": 1442 }, { "sctid": "404684003", "concept": "Clinical finding (finding)", "hierarchy": "finding", "frecuency": 523 }, ...] } 400 Bad Request { error: Mensaje de error }



3.2.2.4. Interfaz de la aplicación La interfaz de la aplicación está dividida en varias vistas, cada una de ellas para dar soporte a las

diferentes consultas que quiera realizar el usuario. A continuación se presentan cada una de estas vistas y las funcionalidades asociadas.

3.2.2.4.1. Pantalla principal

La pantalla principal de la aplicación permite al usuario especificar los ensayos que quiera procesar a través del identificador del ensayo. Una vez finalizada la tarea de procesamiento el cliente ofrece un enlace al detalle de los ensayos procesados y los resultados producidos.

Figura 34 - Pantalla principal

Figura 35 – Sección de procesamiento de varios ensayos



3.2.2.4.2. Pantalla de listado de ensayos clínicos

En esta pantalla se muestra un listado de los ensayos clínicos procesados por la herramienta ECCET y almacenados en la base de datos. Los ensayos pueden ser ordenados y/o filtrados, además de poder acceder a una vista detallada de los resultados producidos por la herramienta.

Figura 36 - Pantalla de listado de ensayos



Figura 37 - Detalle de un ensayo



3.2.2.4.3. Pantalla de listado de conceptos

La pantalla del listado de conceptos es similar a la de ensayos clínicos. Aquí se muestran los conceptos extraídos de todos los ensayos procesados e información asociada, como la forma normalizada del concepto.

Figura 38 - Pantalla del listado de conceptos



3.2.2.4.4. Pantallas de informes

Las pantallas de informes muestran información de consultas útiles para analizar los resultados producidos por ECCET, tales como la frecuencia de aparición de los conceptos en el total de los ensayos procesados, o filtrados por la temática de los ensayos.

Figura 39 - Pantalla de informe de frecuencias de aparición



Figura 40 - Detalle de las apariciones de un concepto



3.2.3. Modelo de datos El modelo de datos utilizado por el sistema viene representado en la siguiente figura:

Figura 41 - Modelo de datos del sistema

Las tablas attribute y clinical_trial almacenan la información relativa a los ensayos procesados.

La tabla eligibility_criteria representa los criterios de elegiblidad de cada ensayo clínico.

Las tablas concept y cmatch sirven para capturar los resultados del procesamiento.

o La tabla concept recoge cada uno de los distintos conceptos que se identifican en cualquiera de los ensayos.

o Por otro lado, la tabla cmatch recoge cada ocurrencia de cada concepto, el criterio de elegiblidad y el ensayo en el que aparece, además de otra información útil como la frase donde aparece, que palabra o palabras dieron origen al mapping.

La tabla refinement se utiliza para almacenar los atributos y valores de la forma normal de SNOMED-CT de cada concepto.



3.2.4. Tecnologías y herramientas empleadas Para la implementación del sistema se han empleado diferentes tecnologías. A continuación se

ofrece una tabla de las más relevantes, además de una breve descripción de la implicación que han tenido en el desarrollo de cada uno de los componentes del sistema.

Tecnología Tipo Partes implicadas Utilizado para

Java Lenguaje de programación

ECCET Implementación de la herramienta

SQL Lenguaje de programación

ECCET Realización de consultas e inserciones de las distintas bases de datos utilizados por el sistema Servidor de la aplicación

web

HTML Lenguaje de marcado

Cliente de la aplicación web

Implementación del cliente web

CSS Lenguaje de hojas de estilos


Maquetación del cliente web

Javascript Lenguaje de programación

Servidor y cliente de la aplicación web

Implementación de las funcionalidades del cliente y servidor web

MySQL Servidor Gestor de Bases de Datos Relacionales

ECCET

Servidor de las bases de datos Servidor de la aplicación web

SpringJDBC Librería ECCET Gestión de las conexiones JDBC con las base de datos

OpenNLP Librería ECCET Preprocesamiento de los criterios de elegibilidad

NodeJS Librería, entorno de ejecución

Servidor de la aplicación web

Implementación del servidor web y API REST



Express Librería Servidor de la aplicación web

Implementación del servidor web y API REST

AngularJS Librería Cliente de la aplicación web

Implementación del cliente web

MetaMap Librería, Software ECCET Anotación de los conceptos presentes en los criterios de elegibilidad

Npm Gestor de paquetes y dependencias


Gestión de las dependencias de la aplicación web

Bower Gestor de paquetes y dependencias


Gestión de las dependencias de la aplicación web

Gulp Automatizador de tareas, Librería


Automatización de tareas en compilado less, inyección de dependencias y lanzamiento del servidor de desarrollo

Git Control de versiones, Software

ECCET

Control de versiones del código de ECCET y la aplicación web



Less Lenguaje de hojas de estilo, Lenguaje de preprocesado


Procesado de ficheros de estilo less a ficheros css

Vagrant

Herramienta de creación de entornos de desarrollo virtualizados

ECCET

Configuración del entorno de desarrollo con servidor virtualizado





Sublime Text

Editor de texto Servidor y cliente de la aplicación web

-

Eclipse Entorno de desarrollo

ECCET -

Maven

Gestor de dependencias y constructor de proyectos Java

ECCET Gestión de las dependencias del proyecto de ECCET

Putty Cliente SSH

ECCET

Interacción vía ssh con el servidor de la aplicación



WinSCP Cliente SFTP

ECCET

Interacción vía sftp con el servidor de la aplicación





3.3. Evaluación del impacto de la normalización sobre los conceptos extraídos

3.3.1. Conjunto de datos seleccionado El objetivo principal del trabajo era evaluar el impacto de la normalización en los conceptos

extraídos por el sistema. Para ello se utilizaron ensayos clínicos de clinicaltrials.gov sobre investigaciones relacionadas con el cáncer de mama. Esto es debido a que el trabajo de filtrado manual de los conceptos se realizó sobre ensayos relacionados con esta temática. Es decir, el sistema está “entrenado” para procesar ensayos sobre cáncer de mama y, aunque se podrían procesar ensayos de cualquier tipo, podrían aparecer nuevos conceptos considerados no válidos que alterarían la información a analizar.

Los ensayos clínicos escogidos tienen las siguientes características:

Temática: Cáncer de mama Rango de fechas de publicación: 24 de Abril de 2015 a 24 de Abril de 2016

Al ser ensayos relativamente recientes, el formato de los criterios de elegibilidad sigue un patrón más o menos definido, enumerando primero los criterios de inclusión y después los criterios de exclusión.

3.3.2. Resultados de la evaluación Tras el procesamiento de un total de 300 ensayos clínicos relacionados con el cáncer de mama

se obtuvieron los siguientes datos:

Figura 42 - Distribución de las jerarquías de SNOMED-CT de conceptos no normalizados



Figura 43 - Frecuencia de los conceptos no normalizados

Figura 44 - Distribución de las jerarquías de SNOMED-CT de conceptos normalizados



Figura 45 - Frecuencia de los conceptos normalizados

Como se puede observar, el proceso de normalización tiene un impacto en dos factores: (1) la variedad de conceptos y (2) la cantidad de conceptos. En el caso de los conceptos no normalizados existe mayor cantidad de conceptos distintos en comparación con el caso de los conceptos normalizados. Esto podría tener implicaciones importantes a la hora de automatizar la comparación de las condiciones de los pacientes y los criterios de elegibilidad adecuadamente formalizados. Al normalizar los conceptos de las expresiones de SNOMED-CT que representan la información de los pacientes y de los criterios se reduciría la complejidad en la comparación entre ambas expresiones [5], reduciendo a su vez el tiempo de cómputo.



4. CONCLUSIONES Y LÍNEAS FUTURAS En este último capítulo se presentan las conclusiones obtenidas de la realización de este trabajo de fin de grado, junto con las dificultades encontradas y las líneas futuras que pueden derivar del trabajo.

4.1. Conclusiones La formalización de la información presente en textos clínicos representa uno de los grandes

retos de la bioinformática. Ser capaces de estructurar adecuadamente la información clínica presente en la inmensa cantidad de recursos disponibles (como historiales de pacientes, información sobre enfermedades, procedimientos o diagnósticos) puede dar cabida al desarrollo de nuevas aplicaciones que sean capaces de automatizar el manejo de esta información, y mejorar de manera significativa los cuidados sanitarios que se proporcionan a los pacientes. En el caso particular de los ensayos clínicos, conseguir estructurar la información presente en los criterios de elegibilidad podría reducir la carga de tiempo y trabajo en los procesos de selección de pacientes, acelerando la consecución de avances en investigación sobre nuevas técnicas y fármacos para el tratamiento de enfermedades. La utilización de estándares como las terminologías clínicas supone un paso adelante en el desarrollo de nuevas aplicaciones que mejoren los cuidados sanitarios, al habilitar la interoperabilidad entre sistemas heterogéneos y la compartición de información clínica. Estándares como SNOMED-CT posibilitan además capturar la semántica de los recursos clínicos expresados en lenguaje natural de manera unívoca y sin ambigüedad, facilitando el procesamiento automático de esta información.

Durante la realización de este trabajo he podido observar la gran dificultad que conlleva estructurar la información presente en un texto clínico, que es normalmente expresado en lenguaje natural. En el dominio de la medicina, cada ápice de información resulta fundamental para tomar las mejores decisiones, de las que dependen vidas de seres humanos. La importancia de extraer cada matiz de información de una frase conlleva realizar análisis exhaustivos del texto y comprender el funcionamiento del lenguaje humano, lo que a su vez implica que profesionales de distintas disciplinas (lingüística, medicina, informática) cooperen para realizar avances significativos.

Uno de los principales objetivos del trabajo era aplicar el mecanismo de normalización de conceptos de SNOMED-CT, que pretendía arrojar nuevas pistas sobre cómo cambiaba la representación de los criterios según se utilizasen conceptos normalizados o sin normalizar. Es decir, se quería comprobar si este proceso resultaba de utilidad en algún aspecto que ayudase en un proceso de formalización más completo o si podría influir en una hipotética aplicación que automatizase el proceso de selección de pacientes para la realización de ensayos clínicos. Como se ha podido observar, la normalización reduce significativamente la variedad de conceptos que hay que utilizar para representar los criterios, a cambio de un aumento drástico de la aparición de conceptos más genéricos y primitivos. Esto podría ser beneficioso a la hora de hacer las comparaciones de las expresiones de SNOMED-CT que representasen los criterios de elegibilidad y las características de los pacientes, al aumentar la eficiencia de cómputo de estas comprobaciones.



Por último, y como conclusión final, si bien el sistema desarrollado en este trabajo de fin de grado puede ayudar en la tarea de visualizar la información (conceptos) contenida en los criterios de elegibilidad, el potencial del sistema reside en poder utilizar y analizar esta información (comprender qué tipo de conocimiento se incluye y cómo viene estructurado en el texto de los criterios de elegibilidad) para poder desarrollar técnicas y algoritmos específicos que sean capaces de formalizar con mayor detalle los criterios de elegibilidad.

4.2. Líneas futuras El presente trabajo plantea posibles mejoras, tanto por la parte de la extracción de conceptos

como en la parte de la aplicación web.

En primer lugar, el procedimiento de extracción utilizado es dependiente de dos factores fundamentales: el formato de los criterios de elegibilidad y del algoritmo del anotador MetaMap. La creación de un estándar para representar los criterios de elegibilidad permitiría un parsing más eficaz y sencillo, capaz de manejar más variables y simplificando la complejidad de las técnicas de procesamiento de lenguaje natural a utilizar. Sería interesante poder identificar los atributos de las entidades y los valores asociados, y la estandarización del formato de representación de los criterios podría facilitar esta tarea. Respecto al algoritmo de MetaMap, éste está pensado para identificar y codificar entidades del UMLS de textos clínicos genéricos, por lo que el nivel de especificidad actual se podría mejorar a través de nuevos algoritmos.

Por otro lado, la aplicación web ofrece funcionalidad limitada y se podría extender la variedad de consultas que se pueden hacer sobre los resultados del procesamiento de los ensayos, y en general, un mayor control sobre los datos almacenados. Un mecanismo de autenticación dotaría un mínimo de seguridad en la utilización de la aplicación web, ya que en un principio se planteó la aplicación como una plataforma de visualización de los datos que no podría interactuar con la propia herramienta de procesamiento de ensayos ECCET.

Como nota final, respecto a la problemática de automatizar el proceso de selección de pacientes para los ensayos clínicos, aún queda un largo camino por recorrer en el área del procesamiento de lenguaje natural y la extracción de información en textos clínicos. Formalizar la información presente en los cada vez más abundantes recursos clínicos con el máximo detalle posible y de manera automática es una tarea a día de hoy imposible, pero necesaria dada la sensibilidad de las decisiones que se toman en este dominio.



ANEXOS A. Despliegue de la aplicación y requisitos del entorno

A.1. Requisitos previos

Para el despliegue de la aplicación desarrollada es necesario el cumplimiento de los siguientes requisitos previos:

Java Runtime Environment o JRE de 64 bits, versión 1.8 [24] MetaMap y MetaMap Java API [14] MySQL Server(opcional) [25] NodeJS [26] NPM [26] Bower [27] Gulp [28]

A.2. Estructura de directorios

La estructura de directorios es la siguiente:

eccet/ │ config.properties │ ECCET.jar │ tree.txt │ ├───data/ │ └───trials/ ├───normct_app/ │ │ bower.json │ │ config.json │ │ gulpfile.js │ │ package.json │ └───app/ └───resources/ │ MetaMapApi.jar │ prologbeans.jar │ └───opennlp/ en-chunker.bin en-pos-maxent.bin en-sent.bin en-sent.train en-token.bin

Figura 46 - Estructura de directorios de la aplicación



El directorio eccet es el directorio raíz de la aplicación. Dicho directorio debe contener los siguientes elementos:

Fichero config.properties. Este fichero contiene los parámetros de configuración.

ECCET.jar. Este fichero es la herramienta ECCET empaquetada en un Java Archive ejecutable.

Directorio data/trials/. Este es el directorio temporal por defecto donde se descargan y buscan los ensayos a procesar. Puede modificarse a través del fichero de configuración config.properties.

normct_app. Este es el directorio con los ficheros de la aplicación web, tanto del cliente web como la API REST.

El directorio resources contiene librerías y ficheros externos utilizados por ECCET.

A.3. Instalación de dependencias

Para la ejecución de la aplicación web es necesario instalar una serie de dependencias. Para ello se utilizan los gestores de paquetes NPM y Bower. La instalación de las dependencias se realiza con los siguientes comandos, una vez situados en el directorio raíz de la aplicación web, normct_app

> npm install

> bower install

Esto creara los directorios node_modules y bower_components con las dependencias de la aplicación.

A.4. Configuración de las bases de datos

La aplicación utiliza 3 bases de datos diferentes. A continuación una breve descripción de cada una:

normdb: Esta es la base de datos que contiene la información generada en las tareas de procesamiento de los ensayos clínicos. Es también la base de datos que proporciona los datos que se muestran en la aplicación web.

snomedct: Se trata de una base de datos de apoyo que contiene la ontología de SNOMED-CT. El script de creación del esquema se encuentra en el repositorio de GitHub https://github.com/rorydavidson/SNOMED-CT-Database. Los ficheros de SNOMED-CT deben descargarse desde la National Library of Medicine [30] tras pasar por el correspondiente proceso de registro de una cuenta.



metathesaurus: La base de datos del metathesaurus también es una base de datos de apoyo, utilizada para el proceso de traducción de los códigos del UMLS Metathesaurus a códigos de SNOMED-CT.

La configuración de las bases de datos se debe realizar en 2 ficheros:

config.properties. En este fichero se debe indicar la dirección de cada una de las bases de datos, un usuario autorizado y su contraseña. En el caso de las bases de datos snomedct y metathesaurus bastará con permisos de consulta.

config.json. En este fichero se debe indicar la configuración de la base de datos de la aplicación normdb.

A.5. Lanzamiento de MetaMap

Para poder procesar ensayos desde la aplicación web el servidor de MetaMap y sus servidores auxiliares deben estar corriendo. Además, es necesario configurar las direcciones IP de las máquinas a las que se le permite hacer consultas (en caso de que el servidor de MetaMap se encuentre en la misma máquina que la aplicación, este paso no es necesario ya que viene configurado por defecto).

Lanzamiento de servidores auxiliares, situándose en el directorio public_mm de MetaMap:

Servidor de anotación: ./bin/skrmedpostctl start

Servidor de desambiguación: ./bin/wsdserverctl start

Lanzamiento del servidor principal, situándose en el directorio public_mm de MetaMap:

Servidor de MetaMap: ./bin/mmserver16 –Z 2015AB --nomap Exclusions

Donde la opción –Z indica la versión del modelo de datos utilizado por MetaMap [14] para la búsqueda de coincidencias y la opción --nomap indica el nombre del fichero que contiene el listado de conceptos a excluir de la fase de mapping.

A.6. Lanzamiento de la aplicación web

Para el lanzamiento de la aplicación web se deben compilar en primer lugar los ficheros less [29] para generar las hojas de estilo de la aplicación. A través del fichero Gulpfile.js y del automatizador de tareas se puede realizar este proceso con el siguiente comando:

> gulp less

Una vez generados los ficheros CSS se procede a lanzar la aplicación con el siguiente comando desde el directorio raíz de la aplicación, normct_app:

> node nohub node app/backend/bin/www &



BIBLIOGRAFÍA [1] K. Raja and Siddhartha R. Jonnalagadda, “An Introduction to Healthcare Data Analytics” in Healthcare Data Analytics, pp. 2-5.

[2] K. Raja and Siddhartha R. Jonnalagadda, “Natural Language Processing and Data Mining for Clinical Text” in Healthcare Data Analytics, pp. 219-242.

[3] IHTSDO, Febrero 2014, “SNOMED CT Starter Guide”,

[4] Ministerio de Sanidad, Servicios Sociales e Igualdad, Preguntas frecuentes sobre SNOMED CT, Available: https://www.msssi.gob.es/profesionales/hcdsns/areaRecursosSem/snomed-ct/preguntas.htm

[5] IHTSDO Enero 2007, “SNOMED Clinical Terms. Transforming Expressions to Normal Forms”,

[6] National Library of Medicine, UMLS Quick Start Guide [Online] Available: https://www.nlm.nih.gov/research/umls/quickstart.html

[7] National Library of Medicine, Fact Sheet UMLS Metathesaurus, Available: https://www.nlm.nih.gov/pubs/factsheets/umlsmeta.html

[8] National Library of Medicine, Unique Identifiers in the Metathesaurus, Available: https://www.nlm.nih.gov/research/umls/new_users/online_learning/Meta_005.html

[9] Aronson, A. and Lang, F. (2010). An overview of MetaMap: historical perspective and recent advances. Journal of the American Medical Informatics Association, 17(3), pp.229-236.

[10] Docs.oracle.com. (2016). Properties (The Java™ Tutorials > Essential Classes > The Platform Environment). [online] Available at: https://docs.oracle.com/javase/tutorial/essential/environment/properties.html [Accessed 30 May 2016].

[11] JOSHI, A. (1991). Natural Language Processing. Science, 253(5025), pp.1242-1249.

[12] C. Mihaila, R. Batista-Navarro, N. Alnazzawi, G. Kontonatsios, I. Korkontzelos, R. Rak, P. Thomson and S. Ananiadou, “Mining the Biomedical Literature” in Healthcare Data Analitycs, pp. 251-284.

[13] Bioportal.bioontology.org. (2016). Welcome to the NCBO BioPortal | NCBO BioPortal. [online] Available at: http://bioportal.bioontology.org/ [Accessed 2 Jun. 2016].

[14] MetaMap.nlm.nih.gov. (2016). MetaMap - A Tool For Recognizing UMLS Concepts in Text. [online] Available at: https://MetaMap.nlm.nih.gov/ [Accessed 2 Jun. 2016].

[15] Ghoulam, A., Barigou, F. and Belalem, G. (2015). Information Extraction in the Medical Domain. Journal of Information Technology Research, 8(2), pp.1-15.

[16] Es.wikipedia.org. (2016). Principio de Pareto. [online] Available at: https://es.wikipedia.org/wiki/Principio_de_Pareto [Accessed 2 Jun. 2016].

[17] Docs.oracle.com. (2016). The Java™ Tutorials. [online] Available at: https://docs.oracle.com/javase/tutorial/ [Accessed 4 Jun. 2016].



[18] Mozilla Developer Network. (2016). JavaScript reference. [online] Available at: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference [Accessed 4 Jun. 2016].

[19] Vagrantup.com. (2016). Vagrant by HashiCorp. [online] Available at: https://www.vagrantup.com/ [Accessed 4 Jun. 2016].

[20] Docs.angularjs.org. (2016). AngularJS. [online] Available at: https://docs.angularjs.org/api [Accessed 4 Jun. 2016].

[21] Docs.spring.io. (2016). 18. Data access with JDBC. [online] Available at: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/jdbc.html [Accessed 4 Jun. 2016].

[22] Opennlp.apache.org. (2016). Apache OpenNLP Developer Documentation. [online] Available at: https://opennlp.apache.org/documentation/1.6.0/manual/opennlp.html [Accessed 4 Jun. 2016].

[23] Expressjs.com. (2016). Express - Infraestructura de aplicaciones web Node.js. [online] Available at: http://expressjs.com/es/ [Accessed 5 Jun. 2016].

[24] Java.com. (2016). Descarga gratuita de software de Java. [online] Available at: http://www.java.com/es/download/ [Accessed 5 Jun. 2016].

[25] Mysql.com. (2016). MySQL. [online] Available at: https://www.mysql.com/ [Accessed 5 Jun. 2016].

[26] Foundation, N. (2016). Node.js. [online] Nodejs.org. Available at: https://nodejs.org/en/ [Accessed 5 Jun. 2016].

[27] Bower.io. (2016). Bower. [online] Available at: http://bower.io/ [Accessed 5 Jun. 2016].

[28] Gulpjs.com. (2016). gulp.js - the streaming build system. [online] Available at: http://gulpjs.com/ [Accessed 5 Jun. 2016].

[29] Team, T. (2016). Getting started | Less.js. [online] Lesscss.org. Available at: http://lesscss.org/ [Accessed 5 Jun. 2016].

[30] Nlm.nih.gov. (2016). International Release of SNOMED CT. [online] Available at: https://www.nlm.nih.gov/healthit/snomedct/international.html [Accessed 5 Jun. 2016].

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Mon Jun 06 19:13:05 CEST 2016

Emisor delCertificado

[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe Signature)

graduado en ingeniería informáticaoa.upm.es/43499/1/tfg_jorge_gonzalez_valencia_a.pdfrequeriría...

Documents