Quality Systems (Part 4): Standards-centric vs. Product-centric

In the 4th part of this series, we are going to talk about the differences between a QMS that is standards-centric and one that is product-centric.

Share this
Share this

In the 4th part of this series, we are going to talk about the differences between a QMS that is standards-centric and one that is product-centric.

A product-centric QMS is created and structured based upon the development and production of a specific product or device family. This is an intuitive approach because that product or device family is typically what the company that created it knows best. It feels (and often is) efficient, as long as that product or device family remains consistent – a growing rarity in today’s fast-paced and merger/acquisition environment. Still, a product-centric QMS needs to demonstrate compliance with applicable standards, which is accomplished by mapping the QMS elements to the standards and performing gap-analyses to ensure every nuanced aspect is addressed. Companies may have this type of QMS because they have designed and manufactured their product for a significant amount of time, even well before the creation of the standards. In specific scenarios, as suggested previously, this process can and does work out well for many companies within the industry. However, some of these companies can get into a bind when they acquire or pivot to a new product line and are forced to either revamp their QMS or figure out how to integrate their new product with another product’s QMS. Such integration from a product-centric approach can inadvertently apply methods, guidelines, or rules – particularly those who have become culturally ingrained – which may be unnecessary or even burdensome for newly introduced products.

In contrast, at Velentium, we created a standards-centric QMS. Our quality procedures are based upon and structured by adherence to industry standards, specifically ISO 13485, ISO 14791 and IEC 62304. This approach ensures comprehensive mapping to the standards, which regulatory bodies appreciate, and also equips us with a common language to use with our clients and diverse associated teams. Not only do we adhere to definitions and terminology in the standards, but we also resisted the temptation to create our lexicon of new Velentium- or team-specific jargon terms. If every company creates its QMS with a different organization, conditions, divisions, sub-documents, and procedures, it causes confusion or delay among teams – a needless inefficiency in today's rapid distributed development culture. Because we leverage these standards, our clients know exactly where to find and how to understand detailed technical information within our QMS and within the Design History Files (DHFs) we provide or co-develop with each client. This allows for easy identification and avoids deciphering and translation of the content itself. Everything is structured around the standards – they become the lingua franca of medical device development. Many of our clients are startups or small businesses which do not have an established QMS, and our QMS provides an inexpensive way to hit the ground running while retaining flexibility and portability to pivot as-needed within the development cycle.

We also create and support a diverse range of products, including varying stages within the product lifecycle based upon a client’s needs. This would be challenging for a product-centric QMS. Since we did not create our QMS around existing product processes, but instead around industry standards, each new project can be completed according to its essential needs and not those of an unrelated design. This also provides an increased form of privacy for our clients: quality for each project is managed according to that project’s specific needs, eliminating unintended project cross-pollination.

We also work with large, well-established clients who have mature, product-centric QMSes. Because our system is standards-centric, our QMS is easily overlaid onto the client QMS’ applicable standard map. This allows smooth interaction, bridging, and translation because the client has already performed that task.

At the same time, we fully understand the necessity for product-centric QMS aspects at the appropriate levels. While at the top level our QMS is based around ISO 13485, the products we help design or manufacture may have product-centric components. But even then, we utilize standards-centric approaches wherever beneficial, such as developing neurostimulators with the validated risk mitigations of ISO 14708-3, a product standard. Standards are becoming ubiquitous and continue to improve with time and use, being refined by stakeholders for efficiency. So once again, we encourage everyone to leverage validated standards to accelerate time-to-market and reduce healthcare costs.

Our next post will cover why designing a lean and straightforward QMS is hard, but worth it. If you’d rather not wait, click here to download our QMS white paper.

If you would like to be notified when these posts go live, please subscribe for up-to-date email alerts.

Prev Post
Next Post