SMART App Launch, kortweg SMART on FHIR, is een HL7-specificatie die op OAuth 2.0 regelt hoe toepassingen toegang krijgen tot een FHIR-server. Een app kan vanuit het EPD starten en de geselecteerde patiënt meekrijgen; een backend service werkt zonder gebruiker. Rechten heten 'scopes' en steunen op FHIR-interacties en zoekparameters. Bulk Data, CDS Hooks en FHIRcast bouwen erop voort. In de Belgische FHIR-gidsen werd geen gebruik gevonden; Vitalink laat toepassingen aanmelden met OAuth en PKCE via I.AM Connect.
", "last_verified": "2026-11-12", "verification_outdated": false, "sections": [ { "id": "wat-is-het", "title": "Wat is het?", "kind": "tekst", "html": "SMART App Launch, in de praktijk vaak 'SMART on FHIR' genoemd, is een implementatiegids van HL7 International met basispatronen op OAuth 2.0 (de open standaard voor gedelegeerde toegang) waarmee clienttoepassingen zich autoriseren, authenticeren en integreren met systemen die gegevens via FHIR aanbieden[1]. Het lost een concreet probleem op: een app van een derde partij moet bij een FHIR-server weten wie de gebruiker is, welke gegevens ze mag zien en in welke context ze gestart werd.
\nDe gids beschrijft twee hoofdpatronen. Het App Launch-patroon autoriseert een app voor een gebruiker en kan 'launch context' meegeven, zoals de patiënt die in de EPD-sessie van de gebruiker geselecteerd is[1]. Het Backend Services-patroon autoriseert een headless of geautomatiseerde toepassing, zonder dat een gebruiker bij de start betrokken is[1]. Als voorbeeld van zo'n backend service noemt de gids een analyseplatform of datawarehouse dat periodiek een bulkimport uit een EPD doet om een patiëntenpopulatie te analyseren[2].
" }, { "id": "hoe-is-het-opgebouwd", "title": "Hoe is het opgebouwd?", "kind": "tekst", "html": "Scopes. SMART drukt toegangsrechten uit in 'scopes' die aan een clienttoepassing gedelegeerd kunnen worden en die steunen op de FHIR-interacties, resourcetypes en zoekparameters[1]. Sinds versie 2.0 kunnen scopes fijner beperkt worden met de syntaxis van FHIR-zoekparameters[3].
\nOntdekking. Een FHIR-server publiceert een ontdekkingsdocument (.well-known/smart-configuration) waaruit een client de autorisatie-endpoints en de ondersteunde functies leert kennen[1].
Clientauthenticatie. SMART verkiest authenticatie met een asymmetrisch sleutelpaar boven een gedeeld geheim, omdat er dan geen geheim over het netwerk gaat[1].
\nVersie en status. De huidige gepubliceerde versie is 2.2.0 (STU 2.2), gebaseerd op FHIR R4[1]. In de publicatiehistoriek staat die versie als trial use (FHIR 4.0.1), gepubliceerd op 30 april 2024 en gemarkeerd als huidige versie[4]. 'Trial use' betekent dat de gids gebruikt kan worden maar nog niet normatief is.
\nSMART Backend Services is ontworpen om samen te werken met FHIR Bulk Data Access, maar kan voor elke FHIR-API gebruikt worden, synchroon of asynchroon[2]. CDS Hooks, de HL7-specificatie voor beslissingsondersteuning vanuit de klinische workflow, kan een SMART-app starten wanneer verdere interactie nodig is[5]. FHIRcast breidt het SMART-launchprotocol uit om afzonderlijke toepassingen nauw te laten samenwerken[6]. Een overzicht van het bredere FHIR-ecosysteem staat op HL7 FHIR en FHIR-tools, registers en testplatformen.
" }, { "id": "waar-wordt-het-gebruikt", "title": "Waar wordt het gebruikt?", "kind": "tekst", "html": "In de Belgische FHIR-gidsen (Belgische FHIR-implementatiegidsen) en in de eHealth-diensten werd geen gebruik van SMART App Launch of SMART Backend Services gevonden; de hiaat staat in het register. Dat is geen bewijs dat in België gebruikte EPD's of apps SMART niet aanbieden.
\nDe toegang tot Belgische FHIR-REST-diensten loopt via een eigen OAuth-route. Voor de REST-diensten van Vitalink moet de integratie aangevraagd worden via de formulieren van I.AM Connect[7]. De integratiegids van Vitalink (versie 1.0, oktober 2025) schrijft voor een gedistribueerde toepassing de 'authorization code flow' met PKCE voor, waarbij de gebruiker zich rechtstreeks aanmeldt via de identiteitsprovider en de federatieve autorisatiedienst van het eHealth-platform[7]. Beide routes steunen dus op OAuth, maar Vitalink verwijst niet naar SMART App Launch[7].
" }, { "id": "wat-betekent-het-voor-een-ziekenhuis", "title": "Wat betekent het voor een ziekenhuis?", "kind": "tekst", "html": "SMART bepaalt of externe apps, bijvoorbeeld voor beslissingsondersteuning, vanuit het EPD met de geselecteerde patiënt kunnen starten[1], en of een analyseplatform of datawarehouse zonder gebruiker gegevens uit het EPD kan afhalen[2]. Er is geen Belgische verplichting gevonden; voor de eHealth-diensten geldt de route via I.AM Connect[7].
\nAanbeveling: vraag bij een EPD- of app-aanbesteding expliciet of het systeem een SMART-ontdekkingsdocument, App Launch en Backend Services aanbiedt, met welke scopes, en hoe dat samengaat met de aanmelding via I.AM Connect voor de eHealth-diensten.
" }, { "id": "onzekerheden-en-tegenstrijdige-informatie", "title": "Onzekerheden en tegenstrijdige informatie", "kind": "tekst", "html": "