Monitor de signos vitales

Uno de los componentes innovadores del proyecto AR_CODEX es el monitor de signos vitales que será una parte integral del sistema de control del respirador automático. Este monitor permitirá consultar los datos que se registren con los sensores de los signos vitales del paciente y los que se encuentran en el respirador automático, a través de dispositivos móviles (smartphones/tablets), por medio de una conexión WIFI.

Componentes del monitor de signos vitales

Servidor

El servidor está compuesto por el Backend, que es el entorno lógico que se encarga del funcionamiento de una página web. Este utiliza el micro.framework Flask, el cual utiliza el lenguaje de programación Phyton, que se utiliza para el desarrollo de aplicaciones Web bajo el patrón MVC. 

Utiliza las siguientes dependencias: 

• Flask-Authorize
• Websockets
• Flask-SQLalchemy

Receptor de datos

Es el componente encargado de aceptar las conexiones de los clientes-sensores y guarda las mediciones enviadas por estos en una base de datos local. Está basado en websockets y maneja conexiones simultáneas.

Base de datos

Se basa en SQLite, el cual es un sistema de gestión de bases de datos transaccionales, y cumple con las características ACID. Maneja velocidades altas con baja carga (cientos de clientes).

API

Se utiliza API-REST para administrar y para consultar datos.

Frontend

El frontend es la interfaz con la que el usuario interactúa dentro de una página web. Podría estar basado en Vue.js o en otra tecnología que se ajuste a las necesidades de los usuarios. Permite la visualización de datos, configuración de alarmas, administración del sistema dependiendo de roles y permisos del usuario.

Estructuras de datos

1. Usuarios
2. Roles
3. Permisos
4. Clientes-Sensores
1. Creado
2. Dirección MAC
3. ID
4. Agente (versión del cliente y modelo del hardware, un texto breve e informativo)
5. Sensores
1. Creado
2. Nombres
3. Descripción
4. Unidad
5. Agente (versión, modelo del sensor, etc., deberían de ser textos breves, informativos que permitan saber nombres de chips, año de modelo, desarrollador, etc.)
6. ID
6. Datos de sensores
1. Timestamp
2. Valor
3. Sensor ID
4. Sesión ID
7. Sesiones
1. Creado
2. Cliente ID
3. Descripción (el contexto de la sesión)
4. Identificador local (Puede ser DPI, ID de ficha clínica, u otro, antecedido por el tipo de ID)

Protocolo de conexión

Un cliente-sensor nuevo es configurado para conectarse con el servidor configurando la conexión al WiFi, luego la dirección IP del servidor, la clave de seguridad (si se usa HTTPS no sería necesario, si no se puede usar Diffie-Helman o RSA), la información del paciente, y del contexto (puede ser el hospital X o una clínica, un proyecto, ONG, etc), la información de cada sensor disponible conectado a este cliente-sensor. Al recibir esta información el servidor registra una nueva sesión, registra los sensores si estos no existen, mapea ids de sensores con los sensores presentes en el cliente sensor para ir guardando los datos, a nivel de sesión y envía de vuelta una señal que informa que está listo para comenzar el registro continuo de datos. Al perder la conexión olvida el mapeo de sensores.

#Guatemala #OpenSource #AR_CODEX