Printer Friendly, PDF & Email Printer Friendly, PDF & Email

§170.315(g)(10) Standardized API for patient and population services

Updated on 08-29-2022
Resource Documents
Revision History
Version # Description of Change Version Date
1.0

Final Test Procedure.

06-01-2020
1.1

Corrected typos. Corrected internal document references in Steps 12, 13, and 19 of “Authentication and Authorization for Patient and User Scopes.” Corrected applicable launch scenarios in Step 13, of “Authentication and Authorization for Patient and User Scopes.” Amended Step 10, of "Authentication and Authorization for Patient and User Scopes" by removing non-USCDI mapped US Core IG FHIR® resources. 

08-07-2020
1.2

Updated compliance date, regulation text, and standard for trial use (STU) 3 Release 3.1.1 at § 170.215(2), per the IFR, Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency.

11-02-2020
1.3

Added step for issuance of a refresh token to native apps that are capable of storing a refresh token (Step 21 of "Paragraph (g)(10)(v)(A) - Authentication and authorization for patient and user scopes"). 

Removed "PractitionerRole" and "RelatedPerson" from multiple patient services data support list (Step 8 of "Paragraph (g)(10)(i) - Data response").

12-16-2020
1.4

Updated test procedure step regarding "offline_access" scope, enabling a health IT developer to demonstrate either support for the end-user to explicitly enable/disable the "offline_access" scope, or information communicating the application's request for the "offline_access" scope. 

04-02-2021
1.5

Corrected typo in Step 5, of “Paragraph (g)(10)(v)(B) – Authentication and authorization for system scopes” to indicate that the “cache-control” header is sent by the application. Added step for health IT developer to demonstrate the public location of its certified API technology service base URLs that can be used by patients to access their Electronic Health Information.

05-13-2021
1.6

Updated Step 13, of “Paragraph (g)(10)(v)(A) – Authentication and authorization for patient and user scopes” to indicate that only the “launch” parameter, in EHR-Launch mode, is tested against the “launch” parameter provided in Step 8. Added a new Step 14, to this section to indicate how the “aud” parameter is tested. Corrected a typo in Step 22, of this section to indicate refresh tokens are granted to native applications capable of securing a refresh token.

06-08-2021
1.7

Updated “Missing Data” requirements in section “Data Response Checks for Single and Multiple Patients” to clarify that health IT developers must demonstrate that Health IT Modules support “Missing Data” according to the US Core IG, including for non-coded and coded data elements.

08-02-2021
1.8

Updated the version and link for § 170.215(a)(2) FHIR® US Core Implementation Guide STU V3.1.1.

11-03-2021
1.9

Updated the Bulk Data IG references in “Standard(s) Referenced” from “HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.0:STU 1)” to the ONC-approved errata version “HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1)” that is now effective for testing.

12-08-2021
2.0

Updated Testing Tool and Test Tool Documentation links.

04-06-2022
2.1

Removed Step 13, for Paragraph (g)(10)(v)(A) – “Authentication and authorization for patient and user scopes”, which tested the response to an invalid “launch” parameter for EHR-Launch.

06-01-2022
2.2

Updated to include the Standards Version Advancement Process (SVAP) Approved Standards for 2022. Added unique identifiers (e.g., “APP-REG-1”) to each test procedure step.

08-29-2022
Regulation Text
Regulation Text

§ 170.315(g)(10) Standardized API for patient and population services

The following technical outcomes and conditions must be met through the demonstration of application programming interface technology.

  1. Data response.
    1. Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.
    2. Respond to requests for multiple patients’ data as a group according to the standard adopted in § 170.215(a)(1) and implementation specifications adopted at § 170.215(a)(2) and (a)(4), for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.
  2. Supported search operations.
    1. Respond to search requests for a single patient’s data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(2), specifically the mandatory capabilities described in “US Core Server CapabilityStatement”.
    2. Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(4).
  3. Application registration. Enable an application to register with the Health IT Module’s “authorization server.”
  4. Secure connection.
    1. Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(a)(2) and (3).
    2. Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(a)(4).
  5. Authentication and authorization.
    1. Authentication and authorization for patient and user scopes.
      1. First time connections.
        1. Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b).
        2.  A Health IT Module’s authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret. 
        3. A Health IT Module’s authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token. 
      2. Subsequent connections.
        1. Access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application.
        2. A Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. 
    2. Authentication and authorization for system scopes. Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token.
  6. Patient authorization revocation. A Health IT Module’s authorization server must be able to revoke an authorized application’s access at a patient’s direction.
  7. Token introspection. A Health IT Module’s authorization server must be able to receive and validate tokens it has issued.
  8. Documentation.
    1. The API(s) must include complete accompanying documentation that contains, at a minimum:
      1. API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.
      2.  The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).
      3. All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module’s authorization server.
    2. The documentation used to meet paragraph (g)(10)(viii)(A) of this section must be available via a publicly accessible hyperlink without any preconditions or additional steps.
Standard(s) Referenced

Paragraph (g)(10)(i)(A)

§ 170.215(a)(1) Health Level 7 (HL7®) Version 4.0.1 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, October 30, 2019

§ 170.215(a)(2) FHIR® US Core Implementation Guide STU V3.1.1

§ 170.213 United States Core Data for Interoperability (USCDI)

Paragraph (g)(10)(i)(B)

§ 170.215(a)(1) HL7® Version 4.0.1 FHIR® Release 4, October 30, 2019

§ 170.215(a)(2) FHIR® US Core Implementation Guide STU V3.1.1

§ 170.213 USCDI

§ 170.215(a)(4) HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1)

Paragraph (g)(10)(ii)(A)

§ 170.215(a)(2) FHIR® US Core Implementation Guide STU V3.1.1

Paragraph (g)(10)(ii)(B)

§ 170.215(a)(4) HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1)

Paragraph (g)(10)(iii)

None

Paragraph (g)(10)(iv)(A)

§ 170.215(a)(2) FHIR® US Core Implementation Guide STU V3.1.1

§ 170.215(a)(3) HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0

Paragraph (g)(10)(iv)(B)

§ 170.215(a)(4) HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1)

Paragraph (g)(10)(v)(A)(1)

§ 170.215(a)(3) HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0

§ 170.215(b) OpenID Connect Core 1.0 incorporating errata set 1

Paragraph (g)(10)(v)(A)(2)

§ 170.215(a)(3) HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0

Paragraph (g)(10)(v)(B)

§ 170.215(a)(4) HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1)

Paragraph (g)(10)(vi)

None

Paragraph (g)(10)(vii)

None

Paragraph (g)(10)(viii)

None

 

Standards Version Advancement Process (SVAP) Version(s) Approved

United States Core Data for Interoperability (USCDI), Version 2, July 2021

HL7® FHIR® US Core Implementation Guide STU 4.0.0, June 2021

HL7® FHIR® US Core Implementation Guide STU 5.0.1, June 2022 

HL7® FHIR® SMART Application Launch Framework Implementation Guide Release 2.0.0, November 26, 2021

HL7® FHIR® Bulk Data Access (Flat FHIR®) (v2.0.0: STU 2), November 26, 2021

Testing

Please consult the Final Rule entitled: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program and the Interim Final Rule (IFR), Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency for associated regulations and a detailed description of the certification criterion with which these testing steps are associated. Developers are encouraged to consult the Certification Companion Guide in tandem with the test procedure as these provide clarifications that may be useful for product development and testing.

Note: The order in which the test steps are listed reflects the sequence of the certification criterion and does not necessarily prescribe the order in which the test should take place.

PDF Version170 315(g)(10) Standardized API for Patient and Population Services SVAP [PDF - 534 KB]

 

Testing components

No GAP Icon Documentation Icon Visual Inspection Icon Test Tool Icon No ONC Supplied Test Data Icon SVAP Icon
System Under Test Test Lab Verification

Certification Option: Applies to all applicable base regulatory and SVAP standards

Application Registration

  1. APP-REG-1: The health IT developer demonstrates the Health IT Module supports application registration with an authorization server for the purposes of Electronic Health Information (EHI) access for single patients, including support for application registration functions to enable authentication and authorization in § 170.315(g)(10)(v).
  2. APP-REG-2: The health IT developer demonstrates the Health IT Module supports application registration with an authorization server for the purposes of EHI access for multiple patients including support for application registration functions to enable authentication and authorization in § 170.315(g)(10)(v).

Certification Option: Applies to all applicable base regulatory and SVAP standards

Application Registration

  1. APP-REG-1: The tester verifies the Health IT Module supports application registration with an authorization server for the purposes of EHI access for single patients, including support for application registration functions to enable authentication and authorization in § 170.315(g)(10)(v).
  2. APP-REG-2: The tester verifies the Health IT Module supports application registration with an authorization server for the purposes of EHI access for multiple patients including support for application registration functions to enable authentication and authorization in § 170.315(g)(10)(v).

System Under Test Test Lab Verification

Certification Option: Applies to all applicable base regulatory and SVAP standards

Secure Connection

  1. SEC-CNN-1: For all transmissions between the Health IT Module and the application, the health IT developer demonstrates the use of a secure and trusted connection in accordance with the implementation specifications adopted in § 170.215(a)(2) and § 170.215(a)(3), including:
    • Using TLS version 1.2 or higher; and
    • Conformance to FHIR® Communications Security requirements.

Certification Option: Applies to all applicable base regulatory and SVAP standards

Secure Connection

  1. SEC-CNN-1: For all transmissions between the Health IT Module and the application, the tester verifies the use of a secure and trusted connection in accordance with the implementation specifications adopted in § 170.215(a)(2) and § 170.215(a)(3), including:
    • Using TLS version 1.2 or higher; and
    • Conformance to FHIR® Communications Security requirements.

System Under Test Test Lab Verification

Regulatory Standard: SMART 1.0.0

