Search This Blog

Tuesday, March 13, 2018

Does a QMS have to be static or can it be agile as well?


The QA department is like a zombie island. We all know it’s there, but we don’t want to go there. They seem to be living on dead paperwork. They have a thing called a QMS. It comes with rules and procedures, which never truly reflects the real way of working. But it’s just too much effort to change them…



Sounds familiar? Not how it should be, but unfortunately true for quite a lot of companies.

But does it have to be that way?

Is there no way to move your QMS from being this solid, static, non-flexible thing that only a few people know how to operate in, to a flexible, adaptable tool that actually helps the company to function in a better, more harmonized way?

In short, can a QMS be Agile?

First of all, let’s set the baseline on what we understand by Agile. For all you software developers out there, you know what we mean. For those who are less familiar, here it is in super simple language.

Agile is a way of working where you break up the big task into smaller pieces. This allows you to create, evaluate, release and improve faster. You don’t deliver everything at once. You work in bits, prioritize and add value over time. And yes, you can change your plans at any time as this way of working allows you to incorporate changes fast.

So let’s do the exercise. Is it possible to work in this way and still have a QMS that is compliant with standards like ISO 13485?

If you look at a distance to what is expected of a QMS, everything needs to be done according to the Plan-Do-Check-Act principle and needs to be controlled.

Isn’t that what we just explained for Agile?

You look at the big picture and break it up into smaller, comprehensible tasks which can be tackled separately but in parallel. That requires planning and understanding.

Instead of having monster procedures covering a lot of different processes and their corresponding forms, templates and so on, you could try to break this up into smaller pieces, for example: different processes, different work instructions, different forms, different templates.

Each of them could be reviewed and released individually, right? Yes, they could. As long as you have good traceability between all of these different items in place. A decent version control makes sure that you keep track of which version has been released and which one is still in draft.

So it’s possible to break up big procedures into smaller pieces which do allow faster review.

Another advantage of having smaller items in your QMS focusing on one specific process or one specific template is that it’s easier to trace the information one needs and to implement that information. Even training on a specific process all of a sudden becomes less complex.

Not to mention audits and CAPAs. Audits could become much leaner and faster if they focus on more specific processes. Same as for follow-up actions coming from those audits or any other input that would require a CAPA.

Another principle of the agile method is that people take accountability for their activities and tasks. Translating this to an agile QMS, the QMS belongs to the company and should be part of everyone’s daily way of working without any special effort. This is perhaps the most challenging part of converting a static QMS to a dynamic, agile QMS.

Looking at requirements from ISO 13485, it actually says everyone needs to know their responsibility and authority, but it’s not only in terms of authorizations within the organization, it’s also about responsibility and authority within the QMS and the described processes.

Who is responsible for implementing a certain process? Who is impacted by certain processes? Who can change templates? Who needs to use them?

This requires that all information, both content and also responsibilities and impact, need to be easily accessible and searchable by everyone. In this way, you avoid people having to dig through a pile of procedures, only to find that the information that they are looking for is not there. Having both the responsibility for a process clearly defined, as well as who is impacted by this process, makes it easier for people to take ownership and contribute to making sure the QMS is reflecting the real way of working in the company while keeping an eye on compliance.

How about fast approval to allow changes more easily? It’s a must if you want people to take ownership, actively make use of the system and contribute to it.

It’s not always easy to get documents approved. If you want to have an agile QMS, you have to find a way to have a smooth review and approval routing process. The most convenient way to do this will depend on your organizational structure. However, not depending on papers that have to travel from one desk to another or even worse be scanned, printed, signed, scanned and emailed, will help already a great deal.

And last, but not least, what with all the paperwork? Isn’t that contradicting the principles of agile methods? Not to mention killing forests and filling landfills with excess paper!

Documentation for the sake of documentation is indeed not the way to go. But that’s not required for an effective QMS. On the contrary, you need to document certain things to be able to plan, to check, to act and to make further plans. When you keep documentation and records as simple as possible, without losing the necessary content, it serves its purpose. Some adaptations might be needed when you want your QMS to be more dynamic. Again, it’s worthwhile investigating the best tools to help you with this.

