Requirements on Privacy in Clinical Trials

Been thinking a lot recently of privacy in regard to clinical trials. As you do, I started with gathering some requirements together. Here is what I have:

Brief Standard Identifier	Description of Industry Standard	Regulation/Guidance/ Source
Subject Identification in Data Systems	The business has SOPs to ensure that data collection instruments and databases utilize an unambiguous subject identification code that allows identification and linkage of all the data reported for each subject. Data tools and systems do not contain personally identifiable information, except the unique subject identification code to link data across the study.	GCDMP – Data Privacy; ICH 5.5.5
Patient Diaries Review	The business has and utilizes SOPs to ensure that the Investigator site personnel review paper-based patient diaries prior to sending the diaries to Data Management to confirm that no personal identification information is present.	MHRA 8.2.7
Confidentiality of Subject Records	The business utilizes formal procedures and practices to ensure that the confidentiality of records that could identify subjects is protected in accordance with the applicable regulatory requirement(s).	ICH 2.11
Informed Consent Prior to Data Collection	The business has a process to establish expectations with the site and confirm that informed consent is obtained from every subject prior to clinical trial participation and prior to processing clinical data. The process should provide direction for withdrawal and revocation of consents.	ICH 2.9, 4.8.8, 6.5.3 21 CFR 50
Privacy and Personal Data Protection Policy	The business has a Privacy and Personal Data Protection Policy and a Chief Privacy Officer/ Data Protection Officer to ensure compliance with EU GDPR and other country, local, and Independent Ethics Committee-required privacy, and data protection practices.	US HIPAA EU 1995 Data Protection Directive 1995/45/EC EU GDPR 2016/679 Japan 2016 Act on the Protection of Personal Information- US Privacy Act
Privacy and Personal Data Protection Documented Practices	The business has documented procedures, standards, documentation requirements, and responsibilities for defining and ensuring confidentiality, protection, and security of personal data (including but not limited to employee, client, investigator, and patient data) and applying Privacy by Design requirements into procedures that include: definitions of personally-identifying information descriptions of personal information collected the purposes for which it is collected the lawful basis (in the EU) for its collection/use the types of persons to whom it will be released the countries to which it may be transferred privacy and security safeguards the rights of individuals with respect to their personal information compliance monitoring	US HIPAA EU Data Protection Directive 1995/45/EC EU GDPR 2016/679 Japan’s Law Concerning the Protection of Personal Information – 2005; Japan Act on the Protection of Personal Information- 2016
	The business has documented procedures, standards, documentation requirements, and responsibilities for conducting Privacy Impact Assessments, including when they are implemented, or documentation regarding why they are not applicable.	EU Data Protection Directive 1995/45/EC EU GDPR 2016/679
Personal Data Processing, De-identification and Pseudonymization	The business has documented procedures, standards, documentation requirements, and responsibilities for enhancing privacy and protecting personal data, both at the time of determining the means for processing data and at the time of actual processing, by adherence to the data minimization principle (i.e., ensuring that only data needed for a clinical trial are collected from clinical trial subjects’ records), encryption at rest and during transit, de-identification and pseudonymization. Where pseudonymization is deployed, the business has appropriate technical (e.g., encryption, hashing, or tokenization) and organizational (e.g., agreements, policies, privacy by design) measures in place to separate pseudonymous data from identification keys.	EU GDPR 2016/679
Personal Data Capture and Data Flow Procedures	The business has written procedures for documenting the data flow for the organization/for individual projects. The data flow comprises what personal data the organization holds, where it came from, and with whom they share it.	EU Data Protection Directive 1995/45/EC EU GDPR 2016/679
Individual Privacy Notice or Consent	Ensuring that individuals are informed of all required privacy provisions in Privacy Notice or Consent, including: their right to confirm if and how their data are processed, including the right to object to (or limit use of) processing and the right of erasure; plans for data retention; the right to receive a copy of their personal data and to have them transmitted to other organizations; and the complaint process.	US HIPAA EU Data Protection Directive 1995/45/EC EU GDPR 2016/679
Support for Personal Data Subject Requests	Receiving, processing, and responding to Personal Data Subject Requests submitted by Data Subjects per their rights under GDPR, and/or assisting the Client to fulfill Client’s obligation to do so: right of access right to rectification restriction of processing erasure (“right to be forgotten”)data portability objection to the processing, or the right not to be subject to automated individual decision making	EU GDPR 2016/679 Directive 1995/45/EC
Privacy and Personal Data Breach Procedures	Detecting, reporting, and investigating personal data breaches, and communicating confirmed data breaches to impacted parties within timelines dictated by applicable regulations (72 hours for regulatory authority reporting) and agreements. Sponsor will be notified of any data breach in association with sponsor projects, including breaches at subcontracted vendors, according to pre-defined timing.	EU Data Protection Directive 1995/45/EC EU GDPR 2016/679
Privacy and Personal Data Protection Training	The business trains all individuals who have access to personal data on the policy and practices that ensure confidentiality, protection, and security of personal data.	EU Data Protection Directive 1995/45/EC EU GDPR 2016/679

