Casos de Uso documentados PDF

Preview

Summary

Download Casos de Uso documentados PDF

Description

Casos de uso RIS-INR

1 Gestionar Equipos Añadir Equipo Nombre de Caso de Uso

1.1 Añadir Equipo

Actor participante

SIAEM Ingeniero Biomédico

Precondición

Usuario dado de alta en el Sistema Vista acorde a usuario Conexión con base de datos

Flujo de eventos

1.- RIS consulta a SIAEM equipo a registrar. 2.- RIS verifica si el equipo ya se ha registrado antes. 3.-Registrar equipo

Flujo alterno

3a. Si equipo ya se ha registrado 3a 1. RIS despliega mensaje de equipo ya existente .

Postcondición

Equipo registrado en el Sistema. Todas las transacciones o errores deben registrarse en un archivo log.

Actualizar información de Equipo Nombre de caso de uso

1.2. Actualizar información de equipo.

Actor participante

Ingeniero Biomédico Jefe de Servicio

Precondición

Usuario dado de alta en el sistema Vista acorde al usuario Conexión con base de datos Equipo registrado en RIS.

Flujo de eventos

1.- RIS consulta equipos registrados. 2.- Usuario selecciona equipo a modificar. 3.- RIS despliega formulario con información del equipo. 4.- Usuario registra modificaciones. 5.- RIS solicita confirmación para actualizar.

6.- Usuario confirma cambios realizados. 7.- RIS registra cambios en equipo. Flujo alterno

6a. Si el Usuario decide cancelar la operación. 6a 1.- Usuario selecciona cancelar actualización. 6a 2.- RIS despliega mensaje de operación cancelada.

Postcondición

Equipo modificado y guardado en base de datos. Todas las transacciones o errores deben registrarse en un archivo log.

Consultar Equipo Nombre de caso de uso

1.3. Consultar equipo

Actor participante

Administrador del sistema. Jefe de servicio.

Precondición

Usuario dado de alta en el sistema. Vista acorde al usuario. Conexión a base de datos. Equipo registrado en RIS.

Flujo de eventos

1.- Usuario introduce filtros de búsqueda a realizar. 2.- RIS realiza búsqueda de acuerdo a los filtros definidos. 3.- RIS despliega resultados de la búsqueda.

Flujo alterno

3a.- RIS no encuentra la búsqueda solicitada. 3a.1.- RIS despliega mensaje busqueda sin resultados. 3a.2.- RIS da la opción de reintentar búsqueda. 3a.3.- Usuario reintenta, regresa al punto 1.

Postcondición

Resultados acorde a la necesidad del usuario. Todas las transacciones o errores deben registrarse en un archivo log.

2 Gestionar Citas Agendar Estudio Nombre del caso de uso

CU 2.1 Agendar Estudio

Actores participantes

Recepcionista, Médico Radiólogo y SAIH

Precondición

Solicitud de estudios elaborada.

Fecha de próxima cita médica agendada. Interoperabilidad con el SAIH.

Postcondición

Cita de estudios generada y guardada en bases de datos. Estado de solicitud de estudios actualizado. Todas las transacciones o errores deben registrarse en un archivo log.

Flujo de eventos

1.- RIS recibe orden para agendar una solicitud de estudios. 2.- Usuario ingresa número de registro del paciente. 3.- RIS despliega orden de estudios del paciente. 4.- RIS solicita seleccionar equipo. 5.- Usuario selecciona fecha y hora de cita. 6.- RIS guarda cita en base de datos 7.- RIS actualiza estado de solicitud de estudios a “Agendado”.

Flujos alternos

5a. Si el usuario no selecciona fecha y hora de cita. 5a 1.- Usuario selecciona regresar El flujo regresa al punto 3.

Reagendar Estudio Nombre del caso de uso

CU 2.2 Reagendar Estudio

Actores participantes

Recepcionista, Médico Radiólogo y SAIH

Precondición

Solicitud de estudios agendada. Conexión a base de datos. Vista de acuerdo al usuario.

Postcondición

Estado de solicitud de estudios actualizado. Todas las transacciones o errores deben registrarse en un archivo log.

