Transforming your CAPA SOP with JIRA Core – an action plan

A CAPA process set up in JIRA will be part of your quality management system, so it will be subject to the relevant validation and verification (V&V) procedures. If you don’t yet have a V&V strategy in place for automated processes, it’s a good idea to invest some time in developing one.

Bear in mind that the extent and depth of V&V activities required will depend on the regulatory framework in which you’re operating. For example, if you’re a medical technology company operating within the framework of FDA QSR 820, you will find the applicable rules in Section 70, Article i. These stipulate that the V&V activities for automated processes must cover the intended use of the software in your specific context. This means that you will need to create and execute a test plan to ensure that your CAPA implementation works as it should.

If you rely on software for other aspects of your business, for example if your medical technology incorporates a software element, you may take inspiration from the practices and tools you use there. However, before you consider applying similar methods to your CAPA SOP process, carefully consider the level of risk associated. For example if your device is a heart pacemaker, then obviously a CAPA process in JIRA will carry significantly less patient risk than the software controlling your device, so may need less stringent V&V efforts.

The most straightforward strategy at this point is to map each quality assurance (QA) process to a dedicated project in JIRA Core, and each instance of that process to a particular issue type in JIRA Core. For example:

• CAPAs will be managed within the CAPA management project and each CAPA instance will be a CAPA issue.
• Training activities will be managed within the Training management project and each training activity (ie one person trained on one subject) will be a training activity issue.
• Nonconformities will be managed within the Nonconformities management project and each nonconformity will be a nonconformity issue.

You will then define these new issue types in JIRA Core.

Some procedures require multiple actions to happen in parallel. For example, imagine a pharmaceutical company opens a CAPA due to a series of complaints about medicines arriving at hospitals with damaged packaging. Following an investigation into the root cause, two separate courses of actions are planned: a redesign of the packaging and a change in transportation arrangements. Those should be assigned to two different people and will progress in two parallel timelines. The CAPA cannot be completed before these two actions are completed. This type of process calls for the creation of subtasks, so you would need to define both a CAPA issue type and CAPA subtask issue types.

At this stage it’s also worth identifying which processes are related to each other, because this can provide valuable contextual information. For example, a nonconformity issue may trigger a CAPA issue. This can be indicated in JIRA Core using issue links.

CAPA SOPs are often written using process language which lends itself easily to producing a workflow description. Here are a few hints on how to break your process into distinct statuses:

1. When completing one set of actions is a prerequisite to another set of actions, it’s usually best to break those up into two separate status steps in the workflow. In the case of CAPAs, identifying the root cause should be done before planning the preventive and corrective actions, so those should be separated into two consecutive statuses.
2. If a person in a specific role has to take action at a specific stage of the process, this is also a good indication that the status should change. For CAPAs, if the QA manager needs to review the CAPA before any action is taken, then it makes sense to create a dedicated ‘Review by QA’ status.
3. If there should be a time delay between actions, a ‘Waiting’ status should be introduced. If an effectiveness check is due six months after a CAPA has been implemented, it should move to ‘Waiting for effectiveness check’ status (see Figure 1).

Image may be NSFW.
Clik here to view.

Typically, the existing CAPA form is a good starting point for the list of data fields you should define in your CAPA screens. Having a field on a screen can serve a few purposes beyond merely recording relevant information:
1. It can serve as guidance to the person executing the CAPA. We often see phrases within a CAPA SOP like ‘Check if the risk management file could be affected’ or ‘Notify the management representative if this might be related to the QMS’. As these are actions that need to occur during the CAPA process, it might be useful to add fields that will not only remind people of what they need to do but also record their decisions about it. A checkbox field with the title ‘Could risk management be affected?’ will enforce consideration of this question.
2. Data fields may influence the workflow of a CAPA. For example, if your organisation allows the ‘Effectiveness check’ stage to be avoided, then a field that allows users to indicate that the effectiveness check should be avoided can cause that stage to be skipped, taking the CAPA directly to the final status.
3. Data fields provide structured information which can be used to filter reports, facilitate analysis of long term trends and statistics and provide meaningful information for dashboards (see Figure 2).

Image may be NSFW.
Clik here to view.

Along with identifying the list of fields you will need, you should associate each field with the corresponding workflow status. For example, the field ‘Was this CAPA effective?’ should be filled in during the ‘Effectiveness check’ status. Because you could easily have many fields in a CAPA issue – a couple of dozens is typical – it’s good to split the fields into separate tabs, a tab for each workflow status. You should keep the layout of tabs and fields consistent across the different screens you use, for example using the same layout for the View and Edit screens.
Another design paradigm for creating a good user experience is to make the transition screen between workflow statuses present all the fields that need to be filled in for the current status. If ‘Root cause’ is a field that has to be filled in during the ‘Root cause analysis’ status, then the transition screen between ‘Root cause analysis’ and ‘Action’ will display the ‘Root cause’ field, along with all the other fields that have to be filled in before you can move forward. This is then coupled with a workflow validator, which will block the transition and display an error message if a user tries to move to the next stage without that field being filled in.

