DocumentationSupportCosta Rica · Contact
ESENPT
Let’s talk
  • Technical

SMART App LaunchSubstitutable Medical Applications and Reusable Technologies

In short

SMART App Launch is the HL7 guide that defines how an application gets permission to read or write data in a health system with a FHIR API, without knowing the user's password. It lets the same app work with health records from different vendors. In the US, ONC (formerly ASTP/ONC) health IT certification requires it for standardized FHIR APIs.

Type
Implementation guide
Steward
HL7 International
Current version
STU 2.2 (2.2.0)
Reviewed
October 25, 2026

Explanation

What it is

SMART App Launch, known as "SMART on FHIR", is an HL7 International implementation guide that defines OAuth 2.0-based patterns for client applications to authorize, authenticate and integrate with FHIR-based data systems. SMART (Substitutable Medical Applications and Reusable Technologies) started in 2010 as a Harvard Medical School and Boston Children's Hospital project, adopted FHIR in 2013, and its guide is now published by HL7. As of October 2026, the current version is STU 2.2 (2.2.0), based on FHIR R4.

What it defines

  • Discovery: each server publishes its authorization endpoints and supported capabilities at .well-known/smart-configuration.
  • Two authorization patterns: launching user-facing apps, and backend services for automated processes with no user, such as a bulk data export.
  • Two ways to launch an app: from inside the health record (EHR launch), receiving session context such as the open patient; or independently (standalone launch), where the user chooses at start-up.
  • Scopes: permissions expressed with FHIR resources, for example user/Encounter.rs to read and search the encounters the user can access. The syntax changed from SMART v1.
  • Client authentication: preferably with an asymmetric key pair (signed JWT), or with a shared secret.

Every SMART app must support PKCE (RFC 7636). To identify the user, SMART adds OpenID Connect with the openid and fhirUser scopes.

Common misconceptions

  • SMART is not a data standard: it does not say what a resource contains, only who can access it and with which permissions.
  • A broad scope such as patient/*.rs grants far more than an app usually needs. The least-privilege principle applies here too.
  • The server decides which context and permissions it grants. An app must not assume it got everything it asked for.
  • The SMART version matters. According to the ONC (g)(10) test kit, US Core 7.0.0 should only be used with SMART App Launch 2.0.0 or above, because of its granular scope requirements.

Usage examples

  1. In the US, ONC (formerly ASTP/ONC) criterion § 170.315(g)(10) requires certified health IT to authorize its FHIR APIs with SMART App Launch, both from the health record and standalone.

  2. The HL7 FHIR Bulk Data Access guide says bulk data exports should be authorized following the SMART Backend Services profile, with no user involved.

  3. In the US, CMS lists SMART App Launch 2.0.0 among the standards for the Patient Access API that payers covered by its interoperability rules must offer; version 1.0.0 expired on 1 January 2026.

  4. The ONC (g)(10) test kit lets developers test with SMART App Launch 2.0.0 or 2.2.0, together with US Core and Bulk Data.

  5. The CMS Blue Button 2.0 API uses scopes with SMART syntax, such as patient/ExplanationOfBenefit.rs and launch/patient.

  6. A physician opens a risk calculator from the health record; the app receives through context (launch/patient) the patient the physician has open.

  7. A patient app reads the provider's .well-known/smart-configuration file to find out where to request authorization.

Relation to other terms

Relies on3

  • FHIRRequired

    SMART authorizes access to FHIR servers and expresses permissions in terms of FHIR resource types.

  • OAuth 2.0Required

    Every SMART authorization pattern is a profile of OAuth 2.0.

  • OpenID ConnectMedium

    Only when the app needs to know who the user is (sso-openid-connect capability, openid and fhirUser scopes).

Depend on this one0

No glossary term depends on this one.

Sources

  1. HL7 — SMART App Launch Implementation Guide (STU 2.2)hl7.org
  2. SMART App Launch — Scopes and Launch Contexthl7.org
  3. Mandel et al. — SMART on FHIR: a standards-based, interoperable apps platform for electronic health records (JAMIA, 2016)academic.oup.com
  4. ONC — ONC Certification (g)(10) Standardized API Test Kitfhir.healthit.gov
  5. CMS — APIs and relevant standards and implementation guidescms.gov
  6. HL7 — FHIR Bulk Data Access: Exporthl7.org
  7. CMS — Blue Button 2.0 API: Authorizationbluebutton.cms.gov
  8. Federal Register — HHS Statement of Organization: Office of the National Coordinator for Health IT (91 FR 16204, 1 April 2026)federalregister.gov
Health interoperability glossary