Download Raúl Mateos - DEIM (URV)

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
PROYECTO FINAL DE CARRERA
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
1
PROYECTO FINAL DE CARRERA
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
2
PROYECTO FINAL DE CARRERA
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.
3
PROYECTO FINAL DE CARRERA
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.
4
PROYECTO FINAL DE CARRERA
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 multiagente 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
5
PROYECTO FINAL DE CARRERA
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.
6
PROYECTO FINAL DE CARRERA
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.
INGRESO
ALTA
TRATAMIENTO
EPISODIO
Figura 2. Episodio de un paciente
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.
7
PROYECTO FINAL DE CARRERA
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).
8
PROYECTO FINAL DE CARRERA
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.
9
PROYECTO FINAL DE CARRERA
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
10
PROYECTO FINAL DE CARRERA
•
•
•
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.
11
PROYECTO FINAL DE CARRERA
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.
12
PROYECTO FINAL DE CARRERA
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.
13
PROYECTO FINAL DE CARRERA
A continuación se describen los tipos de datos que podemos encontrar dentro
de la Base de Datos:
Datos de los pacientes:
•
•
Datos de la asistencia clínica prestada en cada posible ubicación (UCP, CSS o
domicilio).
•
•
•
•
•
•
•
•
•
Datos personales, como el nombre, dirección, teléfono, etc.
Datos familiares, como el número de hijos, la situación familiar, trabajo,
etc.
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.
14
PROYECTO FINAL DE CARRERA
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
15
PROYECTO FINAL DE CARRERA
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.
9
F
B
21
12
C
5
20
4
2
A
4
2
17
E
7
15
D
Figura 4. Grafo conexo, dirigido y etiquetado.
16
PROYECTO FINAL DE CARRERA
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.
17
PROYECTO FINAL DE CARRERA
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
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
18
PROYECTO FINAL DE CARRERA
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:
19
PROYECTO FINAL DE CARRERA
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.
20
PROYECTO FINAL DE CARRERA
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.
21
PROYECTO FINAL DE CARRERA
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 para 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
1
del atributo clasificador en los registros de S
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
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
22
PROYECTO FINAL DE CARRERA
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
Función
C4.5
(R: conjunto de atributos no clasificadores,
C: atributo
clasificador,
El algoritmo
del método
C4.5 para la construcción de árboles de decisión a
S: conjunto de entrenamiento) devuelve un árbol de decisión;
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.
Comienzo
Si S está vacío entonces
Devolver un único nodo con Valor Falla;
Si todos los registros de S tienen mismo valor para 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
1
atributo clasificador en los registros de S
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
1
Tabla 3. Algoritmo C4.5
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.
23
PROYECTO FINAL DE CARRERA
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.
24
PROYECTO FINAL DE CARRERA
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
C1 El paciente tiene seguro médico básico
C2 El paciente tiene seguro social
A1 Pagar la consulta
A2 Exento de pago
A3 Pagar todos los servicios
Reglas de decisión
1
2
4
SI
NO
NO
SI
NO
X
X
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).
25
PROYECTO FINAL DE CARRERA
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.
26
PROYECTO FINAL DE CARRERA
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) :
DB
Wrapper
Data
Analyser
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
27
PROYECTO FINAL DE CARRERA
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.
28
PROYECTO FINAL DE CARRERA
DB
Wrapper
Data Analyser
Datos de los pacientes
Registro clínico: Paciente 1
Registro clínico: Paciente 1
Clasificación de los pacientes
detección de estados
de paciente
con K-Means
Paciente 1: Estadío 1
Paciente 1: Estadío 2
Registro clínico: Paciente 2
Paciente 2: Estadío 3
Registro clínico: Paciente 3
Paciente 3: Estadío 2
Registro clínico: Paciente 3
Grafo de Circuitos
Paciente 3: Estadío 4
Grafo de Estados
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).
29
PROYECTO FINAL DE CARRERA
Grafo de Estados
Grafo de Circuitos
Árbol decisión C4.5
Reglas
Tabla de Decisión
Condición
Reglas de decisión
Condiciones Entrada de Condiciones
Acciones Entrada de Acciones
R1: Si .... entonces
R2: Si .... entonces
R3: Si .... entonces
R4: Si .... entonces
R5: Si .... entonces
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.
Nuevo Paciente
Estructura de Decisión
Actuación
Figura 9. Proceso de decisión sobre un paciente.
30
PROYECTO FINAL DE CARRERA
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
31
PROYECTO FINAL DE CARRERA
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 periodo de
tiempo).
G(N,M): grafo vacío: N = ∅ , M = ∅ , donde N es una lista
de nodos_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
32
PROYECTO FINAL DE CARRERA
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:
P1
Paciente
P1
P1
P2
P2
P3
P4
P4
Servicio Partida
UCP
CSS1
UCP
CSS2
HOME
HOME
UCP
Servicio Destino
CSS1
CSS2
CSS2
CSS1
CSS1
UCP
HOME
CSS1
CSS2
P2
P1
P3
P2
UCP
P4
P4
HOME
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
33
PROYECTO FINAL DE CARRERA
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:
Evaluaciones
P1
P1
E0
P2
E0
P3
E0
E1
E2
E2
E3
E4
P1
E4
E1
Exitus
E4
P2
P2
P1
P2
E3
E0
E3
E2
P3
P1
EXITUS
P3
Exitus
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
34
PROYECTO FINAL DE CARRERA
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:
Á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.
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
35
PROYECTO FINAL DE CARRERA
á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.
36
PROYECTO FINAL DE CARRERA
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.
Condiciones
Apoyo familiar
Disnea refractaria
VAS Depresión
MorfinaSavredolOral
STAS Apetito
Edad joven
CSS3
HOME
CSS1
ONCO
CARDIO
CSS2
Reglas de decisión
Cierto
Cierto
<= 1
<= 100
X
Cierto
Cierto
<= 1
> 100
-
Cierto
Cierto
> 1
-
Cierto
Falso
<= 5
-
X
X
Cierto
Falso
> 5
-
Falso
Falso
<= 5
-
Falso
> 5
Cierto
Falso
> 5
Falso
X
X
X
X
X
Figura 14. Ejemplo Tabla de Decisión.
37
PROYECTO FINAL DE CARRERA
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.
38
PROYECTO FINAL DE CARRERA
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.
39
PROYECTO FINAL DE CARRERA
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.
40
PROYECTO FINAL DE CARRERA
Figura 16. Nuevo Proyecto.
Figura 17. Datos generados.
41
PROYECTO FINAL DE CARRERA
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 KMeans 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ú.
42
PROYECTO FINAL DE CARRERA
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).
43
PROYECTO FINAL DE CARRERA
Figura 20. Circuito de Pacientes.
Figura 21. Circuito de Estadios.
44
PROYECTO FINAL DE CARRERA
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.
45
PROYECTO FINAL DE CARRERA
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.
46
PROYECTO FINAL DE CARRERA
Figura 24. Reglas de Producción.
Figura 25. Tabla de Decisión.
47
PROYECTO FINAL DE CARRERA
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.
48
PROYECTO FINAL DE CARRERA
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.
49
PROYECTO FINAL DE CARRERA
Figura 28. Guardar Proyecto.
Figura 29. Abrir Proyecto.
50
PROYECTO FINAL DE CARRERA
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.
51
PROYECTO FINAL DE CARRERA
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.
52
PROYECTO FINAL DE CARRERA
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.
53
PROYECTO FINAL DE CARRERA
Seguidamente vamos a mostrar dos de ellos: un árbol de Servicios y uno de
Estadios (figuras 32 y 33).
Á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
Figura 32. Árbol de Decisión (Servicio Partida UCP)
Á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)
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.
54
PROYECTO FINAL DE CARRERA
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.
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 34. Reglas de Producción (Servicio Partida UCP)
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
Figura 35. Reglas de Producción (Estadio Partida Clase0)
55
PROYECTO FINAL DE CARRERA
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.
Figura 36. Tabla de Decisión (Servicio Partida UCP)
Figura 37. Tabla de Decisión (Estadio Partida Clase0)
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.
56
PROYECTO FINAL DE CARRERA
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).
10
6
CSS2
9
18
CSS3
13
CSS1
8
6
UCP
8
8
7
9
12
9
6
12
11
10
9
6
HOME
8
CARDIO
14
6
ONCO
8
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:
57
PROYECTO FINAL DE CARRERA
29
15
Clase3
38
Clase2
Clase4
1
2
1
Clase0
16
22
3
6
Clase1
23
Clase5
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
58
PROYECTO FINAL DE CARRERA
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
59
PROYECTO FINAL DE CARRERA
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).
60
PROYECTO FINAL DE CARRERA
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
61
PROYECTO FINAL DE CARRERA
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.
62
PROYECTO FINAL DE CARRERA
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).
63
PROYECTO FINAL DE CARRERA
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.
64
PROYECTO FINAL DE CARRERA
Capítulo 6. ANEXOS
6.1 Anexo 1: Datos de Pacientes.
Nombre del Atributo
Problemas STAS
Edad
Sexo
Fecha
Dolor
Debilidad
Depresión
Ansiedad
Nauseas
Somnolencia
Apetito
Bienestar
Dificultad respiratoria
Sequedad boca
Tipo Atributo
numeric
{H,M}
numeric
numeric
numeric
numeric
numeric
numeric
numeric
numeric
numeric
numeric
numeric
Problemas VAS
Dolor
Debilidad
Depresión
Ansiedad
Nauseas
Somnolencia
Apetito
Bienestar
Dificultad respiratoria
Sequedad boca
numeric
numeric
numeric
numeric
numeric
numeric
numeric
numeric
numeric
numeric
Estreñimiento
Insomnio
{Cierto,Falso}
{Cierto,Falso}
Criterios de Complejidad
Edad joven
Personalidad adictiva
{Cierto,Falso}
{Cierto,Falso}
65
PROYECTO FINAL DE CARRERA
Problematica socio familiar
Dificultad Adaptacion
dolores dificiles
Obstruccion intestinal
Fallo cognitivo
Compresion medular
Disnea refractaria
Hemorragias
Angustia existencial
Crisis deterioro rapido
Situacion agonica
Evalucion clinica exploraciones
Radioterapia
Endoscopia paliativa
Cirugia paliativa
Rotacion opioides
Via subcutanea
Bifosfonatos
Soporte transfusional paliativo
Indicacion estategias sedacion
Claudicación
Crisis deterioro rapido familia
Gran impacto emocional
Obstinacion terapeutica
Negacion
Desconocimiento
Paliativo
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
enfoque {Cierto,Falso}
Tratamiento
Apoyo familiar
Control Ansiedad
Control Depresion
Control Dificultad Respiratoria
Soporte Emocional
Soporte Espiritual
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
{Cierto,Falso}
Fármacos
Ibuprofeno-Intravenosa
Tamadol-Oral
Morfina Savredol-Oral
Valproato-Oral
Metilprednisolona-Oral
numeric
numeric
numeric
numeric
numeric
66
PROYECTO FINAL DE CARRERA
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:
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 Manterior
Añadir L(M)
Fin mientras
Fin mientras
fin
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.
67
PROYECTO FINAL DE CARRERA
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/
68