ANÁLISIS DE ARQUITECTURA Y
PROPUESTA DE MEJORA INTEGRAL DEL
SISTEMA IOT PARA MONITOREO
CONTINUO DE GLUCOSA
ARCHITECTURE ANALYSIS AND COMPREHENSIVE
IMPROVEMENT PROPOSAL FOR AN IOT-BASED
CONTINUOUS GLUCOSE MONITORING SYSTEM
Luis Alejandro Santana Valadez
Instituto Tecnológico de Pachuca
Wendy Daniel Martínez
Universidad Politécnica Metropolitana de Hidalgo
Víctor Manuel Zamudio García
Universidad Politécnica Metropolitana de Hidalgo
Carlos Alberto Carrillo Santos
Universidad Politécnica Metropolitana de Hidalgo
pág. 2552
DOI: https://doi.org/10.37811/cl_rcm.v10i4.25286
Análisis de arquitectura y propuesta de mejora integral del sistema IoT
para monitoreo continuo de glucosa
Luis Alejandro Santana Valadez1
luis.sv@pachuca.tecnm.mx
https://orcid.org/0000-0003-1561-020X
Instituto Tecnológico de Pachuca
Pachuca Hidalgo, México
Wendy Daniel Martínez
wdaniel@upmh.edu.mx
https://orcid.org/0000-0002-4455-940X
Universidad Politécnica Metropolitana de
Hidalgo
Tolcayuca Hidalgo, México
Víctor Manuel Zamudio García
vzamudio@upmh.edu.mx
https://orcid.org/0000-0002-4660-8025
Universidad Politécnica Metropolitana de
Hidalgo
Tolcayuca Hidalgo, México
Carlos Alberto Carrillo Santos
ccarrillo@upmh.edu.mx
https://orcid.org/0000-0001-6866-8558
Universidad Politécnica Metropolitana de
Hidalgo
Tolcayuca Hidalgo, México
RESUMEN
El monitoreo continuo de glucosa (CGM) representa una de las aplicaciones más relevantes del Internet
de las Cosas Médicas por su capacidad para capturar datos fisiológicos frecuentes, generar alertas y
apoyar decisiones clínicas oportunas. El objetivo de este artículo es analizar la arquitectura actual de un
sistema IoT-CGM y proponer una mejora integral orientada a resiliencia, seguridad, interoperabilidad,
escalabilidad y experiencia de usuario. Metodológicamente, se desarrolló un estudio tecnológico-
aplicativo mediante revisión documental, modelado con grafos dirigidos, análisis de rutas críticas y
rediseño arquitectónico por capas. Los resultados evidencian que el smartphone del paciente y la
plataforma en la nube concentran alta centralidad funcional, por lo que constituyen puntos únicos de
fallo frente a pérdida de conectividad, caída del servicio o agotamiento de batería. Como respuesta, se
propone una arquitectura edge-fog-cloud con motor local de alertas, sincronización tolerante a fallos,
middleware IoT, microservicios, bases de datos de series temporales, seguridad extremo a extremo e
interoperabilidad clínica mediante estándares. Se concluye que la arquitectura integral propuesta
constituye una alternativa técnicamente más robusta para pacientes de distintas edades que requieren
monitoreo continuo, oportuno y comprensible de la glucosa.
Palabras clave: Internet de las Cosas Médicas; monitoreo continuo de glucosa; arquitectura IoT; edge
computing; interoperabilidad clínica.
1Autor principal.
Correspondencia: luis.sv@pachuca.tecnm.mx
DOI: https://doi.org/10.37811/cl_rcm.v10i4.25286
Análisis de arquitectura y propuesta de mejora integral del sistema IoT
para monitoreo continuo de glucosa
Luis Alejandro Santana Valadez1
luis.sv@pachuca.tecnm.mx
https://orcid.org/0000-0003-1561-020X
Instituto Tecnológico de Pachuca
Pachuca Hidalgo, México
Wendy Daniel Martínez
wdaniel@upmh.edu.mx
https://orcid.org/0000-0002-4455-940X
Universidad Politécnica Metropolitana de
Hidalgo
Tolcayuca Hidalgo, México
Víctor Manuel Zamudio García
vzamudio@upmh.edu.mx
https://orcid.org/0000-0002-4660-8025
Universidad Politécnica Metropolitana de
Hidalgo
Tolcayuca Hidalgo, México
Carlos Alberto Carrillo Santos
ccarrillo@upmh.edu.mx
https://orcid.org/0000-0001-6866-8558
Universidad Politécnica Metropolitana de
Hidalgo
Tolcayuca Hidalgo, México
RESUMEN
El monitoreo continuo de glucosa (CGM) representa una de las aplicaciones más relevantes del Internet
de las Cosas Médicas por su capacidad para capturar datos fisiológicos frecuentes, generar alertas y
apoyar decisiones clínicas oportunas. El objetivo de este artículo es analizar la arquitectura actual de un
sistema IoT-CGM y proponer una mejora integral orientada a resiliencia, seguridad, interoperabilidad,
escalabilidad y experiencia de usuario. Metodológicamente, se desarrolló un estudio tecnológico-
aplicativo mediante revisión documental, modelado con grafos dirigidos, análisis de rutas críticas y
rediseño arquitectónico por capas. Los resultados evidencian que el smartphone del paciente y la
plataforma en la nube concentran alta centralidad funcional, por lo que constituyen puntos únicos de
fallo frente a pérdida de conectividad, caída del servicio o agotamiento de batería. Como respuesta, se
propone una arquitectura edge-fog-cloud con motor local de alertas, sincronización tolerante a fallos,
middleware IoT, microservicios, bases de datos de series temporales, seguridad extremo a extremo e
interoperabilidad clínica mediante estándares. Se concluye que la arquitectura integral propuesta
constituye una alternativa técnicamente más robusta para pacientes de distintas edades que requieren
monitoreo continuo, oportuno y comprensible de la glucosa.
Palabras clave: Internet de las Cosas Médicas; monitoreo continuo de glucosa; arquitectura IoT; edge
computing; interoperabilidad clínica.
1Autor principal.
Correspondencia: luis.sv@pachuca.tecnm.mx
pág. 2553
Architecture analysis and comprehensive improvement proposal for an IoT-
based continuous glucose monitoring system
ABSTRACT
Continuous glucose monitoring (CGM) is one of the most relevant applications of the Internet of
Medical Things because it enables frequent physiological data capture, alerts, and timely clinical
decision support. This article aims to analyze the current architecture of an IoT-CGM system and
propose a comprehensive improvement focused on resilience, security, interoperability, scalability, and
user experience. Methodologically, a technological-applied study was conducted through documentary
review, directed graph modeling, critical path analysis, and layered architectural redesign. The findings
show that the patient smartphone and the cloud platform concentrate high functional centrality;
therefore, they become single points of failure in the event of connectivity loss, service outage, or battery
depletion. In response, an edge-fog-cloud architecture is proposed, including a local alert engine, fault-
tolerant synchronization, IoT middleware, microservices, time-series databases, end-to-end security, and
clinical interoperability based on standards. The study concludes that the proposed comprehensive
architecture represents a more technically robust alternative for patients of different ages who require
continuous, timely, and understandable glucose monitoring.
Keywords: Internet of Medical Things; continuous glucose monitoring; IoT architecture; edge
computing; clinical interoperability.
Artículo recibido 20 mayo 2026
Aceptado para publicación: 20 junio 2026
Architecture analysis and comprehensive improvement proposal for an IoT-
based continuous glucose monitoring system
ABSTRACT
Continuous glucose monitoring (CGM) is one of the most relevant applications of the Internet of
Medical Things because it enables frequent physiological data capture, alerts, and timely clinical
decision support. This article aims to analyze the current architecture of an IoT-CGM system and
propose a comprehensive improvement focused on resilience, security, interoperability, scalability, and
user experience. Methodologically, a technological-applied study was conducted through documentary
review, directed graph modeling, critical path analysis, and layered architectural redesign. The findings
show that the patient smartphone and the cloud platform concentrate high functional centrality;
therefore, they become single points of failure in the event of connectivity loss, service outage, or battery
depletion. In response, an edge-fog-cloud architecture is proposed, including a local alert engine, fault-
tolerant synchronization, IoT middleware, microservices, time-series databases, end-to-end security, and
clinical interoperability based on standards. The study concludes that the proposed comprehensive
architecture represents a more technically robust alternative for patients of different ages who require
continuous, timely, and understandable glucose monitoring.
Keywords: Internet of Medical Things; continuous glucose monitoring; IoT architecture; edge
computing; clinical interoperability.
Artículo recibido 20 mayo 2026
Aceptado para publicación: 20 junio 2026
pág. 2554
INTRODUCCIÓN
La convergencia entre Internet de las Cosas (IoT), aplicaciones móviles, computación en la nube y
dispositivos biomédicos ha impulsado el desarrollo del Internet de las Cosas Médicas (IoMT), entendido
como un ecosistema de sensores, plataformas y servicios capaces de recolectar, transmitir, procesar y
visualizar datos de salud en escenarios clínicos y domiciliarios. En este marco, la salud digital deja de
depender únicamente de mediciones aisladas y avanza hacia modelos de monitoreo remoto,
telemedicina, seguimiento longitudinal y toma de decisiones basada en datos (Huang et al., 2023; Seth
et al., 2025).
Uno de los ámbitos donde esta transformación tiene mayor impacto es la atención de la diabetes. Los
sistemas de monitoreo continuo de glucosa permiten capturar lecturas frecuentes de glucosa en líquido
intersticial mediante sensores portables, transmitirlas a un smartphone o lector dedicado, consolidarlas
en plataformas en la nube y compartirlas con pacientes, cuidadores y profesionales de salud. Estudios
previos han mostrado la viabilidad de arquitecturas IoT-CGM basadas en sensores, aplicaciones móviles,
fog computing y servicios cloud, especialmente para la generación de alertas tempranas y la vigilancia
continua de eventos de hipo e hiperglucemia (Gia et al., 2017; Fernández-Caramés et al., 2019;
Dhanumjaya et al., 2025).
No obstante, la utilidad clínica de un sistema CGM no depende únicamente de la precisión del sensor o
de la existencia de una aplicación móvil. Su desempeño real está condicionado por la arquitectura
completa: conectividad de proximidad, procesamiento local, sincronización con la nube,
almacenamiento de series temporales, integración con sistemas clínicos, seguridad de los datos y diseño
de experiencia de usuario. Cuando estas dimensiones no se integran de manera coherente, pueden
aparecer riesgos operativos como latencia elevada, pérdida de continuidad, fallos de notificación,
fragmentación de datos, fatiga de alertas y dependencia excesiva de nodos centrales.
Desde una perspectiva arquitectónica, el sistema CGM puede analizarse como un grafo dirigido en el
que los nodos representan sensores, smartphones, servicios cloud, portales clínicos, dispositivos de
insulina, cuidadores y sistemas externos; mientras que las aristas representan los flujos de información
y dependencias funcionales. Este enfoque permite identificar rutas críticas, cuellos de botella y puntos
INTRODUCCIÓN
La convergencia entre Internet de las Cosas (IoT), aplicaciones móviles, computación en la nube y
dispositivos biomédicos ha impulsado el desarrollo del Internet de las Cosas Médicas (IoMT), entendido
como un ecosistema de sensores, plataformas y servicios capaces de recolectar, transmitir, procesar y
visualizar datos de salud en escenarios clínicos y domiciliarios. En este marco, la salud digital deja de
depender únicamente de mediciones aisladas y avanza hacia modelos de monitoreo remoto,
telemedicina, seguimiento longitudinal y toma de decisiones basada en datos (Huang et al., 2023; Seth
et al., 2025).
Uno de los ámbitos donde esta transformación tiene mayor impacto es la atención de la diabetes. Los
sistemas de monitoreo continuo de glucosa permiten capturar lecturas frecuentes de glucosa en líquido
intersticial mediante sensores portables, transmitirlas a un smartphone o lector dedicado, consolidarlas
en plataformas en la nube y compartirlas con pacientes, cuidadores y profesionales de salud. Estudios
previos han mostrado la viabilidad de arquitecturas IoT-CGM basadas en sensores, aplicaciones móviles,
fog computing y servicios cloud, especialmente para la generación de alertas tempranas y la vigilancia
continua de eventos de hipo e hiperglucemia (Gia et al., 2017; Fernández-Caramés et al., 2019;
Dhanumjaya et al., 2025).
No obstante, la utilidad clínica de un sistema CGM no depende únicamente de la precisión del sensor o
de la existencia de una aplicación móvil. Su desempeño real está condicionado por la arquitectura
completa: conectividad de proximidad, procesamiento local, sincronización con la nube,
almacenamiento de series temporales, integración con sistemas clínicos, seguridad de los datos y diseño
de experiencia de usuario. Cuando estas dimensiones no se integran de manera coherente, pueden
aparecer riesgos operativos como latencia elevada, pérdida de continuidad, fallos de notificación,
fragmentación de datos, fatiga de alertas y dependencia excesiva de nodos centrales.
Desde una perspectiva arquitectónica, el sistema CGM puede analizarse como un grafo dirigido en el
que los nodos representan sensores, smartphones, servicios cloud, portales clínicos, dispositivos de
insulina, cuidadores y sistemas externos; mientras que las aristas representan los flujos de información
y dependencias funcionales. Este enfoque permite identificar rutas críticas, cuellos de botella y puntos
pág. 2555
únicos de fallo, conectando el análisis técnico del IoT con criterios de resiliencia, seguridad,
escalabilidad e interoperabilidad (Gallo & Micucci, 2025).
El objetivo de este artículo es analizar la arquitectura actual de un ecosistema IoT para monitoreo
continuo de glucosa y proponer una mejora integral que incorpore edge computing en el smartphone,
middleware IoT, microservicios, almacenamiento optimizado para series temporales, seguridad
multicapa, integración clínica y diseño centrado en pacientes de cualquier edad. La contribución
principal consiste en transformar un análisis de arquitectura funcional en una propuesta técnica de
evolución, orientada a que el sistema sea más confiable, accesible y sostenible para el monitoreo
continuo de glucosa en escenarios reales.
METODOLOGÍA
El estudio se desarrolló bajo un enfoque tecnológico-aplicativo, de alcance descriptivo y propositivo.
No se trata de un ensayo clínico ni de una evaluación con pacientes, sino de un análisis arquitectónico
de un ecosistema IoT-CGM a partir de literatura técnica y del modelado formal de sus componentes. El
diseño metodológico se estructuró en cuatro fases: caracterización de la arquitectura actual, modelado
matemático mediante grafos dirigidos, identificación de limitaciones y formulación de una arquitectura
integral mejorada (véase la Tabla 1).
Tabla 1. Matriz metodológica del análisis arquitectónico IoT-CGM.
Fase Propósito Procedimiento técnico Producto obtenido
Caracterización
actual
Describir el
funcionamiento del
ecosistema CGM.
Clasificación por capas
IoT: percepción, red,
servicios y aplicación.
Mapa funcional de
componentes y flujos de
datos.
Modelado con
grafos
Identificar rutas
críticas y nodos
centrales.
Definición de V, E,
matriz de adyacencia y
rutas de propagación.
Grafo dirigido del sistema
actual y detección de
puntos únicos de fallo.
Análisis de
brechas
Determinar
limitaciones técnicas
y operativas.
Comparación contra
criterios de resiliencia,
seguridad,
Lista priorizada de áreas
de mejora arquitectónica.
únicos de fallo, conectando el análisis técnico del IoT con criterios de resiliencia, seguridad,
escalabilidad e interoperabilidad (Gallo & Micucci, 2025).
El objetivo de este artículo es analizar la arquitectura actual de un ecosistema IoT para monitoreo
continuo de glucosa y proponer una mejora integral que incorpore edge computing en el smartphone,
middleware IoT, microservicios, almacenamiento optimizado para series temporales, seguridad
multicapa, integración clínica y diseño centrado en pacientes de cualquier edad. La contribución
principal consiste en transformar un análisis de arquitectura funcional en una propuesta técnica de
evolución, orientada a que el sistema sea más confiable, accesible y sostenible para el monitoreo
continuo de glucosa en escenarios reales.
METODOLOGÍA
El estudio se desarrolló bajo un enfoque tecnológico-aplicativo, de alcance descriptivo y propositivo.
No se trata de un ensayo clínico ni de una evaluación con pacientes, sino de un análisis arquitectónico
de un ecosistema IoT-CGM a partir de literatura técnica y del modelado formal de sus componentes. El
diseño metodológico se estructuró en cuatro fases: caracterización de la arquitectura actual, modelado
matemático mediante grafos dirigidos, identificación de limitaciones y formulación de una arquitectura
integral mejorada (véase la Tabla 1).
Tabla 1. Matriz metodológica del análisis arquitectónico IoT-CGM.
Fase Propósito Procedimiento técnico Producto obtenido
Caracterización
actual
Describir el
funcionamiento del
ecosistema CGM.
Clasificación por capas
IoT: percepción, red,
servicios y aplicación.
Mapa funcional de
componentes y flujos de
datos.
Modelado con
grafos
Identificar rutas
críticas y nodos
centrales.
Definición de V, E,
matriz de adyacencia y
rutas de propagación.
Grafo dirigido del sistema
actual y detección de
puntos únicos de fallo.
Análisis de
brechas
Determinar
limitaciones técnicas
y operativas.
Comparación contra
criterios de resiliencia,
seguridad,
Lista priorizada de áreas
de mejora arquitectónica.
pág. 2556
interoperabilidad, UX y
escalabilidad.
Propuesta integral
Diseñar una
arquitectura técnica
optimizada.
Incorporación de edge
analytics, middleware
IoT, microservicios,
estándares clínicos y
seguridad multicapa.
Arquitectura IoT-CGM
mejorada y matriz de
tecnologías
recomendadas.
La unidad de análisis fue un ecosistema de monitoreo continuo de glucosa compuesto por sensor CGM,
smartphone del paciente, plataforma cloud, portal clínico, dispositivo de cuidador, dispositivos de
administración de insulina y sistemas clínicos externos. La caracterización se organizó con base en el
modelo de capas IoT: percepción, red, soporte de servicios y aplicación. Este criterio permitió ubicar
funciones, protocolos y riesgos técnicos de manera sistemática.
Para la formalización, se construyó un grafo dirigido G=(V,E), donde V representa el conjunto de nodos
técnicos y humanos del ecosistema, y E representa las relaciones de comunicación o dependencia
funcional entre ellos. A partir del grafo se revisaron rutas de propagación de datos, centralidad funcional,
vértices de corte y posibles puntos únicos de fallo. Posteriormente, se definió un grafo mejorado con
nuevos nodos de middleware, microservicios, analítica, notificaciones, reportes e interoperabilidad
clínica.
Las técnicas de análisis utilizadas fueron revisión documental especializada, abstracción arquitectónica
por capas, comparación de escenarios actual-propuesto y diseño técnico basado en criterios no
funcionales. Los criterios de evaluación considerados fueron eficiencia energética, latencia, continuidad
de servicio, escalabilidad, seguridad, privacidad, interoperabilidad, mantenibilidad y experiencia de
usuario. En términos éticos, el estudio no emplea datos personales ni mediciones reales de pacientes;
por ello, la discusión se limita al plano arquitectónico y no sustituye validaciones clínicas, regulatorias
o biomédicas.
interoperabilidad, UX y
escalabilidad.
Propuesta integral
Diseñar una
arquitectura técnica
optimizada.
Incorporación de edge
analytics, middleware
IoT, microservicios,
estándares clínicos y
seguridad multicapa.
Arquitectura IoT-CGM
mejorada y matriz de
tecnologías
recomendadas.
La unidad de análisis fue un ecosistema de monitoreo continuo de glucosa compuesto por sensor CGM,
smartphone del paciente, plataforma cloud, portal clínico, dispositivo de cuidador, dispositivos de
administración de insulina y sistemas clínicos externos. La caracterización se organizó con base en el
modelo de capas IoT: percepción, red, soporte de servicios y aplicación. Este criterio permitió ubicar
funciones, protocolos y riesgos técnicos de manera sistemática.
Para la formalización, se construyó un grafo dirigido G=(V,E), donde V representa el conjunto de nodos
técnicos y humanos del ecosistema, y E representa las relaciones de comunicación o dependencia
funcional entre ellos. A partir del grafo se revisaron rutas de propagación de datos, centralidad funcional,
vértices de corte y posibles puntos únicos de fallo. Posteriormente, se definió un grafo mejorado con
nuevos nodos de middleware, microservicios, analítica, notificaciones, reportes e interoperabilidad
clínica.
Las técnicas de análisis utilizadas fueron revisión documental especializada, abstracción arquitectónica
por capas, comparación de escenarios actual-propuesto y diseño técnico basado en criterios no
funcionales. Los criterios de evaluación considerados fueron eficiencia energética, latencia, continuidad
de servicio, escalabilidad, seguridad, privacidad, interoperabilidad, mantenibilidad y experiencia de
usuario. En términos éticos, el estudio no emplea datos personales ni mediciones reales de pacientes;
por ello, la discusión se limita al plano arquitectónico y no sustituye validaciones clínicas, regulatorias
o biomédicas.
pág. 2557
RESULTADOS Y DISCUSIÓN
Arquitectura actual del ecosistema IoT-CGM
La arquitectura actual del ecosistema CGM se organiza en cuatro capas principales. En la capa de
percepción se ubican el sensor CGM, el smartphone o lector del paciente y, en algunos escenarios,
dispositivos complementarios como bombas de insulina o plumas inteligentes. En la capa de red se
integran tecnologías de proximidad, principalmente Bluetooth Low Energy (BLE) y NFC, así como
conectividad IP mediante Wi-Fi o redes celulares. En la capa de soporte de servicios se ubica la
plataforma cloud que almacena y procesa series temporales de glucosa. Finalmente, la capa de aplicación
integra la app móvil del paciente, portales clínicos, aplicaciones de cuidadores y posibles sistemas de
telemedicina.
El modelo actual es funcional y coherente con la evolución del IoMT, pero mantiene una dependencia
fuerte del smartphone y de la nube. El smartphone actúa simultáneamente como receptor local, interfaz
de usuario, pasarela de comunicación y primer punto de notificación; la nube concentra almacenamiento,
analítica, reportes y distribución de información hacia profesionales y cuidadores. Esta concentración
simplifica el despliegue inicial, pero reduce resiliencia cuando se presentan fallas de conectividad,
batería, sincronización o disponibilidad de servicios (véase Tabla 2 y Figura 1).
Tabla 2. Síntesis de componentes, funciones y riesgos de la arquitectura actual.
Capa IoT Componentes
principales
Función dentro del
CGM
Riesgo o limitación
identificada
Percepción
Sensor CGM, dispositivo
de insulina, smartphone
del paciente.
Captura lecturas de
glucosa y habilita
comunicación inicial
con el usuario.
Dependencia de
batería, memoria local
limitada y necesidad de
enlace BLE/NFC
estable.
Red
BLE, NFC, Wi-Fi,
4G/5G, protocolos IP.
Transmite lecturas
hacia smartphone y
nube.
Latencia variable,
pérdida de cobertura y
retraso en
sincronización de
alertas remotas.
RESULTADOS Y DISCUSIÓN
Arquitectura actual del ecosistema IoT-CGM
La arquitectura actual del ecosistema CGM se organiza en cuatro capas principales. En la capa de
percepción se ubican el sensor CGM, el smartphone o lector del paciente y, en algunos escenarios,
dispositivos complementarios como bombas de insulina o plumas inteligentes. En la capa de red se
integran tecnologías de proximidad, principalmente Bluetooth Low Energy (BLE) y NFC, así como
conectividad IP mediante Wi-Fi o redes celulares. En la capa de soporte de servicios se ubica la
plataforma cloud que almacena y procesa series temporales de glucosa. Finalmente, la capa de aplicación
integra la app móvil del paciente, portales clínicos, aplicaciones de cuidadores y posibles sistemas de
telemedicina.
El modelo actual es funcional y coherente con la evolución del IoMT, pero mantiene una dependencia
fuerte del smartphone y de la nube. El smartphone actúa simultáneamente como receptor local, interfaz
de usuario, pasarela de comunicación y primer punto de notificación; la nube concentra almacenamiento,
analítica, reportes y distribución de información hacia profesionales y cuidadores. Esta concentración
simplifica el despliegue inicial, pero reduce resiliencia cuando se presentan fallas de conectividad,
batería, sincronización o disponibilidad de servicios (véase Tabla 2 y Figura 1).
Tabla 2. Síntesis de componentes, funciones y riesgos de la arquitectura actual.
Capa IoT Componentes
principales
Función dentro del
CGM
Riesgo o limitación
identificada
Percepción
Sensor CGM, dispositivo
de insulina, smartphone
del paciente.
Captura lecturas de
glucosa y habilita
comunicación inicial
con el usuario.
Dependencia de
batería, memoria local
limitada y necesidad de
enlace BLE/NFC
estable.
Red
BLE, NFC, Wi-Fi,
4G/5G, protocolos IP.
Transmite lecturas
hacia smartphone y
nube.
Latencia variable,
pérdida de cobertura y
retraso en
sincronización de
alertas remotas.
pág. 2558
Soporte de
servicios
Plataforma cloud de datos
de glucosa.
Almacena series
temporales, calcula
métricas y genera
reportes.
Punto central de fallo;
riesgo de
indisponibilidad y
acoplamiento
funcional.
Aplicación
App paciente, portal
clínico, app cuidador,
sistemas clínicos.
Visualiza datos,
configura alertas y
comparte información.
Fragmentación de
interfaces, fatiga de
alertas y complejidad
para usuarios
vulnerables.
Figura 1. Arquitectura actual del ecosistema de monitoreo continuo de glucosa (CGM).
Modelado con grafos y rutas críticas
El ecosistema actual se formalizó como un grafo dirigido G=(V,E), con siete nodos principales y un
conjunto de aristas que describen los flujos de información y las dependencias funcionales entre sensor,
Soporte de
servicios
Plataforma cloud de datos
de glucosa.
Almacena series
temporales, calcula
métricas y genera
reportes.
Punto central de fallo;
riesgo de
indisponibilidad y
acoplamiento
funcional.
Aplicación
App paciente, portal
clínico, app cuidador,
sistemas clínicos.
Visualiza datos,
configura alertas y
comparte información.
Fragmentación de
interfaces, fatiga de
alertas y complejidad
para usuarios
vulnerables.
Figura 1. Arquitectura actual del ecosistema de monitoreo continuo de glucosa (CGM).
Modelado con grafos y rutas críticas
El ecosistema actual se formalizó como un grafo dirigido G=(V,E), con siete nodos principales y un
conjunto de aristas que describen los flujos de información y las dependencias funcionales entre sensor,
pág. 2559
smartphone, nube y actores clínicos. Las tablas 3 y 4 que se muestran a continuación sintetizan los nodos
y las aristas del modelo antes de visualizar el grafo dirigido del sistema.
Tabla 3. Nodos del grafo actual, rol funcional y criticidad arquitectónica.
Nodo Elemento Rol funcional Criticidad
v1 Sensor CGM Nodo de origen de lecturas
de glucosa.
Alta: fuente primaria de datos,
pero con conectividad limitada
hacia v2.
v2 Smartphone del
paciente
Gateway, interfaz, receptor
y primer procesador local.
Muy alta: vértice de corte entre
sensor y nube.
v3 Plataforma en la
nube
Almacenamiento, analítica,
reportes y distribución de
datos.
Muy alta: concentra acceso
clínico, cuidadores e
interoperabilidad.
v4 Portal clínico Consulta de reportes por
profesionales.
Media: depende de la
disponibilidad de v3.
v5 Dispositivo de
administración de
insulina
Soporte a terapia
automatizada o
semiautomatizada.
Alta en escenarios de lazo
cerrado o semi-cerrado.
v6 Dispositivo del
cuidador/familiar
Recepción de alertas y
seguimiento remoto.
Media: relevante para niños,
adultos mayores o pacientes
dependientes.
v7 Sistemas clínicos
externos
Integración con EHR y
telemedicina.
Media-alta: clave para
continuidad institucional de
atención.
smartphone, nube y actores clínicos. Las tablas 3 y 4 que se muestran a continuación sintetizan los nodos
y las aristas del modelo antes de visualizar el grafo dirigido del sistema.
Tabla 3. Nodos del grafo actual, rol funcional y criticidad arquitectónica.
Nodo Elemento Rol funcional Criticidad
v1 Sensor CGM Nodo de origen de lecturas
de glucosa.
Alta: fuente primaria de datos,
pero con conectividad limitada
hacia v2.
v2 Smartphone del
paciente
Gateway, interfaz, receptor
y primer procesador local.
Muy alta: vértice de corte entre
sensor y nube.
v3 Plataforma en la
nube
Almacenamiento, analítica,
reportes y distribución de
datos.
Muy alta: concentra acceso
clínico, cuidadores e
interoperabilidad.
v4 Portal clínico Consulta de reportes por
profesionales.
Media: depende de la
disponibilidad de v3.
v5 Dispositivo de
administración de
insulina
Soporte a terapia
automatizada o
semiautomatizada.
Alta en escenarios de lazo
cerrado o semi-cerrado.
v6 Dispositivo del
cuidador/familiar
Recepción de alertas y
seguimiento remoto.
Media: relevante para niños,
adultos mayores o pacientes
dependientes.
v7 Sistemas clínicos
externos
Integración con EHR y
telemedicina.
Media-alta: clave para
continuidad institucional de
atención.
pág. 2560
Tabla 4. Aristas del grafo actual y significado funcional.
Arista Relación entre nodos Finalidad funcional Tecnología o canal
predominante
v1→v2 Sensor CGM →
smartphone del paciente
Transmisión primaria de lecturas
de glucosa al gateway del paciente.
BLE o NFC
v2→v3 Smartphone del paciente
→ plataforma en la nube
Sincronización de lecturas,
eventos y metadatos hacia la
infraestructura cloud.
Wi-Fi / 4G / 5G,
HTTPS o MQTT
v3→v4 Plataforma en la nube →
portal clínico
Consulta de reportes y métricas
por parte del profesional de salud.
API web / HTTPS
v3→v6 Plataforma en la nube →
dispositivo del cuidador
Envío de alertas y visualización
remota compartida.
Servicios push / API
móvil
v3→v7 Plataforma en la nube →
sistemas clínicos externos
Interoperabilidad con historia
clínica electrónica y telemedicina.
APIs e integración
clínica
v3↔v5 Plataforma en la nube ↔
dispositivo de insulina
Intercambio de información
terapéutica en escenarios híbridos
de lazo cerrado.
Servicios cloud /
protocolos del
fabricante
v2→v5 Smartphone del paciente
→ dispositivo de insulina
Comunicación local
complementaria para soporte
terapéutico.
BLE / canal propietario
El análisis evidencia que v2 y v3 son nodos de alta centralidad. La ruta paciente-médico sigue el flujo
v1→v2→v3→v4; la ruta paciente-cuidador, v1→v2→v3→v6; y la ruta paciente-sistema clínico,
v1→v2→v3→v7. En consecuencia, la eliminación de v2 desconecta al sensor del resto del ecosistema,
mientras que la caída de v3 aísla el subgrafo clínico y el subgrafo de soporte social. La figura 2 permite
visualizar esta concentración de rutas críticas y la existencia de puntos únicos de fallo.
Tabla 4. Aristas del grafo actual y significado funcional.
Arista Relación entre nodos Finalidad funcional Tecnología o canal
predominante
v1→v2 Sensor CGM →
smartphone del paciente
Transmisión primaria de lecturas
de glucosa al gateway del paciente.
BLE o NFC
v2→v3 Smartphone del paciente
→ plataforma en la nube
Sincronización de lecturas,
eventos y metadatos hacia la
infraestructura cloud.
Wi-Fi / 4G / 5G,
HTTPS o MQTT
v3→v4 Plataforma en la nube →
portal clínico
Consulta de reportes y métricas
por parte del profesional de salud.
API web / HTTPS
v3→v6 Plataforma en la nube →
dispositivo del cuidador
Envío de alertas y visualización
remota compartida.
Servicios push / API
móvil
v3→v7 Plataforma en la nube →
sistemas clínicos externos
Interoperabilidad con historia
clínica electrónica y telemedicina.
APIs e integración
clínica
v3↔v5 Plataforma en la nube ↔
dispositivo de insulina
Intercambio de información
terapéutica en escenarios híbridos
de lazo cerrado.
Servicios cloud /
protocolos del
fabricante
v2→v5 Smartphone del paciente
→ dispositivo de insulina
Comunicación local
complementaria para soporte
terapéutico.
BLE / canal propietario
El análisis evidencia que v2 y v3 son nodos de alta centralidad. La ruta paciente-médico sigue el flujo
v1→v2→v3→v4; la ruta paciente-cuidador, v1→v2→v3→v6; y la ruta paciente-sistema clínico,
v1→v2→v3→v7. En consecuencia, la eliminación de v2 desconecta al sensor del resto del ecosistema,
mientras que la caída de v3 aísla el subgrafo clínico y el subgrafo de soporte social. La figura 2 permite
visualizar esta concentración de rutas críticas y la existencia de puntos únicos de fallo.
pág. 2561
Figura 2. Grafo dirigido del ecosistema CGM actual y relaciones funcionales entre nodos.
Áreas de mejora identificadas
El análisis arquitectónico permite agrupar las áreas de mejora en cinco dimensiones. La primera es la
resiliencia: el sistema requiere mantener alertas locales aun cuando la nube o la conectividad móvil no
estén disponibles. La segunda es la continuidad de servicio: las lecturas deben conservarse localmente
y sincronizarse posteriormente con mecanismos de confirmación, reintentos y consistencia eventual. La
tercera es la seguridad y privacidad: los datos de glucosa son información sensible de salud y deben
protegerse mediante cifrado, autenticación, autorización, auditoría y minimización de exposición.
La cuarta dimensión es la interoperabilidad. La coexistencia de sensores, bombas de insulina,
aplicaciones, portales y sistemas clínicos heterogéneos exige estándares que eviten islas de información.
La quinta dimensión corresponde a la experiencia de usuario. Un sistema destinado a personas de
cualquier edad debe ser comprensible para niñas, niños, adolescentes, adultos y adultos mayores;
además, debe permitir roles diferenciados para cuidadores, familiares y profesionales de salud. La
mejora integral no se limita a agregar componentes tecnológicos, sino a reorganizar el ecosistema para
que el dato crítico llegue al actor correcto, en el momento correcto y con una interfaz usable.
Arquitectura integral propuesta para el ecosistema IoT-CGM
La arquitectura propuesta transforma el smartphone del paciente de una simple pasarela a un nodo edge
inteligente. Este nodo incorpora un motor local de reglas y alertas, capaz de evaluar umbrales, tendencias
Figura 2. Grafo dirigido del ecosistema CGM actual y relaciones funcionales entre nodos.
Áreas de mejora identificadas
El análisis arquitectónico permite agrupar las áreas de mejora en cinco dimensiones. La primera es la
resiliencia: el sistema requiere mantener alertas locales aun cuando la nube o la conectividad móvil no
estén disponibles. La segunda es la continuidad de servicio: las lecturas deben conservarse localmente
y sincronizarse posteriormente con mecanismos de confirmación, reintentos y consistencia eventual. La
tercera es la seguridad y privacidad: los datos de glucosa son información sensible de salud y deben
protegerse mediante cifrado, autenticación, autorización, auditoría y minimización de exposición.
La cuarta dimensión es la interoperabilidad. La coexistencia de sensores, bombas de insulina,
aplicaciones, portales y sistemas clínicos heterogéneos exige estándares que eviten islas de información.
La quinta dimensión corresponde a la experiencia de usuario. Un sistema destinado a personas de
cualquier edad debe ser comprensible para niñas, niños, adolescentes, adultos y adultos mayores;
además, debe permitir roles diferenciados para cuidadores, familiares y profesionales de salud. La
mejora integral no se limita a agregar componentes tecnológicos, sino a reorganizar el ecosistema para
que el dato crítico llegue al actor correcto, en el momento correcto y con una interfaz usable.
Arquitectura integral propuesta para el ecosistema IoT-CGM
La arquitectura propuesta transforma el smartphone del paciente de una simple pasarela a un nodo edge
inteligente. Este nodo incorpora un motor local de reglas y alertas, capaz de evaluar umbrales, tendencias
pág. 2562
y tasas de cambio sin depender de la nube. También integra una cola local de eventos con estados de
envío, confirmación y reintento, de modo que la pérdida temporal de conectividad no implique pérdida
de datos ni ausencia de alertas críticas para el paciente.
En la capa de comunicación se introduce un middleware IoT compuesto por un broker MQTT en clúster
y un API Gateway. El broker permite telemetría ligera bajo el modelo publish/subscribe, mientras que
el gateway concentra autenticación, autorización, control de acceso y exposición de servicios REST para
operaciones administrativas. En la capa de servicios, la lógica se divide en microservicios
especializados: ingestión de lecturas CGM, analítica clínica, notificaciones, historiales, reportes e
integración clínica. Esta separación reduce acoplamiento, facilita mantenimiento y permite escalar cada
servicio de forma independiente.
La propuesta también incorpora una capa explícita de integración y seguridad. Los adaptadores
FHIR/HL7 permiten interoperar con historias clínicas electrónicas y plataformas de telemedicina.
OAuth2/OpenID Connect proporciona autenticación y autorización por roles; TLS protege
comunicaciones; y el cifrado de datos en reposo, junto con auditoría y monitoreo, fortalece la privacidad.
Desde la perspectiva del usuario, el sistema puede adaptar alertas, visualizaciones y permisos según
perfil: paciente autónomo, menor de edad, adulto mayor, cuidador o profesional clínico.
Modelado del grafo propuesto y análisis de mejoras
La arquitectura integral propuesta se formalizó mediante un grafo dirigido Gmej=(W,Emej), compuesto
por diez nodos especializados que distribuyen la lógica del sistema entre edge, middleware IoT,
microservicios clínicos y aplicaciones consumidoras. Este modelado permite identificar con mayor
precisión la modularidad de la solución y comparar la reducción de centralización respecto del modelo
actual. Las tablas 5 y 6 mostradas a continuación sintetizan los nodos y las aristas del modelo propuesto
antes de visualizar el grafo dirigido mejorado del sistema.
y tasas de cambio sin depender de la nube. También integra una cola local de eventos con estados de
envío, confirmación y reintento, de modo que la pérdida temporal de conectividad no implique pérdida
de datos ni ausencia de alertas críticas para el paciente.
En la capa de comunicación se introduce un middleware IoT compuesto por un broker MQTT en clúster
y un API Gateway. El broker permite telemetría ligera bajo el modelo publish/subscribe, mientras que
el gateway concentra autenticación, autorización, control de acceso y exposición de servicios REST para
operaciones administrativas. En la capa de servicios, la lógica se divide en microservicios
especializados: ingestión de lecturas CGM, analítica clínica, notificaciones, historiales, reportes e
integración clínica. Esta separación reduce acoplamiento, facilita mantenimiento y permite escalar cada
servicio de forma independiente.
La propuesta también incorpora una capa explícita de integración y seguridad. Los adaptadores
FHIR/HL7 permiten interoperar con historias clínicas electrónicas y plataformas de telemedicina.
OAuth2/OpenID Connect proporciona autenticación y autorización por roles; TLS protege
comunicaciones; y el cifrado de datos en reposo, junto con auditoría y monitoreo, fortalece la privacidad.
Desde la perspectiva del usuario, el sistema puede adaptar alertas, visualizaciones y permisos según
perfil: paciente autónomo, menor de edad, adulto mayor, cuidador o profesional clínico.
Modelado del grafo propuesto y análisis de mejoras
La arquitectura integral propuesta se formalizó mediante un grafo dirigido Gmej=(W,Emej), compuesto
por diez nodos especializados que distribuyen la lógica del sistema entre edge, middleware IoT,
microservicios clínicos y aplicaciones consumidoras. Este modelado permite identificar con mayor
precisión la modularidad de la solución y comparar la reducción de centralización respecto del modelo
actual. Las tablas 5 y 6 mostradas a continuación sintetizan los nodos y las aristas del modelo propuesto
antes de visualizar el grafo dirigido mejorado del sistema.
pág. 2563
Tabla 5. Nodos del grafo propuesto y función dentro de la arquitectura integral.
Nodo Elemento Rol funcional Aporte arquitectónico
w1 Sensor CGM Captura continua de glucosa y
almacenamiento temporal local.
Mantiene la
adquisición de datos en
el borde con tolerancia
básica a desconexiones.
w2 Smartphone del paciente
(app + motor local)
Recepción del sensor, edge
analytics y sincronización tolerante
a fallos.
Reduce latencia de
alertas y preserva
continuidad operativa
en modo offline.
w3 Middleware IoT (API
Gateway + Broker MQTT)
Punto de entrada controlado para
telemetría y servicios.
Desacopla clientes y
backend, favoreciendo
escalabilidad
horizontal.
w4 Servicio de ingestión CGM Validación y almacenamiento
inicial de lecturas.
Aísla el procesamiento
de entrada y evita
sobrecarga del
middleware.
w5 Servicio de analítica
clínica
Cálculo de TIR, variabilidad y
detección de eventos críticos.
Especializa la
inteligencia clínica sin
afectar el flujo de
ingestión.
w6 Servicio de notificaciones Distribución de alertas al paciente
y cuidadores.
Separa la mensajería
crítica de otras
funciones del backend.
w7 Servicio de historiales y
reportes
Consolidación longitudinal y
exposición de reportes.
Facilita trazabilidad
clínica e
interoperabilidad con
actores externos.
w8 Portal clínico Consumo profesional de métricas e
historiales.
Aísla la experiencia del
profesional de salud
como consumidor
especializado.
w9 App cuidador/familiar Seguimiento remoto y recepción de
alertas compartidas.
Extiende el soporte
social sin incrementar
la carga operativa del
paciente.
w10 Sistema clínico / EHR Integración institucional con
expedientes y telemedicina.
Inserta la solución en
ecosistemas sanitarios
interoperables.
Tabla 5. Nodos del grafo propuesto y función dentro de la arquitectura integral.
Nodo Elemento Rol funcional Aporte arquitectónico
w1 Sensor CGM Captura continua de glucosa y
almacenamiento temporal local.
Mantiene la
adquisición de datos en
el borde con tolerancia
básica a desconexiones.
w2 Smartphone del paciente
(app + motor local)
Recepción del sensor, edge
analytics y sincronización tolerante
a fallos.
Reduce latencia de
alertas y preserva
continuidad operativa
en modo offline.
w3 Middleware IoT (API
Gateway + Broker MQTT)
Punto de entrada controlado para
telemetría y servicios.
Desacopla clientes y
backend, favoreciendo
escalabilidad
horizontal.
w4 Servicio de ingestión CGM Validación y almacenamiento
inicial de lecturas.
Aísla el procesamiento
de entrada y evita
sobrecarga del
middleware.
w5 Servicio de analítica
clínica
Cálculo de TIR, variabilidad y
detección de eventos críticos.
Especializa la
inteligencia clínica sin
afectar el flujo de
ingestión.
w6 Servicio de notificaciones Distribución de alertas al paciente
y cuidadores.
Separa la mensajería
crítica de otras
funciones del backend.
w7 Servicio de historiales y
reportes
Consolidación longitudinal y
exposición de reportes.
Facilita trazabilidad
clínica e
interoperabilidad con
actores externos.
w8 Portal clínico Consumo profesional de métricas e
historiales.
Aísla la experiencia del
profesional de salud
como consumidor
especializado.
w9 App cuidador/familiar Seguimiento remoto y recepción de
alertas compartidas.
Extiende el soporte
social sin incrementar
la carga operativa del
paciente.
w10 Sistema clínico / EHR Integración institucional con
expedientes y telemedicina.
Inserta la solución en
ecosistemas sanitarios
interoperables.
pág. 2564
Tabla 6. Aristas del grafo propuesto y distribución de flujos funcionales.
Arista Relación entre nodos Finalidad funcional Beneficio principal
w1→w2 Sensor CGM →
smartphone paciente
Entrega local de lecturas
desde el sensor al nodo edge.
Permite análisis inmediato
en el dispositivo del
paciente.
w2→w3 Smartphone paciente
→ middleware IoT
Sincronización segura de
telemetría y eventos.
Desacopla el edge del
backend y mejora tolerancia
a intermitencia.
w3→w4 Middleware IoT →
servicio de ingestión
Canaliza los datos hacia
validación y persistencia
inicial.
Evita acoplamiento directo
con servicios de negocio.
w4→w5 Ingestión → analítica
clínica
Alimenta cálculos clínicos y
detección de eventos.
Especializa el procesamiento
avanzado.
w4→w7 Ingestión → historiales
y reportes
Persisten datos longitudinales
y conforma la base histórica.
Asegura trazabilidad clínica
continua.
w5→w6 Analítica clínica →
notificaciones
Activa alertas críticas y
recomendaciones.
Permite mensajería sensible
al tiempo sin depender del
portal clínico.
w5→w7 Analítica clínica →
historiales y reportes
Incorpora métricas calculadas
al repositorio clínico.
Enriquece la consulta
retrospectiva y longitudinal.
w6→w2 Notificaciones →
smartphone paciente
Entrega alertas al usuario
principal.
Refuerza continuidad local
de atención.
w6→w9 Notificaciones → app
cuidador
Comparte eventos relevantes
con la red de apoyo.
Mejora supervisión en niños,
adultos mayores o pacientes
dependientes.
w7→w8 Historiales y reportes
→ portal clínico
Expone tableros y reportes al
profesional.
Aísla el consumo clínico del
procesamiento interno.
w7→w10 Historiales y reportes
→ sistema
clínico/EHR
Intercambia información con
el ecosistema hospitalario.
Fortalece interoperabilidad y
continuidad institucional.
El grafo propuesto incrementa el número de nodos de 7 a 10 y redistribuye la centralidad que antes
recaía casi por completo en el smartphone del paciente y en un backend cloud monolítico. La lógica se
reparte entre middleware, ingestión, analítica, notificaciones e historiales, lo que reduce el efecto de
punto único de fallo y permite que una falla en un servicio no interrumpa de manera total el ecosistema.
Tabla 6. Aristas del grafo propuesto y distribución de flujos funcionales.
Arista Relación entre nodos Finalidad funcional Beneficio principal
w1→w2 Sensor CGM →
smartphone paciente
Entrega local de lecturas
desde el sensor al nodo edge.
Permite análisis inmediato
en el dispositivo del
paciente.
w2→w3 Smartphone paciente
→ middleware IoT
Sincronización segura de
telemetría y eventos.
Desacopla el edge del
backend y mejora tolerancia
a intermitencia.
w3→w4 Middleware IoT →
servicio de ingestión
Canaliza los datos hacia
validación y persistencia
inicial.
Evita acoplamiento directo
con servicios de negocio.
w4→w5 Ingestión → analítica
clínica
Alimenta cálculos clínicos y
detección de eventos.
Especializa el procesamiento
avanzado.
w4→w7 Ingestión → historiales
y reportes
Persisten datos longitudinales
y conforma la base histórica.
Asegura trazabilidad clínica
continua.
w5→w6 Analítica clínica →
notificaciones
Activa alertas críticas y
recomendaciones.
Permite mensajería sensible
al tiempo sin depender del
portal clínico.
w5→w7 Analítica clínica →
historiales y reportes
Incorpora métricas calculadas
al repositorio clínico.
Enriquece la consulta
retrospectiva y longitudinal.
w6→w2 Notificaciones →
smartphone paciente
Entrega alertas al usuario
principal.
Refuerza continuidad local
de atención.
w6→w9 Notificaciones → app
cuidador
Comparte eventos relevantes
con la red de apoyo.
Mejora supervisión en niños,
adultos mayores o pacientes
dependientes.
w7→w8 Historiales y reportes
→ portal clínico
Expone tableros y reportes al
profesional.
Aísla el consumo clínico del
procesamiento interno.
w7→w10 Historiales y reportes
→ sistema
clínico/EHR
Intercambia información con
el ecosistema hospitalario.
Fortalece interoperabilidad y
continuidad institucional.
El grafo propuesto incrementa el número de nodos de 7 a 10 y redistribuye la centralidad que antes
recaía casi por completo en el smartphone del paciente y en un backend cloud monolítico. La lógica se
reparte entre middleware, ingestión, analítica, notificaciones e historiales, lo que reduce el efecto de
punto único de fallo y permite que una falla en un servicio no interrumpa de manera total el ecosistema.
pág. 2565
Además, se crea un bucle corto para notificaciones críticas (w5→w6→w2), a la vez que se separan los
caminos de consumo clínico (w7→w8 y w7→w10), favoreciendo modularidad, escalabilidad y
resiliencia operativa.
En la Figura 3 se visualiza el grafo dirigido mejorado del sistema propuesto con énfasis en la
redistribución de la centralidad y la especialización funcional de los componentes. En la Figura 4 se
muestra la arquitectura integral propuesta alineada al grafo mejorado. Finalmente, en la Tabla 7 se
muestra la comparación de la arquitectura actual con la arquitectura propuesta y el impacto técnico
esperado.
Figura 3. Grafo dirigido mejorado del ecosistema IoT-CGM.
Además, se crea un bucle corto para notificaciones críticas (w5→w6→w2), a la vez que se separan los
caminos de consumo clínico (w7→w8 y w7→w10), favoreciendo modularidad, escalabilidad y
resiliencia operativa.
En la Figura 3 se visualiza el grafo dirigido mejorado del sistema propuesto con énfasis en la
redistribución de la centralidad y la especialización funcional de los componentes. En la Figura 4 se
muestra la arquitectura integral propuesta alineada al grafo mejorado. Finalmente, en la Tabla 7 se
muestra la comparación de la arquitectura actual con la arquitectura propuesta y el impacto técnico
esperado.
Figura 3. Grafo dirigido mejorado del ecosistema IoT-CGM.
pág. 2566
Figura 4. Arquitectura integral propuesta para el ecosistema IoT-CGM.
Tabla 7. Comparación técnica entre arquitectura actual y arquitectura propuesta.
Dimensión Arquitectura actual Arquitectura
propuesta Impacto técnico esperado
Resiliencia
Alertas y
sincronización
dependen fuertemente
de smartphone y nube.
Motor local de alertas,
cola offline y
sincronización tolerante
a fallos.
Continuidad de alerta local
y recuperación posterior de
datos.
Escalabilidad
Backend centralizado
con riesgo de cuello de
botella.
Middleware IoT, broker
MQTT en clúster y
microservicios
escalables.
Crecimiento horizontal por
servicio y mejor gestión de
carga.
Seguridad
Protección dependiente
de implementación del
proveedor.
TLS, OAuth2/OIDC,
auditoría, monitoreo y
cifrado en reposo.
Reducción de exposición de
datos sensibles y
trazabilidad.
Interoperabilidad
APIs y formatos
potencialmente
propietarios.
Adaptadores FHIR/HL7
y APIs seguras.
Integración con EHR,
telemedicina y ecosistemas
hospitalarios.
Experiencia de
usuario
Visualización y alertas
con riesgo de fatiga o
complejidad.
Alertas configurables,
roles diferenciados y
UX centrada en
edad/perfil.
Mayor comprensión,
adherencia y soporte a
cuidadores.
Figura 4. Arquitectura integral propuesta para el ecosistema IoT-CGM.
Tabla 7. Comparación técnica entre arquitectura actual y arquitectura propuesta.
Dimensión Arquitectura actual Arquitectura
propuesta Impacto técnico esperado
Resiliencia
Alertas y
sincronización
dependen fuertemente
de smartphone y nube.
Motor local de alertas,
cola offline y
sincronización tolerante
a fallos.
Continuidad de alerta local
y recuperación posterior de
datos.
Escalabilidad
Backend centralizado
con riesgo de cuello de
botella.
Middleware IoT, broker
MQTT en clúster y
microservicios
escalables.
Crecimiento horizontal por
servicio y mejor gestión de
carga.
Seguridad
Protección dependiente
de implementación del
proveedor.
TLS, OAuth2/OIDC,
auditoría, monitoreo y
cifrado en reposo.
Reducción de exposición de
datos sensibles y
trazabilidad.
Interoperabilidad
APIs y formatos
potencialmente
propietarios.
Adaptadores FHIR/HL7
y APIs seguras.
Integración con EHR,
telemedicina y ecosistemas
hospitalarios.
Experiencia de
usuario
Visualización y alertas
con riesgo de fatiga o
complejidad.
Alertas configurables,
roles diferenciados y
UX centrada en
edad/perfil.
Mayor comprensión,
adherencia y soporte a
cuidadores.
pág. 2567
Justificación de protocolos y tecnologías
La selección de tecnologías se realizó considerando eficiencia energética, latencia, robustez, seguridad
e interoperabilidad. En el enlace sensor-smartphone, BLE se mantiene como tecnología principal por su
bajo consumo y adecuación a transmisiones periódicas de pequeños volúmenes de datos, especialmente
en dispositivos médicos portables (Gómez et al., 2012; Omre & Keeping, 2010). NFC funciona como
canal complementario aportando proximidad física como mecanismo adicional de control.
Para la comunicación smartphone-nube, MQTT sobre TLS optimiza la telemetría continua y eventos
críticos por su modelo ligero publish/subscribe y su operatividad eficiente en escenarios IoT con
conectividad intermitente (OASIS, 2019; MQTT.org, n.d.). HTTPS/REST se reserva para operaciones
transaccionales menos frecuentes: consulta de reportes, administración de usuarios, descarga de
configuración y gestión de dispositivos.
En backend, los microservicios y contenedores permiten separar responsabilidades técnicas y clínicas:
ingestión, analítica, notificaciones, historiales, reportes e integración. Las bases de datos de series
temporales son útiles porque las lecturas de glucosa tienen naturaleza secuencial y frecuencia definida.
Finalmente, la aplicación de FHIR/HL7, OAuth2/OpenID Connect, cifrado y auditoría permite que el
sistema sea integrable, seguro y gobernable dentro de ecosistemas sanitarios reales (Seth et al., 2025;
Gallo & Micucci, 2025). En la Tabla 8 se muestra el resumen con la descripción de las tecnologías
recomendadas.
Tabla 8. Matriz de tecnologías recomendadas para la arquitectura integral IoT-CGM.
Capa /
componente
Tecnología
recomendada Uso propuesto Justificación
Percepción BLE + NFC
Lectura sensor-smartphone
y configuración puntual.
Bajo consumo,
proximidad y
compatibilidad con
dispositivos portables.
Edge móvil
Motor local de reglas
+ cola offline
Alertas inmediatas y
sincronización posterior.
Reduce latencia y
dependencia de
conectividad permanente.
Justificación de protocolos y tecnologías
La selección de tecnologías se realizó considerando eficiencia energética, latencia, robustez, seguridad
e interoperabilidad. En el enlace sensor-smartphone, BLE se mantiene como tecnología principal por su
bajo consumo y adecuación a transmisiones periódicas de pequeños volúmenes de datos, especialmente
en dispositivos médicos portables (Gómez et al., 2012; Omre & Keeping, 2010). NFC funciona como
canal complementario aportando proximidad física como mecanismo adicional de control.
Para la comunicación smartphone-nube, MQTT sobre TLS optimiza la telemetría continua y eventos
críticos por su modelo ligero publish/subscribe y su operatividad eficiente en escenarios IoT con
conectividad intermitente (OASIS, 2019; MQTT.org, n.d.). HTTPS/REST se reserva para operaciones
transaccionales menos frecuentes: consulta de reportes, administración de usuarios, descarga de
configuración y gestión de dispositivos.
En backend, los microservicios y contenedores permiten separar responsabilidades técnicas y clínicas:
ingestión, analítica, notificaciones, historiales, reportes e integración. Las bases de datos de series
temporales son útiles porque las lecturas de glucosa tienen naturaleza secuencial y frecuencia definida.
Finalmente, la aplicación de FHIR/HL7, OAuth2/OpenID Connect, cifrado y auditoría permite que el
sistema sea integrable, seguro y gobernable dentro de ecosistemas sanitarios reales (Seth et al., 2025;
Gallo & Micucci, 2025). En la Tabla 8 se muestra el resumen con la descripción de las tecnologías
recomendadas.
Tabla 8. Matriz de tecnologías recomendadas para la arquitectura integral IoT-CGM.
Capa /
componente
Tecnología
recomendada Uso propuesto Justificación
Percepción BLE + NFC
Lectura sensor-smartphone
y configuración puntual.
Bajo consumo,
proximidad y
compatibilidad con
dispositivos portables.
Edge móvil
Motor local de reglas
+ cola offline
Alertas inmediatas y
sincronización posterior.
Reduce latencia y
dependencia de
conectividad permanente.
pág. 2568
Telemetría MQTT sobre TLS
Publicación continua de
lecturas y eventos.
Ligero, escalable y
adecuado para redes
intermitentes.
Administración HTTPS/REST
Consultas, configuración y
gestión de dispositivos.
Modelo transaccional
claro y ampliamente
compatible.
Servicios cloud
Microservicios +
contenedores
Ingestión, analítica,
notificación e historiales.
Escalabilidad
independiente, aislamiento
de fallos y mantenimiento
modular.
Datos
Base de series
temporales + data lake
Historial glucémico,
reportes y analítica
avanzada.
Estructura optimizada para
datos secuenciales y
análisis longitudinal.
Integración
clínica
FHIR/HL7
Interoperabilidad con EHR
y telemedicina.
Evita silos y facilita
continuidad institucional
de atención.
Seguridad
OAuth2/OIDC, TLS,
cifrado y auditoría
Control de acceso,
trazabilidad y protección
de datos.
Necesario para
información sensible de
salud.
Perspectiva de uso para pacientes de cualquier edad
El valor de la arquitectura propuesta se fortalece cuando se analiza desde la diversidad de usuarios. En
pacientes pediátricos, la disponibilidad de alertas locales y notificaciones a cuidadores resulta crítica
para eventos nocturnos o entornos escolares. En adolescentes, la experiencia móvil debe balancear
autonomía, privacidad y acompañamiento. En adultos, el sistema debe integrarse con rutinas laborales
y actividad física. En adultos mayores, la interfaz debe reducir carga cognitiva mediante iconografía
clara, mensajes breves, niveles de urgencia y opciones de accesibilidad.
Telemetría MQTT sobre TLS
Publicación continua de
lecturas y eventos.
Ligero, escalable y
adecuado para redes
intermitentes.
Administración HTTPS/REST
Consultas, configuración y
gestión de dispositivos.
Modelo transaccional
claro y ampliamente
compatible.
Servicios cloud
Microservicios +
contenedores
Ingestión, analítica,
notificación e historiales.
Escalabilidad
independiente, aislamiento
de fallos y mantenimiento
modular.
Datos
Base de series
temporales + data lake
Historial glucémico,
reportes y analítica
avanzada.
Estructura optimizada para
datos secuenciales y
análisis longitudinal.
Integración
clínica
FHIR/HL7
Interoperabilidad con EHR
y telemedicina.
Evita silos y facilita
continuidad institucional
de atención.
Seguridad
OAuth2/OIDC, TLS,
cifrado y auditoría
Control de acceso,
trazabilidad y protección
de datos.
Necesario para
información sensible de
salud.
Perspectiva de uso para pacientes de cualquier edad
El valor de la arquitectura propuesta se fortalece cuando se analiza desde la diversidad de usuarios. En
pacientes pediátricos, la disponibilidad de alertas locales y notificaciones a cuidadores resulta crítica
para eventos nocturnos o entornos escolares. En adolescentes, la experiencia móvil debe balancear
autonomía, privacidad y acompañamiento. En adultos, el sistema debe integrarse con rutinas laborales
y actividad física. En adultos mayores, la interfaz debe reducir carga cognitiva mediante iconografía
clara, mensajes breves, niveles de urgencia y opciones de accesibilidad.
pág. 2569
La propuesta no se limita a optimizar protocolos; plantea una arquitectura centrada en continuidad de
servicio y comprensión humana. Un valor de glucosa aislado puede no ser suficiente para actuar; en
cambio una alerta contextualizada, una flecha de tendencia, una explicación breve y un canal de apoyo
familiar o clínico pueden mejorar la oportunidad de respuesta. Esta perspectiva coincide con la
evolución del IoMT hacia sistemas de atención personalizados, remotos e interoperables (Huang et al.,
2023; Seth et al., 2025).
Aporte técnico y pertinencia de la propuesta
La principal aportación del artículo consiste en pasar de una arquitectura CGM funcional pero
centralizada a una arquitectura integral, resiliente y modular. El análisis por grafos aporta evidencia
formal para sostener que la concentración de rutas en smartphone y nube representa un riesgo operativo.
A partir de esa evidencia, el rediseño propuesto distribuye responsabilidades: el smartphone resuelve
alertas locales y continuidad inmediata; el middleware gestiona telemetría y seguridad de entrada; los
microservicios procesan lógica especializada y la capa clínica estandariza interoperabilidad.
En comparación con un modelo cloud-céntrico, la arquitectura edge-fog-cloud permite disminuir la
latencia de eventos críticos, preservar funcionamiento en zonas con baja cobertura, escalar por
componentes y mejorar la gobernanza de datos sensibles. Esta combinación resulta especialmente
pertinente en sistemas de diabetes, donde el tiempo de respuesta no es un atributo secundario sino una
condición de seguridad. En este sentido, la propuesta constituye, con base en el análisis arquitectónico
realizado, una opción técnica más sólida que una arquitectura monolítica dependiente de la nube.
La propuesta no elimina la necesidad de validaciones clínicas, regulatorias y de usabilidad; por el
contrario, las hace más factibles al separar responsabilidades y establecer trazabilidad. La arquitectura
sugerida puede evaluarse posteriormente mediante prototipos, pruebas de latencia, análisis de
disponibilidad, simulación de fallos, pruebas de seguridad y estudios de experiencia de usuario con
distintos grupos etarios. De esta manera, el diseño tecnológico se convierte en una base para
investigación aplicada en salud digital.
CONCLUSIONES
El monitoreo continuo de glucosa constituye un caso estratégico de aplicación del Internet de las Cosas
Médicas, ya que integra sensores corporales, aplicaciones móviles, conectividad, nube, analítica y
La propuesta no se limita a optimizar protocolos; plantea una arquitectura centrada en continuidad de
servicio y comprensión humana. Un valor de glucosa aislado puede no ser suficiente para actuar; en
cambio una alerta contextualizada, una flecha de tendencia, una explicación breve y un canal de apoyo
familiar o clínico pueden mejorar la oportunidad de respuesta. Esta perspectiva coincide con la
evolución del IoMT hacia sistemas de atención personalizados, remotos e interoperables (Huang et al.,
2023; Seth et al., 2025).
Aporte técnico y pertinencia de la propuesta
La principal aportación del artículo consiste en pasar de una arquitectura CGM funcional pero
centralizada a una arquitectura integral, resiliente y modular. El análisis por grafos aporta evidencia
formal para sostener que la concentración de rutas en smartphone y nube representa un riesgo operativo.
A partir de esa evidencia, el rediseño propuesto distribuye responsabilidades: el smartphone resuelve
alertas locales y continuidad inmediata; el middleware gestiona telemetría y seguridad de entrada; los
microservicios procesan lógica especializada y la capa clínica estandariza interoperabilidad.
En comparación con un modelo cloud-céntrico, la arquitectura edge-fog-cloud permite disminuir la
latencia de eventos críticos, preservar funcionamiento en zonas con baja cobertura, escalar por
componentes y mejorar la gobernanza de datos sensibles. Esta combinación resulta especialmente
pertinente en sistemas de diabetes, donde el tiempo de respuesta no es un atributo secundario sino una
condición de seguridad. En este sentido, la propuesta constituye, con base en el análisis arquitectónico
realizado, una opción técnica más sólida que una arquitectura monolítica dependiente de la nube.
La propuesta no elimina la necesidad de validaciones clínicas, regulatorias y de usabilidad; por el
contrario, las hace más factibles al separar responsabilidades y establecer trazabilidad. La arquitectura
sugerida puede evaluarse posteriormente mediante prototipos, pruebas de latencia, análisis de
disponibilidad, simulación de fallos, pruebas de seguridad y estudios de experiencia de usuario con
distintos grupos etarios. De esta manera, el diseño tecnológico se convierte en una base para
investigación aplicada en salud digital.
CONCLUSIONES
El monitoreo continuo de glucosa constituye un caso estratégico de aplicación del Internet de las Cosas
Médicas, ya que integra sensores corporales, aplicaciones móviles, conectividad, nube, analítica y
pág. 2570
participación de actores clínicos y familiares. Sin embargo, su potencial no depende solo de medir
glucosa con mayor frecuencia, sino de garantizar que el dato se convierta en información oportuna,
segura, interoperable y comprensible para el usuario final.
El análisis de la arquitectura actual permitió identificar que el smartphone del paciente y la plataforma
en la nube concentran rutas críticas del ecosistema. Al comportarse como nodos de alta centralidad y
posibles puntos únicos de fallo, estos componentes pueden afectar continuidad, alertas y acceso remoto
cuando existen fallas de batería, conectividad o disponibilidad de servicios. La teoría de grafos resultó
útil para justificar técnicamente esta vulnerabilidad y orientar el rediseño.
La arquitectura integral propuesta mejora la solución mediante edge analytics en el smartphone,
sincronización tolerante a fallos, middleware IoT, microservicios especializados, bases de datos de series
temporales, estándares de interoperabilidad clínica y seguridad multicapa. Esta combinación ofrece una
alternativa más robusta, escalable y mantenible que el modelo centralizado, particularmente para
pacientes de cualquier edad que requieren alertas confiables, seguimiento por cuidadores y continuidad
clínica.
Como trabajo futuro, se recomienda desarrollar un prototipo funcional de la arquitectura propuesta y
evaluarlo mediante indicadores de latencia, disponibilidad, pérdida de mensajes, consumo energético,
seguridad, interoperabilidad y experiencia de usuario. También será necesario someter la solución a
validación clínica y normativa antes de considerarla para escenarios asistenciales reales. La propuesta,
por tanto, constituye un marco técnico de alto nivel para avanzar hacia sistemas CGM más resilientes,
humanos y sostenibles dentro de la transformación digital en salud.
REFERENCIAS BIBLIOGRÁFICAS
Dhanumjaya, K., Kumar, I., Jayasrikrupaa, R., Karthika, V. R., Mudholkar, M., & Mudholkar, P. (2025).
Integration of IoT and cloud computing in smart diabetes management systems: A multidisciplinary
framework. Vascular and Endovascular Review, 8(7s), 205-211.
https://verjournal.com/index.php/ver/article/view/619?utm_source=chatgpt.com
Fernández-Caramés, T. M., Froiz-Míguez, I., Blanco-Novoa, Ó., & Fraga-Lamas, P. (2019). Enabling
the Internet of Mobile Crowdsourcing Health Things: A mobile fog computing, blockchain and IoT-
participación de actores clínicos y familiares. Sin embargo, su potencial no depende solo de medir
glucosa con mayor frecuencia, sino de garantizar que el dato se convierta en información oportuna,
segura, interoperable y comprensible para el usuario final.
El análisis de la arquitectura actual permitió identificar que el smartphone del paciente y la plataforma
en la nube concentran rutas críticas del ecosistema. Al comportarse como nodos de alta centralidad y
posibles puntos únicos de fallo, estos componentes pueden afectar continuidad, alertas y acceso remoto
cuando existen fallas de batería, conectividad o disponibilidad de servicios. La teoría de grafos resultó
útil para justificar técnicamente esta vulnerabilidad y orientar el rediseño.
La arquitectura integral propuesta mejora la solución mediante edge analytics en el smartphone,
sincronización tolerante a fallos, middleware IoT, microservicios especializados, bases de datos de series
temporales, estándares de interoperabilidad clínica y seguridad multicapa. Esta combinación ofrece una
alternativa más robusta, escalable y mantenible que el modelo centralizado, particularmente para
pacientes de cualquier edad que requieren alertas confiables, seguimiento por cuidadores y continuidad
clínica.
Como trabajo futuro, se recomienda desarrollar un prototipo funcional de la arquitectura propuesta y
evaluarlo mediante indicadores de latencia, disponibilidad, pérdida de mensajes, consumo energético,
seguridad, interoperabilidad y experiencia de usuario. También será necesario someter la solución a
validación clínica y normativa antes de considerarla para escenarios asistenciales reales. La propuesta,
por tanto, constituye un marco técnico de alto nivel para avanzar hacia sistemas CGM más resilientes,
humanos y sostenibles dentro de la transformación digital en salud.
REFERENCIAS BIBLIOGRÁFICAS
Dhanumjaya, K., Kumar, I., Jayasrikrupaa, R., Karthika, V. R., Mudholkar, M., & Mudholkar, P. (2025).
Integration of IoT and cloud computing in smart diabetes management systems: A multidisciplinary
framework. Vascular and Endovascular Review, 8(7s), 205-211.
https://verjournal.com/index.php/ver/article/view/619?utm_source=chatgpt.com
Fernández-Caramés, T. M., Froiz-Míguez, I., Blanco-Novoa, Ó., & Fraga-Lamas, P. (2019). Enabling
the Internet of Mobile Crowdsourcing Health Things: A mobile fog computing, blockchain and IoT-
pág. 2571
based continuous glucose monitoring system for diabetes mellitus research and care. Sensors,
19(15). Artículo 3319. https://doi.org/10.3390/s19153319
Gallo, G. D., & Micucci, D. (2025). Internet of Medical Things systems review: Insights into non-
functional factors. Sensors, 25(9), Artículo 2795. https://doi.org/10.3390/s25092795
Gia, T. N., Ali, M., Ben Dhaou, I., Rahmani, A. M., Westerlund, T., Liljeberg, P., & Tenhunen, H. (2017).
IoT-based continuous glucose monitoring system: A feasibility study. Procedia Computer Science,
109, 327-334. https://doi.org/10.1016/j.procs.2017.05.359
Gómez, C., Oller, J., & Paradells, J. (2012). Overview and evaluation of Bluetooth Low Energy: An
emerging low-power wireless technology. Sensors, 12(9), 11734-11753.
https://doi.org/10.3390/s120911734
Huang, C., Wang, J., Wang, S., & Zhang, Y. (2023). Internet of Medical Things: A systematic review.
Neurocomputing, 557, Artículo 126719. https://doi.org/10.1016/j.neucom.2023.126719
MQTT.org. (n.d.). FAQ. Consultado el 12 de enero de 2026, de. https://mqtt.org/faq/
OASIS. (2019). MQTT Version 5.0. OASIS standard. OASIS MQTT Technical Committee.
https://www.oasis-open.org/standard/mqtt-v5-0-os/
Omre, A. H., & Keeping, S. (2010). Bluetooth Low Energy: Wireless connectivity for medical
monitoring. Journal of Diabetes Science and Technology, 4(2), 457-463.
https://doi.org/10.1177/193229681000400227
Seth, M., Jalo, H., Högstedt, Å., Medin, O., Sjöqvist, B. A., & Candefjord, S. (2025). Technologies for
interoperable Internet of Medical Things platforms to manage medical emergencies in home and
prehospital care: Scoping review. Journal of Medical Internet Research, 27, e54470.
https://doi.org/10.2196/54470
based continuous glucose monitoring system for diabetes mellitus research and care. Sensors,
19(15). Artículo 3319. https://doi.org/10.3390/s19153319
Gallo, G. D., & Micucci, D. (2025). Internet of Medical Things systems review: Insights into non-
functional factors. Sensors, 25(9), Artículo 2795. https://doi.org/10.3390/s25092795
Gia, T. N., Ali, M., Ben Dhaou, I., Rahmani, A. M., Westerlund, T., Liljeberg, P., & Tenhunen, H. (2017).
IoT-based continuous glucose monitoring system: A feasibility study. Procedia Computer Science,
109, 327-334. https://doi.org/10.1016/j.procs.2017.05.359
Gómez, C., Oller, J., & Paradells, J. (2012). Overview and evaluation of Bluetooth Low Energy: An
emerging low-power wireless technology. Sensors, 12(9), 11734-11753.
https://doi.org/10.3390/s120911734
Huang, C., Wang, J., Wang, S., & Zhang, Y. (2023). Internet of Medical Things: A systematic review.
Neurocomputing, 557, Artículo 126719. https://doi.org/10.1016/j.neucom.2023.126719
MQTT.org. (n.d.). FAQ. Consultado el 12 de enero de 2026, de. https://mqtt.org/faq/
OASIS. (2019). MQTT Version 5.0. OASIS standard. OASIS MQTT Technical Committee.
https://www.oasis-open.org/standard/mqtt-v5-0-os/
Omre, A. H., & Keeping, S. (2010). Bluetooth Low Energy: Wireless connectivity for medical
monitoring. Journal of Diabetes Science and Technology, 4(2), 457-463.
https://doi.org/10.1177/193229681000400227
Seth, M., Jalo, H., Högstedt, Å., Medin, O., Sjöqvist, B. A., & Candefjord, S. (2025). Technologies for
interoperable Internet of Medical Things platforms to manage medical emergencies in home and
prehospital care: Scoping review. Journal of Medical Internet Research, 27, e54470.
https://doi.org/10.2196/54470