HTI-5 Proposed Rule Implementation: Technical Roadmap for Payer Revenue Optimization

‍

Most payer CTOs encounter the HTI-5 proposed rule as a compliance headline and move on. That is the wrong read. ASTP/ONC published the HTI-5 proposed rule on December 22, 2025, with the public comment window closing February 27, 2026. Those dates matter because the final rule will land squarely inside FY26/FY27 capex and opex planning cycles and the technical decisions made now will determine whether the organization is positioned or caught flat-footed.

‍

This guide is written for CTOs and VPs of Engineering at regional health plans, Medicare Advantage (MA) organizations, and PE-backed payers actively scoping infrastructure modernization. 

‍

We'll go over:

‍

• HTI-5's technical requirements
• How to assess the organization's readiness gaps
• A phased implementation roadmap to turn compliance into a competitive advantage

‍

Understanding HTI-5 Requirements for Payer Technology Infrastructure

‍

Removing 34 Legacy Functional Criteria to "Clear the Decks" for FHIR

‍

The headline move in HTI-5 is deregulatory. The HTI-5 fact sheet from ASTP/ONC confirms the rule removes 34 and revises 7 out of 60 existing certification criteria in the ONC Health IT Certification Program. This includes the removal of AI "model card" requirements from decision-support criteria. This is not simplification for its own sake. ASTP is clearing out a document-centric, CDA-era compliance layer so FHIR can become the primary architecture not just an add-on sitting on top of legacy infrastructure.

‍

For payers, the opportunity is greater architectural flexibility. The risk is that certification now covers less surface area.

‍

Here are some areas requiring tighter due diligence:

‍

• Vendor contracts
• API quality
• Security baselines
• "No information blocking" warranties

‍

Why ASTP Is Cutting the Checklist While Sharpening Information Blocking Enforcement

‍

HTI-5 reduces certification burden while simultaneously sharpening Information Blocking enforcement. The shift is from checklist compliance passing an audit  to conduct-based accountability. It is the difference between showing a driver's license and actually driving safely. Vendors who previously pointed to certification as a compliance proxy can no longer rely on that argument. Payer CTOs should update contracts to include explicit warranties against information blocking practices and require equitable migration paths if a vendor is sanctioned.

‍

FHIR API Requirements for MA and Regional Health Plans

‍

HTI-5 explicitly frames FHIR-based APIs and automation as the next foundation, including autonomous AI systems accessing electronic health information. For payers building agentic member and provider experiences benefit navigation copilots, automated prior auth routing, real-time eligibility agents  this regulatory posture is a tailwind if the data infrastructure is ready for it.

‍

HTI-5 Timeline and CMS Submission Windows

‍

The CMS-0057-F fact sheet is where operational deadlines live. Operational and process provisions generally begin January 1, 2026. API development requirements generally begin January 1, 2027. The must-ship set includes a Patient Access API (adding prior authorization status), a Provider Access API for in-network providers, a Payer-to-Payer API with opt-in patient permission, and a Prior Authorization API that must support explicit approve/deny/request-more-info responses within 72 hours expedited and 7 calendar days standard. Payers who wait for HTI-5 final rule publication to begin scoping will already be behind the CMS-0057-F API clock.

‍

HTI-5 Exposes Hidden Technical Debt in Payer Data Architecture

‍

HTI-5 does not create the technical debt. It removes the excuses that kept it off the roadmap.

‍

Real-Time Data Access Requirements vs. Batch ELT Processing Reality

‍

Most regional payers built their enterprise data warehouses (EDW) on batch ELT processes nightly or weekly jobs moving data from claims processors into Snowflake or a similar warehouse. That works for retrospective reporting. It fails the moment an API consumer queries real-time eligibility or current claims status. FHIR APIs demand latency measured in seconds. The batch pipeline was never designed for that contract.

‍

Why Payers Can No Longer Use Legacy System Limitations as an Information Blocking Exception

‍

The HTI-5 proposed rule in the Federal Register proposes changes to Information Blocking definitions and exceptions that narrow the room to cite "the manner requested" as a cover for unfair contract terms. If the legacy mainframe claims processor cannot surface data through an API, that is no longer an acceptable answer. It is now a remediation project.

‍

EDI Transaction Dependencies

‍

Payer operations run on EDI. CMS administrative simplification guidance identifies the X12 837 (claims), 835 (remittance advice), 834 (benefit enrollment), and 278 (prior authorization) as the adopted standard transactions that form the backbone of payer plumbing. FHIR APIs need to translate these batch EDI payloads into structured, real-time queryable resources. That is not a wrapper problem. It is a data architecture problem.

