Consultorio Médico

Consultorio Médico
Gustavo Maximiliano Cortez
gustavo@uku.co.uk
Julio de 2005
Índice
I. Idea de Producto 4
1. Identificación de usuarios participantes 4
2. Catálogo de requisitos del sistema 5
2.1. Objetivos y alcance del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Definiciones, acrónimos y abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Suposiciones y dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6. Requisitos de usuario y tecnológicos . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7. Requisitos de interfaces externas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8. Requisitos de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9. Requisitos de desarrollo y restricciones de diseño . . . . . . . . . . . . . . . . . . . 13
II. Especificación C 13
3. Modelización del sistema 13
3.1. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3. Diagramas de interacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1. Escenario: ingreso de nuevas personas . . . . . . . . . . . . . . . . . . . . . 16
3.3.2. Escenario: eliminar personas . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.3. Escenario: modificar personas . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.4. Escenario: llegada de un paciente nuevo . . . . . . . . . . . . . . . . . . . . 16
2

Índice Índice
3.3.5. Escenario: agregar paciente a la lista de espera . . . . . . . . . . . . . . . . 17
3.3.6. Escenario: atención del paciente de la lista de espera . . . . . . . . . . . . . 17
3.3.7. Escenario: facturación del mes . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.8. Escenario: nueva obra social . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.9. Escenario: nueva historia clínica . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Fichas CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.1. Clase Consultorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.2. Clase Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.3. Clase Médicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.4. Clase Secretaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.5. Clase Atención . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.6. Clase LíneaAtención . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.7. Clase Facturación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.8. Clase LíneaFacturación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.9. Clase HistoriaClínica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.10. Clase Pacientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.11. Clase ObraSocial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4. Identiﬁcación de roles 20
4.1. Rol Médico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Rol Secretaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Rol Administración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. Guiones y Escenarios 21
5.1. Diagramas de Transición de Escenarios . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Tablas de Transición de Escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3. Escenario US-00-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4. Escenario US-01-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.5. Escenario US-02-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.6. Escenario US-03-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.7. Escenario US-04-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.8. Escenario US-05-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.9. Escenario US-06-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.10. Escenario US-07-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.11. Escenario US-08-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.12. Escenario US-09-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
III. Especiﬁcación D 28
3

1 IDENTIFICACIÓN DE USUARIOS PARTICIPANTES
6. Arquitectura física del sistema 28
7. Fichas técnicas de Métodos de Objetos 29
7.1. Clase Secretaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2. Clase Facturación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Clase LíneaFacturación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Fichas técnicas de eventos de Objetos de Escenarios 32
8.1. Escenario US-01-00 (Administrador) . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.2. Escenario US-09-00 (Facturación) . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Diseño de la estructura de datos 34
9.1. Modelo lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2. Modelo físico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Parte I.
Idea de Producto
Esta especificación tiene como objetivo analizar y documentar las necesidades funcionales que de-
berán ser soportadas por el sistema CONSULTORIO MÉDICO. Para ello, se identificarán los requisitos
que ha de satisfacer el nuevo sistema mediante varias entrevistas, el estudio de los problemas de las
unidades afectadas y sus necesidades actuales.
Además de identificar los requisitos se deberán establecer prioridades, lo que nos proporciona un
punto de referencia para validar el sistema final y compruebe que se ajusta a las necesidades del
usuario.
1. Identificación de usuarios participantes
Los objetivos de esta tarea son identificar el o los responsable/s del manejo e interacción directa
con el software, es decir las personas que ingresan los datos al sistema.
Estas personas son denominadas usuarios del sistema, y además cuentan con los privilegios de-
terminados por el grupo al que pertenecen para el ingreso de determinados datos. Estos grupos de
usuarios están compuestos por:
1. Médico: es quien lleva a cabo todo el proceso de ingreso de datos del paciente, así también
como el ingreso de un exámen médico, historia clínica y además debe consultar al sistema para
imprimir informes de los pacientes, la facturación del mes, etc.
4

2 CATÁLOGO DE REQUISITOS DEL SISTEMA
2. Secretaria: encargada de llevar a cabo el proceso de recepción e ingreso de datos personales de
un paciente nuevo y agregarlo a la cola de espera.
3. Administrador: encargado de la administración del sistema, con los privilegios para crear,
borrar y modificar los usuarios Médico y Secretaria. También pueden ingresar nuevas Obras
Sociales, modificarlas o eliminarlas.
2. Catálogo de requisitos del sistema
El objetivo de la especificación es definir de forma clara, precisa, completa y verificable todas las
funcionalidades y restricciones del sistema CONSULTORIO MÉDICO. Esta documentación está sujeta
a revisiones por parte del grupo de usuarios del sistema, que se recogerán por medio de sucesivas
versiones del documento hasta alcanzar su aprobación por parte de los mismos. Una vez aprobada
la documentación, la misma servirá de base al equipo de desarrollo para la construcción del nuevo
sistema.
El sistema es capaz de llevar a cabo la administración de un consultorio médico en el que participan
los usuarios antes mensionados, con la finalidad de agilizar el procedimiento de una consulta y brindar
un mejor servicio a sus clientes.
Esta especifiación se ha realizado de acuerdo al estándar “IEEE Recomended Practice for Software
Requeriments Specifications (IEEE/ANSI 830-1993)”, y se basa en las entrevistas realizadas a los
Médico interesados en adquirir el sistema y además en el estudio de la documentación actual.
2.1. Objetivos y alcance del sistema
El principal objetivo del sistema es mejorar y acelerar el proceso de consultas médica, permitiendo
a los médicos llevar un mejor control de los pacientes, ya que pueden recurrir a sus historias clínicas,
examenes anteriores, resultados de análisis impresos, sin necesidad de volver a repetir los motivos de
consulta anteriores. El futuro sistema será denominado de tal manera que describa brevemente su fun-
cionamiento: CONSULTORIO MÉDICO. El desarrollo del mismo será efectuado por Cissu Software.
El sistema debe satisfacer las necesidades de todo médico especialista que requiera llevar un control
estricto de atención médica de todos sus pacientes. Esta necesidad permite plantear el objetivo del
sistema como una solución que conlleva a resolver los problemas tales como el espacio físico que
ocupan las grandes cantidades de archivos de datos histórico de los pacientes y a acelerar el proceso
de atención médica. Además, la pérdida de tiempo a la hora de realizar la facturación mensual y la
falta de estándares que permitan realizar una historia clínica limpia y precisa son factores que llevan
a optar por el sistema CONSULTORIO MÉDICO.
Por lo tanto, el sistema hace incapié en la performance y en la posibilidad de almacenar gran
cantidad de información y manipularla sin pérdida de rendimiento.
5

