HealthPartners logo Overview

SMART on FHIR defines how third-party applications securely access FHIR APIs using OAuth 2.0 and OpenID Connect (OIDC). HealthPartners supports the SMART App Launch workflow for confidential, standalone client applications and provides a sandbox environment with synthetic data for integration testing.

Our SMART configuration is published at [FHIR base]/.well-known/smart-configuration and includes the authorization, token, registration and introspection endpoints that client applications use to discover our OAuth capabilities.

Security requirements by API
  • Patient Access API: Requires end-user authorization via the SMART authorization code flow. Access tokens must include patient context and patient-level scopes ( patient/*.rs and launch/patient). Members can revoke access grants at any time.
  • Provider Directory API: Does not require end-user authentication. Clients use the OAuth client credentials flow with system-level scopes (system/*.rs) to access provider data.

Our gateway validates access tokens based on the subscription plan. Patient Access plans require patient-level scopes and a patient claim. Provider Directory plans require system-level scopes and must not include a patient claim.

Getting access
  1. Sign up for a developer account in the developer portal.
  2. Create a client application and register redirect URIs.
  3. Subscribe the client application to the appropriate plan (Patient Access API for the authorization code flow or Provider Directory API for the client credentials flow).
  4. Request production access when ready (manual approval is required).

If you need access to multiple plans, create separate client applications for each plan.

Sandbox vs production access

Sandbox access is provisioned automatically when your client application is created and subscribed to a plan. Use the sandbox product to test integrations with synthetic data.

The sandbox base URL is: https://sandbox.api-developerportal.healthpartners.com/interop/external/fhir

Production access requires a separate approval step. Request production access once your integration is ready for review.

The production base URL is: https://api-developerportal.healthpartners.com/interop/external/fhir

Client registration in our gateway

During registration, our gateway issues a single client_id and client_secret that can be used across sandbox and production. Register one or more fully specified redirect URIs for your client application.

Register your application in our gateway by creating a new client app, adding redirect URIs, and saving the issued client_id and client_secret for use in your OAuth flows.

Redirect URI rules

  • URIs must match exactly.
  • A trailing slash must match exactly (a URI with / at the end will not match one without it).
  • Only registered redirect URIs will be accepted.
OAuth flows Two distinct authorization models are supported, depending on whether access is tied to an individual patient or to a system acting on its own behalf. Patient Access API uses the authorization code flow, where the patient authenticates and consents to data access. All API requests made with the token are performed on behalf of the authenticated patient and only return data the patient is permitted to see. Provider Directory API uses the client credentials flow, and there is no login or consent step. This token grants system-level, read-only access to publicly available provider directory data and is not associated with an individual patient. Authorization code flow (Patient Access API)
  1. Redirect the member to the authorization endpoint with response_type=code, your client_id, and your registered redirect_uri.
  2. Include the following SMART scopes: openid, fhirUser, launch/patient, and patient/*.rs. No other scopes are supported for Patient Access API tokens, including specific FHIR resource or wildcard scopes.
  3. The authorization server redirects back with an auth code.
  4. Exchange the auth code for tokens at the token endpoint using Basic authentication (client_id:client_secret).
Example authorization request
GET <authorization_endpoint>?response_type=code
&client_id=<client_id>
&redirect_uri=https://client-app.com/redirect
&scope=openid fhirUser launch/patient patient/*.rs
Example redirect response
https://client-app.com/redirect?code=<auth_code>
Example auth code exchange
POST <token_endpoint>
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
code=<auth_code>
redirect_uri=https://client-app.com/redirect
Client credentials flow (Provider Directory API)
  1. Call the token endpoint directly with grant_type=client_credentials.
  2. Request the system-level scope system/*.rs. No other scopes are supported for Provider Directory API tokens.
  3. Use the returned access token to call the API.
Example client credentials request
POST <token_endpoint>
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
scope=openid fhirUser system/*.rs
Example token response
{
  "access_token": "<access_token>",
  "scope": "openid fhirUser launch/patient patient/*.rs",
  "id_token": "<id_token>",
  "token_type": "Bearer",
  "expires_in": 3599
}
Example FHIR request
curl --request GET   --url <fhir_endpoint>   --header 'Authorization: Bearer <access_token>'
Refresh token redemption

If your authorization flow returned a refresh token, you can exchange it for a new access token by calling the token endpoint again.

Example refresh token request
POST <token_endpoint>
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
refresh_token=<refresh_token>
Scope overview
  • patient/*.rs: required patient-level scope for Patient Access API.
  • launch/patient: provides patient context in the access token.
  • openid and fhirUser: required for SMART auth and user context.
  • system/*.rs: system-level access for Provider Directory clients.

Currently, we do not support user-level scopes (user/*.rs ) or EHR launch contexts.

Sandbox test members

The sandbox environment includes synthetic members and sample data to support end-to-end testing without affecting production records.


Username Password Patient identifier
sbx-patientAccessMember-1 hpTest11 ffaa7043-d695-4cf0-a541-945bca539041
sbx-patientAccessMember-2 hpTest22 b5631ecf-b58c-48f5-87f0-b9988f41969b
sbx-patientAccessMember-3 hpTest33 3db6ef9b-0278-4350-b6cc-857096540993

Additional synthetic FHIR resources (patients, organizations, practitioners, locations, coverage, encounters, conditions, observations and more) are available for testing.

Helpful links SMART App Launch Conformance SMART Scopes and Launch Context SMART App Launch Example (symmetric auth) More resources