§170.315(b)(11) Decision support interventions

Certification Companion Guide (CCG)
Conformance Method

Updated on 03-11-2024

Regulation Text

§ 170.315 (b)(11) Decision support interventions—

Decision support intervention interaction. Interventions provided to a user must occur when a user is interacting with technology.
Decision support configuration.
1. Enable interventions specified in paragraphs (b)(11)(iii) of this section to be configured by a limited set of identified users based on a user's role.
2. Enable interventions when a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care or referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.
3. Enable a user to provide electronic feedback data for evidence-based decision support interventions selected via the capability provided in paragraph (b)(11)(iii)(A) of this section and make available such feedback data to a limited set of identified users for export, in a computable format, including at a minimum the intervention, action taken, user feedback provided (if applicable), user, date, and location.
Decision support intervention selection. Enable a limited set of identified users to select (i.e., activate) electronic decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) that are:
1. Evidence-based decision support interventions and use any data based on the following data expressed in the standards in § 170.213:
  1. Problems;
  2. Medications;
  3. Allergies and Intolerances;
  4. At least one demographic specified in paragraph (a)(5)(i) of this section;
  5. Laboratory;
  6. Vital Signs;
  7. Unique Device Identifier(s) for a Patient's Implantable Device(s); and
  8. Procedures.
2. Predictive Decision Support Interventions and use any data expressed in the standards in § 170.213.
Source attributes. Source attributes listed in paragraphs (b)(11)(iv)(A) and (B) of this section must be supported.
1. For evidence-based decision support interventions:
  1. Bibliographic citation of the intervention (clinical research or guideline);
  2. Developer of the intervention (translation from clinical research or guideline);
  3. Funding source of the technical implementation for the intervention(s) development;
  4. Release and, if applicable, revision dates of the intervention or reference source;
  5. Use of race as expressed in the standards in § 170.213;
  6. Use of ethnicity as expressed in the standards in § 170.213;
  7. Use of language as expressed in the standards in § 170.213;
  8. Use of sexual orientation as expressed in the standards in § 170.213;
  9. Use of gender identity as expressed in the standards in § 170.213;
  10. Use of sex as expressed in the standards in § 170.213;
  11. Use of date of birth as expressed in the standards in § 170.213;
  12. Use of social determinants of health data as expressed in the standards in § 170.213; and
  13. Use of health status assessments data as expressed in the standards in § 170.213.
2. For Predictive Decision Support Interventions:
  1. Details and output of the intervention, including:
    1. Name and contact information for the intervention developer;
    2. Funding source of the technical implementation for the intervention(s) development;
    3. Description of value that the intervention produces as an output; and
    4. Whether the intervention output is a prediction, classification, recommendation, evaluation, analysis, or other type of output.
  2. Purpose of the intervention, including:
    1. Intended use of the intervention;
    2. Intended patient population(s) for the intervention’s use;
    3. Intended user(s); and
    4. Intended decision-making role for which the intervention was designed to be used/for (e.g., informs, augments, replaces clinical management).
  3. Cautioned out-of-scope use of the intervention, including:
    1. Description of tasks, situations, or populations where a user is cautioned against applying the intervention; and
    2. Known risks, inappropriate settings, inappropriate uses, or known limitations.
  4. Intervention development details and input features, including at a minimum:
    1. Exclusion and inclusion criteria that influenced the training data set;
    2. Use of variables in paragraph (b)(11)(iv)(A)(5)-(13) as input features;
    3. Description of demographic representativeness according to variables in paragraph (b)(11)(iv)(A)(5)-(13) including, at a minimum, those used as input features in the intervention;
    4. Description of relevance of training data to intended deployed setting; and
  5. Process used to ensure fairness in development of the intervention, including:
    1. Description of the approach the intervention developer has taken to ensure that the intervention’s output is fair; and
    2. Description of approaches to manage, reduce, or eliminate bias.
  6. External validation process, including:
    1. Description of the data source, clinical setting, or environment where an intervention’s validity and fairness has been assessed, other than the source of training and testing data
    2. Party that conducted the external testing;
    3. Description of demographic representativeness of external data according to variables in paragraph (b)(11)(iv)(A)(5)-(13) including, at a minimum, those used as input features in the intervention; and
    4. Description of external validation process.
  7. Quantitative measures of performance, including:
    1. Validity of intervention in test data derived from the same source as the initial training data;
    2. Fairness of intervention in test data derived from the same source as the initial training data;
    3. Validity of intervention in data external to or from a different source than the initial training data;
    4. Fairness of intervention in data external to or from a different source than the initial training data;
    5. References to evaluation of use of the intervention on outcomes, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other outcomes;
  8. Ongoing maintenance of intervention implementation and use, including:
    1. Description of process and frequency by which the intervention’s validity is monitored over time;
    2. Validity of intervention in local data;
    3. Description of the process and frequency by which the intervention’s fairness is monitored over time;
    4. Fairness of intervention in local data; and
  9. Update and continued validation or fairness assessment schedule, including:
    1. Description of process and frequency by which the intervention is updated; and
    2. Description of frequency by which the intervention’s performance is corrected when risks related to validity and fairness are identified.
Source attribute access and modification.
1. Access.
  1. For evidence-based decision support interventions and Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information specified in paragraphs (b)(11)(iv)(A) and (B) of this section.
  2. For Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must indicate when information is not available for review for source attributes in paragraphs (b)(11)(iv)(B)(6); (b)(11)(iv)(B)(7)(iii), (iv), and (v); (b)(11)(iv)(B)(8)(ii) and (iv); and (b)(11)(iv)(B)(9) of this section.
2. Modify.
  1. For evidence-based decision support interventions and Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section.
  2. For Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access additional source attributes not specified in paragraph (b)(11)(iv)(B) of this section.
Intervention risk management. Intervention risk management practices must be applied for each Predictive Decision Support Intervention supplied by the health IT developer as part of its Health IT Module.
1. Risk analysis. The Predictive Decision Support Intervention(s) must be subject to analysis of potential risks and adverse impacts associated with the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy.
2. Risk mitigation. The Predictive Decision Support Intervention (s) must be subject to practices to mitigate risks, identified in accordance with paragraph (b)(11)(vi)(A) of this section; and
3. Governance. The Predictive Decision Support Intervention(s) must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used.

Standard(s) Referenced

§ 170.213(a) United States Core Data for Interoperability (USCDI), July 2020 Errata, Version 1 (Adoption of this standard expires on January 1, 2026)

§ 170.213(b) United States Core Data for Interoperability Version 3 (USCDI v3) (This standard is required by December 31, 2025)

Required Update Deadlines

The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to one’s certification under Certification Dependencies.

Deadline: December 31, 2024

Actions to be taken: Developers who wish to remain certified to the Base EHR definition must certify to the criterion in § 170.315(b)(11).

Deadline: December 31, 2025

Actions to be taken: Compliance with USCDI v3 will be required as part of this certification criterion in § 170.315(b)(11), which will include identification of the use of the patient demographic data elements that are only found in USCDI v3 as part of evidence-based DSIs in § 170.315(b)(11)(11)(iv)(A)(5)-(13). The expansion from USCDI v1 to v3 also expands the data set from which users must be able to select Predictive DSIs.

Certification Dependencies

Conditions and Maintenance of Certification

Assurances: Products certified to this criterion must complete requirements outlined for the Assurances Conditions and Maintenance of Certification at § 170.402(b)(4).

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.

Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion. Certified Health IT Developers must assess user-facing functionality gaps between the requirements of § 170.315(a)(9) and § 170.315(b)(11) and as necessary update their safety-enhanced design (SED) testing.
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	03-11-2024

Regulation Text

Regulation Text

§ 170.315 (b)(11) Decision support interventions—