‍

Delivering Real-Time Responses from Batch Data

‍

Claims experience a typical 30 to 60 day lag between service delivery and final adjudication — the unprocessed portion actuaries call IBNR. The FHIR API cannot pretend that lag does not exist. 

‍

The right model is to define and publish freshness semantics clearly:

‍

• What is real-time (eligibility) 
• Near-real-time (prior auth status)
• Delayed (adjudicated claims)
• Corrected-later (adjustments and COB)

‍

Under HTI-5's conduct-based framework, surfacing incomplete data as complete is a potential Information Blocking issue, not just an accuracy problem.

‍

FHIR Resource Mapping for Core Payer Operations

‍

Coverage Resource Implementation for Eligibility Verification

‍

Eligibility is the source of truth in payer operations. Every downstream process claims, risk adjustment, quality metrics, provider attribution depends on it being accurate and current. The FHIR Coverage resource is the standardized representation of member eligibility, including effective dates, termination dates, and plan details. In a delegated-risk MA model, Coverage must unify multiple delegated entities under one member identity so downstream agents do not mis-route benefits.

‍

ExplanationOfBenefit Resource for Claims 835/837 Translation

‍

The ExplanationOfBenefit resource is the most complex FHIR resource for payers to implement. It must reconcile data from the 835 (remittance advice) and the 837 (procedure and diagnosis codes), surface adjudication status, and do so with honest lag disclosure. The CARIN Consumer Directed Payer Data Exchange implementation guide provides the payer-specific EOB profile that should be the engineering baseline the only real path to converting "claim plus adjudication plus adjustments" into a member-usable, queryable timeline without forcing members through PDF archaeology.

‍

Member Demographics and NPI/TIN Matching

‍

The FHIR Patient resource handles member demographics. Practitioner and Organization resources cover provider data. The payer-specific challenge is NPI-to-TIN matching: NPI-1 identifies individual clinicians, NPI-2 identifies organizations, and accurate mapping is what makes provider attribution reliable downstream. If the EMPI (Enterprise Master Patient Index) is not clean, the Patient resource implementations will surface identity mismatches that create both compliance risk and care coordination failures.

‍

Formulary and Provider Directory Resources for Member Self-Service

‍

Formulary and Provider Directory resources profiled in the Da Vinci PDex Plan Net Implementation Guide are the technical foundation for member self-service that actually works. The goal is enabling "what's covered, what requires prior auth, is this provider in-network" queries in seconds, without a call to member services. That is both a STARS-relevant member experience and a direct administrative cost reduction.

‍

Current State Assessment for HTI-5 Readiness

‍

Which Platforms Need FHIR Capability Now?

‍

Catalog every system that touches member data: core claims processor, eligibility system, member portal, care management platform, and analytics warehouse. For each, ask if it serves FHIR R4 responses with acceptable latency today. Most payers will find the answer is "no" across most of their core platforms. That inventory is the remediation backlog.

‍

Technical Debt Assessment

‍

CDA-based systems were built to exchange documents, not data. Legacy care management and clinical decision support tools that speak CDA natively cannot be queried the way FHIR demands. Identify every CDA dependency in the data flow and flag it as a remediation item. Some will be vendor problems; others will require middleware built internally.

‍

Epic Payer Platform, Innovaccer, Arcadia HTI-5 Status

‍

The EDW vendor's HTI-5 posture matters as much as the payer's own. When evaluating Epic Payer Platform, Innovaccer, Arcadia, or similar platforms, do not accept "FHIR-ready" marketing claims at face value. Ask specifically about FHIR R4 Coverage resource implementation, EOB profile compliance with CARIN Blue Button, and real-time API latency benchmarks under production open enrollment load.

‍

Member Portal Readiness 

‍

Today's member portal was yesterday's compliance answer. HTI-5 points toward a future where members access data through third-party apps and automated agents calling The FHIR APIs directly. That shift means the portal's underlying data access layer needs to be rebuilt around API-first principles, not retrofitted on top of a document-generation engine.

‍

Phased Implementation Roadmap Aligned with Payer Operational Cycles

‍

Phase 1: Platform Selection and Architecture Decisions

‍

Phase 1 builds the foundational layer: 

‍

• FHIR server technology
• API gateway
• Connection to source-of-truth systems 

‍

