Managing CAPAs in Jira: key questions answered

Managing CAPAs with JIRA: answering key questions

Putting aside software development processes, managing CAPAs processes is definitely the most frequent QMS process which companies choose to implement in JIRA. This is likely due to:

1. The CAPA being a key process in virtually any of the QMS standards applicable across pharma, biotech, medical devices, the food industry, and others. 
2. Even in the most simplistic implementation, CAPA management is quite a complex process which:
   •  Spans over a significant amount of time. (Typically between few days to months.)
   •  Involves multiple steps.
   • Requires a coordinated team-effort.
3. Companies invest many resources in performing CAPAs. Thus they’re keen to know how these resources are invested and in ensuring that their CAPA process itself is efficient.

I gathered here few of the questions which are frequently asked by those considering managing CAPAs processing in JIRA.

Note: The answers provided relate to a JIRA installation using some extensions available from the Atlassian marketplace with configurations and customization, and relate to a JIRA Server installation.

Can we link between our CAPAs and other processes? (i.e. Nonconformities/Customer issues)

CAPAs are triggered from other processes, such as customer complaints or audit nonconformities. A CAPA very often also triggers other processes – for example, a CAPA may trigger Engineering Change Request (ECR) or a training activity. Linking between CAPAs and the other processes helps provide the full context of the CAPA. This avoids the need to duplicate information and efforts, and enhances coherence. Check out our article on streamlining the CAPA process by triaging customer issues. Linking can also be used to enforce certain processing rules. For example, we can avoid the CAPA to be declared as “implemented” before any related dependent activities are completed.

Yes, such links may be established and registered as part of the CAPA information. The exact function of these links depend on where the other processes are managed:

1. If your linked processes, such as customer issues and training, are managed within the same or different JIRA instances, the link can be customized to implement and enforce business logic. The processing of the two linked issues will mutually depend on each other. For example, a Nonconformity cannot be closed until the related CAPA has not been validated. It’s also possible to configure what information on the linked issue will be seen in the CAPA and to adopt the link name to whatever local terms you use.
2. If your linked process resides on an external system which is not a JIRA instance. Then it may still be possible to implement a link between the two issues. JIRA supports a large variety of interface options. In many cases, the exact function of the link will depend on the technical interfaces available on that other system.
3. If the other issue is managed in a way that does not support electronic connection, then the typical solution would be to include in the CAPA a data field with the unique ID or any textual description of that other issue or form. 

Figure 1. When creating a CAPA, you can directly select a customer issue that triggered the CAPA. The source issue and the CAPA will be linked.

Figure 2. CAPA issue shows links to other issues.

Can we attach files to the CAPA?

Yes, JIRA allows attaching multiple files to each issue. These files may be of any type, and may be added to the issue at any stage.

Figure 3. A CAPA issue with three attachments.

When managing CAPAs, can we use metrics to measure our performance?

An organization may measure CAPA performance using many indicators (KPIs):

1. The time between the opening of a CAPA and when it completed validation.
2. The percentage of CAPA which is found to be effective.
3. The cases where a similar issue is being reported after a CAPA has once already been processed.
4. The amount of work hours associated directly with the CAPA.

All the above and many more options can be accommodated to. Once a KPI is defined a corresponding report may be created. In some cases, if the raw data for the KPI is not yet collected, it has to be added so that the subsequent report can be generated. The KPI report can then be displayed within JIRA as either a tabular or graphic chart, such as a pie chart. Alternatively, the data may be exported from JIRA to be analyzed in excel or in other statistical packages.

Can the system notify us when a CAPA is updated?

JIRA provides a rich set of possibilities to keep up to date with the various activities. You can tune the notification methods that suit you, out of the following options:

1. Email notifications for every update.
2. Email digests: many users find this the most useful type of notification, because it packages all the updates into a single email.  Examples are: a daily digest of all CAPAs which were updated this week. A weekly digest of all new CAPAs. A weekly digest of all CAPAs for whom the delay to validation is longer than one month.
3. The JIRA dashboard: The JIRA dashboard is one web page which displays a concentration of stats and reports relating to your CAPAs. The dashboard is live in two ways. Firstly, it reflects the up to date information and refreshes in regular intervals. Secondly, it links to the specific raw data from which it is derived. This means that in one click you can investigate or act on any information you see in the dashboard. People who work regularly with JIRA keep the Dashboard open in their browser continuously. Or they have the dashboard display on a big monitor in their open space office. 

Figure 4. A JIRA Dashboard displays various CAPA statistical and follow-up information

