Tesina Gloria Vazquez PDF

UNIVERSIDAD POLITÉCNICA DE VICTORIA
DESARROLLO DE SISTEMA WEB PARA

SERVICIOS DE COMUNICACIÓN MEDICA
TESINA
QUE PARA OBTENER EL GRADO DE
INGENIERÍA EN TECNOLOGÍAS DE LA
INFORMACIÓN
PRESENTA:
VÍCTOR MANUEL GLORIA VÁZQUEZ
DIRECTOR
DR. SAID POLANCO MARTAGÓN
ORGANISMO RECEPTOR
UNIVERSIDAD POLITÉCNICA DE VICTORIA
CIUDAD VICTORIA, TAMAULIPAS, DICIEMBRE DE 2017
CARTA DE ACEPTACIÓN DEL DOCUMENTO PARA SU
IMPRESIÓN
Cd. Victoria, Tamaulipas a 12 de Diciembre de 2017
Vı́ctor Manuel Gloria Vázquez

PRESENTE
Le comunico que el Programa Académico de Ingenierı́a en Tecnologı́as de la

Información le ha otorgado la autorización para la impresión de su Tesina de
Estadı́a Práctica cuyo tı́tulo es:
Desarrollo de sistema web para servicios de comunicación medica
ATENTAMENTE
Dr. Said Polanco Martagón

ASESOR INSTITUCIONAL
c.c.p Director de programa académico
AV. NUEVAS TECNOLOGÍAS 5902 UNIVERSIDAD

PARQUE CIENTÍFICO Y POLITÉCNICA
TECNOLÓGICO DE TAMAULIPAS
DE VICTORIA
CARRETERA VICTORIA SOTO LA
MARINA KM. 5.5
CD. VICTORIA, TAMAULIPAS. TELS. (834) 1711100 AL 10
C P. 87138 FAX EXT. 5000 Y 5001
WWW.UPVICTORIA.EDU.MX
REGISTRO DE EVALUACION DE EXPOSICIÓN DE ESTADÍA
Siendo las hrs del dı́a de de 201 ,

el alumno Vı́ctor Manuel Gloria Vázquez, del programa académico
Ingenierı́a en Tecnologı́as de la Información, con matricula 1430258,
presentó la exposición de la estadı́a realizada durante el cuatrimestre septiembre-
diciembre 2017, en Universidad Politécnica de Victoria, con el proyecto
titulado Desarrollo de sistema web para servicios de comunicación
medica.
Una vez concluido el proceso de evaluación, y con base a la rúbrica estable-

cida para éste propósito, se determina que la calificación de la estadı́a es
.
Dr. Said Polanco Martagón

ASESOR INSTITUCIONAL
MSC. Jorge Arturo Hernández Almazan

EVALUADOR
EVALUADOR DE INGLÉS
AV. NUEVAS TECNOLOGÍAS 5902 UNIVERSIDAD
PARQUE CIENTÍFICO Y POLITÉCNICA
TECNOLÓGICO DE TAMAULIPAS
DE VICTORIA
CARRETERA VICTORIA SOTO LA
MARINA KM. 5.5
CD. VICTORIA, TAMAULIPAS. TELS. (834) 1711100 AL 10
C P. 87138 FAX EXT. 5000 Y 5001
WWW.UPVICTORIA.EDU.MX
Agradecimientos
iii
Resumen
En el presente documento se describen las actividades llevadas a cabo en el cumplimiento del
periodo de estadı́a, comprendido del 4 de Septiembre del 2017 al 1 de Diciembre del 2017, en
el proyecto titulado “Desarrollo de Sistema web para servicios de comunicación médica”.
Dada la necesidad de ayudar a optimizar la gestión de las agendas médicas y la comunicación

entre médicos y pacientes, se decidió desarrollar un sistema web, en el cual los pacientes,
médicos y administradores puedan realizar las agendas de citas, comunicación, crear recetas
electrónicas y mantener comunicación mediante un módulo de chat, además, de que los pa-
cientes puedan localizar en un mapa consultorios médicos permitiendo su ubicación, y de
esta forma encontrar los consultorios más cercanos. Para lograr ésto, se tuvo que realizar el
diseño del sistema, la estructura de los datos, seleccionar la metodologı́a de trabajo, elegir
las tecnologı́as que beneficien al sistema para cumplir con las metas propuestas.
Como resultado se obtuvo un sistema web, con el los pacientes pueden encontrar en un mapa
los consultorios médicos cercanos, ver la información del consultorio y seleccionar a alguno
de los médicos que laboran ahı́ y en caso de ası́ desearlo, agendar una cita médica en los
horarios que anteriormente han sido establecidos por el médico, ası́ mismo, tanto el médico
como el administrador pueden gestionar la agenda, editar, agregar o eliminar si es necesario,
cuando se hace una modificación a la cita, se le envı́a una notificación a cada uno de los
usuarios participantes, ası́ mismo, el médico puede realizar una receta médica, la cual se crea
en pdf y envı́a al paciente.
Palabras claves: Modelo Vista Controlador, Sistema Web, Prescripción Médica, Consulto-
rio Médico.
iv
Summary
This document describes the activities carried out in compliance with the internship period,
from September 4, 2017 to December 1, 2017, in the project entitled “Development of a web
system for medical communication services”.
Given the need to help optimize the management of medical agendas and communication
between doctors and patients, it was decided to develop a web system, in which patients,
doctors and administrators can make appointment schedules, create electronic recipes and
maintain communication by means of a chat module, in addition, that patients can locate on a
map medical offices allowing their location, and in this way find the closest offices. To achieve
this, the design of the system, the structure of the data, the selection of the work methodol-
ogy, the choice of technologies that benefit the system to meet the proposed goals were made.
As a result a web system was obtained, with the patients can find on a map the nearby
medical offices, see the information of the office and select one of the doctors who work there
and if desired, schedule a medical appointment in the schedules that previously have been
established by the doctor, likewise, both the doctor and the administrator can manage the
agenda, edit, add or delete if necessary, when a modification is made to the appointment,
a notification is sent to each one of the participating users, likewise, the doctor can make a
medical prescription, which is created in pdf and sent to the patient.
Keywords: Model View Controller, Web System, Meical Prescription, Doctor’s office.
v
Índice
Agradecimientos iii
Resumen iv
Summary v
Índice vi
1 Introducción 1
1.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Objetivo Particular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Descripción y Alcances del Proyecto . . . . . . . . . . . . . . . . . . . . . . . 8
2 Marco Teórico 9
2.1 Sistemas web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Ventajas y Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Protocolo HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Arquitectura cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Modelo-Vista-Controlador(MVC) . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Uso en sistemas web . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Transferencia de Estado Representacional(REST) . . . . . . . . . . . . . . . 14
2.3.1 Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Modelo Entidad-Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Notificaciones push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.1 Service Workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Sistema Propuesto 18
3.1 Descripción General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Análisis de los módulos del sistema . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.1 Login de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.2 Selección de consultorio . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.3 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.4 Prescripciones electrónicas . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.5 Selección de médico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.6 Búsqueda de consultorio . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.7 Módulo chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.8 Notificaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
vi
3.5.1 Caso de uso del login . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5.2 Caso de uso para la búsqueda de consultorios . . . . . . . . . . . . . 27
3.5.3 Caso de uso para el chat de usuarios . . . . . . . . . . . . . . . . . . 28
3.5.4 Caso de uso del módulo de prescripciones electrónicas . . . . . . . . . 29
3.5.5 Caso de uso del módulo de selección de consultorio . . . . . . . . . . 30
3.5.6 Caso de uso del módulo de selección de médico . . . . . . . . . . . . . 31
3.5.7 Caso de uso del módulo de agenda . . . . . . . . . . . . . . . . . . . 32
3.6 Diseño de la Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6.1 Gestión de roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6.2 Agenda de citas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6.3 Prescripciones electrónicas . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6.4 Búsqueda de consultorios . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6.5 Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6.6 Notificaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6.7 Tablas laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6.8 Entidades de la base de datos . . . . . . . . . . . . . . . . . . . . . . 36
3.7 Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7.1 Selección de token de notificaciones . . . . . . . . . . . . . . . . . . . 38
3.7.2 Cambio de horarios automático . . . . . . . . . . . . . . . . . . . . . 39
4 Resultados 40
4.1 Hardware utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Software utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Elementos a evaluar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.1 Prueba de responsividad . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.2 Prueba de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.3 Prueba de notificaciones . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.4 Prueba de chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.5 Prueba de gestión de agendas . . . . . . . . . . . . . . . . . . . . . . 44
5 Conclusiones y Trabajo Futuro 45
Índice de figuras 46
Índice de tablas 47
Referencias 48
vii
1 Introducción
Hoy en dı́a, los sistemas de información otorgan una gran cantidad de beneficios como son:
el rápido acceso a la información, fácil realización de tareas, mayor cantidad de procesos de
manera simultánea, generación de reportes, la capacidad de trabajo a distancia, etc. Dichos
beneficios han sido observados por las organizaciones, haciendo que cada vez más de éstas
migren los procesos más importantes con sus clientes, a nuevos y modernos sistemas, bene-
ficiando sus actividades, reduciendo los márgenes de error, tiempos y papeleos. Por su lado,
los clientes también han tomado parte del cambio a los sistemas de información, ya que optan
por el uso en la realización de sus tareas del dı́a a dı́a, ésto con la finalidad de ahorrar tiempo
y dinero, puesto que se sustituye el acudir a las instalaciones de la organización y hacer
largas filas para presentar documentos, realizar formularios u otras actividades. En general,
estos sistemas aportan al usuario las ventajas de tener un mayor control y administración de
sus actividades. Algunos ejemplos de sistemas de información implementados por las orga-
nizaciones son: Microsoft Dynamics [1], IMSS Digital [2], CONTPAQ [3], SALESFORCE [4].
Consecuentemente, los sistemas de información se han vuelto una herramienta vital en el

funcionamiento y contacto con los clientes de las distintas organizaciones alrededor de todo
el mundo, ya que por ellos fluye información sumamente importante, la cual debe de ser
correctamente procesada, manteniendo la seguridad, para posteriormente almacenarla en los
servidores de la organización.
De igual forma, las instituciones médicas tanto públicas como privadas, han sido parte de los
cambios de la era digital, adquiriendo software especializado para resolver ciertos problemas.
Una de las problemáticas que tienen las instituciones médicas, la cual puede ser solucionada
mediante un sistema de información, es la comunicación médico-paciente, donde con los
métodos de antaño el paciente tenı́a que asistir al consultorio, para poder realizar ciertas
tareas como lo es el agendar o hacer cambios a las citas. En la Figura 1 se ve representado
un diagrama de flujo el proceso tradicional para realizar una cita médica.
Sin duda alguna, la importancia de la comunicación es un punto clave a la hora de establecer

un diagnóstico médico, dado que es cuando el paciente expone al médico información pri-
mordial sobre su estado de salud e historia clı́nica, ası́ como los sı́ntomas que se presentan,
detalles sobre las enfermedades que han manifestado sus familiares, alimentación, actividades
fı́sicas, ritmo de vida y en general, situaciones que pueden influenciar en la salud y que son de
suma importancia cuando se realiza un diagnóstico sobre la salud del paciente. Por otro lado,
el médico da al paciente sus conclusiones, cuáles son los detalles encontrados, y que es lo que
se debe hacer para poder solucionar el problema, para ello el médico da instrucciones que el
paciente debe seguir, los medicamentos que debe de tomar, las recomendaciones generales y
pasos que deben de ser seguidos al pie de la letra para garantizar el éxito del tratamiento.
Éste tipo de comunicación, puede ser considerada meramente informativa e instructiva [5],
ya que como se mencionó, sólo se basa en información proporcionada por el paciente e in-
strucciones y detalles dados por el médico.
Por lo anterior, se plantea que mediante un sistema de información web, pacientes y médicos
1
puedan tener una comunicación sencilla y eficaz, en el cual, el paciente tenga la capacidad
de acceder y ver en un mapa todos los consultorios médicos cercanos a su ubicación, en
donde podrá acceder a la información del consultorio seleccionado y a la información del
médico o médicos que atienden, una vez elegido un médico, el usuario podrá agendar una
cita a disposición de los horarios preestablecidos por el médico, agregando la información más
relevante sobre la consulta, por su parte, el médico podrá administrar su agenda haciendo
las modificaciones que crea necesarias, para posteriormente, generar una receta médica, la
cual podrá ser enviada al paciente, cuidando de la privacidad de la información y que sea
únicamente accedida por el médico y por el paciente.
Figura 1: Diagrama de flujo para realizar citas médicas.
De esta manera, el presente trabajo se abordaran temas sobre el desarrollo de este proyecto,
la estructura que tomará éste documento inicia con los antecedentes, trabajos similares que
2
anteriormente han sido desarrollados; posteriormente se hará mención de la justificación de

