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

Transcripción

1 IMPLEMENTACIÓN DE UN APLICATIVO WEB EN PLATAFORMA J2EE PARA LA ADMINISTRACIÓN DE CITAS E HISTORIAS ODONTOLÓGICAS JOHANNA MARITZA BOLAÑOS BARRIOS NATALIA LONDOÑO OSPINA UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D.C

2 IMPLEMENTACIÓN DE UN APLICATIVO WEB EN PLATAFORMA J2EE PARA LA ADMINISTRACIÓN DE CITAS E HISTORIAS ODONTOLÓGICAS JOHANNA MARITZA BOLAÑOS BARRIOS NATALIA LONDOÑO OSPINA Proyecto de grado como requisito para optar por el título de Ingeniero de Sistemas. ASESOR EMILIO BARAJAS INGENIERO DE SISTEMAS UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D.C

3 Nota de aceptación Presidente del Jurado Firma del Jurado Firma del jurado Bogotá D.C., Noviembre de

4 Dedico mi trabajo al Dios de la vida, que me ha dado una nueva oportunidad de vivir. A mi familia por todo su apoyo incondicional y todos aquellos que de una u otra manera han apoyado mi estudio y han sido oportunos con sus consejos y sugerencias. Mis padres, Juan Antonio y María Ruth han sido ejemplares en la comunicación de valores, de ellos aprendí la perseverancia, la constancia, la dedicación y el valor mostrado para salir adelante. Gracias papás por su amor. A Gabriel por haberme apoyado en todo momento, por sus exigencias, pero más que nada, por su comprensión. A mi compañera de tesis, que gracias al equipo y la unidad que formamos, logramos llegar hasta el final. Natalia Londoño Ospina A Dios por darme la oportunidad que me brindo al llegar hasta aquí, a mis padres y familia porque sin su apoyo incondicional este paso en mi vida no hubiese sido posible de alcanzar, a mis amigos que siempre me dieron una voz de aliento y de ánimo para no desfallecer en este proceso y a mi compañera Natalia por su colaboración, esfuerzo y constancia para terminar con éxito el propósito que nos unió. Johanna Maritza Bolaños Barrios 3

5 TABLA DE CONTENIDO INTRODUCCIÓN PLANTEAMIENTO DEL PROBLEMA ANTECEDENTES (ESTADO DEL ARTE) DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA JUSTIFICACIÓN OBJETIVOS Objetivo General Objetivos Específicos ALCANCES Y LIMITACIONES Alcances Limitaciones METODOLOGÍA LÍNEA DE INVESTIGACIÓN ENFOQUE DE LA INVESTIGACIÓN LÍNEA DE INVESTIGACIÓN DE USB SUB-LÍNEA DE FACULTAD CAMPO TEMÁTICO DEL PROGRAMA MARCO DE REFERENCIA TEÓRICO CONCEPTUAL Metodología de Desarrollo de Software Servidor de Aplicaciones Base de Datos Plataforma J2EE JavaBean SMS (Short Message Service) Administración de la Historia Clínica Odontológica Proceso para solicitar una cita odontológica MARCO LEGAL O NORMATIVO RESOLUCIÓN NÚMERO 1995 DE 1999 (JULIO 8)

6 5. DESARROLLO INGENIERIL METODOLOGÍA DEL PROYECTO ANÁLISIS Y DEFINICIÓN DE REQUERIMIENTOS Levantamiento de información Requerimientos funcionales Requerimientos no funcionales DISEÑO DEL SISTEMA Y DE SOFTWARE Diseño del sistema Diagramas de casos de uso Diseño del software IMPLEMENTACIÓN Y PRUEBA DE UNIDADES Implementación Prueba de Unidades INTEGRACIÓN Y PRUEBAS DEL SISTEMA FUNCIONAMIENTO Y MANTENIMIENTO PRESENTACIÓN Y ANÁLISIS DE RESULTADOS CONCLUSIONES RECOMENDACIONES BIBLIOGRAFÍA WEBGRAFÍA GLOSARIO ODONTOLÓGICO GLOSARIO TÉCNICO

7 LISTA DE TABLAS Tabla 1. Cuadro Comparativo...16 Tabla 2. Metodologías de Desarrollo de Software Tabla 3. Servidor de Aplicaciones Tabla 4. Motor de Base de Datos Tabla 5. Descripción Caso de Uso Registrar Usuario 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 Tabla 9. Descripción Caso de Uso Gestionar Datos Básicos de Usuarios Tabla 10. Descripción Caso de Uso Generar Reportes 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 Tabla 14. Descripción Caso de Uso Cancelar Cita Tabla 15. Descripción Caso de Uso Crear Historia Clínica Tabla 16. Descripción Caso de Uso Actualizar Historia Clínica Tabla 17. Descripción Caso de Uso Consultar Historia Clínica...50 Tabla 18. Descripción Caso de Uso Actualizar Datos de Usuarios 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

8 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 Tabla 29. Evolución...73 Tabla 30. Anexos...74 Tabla 31. Citas Tabla 32. Servicio...76 Tabla 33. Servicios_Por_Odontólogo Tabla 34. SMS...77 Tabla 35. Usuario: Administrador Tabla 36. Usuario: Odontólogo Tabla 37. Usuario: Asistente...79 Tabla 38. Usuario: Paciente Tabla 39. Caso de Prueba Iniciar Sesión...96 Tabla 40. Caso de Prueba Cerrar Sesión Tabla 41. Caso de Prueba Registrar Usuario Tabla 42. Caso de Prueba Actualizar Usuario Tabla 43. Caso de Prueba Crear Historia Clínica Odontológica...97 Tabla 44. Caso de Prueba Consultar Historia Clínica Odontológica Tabla 45. Caso de Prueba Solicitar Cita Tabla 46. Caso de Prueba Cancelar Cita Tabla 47. Caso de Prueba Enviar SMS Tabla 48. Caso de Prueba Registrar Usuario Existente

9 Tabla 49. Caso de Prueba Registrar Usuario con datos no válidos Tabla 50. Caso de Prueba Consultar Cita Tabla 51. Autenticar usuarios con datos no válidos

10 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 Figura 7. Diagrama Caso de Uso Asistente Figura 8. Diagrama Caso de Uso Paciente...53 Figura 9. Diagrama de Clases Dentistry Web Figura 10. Diagrama de Secuencia Registrar Usuario Figura 11. Diagrama de Secuencia Crear Historia Clínica Figura 12. Diagrama de Secuencia Solicitar Cita...58 Figura 13. Diagrama de Secuencia Enviar SMS Figura 14. Diagrama de Secuencia Actualizar Datos...59 Figura 15. Diagrama de Actividades Odontólogo y Administrador Figura 16. Diagrama de Actividades Asistente y Paciente Figura 17. Modelo Base de Datos Dentistry Web Figura 18. Diseño del Odontograma Figura 19. Herramientas para el diseño de Interfaces Figura 20. Herramientas para el diseño de interfaces...82 Figura 21. Escenario Basado en la Web de J2EE Figura 22. Conexión Base de Datos

11 Figura 23. Propiedades de la base de datos...86 Figura 24. Consulta Personas Figura 25. Consulta Citas Figura 26. Consulta Pacientes...88 Figura 27. Consulta Odontólogos Figura 28. Consulta Citas Agendadas...89 Figura 29. JavaBeans de la aplicación Figura 30. Código para envió de SMS Figura 31. JSP s de la aplicación Figura 32. Interfaz Gráfica del Aplicativo Figura 33. Envio de SMS...99 Figura 34. Confirmación de Salida SMS Figura 35. Error Registro Figura 36. Cita Asignada Figura 37. Error Registro

12 LISTA DE GRÁFICAS Gráfica 1. Resultados Encuesta Preguntas 1 y Gráfica 2. Resultados Encuesta Preguntas 3, 4, 5 y Gráfica 3. Resultados Encuesta Preguntas 8, 9, 10 y Gráfica 4. Resultados Encuesta Preguntas 12, 13, 15, 16 y

13 LISTA DE ANEOS ANEO A. Ejemplo de procedimiento institucional documentado para el uso y manejo de la historia clínica de un servicio odontológico ANEO B. Formato Historia Clínica Odontológica ANEO C. Resolución Número 1995 de 1999 (Julio 8) MINISTERIO DE SALUD ANEO D. Encuesta pacientes ANEO E. Resultados de las encuestas ANEO F. Ficha técnica y resultados encuestas ANEO G. Entrevista odontóloga

14 INTRODUCCIÓN El desarrollo avanzado de la tecnología ha hecho posible utilizar la ciencia en beneficio de la humanidad, haciendo cada vez más eficientes los procesos, facilitando las actividades humanas. Es así como este proyecto plantea el uso de la tecnología para la implementación de un aplicativo web que facilite el proceso de administración de las citas e historias odontológicas. Según Roger S. Pressman en su libro Ingeniería del Software (un enfoque práctico): las Aplicaciones Web o WebApps son diferentes de otras categorías de software informático; son eminentemente en red, las gobiernan los datos y se encuentran en evolución continua. Las WebApps pueden valorarse mediante una diversidad de criterios de calidad que incluyen facilidad de uso, funcionalidad, confiabilidad, eficiencia, capacidad de mantenimiento, seguridad, disponibilidad y escalabilidad. La aplicación web se desarrollará en la plataforma J2EE (Java 2 Enterprise Edition) la cual se basa en una estructura multicapa para el desarrollo de los sistemas. La división de capas para estructura es la siguiente: Capa de presentación, Capa de negocios y Capa de integración. El aplicativo contará con SMS (Short Message Service), servicio por medio del cual se utiliza el sitio web para enviar a través de internet un mensaje al teléfono móvil de cada paciente, recordando el día y la hora de su próxima cita odontológica. Adicionalmente la implementación se hará con un servidor de aplicaciones Java, sobre una plataforma J2EE (Java 2 Enterprise Edition). Este estándar permite el desarrollo de aplicaciones de una manera eficiente y versátil. 13

15 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 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 $ 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: < 15 de :30pm. 2 Dentilogic, [artículo en línea] Disponible desde Internet en: < Mayo 15 de :30pm. 3 Dental Pro, [artículo en línea] Disponible desde Internet en: < Mayo 15 de :40pm. 14

16 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 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA En la actualidad algunas clínicas y consultorios odontológicos no tienen implementado un sistema que permita administrar la información de los pacientes que buscan una solución a sus problemas dentales. Esta información se consigna en una historia clínica odontológica, la cual es diligenciada manualmente por el odontólogo para luego ser archivadas en carpetas y folders, lo cual no es lo más adecuado porque con el tiempo se van deteriorando. En el momento de consultar, actualizar o verificar la información de cada paciente la búsqueda es lenta y tarda más tiempo. Cómo implementar un aplicativo web en plataforma J2EE para la administración de citas e historias odontológicas? 1.3. JUSTIFICACIÓN Las clínicas necesitan un sistema de información que permita crear una historia odontológica para almacenar los datos de cada paciente, hacer un seguimiento de su tratamiento, evolución y procedimientos realizados de una manera más ágil. 4 Galeno Dental, [artículo en línea] Disponible desde Internet en: < Mayo 15 de :30pm. 15

17 Las ventajas de Dentistry Web con respecto a los mencionados en la tabla 1 son el bajo costo de las herramientas de desarrollo. Asimismo la aplicación contará con una interfaz web cuyo beneficio es que se puede acceder a un servidor web a través de internet lo cual significa que no se instala el software en varias pc s. CUADRO COMPARATIVO ENTRE DENTISTRY WEB Y OTROS SISTEMAS Tabla 1. Cuadro Comparativo CARACTERÍSTICAS DENTAL SOFTWARE DENTILOGIC DENTISTRY WEB Manejo de citas Si Si Si Manejo de historias Si Si Si Costo comercial $ $ $ Interfaz web No Si Si Usabilidad Si Si Si Los beneficios que se pueden encontrar en el aplicativo son: Tener un manejo del tiempo eficiente en una consulta odontológica, proporciona información inmediata sobre las historias clínicas odontológicas. Con la implementación del aplicativo web se va a tener un control de toda la información relacionada con los pacientes (datos personales, historia odontológica, antecedentes personales y familiares, tratamiento a realizar, procedimientos realizados y programación de sus citas). Su uso permitirá administrar de manera eficiente la información odontológica de los pacientes, llevar un registro organizado del historial odontológico permitiendo una búsqueda ágil y fácil. El aplicativo web cumplirá con los requerimientos necesarios de confidencialidad de las historias odontológicas mediante la autenticación (seguridad) que permita sólo el acceso a personas del consultorio que se encuentran registradas. El acceso al sistema estará restringido por usuario y contraseña para cada uno de los usuarios. El odontólogo tendrá la posibilidad de consultar y actualizar las historias clínicas de los pacientes cuantas veces sea necesario, al mismo tiempo las anotaciones que ya se han 16

18 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 OBJETIVOS Objetivo General. Implementar un aplicativo web en plataforma J2EE para la administración de citas e historias odontológicas Objetivos Específicos. Analizar los requerimientos funcionales y no funcionales para la administración de citas e historias odontológicas. Modelar una base de datos que permita almacenar toda la información relacionada con los pacientes del consultorio. Desarrollar un módulo de autenticación (seguridad) que permita sólo el acceso a personas del consultorio que se encuentran registradas. Diseñar el software para la aplicación en plataforma J2EE que cumpla con el estándar UML (Unified Modeling Language) para generar un software de calidad. Diseñar las interfaces gráficas para el software y el odontograma. Implementar el software mediante un servidor de aplicaciones que permita la interacción con los usuarios (médico o asistente) del consultorio. Realizar pruebas de aceptación para determinar si el software cumple con los requerimientos especificados ALCANCES Y LIMITACIONES Alcances. El proyecto culmina con la implementación de la aplicación web y con las pruebas aceptación que se realizarán para determinar si esta cumple con los requerimientos especificados. Esta aplicación contará con varios menús en los que se puede encontrar el paciente con toda su información personal y de contacto (nombre, apellidos, tipo documento de identidad, documento de identidad, fecha de nacimiento, género, ocupación, estado civil, barrio, teléfono y celular). También permitirá agregar nuevos pacientes, actualizar, editar 17

19 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 Limitaciones. Los pacientes no podrán consultar por internet la información de su historia odontológica debido a políticas internas de las clínicas (Ministerio de Salud, Resolución 1995 de 1999 capítulo III artículo 14. ACCESO A LA HISTORIA CLÍNICA) el cual se encuentra en el anexo C, pero en el momento que el paciente lo desee, puede reclamar una copia de su historia y en la clínica quedará archivado el documento original. El sistema no contará con un módulo que permita llevar la información contable de la clínica, especificar pagos, procesos administrativos (recursos humanos, nómina, y otros.) y/o módulo de cartera. 18

