SISTEMA DE ANÁLISIS DE DATOS MÉDICOS SEGÚN …deim.urv.cat/~pfc/docs/pfc339/d1117431499.pdf ·...

PROYECTO FINAL DE CARRERA

SISTEMA DE ANÁLISIS DE DATOS MÉDICOS SEGÚN ITINERARIOS Y EVOLUCIONES

Alumno: RAUL MATEOS FERRÉ

Director:

DAVID RIAÑO

Ingeniería Técnica en Informática de Gestión


1

INDICE DE CONTENIDOS Capítulo 1. INTRODUCCIÓN.................................................................................. 3

1.1 Descripción del Proyecto .............................................................................. 3 1.2 El contexto del trabajo: El Sistema PalliaSys.............................................. 5

1.2.1 Descripción general ............................................................................... 5 1.2.2 Funcionamiento: PalliaSys. .................................................................. 7

1.3 Objetivos. ........................................................................................................ 8 1.4 Organización del documento....................................................................... 9

Capítulo 2. ANTECEDENTES................................................................................ 10

2.1 Un hospital ................................................................................................... 10 2.1.1 La UCP .................................................................................................. 11 2.1.2 El paciente paliativo ............................................................................ 12 2.1.3 El medico paliativo .............................................................................. 12 2.1.4 Servicios de la UCP ............................................................................. 12

2.2 Circuito de Pacientes paliativos................................................................. 15 2.3 Evolución de un paciente ........................................................................... 17

2.3.1 Clasificación no supervisada: K-Means............................................. 17 2.3.2 Pseudocódigo del Algoritmo K-Means ............................................. 17

2.4 Estructuras de Decisión .............................................................................. 18 2.4.1 Minería de Datos.................................................................................. 18 2.4.2 Aprendizaje Automático .................................................................... 18 2.4.3 Algoritmos de inducción .................................................................... 19 2.4.4 Reglas de producción .......................................................................... 24 2.4.5 Tablas de Decisión ............................................................................... 24

Capítulo 3. SISTEMA DE AYUDA A LA TOMA DE DECISIÓN. .................... 27

3.1 Descripción del sistema .............................................................................. 27 3.1.1 Funcionalidad y uso ............................................................................ 28

3.2 Aspectos de la implementación................................................................. 31 3.2.1 Fase 1: Recogida de datos. .................................................................. 31 3.2.2 Fase 2: Circuito de pacientes y Cambio de estado. ......................... 32 3.2.3 Fase 3: Estructuras de decisión. ......................................................... 34 3.2.4 Fase 4: Previsión de evoluciones de nuevos pacientes................... 38

3.3 Interficie de usuario..................................................................................... 39 3.3.1 Introducción ......................................................................................... 39 3.3.2 Pantalla principal................................................................................. 39 3.3.3 Pantalla Nuevo Proyecto. ................................................................... 40 3.3.4 Pantalla de circuitos de Pacientes y Estadios. ................................. 43 3.3.5 Pantalla árbol de decisión................................................................... 45 3.3.6 Pantalla Reglas de Producción. ......................................................... 46 3.3.7 Pantalla Tabla de Decisión. ................................................................ 46 3.3.8 Pantalla de Nuevo Paciente................................................................ 48 3.3.9 Pantalla Guardar Proyecto. ................................................................ 49 3.3.10 Pantalla Abrir Proyecto....................................................................... 51


2

Capítulo 4. PRUEBAS REALIZADAS................................................................... 52 4.1 Descripción de las pruebas......................................................................... 52 4.2 Datos Obtenidos. ......................................................................................... 53

4.2.1 Circuito de Pacientes. .......................................................................... 53 4.2.2 Árbol de decisión. ................................................................................ 53 4.2.3 Reglas de Producción .......................................................................... 55 4.2.4 Tablas de decisión................................................................................ 56 4.2.5 Nuevo Paciente: Previsión.................................................................. 56

4.3 Análisis de resultados. ................................................................................ 56 4.3.1 Circuito de Pacientes. .......................................................................... 57 4.3.2 Árbol, Reglas y Tablas de Decisión...................................................58

4.4 Conclusión de las pruebas.......................................................................... 60 Capítulo 5. CONCLUSIÓN DEL PROYECTO..................................................... 61

5.1 Resumen del trabajo. ................................................................................... 61 5.2 Alcance de los objetivos marcados............................................................ 62

5.2.1 Conclusiones obtenidas. ..................................................................... 63 5.3 Trabajo futuro............................................................................................... 64

Capítulo 6. ANEXOS ............................................................................................... 65

6.1 Anexo 1: Datos de Pacientes. .................................................................... 65 6.2 Anexo 2: Algoritmo de generación aleatoria de datos ........................... 67

Capítulo 7. BIBLIOGRAFÍA ................................................................................... 68


3

Capítulo 1. INTRODUCCIÓN

1.1 Descripción del Proyecto

El presente trabajo se engloba dentro del proyecto PalliaSys, en el que se diseña e implementa un sistema informático que ayude a gestionar la información de los pacientes de la Unidad de Curas Paliativas (UCP) del Hospital de la Santa Creu i Sant Pau (Barcelona).

Figura 1. Arquitectura Multi-Agente del proyecto Palliasys.


4

La idea central de este proyecto reflejada en la figura 1, es la de desarrollar una herramienta que ayude a la toma de decisiones de los profesionales de un Hospital que interactúan en la Unidad de Curas Paliativas. Por ayuda a la toma de decisión se entiende la tarea de, en base a un conjunto de datos, extraer y presentar conocimiento implícito de tal forma que el profesional tenga una visión más amplia del problema a resolver. Los pacientes paliativos son enfermos en estado terminal atendidos por centros sanitarios con el fin de paliar el sufrimiento en la última etapa de su vida. El tratamiento de estos pacientes define un modelo altamente distribuido tanto por lo que atañe a los pacientes como a los profesionales médicos. Los pacientes pueden residir en casa, con o sin posibilidades de asistir a la consulta del especialista médico, estar ingresados en algún servicio hospitalario (oncología, unidad de curas intensivas, etc.) o en un centro sociosanitario (CSS), o residir en la unidad de curas paliativas (UCP) del hospital. Como complemento, los médicos y demás facultativos realizan labores de asistencia a domicilio o PADEs, visita a los pacientes hospitalizados y consulta en el despacho. Las bases de datos de una UCP incorporan información sobre las evoluciones de los pacientes a lo largo de los tránsitos entre deferentes emplazamientos. Cada uno de los pasos de un episodio de tratamiento contiene información básica sobre el lugar en que se encuentra el paciente (inmovilizado en domicilio, en domicilio con movilidad, en CSS, en un servicio hospitalario, en la UCP, etc.), la duración de la estancia (nº de días), la medicación que se le ha suministrado en ese periodo (fármacos y dosis), las pruebas y procedimientos recibidos por el paciente y el estado de salud medio durante la estancia. El tratamiento de un paciente desde el momento en que entra en contacto con la UCP y el momento final, está representado por un episodio asistencial que es, una secuencia de bloques de datos conteniendo información del tipo que se ha comentado en el párrafo anterior. Con este tipo de información, acumulada para todos los pacientes en un intervalo temporal significativo, se propone realizar los siguientes estudios, empleando técnicas de análisis inteligente de datos: � Detección de patrones de circuitos seguidos por los pacientes.

� Aplicación de métodos clasificatorios no supervisados para la detección de estados de paciente, si éstos son desconocidos.

� Construcción de la estructura de estados (no supervisados) de los pacientes para mostrar los cambios de estado.

� Algoritmos de construcción de estructuras de decisión (árboles, reglas, tablas) sobre la movilidad de los pacientes con el fin de prever el circuito que seguirá un nuevo paciente dentro de la estructura de la que forma parte la Unidad de Curas Paliativas.


5

� Algoritmos de construcción de estructuras de decisión sobre la evolución de los pacientes, a partir de los estados en que se clasifican los pacientes ya tratados. Estas estructura será empleada para la previsión de evoluciones de nuevos pacientes.

1.2 El contexto del trabajo: El Sistema PalliaSys

1.2.1 Descripción general

El sistema informático PalliaSys es un sistema en red orientado a la e-asistencia de los pacientes de una Unidad de Cuidados Paliativos (UCP). PalliaSys permite el acceso desde cualquier lugar y en cualquier momento a un registro electrónico de los pacientes paliativos almacenado de forma centralizada, bajo el control de la UCP responsable de esos pacientes. Mediante dispositivos electrónicos de distinto tipo (teléfonos móviles, agendas electrónicas, ordenadores portátiles, PCs) se puede acceder a una serie de servicios orientados a mejorar la calidad del tratamiento de estos pacientes. Esto es especialmente interesante en este tipo de asistencia puesto que las actividades que se llevan a cabo para atender a los enfermos paliativos se realizan en distintos lugares y por distinto personal. Una UCP está a cargo de la atención tanto de los pacientes paliativos que están ingresados (hospitalizaciones, sea en la propia UCP, en otras unidades del hospital, o en un centro sociosanitario), como de los pacientes paliativos que, o están en su casa sin poderse desplazar (visitados por el personal PADES), o bien realizan visitas periódicas a los especialistas de la UCP (consulta externa). Así pues, un paciente puede ser tratado por el personal de la UCP, por médicos de otros centros, por PADES, o incluso puede requerir la ayuda de la familia, amigos o de un cuidador personal. Por tanto, el seguimiento de un paciente puede llegar a ser multiservicio , multicentro y multipersona. Se puede apreciar, pues, el carácter multidisciplinario y distribuido de la asistencia de pacientes paliativos. Esto describe un entorno propicio para el uso de un sistema informático, basado en la historia clínica electrónica de los pacientes, que facilite a cada tipo de usuario el acceso a los datos de los pacientes que necesite, y proporcione herramientas que puedan ayudar a llevar a cabo las funciones de apoyo al personal y que permitan diseñar una estrategia terapéutica conjunta a seguir entre la UCP, otros servicios hospitalarios involucrados (Oncología, Radiología, etc.), los centros sociosanitarios, los PADES y los equipos de atención primaria correspondientes. Para ello proponemos el uso de diversas tecnologías desarrolladas dentro del campo de la Inteligencia Artificial: concretamente, se está desarrollando un sistema multi-agente que incorpora herramientas de análisis inteligente de datos . Un agente se podría definir como un programa que aplica técnicas de Inteligencia Artificial para escoger en cada momento las acciones más adecuadas a realizar para llegar a conseguir unos objetivos asignados por un


6

usuario. Debería reaccionar de forma flexible, proactiva, dinámica, autónoma e inteligente a los cambios que se producen de forma continua en su entorno de actuación. Un sistema multi-agente es un conjunto de agentes autónomos que se comunican entre ellos para coordinar sus actividades y así ser capaces de resolver de forma colectiva un problema complejo que no podría resolver ninguno de los agentes de forma individual. Los sistemas de análisis inteligente de datos pueden ser empleados para la explotación de los datos del registro electrónico de pacientes y para extraer modelos de comportamiento que definan perfiles de usuario explícitos que puedan ser analizados por los médicos con fines asistenciales, organizativos, económicos o de control de la calidad. Estos modelos también pueden emplearse en la predicción de circuitos de pacientes nuevos y permiten anticipar la toma de decisiones de los jefes de servicio. En el caso de PalliaSys, uno de los agentes del sistema (Véase figura 1), el Data Analyser, estará especializado en técnicas de minería de datos, descubrimiento de conocimiento y algoritmos de aprendizaje automático, y utilizará toda esta capacidad procedural para analizar la información clínica de los pacientes paliativos y ayudar a los directivos de la UCP en la toma de decisiones. Este agente puede definir modelos de diferentes tipos de pacientes, empleando técnicas de aprendizaje automático no supervisado. Puede también analizar la evolución clínica de los pacientes y los flujos de pacientes entre diversas localizaciones, creando modelos de estas evoluciones que permitan realizar predicciones sobre los estados futuros de los pacientes (p.e. podría anticipar que el estado de un paciente empeorará mucho en breves semanas, y recomendar la adopción de mesuras preventivas). Estos modelos se crean utilizando técnicas de aprendizaje automático inductivo. Las funcionalidades ofrecidas por este agente sólo podrán ser utilizadas por la persona responsable de la UCP. Flujo de los pacientes paliativos dentro del hospital La transición de los pacientes paliativos entre sus posibles localizaciones (UCP, otros servicios del hospital, centros sociosanitarios u hospitalización domiciliaria) es un tema importante para el responsable de la UCP, ya que se pueden tomar muchas decisiones organizativas como resultado del análisis de tales transiciones. Análisis de la evolución clínica de los pacientes Un estadío indica el grado de evolución de la enfermedad de un paciente paliativo. Básicamente en este trabajo se definen seis estadíos diferentes, aunque el número posible de estadios de un paciente dependerá del campo médico en que se encuentre, de la voluntad del propio facultativo y de la patología del paciente. Dado que la mayoría de pacientes paliativos provienen del ámbito de la oncología y en esta se definen los estadíos 0, 1, 2, 3 y 4, nuestra decisión ha sido fijar seis estados posibles: los anteriores y el estadío de éxitus.


7

pero todos ellos se pueden refinar en estados más específicos según las peculiaridades de cada paciente concreto. El análisis de los registros clínicos de los pacientes permite la propuesta detección automática de tales estados si estos no han sido definidos de antemano y la construcción de diagramas de flujo de la evolución de los pacientes.

1.2.2 Funcionamiento: PalliaSys.

La descripción del funcionamiento general de la asistencia médica en el sistema PalliaSys es la siguiente: � INGRESO: Cuando ingresa el paciente en el programa de curas paliativas

por primera vez, se rellena la ficha de registro con sus datos personales, datos familiares, estado de salud de la primera visita, diagnósticos, y episodio. A partir de aquí, y hasta que el paciente fallece, se van realizando evaluaciones periódicas en cada una de las sucesivas visitas. Estas evaluaciones se llevan a cabo tanto si el paciente se visita en la consulta médica como si el médico va a visitarle a domicilio o si el paciente está ingresado en algún pabellón del hospital.

� TRATAMIENTO: En cada visita, el paciente (o la persona que se ocupa de su cuidado) debe rellenar una ficha de auto-evaluación. Posteriormente, el médico, según sus observaciones y las pruebas realizadas, rellena un formulario evaluando los mismos factores de manera objetiva. Además, introduce una serie de datos útiles consistentes básicamente en la medicación y ordenes para realizar pruebas y análisis.

� ALTA: Cuando el paciente fallece (exitus) se realiza la evaluación final.

La figura 2 muestra de manera esquemática un episodio clínico de un paciente de la UCP, destacándose la entrada de datos en el ingreso, durante el tratamiento y al alta. Durante el tratamiento puede observarse puntualmente cada visita de manera independiente.

INGRESO ALTA

TRATAMIENTO

EPISODIO

Figura 2. Episodio de un paciente


8

1.3 Objetivos.

Los objetivos que se presentan en este trabajo pretenden alcanzar la resolución de los problemas planteados. Pero hay que tener en cuenta que son los profesionales médicos quienes plantean estos problemas, y la tarea del presente trabajo es dar una solución técnica. Por tanto, hay una motivación externa a la hora de formular los problemas que se pretenden solucionar. Los objetivos tiene la siguiente división: Detección de estados del paciente Este objetivo plantea la detección del estado de los paciente mediante métodos de clasificación no supervisados. La clasificación se hará en base a unos atributos del paciente previamente seleccionados por un experto. Todos los atributos se obtendrán de la fuente de datos descrita en la sección 2.1.4.1. Esta fuente aparece con el nombre PCU Database en la figura 1, donde el agente DB Wrapper actúa como intermediario entre la Base de Datos física y el agente Data Analyser que se desarrolla en este trabajo. Patrones de circuitos y Cambios de estado En este apartado se modela el circuito estándar de los pacientes a medida que cambian de ubicación durante el tratamiento. De esta manera se obtiene una representación de la conducta general del hospital con respecto a la unidad de curas paliativas. También se modela la evolución de los pacientes atendiendo a su estado de salud, obteniéndose al igual que antes una representación de la conducta general del hospital frente a un estado de un paciente en concreto. Creación de Estructuras de decisión Este objetivo prevé la incorporación de algoritmos creación de estructuras de decisión: Árboles, reglas y tablas; partiendo de los datos que se desprenden de la consecución de los objetivos anteriormente mencionados. Creación de una Base del Conocimiento y predicción de nuevos pacientes Una vez obtenidos las estructuras de decisión estaremos en disposición de crear una Base del Conocimiento (BC). Esta BC recogerá todos los datos imprescindibles para la ayuda a la toma de decisión, dispuestos de forma tal que permita realizar consultas sobre futuras evoluciones de pacientes (cambios de ubicación o cambios en su estado).


9

Análisis de resultados con datos reales Una vez creada la aplicación que implemente la solución a los problemas propuestos en el apartado 1.1, se iniciará un análisis detallado de los resultados con datos reales extraídos de la Base de Datos Hospitalarios del Hospital de la Santa Creu i Sant Pau (Barcelona).

1.4 Organización del documento

En el capítulo 2 se describen los antecedentes tenidos en cuenta para la realización del presente trabajo. Se pasará revista a conceptos clave como son: Hospital, paciente o doctor paliativo, intentando situar al lector en el campo de las curas paliativas. En este capítulo también se presentará la fuente de datos con la cual se ha efectuado el estudio, así como técnicas de clasificación automática de estado de un paciente (Algoritmo K-Means) y de toma de decisión que se han utilizado (Árboles, Reglas y Tablas de Decisión), dando una visión teórica de todas estos métodos. En el capítulo 3 se presenta una solución al problema planteado en la sección 1.1 detallando el sistema creado y describiendo su funcionamiento, uso e implementación. En el capítulo 4 se analizan los resultados obtenidos de las pruebas realizadas, mostrando gráficos de modelado, árboles de decisión, reglas de aprendizaje y tablas de decisión generados. En el capítulo 5 se detallan los objetivos conseguidos y las conclusiones más relevantes a las que se ha llegado. Se presenta una comparativa entre los objetivos propuestos y los realmente alcanzados, y finalmente, se detalla una perspectiva de futuro. En el capítulo 6 se incluyen los anexos que describen diferentes términos que aparecen en el documento.


10

Capítulo 2. ANTECEDENTES

2.1 Un hospital

Un hospital es una empresa de servicios cuya principal función es el cuidado de los pacientes, ya sea obteniendo su cura absoluta o una mejora de su calidad de vida. La función del médico es determinar cuáles son los cuidados adecuados a cada paciente de acuerdo a sus necesidades. Todos los médicos están asociados a uno o varios servicios o departamentos del hospital dependiendo de su especialización. Todos los pacientes tratados en un hospital se encuentran identificados por un número de historia que se mantiene de forma permanente en el sistema informático, aun después de la defunción de la persona a la que identifican. A este número de historia se le asocia un historial médico que se divide en diferentes secciones: los datos personales y familiares del paciente paliativo, los episodios y diagnósticos, el estado de salud y la evaluación final (en caso de muerte del paciente). También han de estar disponibles todas las evaluaciones que se han realizado al paciente, ya sean resultado de una visita presencial (en domicilio, consulta o pabellón) o bien a través del mecanismo de autoevaluación del paciente, si éste es el caso. El acceso de un paciente al hospital, puede realizarse por diferentes entradas: � Hospitalización en la Unidad de Cuidados Paliativos (UCP). Véase 2.1.1

� Hospitalización en otras unidades del hospital.

� La hospitalización en un Centro SocioSanitario (CSS): Centros de institucionalización que pueden tener diversas unidades de hospitalización y atención diurna. Pueden ser de diversos tipos:

• Larga estancia: Destinados a la atención continuada de personas con enfermedades o procesos crónicos y diferentes niveles de dependencia con diversos grados de complejidad clínica y que no pueden atendidos en su domicilio.

• Estancia media – convalecencia. Destinados a personas con enfermedades que se encuentran en fase de recuperación de un proceso agudo y con pérdida de autonomía potencialmente recuperable, o que necesitan la


11

continuación de un tratamiento o supervisión clínica continuada y que, a causa de su complejidad, requieren unas curas intensivas.

• Estancia media – curas paliativas. Destinados a enfermos en situación de enfermedad avanzada o terminal que necesitan control de los síntomas o tratamientos continuados en régimen de hospitalización. La patología predominante es la oncológica.

• Estancia media – polivalente. Destinados a la atención de convalecencia y curas paliativas en unidades que, por su dimensión y criterios de planificación, no pueden realizar estas actividades de una manera específica.

• Hospital de día. Asistencia predominantemente a personas mayores enfermas, enfermos crónicos que requieren medidas integrales de apoyo, rehabilitación, tratamiento o diagnóstico, y seguimiento especializado en régimen diurno ambulatorio. Los objetivos de los servicios de atención de día son la evaluación integral, la rehabilitación y la atención continuada de mantenimiento.

A la hora de formalizar un ingreso del paciente, se determina la unidad o centro al que se le destina y el diagnóstico de entradas. Posteriormente se van realizando evaluaciones periódicas en cada una de las sucesivas visitas.

2.1.1 La UCP

La Unidad de Cuidados Paliativos (UCP) de un hospital atiende a los pacientes que se encuentran en fase terminal, con la finalidad de aliviar, en la medida de lo posible, el dolor y sufrimiento de estos pacientes en la última etapa de su vida. Los pacientes atendidos, así como los facultativos involucrados en el proceso, tienen unas necesidades de manejo de información que han de ser satisfechas dentro de un entorno distribuido. Una UCP está a cargo de la atención tanto de los pacientes paliativos que están ingresados (hospitalizaciones, sea en la propia UCP, en otras unidades del hospital, o en un centro sociosanitario), como de los pacientes paliativos que, o están en su casa sin poderse desplazar (visitados por los PADES), o bien realizan visitas periódicas a los especialistas de la UCP (consulta externa). En la descripción general de una UCP se aprecia su carácter multidisciplinario y distribuido en que participan diversos interlocutores (doctores, enfermeros y diversos tipos de pacientes) con diversas actividades sanitarias (visitas a pabellón, a casa y a consulta). Esto describe un entorno propicio para el uso de un sistema informático basado en la historia clínica electrónica de los pacientes centralizada y accesible por las diversas plataformas suministradas por las nuevas tecnologías de la información y las comunicaciones.


12

2.1.2 El paciente paliativo

Persona que recibe cuidados paliativos. Puede residir en su domicilio o estar ingresado en el pabellón de la UCP del hospital, en otros pabellones del hospital o en un centro sociosanitario. El cuidado paliativo es un modelo interdisciplinario que se centra en la gestión completa de las necesidades físicas, psicológicas, sociales y espirituales de los pacientes con todo tipo de enfermedades progresivas e incurables, así como de sus familias.

2.1.3 El medico paliativo

Estos médicos realizan visitas en su consulta y pasan visita en los pabellones hospitalarios. En principio, no se distinguirán diferentes tipos de usuarios (médicos, enfermeras) del sistema en esta categoría.

2.1.4 Servicios de la UCP

Los servicios que se llevan a cabo para atender a los enfermos paliativos son básicamente las siguientes: la hospitalización en la UCP, en otras unidades del hospital o en un centro sociosanitario, la consulta externa, la visita a domicilio y la evaluación periódica del estado de los pacientes que son responsabilidad de la UCP. La hospitalización en la UCP se basa en gestionar las camas disponibles de la UCP para alojar temporalmente los casos más complejos de pacientes paliativos hasta el momento en que o bien fallecen o bien se estabilizan y son dados de alta y trasladados a sus domicilios o a un centro sociosanitario. La hospitalización en otras unidades del hospital es práctica habitual cuando el número de camas disponibles en la UCP no es muy elevado. Esta limitación provoca que un paciente paliativo pueda estar hospitalizado en otras unidades del hospital, dependiendo de su enfermedad (p.e. un enfermo de cáncer podría estar en la unidad de Oncología, o un paciente con una insuficiencia cardiaca terminal en Cardiología). Por tanto, el seguimiento de un paciente puede llegar a ser multiservicio. En estos casos el equipo de cuidados paliativos realiza interconsultas con los profesionales responsables de las distintas unidades del hospital. La hospitalización en un centro sociosanitario (CSS) se lleva a cabo con los pacientes paliativos que precisan estar hospitalizados por un periodo de tiempo prolongado. En este caso, el seguimiento de un paciente es multicentro y el equipo de cuidados paliativos requerirá la localización del paciente en diferentes centros sanitarios.


13

La consulta externa se ocupa de la evaluación y orientación terapéutica de los enfermos y sus familiares y el seguimiento de los pacientes que no precisan hospitalización o que son dados de alta desde la UCP. Estas consultas las realizan los médicos de la UCP en la propia unidad. Ante dificultades de desplazamiento, o cuando se requiere un control intensivo, los equipos PADES (Personal de Atención Domiciliaria – Equipos de Soporte) se ocupan, junto con los Equipos de Atención Primaria, de la atención en el domicilio. En este caso, el seguimiento de un paciente por parte del equipo paliativo se hace completamente distribuido en el área de influencia urbana o rural de la UCP. Por último, se puede destacar que en la evaluación periódica del estado de los pacientes es el propio paciente el que rellena un cuestionario de auto-evaluación de su estado cada vez que se le realiza una visita médica (en el hospital o en su domicilio). Este cuestionario es también revisado por el médico durante la visita.

2.1.4.1 Base de Datos Hospitalarios

El sistema PalliaSys dispone de una base de datos centralizada, situada en la UCP del hospital, donde se almacenan el histórico de los datos relevantes de los pacientes paliativos. El contenido de la base de datos incluye información sobre pacientes, asistencia, personal médico y ubicación.

Figura 3. PCU Database.


14

A continuación se describen los tipos de datos que podemos encontrar dentro de la Base de Datos: � Datos de los pacientes:

• Datos personales, como el nombre, dirección, teléfono, etc. • Datos familiares, como el número de hijos, la situación familiar, trabajo,

etc.

� Datos de la asistencia clínica prestada en cada posible ubicación (UCP, CSS o domicilio).

• Estado de salud en la primera visita del paciente. Incluye la capacidad funcional (alimentación, higiene, movilidad, etc.), problemas de salud (molestias y preocupaciones) y dolor principal (localización, tratamiento previo, etc.).

• Datos diagnósticos, que corresponden a la enfermedad que padece el paciente. Se distingue entre el diagnóstico principal único y los diagnósticos secundarios múltiples.

• Datos históricos de las auto-evaluaciones periódicas, como los grados de dolor, debilidad, depresión, ansiedad, náuseas, somnolencia, apetito, bienestar, dificultad respiratoria o sequedad bucal. Hay otros datos que miden la presencia o no de estreñimiento o insomnio, así como un dato general para expresar otras dolencias.

• Datos de los episodios que reflejan los datos del tratamiento en cada visita.

• Criterios de complejidad que recogen características de complejidad de las actuaciones paliativas dependientes del paciente (p.e. personalidad adictiva, dolor neuropático severo), de la familia (p.e. gran impacto emocional) o de los profesionales (p.e. obstinación terapéutica).

