Interesting Discussion Using a Wiki to implement a Quality Management System (QMS)

[Pancho]

I hadn't noticed that 7.3.7 mentions "approval" and 7.3.1 doesn't.

Still, I agree with Helmut. By 7.3.1, you need to determine what are the appropriate review, verification and validation that need to be performed on your product's design "at each design and development stage". Changes may occur at any stage, so they must be controlled by 7.3.1. Sec. 7.3.7 just makes it more explicit.

As to whether "self approval" is adequate here (or in 4.2.3a), that's something only you or someone in your organization could answer.

In Geometrica, designers prepare "design reports" and "approval plans" that document, in detail, the design process and its results. These reports contain information about the designer's verification, including, for some critical design aspects, redundant calculations using different methods. Geometric validation is done on an actual, full scale, "test module", that is fabbed and assembled before the bulk of production, and then inspected by the designer. Design review and a second verification are done by the technical director or a senior engineer from the design report and the test module inspection report. Only after this design review, the records are sent to the customer for their approval before production (we call these "submittals"). Structural validation is done by sample testing during production. Any significant design changes require modification of the submittals.

So, because of the critical nature of our design process, we don't do "self approval" of the design nor of most changes.

 

[amirh]

Thank you Pancho for this reply.

I am trying to understand what is the extent of the documents you maintain in your wiki. For example, is the "design reports" and "approval plans" "verification reports" part of the wiki ? What about requirements and specification documents ?

The process that you describe clarifies to me the stages of your development process, however I am wondering how you track the of process and it's intermediate/final outcomes, and how do you maintain the documentation of your actual design in terms of revisions etc.

 

[Pancho]

Thank you Pancho for this reply.

I am trying to understand what is the extent of the documents you maintain in your wiki. For example, is the "design reports" and "approval plans" "verification reports" part of the wiki ? What about requirements and specification documents ?

The process that you describe clarifies to me the stages of your development process, however I am wondering how you track the of process and it's intermediate/final outcomes, and how do you maintain the documentation of your actual design in terms of revisions etc.

Yes, the design reports and approval plans are kept in the wiki, as are the contract documents. In fact, all project documents are kept in the wiki.

To be more precise, there is not one "the wiki" but several wikis, although this is neither obvious nor important to most of our users. Each project gets its own separate wiki space. Parts of each project wiki space are procedurally made accessible to the client as documents are ready and as the project develops.

For most documents, revisions are kept using the wiki's history feature. For a few documents, like some client submittals, we keep live separate pages for earlier revisions that were submitted to the client. If a particular document is being revised, we may close external access to that document temporarily, while it undergoes the internal work.

 

[Aziz Khan]

Hi Mike

We use JIRA to handle the record control requirements of ISO 9001, eg: CARs, NCRs, audits, etc. And the combination of JIRA workflows and Confluence handles the control of documents.

I'm not sure how much you know about JIRA, but while it started out as a software bug tracking application, it has evolved over the years into "Issue Management". So CARs, NCRs and audits are specific types of "issues". But we also have other types of issues, such as manufacturing issues, sales and marketing issues, product development issues as well as help desk or product return tickets.

Before we started implementing and rolling out the system, we needed to make a decision: does everything get raised as CARs (and use the priority field to determine how big the issue is) or do we have CARs for certain situations and other types of issues for everything else?

In my experience in organisations that only use CARs, while everyone understands the importance of raising them and continuous improvement, over time employees tend to start perceiving CARs as these serious things that get a lot of visibility, especially to the senior management. And that they often involve a lot of work taking it through the process - it just gets too hard... And you start getting the feeling that even the managers also start avoiding them….

And what this results in is people start avoid raising CARs, which defeats the whole idea of the corrective and preventative action process and continuous improvement.

So I expanded the Corrective and Preventative Action Procedure to differentiate between CARs (following the CAPA process) and other types of issues (using a less formal process).

