Download 0 implementación de un aplicativo web en plataforma j2ee para la

IMPLEMENTACIÓN DE UN APLICATIVO WEB EN PLATAFORMA J2EE
PARA LA ADMINISTRACIÓN DE CITAS E HISTORIAS ODONTOLÓGICAS
JOHANNA MARITZA BOLAÑOS BARRIOS
NATALIA LONDOÑO OSPINA
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2010
0
IMPLEMENTACIÓN DE UN APLICATIVO WEB EN PLATAFORMA J2EE
PARA LA ADMINISTRACIÓN DE CITAS E HISTORIAS ODONTOLÓGICAS
JOHANNA MARITZA BOLAÑOS BARRIOS
NATALIA LONDOÑO OSPINA
Proyecto de grado como requisito para optar por el título de Ingeniero de Sistemas.
ASESOR
EMILIO BARAJAS
INGENIERO DE SISTEMAS
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2010
1
Nota de aceptación
_________________________
_________________________
_________________________
_________________________
Presidente del Jurado
_________________________
Firma del Jurado
_________________________
Firma del jurado
Bogotá D.C., Noviembre de 2010
2
Dedico mi trabajo al Dios de la vida, que me ha dado una nueva oportunidad de vivir. A mi
familia por todo su apoyo incondicional y todos aquellos que de una u otra manera han
apoyado mi estudio y han sido oportunos con sus consejos y sugerencias.
Mis padres, Juan Antonio y María Ruth han sido ejemplares en la comunicación de
valores, de ellos aprendí la perseverancia, la constancia, la dedicación y el valor mostrado
para salir adelante. Gracias papás por su amor.
A Gabriel por haberme apoyado en todo momento, por sus exigencias, pero más que
nada, por su comprensión. A mi compañera de tesis, que gracias al equipo y la unidad
que formamos, logramos llegar hasta el final.
Natalia Londoño Ospina
A Dios por darme la oportunidad que me brindo al llegar hasta aquí, a mis padres y familia
porque sin su apoyo incondicional este paso en mi vida no hubiese sido posible de
alcanzar, a mis amigos que siempre me dieron una voz de aliento y de ánimo para no
desfallecer en este proceso y a mi compañera Natalia por su colaboración, esfuerzo y
constancia para terminar con éxito el propósito que nos unió.
Johanna Maritza Bolaños Barrios
3
TABLA DE CONTENIDO
INTRODUCCIÓN..............................................................................................................13
1.
PLANTEAMIENTO DEL PROBLEMA ......................................................................14
1.1. ANTECEDENTES (ESTADO DEL ARTE) ...............................................................14
1.2. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA .............................................15
1.3. JUSTIFICACIÓN .....................................................................................................15
1.4. OBJETIVOS ............................................................................................................17
1.4.1. Objetivo General....................................................................................................17
1.4.2. Objetivos Específicos. ...........................................................................................17
1.5. ALCANCES Y LIMITACIONES ................................................................................17
1.5.1. Alcances................................................................................................................17
1.5.2. Limitaciones...........................................................................................................18
2.
METODOLOGÍA......................................................................................................20
3.
LÍNEA DE INVESTIGACIÓN ...................................................................................21
3.1. ENFOQUE DE LA INVESTIGACIÓN .......................................................................21
3.2. LÍNEA DE INVESTIGACIÓN DE USB .....................................................................21
3.3. SUB-LÍNEA DE FACULTAD ....................................................................................21
3.4. CAMPO TEMÁTICO DEL PROGRAMA...................................................................21
4.
MARCO DE REFERENCIA .....................................................................................22
4.1. TEÓRICO CONCEPTUAL .......................................................................................22
4.1.1. Metodología de Desarrollo de Software .................................................................22
4.1.2. Servidor de Aplicaciones .......................................................................................25
4.1.3. Base de Datos. ......................................................................................................27
4.1.4. Plataforma J2EE....................................................................................................29
4.1.5. JavaBean. .............................................................................................................31
4.1.6. SMS (Short Message Service)...............................................................................31
4.1.7. Administración de la Historia Clínica Odontológica. ...............................................32
4.1.8. Proceso para solicitar una cita odontológica ..........................................................33
4.2. MARCO LEGAL O NORMATIVO.............................................................................34
4.2.1. RESOLUCIÓN NÚMERO 1995 DE 1999 (JULIO 8) ..............................................34
4
5.
DESARROLLO INGENIERIL ...................................................................................35
5.1. METODOLOGÍA DEL PROYECTO .........................................................................35
5.2. ANÁLISIS Y DEFINICIÓN DE REQUERIMIENTOS.................................................35
5.2.1. Levantamiento de información. ..............................................................................35
5.2.2. Requerimientos funcionales...................................................................................36
5.2.3. Requerimientos no funcionales..............................................................................38
5.3. DISEÑO DEL SISTEMA Y DE SOFTWARE. ...........................................................39
5.3.1. Diseño del sistema. ...............................................................................................39
5.3.1.2. Diagramas de casos de uso................................................................................40
5.3.2. Diseño del software. ..............................................................................................54
5.4.
IMPLEMENTACIÓN Y PRUEBA DE UNIDADES....................................................83
5.4.1. Implementación. ....................................................................................................83
5.4.2. Prueba de Unidades. .............................................................................................95
5.5.
INTEGRACIÓN Y PRUEBAS DEL SISTEMA. ......................................................101
5.6.
FUNCIONAMIENTO Y MANTENIMIENTO ...........................................................105
6.
PRESENTACIÓN Y ANÁLISIS DE RESULTADOS ..............................................106
CONCLUSIONES...........................................................................................................109
RECOMENDACIONES...................................................................................................110
BIBLIOGRAFÍA ..............................................................................................................111
WEBGRAFÍA..................................................................................................................113
GLOSARIO ODONTOLÓGICO ......................................................................................115
GLOSARIO TÉCNICO....................................................................................................116
5
LISTA DE TABLAS
Tabla 1. Cuadro Comparativo...........................................................................................16
Tabla 2. Metodologías de Desarrollo de Software. ...........................................................24
Tabla 3. Servidor de Aplicaciones. ...................................................................................26
Tabla 4. Motor de Base de Datos. ....................................................................................28
Tabla 5. Descripción Caso de Uso Registrar Usuario. ......................................................41
Tabla 6. Descripción Caso de Uso Autenticar Usuario......................................................41
Tabla 7. Descripción Caso de Uso Gestionar Historia Clínica...........................................42
Tabla 8. Descripción Caso de Uso Gestionar Cita. ...........................................................43
Tabla 9. Descripción Caso de Uso Gestionar Datos Básicos de Usuarios. .......................44
Tabla 10. Descripción Caso de Uso Generar Reportes. ...................................................44
Tabla 11. Descripción Caso de Uso Cerrar Sesión...........................................................45
Tabla 12. Descripción Caso de Uso Solicitar Cita.............................................................47
Tabla 13. Descripción Caso de Uso Consultar Cita. .........................................................48
Tabla 14. Descripción Caso de Uso Cancelar Cita. ..........................................................48
Tabla 15. Descripción Caso de Uso Crear Historia Clínica. ..............................................49
Tabla 16. Descripción Caso de Uso Actualizar Historia Clínica. .......................................50
Tabla 17. Descripción Caso de Uso Consultar Historia Clínica.........................................50
Tabla 18. Descripción Caso de Uso Actualizar Datos de Usuarios. ..................................51
Tabla 19. Descripción Caso de Uso Enviar Sms...............................................................52
Tabla 20. Paciente............................................................................................................65
Tabla 21. Asistente...........................................................................................................66
Tabla 22. Odontólogo ......................................................................................................67
Tabla 23. Acudiente..........................................................................................................68
6
Tabla 24. Estudio..............................................................................................................69
Tabla 25. Historia_Clínica.................................................................................................70
Tabla 26. Plan_de_Tratamiento........................................................................................71
Tabla 27. Examen_Básico................................................................................................72
Tabla 28. Diente. ..............................................................................................................72
Tabla 29. Evolución ..........................................................................................................73
Tabla 30. Anexos..............................................................................................................74
Tabla 31. Citas. ................................................................................................................75
Tabla 32. Servicio.............................................................................................................76
Tabla 33. Servicios_Por_Odontólogo. ..............................................................................76
Tabla 34. SMS..................................................................................................................77
Tabla 35. Usuario: Administrador. ....................................................................................78
Tabla 36. Usuario: Odontólogo. ........................................................................................78
Tabla 37. Usuario: Asistente.............................................................................................79
Tabla 38. Usuario: Paciente. ............................................................................................79
Tabla 39. Caso de Prueba Iniciar Sesión..........................................................................96
Tabla 40. Caso de Prueba Cerrar Sesión. ........................................................................96
Tabla 41. Caso de Prueba Registrar Usuario. ..................................................................96
Tabla 42. Caso de Prueba Actualizar Usuario. .................................................................97
Tabla 43. Caso de Prueba Crear Historia Clínica Odontológica........................................97
Tabla 44. Caso de Prueba Consultar Historia Clínica Odontológica. ................................98
Tabla 45. Caso de Prueba Solicitar Cita. ..........................................................................98
Tabla 46. Caso de Prueba Cancelar Cita. ........................................................................98
Tabla 47. Caso de Prueba Enviar SMS. ...........................................................................99
Tabla 48. Caso de Prueba Registrar Usuario Existente. .................................................101
7
Tabla 49. Caso de Prueba Registrar Usuario con datos no válidos. ...............................102
Tabla 50. Caso de Prueba Consultar Cita. .....................................................................103
Tabla 51. Autenticar usuarios con datos no válidos. .......................................................104
8
LISTA DE FIGURAS
Figura 1. Secuencia de actividades para el modelo de cascada.......................................23
Figura 2. Arquitectura J2EE..............................................................................................30
Figura 3. Escenario Basado en la Web.............................................................................31
Figura 4. Diagrama de Caso de Uso Principal ..................................................................40
Figura 5. Diagrama Caso de Uso Administrador...............................................................46
Figura 6. Diagrama Caso de Uso Odontólogo. .................................................................47
Figura 7. Diagrama Caso de Uso Asistente. .....................................................................52
Figura 8. Diagrama Caso de Uso Paciente.......................................................................53
Figura 9. Diagrama de Clases Dentistry Web. ..................................................................54
Figura 10. Diagrama de Secuencia Registrar Usuario. .....................................................56
Figura 11. Diagrama de Secuencia Crear Historia Clínica. ...............................................57
Figura 12. Diagrama de Secuencia Solicitar Cita..............................................................58
Figura 13. Diagrama de Secuencia Enviar SMS. ..............................................................59
Figura 14. Diagrama de Secuencia Actualizar Datos........................................................59
Figura 15. Diagrama de Actividades Odontólogo y Administrador. ...................................61
Figura 16. Diagrama de Actividades Asistente y Paciente. ...............................................62
Figura 17. Modelo Base de Datos Dentistry Web. ............................................................64
Figura 18. Diseño del Odontograma. ................................................................................80
Figura 19. Herramientas para el diseño de Interfaces. .....................................................81
Figura 20. Herramientas para el diseño de interfaces.......................................................82
Figura 21. Escenario Basado en la Web de J2EE. ...........................................................84
Figura 22. Conexión Base de Datos. ................................................................................85
9
Figura 23. Propiedades de la base de datos.....................................................................86
Figura 24. Consulta Personas. .........................................................................................87
Figura 25. Consulta Citas. ................................................................................................87
Figura 26. Consulta Pacientes..........................................................................................88
Figura 27. Consulta Odontólogos. ....................................................................................88
Figura 28. Consulta Citas Agendadas ..............................................................................89
Figura 29. JavaBeans de la aplicación. ............................................................................91
Figura 30. Código para envió de SMS. .............................................................................92
Figura 31. JSP´s de la aplicación. ....................................................................................94
Figura 32. Interfaz Gráfica del Aplicativo. .........................................................................95
Figura 33. Envio de SMS..................................................................................................99
Figura 34. Confirmación de Salida SMS .........................................................................100
Figura 35. Error Registro. ...............................................................................................102
Figura 36. Cita Asignada. ...............................................................................................103
Figura 37. Error Registro. ...............................................................................................104
10
LISTA DE GRÁFICAS
Gráfica 1. Resultados Encuesta – Preguntas 1 y 14......................................................142
Gráfica 2. Resultados Encuesta – Preguntas 3, 4, 5 y 7. ................................................143
Gráfica 3. Resultados Encuesta – Preguntas 8, 9, 10 y 11. ............................................144
Gráfica 4. Resultados Encuesta – Preguntas 12, 13, 15, 16 y 17. ..................................145
11
LISTA DE ANEXOS
ANEXO A. Ejemplo de procedimiento institucional documentado para el uso y manejo de
la historia clínica de un servicio odontológico .................................................................117
ANEXO B. Formato Historia Clínica Odontológica ......................................................126
ANEXO C. Resolución Número 1995 de 1999 (Julio 8) MINISTERIO DE SALUD ........128
ANEXO D. Encuesta pacientes .....................................................................................139
ANEXO E. Resultados de las encuestas .......................................................................142
ANEXO F. Ficha técnica y resultados encuestas...........................................................146
ANEXO G. Entrevista odontóloga...................................................................................147
12
INTRODUCCIÓN
El desarrollo avanzado de la tecnología ha hecho posible utilizar la ciencia en beneficio de
la humanidad, haciendo cada vez más eficientes los procesos, facilitando las actividades
humanas. Es así como este proyecto plantea el uso de la tecnología para la
implementación de un aplicativo web que facilite el proceso de administración de las citas
e historias odontológicas.
Según Roger S. Pressman en su libro Ingeniería del Software (un enfoque práctico): “las
Aplicaciones Web o WebApps son diferentes de otras categorías de software informático;
son eminentemente en red, las gobiernan los datos y se encuentran en evolución
continua. Las WebApps pueden valorarse mediante una diversidad de criterios de calidad
que incluyen facilidad de uso, funcionalidad, confiabilidad, eficiencia, capacidad de
mantenimiento, seguridad, disponibilidad y escalabilidad”.
La aplicación web se desarrollará en la plataforma J2EE (Java 2 Enterprise Edition) la
cual se basa en una estructura multicapa para el desarrollo de los sistemas. La división de
capas para estructura es la siguiente: Capa de presentación, Capa de negocios y Capa de
integración.
El aplicativo contará con SMS (Short Message Service), servicio por medio del cual se
utiliza el sitio web para enviar a través de internet un mensaje al teléfono móvil de cada
paciente, recordando el día y la hora de su próxima cita odontológica. Adicionalmente la
implementación se hará con un servidor de aplicaciones Java, sobre una plataforma J2EE
(Java 2 Enterprise Edition). Este estándar permite el desarrollo de aplicaciones de una
manera eficiente y versátil.
13
1. PLANTEAMIENTO DEL PROBLEMA
1.1.
ANTECEDENTES (ESTADO DEL ARTE)
En Colombia ya se ha desarrollado software para consultorios odontológicos. Uno de los
más conocidos hasta el momento es Pro práctica Dental Software1, éste fue desarrollado
en idioma Español específicamente para los consultorios o clínicas de Odontología;
lanzado al mercado en el año 1.999 y se ha venido actualizando para cubrir todos los
aspectos de la gestión moderna de los profesionales del ramo Odontológico.
Su uso permite administrar de manera eficiente y rentable la información médica y
económica de los pacientes de su consultorio o clínica dental, así como llevar un registro
organizado del historial clínico odontológico de sus pacientes.
Otra alternativa de software dental es DentiLogic2, el cual posee todas las herramientas
que se necesitan para gestionar una clínica odontológica en un entorno intuitivo y
amigable, mientras que el sistema se encarga de procesos complejos y rutinarios. Aunque
este software tiene un costo comercial de $1.265.000 anual, que puede ser considerado
alto para un consultorio odontológico promedio.
Al mismo tiempo Dental Pro3 es otro software que da el control completo sobre los
tratamientos odontológicos de los pacientes en el Consultorio. Base de Datos Profesional
pensado tanto para principiantes como para profesionales, lleva el control de: Pacientes,
Historias Clínicas, Presupuestos, Pagos y/o Abonos, Tratamientos y/o Trabajos Dentales,
Agenda de Citas, Estado de Cuenta, Fotos e Imágenes, Recetas Médicas y Trabajos de
Laboratorio.
1
Pro practica, [artículo en línea] Disponible desde Internet en: <http://propractica.tripod.com/>,Mayo 15 de 2010.
7:30pm.
2
Dentilogic, [artículo en línea] Disponible desde Internet en: <https://www.dentilogic.com/acm/es/dl/About.htm>, Mayo
15 de 2010. 8:30pm.
3
Dental Pro, [artículo en línea] Disponible desde Internet en: <http://www.digitalab-software.com/consultorio>, Mayo 15
de 2010. 8:40pm.
14
Finalmente existe Galeno Dental4 que se dedica al almacenamiento e identificación de
imágenes y videos, registro personalizado y manipulación precisa de imagen,
administración de todas las citas, horarios y consultorios.
El consultorio que se tendrá como referencia para hacer el levantamiento de información y
definir los requerimientos está en funcionamiento hace 15 años, no tiene un software que
administre la información de cerca de 240 pacientes que en promedio acceden a este
servicio en el mes, los cuales se atienden en un horario de 9:00 a.m. a 12:00 p.m. y de
2:00 p.m. a 5:00 p.m., y tienen media hora de tiempo para cada consulta. La forma en la
que se crean las historias es lenta, además que la asignación de citas la hacen en el
calendario de Outlook registrando el nombre del paciente, su número telefónico fijo, la
fecha y la hora de la próxima cita o también se puede hacer telefónicamente.
1.2.
DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA
En la actualidad algunas clínicas y consultorios odontológicos no tienen implementado un
sistema que permita administrar la información de los pacientes que buscan una solución
a sus problemas dentales.
Esta información se consigna en una historia clínica odontológica, la cual es diligenciada
manualmente por el odontólogo para luego ser archivadas en carpetas y folders, lo cual
no es lo más adecuado porque con el tiempo se van deteriorando. En el momento de
consultar, actualizar o verificar la información de cada paciente la búsqueda es lenta y
tarda más tiempo.
¿Cómo implementar un aplicativo web en plataforma J2EE para la administración
de citas e historias odontológicas?
1.3.
JUSTIFICACIÓN
Las clínicas necesitan un sistema de información que permita crear una historia
odontológica para almacenar los datos de cada paciente, hacer un seguimiento de su
tratamiento, evolución y procedimientos realizados de una manera más ágil.
4
Galeno Dental, [artículo en línea] Disponible desde Internet en: <http://www.galeno.com.mx/main/index.php>, Mayo 15
de 2010. 9:30pm.
15
Las ventajas de Dentistry Web con respecto a los mencionados en la tabla 1 son el bajo
costo de las herramientas de desarrollo. Asimismo la aplicación contará con una interfaz
web cuyo beneficio es que se puede acceder a un servidor web a través de internet lo
cual significa que no se instala el software en varias pc’s.
CUADRO COMPARATIVO ENTRE DENTISTRY WEB Y OTROS SISTEMAS
Tabla 1. Cuadro Comparativo
CARACTERÍSTICAS
DENTAL SOFTWARE
DENTILOGIC
DENTISTRY WEB
Manejo de citas
Si
Si
Si
Manejo de historias
Si
Si
Si
Costo comercial
$ 1.100.000
$ 1.265.000
$ 1.000.000
Interfaz web
No
Si
Si
Usabilidad
Si
Si
Si
Los beneficios que se pueden encontrar en el aplicativo son: Tener un manejo del tiempo
eficiente en una consulta odontológica, proporciona información inmediata sobre las
historias clínicas odontológicas. Con la implementación del aplicativo web se va a tener un
control de toda la información relacionada con los pacientes (datos personales, historia
odontológica, antecedentes personales y familiares, tratamiento a realizar, procedimientos
realizados y programación de sus citas). Su uso permitirá administrar de manera eficiente
la información odontológica de los pacientes, llevar un registro organizado del historial
odontológico permitiendo una búsqueda ágil y fácil.
El aplicativo web cumplirá con los requerimientos necesarios de confidencialidad de las
historias odontológicas mediante la autenticación (seguridad) que permita sólo el acceso a
personas del consultorio que se encuentran registradas. El acceso al sistema estará
restringido por usuario y contraseña para cada uno de los usuarios.
El odontólogo tendrá la posibilidad de consultar y actualizar las historias clínicas de los
pacientes cuantas veces sea necesario, al mismo tiempo las anotaciones que ya se han
16
realizado anteriormente en los avances de los tratamientos, no podrán ser modificadas ni
eliminadas, solo se podrán agregar nuevas observaciones o comentarios en la evolución
oral de los pacientes.
1.4.
OBJETIVOS
1.4.1. Objetivo General. Implementar un aplicativo web en plataforma J2EE para la
administración de citas e historias odontológicas.
1.4.2. Objetivos Específicos.
 Analizar los requerimientos funcionales y no funcionales para la administración de citas
e historias odontológicas.
 Modelar una base de datos que permita almacenar toda la información relacionada con
los pacientes del consultorio.
 Desarrollar un módulo de autenticación (seguridad) que permita sólo el acceso a
personas del consultorio que se encuentran registradas.
 Diseñar el software para la aplicación en plataforma J2EE que cumpla con el estándar
UML (Unified Modeling Language) para generar un software de calidad.
 Diseñar las interfaces gráficas para el software y el odontograma.
 Implementar el software mediante un servidor de aplicaciones que permita la interacción
con los usuarios (médico o asistente) del consultorio.
 Realizar pruebas de aceptación para determinar si el software cumple con los
