SMART App Launch, en abrégé SMART on FHIR, est une spécification HL7 qui règle, sur la base d'OAuth 2.0, la manière dont des applications obtiennent l'accès à un serveur FHIR. Une application peut démarrer depuis le DPI et recevoir le patient sélectionné ; un backend service fonctionne sans utilisateur. Les droits s'appellent « scopes » et s'appuient sur les interactions et les paramètres de recherche FHIR. Bulk Data, CDS Hooks et FHIRcast s'appuient sur elle. Aucun usage n'a été trouvé dans les guides FHIR belges ; Vitalink fait authentifier les applications avec OAuth et PKCE via I.AM Connect.
", "last_verified": "2026-11-12", "verification_outdated": false, "sections": [ { "id": "qu-est-ce-que-c-est", "title": "Qu'est-ce que c'est ?", "kind": "tekst", "html": "SMART App Launch, souvent appelé « SMART on FHIR » dans la pratique, est un guide d'implémentation de HL7 International qui contient des modèles de base reposant sur OAuth 2.0 (la norme ouverte d'accès délégué) permettant aux applications clientes de s'autoriser, de s'authentifier et de s'intégrer avec des systèmes qui proposent des données via FHIR[1]. Il résout un problème concret : une application d'un tiers doit savoir, auprès d'un serveur FHIR, qui est l'utilisateur, quelles données elle peut consulter et dans quel contexte elle a été lancée.
\nLe guide décrit deux modèles principaux. Le modèle App Launch autorise une application pour un utilisateur et peut transmettre un « launch context », comme le patient sélectionné dans la session DPI de l'utilisateur[1]. Le modèle Backend Services autorise une application headless ou automatisée, sans qu'un utilisateur intervienne au démarrage[1]. Comme exemple d'un tel backend service, le guide cite une plateforme d'analyse ou un entrepôt de données qui effectue périodiquement une importation en masse depuis un DPI afin d'analyser une population de patients[2].
" }, { "id": "comment-est-il-structure", "title": "Comment est-il structuré ?", "kind": "tekst", "html": "Scopes. SMART exprime les droits d'accès en « scopes », qui peuvent être délégués à une application cliente et qui s'appuient sur les interactions, les types de ressources et les paramètres de recherche FHIR[1]. Depuis la version 2.0, les scopes peuvent être restreints plus finement avec la syntaxe des paramètres de recherche FHIR[3].
\nDécouverte. Un serveur FHIR publie un document de découverte (.well-known/smart-configuration) par lequel un client prend connaissance des endpoints d'autorisation et des fonctionnalités prises en charge[1].
Authentification du client. SMART préfère l'authentification par une paire de clés asymétriques à un secret partagé, parce qu'aucun secret ne transite alors sur le réseau[1].
\nVersion et statut. La version publiée actuelle est la 2.2.0 (STU 2.2), fondée sur FHIR R4[1]. Dans l'historique des publications, cette version figure comme trial use (FHIR 4.0.1), publiée le 30 avril 2024 et marquée comme version actuelle[4]. « Trial use » signifie que le guide peut être utilisé, mais n'est pas encore normatif.
\nSMART Backend Services est conçu pour fonctionner avec FHIR Bulk Data Access, mais peut être utilisé pour n'importe quelle API FHIR, de manière synchrone ou asynchrone[2]. CDS Hooks, la spécification HL7 d'aide à la décision depuis le flux de travail clinique, peut lancer une application SMART lorsqu'une interaction supplémentaire est nécessaire[5]. FHIRcast étend le protocole de lancement SMART pour permettre à des applications distinctes de collaborer étroitement[6]. Une vue d'ensemble de l'écosystème FHIR plus large figure sur HL7 FHIR et Outils, registres et plateformes de test FHIR.
" }, { "id": "ou-est-il-utilise", "title": "Où est-il utilisé ?", "kind": "tekst", "html": "Aucun usage de SMART App Launch ou de SMART Backend Services n'a été trouvé dans les guides FHIR belges (Guides d'implémentation FHIR belges) ni dans les services eHealth ; la lacune figure dans le registre. Cela ne prouve pas que des DPI ou des applications utilisés en Belgique ne proposent pas SMART.
\nL'accès aux services FHIR REST belges passe par une voie OAuth propre. Pour les services REST de Vitalink, l'intégration doit être demandée via les formulaires d'I.AM Connect[7]. Le guide d'intégration de Vitalink (version 1.0, octobre 2025) prescrit pour une application distribuée l'« authorization code flow » avec PKCE, dans lequel l'utilisateur s'authentifie directement via le fournisseur d'identité et le service fédératif d'autorisation de la Plate-forme eHealth[7]. Les deux voies reposent donc sur OAuth, mais Vitalink ne renvoie pas à SMART App Launch[7].
" }, { "id": "qu-est-ce-que-cela-signifie-pour-un-hopital", "title": "Qu'est-ce que cela signifie pour un hôpital ?", "kind": "tekst", "html": "SMART détermine si des applications externes, par exemple d'aide à la décision, peuvent démarrer depuis le DPI avec le patient sélectionné[1], et si une plateforme d'analyse ou un entrepôt de données peut récupérer des données du DPI sans utilisateur[2]. Aucune obligation belge n'a été trouvée ; pour les services eHealth, c'est la voie via I.AM Connect qui s'applique[7].
\nRecommandation : lors d'un marché pour un DPI ou une application, demandez explicitement si le système propose un document de découverte SMART, App Launch et Backend Services, avec quels scopes, et comment cela s'articule avec l'authentification via I.AM Connect pour les services eHealth.
" }, { "id": "incertitudes-et-informations-contradictoires", "title": "Incertitudes et informations contradictoires", "kind": "tekst", "html": "