With HTI-2, the feds go all-in on interoperability
Over the summer, ASTP (formerly ONC) released HTI-2, a massive proposed rule with widespread implications for stakeholders across the healthcare ecosystem. This regulation is focused on two important things. First, it broadens the interoperable capabilities of health IT to support a greater variety of workflows, and second, it increases the reliability and trustworthiness of the data exchanged. In some cases, new requirements will unlock brand new workflows and open the door to previously unavailable outcomes. More often, changes will increase the utility of data by improving its reliability or timeliness.
The word you will see often both in the rule and in this post is "standardize." Standardization is desperately needed across healthcare, and in HTI-2 ASTP has proposed to expand and update the code systems, protocols, and implementation guides that certified health IT systems would be required to adhere to. There are plenty of summaries out there to peruse, so this post will instead dive more deeply into a couple of the rule's key provisions and explain why we at Ashavan are so excited about their implications.
A combo draw for public health
HTI-2 packs many new public health data exchange requirements that concern not only provider-facing health IT like EMRs, but also Public Health Agency (PHA) health IT. This is an important acknowledgement by ASTP that both participants in a public health data transaction are responsible for its outcome and that efficacious bidirectional exchange of data will lead to the greatest utility of shared public health data. Our discussion will focus on the new certification criteria for the health IT used by PHAs.
HTI-2 proposes a baseline level of data exchange functionality for all certified PHA health IT systems. Important new requirements like a standardized data transport mechanism, data validation logic, and support for querying and filtering would be included in this baseline functionality. This would create much clearer expectations for external systems when sending data into or receiving it from PHA systems, leading to an environment in which stakeholders can better trust public health data quality and access it when needed.
Let's look at how HTI-2's proposed criteria would impact immunization data exchange as an example use case. Today, there is no standardized data transport mechanism that all PHAs must support to send and receive immunization data. This has led to mismatched, incompatible integration interfaces between EMRs and PHAs' Immunization Information Systems (IIS) and particular barriers to accessing immunization data from multiple states. HTI-2 would require PHAs' certified health IT systems to adopt SOAP-based data transport. We would prefer to see ASTP jump straight to FHIR APIs as it did for the public health FHIR API requirement for EMRs, but possibly more important than the chosen standard is the fact that a standard would now exist, allowing for more consistent and predictable connections with PHAs.
Equally important is today's lack of minimum validation logic required of PHA health IT when ingesting and storing immunization data. Data submission errors such as an invalid CVX code or missing required data like a vaccination date hurt data quality and erode users' trust. HTI-2 proposes that certified health IT for PHAs incorporate specific data validation, including data mapping, null value interpretation, and proper error detection, into the data ingestion process. This should create a baseline level of data quality that consumers of IIS data can expect.
Additionally, new requirements in HTI-2 mean that certified IIS would need to support a minimum level of querying and filtering. Say a patient comes to the emergency department after stepping on a nail, and their provider accesses the local immunization registry to determine the date of the patient's last tetanus shot. Without a way to filter down to only pertinent immunization data, the provider may see and need to hunt through a long list of vaccinations. But with HTI-2, that registry's software must be able to filter by a specific vaccine code, making it much easier for the provider.
While some of these changes may seem modest at first glance, ASTP's proposed requirements would finally establish clear baseline capabilities of PHA health IT systems to exchange public health data with a wide variety of stakeholders, including clinicians, researchers, and other health agencies. The COVID-19 pandemic highlighted the need for efficient exchange of public health data, including immunizations, disease transmission, drug prescribing, and lab results. This regulation would guide the US' public health ecosystem towards a future where public health data of verifiable quality can be exchanged through repeatable, secure integrations.
Showdowns through subscriptions
FHIR adoption in the U.S. healthcare system has been limited in supporting real-time workflows at the point of care, primarily because many EMRs have implemented FHIR without enabling external systems to detect data changes with webhooks. As a result, implementers often must rely on older integration modalities like HL7v2 for event-driven triggers. Some EMRs like athenahealth have implemented proprietary APIs to accommodate these types of workflows, and others like Epic and eClinicalWorks support the CDS Hooks specification, which allows the exchange of real-time data for clinical decision support in specific scenarios. That said, a standardized, API-based means of triggering real-time data exchange from within a source system has yet to be adopted across the health IT landscape, which has severely curtailed health IT innovation.
To address this gap, HTI-2 proposes the widespread adoption of the FHIR event subscription framework. This FHIR-based protocol would allow external systems to "subscribe" to notifications when a particular "event" occurs in a health IT system. For example, when a new lab result appears in an EMR, subscribers of that event would be notified, allowing them to retrieve those lab results from the electronic health record via a FHIR API request. Imagine if a patient's care team members could subscribe to each other's patient updates. Patients could identify new providers in pre-appointment questionnaires to allow for the exchange of EMR endpoint information. Then, when the patient's psychiatrist updates the dosage of a medication they are taking, the primary care physician's EMR would be alerted to this change. It could make a subsequent FHIR API request to the psychiatrist's system to get the medication update and notify the PCP of the change. This could all be implemented with a small fraction of the effort and cost needed to accomplish the same thing through an HL7v2 interface.
The proposed initial rollout of the FHIR event subscription requirement in HTI-2 focuses primarily on clinical data contained in key FHIR resources like Condition, DocumentReference, Immunization, MedicationRequest, Observation, and Patient. Subscribing health IT systems would be notified when a FHIR resource they are subscribed to is created or updated, allowing it to immediately retrieve those changes. We're pleased that ASTP incorporated filtering capabilities into the proposed subscription requirements; for example, Encounter subscriptions must be filterable on reasonCode, patient, and type.
The implications here are extensive. With better real-time data exchange, clinical decision support use cases expand dramatically. Contraindicated medications that a patient is on could be identified without relying on the patient properly relaying the changes to their care team. Public health agencies could be alerted in real time when a new case of a disease is identified, and details of the case could be made available in their systems immediately upon the diagnosis being documented in the provider's EMR.
In practice, use cases like these may be limited in the near-term, but the reason for this is much less likely to be technical in nature. These new requirements improve the repeatability and durability of event-driven data exchange by allowing us to finally move on from the HL7v2 standard and alter the cost-benefit analyses of decision-makers considering whether to invest in these types of integrations.
More ways to win
The proposed changes in HTI-2 are immense and this article has hit on only a subset of the changes that will take effect if the rule is finalized. We'll be following closely as HTI-2 makes its way through the finalization period. Given the impending presidential election and subsequent change in administration, it will be worth seeing whether ASTP is able to finalize HTI-2 in the near future. Overall, we applaud ASTP for proposing regulations that go all-in on advancing healthcare interoperability and improving patient outcomes.