2.2 Definiciones, acrónimos y abreviaturas 2 CATÁLOGO DE REQUISITOS DEL SISTEMA
2.2. Definiciones, acrónimos y abreviaturas
En esta sección se listan términos escenciales para la mejor comprensión de la presente documen-
tación.
Definiciones
Historia clínica: es el exámen médico predeterminado que se lleva a cabo para obtener infor-
mación sobre el estado de salud de un paciente.
Prestador: es el profesional Médico desde el punto de vista comercial, ya que éste actúa como
mediador entre una obra social o prepaga y el paciente.
Ficha Médica: donde se ingresan todos aquellos datos que hagan referencia al paciente, como
apellidos, nombre, dirección, etc. para luego tener una referencia del mismo en consultas pos-
teriores.
Prepaga: se llama así a una obra social privada, que no depende del estado ni de gremios,
y presta diferentes tipos de servicios como por ejemplo la posibilidad de realizar consultas,
internaciones, etc.
Obra Social: presta servicios destinados a la salud, como la emisión de órdenes de consulta, in-
ternación, medicamentos, etc. Estos servicios pertenecen al estado o a gremios de trabajadores.
Nomenclador: es un sistema de prácticas médicas nacional codificado. Está compuesto por
código, subcódigo, práctica, honorarios de especialista, de primer ayudante, segundo ayudante,
anestesista, instrumentista, honorarios totales, gastos sanatoriales, unidad arancelaria, total en
pesos, comentarios y zonas agrupadas de prácticas.
Galeno: unidad en que se miden los honorarios en el Nomenclador. Estas unidades luego son
pasadas a pesos argentinos.
Acrónimos
SQL: Structured Query Language
ORDBMS: Sistema de Gestión de Base de Datos Relacionales de Objetos (definición según el
equipo de desarrollo de PostgreSQL1)
Abreviaturas
IEEE: Institute of Electrical and Electronics Engineers
SOGO Tuc: Sociedad de Ginecología y Obstetricia de Tucumán
FASGO: Federación Argentina de Sociedades de Ginecología y Obstetricia
1
www.postgresql.org
6

2.3 Descripción general 2 CATÁLOGO DE REQUISITOS DEL SISTEMA
2.3. Descripción general
En esta sección se presenta una descripción general del funcionamiento del sistema, con el fin de
conocer las funciones principales que servirá de futura referencia para el desarrollo y entendimiento
del sistema.
Al tratarse de un sistema destinado a la salud y al uso de profesionales Médico capacitados para
ejercer su profesión pero no para el manejo de sistemas complejo2, el diseño de la interface de usuario
es lo primordial a la hora del desarrollo, ya que debe ser lo más amigable y fácil de usar posible,
ocultando toda su compejidad para que no requiera de grandes conocimientos en computación por
parte los usuarios.
Por otro lado, muchos profesionales que trabajan en empresas privadas (sanatorios, clínica, etc.),
deben recurrir al encargado de contaduría de la misma para comprobar que las ordenes de consultas
o prácticas hayan sido archivadas como corresponden. Pero en dicho proceso puede ocurrir que se
pierdan papeles o que sean traspapelados (ya que en una empresa de deben controlar todo lo que
ingresa y lo que egresa de la misma) perjudicando de esta manera a los médicos del lugar, ya que
pierden dinero al no disponer de la orden que fue emitida por la obra social o prepaga. Por este motivo
con el sistema se lleva a cabo fundamentamente el control de órdenes y la facturación correspondiente
realizada en el mes. De esta manera se conserva una copia de todas las prestaciones realizadas para
que el mismo profesional sea encargado de llevar a cabo sus finanzas.
El sistema no abarca temas demasiado profundos en el ámbito de la medicina (como especialida-
des específicas), ya que estas características aumentaría considerablemente su tamaño y sería inútil
para algunos profesionales de otras ramas de la medicina. Por ejemplo si la especialidad de un Mé-
dico es Tocoginecología, de nada le serviría un sistema base que contenga todos los exámentes que
se realizan en una sala de traumatología, y solo unas cuantas funciones sobre ginecología. Por este
motivo, el sistema esta destinado a las consultas en general, pero a su vez soporta plug-in para otras
especialidades. Los plug-in son programas que no pueden funcionar por si solos sino que necesitan
de algún programa base, en este caso el programa principal CONSULTORIO MÉDICO. Tales plug-in
contienen la información necesaria para cada especialidad, de manera que los usuarios no necesitan
instalar grandes cantidades de datos en especialidades que no se van a usar, es decir solamente con
instalar el plug-in de su especialidad y se tiene todas las funciones necesarias para tal especialidad.
En otras palabras el sistema permite una gran escalabilidad (utilizando el sistema de plug-in) ya que
mientras haya más usuarios con diferentes especialidades sólo se necesita instalar el plug-in para tal
especialidad y se continúa trabajando. Esta es una característica que permite seguir mejorando el sis-
tema (por módulos) e ir añadiendo nuevas funciones sin necesidad de realizar grandes modificaciones
en el núcleo del sistema.
La distribución de funciones debe estar disponible desde un único Panel Principal, donde estarán
las diferentes opciones para gestionar los múltiples usuarios y grupos del sistema, permitiendo el ac-
ceso (según sus privilegios) a determinados módulos. De esta manera se limita el uso de determinadas
2
Refiérase a sistemas computacionales.
7

