Demystifying HTI-2: What developers, providers, and patients need to know

This is quite a lot to process, so below you’ll find our biggest takeaways for developers, providers, patients, and other stakeholders.

The HTI-2 Proposed Rule weighs in at 1067 pages in its PDF format. By comparison, the previous rule (HTI-1) was only 556 pages in its proposed form and the Cures Act Proposed Rule itself was 687 pages. This is not just pageflation—these are very different rules in tone, scope, and ambition.

HTI-1 was iterative in many ways, riffing off Cures but not inventing or pushing new capabilities (the only substantive novel feature was the Decision Support Interventions, their attempt to add some transparency into generative AI). If you were to film the ONC’s offices and create a Rocky-style montage, it would be them hitting the weights in the gym or running up the Art Museum steps:

• They restructured and streamlined the certification program to get fit and efficient
• They added Insights Conditions to have developers report key metrics to ensure better visibility
• They updated minimum standards, set new baselines such as USCDIv3, and tweaked definitions to information blocking to keep the ball moving
• They requested a lot of information about cutting-edge standards and unique use cases to have full visibility of where to go next

All of that strength training came to bear in HTI-2. This is the rule where they land blow after blow, dramatically expanding the total number of criteria for certified health IT. HTI-2 allows a much broader set of technology developers to participate in certification, while also laying the foundational architecture, policy, and tooling needed for their vision of our national healthcare ecosystem.

Three broad themes underpin this:

• Ensure certified health IT includes advanced capabilities such as CDS Hooks and Subscriptions to allow provider apps to live in a FHIR-only world
• Directly address discrete sub-problems of interoperability (provider-public health exchange and provider-payer exchange) by expanding the scope of the certification program
• Support TEFCA directly and indirectly across provider, payer, and public health entities with technology and policy

Almost all of HTI-1 would fit into just that first bullet.

Digital health applications (those business associate applications that sell to hospitals and clinics), have long suffered from disparate integration standards and formats. Whether making a patient engagement application, an AI scribe, a lab information system, or the many other applications that orbit around the EHR for a given health system, dealing with the varied legacy standards in play was painful

With the patient and population FHIR API of the Cures Final Rule kicking into effect in December 2022, developers of ancillary applications were excited about the promise of a FHIR-only world free of the constraints of VPNs and the hieroglyphic complexity of HL7v2, X12, and older standards.

That promise was not fulfilled for most developers, however. The reality is that the FHIR capabilities of the Cures Final Rule, even when extended slightly with HTI-1 to a fuller set of resources in USCDI version 3, could not meet the needs of many applications:

• Query-based APIs often lack real-time event notifications, limiting applications’ ability to enroll patients and maintain up-to-date user lists for specific use cases
• Clinical decision support applications were stuck with clunky SMART on FHIR workflows, forcing users to jump out of their EHR constantly in order to review advised care
• While EHRs were required to provide proper authentication for patient-facing and provider-facing applications, some “backend” applications have no user to authenticate, since they provide system-to-system functionalities.

As a result, these apps were forced to mix FHIR and legacy standards together or avoid FHIR entirely. The ONC’s new proposals go a long way toward enabling many applications to take the full FHIR plunge:

• The Subscriptions functionality allows applications to subscribe to be notified of different key triggers and events
• The CDS Hooks functionality means that ancillary applications can embed directly into EHR workflows, suggesting medications and procedures or linking helpful information for providers
• The proposals enable system-level authentication for all FHIR APIs, meaning that “user-less” backend applications can now integrate

Beyond these, there are a lot of other small tweaks that will help developers of ancillary applications, like adding imaging links to USCDI data or the update to require USCDI version 4.

However, as proposed, they are missing one big feature/requirement to enable this future: the ability to write data back into the EHR. This would require “Create” style FHIR APIs to allow applications to push data into EHRs.

This capability has long been hard to pin down, with the Argonaut workgroup thinking about it in the context of vitals and the ONC convening expert webinars. However, we see that the ONC might be reluctant to force EHRs to allow writing across the varied use cases of patient apps, provider apps, and backend services. Writing into EHRs via FHIR is (surprisingly) not that difficult technically, with EHRs like Epic and Cerner already offering some APIs for that purpose. The challenge for the ONC is how to prescriptively define a write capability factoring in different use cases (patient apps, provider apps, etc).

A glidepath to that end might be to update the “Revised Clinical Information Reconciliation and Incorporation Criterion” section to include FHIR payloads as well as transfer of care documents. This would mean, to start, that “written” FHIR payloads would go through a reconciliation process or be auto-reconciled into the chart according to the customer provider’s preferences. Given they are already proposing this requirement for CDA documents, the extra lift for a more modern format seems reasonable. This is especially true given the upside of enabling the full initial ecosystem for apps to build in a FHIR-only world.

