The ONC Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing proposed rule (HTI-1 for short) is a bit of a mishmash covering all sorts of proposals in a variety of areas:
- updates to the data standards required for various certifications
- various adjustments to API and other rules
- mechanisms for patients to request specific data not be exchanged
- interoperability quality measures reporting under a new Insights Conditions program
- changes to the information blocking rules
- changes to the way clinical decision support (now called decision support intervention) is managed and expands it to include AI and machine learning
It also includes RFIs on FHIR, real-time pharmacy benefits, and laboratory data. If finalized as is, most components in the rule would take effect on January 1, 2025 but a few are scheduled for January 1, 2026 instead.
No single article can discuss everything in the rule - there's just too much there - but we'll look at some highlights in each of the following areas:
- Standards updates
- Demographic data
- Other certification updates
- Patient consent
- Decision Support Interventions
- Insights reporting
- Information blocking
- RFIs
Standards Updates
The biggest change here is a move from USCDI v1 to USCDI v3. ONC plans to deprecate support for USCDI v1 on January 1, 2025 and make USCDI v3 the new minimum data set for support within certified health IT at that time.
USCDI v3 adds quite a bit of new data to the required baseline support compared to the previous USCDI v1 expectations. In keeping with the ONC health equity by design approach, it incorporates a lot of equity-related data including new demographic data (particularly around sexual orientation and gender identity or SOGI), several new health status categories (including pregnancy and disability status), and SDOH-related data including goals, assessments, problems/concerns, and interventions. It also adds data about encounters, diagnostic imaging, non-laboratory clinical tests, care team members, and health insurance information to the mix.
In addition to the move from USCDI v1 to v3, HTI-1 also iterates the following standards:
• US Core to v5.0.1 (only because v6.0.0 hadn't been released yet)
• Code system version updates (to match those required in USCDI v3)
• SMART on FHIR v2
• Updates to code sets defined in regulation
The last category is interesting because it functionally overlaps with the role of USCDI now that USCDI exists. Ideally these other requirements would be incorporated into USCDI then deprecated as separate requirements. This type of duplication is often problematic; we'll discuss this in more detail in the next section on demographic data.
Demographic Data
In addition to the data required by USCDI v3, HTI-1 updates the following separate code sets defined in the Federal Register:- § 170.207(a)—Problems
- § 170.207(c)—Laboratory tests
- § 170.207(d)—Medications
- § 170.207(e)—Immunizations
- § 170.207(f)—Race and ethnicity
- § 170.207(m)—Numerical references
- § 170.207(n)—Sex
- § 170.207(o)—Sexual orientation and gender information
- § 170.207(p)—Social, psychological, and behavioral data
- § 170.207(r)—Provider type
- § 170.207(s)—Patient insurance
Many of these have direct analogues in USCDI. This can lead to maintenance difficulties, potential incompatibility problems, or different requirements in different sections of the rule. It also makes the idea of USCDI encompassing the baseline required data support murky because other required data is being defined elsewhere.
In this iteration, this issues manifests most significantly under demographic data support. USCDI v3 considered supporting several additional demographic data elements including preferred pronouns and name to use but decided against it, citing lack of industry readiness. However, both of these data elements are required under the new sexual orientation and gender information standards outlined in § 170.207(o). This is inconsistent and confusing.
To add insult to injury, the actual data requirements are not entirely clear, referencing external data sets generally without specific links. Pronoun data is supposed to come from LOINC, but the only list of pronouns in LOINC is an example set - is ONC adopting that example as the full breadth of its support? It's unclear, and we asked for further clarification in our comment. Hopefully they'll clear up some of the confusion in the final rule.
Other Certification Updates
HTI-1 includes a lot of disparate requirements. We won't discuss all of them here, but some of the more interesting requirements include:
- Requirement to use a standardized naming format and to publish all service base URLs (endpoints) regardless of whether services are hosted by the certified health IT developer or installed locally
- Ability to expire access tokens for patient-facing third party apps within 60 minutes of patient request (or generate tokens that are valid for 60 minutes or less so new requests can be rejected if the patient has revoked access)
- Issue refresh tokens for B2B apps (apps using the confidential app profile) that are valid for at least three months at a time
The first two are extremely positive in our view. Having predictable names for endpoints as well as a requirement that all endpoints be published regardless of where the servers processing requests actually reside will make it much easier to find and use partner services. Requiring specific standards of behavior when patients revoke application access will also go a long way toward their comfort in using such apps.
The refresh tokens are a bit more problematic because of the way SMART on FHIR works. Authentication tokens for SMART on FHIR apps include scope information providing the access rules for bearers of the tokens. Having tokens last that long may mean that underlying changes to access rights may not be respected. We suggested ONC revisit this requirement when finalizing the rule.
Patient Consent
Certified health IT should support a new mechanism allowing users to mark any individual data element in USCDI v3 as restricted from exchange. This option would be exercised in conjunction with patient requests to restrict data per their HIPAA rights. This rule does not change the HIPAA rule, impose additional requirements around the way these requests are adjudicated, or the ability of a provider to say no to these requests.
It does provide a framework for noting decisions to honor patient requests for restrictions. These are intended to be globally applied for each data element. Our comment suggesting supporting more granular controls in terms of allowing some exchanges but not others and the ability to group types of data together to apply the same rules to the whole group.
The rule also requires supporting an electronic mechanism for patient requests to restrict sharing of USCDI data elements. Our comment noted this should be available both via the patient portal and via API (both for those patients who cannot use a portal and to permit third party app access to this data).
Decision Support Interventions
Decision Support Interventions (DSI) replaces Clinical Decision Support as a certification area. It encompasses the existing functionality as well as similar options for administrative, financial, and other non-clinical purposes. It encompasses traditional decision support mechanisms as well as various types of AI. It also covers the development and use of models and tools.
Frankly, ONC is too vague about when different statements apply. For example, sometimes it is difficult to sort out what content applies to developing algorithms vs using algorithms developed by others. We asked ONC to better differentiate between topics and specify what is under discussion in each portion of this section.
Pervasive throughout this section was the idea of FAVES (fair, appropriate, valid, effective, and safe) DSI as the goal. Obviously other areas are important too (such as security) but the bulk of the discussion focused on areas that fall under FAVES, most notably transparency.
Transparency really is king here. Much of the criteria outlined in the rule involves ensuring real transparency around the development of algorithms, the source of their ground truth data, and the way the data is evaluated. However, ONC does not actually regulate the use of DSI. Rather, it mandates how certified health IT presents DSI to clinical users and to folks using certified health IT to aid in the DSI development process.
We will revisit this topic when the final rule is released. Hopefully ONC takes our suggestions to separate development and usage information and clarify these requirements in the final rule.
Insights Reporting
This rule outlines a new Insights Condition related to reporting quality measures around interoperability use and performance for EHRs and other certified health IT.
The initial proposal includes nine measures across four categories:
- Individual access to EHI (format agnostic)
- Public health information exchange
- Clinical care information exchange
- Standards adoption and conformance (including FHIR and bulk FHIR)
These measures must be reported every six months for each certified health IT module with at least 50 hospital or 500 clinician users. If you do not meet the conditions required to report you still need to attest that you do not qualify. ONC plans to provide a six month window for collating data after its collection, meaning data collected from April to September of one year is reported in April of the following year and data collected from October to March is reported in the next October.
The first set of measures start reporting in April 2025 and the second set follow a year later. ONC has made it clear additional measures will be forthcoming in the future. ONC has indicated any contract renegotiation needed to collect the necessary data must be in place prior to the start of its first collection window.
Information Blocking
ONC has made some adjustments to the information blocking rules (also known as information sharing rules). They clarified several definitions, particularly around trying to make a distinction around when a provider is acting as an entity providing health technology vs an entity providing healthcare. They also renamed the Content and Manner exception to just the Manner exception since all electronic health information or EHI is now subject to the rule. There are several new exceptions or conditions to existing exceptions including:
- An Uncontrollable Events condition of the Infeasibility exception to cover natural or man-made disasters (war, civil unrest, etc.) or other unavoidable service interruptions (utilities outages, strikes, etc.). The event is not sufficient; a direct causal link from the event to the inability to share data must be established.
- A Manner Exception Exhausted condition of the Infeasibility exception that sets forth some rules around when the parties can give up on coming to agreement on an acceptable form/format for the data exchange
- A TEFCA condition of the Manner exception that states the requestor must accept information via TEFCA if they are a TEFCA QHIN, participant, or sub-participant, even if they'd prefer to receive it via other means or in other formats
This last condition is problematic in our view as it requires organizations to take an "all in" approach to TEFCA. They cannot choose to use TEFCA selectively, but must be willing to use it for any data if an exchange partner prefers. Further, it is unclear if this applies to an entire organization even if only one business unit signs up for TEFCA and is prepared to interface with it. This could result in an unintended disincentive to TEFCA participation.
RFIs
This proposed rule also included several RFIs including:- Laboratory Data and Interoperability
- FHIR
- Pharmacy Interoperability
We've seen laboratory projects come to a screeching halt because of the inability to standardize data or code set use. MHDC supports improvements in this area, but we focus on the other two RFIs in this article.
On the FHIR front, ONC specifically asked about FHIR subscriptions, CDS Hooks, FHIR Scheduling, and SMART Health Links. We support exploring additional uses of all of them, but are looking at just the first two here.
FHIR subscriptions are interesting because they're one of the areas that changed radically between FHIR r4 and FHIR r5. FHIR r4 - the version mandated for use in the US - supports query-based subscriptions while FHIR r5 switches to topic-based subscriptions. However, support for topic-based subscriptions has been backported to FHIR r4 in a somewhat haphazard manner and will likely be used in future iterations of prior authorization workflows. To add even more complexity, the questions ONC asked made it obvious they were not entirely clear about this current landscape. In a perfect world, MHDC would not recommend supporting FHIR subscriptions until the US moved to FHIR r5. However, the likely choice of using the backport for future prior authorization workflows means we may not be able to wait.
CDS Hooks is an interesting area. Hooks are triggers that permit some external action or activity to take place when a particular event happens (usually tied to an EHR activity such as viewing a patient record). They've been around for quite a while and are part of the prior authorization workflow (among many other workflows). The big issue here is which version of CDS Hooks ONC should support in future rulemaking. They ask whether v1 is mature enough, but v1.1 was released three years ago and many are already using it. Version 2.0 was released almost a year ago. We recommended supporting at least v1.1 in our comment.
ONC also asked for comment on which hooks should be required. The prior authorization workflow alone uses most of the defined hooks. Two of the three other hooks seem like they'd have lots of potential uses so we recommended requiring support for all of them.
The Pharmacy RFI was by far the largest, asking questions about real time prescribing, prior authorization, adoption of newer NCPDP standards, price transparency at the time of prescribing, collection of demographic data during the prescription process, code standards for prescriptions, access to formulary data, and more. In general, our comments were in favor of better data definition, more standardization, more consistency, and more transparency in all of these areas.
Takeaways
ONC's HTI-1 proposed rule is complex and wide ranging. It covers a lot of ground and needs polishing before it's finalized. Some key provisions include moving the baseline federal data standard to USCDI v3, starting the process of dealing with AI in healthcare, and adopting mechanisms for managing patient requests that their data not be shared. HTI-1 clearly signals additional plans to increase areas of FHIR certification in the future and extensive plans for improved integration of pharmacy data and workflows with other types of medical data. One thing it does not do is address prior authorization.
A proposed rule being called HTI-2 is on the books for an expected release in November 2023 with no specifics of its contents available. The industry expects that rule to cover prior authorization. Regardless, the interoperability rules will keep coming from both CMS and ONC. Other related rules will come from other federal agencies. MHDC will be here to help you understand them when they do.