The Trusted Exchange Framework and Common Agreement, created by the Office of the National Coordinator for Health IT under the 21st Century Cures Act, holds huge promise for interoperability and information exchange.
It also has big implications for privacy and security.
“It’s possible that a TEFCA security incident is also a HIPAA security incident, and it’s possible that a HIPAA security incident may or may not be a TEFCA security incident,” said Johnathan Coleman, principal at Security Risk Solutions and the chief information security officer at the Sequoia Project, TEFCA’s recognized coordinating entity.
At HIMSS24, this past month, Coleman, alongside Zoe Barber, Sequoia’s policy director, provided an overview of TEFCA’s incident response and incident reporting flows, focusing on developing areas that could trip up non-HIPAA-covered entities.
New agility, new security requirements
Barber said requirements securing protected data exchange under TEFCA would not see significant updates in the upcoming second version of the common agreement.
“Privacy and security obligations apply to all, and they are consistent across the framework,” she said during a brief TEFCA overview before Coleman dove into TEFCA’s cybersecurity incident reporting nuances.
While Sequoia, as RCE, is making it easier to exchange data by simplifying how participants connect to the network, under TEFCA, an individual participant can use an app of their choice to request access to their health information.
Since the Office of the National Coordinator for Health IT drafted the TEFCA interoperability proposal, it’s also gotten easier for principal delegates – a vendor, health information exchange or another business associate working for primary authorities that provide clinical services and maintain patient data – to exchange and simplify their connection to the network, Barber explained.
Creating more agility for participants means that exchange is not just QHIN-to-QHIN, but interoperability can happen directly between participants through APIs.
“We previously had a pretty hard requirement that you could only participate with one [qualified health information network], but now we’re breaking that open a little bit to allow for participation among multiple QHINs – as long as you’re using a different system,” she said.
Encryption for HIEs, BAs and others
Changes to support wider use of Health Level Seven’s Fast Healthcare Interoperability Resources-based transactions have driven terminology updates in TEFCA standards of practice, Barber noted.
The draft TEFCA updates were released for public comment in January and the comment period closed in February. Micky Tripathi, ONC national coordinator, told HealthcareITNews in January that the arrival for TEFCA 2.0 would come early in ONC’s interoperability 2024 roadmap.
To enable FHIR exchange, the RCE requires identity proofing on two levels, Coleman noted.
“They have to use an app that has a contract and a working relationship with the credential service provider so that the appropriate level of security can be applied to those transactions as they then query for their health information through the TEFCA network and it gets responded to,” he said.
Further, for individual access service providers that may not be a HIPAA-covered entity, such as a business associate, “we wanted to make sure that the individually identifiable information that an individual access service provider organization stores, maintains and uses in that role is encrypted both at rest and transit.”
Incident reporting protocols
Coleman said that for incident reporting, it’s going to be critical for these entities to know if they have to follow the TEFCA security incident reporting protocol as well as HIPAA incident reporting protocols that they have in place, “or if they just follow, for example, the HIPAA incident reporting protocols.”
There are four exclusions modeled “in a similar fashion” to the HIPAA security rules – “Solutions that exist, not intended to replace them in any way,” he said.
“All QHINs have to abide by the HIPAA security rule, as do participants and sub-participants, even if they’re not a HIPAA entity,” he said, and there are additional requirements for QHIN cybersecurity coverage that must be certified by an independent third party.
HITRUST certification, for example, is “extremely comprehensive, time-consuming and very thorough,” particularly in certification maintenance requirements.
“It is no small accomplishment,” said Coleman.
QHINs “have to actively move forward on anything that is on their corrective action plan or plan of action and milestones, and they have to be addressing their identified weaknesses,” he said.
They are also obligated to share that information with participants and sub-participants, “so that collectively, the tech ecosystem can start really raising the floor on security best practices and implementing those security best practices.”
For a non-HIPAA-covered entity, “it’s all individually identifiable information that they maintain, not just TEFCA information,” said Coleman.
“Because they don’t have OCR looking over their shoulders…we want to make sure that they’re doing the right thing and encrypting their healthcare information at risk and transit.”
When a participant who is affected by a TEFCA security incident makes their required report of that incident to their QHIN, “the QHIN would have an obligation to report that to the RCE, and to other QHINs that are impacted by the breach or by the incident,” Coleman explained.
Additionally, affected entities would have to report down, notifying their participants and sub-participants. These TEFCA flow-down requirements ensure that “we get good communication flowing – in a timely manner – so that those that need to know, get notified as soon as possible,” he said.
TEFCA incident, HIPAA incident or both?
While they are still considered works in progress, Coleman shared Sequoia Project resources for identifying security incident types for non-HIPAA-covered entities.
If an incident affected individually identifiable information and the information was not encrypted, “then it’s automatically a TEFCA security incident,” he said.
“Not only is there a TEFCA security incident, but they’re in violation of their terms of participation within TEFCA because they failed to encrypt in transit and at rest,” he said. “That’s a big no-no.”
Meanwhile, if individual identifier information was encrypted, it might still be a TEFCA security incident, he said.
It’s when an incident affects any healthcare data, and that data had been incorporated into a system like electronic health records, “according to the definitions, it’s no longer TEFCA information,” Coleman clarified. “Now it’s HIPAA information, right?”
He then discussed how an incident could be a TEFCA security incident – even when it does not involve TEFCA information.
“If it adversely affects that organization’s ability to participate in the TEFCA exchange, if they’re no longer able to respond to queries – even though nothing was disclosed under the definition of TEFCA information – it’s still affecting their ability to participate.”
There is a whole “purple decision tree” for that protocol, which walks users through if the incident meets one of the TEFCA exceptions, such as when a doctor sends information to the wrong doctor.
“They’re both authorized to receive healthcare information,” Coleman said. When the receiving provider does nothing further with the patient’s information and they clear it up, it’s not a TEFCA incident.
“However, if it doesn’t meet one of these exceptions and it also falls into the threshold of other security, other reportable incidents, then it is something that we would want to know about,” he said. “So that becomes a TEFCA security incident, as well as a HIPAA security incident,” where duplicative notification to affected individual patients would not be required.
Andrea Fox is senior editor of Healthcare IT News.
Email: afox@himss.org
Healthcare IT News is a HIMSS Media publication.