2.3 Descripción general 2 CATÁLOGO DE REQUISITOS DEL SISTEMA
funciones, que son permitidas según los privilegios del usuario, y además impidiendo el acceso a otras
opciones que pueden poner en peligro al sistema y a todos los datos almacenados en el mismo. Estos
usuarios deben ser asignados por el Administrador de la aplicación, el cual debe tener permisos a
todas las funciones del sistema. La lista de usuarios debe estar asociada a un ”grupo de usuarios”, los
cuales se dividirán en Médico (y su especialidad), Secretaría y Administración. Estos grupos marcan
los límites que tiene cada usuario a la hora de interactuar con el sistema, permitiéndoles solamente el
acceso a los recursos y opciones de acuerdo al grupo que pertenecen.
El sistema estará dividido en cuatro grandes módulos que cumplen con su función independiente-
mente de los demás módulos. Cada uno de estos módulos tiene un grupo asociado, donde cada grupo
está compuesto por uno o más usuarios. Estos usuarios están limitados a utilizar solamente el módulo
que le fue asignado a su grupo. La división de los módulos del sistema en grupos de trabajo implica
un tipo de seguridad a la hora de permitir o no a determinados usuarios la utilizacón del módulo que
pertenece a su grupo. El ingreso a cada módulo se realiza mediante la pantalla principal de “Inicio de
sesión”, en el cual se ingresa nombre de usuario, contraseña y grupo de trabajo. De esta manera el
sistema verifica los datos ingresados para permitir el acceso al grupo de trabajo previamente seleccio-
nado. A los grupos que se pueden acceder son: Administración, Médico y Secretaria. A continuación
se listan los módulos disponibles.
ADMINISTRADOR: este módulo pertenece al grupo Administración, y cumple la función de
agregar, modificar o eliminar usuarios que pueden utilizar el sistema. También tienen la posibi-
lidad de agregar nuevas Obras Sociales.
MESA DE ENTRADA: este módulo pertenece al grupo Secretaria y se encarga de la recopilación
de datos personales de los pacientes. Esta función debe permitir realizar búsquedas, mostrar el
listado completo de pacientes, agregar, modificar y eliminar los mismos. Debe existir la posi-
bilidad de reservar turnos, pero por orden de llegada, es decir si un paciente existe, solamente
se lo debe agregar a la cola de espera para luego ser atendido. Esto significa que los turnos no
son reservados de un día para otro, sino que por orden de llegada se coloca al paciente en la
cola. Una vez almacenados los datos personales de un paciente y realizada la reserva de turno,
el sistema automáticamente debe calcular cuanto tiempo tiene que esperar el paciente para ser
atendido. En pocas palabras esta función consiste en recopilar los datos personales de un pacien-
te en particular y reservar turnos agregándolos a la cola de espera. Para realizar este proceso,
previamente se debe indicar el número de orden si es que el paciente dispone de obra social,
sino se debe indicar que se trata de una consulta particular.
ATENCIÓN MÉDICA: en este módulo se debe llevar a cabo todo el proceso necesario para rea-
lizar una consulta médica. El usuario de este módulo debe pertenecer al grupo Médicos para
poder realizar la atención médica de un paciente. En este módulo debe figurar lista de pacientes
que se encuentran en la cola de espera, para así seleccionarlos y disponer automáticamente de
todos sus datos, pudiendo rápidamente comenzar con la atención médica propiamente dicha.
8

2.4 Requisitos funcionales 2 CATÁLOGO DE REQUISITOS DEL SISTEMA
Esta función debe visualizar anteriores consultas realizadas por el mismo paciente junto a sus
respectivos motivos de consulta. Además debe tener la posibilidad de imprimir el historial de
consultas anteriores, fichas personales y listas de indicaciones médicas. Por otro lado, el sis-
tema debe ser capaz de mostrar el listado de pacientes atendidos en el día y en el mes junto
a sus respectivos motivos de consulta para la realización de estadísticas sobre los casos más
frecuente o casos menos frecuentes, que son datos valiosos para entidades como SOGO Tuc. a
nivel provincial y la FASGO a nivel nacional (en el caso de la especialidad de Ginecología y
Obstetricia).
FACTURACIÓN: este módulo pertenece al grupo Médico, pudiendo acceder al mismo a través
del módulo ATENCIÓN MÉDICA. En esta función se lleva a cabo el control de las atenciones
realizadas a cada paciente en un período mensual. Luego, el listado de consultas realizadas
deben ser impresas por obra social para ser enviadas a las mismas y poder recibir el pago por
las atenciones realizadas. Por otro lado, esta función debe permitir una vista previa (por mes)
de todo lo facturado durante un período, para luego preguntar si desea imprimir el informe.
Debe existir la posibilidad de que mientras se esté realizando la consulta médica, sea posible el
ingreso inmediato del paciente a la lista de facturación si es que dispone del número de orden.
Además se debe tener en cuenta de que algunos pacientes pueden ser atendidos con órdenes de
consultas de otra persona que no sea la que requiera la atención médica.
2.4. Requisitos funcionales
INGRESO AL SISTEMA
Esta función solamente recibe el nombre de usuario, la contraseña y el grupo de trabajo al que
pertenece el cliente. Cada uno de estos grupos de trabajo definen qué módulo será cargado una vez
que el sistema haya verificado el nombre y la contraseña del usuario.
Entrada: Usuario + Contraseña + Grupo [Médico | Secretaría | Administrador]
Proceso: el proceso de ingreso al sistema es mediante la comparación correcta de los datos
ingresados por el teclado y el registro en la base de datos. Si todo ello es correcto, entonces se
debe poder acceder al sistema.
Salida: la comparación correcta de los datos se debe visualizar mediante el ingreso al sistema y
al módulo habilitado para el grupo seleccionado.
FICHA DE LOS PACIENTES
El sistema recibe los datos que se consideren importantes para las ficha de los pacientes, que no
estén relacionados con su estado de salud o su historia clínica.
Entrada: IdPaciente + Apellido + Nombre + Dirección + {Teléfono} + (Celular) + {Email} +
CP + Ciudad + Provincia + Pais + Sexo [Masculino | Femenino] + Fecha Nacimiento + Estado
9

