Sistema de Gestion de Pacientes

Curso/ Grupo
Proyecto
K-4071
Sistema de gestin de pacientes
Grupo 03
Versin
Fecha
5.0
10/11/2009
HABILITACION PROFESIONAL
Sistema de Gestin de
Pacientes
Grupo03 K-4071
Ao 2008
La plataforma intenta promover la gestin centralizada de pacientes para los
pequeos y medianos centros mdicos, a travs de solicitudes online segn
disponibilidad de profesionales y turnos; y adems
adems una mejor administracin de
historias clnicas de los clientes.
Integrantes del equipo:

Nombre y Apellido
Legajo
e-mail
Telfono
Federico Jos Botti
119046-5
federicojbotti@yahoo.com.ar
1555980033
Mara Gimena Conde
120810-0
gime_conde@yahoo.com.ar
1558920753
Docentes:
Solanas, Alberto
Puyol, Mara Elisa
Gonzlez, Gerardo
VERSION 1.0
Pgina 1 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
Historial de Revisiones
Fecha
Versin
Descripcin
Autor
28/08/2008
0.5
Definicin de Tareas
Grupo03
01/09/2008
1.0
Primera entrega
Grupo03
15/09/2008
2.0
Especificacin de requisitos
Grupo03
29/09/2008
2.5
Estudio de Factibilidad
Grupo03
06/10/2008
3.0
Anlisis del sistema
Grupo03
08/10/2008
3.5
Especificacin de Casos de Uso
Grupo03
20/10/2008
4.0
DER y UML
Grupo03
03/11/2008
4.2
Se agregan diagramas de actividades y Grupo03

se completa introduccin.
10/11/2008
4.5
Se agrega descripcin de diagramas
Grupo03
10/11/2008
5.0
Manual de Usuario
Grupo03
Pgina 2 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
Tabla de Contenidos
1.
INTRODUCCIN ..............................................................................................................................................5
1.1
1.1.1
Objetivos ..................................................................................................................................................5
1.1.2
Alcances...................................................................................................................................................6
1.1.3
Lmites .....................................................................................................................................................7
1.2
2.
3.
OBJETIVOS, ALCANCES Y LMITES ................................................................................................................5
DEFINICIN DEL MODELO DE CICLO DE VIDA ..............................................................................................7
PLANIFICACIN..............................................................................................................................................9
2.1
CRONOGRAMA DE ACTIVIDADES: GANTT....................................................................................................9
2.2
DEFINICIN DE ACTIVIDADES......................................................................................................................11
2.2.1
Inicio......................................................................................................................................................11
2.2.2
Relevamiento..........................................................................................................................................11
2.2.3
Estudio de Factibilidad..........................................................................................................................11
2.2.4
Planificacin..........................................................................................................................................12
2.2.5
Anlisis ..................................................................................................................................................13
2.2.6
Diseo....................................................................................................................................................13
2.2.7
Implementacin......................................................................................................................................14
ANLISIS .........................................................................................................................................................14
3.1
ANLISIS DE REQUISITOS............................................................................................................................14
3.1.1
Introduccin...........................................................................................................................................14
3.1.2
Identificacin de mdulos......................................................................................................................15
3.1.3
Especificacin de requisitos ..................................................................................................................15
3.2
ESTUDIO DE FACTIBILIDAD .........................................................................................................................23
3.2.1
Estudio de Mercado ...............................................................................................................................23
3.2.2
Factibilidad Tcnica ..............................................................................................................................24
3.2.3
Factibilidad Operativa ..........................................................................................................................26
3.2.4
Factibilidad Econmico-Financiera......................................................................................................28
3.2.5
Conclusin de Factibilidad....................................................................................................................29
3.3
3.3.1
ARQUITECTURA ..........................................................................................................................................29
Definicin de incrementos: mdulos......................................................................................................30
Pgina 3 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
3.3.2
3.4
4.
Fecha
5.0
10/11/2009
Arquitectura...........................................................................................................................................30
CASOS DE USO ............................................................................................................................................34
3.4.1
Diagramas de Casos de Uso..................................................................................................................35
3.4.2
Especificacin de Casos de Uso ............................................................................................................37
DISEO .............................................................................................................................................................44
4.1
U.M.L.........................................................................................................................................................45
4.1.1
Pedido tpico al servidor Web................................................................................................................45
4.1.2
Diagramas de Actividades .....................................................................................................................46
4.2
5.
Versin
D.E.R..........................................................................................................................................................50
MANUAL DE USUARIO.................................................................................................................................51
5.1
INSTALACIN ..............................................................................................................................................51
5.1.1
Breve resea ..........................................................................................................................................51
5.1.2
Requisitos...............................................................................................................................................51
5.1.3
Restore de la base de datos....................................................................................................................52
5.1.4
Instalacin de aplicacin.......................................................................................................................53
5.1.5
Listo .......................................................................................................................................................53
5.2
DESCRIPCIN GENERAL DE SISTEMA ...........................................................................................................53
5.2.1
Login......................................................................................................................................................53
5.2.2
Home......................................................................................................................................................56
5.2.3
Salir del Sistema ....................................................................................................................................66
6.
GLOSARIO.......................................................................................................................................................67
7.
BIBLIOGRAFA ..............................................................................................................................................68
8.
7.1
APLICACIN ................................................................................................................................................68
7.2
HARDWARE.................................................................................................................................................68
7.3
MODELADO .................................................................................................................................................69
ANEXOS............................................................................................................................................................70
8.1
ANEXO I: MODELO HISTORIA CLNICA .....................................................................................................70
Pgina 4 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
Pgina 8 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
2. Planificacin
2.1 Cronograma de actividades: GANTT
Pgina 9 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
Pgina 10 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
3.1.1.2 Problema existente
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
K-4071
Grupo 03
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
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
3.1.3.2 Seguridad
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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.
Historia Clnica.
Citas o turnos.
Pgina 23 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
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.
-
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
3.2.4 Factibilidad Econmico-Financiera

