Especificació n de

requisitos de software
Proyecto: Automatización de Fichas Clínicas
Unidad de Urgencia Servicio de Salud DUOC UC
(AFCU)
Revisión: [2.0]
[23/05/2019]

Especificación de Requisitos según estándar de IEEE 830.

Integrantes: Asignatura: Diseño y Gestión de Requisitos

 Pedro Arrate Sección: DRY1101
 Christian Torrejón Docente: Juan Gana Reyes
 Rodrigo Zuloaga Fecha de Entrega: 23 de mayo de 2019
 Américo Morales
 Alistair García
 Especificación de Requisitos, estándar de IEEE 830

Contenido

1. Introducción 4
1.1. Propósito 4
1.2. Ámbito del Sistema 5
1.3. Definiciones, Acrónimos y Abreviaturas 5
1.4. Referencias 6
1.5. Visión General del Documento 6
2. Descripción General 7
2.1. Perspectiva del Producto 7
2.2. Funciones del Producto 7
2.3. Características de los Usuarios 7
2.4. Restricciones 8
2.5. Suposiciones y Dependencias 9
2.6. Requisitos Futuros 9
3. Requisitos Específicos 10
3.1. Requisitos comunes de las interfaces 10
3.1.1. Interfaces de usuario 10
3.1.2. Interfaces de hardware 12
3.1.3. Interfaces de software 12
3.1.4. Interfaces de comunicación 12
3.2. Requisitos funcionales 12
3.3. Requisitos no funcionales 13
3.4. Otros Requisitos 13
4. Apéndices 14
4.1. –Diagrama Sistema AFCU 14
4.2. Acta de Reunión Kick-Off 15
4.3. Acta de Constitución de Proyecto 15
4.4. Planilla de Requerimientos 15
4.5. Casos de Uso 15

2
 Especificación de Requisitos, estándar de IEEE 830

CASOS DE USO.pptx 15
4.6. Fichas Técnicas 16

3
 Especificación de Requisitos, estándar de IEEE 830

1. Introducción

El registro de datos de un paciente es una fase fundamental en el proceso de atención de

urgencia. A pesar de contar en la actualidad con mucha tecnología, existen servicios de urgencia
en donde este proceso se realiza manualmente.

En este tipo de unidades, son los pacientes los responsables de llenar en forma manual
una mal denominada “Ficha Clínica de Urgencia”; el nombre correcto es “Dato de Atención de
Urgencia” o DAU, recordemos que una ficha es un documento que registra todas las atenciones
que ha recibido un paciente; en lo que se refiere a los datos personales, y un funcionario
administrativo completa el registro realizando preguntas técnicas sobre el porqué solicita ser
atendido de urgencia. Este proceso mixto (paciente-administrativo), genera demora en la atención
y puede ocasionar duplicidad de información (doble registro). También existe la problemática de
no contar con un “Registro Histórico de Pacientes” (Ficha Clínica), al cual accedieran el o los
médicos para ver atenciones previas, tratamientos, exámenes solicitados, medicamentos
recetados, etc., es decir, no tienen acceso a datos previos de los pacientes los cuales son de vital
importancia para un correcto diagnóstico y tratamiento.

Es por lo anteriormente expuesto que el Servicio de Salud DUOC UC, nos ha contactado
para solicitarnos un Proyecto de “Modernización de Registro de Fichas Clínicas” en su unidad de
Urgencia, para que, mediante el uso de la tecnología, se mejoren los procesos involucrados en la
correcta atención y tratamiento del paciente.

1.1.Propósito

Entregar a nuestro cliente, el Servicio de Salud DUOC UC, un proyecto de “Automatización

de Fichas Clínicas” para su unidad de Urgencia, el cual aborde la problemática de contar en la
actualidad con un proceso arcaico para la captura de información de pacientes, como también
generar un “Registro Histórico de Atenciones” al cual puedan acceder todos los interesados, ya
sean médicos o administrativos, para el desarrollo correcto de sus respectivos procesos, esto
siempre resguardando la información sensible procediendo según la Ley de Protección de Datos
Personales de Chile (Ley 19628, Derecho a la Privacidad, promulgada en agosto de 1999). Otro
punto a considerar es contar con un enlace a Farmacia para gestionar correctamente el despacho
de recetas.

