EntregaV5 - Final Release

.
setneilc sol ed sacinlc sairotsih ed nicartsinimda rojem anu smeda y ;sonrut y selanoiseforp ed dadilibinopsid ed nicartsinimda rojem anu smeda y ;sonrut y selanoiseforp ed dadilibinopsid ed nicartsinimda rojem anu smeda y ;sonrut y selanoiseforp ed dadilibinopsid ed nicartsinimda rojem anu smeda y ;sonrut y selanoiseforp ed dadilibinopsid nges enilno seduticilos ed svart a ,socidm sortnec sonaidem y soeuqep nges enilno seduticilos ed svart a ,socidm sortnec sonaidem y soeuqep nges enilno seduticilos ed svart a ,socidm sortnec sonaidem y soeuqep nges enilno seduticilos ed svart a ,socidm sortnec sonaidem y soeuqep sol arap setneicap ed adazilartnec nitseg al revomorp atnetni amrofatalp aL sol arap setneicap ed adazilartnec nitseg al revomorp atnetni amrofatalp aL sol arap setneicap ed adazilartnec nitseg al revomorp atnetni amrofatalp aL sol arap setneicap ed adazilartnec nitseg al revomorp atnetni amrofatalp aL
Docentes:
Integrantes del equipo:
HABILITACION PROFESIONAL
Mara Gimena Conde
Federico Jos Botti
Nombre y Apellido
Sistema de Gestin de
Solanas, Alberto
Gonzlez, Gerardo
Puyol, Mara Elisa
Grupo03 K-4071 Ao 2008
Pacientes
119046-5
120810-0
Legajo
Curso/ Grupo
Grupo 03
K-4071
gime_conde@yahoo.com.ar
federicojbotti@yahoo.com.ar
e-mail
Sistema de gestin de pacientes
Versin
5.0
Proyecto
1558920753
1555980033
VERSION 1.0
Telfono 10/11/2009
Fecha
Pgina 1 de 70
Curso/ Grupo
Proyecto
K-4071 Grupo 03 HABILITACION PROFESIONAL

Versin Fecha
5.0
10/11/2009
Historial de Revisiones
Fecha 28/08/2008 01/09/2008 15/09/2008 29/09/2008 06/10/2008 08/10/2008 20/10/2008 03/11/2008 Versin 0.5 1.0 2.0 2.5 3.0 3.5 4.0 4.2 Descripcin Definicin de Tareas Primera entrega Especificacin de requisitos Estudio de Factibilidad Anlisis del sistema Especificacin de Casos de Uso DER y UML Autor Grupo03 Grupo03 Grupo03 Grupo03 Grupo03 Grupo03 Grupo03
Se agregan diagramas de actividades y Grupo03 se completa introduccin.
10/11/2008 10/11/2008
4.5 5.0
Se agrega descripcin de diagramas Manual de Usuario
Grupo03 Grupo03
Pgina 2 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Tabla de Contenidos
1. INTRODUCCIN ..............................................................................................................................................5 1.1 1.1.1 1.1.2 1.1.3 1.2 2. OBJETIVOS, ALCANCES Y LMITES ................................................................................................................5 Objetivos ..................................................................................................................................................5 Alcances...................................................................................................................................................6 Lmites .....................................................................................................................................................7 DEFINICIN DEL MODELO DE CICLO DE VIDA ..............................................................................................7
PLANIFICACIN..............................................................................................................................................9 2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 CRONOGRAMA DE ACTIVIDADES: GANTT....................................................................................................9 DEFINICIN DE ACTIVIDADES......................................................................................................................11 Inicio......................................................................................................................................................11 Relevamiento..........................................................................................................................................11 Estudio de Factibilidad..........................................................................................................................11 Planificacin..........................................................................................................................................12 Anlisis ..................................................................................................................................................13 Diseo....................................................................................................................................................13 Implementacin......................................................................................................................................14
3.
ANLISIS .........................................................................................................................................................14 3.1 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.3 3.3.1 ANLISIS DE REQUISITOS............................................................................................................................14 Introduccin...........................................................................................................................................14 Identificacin de mdulos......................................................................................................................15 Especificacin de requisitos ..................................................................................................................15 ESTUDIO DE FACTIBILIDAD .........................................................................................................................23 Estudio de Mercado ...............................................................................................................................23 Factibilidad Tcnica ..............................................................................................................................24 Factibilidad Operativa ..........................................................................................................................26 Factibilidad Econmico-Financiera......................................................................................................28 Conclusin de Factibilidad....................................................................................................................29 ARQUITECTURA ..........................................................................................................................................29 Definicin de incrementos: mdulos......................................................................................................30
Pgina 3 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
3.3.2 3.4 3.4.1 3.4.2 4.
Arquitectura...........................................................................................................................................30 CASOS DE USO ............................................................................................................................................34 Diagramas de Casos de Uso..................................................................................................................35 Especificacin de Casos de Uso ............................................................................................................37
DISEO .............................................................................................................................................................44 4.1 4.1.1 4.1.2 4.2 U.M.L.........................................................................................................................................................45 Pedido tpico al servidor Web................................................................................................................45 Diagramas de Actividades .....................................................................................................................46 D.E.R..........................................................................................................................................................50
5.
MANUAL DE USUARIO.................................................................................................................................51 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.2 5.2.1 5.2.2 5.2.3 INSTALACIN ..............................................................................................................................................51 Breve resea ..........................................................................................................................................51 Requisitos...............................................................................................................................................51 Restore de la base de datos....................................................................................................................52 Instalacin de aplicacin.......................................................................................................................53 Listo .......................................................................................................................................................53 DESCRIPCIN GENERAL DE SISTEMA ...........................................................................................................53 Login......................................................................................................................................................53 Home......................................................................................................................................................56 Salir del Sistema ....................................................................................................................................66
6. 7.
GLOSARIO.......................................................................................................................................................67 BIBLIOGRAFA ..............................................................................................................................................68 7.1 7.2 7.3 APLICACIN ................................................................................................................................................68 HARDWARE.................................................................................................................................................68 MODELADO .................................................................................................................................................69
8.
ANEXOS............................................................................................................................................................70 8.1 ANEXO I: MODELO HISTORIA CLNICA .....................................................................................................70
Pgina 4 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
1. Introduccin
A lo largo de la historia el hombre se fue desarrollando para poder satisfacer sus necesidades de la mejor manera posible, procurando realizar el menor esfuerzo. Una de las necesidades primarias del hombre es su salud y por ello el inters hacia este proyecto. Para que el hombre pueda mantener su salud, requiere de especialistas que sepan atenderlo y adems, que puedan asistirlo de la mejor manera posible, tanto en beneficio de la salud del paciente como para el beneficio del profesional. Es por esto y gracias a la falta de organizacin y estandarizacin de un proceso para la atencin de los clientes en pequeos y medianos centros mdicos, nos encontramos en un problema muy grave. Teniendo en cuenta el xito que significara un producto open source aplicable a los centros mdicos de menos recursos y, centrndonos en pequeas y medianas empresas, surge la necesidad y la oportunidad de una plataforma que integre de manera eficaz la gestin de los pacientes. De esta manera se pretende satisfacer una necesidad social imprescindible como lo es la mejor atencin en cuanto a centros de salud se refiere, generando un beneficio tanto para las pymes como para sus clientes, con la posibilidad de extender dicho proyecto a centros asistenciales del estado.
1.1 Objetivos, Alcances y Lmites

1.1.1 Objetivos
El proyecto tiene como principal objetivo proveer a los consultorios mdicos de un sencillo y poderoso sistema open source para la organizacin eficiente de los pacientes, core del negocio de dichos establecimientos. Se busca que a travs de este sistema muchos consultorios puedan eliminar el ya obsoleto sistema de fichas utilizados, centralizando toda la informacin en formato digital en uno o varios servidores previendo el respaldo de la informacin. Esto permitir acceder a la informacin requerida en tiempo real, conociendo el estado de pacientes, calendario, citas, historias clnicas desde cualquier parte del mundo con el nico requisito de disponer de conexin a internet. Pgina 5 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Adems se asegura el desarrollo en un marco orientado a la seguridad y confidencialidad de los datos tal, que slo los usuarios autorizados podrn acceder a la informacin de paciente: historia clnica, historial de consultas, diagnsticos, etc. Por ejemplo: Los mdicos podrn acceder a un listado detallado de las consultas, diagnsticos y historia clnica del paciente previo a la consulta y desde cualquier lugar del mundo para estar al tanto de la problemtica con suficiente antelacin.
1.1.2 Alcances
Se centraliza la informacin de cada usuario, pudiendo acceder desde cualquier parte del mundo en tiempo real y de forma segura (Encriptacin SSL). El sistema contempla cuatro clases de usuario o roles: mdicos, secretarias, pacientes, administrador de la plataforma. Estos roles tendrn permisos diferentes sobre cada uno de los mdulos de la plataforma. El sistema contemplar la calendarizacin de las consultas mdicas mediante una interfaz Web, poniendo a disposicin de los pacientes los horarios, turnos y profesionales disponibles. Los pacientes podrn realizar el pedido de turno va esta misma interfaz, siempre y cuando se hayan debidamente registrado en el sistema y previamente logueado. Luego de la primer consulta se mantiene el registro de lo acontecido en cada turno mdico, manteniendo actualizada y a disposicin del paciente su historia clnica. Desde el punto de vista del mdico se registran todos los pacientes atendidos, centralizando en una estructura de base de datos las historias clnicas de los pacientes atendidos. Esto facilita las futuras consultas por parte del paciente, ya sea con el mismo profesional u otro del mismo consultorio. Existir un mdulo de estadsticas de toda clase: tiempo de atencin, cantidad de pacientes atendidos por mdico, ranking de consultas ms comunes, entre otros. La idea con este mdulo es que sirva como base para la toma de decisiones para mejorar la atencin de los Pgina 6 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
pacientes.
1.1.3 Lmites
No se contemplarn las urgencias mdicas. El sistema est pensado para pequeos y medianos centros de atencin a pacientes con lo cual si bien, la arquitectura ser altamente escalable, se analizarn los mdulos estrictamente necesarios. Al final del documento que presentaremos pondremos un breve apartado especificando ms en detalle posibilidades de escalabilidad de la plataforma. La plataforma estar desarrollada con la tecnologa orientada a objetos, lo que hace que sea fcilmente extensible y escalable. La autenticacin y la carga de permisos y roles podra estar definida en un servidor LDAP, previamente instaurado, y se podra autenticar a los usuarios contra esos sistemas preexistentes. Esto no se contemplar en este proyecto.
1.2 Definicin del Modelo de Ciclo de Vida

