Bar

Process Overview

 

Welcome to Altera Developer Portal - User Acceptance Testing (UAT) site. This site is only for UAT testing for Altera Clients. App developers registered in UAT can connect with Altera Client's UAT envrionment to conduct HL7 FHIR® APIs testing, however Altera Developer Program does not provide any Altera EHR sandboxes for testing in UAT. If app developers would like to test with Altera EHR sandboxes, not with specific Altera Client's UAT environment, you will need to register your application in the production Altera Developer Protal, https://developer.adp.ahcentral.com, and follow the instructions in the production site.

Altera EHRs supporting HL7 FHIR® APIs are Sunrise, Touchworks, Paragon, and dbMotion.  Review our terms of use and documentation to beign integration with Altera EHRs via HL7 FHIR® APIs.  

Altera Developer Portal UAT Sign-up

  1. Click Sign Up.
  2. Complete the required information.
  3. Review the user agreement.
  4. Confirm you are not a robot.
  5. Click I Accept.

Register FHIR® Application

Register your FHIR® API enabled application to connect to clients and begin testing.

  1. After sign-in, go to the My Dashboard page.
  2. On the My FHIR Applications tile, click + to a new application. 
  3. On the FHIR App page, complete the following information:
    • App Name: Indicates the application name. Enter an App Name that clearly identifies your company and product. This name will appear in our client's License Management Portal where clients will elect to license your application.
    • App Type: Indicates the primary audience for the application. Select Patient, Provider, or System. The App type impacts how the client views your application within the License Management Portal. It is important to identify the app type accurately.
      • Patient: The app's intended audience is patients.
      • Provider: The app's intended audience is physicians and healthcare providers.
      • System: The app's intended audience is an external system, not a physician or provider. For example, an insurance company.
    • App Description: Indicates a detailed description of how and why the application is used.
    • Additional info link: Indicates a link to more information on the application. For example, the partner's marketing website. Both the App Description and the Additional info link will display in the client License Management Portal to help identify the application to EHR organizations when authorizing applications.
    • JWKS URL: Indicates the URL for backend authentication access (JWKS) tokens. It is expected that a SMART on FHIR application developer can stand up a JWKS endpoint for their public key. That way, the application developer can recycle the keys when necessary, without having to contact all the FHIR API vendors they communicate with.
    • Redirect URLs: Indicates up to five redirect URLs. Include redirect_uri urn:ietf:wg:oauth:2.0:oob for desktop applications; if you are developing a web client, use a URL pointing back to your website. For example, <https://yourdomain.com/callback.>
    • Launch URLs: Indicates the URL used to launch a SMART on FHIR application. Enter up to three values.
    • Client Type: Indicates if this is a Confidential Client (trusted) or a Public Client (not trusted).
    • App Type: Indicates if this is a Native App (desktop) or a Web App (mobile).
  4. There is no need to indicate if this is a test or production application under Licensing Information. Once clients have licensed the application, the portal displays a list of organizations that have authorized the R4 application to connect to their environments. Please note,
    • As of 6/1/2025, Altera will no longer be providing support for DSTU2 as it approaches deprecation.
    • 'Request Production Access' in this site is mocked feature, whicn won't provide access to the Altera production environments. It will change the application status to 'Proudction' only within the Altera Clients' UAT environments.   Applications will need to be registered in the production Altera Developer Portal to be able to access Altera EHRs in the production.  
  5. For R4 applications, check the scopes that are required for the application to function as intended. Once production access has been granted, these scopes become the default scope values for the application in the License Management Portal. Do not request scopes that don't correspond to your app type and aren't necessary for the application to function. For example, if you have a patient application that works with medications, don't request scopes that begin with user/. If the application will require a refresh token, check offline_access. Note: A client may still deny access to certain scopes when they authorize an application in the License Management Portal.
  6. Click Save. The portal generates and displays the following information, collectively referred to as OAuth/FHIR Credentials:
    • Client ID
    • Secret
    • Secret Expiration Date
  7. Click OK.

The application has been registered. However, before it can be activated for a client, the developer needs to perform the following additional steps:

    1. On the FHIR App page, select a Purpose of Use for the application. 
    2. Select the appropriate SMART Auth Scopes for the application. Scopes control the type of information the application is requesting from the EHR. The scopes must match the App Type. For example, scopes that begin patient/ are for use with patient applications. Do not request scopes that are not required for the application to function. 
    3. When appropriate, convert to v2 Auth Scopes by clicking 'Click here to migrate v1 scopes to V2'. Notes:
      • Applications can still use SMART App Launch V1 scopes however with US ASTP expired its approval of version 1.0 use as of December 31, 2025, it is strongly recomended that you applications to suupport SMART App Launch v2.0.0 framework. 
      • Once you migrate to v2 Auth Scopes, you won't be able to go back to V1 Auth scopes. 
      • Altera Clients will upgrade their EHRs to the version that supports SMART App Launch v2.0.0 throughout the year of 2026. 
      • Once your target Altera client has completed the upgrade, your application can get authenticated following v2 Auth Scopes.  