Decision support intervention interaction. Interventions provided to a user must occur when a user is interacting with technology.
Decision support configuration.
1. Enable interventions specified in paragraphs (b)(11)(iii) of this section to be configured by a limited set of identified users based on a user's role.
2. Enable interventions when a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care or referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.
3. Enable a user to provide electronic feedback data for evidence-based decision support interventions selected via the capability provided in paragraph (b)(11)(iii)(A) of this section and make available such feedback data to a limited set of identified users for export, in a computable format, including at a minimum the intervention, action taken, user feedback provided (if applicable), user, date, and location.
Decision support intervention selection. Enable a limited set of identified users to select (i.e., activate) electronic decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) that are:
1. Evidence-based decision support interventions and use any data based on the following data expressed in the standards in § 170.213:
  1. Problems;
  2. Medications;
  3. Allergies and Intolerances;
  4. At least one demographic specified in paragraph (a)(5)(i) of this section;
  5. Laboratory;
  6. Vital Signs;
  7. Unique Device Identifier(s) for a Patient's Implantable Device(s); and
  8. Procedures.
2. Predictive Decision Support Interventions and use any data expressed in the standards in § 170.213.
Source attributes. Source attributes listed in paragraphs (b)(11)(iv)(A) and (B) of this section must be supported.
1. For evidence-based decision support interventions:
  1. Bibliographic citation of the intervention (clinical research or guideline);
  2. Developer of the intervention (translation from clinical research or guideline);
  3. Funding source of the technical implementation for the intervention(s) development;
  4. Release and, if applicable, revision dates of the intervention or reference source;
  5. Use of race as expressed in the standards in § 170.213;
  6. Use of ethnicity as expressed in the standards in § 170.213;
  7. Use of language as expressed in the standards in § 170.213;
  8. Use of sexual orientation as expressed in the standards in § 170.213;
  9. Use of gender identity as expressed in the standards in § 170.213;
  10. Use of sex as expressed in the standards in § 170.213;
  11. Use of date of birth as expressed in the standards in § 170.213;
  12. Use of social determinants of health data as expressed in the standards in § 170.213; and
  13. Use of health status assessments data as expressed in the standards in § 170.213.
2. For Predictive Decision Support Interventions:
  1. Details and output of the intervention, including:
    1. Name and contact information for the intervention developer;
    2. Funding source of the technical implementation for the intervention(s) development;
    3. Description of value that the intervention produces as an output; and
    4. Whether the intervention output is a prediction, classification, recommendation, evaluation, analysis, or other type of output.
  2. Purpose of the intervention, including:
    1. Intended use of the intervention;
    2. Intended patient population(s) for the intervention’s use;
    3. Intended user(s); and
    4. Intended decision-making role for which the intervention was designed to be used/for (e.g., informs, augments, replaces clinical management).
  3. Cautioned out-of-scope use of the intervention, including:
    1. Description of tasks, situations, or populations where a user is cautioned against applying the intervention; and
    2. Known risks, inappropriate settings, inappropriate uses, or known limitations.
  4. Intervention development details and input features, including at a minimum:
    1. Exclusion and inclusion criteria that influenced the training data set;
    2. Use of variables in paragraph (b)(11)(iv)(A)(5)-(13) as input features;
    3. Description of demographic representativeness according to variables in paragraph (b)(11)(iv)(A)(5)-(13) including, at a minimum, those used as input features in the intervention;
    4. Description of relevance of training data to intended deployed setting; and
  5. Process used to ensure fairness in development of the intervention, including:
    1. Description of the approach the intervention developer has taken to ensure that the intervention’s output is fair; and
    2. Description of approaches to manage, reduce, or eliminate bias.
  6. External validation process, including:
    1. Description of the data source, clinical setting, or environment where an intervention’s validity and fairness has been assessed, other than the source of training and testing data
    2. Party that conducted the external testing;
    3. Description of demographic representativeness of external data according to variables in paragraph (b)(11)(iv)(A)(5)-(13) including, at a minimum, those used as input features in the intervention; and
    4. Description of external validation process.
  7. Quantitative measures of performance, including:
    1. Validity of intervention in test data derived from the same source as the initial training data;
    2. Fairness of intervention in test data derived from the same source as the initial training data;
    3. Validity of intervention in data external to or from a different source than the initial training data;
    4. Fairness of intervention in data external to or from a different source than the initial training data;
    5. References to evaluation of use of the intervention on outcomes, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other outcomes;
  8. Ongoing maintenance of intervention implementation and use, including:
    1. Description of process and frequency by which the intervention’s validity is monitored over time;
    2. Validity of intervention in local data;
    3. Description of the process and frequency by which the intervention’s fairness is monitored over time;
    4. Fairness of intervention in local data; and
  9. Update and continued validation or fairness assessment schedule, including:
    1. Description of process and frequency by which the intervention is updated; and
    2. Description of frequency by which the intervention’s performance is corrected when risks related to validity and fairness are identified.
Source attribute access and modification.
1. Access.
  1. For evidence-based decision support interventions and Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information specified in paragraphs (b)(11)(iv)(A) and (B) of this section.
  2. For Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must indicate when information is not available for review for source attributes in paragraphs (b)(11)(iv)(B)(6); (b)(11)(iv)(B)(7)(iii), (iv), and (v); (b)(11)(iv)(B)(8)(ii) and (iv); and (b)(11)(iv)(B)(9) of this section.
2. Modify.
  1. For evidence-based decision support interventions and Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section.
  2. For Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access additional source attributes not specified in paragraph (b)(11)(iv)(B) of this section.
Intervention risk management. Intervention risk management practices must be applied for each Predictive Decision Support Intervention supplied by the health IT developer as part of its Health IT Module.
1. Risk analysis. The Predictive Decision Support Intervention(s) must be subject to analysis of potential risks and adverse impacts associated with the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy.
2. Risk mitigation. The Predictive Decision Support Intervention (s) must be subject to practices to mitigate risks, identified in accordance with paragraph (b)(11)(vi)(A) of this section; and
3. Governance. The Predictive Decision Support Intervention(s) must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used.

Standard(s) Referenced

§ 170.213(a) United States Core Data for Interoperability (USCDI), July 2020 Errata, Version 1 (Adoption of this standard expires on January 1, 2026)

§ 170.213(b) United States Core Data for Interoperability Version 3 (USCDI v3) (This standard is required by December 31, 2025)

Required Update Deadlines

Deadline: December 31, 2024

Actions to be taken: Developers who wish to remain certified to the Base EHR definition must certify to the criterion in § 170.315(b)(11).

Deadline: December 31, 2025

Certification Dependencies

Conditions and Maintenance of Certification

Assurances: Products certified to this criterion must complete requirements outlined for the Assurances Conditions and Maintenance of Certification at § 170.402(b)(4).

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.

Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion. Certified Health IT Developers must assess user-facing functionality gaps between the requirements of § 170.315(a)(9) and § 170.315(b)(11) and as necessary update their safety-enhanced design (SED) testing.
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	03-11-2024

Testing components

Attestation: As of March 11, 2024, the testing approach for this criterion is satisfied by attestation.

System Under Test	ONC-ACB Verification
The health IT developer will attest directly to the ONC-ACB to conformance with § 170.315 (b)(11) Decision support interventions.	The ONC-ACB verifies the health IT developer attests conformance to § 170.315(b)(11) Decision support interventions.

Archived Version:

Updated on 09-16-2024

Regulation Text

§ 170.315 (b)(11) Decision support interventions—

Decision support intervention interaction. Interventions provided to a user must occur when a user is interacting with technology.
Decision support configuration.
1. Enable interventions specified in paragraphs (b)(11)(iii) of this section to be configured by a limited set of identified users based on a user's role.
2. Enable interventions when a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care or referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.
3. Enable a user to provide electronic feedback data for evidence-based decision support interventions selected via the capability provided in paragraph (b)(11)(iii)(A) of this section and make available such feedback data to a limited set of identified users for export, in a computable format, including at a minimum the intervention, action taken, user feedback provided (if applicable), user, date, and location.
Decision support intervention selection. Enable a limited set of identified users to select (i.e., activate) electronic decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) that are:
1. Evidence-based decision support interventions and use any data based on the following data expressed in the standards in § 170.213:
  1. Problems;
  2. Medications;
  3. Allergies and Intolerances;
  4. At least one demographic specified in paragraph (a)(5)(i) of this section;
  5. Laboratory;
  6. Vital Signs;
  7. Unique Device Identifier(s) for a Patient's Implantable Device(s); and
  8. Procedures.
