Digital Health Apps & SaMD: Incorporating Privacy In Design & Development

By John Giantsidis, president, CyberActa, Inc.

Technologies like artificial intelligence (AI) and digital health have made a positive impact in expanding access to healthcare and there are software applications, whether downloadable, native, or web-based, that can do just that. Some of those apps may be considered medical devices (SaMD) and some may be considered clinical decision support (CDS) software, which provides clinicians, staff, patients, or other individuals with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and healthcare. The International Medical Device Regulators Forum (IMDRF) has defined SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device,” and the FDA is taking a risk-based policy stance on regulation of CDS software. CDS encompasses a variety of tools to enhance decision-making in the clinical workflow. These tools include computerized alerts and reminders to care providers and patients; clinical guidelines; condition-specific order sets; focused patient data reports and summaries; documentation templates; diagnostic support, and contextually relevant reference information, among other tools.

Irrespective of the categorization, digital health apps gather data, analyze and process such data, and provide some type of information for the user of the app; it could take an immediate or near-term action to drive or to inform clinical management. Some of the apps are regulated by the FDA and other regulatory bodies, and some are not. But all have a common expectation: privacy.

In Europe, under the General Data Protection Regulation (GDPR), the following principles are to be adhered to, at a minimum, when health data is analyzed and processed:

• Principle of purpose: Before any health data is collected or used, the app must inform the individuals concerned precisely what the data will be used for.
• Principle of data relevance: Only data that is strictly necessary for achieving the objective may be collected. This is the principle of minimizing collection. Digital health apps must not collect more data than they need.
• Principle of limited-duration data storage, also known as the right to be forgotten: Once the objective behind collecting the data is achieved, there is no longer any reason to store them, and they must be deleted. The duration of storage must be defined in advance, taking into account any obligations to keep certain data.
• Principle of data security and confidentiality: Data controllers and processors must take all measures necessary to guarantee that data they collect is secure and confidential; in other words, they must ensure that only authorized people access them.
• Principle of respecting people’s rights: Data about people may only be collected on the essential condition that they have been informed of this operation. People also have certain rights that can be exercised with the organization that holds their data: the right to access these data; the right to correct them; the right to oppose their use; the right to be forgotten (have personal data deleted); the right to data portability, allowing individuals to easily send their data to another data controller; and the right to be informed if their data is breached, inappropriately disclosed or accessed. .

In the U.S., the Privacy Rule created under The Health Insurance Portability and Accountability Act of 1996 (HIPAA) was developed to increase consumer confidence in privacy by requiring that the entities involved in healthcare guard against misuse of information and limit the sharing of such information. HIPAA applicability rests on a single question: Does the app store or transmit protected health information? If it is individually identifiable and consists of data regarding an individual’s health, then the answer is yes, it must be HIPAA compliant.

So, how do we go about designing, building, and commercializing SaMDs that incorporate the principles of privacy? The concept is not new; it was developed by the Commissioner of Ontario Data Protection, Ann Cavoukian, in the ‘90s, and it is very much current today. Since most SaMDs perform computation on data input and provide data output to a user to inform clinical management, drive clinical management, or in the diagnosis or treatment of the patient, we concentrate on the data to launch SaMD Privacy by Design, which involves establishing strategies that incorporate privacy protection throughout the life cycle of a SaMD. Designing in privacy within a SaMD creates essential privacy safeguards that would prevent the retrospective and costly privacy features being added on and saves money on managing, controlling, and storing data.

Integrating privacy requirements in the design of a SaMD is not a simple task. Privacy is generally not the primary requirement of a SaMD, and it may even come into conflict with other (functional or non-functional) requirements. It is therefore of paramount importance to define precisely the goals of a Privacy by Design process. These goals should form the starting point of the process itself and the basis of its evaluation.

The seven original principles of Privacy by Design – developed for software engineers by the Information and Privacy Commissioner of Ontario, Canada – suggest the path forward:

• Proactive, not reactive: Anticipate and ascertain root causes of issues and remediate at the source.
• Privacy as the default setting: Ensure privacy remains intact even if a user does nothing.
• Privacy embedded into design: Embed privacy into all systems and business practices.
• Full functionality: Positive-sum, not zero-sum, allows for balancing conflicting needs without sacrificing privacy.
• End-to-end security: Consider privacy throughout the entire application life cycle.
• Visibility and transparency: Ensure clarity for both providers and users.
• Respect for user privacy: Keep it user-centric by putting the interests of those who need their privacy protected first.

How do we embed privacy in SaMDs?

• Specify the privacy properties and functionalities that must be fulfilled by the SaMD such that their design and implementation are possible (privacy requirements definition);
• Design the architecture and implement system elements that cover the defined privacy requirements (privacy design and development); and
• Confirm that the defined privacy requirements have been correctly implemented and fulfill the expectations and needs of the stakeholders (privacy verification and validation).

