HTI-1 Compliance Checklist for EHRs and Health IT Teams
HTI-1 has changed the FHIR API conversation for EHR and Health IT developers.
Implementing certified FHIR API functionality is only the starting point. EHRs and Health IT teams must also consider the ongoing operational, compliance, and maintenance responsibilities required to support the FHIR API and additional HTI-1 requirements over time. A complete HTI-1 strategy needs to account for EHI export, application access, permission management, USCDI alignment, SMART app launch, developer support, Real World Testing, Insights reporting, and the ongoing effort required to keep certified functionality up to date.
That is why the Build vs. Buy decision needs to be made at the capability level, not just the feature level.
What EHRs and Health IT teams need to evaluate
HTI-1 certification is not just a question of technical capability. Most EHR and health IT teams can build what is required. The harder question is where to focus limited time, budget, and engineering capacity.
To make the right call, teams need to evaluate the true lift of certification, production readiness, ongoing maintenance, and competitive impact. The checklist below outlines the key areas every EHR team should review before committing resources.
FHIR Infrastructure and Operations
Determine how FHIR servers will be provisioned for your customers, scaled, and published for the required service base URL directory. Consider who will be responsible for uptime, security updates, and ongoing operations.Provider Directory Management
Determine how provider directory information, endpoints, and ongoing directory updates will be maintained to support interoperability requirements.API Permission Management
Define how permissions would be managed for authorization, revocation, and changes. Ensure your EHR can capture and report FHIR API request activity needed to support ONC HTI-1 Insights reporting for (g)(10)-certified functionality.Upload Patient Data in USCDI v3.1 Format
Confirm that your C-CDA and clinical data can be mapped, validated, and made available in the required USCDI v3.1 format, and that your CHPL listing is up to date. Outline the process and frequency of patient data.Patient and Authorized Representative Access
Plan how patient accounts will be created, invitations sent, password resets handled, and access instructions provided.Developer Portal and App Registration
Define how third-party developers will register apps (including SMART on FHIR apps), access documentation, navigate approval workflows, and receive ongoing support. The ability to differentiate between “Read Only” and “Read/Write Requests” would be crucial.
Note: The Developer Portal is an ONC requirementDecision Support Intervention (DSI) (b)(11) Transparency
Account for DSI transparency requirements, including how intervention logic, source attributes, CDS Hooks integrations, and related disclosures will be managed.MIPS Provider to Patient Exchange Support
Ensure your EHR logic supports the MIPS Promoting Interoperability measure, Provider to Patient Access, to include the ability for patients to access their information through third-party apps of their choice.Support Full-Scope EHI Access, Export, and Information Blocking Readiness
Check whether your system can support broader EHI access and bulk export requirements (b)(10) and align with ongoing Information Blocking obligations.Real World Testing and Insights Reporting
Identify who will create the annual Real World Testing plan, conduct testing with users, prepare reports, monitor usage, and submit required reports to your ONC-ATB - required for (g)(7), (g)(9), and (g)(10).Total Cost of Ownership
Look beyond development estimates. Include QA, testing, ONC-ATB certification, hosting, licensing, developer support, provider directory maintenance, ongoing standards updates, and compliance activities when evaluating the true cost of ownership.
Build vs. Buy Decision
The checklist above identifies what EHR and health IT teams need to evaluate. The table below turns these evaluation areas into a quick build-versus-buy reference, showing where internal development creates added operational lift and where Darena Health can reduce time, cost, and certification risk.
| Capability Area | Build Internally | Integrate with Darena Health |
|---|---|---|
| 1. FHIR Infrastructure and Operations | Build and operate FHIR infrastructure across customers, environments, security, uptime, and scaling. | Use hosted, multi-tenant FHIR infrastructure designed for certified production use. |
| 2. Provider Directory Management | Maintain provider data, endpoint records, updates, and discovery workflows. | Use provider directory and endpoint discovery capabilities with Lantern compatibility support. |
| 3. API Permission Management | Build authorization, revocation, app permissions, and API activity tracking. | Use managed SMART on FHIR access workflows with permission and reporting support. |
| 4. Upload Patient Data in USCDI v3.1 Format | Map, validate, and maintain clinical data in the required USCDI v3.1 format. | Use implementation support for USCDI v3.1 readiness, validation, and the publication of certified APIs. |
| 5. Patient and Authorized Representative Access | Build account, invitation, representative access, reset, and support workflows. | Support patient and representative access through certified API and SMART on FHIR workflows. |
| 6. Developer Portal and App Registration | Build developer onboarding, app registration, sandbox, documentation, and access controls. | Use a self-service Developer Portal with sandbox, documentation, and app registration workflows. |
| 7. DSI (b)(11) Transparency | Build, certify, and maintain DSI logic, disclosures, CDS Hooks, and transparency requirements. | Use a certified (b)(11) DSI platform with CDS Hooks, CQL, transparency, and AI model support. |
| 8. MIPS Provider to Patient Exchange Support | Maintain MIPS logic and patient access workflows for third-party app use. | Use Darena Health and MyMipsScore support for certified interoperability and quality reporting. |
| 9. Full-Scope EHI Access, Export, and Information Blocking Readiness | Build certified EHI export and maintain broader EHI access and Information Blocking readiness. | Use certified (b)(10) EHI Export capability with attestation-ready support. |
| 10. Real World Testing and Insights Reporting | Plan, test, collect evidence, monitor usage, and prepare annual reporting. | Use certified module maintenance support for Real World Testing and Insights reporting readiness. |
| 11. Total Cost of Ownership | Account for engineering, QA, certification, ONC-ATB coordination, hosting, licensing, security, developer support, provider directory maintenance, standards updates, and ongoing compliance. | Significantly reduced operational burden, quick readiness for market, lower certification and maintenance risk, and elimination of building core HTI-1 infrastructure. |
The Strategic Question: What Should Your Team Own?
The Build vs. Buy decision is not just about whether your team can develop the required functionality. It is about deciding which responsibilities your organization should own in the long term.
Although FHIR API is a large part of HTI-1 compliance, it goes much further. EHR and health IT teams must account for certified infrastructure, SMART on FHIR workflows, provider directory management, developer enablement, Real World Testing, Insights reporting, support processes, and ongoing compliance as standards and requirements evolve.
⚡The practical question is whether your team should invest engineering and compliance resources in building and maintaining these capabilities internally or focus those resources on your core product, customer experience, and market differentiation.
A strong HTI-1 strategy should be evaluated by more than development effort. It should account for total cost of ownership, certification risk, time to market, production readiness, long-term maintenance, and the operational burden required to stay compliant.
Make HTI-1 Compliance Easier to Execute
For EHRs and health IT vendors evaluating a buy-or-partner strategy, Darena Health offers certified interoperability capabilities that can reduce internal lift and accelerate readiness. These include (g)(10) FHIR APIs, (b)(10) EHI Export, (b)(11) Clinical Decision Support, SMART on FHIR, CDS Hooks, provider directory services, developer enablement tools, and ongoing certification maintenance.
The right path depends on your organization’s product priorities, available resources, timeline, and long-term interoperability strategy. The important step is to evaluate that path before engineering and compliance teams are locked into a costly internal build.
Find the Right HTI-1 Path for Your Organization
Let's discuss the trade-offs between building internally and leveraging a certified interoperability platform to reduce cost, risk, and time to market.
RECENT BLOGS