Flujo de eventos

1.- RIS recibe orden para reagendar una solicitud de estudios. 2.- Usuario ingresa número de registro del paciente. 3.- RIS consulta solicitudes de estudios agendadas. 4.- Usuario selecciona cita agendada. 5.- RIS actualiza estado de solicitud de estudios a “Solicitado”. 6.- RIS solicita seleccionar equipo. 7.- Usuario selecciona fecha y hora de cita. 8.- RIS guarda cita en base de datos 9.- RIS actualiza estado de solicitud de estudios a “Reagendado”.

Flujos alternos

7a. Si el usuario no selecciona fecha y hora de cita. 7a 1.- Usuario selecciona regresar El flujo regresa al punto 6.

CU 2.3 Consultar Citas de Estudios Nombre del caso de uso

CU 2.3 Consultar Citas de Estudios

Actores participantes

Jefe de Servicio, Médico Radiólogo y Recepcionista.

Precondición

Conexión a base de datos. Vista de acuerdo al usuario.

Postcondición

Todas las transacciones o errores deben registrarse en un archivo log.

Flujo de eventos

1.- Usuario solicita búsqueda. 2.-RIS realiza búsqueda de acuerdo a los filtros definidos. 3.-RIS despliega resultados de la búsqueda.

Flujos alternos

3a. RIS no encuentra la búsqueda solicitada. 3a.1. RIS despliega mensaje de búsqueda sin resultados. 3a.2. RIS da la opcion de reintentar búsqueda. 3b.3. Usuario acepta reintentar, regresa al punto 1

3 Gestionar Listas de Trabajo Añadir Estudio a Lista de Trabajo Automático Nombre del caso de uso

CU 3.1 Agregar automática de estudios

Actor participante

Jefe de Servicio, Coordinador de Servicio y Temporizador.

Precondición

Conexión a base de datos establecida. Timmer activo el caso de uso. Solicitudes de estudio agendadas Timmer por servicio.

Postcondición

Se añaden estudios del día a lista de trabajo. Todas las transacciones o errores deben registrarse en un archivo log.

Flujo de eventos 1

1.- Cuando la modalidad no es de Rayos X. 2.- Sistema consulta la disponibilidad de los equipos. 3.- Sistema consulta las solicitudes agendadas para el dia. 4.- Sistema reparte equitativamente las solicitudes de estudio en listas de trabajo de equipos. 5.- Sistema envía a jefe de servicio un mensaje de que las listas fueron creadas con éxito.

Flujo alterno de flujos de eventos 1

2a.- Cuando no hay equipos disponibles. 2a.1.- Sistema notifica a jefe de servicio que no se pudieron crear las listas porque no hay equipos disponibles.

Flujo de eventos 2

1.- Cuando la modalidad es de Rayos X de estudio normal o especial.. 2.- Sistema debe consultar los equipos disponibles para estudios especiales y normales. 3.- Sistema consulta las solicitudes de estudio agendadas para estudios especiales y normales para el día. 4.- Sistema reparte las solicitudes de estudio en los equipos disponibles de forma equitativa. 5.- Sistema envía mensaje de éxito a jefe de servicio.

Flujo alterno de flujo de eventos 2

2a.- Cuando no hay equipos disponibles. 2a.1.- Sistema notifica que no se pudieron crear las listas por que no hay equipos disponibles.

Añadir Estudio a Lista de Trabajo Manual Nombre del caso de uso

CU 3.2 Agregación manual de estudios

Actor participante

Jefe de Servicio Médico Especialista

Precondición

Vista definida de acuerdo al usuario. Conexión a base de datos establecida. Solicitud de estudios generada. Usuario debió haber activado el caso de uso.

Postcondición

Todas las transacciones o errores deben registrarse en un archivo log.

Flujo de eventos

1.- Sistema realiza consulta de solicitud de estudios. 2.- Sistema consulta las listas disponibles para agregar el estudio. 3.- Sistema da opción a elegir la lista donde se va a agregar el trabajo 4.- Usuario selecciona la lista. 5.- Sistema le presenta la lista para verificar. 6.- Sistema añade la solicitud a la lista.