And utilize the following eight privacy design strategies:

	Strategy	Description
1	Minimize	The amount of data collected should be restricted to the minimal amount possible (data minimization).
2	Hide	Data and their interrelations should be hidden from plain view.
3	Separate	Data should be processed in a distributed fashion, in separate compartments whenever possible.
4	Aggregate	Data should be processed at the highest level of aggregation and with the least possible detail in which it is (still) useful.
5	Inform	Data subjects should be adequately informed whenever personal data is processed (transparency).
6	Control	Data subjects should be provided control over the processing of their data.
7	Enforce	A privacy policy compatible with legal requirements should be in place and enforced.
8	Demonstrate	SaMD must be able to demonstrate compliance with privacy policies in force and any applicable legal requirements.

 

Minimize

The goal is to collect and process the least amount of data possible, thus averting the processing of unnecessary data and limiting possible impacts on privacy. This may be achieved by collecting data from fewer subjects (reducing the population size) or less data from subjects (reducing the volume of collected information), for which the following tactics may be used:

• Select: Choose only the sample of relevant individuals and the attributes required, with a conservative approach when establishing the selection criteria and processing only the data that satisfy the selection criteria (white list).
• Exclude: Exclude beforehand subjects and attributes that are irrelevant to the processing (black list). In this case, an open attitude must be adopted, excluding as much information as possible unless its inclusion can be justified as being necessary for the intended goal (reverse of select).
• Strip: Partially eliminate personal data as soon as they cease to be necessary, which requires establishing beforehand the storage period for each item of the collected data and establishing automatic deleting mechanisms when said period is over. In case the data are part of a record that has more information than is necessary, the values of the unnecessary fields can be modified to a prefixed default value.
• Destroy: Completely delete personal data as soon as they cease to be relevant, ensuring that it is impossible to recover both the data and any backup copies.

Hide

The “Hide” strategy focuses on limiting data observability by establishing necessary means to guarantee the protection of confidentiality and unlinkability. The following tactics are used to implement this strategy:

• Restrict: Restrict access to personal data by setting limits through an access control policy that implements a “need to know" principle both in space (details and type of data accessed) and in time (processing stages).
• Obfuscate: Make personal data unintelligible to those who are not authorized to see it, using encryption techniques and hashing, both for storage operations as well as information transmission.
• Dissociate: Eliminate the links between data sets that should be kept independent, as well as the identification attributes of data records to avert correlations between them, with special attention to metadata.
• Mix: Group together information on various subjects using generalization and suppression techniques to avoid correlations.

Separate

The goal of this strategy is to avoid or at least minimize the risk that while processing within one entity, different personal data of the same individual that are used in independent processes can be combined to create a complete profile of the data subject. For this, it is necessary to maintain independent processing contexts that make it difficult to correlate data sets that should be unlinked. The following tactics help to implement a separation strategy:

• Isolate: Collect and store personal data in different databases or applications that are independent, either logically or are executed on different physical systems, and adopt additional measures to guarantee unlinkability, such as the programmed deletion of database indexes.
• Distribute: Spread out the collection and processing of different subsets of personal data corresponding to different types of processing over management and handling units that are physically independent within the SaMD and use different systems and applications to implement decentralized and distributed architectures that process the information locally whenever possible, instead of using centralized solutions with unified access that may depend on a single control unit.

Aggregate

Here, we limit the details of the processed personal data as much as possible. While the “Minimize” strategy guides the selection of the data to be collected, this strategy focuses on the degree of detail in which the data are processed and on their aggregation by using three tactics:

• Summarize: Generalize the values of the attributes using value ranges or intervals, instead of a concrete field value.
• Group: Aggregate information from a group of records into categories instead of using the detailed information on each of the subjects that belong to the group by using average or general values.
• Perturb: Use approximate values or modify the real data using some type of random noise instead of employing the exact value of the personal data.

It is necessary to study how the level of detail of the entered data affects the result and what degree of precision is necessary for effective processing. Especially, the passage of time after the data were collected may affect their relevance, which is why it is useful to periodically review the stored information and apply these strategies.

Inform

We seek to make data subjects fully aware of the processing of their data in a timely manner. Transparency about this information is a basic requirement of privacy as it allows data subjects to make informed decisions on the processing and, accordingly, provide free, specific, informed, and unambiguous consent. Any modification in processing regarding previously provided information must be communicated, including possible security breaches. This strategy can be achieved with the following tactics:

• Supply: Inform data subjects what personal data is processed, how it is processed, and why, by identifying the motive and goal. Details on data storage periods must be provided, as well as on the sharing of this data with third parties. Indicate who can be contacted by the data subjects and how to ask questions about their privacy as well as regarding personal data protection.
• Explain: Provide information on data processing in a concise, transparent, intelligible, and easily accessible fashion using clear and simple language. To avoid dense, complex, and unwieldy information policies, it is worth adopting a layered approach that first provides basic information at the time of collection and within the same data collection medium and then makes additional detailed information available at a second level.
• Notify: Inform data subjects of the processing when the data is not derived directly from them. Subjects must also be informed if their data is going to be transferred to third parties. Mechanisms to notify subjects of security breaches that may have happened and may pose a serious risk must also be implemented, using clear and simple language to describe the nature of the breach.

