implementaciÓn de un aplicativo web en plataforma j2ee …

0

IMPLEMENTACIÓN DE UN APLICATIVO WEB EN PLATAFORMA J2EEPARA LA ADMINISTRACIÓN DE CITAS E HISTORIAS ODONTOLÓGICAS

JOHANNA MARITZA BOLAÑOS BARRIOSNATALIA LONDOÑO OSPINA

UNIVERSIDAD DE SAN BUENAVENTURAFACULTAD DE INGENIERÍAINGENIERÍA DE SISTEMAS

BOGOTÁ D.C.2010

1

IMPLEMENTACIÓN DE UN APLICATIVO WEB EN PLATAFORMA J2EEPARA LA ADMINISTRACIÓN DE CITAS E HISTORIAS ODONTOLÓGICAS

JOHANNA MARITZA BOLAÑOS BARRIOSNATALIA LONDOÑO OSPINA

Proyecto de grado como requisito para optar por el título de Ingeniero de Sistemas.

ASESOREMILIO BARAJAS

INGENIERO DE SISTEMAS

UNIVERSIDAD DE SAN BUENAVENTURAFACULTAD DE INGENIERÍAINGENIERÍA DE SISTEMAS

BOGOTÁ D.C.2010

2

Nota de aceptación

_________________________

_________________________

_________________________

_________________________Presidente del Jurado

_________________________Firma del Jurado

_________________________Firma del jurado

Bogotá D.C., Noviembre de 2010

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

LISTA DE ANEXOS

ANEXO A. Ejemplo de procedimiento institucional documentado para el uso y manejo dela 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

13

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.

14

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>, Mayo15 de 2010. 8:30pm.3 Dental Pro, [artículo en línea] Disponible desde Internet en: <http://www.digitalab-software.com/consultorio>, Mayo 15de 2010. 8:40pm.

15

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ónde 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 15de 2010. 9:30pm.

16

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

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

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

17

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

18

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.

19

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.

20

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.

21

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.

22

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.

23

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.

24

Tabla 2. Metodologías de Desarrollo de Software.

METODOLOGÍAS FASES DEFINICIÓN TIEMPO DEEJECUCIÓN

MANTENIMIENTO

RUP

• Inicio• Elaboración• Construcción• Transmisión• Mantenimiento• Planificación.

El método RUP específica,principalmente, la constitución delequipo y las escalas de tiempo, asícomo un numero de modelos dedocumento

6 meses El mantenimiento esinmediato.

EXTREME PROGRAMING (XP)

• Planificación• Diseño• Desarrollo• Pruebas

La metodología consiste en unaprogramación rápida o extrema, cuyaparticularidad es tener como parte delequipo al usuario final pues uno de losrequisitos para llegar al éxito delproyecto

3 meses El mantenimiento esinmediato.

DESARROLLO GUIADO PORLA FUNCIONALIDAD O FDD

• Mantenimiento• Muerte del proyecto• Desarrollo de un modelo general.• Construcción• Plan de raleases e• Diseñar• Implementar

FDD establece algunas medidas útilesque son muy importantes para ladirección de la empresa y muestran elestado actual del desarrollo y realizar,en el futuro, mejores estimaciones.

Tiempo de desarrollocorto, es decir, menosde un año. El mantenimiento es

inmediato.

CICLO DE VIDA

• Análisis• Diseño• Codificación• Pruebas e integración• Operación y Mantenimiento

Conjunto de fases por las que pasa elsistema que se está desarrollandodesde que nace la idea inicial hasta queel software es retirado o reemplazado(“muere”).

Mediano Plazo El mantenimiento esinmediato.

MODELO EN CASCADA

•Análisis• Diseño• Implementación y pruebas• Integración y pruebas• Funcionamiento y Mantenimiento

Ssecuencia de actividades, donde laestrategia principal es seguir el progresodel software hacia puntos de revisiónbien definidos mediante entregascalendarizadas.

Mediano Plazo El mantenimiento esinmediato.

25

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.