4
 Especificación de Requisitos, estándar de IEEE 830

1.2.Ámbito del Sistema

 Nombre del Sistema: “Automatización de Fichas Clínicas de Urgencia” o AFCU

 Definición de propósito del sistema y acciones a cumplir:

a) Propósito: “Modernizar el Registro de Pacientes mediante un sistema informático”

b) Acciones a Cumplir:
o Administración de Usuarios y Contraseñas.
o Diferencias niveles de acceso.
o DAU a cargo de personal administrativo (captura de datos).
o Enlace con BD de Farmacia.
o Administrar Recetas de Medicamentos.
o Generar RHP.
o Gestión de Informes y Reportes.
o Enlace a PREVIRED o FONASA.

 Los principales beneficiados por AFCU son la Unidad de Urgencia del Servicio de Salud
DUOC UC y los Pacientes. El objetivo principal es la Modernización del ingreso de fichas
clínicas de la unidad de urgencia, para con ello, disminuir los tiempos de espera. La meta
de AFCU es establecerse como un sistema integral de gestión de pacientes el cual se
pueda replicar en distintas unidades de atención de pacientes del Servicio de Salud DUOC
UC.

1.3.Definiciones, Acrónimos y Abreviaturas

 AFCU – Automatización de Fichas Clínicas de Urgencia.

 DAU – Dato de Atención de Urgencia.
 BD – Base de Datos.
 BDA – Administrador de Bases de Datos.
 RHP – Registro Histórico de Pacientes.
 FONASA – Fondo Nacional de Salud.
 SIDRA – Sistema Integral de Registro de Atenciones.
 SSMS – Servicio de Salud Metropolitano Sur.
 PNM – Profesional No Médico.
 TENS – Técnico en Enfermería de Nivel Superior.
 QF – Químico Farmacéutico.
 PPA – Personal Profesional Administrativo.
 TI – Tecnología Informática.
 OIRS – Oficina de Informaciones, Reclamos y Sugerencias.
 RAM – Memoria de Acceso Aleatorio.

5
 Especificación de Requisitos, estándar de IEEE 830

 GB – Gigabyte.
 REM – Resumen Estadístico Mensual.
 A08 – Sección de REM correspondiente a Estadísticas de Atenciones de Urgencia.
 SQL – Por sus siglas en inglés Structured Query Language; en español Lenguaje de Consulta
Estructurada.
 PDF – Por sus siglas del inglés Portable Document Format, en español Formato de
Documento Portátil.

1.4.Referencias

 Derecho a la Privacidad, Ley N° 19628, https://www.leychile.cl/Navegar?idNorma=141599

 Copago Ley de Urgencia, http://www.supersalud.gob.cl/difusion/665/w3-printer-
14577.html
 Funciones de un BDA, https://prezi.com/yabsrdqiwowy/principales-funciones-del-
administrador-de-base-de-datos/
 Alegsa.com.ar (2015). Definición de Windows 8 - ALEGSA © 2015-07-29
http://www.alegsa.com.ar/Dic/windows 8.php

1.5.Visión General del Documento

Este documento se encuentra dividido en 4 secciones:

 Sección 1 – Introducción
o Se enfoca en la descripción del documento, objetivos y metas.

 Sección 2 – Descripción General

o Como su nombre lo indica, se enfoca en la descripción del sistema, en donde la
información está orientada al cliente.

 Sección 3 – Requerimientos Específicos

o Se enfoca principalmente en los Requerimientos Específicos del Sistema. Se
emplean términos técnicos orientados principalmente a Desarrolladores y
Programadores.

 Sección 4 – Apéndices
o Contiene enlaces directos a documentos importantes del proyecto.


6
 Especificación de Requisitos, estándar de IEEE 830

2. Descripción General

Existen agentes que afectan el desarrollo de nuestro proyecto y sus requerimientos. En

esta sección se identifican estos agentes, como también, el contexto del desarrollo del sistema.
Algunos de estos agentes son los costos, el tiempo, etc.

