Sergio Santos Guerra 2º ASIR |
Medical Change PROYECTO FINAL
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 1
Índice Página
Planificación Principal 3
Requisitos Previos 4
Planificación del Contenido 5
Diseño Básico de la Base de Datos 6
Instalación del Servidor 9
Código de Base de Datos 14
Árbol de Directorios 19
Ficheros y Código 24
Posibles Actualizaciones 61
Costes 62
Resumen y Conclusiones 63
Bibliografía y documentación 64
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 2
Con la elaboración de este proyecto trato de crear una herramienta para cubrir una necesidad
que, en la gran mayoría de hospitales está obsoleta, que es el generado de turnos para los
médicos. Todo ello se utilizara mediante una interfaz web con bases de datos para el generado
de calendarios y su posterior consulta. En cuanto a la parte del usuario es simple y sencilla,
pero para el administrador es donde está toda la labor para que los trabajadores estén
contentos con el servicio.
El proceso es sencillo: un administrador genera un calendario mediante un procedimiento
almacenado donde se establecen una clase de patrones para su generado y eso se muestra al
usuario de una forma sencilla y clara. Esto es útil a la hora de tener una cantidad de
trabajadores y que ellos puedan consultar los horarios de trabajo. También está pensado y de
hecho, optimizado, para que haya un patrón de turnos en el cual:
Haya mínimo un día de descanso entre ellos
Haya unos horarios diferentes dependiendo del puesto que ocupa cada uno
Depende del horario que establezcamos, podemos generar calendarios estándares de
8, 12 o 24 horas
No haya solapamiento de usuarios, ni preferencia a la hora de ir creando los registros,
puesto que los usuarios se sacan de forma aleatoria
Hay herramientas para modificar los datos de un día, por si se ha generado mal
Dispone de un cambio de turno con un usuario por si no puede cubrir una guardia
Herramientas para modificar, insertar o eliminar guardias
También se ha generado una plataforma de gestión de incidencias para que los usuarios
puedan postear sus quejas o sugerencias para los calendarios. Así pueden dejar constancia de
que es lo que les molesta y posteriormente que se solvente.
Un administrador autorizado puede entrar en la plataforma y disponer de una amplia gama de
herramientas para solventar cualquier problema que tenga el usuario y proceder a la
resolución de dicha incidencia. La resolución se hace mediante una plataforma que envía un
correo con el estado de la incidencia.
Los usuarios aun así, pueden consultar el estado de sus incidencias en el tablón de anuncios
que tienen, donde aparece el estado de la incidencia y si hay algún comentario de algún tipo.
Los administradores tienen un panel diferente y un buscador de incidencias por usuario, para
que la navegación a través de la página sea mucho más sencilla.
También esta optimizado para que cada vez que haya una modificación en la cantidad de
médicos, véase un alta o una baja, los calendarios sean dinámicos y se actualicen con los
usuarios que existen. Así siempre serán fieles a la realidad que les atañe.
Como medidas de salvación de datos se han generado procedimientos para que se
salvaguarden los datos en backups que podemos consultar, eliminar, etc...
También se genera en un fichero externo un log de entrada al servidor con fecha y hora,
además del usuario, ip y permisos de dicho usuario, el cual podemos mostrar mediante la
herramienta de logs de entradas.
Para no sobresaturar la tabla de incidencias, cada 7 días se hace una copia de los datos de las
que hay en una tabla externa para tenerlas externalizadas e ira limpiando todas las que están
resueltas, para que solo estén las que quedan pendientes de resolver.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 3
Requisitos previos
Hemos explicado un poco el concepto de lo que sería el sistema de cálculo de turnos, así que
procedemos a explicar un poco más las herramientas que hemos usado para poder crearlo y
así llevarlo a cabo.
La aplicación está hecha con lenguaje de marcas, en este caso se muestra con el lenguaje
HTML. El sistema operativo que utilizaremos para almacenar los datos será Windows 7, ya que
es un sistema operativo funcional y practico que nos permitirá hacer los cambios que
queramos en nuestro servicio mediante una interfaz de usuario sencilla.
Para poder sacar dinámicamente los datos necesarios para poder llevar a cabo el proceso,
hemos utilizado también MySQL, todo ello montado en un servidor WAMP. Utilizare la versión
2.5 de Wamp Server, donde trabajamos con PHP 5.5 y HTML5.
Los datos se almacenan en tablas dentro de una base de datos, y para ello usaremos un
sistema gestor de bases de datos, el cual, como hemos dicho antes es MySQL. Los datos que
almacenamos y recopilamos en MySQL se mostraran dinámicamente en HTML mediante PHP,
que es un lenguaje de cara a servidores para programación. Esto nos servirá tanto para
mostrar datos, como para almacenar nuevos o modificar los existentes.
El sistema gestor de bases de datos se puede utilizar mediante la interfaz web, que es
PHPMyAdmin, o por consola y todos los datos de los ficheros que se mostraran se
almacenaran en una carpeta dentro de un directorio en un equipo.
El equipo donde se implementara el servidor Wamp será una Windows 7 con 8GB de RAM y un
procesador Intel I5 de última generación, para que su rendimiento sea el óptimo y requerido.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 4
Planificación del contenido
Una vez que tengamos el los requisitos, lo que va a hacer la aplicación y como va a funcionar,
vamos a proceder a crear lo que sería la interfaz de usuario, entre la cual diferenciaremos 3
partes:
Calendario:
Panel de administración:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 5
Menús y submenús:
Las interfaces son bastante sencillas, ya que viene la información justa y necesaria para el
usuario para que pueda acceder a los datos necesarios y poder consultar sus datos con
normalidad.
Para los administradores hay más menús y submenús, de entre los cuales hay 2 grandes:
Gestión de incidencias: En el cual podemos gestionar un problema de un calendario
del cual podremos:
o Cambiar turnos con otro usuario
o Modificar los datos de un día
o Generar un día, por si se ha eliminado
o Eliminar un día
Gestionar una incidencia modificándola o eliminándola
Gestionar las backups de los datos de anteriores calendarios
Gestión de logs de entrada al servidor
Y otro submenú donde podemos gestionar la resolución de las incidencias para enviar un
correo al usuario en cuestión.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 6
Diseño básico de la base de datos
Vamos a hacer un inciso para explicar el diseño de la base de datos, las entidades y los
diferentes atributos y relaciones que congenian en ella para crear la estructura.
Todo ello se encuentra dentro de una base de datos la cual se llamara “proyecto”.
Vamos a desglosar uno por uno los componentes, de los cuales vamos a analizar ahora las
entidades y los atributos correspondientes:
Médicos: Aquí se almacenan los usuarios que tendrán acceso al servicio, con su
nombre, su contraseña, puesto de trabajo, correo, un id identificativo además de un
nivel de privilegios (esto servirá para determinar quién puede entrar a la vista básica o
a la de administrador).
Calendarios: Mediante un procedimiento almacenado crearemos calendarios con un id
identificativo que será el día del mes, la descripción de él, que será el medico que
tendrá el servicio, la fecha_inicio para indicar cuando entra a trabajar y la fecha_fin
que determinara cuando sale.
Incidencias: Almacenaremos las incidencias conforme las vayan creando los usuarios y
aquí se almacenara un id identificativo de incidencia, el usuario al que hace referencia,
el calendario al que hace referencia, la fecha en la que ha sido creada, la fecha en la
que ha sido modificada (si lo ha sido), el problema en sí que tiene, una categoría de
otros para explicar algo más la incidencia, estado, que determinara si está resuelta,
pendiente… y comentario, para que el administrador pueda dar una razón de por qué
se ha aceptado o denegado una incidencia.
Incidencia-otra: Es una backup de la entidad incidencias, en la cual mediante un
evento posterior se hará una backup de todos los datos cada 7 días.
Temp2: Almacena los datos de la creación de un calendario para una configuración
posterior a la hora de recalcular los calendarios. En ella almacena un id especifico, el
nombre del calendario, el mes para el que se crea, el año para el que se crea y el
horario.
Temp: Es una tabla temporal en la cual se realizan cálculos matemáticos durante el
proceso de creación del calendario. Tiene un atributo que es valor, que es necesario
para cuando creemos un calendario, vaya calculando datos externos e internos.
Una vez tenemos explicadas las entidades procedemos a analizar los atributos:
Medicos:
o Id: identificador de cada medico único y exclusivo. Este nos sirve para la
verificación de datos a la hora de entrar en el sitio web
o Nombre: nombre del usuario
o Primer_Apellido: Primer apellido del medico
o Segundo_Apellido: Segundo apellido del medico
o Pass: password de cada usuario
o Puesto: puesto que desarrolla cada usuario. Dependiendo del puesto tendrá
posteriormente un tipo de turno u otro
o Correo: dirección de correo de cada usuario para el envio de incidencias
o Nivel: nivel de permisos concedidos a cada usuario
Calendarios:
o ID: identificador único de cada calendario
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 7
o Descripción: nombre del usuario que ejercerá el turno en dicho dia/registro
o Fecha_inicio: fecha de inicio del turno
o Fecha_fin: fecha de fin del turno. Ambas van en formato DATETIME
Temp2:
o Id: identificador de cada registro
o Horariocal: copia de los horarios de cada calendario.
o Aniocal: copia de los años de cada calendario
o Mescal: copia de los meses de cada calendario
o Calendario: copia de los nombres de cada calendario. Esta tabla nos sirve para
un procedimiento almacenado de comparación de los calendarios que
tenemos y los que hay aquí, y dependiendo de si existen en ambas o no se
pueden actualizar o no
Incidencias:
o ID: identificador de cada registro
o Usuario: usuario que formaliza la incidencia
o Calendario: calendario al que hace referencia la incidencia
o Fecha_creacion: fecha y hora de la creación de la incidencia
o Fecha_modificacion: fecha y hora de la modificación de la incidencia, por si ha
sido resuelta o denegada, para especificar una hora y dia
o Problema: problema que le ocurre al usuario o motivo de la incidencia
o Otro: comentarios aparte del motivo principal de la incidencia
o Estado: estado en el que se encuentra la incidencia: resuelta, denegada, etc…
o Comentario: comentario impuesto por el administrador para explicar los
motivos de la resolución de la incidencia
Incidencias-otra
o Consta de los mismos campos de incidencias, se utiliza para almacenar los
datos de incidencias cada x tiempo
Temp
o Valor: numero int que se encarga de hacer cálculos matemáticos para cuando
se crean los calendarios.
Las entidades relacionales lo que hacen es relacionar que los usuarios pueden crear
calendarios, o incidencias. En las incidencias tienen que ver el usuario, el calendario al que
hace referencia y la propia incidencia.
Cabe destacar que la entidad CALENDARIO no es estatica, sino que es dinámica. Lo que
hacemos con el procedimiento es generar un calendario extrapolando datos de la tabla de
médicos. Lo que he descrito es la estructura de la tabla que posteriormente se creara, aunque
en este caso cada vez que se genera un calendario, se genera con esa estructura.
Vamos a ver el diseño de la base de datos, el modelo de entidad relación:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 8
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 9
Instalación del Servidor Wamp
Procedemos a la instalación del servidor Wamp.
Aceptamos los términos del contrato (eso que todo el mundo se lee) y le damos a siguiente.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 10
Seleccionamos la ruta de destino donde vamos a localizar los ficheros de nuestro proyecto.
Establecemos que el servidor SMTP será localhost, ya que vamos a trabajar sobre nuestro
equipo.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 11
Procedemos a crear un icono de escritorio y continuamos.
Una vez rellenos todos los campos, le damos a instalar.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 12
Una vez que se haya instalado procedemos a ejecutarlo.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 13
Una vez este ejecutándose, ya lo tendríamos listo para funcionar. En el botón de W podemos
gestionar todas las opciones que necesitamos, como iniciarlo, pararlo, resetearlo, además de
abrir la consola de MySQL, parámetros de PHP, apache…
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 14
Código de bases de datos
En cuanto a datos que trabajara el proyecto tenemos varios procedimientos, eventos tal y
como vamos a ver ahora:
CREATE EVENT BACKUP ON SCHEDULE EVERY 7 DAY STARTS '2015-12-21 09:00:00'
DO INSERT INTO incidencias-otra select * from incidencias//
CREATE EVENT limpiezaresueltas ON SCHEDULE EVERY 7 DAY STARTS '2015-12-21 09:00:00'
DO DELETE FROM incidencias WHERE estado='resuelta'; //
Estos dos eventos se encargaran de eliminar las incidencias de la base de datos cada 7 días
para que las incidencias se guarden en una tabla externa y posteriormente otro que limpia la
tabla de las incidencias resueltas, para que solo queden las que están sin resolver.
Ahora procedemos a ver el procedimiento actualizarcampos, el cual nos servirá para, en una
de las herramientas de administración, para poder cambiar el turno de un usuario con otra
persona. Lo que hace es cambiar varios valores en un momento mediante unas sentencias.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 15
Para eliminar las backups que se van generando con los cambios que vamos haciendo, para
mantener la base de datos limpia, hemos creado un procedimiento para eliminar dichas
backups:
Este proyecto saca de la tabla de information_schema.tables saca las tablas que se llamen
parecido a backup en la base de datos proyecto. Una vez hecho crea un cursor y un bucle en el
cual va a ir eliminando cada una de las tablas que tengan coincidencias con los valores.
El proyecto se centra en un procedimiento que es el que se encarga de generar los calendarios
de forma aleatoria, llamado calculo:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 16
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 17
Este procedimiento lo que hace es:
Primero crea una tabla con el nombre que le hemos dado y una estructura
Luego inserta en la tabla temp2 los valores que hemos introducido
Establece el número de días que tiene un mes dependiendo de qué mes hayamos
cogido
Sacamos un conteo de médicos/usuarios
Establecemos una media de días/médico que le corresponden. Ejemplo, si hay 10
médicos y hay 30 días le tocaría a 3 turnos por mes a cada medico
Saca un médico al azar
Saca el puesto en el que trabaja el medico
Crea una tabla temporal en la cual se inserta un conteo en el calendario que hemos
creado (la primera vez es 0) donde el medico sea el que hemos sacado. Asi llevaremos
una cuenta de cuantas veces se ha insertado.
Se crea una sucesión de ifs anidados en la cual establece que
o Si el medico es diferente que el anterior y la cantidad de médicos es inferior a
la media entra en el if
o Dependiendo del puesto que tiene el medico se le establecen unos horarios u
otros
Todo está hecho dentro de un bucle en el cual se termina cuando llegue al final de los
días del mes.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 18
A continuación podemos ver el proyecto hacerbackup, el cual se encargara de registrar los
datos de los calendarios antes de modificarlos, para así tener un registro de todo los datos que
se tienen en la tabla. Esto es útil a la hora de cuando generemos calendarios, mantener los
antiguos por posibles incidencias. Estas backup llevan un timestamp del momento en el que se
hacen.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 19
El procedimiento de eliminar lo que hace es recalcular los datos de los calendarios. El
calendario actual lo recalcula de tal manera que a partir del dia en el que se encuentra borra
los registros hasta el final y lo que hace es insertar los registros hasta llegar al final de la
cantidad de días para asi arreglar el calendario y los demás calendarios los arregla:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 20
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 21
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 22
JavaScript
Se ha insertado algunas funciones de JavaScript para la verificación de datos a la hora de
insertar, para que no se puedan meter números:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 23
Árbol de directorios
En mi estructura he decidido hacerlo de la siguiente manera:
www
o img: aquí es donde guardamos las imágenes
o phpmailer: aquí es donde están las librerías para poder enviar correos
electrónicos
o php: aquí es donde están los ficheros que conforman la estructura
actualizar: aquí se almacenan los ficheros relacionados con actualizar
datos
backup: aquí residen los ficheros que se encargan de hacer las backups
calendarios: todo lo relacionado con la creación y modificación de
calendarios
correo: aquí están los ficheros que se encargan de enviar los correos
electrónicos a los usuarios
eliminar: dentro se encuentran los ficheros para eliminar backups,
eliminar usuarios, eliminar calendarios, etc…
incidencias: aquí guardamos todo lo relacionado con las incidencias
redirecciones: algunos ficheros tienen unas redirecciones manuales,
las cuales se almacenan aquí
usuarios: todo lo relacionado con los usuarios se almacena aqui
conexión.php: este fichero se conecta a la base de datos de MySQL
administración.php: fichero de entrada después del login
identificación.php: verifica los datos introducidos en el index.php
index.php: fichero de entrada a la página
seguridad.php: medidas de seguridad aplicadas a todos los documentos, para evitar
entrar a una ruta sin verificarse
log.txt: en este fichero se almacenan todas las entradas de usuarios, con un timestamp
salir.php: este fichero hace que se cierre la sesión y te saque al index
estilos.css, style.css y style2.css: estilos css aplicados a los ficheros
Dentro de cada carpeta se encuentran los ficheros relacionados con cada opción de la pagina,
los cuales podemos ver aquí:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 24
Aquí podemos ver el root de ficheros y de carpetas.
Aquí el contenido de la carpeta phpmailer, que es la librería para poder enviar correos.
Aquí tenemos la carpeta img donde se almacenaran las imágenes.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 25
Dentro de la carpeta de PHP tenemos las siguientes carpetas:
Los ficheros encargados de actualizar están en la carpeta actualizar.
Los que afectan a las backup y a su manipulación están en backup.
Todo lo relacionado con los calendarios, lo tenemos localizado en calendarios.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 26
Los ficheros que apuntan a PHPMAILER están en correo.
Los que se encargan de eliminar algo, están en eliminar.
Todo lo que esté relacionado con incidencias está en la carpeta de incidencias.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 27
Algunas de las redirecciones que más adelante comentaremos, están en la carpeta redirección.
Y por último, todo lo relacionado con los usuarios está localizado en la carpeta de usuarios.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 28
Ficheros y código. Demostración aplicada:
El fichero index es el encargado de darnos la entrada a la página, tal y como vemos en su
código:
Esto nos redirige al fichero identificación que comprueba si el usuario está o no en la base de
datos:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 29
Si esta autenticado, lo pasa a administración, si no, lo devuelve a index.
En administración tenemos la conexión y poco a poco ir colocando los botones para que el
resultado quede tal que así:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 30
Eso sí es usuario administrador, que si no, solo vería esto:
Aquí podemos ver donde se gestiona que si tiene x permisos puede ver unas cosas u otras:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 31
Ahora procedemos a ver como se vería la parte de calendarios. Claro está que en el código
debe de haber parte que se muestre dependiendo que permisos haya:
Dependiendo de qué permisos tenga podrá ver más o menos opciones. Si es un usuario básico
solamente podrá ver calendarios:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 32
Pero si es administrador, tendrá acceso a otras herramientas administrativas:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 33
Para generar los calendarios procedemos a ver el código para explicarlo un poco:
Con esto sacamos los datos del calendario que le pasamos y creamos un bucle con diferentes
fechas y lo que sacara cada vez que genere un cuadro. Un cuadro es equivalente a un dia.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 34
Con esto sacamos el nombre en la variable rest y hacemos varios bucles para ir igualando las
variables.
Y por ultimo, con esto, hacemos un bucle donde vamos mostrando en cada cuadro el dia, la
descripcion, la hora de inicio y la hora de fin.
El resultado es el siguiente:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 35
Si somos administradores podemos crear en el fichero calendarios.php (o apartado de
calendarios) los calendarios mediante un formulario:
Y aquí podemos ver el código que hace que muestre esto. Estos valores se pasan a un fichero
llamado formulariocrear.php donde llamaremos al procedimiento ‘calculo’.
Primero establecemos que dependiendo del mes que nos pase le daremos un día. También
cogeremos las variables pasadas por POST:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 36
Una vez hecho eso, procedemos a conectarnos a la base de datos y después a llamar al
procedimiento con las variables especificadas:
El resultado nos mostrara un mensaje de OK si funciona, o si ocurre un error.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 37
También tenemos una opción dentro para eliminar calendarios, el cual podemos ver el código
aquí:
Esto saca una consulta la cual mete en un bucle y la muestra en un select, que es el valor que
pasa por POST al fichero formularioeliminar.php
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 38
Se hace una multiquery para además de borrar el calendario, borre el valor dentro de temp2.
Esto nos ayuda a mantener la base de datos que tenemos de comparación de registros en
temp2.
Eso hace referencia al apartado de calendarios, así que vamos a explicar cómo funciona el
apartado de usuarios. Al igual que en el de calendarios, dependiendo de los permisos que
tengamos podremos ver o ver, dar de alta o de baja o modificar usuarios:
Si tenemos permisos de usuario de nivel 3 podemos ver el apartado de dar de alta usuarios, tal
y como se mostraría:
Esto nos llevara a un fichero externo donde daremos de alta al usuario:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 39
Esto es un paso importante, ya que en este paso, como en el de eliminar usuarios, hay que
hacer 3 pasos:
Hacer una backup de los calendarios que tenemos antes de insertar nada
Dar de alta el usuario
Eliminar el calendario específico y REHACERLO de nuevo. Así coge de nuevo los datos
del nuevo usuario y por lo tanto SE MANTENDRA ACTUALIZADO
Esto ocurre igual en los ficheros de actualizar datos como en el de eliminar. Los calendarios
deben ser dinámicos, y no pueden tener la misma cantidad de registro por usuario si hay 10
médicos que si hay 5, así que de esta manera mantendremos actualizados los datos.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 40
Así se mostrarían los apartados y lo que hemos puesto antes serían sus ficheros de
actualización:
Si modificamos un usuario nos llevara a un fichero donde mostraremos dentro de él los datos
que ya tiene un usuario y podremos modificarlos encima de ellos, véase un ejemplo:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 41
Tanto los usuarios básicos como los que tienen permisos de administración pueden ver los
usuarios que hay en la tabla, solo que los usuarios básicos solo pueden ver varios aspectos:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 42
Y los usuarios administrativos pueden ver más opciones:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 43
Eso se puede hacer gracias a un if comparando la sesión con un valor determinado:
Ahora procedemos a ver el panel de creación de incidencias. Dicho panel para abrir incidencias
podemos encontrarlo en los calendarios, aunque también los usuarios básicos lo tendrán en el
menú principal de estas maneras:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 44
Esto nos lleva a un formulario el cual muestro el código y como quedaría donde coge la sesión
del usuario que interpone la incidencia, le pide que escoja el calendario al que quiere ponerle
la incidencia, uno de los motivos principales y un textarea explicando el motivo:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 45
Quedaría tal que así:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 46
Una vez se interponga se creara un registro en la tabla INCIDENCIAS en la cual se almacenaran
los siguientes datos:
Usuario
Calendario
Fecha_Creacion
Problema
Otro
Estado
Esta sería la sentencia a introducir:
No está dentro de los valores el fecha_modificacion ni el comentario, ya que eso afecta a la
parte de RESOLUCION DE INCIDENCIAS.
Una vez introducida la incidencia podemos ver desde el panel principal de usuario básico la
incidencia interpuesta. Este panel es igual a todos los usuarios básicos, solo que solo muestra
las básicas por cada usuario. A cada usuario solamente le muestra las que ha interpuesto él,
para poder ver y llevar un seguimiento de cómo va su estado.
El administrador tiene una interfaz diferente en la cual puede ver las incidencias paginadas
además de un buscador de usuarios para especificar las opciones de búsqueda a un solo
usuario.
Si entramos con un usuario administrador lo veríamos de la siguiente manera:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 47
Como podemos ver, la información esta paginada para que sea más cómodo poder buscar
entre muchas de ellas, además de un buscador.
Si buscamos de un usuario específico podemos verlas así:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 48
Para buscar de un usuario específico le pasamos el usuario mediante POST y lo buscamos
mediante la siguiente consulta:
Y lo mostraríamos con una tabla que muestre los datos:
Ahora procedemos a la parte de gestión de incidencias. Las incidencias interpuestas por los
usuarios deben de ser solucionadas de alguna manera, y para ello he creado diferentes
documentos con diferentes maneras de solucionar las incidencias que ellos piden. Para ello
nos vamos al apartado de gestión de incidencias o el fichero gestionincidencias2.php
Podemos seleccionar un calendario para trabajar con él, aunque en dicha parte del documento
hay más herramientas, aunque vamos a centrarnos en arreglar los calendarios:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 49
Una vez hayamos entrado podemos hacer varias opciones, cada una con su submenú
correspondiente:
Cambiar un turno con otro usuario (se utilizara el procedimiento que anteriormente
creamos)
Modificar los datos de un día en concreto
Crear un día en especifico
Eliminar un día en especifico
Además tenemos un pequeño recordatorio de las incidencias que tenemos, para que mientras
se vayan avanzando en los menús, vayamos viendo las incidencias que tenemos:
Vamos a proceder a analizar cada una de las opciones que hemos nombrado, entre las cuales
podemos ver el cambio de turno con un usuario:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 50
Podemos ver el código aquí:
Esto lo envía a un fichero externo donde llama al procedimiento actualizarcampos, ya
mencionado anteriormente:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 51
Una vez hecho cambiaría el registro del primer campo al del segundo campo. Así obtendríamos
un cambio de turno fácil y cómodo.
Procedemos a seguir viendo las opciones que tenemos en el programa, y una de ellas es
modificar un día en específico con el apartado de modificar día:
Y aquí podemos ver el código:
Esto nos redirige a un fichero donde podemos cambiar los valores de dicho registro sobre los
valores que ya tenía.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 52
Además, contamos por si por error, se ha generado un día de más, o un día de menos,
herramientas para crear un día en especial o borrarlo:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 53
La gran mayoría de herramientas tienen un comentario para que sea más cómodo e intuitivo
para el usuario el interpretar para que sirven.
Con eso hemos podido ver para qué sirve la utilidad de seleccionarincidencia, en la cual nos
encontramos.
Procedemos a volver atrás para ver las siguientes herramientas que teníamos en
gestionincidencias2.php
Podemos tanto borrar como modificar una incidencia directamente desde ese panel. Lo que
hacen es básicamente, modificar registros de una tabla.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 54
Ahora vamos con una de las utilidades que hemos implementado que es la de leer los logs de
entrada. Como anteriormente comentamos, habíamos metido una función que creaba un
registro de las entradas al servidor junto con la hora y fecha, además del usuario, la ip y el nivel
de permisos con el que entraba en el apartado de leer logs:
Esto nos llevara al fichero leerfichero.php el cual nos mostrara el fichero y paginado, así
podremos entrar y leerlo cómodamente:
Aquí vamos a ver el código, de dónde saca el fichero y hace un conteo total de todos los
registros:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 55
De esta manera podemos avanzar por páginas y ver la información paginada y cómodamente.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 56
Uno de los inconvenientes que podemos encontrar en el cálculo es que es aleatorio, y cada vez
que se da de alta a alguien, se actualizan los datos o se da de baja se recalculan con el usuario
nuevo.
Esto genera un problema ya que si se hace el primer día del mes no pasa nada, pero si se da de
alta a alguien en la plataforma el día 19 por ejemplo otros usuarios pueden entrar y tener ya
guardias anteriores.
Para ello hemos creado un sistema de backups para que cada vez que se cree algún usuario o
se de baja o se modifiquen datos, los anteriores se almacenen y así poder usarlos para
comparar los anteriores con los nuevos.
En la misma página tenemos un botón con imagen llamado backup, el cual nos dejara mostrar
tanto las backups que hemos creado (previamente explicamos que cada vez que se hace una
alteración de la tabla de médicos, se llama a un procedimiento llamado hacerbackup).
El submenú que nos encontramos es el siguiente:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 57
Podemos consultar una backup o eliminarla. El proceso de ver un calendario backup es el
mismo que el de ver un calendario normal:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 58
La backup genera un nombre del calendario, el año, día y mes en el que se ha generado más la
hora, minuto y segundo en el que se hizo. Así podemos ver cómo van los datos que tenemos.
El proceso de eliminar las backups es para que cuando estén llenas, podamos borrarlas
manualmente:
Y con eso tendríamos el apartado de la gestión de incidencias resuelto. Con esas herramientas
somos capaces de manipular los datos que tenemos dentro de nuestros calendarios, así que
ahora toca informar al usuario cuando se ha terminado de solucionar su incidencia.
Nos vamos al botón de la llave inglesa del inicio para ir al apartado de resolución de
incidencias:
Cabe destacar que tanto la gestión como la resolución solo puede hacerlas el administrador, ya
que para el usuario básico vienen capadas.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 59
Con esta herramienta seleccionamos la incidencia, el estado que le vamos a poner y un
comentario acerca de la resolución.
Así podría ser una manera de rellenar los campos que tenemos:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 60
Cabe destacar que esto es meramente un formulario, que más tarde se relacionara con la
librería de phpmailer.
Una vez tengamos hecho esto nos llevara a una pantalla donde podremos ver y seleccionar el
correo del médico al que vamos a enviar la notificación:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 61
Una vez le demos a enviar incidencia tendríamos una notificación por correo con el estado, la
resolución de ella y el comentario, acompañado de un timestamp de tal manera:
Esto hace referencia a la librería PHPMAILER, la cual tenemos configurada de tal manera:
Aquí podemos ver que nos pasa los valores que hemos ido introduciendo mediante POST a
dicho fichero.
Para que la librería funcione hay que incluirla con el require_once.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 62
Aquí configuramos el servidor smtp junto al correo y los puertos. El receptor es el que hemos
seleccionado anteriormente.
Aquí podemos ver el cuerpo del mensaje y antes hemos visto cómo quedaría.
Una vez enviado el correo, nos devuelve al sitio donde estábamos, resolverincidencia.php
Ahora vamos con la seguridad. Hemos vinculado a todos los ficheros el include seguridad.php
en el cual si un usuario no se ha autenticado, se cierra la conexión y lo manda al index. De esta
manera evitaremos logueos de usuarios sin autenticar:
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 63
Tambien todo hay que decirlo, hemos creado diferentes estilos para nuestra pagina, uno para
el login form de entrada y otro que se utilizara para la interfaz general, style2 y estilos.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 64
Posibles actualizaciones
El calculador funciona, pero para ver que mejoras pueden ser aplicables debe de
implementarse en un entorno real y no recreado, para ver que necesidades reales tienen los
consumidores.
La versión base que tenemos de nuestro software es la 1.0, y para la versión 1.1 tenemos
pensado lo siguiente:
Un registro global de todo lo que se modifica en la base de datos
Incluir más puestos con diferentes horarios y espaciado temporal entre guardias
Intercambio de turnos sin intervención del administrador, solo entre varios usuarios
Creación de servicios diferenciados
Generado de estadísticas de guardias de un servicio en especifico
Establecer patrones para el generado automático
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 65
Costes
Dado el tiempo invertido en este proyecto, diría que se han invertido más de 40 horas, ya que
cada semana le podría echar fácil unas 30 horas, para un mes y medio que hemos echado sería
un total de 240 horas en total, más o menos.
Calculando el total de horas invertidas y de 8 euros la hora, el presupuesto estimado para la
venta del producto seria de 1920 euros.
Es una cantidad estimada, y puede ser susceptible de cambiar.
Los principales sitios de venta, o puntos de comercialización, serian hospitales, centros de
salud, ya que el programa está diseñado para este fin.
También está abierto para otras posibles zonas de comercialización y otros servicios que
requieran del programa, aunque en este caso habría que adaptarlo previamente.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 66
Resultados y conclusiones
Con el tiempo y esfuerzo hemos creado esta aplicación para la gestión de turnos para
solventar la falta de herramientas de este estilo en el ámbito médico.
Se ha logrado conseguir una herramienta sencilla, rápida y manejable que permite la creación
de calendarios y la de su mantenimiento sostenido.
Gracias a ello he aprendido bastante de lenguajes de programación, tanto PHP como retocar
algunos detalles de HTML, gracias a las horas que se le han dedicado a ello. Es una muy buena
manera de aprender un lenguaje, lo que viene siendo “pelearse” con un proyecto hasta que
acabas conquistándolo.
Gracias a ello, hemos creado una página web en la cual hemos conseguido llevar a cabo
nuestros objetivos de una manera lineal con el tiempo.
También se ha configurado exitosamente una base de datos, junto a los procedimientos,
eventos y demás para un funcionamiento de ella óptimo.
PROYECTO FINAL – SERGIO SANTOS GUERRA – MEDICAL CHANGE
SERGIO SANTOS GUERRA 67
Documentación y Bibliografía
La información que he ido sacando ha sido de diferentes puntos, de los cuales ha habido tanto
páginas oficiales de lenguajes de programación como foros:
http://php.net
http://stackoverflow.com/
http://www.joseberenguel.com/archivos/imrl/practicas/guion_pr10gpg.pdf
http://www.genbetadev.com/seguridad-informatica/manual-de-gpg-cifra-y-envia-datos-de-forma-segura
http://pastebin.com/
reddit.com Además he contado con información de apoyo gracias a mis compañeros en las prácticas, además de la información y formación que me han dado todo el departamento de informática