22.7 Release: Updated: Enable Patient Authentication Against Multiple athenaOne® Practices

Summary

This change eliminates the need for apps to specify both an athenahealth practice and Patient Portal brand for Login with athenahealth.

Products

athenaClinicals, athenaCommunicator, athenaClinicals for Hospitals & Health Systems

Roles

Management/Technical

Available

July 27, 2022 (22.7)

Is this a breaking change?

No, this is not a breaking change

Endpoints affected

  • GET /oauth2/v1/authorize

Resources

Refer to the following resources for more information:

Overview

What is changing

This change eliminates the need for apps to specify both an athenahealth practice and Patient Portal brand for Login with athenahealth. 

Apps decide whether to authenticate patients against a specific practice Patient Portal brand using the aud parameter of the GET /oauth2/v1/authorize endpoint. For brand-specific authentication, an app would pass a URL in either of the following formats to the aud parameter of their authorize request: 

  • FHIR DSTU2 format: 

Production: https://api.platform.athenahealth.com/v1/{practiceid}/{brandid}/{chartsharinggroupid}/fhir/dstu2 

Preview: https://api.preview.platform.athenahealth.com/v1/{practiceid}/{brandid}/{chartsharinggroupid}/fhir/dstu2 

  • FHIR R4 format: 

Production: https://api.platform.athenahealth.com/{practiceid}/brand/{brandid}/csg/{chartsharinggroupid}/fhir/r4 

Preview: https://api.preview.platform.athenahealth.com/{practiceid }/brand/{brandid}/csg/{chartsharinggroupid}/fhir/r4

For cross-context authentication, an app would pass a URL in the following format to the aud parameter of their authorize request – note that only the FHIR R4 format is supported: 

  • FHIR R4 format: 

Production: https://api.platform.athenahealth.com/fhir/r4 

Preview: https://api.preview.platform.athenahealth.com/fhir/r4 

If cross-context authentication is used with SMART on FHIR, in which patients must select a single patient record to grant access, patients will encounter an updated prompt that indicates the athenahealth Patient Portal brand associated with each of their records. Apps indicate use of SMART on FHIR by inclusion of the launch/patient scope in the scope parameter of their authorize request. 

Graphical user interface, text, application

Description automatically generated

Why we're making the change

We’re making this change to accommodate developers of patient-facing applications seeking to authenticate users against multiple athenaOne practices simultaneously using Login with athenahealth. Previously, apps had to specify both an athenahealth practice and Patient Portal brand for login. 

Example use cases include: 

  • A third-party application using Login with athenahealth to offer patients a single point of login for retrieving their health records across the athenaOne network. 

  • A centralized patient experience offered by an athenaOne customer to patients across their multiple athenaOne practices, for which patients can log in with their existing athenahealth Patient Portal credentials. 

What will current users of the endpoint need to update in their code

Nothing

What will happen if users of the endpoint do not update their code

Nothing

Was this information helpful? Yes | No Thank you for your feedback! What went wrong? Incomplete or incorrect information | Irrelevant Content | Others
Submit

On this Page