Healthcare Reform

Health Data, Technology and Interoperability: Certification Program Updates, Algorithm Transparency and Information Sharing (HTI-1) Overview

The Office of the National Coordinator for Health Information Technology (ONC) published the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule on Dec. 13.

The new rule requires new and updated standards, implementation specifications and certification criteria for electronic health records and health information technology modules for certification through the ONC certification program.

Revised Timeline for Implementation of New and Updated Standards and Certification Criteria, and timeline for reporting to Insights Condition EHR Reporting Program

2024

  • By December 31, 2024:
    • Certified API Developers must publish their customers' service base URL information (FHIR Endpoints) in accordance with approved standards
    • Certified developers of Health IT and Health IT modules certified to current clinical decision support criterion must:
      • Update their certificate clinical decision support to the new criterion for Decision Support Interventions criterion (see below)
      • Provide updated functionality of decision support interventions as required in the final rule to customers

2025

  • On January 1, 2025:
    • Decision Support Interventions criterion officially replaces Clinical Decision Support criterion in certification
    • “Assurances” Maintenance of Certification requirement for decision support interventions begins
  • By December 31, 2025:
    • To receiver certification, health IT developers must update and provide to their customers certified health IT that conforms to new and revised standards and certification criteria included in the final rule (see below)

2026

  • January 1, 2026
    • All HTI-1 updated standards in certification criteria are required for certification
  • January 1, 2026-December 31, 2026
    • Health IT developers must collect the data required for the Year 1 Measures (see below) for the Insights Conditions Reporting Program to maintain certification

2027

  • January 1, 2027-December 31, 2027
    • Health IT developers must collect Year 1 and Year 2 measures (see below) for the Insights Condition reporting program
  • July 1, 2027
    • Health IT developers must submit 2026 measure data for Year 1 measures for the Insights Condition reporting program

2028

  • January 1, 2028-December 31, 2028
    • Health IT developers must collect Year 1, Year 2, and Year 3 measures (see below) for the Insights Condition reporting program
  • July 1, 2028
    • Health IT developers must submit 2027 measure data for Year 1 and Year 2 measures for the Insights Condition reporting program

2029

  • January 1, 2029-December 31, 2029
    • Health IT developers must collect all measures (see below) for the Insights Condition reporting program
  • July 1, 2029
    • Health IT developers must submit 2028 measure data for Year 1, Year 2, and Year 3 measures for the Insights Condition reporting program

Decision Support Interventions and Certification

Decision Support Certification Criterion

  • Decision Support Interventions (DSI) certification criterion has been updated and adopted to replace current criterion for CDS
  • The DSI criterion must be implemented before January 1, 2025
  • Delays in the implementation deadline for other new/revised certification standards and criteria were selected to allow developers of Health IT to focus on updating to the DSI criterion in 2024.
  • DSI is a revised certification criterion of the current CDS criterion.
  • Scope was narrowed only to DSI developed by the developer of Health IT seeking certification for the Health IT module
  • Starting December 31, 2025, Data elements required for DSI configuration must be expressed according to new and revised standards finalized for Certification, including USCDI v3.

Evidence-based Decision Support Interventions

  • Definition- Evidence-based DSIs, for purposes of certifying Health IT modules to DSI criterion, 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 Decision Support Intervention
    • “Actively presented” includes interruptive alerts, but not exclusive to interruptive alerts
    • “Related to the care a patient receives” includes at the point of care and use cases that impact the care the patient receives (for example, an evidence based guideline for when a follow up visit should occur)
  • Requirement for DSI to support the end user providing feedback electronically is only required for Evidence Based DSI that actively present 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 , not Predictive DSI
  • Feedback including but not limited to:
    • Intervention Taken
    • Action Taken
    • User Feedback Provided (if applicable)
    • User
    • Date
    • Location
  • Feedback data be available for export by users for analysis in a computable format consistent with current requirements for EHI export, so that it could be associated with other relevant data
  • Health IT Module must enable any user to provide electronic feedback
  • 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 