Start with an API facade that serves the coverage resource against the eligibility system as a proof of concept. This validates architecture under real conditions without a big-bang launch risk.

‍

Phase 2: Legacy System Integration Without Disrupting Claims Processing

‍

The fear of disrupting EDI-based claims processing causes most implementations to stall here. The answer is not to touch the EDI pipeline directly. Build an event-driven integration layer that consumes EDI events and populates the FHIR data store asynchronously. The claims processor keeps operating. The FHIR API serves data from the integration layer with honest lag disclosure. Add prior auth status into Patient Access API pathways here, using the 72-hour and 7-calendar-day decision timeframes as acceptance tests.

‍

Phase 3: Member-Facing Application Deployment for Portal and Mobile

‍

Phase 3 deploys member-facing capabilities: provider directory search, formulary lookup, claims history, care gap notifications, and third-party app authorization. This is also where full EDI-to-FHIR conversion depth for claims and remittances gets completed  because that is where data quality and reconciliation complexity spikes most. Do not attempt it in Phase 1 or 2.

‍

Open Enrollment Considerations and STARS Reporting Cycles

‍

Plan phases around the operational calendar. Open enrollment and STARS measurement periods are blackout windows for major infrastructure changes. Phase 1 targets Q1 to Q2. Phase 2 fits Q3. Phase 3 deploys post-open-enrollment in Q1 of the following year. Sequencing this way prevents a compliance-driven change from creating a STARS-damaging service disruption.

‍

Architecture Decision Framework for HTI-5 Compliance

‍

How HTI-5 Influences Snowflake vs. Databricks Selection

‍

Snowflake's concurrent query performance and separation of compute and storage make it better suited for serving real-time API queries against large claims and eligibility datasets. Databricks' unified batch and streaming processing is more useful when the primary constraint is the data engineering pipeline feeding the FHIR data store. Many mature payer architectures use both Databricks for engineering and Snowflake for query serving. The key is identifying which layer is the bottleneck before deciding where to invest first.

‍

Why HTI-5's Removal of MFA Certification Doesn't Mean Payers Can Skip It

‍

HTI-5 removes MFA as a certification criterion. That is not a security signal but instead ASTP trusting organizations to implement appropriate controls without mandating a specific mechanism. The API infrastructure still needs OAuth 2.0, SMART on FHIR authorization, audit logging, and rate limiting. The business case for serious security investment is concrete: HHS OCR reports that Change Healthcare notified OCR of approximately 192.7 million impacted individuals by July 31, 2025. A HIPAA Security Rule NPRM fact sheet recommends vulnerability scanning at least every six months and penetration testing at least every 12 months. Budget for these controls explicitly.

‍

Event-Driven vs. Batch Synchronization Patterns for FHIR Data

‍

The practical architecture for most payers is a hybrid: event-driven messaging (Kafka, AWS EventBridge, or similar) propagates eligibility and claims events from source systems into the FHIR data store in near real time, while batch reconciliation jobs catch anything the event stream misses. This gives API consumers acceptable latency without requiring a full streaming rewrite of the core claims pipeline.

‍

Data Consistency Strategies for Handling Claims Lag in Real-Time APIs

‍

Build explicit status fields into the FHIR EOB responses that distinguish adjudicated claims, pending claims, and estimated liability. Surface the as-of date prominently so consuming applications can make appropriate decisions. This is not just good engineering under HTI-5's conduct-based framework, representing incomplete data as complete is a potential Information Blocking exposure.

‍

HTI-5 as Strategic Revenue Opportunity for MA Plans

‍

Connecting API Access and Automated Agents to STARS Ratings

‍

CMS confirms 2025 Star Ratings directly determine 2026 MA quality bonus payments making STARS a near-term revenue lever inside a three-to-five-year PE hold. FHIR-powered member applications that surface care gap reminders, appointment options, and prescription refill prompts are directly additive to STARS performance.

‍

Administrative Cost Reduction Through True Member Self-Service

‍

CAQH's 2024 Index estimates $222 billion is avoided annually through automation, with an additional $20 billion unlockable by transitioning to fully electronic administrative workflows and an average of 70 minutes saved per patient visit. The 2023 CAQH Index puts tracked administrative transaction spend at $89 billion, with $18.3 billion in savings available through full electronic transition. These are the numbers the board and PE sponsors understand  and they are the ROI frame for FHIR infrastructure investment.

‍

Care Gap Closure Automation Using FHIR-Based Member Data Access

‍