26

Tabla 3. Servidor de Aplicaciones.

SERVIDOR DE APLICACIONES CARÁCTERÍSTICAS DEFINICIÓN

WEBLOGIC

Puede utilizar Oracle, DB2, Microsoft SQL Server,y otras bases de datos que se ajusten al estándarJDBC. El servidor WebLogic es compatible conWS-Security y cumple con los estándares de J2EE1.3 desde su versión 7 y con la J2EE 1.4 desde suversión 9 y Java EE para las versiones 9.2 y 10.x

Servidor de aplicaciones Java EE y también un servidor web HTTP.

EAServer

Un motor de ejecución escalable e independientede la plataforma.

Soporte de "stubs" y "proxys" para los principalesmodelos de componentes, incluyendo JavaBeans,PowerBuilder, Java, ActiveX, y C/C++

Soporte a HTML dinámico usando Servlets Java yJava Server Pages(JSP)

Soporte a la plataforma de desarrollo Java 2Enterprise Edition (J2EE).

Servidor de aplicaciones, el cual incluye un conjunto integrado de herramientasque se usan para crear y ejecutar aplicaciones Web con soporte a altos nivelesde tráfico, contenido dinámico y procesamiento intensivo de transacciones enlínea.

GLASSFISH

Modularidad.

Tiempo mejorado de inicio.

Despliegues desde plugins en NetBeans y Eclipse,y preservación de sesiones a través deredespliegues.

Servidor de aplicaciones desarrollado por Oracle Corporation que implementa lastecnologías definidas en la plataforma Java EE y permite ejecutar aplicacionesque siguen esta especificación.

TOMCAT

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.

Servidor web con soporte de servlets y JSPs. Tomcat incluye el compiladorJasper, que compila JSPs convirtiéndolas en servlets.

27

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>, Marzo25 de 2010. 6:10pm.

28

Tabla 4. Motor de Base de Datos.

MOTOR DE BASE DE DATOS MODELOSDE DATOS

CARACTERISTICAS HERRAMIENTAS SEGURIDAD

ORACLE

Relacional Soporte detransacciones.

Estabilidad. Escalabilidad. Multiplataforma.

Patrón de consulta Agrupamiento de datos Subconsultas Índices

Seguridad de cuentas para la validación deusuarios.

Seguridad en el acceso a los objetos de labase de datos.

Seguridad a nivel de sistema para lagestión de privilegios globales.

SQL SERVER

Relacional Flexibilidad ypotencia de lossistemasrelacionales.

Lenguaje de altonivel y no deprocedimiento.

Configuración de cliente Monitor de

funcionamiento Sql Server Profiler Analizador de Queries

Un único ID de login tanto para red comopara la DB para mejorar la seguridad yfacilitar la administración.

Password y encriptación de datos en redpara mejorar la seguridad.

Encriptación de procedimientosalmacenados para la integridad yseguridad de código de aplicación.

POSTGRES

Relacional Aproxima los datos aun modelo objeto-relacional, y escapaz de manejarcomplejas rutinas yreglas.

Soporta integridadreferencial, la cuales utilizada paragarantizar la validezde los datos de labase de datos.

PgAdmin3 : entorno deescritorio Visual

PgAccess : entorno deescritorio Visual

PhpPgAdmin : entornoWeb

psql : cliente de consola

Protección de los ficheros de la base dedatos.

Las conexiones de los clientes al servidorde la base de datos están permitidas, pordefecto.

Las conexiones de los clientes se puedenrestringir por dirección IP y/o por nombrede usuario mediante el ficheropg_hba.conf situado en PG_DATA.

MYSQL

Relacional Aprovecha lapotencia desistemasmultiprocesador.

Soporta grancantidad de tipos dedatos paracolumnas.

Gestión de usuariosy passwords.

Gran portabilidadentre sistemas.

TurboDbAdmin EMS SQL Manager for

MySQL MySQL GUI Tools phpMyAdmin Instant SQL Formatter DB Designer 4 WWW SQL Designer

