On July 1, 2024, The Sequoia Project, as TEFCA’s Recognized Coordinating Entity (“RCE”), released new documents with TEFCA’s July 2024 update. Here’s the public announcement. These are a lot of documents, like a huge, hot stack of pancakes, with a lot of detailed, complex and interconnected pieces. Which is to say, prepare for some digestion issues. So we’ve decided to offer a side stack of hot takes to make them easier to digest, delivered as David Letterman would, with a top 10 list.
10. RCE devised a solution to deter misuse of Treatment-based exchange in TEFCA’s July 2024 update.
TEFCA keeps the original Treatment exchange purpose (T-TREAT), which aligns to the HIPAA definition of Treatment, but adds a more selective exchange purpose called “TEFCA Required Treatment (T-TRTMNT)”.
T-TRTMNT can only be asserted by health care providers regulated by HIPAA or their delegates, with a major caveat that health plans can’t be a health care provider’s delegate for Document Queries. For more, see #6 below. The theory seems to be, it’s easier to objectively trust that a HIPAA health care provider will query for an authorized treatment purpose, or a delegate (other than a health plan) that’s been authorized to query for that provider. If a responding party can find that health care provider’s details in the RCE Directory Services, and interrogate the delegation, it’s easier for the responding party to trust that request’s treatment purpose, and respond with information. Relationships between health care providers and health plans are trickier, though, so the RCE has other plans for health plans to participate in TEFCA.
9. RCE also creates transaction codes for all exchange purposes; they act like “click wrap” attestations for each transaction.
The codes align to TEFCA’s six original exchange purposes (Treatment, Payment, Healthcare Operations, Individual Access Services, Public Health and Government Benefits Determination), plus three codes for these newly created selective exchange purposes: TEFCA Required Treatment, Public Health – Electronic Case Reporting and Public Health – Electronic Lab Reporting. Any of these codes must be in each new transaction initiated on the network. The selected code represents the initiator’s attestation that it has authority to receive information for the claimed exchange purpose, and adheres to all Framework Agreements, the QTF, relevant SOPs and Implementation Guides and Applicable Law.
These codes, combined with other updated requirements throughout TEFCA’s July 2024 update, means that disputes can be addressed at the transaction level, with initiators accountable for compliance with all TEFCA requirements, not just with applicable law. More detailed operational controls for audit log reporting, RCE Service Directory maintenance and how the rest of transactions must be composed should further help deter misuse of the network. They might also alleviate operational and regulatory burdens on responders, which became apparent as the Epic-Particle dispute became public, when some responders turned to manual vetting processes to make sure initiators were using Treatment appropriately.
8. RCE withdrew its proposed “Healthcare Ops (Facilitated FHIR only)” as a mandatory exchange purpose, but replaced it with a flexible incentive structure.
In the new Exchange Purposes SOP, the only exchange purposes with mandatory responses where a fee can’t be charged by responders are TEFCA Required Treatment (T-TRTMNT) and Individual Access Services (T-IAS). Responses for the remaining transactions (Treatment (T-Treat), Payment, Healthcare Operations, Public Health, Public Health-Electronic Case Reporting, Public Health-Electronic Lab Reporting and Government Benefits Determinations), are optional, and responders can charge a fee.
In effect, RCE has designed a voluntary framework for responders to decide if, when and for what fees it will support these other exchange purposes. We’ll know if this approach is successful if more data holders join TEFCA and begin to support these other purposes.
7. The new incentive structure helps resolve business conflicts with EMR payor platforms.
A lot of EMR vendors have private payor platforms as existing business lines with their customers, where they charge payers and others for access to clinical data. These EMR vendors and customers have been hesitant to join TEFCA, and one reason might have been over concerns that prescriptive mandates (for example, for Healthcare Ops (Facilitated FHIR only) would cannibalize these businesses.
If the new incentive structure described in #8 translates into a complementary source of revenue for these data holders, it could help RCE’s aims of expanding TEFCA into all its intended exchange purposes faster, and might be the change that ensures TEFCA’s ultimate viability. To see if it works, we’ll be watching for early indicators of (x) EMR customers joining TEFCA in greater volumes, and (y) EMR customers expanding support for these optional exchange purposes.
6. Some health plans will feel sucker-punched by TEFCA’s July 2024 update.
Health plans are boxed out from initiating transactions with the TEFCA Required Treatment code. Some might need to rethink their health interoperability strategies, and plan to pay more for data access.
Health plans can consider one or more of these options as part of a single- or multi-threaded interoperability strategy: (a) go direct to the private payor platforms, but that will cost money and require multiple integrations; (b) query for Treatment, but responses are optional, will cost money and may draw scrutiny; (c) collaborate with data holders to enable TEFCA exchange for Payment or Healthcare Operations under the new incentive structure, but this will take time, cooperation and money; (d) introduce health care providers to interoperability vendors that support TEFCA, and create private downstream sharing arrangements between providers and health plans, enabled by these vendors; (e) leverage consumer-directed access and sharing of their health data through a network of patient access API connections and individual access services through networks, because data holders can’t charge fees.
5. RCE moved Facilitated FHIR out of the QTF and into a new voluntary incentive framework too.
Moving Facilitated FHIR out of the QTF and into a new Facilitated FHIR SOP takes the pressure off QHINs, participants and subparticipants from supporting Facilitated FHIR solutions right away. Instead, RCE encourages members of the TEFCA community to form voluntary alliances with partners of their choice on activities that align to the Facilitated FHIR SOP roadmap, without an immediate obligation to support others that might want the same connectivity. The roadmap aligns to some of the new QTF requirements, but it also encourages adopters to start implementing dynamic client registration by following the HL7 FAST Security for Scalable Registration, Authorization & Authentication IG v.1.0.0 STU1; or use manual registration, at least until January 1, 2026.
Again, by adopting a more flexible structure instead of prescriptive mandates, the RCE is encouraging members of the TEFCA community to decide which FHIR-forward neurological pathways they want to prioritize, and allow a multiplicity of pathways to emerge. This is an elegant approach that promotes innovation, free market principles and open standards. But it should also be noted, RCE has no enforcement discretion over the Information Blocking Rule or federal antitrust law. That means data holders must still meet their info blocking obligations, like support for connectivity through APIs based on ONC approved standards, and they can’t use their market dominance unlawfully in ways that harm the competitive process.
4. RCE creates requirements that should allow initiating nodes to point to different responding nodes.
This is good for health care providers using products and services outside their EMR to get health information, but want just one system to respond with information from their designated record set.
This is a big advance for TEFCA, filling a parity gap with what’s supported today in Carequality and Commonwell. These use cases will encourage participants to pressure test TEFCA to see if enhanced requirements in the QTF and RCE Directory Service SOP provide the needed transparency and accountability to deter misuse and promote appropriate use of the networks, and more streamlined, predictable paths for reciprocity requirements to be met.
3. The RCE Directory Services SOP answers a long-sought need for a national digital healthcare directory.
Back in the day, when the 21st Century Cures Act became law in December 2016, Congress directed HHS to establish, directly or through a partnership with a private entity, “a provider digital contact information index to provide digital contact information for health professionals and health facilities.” In 2022, HHS published a request for information for a national healthcare directory. Eight years on, interoperability continues to be hampered by the absence of a comprehensive, open, actively managed directory of digital endpoints.
RCE’s updated RCE Directory Services SOP could finally stand up the long pole for the health interoperability tent. Among other things, QHINs and, through contract flow downs, all TEFCA participants and subparticipants, will be required to maintain up-to-date information in QHIN directories, and QHINS would be required to regularly sync these directories with the RCE Directory. Plus, these directory entries will be required to include all FHIR endpoints, and important organizational and location details so initiators can find data down to the provider and facility level much more confidence that they’re getting it from the right place. This will also support targeted queries in TEFCA.
2. Unlike HIPAA or the FTC Health Breach Notification Rule, TEFCA imposes reporting obligations on recipients of TEFCA Information.
These reporting obligations will promote discovery of Security Incidents or Threat Conditions by responders so they can perform their HIPAA Breach Notification obligations. Responders might still be able to decide a Breach is not reportable under the low probability of compromise analysis, but the reporting requirements are an important pillar of promoting transparency.
That said, there is a significant variance in the reporting obligations between HIPAA entities and Non-HIPAA Entities. For example, a reporting obligation doesn’t attach to a HIPAA Entity after TEFCA Info becomes part of a Designated Record Set, unless the incident involves an external attack. Because Non-HIPAA Entities don’t create Designated Record Sets, their reporting obligations attach anytime a breach of unencrypted individually identifiable information occurs. That includes situations when a member of a Non-HIPAA Entity’s workforce discovers a record for the wrong patient was shared through a TEFCA transaction. HIPAA Entities in the same situation don’t have to report this as a Security Incident.
There is an odd interplay between the TEFCA Security Incident SOP and HIPAA. Whether the wrong record is shared with a Non-HIPAA Entity or an unrelated HIPAA Entity, it’s still technically a Breach. The critical difference is that the SOP imposes a reporting obligation in this instance, when HIPAA does not. The reason to impose a greater reporting obligation on Non-HIPAA Entities is that they won’t have permission from the patient of a wrong record to access, use or redisclose their information. If a HIPAA Entity subsequently uses or rediscloses the wrong record, they will have to demonstrate that an available HIPAA permission or exception applies.
In the end, most Non-HIPAA Entities will be involved in TEFCA to support Individual Access Services. Consequently, the policy question is whether the over/under for this SOP is whether it improves chances that data holders will respond with records to Individual Access Service requests. We’d like to think so, but as with all things in health interoperability, we have to see how policy plays out in practice. We are not opposed to Non-HIPAA Entities reporting when they discover and report wrong records. Reporting gives data holders the information they need to determine whether a Breach is reportable under the low probability of compromise analysis in the HIPAA Breach Notification Rule. When Non-HIPAA Entities demonstrate that they have the appropriate data protections and controls to detect, report and avoid redisclosure of the wrong records, more data holders will be justified in adjusting their local security policies to reflect a greater tolerance for potentially mismatched records to be shared with Non-HIPAA Entities.
In practice, we expect this may translate into non-scalable vetting practices, and that will gum up the gears for Individual Access Services in TEFCA. But this SOP helps begin to break the current logjam in local security policies, which tend to be categorical in denying individual access service requests. All of which is to say, let’s begin these queries in earnest, and center our dialogue around compliance under this SOP, so the neurological pathways for trusted exchange for IAS requests can be established.
1. Query Initiators are free to share patient consents and other documents, but responders don’t need to act on them (yet).
In January 2024, RCE introduced a concept from the Carequality Framework that allows query initiators to share documents like a completed patient permission form that responders can consider in deciding whether to share documents on a given patient. This concept is called Access Control Policies, and each document on a patient, represented by a unique URI, is an Instance Access Control Policy. Access Control Policies sets the stage for responders to validate patient consent in transactions asserting an Individual Access Service exchange purpose, or even to validate patient consent in payer-to-payer API transactions or provider attestations in provider access API transactions if Facilitated FHIR enables compliance with the latest CMS interoperability mandates. While the final July 1, 2024 QTF v.2 includes requirements for QHINs to support the access and sharing of IACPs, it does not require Responding Nodes to access an IACP, or incorporate it into their decision whether to release information about the impacted patient. Consequently, we are not any clearer whether these requirements will improve response rates for Individual Access Service requests, but perhaps adopters implementing the Facilitated FHIR roadmap will act as an accelerant.
Closing Thoughts
Overall, RCE has attempted to address stakeholder concerns about TEFCA’s potential risks to their revenue models with incentives as much as possible, rather than running roughshod over them with directives. It also seems like RCE has taken to heart that it needs to solve for the “T” (trust) in TEFCA. These trust predicates set the stage for the next important phases of growth in TEFCA, which center around expanded support in and beyond treatment, support for FHIR and support for individual access through Non-HIPAA Entities.
