La tendance FHIR est toujours appelée à dominer en 2024. Les règles de l'ONC représentent un véritable défi pour les fournisseurs, car ils doivent offrir une API HL7® FHIR avec prise en charge de SMART on FHIR pour chaque client.
De nombreux fournisseurs de DSÉ se posent encore des questions sur la façon de réduire le fardeau lié à la gestion d'autant de serveurs FHIR. La réponse est simple : la multilocation est toujours la bonne solution. Dans cet article, vous trouverez les réponses aux questions suivantes :
- Qu'est-ce que la multilocation? Quels en sont les avantages?
- Comment construire une API FHIR multi-locataires?
- Comment intégrer une API FHIR à votre solution DSÉ existante?
Qu'est-ce que la multilocation?
La multilocation est un avantage clé des systèmes ERP SaaS. En bref, il s'agit d'une façon de fournir des ressources partagées à plusieurs clients (locataires), chaque client disposant de son propre environnement dédié.
Les locataires sont isolés les uns des autres, ce qui signifie que les données de l'un ne seront en aucun cas visibles par un autre. Les utilisateurs peuvent accéder à leurs propres données sans porter atteinte à la vie privée ou aux données des autres locataires.
Cela en fait une option attrayante pour les entreprises qui doivent partager des ressources entre plusieurs utilisateurs tout en maintenant la confidentialité et la sécurité des données individuelles.
Cependant, lorsqu'on aborde la multilocation, l'isolation physique doit également être prise en considération. Le degré d'isolation physique est flexible et peut aller d'une séparation physique complète à un espace d'hébergement partagé où chaque locataire dispose de son propre espace de plateforme unique.
Le degré d'isolation physique entre les différents locataires est déterminé par la technologie sous-jacente, mais il doit généralement assurer une isolation logique complète pour garantir que les données de chaque locataire demeurent sécurisées (Gartner).
Quels avantages obtenez-vous avec la multilocation?
Examinons maintenant les avantages de la multilocation pour les fournisseurs de DSÉ et autres services de plateforme :
- Réduire les coûts opérationnels : Tout comme il est moins coûteux de partager un trajet avec d'autres personnes, il est moins coûteux de partager des ressources infonuagiques. Vous obtenez ainsi de nombreux serveurs FHIR pour le prix d'un seul.
- Évoluer facilement : Les clients ont la possibilité d'ajouter ou de supprimer des ressources. Cette adaptabilité est idéale pour les entreprises connaissant une croissance rapide mais imprévisible.
- Assurer la sécurité de vos données : Bien que les solutions à locataire unique soient plus sécurisées, la multilocation est néanmoins plus efficace pour identifier les menaces et isoler les ressources des locataires.
Cela dit, aucune solution n'est parfaite. Du point de vue de l'hôte, la multilocation est plus complexe qu'une solution à locataire unique. Nous ne nous arrêtons pas à la théorie, alors continuez à lire!
Commencez avec le serveur FHIR Aidbox pour le stockage de données, les intégrations, l'analytique de santé et bien plus encore, ou engagez notre équipe pour répondre à vos besoins en développement logiciel.
Qu'en est-il de FHIR?
FHIR ne prend pas en charge la multilocation au niveau de la spécification. En fait, il n'en a pas besoin. Cependant, de nombreux serveurs FHIR comme Aidbox tirent le meilleur des deux mondes : FHIR et l'architecture multi-locataires. En savoir plus sur la multilocation dans la documentation Aidbox.
La multilocation est une question de décisions architecturales internes. FHIR expose le FHIR_BASE_URL pour rendre la fonctionnalité accessible à d'autres. Chacun de vos clients doit obtenir son propre FHIR_BASE_URL. Nous expliquerons cela plus en détail par la suite.
Mise en œuvre de la multilocation
Nous allons ici explorer quelques techniques qui peuvent vous aider à construire une solution hautement partagée. Cela va encore plus loin en vous permettant de migrer vers un niveau inférieur de multilocation à la demande, dans le cas où certains clients auraient besoin de ressources plus dédiées. Pour la mettre en œuvre, nous devons examiner quelques étapes clés :
- Rendre les locataires explicites;
- Marquer les données avec un identifiant de locataire afin qu'elles appartiennent à un locataire spécifique;
- Enrichir le
FHIR_BASE_URLavec l'identifiant du locataire; - Enrichir le
AUTH_SERVER_BASE_URLavec l'identifiant du locataire.
À la fin du processus, votre client aura une grande confiance en son isolation totale au niveau des données et de l'API, ce qui sera justifié.
Rendre les locataires explicites
Définir explicitement les locataires est crucial pour deux raisons importantes :
- Vous voudrez inévitablement savoir quels locataires se trouvent dans votre système;
- Vous voudrez éventuellement effectuer des personnalisations pour eux.
Les ressources de locataires explicites constituent un bon endroit pour les suivre et saisir des configurations personnalisées spécifiques. Vous pouvez envisager d'introduire des ressources supplémentaires :
id: my-clinic resource Type: Tenant name: My Clinic
Les données appartiennent au locataire
C'est la raison pour laquelle nous optons pour la multilocation. Je suggère de faire du locataire une propriété explicite de chaque ressource. Cela ouvrira un vaste espace où vous pourrez stocker des données, et vous permettra également d'effectuer des migrations et de faire évoluer votre infrastructure pour répondre aux exigences de performance au fur et à mesure de leur croissance.
La location est une métapropriété, alors prenons Aidbox comme exemple et voyons comment nous la stockons sous le champ meta dans les ressources FHIR.
Format Aidbox meta: tenant: id: my-clinic resourceType: Tenant
Format FHIR meta: extension:
- url: https://aidbox.app/tenant-id valueReference reference: Tenant/my-clinic
Il s'agit d'une représentation externe. En ce qui concerne la représentation interne, nous pouvons commencer par une approche simple d'un point de vue infrastructurel. Nous pouvons stocker les données dans une seule base de données et une seule table par type de ressource.
La seule contrainte importante que je constate est que vous devrez implémenter le filtrage par locataire au niveau de l'application, ce qui est un coût raisonnable pour maintenir votre infrastructure aussi simple que possible.
Si un locataire a besoin de plus de ressources, génère une charge importante et affecte les autres locataires, vous pouvez toujours migrer ses données vers une autre base de données et exécuter une instance dédiée de la même application pour ce locataire.
L'URL de base FHIR doit contenir l'identifiant du locataire
Lorsque tous vos clients disposent d'une API FHIR dédiée, vous devez leur fournir un FHIR_BASE_URL différent sur lequel leur serveur FHIR virtuel fonctionnera. Il y a deux façons de procéder :
- Vous pouvez inclure l'identifiant du locataire dans le nom de domaine, comme
my-clinic.aidbox.app/fhir-api; - L'identifiant du locataire peut apparaître dans le chemin de l'URL, p. ex.
aidbox.app/tenant/my-clinic/fhir-api.
Les deux options sont acceptables, bien que la première semble plus précise et plus claire.
Si vous avez un accès complet à votre domaine et pouvez réserver des sous-domaines pour vos locataires, vous pouvez envisager d'inclure l'identifiant du locataire dans le nom de domaine. Votre application doit également être capable de fonctionner avec différents domaines dans la même instance, ce qu'elle fait généralement.
Avoir l'identifiant du locataire dans le chemin de l'URL est également acceptable. Cela ne vous oblige pas à sacrifier autant de noms de domaine, même si vous n'y avez pas accès. L'API FHIR implémente le style REST, et l'API REST n'attend aucune session entre les requêtes, ce qui signifie pas de témoins de connexion de navigateur.
L'authentification doit appartenir au locataire
Nous disposons maintenant d'une API FHIR dédiée pour chaque client, et les données dans le stockage appartiennent également aux locataires. La touche finale est de dédier le serveur d'authentification. Pourquoi cela? Vous pourriez vous demander s'il est possible d'avoir un seul serveur d'authentification. Je crois que non, et voici pourquoi.
Supposons qu'un utilisateur ait un compte dans deux locataires différents. Que se passe-t-il alors? Cet utilisateur peut-il être simultanément connecté aux deux locataires? Techniquement, oui. Google en est un bon exemple. Vous pouvez utiliser les services Google et passer d'un compte à l'autre en quelques clics. Mais est-ce l'expérience utilisateur que vous recherchez? Je crois que non. Il y a deux raisons à cela :
- Vos utilisateurs devront choisir leur compte chaque fois qu'ils interagiront avec l'un de vos locataires, même s'ils n'ont qu'un seul compte (vous ne pouvez pas être certain qu'ils n'ont pas d'autres comptes et vous devrez demander chaque fois qu'ils souhaitent interagir avec votre API FHIR);
- Sachant que vous avez différents locataires, vos utilisateurs pourraient théoriquement interagir avec des fuites externes. Notre objectif est une isolation complète du côté de l'utilisateur.
Mais cela ne s'arrête pas là, car le serveur d'authentification doit également être multi-locataires. Cela peut être réalisé en suivant la même méthode que celle utilisée pour séparer les API FHIR des locataires : un AUTH_BASE_URL dédié. Peu importe si l'identifiant du locataire apparaît dans le nom de domaine ou dans le chemin de l'URL. La seule chose qui importe est que les locataires puissent être simultanément connectés à tous vos serveurs d'authentification et interagir avec vos serveurs FHIR en tant qu'entités indépendantes.
Conclusion
Il y a quatre étapes simples pour atteindre la multilocation :
- Rendez votre locataire explicite et de premier rang;
- Enregistrez un lien vers le locataire dans chaque ressource;
- Injectez l'identifiant du locataire dans une URL de base FHIR;
- Rendez votre serveur d'authentification multi-locataires également.
Une fois ces quatre étapes simples appliquées, vous serez en mesure de créer un serveur FHIR sans coûts d'infrastructure supplémentaires, car il vous suffit de créer une ressource Tenant et un serveur FHIR virtuel, ce qui signifie que le serveur d'authentification sera déjà déployé pour celui-ci.
Si certains de vos locataires dépassent leur allocation, vous pouvez facilement dédier un niveau d'isolation plus élevé. Il vous suffit de :
- déployer la même application sur un autre serveur;
- migrer les données du locataire;
- rediriger les requêtes vers la nouvelle application.
Mise à jour : Contrôle d'accès hiérarchique amélioré basé sur l'organisation
Nous avons récemment amélioré le système en ajoutant un contrôle d'accès hiérarchique basé sur l'organisation. Cette nouvelle fonctionnalité permet une gestion plus flexible et précise des accès aux données selon la hiérarchie organisationnelle. Les administrateurs peuvent désormais définir des autorisations d'accès à différents niveaux organisationnels, s'assurant que les utilisateurs ne voient que les données qu'ils sont autorisés à consulter. Cette amélioration renforce considérablement la sécurité et la gestion du système, en particulier dans les grandes organisations aux structures complexes. Des informations détaillées sur la nouvelle fonctionnalité se trouvent dans la documentation Aidbox.
Pour explorer la mise en œuvre d'une API FHIR multi-locataires dans votre système DSÉ, envisagez d'utiliser la version gratuite d'Aidbox. Elle fournit un environnement robuste pour tester et développer ces capacités, offrant tous les outils nécessaires sans aucune limitation de fonctionnalités.
Auteur : Vlad Ganshin, ingénieur logiciel chez Health Samurai
Si vous cherchez une API FHIR multi-locataires qui vous propulsera en 2024 et au-delà, essayez le module API FHIR Aidbox certifié par l'ONC dès aujourd'hui.
Voir aussi : Pourquoi vous avez besoin d'un serveur FHIR indépendant.