In life sciences, you need to consider the FDA CFR 21 part 11 if you want to use your JIRA Core Server CAPA implementation as your evidence for compliance. Intenso’s Electronic Signature plugin does a good job of providing an easy and compliant way to integrate electronic signatures into the workflow. You just need to decide during which workflow transitions you need an electronic signature then add an electronic signature field to those transition screens.
The other major requirement from FDA CFR 21 part 11 is the need to have an audit trail. JIRA Core has an audit trail facility built in. The trail for each issue can be found in the ‘History’ tab at the bottom of the View screen (see Figure 3).

Image may be NSFW.
Clik here to view.

In many cases steps 1-5 are all you need to get going using JIRA Core for your CAPA SOP.
However you can add plugins to streamline the workflow, making users’ lives easier. For example by using the right plugins you can:

• prevent users from making errors or performing the CAPA in a non-compliant way
• avoid people having to guess exactly what is expected of them
• and reduce the number of clicks needed.

You can use workflow mechanisms powered by plugins to achieve some very cool effects in JIRA Core. Here are a few examples of ways they can improve your CAPA implementation:

1. Opening CAPA subtasks automatically, such as a subtask to evaluate the risk management file when transitioning from ‘Root cause investigation’ status to ‘Action’ status. Several predefined subtasks may be created, depending on the fields filled in during the investigation. For example, if it was indicated that ‘Risk management may be affected’, then a CAPA subtask titled ‘Evaluate potential impact on risk management file’ will automatically be created and assigned to the right engineer.
2. Blocking the progress of the CAPA until all relevant subtasks have been completed.
3. Moving the CAPA from ‘Waiting for effectiveness check’ to ‘Effectiveness check’ status when the effectiveness check due date has elapsed.
4. Automatically assigning a CAPA to the quality assurance officer responsible for CAPA validation when it transitions to validation and verification.

Although you may think your process is very easy and logical, it’s always good practice to allow some of your end users to try it out. You will often discover quirks that will be easy to iron out but which could make a big difference to the user experience. Simply changing the name of a field, the options within a particular field or even the name of a transition could make the whole process more intuitive.
Before launching the new system it’s very important to get the quality assurance team to validate that the implementation accurately reflects your CAPA SOP. As a matter of fact, this stage often reveals not just problems in the implementation but also issues with the original SOP that should be addressed, such as an overcomplicated or incomplete description.
This step will give you a good feeling for how your CAPA meets the following awesomeness criteria:

1. Easy – a person who is familiar with JIRA (ie uses JIRA for other purposes) needs less than 15 minutes of training to be able to contribute to a CAPA issue.
2. Self-explanatory – a compliant execution of the CAPA process does not require the person to read the SOP.

If your CAPA doesn’t meet these two criteria, use this step to discover what you could do to improve it.

Reports and dashboards are the gateway to some of the key advantages to be gained from using JIRA Core.

It’s important to give people access to meaningful reports and dashboards from the very start. This helps to keep users motivated during the adjustment period and can help them realise some very quick wins.

My go-to set of CAPA-related gadgets for dashboards is:

1. Two dimensional filter statistics that shown all CAPAs split into their status (one axis of the table) and assignee (second axis).
2. List of all CAPAs for which effectiveness check is due.
3. Pie charts to view distribution of all our CAPAs per: CAPA source, status, assignee, etc.

Before signing off the implementation you’ll need to complete the V&V activities you defined in Step 1.

You will now be ready to roll out your new CAPA SOP implementation.

A few tips to guide you through the planning of the rollout:

1. Depending on the size of your organisation the rollout may be done in one go or gradually spread across teams and departments. By its very nature the CAPA process requires cross-team collaboration, so it’s not always easy to do a stepped rollout.
2. Teams that are already working with JIRA will have a much easier time getting accustomed to managing CAPAs in JIRA. They may act as champions for the new way of working and support other users. So, if possible, it makes sense to roll out the new CAPA process first in areas where some of the people already know JIRA. For example you could start the rollout on a product line that involves a big software team that already uses JIRA to manage their development work.
3. Create a JIRA project (or even a JIRA Service Desk project) where users can log tickets relating to the CAPA process implementation in JIRA. This will help you provide support where it’s needed and gather feedback to and drive the improvement of your implementation.