Privacy by design

Nearly 30 years ago, in 1996, the Health Insurance Portability and Accountability Act (HIPAA) became law and the right to health information privacy in the U.S. was born. Needless to say, there have been a few changes in the healthcare and technology spaces since then. The intrusions on what’s considered private data are beyond what anyone would have believed at the time of passage.

Before we explore the issue of patient data privacy, it’s important to differentiate it from another major data-related issue in the industry – cybersecurity. While the two issues are related – a cyber breach can result in the exposure of critical patient data – cybersecurity has much broader implications, such as interference with hospital operations.

Patient data privacy includes securing access to the data and also ensuring prior to any use of the patient data, all identifying information has been appropriately anonymized. Additionally, any use of this data must be proscribed by the related data rights associated with the data. Tracking data provenance in terms of specific use, geography of use and, potentially, geography of use of algorithms created through use of the data all have taken on new importance.

The emergence of connected systems is stressing HIPAA compliance. Controlling the perfusion of data has become increasingly complex for any data repository. The recent explosion of artificial intelligence (AI)-based development and evolving business strategies to monetize personal data has rung global alarm bells.

The issue of personal and patient privacy has driven the problem beyond the Health IT industry right into the heart of medical devices. The prevalence of cloud-based data repositories, which have also become the norm throughout the past several years, has direct bearing on the challenge, as the evolution moves the privacy responsibility from the product users directly to the medical device manufacturer.

Recent changes

As if this backdrop were not complex enough for the typical device manufacturer, the explosion of AI development taking advantage of the plethora of data has driven a spasm of global regulations. The European standard, General Data Protection Regulation (GDPR), was completed in 2016, going into effect in 2018. The implications of this regulation are still slowly permeating through on-line data systems. Early reticence in the U.S. to adopt or even acquiesce to GDPR has slowly given way with increasing compliance on web-based systems seen on a regular basis.

To add to the difficulty, according to the International Association of Privacy Professionals [US State Privacy Legislation Tracker (https://iapp.org)], during the past four years, 19 states have passed variations of personal data privacy laws, with eight already in effect and another eight in effect within 12 months. Sixteen additional states have bills in various stages of development. While many, if not most, of the basic tenets of these laws address the same issues, the approaches differ quite significantly. To be sure, none of the U.S. laws are anywhere near as encompassing (or punishing) as GDPR, but each has their own spin on what’s in scope and the jurisdiction of the laws. This creates a worst-case scenario for medical device manufacturers.

The unwillingness, or inability, of Congress to generate a unified set of privacy standards – more or less in line with GDPR – has created a hodge-podge of new laws, mostly quite different than GDPR, but in differing ways.

One area of broad agreement, however, is in the requirement for companies accumulating, storing, analyzing, and/or selling private user data to develop a Data Privacy Impact Assessment (DPIA). Unfortunately, the scope of the DPIA does vary significantly from jurisdiction to jurisdiction.

Another area of general agreement is the requirement to report data breaches. Unfortunately, the definition of what qualifies as a reportable breach varies state-by-state generating real complexity in one of the most public aspects of data privacy compliance. Similarly, the definition of consent also varies across implementations, with some requiring opt in and others allowing for opt out. This difference is most pertinent in the area of secondary data rights, i.e., the right to sell user data. While GDPR and many U.S. states require specific permission to resell user data, in several states this use is allowed unless the user specifically opts out.

On the other hand, an area of stark contrast is the Right to be Forgotten, which was a contentious cornerstone of GDPR. None of the U.S. data laws currently has a strong standard in this regard [Data privacy laws in the United States (updated June 2024) | Didomi], but it’s an area of continued discussion.

Another area of large discrepancy is penalties; purposeful (or simply blissful) violation of GDPR can be very financially painful, with fines running to €20 million. In the U.S., the fines are much lower, typically in the range of $7,500. However, incidence multipliers of the laws ensure that intentional violation can be onerous.

As a note, it’s important to point out that most states don’t differentiate between Patient Health Information (PHI) and other user data. In these cases, irrespective of the laws in question, PHI is covered by the requirements of HIPAA.

Impact on system design & implementation

Clearly all of this has a direct impact on the product system design process. Creating (and maintaining) a unified view of these conflicting regulations is only the starting point. Making a determination of how to comply is more complex.

It’s only a matter of time until each state has passed its own data privacy laws, so planning for how to manage this will pay off over time. Since GDPR is currently the gold standard for data privacy protection, and U.S. laws will almost inevitably evolve toward that standard, it may make sense to use GDPR as the tiebreaker in case of conflict between U.S. standards. By meeting GDPR, your product will meet current European standards and will provide confidence the product meets any U.S. privacy law as well.

Some specific design challenges will evolve – especially around AI algorithm development using PHI. The Right to be Forgotten has a direct impact on de-identified data. Patients have the right to ask that their data not be used in algorithm development. If the request is made retrospectively, the difficulty in identifying which data rights have been rescinded will be exceedingly complex.

The requirement to track which data set is used in which algorithm development must be extended to ensure tracking of internal engineering data sets as well. Avoiding the creation of unmanaged copies of data containing PHI will become a core design requirement.

User access to data will also be required. Several very complex functions must be added to any medical system accruing PHI. To name just a few, easy to use mechanisms to excise or edit incorrect data, clearly presented schedules that indicate what data is to be collected and what rights the patient grants to each class, and the ability to fully delete specific PHI – including from data backups.

Conclusion

To meet the onslaught of data privacy laws, it’s clear device manufacturers will certainly need to strengthen their data management knowledge and development practices. But there may be a silver lining in all this chaos. Stronger data privacy regulations may well help organizations in the long run. Stronger control over PHI privacy goes together with minimizing the risk of security breaches, class action lawsuits, and lost business due to operations disruption and, of course, avoiding the reputational damage going along with the publicity of each of these incursions.

Full Spectrum
http://www.fullspectrumsoftware.com

About the author: Adam Hesse is CEO of Full Spectrum and can be reached at ahesse@fullspectrumsoftware.com.