§170.315(j)(20) Workflow triggers for decision support interventions — clients
§ 170.315(j)(20) Workflow triggers for decision support interventions—clients.
Support the requirements applicable to a “CDS Client” according to at least one of the implementation specifications in § 170.215(f) including the following:
- Registration. Support registration capabilities applicable to “CDS Clients”.
- Authentication and authorization. Support authentication and authorization, including the following:
- Support for client authentication using JSON web tokens (JWT).
- Support for data access authorization of a “CDS Service” using access tokens.
- Workflow triggers. Support the execution of decision support workflow triggers.
- Information exchange. Send a decision support request to a “CDS Service,” including support for the following:
- Resource access via API. Support access to HL7 FHIR Resources via a RESTful API to support decision support intervention workflows according to the “FHIR Resource Access” section.
- Receive and display response. Support the receipt of a decision support response, including support for the display of the contents of a decision support response to an end-user.
Entire Criterion
§ 170.215(f)(1) HL7 FHIR® CDS Hooks Release 2.0.1
Conditions and Maintenance of Certification
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of 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.
- Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
- Accessibility-centered design (§ 170.315(g)(5)): 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.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial publication |
10-01-2025
|
- Regulation Text
-
Regulation Text
§ 170.315(j)(20) Workflow triggers for decision support interventions—clients.
Support the requirements applicable to a “CDS Client” according to at least one of the implementation specifications in § 170.215(f) including the following:
- Registration. Support registration capabilities applicable to “CDS Clients”.
- Authentication and authorization. Support authentication and authorization, including the following:
- Support for client authentication using JSON web tokens (JWT).
- Support for data access authorization of a “CDS Service” using access tokens.
- Workflow triggers. Support the execution of decision support workflow triggers.
- Information exchange. Send a decision support request to a “CDS Service,” including support for the following:
- Resource access via API. Support access to HL7 FHIR Resources via a RESTful API to support decision support intervention workflows according to the “FHIR Resource Access” section.
- Receive and display response. Support the receipt of a decision support response, including support for the display of the contents of a decision support response to an end-user.
- Standard(s) Referenced
-
Entire Criterion
§ 170.215(f)(1) HL7 FHIR® CDS Hooks Release 2.0.1
- Certification Dependencies
-
Conditions and Maintenance of Certification
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of 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.
- Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
- Accessibility-centered design (§ 170.315(g)(5)): 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.
- Testing
-
Testing Tool
Inferno Framework (A link will be provided once the testing tool is available.)
Test Tool Documentation (A link will be provided once the testing tool is available.)
- Revision History
-
Version # Description of Change Version Date 1.0 Initial publication
10-01-2025
This Test Procedure illustrates the test steps required to certify a Health IT Module to this criterion. Please consult the most recent ASTP/ONC Final Rule on theCertification Regulations page for a detailed description of the certification criterion with which these testing steps are associated. ASTP/ONC also encourages developers to consult the Certification Companion Guide in tandem with the test procedure as it provides clarifications that may be useful for product development and testing.
Note: The tests step order does not necessarily prescribe the order in which the tests should take place.
Testing components
Paragraph (j)(20)
The health IT developer demonstrates the Health IT Module supports the following capabilities as a “CDS Client” in accordance with an implementation specification at § 170.215(f):
- CDS-1: Registration with a “CDS Service” including all configuration necessary to invoke a CDS Hook, authenticate as a client, and authorize FHIR resource access.
- CDS-2: Trigger an invocation of a “CDS Service” in accordance with a CDS Hook.
- CDS-3: Authentication as a client with a “CDS Service” using JSON web tokens (JWT).
- CDS-4: Authorization of a “CDS Service” to have the FHIR resource access necessary to enable the “CDS Service” including provisioning an access token.
- CDS-5: FHIR resource access to enable a “CDS Service.” This may include supporting FHIR resource “read” and “search” requests from the “CDS Service.”
- CDS-6: As applicable, processing and display of clinical decision support provided by a “CDS Service.”
The tester verifies the Health IT Module supports the following capabilities as a “CDS Client” in accordance with an implementation specification at § 170.215(f):
- CDS-1: Registration with a “CDS Service” including all configuration necessary to invoke a CDS Hook, authenticate as a client, and authorize FHIR resource access.
- CDS-2: Trigger an invocation of a “CDS Service” in accordance with a CDS Hook.
- CDS-3: Authentication as a client with a “CDS Service” using JSON web tokens (JWT).
- CDS-4: Authorization of a “CDS Service” to have the FHIR resource access necessary to enable the “CDS Service” including provisioning an access token.
- CDS-5: FHIR resource access to enable a “CDS Service.” This may include supporting FHIR resource “read” and “search” requests from the “CDS Service.”
- CDS-6: As applicable, processing and display of clinical decision support provided by a “CDS Service.”
| System Under Test |
Test Lab Verification
|
|---|---|
|
The health IT developer demonstrates the Health IT Module supports the following capabilities as a “CDS Client” in accordance with an implementation specification at § 170.215(f):
|
The tester verifies the Health IT Module supports the following capabilities as a “CDS Client” in accordance with an implementation specification at § 170.215(f):
|
§ 170.315(j)(20) Workflow triggers for decision support interventions—clients.
Support the requirements applicable to a “CDS Client” according to at least one of the implementation specifications in § 170.215(f) including the following:
- Registration. Support registration capabilities applicable to “CDS Clients”.
- Authentication and authorization. Support authentication and authorization, including the following:
- Support for client authentication using JSON web tokens (JWT).
- Support for data access authorization of a “CDS Service” using access tokens.
- Workflow triggers. Support the execution of decision support workflow triggers.
- Information exchange. Send a decision support request to a “CDS Service,” including support for the following:
- Resource access via API. Support access to HL7 FHIR Resources via a RESTful API to support decision support intervention workflows according to the “FHIR Resource Access” section.
- Receive and display response. Support the receipt of a decision support response, including support for the display of the contents of a decision support response to an end-user.
Entire Criterion
§ 170.215(f)(1) HL7 FHIR® CDS Hooks Release 2.0.1
Conditions and Maintenance of Certification
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of 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.
- Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
- Accessibility-centered design (§ 170.315(g)(5)): 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.
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Initial publication |
10-01-2025
|
- Regulation Text
-
Regulation Text
§ 170.315(j)(20) Workflow triggers for decision support interventions—clients.
Support the requirements applicable to a “CDS Client” according to at least one of the implementation specifications in § 170.215(f) including the following:
- Registration. Support registration capabilities applicable to “CDS Clients”.
- Authentication and authorization. Support authentication and authorization, including the following:
- Support for client authentication using JSON web tokens (JWT).
- Support for data access authorization of a “CDS Service” using access tokens.
- Workflow triggers. Support the execution of decision support workflow triggers.
- Information exchange. Send a decision support request to a “CDS Service,” including support for the following:
- Resource access via API. Support access to HL7 FHIR Resources via a RESTful API to support decision support intervention workflows according to the “FHIR Resource Access” section.
- Receive and display response. Support the receipt of a decision support response, including support for the display of the contents of a decision support response to an end-user.
- Standard(s) Referenced
-
Entire Criterion
§ 170.215(f)(1) HL7 FHIR® CDS Hooks Release 2.0.1
- Certification Dependencies
-
Conditions and Maintenance of Certification
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of 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.
- Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
- Accessibility-centered design (§ 170.315(g)(5)): 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.
- Revision History
-
Version # Description of Change Version Date 1.0 Initial publication
09-30-2025 - Testing
-
Testing Tool
Inferno Framework (A link will be provided once the testing tool is available.)
Test Tool Documentation (A link will be provided once the testing tool is available.)
Certification Companion Guide: Workflow triggers for decision support interventions — clients
This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product certification. The CCG is not a substitute for the requirements outlined in regulation and related ASTP/ONC final rules. It extracts key portions of ASTP/ONC final rules’ preambles and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the Certification Program Regulations page for links to all final rules or consult other regulatory references as noted. The CCG is for public use and should not be sold or redistributed.
The below table outlines whether this criterion has additional Maintenance of Certification dependencies, update requirements and/or eligibility for standards updates via SVAP. Review the Certification Dependencies and Required Update Deadline drop-downs above if this table indicates “yes” for any field.
| Base EHR Definition | Real World Testing | Insights Condition | SVAP | Requires Updates |
|---|---|---|---|---|
| Not Included | Yes | No | No | No |
Applies to entire criterion
Clarifications:
- The criterion does not define specific workflows associated with decision support, including how and when clinicians use decision support capabilities. Rather, this criterion includes standards-based interfaces to enable clinical systems to call other systems offering decision support services in a standardized manner to support the exchange and use of these services. [see also 90 FR 37159]
|
Clarifications:
|
Paragraph (j)(20)(i) Registration
Technical outcome – The Health IT Module supports registration capabilities applicable to “CDS Clients” according to the HL7 FHIR® CDS Hooks IG.
Clarifications:
- No additional clarifications
|
Technical outcome – The Health IT Module supports registration capabilities applicable to “CDS Clients” according to the HL7 FHIR® CDS Hooks IG. Clarifications:
|
Paragraph (j)(20)(ii) Authentication and authorization
Technical outcome – The Health IT Module supports authentication and authorization, with client authentication using JSON web tokens (JWT) and data access authorization of a “CDS Service” using access tokens.
Clarifications:
- No additional clarifications
|
Technical outcome – The Health IT Module supports authentication and authorization, with client authentication using JSON web tokens (JWT) and data access authorization of a “CDS Service” using access tokens. Clarifications:
|
Paragraph (j)(20)(iii) Workflow triggers
Technical outcome – The Health IT Module supports the execution of decision support workflow triggers.
Clarifications:
- No additional clarifications
|
Technical outcome – The Health IT Module supports the execution of decision support workflow triggers. Clarifications:
|
Paragraph (j)(20)(iv) Information exchange
Technical outcome –The Health IT Module supports sending a decision support request to a “CDS Service,” including support for (A) access to FHIR® Resources via a RESTful API, and (B) the receipt of a decision support response.
Clarifications:
- No additional clarifications
|
Technical outcome –The Health IT Module supports sending a decision support request to a “CDS Service,” including support for (A) access to FHIR® Resources via a RESTful API, and (B) the receipt of a decision support response. Clarifications:
|