Detalle
Horas
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
Costo
1 hs.
29 hs.
29 hs.
16 hs.
40 hs.
$ 20,00
$ 4.640,00
$ 4.640,00
$ 240,00
$ 800,00
$ 200,00
Total $ 10.540,00
2 hs.
Total
$ 40,00
$ 160,00
$ 24,00
$ 224,00
Total
$ 0,00
$ 0,00
Promocin
Soporte Online post implementacin (1 semana)
Tabla 3.2.4.1 Costos detallados
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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.
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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.
Versin
Fecha
5.0
10/11/2009
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.
5- El usuario confirmar la cuenta e ingresa al sistema con su usuario y

la contrasea asignada.

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.

Actor:
Objetivos:
Solicitar Turno
Paciente, Secretaria
Realizar la reserva de un turno.
Pgina 38 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
Precondiciones:
Versin
Fecha
5.0
10/11/2009
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.
Curso Normal
6.1- En caso de que el paciente desee cancelar la cita, ver

extend "Modificar Solicitud"
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
K-4071
Grupo 03
Postcondiciones:
Turno reservado por el paciente.

Actor:
Objetivos:
Modificar Solicitud
Precondiciones:
Versin
Fecha
5.0
10/11/2009
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
Actor: Paciente
Curso Alternativo
1- El paciente clickea sobre modificar turno.
1.1- El paciente clickea sobre cancelar turno.
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.
1.2- El sistema muestra una pantalla de confirmacin y

procede a cancelar dicho turno, habilitandolo para que pueda
ser elegido por otro paciente.
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
K-4071
Grupo 03
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.

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.
3.1- En caso de que la solicitud no fuese justificada, se le

revocar el permiso e informar va e-mail al paciente.
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.
Postcondiciones:

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
K-4071
Grupo 03
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:

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.
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- El sistema mostrar la estadstica seleccionada por el mdico:

mostrando tablas, grficos, etc. segn corresponda.
4.1- El sistema mostrar la estadstica seleccionada por el

paciente: mostrando tablas, grficos, etc. segn corresponda.
Postcondiciones:

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
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009

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:

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:

Actor:
Objetivos:
Precondiciones:
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
K-4071
Grupo 03
Curso Normal
Versin
Fecha
5.0
10/11/2009
Curso Alternativo
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.
Postcondiciones:

Actor:
Objetivos:
Precondiciones:
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
Curso Alternativo
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).
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
Secretaria y
Versin
Fecha
5.0
10/11/2009
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
5.2.1.1 Ingresar al sistema
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
Vuelve a la pantalla principal
Clickeando aqu se
visualizarn los turnos del
Clickeando aqu se
mes posterior
visualizarn los turnos del

