MEDITECH

Complete OAuth 2.0 and FHIR R4/STU3 integration adapter for MEDITECH EHR systems (Expanse). Supports patient-facing, system-to-system, and embedded EHR launch workflows with full FHIR resource operations and bulk data export.

MEDITECH FHIR R4 FHIR STU3 standalone-oauth backend-jwt smart-on-fhir

Overview

ConnectHealth's MEDITECH integration gives your application secure access to patient data and clinical workflows through MEDITECH Expanse'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 MEDITECH-specific OAuth flows.

ℹ

Application Ownership

You (your organization) must own MEDITECH application credentials. ConnectHealth is middleware — it does NOT manage MEDITECH Greenfield registrations or submit applications on your behalf, so you must have a Client ID issued by MEDITECH Greenfield 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 users authorize access to their data via MEDITECH Patient and Consumer Health (PCHE) portal. Best for patient portals, health tracking apps, and third-party apps needing patient consent.

Backend to Backend (B2B)

JWT Bearer assertion flow for server-to-server authentication without any user interaction. Best for automated data sync, population health analytics, and background processing.

Embed Launch

SMART on FHIR launch flow for applications embedded within MEDITECH Expanse's clinical interface. The app is launched from within the EHR and receives patient and encounter context automatically. Best for clinical decision support and in-context clinical tools.

Key Features

FHIR resource CRUD operations
Bulk data export
SMART endpoint auto-discovery (auth/token URLs derived from the FHIR base URL)
JWT Bearer assertion for B2B (RSA key pair managed by ConnectHealth)
Token refresh
Embed Launch with automatic patient and encounter context
Audit logging for all operations

Before You Begin

Before you can use MEDITECH with ConnectHealth, you must register with MEDITECH Greenfield Workspace. This section outlines the prerequisites and gives you a step-by-step guide to get started.

Prerequisites Checklist

✓ MEDITECH Greenfield Workspace access — Register via MEDITECH Greenfield — the MEDITECH team will review and grant access
✓ MEDITECH-issued credentials — Client ID (and Client Secret if applicable) issued by the MEDITECH Greenfield team after registration
✓ Redirect URI confirmed — Your ConnectHealth callback URL confirmed with MEDITECH Greenfield (for Standalone and Embed Launch)
✓ For B2B: JWKS URI registered — Copy the JWKS URI from ConnectHealth and provide it to the MEDITECH Greenfield support team (MEDITECH verifies JWT assertions using this public key endpoint)
✓ For production — Coordination with the MEDITECH Expanse administrator at your customer's organization to activate the app on their instance

Create Your MEDITECH Application

Follow these steps to register your MEDITECH application. MEDITECH Greenfield handles the registration and issues your credentials — this is a support-team-mediated process, not a self-service portal.

Register for MEDITECH Greenfield Workspace

Start by visiting MEDITECH's REST API Resources page to access Greenfield Workspace documentation and registration information.

Review the Greenfield Workspace requirements and available API resources
Contact the MEDITECH Greenfield support team to initiate your registration
MEDITECH will review your organization's request before granting Greenfield access

Submit Your Application Registration to MEDITECH Greenfield

Contact the MEDITECH Greenfield support team to register your application. Provide the following information:

Application name and description (e.g., "ConnectHealth Integration - Sandbox")
Application type — let MEDITECH know which workflow(s) you need:
- Standalone (patient-facing): Patient Access — authorization code flow
- Backend (B2B): System Access — JWT Bearer / client_credentials
- Embed Launch (in-EHR): SMART on FHIR EHR Launch
Redirect URI (for Standalone / Embed Launch) — your ConnectHealth OAuth callback URL
JWKS URI (for B2B) — the public key endpoint from ConnectHealth for JWT verification

MEDITECH will review your submission and issue your Client ID and (if applicable) Client Secret.

Receive Your Client ID and Configure Credentials

Once MEDITECH Greenfield approves your registration, they will issue your credentials. Store these securely and configure ConnectHealth:

Use the Client ID issued by MEDITECH Greenfield — you will enter this in ConnectHealth when setting up your connection
For Standalone and Embed Launch: Confirm with MEDITECH that your Redirect URI (OAuth callback URL) is registered: https://your-connecthealth-domain/api/workflow/auth/{integrationId}/callback
You will get the exact {integrationId} from ConnectHealth after creating your connection
For Embed Launch: Also confirm the Launch URL is registered: https://your-connecthealth-domain/api/workflow/auth/{integrationId}/launch
For B2B (Backend): Copy the JWKS URI from your ConnectHealth connection settings and provide it to the MEDITECH Greenfield support team. This is how MEDITECH verifies your JWT assertions without sharing private keys

Request Access to Your Customer's MEDITECH Instance

Once your app is registered, you need to request access to your customer's specific MEDITECH Expanse instance:

Share your Client ID with the MEDITECH Expanse administrator at your customer's organization
Their administrator must approve and activate your application on their instance
Once activated, you will receive the instance-specific FHIR base URL (e.g., https://fhir.yourorg.meditech.com/ehr/api/FHIR/R4)
For sandbox testing, MEDITECH provides a shared sandbox environment (see Sandbox section below)

Configure in ConnectHealth

Now you're ready to configure your MEDITECH connection in ConnectHealth:

In ConnectHealth, navigate to Connections and create a new connection
Select MEDITECH as the EHR type
Select your workflow type:
- Standalone for patient-facing applications
- Backend for server-to-server automation
- Embed Launch for in-EHR applications
Paste your Client ID issued by MEDITECH Greenfield
Fill in the FHIR Base URL — ConnectHealth auto-discovers auth and token endpoints from it via SMART configuration
For B2B: ConnectHealth auto-generates an RSA key pair — copy the JWKS URI shown in your connection settings and send it to the MEDITECH Greenfield support team (if not done already in Step 3)
Save your connection

Test with Sandbox Data

Test your integration using MEDITECH's sandbox environment (see Sandbox Environment Setup below for test data and URLs).

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

Production App (When Ready)

⚠

Production Requires Customer's Administrator Approval

MEDITECH production access requires coordination with your customer's IT team:

Your MEDITECH Greenfield-issued Client ID must be approved by the MEDITECH Expanse administrator at your customer's organization.
The production FHIR base URL is unique per customer — you must obtain it from their MEDITECH admin.

The production URL is not global — each MEDITECH customer runs their own hosted Expanse instance (e.g., https://fhir.yourhospital.meditech.com/ehr/api/FHIR/R4), which you must obtain from your customer's MEDITECH administrator. Do not attempt to go live until both app approval and URL confirmation are in place.

When you're ready to go to production:

Share your MEDITECH Greenfield-issued Client ID with your customer's MEDITECH Expanse administrator
Coordinate with their admin to activate your application on their production instance
Obtain the production FHIR base URL from their administrator
Create a new production connection in ConnectHealth using your production Client ID and the customer's MEDITECH FHIR base URL
Notify the MEDITECH Greenfield support team of any production redirect URI or JWKS URI changes if they differ from sandbox
See the MEDITECH REST API Resources for detailed production guidance

Sandbox Environment Setup

MEDITECH provides a sandbox environment for integration testing through MEDITECH Greenfield. You will need a Client ID issued by MEDITECH Greenfield to access the sandbox. MEDITECH also provides shared test patient data for quick functional testing — listed below.

Shared Test Data (MEDITECH Sandbox)

Use the following sandbox endpoints for validating your integration. Note: You still need a MEDITECH Greenfield-issued Client ID — these are sandbox service URLs, not shared application credentials.

MEDITECH Sandbox Endpoints

Purpose	URL
FHIR Base (R4)	`https://sandbox.meditech.com/ehr/api/FHIR/R4`
OAuth Authorization	`https://sandbox.meditech.com/ehr/oauth2/authorize`
OAuth Token	`https://sandbox.meditech.com/ehr/oauth2/token`
SMART Configuration	`https://sandbox.meditech.com/ehr/api/FHIR/R4/.well-known/smart-configuration`

ConnectHealth auto-discovers the Authorization and Token URLs from the SMART Configuration endpoint — in most cases you only need to enter the FHIR Base URL when configuring your connection.

Test Patient Data

Sandbox Patient Login: Use test patient credentials provided when your Greenfield Workspace registration is approved for sandbox access
Contact MEDITECH Support: To request specific test patient IDs for your sandbox environment, contact the MEDITECH Greenfield support team
Group ID (bulk export): Obtain test Group IDs from MEDITECH sandbox documentation or support

For complete sandbox test data details, refer to MEDITECH's REST API Resources documentation.

Sandbox vs Production Comparison

Understand the key differences between sandbox and production MEDITECH environments:

Aspect	Sandbox	Production
FHIR Base URL	`sandbox.meditech.com/ehr/api/FHIR/R4`	Customer's own Expanse instance (e.g., `fhir.yourhospital.meditech.com/ehr/api/FHIR/R4`)
App Approval	Greenfield Workspace access (approved by MEDITECH)	MEDITECH Greenfield registration + customer's MEDITECH admin must separately activate the app
Data	Synthetic test patients only	Real patient data (HIPAA-covered)
Credentials	Client ID issued by MEDITECH Greenfield	Same Client ID — activated by customer admin on their production instance
Approval Timeline	Hours to 1 day	Days to weeks (customer admin activation)
FHIR Base URL format	Single shared sandbox URL	Unique per customer — obtain from your customer's MEDITECH admin

Important: MEDITECH does not have a global production URL. Every MEDITECH customer runs their own hosted Expanse instance. You must obtain the production FHIR base URL directly from the MEDITECH administrator at your customer's organization — there is no single "MEDITECH production URL" you can use across all customers.

Configuration Reference

Complete Steps 1–4 above (register with MEDITECH Greenfield and receive your Client ID) before filling in these fields. You will need your Client ID and an approved MEDITECH application to proceed.

ConnectHealth supports multiple workflow types for this integration. 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 MEDITECH's Patient and Consumer Health (PCHE) portal. Best for patient portals, health tracking apps, and third-party apps needing patient consent.

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your unique application identifier issued by MEDITECH Greenfield.
`Client Secret`	No	No	Required only for confidential clients. Public MEDITECH patient-facing apps may not use a Client Secret.
`Authorization URL`	Yes	Yes	MEDITECH's OAuth authorization endpoint. Auto-discovered from the FHIR base URL's SMART configuration if not provided.
`Token URL`	Yes	Yes	MEDITECH'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 match the redirect URI confirmed with MEDITECH Greenfield.
`FHIR Base URL`	No	Yes	The base URL of the MEDITECH FHIR server. ConnectHealth auto-discovers auth/token endpoints from this URL.

Setup Steps

Submit your registration to MEDITECH Greenfield as a patient-access app and note the Client ID they issue.
Confirm that MEDITECH Greenfield has registered your redirect URI (ConnectHealth callback URL).
Determine the scopes your application needs (e.g., patient/*.read openid fhirUser).
Enter the FHIR base URL — ConnectHealth will auto-discover the authorization and token endpoints.
Configure the Standalone workflow in ConnectHealth with all the fields above.
Test the authorization flow by initiating a login — the user should be redirected to MEDITECH's patient portal to authorize.

Backend to Backend (B2B)

JWT Bearer assertion flow for server-to-server authentication without any user interaction. ConnectHealth automatically generates and manages the RSA key pair for you. Best for automated data sync, population health analytics, and background processing.

ℹ

JWT Bearer Assertion for MEDITECH B2B

MEDITECH backend applications use JWT Bearer assertion for authentication. ConnectHealth generates an RSA key pair — you provide the public key (JWKS URI) to the MEDITECH Greenfield support team, and ConnectHealth signs JWT assertions using the private key.

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your unique application identifier issued by MEDITECH Greenfield.
`Private Key`	Yes	Yes	PEM-encoded RSA private key used to sign JWT assertions. Automatically generated and managed by ConnectHealth — copy the corresponding JWKS URI and provide it to the MEDITECH Greenfield support team.
`Token URL`	Yes	Yes	MEDITECH'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 MEDITECH FHIR server. Used for SMART endpoint discovery and FHIR requests.
`Scopes`	No	Yes	Space-separated list of system-level OAuth scopes (e.g., `system/*.read`).

Setup Steps

Submit your registration to MEDITECH Greenfield as a system/backend application.
In ConnectHealth, create the Backend connection — ConnectHealth will auto-generate an RSA key pair (RS384).
Copy the JWKS URI from your ConnectHealth connection settings and provide it to the MEDITECH Greenfield support team for your application registration.
Enter your FHIR base URL — ConnectHealth auto-discovers the token endpoint.
Test by requesting a backend token — no user interaction should be required.

SMART on FHIR - Embed Launch

SMART on FHIR launch flow for applications embedded within MEDITECH Expanse's clinical interface. The app is launched from within MEDITECH and receives patient and encounter context automatically. ConnectHealth auto-discovers MEDITECH's SMART endpoints from the iss parameter on launch. Best for clinical decision support, order entry helpers, and in-context clinical tools.

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your unique application identifier issued by MEDITECH Greenfield.
`Client Secret`	No	No	Required only for confidential clients. Public MEDITECH SMART apps may not use a Client Secret.

Setup Steps

Submit your registration to MEDITECH Greenfield as a SMART on FHIR EHR Launch application.
Provide your Launch URL to the MEDITECH Greenfield support team: https://your-connecthealth-domain/api/workflow/auth/{integrationId}/launch
Provide your Redirect URI to the MEDITECH Greenfield support team: https://your-connecthealth-domain/api/workflow/auth/{integrationId}/callback
Configure the Embed Launch workflow in ConnectHealth with the Client ID (and Client Secret if confidential).
Your app needs to handle the tokenId returned by ConnectHealth and call the token exchange endpoint to retrieve the access token.
Test by launching your app from within the MEDITECH Expanse sandbox environment.

How to Handle SMART Launch

Once your Embed Launch app is configured, here's the end-to-end flow — from MEDITECH initiating the launch, to your app receiving a usable FHIR access token. Each step is tied to the exact ConnectHealth endpoint involved.

MEDITECH Initiates the Launch

When a clinician opens your app from within MEDITECH Expanse, MEDITECH calls your registered Launch URL:

GET https://<your-ch-domain>/api/workflow/auth/{integrationId}/launch?iss=...&launch=...

iss — MEDITECH's FHIR base URL for that customer's Expanse instance (e.g., https://fhir.yourhospital.meditech.com/ehr/api/FHIR/R4)
launch — an opaque token carrying patient and encounter context

ConnectHealth auto-discovers MEDITECH's SMART endpoints (auth URL, token URL) from the iss parameter — you don't need to hardcode these. No action needed from you — this is the Launch URL you provided to MEDITECH Greenfield.

ConnectHealth Completes OAuth and Returns a `tokenId`

ConnectHealth exchanges the launch token with MEDITECH server-side, stores the resulting access token securely on the backend, and redirects back to your embedded app with a short-lived tokenId (a UUID) appended to the URL. The tokenId is one-time use — it's consumed on read and cannot be replayed.

Call Token Exchange to Retrieve the Access Token

Your app must call the Token Exchange endpoint with the tokenId. This endpoint requires the x-api-key header — without it, you will get a 401:

GET https://<your-ch-domain>/api/workflow/auth/{integrationId}/token/exchange/{tokenId}
Headers:
  x-api-key: <your-connecthealth-api-key>
  Accept: application/json

Response contains access_token, patient, encounter (if available), scope, expires_in, and — if offline_access was requested — a refresh_token.

🔑

Don't have a ConnectHealth API Key yet?

Jump to Get Your ConnectHealth API Key to create one from the Settings tab before calling Token Exchange.

Call FHIR Using the Access Token

Use the access_token as a Bearer token against MEDITECH's FHIR base URL. In sandbox, use the MEDITECH sandbox URL; in production, use the customer's Expanse instance URL:

Sandbox: https://sandbox.meditech.com/ehr/api/FHIR/R4
Production: https://fhir.yourhospital.meditech.com/ehr/api/FHIR/R4 (customer-specific — obtain from their MEDITECH admin)

GET {fhirBaseUrl}/Patient/{patient}
Headers:
  Authorization: Bearer {access_token}
  Accept: application/fhir+json

Refresh Before Expiry

Access tokens expire (typically in minutes). Before the token expires, call the Token Refresh endpoint to obtain a new one without re-prompting the user. Like Token Exchange, this requires x-api-key:

POST https://<your-ch-domain>/api/workflow/auth/{integrationId}/token/refresh
Headers:
  x-api-key: <your-connecthealth-api-key>
  Content-Type: application/json

Body:
{
  "refresh_token": "<your-refresh-token>"
}

Refresh only works if offline_access was included in your requested scopes.

General Scopes

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

User Scopes

User-level scopes grant access based on the permissions of the logged-in clinician or user.

Scope	Description
`user/*.read`	Read all resource types the user has access to
`user/Patient.read`	Read patient demographics the user can access
`user/Encounter.read`	Read encounter records the user can access

System Scopes

System-level scopes grant access for backend/server applications without a specific user context. Used with the Backend to Backend (B2B) workflow.

Scope	Description
`system/*.read`	Read all resource types at the system level
`system/Patient.read`	Read all patient demographics
`system/Group.read`	Read patient groups (required for bulk data export)

Launch Scopes

Launch scopes are used with SMART on FHIR to receive context from the EHR launch.

Scope	Description
`launch`	Required for EHR launch — receives the launch context from MEDITECH Expanse
`launch/patient`	Request patient context in a standalone or patient-facing EHR launch
`launch/encounter`	Request encounter context in a provider-facing EHR launch

Identity Scopes

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 launch/patient offline_access

System-to-System Integration

Scenario: A server needs to access MEDITECH 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

EHR-Embedded Applications

Scenario: An application launched from within MEDITECH Expanse's clinical workflow that receives patient and encounter context automatically.

Recommended Workflow: Embed Launch (SMART on FHIR)

Best For: Clinical decision support, order entry helpers, documentation assistants

Recommended Scopes: launch openid fhirUser patient/*.read launch/encounter

Bulk Data Export

Scenario: Extracting large datasets from MEDITECH for analytics, research, or population health.

Recommended Workflow: Backend to Backend (B2B)

Best For: Population health reports, research datasets, quality measure reporting

Recommended Scopes: system/*.read system/Group.read

Workflow Automation

Scenario: Low-code Node-RED workflows interacting with MEDITECH 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 a ConnectHealth API key passed as the x-api-key header. Without this header, these endpoints return 401 Unauthorized. Follow these steps to create your API key.

Log in to the ConnectHealth Dashboard

Open your ConnectHealth instance (the URL where your deployment is hosted) and sign in with your account credentials.

Navigate to Settings → API Keys

From the left navigation, click Settings, then open the API Keys tab. If you have never generated a key before, the list will be empty.

Create a New API Key

Click Create API Key, enter a descriptive name (e.g., meditech-prod-client or embed-launch-dev), and submit. Use one key per environment or per client application so you can rotate individual keys without affecting others.

Copy Your API Key

ConnectHealth automatically saves your API key securely. You can view and copy the key value from Settings → API Keys at any time. Click your key name to reveal and copy it whenever you need it.

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

Pass the key on every request to a protected endpoint using the header name x-api-key (lowercase, hyphenated). Example:

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

Endpoints requiring this header are listed in the API Endpoints section below.

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 hit from a browser; returns a redirect to MEDITECH's patient portal.	No
`GET`	`/api/workflow/auth/{integrationId}/callback`	OAuth redirect URI. Called by MEDITECH after user authorization — not by your client. Exchanges the code for tokens and stores them, returning a one-time `tokenId`.	No
`GET`	`/api/workflow/auth/{integrationId}/launch`	SMART on FHIR EHR Launch URL. Called by MEDITECH with `iss` and `launch` query params — not by your client. ConnectHealth auto-discovers SMART endpoints from `iss`.	No
`GET`	`/api/workflow/auth/{integrationId}/token/exchange/{tokenId}`	Exchange a one-time `tokenId` for the actual access token and patient/encounter context. The `tokenId` is consumed on read.	Yes
`GET`	`/api/workflow/auth/{integrationId}/token`	Request a Backend (B2B) system token using JWT Bearer assertion. 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}/token/status/{tokenId}`	Check whether a `tokenId` is still valid and ready to exchange. Does not consume the token.	No
`GET`	`/api/workflow/auth/{integrationId}/introspect`	Optional diagnostic endpoint that inspects the currently stored token for the integration.	No
`GET`	`/api/workflow/auth/{integrationId}/health`	Optional liveness check for the integration's auth pipeline.	No

Examples

Copy-paste examples for the client-callable endpoints. Replace <your-ch-domain>, {integrationId}, {tokenId}, and YOUR_API_KEY with your actual values.

Token Exchange

Exchange a one-time tokenId for an access token + patient/encounter context after Standalone or Embed Launch flows.

curl

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

JavaScript (fetch)

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

Backend Token (B2B)

Request a system-level access token for server-to-server flows using JWT Bearer assertion.

curl

curl -X GET "https://<your-ch-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-ch-domain>/api/workflow/auth/${integrationId}/token`,
  {
    headers: {
      "x-api-key": process.env.CH_API_KEY,
      "Accept": "application/json",
    },
  }
);
const { access_token, expires_in, scope } = await res.json();

Token Refresh

Refresh an access token before expiry. Only works if the original token was issued with offline_access.

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
}

Token Status

Check if a one-time tokenId is still valid and ready to exchange. Non-consuming.

curl

curl -X GET "https://<your-ch-domain>/api/workflow/auth/{integrationId}/token/status/{tokenId}" \
  -H "Accept: application/json"

JavaScript (fetch)

const res = await fetch(
  `https://<your-ch-domain>/api/workflow/auth/${integrationId}/token/status/${tokenId}`,
  { headers: { "Accept": "application/json" } }
);
const { valid, expiresAt } = await res.json();

OAuth Start (browser-initiated)

Begin the Standalone OAuth flow. Typically opened in a browser so the user can authorize with MEDITECH's patient portal.

curl (inspect redirect only)

curl -I "https://<your-ch-domain>/api/workflow/auth/{integrationId}/start"

Example Launch URL (provided to MEDITECH Greenfield):

https://demo.ehrconnect.healthconnect.systems/api/workflow/auth/[your-integration-id]/launch

Replace the domain and integration ID with your actual values.

External Resources

MEDITECH REST API Resources — Developer documentation and Greenfield Workspace registration
MEDITECH Expanse — Overview of the MEDITECH Expanse platform
SMART App Launch Guide
FHIR R4 Specification

MEDITECH

MEDITECH FHIR R4 FHIR STU3 standalone-oauth backend-jwt smart-on-fhir

Overview

ℹ

Application Ownership

Supported Authentication Flows

Click a card to jump to its configuration section.

Standalone OAuth

Backend to Backend (B2B)

JWT Bearer assertion flow for server-to-server authentication without any user interaction. Best for automated data sync, population health analytics, and background processing.

Embed Launch

Key Features

FHIR resource CRUD operations
Bulk data export
SMART endpoint auto-discovery (auth/token URLs derived from the FHIR base URL)
JWT Bearer assertion for B2B (RSA key pair managed by ConnectHealth)
Token refresh
Embed Launch with automatic patient and encounter context
Audit logging for all operations

Before You Begin

Before you can use MEDITECH with ConnectHealth, you must register with MEDITECH Greenfield Workspace. This section outlines the prerequisites and gives you a step-by-step guide to get started.

Prerequisites Checklist

✓ MEDITECH Greenfield Workspace access — Register via MEDITECH Greenfield — the MEDITECH team will review and grant access
✓ MEDITECH-issued credentials — Client ID (and Client Secret if applicable) issued by the MEDITECH Greenfield team after registration
✓ Redirect URI confirmed — Your ConnectHealth callback URL confirmed with MEDITECH Greenfield (for Standalone and Embed Launch)
✓ For B2B: JWKS URI registered — Copy the JWKS URI from ConnectHealth and provide it to the MEDITECH Greenfield support team (MEDITECH verifies JWT assertions using this public key endpoint)
✓ For production — Coordination with the MEDITECH Expanse administrator at your customer's organization to activate the app on their instance

Create Your MEDITECH Application

Register for MEDITECH Greenfield Workspace

Start by visiting MEDITECH's REST API Resources page to access Greenfield Workspace documentation and registration information.

Review the Greenfield Workspace requirements and available API resources
Contact the MEDITECH Greenfield support team to initiate your registration
MEDITECH will review your organization's request before granting Greenfield access

Submit Your Application Registration to MEDITECH Greenfield

Contact the MEDITECH Greenfield support team to register your application. Provide the following information:

Application name and description (e.g., "ConnectHealth Integration - Sandbox")
Application type — let MEDITECH know which workflow(s) you need:
- Standalone (patient-facing): Patient Access — authorization code flow
- Backend (B2B): System Access — JWT Bearer / client_credentials
- Embed Launch (in-EHR): SMART on FHIR EHR Launch
Redirect URI (for Standalone / Embed Launch) — your ConnectHealth OAuth callback URL
JWKS URI (for B2B) — the public key endpoint from ConnectHealth for JWT verification

MEDITECH will review your submission and issue your Client ID and (if applicable) Client Secret.

Receive Your Client ID and Configure Credentials

Once MEDITECH Greenfield approves your registration, they will issue your credentials. Store these securely and configure ConnectHealth:

Use the Client ID issued by MEDITECH Greenfield — you will enter this in ConnectHealth when setting up your connection
For Standalone and Embed Launch: Confirm with MEDITECH that your Redirect URI (OAuth callback URL) is registered: https://your-connecthealth-domain/api/workflow/auth/{integrationId}/callback
You will get the exact {integrationId} from ConnectHealth after creating your connection
For Embed Launch: Also confirm the Launch URL is registered: https://your-connecthealth-domain/api/workflow/auth/{integrationId}/launch
For B2B (Backend): Copy the JWKS URI from your ConnectHealth connection settings and provide it to the MEDITECH Greenfield support team. This is how MEDITECH verifies your JWT assertions without sharing private keys

Request Access to Your Customer's MEDITECH Instance

Once your app is registered, you need to request access to your customer's specific MEDITECH Expanse instance:

Share your Client ID with the MEDITECH Expanse administrator at your customer's organization
Their administrator must approve and activate your application on their instance
Once activated, you will receive the instance-specific FHIR base URL (e.g., https://fhir.yourorg.meditech.com/ehr/api/FHIR/R4)
For sandbox testing, MEDITECH provides a shared sandbox environment (see Sandbox section below)

Configure in ConnectHealth

Now you're ready to configure your MEDITECH connection in ConnectHealth:

In ConnectHealth, navigate to Connections and create a new connection
Select MEDITECH as the EHR type
Select your workflow type:
- Standalone for patient-facing applications
- Backend for server-to-server automation
- Embed Launch for in-EHR applications
Paste your Client ID issued by MEDITECH Greenfield
Fill in the FHIR Base URL — ConnectHealth auto-discovers auth and token endpoints from it via SMART configuration
For B2B: ConnectHealth auto-generates an RSA key pair — copy the JWKS URI shown in your connection settings and send it to the MEDITECH Greenfield support team (if not done already in Step 3)
Save your connection

Test with Sandbox Data

Test your integration using MEDITECH's sandbox environment (see Sandbox Environment Setup below for test data and URLs).

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

Production App (When Ready)

⚠

Production Requires Customer's Administrator Approval

MEDITECH production access requires coordination with your customer's IT team:

Your MEDITECH Greenfield-issued Client ID must be approved by the MEDITECH Expanse administrator at your customer's organization.
The production FHIR base URL is unique per customer — you must obtain it from their MEDITECH admin.

When you're ready to go to production:

Share your MEDITECH Greenfield-issued Client ID with your customer's MEDITECH Expanse administrator
Coordinate with their admin to activate your application on their production instance
Obtain the production FHIR base URL from their administrator
Create a new production connection in ConnectHealth using your production Client ID and the customer's MEDITECH FHIR base URL
Notify the MEDITECH Greenfield support team of any production redirect URI or JWKS URI changes if they differ from sandbox
See the MEDITECH REST API Resources for detailed production guidance

Sandbox Environment Setup

Shared Test Data (MEDITECH Sandbox)

MEDITECH Sandbox Endpoints

Purpose	URL
FHIR Base (R4)	`https://sandbox.meditech.com/ehr/api/FHIR/R4`
OAuth Authorization	`https://sandbox.meditech.com/ehr/oauth2/authorize`
OAuth Token	`https://sandbox.meditech.com/ehr/oauth2/token`
SMART Configuration	`https://sandbox.meditech.com/ehr/api/FHIR/R4/.well-known/smart-configuration`

ConnectHealth auto-discovers the Authorization and Token URLs from the SMART Configuration endpoint — in most cases you only need to enter the FHIR Base URL when configuring your connection.

Test Patient Data

Sandbox Patient Login: Use test patient credentials provided when your Greenfield Workspace registration is approved for sandbox access
Contact MEDITECH Support: To request specific test patient IDs for your sandbox environment, contact the MEDITECH Greenfield support team
Group ID (bulk export): Obtain test Group IDs from MEDITECH sandbox documentation or support

For complete sandbox test data details, refer to MEDITECH's REST API Resources documentation.

Sandbox vs Production Comparison

Understand the key differences between sandbox and production MEDITECH environments:

Aspect	Sandbox	Production
FHIR Base URL	`sandbox.meditech.com/ehr/api/FHIR/R4`	Customer's own Expanse instance (e.g., `fhir.yourhospital.meditech.com/ehr/api/FHIR/R4`)
App Approval	Greenfield Workspace access (approved by MEDITECH)	MEDITECH Greenfield registration + customer's MEDITECH admin must separately activate the app
Data	Synthetic test patients only	Real patient data (HIPAA-covered)
Credentials	Client ID issued by MEDITECH Greenfield	Same Client ID — activated by customer admin on their production instance
Approval Timeline	Hours to 1 day	Days to weeks (customer admin activation)
FHIR Base URL format	Single shared sandbox URL	Unique per customer — obtain from your customer's MEDITECH admin

Configuration Reference

ConnectHealth supports multiple workflow types for this integration. Choose the one that matches your use case.

Standalone OAuth

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your unique application identifier issued by MEDITECH Greenfield.
`Client Secret`	No	No	Required only for confidential clients. Public MEDITECH patient-facing apps may not use a Client Secret.
`Authorization URL`	Yes	Yes	MEDITECH's OAuth authorization endpoint. Auto-discovered from the FHIR base URL's SMART configuration if not provided.
`Token URL`	Yes	Yes	MEDITECH'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 match the redirect URI confirmed with MEDITECH Greenfield.
`FHIR Base URL`	No	Yes	The base URL of the MEDITECH FHIR server. ConnectHealth auto-discovers auth/token endpoints from this URL.

Setup Steps

Submit your registration to MEDITECH Greenfield as a patient-access app and note the Client ID they issue.
Confirm that MEDITECH Greenfield has registered your redirect URI (ConnectHealth callback URL).
Determine the scopes your application needs (e.g., patient/*.read openid fhirUser).
Enter the FHIR base URL — ConnectHealth will auto-discover the authorization and token endpoints.
Configure the Standalone workflow in ConnectHealth with all the fields above.
Test the authorization flow by initiating a login — the user should be redirected to MEDITECH's patient portal to authorize.

Backend to Backend (B2B)

ℹ

JWT Bearer Assertion for MEDITECH B2B

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your unique application identifier issued by MEDITECH Greenfield.
`Private Key`	Yes	Yes	PEM-encoded RSA private key used to sign JWT assertions. Automatically generated and managed by ConnectHealth — copy the corresponding JWKS URI and provide it to the MEDITECH Greenfield support team.
`Token URL`	Yes	Yes	MEDITECH'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 MEDITECH FHIR server. Used for SMART endpoint discovery and FHIR requests.
`Scopes`	No	Yes	Space-separated list of system-level OAuth scopes (e.g., `system/*.read`).

Setup Steps

Submit your registration to MEDITECH Greenfield as a system/backend application.
In ConnectHealth, create the Backend connection — ConnectHealth will auto-generate an RSA key pair (RS384).
Copy the JWKS URI from your ConnectHealth connection settings and provide it to the MEDITECH Greenfield support team for your application registration.
Enter your FHIR base URL — ConnectHealth auto-discovers the token endpoint.
Test by requesting a backend token — no user interaction should be required.

SMART on FHIR - Embed Launch

Field	Autofill	Required	Description
`Client ID`	No	Yes	Your unique application identifier issued by MEDITECH Greenfield.
`Client Secret`	No	No	Required only for confidential clients. Public MEDITECH SMART apps may not use a Client Secret.

Setup Steps

Submit your registration to MEDITECH Greenfield as a SMART on FHIR EHR Launch application.
Provide your Launch URL to the MEDITECH Greenfield support team: https://your-connecthealth-domain/api/workflow/auth/{integrationId}/launch
Provide your Redirect URI to the MEDITECH Greenfield support team: https://your-connecthealth-domain/api/workflow/auth/{integrationId}/callback
Configure the Embed Launch workflow in ConnectHealth with the Client ID (and Client Secret if confidential).
Your app needs to handle the tokenId returned by ConnectHealth and call the token exchange endpoint to retrieve the access token.
Test by launching your app from within the MEDITECH Expanse sandbox environment.

How to Handle SMART Launch

MEDITECH Initiates the Launch

When a clinician opens your app from within MEDITECH Expanse, MEDITECH calls your registered Launch URL:

GET https://<your-ch-domain>/api/workflow/auth/{integrationId}/launch?iss=...&launch=...

iss — MEDITECH's FHIR base URL for that customer's Expanse instance (e.g., https://fhir.yourhospital.meditech.com/ehr/api/FHIR/R4)
launch — an opaque token carrying patient and encounter context

ConnectHealth Completes OAuth and Returns a `tokenId`

Call Token Exchange to Retrieve the Access Token

Your app must call the Token Exchange endpoint with the tokenId. This endpoint requires the x-api-key header — without it, you will get a 401:

GET https://<your-ch-domain>/api/workflow/auth/{integrationId}/token/exchange/{tokenId}
Headers:
  x-api-key: <your-connecthealth-api-key>
  Accept: application/json

Response contains access_token, patient, encounter (if available), scope, expires_in, and — if offline_access was requested — a refresh_token.

🔑

Don't have a ConnectHealth API Key yet?

Jump to Get Your ConnectHealth API Key to create one from the Settings tab before calling Token Exchange.

Call FHIR Using the Access Token

Use the access_token as a Bearer token against MEDITECH's FHIR base URL. In sandbox, use the MEDITECH sandbox URL; in production, use the customer's Expanse instance URL:

Sandbox: https://sandbox.meditech.com/ehr/api/FHIR/R4
Production: https://fhir.yourhospital.meditech.com/ehr/api/FHIR/R4 (customer-specific — obtain from their MEDITECH admin)

GET {fhirBaseUrl}/Patient/{patient}
Headers:
  Authorization: Bearer {access_token}
  Accept: application/fhir+json

Refresh Before Expiry

POST https://<your-ch-domain>/api/workflow/auth/{integrationId}/token/refresh
Headers:
  x-api-key: <your-connecthealth-api-key>
  Content-Type: application/json

Body:
{
  "refresh_token": "<your-refresh-token>"
}

Refresh only works if offline_access was included in your requested scopes.

General Scopes

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

User Scopes

User-level scopes grant access based on the permissions of the logged-in clinician or user.

Scope	Description
`user/*.read`	Read all resource types the user has access to
`user/Patient.read`	Read patient demographics the user can access
`user/Encounter.read`	Read encounter records the user can access

System Scopes

System-level scopes grant access for backend/server applications without a specific user context. Used with the Backend to Backend (B2B) workflow.

Scope	Description
`system/*.read`	Read all resource types at the system level
`system/Patient.read`	Read all patient demographics
`system/Group.read`	Read patient groups (required for bulk data export)

Launch Scopes

Launch scopes are used with SMART on FHIR to receive context from the EHR launch.

Scope	Description
`launch`	Required for EHR launch — receives the launch context from MEDITECH Expanse
`launch/patient`	Request patient context in a standalone or patient-facing EHR launch
`launch/encounter`	Request encounter context in a provider-facing EHR launch

Identity Scopes

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 launch/patient offline_access

System-to-System Integration

Scenario: A server needs to access MEDITECH 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

EHR-Embedded Applications

Scenario: An application launched from within MEDITECH Expanse's clinical workflow that receives patient and encounter context automatically.

Recommended Workflow: Embed Launch (SMART on FHIR)

Best For: Clinical decision support, order entry helpers, documentation assistants

Recommended Scopes: launch openid fhirUser patient/*.read launch/encounter

Bulk Data Export

Scenario: Extracting large datasets from MEDITECH for analytics, research, or population health.

Recommended Workflow: Backend to Backend (B2B)

Best For: Population health reports, research datasets, quality measure reporting

Recommended Scopes: system/*.read system/Group.read

Workflow Automation

Scenario: Low-code Node-RED workflows interacting with MEDITECH 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 (the URL where your deployment is hosted) and sign in with your account credentials.

Navigate to Settings → API Keys

From the left navigation, click Settings, then open the API Keys tab. If you have never generated a key before, the list will be empty.

Create a New API Key

Copy Your API Key

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

Pass the key on every request to a protected endpoint using the header name x-api-key (lowercase, hyphenated). Example:

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

Endpoints requiring this header are listed in the API Endpoints section below.

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 hit from a browser; returns a redirect to MEDITECH's patient portal.	No
`GET`	`/api/workflow/auth/{integrationId}/callback`	OAuth redirect URI. Called by MEDITECH after user authorization — not by your client. Exchanges the code for tokens and stores them, returning a one-time `tokenId`.	No
`GET`	`/api/workflow/auth/{integrationId}/launch`	SMART on FHIR EHR Launch URL. Called by MEDITECH with `iss` and `launch` query params — not by your client. ConnectHealth auto-discovers SMART endpoints from `iss`.	No
`GET`	`/api/workflow/auth/{integrationId}/token/exchange/{tokenId}`	Exchange a one-time `tokenId` for the actual access token and patient/encounter context. The `tokenId` is consumed on read.	Yes
`GET`	`/api/workflow/auth/{integrationId}/token`	Request a Backend (B2B) system token using JWT Bearer assertion. 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}/token/status/{tokenId}`	Check whether a `tokenId` is still valid and ready to exchange. Does not consume the token.	No
`GET`	`/api/workflow/auth/{integrationId}/introspect`	Optional diagnostic endpoint that inspects the currently stored token for the integration.	No
`GET`	`/api/workflow/auth/{integrationId}/health`	Optional liveness check for the integration's auth pipeline.	No

Examples

Copy-paste examples for the client-callable endpoints. Replace <your-ch-domain>, {integrationId}, {tokenId}, and YOUR_API_KEY with your actual values.

Token Exchange

Exchange a one-time tokenId for an access token + patient/encounter context after Standalone or Embed Launch flows.

curl

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

JavaScript (fetch)

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

Backend Token (B2B)

Request a system-level access token for server-to-server flows using JWT Bearer assertion.

curl

curl -X GET "https://<your-ch-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-ch-domain>/api/workflow/auth/${integrationId}/token`,
  {
    headers: {
      "x-api-key": process.env.CH_API_KEY,
      "Accept": "application/json",
    },
  }
);
const { access_token, expires_in, scope } = await res.json();

Token Refresh

Refresh an access token before expiry. Only works if the original token was issued with offline_access.

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
}

Token Status

Check if a one-time tokenId is still valid and ready to exchange. Non-consuming.

curl

curl -X GET "https://<your-ch-domain>/api/workflow/auth/{integrationId}/token/status/{tokenId}" \
  -H "Accept: application/json"

JavaScript (fetch)

const res = await fetch(
  `https://<your-ch-domain>/api/workflow/auth/${integrationId}/token/status/${tokenId}`,
  { headers: { "Accept": "application/json" } }
);
const { valid, expiresAt } = await res.json();

OAuth Start (browser-initiated)

Begin the Standalone OAuth flow. Typically opened in a browser so the user can authorize with MEDITECH's patient portal.

curl (inspect redirect only)

curl -I "https://<your-ch-domain>/api/workflow/auth/{integrationId}/start"

Example Launch URL (provided to MEDITECH Greenfield):

https://demo.ehrconnect.healthconnect.systems/api/workflow/auth/[your-integration-id]/launch

Replace the domain and integration ID with your actual values.

External Resources

MEDITECH REST API Resources — Developer documentation and Greenfield Workspace registration
MEDITECH Expanse — Overview of the MEDITECH Expanse platform
SMART App Launch Guide
FHIR R4 Specification

MEDITECH

Overview

On This Page

Supported Authentication Flows

Standalone OAuth

Backend to Backend (B2B)

Embed Launch

Key Features

Before You Begin

Prerequisites Checklist

Create Your MEDITECH Application

Register for MEDITECH Greenfield Workspace

Submit Your Application Registration to MEDITECH Greenfield

Receive Your Client ID and Configure Credentials

Request Access to Your Customer's MEDITECH Instance

Configure in ConnectHealth

Test with Sandbox Data

Production App (When Ready)

Sandbox Environment Setup

Shared Test Data (MEDITECH Sandbox)

MEDITECH Sandbox Endpoints

Test Patient Data

Sandbox vs Production Comparison

Configuration Reference

Standalone OAuth

Setup Steps

Backend to Backend (B2B)

Setup Steps

SMART on FHIR - Embed Launch

Setup Steps

How to Handle SMART Launch

MEDITECH Initiates the Launch

ConnectHealth Completes OAuth and Returns a tokenId

Call Token Exchange to Retrieve the Access Token

Call FHIR Using the Access Token

Refresh Before Expiry

General Scopes

User Scopes

System Scopes

Launch Scopes

Identity Scopes

Use Cases

Patient-Facing Applications

System-to-System Integration

EHR-Embedded Applications

Bulk Data Export

Workflow Automation

Get Your ConnectHealth API Key

Log in to the ConnectHealth Dashboard

Navigate to Settings → API Keys

Create a New API Key

Copy Your API Key

Use the Key in the x-api-key Header

API Endpoints

Authentication Endpoints

Examples

Token Exchange

curl

JavaScript (fetch)

Backend Token (B2B)

curl

JavaScript (fetch)

Token Refresh

curl

JavaScript (fetch)

Response

Token Status

curl

JavaScript (fetch)

OAuth Start (browser-initiated)

curl (inspect redirect only)

External Resources

MEDITECH

Overview

On This Page

Supported Authentication Flows

Standalone OAuth

Backend to Backend (B2B)

Embed Launch

Key Features

ConnectHealth Completes OAuth and Returns a `tokenId`

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

ConnectHealth Completes OAuth and Returns a `tokenId`

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