ONC HTI-1 NPRM Through Public Health Eyes

Though primarily aimed at EHR vendors and their users, there are a number of provisions of this proposed rule that have a direct, if not profound impact on public health systems and operations. There are two main areas where the proposed rule may have a major impact. Sorry, this gets a little long…

First, ONC proposes some changes to the current certification criterion for electronic case reporting (eCR) which to date has not included specific standards. The proposal focuses on an EHR’s ability to consume and process eCR trigger codes; create a standards-compliant electronic initial case report (eICR) in either CDA or FHIR format; and then receive, consume and process a standards-compliant Reportability Response (RR) once again in either CDA or FHIR format. EHRs then need to be able to transmit the eICR to an appropriate public health system that can receive it.

Today, eICRs are usually generated in CDA format (sometimes with the help of the eCR Now application which queries the EHR’s FHIR API and generates the CDA-based eICR) and then transmitted to the Reportable Conditions Knowledge Management System (RCKMS) through the APHL AIMS platform. The AIMS platform transports the message as well as the resulting RR using RCKMS data. These central services are capable of converting both the eICR and RR between CDA and FHIR formats. Over time we would expect the eCR process to migrate to a FHIR-based standard end-to-end, but it will take some time for all the pieces to catch up to this newer standard.

Generally, ONC did a good job of defining new certification criteria to help move eCR forward. Inclusion of consuming and processing the Electronic Reporting and Surveillance Distribution (eRSD) Specification Library and the eRSD Supplemental Library for trigger code processing is useful, while recognizing that though certification criteria need to identify a specific eRSD version, in reality these code sets can change rapidly, especially in an emergency. Across the board, both CDA and FHIR-based specifications for eRSD, as well as eICR and RR, need to continue to be supported for the foreseeable future as proposed. Of course, a clinical site must provide an eICR in the format required by the appropriate agency (CDA or FHIR), not simply pick one of these formats on its own. These criteria must reference the appropriate implementation guides which stipulate the required and optional data elements regardless of what USCDI might indicate more broadly. ONC also suggests that EHR technology needs to be recertified once these new criteria go into effect and we support clinical sites being required to use this newly-certified technology. 

Recognition by ONC of the role of the eCR Now application (or its functional equivalent in the future) might also be useful. As a nuance, ONC might stipulate more precisely that not only does a certified EHR need to support either CDA or FHIR-based files as proposed, but that the file format of the RR should match the format of the eICR originally generated (for example, if an EHR supports only CDA-based eCIR generation it should support acceptance of CDA-based RRs).

It is worth noting that while the NPRM recognizes that decision support for eCR is part of the workflow and process, the use of AIMS as the transport intermediary and RCKMS as the proscribed CDS strategy are not part of the recommendation even though it is the dominant architecture for eCR today. I do have mixed feelings about this. Likely ONC wants to ensure that standards-based case reports are transmitted as required by public health agencies that are receiving them. Since AIMS and RCKMS are not required by all public health agencies, I suppose it is consistent that ONC would not create a new requirement through this regulation.

The second major area of interest for public health are the newly-proposed “Insights Conditions” (an odd term, to be honest). These refer to a statutory requirement in the Cures Act for ONC to generate metrics for health data interoperability to measure the performance of certified technology in an open and transparent manner. ONC chose to focus initially on interoperability, and public health measures were included in the initial set. If approved as proposed, certified HIT developers will need to submit data every six months on the performance of software they distribute along with the methodology used to generate the data. These measures would be submitted to an as of yet unidentified independent party via a new submission website. Developers whose contracts prevent access to client data would need to renegotiate those contracts!

There are two measures related to public health that are identified in the NPRM, both related to immunization data interoperability. The first measure is focused on immunization data submission to immunization information systems (IIS). ONC claims that current information on this is insufficient, especially when they ask clinical sites about it via surveys. ONC wants to know “whether and to what extent providers are using their certified health IT to electronically send and receive public health information to and from public health agencies.” While the current compliance data that ONC collects on “active engagement” does not provide statistics, public health agencies certainly know the landscape of data submission for clinical sites submitting data. One has to wonder whether engaging with public health to generate some meaningful data might not be less of a burden on EHR vendors and their users and perhaps paint a more complete picture of the situation.

