On February 8, 2024 the Office of the National Coordinator for Health Information Technology (ONC) released the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing Final Rule (and corresponding Correction document) officially in the Federal Register to take effect on March 11, 2024. ONC provides a very nice summary of the rule along with recordings and slides from a series of informational webinars held to explain its contents (see overview slides).
The rule has these key topics which will be covered in this post:
- Adoption of the updated USCDI version 3 which defines core data elements for CEHRT interoperability.
- Updates to Clinical Document Architecture (CDA) Companion Guides (implementation guides).
- Updates to various minimum code set versions under the Program.
- Updates to better support electronic case reporting (eCR)
- Algorithm transparency for certified EHR technology (CEHRT) to begin to define the role of artificial intelligence (AI) and other predictive algorithms.
- Based on the requirements of the 21st Century Cures Act, new interoperability-focused reporting metrics (called “Insights Conditions”) for CEHRT.
The final rule also covers enhancements and clarifications to the Information Blocking rules which we will not discuss here. They may or may not apply to public health agencies (PHAs) but may help PHAs get data they need (see a short but interesting previous Network for Public Health Law discussion on this).
The text of the final rule is nearly 250 pages long in that little Federal Register type (the pre-release version is nearly 1,000 pages, double spaced). There are many, many other changes and enhancements to the Programs covered by this regulation, too many to mention. The text itself not only includes the final decisions with respect to the issues discussed, but a review of comments received by ONC during the comment period which includes ONC’s responses and logic for certain decisions. Following the themes presented in our previous post on the HTI-1 Notice of Proposed Rulemaking, we will comment on those changes that are most relevant to public health.
Like our last post on the proposed rule, this is going to be a little long…
Impact on Public Health
There was an interesting note about some comments received expressing concern about the impact of these Programs on public health agencies (PHAs), particularly the potential for a long tail of support for old versions of standards which could be handled by “expiration dates,” as well a lack of consideration for the financial cost incurred by PHAs to maintain their side of interoperability connections. ONC acknowledged these concerns, and indicated that some areas of the Program did have expiration dates, but really offered no assistance or promise on considering the cost impact on public health.
USCDI
The final rule updates national data exchange standards for EHRs to use USCDI version 3 effective January 1, 2025, though it extends the deadline for the expiration of version 1 to January 1, 2026. There were lots of comments about the timing and contents of USCDI, but ONC was unwavering in its plan. ONC correctly points out that the Final Rule only addresses the ability of CEHRT to exchange USCDI classes and data elements. It does not stipulate requirements for clinical sites actually recording or storing the data. There were lots of comments about inclusion or exclusion of specific data classes and elements in USCDI, but ONC correctly pointed out that the Final Rule was not the place for that discussion and that other processes existed for those comments. We note again that there are no certification criteria in the Program related to public health reporting that reference USCDI so this is not very relevant for public health at this time, other than to continue to set a broader foundation for the availability of data, including new social determinants of health (SDOH) data elements.
Clinical Document Architecture (CDA), Code Sets
The final rule updates Clinical Document Architecture (CDA) Companion Guides (implementation guides) that do not directly affect public health reporting to new versions effective January 1, 2025. Previous versions will expire on January 1, 2026.
The final rule updates various minimum code set versions under the Program, including CVX (including updates to the codes through June 15, 2022) and NDC codes (including updates to the codes through July 19, 2022) used for immunization reporting; LOINC codes (version 2.40) for laboratory tests; and affirmed their renaming of SOGI to “sexual orientation and gender information.” All these changes will be effective January 1, 2026.
Electronic Case Reporting (eCR)
To better support electronic case reporting (eCR), the final rule now incorporates the submission by CEHRT of an electronic initial case report (eICR) in either CDA or FHIR formats (using appropriate HL7 implementation guides), and the consumption by the EHR of a Reportability Response (RR) from the Reportable Conditions Knowledge Management Management System (RCKMS). The final rule agreed with our suggestion that the CEHRT must only support a RR in a format (CDA or FHIR) corresponding to the format of the eICR it submitted (while supporting a RR in either format is certainly a good thing to do). As a precursor, CEHRT must also be able to consume and process case reporting trigger codes as defined by the Reportable Conditions Trigger Codes (RCTC) Value Set that are distributed through the Electronic Reporting and Surveillance Distribution (eRSD) system (though to be compliant, CEHRT does not have to actually support eRSD but can acquire and process the RCTC any way it wishes). All these changes will be effective January 1, 2026.
There were some interesting comments questioning why ONC was requiring CEHRT to submit standards-compliant case reports even though PHAs are under no requirement to consume them, and in fact many jurisdictional disease surveillance systems cannot. Furthermore, some comments wondered why CEHRT had to support jurisdiction-specific transport requirements. Still others wondered whether the current standards direction for eCR should be modified in favor of standards and strategies that were not public health-specific (like SMART and FHIR). ONC correctly asserted that it cannot solve all of the inconsistencies of our complex healthcare ecosystem, and that it hoped/expected that PHA capabilities would catch up in conformance with CDC’s Public Health Data Strategy, the extended timetable provided in the final rule, and other initiatives. And once again, ONC declined to endorse any specific product (like eCR Now), intermediary (like APHL’s AIMS Platform or RCKMS), or real-world testing strategy.
Clinical Decision Support
As expected, the final rule contains an exhaustive discussion of changes to the treatment of clinical decision support (CDS) in CEHRT. It seems like the core of what was proposed in the NPRM last year was accepted with modifications at the edges. In response to many different comments, ONC does provide some examples of what might be considered Predictive DSI versus evidence-based DSI which were not in the NPRM (starting on p. 1245). As stated in our earlier comments, it is not clear whether there is any impact on public health specifically other than the downstream impact based on changes that may be required of CEHRT in the future. It is worth noting that when asked specifically about patient matching algorithms that use training data (and might be thought of as falling into the definition of predictive DSI), that these systems would likely still be considered evidence-based DSI because they are not really predicting an unknown outcome but scoring the similarity of new data to the training data.
One interesting aspect of this new rule has to do with the potential impact on Immunization Information Systems (IIS) and their evaluation and forecasting systems, often referred to as clinical decision support (CDS) for Immunizations (CDS-I). These CDS-I systems may be accessible from CEHRT through an application programming interface (API), or the results of the evaluation and forecast may be imported into an EHR through a response from an IIS to an electronic query and then used by a clinician to inform a patient’s preventive care. Based on the definitions in the final rule it appears that these CDS-I systems are evidence-based DSI (and not Predictive DSI) judging by how they usually work today.
But the final rule specifies somewhat extensive “source attribute information” that needs to be made available to users of evidence-based DSI for their review so they can understand how the algorithms work and what data they use. The requirement to provide this information is incumbent on the EHR vendor not the CDS creator. So, unless a CDS-I module was being certified by ONC as CEHRT there is no requirement to provide this information. The one exception to this is if the CDS-I creator wants the CEHRT to provide the information – then the CEHRT vendor would be obligated to provide it. Additional information on the CDS part of the final rule can be found on the ONC website in both presentation slides and a fact sheet.
Insights Conditions
A fundamentally new construct introduced in the final rule are the Insights Conditions. These are measures of interoperability that are incumbent on CEHRT vendors to submit to ONC every six months in aggregate for all users of their certified technology – a single set of metrics reported across all customers, all products, and all versions of the CEHRT (assuming contractual requirements do not prevent this). Vendors with a very small installed base of users would be excluded. Data collection for these metrics would not begin until calendar year 2026 with reporting beginning in 2027. Overall objections to the introduction of Insights Conditions were rejected by ONC as the requirement for introducing them came from Congress in the 21st Century Cures Act and is outside of ONC’s control. ONC noted that, “Another commenter opined (their word) on whether engaging with public health agencies to generate some meaningful data might be less burdensome on vendors and their users and may paint a more complete picture of the situation.” Opined? Uh… I think that was me…
The first two measures being requested by ONC that are relevant to public health relate to data submission to IIS and data query from IIS. As we pointed out in our previous post, the data initially being requested was somewhat confusing, as was the use of “numerator” and “denominator” values to calculate these measures. Based on this feedback, ONC replaced these terms simply with the term “metric” and will collect the data necessary to perform the calculations they desire rather than have the vendors perform the calculations themselves. To somewhat reduce the burden of reporting, ONC is phasing in some of the measures over several years rather than having them all required initially. We had suggested in a comment that IIS might be in a better position to provide these metrics, but ONC expressed concern about the uneven ability of IIS across the country to do so.
With respect to the first metric – submission of data to an IIS – ONC essentially accepted their proposed details with respect to the data they are requesting and its stratification in age groups (children/adolescents, wisely adjusted to age 18 and below to match Vaccines for Children’s program stratification, and adults), though the implementation of age stratification is delayed to the second year to allow time for implementation. ONC clarified that a transmission should only count once if a successful submission to an IIS is followed by an unsuccessful update attempt, and that messages sent multiple times for the same immunization should also not count as additional transmissions. ONC also confirmed that only message submission errors that result in an “Error (E)” severity should be ignored (i.e., not counted); errors that represent a “Warning (W)” should be counted. If an IIS does not send an acknowledgement message at all back to the EHR for an apparently successful submission that message should be counted. ONC also clarified that the metric is counted per IIS, so if the same immunization was reported to more than one IIS it would count for each one. Finally, ONC clarified that only the transmission of newly administered doses (as opposed to historical doses) should be counted, and those doses need to be both administered and transmitted during the reporting period.
With respect to calculating the number of immunizations administered overall (to be compared with the number submitted to an IIS), ONC clarified that it was not necessary to remove patients who opted out of participating in IIS data submission since the number is relatively small but the burden to exclude them may be greater. ONC further clarified that the number of immunizations administered could be “assigned” to specific IIS either based on the IIS primarily used by the clinical site, or the IIS associated with the clinical site location (and documented as such).
The second metric for immunization reporting is related to IIS queries for information. ONC clarified that a query response should be counted by the CEHRT if it is received regardless of whether the data is absorbed into the EHR itself. If several queries are required to ultimately receive data (for example, an initial query that requires a follow-up to narrow a set of possible patient matches received from the IIS), each query should be counted. Responses from the IIS which indicate an error (severity of “E” included in HL7 v2 RSP message) would be excluded from the count. Both responses with and without an immunization forecast would count. Stratification of the responses by age groups is being delayed to the second year of data collection to lessen the burden on vendors. Data should be included whether the provider administered immunizations during the reporting period or not.
An additional Insights Condition that is relevant to public health is the the “applications
supported through certified health IT” measure which asks for information about how external applications (apps) access CEHRT. Public health apps are included as one of the named categories, though I am not exactly sure what types of apps ONC is thinking about (eCR Now?). Apps would need to be “registered” with the CEHRT vendor who would report the “active use” of the application based on characteristics described in the final rule. Additional Insights Conditions focus on the adoption of FHIR (CEHRT response to a FHIR-based query, which could come from a PHA to support, say, case investigation), and bulk FHIR queries sent from CEHRT to another organization (which could be a public health system like an IIS). The presence of these Insights Conditions may encourage or incentivize the deployment of these FHIR-based solutions.
Final Comments
ONC included a number of requests for information in the original NPRM but offered nothing more than an acknowledgment of having received responses.
We encourage all those affected stakeholders to examine not only the final rule but additional material summarizing and discussing these developments offered by ONC as well as other organizations (like HIMSS).