HTI-1 & HTI-2: What Every EHR Vendor Must Prepare for in 2026

Most EHR vendors are already familiar with what HTI requires at a high level. The real challenge begins when teams start preparing their systems for it. Product leaders, architects, and engineering teams are not just interpreting the rules. They are uncovering how their platform actually behaves under those expectations. 

That is where many EHR vendors discover that readiness looks very different in practice than it does in presentations or certification summaries. 

A platform may appear to be in good shape. It may already support APIs, exchange data with outside systems, and include decision support functionality within clinical workflows. On the surface, that can create a sense that the product is already close to where it needs to be.  

Once HTI preparation begins, the questions become more demanding.  

• Do APIs behave consistently across modules? 

• Can decision support functionality be explained clearly enough to meet newer transparency expectations? 

• Can the platform handle updated interoperability, reporting, and governance demands without exposing deeper architectural weaknesses? 

That is why this work rarely stays limited to certification alone. It quickly becomes a platform-readiness issue involving architecture, data behavior, testing, observability, and product governance. 

This article focuses on the practical side of HTI readiness. It looks at what is at stake for EHR vendors, what HTI-1 changes in implementation terms, and what the finalized HTI-2 rule really means now that ONC has narrowed it to specific TEFCA-related provisions rather than the broader set of ideas many earlier summaries assumed.  

What Is at Stake for EHR Platforms 

HTI-1 strengthens expectations around how certified health IT supports interoperability, transparency, and how these capabilities perform in practice. It updates certification criteria, advances interoperability, improves transparency, and supports the access, exchange, and use of electronic health information.  

That matters because healthcare interoperability problems rarely come from one obvious failure. They usually emerge from a mix of issues: old internal data models, inconsistent API behavior across modules, weak normalization between legacy structures and newer exchange requirements, and limited visibility into how decision support logic works in practice. 

For vendors, this becomes an engineering problem before it becomes a compliance problem. If data cannot be mapped cleanly, if APIs return different behavior depending on workflow context, or if predictive DSIs cannot be documented and governed properly, the result goes beyond certification pressure. It becomes roadmap disruption, late rework, heavier QA cycles, and customer-facing delivery risk. 

That is why HTI readiness should be treated as a platform modernization issue rather than a documentation exercise. 

What HTI-1 Changes for EHR Vendors 

HTI-1 introduced several changes that vendors need to treat as active implementation work. 

One major area is the set of updated certification requirements tied to APIs, interoperability behavior, and related criteria. ASTP/ONC’s regulatory materials indicate that several HTI-1 updates were required by December 31, 2025, with the revised requirements now in effect as of January 1, 2026. 

ASTP/ONC later published enforcement discretion notices that temporarily adjusted these expectations after interruptions to testing tools and support resources. For vendors, that does not remove the engineering burden. It simply changes the timeline pressure around it.  

Another major area is decision support interventions, or DSIs. HTI-1 replaced the older clinical decision support approach with the newer DSI criterion in the certification program. That change matters because it pushes platforms toward a clearer and more maintainable level of transparency around how these interventions are developed, evaluated, and presented. Certified health IT must support 13 source attribute fields for evidence-based DSIs and 31 source attribute fields for predictive DSIs. The same materials describe risk-related expectations for predictive DSIs, including validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy.  

This is where many teams realize the work is broader than expected. A predictive or algorithm-driven feature cannot simply exist and be treated as finished. It needs structured support around source attributes, transparency content, update responsibility, and ongoing maintenance. Its clear that responsibility for source attribute content depends in part on whether the certified health IT developer supplies the DSI as part of its module.  

ASTP/ONC certification program resources also continue to tie developers to update deadlines, Real World Testing obligations, and maintenance expectations that go beyond a narrow pass-fail view of certification. In practice, this means readiness depends on more than whether a capability exists. It depends on whether that capability behaves consistently, can be supported across environments, and can be maintained without creating recurring engineering drag.   

What the Finalized HTI-2 Rule Means 