El proyecto se llevar a cabo teniendo en cuenta un modelo incremental prototipado no desechable. Teniendo en cuenta que las necesidades del usuario no son estticas y debido al poco conocimiento del negocio, tendremos un acercamiento continuo con el cliente para validar los avances y, de ser necesario, redefinir requisitos. Esto justifica el modelo incremental donde cada tarea es considerada un incremento en el desarrollo del proyecto, y donde los requisitos pueden ser redefinidos en etapas posteriores al relevamiento. La eleccin del prototipado no desechable se basa en dos ideas: La tecnologa a utilizar es relativamente nueva y la curva de aprendizaje de dichas herramientas es inicialmente empinada. Esto generar la necesidad de capacitacin del personal involucrado en el proyecto. Para absorber las modificaciones que surjan por parte de cliente en forma efectiva y para validar en forma iterativa la interfaz de la aplicacin web. Pgina 7 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Pgina 8 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
2. Planificacin
2.1 Cronograma de actividades: GANTT
Pgina 9 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Pgina 10 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
2.2 Definicin de actividades

2.2.1 Inicio
Definicin de objetivos, alcances y lmites: Especificar minuciosamente cada uno de estos puntos para poder definir y delimitar el trabajo a realizar. Definicin y eleccin del ciclo de vida: De esta manera sabremos la manera en la que llevaremos a cabo el proyecto.
2.2.2 Relevamiento
Primer acercamiento al cliente con el objetivo de conocer a fondo el negocio y as definir los requerimientos. Anlisis de requisitos. Analizaremos en profundidad aquellos requerimientos solicitados por el cliente, especificando a fondo y planteando dudas que vayan surgiendo para poder saciarlas en prximos encuentros. Validacin y verificacin de requisitos con el cliente .Una vez estudiado los requisitos se proceder a validar y verificar la informacin obtenida y poder consultar las dudas existentes. Especificacin de requisitos: Realizar una especificacin detallada de cada uno de ellos Confeccin y entrega de documento de especificacin del sistema: Confeccionar por escrito un documento para que queden asentados los requerimientos. Podremos remitirnos a l durante todo el proceso y compararlo contra el proyecto.
2.2.3 Estudio de Factibilidad
Luego de tener los requisitos debidamente especificados, se proceder a realizar el estudio de la factibilidad pertinente. ste consta del anlisis de la capacidad tcnica, operativa y econmico-financiera que se requiere para llevar a cabo el proyecto. El estudio intenta definir y poner de manifiesto la infraestructura requerida para dar soporte al desarrollo, anlisis de los perfiles de RRHH que debern intervenir, as como tambin analizar Pgina 11 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
cual ser el impacto del producto en el mercado.
Estudio de Mercado: Analizaremos el contexto en el que se sita el proyecto: la competencia, la factibilidad de lanzar el producto, los clientes potenciales, las ventajas competitivas del producto, etc. Factibilidad Tcnica: Consiste en realizar una evaluacin de la tecnologa existente, sobre los componentes tcnicos y la posibilidad de hacer uso de los mismos en el desarrollo e implementacin del sistema propuesto. Adems se analizarn los requerimientos tecnolgicos que deben ser adquiridos para el desarrollo y puesta en marcha del sistema en cuestin. Factibilidad Operativa: se desarrollar teniendo en cuenta principalmente los RRHH con los que cuento para llevar a cabo el proyecto. Se realizar un anlisis riguroso de los conocimientos tcnicos que deben tener las personas involucradas. De ser necesario se deber pensar en capacitaciones o en adquirir mano de obra calificada para cubrir los puestos requeridos.
Factibilidad Econmico-Financiera: Analizar los gastos en los que debe incurrir la organizacin para llevar a cabo el proyecto y su posterior mantenimiento en productivo. Adems analizar si los recursos econmicos y financieros necesarios para desarrollar las actividades pueden ser cubiertos segn la posicin financiera de la organizacin, en particular segn el capital con el cuenta. Confeccin de documento de estudio de factibilidad: Confeccionaremos por escrito un documento con el anlisis realizado y las diferentes propuestas sugeridas.
2.2.4 Planificacin
Administracin de recursos: Una vez puesto en claro los recursos con los que contamos, los adecuaremos de la mejor manera posible para que las tareas que involucra el proyecto puedan realizarse en forma eficiente. Planificacin de tareas: Se asignarn tiempos a las tareas teniendo en cuenta la administracin de recursos realizada anteriormente, y se plasmarn en un diagrama tipo GANTT, que ser el Pgina 12 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
eje de la planificacin a lo largo de todo el proyecto.
2.2.5 Anlisis
Definicin de Incrementos: mdulos. Modularizaremos las tareas para poder abarcar todos los puntos e ir validando con el cliente los distintos incrementos. Arquitectura de la aplicacin: hardware y software. En esta etapa realizaremos un anlisis que se refiere a la arquitectura del proyecto, es decir a la organizacin y la disposicin eficiente de los recursos para que cumplan con los objetivos previstos. Definicin Casos de Uso: Identificaremos los posibles actores y las actividades que cada uno realiza. Los diagramas de casos de uso sirven para facilitar la comunicacin con los futuros usuarios del sistema, con el cliente y adems resultan especialmente tiles para determinar las caractersticas necesarias que tendr el sistema. En otras palabras, los diagramas de casos de uso describen qu es lo que debe hacer el sistema, pero no cmo. Especificacin de Casos de Uso: especificaremos cada uno de estos caso de uso y los posibles flujos alternativos. Tambin se especificarn los roles de los diferentes actores.
2.2.6 Diseo
UML: se pretende describir el comportamiento, la interaccin, la comunicacin, etc. entre los diferentes componentes que intervienen en el sistema mediante, un lenguaje estandarizado de modelado. En esta etapa se realizarn modelos uml: diagrama de clases, diagrama de actividades, diagrama de secuencia, etc. En su conjunto, estos diagramas pretenden la fcil y rpida comprensin de cmo debera funcionar el sistema desarrollado. Adems estos diagramas sirven para visualizar, especificar, construir y documentar el sistema de informacin. DER: este diagrama tambin conocido como diagrama lgico de datos, sirve para identificar y especificar las entidades que se utilizarn en el sistema junto con su estructura detallada. Adems la importancia de dicho diagrama es analizar las relaciones ptimas de estas entidades para que sea un sistema confiable, eficiente y sobre todo escalable en gran medida. Pgina 13 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Prototipos: Bosquejos de distintas pantallas que iremos mostrando a los distintos usuarios. stos son de carcter no desechables, puesto que son a partir de los cuales se construir el sistema.
2.2.7 Implementacin
Esta etapa consta de la construccin y el desarrollo propio del sistema de informacin. Esta implementacin estar basada segn los diferentes mdulos que iremos definiendo en la etapa de anlisis. Es decir que cada mdulo ser un incremento de software propiamente dicho que se adicionar al sistema base para agregar funcionalidad en forma incremental. Por ejemplo, uno de los mdulos bsicos ser el ABM de usuarios. Acto seguido deber desarrollarse un mdulo de seguridad para las capacidades y los accesos de dichos usuarios a las diferentes funcionalidades del sistema.
3. Anlisis
3.1 Anlisis de Requisitos
3.1.1 Introduccin
3.1.1.1 Qu es CIEM?
Consultorio Integral de Esttica Mdica (CIEM) es una empresa familiar en crecimiento que desde hace ms de dos aos se especializa en el cuidado no slo esttico sino, adems, cubre las necesidades de sus pacientes en forma integral. Los profesionales que integran la organizacin estn altamente calificados en las diferentes especialidades y de esta manera se asegura la calidad de atencin a todos los pacientes.
Pgina 14 de 70
Curso/ Grupo
Proyecto

3.1.1.2 Problema existente

Versin Fecha
5.0
10/11/2009
Actualmente se puede observar inconvenientes al momento de la solicitud de turnos por parte de los pacientes. La organizacin consta de muy poco personal administrativo por lo cual decidieron sistematizar esta operacin. Adems no encontramos un criterio unificado a la hora del manejo de las historias clnicas de los pacientes por lo que se encontraron historias duplicadas. Esto sumado a la falta de informacin acerca de los turnos asignados y la falta de planificacin por parte de los mdicos haca que algunos turnos se tengan que posponer o hasta cancelar. Esto provoc un malestar general en la organizacin, prdida de clientes y una prdida econmico-financiera.
3.1.2 Identificacin de mdulos

Plataforma. Seguridad. Administracin de usuarios. Historia clnica. Citas o turnos. Estadsticas.
3.1.3 Especificacin de requisitos

3.1.3.1 Plataforma
Este apartado supone la descripcin de todas las herramientas de infraestructura requeridas para montar la aplicacin en Web. Se enumeran los aplicativos requeridos y sus respectivas versiones para que la implementacin se haga de forma eficaz y eficiente. Y se explican las diferentes configuraciones necesarias:
Servidor Web: El servidor web elegido es Apache en su versin 2.2.x distribuido en forma libre mediante la licencia: Apache License versin 2.0. Pgina 15 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Se requiere que la configuracin del servidor tenga habilitado el mdulo mod_rewrite para que la aplicacin funcione en forma correcta.
PHP Servidor PHP para interpretar el cdigo de la aplicacin. El esquema de trabajo de los lenguajes interpretados es el siguiente: luego de tener el cdigo de aplicacin, el servidor interpreta dicho cdigo y luego de procesado le entrega al servidor Web los resultados de dicho procesamiento. La versin que vamos a utilizar ser desde la 5.2.x en adelante
Framework CakePHP Adems de la metodologa aplicada al desarrollo del proyecto hemos decidido implementar la solucin basndonos en un Framework orientado a la metodologa de desarrollo rpido (RAD o RApid Development) de aplicacin. Este marco de trabajo nos permite entregar los diferentes mdulos de forma mucho ms rpida que de la manera tradicional, manteniendo tanto la confiabilidad como la seguridad de la aplicacin. Se utilizar la ultima versin del Framework 1.2 Release Candidate 2. Este Framework se basa en el patrn de diseo MVC para la fcil construccin de aplicaciones y para mantener la flexibilidad as como tambin la escalabilidad de la aplicacin.
Control del Desarrollo El desarrollo ser realizado de forma controlada mediante un software de control de versiones como lo es el SVN (SubVersioN). Dentro de las funcionalidades que nos provee code.google.com/p/g-pac08, utilizaremos el versionado del software para llevar una traza del proceso de desarrollo minimizando al mximo los riesgos que implicara no hacerlo y garantizando un proceso de desarrollo fiable 100%. Pgina 16 de 70
Curso/ Grupo
Proyecto

3.1.3.2 Seguridad