Authentication and Authorization for Patient and User Scopes

  1. AUT-PAT-1: The health IT developer demonstrates the ability of the Health IT Module to support the following for “EHR-Launch,” “Standalone-Launch,” and “Both” (“EHR-Launch” and “Standalone-Launch”) as specified in the implementation specification adopted in § 170.215(a)(3).
  2. AUT-PAT-2: [EHR-Launch] The health IT developer demonstrates the ability of the Health IT Module to initiate a “launch sequence” using the “launch-ehr" “SMART on FHIR® Core Capability” SMART EHR Launch mode detailed in the implementation specification adopted in § 170.215(a)(3), including:
    • Launching the registered launch URL of the application; and
    • Passing the parameters: “iss” and “launch”.
  3. AUT-PAT-3: [Standalone-Launch] The health IT developer demonstrates the ability of the Health IT Module to launch using the “launch-standalone" “SMART on FHIR® Core Capability” SMART Standalone Launch mode detailed in the implementation specification adopted in § 170.215(a)(3).
  4. AUT-PAT-4: [Standalone-Launch] The health IT developer demonstrates the ability of the Health IT Module to support SMART’s public client profile.
  5. AUT-PAT-5: [Both] The health IT developer demonstrates the ability of the Health IT Module to support the following as detailed in the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(a)(1):
    • The “.well-known/smart-configuration.json” path; and
    • A FHIR® “CapabilityStatement”.
  6. AUT-PAT-6: [Both] The health IT developer demonstrates the ability of the “.well-known/smart-configuration.json” path to support at least the following as detailed in the implementation specification adopted in § 170.215(a)(3):
    • “authorization_endpoint”;
    • “token_endpoint”; and
    • “capabilities” (including support for all the “SMART on FHIR® Core Capabilities”).
  7. AUT-PAT-7: [Both] The health IT developer demonstrates the ability of the FHIR® “CapabilityStatement” to support at least the following components as detailed in the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(a)(1), including:
    • “authorize”; and
    • “token”.
  8. AUT-PAT-8: [Both] The health IT developer demonstrates the ability of the Health IT Module to receive an authorization request according to the implementation specification adopted in § 170.215(a)(3), including support for the following parameters:
    • “response_type”;
    • “client_id”;
    • “redirect_uri”;
    • “launch” (for EHR-Launch mode only);
    • “scope”;
    • “state”; and
    • “aud”.
  9. AUT-PAT-9: [Both] The health IT developer demonstrates the ability of the Health IT Module to support the receipt of the following scopes and capabilities according to the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b):
    • “openid” (to support “sso-openid-connect” “SMART on FHIR® Core Capability”);
    • “FHIR®User” (to support “sso-openid-connect” “SMART on FHIR® Core Capability”);
    • “need_patient_banner” (to support “context-banner” “SMART on FHIR® Core Capability” for EHR-Launch mode only);
    • “smart_style_url” (to support “context-style” “SMART on FHIR® Core Capability” for EHR-Launch mode only);
    • “launch/patient” (to support “context-standalone-patient” “SMART on FHIR® Core Capability” for Standalone-Launch mode only);
    • “launch” (for EHR-Launch mode only);
    • “offline_access” (to support “permission-offline” “SMART on FHIR® Core Capability”);
    • Patient-level scopes (to support “permission-patient” “SMART on FHIR® Core Capability”); and
    • User-level scopes (to support “permission-user” “SMART on FHIR® Core Capability”).
  10. AUT-PAT-10: [Both] The health IT developer demonstrates the ability of the Health IT Module to evaluate the authorization request and request end-user input, if applicable (required for patient-facing applications), including the ability for the end-user to authorize an application to receive EHI based on FHIR® resource-level scopes for all of the FHIR® resources associated with the profiles specified in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2).
    If using US Core 3.1.1, 4.0.0, or 5.0.1, these resources include:
    • “AllergyIntolerance”;
    • “CarePlan”;
    • “CareTeam”;
    • “Condition”;
    • “Device”;
    • “DiagnosticReport”;
    • “DocumentReference”;
    • “Goal”;
    • “Immunization”;
    • “Medication” (if supported);
    • “MedicationRequest”;
    • “Observation”;
    • “Patient”;
    • “Procedure”; and
    • “Provenance”.
      Additionally, the following resources must be supported if using US Core 5.0.1:
    • “Encounter”;
    • “RelatedPerson”; and
    • “ServiceRequest”
  11. AUT-PAT-11: [Both] The health IT developer demonstrates the ability of the Health IT Module to evaluate the authorization request and request end-user input, if applicable (required for patient-facing applications), including either the ability for the end-user to explicitly enable / disable the “offline_access” scope or information communicating the application’s request for the “offline_access” scope.
  12. AUT-PAT-12: [Both] The health IT developer demonstrates the ability of the Health IT Module to deny an application’s authorization request according to a patient’s preferences selected in AUT-PAT-10, and AUT-PAT-11, of this section in accordance with the implementation specification adopted in § 170.215(a)(3).
  13. AUT-PAT-13: [Both] The health IT developer demonstrates the ability of the Health IT Module to return an error response if the "aud" parameter provided by an application to the Health IT Module in AUT-PAT-8, is not a valid FHIR® resource server associated with the Health IT Module's authorization server.
  14. AUT-PAT-14: [Both] The health IT developer demonstrates the ability of the Health IT Module to grant an application access to EHI by returning an authorization code to the application according to the implementation specification adopted in § 170.215(a)(3), including the following parameters:
    • “code”; and
    • “state”.
  15. AUT-PAT-15: [Both] The health IT developer demonstrates the ability of the Health IT Module to receive the following parameters from an application according to the implementation specification adopted in § 170.215(a)(3):
    • “grant_type”;
    • “code”;
    • “redirect_uri”;
    • “client_id”; and
    • Authorization header including “client_id” and “client_secret”.
  16. AUT-PAT-16: [Both] The health IT developer demonstrates the ability of the Health IT Module to return a JSON object to applications according to the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b), including the following:
    • “access_token”;
    • “token_type”;
    • “scope”;
    • “id_token”;
    • “refresh_token” (valid for a period of no shorter than three months);
    • HTTP “Cache-Control” response header field with a value of “no-store”;
    • HTTP “Pragma” response header field with a value of “no-cache”;
    • “patient” (to support “context-ehr-patient” and “context-standalone-patient” “SMART on FHIR® Core Capabilities”);
    • “need_patient_banner” (to support “context-banner” “SMART on FHIR® Core Capability” for EHR-Launch mode only); and
    • “smart_style_url” (to support “context-style” “SMART on FHIR® Core Capability” for EHR-Launch mode only).
      Additionally, the following must be supported if using US Core 5.0.1:
    • “encounter” (to support"context-ehr-encounter" “SMART on FHIR® Capability”)
  17. AUT-PAT-17: [Both] The health IT developer demonstrates the ability of the Health IT Module to provide an OpenID Connect well-known URI in accordance with the implementation specification adopted in § 170.215(b), including:
    • All required fields populated according to implementation specification adopted in § 170.215(b); and
    • Valid JWKS populated according to implementation specification can be retrieved via JWKS URI.
  18. AUT-PAT-18: [Both] The health IT developer demonstrates the ability of the Health IT Module to deny an application’s authorization request in accordance with the implementation specification adopted in § 170.215(a)(3).
  19. AUT-PAT-19: [Both] The health IT developer demonstrates the ability of the Health IT Module to return a “Patient” FHIR® resource that matches the patient context provided in step AUT-PAT-9 of this section according to the implementation specification adopted in § 170.215(a)(2).
  20. AUT-PAT-32: [EHR-Launch] The following must be supported if using US Core 5.0.1: The health IT developer demonstrates the ability of the Health IT Module to return an “Encounter” FHIR® resource that matches the encounter context provided in step AUT-PAT-9 of this section according to the implementation specification adopted in § 170.215(a)(2).
  21. AUT-PAT-20: [Both] The health IT developer demonstrates the ability of the Health IT Module to grant an access token when a refresh token is supplied according to the implementation specification adopted in § 170.215(a)(2).
  22. AUT-PAT-21: [Both] The health IT developer demonstrates the ability of the Health IT Module to grant a refresh token valid for a period of no less than three months to native applications capable of securing a refresh token.

Subsequent Connections: Authentication and Authorization for Patient and User Scopes

  1. AUT-PAT-22: The health IT developer demonstrates the ability of the Health IT Module to issue a refresh token valid for a new period of no shorter than three months without requiring re-authentication and re-authorization when a valid refresh token is supplied by the application according to the implementation specification adopted in § 170.215(a)(3).
  2. AUT-PAT-23: The health IT developer demonstrates the ability of the Health IT Module to return an error response when supplied an invalid refresh token as specified in the implementation specification adopted in § 170.215(a)(3).

SVAP Version Approved: SMART 2.0.0

Authentication and Authorization for Patient and User Scopes

  1. AUT-PAT-1: The health IT developer demonstrates the ability of the Health IT Module to support the following for “EHR-Launch,” “Standalone-Launch,” and “Both” (“EHR-Launch” and “Standalone-Launch”) as specified in the implementation specification adopted in § 170.215(a)(3).
  2. AUT-PAT-2: [EHR-Launch] The health IT developer demonstrates the ability of the Health IT Module to initiate a “launch sequence” using the “launch-ehr" “SMART on FHIR® Core Capability” SMART EHR Launch mode detailed in the implementation specification adopted in § 170.215(a)(3), including:
    • Launching the registered launch URL of the application; and
    • Passing the parameters: “iss” and “launch”.
  3. AUT-PAT-3: [Standalone-Launch] The health IT developer demonstrates the ability of the Health IT Module to launch using the “launch-standalone" “SMART on FHIR® Core Capability” SMART Standalone Launch mode detailed in the implementation specification adopted in § 170.215(a)(3).
  4. AUT-PAT-4: [Standalone-Launch] The health IT developer demonstrates the ability of the Health IT Module to support SMART’s public client profile.
  5. AUT-PAT-24: [Both] The health IT developer demonstrates the ability of the Health IT Module to support a “.well-known/smart-configuration.json” path as detailed in the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(a)(1).
  6. AUT-PAT-25: [Both] The health IT developer demonstrates the ability of the “.well-known/smart-configuration.json” path to support at least the following as detailed in the implementation specification adopted in § 170.215(a)(3):
    • “authorization_endpoint”;
    • “token_endpoint”;
    • “capabilities” including support for “launch-ehr", “launch-standalone”, “client-public”, “client-confidential-symmetric", “sso-openid-connect", “context-banner”, “context-style”, “context-ehr-patient", “context-standalone-patient", “permission-offline”, “permission-patient”, “permission-user”, “authorize-post”, “permission-v2”;
    • “grant_types_supported” with support for “authorization_code” and “client_credentials”; and
    • “code_challenge_methods_supported” with support for “S256” and shall not include support for “plain”
    • Additionally, the following “capabilities” must be supported if using US Core 5.0.1:
    • "context-ehr-encounter"
  7. AUT-PAT-26: [Both] The health IT developer demonstrates the ability of the Health IT Module to receive an authorization request according to the implementation specification adopted in § 170.215(a)(3), including support for the following parameters:
    • “response_type”;
    • “client_id”;
    • “redirect_uri”;
    • “launch” (for EHR-Launch mode only);
    • “scope”;
    • “state”;
    • “aud”;
    • “code_challenge”; and
    • “code_challenge_method”
  8. AUT-PAT-27: [Both] The health IT developer demonstrates the ability of the Health IT Module’s Authorization Server to support the use of the HTTP GET and POST methods at the Authorization Endpoint as detailed in the implementation specification adopted in § 170.215(a)(3).
  9. AUT-PAT-28: [Both] The health IT developer demonstrates the ability of the Health IT Module to support the receipt of the following scopes and capabilities according to the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b):
    • “openid” (to support “sso-openid-connect” “SMART on FHIR® Capability”);
    • “FHIR®User” (to support “sso-openid-connect” “SMART on FHIR® Capability”);
    • “need_patient_banner” (to support “context-banner” “SMART on FHIR® Capability” for EHR-Launch mode only);
    • “smart_style_url” (to support “context-style” “SMART on FHIR® Capability” for EHR-Launch mode only);
    • “launch/patient” (to support “context-standalone-patient” “SMART on FHIR® Capability” for Standalone-Launch mode only);
    • “launch” (for EHR-Launch mode only);
    • “offline_access” (to support “permission-offline” “SMART on FHIR® Capability”);
    • Patient-level scopes (to support “permission-patient” and “SMART on FHIR® Capability”); and
    • User-level scopes (to support “permission-user” “SMART on FHIR® Capability”).
    • SMARTv2 scope syntax for patient-level and user-level scopes (to support “permission-v2” “SMART on FHIR® Capability”)
  10. AUT-PAT-10: [Both] The health IT developer demonstrates the ability of the Health IT Module to evaluate the authorization request and request end-user input, if applicable (required for patient-facing applications), including the ability for the end-user to authorize an application to receive EHI based on FHIR® resource-level scopes for all of the FHIR® resources associated with the profiles specified in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2).
    If using US Core 3.1.1, 4.0.0, or 5.0.1, these resources include:
    • “AllergyIntolerance”;
    • “CarePlan”;
    • “CareTeam”;
    • “Condition”;
    • “Device”;
    • “DiagnosticReport”;
    • “DocumentReference”;
    • “Goal”;
    • “Immunization”;
    • “Medication” (if supported);
    • “MedicationRequest”;
    • “Observation”;
    • “Patient”;
    • “Procedure”; and
    • “Provenance”.
      Additionally, the following resources must be supported if using US Core 5.0.1:
    • “Encounter”;
    • “RelatedPerson”; and
    • “ServiceRequest”
  11. AUT-PAT-11: [Both] The health IT developer demonstrates the ability of the Health IT Module to evaluate the authorization request and request end-user input, if applicable (required for patient-facing applications), including either the ability for the end-user to explicitly enable / disable the “offline_access” scope or information communicating the application’s request for the “offline_access” scope.
  12. AUT-PAT-12: [Both] The health IT developer demonstrates the ability of the Health IT Module to deny an application’s authorization request according to a patient’s preferences selected in AUT-PAT-10, and AUT-PAT-11, of this section in accordance with the implementation specification adopted in § 170.215(a)(3).
  13. AUT-PAT-29: [EHR-Launch] The health IT developer demonstrates the ability of the Health IT Module to establish a patient in context if an application requests a clinical scope which is restricted to a single patient as detailed in the implementation specification adopted in § 170.215(a)(3).
  14. AUT-PAT-13: [Both] The health IT developer demonstrates the ability of the Health IT Module to return an error response if the "aud" parameter provided by an application to the Health IT Module in AUT-PAT-8, is not a valid FHIR® resource server associated with the Health IT Module's authorization server.
  15. AUT-PAT-14: [Both] The health IT developer demonstrates the ability of the Health IT Module to grant an application access to EHI by returning an authorization code to the application according to the implementation specification adopted in § 170.215(a)(3), including the following parameters:
    • “code”; and
    • “state”.
  16. AUT-PAT-30: [Both] The health IT developer demonstrates the ability of the Health IT Module to receive the following access token request parameters from an application according to the implementation specification adopted in § 170.215(a)(3):
    • “grant_type”;
    • “code”;
    • “redirect_uri”;
    • “code_verifier”;
    • “client_id”; and
    • Authorization header including “client_id” and “client_secret”.
  17. AUT-PAT-31: [Both] The health IT developer demonstrates the ability of the Health IT Module to return an error response if an invalid “code_verifier” value is supplied with an access token request according to the implementation specification adopted in § 170.215(a)(3).
  18. AUT-PAT-16: [Both] The health IT developer demonstrates the ability of the Health IT Module to return a JSON object to applications according to the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b), including the following:
    • “access_token”;
    • “token_type”;
    • “scope”;
    • “id_token”;
    • “refresh_token” (valid for a period of no shorter than three months);
    • HTTP “Cache-Control” response header field with a value of “no-store”;
    • HTTP “Pragma” response header field with a value of “no-cache”;
    • “patient” (to support “context-ehr-patient” and “context-standalone-patient” “SMART on FHIR® Core Capabilities”);
    • “need_patient_banner” (to support “context-banner” “SMART on FHIR® Core Capability” for EHR-Launch mode only); and
    • “smart_style_url” (to support “context-style” “SMART on FHIR® Core Capability” for EHR-Launch mode only).
      Additionally, the following must be supported if using US Core 5.0.1:
    • “encounter” (to support "context-ehr-encounter" “SMART on FHIR® Capability”)
  19. AUT-PAT-17: [Both] The health IT developer demonstrates the ability of the Health IT Module to provide an OpenID Connect well-known URI in accordance with the implementation specification adopted in § 170.215(b), including:
    • All required fields populated according to implementation specification adopted in § 170.215(b); and
    • Valid JWKS populated according to implementation specification can be retrieved via JWKS URI.
  20. AUT-PAT-18: [Both] The health IT developer demonstrates the ability of the Health IT Module to deny an application’s authorization request in accordance with the implementation specification adopted in § 170.215(a)(3).
  21. AUT-PAT-19: [Both] The health IT developer demonstrates the ability of the Health IT Module to return a “Patient” FHIR® resource that matches the patient context provided in step AUT-PAT-9 of this section according to the implementation specification adopted in § 170.215(a)(2).
  22. AUT-PAT-32: [EHR-Launch] The following must be supported if using US Core 5.0.1: The health IT developer demonstrates the ability of the Health IT Module to return an “Encounter” FHIR® resource that matches the encounter context provided in step AUT-PAT-9 of this section according to the implementation specification adopted in § 170.215(a)(2).
  23. AUT-PAT-20: [Both] The health IT developer demonstrates the ability of the Health IT Module to grant an access token when a refresh token is supplied according to the implementation specification adopted in § 170.215(a)(2).
  24. AUT-PAT-21: [Both] The health IT developer demonstrates the ability of the Health IT Module to grant a refresh token valid for a period of no less than three months to native applications capable of securing a refresh token.

