From (a)(9) to (b)(11) – 7 Key Differences You Must Know
The healthcare industry is constantly evolving. With this evolution comes the need for new or revised standards and regulations to ensure that technology keeps pace with clinical advancements. One of the most significant regulatory updates is the Health Data, Technology, and Interoperability (HTI-1) Final Rule, which represents a major shift in how healthcare providers, electronic health records (EHRs), and health IT developers will approach interoperability and decision support.
The HTI-1 Final Rule focuses on improving the flow of health data across systems, ensuring that healthcare organizations can securely share and use critical patient information. At the heart of this rule, and an intended use for the exchanged data, is the shift toward more advanced, predictive, and flexible decision support mechanisms, designed to enhance the quality of care and patient safety. This includes the transition from the older criterion of (a)(9) Clinical Decision Support (CDS) to the more contemporary and robust (b)(11) Decision Support Interventions (DSI), which brings with it significant advancements in how healthcare technology interacts with clinical data.
As we move from (a)(9) to (b)(11) under the HTI-1 Final Rule, the differences between these two criteria are substantial, driving significant improvements in how decision support is delivered within healthcare systems.
Here is the TL;DR version of the key differences:
(a)(9) Clinical Decison Support (CDS) | (b)(11) Decision Support Interventions (DSI) | |
---|---|---|
1. Data Set Used | Common Clinical Data Set (CCDS) | U.S. Core Data for Interoperability (USCDI) v1 |
2. Third-Party App Integration | Embedded in the EHR with limited flexibility | Allows incorporation of third-party apps - open and modular |
3. Types of Decision Support | Mainly evidence-based drawing from clinical guidelines | Includes both evidence-based and predictive (AI, ML) decision support |
4. Bibliographic References and Source Attributes | Fixed InfoButton provides limited context | Editable source attributes enable adjustment to specific clinical situations |
5. Feedback Collection and Reporting | Ability to dismiss alerts, but no feedback capability | Enables feedback loop for continuous improvement- feedback collection, alerts dismissal, and feedback export for analytics |
6. Scope of Decision Support | Primarily clinical decision-making with limited scope | Covers the entire workflow of a patient encounter - clinical decisions, patient interactions, documentation, and care coordination |
7. Safety-Enhanced Design | Basic safety-enhanced design with minimal safety | Elaborate safety-enhanced design for improving usability and minimizing errors |
1. Data Set Used
(a)(9) - CDS: Relied on the Common Clinical Data Set (CCDS), which had more limited, standardized data elements. This restricted the depth of information available for decision-making.
(b)(11) - DSI: Utilizes U.S. Core Data for Interoperability (USCDI) Version 1 moving to version 3 in 2025, incorporating a more comprehensive dataset that includes elements like social determinants of health (SDOH). This fosters greater interoperability and more detailed clinical insights.
2. Third-Party App Integration
(a)(9) – CDS: Was typically embedded directly in the EHR, limiting customization and flexibility. Upon reflection, we did not see CDS used to a great degree.
(b)(11)—DSI allows for the incorporation of third-party apps, offering a more open and modular architecture. This enables healthcare organizations to integrate advanced, customizable decision-support tools tailored to their needs.
3. Types of Decision Support
(a)(9) – CDS: Focused only on evidence-based interventions that responded to pre-existing clinical guidelines but lacked adaptability.
(b)(11)—DSI: This introduces Predictive Decision Support Interventions (PDSI), allowing the system to provide not only evidence-based recommendations but also predictive analytics that draw on AI and Machine Learning (ML) trends, which is crucial for modern healthcare.
4. Bibliographic References and Source Attributes
(a)(9) – CDS: Featured static bibliographic references that were triggered by an InfoButton, providing limited context for clinicians.
(b)(11) – DSI: Includes editable source attributes, with 13 source attributes for evidence-based interventions and 31 attributes for predictive DSI. This flexibility enables clinicians to fine-tune or update their decision-making tools and adjust references as needed for specific clinical situations.
5. Feedback Collection and Reporting
(a)(9) – CDS: Had a basic function allowing clinicians to dismiss alerts, but no structured feedback mechanisms.
(b)(11) – DSI: Enhances this by requiring the ability to collect feedback, dismiss alerts, and export the feedback in a computer-reportable format. This creates a feedback loop to continually improve the quality of decision-support interventions and provide insight into clinician behavior. This process can contribute to reducing Alert Fatigue.
6. Scope of Decision Support
(a)(9) – CDS: This criterion focused primarily on clinical decision-making. It provided tools and guidelines to assist healthcare providers in making clinical decisions but was limited in scope, addressing only specific clinical elements during patient encounters.
(b)(11) – DSI: In contrast, (b)(11) represents a broader approach as it encompasses Decision Support Interventions. This means it covers interventions throughout the entire workflow of a patient encounter, integrating clinical, administrative, and operational aspects. (b)(11) ensures that healthcare providers have the support they need not only for clinical decisions but also for managing patient interactions, documentation, and care coordination.
7. Safety-Enhanced Design
(a)(9) – CDS: Had a basic safety-enhanced design, which covered minimal safety or risk features.
(b)(11) – DSI: Introduces a more elaborate safety-enhanced design, focused on improving usability and minimizing errors through better interface designs and safety features. (b)(11) also add governance, risk mitigation, and analysis to the new criterion.
MeldRx: Nation’s first ONC HTI-1 Certified Plug-and-Play (b)(11) Solution
As healthcare organizations and EHRs look to comply with the new HTI-1 criteria, Darena Solutions stands out with its unique ONC-certified (b)(11) module under the brand name MeldRx. This solution incorporates all the advanced features of (b)(11), including third-party app integration, predictive DSI access mechanisms, editable source attributes, and a comprehensive feedback process (as shown in the video) into a plug-and-play application.
What makes MeldRx particularly advantageous for EHRs is they don’t need to certify the (b)(11) criteria on their own, enabling seamless integration with their EHR systems. Additionally, the solution leverages the EHR Launch functionally of the (g)(10) criterion, ensuring compliance without the additional cost or effort of separate certification processes.
It is worth noting that although (a)(9) CDS criterion did not require Real-World Test (RWT) Plans and Results, the new and improved (b)(11) DSI criterion does. RWT plans and results are required as a part of the Conditions and Maintenance of Certification under HTI-1. This ensures that the DSI solutions are not only theoretically sound but also proven effective in real-world healthcare settings, giving healthcare organizations and providers greater confidence in the reliability and utility of their decision-support tools. With MeldRx plug-and-play (b)(11) solution, you can offload the burden of RWT compliance.
With this solution, healthcare organizations can quickly and easily adopt the enhanced decision support features of (b)(11), improving both interoperability and the quality of care they provide, while EHRs benefit from faster compliance and reduced development overhead.
Transitioning from (a)(9) to (b)(11) can be easy
Let us show you how.
Partner with us to enhance the DSI functionality within your EHR or organization to encourage the responsible use of AI apps.