2. Predictive Decision Support Interventions and use any data expressed in the standards in § 170.213.
Source attributes. Source attributes listed in paragraphs (b)(11)(iv)(A) and (B) of this section must be supported.
1. For evidence-based decision support interventions:
  1. Bibliographic citation of the intervention (clinical research or guideline);
  2. Developer of the intervention (translation from clinical research or guideline);
  3. Funding source of the technical implementation for the intervention(s) development;
  4. Release and, if applicable, revision dates of the intervention or reference source;
  5. Use of race as expressed in the standards in § 170.213;
  6. Use of ethnicity as expressed in the standards in § 170.213;
  7. Use of language as expressed in the standards in § 170.213;
  8. Use of sexual orientation as expressed in the standards in § 170.213;
  9. Use of gender identity as expressed in the standards in § 170.213;
  10. Use of sex as expressed in the standards in § 170.213;
  11. Use of date of birth as expressed in the standards in § 170.213;
  12. Use of social determinants of health data as expressed in the standards in § 170.213; and
  13. Use of health status assessments data as expressed in the standards in § 170.213.
2. For Predictive Decision Support Interventions:
  1. Details and output of the intervention, including:
    1. Name and contact information for the intervention developer;
    2. Funding source of the technical implementation for the intervention(s) development;
    3. Description of value that the intervention produces as an output; and
    4. Whether the intervention output is a prediction, classification, recommendation, evaluation, analysis, or other type of output.
  2. Purpose of the intervention, including:
    1. Intended use of the intervention;
    2. Intended patient population(s) for the intervention’s use;
    3. Intended user(s); and
    4. Intended decision-making role for which the intervention was designed to be used/for (e.g., informs, augments, replaces clinical management).
  3. Cautioned out-of-scope use of the intervention, including:
    1. Description of tasks, situations, or populations where a user is cautioned against applying the intervention; and
    2. Known risks, inappropriate settings, inappropriate uses, or known limitations.
  4. Intervention development details and input features, including at a minimum:
    1. Exclusion and inclusion criteria that influenced the training data set;
    2. Use of variables in paragraph (b)(11)(iv)(A)(5)-(13) as input features;
    3. Description of demographic representativeness according to variables in paragraph (b)(11)(iv)(A)(5)-(13) including, at a minimum, those used as input features in the intervention;
    4. Description of relevance of training data to intended deployed setting; and
  5. Process used to ensure fairness in development of the intervention, including:
    1. Description of the approach the intervention developer has taken to ensure that the intervention’s output is fair; and
    2. Description of approaches to manage, reduce, or eliminate bias.
  6. External validation process, including:
    1. Description of the data source, clinical setting, or environment where an intervention’s validity and fairness has been assessed, other than the source of training and testing data
    2. Party that conducted the external testing;
    3. Description of demographic representativeness of external data according to variables in paragraph (b)(11)(iv)(A)(5)-(13) including, at a minimum, those used as input features in the intervention; and
    4. Description of external validation process.
  7. Quantitative measures of performance, including:
    1. Validity of intervention in test data derived from the same source as the initial training data;
    2. Fairness of intervention in test data derived from the same source as the initial training data;
    3. Validity of intervention in data external to or from a different source than the initial training data;
    4. Fairness of intervention in data external to or from a different source than the initial training data;
    5. References to evaluation of use of the intervention on outcomes, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other outcomes;
  8. Ongoing maintenance of intervention implementation and use, including:
    1. Description of process and frequency by which the intervention’s validity is monitored over time;
    2. Validity of intervention in local data;
    3. Description of the process and frequency by which the intervention’s fairness is monitored over time;
    4. Fairness of intervention in local data; and
  9. Update and continued validation or fairness assessment schedule, including:
    1. Description of process and frequency by which the intervention is updated; and
    2. Description of frequency by which the intervention’s performance is corrected when risks related to validity and fairness are identified.
Source attribute access and modification.
1. Access.
  1. For evidence-based decision support interventions and Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information specified in paragraphs (b)(11)(iv)(A) and (B) of this section.
  2. For Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must indicate when information is not available for review for source attributes in paragraphs (b)(11)(iv)(B)(6); (b)(11)(iv)(B)(7)(iii), (iv), and (v); (b)(11)(iv)(B)(8)(ii) and (iv); and (b)(11)(iv)(B)(9) of this section.
2. Modify.
  1. For evidence-based decision support interventions and Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section.
  2. For Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access additional source attributes not specified in paragraph (b)(11)(iv)(B) of this section.
Intervention risk management. Intervention risk management practices must be applied for each Predictive Decision Support Intervention supplied by the health IT developer as part of its Health IT Module.
1. Risk analysis. The Predictive Decision Support Intervention(s) must be subject to analysis of potential risks and adverse impacts associated with the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy.
2. Risk mitigation. The Predictive Decision Support Intervention (s) must be subject to practices to mitigate risks, identified in accordance with paragraph (b)(11)(vi)(A) of this section; and
3. Governance. The Predictive Decision Support Intervention(s) must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used.

Standard(s) Referenced

§ 170.213(a) United States Core Data for Interoperability (USCDI), July 2020 Errata, Version 1 (Adoption of this standard expires on January 1, 2026)

§ 170.213(b) United States Core Data for Interoperability Version 3 (USCDI v3) (This standard is required by December 31, 2025)

Required Update Deadlines

Deadline: December 31, 2024

Actions to be taken: Developers who wish to remain certified to the Base EHR definition must certify to the criterion in § 170.315(b)(11).

Deadline: December 31, 2025

Certification Dependencies

Conditions and Maintenance of Certification

Assurances: Products certified to this criterion must complete requirements outlined for the Assurances Conditions and Maintenance of Certification at § 170.402(b)(4).

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.

Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion. Certified Health IT Developers must assess user-facing functionality gaps between the requirements of § 170.315(a)(9) and § 170.315(b)(11) and as necessary update their safety-enhanced design (SED) testing.
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	03-11-2024

Regulation Text

Regulation Text

§ 170.315 (b)(11) Decision support interventions—

Decision support intervention interaction. Interventions provided to a user must occur when a user is interacting with technology.
Decision support configuration.
1. Enable interventions specified in paragraphs (b)(11)(iii) of this section to be configured by a limited set of identified users based on a user's role.
2. Enable interventions when a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care or referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.
3. Enable a user to provide electronic feedback data for evidence-based decision support interventions selected via the capability provided in paragraph (b)(11)(iii)(A) of this section and make available such feedback data to a limited set of identified users for export, in a computable format, including at a minimum the intervention, action taken, user feedback provided (if applicable), user, date, and location.
Decision support intervention selection. Enable a limited set of identified users to select (i.e., activate) electronic decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) that are:
1. Evidence-based decision support interventions and use any data based on the following data expressed in the standards in § 170.213:
  1. Problems;
  2. Medications;
  3. Allergies and Intolerances;
  4. At least one demographic specified in paragraph (a)(5)(i) of this section;
  5. Laboratory;
  6. Vital Signs;
  7. Unique Device Identifier(s) for a Patient's Implantable Device(s); and
  8. Procedures.
2. Predictive Decision Support Interventions and use any data expressed in the standards in § 170.213.
Source attributes. Source attributes listed in paragraphs (b)(11)(iv)(A) and (B) of this section must be supported.
1. For evidence-based decision support interventions:
  1. Bibliographic citation of the intervention (clinical research or guideline);
  2. Developer of the intervention (translation from clinical research or guideline);
  3. Funding source of the technical implementation for the intervention(s) development;
  4. Release and, if applicable, revision dates of the intervention or reference source;
  5. Use of race as expressed in the standards in § 170.213;
  6. Use of ethnicity as expressed in the standards in § 170.213;
  7. Use of language as expressed in the standards in § 170.213;
  8. Use of sexual orientation as expressed in the standards in § 170.213;
  9. Use of gender identity as expressed in the standards in § 170.213;
  10. Use of sex as expressed in the standards in § 170.213;
  11. Use of date of birth as expressed in the standards in § 170.213;
  12. Use of social determinants of health data as expressed in the standards in § 170.213; and
  13. Use of health status assessments data as expressed in the standards in § 170.213.