Subsequent Connections: Authentication and Authorization for Patient and User Scopes

  1. AUT-PAT-22: The health IT developer demonstrates the ability of the Health IT Module to issue a refresh token valid for a new period of no shorter than three months without requiring re-authentication and re-authorization when a valid refresh token is supplied by the application according to the implementation specification adopted in § 170.215(a)(3).
  2. AUT-PAT-23: The health IT developer demonstrates the ability of the Health IT Module to return an error response when supplied an invalid refresh token as specified in the implementation specification adopted in § 170.215(a)(3).

Regulatory Standard: SMART 1.0.0

Authentication and Authorization for Patient and User Scopes

  1. AUT-PAT-1: The tester verifies the ability of the Health IT Module to support the following for “EHR-Launch,” “Standalone-Launch,” and “Both” (“EHR-Launch” and “Standalone-Launch”) as specified in the implementation specification adopted in § 170.215(a)(3).
  2. AUT-PAT-2: [EHR-Launch] The tester verifies the ability of the Health IT Module to initiate a “launch sequence” using the “launch-ehr" “SMART on FHIR® Core Capability” SMART EHR Launch mode detailed in the implementation specification adopted in § 170.215(a)(3), including:
    • Launching the registered launch URL of the application; and
    • Passing the parameters: “iss” and “launch”.
  3. AUT-PAT-3: [Standalone-Launch] The tester verifies the ability of the Health IT Module to launch using the “launch-standalone" “SMART on FHIR® Core Capability” SMART Standalone Launch mode detailed in the implementation specification adopted in § 170.215(a)(3).
  4. AUT-PAT-4: [Standalone-Launch] The tester verifies the ability of the Health IT Module to support SMART’s public client profile.
  5. AUT-PAT-5: [Both] The tester verifies the ability of the Health IT Module to support the following as detailed in the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(a)(1):
    • The “.well-known/smart-configuration.json” path; and
    • A FHIR® “CapabilityStatement”.
  6. AUT-PAT-6: [Both] The tester verifies the ability of the “.well-known/smart-configuration.json” path to support at least the following as detailed in the implementation specification adopted in § 170.215(a)(3):
    • “authorization_endpoint”;
    • “token_endpoint”; and
    • “capabilities” (including support for all the “SMART on FHIR® Core Capabilities”).
  7. AUT-PAT-7: [Both] The tester verifies the ability of the FHIR® “CapabilityStatement” to support at least the following components as detailed in the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(a)(1), including:
    • “authorize”; and
    • “token”.
  8. AUT-PAT-8: [Both] The tester verifies the ability of the Health IT Module to receive an authorization request according to the implementation specification adopted in § 170.215(a)(3), including support for the following parameters:
    • “response_type”;
    • “client_id”;
    • “redirect_uri”;
    • “launch” (for EHR-Launch mode only);
    • “scope”;
    • “state”; and
    • “aud”.
  9. AUT-PAT-9: [Both] The tester verifies the ability of the Health IT Module to support the receipt of the following scopes according to the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b):
    • “openid” (to support “sso-openid-connect” “SMART on FHIR® Core Capability”);
    • “FHIR®User” (to support “sso-openid-connect” “SMART on FHIR® Core Capability”);
    • “need_patient_banner” (to support “context-banner” “SMART on FHIR® Core Capability” for EHR-Launch mode only);
    • “smart_style_url” (to support “context-style” “SMART on FHIR® Core Capability” for EHR-Launch mode only);
    • “launch/patient” (to support “context-standalone-patient” “SMART on FHIR® Core Capability” for Standalone-Launch mode only);
    • “launch” (for EHR-Launch mode only);
    • “offline_access” (to support “permission-offline” “SMART on FHIR® Core Capability”);
    • Patient-level scopes (to support “permission-patient” “SMART on FHIR® Core Capability”); and
    • User-level scopes (to support “permission-user” “SMART on FHIR® Core Capability”).
  10. AUT-PAT-10: [Both] The tester verifies the ability of the Health IT Module to evaluate the authorization request and request end-user input, if applicable (required for patient-facing applications), including the ability for the end-user to authorize an application to receive EHI based on FHIR® resource-level scopes for all of the FHIR® resources associated with the profiles specified in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2).
    If using US Core 3.1.1, 4.0.0, or 5.0.1, these resources include:
    • “AllergyIntolerance”;
    • “CarePlan”;
    • “CareTeam”;
    • “Condition”;
    • “Device”;
    • “DiagnosticReport”;
    • “DocumentReference”;
    • “Goal”;
    • “Immunization”;
    • “Medication” (if supported);
    • “MedicationRequest”;
    • “Observation”;
    • “Patient”;
    • “Procedure”; and
    • “Provenance”.
      Additionally, the following resources must be supported if using US Core 5.0.1:
    • “Encounter”;
    • “RelatedPerson”; and
    • “ServiceRequest”
  11. AUT-PAT-11: [Both] The tester verifies the ability of the Health IT Module to evaluate the authorization request and request end-user input, if applicable (required for patient-facing applications), including either the ability for the end-user to explicitly enable / disable the “offline_access” scope or information communicating the application’s request for the “offline_access” scope.
  12. AUT-PAT-12: [Both] The tester verifies the ability of the Health IT Module to deny an application’s authorization request according to a patient’s preferences selected in AUT-PAT-10, and AUT-PAT-11, of this section in accordance with the implementation specification adopted in § 170.215(a)(3).
  13. AUT-PAT-13: [Both] The tester verifies the ability of the Health IT Module to return an error response if the "aud" parameter provided by an application to the Health IT Module in AUT-PAT-8, is not a valid FHIR® resource server associated with the Health IT Module's authorization server.
  14. AUT-PAT-14: [Both] The tester verifies the ability of the Health IT Module to grant an application access to EHI by returning an authorization code to the application according to the implementation specification adopted in § 170.215(a)(3), including the following parameters:
    • “code”; and
    • “state”.
  15. AUT-PAT-15: [Both] The tester verifies the ability of the Health IT Module to receive the following parameters from an application according to the implementation specification adopted in § 170.215(a)(3):
    • “grant_type”;
    • “code”;
    • “redirect_uri”;
    • “client_id”; and
    • Authorization header including “client_id” and “client_secret”.
  16. AUT-PAT-16: [Both] The tester verifies the ability of the Health IT Module to return a JSON object to applications according to the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b), including the following:
    • “access_token”;
    • “token_type”;
    • “scope”;
    • “id_token”;
    • “refresh_token” (valid for a period of no shorter than three months);
    • HTTP “Cache-Control” response header field with a value of “no-store”;
    • HTTP “Pragma” response header field with a value of “no-cache”;
    • “patient” (to support “context-ehr-patient” and “context-standalone-patient” “SMART on FHIR® Core Capabilities”);
    • “need_patient_banner” (to support “context-banner” “SMART on FHIR® Core Capability” for EHR-Launch mode only); and
    • “smart_style_url” (to support “context-style” “SMART on FHIR® Core Capability” for EHR-Launch mode only).
    • Additionally, the following must be supported if using US Core 5.0.1:
    • “encounter” (to support"context-ehr-encounter" “SMART on FHIR® Capability”)
  17. AUT-PAT-17: [Both] The tester verifies the ability of the Health IT Module to provide an OpenID Connect well-known URI in accordance with the implementation specification adopted in § 170.215(b), including:
    • All required fields populated according to implementation specification adopted in § 170.215(b); and
    • Valid JWKS populated according to implementation specification can be retrieved via JWKS URI.
  18. AUT-PAT-18: [Both] The tester verifies the ability of the Health IT Module to deny an application’s authorization request in accordance with the implementation specification adopted in § 170.215(a)(3).
  19. AUT-PAT-19: [Both] The tester verifies the ability of the Health IT Module to return a “Patient” FHIR® resource that matches the patient context provided in step AUT-PAT-9 of this section according to the implementation specification adopted in § 170.215(a)(2).
  20. AUT-PAT-32: [EHR-Launch] The following must be supported if using US Core 5.0.1: The tester verifies the ability of the Health IT Module to return an “Encounter” FHIR® resource that matches the encounter context provided in step AUT-PAT-9 of this section according to the implementation specification adopted in § 170.215(a)(2).
  21. AUT-PAT-20: [Both] The tester verifies the ability of the Health IT Module to grant an access token when a refresh token is supplied according to the implementation specification adopted in § 170.215(a)(2).
  22. AUT-PAT-21: [Both] The tester verifies the ability of the Health IT Module to grant a refresh token valid for a period of no less than three months to native applications capable of securing a refresh token.

Subsequent Connections: Authentication and Authorization for Patient and User Scopes

  1. AUT-PAT-22: The tester verifies the ability of the Health IT Module to issue a refresh token valid for a new period of no shorter than three months without requiring re-authentication and re-authorization when a valid refresh token is supplied by the application according to the implementation specification adopted in § 170.215(a)(3).
  2. AUT-PAT-23: The tester verifies the ability of the Health IT Module to return an error response when supplied an invalid refresh token as specified in the implementation specification adopted in § 170.215(a)(3).

SVAP Version Approved: SMART 2.0.0