2.4 Requisitos funcionales 2 CATÁLOGO DE REQUISITOS DEL SISTEMA
Civil [Casado | Soltero | Viudo | Divorsiado] + Estudio [Primario | Secundario | Terciario |
Universitario] + Ocupación + Obra Social + N◦ Afiliado
Proceso: se realiza el ingreso de datos mediante la información dada por el paciente, siendo
algunos campos obligatorio, mientras que otros opcionales.
Salida: los datos ingresados deben ser almacenados en el sistema, o de lo contrario se debe
mostrar un mensaje de error. Datos actualizados.
ATENCIÓN MÉDICA
La atención médica consiste en estudios realizados al paciente y el ingreso de los resultados en el
sistema. Cada especialidad debe disponer de opciones específicas a su área, de manera que el sistema
pueda ser utilizado por Médico de cualquier especialidad.
Entrada: IdPaciente + IdConsulta + Fecha + Nro Orden + Motivo de consulta.
Proceso: el proceso consiste en el ingreso del número de orden (otorgado por la Obra Social) y
todos los demás datos de acuerdo al tipo de atención que se le realice al paciente. Estos datos
tienen que ver con la interacción directa médico-paciente, en donde será el médico quien cargue
los datos necesarios en el sistema.
Salida: se visualizan en la pantalla los datos ingresados por el médico y además todo el historial
del paciente que está siendo atendido. Es decir, sus consultas anteriores, prácticas y cualquier
información que sirva de ayuda para el médico en la atención corriente.
NUEVO/MODIFICAR USUARIO
Esta función permite tanto el ingreso como la modificación de los datos personales de un usuario
del sistema, es decir de las personas que van a interactuar con el sistema.
Entrada: IdUsuario + Password + Grupo [Médico | Secretaría | Administrador] + Nombre +
Apellido + Dirección + {Teléfono} + Celular + E-Mail + Notas
Proceso: se ingresan los datos de los usuarios del sistema con su respectiva contraseña y otros
datos importantes para un control más estricto de personal.
Salida: datos actualizados en el sistema. Error en caso de existir alguno.
CONSULTAR FICHA PACIENTE
Esta función es capaz de realizar una búsqueda rápida de algún paciente existente en el sistema.
Entrada: Tipo [Nombre | Apellido | ... ]
Proceso: se ingresa una cadena con el valor que se desea buscar. Este valor puede ser algún
nombre, apellido, número de documento, fecha de ingreso u obra social.
10

2.5 Suposiciones y dependencias 2 CATÁLOGO DE REQUISITOS DEL SISTEMA
Salida: lista de pacientes encontrados, o no se encontró ningún registro.
FACTURACIÓN
Esta función se encarga de procesar la información ingresada de manera que a fin de mes se pueda
detallar lo facturado de cada obra social y el importe monetario realizado. El sistema también debe
diferenciar las vías de facturación mensionadas anteriormente.
Entrada: Fecha + N◦ de Orden + Vía Facturación [Sanatorio | Obra Social] + Prestador + Pa-
ciente + Prestación [Consulta | Páctica]
Proceso: el proceso de facturación, realizado por el personal de facturación, consiste en ingresar
todas las órdenes realizadas en el mes facturada por cada Médico en particular.
Salida: indica si el ingreso de datos fue realizado correctamente.
LISTAR E IMPRIMIR FACTURACIÓN
Entrada: MesFacturación + Orden [Por obra social | Por apellido | Por fecha atención]
Proceso: para listar la facturación se ingresa el mes que se quiere visualizar junto al orden. Este
proceso se realiza siempre a fin de mes y luego de imprimir se lo presenta a la obra social en
cuestión.
Salida: listado de la facturación realizada en el mes, con la opción de imprimirlo. De otra manera
se mostrará una pantalla vacía sin registros.
2.5. Suposiciones y dependencias
1. Suposiciones: se asume que los requisitos de este documento son estables una vez que sean
aprobados por los clientes que fueron entrevistados. Cualquier petición de cambios en la espe-
cificación debe ser aprobada por todas las partes intervinientes y será gestionada por el equipo
de desarrollo.
2. Dependencias: no dispone de dependencias.
2.6. Requisitos de usuario y tecnológicos
Requisitos de usuario
como se mencionó anteriormente que al tratarse de profesionales en el área de salud, no se espera
que sean especialistas ni que realicen cursos para el manejo del sistema. Por este motivo, es tal la
importancia de desarrollar un sistema sensillo de utilizar y con una ayuda en línea para cada función
que se implemente.
11

2.7 Requisitos de interfaces externas 2 CATÁLOGO DE REQUISITOS DEL SISTEMA
Requisitos tecnológicos
debido a que la aplicación estará formada por una sola parte, es decir que no se van a dividir los mó-
dulos en programas separados, la instalación se debe efectuar en cada computadora que quiera utilizar
el sistema (luego se pueden instalar los plug-in por separados). De cada una de estas computadora se
puede acceder a cualquier módulo, ya que esta aplicación (cliente) se conectará al servidor de base de
datos (servidor), quién deﬁnirá los privilegios de cada usuario y así habilitará determinados módu-
los. De esta manera se construye un esquema cliente/servidor, en donde el servidor se debe encargar
únicamente de gestionar la base de datos del sistema, mientras que el entorno del cliente debe ofrecer
una interfaz amigable e intuitiva para ingresar los datos correspondientes. El sistema operativo que
utilizan los clientes actualmente es Microsoft Windows 95 y por el momento el médico realiza las
funciones de secretaria y de facturación, en el que luego se dividirán las tareas entre el personal. Por
lo tanto se prevee que el sistema operativo por defecto sea Windows y sus variantes en versiones, pero
a su vez el sistema debe tener la característica de portabilidad a otros sistemas operativos (por razones
de costo, o cualquier otro motivo). De esta manera las exigencias de hardware de máquinas clientes
no son relevante, de manera que la velocidad de las mismas no afectan al funcionamiento global del
sistema. Por otro lado, el sistema operativo del servidor estará instalado en una computadora apta para
las exigencias de los clientes (conectados simultáneamente). El sistema operativo instalado en el ser-
vidor será GNU/Linux para no tener que invertir en licencias de software original, ya que se ofrece un
servicio público y se pueden tener problemas legales. Esta implementación también ayuda a no tener
que invertir demasiado en hardware de la computadora servidor, que deberá ser como mínimo una In-
tel Pentium III 550Mhz en adelante o AMD Durón 800Mhz en adelante y 512MB de memoria RAM
(preferentemente 1GB). El sistema gestor de base de datos que va a estar instalado bajo GNU/Linux
será PostgreSQL, que tampoco requiere pagar licencia para su utilización comercial. Actualmente no
se dispone de una red físicamente conectada, pero para su funcionamiento se debe implementar una
red con tecnología Ethernet (o wi-ﬁ 802.11b según presupuesto) y se utilizará únicamente el protocolo
de control de transmisión (TCP) y protocolo de internet (IP).
2.7. Requisitos de interfaces externas
1. Interfaces de usuario: la interfaz de usuario debe ser de tipo ventanas, con estilo propio para
este tipo de aplicaciones, poniendo énfasis en el aspecto visual y la sensillez de uso.
2. Interfaces de hardware: para manejar el sistema se debe disponer de teclado y ratón, siendo el
primero para el ingreso de datos, y el segundo para agilizar algunas operaciones.
3. Interfaces de software: no dispone de interfaz con otro software.
12