Versin Fecha
5.0
10/11/2009
Este mdulo es de suma importancia a la hora del manejo de cualquier tipo de informacin. Se requiriere que la comunicacin sea fiable, es decir, que no pueda ser accedida por otras personas y a su vez que la informacin sea correcta e inviolable. Por lo tanto se desplegar un sistema de encriptacin de datos para la comunicacin con la plataforma segn la especificacin siguiente:
Encriptacin: Interfaz de usuario totalmente segura debido al uso de SSL para asegurar y encriptar las transmisiones de datos entre el usuario y el servidor. La va de comunicacin ser el acceso mediante internet al servidor web destinado para alojar la aplicacin. Teclado Virtual: Se proveer un teclado virtual para ingresar el usuario y el password para el acceso al sistema, para evitar ataques tipo keylogger. Este requerimiento surge esencialmente debido a que los usuarios pueden acceder desde cualquier terminal de datos del mundo a informacin sensible. Contrasea: El usuario podr y deber cambiar la contrasea cada cierto intervalo de tiempo. Al momento de creacin de la cuenta del usuario, el sistema generar de forma automtica una contrasea alfanumrica aleatoria la cual ser enviada a la cuenta de mail del usuario especificada. Acto seguido el usuario confirmar la recepcin del mail, haciendo que se habilite su cuenta en el sistema. En el primer acceso del usuario a la aplicacin, ste deber proporcionar una nueva contrasea alfanumrica de 8 caracteres. La aplicacin prevee cada 3 meses la obligacin del cambio de contrasea por parte del usuario, por lo que repetir el proceso como si ingresase por primera vez a la plataforma.
3.1.3.3 Administracin de usuarios
Un usuario se define como cualquier persona que tenga acceso legtimo a la aplicacin. Estos usuarios sern otorgados y administrados por personal idneo perteneciente al consultorio mdico, quien estar a cargo de la asignacin de los diferentes roles que cumplir cada uno de ellos dentro del sistema. La idea es que slo aquellas personas que pueden tener acceso a la informacin lo tengan, de la manera ms fiable y segura posible. Pgina 17 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Creacin de usuarios: Para la creacin de un usuario se requerirn los siguientes datos:
Nombre de usuario Tipo y N de Documento: D.N.I., L.C., L.E, Cdula. Nombre Apellido Fecha de nacimiento Telfono particular Celular Direccin Localidad Cdigo postal E-mail Telfono de emergencia Comentario Acto seguido se le proveer al usuario una contrasea segn lo especificado en el apartado de Seguridad. En caso de que el usuario no posea una cuenta de correo electrnico, se le proveer una con el siguiente formato nombre_de_usuario@ciem.com.ar.
Acceso de usuarios: El acceso a la plataforma deber validarse contra una base de datos, definida en el apartado Plataforma, ingresando un nombre de usuario y una contrasea vlidos. De no poseer una cuenta de login vlida en el sistema, se proveer un formulario para la creacin de la misma.
Pgina 18 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Roles:
La aplicacin est pensada para proveer y definir diferentes permisos por sobre las distintas funcionalidades. Estos permisos se definen de forma agrupada bajo roles de usuario. Los roles de usuario permiten identificar de alguna manera cmo ser la interaccin con el sistema, siguiendo los lineamientos de seguridad especificados anteriormente y por una cuestin de flexibilidad. Se crearn formulario de alta, baja, modificacin para la administracin de roles. Si bien se crearn roles predefinidos, la flexibilidad de la plataforma est dada por la posibilidad de agregar y definir nuevos. Se definen 4 roles fundamentales: - Mdico: - Acceso al calendario de turnos. - Acceso a historias clnicas de todos los pacientes del consultorio, independientemente de si dicho paciente ha sido atendido por l u otro colega. - Definicin de das y horarios de atencin. - Acceso a estadsticas del sitio - Acceso a feedback por parte del usuario. - Modificacin de historias clnicas. - Posibilidad de darse de baja como mdico.
- Secretaria: - Acceso al calendario de turnos. - Asignacin de turnos segn das, horarios y profesionales disponibles para cualquier paciente. - Modificacin de turnos pedidos ante eventuales cancelaciones previas al turno. - Creacin de usuarios y modificacin de datos de usuarios existentes. - Acceso a los datos de los distintos usuarios, exceptuando las historias clnicas de los pacientes. - Posibilidad de darse de baja a distintos usuarios. Pgina 19 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
- Paciente: - Acceso al calendario de turnos, mostrando das, horarios y profesionales disponibles. - Solicitar y cancelar turnos. - Creacin de cuenta de usuario y modificacin de datos de ste. - Acceso a su historia clnica. - Posibilidad de darse de baja como paciente. - Administrador: - Acceso a todas las funcionalidades del sistema sin restricciones. Baja de usuarios: posibilidad de eliminar uno o varios usuarios del sistema, dependiendo el rol asignado.
Modificacin del perfil del usuario: se podr realizar la modificacin de los datos del perfil del usuario, dependiendo el rol asignado.
Modificacin de permisos: el administrador de la aplicacin podr modificar los diferentes permisos por sobre los diferentes roles. Esto significa que si a un rol determinado se le quiere dar la posibilidad de realizar una accin determinada no permitida por default, esto podr cambiarse mediante un formulario de administracin de roles.
Definicin de nuevos roles y sus permisos: la aplicacin es escalable en lo que a administracin de roles se refiere. Con esto queremos decir que si en un futuro se requiere la creacin de nuevos roles al sistema con permisos determinados, esto podr realizarse mediante el formulario de administracin de roles.
3.1.3.4 Solicitud de Turnos
El usuario deber seleccionar la especialidad del mdico con el cual quiere consultar (clnico, nefrlogo, esttica, otro). Una vez seleccionada la especialidad, se habilitar un men de seleccin con los profesionales disponibles de esa especialidad. En caso de que no se seleccione ninguna especialidad, se listarn todos los profesionales. A partir de la seleccin del profesional se cargar el calendario con los horarios libres y Pgina 20 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
asignados del profesional seleccionado.
Paciente El paciente, previamente logueado, podr solicitar un turno, de acuerdo a sus disponibilidades horarias y a los turnos disponibles. Esto variar dependiendo la especialidad y el profesional seleccionado. La duracin de los mismos ser de 30 minutos (pudiendo presentarse excepciones a futuro). Una vez realizada una reserva de turno, quedar automticamente deshabilitado. De esta forma, cualquier otro paciente interesado por ese turno, no podr reservarlo. Para solicitar un turno, se deber completar un formulario con el motivo de la consulta. Una vez generada la consulta se agregarn a ella los datos de usuario correspondientes, segn quin haya solicitado el turno. Adems el paciente podr cancelar y hasta realizar modificaciones sobre el turno pedido si le surgiere algn inconveniente con el horario previamente seleccionado. Se podrn realizar varias solicitudes de turnos con distintos profesionales, siempre y cuando no se superpongan. No se podr realizar ms de una reserva con un mismo mdico hasta tanto no haya pasado la fecha de la 1era solicitud. Esto es para evitar que reserve varios turnos y no concurra a ninguno de ellos, quintndole la posibilidad de reserva a otro paciente. Una vez reservado los n turnos se podr realizar una impresin de los mismos, donde figurar: - Nombre de especialista - Fecha y Hora de atencin - Direccin de la sede correspondiente (hoy en da el consultorio posee solo una, pero hay visin de crecimiento.) Pgina 21 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Secretaria
Podr reservar turnos para cualquier paciente que lo solicite y adems visualizar la asignacin de los turnos de todos los mdicos puesto que su funcin principal ser la de gestionar los turnos.
Tendrn la posibilidad de modificar turnos sin ninguna dificultad.
Mdicos
Los mdicos tendrn tambin acceso al calendario. De este modo podrn ver la cantidad de pacientes que debern ser atendidos y por qu motivos realizan la consulta entonces, de ser necesario, se podr preparar el procedimiento especfico con suficiente anticipacin.
Si se diera la casualidad de que algn da no tuviese asignado ningn turno, podr no concurrir a trabajar ya que no se atendern pacientes sin previa solicitud de turno.
Cabe destacar que todas las tareas cubiertas en este mdulo sern debidamente logueadas. Es decir, que cualquier alta, baja o modificacin de un turno ser debidamente logueado en la base de datos del sistema identificando, nombre de usuario operacin fecha y hora del acontecimiento.
3.1.3.5 Historias Clnicas
Al momento de generar el usuario al sistema, se le asigna a ste una historia clnica con los datos completados por el usuario. Este historial es de carcter aditivo y se ir completando por los profesionales a travs de cada consulta, visita y/o turno. A partir de la primera consulta, cada paciente tendr una historia clnica propia y de carcter nico. Luego de cada revisacin o consulta mdica, el profesional deber asentar en ella lo Pgina 22 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
ocurrido y aquello que considere necesario. No se podrn realizar modificaciones sobre los documentos sino que todo asiento es acumulativo sobre el historial clnico del paciente. Todos los especialistas tendrn acceso a todas las historias de todos los pacientes del consultorio, pero ser un acceso de slo lectura sin posibilidad de realizar modificaciones. Los pacientes tambin podrn acceder a su historia clnica desde cualquier parte del mundo con un computador conectado a Internet, luego de haber solicitado el acceso a la misma. Se deber respetar el formato de historia clnica predeterminado (ver Anexo I en la seccin Anexos).
3.2 Estudio de Factibilidad

El estudio de factibilidad es el primer paso que debe realizarse en cualquier proyecto para analizar la viabilidad de las mejores alternativas desde el punto de vista tcnico, operativo y econmicofinanciero. Este estudio abarca los tres puntos de vista arriba mencionados, en forma independiente, sin dejar de lado el impacto que tendr el producto en el mercado. Para esto se incurre en un proceso de estudio de mercado para poder esbozar no slo las funcionalidades bsicas que cubren otras aplicaciones ya implantadas, sino para detectar posibles ventajas competitivas por sobre dichas aplicaciones. Estas ventajas sern fundamentales a la hora de la exitosa introduccin del producto en el mercado.
3.2.1 Estudio de Mercado