Gaps in care are simultaneously a quality problem and a revenue problem. Closing a care gap improves a STARS quality measure and may surface HCC codes that raise RAF scores and CMS revenue. FHIR-based analytics that continuously monitor member care gap status and trigger automated outreach turn the HTI-5 data infrastructure into an active revenue management tool.

‍

Prior Authorization Streamlining with Real-Time Eligibility and Clinical Data APIs

‍

The baseline here is sobering. Only 28% of prior authorization transactions were fully electronic in 2022. Most organizations are implementing a mixed reality of portals, fax, and phone while being expected to report metrics and hit CMS timeframes. FHIR-based real-time eligibility and clinical data APIs can compress the prior auth cycle dramatically. CMS-0057-F estimates at least $15.8 billion in provider-side paperwork savings over 10 years, a direct argument for treating API enablement as a network strategy that benefits both sides of the payer-provider relationship.

‍

Alignment with Broader Interoperability Strategy

‍

CMS Interoperability Final Rule vs. HTI-5

‍

CMS-0057-F established the payer mandate for FHIR APIs  the "what." HTI-5 sharpens the technical and behavioral standards that define what compliant implementation looks like. Understanding both together is what separates organizations that will pass enforcement scrutiny from those that built technically compliant but operationally hollow APIs.

‍

Why Participating in TEFCA No Longer Grants Immunity from Information Blocking

‍

HTI-5 specifically proposes removing the TEFCA-specific manner exception. TEFCA participation shields organizations from Information Blocking consequences. "Use TEFCA only" is no longer a viable blanket response to modern API access requests. Payers who built their interoperability strategy partially around TEFCA as an Information Blocking safe harbor need to revisit that posture now.

‍

Da Vinci and CARIN Blue Button Implementation Guides for Payers

‍

The CARIN Consumer Directed Payer Data Exchange guide and the Da Vinci PAS guide are the practical bridge between FHIR specification and real-world payer use cases. CARIN profiles the EOB resource for consumer-facing claims access. Da Vinci covers prior authorization workflows, payer-to-payer exchange, and provider access patterns. These should be the engineering team's working documents, not background reading.

‍

Future-Proofing for CMS-0057-F and Emerging AI/Agentic Governance

‍

The trajectory is clear: more automation, more API-driven workflows, and AI agents acting on member data autonomously. HTI-5 explicitly references autonomous AI systems in its framing of electronic health information access. The FHIR infrastructure built for HTI-5 compliance today is the data layer those AI applications will run on tomorrow. Build it with that architecture in mind from the start.

‍

Action Plan and Technical Readiness Assessment

‍

Evaluating Current Infrastructure vs. Conduct Standards

‍

A useful readiness assessment measures capability, not certification posture. 

‍

Evaluate five domains:

‍

• Data timeliness and freshness semantics (can the payer publish and honor them?)
• Member identity and consent model (can it support CMS opt-in/opt-out requirements without bespoke logic per product line?)
• API operating model (rate limiting, auditability, third-party developer onboarding)
• FHIR resource coverage (Coverage, EOB, Patient, Practitioner, Formulary, Provider Directory)
• Security control coverage (MFA, scanning cadence, pen testing frequency)

‍

Any domain below three out of five is a FY26 remediation priority.

‍

Presenting to the Board and PE Sponsors

‍

PE-backed payers need an exit-ready financial narrative. The reframe that works is positioning HTI-5 infrastructure investment as a STARS optimization and administrative cost reduction program with compliance as the forcing function. CMS-0057-F's Federal Register filing estimates total payer implementation costs beginning at roughly $182 million in years one and two  a real number to anchor board conversations, especially set against CAQH's $20 billion automation upside and Urban Institute's STARS bonus economics.

‍

Vendor RFP Requirements

‍

The worst HTI-5 implementation decision is buying a rigid functional module from a vendor who sells "HTI-5 compliance" as a product feature. What payers actually need is flexible infrastructure that adapts as the regulatory and technical landscape evolves. The RFP should require documented FHIR R4 capabilities, real-time API latency benchmarks under peak load, CARIN Blue Button and Da Vinci conformance testing results, and a clear vendor roadmap for future FHIR version support. Contracts should include warranties against information blocking practices and allow equitable migration if the vendor is sanctioned.

‍

Technical KPIs and Business Outcome Measurement

‍