Can the system indicate when a CAPA effectiveness check is due?

One of the sticky areas in implementing an effective CAPA system is to follow-up CAPAs. Regulations oblige us to make an effectiveness check to the CAPA sometime appropriate in the future. Generally speaking, this future timing depends mainly on how long it takes to accumulate enough events where our corrective or preventive action can be relevant. That way it can be demonstrated that it effectively mitigated the CAPA root cause.

When we implement a CAPA process in JIRA we ensure this follow-up occurs:

1. After the implementation and the initial validation of the CAPA, a date for the effectiveness check is set. This can be done manually, or based on a certain business logic that is defined.
2. The CAPA is then transitioned into a “dormant” waiting status. 
3. When the due date arrives the CAPA is automatically transitioned into an active status “effectiveness check is due.” It then appears in the various Dashboards, reports, and email notifications. That way the assigned staff can act on them.

Can this help us standardize our CAPA process and promote best practices?

Standardization can be built into the process to make it easier for the team.

The following is an example of standardization through checkpoint questions. In this case, the JIRA CAPA issue is designed to include several checkpoint questions:

1. Have non-conforming products been released to the market?
2. Can this issue affect other product lines?
3. Can this issue affect risk management?

By going through those questions, the staff member is forced to consider all the aspects pertaining to an effective analysis of the problem. Once the analysis is complete and the CAPA moves to planning and implementation, those questions may be used to create the required actions. In JIRA, these actions are called subtasks. So, if, during the analysis stage, it was indicated that “this issue may effect other product lines” a subtask to “evaluate possible relevance to other products” is automatically generated. If it was indicated that “this issue may affect risk management” a subtask dedicated to “performing risk-management” is generated. You can find out more about managing the lifecycle of your controlled documents in our article on the topic.

By building the process this way, we ensure that all the complexities and possibilities related to CAPA situations are followed through.

What about FDA CFR 21/Part 11 compliance?

This issue definitely deserves a whole (or even several) posts for itself. You can hear the FDA’s stance on CAPAs straight from the horses’ mouth on their website. But there’s no need to go far. Here, we will just provide the two most important points:

Managing CAPAs with electronic signatures

JIRA has an extension which provides electronic signatures. The plug-in we often use is inTenso’s Electronic Signature plug-in. To electronically sign the process of managing CAPAs, the user has to introduce his user credentials on the JIRA transition screen. This signature is then logged together with the issue.

Audit trail

JIRA has, out of the box, an audit trail for each issue. Creation, modifications and comments on the issue are all logged as part of the issue itself. In an FDA compliant environment, deletion of issues should be restricted by permissions scheme. If needed, issues can always be cancelled. In which case, all their audit information is accessible.

Figure 5. All Modifications of an issue are automatically logged with full details, creating a compliant audit trail.

What about validation?

Some companies opt to create paper copies of the CAPA records, to serve as the master records when managing CAPAs. Two motives can support this approach:

1. This reduces upfront investment in the system because of the elimination of the validation efforts.
2. Some compliance officers still hold that a paper copy has less risk of getting deleted or lost than an electronic record. This shows that paper documents grant the illusion of greater control. These compliance officers have first to be convinced that adequate IT governance solutions are in place.

If your organization is ready to move to a fully electronic system for your regulatory compliance, you will have to develop a validation strategy and implement it. The regulations do require that the system will be validated within your context of use and with all your specific procedures in place. Confluence is terrific tool for engineering your processes, check out our article on the topic. This is an area where we work closely with our customers and supply the support they need to achieve a state of validation, as well as long term plans in regards to system re-validation. 

Can the JIRA implementation of the CAPA process reflect our SOP or Form?

A JIRA issue is created, and then transitions through several stages and closure. “Done” in JIRA language. This is called the issue workflow. Each issue consists of several data fields, like its summary, which effectively functions as the title of the issue. As well as description creation date, etc. JIRA comes out-of-the-box with several workflows and data fields. These mostly target software development activities. However, it comes with a full set of features that make it possible to define an infinite number of other workflows. Like it can follow many business logics, and requires a huge number of data field types. This is the foundation that allows us to define virtually any CAPA process in JIRA.

Figure 6. CAPA workflow in JIRA, and example implementation (A)

Figure 7. CAPA workflow in JIRA, and example implementation (B)

Blog posts in this series:

1. Improving your CAPA SOP with Jira – an action plan
2. How triaging customer issues helps streamline CAPA
3. Compliance, usability and culture in quality management
4. Use Jira to Document Meetings, So You Can Focus on What Matters