HTI-5 Explained: How a Quiet Rule Shift Moved Healthcare Terminology from Compliance to Execution

If you have been in health data long enough, you know the old routine.

Step one: a regulation defines what “must” be available. Step two: certification turns that “must” into checkboxes. Step three: the market pretends the checkboxes mean the data will actually work in the wild.

HTI-5 is a loud document with a quiet consequence.

HTI-5 refers to the upcoming deregulatory actions under the Health Data, Technology, and Interoperability (HTI) framework, aimed at reducing regulatory burdens in health information technology. Formally, HTI-5 is a proposed rule from HHS ASTP/ONC, published December 29, 2025, titled Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions To Unleash Prosperity. Its stated goal is to reduce burden and offer more flexibility by removing or revising parts of the ONC Health IT Certification Program, while also revisiting pieces of the information blocking framework.

That sounds like inside baseball. It is. But it matters because certification has been the de facto enforcement mechanism for a lot of the “terminology hygiene” that makes interoperability feel real.

Background on HTI Regulations

The HTI regulations are part of a series of rules established by the Assistant Secretary for Technology Policy (ASTP) and the Office of the National Coordinator for Health Information Technology (ONC). These regulations are designed to enhance interoperability and the secure exchange of electronic health information. The HTI-5 rule is anticipated to continue this trend by focusing on deregulation to foster innovation and reduce compliance costs for healthcare organizations.

Key Aspects of HTI-5 Deregulation

1. Executive Order 14192: Signed on January 31, 2025, this order emphasizes the need to reduce private expenditures related to federal regulations, aligning with the goals of HTI-5 to lessen the regulatory burden on health IT entities.
   

2. Unified Agenda: The HTI-5 rule is included in the Unified Agenda for Spring 2025, indicating that it will outline specific deregulatory actions aimed at streamlining compliance processes and enhancing the efficiency of health data management.

   
   

3. Stakeholder Engagement: The ASTP/ONC is expected to engage with stakeholders to gather input on how to effectively implement these deregulatory measures while ensuring that the integrity and objectives of health information technology standards are maintained.

   
   

Implications of HTI-5

The HTI-5 deregulation is anticipated to have significant implications for healthcare organizations, including:

• Reduced Compliance Costs: By easing regulatory requirements, organizations may experience lower costs associated with compliance, allowing them to allocate resources more effectively.
  

• Enhanced Innovation: Deregulation may encourage innovation in health IT solutions, as organizations will have more flexibility to develop and implement new technologies without the constraints of stringent regulations.
  

• Improved Interoperability: The focus on deregulation is likely to support the overarching goal of improving interoperability among health information systems, facilitating better data sharing and patient care.

  
  

  In summary, HTI-5 represents a strategic move towards deregulation in the health IT sector, aiming to balance the need for compliance with the desire for innovation and efficiency in healthcare delivery.
  

First, what HTI-5 actually is, and why it exists

ASTP/ONC is proposing to pull back on certain certification requirements and some related administrative and reporting obligations. In the proposed rule’s executive summary, the agency is explicit: this is a deregulatory package intended to reduce burden on providers and developers, and to support innovation by removing or revising certain certification criteria and provisions.

Two details in the HTI-5 text are especially relevant to where terminology “gets enforced” going forward:

1) The certification program is being streamlined, with a heavier tilt toward API and FHIR-forward priorities. The rule frames a future where API capabilities remain central, while other criteria are candidates for removal or descoping, particularly where the agency believes capabilities are already widely adopted.

2) Information blocking definitions are being modernized to explicitly contemplate automation and autonomous AI. HTI-5 proposes revising definitions such as “access” and “use” to emphasize that they include automated means, explicitly including autonomous AI systems. That is a big signal about how the government expects software to behave as the ecosystem becomes more agentic. The throughline is clear: keep the rails that matter for nationwide exchange and app ecosystems and loosen the parts that feel duplicative or burdensome.

The history in plain English: how we got here

To understand HTI-5, you have to understand what it is reacting to. The ONC certification program has been evolving since the early Meaningful Use era. In HTI-5’s own regulatory history section, the agency walks through how standards, implementation specifications, and certification criteria have been used since the 2011 Edition and the 2014 Edition to define what certified EHR technology must do.

That era trained the industry to think like this:

• If it is in certification, vendors will build it.

• If vendors build it, it becomes “normal.”