Luego de una exhaustiva bsqueda por diferentes partes del mundo a travs de Internet hemos encontrado una serie de aplicaciones similares que cubran parcialmente los requerimientos de nuestro cliente. Los puntos fundamentales que cubran son:
Mdulo Seguridad: slo a nivel de autenticacin de usuarios. Administracin de usuarios. Historia Clnica. Citas o turnos. Pgina 23 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Luego de ver la forma en la que se resolvieron los diferentes requisitos en las diferentes aplicaciones concluimos que podamos realizar ciertas mejoras que nos llevaran a generar una ventaja competitiva por sobre los dems productos. Estas ventajas son las siguientes:
Plataforma: Plataforma completamente libre, es decir, software no propietario apoyado por grandes comunidades de usuarios alrededor del mundo. Seguridad: Teclado Virtual (Anti Key-Logger). Renovacin peridica de la contrasea de acceso. Encriptacin del acceso a la pgina va SSL. Acceso restringido a las funcionalidades del sistema segn el rol definido para el usuario. Administracin de usuarios. Definicin de roles. Historia clnica. Acceso por parte de los usuarios a sus historias clnicas. Estadsticas. Estadsticas del sitio: cantidad de accesos, usuarios, direccin ip de acceso, etc. Estadsticas de consultas por profesional. Cantidad de acceso a historia clnica solicitados por el pacientes.
3.2.2 Factibilidad Tcnica