este proyecto, al igual que su objetivos y descripción; continuando, se detallaran las ideas,
y procedimientos, llevados a cabo; después se realizará un análisis del sistema propuesto, se
explicará el diseño del mismo, el diseño de la base de datos y los correspondientes diagramas
de casos de uso y de contexto; posteriormente hará un análisis de los resultados obtenidos;
para finalizar, se hablara sobre las conclusiones obtenidas, y el trabajo futuro.
1.1 Antecedentes
El uso de las computadoras, ha facilitado y revolucionado la forma de trabajar y de vivir de
millones de personas alrededor del mundo, al ahorrar tiempo y dinero en el procesamiento y
traslado de la información.
Naturalmente, al igual que en otros tipos de organizaciones, el uso de los sistemas de infor-
mación fue adoptado para su utilización en el ámbito médico, generando que la comunicación
médico-paciente sea mucho más rápida y eficaz de lo que era anteriormente, logrando ası́,
que las recomendaciones, agendas y recetas tengan un mayor seguimiento para, lograr los
resultados esperados [6].
Actualmente las tecnologı́as han cobrado mayor importancia en cualquier ámbito, y más aún
si de medicina se trata, pues tal como lo menciona Veloz Martı́nez, Almanza Velasco, Uribe
Ravell, Dı́az González, Quintana-Romero, Alanı́s López “en el área de la salud, el crecimiento
de Internet como medio de comunicación masivo ha revolucionado el manejo e intercambio
de información en medicina” [7]. Lo cual quiere decir, que el uso de las tecnologı́as de la
información en el ámbito médico, es algo muy importante, puesto el intercambio de infor-
mación otorga a los médicos el acceso a una gran cantidad de datos.
Miguel Ángel Mayer doctor en Ciencias de la salud y de la vida de la universidad Pompeu

Fabra en su artı́culo “El correo electrónico en la relación médico-paciente: uso y recomen-
daciones generales”, habla sobre las tecnologı́as de la información entre las comunicaciones
médico-paciente [8], especı́ficamente sobre el uso del correo electrónico, mencionando los dis-
tintos beneficios que puede proveer para la comunicación, como lo son: el almacenaje de
información relevante, la comunicación a distancia, el envı́o sobre resultados de laboratorio,
seguimiento de enfermedades, etc. También se hace mención sobre la adaptación de ciertos
tipos de personas a éste tipo de comunicación, dado que se deben tener en cuenta algunos
factores como los socioeconómicos y los culturales, ya que pueden ser un factor clave en el
éxito de la comunicación.
El artı́culo “Acceso y uso de las tecnologı́as de información y comunicación y percepciones

hacia un sistema informático para mejorar la adherencia al tratamiento, en médicos en-
docrinólogos de un hospital público de Perú.” [9] de Walter H. Curioso, Ernesto Gozzer y
Juan Rodrı́guez Abad, especialista en informática Biomédica, especialista en salud interna-
cional y magı́ster en administración de negocios respectivamente, se hace una investigación
sobre los beneficios de la implementación de los sistemas información en el área médica, donde
3
se procesa información de suma importancia: como las historias clı́nicas, historias de salud,
etc. Se hace mención que cuando un centro de salud implementan sistemas de información,
generalmente mejoran los procesos internos, lo cual conlleva una mejor atención a los pa-
cientes haciendo que la tasa de mortalidad disminuya. Ésto demuestra que con la correcta
implementación de un sistema de información, los servicios prestados por un hospital, pueden
ser más efectivos y dar una mayor calidad a la atención del paciente.
Por lo tanto, se dio inició al desarrollo de sistemas de información especializados en las

actividades de los centros de salud, ası́ forma nacieron los SIH(Sistemas de información
hospitalaria) [10], los cuales tienen como principal objetivo el apoyo a los procesos y toma
de decisiones que son llevados a cabo en los hospitales, ya que intervienen en la gestión,
procesamiento, almacenamiento y distribución de la información de la inmensa base de datos
que es alimentada dı́a con dı́a por cada una de las distintas áreas en los centros de salud.
A su vez, con el rápido desarrollo de los centros de salud, el aumento de las necesidades
que son requeridas, la cada vez mayor cantidad de información que es generada, los SIH
se han visto obligados a incrementar sus funcionalidades, teniendo que realizar tareas más
especı́ficas y delicadas, las cuales, requieren grandes procesamientos de información. Un
ejemplo de las tareas que son realizadas por los SIH es la generación de reportes e informes,
que posteriormente son utilizados a la hora de la toma decisiones, ésto con el objetivo de
fortalecer la atención y calidad de los servicios que son prestados por la institución [11]. A
continuación de presentan otros ejemplos de usos para los SIH según Francisco J. Fernández
Puerto y Florina Gatica Lara [11]:
• Gestión de los pacientes.
• Administración de los recursos económicos.
• Comunicación entre médicos y pacientes.
• Control de información de los medicamentos.
• Consulta de información sobre pacientes.
• Administración de los horarios.
• Sistema de Manejo de Materiales.
El flujo de la información es el elemento más importante que participa en los procesos de

los SIH, dado que “El funcionamiento de un hospital, al igual que en cualquier empresa,
depende de lo bien que se utilicen sus recursos. La maquinaria, material diverso, el dinero,
las personas y la información son todos recursos; pero la información es, quizá, el recurso más
valioso que cualquier empresa tiene, ya que sin él todos los demás recursos quedan aislados e
inmanejables.” [12]. Por dicha razón, los SIH se han vuelto sumamente importantes, dado
que son parte de los pilares en el correcto funcionamiento de los hospitales, ésto debido a
que su uso con el paso de los años ha ido aumentando, generando que la mayor parte de la
información fluya por dichos sistemas, dejando por un lado el uso de libretas u otros métodos
4
de almacenamiento.
En los años 50’s y 60’s, con el avance de las tecnologı́as de salud, el volumen de la información
generada aumentó considerablemente; con ello el procesamiento de la información se volvió
una tarea más compleja y tediosa, la cual requerı́a una mayor cantidad de recursos para que
fuera correctamente realizada [13], de ésta forma surgió la necesidad de una herramienta que
diera apoyo para solucionar el problema del aumento del procesamiento de la información.
Durante las décadas de los 50’s y 60’s, , con el naciente uso de las tecnologı́as de la infor-
mación, las computadoras fueron introducidas en la medicina, casi al mismo tiempo que su
uso en los negocios y en la ciencia, aunque su uso era mediante las llamadas ”Computadora
central”, las cuales eran grandes y costosas computadoras, las cuales requerı́an una gran
inversión de mantenimiento, y controles climáticos, lo cual, obligaba a los hospitales a usar
computadoras centrales compartidas para poder solventar los costos que se requerı́an [14].
Inicialmente, las sistemas de computadoras tenı́an como función el almacenar información
acerca del paciente, para estudiar sus diagnósticos y ayudar a la toma de decisiones, el poten-
cial de éste tipo de sistemas fue rápidamente observado y aprovechado, generando que para
mediados de los años 60’s, las computadoras dejarán de ser vistas como una herramienta
más, sino como parte fundamental en la ayuda en el cuidado del paciente [15].
Para las décadas de los 70’s y los 80’s, el uso de los sistemas informáticos aumentó consid-
erablemente, debido al uso de computadores personales ya que gracias a su menor costo,
las instituciones médicas podı́an darse el lujo de obtener equipos con mayor capacidad y
mejores sistemas. Aunque durante éstos años, el desarrollo de los sistemas de información
en los hospitales fue enfocado mayoritariamente en las finanzas desarrollando sistemas que
tuvieran la capacidad de aumentar los ingresos, el uso que se le daba la información del
paciente generalmente era para poder llevar un registro de los costes que generaba, lo cual
provocó que los esfuerzos innovación en la ayuda de los médicos y pacientes disminuyeron en
gran parte, generando un menor avance en éstas áreas [12].
Durante los años 90, el avance de los SIH dio un gran salto, ya que se inició el desarrollo
de sistemas distribuidos, de esta manera la información del hospital pudo ser correctamente
organizada y compartida para su uso en todas las áreas donde fuera necesaria [14]. Por lo
tanto, los SIH se fueron enfocando más en la información del paciente, extendiéndose al área
de historia clı́nica, obteniendo datos acerca de la consulta y con ésto mejorar la atención
prestada. Se observó que el contar con sistemas de información, hacı́a que la atención al
paciente fuera más efectiva, ya que se podı́an dar indicaciones y recordatorios electrónicos,
los cuales ayudaban en el tratamiento al mantener la información accesible de forma rápida
[16]. Otro evento ocurrido durante esta época, fue el nacimiento de la World Wide Web, la
cual junto con el internet, revolucionaron inmensamente el uso de las computadoras, ya que
mejoraron la forma en que las organizaciones trabajaban y comunicaban entre sı́ [16].
Con la llegada del nuevo milenio, el uso de las Tecnologı́as de la información se hizo parte
del dı́a a dı́a en los centros de salud, tanto ası́ que la gran mayor parte de las organiza-
ciones médicas tuvieron que implementar sistemas capaces de recopilar,procesar y compartir
información sobre los pacientes y sus cuidados [16]. En ésta época, el uso del Internet se
5
expandió aún más, dando acceso a áreas rurales, mejorando el traslado de la información. De
la misma forma, el avance de los dispositivos móviles incrementó aún más la eficiencia de las
comunicaciones, ya que con estos dispositivos el médico y el paciente tienen la capacidad de
compartir información de manera remota, y de esta forma llevar un mayor control acerca de
los tratamientos que el paciente necesita [16]. Cada vez más empresas de tecnologı́a vieron
el potencial que contaban los sistemas médicos en el área de salud, por lo tanto, se han ido
desarrollando sistemas que apoyan la calidad de la atención del paciente, creando ası́ progra-
mas que se integraron a los centros de salud [16].
Algo muy importante de lo que se han beneficiado las instituciones médicas de las tecnologı́as
de la información, es el uso de agendas electrónicas, ya que con ellas, se tiene la capacidad
de organizar fácilmente el control y acceso a las agendas del médico, logrando ası́ organizar
mejor sus tiempos, tener un mayor control sobre las citas del dı́a, evitar confusiones en los
horarios establecidos, etc. Además, gracias a las agendas electrónicas, el paciente tiene la
capacidad de poder agendar una cita sin la necesidad de dirigirse al consultorio médico. Un
claro ejemplo del uso de agendas de éste tipo es el IMSS(Instituto Mexicano del Seguro So-
cial ) [2], el cual cuenta con un sistema de agendas electrónicas para sus derechohabientes,
e puede ser accedido mediante la plataforma web o la aplicación para dispositivos móviles.
El uso de este sistema permite al usuario agendar citas en un plazo de 5 dı́as hábiles en los
horarios disponibles y en el consultorio asignado previamente por la institución [2].
Ası́ como con las agendas electrónicas, el uso prescripciones electrónicas es algo que poco a
poco se ha ido expandiendo con el paso de los años, sustituyendo el uso de las prescripciones
escritas a mano. El uso de prescripciones médicas en papel es algo que los médicos han
hecho tradicionalmente, y ası́ mismo, a los médicos se les ha asociado que tienen una mala
letra. Lamentablemente, el uso de este tipo de prescripciones ha llevado consigo muchos
errores y malinterpretaciones. Letra ilegible, falta de letras, palabras mal escritas, este tipo
de errores pueden causar graves complicaciones, e incluso ocasionar la muerte del paciente.
La FDA(Food and Drug Administration de Estados Unidos) expuso que errores tan simples,
como el confundir una letra con otra puede generar graves consecuencias. Por ejemplo: A un
paciente se le recetó 20 unidades de insulina, abreviado como “20 U”, donde la ‘U” fue confun-
dida con un cero, causando que el paciente se administrara 200 unidades de insulina, dando
como resultado la muerte [17]. Investigadores encontraron que por cada 100 prescripciones,
37 contenı́an errores, aunque la mayorı́a de los errores no son graves, se estima que aproxi-
madamente el 7% pueden ocasionar daño que ponga en peligro la integridad del paciente [18].
Por otro lado, el uso de prescripciones electrónicas ha venido a sustituir los problemas que
trae el uso de papel. Comúnmente, es menos probable equivocarse dando instrucciones en
una computadora, que escribirlas manualmente, ya que con el uso de una computadora, se
puede tener listas de sugerencias, validaciones de errores y en caso de ser necesario, modi-
ficar únicamente una parte, en lugar de tener que reiniciar el proceso nuevamente, además
de evitar los errores, otorgan una serie de ventajas como lo son: mantener un historial del
paciente, fácil corrección en caso de ser necesario, fácil de entender por parte del paciente.
Actualmente el uso de prescripciones electrónicas está expandiéndose cada vez en hospitales
de Estados Unidos, como es el ejemplo del estado de Nueva York , donde por ley los médicos
6
tienen que dar prescripciones electrónicas a sus pacientes, ésto con el fin de evitar los proble-
mas que generan las prescripciones escritas a mano, además de luchar contra la falsificación
de prescripciones para su uso indebido [19]. En México, el uso de prescripciones electrónicas
no está muy generalizado, aunque eso no implica que no existan alternativas que pueden ser
utilizadas, como ejemplo: Prescrypto, que es un sistema de prescripciones electrónicas, en
donde el médico puede registrarse, y enviar mediante correo electrónico recetas a sus pa-
cientes [20].
1.2 Justificación
En la actualidad, con el ritmo de vida acelerado que llevan las personas, el tiempo es un bien
muy preciado, el cual no debe de ser desperdiciado. El realizar citas médicas es algo que
puede tomar algo de tiempo, dado que se tiene que ir al consultorio para agendar una cita
donde se corre el riesgo de que no estén atendiendo o que en ocasiones es necesario hacer
hacer largas filas que pueden tomar más de una hora de espera. También es importante
mencionar, que en ocasiones los médicos pueden ocuparse de un momento a otro, viéndose
en la necesidad de cancelar todas las citas de un determinado rango de tiempo, donde es
necesario avisar a cada uno de los pacientes para evitar inconformidades. El uso de pre-
scripciones médicas representan ciertos riesgos, como recetas mal escritas, malinterpretación
por parte del farmacéutico o paciente, lo que puede causar la confusión de medicamentos
y dosis mal administradas. Aunque existen diversas opciones en cuanto a la búsqueda de
consultorios médicos y gestión de agendas, dichas soluciones no dan el beneficio al usuario de
poder encontrar en un mapa los consultorios más cercanos a su ubicación, lo que supondrı́a
una facilidad al usuario, puesto que es fácil saber cómo llegar al consultorio mediante un
mapa, en el sistema explicado en este documento si está implementado la opción de realizar
una búsqueda de consultorios médicos en un mapa, otra ventaja del presente sistema, es la
implementación de un chat entre médicos y pacientes, en el cual se estarán enviando actual-
izaciones mutuamente y servirá como canal de comunicación para llevar a cabo el tratamiento.
1.3 Objetivo General

