--- { "title": "Comment concevoir une API FHIR multi-locataire pour un système DSE existant", "description": "Explorez des moyens de réduire les coûts de conception à l'aide d'une API FHIR multi-locataire avec prise en charge de SMART on FHIR et conformez-vous au 21st Century Cures Act pour les systèmes DSE à la volée.", "date": "2024-07-08", "author": "Vlad Ganshin", "reading-time": "7 min read", "tags": [ "System Design", "Infrastructure", "Compliance" ], "seo-tags": [ "multitenancy", "fhir", "aidbox" ] } --- La tendance FHIR est toujours appelée à dominer en 2024. [Les règles de l'ONC](https://www.health-samurai.io/aidbox/resources/standardized-api-for-ehr-cheatsheet) représentent un défi de taille pour les fournisseurs, qui doivent offrir une API HL7® FHIR avec prise en charge de SMART on FHIR pour chaque client. De nombreux fournisseurs de DSE ont encore des questions sur la façon de réduire le fardeau lié à la gestion d'autant de [serveurs FHIR](https://www.health-samurai.io/fhir-server). 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-locataire](/blog/managing-multi-clinic-data-and-real-time-synchronization-with-orgbac-and-subscriptions)? - Comment connecter une API FHIR à votre solution DSE existante? ![](image-1.avif) ## Qu'est-ce que la multilocation? La multilocation est un avantage clé des systèmes ERP en mode 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 visibles par un autre d'aucune façon. Les utilisateurs peuvent accéder à leurs propres données sans empiéter sur la vie privée ou les 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 parle de 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 restent sécurisées ([**Gartner**](https://www.gartner.com/en/information-technology/glossary/multitenancy)). [![](image-2.avif)](https://www.health-samurai.io/docs/aidbox/modules-1/security-and-access-control/security/multitenancy) ## Quels avantages obtenez-vous avec la multilocation? Examinons maintenant les avantages de la multilocation pour les fournisseurs de DSE 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](https://www.health-samurai.io/fhir-server) pour le prix d'un seul. - **Évoluer facilement :** Les clients ont la possibilité d'ajouter ou de retirer des ressources. Cette adaptabilité est idéale pour les entreprises connaissant une croissance rapide mais imprévisible. - **Garder vos données sécurisées :** Bien que la location unique soit plus sécurisée, la multilocation est tout de même 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 que la location unique. Nous ne nous arrêtons pas à la théorie, alors continuez à lire! > Commencez avec le [serveur FHIR](https://www.health-samurai.io/aidbox) Aidbox pour le stockage de données, les intégrations, l'analytique en santé et plus encore, ou [faites appel à notre équipe](https://www.health-samurai.io/services) pour répondre à vos besoins en développement logiciel. ## Et FHIR dans tout ça? FHIR ne prend pas en charge la multilocation au niveau des spécifications. En fait, il n'en a pas besoin. Cependant, de nombreux [serveurs FHIR](https://www.health-samurai.io/fhir-server) comme [**Aidbox**](https://www.health-samurai.io/aidbox) tirent le meilleur des deux mondes : FHIR et l'architecture multi-locataire. [*En savoir plus sur la multilocation dans la documentation Aidbox*](https://www.health-samurai.io/docs/aidbox/modules-1/security-and-access-control/security/multitenancy). La multilocation est une question de décisions architecturales internes. FHIR expose `FHIR_BASE_URL` pour rendre la fonctionnalité disponible aux autres. Chacun de vos clients devrait obtenir sa propre `FHIR_BASE_URL`. Nous expliquerons cela plus en détail ultérieurement. ![](image-3.avif) ## Mise en œuvre de la multilocation Nous allons explorer ici quelques techniques qui peuvent vous aider à construire une solution hautement partagée. Elle permet également 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 `FHIR_BASE_URL` avec l'identifiant du locataire; - Enrichir `AUTH_SERVER_BASE_URL` avec l'identifiant du locataire. À la fin du processus, votre client aura la pleine assurance de 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; - Tôt ou tard, vous voudrez effectuer des personnalisations pour eux. Les ressources de locataires explicites constituent un bon endroit pour les suivre et y 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 ![](image-4.avif) ## 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 grand 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 qu'elles augmentent. La location est une méta-propriété, alors prenons [**Aidbox**](https://www.health-samurai.io/fhir-api) comme exemple et voyons comment nous la stockons dans le champ `meta` des ressources FHIR. > # Aidbox format meta: tenant: id: my-clinic resourceType: Tenant > # FHIR format meta: extension: - url: valueReference reference: Tenant/my-clinic Il s'agit d'une représentation externe. Pour ce qui est de 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 perçois est que vous devrez mettre en œuvre un **filtrage par locataire au niveau de l'application**, ce qui représente un coût assez raisonnable pour maintenir votre infrastructure aussi simple que possible. Dans le cas où un locataire nécessite 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. [![](image-5.avif)](https://www.health-samurai.io/articles/aidbox-hipaa-book-technical-safeguards) ## 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 une `FHIR_BASE_URL` différente sur laquelle leur serveur FHIR virtuel fonctionnera. Il existe deux façons de procéder : - Vous pouvez placer 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, par exemple `aidbox.app/tenant/my-clinic/fhir-api`. Les deux options sont acceptables, bien que la première soit 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 de placer 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**](https://www.health-samurai.io/docs/aidbox/api-1/fhir-api) met en œuvre le style REST, et l'[**API REST**](https://www.health-samurai.io/docs/aidbox/api-1/api) n'attend aucune session entre les requêtes, ce qui signifie qu'il n'y a pas de témoins de connexion (cookies) dans le 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? Vous vous demandez peut-être s'il est possible d'avoir un seul serveur d'authentification. Je crois que non, et voici pourquoi. Supposons qu'un utilisateur possède 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 travaillent 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 lui aussi être multi-locataire. Cela peut être réalisé en suivant la même méthode que celle utilisée pour séparer les API FHIR pour les locataires : une `AUTH_BASE_URL` dédiée. 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](https://www.health-samurai.io/fhir-server) en tant qu'entités indépendantes. ### Conclusion Il y a **quatre étapes simples** pour atteindre la multilocation : - Rendez votre locataire explicite et de première classe; - 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-locataire lui aussi. Une fois ces quatre étapes simples appliquées, vous pourrez créer un [serveur FHIR](https://www.health-samurai.io/fhir-server) sans frais d'infrastructure supplémentaires, puisque vous n'avez qu'à créer une ressource Tenant et un [serveur FHIR](https://www.health-samurai.io/fhir-server) 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é**. Vous n'avez qu'à : - 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 souple et précise de l'accès aux données en fonction de la hiérarchie organisationnelle. Les administrateurs peuvent désormais définir des permissions d'accès à différents niveaux organisationnels, garantissant ainsi 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](https://www.health-samurai.io/docs/aidbox/modules-1/security-and-access-control/multitenancy/organization-based-hierarchical-access-control). Pour explorer la mise en œuvre d'une API FHIR multi-locataire dans votre système DSE, envisagez d'utiliser la [version gratuite d'Aidbox](https://www.health-samurai.io/aidbox#run). 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-locataire capable de vous accompagner en 2024 et au-delà, essayez**[ **le module API FHIR Aidbox certifié par l'ONC**](https://www.health-samurai.io/fhir-api) **dès aujourd'hui.** [![](image-6.avif)](https://www.health-samurai.io/fhir-api) Voir aussi : [Pourquoi vous avez besoin d'un serveur FHIR indépendant](/blog/why-you-need-independent-fhir-server-side-by-side-with-your-ehr-system).