---
{
  "title": "Suscripciones en Aidbox: Una visión completa de la integración de datos, desafíos y soluciones",
  "description": "Descubra cómo las suscripciones simplifican la gestión de datos con flujos de trabajo automatizados y basados en eventos. Mejoran la coordinación asistencial, la toma de decisiones y optimizan procesos como la sincronización de datos y la automatización. Además, Aidbox ofrece soluciones fiables y escalables tanto para sistemas sencillos como de alta carga.",
  "date": "2024-09-19",
  "author": "Marat Surmashev",
  "reading-time": "8 min read",
  "tags": [
    "Integrations",
    "Aidbox"
  ]
}
---

> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt).
> Use it to discover all available pages before guessing URLs.

---
Las suscripciones ofrecen una forma estandarizada de establecer flujos de datos automatizados y basados en eventos, lo que permite mantenerse informado sobre los cambios importantes en los datos. Esta capacidad abre nuevas posibilidades para mejorar la coordinación asistencial, potenciar el soporte a la decisión clínica y optimizar los flujos de trabajo en todo el ecosistema sanitario.

Casos de uso habituales de las suscripciones:
- **Replicación de datos:** Propagación automática de cambios en los datos hacia servicios basados en colas o mensajería.
- **Agregación de datos:** Recopilación y centralización de datos procedentes de múltiples fuentes de servidores FHIR en un Repositorio Clínico de Datos (CDR) central.
- **Replicación de datos hacia sistemas analíticos:** Envío de datos a sistemas externos para análisis o generación de informes.
- **Automatización de flujos de trabajo:** Activación de flujos de trabajo en función de condiciones específicas.
- **Extensión y personalización del sistema:** Amplíe la funcionalidad de su sistema existente. Por ejemplo, un recurso *Task* puede crearse automáticamente cuando se crea un *Appointment*.
- **Notificaciones específicas para el usuario:** Permite que los usuarios finales se suscriban a eventos concretos, como recibir un correo electrónico cuando se cancela un *Appointment*.

## Objetivos clave para la implementación de suscripciones

Al implementar suscripciones, deben abordarse tres objetivos fundamentales:
- **Gestión de eventos:** Captura eficiente de cambios a nivel de aplicación o de base de datos.
- **Condiciones de carrera:** Garantizar que los eventos se procesen correctamente para evitar incoherencias.
- **Garantías de entrega:** Asegurar la entrega de eventos para garantizar la fiabilidad de los datos.

## Gestión de eventos: captura a nivel de aplicación y de base de datos

#### Captura a nivel de aplicación
Este enfoque implica capturar eventos únicamente a través de la API en la capa de aplicación. Aunque es más sencillo de implementar, no captura migraciones de datos ni ingestas masivas de datos a nivel de base de datos. Esto puede provocar la pérdida de eventos si se producen actualizaciones de datos a gran escala fuera de la API de la aplicación.

#### Captura a nivel de base de datos
Este enfoque captura todos los cambios posibles directamente desde la base de datos, ofreciendo una solución más completa. Sin embargo, es más complejo y costoso de implementar y mantener. Además, el filtrado granular de eventos puede resultar complicado y puede requerir un posprocesamiento para eliminar eventos innecesarios.

## Condiciones de carrera

Mantener el orden correcto de los eventos es fundamental, especialmente en escenarios donde pueden producirse actualizaciones concurrentes. Consideremos una situación en la que dos solicitudes concurrentes actualizan el mismo *Appointment*:

- *Request_A* establece *Appointment.status: 'canceled'*

- *Request_B* establece *Appointment.status: 'pending'*

Si los eventos se gestionan a nivel de aplicación en hilos separados o en diferentes instancias de la aplicación, los eventos podrían procesarse fuera de orden. Por ejemplo, la secuencia de eventos podría aparecer como: *status = pending,* *status = canceled.*

Sin embargo, el orden real de confirmación en la base de datos podría ser *status = canceled*, *status = pending*.

Como resultado, el estado final de la base de datos muestra *pending*, pero el último evento procesado por el suscriptor muestra *canceled*.

Para resolver este problema, existen las siguientes opciones:

#### Ejecución en hilo único e instancia única
Esto puede ser viable para aplicaciones con cargas de trabajo mínimas, pero no es una solución escalable. Los sistemas de alto rendimiento suelen requerir configuraciones de múltiples hilos y múltiples réplicas para garantizar el rendimiento y la alta disponibilidad.

#### Bloqueo optimista
Utilice el bloqueo optimista con la cabecera FHIR `If-None-Match: W/"[ETag]"` para gestionar las actualizaciones. Sin embargo, esto suele resultar inconveniente e impracticable, especialmente cuando no es posible modificar la solicitud original.

#### Serialización a nivel de base de datos
Utilice mecanismos a nivel de base de datos para garantizar la serialización de eventos. Por ejemplo, en PostgreSQL, un slot de replicación puede garantizar que todos los eventos se procesen secuencialmente en orden de confirmación. Sin embargo, este enfoque presenta inconvenientes significativos, como cuellos de botella en el rendimiento bajo cargas de trabajo elevadas, ya que el slot de replicación solo puede ser leído por un hilo. Además, mantener esta configuración puede resultar complejo.

## Garantías de entrega

Existen tres niveles de garantías de entrega que deben tenerse en cuenta al implementar suscripciones:

#### Como máximo una vez (At Most Once)
Los eventos se envían sin requerir confirmación de recepción. Este enfoque es adecuado en escenarios donde los eventos se generan a una tasa elevada y es necesario minimizar el consumo de recursos.

#### Al menos una vez (At Least Once)
Este enfoque garantiza que cada evento se entregará al menos una vez, incluso en caso de fallos, aunque pueden producirse duplicados. Es adecuado para operaciones críticas, como cambios de datos a nivel de sistema donde la fiabilidad es esencial, pero los duplicados deben gestionarse en el lado receptor.

#### Exactamente una vez (Exactly Once)
En este modelo, el sistema garantiza que cada evento se entrega exactamente una vez, asegurando tanto la fiabilidad como la ausencia de duplicados. Este nivel de garantía requiere soporte tanto en los sistemas emisor como receptor y puede ser más costoso en recursos para su implementación.

## Capacidades de Aidbox

La [Plataforma FHIR de Aidbox](https://www.health-samurai.io/aidbox) ofrece varias implementaciones de suscripciones:

| Implementación | Gestión de eventos | Condición de carrera | Garantía | Canal |
| --- | --- | --- | --- | --- |
| [Aidbox Subscriptions](https://www.health-samurai.io/docs/aidbox/api-1/reactive-api-and-subscriptions/subscriptions-1) | Aplicación | Posible | At most once | Webhook |
| [FHIR topic-based Subscriptions](https://www.health-samurai.io/docs/aidbox/modules-1/topic-based-subscriptions/topic-based-subscriptions) | Base de datos | No posible | At least once | Webhook |
| [Aidbox topic-based Subscriptions](https://www.health-samurai.io/docs/aidbox/modules-1/topic-based-subscriptions/wip-dynamic-subscriptiontopic-with-destinations) | Aplicación | Posible | At least once At most once | Kafka Webhook (próximamente) |

> 
[Aidbox Subscriptions](https://www.health-samurai.io/docs/aidbox/api-1/reactive-api-and-subscriptions/subscriptions-1) — La mejor opción para interacciones sencillas y no críticas entre servicios.

- Fácil de usar con una configuración mínima.

- La ausencia de garantías estrictas de entrega es adecuada cuando la pérdida de mensajes es aceptable.

- Ideal para sistemas ligeros donde la simplicidad es prioritaria.

> 
[FHIR topic-based subscriptions](https://www.health-samurai.io/docs/aidbox/modules-1/topic-based-subscriptions/topic-based-subscriptions) — La mejor opción para sistemas que tienen requisitos exigentes de consistencia y entrega, pero que no operan bajo cargas de trabajo elevadas.

- Conforme con FHIR.

- Sin condiciones de carrera y con garantías de entrega.

> 
[Aidbox topic-based subscriptions](https://www.health-samurai.io/docs/aidbox/modules-1/topic-based-subscriptions/wip-dynamic-subscriptiontopic-with-destinations) — La mejor opción para sistemas de alta carga que requieren escalabilidad y garantías de entrega.

- Se integra con Kafka para mensajería de alto rendimiento.

- Mantiene un alto rendimiento bajo cargas elevadas.

- Fundamental para aplicaciones donde la pérdida de datos es inaceptable.

Ejemplos
- Demo de Aidbox [topic-based subscriptions](/blog/topic-based-subscriptions-top-5-use-cases-for-digital-health) — [https://github.com/Aidbox/examples](https://github.com/Aidbox/examples)
- FHIR topic-based subscriptions — [https://github.com/Aidbox/aidbox-project-template/tree/topic-based-subscription-r4b-fhir-schema-mode](https://github.com/Aidbox/aidbox-project-template/tree/topic-based-subscription-r4b-fhir-schema-mode)[
](https://github.com/Aidbox/aidbox-project-template/tree/topic-based-subscription-r4b-fhir-schema-mode)

## El futuro de las suscripciones en Aidbox

Las [Aidbox Topic-based Subscriptions](https://www.health-samurai.io/docs/aidbox/modules-1/topic-based-subscriptions/wip-dynamic-subscriptiontopic-with-destinations) se están convirtiendo en la solución de referencia para notificaciones y actualizaciones en tiempo real en aplicaciones sanitarias, proporcionando una combinación ideal de simplicidad, escalabilidad y fiabilidad.

Nos dedicamos a mejorar continuamente las Aidbox Topic-Based Subscriptions ampliando AidboxTopicDestination para dar soporte a canales adicionales como webhooks, RabbitMQ, Amazon SNS y más. También estamos trabajando en una API de Eventos (o Mensajes), similar a Amazon SNS, para ofrecer una flexibilidad aún mayor para sus necesidades de integración.

> [Póngase en contacto con nosotros](https://www.health-samurai.io/contacts) con sus casos de uso y requisitos, o comience a utilizar las Aidbox topic-based subscriptions de forma gratuita con [nuestras licencias de desarrollo](https://aidbox.app/ui/portal#/signin).

*Autor*: 
[**Marat Surmashev**](https://www.linkedin.com/in/marat-surmashev-1b852b59/?originalSubdomain=me), 
VP de Ingeniería en Health Samurai

Véase también: [Gestión de datos multi-clínica con OrgBAC](/blog/managing-multi-clinic-data-and-real-time-synchronization-with-orgbac-and-subscriptions).