Documents and the Heart of the Quality System

A month back on LinkedIn I complained about a professional society pushing the idea of a document-free quality management system. This has got to be one of my favorite pet peeves that come from Industry 4.0 proponents, and it demonstrates a fundamental failure to understand core concepts. And frankly one of the reasons why many Industry/Quality/Pharma 4.0 initiatives truly fail to deliver. Unfortunately, I didn’t follow through with my idea of proposing a session to that conference, so instead here are my thoughts.

Fundamentally, documents are the lifeblood of an organization. But paper is not. This is where folks get confused. But fundamentally, this confusion is also limiting us.

Let’s go back to basics, which I covered in my 2018 post on document management.

When talking about documents, we really should talk about function and not just by name or type. This allows us to think more broadly about our documents and how they function as the lifeblood.

There are three types of documents:

Functional Documents provide instructions so people can perform tasks and make decisions safely effectively, compliantly, and consistently. This usually includes things like procedures, process instructions, protocols, methods, and specifications. Many of these need some sort of training decision. Functional documents should involve a process to ensure they are up-to-date, especially in relation to current practices and relevant standards (periodic review)
Records provide evidence that actions were taken, and decisions were made in keeping with procedures. This includes batch manufacturing records, logbooks and laboratory data sheets and notebooks. Records are a popular target for electronic alternatives.
Reports provide specific information on a particular topic on a formal, standardized way. Reports may include data summaries, findings, and actions to be taken.

The beating heart of our quality system brings us from functional to record to reports in a cycle of continuous improvement.

Functional documents are how we realize requirements, that is the needs and expectations of our organization. There are multiple ways to serve up the functional documents, the big three being paper, paper-on-glass, and some sort of execution system. That last, an execution system, united function with record, which is a big chunk of the promise of an execution system.

The maturation mind is to go from mostly paper execution, to paper-on-glass, to end-to-end integration and execution to drive up reliability and drive out error. But at the heart, we still have functional documents, records, and reports. Paper goes, but the document is there.

So how is this failing us?

Any process is a way to realize a set of requirements. Those requirements come from external (regulations, standards, etc) and internal (efficiency, business needs) sources. We then meet those requirements through People, Procedure, Principles, and Technology. They are interlinked and strive to deliver efficiency, effectiveness, and excellence.

So this failure to understand documents means we think we can solve this through a single technology application. an eQMS will solve problems in quality events, a LIMS for the lab, an MES for manufacturing. Each of these is a lever for change but alone cannot drive the results we want.

Because of the limitations of this thought process we get systems designed for yesterday’s problems, instead of thinking through towards tomorrow.

We get documentation systems that think of functional documents pretty much the same way we thought of them 30 years ago, as discrete things. These discrete things then interact through a gap with our electronic systems. There is little traceability, which complicates change control and makes it difficult to train experts. The funny thing, is we have the pieces, but because of the limitations of our technology we aren’t leveraging them.

The v-model approach should be leveraged in a risk-based manner to the design of our full system, and not just our technical aspects.

System feasibility matches policy and governance, user requirements allow us to trace to what elements are people, procedure, principles, and/or technology. Everything then stems from there.

Level of Effort for Planning

In the post “Design Lifecycle within PDCA – Planning” I laid out a design thinking approach to planning a change.

Like most activities, the level of effort is commensurate with the level of risk. Above I provide some different activities that can happen based on the risk inherent in the process and problem being evaluated.

This is a great reason why Living Risk Assessments are so critical to an organization.

Design Lifecycle within PDCA – Planning

