Welcome to the HealtheIntent open development documentation. The HealtheIntent open development ecosystem allows access to population health based concepts through RESTful APIs. These APIs are meant to be consumed by other systems/applications in a B2B (Business to business) context. As such, there is no user-level authorization or filtering applied; it is expected that the systems/applications interacting with these APIs are applying the appropriate authorization controls for end users.


The HealtheIntent APIs support two different mechanisms for authenticating API calls. The newer, and simpler, authentication mechanism is bearer token authentication. All but one of the existing APIs support bearer token authentication – The Data Collector API does not support bearer tokens. Alternatively, all APIs also support two-legged OAuth 1.0a authentication.

In order to make calls to the APIs you will need a Cerner system account which includes a bearer token and a set of OAuth credentials called the consumer key and consumer secret.

Requesting a System Account

A system account can be requested through the CernerCentral administrative portal. Fill out the request form with the following information:

Once the new account is approved, work with your HealtheIntent Engagement Leader or submit an eService ticket to request that the account be granted access to the appropriate APIs and resources.

Authenticating Using a Bearer Token

This section provides basic steps for accessing protected APIs using a bearer token. This is the simpler means of authentication as compared to the OAuth 1.0a flow described later.


Using the bearer token to call a protected API

The Authorization header is used for calling protected APIs. The header can be built using the structure below. The built header should then be added when calling protected APIs.

Example authorization header value (multiline for readability):

Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.

Authenticating Using OAuth

This section provides basic steps for accessing protected APIs using a two-legged OAuth 1.0a authentication flow. Since this flow is less common than three-legged authentication, you should test making an OAuth call using a browser or curl before writing any code. This will help you get familiar with the fundamentals of two-legged authentication before using any third-party libraries, many of which are optimized for the three-legged flow and may be difficult to use with the two-legged flow. See Cerner’s OAuth specification in the Reference Pages on uCern Wiki for more information about the authentication flow below.

For detailed OAuth 1.0a documentation see the OAuth 1.0a spec.


Retrieving an access token

Make an HTTPS POST to the OAuth access token URL as follows:

Curl can be used to test retrieving an access token. The following examples will use 32dc21c-8ece-4ada-89b3-c152713f0575 as an example consumer key and L5ZeC0mVyot2C-KQlkXg5egglZsIphaC as an example consumer secret. You would replace these values with your own consumer key and secret.

Example request (multiline for readability):

curl -X POST -d "oauth_consumer_key=32dc21c-8ece-4ada-89b3-c152713f0575\

Example response:


Using the access token to call a protected API

Given an access token it is now possible to call a protected API.

The following information will be needed from the access token response:

The Authorization header is used for calling protected APIs. The header can be built using the structure below. The built header should then be added when calling protected APIs.

Example authorization header (multiline for readability):

OAuth oauth_token="ConsumerKey%3D332dc21c-8ece-4ada-89b3-c152713f0575%26ExpiresOn%3D1461779242%26HMACSecrets%3DL-RNB8AAMQM6iIdiP9m091f-JwYpcsJKj18SJNaGVqBtx7t0NA1SLVxm0cKvatdK4o3cb5sHPpHsr8rcNSofmzbX39sS2MsQc81cdjr0_HyBlKgC2rIy_2TRzjGvytsv0B5daJUmuA-EPW6U0-o7BQ%253D%253D%26KeysVersion%3Dfcecee6b-0c23-4df5-a332-799f9a515c16%26RSASHA1%3DOg5rz-58zVBJ924PSgOGoT34vOBOBNsbYNn_i1HijNDhbb_H3PbQXIFKvAcSU636hdqVT2eDeoRgz7aDitlmkvpFZuK3yi-cEYSFXIXuRmagHWeVYQs8A8I3WdZ-yritAwwfTESOGqXmomP6hC-2wiR_WFzqbGJcFcGVqdv2VqzMPgtd3CGz7KoTlOKSacBPq0AHGcu_PCm3oIlrgNReUZdm89MG7MkWNeGFOxiwMHKUzr4oZqwRehZb6LdpYrBJ0vYu94Qg-V_0UME9b7RIASXLtcTtducEREpDCwQZ0MqMsL0mXQ20dDfDD7t7AUziJZELZIDjTB4tPNZD3-aukQ%253D%253D",

Base URIs

