The journey from proposed rulemaking to the enactment of final regulations is a critical process. On December 13th, 2023, the ONC Cures Act HTI-1 Proposed Rule completed this important phase in its development when the ONC released the HTI-1 Final Rule. It officially takes effect on February 8, 2024, and sets key enforcement deadlines in 2025, 2026, and beyond. Saying that EHR developers and their healthcare provider customers will need to start planning now to effectively prepare for the multiple waves of compliance deadlines arriving over the next few years.
To help you prepare, we’ve highlighted several of the most pertinent changes found in the HTI-1 Final Rule, along with suggesting various methods that can help your organization achieve timely compliance with the enforcement deadlines. The most effective way to start this process is to explore the original HTI-1 proposed rule, so we can better understand what’s changed throughout the HTI-1 Final Rule and what those amendments mean for compliance.
The HTI-1 Proposed Rule covered the following core requirements:
- Decision Support Intervention
- USCDI Version 3 Updates
- Insights Condition Reporting
- Electronic Case Reporting Update
- Minimum Standard Code Set
- Patient Request for Data Restriction
- Information Blocking Update
Each of these requirement areas is essential to ensuring the success of the HTI-1 initiative, which is why the ONC conscientiously implemented changes to their language in the HTI-1 Final Rule. Let’s examine one of the most significant changes by dissecting the final version of the “Decision Support Intervention (DSI)” requirement.
Decision Support Intervention (DSI)
Maintaining The DSI Enforcement Date
The most discussed section of HTI-1 is the new DSI criterion—(b)(11). One of the many important aspects of this regulation is that it represents the first substantial revision to the Certification Program’s requirements for Clinical Decision Support (CDS) functionality since 2015.
Clinical Decision Support has been a standard requirement in the “Base EHR” definition for Certified Electronic Health Record Technology (CEHRT). This continues under the HTI-1 Final Rule, with the ONC continuing to define “Base EHR” as having the capacity to:
(i) provide clinical decision support;
(ii) support physician order entry;
(iii) capture and query information relevant to healthcare quality;
(iv) exchange electronic health information with, and integrate such information from other sources
As such, all Base EHR-certified developers that currently meet the requirements of (a)(9) must prepare to address the new requirements of its replacement, (b)(11). Complying with all Base EHR criteria is necessary to enable EHR customers to satisfy “Promoting Interoperability” requirements for CMS Medicare reimbursements.
The HTI-1 Proposed Rule stated that the new Decision Support Intervention (DSI) rule (b)(11) will replace the CDS rule (a)(9) by the start of 2025. The ONC kept this enforcement date in place, giving Health IT developers until January 1, 2025, to comply with the rule’s complete list of new requirements.
New Predictive DSI Category
The biggest change from (a)(9) to (b)(11) is the addition of the “predictive” DSI category (PDSI), encompassing software capabilities associated with artificial intelligence (AI) and machine learning. As such, EHR developers must now support two types of DSI—evidence-based and predictive. They are not required to “supply” predictive DSI, but if they do, additional requirements apply. The HTI-1 Final Rule defines PDSI to mean the following:
"Technology that supports decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis."
In explanatory guidance, the ONC breaks down its definition of PDSI in a 3-prong test:
(1) Supports decision-making based on algorithms or models;
(2) Derive[s] relationships from training data; and
(3) Results in prediction, classification, recommendation, evaluation, or analysis.
The second prong will often be the key distinguishing factor – if the decision support isn’t driven by training data (e.g., a learning model trained on a data set), it is outside the PDSI definition.
Differing Requirements for the Two DSI Categories
A key change in the HTI-1 Final Rule is how it sets differing requirements for the two categories of DSI. For example, the HTI-1 Proposed Rule had included a requirement for all DSIs to enable its users to provide electronic feedback data. The HTI-1 Final Rule limits this feedback mechanism requirement to evidence-based DSI only.
By contrast, the HTI-1 Proposed Rule had imposed risk management and governance program requirements for predictive DSI – applying it to PDSI that “enables or interfaces with” the EHR.
Many EHR developers expressed concerns with the scope of this requirement, specifically the “interfaces with” language after the PDSI requirements of the HTI-1 Proposed Rule were released. Based on this input, the ONC revised the HTI-1 Final rule to establish that the risk management program requirements apply only to Predictive DSIs “supplied by” the EHR developer as part of their certified health IT.
This new language recognizes that many PDSI capabilities will be supplied by healthcare provider organizations rather than EHRs, integrating with the PDSI enablement support offered by certified EHRs. As such, risk management responsibility for these DSIs would be difficult for the EHR developer and should logically be handled elsewhere (e.g., by the provider or their PDSI development partner).
In short, EHR developers are not required to supply PDSI capabilities, but they must support the enablement of these capabilities. If they directly supply PDSIs, however, they must conduct and document a risk program for the PDSIs that includes:
(1) Risk analysis
(2) Risk mitigation
(3) Risk governance
DSI source attributes – support and management.
Developers must support a list of source attributes for evidence-based DSI, largely but not entirely unchanged from the (a)(9) rule (some USCDI v3 data elements have been added to the list; see USCDI v3 discussion below).
The HTI-1 Final Rule provides a separate new set of source attribute requirements for predictive DSI, including many data elements intended to enable independent understanding, assessment, and management of potential risk factors by end users. An in-depth discussion of the source attributes requirements is beyond the scope of this article, but suffice it to say, this is a significant area of complexity in the new rule, for which developers may need to consult with subject matter experts.
Reading through the HTI-1 Final Rule, it is easy to see the ONC applied additional emphasis on facilitating first-of-its-kind transparency requirements for the use of artificial intelligence (AI) and predictive algorithms in the health-IT sector.
Due to the breadth and depth of the new DSI requirements, EHR developers who wish to stay in compliance will need to start preparing today to ensure they can satisfy the requirements with an end-of-2024 deadline.
Webinar
Next, let’s look at the HTI-1 Final Rule’s new requirements for data and other related standards, including implementation guides.
USCDI Version 3 and New Versions of Standards Guides
The HTI-1 Final Rule mandates that EHR developers adopt USCDI v3 as the new baseline data standard within the ONC Health IT Certification Program by January 1, 2026. The critical difference is the change in enforcement date from January 1, 2025, with the HTI-1 Final Rule providing developers one additional year to upgrade to USCDI v3 across many EHR product areas.
The adoption of USCDI v3 is incorporated into several implementation guides and standards documents, all of which will be new required versions as of January 1, 2026. The official new standards versions are:
- United States Core Data for Interoperability Version 3 (USCDI v3)
- HL7® FHIR® US Core Implementation Guide STU 6.1.0
- HL7® SMART App Launch Implementation Guide Release 2.0.0, including mandatory support for the “Capability Sets” of “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch”; all “Capabilities” as defined in “8.1.2 Capabilities,” excepting the “permission-online” capability; “Token Introspection” as defined in “7 Token Introspection”
- HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1
The v3 upgrade will impact multiple certification criteria, meaning EHR developers will need to focus on testing to validate continuing compliance with the criteria requirements. Design and implementation impacts start at the data layer and will extend across transport and presentation layers. As noted in our previous article regarding the HTI-1 Proposed Rule, the changes to data elements and classes from USCDI v1 to v3 include:
- 47 new elements
- 30 elements with updates to vocabulary standards
- Five new classes
- Five elements moved to different classes
- Two deleted classes
- Three renamed classes
While deeper analysis and design across certified capabilities and other product functionality will clearly be required, there are several immediate cases where USCDI v3 changes will come into play.
For example, the requirements for demographics have been set forth in (a)(5), and due to significant updates for demographic data in USCDI v3, (a)(5) is revised in HTI-1 and now entitled “Patient Demographics and Observations”. Essentially, (a)(5) sets requirements that enable users to “record, change, and access” this data. Developers must extend their UX to cover the USCDI v3 data additions and changes.
Further examples of USCDI v3 changes that will extend to user-facing capabilities:
- (g)(10): The Standardized API for Patient and Population Services extends to all EHI, with a few defined exceptions. USCDI v3 data changes will need to be implemented and mapped into FHIR servers, requiring coordination with relied-upon software partners as well.
- (b)(11); See prior discussion of this new DSI requirement. Source attribute support requirements extend to all USCDI v3 data, referencing the USCDI standard in 170.213. That section does not require compliance with v3 for 2 years, but development to meet DSI requirements must be done in 1 year. So, developers must consider – do you release (b)(11) DSI support by the end of 2024 based on USCDI v1, and then pursue another workstream in 2025 to revise DSI capabilities to support additional v3 attributes and changes?
In addition to USCDI v3 and the other new standards versions mentioned above, new versions (minimum standards) have been adopted for Code Sets (SNOMED CT® and LOINC), with varying compliance dates. An understanding of these code set requirements is important, and beyond the scope of this article.
EHR developers should be cautious about using two year compliance window as their rationale to shrink compliance development plans during 2024. It is our belief the ONC provided an additional year due to the extensive amount of time they project it will take EHR developers to migrate all certified functions to USCDI v3 successfully, together with other new requirements in the two year compliance window.
Another important new requirement that must be met in the two year compliance window is the Insights reporting requirement. It brings more roadmap planning considerations into the same period with the requirements previously discussed.
Get Expert Advice
Insights Condition Requirement
The Insights Condition is a new reporting mandate – a “Condition of Certification” – that requires EHRs, starting January 2026, to begin collecting data for full annual periods:
- Number of unique individuals who accessed their EHR using technology certified to “standardized API for patient population services” certification criterion under § 170.315(g)(10);
- Number of unique individuals who accessed their EHR using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1);
- Number of unique individuals who accessed their EHR using any method.
he report metrics will be phased in over three consecutive years, and EHRs will have six months after each reporting year to build and deliver their reports with the required metrics. Initially, the HTI-1 Proposed Rule stated that the first collection period would begin in April 2024. The HTI-1 Final Rule changed the data collection start date to January 1, 2026, with the first responses due July 2027.
The Final Rule maintained a key limitation on the applicability of the Insights requirements. Only EHR developers that have at least “50 hospital sites or 500 individual clinician users across the developer’s certified health IT” are subject to this reporting requirement. Smaller developers won’t have to worry about Insights reporting but should consider whether customer growth projections could trigger this requirement down the road.
Many developers have asked, “how is this different from Real World Testing (RWT)?” Conceptually, one way to think about “Insights” reporting is that it is designed to provide ONC and CMS with actual metrics on the volume of usage of certified capabilities for complete annual periods. By contrast, Real World Testing serves a different purpose – generating sample data to show that certified capabilities are working as expected, per the certification requirements.
EHR developers that meet the 50/500 user threshold should take stock of this requirement and ask themselves if they have the functionality to collect the data required for the first annual collection period (2026). For this reason, EHR developers shouldn’t view the extended 2026 deadline as justification to put off development to support collection of the reporting metrics. The ONC has provided the extra compliance runway – a 2-year window to be ready to collect Insights data – because they understood significant new development may be needed to support this data collection.
There are many data collection requirements across (g)(10), (e)(1) and (f)(1) that are triggered starting in 2026. Here is one example of the type of metrics that will be required for collection in 2026, relating to applications (e.g., SMART apps) that connect to a developer’s production (g)(10) FHIR APIs across the entire customer base:
(A) Application Name(s);
(B) Application Developer Name(s);
(C) Intended Purpose(s) of Application;
(D) Intended Application User(s); and
(E) Application Status.
In addition, FHIR data will need to be broken down by deployment, including:
- the number of requests made to distinct certified health IT deployments that returned FHIR resources,
- number of distinct of certified health IT deployments active at any time,
- the number of distinct deployments active at any time that returned FHIR resources in response to API calls from apps connected to certified health IT,
including stratifying responses by the following:
(A) User type;
(B) FHIR resource;
Developers should start now to determine the potential applicability of Insights reporting to their customer scope and recognize that it is a different animal from RWT. Insights reporting development work could be overlooked as other HTI-1 requirements are more directly intertwined with user-facing functionality that may appear more complex from a change management perspective.
Another example of a requirement that builds on the other requirements in the two-year development window, with significant preparation effort, is the HTI-1 Final Rule’s changes to the Electronic Case Reporting (eCR) requirement for public health.
Electronic Case Reporting Requirements
Simply put, eCR is the automated generation and transmission of case reports from electronic health records (EHRs) to public health agencies (PHAs), for purposes such as monitoring disease outbreaks. The HTI-1 Proposed Rule detailed a more robust eCR protocol by requiring consensus-based, industry-developed electronic standards and implementation guides (IGs) to facilitate case reporting.
The HTI-1 Final Rule maintained this requirement and mandated the following standards to support the eCR process under § 170.315(f)(5) as amended:
(i) create an electronic initial case report (eICR) according to at least the HL7 Clinical Document Architecture (CDA) eICR implementation guide (IG) or the eICR profiles defined in the HL7 Fast Health Interoperability Resources (FHIR) eCR IG and;
(ii) consume and process a reportability response (RR) according to at least the HL7 CDA RR IG or the RR profiles defined in the HL7 FHIR eCR IG.
After the release of the HTI-1 Final Rule, the enforcement date for these requirements was changed from January 1, 2025, to January 1, 2026. This is a helpful extension, but it pulls another key development requirement into the 2-year planning window with previously discussed Insights reporting and USCDI v3 migration requirements.
Electronic Case Reporting is a key need for CMS and other public health agencies, so this requirement cannot be ignored by providers who are subject to these reporting requirements.
Another requirement that was referenced in the HTI-1 Proposed Rule and maintained in the Final Rule was the “Request for Restriction” requirement.
Request For Restriction Requirements
The HTI-1 Proposed Rule put in place a “Request for Restrictions” requirement, which mandates that certified EHRs provide patients (and their authorized representatives) an internet-based method to request a restriction on someone accessing their healthcare data.
The Proposed Rule had included significantly greater data handling requirements in a new criterion, (d)(14), but this was abandoned in the Final Rule. Thus, the new rule is limited to patient request functionality only, with no explicit requirement about how to address requests. Providers must look to the HIPAA Privacy Rule and other applicable privacy requirements for guidance on handling requests for access restrictions on patient data.
In short, the new rule focuses only on establishing the request capability, which is required by January 1, 2026.
Once again, this deadline sits within the 2-year development window together with many other HTI-1 requirements. It reinforces the need for a comprehensive plan to integrate HTI-1 requirements into a 2-year development plan that will assure timely compliance with year 1 and year 2 enforcement deadlines.
Standardized API for Patient and Population Services—(g)(10) Updates
A final set of changes in requirements for the (g)(10) standardized API is important to mention. First, the ONC amended (g)(10) to codify some requirements that it had provided in published guidance in the past. The ONC assumes that most (g)(10) developers have already complied with their earlier guidance, so these requirements are expected to trigger limited, if any, change requirements for developers.
As a result of this assumption, the new (g)(10) requirements appear to have immediate effect (February 8, 2024) under the terms of the amended rule. While ACBs may provide a short grace period for compliance, EHR developers should immediately review their (g)(10) API functionality to confirm compliance with the newly codified requirements, which are summarized as follows:
(i) Complying with the applicable standards and implementations—170.215(a), (b)(1), and (d) – and supporting all data elements indicated as “mandatory” and “must support”.
(ii) Following standards in 170.215(c) and (d) to:
- Establish a secure and trusted connection with an application in multiple scenarios;
- Issue a refresh token valid for a period of no less than three months to applications using the “confidential app” profile;
- Grant access without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application;
- Be able to revoke and must revoke an authorized application’s access at a patient’s direction within 1 hour of the request;
- Be able to receive and validate tokens it has issued.
Developers should review the specific requirements mandated by the amendments to the (g)(10) rule and the applicable standards and implementation specifications it references. You may want to engage outside assistance to confirm full compliance. Consulting with the ACB on compliance deadlines is also recommended.
A last important new (g)(10)-related requirement is that API developers must “publish, at no charge, the service base URLs and related organization details that can be used by patients to access their electronic health information, by December 31, 2024.” The rule includes specific requirements for publication, whether centrally managed or locally deployed. Various resource format and organization details are specified.
Conclusion – Use the Two-Year Window Wisely
As we move forward into 2024, EHR developers must seize the opportunity this year to prepare their roadmaps for the numerous HTI-1 deadlines ahead. This preemptive approach will not only benefit one’s organization by advancing its practices, but it will also minimize the risk of dealing with unintended consequences and disruptions on your journey toward compliance. 2024 and 2025 are set to be eventful years for EHR developers, and the steps taken today will largely dictate how much positive change and growth your organization can benefit from in 2025 and beyond.
Get Expert Advice
DISCLAIMER
The services offered by Drummond Advisory Services are separate and distinct from the Drummond Group Test Lab and Certification Body. The purpose of Drummond Advisory Services is to provide expert support and guidance for the planning, analysis, and execution of certification activities; it does not negate the steps or required actions of the certification process. Use of Drummond Advisory Services does not guarantee successful ONC Health IT testing or certification.