20 El sistema de SMS se implementará a través de un proveedor de servicios de mensajería, este servicio depende si el consultorio lo desea implementar. El consultorio no proporciona ninguna información acerca de los pacientes a personas externas a este debido a políticas internas, por esta razón sólo fue posible realizar 10 encuestas a pacientes que asisten regularmente. El aplicativo no contará con el servicio de adicionar ninguna opción diferente a las que se encuentran establecidas en el formato de la historia clínica detallado en el anexo B. 19

21 2. METODOLOGÍA Para el desarrollo del proyecto se tendrán en cuenta los siguientes métodos y herramientas requeridos para cumplir los objetivos propuestos. La metodología de desarrollo de software seleccionada es el modelo en cascada en la cual se deben cumplir con las fases de: Análisis y definición de requerimientos, diseño del sistema y del software, implementación y prueba de unidades, integración y pruebas del sistema, funcionamiento y mantenimiento. En el diseño del sistema del software es necesario escoger un motor de base de datos que permita almacenarlos, en este caso se escogió My Sql 5.1 ya que es la herramienta sobre la cual se tiene más conocimiento, es de fácil uso, rápido y lo más importante es que es un software libre. Para la fase de implementación, la plataforma J2EE permite crear un escenario ideal para el desarrollo y despliegue de aplicaciones escalables en la Web, esto hace que se reduzcan los costos. El envío de un Sms es un servicio adicional, que hoy en día es uno de los mejores medios para comunicarse. Se usa en la aplicación para recordar al paciente la hora y fecha de su próxima cita. Netbeans IDE 6.7 es el entorno de desarrollo visual de código abierto para aplicaciones programadas mediante Java, uno de los lenguajes de programación más poderosos del momento y el cual se usará para el desarrollo esta aplicación. En la fase de implementación, el aplicativo se publicará en Tomcat 6.0 que es un servidor de aplicaciones web, el cual ayudará a acceder a la interfaz de la aplicación. 20

22 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 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. 21

23 4. MARCO DE REFERENCIA 4.1. TEÓRICO CONCEPTUAL 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 p

24 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

25 Tabla 2. Metodologías de Desarrollo de Software. METODOLOGÍAS RUP ETREME PROGRAMING (P) DESARROLLO GUIADO POR LA FUNCIONALIDAD O FDD CICLO DE VIDA MODELO EN CASCADA FASES DEFINICIÓN Inicio Elaboración Construcción Transmisión Mantenimiento Planificación. El método RUP específica, principalmente, la constitución del equipo y las escalas de tiempo, así como un numero de modelos de documento Planificación Diseño Desarrollo Pruebas La metodología consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo al usuario final pues uno de los requisitos para llegar al éxito del proyecto Mantenimiento Muerte del proyecto Desarrollo de un modelo general. Construcción Plan de raleases e Diseñar Implementar FDD establece algunas medidas útiles que son muy importantes para la dirección de la empresa y muestran el estado actual del desarrollo y realizar, en el futuro, mejores estimaciones. TIEMPO DE EJECUCIÓN MANTENIMIENTO 6 meses El mantenimiento inmediato. es 3 meses El mantenimiento inmediato. es El mantenimiento inmediato. es Tiempo de desarrollo corto, es decir, menos de un año. Análisis Diseño Codificación Pruebas e integración Operación y Mantenimiento Conjunto de fases por las que pasa el sistema que se está desarrollando desde que nace la idea inicial hasta que el software es retirado o reemplazado ( muere ). Mediano Plazo El mantenimiento inmediato. es Análisis Diseño Implementación y pruebas Integración y pruebas Funcionamiento y Mantenimiento Ssecuencia de actividades, donde la estrategia principal es seguir el progreso del software hacia puntos de revisión bien definidos mediante entregas calendarizadas. Mediano Plazo El mantenimiento inmediato. es 24

26 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 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: < Marzo 21 de :30am. 25

27 Tabla 3. Servidor de Aplicaciones. SERVIDOR DE APLICACIONES CARÁCTERÍSTICAS WEBLOGIC EAServer GLASSFISH TOMCAT Puede utilizar Oracle, DB2, Microsoft SQL Server, y otras bases de datos que se ajusten al estándar JDBC. El servidor WebLogic es compatible con WS-Security y cumple con los estándares de J2EE 1.3 desde su versión 7 y con la J2EE 1.4 desde su versión 9 y Java EE para las versiones 9.2 y 10.x Un motor de ejecución escalable e independiente de la plataforma. Soporte de "stubs" y "proxys" para los principales modelos de componentes, incluyendo JavaBeans, PowerBuilder, Java, Active, y C/C++ Soporte a HTML dinámico usando Servlets Java y Java Server Pages(JSP) Soporte a la plataforma de desarrollo Java 2 Enterprise Edition (J2EE). Modularidad. Tiempo mejorado de inicio. Despliegues desde plugins en NetBeans y Eclipse, y preservación de sesiones a través de redespliegues. Implementado de Servlet 3.0 JSP 2.2 y EL 2.2 Mejoras para detectar y prevenir "fugas de memoria" en las aplicaciones web Limpieza interna de código Soporte para la inclusión de contenidos externos directamente en una aplicación web. DEFINICIÓN Servidor de aplicaciones Java EE y también un servidor web HTTP. Servidor de aplicaciones, el cual incluye un conjunto integrado de herramientas que se usan para crear y ejecutar aplicaciones Web con soporte a altos niveles de tráfico, contenido dinámico y procesamiento intensivo de transacciones en línea. Servidor de aplicaciones desarrollado por Oracle Corporation que implementa las tecnologías definidas en la plataforma Java EE y permite ejecutar aplicaciones que siguen esta especificación. Servidor web con soporte de servlets y JSPs. Tomcat incluye el compilador Jasper, que compila JSPs convirtiéndolas en servlets. 26

28 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 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: < Marzo 25 de :10pm. 27

29 Tabla 4. Motor de Base de Datos. MOTOR DE BASE DE DATOS MODELOS DE DATOS CARACTERISTICAS Relacional ORACLE Relacional SQL SERVER Relacional POSTGRES Relacional MYSQL HERRAMIENTAS SEGURIDAD Soporte de transacciones. Estabilidad. Escalabilidad. Multiplataforma. Patrón de consulta Agrupamiento de datos Subconsultas Índices Flexibilidad y potencia de los sistemas relacionales. Lenguaje de alto nivel y no de procedimiento. Configuración de cliente Monitor de funcionamiento Sql Server Profiler Analizador de Queries Aproxima los datos a un modelo objetorelacional, y es capaz de manejar complejas rutinas y reglas. Soporta integridad referencial, la cual es utilizada para garantizar la validez de los datos de la base de datos. PgAdmin3 : entorno de escritorio Visual PgAccess : entorno de escritorio Visual PhpPgAdmin : entorno Web psql : cliente de consola Aprovecha la potencia de sistemas multiprocesador. Soporta gran cantidad de tipos de datos para columnas. Gestión de usuarios y passwords. Gran portabilidad entre sistemas. TurboDbAdmin EMS SQL Manager for MySQL MySQL GUI Tools phpmyadmin Instant SQL Formatter DB Designer 4 WWW SQL Designer Seguridad de cuentas para la validación de usuarios. Seguridad en el acceso a los objetos de la base de datos. Seguridad a nivel de sistema para la gestión de privilegios globales. Un único ID de login tanto para red como para la DB para mejorar la seguridad y facilitar la administración. Password y encriptación de datos en red para mejorar la seguridad. Encriptación de procedimientos almacenados para la integridad y seguridad de código de aplicación. Protección de los ficheros de la base de datos. Las conexiones de los clientes al servidor de la base de datos están permitidas, por defecto. Las conexiones de los clientes se pueden restringir por dirección IP y/o por nombre de usuario mediante el fichero pg_hba.conf situado en PG_DATA. MySQL Network Scanner: Este programa permite auditar una red de clase C en busca de servidores MySQL que no tengan definida una contraseña para el usuario root. MySQL Brute Force Password Hash Cracker: Esta utilidad, complementaria a la anterior, admite como argumento el hash de una contraseña de un usuario de MySQL y, mediante fuerza bruta, intentará descifrarlo. 28

30 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: < Abril 02 de :10pm. 29

31 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: < Octubre 7 de 2010, 4:01 p.m. 30

32 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 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 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 SINGH Inderjeet, STEARNS Beth, JOHNSON Mark, Designing Enterprise applications with the J2EE platform, Sun Microsystem 2002, p Definición JavaBean [artículo en línea] Disponible desde Internet en: < de JavaBean>, Octubre 5 de 2010, 2:23 p.m. 13 Definición SMS, [artículo en línea] Disponible desde internet en: < Octubre 5 de 2010, 2:23 p.m. 31

33 Administración de la Historia Clínica Odontológica. Para llevar a cabo este proceso es necesario tener en cuenta las directivas internas, características, componentes, formatos, instructivos, diligenciamiento, uso y manejo de la historia clínica odontológica las cuales se encuentran detalladas en el anexo A. A continuación se referencia la Resolución 1995 de 1999 incluida en el anexo C y establece que: La Historia Clínica es un documento privado, obligatorio y sometido a reserva, en el cual se registran cronológicamente las condiciones de salud del paciente, los actos médicos y los demás procedimientos ejecutados por el equipo de salud que interviene en su atención. Dicho documento únicamente puede ser conocido por terceros con previa autorización del paciente o en los casos previstos por la ley 14. En el anexo A se encuentra un ejemplo de un procedimiento para el uso y manejo de la historia clínica de un servicio odontológico, en este se mencionan las partes que componen la historia clínica odontológica, estas se pueden ver representadas en un formato el cual se encuentra en el anexo B y son: 1. Datos personales: identificación del usuario, apellidos y nombres completos, estado civil, documento de identidad, fecha de nacimiento, sexo, ocupación, dirección y teléfono del domicilio y lugar de residencia, nombre y teléfono del acompañante; nombre, teléfono y parentesco de la persona responsable del usuario. 2. Antecedentes personales y familiares: enfermedades relevantes que ha sufrido el paciente o alguno de los integrantes de su familia más cercanos. 3. Examen físico: estomatológico, periodontal, pulpar, tejidos dentarios y oclusión 4. Odontograma: es un elemento básico y fundamental desde el punto de vista clínico para el establecimiento del diagnóstico, el plan de tratamiento y el seguimiento de la rehabilitación del paciente. 5. Plan de tratamiento: como su nombre lo indica es el tratamiento odontológico que se le llevará a cabo al paciente, según lo establezca el odontólogo. 14 Resolución número 1995 de 1999 (julio 8). 32

34 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 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: Agosto 5 de 2010, 4:01 p.m. 33

35 4.2. MARCO LEGAL O NORMATIVO 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 Esta ley se incluye en el anexo C. 34

36 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 Levantamiento de información. Para llevar a cabo el proceso de levantamiento de información se seleccionó un consultorio odontológico. En este lugar se le realizó una entrevista a la odontóloga la cual se refleja en el anexo G. Además se encuestaron a 10 de los pacientes que frecuentan el consultorio y no fue posible realizar más de estas, puesto que a políticas del lugar no es permitido suministrar información sobre los pacientes. Para la ejecución de las encuestas se utilizó un formato con 18 preguntas que fueron realizadas en su totalidad representadas en el anexo D, las cuales permitieron determinar los requerimientos funcionales y no funcionales del sistema. Se obtiene una tabulación de los datos como se encuentra en el anexo E, donde los pacientes coinciden en que se implemente en el consultorio un aplicativo web para administrar las citas e historias odontológicas. En consecuencia de este proceso se establece su ficha técnica que se encuentra en el anexo F. 35

37 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 Requerimientos funcionales. Describen con detalle lo que el sistema debe hacer, dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado de la organización al redactar requerimientos 16. A continuación se presentan en detalle dichos requerimientos con los que debe cumplir el software: Para acceder a los servicios que presta el consultorio, los odontólogos, la asistente o los pacientes deben autenticarse por medio de la página web ingresando el usuario y contraseña que los identifica en el sistema. Si es un paciente que no existe debe registrarse ingresando nombres, apellidos, estado civil, sexo, tipo de documento, número de documento, fecha de nacimiento, ocupación, dirección, barrio, teléfono, y celular. Después del registro, el sistema genera el usuario el cual es: nombre.primerapellido y la contraseña que es: el día de nacimiento + primer apellido con los que el paciente debe autenticarse para poder solicitar una cita, la cual se consigna en la base de datos que el sistema posee, donde debe señalar el odontólogo, la fecha y la hora, que el paciente desee, el sistema verifica si el odontólogo está disponible en esa fecha y horario, de ser así quedará registrada la cita, en caso contrario se mostrarán los horarios disponibles para esa fecha con ese odontólogo y si desea solicitarla será guardada en el sistema. El paciente debe cerrar su sesión después de haberse registrado o en el momento que lo desee. Para recordarle al paciente la hora y fecha de su próxima cita se le enviará un sms a su celular. 16 SOMMERVILLE, Ian, Ingeniería del Software, Pearson Educación S.A. Madrid 2005, p

38 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 R, diseños, fotografías). En la página web los usuarios encontrarán la información sobre los odontólogos (nombres apellidos, y estudios realizados), servicios que presta el consultorio, dirección y teléfono de éste. Para el registro de odontólogos el administrador lo realizará en un formulario diseñado el cual pedirá los datos básicos como nombres, apellidos, cédula, teléfono, celular, dirección, entre otros. Esto se guardará en la base de datos del sistema. 37

39 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 Requerimientos no funcionales. Son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento 17. A continuación se encuentra el listado de requerimientos no funcionales identificados como sigue: Para utilizar la aplicación web se requiere una conexión a internet. La disponibilidad del aplicativo depende de los servicios que ofrezca el hosting empleado. 17 SOMMERVILLE, Ian, Ingeniería del Software, Pearson Educación S.A. Madrid 2005, p

40 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 DISEÑO DEL SISTEMA Y DE SOFTWARE 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 Actores. En el desarrollo de la Implementación del aplicativo web se encuentran los siguientes actores autorizados para interactuar con el sistema y la aplicacion Dentistry Web: Administrador: es la persona que cuenta con todos los privilegios para gestionar todos los módulos con los cuales cuenta el sistema (gestionar historia odontológica, información de pacientes, odontólogos y asistente, y solicitar, consultar o cancelar citas). Odontólogo: es el usuario encargado de prestar el servicio odontológico a los pacientes del consultorio y cuenta con los privilegios de gestionar la historia odontológica, su propia información y la de los pacientes, además generar algunos reportes, solicitar, consultar o cancelar citas. Asistente: es la persona que se encarga de apoyar y asistir los procedimientos que realiza el odontólogo a sus pacientes. En el aplicativo cuenta con los privilegios de solicitar, consultar o cancelar citas. Al mismo tiempo se encarga de enviar los sms para recordar a los pacientes su próxima cita en caso de que el 39