requerimientos especificados.
1.5.
ALCANCES Y LIMITACIONES
1.5.1. Alcances. El proyecto culmina con la implementación de la aplicación web y con
las pruebas aceptación que se realizarán para determinar si esta cumple con los
requerimientos especificados.
Esta aplicación contará con varios menús en los que se puede encontrar el paciente con
toda su información personal y de contacto (nombre, apellidos, tipo documento de
identidad, documento de identidad, fecha de nacimiento, género, ocupación, estado civil,
barrio, teléfono y celular). También permitirá agregar nuevos pacientes, actualizar, editar
17
sus datos personales y generar reportes. Además en la historia odontológica de cada
paciente se puede seleccionar un plan de tratamiento adecuado a realizar y almacenar
sus procedimientos realizados anteriormente.
Tendrá un odontograma, en el cual se puede detallar ordenadamente según la secuencia
de los dientes el índice COP (Cariado, Obturado y Perdido) que pueda estar presente en
algunos de los dientes. Para identificar en el odontograma este índice se establece la
siguiente relación: Cariado(C) = color azul, Obturado(O) = color rojo, Perdido (P)= color
verde y si el diente está sano no lleva ningún color.
Permitirá crear citas semanales asignando cada una de ellas en un lapso de treinta
minutos y donde se puede consultar disponibilidad de odontólogos y horarios.
Un valor adicional con el que contará la aplicación web es el SMS, servicio por medio del
cual se puede enviar a través de internet un mensaje al teléfono móvil de cada paciente,
recordando el día y la hora de su próxima cita odontológica. Además el paciente se podrá
comunicar con la clínica telefónicamente donde se le dará respuesta a cualquier inquietud
o solicitud que esté presente.
La implementación de la aplicación web se hará con un servidor de aplicaciones Java,
sobre J2EE. Este estándar permite el desarrollo de aplicaciones de una manera eficiente;
estas aplicaciones son desplegadas en un servidor web llamado Tomcat que cumple con
el estándar J2EE, habilitará el acceso a la información por varias personas a la vez y que
desde cualquier lugar se pueda lograr una gestión eficiente del tiempo.
1.5.2. Limitaciones. Los pacientes no podrán consultar por internet la información de su
historia odontológica debido a políticas internas de las clínicas (Ministerio de Salud,
Resolución 1995 de 1999 capítulo III artículo 14. ACCESO A LA HISTORIA CLÍNICA) el
cual se encuentra en el anexo C, pero en el momento que el paciente lo desee, puede
reclamar una copia de su historia y en la clínica quedará archivado el documento original.
El sistema no contará con un módulo que permita llevar la información contable de la
clínica, especificar pagos, procesos administrativos (recursos humanos, nómina, y otros.)
y/o módulo de cartera.
18
El sistema de SMS se implementará a través de un proveedor de servicios de mensajería,
este servicio depende si el consultorio lo desea implementar.
El consultorio no proporciona ninguna información acerca de los pacientes a personas
externas a este debido a políticas internas, por esta razón sólo fue posible realizar 10
encuestas a pacientes que asisten regularmente.
El aplicativo no contará con el servicio de adicionar ninguna opción diferente a las que se
encuentran establecidas en el formato de la historia clínica detallado en el anexo B.
19
2. METODOLOGÍA
Para el desarrollo del proyecto se tendrán en cuenta los siguientes métodos y
herramientas requeridos para cumplir los objetivos propuestos.
La metodología de desarrollo de software seleccionada es el modelo en cascada en la
cual se deben cumplir con las fases de: Análisis y definición de requerimientos, diseño del
sistema y del software, implementación y prueba de unidades, integración y pruebas del
sistema, funcionamiento y mantenimiento.
En el diseño del sistema del software es necesario escoger un motor de base de datos
que permita almacenarlos, en este caso se escogió My Sql 5.1 ya que es la herramienta
sobre la cual se tiene más conocimiento, es de fácil uso, rápido y lo más importante es
que es un software libre.
Para la fase de implementación, la plataforma J2EE permite crear un escenario ideal para
el desarrollo y despliegue de aplicaciones escalables en la Web, esto hace que se
reduzcan los costos.
El envío de un Sms es un servicio adicional, que hoy en día es uno de los mejores medios
para comunicarse. Se usa en la aplicación para recordar al paciente la hora y fecha de su
próxima cita.
Netbeans IDE 6.7 es el entorno de desarrollo visual de código abierto para aplicaciones
programadas mediante Java, uno de los lenguajes de programación más poderosos del
momento y el cual se usará para el desarrollo esta aplicación.
En la fase de implementación, el aplicativo se publicará en Tomcat 6.0 que es un servidor
de aplicaciones web, el cual ayudará a acceder a la interfaz de la aplicación.
20
3. LÍNEA DE INVESTIGACIÓN
3.1.
ENFOQUE DE LA INVESTIGACIÓN
Empírico-analítico: orientado a la interpretación y transformación del mundo material, que
se realiza con el fin de implementar un aplicativo web en plataforma J2EE para que los
consultorios odontológicos puedan administrar las citas e historias.
3.2.
LÍNEA DE INVESTIGACIÓN DE USB. Tecnologías actuales y sociedad.
3.3.
SUB-LÍNEA DE FACULTAD. Sistemas de información y comunicación.
3.4.
CAMPO TEMÁTICO DEL PROGRAMA. Desarrollo de software.
21
4. MARCO DE REFERENCIA
4.1.
TEÓRICO CONCEPTUAL
4.1.1. Metodología de Desarrollo de Software. En la tabla 2 que se refiere a las
metodologías existentes para este fin, se establecen algunas de ellas describiendo sus
fases, definición, tiempo de ejecución, mantenimiento y procesos que son necesarios para
llevar a cabo el desarrollo de un software.
Para alcanzar los objetivos propuestos en el desarrollo del aplicativo web se escogió la
siguiente metodología que servirá para dar respuesta al problema que se ha planteado.
Según Alfredo Weitzenfeld “El modelo de cascada se define como una secuencia de
actividades, donde la estrategia principal es seguir el progreso del software hacia puntos
de revisión bien definidos mediante entregas calendarizadas”5.
De acuerdo a la metodología mencionada, las principales etapas de este modelo se
transforman en actividades fundamentales de desarrollo, las cuales se representan en la
figura 1 y son:
1. Análisis y definición de requerimientos: En esta fase se analizan las
necesidades de los usuarios finales del software para determinar qué objetivos
debe cubrir. En esta etapa se debe consensuar todo lo que se requiere del sistema
y será aquello lo que seguirá en las siguientes etapas.
2. Diseño del sistema y del software: El proceso de diseño del sistema divide los
requerimientos en sistemas hardware y software. El diseño del software identifica
y describe las abstracciones fundamentales del sistema software y sus relaciones.
3. Implementación y prueba de unidades: En esta etapa el diseño del software se
lleva a cabo como un conjunto de unidades de programas. Los elementos, ya
programados, se ensamblan para componer el sistema y se comprueba que
funciona correctamente y que cumple con los requisitos.
5
WEITZENFELD, Alfredo, Ingeniería de Software. México Thomson 2005. p678.
22
4. Integración y pruebas del sistema: El software obtenido se pone en producción.
Se implantan los niveles software y hardware que componen el proyecto. Durante
la explotación del sistema de software pueden surgir cambios, bien para corregir
errores o bien para introducir mejoras. Después de las pruebas el sistema software
se entrega al cliente.
5. Funcionamiento y mantenimiento: En esta etapa el sistema se instala y se pone
en funcionamiento práctico. El mantenimiento implica corregir errores no
descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación
de las unidades del sistema y resaltar los servicios del sistema una vez se
descubran nuevos requerimientos.6
Figura 1. Secuencia de actividades para el modelo de cascada.
Autor: Ian Sommerville. Ingeniería del software
6
SOMMERVILLE, Ian, Ingeniería del Software, Pearson Educación S.A. Madrid 2005, p 62.
23
Tabla 2. Metodologías de Desarrollo de Software.
METODOLOGÍAS
RUP
EXTREME PROGRAMING (XP)
DESARROLLO GUIADO POR
LA FUNCIONALIDAD O FDD
CICLO DE VIDA
MODELO EN CASCADA
FASES
DEFINICIÓN
• Inicio
• Elaboración
• Construcción
• Transmisión
• Mantenimiento
• Planificación.
El
método
RUP
específica,
principalmente, la constitución del
equipo y las escalas de tiempo, así
como un numero de modelos de
documento
• Planificación
• Diseño
• Desarrollo
• Pruebas
La metodología consiste en una
programación rápida o extrema, cuya
particularidad es tener como parte del
equipo al usuario final pues uno de los
requisitos para llegar al éxito del
proyecto
• Mantenimiento
• Muerte del proyecto
• Desarrollo de un modelo general.
• Construcción
• Plan de raleases e
• Diseñar
• Implementar
FDD establece algunas medidas útiles
que son muy importantes para la
dirección de la empresa y muestran el
estado actual del desarrollo y realizar,
en el futuro, mejores estimaciones.
TIEMPO DE
EJECUCIÓN
MANTENIMIENTO
6 meses
El
mantenimiento
inmediato.
es
3 meses
El
mantenimiento
inmediato.
es
El
mantenimiento
inmediato.
es
Tiempo de desarrollo
corto, es decir, menos
de un año.
• Análisis
• Diseño
• Codificación
• Pruebas e integración
• Operación y Mantenimiento
Conjunto de fases por las que pasa el
sistema que se está desarrollando
desde que nace la idea inicial hasta que
el software es retirado o reemplazado
(“muere”).
Mediano Plazo
El
mantenimiento
inmediato.
es
•Análisis
• Diseño
• Implementación y pruebas
• Integración y pruebas
• Funcionamiento y Mantenimiento
Ssecuencia de actividades, donde la
estrategia principal es seguir el progreso
del software hacia puntos de revisión
bien definidos mediante entregas
calendarizadas.
Mediano Plazo
El
mantenimiento
inmediato.
es
24
Como metodología de desarrollo se escogió el modelo en Cascada porque permite hacer
modificaciones en el diseño lo cual significa que se harán cambios en la codificación y se
tendrán que realizar de nuevo las pruebas. En esta metodología el tiempo de ejecución se
lleva a cabo en mediano plazo lo cual es una ventaja para el desarrollo del proyecto.
4.1.2. Servidor de Aplicaciones. En la fase de implementación el aplicativo se
desarrollará por medio de un servidor de aplicaciones especificado anteriormente, éste
por lo general proporciona aplicaciones a los equipos clientes a través de internet
utilizando el protocolo http (Hypertext Transfer Protocol). Según Jorge Luis Ricco “Un
servidor de aplicación maneja la mayoría de las transacciones relacionadas con la lógica y
el acceso a los datos de la aplicación.
Los servidores de aplicaciones proporcionan las siguientes ventajas:
Integridad de datos y códigos: al estar centralizada en una o un pequeño número de
máquinas servidoras, las actualizaciones están garantizadas para todos sus usuarios.
Configuración centralizada: los cambios en la configuración de la aplicación, como
mover el servidor de base de datos o la configuración del sistema.
Seguridad: se consideran más seguras.
Performance: limitado el tráfico de la red solamente al tráfico de la capa de presentación,
es percibido como un modelo cliente/servidor que mejora performance de grandes
aplicaciones”.7
7
¿Qué es un servidor de aplicaciones?, [artículo en línea] Disponible desde Internet en: <
http://updateycommit.blogspot.com/2010/08/diferencia-de-servidor-de-aplicaciones.html>, Marzo 21 de 2010. 9:30am.
25
Tabla 3. Servidor de Aplicaciones.
SERVIDOR DE APLICACIONES
CARÁCTERÍSTICAS

WEBLOGIC


EAServer


GLASSFISH
TOMCAT
Puede utilizar Oracle, DB2, Microsoft SQL Server,
y otras bases de datos que se ajusten al estándar
JDBC. El servidor WebLogic es compatible con
WS-Security y cumple con los estándares de J2EE
1.3 desde su versión 7 y con la J2EE 1.4 desde su
versión 9 y Java EE para las versiones 9.2 y 10.x
Un motor de ejecución escalable e independiente
de la plataforma.
Soporte de "stubs" y "proxys" para los principales
modelos de componentes, incluyendo JavaBeans,
PowerBuilder, Java, ActiveX, y C/C++
Soporte a HTML dinámico usando Servlets Java y
Java Server Pages(JSP)
Soporte a la plataforma de desarrollo Java 2
Enterprise Edition (J2EE).

Modularidad.

Tiempo mejorado de inicio.

Despliegues desde plugins en NetBeans y Eclipse,
y preservación de sesiones a través de
redespliegues.


Implementado de Servlet 3.0 JSP 2.2 y EL 2.2
Mejoras para detectar y prevenir "fugas de
memoria" en las aplicaciones web
Limpieza interna de código
Soporte para la inclusión de contenidos externos
directamente en una aplicación web.


DEFINICIÓN
Servidor de aplicaciones Java EE y también un servidor web HTTP.
Servidor de aplicaciones, el cual incluye un conjunto integrado de herramientas
que se usan para crear y ejecutar aplicaciones Web con soporte a altos niveles
de tráfico, contenido dinámico y procesamiento intensivo de transacciones en
línea.
Servidor de aplicaciones desarrollado por Oracle Corporation que implementa las
tecnologías definidas en la plataforma Java EE y permite ejecutar aplicaciones
que siguen esta especificación.
Servidor web con soporte de servlets y JSPs. Tomcat incluye el compilador
Jasper, que compila JSPs convirtiéndolas en servlets.
26
En la tabla 3 se encuentran algunos servidores de aplicaciones existentes haciendo una
comparación entre las características que poseen para determinar el que más se ajuste a
las necesidades de la aplicación. Por consiguiente, se escogió Apache Tomcat 6.0 porque
incluye un servidor web que abarca todas las funcionalidades de los JSP’s y además es la
herramienta sobre la cual se tiene más conocimiento.
4.1.3. Base de Datos. Para el almacenamiento de datos, la plataforma requiere una base
de datos que sea accesible a través de JDBC (Java Database Connectivity). Esto se hace
a través desde los componentes web y los componentes de la aplicación cliente.
Uno de los beneficios de las Bases de datos es que el servidor puede manejar
transacciones, la seguridad, escalabilidad, concurrencia.
En la tabla 4 se mencionan los diferentes motores de bases de datos que se encuentran
hoy en día, que pueden servir para almacenar la información necesaria y que permiten las
realizar las actividades señaladas anteriormente.
Se seleccionó MySql porque es un sistema de gestión de bases de datos relacional. Su
diseño permite soportar una gran carga de forma muy eficiente.
Como lo afirma Daniel Pecos, “MySql es el gestor de bases de datos más usado en el
mundo del software libre, debido a su gran rapidez y facilidad de uso. Ésta contiene
infinidad de librerías y otras herramientas que permiten su uso a través de gran cantidad
de lenguajes de programación, además de su fácil instalación y configuración”.8
8
MySql, [artículo en línea] Disponible desde Internet en: <http://danielpecos.com/docs/mysql_postgres/x57.html>, Marzo
25 de 2010. 6:10pm.
27
Tabla 4. Motor de Base de Datos.
MOTOR DE BASE DE DATOS
MODELOS
DE DATOS
CARACTERISTICAS
Relacional




ORACLE
Relacional
SQL SERVER


Relacional
POSTGRES


Relacional


MYSQL


HERRAMIENTAS
SEGURIDAD
Soporte de
transacciones.
Estabilidad.
Escalabilidad.
Multiplataforma.




Patrón de consulta
Agrupamiento de datos
Subconsultas
Índices

Flexibilidad y
potencia de los
sistemas
relacionales.
Lenguaje de alto
nivel y no de
procedimiento.


Configuración de cliente
Monitor
de
funcionamiento
Sql Server Profiler
Analizador de Queries

Aproxima los datos a
un modelo objetorelacional, y es
capaz de manejar
complejas rutinas y
reglas.
Soporta integridad
referencial, la cual
es utilizada para
garantizar la validez
de los datos de la
base de datos.

PgAdmin3 : entorno de
escritorio Visual
PgAccess : entorno de
escritorio Visual
PhpPgAdmin : entorno
Web
psql : cliente de consola

Aprovecha la
potencia de
sistemas
multiprocesador.
Soporta gran
cantidad de tipos de
datos para
columnas.
Gestión de usuarios
y passwords.
Gran portabilidad
entre sistemas.


TurboDbAdmin
EMS SQL Manager for
MySQL
MySQL GUI Tools
phpMyAdmin
Instant SQL Formatter
DB Designer 4
WWW SQL Designer


















Seguridad de cuentas para la validación de
usuarios.
Seguridad en el acceso a los objetos de la
base de datos.
Seguridad a nivel de sistema para la
gestión de privilegios globales.
Un único ID de login tanto para red como
para la DB para mejorar la seguridad y
facilitar la administración.
Password y encriptación de datos en red
para mejorar la seguridad.
Encriptación
de
procedimientos
almacenados para la integridad y
seguridad de código de aplicación.
Protección de los ficheros de la base de
datos.
Las conexiones de los clientes al servidor
de la base de datos están permitidas, por
defecto.
Las conexiones de los clientes se pueden
restringir por dirección IP y/o por nombre
de
usuario
mediante
el
fichero
pg_hba.conf situado en PG_DATA.
MySQL Network Scanner: Este programa
permite auditar una red de clase C en
busca de servidores MySQL que no
tengan definida una contraseña para el
usuario root.
MySQL Brute Force Password Hash
Cracker: Esta utilidad, complementaria a la
anterior, admite como argumento el hash
de una contraseña de un usuario de
MySQL y, mediante fuerza bruta, intentará
descifrarlo.
28
4.1.4. Plataforma J2EE. Como lo afirma Felipe Aguilera, J2EE “Es una plataforma creada
por Sun y basada en Java, para el desarrollo de aplicaciones empresariales distribuidas.
J2EE se basa en una arquitectura multicapa para el desarrollo de sistemas”9.
Así mismo, Juan Manuel Barrios dice que dicha arquitectura “se basa en los conceptos de
capas, containers, componentes, servicios y las características de cada uno de éstos. Las
aplicaciones J2EE son divididas en cuatro capas: la capa cliente, la capa web, la capa
negocio y la capa datos. La figura 2 representa estas capas y sus componentes.
Capa Cliente
Esta capa corresponde a lo que se encuentra en el computador del cliente. Es la interfaz
gráfica del sistema y se encarga de interactuar con el usuario. J2EE tiene soporte para
diferentes tipos de clientes incluyendo clientes HTML, applets Java y aplicaciones Java.
Capa Web
Se encuentra en el servidor web y contiene la lógica de presentación que se utiliza para
generar una respuesta al cliente. Recibe los datos del usuario desde la capa cliente y
basado en éstos genera una respuesta apropiada a la solicitud. J2EE utiliza en esta capa
las componentes Java Servlets y JavaServer Pages para crear los datos que se enviarán
al cliente.
9
Análisis y diseño orientado a objetos Patrones de diseño, [artículo en línea] Disponible desde Internet en:
<http://www.dcc.uchile.cl/~luguerre/cc40b/clase13.html>, Abril 02 de 2010. 5:10pm.
29
Figura 2. Arquitectura J2EE.
Autor: Juan Manuel Barrios. Investigación de la plataforma J2EE
Capa Negocio
Se encuentra en el servidor de aplicaciones y contiene el núcleo de la lógica del negocio
de la aplicación. Provee las interfaces necesarias para utilizar el servicio de componentes
del negocio. Las componentes del negocio interactúan con la capa de datos y son
típicamente implementadas como componentes EJB.
Capa Datos
Esta capa es responsable del sistema de información de la empresa o Enterprise
Information System (EIS) que incluye bases de datos, sistema de procesamiento datos,
sistemas”.10
Escenario basado en la Web
Según Johnson Mark, “La plataforma J2EE no obliga a usar en un sistema todas las
capas. Lo esencial es escoger el mecanismo adecuado para el problema. En este sentido,
en ocasiones no hay la complejidad como para requerir una capa EJB. Se denomina
10
Investigación de la plataforma J2EE y su aplicación práctica [artículo en línea] Disponible desde Internet en: <
http://www.dcc.uchile.cl/~jbarrios/J2EE/node14.html>, Octubre 7 de 2010, 4:01 p.m.
30
escenario web-centric porque el contenedor web es el que realiza gran parte del trabajo
del sistema. En este tipo de escenario la capa web implica tanto lógica de presentación
como lógica de negocio”.11 En la figura 3 se representa el escenario basado en la web
descrito anteriormente.
Figura 3. Escenario Basado en la Web.
Autor: Inderjeet Singh,Beth Stearns,Mark Johnson; Designing Enterprise applications with the J2EE
platform.
4.1.5. JavaBean. “Un JavaBean o bean es un componente hecho en software que se
puede reutilizar y que puede ser manipulado visualmente por una herramienta de
programación en lenguaje Java”.12
4.1.6. SMS (Short Message Service). “El SMS permite enviar y recibir mensajes, recibir
notificaciones de correo electrónico, correo de voz y fax integrados, recordatorios, avisos
de retraso de vuelos, noticias, agenda de acontecimientos culturales y el precio de una
llamada que se acaba de hacer. Su ventaja reside en la rapidez y bajo coste. También se
pueden enviar mensajes a móviles desde diferentes portales de Internet”.13
11
SINGH Inderjeet, STEARNS Beth, JOHNSON Mark, Designing Enterprise applications with the J2EE platform, Sun
Microsystem 2002, p19.
12
Definición
JavaBean
[artículo
en
línea]
Disponible
desde
Internet
en:
<http://www.sc.ehu.es/sbweb/fisica/cursoJava/applets/javaBeans/fundamento.htm#Definición de JavaBean>, Octubre 5
de 2010, 2:23 p.m.
13
Definición SMS, [artículo en línea] Disponible desde internet en: <http://www.sitiosespana.com/notas/febrero2005/QUE-ES-SMS.htm>, Octubre 5 de 2010, 2:23 p.m.
31
4.1.7. Administración de la Historia Clínica Odontológica. Para llevar a cabo este
proceso es necesario tener en cuenta las directivas internas, características,
componentes, formatos, instructivos, diligenciamiento, uso y manejo de la historia clínica
odontológica
las
cuales
se
encuentran
detalladas
en
el
anexo
A.
A continuación se referencia la Resolución 1995 de 1999 incluida en el anexo C y
establece que: “La Historia Clínica es un documento privado, obligatorio y sometido a
reserva, en el cual se registran cronológicamente las condiciones de salud del paciente,
los actos médicos y los demás procedimientos ejecutados por el equipo de salud que
interviene en su atención. Dicho documento únicamente puede ser conocido por terceros
con previa autorización del paciente o en los casos previstos por la ley”14.
En el anexo A se encuentra un ejemplo de un procedimiento para el uso y manejo de la
historia clínica de un servicio odontológico, en este se mencionan las partes que
componen la historia clínica odontológica, estas se pueden ver representadas en un
formato el cual se encuentra en el anexo B y son:
1. Datos personales: identificación del usuario, apellidos y nombres completos,
estado civil, documento de identidad, fecha de nacimiento, sexo, ocupación,
dirección y teléfono del domicilio y lugar de residencia, nombre y teléfono del
acompañante; nombre, teléfono y parentesco de la persona responsable del
usuario.
2. Antecedentes personales y familiares: enfermedades relevantes que ha sufrido el
paciente o alguno de los integrantes de su familia más cercanos.
3. Examen físico: estomatológico, periodontal, pulpar, tejidos dentarios y oclusión
4. Odontograma: es un elemento básico y fundamental desde el punto de vista clínico
para el establecimiento del diagnóstico, el plan de tratamiento y el seguimiento de
la rehabilitación del paciente.
5. Plan de tratamiento: como su nombre lo indica es el tratamiento odontológico que
se le llevará a cabo al paciente, según lo establezca el odontólogo.
14
Resolución número 1995 de 1999 (julio 8).
32
6. Consentimiento Informado: es la aprobación del paciente a que se le realicen los
procedimientos, dar a conocer los posibles riesgos y complicaciones que se
pueden presentar en el tratamiento.
7. Evolución salud oral: es la parte que indica la fecha, hora, diente y el tratamiento
que se le realizó al paciente.
8. Anexos: son todos aquellos documentos que sirven como sustento legal, técnico,
científico y/o administrativo de las acciones realizadas al usuario en los procesos
de
atención,
tales
como:
autorizaciones
para
intervenciones
quirúrgicas
(consentimiento informado), procedimientos, declaración de retiro voluntario y
demás documentos que las instituciones prestadoras consideren pertinentes.
Las partes de la historia odontológica que corresponden al examen físico y los
anexos fueron tomadas del anexo A.15
4.1.8. Proceso para solicitar una cita odontológica. El paciente solicita la cita
telefónicamente, se le asigna una fecha y hora con el que esté de acuerdo, este proceso
es igual si el paciente asiste por primera vez o si ya es un usuario habitual del consultorio.
Otra opción para solicitar la cita es hacerlo en el consultorio el mismo día de la consulta.
15
Ejemplo para el manejo de una historia clínica odontológica, [artículo en línea] Disponible desde Internet en:
http://www.saludcapital.gov.co/Publicaciones/doc, Agosto 5 de 2010, 4:01 p.m.
33
4.2.
MARCO LEGAL O NORMATIVO
4.2.1. RESOLUCIÓN NÚMERO 1995 DE 1999 (JULIO 8): “por la cual se establecen
normas para el manejo de la historia clínica.
Que la Historia Clínica es un documento de vital importancia para la prestación de los
servicios de atención en salud y para el desarrollo científico y cultural del sector. Que de
conformidad con el Artículo 35 de la Ley 23 de 1981, corresponde al Ministerio de Salud
implantar modelos relacionados con el diligenciamiento de la Historia Clínica en el
Sistema Nacional de Salud.
Que se hace necesario expedir las normas correspondientes al diligenciamiento,
administración, conservación, custodia y confidencialidad de las historias clínicas,
conforme a los parámetros del Ministerio de Salud y del Archivo General de la Nación en
lo concerniente a los aspectos archivísticos contemplados en la Ley 80 de 1989”. Esta ley
se incluye en el anexo C.
34
5. DESARROLLO INGENIERIL
5.1.
METODOLOGÍA DEL PROYECTO
Para alcanzar los objetivos propuestos con el desarrollo del aplicativo web se escogió la
metodología en cascada que servirá para dar respuesta al problema que se ha planteado
y respaldará su información, ejecución y mantenimiento de modo que cuente con la mejor
calidad, basándose en la Ingeniería de software. Actualmente éste es uno de los más
utilizados por su eficacia y simplicidad, además ayuda a minimizar los gastos de la
planificación.
A continuación se desarrollan las fases que componen esta metodología:
5.2.
ANÁLISIS Y DEFINICIÓN DE REQUERIMIENTOS
Para cumplir con la fase de análisis y definición de requerimientos se clasificó la
información que el consultorio odontológico suministró y con base en ésta se ejecutan las
siguientes actividades: levantamiento de información, requerimientos funcionales y no
funcionales que se comentan en la siguiente sección.
5.2.1. Levantamiento de información. Para llevar a cabo el proceso de levantamiento de
información se seleccionó un consultorio odontológico. En este lugar se le realizó una
entrevista a la odontóloga la cual se refleja en el anexo G. Además se encuestaron a 10
de los pacientes que frecuentan el consultorio y no fue posible realizar más de estas,
puesto que a políticas del lugar no es permitido suministrar información sobre los
pacientes. Para la ejecución de las encuestas se utilizó un formato con 18 preguntas que
fueron realizadas en su totalidad representadas en el anexo D, las cuales permitieron
determinar los requerimientos funcionales y no funcionales del sistema. Se obtiene una
tabulación de los datos como se encuentra en el anexo E, donde los pacientes coinciden
en que se implemente en el consultorio un aplicativo web para administrar las citas e
historias odontológicas. En consecuencia de este proceso se establece su ficha técnica
que se encuentra en el anexo F.
35
 Aporte de los encuestados: La mayoría de los encuestados coincidieron en que para