2.1.Perspectiva del Producto

Semejante al Sistema Integral de Registro de Atenciones (SIDRA), utilizado por el SSMS, el

producto final permite la captura de información de pacientes de manera óptima, concentrando la
responsabilidad de esta en el funcionario administrativo designado para ello, generando un DAU,
el cual será el documento de enlace entre el paciente y los profesionales del Servicio de Urgencia
DUOC UC, ofrece un enlace a los sistemas de Farmacia y otros centros de interés, con la finalidad
de mejorar la atención de pacientes. También cuenta con la administración de información
enfocada a diversos aspectos estadísticos, necesarios y obligatorios, según los requerimientos del
MINSAL, siempre cuidando la integridad y privacidad de los datos, según la ley 19628.

2.2.Funciones del Producto

 Administración de Usuarios y Contraseñas.

 Administración de Niveles de Usuarios.
 Captura de Datos del Paciente – DAU.
 Gestión de Despacho de Recetas.
 Gestión de RHP.
 Gestión de Informes y Reportes según niveles de usuario.
 Administración de Información en consecuencia a Ley 19628.

2.3.Características de los Usuarios

El sistema cuenta con 6 niveles de usuarios:

 El primer nivel esta conformado por personal administrativo, tiene a cargo la captura de
información inicial del DAU, deben tener conocimientos básicos de computación. Este se
denomina “Nivel Administrativo”.
 El segundo nivel esta conformado por personal profesional de la salud no médico, es decir,
Enfermeros, Matronas, Kinesiólogos, etc., quienes tienen a cargo los chequeos pre y post

7
 Especificación de Requisitos, estándar de IEEE 830

médicos y administración de tratamientos, deben tener conocimientos básicos de

computación. Este se denomina “Nivel PNM”.
 El tercer nivel esta conformado por el personal médico, tienen a cargo el registro de
diagnóstico, tratamiento, exámenes, recetas; deben poseer conocimientos básicos de
computación. Este se denomina “Nivel Médico”.
 El cuarto nivel esta conformado por personal TENS y QF, tienen a cargo el despacho de
medicamentos desde Farmacia, deben poseer conocimientos básicos de computación.
Este se denomina “Nivel Farmacia”.
 El quinto nivel esta conformado por PPA, quienes tienen a cargo la administración de
reportes e informes estadísticos solicitados por los directivos de DUOC UC y MINSAL,
deben tener conocimientos medio/avanzados de computación. Este se denomina “Nivel
PPA”.
 El sexto nivel esta conformado por personal TI, quienes tienen a cargo la administración
del sistema, deben poseer conocimientos avanzados de computación. Este se denomina
“Nivel TI”.

2.4.Restricciones

Las restricciones que se imponen a nuestros desarrolladores se enmarcan en los siguientes

ítems:

 Políticas de la empresa.
o Debe contar con los emblemas y colores institucionales, además de ser de uso
exclusivo para DUOC UC.

 Limitaciones del hardware.

o El sistema de debe adecuar al Hardware con el cual cuenta habilitado para este
propósito.

 Interfaces con otras aplicaciones.

o Debe conectarse a Previred y/o FONASA para gestionar los copagos respectivos,
según las especificaciones indicadas en Ley de Urgencia; en lo referente a copagos.
También debe conectarse a la BD de Farmacia para la administración de despacho
de recetas.

 Lenguaje(s) de programación.
o Debe regirse a programación enfocada a SQL, para permitir mayor compatibilidad
con respecto a la administración de BD.

 Requisitos de habilidad.
o El equipo TI debe ser de Alto Nivel, Desarrolladores, Programadores Sénior.

8
 Especificación de Requisitos, estándar de IEEE 830

 Consideraciones acerca de la seguridad.

o Habilitar en los niveles correspondientes de usuarios los respaldos de información,
esto se deben realizar en dos partes, Servidor Local y Nube.

2.5.Suposiciones y Dependencias

Para que el producto final sea completamente funcional se debe tener preinstalado el
Plug-In Adobe Flash Player, para los reportes debe contar con un complemento lector de archivos
PDF, sistema operativo Windows 8 o superior, y más importante aún, conexión a Internet.

