Announcement: HTD’s Response to ONC HTI-2 Proposed Rule

Dear ONC Rulemaking Team,

This letter is in response to the proposed Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) rule.

HTD Health, as a leading technology services group focused on virtual-first care and healthcare interoperability, strongly supports the principles and goals of the HTI-2 Proposed Rule. We commend the Office of the National Coordinator for Health Information Technology (ONC) for its ambitious and comprehensive approach to advancing interoperability across the healthcare ecosystem.

The HTI-2 rule represents a significant step forward in several key areas, including enhancing existing certified health IT functionalities, adding cutting-edge FHIR capabilities, expanding the certification program to include public health and payer software developers, and formalizing key concepts related to the Trusted Exchange Framework and Common Agreement (TEFCA). These changes have the potential to dramatically improve interoperability, reduce provider burden, and enhance patient care.

However, to ensure the success of this rule and its widespread adoption, we strongly encourage the ONC to address several key areas that we believe are critical for realizing the full potential of these policies. These areas include balancing developer burden and innovation, clarifying standards and implementation guides, addressing potential regulatory overreach concerns, enhancing write capabilities for FHIR APIs, and strengthening enforcement and compliance mechanisms.

Today, provider applications are still reliant on HL7v2 interfaces, flat file reports, and other mechanisms to understand the relevant populations and begin their workflows. This step of enrollment may be predicated on certain orders being placed, patients being scheduled in certain departments, or specific procedures being completed.

Today, FHIR implementations lack any variety of “push” (either a broadcast or a subscription). Furthermore, their query-based nature is restricted by the requirement of specifying patient specific query parameters, such as the patient or subject search parameters.Thus, without cross-patient queries for orders, encounters, or other relevant data, “polling” as a workaround to the lack of a push is not possible to enroll patients and create a relevant panel/subset. The lack of cross-patient queries, as well as the lack of support for the lastUpdated parameter, force applications to mass query certified technology, pulling and discarding duplicative data, or again to rely on legacy technology such as HL7v2.

As a result, we deeply appreciate the inclusion of FHIR Subscriptions in the proposed rule, as this addresses a significant gap in current FHIR implementations and will address one of the main blockers to provider applications building in a FHIR-only world: enrollment of relevant patients to provider and backend applications. This criterion arguably will be the most impactful in the rule in the modernization of healthcare infrastructure.

However, we have identified several areas where further clarification and enhancement could greatly improve the effectiveness of this requirement. We have two tactical and one strategic recommendations.

Firstly, the current proposal to require both R4 and R4B versions of the Subscription backport is potentially confusing and burdensome for developers. We recommend standardizing on R4B to simplify implementation and reduce complexity. This standardization would provide a clear path forward for developers and ensure consistency across different systems.

Secondly, there is a lack of clarity regarding the use of filters in Subscriptions. Specifically, it’s unclear whether filters can be used independently or must always be used in conjunction with patient filtering. We urge the ONC to provide explicit guidance on this matter to ensure that developers can fully leverage the power of FHIR Subscriptions while maintaining appropriate data access controls. We strongly recommend that the rule makes clear that while servers must support the patient/subject filters on Subscriptions, they should not be required filters and that a server must support a resource-level Subscription with no filters. Without this clarification, as worded in the proposed rule, certified technology developers may limit Subscriptions by requiring the patient filter, which would mean that Subscriptions could not fulfill the aforementioned enrollment use case.

Lastly, we strongly recommend clearly stating that Subscription functionality is required to be supported for patient-facing apps as well as provider-facing apps. Patient-facing applications will greatly benefit from real-time notifications of new data, greatly enhancing the patient experience and the timeliness of care coordination, but may be excluded without explicit callout.

At a higher level, to truly enable a FHIR-centric ecosystem for healthcare applications, we believe several additional steps are necessary. The last step of any ancillary application workflow is to write data back into the EHR. We believe that the addition of write APIs for patient, provider, and backend applications is both necessary and straightforward.