ellos sería más cómodo, rápido y fácil solicitar o cancelar su próxima cita odontológica por
medio de una página web, ya que en ella se podrá visualizar horarios, fechas y
odontólogos disponibles con su respectiva especialidad. Igualmente todos opinaron en
que les gustaría que se les recordara la fecha y hora de su próxima cita a través de un
mensaje corto de texto en el celular.
Con respecto a la odontóloga, considera que es necesario sistematizar las historias
odontológicas ya que las tendencias tecnológicas van evolucionando y estas permiten
agilizar los procesos que se llevan actualmente en el consultorio. También por medio del
aplicativo web existe la oportunidad para darse a conocer mundialmente y de esta forma
hacer que los visitantes a la página encuentren los servicios que ella ofrece.
5.2.2. Requerimientos funcionales.
“Describen con detalle lo que el sistema debe
hacer, dependen del tipo de software que se desarrolle, de los posibles usuarios del
software y del enfoque general tomado de la organización al redactar requerimientos”16. A
continuación se presentan en detalle dichos requerimientos con los que debe cumplir el
software: Para acceder a los servicios que presta el consultorio, los odontólogos, la
asistente o los pacientes deben autenticarse por medio de la página web ingresando el
usuario y contraseña que los identifica en el sistema. Si es un paciente que no existe debe
registrarse ingresando nombres, apellidos, estado civil, sexo, tipo de documento, número
de documento, fecha de nacimiento, ocupación, dirección, barrio, teléfono, y celular.
Después del registro, el sistema genera el usuario el cual es: “nombre.primerapellido” y la
contraseña que es: ”el día de nacimiento + primer apellido” con los que el paciente debe
autenticarse para poder solicitar una cita, la cual se consigna en la base de datos que el
sistema posee, donde debe señalar el odontólogo, la fecha y la hora, que el paciente
desee, el sistema verifica si el odontólogo está disponible en esa fecha y horario, de ser
así quedará registrada la cita, en caso contrario se mostrarán los horarios disponibles
para esa fecha con ese odontólogo y si desea solicitarla será guardada en el sistema.
El paciente debe cerrar su sesión después de haberse registrado o en el momento que lo
desee. Para recordarle al paciente la hora y fecha de su próxima cita se le enviará un sms
a su celular.
16
SOMMERVILLE, Ian, Ingeniería del Software, Pearson Educación S.A. Madrid 2005, p 110.
36
El día que el paciente acude a la consulta se crea una historia odontológica por medio de
un formato el cual contiene 8 secciones, ellas son:
1. Datos personales
2. Examen básico
3. Antecedentes personales y familiares
4. Odontograma
5. Plan de tratamiento
6. Consentimiento informado
7. Evolución
8. Anexos.
En la sección de datos personales el sistema pedirá los datos básicos del paciente
(nombres, apellidos, dirección, teléfono, celular, género, fecha de nacimiento, ocupación,
estado civil y documento de identidad, nombre, dirección y teléfono de la persona
responsable (en el caso que el paciente sea menor de edad.) los cuales se guardarán en
la base de datos creada para este fin. Seguido de esto se dispone a realizar un examen
básico, antecedentes personales y familiares que le permitirán saber las enfermedades
sufridas y la ingestión de medicamentos del paciente, tratamientos realizados, hábitos de
higiene oral, estado general de los dientes lo cual queda consignado en el odontograma.
Las demás secciones contienen: el plan de tratamiento a realizar y la descripción del
mismo, el consentimiento informado que el paciente o el responsable acepta o no antes
de realizar cualquier procedimiento, la evolución en donde se consigna en secuencia
cronológica el seguimiento de la rehabilitación (fecha, hora, diente, valor y tratamiento) y
por último se encuentra la sección de anexos (placas RX, diseños, fotografías).
En la página web los usuarios encontrarán la información sobre los odontólogos (nombres
apellidos, y estudios realizados), servicios que presta el consultorio, dirección y teléfono
de éste. Para el registro de odontólogos el administrador lo realizará en un formulario
diseñado el cual pedirá los datos básicos como nombres, apellidos, cédula, teléfono,
celular, dirección, entre otros. Esto se guardará en la base de datos del sistema.
37
El sistema contará con las siguientes restricciones:
No puede haber dos pacientes registrados con el mismo número de cédula. El número de
historia clínica debe ser consecutivo generado automáticamente por el sistema y por
ningún motivo debe repetirse y por último los pacientes no pueden acceder a la historia
clínica odontológica desde la página web.
Además, el sistema contará con las siguientes operaciones:
En primera instancia el sistema debe permitir el ingreso, consulta y modificación de la
información básica de los pacientes registrados en el sistema. Igualmente el ingreso,
consulta y modificación de la información básica de los odontólogos registrados en el
sistema, además debe permitir solicitar, consultar y cancelar una cita odontológica para
luego generar los siguientes reportes:

Listado de citas por día.

Listado de citas por mes.

Listado de citas por fecha y odontólogo.

Listado de servicios y odontólogos que los realizan.

Consultar historia clínica del paciente.

Consultar datos básicos de usuario.

Consultar información de la clínica.
5.2.3. Requerimientos no funcionales. “Son aquellos requerimientos que no se refieren
directamente a las funciones específicas que proporciona el sistema, sino a las
propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad
de almacenamiento”17. A continuación se encuentra el listado de requerimientos no
funcionales identificados como sigue:
 Para utilizar la aplicación web se requiere una conexión a internet.
 La disponibilidad del aplicativo depende de los servicios que ofrezca el
hosting empleado.
17
SOMMERVILLE, Ian, Ingeniería del Software, Pearson Educación S.A. Madrid 2005, p 111.
38
 El equipo desde donde se acceda a la aplicación debe tener instalado un
navegador de internet. (Internet Explorer Versión 7 en adelante, Mozilla
Firefox Versión 3.0 en adelante, Opera Versión 8.5 en adelante).
 Conocimientos básicos sobre sistemas informáticos de las personas que
interactúan con el sistema.
5.3. DISEÑO DEL SISTEMA Y DE SOFTWARE
5.3.1. Diseño del sistema. El diseño del sistema se realizará con los conceptos de UML
(Unified Modeling Language) adquiridos en ingeniería de software, por medio de los casos
de uso. Estos casos representan una interacción típica entre el usuario y el sistema
informático, los cuales permiten establecer la funcionalidad propia del sistema. A
continuación se definen los actores y los casos de usos.
5.3.1.1. Actores. En el desarrollo de la Implementación del aplicativo web se encuentran
los siguientes actores autorizados para interactuar con el sistema y la aplicacion Dentistry
Web:

Administrador: es la persona que cuenta con todos los privilegios para gestionar
todos los módulos con los cuales cuenta el sistema (gestionar historia
odontológica, información de pacientes, odontólogos y asistente, y solicitar,
consultar o cancelar citas).

Odontólogo: es el usuario encargado de prestar el servicio odontológico a los
pacientes del consultorio y cuenta con los privilegios de gestionar la historia
odontológica, su propia información y la de los pacientes, además generar algunos
reportes, solicitar, consultar o cancelar citas.

Asistente: es la persona que se encarga de apoyar y asistir los procedimientos
que realiza el odontólogo a sus pacientes. En el aplicativo cuenta con los
privilegios de solicitar, consultar o cancelar citas. Al mismo tiempo se encarga de
enviar los sms para recordar a los pacientes su próxima cita en caso de que el
39
consultorio desee implementar el servicio de mensajería. Por último puede
actualizar sus propios datos.

Paciente: es el usuario al que el consultorio presta sus servicios. En el sistema
puede realizar las siguientes acciones: gestionar su propia información personal,
solicitar, consultar o cancelar citas.
5.3.1.2. Diagramas de casos de uso. Para el desarrollo del sistema Dentistry web se
elaboraron los siguientes diagramas de casos de uso como lo muestran las figuras 4, 5, 6,
7 y 8.
Figura 4. Diagrama de Caso de Uso Principal
40
Tabla 5. Descripción Caso de Uso Registrar Usuario.
Caso de uso
Registrar Usuario
Objetivo
Permitir a un usuario registrarse en el sistema.
Actores
Administrador, Odontólogo, Asistente y Paciente.
1. Se presenta al usuario una pantalla principal en donde
se encuentra un link para cada perfil.
Curso normal de eventos
2. Si el usuario es un paciente y no se encuentra
registrado, encontrará un link para hacer el debido
registro.
3. Si la actividad seleccionada es registrarse el sistema
pide los siguientes datos: primer apellido, segundo
apellido, nombres, estado civil, sexo, tipo documento,
número de documento, fecha de nacimiento,
ocupación, dirección, barrio, teléfono y celular.
4. Automáticamente el sistema genera un usuario y
contraseña después del registro.
5. El Administrador es el único que puede registrar a un
odontólogo o asistente y para este fin realiza el evento
3.
Flujo alternativo de eventos
Se debe hacer una validación de los campos registrados.
Precondición
Es obligatorio diligenciar todos los campos con la información
requerida.
Pos condiciones
Usuarios registrados en el sistema.
Tabla 6. Descripción Caso de Uso Autenticar Usuario.
Caso de uso
Autenticar Usuario
Objetivo
Validar usuario y contraseña de los usuarios del sistema.
Actores
Administrador, Odontólogo, Asistente y Paciente.
1. El usuario ingresa su usuario y contraseña
41
Curso normal de eventos
insertados por pantalla.
2. Una vez autenticado el usuario puede acceder a
los servicios a los cuales tiene permiso.
Precondiciones
Existe el registro de usuario.
Flujo alternativo de eventos
Si los datos ingresados no corresponden al usuario se muestra
un mensaje en pantalla que los datos no son correctos y debe
escribirlos nuevamente.
Pos condiciones
Usuarios autenticados en el sistema.
Tabla 7. Descripción Caso de Uso Gestionar Historia Clínica.
Caso de uso
Gestionar Historia Clínica
Objetivo
Ofrecer a los usuarios permitidos las opciones de crear,
actualizar y guardar la historia clínica de los pacientes.
Actores
Administrador y Odontólogo
1. Se presenta al usuario una pantalla en donde
encuentra un link llamado paciente.
Curso normal de eventos
2. El usuario ingresa la identificación del paciente. Si el
paciente se encuentra registrado puede consultar o
crear la historia en donde deberá llenar las secciones
con las cuales esta cuenta y vuelve a la página
principal.
3. Después de crear la historia aparecen todas las
secciones en pantalla pero la única que puede
modificar es la evolución de la salud oral. Después de
haber realizado la actualización se guardan los
cambios.
4. Si la actividad seleccionada es cerrar sesión y volverá
a la página principal.
Precondiciones
El Administrador u Odontólogo deben haber ejecutado el caso
de uso autenticar usuario.
Para actualizar se debe haber ejecutado el caso de uso crear
42
historia.
Flujo alternativo de eventos
Si el número de documento del paciente no se encuentra en la
base de datos se debe hacer el registro.
Pos condiciones
Historia Clínica modificada.
Tabla 8. Descripción Caso de Uso Gestionar Cita.
Caso de uso
Gestionar Cita
Objetivo
Ofrecer a los usuarios permitidos las opciones de solicitar,
consultar o cancelar una cita.
Actores
Administrador, Odontólogo, Asistente y Paciente.
Curso normal de eventos
1. Se presenta al usuario una pantalla y puede solicitar,
consultar o cancelar.
2. Si el usuario escoge solicitar cita aparece una lista de
odontólogos en donde puede escoger el que desee y
un botón que muestra la lista semanal de horarios con
la fecha y hora disponibles. Este registro se guarda en
la base de datos.
3. Cuando pide la cita aparecen en pantalla los datos de
esta.
4. Si el usuario desea consultar una cita, debe haber sido
creada y muestra los datos de esta, si la cita no ha
sido creada aparece un mensaje informando el estado
de la cita.
5. Si escoge cancelar la cita que ya existe se borrará la
cita creada y vuelve a quedar disponible el horario que
había escogido.
6. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
Precondiciones
El Administrador, Odontólogo, Asistente y Paciente deben
haber ejecutado el caso de uso autenticar usuario.
Para cancelar una cita ya debe haber sido solicitada.
43
Flujo alternativo de eventos
Ninguno.
Pos condiciones
Cita Modificada.
Tabla 9. Descripción Caso de Uso Gestionar Datos Básicos de Usuarios.
Caso de uso
Gestionar Datos Básicos de Usuarios
Objetivo
Permitir a todos los usuarios del sistema actualizar sus
respectivos datos básicos.
Actores
Administrador, Odontólogo, Asistente y Paciente.
Curso normal de eventos
1. Se presenta al usuario una pantalla en donde puede
escoger la opción de actualizar los datos.
2. Si el usuario escoge actualizar solo puede cambiar los
siguientes datos: ocupación, dirección, teléfono,
celular y contraseña. Para cada uno aparece un link
para editar.
3. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
Precondiciones
Todos los usuarios deben haber ejecutado los casos de uso
registrar y autenticar usuario.
Flujo alternativo de eventos
Si en el momento de editar un campo el usuario no escoge la
opción actualizar el campo no tendrá ningún cambio.
Pos condiciones
Información de usuarios actualizada.
Tabla 10. Descripción Caso de Uso Generar Reportes.
Caso de uso
Generar Reportes
Objetivo
Consultar en la base de datos la información que el usuario
desee.
Actores
Administrador, Odontólogo.
1. Se presenta una opción en donde se encuentra el
44
listado de reportes disponibles para los usuarios.
2. El usuario ingresa fecha y/o cédula y el sistema
verifica si esta es válida.
Curso normal de eventos
3. El sistema muestra en pantalla todos los registros
encontrados.
4. Si la actividad seleccionada es regresar volverá a la
sesión iniciada por el odontólogo.
Precondiciones
El Administrador u Odontólogo deben haber ejecutado el caso
de uso autenticar usuario.
Flujo alternativo de eventos
Si los datos de ingreso no son válidos el sistema no muestra
ningún reporte.
Pos condiciones
Visualización del reporte.
Tabla 11. Descripción Caso de Uso Cerrar Sesión.
Caso de uso
Cerrar Sesión
Objetivo
Dar por terminada las actividades que el usuario está
realizando en el sistema.
Actores
Administrador, Odontólogo, Asistente y Paciente.
1. Se muestra en pantalla un botón cerrar sesión.
Curso normal de eventos
2. El usuario vuelve a la página principal. Si desea
ingresar nuevamente debe autenticarse.
Precondiciones
Los usuarios deben haber ejecutado el caso de uso autenticar
usuario.
Flujo alternativo de eventos
Ninguno.
Pos condiciones
Salir del sistema y volver a la pantalla principal.
45
Figura 5. Diagrama Caso de Uso Administrador.
46
Figura 6. Diagrama Caso de Uso Odontólogo.
Tabla 12. Descripción Caso de Uso Solicitar Cita.
Caso de uso
Solicitar Cita
Objetivo
Ofrecer al usuario la opción de solicitar una cita.
Actores
Administrador, Odontólogo, Asistente, Paciente.
1. Se presenta al usuario una opción para solicitar la cita.
Curso normal de eventos
2. El usuario debe escoger la fecha, la hora y el
odontólogo disponible para asignar la cita; y se
guardan los cambios en la base de datos.
3. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
47
Precondiciones
El usuario debe haber ejecutado el caso de uso autenticar
usuario.
Flujo alternativo de eventos
Si el usuario no escoge la fecha, hora y odontólogo la cita no
se puede solicitar.
Pos condiciones
Cita creada.
Tabla 13. Descripción Caso de Uso Consultar Cita.
Caso de uso
Consultar Cita
Objetivo
Ofrecer al usuario la opción de consultar una cita.
Actores
Administrador, Odontólogo, Asistente, Paciente.
Curso normal de eventos
Precondiciones
1. Al escoger la opción de consultar cita aparece los
datos de la cita solicitada anteriormente.
2. Si la actividad seleccionada es salir volverá a la página
principal.
El usuario debe haber ejecutado el caso de uso autenticar
usuario.
Se debe haber ejecutado el caso de uso solicitar cita.
Flujo alternativo de eventos
Ninguno.
Pos condiciones
Cita modificada.
Tabla 14. Descripción Caso de Uso Cancelar Cita.
Caso de uso
Cancelar Cita
Objetivo
Ofrecer al usuario la opción de cancelar una cita.
Actores
Administrador, Odontólogo, Asistente, Paciente.
1. Se presenta al usuario una opción para cancelar una
cita.
2. Si el usuario lo desea puede crear la cita nuevamente
48
Curso normal de eventos
en el horario y fecha que el paciente lo desee.
3. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
Precondiciones
El usuario debe haber ejecutado el caso de uso autenticar
usuario.
Se debe haber ejecutado el caso de uso solicitar cita.
Flujo alternativo de eventos
Si el usuario desea cancelar la cita aparecerá un mensaje
preguntando si está seguro de hacerlo.
Pos condiciones
Cita modificada.
Tabla 15. Descripción Caso de Uso Crear Historia Clínica.
Caso de uso
Crear Historia Clínica
Objetivo
Ofrecer al usuario la opción de crear la historia clínica de los
pacientes.
Actores
Administrador, Odontólogo.
1. Se presenta al usuario en la pantalla la opción primer
historia.
Curso normal de eventos
2. El usuario debe llenar todas las secciones con las
cuales cuenta la historia clínica y se guardan los
cambios en la base de datos.
3. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
Precondiciones
El usuario debe haber ejecutado el caso de uso autenticar
usuario.
Flujo alternativo de eventos
Ninguno.
Pos condiciones
Historia Clínica creada.
49
Tabla 16. Descripción Caso de Uso Actualizar Historia Clínica.
Caso de uso
Actualizar Historia Clínica
Objetivo
Ofrecer al usuario la opción de actualizar la historia clínica de
los pacientes.
Actores
Administrador, Odontólogo.
Curso normal de eventos
1. El usuario puede actualizar únicamente la evolución
salud oral de la historia clínica del paciente las veces
que sea necesario.
2. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
Precondiciones
El usuario debe haber ejecutado el caso de uso autenticar
usuario.
Se debe haber ejecutado el caso de uso crear historia clínica.
Flujo alternativo de eventos
Ninguno.
Pos condiciones
Historia Clínica actualizada.
Tabla 17. Descripción Caso de Uso Consultar Historia Clínica.
Caso de uso
Consultar Historia
Objetivo
Ofrecer al usuario la opción de consultar la historia clínica de
los pacientes.
Actores
Administrador, Odontólogo.
1. Se presenta al usuario una opción para consultar la
historia clínica.
Curso normal de eventos
2. El usuario debe ingresar la cédula para que el sistema
busque la historia clínica que corresponde.
3. Se muestra en pantalla la historia clínica del paciente,
el usuario puede seleccionar la sección de la historia
50
que desee visualizar.
4. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
Precondiciones
El usuario debe haber ejecutado el caso de uso autenticar
usuario.
Se debe haber ejecutado el caso de uso crear historia clínica.
Flujo alternativo de eventos
En el momento de hacer la consulta la cédula del paciente
debe ser válida.
Pos condiciones
Visualización de la historia clínica.
Tabla 18. Descripción Caso de Uso Actualizar Datos de Usuarios.
Caso de uso
Actualizar Datos de Usuarios
Objetivo
Permitir al usuario del sistema actualizar y consultar.
Actores
Administrador, Odontólogo, Asistente, Paciente.
1. Se presenta al usuario una pantalla en donde puede
actualizar y consultar sus datos básicos.
2. Si el usuario escoge actualizar solo puede cambiar los
siguientes datos: ocupación, dirección, teléfono,
celular y contraseña. Para cada uno aparece un link
para editar.
Curso normal de eventos
3. El sistema muestra en pantalla los datos actualizados.
4. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
Precondiciones
El usuario debe haber ejecutado los casos de uso registrar y
autenticar usuario.
Flujo alternativo de eventos
Si en el momento de editar un campo el usuario no escoge la
opción actualizar el campo no tendrá ningún cambio.
Pos condiciones
Información de usuario actualizada.
51
La tabla 6 describe el caso de uso de autenticación de los usuarios administrador y
odontólogo.
Figura 7. Diagrama Caso de Uso Asistente.
Tabla 19. Descripción Caso de Uso Enviar Sms.
Caso de uso
Enviar Sms
Objetivo
Ofrecer al asistente la opción de enviar a los pacientes un sms.
Actores
Asistente.
Curso normal de eventos
1. Se presenta al asistente una opción para enviar sms.
2. El asistente debe ingresar la cédula del paciente para
que el sistema lo busque en la base de datos y así
obtener el celular al cual se envía el sms para recordar
la fecha y hora de la próxima cita.
52
3. Si la actividad seleccionada es cerrar sesión volverá a
la página principal.
Precondiciones
El Asistente debe haber ejecutado el caso de uso autenticar
usuario.
Se debe haber ejecutado el caso de uso crear cita.
Flujo alternativo de eventos
Si la asistente no escoge la opción de enviar el mensaje no
llegará al celular del paciente.
Pos condiciones
Cita modificada.
Las tablas 6, 11, 12, 13, 14 y 18 describen los demás casos de uso que la asistente
realiza que corresponden a Autenticar Usuario, Cerrar Sesión, Solicitar Cita, Consultar
Cita, Cancelar Cita y Actualizar Datos.
Figura 8. Diagrama Caso de Uso Paciente.
53
La descripción de los casos de uso del paciente ya se encuentra en las tablas 5, 6, 11, 12,
13, 14 y 18; que corresponden a Registrar Usuario, Autenticar Usuario, Cerrar Sesión,
Solicitar Cita, Consultar Cita, Cancelar Cita y Actualizar Datos.
5.3.2.
Diseño del software. Para cumplir con la fase de diseño del software se tomaron
los requerimientos funcionales establecidos en la fase de análisis para elaborar el
diagrama de clases, los diagramas de secuencia con su respectiva descripción, los
diagramas de actividades y el modelo de la base de datos con su diccionario el cual
define las tablas que la describen.
5.3.2.1. Diagrama de Clases. “Muestra la estructura estática de las clases en un dominio;
se muestran las clases y las relaciones entre éstas, que pueden ser de herencia,
asociación, agregación ó uso”.18
Figura 9. Diagrama de Clases Dentistry Web.
18
FALGUERAS Campderrich, Benet, Ingeniería del Software, Editorial UOC. Barcelona 2003, p 38.
54
La figura 9 representa el diagrama de clases que se usan en el aplicativo, cada una con
los atributos, operaciones y relaciones que las componen. Serán implementadas para el
buen funcionamiento del sistema y cumplirán con cada uno de los requisitos establecidos
para este fin. La clase principal es Historia Clínica ya que sin ella el objetivo principal del
aplicativo no se cumpliría. Para mayor facilidad a la hora registrar y consultar la Historia
se dividió en sub clases en las cuales se guarda toda la información que se está
sistematizando y va permitir administrar de una manera sencilla la información de los
pacientes.
5.3.2.2. Diagramas de secuencia. “Describe las interacciones entre un grupo de objetos
mostrando de forma secuencial los envíos de mensajes entre objetos”.19
En la figura 10 se muestra como el usuario (Administrador, odontólogo, paciente y
asistente) debe ingresar los todos los datos básicos solicitados en el formulario de registro
en la interfaz que se ha creado para el esto, se validan los datos y se guardan en la base
de datos. Si estos están completos se muestra al usuario por medio de la interfaz que ha
sido registrado, y si por el contrario no llena todos los campos, no puede continuar con
otra actividad que desee, debe llenarlos para terminar el registro.
19
DEBRAUER, Lauren y VAN DER HEIDE, Fien UML2, Ediciones ENI. Barcelona 2009, p 59.
55
Figura 10. Diagrama de Secuencia Registrar Usuario.
La figura 11 representa como el odontólogo debe ingresar su usuario y contraseña en la
interfaz que se ha creado para autenticarse, luego ingresa la cédula del paciente para
verificar si está en la base de datos, si éste no se encuentra debe registrarlo. Después
puede proceder a crear la historia clínica de un paciente por medio de la interfaz que se
realizó para ingresar los datos que la componen. Se guarda la historia en la base de datos
y vuelve a la página principal.
56
Figura 11. Diagrama de Secuencia Crear Historia Clínica.
Para solicitar una cita como se muestra en la figura 12, el usuario (odontólogo, asistente o
paciente) debe autenticarse con usuario y contraseña por medio de la interfaz de
autenticación, luego ingresa los datos requeridos para crear una cita odontológica lo cual
también hace por medio de una interfaz que se ha diseñado, se verifican los horarios y
odontólogos disponibles. Se envía un mensaje confirmando que se ha creado la cita
mostrando en pantalla el día, la hora y el odontólogo. Por último se vuelve al menú
principal.
57
Figura 12. Diagrama de Secuencia Solicitar Cita.
En la figura 13 se describe como el usuario (asistente) se debe autenticar con usuario y
contraseña por medio de la interfaz, a continuación consulta las citas asignadas, crea el
SMS con la fecha y hora de la próxima cita, lo envía al celular del paciente. Este mensaje
se guarda en la base de datos, se confirma que el estado del mensaje ha sido enviado
con éxito y por ultimo vuelve al menú principal. Los mensajes cortos de texto no se hacen
de forma automática, la asistente debe consultar los pacientes programados para el día
siguiente y enviarlos a los respectivos celulares de los pacientes.
58
Figura 13. Diagrama de Secuencia Enviar SMS.
El usuario debe autenticarse con usuario y contraseña por medio de la interfaz de
autenticación como lo muestra la figura 14, luego ingresa los datos que va a actualizar, se
guardan los nuevos datos en la base de datos. Por último se muestra en pantalla los
datos han sido actualizados y se vuelve al menú principal.
Figura 14. Diagrama de Secuencia Actualizar Datos.
59
5.3.2.3. Diagrama de Actividades. “Un diagrama de actividades muestra un flujo de
acciones, generalmente secuenciales. Es decir, hay un punto inicial y luego se muestran
las diferentes actividades que se realizan, una tras otra hasta llegar a un punto final. Estos
diagramas son utilizados principalmente para representar procesos del negocio y flujos de
trabajo en un sistema. El diagrama de actividades es un diagrama dinámico, que puede
verse como un diagrama de flujo que muestran los eventos y las decisiones que se toman
al realizar un proceso”.20
El diagrama de actividades del odontólogo y administrador que se encuentra en la figura
15, describe como el usuario debe autenticarse ingresando el usuario y la contraseña, el
sistema valida los datos ingresados si el usuario se encuentra en la base de datos puede
crear la historia clínica, crear una cita, consultar la historia y se guardan los cambios en la
base de datos. Si el usuario no se encuentra en la base de datos se procede a registrar y
puede realizar las actividades dichas anteriormente.
20
Definición
Diagrama
de
Actividades,
[artículo
en
línea]
Disponible
desde
Internet
en:
<http://www.scribd.com/doc/13735556/ADOO-Diagramas-de-Actividades>, Septiembre 23 de 2010, 8:20 p.m.
60
Figura 15. Diagrama de Actividades Odontólogo y Administrador.
61
Figura 16. Diagrama de Actividades Asistente y Paciente.
El diagrama de actividades para la asistente y el paciente que se encuentra en la figura
16, representa la forma en la que el usuario debe autenticarse, el sistema valida los datos
ingresados, si el usuario se encuentra en la base de datos puede crear una cita y enviar el
SMS si el usuario es el asistente. Guarda la cita, después envía el sms y guarda el sms.
Si el usuario no se encuentra en la base de datos se procede a registrarse y puede
realizar las actividades dichas anteriormente. Para el caso en el que el usuario es el
paciente solo puede crear la cita.
62
5.3.2.4. Base de datos. Según el autor Miguel A. Rodríguez una base de datos es “un
conjunto de datos almacenados de forma integrada y compartida. Se entiende por
integrada que la base de datos puede considerarse como un conjunto de varios archivos
independientes, donde se elimina o se reduce al mínimo cualquier redundancia entre los
mismos.”21
En la figura 17 se encuentra el modelo que representa la base de datos en el sistema
cuenta con las siguientes tablas y sus atributos:















Persona
Asistente
Odontólogo
Acudiente
Estudio
Historia clínica
Plan de tratamiento
Examen básico
Diente
Evolución
Anexos
Citas
Servicios
Servicios por odontólogo
Sms
La descripción detallada de cada una de las anteriores se encuentra en el diccionario de
datos que corresponde a las tablas 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33 y
34. Asimismo los actores del sistema cuentan con una serie de privilegios en la base de
datos los cuales se describen en las tablas 35, 36, 37 y 38.
21
RODRIGUEZ ALMEIDA, Miguel Ángel, Bases de Datos. México Mc. Graw Hill. P257.
63
5.3.2.4.1. Modelo de la base de Datos
Figura 17. Modelo Base de Datos Dentistry Web.
64
5.3.2.4.2. Diccionario de datos.
Tabla 20. Paciente.
NOMBRE DE LA TABLA: PACIENTE
Descripción: En esta tabla se almacenan los datos básicos de todos los usuarios.
Campos
Numero_documento
Llave Primaria
X
Llave Foránea
Tipo de dato
Longitud
Double
Not Null
X
Tipo_documento
Varchar
3
X
Nombre
Varchar
30
X
Apellidos
Varchar
30
X
Telefono
Double
X
Celular
Double
X
Direccion
Varchar
40
X
Genero
Char
1
X
Fecha_de_nacimiento
Date
X
Cargo
Varchar
40
X
Login
Varchar
15
X
Varchar
15
X
Password
DESCRIPCIÓN DE LOS CAMPOS
Numero_documento: Es la llave primaria de la tabla PACIENTE que se encarga de enlazar esta tabla con las demás.
Tipo_documento: Este campo se refiere a tipo de identificación del paciente.
Nombre: En este campo se almacenan los nombres de los pacientes del sistema.
Apellidos: En este campo se almacenan los apellidos de los pacientes del sistema.
Teléfono: En este campo se almacena el número de teléfono fijo de los pacientes del sistema.
Celular: En este campo se almacena el número de celular de los pacientes del sistema.
Direccion: En este campo se almacena la dirección de los pacientes del sistema.
Genero: En este campo se almacena el género (masculino o femenino) de los pacientes del sistema.
Fecha_de_nacimiento: En este campo se almacena la fecha de nacimiento de los pacientes del sistema.
Login: En este campo se almacena el usuario de los pacientes para poder ingresar al sistema.
Password: En este campo se almacena la contraseña de los pacientes para poder ingresar al sistema.
65
Tabla 21. Asistente.
NOMBRE DE LA TABLA: ASISTENTE
Descripción: En esta tabla se almacenan los datos básicos de todos los usuarios.
Campos
Numero_documento
Llave Primaria
X
Llave Foránea
Tipo de dato
Longitud
Double
Not Null
X
Tipo_documento
Varchar
3
X
Nombre
Varchar
30
X
Apellidos
Varchar
30
X
Telefono
Double
X
Celular
Double
X
Direccion
Varchar
40
X
Genero
Char
1
X
Fecha_de_nacimiento
Date
X
Cargo
Varchar
40
X
Login
Varchar
15
X
Varchar
15
X
Password
DESCRIPCIÓN DE LOS CAMPOS
Numero_documento: Es la llave primaria de la tabla ASISTENTE que se encarga de enlazar esta tabla con las demás.
Tipo_documento: Este campo se refiere a tipo de identificación del asistente.
Nombre: En este campo se almacenan los nombres del asistente.
Apellidos: En este campo se almacenan los apellidos del asistente.
Teléfono: En este campo se almacena el número de teléfono fijo del asistente.
Celular: En este campo se almacena el número de celular del asistente.
Direccion: En este campo se almacena la dirección del asistente.
Genero: En este campo se almacena el género (masculino o femenino) del asistente.
Fecha_de_nacimiento: En este campo se almacena la fecha de nacimiento de los pacientes del sistema.
Cargo: en este campo se almacena el cargo de la asistente, puede ser enfermera, secretaria o solo asistente.
Login: En este campo se almacena el usuario del asistente para poder ingresar al sistema.
Password: En este campo se almacena la contraseña del asistente para poder ingresar al sistema.
66
Tabla 22. Odontólogo
NOMBRE DE LA TABLA: ODONTÓLOGO
Descripción: En esta tabla se almacenan los datos básicos de todos los usuarios.
Campos
Numero_documento
Llave Primaria
X
Llave Foránea
Tipo de dato
Longitud
Double
Not Null
X
Tipo_documento
Varchar
3
X
Nombre
Varchar
30
X
Apellidos
Varchar
30
X
Telefono
Double
X
Celular
Double
X
Direccion
Varchar
40
X
Genero
Char
1
X
Fecha_de_nacimiento
Date
X
Tarjeta_profesional
Varchar
20
X
Administrador
Varchar
2
X
Login
Varchar
15
X
Password
Varchar
15
X
DESCRIPCIÓN DE LOS CAMPOS
Numero_documento: Es la llave primaria de la tabla ODONTÓLOGO que se encarga de enlazar esta tabla con las demás.
Tipo_documento: Este campo se refiere a tipo de identificación del odontólogo.
Nombre: En este campo se almacenan los nombres del odontólogo.
Apellidos: En este campo se almacenan los apellidos del odontólogo.
Teléfono: En este campo se almacena el número de teléfono fijo del odontólogo.
Celular: En este campo se almacena el número de celular del odontólogo.
Direccion: En este campo se almacena la dirección del odontólogo.
Genero: En este campo se almacena el género (masculino o femenino) del odontólogo.
Fecha_de_nacimiento: En este campo se almacena la fecha de nacimiento de los odontólogos del sistema.
Tarjeta_profesional: En este campo se almacena el número de tarjeta profesional del odontólogo.
Administrador: Este campo se refiere a si el odontólogo es administrador o no.
Login: En este campo se almacena el usuario del odontólogo para poder ingresar al sistema.
Password: En este campo se almacena la contraseña del odontólogo para poder ingresar al sistema.
67
Tabla 23. Acudiente.
NOMBRE DE LA TABLA: ACUDIENTE
Descripción: En esta tabla se almacenan los títulos o estudios que ha realizado cada odontólogo.
Campos
Numero_documento
Llave Primaria
Llave Foránea
Tipo de dato
X
Longitud
Double
Not Null
X
Tipo_documento
Varchar
3
X
Nombre
Varchar
30
X
Apellidos
Varchar
30
X
Telefono
Double
Direccion
Varchar
X
40
X
DESCRIPCIÓN DE LOS CAMPOS
Numero_documento: Es la llave primaria de la tabla ACUDIENTE que se encarga de enlazar esta tabla con las demás.
Tipo_documento: Este campo se refiere a tipo de identificación del acudiente del paciente.
Nombre: En este campo se almacenan los nombres del acudiente del paciente.
Apellidos: En este campo se almacenan los apellidos del acudiente del paciente.
Teléfono: En este campo se almacena el número de teléfono fijo del acudiente del paciente.
Celular: En este campo se almacena el número de celular del acudiente del paciente.
Direccion: En este campo se almacena la dirección del acudiente del paciente.
68
Tabla 24. Estudio.
NOMBRE DE LA TABLA: ESTUDIO
Descripción: En esta tabla se almacenan los títulos o estudios que ha realizado cada odontólogo.
Campos
Tipo de dato
Longitud
Not Null
Int
2
X
Titulo
Varchar
20
X
Institucion
Varchar
20
X
Id_estudio
Llave Primaria
Llave Foránea
X
Fecha_de_grado
Numero_documento_odontologo
X
Date
X
Double
X
DESCRIPCIÓN DE LOS CAMPOS
Id_estudio: En este campo se almacena el Id del estudio del odontólogo.
Titulo: En este campo se almacena el estudio realizado por el odontólogo.
Institucion: En este campo se almacena la institución en donde el odontólogo realizó un estudio.
Fecha_de_grado: En este campo se almacena la fecha en que se graduó el odontólogo.
Numero_documento_odontólogo: Es la llave primaria de la tabla ODONTÓLOGO. Además es una llave foránea en la tabla ESTUDIO.
69
Tabla 25. Historia_Clínica.
NOMBRE DE LA TABLA: HISTORIA_CLINICA
Descripción: En esta tabla se almacenan la información que debe llevar la historia clínica odontológica.
Campos
Tipo de dato
Longitud
Not Null
Int
10
X
Antecedente_personal
Varchar
40
Antecedente_familiar
Varchar
40
Numero_historia
Llave Primaria
Llave Foránea
X
Fecha_de_actualizacion
Numero_documento_paciente
X
Date
X
Double
X
DESCRIPCIÓN DE LOS CAMPOS
Numero_historia: es la llave primaria de la tabla HISTORIA_CLÍNICA que se encarga de enlazar esta tabla con las demás.
Antecedente_personal: es el campo que almacena los antecedentes personales del paciente.
Antecedente_familiar: es el campo que almacena los antecedentes familiares del paciente.
Fecha_de_actualizacion: este campo almacena la fecha en que se actualiza la historia clínica.
Numero_documento_paciente: es la llave foránea de la tabla PACIENTE.
70
Tabla 26. Plan_de_Tratamiento.
NOMBRE DE LA TABLA: PLAN_DE_TRATAMIENTO
Descripción: En esta tabla se almacenan la información del tratamiento que se le realiza al paciente.
Campos
Numero_tratamiento
Numero_historia
Llave Primaria
Llave Foránea
Tipo de dato
Longitud
Not Null
Int
4
X
X
X
Double
X
Nombre
Varchar
40
X
Descripcion
Varchar
200
X
Estado
Varchar
12
X
Aprobacion
Varchar
2
X
Fecha_inicio
Date
Fecha_fin
Date
Anomalias
Varchar
200
DESCRIPCIÓN DE LOS CAMPOS
Numero_tratamiento: es la llave primaria de la tabla PLAN_DE_TRATAMIENTO que se encarga de enlazar esta tabla con las demás.
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
Nombre: es el campo que almacena el nombre del tratamiento.
Descripción: es el campo que almacena la descripción del tratamiento odontológico al que se someterá el paciente
Estado: este campo almacena los estados del tratamiento (En Desarrollo, Finalización, Sin Realizar, Aplazado).
Aprobación: este campo almacena la aprobación del paciente a que se le haga el respectivo tratamiento odontológico.
Fecha_inicio: este campo almacena la fecha de inicio del tratamiento.
Fecha_fin: este campo almacena la fecha de finalización del tratamiento.
Anomalías: este campo almacena las anomalías.
71
Tabla 27. Examen_Básico.
NOMBRE DE LA TABLA: EXAMEN_BASICO
Descripción: la tabla almacena la información sobre el examen básico que se le realiza al paciente.
Campos
Tipo de dato
Longitud
Not Null
Int
2
X
Nombre
Int
40
Detalle
Varchar
200
Id_examen
Llave Primaria
Llave Foránea
X
Numero_historia
X
Double
X
DESCRIPCIÓN DE LOS CAMPOS
Id_examen: es la llave primaria de la tabla EXAMEN_BASICO que se encarga de enlazar esta tabla con las demás.
Nombre: este campo almacena el nombre del examen que se realizara.
Detalle:
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
Tabla 28. Diente.
NOMBRE DE LA TABLA: DIENTE.
Descripción: la tabla almacena la información sobre los dientes del paciente.
Campos
Tipo de dato
Longitud
Not Null
Int
2
X
Cop
Varchar
8
Manifestacion
Varchar
200
Numero_diente
Numero_historia
Llave Primaria
Llave Foránea
X
X
Double
X
DESCRIPCIÓN DE LOS CAMPOS
Numero_diente: es la llave primaria de la tabla DIENTE que se encarga de enlazar esta tabla con las demás.
Cop: cariado, opturado, perdido.
Manifestación: campo que almacena si es blanda o calcificada.
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
72
Tabla 29. Evolución
NOMBRE DE LA TABLA: EVOLUCION.
Descripción: la tabla almacena la información sobre la evolución de la historia clínica.
Campos
Fecha
Llave Primaria
Llave Foránea
Tipo de dato
X
Date
Hora
Not Null
X
Time
Descripcion
Varchar
200
Int
7
Valor
Numero_historia
Longitud
X
Double
X
DESCRIPCIÓN DE LOS CAMPOS
Fecha: es la llave primaria de la tabla EVOLUCIÓN que se encarga de enlazar esta tabla con las demás y almacena la fecha en la que se presenta la evolución en el
tratamiento.
Hora: este campo almacena la hora en la cual se realiza el tratamiento.
Descripción: almacena la información de lo que se realizó al paciente y que hace parte del tratamiento.
Valor: es el valor que el paciente cancela por el servicio que se le presta en esa fecha.
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
73
Tabla 30. Anexos.
NOMBRE DE LA TABLA: ANEXOS
Descripción: esta tabla almacena la información de los anexos que se adjuntan a los pacientes.
Campos
Numero_anexo
Llave Primaria
Llave Foránea
Tipo de dato
Longitud
Not Null
Int
3
X
Int
15
Varchar
200
X
Tipo_anexo
Direccion_interna
Numero_historia
X
Double
X
DESCRIPCIÓN DE LOS CAMPOS
Numero_anexo: es la llave primaria de la tabla ANEXOS que se encarga de enlazar esta tabla con las demás.
tipo_anexo: es el campo que almacena los tipos de anexo, pueden ser imágenes, radiografías, fotos, etc…
Direccion_interna: es el campo que almacena la dirección de la carpeta que contiene los anexos.
Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA.
74
Tabla 31. Citas.
NOMBRE DE LA TABLA: CITAS
Descripción: En esta tabla se almacena el Id del paciente y del odontólogo, la fecha y hora de la cita.
Campos
Fecha
Llave Primaria
Llave Foránea
Tipo de dato
X
Hora
Longitud
Not Null
Date
X
Time
X
Numero_documento_paciente
X
Double
X
Numero_documento_odontologo
X
Double
X
Numero_documento_asistente
X
Double
X
DESCRIPCIÓN DE LOS CAMPOS
Fecha: Es la llave primaria de la tabla CITAS que se encarga de enlazar esta tabla con las demás. En este campo se almacena la fecha de la cita odontológica.
Hora: En este campo se almacena la hora de la cita odontológica.
Numero_documento_paciente: Es la llave primaria de la tabla PACIENTE. Además es una llave foránea de la tabla CITAS.
Numero_documento_odontólogo: Es la llave primaria de la tabla ODONTÓLOGO. Además es una llave foránea de la tabla CITAS.
Numero_documento_asistente: Es la llave primaria de la tabla ASISTENTE. Además es una llave foránea de la tabla CITAS.
75
Tabla 32. Servicio.
NOMBRE DE LA TABLA: SERVICIO.
Descripción: la tabla almacena la información sobre los servicios que presta el consultorio.
Campos
Llave Primaria
Id_servicio
Llave Foránea
Tipo de dato
Longitud
Not Null
Int
2
X
Varchar
20
X
Nombre_servicio
Descripcion_de_servicio
Text
DESCRIPCIÓN DE LOS CAMPOS
Id_servicio: es la llave primaria de la tabla SERVICIO que se encarga de enlazar esta tabla con las demás.
Nombre_servicio: es el nombre de los servicios que se prestan en el consultorio.
Descripción_de_servicio: es la descripción de los servicios que se prestan en el consultorio.
Tabla 33. Servicios_Por_Odontólogo.
NOMBRE DE LA TABLA: SERVICIOS_POR_ODONTOLOGO.
Descripción: Es la tabla intermedia de las tablas ODONTOLOGO y SERVICIO.
Campos
Id_servicio_odontologo
Llave Primaria
Llave Foránea
Tipo de dato
Longitud
Not Null
Int
2
X
8
X
X
Id_servicio
X
Int
Numero_documento_odontologo
X
Double
X
DESCRIPCIÓN DE LOS CAMPOS
Id_servicio_odontologo: es la llave primaria de la tabla SERVICIO_POR_ODONTOLOGO que se encarga de enlazar esta tabla con las demás.
id_servicio: es la llave foránea de la tabla SERVICIO.
Numero_documento_odontologo: es la llave foránea de la tabla ODONTOLOGO.
76
Tabla 34. SMS.
NOMBRE DE LA TABLA: SMS
Descripción: En esta tabla se almacena el mensaje SMS, su hora de salida y estado.
Campos
Id_sms
Llave Primaria
Llave Foránea
X
Tipo de dato
Longitud
Double
Hora_salida_sms
Not Null
X
Time
X
Mensaje_sms
Varchar
100
X
Estado
Varchar
20
X
Numero_documento_paciente
X
Double
X
DESCRIPCIÓN DE LOS CAMPOS
Id_sms: Es la llave primaria de la tabla SMS que se encarga de enlazar esta tabla con las demás.
Hora_salida_sms: En este campo se almacena la hora de salida del mensaje.
Mensaje_sms: En este campo se almacena el contenido del mensaje.
Estado: En este campo se almacena el estado del mensaje, si el paciente lo recibió o no.
Numero_documento_paciente: Es la llave primaria de la tabla PACIENTE. Además es una llave foránea de la tabla SMS.
77
5.3.2.4.3. Asignación de Privilegios.
Tabla 35. Usuario: Administrador.
USUARIO: ADMINISTRADOR
UPDATE
SELECT
PERSONA
TABLAS
INSERT
X
DELETE
X
X
PACIENTE
X
X
X
ACUDIENTE
X
X
X
ASISTENTE
X
X
X
ODONTÓLOGO
X
X
X
ESTUDIO
X
X
X
SERVICIOS_POR_ODONTÓLOGO
X
X
X
SERVICIOS
X
X
X
HISTORIA CLÍNICA
X
X
X
PLAN DE TRATAMIENTO
X
X
X
DIENTE
X
X
X
EXÁMEN BÁSICO
X
X
X
ANEXOS
X
X
X
EVOLUCIÓN
X
X
X
CITAS
X
X
X
X
SMS
X
X
X
X
Tabla 36. Usuario: Odontólogo.
USUARIO: ODONTÓLOGO
TABLAS
UPDATE
SELECT
PERSONA
INSERT
X
DELETE
X
X
PACIENTE
X
X
X
ACUDIENTE
X
X
X
ODONTÓLOGO
X
X
ESTUDIO
X
X
SERVICIOS_POR_ODONTÓLOGO
X
SERVICIOS
X
HISTORIA CLÍNICA
X
X
X
PLAN DE TRATAMIENTO
X
X
X
DIENTE
X
X
X
EXÁMEN BÁSICO
X
X
X
ANEXOS
X
X
X
EVOLUCIÓN
X
X
X
CITAS
X
X
X
ASISTENTE
X
X
X
SMS
78
Tabla 37. Usuario: Asistente.
USUARIO: ASISTENTE
TABLAS
PERSONA
INSERT
DELETE
X
UPDATE
SELECT
X
PACIENTE
ACUDIENTE
ASISTENTE
ODONTÓLOGO
ESTUDIO
SERVICIOS_POR_ODONTÓLOGO
SERVICIOS
HISTORIA CLÍNICA
PLAN DE TRATAMIENTO
DIENTE
EXÁMEN BÁSICO
ANEXOS
EVOLUCIÓN
CITAS
X
SMS
X
X
X
X
X
Tabla 38. Usuario: Paciente.
USUARIO: PACIENTE
TABLAS
PERSONA
INSERT
DELETE
X
UPDATE
SELECT
X
PACIENTE
ACUDIENTE
ASISTENTE
ODONTÓLOGO
ESTUDIO
SERVICIOS_POR_ODONTÓLOGO
SERVICIOS
HISTORIA CLÍNICA
PLAN DE TRATAMIENTO
DIENTE
EXÁMEN BÁSICO
ANEXOS
EVOLUCIÓN
CITAS
X
X
X
X
SMS
79
5.3.2.5. Diseño de las interfaces y el odontograma. Para cumplir con los
requerimientos del aplicativo también se crean las interfaces y el odontograma, los cuales
deben ser amigables en el momento en que los usuarios interactúen con el aplicativo,
puesto que éstas son el medio de comunicación entre los usuarios y el sistema.
La herramienta que se usa para este desarrollo es Dreamweaver, Para esto se hizo en
código HTML (HyperText Markup Language) el cual está plasmado en los JSP’s del
aplicativo, se descargó una plantilla la cual se usa como interfaz para todas las pantallas,
en la parte izquierda se encuentran los links (command Link) que van asociados a
imágenes y los cuales generan una acción determinada.
Para el odontograma, como se muestra en la figura 18, se crea una matriz de las
imágenes de los dientes y se enumeran, para que cada vez que se registra un diente por
medio de la interfaz se refresque la imagen. El bean es el que realiza las consultas y
guarda la información registrada del odontograma a la hora de llenar la historia
odontológica.
Figura 18. Diseño del Odontograma.
80
En el momento de llenar la historia clínica en cada sección se usan determinados
elementos para llenar este registro, por ejemplo en los campos que se deben llenar datos
de usuario se trabaja con un Text-Area como se muestra en la figura 19, en el plan de
tratamiento al escoger los tratamientos a realizar se usan Checkbox como se muestra en
la figura 20, ya que esta función sirve para escoger varios elementos.
En la parte de hábitos de higiene oral se usan Radio Butons que en este caso se emplean
para escoger solo una opción. Para las consultas se usan herramientas de Select One
Menu, que son las listas que aparecen para escoger una opción que se encuentre en
ellas. Por último el uso de botones (command buton) que generan una acción
determinada sobre los beans en algunos casos.
Figura 19. Herramientas para el diseño de Interfaces.
81
Figura 20. Herramientas para el diseño de interfaces.
82
5.4.
IMPLEMENTACIÓN Y PRUEBA DE UNIDADES
Las herramientas de software a utilizar para la implementación del proyecto se describen
en la metodología que se encuentra en el numeral 2 en la página 20. Igualmente se deben
instalar las siguientes librerías: jsf-api y jsf-impl que corresponden a los archivos .jar y
normalmente se usan en J2EE para empaquetar módulos. Los complementos necesarios
a instalar en Netbeans son: Visual JSF, Visual Web JSF, Faceles support, Sample JSF,
Visual JSF Runtime, Ice Faces, Sun Java System, Interactive UI, Axis 2 Support. Adicional
a esto se debe instalar un navegador de internet cualquiera.
Las características de hardware con las que se debe contar para la implementación son:
el equipo en el que se desarrolla el código debe tener como mínimo una memoria RAM de
1Gb (Gigabyte) y procesador 1.5 Ghz.
5.4.1. Implementación. A continuación se describen las capas en las que se basa la
arquitectura J2EE, que se tendrán en cuenta para la implementación de la aplicación y
son: capa cliente, capa web, capa negocio y capa integración o datos. Se usará el
escenario basado en la web representado en la figura 21, el cual unifica la capa de
presentación y la capa de negocio, se escogió porque la plataforma J2EE no obliga a usar
todas las capas, en este caso el aplicativo no es tan complejo como para requerir usar
EJB (Enterprise Java Beans), para esto el escenario web nos ofrece un mecanismo
adecuado para darle solución al objetivo principal y además es el más usado actualmente.
Esto permite dar inicio a la implementación y pruebas del aplicativo web creado para la
administración de citas e historias odontológicas.
83
Figura 21. Escenario Basado en la Web de J2EE.
5.4.1.1. Capa de Integración o Datos. En la figura 22 se muestra como se hace la
conexión a la base de datos, para este fin llamada odontocentro, ya que sin esta no es
posible agregar los datos que se necesitan para que el aplicativo funcione correctamente
y de acuerdo a los requerimientos antes mencionados. Para esto se creó una clase en
netbeans llamada Conexión en donde importa la librería java.sql, debe contener el
nombre, el login, password de la base de datos y el url de conexión.
84
Figura 22. Conexión Base de Datos.
En la figura 23 encontramos las propiedades de la base de datos, se encuentran el Url de
la base de datos el cual es: jdbc:mysql:///odontocentro, el controlador usado:
com.mysql.jdbc.Driver, proveedor de la base de datos MySQL y la versión de la base de
datos: 5.1.50.
85
Figura 23. Propiedades de la base de datos.
Para ver la consistencia y el cumplimiento de la integridad de los datos, se hacen
consultas para determinar estas características. En la figura 24 se hace una consulta para
ver que personas se encuentran registradas en la base de datos.
86
Figura 24. Consulta Personas.
En la figura 25 se hace una consulta para ver las citas que se han programado y están
guardadas en la base de datos.
Figura 25. Consulta Citas.
87
En la figura 26 encontramos a los pacientes que se encuentran registrados en la base de
datos.
Figura 26. Consulta Pacientes.
La figura 27 es una consulta de los odontólogos que también están registrados en el
sistema.
Figura 27. Consulta Odontólogos.
88
En la figura 28 podemos encontrar una de las consultas que realiza el asistente por medio
de la interfaz, para saber que citas hay programadas en un día determinado, mostrando el
nombre y el número de documento del paciente, el odontólogo que lo atenderá y la fecha.
Figura 28. Consulta Citas Agendadas
89
5.4.1.2. Capa de Negocio. En esta capa se hace el uso de “JavaBeans que son
componentes hechos en software que se pueden reutilizar y que pueden ser manipulado
visualmente por una herramienta de programación en lenguaje Java.”22. Para la
implementación de esta capa se crean los siguientes JavaBeans como se muestran en la
figura 29, que son necesarios para ofrecer los servicios con los que éste debe contar.
Estos beans son los siguientes: ActualizaPaciente, Anexos, Evolucion, Historial,
IngresarEstudio,
PlandeTratamiento,
InsertarAcudiente,
Registro,
Odontograma,
Servicios, AsignarCita, ConsultarCitas, SolicitarCita, SesionAsistente, SesionOdontologo,
SesionPaciente, InicioAsistente, InicioPaciente e InicioOdontologo. Los beans antes
mencionados se clasifican de la siguiente manera:

Beans para actualizar: Los beans de ActualizaPaciente, se usa en general como el
nombre lo indica para actualizar los datos básicos de los usuarios.

Beans
para
guardar
y
consultar
datos:
Anexos,
Evolucion,
Historial,
IngresarEstudio, PlandeTratamiento, InsertarAcudiente, Registro, Odontograma,
Servicios, AsignarCita, ConsultarCitas y SolicitarCita.

Beans para iniciar sesión: SesionAsistente, SesionOdontologo y SesionPaciente.
Encargados de validar los datos que se están ingresando para el inicio de sesión
de cada usuario.

Beans de inicio: InicioAsistente, InicioPaciente e InicioOdontologo, se crean para
mostrar los datos a los usuarios a la hora de generar una consulta.
22
Definición
JavaBean
[artículo
en
línea]
Disponible
desde
Internet
en:
<http://www.sc.ehu.es/sbweb/fisica/cursoJava/applets/javaBeans/fundamento.htm#Definición de JavaBean>, Octubre 5
de 2010, 2:23 p.m.
90
Figura 29. JavaBeans de la aplicación.
En esta capa también se encuentra el proceso que se lleva a cabo para implementar la
mensajería de texto a través de un servicio llamado elibom, el cual ofrece un ejemplo del
código en java, el cual conecta la aplicación al Gateway de mensajería para enviar
mensajes SMS de forma automática. En la figura 30 se muestra el código que se
implementó en la aplicación para le envió de mensajes SMS.
91
Figura 30. Código para envió de SMS.
Para usar este servicio antes debe hacerse un registro de usuario por medio de la página
www.elibom.com para que se pueda usar el mail, contraseña (del registro), número de
celular y mensaje que se va a enviar.
5.4.1.3. Capa Web. “Se encuentra en el servidor web y contiene la lógica de presentación
que se utiliza para generar una respuesta al cliente. Recibe los datos del usuario desde la
capa cliente y basado en estos genera una respuesta apropiada a la solicitud. J2EE utiliza
en esta capa los componentes Java Servlets y JavaServer Pages para crear los datos que
se envían al cliente”.23. En la figura 31 se encuentran los JSP implementados en esta
capa para desplegar las páginas con las que cuenta la aplicación, a continuación se
mencionan algunos JSP’s que se encuentran:
23
Investigación de la plataforma J2EE y su aplicación práctica [artículo en línea] Disponible desde Internet en:
<http://www.dcc.uchile.cl/~jbarrios/[email protected]>, Octubre 7 de 2010, 4:01 p.m.
92

JSP’s para actualizar datos de los usuarios.

JSP´s para asignar citas.

JSP´s para la consulta de citas.

JSP´s para envio de SMS.

JSP´s para errores.

JSP´s para registros.

JSP´s para iniciar sesión.

JSP´s para reportes.

JSP´s para cada sección de la historia odontológica.
93
Figura 31. JSP´s de la aplicación.
El código XML nombra los beans para realizar las acciones determinadas por cada uno y
también a los JSP´s para encadenar cada página y crear las reglas de navegación. Este
código se encuentra en la aplicación en la parte de Configuration Files, faces-config.xml,
en la herramienta de desarrollo en netbeans.
5.4.1.4. Capa Cliente. Es la interfaz gráfica del sistema y se encarga en interactuar con
el usuario. La figura 32 es la interfaz del aplicativo que sirve para que un paciente se
pueda registrar por medio de la página web. Las demás interfaces se encuentran en el
manual de usuario, ya que con ellas se explica paso a paso el funcionamiento del
aplicativo.
94
Figura 32. Interfaz Gráfica del Aplicativo.
5.4.2. Prueba de Unidades. En esta etapa del proyecto se llevan a cabo las pruebas a
cada uno de los módulos, se ejecutan y si fallan se procede a localizar el fallo y repararlo.
“Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir,
intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se
denominan pruebas funcionales, y el probador se limita a suministrarle datos como
entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo
por dentro.”24
“Pueden aplicarse cuando aún no esté implementado el código fuente del programa, pero
sí se conoce lo que se espera que haga”.25
24
Pruebas
del
sistema,
[artículo
en
línea]
Disponible
desde
Internet
en:
<http://www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/testing.htm>, Octubre 6 de 2010, 10:34 a.m.
25
TUYA Javier, RAMOS ROMAN Isabel, DOLADO COSIN Javier, Técnicas Cuantitativas Para La Gestión En La
Ingeniería del Software, Editores NETBIBLO, España 2007, p 49.
95
5.4.2.1. Prueba Autenticación. Se realizan las pruebas de autenticación para el paciente,
odontólogo, asistente y administrador; los cuales interactúan todo el tiempo con el sistema
y están representadas en las tablas 39 y 40.
Tabla 39. Caso de Prueba Iniciar Sesión.
Caso de Prueba: Iniciar Sesión.
Objetivo: Probar la acción de iniciar sesión del paciente, odontólogo, asistente y administrador cuando sus datos están en
la base de datos.
Condiciones de la prueba: Los usuarios deben estar registrados con anterioridad.
Entradas: Usuario y Contraseña.
Salidas deseadas: Los usuarios inician sesión correctamente y pueden hacer uso de los servicios a los que puede
acceder.
Tabla 40. Caso de Prueba Cerrar Sesión.
Caso de Prueba: Cerrar Sesión.
Objetivo: Probar la acción de cerrar sesión del paciente, odontólogo, asistente y administrador cuando ha iniciado una
sesión.
Condiciones de la prueba: Los usuarios deben estar registrados con anterioridad y haber iniciado la sesión.
Entradas: cerrar sesión.
Salidas deseadas: Los usuarios cierran sesión correctamente y vuelven a la página principal.
5.4.2.2. Prueba Registrar Usuario.
Se realizan las pruebas a los registros de los
pacientes que se hacen por medio de la página web, los demás usuarios del sistema
deben ser registrados por el administrador, se describe esta prueba en la tabla 41.
Tabla 41. Caso de Prueba Registrar Usuario.
Caso de Prueba: Registrar Usuario.
Objetivo: Probar la acción de registrar el paciente, odontólogo, asistente y administrador.
96
Condiciones de la prueba: Los usuarios deben ingresar los datos requeridos para su registro.
Entradas: Nombre, apellidos, estado civil, sexo, tipo de documento, número de documento, fecha de nacimiento,
ocupación, dirección, barrio, teléfono y celular.
Salidas deseadas: Los usuarios se registran correctamente.
5.4.2.3. Pruebas Actualizar Usuario. Para actualizar los datos de los usuarios
previamente deben estar autenticados como lo muestra la tabla 42.
Tabla 42. Caso de Prueba Actualizar Usuario.
Caso de Prueba: Actualizar Usuario.
Objetivo: Probar la acción de actualizar los datos de los usuarios.
Condiciones de la prueba: Los usuarios deben estar registrados y autenticados con anterioridad, solo se pueden
actualizar los campos permitidos.
Entradas: Ocupación, dirección, barrio, teléfono, celular y contraseña.
Salidas deseadas: Los usuarios se actualizan los datos permitidos.
5.4.2.4. Prueba Historia Clínica Odontológica. Se realizan las pruebas a la historia
clínica, para esto el odontólogo y el administrador deben tener permisos para acceder a
esta, es decir, que la pueden crear y consultar. La tabla 43 corresponde a la prueba crear
historia clínica odontológica y la tabla 44 hace referencia al caso de prueba clínica
odontológica.
Tabla 43. Caso de Prueba Crear Historia Clínica Odontológica.
Caso de Prueba: Crear Historia Clínica Odontológica.
Objetivo: Probar la acción de crear la historia clínica odontológica de un paciente.
Condiciones de la prueba: Los usuarios deben autenticados con anterioridad.
Entradas: Usuario y Contraseña.
Salidas deseadas: El usuario crea la historia clínica odontológica.
97
Tabla 44. Caso de Prueba Consultar Historia Clínica Odontológica.
Caso de Prueba: Consultar Historia Clínica Odontológica.
Objetivo: Probar la acción de consultar la historia clínica odontológica de un paciente.
Condiciones de la prueba: Los usuarios deben autenticados con anterioridad.
Entradas: Número de documento del paciente.
Salidas deseadas: El usuario consulta la historia clínica odontológica.
5.4.2.5. Prueba Citas. Para realizar estas pruebas los usuarios deben estar autenticados
con anterioridad en el sistema, en este módulo se pueden solicitar y cancelar citas que
corresponden a las tablas 45 y 46 respectivamente.
Tabla 45. Caso de Prueba Solicitar Cita.
Caso de Prueba: Solicitar Cita.
Objetivo: Probar la acción de solicitar una cita odontológica.
Condiciones de la prueba: Los usuarios deben estar autenticados con anterioridad. Cuando el usuario ingrese los datos
requeridos se confirma la disponibilidad para crear la cita.
Entradas: Número de documento del paciente, día, fecha, hora de la cita, y odontólogo disponible.
Salidas deseadas: El usuario Solicita la cita odontológica.
Tabla 46. Caso de Prueba Cancelar Cita.
Caso de Prueba: Cancelar Cita.
Objetivo: Probar la acción de cancelar una cita odontológica.
Condiciones de la prueba: Los usuarios deben autenticados con anterioridad.
Entradas: Número de documento del paciente.
Salidas deseadas: El usuario cancela la cita odontológica.
98
5.4.2.6. Prueba Enviar Sms. Después que la asistente se autentica procederá a enviar el
sms al celular del paciente indicando la fecha y hora de su próxima cita odontológica
como se muestra en la tabla 47.
Tabla 47. Caso de Prueba Enviar SMS.
Caso de Prueba: Enviar Sms.
Objetivo: Probar la acción de enviar un mensaje de texto al celular de los pacientes para recordar la fecha y hora de la
próxima cita odontológica.
Condiciones de la prueba: La asistente debe estar autenticada con anterioridad y la información del paciente debe estar
en la base de datos.
Entradas: Número de documento del paciente, numero de celular y mensaje.
Salidas deseadas: Se envía el sms.
En la figura 33 se representa el caso de prueba enviar un mensaje de texto corto,
ingresado desde el aplicativo.
Figura 33. Envio de SMS
99
En la figura 34 se muestra en la base de datos que el mensaje de texto corto ha sido
enviado con éxito a su destinatario.
Figura 34. Confirmación de Salida SMS
100
5.5.
INTEGRACIÓN Y PRUEBAS DEL SISTEMA.
Seguido de las pruebas funcionales se procede a realizar las pruebas del sistema en
conjunto, esto se hace para determinar si se cumplen con los requerimientos, identificar y
corregir los errores que se pueden presentar en el funcionamiento del aplicativo. Todas
las pruebas que a continuación se describen en las tablas 48, 49, 50 y 51 se han hecho a
través de la interfaz creada para la comunicación entre el usuario y el sistema.
Tabla 48. Caso de Prueba Registrar Usuario Existente.
Caso de Prueba: Registrar Usuario Existente.
Objetivo: Probar la acción de registrar un usuario que ya existe en la base de datos.
Condiciones de la prueba: Llenar el registro con el mismo número de documento.
Entradas: Nombre, apellidos, estado civil, sexo, tipo de documento, número de documento, fecha de nacimiento,
ocupación dirección barrio teléfono celular.
Salidas deseadas: El usuario ya se encuentra registrado.
Al hacer la prueba se identificó que el sistema no valida si existe el número de documento
que el usuario ingresa y lo deja registrar. Al revisar en la base de datos no almacena de
nuevo ese registro y deja el que ya se había creado.
101
Figura 35. Error Registro.
En la figura 35 se muestra el error corregido se validó que el número de documento que
ingresa el usuario no se encuentre en la base de datos, si existe, envía un mensaje
diciendo que el usuario ya está registrado.
Tabla 49. Caso de Prueba Registrar Usuario con datos no válidos.
Caso de Prueba: Registrar Usuario con datos no válidos.
Objetivo: Probar la acción de registrar un usuario con datos que no son válidos.
Condiciones de la prueba: Llenar el registro.
Entradas: Nombre, apellidos, estado civil, sexo, tipo de documento, número de documento, fecha de nacimiento,
ocupación, dirección, barrio, teléfono, celular no válidos.
Salidas deseadas: No se pudo realizar el registro, compruebe los datos ingresados.
Se identifica que el sistema hace el registro sin enviar ningún mensaje de error, pero no
guarda ese registro en la base de datos.
102
Se corrige el error validando que cada uno de los campos que se ingresan son los
correctos y realiza el registro, en caso contrario envía un mensaje diciendo que
compruebe los datos ingresados.
Tabla 50. Caso de Prueba Consultar Cita.
Caso de Prueba: Consultar Cita.
Objetivo: Probar la acción de consultar una cita.
Condiciones de la prueba: El usuario debe estar autenticado.
Entradas: ninguna.
Salidas deseadas: nombre del odontólogo, fecha y hora de la cita.
Al hacer la consulta solo aparecen en pantalla la fecha y hora de la cita.
Figura 36. Cita Asignada.
Se corrige la prueba mostrando todas las salidas deseadas como se ve en la figura 36.
103
Tabla 51. Autenticar usuarios con datos no válidos.
Caso de Prueba: Autenticar usuarios con datos no válidos.
Objetivo: Probar la acción de autenticar usuarios con datos no válidos.
Condiciones de la prueba: ninguna.
Entradas: Usuario y contraseña.
Salidas deseadas: el usuario o la contraseña son incorrectos.
Figura 37. Error Registro.
En el momento que el usuario quiera ingresar al sistema, debe digitar el usuario y
contraseña que se le asignaron en el proceso de registro y con los cuales se identifica. La
figura 37 muestra que la prueba se realizó satisfactoriamente ya que se validan que los
datos son correctos.
104
5.6.
FUNCIONAMIENTO Y MANTENIMIENTO
Esta fase no se realizó, porque, no es inmediata sino que hace parte de un proceso de
acompañamiento a mediano plazo, en el cual se debe tener disponibilidad para solucionar
problemas e imprevistos que se generan en el uso del software, mientras la persona que
lo utiliza en lo cotidiano se capacita totalmente.
105
6.
PRESENTACIÓN Y ANÁLISIS DE RESULTADOS
El producto final es un software que cumple con las necesidades de un consultorio
odontológico que le permita administrar las historias clínicas odontológicas y las citas. Por
medio del sitio web se facilita al paciente el proceso de solicitud de una cita, ya que
muchas veces el servicio telefónico no está disponible o es más ágil para el usuario hacer
uso de internet para este fin.
Para alcanzar los objetivos propuestos se desarrollaron con éxito cada una de las etapas
establecidas en la metodología del modelo en cascada y se presentan los siguientes
resultados:
Análisis y definición de requerimientos
Una vez realizadas las encuestas a los pacientes y la entrevista a la odontóloga en el
consultorio que se utilizó como base, se hizo el levantamiento de la información, se
identificaron los requerimientos funcionales y no funcionales para determinar el
comportamiento del sistema. Posteriormente se realizó una tabulación de los datos
adquiridos.
La odontóloga, consideró que era necesario sistematizar la información ya que las
tendencias tecnológicas van evolucionando y estas permiten agilizar los procesos que se
llevan actualmente en el consultorio. También por medio del aplicativo web existe la
oportunidad para darse a conocer a nivel mundial y de esta forma hacer que los visitantes
a su página conozcan los servicios del consultorio odontológico.
Igualmente la mayoría de los encuestados coincidieron en que para ellos sería más
cómodo, rápido y fácil solicitar o cancelar su próxima cita odontológica por medio de una
página web, ya que en ella se pueden visualizar horarios, fechas y odontólogos
disponibles con su respectiva especialidad.
106
Diseño del sistema
Se definieron los 4 actores que interactúan en el sistema (Administrador, Odontólogo,
Asistente y Paciente), se elaboraron los diferentes diagramas de casos de uso para cada
uno de los actores especificando las funciones y actividades que pueden realizar en el
sistema y por último estos se describieron de manera secuencial.
Diseño del software
Se tomaron ya elaborados los diagramas de casos de uso, se diseñaron los de secuencia,
clases y actividades para esta etapa, se diseñó el modelo de la base de datos, se
establecieron privilegios; a medida que se fue construyendo el software los diagramas
mencionados fueron cambiando poco a poco pero sin modificar los requerimientos
iniciales que se obtuvieron por medio de las encuestas realizadas en el consultorio.
Implementación y pruebas de unidades
Se implementó la aplicación basada en la arquitectura J2EE creando las capas que la
componen: capa cliente, capa web, capa negocio y capa integración o datos. Para esto se
codificaron las clases y métodos que dan soporte al escenario basado en la web el cual
unifica la capa de presentación y la capa de negocio y no obliga al uso de EJB.
De la misma manera se estableció la conexión con la base de datos, se diseñó el
odontograma y las interfaces gráficas para la comunicación entre el usuario y el sistema.
En la fase de pruebas de unidades se realizaron las pruebas de caja negra las cuales se
centran en lo que se espera de cada uno de los módulos implementados, se ejecutó cada
uno de ellos y en el momento que se encontraron fallos se procedió a localizarlos y
repararlos.
107
Integración y pruebas del sistema.
Se realizaron las pruebas del sistema en conjunto con el fin de determinar si se
cumplieron los requerimientos y corregir los errores que se presentaron en el
funcionamiento del aplicativo. Con estas correcciones se da por terminada esta fase y se
puede proceder a hacer mejoras futuras.
Funcionamiento y mantenimiento
Esta fase requiere, como ya se dijo anteriormente, disponibilidad y acompañamiento por
parte del ingeniero mientras en el consultorio se tiene la capacitación necesaria para el
uso óptimo del software.
En definitiva, se confirmó la validez del uso de este software para el consultorio
odontológico porque su uso facilita el trabajo y ayuda en este caso a esta disciplina a
mejorar sus procesos como lo es la atención a los pacientes. Además la tecnología
aplicada a las ciencias hace más efectivo el trabajo de los profesionales.
108
CONCLUSIONES
Los requerimientos obtenidos son la base para empezar a construir el software de
acuerdo a las necesidades del usuario final, estos ayudan a establecer las entradas,
procesos y salidas que el aplicativo debe generar para su buen funcionamiento.
El modelo de la base de datos permitió construir una representación gráfica de las
entidades, atributos y relaciones con las que cuenta el aplicativo. Este diseño facilitó que
la información guardada funcione de una manera integral en el sistema, haciendo que
esta no sea redundante y repetitiva.
La autenticación de los usuarios que ingresan al sistema se hizo por medio de la
identificación de los privilegios con los que cuenta cada uno. Se establece un usuario y
contraseña para restringir el acceso a personas que no están autorizadas para el uso de
los servicios con los que el aplicativo cuenta.
Se diseñó el software basado en un escenario web que se trabaja en la plataforma J2EE,
para llegar a este diseño se crearon los diagramas de casos de uso, secuencia, clases y
actividades; los cuales son establecidos por el estándar UML.
Las interfaces gráficas y el odontograma se diseñaron con el motor de desarrollo
dreamweaver que permite combinar los diseños en HTML e integrarlos en el código java.
El odontograma es un diseño ya establecido para la representación de las características
de los dientes del ser humano, se incluye esta representación para una persona adulta o
un niño sobre los cuales se deben señalar las patologías que tienen o tratamientos que se
deben realizar a los pacientes.
Las pruebas permitieron detectar los errores y fallas identificadas a lo largo del desarrollo
del proyecto; a partir de estas se corrigieron para hacer entrega de un software que
cumple con los requerimientos planteados.
109
RECOMENDACIONES
Incluir los temas que abarcan la plataforma J2EE en las materias que son electivas para
el programa de ingeniería de sistemas, ya que está presente en las nuevas tecnologías y
actualmente no se encuentra mucha información acerca de cómo hacer uso de ella.
El buen modelamiento de la base de datos debe reflejar todas las entidades y atributos
imprescindibles para que se puedan guardar los datos, éste es uno de los pasos más
tediosos para la realización de una aplicación que interactúe con ésta, ya que si no es
bien modelada se puede tardar más del tiempo estimado para la culminación del proyecto.
Cumplir con todas las etapas de manera secuencial establecidas en la metodología que
se escoja, puesto que en cada una de ellas se pueden solucionar los inconvenientes que
se presenten en el momento y así no tener dificultades graves con el producto final.
Elegir un adecuado proveedor de mensajería que permita conectar la aplicación al
servicio SMS que este presta.
Adquirir un servicio de hosting que soporte el motor de bases de datos MySql, el servidor
de aplicaciones Apache Tomcat y el lenguaje java para usar el aplicativo en la web.
En el momento de poner en funcionamiento la aplicación es necesario reiniciar el servidor
Tomcat para que guarde correctamente en la base de datos; cuando la aplicación esté en
internet el hosting lo hace automáticamente.
Se pueden adicionar mejoras a la aplicación según las necesidades de los diferentes
consultorios odontológicos, incluyendo nuevos módulos para elaborar un software
competitivo en el mercado.
110
BIBLIOGRAFÍA
ARIZA, Lina. Panorámica del software libre en Colombia. En Sistemas. SeptiembreNoviembre, 2004, vol.90.
AVELLANAL DURANTE, Ciro, Diccionario Odontológico. Buenos Aires: Mundi, 1961.
777 p.
DEBRAUER, LAUREN Y VAN DER HEIDE, FIEN UML2, Ediciones ENI. Barcelona 2009.
245 p.
DEITEL, Harvey y Deitel Paul. Como Programar en Java. México: Pearson Prentice Hall,
2004. 1268 p.
FALGUERAS CAMPDERRICH, BENET, Ingeniería del Software, Editorial UOC.
Barcelona 2003. 314 p.
JACOBSON, Ivar; Booch, Grady; Rumbaugh James. El proceso de desarrollo de software,
Addison-Wesley , 1999.
PRESSMAN S. Roger. Ingeniería del software un enfoque práctico. México: Mc Graw Hill,
2006. 958 p.
RODRIGUEZ ALMEIDA, Miguel Ángel. Bases de Datos, Mc. Graw Hill. P257.
SOMMERVILLE, Ian. Ingeniería del software. Madrid: Pearson Educación. S.A., 2005.
712 p.
TUYA Javier, RAMOS ROMAN Isabel, DOLADO COSIN Javier, Técnicas Cuantitativas
Para La Gestión En La Ingeniería del Software, Editores NETBIBLO, España 2007, 325 p.
111
WEITZENFELD, Alfredo. Ingeniería de software orientada a objetos con Uml. Java e
internet. México: Thomson, 2005. 678 p.
112
WEBGRAFÍA
Dentilogic,
[artículo
en
línea]
Disponible
desde
Internet
en:
<https://www.dentilogic.com/acm/es/dl/About.htm> [con acceso el 10 de marzo de 2009]
Propractica Dental Software, [artículo en línea] Disponible desde Internet en:
<http://propractica.tripod.com/descripc.htm> [con acceso el 10 de marzo de 2009]
Historia
Clínica,
[artículo
en
línea]
Disponible
desde
Internet
en:
<http://es.wikipedia.org/wiki/Historia_cl%C3%ADnica> [con acceso el 30 de marzo de
2009]
Definición de servidor de aplicaciones, [artículo en línea] Disponible desde Internet en:
<http://www.alegsa.com.ar/Dic/servidor%20de%20aplicaciones.php> [con acceso el 01 de
mayo de 2009]
¿Qué es un servidor de aplicaciones?, [artículo en línea] Disponible desde Internet en:
<http://www.editum.org/Que-Es-Un-Servidor-De-Aplicaciones-p-473.html> [con acceso el
01 de mayo de 2009]
Introducción a los servidores de aplicaciones, [artículo en línea] Disponible desde Internet
en:
<http://www.jtech.ua.es/j2ee/2003-2004/abierto-j2ee-2003-2004/sa/sesion1apuntes.htm> [con acceso el 02 de mayo de 2009]
¿Qué
es
SMS?,
[artículo
en
línea]
Disponible
desde
Internet
en:
<http://www.sitiosespana.com/notas/febrero-2005/QUE-ES-SMS.htm> [con acceso el 02
de mayo de 2009]
Definiciones [artículo en línea] Disponible desde Internet en: <http://es.wikipedia.org/wiki/>
[con acceso el 10 de mayo de 2009]
Gestión de Transacciones en la Plataforma J2EE, Leonardo Rodríguez Viacava Daniel
Perovich
[pdf
en
línea]
Disponible
desde
Internet
en:
<
http://www.fing.edu.uy/inco/pedeciba/bibliote/reptec/TR0312.pdf> [con acceso el 13 de
mayo de 2009]
Definición
de
J2EE,
[artículo
en
línea]
Disponible
desde
Internet
en:
<
http://www.mastermagazine.info/termino/5466.php> [con acceso el 13 de mayo de 2009]
113
Definición de Ingeniería de software, metodologías y ciclos de vida, [artículo en línea]
Disponible desde Internet en: < http://www.slideshare.net/vdaniel20/metodologas-y-ciclosde-vida > [con acceso el 31 de julio de 2010]
Definición de Desarrollo en Cascada, [artículo en línea] Disponible desde Internet en:
<http://es.wikipedia.org/wiki/Modelo_en_cascada> [con acceso el 31 de julio de 2010]
Framework unificado para desarrollo de interfaces J2EE, [artículo en línea] Disponible
desdeInterneten:<http://pegasus.javeriana.edu.co/~fwj2ee/descargas/requerimientos(v1.1)
.pdf>[con acceso el 5 de agosto de 2010]
Análisis y Diseño Orientado a Objetos, [artículo en línea] Disponible desde Internet en:
<http://www.dcc.uchile.cl/~luguerre/cc40b/clase13.html> [con acceso el 8 de agosto de
2010]
Definición
JavaBean
[artículo
en
línea]
Disponible
desde
Internet
en:
http://www.sc.ehu.es/sbweb/fisica/cursoJava/applets/javaBeans/fundamento.htm#Definició
n de JavaBean. [Con acceso Octubre 5 de 2010]
Definición Diagrama de Actividades, [artículo en línea] Disponible desde Internet en:
http://www.scribd.com/doc/13735556/ADOO-Diagramas-de-Actividades,
[Con
acceso
Septiembre 23 de 2010]
Pruebas del sistema, [artículo en línea] Disponible desde Internet en:
http://www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/testing.htm, [Con acceso
Octubre 6 de 2010]
Ejemplo para el manejo de una historia clínica odontológica, [artículo en línea] Disponible
desde Internet en:
http://www.saludcapital.gov.co/Publicaciones/Garantia%20de%20Calidad/GUIA%20PRAC
TICA%20DE%20HABILITACION/Anexos%20Guia%20Practica%20ajustados/Anexo%20N
%C2%B0%2037%20Protocolo%20de%20Uso%20y%20Manejo%20Historia%20Clinica.do
c, [Con acceso Agosto 5 de 2010]
114
GLOSARIO ODONTOLÓGICO
AMALGAMA: material de restauración a base de plata con excelentes características de
adhesión al tejido dentario.
CARIES DENTAL: proceso patológico localizado, que comienza con la desmineralización
de los tejidos duros del diente hasta llegar a la cavitación.
CIRUGÍA: tiene por objeto tratar las enfermedades de los dientes y de los maxilares.
ENDODONCIA: parte de la odontología que trata de las enfermedades de la pulpa dental.
HISTORIA CLÍNICA: es un documento, el cual surge en el contacto entre el equipo de
salud y los usuarios. Además de los datos clínicos que tengan relación con la situación
actual del paciente, incorpora los datos de sus antecedentes personales y familiares, sus
hábitos. También incluye el proceso evolutivo, tratamiento y recuperación.
ODONTOGRAMA: representación de las características, alteraciones y patologías que
pueden encontrarse en un paciente, al momento de su examen por un odontólogo, en una
historia clínica.
OPERATORIA: parte de la odontología que estudia todos los procedimientos manuales
destinados a evitar y curar las enfermedades de los dientes.
ORTODONCIA: ciencia que estudia la corrección de las anomalías dentarias.
PROFILAXIS: conjunto de medios o procedimientos que se emplean para prevenir las
enfermedades.
RESINA: biomaterial para restauración dental, su principal diferencia con la amalgama es
su color que brinda mayor estética.
SELLANTE: resina fluida que se utiliza para sellar las fosas y fisuras de los dientes
jóvenes para prevenir la caries dental.
115
GLOSARIO TÉCNICO
HTTP: define la sintaxis y la semántica que utilizan los elementos software de la
arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo
orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un
servidor.
JAR: Java Archive. Formato de fichero independiente de la plataforma que permite
empaquetar varios ficheros en uno. Normalmente se usa en J2EE para empaquetar
módulos EJB.
JavaBean: Un JavaBean o bean es un componente hecho en software que se puede
reutilizar y que puede ser manipulado visualmente por una herramienta de programación
en lenguaje Java
J2EE: Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2
Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de
programación—parte de la Plataforma Java—para desarrollar y ejecutar software de
aplicaciones en Lenguaje de programación Java con arquitectura de N niveles distribuida,
basándose ampliamente en componentes de software modulares ejecutándose sobre un
servidor de aplicaciones.
JSP: JavaServer Pages (JSP) es una tecnología Java que permite generar contenido
dinámico para web, en forma de documentos HTML, XML o de otro tipo. Ésta tecnología
es un desarrollo de la compañía Sun Microsystems. La Especificación JSP 1.2 fue la
primera que se liberó y en la actualidad está disponible la Especificación JSP 2.1.
XML: Extensible Markup Language (XML) es un sencillo, formato de texto muy flexible
derivado de SGML (ISO 8879). Originally designed to meet the challenges of large-scale
electronic publishing, XML is also playing an increasingly important role in the exchange of
a wide variety of data on the Web and elsewhere. Originalmente diseñado para afrontar
los retos de gran escala de la publicación electrónica, XML también está desempeñando
un papel cada vez más importante en el intercambio de una amplia variedad de datos en
la Web y en otros lugares.
116
ANEXO A.
Ejemplo de procedimiento institucional documentado para el uso y manejo de la
historia clínica de un servicio odontológico
ANEXO A.
XXXXXXXXXXXXXXXXX
INSTITUCION
DOCUMENTO
PROCEDIMIENTO INSTITUCIONAL PARA EL USO Y
MANEJO DE LA HISTORIA CLÍNICA
FECHA DE ELABORACIÓN:
DD/MM/AAAA
FECHA DE
ACTUALIZACIÓN:
DD/MM/AAAA
CONTENIDO
1.
2.
3.
3.1
3.2
3.3
3.4
3.5
4.
5.
6.
6.1
6.2
6.3
6.4
6.5
7.
8.
9.
10.
10.1
10.2
10.3
10.4
11.
Definición
Normatividad vigente
Directivas internas sobre la Historia Clínica
Historia Clínica Única
Obligatoriedad de la apertura de Historia Clínica
Obligatoriedad del registro
Calidad de los registros en la Historia Clínica
Custodia de la Historia Clínica
Características de la Historia Clínica
Componentes de la Historia Clínica
Formatos de la Historia Clínica
Historia Clínica (Apertura de Historia Clínica de Primera Vez)
Evolución del Tratamiento
Referencia y Contrarreferencia
Consentimiento Informado
Presupuesto Odontológico
Instructivos de la Historia Clínica
Diligenciamiento de la Historia Clínica
Uso de la Historia Clínica
Manejo de la Historia Clínica
Archivo de Historias Clínicas
Registro de salida y entrada de Historias Clínicas
Foliación de Historias Clínicas
Registro general de Historias Clínicas
Anexos específicos de la Historia Clínica
117
1.
DEFINICIÓN.
En XXXXXX, la Historia Clínica es el documento privado de tipo técnico, clínico y legal, de
OBLIGATORIO diligenciamiento y sometido a reserva, donde se registran los datos del
prestador de servicios de salud y del paciente, así como la información sobre las
condiciones somática, psíquica, social, cultural, económica y medioambiental que inciden
o que pueden incidir en la salud del paciente; contiene los datos de identificación del
paciente, la información relacionada con su condición o situación clínica, sus
antecedentes personales y familiares, (patológicos, quirúrgicos, farmacológicos y
terapéuticos), los hallazgos clínicos, diagnósticos, pronósticos, el proceso evolutivo de su
condición clínica, los planes de tratamiento propuestos, los tratamientos realizados, los
controles pertinentes, el proceso de rehabilitación y la recuperación de la salud oral;
juicios clínicos, documentos relacionados, descripción de procedimientos, informaciones
generales pertinentes, información relacionada con el consentimiento informado,
documento de consentimiento del paciente, declaración de retiro voluntario del
tratamiento; también puede incluir y contener, fotografías, videos, diagramas y diseños de
estudios odontológicos (incluido el odontograma), placas y estudios radiológicos o de
imágenes diagnósticas, resultados y/o registros de exámenes clínicos y paraclínicos que
sean pertinentes para el conocimiento, evaluación, estudio, análisis, tratamiento,
recuperación, seguimiento y rehabilitación del paciente, orientado al manejo de su salud
oral.
La Historia Clínica en XXXXXX, es un documento que se inicia con la valoración del
paciente por primera vez, registra la evolución cronológica de la atención en salud oral del
paciente y se va construyendo a través del tiempo en la medida que se van
documentando los aspectos de la relación odontólogo-paciente.
La Historia clínica en XXXXXX, se constituye en el documento clave y consustancial de la
atención en salud, en este caso referida a la atención odontológica general y
especializada y representa el documento básico y principal del sistema de información de
la institución.
118
2.
NORMATIVIDAD VIGENTE
La Historia Clínica se encuentra sustentada y reglamentada en la normatividad vigente y
elaborada de acuerdo con los parámetros generales previstos en la misma, con los
contenidos mínimos requeridos y con los demás adicionales que son pertinentes y de
utilidad para la atención de salud oral en XXXXXXX.
La normatividad de referencia es la Resolución Nº 1995 de 1999, por la cual se
establecen normas para el manejo de la Historia Clínica.
3. DIRECTIVAS INTERNAS SOBRE LA HISTORIA CLÍNICA
Historia Clínica Única: En cumplimiento de la normatividad vigente, en XXXXXX se
adoptan los formatos establecidos en este protocolo como la HISTORIA CLÍNICA ÚNICA
que se utilizará para la atención de los pacientes por parte de todos y cada uno de los
profesionales de la institución.
Obligatoriedad de la apertura de Historia Clínica: A todo paciente atendido por primera
vez en XXXXXXX se le realizará el proceso de apertura de Historia Clínica.
Obligatoriedad del registro: “Los profesionales, técnicos y auxiliares que intervienen
directamente en la atención a un usuario, tienen la obligación de registrar sus
observaciones, conceptos, decisiones y resultados de las acciones en salud
desarrolladas” con ocasión de la prestación de los servicios de salud oral en XXXXXX.
Para cada una de las atenciones realizadas a los pacientes debe registrarse en la historia
clínica las acciones realizadas, los hallazgos, las observaciones, las recomendaciones y
todas las circunstancias relacionadas con la prestación de los servicios, registrando la
fecha y la hora de la atención.
Calidad de los registros en la Historia Clínica: “La Historia Clínica debe diligenciarse
en forma clara, legible, sin tachones, enmendaduras, intercalaciones, sin dejar espacios
en blanco y sin utilizar siglas. Cada anotación debe llevar la fecha y hora en la que se
realiza, con el nombre completo y firma del autor de la misma”.
119
Custodia de la Historia Clínica: Aunque en este Protocolo se establecen los flujos y
manejos de entrada y salida de la Historia Clínica del archivo y las personas responsables
de los mismos, debido al carácter confidencial y de reserva de la Historia Clínica, todo el
personal asistencial y administrativo de la institución relacionado con el manejo y tráfico
de la Historia Clínica debe velar por su custodia y conservación.
4. CARACTERÍSTICAS DE LA HISTORIA CLÍNICA
En coincidencia con la normatividad vigente, en XXXXXXX se establece que las
características básicas de la Historia Clínica son:
Integralidad: Que consiste en que la historia clínica de un paciente reunirá la información
concerniente a los aspectos científicos, técnicos y administrativos de la atención en salud
oral en las fases de fomento, promoción, prevención específica, diagnóstico, tratamiento,
recuperación y rehabilitación de la salud oral, considerando al paciente integralmente y en
sus relaciones con los ámbitos biológicos, psicológico y social, e interrelaciones con sus
dimensiones personal, familiar y comunitaria.
Secuencialidad: Los registros de la prestación de los servicios en salud deben
consignarse en la secuencia cronológica en que ocurrió la atención.
Racionalidad científica: Es la aplicación de criterios científicos en el diligenciamiento y
registro de las acciones en salud brindadas al paciente de modo que evidencie en forma
lógica, clara y completa, el procedimiento que se realizó en la investigación de sus
condiciones de salud, diagnóstico y plan de manejo.
Disponibilidad: Es la posibilidad de utilizar la historia clínica en el momento en que se
necesita, con las limitaciones que impone la Ley.
Oportunidad: Es el diligenciamiento de los registros de atención de la historia clínica,
simultánea o inmediatamente después de que ocurre la prestación del servicio.
5. COMPONENTES DE LA HISTORIA CLÍNICA.
La Historia Clínica de XXXXXXX, se concibe en dos dimensiones prácticas que son:
120