Predictive Decision Support Interventions

  • Definition: “Predictive decision support intervention or Predictive DSI means 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.”
  • Large Language Models (LLMs) developed by the Health IT developer for use in the Module requiring certification are in scope under the Predictive DSI definition
  • Meeting Predictive DSI definition is not dependent on risk level, or degree to which DSI informs or drives treatment, is relied upon by the user, relates to time sensitive action, or whether the Predictive DSI is augmentative or autonomous
  • Predictive DSI support decision-making by learning or deriving relationships to produce an output, rather than those that rely on pre-defined rules based on expert consensus (Evidence Based DSI)
  • Predictive DSI must enable access to complete and up- to-date plain language descriptions of source attribute information related to that Predictive DSI
  • Predictive DSI must have the technical capability for users and other parties to populate the source attributes listed in the DSI Criterion themselves
  • The following could be Predictive DSIs, if they are driven by algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis.
    • Alerts
    • order sets
    • flowsheets
    • dashboards
    • patient lists
    • documentation forms
    • relevant data presentations
    • protocol or pathway support
    • reference information or guidance
    • reminder messages

Infobutton/Linked Referential Decision Support Interventions

  • Linked Referential DSI has been removed from DSI Criterion
  • HL7 Context Aware Knowledge Retrieval Application (“Infobutton”) standards have been removed from the scope of the DSI Criterion
  • Infobuttons are still valuable, but with expanded focus in other areas, Infobuttons/LR DSI have been removed from the DSI criterion

Certification Requirements for Predictive DSI

  • Intervention Risk Management Practices
    • Developer of certified health IT with a Health IT Module certified to DSI must apply IRM practices for each Predictive DSI supplied by the health IT developer a and submit summary information of their IRM practices to its ONC-ACB via publicly accessible hyperlink before December 31, 2024.
    • Required for submission are the risk analysis and management practices taken during the development of Predictive DSI, including assessments for:
      • Validity
      • Reliability
      • Robustness
      • Fairness
      • Intelligibility
      • Safety
      • Security
      • Privacy
    • Source Attribution
      • Developer of Health IT must provide, review, and update the following in plain language through a prescribed electronic format as a condition of maintenance for certification
        • Details and the output of the DSI
        • Name/contact information for the DSI
        • Funding source of the technical implementation and development of the DSI
        • Description of the output produced by the DSI, noting if this value output is a prediction, classification, recommendation, analysis, or other type of output
        • Purpose of the intervention
        • Intended use of the DSI
        • Intended patient population(s) for the use of the DSI
        • Intended user(s)and Intended decision-making role for which the DSI was designed to be used (informs, augments, replaces clinical management)
        • Out of scope use of the intervention
        • Description of tasks, situations, or populations where a user is cautioned against applying the DSI
        • Description of known risks, inappropriate settings, inappropriate uses, or known limitations of the DSI
        • Development details and input features (including)
        • Exclusion and inclusion criteria that influenced the training data set
        • Use of variables as input features
        • Description of demographic representativeness according to variables including, at a minimum, those used as input features in the intervention
        • Race Ethnicity and Language (REL) data elements used
        • Sexual Orientation and Gender Identity (SOGI) data elements used
        • Social Determinants of Health (SDOH) data elements used
        • Health Status data elements used
        • Description of relevance of training data to intended deployed setting
        • Processes used to ensure fairness in the development of the intervention
        • Description of the approach the developer has taken to manage, reduce, or eliminate bias in order to ensure the DSI output is fair
        • External validation processes
        • Description of the data source
        • Description of the clinical setting where the DSI’s validity and fairness has been assessed (other than the source of training and testing data)
        • The name of the external party that conducted the testing
        • Description of demographic representativeness of external data including, at a minimum, variables used as input in the development of the DSI
        • Description of external validation process
        • Quantitative measures of performance
        • Validity and fairness of prediction using test data
        • Validity and fairness of prediction using external data
        • References to evaluation of the use of the model and outcomes, examples including:
        • bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other outcomes.
        • Ongoing maintenance of DSI (implementation and use)
        • Description of process and frequency needs to be used to monitor the ongoing validity and fairness of the DSI over time
        • Validity and fairness of intervention using local data
        • Required revalidation and fairness assessment schedule
        • Recommended revalidation schedule
        • Description of frequency DSI is updated when risks related to validity and fairness are identified 

New Standards and Certification Criteria

Adoption of USCDI v3

  • USCDI v3 will be optional January 1, 2024-December 31, 2025 and will coexist with USCDI v1 in the standard until USCDI v1 expires on January 1, 2026.
  • ONC encourages developers to implement update their certified Health IT/modules as soon as practical
  • ONC adopted the C-CDA Companion Guide Release 4.1 and FHIRUS Core IG 6.1.0 which will coexist with existing standards until January 1, 2026.
  • USCDI v3, C-CDA 4.1, and FHIRUS Core IG 6.1.0 will be the required standards and implementation guides for certified health IT/modules starting on January 1, 2026