HTI-2 should not be described as a broad finalized expansion across all the ideas that were discussed during the proposed-rule stage. ASTP/ONC’s official HTI-2 final rule page says the rule finalizes certain TEFCA-related proposals from the HTI-2 proposed rule to advance interoperability and support the access, exchange, and use of electronic health information. It also amends the information blocking regulations with definitions related to the TEFCA Manner Exception and implements provisions to support reliability, privacy, security, and trust within TEFCA. At the same time, the program says certain proposals from the HTI-2 proposed rule that were not finalized are being withdrawn.  

So the real implication for EHR vendors is narrower and more precise than many earlier summaries suggested. 

HTI-2, as finalized, reinforces the importance of being able to participate in trusted exchange environments shaped by TEFCA-related governance and trust requirements. It is connected to the broader interoperability environment, but it should not be casually framed as a finalized mandate covering every earlier proposed item around patient-facing APIs, longitudinal records, or additional governance categories unless those specifics are clearly sourced to active finalized requirements.  

Where EHR Vendors Usually Discover the Work 

The engineering effort behind HTI readiness usually shows up in four places. 

The first is the data model. Many EHR platforms still carry legacy structures that were built around internal workflows rather than modern exchange requirements. When certification criteria and exchange expectations tighten, teams often discover that fields do not map cleanly, normalization logic is brittle, or additional data handling layers are needed before external exchange can behave consistently. 

The second is API consistency. A platform may technically support FHIR or patient and population services, but that does not automatically mean behavior is uniform across modules. In practice, readiness work often exposes variation in payload completeness, authorization handling, resource behavior, or data interpretation depending on where the request originates. HTI-1’s updated API-related certification expectations make this harder to ignore.  

The third is decision support governance. Once a vendor has to support transparent source attributes, predictive DSI selection, risk characteristics, and developer disclosures, that work quickly spans product, engineering, clinical stakeholders, compliance, QA, and documentation teams. What looked like a feature-level requirement becomes an operating model issue.  

The fourth is reporting and observability. Modern interoperability compliance increasingly depends on whether the platform can measure, monitor, and explain how certified functionality performs. That means logging, analytics, traceability, and reporting pipelines often need more attention than teams originally expect. 

Why Waiting Gets Expensive 

The cost of delay usually does not show up first as a regulatory penalty. It shows up as an engineering drag. 

Many EHR vendors delay HTI preparation because the product appears to be mostly ready. The APIs are in place. Exchange works in many scenarios. Decision support features are live. From a distance, the platform feels close enough that the remaining work can wait. The problem is that HTI readiness tends to expose issues that are connected to each other. Once one area is reviewed closely, other dependencies start appearing. 

A typical pattern looks like this: 

1. API review exposes inconsistency 
A team starts by checking whether certified API behavior is aligned with updated expectations. Very quickly, it becomes clear that behavior differs across modules, resource handling is uneven, or payload completeness changes depending on workflow context. That turns an API review into a broader product review. 

2. Data mapping becomes the next bottleneck 
Once APIs are examined closely, older data structures and translation logic start becoming visible. Teams realize that clean exchange depends on cleaner normalization, better mapping, and more reliable interpretation of data across the product. Research on interoperability continues to show that fragmented exchange and inconsistent implementation remain major barriers across healthcare systems. 

3. Decision support work expands beyond engineering 
If the product includes evidence-based or predictive DSIs, readiness is no longer limited to code changes. HTI-1 guidance requires support for source attributes, with 13 source attribute fields for evidence-based DSIs and 31 for predictive DSIs, along with clearer treatment of risk-related characteristics for predictive interventions. That means product, engineering, clinical, QA, and compliance teams all get pulled into the effort. 

4. Testing and reporting grow faster than expected 
Teams then discover that the job is not simply to make a feature exist. It has to behave consistently, be supportable, and stand up under testing, monitoring, and certification-program expectations. ASTP/ONC’s certification materials and enforcement notices make clear that this work is tied to active program deadlines and maintenance obligations, not just future planning.  

This is why waiting gets expensive. The later readiness work begins, the more likely it is that roadmap work, remediation work, testing work, and compliance work all collide at the same time. What looked like a contained regulatory update turns into platform rework under deadline pressure. 

A Roadmap for 2026 HTI Readiness 

The most useful way to approach HTI readiness is not as one large compliance project. It works better as a staged execution plan, where each step reduces a specific kind of risk before the next one begins. 

Step 1: Confirm Where the Platform Is Exposed 

