Existing Wording: The information needed to obtain the needed resources will be provided as escaped JSON in the appContext property of the CDS Hooks Card Link object, as described in Section 4.2.1. That object will have the following properties:

Field Optionality Type Description

fhirAuthorization OPTIONAL object A structure holding an OAuth 2.0 bearer access token granting the DTR Application access to payer FHIR resources, along with supplemental information relating to the token.

Comment:

The appContext CDS Hooks field is intended to allow a CDS Hooks service pass information to SMART app. The profiled template and request parameters are an appropriate use of this field. The proposed fhirAuthorization element is not appropriate because it gives the CDS client (EHR) access to the OAuth bearer token intended for the SMART app. This is a security violation. The SMART app must authenticate to the payer's resource server in some other way. A creative solution would be permitting the existing, EHR-generated access_token to be used to authenticate against the payer's resource server by having the payer validate the EHR access_token against an EHR introspection endpoint (aka Josh's imaging access for consumers proposal). A more mundane and easier solution would backend service/client_credentials app-level access to the payer's resource server.

Summary:

Don't insecurely expose DTR app's payer-granted OAuth2 access_token to EHR.