Authentication and Authorization for Patient and User Scopes

  1. AUT-PAT-1:  The tester verifies the ability of the Health IT Module to support the following for “EHR-Launch,” “Standalone-Launch,” and “Both” (“EHR-Launch” and “Standalone-Launch”) as specified in the implementation specification adopted in § 170.215(a)(3).
  2. AUT-PAT-2: [EHR-Launch] The tester verifies the ability of the Health IT Module to initiate a “launch sequence” using the “launch-ehr" “SMART on FHIR® Core Capability” SMART EHR Launch mode detailed in the implementation specification adopted in § 170.215(a)(3), including:
    • Launching the registered launch URL of the application; and
    • Passing the parameters: “iss” and “launch”.
  3. AUT-PAT-3: [Standalone-Launch] The tester verifies the ability of the Health IT Module to launch using the “launch-standalone" “SMART on FHIR® Core Capability” SMART Standalone Launch mode detailed in the implementation specification adopted in § 170.215(a)(3).
  4. AUT-PAT-4: [Standalone-Launch] The tester verifies the ability of the Health IT Module to support SMART’s public client profile.
  5. AUT-PAT-24: [Both] The tester verifies the ability of the Health IT Module to support a “.well-known/smart-configuration.json” path as detailed in the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(a)(1).
  6. AUT-PAT-25: [Both] The tester verifies the ability of the “.well-known/smart-configuration.json” path to support at least the following as detailed in the implementation specification adopted in § 170.215(a)(3):
    • “authorization_endpoint”;
    • “token_endpoint”;
    • “capabilities” including support for “launch-ehr", “launch-standalone”, “client-public”, “client-confidential-symmetric", “sso-openid-connect", “context-banner”, “context-style”, “context-ehr-patient", “context-standalone-patient", “permission-offline”, “permission-patient”, “permission-user”, “authorize-post”, “permission-v2”;
    • “grant_types_supported” with support for “authorization_code” and “client_credentials”; and
    • “code_challenge_methods_supported” with support for “S256” and shall not include support for “plain” 
      Additionally, the following “capabilities” must be supported if using US Core 5.0.1:
    • "context-ehr-encounter"
  7. AUT-PAT-26: [Both] The tester verifies the ability of the Health IT Module to receive an authorization request according to the implementation specification adopted in § 170.215(a)(3), including support for the following parameters:
    • “response_type”;
    • “client_id”;
    • “redirect_uri”;
    • “launch” (for EHR-Launch mode only);
    • “scope”;
    • “state”;
    • “aud”;
    • “code_challenge”; and
    • “code_challenge_method”
  8. AUT-PAT-27: [Both] The tester verifies the ability of the Health IT Module’s Authorization Server to support the use of the HTTP GET and POST methods at the Authorization Endpoint as detailed in the implementation specification adopted in § 170.215(a)(3).
  9. AUT-PAT-28: [Both] The tester verifies the ability of the Health IT Module to support the receipt of the following scopes and capabilities according to the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b):
    • “openid” (to support “sso-openid-connect” “SMART on FHIR® Capability”);
    • “FHIR®User” (to support “sso-openid-connect” “SMART on FHIR® Capability”);
    • “need_patient_banner” (to support “context-banner” “SMART on FHIR® Capability” for EHR-Launch mode only);
    • “smart_style_url” (to support “context-style” “SMART on FHIR® Capability” for EHR-Launch mode only);
    • “launch/patient” (to support “context-standalone-patient” “SMART on FHIR® Capability” for Standalone-Launch mode only);
    • “launch” (for EHR-Launch mode only);
    • “offline_access” (to support “permission-offline” “SMART on FHIR® Capability”);
    • Patient-level scopes (to support “permission-patient” and “SMART on FHIR® Capability”); and
    • User-level scopes (to support “permission-user” “SMART on FHIR® Capability”).
    • SMARTv2 scope syntax for patient-level and user-level scopes (to support “permission-v2” “SMART on FHIR® Capability”)
  10. AUT-PAT-10: [Both] The tester verifies the ability of the Health IT Module to evaluate the authorization request and request end-user input, if applicable (required for patient-facing applications), including the ability for the end-user to authorize an application to receive EHI based on FHIR® resource-level scopes for all of the FHIR® resources associated with the profiles specified in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2):
    If using US Core 3.1.1, 4.0.0, or 5.0.1, these resources include:
    • “AllergyIntolerance”;
    • “CarePlan”;
    • “CareTeam”;
    • “Condition”;
    • “Device”;
    • “DiagnosticReport”;
    • “DocumentReference”;
    • “Goal”;
    • “Immunization”;
    • “Medication” (if supported);
    • “MedicationRequest”;
    • “Observation”;
    • “Patient”;
    • “Procedure”; and
    • “Provenance”.
      Additionally, the following resources must be supported if using US Core 5.0.1:
    • “Encounter”;
    • “RelatedPerson”; and
    • “ServiceRequest”
  11. AUT-PAT-11: [Both] The tester verifies the ability of the Health IT Module to evaluate the authorization request and request end-user input, if applicable (required for patient-facing applications), including either the ability for the end-user to explicitly enable / disable the “offline_access” scope or information communicating the application’s request for the “offline_access” scope.
  12. AUT-PAT-12: [Both] The tester verifies the ability of the Health IT Module to deny an application’s authorization request according to a patient’s preferences selected in AUT-PAT-10, and AUT-PAT-11, of this section in accordance with the implementation specification adopted in § 170.215(a)(3).
  13. AUT-PAT-29: [EHR-Launch] The tester verifies the ability of the Health IT Module to establish a patient in context if an application requests a clinical scope which is restricted to a single patient as detailed in the implementation specification adopted in § 170.215(a)(3).
  14. AUT-PAT-13: [Both] The tester verifies the ability of the Health IT Module to return an error response if the "aud" parameter provided by an application to the Health IT Module in AUT-PAT-8, is not a valid FHIR® resource server associated with the Health IT Module's authorization server.
  15. AUT-PAT-14: [Both] The tester verifies the ability of the Health IT Module to grant an application access to EHI by returning an authorization code to the application according to the implementation specification adopted in § 170.215(a)(3), including the following parameters:
    • “code”; and
    • “state”.
  16. AUT-PAT-30: [Both] The tester verifies the ability of the Health IT Module to receive the following access token request parameters from an application according to the implementation specification adopted in § 170.215(a)(3):
    • “grant_type”;
    • “code”;
    • “redirect_uri”;
    • “code_verifier”;
    • “client_id”; and
    • Authorization header including “client_id” and “client_secret”.
  17. AUT-PAT-31: [Both] The tester verifies the ability of the Health IT Module to return an error response if an invalid “code_verifier” value is supplied with an access token request according to the implementation specification adopted in § 170.215(a)(3).
  18. AUT-PAT-16: [Both] The tester verifies the ability of the Health IT Module to return a JSON object to applications according to the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b), including the following:
    • “access_token”;
    • “token_type”;
    • “scope”;
    • “id_token”;
    • “refresh_token” (valid for a period of no shorter than three months);
    • HTTP “Cache-Control” response header field with a value of “no-store”;
    • HTTP “Pragma” response header field with a value of “no-cache”;
    • “patient” (to support “context-ehr-patient” and “context-standalone-patient” “SMART on FHIR® Core Capabilities”);
    • “need_patient_banner” (to support “context-banner” “SMART on FHIR® Core Capability” for EHR-Launch mode only); and
    • “smart_style_url” (to support “context-style” “SMART on FHIR® Core Capability” for EHR-Launch mode only).
      Additionally, the following must be supported if using US Core 5.0.1:
    • “encounter” (to support "context-ehr-encounter" “SMART on FHIR® Capability”)
  19. AUT-PAT-17: [Both] The tester verifies the ability of the Health IT Module to provide an OpenID Connect well-known URI in accordance with the implementation specification adopted in § 170.215(b), including:
    • All required fields populated according to implementation specification adopted in § 170.215(b); and
    • Valid JWKS populated according to implementation specification can be retrieved via JWKS URI.
  20. AUT-PAT-18: [Both] The tester verifies the ability of the Health IT Module to deny an application’s authorization request in accordance with the implementation specification adopted in § 170.215(a)(3).
  21. AUT-PAT-19: [Both] The tester verifies the ability of the Health IT Module to return a “Patient” FHIR® resource that matches the patient context provided in step AUT-PAT-9 of this section according to the implementation specification adopted in § 170.215(a)(2).
  22. AUT-PAT-32: [EHR-Launch] The following must be supported if using US Core 5.0.1: The tester verifies the ability of the Health IT Module to return an “Encounter” FHIR® resource that matches the encounter context provided in step AUT-PAT-9 of this section according to the implementation specification adopted in § 170.215(a)(2).
  23. AUT-PAT-20: [Both] The tester verifies the ability of the Health IT Module to grant an access token when a refresh token is supplied according to the implementation specification adopted in § 170.215(a)(2).
  24. AUT-PAT-21: [Both] The tester verifies the ability of the Health IT Module to grant a refresh token valid for a period of no less than three months to native applications capable of securing a refresh token.

Subsequent Connections: Authentication and Authorization for Patient and User Scopes

  1. AUT-PAT-22: The tester verifies the ability of the Health IT Module to issue a refresh token valid for a new period of no shorter than three months without requiring re-authentication and re-authorization when a valid refresh token is supplied by the application according to the implementation specification adopted in § 170.215(a)(3).
  2. AUT-PAT-23: The tester verifies the ability of the Health IT Module to return an error response when supplied an invalid refresh token as specified in the implementation specification adopted in § 170.215(a)(3).

System Under Test Test Lab Verification

Certification Option: Applies to all applicable base regulatory and SVAP standards

Patient Authorization Revocation

  1. PAR-1: The health IT developer demonstrates the ability of the Health IT Module to revoke access to an authorized application at a patient’s direction, including a demonstration of the inability of the application with revoked access to receive patient EHI.

Certification Option: Applies to all applicable base regulatory and SVAP standards

Patient Authorization Revocation

  1. PAR-1: The tester verifies the ability of the Health IT Module to revoke access to an authorized application at a patient’s direction, including a demonstration of the inability of the application with revoked access to receive patient EHI.

System Under Test Test Lab Verification

Certification Option: Applies to all applicable base regulatory and SVAP standards

Authentication and Authorization for System Scopes

  1. AUT-SYS-1: The health IT developer demonstrates the ability of the Health IT Module to support OAuth 2.0 client credentials grant flow in accordance with the implementation specification adopted in § 170.215(a)(4).
  2. AUT-SYS-2: The health IT developer demonstrates the ability of the Health IT Module to support the following parameters according to the implementation specification adopted in § 170.215(a)(4):
    • “scope”;
    • “grant_type”;
    • “client_assertion_type”; and
    • “client_assertion”.
  3. AUT-SYS-3: The health IT developer demonstrates the ability of the Health IT Module to support the following JSON Web Token (JWT) Headers and Claims according to the implementation specification adopted in § 170.215(a)(4):
    • “alg” header;
    • “kid” header;
    • “typ” header;
    • “iss” claim;
    • “sub” claim;
    • “aud” claim;
    • “exp” claim; and
    • “jti” claim.
  4. AUT-SYS-4: The health IT developer demonstrates the ability of the Health IT Module to receive and process the JSON Web Key (JWK) Set via a TLS-protected URL to support authorization for system scopes in § 170.315(g)(10)(v)(B).
  5. AUT-SYS-5: The health IT developer demonstrates that the Health IT Module does not cache a JWK Set received via a TLS-protected URL for longer than the “cache-control” header sent by an application indicates.
  6. AUT-SYS-6: The health IT developer demonstrates the ability of the Health IT Module to validate an application’s JWT, including its JSON Web Signatures, according to the implementation specification adopted in § 170.215(a)(4).
  7. AUT-SYS-7: The health IT developer demonstrates the ability of the Health IT Module to respond with an “invalid_client” error for errors encountered during the authentication process according to the implementation specification adopted in § 170.215(a)(4).
  8. AUT-SYS-8: The health IT developer demonstrates the ability of the Health IT Module to assure the scope granted based on the scope requested by an application is no greater than the pre-authorized scope for multiple patients according to the implementation specification adopted in § 170.215(a)(4).
  9. AUT-SYS-9: The health IT developer demonstrates the ability of the Health IT Module to issue an access token to an application as a JSON object in accordance with the implementation specification adopted in § 170.215(a)(4), including the following property names:
    • “access_token”;
    • “token_type”;
    • “expires_in”; and
    • “scope”.
  10. AUT-SYS-10: The health IT developer demonstrates the ability of the Health IT Module to respond to errors using the appropriate error messages as specified in the implementation specification adopted in § 170.215(a)(4).

Certification Option: Applies to all applicable base regulatory and SVAP standards

Authentication and Authorization for System Scopes

  1. AUT-SYS-1: The tester verifies the ability of the Health IT Module to support OAuth 2.0 client credentials grant flow in accordance with the implementation specification adopted in § 170.215(a)(4).
  2. AUT-SYS-2: The tester verifies the ability of the Health IT Module to support the following parameters according to the implementation specification adopted in § 170.215(a)(4):
    • “scope”;
    • “grant_type”;
    • “client_assertion_type”; and
    • “client_assertion”.
  3. AUT-SYS-3: The tester verifies the ability of the Health IT Module to support the following JSON Web Token (JWT) Headers and Claims according to the implementation specification adopted in § 170.215(a)(4):
    • “alg” header;
    • “kid” header;
    • “typ” header;
    • “iss” claim;
    • “sub” claim;
    • “aud” claim;
    • “exp” claim; and
    • “jti” claim.
  4. AUT-SYS-4: The tester verifies the ability of the Health IT Module to receive and process the JWK structure via a TLS-protected URL to support authorization for system scopes in § 170.315(g)(10)(v)(B).
  5. AUT-SYS-5: The tester verifies that the Health IT Module does not cache a JWK Set received via a TLS-protected URL for longer than the “cache-control” header sent by an application indicates.
  6. AUT-SYS-6: The tester verifies the ability of the Health IT Module to validate an application’s JWT, including its JSON Web Signatures, according to the implementation specification adopted in § 170.215(a)(4).
  7. AUT-SYS-7: The tester verifies the ability of the Health IT Module to respond with an “invalid_client” error for errors encountered during the authentication process according to the implementation specification adopted in § 170.215(a)(4).
  8. AUT-SYS-8: The tester verifies the ability of the Health IT Module to assure the scope granted based on the scope requested by an application is no greater than the pre-authorized scope for multiple patients according to the implementation specification adopted in § 170.215(a)(4).
  9. AUT-SYS-9: The tester verifies the ability of the Health IT Module to issue an access token to an application as a JSON object in accordance with the implementation specification adopted in § 170.215(a)(4), including the following property names:
    • “access_token”;
    • “token_type”;
    • “expires_in”; and
    • “scope”.
  10. AUT-SYS-10: The tester verifies the ability of the Health IT Module to respond to errors using the appropriate error messages as specified in the implementation specification adopted in § 170.215(a)(4).