2.6.Requisitos Futuros

Una vez implementado el sistema, se puede evaluar la incorporación de nuevos módulos

como de comunicación con Pabellones Quirúrgicos u otras unidades relacionadas con urgencias,
envío automático de reportes según definición de dependencia y frecuencia, para posteriormente,
generar un Módulo de Consulta de Pacientes orientado a la oficia OIRS de cada establecimiento de
salud.

9
 Especificación de Requisitos, estándar de IEEE 830

3. Requisitos Específicos

En esta sección se dan a conocer los requisitos a un nivel de detalle suficiente como para
permitir diseñar un sistema que satisfaga las necesidades y problemáticas descritas por el Servicio
de Salud DUOC UC, además debe permitir al equipo de pruebas planificar y realizar los test que
demuestren si el sistema satisface, o no, los requisitos que debe cumplir.

3.1.Requisitos comunes de las interfaces

3.1.1. Interfaces de usuario

La interfaz gráfica con la que el usuario final se encuentre debe ser intuitiva, es decir, que
sin la necesidad de contar con un manual se referencias, el usuario identifique rápidamente las
distintas secciones y componentes del sistema. También deberá contar con los colores
institucionales y una combinación de colores agradables en las zonas de trabajo, para que el
usuario pueda trabajar por varias horas sin problemas.

De igual forma, la interfaz debe ser compatible con los navegadores más comunes, como
por ejemplo:

 Google Crome
 Firefox
 Explorer

Las distintas opciones de interfaz gráfica del sistema serán las siguientes:

 Inicio de Sesión.
o Mensaje de bienvenida, el cual aparecerá con barrido de pantalla y luego
desaparecerá de igual forma, dando paso al Inicio de Sesión.
o Ventana de Inicio de Sesión, solicita nombre de usuario y contraseña.
 Menú.
o El menú se desplegará desde el costado superior izquierdo de la pantalla, de
acuerdo a los niveles de usuarios solicitados:
 Nivel Administrativo.
 Nivel PNM.
 Nivel Médico.
 Nivel Farmacia.
 Nivel PPA.
 Nivel TI.

10
 Especificación de Requisitos, estándar de IEEE 830

o Menú Administrativo.
 El menú administrativo contendrá:
 Dato de Atención de Urgencia – DAU.
 Consulta Previsional.
 Venta de Bonos.
 Cuadratura de Caja.
 Cierres de Sesión.
o Menú PNM.
 El menú PNM contendrá:
 Categorización de Pacientes.
 Tratamientos a Pacientes.
 Derivación a Médicos Sector Azul.
 Derivación a Médicos Sector Rojo.
 Cierre de Sesión.
o Menú Médico.
 El menú médico contendrá:
 Pacientes Sector Azul.
 Pacientes Sector Rojo.
 Ficha de Atención de Paciente.
 Histórico de Pacientes Atendidos.
 Recetas Internas.
 Recetas Externas.
 Cierre de Sesión.
o Menú Farmacia.
 El menú farmacia contendrá:
 Despacho de Recetas Internas.
 Ingreso de Medicamentos.
 Stock de Medicamentos.
 Cierre de Sesión.
o Menú PPA.
 El menú PPA contendrá:
 Reporte REM Serie A, sección A08.
 Reporte DAU por periodo.
 Reporte Categorizaciones.
 Reporte de Prestaciones Realizadas.
 Cierre de Sesión.
o Menú TI.
 El menú TI contendrá:
 Asignación de niveles de usuarios.
 Archivos Maestros.
 Mantenimiento de niveles de usuarios.

11
 Especificación de Requisitos, estándar de IEEE 830

 Reportes varios.
 Respaldo de Información.
 Cierre de Sesión.

3.1.2. Interfaces de hardware

Para que el sistema final pueda ser implementado, la interfaz de hardware debe cumplir
con las siguientes especificaciones y características:

 Procesador Intel Pentium i5 o superior

 RAM 2 GB o superior
 Tipo de Memoria Interna DDR4
 Disco Duro de 250GB
 Tarjeta LAN 10/100
 Dispositivos de Entrada (Teclado y Mouse)
 Tarjeta de Video Genérica o Estándar
 Monitor 14” LCD o Plasma
 Impresora (Ink Jet o Lasser)