HealtheIntent is a multi-tenant platform. All APIs are documented as HTTP paths relative to a tenant-specific hostname. HealtheIntent hostnames are provisioned using the following pattern:

  {client} => The tenant identifier.
  {solution} => The solution identifier

Examples for cernerdemo tenant:

HTTP Status Codes

Cerner uses standard HTTP status codes to indicate the success or failure of an API request. Generally, codes in the 2xx range indicate success, codes in the 4xx range indicate a problem with your request, and codes in the 5xx range indicate a problem on our end. The HealtheIntent APIs use the status codes below. More details about the possible responses for each endpoint are listed in the Responses sections on the pages for the APIs.

Code HTTP Definition Meaning
200 Success Everything worked as expected.
201 Created Your item was created.
204 No content Returned for PUT, POST, or DELETE requests when you should not expect a response body to be returned.
304 Not modified Returned for conditional ‘GET’ requests when nothing has changed since the previous request.
400 Bad request Your request could not be understood by the server, often due to bad syntax or parameters.
401 Unauthorized Your request did not have valid authentication credentials.
403 Forbidden Your request had valid authentication credentials, but those credentials are not allowed to complete the requested operation.
404 Not found The resource you requested doesn’t exist.
409 Conflict Your request failed due to a conflict with the current state of the resource.
412 Precondition failed Your request contained preconditions that were not met.
422 Unprocessable entity The content type and syntax of the request are correct, but the server was unable to process the instructions.
500 Internal server error Something went wrong on our end.

HealtheIntent API Catalog

HealtheLife Framework SDK



What are FHIR APIs?

Fast Healthcare Interoperability Resources (FHIR) is a health information data interchange format that can be used as an interoperability standard for electronic health records (EHRs). FHIR allows healthcare data to be accessed easily outside the context of the core system, such as by mobile apps or embeddable apps that extend the functionality provided by an EHR vendor. Applications built to rely on FHIR resources can be used with any system that supports the FHIR standard, eliminating the need for custom app development for each EHR platform. See the FHIR resources on the Health Level Seven (HL7) website for more information.

What is SMART?

SMART (Substitutable Medical Applications and Reusable Technologies) is an open, standards-based technology platform whose primary purpose is to support portable, interoperable healthcare applications. SMART apps can be standalone web applications, or they may be embedded in the context of other systems, such as an EHR, data warehouse, or patient portal. In the embedded model, the “SMART container” that encapsulates the app negotiates the user authentication and authorization, while the app itself provides the functionality and the user experience.

What is SMART on FHIR?

As described above, FHIR and SMART are two different technologies that fulfill two separate purposes. FHIR APIs are not required to be used only within a SMART application, and SMART apps can be built using non-FHIR APIs. However, when you build a SMART app that uses FHIR APIs — that is, a “SMART on FHIR” app — that app is theoretically “pluggable” into any EHR or other system that provides both a SMART container and FHIR APIs.

Why aren’t HealtheIntent’s APIs FHIR APIs?

HealtheIntent is a cloud-native platform that exists outside the context of any particular EHR, so HealtheIntent’s APIs are already reusable across systems. For example, the call to retrieve registry information for a person is the same regardless of whether you make the request from within a Cerner EHR, a non-Cerner EHR, a patient portal, or a standalone app. Therefore, SMART apps built using HealtheIntent APIs are already “pluggable” in the same manner as SMART on FHIR apps.

Much like the designers of FHIR, we subscribe to core values of simplicity, readability, usability, and consistency in our APIs. Because FHIR is primarily a standard for EHR information and not population health information, at least right now, some of the data we expose through the HealtheIntent APIs would not fit cleanly into FHIR resources. Paradoxically, shoehorning HealtheIntent data into FHIR models and vendor extensions would make many of the APIs less simple and usable, not more so, and would not provide any advantage in terms of reusability.

Are you ever going to provide FHIR APIs for HealtheIntent?

We may create FHIR APIs for certain key features of HealtheIntent that line up well with FHIR resources, including many of the concepts in the longitudinal person record and the forthcoming longitudinal care plan. Any new FHIR APIs that we may create for HealtheIntent would be additions to our existing APIs, not replacements for them.



The Ignite API Community on uCern is the best place to connect with Cerner engineers and other developers using the HealtheIntent APIs. Ask questions, share tips and tricks, make suggestions, and show off your work!

Note: This page includes links to external resources. These resources are provided for reference purposes and should be used with caution. Contact your Cerner support team for more information about third-party content.