7.- Sistema despliega mensaje de éxito. Flujos alternos

6a.- Si el usuario se equivoca de lista 6a.1.- Sistema le da la opción de elegir otra lista, regresandolo al punto 3.

Eliminar estudios de lista de trabajo Nombre de caso de uso

CU 3.3 Eliminar estudios de lista de trabajo

Actor participante

Modalidad, Jefe de Servicio, Coordinador

Precondición

Lista de trabajo con estudios. Vista acorde al usuario. Conexión a base de datos. Estudio Realizado y modalidad notifica al RIS. Jefe de servicio o coordinador disparan el caso de uso.

Postcondición

Estado de la solicitud de estudios actualizada. Todas las transacciones o errores deben registrarse en un archivo log.

Flujo de eventos 1

1.- Sistema actualiza el estatus de la solicitud de estudios. 2.- Sistema quita solicitud realizada de la lista de trabajo.

Flujo de eventos 2

1.- Sistema realiza una consulta de las listas de trabajo. 2.- Usuario selecciona la lista. 3.-Sistema realiza una consulta de estudios de la lista. 4.- Sistema despliega solicitudes de estudio de la lista seleccionada. 5.-Sistema invita a usuario a seleccionar la solicitud a eliminar. 6.- Usuario selecciona la solicitud. 7.-Sistema presenta al usuario la solicitud a eliminar para confirmar. 8.-Sistema quita la solicitud de la lista de trabajo.

Flujo alterno de flujo de eventos 2

7a.- Usuario se equivoca de solicitud de estudios 7a.1.- Sistema le da la opción de volver a elegir otro estudio regresando al punto 5.

Consultar Lista de Trabajo Nombre de caso de uso

CU 3.4. Consultar Lista de trabajo

Actor participante Precondición

La consulta se trabajará con la modalidad que le

corresponda. Postcondición

Todas las transacciones o errores deben registrarse en un archivo log.

Flujo de eventos 1

1.- Sistema despliega lista de trabajo asociada a la modalidad. 2.- Solicita a usuario seleccionar continuar. 3.- Sistema despliega la solicitud de estudios que esta en la cabecera de la lista de trabajo.

Flujo de eventos 2

1.- Sistema realiza consulta de acuerdo al filtro vinculado al usuario. 2.- Despliega los resultados en un formato vinculado al usuario.

Flujo alterno de flujo de eventos 2

1a.- No se encontró la lista de trabajo. 1a.1.- Sistema despliega no se encontro trabajo en la lista. 1b.2.- Sistema despliega no hay trabajo en la lista. Sistema da opción de reintentar, si aceptan vuelven al punto 1, si no, se sale de caso de uso.

4 Gestionar Estudios Agregar estudio Nombre de Caso de Uso

4.1. Registrar Estudio

Actor participante

Jefe de Servicio Administrador del Sistema

Precondición

Usuario dado de alta en el Sistema Vista acorde a usuario Conexión con base de datos

Flujo de eventos

1.- RIS solicita nombre del estudio. 2.- RIS invoca consultar estudio. 3.- RIS despliega formulario para registrar estudio. 4.- Usuario llena campos de la plantilla. 5.- RIS presenta los datos del estudio a agregar. 6.- Usuario verifica datos de estudio. 7.- RIS guarda estudio en la base de datos. 8.- RIS despliega un mensaje de estudio agregado.

Flujo alterno

3 a.- Sistema encuentra el estudio. 3a.1. RIS despliega mensaje estudio registrado. 4a. Campos obligatorios no se llenaron. 4a.1. RIS despliega mensaje llenar campos obligatorios. 4a.2. Regresa a punto 3. 6a. Si los datos presentados están mal. 6a.1. Usuario selecciona cancelar. 6a.2. Regresa al punto 3. 8a. No se guarda en base de datos. 8a.1. RIS despliega mensaje no se pudo guardar en base de datos. 8a.2. RIS da la oportunidad de reintentar. 8a.3. Si usuario reintenta, Regresa al punto 7. 8b.3. Si usuario no reintenta sale del caso de uso .

