Sistema Generador de Solicitudes

Dise no e Implementaci on del Sistema Generador de Solicitudes de Auxiliares de Diagn ostico de la Consulta Externa del HRAE Ciudad Salud
Residentes: Acosta D az Jarumy Jacquelin Rodr guez S anchez Jos e Alberto
Asesor Externo: M.C.C. Jehiely Belem Hern andez Castillo Asesor Interno: Ing. Sergio Esteban Carrillo P erez Del 20 de Agosto al 7 de Diciembre; 2012
Indice general
1. PLANTEAMIENTO DEL PROYECTO 1.1. Problemas a resolver . . . . . . . . . . . 1.2. Justicaci on . . . . . . . . . . . . . . . . 1.3. Objetivos . . . . . . . . . . . . . . . . . 1.3.1. Objetivo general . . . . . . . . . 1.3.2. Objetivos espec cos . . . . . . . 1.4. Alcances y Limitaciones . . . . . . . . . 1.4.1. Alcances . . . . . . . . . . . . . . 1.4.2. Limitaciones . . . . . . . . . . . . 1 1 2 2 2 3 4 4 4 5 5 6 6 6 6 7 8 9 11 11 12 12 12 13 14 16 16 17 17 17 17 18 18 19 19 19
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
2. DATOS DE LA EMPRESA 2.1. Antecedentes del Hospital Regional de alta Especialidad Ciudad Salud 2.2. Misi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Visi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Organigramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1. Organigrama General del HRAE . . . . . . . . . . . . . . . . . 2.4.2. Organigrama del Depto. de Tecnolog as . . . . . . . . . . . . . . 2.5. Macrolocalizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6. Microlocalizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. FUNDAMENTO TEORICO 3.1. Concepto de sistema . . . . . . . . 3.2. Sistemas de Informaci on . . . . . . 3.3. Lenguaje de Programaci on . . . . . 3.3.1. PHP . . . . . . . . . . . . . 3.4. JavaScript . . . . . . . . . . . . . . 3.5. HTML . . . . . . . . . . . . . . . . 3.6. Base de Datos . . . . . . . . . . . . 3.6.1. Diagrama Entidad-Relaci on 3.6.2. Diagrama Relacional . . . . 3.6.3. Diccionario de Datos . . . . 3.7. Gestor de Base de Datos . . . . . . 3.7.1. MySQL . . . . . . . . . . . 3.8. UML . . . . . . . . . . . . . . . . . 3.8.1. Casos de Uso . . . . . . . . 3.8.2. Diagrama de Clases . . . . . 3.9. RUP . . . . . . . . . . . . . . . . . 3.10. Modelo Constructivo de Costos . . I
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
II
INDICE GENERAL 3.11. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 23 23 23 23 25 26 26 26 27 28 40 41 50 51 52 66 77 78 79 80 81 82 83 84 86 87 87 88 89
4. METODOLOG IA DE DESARROLLO 4.1. Plan de Trabajo . . . . . . . . . . . . . . . . . . 4.2. Determinaci on de los Requerimientos . . . . . . 4.2.1. Requerimientos Funcionales . . . . . . . 4.2.2. Requerimientos No Funcionales . . . . . 4.3. Factibilidades . . . . . . . . . . . . . . . . . . . 4.3.1. Factibilidad T ecnica . . . . . . . . . . . 4.3.2. Factibilidad Econ omica . . . . . . . . . . 4.3.3. Factibilidad Operacional . . . . . . . . . 4.4. Diagrama Entidad Relaci on . . . . . . . . . . . 4.5. Diagrama Relacional . . . . . . . . . . . . . . . 4.6. Diccionario de Datos . . . . . . . . . . . . . . . 4.7. Casos de Uso . . . . . . . . . . . . . . . . . . . 4.7.1. Objetivos del sistema . . . . . . . . . . . 4.7.2. Diagrama de subsistemas y casos de Uso 4.7.3. Especicaci on de los Casos de Uso . . . 4.8. Diagrama de Clases . . . . . . . . . . . . . . . . 4.9. Modelo de Procesos . . . . . . . . . . . . . . . . 4.10. Diagrama de Actividades . . . . . . . . . . . . . 4.11. Diagrama de Estados . . . . . . . . . . . . . . . 4.12. Diagrama de Secuencias . . . . . . . . . . . . . 4.13. Diagrama de Distribuci on . . . . . . . . . . . . 4.14. Diagrama de Colaboraci on . . . . . . . . . . . . 4.15. Modelo Costructivo de Costos COCOMO . . 4.16. Cronograma de Actividades . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
5. RESULTADOS 5.1. Sistema implementado vs Sistema manual . . . . . . . . . . . . . . . . 5.2. Conclusi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Indice de guras
2.1. 2.2. 2.3. 2.4. Organigrama General de HRAE Ciudad Salud . . . . . . . . . . Organigrama del Depto. de Tecnolog as de Informaci on del HRAE Macrolocalizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . Microlocalizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 8 9 28 29 29 29 29 30 30 30 30 31 31 31 31 32 32 32 32 33 33 33 34 34 35 35 35 36 36 36 36 37 37 37 37
4.1. Diagrama Entidad-Relaci on . . . . . . . . . . . . 4.2. Entidad Solicitud de Electrodiagn ostico . . . . . . 4.3. Entidad cama . . . . . . . . . . . . . . . . . . . . 4.4. Entidad seccion . . . . . . . . . . . . . . . . . . . 4.5. Entidad estudios de electrodiagn ostico . . . . . . 4.6. Entidad receta hospitalaria . . . . . . . . . . . . . 4.7. Entidad receta externa . . . . . . . . . . . . . . . 4.8. Entidad Ex amenes de Laboratorio . . . . . . . . . 4.9. Entidad Detalle de Ex amenes de laboratorio . . . 4.10. Entidad cat alogo ex amenes de laboratorio . . . . 4.11. Entidad de Anatom a Patolog a . . . . . . . . . . 4.12. Entidad Estudio Anatom a Patolog a . . . . . . . 4.13. Entidad Interconsulta . . . . . . . . . . . . . . . . 4.14. Entidad Imagenolog a . . . . . . . . . . . . . . . . 4.15. Entidad detalle de estudios Imagenolog a . . . . . 4.16. Entidad Curaciones . . . . . . . . . . . . . . . . . 4.17. Entidad paquete Curaciones . . . . . . . . . . . . 4.18. Entidad Cat alogo de curaciones . . . . . . . . . . 4.19. Entidad Componentes Sangu neos . . . . . . . . . 4.20. Entidad Detalle de Componentes Sangu neos . . . 4.21. Entidad Banco de sangre Componente Sangu neo 4.22. Entidad Pruebas Cruzadas . . . . . . . . . . . . . 4.23. Entidad Banco de sangre Pruebas Cruzadas . . . 4.24. Entidad Producto Sangu neo . . . . . . . . . . . . 4.25. Entidad descripci on productos sangu neos . . . . 4.26. Entidad Detalle pruebas cruzadas . . . . . . . . . 4.27. Entidad Pacientes . . . . . . . . . . . . . . . . . . 4.28. Entidad Expedientes . . . . . . . . . . . . . . . . 4.29. Entidad Personal . . . . . . . . . . . . . . . . . . 4.30. Entidad Cat alogo de Especialidades . . . . . . . . 4.31. Entidad Detalle personal especialidad . . . . . . . 4.32. Entidad cat alogo Electrodiagn ostico . . . . . . . . 4.33. Entidad cat alogo componentes sangu neos . . . . III
IV
INDICE DE FIGURAS 4.34. Entidad cat alogo anatom a-patolog a . . . . . . . . . . . . . . 4.35. Entidad cat alogo Imagenolog a . . . . . . . . . . . . . . . . . . 4.36. Entidad cat alogo Ex amenes de Laboratorio . . . . . . . . . . . 4.37. Entidad cat alogo Productos sangu neos . . . . . . . . . . . . . 4.38. Entidad cat alogo Productos banco . . . . . . . . . . . . . . . . 4.39. Entidad banco Productos sangu neos . . . . . . . . . . . . . . 4.40. Entidad cat alogo pruebas cruzadas . . . . . . . . . . . . . . . 4.41. Diagrama Relacional . . . . . . . . . . . . . . . . . . . . . . . 4.42. Diccionario de Datos . . . . . . . . . . . . . . . . . . . . . . . 4.43. Sistema Generador de Solicitudes de Auxiliares de Diagn ostico 4.44. Descripci on del subsistema Gesti on de Solicitudes y Formatos 4.45. Descripci on del subsistema Gesti on de consultas . . . . . . . . 4.46. Descripci on del subsistema Gesti on de usuarios . . . . . . . . 4.47. Diagrama de subsistemas y casos de uso . . . . . . . . . . . . 4.48. Caso de uso del subsistema Gesti on de Solicitudes y Formatos 4.49. Caso de uso del subsistema Gesti on de Consultas . . . . . . . 4.50. Caso de uso del subsistema Gesti on de Usuarios . . . . . . . . 4.51. Receta Hospitalaria Interna . . . . . . . . . . . . . . . . . . . 4.52. Receta Hospitalaria Externa . . . . . . . . . . . . . . . . . . . 4.53. Solicitud de Imagenolog a . . . . . . . . . . . . . . . . . . . . 4.54. Solicitud de Interconsulta . . . . . . . . . . . . . . . . . . . . 4.55. Solicitud de Ex amenes de Laboratorio . . . . . . . . . . . . . 4.56. Solicitud de Electrodiagn ostico . . . . . . . . . . . . . . . . . 4.57. Formato de Cobro por Curaciones . . . . . . . . . . . . . . . . 4.58. Solicitud de Anatom a-Patolog a . . . . . . . . . . . . . . . . . 4.59. Descripci on del caso de uso Solicitud de Productos sangu neos 4.60. Descripci on del caso de uso Componentes sangu neos . . . . . 4.61. Descripci on del caso de uso Pruebas Cruzadas . . . . . . . . . 4.62. Descripci on del caso de uso Receta Hospitalaria . . . . . . . . 4.63. Descripci on del caso de uso Receta Externa . . . . . . . . . . 4.64. Descripci on del caso de uso Solicitud de Imagenolog a . . . . . 4.65. Descripci on del caso de uso Interconsulta . . . . . . . . . . . . 4.66. Descripci on del caso de uso Ex amenes de Laboratorio . . . . . 4.67. Descripci on del caso de uso Electrodiagn ostico . . . . . . . . . 4.68. Descripci on del caso de uso Formato de cobro por curaciones . 4.69. Descripci on del caso de uso Anatom a-Patolog a . . . . . . . . 4.70. Descripci on del caso de uso Componentes Sangu neos . . . . . 4.71. Descripci on del caso de uso Productos Sangu neos . . . . . . . 4.72. Descripci on del caso de uso Pruebas Cruzadas . . . . . . . . . 4.73. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . 4.74. Modelo de Procesos del Sistema . . . . . . . . . . . . . . . . . 4.75. Diagrama de actividades . . . . . . . . . . . . . . . . . . . . . 4.76. Diagrama de Estados . . . . . . . . . . . . . . . . . . . . . . . 4.77. Diagrama de secuencias . . . . . . . . . . . . . . . . . . . . . . 4.78. Diagrama de Distribuci on . . . . . . . . . . . . . . . . . . . . 4.79. Diagrama de colaboraci on . . . . . . . . . . . . . . . . . . . . 4.80. Tabla de Clasicaci on de Proyectos en el Modelo COCOMO . 4.81. Cronograma de Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 38 38 38 39 39 39 40 49 50 51 51 52 52 53 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 86
INDICE DE FIGURAS 5.1. Gr aca comparaci on de tiempo en minutos de la solicitud entre ambos sistemas . . . . . . . . . . . . . . . . . . . . . 5.2. Pantalla principal del sistema . . . . . . . . . . . . . . . . 5.3. Pantalla de a rea de solicitudes . . . . . . . . . . . . . . . . 5.4. Formulario de Interconsulta . . . . . . . . . . . . . . . . . 5.5. Formulario de receta m edica hospitalaria . . . . . . . . . . 5.6. Formulario de receta m edica hospitalaria externa . . . . . 5.7. Formulario de solicitud de componentes sangu neos . . . . 5.8. Formulario de solicitud de Anatom a Patolog a . . . . . . 5.9. Formulario solicitud de estudios de Imagenolog a . . . . . 5.10. Formulario solicitud de estudios Electrodiagn ostico . . . . 5.11. Formulario solicitud de Ex amenes de Laboratorio . . . . . 5.12. Formulario solicitud de Productos Sangu neos . . . . . . . 5.13. Formato de cobro por curaciones . . . . . . . . . . . . . . 5.14. Formato de consulta de registros . . . . . . . . . . . . . . . de estudios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87 89 89 90 90 91 91 92 92 93 94 94 95 96
VI
INDICE DE FIGURAS
Introducci on
En este cap tulo se plantear a la problem atica que actualmente existe y la cual se quiere resolver, as mismo, dentro de este apartado se incluir an todos los detalles y requerimientos que se necesitan para el desarrollo del software el cual se identica con el nombre Sistema de control de consulta externa del Hospital Regional de Alta Especialidad (HRAE) Ciudad Salud. Se denir a informaci on base de total importancia para el desarrollo del proyecto, entre estas podemos mencionar: las capacidades del software, sus l mites, caracter sticas, en resumen; lo que el software ser a capaz de realizar. La problem atica mencionada anteriormente llev o a realizar una serie de estudios, investigaciones y an alisis que permitieran establecer propuestas y, as mismo, poder establecer un modelo que cubriera las necesidades de la organizaci on, cubriendo gran parte de sus movimientos y eliminando p erdidas de tiempo, p erdidas monetarias, y como mayor benecio el poder agilizar los procesos utilizando para ello las Tecnolog as de Informaci on TICs y la Programaci on, destacando lo u ltimo como punto fundamental, conociendo de antemano que esta herramienta est a implementada en la mayor a de las empresas y organizaciones para poder alcanzar un mayor grado de competitividad y desempe no.
Cap tulo 1 PLANTEAMIENTO DEL PROYECTO

1.1. Problemas a resolver
Dentro del Hospital Regional de Alta Especialidad (HRAE) Ciudad Salud se necesita solucionar el problema asociado con la generaci on de notas, recetas m edicas al paciente o solicitudes, as como tambi en las solicitudes a las distintas areas del mismo Hospital, a continuaci on se denen los diversos tipos de solicitudes a las areas mencionadas anteriormente: Solicitud de Electrodiagn ostico Solicitud de Estudio de Anatom a Patolog a Solicitud al Departamento de Imagenolog a Solicitud de Ex amenes de Laboratorio Solicitud de Interconsulta Receta m edica Hospitalaria Receta m edica Hospitalaria Interna Formato de Curaciones Solicitud de Pruebas Cruzadas Solicitud de Productos Sangu neos Solicitud de Componentes Sangu neos El origen del problema mencionado consiste en que dicho hospital no cuenta con un sistema que le permita automatizar notas, solicitudes y recetas m edicas al paciente, actualmente cada m edico tiene que llenar la receta del paciente de forma manual sin utilizar un medio tecnol ogico o sistema inform atico que le facilite y agilice el trabajo.
CAP ITULO 1. PLANTEAMIENTO DEL PROYECTO
Las consecuencias de este asunto consisten en: la p erdida de tiempo que le genera a cada doctor de la instituci on elaborar sus solicitudes y recetas, el no tener un respaldo exacto y ecaz de cada nota y/o solicitud expedida a cada paciente, y adem as, el no contar con los datos correctos y necesarios en cada formato, lo cual provoca la inexacta valoraci on del paciente y aumenta en grandes cantidades los riesgos de equivocaci on al momento de ordenar alg un tipo de estudios o la tergiversaci on de informaci on que pudiese estar mal escrita.
1.2.
Justicaci on
Cada consultorio dentro del HRAE Ciudad Salud tiene la tarea d a con d a de atender a gran cantidad de pacientes, lo cual genera el trabajo de extender diversas recetas m edicas, notas del estado de pacientes que ya son atendidos y que tienen en observaci on; y solicitudes a diferentes areas del mismo hospital para la realizaci on de distintos tipos de an alisis y pruebas m edicas, todos estos formatos son llenados a mano directamente por el m edico. Es por lo anterior y por muchas otras necesidades que se necesita la ayuda de un software (programa inform atico) que permita controlar y ordenar la informaci on que se expide en cada formato, permitiendo una mayor organizaci on en los datos obtenidos y necesarios del paciente, un ahorro de tiempo, efectividad en los datos manejados, el desuso de formatos en papel entre areas y/o departamentos del Hospital para enviar informaci on o datos relacionados entre ellas mismas, y sobre todo, la facilidad y la comodidad para el personal m edico dentro del hospital. El sistema planteado tendr a un gran benecio tanto para el personal que labora dentro de la organizaci on y as mismo, para los pacientes que son atendidos dentro del hospital, ayudar a a resolver problemas pr acticos en su mayor totalidad no descartado los benecios que traer a en otros ambitos de la informaci on, por lo cual dar a un gran aporte a nivel tecnol ogico y social.
1.3.
1.3.1.
Objetivos
Objetivo general
Dise nar e implementar un Sistema Generador de Solicitudes de Auxiliares de Diagn ostico de la Consulta Externa del Hospital Regional de Alta Especialidad Ciudad Salud que automatice y permita al m edico de cada consultorio realizar de forma eciente la elaboraci on de notas, diagn osticos, recetas m edicas y solicitudes de estudios referentes a la consulta del paciente del HRAE, para ello se utilizar an herramientas de programaci on que permitan el dise no y creaci on de este software las cuales se denen a detalle m as adelante.
1.3. OBJETIVOS
1.3.2.
Objetivos espec cos
1. Dise nar e implementar un sistema inform atico con las herramientas de programaci on necesarias para ello, el cual otorgue los distintos tipos de solicitudes, recetas m edicas y notas utilizadas dentro del HRAE las cuales contendr an los datos necesarios y aprobados por la instituci on para su debido uso, los m odulos que estar an contemplados ser an los mencionados a continuaci on: Dise nar un m odulo de nombre Receta Hospitalaria Externa que permita registrar y almacenar los datos del paciente, su diagn ostico y la dosis establecida de medicamentos expedidos por el m edico. Dise nar un m odulo que lleve por nombre Receta Hospitalaria la cual contendr a datos del paciente y su diagn ostico, pero a diferencia de la Receta Hospitalaria Externa solo permitir a asignar un solo medicamento con su dosis, de manera que si se requiere administrar m as de un medicamento al paciente se tendr a que llenar otra solicitud, en espec co ser a una solicitud por cada medicamento. Dise nar un m odulo de Solicitud de Interconsulta que permita registrar y almacenar los datos del paciente que se encuentra internado as como la valoraci on de su estado de salud y su resumen cl nico. Dise nar un m odulo de nombre Solicitud de Electrodiagn ostico que permita registrar y almacenar los datos necesarios del paciente, su diagn ostico y los estudios que son solicitados por el m edico que lo atiende. Dise nar un m odulo de Solicitud de Estudio de Anatom a Patolog a que permita registrar y almacenar datos del paciente, su diagn ostico y los tipos de estudio a realizar. Dise nar un m odulo de nombre Solicitud de Imagenolog a que permita registrar y almacenar los tipos de pruebas a realizar, datos del paciente e informaci on necesaria para determinar los estudios solicitados por el m edico. Dise nar un m odulo de Solicitud de Ex amenes de Laboratorio que permita el registro y el almac en de datos del paciente y los tipos de pruebas de laboratorios que se realizar an. Dise nar un m odulo de Formato de Curaciones en el cual se especican los paquetes de curaciones que han sido utilizados por los m edicos durante las curaciones, este m odulo a su vez estar a enlazado con el sistema de cobro para poder realizar el cobro debido de dichos paquetes. Dise nar un m odulo de Solicitud de Pruebas Cruzadas el cual se encargar a de solicitar estudios de acuerdo al diagn ostico del paciente. Dise nar un m odulo de nombre Solicitud de Productos Sangu neos el cual se encargar a de llevar el control de las solicitudes de productos sangu neos de un paciente. Dise nar un m odulo de Componentes Sangu neos, su funci on ser a la de solicitar componentes sangu neos que ser an requeridos para la atenci on de un paciente. 2. Dise nar y realizar un cat alogo de m edicos, el cual contendr a informaci on espec ca o datos que pertenecen a cada uno de ellos seg un el consultorio que atiendan y el
CAP ITULO 1. PLANTEAMIENTO DEL PROYECTO area, de esta manera cada receta, solicitud o nota se adecuar a con la informaci on del m edico que expida las anteriores. 3. Denir los datos de los pacientes que se necesiten para el llenado de las solicitudes, notas o recetas m edicas expedidas por el HRAE, estos datos se extraer an del sistema que utiliza el departamento de cobro, quien a su vez utiliza datos del area de trabajo social el cual se encarga de dar de alta al paciente. 4. Desarrollar una area de consultas dentro del sistema el cual permita lo siguiente: si un m edico otorga una orden de estudios a un paciente para alg un area del HRAE seg un el tipo de an alisis que se le solicite, el area o departamento al cual se dirige la solicitud ser a capaz de consultar en el sistema los datos de esta solicitud, mostrando en pantalla la orden expedida por dicho m edico y los detalles de la misma. 5. El sistema ser a capaz de ingresar nuevos pacientes al sistema desde la cuenta Administrador la cual contendr a un password denido; desde esta cuenta se podr a agregar, modicar o eliminar datos o contenidos.
1.4.
1.4.1.
Alcances y Limitaciones
Alcances
1. El sistema (software) se encontrar a dentro de una red Intranet. 2. Las solicitudes y recetas generadas por el Sistema podr an ser impresas en formato electr onico PDF y de esta misma manera estar an disponibles para ser impresas en papel. 3. El sistema permitir a agilizar el proceso de llenado o generaci on de las solicitudes debido a que algunos datos ya se encontrar an almacenados en dicho sistema.
1.4.2.
Limitaciones
1. El sistema dise nado no ser a capaz de actualizar la base de datos si nuevos pacientes han sido agregados al sistema, esta actualizaci on no se realizar a de forma autom atica, es decir, el administrador tendr a que agregar peri odicamente los nuevos pacientes y/o personal. 2. No ser a posible acceder al sistema a trav es de Internet 3. Datos incompletos del personal m edico o de los pacientes registrados dentro del sistema. 4. Falta de capacitaci on en general sobre el manejo de sistemas de informaci on por parte del personal m edico.
Cap tulo 2 DATOS DE LA EMPRESA

2.1. Antecedentes del Hospital Regional de alta Especialidad Ciudad Salud
Con el n de racionalizar y priorizar los recursos para la inversi on y la operaci on sustentable en materia de salud, en el Plan federal maestro de infraestructura f sicase identicaron 18 redes de atenci on con posibilidades de soportar servicios de alta especialidad. Derivado de esto, el Gobierno del estado, siguiendo el esquema de Planeaci on estrat egica, llev o a cabo el estudio Plan estatal maestro de infraestructura para la saluddetermin andose la Red de servicios de atenci on a la salud y con esto la creaci on del Centro regional de alta especialidad, con dos nodos: uno en Tapachula que es el Hospital de Alta Especialidad Ciudad Salud; y el otro en Tuxtla Guti errez, que es el Hospital de Especialidades Pedi atricas. De esta manera surgen los Hospitales de alta especialidad: El Hospital de Especialidades Pedi atricas de Tuxtla Guti errez y El Hospital de Alta Especialidad Ciudad Salud en Tapachula, Chiapas, como establecimientos p ublicos del sistema nacional de salud, integrantes de la red de servicios de alta especialidad que prestar an servicios de atenci on m edica enmarcados en la denici on de alta especialidad, mediante una organizaci on social productiva, de extrema complejidad y con un esquema conceptual y propuesta funcional operativa que representa la articulaci on de todos los procesos que conducen al logro de la misi on y objetivos del establecimiento de atenci on a la salud. Los hospitales se crean considerando los tremendos cambios que le esperan a la salud en las pr oximas d ecadas, fundamentados en la explosi on tecnol ogica, los cambios demogr acos y las nuevas f ormulas de gesti on cl nica. Obligados a adaptarse a estos cambios introduciendo nuevos m etodos de gesti on y nuevas estructuras que les permitan transitar de una unidad protot pica centrada en las necesidades del paciente a una organizaci on exible, abierta, profesional, centrada en el cliente, interconectada, de geometr a variable, orientada a procesos, con infraestructura y tecnolog a apropiadas, que le permita: Garantizar la atenci on m edica de los pr oximos 20 a nos y Adquirir una rector a normativa.
CAP ITULO 2. DATOS DE LA EMPRESA
2.2.
Misi on
Otorgar servicios de alta especialidad a la poblaci on del estado de Chiapas, con oportunidad y alto sentido humano, en un ambiente de calidad, con personal altamente capacitado, con procesos y t ecnicas de vanguardia y con autonom a de gesti on; para resolver sus problemas de salud. Obtener el reconocimiento de los hospitales como centro de alto nivel para referencia, formaci on de recursos humanos e investigaci on; integrados al funcionamiento y consolidaci on del Sistema Nacional de Salud, particularmente a las redes de servicio en el estado.
2.3.
Visi on
Lograr ser l deres en la atenci on m edica de mayor resoluci on, autosustentables por servicios, de vanguardia en la medicina y de referencia por su calidad y eciencia, para la atenci on de padecimientos considerados de alta especialidad, para toda la poblaci on del estado de chiapas; as como constituirse en centro de investigaci on y docencia en la salud, con plena satisfacci on del usuario y del prestador de servicios.
2.4.
2.4.1.
Organigramas
Organigrama General del HRAE
Figura 2.1: Organigrama General de HRAE Ciudad Salud
2.4. ORGANIGRAMAS
2.4.2.
Organigrama del Depto. de Tecnolog as
Figura 2.2: Organigrama del Depto. de Tecnolog as de Informaci on del HRAE
2.5.
Macrolocalizaci on
El Hospital Regional de Alta Especialidad Ciudad Salud se encuentra ubicado en carretera Tapachula-Puerto madero. km 15+200, colonia Los Toros, municipio de Tapachula, Chiapas.
Figura 2.3: Macrolocalizaci on
2.6. MICROLOCALIZACION
2.6.
Microlocalizaci on
En la siguiente imagen se muestra el croquis del Hospital Regional de Alta Especialidad Ciudad Salud. Con el n de ser breves, solamente se muestra la planta alta del mismo, donde se encuentra el area de consultor a externa.
Figura 2.4: Microlocalizaci on
10
Cap tulo 3 FUNDAMENTO TEORICO

3.1. Concepto de sistema
En el sentido m as amplio, un sistema es un conjunto de componentes que interaccionan entre s para lograr un objetivo com un.1 Una organizaci on es un ejemplo cl asico de un sistema, siendo algunos de sus componentes los siguientes: mercadotecnia, manufactura, ventas, investigaci on, contabilidad y personal, los cuales trabajan en conjunto para crear utilidades que benecien tanto a los empleados como los miembros de la compa n a. Cada uno de estos componentes es a su vez, un sistema. Para alcanzar sus objetivos, el cual est a formado por todos los objetos que se encuentran fuera de las fronteras de los sistemas. Los sistemas que interact uan con su medio ambiente (reciben entradas y producen salidas) se denominan Sistemas Abiertos a diferencia de aquellos que no interact uan con su medio ambiente se conocen como Sistemas Cerrados existen solo como un concepto. El elemento de control est a relacionado con la naturaleza de los sistemas sean cerrados o abiertos. Para resumir. Los sistemas emplean un modelo de control b asico consistente en: 1. Un est andar para lograr su desempe no aceptable. 2. Un m etodo para medir el desempe no actual. 3. Un medio para comparar el desempe no actual contra el est andar. 4. Un m etodo de retroalimentaci on. Los sistemas que pueden ajustar sus actividades para mantener sistemas aceptables, contin uan funcionando; aquellos que no lo hacen tienden a desaparecer. El concepto de interacci on con el medio ambiente que es lo que caracteriza a los sistemas abiertos, es esencial para el control. Recibir y evaluar la retroalimentaci on permite al sistema determinar que tan bien est a operando.
www.geocities.com/Silicon Valley/Pires/7894/Introducci on al desarrollo de los sistemas de informaci on.
1
11
12
CAP ITULO 3. FUNDAMENTO TEORICO
3.2.
Sistemas de Informaci on
Este sistema es el medio por el cual los datos de una persona o departamento uyen hacia otros y pueden ser cualquier cosa, desde la comunicaci on interna entre los diferentes componentes de la organizaci on y l neas telef onicas, hasta sistemas de c omputos que generan reportes peri odicos por varios usuarios. Los sistemas de informaci on est an formados por subsistemas que incluyen hardware, software y medios de almacenamiento de datos para archivos y bases de datos. El conjunto particular de subsistemas utilizados, equipo espec co, programas, archivos y procedimientos son los que se denominan una aplicaci on de sistemas de informaci on. De esta forma los sistemas de informaci on pueden tener aplicaciones en los diversos campos en que se requiera su utilizaci on. En sentido general, un sistema es un objeto complejo cuyas partes o componentes se relacionan con al menos alg un otro componente. Tomando esta denici on como base, se puede se nalar que un sistema de informaci on es un conjunto de elementos que interact uan entre s para procesar informaci on y distribuirla de manera adecuada en funci on de los objetivos de una organizaci on. Estos elementos pueden ser personas, datos, actividades o recursos materiales en general.
3.3.
Lenguaje de Programaci on
Un lenguaje es un m etodo conveniente y sencillo de describir las estructuras de informaci on y las secuencias de acciones necesarias para ejecutar una tarea concreta. Los lenguajes de programaci on utilizan juegos de caracteres llamado tambi en alfabeto para comunicarse con las computadoras. De este modo una computadora a trav es de los diferentes lenguajes de programaci on utilizan un juego o c odigo de caracteres que ser an f acilmente interpretados por la computadora y que pueden ser programados por el usuario. Cada lenguaje tiene sus instrucciones y enunciados verbales propios que se combinan para formar los programas de c omputo. Finalmente, los lenguajes de programaci on no son aplicaciones, sino herrameintas que permiten construir y adecuar aplicaciones, se denir a generalmente como un conjunto de reglas, s mbolos y palabras especiales que permiten construir un programa.
3.3.1.
PHP
PHP (acr onimo de PHP: HyperText Preprocessor) es un lenguaje interpretado de alto nivel embebido en p aginas HTML y ejecutado en el servidor. Es un lenguaje interpretado del lado del servidor que surge dentro de la corriente denominada c odigo abierto (open source). Se caracteriza por su potencia, versatilidad, robustez y modularidad. Al igual que ocurre con tecnolog as similares, los programas son integrados directamente dentro del c odigo HTML.2
A. Cobo, P. G omez y R. Rocha, PHP y MySQL Tecnolog as para el desarrollo de aplicaciones web,2005,pag. 99.
2
3.4. JAVASCRIPT
13
Comparado con ASP, la principal ventaja de PHP es su car acter multiplataforma. Por otro lado, los programas en ASP resultan m as lentos y pesados, y tambi en menos estables. En los entornos Microsoft soportan directamente ASP sin necesidad de ninguna instalaci on adicional. Comparando el lenguaje PHP con el lenguaje Perl, utilizado habitualmente en la programaci on CGI, puede decirse que PHP fue dise nado para desarrollo de scripts orientados a web, mientras que Perl fue dise nado para hacer muchas m as cosas y debido a esto, se hace muy complicado. La sintaxis de PHP es menos confusa y m as estricta, pero sin perder la exibilidad. En denitiva, PHP es uno de los lenguajes m as utilizados actualmente en el desarrollo de aplicaciones web y viene experimentando un constante crecimiento en su nivel de utilizaci on en Internet. Lo que distingue a PHP de la tecnolog a JavaScript, la cual se ejecuta en la m aquina cliente es que el c odigo PHP es ejecutado en el servidor. Lo mejor de usar PHP es que es extremadamente simple para el principiante, pero a su vez, ofrece muchas caracter sticas avanzadas para los programadores profesionales. Aunque el desarrollo de PHP est a concentrado en la programaci on de scripts en la parte del servidor, se puede utilizar para muchas otras cosas. PHP puede ser utilizado en cualquiera de los principales sistemas operativos del mundo, incluyendo Linux, muchas variantes Unix (incluido HP-UX, Solaris y OpenBSD), Microsoft Windows, Mac OS X, RISC OS y probablemente alguno m as. PHP soporta la mayor a de servidores web de hoy en d a, incluyendo Apache, Microsoft Internet Information Server, Personal Web Server, Netscape y iPlanet, Oreilly Website Pro server, Caudium, Xitami, de los OmniHTTPd y muchos otros. PHP tiene m odulos disponibles para la mayorAa servidores, para aquellos otros que soporten el est andar CGI, PHP puede usarse como procesador CGI. Quiz as la caracter stica m as potente y destacable de PHP es su soporte para una gran cantidad de bases de datos.
3.4.
JavaScript
Es un lenguaje interpretado basado en guiones que son integrados directamente en el c odigo HTML. El c odigo es transferido al cliente para que este lo interprete al cargar la p agina. Con JavaScript no pueden crearse programas independientes. La primera versi on de este lenguaje apareci o con el navegador Netscape 2.0 en 1995, con el nombre original de LiveScript y soportando gran cantidad de las instrucciones que tiene en la actualidad. La versi on JavaScript 1.1 se dise no con la llegada de las versiones 3.0 de los navegadores e incorpor o algunas funcionalidades nuevas como el tratamiento din amico de im agenes y la creaci on de arrays. Es esta versi on la primera que se incorpora al explorador de Microsoft. En los navegadores 4.0 de Microsoft y Netscape se incorpor o ya un int erprete para una nueva versi on del lenguaje, el JavaScript 1.2. Con esta versi on se iniciar un proceso de diferenciaci on en algunos aspectos de la implementaci on en los dos
14
navegadores, proceso que culminar a con el nacimiento de JScript, nombre con el que Microsoft denomina a su versi on de JavaScript. En la actualidad Microsoft ha desarrollado su JScript.net. Las principales caracter sticas de este lenguaje son: Es un lenguaje interpretado No necesita compilaci on Multiplataforma Lenguaje de alto nivel Admite programaci on estructurada Basado en objetos Maneja la mayor a de los eventos que se pueden producir sobre la p agina web No se necesita ning un kit o entorno de desarrollo En sentido m as amplio JavaScript es un lenguaje de programaci on que se utiliza principalmente para crear p aginas web din amicas. Una p agina web din amica es aquella que incorpora efectos como texto que aparece y desaparece, animaciones, acciones que se activan al pulsar botones y ventanas con mensajes de aviso al usuario. T ecnicamente, JavaScript es un lenguaje de programaci on interpretado, por lo que no es necesario compilar los programas para ejecutarlos. Entre otras palabras, los programas escritos con JavaScript se pueden probar directamente en cualquier navegador sin necesidad de procesos intermedios. A pesar de su nombre, JavaScript no guarda ninguna relaci on directa con el lenguaje de programaci on Java. Legalmente, JavaScript es una marca registrada de la empresa Sun Microsystems. A diferencia de Java, JavaScript no dispone de elementos para crear interfaces de usuario propias para los programas y tiene que utilizar para ello los formularios de HTML a trav es de los denominados manejadores de eventos.
3.5.
HTML
El lenguaje de marcas de hipertexto, HTML o (HyperText Markup Language) se basa en el metalenguaje SGML (Standard Generalized Markup Language) y es el formato de los documentos de la World Wide Web. El World Wide Web Consortium (W3C) es la organizaci on que desarrolla los est andares para normalizar el desarrollo y la expansi on de la Web y la que publica las especicaciones relativas al lenguaje HTML.
3.5. HTML
15
HTML fue concebido como un lenguaje para el intercambio de documentos cient cos y t ecnicos adaptado para su uso por no especialistas en tratamiento de documentos. HTML resolvi o el problema de la complejidad de SGML sirvi endose de un reducido conjunto de etiquetas estructurales y sem anticas apropiadas para la realizaci on de documentos relativamente simples. Pero, adem as de simplicar la estructura de los documentos, HTML soportaba el hipertexto. En un corto per odo de tiempo, HTML se hizo muy popular y r apidamente super o los prop ositos para los que hab a sido creado. Desde sus albores, ha habido una constante invenci on de nuevos elementos para usarse dentro de HTML como est andar y para adaptar HTML a las nuevas posibilidades de la Web, como la posibilidad de usar elementos multimedia o la utilizaci on de elementos din amicos (animaciones Java, uso de Flash, controles ActiveX, etc. que hacen las p aginas web mucho m as llamativas e interactivas para el usuario. Sin embargo, esta ampliaci on de nuevos elementos tambi en ha tra do problemas de compatibilidad de los documentos entre las distintas plataformas y programas. El lenguaje HTML nace en 1991 de manos de Tim Bernes-Lee del CERN como un sistema hipertexto con el u nico objetivo de servir como medio de transmisi on de informaci on entre los cient cos que se ocupaban de la F sica de alta energ a como parte de la iniciativa World Wide Web. As pues, HTML tuvo lugar a la par que el origen de la Web, ya que se trata del lenguaje que sirve para crear p aginas web. En 1993 Dan Connelly escribe la primera DTD (Document Type Denition) de SGML describiendo el lenguaje y, desde entonces, el lenguaje HTML ha estado sometido a incesantes cambios. Los documentos HTML son archivos de texto plano (tambi en conocidos como ASCII) que pueden ser creados mediante cualquier editor de texto, aunque tambi en existen programas espec cos para editar HTML (los editores m as conocidos son Microsoft FrontPage, Netscape Composer, Macromedia Dreamweaver y Adobe PageMill), concebidos espec camente para editar p aginas web en HTML. HTML no permite denir de forma estricta la apariencia de una p agina, aunque en la pr actica, se utiliza tambi en como un lenguaje de presentaci on. Los archivos de HTML se leen en un navegador web tal como Netscape Navigator, Microsoft Explorer, Mozilla, Chrome, etc. La presentaci on de la p agina es muy dependiente del navegador o browser utilizado ya que el mismo documento no produce el mismo resultado en la pantalla si se visualiza con uno u otro, o sea, HTML se limita a describir la estructura y el contenido de un documento, y no el formato de la p agina y su apariencia. Una de las claves del exito de la World Wide Web, aparte de lo atractivo de su presentaci on es, sin duda, su organizaci on y coherencia. Todos los documentos WWW comparten un mismo aspecto y una u nica interfaz, lo que facilita enormemente su manejo por parte de cualquier persona. Esto es posible porque el lenguaje HTML no s olo permite establecer enlaces entre diferentes documentos, sino que es un lenguaje de descripci on de p agina independiente de la plataforma en que se utilice. Es decir un documento HTML contiene toda la informaci on necesaria sobre su aspecto y su interacci on con el usuario, y es luego el navegador que utilicemos el responsable de asegurar que el documento tenga un aspecto coherente, independientemente del tipo de ordenador o de estaci on de trabajo desde donde estemos efectuando la consulta.
16
Los archivos HTML tienen la extensi on .html o htm y para ver la estructura de una p agina web en lenguaje HTML, los navegadores suelen disponer de un men u con la opci on Verdesde la que se puede visualizar el c odigo fuente de la p agina HTML. Dicho c odigo fuente nos dar a una idea clara de en qu e consiste este lenguaje que, como hemos dicho anteriormente, es un simple lenguaje de marcas entre cuyas funciones destaca la posibilidad de enlazar documentos y partes de documentos, esto es, la hipertextualidad. As pues, existen dos herramientas fundamentales e imprescindibles asociadas al lenguaje HTML, por un lado, los editores HTML (para crear documentos HTML) y, por otro, los navegadores (para visualizar dichos documentos). Aunque tambi en existen otras herramientas automatizadas para generar p aginas web, como son los conversores desde otros formatos y otro tipo de herramientas como los revisores y validadores que nos permiten analizar los documentos HTML ya creados para ver si se ajustan a los par ametros de este lenguaje.
3.6.
Base de Datos
Una base de datos es un conjunto de datos organizados de forma estructurada y relacionados entre s , que son almacenados sistem aticamente para su uso posterior. El empleo de bases de datos provee varias ventajas a una organizaci on, entre ellas, ofrece independencia tanto l ogica, como f sica de datos, provocan una redundancia m nima (aunque cabe resaltar que en una base de datos no se puede eliminar la redundancia por completo, ya que en ocasiones es necesaria para modelar las relaciones entre los datos), permiten el acceso concurrente de m ultiples usuarios sin interferir entre ellos, previniendo la p erdida de informaci on o de la integridad, provocan consistencia de datos, debido a que si un dato se almacena una sola vez, cualquier actualizaci on tambi en debe realizarse una sola vez. Una denici on gen erica: conjunto de elementos de software con capacidad para denir,mantener y utilizar una base de datos.
3.6.1.
Diagrama Entidad-Relaci on
El modelo entidad relaci on se caracteriza por emplear s mbolos y reglas para representar los datos y sus relaciones. A trav es de este modelo es posible representar en forma gr aca la estructura de datos en una organizaci on. Los elementos m as importantes del modelo entidad relaci on son: Entidad, relaci on y atributo. El primero se trata de un objeto sobre el cual se recolecta datos que ser an almacenados en la base de datos. La entidad est a representada por un tri angulo. Una relaci on se dene como la asociaci on de una o m as entidades. Las relaciones se representan gr acamente por rombos, dentro de los cuales son colocados sus nombres. El u ltimo elemento, el atributo, es cada una de las propiedades de una entidad o relaci on.
3.7. GESTOR DE BASE DE DATOS
17
3.6.2.
Diagrama Relacional
El modelo relacional es considerado un modelo conceptual, debido a que permite ver en alto nivel y de forma clara, la estructura de datos empleada en una organizaci on. 3 El modelo relacional est a basado en la l ogica de predicados y en la teor a de conjuntos. Hoy en d a, es el modelo m as empleado. El modelo relacional es m as f acil de entender por usuarios con poca experiencia, debido a que es posible almacenar y recuperar los datos a trav es de consultas que son exibles y que ofrecen poder al proceso de administraci on de los datos.
3.6.3.
Diccionario de Datos
Contiene las caracter sticas l ogicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripci on, alias, contenido y organizaci on. Identica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informaci on, se desarrolla durante el an alisis de ujo de datos y auxilia a los analistas que participan en la determinaci on de los requerimientos del sistema, su contenido tambi en se emplea durante el dise no.
3.7.
Gestor de Base de Datos
El SGBD est a constituido por una serie de programas que permiten crear, alterar y eliminar BDs y que proporciona al usuario los mecanismos para dotar a las BDs de contenido y acceder a su informaci on. Adem as dispone de una bater a de utilidades para garantizar la disponibilidad y la seguridad de su contenido.4
3.7.1.
MySQL
MySQL es un sistema de gesti on de bases de datos relacional, licenciado bajo la GPL de la GNU. Su dise no multihilo le permite soportar una gran carga de forma muy eciente. MySQL fue creada por la empresa sueca MySQL AB, que mantiene el copyright del c odigo fuente del servidor SQL, as como tambi en de la marca. Aunque MySQL es software libre, MySQL AB distribuye una versi on comercial de MySQL, que no se diferencia de la versi on libre m as que en el soporte t ecnico que se ofrece, y la posibilidad de integrar este gestor en un software propietario, ya que de no ser as , se vulnerar a la licencia GPL. Este gestor de bases de datos es, probablemente, el gestor m as usado en el mundo del software libre, debido a su gran rapidez y facilidad de uso. Esta gran aceptaci on es debida, en parte, a que existen innidad de librer as y otras herramientas que permiten su uso a trav es de gran cantidad de lenguajes de programaci on, adem as de su f acil instalaci on y conguraci on. Las principales caracter sticas de este gestor de bases de datos son las siguientes:
3 4
Ian Sommerville, Ingenier a del software 7, Edicion Pearson, 2005, pag. 142 Olga Pons, N. Mar n, Introducci on a las bases de datos El modelo relacional,2005,pag.10
18
CAP ITULO 3. FUNDAMENTO TEORICO 1. Aprovecha la potencia de sistemas multiprocesador, gracias a su implementaci on multihilo. 2. Soporta gran cantidad de tipos de datos para las columnas. 3. Dispone de APIs en gran cantidad de lenguajes (C, C++, Java, PHP, etc.) 4. Gran portabilidad entre sistemas. 5. Soporta hasta 32 ndices por tabla. 6. Gesti on de usuarios y passwords, manteniendo un muy buen nivel de seguridad en los datos.
MySQL es la base de datos open source m as popular y, posiblemente, mejor del mundo. Su continuo desarrollo y su creciente popularidad est an haciendo de MySQL un competidor cada vez m as directo de gigantes en la materia de las bases de datos como Oracle. Existen muchos tipos de bases de datos, desde un simple archivo hasta sistemas relacionales orientados a objetos. MySQL como base de datos relacional, utiliza m ultiples tablas para almacenar y organizar la informaci on. Este software fue escrito en C y C++ y destaca por su gran adaptaci on a diferentes entornos de desarrollo, permitiendo su interactuaci on con los lenguajes de programaci on m as utilizados como PHP, Perl y Java y su integraci on en distintos sistemas operativos.
3.8.
UML
UML (Unied Modeling Language)o lenguaje unicado de modelaci on, es un lenguaje gr aco destinado al modelado de sistemas y procesos. Est a basado en la orientaci on a objetos que condujo, en primer lugar, a la creaci on de lenguajes de programaci on como Java, C++ o Smalltalk. UML est a unicado, ya que deriva de varias notaciones precedentes. En la actualidad est a promovido por el OMG. UML es un lenguaje sem antico rico y, por tanto, resulta bastante dif cil retener todos los conceptos en los que se basa.
3.8.1.
Casos de Uso
Un caso de uso es la descripci on de los pasos que deben realizarse para poder llevarse a cabo un proceso. Las entidades que intervienen en los casos de uso se denominan actores. Los actores pueden ser personas u otros sistemas que tienen que ver con el caso de uso a describir. Un diagrama de caso de uso es un auxiliar para denir la comunicaci on y la forma en la que act ua el sistema con los usuarios o con otros sistemas. Los principales elementos de un caso de uso son: Los actores: que representan cualquier entidad externa al sistema y est an representados gr acamente por una gura humana b asica.
3.9. RUP
19
Los casos de uso: que son las tareas que se deben llevar a cabo con ayuda del sistema. Los casos de uso se representan por medio de ovalos. El tercer elemento es la asociaci on: una asociaci on es la relaci on que existe entre un actor y un caso de uso. El u ltimo elemento principal es el escenario, que es la interacci on entre el sistema y los actores, este puede ser descrito mediante una secuencia de mensajes.
3.8.2.
Diagrama de Clases
Los diagramas de clases representan la vista de dise no est atica y de procesos en t erminos 5 de clases, relaciones, interfaces y colaboraciones. Mediante un Diagrama de Clases podemos modelar el esquema de una base de datos. Un diagrama de clases se compone de: clases, interfaces y relaciones; las relaciones pueden ser de dependencia, de asociaci on y de generalizaci on.
3.9.
RUP
El Proceso Unicado de Rational (RUP) es un ejemplo de un modelo de proceso moderno que proviene del trabajo en el UML y el asociado Proceso Unicado de Desarrollo de Software. El RUP reconoce que los modelos de procesos gen ericos presentan un solo enfoque de proceso. En contraste, el RUP se describe normalmente desde tres perspectivas: Una perspectiva din amica que muestra las fases del modelo sobre el tiempo. Una perspectiva est atica que muestra las actividades del proceso que se representan. Una perspectiva pr actica que sugiere buenas pr acticas a utilizar durante el proceso. El RUP no es un proceso apropiado para todos los tipos de desarrollo sino que representa una nueva generaci on de procesos gen ericos.
3.10.
Modelo Constructivo de Costos
El modelo COCOMO es un modelo emp rico que se obtuvo recopilando datos de varios proyectos grandes. Estos datos fueron analizados para descubrir las f ormulas que mejor se ajustaban a las observaciones. Estas f ormulas vinculan el tama no del sistema y del producto, factores del proyecto y del equipo con el esfuerzo necesario para desarrollar el sistema. Los modelos COCOMO son comprensibles, con un gran n umero de par ametros, los cuales pueden tomar un rango de valores. La primera versi on del modelo COCOMO, COCOMO 81, fue un modelo de tres niveles donde estos reejaban el detalle del an alisis de la estimaci on del coste. El primer nivel
5
Esperanza Marcos, B. Vela, Dise no de base de datos Objeto-Relacionales con UML, 2005, pag.5
20
(b asico) provee una estimaci on inicial burda, el segundo nivel la modica utilizando una serie de multiplicadores de proyecto y proceso, y el nivel m as detallado produce estimaciones para las diferentes fases del proyecto. COCOMO 81 supone que el software se desarrolla seg un un proceso en cascada usando lenguajes de programaci on imperativos est andares como C o FORTRAN. Sin embargo, ha habido cambios radicales en el desarrollo del software desde que se propuso esta versi on inicial.
3.10. MODELO CONSTRUCTIVO DE COSTOS
21
El prototipado y el desarrollo incremental son modelos de proceso utilizados com unmente. El software se desarrolla ahora ensamblando componentes reutilizables y vincul andolos mediante un lenguaje de secuencia de comandos (scripts). Teniendo en cuenta estos cambios, el modelo COCOMO II considera diferentes enfoques para el desarrollo de software, como el de la construcci on de prototipos, el desarrollo basado en componentes y el uso de programaci on con bases de datos. COCOMO II soporta el modelo de desarrolla en espiral y engloba varios niveles que producen estimaciones deta lladas de forma incremental. Estos pueden utilizarse en sucesivas iteraciones en el desarrollo en espiral. Los niveles de COCOMO II son los siguientes: 1. Nivel de construcci on de prototipos: Este presume que el sistema es creado mediante componentes reutilizables, scripts y programaci on de base de datos. Fu e dise nado para hacer estimaciones de desarrollo de prototipos. Las estimaciones de tama no del software est an basadas en punto de aplicaci on, y se utiliza una f ormula simple (tama no/productividad) para estimar el esfuerzo requerido. El concepto de puntos de aplicaci on es el mismo que el de puntos objeto, pero el nombre fue cambiado para evitar confusiones con el desarrollo orientado a objetos. 2. Nivel de disen o inicial: Este nivel se utiliza en etapas tempranas del dise no del sistema, despu es de que los requerimientos hayan sido establecidos. Las estimaciones est an basadas en puntos de funci on, los cuales se convierten a n umeros de l neas de c odigo. La f ormula permite seguir el est andar expuesto anteriormente con un conjunto de siete multiplicadores. 3. Nivel de reutilizaci on: Este nivel se utiliza para calcular el esfuerzo requerido para integrar componentes reutilizables y/o el c odigo que es autom aticamente generado por herramientas de dise no o programas de traducci on. Normalmente es utilizado junto con el nivel de post-arquitectura. 4. Nivel de post-arquitectura: Una vez dise nado el sistema, se puede hacer una estimaci on m as precisa del tama no del software. Otra vez se utiliza la f ormula est andar para la estimaci on del coste expuesta anteriormente. Sin embargo, esta incluye un conjunto de 17 multiplicadores que reejan las habilidades del personal y las caracter sticas del producto y del proyecto. Por supuesto, en sistemas grandes, diferentes partes pueden ser desarrolladas utilizando diversas tecnolog as, y puede que no sea preciso estimar todas las partes con el mismo nivel de precisi n. En estos casos se puede utilizar el modelo apropiado para cada parte del sistema y combinar los resultados para crear una estimaci on del sistema completo. As mismo se pueden denir tres tipos de proyectos de software: 1. Modelo Org anico: proyectos de software relativamente pequen os y sencillos en donde trabajan peque nos equipos, con buena experiencia en la aplicaci on. 2. Modelo Semiacoplado: proyectos de software intermedios en los que equipos con variados niveles de experiencia deben satisfacer requerimientos poco o medio r gidos.
22
CAP ITULO 3. FUNDAMENTO TEORICO 3. Modelo a la Medida: proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas.
3.11.
Estado del Arte
Las instituciones de salud generan con sus actividades una enorme cantidad de datos dispersos y muchas veces de mala calidad que generalmente no est an a disposici on o que por lo menos no lo est an oportunamente. Es por lo anterior que el manejo de un sistema inform atico dentro de estas instituciones provee los caminos y las herramientas necesarias para organizar y controlar una gran cantidad de estos datos o informac on. Estos sistemas est an constituidos por un conjunto de personas, datos, formularios, equipamiento, programas de computaci on, procesos y procedimientos que funcionan articuladamente. Con base a lo anterior el Hospital Regional de Alta Especialidad Ciudad Salud ha tenido la necesidad de implementar el sistema inform atico de nombre SIGO el cual lleva el control aparente de todas las areas del hospital, aunque profundizando en caracter sticas y benecios este sistema cuenta con gran parte de funcionalidades que no son aplicables a la administraci on del hospital, por lo que, se podr a concluir que SIGO no es completamente funcional dentro de la instituci on. Partiendo de las necesidades que surgen para llevar un control de solicitudes de estudios del area de consulta m edica dentro del hospital y tratando de cubrir parte de las funciones carecientes del sistema SIGO se desarroll o el Sistema Generador de Solicitudes de Auxiliates de Diagn ostico de la Consulta Externa del Hospital Regional de Alta Especialidad Ciudad Salud de manera que se adaptar a en la mayor cantidad posible a las necesidades de estas areas. Una caracter stica que no se puede omitir en este sistema desarrollado es que permite la modicaci on de gran parte de la informaci on predenida por esta areas (ejemplo: tipos de estudios, areas de estudios), as como tambi en la ventaja de poder imprimir los formatos en el momento que se disponga para realizar alg un tr amite o comprobaci on. Otra caracter stica no menos importante es el hecho de que el sistema desarrollado estar a alojado y funcionar a completamente sobre el hardware con el que el HRAE Ciudad Salud cuenta sin provocar ning un cambio o conicto y sin la necesidad de adquirir nuevos equipos de c omputo.
Cap tulo 4 METODOLOG IA DE DESARROLLO

4.1. Plan de Trabajo
Actividades a Realizar 1. Identicaci on de problemas, oportunidades y objetivos 2. Determinaci on de los requerimientos de informaci on 3. An alisis de las necesidades del sistema 4. Dise no del sistema planteado 5. Desarrollo y documentaci on del software 6. Pruebas y mantenimiento del sistema 7. Implementaci on y Evaluaci on del sistema
4.2.
4.2.1.
Determinaci on de los Requerimientos

Requerimientos Funcionales
Autenticidad y Funcionalidad El usuario tendr a la posibilidad de acceder al Sistema de control de consulta externa del Hospital Regional de Alta Especialidad (HRAE) Ciudad Salud en sus diferentes areas u nicamente identic andose con un usuario y un password dentro de un formulario de inicio de sesi on. El sistema contar a con un men u que permita a los usuarios acceder a las diferentes funcionalidades del sistema A cada solicitud realizada dentro del sistema de control se le asignar a un identicador u nico (ID NOMBRE SOLICITUD). 23
24
CAP ITULO 4. METODOLOG IA DE DESARROLLO El sistema deber a agregar desde el inicio algunos datos del paciente y del personal dentro del formulario actual al momento de ingresar el n umero de expediente de dicho paciente. El sistema de control de consulta tendr a la funcionalidad de poder imprimir los diferentes tipos de solicitudes en el momento en que se disponga. El sistema podr a ser ejecutado en los diversos navegadores web disponibles actualmente. El sistema permitir a el ingreso o registro de nuevos usuarios.
Consultas El Sistema permitir a al usuario elegir qu e tipo de solicitud desea visualizar. Esta tendr a la posibilidad de ser impresa en formato digital o en papel Solicitudes y Formatos Solicitud de Electrodiagn ostico: El formato permitir a al usuario realizar el llenado de toda la solicitud, as mismo contar a con la restricci on de llenado de los campos: car acter, fecha y hora de la cita, secci on y cama, y tipo de estudio solicitado; si estos datos no est an llenos el formato no podr a ser almacenado o impreso. Interconsulta: Permitir a al usuario llenar los datos cl nicos del paciente internado, el formato ser a almacenado hasta que los datos est en completos teniendo como restricci on de guardado los campos: hora, servicio y servicio interconsultado, sin los cuales no podr a almacenarse. Receta Hospitalaria: Permitir a el llenado de la receta del paciente internocon sus datos y su diagn ostico, cada receta proporcionar a espacio para un solo medicamento por lo que al recetar m as de un medicamento ser a obligatorio llenar otra receta m edica, las restricciones para ser almacenada dentro del sistema ser an los campos: secci on y cama. Receta Externa: Permite el llenado de los datos para la asignaci on de medicamentos al paciente. Componentes Sangu neos: Las restricciones de esta solicitud para poder ser almacenada ser a el ingreso obligatorio de los datos: tipos de componentes, car acter de la solicitud, unidades solicitadas, transfusiones previas, fecha de la u ltima transfusi on, reacciones transfusionales, obitos y el tipo de paciente que es atendido. Productos Sangu neos: Este formato ser a almacenado hasta que los siguientes campos est en llenos: fracci on, n umero de unidades solicitadas y vol umen, fecha de cirug a, hora, transfusiones previas y reacci on transfusional. Solicitud de Anatom a-Patolog a: Permite realizar la orden de estudios, los datos personales y cl nicos del paciente, la pieza quir urgica o espec men a enviar; as mismo contar a con los datos necesarios los cuales ser an: tipo de estudio a solicitar, n umero de estudio, servicio, secci on y cama, sin los cuales no podr a ser almacenado.
DE LOS REQUERIMIENTOS 4.2. DETERMINACION
25
Solicitud de Imagenolog a:Permitir a solicitar la orden de estudios al Departamento de Imagenolog a, los datos que deber an ser llenados obligatoriamente ser an: la persona quien autoriza el formato, el caracter del estudio a solicitar, la fecha de la cita, hora, secci on, cama y el o los tipos de estudios necesarios. Solicitud de Ex amenes de Laboratorio: Este formato permite al usuario solicitar diversos tipos de estudios de laboratorio, el cual a su vez contiene los datos del paciente y su diagn ostico cl nico; este formato estar a restringido por los campos: servicio, secci on y cama, tipos de estudio solicitados y el nombre espec co de los estudios a realizar, estos campos ser an necesarios para poder guardar los datos en el sistema. Formato de Curaciones: Permite seleccionar los paquetes de curaciones utilizados por el m edico. El formato cuenta tambi en con el nombre del paciente y la fecha. Pruebas cruzadas: Esta solicitud contemplar a la siguiente restricci on: ser a estrictamente obligatorio llenar los campos de: tipo de estudio a realizar, caracter de la solicitud, n umero de unidades a solicitar, secci on y cama, transfusiones previas, fecha de la u ltima transfusi on, reacci on transfusional, obitos, servicio y tipo de paciente. Todos los datos anteriores ser an necesarios para que la solicitud sea guardada exitosamente. Administrador Contar a con una cuenta de administrador protegida con Usuario y contrase na desde la cual se podr an realizar modicaciones o altas de datos en el sistema. Esta cuenta no se encontrar a visible en la pantalla de inicio del usuario.
4.2.2.
Requerimientos No Funcionales
El sistema se deber a implementar sobre la infraestructura existente dentro del Hospital Regional de Alta EspecialidadCiudad Salud. La aplicaci on deber a funcionar sobre el sistema operativo Windows. El sistema deber a ser desarrollado bajo el entorno del Gestor de Base de Datos MySQL. La informaci on estar a protegida contra accesos no autorizados al sistema utilizando para ello mecanismos de validaci on de datos que puedan suplir esta funci on, de manera que cada usuario estar a identicado con un u nico nombre de usuario y una contrase na. El sistema deber a ser tolerante ante fallos y las operaciones deben ser transaccionales. Requisitos de rendimiento El sistema web prestar a un servicio r apido y veraz atendiendo las necesidades del administrador/usuario con un tiempo l ogico teniendo en cuenta la cantidad de informaci on alojada dentro de la base de datos.
26
CAP ITULO 4. METODOLOG IA DE DESARROLLO Seguridad: Esta caracter stica ser a controlada de acuerdo a las cuentas de usuario y password que se exigir an para poder acceder a la plataforma o interfaz del sistema. Fiabilidad: El sistema ser a able y conable mientras cuente con los recursos necesarios para su funcionamiento, siendo el mayor recurso la energ a el ectrica y el internet. Disponibilidad: El sistema necesitar a mantenimiento, por lo cual ser a autom aticamente, esto se decidir a al momento que se est e desarrollando el software, obviamente por ciertas restricciones espec cas del programador. Portabilidad: El software ser a portable y funcional en otro hardware (equipo) siempre y cuando re una los requisitos del software o sistema (sistema operativo, herramientas y aplicaciones para la compilaci on del software, ejemplo: mysql, apache, php).
4.3.
Factibilidades
Despu es de denir la problem atica presente dentro del Hospital Regional de Alta Especialidad Ciudad Salud y establecer las causas que ameritan la creaci on de un nuevo sistema, es pertinente realizar un estudio de factibilidad para determinar la infraestructura tecnol ogica y la capacidad t ecnica que implica la implementaci on del sistema en cuesti on as como los costos, benecios y el grado de aceptaci on que la propuesta genera en la instituci on. Este an alisis permiti o determinar las posibilidades de dise nar el sistema propuesto y su puesta en marcha, los aspectos tomados en cuenta para este estudio fueron clasicados en tres areas, las cuales se describen a continuaci on:
4.3.1.
Factibilidad T ecnica
La factibilidad t ecnica consisti o en realizar una evaluaci on de la tecnolog a existente dentro de la organizaci on, este estudio estuvo destinado a recolectar informaci on sobre los componentes t ecnicos que posee dicha organizaci on y la posibilidad de hacer uso de los mismos en el desarrollo e implementaci on del sistema propuesto y de ser necesario, los requerimientos tecnol ogicos que deben ser adquiridos para el desarrollo y puesta en marcha del sistema en cuesti on. Evaluando el hardware existente y tomando en cuenta la conguraci on m nima necesaria del sistema, la organizaci on no requiere realizar inversi on inicial para la adquisici on de nuevos equipos, ni tampoco para potenciar o actualizar los equipos existentes, ya que los mismos satisfacen los requerimientos establecidos para el desarrollo y puesta en funcionamiento del sistema propuesto.
4.3.2.
Factibilidad Econ omica
En este apartado se muestra un estudio que dio como resultado la factibilidad econ omica del desarrollo del nuevo sistema de informaci on. Se determinaron los recursos para desarrollar, implantar y mantener en operaci on el sistema programado haciendo una evaluaci on donde se puso de maniesto el equilibrio existente entre los costos intr nsecos del sistema y los benecios que se derivaron de este, lo cual permiti o observar de una manera m as precisa las bondades del sistema desarrollado.
4.3. FACTIBILIDADES
27
Es por lo anterior que, el Sistema de control de consulta externa del Hospital Regional de Alta Especialidad (HRAE) Ciudad Salud es viable y aceptable dentro de la instituci on de salud. En apoyo a lo anterior se realiz o una estimaci on de los costos de desarrollo e implementaci on del sistema planteado, este an alisis se realiz o en base al modelo llamado COCOM (Modelo Constructivo de Costos).
4.3.3.
Factibilidad Operacional
Operacionalmente el sistema cuenta con recursos que permiten al usuario/administrador una f acil y sencilla operaci on, teniendo interfaces claras y permitiendo el uso paralelo de otros sistemas necesarios para su operaci on diaria. El proyecto cubre al cien por ciento los requerimientos planteados y su operaci on es igualmente pr actica y sencilla.
28
CAP ITULO 4. METODOLOG IA DE DESARROLLO
4.4.
Diagrama Entidad Relaci on
El siguiente esquema muestra el diagrama general de entidades y relaciones del Sistema Generador de Solicitudes de Auxiliares de Diagn ostico de la Consulta Externa del Hospital Regional de Alta Especialidad Ciudad Salud. Para su mejor comprensi on se opt o por simplicar el diagrama en entidades y relaciones debido a su tama no y a sus m ultiples atributos.
Figura 4.1: Diagrama Entidad-Relaci on
4.4. DIAGRAMA ENTIDAD RELACION
29
El diagrama se compone por 30 entidades, las cuales se encuentran detalladas a continuaci on:
Figura 4.2: Entidad Solicitud de Electrodiagn ostico
Figura 4.3: Entidad cama
Figura 4.4: Entidad seccion
Figura 4.5: Entidad estudios de electrodiagn ostico
30
Figura 4.6: Entidad receta hospitalaria
Figura 4.7: Entidad receta externa
Figura 4.8: Entidad Ex amenes de Laboratorio
Figura 4.9: Entidad Detalle de Ex amenes de laboratorio
31
Figura 4.10: Entidad cat alogo ex amenes de laboratorio
Figura 4.11: Entidad de Anatom a Patolog a
Figura 4.12: Entidad Estudio Anatom a Patolog a
Figura 4.13: Entidad Interconsulta
32
Figura 4.14: Entidad Imagenolog a
Figura 4.15: Entidad detalle de estudios Imagenolog a
Figura 4.16: Entidad Curaciones
Figura 4.17: Entidad paquete Curaciones
33
Figura 4.18: Entidad Cat alogo de curaciones
Figura 4.19: Entidad Componentes Sangu neos
Figura 4.20: Entidad Detalle de Componentes Sangu neos
34
Figura 4.21: Entidad Banco de sangre Componente Sangu neo
Figura 4.22: Entidad Pruebas Cruzadas
35
Figura 4.23: Entidad Banco de sangre Pruebas Cruzadas
Figura 4.24: Entidad Producto Sangu neo
Figura 4.25: Entidad descripci on productos sangu neos
36
Figura 4.26: Entidad Detalle pruebas cruzadas
Figura 4.27: Entidad Pacientes
Figura 4.28: Entidad Expedientes
Figura 4.29: Entidad Personal
37
Figura 4.30: Entidad Cat alogo de Especialidades
Figura 4.31: Entidad Detalle personal especialidad
Figura 4.32: Entidad cat alogo Electrodiagn ostico
Figura 4.33: Entidad cat alogo componentes sangu neos
38
Figura 4.34: Entidad cat alogo anatom a-patolog a
Figura 4.35: Entidad cat alogo Imagenolog a
Figura 4.36: Entidad cat alogo Ex amenes de Laboratorio
Figura 4.37: Entidad cat alogo Productos sangu neos
39
Figura 4.38: Entidad cat alogo Productos banco
Figura 4.39: Entidad banco Productos sangu neos
Figura 4.40: Entidad cat alogo pruebas cruzadas
40
4.5.
Diagrama Relacional
Figura 4.41: Diagrama Relacional
4.6. DICCIONARIO DE DATOS
41
4.6.
Diccionario de Datos
42
43
44
45
46
47
48
49
Figura 4.42: Diccionario de Datos
50
4.7.
Casos de Uso
Figura 4.43: Sistema Generador de Solicitudes de Auxiliares de Diagn ostico
4.7. CASOS DE USO
51
4.7.1.
Objetivos del sistema
Figura 4.44: Descripci on del subsistema Gesti on de Solicitudes y Formatos
Figura 4.45: Descripci on del subsistema Gesti on de consultas
52
Figura 4.46: Descripci on del subsistema Gesti on de usuarios
4.7.2.
Diagrama de subsistemas y casos de Uso
Figura 4.47: Diagrama de subsistemas y casos de uso
4.7. CASOS DE USO
53
Figura 4.48: Caso de uso del subsistema Gesti on de Solicitudes y Formatos
Figura 4.49: Caso de uso del subsistema Gesti on de Consultas
54
Figura 4.50: Caso de uso del subsistema Gesti on de Usuarios
4.7. CASOS DE USO
55
Figura 4.51: Receta Hospitalaria Interna
56
Figura 4.52: Receta Hospitalaria Externa
4.7. CASOS DE USO
57
Figura 4.53: Solicitud de Imagenolog a
58
Figura 4.54: Solicitud de Interconsulta
4.7. CASOS DE USO
59
Figura 4.55: Solicitud de Ex amenes de Laboratorio
60
Figura 4.56: Solicitud de Electrodiagn ostico
4.7. CASOS DE USO
61
Figura 4.57: Formato de Cobro por Curaciones
62
Figura 4.58: Solicitud de Anatom a-Patolog a
4.7. CASOS DE USO
63
Figura 4.59: Descripci on del caso de uso Solicitud de Productos sangu neos
64
Figura 4.60: Descripci on del caso de uso Componentes sangu neos
4.7. CASOS DE USO
65
Figura 4.61: Descripci on del caso de uso Pruebas Cruzadas
66
4.7.3.
Especicaci on de los Casos de Uso
Figura 4.62: Descripci on del caso de uso Receta Hospitalaria
4.7. CASOS DE USO
67
Figura 4.63: Descripci on del caso de uso Receta Externa
68
Figura 4.64: Descripci on del caso de uso Solicitud de Imagenolog a
4.7. CASOS DE USO
69
Figura 4.65: Descripci on del caso de uso Interconsulta
70
Figura 4.66: Descripci on del caso de uso Ex amenes de Laboratorio
4.7. CASOS DE USO
71
Figura 4.67: Descripci on del caso de uso Electrodiagn ostico
72
Figura 4.68: Descripci on del caso de uso Formato de cobro por curaciones
4.7. CASOS DE USO
73
Figura 4.69: Descripci on del caso de uso Anatom a-Patolog a
74
Figura 4.70: Descripci on del caso de uso Componentes Sangu neos
4.7. CASOS DE USO
75
Figura 4.71: Descripci on del caso de uso Productos Sangu neos
76
Figura 4.72: Descripci on del caso de uso Pruebas Cruzadas
4.8. DIAGRAMA DE CLASES
77
4.8.
Diagrama de Clases
Figura 4.73: Diagrama de clases
78
4.9.
Modelo de Procesos
Figura 4.74: Modelo de Procesos del Sistema
4.10. DIAGRAMA DE ACTIVIDADES
79
4.10.
Diagrama de Actividades
Figura 4.75: Diagrama de actividades
80
4.11.
Diagrama de Estados
Figura 4.76: Diagrama de Estados
4.12. DIAGRAMA DE SECUENCIAS
81
4.12.
Diagrama de Secuencias
Figura 4.77: Diagrama de secuencias
82
4.13.
Diagrama de Distribuci on
Figura 4.78: Diagrama de Distribuci on
4.14. DIAGRAMA DE COLABORACION
83
4.14.
Diagrama de Colaboraci on
Figura 4.79: Diagrama de colaboraci on
84
4.15.
Modelo Costructivo de Costos COCOMO
De acuerdo a lo explicado en el Cap tulo 3 se ha identicado al Sistema de Control de consulta externa del Hospital Regional de Alta Especialidad Ciudad Salud como un proyecto de tipo Org anico. Para poder calcular las determinantes del sistema el Modelo COCOMO establece las siguientes ecuaciones: Esfuerzo Hombre -Mes: M M = a(Kl)b Tiempo de desarrollo en Meses: T DEV = c(M M d ) N umero de personas seg un la duraci on del proyecto: costeH = M M/T DEV Costo total del proyecto:costeM = costeH SalarioM edioP rogramadores D onde: Kl= es el n umero de miles de l neas c odigo estimado para el proyecto. Los coecientes de las ecuaciones est an establecidas dentro del modelo y se muestran en la siguiente tabla:
Figura 4.80: Tabla de Clasicaci on de Proyectos en el Modelo COCOMO De acuerdo a los datos denidos que proporciona el modelo de Costos, se han realizado las siguientes operaciones para calcular los factores mencionados anteriormente: C alculo del Esfuerzo Hombre - Mes: M M = a(Kl)b M M = 2,4(5)1,05 M M = 2,4(5,41) M M = 13 C alculo del tiempo de desarrollo en Meses: T DEV = c(M M d ) T DEV = 2,5(130,38 )
4.15. MODELO COSTRUCTIVO DE COSTOS COCOMO T DEV = 2,5(2,65) T DEV = 6,62 C alculo costeH costeH costeH del n umero de personas para la realizaci on del proyecto: = M M/T DEV = 13/6,62 = 1,96
85
C alculo del costo total del proyecto Salario promedio seg un tecnolog a: $25,0001 (Mensuales) costeM = CosteH SalarioP romedioP rogramador CosteH = 2 25, 000 (6meses) CosteM = 2 $120, 000 CosteM = $300, 000
Salarios en M exico http://briceno.mx/2011/05/php-y-los-salarios-en-mexico/
86
4.16.
Cronograma de Actividades
Figura 4.81: Cronograma de Actividades
Cap tulo 5 RESULTADOS

5.1. Sistema implementado vs Sistema manual
Con el objetivo de minimizar el periodo de tiempo que lleva realizar una solicitud de estudio para las diversas areas del hospital se desarroll o el Sistema Generador de solicitudes de Auxiliares de Diagn ostico de la Consulta Externa del Hospital Regional de Alta Especialidad Ciudad Salud. Haciendo una comparaci on entre estos dos sistemas: el sistema actual que realiza las solicitudes de forma manual; y el sistema automatizado de solicitudes se obtuvieron los siguientes resultados:
Figura 5.1: Gr aca comparaci on de tiempo en minutos de la solicitud de estudios entre ambos sistemas Aunque la diferencia de tiempo no es relativamente amplia, cabe recordar que el Sistema Generador de solicitudes realizar a los formatos debidamente requisitados y llenados ya que obliga al usuario del sistema a ingresar todos los datos de estas solicitudes para llevar un mayor control de datos y sobre todo una abilidad y consistencia de mayor grado en los datos capturados y almacenados.
87
88
CAP ITULO 5. RESULTADOS
5.2.
Conclusi on
La rama de la inform atica con el paso del tiempo se ha ido mezclando en la mayor parte de las actividades de la vida cotidiana, hoy en d a es una de las herramientas imprescindibles de muchas empresas y organizaciones tal es el caso del Hospital Regional de Alta ACiudad Especialidad A Salud el cual ha basado gran parte de su control de datos en sistemas inform aticos. Esta herramienta permite, entre otras actividades: manejar grandes cantidades de informaci on y relacionarla entre s , as como tambi en compartirla entre los diferentes departamentos de una instituci on, en este caso de tipo m edica, adem as provee un estilo unicado en la presentaci on de los datos y el manejo de formatos electr onicos. Es l ogico pensar que la inform atica puede proveer un entorno de seguridad, satisfacci on y calidad en la presentaci on de los datos, que es mAs ecaz que la versatilidad que proporciona el l apiz y el papel. Con el desarrollo del nuevo sistema se pretende reducir la propagaci on de informaci on con mala calidad, m as preciso, datos err oneos e incompletos que la mayor a de las veces surgen por la falta de un medio que ayude y exorte al usuario a indicar y anotar adecuadamente sus datos, el sistema tiene como restricci on el no poder realizar solicitud de estudios con datos faltantes o err oneos. Es por lo anterior que este sistema permitir a un nuevo ujo de datos dentro del hospital y de la misma manera un orden estricto de su informaci on.
5.3. ANEXOS
89
5.3.
Anexos
Las siguientes im agenes son capturas de pantalla del Sistema Generador de Solicitudes.
Figura 5.2: Pantalla principal del sistema
Figura 5.3: Pantalla de a rea de solicitudes
90
Figura 5.4: Formulario de Interconsulta
Figura 5.5: Formulario de receta m edica hospitalaria
5.3. ANEXOS
91
Figura 5.6: Formulario de receta m edica hospitalaria externa
Figura 5.7: Formulario de solicitud de componentes sangu neos
92
Figura 5.8: Formulario de solicitud de Anatom a Patolog a
Figura 5.9: Formulario solicitud de estudios de Imagenolog a
5.3. ANEXOS
93
Figura 5.10: Formulario solicitud de estudios Electrodiagn ostico
94
Figura 5.11: Formulario solicitud de Ex amenes de Laboratorio
Figura 5.12: Formulario solicitud de Productos Sangu neos
5.3. ANEXOS
95
Figura 5.13: Formato de cobro por curaciones
96
Area de Consulta
Este formulario se encuentra disponible para cada area de solicitudes de estudios.
Figura 5.14: Formato de consulta de registros
Bibliograf a
[1] www.geocities.com/Silicon Valley/Pires/7894/Introducci on al desarrollo de los sistemas de informaci on. [2] Angel Cobo, Patricia G omez, Daniel P erez y Roc o Rocha. (2005). PHP y MySQL Tecnolog as para el desarrollo de aplicaciones web. Ediciones D az Santos, ISBN: 84-7978-706-6. [3] http://www.esepestudio.com/articulo/desarrollo-web/bases-de-datos-mysql/Quees-MySQL.html. Recuperado el 16 de Agosto de 2005. [4] : Mar a Jes us Lamarca Lapuente. Tesis doctoral. Universidad Complutense de Madrid. URL: http://www.hipertexto.info. Fecha de Actualizaci on: 05 de Diciembre de 2011. [5] Mario Bunge. Diccionario El peque no Larousse Ilustrado, Editorial Larousse, edici on 1999. http://fcasua.contad.unam.mx/apuntes /interiores/docs/98/4/informatica4.pdf [6] Olga Pons, Nicol as Mar n, Juan Miguel Medina, Silvia Acid, Ma. Amparo Vila. Introducci on a las bases de datos El modelo Relacional. Thomson Editores Spain 2005 (281 pags.) [7] Ian Sommerville. Ingenier a del software 7. Edici on Pearson Educaci on, S.A.,Madrid, 2005. (712 pags.) [8] Esperanza Marcos, Bel en Vela, Juan M. Vara. Dise no de base de datos ObjetoRelacionales con UML. Editorial DYKINSON, Madrid, 2005.
97

Sistema Generador de Solicitudes

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema Generador de Solicitudes

Cargado por

Copyright:

Formatos disponibles

Dise no e Implementaci on del Sistema Generador de Solicitudes de Auxiliares de Diagn ostico de la Consulta Externa del HRAE Ciudad Salud

Residentes: Acosta D az Jarumy Jacquelin Rodr guez S anchez Jos e Alberto

INDICE GENERAL 3.11. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 23 23 23 23 25 26 26 26 27 28 40 41 50 51 52 66 77 78 79 80 81 82 83 84 86 87 87 88 89

Cap tulo 1 PLANTEAMIENTO DEL PROYECTO

CAP ITULO 1. PLANTEAMIENTO DEL PROYECTO

Objetivos espec cos

Cap tulo 2 DATOS DE LA EMPRESA

CAP ITULO 2. DATOS DE LA EMPRESA

Figura 2.1: Organigrama General de HRAE Ciudad Salud

Organigrama del Depto. de Tecnolog as

Figura 2.2: Organigrama del Depto. de Tecnolog as de Informaci on del HRAE

CAP ITULO 2. DATOS DE LA EMPRESA

Figura 2.3: Macrolocalizaci on

Figura 2.4: Microlocalizaci on

CAP ITULO 2. DATOS DE LA EMPRESA

Cap tulo 3 FUNDAMENTO TEORICO

CAP ITULO 3. FUNDAMENTO TEORICO

CAP ITULO 3. FUNDAMENTO TEORICO

CAP ITULO 3. FUNDAMENTO TEORICO

3.7. GESTOR DE BASE DE DATOS

Gestor de Base de Datos

Modelo Constructivo de Costos

CAP ITULO 3. FUNDAMENTO TEORICO

3.10. MODELO CONSTRUCTIVO DE COSTOS

Estado del Arte

Cap tulo 4 METODOLOG IA DE DESARROLLO

Determinaci on de los Requerimientos

DE LOS REQUERIMIENTOS 4.2. DETERMINACION

Factibilidad Econ omica

CAP ITULO 4. METODOLOG IA DE DESARROLLO

Diagrama Entidad Relaci on

Figura 4.1: Diagrama Entidad-Relaci on

4.4. DIAGRAMA ENTIDAD RELACION

Figura 4.2: Entidad Solicitud de Electrodiagn ostico

Figura 4.3: Entidad cama

Figura 4.4: Entidad seccion

Figura 4.5: Entidad estudios de electrodiagn ostico

CAP ITULO 4. METODOLOG IA DE DESARROLLO

Figura 4.6: Entidad receta hospitalaria

Figura 4.7: Entidad receta externa

Figura 4.8: Entidad Ex amenes de Laboratorio

Figura 4.9: Entidad Detalle de Ex amenes de laboratorio

4.4. DIAGRAMA ENTIDAD RELACION

Figura 4.10: Entidad cat alogo ex amenes de laboratorio

Figura 4.11: Entidad de Anatom a Patolog a

Figura 4.12: Entidad Estudio Anatom a Patolog a

Figura 4.13: Entidad Interconsulta

CAP ITULO 4. METODOLOG IA DE DESARROLLO

Figura 4.14: Entidad Imagenolog a

Figura 4.15: Entidad detalle de estudios Imagenolog a

Figura 4.16: Entidad Curaciones

Figura 4.17: Entidad paquete Curaciones

4.4. DIAGRAMA ENTIDAD RELACION

Figura 4.18: Entidad Cat alogo de curaciones

Figura 4.19: Entidad Componentes Sangu neos

Figura 4.20: Entidad Detalle de Componentes Sangu neos

CAP ITULO 4. METODOLOG IA DE DESARROLLO

Figura 4.21: Entidad Banco de sangre Componente Sangu neo

Figura 4.22: Entidad Pruebas Cruzadas

4.4. DIAGRAMA ENTIDAD RELACION

Figura 4.23: Entidad Banco de sangre Pruebas Cruzadas

Figura 4.24: Entidad Producto Sangu neo

Figura 4.25: Entidad descripci on productos sangu neos

CAP ITULO 4. METODOLOG IA DE DESARROLLO