3.2.2.1 Software
La premisa a la hora de comenzar con este proyecto fue desarrollar un sistema con las principales ventajas competitivas a nivel de mercado pero siempre teniendo en cuenta que iba a ser una aplicacin Open-Source. Esto significa que se distribuira de forma completamente gratuita para poder llegar a centros de muy bajos recursos econmicos, sin posibilidad de obtener un software privativo de tales funcionalidades. Con dicha premisa en mente basamos tanto el desarrollo, la prueba como la puesta en Pgina 24 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
productivo sobre aplicaciones tambin Open-Source. Estas aplicaciones son:
Apache Web Server (http://www.apache.org) PHP (http://www.php.net) Framework CakePHP (http://www.cakephp.org) SVN (http://subversion.tigris.org/)
Todas estas aplicaciones nos proveen de un entorno controlado a nivel profesional para el desarrollo de una aplicacin segura, cien por ciento fiable y por sobre todas las cosas, amigable para el usuario.
3.2.2.2 Hardware
A nivel de Hardware no se presentan grandes restricciones segn las tecnologas que hemos elegido en el punto anterior. Por esto, el hardware necesario ser cualquier computador que disponga de buena llegada a internet, es decir, que est disponible las 24hs., que sea fiable a nivel de la informacin que manejar (backups diarios), etc. Por todo lo expuesto en este apartado lo ms factible tcnicamente ser hostear la aplicacin en una empresa especializada en web hosting. Algunas de estas empresas son: Wizhosting (http://www.wizhosting.com/) Aeolus (http://www.aeolushosting.com.ar/) Dattatec (http://www.dattatec.com/) ToWebs (http://www.towebs.com/)
Luego de realizar un relevamiento de los planes ofrecidos por estas empresas de hosting hemos seleccionado la empresa ToWebs, el plan E-Commerce Plus. Dicho plan nos ofrece estas caractersicas (Ver Figura 3.2.2.1).
3.2.2.3 RRHH
El personal requerido debe conocer y manejar las tecnologas que intervienen en este proyecto mencionadas en los dos apartados anteriores. Lo ideal sera que las personas que estarn a Pgina 25 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
cargo del desarrollo de la aplicacin manejen el framework a utilizar a la perfeccin. En el caso que el personal no est capacitado para aplicar las tcnicas ofrecidas por el framework no ser impedimento ya que la curva de aprendizaje no es mayor a un par de semanas. La capacitacin prevista quedar a cargo del programador, es decir que ser una auto capacitacin. Toda la documentacin necesaria para la capacitacin se encuentra en : http://book.cakephp.org/.
3.2.3 Factibilidad Operativa

La organizacin previ afectar a una persona para administrar la aplicacin. La secretaria ser la encargada de interactuar con el sistema administrando usuarios, citas o turnos y dems funcionalidades de la aplicacin segn las capacidades del rol de secretaria. Las personas afectadas al desarrollo de la aplicacin segn los tiempos previstos sern los dos integrantes del grupo. La capacitacin estar a cargo de los programadores y ser en la modalidad on-site. Se llevar a cabo en un da de 8hs. junto con la secretaria. Adems, dentro de dicho tiempo, se realizar una pequea charla orientada a los profesionales que utilizarn el sistema. Luego de la charla se entregar un pequeo instructivo que detalla las funciones bsicas que se podrn realizar con la aplicacin. Este manual de usuario se realizar una vez terminado el proceso de desarrollo del sistema.
Pgina 26 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Figura 3.2.2.1: Fuente: http://www.towebs.com/hosting/unix_700.html
Pgina 27 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
3.2.4 Factibilidad Econmico-Financiera

Detalle Unica Vez Registro de dominio .com.ar Desarrollador 1 Desarrollador 2 Capacitacin (2 personas) Anlisis del problema y planteo de solucin Alquiler espacio en un testing server propio Mensual Backups mensuales Matenimiento Hosting Promocin Soporte Online post implementacin (1 semana) Total
Tabla 3.2.4.1 Costos detallados
Horas 1 hs. 29 hs. 29 hs. 16 hs. 40 hs.
Costo
$ 20,00 $ 4.640,00 $ 4.640,00 $ 240,00 $ 800,00 $ 200,00 Total $ 10.540,00 2 hs. $ 40,00 $ 160,00 $ 24,00 $ 224,00 $ 0,00 $ 0,00
Total
3.2.4.1 Detalles
Registro del Dominio .com.ar: es una tarea que llevar a cabo la empresa. Este dominio apuntar al Server productivo donde se alojar la aplicacin.
Desarrollador 1 / 2: personas asignadas a dicha tarea. Capacitacin: tarea detallada en la factibilidad operativa. Anlisis del Problema y planteo de la solucin: tarea encarada desde el primer da por parte del grupo.
Alquiler de espacio en Server testing: para hacer ms eficiente el proceso de desarrollo y gracias al uso de una metodologa iterativa incremental con prototipos no desechables, se requiere un Server testing donde el cliente pueda observar los cambios realizados en tiempo real. Este espacio est en un servidor de la empresa.
Mantenimiento: el sitio requiere un mantenimiento mnimo. Esto se refiere a la generacin de estadsticas a nivel de servidor que sern enviadas en forma mensual a una casilla de correo que el cliente solicite; la limpieza de logs, la registracin anual del dominio (NIC Argentina requiere el registro de los dominios ya registrados en forma Pgina 28 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
anual), el recupero del Server en caso de fallas, etc. Back Ups mensuales: siguiendo con el ofrecimiento de un servicio de calidad se realizarn Back Ups de la base de datos de la aplicacin en forma Mensual. Hosting: pago mensual por alquiler de espacio en internet (Server donde correr la aplicacin). Soporte Online post-implementacin (1 semana): luego de realizar el deploy de la aplicacin y la capacitacin, se otorgar una semana de soporte tcnico online sobre la aplicacin de forma gratuita.
3.2.5 Conclusin de Factibilidad

Este anlisis parti de la base de la independencia de los focos analizados: tcnico, operativo, econmico-financiero. Para generar la mejor solucin se tendr que realizar un mix de dichos factores, ponderando en mayor o en menor medida la aplicacin de uno u otro de ellos segn la mejor solucin al problema consumiendo los menores recursos posibles. Aqu se observa la dependencia de un factor con respecto a los otros. Si bien luego de este anlisis se podran presentar varias alternativas, decidimos presentar la opcin que pondera, en mayor medida, el factor econmico-financiero. Por este motivo se eligi trabajar sobre plataformas libres, ya que si bien son gratuitas, se trata de herramientas 100% fiables, apoyadas por comunidades de miles de usuarios alrededor del mundo.
3.3 Arquitectura
Luego de definir las funcionalidades bsicas que debe cubrir el sistema y habiendo completado la etapa del estudio de factibilidad del sistema procederemos a realizar un anlisis exhaustivo de la aplicacin a implementar. Este anlisis basar su estudio no slo en los requerimientos del sistema sino en la infraestructura tanto a nivel software como hardware en que se basar el posterior desarrollo. Las piezas intervinientes se estructurarn de determinada manera para as obtener la mayor flexibilidad, escalabilidad, seguridad y fiabilidad posible. Pgina 29 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
3.3.1 Definicin de incrementos: mdulos

Los mdulos que han de ser desarrollados ya fueron explicados de forma granular en el apartado Anlisis de Requisitos. stos mdulos son: Plataforma. Seguridad. Administracin de usuarios. Historia clnica. Citas o turnos. Estadsticas. Lo que cabe destacar es que la concrecin de todas las tareas que definen un mdulo definirn un incremento completamente funcional de nuestro sistema de gestin de pacientes. Esto quiere decir que las tareas del marco de trabajo fueron siempre agrupadas teniendo en cuenta los entregables que se iban a ir sucediendo en el tiempo. Al estructurar el desarrollo de esta manera se gana no slo en claridad de implementacin sino que supone una aplicacin construida en las bases de la escalabilidad y de la flexibilidad. Cada incremento podra pensarse como un componente del sistema: a medida que desarrollamos ms componentes, muchas ms funcionalidades tendr el sistema. Teniendo en cuenta dicha estructuracin de la aplicacin podemos decir que si bien este proyecto probablemente no llegue a concluirse antes del fin de la materia, de hecho la planificacin no lo supone as, la idea es que cualquier persona que lea estas pginas pueda desarrollar componentes funcionales para seguir sumando funcionalidad. Es por esto que tambin se plante desde un primer momento liberar el cdigo de la aplicacin bajo una licencia open source: de tener la aceptacin que nosotros esperamos del producto, ste pueda ser apoyado por una comunidad alrededor del mundo que pueda llevar la aplicacin hasta un lugar privilegiado por ser un software libre.
3.3.2 Arquitectura
La definicin de arquitectura puede llegar a ser muy ambigua ya que estamos analizando sistemas informticos. Sin embargo este trmino se adopt en la industria informtica debido a la gran similitud con la construccin de sistemas. Este trmino supone la realizacin de un modelo de todas las piezas en juego y su disposicin ms ptima, con la principal meta de cumplir los Pgina 30 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
objetivos de la forma ms eficiente y utilizando la menor cantidad de recursos disponibles posible.
3.3.2.1 Hardware
La estructura bsica de acceso a la aplicacin se basa en un request a un servidor Web, a travs de Internet. Para que las conexiones sean seguras se dise un sistema el cual establezca conexiones encriptadas entre el cliente y el servidor ya que se manejar informacin sensible. Esta seguridad se logra gracias a la configuracin del servior Apache. Todos los servidores tanto Testing como Production corrern el sistema operativo OpenSource: Debian Linux. A su vez dentro del mismo servidor correr una aplicacin de base de datos: MySQL. El Testing Server est pensado para alojar la aplicacin durante el tiempo de desarrollo de prototipos y durante el tiempo de desarrollo. Esto se llevar a cabo trabajando con un sistema de control de versiones del software (SVN). Esta aplicacin nos mantiene dentro de un ambiente de trabajo controlado por el desarrollador donde ante eventuales errores puede volverse a versiones anteriores sin ningn problema. Esta tcnica cumple con los estndares de calidad del desarrollo. El pasaje a productivo se realizar de la siguiente forma: (Ver: Figura 3.3.2.1) Antes de realizar este proceso se dejar el Production Server en modo mantenimiento. Luego de desarrollar un mdulo completo se testear segn los estndares definidos y se
construir un release. Este release se instalar en el Production Server a travs del servidor SVN.
Pgina 31 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Figura 3.3.2.1: Arquitectura de Hardware del desarrollo del sistema
Como puede apreciarse en la Figura anterior cada uno de los servidores se apoya en un servidor de backup que mantiene de forma peridica una copia del sistema de archivos de cada servidor. Esto respeta las normas de calidad definidas en los requisitos funcionales.
3.3.2.2 Software
Independientemente de que la aplicacin debe tener un soporte de hardware tecnolgicamente consistente con la aplicacin de va a correr creemos que la flexibilidad, escalabilidad, y robustez del sistema se basa en la forma en la cual se dispondrn las piezas de software. La estructura bsica de la aplicacin se basar en el patrn de diseo MVC (Model View Controller) y est aplicada en el patrn que se usar para el desarrollo. Los patrones de diseo son tcnicas utilizadas en determinadas circunstancias que ya han sido Pgina 32 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
probadas por miles de ingenieros de software y que bajo ciertas condiciones ayudan a dar soluciones eficientes, flexibles, escalables y robustas. El MVC o por sus siglas en castellano, Modelo-Vista-Controlador, supone la divisin de la aplicacin en tres partes bien cohesivas: El modelo: o vulgarmente llamado el sujeto que estoy representando. ste est
orientado a la representacin del objeto de la realidad que quiero que intervenga en mi aplicacin. Por ejemplo: el usuario, la cita o turno, la historia clnica, los roles, etc. El modelo est ntimamente ligado con las tablas de la base de datos de la aplicacin. Es decir que el objeto tomar todas sus propiedades segn lo que se defina la tabla de la base de datos y en particular en el modelo en s mismo. La vista: es el conjunto de elementos que definen de que forma mostrar la informacin
procesada por el sistema. Es decir que define si utilizar tablas HTML, divs, ordered lists, Ajax, JavaScript, etc. stas estn pensadas desde el punto de vista visual de la aplicacin y no deberan tener otra responsabilidad ms que la de formatear los datos pasados por el Controlador para mostrarlos en pantalla segn el formato definido. El controlador: esta pieza de la estructura es el encargado tomar las peticiones del
cliente y ejecutar la lgica establecida ante dicho evento valindose de todos los modelos que estn a su alcance. Es decir que el componente que tiene programada la lgica de negocio. Luego de realizar todas las acciones requeridas enviar la informacin a mostrar a la vista, quien se encargar de mostrar los datos del controlador. Ver grfico donde se explica de forma clara los pasos en un MVC en la Figura 3.2.2.2.
Pgina 33 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Figura 3.2.2.2: Patrn MVC. Fuente: http://book.cakephp.org/view/11/Overview
3.4 Casos de Uso

Los casos de uso son modelos pertenecientes a UML (Unified Modeling Language) clasificados dentro de los modelos de comportamiento de sistemas. Mediante este simple grfico se intenta dar una rpido vistazo a las diferentes funcionalidades cubiertas por el sistema y los actores que intervendrn en esas funciones. Para hacer todava ms eficaz estos modelos luego se proceder a especificar cada burbuja para clarificar qu es lo que cumple cada funcin y cuales son los roles que intervienen.
Pgina 34 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
3.4.1 Diagramas de Casos de Uso
Figura 3.4.1.1 Casos de uso de g-pac08
Pgina 35 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Figura 3.4.1.2 Casos de uso de g-pac08
Pgina 36 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
3.4.2 Especificacin de Casos de Uso

Nombre del caso de uso: Actor: Objetivos: Precondiciones:
Crear Cuenta
Usuario no logueado o Rol de Secretaria Crear una cuenta para que se identifique como un usuario del sistema.
Curso Normal
Actor: Usuario no logueado Curso Alternativo
1- El usuario no logueado selecciona la opcin de crear una cuenta de usuario nueva.
2- El sistema mostrar un formulario con los siguientes campos a completar por el futuro usuario: Nombre de usuario,Tipo y N de Documento: D.N.I., L.C., L.E, Cdula, Nombre, Apellido, Fecha de nacimiento, Telfono particular, Celular, Direccin, Localidad, Cdigo postal, E-mail, Telfono de emergencia, Comentario. 3- El usuario no logueado proceder a completar dicho formulario con sus datos personales. 4- El sistema crear la cuenta dando de alta al usuario en la base de datos de usuarios. Enviar por mail la informacin para confirmar la creacin de dicha cuenta, junto con una contrasea alfanumrica creada y asignada de forma aleatoria por el sistema. 5- El usuario confirmar la cuenta e ingresa al sistema con su usuario y la contrasea asignada.
Curso Normal
Actor: Secretaria Curso Alternativo
1- La Secretaria selecciona la opcin de crear una cuenta de usuario nueva.
2- El sistema mostrar un formulario con los siguientes campos a completar por el futuro usuario: Nombre de usuario, Rol del usuario: paciente o mdico, matrcula,Tipo y N de Documento: D.N.I., L.C., L.E, Cdula, Nombre, Apellido, Fecha de nacimiento, Telfono particular, Celular, Direccin, Localidad, Cdigo postal, E-mail, Telfono de emergencia, Comentario. En el caso que el rol asignado corresponda al de mdico entonces se deber completar el campo matrcula con el nmero del profesional. De ser paciente, dicho campo quedar oculto y vaco. 3- La Secretaria proceder a completar dicho formulario con los datos personales otorgados por el paciente o el mdico.
Pgina 37 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
4- El sistema crear la cuenta dando de alta al usuario en la base de datos de usuarios. Enviar por mail la informacin para confirmar la creacin de dicha cuenta, junto con una contrasea alfanumrica creada y asignada de forma aleatoria por el sistema. 5- El usuario confirmar la cuenta e ingresa al sistema con su usuario y la contrasea asignada.
4.1 - En caso que la persona a la que se le est creando la cuenta no posea una casilla de correo electrnico para realizar la operacin, la secretaria crear una cuenta de email del tipo nombre_de_usuario@ciem.com.ar, con la cual se completar el campo email dentro del formulario de creacin de usuarios.
Nombre del caso de uso: Cambiar Contrasea Actor: Paciente, Secretaria, Mdico. Objetivos: Realizar el cambio de contrasea correspondiente. Precondiciones: El paciente, secretaria o mdico deben estar logueados en la aplicacin. Curso Normal Curso Alternativo
1- El actor hace un click en el botn cambiar contrasea dentro del panel de administracin, ubicado a la izquierda de la pantalla. 2- El sistema imprime un formulario con los siguientes campos: contrasea actual, nueva contrasea, confirmacin de la nueva contrasea. 3- El actor provee la informacin requerida por el formulario, seleccionando una nueva contrasea. 4- El sistema verifica primero que la contrasea antigua sea la que corresponde a dicho usuario. Si esto es as entonces se verifica que tanto la contrasea nueva como el reingreso de la misma sean iguales. Si se cumplen estas dos condiciones el sistema realiza el cambio de contrasea en la base de datos.
4.1- Si la contrasea antigua no se corresponde con la del usuario, el sistema devolver el mismo formulario de cambio de contrasea con un error descriptivo en color rojo.Volver punto 2. 4.2- El sistema volver a imprimir el formulario de cambio de contrasea con un error descriptivo en color rojo, en el caso en que la nueva contrasea y su reingreso no coincidan, invitando al actor a ingresar nuevamente los datos.Volver punto 2.
5- El sistema informa con una leyenda que el cambio de contrasea se realiz con xito.
Nombre del caso de uso: Actor: Objetivos:
Solicitar Turno
Paciente, Secretaria Realizar la reserva de un turno.
Pgina 38 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Precondiciones:
El actor debe estar logueado y tener el rol adecuado(Paciente o Secretaria).
Curso Normal
Actor: Paciente Curso Alternativo
1- El paciente hace click en el link de "turnos" en la pgina principal. 2- El sistema desplegar una pantalla donde aparecern las distintas especialidades y los profesionales dedicados a las mismas. 3- El paciente har click sobre el mdico elegido. 4- El sistema mostrar una pantalla con los dias y horarios de antencin de dicho mdico. 5- El paciente podr seleccionar el turno que mejor se adece a sus necesidades indicando el motivo de la consulta; siempre y cuando ste se encuentre habilitado. 6- El sistema proceder a inhabilitar el turno solicitado por el actor para que no pueda ser elegido nuevamente. Imprimir, a continuacin, una pgina de confirmacin. 6.1- En caso de que el paciente desee cancelar la cita, ver extend "Modificar Solicitud"
Curso Normal
Actor: Secretaria y Paciente Curso Alternativo
1- La secretaria hace click en el link de "Bsqueda de pacientes" en la pgina principal. 2- El sistema mostrar un formulario de bsqueda de usuarios. El mismo constar de un campo de texto en donde se buscar por: documento, nombre, apellido. 3- La secretaria buscar al paciente segn los datos que ste le informe, completando el formulario de bsqueda. 4- El sistema desplegar una pantalla donde aparecern las distintas especialidades y los profesionales dedicados a las mismas. 4- La secretaria har click sobre el mdico elegido. 5- El sistema mostrar una pantalla con los dias y horarios de antencin de dicho mdico. 6- La secretaria podr seleccionar el turno que mejor se adece a necesidades del paciente; siempre y cuando dicho turno se encuentre disponible. 7- Una vez que el paciente elegi el da y horario para realizar la reserva del turno, el sistema desplegar un formuario con el motivo de la consulta. 8- La secretaria proceder a completar el motivo que le es informado por el paciente. 9- El sistema proceder a inhabilitar el turno solicitado por el paciente para que no pueda ser elegido nuevamente. Mostrar, a continuacin, una pgina de confirmacin. 9.1- En caso de querer cancelar la cita, ver extend "Modificar Solicitud"
Pgina 39 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Postcondiciones:
Turno reservado por el paciente.
Modificar Solicitud
Paciente, Secretaria Cancelar o modificar un turno previamente reservado. * El actor debe estar logueado y tener el rol adecuado(Paciente o Secretaria). * El actor debe haber reservado un turno con anterioridad.
Curso Normal
1- El paciente clickea sobre modificar turno.
Actor: Paciente Curso Alternativo

1.1- El paciente clickea sobre cancelar turno. 1.2- El sistema muestra una pantalla de confirmacin y procede a cancelar dicho turno, habilitandolo para que pueda ser elegido por otro paciente.
2- El sistema procede a cancelar dicho turno y despliega una pantalla con todos los dias y horarios de atencin de ese mdico, mostrndose inhabilitados aquellos turnos que ya fueron tomados. 3- El paciente elegir un nuevo turno de aquellos diponibles e indicar nuevamente el motivo de la consulta. 4- El sistema proceder a inhabilitar el turno solicitado por el paciente para que no pueda ser elegido nuevamente. Imprimir, a continuacin, una pgina de confirmacin.
Curso Normal
Actor: Secretaria Curso Alternativo
1- La secretaria hace click en el link de "Bsqueda de pacientes" en la pgina principal. 2- El sistema mostrar un formulario de bsqueda de usuarios. El mismo constar de un campo de texto en donde se buscar por: documento, nombre, apellido. 3- La secretaria busca por los datos informados por el paciente, ingresando el texto en el formulario. Luego, hace un click en modificar turno y procede a cambiar el turno.
3.1- La secretaria clickea sobre cancelar turno. 3.2- El sistema muestra una pantalla de confirmacin y procede a cancelar dicho turno, habilitandolo para que pueda ser elegido por otro paciente.
4- El sistema procede a cancelar dicho turno y despliega una pantalla con todos los dias y horarios de atencin de ese mdico, mostrndose inhabilitados aquellos turnos que ya fueron tomados. 5- La secretaria le reservar al paciente un nuevo turno de aquellos diponibles, segn el paciente lo requiera, e indicar nuevamente el motivo de la consulta.
Pgina 40 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
6- El sistema proceder a inhabilitar el turno solicitado para que no pueda ser elegido nuevamente. Imprimir, a continuacin, una pgina de confirmacin.
Postcondiciones:
Turno modificado o cancelado por el paciente.
Nombre del caso de uso: Ver Historia Clnica Actor: Paciente Objetivos: Acceder a su propia historia clnica Precondiciones: El actor debe estar logueado y tener el rol adecuado(Paciente). Curso Normal Curso Alternativo
1- El paciente har un click en el link "Historia Clnica". 2- El sistema verifica que el paciente est habilitado para ver su historia clnica. En caso de no estar habilitado, el sistema imprimir un formulario solicitando al paciente que ingrese el motivo por el cual se solicita ver la 2.1 - En caso de poder ver la historia clnica el sistema historia clnica. Esto disparar un email al centro mdico indicando la imprimir los datos de la misma con permisos de slo lectura solicitud. para que no pueda ser modificada por el paciente. 3- La secretaria evaluar la causa y si fuese justificada, procede a otorgarle el permiso al paciente informndole va e-mail. 4- Se le habilitar un link en el sistema para que pueda visualizar su historia clnica. El paciente tendr permisos de slo lectura sobre la misma. 5- EL sistema revocar dicha habilitacin al cabo de 7 das, avisndole por e-mail al paciente. 3.1- En caso de que la solicitud no fuese justificada, se le revocar el permiso e informar va e-mail al paciente.
Postcondiciones:
Nombre del caso de uso: Modificar datos personales Actor: Paciente Objetivos: Realizar cambios en los datos personales Precondiciones: El actor debe estar logueado y tener el rol adecuado(Paciente). Curso Normal Curso Alternativo
1- El paciente hace click en el link "Modificar Datos Personales" en la pgina principal del sistema. 2- El sistema mostrar un formulario con los siguientes campos junto a los datos a modificar: Nombre de usuario,Tipo y N de Documento: D.N.I., L.C., L.E, Cdula, Nombre, Apellido, Fecha de nacimiento, Telfono particular, Celular, Direccin, Localidad, Cdigo postal, E-mail, Telfono de emergencia, Comentario.
Pgina 41 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
3- El paciente realiza las modificaciones necesarias, respetando los campos obligatorios. 4- El sistema guardar los cambios imprimiendo una pantalla confirmando los mismos.
Postcondiciones:
Nombre del caso de uso: Acceder a Estadsticas Actor: Mdico, Paciente Objetivos: Ofrecer estadsticas a distintos niveles segn el actor que ejecute el caso de uso. Precondiciones: El actor debe estar logueado y tener el rol adecuado(Mdico, Paciente). Curso Normal Curso Alternativo
1- El actor hace click en "Ver estadsticas". 2- El sistema mostrar una serie de estadsticas para que el actor elija.
3- El mdico podr elegir una de las siguientes estadsticas: a) cantidad de pacientes atendidos en un perodo dado. b) Cantidad de cancelaciones de turnos en un perodo. c) Porcentaje de pacientes atendidos con respecto al total de turnos. d) Porcentaje de atencin de pacientes segn especialidad y segn profesional en un perodo dado. 4- El sistema mostrar la estadstica seleccionada por el mdico: mostrando tablas, grficos, etc. segn corresponda.
3.1- El paciente elegir una de las siguientes estadsticas: a) Porcentaje de atencin de profesionales por especialidad. b) Cantidad de consultas de dicho paciente por perodo. 4.1- El sistema mostrar la estadstica seleccionada por el paciente: mostrando tablas, grficos, etc. segn corresponda.
Postcondiciones:
Nombre del caso de uso: Establecer Horarios de Atencin Actor: Mdico Objetivos: Determinar los horarios en que atender el mdico Precondiciones: El actor debe estar logueado y tener el rol adecuado(Mdico). Curso Normal Curso Alternativo
1- El mdico deber definir el horario de atencin ingresando al link 'Horario de Atencin'. 2- El sistema desplegar un formulario el cual deber ser completado con los das y horarios que le fueron asignados en el centro al mdico. 3- El sistema cargara los datos en base y habilitar los turnos segn los horarios establecidos.
Postcondiciones:
Pgina 42 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Nombre del caso de uso: Visualizar Turnos Actor: Mdico, Secretaria Objetivos: Acceder a los turnos reservados discriminados por dia y hora. Precondiciones: El actor debe estar logueado y tener el rol adecuado(Mdico, Secrearia). Curso Normal Curso Alternativo
1- El mdico tendr acceso al calendraio en tiempo real, es decir, podr visualizar todos los pacientes que tendr que atender a medida que stos soliciten un turno. 2- El sistema desplegar una tabla con el nombre del paciente y la fecha y hora en que ser atendido. 3- El mdico podr acceder a la histria clnica de cada uno de estos pacientes haciendo click sobre el nombre del mismo. 4.1 - Si el mdico accediera a ver una historia clnica, el sistema imprimir una pantalla con los datos de la historia clnica de dicho paciente.
Postcondiciones:
Nombre del caso de uso: Acceder a Historia Clnica Actor: Mdico Objetivos: Acceder a las historias clnicas de los distintos pacientes del centro. Precondiciones: El actor debe estar logueado y tener el rol adecuado(Mdico). Curso Normal Curso Alternativo
1- El mdico hace click en el link "Historias Clnicas" 2- El sistema despliega una pgina de bsqueda por DNI, Nombre y Apellido del paciente o Fecha de turno. 3- El mdico completa con los datos que posea y procede a realizar al bsqueda. 4- El sistema desplegar una lista con todos los pacientes que posean dichos datos. 5- El mdico seleccionar con un click al paciente requerido. 6- El sistema desplegar una nueva pgina con la historia clnica del paciente ofreciendo un link para agregar ms informacin.
6.1- En caso de de necesitar aadir informacin, el mdico agrega los datos necesarios.
Postcondiciones:
Gestionar Roles
Administrador Realizar alta, baja y modificacin de roles El actor debe estar logueado y tener el rol adecuado(Administrador).
Pgina 43 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Curso Normal
1- El administrador hace click en el link "Roles" 2- El sistema despliega una lista con los roles existentes y su definicin. 3- El aministrador tiene la opcin de dar de alta un nuevo rol, eliminarlo o modificarlo, seleccionando el link correspondiente.
Curso Alternativo
Postcondiciones:
Gestionar Permisos
Administrador Asignar a un determinar Rol una determinada cantidad de permisos por sobre las funcionalidades del sistema. El actor debe estar logueado y tener el rol adecuado(Administrador).
Curso Normal
1- El administrador hace click en el link "Permisos por Roles" 2- El sistema despliega una lista con los roles existentes y su definicin. 3- El aministrador seleccionar un rol determinado haciendo un click sobre el nombre del mismo. 4- El sistema desplegar dos boxes html: el primero contendr todas las funcionalidades sobre las que tiene permiso el rol seleccionado; el segundo contendr todos los permisos no asignados. 5- El administrador podr seleccionar un permiso y aadirlo o quitarlo del rol determinado haciendo un simple drug and drop sobre el box html que corresponda (segn se quiera dar ese permiso o quitarlo).
Curso Alternativo
Postcondiciones:
4. Diseo
Continuando con la etapa de diseo del sistema g-pac08 nos encontramos en la necesidad de modelar la estructura de Base de Datos que utilizar. Para esto nos basamos en modelos llamados Diagramas de Entidad Relacin. stos nos muestran rpidamente cuales son las entidades del sistema y las relaciones que existen entre ellas. A su vez nos apoyaremos en ms diagramas UML para describir un poco mejor cul es el diseo del sistema. Para esto utilizaremos diagramas de clases y diagramas de actividad. El primero nos sirve para entender como acta la compleja estructura de objetos que intervienen en cada pedido al Pgina 44 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
servidor Web (pedido que utiliza el protocolo de comunicaciones HTTPS HyperText Transfer Protocol Secure); la segunda nos ayuda a clarificar y dar ms detalle a uno o varios casos de uso relacionados. Es decir que se apoya en los casos de uso y los extiende especificando detalladamente como suceden las actividades dentro del sistema cuando se ejecuta el o los casos de usos intervinientes.
4.1 U.M.L.
4.1.1 Pedido tpico al servidor Web
Figura 4.1.1 Pedido Tpico al Servidor Web Fuente: http://book.cakephp.org/view/21/A-Typical-CakePHP-Request
El cliente direcciona su navegador ingresando la direccin de su aplicacin, por ejemplo, https://www.midominio.com.ar/users/add . El servidor Web toma el pedido y se lo pasa al objeto CakePHP Dispatcher. Este objeto pasa el pedido hacia el objeto Routes, que es el encargado de Pgina 45 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
desglosar la url en sus partes componentes y pasarle los datos de la accin al controlador, encargado de la lgica de negocio. El controlador es el encargado de por un lado, tomar los datos del modelo o los modelos que tiene asociados, procesarlos y luego pasarle la informacin a la vista correspondiente. En este ejemplo el objeto Routes llama al controlador Users y en particular llama al mtodo add(). Este mtodo es el encargado de ejectuar la lgica de negocio, tomar los datos del modelo asociado y pasarle la informacin procesada a la vista con el mismo nombre (add.ctp). Esta estructuracin de la aplicacin nos permite mucha flexibilidad y por sobre todas las cosas escalabilidad. En la figura 2 mostrada con anterioridad vemos una serie de elementos que no hemos explicado: components, helpers y behaviours. Los componentes fueron creados para asociar una serie de comportamientos polimrficos a distintos controladores en un solo archivo php. De esta forma agrupo comportamientos iguales en un solo lugar y los uso en tantos como sea requerido. Los Helpers y los Behaviours tambin son una extensin a nuestro modelo mvc y tambin sirven para agrupar en un solo lugar tanto vistas comunes de datos como comportamientos, respectivamente. Es decir que el Framework que hemos elegido utiliza muchas por no decir todas las ventajas de la programacin orientada a objetos. Esto nos permite realizar aplicaciones flexibles, escalables y seguras.
4.1.2 Diagramas de Actividades

