By Danielle Friend (Epic), Chair, Standards & Interoperability Workgroup, and John Stamm (Epic), Vice Chair, Public Health Workgroup

Previous installments of this 3-part blog series on the EHR Association’s top concerns with HTI-2 focused on the overarching issues and specific issues with the complex web of proposed changes to Insights Measures. Our full comments to ASTP are available on our website.

Along with unrealistic compliance timeframes and out-of-sync cross-agency requirements, ASTP’s Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) proposed rule creates substantial compliance burdens for providers, the EHR developers that support them, and public health agencies (PHAs) due to the laundry list of premature and/or unnecessary and lopsided requirements.

Three areas where these issues are quite prominent are HTI-2’s proposed requirements pertaining to standards, electronic prior authorization (ePA), and public health reporting.

Unsupported Standards Expansion

While understandable, ASTP’s enthusiasm for interoperability and data-sharing progress has led them to propose standards requirements that are premature and unreasonable. In some cases, proposed requirements related to standards with still-low industry adoption have been published but have offered no incentives to boost rates.

While understandable, ASTP’s enthusiasm for interoperability and data-sharing progress has led them to propose standards requirements that are premature and unreasonable.

For example, ASTP proposes expanding clinical reconciliation criteria from supporting just three (problems, medications, and the allergy list) to supporting all ~114 USCDI v4 data elements—several of which are irrelevant for health IT vendors and providers with a more specialized focus (e.g., pediatric data for geriatric-focused EHRs or encounter data for specialty EHRs focused on procedures). Another example would require the support of Da Vinci implementation guides that only recently started to see initial production. 

Not only are these expectations unrealistic, but compliance within the proposed timeframe is infeasible—an issue we’ve hit on numerous times, including in this blog series. As such, we urge ASTP to take an alternate approach that is more focused and clinically impactful by defining a more limited scope of data that aligns with the highest impact clinical priorities and needs. 

Specifically, we propose a more modest expansion focused only on Problems, Allergies & Intolerances, Medications, Immunizations, Procedures, Laboratory, and Clinical Notes. This approach still aligns with critical areas of patient care but also balances the need for meaningful data reconciliation with the practical realities of implementation within the proposed time frame.

Requiring developers to support a significantly expanded scope for some public health reporting criteria is one of the most significant issues we have with HTI-2.

Requiring developers to support a significantly expanded scope for some public health reporting criteria is one of the most significant issues we have with HTI-2. The Cancer Pathology Reporting and Prescription Drug Monitoring measures recommend standards not currently in use in the industry, despite live exchange occurring today using established standards. Additions like Birth Reporting require new provider-intensive workflows, data collection, and interoperability options for exchanges that are not yet in production in any jurisdiction according to the 2024 ISA.  

The end result of these overly aggressive inclusions is a great deal of interoperability development for EHR developers and a heavy implementation burden for providers—despite the reality that most or all PHAs are currently unable to receive the data.

Finally, the vast array of new FHIR-based standards proposed for adoption—Dynamic Registration, CDS Hooks, FHIR Subscriptions, Smart Health Cards—presents an overwhelming scope of new requirements with some standards that are either too broad (FHIR Subscriptions) or immature (Smart Health Cards) for inclusion. These proposals should not be finalized without refinement, scoping, and clear ROI.

Unfunded PHA Mandates

HTI-2 would require EHR development and provider implementation in areas that aren’t supported by today’s PHA funding. FHIR Subscriptions and Bulk Data may yet meet use cases within public health, but mandating them before public health-specific guidance, prototyping, and piloting risks adding burdensome development and workflows for functionality that may not meet the needs of PHAs.

One example is the Standardized API for Public Health Data Exchange, which aspires to provide public health with dynamic, current, and actionable data. Unfortunately, while laudable, the guides referenced in HTI-2 do not appear to meet the public health need, pointing to standards that, while available, are not well-tailored to this use case. Additionally, investing in these APIs is premature at a time when most public health jurisdictions are still struggling to invest resources into case management systems that allow them to take advantage of current interoperability, such as electronic case reporting (eCR).

Indeed, funding the proposed public health requirements in HTI-2 in general is a serious concern. Many of HTI-2’s proposals require new and emerging EHR standards without any corresponding support for the burdens incurred by jurisdictional public health. 

Indeed, funding the proposed public health requirements in HTI-2 in general is a serious concern. Many of HTI-2’s proposals require new and emerging EHR standards without any corresponding support for the burdens incurred by jurisdictional public health. Added requirements like Birth and Fetal Death Reporting and Cancer Pathology Reporting cannot be successful unless PHAs can implement and support them—which they cannot do without sustained public health funding.

For example, eCR has been included in the regulation for several years. However, because no jurisdiction can fully integrate eCR into their case management systems, this results in overhead for providers to build and support the interoperability in addition to their preexisting requirements to manage paper, fax, and portal submissions.

Finally, we strongly support the thinking behind ASTP’s proposal to expand the required use of a certified health ID to include PHAs, as it could significantly enhance data exchange. However, with no corresponding incentive or enforcement mechanism, it is unlikely to drive adoption and use at levels necessary to move the needle on meaningful data exchange with these agencies. That, in turn, means an extensive investment of resources by health IT vendors to include the functionality in our EHRs even where the corresponding work is unlikely to be done within the systems used by the PHAs.

Lopsided Enforcement

This type of lopsided mandate is also present in HTI-2’s requirements around electronic prior authorization (ePA), where adoption of ePA transactions as part of certification is required for EHR developers in HTI-2 but only recommended by CMS for payers, providers, and pharmacies. As such, health IT companies must invest significant development resources to make available certified technologies that other stakeholders are not required or even incentivized to adopt. 

This uneven approach to certified health IT creates inconsistency across HHS agencies and limits real-world use. It also adds unnecessary hardships for health IT developers with a very minimal likelihood of adoption on the payer and provider sides of the data exchange process. It is therefore a waste of developer resources and adds unnecessary costs. 

Until both sides of the exchange process are using similar technology based on the same standards, the requirements proposed in HTI-2 are unreasonable.

Until both sides of the exchange process are using similar technology based on the same standards, the requirements proposed in HTI-2 are unreasonable. Thus, we urge ASTP to delay or adopt a staged approach to ensure a more comprehensive and functional ePA system that aligns with the broader goals of streamlining care coordination and reducing administrative burdens across the healthcare ecosystem.  

The first step should be strongly recommending that both payer and provider health IT use the same implementation guides. Further, shared certification requirements should align with community needs, as those built by implementers in Da Vinci. This consensus approach enables interoperability to mature and align with the needs of all parties.

A Level Playing Field

In general, forcing one group to adopt a standard on a certain timeline without requiring the same of other stakeholders in the exchange “circle” is hugely problematic. Uneven and uncoordinated application of standards and certification requirements will ultimately prevent HTI-2 from achieving its important goals of advancing interoperability and safe, meaningful, and effective information sharing among patients, providers, payers, and PHAs.

Read the first installment of this blog series, Huge Scope, Not Enough Time: Concerns with ASTP’s HTI-2 Proposed Rule, here. and the second installment, ASTP’s HTI-2 Proposes Concerning Changes to Insights Measures, here. Our full comment letter to ASTP on HTI-2 is available here. 

Leigh Burchell (Altera Digital Health), Vice Chair of the EHR Association Executive Committee, Hans Buitendijk (Oracle Health), Chair of the Public Health Workgroup, and Megan Saffen (Greenway Health), Vice Chair of the Standards & Interoperability Workgroup contributed to this blog.