Log in Register

TEFCA Leaves Privacy Questions Unanswered

  • Monday, 08 October 2018 20:26
  • Written by 

LaptopStethoscope2017

Previously, in “TEFCA: A beginning for nationwide interoperability,” we discussed the basics of the Trusted Exchange Framework and Common Agreement (TEFCA), an ambitious plan assembled by The Office of the National Coordinator for Health Information Technology (ONC) to provide an “on-ramp” to nationwide interoperability for healthcare data.

As TEFCA is being implemented (at least initially) as a voluntary framework, its success will depend on convincing healthcare stakeholders that joining TEFCA is worth the investment required to make their systems compatible. While the value proposition for interoperability is clear, decision makers will also have to consider the risks and their potential consequences before deciding whether to participate. Security and privacy concerns will constitute significant factors in any analysis of the risk of joining TEFCA—nobody wants their organization to be the target of the next headline-grabbing data breach and suffer the associated legal and reputational costs.

The ONC’s intention is “to build on the industry’s commitment to increasing trust across networks, while ensuring the privacy, security, and appropriate use of Electronic Health Information when and where it is needed.” For the most part, the technical specifications for privacy and security (laid out in Part B of the draft Trusted Exchange Framework—especially in section 6), are well-considered and robust. However, effective systems are designed with proper incentives for both compliance and verification, not just trust; we cannot safely build an electronic system which relies on trusting users to behave appropriately—it leaves the system vulnerable to bad actors both within and without.

In two regards, TEFCA already begins to embrace this trust-but-verify approach. First, TEFCA’s requirement that TLS/SSL security certificates only be trusted if they appear in a certificate log is commendable; this requirement alone should prevent an entire class of cyberattacks—which continue to plague the internet—from affecting TEFCA.

Second, TEFCA embraces a patient-centered approach to healthcare data. “Principle 5 – Access” specifies that stakeholders should “ensure that individuals have a way to learn how their information is shared and used” and “should provide reasonable opportunities for individuals to review who has accessed their individually identifiable health information or to whom it has been disclosed.” The underlying idea here is intriguing; if patients can see who has accessed their records, they would be able to spot unauthorized access, and they will have more trust and confidence in the system. However, this still falls short. While this admirable sentiment is expressed in the Principles section (Part A), its actual implementation would benefit from being codified more clearly and directly in the legal language of the Minimum Required Terms and Conditions (Part B).

To state the even more obvious concern, what about patients who do not proactively manage their healthcare records (certainly the vast majority)? What protections can they rely on?

For these patients to be fully protected, strong standards for capturing consent and logging access—combined with thorough audits—will be required. Right now, the draft TEFCA does require QHINs to capture consent and maintain an audit log. However, the requirements for capturing consent focus mostly on the patient’s initial consent to join the system, and not enough on how other providers will prove that they have a legitimate need to subsequently access that patient’s data. Standards for performing audits of the logs are not spelled out, but, ultimately, they will be needed.

As stated above, most of the technical specifications for privacy and security—including access control, identity proofing, authentication, data integrity, and compliance with the HIPAA Security Rule—laid out in Part B are well-considered and robust. However, once again, mechanisms for evaluating compliance are lacking. Further, TEFCA requires that “Qualified Health Information Networks” (QHINs) respond to queries from other QHINs, threatening penalties for those that engage in “data blocking.” The balance at stake here is delicate: anti-competitive QHINs could potentially stifle interoperability under the guise of burdensome security audits, while, on the other hand, many security concerns are legitimate. Solving this issue will require a more nuanced approach than just implementing regulations against data blocking; rather, these regulations should be paired with incentives for sharing security knowledge and best practices. The Recognized Coordinating Entity (RCE) could even play a role—potentially coordinating additional system-wide security efforts or penetration testing.

It would behoove the ONC to explore the following unanswered questions in future drafts of TEFCA:

  • What verification mechanisms will be in place to ensure compliance with privacy principles?
  • How will the principle of patient access to their healthcare data be codified and enforced?
  • How often, who, and how will audits of access logs be performed?
  • Will Health Information Networks (HINs) be allowed to evaluate the data security efforts of other participants, or will they be forced to allow other participants to access their data regardless?

TEFCA represents the potential for a new age in American healthcare where data is interoperable and patients receive better, more coordinated care; physicians have instant access to the data they need; and providers reap the savings of a more efficient healthcare system. At the same time, TEFCA represents a massive effort to centralize the storage of and access to some of Americans’ most private and personal information. Security and privacy are paramount because the consequences of a breach can be permanent. This is too important to not get it right the first time.

  • 3503
  • Last modified on Tuesday, 26 September 2023 15:01
Rey Johnson

Rey Johnson works as an HDD Analyst for 3M Health Information Systems where he develops software solutions to meet interoperability needs for health data. He led the technical work on patient consent management which forms a critical portion of 3M’s recent patent application “Shared Revocation Ledger for Data Access Control.” He joined 3M in 2018 at the conclusion of a software engineering internship where he built a modern ETL pipeline to load medical terminologies into the Healthcare Data Dictionary, a FHIR-compatible terminology server.

Rey is anticipating to complete a Masters of Biomedical Informatics at the University of Utah, with an emphasis on data science, by May 2021. He has also started in the Catalyst Fellowship at MIT, an applied research program focused on making a positive impact on healthcare. As an undergraduate student, he studied cryptography and blockchain technology and he holds a Bachelor of Science in Finance. Since learning to code at eight years old, Rey has maintained                                                                                a lifelong interest in applying technology to improve life. His current focus on interoperability in health data reflects his                                                                                commitment to building an accessible, patient-centered healthcare system.