El fundamento de la utilizacin de los diagramas de actividades se basa en la falta de profundizacin a la que nos dejan librados los casos de uso. Es decir que si bien estos se centran en describir qu sucedera si se ejecutara su curso normal o su curso alternativo no se explica de manera grfica cules son las actividades que tengo que cumplimentar para concretar un determinado objetivo. El diagrama de actividades me permite por un lado mostrar los roles dentro de la plataforma que realizan las actividades y por otro como es el flujo de estas actividades para que el objetivo se lleve a cabo con xito. Un mismo diagrama puede describir uno o varios casos de uso con lo cual es una herramienta de complemento a los casos de uso fundamental.
Pgina 46 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
El diagrama de actividad de Login describe el proceso de inicio de sesin en el sistema gpac08. Se muestran las distintas actividades y sus flujos para llevar a cabo el objetivo final: Usuario logueado con privilegios segn su rol. (Ver Figura 4.1.2.1)
Figura 4.1.2.1 Diagrama de actividades: Login
El diagrama que se muestra en la figura 4.1.2.2 describe el proceso de solicitud de turnos. Vemos claramente que este proceso puede ser disparado por dos roles distintos de la plataforma: Pgina 47 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Secretaria y
Paciente. Es decir que sin haber ledo ni la especificacin del caso de uso ni
cualquier otra documentacin del sistema, notamos rpidamente que los turnos pueden ser realizados tanto por parte del Paciente con su usuario logueado al sistema, como tambin por parte de la secretaria en nombre del usuario existente en el sistema.
Figura 4.1.2.2 Diagrama de actividades: Turnos
El ltimo diagrama descripto en la figura 4.1.2.3 nos muestra cules son las actividades que deben realizar o el mdico, o el paciente para acceder a los datos de una historia clnica. En el primer caso puede darse la situacin en un mdico quiera anticiparse al turno siguiente entonces Pgina 48 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
puede acceder a la ficha o historia clnica del paciente que se va a atender. De esta forma el mdico no slo gana tiempo sino se que se le hace mucho ms claro el proceso de diagnstico del paciente, sin tener que volver a rearmar la historia clnica del paciente. En el caso del paciente es claro que el centro mdico para el que desarrollamos la aplicacin quiere cierta restriccin con respecto al permiso de visualizacin de historias clnicas. Es por este motivo que para que el paciente pueda visualizar su historia clnica, la Secretaria debe previamente autorizarlo.
Figura 4.1.2.3 Diagrama de actividades: Historias Clnicas
Pgina 49 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
4.2 D.E.R.
El diagrama de entidad relacin nos ayuda a ver rpidamente y de forma clara cules son las entidades de datos que intervienen en el sistema y cules son las relaciones entre cada entidad. A partir de este modelo se procede a crear la estructura fsica de la base de datos que utilizaremos en la etapa de implementacin.
Figura 4.2.1 D.E.R. de g-pac08
Pgina 50 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
5. Manual de Usuario
El objetivo del presente manual es brindar al usuario los conocimientos adecuados y necesarios para que pueda interactuar con la aplicacin Web de gestin de pacientes, implementada para el Centro Mdico CIEM. En el mismo se detalla la forma de operar y el resultado esperado para cada una de las opciones de men que conforma el web site para los distintos perfiles.
5.1 Instalacin
Con esta gua se adjunta un CD, el cual contiene las siguientes carpetas: \Aplicacin: contiene todos los archivos que la aplicacin necesita para ejecutarse. \Base de datos: contiene el g-pac08.sql que sirve para instalar la base de datos. \Manuales: este manual est incluido en esta carpeta. \Documento del proyecto: contiene todos los documentos que fueron generados para la realizacin de este proyecto.
5.1.1 Breve resea