El documento de Apertura de Historia Clínica de Primera Vez, de donde
se registran los datos de identificación del paciente, la anamnesis y la
información clínica resultante de la atención de Primera vez, y

La Historia Clínica como el expediente que incluye el documento de
apertura mencionado arriba y todos los demás documentos de la Historia
Clínica.
Son componentes de la historia clínica, la identificación del usuario, los registros
específicos y los anexos. Los datos de los componentes de identificación del usuario y de
los registros específicos del documento de Apertura de Historia Clínica de Primera Vez
de la Historia Clínica de XXXXXX, son los siguientes, aquí solamente mencionados
debido a que serán descritos en detalle es los numerales 6 y 7 de formatos e instructivos
respectivamente:

Número de Historia Clínica

Fecha y Hora de atención

Datos personales del paciente: número y tipo de documento de identidad,
fecha de nacimiento, edad, estado civil, dirección, aseguradora, tipo de
vinculación, ocupación.

Datos del Responsable del paciente: nombre, parentesco, dirección,
ciudad, localidad, barrio, teléfono.

Datos del Acompañante del paciente: nombre, parentesco, teléfono.

Causa de consulta y enfermedad actual

Antecedentes personales

Antecedentes Familiares

Examen Físico: Estomatológico, periodontal, pulpar, tejidos dentarios y
oclusión, odontograma.