Diseñar y desarrollar módulos especı́ficos y base de datos de una aplicación web de comuni-
cación médico-paciente, donde se podrán elegir consultorios y médicos, para posteriormente
el paciente pueda agendar una cita en los horarios establecidos por el médico, además, el
médico podrá gestionar sus citas, y enviar recetas médicas a los pacientes. La aplicación
web tendrá que garantizar la seguridad, confidencialidad y comunicación entre consultorios
médicos y público en general.
1.4 Objetivo Particular

• Diseñar el esquema modelo, vista y controlador de los módulos que serán desarrollados.
• Implementar herramientas y tecnologı́as web para el desarrollo de módulos especı́ficos
7
del proyecto denominados como: la gestión de agendas médicas, gestión de roles co-
municación paciente-médico, generación de recetas, ası́ asegurando su correcto fun-
cionamiento y compatibilidad con las correspondientes plataformas móvil y web.
• Desarrollar módulo de transferencia de recetas médicas.
1.5 Descripción y Alcances del Proyecto

Para fines de este proyecto, se busca diseñar, desarrollar e implementar módulos de un sis-
tema web de comunicación médica. Los módulos que serán desarrollados son:
• Gestión de usuarios y manejo de sesiones.
• Búsqueda de consultorios con geolocalización.
• Gestión de agendas.
• Creación de prescripciones electrónicas.
• Módulo de chat.
Con el desarrollo de este proyecto, se pretende facilitar la gestión de las agendas y creación
de prescripciones a los médicos, y de ésta forma, ahorrar tiempo y evitar errores que pueden
generar el uso de prescripciones en papel. Por otra parte, el paciente obtendrá el beneficio
de agendar una cita médica de manera electrónica, evitando ası́ asistir directamente al con-
sultorio.
Las limitaciones presentadas para el desarrollo de éste proyecto son:
• Se tiene restringido el uso de servicios de paga.
• El periodo de tiempo para realizar el proyecto es algo corto.
8
2 Marco Teórico
En este capı́tulo se hablará acerca de los conceptos más importantes para el desarrollo de
este proyecto, los cuales abarcan desde que son los sistemas de información web, protocolos
utilizados, patrones de arquitectura de software implementados, modelado de datos, servicios
de mensajerı́a en la nube .
2.1 Sistemas web

Son un tipo de sistemas de información, los cuales no tienen la necesidad de ser instalados
en el equipo del usuario, ya que se accede mediante la web. Toda la información generada
por estos sistemas es almacenada, procesada y distribuida mediante servidores remotos, los
cuales pueden estar ubicados en cualquier parte del mundo, para posteriormente el usuario,
que como único requisito es una conexión a Internet, puede realizar una petición a los servi-
dores, los cuales procesarán la solicitud y como resultado se obtendrá el sistema web, el cual
será interpretado en el navegador del usuario [21]. En la Figura 2 se muestra un esquema de
un sistema web dinámico. A continuación se presentan algunos ejemplos de sistemas web:
• IMSS Digital [2].
• Consulta Curp [22].
Figura 2: Esquema de un sistema web dinámico.
2.1.1 Ventajas y Desventajas

El uso de sistemas de información web presenta una variedad de ventajas, que mejoran
tanto la experiencia del usuario como la de las organizaciones que los implementan. Una
de estas ventajas es el ahorro de tiempo, puesto los sistemas web no tienen la necesidad
de ser instalados, ahorrando al usuario los pasos de una instalación tradicional de software,
se accede únicamente ingresando una dirección en el navegador y se está listo para usarse;
Otra ventaja es la recuperación de datos, ya que debido a que se puede acceder al sistemas
mediante una conexión a Internet desde cualquier lugar, quitando ası́ la dependencia a un
dispositivo en especı́fico. Una ventaja más, es que gracias a que el sistema no está instalado
9
en el dispositivo, se puede ahorrar una gran cantidad de recursos y memoria en el equipo [23].
Aunque el uso de sistemas web provee ventajas, también tiene desventajas que pueden afectar
su funcionamiento. Una de éstas desventajas es la dependencia de una conexiona Internet,
puesto que si no se cuenta con una conexión, el acceso al sistema no podrá ser establecido.
Otra desventaja es que si el servidor tiene una caı́da, el acceso al sistema se verá afectado
en la totalidad de los usuarios. Una última desventaja es que no se cuenta con la libertad
de elegir una versión en especı́fico, y en consecuencia, debe ser utilizada la versión que está
actualmente disponible en el servidor [24].
2.1.2 Protocolo HTTP

El protocolo HTTP(HyperText Transfer Protocol ) es un protocolo de transferencia web uti-
lizado para el intercambio de información como archivos de html, css, código javascript, o
archivos multimedia entre cliente-servidor. El funcionamiento de éste protocolo está basado
en operaciones de solicitud-respuesta, ya que mediante una solicitud realizada por un cliente,
el servidor responde con lo solicitado, o con un código de error en caso de presentarse [25].
HTTP tiene una series de código de estado, ésto con la finalidad de mostrar el resultado de la
petición . En la Tabla 1 se muestran ejemplos de algunos de los códigos HTTP más comunes.
Tabla 1: Ejemplos de códigos HTTP y su significado [25].
Código Significado
200 OK Petición exitosa.
301 Moved Permanently El objeto demandado ha sido movido a
la URL especificada en Location:
400 Bad Request Petición no entendida por el servidor.
404 Not Found Objeto no encontrado en el servidor.
505 HTTP Version Not Supported La versión de HTTP no es soportada.
Los métodos HTTP, también llamados “verbs”, sirven para indicar al servidor la acción que
éste debe realizar. En la Tabla 2 se muestran ejemplos de los métodos más utilizados.
El proceso de transferencia del protocolo http, comienza cuando el usuario mediante una
url(Uniform Resource Locator ) ingresada en el navegador envı́a una solicitud al servidor;
la url es decodificada, con el formato establecido, por el cliente web; se crea una conexión
TCP/IP con el servidor, donde se aloja el recurso; luego se envı́a una solicitud http con la
información necesaria como el método solicitado, el host y los parámetros, en la Figura 3a
se muestra un ejemplo de la estructura de una solicitud GET; cuando el servidor obtiene y
procesa la solicitud, se devuelve una respuesta la cual está formada por el código de estado,
y la información requerida como se muestra en la Figura 3b; por último se cierra la conexión
10
Tabla 2: Ejemplos de métodos para una solicitud HTTP [25].
Método
Significado
GET Devuelve el recurso identificado en la URL pedida.
POST Indica al servidor que se prepare para recibir información del
cliente. Suele usarse para enviar información desde formula-
rios.
PUT Envı́a el recurso identificado en la URL desde el cliente hacia
el servidor.
DELETE Solicita al servidor que borre el recurso identificado con el
URL
TCP. En la Figura 4 se ve representado el proceso de una petición HTTP desde la solicitud

por parte del cliente hasta la respuesta del servidor [25].
(a) Ejemplo de la estructura de una solicitud (b) Ejemplo de la estructura de una re-
get. spuesta Http.
Figura 3: Ejemplo de la estructura de una solicitud get y su respectiva respuesta [26].
Figura 4: Proceso de petición http [27].
2.1.3 Arquitectura cliente-servidor

La arquitectura cliente-servidor es un modelo de aplicación distribuida, en donde las tareas
son divididas en dos partes, entre el cliente y servidor, los cuales se comunican mediante
11
el uso de una red. En esta arquitectura, los clientes tienen la capacidad de conectarse a
los servidores, y poder solicitar recursos mediante peticiones, por el lado el servidor obtiene
y procesa las peticiones y en consecuencia, como respuesta envı́a el recurso solicitado o un
error en caso de presentarse [28]. En la Figura 5 se muestra un esquema de la arquitectura
cliente-servidor. Aunque los clientes hacen uso de los servidores, ésto no significa que ambos
dependen enteramente uno de otro, tanto cliente como servidor pueden actuar una indepen-
dientemente de la otra, realizando sus propios procesos y actividades.
Figura 5: Esquema de la arquitectura cliente-servidor [28].
En la arquitectura cliente-servidor, las tareas son divididas en ambos lados, ésto con la fi-
nalidad de que los clientes tengan menos carga de información, de ésta forma se mejora la
eficiencia del cliente, puesto que el servidor hace gran parte de los procesos. Además, gracias
a ésta arquitectura las organizaciones que la utilizan, pueden manejar mejor la gestión de la
información, dado que la información está más centralizada [28].
Cliente: en la arquitectura cliente-servidor, el cliente es el que hace la manipulación y el

despliegue de los datos hacia el usuario, además de que se encarga de realizar las peticiones al
servidor [29], y no necesariamente debe estar conectado a un único servidor, sino que puede
realizar una conexión a múltiples servidores. Bertha Márquez en su tesis “Implementación
de un reconocedor de voz gratuito a el sistema de ayuda a invidentes Dos-Vox en español ”
[29], menciona que las funciones que lleva a cabo el cliente son:
• Administrar la interfaz de usuario.

• Interactuar con el usuario.
• Procesar la lógica de la aplicación y hacer validaciones locales.
• Generar requerimientos de bases de datos.
• Recibir resultados del servidor.
• Formatear resultados.
Servidor: el servidor es el encargado de responder a cada una de las solicitudes de los cliente,
puede soportar una múltiple cantidad de clientes, aunque su mayor limitación es la capacidad
12
que tenga para recibir las solicitudes de sus clientes. En el servidor es donde se procesa la
información y las reglas del negocio [29]. Bertha Márquez en su tesis “Implementación de
un reconocedor de voz gratuito a el sistema de ayuda a invidentes Dos-Vox en español ” [29],
menciona que las funciones que lleva acabo el servidor son:
• Aceptar los requerimientos de bases de datos que hacen los clientes.
• Procesar requerimientos de bases de datos.
• Formatear datos para transmitirlos a los clientes.
• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.
2.2 Modelo-Vista-Controlador(MVC)
MVC(Modelo-Vista-Controlador ) es un patrón de arquitectura de software, en donde el de-
sarrollo se divide en 3 capas, las cuales tienen una tarea especı́fica, que son la lógica del
negocio y los datos, la presentación al usuario y la lógica del sistema. En el desarrollo de
un sistema, la combinación de éstos 3 elementos puede ser en un mismo lugar, sin causar
problemas y trabajar correctamente, pero a la hora de dar mantenimiento el que no exista
separación puede tornar difı́cil y confusa ésta tarea [30]. El MVC viene a solucionar dicho
problema, dividiendo los elementos en: Modelo, Vista y el Controlador. En la Figura 6 se
muestra el ciclo de vida e interacción de las capas del MVC.
Figura 6: Ciclo de vida e interacción de las capas del MVC [31].
Modelo: El modelo es visto como una representación de la estructura de los datos del sis-
tema. Aquı́ es donde se especifica la lógica del negocio, que es la forma en cómo se gestionan
las validaciones de los datos, como pueden ser accedidos, modificados y/o almacenados [32].
Vista: La vista es la interfaz gráfica en donde se muestra la información del modelo al

usuario [32].
Controlador: El controlador es un intermediario entre la vista y el modelo, dado que cuando

el usuario quiere realizar una acción, se accede al controlador, el cual se encargará de invocar
13
al modelo para cumplir lo solicitado por el usuario [32].
2.2.1 Uso en sistemas web

En las páginas web, los diseñadores trabajan desde una perspectiva HTML, posteriormente,
éstas páginas son pasadas a los programadores del lado servidor, los cuales empiezan a cod-
ificar las funciones, ésto en ocasiones es realizado en los mismos archivo causando un gran
aglomeramiento que disminuye mucho la calidad del código. Esta forma de trabajar, causa
que el código sea difı́cil de comprender y mantener, complicando las correcciones de errores
y actualizaciones [33].
El uso de la arquitectura MVC hace que el código del lado del cliente y del lado del servidor
se separen, y de ésta forma los programadores como los diseñadores web sean mucho más
independientes, evitando ası́ el aglomeramiento de código [33].
2.3 Transferencia de Estado Representacional(REST)