2.8 Requisitos de rendimiento 3 MODELIZACIÓN DEL SISTEMA
2.8. Requisitos de rendimiento
El tiempo de espera que puede tolerar un usuario del sistema al realizar cualquier consulta por
compleja que sea, debe ser como máximo de 10 segundos. Por lo tanto, la tecnología utilizada para
la conexión de las máquinas debe ser lo suficientemente buena para lograr los resultados esperados.
Así también como el servidor, que debe responder rápidamente a cualquier petición por parte de las
máquinas clientes.
2.9. Requisitos de desarrollo y restricciones de diseño
Como requisito de desarrollo, el ciclo de vida del sistema será de Prototipado Evolutivo, de tal
manera que permita un desarrollo con posibles mejoras, cambio de funcionalidades, ingreso de carac-
terísticas adicionales o algunas otras características solicitadas por los clientes.
1. Ajuste a estándares: el ajuste a algún estándar estará desarrollado de acuerdo a la especialidad
y sus respectivos requerimiento en la solicitud de datos del paciente.
2. Seguridad: el sistema cliente debe manejar datos encriptados y no debe permitir el ingreso de
algún usuario sin contraseña. Del lado del servidor, la seguridad está limitada por el sistema
operativo y por el gestor de base de datos.
3. Política de respaldo: el sistema gestor de base de datos, debe realizar todas las noches (que es
el horario en que no hay actividad) el proceso de copia de seguridad de la base de datos a otro
disco rígido, para luego (cada dos o tres semanas) realizar la copia a un medio óptico que es el
más económico.
4. Base de datos: se ingresará al sistema por ODBC mediante el protocolo de red TCP/IP.
5. Política de borrado: no definido.
Parte II.
Especificación C
En la presente sección se tratarán los temas de modelización del sistema, identificación de roles y
desarrollo de los guiones y escenarios.
3. Modelización del sistema
A continuación se documenta la modelización del sistema Consultorio Médico, mediante diagramas
de clases, casos de uso, diagramas de transición de estados y fichas CRC.
13

3.1 Diagrama de clases 3 MODELIZACIÓN DEL SISTEMA
3.1. Diagrama de clases
14

3.2 Casos de uso 3 MODELIZACIÓN DEL SISTEMA
3.2. Casos de uso
Listado de casos de uso para el sistema Consultorio médico:
1. Ingreso de nuevas personas (usuarios del sistema)
2. Modificación de personas
3. Eliminación de personas
4. Llega un paciente
5. Se lo busca en la base de datos
6. Se ingresa un nuevo paciente
7. Se asocia un paciente a una obra social
8. Si se tiene, se ingresa el número de orden de la consulta
9. Se agrega el paciente a la lista de espera
10. El médico realiza una nueva atención al paciente en la lista de espera
11. El médico escribe el motivo de consulta
12. El médico escribe la historia clínica del paciente
13. El médico efectúa la facturación del mes, la cual tiene todas las consultas realizadas por obra
social
14. Imprimir facturación mensual por obra social
15. Ver registro de atención por obra social o particular
16. Consultar historia clínica de un paciente
17. Modificar historia clínica de un paciente
18. Eliminar historia clínica de un paciente
19. Imprimir historia clínica de un paciente
20. Ingreso de nueva obra social
21. Modificación de una obra social existente
22. Eliminación de una obra social
15

3.3 Diagramas de interacción 3 MODELIZACIÓN DEL SISTEMA
3.3. Diagramas de interacción
A Continuación se lleva a cabo el proceso de interacción de los usuarios con el sistema Consultorio
Médico.3
3.3.1. Escenario: ingreso de nuevas personas
Usuario Consultorio
Conjunto Personas BuscarPersona(cadena)
AgregarPersona(tipo_persona)
Buscar Persona
Si no existe
Crear persona
Sino
’La persona ya existe’
3.3.2. Escenario: eliminar personas
Usuario Consultorio
EliminarPersona(idPersona)
Buscar Persona
Si no existe
’La persona no existe’
Sino
Seleccionar persona
Borrar persona
3.3.3. Escenario: modiﬁcar personas
Usuario Consultorio
ModificarPersona(idPersona)
Buscar Persona
Si no existe
’La persona no existe’
Sino
Seleccionar persona
Modificar persona
3.3.4. Escenario: llegada de un paciente nuevo
Secretaria Pacientes
Conjunto Pacientes BuscarPaciente(cadena)
AgregarPaciente()
Buscar Paciente
Si no existe
’Paciente no existe’
Agregar paciente
Agregar afiliado
Buscar Obra Social
Seleccionar Obra Social
Agregar Obra Social
Sino
’Paciente existente’
Afiliado
Afiliar(idPaciente)
Obra Social
idObraSocial ObtenerObraSocial()
Consultorio
Conjunto ObraSocial BuscarObraSocial(cadena)
3
El recuadro de ’Usuario’ representa al grupo de usuario Administración.
16

3.3 Diagramas de interacción 3 MODELIZACIÓN DEL SISTEMA
3.3.5. Escenario: agregar paciente a la lista de espera
Secretaria Pacientes
Buscar Paciente
Si existe
Seleccionar paciente
Agregar paciente
Sino
’Paciente NO existente’
ColaPacientes
enColar(idPaciente)
3.3.6. Escenario: atención del paciente de la lista de espera
Medico
Obtener paciente
Obtener afiliado
Nueva atencion
AtencionColaPacientes
idPaciente deCola()
Afiliado
idAfiliado ObtenerAfiliado(idPaciente)
AgregarAtencion(idAfiliado)
3.3.7. Escenario: facturación del mes
Medico
Obtener facturacion
del mes
Nuevas entradas
Facturacion
ObtenerFacturacion(fecha)
LineaFacturacion
AgregarLineaFacturacion()
3.3.8. Escenario: nueva obra social
Usuario Consultorio
AgregarObraSocial()
Buscar Obra Social
Si no existe
Crear Obra Social
Sino
’La Obra Social ya existe’
3.3.9. Escenario: nueva historia clínica
Medico
Nueva historia clinica
HistoriaClinica
AgregarHistoriaClinica(idPaciente)
17

