Being in the QMS consulting business, we get to work with all sorts of clients from various industries who want to implement or improve their quality management systems starting from various levels of maturity. Some have systems in place but are looking to make them more robust or more reflective of their processes, eliminating redundancies and bloat. Some – mainly startups – have no systems in place and are starting from scratch and come to us for guidance on how to get started. A small number of firms that we work with are still using paper-based systems, most are using some form digital documentation that is accessed from shared locations, and some are looking to transition to eQMS solutions. But many folks who engage with us see their QMS efforts as somehow being separate from their other business initiatives – a bit of a central theme throughout this article.
In clause 5.1.1 of ISO 9001:2015, the standard requires that ‘top management shall demonstrate leadership and commitment with respect to the quality management system by…ensuring the integration of the quality management system requirements into the organization’s business processes’. This simple statement is profound and sets the perspective for where a QMS lies in relation to a firm’s business processes. A QMS cannot be independent of and cannot be built, executed, or maintained parallel to business processes – the requirements of the QMS have to – note the use of the word shall from the standard – be integrated into the business processes.
In this blog, I am looking at the two most common misconceptions about what a QMS is that I see when we first engage with clients. The first, very common among medical device startups, is that a QMS is a set of product or process-specific documentation to support a product or process that they’ve developed in order to get certification or regulatory clearance. The second, which seems to be as commonly understood between folks looking for eQMS solutions as it is from many of the software companies that offer them, is that a QMS application or suite of QMS applications is a QMS. Both have a common and incorrect perspective on what a QMS is and thus try to begin implementation of their QMS while standing on the finish line.
What a QMS isn’t: a product or process-specific set of documents to support a product or process that you’ve already developed.
As I mentioned in the introduction, the misconception being explored here seems to happen most commonly with medical device startups, but that is purely circumstantial and the misconception could occur in any industry of any size – but medical device firms do have a couple of factors that I think aid in this being such a common theme among our client base: 1) there are a lot of opportunities in this space, which means there are a lot of startups looking for contracted help to get their quality systems off the ground, and 2) it is easy to confuse overall QMS requirements with regulatory requirements for the DHF and DMR when dealing with the FDA or with the comparable requirements for design and development files and medical device files when working with ISO 13485, discussed later in this section. This confusion leads to the misconception that the QMS is a set of documentation to support the product or process rather than understanding the QMS as a system of interconnected processes in which the documentation needed to support the product or process is an output.
Of course a QMS can be built as a product or process-specific system, if a single product or process exists within the scope of the quality management system, such as for a firm classified as a medical device manufacturer who only produces, packages, or labels a single product using a single process, but even if that were the case, the QMS still exists at a higher level than the set of product or process-specific documentation and will dictate how that documentation comes about – not understanding that a QMS is intended to be incorporated into all business processes at a macro level and instead viewing it at a micro level as a set of documents to support a particular product or process causes several of our clients to struggle for months and eventually rework their systems – sometimes post-certification – after they’ve truly grasped the idea.
Looking again at ISO 13485:2016, clause 4.2.2, the standard requires that medical device manufacturers ‘document a quality manual that includes…the scope of the QMS, including details of and justification for any exclusion or non-application’; the 1st clause of the standard, also titled Scope, includes language to qualify this requirement: “If applicable regulatory requirements permit exclusions of design and development controls, this can be used as a justification for their exclusion from the quality management system”. The reason that this is brought up here is that it clearly illustrates that the quality manual, as a core element of the documented quality management system and as represented in the illustration above, includes a defined scope including or excluding with justification whether a firm has design and development within it – and if design and development is included in the scope, all of the requirements as defined in Clause 7.3 would be applicable and required to be implemented.
Why this matters: the opening statement in Clause 7.3, housed in 7.3.1 General, states, “The organization shall document procedures for design and development,” and then continues with several requirements for design an development planning, inputs, outputs, reviews, verification, validation, transfer, control of changes, and finally culminating in the requirements for design and development files, also referred to as the DHF in the FDA QSR. Regarding design of processes, 7.1 is similar, albeit not having the same general introductory section requiring a documented procedure, the Clause also defines documentation requirements for process planning, conducting risk management, defining quality objectives and product requirements to be met through the process, necessary verification and validation activity, and necessary record keeping to ensure that resulting product from the process meets requirements. The output of this process planning activity would typically be kept in the medical device file, or DMR for folks working with the FDA QSR, as defined in 4.2.3 which states, ‘for each medical device type or medical device family, the organization shall establish and maintain one or more files either containing or referencing documents…including but not limited to…specifications or procedures for manufacturing, packaging, storage, handling and distribution; procedures for measuring and monitoring; as appropriate, procedures for servicing’.
The point is this: the quality management system is the core and is largely codified through the quality manual and associated documentation, as illustrated in the diagram above, and these core QMS documents dictate how the products and processes are designed, verified, validated, etc. The resultant documentation, such as DHF, DMR, and other various documents and records, are outputs of required QMS processes – as outputs, they can not come first with the QMS then built around them to support them. The user who completes product or process design and development and then chooses to build a QMS in support of their work is starting from the wrong origin point.
What a QMS isn’t: a software application or suite of applications.
I recently saw a meme posted on LinkedIn from a SaaS provider that said something like ‘bought a QMS, forgot to read the fine print’, with the body of the post elaborating using a fictional scenario in which a firm purchased an eQMS license and didn’t understand some of the fees that were associated with the licensing because they didn’t read all of the fine print. Aside from memes generally being a terrible way to communicate in what should be a professional setting, the message here also raises the inevitable question: how do you buy a QMS?
Right in the introduction of ISO 9001, the world’s most widely adopted quality management standard, it is said that ‘[ISO 9001] promotes the adoption of a process approach when developing, implementing, and improving the effectiveness of a quality management system…understanding and managing interrelated processes as a system contributes to the organization’s effectiveness and efficiency in achieving its intended results.’ – paraphrased from ISO 9001:2015 0.3.1
An interlinked set of processes essential for ensuring that quality products and/or services are produced and provided to your customers is not something that can be purchased off of a shelf or be licensed from a software provider; systems are designed and built for your specific purpose and within the context of your organization, or, as the standard says in the following paragraph,
“The process approach involves the systematic definition and management of processes, and their interactions, so as to achieve the intended results in accordance with the quality policy and strategic direction of the organization. Management of the processes and the system as a whole can be achieved using the PDCA cycle with an overall focus on risk-based thinking aimed at taking advantage of opportunities and preventing undesirable results.”
They must be done so in a way that meets the requirements of relevant standards and regulations, sure, but there are reasons why standards such as ISO 9001 are not very prescriptive in nature and why they emphasize the need for their requirements to be incorporated into business processes.
The software solution cannot be your quality system, but QMS software can surely be a valuable tool to bolster your existing system to improve its efficiency or efficacy, or be used as a tool to more effectively build a QMS from the ground up. I will certainly never downplay the value of using such solutions, as the benefits of using well-designed QMS software tools can have profound impact to the robustness and efficacy of your quality system – Isometric Consulting Group, LLC works as a partner with a large firm to implement cloud-based QMS and EHS solutions and can attest first-hand to the massive improvements that can be made as a result of using such tools as a crucial element of a firm’s Quality 4.0 initiatives – but the tools will always be tools used to build, sustain, support, and improve a quality system, not the system itself.
Implementations of such solutions in firms that understand this and use the tools to automate and improve their existing systems are the ones that are the smoothest as to where ones that have no existing systems and assume that one can be purchased and implemented without thought into the design of the system that the software is meant to bolster are the most difficult. Firms that utilize software with the understanding in former statement reap the most benefits as to where the latter firms are most likely to abandon their efforts and miss out on the opportunities for improvement in their system that could have been gained.
What a QMS is:
So what is a QMS? ASQ defines it this way:
A quality management system (QMS) is defined as a formalized system that documents processes, procedures, and responsibilities for achieving quality policies and objectives. A QMS helps coordinate and direct an organization’s activities to meet customer and regulatory requirements and improve its effectiveness and efficiency on a continuous basis.
ISO 9001:2015, the international standard specifying requirements for quality management systems, is the most prominent approach to quality management systems. While some use the term “QMS” to describe the ISO 9001 standard or the group of documents detailing the QMS, it actually refers to the entirety of the system. The documents only serve to describe the system.
Of note in that definition, a quality management system is a formalized system containing process, procedures, and responsibilities for achieving quality policies and objectives…while some use the term QMS to describe a group of documents – such as in our medical device example – or we could substitute this with referring to our software tool as a QMS for the latter example, QMS actually refers to the entirety of the system. How you design and develop a product or process and the documented outputs from this activity, then, is dictated by documented QMS processes – the QMS processes support the design and development efforts to produce the desired outputs, they are not developed in support of the outputs that already exist. The software tools that you use, likewise, are not your QMS, but can be valuable to automate or glean valuable insight about QMS processes and aid an organization to appropriate meet compliance requirements – but they will always be tools used to execute your QMS processes, not a QMS in and of themselves.