Managing your CAPAs in JIRA: key questions answered

Yes, you can.
CAPAs are triggered from other processes, such as customer complaints or audit nonconformities. A CAPA often also triggers other processes, for example an engineering change request (ECR) or a training activity. Linking CAPAs with the other relevant processes in JIRA helps to provide the full context of the CAPA, avoids the need to duplicate information and efforts and facilitates coherency. Linking can also be used to enforce certain business rules. For instance we can avoid the CAPA being marked as ‘implemented’ before all the related activities are completed.
The way the links work will depend on where the other processes are managed.
If your linked process is managed in JIRA, whether in the same instance or a different one, the link can be customised to implement and enforce business logic. The processing of the two linked issues will be mutually dependent. For example, a nonconformity cannot be closed until the related CAPA has been validated. It is also possible to configure what information about the linked issue will be seen in the CAPA and to adapt the link name to whatever terms you use.
If the other process runs on a system which is not a JIRA instance, it may still be possible to implement a link between the two. 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 the other system.
Even if the other process is managed in a way that doesn’t support an electronic connection, it should be possible to include a relevant data field in the CAPA process.

Yes, JIRA makes it possible to attach multiple files to each issue. These files may be of any type, and may be added to the issue at any stage.

Yes, you can use a variety of key performance indicators (KPIs) to measure CAPA performance. These may be based on factors such as:

• the time between the opening of a CAPA and when validation is completed
• the percentage of CAPAs found to be effective
• the number of similar cases reported after a CAPA has been processed
• the number of work hours directly associated with the CAPA.

All the above and many more options can be accommodated. Once a KPI has been defined, a corresponding report may be created. The KPI report can then be displayed within JIRA in a table, pie chart or other format of your choice. Alternatively, you can export the data from JIRA into Excel or a specialist statistical package for analysis.

Yes, JIRA provides a rich set of possibilities to keep you up to date with the various activities. Each user can set up notifications to suit their needs. The options include:

• Email notifications for every update.
• Email digests – You can choose between a daily digest of all CAPAs which were updated that week, a weekly digest of all new CAPAs or a weekly digest of all CAPAs where validation is more than a month overdue.
• The JIRA dashboard – This is a secure web page that displays a concentration of stats and reports relating to your CAPAs. The dashboard is live in two ways: 1) it refreshes at regular intervals to reflect the latest information and 2) the information displayed links directly to the data from which it is derived. That means that in one click you can investigate or act on any information you see on the dashboard. People who work regularly with JIRA tend to keep the dashboard open in their browser continuously and some companies display the dashboard on a big monitor for everyone to see.

Yes, JIRA can help with this.
Ensuring follow-ups occur at the correct intervals is one of the sticky areas in implementing an effective CAPA system. When you need to make an effectiveness check on a CAPA will be dictated by a combination of factors:

• Regulations.
• How long it takes to demonstrate that the CAPA has effectively mitigated the reason for its creation.

When you implement a CAPA process in JIRA we can ensure this follow-up occurs at the correct point. The date can either be set manually or be based on defined business logic. The CAPA will then go into a ‘dormant’ waiting status. When the due date arrives, the CAPA will automatically transition to ‘Effectiveness check is due’ status. At this point it will appear on the dashboard and in reports and email notifications, to remind the assigned staff to carry out the appropriate check.

Yes, standardisation can be built into the process.
One approach is to use standard checkpoint questions, such as:

• Have non-conforming products been released to the market?
• Could this issue affect other product lines?
• Could this issue affect risk management?

Going through those questions forces the team to carry out an effective analysis of the problem. Once the analysis is done and the CAPA moves to planning and implementation stage, the same questions may be used to create the required actions. In JIRA, these actions are called subtasks.
If, during the analysis stage, it was indicated that ‘This issue could affect other product lines’, an ‘Evaluate possible relevance to other products’ subtask would be generated automatically. If it was indicated that ‘This issue could affect risk management’, a subtask dedicated to performing risk management would be generated.

By building the process in this way, we ensure that all the relevant complexities and possibilities are followed through

This issue deserves a whole post dedicated to it, or even several. However, here are two important examples of how JIRA could help you adhere to the FDA CFR 21 Part 11 requirements.

Electronic signatures

Using an extension such as inTenso’s Electronic Signature plug-in we can enable the relevant people to submit electronic signatures in JIRA. To electronically sign the process a user has to introduce their user credentials on the JIRA transition screen. The signature is then logged together with the issue.

Audit trail

JIRA, out of the box, creates an audit trail for each issue. The trail includes a record of the issue’s creation and any modifications or comments.

Some companies opt to create paper copies of the CAPA records, to serve as the master records. This approach is usually motivated by a combination of the following factors:

• It reduces upfront investment in the system compared to implementing electronic validation.
• The compliance officer believes a paper copy has less risk of being deleted or lost then an electronic record.
• A lack of sufficient IT governance resources.

If your organisation is ready to move to a fully electronic system for your regulatory compliance, you will need to develop and implement a validation strategy. Bear in mind that the regulations require that the system is validated within its context of use and with the relevant procedures in place.
This is an area where we work closely with our customers, to provide the support they need to achieve validation and put a good long-term revalidation plan in place.

Yes, we can configure and customise JIRA to reflect your standard operating procedures (SOPs) or your existing forms.
When a JIRA issue is created, it transitions through several stages to closure (‘Done’ in JIRA language). This is called the issue workflow. Each issue consists of several data fields, including Summary (this consists of the title of the issue, description and creation date).
Out-of-the-box, JIRA comes with several workflows and data fields, mostly designed to suit software development activities. However, it comes with a full set of features that make it possible to define an infinite number of other workflows. This is the foundation that allows us to define virtually any CAPA process in JIRA.
The figures below show schematics of two CAPA workflows that we’ve implemented for clients. Although each one has nuances specific to the organisation, both embody some common CAPA principals.