MySQL Network Scanner: Este programapermite auditar una red de clase C enbusca de servidores MySQL que notengan definida una contraseña para elusuario root.

MySQL Brute Force Password HashCracker: Esta utilidad, complementaria a laanterior, admite como argumento el hashde una contraseña de un usuario deMySQL y, mediante fuerza bruta, intentarádescifrarlo.

29

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.

30

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.

31

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, SunMicrosystem 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 5de 2010, 2:23 p.m.13 Definición SMS, [artículo en línea] Disponible desde internet en: <http://www.sitiosespana.com/notas/febrero-2005/QUE-ES-SMS.htm>, Octubre 5 de 2010, 2:23 p.m.

32

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).

33

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.

34

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.

35

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.

36

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.


37

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.

38

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.


39

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

40

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

41

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.

Curso normal de eventos

1. Se presenta al usuario una pantalla principal en dondese encuentra un link para cada perfil.

2. Si el usuario es un paciente y no se encuentraregistrado, encontrará un link para hacer el debidoregistro.

3. Si la actividad seleccionada es registrarse el sistemapide los siguientes datos: primer apellido, segundoapellido, 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 ycontraseña después del registro.

5. El Administrador es el único que puede registrar a unodontólogo o asistente y para este fin realiza el evento3.

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ónrequerida.

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.


1. El usuario ingresa su usuario y contraseña

42

Curso normal de eventos insertados por pantalla.

2. Una vez autenticado el usuario puede acceder alos 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 muestraun mensaje en pantalla que los datos no son correctos y debeescribirlos 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

ObjetivoOfrecer 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 dondeencuentra un link llamado paciente.

2. El usuario ingresa la identificación del paciente. Si elpaciente se encuentra registrado puede consultar ocrear la historia en donde deberá llenar las seccionescon las cuales esta cuenta y vuelve a la páginaprincipal.

3. Después de crear la historia aparecen todas lassecciones en pantalla pero la única que puedemodificar es la evolución de la salud oral. Después dehaber realizado la actualización se guardan loscambios.

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 casode uso autenticar usuario.

Para actualizar se debe haber ejecutado el caso de uso crear

43

historia.

Flujo alternativo de eventos Si el número de documento del paciente no se encuentra en labase 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

ObjetivoOfrecer a los usuarios permitidos las opciones de solicitar,consultar o cancelar una cita.


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 deodontólogos en donde puede escoger el que desee yun botón que muestra la lista semanal de horarios conla fecha y hora disponibles. Este registro se guarda enla base de datos.

3. Cuando pide la cita aparecen en pantalla los datos deesta.

4. Si el usuario desea consultar una cita, debe haber sidocreada y muestra los datos de esta, si la cita no hasido creada aparece un mensaje informando el estadode la cita.

5. Si escoge cancelar la cita que ya existe se borrará lacita creada y vuelve a quedar disponible el horario quehabía escogido.

6. Si la actividad seleccionada es cerrar sesión volverá ala página principal.

Precondiciones El Administrador, Odontólogo, Asistente y Paciente debenhaber ejecutado el caso de uso autenticar usuario.

Para cancelar una cita ya debe haber sido solicitada.

44

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

ObjetivoPermitir a todos los usuarios del sistema actualizar susrespectivos datos básicos.



1. Se presenta al usuario una pantalla en donde puedeescoger la opción de actualizar los datos.

2. Si el usuario escoge actualizar solo puede cambiar lossiguientes datos: ocupación, dirección, teléfono,celular y contraseña. Para cada uno aparece un linkpara editar.


PrecondicionesTodos los usuarios deben haber ejecutado los casos de usoregistrar y autenticar usuario.

Flujo alternativo de eventos Si en el momento de editar un campo el usuario no escoge laopció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

ObjetivoConsultar en la base de datos la información que el usuariodesee.

Actores Administrador, Odontólogo.

1. Se presenta una opción en donde se encuentra el

45


listado de reportes disponibles para los usuarios.