Interoperability (in its truest sense) is less about intraoperability (integration) within a healthcare organization (point 2) and more about workflows between disparate healthcare organizations. The government is uniquely positioned to incentivize these cross-organizational utilities and cross-sector infrastructure at a national scale.

Looking at this rule, it’s clear the ONC is acutely aware of this. They have an explicit goal of reducing provider burden by focusing on public health data exchange and digitization of payer workflows. This is not new per se: HIPAA literally required standards related to payer workflows and public health capabilities, which have long been part of the certification program. Rather, the newest components and a large portion of the rule’s length come from the ONC certifying not just the provider side, but also the technology used on the payer and public health agency side.

This is logical because certifying only one side of a two-party exchange does half the job.

But this is an expansion of scope. In the past few weeks, nothing has become more in-vogue than questioning what regulatory action might be struck down or undone in the wake of Loper Bright Enterprises v. Raimondo (and the companion Relentless, Inc. v. Department of Commerce). If you’re not familiar with the Chevron case and want a more balanced take than you often find in today’s polarized politics, Andrew Tomlinson has an excellent framework for how to conceptually think about regulation post Loper Bright/Raimondo:

As a brief note, I am not a lawyer and HTD Health is not a law firm, so take these opinions with a grain of salt. As an industry implementer, though, I think about things post-Chevron in these terms:

1. Which affected party feels sufficiently burdened to try and overturn this?
2. Which section of the rule represents an overstep in authority granted by law to the regulatory agency?
3. Are the affected parties certain that going through judicial processes and overturning the rule will actually cause Congress to give more direct authority?

For point 1, EHR developers may feel burdened, but the ONC is given direct authority via HITECH to make a certification program for them. Payers and public health agencies, however, were not included in HITECH, nor were they included in subsequent regulation about the certification program’s boundaries. Let’s look at each affected group below:

EHR developers:

1. Possibly yes to point 1, this is a big rule.
2. They’re directly regulated by ONC since HITECH, but is HTI-2 an overstep (i.e. did the ONC go beyond what Congress explicitly authorized)? There’s possibly a case to be made here.
3. I feel confident Congress would be frustrated to see that, given regulating health tech has been bipartisan in nature. Even with an administration change, there’s a lot of risk.

Public Health software developers:

1. Probably not on point 1: I think the CDC is onboard and generally Public Health Agencies would be pumped to have a reason (and possibly funding to come) to modernize.
2. Traditionally the ONC has had zero authority over their vendors.
3. It’s not clear why they’d pursue this, unless it’s a conservative state that resents federal oversight and control.

Payer software vendors:

1. Almost certainly yes to 1, but they are already compelled to create the functionality via CMS-9115 and CMS-0057.
2. Traditionally the ONC has had zero authority over payers or their vendors.
3. Payers have the resources and the stubbornness to pursue judicial action. However, the downside risk is huge—if the courts overturn and Congress explicitly authorizes ONC in this function or the CMS’ tech prerogatives, they will have less leeway for non-compliance. Regardless, I’d imagine they would target the initial CMS-9115 and CMS-0057 regulations first if they do.

In section 13103 of the Cures Act, Congress authorizes the ONC to reduce regulatory or administrative burdens (such as documentation requirements) relating to the use of electronic health records. In general, across all of the above, the ONC is making the case that the provisions of HTI-1 and HTI-2 directly relate to that mandate. While the capabilities it wants to certify may increase the regulatory burden, they are focused on the massive administrative burdens of EHR use via all the criteria they propose.

Ultimately, the greatest defense for the ONC is that, as detailed previously, the EHR certification program is voluntary. Only EHR developers really have a regulatory reason (via the CMS Promoting Interoperability and MIPS programs) to feel that they must certify their software in order to help their customers. Without the CDC or CMS giving public health and payer software vendors a reason to certify, many may avoid that, especially since that certification would bring them under information blocking provisions.

The Trusted Exchange Framework and Common Agreement (TEFCA) is another outcome of the Cures Act, although separate and distinct from the portion related to EHR certification updates. It is intended to broaden existing health information networks and exchanges with a common agreement on data-sharing principles. It is voluntary to join, so some had hoped that the ONC might tie TEFCA capabilities tightly into their EHR certification criteria.

In this proposed rule, though, there aren’t new pieces directly compelling EHRs or providers to use TEFCA. The direct TEFCA-related content in the rule is fairly straightforward in defining relationships and procedures between the ONC, the Recognized Coordinating Entity (RCE) and Qualified Health Information Networks (QHINs).