41 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 Diagramas de casos de uso. Para el desarrollo del sistema Dentistry web se elaboraron los siguientes diagramas de casos de uso como lo muestran las figuras 4, 5, 6, 7 y 8. Figura 4. Diagrama de Caso de Uso Principal 40

42 Tabla 5. Descripción Caso de Uso Registrar Usuario. Caso de uso Registrar Usuario Objetivo Permitir a un usuario registrarse en el sistema. Actores Administrador, Odontólogo, Asistente y Paciente. 1. Se presenta al usuario una pantalla principal en donde se encuentra un link para cada perfil. Curso normal de eventos 2. Si el usuario es un paciente y no se encuentra registrado, encontrará un link para hacer el debido registro. 3. Si la actividad seleccionada es registrarse el sistema pide los siguientes datos: primer apellido, segundo apellido, nombres, estado civil, sexo, tipo documento, número de documento, fecha de nacimiento, ocupación, dirección, barrio, teléfono y celular. 4. Automáticamente el sistema genera un usuario y contraseña después del registro. 5. El Administrador es el único que puede registrar a un odontólogo o asistente y para este fin realiza el evento 3. Flujo alternativo de eventos Se debe hacer una validación de los campos registrados. Precondición Es obligatorio diligenciar todos los campos con la información requerida. Pos condiciones Usuarios registrados en el sistema. Tabla 6. Descripción Caso de Uso Autenticar Usuario. Caso de uso Autenticar Usuario Objetivo Validar usuario y contraseña de los usuarios del sistema. Actores Administrador, Odontólogo, Asistente y Paciente. 1. El usuario ingresa su usuario y contraseña 41

43 Curso normal de eventos insertados por pantalla. 2. Una vez autenticado el usuario puede acceder a los servicios a los cuales tiene permiso. Precondiciones Existe el registro de usuario. Flujo alternativo de eventos Si los datos ingresados no corresponden al usuario se muestra un mensaje en pantalla que los datos no son correctos y debe escribirlos nuevamente. Pos condiciones Usuarios autenticados en el sistema. Tabla 7. Descripción Caso de Uso Gestionar Historia Clínica. Caso de uso Gestionar Historia Clínica Objetivo Ofrecer a los usuarios permitidos las opciones de crear, actualizar y guardar la historia clínica de los pacientes. Actores Administrador y Odontólogo 1. Se presenta al usuario una pantalla en donde encuentra un link llamado paciente. Curso normal de eventos 2. El usuario ingresa la identificación del paciente. Si el paciente se encuentra registrado puede consultar o crear la historia en donde deberá llenar las secciones con las cuales esta cuenta y vuelve a la página principal. 3. Después de crear la historia aparecen todas las secciones en pantalla pero la única que puede modificar es la evolución de la salud oral. Después de haber realizado la actualización se guardan los cambios. 4. Si la actividad seleccionada es cerrar sesión y volverá a la página principal. Precondiciones El Administrador u Odontólogo deben haber ejecutado el caso de uso autenticar usuario. Para actualizar se debe haber ejecutado el caso de uso crear 42

44 historia. Flujo alternativo de eventos Si el número de documento del paciente no se encuentra en la base de datos se debe hacer el registro. Pos condiciones Historia Clínica modificada. Tabla 8. Descripción Caso de Uso Gestionar Cita. Caso de uso Gestionar Cita Objetivo Ofrecer a los usuarios permitidos las opciones de solicitar, consultar o cancelar una cita. Actores Administrador, Odontólogo, Asistente y Paciente. Curso normal de eventos 1. Se presenta al usuario una pantalla y puede solicitar, consultar o cancelar. 2. Si el usuario escoge solicitar cita aparece una lista de odontólogos en donde puede escoger el que desee y un botón que muestra la lista semanal de horarios con la fecha y hora disponibles. Este registro se guarda en la base de datos. 3. Cuando pide la cita aparecen en pantalla los datos de esta. 4. Si el usuario desea consultar una cita, debe haber sido creada y muestra los datos de esta, si la cita no ha sido creada aparece un mensaje informando el estado de la cita. 5. Si escoge cancelar la cita que ya existe se borrará la cita creada y vuelve a quedar disponible el horario que había escogido. 6. Si la actividad seleccionada es cerrar sesión volverá a la página principal. Precondiciones El Administrador, Odontólogo, Asistente y Paciente deben haber ejecutado el caso de uso autenticar usuario. Para cancelar una cita ya debe haber sido solicitada. 43

45 Flujo alternativo de eventos Ninguno. Pos condiciones Cita Modificada. Tabla 9. Descripción Caso de Uso Gestionar Datos Básicos de Usuarios. Caso de uso Gestionar Datos Básicos de Usuarios Objetivo Permitir a todos los usuarios del sistema actualizar sus respectivos datos básicos. Actores Administrador, Odontólogo, Asistente y Paciente. Curso normal de eventos 1. Se presenta al usuario una pantalla en donde puede escoger la opción de actualizar los datos. 2. Si el usuario escoge actualizar solo puede cambiar los siguientes datos: ocupación, dirección, teléfono, celular y contraseña. Para cada uno aparece un link para editar. 3. Si la actividad seleccionada es cerrar sesión volverá a la página principal. Precondiciones Todos los usuarios deben haber ejecutado los casos de uso registrar y autenticar usuario. Flujo alternativo de eventos Si en el momento de editar un campo el usuario no escoge la opción actualizar el campo no tendrá ningún cambio. Pos condiciones Información de usuarios actualizada. Tabla 10. Descripción Caso de Uso Generar Reportes. Caso de uso Generar Reportes Objetivo Consultar en la base de datos la información que el usuario desee. Actores Administrador, Odontólogo. 1. Se presenta una opción en donde se encuentra el 44

46 listado de reportes disponibles para los usuarios. 2. El usuario ingresa fecha y/o cédula y el sistema verifica si esta es válida. Curso normal de eventos 3. El sistema muestra en pantalla todos los registros encontrados. 4. Si la actividad seleccionada es regresar volverá a la sesión iniciada por el odontólogo. Precondiciones El Administrador u Odontólogo deben haber ejecutado el caso de uso autenticar usuario. Flujo alternativo de eventos Si los datos de ingreso no son válidos el sistema no muestra ningún reporte. Pos condiciones Visualización del reporte. Tabla 11. Descripción Caso de Uso Cerrar Sesión. Caso de uso Cerrar Sesión Objetivo Dar por terminada las actividades que el usuario está realizando en el sistema. Actores Administrador, Odontólogo, Asistente y Paciente. 1. Se muestra en pantalla un botón cerrar sesión. Curso normal de eventos 2. El usuario vuelve a la página principal. Si desea ingresar nuevamente debe autenticarse. Precondiciones Los usuarios deben haber ejecutado el caso de uso autenticar usuario. Flujo alternativo de eventos Ninguno. Pos condiciones Salir del sistema y volver a la pantalla principal. 45

47 Figura 5. Diagrama Caso de Uso Administrador. 46

48 Figura 6. Diagrama Caso de Uso Odontólogo. Tabla 12. Descripción Caso de Uso Solicitar Cita. Caso de uso Solicitar Cita Objetivo Ofrecer al usuario la opción de solicitar una cita. Actores Administrador, Odontólogo, Asistente, Paciente. 1. Se presenta al usuario una opción para solicitar la cita. Curso normal de eventos 2. El usuario debe escoger la fecha, la hora y el odontólogo disponible para asignar la cita; y se guardan los cambios en la base de datos. 3. Si la actividad seleccionada es cerrar sesión volverá a la página principal. 47

49 Precondiciones El usuario debe haber ejecutado el caso de uso autenticar usuario. Flujo alternativo de eventos Si el usuario no escoge la fecha, hora y odontólogo la cita no se puede solicitar. Pos condiciones Cita creada. Tabla 13. Descripción Caso de Uso Consultar Cita. Caso de uso Consultar Cita Objetivo Ofrecer al usuario la opción de consultar una cita. Actores Administrador, Odontólogo, Asistente, Paciente. Curso normal de eventos Precondiciones 1. Al escoger la opción de consultar cita aparece los datos de la cita solicitada anteriormente. 2. Si la actividad seleccionada es salir volverá a la página principal. El usuario debe haber ejecutado el caso de uso autenticar usuario. Se debe haber ejecutado el caso de uso solicitar cita. Flujo alternativo de eventos Ninguno. Pos condiciones Cita modificada. Tabla 14. Descripción Caso de Uso Cancelar Cita. Caso de uso Cancelar Cita Objetivo Ofrecer al usuario la opción de cancelar una cita. Actores Administrador, Odontólogo, Asistente, Paciente. 1. Se presenta al usuario una opción para cancelar una cita. 2. Si el usuario lo desea puede crear la cita nuevamente 48

50 Curso normal de eventos en el horario y fecha que el paciente lo desee. 3. Si la actividad seleccionada es cerrar sesión volverá a la página principal. Precondiciones El usuario debe haber ejecutado el caso de uso autenticar usuario. Se debe haber ejecutado el caso de uso solicitar cita. Flujo alternativo de eventos Si el usuario desea cancelar la cita aparecerá un mensaje preguntando si está seguro de hacerlo. Pos condiciones Cita modificada. Tabla 15. Descripción Caso de Uso Crear Historia Clínica. Caso de uso Crear Historia Clínica Objetivo Ofrecer al usuario la opción de crear la historia clínica de los pacientes. Actores Administrador, Odontólogo. 1. Se presenta al usuario en la pantalla la opción primer historia. Curso normal de eventos 2. El usuario debe llenar todas las secciones con las cuales cuenta la historia clínica y se guardan los cambios en la base de datos. 3. Si la actividad seleccionada es cerrar sesión volverá a la página principal. Precondiciones El usuario debe haber ejecutado el caso de uso autenticar usuario. Flujo alternativo de eventos Ninguno. Pos condiciones Historia Clínica creada. 49

51 Tabla 16. Descripción Caso de Uso Actualizar Historia Clínica. Caso de uso Actualizar Historia Clínica Objetivo Ofrecer al usuario la opción de actualizar la historia clínica de los pacientes. Actores Administrador, Odontólogo. Curso normal de eventos 1. El usuario puede actualizar únicamente la evolución salud oral de la historia clínica del paciente las veces que sea necesario. 2. Si la actividad seleccionada es cerrar sesión volverá a la página principal. Precondiciones El usuario debe haber ejecutado el caso de uso autenticar usuario. Se debe haber ejecutado el caso de uso crear historia clínica. Flujo alternativo de eventos Ninguno. Pos condiciones Historia Clínica actualizada. Tabla 17. Descripción Caso de Uso Consultar Historia Clínica. Caso de uso Consultar Historia Objetivo Ofrecer al usuario la opción de consultar la historia clínica de los pacientes. Actores Administrador, Odontólogo. 1. Se presenta al usuario una opción para consultar la historia clínica. Curso normal de eventos 2. El usuario debe ingresar la cédula para que el sistema busque la historia clínica que corresponde. 3. Se muestra en pantalla la historia clínica del paciente, el usuario puede seleccionar la sección de la historia 50

52 que desee visualizar. 4. Si la actividad seleccionada es cerrar sesión volverá a la página principal. Precondiciones El usuario debe haber ejecutado el caso de uso autenticar usuario. Se debe haber ejecutado el caso de uso crear historia clínica. Flujo alternativo de eventos En el momento de hacer la consulta la cédula del paciente debe ser válida. Pos condiciones Visualización de la historia clínica. Tabla 18. Descripción Caso de Uso Actualizar Datos de Usuarios. Caso de uso Actualizar Datos de Usuarios Objetivo Permitir al usuario del sistema actualizar y consultar. Actores Administrador, Odontólogo, Asistente, Paciente. 1. Se presenta al usuario una pantalla en donde puede actualizar y consultar sus datos básicos. 2. Si el usuario escoge actualizar solo puede cambiar los siguientes datos: ocupación, dirección, teléfono, celular y contraseña. Para cada uno aparece un link para editar. Curso normal de eventos 3. El sistema muestra en pantalla los datos actualizados. 4. Si la actividad seleccionada es cerrar sesión volverá a la página principal. Precondiciones El usuario debe haber ejecutado los casos de uso registrar y autenticar usuario. Flujo alternativo de eventos Si en el momento de editar un campo el usuario no escoge la opción actualizar el campo no tendrá ningún cambio. Pos condiciones Información de usuario actualizada. 51

53 La tabla 6 describe el caso de uso de autenticación de los usuarios administrador y odontólogo. Figura 7. Diagrama Caso de Uso Asistente. Tabla 19. Descripción Caso de Uso Enviar Sms. Caso de uso Enviar Sms Objetivo Ofrecer al asistente la opción de enviar a los pacientes un sms. Actores Asistente. Curso normal de eventos 1. Se presenta al asistente una opción para enviar sms. 2. El asistente debe ingresar la cédula del paciente para que el sistema lo busque en la base de datos y así obtener el celular al cual se envía el sms para recordar la fecha y hora de la próxima cita. 52

54 3. Si la actividad seleccionada es cerrar sesión volverá a la página principal. Precondiciones El Asistente debe haber ejecutado el caso de uso autenticar usuario. Se debe haber ejecutado el caso de uso crear cita. Flujo alternativo de eventos Si la asistente no escoge la opción de enviar el mensaje no llegará al celular del paciente. Pos condiciones Cita modificada. Las tablas 6, 11, 12, 13, 14 y 18 describen los demás casos de uso que la asistente realiza que corresponden a Autenticar Usuario, Cerrar Sesión, Solicitar Cita, Consultar Cita, Cancelar Cita y Actualizar Datos. Figura 8. Diagrama Caso de Uso Paciente. 53

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

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

57 Figura 10. Diagrama de Secuencia Registrar Usuario. La figura 11 representa como el odontólogo debe ingresar su usuario y contraseña en la interfaz que se ha creado para autenticarse, luego ingresa la cédula del paciente para verificar si está en la base de datos, si éste no se encuentra debe registrarlo. Después puede proceder a crear la historia clínica de un paciente por medio de la interfaz que se realizó para ingresar los datos que la componen. Se guarda la historia en la base de datos y vuelve a la página principal. 56