2. El usuario ingresa fecha y/o cédula y el sistemaverifica si esta es válida.

3. El sistema muestra en pantalla todos los registrosencontrados.

4. Si la actividad seleccionada es regresar volverá a lasesión iniciada por el odontólogo.

PrecondicionesEl Administrador u Odontólogo deben haber ejecutado el casode uso autenticar usuario.

Flujo alternativo de eventos Si los datos de ingreso no son válidos el sistema no muestraningún reporte.

Pos condiciones Visualización del reporte.

Tabla 11. Descripción Caso de Uso Cerrar Sesión.

Caso de uso Cerrar Sesión

ObjetivoDar por terminada las actividades que el usuario estárealizando en el sistema.



1. Se muestra en pantalla un botón cerrar sesión.

2. El usuario vuelve a la página principal. Si deseaingresar nuevamente debe autenticarse.

PrecondicionesLos usuarios deben haber ejecutado el caso de uso autenticarusuario.


Pos condiciones Salir del sistema y volver a la pantalla principal.

46

Figura 5. Diagrama Caso de Uso Administrador.

47

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.

2. El usuario debe escoger la fecha, la hora y elodontólogo disponible para asignar la cita; y seguardan los cambios en la base de datos.


48

PrecondicionesEl usuario debe haber ejecutado el caso de uso autenticarusuario.

Flujo alternativo de eventos Si el usuario no escoge la fecha, hora y odontólogo la cita nose 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.



1. Al escoger la opción de consultar cita aparece losdatos de la cita solicitada anteriormente.

2. Si la actividad seleccionada es salir volverá a la páginaprincipal.

Precondiciones

El usuario debe haber ejecutado el caso de uso autenticarusuario.

Se debe haber ejecutado el caso de uso solicitar cita.


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.


1. Se presenta al usuario una opción para cancelar unacita.

2. Si el usuario lo desea puede crear la cita nuevamente

49

Curso normal de eventos en el horario y fecha que el paciente lo desee.


Precondiciones


Se debe haber ejecutado el caso de uso solicitar cita.

Flujo alternativo de eventos Si el usuario desea cancelar la cita aparecerá un mensajepreguntando si está seguro de hacerlo.


Tabla 15. Descripción Caso de Uso Crear Historia Clínica.

Caso de uso Crear Historia Clínica

ObjetivoOfrecer al usuario la opción de crear la historia clínica de lospacientes.



1. Se presenta al usuario en la pantalla la opción primerhistoria.

2. El usuario debe llenar todas las secciones con lascuales cuenta la historia clínica y se guardan loscambios en la base de datos.


PrecondicionesEl usuario debe haber ejecutado el caso de uso autenticarusuario.


Pos condiciones Historia Clínica creada.

50

Tabla 16. Descripción Caso de Uso Actualizar Historia Clínica.

Caso de uso Actualizar Historia Clínica

ObjetivoOfrecer al usuario la opción de actualizar la historia clínica delos pacientes.



1. El usuario puede actualizar únicamente la evoluciónsalud oral de la historia clínica del paciente las vecesque sea necesario.


Precondiciones


Se debe haber ejecutado el caso de uso crear historia clínica.


Pos condiciones Historia Clínica actualizada.

Tabla 17. Descripción Caso de Uso Consultar Historia Clínica.

Caso de uso Consultar Historia

ObjetivoOfrecer al usuario la opción de consultar la historia clínica delos pacientes.



1. Se presenta al usuario una opción para consultar lahistoria clínica.

2. El usuario debe ingresar la cédula para que el sistemabusque 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

51

que desee visualizar.


Precondiciones


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 pacientedebe 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.



1. Se presenta al usuario una pantalla en donde puedeactualizar y consultar sus datos básicos.

2. Si el usuario escoge actualizar solo puede cambiar lossiguientes datos: ocupación, dirección, teléfono,celular y contraseña. Para cada uno aparece un linkpara editar.

3. El sistema muestra en pantalla los datos actualizados.