Este manual est pensado como una rpida gua para realizar la instalacin de la aplicacin g-pac08. El alcance de este manual no contempla la explicacin de la instalacin y/o configuracin de los sistemas base para correr dicha aplicacin. Es el caso del servidor Web Apache, la base de Datos MySQL y del motor PHP. Para obtener informacin acerca de la instalacin y/o configuracin de dichos sistemas a continuacin se listan sus pginas web: MySQL: http://www.mysql.com Apache: http://www.apache.org CakePHP: http://www.cakephp.org
5.1.2
Requisitos
Tener instalado y funcionando como servicio el webserver Apache 2.2.x, el servidor de base de datos MySQL 5.0.x y el motor PHP 5.2.x. Pgina 51 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Luego de tener todos estos servicios funcionando correctamente se prodr proceder a instalar la aplicacin.
5.1.3 Restore de la base de datos

La aplicacin se basa en una estructura de base de datos que debe ser restaurada antes de poder utilizar la aplicacin. Para la restauracin de la misma utilizaremos el archivo g-pac08.sql que se encuentra en el CD en la carpeta \Base de datos. a) Deberemos conectarnos a la base de datos. Para esto iremos a la lnea de comandos y tipearemos: mysql u root p. Deberemos tener permiso de root sobre la base para poder crear el usuario y la base de datos especfica para nuestra aplicacin. b) Luego de conectarnos a la base de datos deberemos crear el usuario que vamos a utilizar en nuestra aplicacin. Para esto necesitamos primero crear el usuario. Desde la lnea de comandos tipeamos:
CREATE USER 'pacientes'@'localhost' IDENTIFIED BY 'pacientes';
Deberemos crear la base de datos:

CREATE DATABASE `pacientes` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
Luego de crear el usuario deberemos otorgarle los privilegios por sobre la base de datos de la aplicacin:
GRANT ALL PRIVILEGES ON `pacientes` . * TO 'pacientes'@'localhost' WITH GRANT OPTION ;
c) Luego salimos de la aplicacin mysql tipeando exit. Ahora necesitamos restaurar el archivo g-pac08.sql, para lo cual tipearemos:
mysql u pacientes pacientes p < PATH_AL_ARCHIVO
Pgina 52 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Donde el PATH_AL_ARCHIVO es la ruta al archivo de la base de datos g-pac08.sql ubicado en la carpeta \Base de datos.
5.1.4 Instalacin de aplicacin

La instalacin de la aplicacin es un proceso sumamente simple. Basta con dirigirse a la carpeta del CD \Aplicacin y extraer la carpeta cake. Esta carpeta debe situarse en la carpeta /htdocs, situada segn la configuracin del servidor web apache. En linux generalmente se encuentra en /var/www. En cambio, en Windows depender de cada instalacin.
5.1.5 Listo
Una vez restaurada la base de datos y una vez situada la carpeta /cake en la carpeta /htdocs del servidor web apache, usted puede realizar la prueba para ver si est instalado correctamente abriendo un navegador web tipeando la siguiente direccin: https://localhost/cake/app/Pacientes Listo!!! Ingresando el nombre de usuario y la contrasea ya puede empezar a utilizar la aplicacin. Por defecto creamos el usuario admin con password admin para que usted pueda administrar su aplicacin. Por razones de seguridad usted debe cambiar la contrasea de administrador.
5.2 Descripcin general de sistema

La idea general de esta aplicacin es desarrollar una plataforma con funcionalidades y mejoras desde el punto de vista grfico, con el objetivo de facilitar la comunicacin entre los pacientes y el centro; desde la solicitud de turnos hasta el acceso a estadsticas diversas. Para poder acceder al Sistema de Gestin de Pacientes se deber ingresar a la siguiente pgina web: https://consultorio-ciem.com.ar/. A continuacin detallaremos cada uno de los componentes:
5.2.1 Login
En esta seccin se describe la funcionalidad del mdulo correspondiente y se detalla cada una de ellas.
Pgina 53 de 70
Curso/ Grupo
Proyecto

5.2.1.1 Ingresar al sistema

