Decision support interventions

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.
• While the (b)(11) criterion is eligible for SVAP as outlined in 45 CFR 170.405(b)(8-9) and reflected in the CCG table, the criterion was not included in the 2024 approved standards list approved by the National Coordinator in June 2024. For this reason, the USCDI standard referenced in (b)(11) is not eligible for SVAP as part of the 2024 SVAP cycle.
• Consistent with Executive Order (EO) 14168 and OPM guidance, Health IT Modules certifying and/or currently certified to certification criteria that cross-reference the USCDI standard at 45 CFR 170.213 are only required to demonstrate the capability to categorize data on individuals for the sex data element in accordance with the following SNOMED CT® codes:
  • 248152002 |Female (finding)| and
  • 248153007 |Male (finding)|
• Further, these Health IT Modules are no longer required to support the following USCDI data elements for purposes of certification:
  • Sexual orientation in USCDI version 4;
  • Gender identity in USCDI version 4;
  • Sex parameter for clinical use in USCDI version 5;
  • Name to use in USCDI version 5;
  • Pronouns in USCDI version 5.

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.

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.

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]

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]

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.

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]