Standardized API for Patient and Population Services

  • The SMART App Launch Implementation Guide v2 must be adopted by December 31, 2025
  • API Condition and Maintenance of Certification was updated to require use standardized formats for FHIR endpoints to support the use of patient-facing apps of Service Base URLs
  • To receive certification, a Health IT module must have the capaibility to revoke an authorized application's access to EHI at a patient's direction within one hour of the request

Electronic Case Reporting (ECR)

  • Certified health IT must use either the HL7 CDA suite or the FHIR standards and implementation guide no later than December 31, 2024 (replacing current functional and descriptive requirements for 2015 Cures certification requirements)

Patient Demographics and Observations

  • Demographics criterion has been revised to “Patient Demographics and Observations”
  • Changes in “Patient Demographics and Observations” must be adopted to maintain or receiver certification for Health IT/modules no later than December 31, 2025, to align with the implementation timeline for USCDI v3
  • New terminology standards:
    • Sexual Orientation
    • Sex
  • New data elements
    • Sex Parameter For Clinical Use
    • Pronouns
    • Name to Use

Information Blocking Requirements and TEFCA

Information blocking means a practice that except as required by law or covered by an exception, is likely to interfere with access, exchange, or use of electronic health information; and

  • If conducted by:
    • A health IT developer of certified health IT, health information network or health information exchange, such developer, network or exchange knows, or should know, that such practice is likely to interfere with access, exchange, or use of electronic health information; or
    • A health care provider, such provider knows that such practice is unreasonable and is likely to interfere with access, exchange, or use of electronic health information.

New Definitions relevant to the Information Blocking Requirements

  • Developer of certified health IT
    • an individual or entity, other than a health care provider that self-develops health IT for its own use, that develops or offers health information technology and which has, at the time it engages in a practice that is the subject of an information blocking claim, one or more Health IT Modules certified under a program for certification of health by ONC
  • Offers Health IT:
    • Providing, supplying, or otherwise making available certified health IT under any arrangement or terms except for specifically defined exclusions
      • Exclusions would include
        • certain donation and subsidized supply arrangements
        • specific implementation and use activities
        • specified legal services arrangements
  • “Actor” must be a party regulated by the information blocking regulation
  • Must involve Electronic Health Information (EHI)- protected electronic health information designated record set as defined by HIPAA
    • Applicable whether information is held by a HIPAA covered entity or a non-HIPAA covered entity
      • Exemption: psychotherapy notes in anticipation of, or for use in, a civil, criminal, or administrative action/proceeding

Information requires requisite knowledge by the actor.

  • Healthcare Providers must “know that a practice is UNREASONABLE and is likely to interfere with the access, exchange, or use” of EHI
  • Health IT developers must “KNOW OR SHOULD KNOW that such a practice is likely to interfere with the access exchange or use” of EHI

A practice is not information blocking if the practice is mandated by existing law or meets an exemption in the regulation.

Revisions to current exemptions

  • Infeasibility Exemption
    • In the case of information blocking occurring because of an “uncontrollable events” the actor must demonstrate that information blocking occurred “because of” (not “due to”) the uncontrollable event
    • The actor demonstrate the uncontrollable event directly caused the occurrence of information blocking to meet the exception
  • The Third Party Seeking Modification Use Condition
    • The actor’s practice of not fulfilling a request for use of EHI will not be considered information blocking when the actor is asked to enable a third party to:
      • modify EHI within the records or systems maintained by the actor
      • the request is not from a health care provider (including a business associate acting on the health care provider’s behalf) requesting such use from an actor that is its business associate
    • Manner Exception
      • “Content and Manner Exception” has been changed to “Manner Exception”
      • The Manner Exception applies when where an actor does not fulfill a request for access, exchange, or use of EHI after offering alternative, interoperable manners.
        • The exception only applies where the actor does not currently provide the requested manner of access, exchange, or use of the requested EHI to a substantial number of individuals or entities that are similarly situated to the requestor
      • TEFCA Manner Exception
        • When both the actor and the requestor are part of TEFCA and the requested EHI can be supported via TEFCA by both parties, the actor if not information blocking if they provide the EHI requested using TEFCA, even if that isn’t the manner which the requesting party asked for the EHI to be shared