We recommend including requirements for “Create” and “Update” style FHIR APIs, which would allow applications to push data into EHRs. This bi-directional flow of information is crucial for many modern healthcare applications and would significantly enhance the utility of FHIR-based systems. Given the hesitation around “Create” APIs funneling to the chart, it is worth noting that the “Revised Clinical Information Reconciliation and Incorporation Criterion” could easily be extended to support FHIR payloads in addition to the mentioned transfer of care documents. This update would align the criteria, allowing for FHIR-only application development and facilitating a more seamless integration of diverse data sources with minimal developer burden. We note that some certified technology, such as Epic, have already incorporated some of their FHIR Create APIs with Clinical Information Reconciliation, such as the AllergyIntolerance Create, suggesting this pattern is amenable to certified technology developers. In aligning the FHIR APIs with the reconciliation flow, this rule would allow for active participation by the patient and ancillary applications in providing data back to the EHR as a stepping stone to full writing to the chart.

While we appreciate the ONC’s proposal to update to USCDI v4, we strongly recommend advancing directly to USCDI v5. Given that USCDI v5 is already available and includes significant additions such as Orders, we believe this would provide greater value to the healthcare ecosystem and reduce the need for frequent updates in the near future. We urge the ONC to update the rule to require USCDI v5 implementation instead of v4, provide clear guidance on the timeline and process for implementing the new data elements (particularly Orders), and consider a phased approach for implementing more complex USCDI v5 elements if necessary.

We are deeply concerned about the proposal § 170.315(b)(3)(ii)(A)(6) to remove medication history queries from the e-prescribing certification criteria. This decision seems potentially harmful to patient safety. Moreover, the decision seems both counterintuitive and conflicting with other criteria:

• Medication history queries are crucial for safe e-prescribing and medication reconciliation.
• The clinical data reconciliation criterion 170.315(b)(2) already requires nearly equivalent functionality.
• The newly proposed prior authorization requirements are more complex and less universally beneficial than medication history queries.

The sole reason for removal appears to be that some developers “are unable to achieve certification for electronic prescribing altogether”. The fact that a criterion is difficult is not a valid reason for removal – certified health criteria should be weighed on the impact they bring in improving healthcare for Americans.

We strongly urge the ONC to retain the medication history query criteria in the e-prescribing certification. If necessary, we suggest separating it into a distinct criterion to address vendor concerns and providing additional support or guidance to vendors struggling with this implementation, rather than removing the requirement entirely.

While we appreciate the “Electronic Health Information (EHI) Export – Single Patient EHI Export Exemption” proposal, we have significant concerns about the current usability of EHI Export features in the market and remain strongly convinced that more basic fixes are needed to that criterion.

Currently, this functionality is often hidden behind arcane processes, and there is little awareness of its availability at health systems. There are little to no working implementations to be found on market today. Without updates to the criteria or the program’s Conditions & Maintenance of Certification to address this, the EHI export will remain dead weight and wasted effort as a significant burden to health technology developers that provides no real world value.

Requiring the EHI Export capability to be accessible through the patient portal of the certified technology would reduce overall burden for patients. Similarly, exposing the EHI Export API detailed in Argonaut’s EHI Export API Implementation Guide after patient authorization alongside the Patient Access APIs of the (g)(10) criteria would give a straightforward workflow for patients to direct data to the applications and organizations of their choosing.

We recommend that the ONC require certified health IT to make EHI Export functionality easily accessible through patient portals and APIs, mandate clear communication to patients about the availability and process for requesting EHI exports, and implement user experience guidelines to ensure consistency and ease of use across different systems. Additionally, we suggest considering a public education campaign to increase awareness of this right among patients.

The inclusion of imaging links in the proposed rule is a positive step, but the current requirements are insufficiently specific and may not achieve the desired outcome of improving access to diagnostic images. The proposal requires certified health technology to make links to diagnostic images available via patient access APIs, provider access APIs, and cross-organizational exchange, but does not specify how this should be accomplished.

