Elation Health

OAuth 2.0 and FHIR R4 integration adapter for Elation Health EHR. Supports patient-facing (standalone) and system-to-system (backend) workflows using client credentials.

Elation Health FHIR R4 standalone-oauth backend-client-credentials

Overview

ConnectHealth's Elation Health integration gives your application secure access to patient data through Elation's OAuth 2.0 and FHIR R4 APIs. ConnectHealth acts as the middleware layer — handling authentication, SMART endpoint discovery, token lifecycle, and FHIR communication — so your team can focus on building features rather than managing Elation-specific OAuth flows.

ℹ

Application Ownership

You (your organization) must create and own Elation FHIR applications. ConnectHealth is middleware — it does NOT create apps or manage Elation developer portal accounts on your behalf. You must have an approved Elation application with a Client ID (and Client Secret for backend flows) before configuring any workflow in ConnectHealth.

Supported Authentication Flows

Click a card to jump to its configuration section.

Standalone OAuth

Standard OAuth 2.0 authorization code flow where patients authorize access to their data via Elation. Uses the Public FHIR Application Client ID (no secret). Best for patient-facing apps that need patient consent.

Backend to Backend (B2B)

OAuth 2.0 Client Credentials flow using Client ID and Client Secret for server-to-server authentication without user interaction. Simpler than Epic — no JWT signing or private key management required. Best for automated data sync and background processing.

Key Features

FHIR R4 resource operations (search, read, create, update)
SMART endpoint auto-discovery (auth/token URLs derived from the FHIR base URL)
Simple client credentials for B2B — no RSA key pairs or JWT signing required
Token refresh and introspection
Audit logging for all operations

Before You Begin

Before you can use Elation with ConnectHealth, you must have a registered FHIR application in the Elation developer portal. Elation provides two separate application types for different use cases.

Prerequisites Checklist

✓ Elation developer account — Contact Elation Health at partnerships@elationhealth.com to get access to the developer portal
✓ Backend FHIR Application (for B2B) — Provides a Client ID and Client Secret for system-to-system flows
✓ Public FHIR Application (for Standalone) — Provides a Client ID only (no secret) for patient-facing flows
✓ Redirect URI registered — Your ConnectHealth callback URL registered with Elation (for Standalone)
✓ For production — Contact Elation to promote your sandbox application to production

Create Your Elation Application

Elation provides separate application credentials for backend and standalone (patient-facing) workflows. Follow these steps to obtain the credentials you need.

Contact Elation Health Partnerships

Reach out to Elation to initiate the onboarding process:

Email partnerships@elationhealth.com to request a sandbox account
Elation will provision a sandbox environment and send you credentials
You will receive two sets of credentials: one for backend (with secret) and one for patient-facing (public client, no secret)

Review Your Credentials

Elation will send you two sets of credentials:

Backend FHIR Application: Client ID + Client Secret — used for system-to-system (B2B) flows where your server accesses Elation without a patient logging in
Public FHIR Application: Client ID only (no secret) — used for patient-facing (Standalone) flows where a patient logs into Elation and authorizes your app

ℹ

Keep Credentials Secure

Store the Backend Client Secret securely (e.g., AWS Secrets Manager). Never expose it in client-side code or share it over unsecured channels. The Public Client ID (for Standalone) has no secret and is safe to use in browser contexts.

Register Your Redirect URI (Standalone only)

For Standalone OAuth, request Elation to register your ConnectHealth callback URL as an allowed redirect URI:

https://your-connecthealth-domain/api/workflow/auth/{integrationId}/callback
You will get the exact {integrationId} from ConnectHealth after creating your connection. Contact Elation to add or update redirect URIs.

Configure in ConnectHealth

Once you have your credentials, configure your Elation connection in ConnectHealth:

In ConnectHealth, navigate to Connections and create a new connection
Select Elation Health as the EHR type
Select your workflow type:
- Standalone for patient-facing applications (use Public FHIR Application credentials)
- Backend for server-to-server automation (use Backend FHIR Application credentials)
Enter your Client ID (and Client Secret for Backend workflow)
Enter the FHIR Base URL — ConnectHealth will auto-discover auth and token endpoints
Save your connection

Test with Sandbox Data

Test your integration using the Elation sandbox environment (see Sandbox Environment Setup below).