Insights Condition (Maintenance of Certification)

Minimum Thresholds

  • Developers of Health IT/modules must meet the reporting requirements for the Insights Condition Reporting Program if they meet the following thresholds:
    • Developers of Certified Health IT must report on each measure IF:
    • They have 50 hospitals OR 500 clinician users across their certified Health IT products; AND
    • The certified Health IT product is certified to the criteria/criterion for the measure; AND
    • The developer has ANY users of the applicable criteria/criterion associated with the measure

Year 1 Measures

  • Data collection for these measures must start January 1, 2026
  • Data collection for these measures will be captured for the full calendar year of 2026
  • Reporting of these measures will start July 1, 2027
  • Year 1 Measures are:
    • Applications Supported through Certified Health IT
      • Application name(s)
      • Application developer Name(s)
      • Intended purpose(s) of application using categories set out in measurement specification sheets
      • Intended application user(s) using categories set out in measurement specification sheets
      • Application Status
    • Use of FHIR in Apps Supported through Certified Health IT
      • Number of distinct certified health IT deployments (across clients) active at any time during the reporting period, overall and by user type
      • Number of requests made to distinct certified health IT deployments that returned at least one FHIR resource by FHIR resource type
      • Number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned overall and by user type
    • Individuals Access to EHI through Certified Health IT
      • Number of unique individuals who accessed their EHI using technology certified to “standardized API for patient population services” certification criterion
      • Number of unique individuals who accessed their EHI using technology certified to the “view, download, and transmit to 3rd party” certification criterion
      • Number of unique individuals who accessed their EHI using any method
    • Immunization Administrations Electronically Submitted to Immunization Information Systems Through Certified Health IT
      • Number of immunizations administered overall
      • Number of immunizations administered electronically submitted successfully to IISs overall

Year 2 Measures

  • Data collection for these measures must start January 1, 2027
  • Data collection for these measures will be captured for the full calendar year of 2027
  • Reporting of these measures will start July 1, 2028
  • Year 2 Measures
    • C-CDA) Problems, Medications, and Allergies Reconciliation and Incorporation Through Certified Health IT
      • Number of encounters
      • Number of unique patients with an encounter
      • Number of unique patients with an associated C-CDA document
      • Number of total C-CDA documents obtained
      • Number of unique C-CDA documents obtained
      • Number of total C-CDA documents obtained that were pre-processed
      • Number of total C-CDA documents obtained that were not pre-processed
    • Use of FHIR in Apps Supported through Certified Health IT
      • Number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned by the required US Core Implementation Guide
    • Use of FHIR Bulk Data Access Through Certified Health IT
      • Number of distinct certified health IT deployments (across clients) that completed at least one bulk data access request
      • Number of bulk data access requests completed (across clients) to export all data requested for patients within a specified group
    • Immunization Administrations Electronically Submitted to Immunization Information Systems Through Certified Health IT
      • Number of immunizations administered overall by IIS and by age category
      • Number of immunizations administered electronically submitted successfully to IISs overall by IIS and by age category
    • Immunization History and Forecasts Through Certified Health IT
      • Number of immunization queries sent to IISs overall
      • Number of query responses received successfully from IISs overall

Year 3 Measures

  • Data collection for these measures must start January 1, 2028
  • Data collection for these measures will be captured for the full calendar year of 2028
  • Reporting of these measures will start July 1, 2029
  • Year 3 Measures:
    • C-CDA Problems, Medications, and Allergies Reconciliation and Incorporation Through Certified Health IT
      • Number of total C-CDA documents obtained that were pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method
      • Number of total C-CDA documents obtained that were not pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method
      • Number of total C-CDA documents obtained that were determined to have no new problems, medications, or allergies and intolerances information by pre-processes or fully automated processes
    • Immunization History and Forecasts Through Certified Health IT
      • Number of immunization queries sent to IISs overall by IIS
      • Number of query responses received successfully from IISs overall by IIS

Measures will be reported and aggregated at the product level.

Discontinuing Year-Themed Editions

ONC will discontinue the use of year-themed editions for ONC Certification Criteria for Health IT.

ONC will adopt an incremental approach to updates to ONC Certification Criteria for Health IT as reflected in the spacing of deadlines for the required adoption of new and revised standards and criteria.

ONC did not commit to a specific regulatory update schedule for the Certification program, but stated they will provide “clear guidance and timelines for when updates would be required.”