PrecondicionesEl usuario debe haber ejecutado los casos de uso registrar yautenticar usuario.

Flujo alternativo de eventos Si en el momento de editar un campo el usuario no escoge laopción actualizar el campo no tendrá ningún cambio.

Pos condiciones Información de usuario actualizada.

52

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 paraque el sistema lo busque en la base de datos y asíobtener el celular al cual se envía el sms para recordarla fecha y hora de la próxima cita.

53


Precondiciones El Asistente debe haber ejecutado el caso de uso autenticarusuario.

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 nollegará al celular del paciente.


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.

54

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.

55

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.

56

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.

57

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.

58

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.

59

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.

60

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.

61

Figura 15. Diagrama de Actividades Odontólogo y Administrador.

62

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.

63

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.

64

5.3.2.4.1. Modelo de la base de Datos

Figura 17. Modelo Base de Datos Dentistry Web.

65

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 Llave Primaria Llave Foránea Tipo de dato Longitud Not Null

Numero_documento X Double 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

Password Varchar 15 X

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.

66

Tabla 21. Asistente.

NOMBRE DE LA TABLA: ASISTENTE





Nombre Varchar 30 X


Telefono Double X

Celular Double X


Genero Char 1 X


Cargo Varchar 40 X

Login Varchar 15 X



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.

67

Tabla 22. Odontólogo

NOMBRE DE LA TABLA: ODONTÓLOGO





Nombre Varchar 30 X


Telefono Double X

Celular Double X


Genero Char 1 X


Tarjeta_profesional Varchar 20 X

Administrador Varchar 2 X

Login Varchar 15 X



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.

68

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.




Nombre Varchar 30 X


Telefono Double X



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.

69

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.


Id_estudio X Int 2 X

Titulo Varchar 20 X

Institucion Varchar 20 X

Fecha_de_grado Date X

Numero_documento_odontologo X Double X


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.

70

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.


Numero_historia X Int 10 X

Antecedente_personal Varchar 40

Antecedente_familiar Varchar 40

Fecha_de_actualizacion Date X

Numero_documento_paciente X Double X


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.

71

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.


Numero_tratamiento X Int 4 X

Numero_historia 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


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 pacienteEstado: 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.

72

Tabla 27. Examen_Básico.

Tabla 28. Diente.

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.


Id_examen X Int 2 X

Nombre Int 40

Detalle Varchar 200



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.

NOMBRE DE LA TABLA: DIENTE.

Descripción: la tabla almacena la información sobre los dientes del paciente.


Numero_diente X Int 2 X

Cop Varchar 8

Manifestacion Varchar 200



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.

73

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.


Fecha X Date X

Hora Time

Descripcion Varchar 200

Valor Int 7



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 eltratamiento.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.

74

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.


Numero_anexo X Int 3 X

Tipo_anexo Int 15

Direccion_interna Varchar 200



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.

75

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.


Fecha X Date X

Hora Time X

Numero_documento_paciente X Double X


Numero_documento_asistente X Double X


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.

76

Tabla 32. Servicio.

Tabla 33. Servicios_Por_Odontólogo.

NOMBRE DE LA TABLA: SERVICIO.

Descripción: la tabla almacena la información sobre los servicios que presta el consultorio.


Id_servicio X Int 2 X

Nombre_servicio Varchar 20

Descripcion_de_servicio Text


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.

NOMBRE DE LA TABLA: SERVICIOS_POR_ODONTOLOGO.

Descripción: Es la tabla intermedia de las tablas ODONTOLOGO y SERVICIO.


Id_servicio_odontologo X Int 2 X

Id_servicio X Int 8 X



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.

77

Tabla 34. SMS.

NOMBRE DE LA TABLA: SMSDescripción: En esta tabla se almacena el mensaje SMS, su hora de salida y estado.

Campos Llave Primaria Llave Foránea Tipo de dato Longitud Not NullId_sms X Double XHora_salida_sms Time XMensaje_sms Varchar 100 XEstado Varchar 20 XNumero_documento_paciente X Double X


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.

