HTI-6 & Information Blocking: What API Developers Must Change
Healthcare technology is moving toward a future where patient information can be accessed, exchanged, and used securely across different healthcare systems. But despite years of progress in interoperability, many patients and healthcare providers still face challenges when trying to share electronic health information (EHI).
Disconnected EHR systems, restrictive API access, delayed data exchange, and complicated integration requirements continue to create barriers to better healthcare experiences.
The Office of the National Coordinator for Health Information Technology (ONC), now operating within the broader HHS health IT policy structure, has been working to address these challenges through its Health Data, Technology, and Interoperability (HTI) rulemaking initiatives.
One upcoming development that healthcare technology companies should watch closely is HTI-6 and its potential impact on information blocking regulations and API development.
For healthcare API developers, the message is becoming increasingly clear: building an API that technically works is no longer enough. Developers must also consider how easily authorized users, patients, healthcare providers, and emerging AI technologies can access and exchange electronic health information.
At Auspicious Soft, we recognize that healthcare interoperability requires more than connecting two systems. It requires thoughtful architecture, reliable data exchange, security controls, and an understanding of evolving healthcare regulations. In this guide, we explain what HTI-6 means, how information blocking affects API developers, and what healthcare technology teams should prepare for.
What Is HTI-6?
HTI-6 stands for Health Data, Technology, and Interoperability: Application Programming Interfaces and Information Blocking. The initiative is intended to advance interoperability through potential updates to health IT standards, expanded API certification requirements, additional certification conditions, and changes to information blocking regulations.
According to the 2026 Unified Agenda, HHS plans to address API standards, support expanded uses of APIs and successor technologies, and update information blocking regulations. The initiative is listed as a proposed rulemaking, not a finalized regulation.
This distinction matters.
HTI-6 should be treated as a regulatory development to prepare for, not a final set of compliance requirements that developers must already follow. The direction of healthcare interoperability, however, is clear: systems need to support broader, more reliable access to electronic health information.
For developers, this means reviewing existing API architectures and identifying limitations before new requirements are finalized.
Why HTI-6 Matters for Healthcare API Developers
Healthcare APIs connect systems such as:
Electronic Health Records (EHRs)
Electronic Medical Records (EMRs)
Hospital Information Systems (HIS)
Patient-facing mobile applications
Healthcare payer platforms
Clinical decision support systems
Health Information Exchanges (HIEs)
Remote Patient Monitoring (RPM) platforms
AI-powered healthcare applications
When these systems cannot exchange information effectively, patients may need to repeat their medical history, clinicians may lack important clinical context, and healthcare organizations may spend additional time managing fragmented records.
HTI-6 is important because API accessibility and information sharing are central to the future of healthcare technology.
For companies investing in Healthcare Software Development, preparing for interoperability changes can help reduce future technical debt and improve the usability of their digital health products.
What Is Information Blocking in Healthcare?
Information blocking refers to a practice that is likely to interfere with the access, exchange, or use of electronic health information, unless the practice is required by law or covered by an applicable regulatory exception. The information blocking regulations are established under 45 CFR Part 171 and implement provisions of the 21st Century Cures Act.
The rules apply to three categories of actors:
Healthcare providers
Developers of certified health IT
Health Information Networks (HINs) and Health Information Exchanges (HIEs)
For health IT developers and HINs/HIEs, the applicable knowledge standard is whether the entity knows, or should know, that its practice is likely to interfere with access, exchange, or use of EHI. Healthcare providers are subject to a different knowledge standard under the regulation.
The important point for API developers is that information blocking is not limited to intentionally refusing to share medical records. Technical decisions, contractual restrictions, unnecessary delays, and restrictive access policies may also create concerns.
Common Examples of Potential Information Blocking
Consider the following scenarios.
1. Delaying access to patient information
A patient authorizes a third-party application to retrieve their medical records through an API. The healthcare organization delays access without an appropriate justification.
This could raise information blocking concerns.
2. Restricting third-party applications
An EHR vendor prevents patients from using an otherwise authorized application because the application is not part of the vendor's preferred ecosystem.
Such restrictions may interfere with patient-directed access.
3. Creating unnecessary API limitations
A developer introduces technical restrictions that materially discourage authorized access to EHI without a legitimate reason.
4. Blocking automation technologies
A healthcare platform prevents authorized automation tools from accessing or exchanging EHI simply because the request is made through an automated process.
This last example is becoming particularly important as healthcare organizations adopt AI agents. ONC has specifically addressed the possibility that interference with automation technologies, including agentic AI, could implicate information blocking regulations.
HTI-6 and Information Blocking: What Is Changing?
Healthcare API developers should understand the difference between existing requirements and potential future changes.
Area | Current Regulatory Position | What Developers Should Prepare For |
Information blocking | Existing requirements under 45 CFR Part 171 | Review access restrictions and data-sharing workflows |
FHIR APIs | Existing certified API requirements apply where relevant | Improve interoperability and consistent API behavior |
Third-party applications | Patient-directed access must be considered | Review app registration and authorization processes |
AI-powered automation | Existing information blocking rules can apply to automation | Design controlled access for authorized AI agents |
API certification | Requirements depend on applicable certification criteria | Monitor future HTI-6 standards and certification updates |
Information blocking exceptions | Existing exceptions remain relevant | Document legitimate reasons for limiting access |
The goal is not to assume every proposed change will become law. Instead, API developers should use this period to strengthen the foundations of their healthcare platforms.
7 API Development Changes Healthcare Technology Companies Should Prepare For
HTI-6 may introduce new requirements as the rulemaking progresses. However, several API improvements are already valuable under the existing interoperability framework.
1. Build APIs Around Standardized Healthcare Data
Healthcare information is often stored in different formats across EHRs, hospitals, laboratories, and healthcare applications. One system may use a particular terminology or data structure, while another system expects a different format.
This creates integration challenges. Developers should prioritize standardized healthcare data models rather than building isolated, proprietary interfaces.
FHIR (Fast Healthcare Interoperability Resources) is an important foundation for modern healthcare interoperability.
FHIR supports the exchange of healthcare information through structured resources such as:
Patient
Practitioner
Encounter
Observation
Condition
MedicationRequest
DiagnosticReport
AllergyIntolerance
For example, a patient-facing application may need to retrieve laboratory results from an EHR.
Using standardized FHIR resources can make it easier to interpret the data consistently across systems. However, using FHIR alone does not automatically make an API compliant.
Developers must also consider applicable implementation guides, authorization requirements, data completeness, and regulatory obligations. For Healthcare Software Development teams, standardized data architecture can reduce integration complexity and support future interoperability improvements.
2. Review API Access Restrictions
One of the most important areas for developers to examine is how their APIs handle requests for electronic health information. A platform may have legitimate reasons to restrict access in certain circumstances. However, developers should avoid introducing unnecessary barriers.
Review the following:
Does the API delay authorized patient access?
Are third-party applications restricted without a clear justification?
Are API registration requirements unnecessarily complicated?
Are rate limits proportionate to legitimate use?
Are access restrictions documented?
Can the system explain why a request was denied?
A restriction should not automatically be considered acceptable simply because it was implemented as a technical control. The information blocking analysis depends on the facts and circumstances, applicable requirements, and whether an exception applies.
ONC has also clarified that certain app-vetting practices may raise information blocking concerns, particularly when they restrict patient-directed access through certified API technology.
3. Improve OAuth 2.0 and SMART on FHIR Authorization
API accessibility must be balanced with appropriate security.
Healthcare applications frequently rely on OAuth 2.0 and SMART on FHIR to establish secure authorization workflows. These technologies help applications request access to specific healthcare information based on the permissions granted by the patient or authorized user.
Developers should review their authorization architecture to ensure it supports:
Secure authentication
Appropriate access scopes
Patient-authorized data access
Token expiration and renewal
Revocation of access
Audit logging
Protection against unauthorized requests
For example, a patient may authorize a mobile application to retrieve medication information.
The application should receive only the access permitted by the authorization workflow, rather than unrestricted access to the healthcare organization's entire database.
At the same time, developers should avoid using security reviews as a blanket reason to prevent legitimate patient access. A well-designed authorization system supports both security and interoperability.
4. Make API Error Handling More Transparent
API developers sometimes create error responses that make it difficult for third-party applications to understand what happened.
For example:
An API returns a generic error when access is denied.
A request is rejected without explaining the reason.
A temporary service issue is treated as a permanent restriction.
An application cannot distinguish an authorization problem from a technical failure.
These issues can make integrations unreliable and increase support requirements.
Developers should create consistent API error handling that clearly communicates the nature of a failure without exposing sensitive information.
A practical approach includes:
HTTP Status | Typical API Use |
400 | Invalid request |
401 | Authentication required or invalid |
403 | Access denied |
404 | Resource not available or not found |
429 | Rate limit exceeded |
500 | Internal server error |
503 | Service temporarily unavailable |
The actual response should follow the relevant API specification and security requirements. Clear error handling also makes it easier to demonstrate that a technical limitation is genuine rather than an unnecessary barrier to information sharing.
5. Design for Reliable Data Exchange
Healthcare APIs must do more than return a successful response. They must deliver information that is accurate, complete, timely, and usable. A poorly designed API may technically provide access while still creating significant interoperability problems.
For example, an application may retrieve a patient's encounter record but fail to receive associated laboratory results or medication information. This can limit the usefulness of the information.
API developers should consider:
Pagination and large data requests
Consistent resource identifiers
Data synchronization
Updated and historical records
Retry mechanisms
Appropriate caching
Monitoring and availability
Data provenance
Validation of exchanged information
Developers should also review how their systems handle partial data availability.
If a particular resource cannot be returned, the application should have a clear and appropriate response rather than silently omitting information.
Reliable data exchange is an important part of building healthcare platforms that support patients and providers across different systems.
6. Document API Access Decisions and Compliance Workflows
Healthcare API development should include documentation of how access decisions are made. This becomes especially important when an organization limits or delays the exchange of EHI. Developers and healthcare organizations should maintain documentation covering:
API access policies
Authorization requirements
Security controls
Data-sharing restrictions
Technical limitations
Incident management procedures
API availability and performance
Reasons for denied requests
Applicable information blocking exceptions
For example, if an organization determines that a particular disclosure could create a security risk, the team should document the risk assessment and the basis for its decision.
The Information Blocking Security Exception may apply when its specific requirements are satisfied. However, a general security concern is not automatically sufficient to qualify for an exception. A documented and consistently applied process helps healthcare organizations make more defensible decisions.
7. Prepare APIs for AI Agents and Automated Healthcare Workflows
AI is changing how healthcare applications interact with information systems.
Traditional software applications typically make API requests through predefined workflows. AI agents can perform more complex tasks by interpreting information, selecting actions, and coordinating multiple systems.
For example, an AI-powered healthcare workflow might:
Retrieve a patient's authorized clinical history.
Review relevant medication and encounter information.
Identify missing documentation.
Prepare a summary for a clinician.
Request additional information from an authorized system.
Present the result for human review.
These workflows depend on reliable and appropriately authorized access to healthcare information. Developers should consider how their APIs will support automated requests while maintaining security, privacy, and accountability.
This is where AI Agent Development becomes increasingly relevant to healthcare interoperability. However, an AI agent should not be treated as automatically authorized to access patient records.
Developers must establish appropriate identity, permissions, access scopes, audit trails, and safeguards for automated actions. The ability to support AI agents should be built into the architecture rather than added as an uncontrolled integration later.
How AI Agent Development Could Influence Healthcare API Design
The relationship between AI agents and information blocking deserves particular attention. Healthcare organizations are increasingly exploring AI systems that can help manage administrative workflows, support clinical operations, and improve access to information. Some of these systems may need to interact with EHRs, patient portals, laboratory systems, and other healthcare platforms.
For example, an AI agent used in a healthcare organization may need to retrieve a patient's recent encounter information to prepare a clinical summary. If the underlying API is inaccessible, poorly documented, or unnecessarily restrictive, the AI workflow may fail. At the same time, developers must ensure that automated access does not create new privacy or security risks.
Key API Capabilities for AI-Powered Healthcare Applications
Capability | Why It Matters |
Standardized data access | Helps AI systems interpret information consistently |
Secure authorization | Ensures the agent accesses only permitted data |
API documentation | Helps developers integrate systems correctly |
Audit trails | Records access and actions performed |
Rate limiting | Helps protect systems from excessive requests |
Data validation | Reduces errors caused by inconsistent information |
Human oversight | Supports appropriate review of sensitive decisions |
Reliable error handling | Helps agents respond safely to failed requests |
Healthcare organizations should also consider whether an AI agent is acting on behalf of a patient, a healthcare provider, or another authorized entity. The authorization model should reflect the actual purpose of the request. The objective is not to give AI agents unrestricted access to healthcare records. It is to enable authorized, secure, and accountable information exchange. This distinction will remain important as AI capabilities expand.
Understanding the Information Blocking Exceptions
The information blocking regulations include exceptions for certain reasonable and necessary practices. These exceptions are important because healthcare organizations sometimes need to limit access to protect patients, maintain system security, or address practical limitations. However, the requirements of each exception must be satisfied.
Important Information Blocking Exceptions
Exception | Purpose |
Preventing Harm Exception | Allows certain practices intended to prevent harm |
Privacy Exception | Addresses practices necessary to protect individual privacy |
Security Exception | Addresses practices necessary to protect EHI security |
Infeasibility Exception | Applies when fulfilling a request is infeasible under specified conditions |
Health IT Performance Exception | Addresses practices needed to maintain or improve system performance |
Manner Exception | Addresses the manner in which a request for EHI is fulfilled |
Fees Exception | Addresses certain fees associated with access, exchange, or use of EHI |
Licensing Exception | Addresses certain licensing practices |
The exact conditions vary by exception. For instance, the Security Exception is not a general permission to deny access whenever an organization identifies a possible security issue. Similarly, the Infeasibility Exception has specific requirements concerning why a request cannot be fulfilled.
Healthcare API developers should work with compliance and legal teams to understand which exceptions may apply to their products and workflows.
The full requirements are available under 45 CFR Part 171.
HTI-6 vs. HTI-1, HTI-2, HTI-3, HTI-4, and HTI-5
HTI-6 is part of a broader series of healthcare interoperability rulemaking initiatives.
Understanding the earlier rules helps API developers place HTI-6 in context.
Rule | Main Focus |
HTI-1 | Certification program updates, algorithm transparency, and information sharing. |
HTI-2 | Trusted Exchange Framework and Common Agreement (TEFCA), interoperability, and certification updates. |
HTI-3 | Protecting Care Access and information blocking regulatory enhancements. |
HTI-4 | Electronic prescribing, real-time prescription benefits, and electronic prior authorization. |
HTI-5 | ONC deregulatory actions and health IT certification changes. |
HTI-6 | Proposed focus on APIs, interoperability standards, and information blocking updates. |
A Practical HTI-6 Readiness Checklist for API Developers
Healthcare technology companies can begin reviewing their existing systems without waiting for HTI-6 to become final. The following checklist can help development teams identify areas that may need attention.
API Architecture
Review existing API architecture and interoperability capabilities.
Identify proprietary data formats that create integration challenges.
Evaluate the use of FHIR resources and applicable implementation guides.
Review API documentation for completeness.
Identify limitations affecting authorized data access.
Security and Authorization
Review OAuth 2.0 and SMART on FHIR authorization workflows where applicable.
Validate access scopes and permissions.
Implement appropriate token expiration and revocation.
Review API access controls and third-party application registration.
Maintain appropriate audit logs.
Information Blocking Review
Review policies that delay or restrict access to EHI.
Document legitimate technical and security limitations.
Evaluate whether relevant information blocking exceptions apply.
Review contractual restrictions affecting data exchange.
Establish a process for investigating access complaints.
AI and Automation Readiness
Identify APIs that may be used by authorized AI agents.
Establish identity and authorization controls for automated access.
Define which actions require human approval.
Validate AI-generated requests and outputs.
Maintain audit trails for automated workflows.
Monitoring and Compliance
Monitor API availability and performance.
Track failed and denied requests.
Review data quality and synchronization.
Keep regulatory documentation updated.
Monitor future HTI-6 rulemaking developments.
This checklist is a starting point, not a certification of compliance.
Healthcare organizations should evaluate their actual products, business relationships, and regulatory responsibilities.
How Healthcare Organizations Can Reduce API Integration Challenges
Healthcare API development often involves more than writing endpoints and connecting databases. Different systems may have different data structures, authentication methods, workflows, and operational requirements. A successful integration strategy should begin with a clear understanding of the healthcare organization's needs.
Step 1: Identify the Systems That Need to Connect
Determine which platforms need to exchange information.
For example, an organization may need to connect an EHR with a patient portal, laboratory system, billing platform, or remote monitoring application.
Step 2: Define the Data Exchange Requirements
Identify which resources need to be exchanged, who can access them, and how frequently the data must be updated.
Step 3: Select the Appropriate API Standards
Use relevant interoperability standards and implementation guides based on the product's requirements and applicable regulations.
Step 4: Design Security and Authorization
Establish appropriate authentication, authorization, access scopes, and audit requirements.
Step 5: Test Interoperability
Test the integration using realistic healthcare workflows. Testing should cover successful requests, denied requests, incomplete data, service interruptions, and authorization failures.
Step 6: Monitor and Improve
Healthcare APIs require ongoing maintenance. Monitoring, documentation updates, security reviews, and regulatory assessments should be part of the development lifecycle. A structured approach can help reduce integration costs while improving the reliability of healthcare applications.
How Auspicious Soft Supports Healthcare API Development
Healthcare organizations need technology partners who understand the challenges of interoperability, data security, and evolving healthcare regulations.
Auspicious Soft Pvt. Ltd. provides Healthcare Software Development services for organizations building digital healthcare products and connected healthcare platforms.
Our development approach focuses on creating scalable systems that support reliable data exchange, secure integrations, and practical healthcare workflows.
Healthcare Technology Solutions We Develop
Healthcare API Development
We help develop and integrate APIs that connect healthcare applications, EHR systems, patient portals, and other digital health platforms.
FHIR-Based Healthcare Integrations
We support healthcare integration projects involving standardized data exchange and interoperability-focused architecture.
Custom Healthcare Software
We develop healthcare platforms based on the operational requirements of providers, healthcare businesses, and digital health companies.
AI-Powered Healthcare Applications
Our AI Agent Development capabilities can support healthcare automation workflows, intelligent data processing, and AI-powered application integrations.
Healthcare Application Modernization
We help organizations modernize existing healthcare systems while improving architecture, integration capabilities, and long-term maintainability. Our focus is on building healthcare technology that can evolve with changing business needs and interoperability expectations.
For organizations preparing for HTI-6, the right development strategy starts with understanding the current regulatory requirements and building an architecture that can adapt as new rules emerge.
Final Thoughts
HTI-6 represents an important development in the future of healthcare interoperability.
Although the initiative is still in the rulemaking process, healthcare API developers should already be thinking about how their systems support secure, reliable, and authorized access to electronic health information.
The most important priorities are straightforward: build standardized APIs, reduce unnecessary access barriers, strengthen authorization, document legitimate restrictions, and prepare for healthcare workflows that increasingly involve AI-powered automation.
Information blocking compliance should not be treated as a last-minute technical adjustment. It should be considered throughout the software development lifecycle.
For healthcare organizations building or modernizing digital health platforms, investing in interoperability today can help reduce future integration challenges and improve the ability to adapt to regulatory changes.
Auspicious Soft helps healthcare organizations build scalable healthcare software, API integrations, and AI-powered digital solutions designed around real-world business and interoperability needs.
Frequently Asked Questions
1. What is HTI-6 in healthcare?
HTI-6 is a proposed Health Data, Technology, and Interoperability rulemaking initiative focused on APIs, interoperability standards, health IT certification, and information blocking updates. It is intended to support broader access, exchange, and use of electronic health information.
2. Is HTI-6 a final regulation?
No. As of November 3, 2026, HTI-6 is listed as a proposed rulemaking initiative in the 2026 Unified Agenda. Developers should monitor official HHS and ONC announcements for the publication of a proposed rule and any subsequent final requirements.
3. What is information blocking in healthcare APIs?
Information blocking refers to practices that are likely to interfere with the access, exchange, or use of electronic health information, except where required by law or covered by an applicable exception. For API developers, this may include unnecessary restrictions, delays, or technical barriers affecting authorized access.
4. Does information blocking apply to healthcare software developers?
Yes. The information blocking regulations apply to developers of certified health IT, healthcare providers, and health information networks and exchanges. Developers should understand how their products and practices may affect the access, exchange, and use of EHI.
5. Can API developers restrict access for security reasons?
Certain security-related restrictions may be permitted under the Information Blocking Security Exception. However, the exception has specific requirements. A general security concern does not automatically justify restricting access. Developers should assess the relevant facts and document their security decisions.
6. How does FHIR support information sharing?
FHIR provides standardized healthcare data resources and exchange mechanisms that can support interoperability between healthcare systems. FHIR-based APIs can help applications exchange information more consistently, but the use of FHIR alone does not establish regulatory compliance.
7. How could HTI-6 affect AI-powered healthcare applications?
HTI-6 may introduce additional requirements related to APIs, interoperability, and health IT certification. Separately, existing information blocking rules can already apply to practices that interfere with authorized access to EHI by automation technologies, including agentic AI. Healthcare developers should therefore evaluate AI access workflows, authorization, security, and auditability.
8. What should healthcare API developers do before HTI-6 becomes final?
Developers should review their API architecture, access policies, authorization workflows, data exchange capabilities, and information blocking procedures.
They should also monitor official regulatory developments and avoid implementing speculative requirements as though they were already mandatory.
Comments