2. For Predictive Decision Support Interventions:
  1. Details and output of the intervention, including:
    1. Name and contact information for the intervention developer;
    2. Funding source of the technical implementation for the intervention(s) development;
    3. Description of value that the intervention produces as an output; and
    4. Whether the intervention output is a prediction, classification, recommendation, evaluation, analysis, or other type of output.
  2. Purpose of the intervention, including:
    1. Intended use of the intervention;
    2. Intended patient population(s) for the intervention’s use;
    3. Intended user(s); and
    4. Intended decision-making role for which the intervention was designed to be used/for (e.g., informs, augments, replaces clinical management).
  3. Cautioned out-of-scope use of the intervention, including:
    1. Description of tasks, situations, or populations where a user is cautioned against applying the intervention; and
    2. Known risks, inappropriate settings, inappropriate uses, or known limitations.
  4. Intervention development details and input features, including at a minimum:
    1. Exclusion and inclusion criteria that influenced the training data set;
    2. Use of variables in paragraph (b)(11)(iv)(A)(5)-(13) as input features;
    3. Description of demographic representativeness according to variables in paragraph (b)(11)(iv)(A)(5)-(13) including, at a minimum, those used as input features in the intervention;
    4. Description of relevance of training data to intended deployed setting; and
  5. Process used to ensure fairness in development of the intervention, including:
    1. Description of the approach the intervention developer has taken to ensure that the intervention’s output is fair; and
    2. Description of approaches to manage, reduce, or eliminate bias.
  6. External validation process, including:
    1. Description of the data source, clinical setting, or environment where an intervention’s validity and fairness has been assessed, other than the source of training and testing data
    2. Party that conducted the external testing;
    3. Description of demographic representativeness of external data according to variables in paragraph (b)(11)(iv)(A)(5)-(13) including, at a minimum, those used as input features in the intervention; and
    4. Description of external validation process.
  7. Quantitative measures of performance, including:
    1. Validity of intervention in test data derived from the same source as the initial training data;
    2. Fairness of intervention in test data derived from the same source as the initial training data;
    3. Validity of intervention in data external to or from a different source than the initial training data;
    4. Fairness of intervention in data external to or from a different source than the initial training data;
    5. References to evaluation of use of the intervention on outcomes, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other outcomes;
  8. Ongoing maintenance of intervention implementation and use, including:
    1. Description of process and frequency by which the intervention’s validity is monitored over time;
    2. Validity of intervention in local data;
    3. Description of the process and frequency by which the intervention’s fairness is monitored over time;
    4. Fairness of intervention in local data; and
  9. Update and continued validation or fairness assessment schedule, including:
    1. Description of process and frequency by which the intervention is updated; and
    2. Description of frequency by which the intervention’s performance is corrected when risks related to validity and fairness are identified.
Source attribute access and modification.
1. Access.
  1. For evidence-based decision support interventions and Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information specified in paragraphs (b)(11)(iv)(A) and (B) of this section.
  2. For Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must indicate when information is not available for review for source attributes in paragraphs (b)(11)(iv)(B)(6); (b)(11)(iv)(B)(7)(iii), (iv), and (v); (b)(11)(iv)(B)(8)(ii) and (iv); and (b)(11)(iv)(B)(9) of this section.
2. Modify.
  1. For evidence-based decision support interventions and Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section.
  2. For Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access additional source attributes not specified in paragraph (b)(11)(iv)(B) of this section.
Intervention risk management. Intervention risk management practices must be applied for each Predictive Decision Support Intervention supplied by the health IT developer as part of its Health IT Module.
1. Risk analysis. The Predictive Decision Support Intervention(s) must be subject to analysis of potential risks and adverse impacts associated with the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy.
2. Risk mitigation. The Predictive Decision Support Intervention (s) must be subject to practices to mitigate risks, identified in accordance with paragraph (b)(11)(vi)(A) of this section; and
3. Governance. The Predictive Decision Support Intervention(s) must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used.

Standard(s) Referenced

§ 170.213(a) United States Core Data for Interoperability (USCDI), July 2020 Errata, Version 1 (Adoption of this standard expires on January 1, 2026)

§ 170.213(b) United States Core Data for Interoperability Version 3 (USCDI v3) (This standard is required by December 31, 2025)

Required Update Deadlines

Deadline: December 31, 2024

Actions to be taken: Developers who wish to remain certified to the Base EHR definition must certify to the criterion in § 170.315(b)(11).

Deadline: December 31, 2025

Certification Dependencies

Conditions and Maintenance of Certification

Assurances: Products certified to this criterion must complete requirements outlined for the Assurances Conditions and Maintenance of Certification at § 170.402(b)(4).

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.

Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion. Certified Health IT Developers must assess user-facing functionality gaps between the requirements of § 170.315(a)(9) and § 170.315(b)(11) and as necessary update their safety-enhanced design (SED) testing.
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	03-11-2024
1.1	Added Decision Support Interventions (DSI) Resource Guide to clarifications to provide further guidance to developers looking to certify to this criterion	05-17-2024
1.2	Added clarifications for the meaning of “as part of its Health IT Module.”	07-01-2024
1.3	Added clarification regarding scenarios with unknown source attribute information related to subparagraph (b)(11)(v).	09-16-2024

Certification Companion Guide: Decision support interventions

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 ONC final rules. It extracts key portions of 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 ONC final rules related to the Certification Program 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
Included	Yes	No	No	Yes

Certification Requirements

Technical Explanations and Clarifications

Applies to Entire Criterion

Clarifications:

The Base EHR definition has been updated in 45 CFR 170.102 to include an option for a Health IT Module to meet the definition by either being certified to the existing CDS version of the certification criterion in § 170.315(a)(9) or being certified to the revised DSI criterion in § 170.315(b)(11), for the period up to, and including, December 31, 2024. On and after January 1, 2025, only the DSI criterion in § 170.315(b)(11) will be included in the Base EHR definition and the adoption of the criterion in § 170.315(a)(9) will expire on January 1, 2025. [see also 89 FR 1281]
ONC defines Predictive Decision Support Intervention or Predictive DSI at 45 CFR 170.102 as “technology that supports decision-making based on algorithms or models that derive relationships from training data and then produces an output that results in prediction, classification, recommendation, evaluation, or analysis.” [see also 89 FR 1244]
It is the responsibility of the developer to make the determination whether a technology or function meets the definition of Predictive DSI in § 170.102. ONC does not assess whether specific algorithms, models, and technologies would meet the definition for Predictive DSI in § 170.102. Rather than make specific assessments, ONC provides a series of examples of technologies that would likely meet our definition for Predictive DSI and examples of technologies that would likely not meet our definition for Predictive DSI at 89 FR 1245-46.
As part of the Maintenance of Certification requirements outlined at 45 CFR 170.402(b)(4), Certified Health IT developers have an ongoing responsibility to review and update as necessary source attribute information in § 170.315(b)(11)(iv)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi).
The phrase “limited set of identified users” across the (b)(11) criterion conveys that the capability is not required for all users of the Health IT Module. Rather, that the capability can be constrained to a smaller userbase that are identified by the user’s organization to have the privileges necessary to use the capabilities in § 170.315(b)(11). [see also 89 FR 1256]
The Certification Program does not require a developer of certified health IT to author, develop, or otherwise directly provide a Predictive DSI to their customers to be certified to the (b)(11) criterion. [see also 89 FR 1252]
Certified Health IT Developers are not accountable for populating source attribute information for Predictive DSIs they do not supply as part of their Health IT Module, including other-party-developed Predictive DSIs used within their certified health IT. This is true even if the customer leverages data from the Certified Health IT developer’s Health IT Module and even if the output from another party’s Predictive DSI is delivered to or through a Health IT Module into a customer’s clinical workflow. [see also 89 FR 1253]
We interpret “supplied by” to include interventions authored or developed by the health IT developer as well as interventions authored or developed by another party that the health IT developer includes as part of its Health IT Module, such as stated in the comments “when entities have contracts specifically covering the enablement and use of such technologies.” The concept of “supplied by” means that the Certified Health IT developer has taken on stewardship and accountability for that Predictive DSI for the purposes of the Health IT Module. ONC interprets “as part of its Health IT Module” to mean that the Certified Health IT developer has explicitly offered or provided its customers the technical capability to use or support a Predictive DSI, regardless of whether the Predictive DSI was developed by the Certified Health IT developer or by an other party. [see also 89 FR 1253]
“As part of its Health IT Module" includes any supplied DSIs that are a part of a (b)(11)-certified, CHPL-listed product. This means that if a developer supplies a Predictive DSI as part of a product that is (b)(11)-certified, the developer must include source attributes and other requirements for that Predictive DSI.
Certified Health IT developers can find more information and considerations for certifying to the (b)(11) DSI criterion in the Decision Support Interventions (DSI) Resource Guide.

