Especificació n de

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

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

Integrantes: Asignatura: Habilidades de Comunicación Escrita

● Pedro Arrate Sección: PLC011-008V

● Elinoir Norvin
Docente: Rosa Guajardo Fuentes

Fecha de Inicio: 23 de abril de 2019

Fecha de Entrega: 29 de abril de 2019

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

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

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

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.
● GB – Gigabyte.

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

● 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 correspondiente 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.
o Menú Administrativo.

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

▪ 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.
▪ Reportes varios.

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

▪ 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 validar el ingreso de los usuarios.

● R.F.2. El Sistema debe administrar la Ficha Electrónica o DAU (Dato de Atención de
Urgencia).

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

● R.F.3. El Sistema debe realizar consultas en BD de FONASA o PREVIRED.

● R.F.4. El Sistema debe realizar consultas en BD de Farmacia.
● R.F.5. El Sistema debe administrar la Canasta de Especialistas Médicos, generar consultas
por atenciones previas de los pacientes, administrar las Recetas Médicas y Despacho de
Medicamentos.
● R.F.6. El Sistema debe administrar el cobro de las prestaciones según Previsión del
paciente (copagos).
● R.F.7. Definir las fases entregables de Ingeniería de Software.
● R.F.8. Definir Marcha Blanca.
● R.F.9. 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.

4. Apéndices

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

4.1.–Diagrama Sistema AFCU

4.2. Acta de Reunión Kick-Off

Acta_Kick_Off.docx

4.3.Acta de Constitución de Proyecto

Acta_Constitucion_Proyecto.docx

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

4.4. Planilla de Requerimientos

PLANILLA DE REQUERIMIENTOS.xlsx

15