Take a step back, though, and you’ll see a number of symptoms suggesting the ONC is suffering from a case of ADIDAT (All Day I Dream About TEFCA):

1. The repeated insertion of the aforementioned UDAP dynamic client registration into provider, payer, and public health criteria lays a foundational capability for the future TEFCA roadmap
2. The structuring of the Standardized API for Public Health Data Exchange is entirely designed to pull public health workflows into the TEFCA world
3. Likewise, the structuring of the public health and payer certification criteria are angled to lead these organizations toward TEFCA
4. The clarification that participation in TEFCA is not likely to ever constitute information blocking shows that the ONC wants to remove any doubts groups may have
5. The specific definitions at the end of the document related to TEFCA are a mechanism for ONC to cement the governance and escalation paths that might be needed in the event of another Particle v. Epic

This is not by accident. The ONC lacks the regulatory authority to directly require TEFCA, per the Cures Act:

(i) GENERAL ADOPTION.—Nothing in this paragraph shall be construed to require a health information network to adopt the trusted exchange framework or common agreement.

But it does seem that other federal agencies could require the use of TEFCA:

(iv) APPLICATION BY FEDERAL AGENCIES.—Notwithstanding clauses (i), (ii), and (iii), Federal agencies may require the adoption of the trusted exchange framework and common agreement published under subparagraph (C) for health information exchanges contracting with or entering into agreements pursuant to subparagraph (E).

Where section E says:

(E) APPLICATION OF THE TRUSTED EXCHANGE FRAMEWORK AND COMMON AGREEMENT.—As appropriate, Federal agencies contracting or entering into agreements with health information exchange networks may require that as each such network upgrades health information technology or trust and operational practices, such network may adopt, where available, the trusted exchange framework and common agreement published under subparagraph (C).

Simply put, through HTI-2, the ONC is doing everything they can to make TEFCA real. They are laying the groundwork in terms of technical capabilities, operational policies, and governance for other agencies, such as the CMS and CDC, to use and even require TEFCA for their interoperability initiatives. This seems to align with programs like the CDC’s Data Modernization effort.

This quote from Ben Thompson at Stratechery applies well to digital health. Assuming the regulation is evenly distributed and not targeted, it will deepen the moat for incumbents. Smaller entities cannot afford (or at least have fewer resources) to absorb the roadmap deviation that regulation requires.

As we think about HTI-2 (and any other functionality-oriented regulation), the barrier to entry for new EHRs increases and the herd of viable EHRs decreases due to the cost of compliance. There are ways to artfully design regulation to affect only incumbents (or bluntly, in the case of Dodd-Frank’s Durbin Amendment having different interchange rates based on bank size). HTI-2 does not attempt this in its current form—the functional requirements are uniform across all certified health technologies. This will help Epic and other leaders: Compliance represents a smaller roadmap deviation as a percentage of their total development capacity.

We have seen this trend through successive iterations of the ONC’s certification program, in that fewer and fewer products have been certified. This will likely accelerate with HTI-2, given the speed it comes at the heels of HTI-1 and overall complexity of the rule. The ONC knows and admits this trend will continue:

At the same time, while the moat for EHR incumbents increases, the moat of business associate applications slightly decreases due to the API nature of this regulation. As advanced integration is increasingly commoditized, applications must compete on cost and other features. It will be easier than ever to build a competitive patient engagement application, clinical decision support tool, ambient listening scribe, or so many other use cases.

Similarly, the thrust of certification is no longer about EHRs. It is about building nationwide infrastructure that the private sector has not created yet on its own. The handoffs between providers, payers, and public health are true friction that prevents optimal care, reduces patient satisfaction, and blocks swift responses to health crises.

The takeaway here should not be the tired “regulation is bad, government is bad” which is in vogue among startups. Regulatory (and antitrust) actions and inactions are about tradeoffs.

The ONC is choosing to enable:

1. Different competitive ancillary application markets via a broad and modular app ecosystem
2. A number of nationwide infrastructure initiatives

This comes at the cost of EHR consolidation. This is, in my opinion, a good bet—EHR consolidation will continue regardless. If you want otherwise, consider the merits of antitrust to break up these platforms.

If I am the business leader at an EHR or a tech enabled care delivery company that has certified software, it’s worthwhile to take this burden and opportunity seriously. Commenting on the rule with your thoughts on feasibility is the only way to change the path here. Beyond that, updating your roadmap to invest proactively in the capabilities that may be included in the rule could allow you to avoid a race to the finish down the line. Similarly, if I am a provider organization, I would immediately begin discussions with your vendor to understand their perspective on this regulation.

Overall, once all 1000+ pages are read and processed fully, it’s clear that HTI-2 is stunningly well designed – weaving together the themes we mentioned above into a detailed tapestry of interoperable applications and cross-organizational workflows. There are, however, some loose ends that we are excited to watch.