Define success at two levels. Technical KPIs: FHIR API response latency under two seconds at the 95th percentile, eligibility data freshness within 24 hours of payer source update, and EOB accuracy rate against adjudicated claims. Business outcomes: STARS rating movement, member self-service deflection from call center volume, care gap closure rate improvement, and prior authorization cycle time reduction. Both metric sets belong in the executive dashboard from day one  not added later when someone asks for a compliance report.

‍

Final Thoughts

‍

The HTI-5 proposed rule is, on the surface, a compliance requirement. For payer CTOs willing to look past that framing, it is a forcing function. It removes the excuses that kept real-time interoperability on the backlog, narrows the Information Blocking escape hatches that legacy contract language depended on, and makes the data platform modernization payer CTOs have been advocating for a business necessity rather than an engineering preference. STARS economics, CAQH-quantified administrative savings, and CMS-mandated prior authorization automation combine to make this a revenue and cost optimization program — not a cost center. The window to begin gap assessment, scope FY26 budget requests, and pressure-test vendor roadmaps against the January 2027 API deadlines is right now.

‍

Frequently Asked Questions

‍

‍

When HTI-5 is finalized, how can Invene help our organization navigate the transition?

‍

HTI-5 is a deregulatory proposed rule from ASTP/ONC. Its core focus is stripping back more than half of the existing certification criteria for health IT developers and resetting the certification program around FHIR-based APIs. For payer organizations, the practical impact is twofold. First, the shift toward FHIR as the foundational interoperability standard will put pressure on legacy data infrastructure that was not built around API-first exchange. Second, because HTI-5 proposes removing several privacy and security certification criteria, organizations will need to independently verify that their vendor products still meet HIPAA requirements, rather than relying on certification as a proxy.

‍

Invene works with payer organizations on exactly these pressure points. Their team builds and modernizes data infrastructure with FHIR-native architecture, replaces brittle EDI-dependent pipelines with modern data platforms, and ensures PHI handling is compliant by design rather than by certification checkbox. Invene also implements AI on that infrastructure, supporting workflows like prior authorization review and care gap identification. Because Invene works exclusively in healthcare, clients are not starting from scratch on domain context. Engagements begin with a discovery phase to assess current infrastructure and identify the highest-value gaps before any build work starts.

‍

What is the core difference between the HTI-5 proposed rule and previous ONC health IT certification rules?

‍

HTI-5 shifts from a prescriptive functional checklist to a conduct-based framework. It removes 34 and revises 7 of 60 existing certification criteria while sharpening Information Blocking enforcement. The emphasis moves from "did the organization pass the certification audit?" to "is the organization actually enabling data access as the regulation requires?" For payers, vendor due diligence standards need to become more rigorous, not less, as certification covers a smaller surface area.

‍

How does HTI-5 interact with the CMS-0057-F deadlines payers are already tracking?

‍

HTI-5 sets the technical posture and conduct standards. CMS-0057-F sets the operational deadlines. The must-ship APIs  Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization  are driven by CMS-0057-F, with API development generally required by January 1, 2027. HTI-5 shapes what compliant implementation looks like for those APIs, particularly around Information Blocking conduct and FHIR API quality.

‍

Does participating in TEFCA exempt a payer from HTI-5 Information Blocking requirements?

‍

No. HTI-5 specifically proposes removing the TEFCA-specific manner exception because of observed misunderstanding that TEFCA participation provides Information Blocking immunity. It does not. Organizations that built compliance strategy around TEFCA as a safe harbor need to reassess that posture and ensure their FHIR API implementations meet HTI-5's full conduct-based requirements independently.

‍

How should a payer CTO approach the Snowflake vs. Databricks decision in the context of HTI-5?

‍

The right answer depends on the primary bottleneck. If the constraint is serving real-time API queries against large claims and eligibility datasets, Snowflake's concurrent query architecture is generally better suited. If the constraint is the data engineering pipeline translating EDI into FHIR-queryable format, Databricks' unified batch and streaming processing is more relevant. Most mature payer architectures end up using both  identify the bottleneck first and invest there.

‍

What should a payer CTO prioritize first in an HTI-5 readiness program?

‍

Start with eligibility and the Coverage FHIR resource. Eligibility is the foundational dataset  it drives claims processing, risk adjustment, quality metrics, and provider attribution. If the payer cannot serve it accurately through a FHIR API with reliable freshness semantics, everything else in the modernization program sits on an unstable foundation. A clean Coverage implementation also validates the API architecture before tackling the more complex ExplanationOfBenefit and Prior Authorization resources.

‍

‍