Pourquoi utiliser une façade d'API FHIR ?
Il existe de nombreuses raisons d'amener votre solution logicielle à communiquer avec d'autres. Entre l'interaction avec d'autres applications et l'extension de votre solution avec de nouveaux modules, votre solution doit partager des données et exécuter des opérations sur demande externe. Une façon courante d'y parvenir est de fournir une API (interface de programmation d'application). De plus, si vous souhaitez que votre application communique aisément avec tout le monde sans avoir recours à des interprètes coûteux, vous devriez vous en tenir à l'API standard, qui est l'API FHIR. Les développeurs expérimentés de nouvelles technologies en santé pensent à l'API dès le premier jour. Beaucoup d'entre eux adoptent le processus de développement FHIR d'abord, où le serveur principal d'une nouvelle solution est bâti sur un serveur FHIR. Celui-ci utilise le modèle de données FHIR en interne et prend en charge l'API FHIR complète d'emblée. Cependant, si vous avez développé votre solution il y a quelque temps et qu'elle ne dispose pas d'une couche d'API, vous devez permettre à votre application de communiquer avec d'autres. C'est précisément à cela que sert une façade d'API — une interface ajoutée à votre solution qui donne à d'autres applications accès aux opérations et aux données de votre solution.
Comment construire une façade FHIR
Façade FHIR sans stockage
Une approche pour implémenter une façade FHIR consiste à traduire les appels REST FHIR en requêtes vers la base de données sous-jacente ou les services du système d'origine. Vous devez faire correspondre votre modèle d'information interne à FHIR — identifier quelles ressources et quels attributs FHIR représentent les structures de données de votre système. Une telle façade achemine tous les appels vers la base de données d'origine.
L'implémentation est simple pour une API en lecture seule et peut devenir complexe si vous souhaitez permettre à vos utilisateurs d'écrire des données dans le système d'origine. Les cas d'utilisation simples peuvent être résolus avec des outils de correspondance, tandis que les implémentations plus complexes nécessiteront beaucoup de développement personnalisé.
Façade FHIR avec un serveur FHIR intermédiaire
L'autre approche consiste à utiliser un serveur FHIR générique pour stocker les données que vous allez exposer via l'API. Vous effectuez la même correspondance de votre modèle d'information interne à FHIR, puis vous synchronisez les données de votre base de données avec celles du serveur FHIR, qui se charge du reste du travail.
Le serveur FHIR traite toutes les commandes de l'API sans les acheminer vers la base de données sous-jacente du système d'origine. Toutes les modifications dans la base de données d'origine sont transmises en temps opportun au serveur FHIR afin que le système d'origine et le serveur FHIR restent synchronisés.
Avantages et inconvénients
Les deux approches sont viables selon les cas d'utilisation et présentent des avantages et des inconvénients différents. La façade FHIR sans stockage convient bien aux cas d'utilisation simples lorsque vous devez implémenter quelques points de terminaison d'API individuels. Il n'y a pas de duplication des données et elle utilise un minimum de ressources informatiques.
Cependant, si vous souhaitez que votre façade FHIR héberge des applications d'entreprise et prenne en charge des cas d'utilisation à l'échelle populationnelle, alors la mise en cache des données dans un serveur FHIR intermédiaire peut être avantageuse, voire nécessaire. Lorsqu'un serveur FHIR traite tous les appels d'API, vous contrôlez la performance de chaque appel. Vous pouvez atteindre une excellente performance à grande échelle, même lorsqu'un serveur FHIR virtualise des données provenant de plusieurs systèmes. Les mêmes appels d'API avec une façade d'API sans stockage pourraient être très lents.
Commencez avec le serveur FHIR Aidbox pour le stockage de données, les intégrations, l'analytique en santé et bien plus encore, ou faites appel à notre équipe pour répondre à vos besoins en développement logiciel.
Il est important de mentionner la complexité de la recherche FHIR. Elle sera beaucoup plus rapide avec le serveur FHIR intermédiaire, car vous pouvez prendre en charge la recherche avec des index, ce qui est impossible avec une approche sans stockage.
Même si votre serveur FHIR reçoit de nombreuses requêtes d'applications externes, il ne surcharge pas le système sous-jacent. Les données ne sont demandées qu'une seule fois au système d'origine; le serveur FHIR prend en charge tous les appels d'API. Si vous utilisez une façade sans stockage, toutes les requêtes sont acheminées vers la base de données sous-jacente du système d'origine, ce qui pourrait nuire à la performance de ce système et à ses utilisateurs.
L'utilisation d'un serveur FHIR complet vous offre un avantage supplémentaire par rapport à la façade FHIR sans stockage. Il vous permet de bâtir tout un nouvel écosystème d'applications modernes FHIR d'abord par-dessus, de sorte qu'un jour vous puissiez passer de votre serveur principal patrimonial propriétaire à un avenir fondé sur FHIR. Même si cela exige davantage de ressources informatiques, vous ne les gaspillez pas. Elles vous procurent un niveau de flexibilité supérieur.
Conclusions
Le choix de l'approche pour votre implémentation d'API vous appartient. Health Samurai peut prendre en charge les deux approches grâce à ses solutions et services. Envoyez-nous un message ou appelez-nous.
Voir aussi : Pourquoi vous avez besoin d'un serveur FHIR indépendant.
