I want to use Confluence in the medical device industry. Acutally we have the requirement from FDA to validate the system " confluence".
For validation we use GAMP 4 standard like the pharmaceutical industry. Now we need a paper that establish, how Atlassian is doing the quality management in software development.
Also we need an agreement about the follow test:
Happy to discuss this with you -
On a sep note, we have a plugin for FDA compliance needs in JIRA. Maybe you want to check that out in meantime.
Is this easily available or something that would need to be discussed?
Sorry - I should've been more specific! I was actually referring to the testing in the original question as we're in a similar situation. I'm more than happy to email direct at the email above. We're trying to get an idea of whether it's best to do it ourselves, or work with a company like AppFusions.
You probably want to raise this directly with Atlassian support if you're after information on what they do internally. They're pretty open about it (read their blogs and documentation), but direct questions to them will be more focussed and may be able to give you a simple straight answer.
Hi Zach, Ellen,
My company Good Automation provides turn-key FDA compliant validation services. As you point out, a good solution is only half the battle. FDA requires that
"when [software is] used as part of ... the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol...." (see 21CFR820.70i)
Part 11 regulations (21CFR11) and recent FDA guidance (Guidance for Industry Part 11, Electronic Records; Electronic Signatures — Scope and Application) essentially says when the software above either:
A) Keeps records as required by predicate rule requirements (is system of record for certain Quality System data) and/or
B) Lets users electronically sign documents (e.g. manager approval as required by predicate rules)
When either or both apply, FDA says you have to validate the system. This is easier to understand in the context of good documentation practices and good record keeping practices you would use for paper records. Taken with 820.70i above you can see Part 11 just says: "You can use a computer instead of pen and paper, just validate the system to your intended use - i.e. replacing the pen and paper".
Feel free to ping me directly if you have questions about software validation. Like everyone, I struggled when first grappling with these concepts. They seem complex but turn out to be straight forward once you have done a few of them. The key is to get very good at articulating the Intended Use statement. With that in place you next enumerate User Requirements. Then author a Validation Protocol, execute it, and author the Validation Report.
I teach classes on FDA compliant software validation. My company helps medical device makers write SOPs to control the software validation process. We also help them validate individual tools like JIRA.
Using a tool add-on like the one discussed here is a great first step but you still have to validate the final configuration to your intended use. Feel free to ping me if you still have questions. This stuff can seem vague at first but it gets easier.
PS: Sorry if this posted twice. It did not seem to post the first time.
Sorry I misunderstood - yes email me.
We would definitely need more specs / details on this for sure b/c indeed we know that the CFR Part 11 spec is a long and beefy one, and we have experienced varying levels of interpretation on what "compliance" means - which also might be right, for different types of corps with these requirements. It covers a broad set of verticles to say the least!
But yes, we have gotten into this a bit b/c I find it an interesting problem, partly (a bit passionate on this solution angle) and also b/c using Atlassian tools for this use case is a significantly more cost effective solution - even with custom development, than the batch record solutions in the market that may not fit the glove as well.
What's alluded to above could be handled a number of different ways - in Confluence, or in JIRA, or a combo of both - depending on your specific needs.
We can give you some ideas to think about - depending on where you are at on evolving to these new processes in your org (new, migration, evolved, etc.. ).