78

5.3.2.4.3. Asignación de Privilegios.

Tabla 35. Usuario: Administrador.

Tabla 36. Usuario: Odontólogo.

USUARIO: ADMINISTRADORTABLAS INSERT DELETE UPDATE SELECT

PERSONA X X XPACIENTE X X XACUDIENTE X X XASISTENTE X X XODONTÓLOGO X X XESTUDIO X X XSERVICIOS_POR_ODONTÓLOGO X X XSERVICIOS X X XHISTORIA CLÍNICA X X XPLAN DE TRATAMIENTO X X XDIENTE X X XEXÁMEN BÁSICO X X XANEXOS X X XEVOLUCIÓN X X XCITAS X X X XSMS X X X X

USUARIO: ODONTÓLOGOTABLAS INSERT DELETE UPDATE SELECT

PERSONA X X XPACIENTE X X XACUDIENTE X X XASISTENTEODONTÓLOGO X XESTUDIO X X XSERVICIOS_POR_ODONTÓLOGO XSERVICIOS X XHISTORIA CLÍNICA X X XPLAN DE TRATAMIENTO X X XDIENTE X X XEXÁMEN BÁSICO X X XANEXOS X X XEVOLUCIÓN X X XCITAS X X X XSMS

79

Tabla 37. Usuario: Asistente.

Tabla 38. Usuario: Paciente.

USUARIO: ASISTENTETABLAS INSERT DELETE UPDATE SELECT

PERSONA X XPACIENTEACUDIENTEASISTENTEODONTÓLOGOESTUDIOSERVICIOS_POR_ODONTÓLOGOSERVICIOSHISTORIA CLÍNICAPLAN DE TRATAMIENTODIENTEEXÁMEN BÁSICOANEXOSEVOLUCIÓNCITAS X X X XSMS X X

USUARIO: PACIENTETABLAS INSERT DELETE UPDATE SELECT

PERSONA X XPACIENTEACUDIENTEASISTENTEODONTÓLOGOESTUDIOSERVICIOS_POR_ODONTÓLOGOSERVICIOSHISTORIA CLÍNICAPLAN DE TRATAMIENTODIENTEEXÁMEN BÁSICOANEXOSEVOLUCIÓNCITAS X X X XSMS

80

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.

81

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.

82

Figura 20. Herramientas para el diseño de interfaces.

83

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.

84

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.

85

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.

86

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.

87

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.

88

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.

89

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

90

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 5de 2010, 2:23 p.m.

91

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.

92

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.

93

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.

94

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.

95

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 LaIngeniería del Software, Editores NETBIBLO, España 2007, p 49.

96

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.

97

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.

98

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.


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.


Entradas: Número de documento del paciente.

Salidas deseadas: El usuario cancela la cita odontológica.

99

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

100

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

101

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.


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.

102

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.


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.

103

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.

104

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.

105

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.

106

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.

107

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.

108

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.

109

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.

110

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.

111

BIBLIOGRAFÍA

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.

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.

112

WEITZENFELD, Alfredo. Ingeniería de software orientada a objetos con Uml. Java e

internet. México: Thomson, 2005. 678 p.

113

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 de2009]

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 demayo 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 el01 de mayo de 2009]

Introducción a los servidores de aplicaciones, [artículo en línea] Disponible desde Interneten: <http://www.jtech.ua.es/j2ee/2003-2004/abierto-j2ee-2003-2004/sa/sesion1-apuntes.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 02de 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 DanielPerovich [pdf en línea] Disponible desde Internet en: <http://www.fing.edu.uy/inco/pedeciba/bibliote/reptec/TR0312.pdf> [con acceso el 13 demayo 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]

114

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-ciclos-

de-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]

115

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.

116

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.

117

ANEXO A.Ejemplo de procedimiento institucional documentado para el uso y manejo de la

historia clínica de un servicio odontológicoANEXO A.INSTITUCION

XXXXXXXXXXXXXXXXX

