Implementación de técnicas de string matching y selección semántica aproximada en un motor de normalización terminológica

Escuela Técnica Superior de Ingeniería Informática Universitat Politècnica de València IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA Proyecto Final de Carrera Ingeniería Informática Autora: Estíbaliz Parcero Iglesias Directores: Montserrat Robles Viejo Jose Alberto Maldonado Segura 25 de Septiembre de 2012 IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 2 3 A mi madre, Jacinta, a Alfonso y a la memoria de mi padre. IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 4 Resumen En este proyecto se presenta un sistema de normalización terminológica que busca conseguir un sistema eficaz en base a número de términos correctamente mapeados e integrarse dentro de un servidor terminológico. Se implementa un motor de comparación de términos basado en técnicas de correspondencia aproximada de cadenas (approximate string matching), ampliamente utilizadas en data mining y deduplicación de datos. Se estudiaron estas técnicas concluyendo que la técnica Jaccard consigue la mayor eficacia dentro del servidor terminológico objetivo. Una vez establecida la base teórica se describe la herramienta implementada como una aplicación web e integrada dentro del servidor terminológico. Se le añaden sustanciales mejoras que consiguen aumentar significativamente la eficacia. En conclusión se consigue una herramienta que centraliza el proceso de normalización terminológica facilitando y ahorrando tiempo al usuario. Palabras clave: normalización terminológica, servidor terminológico, LOINC, string matching, mapping. 5 IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 6 7 Tabla de contenidos 1. Introducción ............................................................................................................. 11 Objetivos ...................................................................................................................... 12 Estructura de la memoria ............................................................................................ 12 2. Contexto de Trabajo ................................................................................................. 14 IBIME .......................................................................................................................... 14 BITAC ........................................................................................................................... 14 3. Normalización terminológica con LOINC ................................................................ 15 Terminologías clínicas ................................................................................................. 15 LOINC .......................................................................................................................... 16 El servidor terminológico de BITAC ............................................................................ 17 4. Estado del arte .......................................................................................................... 19 Correspondencia aproximada de cadenas ................................................................... 19 Herramientas de normalización terminológica ........................................................... 19 5. Materiales y métodos ............................................................................................... 21 El motor de comparación............................................................................................. 21 Modelos matemáticos de string matching ................................................................... 21 Elección de la técnica de string matching .............................................................. 24 Implementación de la interfaz .................................................................................... 25 Desarrollo web ........................................................................................................ 25 6. Implementación de SANT ....................................................................................... 29 Esquema de ejecución de Vaadin ............................................................................... 29 Esquema general de SANT ......................................................................................... 29 Mejora en el proceso de búsqueda terminológica ....................................................... 31 Casos de uso ................................................................................................................ 35 7. Resultados ................................................................................................................ 51 8. Conclusiones ............................................................................................................ 54 9. Trabajo futuro .......................................................................................................... 55 10. Agradecimientos ..................................................................................................... 56 11. Bibliografía ............................................................................................................... 57 12. Anexo: Artículo Inforsalud’12 ................................................................................. 59 IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 8 Tabla 1: Códigos y términos LOINC ................................................................................ 17 Tabla 2: Pruebas de laboratorio del servidor terminológico relacionadas por un mismo código Bitac ..................................................................................................................... 17 Tabla 3: Pruebas de laboratorio del servidor terminológico sin relacionar con la terminología de referencia .............................................................................................. 18 Tabla 4: Comparación de frameworks de desarrollo de aplicaciones web .................... 26 Tabla 5: Ejemplo de funcionamiento del filtrado por ejes ............................................. 32 Tabla 6: Ejemplo de tablas de sinónimos ....................................................................... 33 Tabla 7: Ejemplo de algunos ejes extraídos a partir de la descripción ........................... 33 Tabla 8: Ejemplo de aplicación del valor por omisión 'orina' ........................................ 34 Tabla 9: Pruebas que incluyen información de alguno de sus ejes en su descripción .... 51 Figura 1: Ejemplo del proceso de tokenización .............................................................. 22 Figura 2: Comparación de las técnicas de string matching en base a su eficacia ......... 25 Figura 3: Arquitectura general de Vaadin ...................................................................... 29 Figura 4: Esquema general de la aplicación desarrollada .............................................. 29 Figura 5: Diagrama de los Principales Casos de Uso ..................................................... 35 Figura 6: Pantalla inicial que muestra un error de login ............................................... 35 Figura 7: Caso de Uso "Procesar Lote" ........................................................................... 36 Figura 8: Lista de lotes ................................................................................................... 36 Figura 9: Botón para actualizar la lista de lotes .............................................................. 37 Figura 10: L lista de pruebas que contiene el lote seleccionado...................................... 37 Figura 11: Botón para ejecutar la función de obtención de ejes ..................................... 38 Figura 12: Ventana de edición del eje muestra obtenido a partir de la descripción ...... 38 Figura 13: Ventana de Default Assumptions .................................................................. 39 Figura 14: Barra de configuración .................................................................................. 39 Figura 15: Botón para enviar el lote al motor de comparación ...................................... 40 Figura 16: Caso de Uso "Validar Lote" ............................................................................ 41 Figura 17: Desplegable de selección de lote .................................................................... 42 Figura 18: Lista de pruebas asociadas a su candidato del lote seleccionado ................. 42 Figura 19: Lista de candidatos desplegada para la prueba seleccionada ....................... 43 Figura 20: Ejemplo de uso del filtro postproceso para la columna método .................. 43 Figura 21: Ventana de sinónimos de una prueba candidata .......................................... 44 Figura 22: Ejemplo de uso del campo comentario y el desplegable de incidencias ....... 44 Figura 23: Conjunto de pruebas marcadas como validadas .......................................... 45 Figura 24: Exportación de resultados a una hoja de cálculo .......................................... 45 Figura 25: Botón para incorporar las pruebas marcadas al servidor terminológico ..... 46 Figura 26: Caso de Uso "Gestionar Tablas de Sinónimos"............................................. 46 Figura 27: Pestaña de sinónimos .....................................................................................47 Figura 28: Ventana de gestión de sinónimos para el eje muestra ..................................47 Figura 29: Ventana de gestión de la tabla de tiempos asociados a muestras ................ 48 Figura 30: Ventana de gestión de sinónimos por lote .................................................... 49 Figura 31: Pestaña LOINC para la búsqueda externa de términos ................................ 50 Figura 32: Botón logout ................................................................................................. 50 Figura 33: Ventana de edición de ejes obtenidos ............................................................ 51 Figura 34: Configuración aplicada ................................................................................. 52 Figura 35: Marcado de pruebas que han encontrado un candidato correcto ................ 52 Figura 36: Gráfica comparativa de la eficacia en cada caso ........................................... 53 9 IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 16 adversos asociados al uso de productos farmacéuticos, de dispositivos médicos o vacunas. Su uso permite el intercambio y análisis de datos relativos a la seguridad de estos productos. MeSH (Medical Subjects Headings) es una agrupación de términos relevantes que conforman un vocabulario controlado para la clasificación de artículos y publicaciones científicas. UMLS es un Sistema de Lenguaje Médico Unificado. Recoge un conjunto de vocabularios médicos y de herramientas que los enlazan a fin de facilitar la interoperabilidad entre sistemas informáticos. LOINC es la terminología de interés en este proyecto puesto que se utiliza para normalizar pruebas de laboratorio. En el siguiente apartado se describe de forma detallada. LOINC La base de datos LOINC proporciona un conjunto de nombres universales y códigos identificativos para pruebas de laboratorio y para observaciones clínicas. LOINC facilita el intercambio y almacenamiento de términos como hemoglobina en sangre, potasio en suero o signos vitales, para su uso en medicina, en investigación, o en gestión de recursos. Los códigos LOINC no pretenden abarcar toda la información relativa a una prueba de laboratorio o a una observación clínica, si no identificar inequívocamente dicha prueba u observación. De esta manera el código LOINC puede formar parte de un mensaje que contenga más campos que completen la información por ejemplo para un paciente dentro de su historia clínica electrónica o para una población dentro de un informe epidemiológico. Cada término codificado en LOINC incluye seis campos o ejes que especifican: 1. Componente o analito. Ej: potasio, hemoglobina, antígeno de la hepatitis C… 2. Propiedad medida. Ej: Concentración de masa, actividad enzimática… 3. Temporalidad, es decir, si la medida es una observación en un momento determinado del tiempo o es durante un periodo de tiempo. Ej: Orina 24 horas. 4. Muestra. Ej: Orina, sangre, suero… 5. Tipo de escala. Ej: si la medida es cuantitativa, ordinal, nominal o narrativa. 6. Método, el utilizado en la medida, se especifica siempre que sea relevante, es decir, sólo cuando proporcione distinción con respecto a otro tipo de método por su relevancia clínica. Ej: radioinmunoensayo, PCR… Un término LOINC se describe formalmente con la siguiente sintaxis: <Componente>:<Propiedad>:<Temporalidad>:<Muestra>:<Escala>:<Método> Los dos puntos forman parte del nombre formal y sirven para separar las principales partes del nombre, es decir, los seis ejes de LOINC. 17 A cada término resultante de una única combinación de los seis ejes se le asigna un código único y permanente que servirá para identificar pruebas de laboratorio en informes electrónicos. Código LOINC Término 25428-4 Glucose:ACnc:Pt:Urine:Ord:Test strip 4546-8 Hemoglobin A/Hemoglobin.total in Blood:MFr:Pt:Bld:Qn 19146-0 Reference lab test results:Find:XXX:Reference lab test:Nar Tabla 1: Códigos y términos LOINC El servidor terminológico de BITAC El servidor terminológico o banco de datos utilizado en este proyecto es propiedad de la empresa BITAC, especialistas en normalización de datos de laboratorio, y hace uso de la terminología LOINC como terminología estándar. Como punto de partida se dispone de este banco de datos compuesto por pruebas clínicas de distintos centros codificados según su sistema local. Junto a estos términos locales está la terminología de referencia LOINC y todos estos términos están asociados a un sistema de codificación del servidor terminológico denominado código Bitac encargado de relacionar términos locales con términos LOINC. Así pues, es posible agrupar los términos por código Bitac, obteniendo un conjunto de sinónimos para un concepto dado. Este grupo es interesante por la información que aporta ya que puede incluir distintas formas de referirse a un concepto, términos con mayor o menor información relevante, y equivalencias de conceptos entre los idiomas utilizados en el banco de datos como se puede observar en el ejemplo siguiente: Código Local Componente Código Bitac 488 ADH ( VASOPRESINA) 1003126 BIO.1.200 3 ADH(ARGININE VASOPRESSIN) 1003126 6892 ADH HORM. ANTIDIURETICA 1003126 1589 ADH plasma 1003126 3126-0 Vasopressin 1003126 7045 Vasopresina 1003126 204 ADH (Hormona Antidiuretica) 1003126 Tabla 2: Pruebas de laboratorio del servidor terminológico relacionadas por un mismo código Bitac Las nuevas pruebas procedentes de centros externos se integran en el banco de datos sin enlazar en un primer momento a la terminología de referencia, con el código Bitac a cero. Se almacenan en su formato original, tal y como proviene del centro, con su codificación local. IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 18 En la siguiente tabla tenemos algunos ejemplos de pruebas para las que aún no se ha encontrado una correspondencia con la terminología de referencia: Código Local Componente Prop. Tiempo Muestra Escala Método 10301 ANTICUERPOS IgM ANTI CARDIOLIPINA [ACA] EN SUERO ACA IgM SUERO Enzimoinmunoanálisis EBG AC.IgG ANTIEPSTEIN BARR SUERO N 7093 Kiwi 1589 PCR HERPESVIRIDAE L.C.R. Ord 2590 ACIDO VANILMANDÉLICO (HISTORICO ORINA DE 24 HORAS + ClH Cromat. intercambio iónic 1761 Seleni a sèrum 2772 Subpoblaciones Linfocitarias Texto Citometria de flujo 7609 Panipenem Antibiótico Tabla 3: Pruebas de laboratorio del servidor terminológico sin relacionar con la terminología de referencia Es habitual encontrar entre las pruebas locales términos con ejes no informados (ninguna de estas pruebas contiene información en el eje “propiedad”), ejes con información incorrecta (la prueba 7609 contiene una información errónea en el eje “escala”) o ejes con información que corresponde a un eje, o incluso a varios ejes distintos (las pruebas 10301 y 1761 contienen la información relativa al eje “muestra” en el eje “componente”). 19 4. Estado del arte A continuación se expone el trabajo de otros autores en relación al tipo de técnicas que usará el motor de comparación de SANT, las técnicas de correspondencia aproximada de cadenas, y en relación a otras herramientas de normalización terminológica. Correspondencia aproximada de cadenas La correspondencia aproximada de cadenas es un tipo de técnica de búsqueda de cadenas que consiste en encontrar patrones coincidentes de manera aproximada entre las cadenas comparadas. La correspondencia aproximada de cadenas se usa en varias áreas de la informática. Se ha utilizado en biología computacional, un área que ha cobrado gran importancia en los últimos años, para detectar correspondencias entre series de proteínas o de ADN. Estas secuencias representan el código genético de los seres vivos y buscar secuencias específicas resulta útil para localizar determinadas propiedades en la cadena de ADN, sin embargo, raramente las secuencias son siempre idénticas, debido a variaciones evolutivas o mutaciones, por tanto, en este campo la correspondencia aproximada de cadenas resulta especialmente útil [6]. En el campo del procesamiento de señales o del reconocimiento de formas también podemos encontrar ejemplos de uso. Es el caso del procesamiento de mensajes de voz que contienen unas órdenes específicas. Problemas en la decodificación, descompresión, grabación, pronunciación o variaciones en la voz puede dar como resultado una palabra o frase diferente a la almacenada en el sistema, de forma que la búsqueda exacta por palabras no resultaría efectiva, y sin embargo sí podría serlo la búsqueda por correspondencia aproximada [7]. Lo mismo ocurre con la detección de escritura manual, en la que un procesamiento de ésta daría lugar a una cadena de caracteres que, al igual que la cadena resultante de un mensaje de voz, puede contener errores, y una búsqueda exacta de cadenas no daría resultado [8]. Y por supuesto, en el campo de la recuperación de textos estas técnicas tienen mucha utilidad, por ejemplo en la búsqueda de textos digitalizados mediante OCR (optical character recognition) donde pueden aparecer errores tipográficos y errores en la digitalización [9]. Otras aplicaciones de procesamiento de textos como los correctores ortográficos utilizan estas técnicas para localizar los errores [10]. Un área en el que ha cobrado una gran importancia la correspondencia aproximada de cadenas ha sido en el del Data Cleaning. El Data Cleaning [11] es un proceso de tratamiento de colecciones de datos, como archivos o bases de datos. Busca conseguir datos limpios de duplicados, corregir errores tipográficos, desarrollar abreviaciones, evitar campos no informados, corregir campos contradictorios, etc. Herramientas de normalización terminológica Existen diversos tipos de herramientas para la normalización terminológica. Algunas buscan correspondencias directas con términos a partir de texto libre, como hace MedLine [12], otras herramientas realizan un preprocesado más o menos complejo, IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 20 como puede ser hacer una limpieza signos de puntuación o desarrollar las abreviaturas, a fin de encontrar correspondencias por búsqueda por palabras. Intelligent Mapper es una aplicación para codificar pruebas locales de radiología en inglés a la terminología LOINC. Busca correspondencias directas entre palabras, y para que el proceso sea efectivo es necesaria una normalización previa de los términos que componen la descripción de la prueba [13]. Otro enfoque distinto a lo realizado en Intelligent Mapper es utilizar tablas de sinónimos para cada uno de los ejes de LOINC, de modo que si una prueba de laboratorio está dentro de una tabla de sinónimos que la relaciona con el término LOINC correspondiente se encuentra una correspondencia directa [14]. 21 5. Materiales y métodos En este apartado se describe el material y los métodos utilizados para conseguir alcanzar el objetivo de nuestro proyecto. La sección está dividida en tres subapartados correspondientes a las principales etapas de desarrollo: implementación del motor de comparación, implementación de la interfaz gráfica e implementación de mejoras. El motor de comparación A fin de comparar las pruebas de laboratorio locales con las ya mapeadas1 en el servidor terminológico, se implementa un motor de comparación basado en técnicas de approximate string matching. El motor de comparación que usará SANT utiliza una de las siguientes técnicas analizadas. A continuación se describen dichas técnicas y los experimentos realizados para la elección de la técnica más apropiada. Modelos matemáticos de string matching Para calcular la similitud entre términos se hace uso de técnicas de búsqueda aproximada de cadenas, más comúnmente conocidas por su término en inglés approximate string matching [15]. Estas técnicas consisten en aplicar una función de similitud a dos cadenas simil(c1, c2), donde c1 es la cadena para la cual queremos encontrar una coincidencia y c2 es una cadena de nuestro documento objetivo (en nuestro caso el documento objetivo es un servidor terminológico), y obtener a partir de ella una puntuación. Si dicha puntuación supera un umbral µ, ajustado según conveniencia, se añade ésta al conjunto de resultados. La cadena con la mejor puntuación será la candidata principal. Las técnicas implementadas en el motor de comparación son aquellas basadas en la descomposición del término en unidades básicas. Este proceso se denomina tokenización, y como resultado del proceso obtendremos un conjunto de tokens, o lo que es lo mismo, de Q-gramas, es decir, subcadenas de tamaño Q [16]. Veamos una explicación más detallada a continuación. 1 El término mapping proviene del término inglés Data Mapping, muy utilizado en la literatura, que indica el proceso de establecer relaciones sinónimas entre dos conceptos. IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 22 Dada una cadena c se introducen caracteres de inicio y de final de cadena (# y $ u otros símbolos no existentes en el alfabeto utilizado) y se obtiene una lista de Q-gramas mediante el uso de una ventana de tamaño q que se deslizará a través de los caracteres de la cadena: Cadena original c Posición de la ventana Q-Grama extraído Lista de Q-gramas Glucosa [#G]lucosa$ [#G] [#G] #[Gl]ucosa$ [Gl] [#G][Gl] #G[lu]cosa$ [lu] [#G][Gl][lu] #Gl[uc]osa$ [uc] [#G][Gl][lu][uc] #Glu[co]sa$ [co] [#G][Gl][lu][uc][co] #Gluc[os]a$ [os] [#G][Gl][lu][uc][co] #Gluco[sa]$ [sa] [#G][Gl][lu][uc][co][sa] #Glucos[a$] [a$] [#G][Gl][lu][uc][co][sa][a$] Figura 1: Ejemplo del proceso de tokenización Un grupo de técnicas de string matching hacen uso de las operaciones de teoría de conjuntos aplicadas al conjunto de tokens generados por el proceso de tokenización para calcular la similitud entre cadenas. Como Intersect y Jaccard [17]. Una especialización de las técnicas descritas son aquellas que además de utilizar los conjuntos de tokens, les proporcionan un peso relativo a su frecuencia de aparición, de modo que puntúa más un token poco común que uno muy común, dando cuenta de la importancia de cada uno de ellos. La técnica cosineTFIDF [18] es de este tipo. Otro tipo de funciones utilizadas son las basadas en distancias, como las distancias de edición de Levenshtein [19]. Existen métodos que combinan estas dos ideas, denominados métodos híbridos, como Monge Elkan [20] y SoftTFIDF [21]. Intersect es una técnica sencilla y barata desde el punto de vista computacional. El coeficiente de similitud Intersect entre dos cadenas c1 y c2 es la cantidad de tokens presentes en ambas. Dando como resultado un coeficiente sin normalizar: Para obtener un resultado normalizado se propone utilizar el coeficiente de Dice [22], consiguiendo así un resultado entre 0 y 1: Jaccard es una técnica muy similar a la anterior, pero en este caso su resultado sí se normaliza, y lo hace en base a la unión de tokens existentes en ambos conjuntos de tokens a comparar. Entonces, el coeficiente de similitud de Jaccard entre dos cadenas c1 y c2 es el cociente de la cantidad de tokens presentes tanto en c1 como en c2 entre la suma de ambas cantidades: 23 Cosine Tf-Idf trata de encontrar la similitud coseno entre dos cadenas c1 y c2. La similitud coseno entre dos vectores v1 y v2 consiste en calcular el producto escalar de ambos y dividirlo por la raíz cuadrada del sumatorio de los componentes del vector w1 por la raíz cuadrada del sumatorio de los componentes del vector w2. Para ello es necesario dar un peso a cada uno de lo tokens que indique la relevancia de dicho token en términos de frecuencia de aparición, de modo que compongamos los vectores w1 y w2. Y la función para calcular el peso normalizado de un token es: Donde tf (term frequency) es la frecuencia del token en la cadena e idf (inversal document frequency) es la frecuencia del token en todo el documento o conjunto de cadenas. Levenshtein consiste básicamente en calcular el coste de transformar una cadena en otra: Donde s1, s2, s3... definen el coste de secuencias de operaciones de edición tales como copia, inserción, substitución y borrado a realizar para convertir la cadena c1 en c2. El resultado es peor cuanto mayor sea este coste, es decir, las cadenas son más diferentes. En Monge Elkan el cálculo de la función de similitud se hace a partir del cálculo de las distancias mínimas de edición entre tokens, y normalizando con respecto al tamaño en tokens de la cadena origen: Donde simil’ es una función secundaria basada en distancias, una variante de la métrica de Levenshtein, K es la cantidad de tokens de c1 y L es la cantidad de tokens de c2. Y por último, en la técnica SoftTFIDF el token se pondera según una función entre las frecuencias de aparición del token en la cadena a comparar y en el banco de datos general, de manera intuitiva cuanto más frecuente sea el token menos significativo resulta. IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 24 Elección de la técnica de string matching En esta sección describiremos la fase de experimentación. Mediante los experimentos que a continuación se indican se pretende dar una medida cuantitativa de la eficacia de cada uno de los métodos expuestos anteriormente. Los resultados de estos experimentos nos permitirán tomar una decisión en cuanto a qué método elegir para implementar en nuestra herramienta de normalización terminológica. Dentro del grupo IBIME, donde se ha desarrollado este proyecto, se realizó un estudio que englobaba diversas técnicas de string matching y se analizaban desde un punto estadístico para decidir qué técnica era la más apropiada [23]. Este estudio compara las técnicas Jaccard, Levenshtein, Monge-Elkan y SoftTF-IDF descritas anteriormente y concluye que la técnica Jaccard usando una tokenización en Q-gramas de 2 es la más apropiada. A continuación se describen los experimentos que se han realizado para este proyecto, comparando las técnicas Intersect, Jaccard y CosineTF-IDF anteriormente descritas que complementa al estudio anterior y que llegan a la misma conclusión de que la técnica adecuada para nuestra herramienta es Jaccard utilizando Q-gramas de 2. Planteamiento Para realizar los experimentos necesitamos, dado el banco de datos del servidor terminológico B, que contiene por una parte un conjunto de términos de la terminología de referencia LOINC L y por otra un conjunto de términos de diversos centros que han sido normalizados mediante el código Bitac C (compartido por el término LOINC y éste), extraer un conjunto de pruebas P suficientemente grande para ser representativo. Por ello, se escogen 3.000 términos de entre los que conforman el conjunto C, que suponen aproximadamente una décima parte de éstos, asegurándose así que siempre existirá al menos un sinónimo de cada término del subconjunto de prueba, el representante LOINC, dentro del conjunto L. Este subconjunto P obtenido se elimina del servidor terminológico B para que no interfiera en el análisis y sobre él se aplicarán cada una de las técnicas de string matching expuestas para comparar su eficacia. Entonces, por cada prueba de P se obtiene un conjunto de resultados o candidatos asociados ya a un código enlace con la terminología LOINC, estos resultados están ordenados por la puntuación de similitud. La eficacia del método analizado la mediremos en función del porcentaje de aciertos, considerando acierto el hecho de encontrar una prueba candidata correcta entre los 10 primeros resultados. Se ha elegido el número 10 porque el técnico especialista puede revisar fácilmente 10 resultados de un solo vistazo y así fue planteado en la especificación de requisitos. Estos experimentos se harán utilizando, además de las técnicas descritas, distintos tipos de tokenización de manera que comprobemos la eficacia de cada una de las técnicas usando Q-gramas de tamaño 2 y 3. 25 Resultados Como resultado de los experimentos, véase figura 2 obtenemos que efectivamente la eficacia de la técnica Jaccard con tokenización de Q-gramas de 2 es la mayor, en torno a un 64%, seguida por la técnica Intersect con un 62%, que es muy parecida en implementación, y por último por la técnica Cosine TF IDF, que a pesar de ser una de las técnicas más elaboradas ya que necesita de un preprocesamiento de la base de datos para extraer la frecuencia de cada uno de los tokens del documento general y del término analizado, no consigue buenos resultados en comparación, quedándose en el mejor de los casos en un 52% de acierto. Figura 2: Comparación de las técnicas de string matching en base a su eficacia Por lo tanto estos resultados respaldan también la decisión de tomar la técnica Jaccard con una tokenización en Q-gramas de 2 como la adecuada para ser implementada en el motor de comparación de SANT. Implementación de la interfaz En este apartado se procede a explicar las decisiones tomadas para la implementación de la interfaz gráfica para nuestro sistema. Desarrollo web Uno de los requisitos era obtener una herramienta ubicua, capaz de conectarse con el servidor terminológico, por lo tanto la opción más lógica era decantarse por una aplicación web, accesible desde cualquier equipo con un navegador compatible y una conexión a Internet. 0 20 40 60 80 Intersect Jaccard CosineTFIDF Porcentaje de acierto Técnica de String Matching Comparación de las técnicas de String Matching en función del porcentaje de acierto Q-Grams=3 Q-Grams=2 IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 32 Por ejemplo, si la prueba local “Calcio - orina” debería mostrar sólo aquellas pruebas cuya muestra sea “orina”, de este modo se limitaría de manera importante el número de pruebas a analizar. En el ejemplo siguiente se puede ver más claramente cómo actúa el filtrado por eje, filtrando aquellas pruebas irrelevantes: Prueba analizada Eje temporalidad Eje muestra Eje tipo Calcio 24 h 24 H Orina Qn Calcio en orina Orina Calcio índice Sangre Calcio Suero Número Cociente calcio/creatina Orina Calcio en orina Orina Número Calcio iónico Sangre Qn Calcio/creatina 24H Orina Qn Tabla 5: Ejemplo de funcionamiento del filtrado por ejes Conseguimos así descartar aquellos mappings incorrectos por tener información distinta en los ejes, de esta forma mejoramos la eficiencia del motor de comparación ya que tendrá que hacer un menor número de comparaciones y mostramos sólo resultados relevantes al usuario. Filtrado por ejes postproceso Aun habiendo reducido considerablemente la lista de pruebas, es posible que la lista de resultados sea amplia, y el técnico especialista conozca más información por contexto de la que proporcionaba la prueba de laboratorio no estandarizada. Para esos casos la aplicación incorpora unos filtros postproceso que permiten filtrar la lista de resultados de acuerdo con una búsqueda por correspondencia directa de cadenas. De esta manera se facilita la tarea de revisión de resultados, haciéndola más fácil y rápida. Tablas de sinónimos La información de un eje debe pertenecer al conjunto de opciones de la terminología de referencia, sin embargo, del mismo modo que ocurre con el nombre del concepto, también existe variabilidad en la forma de expresarlo debido a posibles abreviaturas, traducciones, nombres alternativos, errores tipográficos, etc. Para que el filtrado sea efectivo, dos conceptos deben ser comparables. Para ello es necesario mantener unas tablas de sinónimos que enlacen las variaciones con su término (o incluso varios términos en algunas ocasiones) estándar. Por ejemplo, en el caso de la muestra “sangre” el término estándar en la terminología LOINC es “Bld”, también lo es para “Sang”, “blood”, “sangre-jeringa”… 33 Un ejemplo del contenido de estas tablas de sinónimos es: Muestra Método BLD Automated count Sangre Contadores electrónicos Sang Contador celular automático Sang TOTAL Fluorescencia Sang edta Flujo y reconocimiento de imagen SANGRE EDTA Automatizado Blood Citometría de flujo Sangre-jeringa Citometría … … Tabla 6: Ejemplo de tablas de sinónimos La plataforma proporciona una herramienta de mantenimiento que muestra aquellos términos por eje que aún no han sido relacionados con un término estándar, y el especialista puede agregar la relación o bien editar cualquiera ya existente. De este modo no es necesario que los ejes de las pruebas analizados estén informados en su manera estándar, con cualquier sinónimo incluido en las tablas es suficiente. Obtención de ejes En algunos casos la información de algunos ejes no se proporciona en el eje adecuado y, en su lugar, se encuentra junto con la descripción del concepto. Para estos casos se ha desarrollado una herramienta de preprocesado del lote que consiste en extraer dicha información de la descripción e incluirla en el eje adecuado. En todo caso el especialista puede descartar los cambios o incluso refinar el resultado mediante la edición del eje afectado. Descripción Prop Tiempo Muestra Tipo Método Calcio en orina orina Complemento C7 en suero suero Calcio 24H Qn Aminoácidos en orina orina Aminoácidos suero/plasma suero/plasma Hepatitis A IgG (EIA) Número EIA Toxoplasma en líquido amniótico PCR líquido amniótico PCR Albúmina en suero suero Qn Nefelometría Tabla 7: Ejemplo de algunos ejes extraídos a partir de la descripción De esta forma ahora es posible refinar los resultados ya que podría aplicarse el filtrado por ejes descrito anteriormente. IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 34 Valores por omisión En otros casos la información de los ejes simplemente no ha sido proporcionada, sin embargo el especialista puede conocerla gracias a su experiencia y conocimiento del contexto. Para estos casos SANT proporciona una herramienta mediante la cual es posible aplicar un valor por omisión a un eje seleccionado de entre el conjunto de términos del vocabulario estándar. Dado el ejemplo anterior, si queremos que las pruebas para las que no se ha informado el eje muestra tomen un valor por omisión podemos seleccionarlo y el resultado sería como a continuación se indica: Descripción Prop Tiempo Muestra Tipo Método Calcio en orina orina Complemento C7 en suero suero Calcio 24H orina Qn Aminoácidos en orina orina Aminoácidos suero/plasma suero/plasma Hepatitis A IgG (EIA) orina Número EIA Toxoplasma en líquido amniótico PCR líquido amniótico PCR Albúmina en suero suero Qn Nefelometría Tabla 8: Ejemplo de aplicación del valor por omisión 'orina' Del mismo modo que con la obtención de ejes, mejoramos el filtrado por eje, refinando el conjunto de resultados final. Criterios de ordenación: método y ranking Dentro del conjunto de resultados puede haber pruebas más relevantes que otras, incluso cuando han obtenido la misma puntuación de similitud. Para reflejar esto, se han incluido los siguientes criterios de ordenación: Por método: generalmente si el método ha sido especificado en la prueba de laboratorio local es porque es relevante y necesaria para diferenciar el término LOINC. El conjunto de resultados se ordenará por tanto siguiendo este criterio. Dada una misma similitud tendrá una mayor preferencia aquella prueba que tenga el eje método especificado. Por ranking: El ranking es un campo de LOINC, nuestra terminología de referencia. LOINC ha escogido las 2000 pruebas más comunes y las ha ordenado por frecuencia de uso. De modo que la prueba LOINC más utilizada es aquella con ranking igual a 1. Dada una misma similitud las pruebas del conjunto de resultados se ordenan, como segundo criterio, según el ranking. 35 Casos de uso A continuación se describirán las principales acciones que puede realizar el usuario en nuestra aplicación, los cuales conforman los distintos casos de uso. Figura 5: Diagrama de los Principales Casos de Uso Login La pantalla de login es la pantalla inicial. Se muestra los campos de textos para introducir usuario y contraseña y el botón “Entrar”. Tras pulsar el botón “Entrar” el sistema comprueba los datos en la base de datos, si los datos son correctos la aplicación llevará a la pantalla de trabajo, si los datos son erróneos muestra un mensaje de error. Figura 6: Pantalla inicial que muestra un error de login IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 36 Procesar lote La pestaña Lotes permite por una parte realizar las tareas de preprocesado de las pruebas de laboratorio de los lotes antes de ser enviados al motor de comparación y por otra parte enviar a procesar el lote con una configuración determinada. A continuación se muestra en el diagrama de casos de uso las distintas acciones posibles: Figura 7: Caso de Uso "Procesar Lote" Listar Lotes Al entrar en la pestaña de Lotes se listan los lotes que el usuario ha preparado con antelación (creados desde una aplicación externa, pero gestionados por la nuestra), y que están ya disponibles en la base de datos. Figura 8: Lista de lotes 37 Actualizar Lista de Lotes Si otro lote es creado mientras el usuario está en la pestaña de Lotes, es posible refrescar la vista de lotes mediante un botón. Figura 9: Botón para actualizar la lista de lotes Listar Pruebas de un Lote Seleccionando la fila correspondiente a un lote es posible listar todas las pruebas que lo componen. Figura 10: L lista de pruebas que contiene el lote seleccionado IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 38 Obtener Ejes Una parte de preprocesado del lote es la obtención de ejes, esto es un proceso mediante el cual se buscan muestras, métodos y unidades válidas dentro de la descripción de cada una de las pruebas de laboratorio que componen el lote y se extraen al eje correspondiente para que pueda ser aplicado el filtrado correctamente. Para ejecutar la herramienta se dispone de un botón “Obtener Ejes” por cada uno de los lotes listados. Figura 11: Botón para ejecutar la función de obtención de ejes Editar Ejes Es posible editar los datos extraídos de la descripción si el usuario considera que no son correctos. Pulsando el botón “Editar Ejes” se accede a una ventana de edición de los ejes que han sido modificados en el proceso de obtención de ejes. Figura 12: Ventana de edición del eje muestra obtenido a partir de la descripción 39 Valores por Omisión Otra herramienta para el preprocesado del lote que puede utilizar el usuario es la asignación de valores por omisión (default assumptions) a ejes no informados en la prueba de laboratorio evaluada. Al pulsar el botón “Default Assumptions” accedemos a una ventana donde se puede seleccionar para los ejes muestra, método y propiedad un término del estándar LOINC a aplicar durante la fase de filtrado. La selección se realiza mediante un desplegable, y se aplicará a aquellas pruebas del lote que tengan el campo correspondiente al eje seleccionado vacío. Figura 13: Ventana de Default Assumptions Editar Configuración Desde esta misma pestaña es posible cambiar la configuración de envío del lote. Una barra superior facilita esta tarea desde la misma pestaña que se mandan los lotes al motor de comparación. En esta barra se puede seleccionar mediante un desplegable el umbral de similitud a aplicar (por debajo del cual no se mostrarán resultados), el número máximo de resultados a mostrar y qué filtros aplicar durante el procesado del lote. Además es posible aquí también seleccionar sobre qué ejes actuará la función de obtención de ejes anteriormente descrita. Figura 14: Barra de configuración IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 40 Enviar El caso de uso principal en la pestaña de Lotes es la función de envío del mismo. Se dispone de un botón “Enviar” para cada lote. Además se puede observar el progreso de análisis del mismo mediante una barra de progreso habilitada en la misma línea. Figura 15: Botón para enviar el lote al motor de comparación 41 Validar lote A continuación se describen los casos de uso correspondientes a la pestaña de validación. En este punto los lotes ya han sido analizados por el motor de comparación y por tanto se pueden revisar los resultados. Figura 16: Caso de Uso "Validar Lote" IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 48 Modificar Tabla de Tiempos Asociados a la Muestras Una característica común de las pruebas sin normalizar es que en un único eje de la prueba no estandarizada puede contener información de varios ejes estándar. Esto ocurre con mucha frecuencia en el eje muestra, donde se suele informar también el eje tiempo (o temporalidad). Para poder aplicar los filtros adecuadamente se han creado unas tablas que dividen la información de la muestra proporcionada por la prueba no estandarizada. Para gestionar la tabla se dispone de la siguiente funcionalidad: Figura 29: Ventana de gestión de la tabla de tiempos asociados a muestras 49 Gestión de Sinónimos por Lote Mediante la función de gestión de sinónimos por lote podemos asignar nuevos sinónimos a los ejes de LOINC a partir de nuevas muestras, métodos o unidades que aparezcan en las pruebas de un lote. Pulsando el botón correspondiente se abre una nueva ventana para la gestión de estos sinónimos. Aparece un desplegable donde podemos seleccionar sobre qué eje actuar, posteriormente podremos seleccionar el lote y el término estándar al que queremos asociar un nuevo sinónimo de los listados en la tabla izquierda. En la tabla de la derecha se muestran los sinónimos del término seleccionado. Figura 30: Ventana de gestión de sinónimos por lote IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 50 Búsqueda directa en LOINC La pestaña LOINC permite acceder a una parte de la página web externa http://loinc.org que ofrece una herramienta de búsqueda por palabras de términos LOINC. Se trata de una función de apoyo y consulta para el técnico. Al pulsar la pestaña LOINC se carga en el marco principal de la aplicación la página de búsqueda mencionada. Figura 31: Pestaña LOINC para la búsqueda externa de términos Logout Sobre la barra de pestañas, en el margen derecho, se muestra el mensaje de bienvenida al usuario y el botón para cerrar sesión. Pulsando el botón logout la aplicación vuelve a la pantalla inicial. Figura 32: Botón logout 51 7. Resultados Para evaluar los resultados del proyecto se muestra el ciclo del proceso de análisis y validación completo para un lote de pruebas. Este lote de pruebas ha sido compuesto por la empresa BITAC especialmente para reflejar la casuística del problema. El lote se compone de 157 pruebas reales pertenecientes a distintas áreas de laboratorio para las cuales ya se conoce su código Bitac correcto. Lo que se pretende es, ignorando el código Bitac ya existente, buscar mappings con el resto de pruebas del servidor terminológico y verificar si se encuentra o no el resultado correcto. El primer paso la obtención de ejes no informados a partir de la descripción, para ello ajustamos la configuración, indicando que intente extraer la muestra, el método y la unidad, y pulsamos el botón “Obtener Ejes”. Posteriormente revisamos los resultados: Descripción Unidades Muestra Método ENZIMA CONVERTIDOR ANGIOTENSINA SUERO U/L suero Espectrofotometría UltravioletaVisible GASTRINA EN SUERO pg/mL suero Radioinmunoensayo (RIA) CALCITONINA HUMANA / SUERO pg/mL suero Radioinmunoensayo (RIA) 5-HIAA EN ORINA 24H mg/dL orina 24h Cromatografía Líquida de Alta Resolución (HPLC) / detector electroquímico ANTICUERPOS IgM ANTI EPSTEIN-BARR [EARLY] EN SUERO TITULO suero Inmunofluorescencia indirecta. Acs VIH 1 Y 2 + Ag p24 (ELFA) 1 SUERO Quimioluminiscencia ZINC EN SERUM µg/dL serum Espectroscopía de Absorción Atómica / Llama COBRE EN SUERO µg/dL suero Espectroscopía de emisión atómica en plasma por acoplamiento (ICP-MS) Tabla 9: Pruebas que incluyen información de alguno de sus ejes en su descripción Como se puede observar en la tabla 9, se ha extraído información a partir de la descripción para 8 pruebas. En un caso se ha realizado incorrectamente, es el caso de la prueba “Acs VIH 1 Y 2 + Ag p24 (ELFA)”. En este caso se ha extraído incorrectamente el “1” en el eje unidad. Es posible corregir este error mediante la herramienta de edición: Figura 33: Ventana de edición de ejes obtenidos IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 52 Una vez corregido el error, se comprueba si es necesario aplicar algún Default Assumption, recordemos que al seleccionar un valor por omisión, éste se aplicará sobre todos los campos del eje al que corresponda que se encuentren vacíos, por ejemplo, al seleccionar “Ser/Plas” en nuestro lote, se aplicaría a todas aquellas pruebas que posean el campo muestra vacío. Sin embargo, en nuestro caso no es posible aplicar un valor por omisión debido a la heterogeneidad del lote. Llegados a este punto ya se puede enviar el lote al motor de comparación. Ajustaremos la configuración de envío para que utilice los filtros de muestra, método y unidad(o propiedad). Indicaremos un número máximo de resultados de 10, para que los resultados sean comparables con los experimentos realizados para la técnica de string matching utilizada (Jaccard). Figura 34: Configuración aplicada Una vez completado el análisis del motor de comparación se puede proceder a la validación de las pruebas. En la pestaña correspondiente seleccionamos nuestro lote y procedemos a validar los resultados, marcando aquellas pruebas para las que hemos encontrado al candidato correcto. Figura 35: Marcado de pruebas que han encontrado un candidato correcto 53 De las 157 pruebas del lote se han conseguido validar 146. Esto supone haber encontrado candidato para el 93% de las pruebas. Si comparamos los resultados con los que obteníamos utilizando la técnica Jaccard sin aplicar ninguna de las mejoras que aporta la aplicación observamos una mejora considerable que supone elevar la tasa de acierto en un 30%. Figura 36: Gráfica comparativa de la eficacia en cada caso En definitiva se ha conseguido desarrollar una plataforma de trabajo para la normalización terminológica con LOINC que se integra dentro del servidor terminológico del cliente de forma que se facilita la comunicación con él, tanto para la exportación de pruebas no estandarizadas como para la importación de resultados, y que automatiza el proceso de búsqueda de candidatos mediante un motor de comparación basado en técnicas de correspondencia aproximada de cadenas. Gracias a que SANT se integra dentro del servidor terminológico y a su motor de comparación es posible realizar la búsqueda de términos estandarizados sin necesidad de preprocesado del término no estandarizado (lo que implicaría entre otras cosas la traducción del término al lenguaje de la terminología estándar, en este caso al inglés). De esta forma se consigue ahorrar una cantidad de tiempo muy importante al usuario ya que se reduce sustancialmente la carga de trabajo manual. Por otra parte, el usuario también ve facilitada su labor de búsqueda del candidato correcto mediante las herramientas proporcionadas por SANT que reúne los resultados en una sola ventana, y proporciona una interfaz sencilla y práctica. Una vez el especialista encuentra el mapping apropiado, es posible incorporar este resultado al servidor terminológico para que pase a formar parte de futuras búsquedas. Esto en definitiva es un proceso de realimentación de la base de conocimiento. LOINC es un lenguaje en pleno desarrollo, y por tanto es posible encontrar pruebas de laboratorio que no han sido incorporadas aún a la terminología. Para facilitar este proceso SANT ofrece una herramienta que facilita que estas pruebas se marquen de una manera especial en el servidor terminológico para su posterior envío al organismo responsable del mantenimiento de LOINC. 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Jaccard SANT Comparación de eficacia IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 54 8. Conclusiones Una vez analizados los inconvenientes actuales de la normalización terminológica con LOINC se plantea la implementación de SANT, un sistema de ayuda a la normalización terminológica integrado en el servidor terminológico de BITAC. Para implementar el motor de comparación de nuestro sistema se han analizado distintas técnicas de correspondencia aproximada de cadenas. Tras la realización de experimentos para comprobar la eficacia de cada una de las técnicas consideradas se escoge Jaccard por resultar la más efectiva y ser además de complejidad baja lo que repercute en un mayor rendimiento del motor de comparación. Para la implementación de la interfaz gráfica de usuario se han comparado distintos frameworks de desarrollo web, decantándonos por Vaadin, un framework de última generación que ofrece gran cantidad de documentación, contenido pregenerado en forma de componentes y addons, y un rendimiento óptimo. Hemos aportado mejoras a nuestro sistema para incrementar la eficacia del motor de comparación en forma herramientas de preprocesado de pruebas (obtención de ejes a partir de la descripción, aplicación de valores por omisión), uso de filtros por ejes de LOINC durante el proceso de análisis dentro del motor de comparación y herramientas de búsqueda en el proceso de validación para facilitar el trabajo del usuario. Se han demostrado los beneficios de SANT como sistema de ayuda a la normalización terminológica, ahorrando una sustancial carga de trabajo al técnico especialista y facilitando las tareas de creación de mappings y propuesta de incorporación de nuevos términos LOINC. 55 9. Trabajo futuro Actualmente se está trabajando en una nueva versión del sistema que incluye nuevas mejoras. Una de las nuevas técnicas consiste en mejorar la explotación de la información que nos proporciona el servidor terminológico mediante la extracción de, lo que hemos llamado, los sinónimos por componente. Mediante este proceso se consigue que pruebas ya estandarizadas que tenían pocos sinónimos y de bajo parecidos a la prueba analizada, ahora puedan mostrarse en los resultados, reduciendo así el número de falsos negativos. Otra herramienta que se quiere incorporar próximamente es la validación automática de pruebas. Esto es, según unos criterios a determinar, se podrán validar de forma automática las pruebas analizadas, sin intervención del técnico especialista. A esta nueva versión del proyecto se le ha denominado SAM (Automatic Mapping System). Como trabajo futuro adicional se plantea el uso del sistema desarrollado con otras terminologías clínicas como por ejemplo para SNOMED-CT, terminología clínica de gran aceptación dentro de la comunidad experta en normalización e interoperabilidad semántica que actualmente se está implantando en gran parte de los centros hospitalarios a nivel internacional y recientemente adoptada por el sistema nacional de salud. IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 56 10. Agradecimientos Me gustaría que estas líneas sirvieran para expresar mi más profundo y sincero agradecimiento a todas aquellas personas que con su ayuda han colaborado en la realización del presente trabajo, en especial a la Dra. Montserrat Robles Viejo por darme la oportunidad de trabajar en algo que me apasiona, a mi codirector el Dr. Jose Alberto Maldonado Segura por la orientación, el seguimiento y la supervisión continua del proyecto, a ambos por la motivación y el esfuerzo por que este proyecto llegara a buen término. Expresar mi profundo agradecimiento a BITAC, por darme la oportunidad de trabajar en este proyecto tan interesante y por dedicarle un tiempo precioso, Toni, Mireia, Vicky, por empujarme a mejorar más y más. Gracias a todos mis compañeros en IBIME por toda la ayuda prestada, por el buen ambiente de trabajo que generan y por enriquecer en general mi vida profesional y personal. Un agradecimiento muy especial merece la comprensión, paciencia y el ánimo recibidos de mi familia y amigos. A todos ellos, muchas gracias. 57 11. Bibliografía 1. Cimino JJ. Saying what you mean and meaning what you say: coupling biomedical terminology and knowledge. Academic medicine : journal of the Association of American Medical Colleges. 1993 Apr;68(4):257-260. 2. Rector AL. Clinical terminology: Why is it so hard. In: Methods of Information in Medicine; 1999. p. 239-252. 3. Chute CG. Clinical Classification and Terminology. Journal of the American Medical Informatics Association. 2000 May;7(3):298-303. 4. Forrey AW, McDonald CJ, DeMoor G, Huff SM, Leavelle D, Leland D, et al. Logical observation identifier names and codes (LOINC) database: a public use set of codes and names for electronic reporting of clinical laboratory test results. Clinical Chemistry. 1996 Jan;42(1):81-90. 5. Committee on Data Standards for Patient Safety. "Front Matter." Patient Safety: Achieving a New Standard for Care. Washington, DC: The National Academies Press, 2004. 6. Sellers PH. On the theory and computation of evolutionary distances. SIAM Journal on Applied Mathematics. 1974 Junio; 26(4): p. 787-793. 7. Levenshtein VI. Binary codes capable of correcting spurious insertions and deletions of ones. Problems of information transmission. 1965; 1(1): p. 8. 8. Masui T. An efficient text input method for pen-based computers. In Co. APWP, editor. Proceedings of the SIGCHI conference on Human factors in computing systems; 1998; New York. p. 328-335. 9. Lasko TA, Hauser SE. Approximate string matching algorithms for limitedvocabulary OCR output correction. Society of Photo-Optical Instrumentation Engineers (SPIE) Conference Series. 2000 December; 4307: p. 232-240. 10. Angell RC, Freund GE, Willet P. Automatic spelling correction using a trigram similarity measure. Information Processing & Management. 1983; 19(4): p.255-261. 11. Rahm E, Do HH. Data Cleaning: Problems and Current Approaches. In: IEEE Data Engineering Bulletin. vol. 23; 2000. 12. Kreuzthaler M, Bloice MD, Faulstich L, Simonic KM, Holzinger A. A Comparison of Different Retrieval Strategies Working on Medical Free Texts. Journal of Universal Computer Science. 2011 Apr;17(7). 13. Vreeman DJ, McDonald CJ. A comparison of Intelligent Mapper and Document Similarity Scores for Mapping Local Radiology Terms to LOINC. In AMIA Annual Symposium proceedings; 2006. p. 809-813. IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 64 En otros casos la información de los ejes simplemente no ha sido proporcionada, sin embargo el especialista puede conocerla gracias a su experiencia y conocimiento del contexto. Para estos casos SANT proporciona una herramienta que permite aplicar un valor por omisión a un eje, seleccionado de entre el conjunto de términos del vocabulario estándar. Otros parámetros de configuración que el usuario puede modificar son: el umbral de similitud a aplicar en la técnica de string matching y el número máximo de candidatos a mostrar. 4.3. Tratamiento de los resultados Una vez el motor de comparación ha volcado los resultados, el especialista comienza el proceso de comprobación (ver figura 3) que consiste en verificar si el candidato propuesto es acertado. Si el primer candidato no es correcto se puede seleccionar otro entre un conjunto de candidatos que se despliegan al seleccionar el concepto. SANT proporciona una herramienta de búsqueda por cadenas entre los resultados en el caso de preferir la búsqueda directa a la navegación. Consiste en un filtro por caracteres, y se han incluido para los ejes más comúnmente utilizados. En caso de encontrar un candidato correcto para el concepto éste puede ser seleccionado para posteriormente ser incorporado a la base de datos local con el código de enlace correspondiente que lo relaciona con la terminología de referencia. En caso de no encontrar candidato correcto el usuario tiene varias opciones, puede volver a lanzar el motor de comparación con una configuración menos restrictiva que devuelva un mayor número de candidatos, puede marcar una incidencia mediante un Figura 3: Captura de pantalla de la plataforma SANT 65 desplegable incorporado especialmente para ese caso o incluso introducir un código de enlace manual. 5. Conclusiones Se ha presentado la plataforma SANT, se ha conseguido un entorno integrado y completo, independiente de herramientas externas para la importación de términos locales y exportación de términos ya normalizados. Como indican los datos, las técnicas de búsqueda aproximada consiguen un acierto en el 70% de los casos, esto, unido a las herramientas proporcionadas por la plataforma, facilita la tarea de la normalización terminológica, reduciendo la complejidad del proceso y el tiempo que un especialista debe emplear en él. Referencias [1] A. Forrey, C. McDonald, G. DeMoor, S. Huff, et al. Logical observation identifier names and codes (LOINC) database: a public use set of codes and names for electronic reporting of clinical laboratory test results. Clinical Chemistry, 42 (1), 81-90 (1996). [2] A. Chandel, O. Hassanzadeh, N. Koudas, M. Sadoghi y D. Srivastava. Benchmarking declarative approximate selection predicates. SIGMOD '07. 353-364 (2007). [3] E. Ukkonen. Approximate String Matching with q-Grams and Maximal Matches. Theorical Computer Science, 92 (1), 191-211 (1992). [4] S. Sarawagi y A. Kirpal. Efficient set joins on similarity predicates. SIGMOD’04. 743-754 (2004). [5] D. Gusfield. Algorithms on strings, trees, and sequences: computer science and computational biology. Cambridge University Press (1997). [6] A. Monge y C. Elkan. The Field-Matching Problem: Algorithm and Applications. Proc. 2nd ACM SIGKDD Int’l Conf. Knowledge Discovery and Data Mining, AAAI Press. 267–270 (1996). [7] W. W. Cohen, P. Ravikumar, and S. E. Fienberg. A comparison of string distance metrics for Name-Matching tasks. IJCAI-03 Workshop on Information Integration. 73-78 (2003) IMPLEMENTACIÓN DE TÉCNICAS DE STRING MATCHING Y SELECCIÓN SEMÁNTICA APROXIMADA EN UN MOTOR DE NORMALIZACIÓN TERMINOLÓGICA 66