extracciÓn de metadata extensional a partir de tÉcnicas de

EXTRACCIÓN DE METADATA EXTENSIONAL A PARTIR DE TÉCNICAS DE MINERÍA DE DATOS

PROYECTO ARIBEC

Diego Andrés Ardila Álvarez – Natalia Valencia Lesmes

Asesor: José Eusebio Abásolo Prieto Profesor Asociado

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C. ENERO 2009

[1]

CONTENIDOS

Lista de tablas y figuras ................................................................................................................................ 4

Figuras ............................................................................................................................................................ 4

Ilustraciones ................................................................................................................................................. 4

Tablas .............................................................................................................................................................. 4

I. Introducción ............................................................................................................................................. 6

II. Contenido informe ................................................................................................................................. 7

III. Objetivos del proyecto ..................................................................................................................... 8

Objetivo general .......................................................................................................................................... 8

Objetivos específicos ................................................................................................................................. 8

IV. Marco teórico ...................................................................................................................................... 9

Ontologías ...................................................................................................................................................... 9

Knowledge discovery .............................................................................................................................. 10

Data mining ................................................................................................................................................. 11

Técnicas ................................................................................................................................................... 12

V. ARIBEC ..................................................................................................................................................... 15

VI. Caracterización del problema ..................................................................................................... 20

VII. Propuesta de solución: OBME ..................................................................................................... 23

Ontologías .................................................................................................................................................... 24

Sobre la creación de las ontologías ............................................................................................... 25

Data extractor ............................................................................................................................................ 27

Resumen .................................................................................................................................................. 27

Data cleaner ................................................................................................................................................ 28

Resumen .................................................................................................................................................. 30

Task chooser y data mining ontology ............................................................................................... 31

Resumen .................................................................................................................................................. 32

Data transformer ...................................................................................................................................... 33

Resumen .................................................................................................................................................. 34

Data mining processor ........................................................................................................................... 35

Clustering ................................................................................................................................................ 36

Árboles de decisión ............................................................................................................................. 36

Reglas de asociación ........................................................................................................................... 36

[2]

Medidas de similitud ........................................................................................................................... 37

Presentation & rule edition .................................................................................................................. 40

Resumen .................................................................................................................................................. 42

Knowledge builder ................................................................................................................................... 42

Resumen .................................................................................................................................................. 43

VIII. Aproximación al proceso de construcción de OBME ......................................................... 44

IX. Caso de estudio: segmentación de fuentes a partir de historías clínicas. .................. 47

Entendimiento del negocio ................................................................................................................... 48

Objetivos de negocio y criterios de éxito .................................................................................... 48

Evaluar situación inicial de negocio.............................................................................................. 48

Objetivos de minería ........................................................................................................................... 51

Generación de plan de proyecto ..................................................................................................... 52

Entendimiento de datos ......................................................................................................................... 53

Recolección de datos ........................................................................................................................... 53

Descripción de datos ........................................................................................................................... 54

Exploración y verificación de calidad de datos ........................................................................ 55

Preparación de datos .............................................................................................................................. 58

Selección de datos ................................................................................................................................ 58

Limpieza de datos ................................................................................................................................ 62

Construcción e integración de datos ............................................................................................ 63

Modelamiento ............................................................................................................................................ 66

Selección técnica de modelamiento .............................................................................................. 66

Diseño de pruebas y construcción del modelo ......................................................................... 67

Evaluación del modelo ....................................................................................................................... 69

Evaluación ................................................................................................................................................... 72

Evaluación de resultados .................................................................................................................. 72

Revisión del proceso ........................................................................................................................... 72

Determinar próximos pasos ............................................................................................................ 72

Despliegue ................................................................................................................................................... 73

Plan de despliegue ............................................................................................................................... 73

Evaluación del proyecto .................................................................................................................... 73

X. Conceptualización del caso .............................................................................................................. 75

XI. Implementación de prototipo y reproducción del caso .................................................... 77

[3]

Finalidad y alcance del prototipo ....................................................................................................... 77

Diseño del prototipo ................................................................................................................................ 78

Resultados del prototipo ....................................................................................................................... 80

XII. Conclusiones ...................................................................................................................................... 81

XIII. Recomendaciones y trabajo futuro ........................................................................................... 82

XIV. Glosario ................................................................................................................................................ 84

XV. Referencias ......................................................................................................................................... 85

XVI. Anexos .................................................................................................................................................. 89

I. Plan de proyecto inicial caso de estudio ................................................................................. 90

II. Exploración de base de datos consolidada RIPs .................................................................. 91

III. Muestra archivos RIPs ............................................................................................................... 93

Muestra archivo: hospitalizaciones2006.txt ............................................................................. 93

Muestra archivo: procedimientos2006.txt ................................................................................. 93

Muestra archivo: medicamentos2006.txt ................................................................................... 93

IV. Muestra archivo WEKA ............................................................................................................. 94

V. Modelos obtenidos .......................................................................................................................... 95

Modelos k - means ............................................................................................................................... 95

Farthest first........................................................................................................................................... 98

[4]

LISTA DE TABLAS Y FIGURAS

FIGURAS

Figura 1 Estructura del documento ......................................................................................................... 7Figura 2 Esquematización general de lenguajes de web semántica ......................................... 10Figura 3 Proceso de descubrimiento de conocimientos ................................................................ 11Figura 4 Arquitectura ARIBEC ................................................................................................................. 15Figura 5 Niveles de abstracción ARIBEC ............................................................................................. 16Figura 6 Extracción de metadata extensional .................................................................................... 20Figura 7 Extracción de metadata extensional a gran escala ........................................................ 21Figura 8 Knowledge discovery guiado por ontologías ................................................................... 22Figura 9 Arquitectura OBME .................................................................................................................... 23Figura 10 Conocimiento involucrado en KD (Kuo, Lonie, Sonenberg, & Paizis, 2003) ..... 25Figura 11 Problemas de calidad de datos (Rahm & Do, 1999) ................................................... 29Figura 12 Ontología de minería de datos (Lin, Zhang, & Yu, 2006) .......................................... 32Figura 13 Conceptualización de la etapa de pre-procesamiento ............................................... 34Figura 14 Ontología de asignación de pesos ...................................................................................... 38Figura 15 Transformación segmentos a perfiles .............................................................................. 42Figura 16 Ciclo de implementación OBME ......................................................................................... 44Figura 17 Proceso de evolución de ontologías .................................................................................. 45Figura 18 Alternativa perfilamiento historias clínicas ................................................................... 60Figura 19 Hospitalización base ............................................................................................................... 62Figura 20 Corrección del nombre del medicamento ....................................................................... 63Figura 21 Distribución de tamaños segmentación KM: S=5, N=3 .............................................. 68Figura 22 Distribución de tamaños segmentación FF: S=5, N=3 ................................................ 69Figura 23 Conceptualización de caso de estudio .............................................................................. 76Figura 24 Diseño del prototipo ............................................................................................................... 79Figura 25 Detalles diseño de prototipo ................................................................................................ 79Figura 26 Proceso futuro OBME ............................................................................................................. 83

ILUSTRACIONES

Ilustración 1 Lenguaje y ontología ........................................................................................................... 9Ilustración 2 Visualización en GGobit (Blaz & Demsar, 2008) .................................................... 40Ilustración 3 Visualización KNIME (Blaz & Demsar, 2008) .......................................................... 41

TABLAS

Tabla 1 Tipos de algoritmos usados en minería ............................................................................... 12Tabla 2 Comparación entre técnicas de creación de bases de conocimiento ........................ 26Tabla 3 Resumen data extractor ............................................................................................................. 27

[5]

Tabla 4 Ejemplos de problemas de integración de fuentes .......................................................... 28Tabla 5 Resumen data cleaner ................................................................................................................. 30Tabla 6 Resumen task chooser ................................................................................................................ 32Tabla 7 Resumen data transformer ....................................................................................................... 34Tabla 8 Resumen data mining processor ............................................................................................ 39Tabla 9 Resumen presentation ................................................................................................................ 42Tabla 10 Resumen knowledge builder ................................................................................................. 43Tabla 11 Conceptualización del proceso CRISP-DM ....................................................................... 46Tabla 12 Glosario de negocio ................................................................................................................... 50Tabla 13 Archivos de fuentes RIPs ......................................................................................................... 53Tabla 14 Archivos de soporte para construcción del modelo ..................................................... 54Tabla 15 Campos hospitalización RIPs ................................................................................................. 54Tabla 16 Campos procedimientos RIPs ............................................................................................... 54Tabla 17 Campos medicamentos RIPs .................................................................................................. 55Tabla 18 Campos archivo tabla_mapeo_cie_comorbilidad.xls ..................................................... 55Tabla 19 Campos archivo mapeo_generico_funcion.xls ................................................................. 55Tabla 20 Reporte calidad de datos base datos consolidada RIPs .............................................. 56Tabla 21 Número de registros RIPs ....................................................................................................... 57Tabla 22 Registros reportados fuentes seleccionadas ................................................................... 57Tabla 23 Muestra número de ocurrencias por medicamento ..................................................... 58Tabla 24 Ejemplos de limpieza de registros ....................................................................................... 62Tabla 25 Ejemplos mapeo diagnóstico - sistema comprometido .............................................. 64Tabla 26 Ejemplos mapeo medicamento - función medicamento ............................................. 64Tabla 27 Rango de edades ......................................................................................................................... 65Tabla 28 Descripción de campos hospitalización derivada ......................................................... 65Tabla 29 Ejemplo registro consolidado ............................................................................................... 66Tabla 30 Algoritmos de clustering utilizados .................................................................................... 67Tabla 31 Variación de parámetros ......................................................................................................... 67Tabla 32 Detalle segmentación KM: S=5, N=3 ................................................................................... 68Tabla 33 Detalle segmentación FF: S=5, N=3 ..................................................................................... 69Tabla 34 Segmentación KM: S=10, N=2 ............................................................................................... 70Tabla 35 Segmentación KM: S=10, N=3 ............................................................................................... 70Tabla 36 Segmentación FF: S=10, N=3 ................................................................................................. 71Tabla 37 Segmentación FF: S=10, N=4 ................................................................................................. 71Tabla 38 Identificación de pasos clave ................................................................................................. 76Tabla 39 Glosario .......................................................................................................................................... 84Tabla 40 Exploración de datos tabla procedimiento - BD consolidada RIPs ......................... 91Tabla 41 Exploración de datos tabla hospitalización - BD consolidada RIPs ........................ 91

[6]

I. INTRODUCCIÓN

En un mundo cada vez más globalizado, las organizaciones virtuales (VO) nacen de la necesidad que tienen entidades autónomas de compartir recursos, siendo la información el más preciado. Caracterizadas por ser sistemas altamente distribuidos, heterogéneos y encargados de manejar grandes volúmenes de información, las VO requieren de mecanismos para coordinar eficientemente la búsqueda de información que provenga de uno o más de sus miembros (fuentes).

ARIBEC es un sistema que busca resolver dicha problemática involucrando no solo información que describa la estructura de las fuentes (metadata intencional) sino además, haciendo uso de la semántica de la información contenida en éstas (metadata extensional). Mientras que para la extracción de la metadata intencional se han considerado técnicas de mapeo e ingeniería reversa, la extracción de metadata extensional es un problema abierto en el que quedan preguntas por responder e incluso por formular.

Este proyecto constituye una primera aproximación a la conceptualización del problema y a la solución del mismo. En una propuesta donde converge la utilización de técnicas de minería de datos y el poder de expresividad de las ontologías, se propone una arquitectura que reúne los aportes e investigaciones que múltiples autores han adelantado al respecto.

Se optó por el uso de minería de datos dado que esta área se ha destacado por marcar la diferencia entre tener grandes cantidades de datos y gran cantidad de información. Para caracterizar una fuente no basta con tener datos triviales o identificables a simple vista, resulta indispensable encontrar patrones ocultos que permitan determinar con mayor confianza cuándo una fuente contiene o no información relevante para responder a una consulta dada.

No obstante, múltiples complicaciones surgen de este acercamiento. La aplicación de técnicas de minerías de datos ha estado tradicionalmente caracterizada por seguir procesos manuales que requieren la intervención exhaustiva de expertos. Por su naturaleza dichos procesos no pueden ser reproducidos a gran escala, luego se hace necesario encontrar una alternativa que permita reducir al máximo la cantidad de tiempo y recursos invertidos en éstos. En este escenario aparecen las ontologías.

La solución propuesta busca capturar la información técnica y del dominio que, en otras circunstancias proveerían los expertos, en un modelo estructurado (ontologías) a fin de semi-automatizar el proceso de extracción de metadata. En otras palabras, explotando el potencial de las ontologías para expresar conocimiento se pretende viabilizar el proceso a gran escala.

A continuación se presenta la estructura del documento.

[7]

II. CONTENIDO INFORME

Grosso modo el informe está conformado por las cuatro partes mostradas en la Figura 1.

Comienza por un marco teórico que permite situarse en el contexto del tema a tratar. Se incluyen conceptos básicos de Ontologías, Knowledge Discovery, Data Mining y una visión amplia del proyecto ARIBEC. El entendimiento de lo que es ARIBEC a la fecha de elaboración de este documento y lo que se propone sea en un futuro son fundamentales puesto que constituyen el punto de partida del trabajo realizado.

Expuesto el marco teórico se presenta la caracterización del problema que se desea investigar y se plantea la propuesta de solución a desarrollar a lo largo del documento; dicha solución ha sido llamada OBME (Ontology Based Metadata Extractor). Arquitectura, descripción de componentes y aproximación al proceso de construcción son los temas abordados.

Posteriormente, trazado el proceso de construcción, se continúa con los tres primeros pasos de dicho proceso con el propósito de iniciar la elaboración del módulo, materializar las ideas planteadas y evaluar la viabilidad de la solución propuesta. Como parte de la ejecución de tales pasos, se expone primero el caso de estudio realizado utilizando la metodología CRISP-DM en el contexto del sector salud.

En seguida se procede a la conceptualización del caso para luego describir el diseño de un prototipo que captura dicha conceptualización. Detalles de implementación del prototipo, restricciones del mismo y resultados obtenidos son presentados. Finalmente el documento se cierra con las conclusiones deducidas durante todo el proceso, recomendaciones sugeridas e ideas de lo que debería ser el trabajo futuro.

FIGURA 1 ESTRUCTURA DEL DOCUMENTO

Marco Teórico•Conceptos Básicos•ARIBEC

Problemática•Caracterización•Propuesta de

Solución•Proceso de

construcción de Solución

Aplicación Proceso Construcción•Caso de Estudio•Conceptualización

Caso•Implementación

de Protitpo

Cierre•Conclusiones•Recomendaciones•Trabajo Futuro

[8]

III. OBJETIVOS DEL PROYECTO

OBJETIVO GENERAL

Investigar la utilización de técnicas de minería de datos para la extracción de metadata extensional que apoye el proceso de selección de fuentes en el contexto de las organizaciones virtuales.

OBJETIVOS ESPECÍFICOS

• Conceptualizar la problemática del proceso de extracción de metadata extensional con el propósito de filtrar fuentes.

• Elaborar un estado del arte concerniente a la utilización de ontologías para guiar procesos de minería de datos y el uso de minería de datos para construir o poblar ontologías.

• Proponer una arquitectura para la extracción de metadata extensional en el marco del proyecto ARIBEC.

• Plantear el proceso a seguir para la construcción de dicha arquitectura.

• Definir un modelo de metadata extensional para una entidad del sector salud.

• Realizar una aproximación práctica, mediante un prototipo, al uso de técnicas de minerías de datos para extraer conocimiento a partir de fuentes en un dominio real.

[9]

IV. MARCO TEÓRICO

A continuación se realiza una introducción básica a los principales conceptos y áreas de estudio abordadas a lo largo del presente documento. El lector que disponga de nociones básicas en ontologías y minería de datos puede prescindir de la descripción realizada y pasar a la contextualización del proyecto ARIBEC, proyecto que da marco a la totalidad de este documento.

ONTOLOGÍAS

Una ontología es definida en la literatura como una especificación formal y explícita de un conocimiento compartido en un dominio de interés (Calvanese, Giacomo, Lembo, Lenzerini, & Rosati, 2005). A diferencia de un modelo de datos ordinario, en el que las relaciones entre entidades se limitan a definir reglas para mantener la integridad de las mismas, una ontología captura información semántica del dominio de modo tal que logra pasar de la representación de datos a la representación de conocimiento. Al ser semántica la metadata consignada en una ontología, habla del contenido de los documentos, trascendiendo aspectos como el formato de los mismos (Davies, Rudi, & Warren, 2006). Las ontologías son utilizadas en múltiples dominios para la organización de conocimiento de una manera estructurada. Están compuestas por un conjunto de conceptos, un conjunto de relaciones que vinculan dichos conceptos y un conjunto de instancias que los particularizan. Más allá de la definición formal de ontología, que se puede encontrar en (Ehrig, Haas, Hefke, & Stojanovic, 2005), lo que es importante resaltar de éstas es que estructuran el conocimiento de forma que un computador puede razonar y sacar conclusiones, logros que no son directamente posibles bajo otros esquemas de organización de la información.

-

ILUSTRACIÓN 1 LENGUAJE Y ONTOLOGÍA 1

1 Ilustración tomada de http://www.gettyimages.com/

[10]

Sobre la construcción de ontologías, lo que cabe mencionar es que aunque a lo largo de los años se han propuesto diferentes representaciones para su construcción, el trabajo ha convergido al lenguaje OWL para la creación de los componentes de las ontologías que se basa en el lenguaje de modelamiento de datos RDF. Es de notar que estas dos tecnologías son usadas por ARIBEC. La Figura 2 muestra la esquematización realizada en este aspecto por (Grimm, Hitzler, & Abecke, 2007). Una comparación entre lenguajes ontológicos se encuentra en (Corcho, 2003).

FIGURA 2 ESQUEMATIZACIÓN GENERAL DE LENGUAJES DE WEB SEMÁNTICA

KNOWLEDGE DISCOVERY

Knowledge Discovery (KD) es un proceso que tiene como objetivo la extracción de información interesante (no trivial, implícita, previamente desconocida y potencialmente útil) a partir de grandes volúmenes de datos (Grobelnik & Mladenic, 2006). Tradicionalmente el proceso comienza con la integración de los datos de entrada en caso de que se encuentren dispersos; a continuación se realiza el pre-procesamiento que dispone los datos para la ejecución de la minería que se realiza en seguida. Finalmente se realiza una etapa de pos-procesamiento en la cual se consigna el conocimiento resultante. Se debe resaltar el carácter cíclico o iterativo del proceso, que permite refinar los conocimientos adquiridos a medida que se avanza.

[11]

FIGURA 3 PROCESO DE DESCUBRIMIENTO DE CONOCIMIENTOS

Que dichos conocimientos sean comprensibles para el usuario es una propiedad indispensable si se desea utilizarlos para apoyar la toma de decisiones ligadas al negocio; si el usuario se encuentra frente a una “caja negra” que no explica sus predicciones, éste podría no confiar en ellas. Una de las maneras más habituales para satisfacer esta propiedad es utilizar representaciones de alto nivel que sean fácilmente legibles para un ser humano, por ejemplo un esquema IF-THEN (Freitas, 2003):

IF <la condición se satisface> THEN <predicción de algún valor para un atributo> Entre las aplicaciones de KD, la que resulta relevante para el presente estudio es la construcción semi-automática de ontologías. Ésta se puede apoyar en la aplicación de diversas metodologías, en particular (Grimm, Hitzler, & Abecke, 2007) propone una metodología de construcción de ontologías análoga a la metodología CRISP-DM (la cual se discutirá más adelante), que consta de los siguientes pasos:

1. Entendimiento del dominio. 2. Entendimiento de los datos. 3. Definición de tareas. 4. Poblamiento de ontología. 5. Evaluación de ontología. 6. Refinamiento con intervención humana.

DATA MINING

Data Mining (DM) es una técnica para extraer conocimiento a partir de grandes volúmenes de datos. Con la ayuda de herramientas de presentación y análisis, la información obtenida puede ser usada por expertos del negocio para predecir situaciones y/o comportamientos, segmentar clientes, determinar patrones y, en general, servir como apoyo a la toma de decisiones. Específicamente, entre los dominios de aplicación se encuentran (Data Mining Applications, 2004): sector bancario, bio-informática, mercadeo, detección de fraude, comercio electrónico, seguros, inversión,

[12]

manufactura, seguridad, telecomunicaciones, viajes, entre otras. Cada dominio puede ser dividido en múltiples subdominios que a su vez incluyen múltiples tareas. La gran mayoría de tareas corresponde a alguno de los siguientes tipos (Berry & Linoff, 2004):

• Clasificación: consiste en la evaluación de características de un nuevo objeto para ser asignado a un conjunto predefinido de clases.

• Estimación: busca estimar un valor desconocido a partir de un conjunto de variables conocidas.

• Predicción: intenta clasificar los datos de acuerdo a un comportamiento futuro estimado.

• Afinidad a grupo: consiste en determinar qué cosas van juntas. • Segmentación (CLUSTERING): se trata de dividir una población heterogénea en un

conjunto de grupos o cúmulos homogéneos.

Para realizar cada tarea se dispone de diversas técnicas, las más destacadas son mencionadas a continuación.

TÉCNICAS

Las técnicas utilizadas en minería datan de tiempo atrás, siendo frecuentemente algoritmos y técnicas estudiadas por más de 30 años cuyo origen es el campo denominado Machine Learning. Entre las más populares se encuentran los árboles de decisión, las redes neuronales, las reglas de asociación y los algoritmos genéticos (Sumathi & Sivanandam, 2006); una breve descripción de cada uno se muestra en la Tabla 1.

TABLA 1 TIPOS DE ALGORITMOS USADOS EN MINERÍA

Algoritmo Descripción Redes neuronales artificiales Son modelos de predicción no lineales que

aprenden a través de entrenamiento Árboles de decisión Son estructuras en formal de árbol que

generan reglas para clasificar conjuntos de datos

Reglas de asociación Se trata de la extracción de reglas de la forma if-then con base en significancia estadística

Algoritmos genéticos Consisten en técnicas de optimización basadas en conceptos genéticos

Además de las familias de algoritmos mencionadas, otra importante es la conformada por los algoritmos de segmentación o CLUSTERING, la cual será utilizada en el presente estudio, por lo que las nociones básicas de la misma serán descritas más ampliamente que las ya referenciadas.

[13]

CLUSTERING