58 Figura 11. Diagrama de Secuencia Crear Historia Clínica. Para solicitar una cita como se muestra en la figura 12, el usuario (odontólogo, asistente o paciente) debe autenticarse con usuario y contraseña por medio de la interfaz de autenticación, luego ingresa los datos requeridos para crear una cita odontológica lo cual también hace por medio de una interfaz que se ha diseñado, se verifican los horarios y odontólogos disponibles. Se envía un mensaje confirmando que se ha creado la cita mostrando en pantalla el día, la hora y el odontólogo. Por último se vuelve al menú principal. 57

59 Figura 12. Diagrama de Secuencia Solicitar Cita. En la figura 13 se describe como el usuario (asistente) se debe autenticar con usuario y contraseña por medio de la interfaz, a continuación consulta las citas asignadas, crea el SMS con la fecha y hora de la próxima cita, lo envía al celular del paciente. Este mensaje se guarda en la base de datos, se confirma que el estado del mensaje ha sido enviado con éxito y por ultimo vuelve al menú principal. Los mensajes cortos de texto no se hacen de forma automática, la asistente debe consultar los pacientes programados para el día siguiente y enviarlos a los respectivos celulares de los pacientes. 58

60 Figura 13. Diagrama de Secuencia Enviar SMS. El usuario debe autenticarse con usuario y contraseña por medio de la interfaz de autenticación como lo muestra la figura 14, luego ingresa los datos que va a actualizar, se guardan los nuevos datos en la base de datos. Por último se muestra en pantalla los datos han sido actualizados y se vuelve al menú principal. Figura 14. Diagrama de Secuencia Actualizar Datos. 59

61 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: < Septiembre 23 de 2010, 8:20 p.m. 60

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

63 Figura 16. Diagrama de Actividades Asistente y Paciente. El diagrama de actividades para la asistente y el paciente que se encuentra en la figura 16, representa la forma en la que el usuario debe autenticarse, el sistema valida los datos ingresados, si el usuario se encuentra en la base de datos puede crear una cita y enviar el SMS si el usuario es el asistente. Guarda la cita, después envía el sms y guarda el sms. Si el usuario no se encuentra en la base de datos se procede a registrarse y puede realizar las actividades dichas anteriormente. Para el caso en el que el usuario es el paciente solo puede crear la cita. 62

64 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 RODRIGUEZ ALMEIDA, Miguel Ángel, Bases de Datos. México Mc. Graw Hill. P

65 Modelo de la base de Datos Figura 17. Modelo Base de Datos Dentistry Web. 64

66 Diccionario de datos. Tabla 20. Paciente. NOMBRE DE LA TABLA: PACIENTE Descripción: En esta tabla se almacenan los datos básicos de todos los usuarios. Campos Numero_documento Llave Primaria Llave Foránea Tipo de dato Longitud Double Not Null Tipo_documento Varchar 3 Nombre Varchar 30 Apellidos Varchar 30 Telefono Double Celular Double Direccion Varchar 40 Genero Char 1 Fecha_de_nacimiento Date Cargo Varchar 40 Login Varchar 15 Varchar 15 Password DESCRIPCIÓN DE LOS CAMPOS Numero_documento: Es la llave primaria de la tabla PACIENTE que se encarga de enlazar esta tabla con las demás. Tipo_documento: Este campo se refiere a tipo de identificación del paciente. Nombre: En este campo se almacenan los nombres de los pacientes del sistema. Apellidos: En este campo se almacenan los apellidos de los pacientes del sistema. Teléfono: En este campo se almacena el número de teléfono fijo de los pacientes del sistema. Celular: En este campo se almacena el número de celular de los pacientes del sistema. Direccion: En este campo se almacena la dirección de los pacientes del sistema. Genero: En este campo se almacena el género (masculino o femenino) de los pacientes del sistema. Fecha_de_nacimiento: En este campo se almacena la fecha de nacimiento de los pacientes del sistema. Login: En este campo se almacena el usuario de los pacientes para poder ingresar al sistema. Password: En este campo se almacena la contraseña de los pacientes para poder ingresar al sistema. 65

67 Tabla 21. Asistente. NOMBRE DE LA TABLA: ASISTENTE Descripción: En esta tabla se almacenan los datos básicos de todos los usuarios. Campos Numero_documento Llave Primaria Llave Foránea Tipo de dato Longitud Double Not Null Tipo_documento Varchar 3 Nombre Varchar 30 Apellidos Varchar 30 Telefono Double Celular Double Direccion Varchar 40 Genero Char 1 Fecha_de_nacimiento Date Cargo Varchar 40 Login Varchar 15 Varchar 15 Password DESCRIPCIÓN DE LOS CAMPOS Numero_documento: Es la llave primaria de la tabla ASISTENTE que se encarga de enlazar esta tabla con las demás. Tipo_documento: Este campo se refiere a tipo de identificación del asistente. Nombre: En este campo se almacenan los nombres del asistente. Apellidos: En este campo se almacenan los apellidos del asistente. Teléfono: En este campo se almacena el número de teléfono fijo del asistente. Celular: En este campo se almacena el número de celular del asistente. Direccion: En este campo se almacena la dirección del asistente. Genero: En este campo se almacena el género (masculino o femenino) del asistente. Fecha_de_nacimiento: En este campo se almacena la fecha de nacimiento de los pacientes del sistema. Cargo: en este campo se almacena el cargo de la asistente, puede ser enfermera, secretaria o solo asistente. Login: En este campo se almacena el usuario del asistente para poder ingresar al sistema. Password: En este campo se almacena la contraseña del asistente para poder ingresar al sistema. 66

68 Tabla 22. Odontólogo NOMBRE DE LA TABLA: ODONTÓLOGO Descripción: En esta tabla se almacenan los datos básicos de todos los usuarios. Campos Numero_documento Llave Primaria Llave Foránea Tipo de dato Longitud Double Not Null Tipo_documento Varchar 3 Nombre Varchar 30 Apellidos Varchar 30 Telefono Double Celular Double Direccion Varchar 40 Genero Char 1 Fecha_de_nacimiento Date Tarjeta_profesional Varchar 20 Administrador Varchar 2 Login Varchar 15 Password Varchar 15 DESCRIPCIÓN DE LOS CAMPOS Numero_documento: Es la llave primaria de la tabla ODONTÓLOGO que se encarga de enlazar esta tabla con las demás. Tipo_documento: Este campo se refiere a tipo de identificación del odontólogo. Nombre: En este campo se almacenan los nombres del odontólogo. Apellidos: En este campo se almacenan los apellidos del odontólogo. Teléfono: En este campo se almacena el número de teléfono fijo del odontólogo. Celular: En este campo se almacena el número de celular del odontólogo. Direccion: En este campo se almacena la dirección del odontólogo. Genero: En este campo se almacena el género (masculino o femenino) del odontólogo. Fecha_de_nacimiento: En este campo se almacena la fecha de nacimiento de los odontólogos del sistema. Tarjeta_profesional: En este campo se almacena el número de tarjeta profesional del odontólogo. Administrador: Este campo se refiere a si el odontólogo es administrador o no. Login: En este campo se almacena el usuario del odontólogo para poder ingresar al sistema. Password: En este campo se almacena la contraseña del odontólogo para poder ingresar al sistema. 67

69 Tabla 23. Acudiente. NOMBRE DE LA TABLA: ACUDIENTE Descripción: En esta tabla se almacenan los títulos o estudios que ha realizado cada odontólogo. Campos Numero_documento Llave Primaria Llave Foránea Tipo de dato Longitud Double Not Null Tipo_documento Varchar 3 Nombre Varchar 30 Apellidos Varchar 30 Telefono Double Direccion Varchar 40 DESCRIPCIÓN DE LOS CAMPOS Numero_documento: Es la llave primaria de la tabla ACUDIENTE que se encarga de enlazar esta tabla con las demás. Tipo_documento: Este campo se refiere a tipo de identificación del acudiente del paciente. Nombre: En este campo se almacenan los nombres del acudiente del paciente. Apellidos: En este campo se almacenan los apellidos del acudiente del paciente. Teléfono: En este campo se almacena el número de teléfono fijo del acudiente del paciente. Celular: En este campo se almacena el número de celular del acudiente del paciente. Direccion: En este campo se almacena la dirección del acudiente del paciente. 68

70 Tabla 24. Estudio. NOMBRE DE LA TABLA: ESTUDIO Descripción: En esta tabla se almacenan los títulos o estudios que ha realizado cada odontólogo. Campos Tipo de dato Longitud Not Null Int 2 Titulo Varchar 20 Institucion Varchar 20 Id_estudio Llave Primaria Llave Foránea Fecha_de_grado Numero_documento_odontologo Date Double DESCRIPCIÓN DE LOS CAMPOS Id_estudio: En este campo se almacena el Id del estudio del odontólogo. Titulo: En este campo se almacena el estudio realizado por el odontólogo. Institucion: En este campo se almacena la institución en donde el odontólogo realizó un estudio. Fecha_de_grado: En este campo se almacena la fecha en que se graduó el odontólogo. Numero_documento_odontólogo: Es la llave primaria de la tabla ODONTÓLOGO. Además es una llave foránea en la tabla ESTUDIO. 69

71 Tabla 25. Historia_Clínica. NOMBRE DE LA TABLA: HISTORIA_CLINICA Descripción: En esta tabla se almacenan la información que debe llevar la historia clínica odontológica. Campos Tipo de dato Longitud Not Null Int 10 Antecedente_personal Varchar 40 Antecedente_familiar Varchar 40 Numero_historia Llave Primaria Llave Foránea Fecha_de_actualizacion Numero_documento_paciente Date Double DESCRIPCIÓN DE LOS CAMPOS Numero_historia: es la llave primaria de la tabla HISTORIA_CLÍNICA que se encarga de enlazar esta tabla con las demás. Antecedente_personal: es el campo que almacena los antecedentes personales del paciente. Antecedente_familiar: es el campo que almacena los antecedentes familiares del paciente. Fecha_de_actualizacion: este campo almacena la fecha en que se actualiza la historia clínica. Numero_documento_paciente: es la llave foránea de la tabla PACIENTE. 70

72 Tabla 26. Plan_de_Tratamiento. NOMBRE DE LA TABLA: PLAN_DE_TRATAMIENTO Descripción: En esta tabla se almacenan la información del tratamiento que se le realiza al paciente. Campos Numero_tratamiento Numero_historia Llave Primaria Llave Foránea Tipo de dato Longitud Not Null Int 4 Double Nombre Varchar 40 Descripcion Varchar 200 Estado Varchar 12 Aprobacion Varchar 2 Fecha_inicio Date Fecha_fin Date Anomalias Varchar 200 DESCRIPCIÓN DE LOS CAMPOS Numero_tratamiento: es la llave primaria de la tabla PLAN_DE_TRATAMIENTO que se encarga de enlazar esta tabla con las demás. Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA. Nombre: es el campo que almacena el nombre del tratamiento. Descripción: es el campo que almacena la descripción del tratamiento odontológico al que se someterá el paciente Estado: este campo almacena los estados del tratamiento (En Desarrollo, Finalización, Sin Realizar, Aplazado). Aprobación: este campo almacena la aprobación del paciente a que se le haga el respectivo tratamiento odontológico. Fecha_inicio: este campo almacena la fecha de inicio del tratamiento. Fecha_fin: este campo almacena la fecha de finalización del tratamiento. Anomalías: este campo almacena las anomalías. 71

73 Tabla 27. Examen_Básico. NOMBRE DE LA TABLA: EAMEN_BASICO Descripción: la tabla almacena la información sobre el examen básico que se le realiza al paciente. Campos Tipo de dato Longitud Not Null Int 2 Nombre Int 40 Detalle Varchar 200 Id_examen Llave Primaria Llave Foránea Numero_historia Double DESCRIPCIÓN DE LOS CAMPOS Id_examen: es la llave primaria de la tabla EAMEN_BASICO que se encarga de enlazar esta tabla con las demás. Nombre: este campo almacena el nombre del examen que se realizara. Detalle: Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA. Tabla 28. Diente. NOMBRE DE LA TABLA: DIENTE. Descripción: la tabla almacena la información sobre los dientes del paciente. Campos Tipo de dato Longitud Not Null Int 2 Cop Varchar 8 Manifestacion Varchar 200 Numero_diente Numero_historia Llave Primaria Llave Foránea Double DESCRIPCIÓN DE LOS CAMPOS Numero_diente: es la llave primaria de la tabla DIENTE que se encarga de enlazar esta tabla con las demás. Cop: cariado, opturado, perdido. Manifestación: campo que almacena si es blanda o calcificada. Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA. 72

74 Tabla 29. Evolución NOMBRE DE LA TABLA: EVOLUCION. Descripción: la tabla almacena la información sobre la evolución de la historia clínica. Campos Fecha Llave Primaria Llave Foránea Tipo de dato Date Hora Not Null Time Descripcion Varchar 200 Int 7 Valor Numero_historia Longitud Double DESCRIPCIÓN DE LOS CAMPOS Fecha: es la llave primaria de la tabla EVOLUCIÓN que se encarga de enlazar esta tabla con las demás y almacena la fecha en la que se presenta la evolución en el tratamiento. Hora: este campo almacena la hora en la cual se realiza el tratamiento. Descripción: almacena la información de lo que se realizó al paciente y que hace parte del tratamiento. Valor: es el valor que el paciente cancela por el servicio que se le presta en esa fecha. Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA. 73

75 Tabla 30. Anexos. NOMBRE DE LA TABLA: ANEOS Descripción: esta tabla almacena la información de los anexos que se adjuntan a los pacientes. Campos Numero_anexo Llave Primaria Llave Foránea Tipo de dato Longitud Not Null Int 3 Int 15 Varchar 200 Tipo_anexo Direccion_interna Numero_historia Double DESCRIPCIÓN DE LOS CAMPOS Numero_anexo: es la llave primaria de la tabla ANEOS que se encarga de enlazar esta tabla con las demás. tipo_anexo: es el campo que almacena los tipos de anexo, pueden ser imágenes, radiografías, fotos, etc Direccion_interna: es el campo que almacena la dirección de la carpeta que contiene los anexos. Numero_historia: es la llave foránea de la tabla HISTORIA_CLINICA. 74