Control

The “Control” strategy is closely linked to the “Inform” strategy, and we want to provide subjects with control over the collection, processing, use, and transfer of their data by implementing mechanisms that allow them the means to access, rectify, erase, object to, port, and restrict their data and its processing, as well as the right to give and withdraw consent or modify privacy options in applications and services. The following tactics can be used:

• Consent: Acquire the consent of data subjects, which must be given unambiguously, by demonstrating either a clear affirmative action that must be explicit in certain situations, such as the processing of sensitive data, the adoption of certain automated decisions, or in international transfers. Also, the subject must be able to withdraw their consent at any time, by guaranteed mechanisms and procedures that make it as easy to withdraw consent as it is to give it.
• Alert: Provide real-time notification to the user when personal data is being collected.
• Choose: Provide granular functionality of the SaMD, especially when it comes to basic functionality, without it being contingent on the user’s consent to process personal data that is not required for execution.
• Update: Implement a mechanism that makes it easy for users to – or even lets them directly – make revisions, updates, and corrections of the provided data for specific processing, so they are accurate and reflect reality.
• Retract: Provide mechanisms for users to withdraw or ask for the deletion of their data provided to a controller for processing.

Enforce

We define a privacy framework and an administrative structure that includes a data protection policy supported by the senior levels of management, as well as the roles and responsibilities that are entrusted with its compliance. Privacy culture must be an essential part of the organization and all members must be participants. The following tactics may help to achieve this:

• Create: Specify a data protection policy that reflects internally the privacy clauses that are communicated to data subjects. The necessary structures must be created and resources assigned to support this policy and ensure that the organization's activities respect and comply with data protection regulations. A training and awareness plan must also be developed for all members that seeks to ensure a committed and responsible attitude as part of accountability.
• Maintain: Support the policy by establishing procedures and implementing the necessary technical and organizational measures.
• Uphold: Ensure the compliance, effectiveness, and efficiency of the privacy policy and the procedures, measures, and controls implemented so they account for all processing activities carried out and for the day-to-day activities of the organization.

A data protection officer plays an essential role in implementing this strategy by assessing the controller and supervising the compliance with data protection regulations within the organization. Implementing privacy management models such as that recently proposed by the ISO/IEC 27701:2019 standard is also effective. It lists the requirements and provides directions for establishing, implementing, maintaining, and continually improving a privacy information management system (PIMS).

Demonstrate

This implements a critical, continuous, and traceable self-analysis of all decisions on data processing and ensures authentic management of personal data within the organization. The following tactics can be used:

• Record: Document each and every decision taken, even when they contradict each other, identifying who took the decision, when, and why.
• Audit: Carry out a systematic, independent, and documented review of the degree of compliance with the data protection policy.
• Report: Document audit results and any other incidents regarding personal data processing operations and make them available to the supervisory authorities whenever required.

Conclusion

The efficient and effective implementation of privacy principles requires that they be an integral part of the SaMD and, to achieve this, they must be considered from the initial stages of concept development and design as part of the group of specifications, both functional and non-functional. Privacy by Design involves the use of a methodological focus centered on risk management that lets us determine privacy requirements employ the appropriate practices, procedures, and tools. A risk analysis will establish the specific objectives of data protection as well as security goals from the perspective of privacy (confidentiality, availability, and integrity). The data-oriented and process-oriented privacy strategies, discussed above, that specify the requirements of each privacy goal must be evaluated. For each strategy, define the protection tactics to implement them effectively. In the SaMD design stage, the selected tactics shall be integrated through available solutions, privacy design patterns that deal with common and reiterated problems. Finally, in the SaMD development stage, these patterns shall be implemented.

Aknowledgment

I would like to thank Louise Buccolo, chief privacy officer of Fresenius Medical Care North America, for reviewing this article and providing some insightful suggestions.

About The Author:

John Giantsidis is the president of CyberActa, Inc, a boutique consultancy empowering medical device, digital health, and pharmaceutical companies in their cybersecurity, privacy, data integrity, risk, SaMD regulatory compliance, and commercialization endeavors. He is also a member of the Florida Bar’s Committee on Technology, Vice Chair of the Current and Emerging Technologies Subcommittee and a Cyber Aux with the U.S. Marine Corps. He holds a Bachelor of Science degree from Clark University, a Juris Doctor from the University of New Hampshire, and a Master of Engineering in Cybersecurity Policy and Compliance from The George Washington University. He can be reached at john.giantsidis@cyberacta.com.