El objetivo de un proceso de CLUSTERING es encontrar patrones existentes en los datos sin tener en cuenta alguna variable objetivo. Todas las variables tienen inicialmente el mismo grado de importancia a menos que se especifique lo contrario mediante la asignación de pesos particulares. Igualmente, no existe distinción entre variables dependientes e independientes. Al final del algoritmo cada cluster va a agrupar registros similares y va a intentar distanciarse de otros clusters con registros diferentes.

De acuerdo a (Jain & Dubes, 1988) una tarea de CLUSTERING está compuesta por los siguientes pasos:

1. Representación de patrones: extracción y selección de características. 2. Definición de una medida de similitud. 3. Agrupamiento o segmentación. 4. Abstracción de datos (si se requiere). 5. Evaluación de resultados (si se requiere).

Durante la etapa de extracción y selección de características es necesario tener en cuenta los tipos de datos involucrados: cuantitativos o cualitativos. Mientras que los datos cuantitativos pueden ser valores continuos, valores discretos y valores restringidos a intervalos, los datos cualitativos pueden ser nominales u ordinales. Puesto que no todos los tipos de variables son óptimos para la realización de clusters, las variables categóricas y los rangos deben ser transformados con el fin de poder ser utilizados (e.g. expresándolos como intervalos).

Por otra parte, cuando entran en juego diferentes unidades de medida, las variables no sólo deben ser transformadas sino también escaladas. La solución usual es realizar un mapeo de todas las variables implicadas a un rango común que permita su comparación directa (e.g. 0 -10, 0-1).

En el segundo paso, a la hora de definir la medida de similitud, algunas variables pueden ser más importantes que otras y por ende deben tener más peso en el algoritmo. La noción de importancia depende del contexto y habitualmente se requiere de un experto en el dominio para determinar los pesos a fijar2

El agrupamiento se puede realizar utilizando diversos algoritmos cuyas generalidades se describirán posteriormente en esta sección. La descripción de los algoritmos que serán presentados fue tomada de (Berry & Linoff, 2004).

.

Para abstraer los datos, una alternativa es identificar los atributos más disímiles del cluster con respecto a los otros clusters, es decir aquellos que lo caracterizan; se puede por ejemplo calcular la media o la moda interna al cluster y compararla con la media o moda total. Otras alternativas, expuestas en (Jain, Murty, & P.J., Data Clustering: A Review, 2000), son: selección del centroide, identificación de puntos de frontera, 2 Se profundizará en el tema de medidas de similitud en la sección Medidas de similitud.

[14]

conjunción de predicados y construcción de un árbol de decisión. Finalmente, para evaluar los resultados es posible comparar la distancia entre registros de un cluster con la distancia entre clusters (IBM, 2006).

K-MEANS CLUSTERING

Este algoritmo y sus variantes es uno de los más populares y más ampliamente implementados en las aplicaciones de DM. Para iniciar el proceso de CLUSTERING se seleccionan K registros que serán llamados “semillas” porque a partir de éstos se construirán los K clusters resultantes. Cada registro se asignará a la semilla más cercana, i.e. la más similar. Cuando se tienen los K clusters, se caracteriza cada cluster utilizando su centroide para luego iniciar de nuevo el algoritmo. De esta manera, en cada iteración se recalculan los centroides y se afinan los clusters hasta el punto en que los límites de cada cluster se estabilicen.

AGGLOMERATIVE CLUSTERING

Contrariamente a K-Means, este algoritmo no inicia con un número K fijo de clusters. Su objetivo es permitir que el usuario seleccione el nivel de granularidad deseado según el caso, por lo cual inicia realizando tantos clusters como registros existan y luego permite fusionarlos abstrayendo así las características representativas de cada cluster hasta llegar al número de clusters más indicado. Este algoritmo trabaja de manera inversa a los árboles de decisión, i.e. va subiendo de las hojas a la raíz.

DIVISIVE CLUSTERING

Consiste en usar un árbol de decisión para realizar el CLUSTERING, se trata de comenzar con el conjunto completo de registros y dividirlos en particiones que son más puras de acuerdo a una función predefinida de pureza. Una vez formados los clusters, se aplica la función de pureza una vez más a cada uno de éstos con el fin de formar paulatinamente una estructura jerárquica similar a la construida con el algoritmo AGGLOMERATIVE

CLUSTERING.

[15]

V. ARIBEC 3

ARIBEC es un sistema de mediación orientado por servicios diseñado para contextos distribuidos a gran escala que caracterizan a las organizaciones virtuales. Su objetivo es simplificar la integración de datos en ambientes con fuentes de datos heterogéneas y distribuidas a partir de la abstracción del mundo en un conjunto de objetos de negocio. Un objeto de negocio representa la unidad de integración del sistema. Corresponde al conjunto de conceptos relacionados que tienen significado para una comunidad y cuyos valores pueden provenir de una o varias fuentes de datos.

ARIBEC provee un conjunto de servicios que permiten crear las instancias de los objetos de negocio bajo demanda, respetando las políticas de confidencialidad y seguridad de las fuentes originales. A continuación se presentará de manera general la arquitectura de ARIBEC que se fundamenta en una arquitectura orientada por servicios. La Figura 4 ilustra la arquitectura que implementa la mediación de recursos de datos, a través de un conjunto de servicios propios e inter-operando con los servicios provistos por una infraestructura de mallas de datos, que soporta el funcionamiento del sistema.

FIGURA 4 ARQUITECTURA ARIBEC

3 Está sección ha sido tomada totalmente de (Pomares, 2007) y complementada con la información disponible en (Badillo, 2008).

[16]

Como se puede observar en la Figura 4, los servicios prestados por el sistema ARIBEC se pueden clasificar de acuerdo a la arquitectura de referencia de los sistemas de mediación [ (Garcia-Molina, Papakonstantinou, Quass, & Rajaraman, 1997), (Kossmann, 2000) ] en los siguientes grupos:

• Servicios de Nivel de Adaptación: Responsables de garantizar el acceso transparente y siguiendo las propiedades de privacidad y confidencialidad de las fuentes de datos que se encuentran en el nivel de fuentes de datos.

• Servicios de Nivel Mediación: Responsables de la planeación y ejecución de consultas que dan lugar a la creación de las instancias de las entidades requeridas bajo demanda.

• Servicios de la Aplicación: Son los servicios responsables de la creación y lanzamiento de consultas y de procesos de configuración del sistema.

Adicionalmente, para garantizar la seguridad y confidencialidad de todo el proceso de integración, ARIBEC incluye un conjunto de servicios de Autenticación y Autorización.

Los servicios de cada uno de estos niveles manejan un nivel de abstracción de datos diferente. La Figura 5 ilustra los niveles de abstracción: local, disponible para los servicios del nivel de adaptación; conceptual, disponible para los servicios del nivel de mediación y, externo, creado para los servicios del nivel de aplicación.

FIGURA 5 NIVELES DE ABSTRACCIÓN ARIBEC

El Nivel Local es el conjunto de fuentes de datos registradas para compartir sus datos. Adicionalmente, el sistema maneja en este nivel metadata acerca del rol que cada fuente tienen dentro del sistema de mediación. Se identificaron tres roles de fuentes:

[17]

Proveedora de Datos, Fuente Referencial y Proveedora Referencial. Una fuente que comparte sus propios datos es considerada Proveedora de Datos mientras que las Fuentes Referenciales son aquellas que integran información de otras fuentes. Adicionalmente, ofrecen cierta trazabilidad sobre el origen de los datos, que puede ser explícita o inferida. Una fuente de datos referencial es por ejemplo una bodega de datos o un almacén de datos operativos resultado de esfuerzos de consolidación. El tercer rol Proveedora Referencial, combina características de los dos tipos de fuentes anteriores.

El Nivel Externo representa la visión que los usuarios tienen del mundo. Está conformada por un conjunto de esquemas que definen los objetos de negocio. Cada usuario puede tener una visión del mundo diferente, lo que genera múltiples esquemas externos, cada uno con el conjunto de objetos de negocio de interés para el grupo de usuarios.

El Nivel Conceptual se encuentra entre los niveles local y externo. Representa el mundo a través de una definición semántica y general de los datos usando una ontología de referencia. No considera ni necesidades específicas para un grupo de usuarios no restricciones de los modelos locales.

Las consultas de usuario son formuladas en el nivel externo y son evaluadas en las fuentes de datos a nivel local. La relación entre los niveles se realiza utilizando la ontología en el nivel conceptual que facilita el soporte a cualquier tipo de fuente de datos. La clave es elegir una ontología de referencia flexible que permita mapear fuentes de datos heterogéneas. ARIBEC define las siguientes relaciones entre los tres niveles de datos.

• Niveles Local - Conceptual: Los modelos usados por las fuentes local son mapeados a conceptos de la ontología en el nivel conceptual. Esto favorece la extensibilidad del sistema porque, adicionar una nueva fuente únicamente requiere crear un nuevo mapping sin hacer cambios a nivel conceptual.

• Niveles Conceptual - Externo: Los esquemas en este nivel son definidos como vistas sobre la ontología de referencia. Si es necesario crear o modificar un nuevo objeto de negocio para un grupo de usuarios, sólo se requiere definir una nueva vista sobre la ontología de referencia y dejarla disponible como un nuevo objeto.

Ejecutar una consulta en ARIBEC puede ser resumido de la siguiente manera: un usuario, miembro de la organización virtual se autentica ante el sistema a través del Servicio de Autenticación; una vez autenticado pueden expresar sus peticiones a través del Servicio de Consulta, que recibe una petición en un lenguaje de alto nivel sobre uno o más objetos de negocio. El Servicio de Consulta analiza la petición e invoca y coordina los servicios necesarios para ejecutarla:

Servicio de Autorización: responsable de validar si el usuario que lanzó la consulta está autorizado para ver ese objeto de negocio.

[18]

Servicio de Caché: verifica si, como resultado de consultas anteriores, las instancias integradas solicitadas ya se encuentran materializadas.

Servicio de Adaptación: recibe la solicitud de consulta sobre la fuente referencial que representa y ejecuta la consulta directamente sobre ella.

Servicio de Materialización: consulta cada fuente de datos estipulada en la cartografía a través del Servicio de Adaptación y obtiene los conceptos que cada una de ellas está en capacidad de entregar. Con esta información y valiéndose de la ontología de referencia, con la que inicialmente se definió la consulta, conforma cada una de las instancias. Adicionalmente, las ubica en caché según las propiedades de latencia de los conceptos del objeto de negocio y entrega al servicio de consulta el conjunto de instancias resultantes. La latencia en este caso indica qué tan rápido se vuelve obsoleto un concepto de un objeto de negocio a partir de la obtención de su valor desde su fuente.

Servicio de Adaptación: Recibe las solicitudes de consulta de las fuentes que hacen parte de la cartografía y se encarga de ejecutar directamente sobre cada fuente la consulta requerida.

Teniendo en cuenta que la infraestructura que da soporte al funcionamiento de ARIBEC son las mallas de cómputo, los servicios de ARIBEC interactúan con los siguientes grupos de servicios:

• OGSA-DAI: Es un middleware que permite el acceso uniforme a recursos de datos en una arquitectura orientada a servicios. Los servicios de OGSA-DAI son usados para resolver el problema de heterogeneidad sintáctica de los datos.

• Globus ToolKit: Es una herramienta que provee los servicios y herramientas necesarias para compartir poder de procesamiento, fuentes de datos y otras herramientas de forma segura a través de límites corporativos, institucionales, y geográficos sin sacrificar la autonomía local (The Globus Alliance. Globus toolkit 4, 2007).

Actualmente, ARIBEC es una extensión de SISPRO (Camargo & Arteta, 2006), que utiliza la bodega de datos de dicho sistema como base de datos referencial para guiar el proceso de selección de fuentes aprovechando que ésta mantiene un resumen de todos los servicios de salud a nivel nacional (Pomares, Roncacio, & Abásolo, Virtual Objects in Large Scale Health Information Systems, 2008). No obstante, con el fin de remover la dependencia de ARIBEC a SISPRO, se trabaja en la construcción y utilización de un repositorio de conocimiento (basado en ontologías) que apoye el proceso de filtraje o selección de nodos.

Lo que se pretende es extraer y almacenar metadata de cada fuente (nodo) durante su incorporación y plantear mecanismos que permitan utilizar la información extraída para seleccionar aquellas fuentes relevantes a la hora de resolver una consulta. La metadata propuesta ha sido clasificada en dos tipos: la metadata intencional que representa información sobre la estructura de los datos de la fuente, y la metadata extensional que

[19]

corresponde a información no explícita, no trivial y relacionada a nivel semántico con el dominio donde la fuente opera.

Mientras que para la extracción de la metadata intencional se han considerado técnicas de mapeo e ingeniería reversa, para la extracción de la metadata extensional se ha considerado el uso de técnicas de minerías de datos. La justificación para optar por la aplicación de dichas técnicas está dada por los siguientes factores:

• Permiten hallar patrones en los datos que no sean fácilmente identificables mediante técnicas básicas de estadística.

• Abarcan un amplio conjunto de herramientas configurables según las necesidades y objetivos del caso.

• Pueden haber detalles desconocidos de las fuentes para los encargados de las mismas.

• Existe información que puede ser pasada por alto en una entrevista o cuestionario.

La extracción de este último tipo de metadata es el tema que se aborda en el presente documento. A continuación se expone la problemática asociada.

[20]

VI. CARACTERIZACIÓN DEL PROBLEMA

Como fue recién esbozado, este proyecto aborda la problemática de extracción de metadata extensional mediante técnicas de minería de datos. A grandes rasgos, dicha extracción consiste en la captura de los datos, el análisis de los mismos (extracción de conocimiento) y la consolidación del conocimiento extraído (conceptualización en una ontología). Para realizar dicho proceso es indispensable conocer la estructura de la fuente (metadata intencional) ya que la gran mayoría de técnicas de análisis de datos así lo requieren.

FIGURA 6 EXTRACCIÓN DE METADATA EXTENSIONAL

Aunque en ARIBEC se habla de miles de fuentes, para entender la problemática resulta útil primero restringirla a la extracción de metadata extensional para una única fuente. En este contexto, lo más simple sería aplicar un proceso de extracción de conocimiento tradicional donde un experto del dominio y un experto en técnicas de minería de datos suministraran la información necesaria para analizar la fuente y consolidar la información extraída en la base de conocimiento de ARIBEC.

En este proceso, el experto del dominio aporta información acerca de qué tipos de datos pueden ser extraídos, dice como éstos deben ser procesados y valida los modelos obtenidos. El experto en minería indica las técnicas aplicables a los datos, realiza la obtención de modelos y colabora en el ajuste de sus respectivos parámetros. Posteriormente, un experto en ontologías debe plasmar en la base de conocimiento de ARIBEC el resultado de la minería. En el proceso, específico a la fuente, confluyen la minería de datos y la construcción de ontologías.

Sin embargo, a la hora de extrapolar dicho proceso a decenas de miles de fuentes es evidente que es imposible aplicarlo de forma individual e independiente; para cada fuente sería necesario pasar por el entendimiento de su estructura, el acompañamiento de expertos y posiblemente la transformación de sus datos a estructuras idóneas para la

[21]

obtención de la metadata. Por otra parte, asumir que todas las fuentes son iguales tampoco es una suposición realista puesto que como es bien sabido, en la realidad las fuentes son heterogéneas.

FIGURA 7 EXTRACCIÓN DE METADATA EXTENSIONAL A GRAN ESCALA

Además de las dificultades propias de un contexto heterogéneo de gran escala, surge también la necesidad de confrontar los problemas inherentes a la creación y poblamiento de una ontología que logre contener todo el conocimiento encontrado:

Por un lado, actualmente las ontologías son creadas principalmente mediante una integración de lexicones, taxonomías y otras ontologías en el procesamiento de lenguaje natural y áreas de lingüística computacional (Gottgroy, Kasabov, & MacDonell, An Ontology driven approach knowledge discovery in Biomedicine , 2004). Siendo mucho menos usual la integración de ontologías con el área de las bases de datos, específicamente la utilización de esquemas y datos existentes en sistemas relacionales para su creación y poblamiento.

Por otro lado, la forma de integrar la minería de datos, las bases de datos y las ontologías es reconocida por múltiples autores como un campo poco explorado donde todavía existen preguntas sin responder e incluso por formular. No solo porque la creación de ontologías, parcialmente automatizada, continúa requiriendo amplia intervención humana y una metodología para dicha intervención, sino porque aún no es claro el rol de la minería y las bases de datos en esta disciplina.

Alta Heterogeneidad

Fuente

Extensivo acompañamiento

expertos

Transformación de datos

Tareas de minería específica a la

fuente

Conocimiento estructura cada

fuente

[22]

Aunque se han planteado frameworks de integración KD – Ontologías (Figura 8) como los propuestos en (Gottgroy, Kasabov, & MacDonell, Building Evolving Ontology Maps for Data Mining and Knowledge Discovery in Biomedical Informatics, 2003) y en (Phillips & Buchanan) donde se sugieren alternativas para que las ontologías guíen el descubrimiento de conocimiento y para que el uso de técnicas de minería apoye la construcción de ontologías, el proceso es fundamentalmente manual por lo que no resulta viable su aplicación a gran escala.

FIGURA 8 KNOWLEDGE DISCOVERY GUIADO POR ONTOLOGÍAS

Teniendo en cuenta las dificultades recién expuestas (proceso de minería a gran escala y creación y poblamiento de ontologías) y los requerimientos de ARIBEC se entiende que es necesario un mecanismo de extracción de metadata que cumpla con las siguientes características:

• Escalabilidad: el mecanismo debe ser escalable con el número de fuentes y el tamaño de sus respectivos conjuntos de datos.

• Semiautomático: la intervención humana debe reducirse para limitar los costos derivados de ésta.

• Usabilidad: cuando se requiera la intervención humana se debe proveer un entorno amigable y fácil de usar que permita al usuario ajustar los resultados obtenidos.

• Flexibilidad: debe garantizarse la posibilidad de evolución del mecanismo. • Integrable: el mecanismo debe posibilitar la integración con la infraestructura

actual del proyecto ARIBEC.

Ahora bien, la metadata a ser extraída solo tiene como propósito la selección de fuentes durante el proceso de resolución de una consulta, luego las siguientes suposiciones y simplificaciones se consideran válidas:

• La metadata no tiene que identificar de forma precisa la fuente, una aproximación razonable es suficiente.

• El objetivo de extracción de la metadata es el perfilamiento de fuentes (se descartan tareas de minería como predicción y clasificación).

Preparación de Ontología

Poblamiento de Ontología

Selección de Instancias

Minería de Ontología

Poblamiento de Ontología

[23]

VII. PROPUESTA DE SOLUCIÓN: OBME

FIGURA 9 ARQUITECTURA OBME

Para dar respuesta a la problemática planteada se propone el sistema cuya arquitectura se muestra en la Figura 9. La solución ha sido denominada OBME por sus siglas en inglés: Ontology Based Metadata Extraction.

De acuerdo a la descripción de la problemática, se identificaron dos tipos de usuarios: el experto del dominio que conoce la fuente y el experto en minería responsable de extraer la metadata de la misma. El sistema está ideado de modo tal que la intervención de ambos actores se vea significativamente reducida frente a la alternativa de ejecutar un proceso típico de extracción de conocimiento. Es de aclarar que si bien gráficamente solo se muestra interacción directa con el usuario en dos módulos, cada uno de los módulos debe permitir la interacción con los usuarios para garantizar la transparencia y entendimiento del proceso. Esto es fundamental puesto que OBME no deja de ser parte de un proceso de descubrimiento de conocimiento donde las cajas negras deben en lo posible ser evitadas.

El funcionamiento de OBME se describe a continuación:

Cuando una fuente va a ser analizada el seleccionador de tareas (TASK CHOOSER)

determina, de acuerdo a las características de la fuente, los algoritmos que deben ser

[24]

ejecutados; en este punto, el experto en minería puede modificar la decisión tomada de acuerdo a sus criterios. Teniendo en cuenta los requerimientos del algoritmo seleccionado se extraen los datos necesarios. Una vez se ha realizado la extracción de los datos (DATA EXTRACTOR), la calidad de los mismos es verificada (DATA CLEANER) desarrollando de ser necesario tareas de transformación (DATA TRANSFORMER). Verificada la calidad de los datos, los algoritmos de minería son ejecutados (DATA MINING

PROCESSOR) y presentados (PRESENTATION) al experto de la fuente quien tiene la potestad de descartar resultados, editar las reglas y de ser preciso, ejecutar una vez más los algoritmos. Finalmente, cuando los resultados han sido validados por el usuario son transformados a una representación adecuada (KNOWLEDGE BUILDER) para su incorporación al repositorio de metadatos de ARIBEC.

El conocimiento necesario para ejecutar las tareas específicas que deben realizarse según la fuente que será analizada ha sido capturado en un conjunto de ontologías. Éstas, además de contener la metadata intencional que previamente debió ser obtenida, reúnen parte del conocimiento de los expertos de forma que la necesidad de recurrir a ellos se vea disminuida. El uso de ontologías que capturen el conocimiento técnico y del dominio busca además abordar al menos 3 de los 4 factores claves identificados por (Graco, Semenova, & Dubossarsky, 2007) para lograr un proceso de minería de datos guiado por conocimiento: construir algoritmos hábiles, hacer uso de datos hábiles y combinar el conocimiento técnico y del negocio para obtener resultados óptimos en la minería.

En lo que sigue del documento se describirá en mayor detalle cada uno de los módulos que componen la solución junto con la problemática específica que apuntan a resolver.

ONTOLOGÍAS

Las ontologías constituyen el núcleo del sistema y de una u otra forma son prerrequisitos de los demás módulos. El sistema está constituido por tres tipos distintos de ontologías:

[25]

La primera ontología, la ontología local, corresponde a la metadata intencional de la fuente. En la jerarquía de (Pollock, 2004) corresponde a las capas 2 y 3 puesto que se trata de metadata sintáctica y estructural que sirve para saber qué tipo de información almacena la fuente.

La segunda ontología, la ontología global, es una ontología de referencia que es utilizada para procesar los datos y expresar los resultados en un lenguaje común a todas las fuentes. La información extraída utilizando la ontología local es convertida en términos de la ontología global para luego ser sujeta a la totalidad del proceso de análisis.