In the post “Review of Process/Procedure” I mentioned how the document draft and review cycle can be seen as an iterative design cycle. In this post I want to expand on the design lifecycle as a fundamental expression of PDCA that sits at the heart of all we do.

PDCA, a refresher

PDCA (and it’s variants) are a pretty tried and true model for process improvement. In the PDCA model a plan is structured in four steps: P (plan) D (do) C (check) A (act). The intention is create a structured cycle that allows the process to flow in accordance with the objectives to be achieved (P), execute what was planned (D), check whether the objectives were achieved with emphasis on the verification of what went right and what went wrong (C) and identify factors of success or failure to feed a new process of planning (A).

Conceptually, the organization will be a fast turning wheel of endlessly learning from mistakes and seeking to maximize processes in order to remain forever in pursuit of strategic objectives, endlessly searching for the maximum efficiency and effectiveness of the system.

PDCA cycle driving continuous improvement

Design Lifecycle

This design lifecycle just takes the PDCA spiral and spreads it across time. At the same time it breaks down a standard set of activities and recognizes the stage gates from moving between startup (or experiment) and continuous improvement.

Identifying the Problem (Plan)

At it’s heart problem-solving requires understanding a set of requirements and building for success.

I always go back to the IEEE definition of “A requirement is a condition or capability needed by a user to solve a problem or achieve an objective; a condition or capability that must be met or possessed by a system or system component to satisfy a contract ,standard, specification , or other formally imposed document; a document representation of condition or capability “

A requirement can be explicitly stated, implicit, inherited or derived from other requirements.

The first place to look for requirements is the organization itself.

Understanding the needs of the organization

The cultural needs of the organization drives the whole problem-solving and requirement gathering activity and it starts by being clear on Strategy and understanding the goals and objectives and how these goals percolate to the different business processes that we are improving. This gives a good starting point to focus on what opportunities to be explored and what problems to be solved.

It is not uncommon in the problem-solving phase that the objectives/needs are not known, so we must work our way through figuring out what the initial need is. Go back to the fundamentals of understanding the business processes “as-is” and review existing regulations, standards, guidelines and other internal sources of requirements followed currently. This is the time to interview stakeholders and go the GEMBA.

We state the problem, and re-frame it. And now we can move on to Requirement Elicitation.

Requirement Elicitation

Requirement Elicitation is the process of probing and facilitating the stakeholders to provide more clarity and granular details pertaining to the (usual) high-level requirement gathered so far. This is a discovery process, exploratory in nature, focusing on finding enough details so that a solution can be envisioned and developed. Elicitation is not an isolated activity, and has been happening throughout the process by all the discussion, interaction, analysis, verification and validation up to now.

You should be engaging with knowledge management throughout the cycle, but ensure there is specific engagement here.

It is a progressive process where the requirement clarity ushers in increments and may need multiple rounds of probing/discussions. As the new details are uncovered the requirements are further elaborated and detailed. There are a whole toolbox of elicitation techniques and like any engagement it is important to properly prepare.

Requirement Analysis

Requirement Analysis pertains to extracting the requirement out of the heaps of information acquired from various stakeholders and communicated and turned into documentation in a form that is easily understood by the stakeholders, including the project team. Here we are engaging in requirement refinement, modification, clarification, validation & finalization and engaging in extensive communication.

A requirement can be classified as:

External or Internal Obligation
Business requirement: The organizational need
Stakeholder requirement
Functional Requirement
Non-Functional Requirement
Transitioning requirement

We build for traceability here, so as we build and test solutions we can always trace back to the requirements.

Design the Solution

Building for the solution includes change management. Any solution focuses both on the technical, the organization and the people.

Ensure you leverage risk management.

The Place of Empathy

In this design process, we address and use empathy to acquire insight into users’ (stakeholders) needs and inform the design process and create a relevant solution. Using an approach informed by cognitive empathy, we apply different methods to build up that competence and insight, enabling us to prioritize the needs of the users and make the results of the process more desirable.

Psychological safety, reflexivity and sense-making inform our work.

Prepare for Startup

By engaging in Design Thinking we are ready for Startup. Moving through the three steps of:

Problem-Solving
Requirement Elicitation
Design Solution

We have created a plan to execute against. Startup, which can often be Experimentation, is it’s own, future, post.