REST(Representational State Transfer ) es un estilo de arquitectura para el desarrollo de
API's(Application Programming Interface). Con el uso de REST se pueden crear interfaces
de programación, que pueden ser usadas por distintas aplicaciones, de ésta forma las organi-
zaciones no se quedan estancadas en las utilidades que pueden ser aprovechadas en una sola
aplicación, sino que pueden extender la comunicación con otras aplicaciones, ası́ la versatili-
dad de los sistemas aumentan [34]. En la Figura 7 se muestra la comunicación entre clientes
y una api rest.
Figura 7: Comunicación entre clientes y un api rest [35]
2.3.1 Caracterı́sticas
Se basa en el protocolo cliente-servidor HTTP, es decir, se basa en peticiones y respuesta
entre el cliente y el servidor. El estado de cada una de las peticiones no es almacenado, y
éstas son independientes entre una y la otra, ésto incluye la autenticación, puesto que es
14
necesario enviar la información que verifique que el cliente está autenticado [34].
El uso de REST incluye la correcta implementación de los métodos HTTP, dado que éstos
son utilizados para especificar las acciones que se quieren realizar al recurso [34], en la Tabla
2 se muestran los métodos más utilizados del protocolo HTTP y su significado.
El correcto uso de los códigos de estado HTTP, ésto con el fin de poder mostrar al usuario
cuál ha sido el resultado de su petición [34], en la Tabla 1 se especifican algunos de los códigos
más comunes del protocolo HTTP y su significado .
El uso de URI's(Uniform Resource Identifier) en REST sirve para acceder a los recursos.
Cada uno de los recursos tiene un nombre el cual lo identifica, haciendo uso de las URI's
junto con los verbos HTTP se pueden indicar cuales son las acciones que deben de ser tomada
para ese recurso en especı́fico [34]. En la Tabla 3 se muestran ejemplos de usos de URI's con
sus respectivos métodos HTTP.
Tabla 3: Ejemplos de URI's.
URI Método Acción

http://rest.com/autos GET Se obtienen todos los autos
disponibles
http://rest.com/autos POST Recibe parámetros POST y alma-
cena un nuevo auto.
http://rest.com/autos/1 PUT Se edita el auto identificado con
el id 1.
http://rest.com/autos/1 DELETE Se borra el auto identificado con
el id 1.
http://rest.com/autos/1 GET Se obtiene la información del auto
identificado con el id 1.
2.4 Modelo Entidad-Relación

El modelo entidad-relación es una forma de modelado de datos, la cual representa a los
participantes de la base de datos como “Entidades”, las cuales cuentan con atributos que
las definen y diferencian, éstas entidades pueden estar relacionadas entre sı́ mediante una
“Relación” que indica cómo coexisten unas con las otras, lo que finalmente es representado
como un diagrama [36].
2.4.1 Entidades
Una entidad es la representación de los objetos del mundo real, los cuales pueden ser abstrac-
tos, inanimados, roles, etc [36]. Algunos ejemplos de entidades son: “Persona”, “Trabajo”,
15
“Auto”. Cada una de éstas entidades cuentan con atributos que son las caracterı́sticas que las
definen, por ejemplo, la entidad “Persona” puede contar con los atributos “Nombre”, “Fecha
de nacimiento”, “Domicilio”. Las entidades comúnmente deben contar con un identificador
con el cual se puedan diferenciar, normalmente se usa un “id” numérico autoincremental,
aunque ésto depende del diseño que se le quiera dar.
2.4.2 Relaciones
Las relaciones son la forma en que las entidades se asocian entre ellas, como trabajan una con
otras, las relaciones deben de contar con un nombre que indique la función entre ambas enti-
dades [36]. Un ejemplo de relación es: “Auto” pertenece a “Persona”, ésta relación indica
que una persona es propietaria de un auto. A continuación se explican las cardinalidades de
mapeo en las relaciones [36]:
• Uno a uno: Indica que la entidad “A” únicamente puede estar relacionada con la
entidad “B” y viceversa.
• Uno a muchos: La entidad “A” puede estar relacionada a varios miembros de la

entidad “B”.
• Muchos a uno: La entidad “A” está relacionada a la entidad “B”, pero “B” puede
estar relacionado a varios miembros de la entidad “A”.
• Muchos a Muchos:Varios miembros de la entidad “B” pueden estar relacionados a

varios miembros de la entidad “A”.
2.5 Notificaciones push

En la actualidad con el constante uso de las tecnologı́as de la información en los dispositivos
móviles o computadoras de escritorio, el envió de datos en tiempo real es una tarea funda-
mental para generar una mejor experiencia de usuario, ya que es importante mantenerlo al
tanto de las actualizaciones más importantes de la aplicación, como lo son mensajes nuevos,
notificaciones de eventos, solicitudes, advertencias, actualizaciones del clima, resultados de-
portivos, etc.
Consecuentemente, nacieron las “Notificaciones push”, que son básicamente, lo contrario a

lo que se hace normalmente, donde un cliente realiza una petición al servidor y éste último
responde. En éste caso, el servidor es que que inicia la comunicación enviando una solicitud
al cliente, el cual la recibe y la muestra al usuario en forma de notificación, inclusive si
la aplicación no está abierta o si se encuentra en segundo plano [37]. Para lograr ésto
se tienen que tener en cuenta varios factores, ya que primeramente se debe de tener un
servidor de notificaciones, como ejemplo Firebase Cloud Messaging; posteriormente el cliente
debe de tener instalada la aplicación, lo que genera un token, con el cual se identificará el
dispositivo; el token debe de ser almacenado en el servidor principal de la aplicación, y con él
se identificara a qué dispositivo se requiere enviar la notificación; el servidor de la aplicación
realiza una solicitud al servidor de notificaciones, enviando el token del dispositivo; el servidor
16
de notificaciones procesa la solicitud y envı́a la notificación al dispositivo; el dispositivo recibe

la notificación.
2.5.1 Service Workers

Los service workers son funciones de javascript, que se pueden ser ejecutadas independien-
temente de la página web, es decir, la página puede estar cerrada o en segundo plano, y los
service workers seguirán ejecutándose, de esta forma se logra la capacidad de funcionar de
manera similar a las aplicaciones nativas. Gracias a ésto, las páginas web tienen la habilidad
de recibir notificaciones push, y sincronización en segundo plano, mejorando considerable-
mente la experiencia del usuario. Para su uso, cuando se accede a la página web por primera
vez, el service worker se instala en el navegador, es necesario que las paginas sean transmiti-
das mediante el protocolo HTTPS, ésto con el fin de que el service worker no sea manipulado
por algún intruso [38].
17
3 Sistema Propuesto
En el presente capı́tulo hará una descripción general del proyecto, además de que se detallarán
los procesos que fueron llevados a cabo durante el desarrollo, también se realizará un análisis
del diseño y la arquitectura del sistema; los diagramas correspondientes de casos de uso;
diseños de la base de datos y para finalizar los algoritmos utilizados.
3.1 Descripción General

La función del sistema desarrollado es permitir que consultorios médicos, tanto privados como
públicos, cuenten con su propio sistema de gestión de agendas médicas, dando la oportunidad
que tanto médicos como los respectivos administradores del consultorio puedan gestionar
fácilmente las agendas, otorgando la opción de mostrar en un calendario las fechas disponibles
para consulta, para posteriormente poder crear una cita en los horarios que el médico trabaje
en el consultorio; posteriormente, el dı́a de la cita, el médico podrá realizar la consulta,
generando una receta médica, que contendrá la información del paciente, el diagnóstico, los
medicamentos y las recomendaciones, esta receta será impresa en formato PDF y podrá ser
enviada al paciente. Por el lado de los pacientes, tendrán la opción de mediante un mapa con
geolocalización, se buscarán todos los consultorios médicos más cercanos a su posición, de
esta forma podrá elegir el consultorio, y el respectivo médico, para luego si es que lo desea,
podrá agendar una cita en los horarios en los que el médico está disponible. El sistema
tendrá un módulo de chat en tiempo real, en donde los médicos y los pacientes podrán
comunicarse, para de esta forma el tratamiento resulte efectivo, y el paciente consulte sus
dudas y las recomendaciones por parte del médico. También se debe contar con un sistema de
notificaciones en tiempo real, las cuales serán enviadas a los pacientes, médicos o pacientes
al momento de que se agende una cita, esto con el fin de que los usuarios se mantengan
informados en los cambios en sus agendas. Cabe mencionar que tanto el chat, como las
notificaciones en tiempo real, deben de ser compatibles con la versión web y la versión para
dispositivos móviles android.
3.2 Metodologı́a
Para el desarrollo de éste proyecto se utilizó la metodologı́a de scrum, dado que es útil en el
desarrollo de proyectos rápidos, en donde los requisitos cambian constantemente, y que en
ocasiones tienen que ser modificados [39].
En esta metodologı́a el proyecto es dividido en bloques de tiempo, en donde cada bloque

tiene que dar como resultado una parte del producto final [39].
Durante los bloques de tiempo, el equipo realiza reuniones diarias en donde se van viendo los
avances de los integrantes, cuáles son las dificultades que se han presentado, que es lo que se
ha hecho desde la última reunión, y que es lo que se planea tener para la próxima reunión
[39]. También se hace uso del “Scrum Board”, que no es más que una pizarra, en donde
se van colocando las actividades de cada miembro del equipo, esta pizarra sirve para llevar
un control de lo que se está haciendo, debe de estar ubicado en un lugar en donde todo el
18
equipo pueda verlo y se tiene acceso fácilmente, esta pizarra puede ser digital o en fı́sico, está
dividida en cosas por hacer, actividades en progreso y actividades realizadas. En la Figura 8
se muestra un esquema de la metodologı́a Scrum.
Figura 8: Esquema de la metodologı́a scrum [39].
3.3 Arquitectura del sistema

Debido a que se hace uso del Framework “Laravel ”, el sistema adopta una arquitectura MVC,
apoyado con la arquitectura cliente-servidor, donde los usuarios hacen las peticiones al servi-
dor para obtener los recursos e información deseada, ası́ como hacer modificaciones en los
registros, y gracias a la arquitectura MVC, los componentes del sistema como la vista, la
lógica de los datos y la lógica del sistema, se mantienen separados, otorgando a los desarrol-
ladores una mayor limpieza e independencia.
Dado que laravel provee un sistema de rutas, el usuario puede simplemente colocar las rutas
en su cliente web, de esta forma se manda a llamar la vista a la cual se desea acceder.
Para obtener y modificar los registros, se basó en la arquitectura REST, esto se debe a que se
planea desarrollar una versión del sistema para dispositivos móviles, de ésta forma se podrá
tener un fácil acceso a la información, dando al cliente la facilidad de obtener y modificar los
datos, únicamente con el sistema de URI's REST que proveen las rutas de laravel.
Por el lado del sistema de notificaciones y mensajes, se utilizó el servicio de “Firebase Cloud
Messaging”, gracias a este servicio, los controladores de laravel, pueden enviar solicitudes
HTTP al servidor de notificaciones push, el cual procesa la información enviada y mediante
el token proveı́do, se envı́a la notificación al cliente relacionado a dicho token, en caso de que
el cliente no esté disponible, la notificación se coloca en una cola de espera, de lo contrario,
cuando el cliente recibe la notificación, ésta se analiza verificando cual es su contenido, puesto
19
que puede ser una notificación de solicitud, avisos de cambios a las agendas, o un mensaje
mediante el chat. En la Figura 9 se muestra un esquema de la arquitectura del sistema.
Figura 9: Esquema de la arquitectura del sistema.
3.4 Análisis de los módulos del sistema

Como se mencionó en el inicio del capı́tulo, los usuarios del sistema están compuestos por
roles, de Administrador, Médico y Paciente. Éstos roles tienen acceso a distintos módulos
y diferentes niveles de acceso, algunos pueden ser módulos en donde cualquiera de los roles
tienen acceso, en cambio, hay otros módulos donde únicamente pueden acceder ciertos roles.
En la presente sección, se hará un análisis del diseño del sistema, especificando cada uno de
los módulos que lo componen.
3.4.1 Login de usuarios

El módulo login, es el primer módulo en el que cualquier usuario accede. En éste módulo,
el usuario debe de ingresar su nombre de usuario y su contraseña, ésto con el fin de darle
acceso al sistema, en caso de que alguno de sus datos sea inválido, se le avisara especificando
cual es el error para que lo corrija. En caso de que los datos sean correctos, se verificará el
tipo de usuario que es, y se le enviará a un módulo diferente, todo en base al rol de usuario
que tenga. Para mantener la seguridad de la aplicación, se utilizaron los “Middleware” de
laravel, éstos middleware permiten crear un filtro al realizar las peticiones al sistema, de esta
forma se puede saber si el que está realizando la petición está autenticado, en caso de que
no, se le enviara a otra pantalla del sistema. En la Tabla 4 se muestran las especificaciones
del módulo.
20
Tabla 4: Especificaciones del módulo login.
Rol Médico, Paciente, Administrador.

Información N.A
Restricciones N.A
Acciones Ingresar al sistema.
3.4.2 Selección de consultorio