La tercera ontología es exclusiva de OBME en el sentido de que no ha sido pensada para ser explotada por otros componentes de ARIBEC. Se trata de una ontología de minería de datos que es usada por los distintos módulos del sistema para la toma de decisiones y que encapsula conocimiento tanto técnico como del dominio. Dicho conocimiento es aquél relacionado al problema de extracción de metadata extensional con fines de selección de fuentes (Figura 10), conocimiento que sería en otras circunstancias suministrado por expertos para el análisis de las mismas. En la jerarquía de metadata de (Pollock, 2004) la ontología se ubica en las capas 5 y 6 puesto que establece reglas que pueden ser usadas para concretar la semántica capturada.

FIGURA 10 CONOCIMIENTO INVOLUCRADO EN KD (KUO, LONIE, SONENBERG, & PAIZIS, 2003)

SOBRE LA CREACIÓN DE LAS ONTOLOGÍAS

Si bien la ontología de minería y de dominio puede llegar a ser creada manualmente, no ocurre lo mismo con la ontología local y su relación con la ontología global del sistema. El tamaño y complejidad de la estructura de cada fuente, al igual que el número potencial de nodos que pueden llegar a participar en el sistema, son factores que dificultan significativamente la tarea de su construcción.

[26]

La edificación de la ontología local y el mapeo a la ontología general equivale a la extracción de la metadata intencional. Su construcción puede comenzar con técnicas de ingeniería reversa y ser complementada con algoritmos de MACHINE LEARNING (ML) que propongan relaciones, mapeos y MATCHINGS. Actualmente esta problemática es un tema abierto de investigación, existiendo todavía visibles limitaciones; en la tabla presentada a continuación se realiza una comparación entre las características de las ontologías creadas manualmente y lo que se ha logrado a partir de ML (Omelayenko, 2001).

TABLA 2 COMPARACIÓN ENTRE TÉCNICAS DE CREACIÓN DE BASES DE CONOCIMIENTO

Bases de conocimiento a partir de Machine learning

Ontologías construidas manualmente

PRIMITIVAS DE MODELAMIENTO Simple y limitada. Por ejemplo, los algoritmos de árboles de decisión generan reglas en forma de conjunciones sobre valores de atributos

Amplio conjunto de primitivas de modelamiento (frames, relaciones de subclase, reglas con un gran conjunto de operaciones, funciones, etc.)

ESTRUCTURA DE LA BASE DE CONOCIMIENTO Plana y homogénea Jerárquica, consiste en varios componentes

como subclase-de, parte-de y otras relaciones

TAREAS Clasificación y segmentación que mapea los objetos descritos por las parejas atributo-valor a un conjunto limitado y no estructurado de clases o etiquetas de clusters

La tarea de clasificación requiere mapear los objetos a un árbol de clases estructuradas. Puede requerir la construcción de descripciones de clases

MÉTODOS PARA SOLUCIONAR PROBLEMAS Muy primitivos, basados en simples estrategias de búsqueda

Complicados, requieren la intervención sobre una base de conocimientos rica en estructura, generalmente específicos a cada dominio y a cada aplicación

ESPACIO DE SOLUCIONES Conjunto fijo de etiquetas de clases no extensible

Conjunto extensible de primitivas y soluciones compuestas

LEGIBILIDAD DE LA BASE DE CONOCIMIENTOS No requerida. Pueden ser usadas solamente automáticamente y en dominios específicos

Requerida. Pueden ser usadas por humanos (al menos potencialmente)

Además de la problemática de construcción de ontologías, la obtención de la metadata intencional también involucra el análisis de información no estructurada. Por ejemplo, la descripción de los síntomas de un paciente en una historia clínica típicamente se encuentra en forma libre.

[27]

DATA EXTRACTOR

A partir de la ontología local y del algoritmo de minería a ser ejecutado, este módulo extrae los datos necesarios para perfilar la fuente. El módulo se entiende como una fachada que se integra a los servicios de extracción de datos de ARIBEC.

Teniendo siempre en cuenta que una gran cantidad de datos no garantiza una gran cantidad de información se trata de extraer solo aquellos atributos relevantes para el proceso de minería y descartar aquellos que no agregan valor al proceso o incluso lo entorpecen.

Para cumplir la tarea es esencial disponer de la metadata intencional puesto que de otro modo no es posible precisar qué datos deben ser consultados.

RESUMEN

TABLA 3 RESUMEN DATA EXTRACTOR

Nombre Data Extractor Función Extracción de datos a partir de los cuales se obtiene la metadata extensional Entradas - Ontología que describe a nivel intencional la fuente

- Fuente a ser analizada - Ontología que describe qué datos deben ser extraídos de acuerdo al

algoritmo a ser ejecutado Salidas Datos necesario para ejecutar los algoritmos seleccionados Prerrequisitos de uso

Existencia de una ontología que describe de acuerdo a la fuente, la información que debe ser extraída. Existencia de la metadata intencional tanto a nivel de estructura como a nivel de instancia

Dependencias directas

Task Chooser Data Cleaner

[28]

DATA CLEANER

Una vez los datos han sido extraídos, este módulo procede a la limpieza de los mismos para afrontar los problemas típicos de integración de fuentes descritos en (Kedad & Métais, 2002) y ejemplificados en la Tabla 4. Se trata entonces de resolver los problemas relacionados con la calidad de los datos tanto a nivel intencional (correspondencia entre esquemas) como a nivel extensional (correspondencia entre instancias semánticamente equivalentes).

TABLA 4 EJEMPLOS DE PROBLEMAS DE INTEGRACIÓN DE FUENTES

Problema Ejemplo Diferencias en tipos Un valor representado por un número en una fuente

y por una cadena de caracteres en otra Diferencias en formato Un valor representado con diferente longitud según la

fuente Diferencias en escala El precio de un producto representado en euros en

una fuente y en pesos en otra Diferencias en codificación El atributo género representado como {F,M} en una

fuente y {0,1} en otra Diferencias en terminología La utilización de la palabra “antibiótico” en una

fuente y “penicilina” en otra para referirse al mismo medicamento

Diferencias en granularidad Consignación de datos de un inventario diariamente en una fuente y semanalmente en otra

Conflictos con identificadores Dos instancias no equivalentes con el mismo identificador o dos instancias equivalentes con identificadores diferentes

[29]

FIGURA 11 PROBLEMAS DE CALIDAD DE DATOS (RAHM & DO, 1999)

Los datos deben ser primero mapeados a la ontología local y luego ser llevados a la ontología general. En la transformación a la ontología local se pueden resolver los problemas a nivel intencional utilizando técnicas tradicionales como lógica difusa. Para la integración a la ontología global se puede usar como base una ontología que permita resolver conflictos entre valores provenientes de fuentes diferentes (Kedad & Métais, 2002).

En este punto, se hace necesario explicar por qué los mapeos se realizan en el momento y orden indicado (local - global) si el conocimiento obtenido estará a un nivel mucho mayor de agregación. En otras palabras, por qué incurrir en el procesamiento adicional que implica llevar los datos a la ontología local y luego a la global si la cantidad de datos que en últimas deben ser expresados en términos de la base de conocimiento común es mucho menor.

El argumento de la explicación se compone de tres partes. La primera consiste en notar que una vez los datos se traducen a la ontología global se simplifican las etapas posteriores del proceso, siendo de especial interés la reducción que se aprecia en el tamaño de la ontología de minería puesto que ya no es necesario especificar para cada fuente cómo los datos deben ser pre-procesados antes de ejecutar los algoritmos; en cambio basta con expresar cómo los datos deben ser pre-procesados en términos de la ontología global. La segunda parte yace en el hecho de que el mapeo a la ontología

Problemas Calidad de Datos

Una fuente

IntencionalFalta de reglas de

integridad, diseño de esquema pobre

Extensional

Errores tipográficos, redundancia o

duplicados, valores cotradictorios

Múltiples fuentes

IntencionalModelos de datos y

diseños de esquemas heterogéneos

Extensional Datos contradictorios e inconsistentes

[30]

general debe realizarse de forma muy eficiente puesto que es también necesario a la hora de resolver una consulta, los resultados entregados al usuario deben en últimas ser presentados en términos de la ontología global; si el mapeo se hace cuando el usuario está dispuesto a menores tiempos de espera, no hay razón para no hacerlo cuando se dispone de un tiempo mucho mayor como lo es en la etapa de incorporación de fuentes. Finalmente, la última parte del argumento se centra en que lo costoso del mapeo es construirlo mas no hacerlo, su ejecución es polinomial en el número de datos y puede ser paralelizada sin mayores dificultades.

Ahora bien, hacer dicha reparación de manera automática es imposible (Curé & Jeansoulin, 2007) y la intervención humana es indispensable, por esta razón el módulo debe solicitar asistencia al usuario cuando se detecte un número muy alto de errores o la incertidumbre en su corrección supere umbrales aceptables (el valor de estos parámetros debería ser ajustado por el usuario de acuerdo a la sensibilidad en los datos de la fuente).

Finalmente, es de notar que el componente interno de OBME realmente actuaría como un proxy frente a lo que debería ser el integrador de esquemas de ARIBEC. La problemática de integración de datos es transversal tanto al proceso de extracción de metadata extensional como al proceso de resolución de consultas.

RESUMEN

TABLA 5 RESUMEN DATA CLEANER

Nombre Data Cleaner Función Limpieza e integración semi-automática de datos Entradas - Ontología que describe a nivel intencional la fuente

- Fuente a ser analizada - Ontología que describe qué datos deben ser extraídos de acuerdo al

algoritmo a ser ejecutado - Mapeos a ontología local y ontología global

Salidas Datos expresados en términos de la ontología global Prerrequisitos de uso

Existencia de una ontología que describe de acuerdo a la fuente, la información que debe ser extraída Existencia de la metadata intencional tanto a nivel de estructura como a nivel de instancia Existencia de mapeos a la ontología local y a la ontología global


Task Chooser Data Extractor Data Transformer

[31]

TASK CHOOSER Y DATA MINING ONTOLOGY

Ningún algoritmo es universalmente superior (Wolpert, 1997), el desempeño de cada uno está sujeto al contexto donde se utilice y a las particularidades de cada conjunto de datos. Para un DATASET dado, habrá algoritmos que obtengan mejores resultados frente a otros menos adecuados y habrá algunos que ni siquiera sean aplicables. Por ejemplo, para un conjunto de datos mayoritariamente categóricos, la utilización de reglas asociación o árboles de decisión puede llegar a ser más apropiada que algoritmos de CLUSTERING debido a las dificultades de establecer una función de distancia.

Por esta razón, cada proceso de minería debe pasar por una fase de selección de algoritmos que resulta costosa ya que requiere la presencia de un experto en DM. Así, en ausencia de otros mecanismos de información, por cada fuente a partir de la cual se desee extraer metadata extensional se requiere de un experto que guie el proceso. Si el número de fuentes alcanza el orden de miles, el proceso de incorporación de fuentes resulta insostenible.

Dado este contexto, se propone la creación de un módulo responsable de seleccionar de forma asistida los algoritmos más apropiados para la ejecución del proceso de minería. El núcleo del módulo se concibe partiendo de las ideas propuestas en (Lin, Zhang, & Yu, 2006) donde se plantea una ontología de minería de datos para decidir qué algoritmo es mejor según el tipo de datos con los que se va a trabajar y según la pregunta que se desea responder. La ontología recopila el conocimiento del experto con el fin de integrarlo a una aplicación que pueda, sin la intervención del mismo, hacer minería automáticamente; la ontología entonces simula el conocimiento del experto lo que convierte a OBME en un sistema capaz de responder preguntas relativamente sofisticadas sobre minería. El esquema de la ontología propuesta por los autores mencionados se muestra en la Figura 12.

[32]

FIGURA 12 ONTOLOGÍA DE MINERÍA DE DATOS (LIN, ZHANG, & YU, 2006)

La ontología presentada consigna parcialmente el conocimiento necesario para seleccionar el algoritmo DM a utilizar; sin embargo esta ontología podría ser extendida de modo tal que incluya además información del contexto, también útil a la hora de determinar dicho algoritmo. En (Singh, Vajirkar, & Lee, 2003) se describen otros tipos de información contextual que podrían complementar la ontología: el dominio específico, el área de la cual tiene información la fuente, los conjuntos de datos semánticamente relacionados y los tipos de usuarios que podrían acceder a la información.

El módulo entonces, utilizaría la ontología de minería extendida con la información del contexto para determinar el o los algoritmos que pueden ser aplicados a la fuente. Una vez seleccionado el algoritmo, el módulo debe especificar la finalidad del mismo y los datos que requiere. Con dicha información, los módulos relacionados pueden continuar el proceso de análisis de la fuente.

RESUMEN

TABLA 6 RESUMEN TASK CHOOSER

Nombre Task Chooser Función Selección semiautomática del(os) algoritmos más apropiados para la

extracción de metadata extensional Entradas - Ontología que describe a nivel intencional la fuente

- Fuente a ser analizada - Ontología que describe bajo qué parámetros técnicos y de negocio el uso

de un algoritmo es factible y adecuado Salidas Algoritmo a ser utilizado Prerrequisitos de uso

Existencia de una ontología de minería de datos sobre la cual se ejecute el razonamiento Existencia de metadata intencional que describa la fuente a nivel de esquema


Data Transformer Data Cleaner

Proceso de Minería

•Tipo de datos guardados en el dataset(numérico, categórico)Tipo de datos

•Tarea de minería(clustering, regresión, reglas de asociación)Función

•Familias de algoritmos(redes neuronales, árboles de decisión)Método

•Implementación particular de un método(clustering usando K-means)Algoritmo

[33]

DATA TRANSFORMER

Como es señalado por (Zagoruiko, Gulyaevskii, & Kovalerchuk, 2007), la información a ser analizada puede encontrarse en formatos distintos: una imagen, un texto en lenguaje natural o seguir una organización semi-estructurada. Cada tipo de información requiere de métodos especiales de pre-procesamiento cuyo objetivo es transformar los datos de la fuente a forma tabular o, en términos generales, en una forma tal que los datos puedan ser procesados directamente por los algoritmos a ejecutar. La primera responsabilidad de este módulo es responder a esta problemática, es decir, transformar los datos de manera que puedan ser directamente utilizados por el o los algoritmos seleccionados por el TASK CHOOSER.

La aproximación sugerida consiste en complementar la base de conocimiento (las diversas ontologías) con la información necesaria para el pre-procesamiento. Así, a partir de una ontología, un razonador podría hacer deducciones sobre el modo como debe ser manejados los datos. La Figura 13 muestra una parte de la ontología realizada en este tema por los autores recién mencionados.

Aunque la conceptualización mostrada encierra factores técnicos que necesariamente deben ser considerados a la hora de transformar los datos, dichos factores son insuficientes si de automatizar la extracción de conocimiento se trata. El hecho de disponer de los datos de manera tabular, incluso en un formato adecuado, no da respuesta a la pregunta de determinar cómo los datos deben ser presentados a los algoritmos DM; en otras palabras, cómo a partir de los datos disponibles, debe ser construido el itemset y el dataset. Por ejemplo, bajo el supuesto de que se trabaje con la historia crediticia de las personas y se haya determinado que el objetivo de la minería es perfilar clientes, la historia debe ser interpretada y modificada puesto que refleja un comportamiento secuencial que no puede ser directamente capturado por un proceso de CLUSTERING.

[34]

FIGURA 13 CONCEPTUALIZACIÓN DE LA ETAPA DE PRE-PROCESAMIENTO

La base de conocimiento en la que se apoya el DATA TRANSFORMER debería también incluir este tipo de información; el tipo de fuente, lo que potencialmente puede extraerse de ésta (objetivos de la minería) y el modo como deben ser transformados los datos son algunos de los factores que deberían considerarse. Más aún, es recomendable estandarizar el proceso de conceptualización de esta información de modo tal que sea viable la extensión de ARIBEC a otros dominios.

En (Gómez, 2008) se enfrentó la problemática de dicha transformación. Partiendo de una porción de los registros disponibles en el RUAF, se construyó un dataset que permitiera establecer las causas de hospitalizaciones prolongadas. Para ello primero se determinó que el conjunto de datos serían las hospitalizaciones, posteriormente se identificaron los atributos relevantes para el problema y finalmente, antes de pasar a la ejecución del algoritmo de obtención de reglas de asociación, se construyó un conjunto de atributos derivados y se mapeó cada atributo numérico a un conjunto de rangos para obtener reglas más interesantes. Todo el proceso estuvo acompañado de un experto médico que validó las transformaciones realizadas. El trabajo realizado en (Gómez, 2008) constituye un ejemplo del tipo de tareas para el que debería estar facultado este módulo.

RESUMEN

TABLA 7 RESUMEN DATA TRANSFORMER

Nombre Data Transformer Función Transformación de datos a un formato directamente procesable por el

algoritmo seleccionado por el Task Chooser Entradas - Ontología que describe la fuente y el conocimiento extraíble de ésta

- Base de conocimiento que describe cómo deben ser transformados los datos de acuerdo a la fuente

- Algoritmo(s) a utilizar para la extracción de metadata Salidas Datos pre-procesados, dataset e itemset satisfactoriamente construidos. En

PreprocesamientoEscalamiento•Ord–Nom•Abs–Nom•Abs–Ord

Normalización• Por varianza• Por media•De 0 a 1

Extracción de Características•De Señales•De imágenes•De Texto

Medición de Distancias• Entre Taryectorias• Entre Objectos• Entre

Características

[35]

este punto los datos se encuentran normalizados, escalados y semánticamente transformados para ser utilizados por el DM Processor

Prerrequisitos de uso

Los datos deben haber sido limpiados Existencia de una ontología de minería de datos sobre la cual se ejecute el razonamiento Existencia de metadata intencional que describa la fuente a nivel de esquema Ontología que describa la fuente y los posibles objetivos de DM que podrían cumplirse en dicha fuente


Data Cleaner Task Chooser Data Mining Processor

DATA MINING PROCESSOR

Los algoritmos típicos de minería de datos, como aquellos presentados en el marco teórico, requieren de la intervención de un experto del dominio. El experto es responsable de proporcionar conocimiento que permita parametrizar los algoritmos y validar los resultados de la minería.

Como ha sido mencionado por diversos autores (Cespivová, Rauch, Svátek, Kejkula, & Tomecková, 2001), no es posible ni recomendable prescindir de este experto, no obstante, dado el gran número de fuentes que podrían potencialmente incorporarse a ARIBEC, es deseable reducir la complejidad de las tareas del mismo de modo tal que el tiempo y esfuerzo invertido sea acotado a márgenes aceptables.

Una alternativa para lograr este objetivo consiste en enriquecer los algoritmos tradicionales aprovechando el conocimiento del dominio; por ejemplo, seleccionando factores relevantes del contexto se puede reducir el conjunto de parámetros de entrada de un algoritmo y permitir que el sistema haga deducciones a partir de éstos. Este módulo se propone como un componente capaz de ejecutar algoritmos con las

[36]

características mencionadas, su responsabilidad principal es ejecutar el o los algoritmos seleccionados y prestar los servicios necesarios para su parametrización. Dado que eventualmente los algoritmos típicos podrían ser de utilidad no se descarta la inclusión de éstos.

En lo que sigue de esta sección se describen algoritmos y funciones que, puesto que incorporan mediante el uso de ontologías conocimiento del dominio en sus fases de configuración y ejecución, son candidatos a ser parte del conjunto de algoritmos del que este módulo podría disponer.

CLUSTERING

La incorporación de conocimiento del dominio en algoritmos de CLUSTERING es un tema abierto de investigación. Todavía no hay una solución definitiva para utilizar dicho conocimiento con el fin de guiar la segmentación.

Entre las propuestas existentes actualmente se destaca el trabajo realizado por (Liu, Wang, & Yang, 2004) que incorpora directamente el conocimiento en un proceso de CLUSTERING de subespacios usando una ontología jerárquica. La ontología es utilizada para podar el espacio de búsqueda (en principio exponencial). A su vez, el algoritmo genera clusters que pueden enriquecer de forma natural a la ontología puesto que ésta intervino directamente en el proceso de construcción de los mismos.

ÁRBOLES DE DECISIÓN

(Zhang, Silvescu, & Honavar, 2002) extienden el algoritmo básico de árboles de decisión para inducir reglas de clasificación en diferentes niveles de abstracción. En cada paso de construcción del árbol, además del conjunto de atributos candidatos para hacer crecer el árbol, se dispone de una estructura jerárquica por cada atributo de modo que las posibles opciones de selección se amplían a los distintos niveles de abstracción de los candidatos originales.

REGLAS DE ASOCIACIÓN

La obtención de reglas de asociación utilizando conocimiento del dominio ha sido estudiada en (Tseng, Lin, & Jeng, Mining Association Rules with Ontological Information, 2007) y (Tseng, Lin, & Jeng, Incremental Maintenance of Ontology-Exploting Association Rules, 2007) donde se proponen dos algoritmos que utilizan una ontología que describe el dominio para encontrar ítems frecuentes e incrementalmente descubrir reglas de asociación acorde al mismo. La idea fundamental es extender el conjunto de ítems adicionando a cada conjunto aquellos que guardan relación de composición o generalización con los elementos que lo componen.

[37]

MEDIDAS DE SIMILITUD

Mientras que para las personas es fácil saber cuándo dos conceptos son similares, para un computador el razonamiento resulta mucho menos evidente. En efecto, uno de los problemas más comunes relacionados con las búsquedas en bases de datos es la cantidad de resultados obtenidos (Bernstein, Kaufmann, & Bürki, 2005): por un lado ésta puede ser demasiado grande y por otro puede ser demasiado pequeña (incluso nula). La solución al primer problema es basarse en un ranking para retornar sólo los resultados más relevantes. Con respecto al segundo, la solución es retornar respuestas similares a la esperada. En este orden de ideas, la medida de similitud es un elemento indispensable para la implementación de ambas soluciones. Ahora bien, si extendemos esta problemática a la minería de datos, encontramos que la medida de similitud juega también un rol fundamental puesto que tareas como CLUSTERING y clasificación basan su funcionamiento en la cuantificación o cualificación de la similitud entre dos conceptos.

Al involucrar la noción de ontología, es posible crear medidas de similitud que conserven la semántica del dominio y al mismo tiempo puedan ser directamente procesadas por un computador. En ARIBEC, el conocimiento de estas medidas podría ser incorporado como parte de la ontología de minería expuesta anteriormente; dependiendo del tipo de datos y del conocimiento disponible acerca de la fuente, podría usarse una o más de estas medidas para el proceso de extracción de metadata extensional.

