TEFCA: With greater simplification comes greater responsibility in cybersecurity
The Trusted Exchange Framework and Common Agreement, created by the Office of the National Coordinator for Health IT under the 21st Century Cures Act, hold great promise for interoperability and information sharing.
It also has major consequences for privacy and security.
“It is possible that a TEFCA security incident is also a HIPAA security incident, and it is possible that a HIPAA security incident may or may not be a TEFCA security incident,” said Johnathan Coleman, director of Security Risk Solutions and the chief information security officer at the Sequoia Project, TEFCA’s recognized coordinating entity.
At HIMSS24 last month, Coleman, along with Zoe Barber, Sequoia’s policy director, provided an overview of TEFCA’s incident response and incident reporting flows, highlighting areas of development that could trip up non-HIPAA entities.
New flexibility, new safety requirements
Barber said the requirements for securing protected data exchanges under TEFCA will not see significant updates in the upcoming second version of the joint agreement.
“Privacy and security obligations apply to everyone, and they are consistent across the framework,” she said during a brief TEFCA overview before Coleman delved into the nuances of cybersecurity incident reporting at TEFCA.
While Sequoia, as RCE, makes it easier to exchange data by simplifying the way 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 developed the TEFCA interoperability proposal, it has also become easier for lead delegates – a vendor, health information exchange, or other business partner working for primary authorities that provide clinical services and maintain patient data – to exchange and maintain. simplify their connection to the network, Barber explains.
Creating more flexibility for participants means that exchange is not just QHIN-to-QHIN, but interoperability can happen directly between participants via APIs.
“We previously had a pretty strict requirement that you could only participate with one (qualified health information network), but now we’re breaking that open a little bit to allow participation between multiple QHINs — as long as you use a different system,” she said.
Encryption for HIEs, BAs and others
Changes to support broader use of Health Level Seven’s Fast Healthcare Interoperability Resources-based transactions have led to terminology updates in the TEFCA practice standards, 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, shared HealthcareITNews in January that the arrival of TEFCA 2.0 would fall early in ONC’s 2024 Interoperability Roadmap.
To enable FHIR exchange, the RCE requires two levels of identification, Coleman noted.
“They should use an app that has a contract and working relationship with the credential service provider so that the appropriate level of security can be applied to those transactions as they then request and respond to their health information through the TEFCA network,” he said.
Further, for individual access service providers that may not be a HIPAA covered entity, such as a business associate, we wanted to ensure 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 in transit. “
Protocols for reporting incidents
Coleman said that for incident reporting, it is critical that these entities know whether they need to follow the TEFCA security incident reporting protocol, as well as the HIPAA incident reporting protocols they have established, “or whether they simply follow, for example, the HIPAA Incident Reporting Protocols.”
There are four exclusions that are modeled “in a similar manner” to the HIPAA security rules: “Solutions that exist are in no way intended to replace them,” he said.
“All QHINs must adhere to the HIPAA Security Rule, as do participants and sub-participants, even if they are not a HIPAA entity,” he said, and there are additional requirements for QHIN cybersecurity coverage that must be certified by an independent body. third party.
For example, the HITRUST certification is “extremely comprehensive, time-consuming, and very thorough,” especially in terms of certification maintenance requirements.
“It’s no small feat,” Coleman said.
QHINs “must actively progress everything in their corrective action plan or action plan and milestones, and they must address their identified weaknesses,” he said.
They are also required to share that information with participants and sub-participants, “so that the tech ecosystem can collectively begin to really improve security best practices and implement those security best practices.”
For an entity not covered by HIPAA, “it’s all individually identifiable information that they hold, not just TEFCA information,” Coleman said.
“Because they don’t have OCR looking over their shoulders, we want to make sure they do the right thing and encrypt their healthcare information that is at risk and being transferred.”
Where a participant affected by a TEFCA security incident makes the required notification of that incident to its QHIN, “the QHIN would have an obligation to report it to the RCE and to other QHINs affected by the breach or by the incident ,” explained Coleman.
In addition, affected entities would be required to come forward and notify their participants and sub-participants. This TEFCA flow requirements ensuring that “we get good communication – in a timely manner – so that those who need to know are notified as quickly as possible,” he said.
TEFCA incident, HIPAA incident or both?
While still considered a work in progress, Coleman shared the Sequoia Project’s resources for identifying security incident types for non-HIPAA entities.
If an incident affected individually identifiable information and the information was not encrypted, “then it is automatically a TEFCA security incident,” he said.
“Not only is there a TEFCA security incident, but they are also in violation of their terms of participation in TEFCA because they failed to encrypt in transit and at rest,” he said. “That’s a big no-no.”
Meanwhile, if individual identifiers were encrypted, it could still be a TEFCA security incident, he said.
It’s when an incident affects healthcare data, and that data is contained in a system such as electronic health records, “under the definitions, it is no longer TEFCA information,” Coleman clarified. “Now it’s HIPAA information, right?”
He then discussed how an incident could be a TEFCA safety incident – even if no TEFCA information is involved.
“If it negatively impacts that organization’s ability to participate in the TEFCA exchange, if they are no longer able to respond to inquiries – even though nothing has been disclosed under the definition of TEFCA information – does this still impact their ability to participate.”
There’s a whole ‘purple decision tree’ for that protocol, which guides users through it if the incident meets one of the TEFCA exceptions, such as when a doctor sends information to the wrong doctor.
“They are both authorized to receive health care information,” Coleman said. If the receiving provider does nothing further with the patient’s information and cleans it up, it is not a TEFCA incident.
“However, if it does not meet one of these exceptions and it also falls within the threshold of other security and other reportable incidents, then it is something we would want to know about,” he said. “So that becomes a TEFCA security incident, as well as a HIPAA security incident,” where double notification to affected individual patients would not be necessary.
Andrea Fox is editor-in-chief of Healthcare IT News.
Email: afox@himss.org
Healthcare IT News is a HIMSS Media publication.