21 CFR Part 11 Compliance Guide for Jira (Atlassian)

FDA 21 CFR Part 11, also known as Part 11, are complex regulations all medical device software companies (and other companies under FDA regulation) in the United States must comply with. Part 11 regulations require detailed planning and documentation, proof the organization uses a compliant quality management system (QMS), as well as proof that all electronic records, electronic signatures, and handwritten signatures attached to electronic records are dependable and credible. 

In the words of the FDA, “Part 11 applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted under any records requirements set forth in Agency regulations. … We intend to enforce all other provisions of Part 11 including, but not limited to, certain controls for closed systems in § 11.10. For example, we intend to enforce provisions related to the following controls and requirements:

• limiting system access to authorized individuals
• use of operational system checks
• use of authority checks
• use of device checks
• determination that persons who develop, maintain, or use electronic systems have the education, training, and experience to perform their assigned tasks
• establishment of and adherence to written policies that hold individuals accountable for actions initiated under their electronic signatures
• appropriate controls over systems documentation
• controls for open systems corresponding to controls for closed systems bulleted above (§ 11.30)
• requirements related to electronic signatures (e.g., §§ 11.50, 11.70, 11.100, 11.200, and 11.300)”
  

Jira, Atlassian’s product management software, can be an excellent choice to ensure companies are compliant with 21 CFR Part 11. However, Jira alone is unable to ensure compliance with 21 CFR Part 11. To become compliant with Part 11, Jira needs to be properly managed with specific plugins and/or external software. Although Jira has many important features to help with Part 11, companies using Jira to be FDA 21 CFR Part 11 compliant need to be aware of specific pitfalls within Jira that can push them out of compliance. 

Is Jira FDA 21 CFR Part 11 Compliant?

Yes, Jira could be FDA 21 CFR Part 11 compliant, only if it is configured with the correct features. However, Jira, by design, is not Part 11 compliant. The main issue with the default configuration in Jira is the lack of an audit trail  when tickets are changed or deleted. Jira only cares about the current state of tickets and does not provide an immutable audit trail for each record. Jira does not show who made a change to the record, when the changes were made or the difference between the old and revised record. This is one major issue that companies must address to stay in 21 CFR Part 11 compliance.

When using Jira, companies need to make sure evidence can be created and exported to be able to show they meet Part 11 requirements, such as: knowing how to use the specific company’s computer systems and software, tracking data changes, preventing and/or detection of falsified records, storing data securely and ensuring data is neither corrupted or lost, and ensuring that approval and verification of signatures cannot be disputed. 

‍

Adjusting issues in Jira to prevent companies from falling out of FDA 21 CFR Part 11 compliance

21 CFR Part 11, Subpart B – Electronic Records in Jira, § 11.10 Controls for closed systems.

Subpart B, Section 11.10 of 21 CFR Part 11 states that Persons who use closed systems must have “use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records.” A very important flaw to note in Jira is the irreversibility of the ‘Delete’ operation. Deleting an issue in Jira permanently removes the issue, comments, and attachments, with no way of retrieving the deleted data. If information is permanently deleted—with no audit trail to show when or what item was deleted, or by whom—companies will automatically fall out of compliance with 21 CFR Part 11. To resolve this, users can change the default setting in Jira to set up a dedicated resolution type such as ‘Canceled’ or install the Atlassian plugin, ‘Issue History for Jira,’ to allow an audit trail to track all changes and deletions. 

This Subpart also covers another issue in Jira—the lack of traceability with who is changing tickets, items or data within the system. A plugin to potentially help this issue with 21 CFR Part 11 is Atlassian’s “Auditor for Jira.” This plugin was designed to meticulously monitor all administrative actions, effectively mitigating the challenge of incomplete data concerning past interventions carried out by a number of Jira administrators. 

21 CFR Part 11, Subpart C–Electronic Signatures in Jira, § 11.100 Electronic signature components and controls.