76 Tabla 31. Citas. NOMBRE DE LA TABLA: CITAS Descripción: En esta tabla se almacena el Id del paciente y del odontólogo, la fecha y hora de la cita. Campos Fecha Llave Primaria Llave Foránea Tipo de dato Hora Longitud Not Null Date Time Numero_documento_paciente Double Numero_documento_odontologo Double Numero_documento_asistente Double DESCRIPCIÓN DE LOS CAMPOS Fecha: Es la llave primaria de la tabla CITAS que se encarga de enlazar esta tabla con las demás. En este campo se almacena la fecha de la cita odontológica. Hora: En este campo se almacena la hora de la cita odontológica. Numero_documento_paciente: Es la llave primaria de la tabla PACIENTE. Además es una llave foránea de la tabla CITAS. Numero_documento_odontólogo: Es la llave primaria de la tabla ODONTÓLOGO. Además es una llave foránea de la tabla CITAS. Numero_documento_asistente: Es la llave primaria de la tabla ASISTENTE. Además es una llave foránea de la tabla CITAS. 75

77 Tabla 32. Servicio. NOMBRE DE LA TABLA: SERVICIO. Descripción: la tabla almacena la información sobre los servicios que presta el consultorio. Campos Llave Primaria Id_servicio Llave Foránea Tipo de dato Longitud Not Null Int 2 Varchar 20 Nombre_servicio Descripcion_de_servicio Text DESCRIPCIÓN DE LOS CAMPOS Id_servicio: es la llave primaria de la tabla SERVICIO que se encarga de enlazar esta tabla con las demás. Nombre_servicio: es el nombre de los servicios que se prestan en el consultorio. Descripción_de_servicio: es la descripción de los servicios que se prestan en el consultorio. Tabla 33. Servicios_Por_Odontólogo. NOMBRE DE LA TABLA: SERVICIOS_POR_ODONTOLOGO. Descripción: Es la tabla intermedia de las tablas ODONTOLOGO y SERVICIO. Campos Id_servicio_odontologo Llave Primaria Llave Foránea Tipo de dato Longitud Not Null Int 2 8 Id_servicio Int Numero_documento_odontologo Double DESCRIPCIÓN DE LOS CAMPOS Id_servicio_odontologo: es la llave primaria de la tabla SERVICIO_POR_ODONTOLOGO que se encarga de enlazar esta tabla con las demás. id_servicio: es la llave foránea de la tabla SERVICIO. Numero_documento_odontologo: es la llave foránea de la tabla ODONTOLOGO. 76

78 Tabla 34. SMS. NOMBRE DE LA TABLA: SMS Descripción: En esta tabla se almacena el mensaje SMS, su hora de salida y estado. Campos Id_sms Llave Primaria Llave Foránea Tipo de dato Longitud Double Hora_salida_sms Not Null Time Mensaje_sms Varchar 100 Estado Varchar 20 Numero_documento_paciente Double DESCRIPCIÓN DE LOS CAMPOS Id_sms: Es la llave primaria de la tabla SMS que se encarga de enlazar esta tabla con las demás. Hora_salida_sms: En este campo se almacena la hora de salida del mensaje. Mensaje_sms: En este campo se almacena el contenido del mensaje. Estado: En este campo se almacena el estado del mensaje, si el paciente lo recibió o no. Numero_documento_paciente: Es la llave primaria de la tabla PACIENTE. Además es una llave foránea de la tabla SMS. 77

79 Asignación de Privilegios. Tabla 35. Usuario: Administrador. USUARIO: ADMINISTRADOR UPDATE SELECT PERSONA TABLAS INSERT DELETE PACIENTE ACUDIENTE ASISTENTE ODONTÓLOGO ESTUDIO SERVICIOS_POR_ODONTÓLOGO SERVICIOS HISTORIA CLÍNICA PLAN DE TRATAMIENTO DIENTE EÁMEN BÁSICO ANEOS EVOLUCIÓN CITAS SMS Tabla 36. Usuario: Odontólogo. USUARIO: ODONTÓLOGO TABLAS UPDATE SELECT PERSONA INSERT DELETE PACIENTE ACUDIENTE ODONTÓLOGO ESTUDIO SERVICIOS_POR_ODONTÓLOGO SERVICIOS HISTORIA CLÍNICA PLAN DE TRATAMIENTO DIENTE EÁMEN BÁSICO ANEOS EVOLUCIÓN CITAS ASISTENTE SMS 78

80 Tabla 37. Usuario: Asistente. USUARIO: ASISTENTE TABLAS PERSONA INSERT DELETE UPDATE SELECT PACIENTE ACUDIENTE ASISTENTE ODONTÓLOGO ESTUDIO SERVICIOS_POR_ODONTÓLOGO SERVICIOS HISTORIA CLÍNICA PLAN DE TRATAMIENTO DIENTE EÁMEN BÁSICO ANEOS EVOLUCIÓN CITAS SMS Tabla 38. Usuario: Paciente. USUARIO: PACIENTE TABLAS PERSONA INSERT DELETE UPDATE SELECT PACIENTE ACUDIENTE ASISTENTE ODONTÓLOGO ESTUDIO SERVICIOS_POR_ODONTÓLOGO SERVICIOS HISTORIA CLÍNICA PLAN DE TRATAMIENTO DIENTE EÁMEN BÁSICO ANEOS EVOLUCIÓN CITAS SMS 79

81 Diseño de las interfaces y el odontograma. Para cumplir con los requerimientos del aplicativo también se crean las interfaces y el odontograma, los cuales deben ser amigables en el momento en que los usuarios interactúen con el aplicativo, puesto que éstas son el medio de comunicación entre los usuarios y el sistema. La herramienta que se usa para este desarrollo es Dreamweaver, Para esto se hizo en código HTML (HyperText Markup Language) el cual está plasmado en los JSP s del aplicativo, se descargó una plantilla la cual se usa como interfaz para todas las pantallas, en la parte izquierda se encuentran los links (command Link) que van asociados a imágenes y los cuales generan una acción determinada. Para el odontograma, como se muestra en la figura 18, se crea una matriz de las imágenes de los dientes y se enumeran, para que cada vez que se registra un diente por medio de la interfaz se refresque la imagen. El bean es el que realiza las consultas y guarda la información registrada del odontograma a la hora de llenar la historia odontológica. Figura 18. Diseño del Odontograma. 80

82 En el momento de llenar la historia clínica en cada sección se usan determinados elementos para llenar este registro, por ejemplo en los campos que se deben llenar datos de usuario se trabaja con un Text-Area como se muestra en la figura 19, en el plan de tratamiento al escoger los tratamientos a realizar se usan Checkbox como se muestra en la figura 20, ya que esta función sirve para escoger varios elementos. En la parte de hábitos de higiene oral se usan Radio Butons que en este caso se emplean para escoger solo una opción. Para las consultas se usan herramientas de Select One Menu, que son las listas que aparecen para escoger una opción que se encuentre en ellas. Por último el uso de botones (command buton) que generan una acción determinada sobre los beans en algunos casos. Figura 19. Herramientas para el diseño de Interfaces. 81

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

84 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 Implementación. A continuación se describen las capas en las que se basa la arquitectura J2EE, que se tendrán en cuenta para la implementación de la aplicación y son: capa cliente, capa web, capa negocio y capa integración o datos. Se usará el escenario basado en la web representado en la figura 21, el cual unifica la capa de presentación y la capa de negocio, se escogió porque la plataforma J2EE no obliga a usar todas las capas, en este caso el aplicativo no es tan complejo como para requerir usar EJB (Enterprise Java Beans), para esto el escenario web nos ofrece un mecanismo adecuado para darle solución al objetivo principal y además es el más usado actualmente. Esto permite dar inicio a la implementación y pruebas del aplicativo web creado para la administración de citas e historias odontológicas. 83

85 Figura 21. Escenario Basado en la Web de J2EE Capa de Integración o Datos. En la figura 22 se muestra como se hace la conexión a la base de datos, para este fin llamada odontocentro, ya que sin esta no es posible agregar los datos que se necesitan para que el aplicativo funcione correctamente y de acuerdo a los requerimientos antes mencionados. Para esto se creó una clase en netbeans llamada Conexión en donde importa la librería java.sql, debe contener el nombre, el login, password de la base de datos y el url de conexión. 84

86 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:

87 Figura 23. Propiedades de la base de datos. Para ver la consistencia y el cumplimiento de la integridad de los datos, se hacen consultas para determinar estas características. En la figura 24 se hace una consulta para ver que personas se encuentran registradas en la base de datos. 86

88 Figura 24. Consulta Personas. En la figura 25 se hace una consulta para ver las citas que se han programado y están guardadas en la base de datos. Figura 25. Consulta Citas. 87

89 En la figura 26 encontramos a los pacientes que se encuentran registrados en la base de datos. Figura 26. Consulta Pacientes. La figura 27 es una consulta de los odontólogos que también están registrados en el sistema. Figura 27. Consulta Odontólogos. 88

90 En la figura 28 podemos encontrar una de las consultas que realiza el asistente por medio de la interfaz, para saber que citas hay programadas en un día determinado, mostrando el nombre y el número de documento del paciente, el odontólogo que lo atenderá y la fecha. Figura 28. Consulta Citas Agendadas 89

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

92 Figura 29. JavaBeans de la aplicación. En esta capa también se encuentra el proceso que se lleva a cabo para implementar la mensajería de texto a través de un servicio llamado elibom, el cual ofrece un ejemplo del código en java, el cual conecta la aplicación al Gateway de mensajería para enviar mensajes SMS de forma automática. En la figura 30 se muestra el código que se implementó en la aplicación para le envió de mensajes SMS. 91

93 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 para que se pueda usar el mail, contraseña (del registro), número de celular y mensaje que se va a enviar 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: < Octubre 7 de 2010, 4:01 p.m. 92

94 JSP s para actualizar datos de los usuarios. JSP s para asignar citas. JSP s para la consulta de citas. JSP s para envio de SMS. JSP s para errores. JSP s para registros. JSP s para iniciar sesión. JSP s para reportes. JSP s para cada sección de la historia odontológica. 93

95 Figura 31. JSP s de la aplicación. El código ML 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 Capa Cliente. Es la interfaz gráfica del sistema y se encarga en interactuar con el usuario. La figura 32 es la interfaz del aplicativo que sirve para que un paciente se pueda registrar por medio de la página web. Las demás interfaces se encuentran en el manual de usuario, ya que con ellas se explica paso a paso el funcionamiento del aplicativo. 94

96 Figura 32. Interfaz Gráfica del Aplicativo 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 Pruebas del sistema, [artículo en línea] Disponible desde Internet en: < Octubre 6 de 2010, 10:34 a.m. 25 TUYA Javier, RAMOS ROMAN Isabel, DOLADO COSIN Javier, Técnicas Cuantitativas Para La Gestión En La Ingeniería del Software, Editores NETBIBLO, España 2007, p

97 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 Prueba Registrar Usuario. Se realizan las pruebas a los registros de los pacientes que se hacen por medio de la página web, los demás usuarios del sistema deben ser registrados por el administrador, se describe esta prueba en la tabla 41. Tabla 41. Caso de Prueba Registrar Usuario. Caso de Prueba: Registrar Usuario. Objetivo: Probar la acción de registrar el paciente, odontólogo, asistente y administrador. 96

98 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 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 Prueba Historia Clínica Odontológica. Se realizan las pruebas a la historia clínica, para esto el odontólogo y el administrador deben tener permisos para acceder a esta, es decir, que la pueden crear y consultar. La tabla 43 corresponde a la prueba crear historia clínica odontológica y la tabla 44 hace referencia al caso de prueba clínica odontológica. Tabla 43. Caso de Prueba Crear Historia Clínica Odontológica. Caso de Prueba: Crear Historia Clínica Odontológica. Objetivo: Probar la acción de crear la historia clínica odontológica de un paciente. Condiciones de la prueba: Los usuarios deben autenticados con anterioridad. Entradas: Usuario y Contraseña. Salidas deseadas: El usuario crea la historia clínica odontológica. 97

99 Tabla 44. Caso de Prueba Consultar Historia Clínica Odontológica. Caso de Prueba: Consultar Historia Clínica Odontológica. Objetivo: Probar la acción de consultar la historia clínica odontológica de un paciente. Condiciones de la prueba: Los usuarios deben autenticados con anterioridad. Entradas: Número de documento del paciente. Salidas deseadas: El usuario consulta la historia clínica odontológica Prueba Citas. Para realizar estas pruebas los usuarios deben estar autenticados con anterioridad en el sistema, en este módulo se pueden solicitar y cancelar citas que corresponden a las tablas 45 y 46 respectivamente. Tabla 45. Caso de Prueba Solicitar Cita. Caso de Prueba: Solicitar Cita. Objetivo: Probar la acción de solicitar una cita odontológica. Condiciones de la prueba: Los usuarios deben estar autenticados con anterioridad. Cuando el usuario ingrese los datos requeridos se confirma la disponibilidad para crear la cita. Entradas: Número de documento del paciente, día, fecha, hora de la cita, y odontólogo disponible. Salidas deseadas: El usuario Solicita la cita odontológica. Tabla 46. Caso de Prueba Cancelar Cita. Caso de Prueba: Cancelar Cita. Objetivo: Probar la acción de cancelar una cita odontológica. Condiciones de la prueba: Los usuarios deben autenticados con anterioridad. Entradas: Número de documento del paciente. Salidas deseadas: El usuario cancela la cita odontológica. 98

100 Prueba Enviar Sms. Después que la asistente se autentica procederá a enviar el sms al celular del paciente indicando la fecha y hora de su próxima cita odontológica como se muestra en la tabla 47. Tabla 47. Caso de Prueba Enviar SMS. Caso de Prueba: Enviar Sms. Objetivo: Probar la acción de enviar un mensaje de texto al celular de los pacientes para recordar la fecha y hora de la próxima cita odontológica. Condiciones de la prueba: La asistente debe estar autenticada con anterioridad y la información del paciente debe estar en la base de datos. Entradas: Número de documento del paciente, numero de celular y mensaje. Salidas deseadas: Se envía el sms. En la figura 33 se representa el caso de prueba enviar un mensaje de texto corto, ingresado desde el aplicativo. Figura 33. Envio de SMS 99

101 En la figura 34 se muestra en la base de datos que el mensaje de texto corto ha sido enviado con éxito a su destinatario. Figura 34. Confirmación de Salida SMS 100