• Evaluación final, con los datos del fallecido (fecha, lugar, aceptación, sedación, etc.).

• Datos de las estrategias terapéuticas que se están siguiendo con los pacientes.

• Medicación recibida por el paciente a lo largo de los diferentes episodios. La medicación consiste en un conjunto de medicamentos para los que se indica el nombre, dosis (en mg), intervalo de la toma (en horas) y vía de administración.

• Tratamientos recibidos por el paciente a lo largo de los diferentes episodios.

� Datos del personal médico:

Se anotan los médicos responsables y teléfonos, tanto a nivel de atención primaria como de atención especializada.


15

� Datos de la ubicación:

Registran los cambios de ubicación del paciente, que debe quedar perfecta y unívocamente establecida. Se identifican cuatro situaciones posibles: 1) En domicilio: debe registrarse la dirección completa, así como el número

de teléfono. 2) En la UCP: se debe indicar el identificador de cama que ocupa. 3) En otro servicio del hospital: se debe indicar el servicio y el identificador

de la cama. 4) En el CSS: se indica el CSS, y opcionalmente su sección y el identificador

de la cama. Además, el sistema almacena también los datos necesarios para la gestión adecuada de los usuarios (claves y contraseñas de acceso, permisos asociados a cada tipo de usuario, etc.).

A lo largo de todas los episodios clínicos de todos los pacientes relacionados con la UCP (Ver figura 2), la información descrita anteriormente queda almacenada en la PCU Database (Ver figura 1) cuyo diseño se muestra en la figura 3.

2.1.4.2 Análisis de circuitos

En cada una de las evaluaciones de un paciente se estudia si es necesario realizar un cambio de ubicación del paciente o si sigue donde está. Las ubicaciones posibles son: en domicilio sin PADES, en domicilio pero con PADES, en un centro socio-sanitario asociado al hospital, en urgencias o en el hospital de día.

En caso de determinarse un cambio de ubicación del paciente, el médico indicará cuáles han sido los motivos del traslado (mal control de algún síntoma, bajo soporte familiar, petición expresa del paciente, etc.). De esta forma, el médico podrá saber para cada paciente en qué ubicaciones ha estado y cuáles han sido los motivos de los cambios. Así también se podrán realizar diferentes estudios de los que se podrán extraer resultados útiles para casos posteriores.

2.1.4.3 Análisis de la evolución de un paciente

En cada una de las evaluaciones de un paciente durante su episodio (registro clínico) puede darse el caso que su estado de salud cambie, debido a diferentes razones que sólo los profesionales médicos saben determinar. El análisis de los registros clínicos de los pacientes permite la detección automática de tales estados y la definición de diagramas de flujo de la evolución de los pacientes.

2.2 Circuito de Pacientes paliativos

Para representar la movilidad de los pacientes paliativos, tenemos a nuestra disposición una Base de Datos Hospitalarios que recoge los datos del transito


16

entre servicios de los pacientes con un información específica común (Véase figura 3). Durante el periodo de ingreso del paciente, hasta la fecha en que se le da de alta médica por exitus en el sistema, al paciente se le realizan una serie de evaluaciones periódicas que aportan información referente a su ubicación (en el momento de la evaluación, y de su posible cambio a otra ubicación). Este comportamiento viene esquematizado en la figura 2. La modelización de un circuito de pacientes paliativos pasa por la creación de una estructura de datos tal que permita representar la movilidad de estos pacientes. Para este cometido, la utilización de Grafos parece la opción más indicada. Un grafo es una colección de vértices llamados nodos, algunos de los cuales están unidos por flechas mediante arcos. Tradicionalmente se han utilizado los grafos para representar elementos relacionados entres sí. Distinguimos un solo tipo de nodo Servicio que representa el servicio hospitalario donde se ubican los pacientes paliativos. El nodo servicio recogerá el nombre de la unidad sanitaria que representa (p.e. Oncología, UCP, CSS, etc.). A su vez, los arcos representan el tránsito de los pacientes entre diferentes nodos Servicio. Formalmente, existen algunas características que definen particularidades sobre el tipo de grafo con el que se está trabajando: grafo conexo, grafo dirigido, grafo informado y grafo etiquetado. En un grafo conexo, todos los nodos están conectados directa o indirectamente entre sí, y por lo tanto no existe ningún nodo aislado del resto. En un grafo dirigido, los arcos tienen asociado un sentido representando la dirección de su relación (dos nodos mutuamente relacionados deberán representarse con dos arcos de diferentes sentidos). En un grafo etiquetado, los arcos almacena información concerniente al problema que se intenta resolver. La figura 4 muestra un ejemplo de este tipo de grafo.

A

F

B

C

E D

21

4

9

12

4

20 5

2

2

17 7

15

Figura 4. Grafo conexo, dirigido y etiquetado.


17

La estructura de datos básica utilizada en este trabajo es la de un grafo conexo, dirigido y etiquetado.

2.3 Evolución de un paciente

Paralelamente al circuito de pacientes descrito en la anterior sección, podemos describir la modelización de la evolución de un paciente. Esto se debe a que la metodología utilizada también incorpora el grafo como estructura de datos. En este caso distinguimos también un solo tipo de nodo Estadío, que representa el estado en que se pueden encontrar los pacientes paliativos. A su vez, los arcos representan el tránsito de los pacientes entre diferentes nodos Estadío y por tanto describen cambios de estado de pacientes o evoluciones. La peculiaridad que podemos observar en la construcción de este tipo de grafos es que la Base de Datos Hospitalarios no incluye información referente al estadío de los pacientes, y por tanto, se debe buscar la forma de obtenerla. En este trabajo se ha optado por la utilización de técnicas de clasificación no supervisada, en concreto el algoritmo K-means.

2.3.1 Clasificación no supervisada: K-Means

K-Means es un algoritmo de clasificación estadístico basado en clusters, no paramétrico y no supervisado cuyo cometido es el de crear una partición del espacio de patrones en K grupos (clusters) adyacentes. Su funcionamiento se basa en definir K puntos en el espacio de patrones, correspondientes a los centros de los K clusters que se desea crear. Luego se asigna cada patrón de entrenamiento presente en el espacio a cada grupo de acuerdo al centro que se encuentra a menor distancia del patrón. Una vez creados los grupos, se recalculan los centros originales de cada grupo en base al punto medio calculado para los patrones que pertenecen a cada uno de ellos respectivamente. Estas dos etapas se reiteran en un bucle que culmina cuando el sistema llega a un estado estable.

2.3.2 Pseudocódigo del Algoritmo K-Means

El algoritmo en cuestión es esquematizado por el pseudocódigo de la tabla 1. Al cabo de algunas iteraciones los centros se estabilizan y con ellos la partición del espacio formada por los K grupos definidos por estos centros.


18

Tabla 1. Algoritmo K-Means. El parámetro principal que configura a este algoritmo es K, definido por el usuario en cada caso. El valor óptimo de K es difícil de determinar y depende mucho del caso y de la real distribución de los patrones en el espacio.

2.4 Estructuras de Decisión

2.4.1 Minería de Datos

Se denomina Minería de Datos al conjunto de técnicas y herramientas aplicadas al proceso no trivial de extraer y presentar conocimiento implícito, previamente desconocido, potencialmente útil y humanamente comprensible, a partir de grandes conjuntos de datos, con objeto de predecir de forma automatizada tendencias y comportamientos; y describir de forma automatizada modelos previamente desconocidos. El término Minería de Datos Inteligente se refiere específicamente a la aplicación de métodos de aprendizaje automático, para descubrir y enumerar patrones presentes en los datos, para estos métodos, se desarrollaron un gran número de métodos de análisis de datos basados en la estadística. En la medida en que se incrementaba la cantidad de información almacenada en las bases de datos, estos métodos empezaron a enfrentarse a problemas de eficiencia y escalabilidad y es aquí donde aparece el concepto de minería de datos. Una de las diferencias entre al análisis de datos tradicional y la minería de datos es que el primero supone que las hipótesis ya están construidas y validadas contra los datos, mientras que el segundo supone que los patrones e hipótesis son automáticamente extraídos de los datos.

2.4.2 Aprendizaje Automático

El aprendizaje puede ser definido como "cualquier proceso a través del cual un sistema mejora su eficiencia". La habilidad de aprender es considerada como

Procedimiento K-Means Comienzo

Determinar K centros iniciales Repetir

Crear K grupos con los patrones más cercanos a cada centro Recalcular los K centros como los puntos medios de cada grupo creado

hasta (los K centros tengan una despreciable entre dos iteraciones).

Fin


19

una característica central de los "sistemas inteligentes", y es por esto que se ha invertido esfuerzo y dedicación en la investigación y el desarrollo de esta área. El desarrollo de los sistemas basados en conocimientos motivó la investigación en el área del aprendizaje con el fin de automatizar el proceso de adquisición de conocimientos el cual se considera uno de los problemas principales en la construcción de estos sistemas. Entre los múltiples modelos de aprendizaje automático, el aprendizaje inductivo consiste en obtener un modelo que represente el dominio de conocimiento y que sea accesible para el usuario a partir de instancias de conocimiento concretas, en particular, resulta importante obtener la información de dependencia entre las variables involucradas en el fenómeno, en los sistemas donde se desea predecir el comportamiento de algunas variables desconocidas basados en otras conocidas.

2.4.3 Algoritmos de inducción

Este tipo de algoritmos utiliza ejemplos como entradas para aplicar sobre ellos un proceso inductivo y así presentar la generalización de los mismos como resultado de salida. Existen dos tipos de ejemplo, los positivos y los negativos, Los primeros fuerzan la generalización, mientras que los segundos previenen para que no sea excesiva. Los ejemplos que se traten durante la fase de entrenamiento deben ser representativos de los conceptos que se está tratando de enseñar. En la actualidad existen numerosos enfoques de algoritmos de inducción y variedad en cada enfoque, el presente trabajo solo tratará los algoritmos orientados a generar árboles de decisión, particularmente el algoritmos C4.5. Dado a que el algoritmo C4.5 proviene del algoritmo ID3, se aporta la explicación detallada de ambos.

2.4.3.1 Árboles de Decisión: Algoritmo ID3

2.4.3.1.1 Introducción al Algoritmo ID3

El algoritmo ID3, diseñado en 1993 por J. Ross Quinlan, toma objetos de una clase conocida y los describe en términos de una colección fija de propiedades o de variables, produciendo un árbol de decisión sobre estas variables que clasifica correctamente todos los objetos. Hay ciertas cualidades que diferencian a este algoritmo de otros sistemas generales de inferencia. La primera se basa en la forma en que el esfuerzo requerido para realizar una tarea de inducción crece con la dificultad de la tarea. El ID3 fue diseñado específicamente para trabajar con masas de objetos, y el tiempo requerido para procesar los datos crece sólo linealmente con la dificultad, como producto de:


20

� La cantidad de objetos presentados como ejemplos.

� La cantidad de variables dadas para describir estos objetos.

� La complejidad del concepto a ser desarrollado (medido por la cantidad de nodos en el árbol de decisión).

Esta linealidad se consigue a costa del poder descriptivo ya que los conceptos desarrollados por el ID3 solo toman la forma de árboles de decisión basados en las variables dadas, y este "lenguaje" es mucho más restrictivo que la lógica de primer orden o la lógica multivaluada, en la cual otros sistemas expresan sus conceptos. El ID3 fue presentado como descendiente del CLS creado por Hunt y, como contrapartida de su antecesor, es un mecanismo mucho más simple para el descubrimiento de una colección de objetos pertenecientes a dos o más clases. Cada objeto debe estar descrito en términos de un conjunto fijo de variables, cada una de las cuales cuenta con su conjunto de posibles valores. Por ejemplo, la variable Insomnio puede tener los valores {Cierto, Falso}, la variable sexo, {Hombre, Mujer} y la variable estadío {0, 1, 2, 3, 4, 5}. Una regla de clasificación en la forma de un árbol de decisión puede construirse para cualquier conjunto C de variables de esta forma: � Si C está vacío, entonces se asocia arbitrariamente a cualquiera de las clases.

� Si C contiene los representantes de varias clases, se selecciona una variable V y se particiona C en conjuntos disjuntos C1,C2,....., Cn, donde Ci contiene aquellos miembros de C que tienen el valor i para la variable V. Cada uno de estos subconjuntos se trata con la misma estrategia.

Árbol ID3 Apoyo_familiar = Cierto | Disnea_refractaria = Cierto | | VAS_Depresion <= 1 | | | Morfina_Savredol-Oral <= 100: CSS3 | | | Morfina_Savredol-Oral > 100: HOME | | VAS_Depresion > 1: CSS1 | Disnea_refractaria = Falso | | STAS_Apetito <= 5: CSS1 | | STAS_Apetito > 5: ONCO Apoyo_familiar = Falso | STAS_Apetito <= 5: CARDIO | STAS_Apetito > 5 | | Edad_joven = Cierto: CSS2 | | Edad_joven = Falso: ONCO

Figura 5. Ejemplo árbol de Decisión.


21

El resultado es un árbol en el cual cada hoja contiene un nombre de clase y cada nodo interior especifica una variable para ser testeada con una rama correspondiente al valor de la variable.

2.4.3.1.2 Descripción del Algoritmo ID3.

El objetivo del algoritmo ID3 es crear una descripción eficiente de un conjunto de datos mediante la utilización de un árbol de decisión. Dados unos datos consistentes, es decir, sin contradicción entre ellos, el árbol resultante describirá el conjunto de entrada a la perfección. Además, el árbol puede ser utilizado para predecir los valores de nuevos datos, asumiendo siempre que el conjunto de datos sobre el cual se trabaja es representativo de la totalidad de los datos. Dados: � Un conjunto de datos.