Subpart C, Section 11.100 of 21 CFR Part 11 states, “When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.” This means that after a user first uses an electronic signature (signing in to their Jira account), users must provide a secondary electronic signature component when modifying, adding, or removing data from the system. This secondary electronic signature can consist of a user name / password, biometric identification (fingerprint of retina scan), or a secure token / device. 

‍

‍

Jira does not have the proper default compliance when dealing with electronic signatures. An ‘Electronic Signature’ plugin is necessary to verify the credentials within the advanced technical requirement of 21 CFR Part 11. 

How Ketryx can ensure companies are compliant with the FDA and 21 CFR Part 11 in Jira

Ketryx lifecycle management software effectively solves all of Jira’s non-compliance problems with 21 CFR Part 11. If users integrate Jira with Ketryx, there is no need for multiple plugins, guess work, or the tedious amount of time and effort administrators need to exert in order to be 21 CFR Part 11 compliant. With the integration, Ketryx transforms companies' Jira instance into 62304 compliance. Ketryx preserves companies data by validating the system to maintain the integrity of all data and gives Ketryx users 21 CFR Part 11 signature compliance in the front-end of Jira. Watch the short video below to see it in action.

‍

FDA 21 CFR Part 11 Compliance in Jira interview with Part 11 experts, Jake Stowe and Lee Chickering: 

As a benefit to our readers, we have included an edited transcript of an interview with two top engineers at Ketryx about compliance with the FDA and 21 CFR Part 11 in Jira. 

21 CFR Part 11 Compliance in Jira – Abridged Interview Transcript:

The topic is 21 CFR part 11 and its application. One thing that I hate about the content in this space is that it's kind of all deliberate, not maybe deliberately, but it's a lot of people using a lot of big fancy words for things that are not really at the end of the day that complicated. 

Initially built for pharmaceuticals to be applied to manufacturing facilities, 21 CFR part 11 is a set of regulations promulgated by the FDA in the late 1990s to adapt to the industries they were regulating and who were starting to use electronic media to record sensitive data, rather than paper. There are two primary problems. One of them is that you have to follow a very strict set of procedures and policies. You know, it was a binding procedure, you could not deviate from it without incurring consequences to the organization and consequences to yourself.

So, when someone was executing, for example, a washing operation, he would be with someone as his verifier and the verifier would have the procedure open. They would read the line of the procedure; he would execute that line. Then on a really important step, they would have to both sign that the step has been performed correctly. He is the performer, and the verifier is the verifier. So, there's a witness standing next to you ensuring that you executed that procedure exactly according to what was written down in it. That's one problem. 

The other problem is that you need to very rigorously record the data that is generated from each of those steps. So sometimes those signatures indicate that the thing got done. Sometimes it's readings off of a piece of equipment. Sometimes it's the outcome of a specific analytical test that was performed. Prior to the 1990s, all of that was done on paper. So, you'd have a controlled procedure, which means that it had a controlled versioning, someone would write it or type it up. Someone would sign off on it saying this is the official version. And then when a new version came out, someone had to scour the floor to make sure all of the old copies were destroyed. Then there were official forms, and you can't imagine the level of detail that this gets down to like if you had a piece of paper that we had to write down something on in the manufacturing plant. It had to be written down on what's called a controlled form, which is literally in a page of documents that have been specifically numbered in an indelible way so that you could audit to ensure that no form had been produced that wasn't accounted for in the plant. It's an insane amount of detail. As you can imagine, this was very hard operationally for people to deal with. It's just a ton of paper. 

As soon as computers started entering the mainstream as ways for people to organize work, pharmaceutical companies started to want to work with modern database applications to be able to record this data. It's just a better way of doing things. Then the FDA was very slow because these applications started in the late 1980s and it took them about a decade to adapt to it. They promulgated the set of regulations that basically explained to organizations that they regulated how they could use these electronic systems to record this very sensitive data. 

Then the regulations for 21 CFR part 11 came out. There are a variety of aspects of the regulation that are important. And again, if you go back to the first time 21 CFR part 11 was promulgated, it was in the late 1990s. 

This is a signature manifestation. So, one of the first distinctions that the agency makes is the distinction between closed and open systems. An open system is essentially anything that you can access without a password and a username, something that you don't really have a control over. And controlled systems are exactly the opposite. You have control over who's able to access the system and you'll find that pretty much any system that is used in executing a GXP process. GXP being a regulated process by the FDA is going to be a closed system. The reason for that is that you have to ensure that people have been appropriately trained. They're all items in here. They've been trained appropriately that they have the appropriate permissions within the system to do things. All of that comes with being in a closed system where you know what the user who the user is who's accessing the system, as well as applying electronic signature which will get to in just a moment. 

This subsection 11.10a is really important. What it essentially says is that systems like this need to be validated. We can talk extensively about what validation means - it is kind of the core of what Ketryx does as a product right now, we make validating products significantly easier than it is. Validation, in a very layman's sense, is just ensuring that you have evidence of confidence that the system that you're building does the thing that you say it should do. There’s a lot that goes into that but there's a kind of a well-defined art of validating systems and you need to apply that art to any system that you were going to use as a part of a regulated process. One of the main things that you need to be able to do is preserve the data. This is, I think, one of the FDA’s primary concerns when they promulgated these regulations is that they did not want to have databases that were going to allow you to create mutable data. You want people to be able to go in and edit that data after the fact. So one of the things that you have to validate the system to is the integrity of the data. Once it's entered you can't lose it anywhere it's there forever and ever and ever. 

You also need to be able to generate human readable and electronic readable records. It's not okay for an auditor to go to a regulated site and say I want to know what happened at this unit operation on this day, and for you to say well it's stored in our database, but we can't produce a copy that you can understand. That's not alright, you need to be able to produce a paper copy or something that a human would be able to understand. 

You also want to be able to limit the system access, as we were talking about before, to only people who have been trained or allowed to use the system. You only want certain people to be able to extract data from the system and you only want certain people to be able to do certain things in the system. Obviously, you don't want everyone to have administrative rights in the system. Some people are just users, they can input data and some people are administrators who can do higher level things. This part is really important as we talk about Jira, which is the use of secure computer-generated timestamped audit trail. Not only do you need to have the original data that needs to be documented, but you also need to have all the data about who did that documenting and at what time. So, if you write down data or you say anything, you need to know who wrote it down at what time and generally why they wrote it down too, especially if for some reason you are going to modify the data in some way. 

The agency is basically taking this very old practice within the regulated environment and bringing it into this modern way of doing things. You are not allowed to not know who wrote that thing down. So, you need to have audit trails that go along with it. There are some other items in here that are important like authority checks of who's allowed to do what within the system and operational system checks to ensure that the system is doing the things.

So, if you're taking a reading on a tank, and that's going to get multiplied out or something into a density, as a minimal example, the calculation that does that would need to be checked and double checked and there would need to be evidence that it had been implemented correctly within the program. You need to have training, anyone who uses those systems needs to be trained. There needs to be a written set of policies and procedures that goes along with that system that's under control. So, you have to generate documentation that explains how you can use that system and it's not possible for anyone to change that documentation that needs to be controlled. 

So, essentially, it's like the agency is trying to take away all of your outs for saying that the data wasn't documented appropriately, or I wasn't able to keep track of it or people didn't know how to do it. No, you're not allowed to do that. The people who use the system have to know how to do it. The system should ensure that people are not allowed to do things that they shouldn't be doing. The system should store that data indelibly for whatever the retention period of those records are. You should know for every change to the system, every change to the data that that system is managing. You should know who did it and why. It's an enormous amount of detail. 

Along with that, because signatures are such an important part of regulated operations, you need to have some concept of who has the authority to do something. You need to have some concept of whether I was allowed to make that decision. Signatures are such a critical part of the standard operations as I explained earlier. You have this reader/doer concept where someone is reading to perform the procedure. They're executing each of those steps and then they are signing on the dotted line. Their signature basically says they take responsibility for that thing that was done. If we find out later on that it wasn't done, well then we can fire them. Or there can actually be criminal penalties for perjuring yourself in that way. So electronic signatures are really important and the agency is now saying in this electronic signature section that we need to make those signatures airtight. There should be no way for someone to claim that their electronic signature was made in their absence. They say all these things you need to be logged in. You need to provide a second bit of data when you make the signature to ensure that it's actually you. 

You're only allowed to use these certain types of biometric signatures. So most of the electronic signatures that you use for signing, for example, rental agreements with your apartment complex are not stringent enough for the FDA. There's this component of you're logged in so there's one set of identifying information and then you need to enter another password or something like that at the time that you make the signature. So, in the end, the 21 CFR Part 11 is about ensuring that the people who are working within the electronic system are who they say they are, that they are doing the things that they're allowed to do, and that the system isn't going to inadvertently lose data or isn't going to inadvertently transform data in a way that could be misinterpreted. 

You have various checks that are built into the process that are gated by whether someone signs off to say that this is okay. So, if you're, you're checking the tank and you're seeing what the level is in the tank, and two people look at it and they agree that the tank is at 70 liters or something like that. In some sense, that is the same as reviewing a feature and checking to see if it does the thing it's supposed to do. Like both of those are decisions, they're somewhat different, but at the end of the day there's a binary decision you have over whether this thing is good enough or not good enough. 

So, what's wrong with Jira? 

One thing that's wrong with Jira is that Jira as a system only believes in the current data that exists here. So, if I edit this description and change something about it, I can't easily trace or find out why or where that data went. It's kind of impossible to reconstruct that if a lot of things are being edited here. The other thing that it doesn't have, is it doesn't really have a strong concept of a signature. So, if I make a transition or something like that, it's very hard to ensure that it is me who did that thing. Two pretty serious violations. The two core criticisms about Jira is that you don't have a concept of identity with signatures or changing things. 

Again, Jira on its own only believes in the present data. The present data is what's important, but 21 CFR part 11 says all of the data is important. You need to know who changed every little last detail. That's what I mean by keeping track of everything. So, from a part 11 standpoint, I think the really the core thing that Ketryx does is we don't allow you to lose any data. 

So, if you look at this record, and I scroll on it, every change is documented. Each one of these items here represents a version of this ticket. So, if I look at this version, the last version of the product, you can see that this description was edited. You can see that this was removed and it was me who did it. So, this is on the Ketryx software. Jira itself wouldn't have this ability. When you install the Ketryx connector in Jira, then that sends the data to the Ketryx software that we're looking at now. You can't do any of that within Jira itself. 

Let's say that I'm unhappy that someone deleted that, and I want to know where it went and I prefer the record that way. Well, I can just go back to that record. The version that I liked, the one that includes this user-friendly interface, I can restore it. I take that version and I make it the present copy of that record and it will push that record back to Jira. Now if I refresh this and you'll see that it's back. 

The other thing that Ketryx does is we give you 21 CFR part 11 compliance signatures on the front end. So, I'm logged into Jira, that's the first gate. A password is necessary to log in. But then if you're going to do an electronic signature application, what that does is it makes the ticket immutable, but it also tells Ketryx that this ticket is ready for approval. If I click this button, this pop-up will open and it prompts me for the second bit of information that's necessary for me to complete the signature. I agree to electronically sign this. I am basically checking, saying yes, I want to do this. I sign, and their ticket closes. Jira does not do that. 

The three main things are the signatures, the version trail and then the auditing. That's their method of doing it because they're not doing things nearly as sophisticated as Ketryx is. Most of the people, consultants who do this, literally tell you to take a screenshot of the completed record. So, a human has to screenshot the completed record, which is crazy. That doesn't need to be validated. That's just an aspect of the procedure. Then, for the extraction, you use the API to pull the data out. Then you would need to do some validation on doing that. It's human processing from there to get it into a format that's correct. In every situation where you're performing the validation yourself it takes a lot of time and money. 

An Important component of the regulations on producing medical devices is when computers are automated, data processing systems are used as part of a production of the quality system. The manufacturer shall validate computer software for its intended use, according to an established protocol. All software changes shall be validated before approval and issuance validation activities and results shall be documented. The regulations in this part is set forth a criterion under which the agency 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.

‍