What has been really exciting is that the senior management team are now running a fortnightly review meeting of all the issues deciding what actions should take place, which includes determining which issues should be turned into CARs to follow the formal Corrective and Preventative Action process. So they are looking at issues across the different areas of the business that can quickly identify related issues, eg: picked up an issue in the manufacturing which we think we have solved, but we can see that we are getting help desk calls and returned products related to it. This is powerful data to support decision-making!

So you get the best of both worlds: people are not afraid to raise issues and the issues are dealt with appropriately, whether it be via the CAPA process for serious issues or less formal process for less serious issues.

How are you doing record control?

Cheers
David

Hello David

We are a small electronics manufacturing company and i am tasked with revising our ISO 9001:2008 QMS procedures from paper based to WiKi (Confluence) and it has been an interesting journey as we are also using Share Point and forms/records are scattered.

I too (as did you) realized that over use of CAPA desensitizes people so I have created another category, IRR (Issue Resolution Request) which handles smaller issues. But since both of the processes are being handled by our PLM, Arena (Requests), it is difficult to get a good collaboration.

In short, I would like to discuss with you on how can i bring the CAPA and IRR to WiKi as well as implement WiKi based QMS less painfully.

Thanks,
Aziz

 

[maaquilino]

Several interesting discussions about using Wikis for QMS are going on; thanks for all the great info!

My question is based on using a wiki for a QMS for a medical device company, which is regulated by the FDA/ISO. In a previous company we used Documentum for Document Control, so it had to be validated. We also used several other software system for other parts of the QMS and each needed to be validated. So, what has someone who uses a wiki had to do to validate it?

The FDA General Principles of Software Validation; Final Guidance for Industry and FDA Staff states:

Any software used to automate any part of the device production process or any part of the quality system must be validated for its intended use, as required by 21 CFR ?820.70(i). This requirement applies to any software used to automate device design, testing, component acceptance, manufacturing, labeling, packaging, distribution, complaint handling, or to automate any other aspect of the quality system.

"In addition, computer systems used to create, modify, and maintain electronic records and to manage electronic signatures are also subject to the validation requirements. (See 21 CFR ?11.10(a).) Such computer systems must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

Software for the above applications may be developed in-house or under contract. However, software is frequently purchased off-the-shelf for a particular intended use. All production and/or quality system software, even if purchased off-the-shelf, should have documented requirements that fully define its intended use, and information against which testing results and other evidence can be compared, to show that the software is validated for its intended use."

 

[mmagargee]

Hello maaquilino,
You might try this link: https://answers.atlassian.com/questions/151613/confluence-for-fda-regulated-document-management and this: https://answers.atlassian.com/questions/151613/confluence-for-fda-regulated-document-management
The author, Ellen Feaheny, writes the following, "...Our team has done some work in this area - and also understand the different concerns you describe well.
We have released CFR Part 11 Compliance E-Signatures (FDA) for JIRA, and happy to work with you on a Confluence version!...There are corps out there (e.g., pharma, medical, food supply, etc.) that are using JIRA/Confluence in this way now - I know."

We began porting our directory based QMS to Confluence back in late summer 2013 and received our first 9001 audit in mid-March. We have been very pleased with the results. Not being in an FDA area, we have found Confluence without Jira to meet our document change and CAPA record keeping needs by using macro plugins such as Ad Hoc workflows. The approval history is maintained on the page itself and can be easily demonstrated to the auditor when requested (see attached image)."

Mike

 

[riskreward]

I've read these posts with great interest, as we have just embarked on the ISO 9001 / 13485 path at our Product Design Consultancy.