3.1.3. Interfaces de software

Para que el sistema final pueda ser implementado, la interfaz de software debe cumplir
con las siguientes especificaciones y características:

 S.O. Windows 8.0 o superior: Sistema Operativo que es la interfaz entre usuario y PC,
sobre el cual se montara el producto final.
 Microsoft SQL Server: Sistema de gestión de BD relacional, en donde se diseñaran las BD.
 Adobe Acrobat Reader: Aplicación desarrollada por Adobe Systems, la cual es necesaria
para la lectura y creación de los distintos informes y reportes (PDF).

3.1.4. Interfaces de comunicación

El producto final se debe enlazar a otros sistemas para realizar una correcta atención,
estos sistemas son PREVIRED y FONASA, la interfaz de comunicación es Internet, por lo que es de
suma importancia poder contar con una conexión permanente y segura.

3.2.Requisitos funcionales

Los requisitos Funcionales del sistema son:

 R.F.1. El Sistema debe realizar el registro de los usuarios.

12
 Especificación de Requisitos, estándar de IEEE 830

 R.F.2. El Sistema debe validar el ingreso de los usuarios.

 R.F.3. El Sistema debe administrar la Ficha Electrónica o DAU (Dato de Atención de
Urgencia).
 R.F.4. El Sistema debe realizar consultas en BD de FONASA o PREVIRED.
 R.F.5. El Sistema debe realizar consultas en BD de Farmacia.
 R.F.6. El Sistema debe administrar la Canasta de Especialistas Médicos.
 R.F.7. El Sistema debe generar consultas por atenciones previas de los pacientes.
 R.F.8. El Sistema debe administrar las Recetas Médicas y Despacho de Medicamentos.
 R.F.9. El Sistema debe administrar el cobro de las prestaciones según Previsión del
paciente (copagos).
 R.F.10. Definir las fases entregables de Ingeniería de Software.
 R.F.11. Definir Marcha Blanca.
 R.F.12. Determinar riesgos asociados a marcha blanca.

3.3.Requisitos no funcionales

Los requisitos No Funcionales del sistema son:

 R.NF.1. El Sistema debe controlar los respaldos de información en la Nube y en Servidores

Propios
 R.NF.2. Se deben entregar Manuales de Usuario del Sistema
 R.NF.3. El Sistema debe ser amigable con el usuario y de fácil manejo
 R.NF.4. Presupuesto definido U$ 700.000

3.4.Otros Requisitos

En esta sección se consideran los requisitos cambiantes, aquellos que tienen una mayor
probabilidad de ser modificados o agregados a lo largo del desarrollo del sistema, ya sea por parte
de DUOC UC o el Equipo Desarrollador. Estos requisitos son:

 Módulo de Solicitud de Quirófano.

 Reportes Automáticos.
 Módulo de Consultas OIRS.

13
 Especificación de Requisitos, estándar de IEEE 830

4. Apéndices

4.1.–Diagrama Sistema AFCU

14
 Especificación de Requisitos, estándar de IEEE 830

4.2. Acta de Reunión Kick-Off

A_M_Kick_Off.docx

4.3.Acta de Constitución de Proyecto

ACP_ASTUCIA_DUOC_SALUD V2.docx

4.4.Planilla de Requerimientos
PLANILLA DE REQUERIMIENTOS.xlsx

4.5.Casos de Uso

CASOS DE USO.pptx

15
 Especificación de Requisitos, estándar de IEEE 830

4.6. Fichas Técnicas

RF- <1> EL SISTEMA DEBE REALIZAR EL REGISTRO DE LOS

USUARIOS

Versión 1.0 – 23 de mayo de 2019

Actores Administrador del Sistema

Objetivos asociados Registro de los usuarios al sistema informático

Requerimientos RF2. El Sistema de Validar el Ingreso de los Usuarios

asociados

Descripción Registrar usuarios al sistema

Precondición Usuarios debe poseer mail institucional que se usara

como nombre usuario

Secuencia Paso Acción