Start with a readiness assessment that goes deeper than certification status. Review where API behavior varies across modules, where data structures do not align cleanly with updated exchange expectations, and where decision support functionality may fall under the DSI criterion. ASTP/ONC’s certification resources continue to point developers to updated criteria, deadlines, and test-method expectations, so the goal here is to find what will create rework later.  

This first step should answer a few direct questions: 

• Which certified or customer-facing APIs are most likely to behave inconsistently? 

• Which data elements require mapping, normalization, or cleanup before exchange becomes reliable? 

• Which interventions in the product qualify as DSIs? 

• Where is the platform missing the documentation, source attributes, or governance needed to support those DSIs? 

Step 2: Fix the Areas That Will Create the Most Downstream Rework 

Once the exposure points are visible, the next step is prioritization. Do not try to modernize everything at once. Focus first on the areas most likely to slow later phases: 

• API consistency across modules 

• Data normalization and exchange reliability 

• DSI transparency and governance support 

• Monitoring and reporting needed for operational visibility 

This is where many teams make the mistake of treating HTI as an interoperability-only task. In reality, the work often spans architecture, product behavior, release coordination, and observability. If that is not recognized early, later phases become much harder to control. 

Step 3: Validate Under Real Workflows, Not Ideal Scenarios 

A platform can look ready in a controlled review and still create major issues in production-style usage. Testing, therefore, needs to go beyond narrow demonstrations. Teams should validate exchange behavior across realistic module combinations, workflow paths, and downstream integration scenarios. ASTP/ONC continues to emphasize Real World Testing as part of the certification-program context, even while enforcement discretion has affected some 2026 testing obligations. 

At this stage, teams should be able to answer: 

• Does the same API behave consistently across modules? 

• Does the receiving system interpret the returned data correctly? 

• Are DSI-related transparency elements maintained correctly when products are updated? 

• Can the product support ongoing monitoring instead of one-time validation? 

Step 4: Shift from Deadline Response to Ongoing Control 

The final step is operational discipline. HTI readiness is not something teams finish once and forget. EHR products keep changing as new modules are released, existing integrations expand, and decision support capabilities evolve. That means teams need a repeatable way to review API consistency, data handling, DSI governance, and reporting whenever the product changes. ASTP/ONC’s ongoing certification program updates and resource publishing make that expectation clear.  

This staged approach gives buyers something concrete to work from. It also changes internal conversation. Instead of asking, “Are we compliant yet?” teams can ask, “What do we need to stabilize first so this does not become expensive later?” 

What Healthcare Technology Leaders Should Do Now 

For leadership teams, the biggest mistake is treating HTI readiness as a task for compliance alone. 

That approach usually fails because the work does not stay inside compliance. It reaches engineering priorities, product planning, testing, interoperability architecture, and operational support. The leaders who handle this best usually do four things early. 

1. Treat HTI Readiness as a Platform Decision Rather Than a Certification Decision 

If leadership frames this as a narrow certification update, the work will likely be delegated too low and too late. HTI-1 reaches updated certification criteria, API behavior, DSIs, and broader transparency and maintenance expectations. HTI-2, as finalized, reinforces TEFCA-related trust and exchange obligations rather than serving as a vague second-wave placeholder.  

The internal leadership question should be: 

Which parts of the platform will create the most engineering drag if we wait? 

That question is far more useful than: 

Which deadline do we have to hit? 

2. Put Named Ownership on the Work 

HTI readiness tends to stall when everyone assumes someone else is covering it. A better approach is to assign clear ownership across four areas: 

• Product and certification interpretation 

• Interoperability and API architecture 

• DSI governance and documentation 

• Testing, observability, and reporting 

That matters because DSI support, in particular, can easily become unclear without explicit ownership. ASTP/ONC materials show how much detail is expected around source attributes and predictive DSI characteristics, which means this cannot live as an informal side task. 

3. Decide Early Whether the Team Has Enough Execution Capacity 

A lot of vendors understand the regulation well enough. What they do not always have is enough capacity to execute the work while continuing to ship product. That is where delays usually begin. 

Leadership teams should evaluate whether they can realistically handle: 

• API remediation 

• Data model and normalization work 

• DSI documentation and governance 

• Testing and certification support 

• Monitoring and reporting readiness 