Al momento de que el médico tenga acceso al sistema, le enviará al módulo “Selección de
consultorio”, en éste módulo, se le mostrará al médico cada uno de los consultorios en el que
trabaja, con la información de cada uno de éstos, de esta forma, el médico podrá elegir uno
de los consultorios, para ver su agenda. En la Tabla 5 se muestran las especificaciones del
módulo.
Tabla 5: Especificaciones del módulo Selección de consultorio.
Rol Médico.
Información Información de los consultorios en los
que trabaja el médico.
Restricciones Cada médico puede ver únicamente
la información de los consultorios en
donde trabaja.
Acciones Seleccionar un consultorio para ver la
agenda.
3.4.3 Agenda
El módulo de agenda, es un módulo que es libre, puesto que tanto como médicos, pacientes
y administradores tienen acceso, en el caso de médicos únicamente se tiene acceso a sus
agendas, y en el caso de los administradores, se tiene acceso únicamente a las agendas de los
médicos que trabajen en su consultorio, en cambio, los pacientes tienen acceso a las agendas
de todos los médicos, aunque únicamente pueden ver los horarios en los que el médico se
encuentra disponible, o las agendas que el paciente haya realizado.
Dentro de este módulo, los usuarios tendrán la capacidad de agendar una cita médica, ésto
se hace seleccionando en un calendario la fecha deseada; dentro de la fecha seleccionada se
mostrará los horarios en el que el médico trabaja en el dı́a; posteriormente el usuario podrá
agendar una cita de 15 minutos en el horario elegido; al crear la cita se pedirá la información,
como el tipo de cita y una descripción; en el caso de los médicos o administradores, podrán
hacer una búsqueda mediante un campo select al paciente al que se le agendará en la cita,
por otro lado, el paciente no tendrá visible este campo. Ası́ mismo, los usuarios tendrán la
21
capacidad de editar o eliminar las agendas, los administradores y los médicos pueden cam-
biar indefinidamente los horarios, y aumentar el tiempo de cada cita, en cambio el paciente
únicamente puede cambiar el horario de la cita un máximo de 3 veces, cuando esta cantidad
sea sobrepasada, se le enviará una notificación al médico y a su administrador, donde un
paciente está solicitando una cita, y si ası́ se desea, puedan aceptar el cambio o no. En la
Tabla 6 se muestran las especificaciones del módulo.
Tabla 6: Especificaciones del módulo de agenda.
Rol Médico, Paciente, Administrador.

Información Horarios en los que el médico trabaja.
En el caso del médico y el admin-
istrador, pueden ver la información de
las citas que ya han sido agendadas, y
elegir un paciente entre todos los exis-
tentes. El paciente únicamente podrá
ver sus citas agendadas.
Restricciones Los médicos no podrán ver las agendas
de otros médicos, al igual que los ad-
ministradores no podrán ver las agen-
das de médicos que no trabajen en su
consultorio.
Acciones Agendar una cita, eliminar citas, cam-
biar horarios de cita.
3.4.4 Prescripciones electrónicas

El módulo de prescripciones electrónicas, es un módulo en el cual únicamente el médico puede
acceder, ésto se hace entrando a la agenda de la cita, a la hora indicada, si no es la hora que ha
sido indicada en la agenda, entonces no se tendrá acceso, a menos de que se cambie el horario.
Dentro de éste módulo, el médico podrá generar un máximo de 3 recetas médicas, cada una
de las recetas deberá contar con un diagnóstico, medicamentos, sı́ntomas y recomendaciones
generales, en el caso de que alguno de los medicamentos, sı́ntomas o recomendaciones que
el médico desee agregar, no se encuentre registrado, se podrá acceder a un módulo para
agregar un nuevo registro, y se almacene para futuro uso. Para finalizar, las recetas podrán
ser guardadas y enviadas al paciente, únicamente en el lapso de tiempo de la agenda, para
evitar que el tiempo se pase, se le enviará una notificación al médico un par de minutos antes
de terminar la cita. En la Tabla 7 se muestran las especificaciones del módulo.
22
Tabla 7: Especificaciones del módulo de prescripciones electrónicas.
Rol Médico.
Información Información sobre la cita, datos del pa-
ciente y del médico.
Restricciones Solo tiene acceso el médico que atiende
la cita, únicamente puede acceder al
módulo en el horario que ha sido agen-
dado.
Acciones Añadir a la prescripciones un di-
agnóstico, medicamentos, sı́ntomas y
recomendaciones, también se podrá
generar un PDF de la prescripción.
3.4.5 Selección de médico

Al ingresar al sistema,al administrador se le enviara a una pantalla donde se mostrara cada
uno de los médicos que trabajan en su consultorio, de esta forma podrá ver la agenda del
médico, y gestionar las citas. En la Tabla 8 se muestran las especificaciones del módulo.
Tabla 8: Especificaciones del módulo de selección de médico.
Rol Administrador.
Información Información de los médicos que traba-
jan en el consultorio del administrador.
Restricciones Sólo se muestra información de los
médicos que trabajan en el consultorio
del administrador.
Acciones Seleccionar un médico para ver su
agenda.
3.4.6 Búsqueda de consultorio

Al ingresar al sistema, el paciente se le enviará a la pantalla de búsqueda de consultorios,
en éste módulo se le pedirá al paciente que permita que el sistema obtenga su ubicación, en
caso de que no lo permita, el mapa se colocara con las coordenadas del centro de Ciudad
Victoria, en caso de que si permita la ubicación, se hará una búsqueda de los consultorios
más cercanos a una distancia de 1 a 10 kilómetros del punto indicado, el paciente podrá
cambiar manualmente la ubicación de donde partirá la búsqueda. Cuando se muestran los
consultorios, el paciente podrá seleccionar uno, donde se mostrará la información de este
consultorio, como la imagen, el logotipo, dirección, teléfono. Además, se mostrará una lista
23
de todos los médicos que laboran en el, donde el usuario será capaz de elegir uno para ver
los horarios de su agenda, y en caso de que ası́ lo quiera el paciente, agendar una cita en las
fechas indicadas por el médico. En la Tabla 9 se muestran las especificaciones del módulo.
Tabla 9: Especificaciones del módulo de búsqueda de consultorios.
Rol Pacientes.
Información Se muestra un mapa con los consul-
torios cercanos al paciente, al selec-
cionar el consultorio se despliega la
información del mismo, junto con los
médicos que trabajan en el.
Restricciones Ni médicos, ni administradores tienen
acceso.
Acciones Encontrar consultorios cercanos a la
ubicación del paciente, seleccionar con-
sultorio, seleccionar médico para ver su
agenda.
3.4.7 Módulo chat

En el módulo de chat, el usuario podrá ver todas las conversaciones que tenga con otros
usuarios. Únicamente los pacientes podrán mantener una conversación con su médico cuando
el tratamiento esté activo, cuando el tratamiento se dé por terminado, el chat se cerrará hasta
que una nueva cita sea agendada. Los médicos además de mantener conversaciones con sus
pacientes, podrán enviar mensajes a los administradores del consultorio en el que trabaje.
En la Tabla 10 se muestran las especificaciones del módulo.
Tabla 10: Especificaciones del módulo de chat.
Rol Pacientes, médicos, administradores.

Información Se muestran las conversaciones que
tiene un usuario.
Restricciones Solo puede ver sus conversaciones
el usuario, los pacientes únicamente
pueden enviar mensajes a médicos con
los que esté en tratamiento, los admin-
istradores solo pueden enviar mensajes
a médicos que trabajen en su consulto-
rio.
Acciones Enviar un mensaje a otro usuario.
24
3.4.8 Notificaciones
Los usuarios podrán recibir una notificación en tiempo real, estas notificaciones llegarán a
cada una de los dispositivos en los que tengan una cuenta activa. Las notificaciones varı́an,
dado que pueden ser una solicitud de cita nueva, notificación de una cita eliminada o una
cita editada.
Para el funcionamiento del módulo de notificaciones se utiliza el servicio de “Firebase cloud

Messaging”, el cual provee de un token de usuario al momento de iniciar sesion, dicho to-
ken será almacenado en la base de datos relacionado al usuario, posteriormente cuando se
necesite enviar una notificación, el servidor del sistema realizará una búsqueda de los tokens
relacionados al usuario que se le enviará la notificación, para enviar, mediante una solicitud
http, una notificación hacia el servidor de Firebase, esto se hace enviando como parámetro
el token del usuario, y el mensaje de los datos.
En la Tabla 11 se muestran las especificaciones del módulo.
Tabla 11: Especificaciones del módulo de notificaciones.
Rol Pacientes, médicos, administradores.

Información Muestra las notificaciones recibidas por
el usuario.
Restricciones Solo pueden ver sus notificaciones cada
usuario.
Acciones Aceptar o rechazar solicitudes.
3.5 Diagramas de casos de uso

Para describir correctamente cada una de las funcionalidades de los módulos, se crearon Casos
de uso, de esta forma, se verá cómo interactúan los usuarios del sistema con los procesos que
deben de ser realizados en cada uno de los módulos.
25
3.5.1 Caso de uso del login

La Figura 10 muestra los pasos que deben ser seguidos para la autenticación de un usuario,
en este caso de uso, toman parte los actores “Usuario” y “Servidor”, en el caso del actor
usuario, es independiente del rol, puesto que al iniciar sesión el rol será identificado por el
servidor y se mostrará la pantalla del sistema correspondiente. En la Tabla 12 se describe
detalladamente el caso de uso.
Figura 10: Caso de uso del módulo de login.
Tabla 12: Descripción del caso de uso del módulo login.
Nombre: Acceso de usuarios.

Descripción: El usuario ingresa sus credenciales de acceso y el servidor
deniega o da acceso al sistema.
Actores: Usuario, Servidor
Precondición: N.A.
Postcondición: El usuario accede al sistema, y se redirige a un módulo de-
pendiendo de su rol.
Proceso estándar:
• El usuario accede al sistema.
• Se genera el token de notificación.
• Se digita las credenciales de acceso.
• El servidor valida los datos.
• Se accede al sistema.
26
3.5.2 Caso de uso para la búsqueda de consultorios

La Figura 11 muestra los pasos que deben de llevar a cabo los usuarios para seleccionar
consultorios y médicos en el mapa. En éste caso de uso, sólo toma parte el usuario con rol
de “Paciente”, puesto que únicamente los pacientes pueden buscar consultorios en el mapa.
En la Tabla 13 se describe detalladamente el caso de uso.
Figura 11: Diagrama de casos de uso de la búsqueda de consultorios.
Tabla 13: Descripción del caso de uso del módulo de búsqueda de consultorios.
Nombre: Búsqueda de consultorios.

Descripción: El paciente busca en un mapa el consultorio de su pref-
erencia.
Actores: Paciente
Precondición: El paciente elige una posición en el mapa.
Postcondición: El paciente accede a la agenda de un médico.
Proceso estándar:
• El paciente accede al módulo.
• Se le pregunta su ubicación al paciente.

En caso de que no la permita, el paciente
podrá seleccionar su ubicación.
• Se selecciona un consultorio.
• Se selecciona un médico.
27
3.5.3 Caso de uso para el chat de usuarios

La Figura 12 se muestran los pasos llevados a cabo para el chat entre usuarios. Para entablar
una conversación, es necesario la interacción de 2 usuarios independientemente de rol, ya que
cualquier usuario tiene acceso al módulo de chat. Aunque el proceso de enviar un mensaje
se necesita únicamente un usuario, dado que el otro usuario no es necesario que esté activo
para enviar el mensaje. En la Tabla 14 se describe detalladamente el caso de uso.
Figura 12: Diagrama de casos de uso del chat entre usuarios.
Tabla 14: Descripción del caso de uso de chat.
Nombre: Chat.
Descripción: El usuario envı́a mensajes a un contacto.
Actores: Usuario, Administrador, Paciente, Médico
Postcondición: Se envı́a mensajes a otro usuario.
Proceso estándar:
• Se selecciona un contacto a quien enviar un men-

saje.
• Ses escribe el mensaje.
• Se envı́a el mensaje.
28
3.5.4 Caso de uso del módulo de prescripciones electrónicas

La Figura 13 se muestran los pasos llevados a cabo para generar prescripciones electrónicas.
Para el módulo de prescripciones, únicamente el usuario con el rol de médico puede acceder,
además de que sólo puede generar recetas a citas que están agendadas a su nombre. En la
Tabla 15 se describe detalladamente el caso de uso.
Figura 13: Diagrama de casos de uso para generar prescripciones electrónicas.
Tabla 15: Descripción del caso de uso de Prescripciones Electrónicas.
Nombre: Recetas Electrónicas.

Descripción: El médico podrá generar una prescripción electrónica.
Actores: Médico
Precondición: Debe de tener una agenda previamente, la hora al mo-
mento de crear la receta, debe estar en el rango de
tiempo indicado en la agenda.
Postcondición: Se genera un PDF, el cual se envı́a al paciente.
Continua en la siguiente página.
29
Tabla 15 – Continua en la página anterior.

Proceso estándar:
• El médico genera crea la receta, en base a la

agenda.
• Se seleccionan los sı́ntomas.
• Se selecciona un diagnostico.
Se ofrecen sugerencias de diagnósticos.
• Se selecciona medicamentos.
Se ofrecen sugerencias de medicamentos.
• Se agregan los detalles del medicamento elegido.
• Se seleccionan recomendaciones generales.

Se ofrecen sugerencias para las recomenda-
ciones.
• Se envı́a el PDF al paciente.
3.5.5 Caso de uso del módulo de selección de consultorio

La Figura 14 se muestran los pasos llevados a cabo para la selección de un consultorio. Para
éste módulo, únicamente tiene acceso el usuario con el rol de “Médico”, y solo sólo puede ver
los consultorios en los que trabaje. La Tabla 16 se describe detalladamente el caso de uso.
Figura 14: Diagrama de casos de uso para la selección de consultorios.
30
Tabla 16: Descripción del caso de uso para seleccionar consultorio.
Nombre: Seleccionar consultorio.