Applies to Entire Criterion

Clarifications:

The Base EHR definition has been updated in 45 CFR 170.102 to include an option for a Health IT Module to meet the definition by either being certified to the existing CDS version of the certification criterion in § 170.315(a)(9) or being certified to the revised DSI criterion in § 170.315(b)(11), for the period up to, and including, December 31, 2024. On and after January 1, 2025, only the DSI criterion in § 170.315(b)(11) will be included in the Base EHR definition and the adoption of the criterion in § 170.315(a)(9) will expire on January 1, 2025. [see also 89 FR 1281]
ONC defines Predictive Decision Support Intervention or Predictive DSI at 45 CFR 170.102 as “technology that supports decision-making based on algorithms or models that derive relationships from training data and then produces an output that results in prediction, classification, recommendation, evaluation, or analysis.” [see also 89 FR 1244]
It is the responsibility of the developer to make the determination whether a technology or function meets the definition of Predictive DSI in § 170.102. ONC does not assess whether specific algorithms, models, and technologies would meet the definition for Predictive DSI in § 170.102. Rather than make specific assessments, ONC provides a series of examples of technologies that would likely meet our definition for Predictive DSI and examples of technologies that would likely not meet our definition for Predictive DSI at 89 FR 1245-46.
As part of the Maintenance of Certification requirements outlined at 45 CFR 170.402(b)(4), Certified Health IT developers have an ongoing responsibility to review and update as necessary source attribute information in § 170.315(b)(11)(iv)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi).
The phrase “limited set of identified users” across the (b)(11) criterion conveys that the capability is not required for all users of the Health IT Module. Rather, that the capability can be constrained to a smaller userbase that are identified by the user’s organization to have the privileges necessary to use the capabilities in § 170.315(b)(11). [see also 89 FR 1256]
The Certification Program does not require a developer of certified health IT to author, develop, or otherwise directly provide a Predictive DSI to their customers to be certified to the (b)(11) criterion. [see also 89 FR 1252]
Certified Health IT Developers are not accountable for populating source attribute information for Predictive DSIs they do not supply as part of their Health IT Module, including other-party-developed Predictive DSIs used within their certified health IT. This is true even if the customer leverages data from the Certified Health IT developer’s Health IT Module and even if the output from another party’s Predictive DSI is delivered to or through a Health IT Module into a customer’s clinical workflow. [see also 89 FR 1253]
We interpret “supplied by” to include interventions authored or developed by the health IT developer as well as interventions authored or developed by another party that the health IT developer includes as part of its Health IT Module, such as stated in the comments “when entities have contracts specifically covering the enablement and use of such technologies.” The concept of “supplied by” means that the Certified Health IT developer has taken on stewardship and accountability for that Predictive DSI for the purposes of the Health IT Module. ONC interprets “as part of its Health IT Module” to mean that the Certified Health IT developer has explicitly offered or provided its customers the technical capability to use or support a Predictive DSI, regardless of whether the Predictive DSI was developed by the Certified Health IT developer or by an other party. [see also 89 FR 1253]
“As part of its Health IT Module" includes any supplied DSIs that are a part of a (b)(11)-certified, CHPL-listed product. This means that if a developer supplies a Predictive DSI as part of a product that is (b)(11)-certified, the developer must include source attributes and other requirements for that Predictive DSI.
Certified Health IT developers can find more information and considerations for certifying to the (b)(11) DSI criterion in the Decision Support Interventions (DSI) Resource Guide.

Paragraph (b)(11)(i) Decision support intervention interaction

Technical outcome – Interventions provided to a user must occur when a user is interacting with technology.

Clarifications:

This requirement is unchanged from the current requirement at § 170.315(a)(9)(i) and ensures that users can interact with decision support interventions described in this criterion using certified health IT.

Paragraph (b)(11)(i) Decision support intervention interaction

Technical outcome – Interventions provided to a user must occur when a user is interacting with technology.

Clarifications:

This requirement is unchanged from the current requirement at § 170.315(a)(9)(i) and ensures that users can interact with decision support interventions described in this criterion using certified health IT.

Paragraph (b)(11)(ii) Decision support configuration

Technical outcome – Health IT Modules must enable:

Interventions specified in paragraphs (b)(11)(iii) of this section to be configured by a limited set of identified users based on a user's role.
Interventions when a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care or referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.
A user to provide electronic feedback data for evidence-based decision support interventions selected via the capability provided in paragraph (b)(11)(iii)(A) of this section and make available such feedback data to a limited set of identified users for export, in a computable format, including at a minimum the intervention, action taken, user feedback provided (if applicable), user, date, and location.

Clarifications:

ONC clarifies that only evidence-based DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives must be supported by the “feedback loop” functionality described in § 170.315(b)(11)(ii)(C). Health IT Modules certified to § 170.315(b)(11) must support the capability for feedback data; however, use of this capability is at the discretion of users. Users are not required to provide electronic feedback. [see also 89 FR 1239]
Developers of a Health IT Module certified to § 170.315(b)(11) must make feedback data available to a limited set of identified users for export in a computable format. The Health IT Module is not required to export this feedback data to any user; rather, such an export of feedback data must be available to a limited set of identified users. [see also 89 FR 1239]
Certified Health IT developers and their customers are in the best position to determine the range of actions that are appropriate as part of feedback data. The Certification Program does not set forth a list of “actions taken.”
The (b)(11) certification requirements do not specify when or how feedback should be gathered. Real-time and post hoc workflows that include a separate application are acceptable.

Paragraph (b)(11)(ii) Decision support configuration

Technical outcome – Health IT Modules must enable:

Interventions specified in paragraphs (b)(11)(iii) of this section to be configured by a limited set of identified users based on a user's role.
Interventions when a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care or referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.
A user to provide electronic feedback data for evidence-based decision support interventions selected via the capability provided in paragraph (b)(11)(iii)(A) of this section and make available such feedback data to a limited set of identified users for export, in a computable format, including at a minimum the intervention, action taken, user feedback provided (if applicable), user, date, and location.

Clarifications:

ONC clarifies that only evidence-based DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives must be supported by the “feedback loop” functionality described in § 170.315(b)(11)(ii)(C). Health IT Modules certified to § 170.315(b)(11) must support the capability for feedback data; however, use of this capability is at the discretion of users. Users are not required to provide electronic feedback. [see also 89 FR 1239]
Developers of a Health IT Module certified to § 170.315(b)(11) must make feedback data available to a limited set of identified users for export in a computable format. The Health IT Module is not required to export this feedback data to any user; rather, such an export of feedback data must be available to a limited set of identified users. [see also 89 FR 1239]
Certified Health IT developers and their customers are in the best position to determine the range of actions that are appropriate as part of feedback data. The Certification Program does not set forth a list of “actions taken.”
The (b)(11) certification requirements do not specify when or how feedback should be gathered. Real-time and post hoc workflows that include a separate application are acceptable.

Paragraph (b)(11)(iii) Decision support intervention selection

Technical outcome – Enable a limited set of identified users to select (i.e., activate) electronic decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) that are:

Evidence-based DSIs and based on problems; medications; allergies and intolerances; at least one demographic specified in paragraph (a)(5)(i); laboratory; vital signs; Unique Device Identifier(s) for patient implantable device(s); and procedures; and
Predictive DSIs and based on any data expressed in the current USCDI standard(s)