� Un conjunto de descriptores de cada dato.

� Un clasificador/conjunto de clasificadores para cada objeto.

Se desea obtener un árbol de decisión simple basándose en la entropía, donde los nodos pueden ser: � Nodos intermedios: en donde se encuentran los descriptores escogidos

según el criterio de entropía, que determina cuál rama es la que debe tomarse.

� Hojas: estos nodos determinan el valor del clasificador.

Este procedimiento de formación de reglas funcionará siempre, dado que no existen dos objetos pertenecientes a distintas clases pero con idéntico valor para cada una de sus variables; si este caso llegara a presentarse, las variables son inadecuadas para el proceso de clasificación. Hay dos conceptos importantes a tener en cuenta en el algoritmo ID3: la entropía y el árbol de decisión. La entropía se utiliza para encontrar la variable más significativa en la caracterización de un clasificador. El árbol de decisión es un medio eficiente e intuitivo para organizar los descriptores que pueden ser utilizados con funciones predictivas.

2.4.3.1.3 Pseudocódigo del Algoritmo ID3

La tabla 2 presenta el algoritmo del método ID3 para la construcción de árboles de decisión en función de un conjunto de datos previamente clasificados.


22

Tabla 2. Algoritmo ID3.

2.4.3.1.4 Limitaciones del 1Algoritmo ID3

El ID3 puede aplicarse a cualquier conjunto de datos, siempre y cuando las variables sean discretas. Este sistema no cuenta con la facilidad de trabajar con variables continuas ya que analiza la entropía sobre cada uno de los valores de una variable, por lo tanto, tomaría cada valor de una variable continua individualmente en el cálculo de la entropía, lo cual no es útil en muchos de los dominios. Cuando se trabaja con variables continuas, generalmente se piensa en rangos de valores y no en valores particulares. Existen varias maneras de solucionar este problema del ID3, como la agrupación de valores presentada en o la discretización de los mismos. El C4.5 resolvió el problema de los atributos continuos mediante la discretización.

1 Nota: habrá errores, es decir, registros que no estarán bien clasificados en este caso

Función ID3 (R: conjunto de atributos no clasificadores, C: atributo clasificador, S: conjunto de entrenamiento) devuelve un árbol de decisión;

Comienzo Si S está vacío entonces

Devolver un único nodo con Valor Falla; Fin si

Si todos los registros de S tienen el mismo valor par a el

atributo clasificador entonces Devolver un único nodo con dicho valor; Si R está vacío entonces

Devolver un único nodo con el valor más frecuente del atributo clasificador en los registros de S

1

Fin si

Si R no está vacío entonces D = atributo con mayor Ganancia (D,S) entre los

atributos de R; Sean {dj | j=1,2,...., m} los valores del

atributo D; Sean {dj | j=1,2,...., m} los subconjuntos de S

correspondientes a los valores de dj respectivamente;

Devolver un árbol con la raíz nombrada como D y con los arcos nombrados dl, d2,...., dm que van respectivamente a los árboles ID3(R-{D}, C, Sl), ID3(R-{D}, C, S2), .., ID3(R-{D}, C, Sm);

Fin si Fin si Fin


23

2.4.3.2 Árboles de Decisión: Algoritmo C4.5

2.4.3.2.1 Introducción al Algoritmo C4.5

El C4.5 se basa en el ID3, por lo tanto, la estructura principal de ambos métodos es la misma. El C4.5 construye un árbol de decisión mediante el algoritmo "divide y vencerás" y evalúa la información en cada caso utilizando los criterios de entropía y ganancia o proporción de ganancia, según sea el caso. A continuación, se explicarán las características particulares de este método que lo diferencian de su antecesor.

2.4.3.2.2 Pseudocódigo del Algoritmo C4.5

El algoritmo del método C4.5 para la construcción de árboles de decisión a grandes rasgos muy similar al del ID3. Varía en la manera en que realiza las pruebas sobre las variables, como se aprecia en la tabla 3. 1

2.4.3.2.3 Características particulares del Algoritmo C4.5

En cada nodo, el sistema debe decidir cuál prueba escoge para dividir los datos. Los tres tipos de pruebas posibles propuestas por el C4.5 son:

1 Nota: habrá errores, es decir, registros que no estarán bien clasificados en este caso.

Función C4.5 (R: conjunto de atributos no clasificadores, C: atributo clasificador, S: conjunto de entrenamiento) devuelve un árbol de decisión;

Comienzo Si S está vacío entonces

Devolver un único nodo con Valor Falla;

Si todos los registros de S tienen mismo valor para a tributo clasificador entonces Devolver un único nodo con dicho valor;

Si R está vacío entonces Devolver un único nodo con el valor más frecuente d el atributo clasificador en los registros de S

1

Si R no está vacío, D = atributo con mayor Proporción de Ganancia(D,S)

entre los atributos de R; Sean {dj | j=1,2,...., m} los valores del atributo D; Sean {dj | j=1,2,...., m} los subconjuntos de S

correspondientes a los valores de dj respectivamente;

Devolver un árbol con la raíz nombrada como D y con los arcos nombrados d1, d2,....,dm, que van respectivamente a los árboles C4.5(R- {D}, C, Sl), C4.5(R-{D}, C, S2), C4.5(R-{D}, C, Sm);

Fin

Tabla 3. Algoritmo C4.5


24

� La prueba "estándar" para las variables discretas, con un resultado y una rama para cada valor posible de la variable.

� Una prueba más compleja, basada en una variable discreta, en donde los valores posibles son asignados a un número variable de grupos con un resultado posible para cada grupo, en lugar de para cada valor.

� Si una variable A tiene valores numéricos continuos, se realiza una prueba binaria con resultados A <= Z y A > Z, para lo cual debe determinarse el valor límite Z.

Todas estas pruebas se evalúan de la misma manera, mirando el resultado de la proporción de ganancia, o alternativamente, el de la ganancia resultante de la división que producen. Ha sido útil agregar una restricción adicional: para cualquier división, al menos dos de los subconjuntos Ci deben contener un número razonable de casos. Esta restricción, que evita las subdivisiones casi triviales, es tenida en cuenta solamente cuando el conjunto C es pequeño.

2.4.4 Reglas de producción

Una de las formas clásicas más empleadas en el entrono médico para la representación de comportamientos es mediante el uso de reglas de producción. Una regla de producción es una estructura condicionada IF...THEN en la que se distinguen dos componentes: la condición que filtra los elementos para los cuales la regla es válida (antecedente) y la conclusión que establece un hecho sobre todos los elementos que satisfacen el antecedente de la regla (consecuente). Se distinguen diversos tipos de condiciones dependiendo de la estructura lógica con que se combinan los componentes (selectores) del antecedente. En este trabajo, el aprendizaje se centra exclusivamente en la producción de reglas denominadas conjuntivas debido, principalmente, a que son más cómodas e inteligibles. Se denominan reglas conjuntivas aquellas que disponen de un antecedente en el que sus selectores se combinan mediante el “y” lógico: REGLA: S1 y S2 y ... y Sn ENTONCES x

2.4.5 Tablas de Decisión

La tabla de decisión es un instrumento para decidir la mejor alternativa en un proceso de decisión. Una tabla de decisión se compone de una matriz en la que se almacenan una serie de condiciones y sus correspondientes acciones. La tabla de decisión está integrada por cuatro secciones: identificación de condiciones, entradas de condiciones, identificación de acciones y entradas de acciones de la siguiente tabla.


25

Condición Reglas de decisión Identificación de condiciones Entradas de condiciones

Identificación de acciones Entradas de acciones

Figura 5. Forma general de las tablas de decisión. La identificación de condiciones señala aquellas condiciones o variables que son relevantes para la toma de decisión. Las entradas de condiciones indican qué valor, que pude ser indefinido (indicado con el signo “--” ), se debe asociar para una determinada condición. La identificación de acciones lista el conjunto de todas las decisiones individuales que se pueden tomar en el proceso. Las entradas de acciones muestran las acciones específicas del conjunto que deben emprenderse cuando ciertas condiciones o combinaciones de éstas son verdaderas. Las columnas del lado derecho de la tabla enlazan condiciones y acciones, forman reglas de decisión que establecen las condiciones que deben satisfacerse para emprender un determinado conjunto de acciones. Nótese que se omite el orden de la secuencia (en que las condiciones son examinadas) cosa que no sucede con los árboles de decisión. La regla de decisión incorpora todas las condiciones que deben ser ciertas y no sólo una a la vez. La tabla 4 muestra una tabla de decisión que describe las acciones emprendidas para los pagos por parte de los pacientes de un hospital.

Condiciones Reglas de decisión 1 2 4

C1 El paciente tiene seguro médico básico SI - NO C2 El paciente tiene seguro social NO SI NO

A1 Pagar la consulta X A2 Exento de pago X A3 Pagar todos los servicios X

Tabla 4. Tabla de decisión muestra el pago de los servicios de salud.

Las acciones tomadas dependen de que el paciente tenga seguro y, si es así ver de qué tipos dicho seguro. Se tienen identificados dos tipos de seguros: el seguro básico de salud (condición 1) y el seguro social (condición 2). La existencia o no de la primera condición (que el paciente tenga seguro básico de salud) se representa por medio de las letras S y N (sí o no) en la parte correspondiente en la tabla a las entradas de condiciones. Cuatro reglas relacionan las combinaciones de las condiciones 1 y 2 con tres diferentes acciones: � El paciente debe pagar el costo de la consulta sin ningún otro cargo.

� El paciente no paga ninguno de los cargos.

� El paciente paga el costo de todo el tratamiento (consulta y otros cargos).


26

Al observar esta tabla es claro que cuando: C1 y C2 son Sí y No respectivamente, la regla establece que se debe tomar la acción A1; el paciente paga únicamente el costo de la consulta. Cuando el valor de la condición C2 se invierte (C2 es Sí), y el valor de C1 es indiferente (C1 es Sí o No, y lo expresamos con el símbolo “-“) la regla 2 indica que debe emprenderse la acción A2; el paciente no necesita pagar ninguno de los cargos. Para finalizar, la regla 4 estipula que, si tanto C1 como C2 son No (lo que significa que el paciente no tiene seguro), los miembros del personal deben seguir A3: el paciente debe pagar todos los cargos de la atención médica que recibe en la clínica.


27

Capítulo 3. SISTEMA DE AYUDA A LA TOMA DE DECISIÓN.

3.1 Descripción del sistema

El sistema que se presenta en este trabajo, dentro del contexto del proyecto PalliaSys, trata de dar una solución a la problemática siguiente: � Detectar los estados de un paciente y cambios de estado de estos paciente.

� Detectar los patrones de circuitos seguidos por los pacientes

� Construir de estructuras de decisión (árboles, reglas, tablas)

� Detectar la evolución de los pacientes, a partir de los estados en que se clasifican los pacientes ya tratados.

Por tanto la solución aquí planteada resolverá una parte de este proyecto. En concreto, se va a desarrollar el núcleo central del agente Data Analyser (Véase figura 1) :

Figura 6. El proyecto en el contexto de Palliasys. Hay que remarcar, que en este proyecto no se utilizará tecnología de agentes, es decir, sólo se implementará aquello que el agente Data Analyser necesite para la resolución de los problemas planteados, mientras que la tarea propia del agente (como es la comunicación con otros agentes) se deja para un futuro trabajo. Por esta razón, a partir de este momento no se hablará de un agente Data Analyser, sino de un Sistema Data Analyser. Una de las limitaciones que se prevé es pues, la obtención de datos reales de la Base de Datos Hospitalarios, ya que no habrá esa comunicación necesaria entre agentes. Para solventar este contratiempo, en

DB Wrapper

Data Analyser


28

posteriores secciones se describen unos métodos y algoritmos de obtención aleatoria de datos. A continuación se presentan las características específicas de este sistema.

3.1.1 Funcionalidad y uso

El funcionamiento de este sistema se basa en cuatro fases bien diferenciadas: � Fase 1: Recogida de datos provenientes de la Base de Datos Hospitalarios.

� Fase 2: Generación de circuito de pacientes y de circuito de cambio de estado. En esta fase se incluye la detección de estados de paciente.

� Fase 3: Generación de Estructuras de decisión (árboles, reglas y tablas de decisión).

� Fase 4: Previsión de evoluciones de nuevos pacientes.

La figura 7 recoge las fases 1 y 2, la figura 8 recoge las fase 3 y finalmente la figura 9 recoge la fase 4. El acceso a los datos de la Base de Datos Hospitalarios tiene varias entidades en juego, por un lado esta la PCU Database que es la Base de Datos física, por otro lado tenemos el agente DB Wrapper que es quien interactúa directamente con la Base de Datos, y finalmente tenemos al agente Data Analyser que es quien realiza la petición de datos al DB Wrapper para que este a su vez acceda a los datos físico y se los devuelva en un formato establecido previamente. Una vez los datos de los pacientes están en poder del agente Data Analyser, se iniciará la generación de circuito de pacientes y de circuito de cambio de estado. En un primer lugar se generará el grafo de Circuitos que representa el circuito de pacientes, este se genera a medida que se recorre la lista de pacientes que ha proporcionado el agente DB Wrapper y mediante un algoritmo de generación de grafos. Este algoritmo comprobará para cada paciente que recorrido a seguido por los distintos servicio. Seguidamente se iniciará la detección de estados de pacientes con el algoritmo K-Means, generando una lista de pacientes como la anterior algo más reducida en cuanto a atributos de los pacientes, ya que para la detección de estado del paciente puede ser que no sean necesarios la totalidad de los atributos extraídos de la Base de Datos. La nueva lista creada se pasará por el algoritmo de generación del grafos obteniendo como resultado el grafo de Estados. Este proceso corresponde a las fases 1 y 2, y esta esquematizado en la figura 7.


29

Figura 7. Construcción del grafo de circuitos y el grafo de estados. La generación de las estructuras de decisión parte de los grafos de circuitos y de estadíos. Antes de esta generación se deben preparar los datos de los pacientes, organizándolos de forma adecuada. El recorrido de los grafos nos permite estructurar la información de los pacientes de acuerdo al formato de las entradas de los algoritmos de generación de las estructuras de decisión. El árbol de decisión es el primero en crearse, y toma como información de partida los pacientes que han salido de un determinado servicio o estadío, por tanto tendremos tantos árboles como servicios y estadíos de salida tengamos. Una vez se generen los árboles, el agente Data Analyser está en disposición de crear las reglas de producción y las tablas de decisión (tendremos una batería de reglas y una tabla por árbol de decisión).

DB Wrapper

Data Analyser

Registro clínico: Paciente 1





Datos de los pacientes

detección de estados de paciente

con K-Means

Paciente 1: Estadío 1





Clasificación de los pacientes

Grafo de Circuitos Grafo de Estados


30

Figura 8. Construcción de la estructura de decisión Una vez tenemos generados el Árbol de decisión, las Reglas y la Tabla de Decisión estamos en disposición de concluir la fase 4: Dado un nuevo paciente, podemos prever el resultado de su evolución aplicando los datos de este paciente sobre alguna de las estructuras de decisión alcanzadas en la fase anterior. En el presente trabajo la estructura utilizada para prever la evolución de los pacientes es el Árbol de decisión. El Sistema Data Analyser será quien proveerá a los expertos médicos de aquella información complementaria para la toma de decisión.

Figura 9. Proceso de decisión sobre un paciente.

Tabla de Decisión

Grafo de Circuitos Grafo de Estados

Árbol decisión C4.5

Condición Reglas de decisión Condiciones Entrada de Condiciones Acciones Entrada de Acciones

R1: Si .... entonces





Reglas

Nuevo Paciente Estructura de Decisión

Actuación


31

3.2 Aspectos de la implementación

El paradigma de programación utilizado ha sido el Paradigma Orientado a Objetos, y el lenguaje de programación seleccionado para la implementación ha sido JAVA (versión j2sdk1.4.2_01 de Sun Microsystems). La principal motivación de esta elección no es otra que la facilidad para identificar objetos dentro del sistema: Paciente, Lista de pacientes, Grafos, Árboles, Tablas, etc. y esto ayuda enormemente a la concepción general del sistema. Otra motivación relevante la tenemos en el hecho que el proyecto PalliaSys donde se engloba este trabajo, está implementado con esta tecnología. La implementación seguirá la división realizada en el apartado anterior, por lo tanto tendremos 4 fases a implementar independientes, pero teniendo en cuenta que para la consecución de cada una de las fases, previamente se ha tenido que realizar la fase anterior.

3.2.1 Fase 1: Recogida de datos.

La información es un recurso fundamental en cuanto nos permite tratarla para obtener unos resultados que confirmen una hipótesis o que ayuden a la comprobación de los hechos. Por tanto, el acceso a esa información se hace imprescindible para cualquier tipo de estudio que se desee realizar. Entorno a la información, aparecen una serie de problemáticas que hay que tener en cuenta, como son la posibilidad de que ésta no sea completa o de que sea incierta. Estos aspectos hay que considerarlos a la hora de realizar los estudios sobre estos datos. Los métodos y algoritmos utilizados en el presente trabajo prevén este particularidad. La fase de recogida de datos comprende el acceso a la Base de Datos Hospitalarios que contiene la Unidad de Curas Paliativas (UCP) del Hospital de la Santa Creu i Sant Pau (Barcelona). Este acceso se realiza mediante un agente inteligente específico para esta tarea (DB Wrapper), pero como ya se ha indicado anteriormente en la actualidad este agente no está plenamente desarrollado y su uso por parte de este proyecto ha sido suplantada por la creación de un algoritmo de generación aleatoria de datos que sustituye la información que se debería recibir del agente DB Wrapper. En todo caso este agente debería retornar un fichero con todos los registros clínicos de los pacientes en un determinado periodo de tiempo suficientemente relevante. Este fichero debería estar ordenado por número de historial clínico (NHC) y a su vez por fecha de entrada en un servicio. Obviamente, el fichero también debería incluir toda una serie de datos necesarios para las fases posteriores (Véase Anexo 6.1). Una vez obtenido el fichero con todos los datos necesarios, estos se introducen en nuestro sistema para ser tratados. Esto quiere decir que se cargarán todos los


32

registros clínicos en memoria, en una estructura que permite una manipulación de los mismos lo más sencilla posible. De forma resumida podemos decir que esta estructura no será más que una lista de registros clínicos (Lista de objetos paciente) ordenados por el número de historial clínico y a su vez subordenados por la fecha de entrada a un servicio.

3.2.2 Fase 2: Circuito de pacientes y Cambio de estado.

Una vez completada la Fase 1, tenemos en nuestro sistema la lista de pacientes cargados en memoria englobados en una estructura adecuada para su posterior tratamiento. la fase 32comprende la creación de un circuito de pacientes por un lado, y la creación del circuito de cambio de estado de pacientes por otro.

3.2.2.1 Circuito de pacientes

Para la representación de un circuito de pacientes se ha optado por la creación de una estructura de datos correspondiente a un Grafo. El proceso de construcción de la estructura de grafo sigue los pasos de un algoritmo de la tabla 5, donde en primer término el sistema, partiendo del grafo vacío, solicita un objeto paciente de la lista de Pacientes de la fase anterior. Para cada Paciente verifica los servicios por los que el paciente ha sido asistido, creando y actualizando los nodos y arcos que sean necesarios. Por tanto en la información de cada paciente aparece, como mínimo, tanto el servicio de donde proviene como el servicio a donde se dirige (que puede ser el mismo).

PSEUDOCÓDIGO ACCION Introducir_nodo_Partida(x) SI (x ∉ N) ENTONCES (N+x) ACCION Introducir_nodo_destino(x,M)

SI (x ∉ M) ENTONCES (N,M+x)

ACCION Introducir_arco(N,M,Eval) Asociar (N,M,Eval)

L: lista de evaluaciones de pacientes (en un perio do de

tiempo). G(N,M): grafo vacío: N = ∅ , M = ∅ , donde N es una lista

de nod os_partida y M una lista de nodos_destino.

MIENTRAS L ≠ ∅ HACER Eval = evaluación_paciente(L) Introducir_nodo_Partida(Eval.N) Introducir_nodo_destino(Eval.N, Eval.M) Introducir_arco(Eval.N, Eval.M, Eval)

Fin mientras

Tabla 5. Algoritmo de construcción del grafo de Circuitos


33

La implementación en JAVA se ha realizado mediante una estructura HashTable donde se guardan los servicios de partida de cada paciente, y asociado a cada servicio tenemos un puntero a otro HashTable donde se almacenan todos los servicios destino. Por último, asociada a cada servicio destino tenemos una lista (LinkedList) de pacientes que han realizado este circuito (arco del grafo). Mediante esta implementación el acceso a esta estructura de grafo es casi inmediata. Como decisión de diseño para la creación de las estructuras HashTable hay que decir que su inicialización es de 16 posiciones, es decir, inicialmente se prevé que no habrá más de 16 servicios de partida o destino. En todo caso este parámetro es modificable en tiempo de compilación. La figura 10 es ejemplo de grafo de circuito de pacientes:

Figura 10. Ejemplo de circuito de pacientes.

3.2.2.2 Cambio de estado

El circuito descrito por los cambios de estado de los pacientes es similar al presentado en el apartado anterior, pero en este caso tenemos una peculiaridad añadida, y es que contrariamente al circuito de pacientes donde se dispone del nodo de partida y del nodo de destino para generar el grafo, en este caso no hay tales nodos. Para su identificación se emplean técnicas de clasificación automática, que partiendo de los atributos de un paciente se deteminará en que esta se encuentra. La posibilidad de estados se reduce a seis, con lo cual el grafo resultante no tiene unas dimensiones considerables. El algoritmo de clasificación utilizado es el K-Means (Véase 2.3.1). Al tratarse de un algoritmo conocido y ampliamente utilizado, se ha optado por utilizar una herramienta que implemente este algoritmo. WEKA (Waikato Environment for knowledge Analysis, University of Waikato, New Zealand) es una herramienta de código abierto que permitirá clasificar mediante el algoritmo K-Means todos aquellos datos que le pasemos con un formato especifico. Mediante el recorrido

UCP

CSS1

CSS2

HOME

Paciente Servicio Partida Servicio Destino P1 UCP CSS1 P1 CSS1 CSS2 P2 UCP CSS2 P2 CSS2 CSS1 P3 HOME CSS1 P4 HOME UCP P4 UCP HOME

P3

P4

P4

P2 P1

P1

P2


34

de la lista de los pacientes, obtendremos un formato de los datos optimo para introducirlo dentro del algoritmo proporcionado con la herramienta WEKA. Una vez WEKA haya clasificado a los pacientes, estaremos en disposición de crear el grafo de cambio de estado de los pacientes. Este grafo, a diferencia del grafo creado en la sección anterior, tendrá como nodo de partida el estado actual del paciente y como nodo de destino el estado del mismo paciente pero en una evaluación posterior (los registros clínicos de pacientes están ordenados por numero de historial clínico, por tanto las evaluaciones de cada paciente aparecerán contiguas en la lista de pacientes). El algoritmo de generación del grafo será reutilizado tanto para el circuito de pacientes como el de cambio de estado, siendo la única diferencia el significado de los datos que el algoritmo toma como entrada. La figura 11 muestra un ejemplo de cambio de estado de pacientes:

Figura 11. Ejemplo de cambio de estado de pacientes.

3.2.3 Fase 3: Estructuras de decisión.

En esta fase crearemos las estructuras de decisión: árboles, reglas y tablas; para después poder realizar predicciones sobre futuros pacientes.

3.2.3.1 Árbol de Decisión: C4.5

La primera estructura a crear será el Árbol de Decisión mediante el algoritmo C4.5. El resto de estructuras de decisión (Reglas y Tablas) se crearán a partir de este Árbol. Para la implementación del algoritmo C4.5 se ha utilizado nuevamente la herramienta WEKA. Esta herramienta, permite generar árboles mediante el citado algoritmo pasándole un fichero(.arff), como parámetro de entrada, con un formato predefinido. En este fichero han de aparecer todos aquellos atributos

E3

E1

E2

E0

E4

EXITUS

Evaluaciones

P1

P2

P3

E0 E1 E2 E4 Exitus

E0

E0

E2 E4 E3

E3 Exitus

P3

P1 P2

P1

P2

P1

P2

P3

P1


35

del paciente que deseamos evaluar como causante del cambio de ubicación o estado, según el caso, de un paciente. Cada nodo del árbol está conformado por un atributo y puede verse como la pregunta: ¿Qué valor tiene este atributo en el ejemplar a clasificar? Las ramas que salen de los nodos, corresponden a los posibles valores del atributo correspondiente. Para la generación de los ficheros de entrada, en el caso del grafo de cambio de estado, tendremos en cuenta sólo los atributos que el usuario decidió utilizar para la determinación del estado del paciente. Un árbol de decisión clasifica a un ejemplar, filtrándolo de manera descendente, hasta encontrar una hoja, que corresponde a la clasificación buscada. La generación del fichero de entrada del algoritmo C4.5 se produce de forma automática cuando se recorren los grafos construidos en la fase anterior. Dado un nodo de partida (servicio para el grafo de circuito de paciente, estadío para el grafo de cambio de estado) el árbol de decisión representará a qué nodos de destino puede llegar, y que combinación de atributos valor debe darse para llegar a ese destino. Por tanto, tendremos tantos árboles de decisión como nodos de partida tengamos en los dos grafos generados en la fase anterior. La figura 12 muestra un ejemplo de árbol de decisión:

3.2.3.2 Reglas de Producción

Una vez se dispone del árbol de decisión, estamos en disposición de crear las reglas de producción. Estas, aparecerán de forma automática al recorrer dicho

Árbol C4.5 Apoyo_familiar = Cierto | Disnea_refractaria = Cierto | | VAS_Depresion <= 1 | | | Morfina_Savredol-Oral <= 100: CSS3 | | | Morfina_Savredol-Oral > 100: HOME | | VAS_Depresion > 1: CSS1 | Disnea_refractaria = Falso | | STAS_Apetito <= 5: CSS1 | | STAS_Apetito > 5: ONCO Apoyo_familiar = Falso | STAS_Apetito <= 5: CARDIO | STAS_Apetito > 5 | | Edad_joven = Cierto: CSS2 | | Edad_joven = Falso: ONCO

Figura 12. Ejemplo árbol de Decisión.


36

árbol en profundidad. Este recorrido no lo incorpora la herramienta WEKA, pero al tratarse de código abierto el acceso a la estructura de datos donde se almacena el árbol hace posible la implementación de las reglas. Lo relevante aquí es que la conversión del árbol en reglas ayuda a distinguir los diferentes contextos en los que un atributo participa en la clasificación, es decir, reglas diferentes; elimina la diferencia entre nodos ubicados cerca de la raíz y aquellos ubicados cerca de las hojas; y aumenta la facilidad de comprensión por parte del usuario. La figura 13 muestra las reglas de producción que se generan del árbol de la figura 12.

Reglas de Producción Si Apoyo_familiar = Cierto Y