Descripción: El médico puede seleccionar la agenda de uno de los
consultorios en que trabaja.
Actores: Médico
Postcondición: El médico accede a su agenda en el consultorio selec-
cionado.
Proceso estándar:
• El médico accede al sistema.
• Observa los consultorios.
• Selecciona un consultorio.
3.5.6 Caso de uso del módulo de selección de médico

La Figura 15 muestra los pasos llevados a cabo para la selección de un médico. En éste
módulo, únicamente tiene acceso el usuario con el rol de “Administrador”, además de que
sólo se muestran los médicos que trabajen en el consultorio que administra. En la Tabla 17
se describe detalladamente el caso de uso.
Figura 15: Diagrama de casos de uso para la selección de un médico.
31
Tabla 17: Descripción del caso de uso Seleccionar Médico.
Nombre: Seleccionar Médico.

Descripción: El administrador puede seleccionar a uno de los médicos
que trabajan en su consultorio.
Actores: Administrador
Postcondición: El administrador ve la agenda del médico seleccionado.
Proceso estándar:
• El administrador accede al sistema.
• Observa los médicos registrados.
• Selecciona un médico.
3.5.7 Caso de uso del módulo de agenda

En la Figura 16 se muestran los pasos que son llevados a cabo para la gestión de la agenda.
En el módulo de agenda, tiene acceso los 3 tipos de usuario, aunque algunas de sus acciones
pueden ser distintas, por ejemplo, en el caso de los pacientes, no pueden extender el horario
de su consulta al dado inicialmente de 15 minutos, en cambio, el administrador y el médico,
si pueden extender dicho horario. En la Tabla 16 se describe detalladamente el caso de uso.
Figura 16: Diagrama de casos de uso para agendar una cita.
32
Tabla 18: Descripción del caso de uso Gestión de agendas.
Nombre: Gestión de agendas.

Descripción: Los usuarios pueden agregar, eliminar o editar las citas
de un médico.
Actores: Usuario, Médico, Administrador, Paciente
Postcondición: La agenda del médico sufre cambios.
Proceso estándar:
• Se accede a la agenda de un médico.

En caso de que el usuario sea médico, y la
agenda no sea suya, no se le permitirá el acceso.
En caso de que el usuario se administrador,
y la agenda no sea de uno de los médicos de su
consultorio, no se le permitirá el acceso.
• El usuario crea una cita.

En caso de ser médico o administrador, puede
seleccionar un paciente de un listado.
• Editar cita.
• Solo los médicos y administradores pueden exten-

der el tiempo de la cita.
• Eliminar Cita.
• Ver citas pendientes.

Solo los médicos y administradores pueden ver
todas las citas.
3.6 Diseño de la Base de Datos

Para el diseño de la base de datos, se tomó como base el Modelo Entidad-Relación, el cual
es explicado en el capı́tulo 2.
Para la lógica del desarrollo, se dividió en 6 bloques de entidades, cada uno de estos bloques
tiene su funciones en especı́fico, aunque estos bloques tienen sus funciones, muchas de las
entidades participan en otros bloques otorgando información adicional.
Es importante mencionar, que a pesar de que el diseño de la base de datos se hizo en su
totalidad, para fines del proyecto que se detalla en esta tesina, no se hizo uso de todas las
entidades de la base de datos, dado que éstas serán utilizadas en una siguiente versión del
proyecto.
33
3.6.1 Gestión de roles

Debido a que el sistema tiene que manejar un login, y roles de usuario, se diseñó una entidad
llamada “Usuarios”, la cual tiene los datos necesarios para un login, los cuales son “User-
Name” y “Password”, con estos datos se realizará el acceso al sistema. Dicha entidad puede
contar con alguno de los 3 roles que maneja el sistema, estos roles son Paciente, Médico,
Administrador. Dependiendo del rol, el usuario puede contar con distinta información, como
ejemplo en el caso de los pacientes es necesario que se ingrese el peso, la estatura y el tipo
de sangre, o en el caso de los médicos, se necesita conocer su especialidad, la universidad
donde obtuvo su tı́tulo y su cédula profesional, ası́ que en base a ésto se agregaron entidades
adicionales, donde se incluye la información especı́fica que debe de llevar cada uno de los
roles, las entidades extras son las de ”Pacientes”, ”Administradores” y ”Doctores”, cada una
de estas entidades están directamente relacionadas a un usuario. Cada vez que un usuario
inicia sesión, se verifica el rol con el que éste cuenta, de esta forma se accede a la información
de la entidad del rol.
3.6.2 Agenda de citas

Para agendar las citas, se creó una entidad llamada “Agenda” dicha entidad cuenta con la in-
formación necesaria para generar una agenda, esta información debe de ser la fecha en que la
cita será llevada a cabo, la hora en la que iniciara, la hora en la que terminará. Para la agenda,
es necesario contar con la información del paciente, de esta forma la entidad“Paciente” se
relaciona directamente a la entidad “Agenda”, ası́ mismo, se necesita que la entidad “Doc-
tores” esté relacionada a la entidad ”Agenda”, con el fin de obtener el médico que atiende
la cita. Ésta entidad está directamente relacionada a la entidad de “Consultorios”, esto con
el fin de indicar en que consultorio será la cita, dado que los médicos pueden trabajar en
distintos consultorios, es necesario indicar en donde sera, para no generar una confusión con
los otros consultorios en el que el médico atiende. Debido a que los pacientes o los médicos
pueden aceptar o rechazar la solicitud de agenda, se creó un par de ”Atributos Bandera”,
los cuales indican si tanto el usuario como el médico han aceptado la cita, en caso de que
alguno de ellos dos, no haya aceptado, entonces la cita será eliminada pasada la fecha y hora
que se indicó. También, con el fin de informar al médico como sera la cita, se relaciono a
una entidad, donde se indicará el tipo de cita que se tratara. Por último, cuando el médico
decide procesar la cita, entra en acción la entidad “Citas”, esta entidad está directamente
relacionada a la entidad de agenda, de esta forma se conoce a qué hora fue realizada la cita,
y el resto de la información, como consultorios, médico que atendió, paciente, etc.
3.6.3 Prescripciones electrónicas

Para generar las prescripciones electrónicas, se creó la entidad “Receta”, esta entidad está
relacionada con la entidad “Citas”, esto para indicar en qué momento, por quién, para quién
y en donde se hizo la receta. Además de la información antes mencionada, la prescripción
debe de contar con un diagnóstico, de esta forma la receta se relaciona con la entidad “Padec-
imientos” indicando el diagnóstico detectado al paciente. También es importante que una
prescripción cuente con la información de los medicamentos serán recetados, dado que una
34
prescripción puede tener N cantidad de medicamentos, se creó la relación de muchos a mu-

chos con la entidad “Medicamentos”, este tipo de relación obliga a que se genere una nueva
entidad llamada “RecetaMedicamentos”, en esta nueva entidad, se agrega información im-
portante para la administración del medicamento, como lo es la dosis, vı́a de administración,
frecuencia con la que se administra, la duración, y comentarios en dado de ser necesario.
Para llevar a cabo un seguimiento del historial del paciente, la receta debe de contar con los
sı́ntomas presentados, con los que se llevó a cabo la conclusión del diagnóstico, ası́ que se
creó una nueva entidad la que sirva para relacionar los sı́ntomas con la receta. Por último,
para agregar recomendaciones generales, se creó la entidad de “Recomendaciones” la cual
mantiene una relación de muchos a muchos con la entidad “Recetas”, dando opción al médico
de agregar alguna recomendación extra para la receta.
3.6.4 Búsqueda de consultorios

La entidad “Consultorios” es donde se almacena la información de los consultorios médicos,
esta información debe de ser el nombre del consultorio, su dirección, teléfono, logotipo y una
descripción, además, dado que para fines del sistema, se debe de mostrar en un mapa la
ubicación de los consultorios, se incluye la ”Latitud” y ”Longitud”, de ésta manera será fácil
ubicar el consultorio en el mapa. Dado que un consultorio puede tener varios administradores,
se creó una relación con la entidad “Administrador”, la que indica en que consultorio trabaja
cada administrador, ésto para evitar de que usuarios ajenos con dicho rol accedan a la
información de un consultorio al cual no pertenecen. En mismo caso para los médicos, ya
que éstos pueden trabajar en uno o muchos consultorios, se creó una nueva entidad llamada
“ConsultorioDoctor”, la cual está relacionada a las entidades “Doctores” y “Consultorios”,
indicando en qué consultorios labora el médico, es importante puesto que, el médico puede
tener varias agendas en distintos consultorios.
3.6.5 Mensajes
La entidad “Mensajes” sirve para almacenar cada uno de los mensajes que se envı́an entre
los usuarios, estos mensajes pueden ser texto, imágenes o archivos. Se relaciona la entidad
“Usuarios”, con dos relaciones, una relación es para el “Remitente” y otra para el “Des-
tinatario”, de tal forma se obtiene la información del usuario que envı́a y quien recibe el
mensaje.
3.6.6 Notificaciones
Para generar realizar el envı́o de notificaciones, es necesario contar con un token de dispositivo
otorgado por el servidor de notificaciones, este token es almacenado en la entidad “TokenNo-
tificacionUsuario”, esta entidad tiene como atributos el token de notificación, token de sesión,
y está relacionada un usuario. Cada vez que un usuario inicie sesión en un dispositivo difer-
ente, se genera un token de notificación al igual que uno de sesion. De esta forma, cuando se
necesite enviar una notificación, se buscarán todos los tokens de notificación relacionados al
usuario, indicando al dispositivo donde llegará, el token de sesión se utiliza para verificar que
el usuario esté activo, en caso de que no este activo, no se enviará la notificación al dispositivo.
35
La entidad de “Notificaciones” almacenará cada una de las notificaciones enviadas a un

usuario, dicha entidad tiene dos relaciones a la entidad “Usuarios”, estas relaciones indican
el usuario destinatario y el remitente de la notificación, además de que también cuenta con
un par de atributos, los cuales indican si la notificación ha llegado a su destino y si ha sido
vista por el destinatario.
3.6.7 Tablas laravel

El FrameWork Laravel ofrece un sistema de migración de base de datos, donde se puede ir
creando las tablas y los cambios requeridos, al hacer esto, laravel crea una Tabla llamada
“migrations” donde se va almacenando el orden de cada una de las notificaciones a la base
de datos.
Otra Tabla generada por laravel, es la Tabla “jobs”, dicha Tabla sirve para almacenar los
“queues”, que son ejecuciones en segundo plano de la aplicación, cuando se mandan a llamar
se almacena la instrucción en la Tabla jobs, para posteriormente ejecutar la instrucción.
3.6.8 Entidades de la base de datos

En la Tabla 19 se muestran todas las entidades que participan en la base de datos y su
descripción.
Tabla 19: Entidades de la base de datos y su respectiva descripción.
Entidad Descripción
Administradores Almacena la información del rol de admin-
istradores,como su nombre, domicilio, edad.
Agenda Almacena la información de las agendas, como la fecha,
el horario, el médico y el paciente de la cita.
Alergias Almacena la información de las alergias.
Citas Guarda una cita generada, se relaciona directamente con
la entidad agendas.
ConsultorioAdministrador Almacena la información del consultorio en los que tra-
baja un administrador.
ConsultorioDoctor Guarda la información de los consultorios en los que un
doctor atiende.
Consultorios Guarda la información de los consultorios, su nombre,
dirección, logotipo.
Dias Tabla normalizada donde se guarda los dı́as de lunes a
viernes.
Doctores Guarda la información de los médicos, como su nombre,
fecha de nacimiento, informacion, etc.
Farmacias Guarda la información de las farmacias registradas.
FormacionAcademica Almacena las especialidades de los médicos.
36

Generos Tabla normalizada donde se almacena el género mas-
culino o femenino.
Horarios Tabla donde se almacenan los horarios de los médicos.
HorarioDoctor Tabla donde se relaciona un horario con un médico.
Medicamentos Guarda toda la información de los medicamentos,
agentes activos, presentación.
Notificaciones Guarda la información de las notificaciones como el men-
saje, el usuario destinatario y el remitente.
PacienteAlergia Tabla que almacena la relación entre un paciente y su
alergia.
Pacientes Guarda la información de los pacientes, como su nombre,
edad, peso y estatura.
Padecimientos Tabla que almacena los diagnósticos.
PadecimientosSintomas Tabla que almacena los sı́ntomas que se relacionan a los
padecimientos.
RecetaMedicamento Guarda los medicamentos que son puestos en una receta.
Recetas Guarda la información de la receta, a que cita está rela-
cionada.
RecomendacionesGenerales Recomendaciones generales que pueden ser utilizadas
por los médicos en las recetas.
RecomendacionesRecetas Relación Entre las recomendaciones y la receta.
Roles Tabla normalizada para que se relaciona a los usuarios,
esto para verificar el rol que éste tiene.
SintomaReceta Tabla que relaciona los sı́ntomas con su receta.
Sintomas Tabla que almacena los sı́ntomas que pueden ser utiliza-
dos por los médicos.
TipoCita Tabla que almacena los tipos de cita existentes-
TipoDeSangre Guarda la información del tipo de sangre del paciente.
TipoNotificacion Guarda la información del tipo de notificación que ha
sido enviada.
TiposAlergias Guarda la información de los tipos de alergias existentes.
TiposConsultorios Tipos de consultorios.
TiposPadecimientos Los tipos de padecimientos que existen.
TokenNotificacionUsuario Guarda los tokens de notificación y de sesion de los
usuarios.
Universidad Almacena la información de la universidad en la que un
doctor obtuvo su tı́tulo.
Usuarios Tabla que almacena los usuarios existentes.
Mensajes Tabla que almacena los mensajes del chat.
FarmaciaMedicamento Tabla que crea una relación entre las farmacias y los
medicamentos.
37