System Under Test Test Lab Verification

Certification Option: Applies to all applicable base regulatory and SVAP standards

Token Introspection

  1. TOK-INTRO-1: The health IT developer demonstrates the ability of the Health IT Module to receive and validate a token it has issued.

Certification Option: Applies to all applicable base regulatory and SVAP standards

Token Introspection

  1. TOK-INTRO-1: The tester verifies the ability of the Health IT Module to receive and validate a token it has issued.

System Under Test Test Lab Verification

Certification Option: Applies to all applicable base regulatory and SVAP standards

Supported Search Operations for a Single Patient’s Data

  1. SH-PAT-1: The health IT developer demonstrates the ability of the Health IT Module to support the “capabilities” interaction as specified in the standard adopted in § 170.215(a)(1), including support for a “CapabilityStatement” as specified in the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2).
  2. SH-PAT-2: The health IT developer demonstrates the ability of the Health IT Module to respond to requests for a single patient’s data consistent with the search criteria detailed in the “US Core Server CapabilityStatement” section of the implementation specification adopted in § 170.215(a)(2), including demonstrating search support for “SHALL” operations and parameters for all the data included in the standard adopted in § 170.213.
  3. SH-PAT-3: The health IT developer demonstrates the ability of the Health IT Module to support a resource search for the provenance target “(_revIncludes: Provenance:target)” for all the FHIR® resources included in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2) according to the “Basic Provenance Guidance” section of the implementation specification adopted in § 170.215(a)(2).

Supported Search Operations for Multiple Patients’ Data

  1. SH-PAT-4: The health IT developer demonstrates the ability of the Health IT Module to support the “capabilities” interaction as specified in the standard adopted in § 170.215(a)(1), including support for a “CapabilityStatement” as specified in the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(4).
  2. SH-PAT-5: The health IT developer demonstrates the ability of the Health IT Module to support requests for multiple patients’ data as a group using the “group-export” operation as detailed in the implementation specification adopted in § 170.215(a)(4).

Certification Option: Applies to all applicable base regulatory and SVAP standards

Supported Search Operations for a Single Patient’s Data

  1. SH-PAT-1: The tester verifies the ability of the Health IT Module to support the “capabilities” interaction as specified in the standard adopted in § 170.215(a)(1), including support for a “CapabilityStatement” as specified in the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2).
  2. SH-PAT-2: The tester verifies the ability of the Health IT Module to respond to requests for a single patient’s data consistent with the search criteria detailed in the “US Core Server CapabilityStatement” section of the implementation specification adopted in § 170.215(a)(2), including demonstrating search support for “SHALL” operations and parameters for all the data included in the standard adopted in § 170.213.
  3. SH-PAT-3: The tester verifies the ability of the Health IT Module to support a resource search for the provenance target “(_revIncludes: Provenance:target)” for all the FHIR® resources included in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2) according to the “Basic Provenance Guidance” section of the implementation specification adopted in § 170.215(a)(2).

Supported Search Operations for Multiple Patients’ Data

  1. SH-PAT-4: The tester verifies the ability of the Health IT Module to support the “capabilities” interaction as specified in the standard adopted in § 170.215(a)(1), including support for a “CapabilityStatement” as specified in the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(4).
  2. SH-PAT-5: The tester verifies the ability of the Health IT Module to support requests for multiple patients’ data as a group using the “group-export” operation as detailed in the implementation specification adopted in § 170.215(a)(4).

System Under Test Test Lab Verification

Applies to Regulatory Standard (USCDI v1 + US Core STU v3.1.1) and SVAP Version Approved (USCDI v1 + US Core STU v4.0.0)

Data Response Checks for Single and Multiple Patients

  1. DAT-PAT-1: For responses to data for single and multiple patients as described in steps DAT-PAT-7, and DAT-PAT-8, of this section respectively, the health IT developer demonstrates the ability of the Health IT Module to respond to requests for data according to the implementation specification adopted in § 170.215(a)(2), including the following steps.
  2. DAT-PAT-2: The health IT developer demonstrates the ability of the Health IT Module to respond with data that meet the following conditions:
    • All data elements indicated with a cardinality of one or greater and / or “must support” are included;
    • Content is structurally correct;
    • All invariant rules are met;
    • All data elements with required “ValueSet” bindings contain codes within the bound “ValueSet”;
    • All information is accurate and without omission; and
    • All references within the resources can be resolved and validated, as applicable, according to steps DAT-PAT-2, DAT-PAT-3, DAT-PAT-4, DAT-PAT-5, and DAT-PAT-6, of this section.
  3. DAT-PAT-3: The health IT developer demonstrates the ability of the Health IT Module to support a “Provenance” FHIR® resource for all the FHIR® resources included in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2) according to the “Basic Provenance Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  4. DAT-PAT-4: The health IT developer demonstrates the ability of the Health IT Module to support a “DocumentReference” and/or “DiagnosticReport” FHIR® resource for each of the “Clinical Notes” and “Diagnostic Reports” included in and according to the “Clinical Notes Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  5. DAT-PAT-5: If supported, and for responses to data for a single patient only, the health IT developer demonstrates the ability of the Health IT Module to support a “Medication” FHIR® resource according to the “Medication List Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  6. DAT-PAT-6: The health IT developer demonstrates the ability of the Health IT Module to support “Missing Data” according to the implementation specification adopted in § 170. 215(a)(2), including:
    • For non-coded data elements; and
    • For coded data elements, including support for the “DataAbsentReason” Code System.

Note: We require the health IT developers to demonstrate support for the tests above for both responses to requests for a single patient’s data and responses to requests for multiple patients’ data because we make no assumption regarding the re-use of technical infrastructure for “read” services for single and multiple patients in Health IT Modules.

Response to Requests for a Single Patient’s Data

  1. DAT-PAT-7: The health IT developer demonstrates the ability of the Health IT Module to return all of the data associated with requests for a single patient’s data according to the “US Core Server CapabilityStatement” section of the implementation specification adopted in § 170.215(a)(2) for all the data included in the standard adopted in § 170.213.

Response to Requests for Multiple Patients’ Data

  1. DAT-PAT-8: The health IT developer demonstrates the ability of the Health IT Module to respond to requests for multiple patients’ data according to the implementation specification adopted in § 170.215(a)(4) for all of the FHIR® resources associated with the profiles and Data Elements specified in and according to the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2).:
    • “AllergyIntolerance”;
    • “CarePlan”;
    • “CareTeam”;
    • “Condition”;
    • “Device”;
    • “DiagnosticReport”;
    • “DocumentReference”;
    • “Encounter”;
    • “Goal”;
    • “Immunization”;
    • “Location” (if supported);
    • “Medication” (if supported);
    • “MedicationRequest”;
    • “Observation”;
    • “Organization”;
    • “Patient”;
    • “Practitioner”
    • “Procedure”; and
    • “Provenance”.
  2. DAT-PAT-9: The health IT developer demonstrates the ability of the Health IT Module to limit the data returned to only those FHIR® resources for which the client is authorized according to the implementation specification adopted in § 170.215(a)(4).
  3. DAT-PAT-10: The health IT developer demonstrates the ability of the Health IT Module to support a successful data response according to the implementation adopted in § 170.215(a)(4).
  4. DAT-PAT-11: The health IT developer demonstrates the ability of the Health IT Module to support a data response error according to the implementation adopted in § 170.215(a)(4).
  5. DAT-PAT-12: The health IT developer demonstrates the ability of the Health IT Module to support a bulk data delete request according to the implementation specification adopted in § 170.215(a)(4).
  6. DAT-PAT-13: The health IT developer demonstrates the ability of the Health IT Module to support a bulk data status request according to the implementation specification adopted in § 170.215(a)(4).
  7. DAT-PAT-14: The health IT developer demonstrates the ability of the Health IT Module to support a file request according to the implementation specification adopted in § 170.215(a)(4), including support for the “ndjson” format for files provided.
  8. DAT-PAT-15: The health IT developer demonstrates that the information provided as part of this data response includes data for patients in the group identifier provided during the “group-export” request.

 

SVAP Version Approved: USCDI v2 + US Core STU v5.0.1

Data Response Checks for Single and Multiple Patients

  1. DAT-PAT-1: For responses to data for single and multiple patients as described in steps DAT-PAT-7, and DAT-PAT-8, of this section respectively, the health IT developer demonstrates the ability of the Health IT Module to respond to requests for data according to the implementation specification adopted in § 170.215(a)(2), including the following steps.
  2. DAT-PAT-2: The health IT developer demonstrates the ability of the Health IT Module to respond with data that meet the following conditions:
    • All data elements indicated with a cardinality of one or greater and / or “must support” are included;
    • Content is structurally correct;
    • All invariant rules are met;
    • All data elements with required “ValueSet” bindings contain codes within the bound “ValueSet”;
    • All information is accurate and without omission; and
    • All references within the resources can be resolved and validated, as applicable, according to steps DAT-PAT-2, DAT-PAT-3, DAT-PAT-4, DAT-PAT-5, and DAT-PAT-6, of this section.
  3. DAT-PAT-3: The health IT developer demonstrates the ability of the Health IT Module to support a “Provenance” FHIR® resource for all the FHIR® resources included in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2) according to the “Basic Provenance Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  4. DAT-PAT-4: The health IT developer demonstrates the ability of the Health IT Module to support a “DocumentReference” and/or “DiagnosticReport” FHIR® resource for each of the “Clinical Notes” and “Diagnostic Reports” included in and according to the “Clinical Notes Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  5. DAT-PAT-5: If supported, and for responses to data for a single patient only, the health IT developer demonstrates the ability of the Health IT Module to support a “Medication” FHIR® resource according to the “Medication List Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  6. DAT-PAT-6: The health IT developer demonstrates the ability of the Health IT Module to support “Missing Data” according to the implementation specification adopted in § 170. 215(a)(2), including:
    • For non-coded data elements; and
    • For coded data elements, including support for the “DataAbsentReason” Code System.

Note: We require the health IT developers to demonstrate support for the tests above for both responses to requests for a single patient’s data and responses to requests for multiple patients’ data because we make no assumption regarding the re-use of technical infrastructure for “read” services for single and multiple patients in Health IT Modules.

Response to Requests for Single Patients’ Data

  1. DAT-PAT-7: The health IT developer demonstrates the ability of the Health IT Module to return all of the data associated with requests for a single patient’s data according to the “US Core Server CapabilityStatement” section of the implementation specification adopted in § 170.215(a)(2) for all the data included in the standard adopted in § 170.213.

Response to Requests for Multiple Patients’ Data

  1. DAT-PAT-16: The health IT developer demonstrates the ability of the Health IT Module to respond to requests for multiple patients’ data according to the implementation specification adopted in § 170.215(a)(4) for all of the FHIR® resources associated with the profiles and Data Elements specified in and according to the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2).
    • “AllergyIntolerance”;
    • “CarePlan”;
    • “CareTeam”;
    • “Condition”;
    • “Device”;
    • “DiagnosticReport”;
    • “DocumentReference”;
    • “Encounter”;
    • “Goal”;
    • “Immunization”;
    • “Location” (if supported);
    • “Medication” (if supported);
    • “MedicationRequest”;
    • “Observation”;
    • “Organization”;
    • “Patient”;
    • “Practitioner”
    • “Procedure”; and
    • “Provenance”.
    • “PractitionerRole” (if supported);
    • “QuestionnaireReponse” (if supported);
    • “RelatedPerson”; and
    • “ServiceRequest”
  2. DAT-PAT-9: The health IT developer demonstrates the ability of the Health IT Module to limit the data returned to only those FHIR® resources for which the client is authorized according to the implementation specification adopted in § 170.215(a)(4).
  3. DAT-PAT-10: The health IT developer demonstrates the ability of the Health IT Module to support a successful data response according to the implementation adopted in § 170.215(a)(4).
  4. DAT-PAT-11: The health IT developer demonstrates the ability of the Health IT Module to support a data response error according to the implementation adopted in § 170.215(a)(4).
  5. DAT-PAT-12: The health IT developer demonstrates the ability of the Health IT Module to support a bulk data delete request according to the implementation specification adopted in § 170.215(a)(4).
  6. DAT-PAT-13: The health IT developer demonstrates the ability of the Health IT Module to support a bulk data status request according to the implementation specification adopted in § 170.215(a)(4).
  7. DAT-PAT-14: The health IT developer demonstrates the ability of the Health IT Module to support a file request according to the implementation specification adopted in § 170.215(a)(4), including support for the “ndjson” format for files provided.
  8. DAT-PAT-15: The health IT developer demonstrates that the information provided as part of this data response includes data for patients in the group identifier provided during the “group-export” request.