As mentioned at the beginning, HTI-2 is a proposed rule. All aspects of the rule may be changed—the criteria, the policies, the dates. The rule may even be shelved altogether.

In general, sections with non-specific standards rarely make it. If the government can’t specify a standard, the industry probably hasn’t defined the right implementation guides or proven out the exchange pattern, resulting in pushback. Likewise, sections involving non-regulated systems rarely make it.

The imaging link section of the new rule checks both boxes by requiring certified health technology to make links to diagnostic images available via patient access APIs, provider access APIs, and cross-organization exchange but without specifying how. Given that diagnostic images are stored in the PACS, which is not regulated, it will be interesting to see how EHRs navigate this provision while ensuring safe and proper access.

Similarly, there are a few other inconsistencies that we should expect to be ironed out as the rule is finalized, such as the disparate logic across the various public health criteria on FHIR/non-FHIR exchange. Other open questions are whether multiple standards for a single public health criteria make sense, or how the ONC could justify removing medication history from e-prescribing while also requiring medication reconciliation.

In terms of timing, the comment period is 60 days from the initial publication of HTI-2 in the Federal Register. This timer has not yet started, as it is in review with the Office of the Federal Register (OFR) for publication and has not yet been placed on public display. Thinking optimistically and assuming publication in the back half of July, we can expect the comment period to end towards the end of September.

As everyone is well aware, there are elections in November. While healthcare technology regulation is generally bipartisan, with any administration change we often see pauses or shelving of recent rules, such as the interoperability and prior authorization provisions in CMS-9123. After the 2020 elections, it was withdrawn altogether, although the content of that rule was eventually resubmitted and finalized in CMS-0057. In particular, an administration change might threaten the progress of TEFCA, as that languished during the last Trump term.

Turning around and finalizing the rule is likely on the mind of the ONC, but it will be a tough challenge based on recent precedent. The original Cures Act Final Rule was proposed in March 2019 and finalized May 2020. Likewise, HTI-1 was proposed in April 2023 and finalized in December of that year.

So the clock is on for this rule. Make sure to tune into ONC-hosted webinars on the topic, submit your comments when it’s released on the Federal Register, and subscribe to our newsletter to stay updated on future developments.

• If you’re interested in talking more about HTI-2 or other ONC certification, make sure to reach out to HTD, the leading technology services group focused on virtual-first care and healthcare interoperability.
• For an even deeper dive into the guts of HTI-2, check out this Twitter thread, which gives a stream-of-consciousness style review of all major points (and hidden gems) found in the proposed rule.
• For more detailed reading on the history of the ONC’s certification program, we recommend reading The EHR Labyrinth.

• (1) https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi
• (2) https://www.healthit.gov/sites/default/files/facas/2023-08-17_Overview_USCDI_V4_508.pdf
• (3) https://build.fhir.org/ig/HL7/bulk-data/export.html
• (4) https://build.fhir.org/ig/HL7/smart-app-launch/
• (5) https://build.fhir.org/ig/HL7/smart-app-launch/backend-services.html
• (6) https://build.fhir.org/ig/HL7/smart-app-launch/brands.html
• (7) https://standards.ncpdp.org/Standards/media/pdf/Correspondence/2023/20230213_To_CMS_CMS_4201_P_NPRM.pdf
• (8)  https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7295863/#:~:text=Patient%20directions%20are%20also%20commonly%20referred%20to%20as%20%E2%80%98Sigs%E2%80%99%20which%20is%20the%20abbreviation%20for%20the%20Latin%20word%20%E2%80%98Signetur%E2%80%99%20meaning%20%E2%80%98let%20the%20medication%20be%20labeled%E2%80%99.
• (9) https://build.fhir.org/ig/HL7/fhir-us-ph-common-library-ig/
• (10) https://smarthealth.cards/en/
• (11) https://build.fhir.org/ig/HL7/fhir-udap-security-ig/
• (12) https://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/
• (13) https://cds-hooks.org/
• (14) https://www.healthit.gov/sites/default/files/page/2024-07/HTI-2_ProposedRule_PublicHealth_508.pdf
• (15) https://build.fhir.org/ig/HL7/carin-bb/Background.html
• (16) https://build.fhir.org/ig/HL7/davinci-pdex-formulary/
• (17) https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/index.html
• (18) https://build.fhir.org/ig/HL7/davinci-epdx/provider-access-api.html
• (19) https://build.fhir.org/ig/HL7/davinci-epdx/payertopayerbulkexchange.html
• (20) https://build.fhir.org/ig/HL7/davinci-pas/
• (21) https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca