Regulations dictate that controlled records should be managed in compliance with the FDA CFR 21 part 11 (aka Part 11) guidelines.
Part 11 defines the criteria under which the US Food and Drug Administration ‘considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures executed on paper’ . Although released back in 1997, it remains the gold standard for management of software applications, databases and files in the life sciences sector.
JIRA features many important elements to facilitate Part 11 compliance as standard. These include automatic generation of audit trails (covered in section 11.10(e) of Part 11).
With the right configuration, JIRA can be set up to support a fully compliant operation. However there are some pitfalls that, if not correctly managed, can result in the creation of non-compliance loopholes.
The deletion trap
One of the major pitfalls is the ease with which it is possible to completely and irreversibly delete an issue. Quoting from Atlassian’s JIRA documentation:
When you delete an issue, you actually remove it permanently from JIRA, including all of its comments and attachments. If you have completed the issue, you may want to set it to Resolved or Closed instead of deleting it. If there are sub-tasks in the issue, these sub-tasks are also deleted.
Indeed the ‘Delete’ operation in JIRA is as total as it gets. It erases an issue from the database, leaving no trace, and there is no way to recover the deleted issue or the associated audit trail. Even when using JIRA’s powerful reporting language, JQL, to report on past data (using the ‘WAS’ operator), the deleted issue will not be included.
This possibility goes against the essence of an audit trail and leaving this feature in place would contradict Part 11.
Configuration to the rescue
Fortunately, JIRA’s default settings can be changed to avoid the possibility of deleting an issue. In fact, there’s more than one way to manage this, but the most common option is to block the ‘Delete’ operation through the permission settings.
The ability to delete an issue from a specific project is governed by a dedicated permission. You can revoke that permission from all users to avoid the possibility of total deletion. However you will need to decide what should happen when you do actually want to discard an issue.
The most common solution is to follow Atlassian’s own advice and set up a dedicated resolution type, such as ‘Cancelled’. In this scenario, instead of deleting an issue, you would take it through a workflow to a final state, typically ‘Done’, but setting the ‘Resolution’ field to ‘Cancelled’. In this way, the issue can be filtered out from reports, dashboards and your day-to-day work, but will still fully exist in the database.
As a further step, ‘Cancelled’ issues can be moved to a separate project, designed to serve as an electronic repository. They will then be available in case anyone needs to refer back to them, whether for auditing purposes, to learn from past mistakes or to retrieve an issue cancelled in error.
So, in summary, while JIRA comes out of the box with several features that facilitate Part 11 compliance, it needs careful adjustment to avoid potential problems like permanent deletion of issues and their associated records.
If you would appreciate our help to set up your JIRA instance to facilitate compliant process management, please get in touch.