Diagnóstico

Pronóstico

Plan de tratamiento: Operatoria, endodoncia, periodoncia, ortodoncia,
cirugía, prostodoncia.

Descripción del Plan de Tratamiento
121

Consentimiento informado (*)

Firma y sello del profesional

Firma y cédula del paciente
Los componentes de la Historia Clínica como Expediente son:

El documento de Apertura de Historia descrito antes

La hoja de Evolución del tratamiento

El Consentimiento Informado (*)

El Presupuesto odontológico

Todos los demás documentos y registros clínicos (placas Rx, diseños,
exámenes paraclínicos, etc.) que resulten de la valoración clínica
odontológica inicial y/o del seguimiento del paciente a través del tiempo.
NOTA SOBRE EL EXAMEN FÍSICO ODONTOLÓGICO Y EL ODONTOGRAMA:
Tanto el examen físico odontológico como el Odontograma son elementos básicos y
fundamentales desde el punto de vista clínico para el establecimiento del diagnóstico, el
plan de tratamiento y el seguimiento de la rehabilitación del paciente. Adicionalmente, y
no menos importante son las implicaciones legales que tiene el Odontograma como medio
de identificación de odontología forense. En XXXXXX, sin excepciones de ninguna índole,
todos los pacientes atendidos deben tener el registro completo de la Historia Clínica
incluyendo el diligenciamiento completo del Odontograma.
6. FORMATOS DE LA HISTORIA CLÍNICA.
La historia clínica está compuesta por tres partes:
Identificación del Usuario
Registros de la Atención.
Anexos.
Cada uno de los formatos mencionados a continuación se anexan al presente documento
y forman parte del mismo.
122
Historia Clínica (Apertura de Historia Clínica de Primera Vez)
Evolución del Tratamiento
Referencia y Contrarreferencia
Consentimiento Informado
Presupuesto Odontológico
(Recuerde que es solo un EJEMPLO del procedimiento
documentado y, por tanto, NO contiene los formatos
arriba mencionados, los cuales puede encontrarlos en
otros de los anexos de la Guía Práctica de
habilitación).
7. INSTRUCTIVOS DE LA HISTORIA CLÍNICA.
Cada uno de los formatos descritos en el numeral 6 tiene un instructivo para su
diligenciamiento, los cuales se anexan al presente documento y forman parte del mismo.
8. DILIGENCIAMIENTO DE LA HISTORIA CLÍNICA.
Para el diligenciamiento de la Historia Clínica el personal administrativo y los
profesionales odontólogos deben conocer los formatos establecidos en XXXXXXX, y los
instructivos correspondientes a dichos formatos. Para tales efectos, en la recepción y en
cada uno de los consultorios existirá una carpeta guía con los formatos en blanco y los
instructivos para consulta de los funcionarios correspondientes. El diligenciamiento de la
información general de la Historia Clínica, tal como: número de la historia, datos
personales del paciente, responsable y acompañante, pueden ser diligenciados por la
recepcionista y/o auxiliar de salud oral, mientras que los espacios destinados a la
información clínica (desde Causa de Consulta y Enfermedad Actual), solamente deben
ser diligenciados por el profesional odontólogo, quien realizaré el interrogatorio y el
examen al paciente.
9. USO DE LA HISTORIA CLÍNICA.
La Historia Clínica es un documento confidencial sometido a reserva y, por tanto, su uso
123
se restringe única y exclusivamente al personal asistencial odontológico de XXXXXX, y,
en aspectos restringidos únicamente al traslado, archivo y procesos de actualización y
conservación, al personal administrativo no asistencial quien deberá guardar la misma
reserva y confidencialidad de la Historia Clínica que el personal asistencial.
Tales
procesos administrativos se refieren en general a: archivo ordenado, registro de entradas
y salidas del mismo, foliada de hojas, organización en carpetas, marcación de carpetas,
distribución a los consultorios y transporte interno en XXXXXXX.
10. MANEJO DE LA HISTORIA CLÍNICA:
“Desde el punto de vista archivístico la historia clínica es un expediente que de manera
cronológica debe acumular documentos relativos a la prestación de servicios de salud
brindados al usuario”. El manejo aquí descrito se relaciona específicamente con el
proceso de archivo y movimiento de la Historia Clínica considerada como expediente, en
XXXXXX.
Archivo de Historias Clínicas. Las hojas, documentos, placas, diseños y demás
elementos de las Historias clínicas de XXXXXXX, serán dispuestas en un fólder con
gancho legajador; dicho fólder será marcado en la portada exterior con el número de la
Historia Clínica y el nombre del paciente (Apellidos y Nombres), y archivadas en un
mueble de archivo vertical colgante con cerradura con llave. Dicho mueble de archivo
estará situado en el área administrativa de XXXXXXX.
Registro de salida y entrada de Historias Clínicas. Para el registro de salida y entrada
de la Historia Clínica la recepcionista y/o auxiliar de salud oral llevará un formato en el
cual se diligencia la actividad realizada y se registra el documento correspondiente. Dicho
formato contendrá, como mínimo la siguiente información: Número de orden, Número de
la Historia Clínica, fecha de salida; hora de salida; destino de salida (consultorio y
profesional); firma del profesional que recibe la Historia; fecha de devolución; hora de
devolución; firma de la auxiliar-recepcionista que recibe la Historia devuelta; chequeo de
archivado en sitio del archivador. Este diligenciamiento es obligatorio y las planillas se
conservan en un fólder con legajador en el mismo archivador de las Historias Clínicas.
124
Foliación de Historias Clínicas. Las Historias Clínicas serán foliadas con números
arábigos consecutivos comenzando por la primera hoja diligenciada y continuando en
orden secuencial cronológico con las hojas subsiguientes.
Registro General de Historias Clínicas. Para asegurar y organizar la información básica
sobre los pacientes, registrada en la Historia Clínica, la entidad llevará un listado de las
Historias Clínicas de los pacientes atendidos que incluirá: Fecha de atención de primera
vez, número de Historia Clínica y apellidos y nombres del paciente. Esta misma
información se transcribirá progresivamente en una base de datos sistematizada (Excel)
con el objeto de hacerla más expedita para consulta de XXXXXXX.
11. ANEXOS ESPECÍFICOS DE LA HISTORIA CLÍNICA.
Los anexos específicos de la Historia Clínica de XXXXXXX, que constituyen el expediente
básico de la Historia, son: el formato de Historia Clínica de apertura de primera vez; el
formato de evolución del tratamiento; el formato de Consentimiento Informado y el formato
de Presupuesto Odontológico.
Fecha de elaboración
DD/MM/AAAA
Fecha de aprobación
DD/MM/AAAA
Fecha de actualización
DD/MM/AAAA
Aprobado por
Nombre del profesional que aprueba
Firma de aprobación:
_________________________________________________________
NOMBRE DE LA INSTITUCIÓN, REPRESENTANTE O PROFESIONAL
INDEPENDIENTE
Profesión, especialidad o cargo
125
ANEXO B.
Formato Historia Clínica Odontológica
126
127
ANEXO C.
Resolución Número 1995 de 1999 (Julio 8)
MINISTERIO DE SALUD
RESOLUCIÓN NÚMERO 1995 de 1999
(JULIO 8)
Por la cual se establecen normas para el manejo de la Historia Clínica
EL MINISTRO DE SALUD
En ejercicio de las facultades legales y en especial las conferidas por los artículos 1, 3, 4 y
los numerales 1 y 3 del artículo 7 del Decreto 1292 de 1994 y CONSIDERANDO
Que conforme al artículo 8 de la Ley 10 de 1990, al Ministerio de Salud le corresponde
formular las políticas y dictar todas las normas científico-administrativas, de obligatorio
cumplimiento por las entidades que integran el sistema de salud.
Que la Ley 100 de 1993, en su Artículo 173 numeral 2, faculta al Ministerio de Salud para
dictar las normas científicas que regulan la calidad de los servicios, de obligatorio
cumplimiento por parte de todas las Entidades Promotoras de Salud, los Prestadores de
Servicios de Salud del Sistema General de Seguridad Social en Salud y las direcciones
Seccionales, Distritales y Locales de Salud.
Que el Decreto 2174 de 1996, mediante el cual se organizó el Sistema Obligatorio de
Garantía de Calidad del Sistema General de Seguridad Social en Salud, en el numeral 4
del Artículo 5, estableció como uno de los objetivos del mismo, estimular el desarrollo de
un sistema de información sobre la calidad, que facilitara la realización de las labores de
auditoria, vigilancia y control y contribuyera a una mayor información de los usuarios.
Que la Historia Clínica es un documento de vital importancia para la prestación de los
servicios de atención en salud y para el desarrollo científico y cultural del sector.
Que de conformidad con el Artículo 35 de la Ley 23 de 1981, corresponde al Ministerio de
Salud implantar modelos relacionados con el diligenciamiento de la Historia Clínica en el
Sistema Nacional de Salud.
128
Que se hace necesario expedir las normas correspondientes al diligenciamiento,
administración, conservación, custodia y confidencialidad de las historias clínicas,
conforme a los parámetros del Ministerio de Salud y del Archivo General de la Nación en
lo concerniente a los aspectos archivísticos contemplados en la Ley 80 de 1989.
CAPÍTULO I
DEFINICIONES Y DISPOSICIONES GENERALES
ARTÍCULO 1.- DEFINICIONES.
a) La Historia Clínica es un documento privado, obligatorio y sometido a reserva, en el
cual se registran cronológicamente las condiciones de salud del paciente, los actos
médicos y los demás procedimientos ejecutados por el equipo de salud que interviene en
su atención. Dicho documento únicamente puede ser conocido por terceros previa
autorización del paciente o en los casos previstos por la ley.
b) Estado de salud: El estado de salud del paciente se registra en los datos e informes
acerca de la condición somática, psíquica, social, cultural, económica y medioambiental
que pueden incidir en la salud del usuario.
c) Equipo de Salud. Son los Profesionales, Técnicos y Auxiliares del área de la salud que
realizan la atención clínico asistencial directa del Usuario y los Auditores Médicos de
Aseguradoras y Prestadores responsables de la evaluación de la calidad del servicio
brindado.
d) Historia Clínica para efectos archivísticos: Se entiende como el expediente conformado
por el conjunto de documentos en los que se efectúa el registro obligatorio del estado de
salud, los actos médicos y demás procedimientos ejecutados por el equipo de salud que
interviene en la atención de un paciente, el cual también tiene el carácter de reservado.
e) Archivo de Gestión: Es aquel donde reposan las Historias Clínicas de los Usuarios
activos y de los que no han utilizado el servicio durante los cinco años siguientes a la
última atención.
129
f) Archivo Central: Es aquel donde reposan las Historias Clínicas de los Usuarios que no
volvieron a usar los servicios de atención en salud del prestador, transcurridos 5 años
desde la última atención.
e) Archivo Histórico. Es aquel al cual se transfieren las Historias Clínicas que por su valor
científico, histórico o cultural, deben ser conservadas permanentemente.
ARTÍCULO 2.- AMBITO DE APLICACIÓN.
Las disposiciones de la presente resolución serán de obligatorio cumplimiento para
todos los prestadores de servicios de salud y demás personas naturales o jurídicas que
se relacionen con la atención en salud.
ARTÍCULO 3.- CARACTERÍSTICAS DE LA HISTORIA CLÍNICA.
Las características básicas son:
Integralidad: La historia clínica de un usuario debe reunir la información de los aspectos
científicos, técnicos y administrativos relativos a la atención en salud en las fases de
fomento, promoción de la salud, prevención específica, diagnóstico, tratamiento y
rehabilitación de la enfermedad, abordándolo como un todo en sus aspectos biológico,
psicológico y social, e interrelacionado con sus dimensiones personal, familiar y
comunitaria.
Secuencialidad: Los registros de la prestación de los servicios en salud deben
consignarse en la secuencia cronológica en que ocurrió la atención. Desde el punto de
vista archivístico la historia clínica es un expediente que de manera cronológica debe
acumular documentos relativos a la prestación de servicios de salud brindados al usuario.
Racionalidad científica: Para los efectos de la presente resolución, es la aplicación de
criterios científicos en el diligenciamiento y registro de las acciones en salud brindadas a
un usuario, de modo que evidencie en forma lógica, clara y completa, el procedimiento
que se realizó en la investigación de las condiciones de salud del paciente, diagnóstico y
plan de manejo.
Disponibilidad: Es la posibilidad de utilizar la historia clínica en el momento en que se
necesita, con las limitaciones que impone la Ley.
130
Oportunidad: Es el diligenciamiento de los registros de atención de la historia clínica,
simultánea o inmediatamente después de que ocurre la prestación del servicio.
ARTÍCULO 4.- OBLIGATORIEDAD DEL REGISTRO.
Los profesionales, técnicos y auxiliares que intervienen directamente en la atención a un
usuario, tienen la obligación de registrar sus observaciones, conceptos, decisiones y
resultados de las acciones en salud desarrolladas, conforme a las características
señaladas en la presente resolución.
CAPÍTULO II
DILIGENCIAMIENTO
ARTÍCULO 5.- GENERALIDADES.
La Historia Clínica debe diligenciarse en forma clara, legible, sin tachones,
enmendaduras, intercalaciones, sin dejar espacios en blanco y sin utilizar siglas. Cada
anotación debe llevar la fecha y hora en la que se realiza, con el nombre completo y firma
del autor de la misma.
ARTÍCULO 6.- APERTURA E IDENTIFICACIÓN DE LA HISTORIA CLÍNICA.
Todo prestador de servicios de salud que atiende por primera vez a un usuario debe
realizar el proceso de apertura de historia clínica.
A partir del primero de enero del año 2000, la identificación de la historia clínica se hará
con el número de la cédula de ciudadanía para los mayores de edad; el número de la
tarjeta de identidad para los menores de edad mayores de siete años, y el número del
registro civil para los menores de siete años. Para los extranjeros con el número de
pasaporte o cédula de extranjería. En el caso en que no exista documento de identidad de
los menores de edad, se utilizará el número de la cédula de ciudadanía de la madre, o el
del padre en ausencia de ésta, seguido de un número consecutivo de acuerdo al número
de orden del menor en el grupo familiar.
131
PARÁGRAFO PRIMERO. Mientras se cumple el plazo en mención, los prestadores de
servicios de salud deben iniciar el proceso de adecuación correspondiente a lo ordenado
en el presente artículo.
PARÁGRAFO SEGUNDO. Todo prestador de servicios de salud debe utilizar una historia
única institucional, la cual debe estar ubicada en el archivo respectivo de acuerdo a los
tiempos de retención, y organizar un sistema que le permita saber en todo momento, en
qué lugar de la institución se encuentra la historia clínica, y a quien y en qué fecha ha sido
entregada.
ARTÍCULO 7.- NUMERACIÓN CONSECUTIVA DE LA HISTORIA CLINICA
Todos los folios que componen la historia clínica deben numerarse en forma consecutiva,
por tipos de registro, por el responsable del diligenciamiento de la misma.
ARTÍCULO 8.- COMPONENTES.
Son componentes de la historia clínica,
la identificación del usuario, los registros
específicos y los anexos.
ARTÍCULO 9.- IDENTIFICACIÓN DEL USUARIO.
Los contenidos mínimos de este componente son: datos personales de identificación del
usuario, apellidos y nombres completos, estado civil, documento de identidad, fecha de
nacimiento, edad, sexo, ocupación, dirección y teléfono del domicilio y lugar de residencia,
nombre y teléfono del acompañante; nombre, teléfono y parentesco de la persona
responsable del usuario, según el caso; aseguradora y tipo de vinculación.
ARTÍCULO 10.- REGISTROS ESPECÍFICOS.
Registro específico es el documento en el que se consignan los datos e informes de un
tipo determinado de atención. El prestador de servicios de salud debe seleccionar para
consignar la información de la atención en salud brindada al usuario, los registros
específicos que correspondan a la naturaleza del servicio que presta.
Los contenidos mínimos de información de la atención prestada al usuario, que debe
contener el registro específico son los mismos contemplados en la Resolución 2546 de
132
julio 2 de 1998 y las normas que la modifiquen o adicionen y los generalmente aceptados
en la práctica de las disciplinas del área de la salud.
PARAGRAFO PRIMERO. Cada institución podrá definir los datos adicionales en la
historia clínica, que resulten necesarios para la adecuada atención del paciente.
PARAGRAFO SEGUNDO. Todo prestador de servicios de salud debe adoptar mediante
el acto respectivo, los registros específicos, de conformidad con los servicios prestados en
su Institución, así como el contenido de los mismos en los que se incluyan además de los
contenidos mínimos los que resulten necesarios para la adecuada atención del paciente.
El prestador de servicios puede adoptar los formatos y medios de registro que respondan
a sus necesidades, sin perjuicio del cumplimiento de las instrucciones impartidas por las
autoridades competentes.
ARTÍCULO 11.- ANEXOS.
Son todos aquellos documentos que sirven como sustento legal, técnico, científico y/o
administrativo de las acciones realizadas al usuario en los procesos de atención, tales
como: autorizaciones para intervenciones quirúrgicas (consentimiento informado),
procedimientos, autorización para necropsia, declaración de retiro voluntario y demás
documentos que las instituciones prestadoras consideren pertinentes.
PARAGRAFO PRIMERO. Los reportes de exámenes paraclínicos podrán ser entregados
al paciente luego que el resultado sea registrado en la historia clínica, en el registro
especifico de exámenes paraclínicos que el prestador de servicios deberá establecer en
forma obligatoria para tal fin.
PARAGRAFO SEGUNDO. A partir de la fecha de expedición de la presente resolución,
en los casos de imágenes diagnósticas, los reportes de interpretación de las mismas
también deberán registrarse en el registro especifico de exámenes paraclínicos y las
imágenes diagnosticas podrán ser entregadas al paciente, explicándole la importancia de
ser conservadas para futuros análisis, acto del cual deberá dejarse constancia en la
historia clínica con la firma del paciente.
PARAGRAFO TERCERO. Los archivos de imágenes diagnosticas que hasta la fecha
existen en las Instituciones Prestadoras de servicios deberán conservarse de acuerdo a
133
los tiempos fijados en él artículo 15 de la presente resolución. Los prestadores de
servicios podrán efectuar la entrega de las imágenes que reposan en estos archivos, al
usuario, dejando constancia de ello en la historia clínica.
PARAGRAFO CUARTO. En todo caso el prestador de servicios será responsable de
estas imágenes, si no ha dejado constancia en la historia clínica de su entrega. Cuando
existiere esta constancia firmada por el usuario, será este último el responsable de la
conservación de las mismas.
CAPÍTULO III
ORGANIZACIÓN Y MANEJO DEL ARCHIVO DE HISTORIAS CLÍNICAS
ARTÍCULO 12.- OBLIGATORIEDAD DEL ARCHIVO.
Todos los prestadores de servicios de salud, deben tener un archivo único de historias
clínicas en las etapas de archivo de gestión, central e histórico, el cual será organizado y
prestará los servicios pertinentes guardando los principios generales establecidos en el
Acuerdo 07 de 1994, referente al Reglamento General de Archivos, expedido por el
Archivo General de la Nación y demás normas que lo modifiquen o adicionen.
ARTÍCULO 13.- CUSTODIA DE LA HISTORIA CLÍNICA.
La custodia de la historia clínica estará a cargo del prestador de servicios de salud que la
generó en el curso de la atención, cumpliendo los procedimientos de archivo señalados
en la presente resolución, sin perjuicio de los señalados en otras normas legales vigentes.
El prestador podrá entregar copia de la historia clínica al usuario o a su representante
legal cuando este lo solicite, para los efectos previstos en las disposiciones legales
vigentes.
PARÁGRAFO PRIMERO. Del traslado entre prestadores de servicios de salud de la
historia clínica de un usuario, debe dejarse constancia en las actas de entrega o de
devolución, suscritas por los funcionarios responsables de las entidades encargadas de
su custodia.
134
PARÁGRAFO SEGUNDO. En los eventos en que existan múltiples historias clínicas, el
prestador que requiera información contenida en ellas, podrá solicitar copia al prestador a
cargo de las mismas, previa autorización del usuario o su representante legal.
PARÁGRAFO TERCERO. En caso de liquidación de una Institución Prestadora de
Servicios de Salud, la historia clínica se deberá entregar al usuario o a su representante
legal. Ante la imposibilidad de su entrega al usuario o a su representante legal, el
liquidador de la empresa designará a cargo de quien estará la custodia de la historia
clínica, hasta por el término de conservación previsto legalmente. Este hecho se
comunicará por escrito a la Dirección Seccional, Distrital o Local de Salud competente, la
cual deberá guardar archivo de estas comunicaciones a fin de informar al usuario o a la
autoridad competente, bajo la custodia de quien se encuentra la historia clínica.
ARTÍCULO 14.- ACCESO A LA HISTORIA CLÍNICA.
Podrán acceder a la información contenida en la historia clínica, en los términos previstos
en la Ley:
1) El usuario.
2) El Equipo de Salud.
3) Las autoridades judiciales y de Salud en los casos previstos en la Ley.
4) Las demás personas determinadas en la ley.
PARÁGRAFO. El acceso a la historia clínica, se entiende en todos los casos, única y
exclusivamente para los fines que de acuerdo con la ley resulten procedentes, debiendo
en todo caso, mantenerse la reserva legal.
ARTÍCULO 15.- RETENCIÓN Y TIEMPO DE CONSERVACIÓN.
La historia clínica debe conservarse por un periodo mínimo de 20 años contados a partir
de la fecha de la última atención. Mínimo cinco (5) años en el archivo de gestión del
prestador de servicios de salud, y mínimo quince (15) años en el archivo central.
Una vez transcurrido el término de conservación, la historia clínica podrá destruirse.
135
ARTÍCULO 16.- SEGURIDAD DEL ARCHIVO DE HISTORIAS CLÍNICAS.
El prestador de servicios de salud, debe archivar la historia clínica en un área restringida,
con acceso limitado al personal de salud autorizado, conservando las historias clínicas en
condiciones que garanticen la integridad física y técnica, sin adulteración o alteración de
la información.
Las instituciones prestadoras de servicios de salud y en general los prestadores
encargados de la custodia de la historia clínica, deben velar por la conservación de la
misma y responder por su adecuado cuidado.
ARTÍCULO 17.- CONDICIONES FÍSICAS DE CONSERVACIÓN DE LA HISTORIA
CLÍNICA.
Los archivos de historias clínicas deben conservarse en condiciones locativas,
procedimentales, medioambientales y materiales, propias para tal fin, de acuerdo con los
parámetros establecidos por el Archivo General de la Nación en los acuerdos 07 de 1994,
11 de 1996 y 05 de 1997, o las normas que los deroguen, modifiquen o adicionen.
ARTÍCULO 18.- DE LOS MEDIOS TÉCNICOS DE REGISTRO Y CONSERVACIÓN DE
LA HISTORIA CLÍNICA.
Los Prestadores de Servicios de Salud pueden utilizar medios físicos o técnicos como
computadoras y medios magneto-ópticos, cuando así lo consideren conveniente,
atendiendo lo establecido en la circular 2 de 1997 expedida por el Archivo General de la
Nación, o las normas que la modifiquen o adicionen.
Los programas automatizados que se diseñen y utilicen para el manejo de las Historias
Clínicas, así como sus equipos y soportes documentales, deben estar provistos de
mecanismos de seguridad, que imposibiliten la incorporación de modificaciones a la
Historia Clínica una vez se registren y guarden los datos.
En todo caso debe protegerse la reserva de la historia clínica mediante mecanismos que
impidan el acceso de personal no autorizado para conocerla y adoptar las medidas
tendientes a evitar la destrucción de los registros en forma accidental o provocada.
136
Los prestadores de servicios de salud deben permitir la identificación del personal
responsable de los datos consignados, mediante códigos, indicadores u otros medios que
reemplacen la firma y sello de las historias en medios físicos, de forma que se establezca
con exactitud quien realizó los registros, la hora y fecha del registro.
CAPÍTULO IV
COMITÉ DE HISTORIAS CLÍNICAS
ARTÍCULO 19.- DEFINICIÓN.
Defínase el comité de historias clínicas como el conjunto de personas que al interior de
una Institución Prestadora de Servicios de Salud, se encarga de velar por el cumplimiento
de las normas establecidas para el correcto diligenciamiento y adecuado manejo de la
historia clínica.
Dicho comité debe establecerse formalmente como cuerpo colegiado o mediante
asignación de funciones a uno de los comités existentes en la Institución.
PARÁGRAFO. El comité debe estar integrado por personal del equipo de salud. De las
reuniones, se levantarán actas con copia a la dirección de la Institución.
ARTÍCULO 20.- FUNCIONES DEL COMITÉ DE HISTORIAS CLÍNICAS.
a) Promover en la Institución la adopción de las normas nacionales sobre historia clínica y
velar porque estas se cumplan.
b) Elaborar, sugerir y vigilar el cumplimiento del manual de normas y procedimientos de
los registros clínicos del Prestador, incluida la historia clínica.
c) Elevar a la Dirección y al Comité Técnico-Científico, recomendaciones sobre los
formatos de los registros específicos y anexos que debe contener la historia clínica, así
como los mecanismos para mejorar los registros en ella consignados.
d) Vigilar que se provean los recursos necesarios para la administración y funcionamiento
del archivo de Historias Clínicas.
137
ARTICULO 21. - SANCIONES.
Los Prestadores de Servicios de Salud que incumplan lo establecido en la presente
resolución, incurrirán en las sanciones aplicables de conformidad con las disposiciones
legales vigentes.
ARTÍCULO 22.- VIGENCIA.
La presente Resolución rige a partir de la fecha de su publicación y deroga las
disposiciones que le sean contrarias.
VIRGILIO GALVIS RAMÍREZ
Ministro de Salud
138
ANEXO D.
Encuesta pacientes
1. ¿Desde hace cuánto tiempo acude al consultorio odontológico?
2. ¿Qué tipo de tratamiento le realizan?
3. ¿Cada vez que pide una cita en qué forma lo hace?
4. ¿Hay alguna manera en que le recuerden la fecha y hora de su próxima cita?
5. ¿Le parece adecuado el tiempo que dura su consulta?
6. ¿Cada cuánto debe asistir al consultorio?
7. ¿Alguna vez ha solicitado su historia clínica? ¿esta información es entregada a tiempo
o que problema ha tenido para obtenerla?
139
8. ¿Está conforme con el proceso que se lleva actualmente en el consultorio odontológico
para pedir su próxima cita?
9. ¿Cree que si pudiera agendar su próxima cita odontológica por medio de una página
en internet sería más como y rápido? ¿Por qué?
10. ¿Para el proceso de registrarse como paciente nuevo cree que es necesario una foto
para almacenar en su registro?
11. ¿Los horarios y los días de atención que maneja el consultorio son adecuados para
usted como paciente?
12. ¿Le gustaría que le recordaran con un mensaje de texto a su celular la fecha y hora
de su próxima cita?
13. ¿Le gustaría que al usar la página web del consultorio pueda consultar los horarios,
fechas y odontólogos disponibles a los cuales usted desee acudir?
140
14. ¿Cuándo no puede acudir a una cita en que forma la cancela?
15. ¿Para su comodidad desearía que se puedan cancelar citas por medio de la página
web del consultorio?
16. ¿Si necesitan actualizar sus datos tiene que acudir al consultorio? ¿De qué otra
forma lo hace?
17. ¿Le parecería buena la opción de actualizar sus datos por medio de la página web
del consultorio en vez de usar los métodos que anteriormente menciono?
18. ¿Qué información de los odontólogos y del consultorio le gustaría encontrar en la
página web?
141
ANEXO E.
Resultados de las encuestas
Al término del desarrollo de las etapas de este proyecto se presenta un análisis sobre la
información obtenida por medio de las encuestas realizadas.
Para generar el análisis a estos resultados se agruparon las preguntas de tal manera que
las respuestas se lograran combinar en una misma gráfica.
1. ¿Desde hace cuánto tiempo acude al consultorio odontológico?
14. ¿Cuándo no puede acudir a una cita en que forma la cancela?
Gráfica 1. Resultados Encuesta – Preguntas 1 y 14.
Ver punto 5.2.1. Levantamiento de Información.
La gráfica 1 muestra que la mayoría de los encuestados acuden al consultorio
odontológico aproximadamente entre 1 y 5 años, las demás personas acuden entre 6 y 15
años. En la pregunta 14 el 50% de los encuestados cuando no pueden asistir a una cita la
cancelan en telefónicamente o en el consultorio.
142
3. ¿Cada vez que pide una cita lo hace telefónicamente?
4. ¿Hay alguna manera en que le recuerden la fecha y hora de su próxima cita?
5. ¿Le parece adecuado el tiempo que dura su consulta?
7. ¿Alguna vez ha solicitado su historia clínica? ¿esta información es entregada a tiempo
o que problema ha tenido para obtenerla?
Gráfica 2. Resultados Encuesta – Preguntas 3, 4, 5 y 7.
Ver punto 5.2.1. Levantamiento de Información.
En la gráfica 2 se muestra que para la pregunta 3 todos los pacientes encuestados cada
vez que piden una cita lo hacen de manera telefónica. En la pregunta 4 casi siempre hay
alguna manera que a los pacientes se les recuerda su próxima cita.
8. ¿Está conforme con el proceso que se lleva actualmente en el consultorio odontológico
para pedir su próxima cita?
9. ¿Cree que si pudiera agendar su próxima cita odontológica por medio de una página
en internet sería más como y rápido? ¿Por qué?
10. ¿Para el proceso de registrarse como paciente nuevo cree que es necesario una foto
para almacenar en su registro?
11. ¿Los horarios y los días de atención que maneja el consultorio son adecuados para
usted como paciente?
143
Gráfica 3. Resultados Encuesta – Preguntas 8, 9, 10 y 11.
Ver punto 5.2.1. Levantamiento de Información.
En la gráfica 3 se muestra que para la pregunta 8 el 50 % de los pacientes encuestados
están conformes con el proceso que se lleva para pedir su próxima cita. En la pregunta 9
el 90% de los encuestados piensan que es más rápido y cómodo agendar su próxima cita
por medio de una página de internet. Para las preguntas 10 y 11 el
50% de los
encuestados creen que no es necesario almacenar una fotografía en su registro y que los
horarios y días que maneja el consultorio son adecuados.
12. ¿Le gustaría que le recordaran con un mensaje de texto a su celular la fecha y hora
de su próxima cita?
13. ¿Le gustaría que al usar la página web del consultorio pueda consultar los horarios,
fechas y odontólogos disponibles a los cuales usted desee acudir?
15. ¿Para su comodidad desearía que se puedan cancelar citas por medio de la página
web del consultorio?
16. ¿Si necesitan actualizar sus datos tiene que acudir al consultorio? ¿De qué otra
forma lo hace?
17. ¿Le parecería buena la opción de actualizar sus datos por medio de la página web
del consultorio en vez de usar los métodos que anteriormente mencionó?
144
Gráfica 4. Resultados Encuesta – Preguntas 12, 13, 15, 16 y 17.
Ver punto 5.2.1. Levantamiento de Información.
En la gráfica 4 se muestra que para las preguntas 12 y 13 el 100 % de los pacientes
encuestados les gustaría que les recordaran su próxima cita con un mensaje de texto a su
celular y además poder consultar en la página web los horarios, fechas y odontólogos
disponibles. Igualmente la totalidad de los encuestados respondieron que para su
comodidad desearían cancelar una cita por medio de la página web y que para actualizar
sus datos tienen que asistir al consultorio.