Versin Fecha
5.0
10/11/2009
Para ingresar al Sistema de Gestin de Pacientes, el usuario deber acceder a la pgina que se muestra en la Imagen 5.2.1.1, y seguir los pasos que se detallan a continuacin: 1. Ingresar Nombre de Usuario. 2. Ingresar Clave (contrasea). 3. Presionar el botn Login. Si los datos fueron ingresados de forma correcta entonces se mostrar el home del sistema con las opciones segn el rol que tenga definido dicho usuario en el sistema. En caso de haber introducido mal la contrasea, el usuario podr realizar un nuevo intento hasta la 3ra vez inclusive. Si persistiese el acceso fallido, luego de la 3ra vez el sistema inhabilitar dicha cuenta de usuario por seguridad. Esta cuenta deber ser habilitada por la Secretaria del centro mdico CIEM.
Teclado Virtual
El usuario ingresar su nombre de usuario y la clave de acceso.
Imagen 5.2.1.1 Pantalla de Inicio de Sesin
El usuario podr hacer uso del teclado virtual para hacer ms seguro el acceso a la aplicacin.
Pgina 54 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Imagen 5.2.1.2 Uso de teclado virtual para el ingreso del nombre de usuario seleccionando el teclado que aparece debajo del nombre de usuario.
Imagen 5.2.1.3 Uso de teclado virtual para el ingreso de la contrasea seleccionando el teclado que aparece debajo del nombre de usuario.
Pgina 55 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
5.2.2 Home
Una vez que ha ingresado los datos correspondientes y son validados correctamente, el usuario accede a la pantalla principal del sistema. En ella se listan las funcionalidades a las cuales tiene acceso el usuario segn el rol que le fue asignado a cada uno.
5.2.2.1 Rol Paciente
Imagen 5.2.2.1.1 Pantalla principal de un usuario con el perfil paciente.
Al hacer click sobre
se despliega la siguiente interfaz en donde se muestra un
calendario con todos los turnos de las especialidades solicitadas por el paciente.
Pgina 56 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Vuelve a la pantalla principal
Clickeando aqu se Clickeando aqu se visualizarn los turnos del mes anterior visualizarn los turnos del mes posterior
Turno solicitado
Imagen 5.2.2.1.2 Calendario con los turnos solicitados.
Seleccionando un turno en particular se despliega un pop-up con el nombre del mdico con quien desea atenderse, el horario de atencin y la sede donde se llevar a cabo la consulta.
Al hacer click en
, link ubicado en el extremo inferior izquierdo de la
pantalla, se abrir una nueva pgina donde el paciente podr seleccionar la especialidad a la que desea consultar. Una vez seleccionada, se habilitar un combo con los profesionales que estn encargados de dicha especialidad. El usuario elegir el da en que desea atenderse y el sistema desplegar un formulario con los distintos horarios en que el mdico atiende en ese da, estando habilitados solamente aquellos que no fueron pedidos por ningn otro paciente con anterioridad. Pgina 57 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
en la pantalla principal, se abrir una nueva
pantalla en la cual aparecer una leyenda y un formulario a completar con los motivos de dicha peticin: Para acceder a su historia clnica deber hacer la correspondiente solicitud. Si la solicitud hubiese sido aceptada, en dicha pgina se visualizar un link a la Historia Clnica del paciente.
5.2.2.2 Rol Mdico
Imagen 5.2.2.2.1 Pantalla principal de un usuario con el perfil mdico.
Haciendo click en
el usuario con rol de mdico buscar al paciente
por dni o por el nombre y apellido. Una vez realizada la bsqueda el mdico deber hacer un click sobre el nombre del paciente para poder ver y/o agregar datos a la historia clnica del paciente en cuestin.
Pgina 58 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
se despliega un calendario con los turnos tomados por cada
paciente segn el da escogido. Haciendo un click en el nombre del paciente, se podr acceder a la historia clnica del mismo y agregar informacin si fuere necesario.
Si elige la opcin
, el mdico podr configurar los das y horarios de
atencin en el centro mdio CIEM.
5.2.2.3 Rol Secretaria
Imagen 5.2.2.3.1 Pantalla principal de un usuario con el perfil secretaria.
Haciendo click en
la secretaria podr acceder a un listado de todas
las solicitudes que llegaron por parte de los pacientes para que puedan acceder a sus Pgina 59 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
historias clnicas. En cada fila del lista la secretaria podr realizar un click en el botn autorizar para que dicha solicitud sea aceptada. Haciendo click en la secretaria ingresar en el panel de administracin de
usuarios. Desde aqu podr crear usuarios, y modificar datos de aquellos que ya fueron creados, con la particularidad que el rol de secretaria es quien crea a los mdicos. Al hacer click en aparecer la pantalla de la imagen 5.2.2.3.2 en donde a partir
del DNI se puede buscar al paciente deseado para poder asignarle un turno.
Imagen 5.2.2.3.2 Pantalla de bsqueda de usuarios por DNI.
Si elige la opcin
la secretaria podr hacer la bsqueda del mdico por DNI
o nombre y apellido para asignarle los horarios de atencin en el consultorio. muestra todas las especialidades que atiende el centro mdico. (Ver Imagen 5.2.2.3.3 ) Al seleccionar se despliega una tabla con las
especialidades asignadas a cada mdico. Desde aqu se podr agregar y quitar especialidades. Pgina 60 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Imagen 5.2.2.3.3 Tabla con las especialidades que atiende el consultorio.
5.2.2.4 Rol Administrador
Imagen 5.2.2.4.1 Pantalla principal de un usuario con el perfil administrador
5.2.2.4.2)
Abrir una nueva pantalla con todos los datos de los usuarios. (Ver Imagen
Pgina 61 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Desde esta pantalla el administrador podr realizar tanto edicin de datos de usuario como tambin creacin de usuarios y eliminacin de los mismos.
secretaria. Accediendo a
cumple las mismas funcionalidades que para el rol de secretaria. cumple las mismas funcionalidades que para el rol de
el administrador puede gestionar las capacidades que tiene
el sistema. Est pensado para que cuando se agregue nueva funcionalidad y luego de agregar los archivos correspondientes, el administrador puede crear una nueva capacidad para acceder a dicha funcionalidad. (Ver imagen 5.2.2.4.3). Accediendo a se despliega una tabla donde figuran tolas las
capacidades que posee cada uno de los distintos roles. El administrador podr modificar la asignacin de un rol determinado a una capacidad como as tambin eliminar la asignacin de ese rol a esa capacidad (Ver imagen 5.2.2.4.4).
Pgina 62 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Imagen 5.2.2.4.2 Tabla con los datos de todos los usuarios del sistema.
Imagen 5.2.2.4.3 Pantalla de administracin de capacidades.
Pgina 63 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Imagen 5.2.2.4.4 Pantalla de administracin de capacidades.
Haciendo click en
, en la parte inferior izquierda de la
pantalla, se accede a una pgina donde el administrador podr asignar a un rol una capacidad luego de presionar el botn .
El administrador buscar la capacidad
El administrador buscar el rol

El usuario asigna una capacidad a un rol existente
Imagen 5.2.2.4.5 Asignacin de una capacidad a un rol determinado.
Pgina 64 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Accediendo a acontece en el sistema.
el administrador puedo tener un registro de todo lo que
Al hacer click en
se desplegar una tabla con los distintos roles existentes. El
administrador tiene acceso para agregar nuevos roles, modificar o eliminar alguno existente.
Creacin de un nuevo rol
Imagen 5.2.2.4.6 Administracin de roles.
Imagen 5.2.2.4.7 Pantalla para aadir un nuevo rol.
Pgina 65 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
Haciendo click en que posee el rol de secretaria.
el administrador tendr las mismas funcionalidades
muestra todas las especialidades que atiende el centro mdico. (Igual funcionalidad que el rol secretaria).
Al seleccionar
se despliega una tabla con las
especialidades asignadas a cada mdico. (Igual funcionalidad que el rol secretaria). cumple con las mismas funcionalidades que para el rol de secretaria.
5.2.3 Salir del Sistema

Para terminar la sesin, el usuario (cualquiera sea su perfil) debe hacer clic en el link Logout que se encuentra en la parte inferior de la pantalla Imagen 1.3.1 y automticamente el sistema redirecciona al usuario a la pgina de login que se muestra en la Imagen 1.1.1.
El usuario clicklear aqu para salir del sistema
Imagen 5.2.3.1 Logout
Pgina 66 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
6. Glosario
Apache: servidor de pginas web. http://www.apache.org
CakePHP: framework de desarrollo web para aplicaciones que utiliza el patrn de diseo MVC. http://www.cakephp.org
D.E.R.: diagrama de entidad-relacin. Describe las diferentes entidades que intervienen en el sistema y cules son las relaciones entre ellas.
Framework: Es un conjunto de herramientas que ayudan a los programadores a realizar sistemas de forma ms rpida y segura, asegurando y encapsulando cierta funcionalidad.
http://es.wikipedia.org/wiki/Framework
HTTPS: (HyperText Transport Protocol Secure) Protocolo de comunicaciones seguro usado para la comunicacin entre el cliente y el servidor a travs de la encriptacin de los datos. http://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure
Patrn de diseo: son tcnicas utilizadas dentro de las mejores prcticas para el desarrollo de aplicaciones flexibles, escalables. http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
PHP:(Hypertext PreProcessor) Lenguaje de programacin interpretado que sirve para desarrollo de pginas web. http://www.php.net/
MVC: (model-view-controller o modelo-vista-controlador). Es un patrn de diseo por el cual se modulariza la aplicacin en 3 grupos: 1) vistas, encargadas de la presentacin de la informacin del usuario; 2) modelos, encargados de la interaccin con la base de datos; y 3) controladores, encargados de toda la lgica de negocio. http://es.wikipedia.org/wiki/Modelo_Vista_Controlador Pgina 67 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
MySQL: servidor de base de datos open source. http://www.mysql.com/
RAD:
(RApid
Development)
metodologa
aplicada
al
desarrollo
de
software.
http://en.wikipedia.org/wiki/Rapid_application_development
SSL: (Secure Socket Layer) capa que encripta las comunicaciones de datos en un ra red o en la comunicacin entre un web server y el navegador del cliente.
http://es.wikipedia.org/wiki/Transport_Layer_Security
SVN: sistema de control de versiones para el software. Este sistema ayuda en gran medida a entregar software con una calidad superior. http://subversion.tigris.org/
U.M.L.:(Unified modeling language lenguaje de modelado unificado) Lenguaje grfico utilizado en procesos de desarrollo de software para reflejar las funcionalidades, interaccin, etc, que el sistema deber ofrecer. http://es.wikipedia.org/wiki/UML
7. Bibliografa
7.1 Aplicacin
http://groups.google.com/ http://book.cakephp.org http://www.php.net/
7.2 Hardware
http://httpd.apache.org/docs/2.2/
Pgina 68 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
7.3 Modelado
http://vico.org/ The Unified Modeling Language Reference Manual by James Rumbaugh, Ivar Jacobson, Grady
Booch
Pgina 69 de 70
Curso/ Grupo
Proyecto

Versin Fecha
5.0
10/11/2009
8. Anexos
8.1 ANEXO I: Modelo Historia Clnica
Pgina 70 de 70

EntregaV5 - Final Release

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

EntregaV5 - Final Release

Încărcat de

Drepturi de autor:

Formate disponibile

.

Integrantes del equipo:

Mara Gimena Conde

Federico Jos Botti

Puyol, Mara Elisa

Grupo03 K-4071 Ao 2008

Sistema de gestin de pacientes

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

Se agregan diagramas de actividades y Grupo03 se completa introduccin.

Se agrega descripcin de diagramas Manual de Usuario

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

3.3.2 3.4 3.4.1 3.4.2 4.

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

1.1 Objetivos, Alcances y Lmites

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

1.2 Definicin del Modelo de Ciclo de Vida

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

2.2 Definicin de actividades

2.2.3 Estudio de Factibilidad

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

cual ser el impacto del producto en el mercado.

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

eje de la planificacin a lo largo de todo el proyecto.

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

3.1.2 Identificacin de mdulos

3.1.3 Especificacin de requisitos

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

3.1.3.3 Administracin de usuarios

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

Creacin de usuarios: Para la creacin de un usuario se requerirn los siguientes datos:

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

3.1.3.4 Solicitud de Turnos

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes

asignados del profesional seleccionado.

K-4071 Grupo 03 HABILITACION PROFESIONAL

Sistema de gestin de pacientes