We started to set up a paper-based solution that uses MSWord docs and a directory structure on the network (and it's still the backup plan), but over the past two weeks we have been investigating using a wiki for the documentation.

So far we've trialled Project Forum, Confluence (with Ad Hoc Workflows), Google Sites / Docs, and Foswiki (with Workflow Plugin).

Just wondering how you wiki users are handling Records? Do you still have paper forms that need to be scanned in (and perhaps attached to the wiki)?

Thanks.

 

[Pancho]

I've read these posts with great interest, as we have just embarked on the ISO 9001 / 13485 path at our Product Design Consultancy.

We started to set up a paper-based solution that uses MSWord docs and a directory structure on the network (and it's still the backup plan), but over the past two weeks we have been investigating using a wiki for the documentation.

So far we've trialled Project Forum, Confluence (with Ad Hoc Workflows), Google Sites / Docs, and Foswiki (with Workflow Plugin).

Just wondering how you wiki users are handling Records? Do you still have paper forms that need to be scanned in (and perhaps attached to the wiki)?

Thanks.

We keep most records on the wiki. Many are entered directly into the wiki in wiki format, but many others are recorded on paper and later scanned and uploaded to the wiki. We also have records produced electronically, such as CAD drawings and spreadsheets, that are saved into the wiki in two formats: as a screenshot and as its source file.

This works fine for ISO 9001, but I don't know if it does for 13485.

 

[midomidi2013]

Hi Pancho (and all the other people that have chimed in on this),

Very interesting thread, and very timely - we're just about to start moving to Confluence form Atlassian for our ISO 13485 quality and documentation systems. One question or concern that has come up; a fair chunk of our organisation is not technical staff and seem rather uncomfortable with the idea of writing wiki markup. Confluence does have a WYSIWYG editor, but you still need to drop into the markup at times. What has been people's experience with this cultural shift/learning curve? I can see it being possibly the largest hurdle we're going to have to get over in getting people to use it...

 

[mmagargee]

Hi Pancho (and all the other people that have chimed in on this),

Very interesting thread, and very timely - we're just about to start moving to Confluence form Atlassian for our ISO 13485 quality and documentation systems. One question or concern that has come up; a fair chunk of our organisation is not technical staff and seem rather uncomfortable with the idea of writing wiki markup. Confluence does have a WYSIWYG editor, but you still need to drop into the markup at times. What has been people's experience with this cultural shift/learning curve? I can see it being possibly the largest hurdle we're going to have to get over in getting people to use it...

Hello midomidi2013,
We have an ISO 9001, ISO/IEC 80079-34 (potentially explosive areas) QMS that we moved from a server/directory format of document records/spreadsheet logs to Atlassian's Confluence. As far as I know, no one here is using wiki markup unless they are trying to observe plugin macro syntax. We have relied heavily on the functionality of those plugins to link metadata, run approval workflows, summarize record fields into parent log pages, track document reads, and push tasks to assignees.

Regarding the formatting of page content, it is very basic compared to MS word. However, the philosophy is that less is better, because gone also are gigantic page sizes resulting from pretty formatting as well as the maintenance of a fat editing program. Knowing this, people have made the transition fairly well, concentrating on getting the information into the pages more than putting more effort in formatting. Confluence does have its idiosyncrasies (actually a few irritating minor bugs) such as working within its bulleted lists. In situations where I want to insert a photo into a numbered or bulleted list, I have to create the list first, then hit return for a dummy bullet, and then insert the picture. If I try to remove the bullet, or to just have a blank space within the list, all hell breaks loose. There is one other bug involving table row insertion. I notice sometimes the editor locks up when trying to insert multiple rows one at a time and I go elsewhere on the page, select some other text, and then the editor begins to work again.

As far as the big picture goes, our company is very happy with our move to Confluence. It promotes the collaboration that the server approach did not particularly with regard to document sharing and content search ability. And I now have the philosophy that a summary log of individual record data will never be created manually again--we simply point the parent reporting page to the metadata located on its child pages and extract it automatically. Gone then are all of the fat finger data entry mistakes, arbitrary formatting (caps one time, lower case another time), and extra keystrokes.

Mike