El formato de la encuesta realizada a los pacientes se encuentra en el anexo D.

La ficha técnica y resultados de las encuestas se pueden ver en el anexo F.
145
ANEXO F.
Ficha técnica y resultados encuestas
Ficha técnica de la encuesta para la implementación de un aplicativo web que permita la
administración de citas e historias en un consultorio odontológico, la cual facilitará la
administración concurrente y distribuida de la información de los pacientes.
1. Realizada por: Natalia Londoño Ospina, Johanna Maritza Bolaños Barrios.
2. Universo: Bogotá D.C.
3. Unidad de Muestreo: Personas.
4. Fecha: Julio de 2010.
5. Área de Cobertura: Pacientes consultorio odontológico
6. Tipo de Muestreo: Aleatorio.
7. Técnica de Recolección de Datos: Encuesta personal y encuesta correo electrónico.
8. Tamaño de la Muestra: 10 (Diez) Personas.
9. Objeto de le Encuesta: Identificar la importancia de desarrollar una aplicación que
permita administrar de manera eficiente la información odontológica de los pacientes.
Asimismo dicha encuesta es necesaria para llevar a cabo el proceso de levantamiento de
información para determinar los requerimientos funcionales y no funcionales del sistema.
10. Número de Preguntas Formuladas: 18 (Dieciocho) Preguntas.
146
ANEXO G.
Entrevista Odontóloga
Nombre: Deisy Marcela Torres.
Fecha: 22 julio de 2010
Rol: Odontóloga.
1. ¿Desde hace cuanto tiempo funciona el consultorio?
15 años.
2. ¿Cómo se almacena actualmente la información de los pacientes?
Diseño de Historia clínica en Excel.
3. ¿Actualmente de que manera diligencian las historias clínicas?
Se almacena la información en Excel, en un diseño que el esposo creó.
4. ¿Qué procesos realizan de forma manual?
La secretaria de salud exige las historias clínicas de forma manual y los
inventarios.
5. ¿Manejan formularios para el almacenamiento de la información de cada
paciente?
No.
6. ¿Qué tipo de información almacenan en las historias clínicas?
Manejan protocolos ANAMNESIS (identificación, antecedentes médicos,
antecedentes odontológicos, odontograma, diagnostico, plan de tratamiento,
cotización, imágenes y control de pagos.
147
7. ¿Cuál es el proceso que llevan a cabo desde el momento en que un paciente
solicite su cita?
Agenda en la herramienta de office Outlook y se anota el nombre y el
teléfono del paciente.
8. ¿Qué información hay que sistematizar?
La historia clínica odontológica y los inventarios.
9. ¿Se crea historia clínica para todos los pacientes que visitan el consultorio?
A todos los pacientes se crea una historia clínica odontológica.
10. ¿Qué datos se obtienen de los pacientes nuevos?
Nombre, teléfono y dirección.
11. ¿De qué manera se otorgan las citas?
Dependiendo de los pacientes y la urgencia.
12. ¿Qué modalidades de citas manejan?
Ninguna.
13. ¿Tienen prioridades a la hora de otorgar citas?
Ninguna prioridad a menos que sea una urgencia.
14. ¿Cuántos médicos hay en el consultorio?
148
Una solo ella.
15. ¿Cómo se cancelan las citas en caso de que el paciente no pueda asistir?
Se llama para confirmar o cancelar.
16. ¿Imponen alguna sanción en caso de que el paciente no asista?
No ninguna.
17. ¿Qué lapso de tiempo existe entre cada cita?
30 minutos.
18. ¿A la historia clínica le adjuntan la fotografía del paciente?
Si pero no todos los pacientes la tienen.
19. ¿Tiene alguna clase de convenios con empresas o E.P.S?
No ningún convenio.
20. ¿Qué opina del sistema que utilizan actualmente para el manejo de las historias
clínicas?
Le parece fácil aunque no se involucre con el manejo de la herramienta.
21. ¿Qué ventajas y desventajas tiene frente al sistema que manejan?
Las ventajas es que otra persona le ayuda en el almacenamiento de la
información, ya que ella no se involucra demasiado en usar Excel.
22. ¿Cuáles son las características con las cuales debería contar la aplicación?
149
Fácil de aprender y usar, que muestre la información de forma clara y que no
sea tedioso el aprendizaje de funcionamiento de la aplicación.
23. ¿Le gustaría que en su consultorio se implementara una aplicación para la
administración de citas e historias odontológicas? ¿por qué?
Si es fácil, si le gustaría una nueva forma de administrar las citas e historias
odontológicas.
JOHANNA BOLAÑOS
DEISY MARCELA TORRES
FIRMA ENCUESTADOR
FIRMA ENCUESTADO
150
FECHA
25-11-2010
NÚMERO RAE
PROGRAMA
INGENIERÍA DE SISTEMAS
AUTOR (ES)
BOLAÑOS BARRIOS, Johanna; LONDOÑO OSPINA, Natalia.
TÍTULO
IMPLEMENTACIÓN DE UN APLICATIVO WEB EN PLATAFORMA J2EE PARA LA
ADMINISTRACIÓN DE CITAS E HISTORIAS ODONTOLÓGICAS
PALABRAS CLAVES
DESCRIPCIÓN
J2EE (Java 2 Enterprise Edition)
JSP (Java Server Pages)
JAVABEAN
HISTORIA CLÍNICA
La aplicación web se desarrollará en la plataforma J2EE (Java 2 Enterprise
Edition) la cual se basa en una estructura multicapa para el desarrollo de
los sistemas. El aplicativo contará con SMS (Short Message Service),
servicio por medio del cual se utiliza el sitio web para enviar a través de
internet un mensaje al teléfono móvil de cada paciente, recordando el día
y la hora de su próxima cita odontológica. Adicionalmente la
implementación se hará con un servidor de aplicaciones Java, llamado
Apache Tomcat. Este estándar permite el desarrollo de aplicaciones de
151
una manera eficiente y versátil.
FUENTES BIBLIOGRÁFICAS
ARIZA, Lina. Panorámica del software libre en Colombia. En
Sistemas. Septiembre-Noviembre, 2004, vol.90.
AVELLANAL DURANTE, Ciro, Diccionario Odontológico.
Buenos Aires: Mundi, 1961.
DEBRAUER, LAUREN Y VAN DER HEIDE, FIEN UML2,
Ediciones ENI. Barcelona 2009. 245 p.
DEITEL, Harvey y Deitel Paul. Como Programar en Java.
México: Pearson Prentice Hall, 2004. 1268 p.
FALGUERAS CAMPDERRICH, BENET, Ingeniería del Software,
Editorial UOC. Barcelona 2003. 314 p.
JACOBSON, Ivar; Booch, Grady; Rumbaugh James. El proceso
de desarrollo de software, Addison-Wesley , 1999.
PRESSMAN S. Roger. Ingeniería del software un enfoque
práctico. México: Mc Graw Hill, 2006. 958 p.
RODRIGUEZ ALMEIDA, Miguel Ángel. Bases de Datos, Mc.
Graw Hill. P257.
SOMMERVILLE, Ian. Ingeniería del software.
Madrid:
Pearson Educación. S.A., 2005. 712 p.
TUYA Javier, RAMOS ROMAN Isabel, DOLADO COSIN Javier,
Técnicas Cuantitativas Para La Gestión En La Ingeniería del
152
Software, Editores NETBIBLO, España 2007, 325 p.
WEITZENFELD, Alfredo. Ingeniería de software orientada a
objetos con Uml. Java e internet. México: Thomson, 2005.
678 p.
153
NÚMERO RAE
PROGRAMA
CONTENIDOS
INGENIERÍA DE SISTEMAS
OBJETIVOS
Objetivo General.
Implementar un aplicativo web en
plataforma J2EE para la administración de citas e historias
odontológicas.
Objetivos Específicos.
 Analizar los requerimientos funcionales y no funcionales
para la administración de citas e historias odontológicas.
 Modelar una base de datos que permita almacenar toda la
información relacionada con los pacientes del consultorio.
 Desarrollar un módulo de autenticación (seguridad) que
permita sólo el acceso a personas del consultorio que se
encuentran registradas.
 Diseñar el software para la aplicación en plataforma J2EE que
cumpla con el estándar UML (Unified Modeling Language) para
generar un software de calidad.
 Diseñar las interfaces gráficas para el software y el
odontograma.
 Implementar
el
software
mediante
un
servidor
de
aplicaciones que permita la interacción con los usuarios (médico
o asistente) del consultorio.
 Realizar pruebas de aceptación para determinar si el
software cumple con los requerimientos especificados.
154
Alcances. El proyecto culmina con la implementación de la
aplicación web y con las pruebas aceptación que se realizarán
para determinar si esta cumple con los requerimientos
especificados.
Esta aplicación contará con varios menús en los que se puede
encontrar el paciente con toda su información personal y de
contacto. Tendrá un odontograma, en el cual se puede detallar
ordenadamente según la secuencia de los dientes el índice COP
(Cariado, Obturado y Perdido) que pueda estar presente en
algunos de los dientes.
Permitirá crear citas semanales asignando cada una de ellas en
un lapso de treinta minutos y donde se puede consultar
disponibilidad de odontólogos y horarios. Un valor adicional con
el que contará la aplicación web es el SMS, servicio por medio
del cual se puede enviar a través de internet un mensaje al
teléfono móvil de cada paciente, recordando el día y la hora de
su próxima cita odontológica.
NÚMERO RAE
PROGRAMA
INGENIERÍA DE SISTEMAS
155
METODOLOGÍA
ENFOQUE DE LA INVESTIGACIÓN
Empírico-analítico:
orientado
a
la
interpretación
y
transformación del mundo material, que se realiza con el fin de
implementar un aplicativo web en plataforma J2EE para que los
consultorios odontológicos puedan administrar las citas e
historias.
Línea de investigación de usb. Tecnologías actuales y sociedad.
Sub-línea de facultad. Sistemas de información y comunicación.
Campo temático del programa. Desarrollo de software.
Metodología de Desarrollo de Software.
Para alcanzar los
objetivos propuestos en el desarrollo del aplicativo web se
escogió la siguiente metodología que servirá para dar respuesta
al problema que se ha planteado. Según Alfredo Weitzenfeld “El
modelo de cascada se define como una secuencia de
actividades, donde la estrategia principal es seguir el progreso
del software hacia puntos de revisión bien definidos mediante
entregas calendarizadas”.
De acuerdo a la metodología mencionada, las principales etapas
de este modelo se transforman en actividades fundamentales de
desarrollo y son: Análisis y definición de requerimientos, Diseño
del sistema y del software, Implementación y prueba de
unidades, Integración y pruebas del sistema, Funcionamiento y
mantenimiento.
156
CONCLUSIONES
Los requerimientos obtenidos son la base para empezar a
construir el software de acuerdo a las necesidades del usuario
final, estos ayudan a establecer las entradas, procesos y salidas
que el aplicativo debe generar para su buen funcionamiento.
El modelo de la base de datos permitió construir una
representación gráfica de las entidades, atributos y relaciones
con las que cuenta el aplicativo. Este diseño facilitó que la
información guardada funcione de una manera integral en el
sistema, haciendo que esta no sea redundante y repetitiva.
La autenticación de los usuarios que ingresan al sistema se hizo
por medio de la identificación de los privilegios con los que
cuenta cada uno. Se establece un usuario y contraseña para
restringir el acceso a personas que no están autorizadas para el
uso de los servicios con los que el aplicativo cuenta.
Se diseñó el software basado en un escenario web que se
trabaja en la plataforma J2EE, para llegar a este diseño se
crearon los diagramas de casos de uso, secuencia, clases y
actividades; los cuales son establecidos por el estándar UML.
Las interfaces gráficas y el odontograma se diseñaron con el
motor de desarrollo dreamweaver que permite combinar los
diseños en HTML e integrarlos en el código java. El odontograma
es un diseño ya establecido para la representación de las
características de los dientes del ser humano, se incluye esta
representación para una persona adulta o un niño sobre los
cuales se deben señalar las patologías que tienen o tratamientos
que se deben realizar a los pacientes.
Las pruebas permitieron detectar los errores y fallas
identificadas a lo largo del desarrollo del proyecto; a partir de
157
estas se corrigieron para hacer entrega de un software que
cumple con los requerimientos planteados.
158