mes anterior
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
Abrir una nueva pantalla con todos los datos de los usuarios. (Ver Imagen
5.2.2.4.2)
Pgina 61 de 70
Curso/ Grupo
Proyecto
K-4071
Grupo 03
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.
cumple las mismas funcionalidades que para el rol de secretaria.
cumple las mismas funcionalidades que para el rol de
secretaria.
Accediendo a
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
K-4071
Grupo 03
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
K-4071
Grupo 03
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
K-4071
Grupo 03
Accediendo a
Versin
Fecha
5.0
10/11/2009
el administrador puedo tener un registro de todo lo que
acontece en el sistema.
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
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
Haciendo click en
el administrador tendr las mismas funcionalidades
que posee el rol de secretaria.

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
K-4071
Grupo 03
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
segura,
asegurando
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
K-4071
Grupo 03
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
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
K-4071
Grupo 03
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
K-4071
Grupo 03
Versin
Fecha
5.0
10/11/2009
8. Anexos
8.1 ANEXO I: Modelo Historia Clnica
Pgina 70 de 70

Sistema de Gestion de Pacientes

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema de Gestion de Pacientes

Cargado por

Copyright:

Formatos disponibles

Curso/ Grupo

Sistema de gestin de pacientes

Integrantes del equipo:

Federico Jos Botti

Mara Gimena Conde

Sistema de gestin de pacientes

Anlisis del sistema

Especificacin de Casos de Uso

Se agregan diagramas de actividades y Grupo03

Se agrega descripcin de diagramas

Sistema de gestin de pacientes

OBJETIVOS, ALCANCES Y LMITES ................................................................................................................5

DEFINICIN DEL MODELO DE CICLO DE VIDA ..............................................................................................7

CRONOGRAMA DE ACTIVIDADES: GANTT....................................................................................................9

Especificacin de requisitos ..................................................................................................................15

ESTUDIO DE FACTIBILIDAD .........................................................................................................................23

Estudio de Mercado ...............................................................................................................................23

Factibilidad Tcnica ..............................................................................................................................24

Factibilidad Operativa ..........................................................................................................................26

Sistema de gestin de pacientes

Diagramas de Casos de Uso..................................................................................................................35

Especificacin de Casos de Uso ............................................................................................................37

Pedido tpico al servidor Web................................................................................................................45

Diagramas de Actividades .....................................................................................................................46

Breve resea ..........................................................................................................................................51

Restore de la base de datos....................................................................................................................52

DESCRIPCIN GENERAL DE SISTEMA ...........................................................................................................53

Salir del Sistema ....................................................................................................................................66

ANEXO I: MODELO HISTORIA CLNICA .....................................................................................................70

Sistema de gestin de pacientes

1.1 Objetivos, Alcances y Lmites

Sistema de gestin de pacientes

Adems se asegura el desarrollo en un marco orientado a la seguridad y confidencialidad de

El sistema contempla cuatro clases de usuario o roles: mdicos, secretarias, pacientes,

El sistema contemplar la calendarizacin de las consultas mdicas mediante una interfaz

Luego de la primer consulta se mantiene el registro de lo acontecido en cada turno mdico,

Existir un mdulo de estadsticas de toda clase: tiempo de atencin, cantidad de pacientes

Sistema de gestin de pacientes

No se contemplarn las urgencias mdicas.

1.2 Definicin del Modelo de Ciclo de Vida

El proyecto se llevar a cabo teniendo en cuenta un modelo incremental prototipado no

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

Sistema de gestin de pacientes

Sistema de gestin de pacientes

Sistema de gestin de pacientes

Sistema de gestin de pacientes

2.2 Definicin de actividades

Definicin de objetivos, alcances y lmites: Especificar minuciosamente cada uno de estos

2.2.3 Estudio de Factibilidad

Luego de tener los requisitos debidamente especificados, se proceder a realizar el estudio de

Sistema de gestin de pacientes

cual ser el impacto del producto en el mercado.

Estudio de Mercado: Analizaremos el contexto en el que se sita el proyecto: la competencia,

Factibilidad Econmico-Financiera: Analizar los gastos en los que debe incurrir la

Sistema de gestin de pacientes

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

UML: se pretende describir el comportamiento, la interaccin, la comunicacin, etc. entre los

Sistema de gestin de pacientes

Sistema de gestin de pacientes

3.1.1.2 Problema existente

Actualmente se puede observar inconvenientes al momento de la solicitud de turnos por parte

3.1.2 Identificacin de mdulos

3.1.3 Especificacin de requisitos