To achieve this measure, vendors will need to submit a numerator which is the number of immunizations submitted electronically to public health during the reporting period. Submissions that failed due to error (as reported back by the IIS in an HL7 v2 ACK message) would be subtracted. ONC wonders whether an immunization submitted to more than one IIS should count more than once. I don’t see why not, if this is a measure of interoperability. They also ask whether resubmissions to correct errors should count (they think they should). I see no reason why successful resubmissions of rejected transactions should not count since they were removed when unsuccessful. The denominator is the total number of immunizations administered. Both the numerator and denominator would be provided in total, and then segmented by children and adults. ONC states that, “Reporting by these subgroups will assist in interpreting the data and in creating public awareness that could inform IISs and others in the public health community about the progress being made in immunization data exchange… The data collected for this proposed measure would enable ONC to calculate the percent of immunizations administered where the information was electronically submitted to an IIS.”

Note that there are a number of important subtleties with respect to the proposed measures. Remember, an EHR may be just as likely to send a patient’s immunization history as much as a patient’s newly administered dose, or even both. In fact, an EHR can send the history over and over again. So in fact it is quite possible (or even likely) that the total number of doses submitted electronically exceeds the number of doses administered. It might be necessary to either ensure that the count of doses sent electronically only include those doses tagged as newly administered which is certainly possible but which complicates the data collection process. This concern could be mitigated by either making sure they are also included in the denominator or excluding them entirely. Note that historical doses may have questionable data quality and should have already been reported previously (even by a different provider).

Another issue is the potential that while only transmission of fatal errors are excluded from the count, the transmissions that had warnings of potential issues from the IIS (via HL7 v2 ACK messages) might in fact be resubmitted with some additional or corrected information. This has the potential to inflate the numerator in the calculation unless the vendor knows enough to exclude these resubmissions from the count. Keep in mind that any double counting of doses administered, especially in the numerator, makes all of the data suspect. To implement this right, an EHR must store the ACK(s) for each dose; and if the dose has at least one good ACK from an IIS, it can be counted in the numerator. Importantly, without a requirement to store the ACK, ONC would have no way to reliably audit a vendor’s reported metric. If storing ACKs is a requirement (as it must be in order to ensure the integrity of the metric), then ONC will also need to ensure that there is a standards-based way to store ACKs in FHIR resources.

To make matters worse, some providers delete a dose and then recreate it in order to edit a dose in their EHR. If a dose is deleted, logically it should be removed from the numerator and denominator going forward, but this could cause headaches for the data analysis at ONC if deleted doses have already been reported. Another potential problem is if two practices merge, or if a practice using two EHRs merges them into one, or if a practice simply migrates to a new EHR. ONC will need to provide guidance on exactly how doses should be counted in the metrics once they have migrated from one EHR to another.

The second measure is related to “Immunization History and Forecast,” in other words, query of an IIS. The numerator would be the total number of query responses received. Queries that failed due to error (as reported back by the IIS in an HL7 v2 ACK message) would be subtracted. ONC asks whether both queries with and without a forecast should count. Given that it’s the EHR that specifies what kind of data it wants in return, and there are use cases for both including and excluding an immunization forecast, I see no reason why both types of queries should not be included. There would be two denominators reported: first, the total number of queries; and second, the total number of encounters which might actually have a secondary use of measuring potential “missed opportunities” for immunization services. Both the numerator and denominators would be provided in total, and then segmented by children and adults. ONC states that “We propose to add this denominator to the measure proposed by the Urban Institute (the entity that developed the draft measures) to provide data on the total number of query responses that are and are not successfully received from an IIS.” I’m not sure I really know what that means. 

Note that there is also a proposed measure for the use of Bulk FHIR, but it’s unrelated to public health reporting. Though public health is working on a Bulk FHIR query for immunization data from IIS as part of the Helios FHIR Accelerator, the proposed measures are related to EHRs providing data through FHIR, not querying other systems for data.

