Les abonnements offrent une façon normalisée d'établir des flux de données automatisés et pilotés par événements, permettant de rester informé des changements importants dans les données. Cette capacité ouvre de nouvelles possibilités pour améliorer la coordination des soins, renforcer l'aide à la décision clinique et rationaliser les flux de travail dans l'ensemble de l'écosystème de santé.
Cas d'utilisation courants des abonnements :
- Réplication des données : Propager automatiquement les modifications de données vers des services de file d'attente ou de messagerie.
- Agrégation des données : Collecter et centraliser les données provenant de plusieurs sources de serveurs FHIR dans un dépôt de données cliniques (CDR) central.
- Réplication des données vers des systèmes analytiques : Transmettre les données à des systèmes externes à des fins d'analyse ou de production de rapports.
- Automatisation des flux de travail : Déclencher des flux de travail en fonction de conditions spécifiques.
- Extension et personnalisation du système : Étendre les fonctionnalités de votre système existant. Par exemple, une ressource Task peut être créée automatiquement lorsqu'un Appointment est créé.
- Notifications propres à l'utilisateur : Permettre aux utilisateurs finaux de s'abonner à des événements spécifiques, comme recevoir un courriel lorsqu'un Appointment est annulé.
Objectifs clés de la mise en œuvre des abonnements
Lors de la mise en œuvre des abonnements, trois objectifs fondamentaux doivent être pris en compte :
- Gestion des événements : Capturer efficacement les changements au niveau de l'application ou de la base de données.
- Conditions de course : S'assurer que les événements sont traités correctement pour éviter les incohérences.
- Garanties de livraison : Garantir la livraison des événements pour assurer la fiabilité des données.
Gestion des événements : capture au niveau de l'application et de la base de données
Capture au niveau de l'application
Cette approche consiste à capturer les événements uniquement via l'API au niveau de la couche applicative. Bien qu'elle soit plus simple à mettre en œuvre, cette approche ne capture pas les migrations de données ni l'ingestion de données en masse au niveau de la base de données. Cela peut entraîner des événements manqués si des mises à jour de données à grande échelle surviennent en dehors de l'API de l'application.
Capture au niveau de la base de données
Cette approche capture tous les changements possibles directement depuis la base de données, offrant une solution plus complète. Cependant, elle est plus complexe et coûteuse à mettre en œuvre et à maintenir. De plus, le filtrage granulaire des événements peut s'avérer difficile et nécessiter un post-traitement pour éliminer les événements superflus.
Conditions de course
Maintenir le bon ordre des événements est essentiel, surtout dans les scénarios où des mises à jour concurrentes peuvent survenir. Considérons une situation où deux requêtes concurrentes mettent à jour le même Appointment :
-
Request_A définit Appointment.status: 'canceled'
-
Request_B définit Appointment.status: 'pending'
Si les événements sont traités au niveau de l'application dans des fils d'exécution distincts ou sur différentes instances de l'application, les événements pourraient être traités dans le désordre. Par exemple, la séquence d'événements pourrait apparaître comme suit : status = pending, status = canceled.
Cependant, l'ordre réel de validation dans la base de données pourrait être status = canceled, status = pending.
En conséquence, l'état final de la base de données affiche pending, mais le dernier événement traité par l'abonné affiche canceled.
Pour résoudre ce problème, les options suivantes sont disponibles :
Exécution mono-thread et mono-instance
Cette approche peut être envisageable pour les applications à faible charge, mais ce n'est pas une solution évolutive. Les systèmes à haute performance nécessitent généralement des configurations multi-threads et multi-répliques pour la performance et la haute disponibilité.
Verrouillage optimiste
Utiliser le verrouillage optimiste avec l'en-tête FHIR If-None-Match: W/"[ETag]" pour gérer les mises à jour. Cependant, cette approche est souvent peu pratique, surtout lorsqu'il est impossible de modifier la requête d'origine.
Sérialisation au niveau de la base de données
Utiliser des mécanismes au niveau de la base de données pour assurer la sérialisation des événements. Par exemple, dans PostgreSQL, un slot de réplication peut garantir que tous les événements sont traités de manière séquentielle dans l'ordre de validation. Cependant, cette approche présente des inconvénients importants, notamment des goulots d'étranglement de performance sous de fortes charges, car le slot de réplication ne peut être lu que par un seul fil d'exécution. De plus, la maintenance de cette configuration peut s'avérer complexe.
Garanties de livraison
Il existe trois niveaux de garanties de livraison à prendre en compte lors de la mise en œuvre des abonnements :
Au plus une fois
Les événements sont envoyés sans exiger d'accusé de réception. Cette approche convient aux scénarios où les événements sont générés à un rythme élevé et où l'utilisation des ressources doit être minimisée.
Au moins une fois
Cette approche garantit que chaque événement sera livré au moins une fois, même en cas de défaillance, bien que des doublons puissent survenir. Elle convient aux opérations critiques, comme les modifications de données au niveau du système où la fiabilité est essentielle, mais les doublons doivent être gérés du côté récepteur.
Exactement une fois
Dans ce modèle, le système garantit que chaque événement est livré exactement une fois, assurant à la fois la fiabilité et l'absence de doublons. Ce niveau de garantie nécessite une prise en charge aussi bien du côté émetteur que récepteur et peut être plus gourmand en ressources à mettre en œuvre.
Capacités d'Aidbox
La plateforme FHIR Aidbox propose plusieurs mises en œuvre des abonnements :
| Mise en œuvre | Gestion des événements | Condition de course | Garantie | Canal |
|---|---|---|---|---|
| Abonnements Aidbox | Application | Possible | Au plus une fois | Webhook |
| Abonnements FHIR basés sur les sujets | Base de données | Non possible | Au moins une fois | Webhook |
| Abonnements Aidbox basés sur les sujets | Application | Possible | Au moins une fois Au plus une fois | Kafka Webhook (à venir) |
Abonnements Aidbox — Idéal pour les interactions simples et non critiques entre les services.
-
Facile à utiliser avec une configuration minimale.
-
Aucune garantie de livraison stricte, approprié lorsque la perte de messages est acceptable.
-
Idéal pour les systèmes légers où la simplicité est une priorité.
Abonnements FHIR basés sur les sujets — Idéal pour les systèmes ayant des exigences sérieuses en matière de cohérence et de livraison, mais qui ne fonctionnent pas sous de fortes charges.
-
Conforme à FHIR.
-
Aucune condition de course avec des garanties de livraison.
Abonnements Aidbox basés sur les sujets — Idéal pour les systèmes à forte charge nécessitant évolutivité et garanties de livraison.
-
S'intègre à Kafka pour une messagerie à haut débit.
-
Maintient des performances élevées sous forte charge.
-
Essentiel pour les applications où la perte de données est inacceptable.
Exemples
- Démo des abonnements Aidbox basés sur les sujets — https://github.com/Aidbox/examples
- Abonnements FHIR basés sur les sujets — https://github.com/Aidbox/aidbox-project-template/tree/topic-based-subscription-r4b-fhir-schema-mode
L'avenir des abonnements Aidbox
Les abonnements Aidbox basés sur les sujets s'imposent comme la solution de référence pour les notifications et mises à jour en temps réel dans les applications de santé, offrant un équilibre idéal entre simplicité, évolutivité et fiabilité.
Nous nous engageons à améliorer continuellement les abonnements Aidbox basés sur les sujets en élargissant AidboxTopicDestination pour prendre en charge des canaux supplémentaires tels que les webhooks, RabbitMQ, Amazon SNS, et plus encore. Nous travaillons également sur une API d'événements (ou de messages), similaire à Amazon SNS, afin d'offrir une flexibilité encore plus grande pour vos besoins d'intégration.
Communiquez avec nous pour nous faire part de vos cas d'utilisation et de vos exigences, ou commencez à utiliser les abonnements Aidbox basés sur les sujets gratuitement avec nos licences de développement.
Auteur : Marat Surmashev, VP Ingénierie chez Health Samurai
Voir aussi : Gestion des données multi-cliniques avec OrgBAC.
