Comment SMART on FHIR étend les capacités des DME
Il n'existe aucun DME ou DSE capable de couvrir tous les cas d'utilisation. Plutôt que d'essayer d'intégrer toutes les fonctionnalités nécessaires dans un seul produit, il est généralement préférable de fournir des interfaces externes pouvant être exploitées par des extensions tierces. FHIR propose un guide d'implémentation SMART App Launch qui répond à ce problème. Cet article offre un guide pratique, étape par étape, destiné aux ingénieurs en logiciel qui cherchent un moyen efficace d'étendre leurs applications de santé.
Je m'appelle Ilya Beda. Je suis directeur technique chez Beda Software.
Chez Beda Software, nous développons une solution DME à code source ouvert. Elle est conçue pour servir de frontal et transformer n'importe quel serveur FHIR en DME FHIR. Récemment, j'ai participé au volet SMART Launch du connectathon HL7 AU FHIR. J'ai endossé le rôle de fournisseur de lancement SMART, et le DME de Beda a été utilisé pour lancer des applications SMART on FHIR tierces. L'objectif était de vérifier le fonctionnement de l'implémentation et de tester l'intégration entre les applications fournies par les participants.
Avant d'entrer dans les détails techniques, clarifions ce qu'est SMART. SMART (Substitutable Medical Applications, Reusable Technology) est une plateforme de création d'applications de santé pouvant s'exécuter sur différents systèmes DSE (dossier de santé électronique). Elle fournit un cadre pour développer des applications sécurisées, interopérables et substituables. Les applications SMART sont conçues pour être faciles à développer et à déployer dans divers contextes de soins de santé.
SMART on FHIR est construit sur OAuth 2.0, ce qui le rend assez facile à comprendre.
Le DME FHIR initie le lancement SMART en transmettant deux paramètres à l'application SMART.
Le premier paramètre, appelé iss, est l'URL de base du serveur FHIR. Le second paramètre — launch — est une séquence unique qui assure le suivi du processus de lancement et associe un contexte à une session.
Une fois l'application lancée, elle charge les informations du serveur FHIR concernant le point de terminaison d'authentification OAuth. Elle redirige ensuite l'utilisateur vers ce point de terminaison d'authentification. Cette authentification contient une liste de portées qui définissent les permissions demandées par l'application. Examinons de plus près à quoi ressemble une portée :
La première partie identifie le rôle. Patient signifie que les données seront limitées à un patient spécifique, tandis que user signifie que les données seront limitées à un utilisateur spécifique. Si l'utilisateur est un patient, il ne pourra accéder qu'à ses propres données. Si l'utilisateur est un professionnel de la santé, les données de tous les patients ayant fourni leur consentement seront disponibles.
Enfin, le statut system permet d'accéder à toutes les ressources.
Le type de ressource est explicite et définit une ressource FHIR spécifique.
Le reste correspond à des opérations codées par lettre :
- C pour créer (create) ;
- R pour lire par identifiant (read by id) ;
- U pour mettre à jour (update) ;
- D pour supprimer (delete) ;
- S pour rechercher (search).
Ainsi, si votre application a besoin d'accéder à une Observation d'un patient, vous devez fournir la portée suivante : "patient/Observation.rs".
Si vous souhaitez créer un quelconque ressource QuestionnaireResponse, la portée sera : "system/QuestionnaireResponse.c".
Une fois que l'application a demandé les portées au serveur FHIR, un utilisateur doit autoriser et accorder les permissions pour les portées demandées. Si cela se produit, le serveur FHIR fournit un code d'accès pouvant être échangé contre un jeton d'accès, un jeton d'identité et un fhirContext.
Lorsque le DME FHIR effectue le lancement, il sauvegarde le contexte, qui sera disponible sous la clé fhirContext dans la réponse d'échange de jeton.
Maintenant que vous connaissez les principes fondamentaux de SMART on FHIR et du lancement SMART, voyons comment cela peut être implémenté avec Aidbox.
Le composant principal est la ressource Aidbox Client, qui représente le client OAuth. Cette ressource contient également un champ smart utilisé pour définir les propriétés spécifiques à SMART on FHIR, comme l'URI de lancement, le nom et la description :
Le code est accessible ici.
Maintenant, créons une page de galerie d'applications affichant toutes les applications SMART on FHIR. Pour ce faire, nous devons interroger les ressources Client. Les ressources Client ne sont pas utilisées exclusivement pour SMART on FHIR, donc un critère est nécessaire pour sélectionner uniquement les clients représentant des applications SMART on FHIR. J'ai utilisé le champ Client.type et lui ai attribué la valeur "smart-on-fhir". Par conséquent, je peux interroger toutes les données comme suit :
Le code est accessible ici.
J'utilise ici la bibliothèque https://github.com/beda-software/aidbox-react pour interagir avec les ressources personnalisées d'Aidbox.
Une fois les données chargées, le DME FHIR peut afficher la galerie d'applications SMART :
Voyons maintenant comment lancer l'application. Aidbox fournit l'API RPC pour de nombreuses fonctions internes.
La fonction RPC aidbox.smart/get-launch-uri génère l'URI de lancement pour l'application SMART utilisée.
Le code est accessible ici.
Vous pouvez constater que la méthode RPC requiert les paramètres user, iss et ctx. Ctx correspond au fhirContext décrit précédemment. Je l'utilise pour partager des informations sur le patient actuel.
Le résultat de cet appel contient l'URI qui initie le lancement de l'application SMART. Je l'utilise pour remplacer la page actuelle du navigateur :
Le code est accessible ici.
Lorsqu'un utilisateur clique sur le bouton de lancement, il est redirigé vers l'application SMART, qui à son tour nous redirige vers le point de terminaison d'authentification d'Aidbox, puis vers la page d'autorisation avec la liste des portées demandées.
Une fois que l'utilisateur accorde l'accès, Aidbox redirige vers l'application SMART avec le code d'autorisation. Ce code est échangé contre un jeton d'accès et un fhirContext.
L'application reçoit des informations sur l'utilisateur actuel et le patient actuel.
Si un utilisateur souhaite mettre fin à l'accès de l'application à ses données, il peut le révoquer en utilisant l'interface de session d'Aidbox :
Démonstration en direct : DME FHIR + Application SMART
Vous pouvez découvrir le fonctionnement de ce processus grâce à notre version de démonstration en direct du DME Beda ici.
Comme vous pouvez le constater, Aidbox respecte les spécifications décrites précédemment et permet d'ajouter la fonctionnalité de lancement SMART au DME Beda en seulement quelques jours. J'ai testé cette approche lors du connectathon HL7 AU FHIR et elle a fonctionné avec toutes les applications fournies.
Si vous êtes intéressé par une solution DME native FHIR conforme à toutes les normes modernes, veuillez communiquer avec Beda Software.
Pour expérimenter l'extension des capacités de votre DME à l'aide d'applications SMART on FHIR, essayez la version gratuite d'Aidbox. Elle offre un environnement entièrement fonctionnel pour tester et développer ces intégrations, avec tous les outils nécessaires disponibles sans limitations.
Auteur :
Ilya Beda, directeur technique chez Beda Software
Communiquer avec Ilya via LinkedIn
Voir aussi : RBAC avec Keycloak et SMART on FHIR V2 et Pourquoi vous avez besoin d'un serveur FHIR indépendant.
