--- id: smart-on-fhir type: Specification type_label: Norme ou spécification title: SMART App Launch (SMART on FHIR) aliases: - SMART on FHIR - SMART App Launch - SMART Backend Services - hl7.fhir.uv.smart-app-launch names: nl: SMART App Launch (SMART on FHIR) fr: SMART App Launch (SMART on FHIR) en: SMART App Launch (SMART on FHIR) de: SMART App Launch (SMART on FHIR) jurisdiction: - internationaal themes: - identiteit-en-toegang - architectuur-en-infrastructuur - standaardisatie-en-governance lifecycle: trial-use lifecycle_note: 'Trial use: la version 2.2.0 (STU 2.2) du 30 avril 2024 est la version publiée actuelle (historique des publications HL7, état au 12 novembre 2026).' version: 2.2.0 (STU 2.2, FHIR R4) summary: 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. links: - soort: documentatie url: https://hl7.org/fhir/smart-app-launch/ label: SMART App Launch Implementation Guide (HL7) taal: en - soort: documentatie url: https://build.fhir.org/ig/HL7/smart-app-launch/ label: SMART App Launch - CI-build taal: en - soort: repository url: https://github.com/HL7/smart-app-launch label: HL7/smart-app-launch (GitHub) taal: en last_verified: '2026-11-12' relations: - type: ownedBy direction: uit target: hl7-international target_url: https://ehealth-atlas.be/fr/hl7-international/ status: established - type: dependsOn direction: uit target: fhir target_url: https://ehealth-atlas.be/fr/hl7-fhir/ status: established - type: comparedWith direction: uit target: i-am-connect target_url: https://ehealth-atlas.be/fr/i-am-identity-access-management/ status: established - type: recommends direction: in target: fhir-bulk-data target_url: https://ehealth-atlas.be/fr/fhir-bulk-data-access/ status: established release: 2026.11.13-2 url: https://ehealth-atlas.be/fr/smart-app-launch-smart-on-fhir/ license: CC BY 4.0 --- # SMART App Launch (SMART on FHIR) 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. ## Qu'est-ce que c'est ? SMART App Launch, souvent appelé « SMART on FHIR » dans la pratique, est un guide d'implémentation de [HL7 International](https://ehealth-atlas.be/fr/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](https://ehealth-atlas.be/fr/hl7-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. Le 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]. ## Comment est-il structuré ? **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]. **Dé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]. **Version 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. ### Spécifications qui s'appuient sur lui SMART Backend Services est conçu pour fonctionner avec [FHIR Bulk Data Access](https://ehealth-atlas.be/fr/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](https://ehealth-atlas.be/fr/hl7-fhir/) et [Outils, registres et plateformes de test FHIR](https://ehealth-atlas.be/fr/outils-registres-et-plateformes-de-test-fhir/). ## Où est-il utilisé ? 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](https://ehealth-atlas.be/fr/guides-d-implementation-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. L'accès aux services FHIR REST belges passe par une voie OAuth propre. Pour les services REST de [Vitalink](https://ehealth-atlas.be/fr/vitalink/), l'intégration doit être demandée via les formulaires d'[I.AM Connect](https://ehealth-atlas.be/fr/i-am-identity-access-management/)[^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](https://ehealth-atlas.be/fr/plate-forme-ehealth/)[^7]. Les deux voies reposent donc sur OAuth, mais Vitalink ne renvoie pas à SMART App Launch[^7]. ## Qu'est-ce que cela signifie pour un hôpital ? 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]. **Recommandation :** 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. ## Incertitudes et informations contradictoires - La question de savoir si les DPI hospitaliers utilisés en Belgique proposent SMART App Launch ou Backend Services n'a pas trouvé de réponse ; la documentation des fournisseurs n'a pas été examinée. - Au 12 novembre 2026, aucun successeur de la version 2.2.0 ne figure dans l'historique des publications[^4] ; aucun calendrier n'a été trouvé. - Aucune source belge trouvée ne décrit comment un serveur d'autorisation SMART s'articule avec l'IDP eHealth et I.AM Connect. ## Relaties - relève de: [HL7 International](https://ehealth-atlas.be/fr/hl7-international/) (établi)[^1]. Gepubliceerd als HL7-implementatiegids op hl7.org. - dépend de: [HL7 FHIR](https://ehealth-atlas.be/fr/hl7-fhir/) (établi)[^1]. Autorisatiepatronen voor FHIR-servers, gebaseerd op FHIR R4. - est comparé à: [I.AM et I.AM Connect (Identity & Access Management)](https://ehealth-atlas.be/fr/i-am-identity-access-management/) (établi)[^7]. Beide steunen op OAuth; Vitalink vraagt de authorization code flow met PKCE via I.AM Connect, niet SMART App Launch. - recommande (entrant): [FHIR Bulk Data Access ($export)](https://ehealth-atlas.be/fr/fhir-bulk-data-access/) (établi)[^8][^2] ## Open vragen - Bieden in België gebruikte ziekenhuis-EPD's een SMART App Launch- of Backend Services-endpoint aan, en met welke scopes? - Komt er een SMART App Launch-versie 2.3 of een STU 3, en wanneer? - Kan een SMART-autorisatieserver in België samenwerken met de eHealth-IDP en I.AM Connect, of blijven het gescheiden werelden? ## Bronnen [^1]: [SMART App Launch Implementation Guide - Home](https://hl7.org/fhir/smart-app-launch/). HL7 International. Opgehaald 2026-11-12, sha256 b50fe78d4bedeb9f… (SRC-cb5a8034c5) [^2]: [SMART App Launch - Backend Services](https://hl7.org/fhir/smart-app-launch/backend-services.html). HL7 International. Opgehaald 2026-11-12, sha256 20ed28915344311f… (SRC-5b357ff62a) [^3]: [SMART App Launch - Scopes and Launch Context](https://hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html). HL7 International. Opgehaald 2026-11-12, sha256 0ecd5d54cd653c86… (SRC-d20b498334) [^4]: [SMART App Launch - package-list.json (publicatiehistoriek)](https://hl7.org/fhir/smart-app-launch/package-list.json). HL7 International. Opgehaald 2026-11-12, sha256 7b233df314e61aa6… (SRC-d7fd853c3a) [^5]: [CDS Hooks Specification 2.0.1](https://cds-hooks.hl7.org/). HL7 International (Clinical Decision Support WG). Opgehaald 2026-11-09, sha256 fc2502606303afe6… (SRC-4d1d913b91) [^6]: [FHIRcast - Home](https://fhircast.hl7.org/). HL7 International. Opgehaald 2026-11-12, sha256 c35977342d809c7c… (SRC-4c3db153d0) [^7]: [Integration Guide for VITALINK v1.0 (10/2025)](https://www.up.ehealth.fgov.be/ehealthplatform/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/288304022e5253c740645e690dc39edd58c126ed/2025-integration-guide-vitalink-v1.0.pdf). eHealth-platform, 2025-10-01. Opgehaald 2026-11-12, sha256 d58607026b45ad32… (SRC-a5f98689c4) [^8]: [FHIR Bulk Data Access - Bulk Data Export](https://hl7.org/fhir/uv/bulkdata/en/export.html). HL7 International. Opgehaald 2026-11-12, sha256 c36bb7ece0de9b7d… (SRC-d4ea422d02)