Postcondición

Estudio registrado en el Sistema. Todas las transacciones o errores deben registrarse en un archivo log.

Editar estudio Nombre del Caso de Uso

4.2. Editar Estudio

Actor participante

Jefe de Servicio

Precondición

Usuario dado de alta en el sistema. Verificar conexión con base de datos. Vista acorde al usuario.

Flujo de eventos

1.- RIS solicita datos para búsqueda. 2.- RIS invoca consultar estudio. 3.- RIS solicita a usuario llenar los campos de estudio a editar. 4.- Usuario llena los campos del estudio a editar. 5.- RIS presenta los datos del estudio a editar. 6.- Usuario verifica datos. 7.- RIS guarda estudio en la base de datos. 8.- Desplegar mensaje estudio editado.

Flujo alterno

3 a.- Sistema encuentra el estudio. 3a.1. RIS despliega mensaje estudio registrado. 3a.2. Si usuario reintenta, vuelve al punto 1. 3b.1. Si usuario no reintenta, sale de caso de uso. 4a. Campos obligatorios no se llenaron. 4a.1. RIS despliega mensaje llenar campos obligatorios. 4a.2. Regresa a punto 3. 6a. Si los datos presentados están mal. 6a.1. Usuario selecciona cancelar. 6a.2. Regresa al punto 3. 8a. No se guarda en base de datos. 8a.1. RIS despliega mensaje no se pudo guardar en base de datos. 8a.2. RIS da la oportunidad de reintentar. 8a.3. Si usuario reintenta, Regresa al punto 7. 8b.3. Si usuario no reintenta sale del caso de uso.

Postcondición

Estudio registrado en el sistema. Todas las transacciones o errores deben registrarse en un archivo log.

Consultar estudio Nombre de Caso de Uso

Consultar Estudio

Actor participante

Médico Especialista Jefe de Servicio Administrador del sistema

Precondición

Usuario dado de alta en el sistema. Vista acorde al usuario. Conexión con base de datos.

Flujo de eventos

1.- Usuario solicita búsqueda. 2.-RIS realiza búsqueda de acuerdo a los filtros definidos. 3.-RIS despliega resultados de la búsqueda.

Flujo alterno

3a. RIS no encuentra la búsqueda solicitada. 3a.1. RIS despliega mensaje de búsqueda sin resultados. 3a.2. RIS da la opcion de reintentar búsqueda. 3b.3. Usuario acepta reintentar, regresa al punto 1.

Postcondición

Resultados acorde a la necesidad del usuario.

Todas las transacciones o errores deben registrarse en un archivo log.

5 Gestionar Protocolos de Estudios Agregar Protocolo Nombre de caso de uso

5.1. Agregar protocolo

Actor participante

Jefe de servicio Administrador del sistema

Precondición

Usuario dado de alta en el sistema Vista acorde al usuario Conexión con base de datos

Flujo de eventos

1.- RIS solicita nombre de protocolo a registrar. 2.- Usuario introduce nombre. 3.- RIS invoca caso de uso consultar protocolo. 4.- RIS solicita llenar campos de protocolo a dar de alta. 5.-Usuario llena campos. 6.-RIS presenta datos de protocolo a dar de alta. 7.- Usuario verifica datos. 8.- Guarda protocolo en la base de datos. 9.- RIS despliega mensaje de protocolo agregado.

Flujo alterno

4a.- RIS encuentra el protocolo. 4a.1.- RIS despliega mensaje de protocolo registrado. 5a.- Campos obligatorios no se llenaron. 5a.1.- RIS despliega mensaje llenar campos obligatorios. 5a.2.- Regresa al punto 4. 7a.- Si los datos presentados están mal. 7a.1.- Usuario selecciona cancelar. 7a.2.- Regresa al punto 4. 9a.- No se guarda en base de datos. 9a.1.- RIS despliega mensaje no se pudo guardar en BD. 9a.2.- RIS da oportunidad de reintentar. 9a.3.- Usuario reintenta, regresa al punto 7. 9b.3.- Usuario no reintenta, sale del caso de uso.