Clarifications:

The Certification Program provides flexibility in defining the scope for a limited set of identified users. The limited set of identified users can be restricted to a smaller group of users that are specifically identified and granted the necessary privileges to use the capabilities in § 170.315(b)(11). The flexibility is such that any number and configuration of users may enable interventions such as administrators and select front-line clinician users as determined by the organization using the certified EHR. [see also 89 FR 1256]
We did not specify a singular mechanism or configuration to “enable selection” of Predictive DSIs. The conformance requirement is a functional requirement and parallels the “selection” function that’s in the current certification criterion at § 170.315(a)(9)(iii) for evidence-based DSIs. Developers of certified health IT must allow users the ability to enable selection of Predictive DSIs for customers looking to deploy self-developed Predictive DSIs and Predictive DSIs developed by other parties. [ see also 89 FR 1252]
Developers of certified health IT must allow customers to be able to select Predictive DSIs using any of the data elements included in the USCDI standards at § 170.213.
Health IT Modules supporting evidence based DSIs must have the ability to support “any,” meaning all, of the revised data referenced in paragraphs at § 170.315(b)(11)(iii)(A)(1) through (8). [see also 89 FR 1240]
Some of the data elements in § 170.315(b)(11)(iii)(A) are not part of USCDI v1 and are only in USCDI v3. For the time period before the expiration date of USCDI v1, Health IT Modules are not required to support evidence based DSIs that are based solely on data elements included in USCDI v3. However, beginning January 1, 2026, Health IT Modules must support DSIs based on all—meaning each—USCDI v3 data element listed in § 170.315(b)(11)(iii)(A). [see also 89 FR 1240]
Evidence-based DSIs are limited to only those DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives and that do not meet the definition for Predictive DSI. If a Certified Health IT developer with a Health IT Module certified to § 170.315(b)(11) enables a user to select such an evidence-based DSI, that evidence-based DSI would be subject to the requirements that apply to evidence-based DSIs within § 170.315(b)(11). [see also 89 FR 1240]
"Actively presented" stands in contrast to decision support that initiates an action without a user’s knowledge or occurs outside a user’s normal workflow. [see also 89 FR 1240]
ONC clarifies that “actively presented,” is inclusive of, but not limited to, “interruptive alerts,” and ONC clarifies that “related to the care a patient receives,” would include use cases related to direct patient care as well as use cases that impact care a patient receives. For example, a decision support rule that recommends a follow-up appointment within 12 weeks according to United States Preventive Services Taskforce (USPSTF) recommendations would be considered an evidence based DSI for purposes of Program requirements. [see also 89 FR 1241]

Paragraph (b)(11)(iii) Decision support intervention selection

Evidence-based DSIs and based on problems; medications; allergies and intolerances; at least one demographic specified in paragraph (a)(5)(i); laboratory; vital signs; Unique Device Identifier(s) for patient implantable device(s); and procedures; and
Predictive DSIs and based on any data expressed in the current USCDI standard(s)

Clarifications:

The Certification Program provides flexibility in defining the scope for a limited set of identified users. The limited set of identified users can be restricted to a smaller group of users that are specifically identified and granted the necessary privileges to use the capabilities in § 170.315(b)(11). The flexibility is such that any number and configuration of users may enable interventions such as administrators and select front-line clinician users as determined by the organization using the certified EHR. [see also 89 FR 1256]
We did not specify a singular mechanism or configuration to “enable selection” of Predictive DSIs. The conformance requirement is a functional requirement and parallels the “selection” function that’s in the current certification criterion at § 170.315(a)(9)(iii) for evidence-based DSIs. Developers of certified health IT must allow users the ability to enable selection of Predictive DSIs for customers looking to deploy self-developed Predictive DSIs and Predictive DSIs developed by other parties. [ see also 89 FR 1252]
Developers of certified health IT must allow customers to be able to select Predictive DSIs using any of the data elements included in the USCDI standards at § 170.213.
Health IT Modules supporting evidence based DSIs must have the ability to support “any,” meaning all, of the revised data referenced in paragraphs at § 170.315(b)(11)(iii)(A)(1) through (8). [see also 89 FR 1240]
Some of the data elements in § 170.315(b)(11)(iii)(A) are not part of USCDI v1 and are only in USCDI v3. For the time period before the expiration date of USCDI v1, Health IT Modules are not required to support evidence based DSIs that are based solely on data elements included in USCDI v3. However, beginning January 1, 2026, Health IT Modules must support DSIs based on all—meaning each—USCDI v3 data element listed in § 170.315(b)(11)(iii)(A). [see also 89 FR 1240]
Evidence-based DSIs are limited to only those DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives and that do not meet the definition for Predictive DSI. If a Certified Health IT developer with a Health IT Module certified to § 170.315(b)(11) enables a user to select such an evidence-based DSI, that evidence-based DSI would be subject to the requirements that apply to evidence-based DSIs within § 170.315(b)(11). [see also 89 FR 1240]
"Actively presented" stands in contrast to decision support that initiates an action without a user’s knowledge or occurs outside a user’s normal workflow. [see also 89 FR 1240]
ONC clarifies that “actively presented,” is inclusive of, but not limited to, “interruptive alerts,” and ONC clarifies that “related to the care a patient receives,” would include use cases related to direct patient care as well as use cases that impact care a patient receives. For example, a decision support rule that recommends a follow-up appointment within 12 weeks according to United States Preventive Services Taskforce (USPSTF) recommendations would be considered an evidence based DSI for purposes of Program requirements. [see also 89 FR 1241]

Paragraph (b)(11)(iv) Source attributes (categories)

Technical outcome – Source attributes listed in paragraphs (b)(11)(iv)(A) and (B) of this section must be supported.

Clarifications:

The HTI-1 Final Rule discusses “source attributes” as “categories of technical performance and quality information” that must be supported for both evidence-based and predictive DSIs. [see also 89 FR 1196]
While Health IT Modules certified to § 170.315(b)(11) must support the categories or the “fields” for each source attribute, developers of certified health IT are not necessarily responsible for the content related to each source attribute listed at § 170.315(b)(11)(iv)(A) and (B). [see also 89 FR 1256]
The Certification Program does not prescribe a best-practices format in which source attribute information should be displayed. Developers of certified health IT that are certified to § 170.315(b)(11) should work with their customers to determine the best format and structure of source attribute information. [see also 89 FR 1264]

Paragraph (b)(11)(iv) Source attributes (categories)

Technical outcome – Source attributes listed in paragraphs (b)(11)(iv)(A) and (B) of this section must be supported.

Clarifications:

The HTI-1 Final Rule discusses “source attributes” as “categories of technical performance and quality information” that must be supported for both evidence-based and predictive DSIs. [see also 89 FR 1196]
While Health IT Modules certified to § 170.315(b)(11) must support the categories or the “fields” for each source attribute, developers of certified health IT are not necessarily responsible for the content related to each source attribute listed at § 170.315(b)(11)(iv)(A) and (B). [see also 89 FR 1256]
The Certification Program does not prescribe a best-practices format in which source attribute information should be displayed. Developers of certified health IT that are certified to § 170.315(b)(11) should work with their customers to determine the best format and structure of source attribute information. [see also 89 FR 1264]

Paragraph (b)(11)(v) Source attribute access and modification (content)

Technical outcome – The Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information specified in paragraphs (b)(11)(iv)(A) and (B) of this section. The Health IT Module must enable a limited set of identified users to record, change, and access source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section.

Clarifications:

The Certification Program establishes a set of four capabilities that Health IT Modules must support related to source attributes. These capabilities include: (1) access to complete and up-to-date plain language descriptions; (2) indicate when information is not available for specified source attributes; (3) record source attribute information; and (4) change source attribute information. [see also 89 FR 1256]
Certified Health IT developers are not required to receive, acquire, or otherwise obtain source attribute information for an other party’s Predictive DSI unless such Predictive DSI is supplied by the developer of certified health IT as part of its Health IT Module. [see also 89 FR 1253]
Certified Health IT developers are not accountable for populating source attribute information for Predictive DSIs they do not supply as part of their Health IT Module, including other-party-developed Predictive DSIs used within their certified health IT. This is true even if the customer leverages data from the developer of certified health IT’s Health IT Module and even if the output from an other party’s Predictive DSI is delivered to or through a Health IT Module into a customer’s clinical workflow. [see also 89 FR 1253]
The Certification Program defines “other party” to mean any party that develops a DSI, a model, or an algorithm that is used by a DSI, and is not the Certified Health IT developer or a subsidiary of the Certified Health IT developer. [see also 89 FR 1253]
ONC interprets “supplied by” to include interventions authored or developed by the health IT developer as well as interventions authored or developed by an other party that the health IT developer includes as part of its Health IT Module, such as stated in the comments “when entities have contracts specifically covering the enablement and use of such technologies.” The concept of “supplied by” means that the Certified Health IT developer has taken on stewardship and accountability for that Predictive DSI for the purposes of the Health IT Module. ONC interprets “as part of its Health IT Module” to mean that the Certified Health IT developer has explicitly offered or provided its customers the technical capability to use or support a Predictive DSI, regardless of whether the Predictive DSI was developed by the developer of certified health IT or by an other party. [see also 89 FR 1253]
“As part of its Health IT Module" includes any supplied DSIs that are a part of a (b)(11)-certified, CHPL-listed product. This means that if a developer supplies a Predictive DSI as part of a product that is (b)(11)-certified, the developer must include source attributes and other requirements for that Predictive DSI.
For purposes of requirements in § 170.315(b)(11) a subsidiary of a Certified Health IT developer that develops a Predictive DSI would be considered the same as if the subsidiary were the developer of certified health IT, subjecting Predictive DSIs developed by the subsidiary to the same requirements as a Predictive DSI supplied by a developer of certified health IT as part of its Health IT Module. [see also 89 FR 1253]
The concept of “plain language description,” in § 170.315(b)(11)(v)(A) means language that the intended audience can readily understand and use because that language is clear, concise, well-organized, accurately describes the information, and follows other best practices of plain language writing. [see also 89 FR 1257]
The developer of a Health IT Module must indicate when information is not available for review for specific source attributes that are pertinent to the external validation of Predictive DSIs and information related to deployed Predictive DSIs at § 170.315(b)(11)(v)(A)(2). These include source attributes at § 170.315(b)(11)(iv)(B)(6); (b)(11)(iv)(B)(7)(iii), (iv), and (v); (b)(11)(iv)(B)(8)(ii) and (iv); and (b)(11)(iv)(B)(9). [see also 89 FR 1269]
ONC understands that health IT developers may not have access to complete source attribute information for all decision support interventions (DSIs) they supply, especially for DSIs developed and deployed many years prior. In cases like this and others where source attribute information is not available, a Health IT Module certified to § 170.315(b)(11) should clearly indicate “Unknown” when a source attribute listed is not available for the user to review. While we understand that in some cases the source attributes may not be available, we note that we expect health IT developers to exercise due diligence before making a determination that a source attribute’s information is “Unknown.” We also note that developers certified to § 170.315(b)(11) are required under § 170.402(b) Assurances Maintenance of Certification, starting January 1, 2025, and on an ongoing basis thereafter, to review and update as necessary source attribute information. Where source attribute information later becomes known, developers would be expected to make such information available to their end users. See 89 FR 1245.
In cases where a DSI is not based on published clinical guideline but local needs, the bibliographic citation § 170.315(b)(11)(iv)(A)(1) and the developer of the intervention § 170.315(b)(11)(iv)(A)(2) may be the same.
The Certification Program has not established requirements for specific measures of validity or fairness. [see also 89 FR 1262]
Developers may indicate that the relevant information for specific source attributes may not be available nor re-creatable. For example, Predictive DSIs that use models provided through peer-reviewed literature, such as Atherosclerotic Cardiovascular Disease (ASCVD), estimated glomerular filtration rate (eGFR), acute physiology and chronic health evaluation IV (APACHE IV), and the LACE+ models measuring hospital length of stay (L), admission acuity (A), comorbid conditions (C), emergency department utilization within six months before the admission (E) as well as sex, age and hospital, may not have access to training data that would allow them to provide a description of demographic representativeness. In such scenarios, developers may indicate the that the relevant information is not available and cannot be replicated. [see also 89 FR 1269]
Certified Health IT developers are responsible to provide the functionality to enable access and modification to source attributes but are not responsible for the content that may be recorded, changed, or accessed by these users. [see also 89 FR 1271]
Certified Health IT developers are required to provide users the capability to populate source attributes for Predictive DSIs self-developed by customers and Predictive DSIs developed by other parties to be available within the Health IT Module.
Certified Health IT developers are not responsible for the accuracy or use of source attribute information that is modified by their users. Rather, Certified Health IT developers are required to have Health IT Modules that support the capability for their users to author or revise source attribute information. [see also 89 FR 1271]
The Certification Program requires that developers indicate when an evidence-based DSI uses patient demographic, social determinants of health (SDOH), and health status assessment data elements in § 170.315(b)(11)(iv)(A)(5) through (13). Consistent with the dates established in § 170.213, Health IT Modules must indicate when USCDI v1 data elements are used in evidence based DSIs up to and including December 31, 2025. Beginning January 1, 2026, Health IT Modules must indicate when USCDI v3 data elements are used according to § 170.315(b)(11)(11)(iv)(A)(5)-(13). [see also 89 FR 1258]
For source attributes in § 170.315(b)(11)(iv)(A)(5)-(13), use of the data element is required to be disclosed. Identifying that one of those data elements is not used, is not required.

Paragraph (b)(11)(v) Source attribute access and modification (content)

Clarifications:

The Certification Program establishes a set of four capabilities that Health IT Modules must support related to source attributes. These capabilities include: (1) access to complete and up-to-date plain language descriptions; (2) indicate when information is not available for specified source attributes; (3) record source attribute information; and (4) change source attribute information. [see also 89 FR 1256]
Certified Health IT developers are not required to receive, acquire, or otherwise obtain source attribute information for an other party’s Predictive DSI unless such Predictive DSI is supplied by the developer of certified health IT as part of its Health IT Module. [see also 89 FR 1253]
Certified Health IT developers are not accountable for populating source attribute information for Predictive DSIs they do not supply as part of their Health IT Module, including other-party-developed Predictive DSIs used within their certified health IT. This is true even if the customer leverages data from the developer of certified health IT’s Health IT Module and even if the output from an other party’s Predictive DSI is delivered to or through a Health IT Module into a customer’s clinical workflow. [see also 89 FR 1253]
The Certification Program defines “other party” to mean any party that develops a DSI, a model, or an algorithm that is used by a DSI, and is not the Certified Health IT developer or a subsidiary of the Certified Health IT developer. [see also 89 FR 1253]
ONC interprets “supplied by” to include interventions authored or developed by the health IT developer as well as interventions authored or developed by an other party that the health IT developer includes as part of its Health IT Module, such as stated in the comments “when entities have contracts specifically covering the enablement and use of such technologies.” The concept of “supplied by” means that the Certified Health IT developer has taken on stewardship and accountability for that Predictive DSI for the purposes of the Health IT Module. ONC interprets “as part of its Health IT Module” to mean that the Certified Health IT developer has explicitly offered or provided its customers the technical capability to use or support a Predictive DSI, regardless of whether the Predictive DSI was developed by the developer of certified health IT or by an other party. [see also 89 FR 1253]
“As part of its Health IT Module" includes any supplied DSIs that are a part of a (b)(11)-certified, CHPL-listed product. This means that if a developer supplies a Predictive DSI as part of a product that is (b)(11)-certified, the developer must include source attributes and other requirements for that Predictive DSI.
For purposes of requirements in § 170.315(b)(11) a subsidiary of a Certified Health IT developer that develops a Predictive DSI would be considered the same as if the subsidiary were the developer of certified health IT, subjecting Predictive DSIs developed by the subsidiary to the same requirements as a Predictive DSI supplied by a developer of certified health IT as part of its Health IT Module. [see also 89 FR 1253]
The concept of “plain language description,” in § 170.315(b)(11)(v)(A) means language that the intended audience can readily understand and use because that language is clear, concise, well-organized, accurately describes the information, and follows other best practices of plain language writing. [see also 89 FR 1257]
The developer of a Health IT Module must indicate when information is not available for review for specific source attributes that are pertinent to the external validation of Predictive DSIs and information related to deployed Predictive DSIs at § 170.315(b)(11)(v)(A)(2). These include source attributes at § 170.315(b)(11)(iv)(B)(6); (b)(11)(iv)(B)(7)(iii), (iv), and (v); (b)(11)(iv)(B)(8)(ii) and (iv); and (b)(11)(iv)(B)(9). [see also 89 FR 1269]
ONC understands that health IT developers may not have access to complete source attribute information for all decision support interventions (DSIs) they supply, especially for DSIs developed and deployed many years prior. In cases like this and others where source attribute information is not available, a Health IT Module certified to § 170.315(b)(11) should clearly indicate “Unknown” when a source attribute listed is not available for the user to review. While we understand that in some cases the source attributes may not be available, we note that we expect health IT developers to exercise due diligence before making a determination that a source attribute’s information is “Unknown.” We also note that developers certified to § 170.315(b)(11) are required under § 170.402(b) Assurances Maintenance of Certification, starting January 1, 2025, and on an ongoing basis thereafter, to review and update as necessary source attribute information. Where source attribute information later becomes known, developers would be expected to make such information available to their end users. See 89 FR 1245.
In cases where a DSI is not based on published clinical guideline but local needs, the bibliographic citation § 170.315(b)(11)(iv)(A)(1) and the developer of the intervention § 170.315(b)(11)(iv)(A)(2) may be the same.
The Certification Program has not established requirements for specific measures of validity or fairness. [see also 89 FR 1262]
Developers may indicate that the relevant information for specific source attributes may not be available nor re-creatable. For example, Predictive DSIs that use models provided through peer-reviewed literature, such as Atherosclerotic Cardiovascular Disease (ASCVD), estimated glomerular filtration rate (eGFR), acute physiology and chronic health evaluation IV (APACHE IV), and the LACE+ models measuring hospital length of stay (L), admission acuity (A), comorbid conditions (C), emergency department utilization within six months before the admission (E) as well as sex, age and hospital, may not have access to training data that would allow them to provide a description of demographic representativeness. In such scenarios, developers may indicate the that the relevant information is not available and cannot be replicated. [see also 89 FR 1269]
Certified Health IT developers are responsible to provide the functionality to enable access and modification to source attributes but are not responsible for the content that may be recorded, changed, or accessed by these users. [see also 89 FR 1271]
Certified Health IT developers are required to provide users the capability to populate source attributes for Predictive DSIs self-developed by customers and Predictive DSIs developed by other parties to be available within the Health IT Module.
Certified Health IT developers are not responsible for the accuracy or use of source attribute information that is modified by their users. Rather, Certified Health IT developers are required to have Health IT Modules that support the capability for their users to author or revise source attribute information. [see also 89 FR 1271]
The Certification Program requires that developers indicate when an evidence-based DSI uses patient demographic, social determinants of health (SDOH), and health status assessment data elements in § 170.315(b)(11)(iv)(A)(5) through (13). Consistent with the dates established in § 170.213, Health IT Modules must indicate when USCDI v1 data elements are used in evidence based DSIs up to and including December 31, 2025. Beginning January 1, 2026, Health IT Modules must indicate when USCDI v3 data elements are used according to § 170.315(b)(11)(11)(iv)(A)(5)-(13). [see also 89 FR 1258]
For source attributes in § 170.315(b)(11)(iv)(A)(5)-(13), use of the data element is required to be disclosed. Identifying that one of those data elements is not used, is not required.

Paragraph (b)(11)(vi) Intervention risk management

Technical outcome – Intervention risk management (IRM) practices must be applied for each Predictive Decision Support Intervention supplied by the health IT developer as part of its Health IT Module.

Clarifications:

Certified Health IT developers must apply IRM practices for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, including risk analysis, risk mitigation, and governance. [see also 89 FR 1272]
The Certification Program encourages the use of a framework to help facilitate IRM. For example, developers may utilize National Institute of Standards and Technology (NIST) AI Risk Management Framework concepts and emphasis areas. However, conformance with this certification criterion does not require the use of any particular framework, approach, or methodology for providing information about risk management practices. [see also 89 FR 1273]
Developers are not required to review risk management information from other parties nor include the risk management information from other parties as part of the IRM documentation requirement. [see also 89 FR 1273]
Summary information regarding a certified health IT developer’s IRM practices need to be submitted to the developer’s ONC–ACB for review prior to issuing a certification.
The Certification Program gives Certified Health IT developers flexibility to determine the information and the level of detail that would be useful to inform potential users of whether a model is fair, appropriate, valid, effective, and safe (FAVES) without providing information at the level of detail that might constitute proprietary information. [see also 89 FR 1280]
Summary information of IRM practices requirement do not need to include public disclosure of specific information on code, model tuning, parameter or hyperparameter selection, or details on how individual input or output variables were selected or operationalized, which we understand to form the underpinnings of developers concerns related to intellectual property. [see also 89 FR 1280]

Paragraph (b)(11)(vi) Intervention risk management

Clarifications:

Certified Health IT developers must apply IRM practices for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, including risk analysis, risk mitigation, and governance. [see also 89 FR 1272]
The Certification Program encourages the use of a framework to help facilitate IRM. For example, developers may utilize National Institute of Standards and Technology (NIST) AI Risk Management Framework concepts and emphasis areas. However, conformance with this certification criterion does not require the use of any particular framework, approach, or methodology for providing information about risk management practices. [see also 89 FR 1273]
Developers are not required to review risk management information from other parties nor include the risk management information from other parties as part of the IRM documentation requirement. [see also 89 FR 1273]
Summary information regarding a certified health IT developer’s IRM practices need to be submitted to the developer’s ONC–ACB for review prior to issuing a certification.
The Certification Program gives Certified Health IT developers flexibility to determine the information and the level of detail that would be useful to inform potential users of whether a model is fair, appropriate, valid, effective, and safe (FAVES) without providing information at the level of detail that might constitute proprietary information. [see also 89 FR 1280]
Summary information of IRM practices requirement do not need to include public disclosure of specific information on code, model tuning, parameter or hyperparameter selection, or details on how individual input or output variables were selected or operationalized, which we understand to form the underpinnings of developers concerns related to intellectual property. [see also 89 FR 1280]

Certification of Health IT

Health Information Technology Advisory Committee (HITAC)

Health Equity

HTI-1 Final Rule

HTI-2 Proposed Rule

Information Blocking

Interoperability

Patient Access to Health Records

Clinical Quality and Safety

Health IT and Health Information Exchange Basics

Health IT in Health Care Settings

Health IT Resources

Laws, Regulation, and Policy

ONC Funding Opportunities

ONC HITECH Programs

Privacy, Security, and HIPAA

Scientific Initiatives

Standards & Technology

Usability and Provider Burden

§170.315(b)(11) Decision support interventions

Testing components

Certification Companion Guide: Decision support interventions

Applies to Entire Criterion

Applies to Entire Criterion

Paragraph (b)(11)(i) Decision support intervention interaction

Paragraph (b)(11)(i) Decision support intervention interaction

Paragraph (b)(11)(ii) Decision support configuration

Paragraph (b)(11)(ii) Decision support configuration

Paragraph (b)(11)(iii) Decision support intervention selection

Paragraph (b)(11)(iii) Decision support intervention selection

Paragraph (b)(11)(iv) Source attributes (categories)

Paragraph (b)(11)(iv) Source attributes (categories)

Paragraph (b)(11)(v) Source attribute access and modification (content)

Paragraph (b)(11)(v) Source attribute access and modification (content)

Paragraph (b)(11)(vi) Intervention risk management

Paragraph (b)(11)(vi) Intervention risk management

Connect with us: