Update of SOPs for ISO 13485:2016 / MDSAP

[Marcelo]

To clarify, when you say "anyone", there are many qualifiers, no?

First, you have to go through a national member organization, and these, in turn, dictate the "technical committees" that are involved with development of specific standards. Do I have this correct?

The bottom-line is that, it seems (correct me if I'm wrong), to be involved in the development of a specific standard that you're interested in is not a simple matter for the vast majority of small-to-medium sized manufacturers.

I agree that being part of the ISO WG is not an easy task for most organizations.

However, you don't need to be a part of the ISO WG to be part of the development. The WG mostly drafts the text and revised it based on comments, but the comments (after the WD stage) are created by the National Committees mirror committees. So, if you are a member of your country NC mirror committee, you will receive the drafts and can comment. Membership of a NC mirror committee is usually open to interested parties, or they may have some kind of qualifier.

 

[Ronen E]

Membership of a NC mirror committee is usually open to interested parties, or they may have some kind of qualifier.

My previous comment (reproduced below) referred exactly to that.

It seems that it has a lot to do with local mentality / culture. In some countries it's fairly easy to join in and contribute but in others it's practically impossible for the common person.

 

[MikeKen]

Software validation and Software re-validation appears in 3 specific clauses -

• 4.1.2 General Requirements (very general statement to computer software used in the quality management system)
• 7.5.6 Validation (computer software used in production and service provision
• 7.6 Control of monitoring and measuring devices (computer software used for the monitoring and measurement of requirements)

Software val/re-Val is required by various regulations today so it won't be anything new for some companies. It really break down into 3 key area

(1) Computer systems/software which are part of equipment. Software should be validation as part of the equipment qualification/validation.
(2) Spreadsheets used to support the QMS. Would need something like a Spreadsheet validation procedure.
(3) Computer Systems – standalone applications (e.g. ERP, eQMS, Minitab). This is the most complex area and Software validation expertise would be needed.

Hope this is a little helpful.

 

[Sam Lazzara]

At the end of my SOPs I reference and quote all the relevant standard clauses associated with that particular subject - so I had to update this section specifically.
Steve

I recently cracked the 13485:2016 nut after much consternation.

Rather than cross-referencing to the standard clauses in each individual SOP, I prefer to manage the cross-references by placing them into a single document; in my case, it is the Quality Manual.

On a related note, for managing quality system process risks, rather than adding a Risk section to each SOP as some have suggested, I added a new section to my Quality Manual to address process risks, i.e. SOP risks. Since my Quality Manual already lists the SOPs, this makes sense to me. And by having all of the risk assessment and control information in this single document, it seems easier to manage than sprinkling risk assessment/control info into each SOP.

I have attached the front end of my new QM risk section, so you can see how I have formatted it. Any feedback is appreciated.

 

[Wolf.K]

The risk section in each SOP might have the benefit, that everyone who is working with a certain SOP (at least the process owner) (should) know(s) which risks exist. I think this is helpful to cover the "risk-based approach" requirements? Personally, I like the "risk-based thinking" approach in 9001:2015. We have flat hierarchies in our company, and an open discussion culture with no punishments for mistakes (but with punishments if mistakes are known put not reported). Therefore I think every employee should know the risks associated with the processes he/she is involved with. 13485:2016 does not require this, I know, but my gut feeling likes it!

 

[Edward Reesor]

I was recently speaking with someone who has gone through a MDSAP audit and he strongly suggested I use the documents found on the FDA website as a template for our documents. Apparently, the audit format has changed and what is being used is essentially a checklist that follows the format of these documents (done/not done with non-conformity finding). There are no minor/major non-conformities but instead a numerical ranking system (and I believe section 6 is ranked stronger than section 4). As you stray away from conforming, the numbers add up like demerit points.

I was also informed that two auditors are in attendance, doing their respective parts and 20-30 non-conformities are not unheard of for an audit.

My lack of posts won't allow me to hyperlink or post the URL's, however they can be found my searching FDA and MDSAP. There is the program itself as well as a Companion document.

 

[Sam Lazzara]

The risk section in each SOP might have the benefit, that everyone who is working with a certain SOP (at least the process owner) (should) know(s) which risks exist. I think this is helpful to cover the "risk-based approach" requirements? Personally, I like the "risk-based thinking" approach in 9001:2015. We have flat hierarchies in our company, and an open discussion culture with no punishments for mistakes (but with punishments if mistakes are known put not reported). Therefore I think every employee should know the risks associated with the processes he/she is involved with. 13485:2016 does not require this, I know, but my gut feeling likes it!

I agree that anyone involved with a quality system process should understand the risks imposed if the associated procedure is not followed.

For my approach where all of the risk information is included in a single document - the Quality Manual - I would ensure that all personnel are trained on the Quality Manual; something I did not require in the past.

 

[Sam Lazzara]

I was recently speaking with someone who has gone through a MDSAP audit and he strongly suggested I use the documents found on the FDA website as a template for our documents. Apparently, the audit format has changed and what is being used is essentially a checklist that follows the format of these documents (done/not done with non-conformity finding). There are no minor/major non-conformities but instead a numerical ranking system (and I believe section 6 is ranked stronger than section 4). As you stray away from conforming, the numbers add up like demerit points.
My lack of posts won't allow me to hyperlink or post the URL's, however they can be found my searching FDA and MDSAP. There is the program itself as well as a Companion document.

Hello Edward,

I believe you may be referring to these documents established by the regulatory authorities involved with MDSAP to guide their activities.

Do I have this correct?

Interesting that the MDSAP participants are apparently operating under a QMS that they devised. It appears to be modeled after ISO 9001:2015.
Excerpt from Quality Manual: To enhance consistency, efficiency and effectiveness of day-to-day work, MDSAP has adopted a quality management system model derived from IWA 4 Quality Management Systems – Guidelines for the application of ISO 9001:2015 in local government.

If this is what you were referring to, from my perspective it is not a model that is consistent with ISO 13485:2016. And the obligations of a medical device manufacturer, for example, are quite different than the obligations of government entities running a compliance program.

My apologies if I have misunderstood, or perhaps have not yet found the documents you are referring to.

I do think the MDSAP documents are interesting to look at to "get ideas" to aid in the development or improvement of QMS documents for any type of organization.

 

[Edward Reesor]

Hey Sam,
The URL you linked has a different number but was a link to the main page. Yours had the ending of UCM377582.pdf whereas the ones I were referring (probably buried in there somewhere, ended with:
UCM375697.pdf
UCM535976.pdf

That being said, I agree with you completely. Often our 13485 process is much more rigorous than what the government agencies ask for, however the information I was told was that the notifying body was using these MDSAP documents as templates for their audit checklist. My understanding is that the MDSAP checklist is the whip we have to jump to. Folding the new 13485:2016 expectations into that model is the way we plan on going.

One inconsistency we have had to respond to several times is that we chose to apply the highest standard to our SOP's that would exist among the several regulations that we conform to. For example, if a complaint response is 30 days in one jurisdiction, 60 in another and 90 in a third, we chose 30 days to cover all cases. It has been humorous to explain to the 90 auditing body why we go with 30 days when we can take 90.