Process Overview

The following overview provides comprehensive guidance for developers on the process of registering their HL7 Fast Healthcare Interoperability Resources (HL7 FHIR®) API enabled application to integrate with various Altera products including TouchWorks, Sunrise, and Paragon as well as dbMotion. Whether you're integrating with one or all of these products, this overview will serve as an invaluable guide to streamline the Altera Developer Program onboarding process and your FHIR® API-enabled app registration process.

Review our terms of use and documentation to begin onboarding process. When you register your developer account, accept the User Agreement and provide a valid email address. You are strongly encouraged to register as a corporate account and use your corporate email address. You’ll receive credentials that you can use to register your applications. If you have questions, reach out to ADP@alterahealth.com.

Functionality Considerations

The Altera FHIR API is limited to read-only access and not write-backs. For application developers seeking deeper integration with Altera EHRs such as TouchWorks or Sunrise, Altera offers the bidirectional Unity API, enabling both reads and writes.

Developer Portal Sign-up

Sign up at https://developer.adp.ahcentral.com/ to start your onboarding process.

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. Altera clients will be able to provision license to your app once the production access is approved.

1. On the Altera Developer Program portal, go to the My Dashboard page.
2. On the My FHIR Applications tile, click + to a new application. Note: If there is already a version of the application for DSTU2, you do not need to create 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 (LMP) 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 LMP. It is important to identify the app type accurately.
     • Patient: The app's intended end-user is patients.
     • Provider: The app's intended end-user is physicians and healthcare providers.
     • System: The app's intended end-user is an external system, not a physician or provider. For example, an automated back-end system utlizing FHIR APIs.
   • App Description: Indicates a detailed description of how and why the application is used. The description will show to Altera Clients in LMP to understand about your apps.
   • 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 LMP 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. Click Save. The portal generates and displays the following information, collectively referred to as OAuth/FHIR Credentials:
   • Client ID
   • Secret
   • Secret Expiration Date
5. Click OK.

The application has been registered. However, the developer needs to perform the following additional steps before informing Altera client to provision license for your app.

1. Go back to My FHIR Applications page, select the application and settings icon.
2. Under Licensing Information
   • For FHIR R2 enabled apps: As of 1/1/2026, Altera will no longer provide support for newly registered applications integrating with FHIR R2 APIs as it approaches deprecation. The FHIR R2 APIs will not be turned off, but there will no longer be technical support or resolution provided for any issues that arise. You should integrate with FHIR R4 endpoints when the client site provides.
   • For FHIR R4+ enabled apps: When you first register, your app is allowed for testing only. When you complete your self-attestation of FHIR API integration, click Request Porudction Access. Once production access is approved by Altera and licensed by the Altera client, all the production organizations licensed your app will be displayed here.
3. Select a Purpose of Use for the application. Purpose of Use definitions are available from that page. Some data may be restricted to access for the purpose of use by the client licensing.
4. Select the authorization scopes that are required for the application to function as intended. Scopes control the type of information the application is requesting from the EHR.
   • If the application will require a refresh token, select offline_access.
   • The scopes must match the app type. For example, you need to select patient level scopes that begin with patient/... when your app type is Patient.
   • Never request scopes that are not required for your application to function.
   • Once production access has been granted, these scopes become the default scope requested for the application in the LMP. Altera clients can decide to grant all the requested authorization scopes or deny some scopes during license provisioning.
   • As of 1/1/2026, Altera FHIR platform supports both SMART app launch verion 1 and verion 2. You can select 'Click here to migrate v1 scopes to v2' if your application supports SMART App launch version 2 framework. Altera clients will need to upgrade to their EHR version that's compatible with Altera FHIR R4 25.4 or above to work with the version 2 authorization scopes.
   • Important: Once you migrate to verion 2 scopes, you won't be able to swtich back to version 1 scopes.
   • When you want to test your selected auth scopes with the sandbox, you will need to use Standalone Launch mode. Open Intergrators won't be able to test in the EHR Launch mode with ADP provided sandboxes. Please visit SMART on FHIR page for more informaiton.

Client Licensing

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

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




Testing

For information about testing with ADP Sandboxes, go to the Application Testing page.

Once you complete testing with the Sandbox FHIR R4 endpoints, go back to My FHIR Applications page and request for the production access.