For Standalone: Initiate OAuth and log in using the Elation sandbox admin credentials provided by Elation
For Backend: Request a system token and test FHIR calls against the sandbox FHIR base URL
Verify that data flows correctly between Elation and ConnectHealth

Production (When Ready)

⚠

Production Requires Elation Approval

Contact partnerships@elationhealth.com when you are ready to go live. Elation will review your integration and provision production credentials with the production FHIR base URL. Do not use sandbox credentials in production.

Sandbox Environment Setup

Elation provides a sandbox environment at sandbox.elationemr.com for integration testing. Use the credentials provided by Elation for your sandbox account.

Elation Sandbox Endpoints

Purpose	URL
FHIR Base (R4)	`https://sandbox.elationemr.com/fhir/r4/`
OAuth Authorization	`https://sandbox.elationemr.com/api/2.0/oauth2/authorize/`
OAuth Token	`https://sandbox.elationemr.com/api/2.0/oauth2/token/`
Sandbox UI Login	`https://sandbox.elationemr.com/login`

ConnectHealth can auto-discover the Authorization and Token URLs from the FHIR base URL's SMART configuration — in most cases you only need to enter the FHIR Base URL when configuring your connection.

Sandbox vs Production Comparison

Aspect	Sandbox	Production
FHIR Base URL	`https://sandbox.elationemr.com/fhir/r4/`	`https://app.elationemr.com/fhir/r4/`
App Approval	Provisioned by Elation partnerships team	Requires Elation production approval — contact partnerships@elationhealth.com
Data	Synthetic test patients only	Real patient data (HIPAA-covered)
Credentials	Sandbox Client ID (+ Client Secret for backend) from Elation	Separate production credentials — obtained after Elation approval

Configuration Reference

Complete the application setup above (obtain credentials from Elation) before filling in these fields.

ConnectHealth supports two workflow types for Elation. Choose the one that matches your use case.

Standalone OAuth

Standard OAuth 2.0 authorization code flow where patients authorize access to their data via Elation. Uses the Public FHIR Application Client ID — no Client Secret required. Best for patient portals, health tracking apps, and third-party apps needing patient consent.

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your Public FHIR Application Client ID from Elation (patient-facing, no secret).
`Authorization URL`	Yes	Yes	Elation's OAuth authorization endpoint. Auto-discovered from the FHIR base URL's SMART configuration if not provided.
`Token URL`	Yes	Yes	Elation's OAuth token endpoint. Auto-discovered from the FHIR base URL's SMART configuration if not provided.
`Scopes`	No	Yes	Space-separated list of OAuth scopes defining the level of access requested.
`Redirect URL`	Yes	Yes	Your ConnectHealth OAuth callback URL. Must be registered with Elation as an allowed redirect URI.
`FHIR Base URL`	No	Yes	The base URL of the Elation FHIR R4 server. ConnectHealth auto-discovers auth/token endpoints from this URL.

Setup Steps