Client Licensing

Altera Clients use a separate portal for licensing and managing FHIR applications authorized to their organization. Altera cannot license applications for clients; the clients must activate applications themselves through the License Management Portal (LMP). If a client requests guidance from a FHIR application developer, you can provide them the following link to documentation: License Management Portal documentation.

Note that application developers do not have access to this documentation site. Clients must use their Altera Client Portal credentials to access this information.

Testing

Once your application registration is completed and licensed by Altera Client to their UAT environment, you can begin testing. 

Patient and User Applications

Patient and User type FHIR applications authenticate by entering user credentials for the Altera EHR or patient portal (such as AHC or FollowMyHealth). Postman can send requests to these systems to obtain these tokens.

Before attempting to send FHIR requests to the Altera EHR, it is helpful to create an environment file with the following variables.

  • FhirURL: FHIR server URL.
  • AuthURL: FHIR authorization server URL. This often ends in …/authorize. The authorization server validates that the application has been authorized, and then validates the user’s credentials. You can obtain the AuthURL by calling the Capability Statement.
  • CallbackURL: Callback URL. This is where the authorization sends a temporary token to application. For example, <http://localhost/callback>.
  • TokenURL: FHIR Token server URL. This often ends in …/token. The application sends the temporary to the TokenURL and a regular token is returned. You can obtain the TokenURL by calling the Capability Statement.
  • ClientID: FHIR application Client ID. This is found on the FHIR App page in the Altera Connect portal.
  • ClientSecret: FHIR application Client Secret. This is found on the FHIR App page in the Altera Connect portal.
  • Scope: FHIR application scope. This is requested by the FHIR application developer on the FHIR App page in the Altera Connect portal.

To create an environment in Postman:

  1. Create or go to your workspace.
  2. Click Environments, and then click New.
  3. On the Create New screen, click Environment.
  4. Enter the variables, and then click Save.

Next, create a request.

  1. Click New.
  2. On the Create New screen, click HTTP Request.

Next, obtain a token.

  1. On the request’s tab, click the Authorization tab.
  2. In Type, select OAuth 2.0.
  3. In Header Prefix, select Bearer.
  4. Under Configure New Token, refer to the variables you created in your Environment file by using the {{variable name}}. For example, for Auth URL, enter {{AuthURL}}.
  5. Click Get New Access Token.
  6. For a User application, the Altera EHR login screen displays. Enter the EHR credentials. For a Patient application, enter the patient’s portal credentials.
  7. Postman displays the token. Click Use Token.

You can now enter an HTTP request and click Send.

Note: Tokens expire after a set amount of time configured by the client. You will need to generate new tokens periodically.

For more information on Postman, see the Postman Support Center or Learning Center.

System Applications

Instead of entering product credentials to obtain a token, System applications make a direct call to the Token URL. The body of the request must include the following:

  • client_assertion: Indicates a token generated using a private key. The key must be signed by a certificate authority. There is no way to generate this token in Postman, and thus it must be generated by another utility. Sample code for creating your own utility follows.
  • client_assertion_type: urn:ietf;params;oauth:client-assertion-type:jwt-bearer
  • grant_type: client_credentials
  • scope: system/*.read

C# Sample Code for Generating Access Token with System Application

private async Task GetBearerToken()

{

    string accessToken = null;

    string tokenURL = "[token URL of FHIR auth server]";

    string clientID = "[your FHIR app client ID]";

    var tokenCode = GenerateJWT(tokenURL, clientID);

    var address = new Uri(tokenURL);

    using (var handler = new HttpClientHandler())

    {

        handler.UseCookies = false;

        using (var client = new HttpClient(handler))

        {

            var message = new HttpRequestMessage(HttpMethod.Post, address);

            var content = new FormUrlEncodedContent(new[]

            {

                    new KeyValuePair<string, string>("scope", "system/*.read"),

                    new KeyValuePair<string, string>("grant_type", "client_credentials"),

                    new KeyValuePair<string, string>("client_assertion_type", "urn:ietf:params:oauth:client-assertion-type:jwt-bearer"),

                    new KeyValuePair<string, string>("client_assertion", tokenCode),

                });

       &n

  • LinkedIn
  • Twitter
  • YouTube
  • Facebook
  • Instagram

© 2025 Altera Digital Health Inc. and / or its affiliates. All rights reserved.

This site uses only essential cookies required for login, security, and core functionality.