SmartClient

The SmartClient is used to:

• Handle the launch from an EHR
  • Looks up well-known
  • Handles PKCE verification
  • Redirects to the FHIR authorization server
• Handle the callback after an authorized user returns from the FHIR authorization server
  • Verifies PKCE and state
  • Retrieves the access token, ID-token and refresh token as well as Smart on FHIR context
  • Refreshing tokens using the refresh token when needed
• Manage users sessions

class SmartClient(...)

Normal usage of SmartClient, only needs to provide a sessionId and client configuration, as well as a backing store.

Name	Type	Description
sessionId	string	Current users sessionId
storage	SmartStorage	Server side storage implementation
config	SmartClientConfiguration	Smart on FHIR client configuration
options?	SmartClientOptions | null	Options for enabling or disabling certain features

class SmartClient(...) (multi-launch mode)

To enable support for launching multiple sessions using the same sessionId, you need to instantiate the SmartClient with an extra patient ID during initialization.

Name	Description	Type
session	Current sessionId and activePatient (if present)	{ sessionId: string, activePatient: string | null }
storage	Server side storage implementation	SmartStorage
config	Smart on FHIR client configuration	SmartClientConfiguration
options?	Options for enabling or disabling certain features	SmartClientOptions & { enableMultiLaunch: true }

When multi-launch mode is enabled, when the client redirects to the final redirectUrl, it will include the patient query parameter with the launched patients ID (FHIR). This must be parsed from the URL by the application and stored in for example sessionStorage.

This ID must be used in any subsequent instantiations of the SmartClient (and it's subsequent .ready() calls) to ensure that each session is correctly associated with the launched patient.

An example of the typical flow when using multi-launch mode, steps 1-5 are normal, 6-8 are specific to multi-launch mode:

1. EHR launches the application as normal
2. sessionId is generated by the application, and is set as a secure cookie
3. The application does a smartClient.launch(...)
4. User is redirected to the FHIR authorization server
5. The application handles the callback and uses smartClient.callback()
6. The web-application is launched with the ?patient=<id> in the URL
7. The web-application retrieves the query parameter, stores it in sessionStorage, and removes it from the URL.
8. The web-application passes the patient ID (now in session storage) back to the server when the server needs to fetch any data, and the SmartClient is instantiated with both the sessionId (cookie) and activePatient (from session storage, passed to the server) and creates a ReadyClient scoped to that specific patient.