ONC Certification · API Documentation

Elixir API Developer Portal:FHIR and C-CDA API Documentation

The business and technical documentation for the Elixir EHR API: OAuth 2.0 authentication, FHIR-formatted resource endpoints, the C-CDA all-data request, error handling and terms of use. It is published openly because the certification program requires it, which means no registration, no form and no agreement before you read it.

Start with authentication What this API is, and is not

Why it is public
Developers of certified Health IT Modules are required to publish complete API documentation via a publicly accessible hyperlink, without preconditions or additional steps.
What it covers
Token generation, fourteen FHIR-formatted resource endpoints, the C-CDA all-data request, HTTP status codes and exception handling, and what you need on your side.
Scope, stated plainly
Elixir is certified for application access — patient selection. It is not certified to the standardized API criterion. The difference is explained below rather than left for you to find.

No gate, by obligation
No registration, no form, no agreement. Read it, evaluate it, and decide before you talk to anyone.
OAuth 2.0
Client credentials grant. One token request, then a bearer token on every call.
FHIR and C-CDA
Fourteen FHIR-formatted resource endpoints, plus a C-CDA Continuity of Care Document request.
Built on Salesforce
Elixir runs inside your Salesforce organization, so the API is reached at your own instance URL.

Reference

Authentication: OAuth 2.0 Client Credentials

Elixir uses the OAuth 2.0 client credentials grant. Request a token first, then present the returned access token on every subsequent request. Credentials are issued by the organization whose Elixir instance you are integrating with, not by us.

POSTToken generation{EHR Instance}/services/oauth2/token

Parameters

grant_type      client_credentials
client_id       the client ID issued for your application
client_secret   the client secret issued for your application

Response

{
  "access_token": "String",
  "signature":    "String",
  "instance_url": "https://{salesforce_instance}",
  "id":           "String",
  "token_type":   "String",
  "issued_at":    "String"
}

Use the access_token returned here on each subsequent request. {EHR Instance} throughout this documentation is the Salesforce instance URL of the organization you are integrating with.

Reference

FHIR Resource Endpoints

Each endpoint returns a single resource for the identifier supplied, formatted as a FHIR resource. All requests require a valid bearer token. These endpoints sit under the application access — patient selection criterion Elixir is certified to.

GETFetch Patient{EHR Instance}/services/apexrest/fhir/Patient/{Id}
GETFetch Encounter{EHR Instance}/services/apexrest/fhir/Encounter/{Id}
GETFetch Practitioner{EHR Instance}/services/apexrest/fhir/Practitioner/{Id}
GETFetch Appointment{EHR Instance}/services/apexrest/fhir/Appointment/{Id}
GETFetch Allergy{EHR Instance}/services/apexrest/fhir/Allergy/{Id}
GETFetch Diagnosis{EHR Instance}/services/apexrest/fhir/Diagnosis/{Id}
GETFetch Condition{EHR Instance}/services/apexrest/fhir/Condition/{Id}
GETFetch Coverage{EHR Instance}/services/apexrest/fhir/Claim/{Id}
GETFetch Organization{EHR Instance}/services/apexrest/fhir/Organization/{Id}
GETFetch Procedure{EHR Instance}/services/apexrest/fhir/Procedure/{Id}
GETFetch DiagnosticReport{EHR Instance}/services/apexrest/fhir/DiagnosticReport/{Id}
GETFetch Medication{EHR Instance}/services/apexrest/fhir/Medication/{Id}
GETFetch Location{EHR Instance}/services/apexrest/fhir/Location/{Id}
GETFetch CareTeam{EHR Instance}/services/apexrest/fhir/CareTeam/{Id}

Note that the Coverage endpoint is served at the /Claim/ path. That is the live path and is reproduced here as it is, rather than corrected to what it looks like it should be.

Reference

C-CDA All Data Request

The C-CDA endpoint returns a Continuity of Care Document formatted in accordance with the HL7 C-CDA Release 2.1 implementation guide — the specification Elixir is certified against for Consolidated CDA creation performance.

GETFetch C-CDA document{EHR Instance}/services/apexrest/ccda

Request body

{
  "CDAType":      "Consolidated CDA",
  "strAccountId": "String"
}

For exporting all of a single patient’s electronic health information rather than a care summary, see the electronic health information export capability, which is certified separately.

Reference

Errors and Exception Handling

Errors follow standard HTTP status codes. Failures on the FHIR endpoints return a FHIR OperationOutcome resource carrying an issue array with a code, details and severity.

HTTP status codes returned by the Elixir API and the condition each one indicates.
Status	Meaning	Condition
`400`	Bad request	The request carried an invalid query parameter.
`401`	Unauthorized	The authentication token is absent, expired or invalid.
`403`	Forbidden	The client is authenticated but does not hold permission to make the request.
`404`	Not found	No resource exists for the identifier supplied.
`500`	Internal server error	A general server-side error. Retry the request.

OperationOutcome response shape

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "code":     "invalid",
      "details":  { "text": "String" },
      "severity": "error"
    }
  ]
}

Before you build

Software Requirements and Terms of Use

What you need on your side, and the conditions that attach to calling a live instance.

What you need

An HTTP client library capable of sending RESTful requests.
An OAuth 2.0 client credentials setup for the credentials issued to your application.
A JSON parsing library for handling responses.

Nothing is required to read this documentation. Credentials to call a live instance are issued by the organization whose instance you are integrating with, under their agreement with us.

Terms of use

Data accessed through the Elixir API must be handled in accordance with HIPAA and the agreements in force between the calling organization and the covered entity whose data is being accessed.
Access is restricted to authorized users and permitted applications.
The API is subject to maintenance, and downtime may occur during scheduled updates.

Fees are governed by the contract between the customer organization and us, and the fee types that apply are set out in the costs and limitations disclosure.

Being precise

What This API Is Certified To, and What It Is Not

Two certification criteria govern APIs in certified health IT, and they are routinely conflated. If a federal program is part of why you are integrating, the difference will matter to you.

Required attribution statement

This Health IT Module is compliant with the ONC Certification Criteria for Health IT and has been certified by an ONC-ACB in accordance with the applicable certification criteria adopted by the Secretary of Health and Human Services. This certification does not represent an endorsement by the U.S. Department of Health and Human Services.

Elixir is certified to application access — patient selection. That is the criterion at 170.315(g)(7), and it is the one that governs published API documentation: syntax, function names, required and optional parameters and their data types, return variables and their types and structures, exceptions, and exception-handling methods and their returns. This page is that documentation. The endpoints above are built on top of it.

Elixir is not certified to the standardized API criterion. That is a separate criterion, 170.315(g)(10), with its own requirements including support for the current US Core implementation guide and SMART App Launch specification. We state this plainly because the phrase “FHIR API” is used for both, and because the full list of criteria Elixir holds is published where anyone can check it. If a program you participate in requires the standardized API criterion, raise it with us early rather than late.

What that means for an integration. The endpoints on this page are real, documented and callable, and for most point-to-point integrations — a care coordination tool, an analytics pipeline, a partner system reading patient context — the distinction makes no practical difference. It matters where a program or a counterparty specifically requires the certified standardized API, patient-mediated app access under SMART App Launch, or published service base URLs. Those are the cases to flag in a scoping conversation.

The full certification record, including the certificate number, all twenty-one certified criteria and the real world testing documents, is on the ONC Certification page. Broader context on FHIR, HL7 v2 and information blocking is on the Interoperability page.

For integration teams

Tell us what you are connecting

Most integration scope is settled by which systems are involved and what has to move between them. We would rather work through that than send you a standards list — and if what you need is not on this page, we would rather say so.

Talk to Us ONC Certification