Reporting would not be necessary for any site that did not administer immunizations. To reduce the burden on smaller vendors, they would be excluded from this measurement requirement if their products are used in fewer than fifty hospitals or by fewer than 500 users. I assume that a developer would submit single, aggregate numbers for numerator and denominator across all EHR sites that were included. I also assume that this data is not being collected for epidemiological study – and would not be available for that purpose – but only as a measure of the effectiveness of the certified technology.

I must admit, I am having a hard time accepting that these measures will really tell us anything we probably don’t already know with respect to interoperability between EHRs and IIS. On the data submission side, this is a requirement in many jurisdictions and is monitored closely as a function of vaccine inventory management and vaccine distribution through programs like the Vaccine for Children (VFC) program. For query, there are such varying clinical practices about when a query to an IIS is even appropriate that I am not sure how we will be able to interpret the data. The proposed metrics (based on the comments above) are actually quite complex to generate consistently. I would recommend against any further stratification or segmentation of the data as it will likely introduce even more burden on both vendors and providers. As is, I feel many vendors will have to enlist their customers to help them access the data and interpret it properly – I think there is a large potential for misunderstanding as some EHR clients do not necessarily use the software as the vendor intended. Remember, vendors will need to generate this data retrospectively from data stored in the EHR which may or may not be a simple feat.

Here are some additional items included in the proposed rule that public health agencies and stakeholders should review and comment on if desired:

• Changes to minimum code sets references in the regulations. For public health, this includes CVX and NDC codes which are related to immunization reporting. This is a structural problem in part: regulations (apparently) need to stipulate specific code set versions, but these code sets are constantly changing as new vaccines are introduced and others fall away.
• Update to a new version of the United States Core Data for Interoperability (USCDI). Though there are no EHR certification criteria for public health that reference USCDI yet, this may be something more relevant in the future. The proposal includes a refresh of relevant Clinical Document Architecture (CDA) implementation guide (IG) versions.
• Changes to the notion of clinical decision support (CDS). The proposal replaces CDS with “decision support interventions (DSI)” and more specifically “predictive DSI.” Users would need to determine (potentially with the help of industry groups) that a DSI is fair, appropriate, valid, effective, and safe (FAVES). Vendors would need to identify risk management practices – risk analysis, risk management, and governance. Users should be able to identify if certain data elements were used in the DSI. The proposed rule makes additional distinctions between a “predictive DSI” which is derived/informed by training or example data (like a probabilistic person matching engine and an evidence-based DSI (based on rules from experts, like a deterministic matching engine). While not aimed explicitly at public health, changes in this terminology and a refocus of ONC on CDS in EHRs might impact CDS as used by public health (for immunization evaluation and forecasting, for instance).
• Suggested changes to code sets and data elements related to sexual orientation and gender identity (SOGI), now proposed to be referred to as sexual orientation and gender information, which may have an impact on public health registry compatibility and longitudinal data analysis as these codes change over time.ONC included some brief Requests for Information related to specific topics that may have a public health impact:
  • Pharmacy RFI: Wondering, among other things, if pharmacy interoperability for prescribing and fulfillment should be subject to regulation. More consistent use of standards in this arena may benefit public health indirectly, though the impact on prescription drug monitoring programs (PDMP) may be more direct.
  • Lab reporting RFI: Wondering whether laboratory information systems and their use in lab orders and results processing should be certified based on a Congressional mandate to ONC to study this question. Public health lab reporting certification criteria are explicitly mentioned in this section. An interesting question is the relative importance of HL7v2, CDA, and FHIR standards for this activity.
  • FHIR RFI: This RFI addresses several capabilities of FHIR, including appointment scheduling through SMART Scheduling Links (COVID appointment scheduling automation problems were explicitly called out); SMART Health Links (once again, prominent during the pandemic for the use of its predecessor, SMART Health Cards, in providing COVID immunization histories); and CDS Hooks, demonstrated in public health clinical decision support for immunizations.

ONC is accepting comments on this NPRM through June 20, 2023 (see optional comment template document).

This post was published in the HLN Blog. It is reprinted by Open Health News with permission. The original post can be found here.