DOCUMENTO PPRROOCCEEDDIIMMIIEENNTTOO IINNSSTTIITTUUCCIIOONNAALL PPAARRAA EELL UUSSOO YYMMAANNEEJJOO DDEE LLAA HHIISSTTOORRIIAA CCLLÍÍNNIICCAA

FECHA DE ELABORACIÓN: DD/MM/AAAA

FECHA DEACTUALIZACIÓN:

DD/MM/AAAA

CONTENIDO

1. Definición2. Normatividad vigente3. Directivas internas sobre la Historia Clínica3.1 Historia Clínica Única3.2 Obligatoriedad de la apertura de Historia Clínica3.3 Obligatoriedad del registro3.4 Calidad de los registros en la Historia Clínica3.5 Custodia de la Historia Clínica4. Características de la Historia Clínica5. Componentes de la Historia Clínica6. Formatos de la Historia Clínica6.1 Historia Clínica (Apertura de Historia Clínica de Primera Vez)6.2 Evolución del Tratamiento6.3 Referencia y Contrarreferencia6.4 Consentimiento Informado6.5 Presupuesto Odontológico7. Instructivos de la Historia Clínica8. Diligenciamiento de la Historia Clínica9. Uso de la Historia Clínica10. Manejo de la Historia Clínica10.1 Archivo de Historias Clínicas10.2 Registro de salida y entrada de Historias Clínicas10.3 Foliación de Historias Clínicas10.4 Registro general de Historias Clínicas11. Anexos específicos de la Historia Clínica

118

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.

119

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”.

120

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:

121

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

122

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.

123

Historia Clínica (Apertura de Historia Clínica de Primera Vez)

Evolución del Tratamiento

Referencia y Contrarreferencia

Consentimiento Informado

Presupuesto Odontológico

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

(Recuerde que es solo un EJEMPLO del procedimientodocumentado y, por tanto, NO contiene los formatosarriba mencionados, los cuales puede encontrarlos enotros de los anexos de la Guía Práctica dehabilitación).

124

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.

125

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 primeravez, 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 expedientebásico de la Historia, son: el formato de Historia Clínica de apertura de primera vez; elformato de evolución del tratamiento; el formato de Consentimiento Informado y el formatode Presupuesto Odontológico.

Firma de aprobación:

_________________________________________________________

NOMBRE DE LA INSTITUCIÓN, REPRESENTANTE O PROFESIONALINDEPENDIENTE

Profesión, especialidad o cargo

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

126

ANEXO B.Formato Historia Clínica Odontológica

128

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.

129

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.

130

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.

131

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.

132

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

133

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

134

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.

135

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.

136

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 HISTORIACLÍ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 DELA 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.

137

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.

138

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

139

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?

140

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?

141

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?

142

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.

143

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.


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?

144

Gráfica 3. Resultados Encuesta – Preguntas 8, 9, 10 y 11.


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ó?

145

Gráfica 4. Resultados Encuesta – Preguntas 12, 13, 15, 16 y 17.


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.

146

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.

147

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 losinventarios.

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.

148

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 eltelé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?

149

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 lainformació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?

150

Fácil de aprender y usar, que muestre la información de forma clara y que nosea 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 historiasodontológicas.

JOHANNA BOLAÑOS DEISY MARCELA TORRES

FIRMA ENCUESTADOR FIRMA ENCUESTADO

151

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 LAADMINISTRACIÓN DE CITAS E HISTORIAS ODONTOLÓGICAS

PALABRAS CLAVES J2EE (Java 2 Enterprise Edition)JSP (Java Server Pages)JAVABEANHISTORIA CLÍNICA

DESCRIPCIÓN 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

152

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

153

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.

154

NÚMERO RAE


CONTENIDOSOBJETIVOS

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.

155

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


156

METODOLOGÍAENFOQUE 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.

157

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

158

estas se corrigieron para hacer entrega de un software que

cumple con los requerimientos planteados.

implementaciÓn de un aplicativo web en plataforma j2ee …

Documents