Applies to Regulatory Standard (USCDI v1 + US Core STU v3.1.1) and SVAP Version Approved (USCDI v1 + US Core STU v4.0.0)

Data Response Checks for Single and Multiple Patients

  1. DAT-PAT-1: For responses to data for single and multiple patients as described in steps DAT-PAT-7, and DAT-PAT-8, of this section respectively, the tester verifies the ability of the Health IT Module to respond to requests for data according to the implementation specification adopted in § 170.215(a)(2), including the following steps.
  2. DAT-PAT-2: The tester verifies the ability of the Health IT Module to respond with data that meet the following conditions:
    • All data elements indicated with a cardinality of one or greater and / or “must support” are included;
    • Content is structurally correct;
    • All invariant rules are met;
    • All data elements with required “ValueSet” bindings contain codes within the bound “ValueSet”;
    • All information is accurate and without omission; and
    • All references within the resources can be resolved and validated, as applicable, according to steps  DAT-PAT-2, DAT-PAT-3, DAT-PAT-4, DAT-PAT-5, and DAT-PAT-6, of this section.
  3. DAT-PAT-3: The tester verifies the ability of the Health IT Module to support a “Provenance” FHIR® resource for all the FHIR® resources included in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2) according to the “Basic Provenance Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  4. DAT-PAT-4: The tester verifies the ability of the Health IT Module to support a “DocumentReference” and/or “DiagnosticReport” FHIR® resource for each of the “Clinical Notes” and “Diagnostic Reports” included in and according to the “Clinical Notes Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  5. DAT-PAT-5: If supported, and for responses to data for a single patient only, the tester verifies the ability of the Health IT Module to support a “Medication” FHIR® resource according to the “Medication List Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  6. DAT-PAT-6: The tester verifies the ability of the Health IT Module to support “Missing Data” according to the implementation specification adopted in § 170. 215(a)(2), including:
    • For non-coded data elements; and
    • For coded data elements, including support for the “DataAbsentReason” Code System.

Note: We require the tester to verify support for the tests above for both responses to requests for a single patient’s data and responses to requests for multiple patients’ data because we make no assumption regarding the re-use of technical infrastructure for “read” services for single and multiple patients in Health IT Modules.

Response to Requests for a Single Patient’s Data

  1. DAT-PAT-7: The tester verifies the ability of the Health IT Module to return all of the data associated with requests for a single patient’s data according to the “US Core Server CapabilityStatement” section of the implementation specification adopted in § 170.215(a)(2) for all the data included in the standard adopted in § 170.213.

Response to Requests for Multiple Patients’ Data

  1. DAT-PAT-8: The tester verifies the ability of the Health IT Module to respond to requests for multiple patients’ data according to the implementation specification adopted in § 170.215(a)(4) for all of the FHIR® resources associated with the profiles and Data Elements specified in and according to the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2).
    • “AllergyIntolerance”;
    • “CarePlan”;
    • “CareTeam”;
    • “Condition”;
    • “Device”;
    • “DiagnosticReport”;
    • “DocumentReference”;
    • “Encounter”;
    • “Goal”;
    • “Immunization”;
    • “Location” (if supported);
    • “Medication” (if supported);
    • “MedicationRequest”;
    • “Observation”;
    • “Organization”;
    • “Patient”;
    • “Practitioner”
    • “Procedure”; and
    • “Provenance”.
  2. DAT-PAT-9: The tester verifies the ability of the Health IT Module to limit the data returned to only those FHIR® resources for which the client is authorized according to the implementation specification adopted in § 170.215(a)(4).
  3. DAT-PAT-10: The tester verifies the ability of the Health IT Module to support a successful data response according to the implementation adopted in § 170.215(a)(4).
  4. DAT-PAT-11: The tester verifies the ability of the Health IT Module to support a data response error according to the implementation adopted in § 170.215(a)(4).
  5. DAT-PAT-12: The tester verifies the ability of the Health IT Module to support a bulk data delete request according to the implementation specification adopted in § 170.215(a)(4).
  6. DAT-PAT-13: The tester verifies the ability of the Health IT Module to support a bulk data status request according to the implementation specification adopted in § 170.215(a)(4).
  7. DAT-PAT-14: The tester verifies the ability of the Health IT Module to support a file request according to the implementation specification adopted in § 170.215(a)(4), including support for the “ndjson” format for files provided.
  8. DAT-PAT-15: The tester verifies the information provided as part of this data response includes data for patients in the group identifier provided during the “group-export” request.
SVAP Version Approved: USCDI v2 + US Core STU v5.0.1

Data Response Checks for Single and Multiple Patients

  1. DAT-PAT-1: For responses to data for single and multiple patients as described in steps DAT-PAT-7, and DAT-PAT-8, of this section respectively, the tester verifies the ability of the Health IT Module to respond to requests for data according to the implementation specification adopted in § 170.215(a)(2), including the following steps.
  2. DAT-PAT-2: The tester verifies the ability of the Health IT Module to respond with data that meet the following conditions:
    • All data elements indicated with a cardinality of one or greater and / or “must support” are included;
    • Content is structurally correct;
    • All invariant rules are met;
    • All data elements with required “ValueSet” bindings contain codes within the bound “ValueSet”;
    • All information is accurate and without omission; and
    • All references within the resources can be resolved and validated, as applicable, according to steps DAT-PAT-2, DAT-PAT-3, DAT-PAT-4, DAT-PAT-5, and DAT-PAT-6, of this section.
  3. DAT-PAT-3: The tester verifies the ability of the Health IT Module to support a “Provenance” FHIR® resource for all the FHIR® resources included in the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2) according to the “Basic Provenance Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  4. DAT-PAT-4: The tester verifies the ability of the Health IT Module to support a “DocumentReference” and/or “DiagnosticReport” FHIR® resource for each of the “Clinical Notes” and “Diagnostic Reports” included in and according to the “Clinical Notes Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  5. DAT-PAT-5: If supported, and for responses to data for a single patient only, the tester verifies the ability of the Health IT Module to support a “Medication” FHIR® resource according to the “Medication List Guidance” section of the implementation specification adopted in § 170.215(a)(2).
  6. DAT-PAT-6: The tester verifies the ability of the Health IT Module to support “Missing Data” according to the implementation specification adopted in § 170. 215(a)(2), including:
    • For non-coded data elements; and
    • For coded data elements, including support for the “DataAbsentReason” Code System.

Note: We require the health IT developers to demonstrate support for the tests above for both responses to requests for a single patient’s data and responses to requests for multiple patients’ data because we make no assumption regarding the re-use of technical infrastructure for “read” services for single and multiple patients in Health IT Modules.

Response to Requests for Single Patients’ Data

  1. DAT-PAT-7: The tester verifies the ability of the Health IT Module to return all of the data associated with requests for a single patient’s data according to the “US Core Server CapabilityStatement” section of the implementation specification adopted in § 170.215(a)(2) for all the data included in the standard adopted in § 170.213.

Response to Requests for Multiple Patients’ Data

  1. DAT-PAT-16: The health IT developer verifies the ability of the Health IT Module to respond to requests for multiple patients’ data according to the implementation specification adopted in § 170.215(a)(4) for all of the FHIR® resources associated with the profiles and Data Elements specified in and according to the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2).
    • “AllergyIntolerance”;
    • “CarePlan”;
    • “CareTeam”;
    • “Condition”;
    • “Device”;
    • “DiagnosticReport”;
    • “DocumentReference”;
    • “Encounter”;
    • “Goal”;
    • “Immunization”;
    • “Location” (if supported);
    • “Medication” (if supported);
    • “MedicationRequest”;
    • “Observation”;
    • “Organization”;
    • “Patient”;
    • “Practitioner”
    • “Procedure”; and
    • “Provenance”.
    • “PractitionerRole” (if supported);
    • “QuestionnaireReponse” (if supported);
    • “RelatedPerson”; and
    • “ServiceRequest”
  2. DAT-PAT-9: The tester verifies the ability of the Health IT Module to limit the data returned to only those FHIR® resources for which the client is authorized according to the implementation specification adopted in § 170.215(a)(4).
  3. DAT-PAT-10: The tester verifies the ability of the Health IT Module to support a successful data response according to the implementation adopted in § 170.215(a)(4).
  4. DAT-PAT-11: The tester verifies the ability of the Health IT Module to support a data response error according to the implementation adopted in § 170.215(a)(4).
  5. DAT-PAT-12: The tester verifies the ability of the Health IT Module to support a bulk data delete request according to the implementation specification adopted in § 170.215(a)(4).
  6. DAT-PAT-13: The tester verifies the ability of the Health IT Module to support a bulk data status request according to the implementation specification adopted in § 170.215(a)(4).
  7. DAT-PAT-14: The tester verifies the ability of the Health IT Module to support a file request according to the implementation specification adopted in § 170.215(a)(4), including support for the “ndjson” format for files provided.
  8. DAT-PAT-15: The tester verifies the information provided as part of this data response includes data for patients in the group identifier provided during the “group-export” request.

System Under Test Test Lab Verification

Certification Option: Applies to all applicable base regulatory and SVAP standards

API Documentation Requirements

  1. API-DOC-1: The health IT developer supplies documentation describing the API(s) of the Health IT Module and includes at a minimum:
    • API syntax;
    • Function names;
    • Required and optional parameters supported and their data types;
    • Return variables and their types/structures;
    • Exceptions and exception handling methods and their returns;
    • Mandatory software components;
    • Mandatory software configurations; and
    • All technical requirements and attributes necessary for registration.
  2. API-DOC-2: The health IT developer demonstrates that the documentation described in step 1, of this section is available via a publicly accessible hyperlink that does not require preconditions or additional steps to access.
  3. API-DOC-3: To fulfill the API Maintenance of Certification requirement at § 170.404(b)(2), the health IT developer demonstrates the public location of its certified API technology service base URLs. 

Certification Option: Applies to all applicable base regulatory and SVAP standards

API Documentation Requirements

  1. API-DOC-1: The tester verifies that the documentation supplied by the health IT developer describing the API(s) of the Health IT Module includes at a minimum:
    • API syntax;
    • Function names;
    • Required and optional parameters supported and their data types;
    • Return variables and their types/structures;
    • Exceptions and exception handling methods and their returns;
    • Mandatory software components;
    • Mandatory software configurations; and
    • All technical requirements and attributes necessary for registration.
  2. API-DOC-2: The tester verifies the documentation described in step 1, of this section is available via a publicly accessible hyperlink that does not require preconditions or additional steps to access.
  3. API-DOC-3: To fulfill the API Maintenance of Certification requirement at § 170.404(b)(2), the tester verifies the public location of the health IT developer's certified API technology service base URLs. 

Alternative Test Method

Summary Alternative Test Method File Test Tool Updated On

The Drummond Group’s standardized API test suite was developed by AEGIS.net and the Drummond Group and is part of the Touchstone global testing platform. The Drummond G10+ FHIR® API powered by Touchstone tool supports testing implementations focused on interoperability standards such as HL7® FHIR® and beyond. The Drummond G10+ FHIR® API powered by Touchstone tool was approved as an ONC-approved Alternative Test Method on May 3, 2022, for testing § 170.315(g)(10).

Drummond G10+ FHIR® API powered by Touchstone tool

The ONC-approved alternative, Drummond G10+ FHIR® API powered by Touchstone tool, has its own set of testing artifacts. For additional information contact Drummond Group.

Updated on 08-29-2022
Resource Documents
Revision History
Version # Description of Change Version Date
1.0

Initial Publication

06-15-2020
1.1

Amended text to remove pronoun "we," added clarifications based on gaps between United States Core Data for Interoperability (USCDI) and US Core Implementation Guide (IG), clarified "must support" references, removed requirement for patient facing scopes based on US Core IG "must support" references, added clarification for "Encounter," added clarification for launch scenarios included in testing and certification, added clarification regarding US Core IG LOINC code for testing and certification. 