jobs Tabla generada por laravel para almacenar los ”queues”.
migrations Tabla de migraciones generada por laravel.
3.7 Algoritmos
En la presente sección, se hará una descripción de los algoritmos realizados para el correcto
funcionamiento del sistema, ademas de que se mostrara un pseudocodigo que muestre la es-
tructura del algoritmo.
3.7.1 Selección de token de notificaciones

Al momento de enviar notificaciones, se deben de obtener todos los tokens de notificación
que están registrados a nombre del usuario al que le llegara la notificación. Primeramente se
deben de buscar todos los tokens de notificación que estén registrado, posteriormente cada
uno viene con su propio token de sesión, en caso de que el token de sesión este inactivo, el
token de notificación es eliminado y no se envı́a la notificación. En el Algoritmo 1 se muestra
el proceso llevado a cabo para la selección de tokens de notificación.
Algoritmo 1 Algoritmo de selección de token de notificación.

Entrada: TokensDeUsuario.
para i = 0 hasta count(TokensDeUsuario hacer
2: si TokensDeUsuario[i][Sesion]==false entonces
Delete TokensDeUsuario[i];
4: si no
EnviarNotificacion(TokensDeUsuario[i][TokenNotificacion]);
6: fin si
fin para
38
3.7.2 Cambio de horarios automático

Cuando un médico llega tarde, o simplemente no puede asistir al consultorio, se debe de
modificar las consultas que tenga pendiente en el lapso de tiempo indicado, esto puede ser
realizado de dos formas distintas, la primera es modificar el horario de cada cita manual-
mente, la otra forma es obtener todas las citas que serán afectadas y colocarlas en una cola
de prioridad, para posteriormente ir buscando espacios vacı́os en los horarios del médico,
cada cita será eliminada de la cola conforme se vaya colocando en un nuevo horario. En el
Algoritmo 2 se muestra el proceso llevado a cabo para cambiar los horarios.
Algoritmo 2 Algoritmo de cambio de horarios automático.

Entrada: Se obtienen todas las citas agendadas en el horario indicado.
NuevaEntrada=FinRetardo
2: para i = 0 hasta count(agendas) con paso 1 hacer
AgendaFecha, AgendaHoraEntrada, AgendaHoraSalida
4: DiferenciaMinutos=Se calcula los minutos entre la entrada y salida de la cita actual.
mientras Bandera=true hacer
6: NuevoFin=NuevaEntrada+DiferenciaMinutos
HorariosDoctor=Se obtienen los horarios del médico que estén en el rango de la
nueva hora de entrada y salida
8: si count(HorariosDoctor)¿0 entonces
NAgenda=Se Filtran las agendas con el nuevo horario de entrada y salida
10: si count(NAgenda)==0 entonces
Se actualiza el nuevo horario de entrada y de salida de la cita
12: Bandera=false
si no
14: NuevaEntrada=NAgenda[Salida]
fin si
16: si no
NuevaEntrada=Hora de entrada de uno de los horarios de entrada del médico
18: fin si
fin mientras
20: Obtienen las agendas dentro del rango indicado.
fin para
39
4 Resultados
En la presente sección, se mostrarán los resultados del sistema, ası́ como el hardware que
se utilizó, el software, se explicaran cuáles fueron los elementos evaluados, y los respectivos
resultados.
4.1 Hardware utilizado

Para las pruebas al sistema, se utilizaron dos equipos, uno de computo y un dispositivo móvil.
Ésto con la finalidad de probar el funcionamiento del sistema en dos plataformas distintas,
además de analizar la responsividad en pantallas de distinta resolución. A continuación se
describen los dos dispositivos utilizados:
• Computadora: Para la prueba en una computadora, se utilizó una laptop Acer E14
de 14 pulgadas, con un procesador Intel Celeron con 4 GB de memoria RAM.
• Dispositivo Móvil: Para la prueba en el dispositivo móvil, se utilizó un celular Ilium
l910, con un tamaño de pantalla de 5 pulgadas, y con 2 gb de memoria RAM.
4.2 Software utilizado

Sistemas operativos:
• Para el equipo de cómputo, se utilizó como sistema operativo la distribución de Linux
Ubuntu 16.04 lts.
• Para el dispositivo móvil, se utilizó como sistema operativo Android 6.0 Marshmallow.
Navegadores:
• Equipo de cómputo se utilizó el navegador Google Chrome.
• Adicionalmente, en el equipo de computo se utilizo el navegador Mozilla Firefox.
• En el dispositivo móvil se utilizó el navegador Google Chrome.
Otros:
• Para servidor web, se utilizó el Servidor HTTP Apache.
• Como gestor de base de datos, se utilizó MySQL.
• Como administrador para paquetes de laravel se utilizó Composer.
4.3 Elementos a evaluar

Para evaluar el correcto funcionamiento del sistema, se pondrán a prueba distintos elementos,
como lo son la responsividad de las pantallas, el funcionamiento del chat y las notificaciones
en tiempo real, verificar la seguridad, evitar que intrusos entren al sistema, cuando no estén
autenticados, validar que usuarios no puedan acceder ni modificar la información de otros
usuarios,verificar que cuando se necesite agregar, modificar o eliminar algo se realice correc-
tamente.
40
4.4 Pruebas
A continuación se presentan las pruebas realizadas para evaluar el funcionamiento del sistema.
4.4.1 Prueba de responsividad

Para generar una mejor experiencia al usuario, los sistemas web deben de ser responsivos a
las distintos tamaños de los dispositivos, es decir, adaptarse a la pantalla en donde se esté
utilizando, ésto con el fin de que el usuario pueda utilizar fácilmente el sistema en cualquier
dispositivo que desee. En la Figura 17 se muestra la prueba de calendario en diferente
resolución.
(b) Calendario en navegador

(a) Calendario en navegador de computadora. de dispositivo móvil.
Figura 17: Prueba de responsividad para el módulo de calendario.
Como se observa en la Figura 17, el cambio de resolución hizo que los elementos de la pantalla
se adaptaran, mientras en una resolución mayor, se muestran simultáneamente el menú, el
calendario y la tarjeta de información del médico, en una pantalla más pequeña, como en un
dispositivo móvil, se oculta el calendario, se oculta el menú y la tarjeta del médico aparece
un botón con el que se puede desplegar el calendario. Esto se logra con una combinación de
la responsividad de materialize junto a funciones proporcionadas por Jquery.
4.4.2 Prueba de acceso

En la presente prueba se analizará el comportamiento del sistema, al momento de que al-
guien quiera acceder a algún módulo sin haberse autenticado antes, ésto con el objetivo de
encontrar fallas de seguridad que puedan existir. En la Figura 18 se puede observar cuales
41
fueron los resultados al tratar de entrar a los módulos sin autenticación.
(a) Ingreso al módulo agenda sin autor-

ización. (b) Resultado del ingreso.
Figura 18: Solicitud de acceso sin autorización.
Como se puede observar en la Figura 18, al momento de ingresar la dirección del recurso, al
cual se quiere acceder sin autenticación, el resultado es que el sistema redirige al módulo de
Login, de esta forma,cada una de las rutas del sistema están protegidas, evitando que algún
intruso intente realizar alguna acción.
4.4.3 Prueba de notificaciones

Cuando un usuario realiza una acción, como por ejemplo el agendar una cita a un paciente, a
éste último se le debe de avisar con una notificacio. Para esta prueba se utilizó 2 navegadores,
uno Firefox y el otro Google Chrome, desde el primer navegador el usuario está autenticado
como médico, y en el segundo como usuario. Desde la cuenta del médico se realizaron varias
acciones a las citas del paciente, como lo es agregar y eliminar. En la Figura 19 se muestra
la recepción de la notificaciones por parte del paciente, y en la Figura 20 se muestran las
notificaciones que el paciente ha recibido.
Figura 19: Notificación en tiempo real desde dos navegadores.
42
Figura 20: Notificaciones que ha recibido el paciente.
4.4.4 Prueba de chat

Los usuarios pueden mantener una conversación entre ellos, para que el chat funcione cor-
rectamente, como con las notificaciones, se hace uso de ”Firebase Cloud Messagin”, en la
Figura 21 se muestra el chat con el tamaño de un dispositivo móvil.
(b) Conversación entre 2

(a) Contactos para chat. usuarios.
Figura 21: Prueba de chat entre 2 usuarios.
43
4.4.5 Prueba de gestión de agendas

A continuación se muestra la prueba de gestión de agendas, en donde un usuario agendará
una cita a un médico, ésta debe verse reflejada en el calendario del médico para verificar que
haya funcionado correctamente. En la Figura 22 se observa el formulario para agendar una
cita por parte de un paciente, y en la Figura 23 se ven los detalles de la cita, y las acciones
que puede realizar el médico.
Figura 22: Formulario para agendar una cita.
Figura 23: Detalles de la cita.
44
5 Conclusiones y Trabajo Futuro

El uso de sistemas de información, es algo que forma parte del dı́a a dı́a de las personas, es
por eso que la evolución y desarrollo de nuevos sistemas es muy importante, ya que cada vez
las necesidades de las empresas y de los usuarios van en aumento, exigiendo que cumplan
cada vez funciones y apoyen en una gran cantidad de tareas.
Durante este proyecto, se desarrolló una solución web, la cual ayuda en la gestión de las
agendas de los consultorios médicos, ası́ como apoyo en la comunicación entre el médico y
el paciente, y además ayuda en la creación de recetas electrónicas. Ésto se logra siguiendo
los pasos en la metodologı́a utilizada e implementando cada una de las herramientas men-
cionadas.
Con el sistema desarrollado, se logra facilitar el tratamiento que llevan los médicos con su pa-
cientes, mejorando la comunicación e interacción, además de que con la información obtenida,
sirve como apoyo para lograr el veredicto en un análisis médico.
Como trabajo futuro, se prevé desarrollar los módulos restantes del sistema, como lo son el
registro de usuarios, un mapa con geolocalización de farmacias, además del desarrollo de una
versión para dispositivos móviles android entre otros puntos. A continuación se listaran los
puntos de trabajo para el mejoramiento del sistema.
• Creación de registro de usuarios.
• Desarrollo de una versión móvil.
• Geolocalización de farmacias, para venta de medicamentos.
• Sistema de puntuación para médicos y consultorios.
• Reportar pacientes, o médicos.
45
Índice de figuras
1 Diagrama de flujo para realizar citas médicas. . . . . . . . . . . . . . . . . . 2
2 Esquema de un sistema web dinámico. . . . . . . . . . . . . . . . . . . . . . 9
3 Ejemplo de la estructura de una solicitud get y su respectiva respuesta [26]. . 11
4 Proceso de petición http [27]. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5 Esquema de la arquitectura cliente-servidor [28]. . . . . . . . . . . . . . . . . 12
6 Ciclo de vida e interacción de las capas del MVC [31]. . . . . . . . . . . . . . 13
7 Comunicación entre clientes y un api rest [35] . . . . . . . . . . . . . . . . . 14
8 Esquema de la metodologı́a scrum [39]. . . . . . . . . . . . . . . . . . . . . . 19
9 Esquema de la arquitectura del sistema. . . . . . . . . . . . . . . . . . . . . 20
10 Caso de uso del módulo de login. . . . . . . . . . . . . . . . . . . . . . . . . 26
11 Diagrama de casos de uso de la búsqueda de consultorios. . . . . . . . . . . . 27
12 Diagrama de casos de uso del chat entre usuarios. . . . . . . . . . . . . . . . 28
13 Diagrama de casos de uso para generar prescripciones electrónicas. . . . . . . 29
14 Diagrama de casos de uso para la selección de consultorios. . . . . . . . . . . 30
15 Diagrama de casos de uso para la selección de un médico. . . . . . . . . . . . 31
16 Diagrama de casos de uso para agendar una cita. . . . . . . . . . . . . . . . 32
17 Prueba de responsividad para el módulo de calendario. . . . . . . . . . . . . 41
18 Solicitud de acceso sin autorización. . . . . . . . . . . . . . . . . . . . . . . . 42
19 Notificación en tiempo real desde dos navegadores. . . . . . . . . . . . . . . . 42
20 Notificaciones que ha recibido el paciente. . . . . . . . . . . . . . . . . . . . 43
21 Prueba de chat entre 2 usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . 43
22 Formulario para agendar una cita. . . . . . . . . . . . . . . . . . . . . . . . . 44
23 Detalles de la cita. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
46
Índice de tablas
1 Ejemplos de códigos HTTP y su significado [25]. . . . . . . . . . . . . . . . 10
2 Ejemplos de métodos para una solicitud HTTP [25]. . . . . . . . . . . . . . 11
3 Ejemplos de URI's. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Especificaciones del módulo login. . . . . . . . . . . . . . . . . . . . . . . . 21
5 Especificaciones del módulo Selección de consultorio. . . . . . . . . . . . . . 21
6 Especificaciones del módulo de agenda. . . . . . . . . . . . . . . . . . . . . 22
7 Especificaciones del módulo de prescripciones electrónicas. . . . . . . . . . . 23
8 Especificaciones del módulo de selección de médico. . . . . . . . . . . . . . . 23
9 Especificaciones del módulo de búsqueda de consultorios. . . . . . . . . . . 24
10 Especificaciones del módulo de chat. . . . . . . . . . . . . . . . . . . . . . . 24
11 Especificaciones del módulo de notificaciones. . . . . . . . . . . . . . . . . . 25
12 Descripción del caso de uso del módulo login. . . . . . . . . . . . . . . . . . 26
13 Descripción del caso de uso del módulo de búsqueda de consultorios. . . . . 27
14 Descripción del caso de uso de chat. . . . . . . . . . . . . . . . . . . . . . . 28
15 Descripción del caso de uso de Prescripciones Electrónicas. . . . . . . . . . 29
16 Descripción del caso de uso para seleccionar consultorio. . . . . . . . . . . . 31
17 Descripción del caso de uso Seleccionar Médico. . . . . . . . . . . . . . . . . 32
18 Descripción del caso de uso Gestión de agendas. . . . . . . . . . . . . . . . 33
19 Entidades de la base de datos y su respectiva descripción. . . . . . . . . . . 36
47
Referencias
[1] Microsoft. Impulse la transformación digital con Dynamics 365. https://www.micr
osoft .com /es - xl / dynamics365 ? &wt. mc _id =AID623224 _ SEM_ toby2myZ& gclid=
CjwKCAiApJnRBRBlEiwAPTgmxJP5ir1V6gFdBbdeePog9FCrfSbRnY - FlvwtVwtmN34W7Kk
jMGiXDxoC9qgQAvD_BwE.
[2] Instituto Mexicano del seguro social. Cita Médica Digital. http://www.imss.gob.mx/
cita-medica. Consultado el 06-12-2017.
[3] CONTPAQ. CONTPAQ. https://www.contpaqi.com/CONTPAQi/perfil.aspx.
[4] Salesforce. Salesforce. https://www.salesforce.com/mx/.
[5] J A. Flórez Lozanoa, P C. Martı́nez Suáreza, and C. Valdés Sáncheza. Análisis de
la comunicación en la relación médico-paciente. http : / / www . elsevier . es / es -
revista- medicina- integral- 63- articulo- analisis- comunicacion- relacion-
medico-paciente-15330. Consultado el 06-12-2017.
[6] Sreevidya Krishna. Llevando los registros médicos a la era digital. https://www.ibm.
com/developerworks/ssa/industry/library/ind-openemr/index.html. 2011.
[7] Marı́a Guadalupe Veloz-Martı́nez et al. Uso de tecnologı́as en información y comuni-
cación por médicos residentes de ginecologı́a y obstetricia. http://riem.facmed.unam.
mx/sites/all/archivos/V1Num04/05_AO_USO_DE_TECNOLOGIAS.PDF. Consultado el
06-12-2017.
[8] Mayer Pujadas and Leis Machı́n. El correo electrónico en la relación médico-paciente:
uso y recomendaciones generales. https://es.slideshare.net/Qirxaz1/ejemplo-
para-redactar-antecedentes-del-proyecto. Consultado el 06-12-2017.
[9] Walter H Curioso, Ernesto Gozzer, and Juan Rodrı́guez Abad. Acceso y uso de las
tecnologı́as de información y comunicación y percepciones hacia un sistema informático
para mejorar la adherencia al tratamiento, en médicos endocrinólogos de un hospital
público de Perú. http://www.scielo.org.pe/scielo.php?script=sci_arttext&
pid=S1018-130X2011000100004. Consultado el 06-12-2017.
[10] Assetta A. et al. Sistemas de Información Hospitalaria. http://www.intramed.net/
contenidover.asp?contenidoID=44061.
[11] Florina Gatica Lara and Fernando J. Fernández Puerto. Sistema de Información Hos-
pitalaria. http://www.facmed.unam.mx/emc/computo/ssa/HIS/his.pdf. Consultado
el 06-12-2017.
[12] José Antonio Salvador Oliván. Sistemas de informacion hospitalarios: el C.M.B.D.
http://www.ibersid.eu/ojs/index.php/scire/article/viewFile/1081/1063.
Consultado el 06-12-2017.
[13] Jim Gettys, Phil Karlton, and Scott McGregor. “A BRIEF HISTORICAL OVERVIEW
OF HOSPITAL INFORMATION SYSTEM (HIS) EVOLUTION IN THE UNITED
STATES”. In: (1991).
48
[14] Larry Grandia. Healthcare Information Systems: A Look at the Past, Present, and
Future. https://www.healthcatalyst.com/healthcare- information- systems-
past-present-future. Consultado el 06-12-2017.
[15] Bonnie Kaplan. “Development and acceptance of medical information systems: an his-
torical overview.” In: (1988).
[16] Karen A. Wager, Frances Wickham Lee, and John P. Glaser. Health Care Information
Systems A Practical Approach for Health Care Management. Jossey-Bass, 2013.
[17] Food and Drug Administration. Strategies to Reduce Medication Errors: Working to
Improve Medication Safety. https://www.fda.gov/Drugs/ResourcesForYou/Consum
ers/ucm143553.htm. Consultado el 06-12-2017.
[18] RANDALL STROSS. Chicken Scratches vs. Electronic Prescriptions. http: //www.
nytimes . com / 2012 / 04 / 29 / business / e - prescriptions - reduce - errors - but -
their-adoption-is-slow.html. Consultado el 06-12-2017.
[19] SHARON OTTERMAN. The End of Prescriptions as We Know Them in New York.
https : / / www . nytimes . com / 2016 / 03 / 15 / nyregion / new - york - to - discard -
prescription- pads- and- doctors- handwriting- in- digital- shift.html?_r=0.
Consultado el 06-12-2017.
[20] Prescrypto. Prescrypto. https://www.prescrypto.com/. Consultado el 06-12-2017.
[21] GCF AprendeLibre. ¿Qué es una aplicación web? https://www.gcfaprendelibre.
org/tecnologia/curso/informatica_basica/aplicaciones_web_y_todo_acerca_
de_la_nube/1.do.
[22] Consulta Curp. https://consultas.curp.gob.mx/CurpSP/inicio2_2.jsp.
[23] Wiboo. ¿Qué son las Aplicaciones Web? Ventajas y Tipos de Desarrollo Web. https:
/ / wiboomedia . com / que - son - las - aplicaciones - web - ventajas - y - tipos - de -
desarrollo-web/#tab-con-1.
[24] Algsa. Ventajas y desventajas de las aplicaciones web. http://www.alegsa.com.ar/
Respuesta/ventajas_y_desventajas_de_las_aplicaciones_web.htm.
[25] Álvaro Primo Guijarro. Protocolo HTTP. https : / / alvaroprimoguijarro . files .
wordpress.com/2012/01/ud04_http_alvaroprimoguijarro.pdf. 2012.
[26] Nanyang technological University. HTTP (HyperText Transfer Protocol). https : / /
www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html.
[27] Miguel Rodrı́guez. ¿Cómo funciona el protocolo HTTP? https : / / www . miguelra .
com/como-funciona-el-protocolo-http/. 2016.
[28] Emiliano Marini. El Modelo Cliente/Servidor. https://radiosyculturalibre.com.
ar/biblioteca/REDES/linuxito%20-%20El%20Modelo%20Cliente-Servidor.pdf.
2012.
[29] Bertha Mariel Márquez Avendaño. Implementación de un reconocedor de voz gratuito
a el sistema de ayuda a invidentes Dos-Vox en español. http://catarina.udlap.mx/
u_dl_a/tales/documentos/lis/marquez_a_bm/. 2004.
49
[30] Modelo Vista Controlador. https://es.scribd.com/document/51278468/Modelo-

Vista-Controlador.
[31] Rodrigo Gómez. Modelo Vista Controlador. http://rodrigogr.com/blog/modelo-
vista-controlador/. 2015.
[32] Universidad Nacional de la Plata. Modelo–vista–controlador. http://material.concu
rsos.econo.unlp.edu.ar/concursos/T%C3%A9cnico-Profesional%20(Inform%C3%
A1tica)/patrones/Modelo%E2%80%93vista%E2%80%93controlador.pdf.
[33] Nick Heidke, Joline Morrison, and Mike Morrison. Assessing the Effectiveness of the
Model View Controller Architecture for Creating Web Applications. http://micsympo
sium.org/mics_2009_proceedings/mics2009_submission_55.pdf.
[34] Adrián Peña. Qué es un servicio RESTFUL. http : / / www . i2factory . com / es /
integracion/qu%C3%A9-es-un-servicio-restful. 2016.
[35] infosys. Best Practices for Building Resful Web Services. https://www.infosys.com/
digital/insights/Documents/restful-web-services.pdf. 2017.
[36] Universidad Nacional del Litorial. Modelo Entidad Relación. http://www.fca.unl.
edu.ar/agromatica/Docs/09-ModeloEntRel.PDF.
[37] Robbie Pewter. Cómo funcionan las notificaciones push. https://maxwell.softonic.
com/blog/screen-locker/como-funcionan-las-notificaciones-push. 2016.
[38] Matt Gaunt. Service Workers: introducción. https://developers.google.com/web/
fundamentals/primers/service-workers/?hl=es.
[39] Proyectos Agiles.org. Qué es SCRUM. https : / / proyectosagiles . org / que - es -
scrum/.
50

Tesina Gloria Vazquez PDF

Cargado por

Información del documento

Título original

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

Tesina Gloria Vazquez PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD POLITÉCNICA DE VICTORIA

DESARROLLO DE SISTEMA WEB PARA

Cd. Victoria, Tamaulipas a 12 de Diciembre de 2017

Vı́ctor Manuel Gloria Vázquez

Le comunico que el Programa Académico de Ingenierı́a en Tecnologı́as de la

Desarrollo de sistema web para servicios de comunicación medica

Dr. Said Polanco Martagón

c.c.p Director de programa académico

AV. NUEVAS TECNOLOGÍAS 5902 UNIVERSIDAD

Siendo las hrs del dı́a de de 201 ,

Una vez concluido el proceso de evaluación, y con base a la rúbrica estable-

Dr. Said Polanco Martagón

MSC. Jorge Arturo Hernández Almazan

Dada la necesidad de ayudar a optimizar la gestión de las agendas médicas y la comunicación

3.5.1 Caso de uso del login . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Conclusiones y Trabajo Futuro 45

Consecuentemente, los sistemas de información se han vuelto una herramienta vital en el

Sin duda alguna, la importancia de la comunicación es un punto clave a la hora de establecer

Figura 1: Diagrama de flujo para realizar citas médicas.

anteriormente han sido desarrollados; posteriormente se hará mención de la justificación de

Miguel Ángel Mayer doctor en Ciencias de la salud y de la vida de la universidad Pompeu

El artı́culo “Acceso y uso de las tecnologı́as de información y comunicación y percepciones

Por lo tanto, se dio inició al desarrollo de sistemas de información especializados en las

• Gestión de los pacientes.

• Administración de los recursos económicos.

• Comunicación entre médicos y pacientes.

• Control de información de los medicamentos.

• Consulta de información sobre pacientes.

• Administración de los horarios.

• Sistema de Manejo de Materiales.

El flujo de la información es el elemento más importante que participa en los procesos de

1.3 Objetivo General

1.4 Objetivo Particular

• Implementar herramientas y tecnologı́as web para el desarrollo de módulos especı́ficos

• Desarrollar módulo de transferencia de recetas médicas.

1.5 Descripción y Alcances del Proyecto

• Gestión de usuarios y manejo de sesiones.

• Búsqueda de consultorios con geolocalización.

• Creación de prescripciones electrónicas.

Las limitaciones presentadas para el desarrollo de éste proyecto son:

• Se tiene restringido el uso de servicios de paga.

• El periodo de tiempo para realizar el proyecto es algo corto.

2.1 Sistemas web

• IMSS Digital [2].

• Consulta Curp [22].

Figura 2: Esquema de un sistema web dinámico.

2.1.1 Ventajas y Desventajas

2.1.2 Protocolo HTTP

Tabla 1: Ejemplos de códigos HTTP y su significado [25].

Tabla 2: Ejemplos de métodos para una solicitud HTTP [25].

TCP. En la Figura 4 se ve representado el proceso de una petición HTTP desde la solicitud

Figura 3: Ejemplo de la estructura de una solicitud get y su respectiva respuesta [26].

Figura 4: Proceso de petición http [27].

2.1.3 Arquitectura cliente-servidor

Figura 5: Esquema de la arquitectura cliente-servidor [28].

Cliente: en la arquitectura cliente-servidor, el cliente es el que hace la manipulación y el

• Administrar la interfaz de usuario.

• Aceptar los requerimientos de bases de datos que hacen los clientes.

• Procesar requerimientos de bases de datos.

• Formatear datos para transmitirlos a los clientes.

• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.

Figura 6: Ciclo de vida e interacción de las capas del MVC [31].

Vista: La vista es la interfaz gráfica en donde se muestra la información del modelo al