Inside the current product and engineering capacity. If the answer is no, that should be addressed early, before the work starts competing with roadmap commitments. 

4. Use the Next Few Months to Reduce the Most Expensive Unknowns 

Because ASTP/ONC’s recent materials continue to point to HTI-1-related updates, enforcement discretion, and evolving certification-program guidance, the smartest near-term move is to reduce uncertainty now.   

For most EHR vendors, that means: 

• Identify the highest-risk API and exchange workflows 

• Confirm where legacy data structures will create problems 

• Inventory DSIs and determine where transparency support is incomplete 

• Check whether monitoring and reporting are usable in practice 

That is the level of action that tends to impress buyers because it is concrete, technical, and immediately useful. 

The Immediate Step 

At this stage, the focus should shift from understanding HTI to identifying where the platform will not hold up under real conditions. The quickest way to do that is through a targeted assessment that highlights API inconsistencies, data mapping gaps, DSI exposure, and limitations in monitoring or reporting. The goal is not to review everything, but to surface the areas that will create the most rework later. 

If you have reached this part of the blog, this likely means your organization is already thinking through these questions. Our Healthcare Interoperability Solutions help healthcare technology teams improve FHIR APIs, strengthen data exchange, and modernize the parts of the platform that matter most. You can reach out to us at info@nalashaa.com. Early action here can prevent a much larger remediation effort later. 

Frequently Asked Questions 

Where do EHR vendors typically struggle when preparing for HTI-1? 

Most challenges do not come from missing features, but from how existing capabilities behave across the platform. Common issues include inconsistent API behavior between modules, difficulty mapping legacy data to updated exchange requirements, and lack of structured governance for decision support interventions. These gaps usually become visible only when teams begin validating real workflows. 

How much engineering effort does HTI readiness usually require? 

The effort depends on how the platform has evolved over time. Systems with consistent APIs, clean data models, and well-documented decision support logic tend to move faster. Platforms with legacy structures, fragmented integrations, or limited observability often require deeper architectural work. In many cases, the effort extends beyond engineering into product, QA, and compliance teams. 

Does supporting FHIR APIs mean a platform is already HTI-ready? 

Not necessarily. Many platforms already support FHIR, but HTI readiness depends on whether those APIs behave consistently across modules and workflows. Differences in payload completeness, authorization handling, and data interpretation can create issues during certification and real-world exchange scenarios. 

What qualifies as a Decision Support Intervention under HTI-1? 

Any feature that provides patient-specific recommendations, alerts, or guidance based on clinical data may fall under the DSI criterion. This includes both evidence-based rules and predictive models. The key requirement is not just functionality, but the ability to explain how the intervention works, what data it relies on, and what its limitations are. 

Why does DSI transparency require cross-functional effort? 

Supporting DSIs involves more than engineering implementation. Source attributes, clinical logic, model behavior, and risk characteristics need input from product teams, clinicians, compliance, and QA. Without clear ownership across these areas, maintaining transparency and consistency becomes difficult as the product evolves. 

What does HTI-2 actually require EHR vendors to do today? 

The finalized HTI-2 rule is focused on TEFCA-related provisions and trusted exchange requirements. It does not make every previously proposed interoperability expansion an active requirement. Vendors should focus on aligning with TEFCA-related expectations and avoid assuming broader obligations unless they are clearly part of finalized rules. 

How long does HTI readiness typically take for an existing platform? 

Timelines vary depending on the current state of the system. A focused platform with clean architecture may move through readiness in a few months. Platforms that require API remediation, data normalization, DSI governance, and improved reporting can take significantly longer. The earlier teams begin identifying gaps, the more manageable the effort becomes. 

What is the biggest risk in delaying HTI preparation? 

Delay increases the likelihood that multiple issues surface at the same time. API inconsistencies, data mapping problems, decision support gaps, and testing requirements often appear together. This can turn a structured preparation effort into a compressed engineering exercise that affects product timelines and delivery confidence. 

How can teams tell if they are actually ready for HTI? 

Readiness becomes clear when the platform behaves consistently under real conditions. APIs should return predictable results across modules, data should map cleanly to exchange standards, DSIs should have complete and maintainable transparency support, and monitoring should provide visibility into how the system performs in production. 

When should EHR vendors start working on HTI readiness?