08-07-2020
1.2

Updated compliance date, regulatory text, and standard for trial use (STU) 3 Release 3.1.1 at § 170.215(2), per the Interim Final Rule (IFR), Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health EmergencyAdded clarification for USCDI / US Core IG Provenance.  Added clarification for US Core IG “must support” elements with multiple Choices and References.

11-02-2020
1.3

Updated clarifications based on adoption of US Core IG 3.1.1, which include removing USCDI "allergy intolerance," USCDI "head circumference," and US Core IG "RelatedPerson" and "PractitionerRole" clarifications. Addressed typo in 170.315 (g)(10)(vii) by removing duplicative test "is not supported."

12-16-2020
1.4

Added clarification regarding the standardized API conformance expectations of legacy information for the ONC Health IT Certification Program. Added clarification regarding the handling of SMART IG patient/[resource] and user[resource] scopes and US Core IG resources. Added clarification about refresh token support for native applications. Finally, added clarification regarding the SMART IG "permission-offline" SMART on FHIR® Core Capability. 

04-02-2021
1.5

Added clarification regarding refresh token support for native applications and  SMART Application Launch Framework Implementation Guide Release 1.0.0 standard (incorporated by reference at § 170.215(a)(3))

05-13-2021
1.6

Fixed broken links to “Basic Provenance Guidance” section of the US Core IG.

06-10-2021
1.7

Added paragraph adopting “FHIR® Bulk Data Access (Flat FHIR®) (v1.0.1: STU 1)” in ONC Certification Program, which includes technical errata for “FHIR® Bulk Data Access (Flat FHIR®) (v1.0.0: STU 1)”.

07-27-2021
1.8

Added clarifications regarding:

  • standardized API conformance expectations for certain "dataAbsentReason" elements in the US Core IG.
  • use of an access token in accordance with the "SMART Backend Services: Authorization Guide."
  • standardized API conformance expectations for "read" and "write" services. 
11-03-2021
1.9

Added clarification regarding authorization revocation of access tokens.

12-22-2021
2.0

Added clarifications regarding:

  • Use of Proof Key Code Exchange (PKCE) for Authentication and Authorization.
  • Revised clarification regarding support for access control schemes besides OAuth 2.0 for Bulk Data Access file servers.
02-18-2022
2.1

Revised and added a clarification regarding enforcement of TLS for the requirements at Paragraph (g)(10)(iv) “Secure connection.”

08-16-2022
2.2

Updated to include the Standards Version Advancement Process (SVAP) Version(s) Approved

08-29-2022
Regulation Text
Regulation Text

§ 170.315(g)(10) Standardized API for patient and population services

The following technical outcomes and conditions must be met through the demonstration of application programming interface technology.

  1. Data response.
    1. Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.
    2. Respond to requests for multiple patients’ data as a group according to the standard adopted in § 170.215(a)(1) and implementation specifications adopted at § 170.215(a)(2) and (a)(4), for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.
  2. Supported search operations.
    1. Respond to search requests for a single patient’s data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(2), specifically the mandatory capabilities described in “US Core Server CapabilityStatement”.
    2. Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(4).
  3. Application registration. Enable an application to register with the Health IT Module’s “authorization server.”
  4. Secure connection.
    1. Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(a)(2) and (3).
    2. Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(a)(4).
  5. Authentication and authorization.
    1. Authentication and authorization for patient and user scopes.
      1. First time connections.
        1. Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b).
        2.  A Health IT Module’s authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret. 
        3. A Health IT Module’s authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token. 
      2. Subsequent connections.
        1. Access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application.
        2. A Health IT Module’s authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret. 
    2. Authentication and authorization for system scopes. Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token.
  6. Patient authorization revocation. A Health IT Module’s authorization server must be able to revoke an authorized application’s access at a patient’s direction.
  7. Token introspection. A Health IT Module’s authorization server must be able to receive and validate tokens it has issued.
  8. Documentation.
    1. The API(s) must include complete accompanying documentation that contains, at a minimum:
      1. API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.
      2.  The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).
      3. All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module’s authorization server.
    2. The documentation used to meet paragraph (g)(10)(viii)(A) of this section must be available via a publicly accessible hyperlink without any preconditions or additional steps.
Standard(s) Referenced

Paragraph (g)(10)(i)(A)

§ 170.215(a)(1) Health Level 7 (HL7®) Version 4.0.1 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, October 30, 2019

§ 170.215(a)(2) FHIR® US Core Implementation Guide STU V3.1.1

§ 170.213 United States Core Data for Interoperability (USCDI)

Paragraph (g)(10)(i)(B)

§ 170.215(a)(1) HL7® Version 4.0.1 FHIR® Release 4, October 30, 2019

§ 170.215(a)(2) FHIR® US Core Implementation Guide STU V3.1.1

§ 170.213 USCDI

§ 170.215(a)(4) HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1)

Paragraph (g)(10)(ii)(A)

§ 170.215(a)(2) FHIR® US Core Implementation Guide STU V3.1.1

Paragraph (g)(10)(ii)(B)

§ 170.215(a)(4) HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1)

Paragraph (g)(10)(iii)

None

Paragraph (g)(10)(iv)(A)

§ 170.215(a)(2) FHIR® US Core Implementation Guide STU V3.1.1

§ 170.215(a)(3) HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0

Paragraph (g)(10)(iv)(B)

§ 170.215(a)(4) HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1)

Paragraph (g)(10)(v)(A)(1)

§ 170.215(a)(3) HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0

§ 170.215(b) OpenID Connect Core 1.0 incorporating errata set 1

Paragraph (g)(10)(v)(A)(2)

§ 170.215(a)(3) HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0

Paragraph (g)(10)(v)(B)

§ 170.215(a)(4) HL7® FHIR® Bulk Data Access (Flat FHIR®) (V1.0.1:STU 1)

Paragraph (g)(10)(vi)

None

Paragraph (g)(10)(vii)

None

Paragraph (g)(10)(viii)

None

 

Standards Version Advancement Process (SVAP) Version(s) Approved

United States Core Data for Interoperability (USCDI), Version 2, July 2021

HL7® FHIR® US Core Implementation Guide STU 4.0.0, June 2021

HL7® FHIR® US Core Implementation Guide STU 5.0.1, June 2022 

HL7® FHIR® SMART Application Launch Framework Implementation Guide Release 2.0.0, November 26, 2021

HL7® FHIR® Bulk Data Access (Flat FHIR®) (v2.0.0: STU 2), November 26, 2021

Testing

Certification Companion Guide: Standardized API for patient and population services

This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product development. The CCG is not a substitute for the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule (ONC Cures Act Final Rule). It includes extracts of preamble and regulation text from the ONC Cures Act Final Rule with accompanying clarifying interpretations. To access the full context of regulatory intent please consult the ONC Cures Act Final Rule or other included regulatory reference. This CCG is for public use and should not be sold or redistributed.

 

 

Certification Requirements

Privacy and Security: This certification criterion was adopted in § 170.315(g)(10). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to this criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be tested once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification.

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, when different QMS are used, each QMS needs to be separately identified for every capability to which it was applied.
  • When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Table for Privacy and Security
Technical Explanations and Clarifications

 

Applies to Entire Criterion

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • On December 31, 2022, the Application Programming Interface (API) certification criterion in § 170.315(g)(10) replaces the “Application access—data category request” certification criterion (§ 170.315(g)(8)).
  • Health IT Modules are not required to support patient-facing API-enabled “read” services for multiple patients for the purposes of this certification criterion.
  • The clinical note text included in any of the notes described in the “Clinical Notes Guidance” section of the US Core Implementation Guide (IG) adopted in § 170.215(a)(2) must be represented in a “plain text” form, and it would be unacceptable for the note text to be converted to another file or format (e.g., .docx, PDF) when it is provided as part of an API response. The intent of this policy is to prohibit Health IT Modules from converting clinical notes from a “machine readable” format to a non-“machine readable” format (e.g., PDF). Clinical note text that originates from outside Health IT Modules should be exchanged using its original format. Additionally, “plain text” does not necessarily mean the FHIR® “contentType” “text/plain.”
  • The US Core IG Profile “StructureDefinition-us-core-patient” element “name.suffix” is required for testing and certification in the Certification Program to meet the USCDI requirement to support the “Patient Demographics” Data Class: “Suffix” Data Element.
  • A Health IT Module must support at least one Choice or Reference for US Core IG “must support” elements with multiple Choices or References, respectively. 
  • A Health IT Module must be conformant to the US Core IG for all Choices and References included in its standardized API, and cannot misrepresent Choices via the standardized API (e.g. a Health IT Module cannot transform “integer” values to “string” values). 
  • A health IT developer must document which US Core IG Choices and References are supported by their Health IT Module via public technical documentation to meet the requirements at § 170.315(g)(10)(viii) and the transparency conditions at § 170.404(a)(2). 
  • Information originating from the (g)(10)-certified Health IT Module must conform to the requirements included in the criterion, but legacy information and information from outside systems is not required to be mapped to the USCDI “Applicable Standards” and the US Core IG terminologies and value sets. However, health IT developers are encouraged to exceed the minimum requirements described in § 170.315(g)(10) to support the mapping of legacy information to the terminologies and value sets included in the USCDI and US Core IG where possible.
  • In order to mitigate potential interoperability errors and inconsistent implementation of the Fast Healthcare Interoperability Resources (FHIR®) Bulk Data Access (Flat FHIR®) (v1.0.0: STU 1) standard, ONC assesses, approves, and incorporates corrections (errata) as part of required certification and testing to this criterion. Compliance with the following errata is necessary because the errata implements technical corrections and clarifications to the FHIR® Bulk Data Access (Flat FHIR) (v1.0.0: STU 1) standard. There is a 90-day delay from the time the CCG has been updated with the ONC-approved errata to when compliance with the errata will be required to pass testing. Similarly, there will be an 18-month delay before a finding of an erratum’s absence in a Certified Health IT Module during surveillance would constitute a non-conformity under the Certification Program.
  • Version: FHIR® Bulk Data Access (Flat FHIR®) (v1.0.1: STU 1). Effective for testing on October 25, 2021. Surveillance compliance date on January 27, 2023.

Applies to base regulatory standard USCDI v1 and US Core 3.1.1 or USCDI v1 and SVAP approved standard US Core 4.0.0:

  • The US Core IG Profile “StructureDefinition-us-core-patient” element “name.period” is required for testing and certification in the ONC Certification Program to meet the USCDI requirement to support the “Patient Demographics” data class: “Previous Name” data element.

Applies to SVAP approved standard US Core 5.0.1 and USCDI v2:

  • The US Core IG Profiles “StructureDefinition-us-core-patient” elements “name.use” and “name.period” are required for testing and certification in the ONC Certification Program to meet the USCDI requirement to support the “Patient Demographics” data class: “Previous Name” data element.
  • The US Core IG Profiles “StructureDefinition-us-core-patient” element “patient.address.use” and “patient.address.period” are required for testing and certification in the ONC Certification Program to meet the USCDI requirement to support the “Patient Demographics” data class: “Previous Address” data element.

 

Paragraph (g)(10)(i)(A)

Technical outcome – Respond to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • All data elements and operations indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported and are in-scope for testing.
  • Health IT Modules must support provenance according to the “Basic Provenance Guidance” section of the US Core IG.
  • For purposes of ONC Health IT Certification, health IT developers that always provide HL7® FHIR® “observation” values are not required to demonstrate Health IT Module support for “dataAbsentReason” elements. These include “dataAbsentReason” elements contained in the US Core implementation guide profiles and FHIR® Vital Sign profiles that build on the HL7® FHIR® “observation” and its derived profiles including HL7® FHIR® “observation-vitalsigns”, and HL7® FHIR® “observation-oxygensat”, including “component.dataAbsentReason” elements. However, health IT developers are still required to adhere to and demonstrate Health IT Module support for the “Missing Data” section of the US Core implementation guide.

Applies to base regulatory standard US Core 3.1.1 and SVAP approved standard US Core 4.0.0:

  • For “Encounter,” “Organization,” and “Practitioner,” US Core IG profiles, only the “read” type interaction must be supported and will be included in testing and certification. For the “Location” FHIR® resource, Health IT Modules must either demonstrate support for the “read” type interaction or demonstrate support for providing the “Location” and FHIR® resource references as a contained resource. The “search” type interactions for these profiles and resource are not in scope for testing and certification. Health IT Modules must support these US Core IG profiles / FHIR® resource because they are included as “must support” data elements in US Core IG profiles required by the USCDI.
  • Health IT Modules must support provenance according to the “Basic Provenance Guidance” section of the US Core IG. 