3.4 Fichas CRC 3 MODELIZACIÓN DEL SISTEMA
3.4. Fichas CRC
Fichas CRC del sistema Consultorio Médico.
3.4.1. Clase Consultorio
Atributos Operaciones
Agregar_Persona(tipo_persona)
ModificarPersona(idPersona)
EliminarPersona(idPersona)
AgregarObraSocial()
ModificarObraSocial(idObraSocial)
EliminarObraSocial(idObraSocial)
3.4.2. Clase Personas
Usuario: cadena
Contraseña: cadena
Tipo: cadena
Apellido: cadena
Nombre: cadena
Dirección: cadena
Teléfono: cadena
E-Mail: cadena
3.4.3. Clase Médicos
Especialidad: cadena entero DeCola()
Nro_Consultorio: entero entero ObtenerAfiliado(idPaciente)
AgregarAtencion(idAfiliado)
AgregarHistoriaClinica(idPaciente)
ModificarHistoriaClinica(idPaciente)
EliminarHistoriaClinica(idPaciente)
ImprimirFacturacion(fecha, idObraSocial)
AgregarFacturacion(fecha)
18

3.4 Fichas CRC 3 MODELIZACIÓN DEL SISTEMA
3.4.4. Clase Secretaria
Turno: cadena AgregarPaciente()
Sueldo: moneda ModificarPaciente(idPaciente)
Extras: moneda EliminarPaciente(idPaciente)
EnCola(idPaciente)
EliminarDeCola(idPaciente)
3.4.5. Clase Atención
Fecha: fecha NuevaLineaAtencion()
ModificarLineaAtencion(idLineaAtencion)
EliminarLineaAtencion(idLineaAtencion)
3.4.6. Clase LíneaAtención
Nro_Orden: cadena
MotivoConsulta: cadena
Resetario: cadena
3.4.7. Clase Facturación
Fecha: fecha AgregarLineaFacturacion(fecha)
ModificarLineaFacturacion(idLineaFacturacion)
EliminarLineaFacturacion(idLineaFacturacion)
ImprimirFacturacion(fecha)
ImprimirFacturacionPorObraSocial(fecha,idObraSocial)
VerFacturacionTotal(fecha)
19

4 IDENTIFICACIÓN DE ROLES
3.4.8. Clase LíneaFacturación
Nro_Orden: cadena
Via: cadena
Precio: moneda
3.4.9. Clase HistoriaClínica
Fecha: fecha
Motivo: cadena
Historial: cadena
3.4.10. Clase Pacientes
Edad: entero Afiliar()
Sexo: caracter EliminarAfiliado()
VerObraSocial()
3.4.11. Clase ObraSocial
Nombre: cadena
Codigo: entero
Gerenciadora: cadena
4. Identificación de roles
En esta etapa se pretende identificar los roles que cumplen los usuarios finales en el sistema, tenien-
do en cuenta las funciones que realizan y describiendo las restricciones a los datos de cada uno.
4.1. Rol Médico
Funciones que realiza
Ingresar historia clínica de un paciente.
Nueva atención de paciente (en el cual se ingresa el motivo de consulta).
Agrega nueva orden a la facturación del mes.
20

4.2 Rol Secretaria 5 GUIONES Y ESCENARIOS
Restricciones de datos
No se han definido.
4.2. Rol Secretaria
Ingresa, modifica o elimina pacientes.
Agrega a la cola de espera a un paciente.
Afilia un paciente con una Obra Social.
Agregar, modificar o eliminar Obras Sociales.
4.3. Rol Administración
Ingresa, modifica o elimina usuarios del sistema.
Ingresa, modifica o elimina Obras Sociales.
No se han definido.
5. Guiones y Escenarios
En esta sección se grafican los diagramas de transición de escenarios, las tablas de transición de
escenario y así también cada una de las ventanas de la interfaz de usuario.4
4
Para simplificar los diagramas siguientes se utilizará la denominación US-xx-xx, sin hacer distinción a los usuarios
Médicos, Secretaria o Administración.
21

5.1 Diagramas de Transición de Escenarios 5 GUIONES Y ESCENARIOS
5.1. Diagramas de Transición de Escenarios
22

5.2 Tablas de Transición de Escenarios 5 GUIONES Y ESCENARIOS
5.2. Tablas de Transición de Escenarios
US-00-00 US-01-00 US-02-00 US-03-00 US-04-00 US-05-00 US-06-00 US-07-00 U
US-00-00 - US-00-09 US-00-09 US-00-09
US-01-00 US-01-04 - US-01-05 US-00-07
US-02-00 US-02-26 -
US-03-00 US-03-06 - US-03-04
US-04-00 US-00-03 -
US-05-00 - US-05-06
US-06-00 US-06-26 -
US-07-00 US-07-15 - U
US-08-00 US-08-16
US-09-00 US-09-08 U
5.3. Escenario US-00-00
Este escenario es la primera ventana que aparece cuando se ejecuta el programa, en el cual indica
que se ingrese nombre de usuario (02), contraseña (05) y grupo de trabajo (07) para realizar la cone-
xión con la base de datos y permitir o impedir el acceso a la misma si el proceso es verdadero o falso
respectivamente. Para salir del programa sin ingresar al sistema se creó el objeto 08.
Si el grupo de trabajo elegido en US-00-07 corresponde a ’Administrador’, y el inicio de sesión
fue validado correctamente por el sistema, se activa US-01-00, donde permite al administrador del
sistema buscar usuarios mediante 02, visualizar los usuarios encontrados en 03, y ﬁnalmente realizar
operaciones sobre ellos. También está la posibilidad de ingresar nuevos usuarios mediante el objeto
05. Para salir de esta ventana (y del sistema) se utiliza el objeto 04.
23

5.5 Escenario US-02-00 5 GUIONES Y ESCENARIOS
Si se presiona US-01-05 o US-01-06 se activa este escenario que permite la modiﬁcación de un
usuario existente o el ingreso de un nuevo usuario del sistema. Para deshacer toda operación sobre
este escenario se utiliza el objeto 26.
Si en US-00-00 se selecciona como grupo de trabajo a ’Médico’ y el inicio de sesión fue autorizado
por el sistema, entonces es visualizado este escenario que es el principal para el usuario médico. En
el objeto 03 se listan todos los pacientes fueron ya antes ingresado por US-00-00 y se encuentran en
24