Buscando formas para mejorar el desempeño de sus algoritmos de Machine Learning (ML), la división de tecnología de Siemens (Tsymbal, Zillner, & Huber, Feature Ontology for Improved Learning from Large-Dimensional Disease-Specific Heterogeneous Data, 2007) propone redefinir el concepto de similitud mediante la incorporación de conocimiento del dominio. Intuitivamente, si dos conceptos son iguales deberían ser tratados de la misma manera; en términos de ML, si dos conceptos son iguales deberían tener el mismo peso al momento de ser valorados por un algoritmo.

Para consignar el conocimiento del dominio se sugiere utilizar una ontología que registre tanto los conceptos como los pesos que deberían ser asignados a cada uno de ellos. Al integrar dicha ontología a los algoritmos, el resultado que se obtendría es una distribución de pesos que refleje la semántica del dominio y por ende, un conjunto de reglas más acertadas al final de la ejecución. El árbol mostrado en la Figura 14 ilustra la idea. A cada rama de cada nivel se le asigna un peso tal que la suma de todas las ramas con un mismo padre sea igual a uno. El peso relativo que tiene una característica es entonces la multiplicatoria de los pesos que forman un camino hasta ésta.

Bajo la estructura formada las características más especializadas tendrán menor peso frente a otros valores que generalicen más, puesto que su peso total es la multiplicación de valores menores o iguales a uno. Así mismo, a menos que un experto ajuste los pesos, todas las características que están a un mismo nivel tendrán la misma importancia a la hora de aplicar un algoritmo. Finalmente cabe mencionar que aunque en la figura todas

[38]

las características están en las hojas, los autores señalan que podrían estar en cualquier nivel.

FIGURA 14 ONTOLOGÍA DE ASIGNACIÓN DE PESOS

OTRO TIPOS DE SIMILITUD APOYADAS EN ONTOLOGÍAS (BERNSTEIN, KAUFMANN, & BÜRKI, 2005)

1. DETERMINAR EL ANCESTRO COMÚN MÁS RECIENTE (ACMR) La similitud entre un objeto A y un objeto B es calculada a partir de la comparación de las longitudes de los caminos de A-ACMR y B-ACMR. Es altamente dependiente de la construcción de la ontología (de su estructura).

2. FRECUENCIAS DE INSTANCIAS El anterior algoritmo puede complementarse considerando la frecuencia de una instancia en un conjunto de datos. En este sentido, es posible establecer relaciones que consideren a un objeto similar al otro en la medida en que aparezca un número similar de veces.

3. VECTOR DE CONCEPTOS Representa cada objeto como un vector de conceptos en un espacio k-dimensional; según una codificación específica, dos vectores x y y son determinados a partir de dos objetos A y B respectivamente. La similitud es dada por: sim(A,B)=|xy| /|x| *| y|.

4. NÚMERO DE TRANSFORMACIONES La similitud entre un objeto A y un objeto B se calcula como el número de transformaciones necesarias para convertir A en B. Por transformaciones se entiende insertar, remplazar o borrar relaciones y atributos, donde el costo de transformar varía según la operación realizada. En general: c(borrar) + c(instertar) >= c(remplazar).

5. RECUPERACIÓN COMPLETA DE TEXTO Basándose en el método que evalúa la frecuencia de ocurrencia de palabras en documentos de texto, propone crear un documento por cada objeto de la ontología para luego aplicar los algoritmos tradicionales de la web semántica.

[39]

EVALUACIÓN DE MEDIDAS DE SIMILITUD

Las medidas anteriormente descritas deben ser evaluadas para posteriormente ser incluidas como conocimiento en la ontología de minería. En (Tsymbal, Zillner, & Huber, Ontology – Supported Machine Learning and Decision Support in Biomedicine, 2007) se exponen dos técnicas para evaluar una función de distancia destinada a medir la similitud entre dos conceptos, particularmente cuando ésta ha sido diseñada en base a una ontología:

- Similitud percibida por un experto: se realiza comparando un ranking de instancias elaborado por un grupo de expertos con el resultado arrojado por la función al ser aplicada sobre las mismas.

- Evaluación automática guiada por los datos: es usada con frecuencia en ML. La evaluación de la función de similitud es realizada mediante el uso de ésta en un algoritmo de ML; la calidad de la función es entonces determinada a partir del desempeño del algoritmo, se asume que si el algoritmo presenta un comportamiento satisfactorio, la función también.

Debido a la intervención humana existente, la primera técnica puede ser subjetiva y dependiente del contexto, además impone la restricción de trabajar con datasets de tamaño pequeño. Por el contrario, la segunda técnica requiere que se trabaje con una cantidad significativa de datos para evitar que se produzca overfitting.

RESUMEN TABLA 8 RESUMEN DATA MINING PROCESSOR

Nombre DATA MINING PROCESSOR Función Ejecutar algoritmos de minería guiados preferiblemente por el uso de

ontologías Entradas - Algoritmo(s )seleccionado(s)

- Parámetros de ajuste del/los algoritmos Salidas Modelos obtenidos incorporables al repositorio de conocimiento. Prerrequisitos de uso

Existencia de una ontología de dominio que sirva para guiar la ejecución y parametrización de los algoritmos. Dataset construido de acuerdo a los requisitos de cada algoritmo


Data Transformer Task Chooser Presentation Rule Edition Knowlegde Builder

[40]

PRESENTATION & RULE EDITION

Este módulo proporciona un conjunto de herramientas gráficas a través de las cuales el usuario puede validar, modificar u orientar el proceso de extracción de metadata. Este módulo también es responsable de mostrar las reglas extraídas tras la ejecución de los algoritmos.

Cada modelo o perfil obtenido se debe representar de una forma intuitiva y manipulable para el usuario. Por ejemplo, como se sugiere en (Grimm, Hitzler, & Abecke, 2007), los clusters pueden ser visualizados como un grafo donde los nodos tengan el conjunto de características que representan al cluster, y donde clusters similares estén conectados por un arco cuyo costo represente el grado de similitud.

ILUSTRACIÓN 2 VISUALIZACIÓN EN GGOBIT (BLAZ & DEMSAR, 2008)

[41]

Dada la complejidad de una capa de presentación y la diversidad de visualizaciones posibles para un mismo modelo, se recomienda aprovechar las implementaciones realizadas en herramientas de código abierto antes de empezar una implementación desde cero. En este sentido se sugiere revisar herramientas cuyo énfasis ha sido tradicionalmente gráfico tales como KNIME, ORANGE y GGOBIT que han sido destacadas por (Blaz & Demsar, 2008).

ILUSTRACIÓN 3 VISUALIZACIÓN KNIME (BLAZ & DEMSAR, 2008)

[42]

RESUMEN

TABLA 9 RESUMEN PRESENTATION

Nombre Presentation Función Presentar los resultados de la ejecución de minería Entradas Modelos ejecutados Salidas Presentación de resultados Prerrequisitos de uso Ninguno Dependencias directas Data mining processor

Task chooser

KNOWLEDGE BUILDER

Este módulo es el responsable de convertir los modelos o reglas obtenidas en elementos integrables al repositorio de metadata de modo que éstos cumplan las restricciones del mismo. Cada modelo debe representar un perfil o un conjunto de perfiles expresado como un predicado lógico. Por ejemplo, de obtenerse los segmentos mostrados en la Figura 15 y seleccionarse aquellos mostrados en la tabla de la misma figura, habría que construir y registrar los perfiles señalados debajo de la flecha.

FIGURA 15 TRANSFORMACIÓN SEGMENTOS A PERFILES

anticoagulantes

[43]

RESUMEN

TABLA 10 RESUMEN KNOWLEDGE BUILDER

Nombre Knowledge Builder Función Conversión de modelos a elementos integrables a repositorio de metadata e

integración de resultados a dicho repositorio Entradas Modelos validados por el usuario Salidas Modelos integrados a repositorio de conocimiento Prerrequisitos de uso

Los resultados obtenidos tras la ejecución de los algoritmos han sido validados por el usuario


Data mining processor

[44]

VIII. APROXIMACIÓN AL PROCESO DE CONSTRUCCIÓN DE OBME

Como fue visto anteriormente, el objetivo último de OBME es bastante ambicioso: semi-automatizar un proceso de extracción de conocimiento mediante técnicas de minería de datos. La complejidad de cada uno de los módulos sugiere que la construcción del sistema debe pasar por varias etapas dado que un proceso de desarrollo en el que se implemente la totalidad de cada uno por separado resulta inaplicable. Por esta razón, se propone un esquema bottum-up o inductivo donde se desarrollen las etapas mostradas en el diagrama y descritas grosso modo a continuación.

FIGURA 16 CICLO DE IMPLEMENTACIÓN OBME

Aplicación Manual DM Esta etapa consiste en realizar un proceso de minería de datos tradicional aplicado a un contexto específico. Se trata de extraer, siguiendo una metodología típica de minería, la metadata extensional de una fuente particular.

Aplicación Manual DM

Conceptualización del Caso A partir del proceso realizado anteriormente, en esta etapa se pretende hacer una abstracción que permita consignar en ontologías el conocimiento adquirido. Se trata entonces de capitalizar el conocimiento de modo tal que pueda ser construido de forma semi-automática y prescindiendo en la medida que sea posible de los expertos.

Conceptualización del Caso

Implementación

Reproducción Semi

Automatizada

Pruebas en Ambientes Análogos

[45]

Implementación Se desarrollan los artefactos software que permitan el uso de OBME como herramienta de apoyo a la extracción de conocimiento. La implementación debe tener en cuenta la infraestructura GRID en el que se soporta ARIBEC.

Reproducción Semi-automática Una vez implementado el componente software, en esta etapa es necesario verificar que la implementación puede reproducir los resultados obtenidos en el proceso inicial.

En términos prácticos, el propósito de empezar un nuevo ciclo consiste en hacer evolucionar las ontologías que son usadas de una u otra forma por OBME para extraer metadata extensional de las fuentes. Una vez se conoce la nueva información que debe ser agregada a la base de conocimiento, el mantenimiento de la ontología puede llevarse a cabo mediante las seis fases propuestas en (Stojanovic, Mädche, Motik, & Stojanovic, 2002) y mostradas en la

Pruebas en Ambientes Análogos Para verificar que la conceptualización e implementación realizada es lo suficientemente general, se hace necesario verificar su funcionamiento en entornos diferentes al utilizado como base. Si efectivamente es posible extraer conocimiento de manera semi-automática, entonces se puede considerar que el ciclo de desarrollo ha sido exitoso.

Como se puede observar en el diagrama, el desarrollo propuesto consiste en un proceso cíclico donde una vez terminada una iteración es posible iniciar de nuevo para enriquecer OBME y en consecuencia la base de conocimiento. El ciclo puede, bien sea recomenzar en un mismo contexto para otra fuente con el propósito de ampliar la abstracción realizada o, realizarse en otro contexto, lo cual perseguiría la generalización de la extracción a otro tipo de fuentes.

Figura 17.

FIGURA 17 PROCESO DE EVOLUCIÓN DE ONTOLOGÍAS

Del ciclo de implementación de OBME, se puede afirmar que la realización de la etapa 1 es directa siguiendo alguna metodología tradicional como CRISP-DM, metodología ampliamente descrita en (Chapman, Clinton, & Kerber, 2008). La realización de la etapa 2 podría ser adelantada en paralelo con la primera etapa extendiendo la metodología de implementación con tareas que permitan la creación de la ontología mediante la generalización del proceso de minería.

[46]

El uso del proceso de minería como medio para la creación de ontologías es una propuesta alterna al proceso planteado por (Cespivová, Rauch, Svátek, Kejkula, & Tomecková, 2001) donde se propone lo contrario, i.e. el uso de ontologías para la ejecución de minería. En detalle, dicho proyecto plantea el uso de ontologías como apoyo a cada etapa del proceso de descubrimiento de conocimiento siguiendo la metodología CRISP-DM: para inspeccionar el dominio en la etapa de entendimiento del negocio, para identificar atributos redundantes o incompletos en la etapa de entendimiento de los datos, para identificar grupos de atributos comunes en la preparación de los datos, para evitar tener en cuenta hipótesis no relevantes desde el punto de vista ontológico al momento de modelar las diferentes sesiones de minería, en la etapa de evaluación para interpretar los resultados de la minería en términos del negocio consignados en la ontología y, finalmente en la etapa de despliegue o deploy para integrar el nuevo conocimiento mediante el mapeo a una ontología general que permita su uso práctico. Teniendo en cuenta lo que proponen los autores y con el ánimo de generalizar el proceso de consignar en una ontología el conocimiento utilizado, se propone que en cada fase de CRISP-DM, el conocimiento sea conceptualizado tal como lo muestra la Tabla 11.

TABLA 11 CONCEPTUALIZACIÓN DEL PROCESO CRISP-DM

Etapa Tareas Entendimiento del negocio Consignación de aspectos del dominio: tipo de

fuente, objetivos de minería desde la perspectiva del negocio, modos de evaluación de resultados

Entendimiento de datos Tipificación del tipo de datos utilizado, datos que pueden encontrarse, posibles errores que pueden tener

Preparación de datos Modo en que los datos pueden ser corregidos y transformados

Evaluación de los resultados Resultados considerados inválidos, proceso para refinar los perfiles encontrados

Despliegue Forma como los datos pueden ser mapeados a la base de conocimiento

La realización de las tareas de la Tabla 11 puede llevarse a cabo durante o después de seguir los pasos establecidos en CRISP-DM, sin embargo, para no contaminar el proceso de minería se recomienda realizar la conceptualización del caso una vez se ha terminado dicho proceso.

Expuesta la arquitectura y funcionalidades ideales que debería contemplar la solución, así como el procedimiento que a juicio de los autores debería guiar la construcción del módulo, se procede ahora a realizar las etapas 1, 2 y 3 del ciclo con el fin de validar la efectividad del proceso propuesto.

[47]

IX. CASO DE ESTUDIO: SEGMENTACIÓN DE FUENTES A PARTIR DE HISTORÍAS CLÍNICAS.

A la fecha, el escenario principal de aplicación de ARIBEC es una organización virtual del sector salud que integra los actores involucrados en la prestación de servicios de salud en Colombia (Pomares, Roncacio, & Abásolo, Virtual Objects in Large Scale Health Information Systems, 2008). Con el ánimo de avanzar hacia la construcción de OBME en el contexto actual de ARIBEC, se propone aplicar un proceso de minería de datos sobre una Institución Prestadoras de Servicios (IPS) que permita perfilarla según el tipo de servicios que ofrece.

El contexto presenta no pocos retos puesto que según los expertos, la medicina es considerada el dominio más complejo para la aplicación de minería de datos (paradójicamente, se cree que es también uno de los dominios que más se podría beneficiar de esta área). En (Harrinson, 2008) se describen algunas de las características que hacen a los datos médicos especialmente difíciles de analizar utilizando técnicas y metodologías convencionales; entre estos se destacan su alta dimensionalidad, heterogeneidad, imprecisión, falta de completitud e inconsistencia. Además, las restricciones de confidencialidad que tiene inherentemente este campo suelen eliminar las relaciones que guardan los datos con su contexto, perdiéndose así, valiosa información de la fuente (Roddick, Peter, & J., 2003).

A continuación se aplicará la metodología CRISP-DM que busca realizar una primera aproximación a lo que sería la conceptualización del proceso de minería de datos a una fuente con el fin de extraer su metadata extensional. La justificación para la utilización de dicha metodología no es otra que su ya extendido uso en esta disciplina.



Implementación

Reproducción Semi

Automatizada


[48]

ENTENDIMIENTO DEL NEGOCIO

OBJETIVOS DE NEGOCIO Y CRITERIOS DE ÉXITO

El objetivo manifestado por el equipo responsable de ARIBEC es responder eficientemente a las consultas formuladas por un investigador. Lo que OBME puede aportar para alcanzar esta meta es ofrecer mecanismos de perfilamiento de fuentes (o nodos) de manera que usando dicho perfilamiento, sea posible filtrar las fuentes de acuerdo a los datos que contienen y solo sean visitadas aquellas que guarden información relevante para dar respuesta a estas consultas.

Dado que el escenario actual de aplicación de ARIBEC es el sector salud, el perfilamiento debe realizarse sobre fuentes inmersas en este contexto. Siendo de mayor relevancia aquellas que guardan información que sirva para propósitos investigativos como las EPS y las IPS, que son las responsables de almacenar las historias clínicas de los pacientes.

En este orden de ideas, el criterio de éxito consiste en que sea posible determinar para la fuente seleccionada aquello que la caracteriza y diferencia de las otras. El perfilamiento realizado debe aportar información no trivial que no sea posible determinar fácilmente por medios estadísticos. En un contexto ideal, la evaluación de la información extraída debería ser realizada por un experto del negocio, no obstante, dado que no se cuenta con dicho experto y que el propósito de ejercicio más que llegar a la solución definitiva que permita el perfilamiento es realizar una primera aproximación al tema, el responsable de realizar dicha evaluación será el equipo que dirige y coordina las actividades de ARIBEC.

Los resultados deben ser entregados como predicados puesto que la base de conocimiento que construye ARIBEC así los requiere. Adicionalmente, en la medida que sea posible, el proceso debe ser reproducible a otras fuentes del mismo contexto por lo que se debe evitar caer en particularidades propias de la fuente.

EVALUAR SITUACIÓN INICIAL DE NEGOCIO

INVENTARIO DE RECURSOS

PERSONAL

• José Abásolo: asesor principal de OBME, co-asesor de ARIBEC • Diego Ardila: co-resposable de OBME • Julián Badillo: responsable principal del diseño e implementación de la base de

conocimiento • Alexandra Pomares: responsable principal de ARIBEC • Claudia Roncancio: co-asesora de ARIBEC • Natalia Valencia: co-resposable de OBME • María del Pilar Villamil: co-asesora de ARIBEC

[49]

FUENTES DE DATOS

La fuente de datos inicial correspondió a una base de datos donde fue consolidada la información de los RIPs (Avila, 2007). Sin embargo, como será descrito en la fase de entendimiento de los datos, se encontró que dicha fuente no cumplía los requerimientos mínimos de calidad, razón por la cual su uso fue descartado. En consecuencia, la única fuente de datos disponible fueron los archivos originales de los RIPs del período comprendido entre los años 2003 y 2006.

RECURSOS DE INFRAESTRUCTURA

Para la realización del caso de estudio no se cuenta con ningún tipo de hardware especializado. En cuanto al software disponible para el proyecto, es requerimiento que sea software libre e implementado sobre la plataforma Java ya que es necesario mantener compatibilidad con los diferentes componentes del proyecto ARIBEC. Además, para explorar el uso de diferentes técnicas, eventualmente será necesario extender las funcionalidades del software por lo que será indispensable el acceso a su código fuente.

REQUERIMIENTOS, SUPOSICIONES Y RESTRICCIONES

REQUERIMIENTOS

• Confidencialidad: debido a la naturaleza de los datos manejados se debe garantizar que los resultados obtenidos no conlleven a la identificación individual de las personas involucradas.

• Generalidad: es indispensable que los resultados obtenidos no sea influenciados por ningún tipo de sesgo y reflejen la realidad de la fuente.

• Tiempo de Completitud: el caso de estudio junto con la conceptualización de la problemática debe realizarse en un plazo no mayor a cinco meses puesto que es el tiempo dado para los proyectos de grado en la Universidad de los Andes.

SUPOSICIONES

• Se supone que el tipo de información recolectada en los RIPs es suficiente para perfilar fuentes.

• Las entidades vinculadas al sector salud reportan la información con mínimos niveles de calidad, es decir, procuran que cada uno de los datos entregados correspondan con la realidad que se quiere reflejar.

[50]

RIESGOS Y CONTINGENCIAS

Riesgo Contingencia No hay experto de negocio disponible

• Para guiar la elaboración del modelo de datos se propone utilizar la información recopilada en trabajos anteriormente realizados que contaron con la validación de un experto

• Para evaluar los resultados se propone realizar un proceso de validación de la información trivial a partir del conocimiento recopilado por el equipo del proyecto ARIBEC

• Documentar cada una de las ideas propuestas de modo que sean consideradas como futuras alternativas al trabajo realizado

Insuficiencia de la información contenidos en los RIPs

• Recurrir a organizaciones con fuertes vínculos con la universidad que faciliten el acceso a sus datos

• Generar datos semi artificiales que capturen parcialmente la realidad del dominio

Alta dimensionalidad de los datos

• Como fue mencionado en la introducción del caso de estudio, la alta dimensionalidad de los datos es una característica propia de los datos médicos. Se propone crear taxomías que permitan abstraer la información y reducir así la dimensionalidad de los datos

Imposibilidad de Generalizar el proceso

• Presentar alternativas y lecciones aprendidas de modo que sea posible continuar el trabajo en futuros proyectos de investigación

GLOSARIO DE DOMINIO: CASO DE ESTUDIO

A continuación se realiza un glosario de términos de negocio cuyas definiciones corresponden casi en su totalidad con las dadas en el documento de descripción de los RIPs (Camargo & Arteta, 2006). Es de notar que no se realiza el glosario de términos de minería puesto que se entiende que ya han sido ampliamente expuestos a lo largo del documento. TABLA 12 GLOSARIO DE NEGOCIO

Término Definición Causa Causa del evento según reportado por el paciente y/o

acompañantes CIE10 Estándar de codificación bajo el cual se registran los diagnósticos

en los RIPs Comorbilidad Enfermedad que se padece simultáneamente con otros

diagnósticos Diagnóstico Síntomas presentados por un paciente Evento Acontecimiento clínico Finalidad Finalidad bajo la cual se realiza un procedimiento Función Función que pretende cumplir un medicamento suministrado IPS Institución Prestadora de Servicios. Organización que en el marco

[51]

del sistema de salud colombiano ofrece servicios de salud Hospitalización Evento en el que un paciente es hospitalizado Medicamento Medicamento suministrado al paciente durante un evento Procedimiento Procedimiento practicado al paciente y asociado a un evento RIPs Registro Individual de Prestación de Salud. Tipo de registro que

deben reportar las organizaciones del sector salud en Colombia al Sistema General de Seguridad Social en Salud

Sistema Comprometido Sistema fisiológico involucrado en el o los diagnósticos realizados al paciente

COSTOS Y BENEFICIOS