Disnea_refractaria = Cierto Y VAS_Depresion <= 1 Y Morfina_Savredol-Oral <= 100 ENTONCES CSS3

Si Apoyo_familiar = Cierto Y Disnea_refractaria = Cierto Y VAS_Depresion <= 1 Y Morfina_Savredol-Oral > 100 ENTONCES HOME

Si Apoyo_familiar = Cierto Y Disnea_refractaria = Cierto Y VAS_Depresion > 1 ENTONCES CSS1

Si Apoyo_familiar = Cierto Y

Disnea_refractaria = Falso STAS_Apetito <= 5 ENTONCES CSS1

Si Apoyo_familiar = Cierto Y

Disnea_refractaria = Falso STAS_Apetito > 5 ENTONCES ONCO

Si Apoyo_familiar = Falso y STAS_Apetito <= 5 ENTONES CARDIO

Si Apoyo_familiar = Falso Y STAS_Apetito > 5 Y Edad_joven = Cierto ENTONCES CSS2

Si Apoyo_familiar = Falso Y

STAS_Apetito > 5 Y Edad_joven = Falso ENTONCES ONCO

Figura 13. Ejemplo reglas de producción.


37

3.2.3.3 Tabla de Decisión

Tanto las reglas de producción como la Tabla de Decisión son herramientas visuales muy apropiadas para la comprensión del comportamiento que han tenido el conjunto de pacientes que han pasado por la unidad de curas paliativas del hospital en un periodo de tiempo. Como ocurría con las reglas de producción, la tabla de decisión también deriva del árbol C4.5, y será a partir de su exploración con la que se construya la tabla. La implementación de la tabla de decisión a seguido unos pasos similares a la implementación de las reglas de producción, pero en este caso se ha introducido un grado de generalización que permite una mayor comprensión. Como se puede prever, la utilización de atributos de pacientes con valores numéricos hace que un mismo atributo pudiera aparecer varias veces en una rama del árbol con valores diferentes, esto es, un nodo del árbol (p.e. sequedad de boca) podría tener dos ramas (una con valor >3 y otra con valor <=3) , y en una de esas ramas (p.e. valor >3) aparecer de nuevo ese mismo atributo-nodo con otras dos ramas (p.e valor <5 y valor >=5). Este hecho se recogía en las reglas de producción como datos independientes que se debían de cumplir uno a uno, mientras que en el caso de la tabla de decisión se ha unificado el criterio obteniendo como resultado condiciones a cumplir que pueden ser un rango de valores. En el ejemplo que indicaba tendremos las siguientes condiciones a cumplir: � Sequedad de boca <=3

� Sequedad de boca entre [3,5]

� Sequedad de boca >= 5

En conclusión, podemos observar que la representación del conocimiento en forma de tabla de decisión puede ayudar en la localización de una acción posterior a realizar de una forma algo más compacta, si cabe, que como lo realiza las reglas de producción.

Figura 14. Ejemplo Tabla de Decisión.

Condiciones Reglas de decisión Apoyo familiar Cierto Cierto Cierto Cierto Cierto Falso Falso Falso Disnea refractaria Cierto Cierto Cierto Falso Falso Falso - - VAS Depresión <= 1 <= 1 > 1 - - - - - MorfinaSavredolOral <= 100 > 100 - - - - - - STAS Apetito - - - <= 5 > 5 <= 5 > 5 > 5 Edad joven - - - - - - Cierto Falso CSS3 X HOME X CSS1 X X ONCO X X CARDIO X CSS2 X


38

3.2.4 Fase 4: Previsión de evoluciones de nuevos pacientes.

Una vez completadas las tres fases anteriores, el sistema albergará una serie de datos estructurados en forma de base del conocimiento. Con esta información, pretendemos que nuestro sistema sea capaz de dar una respuesta dado un caso específico de paciente. La fase de previsión de evoluciones de nuevos pacientes es uno de los objetivos principales de este trabajo, ya que es una fuente de información directa para la ayuda a la toma de decisión por parte de los expertos. El proceso de “previsión” se efectúa sometiendo los datos (atributos-valor) de un paciente nuevo a un proceso de comparación con los datos de nuestra base de conocimiento. En particular, al nuevo paciente se le hace pasar por el árbol de decisión describiendo un circuito sobre este árbol (desde la raíz, hasta una o varias hojas). De nuevo, en esta apartado, aparece la problemática de poseer información incompleta e inexacta, ya que los datos de un nuevo paciente puede que no sean totalmente completos y carezcamos del valor de ciertos atributos. Para solucionar este problema, en la exploración del árbol se tendrá en cuenta esta cuestión y llegados el caso la solución será mostrar todos los posibles caminos o soluciones, es decir, recorreremos más de una rama del árbol a la vez. Una vez el proceso de previsión haya concluido el sistema mostrará en forma de regla de producción todas las conclusiones a las que haya llegado. En todo caso habrá más o menos conclusiones dependiendo de si la información es totalmente completa o no. La implementación de esta apartado se inicia con la presentación al usuario de un formulario donde podrá introducir los datos de un nuevo paciente (o nueva evaluación del paciente si este ya existía dentro de la base de datos). La introducción de datos requiere que anteriormente se haya cargado la estructura de decisión adecuada para la generación de un resultado, por tanto se necesita saber de antemano el servicio del que proviene o el estado en el que se encuentra para cargar la estructura del árbol adecuada. La carga de la estructura se realiza mediante un fichero .arff que se le pedirá al usuario mediante un cuadro de dialogo, una vez cargada la estructura y recogidos los datos del paciente (que se almacenarán en una variable de tipo paciente) se iniciará la previsión del nuevo servicio o estado al que el paciente evolucionará y se presentará en pantalla en forma de regla de producción como antes ya se ha indicado.


39

3.3 Interficie de usuario

La interficie de usuario permite interactuar con el sistema de una forma más amigable, haciendo fácil la introducción y obtención de resultados y su comprensión. En este trabajo la interficie pretende cubrir todas las actividades que se han descrito en los apartado anteriores, y que hacían referencia a la entrada y salida de datos por pantalla. La implementación se ha realizado con el lenguaje de programación orientada a objetos JAVA.

3.3.1 Introducción

Las estructuras de datos que se crean mediante las metodologías explicadas en los apartados anteriores, deben tener una continuidad en el tiempo para poder ser consultadas cuando sea necesario. Esto obliga a introducir el concepto de persistencia, que en el presente trabajo se plasma con la creación de un “proyecto”, entendido este último concepto como un contenedor donde se guardan las estructuras objeto de nuestro trabajo. El software desarrollado permite la creación de un “proyecto”, así como la recuperación de un proyecto guardado anteriormente. La creación de un “proyecto” tiene una peculiaridad que cabe destacar, y es que los datos de la Base de Datos Hospitalarios de los que parte toda el estudio no son actualmente accesibles debido a que dependen de la conclusión de otro proyecto final de carrera actualmente en proceso. Este inconveniente inesperado al inicio del trabajo se ah solventado con al implementación de un sistema de generación de datos ficticios (Véase 6.2 Anexo 2). Una vez se obtienen estos datos “ficticios” el proceso de creación de grafos y estructuras de decisión sigue la lógica que se describe a continuación.

3.3.2 Pantalla principal

La figura 15 muestra la pantalla principal donde se tiene acceso a todos los servicios del programa. En este caso los servicios iniciales serán la carga un proyecto, o la creación de uno nuevo. Es lógico pensar que no tengamos acceso a otros servicios como la generación de grafos o estructuras de decisión, ya que no tenemos ningún dato en memoria para la creación de dichos objetos.


40

Figura 15. Pantalla principal.

Desde esta pantalla accederemos al resto de pantallas mediante los botones de la barra de herramientas, o desde los menús.

3.3.3 Pantalla Nuevo Proyecto.

Para crear un nuevo proyecto debemos seleccionar la opción correspondiente en el menú “archivo” o en el primer icono de la barra de herramientas. Aparecerá un cuadro de dialogo donde podremos introducir parámetros para la generación aleatoria de datos como son: el número de instancias y el número de pacientes que queremos generar. El número de evaluaciones de cada paciente vendrá dado por la división entre las instancias y los pacientes. En este formulario también podremos seleccionar el número de clusters o clases (número de Estadios) con los que clasificaremos a los pacientes. La figura 16 muestra lo explicado en este párrafo. Una vez generados los datos aleatorios se podrá visualizar el resultado en forma de tabla representada en la figura 17, aquí aparecen todos los pacientes generados ordenados por su numero de historial clínico.


41

Figura 16. Nuevo Proyecto.

Figura 17. Datos generados.


42

En este momento estamos en disposición de lanzar el algoritmo K-means sobre los datos para generar el grafo de Estadíos. Una vez pulsemos el botón con la etiqueta “K-Means” aparecerá otro cuadro de dialogo donde podremos seleccionar aquellos atributos que consideremos relevantes para la obtención de los estadios de los pacientes. Esto se ve reflejado en la figura 18.

Figura 18. Selección de atributos para algoritmo K-Means.

Una vez se han seleccionado los atributos, el sistema muestra una ventana donde se visualizan los pacientes de cada una de las clases que el algoritmo K-Means ha generado (que como máximo serán las que se han introducido como parámetro de entrada en el cuadro de dialogo de “nuevo proyecto”). Esta ventana también proporciona la posibilidad de cambiarle el nombre a las clases generadas, de esta manera es el médico experto quien decide el nombre de los estadíos o clases de pacientes. Para poder cambiar el nombre primero se selecciona la clase mediante una lista desplegable, se introduce el nuevo nombre dentro de un campo de texto y finalmente se pulsar el botón de sustituir. La figura 19 muestra esta ventana. Al pulsar el botón de finalizar se considera creado el nuevo proyecto. En este momento las estructuras de grafos ya están creadas y se pueden visualizar pulsando los respectivos botones o mediante el menú.


43

Figura 19. Estados de Pacientes.

3.3.4 Pantalla de circuitos de Pacientes y Estadios.

Las figuras 20 y 21 muestran la representación en forma de tablas del circuito de los pacientes por los diferentes Servicios, así como el circuito de los pacientes por los diferentes Estadíos. La visualización de estos datos en forma tabular facilita en gran mediada su comprensión. Dado un servicio o estadío de partida, representado por las filas, podemos saber rápidamente a qué servicio o estadío de destino, representado por las columnas, han ido a parar los pacientes paliativos. En este caso solo se muestra el numero de pacientes que han ido de un servicio a otro, o de un estadio a otro. No se muestra ningún tipo de información adicional ya que ese no es el objetivo de la representación. En todo caso internamente los datos completos de cada paciente están almacenados. Una vez mostrados los grafos, tenemos a nuestra disposición los ficheros .arff con la información necesaria para generar los árboles de decisión y las estructuras derivadas (reglas, tablas).


44

Figura 20. Circuito de Pacientes.

Figura 21. Circuito de Estadios.


45

3.3.5 Pantalla árbol de decisión

A esta pantalla se accede tanto por el botón situado en la barra de herramientas como por el menú “Decisión”. La figura 22 muestra la primera acción que se debe realizar para generar el árbol de decisión: “abrir fichero .arff” del servicio o estadío a partir del cual se quiere realizar el estudio. Una vez abierto este fichero se muestra (como indica la figura 23) el resultado de la generación del árbol.

Figura 22. Abrir árbol decisión

La información que se muestra del árbol de decisión es la siguiente: � Atributos utilizados.

� Representación del árbol de decisión.

� Número de hojas del árbol.

� Tamaño del árbol.

� Tiempo de construcción del árbol.


46

Figura 23. Árbol de decisión

3.3.6 Pantalla Reglas de Producción.

En esta pantalla podremos visualizar el resultado de recorrer el árbol de decisión. Las reglas de producción aparecen enumeradas y facilita la comprensión del conocimiento extraído de los datos iniciales. La figura 24 muestra esta pantalla.

3.3.7 Pantalla Tabla de Decisión.

La figura 25 muestra como representa la tabla de decisión el sistema. En este caso los campos vacíos en la parte de las condiciones representan valores indiferentes. Puede darse el caso que aparezcan rangos de valores en las condiciones como apuntábamos en el apartado 2.4.5.


47

Figura 24. Reglas de Producción.

Figura 25. Tabla de Decisión.


48

3.3.8 Pantalla de Nuevo Paciente.

En esta pantalla tenemos la posibilidad de introducir los datos de un nuevo paciente para estudiar su evolución futura. A esta pantalla se puede acceder una vez hayamos cargado el árbol de decisión ya que es a través de la exploración de éste cuando deducimos la evolución futura del paciente.

Figura 26. Nuevo Paciente.

Una vez se han introducido los datos, el sistema mostrará el resultado por pantalla en forma de Regla de Producción, indicando también la regla utilizada, es decir, la referencia a la regla utilizada. La figura 27 muestra el resultado de introducir un nuevo paciente. Como se comento en el apartado 3.2.4, los datos de un paciente nuevo pueden ser desconocidos. Este hecho se puede introducir mediante el símbolo “?” en los campos numéricos, mientras que en los campos boléanos se entiende que falso es el valor por omisión. Cabe decir que la introducción de información desconocida por parte del usuario, genera un resultado poco atractivo y poco útil, ya que la respuesta del sistema será prácticamente igual a la información que facilita las reglas de producción.


49

Figura 27. Resultados Nuevo Paciente.

3.3.9 Pantalla Guardar Proyecto.