A QMS can be agile. Our QMS is agile! Our QMS provides the proper mindset and the correct set of tools to suit your organization. Once you convert from a static system to a dynamic one, you will discover that QMS is not holding your company back, but helps push it forward.

Thursday, March 24, 2016

ISO 13485:2016 - the new revision has arrived!

What changed?

A lot of details and clarifications were added in many places. The most important are these:
  • You are supposed to apply a risk based approach to all processes not only the products and product development.
  • The design and development requirements have changed significantly, for example new requirements for the design transfer and design development files have been added.
  • You have to validate software used to maintain your quality system

Risk based approach for processes


The standard requires now that all processes which are defined in the company shall be reviewed for potential risks. As a result of this the processes might be adopted to minimize the risks, new processes might be defined or the monitoring of the process might be changed. The risk assessment and changes of course need to be documented to have proof that the risk management has been done for the processes.

To define good processes you should at least

  • Define and document the process itself (4.1.2 a)
  • Define and document the input and output of the process, as well as references to related processes (4.1.2 c)
  • Define and document methods to control the execution and results of the process (4.1.3 a)
  • Perform a risk control for the process (what can go wrong, what are the effects if it goes wrong) (4.1.2 b)
  • Document the identified risks
  • Define and document the risk controls you can come up with
  • Implement the risk controls by changing the process or the processes controls

Design and development requirements changes

For the design and development planning the standard now requires explicitly to define the methods used to ensure the traceability from design input to design output for each phase.


For the design and development inputs it now states specifically the usability requirements must be documented and that is must be possible to validate or verify the requirements.


For the design development verification and validation it is now required to include verification methods, acceptance criteria and, as appropriate, statistical techniques with rationale for sample size into the plans for verification and validation.

A new sub clause has been added for the design and development transfer. It requires that a procedure is established describing how to transfer from design and development to manufacturing. This procedure must describe how to ensure that the design outputs are suitable for production and how production capabilities can meet the requirements for the production.

Design and development changes should now also be evaluated for significance of the change to function, performance safety, etc. as well as impact on risk management input and output, products
A new sub-clause now states that design and development files now should be maintained for each medical device type. The file should reference or include the records which show the conformity to the above.


Validation of tools used to maintain your quality system

Matrix Requirements Medical can of course be validated according to ISO 13485:2016 and FDA 21 CFR 820. We support this process by providing our own verification and validation results as well as templates which make it easier for you fill the gap: You need to document the 'proof' that it fits your own procedures and processes. This support with additional validation templates you can adopt to your own needs. See also https://matrixreq.com/news/#20150701

Thursday, March 17, 2016

IEC 62304 2015 - impact for Class A software

The 62304:2015 updates change a few things for class A software. While it makes it easier to segregate between class A and class B/C, it adds a bit of documentation work.

Segregation


It was now clarified that a software system can stay class A if it contributes to risks but there are risk controls outside of the software system (either in hardware or for example also class B/C software running on another processor).

The SOFTWARE SYSTEM is software safety class A if:
– the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in
unacceptable RISK after consideration of RISK CONTROL measures external to the
SOFTWARE SYSTEM.


Additional Requirements

Applying new new version comes with a price for the class A software you need to do the following if you choose to use IEC 62304

  • there must be tests cases for the software requirements
  • you need to manage issues found during testing
  • you need to do regression tests after changes
  • you need verify that the testing approach is god (e.g. that there is a complete and documented traceability to software requirements)
  • you need to maintain the test records (e.g. with pass fail information, tester etc.)
  • before releasing the device you need to make sure that the tests have been all done
  • you need to evaluate and report known issues when releasing the device
  • and finally analyze change requests before implementing them

Conclusion

The above actually looks like a quite a bit of additional work but if you follow any best practice or common approach for software development you will do most of the above work anyhow.

It seems the only exception would be highly agile processes where you move from one user story to the next until you think you are done. But in that case you can still easily extract some software requirements while you move along and link them to the user stories which you use for verification and you will be halfway there.