102 5.5. INTEGRACIÓN Y PRUEBAS DEL SISTEMA. Seguido de las pruebas funcionales se procede a realizar las pruebas del sistema en conjunto, esto se hace para determinar si se cumplen con los requerimientos, identificar y corregir los errores que se pueden presentar en el funcionamiento del aplicativo. Todas las pruebas que a continuación se describen en las tablas 48, 49, 50 y 51 se han hecho a través de la interfaz creada para la comunicación entre el usuario y el sistema. Tabla 48. Caso de Prueba Registrar Usuario Existente. Caso de Prueba: Registrar Usuario Existente. Objetivo: Probar la acción de registrar un usuario que ya existe en la base de datos. Condiciones de la prueba: Llenar el registro con el mismo número de documento. Entradas: Nombre, apellidos, estado civil, sexo, tipo de documento, número de documento, fecha de nacimiento, ocupación dirección barrio teléfono celular. Salidas deseadas: El usuario ya se encuentra registrado. Al hacer la prueba se identificó que el sistema no valida si existe el número de documento que el usuario ingresa y lo deja registrar. Al revisar en la base de datos no almacena de nuevo ese registro y deja el que ya se había creado. 101

103 Figura 35. Error Registro. En la figura 35 se muestra el error corregido se validó que el número de documento que ingresa el usuario no se encuentre en la base de datos, si existe, envía un mensaje diciendo que el usuario ya está registrado. Tabla 49. Caso de Prueba Registrar Usuario con datos no válidos. Caso de Prueba: Registrar Usuario con datos no válidos. Objetivo: Probar la acción de registrar un usuario con datos que no son válidos. Condiciones de la prueba: Llenar el registro. Entradas: Nombre, apellidos, estado civil, sexo, tipo de documento, número de documento, fecha de nacimiento, ocupación, dirección, barrio, teléfono, celular no válidos. Salidas deseadas: No se pudo realizar el registro, compruebe los datos ingresados. Se identifica que el sistema hace el registro sin enviar ningún mensaje de error, pero no guarda ese registro en la base de datos. 102

104 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

105 Tabla 51. Autenticar usuarios con datos no válidos. Caso de Prueba: Autenticar usuarios con datos no válidos. Objetivo: Probar la acción de autenticar usuarios con datos no válidos. Condiciones de la prueba: ninguna. Entradas: Usuario y contraseña. Salidas deseadas: el usuario o la contraseña son incorrectos. Figura 37. Error Registro. En el momento que el usuario quiera ingresar al sistema, debe digitar el usuario y contraseña que se le asignaron en el proceso de registro y con los cuales se identifica. La figura 37 muestra que la prueba se realizó satisfactoriamente ya que se validan que los datos son correctos. 104

106 5.6. FUNCIONAMIENTO Y MANTENIMIENTO Esta fase no se realizó, porque, no es inmediata sino que hace parte de un proceso de acompañamiento a mediano plazo, en el cual se debe tener disponibilidad para solucionar problemas e imprevistos que se generan en el uso del software, mientras la persona que lo utiliza en lo cotidiano se capacita totalmente. 105

107 6. PRESENTACIÓN Y ANÁLISIS DE RESULTADOS El producto final es un software que cumple con las necesidades de un consultorio odontológico que le permita administrar las historias clínicas odontológicas y las citas. Por medio del sitio web se facilita al paciente el proceso de solicitud de una cita, ya que muchas veces el servicio telefónico no está disponible o es más ágil para el usuario hacer uso de internet para este fin. Para alcanzar los objetivos propuestos se desarrollaron con éxito cada una de las etapas establecidas en la metodología del modelo en cascada y se presentan los siguientes resultados: Análisis y definición de requerimientos Una vez realizadas las encuestas a los pacientes y la entrevista a la odontóloga en el consultorio que se utilizó como base, se hizo el levantamiento de la información, se identificaron los requerimientos funcionales y no funcionales para determinar el comportamiento del sistema. Posteriormente se realizó una tabulación de los datos adquiridos. La odontóloga, consideró que era necesario sistematizar la información ya que las tendencias tecnológicas van evolucionando y estas permiten agilizar los procesos que se llevan actualmente en el consultorio. También por medio del aplicativo web existe la oportunidad para darse a conocer a nivel mundial y de esta forma hacer que los visitantes a su página conozcan los servicios del consultorio odontológico. Igualmente la mayoría de los encuestados coincidieron en que para ellos sería más cómodo, rápido y fácil solicitar o cancelar su próxima cita odontológica por medio de una página web, ya que en ella se pueden visualizar horarios, fechas y odontólogos disponibles con su respectiva especialidad. 106

108 Diseño del sistema Se definieron los 4 actores que interactúan en el sistema (Administrador, Odontólogo, Asistente y Paciente), se elaboraron los diferentes diagramas de casos de uso para cada uno de los actores especificando las funciones y actividades que pueden realizar en el sistema y por último estos se describieron de manera secuencial. Diseño del software Se tomaron ya elaborados los diagramas de casos de uso, se diseñaron los de secuencia, clases y actividades para esta etapa, se diseñó el modelo de la base de datos, se establecieron privilegios; a medida que se fue construyendo el software los diagramas mencionados fueron cambiando poco a poco pero sin modificar los requerimientos iniciales que se obtuvieron por medio de las encuestas realizadas en el consultorio. Implementación y pruebas de unidades Se implementó la aplicación basada en la arquitectura J2EE creando las capas que la componen: capa cliente, capa web, capa negocio y capa integración o datos. Para esto se codificaron las clases y métodos que dan soporte al escenario basado en la web el cual unifica la capa de presentación y la capa de negocio y no obliga al uso de EJB. De la misma manera se estableció la conexión con la base de datos, se diseñó el odontograma y las interfaces gráficas para la comunicación entre el usuario y el sistema. En la fase de pruebas de unidades se realizaron las pruebas de caja negra las cuales se centran en lo que se espera de cada uno de los módulos implementados, se ejecutó cada uno de ellos y en el momento que se encontraron fallos se procedió a localizarlos y repararlos. 107

109 Integración y pruebas del sistema. Se realizaron las pruebas del sistema en conjunto con el fin de determinar si se cumplieron los requerimientos y corregir los errores que se presentaron en el funcionamiento del aplicativo. Con estas correcciones se da por terminada esta fase y se puede proceder a hacer mejoras futuras. Funcionamiento y mantenimiento Esta fase requiere, como ya se dijo anteriormente, disponibilidad y acompañamiento por parte del ingeniero mientras en el consultorio se tiene la capacitación necesaria para el uso óptimo del software. En definitiva, se confirmó la validez del uso de este software para el consultorio odontológico porque su uso facilita el trabajo y ayuda en este caso a esta disciplina a mejorar sus procesos como lo es la atención a los pacientes. Además la tecnología aplicada a las ciencias hace más efectivo el trabajo de los profesionales. 108

110 CONCLUSIONES Los requerimientos obtenidos son la base para empezar a construir el software de acuerdo a las necesidades del usuario final, estos ayudan a establecer las entradas, procesos y salidas que el aplicativo debe generar para su buen funcionamiento. El modelo de la base de datos permitió construir una representación gráfica de las entidades, atributos y relaciones con las que cuenta el aplicativo. Este diseño facilitó que la información guardada funcione de una manera integral en el sistema, haciendo que esta no sea redundante y repetitiva. La autenticación de los usuarios que ingresan al sistema se hizo por medio de la identificación de los privilegios con los que cuenta cada uno. Se establece un usuario y contraseña para restringir el acceso a personas que no están autorizadas para el uso de los servicios con los que el aplicativo cuenta. Se diseñó el software basado en un escenario web que se trabaja en la plataforma J2EE, para llegar a este diseño se crearon los diagramas de casos de uso, secuencia, clases y actividades; los cuales son establecidos por el estándar UML. Las interfaces gráficas y el odontograma se diseñaron con el motor de desarrollo dreamweaver que permite combinar los diseños en HTML e integrarlos en el código java. El odontograma es un diseño ya establecido para la representación de las características de los dientes del ser humano, se incluye esta representación para una persona adulta o un niño sobre los cuales se deben señalar las patologías que tienen o tratamientos que se deben realizar a los pacientes. Las pruebas permitieron detectar los errores y fallas identificadas a lo largo del desarrollo del proyecto; a partir de estas se corrigieron para hacer entrega de un software que cumple con los requerimientos planteados. 109

111 RECOMENDACIONES Incluir los temas que abarcan la plataforma J2EE en las materias que son electivas para el programa de ingeniería de sistemas, ya que está presente en las nuevas tecnologías y actualmente no se encuentra mucha información acerca de cómo hacer uso de ella. El buen modelamiento de la base de datos debe reflejar todas las entidades y atributos imprescindibles para que se puedan guardar los datos, éste es uno de los pasos más tediosos para la realización de una aplicación que interactúe con ésta, ya que si no es bien modelada se puede tardar más del tiempo estimado para la culminación del proyecto. Cumplir con todas las etapas de manera secuencial establecidas en la metodología que se escoja, puesto que en cada una de ellas se pueden solucionar los inconvenientes que se presenten en el momento y así no tener dificultades graves con el producto final. Elegir un adecuado proveedor de mensajería que permita conectar la aplicación al servicio SMS que este presta. Adquirir un servicio de hosting que soporte el motor de bases de datos MySql, el servidor de aplicaciones Apache Tomcat y el lenguaje java para usar el aplicativo en la web. En el momento de poner en funcionamiento la aplicación es necesario reiniciar el servidor Tomcat para que guarde correctamente en la base de datos; cuando la aplicación esté en internet el hosting lo hace automáticamente. Se pueden adicionar mejoras a la aplicación según las necesidades de los diferentes consultorios odontológicos, incluyendo nuevos módulos para elaborar un software competitivo en el mercado. 110

112 BIBLIOGRAFÍA ARIZA, Lina. Panorámica del software libre en Colombia. En Sistemas. SeptiembreNoviembre, 2004, vol.90. AVELLANAL DURANTE, Ciro, Diccionario Odontológico. Buenos Aires: Mundi, p. DEBRAUER, LAUREN Y VAN DER HEIDE, FIEN UML2, Ediciones ENI. Barcelona p. DEITEL, Harvey y Deitel Paul. Como Programar en Java. México: Pearson Prentice Hall, p. FALGUERAS CAMPDERRICH, BENET, Ingeniería del Software, Editorial UOC. Barcelona p. JACOBSON, Ivar; Booch, Grady; Rumbaugh James. El proceso de desarrollo de software, Addison-Wesley, PRESSMAN S. Roger. Ingeniería del software un enfoque práctico. México: Mc Graw Hill, p. RODRIGUEZ ALMEIDA, Miguel Ángel. Bases de Datos, Mc. Graw Hill. P257. SOMMERVILLE, Ian. Ingeniería del software. Madrid: Pearson Educación. S.A., p. TUYA Javier, RAMOS ROMAN Isabel, DOLADO COSIN Javier, Técnicas Cuantitativas Para La Gestión En La Ingeniería del Software, Editores NETBIBLO, España 2007, 325 p. 111

113 WEITZENFELD, Alfredo. Ingeniería de software orientada a objetos con Uml. Java e internet. México: Thomson, p. 112

114 WEBGRAFÍA Dentilogic, [artículo en línea] Disponible desde Internet en: < [con acceso el 10 de marzo de 2009] Propractica Dental Software, [artículo en línea] Disponible desde Internet en: < [con acceso el 10 de marzo de 2009] Historia Clínica, [artículo en línea] Disponible desde Internet en: < [con acceso el 30 de marzo de 2009] Definición de servidor de aplicaciones, [artículo en línea] Disponible desde Internet en: < [con acceso el 01 de mayo de 2009] Qué es un servidor de aplicaciones?, [artículo en línea] Disponible desde Internet en: < [con acceso el 01 de mayo de 2009] Introducción a los servidores de aplicaciones, [artículo en línea] Disponible desde Internet en: < [con acceso el 02 de mayo de 2009] Qué es SMS?, [artículo en línea] Disponible desde Internet en: < [con acceso el 02 de mayo de 2009] Definiciones [artículo en línea] Disponible desde Internet en: < [con acceso el 10 de mayo de 2009] Gestión de Transacciones en la Plataforma J2EE, Leonardo Rodríguez Viacava Daniel Perovich [pdf en línea] Disponible desde Internet en: < [con acceso el 13 de mayo de 2009] Definición de J2EE, [artículo en línea] Disponible desde Internet en: < [con acceso el 13 de mayo de 2009] 113

