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

CapabilityStatement: SMART Imaging Access Server

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

Requirements for the Imaging FHIR Server. WADO-RS retrieval and SMART token validation are specified in Retrieving images and Authorization.

Raw OpenAPI-Swagger Definition file | Download

SMART Imaging Access Server

  • Implementation Guide Version: 0.1.0
  • FHIR Version: 4.0.1
  • Supported Formats: json
  • Published on: 2026-09-23
  • Published by: Argonaut Project

Note to Implementers: FHIR Capabilities

Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.

FHIR RESTful Capabilities

Mode: server

Security

FHIR requests carry a SMART access token issued by the Authorization Server configured for the deployment. Deployments SHALL support SMART App Launch, SMART Backend Services, or both, as defined in Authorization. Supported modes are advertised for each imaging endpoint with the corresponding capability http://fhir.org/argonaut/smart-imaging/capabilities/app-launch or http://fhir.org/argonaut/smart-imaging/capabilities/backend-services (or both). The Imaging Server validates the token and enforces granted scopes and underlying access restrictions. App Launch requests SHALL match the token's patient context. Backend Services requests SHALL be limited to the client's pre-authorized access; system/ImagingStudy.rs does not grant access to all patients or studies. Missing patient context SHALL NOT imply system-level access. Every WADO-RS request SHALL carry the same SMART access token used for the authorized FHIR request. A returned Endpoint address may be a capability URL; the DICOMweb Server then validates the token, the capability, and their binding and enforces all applicable restrictions. Capability issuance SHALL be limited to the data and operations authorized by the FHIR request. Each retrieval SHALL enforce the validation, lifetime, and revocation requirements in Retrieving images.

Capabilities by Resource/Profile

Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

  • The relevant profiles (if any)
  • The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
  • The required, recommended, and some optional search parameters (if any).
  • The linked resources enabled for _include
  • The other resources enabled for _revinclude
  • The operations on the resource (if any)
Resource TypeProfileRSUCSearches_include_revincludeOperations
ImagingStudySupported Profiles
  SMART ImagingStudy		ypatient, identifier, _lastUpdatedImagingStudy:endpoint
Core FHIR Resource
ImagingStudy
Reference Policy
Interaction summary
  • Supports search-type.

Supported Profiles

SMART ImagingStudy

Documentation

The server SHALL support searching ImagingStudy by patient, alone and in combination with _lastUpdated and identifier (a DICOM Study Instance UID in urn:oid:... form). The server SHALL support _include=ImagingStudy:endpoint so apps receive the WADO-RS Endpoint for each study. Apps SHALL resolve Endpoints provided as response-local Bundle entries, separately addressable resources included in the Bundle, or contained resources. Response-specific capability Endpoints SHOULD use urn:uuid fullUrl values; the server SHALL include them on the same Bundle page as each referencing study, even without an _include request.

Searches SHALL enforce the access rules in Finding studies: patient-context mismatches and backend requests for unauthorized patients receive 403 Forbidden. Results and included Endpoints SHALL exclude unauthorized studies. Neither authorization mode requires population-wide search.

If results are not yet available (for example, the server is querying an underlying PACS), the server MAY respond 503 with a Retry-After header; the app retries after the indicated number of seconds.

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference

The patient whose studies are requested. SHALL be supported alone and in combination with _lastUpdated or identifier.

SHALLidentifiertoken

A DICOM Study Instance UID in urn:oid:... form, used with patient to look up a specific study.

SHALL_lastUpdateddate

Used with patient to fetch only studies updated after a given time, e.g. _lastUpdated=gt2023-04-17T04:00:00Z.