SMART Imaging Access
0.1.0 - ci-build International flag

SMART Imaging Access, published by Argonaut Project. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/argonautproject/smart-imaging/ and changes regularly. See the Directory of published versions

Home

Official URL: http://fhir.org/argonaut/smart-imaging/ImplementationGuide/fhir.argonaut.smart-imaging Version: 0.1.0
Draft as of 2026-09-23 Computable Name: SmartImagingAccess

SMART Imaging Access lets an app retrieve clinical records, imaging-study metadata, and DICOM images using the same SMART access token.

This helps patients gather their own records, supports second opinions, streamlines research data donation, and lets clinicians pull studies into their preferred viewers.

The guide supports both SMART App Launch, for user-facing authorization, and SMART Backend Services, for pre-authorized clients. Deployments can support either or both patterns. Neither requires a separate imaging authorization step.

System map: an app authorizes with the Authorization Server, optionally queries the Clinical FHIR Server, and uses the Imaging Server for study metadata and DICOM data; the Imaging Server validates tokens through the Authorization Server's introspection endpoint

The diagram illustrates App Launch. Both authorization modes use the same token for study search and image retrieval. These roles may be implemented by one product or multiple cooperating products. The dashed connection shows token validation using SMART Token Introspection.

How it works

  1. Discover — The app finds the imaging endpoint, either from the clinical FHIR endpoint's .well-known/smart-configuration or out-of-band configuration. (Discovery)
  2. Authorize — The app completes SMART App Launch and receives an access token with patient context. Where Backend Services is supported, a pre-authorized client instead obtains a system-scoped token through SMART Backend Services. (Authorization)
  3. Query clinical data (optional) — The app uses the token against the Clinical FHIR Server — for example, to fetch the Patient resource or imaging DiagnosticReports.
  4. Find studies — The app searches the imaging endpoint for the patient's ImagingStudy resources, each of which links to a WADO-RS endpoint. (Finding studies)
  5. Fetch images — The app retrieves DICOM data from the returned WADO-RS endpoint, presenting the same SMART access token. (Retrieving images)

Actors

This guide uses the following actor names throughout:

  • App — a client accessing clinical and imaging data. A user-facing application (patient- or provider-facing) can connect through SMART App Launch; a pre-authorized service can connect through SMART Backend Services. Unless stated otherwise, the guide's discovery, search, retrieval, and token-handling requirements apply to Backend Clients too.
  • Backend Client — an App using SMART Backend Services, with access authorized in advance rather than through a user-facing launch.
  • Authorization Server — the SMART authorization server configured for the deployment. It supports client registration, token issuance, and token validation for participating resource servers. Depending on the supported modes, it provides App Launch authorization and refresh, Backend Services token issuance for pre-authorized clients, or both. It may be provided by an EHR or another service.
  • Clinical FHIR Server — a FHIR service exposing clinical resources such as Patient, DiagnosticReport, and ServiceRequest. Its SMART configuration can advertise imaging endpoints. An app may query it for clinical data as part of an imaging workflow.
  • Imaging Server — the collective term for two cooperating functions:
    • Imaging FHIR Server — serves ImagingStudy resources and returns the WADO-RS Endpoints through which authorized clients can retrieve images.
    • DICOMweb Server — provides WADO-RS retrieval through those endpoints and enforces the applicable retrieval authorization.

These are functional roles, not product categories. One product may implement several roles, or cooperating products may implement them separately. For example, an EHR, imaging platform, or adapter could provide Imaging FHIR; a PACS, archive service, or gateway could provide DICOMweb; and an EHR or a standalone authorization service could provide the Authorization Server. “DICOMweb Server” here refers to the WADO-RS retrieval functionality described in this guide.

Implementing Study-Level Authorization illustrates how these functions can share policy decisions and enforce access to individual studies.

In U.S. certified deployments, the Authorization Server role can be supplied by the authorization capabilities of a Health IT Module certified to §170.315(g)(10). Deploying SMART Imaging Access also requires configuring the participating services to support the imaging discovery, scopes, and token validation described in this guide. This guide defines technical roles and interfaces without requiring changes to certification categories.

Scope

See Connecting Organizations for how this guide can serve as a building block for image exchange between health systems.

In scope:

  • Discovering an imaging endpoint through SMART configuration or direct configuration
  • Reusing the SMART access token issued by the Authorization Server for imaging requests, with server-side validation (for example, via SMART Token Introspection)
  • Using token-bound capability URLs to carry study-specific permissions between cooperating services
  • Searching ImagingStudy by patient and retrieving DICOM data via WADO-RS
  • Backend Services access, with system scopes and enforcement of each client's pre-authorized permissions

Out of scope (for now):

  • Writing or uploading imaging data
  • DICOM capabilities beyond the minimum retrieval requirements in Retrieving images
  • Cross-organization trust agreements, patient matching, record location, and destination-system import workflows

History

This guide grew out of the Sync for Science (S4S) Imaging specification, developed by the SMART team for the NIH All of Us research program, and continues under the Argonaut Project.

Dependencies

Package hl7.fhir.uv.extensions.r4#5.3.0

This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, May 16, 2026 18:32+1000+10:00)

Package hl7.fhir.uv.extensions.r4#1.0.0

This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00)

Package hl7.fhir.uv.tools.r4#1.1.2

This IG defines the extensions that the tools use internally. Some of these extensions are content that are being evaluated for elevation into the main spec, and others are tooling concerns (built Tue, Mar 24, 2026 11:13+1100+11:00)

There are no Global profiles defined

Cross-version analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (fhir.argonaut.smart-imaging.r4) and R4B (fhir.argonaut.smart-imaging.r4b) are available.

Intellectual property statements

This publication includes IP covered under the following statements.