Normal 1 Registro de mail institucional

2 Asignación de contraseña

3 Asignación de Nivel de Usuario

Post Condición Ingreso al sistema mediante usuario y contraseña

Paso Acción

Excepciones 1 No posee mail institucional, usuario regulariza en

unidad de Informática

Rendimiento Paso Cota de tiempo

1 Ingreso de mail institucional, 30 segundos

2 Asignación de Contraseña, 30 segundos

3 Asignación de niveles de usuario, 30 segundos

Frecuencia esperada 20 veces por día

Comentarios

16
 Especificación de Requisitos, estándar de IEEE 830

RF- <2> EL SISTEMA DEBE VALIDAR EL INGRESO DE LOS

USUARIOS

Versión 1.0 – 23 de mayo de 2019

Actores Todos los Usuarios

Objetivos asociados Iniciar Sesión con Nombre Usuario y Contraseña

(LOGIN)

Requerimientos  RF3. El sistema debe administrar la Ficha

asociados Electrónica o DAU
 RF4. El sistema debe realizar consultas en BD
FONASA o PREVIRED
 RF5. El sistema debe realizar consultas en BD de
Farmacia
 RF6. El sistema debe administrar la canasta de
Especialidades Médicas
 RF7. El sistema debe realizar consultas por
atenciones previas
 RF8. El sistema debe administrar las recetas
medicas
 RF9. El sistema debe administrar el despacho de
medicamentos
 RF10. El sistema debe administrar el cobro de las
prestaciones según previsión del paciente

Descripción Ingreso al Sistema a través de nombre usuario y

contraseña

Precondición Usuario debe estar registrado

Secuencia Paso Acción

Normal 1 Usuario digita su nombre usuario (mail

institucional)

2 Usuario digita sus contraseña

Post Condición Ingreso al sistema según su nivel de usuario

Paso Acción

Excepciones 1 Usuario no registrado, solicitar registro a unidad

de Informática

17
 Especificación de Requisitos, estándar de IEEE 830

2 Usuario digita mal su nombre usuario, vuelve a

registrar su nombre usuario

3 Usuario digita mal su contraseña, vuelve a digitar

su contraseña

Rendimiento Paso Cota de tiempo

1 Ingreso de nombre usuario, 30 segundos

2 Ingreso de contraseña, 30 segundos

Frecuencia esperada 100 veces por día

Comentarios

18
 Especificación de Requisitos, estándar de IEEE 830

RF- <3> El Sistema debe administrar la Ficha Electrónica o

DAU (Dato de Atención de Urgencia).

Versión 1.0 – 23 de mayo de 2019

Actores Administrativo – Médicos

Objetivos asociados Registro de Pacientes

Requerimientos  RF4. El sistema debe realizar consultas en BD

asociados FONASA o PREVIRED
 RF7. El sistema debe realizar consultas por
atenciones previas
 RF8. El sistema debe administrar las recetas
medicas
 RF9. El sistema debe administrar el despacho de
medicamentos
 RF10. El sistema debe administrar el cobro de las
prestaciones según previsión del paciente

Descripción Registro de pacientes por parte de Administrativo, junto

con paciente

Precondición Usuario Validado (LOGIN)

Secuencia Paso Acción

Normal 1 Administrativo solicita Cedula de Identidad a

paciente para realizar registro

2 Sistema realiza búsqueda de paciente por RUT

3 Administrativo realiza consultas a paciente para

completar a ficha

4 Administrativo completa ficha

Post Condición Ficha Electrónica emitida

Paso Acción

Excepciones 1 Rut de paciente no encontrado, se digitan los

datos para completar ficha

2 Paciente NN, se realiza ficha con datos como NN

Rendimiento Paso Cota de tiempo

1 Digita RUT, 15 segundos

19
 Especificación de Requisitos, estándar de IEEE 830

2 Digita datos del paciente, 3 minutos

Frecuencia esperada 300 veces por día

Comentarios

20
 Especificación de Requisitos, estándar de IEEE 830

RF- <4> El Sistema debe realizar consultas en BD de FONASA

o PREVIRED

Versión 1.0 – 23 de mayo de 2019