la cola de espera para su atención. Con el objeto 04 se elimina de la cola para su atención corres-
pondiente. En cambio con el objeto 05 se elimina el elemento de la cola pero sin realizar la atención
médica esperada. Con los objetos de escenarios 09, 10, 11 se trabaja sobre la facturación del mes antes
ingresado en 08.
Este escenario se activa cuando se quiere realizar una operación que requiera de una advertencia
antes de continuar el proceso. En este caso al presionar US-00-04 o US-00-08 se preguntará si se
quiere eliminar los registros. Para continuar se utiliza el objeto de escenario 04, sino 03.
Si de US-00-00 en el cuadro de lista se ingresa la opción ’Secretaria’, se activará este escenario que
es el utilizado por la persona quien recibe el primero contacto con el cliente. El objeto de escenario
05 muestra una lista de pacientes encontrados mediante una búsqueda de palabras claves tipeadas en
03. Las operaciones que se pueden realizar sobre esta lista de pacientes estan dadas por 06, 07 y 08.
Luego, para que un paciente reciba atención médica se lo coloca en la cola de espera mediante previo
ingreso del número de orden en el objeto 10, mientras que 11 esté activado, sino se deja en blanco a
10.
25

Si se presiona US-00-06 o US-00-07 se activa este escenario, en donde se pueden modiﬁcar datos
de un paciente existente o agregar un nuevo registro. Para guardar los cambios se utiliza el objeto 27,
mientras que para cancelar todo el proceso se utiliza 26.
Si se activa US-00-04 entonces se muestra este escenario, en el cual se visualiza la atención de un
paciente ordenado en 05 por fecha de atención mediante 09 y con su respectivo motivo de consulta
26

(11). El objeto de escenario 06 contiene los mismo datos que los ingresados en US-01-00. El objeto
14 lleva a otro escenario que permite realizar la facturación del paciente en cuestión.
Este escenario se activa cuando se presiona en US-01-14, pasando como parámetro el nombre del
paciente que está siendo atendido y su respectiva obra social. Como a veces un paciente llega con la
orden de un familiar u otra persona, entonces se utiliza el objeto 05 que es el nombre de la persona
que se le va a facturar la orden. Con el objeto 17 se cargan los datos en facturación y con 16 cancela
todo el proceso y se vuelve a US-01-00.
27

5.12 Escenario US-09-00 6 ARQUITECTURA FÍSICA DEL SISTEMA
Este escenario se visualiza cuando se presiona en US-00-09, en donde se quiere modificar alguna
línea de facturación previamente ingresada en la atención médica. En el objeto de escenario 03 se
ingresa el mes y año de la prestación y es mostrada la lista de facturación en 06. Si se presiona
sobre 07, se activa US-02-00 en donde es posible realizar la modificación de la línea de facturación
seleccionada.
Parte III.
Especificación D
En la Especificación D del sistema se llevan a cabo la descripción sobre la arquitectura física del
sistema, fichas técnicas y el diseño de la estructura de datos.
6. Arquitectura física del sistema
La arquitectura del sistema será de Cliente/Servidor, en el cual el sistema gestor de base de datos
se encontrará en el Servidor y la aplicación de usuario en el Cliente.
Todos los datos recidirán en el servidor, de manera que la aplicación cliente debe ser verificada
por el sistema gestor de base de datos mediante el nombre de usuario y contraseña ingresada por los
usuarios. No pueden quedar datos o información del sistema en las máquinas clientes.
Este modelo tiene la ventaja de permitir trabajar a varios usuarios simultáneamente tanto en canti-
dad de médicos como en cantidad de secretarias, de manera que la información sea obtenida al instante
por todos los usuarios del sistema5.
5
Esto es siempre y cuando el usuario cumpla con los privilegios suficientes para tales operaciones.
28

7 FICHAS TÉCNICAS DE MÉTODOS DE OBJETOS
Por otro lado se debe tener en cuenta que los eventos sobre los objetos de entorno responden a los
estándares del Sistema Operativo y disparan procedimientos que son de carácter local a la ventana
donde se producen. La ventana pasa el control al procedimiento correspondiente al producirse el
evento que, una vez concluido, devuelve el control a la ventana.
7. Fichas técnicas de Métodos de Objetos
7.1. Clase Secretaria
Método: AgregarPaciente()
Conectar a la base de datos
Obtener siguiente idPaciente
Si se ingresaron todos los campos correspondientes a pacientes
Insertar los datos con el idPaciente obtenido en la base de datos
Sino
Mostrar mensaje de error
Desconectar de la base de datos
Método: ModiﬁcarPaciente()
id="idPaciente"
Si id = idPaciente de la base de datos
Modificar los datos
Sino
Mostrar mensaje de error de paciente no encontrado
Método: EliminarPaciente()
id="idPaciente"
Si id = idPaciente de la base de datos
Eliminar registro de la base de datos
Sino
Mostrar mensaje de error de paciente no encontrado
29

7.2 Clase Facturación 7 FICHAS TÉCNICAS DE MÉTODOS DE OBJETOS
Método: Conjunto Paciente BuscarPaciente(cadena)
c = "cadena"
Comparar c con los campos ’Apellido’,’Nombre’ de la base de datos
Mostrar listado de registros encontrados (si no encuentra, mostrar vacío)
Método: enColar(idPaciente)
Agregar idPaciente a ColaPacientes
Método: deCola(fecha)
Quitar el primer elemento de ColaPacientes que corresponda a
la fecha actual
7.2. Clase Facturación
Método: AgregarLineaFacturacion(fecha)
Obtener siguiente idLineaFacturacion
Ingresar idPaciente, idObraSocial, Nro_Orden y Vía
Si No hay error
Crear nuevo registro con los valores anteriores en
el idLineaFacturacion obtenido
Sino
Método: ModiﬁcarLineaFacturacion(idLineaFacturacion)
id="idLineaFacturacion"
Si id = idLineaFacturacion de la base de datos
Mostrar formulario para realizar la modificacion
Sino
Mostrar mensaje de que no existe la linea de facturacion
30

