Musings on the HITAC special meeting on TEFCA, 13 Oct 2021
Considerations for Federal Agencies anticipating FHIR-based exchange
Context
HITAC (Health Information Technology Advisory Committee) is an advisory committee to ONC (Office of the National Coordinator for Health IT).
The 2016 21st Century Cures Act called for a TEFCA (Trusted Exchange Framework and Common Agreement) to establish a minimum national standard for interoperability. In August 2019, The Sequoia Project was selected as the RCE (Recognized Coordinating Entity) to administer the network. In July 2021, a draft Qualified Health Information Network (QHIN) Technical Framework (QTF) was released [1].
Today, TEFCA and QTF presented their progress to HITAC.
Summary of QTF and Common Agreement Drafts with respect to FHIR
As with any complex technical system, let us begin by defining the scope of the Common Agreement and QTFv1. QTFv1 provides the technical exchange specification between QHINs, i.e. QHIN-to-QHIN exchange.
QTFv1 Summary
QTFv1 DOES
- Define QHIN-to-QHIN exchange
- Use IHE (Integrating the Healthcare Enterprise) Profiles with C-CDA (Clinical Document Architecture) documents, not FHIR [2]
- Support targeted queries to specific nodes, as well as broadcast queries.
- Impose technical “flows-downs” from QHINs to Participants, but these are limited. The technical burden on Participants should be substantially less than the technical burden on QHINs.
QTFv1 DOES NOT
- Define QHIN-to-source exchange
- Restrict QHIN status to only HIEs (Health Information Exchange)
Discussion of “QHIN on FHIR” for QTFv1
Most importantly for FHIR, QTFv1 in no way precludes QHIN-to-source exchange via FHIR.
A “QHIN on FHIR” would require
- IHE to FHIR mappings (for queries)
- FHIR to IHE mappings (for message delivery)
- FHIR end-point directory for participants
A “QHIN on FHIR” would benefit from (in the near-term)
- Barring sub-participants use of FHIR
- Restricting FHIR exchanges to a small number of IGs and use-cases, and then slowly expanding the footprint.
IHE profile to/from FHIR mappings are required because the QHIN-to-QHIN exchanges must use IHE profiles. If the QHIN on FHIR were to bar sub-participants and only exchange with Participants directly, the multi-hop “known unknowns“ for routing and authorization could be side-stepped.
Common Agreement Summary
Common Agreement DOES
- Impose “flow-downs” from QHINs to Participants, but these are limited. The legal flow-downs are codified in the Common Agreement, “cooperation and nondiscrimination; confidentiality; utilization of the RCE Directory Service; Uses, Disclosures, and responses; Individual Access Services; privacy; security; and other general obligations.” (p. 6 of Elements document). The concomitant technical flow-downs are specified by the QTF.
- Allow QHINs to charge Participants (and presumably, Participants to charge Sub-Participants)
Common Agreement DOES NOT
- Allow QHINs to charge (impose fees) on each other
- Require providers to participate in TEFCA
Discussion of “QHIN on FHIR” for Common Agreement v1
The Common Agreement is agnostic to payload, and should support “QHIN on FHIR” in QTFv1 without modification. I expect mostly clarifications, and maybe a handful of small changes, in the Common Agreement v2 (my guess is 2024/2025) to incorporate the community’s FHIR-specific learning.
Opinionated responses to common TEFCA on FHIR questions
Why do we still need TEFCA when we already have (proprietary) national networks?
Because the market is extremely fragmented, the existing networks don’t interoperate (eHealthExchange, CareEquality, DirectTrust / SafeIdentity) and the last mile implementation is spotty. The promise of TEFCA is a network of networks. Current networks are concentrated in the provider-to-provider clinical data exchange space; with relatively little progress in areas such as networked exchange for public health. With TEFCA, in theory, an Actor (Participant or Sub-Participant) could connect with a single home network (QHIN), and thereby abstract away the complexity of exchange with the broader network.
Doesn’t FHIR make TEFCA obsolete?
A: No. FHIR (Fast Healthcare Interoperability Resources) supports REST, document and messaging-based exchanges. Most production FHIR systems use REST. FHIR REST is great for B2C (business to consumer) use-cases and can be used in low-volume B2B (business to business) use cases. Where a network shines is high volume B2B use cases, including both bi- and multi-directional message passing.
Further, FHIR is silent on the “common agreement” in TEFCA. Even if FHIR messaging supplants HL7v2 messaging and C-CDA documents — which IMO it won’t for at least a decade under the most optimistic timelines — you still need a common agreement and standards for network-to-network exchange.
Why doesn’t TEFCA require FHIR for QHIN-to-QHIN exchange?
The 21st Century Cures Act mandate for TEFCA includes reusing existing infrastructure [3]. FHIR is a comparatively new standard compared to the IHE standards, the C-CDA based exchanges are more familiar to existing networking participants and FHIR can be added later. Specifying FHIR-based QHIN-to-QHIN exchanges and revamping the existing networks for FHIR is a bigger lift than the QTFv1 approach.
As a stop-gap, and in recognition of the communities desire for FHIR-based exchange, QTF has agreed to publish a roadmap for TEFCA on FHIR in in Q1 2022. My guess is a FHIR-based v1 would push the timeline for QTFv1 out from Q1 2022 to 2023. Instead of delaying TEFCA, release a QTFv1 without FHIR and do TEFCA on FHIR in QTFv2 (my guess is draft in 2024; finale in 2025).
Most importantly, the QTF would have to figure out how to support multi-hop authorization and routing with FHIR. Both of these are surmountable technical challenges. FHIR R4 does not specify authorization. SMART on FHIR, specifies client-to-server authorization using OIDC and OAuth2.0. SMART on FHIR does not specify a multi-hop authorization scenario. OAuth2.0 Extension Grants [4]. The FHIR messaging exchange pattern doesn’t address multi-hop.
Considerations for Federal Agencies
Let us consider the use case from “Architectural considerations for FHIR submissions to US Federal Agencies,” a Federal Agency that wants to accept streaming FHIR-based submissions from submitters. While QTFv1 uses IHE profiles with C-CDA documents, not FHIR messaging, there is nothing precluding a Federal Agency from accepting FHIR messaging from its submitters. The decision for the Federal Agency is then…
- Option 1: Ignore QHINs, and accept FHIR messaging in a parallel network
- Option 2: Become a Participant in a QHIN that accepts FHIR messaging
- Option 3: Become a QHIN, that accepts FHIR
Option 1: Ignore QHINs, and accept FHIR messaging in a parallel network
The pro of this approach is that the Agency can, at least initially, move much faster without the TEFCA requirements.
The con is that, over time, the Agency network will likely be forced to interchange with a TEFCA network. Given that these would be bottom-up requests for information or “get it done, I don’t care how” political imperatives, I anticipate ungoverned exchanges from the Agency network to the TEFCA network. In avoiding TEFCA, the Agency may, in the long-run, reap a worst of both worlds outcome.
Option 2: Become a Participant in a QHIN that accepts FHIR messaging
The con is that i) the Agency must identify and contract with a QHIN that supports FHIR messaging, and ii) the Agency would be subject to the flow-down provisions for the Common Agreement and QTF. ONC roadmap calls for releasing the Common Agreement v1 and QTF v1 in Q1 2022, with onboarding to follow in the remainder of 2022. We must assume that QHIN adoption of FHIR for Participants will lag; a pool of “FHIR-ready” QHINs does not exist.
The pro of this approach is that in the mid-term (2–5 years), it may be possible for Federal Agency Participants to utilize specific exceptions to the Common Agreement.
Both Public Health Authorities and governmental agency that determines non-health care benefits are exempt from required responses [5], though they may choose to respond to TEFCA requests. Consider an Agency like VA (Veterans Affairs) VBA (Veterans Benefits Administration). Without the exception, they may have considered TEFCA-based exchanges for coordinating non-healthcare benefits “juice not worth the squeeze”; however, with the exception they have the freedom to sign-on as a Participant and then, gradually grow (or not) their TEFCA response footprint.
Option 3: Become a QHIN, that accepts FHIR
The Common Agreement require all QHINs to support all exchange purposes: Treatment, Payment, Health Care Operations, Public Health, Benefits Determination, and Individual Access Services. While a very positive step for interoperability, as it sets a higher minimum standard for QHINs, it may have chilling effect on Federal Agencies considering QHIN status.
For example, while it my be reasonable for the CDC to support a QHIN for Public Health Exchanges, it may be a bridge to far to support the other 5 exchange purposes which are not as core to the CDC’s mission.
Federal Use Case: CDC PRIME ReportStream
There are very targeted purpose built networks; for example, those that have emerged due to COVID, that must consider whether to remain independent networks (Option 1), or participate in TEFCA exchange (Option 2 or 3).
One example is the CDC PRIME ReportStream, which is used for electronic COVID case reporting in 23 states. ReportStream is purpose-built for COVID case reporting, is not a generic network, and does not connect to other networks. These are not failures of ReportStream; rather, the illustrate the difference in scope between a specialized network like ReportStream and the general purpose network of networks envisioned by TEFCA.
Footnotes
[1] TEFCA QTF Draft 2 (for Version 1)
[2] Specifically, the IHE profiles: IHE XCPD [ITI-55], IHE XCA Query [ITI-38], IHE XCA Retrieve [ITI-39], IHE XCDR [ITI-80]. IHE does not specify the network payloads, beyond “a collection of bytes.” The QTFv1 asserts that the payloads shall be C-CDA. IHE profiles do not preclude QTF from extending support for payload formats in the future.
[3] 21st Century Cures Act, Sec. 4003. Interoperability
(iii) EXISTING FRAMEWORKS AND AGREEMENTS. — The trusted exchange framework and common agreement published under subparagraph © shall take into account existing trusted exchange frameworks and agreements used by health information networks to avoid the disruption of existing exchanges between participants of health information networks.
[4] OAuth2.0 Extension grants (https://www.rfc-editor.org/rfc/rfc6749#section-4.5). Discussion of OAuth2.0 extension grants for multi-hop (https://stackoverflow.com/questions/41021401/how-can-we-pass-identity-over-multiple-hops-with-openid-connect-oauth)
[5] The Common Agreement summary text, “Elements of the Common Agreement September 20, 2021”, is ambiguous on whether these exceptions apply only to Participants, or also QHINs. However, I take a “spirit of the law” interpretation to that only Participants are allowed exception. QHINs should be general purpose, supporting all six exchange purposes without exception (at the QHIN level).