Postcondición

Editar Protocolo

Protocolo registrado en el sistema. Todas las transacciones o errores deben registrarse en un archivo log.

Nombre de caso de uso

5.2. Editar protocolo

Actor participante

Jefe de servicio Administrador del sistema

Precondición

Usuario dado de alta en el sistema Vista acorde al usuario Conexión con base de datos

Flujo de eventos

1.- RIS solicita datos de protocolo para búsqueda. 2.- Usuario introduce datos. 3.- RIS invoca caso de uso consultar protocolo. 4.- RIS solicita editar campos de protocolo. 5.-Usuario edita campos. 6.-RIS presenta datos de protocolo editado. 7.- Usuario verifica datos. 8.- Guarda usuario en la base de datos. 9.- RIS despliega mensaje de protocolo agregado.

Flujo alterno

4a.- RIS no encuentra el protocolo. 4a.1.- RIS despliega mensaje de reintentar. 4a.2.-Usuario reintenta, regresa al punto 1. 5a.- Campos obligatorios no se llenaron. 5a.1.- RIS despliega mensaje llenar campos obligatorios. 5a.2.- Regresa al punto 4. 7a.- Si los datos presentados están mal. 7a.1.- Usuario selecciona cancelar. 7a.2.- Regresa al punto 4. 9a.- No se guarda en base de datos. 9a.1.- RIS despliega mensaje no se pudo guardar en BD. 9a.2.- RIS da oportunidad de reintentar. 9a.3.- Usuario reintenta, regresa al punto 7. 9b.3.- Usuario no reintenta, sale del caso de uso.

Postcondición

Protocolo registrado en el sistema. Todas las transacciones o errores deben registrarse en un archivo log.

Consultar protocolo Nombre de caso de uso

5.3. Consultar protocolo

Actor participante

Administrador del sistema Jefe de servicio Director de servicios auxiliares de diagnóstico.

Precondición

Usuario dado de alta en el sistema. Vista acorde al usuario. Conexión a base de datos.

Flujo de eventos

1.- Usuario introduce filtros de búsqueda a realizar. 2.- RIS realiza búsqueda de acuerdo a los filtros definidos. 3.- RIS despliega resultados de la búsqueda.

Flujo alterno

3a.- RIS no encuentra la búsqueda solicitada. 3a.1.- RIS despliega mensaje busqueda sin resultados. 3a.2.- RIS da la opción de reintentar busqueda. 3a.3.- Usuario reintenta, regresa al punto 1.

Postcondición

Resultados acorde a la necesidad del usuario. Todas las transacciones o errores deben registrarse en un archivo log.

6 Gestionar Solicitudes de Estudios Generar solicitud de estudios Nombre de caso de uso

6.1. Generar solicitud de estudios.

Actor participante

SAIH Médico especialista

Precondición

Usuario dado de alta en el sistema Vista acorde al usuario Conexión con base de datos

Flujo de eventos

1.- RIS solicita el número de registro de paciente. 2.- Usuario introduce numero. 3.- RIS despliega interfaz de solicitud para llenar. 4.- RIS solicita llenar campos de usuario a dar de alta. 5.-Usuario llena campos. 6.-RIS presenta datos de usuario a dar de alta. 7.- Usuario verifica datos. 8.- Guarda usuario en la base de datos. 9.- RIS despliega mensaje de usuario agregado.

Flujo alterno

5a.- Campos obligatorios no se llenaron. 5a.1.- RIS despliega mensaje llenar campos obligatorios. 5a.2.- Regresa al punto 4. 7a.- Si los datos presentados están mal. 7a.1.- Usuario selecciona cancelar. 7a.2.- Regresa al punto 4. 9a.- No se guarda en base de datos.

9a.1.- RIS despliega mensaje no se pudo guardar en BD. 9a.2.- RIS da oportunidad de reintentar. 9a.3.- Usuario reintenta, regresa al punto 7. 9b.3.- Usuario no reintenta, sale del caso de uso. Postcondición

Solicitud de estudios generada. Todas las transacciones o errores deben registrarse en un archivo log.