• If it becomes normal, regulators can expect it.
  

Over time, certification became a surrogate enforcer not just for transport standards, but for the messy semantics underneath: value sets, mappings, and normalization behaviors that make downstream use cases possible. HTI-5 does not delete the idea of standardization. It proposes narrowing what must be certified and how much process overhead sits on top of it.

Which leads to the real question you are asking. So, did HTI-5 change who “owns” terminology? Not on paper. Not in a single dramatic sentence. But functionally, yes, because it nudges the center of gravity away from certification checklists and toward operational use cases.

Here is the blunt reality: most terminology debates are not actually won in standards committees or certification test scripts. They are won when money is on the line and workflows break. And right now, the most financially and operationally intense interoperability use case in the country is prior authorization.

CMS’ Interoperability and Prior Authorization Final Rule (CMS-0057-F) was released January 17, 2024, with major payer requirements staged into 2026 and primarily 2027 for the API requirements. That rule is not asking politely for nice data. It is forcing the industry toward machine-interpretable exchange at scale.

So even if ONC certification becomes less prescriptive about deep semantics in certain areas, the market does not get a free pass. It just gets a different judge. Instead of “Will you pass certification,” the question becomes: “Will your automation survive contact with the real world?”

Why terminology stops being a compliance checkbox and becomes an execution requirement

Terminology is where interoperability either becomes magic or becomes customer support tickets. You can have FHIR everywhere and still fail if your semantics are mush:

• If a condition is recorded in one system in SNOMED terms, mapped loosely to ICD-10 for billing, and then grouped differently by another system’s rules engine, automation does not “almost work.” It fails.

  
  

• If medication lists are a stew of RxNorm concepts, NDCs, and free text with inconsistent normalization, real-time benefit and automated authorization logic turns into manual work.

  
  

• If procedures and services are interpreted differently across payer and provider logic, you do not get clean automation, you get disputes, denials, and appeals.
  

HTI-5’s deregulatory direction basically says: we will keep building the national floor, but we are not going to be the only mechanism that forces excellence in execution. And prior auth, quality programs, network management, and risk contracting are happy to take over as the enforcement layer because they come with a built-in motivational tool: consequences.

Two voices from inside the shift

Interstella’s CEO Leo Pak describes the moment like this: “For years, healthcare treated terminology like a paperwork problem. Now it is becoming an automation problem. When the use case is real-time decisions, semantics stop being academic. They become operational truth.”

Shelley Brown, a privacy and policy expert and healthcare data attorney, frames it from the governance side: “When enforcement shifts from certification to real-world exchange, governance has to move upstream. You cannot bolt on privacy, provenance, or semantic consistency after the data has already multiplied across systems. The moment you automate, you amplify both value and risk.”

In other words, the shift is not just technical. It is legal, operational, and reputational. If your terminology and mappings are inconsistent, you are not merely “noncompliant.” You are unreliable.

What this means for HIEs, payers, providers, and community ecosystems

If you run an HIE, a payer data platform, a value-based care network, or a community care hub, HTI-5 is basically telling you:

• Do not confuse a lighter certification footprint with easier interoperability.

• Expect automation-driven programs to define what “good data” means.

• Invest in semantic governance like it is infrastructure because it is.
  

And if you are building anything AI-adjacent, HTI-5’s proposed updates to information blocking definitions are a warning label: automated access and use is still access and use, and it will be treated as such.

Where Interstella Lynqsys fits, and how we help

Interstella Lynqsys exists for exactly this moment. We help organizations move from “data exchanged” to data that can be trusted, governed, and executed on, in near real time.

What we do

• Real-time ingestion and refinement of healthcare data so you are not living in yesterday’s batch jobs.

• Inline data quality and semantic normalization so terminology becomes consistent before it hits downstream workflows.

• AI readiness by design, so analytics and agentic workflows are built on dependable signal instead of fragile mappings.

Who we help

• Health Information Exchanges (HIEs) and HIE-adjacent data utilities

• State and regional data organizations, including Medicaid and multi-agency ecosystems

• Payers and provider networks trying to operationalize interoperability for prior auth, quality, and care coordination

• Integration partners who need a clean, governed data backbone that makes their applications actually work
  

HTI-5 sets a floor. CMS-0057 and other high-stakes use cases set the ceiling. The gap in between is where projects either become scalable automation or become expensive manual cleanup. Interstella Lynqsys is built to close that gap.