3. Requisitos específicos
3.1. Requerimientos de Interfaces Externas
3.2. Requerimientos Funcionales
La nomenclatura utilizada será la siguiente:
REQ_{TIPO}[_{SUBTIPO}]_{NÚMERO_MAYOR}[_{NÚMERO_MENOR}] donde:
- {TIPO} puede ser:
- FUN: Funcional
- NFUNC: No Funcional.
- {SUBTIPO} campo opcional usado para los requerimientos no funcionales.
- {NÚMERO_MAYOR}: número de requerimiento mayor.
- {NÚMERO_MENOR}: opcional, permite disgregar un requerimiento en subrequerimientos. Se especificarán dentro de la descripción del requerimiento.
En esta sección sólo serán especificados los requerimientos de tipo funcional.
Las prioridades podrán ser:
- Esencial: Son requerimientos básicos del sistema. Son
prioritarios.
- Condicional: La importancia de implementación no demanda
urgencia, el producto final debe contenerlo pero en las validaciones
a usuarios finales puede obviarse.
- Deseable: Son requerimientos opcionales, su implementación o no,
no limitará el éxito del proyecto.
| ID: |
REQ_FUNC_001 |
| Nombre: |
Monitorear variables básicas |
| Prioridad: |
Esencial |
| Descripción: |
Las variables básicas son:
- 01 - Saturación de O₂.
- 02 - Frecuencia cardíaca.
- 03 - Temperatura corporal.
|
| ID: |
REQ_FUNC_002 |
| Nombre: |
Aplicación para mostrar datos en tiempo real e históricos |
| Prioridad: |
Esencial |
| Descripción: |
El sistema deberá mostrar por cada internación los
valores actuales e históricos de datos sensados (REQ_FUNC_001).
A su vez debe poder:
- 01- Mostrar alarmas individuales.
-
- 02- Mostrar gráficos con datos históricos y actuales para cada internación.
- 03- Disparar alarmas sonoras y visuales con ACK individual.
- 04- Mostrar los valores de cada internación en una única pantalla de manera de permitir el monitoreo múltiple de pacientes.
- 05 - (Opcional) Generar un reporte en PDF.
- 06 - Posibilidad de ordenar el listado de pacientes de manera que aquellos que tengan disparada una alarma queden arriba.
- 07 - Generar un código QR (REQ_FUNC_006) para consumo de los monitores móviles (REQ_FUNC_007).
|
| ID: |
REQ_FUNC_003 |
| Nombre: |
ABM Usuarios |
| Prioridad: |
Esencial |
| Descripción: |
Para utilizar la aplicación el usuario deberá contar
con permisos de acceso, el administrador del sitio maneja
el alta, baja y modificación de:
- 01 - Dispositivos.
- 02 - Ubicaciones (camas, domicilios, etc).
- 03 - Datos de los pacientes.
- 04 - Internaciones. Las mismas asocian paciente, ubicación y dispositivo.
|
| ID: |
REQ_FUNC_004 |
| Nombre: |
Crear un dispositivo de uso individual |
| Prioridad: |
Esencial |
| Descripción: |
- 01 - De uso individual.
- 02 - Alimentado a baterías.
- 03 - Capaz de transmitir las variables básicas y estado del dispositivo por WiFi a un servidor.
- 04 - Identificado con una etiqueta con los datos del equipo en forma escrita y en un código QR
- 05 - LEDs de estado. Funcionalidad a definir.
- 06 - Deberá poder gusradr una cierta cantidad de datos obtenidos en forma tal de que si no es posible enviar los datos en el momento se puedan enviar mas tarde.
|
| ID: |
REQ_FUNC_005 |
| Nombre: |
Aplicación para guardar registro y efectuar consultas |
| Prioridad: |
|
| Descripción: |
- 01 - La aplicación deberá recibir los datos de los dispositivos, validar sus rangos y de ser correctos ingresarlos en una base de datos.
-
02 - La aplicación deberá poder registrar y atender consultas de datos/estados sobre:
- Dispositivos.
- Ubicaciones (camas, domicilios, etc).
- Datos de los pacientes.
- Internaciones. Las mismas asocian paciente, ubicación y dispositivo.
|
|
| ID: |
REQ_FUNC_006 |
| Nombre: |
Códigos QR de identificación de dispositivo |
| Prioridad: |
Condicional |
| Descripción: |
Los códigos QR de identificación del dispositivo se utilizarán para poder
identificar una internación a partir del ID de dispositivo de manera rápida
por dispositivos móviles, evitando interacción cercana entre paciente y
personal médico.
La especificación del mismo debe incluir al menos el ID de dispositivo.
|
| ID: |
REQ_FUNC_007 |
| Nombre: |
Aplicación móvil para mostrar datos en tiempo real e históricos |
| Prioridad: |
Deseable |
| Descripción: |
El sistema deberá mostrar por cada internación los
valores actuales e históricos de datos sensados (REQ_FUNC_001).
A su vez debe poder:
- 01 - Mostrar alarmas individuales.
-
- 02 - Mostrar gráficos con datos históricos y actuales para cada internación.
- 03 - Disparar alarmas sonoras y visuales con ACK individual.
- 04 - (Opcional) Generar un reporte en PDF.
- 05 - Posibilidad de ordenar el listado de pacientes de manera que aquellos que tengan disparada una alarma queden arriba.
- 06 - Escanear el código QR de dispositivo (REQ_FUN_006).
|
| ID: |
REQ_FUNC_008 |
| Nombre: |
Transmisión de datos de soporte |
| Prioridad: |
Deseable |
| Descripción: |
El dispositivo debe poder enviar al sistema datos que establezcan su estado operativo, entre ellos el nivel de batería.
|
| ID: |
REQ_FUNC_009 |
| Nombre: |
El dispositivo debe poder permitir la configuración de la red WiFi y el servidor a utilizar. |
| Prioridad: |
Deseable |
| Descripción: |
El dispositivo debe permitir ser configurado para establecer la red WiFi a utilizar y el servidor al cual transmitir los datos.
|
| ID: |
REQ_FUNC_010 |
| Nombre: |
El sistema debe cumplir con el período de actualización de datos y sus alarmas. |
| Prioridad: |
Esencial |
| Descripción: |
El sistema debe cumplir con las norma ISO/FDIS 80601-2-61 sección 201.12.4.101 que establece alarmas para cuando se muestran datos que exceden los 30 segundos de actualización.
|
| ID: |
REQ_FUNC_011 |
| Nombre: |
El sistema debe advertir ante valores de SpO2 o ritmo cardíaco potencialmente incorrectos. |
| Prioridad: |
Esencial |
| Descripción: |
El sistema debe cumplir con la norma ISO/FDIS 80601-2-61 sección 201.12.4.102 que establece alarmas para cuando los valores sean potencialmente incorrectos.
|
| ID: |
REQ_FUNC_013 |
| Nombre: |
El sistema debe poseer una indicación que el SpO2 o el ritmo cardíaco no son actuales cuando el último dato supera los 30 segundos. |
| Prioridad: |
Esencial |
| Descripción: |
Según la norma ISO/FDIS 80601-2-61 sección 201.12.4.101.
|
| ID: |
REQ_FUNC_015 |
| Nombre: |
Estado inicial de interfaz gráfica (UI) y alarmas visuales. |
| Prioridad: |
Condicional |
| Descripción: |
La aplicación monitor obtiene las alarmas de datakeeper. Existe un tiempo entre recibir las internaciones activas y obtener las alarmas activas en donde estas últimas no están definidas. Para este caso se debe:
- Asumir que los dispositivos recibidos están desaparecidos (se perdió contacto con los mismos).
- Los valores de los sensores son críticos.
|
| Issue relacionado: |
https://gitlab.com/mosimpa/documentation/-/issues/168 |
| ID: |
REQ_FUNC_016 |
| Nombre: |
Alarma visual de valores antigüos. |
| Prioridad: |
Condicional |
| Descripción: |
Existe la posibilidad de que se dejen de recibir datos de uno o varios dispositivos:
- Se pierde conectividad WiFi.
- Un sensor presenta problemas.
- Otros.
En estos casos es conveniente notificar al PM a través de una alarma visual. La aplicación monitor ante una alarma de dispositivo faltante deberá:
- Alerta amarilla: pasar el color de fondo de la fila de la internación a gris, incluídos los valores de los sensores.
- Alerta naranja o roja: idem amarilla pero reemplazando los valores de los sensores por "--".
|
| Issue relacionado: |
https://gitlab.com/mosimpa/documentation/-/issues/168 |
3.2.1. Requerimientos funcionales: casos de uso
3.2.1.1. Diagrama de casos de uso
INCLUIR DIAGRAMA DE CASOS DE USO
3.2.1.2. Casos de Uso
La nomenclatura utilizada será la siguiente:
CU<MÓDULO>;<NÚMERO>;.
3.2. Requerimientos no funcionales
3.2.1. Datos
| ID: |
REQ_NFUNC_DATOS_001 |
| Nombre: |
Rango de saturación de oxígeno SpO₂ |
| Prioridad: |
Esencial |
| Descripción: |
Entre 0 y 100%. Valores por fuera de este rango no tienen sentido físico.
|
| ID: |
REQ_NFUNC_DATOS_002 |
| Nombre: |
Rango de ritmo cardíaco |
| Prioridad: |
Esencial |
| Descripción: |
- 01 - El mínimo es 0 ya que no tiene sentido físico un valor negativo de latidos por minuto.
- 02 - El máximo es 300 latidos por minuto, límite superior observado en pacientes con taquicardia supraventricular.
|
| ID: |
REQ_NFUNC_DATOS_003 |
| Nombre: |
Rango de temperatura corporal |
| Prioridad: |
Esencial |
| Descripción: |
Se requiere al menos un rango entre 20 y 45ºC. |
| ID: |
REQ_NFUNC_DATOS_004 |
| Nombre: |
Rango de valores de alarma |
| Prioridad: |
Esencial |
| Descripción: |
Los rangos de los valores de alarma permiten limitar la configuración de
las mismas a valores con sentido clínico. A modo de contraejemplo no
tiene sentido poner una alarma de baja temperatura corporal para que
dispare solo cuando el valor es menor a 10 ºC, ya que esto sería un riesgo
para el paciente.
Para poder evitar tener que reemplazar las implementaciones de los
monitores en caso de tener que cambiar un rango los mismos serán provistos
de forma centralizada.
Las alarmas con sus rangos se definen como:
- 01 - SpO₂ igual o menor a: entre [85 y 95%](https://gitlab.com/mosimpa/documentation/-/issues/141).
- 02 - Ritmo cardíaco igual o menor a: entre 40 y 60 latidos por minuto.
- 03 - Ritmo cardíaco igual o mayor a: entre 100 y 140 latidos por minuto.
- 04 - Temperatura corporal igual o menor a: entre 35 y 37 ºC.
- 05 - Temperatura corporal igual o mayor a: entre 38 y 40 ºC.
A su vez cada tipo de alarma poseerá un retraso configurable de 15 a 60
segundos, valores recomendados en el estudio
Retrospective analysis of pulse oximeter alarm settings in an intensive care unit patient population.
|
| ID: |
REQ_NFUNC_DATOS_005 |
| Nombre: |
Valores por omisión de las alarmas |
| Prioridad: |
Esencial |
| Descripción: |
Al crear una internación se usan los siguientes valores por omisión:
- 01 - SpO₂: 95%.
- 02 - Ritmo cardíaco igual o menor a: 60 latidos por minuto.
- 03 - Ritmo cardíaco igual o mayor a: 100 latidos por minuto.
- 04 - Temperatura corporal igual o menor a: 37 ºC.
- 05 - Temperatura corporal igual o mayor a: 38 ºC.
- 06 - Delay de cada alarma: 15".
|
| ID: |
REQ_NFUNC_PERFORMANCE_001 |
| Nombre: |
Mínimo de dispositivos simultáneos |
| Prioridad: |
Condicional |
| Descripción: |
El sistema en su conjunto debe permitir al menos 30 dispositivos
funcionando de forma simultánea bajo las siguientes condiciones:
- 01- La red ethernet será exclusiva para este uso.
-
02 - El router tendrá al menos las siguientes características:
- 01 - Soportará los estándares IEEE 802.11 a, b, g y n.
- 02 - Soportará la frecuencia de 2.4 GHz.
- 03 - Soportará WPA2.
- 04 - Podrá funcionar como servidor DHCP.
- 05 - Podrá funcionar como DNS estático, es decir, se podrá configurar un hostname asociado a una IP.
- 03 - El servidor estará conectado al router mediante un cable Ethernet.
- 04 - El canal de transmisión del router deberá estar libre de interferencias.
Las características del router de base se podrán modificar en caso de que
las mismas sean la causa de limitación que impidan cumplimentar este
requerimiento.
Es necesario que en el DNS estático del router se asigne al servidor una IP fija fuera del rango del pool de DHCP (para evitar colisiones).
|
3.2.3. Disponibilidad
| ID: |
|
| Nombre: |
|
| Prioridad: |
|
| Descripción: |
|
3.2.4. Seguridad
| ID: |
Seguridad 1 |
| Nombre: |
Cifrado de datos por fuera del entorno del servidor |
| Prioridad: |
Esencial |
| Descripción: |
Todos los datos que se trafiquen por fuera del servidor y/o dispositivo (redes WiFi/Ethernet) deben estar encriptados. |
3.2.5. Confiabilidad
| ID: |
REQ_NFUNC_CONFIABILIDAD_001 |
| Nombre: |
Realizar varias lecturas de los sensores para determinar que no haya problema de transferencia de datos |
| Prioridad: |
Condicional |
| Descripción: |
El sistema deberá tratar de leer los sensores varias veces para asegurarse de que los datos obtenidos sean confiables. |
3.2.6. Rendimiento
| ID: |
|
| Nombre: |
|
| Prioridad: |
|
| Descripción: |
|
3.2.7. Portabilidad
| ID: |
|
| Nombre: |
|
| Prioridad: |
|
| Descripción: |
|
3.2.8. Mantenibilidad
| ID: |
|
| Nombre: |
|
| Prioridad: |
|
| Descripción: |
|
3.3. Restricciones de Diseño
4. Apéndices
4.1. Anexos
4.2. Historial de cambios
El historial de los cambios puede consultarse en la historia de las
revisiones, o mediante la identificación de las versiones taggeadas
según el Sistema de Control de Versionado (VCS) empleado. La descripción de los cambios estará especificada en
los comentarios del commit correspondiente.