Applies to SVAP approved standard US Core 5.0.0 and USCDI v3:

  • For the “Organization” US Core IG profile, only the “read” type interaction must be supported and will be included in testing and certification. For the “Location” FHIR® resource, Health IT Modules must either demonstrate support for the “read” type interaction or demonstrate support for providing the “Location” FHIR® resource reference as a contained resource. The “search” type interactions for these profiles and resource are not in scope for testing and certification. Health IT Modules must support these US Core IG profiles / FHIR® resource because they are included as “must support” data elements in US Core IG profiles required by the United States Core Data for Interoperability (USCDI).

 

Paragraph (g)(10)(i)(B)

Technical outcome – Respond to requests for multiple patients’ data as a group according to the standard adopted in § 170.215(a)(1), and implementation specifications adopted in § 170.215(a)(2) and (4), for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • Health IT Modules may support scopes using either the system wildcard scope syntax or a list of system resource scopes, to enable the export of multiple patients’ data as a group.
  • During testing and certification for multiple patient services, Health IT Modules must demonstrate support for “Encounter,” “Organization,” and “Practitioner” US Core IG FHIR® Profiles. 
  • Health IT Modules must demonstrate support for “Location” FHIR® resources by providing this resource as part of the multiple patient services response, or by including it as a contained resource as part of the multiple patient services response.
  • Health IT Modules must support provenance according to the “Basic Provenance Guidance” section of the US Core IG.

 

Paragraph (g)(10)(ii)(A)

Technical outcome – Respond to search requests for a single patient’s data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(2), specifically the mandatory capabilities described in “US Core Server CapabilityStatement”.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported and are in scope for testing.
  • The § 170.315(g)(10) certification criterion requires Health IT Modules to support API-enabled “read” services for single and multiple patients. “Read” services include those that allow authenticated and authorized third-party applications to view EHI through a secure API. These services specifically exclude “write” capabilities, where authenticated and authorized third-party applications would be able to create or modify EHI through a secure API.

 

Paragraph (g)(10)(ii)(B)

Technical outcome – Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(4).

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • No additional clarifications.

 

Paragraph (g)(10)(iii)

Technical outcome – Enable an application to register with the Health IT Module’s “authorization server.”

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • Health IT presented for testing and certification must support app registration regardless of the scope of patient search utilized by the application (e.g. single or multiple).
  • This certification criterion requires a health IT developer, as finalized in the Condition of Certification requirements, to demonstrate its registration process, but does not require conformance to a standard.
  • The third-party application registration process that a health IT developer must meet under this criterion is not a form of review or “vetting” for purposes of this criterion.

Applies to base regulatory standard US Core 3.1.1 and SVAP approved standard US Core 4.0.0:

  • For demonstration of the SMART IG "Standalone Launch" steps, health IT developers are permitted to scope US Core IG resources that do not exist in either the standard adopted at § 170.213 (USCDI version 1) or the "Compartment Patient" section of the standard adopted at § 170.215(a)(1) (HL7® FHIR® Release 4.0.1) as either patient/[Resource] or user/[Resource]. These resources include “Encounter,” “Device,” “Location,” “Medication,” “Organization,” “Practitioner,” and “PractitionerRole.” Health IT developers must document their supported scopes according to the technical documentation requirements at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2).

Applies to SVAP approved standard US Core 5.0.1 and USCDI v2:

  • For demonstration of the SMART IG “Standalone Launch” steps, health IT developers are permitted to scope US Core IG resources that do not exist in either the standard adopted at § 170.213 (USCDI version 2) or the “Compartment Patient” section of the standard adopted at § 170.215(a)(1) (HL7® FHIR® Release 4.0.1) as either patient/[Resource] or user/[Resource]. These resources include “Device,” “Location,” “Medication,” “Organization,” “Practitioner,” and “PractitionerRole.” Health IT developers must document their supported scopes according to the technical documentation requirements at § 170.315(g)(10)(viii)(A) and § 170.404(a)(2).

 

Paragraph (g)(10)(iv)

 

Technical outcome - (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(a)(2) and (3). (B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(a)(4).

Clarifications:

Applies to all applicable base regulatory and SVAP standards:


 

Paragraph (g)(10)(v)(A)(1)

Technical outcome – For first time connections, authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b). Additionally, a Health IT Module's authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret. Finally, a Health IT Module's authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • Health IT Modules will be explicitly tested for US Core IG operations using authentication and authorization tokens acquired via the process described in the implementation specification adopted in § 170.215(a)(3).
  • Only the relevant parts of the OpenID Connect Core 1.0 including errata set 1 adopted in § 170.215(b) that are also included in the implementation specification adopted in § 170.215(a)(3) will be in-scope for testing and certification. 
  • As part of the “permission-patient” “SMART on FHIR® Core Capability” in § 170.215(a)(3), Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their electronic health information (EHI) based on FHIR® resource-level scopes. Specifically, this means patients would need to have the ability to authorize access to their EHI at the individual FHIR® resource level, from one specific FHIR® resource (e.g., “Immunization”) up to all FHIR® resources necessary to implement the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2).
  • Although Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their EHI based on FHIR® resource-level scopes, Health IT Modules are not prohibited from presenting authorization scopes in a more user-friendly format (e.g. grouping resources under categories, renaming the scopes for easier comprehension by the end-user, using more granular scopes), as long as the ability for patients to authorize applications based on resource-level scopes is available, if requested by the patient.
  • Health IT Modules will only be tested for the "Patient Access for Standalone Apps" and "Clinician Access for EHR Launch" "Capability Sets”described in the standard adopted at § 170.215(a)(3).
  • Since the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” “Capability Sets” do not include “context-standalone-encounter" ONC will not test Health IT Modules for support for the "context-standalone-encounter" SMART on FHIR® Capability described in the standard adopted at § 170.215(a)(3).
  • Implementers of § 170.315(g)(10)-certified Health IT Modules should be mindful of the information blocking provisions.
  • As part of the requirements at § 170.315(g)(10)(v)(A)(1)(iii), health IT developers must publish the method(s) by which their Health IT Modules support the secure issuance of an initial refresh token to native applications according to the technical documentation requirements at § 170.315(g)(10)(viii) and transparency conditions at § 170.404(a)(2). [see also ONC Clarifications in the Interim Final Rule to Support Native Applications]
  • Application developer affirmations to health IT developers regarding the ability of their applications to secure a refresh token, a client secret, or both, must be treated in a good faith manner consistent with the provisions established in the openness and pro-competitive conditions at § 170.404(a)(4). 
  • Health IT developers can determine the method(s) they use to support interactions with native applications and clarify that health IT developers are not required to support all methods third-party application developers seek to use. 
  • ONC recognizes there may be some ambiguity in the HL7® SMART Application Launch Framework Implementation Guide (incorporated by reference at § 170.215(a)(3)) in its guidance for supporting native applications, in particular, in providing references to best practices, strategies, and examples such as “OAuth 2.0 for Native Apps: 8.5. Client Authentication”, “OAuth 2.0 Dynamic Client Registration Protocol”, and “universal redirect_uris” without a standardized solution. ONC provides flexibility for how the health IT developer implements the HL7® SMART Application Launch Framework implementation specification, as long as the Certified Health IT Module supports for first time connections the issuance of three-month refresh tokens to native applications capable of securing a refresh token.
  • The paragraph at § 170.215(a)(3) requires health IT developers to support the SMART Application Launch Framework Implementation Guide (SMART IG) “SMART [on FHIR®] Core Capabilities,” including “permission-offline,” which grants support for refresh tokens. The ONC Cures Act Final Rule states, “…Importantly, the implementation specification adopted in § 170.215(a)(3) requires that patients have the ability to explicitly enable the “offline_access” scope during authorization. If the “offline_access” scope is not enabled by patients, patients will be required to re-authenticate and re-authorize an application's access to their EHI after the application's access token expires…” (85 FR 25747). However, the ability of a patient to explicitly enable the “offline_access” scope during authorization is not described in the implementation specification. ONC clarifies that health IT developers must support the ability for patients to be provided information about an application’s request for persistent access prior to the patient sharing their health information, in order to enable patients to make an informed decision during authorization. Examples include, but are not limited to a health IT developer allowing patients to granularly grant “offline-access” scopes during authorization or clearly providing this information as a notice during authorization. The critical requirement is that patients are empowered to deny authorization for offline access.

Applies to base regulatory standard US Core 3.1.1 and SVAP approved standard US Core 4.0.0:

  • Since "Encounter" is not a USCDI v1 data class or data element, ONC will not test Health IT Modules for support for "context-ehr-encounter" SMART on FHIR® Core Capabilities described in the standard adopted at § 170.215(a)(3).

Applies to base regulatory standard SMART App Launch Framework 1.0.0:

  • The “SMART on FHIR® Core Capabilities” in § 170.215(a)(3) are explicitly required for testing and certification because these capabilities are otherwise indicated as optional in the implementation specification.
  • As described in the ONC Cures Act Final Rule, we encourage implementers to adhere to industry best practices to mitigate Cross-Site Request Forgery (CSRF) and other known security threats (85 FR 25742). Proof Key for Code Exchange (PKCE) (Internet Engineering Task Force Request for Comments 7636) is an industry standard that can help mitigate CSRF and other known security threats. The ONC Health IT Certification Program will support the optional use of PKCE during authentication and authorization testing. Health IT developers that implement and require the use of PKCE should include documentation for their PKCE implementation as part of the API Documentation requirement at 45 CFR 170.315(g)(10)(viii) and API Transparency Conditions at 45 CFR 170.404(a)(2).

Applies to SVAP approved standard SMART App Launch Framework 2.0.0:

  • The following “Capabilities” in § 170.215(a)(3) are explicitly required for testing and certification because these capabilities are otherwise indicated as optional in the implementation specification:
  1. launch-ehr
  2. launch-standalone
  3. client-public
  4. client-confidential-symmetric
  5. sso-openid-connect
  6. context-banner
  7. context-style
  8. context-ehr-patient
  9. context-ehr-encounter
  10. context-standalone-patient
  11. permission-offline
  12. permission-patient
  13. permission-user
  14. permission-v1
  15. authorize-post

 


 

Paragraph (g)(10)(v)(A)(2)

Technical outcome – For subsequent connections, access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application. Additionally, a Health IT Module's authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • No additional clarifications.

 

Paragraph (g)(10)(v)(B)

Technical outcome – Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • Health IT Modules may use access control schemes other than OAuth 2.0 for controlling access to the file server, such as capability URLs. The HL7® FHIR®-I Work Group has documented expectations for the use of capability URLs with the Bulk Data Access IG on the HL7® confluence website. For purposes of Certification testing, Health IT Modules will be tested for the ability to share bulk data files either using OAuth 2.0 bearer tokens or via capability URLs accessible without preconditions or additional steps.

 

Paragraph (g)(10)(vi)

Technical outcome – A Health IT Module’s authorization server must be able to revoke an authorized application’s access at a patient’s direction.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • This is a functional requirement to allow health IT developers the ability to implement it in a way that best suits their existing infrastructure and allows for innovative models for authorization revocation to develop.
  • Patients are expected to have the ability to revoke an authorized application’s access to their EHI at any time.
  • For authorization revocation, Health IT Modules presented for certification are permitted to allow short-lived access tokens to expire in lieu of immediate access token revocation. ONC recommends health IT developers limit the lifetime of access tokens to one hour or less as recommended in the standard adopted at § 170.215(a)(3). For purposes of testing and certification, Health IT Modules will be tested for patient authorization revocation occurring within one hour of the request.

 

Paragraph (g)(10)(vii)

Technical outcome – A Health IT Module’s authorization server must be able to receive and validate tokens it has issued.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • Although ONC does not specify a standard for token introspection, ONC encourages industry to coalesce around using a common standard, like OAuth 2.0 Token Introspection (RFC 7662), and specifically the profile of the OAuth 2.0 Token Introspection standard included in the SMART App Launch Framework 2.0.0 implementation specification.

 

Paragraph (g)(10)(viii)(A)

Technical outcome – The API(s) must include complete accompanying documentation that contains, at a minimum: (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns; (2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s); and (3) All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module’s authorization server.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • Health IT developers are not required to re-publish documentation from the adopted standards and implementation specifications. However, health IT developers must publish documentation that goes beyond the adopted standards and implementation specifications.
  • Health IT developers are expected to disclose any additional data their § 170.315(g)(10)-certified Health IT Module supports in the context of the adopted standards and implementation specifications.

 

Paragraph (g)(10)(viii)(B)

Technical outcome – The documentation used to meet paragraph (g)(10)(viii)(A) of this section must be available via a publicly accessible hyperlink without any preconditions or additional steps.

Clarifications:

Applies to all applicable base regulatory and SVAP standards:

  • No additional clarifications.