Actores Administrativo

Objetivos asociados Cobro de Atención

Requerimientos  RF9. El sistema debe administrar el despacho de

asociados medicamentos
 RF10. El sistema debe administrar el cobro de las
prestaciones según previsión del paciente

Descripción Revisión de Previsión del paciente en BD FONASA y

PREVIRED

Precondición  Conexión a Internet

 Registro de operador en FONASA o PREVIRED
 Pasar LOGIN FONASA o PREVIRED

Secuencia Paso Acción

Normal 1 Administrativo Ingresa a través de Sistema a

FONASA o PREVIRED

2 Administrativo valida su usuario y contraseña en

FONASA o PREVIRED

3 Administrativo realiza consulta previsional

Post Condición Paciente con previsión validada

Paso Acción

Excepciones 1 Administrativo no registrado en FONASA o

PREVIRED, registrar usuario

2 Sin Acceso a Internet, solicitar a unidad de

informática solución

Rendimiento Paso Cota de tiempo

1 Validar usuario y contraseña, 1 minuto

2 Realzar consulta, 1 minuto

Frecuencia esperada 300 veces por día

Comentarios comentarios adicionales

21
 Especificación de Requisitos, estándar de IEEE 830

R.F.<5> El Sistema debe realizar consultas en BD de

Farmacia.
Versión 1.0 – 23 de mayo de 2019
Actores Médico – Farmacéutico

22
 Especificación de Requisitos, estándar de IEEE 830

Objetivos asociados Consultar la base de datos por stock y descuentos

asociados con la farmacia.
Requerimientos asociados RF9. El sistema debe administrar el despacho de
medicamentos
Descripción Dar a conocer los descuentos y stock de la farmacia
asociada con el hospital.

Precondición Contar con acceso a Red Local de Farmacia

Secuencia Paso Acción
Normal 1 Usuario ingresa a la BD de farmacia
2 Realiza Consulta
Post Condición Donde me lleva el sistema luego de la acción definida
Paso Acción
1 Si el usuario no tiene nivel farmacia, el sistema
Excepciones notificará que no tiene privilegios suficientes
2 En caso de no estar asociados a la farmacia
correspondiente, el sistema de farmacia arroja
error en pantalla “Su cuenta no está asociada.
Rendimiento Paso Cota de tiempo
1 Usuario ingresa a la BD de farmacia, 5 segundos
2 Realiza Consulta, 5 segundos
Frecuencia esperada 200 veces por día
Comentarios

RF- <6> El Sistema debe administrar la Canasta de

Especialistas Médicos

23
 Especificación de Requisitos, estándar de IEEE 830

Versión 1.0 – 23 de mayo de 2019

Actores  Administrador
 Médicos

Objetivos asociados Registrar Especialidades Médicas

Requerimientos asociados RF3. El Sistema debe administrar la Ficha Electrónica o DAU

(Dato de Atención de Urgencia).

Descripción Realizar registro de las distintas especialidades y asociarlas a

los perfiles de los médicos

Precondición Medico Registrado

Secuencia Paso Acción

Normal 1 Administrador o Médico ingresa a opción

después de validar su LOGIN

2 Realizar Asociación de Especialidad a Médico

Post Condición Especialidad Médica asociada a Médico

Paso Acción

Excepciones 1 Médico no registrado, solicitar registro

2 Especialidad no registrada, registrar especialidad

Rendimiento Paso Cota de tiempo

1 Administrador o Médico ingresa a opción

después de validar su LOGIN, 30 segundos

2 Realizar Asociación de Especialidad a Médico,

50 segundos

Frecuencia esperada 10 veces al día

Comentarios

RF- <7> Generar consultas por atenciones previas de los

pacientes

Versión 1.0 – 23 de mayo de 2019

24
 Especificación de Requisitos, estándar de IEEE 830

Actores  Administrativo
 Médicos

Objetivos asociados Realizar consulta de atenciones previas del paciente

Requerimientos asociados RF3. El Sistema debe administrar la Ficha Electrónica o DAU

(Dato de Atención de Urgencia).

Descripción Realizar consulta de atenciones previas por parte