115 Definición de Ingeniería de software, metodologías y ciclos de vida, [artículo en línea] Disponible desde Internet en: < > [con acceso el 31 de julio de 2010] Definición de Desarrollo en Cascada, [artículo en línea] Disponible desde Internet en: < [con acceso el 31 de julio de 2010] Framework unificado para desarrollo de interfaces J2EE, [artículo en línea] Disponible desdeinterneten:< acceso el 5 de agosto de 2010] Análisis y Diseño Orientado a Objetos, [artículo en línea] Disponible desde Internet en: < [con acceso el 8 de agosto de 2010] Definición JavaBean [artículo en línea] Disponible desde Internet en: n de JavaBean. [Con acceso Octubre 5 de 2010] Definición Diagrama de Actividades, [artículo en línea] Disponible desde Internet en: [Con acceso Septiembre 23 de 2010] Pruebas del sistema, [artículo en línea] Disponible desde Internet en: [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: TICA%20DE%20HABILITACION/Anexos%20Guia%20Practica%20ajustados/Anexo%20N %C2%B0%2037%20Protocolo%20de%20Uso%20y%20Manejo%20Historia%20Clinica.do c, [Con acceso Agosto 5 de 2010] 114

116 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. PROFILAIS: conjunto de medios o procedimientos que se emplean para prevenir las enfermedades. RESINA: biomaterial para restauración dental, su principal diferencia con la amalgama es su color que brinda mayor estética. SELLANTE: resina fluida que se utiliza para sellar las fosas y fisuras de los dientes jóvenes para prevenir la caries dental. 115

117 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, ML 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. ML: Extensible Markup Language (ML) es un sencillo, formato de texto muy flexible derivado de SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, ML 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, ML también está desempeñando un papel cada vez más importante en el intercambio de una amplia variedad de datos en la Web y en otros lugares. 116

118 ANEO A. Ejemplo de procedimiento institucional documentado para el uso y manejo de la historia clínica de un servicio odontológico ANEO A. INSTITUCION DOCUMENTO PROCEDIMIENTO INSTITUCIONAL PARA EL USO Y MANEJO DE LA HISTORIA CLÍNICA FECHA DE ELABORACIÓN: DD/MM/AAAA FECHA DE ACTUALIZACIÓN: DD/MM/AAAA CONTENIDO Definición Normatividad vigente Directivas internas sobre la Historia Clínica Historia Clínica Única Obligatoriedad de la apertura de Historia Clínica Obligatoriedad del registro Calidad de los registros en la Historia Clínica Custodia de la Historia Clínica Características de la Historia Clínica Componentes de la Historia Clínica Formatos de la Historia Clínica Historia Clínica (Apertura de Historia Clínica de Primera Vez) Evolución del Tratamiento Referencia y Contrarreferencia Consentimiento Informado Presupuesto Odontológico Instructivos de la Historia Clínica Diligenciamiento de la Historia Clínica Uso de la Historia Clínica Manejo de la Historia Clínica Archivo de Historias Clínicas Registro de salida y entrada de Historias Clínicas Foliación de Historias Clínicas Registro general de Historias Clínicas Anexos específicos de la Historia Clínica 117

119 1. DEFINICIÓN. En, 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, 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, se constituye en el documento clave y consustancial de la atención en salud, en este caso referida a la atención odontológica general y especializada y representa el documento básico y principal del sistema de información de la institución. 118

120 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. 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 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 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. Para cada una de las atenciones realizadas a los pacientes debe registrarse en la historia clínica las acciones realizadas, los hallazgos, las observaciones, las recomendaciones y todas las circunstancias relacionadas con la prestación de los servicios, registrando la fecha y la hora de la atención. Calidad de los registros en la Historia Clínica: La Historia Clínica debe diligenciarse en forma clara, legible, sin tachones, enmendaduras, intercalaciones, sin dejar espacios en blanco y sin utilizar siglas. Cada anotación debe llevar la fecha y hora en la que se realiza, con el nombre completo y firma del autor de la misma. 119

121 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 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, se concibe en dos dimensiones prácticas que son: 120

122 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, son los siguientes, aquí solamente mencionados debido a que serán descritos en detalle es los numerales 6 y 7 de formatos e instructivos respectivamente: Número de Historia Clínica Fecha y Hora de atención Datos personales del paciente: número y tipo de documento de identidad, fecha de nacimiento, edad, estado civil, dirección, aseguradora, tipo de vinculación, ocupación. Datos del Responsable del paciente: nombre, parentesco, dirección, ciudad, localidad, barrio, teléfono. Datos del Acompañante del paciente: nombre, parentesco, teléfono. Causa de consulta y enfermedad actual Antecedentes personales Antecedentes Familiares Examen Físico: Estomatológico, periodontal, pulpar, tejidos dentarios y oclusión, odontograma. Diagnóstico Pronóstico Plan de tratamiento: Operatoria, endodoncia, periodoncia, ortodoncia, cirugía, prostodoncia. Descripción del Plan de Tratamiento 121

123 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 EAMEN 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, sin excepciones de ninguna índole, todos los pacientes atendidos deben tener el registro completo de la Historia Clínica incluyendo el diligenciamiento completo del Odontograma. 6. FORMATOS DE LA HISTORIA CLÍNICA. La historia clínica está compuesta por tres partes: Identificación del Usuario Registros de la Atención. Anexos. Cada uno de los formatos mencionados a continuación se anexan al presente documento y forman parte del mismo. 122

124 Historia Clínica (Apertura de Historia Clínica de Primera Vez) Evolución del Tratamiento Referencia y Contrarreferencia Consentimiento Informado Presupuesto Odontológico (Recuerde que es solo un EJEMPLO del procedimiento documentado y, por tanto, NO contiene los formatos arriba mencionados, los cuales puede encontrarlos en otros de los anexos de la Guía Práctica de habilitación). 7. INSTRUCTIVOS DE LA HISTORIA CLÍNICA. Cada uno de los formatos descritos en el numeral 6 tiene un instructivo para su diligenciamiento, los cuales se anexan al presente documento y forman parte del mismo. 8. DILIGENCIAMIENTO DE LA HISTORIA CLÍNICA. Para el diligenciamiento de la Historia Clínica el personal administrativo y los profesionales odontólogos deben conocer los formatos establecidos en, y los instructivos correspondientes a dichos formatos. Para tales efectos, en la recepción y en cada uno de los consultorios existirá una carpeta guía con los formatos en blanco y los instructivos para consulta de los funcionarios correspondientes. El diligenciamiento de la información general de la Historia Clínica, tal como: número de la historia, datos personales del paciente, responsable y acompañante, pueden ser diligenciados por la recepcionista y/o auxiliar de salud oral, mientras que los espacios destinados a la información clínica (desde Causa de Consulta y Enfermedad Actual), solamente deben ser diligenciados por el profesional odontólogo, quien realizaré el interrogatorio y el examen al paciente. 9. USO DE LA HISTORIA CLÍNICA. La Historia Clínica es un documento confidencial sometido a reserva y, por tanto, su uso 123

125 se restringe única y exclusivamente al personal asistencial odontológico de, 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. 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. Archivo de Historias Clínicas. Las hojas, documentos, placas, diseños y demás elementos de las Historias clínicas de, 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. Registro de salida y entrada de Historias Clínicas. Para el registro de salida y entrada de la Historia Clínica la recepcionista y/o auxiliar de salud oral llevará un formato en el cual se diligencia la actividad realizada y se registra el documento correspondiente. Dicho formato contendrá, como mínimo la siguiente información: Número de orden, Número de la Historia Clínica, fecha de salida; hora de salida; destino de salida (consultorio y profesional); firma del profesional que recibe la Historia; fecha de devolución; hora de devolución; firma de la auxiliar-recepcionista que recibe la Historia devuelta; chequeo de archivado en sitio del archivador. Este diligenciamiento es obligatorio y las planillas se conservan en un fólder con legajador en el mismo archivador de las Historias Clínicas. 124

126 Foliación de Historias Clínicas. Las Historias Clínicas serán foliadas con números arábigos consecutivos comenzando por la primera hoja diligenciada y continuando en orden secuencial cronológico con las hojas subsiguientes. Registro General de Historias Clínicas. Para asegurar y organizar la información básica sobre los pacientes, registrada en la Historia Clínica, la entidad llevará un listado de las Historias Clínicas de los pacientes atendidos que incluirá: Fecha de atención de primera vez, número de Historia Clínica y apellidos y nombres del paciente. Esta misma información se transcribirá progresivamente en una base de datos sistematizada (Excel) con el objeto de hacerla más expedita para consulta de. 11. ANEOS ESPECÍFICOS DE LA HISTORIA CLÍNICA. Los anexos específicos de la Historia Clínica de, que constituyen el expediente básico de la Historia, son: el formato de Historia Clínica de apertura de primera vez; el formato de evolución del tratamiento; el formato de Consentimiento Informado y el formato de Presupuesto Odontológico. Fecha de elaboración DD/MM/AAAA Fecha de aprobación DD/MM/AAAA Fecha de actualización DD/MM/AAAA Aprobado por Nombre del profesional que aprueba Firma de aprobación: NOMBRE DE LA INSTITUCIÓN, REPRESENTANTE O PROFESIONAL INDEPENDIENTE Profesión, especialidad o cargo 125

127 ANEO B. Formato Historia Clínica Odontológica 126

128 127

129 ANEO C. Resolución Número 1995 de 1999 (Julio 8) MINISTERIO DE SALUD RESOLUCIÓN NÚMERO 1995 de 1999 (JULIO 8) Por la cual se establecen normas para el manejo de la Historia Clínica EL MINISTRO DE SALUD En ejercicio de las facultades legales y en especial las conferidas por los artículos 1, 3, 4 y los numerales 1 y 3 del artículo 7 del Decreto 1292 de 1994 y CONSIDERANDO Que conforme al artículo 8 de la Ley 10 de 1990, al Ministerio de Salud le corresponde formular las políticas y dictar todas las normas científico-administrativas, de obligatorio cumplimiento por las entidades que integran el sistema de salud. Que la Ley 100 de 1993, en su Artículo 173 numeral 2, faculta al Ministerio de Salud para dictar las normas científicas que regulan la calidad de los servicios, de obligatorio cumplimiento por parte de todas las Entidades Promotoras de Salud, los Prestadores de Servicios de Salud del Sistema General de Seguridad Social en Salud y las direcciones Seccionales, Distritales y Locales de Salud. Que el Decreto 2174 de 1996, mediante el cual se organizó el Sistema Obligatorio de Garantía de Calidad del Sistema General de Seguridad Social en Salud, en el numeral 4 del Artículo 5, estableció como uno de los objetivos del mismo, estimular el desarrollo de un sistema de información sobre la calidad, que facilitara la realización de las labores de auditoria, vigilancia y control y contribuyera a una mayor información de los usuarios. Que la Historia Clínica es un documento de vital importancia para la prestación de los servicios de atención en salud y para el desarrollo científico y cultural del sector. Que de conformidad con el Artículo 35 de la Ley 23 de 1981, corresponde al Ministerio de Salud implantar modelos relacionados con el diligenciamiento de la Historia Clínica en el Sistema Nacional de Salud. 128

130 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 CAPÍTULO I DEFINICIONES Y DISPOSICIONES GENERALES ARTÍCULO 1.- DEFINICIONES. a) La Historia Clínica es un documento privado, obligatorio y sometido a reserva, en el cual se registran cronológicamente las condiciones de salud del paciente, los actos médicos y los demás procedimientos ejecutados por el equipo de salud que interviene en su atención. Dicho documento únicamente puede ser conocido por terceros previa autorización del paciente o en los casos previstos por la ley. b) Estado de salud: El estado de salud del paciente se registra en los datos e informes acerca de la condición somática, psíquica, social, cultural, económica y medioambiental que pueden incidir en la salud del usuario. c) Equipo de Salud. Son los Profesionales, Técnicos y Auxiliares del área de la salud que realizan la atención clínico asistencial directa del Usuario y los Auditores Médicos de Aseguradoras y Prestadores responsables de la evaluación de la calidad del servicio brindado. d) Historia Clínica para efectos archivísticos: Se entiende como el expediente conformado por el conjunto de documentos en los que se efectúa el registro obligatorio del estado de salud, los actos médicos y demás procedimientos ejecutados por el equipo de salud que interviene en la atención de un paciente, el cual también tiene el carácter de reservado. e) Archivo de Gestión: Es aquel donde reposan las Historias Clínicas de los Usuarios activos y de los que no han utilizado el servicio durante los cinco años siguientes a la última atención. 129

131 f) Archivo Central: Es aquel donde reposan las Historias Clínicas de los Usuarios que no volvieron a usar los servicios de atención en salud del prestador, transcurridos 5 años desde la última atención. e) Archivo Histórico. Es aquel al cual se transfieren las Historias Clínicas que por su valor científico, histórico o cultural, deben ser conservadas permanentemente. ARTÍCULO 2.- AMBITO DE APLICACIÓN. Las disposiciones de la presente resolución serán de obligatorio cumplimiento para todos los prestadores de servicios de salud y demás personas naturales o jurídicas que se relacionen con la atención en salud. ARTÍCULO 3.- CARACTERÍSTICAS DE LA HISTORIA CLÍNICA. Las características básicas son: Integralidad: La historia clínica de un usuario debe reunir la información de los aspectos científicos, técnicos y administrativos relativos a la atención en salud en las fases de fomento, promoción de la salud, prevención específica, diagnóstico, tratamiento y rehabilitación de la enfermedad, abordándolo como un todo en sus aspectos biológico, psicológico y social, e interrelacionado con sus dimensiones personal, familiar y comunitaria. Secuencialidad: Los registros de la prestación de los servicios en salud deben consignarse en la secuencia cronológica en que ocurrió la atención. Desde el punto de vista archivístico la historia clínica es un expediente que de manera cronológica debe acumular documentos relativos a la prestación de servicios de salud brindados al usuario. Racionalidad científica: Para los efectos de la presente resolución, es la aplicación de criterios científicos en el diligenciamiento y registro de las acciones en salud brindadas a un usuario, de modo que evidencie en forma lógica, clara y completa, el procedimiento que se realizó en la investigación de las condiciones de salud del paciente, diagnóstico y plan de manejo. Disponibilidad: Es la posibilidad de utilizar la historia clínica en el momento en que se necesita, con las limitaciones que impone la Ley. 130

132 Oportunidad: Es el diligenciamiento de los registros de atención de la historia clínica, simultánea o inmediatamente después de que ocurre la prestación del servicio. ARTÍCULO 4.- OBLIGATORIEDAD DEL REGISTRO. Los profesionales, técnicos y auxiliares que intervienen directamente en la atención a un usuario, tienen la obligación de registrar sus observaciones, conceptos, decisiones y resultados de las acciones en salud desarrolladas, conforme a las características señaladas en la presente resolución. CAPÍTULO II DILIGENCIAMIENTO ARTÍCULO 5.- GENERALIDADES. La Historia Clínica debe diligenciarse en forma clara, legible, sin tachones, enmendaduras, intercalaciones, sin dejar espacios en blanco y sin utilizar siglas. Cada anotación debe llevar la fecha y hora en la que se realiza, con el nombre completo y firma del autor de la misma. ARTÍCULO 6.- APERTURA E IDENTIFICACIÓN DE LA HISTORIA CLÍNICA. Todo prestador de servicios de salud que atiende por primera vez a un usuario debe realizar el proceso de apertura de historia clínica. A partir del primero de enero del año 2000, la identificación de la historia clínica se hará con el número de la cédula de ciudadanía para los mayores de edad; el número de la tarjeta de identidad para los menores de edad mayores de siete años, y el número del registro civil para los menores de siete años. Para los extranjeros con el número de pasaporte o cédula de extranjería. En el caso en que no exista documento de identidad de los menores de edad, se utilizará el número de la cédula de ciudadanía de la madre, o el del padre en ausencia de ésta, seguido de un número consecutivo de acuerdo al número de orden del menor en el grupo familiar. 131

133 PARÁGRAFO PRIMERO. Mientras se cumple el plazo en mención, los prestadores de servicios de salud deben iniciar el proceso de adecuación correspondiente a lo ordenado en el presente artículo. PARÁGRAFO SEGUNDO. Todo prestador de servicios de salud debe utilizar una historia única institucional, la cual debe estar ubicada en el archivo respectivo de acuerdo a los tiempos de retención, y organizar un sistema que le permita saber en todo momento, en qué lugar de la institución se encuentra la historia clínica, y a quien y en qué fecha ha sido entregada. ARTÍCULO 7.- NUMERACIÓN CONSECUTIVA DE LA HISTORIA CLINICA Todos los folios que componen la historia clínica deben numerarse en forma consecutiva, por tipos de registro, por el responsable del diligenciamiento de la misma. ARTÍCULO 8.- COMPONENTES. Son componentes de la historia clínica, la identificación del usuario, los registros específicos y los anexos. ARTÍCULO 9.- IDENTIFICACIÓN DEL USUARIO. Los contenidos mínimos de este componente son: datos personales de identificación del usuario, apellidos y nombres completos, estado civil, documento de identidad, fecha de nacimiento, edad, sexo, ocupación, dirección y teléfono del domicilio y lugar de residencia, nombre y teléfono del acompañante; nombre, teléfono y parentesco de la persona responsable del usuario, según el caso; aseguradora y tipo de vinculación. ARTÍCULO 10.- REGISTROS ESPECÍFICOS. Registro específico es el documento en el que se consignan los datos e informes de un tipo determinado de atención. El prestador de servicios de salud debe seleccionar para consignar la información de la atención en salud brindada al usuario, los registros específicos que correspondan a la naturaleza del servicio que presta. Los contenidos mínimos de información de la atención prestada al usuario, que debe contener el registro específico son los mismos contemplados en la Resolución 2546 de 132