Use the Public FHIR Application Client ID provided by Elation — there is no client secret for this application type.
Request Elation to register your redirect URI (ConnectHealth callback URL).
Determine the scopes your application needs (e.g., patient/*.read openid fhirUser offline_access).
Enter the FHIR base URL — ConnectHealth will auto-discover the authorization and token endpoints.
Test the authorization flow by initiating a login — the patient should be redirected to Elation to authorize.

Backend to Backend (B2B)

OAuth 2.0 Client Credentials flow for server-to-server authentication without any user interaction. Uses the Backend FHIR Application Client ID and Client Secret. Unlike Epic, Elation does not require JWT assertion — a standard client_id and client_secret is all that is needed. Best for automated data sync, population health analytics, and background processing.

ℹ

Simpler than Epic B2B

Elation's backend authentication uses standard OAuth 2.0 Client Credentials (client_id + client_secret). There is no need to generate RSA key pairs, manage JWKS endpoints, or sign JWT assertions — just provide the credentials Elation gave you.

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your Backend FHIR Application Client ID from Elation.
`Client Secret`	No	Yes	Your Backend FHIR Application Client Secret from Elation. Store securely — never expose in client-side code.
`Token URL`	Yes	Yes	Elation's OAuth token endpoint. Auto-discovered from the FHIR base URL's SMART configuration if not provided.
`FHIR Base URL`	No	Yes	The base URL of the Elation FHIR R4 server. Used for SMART endpoint discovery and FHIR requests.
`Scopes`	No	No	OAuth scopes for backend access. Defaults to `system/*.read` if not specified.

Setup Steps

Use the Backend FHIR Application Client ID and Client Secret provided by Elation.
Store the Client Secret securely in AWS Secrets Manager or your organization's secrets management solution.
Enter the FHIR base URL — ConnectHealth auto-discovers the token endpoint.
Test by requesting a backend token — no user interaction should be required.

General Scopes

Scopes define the level of access your application requests from Elation. Choose the appropriate scopes based on your workflow type and data needs.

Patient Scopes (Standalone)

Patient-level scopes grant access to data for a specific patient who has authorized the application.

Scope	Description
`patient/*.read`	Read all resource types for the authorized patient
`patient/Patient.read`	Read the patient's demographic information
`patient/Observation.read`	Read the patient's observations (vitals, labs)
`patient/Condition.read`	Read the patient's conditions and diagnoses
`patient/MedicationRequest.read`	Read the patient's medication requests

System Scopes (Backend B2B)

System-level scopes grant access for backend/server applications without a specific user context.

Scope	Description
`system/*.read`	Read all resource types at the system level
`system/Patient.read`	Read all patient demographics

Identity Scopes (Standalone)

OpenID Connect scopes for obtaining user identity information.

Scope	Description
`openid`	Required for OpenID Connect — returns an ID token
`fhirUser`	Returns the FHIR resource URL of the authenticated user
`offline_access`	Request a refresh token for long-lived access

Use Cases

Choose the workflow type that best matches your application's needs.

Patient-Facing Applications

Scenario: A third-party app needs to access patient health data with the patient's explicit consent.

Recommended Workflow: Standalone OAuth

Best For: Patient portals, health tracking apps, care management tools

Recommended Scopes: patient/*.read openid fhirUser offline_access

System-to-System Integration

Scenario: A server needs to access Elation data without any user interaction for automated processing.

Recommended Workflow: Backend to Backend (B2B)

Best For: Nightly data sync, population health analytics, automated reporting

Recommended Scopes: system/*.read

Workflow Automation

Scenario: Low-code Node-RED workflows interacting with Elation for automated data pipelines within ConnectHealth.

Recommended Workflow: Backend to Backend (B2B)

Best For: Automated notifications, data transformation pipelines, integration workflows

Recommended Scopes: system/*.read

Get Your ConnectHealth API Key

Several ConnectHealth endpoints — Token Exchange, Backend Token, and Token Refresh — require an ConnectHealth API key passed as the x-api-key header. Without this header, these endpoints return 401 Unauthorized.

Log in to the ConnectHealth Dashboard

Open your ConnectHealth instance and sign in with your account credentials.

Navigate to Settings → API Keys

From the left navigation, click Settings, then open the API Keys tab.

Create a New API Key

Click Create API Key, enter a descriptive name (e.g., elation-prod-client), and submit.

Use the Key in the `x-api-key` Header

Pass the key on every request to a protected endpoint:

curl -X GET "https://<your-connecthealth-domain>/api/workflow/auth/{integrationId}/token" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Accept: application/json"

API Endpoints

These are the ConnectHealth endpoints your application will interact with. All paths are prefixed with /api/workflow/auth/{integrationId}, where {integrationId} is the connection ID you created in ConnectHealth.

🔑

API Key Required on Token Endpoints

Token Exchange, Backend Token, and Token Refresh all require the x-api-key header. Create a key from Settings → API Keys before calling these endpoints.

Authentication Endpoints

Method	Endpoint	Description	API Key
`GET`	`/api/workflow/auth/{integrationId}/start`	Initiate OAuth flow for standalone launch. Typically opened in a browser — redirects to Elation login.	No
`GET`	`/api/workflow/auth/{integrationId}/callback`	OAuth redirect URI. Called by Elation after user authorization — not by your client. Exchanges the code for tokens and returns a one-time `tokenId`.	No
`GET`	`/api/workflow/auth/{integrationId}/token/exchange/{tokenId}`	Exchange a one-time `tokenId` for the actual access token. The `tokenId` is consumed on read.	Yes
`GET`	`/api/workflow/auth/{integrationId}/token`	Request a Backend (B2B) system token using client credentials. No user interaction.	Yes
`POST`	`/api/workflow/auth/{integrationId}/token/refresh`	Refresh an expiring access token. Requires a previously issued refresh token (requested via `offline_access` scope).	Yes
`GET`	`/api/workflow/auth/{integrationId}/introspect`	Optional diagnostic endpoint that inspects the currently stored token for the integration.	No

Examples

Backend Token (B2B)

Request a system-level access token using client credentials.

curl

curl -X GET "https://<your-connecthealth-domain>/api/workflow/auth/{integrationId}/token" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Accept: application/json"

JavaScript (fetch)

const res = await fetch(
  `https://<your-connecthealth-domain>/api/workflow/auth/${integrationId}/token`,
  {
    headers: {
      "x-api-key": process.env.EHRCONNECT_API_KEY,
      "Accept": "application/json",
    },
  }
);
const { access_token, expires_in, scope } = await res.json();

Token Exchange (Standalone)

Exchange a one-time tokenId for an access token after a Standalone OAuth flow.

curl

curl -X GET "https://<your-connecthealth-domain>/api/workflow/auth/{integrationId}/token/exchange/{tokenId}" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Accept: application/json"

Token Refresh

Refresh an access token before expiry. Only works if offline_access was requested.

curl

curl -X POST "https://<your-ch-domain>/api/workflow/auth/{integrationId}/token/refresh" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"refresh_token": "YOUR_REFRESH_TOKEN"}'

JavaScript (fetch)

const res = await fetch(
  `https://<your-ch-domain>/api/workflow/auth/${integrationId}/token/refresh`,
  {
    method: "POST",
    headers: {
      "x-api-key": process.env.CH_API_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ refresh_token: "YOUR_REFRESH_TOKEN" }),
  }
);
const { access_token, refresh_token, expires_in } = await res.json();

Response

{
  "body": {
    "access_token": "eyJhbGc...",
    "refresh_token": "dGhpcyBp...",
    "token_type": "Bearer",
    "expires_in": 3600,
    "scope": "patient/*.read",
    "patient": "patient-id-if-applicable"
  },
  "message": "Token refreshed successfully",
  "timestamp": 1718000000000
}

External Resources

Elation FHIR API Documentation — Official Elation FHIR R4 API reference
Elation Sandbox Login — Access the Elation sandbox UI for manual testing
partnerships@elationhealth.com — Contact Elation to request sandbox access, register redirect URIs, or promote to production
FHIR R4 Specification
SMART App Launch Guide

Elation Health

OAuth 2.0 and FHIR R4 integration adapter for Elation Health EHR. Supports patient-facing (standalone) and system-to-system (backend) workflows using client credentials.

Elation Health FHIR R4 standalone-oauth backend-client-credentials

Overview

ℹ

Application Ownership

Supported Authentication Flows

Click a card to jump to its configuration section.

Standalone OAuth

Backend to Backend (B2B)

Key Features

FHIR R4 resource operations (search, read, create, update)
SMART endpoint auto-discovery (auth/token URLs derived from the FHIR base URL)
Simple client credentials for B2B — no RSA key pairs or JWT signing required
Token refresh and introspection
Audit logging for all operations

Before You Begin

Before you can use Elation with ConnectHealth, you must have a registered FHIR application in the Elation developer portal. Elation provides two separate application types for different use cases.

Prerequisites Checklist

✓ Elation developer account — Contact Elation Health at partnerships@elationhealth.com to get access to the developer portal
✓ Backend FHIR Application (for B2B) — Provides a Client ID and Client Secret for system-to-system flows
✓ Public FHIR Application (for Standalone) — Provides a Client ID only (no secret) for patient-facing flows
✓ Redirect URI registered — Your ConnectHealth callback URL registered with Elation (for Standalone)
✓ For production — Contact Elation to promote your sandbox application to production

Create Your Elation Application

Elation provides separate application credentials for backend and standalone (patient-facing) workflows. Follow these steps to obtain the credentials you need.

Contact Elation Health Partnerships

Reach out to Elation to initiate the onboarding process:

Email partnerships@elationhealth.com to request a sandbox account
Elation will provision a sandbox environment and send you credentials
You will receive two sets of credentials: one for backend (with secret) and one for patient-facing (public client, no secret)

Review Your Credentials

Elation will send you two sets of credentials:

Backend FHIR Application: Client ID + Client Secret — used for system-to-system (B2B) flows where your server accesses Elation without a patient logging in
Public FHIR Application: Client ID only (no secret) — used for patient-facing (Standalone) flows where a patient logs into Elation and authorizes your app

ℹ

Keep Credentials Secure

Register Your Redirect URI (Standalone only)

For Standalone OAuth, request Elation to register your ConnectHealth callback URL as an allowed redirect URI:

Configure in ConnectHealth

Once you have your credentials, configure your Elation connection in ConnectHealth:

In ConnectHealth, navigate to Connections and create a new connection
Select Elation Health as the EHR type
Select your workflow type:
- Standalone for patient-facing applications (use Public FHIR Application credentials)
- Backend for server-to-server automation (use Backend FHIR Application credentials)
Enter your Client ID (and Client Secret for Backend workflow)
Enter the FHIR Base URL — ConnectHealth will auto-discover auth and token endpoints
Save your connection

Test with Sandbox Data

Test your integration using the Elation sandbox environment (see Sandbox Environment Setup below).

For Standalone: Initiate OAuth and log in using the Elation sandbox admin credentials provided by Elation
For Backend: Request a system token and test FHIR calls against the sandbox FHIR base URL
Verify that data flows correctly between Elation and ConnectHealth

Production (When Ready)

⚠

Production Requires Elation Approval

Sandbox Environment Setup

Elation provides a sandbox environment at sandbox.elationemr.com for integration testing. Use the credentials provided by Elation for your sandbox account.

Elation Sandbox Endpoints

Purpose	URL
FHIR Base (R4)	`https://sandbox.elationemr.com/fhir/r4/`
OAuth Authorization	`https://sandbox.elationemr.com/api/2.0/oauth2/authorize/`
OAuth Token	`https://sandbox.elationemr.com/api/2.0/oauth2/token/`
Sandbox UI Login	`https://sandbox.elationemr.com/login`

Sandbox vs Production Comparison

Aspect	Sandbox	Production
FHIR Base URL	`https://sandbox.elationemr.com/fhir/r4/`	`https://app.elationemr.com/fhir/r4/`
App Approval	Provisioned by Elation partnerships team	Requires Elation production approval — contact partnerships@elationhealth.com
Data	Synthetic test patients only	Real patient data (HIPAA-covered)
Credentials	Sandbox Client ID (+ Client Secret for backend) from Elation	Separate production credentials — obtained after Elation approval

Configuration Reference

Complete the application setup above (obtain credentials from Elation) before filling in these fields.

ConnectHealth supports two workflow types for Elation. Choose the one that matches your use case.

Standalone OAuth

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your Public FHIR Application Client ID from Elation (patient-facing, no secret).
`Authorization URL`	Yes	Yes	Elation's OAuth authorization endpoint. Auto-discovered from the FHIR base URL's SMART configuration if not provided.
`Token URL`	Yes	Yes	Elation's OAuth token endpoint. Auto-discovered from the FHIR base URL's SMART configuration if not provided.
`Scopes`	No	Yes	Space-separated list of OAuth scopes defining the level of access requested.
`Redirect URL`	Yes	Yes	Your ConnectHealth OAuth callback URL. Must be registered with Elation as an allowed redirect URI.
`FHIR Base URL`	No	Yes	The base URL of the Elation FHIR R4 server. ConnectHealth auto-discovers auth/token endpoints from this URL.

Setup Steps

Use the Public FHIR Application Client ID provided by Elation — there is no client secret for this application type.
Request Elation to register your redirect URI (ConnectHealth callback URL).
Determine the scopes your application needs (e.g., patient/*.read openid fhirUser offline_access).
Enter the FHIR base URL — ConnectHealth will auto-discover the authorization and token endpoints.
Test the authorization flow by initiating a login — the patient should be redirected to Elation to authorize.

Backend to Backend (B2B)

ℹ

Simpler than Epic B2B

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your Backend FHIR Application Client ID from Elation.
`Client Secret`	No	Yes	Your Backend FHIR Application Client Secret from Elation. Store securely — never expose in client-side code.
`Token URL`	Yes	Yes	Elation's OAuth token endpoint. Auto-discovered from the FHIR base URL's SMART configuration if not provided.
`FHIR Base URL`	No	Yes	The base URL of the Elation FHIR R4 server. Used for SMART endpoint discovery and FHIR requests.
`Scopes`	No	No	OAuth scopes for backend access. Defaults to `system/*.read` if not specified.

Setup Steps

Use the Backend FHIR Application Client ID and Client Secret provided by Elation.
Store the Client Secret securely in AWS Secrets Manager or your organization's secrets management solution.
Enter the FHIR base URL — ConnectHealth auto-discovers the token endpoint.
Test by requesting a backend token — no user interaction should be required.

General Scopes

Scopes define the level of access your application requests from Elation. Choose the appropriate scopes based on your workflow type and data needs.

Patient Scopes (Standalone)

Patient-level scopes grant access to data for a specific patient who has authorized the application.

Scope	Description
`patient/*.read`	Read all resource types for the authorized patient
`patient/Patient.read`	Read the patient's demographic information
`patient/Observation.read`	Read the patient's observations (vitals, labs)
`patient/Condition.read`	Read the patient's conditions and diagnoses
`patient/MedicationRequest.read`	Read the patient's medication requests

System Scopes (Backend B2B)

System-level scopes grant access for backend/server applications without a specific user context.

Scope	Description
`system/*.read`	Read all resource types at the system level
`system/Patient.read`	Read all patient demographics

Identity Scopes (Standalone)

OpenID Connect scopes for obtaining user identity information.

Scope	Description
`openid`	Required for OpenID Connect — returns an ID token
`fhirUser`	Returns the FHIR resource URL of the authenticated user
`offline_access`	Request a refresh token for long-lived access

Use Cases

Choose the workflow type that best matches your application's needs.

Patient-Facing Applications

Scenario: A third-party app needs to access patient health data with the patient's explicit consent.

Recommended Workflow: Standalone OAuth

Best For: Patient portals, health tracking apps, care management tools

Recommended Scopes: patient/*.read openid fhirUser offline_access

System-to-System Integration

Scenario: A server needs to access Elation data without any user interaction for automated processing.

Recommended Workflow: Backend to Backend (B2B)

Best For: Nightly data sync, population health analytics, automated reporting

Recommended Scopes: system/*.read

Workflow Automation

Scenario: Low-code Node-RED workflows interacting with Elation for automated data pipelines within ConnectHealth.

Recommended Workflow: Backend to Backend (B2B)

Best For: Automated notifications, data transformation pipelines, integration workflows

Recommended Scopes: system/*.read

Get Your ConnectHealth API Key

Log in to the ConnectHealth Dashboard

Open your ConnectHealth instance and sign in with your account credentials.

Navigate to Settings → API Keys

From the left navigation, click Settings, then open the API Keys tab.

Create a New API Key

Click Create API Key, enter a descriptive name (e.g., elation-prod-client), and submit.

Use the Key in the `x-api-key` Header

Pass the key on every request to a protected endpoint:

curl -X GET "https://<your-connecthealth-domain>/api/workflow/auth/{integrationId}/token" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Accept: application/json"

API Endpoints

🔑

API Key Required on Token Endpoints

Token Exchange, Backend Token, and Token Refresh all require the x-api-key header. Create a key from Settings → API Keys before calling these endpoints.

Authentication Endpoints

Method	Endpoint	Description	API Key
`GET`	`/api/workflow/auth/{integrationId}/start`	Initiate OAuth flow for standalone launch. Typically opened in a browser — redirects to Elation login.	No
`GET`	`/api/workflow/auth/{integrationId}/callback`	OAuth redirect URI. Called by Elation after user authorization — not by your client. Exchanges the code for tokens and returns a one-time `tokenId`.	No
`GET`	`/api/workflow/auth/{integrationId}/token/exchange/{tokenId}`	Exchange a one-time `tokenId` for the actual access token. The `tokenId` is consumed on read.	Yes
`GET`	`/api/workflow/auth/{integrationId}/token`	Request a Backend (B2B) system token using client credentials. No user interaction.	Yes
`POST`	`/api/workflow/auth/{integrationId}/token/refresh`	Refresh an expiring access token. Requires a previously issued refresh token (requested via `offline_access` scope).	Yes
`GET`	`/api/workflow/auth/{integrationId}/introspect`	Optional diagnostic endpoint that inspects the currently stored token for the integration.	No

Examples

Backend Token (B2B)

Request a system-level access token using client credentials.

curl

curl -X GET "https://<your-connecthealth-domain>/api/workflow/auth/{integrationId}/token" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Accept: application/json"

JavaScript (fetch)

const res = await fetch(
  `https://<your-connecthealth-domain>/api/workflow/auth/${integrationId}/token`,
  {
    headers: {
      "x-api-key": process.env.EHRCONNECT_API_KEY,
      "Accept": "application/json",
    },
  }
);
const { access_token, expires_in, scope } = await res.json();

Token Exchange (Standalone)

Exchange a one-time tokenId for an access token after a Standalone OAuth flow.

curl

curl -X GET "https://<your-connecthealth-domain>/api/workflow/auth/{integrationId}/token/exchange/{tokenId}" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Accept: application/json"

Token Refresh

Refresh an access token before expiry. Only works if offline_access was requested.

curl

curl -X POST "https://<your-ch-domain>/api/workflow/auth/{integrationId}/token/refresh" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"refresh_token": "YOUR_REFRESH_TOKEN"}'

JavaScript (fetch)

const res = await fetch(
  `https://<your-ch-domain>/api/workflow/auth/${integrationId}/token/refresh`,
  {
    method: "POST",
    headers: {
      "x-api-key": process.env.CH_API_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ refresh_token: "YOUR_REFRESH_TOKEN" }),
  }
);
const { access_token, refresh_token, expires_in } = await res.json();

Response

{
  "body": {
    "access_token": "eyJhbGc...",
    "refresh_token": "dGhpcyBp...",
    "token_type": "Bearer",
    "expires_in": 3600,
    "scope": "patient/*.read",
    "patient": "patient-id-if-applicable"
  },
  "message": "Token refreshed successfully",
  "timestamp": 1718000000000
}

External Resources

Elation FHIR API Documentation — Official Elation FHIR R4 API reference
Elation Sandbox Login — Access the Elation sandbox UI for manual testing
partnerships@elationhealth.com — Contact Elation to request sandbox access, register redirect URIs, or promote to production
FHIR R4 Specification
SMART App Launch Guide

Elation Health

Overview

On This Page

Supported Authentication Flows

Standalone OAuth

Backend to Backend (B2B)

Key Features

Before You Begin

Prerequisites Checklist

Create Your Elation Application

Contact Elation Health Partnerships

Review Your Credentials

Register Your Redirect URI (Standalone only)

Configure in ConnectHealth

Test with Sandbox Data

Production (When Ready)

Sandbox Environment Setup

Elation Sandbox Endpoints

Sandbox vs Production Comparison

Configuration Reference

Standalone OAuth

Setup Steps

Backend to Backend (B2B)

Setup Steps

General Scopes

Patient Scopes (Standalone)

System Scopes (Backend B2B)

Identity Scopes (Standalone)

Use Cases

Patient-Facing Applications

System-to-System Integration

Workflow Automation

Get Your ConnectHealth API Key

Log in to the ConnectHealth Dashboard

Navigate to Settings → API Keys

Create a New API Key

Use the Key in the x-api-key Header

API Endpoints

Authentication Endpoints

Examples

Backend Token (B2B)

curl

JavaScript (fetch)

Token Exchange (Standalone)

curl

Token Refresh

curl

JavaScript (fetch)

Response

External Resources

Elation Health

Overview

On This Page

Supported Authentication Flows

Standalone OAuth

Backend to Backend (B2B)

Key Features

Before You Begin

Prerequisites Checklist

Create Your Elation Application

Contact Elation Health Partnerships

Review Your Credentials

Register Your Redirect URI (Standalone only)

Configure in ConnectHealth

Test with Sandbox Data

Production (When Ready)

Sandbox Environment Setup

Elation Sandbox Endpoints

Sandbox vs Production Comparison

Configuration Reference

Standalone OAuth

Setup Steps

Backend to Backend (B2B)

Setup Steps

General Scopes

Patient Scopes (Standalone)

System Scopes (Backend B2B)

Identity Scopes (Standalone)

Use Cases

Patient-Facing Applications

Use the Key in the `x-api-key` Header

Use the Key in the `x-api-key` Header