Disseny d’una plataforma per la gestió de dades obertes

11:24 11:24 TREBALL FINAL DE GRAU TÍTOL: Disseny d’una plataforma per la gestió de dades obertes AUTOR: Edgar Luis Díaz TITULACIÓ: Grau en Enginyeria Informàtica DIRECTOR: Xavier Masip Bruin DEPARTAMENT: Arquitectura de computadors DATA: 01/07/2014 11:24 11:24 TÍTOL: Disseny d’ una plataforma per la gestió de dades obertes COGNOMS: Luis Díaz NOM: Edgar TITULACIÓ: Grau en Enginyeria Informàtica PLA: 2010 DIRECTOR: Xavier Masip Bruin DEPARTAMENT: Arquitectura de computadors QUALIFICACIÓ DEL PFC TRIBUNAL PRESIDENT SECRETARI VOCAL DATA DE LECTURA: Aquest Projecte té en compte aspectes mediambientals:  Sí X No 11:24 11:24 TREBALL FINAL DE GRAU RESUM (màxim 50 línies) Lo que este proyecto pretende es crear una plataforma que permita la gestión y reciclaje de datos. Es decir, una plataforma que gestione los datos para un cliente y a su vez permita reciclarlos para ser reutilizados por la comunidad, para su uso masivo. Por ejemplo para la realización de estudios. Muchos de estos datos tendrán información confidencial por ello su publicación como datos abiertos se realizara limpia de datos confidenciales y de forma masiva. Como caso de uso de nuestra plataforma, realizaremos una aplicación con la colaboración del Hospital de Bellvitge. Esta aplicación capturara, de informes médicos proporcionados por el hospital, los datos necesarios para calcular el riesgo de sangrado y de reinfarto de un paciente. Este tratamiento de la información es de caràcter privado pero reaprovecharemos estos datos para generar con ellos estadísticas abiertas con las que ver que atributos afectan más o menos en el riesgo de las fórmulas. Las estadísticas como hemos comentado anteriormente se realizan de forma masiva y estarán libres de información confidencial sobre el paciente o sobre el hospital. Aprovecharemos todo esto para conocer una tecnologia para el desarrollo de webs que ofrece un gran abanico de opciones de gestión y desarrollo que cada vez esta siendo más utilizada. Esta herramienta es Drupal. Paraules clau (màxim 10): Datos Abiertos Privados Capturar Reciclaje Reutilización Masivos Estadísticas Drupal Plataforma 11:24 11:24 FINAL GRADE PROJECT ABSTRACT (50 lines maximum) This project pretends to create a platform to manage and recycle data. It means that we are going to treat a platform that will manage the data for a client, and at the same time this platform will recycle the data for the purpose that a huge group of people re-use it, for example in studies or investigations. The open data won't have confidential information and its realization will be massively. As an example about our platform, we are going to realize an application with the collaboration of the ''Hospital de Bellvitge''. This application will help us to capture the data to calculate the risk of bleeding and the risk of reinfarction of a patient, to get this we will need medical reports of the hospital. The treatment of the information is private but we are going to re-use all the data to generate open statistics, then we will see the attributes that affects in the risk of the formulas. The statistics will be done in a massively form and it will be free of confidential information about the patient and the hospital. In addition we are going to know a technology that will help us in the development of webs and will give us a lot of management options. I'm talking about Drupal, a tool that every day is more used. Keywords (10 maximum): Data Open Private Capture Recycle Re-use Massive Statistics Drupal Platform 1 1. Agradecimientos Me gustaría agradecer a mi tutor, Xavier Masip, la ayuda, la supervisión y correcciones de este proyecto. También quiero agradecer la ayuda y dedicación de la profesora Eva Marin que me ayudo a ponerme en contacto con los médicos de Bellvitge. Agradezco la colaboración e información proporcionada por los médicos del Hospital de Bellvitge y la oportunidad de trabajar para un proyecto real con ellos. Por último, me gustaría agradecer a mi familia y a mi pareja el apoyo y la ayuda que me proporcionaron a lo largo de este trabajo y a lo largo de toda mi carrera. 2 Tabla de contenido 1. Agradecimientos ................................................................................................................... 1 2. Introducción .......................................................................................................................... 4 3. Caso de uso: Aplicación para el Hospital de Bellvitge ........................................................... 5 4. Objetivos ............................................................................................................................... 7 Objetivos generales ................................................................................................................... 7 Objetivos por bloques: .............................................................................................................. 7 - Bloque de captura de datos: ............................................................................................... 7 - Bloque de tratamiento de datos: ........................................................................................ 8 - Bloque de entorno: ............................................................................................................. 8 5. Estado del arte .................................................................................................................... 10 6. Planificación ........................................................................................................................ 11 Análisis de costes .................................................................................................................... 11 Costes directos .................................................................................................................... 11 Costes indirectos ................................................................................................................. 11 Total y factor de sobrecargo ............................................................................................... 11 Análisis de riesgos ................................................................................................................... 12 Indicadores de seguimiento (KPIs) .......................................................................................... 12 Tabla de WorkPackages .......................................................................................................... 13 Pert .......................................................................................................................................... 13 Gantt........................................................................................................................................ 14 Tabla de Milestones ................................................................................................................ 14 Tabla de Deliverables .............................................................................................................. 14 7. Tecnologías .......................................................................................................................... 15 Drupal ...................................................................................................................................... 15 ¿Qué es Drupal? .................................................................................................................. 15 ¿Por qué usar Drupal? ......................................................................................................... 18 XAMPP ..................................................................................................................................... 19 ¿Qué es XAMPP? ................................................................................................................. 19 ¿Por qué usar XAMPP? ........................................................................................................ 19 8. Arquitectura de nuestra plataforma ................................................................................... 20 9. Funcionamiento de la plataforma ....................................................................................... 22 10. Proceso de desarrollo de la aplicación de nuestro caso de uso...................................... 23 Pre-desarrollo .......................................................................................................................... 23 3 Desarrollo ................................................................................................................................ 23 Post-desarrollo ........................................................................................................................ 24 11. Bloque de captura de datos ............................................................................................ 25 Análisis de los datos e informes .............................................................................................. 25 Captura de datos ..................................................................................................................... 27 Modelo de datos ................................................................................................................. 28 Funciones ............................................................................................................................ 28 Proceso ................................................................................................................................ 31 12. Bloque de tratamiento de datos ..................................................................................... 32 Pase de datos .......................................................................................................................... 32 Formulas .................................................................................................................................. 32 Action bleeding risk score ................................................................................................... 33 Mehran bleeding risk score ................................................................................................. 34 Crusade bleeding risk score................................................................................................. 34 Grace risk score ................................................................................................................... 35 Semáforos ........................................................................................................................... 36 Estadísticas .............................................................................................................................. 36 pChart .................................................................................................................................. 36 Gráficos ............................................................................................................................... 38 13. Bloque de entorno de la plataforma ............................................................................... 40 Instalación y configuración de XAMPP .................................................................................... 40 Instalación y configuración de Drupal ..................................................................................... 41 Módulos .............................................................................................................................. 42 Permisos de usuario ............................................................................................................ 42 14. De nuestro caso de uso a lo general ............................................................................... 43 15. Trabajo futuro ................................................................................................................. 44 16. Conclusiones.................................................................................................................... 45 17. Bibliografía ...................................................................................................................... 46 4 2. Introducción La reciente evolución producida en la tecnología facilita al mismo tiempo que requiere un procesado y una gestión adecuada de datos. En la actualidad los datos se presentan en gran cantidad, y son per se heterogéneos, o sea diversos formatos y diferentes fuentes, lo que hace que su procesado pueda ser una tarea altamente difícil debido a que, anteriormente, deben ser “limpiados” (tratados y/o homogeneizados), ya sea de manera previa a la utilización o durante ésta. Este proyecto pretende generar una plataforma dedicada a extraer información a partir de datos externos existentes. Si bien los datos de las aplicaciones pueden ser de cualquier temática, en este proyecto, explicaremos mediante un caso de uso de carácter hospitalario el estándar que deberían seguir las aplicaciones de esta plataforma. En el proyecto se mostrará desde la automatización de la extracción y tratamientos de información, hasta el análisis previo de los datos que queremos tratar. Es necesario mencionar que toda automatización consta de un análisis previo de los datos que se van a tratar, como por ejemplo la estructura, el formato y el contenido de los ficheros en los cuales nos viene dada la información. Este proyecto mostrará todo el “lifecycle” del proceso. La faceta de datos abiertos de nuestro proyecto pretende que la información extraída de los datos proporcionados a la plataforma no se utilice y se descarte. El objetivo es que la información se guarde en esta plataforma para que usuarios externos puedan reaprovecharla. Se podría considerar un reciclaje de información. Por ejemplo en nuestro caso de uso, que veremos en el siguiente punto, tratamos de datos médicos. Estos datos pueden proporcionar a un médico el riesgo de reinfarto de un paciente, pero pueden ayudar a otro médico a apreciar qué parámetro aumenta el riesgo de que esto suceda o dados dos parámetros calcular la relación entre ellos con fines que nada tienen que ver con temas cardiológicos. Para todo esto queremos diseñar y desarrollar esta plataforma para ir implementando soluciones para todos los ámbitos, comenzando como dijimos con una aplicación hospitalaria aprovechando que en esta mezclamos datos privados y abiertos y la colaboración del Hospital de Bellvitge que dan un valor añadido a este proyecto. Esta plataforma está pensada para su futura ampliación y extensión a todas las ramas para las cuales pueda resultar de utilidad. En resumen, los principales beneficios de la plataforma propuesta son dos: - El procesamiento automático de la información: que evita la realización de dicho procesado por parte del usuario (evita pues realizar de forma “manual” e “individual” tareas para procesar datos y extraer información). - La reutilización de la información: que los datos sean reaprovechados todo lo máximo posible por otros usuarios y con diversos fines. 5 3. Caso de uso: Aplicación para el Hospital de Bellvitge La plataforma objeto de este proyecto se plantea agnóstica a cualquier aplicación y por tanto aplicable a cualquier escenario o campo de aplicabilidad. En este proyecto, la aplicación o caso de uso, como lo llamaremos de ahora en adelante, que utilizaremos para el desarrollo conceptual de la plataforma es de carácter hospitalario. Este caso de uso está desarrollado en colaboración con el Hospital de Bellvitge y pretende ser una herramienta de utilidad para agilizar algunas de las tareas más comunes del personal médico que a día de hoy se realizan de manera manual. En el caso de uso planteado, la fuente de información serán datos clínicos. La numerosa cantidad de informes clínicos hace que analizar y tratar estos datos sea una labor repetitiva, larga y tediosa. A su vez estos datos son sensibles debido a aspectos relativos a la confidencialidad y privacidad, además de a su importancia ya que se trata de la salud de las personas y el análisis de éstos debe ser cuidadoso. Los datos clínicos recibidos como fuente, correspondientes a informes médicos de los pacientes, son recolectados a partir del informe médico. Más concretamente se desea que dado un informe médico la aplicación recolecte los datos del paciente, tanto clínicos como personales y haga un reconocimiento del riesgo de sangrado y del riesgo de reinfarto. Un factor importante para el proyecto es la diversidad de lenguaje empleado en este campo y la diversidad de expresiones para indicar un mismo dato, ya que distintos miembros del personal médico tienen diversas formas de escribir o bien usan diferentes expresiones para referirse a una misma información. Además debe también tenerse en cuenta la casuística debida a un fallo humano que produzca que una palabra se escriba incorrectamente. Debido a esta diversidad semántica, se pretende que la aplicación aprenda de la misma a medida que se vaya utilizando para que sea más precisa. Una vez hallado el riesgo de sangrado o de reinfarto el objetivo es que el médico pueda ver fácilmente qué está fallando en este paciente, motivo por el cual la plataforma también indicará los problemas que el paciente tiene y finalmente dará consejos sobre cómo tratarlos. Otro punto que se pretende en este proyecto es realizar, a partir de los datos y resultados obtenidos, pequeños estudios o estadísticas que den un valor añadido a los datos proporcionados. Estos datos serán los datos abiertos que se publicarían en la plataforma para que cualquier usuario los pueda descargar y procesar, siendo pues datos libres de información privada del paciente que sí incluirán información médica masiva. Este proyecto forma parte de una plataforma global para gestión de datos abiertos, aunque si bien muchos de los datos que tratamos en este proyecto no sean del todo abiertos, las estadísticas y estudios que se van a realizar sí lo van a ser. La aplicación presentada facilitará la creación de dos tipos de usuario: el primer tipo es usuario médico, que podrá ver toda la información tanto personal como clínica individual (datos clínicos, informes de riesgo reinfarto y de sangrado) y modificar los posibles parámetros de la aplicación; el segundo tipo es usuario común, que podrá visualizar los estudios o estadísticas realizados sobre todas las personas incluidas en la plataforma (el usuario común no tendrá acceso a datos privados del paciente). Debido a que ninguno de estos usuarios tiene porque tener conocimientos técnicos, la aplicación debe tener un uso fácil e intuitivo. La manera en la que, tanto los resultados de los 12 Análisis de riesgos Abandono del único miembro del equipo: Consecuencias: El proyecto se queda sin miembros para su desarrollo Probabilidad: Baja Impacto: Alto Solución: Buscar otro integrante para seguir adelante con el proyecto Perdida del material que contiene la plataforma: Consecuencias: Pérdida de material y de toda la plataforma Probabilidad: Baja – Media Impacto: Muy alto Solución: En caso de haber backups restaurar y en caso de no tenerlos volver a empezar Fin actualizaciones Drupal: Consecuencias: Posibles agujeros de seguridad Probabilidad: Baja Impacto: Medio o Alto si no se soluciona Solución: Migrar la plataforma a otras tecnologías Indicadores de seguimiento (KPIs) 1. Estudio de las tecnologías sobre las cuales se realizara la plataforma del proyecto Bloque de entorno 2. Interfaz para empezar a desarrollar nuestra plataforma y la aplicación Bloque de entorno 3. Informe análisis de los datos proporcionados en los informes médicos Bloque de captura de datos 13 4. Captura de los datos de los informes Bloque de captura de datos 5. Resultado fórmulas de reinfarto y sangrado Bloque de tratamiento de la información 6. Estadísticas con los datos proporcionados Bloque de tratamiento de la información 7. Interfaz usable, estética y segura Bloque de entorno Tabla de WorkPackages Como el equipo solo está compuesto por un solo miembro y hay 12 semanas tenemos 12 PW para repartir entre los diferentes workpackages. WP # Nombre Semana inicio Semana fin PW 0 Planificación y diseño 1 12 1 1 Análisis de datos 2 10 3 2 Bloque de captura de datos 3 10 3 3 Bloque de tratamiento de datos 7 12 3 4 Bloque de entorno 1 12 1 5 Validación 10 12 1 Pert WP0 Planificación y diseño WP4 Entorno WP1 Análisis de datos WP2 Captura de datos WP5 Validación WP3 Tratamiento de datos 14 Gantt 1 2 3 4 5 6 7 8 9 10 11 12 Planificación y diseño D Análisis de datos M D Captura de datos M D Tratamiento de datos M D Formulas Estadísticas Validación D Entorno M M D Como podemos ver el tiempo es muy apretado y muchas tareas se tienen que validar y crear paralelamente. Los milestones son tratados como puntos necesarios para desarrollar otras tareas y los diliverables como entregas finales de estas. Tabla de Milestones Bloque Descripción Semana Análisis de datos Estructura del fichero para empezar a capturar datos 5 Captura de datos Algunos campos para empezar a tratar estos 7 Tratamiento de datos Algunas fórmulas resueltas para la estética de los resultados 10 Entorno Interfaz para empezar el desarrollo 3 Entorno Interfaz con la aplicación integrada 6 Tabla de Deliverables Bloque Descripción Semana Planificación y diseño Memoria escrita del proyecto 12 Análisis de datos Informe desglosado en todos los campos necesarios a importar localizados 10 Captura de datos Todos los datos del bloque anterior capturados 10 Tratamiento de datos Todas las formulas pedidas por los médicos y estadísticas con valor añadido a los informes 12 Validación Comprobación de que las formulas den correctamente su resultado 12 Entorno Facilidad de uso en las tareas de los anteriores bloques 12 15 7. Tecnologías En este punto detallaremos las tecnologías externas de las que hace uso este proyecto. El uso de tecnologías externas en este proyecto es un punto importante debido a que el aprendizaje de estas tecnologías puede ser útil tanto para este proyecto como para proyectos posteriores. Drupal La primera y principal tecnología de la que hablaremos es la herramienta más importante del proyecto y es sobre la que se desarrolla. Esta herramienta es Drupal. ¿Qué es Drupal? Drupal es un gestor de contenido altamente configurable y modular. Su licencia es GNU/GPL, es decir, permite al usuario usar, estudiar, modificar y distribuir el software. Esta licencia ayuda a varios desarrolladores a generar contenido para Drupal como módulos (que más adelante explicaremos), lo cual permite y facilita la existencia de una comunidad de desarrollo detrás de Drupal. Está escrito en php y es combinable con MySQL. Esta herramienta ayuda al desarrollador a gestionar el contenido de la página web proporcionando una estructura a la hora de su desarrollo. La principal característica de Drupal es que permite la generación de páginas web de tipo dinámico, es decir, las páginas se cargan a partir de la información de una base de datos ya que ésta no está alojada de forma predeterminada. La página se genera a partir de la base de datos por cada petición que realiza el usuario. Este tipo de página tienen la ventaja de que se pueden actualizar más fácilmente que una estática, por lo tanto, la inserción de nuevas aplicaciones a la plataforma no supondrá una gran dificultad. A continuación veremos una primera aproximación de algunos conceptos generales de Drupal: - Módulos (modules): Son extensiones de Drupal que proporcionan funcionalidades extra. Existen módulos de dos tipos: los del core de Drupal, que son los módulos propios de Drupal que ofrecen las funcionalidades principales de este, y los módulos de contribuyentes, que son módulos que ofrecen funcionalidades extra a las principales y que están desarrollados por la comunidad de Drupal. Por ejemplo, podemos ver módulos para realizar backups, para generar URLs o para ver la web con la visión de otro usuario estando en el rol e desarrollador. Estas herramientas son muy útiles a la hora de gestionar y administrar nuestra página web. Más adelante veremos una explicación más detallada de estos módulos, de cómo funcionan y de cuales nos interesan para nuestro proyecto. - Nodos (nodes): Son una unidad de contenido que puede ser por ejemplo una página, un artículo o un tema en un foro. Cada nodo tendrá sus propiedades como su id, su título, su fecha de creación, su body, así como otras propiedades. Algunas de estas propiedades dependerán de los módulos que estemos usando en ese momento. 16 - Comentarios (comments): Son otro tipo de unidades de contenido. Estos comentarios los envían los usuarios y están relacionados con un nodo concreto. Por ejemplo, comentarios en un tema de un foro. - Taxonomía (taxonomy): Es la herramienta de clasificación de contenido que ofrece Drupal. Es uno de los módulos del core y de los más importantes si se quiere gestionar grupos de contenido. Funciona por grupos de palabras o “vocabularios” donde cada grupo puede pertenecer a diferentes tipos de contenido. Este, como el concepto anterior, es más usado en foros o páginas con artículos de diferente temática y no en páginas como la que se plantea en este proyecto. - Usuarios y roles (users and roles): Representa al usuario de la página. Sus propiedades son nombre, contraseña, rol, email y otras posibles propiedades que se pueden añadir mediante módulos. A estos usuarios se les puede añadir permisos en función de su rol. Los usuarios anónimos al acceder a la página lo hacen con ID 0 mientras los registrados lo hacen con ID 1. - Regiones y bloques (regions and blocks): Las regiones son las divisiones de una página, generalmente: cabecera, pie, laterales y sección principal de contenido. En estas regiones se muestra contenido, ya pueden ser visualizaciones de módulos, menús o información proporcionada por el usuario. Este contenido recibe el nombre de bloque. - Menús: Los menús son regiones donde se proporcionan links para ir a diferentes rincones de nuestra web u ocasionalmente a sitios externos a ella. En Drupal existen varios tipos de menú: - Menú de administrador: este menú solo está disponible para administradores y ofrece las diferentes herramientas de desarrollo con las que podemos trabajar. - Menú principal: Este menú está realizado por los administradores del sitio. Es el que se muestra en la cabecera de nuestra página y enlaza con los principales sitios de la web. - Menú de navegación: Normalmente contiene enlaces proporcionados por los módulos de nuestra página. - Menú de usurario: Contiene un link a la cuenta del usuario y uno al logout. - Menús personalizados: Además de todos los anteriores Drupal permite crear nuestros propios menús, tantos como queramos, para colocarlos en las diferentes regiones de nuestra página web. - Plantillas (themes): Las plantillas, o temas, indicarán como se visualiza el contenido, los colores, el diseño, es decir todo lo relacionado con las estética de nuestro sitio. Se componen de varios php, XHTML así como de diferentes archivos CSS definiendo diferentes estilos. Drupal ofrece unos estilos predeterminados pero el usuario puede realizar los suyos propios partiendo de cero. 17 - Vistas (views): Permite al usuario generar listas de nodos y mostrarlos por ejemplo en forma de página o de bloque. Esto puede ser útil a la hora de por ejemplo generar un bloque con últimas noticias. - Base de datos (database): En Drupal la información se almacena en una base de datos. En esta base de datos existen tablas para los diferentes tipos de información. Por ejemplo los nodos tienen su propia tabla con su información básica, los usuarios, comentarios, roles y demás ajustes también tienen sus propias tablas. Estas tablas son generadas automáticamente por Drupal. - Path: Cuando se visita un sitio desarrollado en Drupal la parte que viene después de la dirección base de nuestro sitio web es lo que se denomina path. Por ejemplo, en ejemplo.com/node/223, el path seria node/223. Esto es lo que Drupal envía a la base de datos para recuperar la información que debe mostrar al usuario. Estos conceptos pretenden dar una vista general de las principales piezas que forman Drupal y comenzar a conocerlo un poco más. Esto no quiere decir que en este proyecto utilicemos todas estas características aunque sí algunas. A continuación veremos un esquema de la estructura de capas que siguen los sitios desarrollados por Drupal: 1) En la base nos encontramos con los nodos y demás contenido que antes que nada se deben introducir como datos. 18 2) En la segunda capa tenemos los módulos de los cuales hablamos anteriormente y que ofrecen funcionalidades extra a las del propio Drupal y que pueden ser generados tanto por personas de forma individual como por grandes corporaciones. Se pueden encontrar en un repositorio proporcionado por Drupal o desarrollarlos nosotros mismos. 3) En esta capa encontramos los bloques y menús. Los bloques en general muestran la salida de algún módulo, que aunque puede mostrar cualquier tipo de información, puede ser mostrada solo a determinados usuarios y solo en determinadas páginas. Estos bloques como vimos anteriormente pueden ser colocados en cualquier región de la página. Los menús son lo que nos permite navegar por nuestra página y también pueden colocarse en cualquier región. 4) La siguiente capa es la capa de permisos. Esta capa es la que permite a los usuarios ver, generar o editar el contenido a través de roles y permisos. 5) En la capa superior tenemos las plantillas o temas. Aquí se define la “piel” de nuestra página. Algunos temas pueden contener funciones que sobrescriban a las funciones estándar de algunos módulos para ofrecer un mayor control sobre cómo estos generan su salida. Con esto hemos visto una visión general de como es Drupal tanto en conceptos como en estructura. Hemos visto que nos permite generar un sitio web potente con una estructura sólida que nos permite en todo momento configurar todos los detalles de este. ¿Por qué usar Drupal? Los motivos por los cuales hemos decidido crear nuestra plataforma en Drupal es: - Desarrollo en php: php es un lenguaje flexible, ideal para páginas web y que ofrece un gran abanico de funciones. Este será el lenguaje de programación con el que desarrollaremos nuestra plataforma. - Compatible con MySQL: Compatible con uno de los SGBD más potentes además de ser libre. Este será el SGBD utilizado en el desarrollo de nuestra plataforma. - Flexibilidad y robustez: Drupal nos ofrece una gran libertad a la hora de desarrollar webs. Podemos desarrollarla como si de un sitio web común se tratara en php y después aplicar la estructura vista en el punto anterior para ofrecer robustez a nuestro sitio web. - Módulos: Los módulos permiten gestionar nuestra página web de forma sencilla. Como hemos visto anteriormente hay módulos para todo tipo de gestión que van desde crear backups a gestionar más eficientemente los permisos de usuario. - Agregar contenido: Gracias a que Drupal genera sitios webs dinámicos no tenemos que entrar en el directorio y crear los ficheros necesarios para nuestro sitio web cada vez que añadamos a nuestra plataforma una aplicación. Bastará con generar un nodo que permita registrar otros nodos de forma automática, cosa que Drupal nos permite. Con esto finalizamos el apartado sobre Drupal habiendo visto de forma general como es su estructura y por qué hemos escogido Drupal como entorno de desarrollo. Más adelante explicaremos más detalladamente algunos puntos conforme vayamos necesitándolos en nuestro proyecto. 19 XAMPP La segunda tecnología de la que hablaremos en este proyecto es XAMPP. ¿Qué es XAMPP? XAMPP es un conjunto de herramientas ideal para servidores web. Incorpora en un solo programa gran parte de los requisitos de un servidor web. Las herramientas que incorpora están nombradas en su nombre formando el acrónimo XAMPP. Estas herramientas son: - X: Sistema operativo de la versión de XAMPP: Esto más que una herramienta es un requisito (WAMPP para Windows, LAMPP para Linux). - A: Apache: Servidor web http de código abierto. - M: MySQL: SGBD de código abierto. - P: PHP: Interprete de lenguaje de programación PHP. - P: Perl: Interprete de lenguaje de programación Perl. ¿Por qué usar XAMPP? Como podemos ver XAMPP contiene todo lo necesario para desarrollar nuestra plataforma. Tiene un servidor Apache donde subir nuestra web de la plataforma, un SGBD MySQL que como comentamos anteriormente es el que usaremos en este proyecto y un intérprete de PHP que como también dijimos será el lenguaje de programación en el que desarrollaremos nuestro proyecto. 20 8. Arquitectura de nuestra plataforma En este apartado del proyecto veremos la arquitectura de nuestro sistema. Nuestro sistema se compone de dos tipos de máquinas: - Máquina servidor: Es la máquina que hospedará tanto nuestra plataforma como las aplicaciones que formen parte de ellas. Además de sus respectivas bases de datos, tanto de la plataforma como de las aplicaciones. - Máquina cliente: Estas máquinas son las que pueden ejecutar nuestra plataforma vía web. Estas máquinas no necesitan nada aparte de un navegador y conexión a Internet o a la red local de la máquina servidor. A continuación veremos un esquema que ilustra la arquitectura general de nuestro sistema: Base de datos plataforma Máquina servidor Aplicación Hospital Bellvitge Aplicación 2 Base de datos Aplicación Aplicación 1 Máquina cliente Base de datos Aplicación Máquina cliente Plataforma Máquina cliente 21 Nuestra plataforma está diseñada para que siga este esquema, pero puede darse el caso que alguna aplicación o alguna base de datos se conecte de forma externa a nuestra plataforma. Por ejemplo una aplicación de procesamiento de datos donde parte de los datos queramos mantenerlos en nuestra plataforma para su posterior gestión y otra parte la queramos en una base de datos local en la maquina cliente donde sólo queramos consultar datos. 28 El principal objetivo de este bloque es extraer los datos de los informes para proporcionarlos al bloque de tratamiento de datos. Los datos a extraer son los mencionados arriba y cómo hemos podido ver algunos datos presentan mayor dificultad para ser extraídos que otros. Para la extracción de estos datos necesitaremos un modelo de datos y unas funciones que detallaremos a continuación. Modelo de datos En una aplicación destinada a la extracción y tratamiento de datos el modelo de datos es un punto muy importante. En este punto veremos cómo y qué datos debemos almacenar en nuestra base de datos y como debe estar diseñada esta. La base de datos de esta aplicación contara con cuatro tipos de tablas: - Tablas de datos médicos: En estas tablas se guardaran los datos que interesen para las formulas además del número de historia clínica. De estas es de donde sacaremos los datos a tratar. Más adelante los datos abiertos serán extraídos de estas tablas de forma masiva. Los datos serán introducidos en su mayor parte a partir de los informes y resultados de fórmulas. - Tabla de datos personales: Esta tabla debe ser una tabla privada en la que solo tengan acceso los médicos debido a que el contenido es confidencial al tratarse de la información personal de los pacientes. Los datos serán introducidos en su mayor parte a partir de los informes y fórmulas. - Tablas de diccionarios: Este conjunto de tablas proporcionaran un apoyo a la aplicación. En estas tablas se guardarán diccionarios de sinónimos con los que buscar los datos debido a la cantidad de sinónimos que pueden ser utilizados en los imformes. Por ejemplo la tabla diabetes contendrá entre otras palabras: diabetes, diabético y DM2. Los datos serán introducidos generalmente a mano por los médicos. El hecho que sean introducidos a mano se debe a la dificultad de aprendizaje en algunas palabras que no tienen nada que ver por ejemplo: diabetes -> DM2 o sodio -> Na. - Tabla de negación: Esta es similar a una tabla de diccionario con la diferencia que en esta se guardan expresiones para negar algo. En esta tabla sí que es posible introducir cierto aprendizaje. Más adelante explicaremos el funcionamiento de estas negaciones. Funciones A continuación veremos las principales funciones de este bloque. Estas funciones están divididas en funciones principales y funciones de apoyo. Las funciones principales son las que tratan a los diferentes apartados del informe médico para extraer los datos. Las funciones de apoyo son las que permiten que esto sea posible de manera indirecta por ejemplo corrigiendo una palabra. Funciones principales - tratamiento_exploracion_fisica($string): Debido a que los datos de la exploración física son todos semidirectos en esta función devolveremos un array con el valor y las unidades de cada uno de los datos de este apartado. Esta función busca y trata tanto valores como unidades 29 para devolver un resultado limpio. El parámetro de entrada es un string que contiene el apartado exploración física. - busca_XXXXX($string): Esto más que una función es un conjunto de funciones que explicaremos de forma general ya que todas tienen la misma estructura. En estas funciones se buscan datos que tengan valor numérico y se devuelve tanto el valor numérico como las unidades. Los datos devueltos ya han sido tratados y están listos para ser usados. El parámetro es el apartado donde se desee buscar el dato. Las funciones pueden variar ligeramente en función del dato a buscar por cada función se carga, de la base de datos, el diccionario correspondiente al dato a buscar. - busca_palabra($string, $text): Devuelve -1 si no se encontró la palabra o expresión y en el caso de que se encuentre devuelve en qué posición. Esta función tiene en cuenta errores ortográficos con una función que explicaremos en funciones de apoyo. Los parámetros introducidos son: $string = expresión a buscar, $text = apartado donde buscarla. Esta función se utiliza para datos que son de Sí/No. - busca_negación($string, $text, $expressions): Esta función va atada a la función de arriba y se utiliza para buscar una negación. Si la función busca_palabra encuentra la expresión se utilizara esta para ver si la expresión esta negada. Los parámetros de la función son: $string = expresión a negar, $text = frase donde buscar la expresión y $expressions = array con las expresiones de negación (cargado de la tabla expresiones de negación). Esta función tiene en cuenta la posición de la palabra o expresión a negar en relación a la expresión de negación: - Si el número de saltos de la expresión de negación a la expresión a ser negada es 2 o menos (no manifiesta diabetes): Negamos la expresión. - Si el número de saltos es mayor a dos comprobamos si se hace referencia a nuestra expresión o a otra y se nos preguntara si hace referencia o no: - No hace referencia a la nuestra (no manifiesta cardiopatías pero manifiesta diabetes): Marcamos no y la expresión no será negada. - Hace referencia (no manifiesta síntomas de diabetes): Marcamos que sí y la expresión quedara negada y la expresión de negación se guardara en la tabla de expresiones de negación desde la expresión de negación inicial (no) a la expresión a negar (diabetes) la próxima aparición se trataría: no manifiesta síntomas de diabetes (salto menos a dos por lo tanto se negaría automáticamente). - Si no aparece negación: La expresión no se niega Funciones de apoyo Estas son las funciones que utilizan las funciones principales para ayudarse. - multiexplode($string, $delimitadores): Esta función divide un texto a partir de un array con las expresiones que delimitan sus apartados. Sus parámetros son: $string = texto y $delimitadores = array con todos los delimitadores). 30 - tratamiento_ef_valor($string): Separa los valores numéricos de las unidades para la función tratamiento_exploracion_fisica. - Levenshtein($string1, $string2): Este es un algoritmo conocido que explicaremos en un subapartado propio. Distancia de Levenshtein Este algoritmo se merece un apartado aparte por su popularidad y su uso en programas de similitud entre dos cadenas, como es el caso de los correctores ortográficos, en programas de reconocimiento de voz o sistemas de detección de plagios. La función de este algoritmo es encontrar la similitud entre dos palabras A y B. Esto se hace a partir de los cambios que sufre la palabra A para convertirse en la palabra B. Entendemos como cambios: inserción, eliminación o sustitución de un carácter. A continuación veremos cómo funciona el algoritmo de Levenshtein a partir de una matriz de similitud de palabras: Las reglas para la matriz son: - Primero se numeran las letras de la palabra en su fila o columna dando como resultado la matriz inicial y rellenando el resto a 0. El resultado es el siguiente. C A S A 0 1 2 3 4 C 1 0 0 0 0 O 2 0 0 0 0 S 3 0 0 0 0 A 4 0 0 0 0 - A continuación miramos para cada posición matriz [i][j] si las letras que coinciden son iguales o distintas: - Si son iguales: matriz[i][j] = min(matriz[i][j], matriz[i-1][j], matriz[i][j-1]) - Si son distintas: matriz[i][j] = min(matriz[i][j], matriz[i-1][j], matriz[i][j-1]) + 1 - Matriz final: C A S A 0 1 2 3 4 C 1 0 1 2 3 O 2 1 1 2 3 S 3 2 2 1 2 A 4 3 2 2 1 31 El valor de la casilla final es la distancia de Levenshtein y es el número de operaciones que debemos realizar a casa para transformarla en cosa. Esta operación sería un intercambio entre O<->A. Esta función en nuestra aplicación será usada para detectar los errores escritos por los médicos. Tenemos que tener en cuenta que debe haber una longitud mínima para que la función trabaje correctamente. Proceso Una vez vistas las funciones vamos a ver un esquema de como es el proceso de captura de datos. Para ello mostraremos un esquema de cómo funciona. Este esquema es el bloque de captura de datos del diagrama de flujo del apartado “Funcionamiento de la plataforma” de este proyecto. En el siguiente esquema los * indican flechas múltiples. La función BuscaXXXXX será la correspondiente a cada dato a capturar. Este esquema representa como los datos son extraídos desde el informe médico hasta convertirse en datos usables. Los datos que no se consiguen mediante el siguiente esquema o los datos a corregir serán introducidos por un formulario HTML. * * * Exploración física * MultiExplode Informe médico texto Antecedentes Exploración complementaria … BD: Dicc. XXXXX Busca XXXXX Levenshtein Dato MultiExplode Dato sin tratar Tratamiento Exp. Física Tratamiento valor EF Conversión Informe médico PDF 32 12. Bloque de tratamiento de datos Una vez extraídos los datos necesarios de los informes médicos procederemos a tratarlos. En este apartado veremos dos muestras de cómo tratar los datos. La primera es enfocada a los médicos, esta trata en calcular las fórmulas que nos pidieron en el Hospital de Bellvitge. La segunda es la que proporcionara los datos abiertos de nuestra plataforma, trata de unas estadísticas masivas con los datos médicos de los pacientes. Antes que nada veamos cómo se pasan los datos de la página php de captura de datos a la página php de tratamiento de datos. Pase de datos En nuestro sistema tenemos varios bloques y entre ellos y entre diferentes páginas php se requiere del pase de datos. Este pase se hace mediante las sesiones de php. En las páginas php que se requiera el paso de variables por sesión se pondrá al comienzo del código la función session_start(). Con esta función abrimos la sesión y ya podemos acceder a la variable automatic global $_SESSION y esta estará disponible en cualquier parte del script. Para utilizar esta variable en otra página a la que nos direccionemos solo tenemos que abrir sesión en la nueva página y tendremos tanto la variable como los valores asignados anteriormente. La variable $_SESSION es un array y para usar esta solo es necesario darle valor de la siguiente manera: $_SESSION[“nombre_de_variable”] = valor. Por ejemplo $_SESSION[“Edad”] = 89. Una vez visto como recuperamos los datos capturados anteriormente veamos cómo utilizar estos para calcular las formulas y estadísticas. Formulas En este apartado veremos las formulas a calcular para el riesgo de sangrado y de reinfarto. Las fórmulas vistas a continuación actuaran como funciones en este apartado. Cada fórmula será representada como una función y el resultado de la función será el resultado final de la fórmula. Estas fórmulas serán implementadas directamente en el php en una página encargada de su cálculo. Esta página php será el recuadro “Bloque de tratamiento de datos” del diagrama de flujo del apartado Funcionamiento de la plataforma. Como hemos mencionado anteriormente estas fórmulas han sido proporcionadas por el Hospital de Bellvitge y pretenden ser una guía de si el paciente corre riesgo o no de reinfarto o 33 sangrado. Para ello se necesitan varias fórmulas y las variables extraídas anteriormente. Este es el objetivo principal de la aplicación para el Hospital de Bellvitge es calculo y resultado de estas fórmulas. En las formulas detalladas a continuación se asignan valores a las variables que participan en la formula en función al peso que ejercen en la formula y a su valor y después se realiza un sumatorio de estas. A continuación detallaremos las formulas a calcular: En el apartado variables recalcularemos el valor de estas variables a partir del valor original asignando un índice con el peso adecuado para el cálculo de la formula. Por lo general indicaremos un intervalo de valores que tienen que tomar las variables indicadas y a continuación seguido del símbolo “=” el nuevo valor de la variable. Action bleeding risk score Variables Edad: Menor de 50 = 0, entre 41 y 50,99 = 1, entre 51 y 60,99 = 2, entre 61 y 70,99 = 3, entre 71 y 80,99 = 4, entre 81 y 90,99 = 5 y 91 o mayor = 6. Creatinina en mg (normalmente viene dada en mmol/l para realizar la conversión Creatinina en mg = Creatinina mmol / 88.49): Menor de 0,7999 = 0, entre 0,8 y 1,5999 = 1, entre 1,6 y 1,999 = 2, entre 2 y 2,999 = 4, entre 3 y 3,999 = 6, eentre 4 y 4,999 = 8, entre 5 y 5,999 = 10 y 6 o mayor = 11. Presión sistólica: Menor de 90 = 4, entre 91 y 100 = 3, entre 101 y 120 = 2, entre 121 y 140 = 1, entre 141 y 170 = 0, entre 171 y 200 = 1 y mayor a 201 = 2. Hemoglobina (en g/dl muchas veces nos lo encontramos en g/l): Menor de 5 =17, entre 5,001 y 7,99 = 15, entre 8 y 9,99 = 13, entre 10 y 10,99 = 12, entre 11 y 13,99 = 11, entre 14 y 15,99 = 6 y 16 o mayor = 2. Frecuencia cardíaca: Menor de 40 = 0, entre 41 y 60 = 2, entre 61 y 70 = 3, entre 71 y 80 = 5, entre 81 y 100 = 6, entre 101 y 110 = 8, entre 111 y 120 = 9, entre 121 y 130 = 11, entre 131 y 150 = 12 y 151 o mayor = 14. Peso: Menor a 50 = 5, entre 51 y 70 = 4, entre 71 y 100 = 3, entre 101 y 120 = 2, entre 121 y 140 = 1 y 140 o mayor = 0. Género: Si es mujer = 4 y si es hombre = 0. Anticoagulantes: Si toma = 2 si no = 0. Diabetes: Si tiene = 2 si no = 0. Vasculopatía periférica: Si tiene = 3 si no = 0. Killip: I = 0, II = 3, III, 3 y IV = 15. Electrocardiograma: Si ECG = 0 y no hay elevación del segmento ST = 0, si no si hay elevación del segmento ST = 7 y si no = 3. 34 Formula La fórmula no es más que la suma de los diferentes pesos de las variables. Action bleeding risk score = Edad + Creatinina en mg + Presión sistólica + Frecuencia cardíaca + Peso + Género + Anticoagulantes + Diabetes + Vasculopatía + Killip + Electrocardiograma + Hemoglobina Esta fórmula indica el riesgo de sangrado. Mehran bleeding risk score Variables Edad: Menor de 49.99 = 0, entre 50 y 59,99 = 3, entre 60 y 69,99 = 6, entre 70 y 79,99 = 9 y 80 o mayor = 12. Sexo: Si es mujer = 8 si es hombre = 0. Creatinina en mg: Menor de 0,99 = 0, entre 1 y 1.1999 = 2, entre 1,2 y 1, 399 = 3, entre 1,4 y 1,599 = 5, entre 1,6 y 1,799 = 6, entre 1,8 y 1,999 = 8 y 2 o mayor 10. Leucocitos: Menor de 9999 = 0, entre 10000 y 11999 = 2, entre 12000 y 13999 = 3, entre 14000 y 15999 = 5, entre 16000 y 17999 = 6, entre 18000 y 19999 = 8 y 20000 o mayor = 10. Anemia: Si es hombre y tiene menos de 13 de hemoglobina o Si es mujer y tiene menos de 12 de hemoglobina = 6 si no = 0. Elevación del segmento ST en el electrocardiograma: Si tiene = 6 si no = 2. Tratamiento con bivalirudina: Si tiene = -5 si no = 0. Formula Esta es otra fórmula para calcular el riesgo de sangrado. Mehran bleeding risk score = Edad + Sexo + Cretinina en mg + Leucocitos + Anemia + Elevación del segmento ST + Tratamiento con bivalirudina. Crusade bleeding risk score Variables Hematocrito: Menor de 30,99 = 9, entre 31 y 33,99 = 7, entre 34 y 36,99 = 3, entre 37 y 39,99 = 2 y 40 o mayor = 0. Frecuencia cardiaca: Menor de 70 = 0, entre 71 y 80 = 1, entre 81 y 90 = 3, entre 91 y 100 = 6, entre 101 y 110 = 8, entre 111 y 120 = 10 y 121 o mayor = 11. Presión sistólica: Menor de 90 = 10, entre 91 y 100 = 8, entre 101 y 120 = 5, entre 121 y 180 = 1, entre 181 y 200 = 3 y 201 o mayor = 5. Killip: I = 0 y II o mayor = 7. Vasculopatía: Si tiene vasculopatía periférica o accidente vascular cerebral = 6. 35 Diabetes: Si tiene = 6 si no = 0. Clearance hombre = ((140 – Edad) * Peso) / (Creatinina en mg * 72). Clearance mujer = Clearance hombre * 0,85 Clearance: Si es mujer = clearance mujer y si es hombre = clearance hombre. Clearance: Menor de 15 = 39, entre 15 y 30 = 35, entre 30 y 60 = 28, entre 60 y 90 = 17 entre 90 y 120 = 7 y 120 o mayor = 0. Género: Si es mujer = 8 si es hombre = 0. Formula Esta es la última formula de riesgo de sangrado. Crusade bleeding risk score = Hematocrito + Clearance + Frecuencia cardiaca + Genero + Killip + Vasculopatía + Diabetes + Presión sistólica Grace risk score Variables Edad: Menor de 29,9 = 0, entre 30 y 39,9 = 8, entre 40 y 49,9 = 25, entre 50 y 59,9 = 41, entre 60 y 69,9 = 58, entre 70 y 79,9 = 75, entre 80 y 89,9 = 91 y 90 o mayor = 100. Frecuencia cardiaca: Menor de 50 = 0, entre 50,1 y 69,9 = 3, entre 70 y 89 = 0, entre 90 y 109 = 15, entre 110 y 149 = 24, entre 150 y 199 = 38 y 200 o mayor = 46. Presión sistólica: Menor de 79,9 = 58, entre 80 y 99 = 53, entre 100 y 119 = 43, entre 120 y 139 = 34, entre 140 y 159 = 24, entre 160 y 199 = 10 y 200 o mayor = 0. Creatinina en mg: Menor de 0,39 = 1, entre 0,4 y 0,79 = 4, entre 0,8 y 1,19 = 7, entre 1,2 y 1,59 = 10, entre 1,6 y 1,99 = 13, entre 2 y 3,99 = 21 y 4 o mayor = 28. Killip: I = 0, II = 2, III = 39, IV = 59. Fibrilación ventricular: Si tiene = 39 si no = 0. Marcadores: Si hay elevación de troponina o creatincinasa = 14 si no 0 Electrocardiograma: Si es 2 = 3 si es 3 = 28. Formula Esta es la fórmula de reinfarto. Grace risk score = Edad + Frecuencia cardiaca + Presión sistólica + Creatinina en mg + Killip + Fibrilación ventricular + Marcadores + Electrocardiograma 36 Con estas fórmulas calcularemos un indicador que nos dirá cuanto de alto es el riesgo del paciente de padecer sangrado o reinfarto. Como hemos podido ver en las formulas anteriores los indicadores varían el peso en función de la importancia de la variable en la fórmula. Una vez calculadas las formulas se podrán guardar los datos médicos correspondientes en la base de datos para su uso en las estadísticas. Semáforos Una vez calculadas las formulas se mostrarán todos los datos en una tabla. Al lado de estos datos se mostrará un semáforo que indicara si el parámetro corre riesgo alto (rojo), riesgo intermedio (naranja) o riesgo leve/nulo (verde). Si el resultado final de la fórmula indica un riesgo leve pero alguno de los parámetros sale alterado el semáforo se pondrá en naranja para indicarlo. Estadísticas Dado que en este proyecto se busca el reciclaje de datos para la gestión de datos abiertos, una manera interesante de reciclarlos es utilizándolos masivamente en estadísticas. La ventaja de esto es que al introducir datos en la plataforma se actualizan estas estadísticas, mostrando así las estadísticas actualizadas. Hay que mencionar primero que los datos masivos estarán libres de información confidencial de los pacientes y/o del hospital. Para ello deberemos tener una base de datos como la mencionada en los apartados anteriores donde almacenar los datos médicos que mostraremos. Para realizar estas estadísticas necesitaremos una librería de php que ofrezca herramientas para generarlas. pChart pChart es una librería para php que permite la generación de gráficas para mostrar estadísticas. Esta librería se encuentra bajo licencia GPL. Esta librería solo requiere las librerías OpenGL para su funcionamiento. A continuación veremos un esquema de cómo funciona esta librería sacado de la propia web de pChart. 37 Como podemos ver una vez inicializado el objeto de la clase pChart y pData el proceso de generación de un gráfico consta de tres partes: 1) Preparación de los datos para ser usados. Estos datos pueden provenir de diferentes fuentes como una base de datos o un fichero CSV. En nuestro caso vendrán de una base de datos. 2) Preparar el gráfico con sus diferentes propiedades como la escala o el fondo. Una vez indicados estos se dibuja el gráfico. 3) Para finalizar se le añade la leyenda y el título y se finaliza el gráfico. Una vez generado el gráfico se puede mostrar en la web o exportar en un fichero de salida. Nosotros siempre mostraremos nuestro gráfico vía web. A continuación veremos un ejemplo de cómo generar un gráfico vía php con esta librería. <?php // Includes de las classes pData y pChart include("pChart/pData.class"); include("pChart/pChart.class"); // 1) Añadimos los datos $DataSet = new pData; $DataSet->AddPoint(array(0,1,2,3,4), "serie1"); $DataSet->AddPoint(array(9,8,7,5,0), "serie2"); $DataSet->AddAllSeries(); $DataSet->SetAbsciseLabelSerie(); $DataSet->SetSerieName("Primera","serie1"); $DataSet->SetSerieName("Segunda","serie2"); $DataSet->SetYAxisName("Eje Y"); $DataSet->SetYAxisUnit("unidades"); // 2) Inicializamos el grafico indicando los atributos del area de dibujo y de grafico $Test = new pChart(800,300); $Test->setFontProperties("Fonts/tahoma.ttf",8); $Test->setGraphArea(70,30,680,200); $Test->drawFilledRoundedRectangle(7,7,693,223,5,240,240,240); $Test->drawRoundedRectangle(5,5,695,225,5,230,230,230); $Test->drawGraphArea(255,255,255,TRUE); $Test->drawScale($DataSet->GetData(),$DataSet- >GetDataDescription(),SCALE_NORMAL,150,150,150,TRUE,0,2); $Test->drawGrid(4,TRUE,230,230,230,50); // 2) Dibuja un grafico de líneas indicando sus atributos $Test->drawLineGraph($DataSet->GetData(),$DataSet- >GetDataDescription()); $Test->drawPlotGraph($DataSet->GetData(),$DataSet- >GetDataDescription(),4,1,255,255,255); // 3) Finalizamos el grafico $Test->setFontProperties("Fonts/tahoma.ttf",8); 44 15. Trabajo futuro Hasta este punto hemos visto el alcance de nuestro proyecto pero lo que pretende este proyecto es generar una plataforma donde no solo se gestionen informes médicos, si no que sea ampliable a cualquier tipo de datos. El trabajo futuro que queremos conseguir a partir de este proyecto es que la plataforma que aquí detallamos crezca y que aparezcan diferentes aplicaciones sobre diferentes temáticas y estudiar cómo hacer para que los datos sean tan útiles para la persona que quiere tratarlos, es decir su uso privado, como para las personas que buscan información sobre estos, es decir convertirlos en datos masivos abiertos. Es decir, con este proyecto pretendemos incentivar el reciclaje de datos como trabajo futuro. 45 16. Conclusiones En este apartado veremos las conclusiones finales de nuestro proyecto. Para empezar en este proyecto hemos demostrado que podemos extraer datos abiertos de cualquier tipología de datos, incluso de los datos más sensibles, como son los datos médicos. Hemos observado que automatizar el proceso del tratamiento de la información es beneficioso tanto para el propietario como para la comunidad, si este proceso se hace de manera que los datos sean reutilizables. También hemos realizado una plataforma que permite esta reutilización de datos y permite consultar estos datos masivamente con datos actuales y reales a la vez que ofrece a un cliente unos cálculos que necesitaba automatizar. También hemos aprendido a aprovechar el conocimiento adquirido en el transcurso de la carrera para realizar un proyecto real con un cliente real como son los médicos del Hospital de Bellvitge. Este factor ha dado un valor añadido a este proyecto al ver que el conocimiento adquirido durante los estudios es aplicable en un proyecto real. En este proyecto hemos utilizado los conocimientos adquiridos durante la carrera. Conocimientos de administración de sistemas operativos y de redes, para las instalaciones y configuraciones de XAMPP y Drupal debido a la gestión de permisos de usuarios de las carpetas y detectar los errores causados por estos permisos en la instalación de Drupal y a la configuración de algunos elementos de XAMPP tanto e forma automática como manual directamente de fichero. Hemos utilizado los conocimientos adquiridos en la asignatura optativa Programación multiplataforma y distribuida, en el conocimiento del lenguaje HTML y en CSS y el apartado visual de la plataforma. Otra asignatura que nos ha resultado de gran utilidad es Proyectos de tecnologías de la información que nos ayudó en la planificación de este proyecto. Y las asignaturas de programación donde adquirimos soltura con los diferentes lenguajes de programación y nos enseñó a adaptarnos a los diferentes lenguajes de programación. Y en general todas las asignaturas, que nos enseñaron a aprender a buscarnos la vida y a aprender a aprender, cosa fundamental en el campo de la informática. Gracias al transcurso de esta carrera en este proyecto hemos sido capaces de aprender tecnologías nuevas y de utilizarlas para brindar una solución a un problema real. Y la oportunidad de realizar este proyecto con un cliente concreto nos ha enseñado a como es tratar con un cliente, como diseñar la aplicación enfocada a sus necesidades y a tener reuniones e intercambios de correos para especificar detalles de la plataforma. En resumen, y para acabar, este proyecto me ha enseñado a ver que el conocimiento adquirido durante la carrera tiene aplicación real y que los datos, sean de la temática que sean, siempre se pueden reutilizar para un bien común. 46 17. Bibliografía Drupal – Open Source CSM [Web en línea] <www.drupal.org> [Consulta: Marzo – Junio 2014] Drupal Hispano | Comunidad de usuarios de Drupal [Web en línea] <www.drupal.org.es/> [Consulta: Marzo – Junio 2014] pChart | a PHP Charting library [Web en línea] <pchart.sourceforge.net> [Consulta: Junio 2014]