administrativa para generar DAU con antecedentes previos, y
por parte de Médicos para ver tratamientos previos.

Precondición Acceso a DB de Atenciones

Secuencia Paso Acción

1 Administrativo o Médico deben validar (LOGIN)

2 Con RUT de paciente generar consulta de

atenciones previas

Post Condición Informe de Atenciones Previas

Paso Acción

Excepciones 1 RUT incorrecto, re ingresar RUT

2 RUT sin Atenciones previas, mensaje “No

existen atenciones previas”

Rendimiento Paso Cota de tiempo

1 Administrativo o Médico deben validar (LOGIN),

40 segundos

2 Con RUT de paciente generar consulta de

atenciones previas, 10 segundos

Frecuencia esperada 300 veces por día

Comentarios

RF- <8> Administrar las Recetas Médicas y Despacho de

Medicamentos.

Versión 1.0 – 23 de mayo de 2019

25
 Especificación de Requisitos, estándar de IEEE 830

Actores  Médico.
 Farmacéutico.
 Pacientes.

Objetivos asociados Despacho de Medicamentos

Requerimientos  RF3. El Sistema debe administrar la Ficha Electrónica

asociados o DAU (Dato de Atención de Urgencia).
 RF5. El Sistema debe realizar consultas en BD de
Farmacia.

Descripción Generar recetas internas para el despacho de medicamentos o

en caso de no contar con stock generar receta para compra en
el exterior

Precondición Paciente Atendido por Médico

Secuencia Paso Acción

Normal 1 Médico realiza consulta de Stock en Farmacia

2 Habiendo Stock genera receta interna para el

despacho

3 Farmacéutico despacha la receta

4 No hay stock genera receta externa y se le

entrega a paciente

Post Condición Receta Despachada o Receta Emitida

Paso Acción

Excepciones 1 Falla en conexión con Farmacia, Solicitar a

unidad de Informática la reconexión

Rendimiento Paso Cota de tiempo

1 Médico realiza consulta de Stock en Farmacia,

10 segundos

2 Habiendo Stock genera receta interna para el

despacho, 1 minuto

3 Farmacéutico despacha la receta, 10 minutos

4 No hay stock genera receta externa y se le

entrega a paciente, 2 minutos

Frecuencia esperada 300 veces por día

26
 Especificación de Requisitos, estándar de IEEE 830

Comentarios

RF- <9> El Sistema debe administrar el cobro de las

prestaciones según Previsión del paciente
(copagos).

Versión 1.0 – 23 de mayo de 2019

27
 Especificación de Requisitos, estándar de IEEE 830

Actores  Administrativo.
 Pacientes.

Objetivos asociados Cobro de Bonos y Prestaciones

Requerimientos  RF3. El sistema debe administrar la Ficha

asociados Electrónica o DAU
 RF4. El sistema debe realizar consultas en BD
FONASA o PREVIRED

Descripción Realizar el cobro de las prestaciones entregadas según

Previsión del Paciente

Precondición  Paciente con Ficha de Urgencia

 Paciente Atendido por Médico
 Paciente con Validación de Previsión

Secuencia Paso Acción

Normal 1 Validado el paciente atendido, se efectúa cobro

de prestaciones

2 Previsión FONASA, se realiza cobro según

copago

3 Previsión ISAPRE, se realiza cobro según

convenio con ISAPRE

4 Otra Previsión, se realiza cobro del valor total de

las prestaciones

Post Condición Cobro de Prestaciones, entrega de Boleta o Bono

Paso Acción

Excepciones 1 Falla en conexión con Internet, Solicitar a unidad

de Informática la reconexión

Rendimiento Paso Cota de tiempo

1 Validado el paciente atendido, se efectúa cobro

de prestaciones, 1 minuto

2 Previsión FONASA, se realiza cobro según

copago, 1 minuto

3 Previsión ISAPRE, se realiza cobro según

convenio con ISAPRE, 1 minuto

28
 Especificación de Requisitos, estándar de IEEE 830

4 Otra Previsión, se realiza cobro del valor total de

las prestaciones, 10 minutos

Frecuencia esperada 300 veces por día

Comentarios

29