Allscripts Healthcare Solutions · Authentication Profile

Allscripts Healthcare Solutions Authentication

Authentication

How a client authenticates to the Veradigm (formerly Allscripts) FHIR API. There is no OpenAPI document to derive securitySchemes from, so this profile is read from three live provider-served documents instead: the SMART App Launch configuration on the published sandbox base, the OpenID Connect discovery document on the authorization server it names as issuer, and the FHIR R4 CapabilityStatement, whose rest.security block declares SMART-on-FHIR and carries the SMART oauth-uris extension with the authorize and token endpoints. Veradigm implements the HL7 SMART Application Launch Framework Implementation Guide Release 2.0.0 and OpenID Connect Core 1.0.

Allscripts Healthcare Solutions secures its APIs with oauth2 and openIdConnect across 4 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode, clientCredentials, and refreshToken flow(s).

Healthcare ITEHRClinicalFHIRHL7SMART on FHIRUSCDIInteroperabilityPatient Access21st Century CuresVeradigm
Methods: oauth2, openIdConnect Schemes: 4 OAuth flows: authorizationCode, clientCredentials, refreshToken API key in:

Security Schemes

SMART on FHIR - standalone / EHR launch (authorization code) oauth2
SMART Backend Services (client credentials) oauth2
OpenID Connect openIdConnect
Mutual TLS client authentication mutualTLS

Source

Authentication Profile

allscripts-healthcare-solutions-authentication.yml Raw ↑
generated: '2026-09-01'
method: searched
source: https://fhir.fhirpoint.open.allscripts.com/fhirroute/fhir/CP00101/.well-known/smart-configuration,
  https://fhirecho.fhirpoint.open.allscripts.com/pro/authorization/.well-known/openid-configuration, fhir/allscripts-healthcare-solutions-veradigm-fhir-r4-capabilitystatement.json
docs: https://developer.veradigm.com/Fhir/Introduction
description: 'How a client authenticates to the Veradigm (formerly Allscripts) FHIR API. There is no OpenAPI
  document to derive securitySchemes from, so this profile is read from three live provider-served documents
  instead: the SMART App Launch configuration on the published sandbox base, the OpenID Connect discovery
  document on the authorization server it names as issuer, and the FHIR R4 CapabilityStatement, whose
  rest.security block declares SMART-on-FHIR and carries the SMART oauth-uris extension with the authorize
  and token endpoints. Veradigm implements the HL7 SMART Application Launch Framework Implementation Guide
  Release 2.0.0 and OpenID Connect Core 1.0.'
summary:
  types:
  - oauth2
  - openIdConnect
  api_key_in: []
  oauth2_flows:
  - authorizationCode
  - clientCredentials
  - refreshToken
  pkce:
  - S256
  - plain
  client_types:
  - confidential (client_secret)
  - confidential (private_key_jwt via developer-hosted JWKS)
  - public
  mutual_tls: true
  dpop: true
  pushed_authorization_requests: true
  note: Credentials are not self-service. A developer registers on the Veradigm Connect portal, registers
    a FHIR application (App Type Patient, Provider or System), and the portal issues a Client ID, Secret
    and Secret Expiration Date. Before an application can reach a client organization the customer must
    license it themselves in the separate client License Management Portal - the developer cannot do it
    for them.
schemes:
- name: SMART on FHIR - standalone / EHR launch (authorization code)
  type: oauth2
  flow: authorizationCode
  authorizationUrl: https://fhir.fhirpoint.open.allscripts.com/fhirroute/authorizationV2/CP00101/connect/authorize
  tokenUrl: https://fhir.fhirpoint.open.allscripts.com/fhirroute/authorizationV2/CP00101/connect/token
  pkce:
  - plain
  - S256
  audience: Patient and Provider FHIR applications
  sources:
  - well-known/allscripts-healthcare-solutions-smart-configuration.json
  note: 'The capability statement is the discovery entry point: GET [FHIR base]/metadata returns the SMART
    oauth-uris extension carrying the authorize and token endpoints for that client environment. Redirect
    URLs (up to five) and launch URLs (up to three) are registered per application; desktop clients may
    register urn:ietf:wg:oauth:2.0:oob.'
- name: SMART Backend Services (client credentials)
  type: oauth2
  flow: clientCredentials
  tokenUrl: https://fhir.fhirpoint.open.allscripts.com/fhirroute/authorizationV2/CP00101/connect/token
  audience: System FHIR applications only
  sources:
  - well-known/allscripts-healthcare-solutions-smart-configuration.json
  - https://developer.veradigm.com/Fhir/BulkData
  note: Required for FHIR Bulk Data ($export). The application must be registered with App Type System
    and must publish a JWKS URL so Veradigm can validate the signed client assertion; Patient and User
    application types cannot make bulk data requests.
- name: OpenID Connect
  type: openIdConnect
  openIdConnectUrl: https://fhirecho.fhirpoint.open.allscripts.com/pro/authorization/.well-known/openid-configuration
  issuer: https://fhirecho.fhirpoint.open.allscripts.com/pro/authorization
  jwks_uri: https://fhirecho.fhirpoint.open.allscripts.com/pro/authorization/.well-known/openid-configuration/jwks
  userinfo_endpoint: https://fhirecho.fhirpoint.open.allscripts.com/pro/authorization/connect/userinfo
  introspection_endpoint: https://fhirecho.fhirpoint.open.allscripts.com/pro/authorization/connect/introspect
  revocation_endpoint: https://fhirecho.fhirpoint.open.allscripts.com/pro/authorization/connect/revocation
  end_session_endpoint: https://fhirecho.fhirpoint.open.allscripts.com/pro/authorization/connect/endsession
  id_token_signing_alg_values_supported:
  - RS256
  token_endpoint_auth_methods_supported:
  - client_secret_basic
  - client_secret_post
  - self_signed_tls_client_auth
  - tls_client_auth
  sources:
  - well-known/allscripts-healthcare-solutions-openid-configuration.json
- name: Mutual TLS client authentication
  type: mutualTLS
  evidence: token_endpoint_auth_methods_supported includes tls_client_auth and self_signed_tls_client_auth;
    the discovery document publishes mtls_endpoint_aliases and tls_client_certificate_bound_access_tokens.
  sources:
  - well-known/allscripts-healthcare-solutions-openid-configuration.json
token_lifetime:
  documented: false
  note: Veradigm states token validity is configured per client in the Veradigm License Management Portal,
    so no fixed TTL is published.
  source: https://developer.veradigm.com/Fhir/Introduction
capabilities_advertised:
- launch-ehr
- launch-standalone
- client-public
- client-confidential-symmetric
- context-ehr-patient
- context-ehr-encounter
- context-standalone-patient
- context-standalone-encounter
- context-passthrough-banner
- context-passthrough-style
- context-banner
- context-style
- sso-openid-connect
- permission-offline
- permission-patient
- permission-user
- client-confidential-asymmetric
- authorize-post
- permission-v1
- permission-v2
gated:
  unity_api: The proprietary bidirectional Unity API - the only Veradigm surface that can write patient
    demographic, appointment or financial data - is not documented publicly. Its authentication model
    could not be observed; access requires a paid Veradigm Connect Integrator subscription.

Work with this as data

Every security artifact here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for security posture

4 MCP tools reach this
  • find_securityBrowse and filter every security artifact in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This security artifact
curl "https://apis.io/api/v1/security/allscripts-healthcare-solutions-authentication"
All security posture
curl "https://apis.io/api/v1/security?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.