134 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.- ANEOS. Son todos aquellos documentos que sirven como sustento legal, técnico, científico y/o administrativo de las acciones realizadas al usuario en los procesos de atención, tales como: autorizaciones para intervenciones quirúrgicas (consentimiento informado), procedimientos, autorización para necropsia, declaración de retiro voluntario y demás documentos que las instituciones prestadoras consideren pertinentes. PARAGRAFO PRIMERO. Los reportes de exámenes paraclínicos podrán ser entregados al paciente luego que el resultado sea registrado en la historia clínica, en el registro especifico de exámenes paraclínicos que el prestador de servicios deberá establecer en forma obligatoria para tal fin. PARAGRAFO SEGUNDO. A partir de la fecha de expedición de la presente resolución, en los casos de imágenes diagnósticas, los reportes de interpretación de las mismas también deberán registrarse en el registro especifico de exámenes paraclínicos y las imágenes diagnosticas podrán ser entregadas al paciente, explicándole la importancia de ser conservadas para futuros análisis, acto del cual deberá dejarse constancia en la historia clínica con la firma del paciente. PARAGRAFO TERCERO. Los archivos de imágenes diagnosticas que hasta la fecha existen en las Instituciones Prestadoras de servicios deberán conservarse de acuerdo a 133

135 los tiempos fijados en él artículo 15 de la presente resolución. Los prestadores de servicios podrán efectuar la entrega de las imágenes que reposan en estos archivos, al usuario, dejando constancia de ello en la historia clínica. PARAGRAFO CUARTO. En todo caso el prestador de servicios será responsable de estas imágenes, si no ha dejado constancia en la historia clínica de su entrega. Cuando existiere esta constancia firmada por el usuario, será este último el responsable de la conservación de las mismas. CAPÍTULO III ORGANIZACIÓN Y MANEJO DEL ARCHIVO DE HISTORIAS CLÍNICAS ARTÍCULO 12.- OBLIGATORIEDAD DEL ARCHIVO. Todos los prestadores de servicios de salud, deben tener un archivo único de historias clínicas en las etapas de archivo de gestión, central e histórico, el cual será organizado y prestará los servicios pertinentes guardando los principios generales establecidos en el Acuerdo 07 de 1994, referente al Reglamento General de Archivos, expedido por el Archivo General de la Nación y demás normas que lo modifiquen o adicionen. ARTÍCULO 13.- CUSTODIA DE LA HISTORIA CLÍNICA. La custodia de la historia clínica estará a cargo del prestador de servicios de salud que la generó en el curso de la atención, cumpliendo los procedimientos de archivo señalados en la presente resolución, sin perjuicio de los señalados en otras normas legales vigentes. El prestador podrá entregar copia de la historia clínica al usuario o a su representante legal cuando este lo solicite, para los efectos previstos en las disposiciones legales vigentes. PARÁGRAFO PRIMERO. Del traslado entre prestadores de servicios de salud de la historia clínica de un usuario, debe dejarse constancia en las actas de entrega o de devolución, suscritas por los funcionarios responsables de las entidades encargadas de su custodia. 134

136 PARÁGRAFO SEGUNDO. En los eventos en que existan múltiples historias clínicas, el prestador que requiera información contenida en ellas, podrá solicitar copia al prestador a cargo de las mismas, previa autorización del usuario o su representante legal. PARÁGRAFO TERCERO. En caso de liquidación de una Institución Prestadora de Servicios de Salud, la historia clínica se deberá entregar al usuario o a su representante legal. Ante la imposibilidad de su entrega al usuario o a su representante legal, el liquidador de la empresa designará a cargo de quien estará la custodia de la historia clínica, hasta por el término de conservación previsto legalmente. Este hecho se comunicará por escrito a la Dirección Seccional, Distrital o Local de Salud competente, la cual deberá guardar archivo de estas comunicaciones a fin de informar al usuario o a la autoridad competente, bajo la custodia de quien se encuentra la historia clínica. ARTÍCULO 14.- ACCESO A LA HISTORIA CLÍNICA. Podrán acceder a la información contenida en la historia clínica, en los términos previstos en la Ley: 1) El usuario. 2) El Equipo de Salud. 3) Las autoridades judiciales y de Salud en los casos previstos en la Ley. 4) Las demás personas determinadas en la ley. PARÁGRAFO. El acceso a la historia clínica, se entiende en todos los casos, única y exclusivamente para los fines que de acuerdo con la ley resulten procedentes, debiendo en todo caso, mantenerse la reserva legal. ARTÍCULO 15.- RETENCIÓN Y TIEMPO DE CONSERVACIÓN. La historia clínica debe conservarse por un periodo mínimo de 20 años contados a partir de la fecha de la última atención. Mínimo cinco (5) años en el archivo de gestión del prestador de servicios de salud, y mínimo quince (15) años en el archivo central. Una vez transcurrido el término de conservación, la historia clínica podrá destruirse. 135

137 ARTÍCULO 16.- SEGURIDAD DEL ARCHIVO DE HISTORIAS CLÍNICAS. El prestador de servicios de salud, debe archivar la historia clínica en un área restringida, con acceso limitado al personal de salud autorizado, conservando las historias clínicas en condiciones que garanticen la integridad física y técnica, sin adulteración o alteración de la información. Las instituciones prestadoras de servicios de salud y en general los prestadores encargados de la custodia de la historia clínica, deben velar por la conservación de la misma y responder por su adecuado cuidado. ARTÍCULO 17.- CONDICIONES FÍSICAS DE CONSERVACIÓN DE LA HISTORIA CLÍNICA. Los archivos de historias clínicas deben conservarse en condiciones locativas, procedimentales, medioambientales y materiales, propias para tal fin, de acuerdo con los parámetros establecidos por el Archivo General de la Nación en los acuerdos 07 de 1994, 11 de 1996 y 05 de 1997, o las normas que los deroguen, modifiquen o adicionen. ARTÍCULO 18.- DE LOS MEDIOS TÉCNICOS DE REGISTRO Y CONSERVACIÓN DE LA HISTORIA CLÍNICA. Los Prestadores de Servicios de Salud pueden utilizar medios físicos o técnicos como computadoras y medios magneto-ópticos, cuando así lo consideren conveniente, atendiendo lo establecido en la circular 2 de 1997 expedida por el Archivo General de la Nación, o las normas que la modifiquen o adicionen. Los programas automatizados que se diseñen y utilicen para el manejo de las Historias Clínicas, así como sus equipos y soportes documentales, deben estar provistos de mecanismos de seguridad, que imposibiliten la incorporación de modificaciones a la Historia Clínica una vez se registren y guarden los datos. En todo caso debe protegerse la reserva de la historia clínica mediante mecanismos que impidan el acceso de personal no autorizado para conocerla y adoptar las medidas tendientes a evitar la destrucción de los registros en forma accidental o provocada. 136

138 Los prestadores de servicios de salud deben permitir la identificación del personal responsable de los datos consignados, mediante códigos, indicadores u otros medios que reemplacen la firma y sello de las historias en medios físicos, de forma que se establezca con exactitud quien realizó los registros, la hora y fecha del registro. CAPÍTULO IV COMITÉ DE HISTORIAS CLÍNICAS ARTÍCULO 19.- DEFINICIÓN. Defínase el comité de historias clínicas como el conjunto de personas que al interior de una Institución Prestadora de Servicios de Salud, se encarga de velar por el cumplimiento de las normas establecidas para el correcto diligenciamiento y adecuado manejo de la historia clínica. Dicho comité debe establecerse formalmente como cuerpo colegiado o mediante asignación de funciones a uno de los comités existentes en la Institución. PARÁGRAFO. El comité debe estar integrado por personal del equipo de salud. De las reuniones, se levantarán actas con copia a la dirección de la Institución. ARTÍCULO 20.- FUNCIONES DEL COMITÉ DE HISTORIAS CLÍNICAS. a) Promover en la Institución la adopción de las normas nacionales sobre historia clínica y velar porque estas se cumplan. b) Elaborar, sugerir y vigilar el cumplimiento del manual de normas y procedimientos de los registros clínicos del Prestador, incluida la historia clínica. c) Elevar a la Dirección y al Comité Técnico-Científico, recomendaciones sobre los formatos de los registros específicos y anexos que debe contener la historia clínica, así como los mecanismos para mejorar los registros en ella consignados. d) Vigilar que se provean los recursos necesarios para la administración y funcionamiento del archivo de Historias Clínicas. 137

139 ARTICULO SANCIONES. Los Prestadores de Servicios de Salud que incumplan lo establecido en la presente resolución, incurrirán en las sanciones aplicables de conformidad con las disposiciones legales vigentes. ARTÍCULO 22.- VIGENCIA. La presente Resolución rige a partir de la fecha de su publicación y deroga las disposiciones que le sean contrarias. VIRGILIO GALVIS RAMÍREZ Ministro de Salud 138

140 ANEO D. Encuesta pacientes 1. Desde hace cuánto tiempo acude al consultorio odontológico? 2. Qué tipo de tratamiento le realizan? 3. Cada vez que pide una cita en qué forma lo hace? 4. Hay alguna manera en que le recuerden la fecha y hora de su próxima cita? 5. Le parece adecuado el tiempo que dura su consulta? 6. Cada cuánto debe asistir al consultorio? 7. Alguna vez ha solicitado su historia clínica? esta información es entregada a tiempo o que problema ha tenido para obtenerla? 139

141 8. Está conforme con el proceso que se lleva actualmente en el consultorio odontológico para pedir su próxima cita? 9. Cree que si pudiera agendar su próxima cita odontológica por medio de una página en internet sería más como y rápido? Por qué? 10. Para el proceso de registrarse como paciente nuevo cree que es necesario una foto para almacenar en su registro? 11. Los horarios y los días de atención que maneja el consultorio son adecuados para usted como paciente? 12. Le gustaría que le recordaran con un mensaje de texto a su celular la fecha y hora de su próxima cita? 13. Le gustaría que al usar la página web del consultorio pueda consultar los horarios, fechas y odontólogos disponibles a los cuales usted desee acudir? 140

142 14. Cuándo no puede acudir a una cita en que forma la cancela? 15. Para su comodidad desearía que se puedan cancelar citas por medio de la página web del consultorio? 16. Si necesitan actualizar sus datos tiene que acudir al consultorio? De qué otra forma lo hace? 17. Le parecería buena la opción de actualizar sus datos por medio de la página web del consultorio en vez de usar los métodos que anteriormente menciono? 18. Qué información de los odontólogos y del consultorio le gustaría encontrar en la página web? 141

143 ANEO 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 Levantamiento de Información. La gráfica 1 muestra que la mayoría de los encuestados acuden al consultorio odontológico aproximadamente entre 1 y 5 años, las demás personas acuden entre 6 y 15 años. En la pregunta 14 el 50% de los encuestados cuando no pueden asistir a una cita la cancelan en telefónicamente o en el consultorio. 142

144 3. Cada vez que pide una cita lo hace telefónicamente? 4. Hay alguna manera en que le recuerden la fecha y hora de su próxima cita? 5. Le parece adecuado el tiempo que dura su consulta? 7. Alguna vez ha solicitado su historia clínica? esta información es entregada a tiempo o que problema ha tenido para obtenerla? Gráfica 2. Resultados Encuesta Preguntas 3, 4, 5 y 7. Ver punto Levantamiento de Información. En la gráfica 2 se muestra que para la pregunta 3 todos los pacientes encuestados cada vez que piden una cita lo hacen de manera telefónica. En la pregunta 4 casi siempre hay alguna manera que a los pacientes se les recuerda su próxima cita. 8. Está conforme con el proceso que se lleva actualmente en el consultorio odontológico para pedir su próxima cita? 9. Cree que si pudiera agendar su próxima cita odontológica por medio de una página en internet sería más como y rápido? Por qué? 10. Para el proceso de registrarse como paciente nuevo cree que es necesario una foto para almacenar en su registro? 11. Los horarios y los días de atención que maneja el consultorio son adecuados para usted como paciente? 143

145 Gráfica 3. Resultados Encuesta Preguntas 8, 9, 10 y 11. Ver punto Levantamiento de Información. En la gráfica 3 se muestra que para la pregunta 8 el 50 % de los pacientes encuestados están conformes con el proceso que se lleva para pedir su próxima cita. En la pregunta 9 el 90% de los encuestados piensan que es más rápido y cómodo agendar su próxima cita por medio de una página de internet. Para las preguntas 10 y 11 el 50% de los encuestados creen que no es necesario almacenar una fotografía en su registro y que los horarios y días que maneja el consultorio son adecuados. 12. Le gustaría que le recordaran con un mensaje de texto a su celular la fecha y hora de su próxima cita? 13. Le gustaría que al usar la página web del consultorio pueda consultar los horarios, fechas y odontólogos disponibles a los cuales usted desee acudir? 15. Para su comodidad desearía que se puedan cancelar citas por medio de la página web del consultorio? 16. Si necesitan actualizar sus datos tiene que acudir al consultorio? De qué otra forma lo hace? 17. Le parecería buena la opción de actualizar sus datos por medio de la página web del consultorio en vez de usar los métodos que anteriormente mencionó? 144

146 Gráfica 4. Resultados Encuesta Preguntas 12, 13, 15, 16 y 17. Ver punto Levantamiento de Información. En la gráfica 4 se muestra que para las preguntas 12 y 13 el 100 % de los pacientes encuestados les gustaría que les recordaran su próxima cita con un mensaje de texto a su celular y además poder consultar en la página web los horarios, fechas y odontólogos disponibles. Igualmente la totalidad de los encuestados respondieron que para su comodidad desearían cancelar una cita por medio de la página web y que para actualizar sus datos tienen que asistir al consultorio. El formato de la encuesta realizada a los pacientes se encuentra en el anexo D. La ficha técnica y resultados de las encuestas se pueden ver en el anexo F. 145