We recommend that the ONC at a minimum clarify how EHRs should interact with Picture Archiving and Communication Systems (PACS), and provide guidance on authentication and authorization mechanisms for image access to ensure patient privacy and data security. Furthermore, while we understand the challenges of specifying standards for image sharing, such as DICOMweb or FHIR ImagingStudy resources, this update will be both extremely burdensome to certified technology developers but also an inconsistent, broken experience for patients, providers, and application developers.

We also suggest considering a phased approach to implementation and exploring the potential for including PACS vendors in the certification program to ensure end-to-end interoperability for imaging data. We recommend providing exact guidance on standards for all use cases where an imaging link must be included.

We commend the ONC’s ambitious expansion of public health criteria in the certification program. However, we have concerns about the inconsistency in standards across different public health reporting types and the potential burden on EHR developers to implement multiple standards for a single public health criterion. The sheer variety of standards in use is a cognitive and operational burden for both technology developers and their provider/public health customers, necessitating significant additional hiring to maintain necessary expertise for ongoing support.

Any reporting standards that are included in certification criteria are significant investments for certified health technology developers and should be forward-facing and future-proof. Calcifying legacy standards into our national infrastructure is a mistake – this regulation represents the chance to invest cleanly into a strong, internet-native technology with a robust community and excellent documentation – FHIR.

We recommend standardizing on FHIR across all public health reporting criteria, even where implementation guides are less mature, with a clear transition plan from legacy standards. To offset the burden on a small minority of technology developers who have already invested in legacy technologies, we also suggest providing a longer implementation timeline for public health criteria to allow for proper development and testing and considering a phased approach to implementing new public health reporting requirements.

We strongly support the ONC’s focus on improving Bulk FHIR capabilities. We note that Bulk FHIR has shifted from a generic feature to a critical dependency for many other features in the proposed rule, and current Bulk FHIR implementations by many EHRs are inadequate for these expanded use cases. In particular, certified technology has non-standard Group creation/registration processes which poses a significant challenge for developers as they scale across EHRs, directly analogous to how non-standard application registration does not enable efficient registration across multiple certified Health IT Module deployments.

We recommend providing more specific guidance on expected Bulk FHIR performance and capabilities. We also recommend requiring the capability for programmatic (API-driven) creation of the Group resource necessary for bulk export.

While we support efforts to streamline prior authorization processes, we have significant concerns about the complexity of the proposed implementation. The requirement to support multiple FHIR Implementation Guides and advanced features like CDS Hooks and Clinical Quality Language (CQL) creates a highly complex system, increasing the likelihood of frequent errors and system failures.

We recommend simplifying the initial requirements for prior authorization APIs, with a phased approach to adding more complex features. We also suggest providing extensive testing resources and support for developers implementing these APIs, and considering a “sandbox” period where these APIs can be tested in real-world scenarios before full implementation is required.

We strongly support the ONC’s proposed enhancements to information blocking regulations, particularly:

• The expansion of the “provider” definition to include pharmacists and labs
• The significant change regarding medical image exchange
• The consideration of anti-compete clauses as potential information blocking.

We recommend providing clear guidance on how these new information blocking provisions will be enforced, particularly regarding medical image exchange, offering resources to help organizations transition from physical to digital image exchange methods, and clarifying the scope and limitations of the anti-compete clause provision, including how it interacts with existing employment law.

HTD Health applauds the ONC’s efforts to advance interoperability and reduce provider burden through the HTI-2 rule. We believe that with the suggested refinements, this rule has the potential to significantly improve healthcare data exchange and ultimately enhance patient care.

We particularly appreciate the ONC’s efforts to expand the certification program to include public health and payer software, as this addresses critical gaps in our current healthcare IT ecosystem. However, we urge the ONC to carefully consider the potential impacts on smaller developers and new market entrants, and to provide clear guidance and support to ensure successful implementation across the industry.

We look forward to continuing to work with the ONC and other stakeholders to realize the full potential of these interoperability advancements. Thank you for your consideration of these comments.