La opción de guardar un proyecto solo está activa si primero lo hemos creado. Al guardar un proyecto se serializan los datos sobre un fichero “.ser” donde se almacenan las estructuras de grafos de evolución del paciente. Esto es así, ya que es a partir de los grafos con los que se generan el resto de estructuras de decisión. A la hora de guardar un proyecto podemos indicar en qué ubicación queremos hacerlo, así como el nombre que queramos ponerle para posteriormente recuperarlo. La generación de estructuras de decisión consiste en la creación de ficheros .arff que también serán permanentes en el tiempo por su condición de fichero. Cuando se crea un proyecto nuevo estos ficheros .arff se almacenan en una carpeta llamada ./tmp/, mientras que por el contrario si el proyecto se ha abierto estos ficheros se almacenarán en la carpeta de donde se abrió el proyecto. La figura 28 muestra el cuadro de dialogo para guardar un proyecto.


50

Figura 28. Guardar Proyecto.

Figura 29. Abrir Proyecto.


51

3.3.10 Pantalla Abrir Proyecto.

La figura 29 muestra el cuadro de dialogo que aparece cuando deseamos abrir un proyecto guardado anteriormente. Esta opción permite cargar en memoria toda la información necesaria para crear las estructuras de decisión. Una vez se ha abierto el proyecto tendremos activas las opciones para visualizar los grafos de evolución de los pacientes (tanto de Servicios como de Estadíos), así como la opción para cargar un fichero que genere un árbol de decisión.


52

Capítulo 4. PRUEBAS REALIZADAS

4.1 Descripción de las pruebas.

En este apartado se analizan los resultados obtenidos del estudio detallado de un conjunto de datos generado aleatoriamente, esto quiere decir que estos resultados pueden ser a veces algo incoherentes desde el punto de vista médico dada la naturaleza aleatoria de los datos. Las pruebas realizadas constan de la creación de un proyecto con unas determinadas opciones de generación de datos. Se ha optado por la creación de un único proyecto ya que, como apuntaba en el párrafo anterior, al ser datos aleatorios los resultados estarán sesgados por ruido aleatorio y se puede dar el caso que los resultados de dos proyectos sean totalmente diferentes y no se siga una lógica de resultados homogénea. El proyecto se ha creado con los siguientes datos: � Numero de instancias: 300

� Numero de pacientes: 100

� Numero de Evaluaciones: 3 por paciente

� Numero de Clusters (Estadios): 6

Estos datos generados se almacenan en un fichero, y corresponden a los obtenidos tras una consulta a la Base de Datos Hospitalarios del Hospital de la Santa Creu i Sant Pau (Barcelona) con la misma estructura (Véase 6.1 Anexo). Los atributos escogidos para la clasificación que realiza el algoritmo K-Means han sido aleatorios.


53

4.2 Datos Obtenidos.

4.2.1 Circuito de Pacientes.

En la figura 30 podemos observar el resultado del circuito de pacientes entre centros de salud. Por ejemplo, observamos el traslado de 18 pacientes del centro sociosanitario CSS3 al centro sociosanitario CSS1.

Figura 30. Circuito de Pacientes (Tabla) La figura 31 muestra la distribución de los pacientes para cada cambio de estadío. Observamos que la diagonal recoge la mayor parte de los pacientes, significando esto que la mayor parte de pacientes permanecen estables en su estadío y esporádicamente saltan a otro.

Figura 31. Circuito de Estadios

4.2.2 Árbol de decisión.

El ejemplo propuesto ha generado tantos árboles de decisión como servicios y estadíos de partida tenemos. En este caso podemos hablar de trece árboles de decisión.


54

Seguidamente vamos a mostrar dos de ellos: un árbol de Servicios y uno de Estadios (figuras 32 y 33).

Figura 32. Árbol de Decisión (Servicio Partida UCP)

Aunque estos resultados carezcan de valor médico podemos indicar, para el árbol de la figura 32, que los pacientes con apoyo familiar, con disnea refractaria y con un grado bajo de depresión son trasladados de la UCP al centro sociosanitario CSS3 si toman menos de 100 mg. de morfina y a su propia casa si toman más de 100 mg. por vía oral, como queda patente en los datos generados de manera aleatoria.

Árbol C4.5 ------------------ Apoyo_familiar = Cierto | Disnea_refractaria = Cierto | | VAS_Depresion <= 1 | | | Morfina_Savredol-Oral <= 100: CSS3 (7.0 /1.0) | | | Morfina_Savredol-Oral > 100: HOME (2.0) | | VAS_Depresion > 1: CSS1 (3.0/1.0) | Disnea_refractaria = Falso | | STAS_Apetito <= 5: CSS1 (2.0/1.0) | | STAS_Apetito > 5: ONCO (3.0) Apoyo_familiar = Falso | STAS_Apetito <= 5: CARDIO (2.0) | STAS_Apetito > 5 | | Edad_joven = Cierto: CSS2 (3.0) | | Edad_joven = Falso: ONCO (2.0) Numero de hojas : 8 Tamaño del árbol: 15 tiempo de construcción del modelo: 0.14 segundos

Árbol C4.5 ------------------ Apoyo_familiar = Cierto: Clase0 (11.0/4.0) Apoyo_familiar = Falso | VAS_Debilidad <= 2 | | Morfina_Savredol-Oral <= 400: Clase5 (8.0/2 .0) | | Morfina_Savredol-Oral > 400: Clase0 (13.0/2 .0) | VAS_Debilidad > 2: Clase0 (3.0/1.0) Numero de hojas : 4 Tamaño del árbol: 7 tiempo de construcción del modelo: 0 segundos

Figura 33. Árbol de Decisión (Estadio Partida Clase0)


55

4.2.3 Reglas de Producción

Las reglas de producción generadas también se mostrarán para los dos árboles escogidos (figuras 34 y 35). Como podemos observar las reglas están numeradas, esto es especialmente importante para la posterior predicción de Servicios o Estadíos destino de nuevos pacientes, ya que permitirá saber qué regla se ha satisfecho.

Figura 34. Reglas de Producción (Servicio Partida UCP)

Reglas de Producción R1: SI Apoyo_familiar = Cierto Y

Disnea_refractaria = Cierto Y VAS_Depresion <= 1 Y Morfina_Savredol-Oral <= 100 ENTONCES CSS3

R2: SI Apoyo_familiar = Cierto Y Disnea_refractaria = Cierto Y VAS_Depresion <= 1 Y Morfina_Savredol-Oral > 100 ENTONCES HOME

R3: SI Apoyo_familiar = Cierto Y Disnea_refractaria = Cierto Y VAS_Depresion > 1 ENTONCES CSS1

R4: SI Apoyo_familiar = Cierto Y Disnea_refractaria = Falso Y STAS_Apetito <= 5 ENTONCES CSS1

R5: SI Apoyo_familiar = Cierto Y Disnea_refractaria = Falso Y STAS_Apetito > 5 ENTONCES ONCO

R6: SI Apoyo_familiar = Falso Y STAS_Apetito <= 5 ENTONCES CARDIO

R7: SI Apoyo_familiar = Falso Y STAS_Apetito > 5 Y Edad_joven = Cierto ENTONCES CSS2

R8: SI Apoyo_familiar = Falso Y STAS_Apetito > 5 Y Edad_joven = Falso ENTONCES ONCO

Figura 35. Reglas de Producción (Estadio Partida Clase0)

Reglas de Producción R1: SI Apoyo_familiar = Cierto

ENTONCES Clase0 R2: SI Apoyo_familiar = Falso Y

VAS_Debilidad <= 2 Y Morfina_Savredol-Oral <= 400 ENTONCES Clase5

R3: SI Apoyo_familiar = Falso Y VAS_Debilidad <= 2 Y Morfina_Savredol-Oral > 400 ENTONCES Clase0

R4: SI Apoyo_familiar = Falso Y VAS_Debilidad > 2

ENTONCES Clase0


56

4.2.4 Tablas de decisión

Las figuras 36 y 37 muestran los resultados obtenidos de la creación de la Tablas de Decisión.

4.2.5 Nuevo Paciente: Previsión

Una vez creadas las estructuras de decisión podemos utilizarlas para prever la posible evolución de un nuevo paciente. Las pruebas realizadas han permitido verificar el correcto funcionamiento de la previsión de evolución de un nuevo paciente.

4.3 Análisis de resultados.

Los resultados obtenidos en el apartado anterior muestran la funcionalidad del sistema devolviendo valores aptos para su estudio. A continuación pasaremos a explicar los resultados.

Figura 36. Tabla de Decisión (Servicio Partida UCP)

Figura 37. Tabla de Decisión (Estadio Partida Clase0)


57

4.3.1 Circuito de Pacientes.

La figura 30 describe, en forma de tabla, el circuito que han realizado los pacientes por los diferentes servicios. Esta tabla tiene dos entradas: las filas que representan el servicio de partida, y las columnas que representan el servicio de destino. Ajustándonos a la prueba realizada podemos observar que el circuito a sido el mostrado en la figura 38. de él se han eliminado los traslados con un nº de pacientes no significativos (<=5).

Figura 38. Grafo del Servicio UCP Esto viene a decir que de la UCP han salido 24 pacientes distribuidos de la forma en que aparecen en la figura 30, sin descartar que alguno de estos 24 pacientes sea el mismo pero en una evaluación diferente. Como vemos los servicios de Oncología y el Centro SocioSanitario 3 tienen la mayor afluencia de pacientes provenientes de la UCP, mientras que el resto de servicios tienen una igual recepción de pacientes. El análisis de las estructuras de decisión permite responder el por qué de esta movilidad. Ahora veamos qué ha sucedido con el circuito de Estadios. La figura 31 muestra este circuito, y si escogemos la clase0 para ilustrar lo sucedido tenemos lo siguiente:

UCP

CSS3

CSS2

CSS1

HOME

ONCO

CARDIO

6 9

6

10

10

6

9

11

13

8

8

14

12

8

12 8

9

7

6

9

18

8

6


58

Figura 39. Grafo de Estadios Clase0 Este grafo muestra la evolución de 35 pacientes que partían de un estadio de tipo “clase0”. Su destino ha sido mayoritariamente el mismo estadio, eso quiere decir que estando en ese estadio hay una gran probabilidad de seguir en él dadas una determinadas condiciones que tendremos ocasión de observar en el apartado de análisis de las estructuras de decisión. Por el contrario, son pocos los pacientes que evolucionan hacia otro estadio, aunque cabe destacar los 6 pacientes que desembocan en el estadio “clase5”. Dado que no se han renombrado los estadios, sus nombres pueden crear confusión, pero esta tarea se delega al médico experto que es quien debe decidir observando los datos de cada clase de pacientes (el sistema permite esta visualización). Nosotros podríamos aventurarnos a decir que la clase 0 se trata de Estadio 0, mientras que la clase 5 se trata del Estadio 1 ya que parece la evolución lógica de un paciente.

4.3.2 Árbol, Reglas y Tablas de Decisión

Este apartado abre las puertas al análisis de las estructuras de decisión, desvelando el por qué de las evoluciones de los pacientes hacia unos Servicios o Estadios determinados. Ya que tanto los árboles como las reglas y la tablas dan la misma información aunque representada de forma diferente, podemos unificarlas a la hora de dar respuesta a las incógnitas que planteábamos anteriormente. En primer lugar vamos a analizar las causas que han generado el circuito de pacientes partiendo de la UCP. Para esto solamente debemos fijarnos en una

Clase0

Clase2

Clase3

Clase4

Clase1

Clase5

2

1

1

22 3

6 23

38

15 29

16


59

serie de atributos que determinan a qué servicio de destino evolucionará un paciente, por tanto los atributos que no aparecen en estas estructuras de decisión se pueden considerar irrelevantes ya que no aportan información para discriminar hacia qué servicio destino dirigirse. Más concretamente, en el caso de los pacientes que se han trasladado al servicio de Oncología los atributos relevantes que han generado que el paciente cambie su ubicación a este destino y no a otro han sido: R5: SI Apoyo_familiar = Cierto Y

Disnea_refractaria = Falso Y STAS_Apetito > 5 ENTONCES ONCO

R8: SI Apoyo_familiar = Falso Y STAS_Apetito > 5 Y Edad_joven = Falso

ENTONCES ONCO Estos son los atributos determinantes que han hecho que un paciente cambie su ubicación de la UCP a Oncología. Por otro lado, vamos a analizar las causa que han originado el cambio de Estadio partiendo de la clase 0. En este caso también debemos fijarnos en unos atributos clave que determinan el cambio de Estadio de los pacientes. Cabe decir, que la generación de datos aleatorios puede pasar factura en este caso, ya que al producirse la situación que la gran mayoría de los pacientes vayan aun Estadio en concreto (en este caso clase0) hace que el árbol C4.5 generalice en exceso y no tenga en cuenta la minoría de pacientes que tienen como destino otros Estadíos. En este caso en particular el árbol C4.5 sólo tiene en cuenta los Estadíos destino: clase 0 y clase 5, repartiendo el resto de pacientes en estas dos clases. Si se observa detenidamente la salida del sistema al mostrar el árbol de decisión puede verse entre paréntesis los pacientes asignados a cada una de las hojas (pacientes bien asignados, pacientes mal asignados). Teniendo en cuenta lo comentado en el párrafo anterior, observamos que los pacientes que parten del Estadio clase 0 sólo tienen dos destinos posibles: clase 0 y clase 5. En el caso de que el destino fuera la clase 5, estos serian los atributos que causarían ese cambio: R2: SI Apoyo_familiar = Falso Y

VAS_Debilidad <= 2 Y Morfina_Savredol-Oral <= 400

ENTONCES Clase5


60

4.4 Conclusión de las pruebas.

