|
Type
|
Reference
|
Content
|
|
web
|
github.com
|
SMART App Launch, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 2.2.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/smart-app-launch/
and changes regularly. See the Directory of published versions
|
|
web
|
smarthealthit.org
|
|
|
web
|
smarthealthit.org
|
IG © 2020+ HL7 International / FHIR Infrastructure
and Boston Children's Hospital
. Package hl7.fhir.uv.smart-app-launch#2.2.0 based on FHIR 4.0.1
. Generated 2026-09-08
Links: Table of Contents |
QA Report
| Version History |
 |
Propose a change
|
|
web
|
ehr.example.org
|
subject
: https://ehr.example.org/fhir/Practitioner/123
|
|
web
|
healthcentral.labs.example.com
|
portalUrl: https://healthcentral.labs.example.com
|
|
web
|
labs.example.com
|
telecom
: https://labs.example.com
|
|
web
|
dev-portal.labs.example.com
|
contact
: https://dev-portal.labs.example.com
|
|
web
|
fhir.labs.example.com
|
address
: https://fhir.labs.example.com/r4
|
|
web
|
example.org
|
brandLogo: https://example.org/examplehealth/logo/main.1024x1024.png
|
|
web
|
example.org
|
portalLogo: https://example.org/examplehealth/logo/main.1024x1024.png
|
|
web
|
example.org
|
portalUrl: https://example.org/examplehealth/patient-portal-url
|
|
web
|
health.example.com
|
telecom
: https://health.example.com
|
|
web
|
www.ehchospital.example.com
|
https://www.ehchospital.example.com
|
|
web
|
ehpmadison.example.com
|
brandLogo: https://ehpmadison.example.com/logo.png
|
|
web
|
www.ehpmadison.example.com
|
https://www.ehpmadison.example.com
|
|
web
|
open.ehr.example.com
|
contact
: https://open.ehr.example.com
|
|
web
|
ehr.example.com
|
address
: https://ehr.example.com/ProdFHIR/api/FHIR/R2
|
|
web
|
ehr.example.com
|
address
: https://ehr.example.com/ProdFHIR/api/FHIR/R4
|
|
web
|
example.org
|
brandLogo: https://example.org/examplehospital-ehr1/themes/custom/logo.svg
|
|
web
|
patientgateway.examplehospital.ehr1.example.org
|
portalUrl: https://patientgateway.examplehospital.ehr1.example.org
|
|
web
|
pediatrics.examplehospital.ehr2.example.org
|
portalUrl: https://pediatrics.examplehospital.ehr2.example.org
|
|
web
|
examplehospital.example.org
|
telecom
: https://examplehospital.example.org/contact
|
|
web
|
open.ehr1.example.com
|
contact
: https://open.ehr1.example.com
|
|
web
|
ehr1.example.org
|
address
: https://ehr1.example.org/ExampleHospital/api/FHIR/R4
|
|
web
|
open.ehr2.example.com
|
contact
: https://open.ehr2.example.com
|
|
web
|
ehr2.example.org
|
address
: https://ehr2.example.org/ExampleHospital/api/FHIR/R4
|
|
web
|
example.org
|
brandLogo: https://example.org/brand1/logo/main.svg
|
|
web
|
example.org
|
portalUrl: https://example.org/chart.brand1.org
|
|
web
|
www.brand1.example.com
|
telecom
: https://www.brand1.example.com
|
|
web
|
example.org
|
brandLogo: https://example.org/brand2/logo/main.svg
|
|
web
|
example.org
|
portalUrl: https://example.org/chart.brand2.org
|
|
web
|
open.ehr.com
|
contact
: https://open.ehr.com
|
|
web
|
example.org
|
address
: https://example.org/brand1.org/ProdFHIR/api/FHIR/R4
|
|
web
|
www.omg.org
|
ServD
|
|
web
|
en.wikipedia.org
|
Both Bundle.link and Bundle.entry.link are defined to support providing additional context when Bundles are used (e.g. HATEOAS
).
|
|
web
|
example.org
|
for
: https://example.org/fhir/Patient/123
|
|
web
|
example.org
|
encounter
: https://example.org/fhir/Encounter/456
|
|
web
|
www.example.org
|
value
: https://www.example.org/myapplication
|
|
web
|
www.example.org
|
https://www.example.org/myapplication
|
|
web
|
fhircast.org
|
The profile defines a method through which an app requests
authorization to access a FHIR resource, and then uses that authorization
to retrieve the resource. Synchronization of patient context is not addressed;
for use cases that require context synchronization (e.g., learning about when
the in-context patient changes within an EHR session) see
FHIRcast
. In other words, if the patient chart is
changed during the session, the application will not inherently be updated.
|
|
web
|
developer.mozilla.org
|
Servers that support purely browser-based apps SHALL enable Cross-Origin Resource Sharing (CORS)
as follows:
|
|
web
|
openid.net
|
The following requirements are adopted from OpenID Connect Core 1.0 Specification section 3.1.2.1
:
|
|
web
|
www.simplecloud.info
|
a token granting user/Basic.s?code=https://app|1
with no patient context
and a user context of "fhirUser": "Practitioner/b"
would require additional
policy information to decide whether to allow
Basic?subject=Patient/a&code=https://app|1
. A server MAY simply reject
queries like this as unauthorized, while still supporting many use cases. To
properly authorize this request, a resource server would need to determine
whether EHR policy allows Practitioner B to access Patient A's records. Such
policy information could be static (e.g., a simple system could maintain a
policy like "all Practitioner users can access all patient records") or
dynamically available in EHR-specific ways such as FHIR Groups, CareTeams,
PractitionerRoles, or non-FHIR APIs such as
SCIM
or others. Such policy details are
beyond the scope of SMART on FHIR.
|
|
web
|
www.udap.org
|
E.g., per-device dynamic client registration (see ongoing work on UDAP specifications
)
|
|
web
|
www.carinalliance.com
|
Publicly document any code of conduct that an app adheres to (e.g., CARIN Alliance code of conduct
)
|
|
web
|
developer.mozilla.org
|
Publishers SHALL support Cross-Origin Resource Sharing (CORS)
for all GET requests to the artifacts described in this guide.
|
|
web
|
www.rfc-editor.org
|
RFC7517, JSON Web Key
|
|
web
|
jwt.io
|
Before a client can request an access token, it SHALL generate a
one-time-use JSON Web Token (JWT) that will be used to authenticate the client to
the FHIR authorization server. The authentication JWT SHALL include the
following claims, and SHALL be signed with the client's private
key (which SHOULD be an RS384
or ES384
signature). For a practical reference on JWT, as well as debugging
tools and client libraries, see https://jwt.io
.
|
|
web
|
openid.net
|
response_types_supported
: RECOMMENDED
, Array of OAuth2 response_type
values that are supported. Implementers can refer to response_type
s defined in OAuth 2.0 ( RFC 6749
) and in OIDC Core
.
|
|
web
|
developer.mozilla.org
|
As described in the underlying HTTP specifications, header names are compared in a case-insensitive manner
.
|
|
web
|
smarthealthit.org
|
This implementation guide describes a set of foundational patterns based on OAuth 2.0
for client applications to authorize, authenticate, and integrate with FHIR-based data systems. The patterns defined in this specification are introduced in the sections below. For background on SMART Health IT, see smarthealthit.org
.
|
|
web
|
openid.net
|
When these scopes are requested (and the request is granted), the app will
receive an
id_token
that comes alongside the access token.
|
|
web
|
openid.net
|
This token must be validated according to the OIDC specification
.
To learn more about the user, the app should treat the fhirUser
claim as the
URL of a FHIR resource representing the current user. This URL MAY be absolute
(e.g., https://ehr.example.org/Practitioner/123
), or it MAY be relative to
the FHIR server base URL associated with the current authorization request
(e.g., Practitioner/123
). This will be a resource of type Patient
,
Practitioner
, PractitionerRole
, RelatedPerson
, or Person
.
Note that the FHIR server base URL is the same as the URL represented in the
aud
parameter passed in to the authorization request.
Note that Person
is only used if the other resource types do not apply to the
current user, for example, the "authorized representative" for >1 patients.
|
|
web
|
openid.net
|
The OpenID Connect Core specification
describes a wide surface area with many optional capabilities. To be considered compatible
with the SMART's sso-openid-connect
capability, the following requirements apply:
|
|
web
|
cds-hooks.org
|
optional appContext to be included in the token response as is specified in a CDShooks Link
|
