Bar

Introduction


The Altera FHIR API allows you to connect to Altera products using the HL7 FHIR® (Fast Healthcare Interoperability Resources) standard for healthcare resources. The FHIR standard enables application developers to create products and exchange clinical data in a secure manner that is consistent, flexible, and easy to implement.


For the purpose of this documentation, the term “application” refers to a software program connecting to a Altera product through the Altera FHIR API. The term “product” refers to the Altera base system such as Sunrise, TouchWorks EHRs.


The FHIR standard is constantly evolving. The current version of the Altera implementation of the FHIR API supports FHIR release 4 (“R4”) and the United States Core Data for Interoperability (“USCDI”) guidelines and requirements for data sharing. As of 2026 August, Altera FHIR APIs can support Electronic Prior Authorization capabilities for Sunrice EHR.

Note: Some Altera clients are still running Altera FHIR DSTU2 APIs. However, new deployment of DSTU2 APIs are prohibited as of 6/1/2025. Altera is in the progress of deprecating FHIR DSTU2 APIs from the production. Any applications onboarding after 1/1/2026 should implement FHIR R4 standard to integrate with Altera products.


Capability Statement

A FHIR Capability Statement documents the set of capabilities and behaviors available from the FHIR API service implementation. The Capability Statement includes information about supported FHIR resources and security protocols and should be used by applications as the set of rules the application should follow. You can retrieve the capability statement of each FHIR endpoint published in the Altera FHIR Endpoint Directory.

Note: Altera FHIR Endpoint directory lists USCDI endpoints for applications joined the Altera Developer Program (ADP). Each Altera FHIR server will provide a separate endpoint (aka. Da Vinci CRD endpoint) for the payer systems to access for coverage requirement determination as part of the prior authorization workflow. And they are provided through only by the CDS Hook when a prior agreemnt between the Altera client and the payer is made outside of ADP program. USCDI endpoint and the Da Vinci CRD endpoint will provide its own capability statement.


To get a copy of the capability statement, make the following request:

GET [Altera FHIR endpoint URL]/metadata

FHIR Resources

The Altera FHIR API allows users to search for and access selected clinical, demographic, and facility information via REST. This data is referred to by FHIR as resources and include healthcare or related items such as patients or medications. All resources are addressable by a unique identifier (id) that can be used to access or reference them. FHIR Resources will be presented in the corresponding US Core profiles via USCDI endpoints whereas they will be represented in the Da Vinci CRD Profiles via CRD endpoints. For information on the individual FHIR resources supported by the Altera FHIR API and the requests they support, see the Resources page.


FHIR resources are accessed through HTTP and use the HTTP verbs. For example, GET.

The Altera FHIR API supports both JSON and XML formats. By default, the Altera FHIR API returns data in JSON. Use the Accept HTTP header to control this format.


  • */*: Application accepts anything.
  • application/fhir+XML: Response is in XML.
  • application/fhir+JSON: Response is in JSON.

The Altera FHIR API returns information using the FHIR R4 standard and US Core profiles. To ensure the Altera FHIR API to return information using the R4 standard from a version-less environment, add fhirVersion=4.0 to the Accept header in the request. If the payer system is accessing a specific FHIR endpoint provided by the Altera Product at the electronic prior authorization workflow, Altera FHIR APIs will return information adhereing to HL7® Da Vinci Coverage Requirement Discovery (CRD) profiles.

Authorization

The Altera FHIR API supports the HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 and Release 2.0.0 implementation specifications, a profile of the OAuth 2.0 specification and OpenID Connect Core 1.0. FHIR API will support the production use of SMART Application Launch Framework 2.0.0 when the target Altera EHR instance is upgraded to the version compatiable with Altera FHIR 25.4 or later.


The following sections describe the authorization flows for FHIR applications registered in ADP accessing USCDI FHIR endpoints.


Stand-alone application launch for a Altera product user

The endpoint for the product's Altera FHIR server is available from the Altera Endpoint Directory. Typically endpoints that include /fhir are for product users. These (non-patient) application endpoints can also be tagged with a Provider badge on the Endpoint Directory.


  1. The application requests the Capability Statement from Altera FHIR server.
  2. The Altera FHIR server returns the Capability Statement which includes two endpoints:
    • authorize endpoint for the Altera Authorization server
    • token endpoint

    For example:

    “url”: “authorize”,
    “valueUri”: “
    },
    {
    “url”: “token”,
    “valueUri”: “
  3. The application sends credentials to the Altera Authorization server. These credentials include the application's client ID and client secret. (On the FHIR App page on the Altera Developer Portal.)
  4. If the application credentials are recognized by the Altera Authorization server (meaning the client has authorized the application in the Altera License Management Portal), the product's log in screen displays. The user can enter their user credentials (user ID and password) in the product.

    If the application credentials are not recognized by the Altera Authorization server, the server returns an error.

  5. OAuth sends the user's product credentials to the Altera Authorization server. If the credentials are valid, the server returns a temporary token to the application's Callback URL (as defined in the Altera Developer Portal for the application).
  6. The application sends the temporary token to the token endpoint, and the Altera Authorization server returns a regular token. The length of time during which the token is valid is defined in the Altera License Management Portal.

Stand-alone application launch for a patient

The endpoint for the product's Altera FHIR server is available from the Altera Endpoint Directory. Typically endpoints that include /open are for patient applications. These patient application endpoints can also be tagged with a Patient badge on the Endpoint Directory.

  1. The application requests the Capability Statement from Altera FHIR server.
  2. The Altera FHIR server returns the Capability Statement which includes the authorize endpoint for the Altera Authorization server and the token endpoint.
  3. The application sends credentials to the Altera Authorization server. These credentials include the application's client ID and client secret. (On the FHIR App page on the Altera Developer Portal.)
  4. If the application credentials are recognized by the Altera Authorization server (meaning the client has authorized the application), the server verifies that the patient is valid.

SMART launch

  1. A Altera product user launches a SMART application from the product. The product sends any relevant context with the launch command to the application.
  2. Application sends credentials to the Altera Authorization server. These credentials include the application's client ID and secret.
  3. If the application credentials are recognized by the Altera Authorization server (meaning the client has authorized the application in the Altera License Management Portal), the product's log in screen displays. The user can enter their user credentials (user ID and password) in the product. If the application credentials are not recognized by the Altera Authorization server, the server returns an error.
  4. OAuth sends the user's product credentials to the Altera Authorization server. If the credentials are valid, the server returns a temporary token to the application's Callback URL (as defined in the Altera Developer Portal for the application).
  5. The application sends the temporary token to the token endpoint, and the Altera Authorization server returns a regular token. The length of time during which the token is valid is defined in the Altera License Management Portal.
  6. If you are testing the authentication in Postman, you can manually copy the access token and paste it into Authorization tab > Current Token section > Token. Enter the URL for the request, and then click Send.

For more infomraiton on SMART Authentication, visit SMART on FHIR page.