Las pruebas realizadas han partido de un numero de instancias de pacientes predefinida por el usuario. Todas estas instancias, en un inicio ofrecían una pobre situación para extraer conocimiento, y ha sido mediante unas técnicas elaboradas, con las que se ha podido extraer unas conclusiones claras para la ayuda a la toma de decisión. Las pruebas anteriormente vistas han demostrado que los métodos utilizados son útiles a la hora de solucionar la problemática que planteábamos en el apartado 1.1. Como hemos observado en párrafos anteriores, el análisis de los circuitos de pacientes, junto al análisis de las estructuras de decisión, han mostrado los atributos que se deben tener en cuenta a la hora de determinar la evolución de un paciente, esto permite tener una visión global de la situación de un hospital, y aporta un valor añadido a la hora de tomar una decisión. La pruebas han permitido observar el fenómeno de movilidad de los pacientes, que en el caso concreto que nos atañe hemos visto que era bastante homogéneo, mientras que en el caso de la evolución de los pacientes por los distintos Estadios no lo era tanto. Esto último se debe por un lado a la generación de datos a la que hemos tenido que recurrir por falta de datos reales, y que provoca que las evaluaciones de los pacientes sean de igual número para todos, y por otro a la poco aleatoriedad de los datos con la que se le ha dotado al algoritmo de generación para que los instancias de un mismo paciente no fueran muy diferentes entre sí (Véase Anexo 6.2).


61

Capítulo 5. CONCLUSIÓN DEL PROYECTO

5.1 Resumen del trabajo.

La idea central de este proyecto ha sido la de desarrollar una herramienta que ayude a la toma de decisión de los profesionales de un Hospital que interactúa en la Unidad de Curas Paliativas. Las bases de datos de una UCP incorporan información sobre las evoluciones de los pacientes a lo largo de los tránsitos entre deferentes emplazamientos. Cada uno de los pasos de un episodio de tratamiento contiene información básica sobre el lugar en que se encuentra el paciente (inmovilizado en domicilio, en domicilio con movilidad, en CSS, en un servicio hospitalario, en la UCP, etc.), la duración de la estancia (nº de días), la medicación que se le ha suministrado en ese periodo (fármacos y dosis), las pruebas y procedimientos recibidos por el paciente y el estado de salud medio durante la estancia. El tratamiento de un paciente desde el momento en que entra en contacto con la UCP y el momento final, está representado por un episodio asistencial que es, una secuencia de bloques de datos conteniendo información del tipo que se ha comentado en el párrafo anterior. Con este tipo de información, acumulada para todos los pacientes en un intervalo temporal significativo, se ha realizado los siguientes estudios, empleando técnicas de análisis inteligente de datos: � Detección de patrones de circuitos seguidos por los pacientes.

� Aplicación de métodos clasificatorios no supervisados para la detección de estados de paciente, si éstos son desconocidos.

� Construcción de la estructura de estados (no supervisados) de los pacientes para mostrar los cambios de estado.

� Algoritmos de construcción de estructuras de decisión (árboles, reglas, tablas) sobre la movilidad de los pacientes con el fin de prever el circuito


62

que seguirá un nuevo paciente dentro de la estructura de la que forma parte la Unidad de Curas Paliativas.

� Algoritmos de construcción de estructuras de decisión sobre la evolución de los pacientes. A partir de los estados en que se clasifican los pacientes ya tratados. Estas estructura será empleada para la previsión de evoluciones de nuevos pacientes.

� Análisis del sistema mediante pruebas con datos generados aleatoriamente.

5.2 Alcance de los objetivos marcados.

Todo trabajo debe plantearse unos objetivos a cumplir más o menos realistas, y que lleven a la consecución de unos fines buscados. El presente trabajo a tratado de alcanzar la totalidad de los objetivos marcados en la sección ¡Error! No se encuentra el origen de la referencia., y a continuación se muestra el resultado obtenido: Patrones de circuitos y Cambios de estado Este objetivo trataba de modelar las evoluciones de los pacientes, y como se ha podido observar es un objetivo plenamente alcanzado. Detección de estados de paciente Este objetivo planteaba la detección del estado de los paciente mediante métodos de clasificación no supervisados. En nuestro caso estos métodos se han materializado en el algoritmo k-means que realiza la clasificación de los pacientes de una forma no supervisada. Creación de Estructuras de decisión Este objetivo previa la incorporación de algoritmos de creación de estructuras de decisión: Árboles, reglas y tablas, partiendo de los datos que se desprendían de la consecución de los objetivos anteriores mencionados. En efecto, la creación de estas estructuras ha sido satisfactoria. Creación de una Base del Conocimiento y predicción de nuevos pacientes Una vez obtenidos las estructuras de decisión estamos en disposición de crear una Base del Conocimiento (BC). Esta BC recoge todos los datos imprescindibles para la ayuda a la toma de decisión, dispuestos de forma tal que permita realizar consultas sobre futuras evoluciones de pacientes (cambios de ubicación o cambios en su estado). Este objetivo no ha sido alcanzado, en todo caso se ha creado la estructura que podrá generar Base del Conocimiento.


63

Análisis de resultados con datos reales Una vez creada la aplicación que implemente la solución a los problemas propuestos en el apartado 1.1, se iniciará un análisis detallado de los resultados con datos reales extraídos de la Base de Datos Hospitalarios del Hospital de la Santa Creu i Sant Pau (Barcelona). Este objetivo no ha sido alcanzado, dado que no se han podido obtener esos datos reales, y por tanto su análisis ha sido imposible. Por otro lado, cabe decir que se ha creado un algoritmo que simula la generación de estos datos, aunque su naturaleza irremediablemente aleatoria ofrezca un pobre resultado desde el punto de vista médico en la fase de pruebas.

5.2.1 Conclusiones obtenidas.

Las pruebas realizadas han partido de un número de instancias de pacientes predefinida. Todas estas instancias, en un inicio ofrecían una pobre situación para extraer conocimiento, y ha sido mediante unas técnicas elaboradas, con las que se ha podido extraer unas conclusiones claras para la ayuda a la toma de decisión. Las pruebas anteriormente vistas han demostrado que los métodos utilizados son útiles a la hora de solucionar la problemática que planteábamos en el apartado 1.1. Como hemos observado en párrafos anteriores, el análisis de los circuitos de pacientes, junto al análisis de las estructuras de decisión han mostrado los atributos que se deben tener en cuenta a la hora de determinar la evolución de un paciente, esto permite tener una visión global de la situación de un hospital, y aporta un valor añadido a la hora de tomar una decisión. La pruebas han permitido observar el fenómeno de movilidad de los pacientes, que en el caso concreto que nos atañe hemos visto que era bastante homogéneo, mientras que en el caso de la evolución de los pacientes por los distintos Estadios no lo era tanto. Esto último se debe por un lado a la generación de datos a la que hemos tenido que recurrir por falta de datos reales, y que provoca que las evaluaciones de los pacientes sean de igual número para todos, y por otro a la poco aleatoriedad de los datos con la que se le ha dotado al algoritmo de generación para que los instancias de un mismo paciente no fueran muy diferentes entre sí (Véase 6.2 Anexo 2).


64

5.3 Trabajo futuro.

Dado que el presente trabajo se enmarca dentro del proyecto Palliasys [1], el trabajo futuro depende de las exigencias de este último, pero en todo caso hay que destacar diferentes actividades que si que se deberían realizar en un futuro independientemente del proyecto Palliasys: � Prueba y análisis del sistema con datos reales.

� Transformación del Sistema de Análisis Inteligente en un agente de Análisis Inteligente e integración en el sistema multi-agente Palliasys.

� Ampliación de los técnicas de minería de datos, incluyendo otras metodologías de inteligencia artificial como son las redes neuronales por ejemplo.

� Ampliación de las opciones que ofrece el sistema software desarrollado, como son la posibilidad de exportar los datos a distintos formatos como xml, excel.


65

Capítulo 6. ANEXOS

6.1 Anexo 1: Datos de Pacientes.

Nombre del Atributo Tipo Atributo

Problemas STAS

Edad numeric Sexo {H,M} Fecha numeric Dolor numeric Debilidad numeric Depresión numeric Ansiedad numeric Nauseas numeric Somnolencia numeric Apetito numeric Bienestar numeric Dificultad respiratoria numeric Sequedad boca numeric Problemas VAS Dolor numeric Debilidad numeric Depresión numeric Ansiedad numeric Nauseas numeric Somnolencia numeric Apetito numeric Bienestar numeric Dificultad respiratoria numeric Sequedad boca numeric Estreñimiento {Cierto,Falso} Insomnio {Cierto,Falso} Criterios de Complejidad Edad joven {Cierto,Falso} Personalidad adictiva {Cierto,Falso}


66

Problematica socio familiar {Cierto,Falso} Dificultad Adaptacion {Cierto,Falso} dolores dificiles {Cierto,Falso} Obstruccion intestinal {Cierto,Falso} Fallo cognitivo {Cierto,Falso} Compresion medular {Cierto,Falso} Disnea refractaria {Cierto,Falso} Hemorragias {Cierto,Falso} Angustia existencial {Cierto,Falso} Crisis deterioro rapido {Cierto,Falso} Situacion agonica {Cierto,Falso} Evalucion clinica exploraciones {Cierto,Falso} Radioterapia {Cierto,Falso} Endoscopia paliativa {Cierto,Falso} Cirugia paliativa {Cierto,Falso} Rotacion opioides {Cierto,Falso} Via subcutanea {Cierto,Falso} Bifosfonatos {Cierto,Falso} Soporte transfusional paliativo {Cierto,Falso} Indicacion estategias sedacion {Cierto,Falso} Claudicación {Cierto,Falso} Crisis deterioro rapido familia {Cierto,Falso} Gran impacto emocional {Cierto,Falso} Obstinacion terapeutica {Cierto,Falso} Negacion Desconocimiento enfoque Paliativo

{Cierto,Falso}

Tratamiento Apoyo familiar {Cierto,Falso} Control Ansiedad {Cierto,Falso} Control Depresion {Cierto,Falso} Control Dificultad Respiratoria {Cierto,Falso} Soporte Emocional {Cierto,Falso} Soporte Espiritual {Cierto,Falso} Fármacos Ibuprofeno-Intravenosa numeric Tamadol-Oral numeric Morfina Savredol-Oral numeric Valproato-Oral numeric Metilprednisolona-Oral numeric


67

6.2 Anexo 2: Algoritmo de generación aleatoria de datos

La motivación que me ha llevado a la creación de este algoritmo ha sido la necesidad de tener una serie de datos con los que poder probar la aplicación software creada en este trabajo. En un principio estos datos debían haber sido proporcionados por el Hospital de la Santa Creu i Sant Pau (Barcelona), pero por causas ajenas al autor del presente estudio finalmente estos datos no han podido formar parte del proyecto. El objetivo de esta generación de datos, es la obtención de una serie de instancias de pacientes configurables en cantidad vía programa. En un principio, el usuario marcará que número de instancias y de pacientes que desea obtener, esto no mostrará el número de evaluaciones que crearemos para cada paciente (instancias/pacientes). Una vez obtenidos los datos anteriores el algoritmo procederá de la siguiente manera: De esta manera tendremos pacientes diferentes en 30 atributos entre sí, mientras que un mismo paciente será diferente en 7 atributos por cada evaluación que realice. La introducción de información referente al ubicación de inicio también se hace aleatoriamente por cada paciente y al primero de cada evaluación.

ALGORITMO I: numero de instancias P: número de pacientes E: número de evaluaciones (I/P) L(N): Lista de pacientes generados Comenzar

N = paciente inicial (datos inicializado desde un fichero externo) Mientras instancias ≠ 0 repetir

M = N (copia del paciente inicial) Mientras evaluaciones de ≠ 0 repetir Si es la primera evaluación entonces M será 30 atributos diferente a N Fin si

M será 7 atributos diferente a M anterior

Añadir L(M) Fin mientras Fin mientras

fin


68

Capítulo 7. BIBLIOGRAFÍA

[1] Proyecto Palliasys: TIC-2003-07936. Ministerio de ciencia y tecnología. [2] A. Moreno, D. Riaño, A. Pascual, A. Valls, X. Mallafré. Sistema telemático para

la gestión de unidades de curas paliativas (2003). [3] D. Riaño, A. Moreno, A. Valls. PalliaSys: Agent-Based Palliative Care. [4] A. Moreno, A. Valls, D. Riaño. Improving palliative care with agent technology. [5] A. Valls, A. Moreno, D. Riaño, A. Pascual .Modelo de e-asistencia basado en las

tecnologías de sistemas multi-agente y análisis inteligente de datos. [6] Richard N. Shiffman. Representation of Clinical Practice Guidelines in

Conventinal and Augmented Decision Tables. 1997.

[7] J. Vanthienen & G. Wets. From Decision Table to Expert System Shells. [8] J.R. Quinlan. Induction of decision trees. Machine Learning, 1(1):81–106, 1986. [9] J.R. Quinlan. C4.5: Programs for Machine Learning. Morgan Kaufmann, San

Mateo, CA., USA, 1993. [10]P. Clark, T. Nieblett. The CN2 induciton Algorithm, October 1988.

[11] S. Microsystems, Java Native Interface Specification –

http://java.sun.com/j2se/1.4/docs/guide/jni/. SUN Microsystems, 2001. [12] Software WEKA http://www.cs.waikato.ac.nz/

SISTEMA DE ANÁLISIS DE DATOS MÉDICOS SEGÚN …deim.urv.cat/~pfc/docs/pfc339/d1117431499.pdf ·...

Documents

Transcript of SISTEMA DE ANÁLISIS DE DATOS MÉDICOS SEGÚN …deim.urv.cat/~pfc/docs/pfc339/d1117431499.pdf ·...