7.2 Clase Facturación 7 FICHAS TÉCNICAS DE MÉTODOS DE OBJETOS
Método: EliminarLineaFacturacion(idLineaFacturacion)
id="idLineaFacturacion"
Si id = idLineaFacturacion de la base de datos
Eliminar el registro de la base de datos
Sino
Mostrar mensaje de que no existe la linea de facturacion
Método: ImprimirFacturacion(fecha)
fecha = "fecha"
Seleccionar Registros de LineaFacturacion que contengan
la misma fecha
Ordenar los registros por Paciente
Mandar a impresora el listado
Método: ImprimirFacturacionPorObraSocial(fecha,idObraSocial)
fecha = "fecha"
id = "idObraSocial"
Seleccionar los registros que contengan "fecha" e "id"
Mandar a impresora el listado obtenido
Método: VerFacturacionTotal(fecha)
fecha = "fecha"
Seleccionar Registros de LineaFacturacion que contengan
la misma fecha
Ordenar los registros por Paciente
Mostrar el listado en una grilla
31

7.3 Clase LíneaFacturación8 FICHAS TÉCNICAS DE EVENTOS DE OBJETOS DE ESCENARIOS
7.3. Clase LíneaFacturación
Método: Conjunto Paciente BuscarPaciente(cadena)
c = "cadena"
Comparar c con los campos ’Apellido’,’Nombre’ de la base de datos
Método: Conjunto ObraSocial BuscarObraSocial(cadena)
c = "cadena"
Comparar c con el campo ’Nombre.ObraSocial’ de la base de datos
8. Fichas técnicas de eventos de Objetos de Escenarios
8.1. Escenario US-01-00 (Administrador)
US-01-00, Evento: Carga ventana
Establecer US-00-02 como vacío
Establecer US-01-03 como vacío
Habilitar US-01-08
Habilitar US-01-04
Habilitar US-01-05
Deshabilitar US-01-06
Deshabilitar US-01-07
US-01-08, Evento: Click
cadena = US-01-02
Comparar cadena con apellido.Personas, nombre.Personas
Mostrar resultado en US-01-03
Seleccionar lista de Personas
32

8.2 Escenario US-09-00 (Facturación)8 FICHAS TÉCNICAS DE EVENTOS DE OBJETOS DE ESCENARIOS
Habilitar US-01-06
Habilitar US-01-07
Descarga ventana
Vuelve a US-00-00
Carga US-02-00
Obtiene idPersonas de US-01-03 seleccionado
Comparar id
Si existe
Recuperar los datos y abrir US-02-00
Sino
Mensaje de error
Obtiene idPersonas de US-01-03 seleccionado
Comparar id
Si existe
Eliminar registro de la base de datos
Sino
Mensaje de error
8.2. Escenario US-09-00 (Facturación)
US-09-00, Evento: Cargar ventana
Habilitar US-09-03
Deshabilitar US-09-04, 05, 06 y 07
33

9 DISEÑO DE LA ESTRUCTURA DE DATOS
Descargar ventana
Volver a US-03-00
Chequear US-09-03 y obtener valor
Comparar US-09-03 con fecha.LineaFacturacion
Mostrar resultado en US-09-06
Deconectar de la base de datos
Chequear US-09-03 y obtener valor
Comparar US-09-03 con fecha.LineaFacturacion
Enviar resultado a impresora
Deconectar de la base de datos
US-09-06, Evento: Seleccionar
Habilitar US-09-07
Obtener idLineaFacturacion
Conectar con la base de datos
Comparar idLineaFacturacion
Si existe
Obtener registros
Abrir US-08-00
Sino
9. Diseño de la estructura de datos
9.1. Modelo lógico
Se elige como modelo lógico el modelo relacional.
34

9.1 Modelo lógico 9 DISEÑO DE LA ESTRUCTURA DE DATOS
35

9.2 Modelo físico 9 DISEÑO DE LA ESTRUCTURA DE DATOS
9.2. Modelo físico
En esta subsección se deﬁne la estructura física de los datos utilizados en el sistema. Este esquema
contempla las maneras de acceder físicamente a los datos, por medio de claves, índices, etc., para
cumplir con todos los requisitos.
En esta fase se modiﬁcará el diseño lógico de datos, para convertirlo en un modelo físico, que
contemple todos los aspectos de funcionalidad y rendimiento.
Tabla Médicos
Columna Tipo de datos Permitir nulo
idSecretaria entero no
Apellido cadena no
Nombre cadena no
Dirección cadena si
Teléfono cadena si
Ciudad cadena si
eMail cadena si
Turno cadena si
Tabla Atenciones
idAtencion entero no
idMedico entero no
idPaciente entero no
Fecha fecha no
Tipo cadena si
Motivo cadena si
Atendido bool no
Tabla Facturación
idFacturacion entero no
idMedico entero no
Fecha fecha no
36

Tabla HistoriaClínica
idHistoriaClinica entero no
idMedico entero no
Fecha fecha si
Historial texto si
Tabla LíneaFacturación
idLineaFacturacion entero no
idFacturacion entero no
idMedico entero no
idAﬁliado entero no
idObraSocial entero no
Nro_Orden cadena no
Via cadena si
Tabla Secretarias
idSecretarias entero no
Apellido cadena no
Nombre cadena no
Teléfono cadena si
Ciudad cadena si
eMail cadena si
Especialidad cadena si
Tabla ObraSocial
Nombre cadena no
Codigo cadena si
Direccion cadena si
Telefono cadena si
37

Tabla Aﬁliados
idAﬁliado entero no
Tabla Pacientes
idPacientes entero no
Apellido cadena no
Nombre cadena no
Teléfono cadena si
Ciudad cadena si
eMail cadena si
Edad cadena si
Para acelerar las búsquedas dentro del sistema gestor de base de datos se crean los siguientes índi-
ces:
Un índice sin duplicados por cada tabla de las claves primarias.
Un índice sin duplicados por cada tabla de las claves foráneas.
Un índice de la columna Nombre de la tabla ObraSocial.
Un índice de las columnas Apellido, Nombre de las tablas Médicos, Secretarias, Pacientes.
38

Consultorio Médico

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (9)

Similar a Consultorio Médico

Similar a Consultorio Médico (20)

Más de Gustavo Cortez

Más de Gustavo Cortez (7)

Consultorio Médico