Los beneficios deben entenderse en el marco del proyecto ARIBEC. Dado que la extracción de metadata extensional es uno de los pilares fundamentes del proceso de selección de fuentes, el desarrollo exitoso de este proceso y su posterior conceptualización implicará un avance en la consolidación de ARIBEC. Si es posible determinar aquello que caracteriza la fuente y generalizar los pasos necesarios para perfilarla, se contará con una base concreta para plasmar el conocimiento adquirido durante el proceso y así lograr su aplicación a otras fuentes. Los costos del proyecto son los recursos humanos invertidos y el tiempo necesario para su elaboración. Es de mencionar que aún cuando no se cumplan los objetivos esperados, el solo hecho de realizar el proceso implica un beneficio dado el carácter académico del mismo. El equipo de ARIBEC podrá descartar alternativas basándose en la experiencia obtenida.

OBJETIVOS DE MINERÍA

• Segmentar las historias clínicas hallando las características que distinguen a cada uno de los posibles grupos de historias existentes. CRITERIO DE ÉXITO: obtener clusters que reflejen de forma coherente la realidad del dominio a partir del conocimiento que se tiene del mismo (%clusters inconsistentes < 10%).

• Obtener segmentos que, de acuerdo al conocimiento previo de la fuente, correspondan a los casos más comunes y a los casos extraños. CRITERIO DE ÉXITO: determinar las características de los clusters de historias clínicas de menor y mayor tamaño (#clusters que capturen a 30% o más de la población > 0 y #clusters que capturen a 7.5% o menos de la población > 0).

• Obtener segmentos que sean representables como perfiles en la base de conocimiento de ARIBEC (%clusters representables en ARIBEC > 75%).

[52]

GENERACIÓN DE PLAN DE PROYECTO

El plan de proyecto inicialmente elaborado para el caso de estudio se muestra en el Anexo I. Además de las etapas propias de la metodología CRISP-DM se incluyen etapas adicionales que enfocan al proceso en el contexto de ARIBEC. El plan realizado fue sujeto a modificaciones a lo largo del proyecto con el fin de ajustarlo a las contingencias del mismo.

EVALUACIÓN INICIAL DE HERRAMIENTAS

Como ya fue indicado en el inventario de recursos, el proceso requiere la utilización de herramientas OPEN-SOURCE implementadas sobre la plataforma Java. Este requerimiento implica prestar especial atención al momento de seleccionar dichas herramientas teniendo en cuenta que por su naturaleza pueden no ser totalmente estables y la integración de varias de ellas puede requerir esfuerzos adicionales.

Considerando los factores anteriormente mencionados y partiendo del reporte elaborado por (Blaz & Demsar, 2008), donde se describen algunas de las principales herramientas OPEN-SOURCE para realizar minerías de datos, se seleccionó WEKA como software principal.

WEKA, Waikato Environment for Knowledge Analysis (The University of Waikato, 2008), es un entorno para ejecutar técnicas de machine learning y minería de datos que brinda herramientas para pre-procesamiento, clasificación, regresión, CLUSTERING y reglas de asociación. Dispone de una interfaz gráfica amigable que permite visualizar tanto los datos originales como los datos resultantes de los diferentes procesos que ofrece la herramienta. Finalmente, ofrece la facilidad de integración con Java, que permite el uso de prácticamente todas sus funcionalidades a través de invocaciones a clases; siendo este último requisito indispensable para la integración con los componentes de ARIBEC.

EVALUACIÓN INICIAL DE TÉCNICAS

En cuanto a las técnicas para hacer minería de datos se tuvieron en cuenta las siguientes opciones: CLUSTERING, reglas de asociación y arboles de decisión. Aunque las tres técnicas pueden potencialmente satisfacer los requerimientos del proyecto, teniendo en cuenta que el objetivo del proceso es la obtención de perfiles para una fuente, se determinó que la opción más conveniente es el CLUSTERING ya que sus resultados son de más directa interpretación. A diferencia de una regla de asociación o un árbol de clasificación donde habría que diseñar algún tipo de heurística para interpretar los resultados como perfiles (por ejemplo, determinar que un conjunto de reglas conforma un perfil), cada cluster obtenido puede pasar automáticamente a considerarse un perfil que representa a una

[53]

fuente. De esta forma, los diferentes clusters se convierten en las diferentes facetas de una misma fuente. Cabe mencionar, que se recomienda no descartar del todo las otras técnicas consideradas y analizar su utilización en eventuales y futuros casos de estudio.

ENTENDIMIENTO DE DATOS

RECOLECCIÓN DE DATOS

La principal fuente de datos utilizada fueron los Registros Integrados de Prestación de Servicios de Salud (RIPs). Dichos registros representan la información que por decreto deben entregar las instituciones prestadores de servicios de salud (IPS) al ministerio colombiano de protección social con el fin de facilitar la formulación de políticas de Salud en Colombia.

El conjunto de datos se extrajo de los archivos originales de los RIPs del año 2006, disponibles en un servidor del departamento de Ingeniería de Sistemas y Computación de la Universidad de los Andes. Los archivos fueron descargados y consolidados localmente en una base de datos creada para tal propósito. El listado y descripción de los archivos se muestra en la Tabla 13.

TABLA 13 ARCHIVOS DE FUENTES RIPS

Nombre Archivo Descripción consultas2006.txt Eventos de tipo consultas hospitalizacion2006.txt Eventos de tipo hospitalización medicamentos2006.txt Medicamentos suministrados

durante los eventos procedimientos2006.txt Procedimientos practicados durante

los eventos urgencias2006.txt Eventos de tipo urgencias

Los archivos están en formato separado por comas, donde la primera línea de cada archivo corresponde a su encabezado; en el Anexo II el lector podrá encontrar fragmentos de cada uno. Una descripción bastante detallada de lo que contienen se encuentra en (Camargo & Arteta, 2006).

Para complementar la información, se utilizó la base de datos de (Avila, 2007) donde están disponibles las lista de códigos usadas por los RIPs para los municipios, departamentos, diagnósticos y ocupaciones de pacientes.

Finalmente, se obtuvieron los siguientes pares de archivos para apoyar el proceso de construcción del modelo de datos a partir del trabajo realizado en (Gómez, 2008). Es de

[54]

mencionar que la autora de dicho trabajo los suministró amablemente vía correo electrónico.

TABLA 14 ARCHIVOS DE SOPORTE PARA CONSTRUCCIÓN DEL MODELO

Nombre Archivo Descripción mapeo_generico_funcion.xls Establece la relación entre el

nombre de un medicamento genérico y su función

tabla_mapeo_cie_comorbilidad.xls Establece la relación entre un diagnóstico en código CIE10 y el sistema comprometido

DESCRIPCIÓN DE DATOS

A continuación se listan algunos de los campos más relevantes de los archivos de los RIPs. La descripción se realiza a partir de la información de (Gómez, 2008) y (Noriega, 2001).

TABLA 15 CAMPOS HOSPITALIZACIÓN RIPS

Nombre Campo Descripción COD_IPS Código de la IPS que reporta el evento FACTURA Número de la factura, es útil para relacionar los medicamentos y los

procedimientos con su evento asociado DIAG_PRIN_INGRE Diagnóstico principal de ingreso DIAG_PRIN_EGRE Diagnóstico principal de egreso DIAG_EGRE1 Diagnóstico secundario egreso 1 DIAG_EGRE2 Diagnóstico secundario de egreso 2 SEXO Sexo del paciente EDAD Edad del paciente COD_MPIO Código del municipio COD_DPTO Código del departamento

TABLA 16 CAMPOS PROCEDIMIENTOS RIPS


procedimientos con su evento asociado AMBITO Tipo de evento que genera el procedimiento FINALIDAD Finalidad del procedimiento:

1 = Diagnóstico 2 = Terapéutico 3 = Protección específica 4 = Detección enfermedad temprana 5 = Detección enfermedad profesional

[55]

COD_PROCI Código del procedimiento COD_MPIO Código del municipio COD_DPTO Código del departamento

TABLA 17 CAMPOS MEDICAMENTOS RIPS


procedimientos con su evento asociado TIPO_MEDI NOMBRE_MEDI Nombre del medicamento COD_MPIO Código del municipio COD_DPTO Código del departamento

Los archivos de soporte son archivos derivados del trabajo realizado con ayuda de médicos especialistas en (Gómez, 2008). Dichos archivos contienen los siguientes campos donde se hace una correspondencia o mapeo entre un diagnóstico y el sistema fisiológico que se compromete y un medicamente genérico y la función que cumple:

TABLA 18 CAMPOS ARCHIVO TABLA_MAPEO_CIE_COMORBILIDAD.XLS

Nombre Campo Descripción Código Código CIE10 del diagnóstico Comorbilidad Comorbilidad asociada al diagnóstico Sistema Sistema fisiológico comprometido

TABLA 19 CAMPOS ARCHIVO MAPEO_GENERICO_FUNCION.XLS

Nombre Campo Descripción Función Función que cumple el medicamento Genérico Nombre del medicamento genérico

EXPLORACIÓN Y VERIFICACIÓN DE CALIDAD DE DATOS

Como fue mencionado en la identificación de fuentes, inicialmente se planeó usar una base de datos que contenía los RIPs consolidados, sin embargo el análisis realizado dejó claro que había serias falencias en la calidad y disponibilidad de los datos requeridos. El procedimiento para evaluar la calidad de los mismos consistió en el análisis de todas las tablas y atributos considerados relevantes mediante consultas de la forma:

SELECT COUNT(*) AS NUMVALUES, [ATTRIBUTENAME] FROM [TABLENAME] GROUP BY [ATTRIBUTENAME];

[56]

Las consultas realizadas permitieron establecer los distintos valores consignados en cada columna y por ende la validez de los mismos. El resultado encontrado para la fuente de datos inicial fue desalentador; atributos considerados de gran importancia presentaron múltiples problemas: demasiados valores nulos (algunos campos hasta un 85%), columnas cuyos valores no guardan relación (ni semántica ni sintáctica) con lo descrito en la documentación, falta de consolidación de los RIPs de medicamentos, tablas vacías, ausencia de reglas de integridad a excepción de la llave primaria, entre otros. En la tabla Tabla 20 se muestra el resultado de la exploración realizada, en la Tabla 40 y la Tabla 41 del Anexo III se presentan los detalles de la evaluación para las tablas de mayor interés (Evento y Procedimiento).

TABLA 20 REPORTE CALIDAD DE DATOS BASE DATOS CONSOLIDADA RIPS

Nombre Tabla Relevante Comentario

PROCEDIMIENTOTEMP NO Se asume que hace parte de las tablas temporales que creadas durante el proceso de cargue

PROCEDIMIENTO SI Alto grado de inconsistencias

EVENTOTEMP NO Tabla Vacía

CAUSA_EXTERNA SI Se obtienen las causas

DEPARTAMENTOS SI Se obtienen los departamentos

CIE SI Se extraen los diagnósticos

FINALIDAD_CONSULTA NO Considerada no relevante

PERSONAL SI Personal del procedimiento

FINALIDAD_PROCEDIMIENTO SI No integrado con procedimientos

MUNICIPIO SI Se obtienen los municipios

TIPOAFILIADO NO No relevante

TIPODIAGNOSTICO SI Resultado consulta vacío

TIPOEVENTO SI Determinar hospitalizaciones

TIPOUSUARIO NO Tabla Vacía

TIPOIDENTIFICACION NO Considerada no relevante

EVENTO SI

INTERCONSULTA NO Toda la información está en la hospitalización

MEDICAMENTOS03 MEDICAMENTOS05 MEDICAMENTOS04 MEDICAMENTOS06

SI No integrado con eventos y procedimientos

PROC_A NO No hay documentación sobre la tabla, se cree que es otra de las tablas temporales

[57]

Descartado el uso de la base datos consolidada se recurrió a los archivos originales de los RIPs. De los distintos períodos disponibles se seleccionó el periodo 2006 como sujeto a estudio puesto que era el período en el que mayor cantidad de datos se habían reportado. El proceso de exploración de datos fue similar al realizado para la primera fuente de datos, aplicando una vez más el tipo de consultas ya mencionado.

Cabe notar que de los tipos de eventos de los que se tiene información en los RIPs, únicamente se exploraron las hospitalizaciones. La justificación para esta decisión será expuesta en la siguiente etapa del proceso.

Los archivos RIPs (aquellos considerados) del año 2006 son un conjunto de tres archivos en los que reposan los datos reportados por más de 5000 IPS de todo el país durante el período referenciado. Su tamaño en número de registros es el que se muestra en la Tabla 21.

TABLA 21 NÚMERO DE REGISTROS RIPS

Nombre Archivo Número de Registros Hospitalizacion2006 267875 Medicamentos2006 10255083 Procedimientos2006 11780891

Puesto que el objetivo del proceso es perfilar una fuente, inicialmente se optó por seleccionar la IPS (identificada por el campo COD_IPS) que más hospitalizaciones hubiese reportado como la fuente sujeta a estudio. No obstante, a partir del análisis que se llevó a cabo se determinó que la cantidad de eventos válidos de dicha fuente no era la deseable para cubrir los requerimientos del proceso de minería.

En este escenario se decidió analizar como una única fuente cinco entidades que hubiesen entregado datos de razonable calidad; los objetivos no se ven afectados puesto que lo importante es la totalidad del proceso y no los resultados del perfilamiento. Las IPS identificadas junto con su respectiva cantidad de registros en cada archivo se muestran a continuación:

TABLA 22 REGISTROS REPORTADOS FUENTES SELECCIONADAS

COD_IPS Hospitalizaciones Medicamentos Procedimientos 1800100025 4965 65100 183283 7600103799 2870 80553 103988 8500106101 1943 5152 90548 2530700022 1699 263761 57524 5200100557 1525 109323 34006 Seleccionadas las fuentes, el siguiente paso en la exploración consistió en la verificación de aquellos atributos considerados clave.

[58]

La exploración arrojó dos resultados de gran interés. El primer hallazgo fue el encontrar una gran cantidad de nombres de medicamentos no válidos y muchas hospitalizaciones sin medicamentos reportados. En este caso se decidió prescindir de los respectivos registros para el proceso de minería y tener en cuenta la ausencia de medicamentos para el análisis de los modelos.

TABLA 23 MUESTRA NÚMERO DE OCURRENCIAS POR MEDICAMENTO

Nombre Medicamento (NOMBRE_MEDI) Número de Ocurrencias Nombre vacío o con espacio 324226 SODIO CLORURO AL 0 9p X 500 CC 10965 RANITIDINA AMPOLLAS X 50 MGR 8638 SOLUCION DE SUERO FISIOLOGICO 8341 DIPIRONA AMPOLLAS X 2 GRAMOS 6580 SOL. SUERO FISIOLOGICO X 100 M 6479 METOCLOPRAMIDA AMPOLLA X 10 MG 5025 RANITIDINA X 50 MG 4282 DIPIRONA SODICA 2 5 GM NOVAL 4264 SOLUCION DE LACTATO DE RINGER 3778 RANITIDINA TABLETAS X 150 MGR 3053

El segundo resultado consistió en confirmar lo encontrado en (Gómez, 2008) para los datos analizados en cuanto a la existencia de facturas repetidas. A pesar de que de acuerdo a la semántica del campo, dicho valor debería ser único en todos los eventos de una misma entidad puesto que constituye un identificador del mismo, se encontraron registros donde no se da cumplimiento a la restricción. Al igual que en el trabajo referenciado, se descartan los eventos que presentan duplicación en dicho campo.

En cuanto a los demás datos, no se encontraron mayores anomalías. Las causas de eventos reportadas presentan concentración en aquellas con código 13 y 15. Hay gran diversificación de diagnósticos y la cantidad pacientes de sexo femenino es el doble de los de sexo masculino.

PREPARACIÓN DE DATOS

SELECCIÓN DE DATOS

La información que está almacenada en las fuentes del sector salud es, fundamentalmente, un conjunto de historias clínicas. Si bien es claro que tales historias reúnen un conjunto de eventos donde está la evolución del paciente en el transcurso del tiempo, cabe preguntarse si dicha evolución debe capturarse al momento de perfilar la información de las fuentes. De la respuesta a dicha pregunta depende si el tiempo es o no relevante para la construcción del modelo.

[59]

Para el perfilamiento de las fuentes en el sector salud, se consideraron dos alternativas. La primera consiste en perfilar los pacientes cuya información se encuentra en las fuentes y segmentarlas de acuerdo a los pacientes que cada una trata, buscando capturar la noción de tiempo a través de la evolución de sus historias. La otra alternativa, consiste en perfilar los eventos de los que la fuente tenga registro y agrupar las fuentes según las características de los eventos que atienden sin considerar la fecha en que ocurrieron.

A continuación se describen más a fondo, cada una de las alternativas: perfilamiento de pacientes y segmentación de eventos.

PERFILAMIENTO DE PACIENTES

Para perfilar pacientes se propone hacer CLUSTERING de sus historias clínicas (HC). Para tal fin se plantearon dos métodos que permiten incluir la noción de historia.

AGRUPACIÓN DE EVENTOS

El primer método consiste en hacer CLUSTERING sobre los primeros n eventos de las historias clínicas, obteniendo así una segmentación inicial de pacientes según las características que los distinguen en la primera fase de su historia. A continuación se realiza de nuevo el proceso de CLUSTERING, ahora en cada uno de los segmentos obtenidos en la fase anterior, incluyendo los siguientes n eventos de las HC. El proceso continúa hasta que se cubra la totalidad de los eventos que componen la historia tal como se muestra en la Figura 18.

Rescatando la influencia de un evento que sucede antes que otro, es posible tener en cuenta la noción de historia de un paciente encontrada en las HC. Sin embargo, este método depende de la selección del parámetro n de agrupamiento de eventos: si n es muy pequeño el número de clusters generados crece exponencialmente y si n es demasiado grande, la granularidad de los clusters formados puede ser demasiado gruesa y el tamaño de los registros usados por formarlos, de muy alta dimensionalidad. Además, también puede crecer demasiado según los tipos de pacientes involucrados: un adulto sano puede ir al médico solamente una vez al año y por ende registrar en su HC un único evento, mientras que una persona de avanzada edad que tenga problemas de salud puede acumular un número de eventos considerable cada año.

[60]

FIGURA 18 ALTERNATIVA PERFILAMIENTO HISTORIAS CLÍNICAS

Con el ánimo de dar solución al problema de crecimiento exponencial del método presente, se propone realizar una agrupación de eventos ontológicamente similares que permita disminuir el número total de eventos en la HC de cada paciente. Por ejemplo, si un paciente tuvo una fractura de brazo y además una fractura de tobillo, no se incluirían “fractura en extremidad superior” y “fractura en extremidad inferior” como dos eventos aislados sino simplemente se obtendría un evento que las agrupe “fractura de miembros”. Eventos considerados de poca importancia para fines de segmentación de fuentes, como por ejemplo gripas o consultas a inyectologías podrían ser descartados. Finalmente, eventos de significativa importancia y/o consecutivos, podrían ser agrupados y a sus campos, ser asignado un peso mayor.

CONSTRUCCIÓN DE FUNCIÓN

El segundo método propuesto consiste en mapear cada atributo de la HC a una función que lo represente. De esta manera, cada HC sería vista como un conjunto de funciones dependientes del tiempo. Al momento de realizar CLUSTERING el algoritmo que lo ejecute debe poseer una función de similitud capaz de comparar las formas de dichas funciones. La ventaja obtenida al comparar la forma y no la función es que dos pacientes que presenten un comportamiento similar a través del tiempo van a pertenecer a un mismo cluster aunque los eventos en sus HC hayan ocurrido en fechas diferentes. No obstante, a pesar de que la construcción de una función representante puede ser trivial en algunos

[61]

casos (e.g. edad), en otros puede ser una tarea de complejidad considerable (e.g. diagnóstico) dado que no es clara la representación numérica de atributos categóricos.

SEGMENTACIÓN DE EVENTOS

La segunda alternativa consiste en segmentar los diferentes eventos registrados en una fuente sin considerar el orden en el que ocurrieron ni el paciente al que pertenecen. Cada evento es manejado de forma independiente y solo se tiene en cuenta la información directamente relacionada con cada uno en particular.

Dada la gran cantidad de eventos que pueden existir, se puede reducir el total de eventos manejados descartando aquellos relacionados con urgencias y consultas médicas. La justificación para poder descartar dichos eventos es que por conocimiento del dominio es sabido que las urgencias y consultas de gravedad desembocan necesariamente en una hospitalización. Por otra parte, para el proceso de selección de fuentes lo fundamental son aquellos eventos que proporcionen información sobre la especialidad de la fuente y ésta necesariamente debe estar capturada en las hospitalizaciones.

SELECCIÓN DE ALTERNATIVA

Teniendo en cuenta que el propósito del proyecto es la extracción de metadata para la selección de fuentes, se optó por la segunda alternativa: segmentación de eventos de tipo hospitalización. La primera alternativa fue descartada debido a su alta complejidad y a que se determinó que más que información acerca de la fuente aportaba información sobre los pacientes.

Ahora bien, elegida la alternativa, se selecciona a continuación la información de las hospitalizaciones que será utilizada para construir los registros sujetos a CLUSTERING.

Para realizar la selección de dicha información se partió de una valoración de prioridad para cada uno de los campos de una hospitalización y las tablas relacionadas con este evento. Se seleccionaron aquellos atributos considerados relevantes según el conocimiento del dominio disponible.

Los cinco componentes principales de la historia clínica son:

1. Datos subjetivos proporcionados por el paciente. 2. Datos objetivos obtenidos de la exploración física y de las exploraciones

complementarias. 3. Diagnóstico. 4. Pronóstico 5. Tratamiento.

Teniendo en cuenta estos componentes y la información disponible de una hospitalización se seleccionaron los atributos mostrados en la Figura 19.

[62]

FIGURA 19 HOSPITALIZACIÓN BASE

LIMPIEZA DE DATOS

Para la limpieza de datos además de suprimir las hospitalizaciones con facturas repetidas se corrigió el nombre de los medicamentos de modo que coincidieran con los medicamentos contenidos en el mapeo del archivo mapeo_generico_funcion.xls.

La corrección se realizó mediante el desarrollo de una aplicación en Java cuya funcionalidad principal es determinar, para un nombre de medicamento existente en los RIPs, el nombre del medicamento más próximo en el archivo de mapeo. Como se puede observar en el código de la Figura 20, el algoritmo toma cada posible valor a mapear y lo compara con el medicamento que actualmente se está analizando; el nombre del medicamento corregido es aquel para el cual se obtuvo la menor “distancia” entre las alternativas del mapeo.

El cálculo de la distancia entre los nombres del medicamento se llevó a cabo mediante el algoritmo de comparación de cadenas Levenshtein que calcula el mínimo número de operaciones necesarias para convertir una cadena en otra; su funcionamiento detallado puede encontrarse en (Levenshtein Algorithm, 2008). A continuación se presentan algunos de los mapeos obtenidos al ejecutar la aplicación de limpieza.

TABLA 24 EJEMPLOS DE LIMPIEZA DE REGISTROS

Nombre Original Nombre Corregido OMEPRAZOL 20 MG OMEPRAZOL AMPICILINA X 1GR AMPICILINA INSULINA-INSULINA HUMANA NPH X 100 UI INSULINA MORFINA X 10 MG X 1 ML MORFINA

[63]

FIGURA 20 CORRECCIÓN DEL NOMBRE DEL MEDICAMENTO

Es importante mencionar que debido a la ausencia de valores válidos para ciertos registros, se incurre en errores no controlables que requerirían intervención de un experto para ser corregidos, posiblemente mediante el enriquecimiento del archivo de mapeo. Por ejemplo, en el archivo de mapeos para medicamentos no hay ningún valor válido para la medicina de nombre “Complejo B”. Otros registros poseen nombres muy similares y el algoritmo tiende a confundirlos como es el caso de la Ranitidina y la Ranitiolina.

CONSTRUCCIÓN E INTEGRACIÓN DE DATOS

La construcción e integración de los datos consistió en la obtención de atributos derivados y el análisis del manejo que debía darse a las variables categóricas. A continuación se presenta el procedimiento realizado a este punto y la descripción del registro consolidado para hacer CLUSTERING.

ABSTRACCIÓN DE ATRIBUTOS

Para manejar el hecho de que una historia clínica puede tener uno o muchos procedimientos, uno o muchos diagnósticos y uno o muchos medicamentos, se crearon nuevos atributos abstrayendo taxonómicamente dichos campos, utilizando para ello los mapeos construidos en (Gómez, 2008). La idea es extender a columnas cada posible valor de los atributos abstraídos.

A cada diagnóstico se le asignó alguno de los sistemas fisiológicos que se vieran afectados por la enfermedad encontrada en el paciente. Ejemplos de este mapeo se

[64]

muestran en la Tabla 25. Del mismo modo, para cada medicamento, se deriva la función que cumple en el paciente; ejemplos de este mapeo se muestran en la Tabla 26. TABLA 25 EJEMPLOS MAPEO DIAGNÓSTICO - SISTEMA COMPROMETIDO

Diagnóstico Sistema Comprometido INFARTO SUBENDOCARDICO AGUDO DEL MIOCARDIO sistema_cardiaco_comprometido DEFICIENCIA DIETETICA DE CALCIO sistema_renal_comprometido ENFERMEDAD PULMONAR OBSTRUCTIVA CRONICA, NO ESPECIFICADA

sistema_respiratorio_comprometido

CIRROSIS HEPÁTICA ALCOHÓLICA sistema_hepatico_comprometido ULCERA DUODENAL AGUDA CON PERFORACION sistema_gastrointestinal_comprometido ENFERMEDAD DE PARKINSON sistema_neurologico_comprometido LINFOMA LINFOEPITELIOIDE sistema_hematologico_comprometido INFECCION DE VIAS URINARIAS, SITIO NO ESPECIFICADO sistema_genito_urinario

TABLA 26 EJEMPLOS MAPEO MEDICAMENTO - FUNCIÓN MEDICAMENTO

Medicamento Función Medicamento FUROSEMIDA DIURÉTICOS CARVEDILOL BETABLOQUEADORES ASPIRINA ANTIAGREGANTES_PLAQUETARIOS DALTEPARINA ANTICOAGULANTES MOFETIL INMUNOSUPRESORAS DEXAMELAXONA GLUCOCORTICOIDES NPH INSULINA FENOBARBITAL ANTICONVULSIONANTES OMEPRAZOL ÁCIDOPÉPTICA MORFINA OPIOIDES LORAZEPAM ANSIOLITICOS TRAZADONE HIPRIOTICOS SINOPAN ANTISICOTICOS SERTRALINA ANTIDEPRESIVOS PENICILINA ANTIBIÓTICOS

Además de buscar obtener segmentos más fácilmente interpretables, el objetivo de abstraer taxonómicamente algunos atributos es evadir la maldición de la dimensionalidad que establece que el tamaño de una muestras representativa aumenta exponencialmente con respecto al número de dimensiones o atributos (Hand, Mannila, & Smyth, 2001).

ESCALAMIENTO Y ATRIBUTOS CATEGÓRICOS

Generalmente las implementaciones de algoritmos de CLUSTERING como K-means no tienen un buen funcionamiento con atributos categóricos y se hace necesario convertirlos a valores numéricos. Igualmente, si las escalas son diferentes es necesario normalizar los valores para obtener medidas comparables. WEKA, la herramienta

[65]

utilizada para realizar CLUSTERING, ofrece funcionalidades útiles para realizar este pre-procesamiento, no obstante, no es indispensable utilizarlas puesto que los algoritmos de CLUSTERING de WEKA manejan tanto atributos numéricos como categóricos y además normalizan automáticamente los valores cuando efectúa los cálculos de distancia entre los mismos. Así pues, no fue necesario realizar conversiones de tipo categórico a numérico, solamente se definieron rangos de edad para facilitar la caracterización de los clusters obtenidos. TABLA 27 RANGO DE EDADES

Rango Edad Grupo [0-18) Niño [18-65) Jóven [65-80) Adulto >= 80 Adulto mayor

DESCRIPCIÓN DE REGISTRO CONSOLIDADO Y PROCESO DE CONSTRUCCIÓN

Derivados los atributos, un evento para aplicar CLUSTERING fue modelado de acuerdo a la Tabla 28. Tal como se mencionó anteriormente, ningún manejo especial fue dado a las variables categóricas. TABLA 28 DESCRIPCIÓN DE CAMPOS HOSPITALIZACIÓN DERIVADA

Atributo Descripción Age Edad del paciente Cause Causa que produjo la hospitalización del paciente medicineFunction Función de la o las medicinas prescritas al paciente. Un

atributo por cada función de medicamento identificada. Si en el evento se prescribió una medicina que cumple la función X, el atributo que representa la función X toma el valor “Yes”, de lo contrario, toma el valor “No”.

primaryInvolvedSystem Sistema fisiológico comprometido purposeProcedure Propósito de los procedimientos realizados al paciente. Un

atributo por cada propósito de procedimiento posible. Si en el evento se realizó un procedimiento con el propósito X, el atributo que representa el propósito X toma el valor “Yes”, de lo contrario, toma el valor “No”.

secondaryInvolvedSystem Segundo sistema fisiológico comprometido. Atributo derivado de acuerdo al mapeo

Sex Género del paciente

Los registros consolidados fueron construidos extendiendo la aplicación implementada para limpiar los datos de modo que ésta transformara los registros de acuerdo a las especificaciones de la Tabla 28 y los almacenara en un archivo con el formato requerido

[66]

por la herramienta de minería de datos. Un ejemplo de una instancia de dicho registro se muestra en el recuadro a continuación; se trata de una hospitalización de una persona adulta, de sexo femenino, que tiene comprometido primariamente su sistema cardíaco y a quien fue suministrada un anticoagulante durante su atención. Una muestra más detallada del archivo formado se muestra en el Anexo IV.

TABLA 29 EJEMPLO REGISTRO CONSOLIDADO

Atributo Valor Age adulto Sex F primary_involved_system sistema_cardiaco_comprometido secondary_involved_system NINGUNO Cause 13 ANTICOAGULANTES YES BETABLOQUEADORES NO GLUCOCORTICOIDES NO ANTIDEPRESIVOS NO DIURÉTICOS NO ANTIBIÓTICOS NO ÁCIDOPÉPTICA NO ANTIAGREGANTES_PLAQUETARIOS NO ANSIOLITICOS NO INMUNOSUPRESORAS NO ANTISICOTICOS NO HIPRIOTICOS NO OPIOIDES NO INSULINA NO ANTICONVULSIONANTES NO Deteccion_Temprana_Enfermedad_Profesional NO Diagnostico YES Terapeutico NO Proteccion_Especifica NO Deteccion_Temprana_Enfermedad_General NO

MODELAMIENTO

SELECCIÓN TÉCNICA DE MODELAMIENTO

Como ya fue presentado, la familia de técnicas seleccionadas corresponde al conjunto de algoritmos de CLUSTERING. De dicha familia se seleccionaron los algoritmos mostrados en la Tabla 30, teniendo como criterio su disponibilidad en la herramienta de minería (WEKA).

[67]

TABLA 30 ALGORITMOS DE CLUSTERING UTILIZADOS

Nombre Descripción Simple K Means (KM) Algoritmo tradicional de k medias Farthest First (FF) Similar a K medias donde el punto más lejos al centro del cluster

es seleccionado como nuevo centro Expectation - EM Modelo estadístico que sirve para encontrar estimadores de

máxima verosimilitud de parámetros en modelos probabilísticos que dependen de variables no observables

DISEÑO DE PRUEBAS Y CONSTRUCCIÓN DEL MODELO

Puesto que los algoritmos de CLUSTERING son bastante sensibles frente a cómo los clusters son formados inicialmente y en general cómo son ajustados sus distintos parámetros, se procuró cubrir un amplio rango de valores para comparar y evaluar los resultados.

Los parámetros variados fueron:

• Cantidad de semillas que serán seleccionadas para iniciar la formación de clusters (S).

• Número de clusters objetivo que se quiere formar (N).

Adicionalmente para el algoritmo EM fue necesario ajustar los siguientes parámetros:

• Máximo número de veces en los que el algoritmo itera (I). • Máxima desviación estándar de los clusters (M).

La forma como fueron cambiados los algoritmos se muestra en la Tabla 31 a continuación:

TABLA 31 VARIACIÓN DE PARÁMETROS

Parámetro Mínimo Valor Máximo Valor Delta de variación S 5 15 5 N 2 5 1 I 100 1000 100 M 10.0-3 10.0-2 10.0-3

En total se obtuvieron 10 escenarios de prueba para cada uno de los algoritmos de la Tabla 30 (30 en total). Los resultados se muestran en el Anexo V.

Cada algoritmo generó un tipo diferente de segmentación. KM formó segmentos de tamaño homogéneo tal como los mostrados en la Figura 21 donde todos los clusters representan al menos el 10% de las hospitalizaciones. Debido a su lógica de recalcular los centros a partir del punto más cercano al mismo, tendió a focalizarse en los casos

[68]

comunes, razón por la cual ninguno de los clusters obtenidos se caracterizó por la función de algún medicamento (es necesario recordar que la gran mayoría de eventos no tienen reportados medicamentos).

FIGURA 21 DISTRIBUCIÓN DE TAMAÑOS SEGMENTACIÓN KM: S=5, N=3

TABLA 32 DETALLE SEGMENTACIÓN KM: S=5, N=3

Cluster 1 2 3

Rango Edad Adulto Niño Adulto Sexo F M M Sistema Primario Comprometido

Cardíaco Cardíaco Cardíaco

Sistema Secundario Comprometido

Ninguno Cardíaco Cardíaco

Finalidad Procedimiento

Diagnóstico Terapéutico

Diagnóstico Terapéutico Diagnóstico Terapéutico

Causa Hospitalización Enfermedad General Enfermedad General Enfermedad General Función Medicamento No Reportada No Reportada No Reportada

FF por su parte, tendió a formar en cada una de sus ejecuciones un segmento de gran tamaño acompañado de segmentos muy pequeños que apenas llegan a representar un mínimo porcentaje de la población. Dichos segmentos corresponden a casos poco comunes en donde si es posible observar que se presentan clusters diferenciados por una o más funciones de medicamentos y otras características que no aparecieron al utilizar KM.

17%

33%

50%

1

2

3

[69]

FIGURA 22 DISTRIBUCIÓN DE TAMAÑOS SEGMENTACIÓN FF: S=5, N=3

TABLA 33 DETALLE SEGMENTACIÓN FF: S=5, N=3

Cluster 1 2 3

Rango Edad Adulto Adulto mayor Anciano Sexo F M M Sistema Primario Comprometido

Neurológico Gastrointestinal Cardíaco


Ninguno Genitourinario Neurológico

Finalidad Procedimiento Diagnóstico Diagnóstico Terapéutico

Terapéutico

Causa Hospitalización Enfermedad General

Enfermedad General Enfermedad General

Función Medicamento No reportada Glucocorticoides Ácido Péptica Ansiolíticos

Anticoagulante Glucocorticoides Opioides

En cuanto al algoritmo EM, no fue no posible obtener convergencia para ninguno de los casos de prueba, razón por la cual sus resultados fueron omitidos. Se cree que dicho comportamiento se explica en la naturaleza categórica de los datos que hacen inadecuada la utilización del algoritmo para las instancias de hospitalizaciones formadas.

EVALUACIÓN DEL MODELO

A pesar de no tener disponible la opinión de expertos en el dominio que validen los resultados obtenidos, es posible deducir el nivel de validez de la segmentación realizada

97%

1% 2%

1

2

3

[70]

de acuerdo a conocimientos generales relacionados con el dominio de la salud en Colombia.

En términos generales las segmentaciones encontradas reflejan la realidad del dominio, siendo muy poco común la aparición de clusters con características contradictorias o improbables. Para los datos analizados predominan las enfermedades cardíacas y hematológicas cuya población afectada es primariamente adulta y de sexo femenino. Se presentan además niños con enfermedades gastrointestinales a quienes se les suministró medicamentos con funciones relevantes para el tratamiento de este tipo de enfermedad.

En cuanto a los tipos de perfiles encontrados, como se mencionó anteriormente, las segmentaciones de KM aluden a casos comunes en la fuente por lo que en ninguno de los segmentos hallados hay indicios de los medicamentos suministrados. Las agrupaciones de este algoritmo presentan un cluster cuyo tamaño por lo menos duplica a sus homólogos del mismo grupo. Las características de dicho cluster tienden a reaparecer en las segmentaciones pese a variar los valores de los parámetros del algoritmo. Tal es el caso de las segmentaciones mostradas en la Tabla 34 y la Tabla 35 que son presentadas a modo de ilustración; los clusters identificados por el número 1 de ambas segmentaciones aparecieron respectivamente en 7 y 5 de los 12 escenarios.

A partir del comportamiento observado, una hipótesis que puede considerarse es que utilizando el algoritmo KM se puede seleccionar los segmentos de mayor tamaño cuya aparición sea recurrente en los distintos escenarios de prueba. Dicha hipótesis podría ser validada a futuro en otras fuentes del mismo dominio.

TABLA 34 SEGMENTACIÓN KM: S=10, N=2

Cluster 1 2

Rango Edad Adulto Adulto

Sexo F F

Sistema Primario Comprometido Cardíaco Cardíaco

Sistema Secundario Comprometido Ninguno Ninguno

Finalidad Procedimiento Diagnóstico Terapéutico Diagnóstico Terapéutico

Causa Hospitalización Enfermedad General Enfermedad General

Función Medicamento No Reportada No Reportada

Tamaño 76 24

TABLA 35 SEGMENTACIÓN KM: S=10, N=3

Cluster 1 2 3

Rango Edad Adulto Adulto Adulto

Sexo F F M

Sistema Primario Comprometido Hematológico Gastrointestinal Cardíaco

Sistema Secundario Comprometido Ninguno Ninguno Ninguno

[71]

Finalidad Procedimiento Diagnóstico Terapéutico Diagnóstico Terapéutico Diagnóstico Terapéutico

Causa Hospitalización Enfermedad General Enfermedad General Enfermedad General

Función Medicamento No Reportada No Reportada No Reportada

Tamaño 62 15 23

Por otra parte, los segmentos de FF se refieren a los casos especializados o pocos comunes que representan perfiles mucho más detallados en la fuente. En este caso se considera que son de interés cualquiera de los perfiles que capture menos del 10% de la población y que al igual que KM, su aparición se repita en los distintos escenarios de prueba. Tal condición es cumplida por los clusters identificados con el número 3 de la Tabla 36 y la Tabla 37.

TABLA 36 SEGMENTACIÓN FF: S=10, N=3

Cluster 1 2 3

Rango Edad Adulto Adulto Mayor Niño

Sexo F F M

Sistema Primario Comprometido

Hematológico Gastrointestinal Gastrointestinal


Ninguno Ninguno Ninguno


Diagnóstic Terapéutico



Causa Hospitalización

Enfermedad General Enfermedad General Enfermedad General

Función Medicamento

No Reportada Glucocorticoides Ácido Péptica Ansiolíticos

Glucocorticoides Antidrepresivos Diuréticos

Tamaño 98 1 1

TABLA 37 SEGMENTACIÓN FF: S=10, N=4

Cluster 1 2 3 4

Rango Edad Adulto Adulto Mayor Anciano Niño

Sexo F M M F


Neurológico Gastrointestinal Cardíaco Hematlológico


Ninguno Genitourinario Neurológico Gastrointestinal

Finalidad Procedimiento Diagnóstico No Reportada Diagnóstico Terapéutico



Enfermedad General


Función Medicamento No Reportada Glucocorticoides Ácido Péptica Ansiolíticos


Glucocorticoides Diuréticos Antibióticos Antiagregantes

Tamaño 97 0 1 1

[72]

El anterior análisis lleva a deducir que el modelo desarrollado refleja la realidad del dominio. Un análisis de un experto en el dominio y la verificación experimental de las hipótesis lanzadas permitiría además establecer con seguridad si el tipo de perfiles encontrados es adecuado para servir en el proceso de selección de fuentes.

EVALUACIÓN

EVALUACIÓN DE RESULTADOS

Además de los modelos obtenidos, vale la pena destacar que el proyecto sirvió para identificar el manejo que deben recibir los datos para la extracción de metadata extensional. Dicho aspecto es fundamental ya que más importante que los perfiles específicos encontrados en el caso de estudio, lo importante es la forma cómo fueron construidos ya que se espera que el proceso seguido sea razonablemente replicable a otras fuentes del mismo dominio.

Aunque se puede establecer el éxito o fracaso del proyecto a partir de los objetivos inicialmente planteados, la evaluación no puede considerarse completa hasta que un experto analice el modelo y sus resultados. Este aspecto será enfatizado a continuación y retomado al final del documento, en el trabajo futuro.

REVISIÓN DEL PROCESO

En las etapas de limpieza y transformación los datos fueron manipulados de manera transparente, evitando toda posible tergiversación de la información que contienen. Esto sirvió como garantía para asegurar que los resultados obtenidos al ejecutar las diferentes técnicas de minería fueran acordes a la realidad.

Por otra parte, la selección de los algoritmos y el ajuste a los parámetros se realizó metódicamente, repitiendo el número de ejecuciones múltiples veces para refinar los resultados.

Para la evaluación de los resultados desafortunadamente no se contó con la retroalimentación que podría entregar un experto del dominio por lo que a mediano plazo es importante cumplir con esta tarea.

DETERMINAR PRÓXIMOS PASOS

Una vez realizado el proceso de minería de datos es necesario pasar a su conceptualización como parte del proceso de despliegue de modo que sea posible integrarlo a ARIBEC y posteriormente replicado en otras fuentes.

Se requiere además la revisión de los resultados con un experto del dominio para realizar un análisis en profundidad de los modelos obtenidos. En dicho análisis debe esencialmente discutirse si la forma como fueron segmentados los datos de la fuente es

[73]

suficiente para diferenciarla de otras de su mismo tipo de manera que a la hora de procesar una consulta pueda establecerse si la fuente perfilada tiene o no información relevante para la misma.

DESPLIEGUE

PLAN DE DESPLIEGUE

• Presentar reporte de los resultados: la presentación fue realizada en dos de las reuniones programadas semanalmente para el seguimiento del proyecto.

• Conceptualización del proceso: la conceptualización será descrita en la siguiente sección de este documento.

EVALUACIÓN DEL PROYECTO

El uso de la metodología CRISP-DM marcó la ruta del proceso de minería de datos y facilitó la organización de los pasos a seguir y de la documentación a consignar.

A pesar de las dificultades enfrentadas para obtener datos confiables y a las contrariedades relacionadas con la calidad de los datos, se obtuvieron resultados válidos y lo que es más importante, aprovechables.

En cuanto a los requerimientos fijados en el inicio del proceso se puede afirmar:

• Confidencialidad: no se violó de ninguna manera la confidencialidad de la identidad de los pacientes.

• Generalidad: los resultados no fueron influenciados por sesgos en el proceso y por ende se asume que reflejan la realidad de la fuente.

• Tiempo de Completitud: el caso de estudio logró desarrollarse durante el plazo ordinario establecido por la Universidad de los Andes, sin embargo el proceso de conceptualización de la problemática necesitó de un plazo adicional, extraordinario, para alcanzar su absoluta completitud.

En cuanto a los objetivos trazados:

• Segmentar las historias clínicas hallando las características que distinguen a cada uno de los posibles grupos de historias existentes. CRITERIO DE ÉXITO: obtener clusters que reflejen de forma coherente la realidad del dominio a partir del conocimiento que se tiene del mismo (%clusters inconsistentes < 10%). CUMPLIDO: SI, menos del 5% de los clusters presentaron características anormales o incoherentes de acuerdo al conocimiento del dominio.

[74]

• Obtener segmentos que, de acuerdo al conocimiento previo de la fuente, correspondan a los casos más comunes y a los casos extraños. CRITERIO DE ÉXITO: determinar las características de los clusters de historias clínicas de menor y mayor tamaño (#clusters que capturen a 30% o más de la población > 0 y #clusters que capturen a 7.5% o menos de la población > 0). CUMPLIDO: SI, la utilización de los dos algoritmos permitió obtener clusters que representan tanto las características muy comunes en la fuente como aquellas consideradas raras o muy especializadas.

• Obtener segmentos que sean representables como perfiles en la base de conocimiento de ARIBEC CRITERIO DE ÉXITO : %clusters representables en ARIBEC > 75%. CUMPLIDO: SI, por construcción la totalidad de los resultados pueden ser directamente convertidos a un predicado de primer orden.

Finalmente, es importante destacar que aunque efectuado de forma manual, el proyecto sirvió para realizar una aproximación concreta a la problemática de extracción de metadata extensional con fines de selección de fuentes. Dicho trabajo no había sido desarrollado con anterioridad.

Completado el proceso de minería de datos usando la metodología CRISP-DM, se hace necesario pasar a la fase de conceptualización del caso de modo que sea posible generalizarlo a otras fuentes.

[75]

X. CONCEPTUALIZACIÓN DEL CASO

En el Capítulo V se explicó que la conceptualización consiste en la abstracción del conocimiento utilizado durante el proceso tradicional de minería (caso de estudio) mediante la identificación de los pasos claves del mismo. A continuación se realiza dicha abstracción:

A grandes rasgos, la síntesis del caso realizado se muestra en la Figura 23. El primer paso consistió en enmarcar el proceso en la problemática de segmentación de una entidad de tipo IPS del sistema colombiano de seguridad social a partir de la información relacionada con los eventos que maneja. Una vez los objetivos de minería fueron determinados, se procedió a extraer y limpiar los eventos de tipo hospitalización.

Posteriormente, los eventos extraídos fueron sometidos a un proceso de transformación donde se derivó para cada evento los sistemas comprometidos en el mismo, las finalidades de los procedimientos practicados y las funciones de los medicamentos suministrados. El propósito de dicho proceso fue preparar los datos de modo que fueran procesables por el algoritmo.

Preparados los datos se ejecutaron dos algoritmos diferentes de CLUSTERING (KM y FF). Cada segmentación obtenida representó un grupo de perfiles distinto. Aquellos modelos inconsecuentes con la realidad fueron descartados. Finalmente, el experto del negocio pudo haber evaluado los resultados y aportado la información que según él enriquecería el conocimiento extraído.

En la Tabla 38 se relaciona para cada paso del proceso las decisiones y conocimientos claves. Para completar la conceptualización se debería incorporar la información



Implementación

Reproducción Semi

Automatizada


[76]

presentada en una ontología, sin embargo, dadas las limitaciones de tiempo del proyecto, se prefiere pasar a la implementación de un primer prototipo que sirva como base para replicar el proceso realizado en otras fuentes.

FIGURA 23 CONCEPTUALIZACIÓN DE CASO DE ESTUDIO

TABLA 38 IDENTIFICACIÓN DE PASOS CLAVE

Etapa Tareas Entendimiento del negocio

Objetivos de Minería: perfilamiento de una IPS del sector salud

Entendimiento de datos

Extracción de la información de un evento de tipo hospitalización. De éste se extrajeron los campos mostrados en la Figura 19 Hospitalización base

Preparación de datos La información de los medicamentos fue corregida mediante un listado previo de medicamentos válidos La hospitalización base sirvió para transformar los registros en una hospitalización derivada de acuerdo a la Tabla 28 Descripción de campos hospitalización derivada

Construcción de Modelos y Evaluación de los resultados

Se ejecutaron dos algoritmos de CLUSTERING. KM sirvió para identificar los casos comunes en los datos. FF los casos especializados Se descartaron segmentos no válidos En este punto, un experto de la fuente debe seleccionar que segmentaciones sirven para perfilar la fuente

Despliegue Los datos pueden ser transformados directamente a predicados de primer orden. Para ello basta con interpretar el conjunto de n características que representan un segmento seleccionado como una conjunción

[77]

XI. IMPLEMENTACIÓN DE PROTOTIPO Y REPRODUCCIÓN DEL CASO

Hecha la conceptualización del caso de estudio, el siguiente pasó consistió en diseñar un prototipo que capturara la información del proceso. Dicho prototipo fue implementado en la plataforma Java 1.5 siguiendo el paradigma orientado a objetos.

FINALIDAD Y ALCANCE DEL PROTOTIPO

El prototipo fue hecho con la finalidad de evaluar la viabilidad de una solución que de forma escalable procesara los datos de la fuente y extrajera la metadata extensional.

Por esta razón, para no introducir complicaciones innecesarias en el desarrollo, se hicieron las siguientes simplificaciones:

• La integración con ARIBEC y la base de conocimiento se supone resuelta. Un componente aísla dicha integración.

• Se supone que se conoce la metadata intencional de la fuente, razón por la cual, se está en capacidad de extraer la información requerida. En la práctica la información es en realidad extraída de una base de datos relacional sin utilizar los servicios de extracción de ARIBEC.

Por otra parte, debido a restricciones de tiempo las siguientes limitaciones en su alcance fueron definidas:



Implementación

Reproducción Semi

Automatizada


[78]

• No se utiliza ninguna tecnología asociada a ontologías, sin embargo, su construcción fue realizada de modo que a futuro pueda usarse la implementación como punto de partida de un sistema que sí tenga como centro una base concreta de conocimiento. No debe perderse de vista que la solución propuesta por los autores es lo que idealmente debería ser el componente de extracción de metadata extensional.

• No se cuenta con una capa de presentación. Todos los resultados son almacenados en un archivo que contiene las distintas segmentaciones obtenidas.

DISEÑO DEL PROTOTIPO

La Figura 24 muestra el diagrama de clases a alto nivel de la aplicación. Un controlador sirve como fachada a los servicios que presta el módulo. Éste a su vez delega la responsabilidad de extraer la metadata a un conjunto de componentes diseñados para tal función.

Para extraer la metadata, el cliente del sistema debe especificar la fuente sujeta a análisis, el dominio del cual se desea extraer metadata y la tarea que se utilizará para dicho propósito (parámetros encapsulados en la clase MiningMetadata). La información del dominio y la tarea es utilizada por el controlador para instanciar los componentes específicos a los parámetros suministrados.

La instanciación se realiza mediante las clases AbstractDomainFactory y ComponentFactory que implementan el patrón FACTORY a dos niveles (según dominio y según tarea de minería). De esta forma lo que se busca es minimizar el impacto de extender el prototipo a otros dominios y a otras formas de perfilamiento.

El controlador instancia primero una fábrica de tareas específica al dominio. Para el alcance dado al prototipo el único dominio válido es HEALTH que representa el sector salud. Instanciada la fábrica de tareas, se instancia una fábrica de componentes capaz de crear componentes que representan cada uno de los pasos del proceso de acuerdo a la tarea de minería establecida por el usuario. Así, para el caso implementado (proceso de perfilación simple), existe un componente extractor, uno de limpieza, otro de transformación, uno de persistencia de datos y uno responsable de construir y almacenar los modelos a partir de los datos transformados.

El conjunto de componentes puede variar de tarea a tarea y es específico al dominio particular. En consecuencia, de quererse extender a otro dominio la perfilación simple, habría que implementar un nuevo conjunto de componentes.

[79]

FIGURA 24 DISEÑO DEL PROTOTIPO

Los detalles de implementación de cada componente para la perfilación simple en el sector salud, se pueden encontrar en la Figura 25; en ésta se observa que todos los componentes de la generación (exceptuando el transformador) delegan sus funciones a controladores específicos a cada etapa del proceso. Los componentes guardan relaciones de dependencia entre sí puesto que constituyen una cadena de responsabilidad (patrón chain of responsability) basada en filtros (pipeline) que permite comenzar la siguiente etapa del proceso sin esperar la finalización de la etapa inmediatamente anterior.

FIGURA 25 DETALLES DISEÑO DE PROTOTIPO

[80]

El extractor utiliza un DAO que debería integrarse a los servicios de extracción de datos de ARIBEC. En el escenario ideal, el controlador del extractor de datos debería usar una base de conocimiento para indicar al DAO qué información debe ser extraída.

Las etapas de limpieza y transformación utilizan un DAO para obtener los mapeos empleados durante el desarrollo del caso de estudio. Tres tipos de mapeos son devueltos por el objeto: mapeo de medicina a función medicamento, mapeo de diagnóstico a sistema comprometido y mapeo de procedimiento a finalidad del mismo.

El proceso de análisis de la fuente cierra con la ejecución de los algoritmos de CLUSTERING (aquellos identificados en la conceptualización del caso de estudio) mediante la clase HealthProfilerMiner que utiliza el API de WEKA para tal propósito. Una clase que responde al patrón command aísla el llamado a dicho API para reducir el acoplamiento entre el prototipo y WEKA.

RESULTADOS DEL PROTOTIPO

El prototipo implementado reproduce exitosamente el caso de estudio considerando las restricciones establecidas. Tras la ejecución de escenarios de prueba para el servicio proveído por el prototipo, se comprobó que el archivo generado contiene los segmentos que debían ser encontrados.

La ejecución del prototipo sirvió además para detectar dos limitaciones que no fueron consideradas durante la etapa de diseño. La primera limitación detectada consistió en notar que la extracción de los datos debe realizarse eficientemente, extrayendo solo la información estrictamente necesaria para el procesamiento y eliminando aquellos valores que ya hayan sido procesados. Extraer la totalidad de los datos para luego procesarlos, resulta poco viable dada la gran cantidad de eventos que puede tener reportada una hospitalización. La segunda, fue notar las limitaciones que presenta WEKA al trabajar con grandes volúmenes de datos. Se encontró que WEKA requiere cargar la totalidad de los datos en memoria antes de su procesamiento, lo que puede desembocar en el agotamiento de la memoria del sistema.

Ambas limitaciones deberían ser subsanadas en caso de continuar con el camino planteado.

[81]

XII. CONCLUSIONES

En este proyecto se estudió la problemática de extracción de metadata extensional mediante técnicas de minería de datos con fines de selección de fuentes, como parte del desarrolló del sistema ARIBEC.

Se encontró que la problemática está determinada por la imposibilidad de seguir un proceso tradicional de minería de datos (donde se cuente con expertos de minería y del dominio) en cada fuente durante su etapa de incorporación, dado el gran número de fuentes que potencialmente pueden participar en el sistema.

Para responder a dicha problemática se propuso un módulo que busca reducir la cantidad de tiempo y recursos invertidos en un proceso tradicional de minería de datos mediante la utilización de una ontología que integre conocimiento que sirva para guiar y realizar de forma semi-automática los procesos de extracción, limpieza y transformación de datos, selección y ejecución de algoritmos y evaluación de resultados. La base de conocimiento (ontologías) consigna tanto información técnica asociada a expertos en minería como la información del dominio que en un proceso tradicional es aportada por un experto de negocio. La forma de construcción del módulo sigue un proceso inductivo que parte de la aplicación manual de metodologías como CRISP-DM para conceptualizar y hacer viable la reproducción del caso con poca intervención humana.

El módulo planteado asume la existencia de metadata intencional, expresada como una ontología local, puesto que se considera indispensable el conocimiento de la estructura de la fuente para el análisis de la misma. Así mismo, se supuso resuelto el problema de mapear de la ontología local a la ontología global o de referencia para el sistema.

Con el propósito de evaluar las ideas expuestas, se realizó un caso de estudio y un primer prototipo de extracción de metadata como parte del proceso inductivo propuesto:

El caso de estudio consistió en el desarrollo de un proyecto CRISP-DM cuyo objetivo fue perfilar la fuente a partir de los eventos de tipo hospitalización. Para ello, se utilizaron dos algoritmos de segmentación o CLUSTERING sobre los datos contenidos en los RIPs: KM y FF. Los segmentos obtenidos describieron la realidad de los eventos de la fuente, siendo KM apropiado para encontrar las características predominantes en las hospitalizaciones y FF más idóneo para encontrar los cúmulos especializados.

El prototipo encapsuló las tareas realizadas durante el caso de estudio y reprodujo de forma exitosa los resultados obtenidos cuando se analizó la fuente de forma manual. Se considera que el prototipo implementado sirve como base para el desarrollo de futuros sistemas más complejos que además estén totalmente integrados a la infraestructura de servicios de ARIBEC.

[82]

XIII. RECOMENDACIONES Y TRABAJO FUTURO

En caso de continuarse por la senda propuesta se recomienda dar prioridad al problema de extracción de metadata intencional puesto que como fue señalado en diferentes partes del documento, dicha tarea es necesariamente previa a la extracción de metadata extensional.

Por otra parte, en cuanto a la conceptualización de la problemática y a la solución propuesta, como ha sido descrito, la solución involucra el desarrollo y uso de una amplia base de conocimiento. Aunque esto puede ser una herramienta muy valiosa para la automatización de la solución de la problemática, es importante tener presente los retos que una aproximación de este tipo pueden potencialmente implicar. Algunos desafíos son (Shillabeer & Darius, 2007):

• El tiempo y los recursos humanos requeridos para construir y mantener una base de conocimiento suficientemente completa para ser utilizada de forma práctica.

• La necesidad de aplicar conocimiento subjetivo para prevenir la exclusión de patrones marginales o no usuales.

• La necesidad de estar seguros de que la base de conocimiento fue desarrollada en base a un dataset y contexto lo suficientemente similar al conjunto de datos y contexto objetivo para hacer plausible la comparación.

En cuanto al caso de estudio, se hace necesario validar los resultados obtenidos con un experto del dominio e iterarlo si la aproximación propuesta no permite perfilar la fuente satisfactoriamente. Eventualmente, puede ensayarse con otras alternativas de perfilamiento de acuerdo a las recomendaciones del experto. En caso de que la aproximación sea satisfactoria, es necesario enriquecer los mapeos utilizados durante el desarrollo del caso de estudio puesto que el alcance de éstos dependió de un contexto muy especializado en donde hay medicinas y diagnósticos que no fueron considerados.

En cuanto a la conceptualización del caso, debe concretarse el diseño de la ontología de minería de datos y plasmar dicho diseño en el lenguaje de implementación utilizado en ARIBEC.

En cuanto a la implementación del prototipo, a futuro se debe completar la integración de éste con la infraestructura de ARIBEC y el uso de ontologías para la toma de decisiones. Adicionalmente, debe desarrollarse una interfaz gráfica para el mismo de modo que el usuario pueda participar en el proceso de extracción de conocimiento.

En cuanto al proceso de construcción de OBME, lo que debería venir a continuación del trabajo descrito es el desarrollo de pruebas en fuentes alternativas para validar la conceptualización realizada (en caso de que el experto determine que la forma de perfilar las fuentes en el caso de estudio es satisfactoria).

[83]

Tal como llegó a mencionarse, se recomienda dividir los frentes de trabajo para la continuación del proyecto en dos. Por una parte la realización de otros casos de estudio de acuerdo a una metodología tradicional de minería de datos, siendo muy deseable el análisis de otras fuentes diferentes a los RIPs. Por otra, la integración concreta de ontologías al proyecto.

Finalmente, se recomienda realizar un levantamiento de servicios previo a cualquier implementación que tenga como fin la integración con la infraestructura de ARIBEC. Se necesita conocer el estado real de dicho sistema y determinar qué servicios pueden ser reutilizables y cuáles no tras el cambio de enfoque realizado: de base de datos referencial a repositorio de metadatos.

FIGURA 26 PROCESO FUTURO OBME



Implementación

Reproducción Semi

Automatizada


[84]

XIV. GLOSARIO

TABLA 39 GLOSARIO

Término Definición ARIBEC Sistema de mediación orientado por servicios diseñado para

contextos distribuidos a gran escala que caracterizan a las organizaciones virtuales

Base de Conocimiento Repositorio de metadata Clustering Algoritmo de agrupamiento de datos típicamente usado para

segmentar un conjunto de datos. Conceptualización Proceso de abstracción de un caso de estudio que busca

capturar el conocimiento recopilado en el desarrollo del mismo para ser consignado en una ontología

CRISP-DM Metodología para la realización de procesos de minería de datos Dataset Conjunto de datos, usualmente en forma tabular, que será

analizado en un proceso de minería DM Data Mining Esquema Estructura lógica bajo la cual se almacena información en la

fuente Itemset Conjunto de ítems que constituyen una muestra para el

algoritmo de minería de datos Metadata Tipo de información que describe las fuente en ARIBEC Metadata Extensional Metadata que describe la fuente a nivel de contenido Metadata Intencional Metadata que define la estructura de la fuente y las instancias

que posee ML Machine Learning OBME Ontology Based Metadata Extractor, propuesta de solución para

la extracción de metadata extensional en el proyecto ARIBEC Ontología de Minería Ontología que captura conocimiento relacionado a la Minería de

Datos Ontología General o Global En el contexto de ARIBEC, ontología en la cual se encuentra

consignado conocimiento de minería de datos para permitir la ejecución semiautomática del proceso

Ontología Local En el contexto de ARIBEC, ontología que contiene la información intencional de la fuente, es decir, que describe el esquema manejado por la fuente para guardar los datos.

Repositorio de Metadata Repositorio que almacena la metadata de la fuentes utilizada por ARIBEC

Similitud (Medida) Medida que permite cuantificar en términos numéricos qué tan similares son dos instancias

SISPRO Bodega de datos del Ministerio de Protección Social que actualmente sirve como base de datos referencial

[85]

XV. REFERENCIAS

Avila, M. (2007). ANÁLISIS DE LA BASE DE DATOS DEL SISTEMA GENERAL DE SEGURIDAD SOCIAL DE SALUD. Bogotá.

Badillo, J. (2008). ARQUITECTURA DE SERVICIOS PARA LA OBTENCIÓN Y ESPECIFICACIÓN DE META-DATOS INTENCIONALES Y EXTENSIONALES EN ORGANIZACIONES VIRTUALES A GRAN ESCALA. Bogotá.

Bernstein, A., Kaufmann, E., & Bürki, C. (2005). How Similar Is It? Towards Personalizad Similarity Measures in Ontologies. En O. K. Ferstl, E. J. Sinz, S. Eckert, & T. Isselhorst, Wirtschaftsinformatik 2005 (págs. 1347-1366). Physica-Verlag HD.

Berry, M., & Linoff, G. (2004). Data Mining Techniques For Marketing, Sales, And Customer. Wiley Publishing Inc.

Blaz, Z., & Demsar, J. (2008). Open-Source Tools for Data Mining. Clinics in Laboratory Medicine , 37-54.

Calvanese, D., Giacomo, G. d., Lembo, D., Lenzerini, M., & Rosati, R. (2005). Description Logics for Ontologies. Proceedings of the 20th National Conference on Artificial Intelligence .

Camargo, F., & Arteta, M. (2006). El sistema integral de información de la protección social - SISPRO. Bogotá.

Cespivová, H., Rauch, J., Svátek, V., Kejkula, M., & Tomecková, M. (2001). Roles of Medical Ontology in Association Mining CRISP-DM Cycle.

Chapman, P., Clinton, J., & Kerber, R. (8 de 2008). CRISP-DM 1.0. Step-by-step data mining guide. Recuperado el 13 de 10 de 2008, de CRISP-DM 1.0: http://www.crisp-dm.org/CRISPWP-0800.pdf

Corcho, O. F.-L.-P. (Julio de 2003). Methodologies, tools and languages for building ontologies. Where is their meeting point? Data and Knowledge Engineering , págs. 41-64.

Curé, O., & Jeansoulin, R. (2007). Data Quality Enhancement of Databases Using Ontologies and Inductive Reasoning. Springer-Verlag Berlin heidelberg , 1117-1134.

Data Mining Applications. (8 de 2004). Recuperado el 18 de 10 de 2008, de kdnuggets: http://www.kdnuggets.com/polls/2004/data_mining_applications_industries.htm

Davies, J., Rudi, S., & Warren, P. (2006). Semantic Web Technologies Trends and Research in Ontology-based Systems. Chichester, West Sussex, PO19 8SQ, England: Wiley.

Ehrig, M., Haas, P., Hefke, M., & Stojanovic, N. (2005). Similarity for Ontologies - A comprehensive framework. Proceedings of 13th European Coference on Information Systems .

[86]

Freitas, A. A. (2003). A Survey of Evolutionary Algorithms for Data Mining and Knowledge Discovery. New York: Springer-Verlag.

Garcia-Molina, H., Papakonstantinou, Y., Quass, D., & Rajaraman, A. (1997). The tsimmis approach to mediation: Data models and languages. Intelligent Information Systems , 117-132.

Gómez, V. (2008). USO DE MINERÍA DE DATOS EN LA DESCRIPCIÓN DE HOSPITALIZACIONES PROLONGADAS. Bogotá: Universidad de los Andes.

Gottgroy, P., Kasabov, P. N., & MacDonell, S. (2004). An Ontology driven approach knowledge discovery in Biomedicine .

Gottgroy, P., Kasabov, P. N., & MacDonell, S. (2003). Building Evolving Ontology Maps for Data Mining and Knowledge Discovery in Biomedical Informatics.

Graco, W., Semenova, T., & Dubossarsky, E. (2007). Toward Knowledge-Driven Data Mining. SIGKDD Workshop on Domain Driven Data Mining. San Jose, California, USA: ACM.

Grimm, S., Hitzler, P., & Abecke, A. (2007). Knowledge Representation and Ontologies. En S. Grimm, R. Studer, & A. Abecke, Semantic Web Services (págs. 51-106). New York: Springer.

Grobelnik, M., & Mladenic, D. (2006). Knowledge Discovery for Ontology Construction. En J. Davies, S. Rudi, & W. Paul, Semantic Web Technologies: Trends and Research in Ontology-based Systems (págs. 9-25). Chichester, England: John Wiley & Sons, Ltd.

Hand, D., Mannila, H., & Smyth, P. (2001). Principles of Data Mining. Cambridge, Massachusetts : MIT Press.

Harrinson, J. H. (2008). Introduction to the Mining Clinical Data. Clinincs in Laboratory Medicine , 1-7.

IBM. (14 de 9 de 2006). Mine DB2 XML columns with DB2 Data Warehouse Edition data mining. Recuperado el 18 de 10 de 2008, de Intelligent Miner articles and tutorials: http://www.ibm.com/developerworks/db2/library/techarticle/dm-0609bendel/index.html

Jain, A., & Dubes, R. (1988). Algorithms for Clustering Data. New Jersey: Prentice-Hall Inc.

Jain, A., Murty, M., & P.J., F. (2000). Data Clustering: A Review. ACM Computing Surveys.

Kedad, Z., & Métais, E. (2002). Ontology-Based Data Cleaning . Springer-Verlag Berlin Heidelberg , 137-149.

Kossmann, D. (2000). The state of the art in distributed query processing. ACM Comput Surv. , 422-469.

[87]

Kuo, Y.-T., Lonie, A., Sonenberg, L., & Paizis, K. (2003). Domain Ontology Driven Data Mining. A medical case study.

Levenshtein Algorithm. (2008). Recuperado el 10 de 10 de 2008, de Levenshtein: http://www.levenshtein.net/

Lin, M.-S., Zhang, H., & Yu, Z.-G. (2006). An Ontology for Supporting Data Mining Process. Computational Engineering in Systems Applications, IMACS Multiconference (págs. 2074-2077). Beijing, China: IEEE.

Liu, J., Wang, W., & Yang, J. (2004). A framework for ontology-driven subspace clustering. Conference on Knowledge Discovery in Data (págs. 623-628). New York, USA: ACM.

Noriega, S. O. (2001). GUÍA PARA LA IMPLEMENTACIÓN EN LOS . Bogotá: Ministerio de Protección Social.

Omelayenko, B. (2001). Learning of Ontologies for the Web: the Analysis of Existent Approaches. Proceedings of hte International Workshop on Web Dynamics, 8th International Conference on Database Theory.

Phillips, J., & Buchanan, B. G. Ontology-Guided Knowledge Discovery in Databases.

Pollock, J. (2004). Metadata Archetypes. En J. Pollock, Adaptative Information (págs. 127-144). John Wiley & Sons, Inc.

Pomares, A. (2007). El proyecto ARIBEC.

Pomares, A., Roncacio, C., & Abásolo, J. (2008). Virtual Objects in Large Scale Health Information Systems. En Global Healthgrid: e-science Meets Biomedical Informatics. Amsterdam, Berlin, Oxf, Wash: IOS Press.

Rahm, E., & Do, H. H. (1999). Data Cleaning: Problems and Current Approaches. IEEE Computer Science Technical Committe on Data Engineering .

Roddick, A. S., & Roddick, J. F. (s.f.). Reconceptualising Interestingness Metrics for Medical Data Mining.

Roddick, J. F., Peter, F., & J., G. W. (2003). Explanatory Medical Knowledge Discovery: Experiences And Issues.

Shillabeer, A., & Darius, P. (2007). Determining pattern element contribution in medical datasets. Australian Computer Society, Inc. , 223-240.

Singh, S., Vajirkar, P., & Lee, Y. (2003). Context-Based Data Mining Using Ontologies. En Conceptual Modeling - ER 2003 (págs. 405-418). Berlin / Heidelberg: Springer Berlin / Heidelberg.

[88]

Stojanovic, L., Mädche, A., Motik, B., & Stojanovic, N. (2002). User-driven ontology evolution management. Knowledge Engineering and Management (EKAW 2002),. Springer.

Sumathi, S., & Sivanandam, S. (2006). Introduction to Data Mining and its Applications. Springer.

(2007). The Globus Alliance. Globus toolkit 4.

The University of Waikato. (2008). Recuperado el 10 de 11 de 2008, de Weka 3: Data Mining Software in Java: http://www.cs.waikato.ac.nz/ml/weka/

Tseng, M.-C., Lin, W.-Y., & Jeng, R. (2007). Incremental Maintenance of Ontology-Exploting Association Rules. Proceedings of the sixth international conference on Machine Learning and Cybernetics (págs. 19-22). Hong Kong: IEEE.

Tseng, M.-C., Lin, W.-Y., & Jeng, R. (2007). Mining Association Rules with Ontological Information. IEEE.

Tsymbal, A., Zillner, S., & Huber, M. (2007). Feature Ontology for Improved Learning from Large-Dimensional Disease-Specific Heterogeneous Data. Proceedings of the Twentieth IEEE International Symposium on Computer-Based Medical Systems (págs. 595-600). Washington, DC, USA: IEEE Computer Society.

Tsymbal, A., Zillner, S., & Huber, M. (2007). Ontology – Supported Machine Learning and Decision Support in Biomedicine. En Data Integration in the Life Sciences (págs. 156-171). Berlin / Heidelberg: Springer Berlin / Heidelberg.

Wolpert, D. M. (1997). No free lunch theorems for optimization. Evolutionary Computation, IEEE Transactions on , 67 - 82.

Zagoruiko, N. G., Gulyaevskii, S. E., & Kovalerchuk, B. Y. (2007). Ontology of the Data Mining Subject Domain. Pattern Recognition and Image Analysis , 349-356.

Zhang, J., Silvescu, A., & Honavar, A. (2002). Ontology-Driven Induction of Decision Trees at Multiple Levels of Abstraction.

[89]

XVI. ANEXOS

I. PLAN DE PROYECTO INICIAL CASO DE ESTUDIO

Etapa Acciones principales Entradas Salidas Entendimiento de negocio - Reunión con personas involucradas en

el proyecto. - Lectura de proyectos relacionados. - Definición de objetivos con asesor.

- Artículos, reportes y tesis relacionadas.

- Objetivos de negocio y criterios de éxito definidos. - Objetivos de minería definidos. - Plan de proyecto elaborado.

Entendimiento de datos - Explorar fuentes de datos: base de datos consolidada y RIPs. - Análisis de calidad de datos. - Obtención de archivos de mapeo para diagnósticos y medicamentos.

- Información de acceso a base de datos. - Archivos RIPs. - Información de contacto con autora de los mapeos.

- Mapeos diagnóstico a sistema comprometido y medicamento a función medicamento. - Reporte de calidad de datos para las fuentes disponibles.

Preparación de datos - Limpieza y transformación de los datos. - Selección de técnicas y herramientas a utilizar.

- Datos y mapeos.

- Datos limpios y registros dispuestos para la ejecución de minería.

Modelamiento - Diseño de plan de pruebas. - Construcción de modelos. - Evaluación de modelos.

- Técnicas seleccionadas. - Registros preparados.

- Modelos encontrados. - Plan de pruebas diseñado. - Reporte de evaluación de modelos.

Evaluación - Evaluación de resultados. - Evaluación del proceso.

- Modelos obtenidos. - Documentación del proceso escrita hasta el momento.

- Reporte de evaluación de resultados y proceso. - Pasos a seguir.

Despliegue - Presentación de resultados. - Evaluación del proyecto.

- Resultados obtenidos. - Evaluación del proceso.

- Reporte de evaluación y cierre del proyecto. - Presentación de resultados a interesados en el proyecto.

II. EXPLORACIÓN DE BASE DE DATOS CONSOLIDADA RIPS

TABLA 40 EXPLORACIÓN DE DATOS TABLA PROCEDIMIENTO - BD CONSOLIDADA RIPS

Procedimiento Relevante Comentario

ID_PROCEDIMIENTO NO Es un consecutivo CODPROCEDIMIENTO NO Valores sin patrón aparecen:

1333, CFF8, 14-24, EPS345

FECHA NO

AMBITO SI En la documentación se dice que un ámbito puede ser Ámbito Descripción 1 Ambulatorio 2 Hospitalario 3 En urgencias. Parece que son números de identificación

FINALIDADPROCEDIMIENTO SI Tipo de documento DIAGPRINCIPAL NO Se pretenderá usar el dato del

evento

DIAGR1 NO Se pretenderá usar el dato del evento

DIAGCOMPLICACION NO Se pretenderá usar el dato del evento

PERSONAL SI VALOR NO Son códigos del tipo:08,09 y no

valores en pesos

ID_EVENTO SI Para identificar el evento del procedimiento

IDPROCEDIMIENTO NO 82.5% Valores no nulos

TABLA 41 EXPLORACIÓN DE DATOS TABLA HOSPITALIZACIÓN - BD CONSOLIDADA RIPS

Nombre Campo Relevante Comentario

ID_EVENTO Para filtrar la fuente CODIGOIPS NO CODIGOEAPB NO FACTURA NO FECHAINGRESO Para seleccionar

período

HORAINGRESO Para seleccionar

[92]

período FECHAEGRESO Para seleccionar

período

HORAEGRESO Para seleccionar período

CAUSAEXTERNA SI DIAGINGRESO SI ??? DIAGPRINCIPAL SI DIAGR1 NO Considerado de poco interés DIAGR2 NO Considerado de poco interés DIAGR3 NO Considerado de poco interés DIAGCOMPLICACION NO Considerado de poco interés DIAGMUERTE SI ??? VALOR NO Resultado Consulta Vacío TIPOIDENTIFICACION NO Considerado de poco interés SEXO SI EDAD SI TIPOUSUARIO NO Tabla Tipousuario vacía CODDEPARTAMENTO SI Considerar utilizar año,

superficie, importancia, etc..

CODMUNICIPIO SI Considerar utilizar año, superficie, importancia, etc..

TIPOAFILIADO NO Considerado de poco interés CODOCUPACION SI 85% Valores Nulos CODCONSULTA NO Resultado Consulta Vacío FINALIDAD SI Resultado Consulta Vacío TIPODIAGNOSTICO SI Resultado Consulta Vacío VALORNETO NO Resultado Consulta Vacío VALORCUOTA NO Resultado Consulta Vacío VIAINGRESO Pendiente 9517 - 1

92 3 - 3 91047 - 2

DESTINO NO Resultado Consulta Vacío ID_TIPOEVENTO SI Para filtrar la fuente ID_HOSPITALIZACION NO No aplica ID_URGENCIAS NO No aplica

[93]

III. MUESTRA ARCHIVOS RIPS

MUESTRA ARCHIVO: HOSPITALIZACIONES2006.TXT

'COD_EAPB','COD_IPS','FACTURA','TIPO_IDENTI','VIA_INGRESO','FECHA_INGRESO','HORA_INGRESO','CAUSA_EXTERNA','DIAG_PRIN_INGRE','DIAG_PRIN_EGRE','DIAG_EGRE1','DIAG_EGRE2','DIAG_EGRE3','DIAG_COMPLI','ESTADO_SALIDA','DIAG_MUERTE','FECHA_EGRE','HORA_EGRE','nro_radicacion','cod_dpto','cod_mpio','sexo','edad','tipo_usuario','consecutivo'

'EPS016','1300100024','25179','RC','1',2006-07-11 00:00:00,'06:42','13','J069','J069','','','','','1','',2006-07-13 00:00:00,'15:44',5145,'13','001','M',3,'1','248'

'EPS016','4400100214','00114231','NU','1',2006-01-09 00:00:00,'01:59','13','J459','J459','','','','','1','',2006-01-09 00:00:00,'07:06',4173,'08','001','M',4,'1','1186'

MUESTRA ARCHIVO: PROCEDIMIENTOS2006.TXT

'COD_EAPB','COD_IPS','FACTURA','TIPO_IDENTI','FECHA','COD_PROCI','AMBITO','FINALIDAD','PERSONAL','DIAG_PRIN','DIAG_R1','COMPLICACION','VALOR','nro_radicacion','cod_dpto','cod_mpio','sexo','edad','tipo_usuario','consecutivo'

'EPS016','2355500463','601','CC',5/13/2006 0:00,'907002','1','1','','','','',2980,5309,'23','555','M',19,'1','18021467'

'EPS016','2355500463','601','CC',5/26/2006 0:00,'907107','1','1','','','','',3785,5309,'23','555','M',19,'1','18021467'

MUESTRA ARCHIVO: MEDICAMENTOS2006.TXT

COD_EAPB,COD_IPS,FACTURA,TIPO_IDENTI,consecutivo,EDAD,UNIDAD_MEDIDA,NOMBRE_MEDI,TIPO_MEDI,FORMA_FARM,CONCENTRACION,UNIDAD_MEDICA,UNIDADES,VAL_UNITARIO,VAL_TOTAL,nro_radicacion,fecha,cod_dpto,cod_mpio,sexo,edad1,tipo_usuario,ambito,diag_prin,diag_r1

13-7,1100108679,1513223,CC,3288848,36,1,TOXOIDE TETANICO,1,70,1,AMPOLLA,1,9424,9424,4333,7/19/2006 0:00,11,1,M,36,5,,,

13-7,1100108679,1513223,CC,3288848,36,1,NAPROXENO TAB O CAP X 250 MG,1,14,1,TABLETA O CAPSULA,6,123,738,4333,7/19/2006 0:00,11,1,M,36,5,,,

[94]

IV. MUESTRA ARCHIVO WEKA

@relation hospitalization @attribute age {ninno,adulto,adulto_mayor,anciano} @attribute sex {F,M} @attribute primary_involved_system {sistema_cardiaco_comprometido,sistema_renal_comprometido,sistema_respiratorio_comprometido, sistema_hepatico_comprometido,sistema_gastrointestinal_comprometido,sistema_neurologico_comprometido,sistema_hematologico_comprometido,sistema_genito_urinario,NINGUNO} @attribute secondary_involved_system {sistema_cardiaco_comprometido,sistema_renal_comprometido,sistema_respiratorio_comprometido, sistema_hepatico_comprometido,sistema_gastrointestinal_comprometido,sistema_neurologico_comprometido,sistema_hematologico_comprometido,sistema_genito_urinario,NINGUNO} @attribute cause {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15} @attribute ANTICOAGULANTES {NO,YES} @attribute BETABLOQUEADORES {NO,YES} @attribute GLUCOCORTICOIDES {NO,YES} @attribute ANTIDEPRESIVOS {NO,YES} @attribute DIURÉTICOS {NO,YES} @attribute Ninguna {NO,YES} @attribute ANTIBIÓTICOS {NO,YES} @attribute ÁCIDOPÉPTICA {NO,YES} @attribute ANTIAGREGANTES_PLAQUETARIOS {NO,YES} @attribute ANSIOLITICOS {NO,YES} @attribute INMUNOSUPRESORAS {NO,YES} @attribute ANTISICOTICOS {NO,YES} @attribute HIPRIOTICOS {NO,YES} @attribute OPIOIDES {NO,YES} @attribute INSULINA {NO,YES} @attribute ANTICONVULSIONANTES {NO,YES} @attribute Deteccion_Temprana_Enfermedad_Profesional {NO,YES} @attribute Diagnostico {NO,YES} @attribute Terapeutico {NO,YES} @attribute Proteccion_Especifica {NO,YES} @attribute Ninguna {NO,YES} @attribute Deteccion_Temprana_Enfermedad_General {NO,YES} @data adulto,F,sistema_hematologico_comprometido,NINGUNO,15,NO,NO,NO,NO,NO,YES,NO,NO,NO,NO,NO,NO,NO,NO,NO,NO,NO,YES,NO,NO,NO,NO adulto,F,sistema_genito_urinario,sistema_genito_urinario,13,NO,NO,NO,NO,NO,YES,NO,NO,NO,NO,NO,NO,NO,NO,NO,NO,YES,YES,YES,NO,NO,NO

[95]

V. MODELOS OBTENIDOS

MODELOS K - MEANS

S=5, N=2

Cluster 1 2


Sexo F M


Sistema Secundario Comprometido Ninguno Cardíaco




Tamaño 76 24

S=5, N=3

Cluster 1 2 3

Rango Edad Adulto Niño Adulto

Sexo F M M

Sistema Primario Comprometido Cardíaco Cardíaco Cardíaco

Sistema Secundario Comprometido Ninguno Cardíaco Cardíaco




Tamaño 64 21 16

S=5, N=4

Cluster 1 2 3 4

Rango Edad Adulto Niño Adulto Adulto

Sexo F M M F


Hematológico Cardíaco Cardíaco Cardíaco


Ninguno Cardíaco Ninguno Cardíaco




Enfermedad General


Función Medicamento No Reportada No Reportada No Reportada No Reportada

Tamaño 40 15 24 22

[96]

S=5, N=5

Cluster 1 2 3 4 5

Rango Edad Adulto Niño Adulto Adulto Adulto

Sexo F M M F F


Hematológico Cardíaco Cardíaco Cardíaco Hematológico


Ninguno Cardíaco Ninguno Cardíaco Ninguno





Enfermedad General

Enfermedad General

Enfermedad General

Otra

Función Medicamento No Reportada No Reportada No Reportada No Reportada No Reportada

Tamaño 37 15 23 21 5

S=10, N=2

Cluster 1 2


Sexo F F






Tamaño 76 24

S=10, N=3

Cluster 1 2 3


Sexo F F M

Sistema Primario Comprometido Hematológico Gastrointestinal Cardíaco





Tamaño 62 15 23

S=10, N=4

Cluster 1 2 3 4

Rango Edad Adulto Adulto Adulto Adulto

Sexo F F M F

[97]


Cardíaco Gastrointestinal Cardíaco Hematológico


Ninguno Ninguno Ninguno Cardíaco

Finalidad Procedimiento Diagnóstico Terapéutico





Enfermedad General

Enfermedad General

Enfermedad General


Tamaño 49 14 30 8

S=10, N=5

Cluster 1 2 3 4 5

Rango Edad Adulto Adulto Adulto Adulto Adulto

Sexo F F M F F


Cardíaco Gastrointestinal Cardíaco Hematológico Hematológico


Ninguno Ninguno Ninguno Cardíaco Ninguno




Diagnóstico Terapéutico Detección Enfermedad Profesional

Diagnóstico


Enfermedad General

Enfermedad General

Enfermedad General

Otra


Tamaño 36 14 29 7 14

S=15, N=2

Cluster 1 2

Rango Edad Adulto Niño

Sexo F F

Sistema Primario Comprometido Cardíaco Hematológico





Tamaño 76 24

S=15, N=3

Cluster 1 2 3


Sexo F F F

Sistema Primario Comprometido Cardíaco Hematológico Gastrointestinal

[98]


Finalidad Procedimiento Diagnóstico Terapéutico Diagnóstico Diagnóstico Terapéutico



Tamaño 64 24 13

S=15, N=4

Cluster 1 2 3 4

Rango Edad Adulto Niño Adulto Adulto

Sexo F F F F


Cardíaco Hematológico Gastrointestinal Cardíaco


Ninguno Ninguno Ninguno Ninguno


Diagnóstico Diagnóstico Terapéutico

Diagnóstico




Tamaño 49 14 30 8

S=15, N=5

Cluster 1 2 3 4 5

Rango Edad Adulto Niño Adulto Adulto Niño

Sexo F F F F F


Cardíaco Hematológico Hematológico Cardíaco Gastrointestinal


Ninguno Ninguno Ninguno Ninguno Ninguno





Enfermedad General

Enfermedad General

Enfermedad General

Enfermedad General


Tamaño 40 24 13 14 8

FARTHEST FIRST

S=5, N=2

Cluster 1 2


Sexo F M

Sistema Primario Comprometido Neurológico Gastrointestinal

Sistema Secundario Comprometido Ninguno Genitourinario

[99]



Función Medicamento No Reportada Glucocorticoides Ácido Péptica

Tamaño 99 1

S=5, N=3

Cluster 1 2 3

Rango Edad Adulto Adulto Mayor Anciano

Sexo F M M

Sistema Primario Comprometido Neurológico Gastrointestinal Cardíaco

Sistema Secundario Comprometido Ninguno Genitourinario Neurológico


Terapéutico




Tamaño 98 1 2

S=5, N=4

Cluster 1 2 3 4

Rango Edad Adulto Adulto Mayor Anciano Niño

Sexo F M M F


Neurológico Gastrointestinal Cardíaco Hematológico


Ninguno Genitourinario Neurológico Gastrointestinal

Finalidad Procedimiento Diagnóstico No Reportada Diagnóstico Terapéutico



Enfermedad General




Glucocorticoides Diuréticos Antibióticos Antiagregantes

Tamaño 97 0 1 1

S=5, N=5

Cluster 1 2 3 4 5

Rango Edad Adulto Adulto Mayor Anciano Niño Adulto

Sexo F M M F F


Neurológico

Gastrointestinal Cardíaco Hematológico Cardíaco

Sistema Secundario

Ninguno Genitourinario Neurológico Gastrointestinal Cardíaco

[100]

Comprometido


Diagnóstico Terapéutico Diagnóstico Terapéutico




Enfermedad General

Enfermedad General

Enfermedad General

Enfermedad General Otra


No Reportada

Glucocorticoides Ácido Péptica Ansiolíticos

Anticoagulante Glucocorticoides Opioides Diuréticos

Glucocorticoides Opioides Diuréticos Anticonvulsionantes

Anticoagulantes Betabloqueadores Diuréticos

Tamaño 97 0 1 1 1

S=10, N=2

Cluster 1 2

Rango Edad Adulto Adulto Mayor

Sexo F M

Sistema Primario Comprometido Cardíaco Gastrointestinal

Sistema Secundario Comprometido Cardíaco Genitourinario


No Reportada

Causa Hospitalización Enfermedad General Otra


Tamaño 99 1

S=10, N=3

Cluster 1 2 3

Rango Edad Adulto Adulto Mayor Niño

Sexo F F M


Hematológico Gastrointestinal Gastrointestinal


Ninguno Ninguno Ninguno









Glucocorticoides Antidepresivos Diuréticos

Tamaño

S=10, N=4

Cluster 1 2 3 4

Rango Edad Adulto Adulto Mayor Niño Niño

[101]

Sexo F M F M


Cardíaco Gastrointestinal Gastrointestinal Cardíaco


Cardíaco Genitourinario Ninguno Ninguno



No Reportada Diagnóstico Diagnóstico Terapéutico


Otra Enfermedad General Otra Lesión Autoinflingida


No Reportada No Reportada No Reportada Antibióticos Ácido Péptica Antiagragantes Ansiolíticos

Tamaño 97 1 1 1

S=10, N=5

Cluster 1 2 3 4 5

Rango Edad Adulto Adulto Mayor Niño Niño Anciano

Sexo F M F M F


Cardíaco Gastrointestinal Gastrointestinal Cardíaco Cardíaco


Cardíaco Genitourinario Ninguno Ninguno Cardíaco



No Reportada Diagnóstico Diagnóstico Terapéutico



Otra Enfermedad General Otra Lesión Autoinflingida

Enfermedad General


No Reportada

No Reportada

No Reportada No Reportada

No Reportada

Tamaño 97 0 1 1 1

S=15, N=2

Cluster 1 2

Rango Edad Adulto Adulto Mayor

Sexo F M

Sistema Primario Comprometido Hematológico Gastrointestinal

Sistema Secundario Comprometido Ninguno Genitourinario

Finalidad Procedimiento Diagnóstico No Reportada

Causa Hospitalización Otra Enfermedad General


Tamaño 99 1

[102]

S=15, N=3

Cluster 1 2 3

Rango Edad Adulto Adulto Mayor Adulto

Sexo F M F


Hematológico Gastrointestinal Genitourinario


Ninguno Genitourinario Cardíaco


Diagnóstico No Reportada Diagnóstico Terapéutico


Otra Enfermedad General Enfermedad General



Anticoagulante Glucocorticoides Diuréticos Antibióticos

Tamaño 98 1 1

S=15, N=4

Cluster 1 2 3 4

Rango Edad Adulto Adulto Mayor Adulto Niño

Sexo F M F M


Hematológico Gastrointestinal Genitourinario Cardíaco


Ninguno Genitourinario Cardíaco Ninguno







Lesión Autoinflingida



Anticoagulantes Glucocorticoides Ácido Péptica Ansiolíticos

Glucocorticoides Antibióticos Antiagregantes

Tamaño 97 0 1 1

extracciÓn de metadata extensional a partir de tÉcnicas de

Documents