Currently, the Quality Department is leading a project to migrate from a paper-based system to an eQMS system, but they have done this without any input from users, such as regulatory, manufacturing, supply chain, engineering, etc. How important is regulatory oversight and input on implementing the eQMS system? I believe input from regulatory is required but wondering I am offbase.
When you says "required", I wonder if you have an SOP that requires it. I don't know of any laws defining a company interdepartmental communication process.
From a practical perspective, project managers are generally much more successful when they engage their stakeholders. Although, to be fair, I have seen reasonably successful implementations done by fiat, where an executive imposes a major change and leaves the various departments to sort out the details afterwards. You have to be careful about unintended consequences during the transition period, especially if the validation may not have been comprehensive, but it's manageable.
I agree with Anne completely. More communication is better than less. I think you should communicate your requirements to the Quality Department. The necessity depends on what you hope to do with the eQMS. Does regulatory want to iterate within the eQMS or does regulatory simply want to import documents into the eQMS as record keeping system?
We just finished an eQMS implementation and there are always surprises, good and bad. We learned things about the system's capability that we couldn't really know before the implementation.
Agree with Anne, there is no regulation that requires input from regulatory. However, as regulatory and quality changes are often intertwined (e.g. quality change may require regulatory input as to impact on filing, and regulatory must inform QA if HA approve the change so can be implemented.), I would highly recommend you work together in the implementation as needed.
In general, a key rule of designing and implementing any aspect of a QMS is to engage the input of affected stakeholders. If we instead design and implement the QMS in a vacuum without getting input from affected stakeholders, then it can alienate them and cause them not to support or cooperate with the QMS. This is not because of their stubbornness (sometimes it is, but oftentimes not). Instead, it is because the QMS impacts stakeholders' day-to-day operations. Thus, whenever we endeavor to insert a new paradigm into a stakeholder's world, we would be remiss if we didn't involve that stakeholder. I think this is one of the reasons behind ISO 13485 clause 5.5.3 (internal communication).
Regarding the involvement of regulatory affairs when documenting (establishing, implementing, maintaining) a QMS implementation: Ultimately, a QMS is a regulatory requirement in multiple jurisdictions. Thus, excluding the regulatory affairs team from a QMS design and/or implementation effort is in stark conflict with this reality.
For example, an ISO (or EN ISO) 13485 QMS must include many attributes that are tethered to regulatory requirements, not the least of which is its general requirement that the QMS is to be documented (established, implemented, maintained) in accordance with applicable regulatory requirements. Indeed, 13485's title is Medical devices - Quality management systems - Requirements for regulatory purposes.
In addition to these fundamental elements, there are also many specific aspects of the QMS that directly impact regulatory stakeholders. Some examples include design and development, risk management, post-market surveillance (e.g., complaint handling and adverse event reporting), change management, recalls, outsourced process control, and others.
The same dynamics exist with respect to the organization's other stakeholders too (e.g., manufacturing, engineering, etc.).
When a quality department fails to properly engage a QMS's affected stakeholders, it is a classic textbook failure that undermines the overall effectiveness of a QMS and gives quality a bad name.
------------------------------Kevin Randall, ASQ CQA, RAC (Europe, U.S., Canada)Principal ConsultantRidgway, COUnited States© Copyright by ComplianceAcuity, Inc. All rights reserved.------------------------------
------------------------------Robert Blanks RACVP, Regulatory Affairs and Quality Assurance[Ardelyx]Auburndale MAUnited StatesOriginal Message:Sent: 08-Feb-2024 17:27From: Anonymous MemberSubject: eQMS implementationThis message was posted by a user wishing to remain anonymous
"Regarding the involvement of regulatory affairs when documenting (establishing, implementing, maintaining) a QMS implementation: Ultimately, a QMS is a regulatory requirement in multiple jurisdictions. Thus, excluding the regulatory affairs team from a QMS design and/or implementation effort is in stark conflict with this reality.
For example, an ISO (or EN ISO) 13485 QMS must include many attributes that are tethered to regulatory requirements, not the least of which is its general requirement that the QMS is to be documented (established, implemented, maintained) in accordance with applicable regulatory requirements. Indeed, 13485's title is Medical devices - Quality management systems - Requirements for regulatory purposes."
Quoting from part of the previous response here (with which I generally agree with - more communication is better)... But I think the above is part of what ends up causing confusion, because it depends on what specifically the companies "Regulatory" and "Quality" teams are responsible for and expected to be the experts in. For instance, in many of the companies I worked for, and for some of my current clients, the "Regulatory" team mainly does pre-market submissions and device change submissions, while the "Quality" team is expected to be the experts on regulations such as global QMS requirements, post market reporting etc. Thus, despite the fact that "regulations require" something, in those companies "regulatory" would not be deemed required to weigh in because of the above, because the "quality" team is the assigned responsibility for it.
In other companies, "regulatory" would be responsible for these items and would need to be highly involved.
The challenge is many aspects of a business involve "regulations" but are not the domain of "regulatory" - think OSHA regulations, SEC regulations, EPA regulations etc. Now I did work at one (small) company in my life where "regulatory" included all that and more, but it is rare.
I think the challenge is that the QMS requirements are in various geographies "medical device regulations" and, in the case of the EU MDR, there seems to be an assumption that the "regulatory" function is responsible for it - even if not the case in many, many companies.
All that said, as intertwined as the Regulatory and Quality functions are these days, more communication is better, and as others have said - in order to successfully implement a QMS solution, all stakeholders should be involved. In fact, I would argue the system should be based on stakeholders REQUIREMENTS including those of regulatory, R&D, manufacturing etc etc....as well as quality.
------------------------------Kevin Randall, ASQ CQA, RAC (Europe, U.S., Canada)Principal ConsultantRidgway, COUnited States© Copyright by ComplianceAcuity, Inc. All rights reserved.Original Message:Sent: 12-Feb-2024 09:16From: Robert BlanksSubject: eQMS implementation
Ginger Glaser always has great insights. I'll add that for the ISO 13485 context (which now seems to be the prevailing QMS requirement globally), there is a built-in provision to assure that "regulatory requirements" doesn't become overblown with unintended regulations. Specifically, "regulatory requirements" are limited to requirements for the QMS and for device safety or performance.
Even disregarding the need for internal stakeholders input regarding user needs (which as already stated, is a huge mistake not to), you more than likely have a requirement to document a change impact assessment. At my company regulatory is involved in assessing the reporting requirement and the ability of the org to meet regulatory requirements with any substantial QMS change. This gets documented in an 2-3 page impact assessment and signed off on by RA and QA. If you are work in the US, EU, Canadian, Australian, SKorean, Swiss, UK or similar markets, you most likely do have this requirement. I can provide citations if needed.
I agree with Kevin and the other thread responders here on gaining input requirements from all stakeholder departments. The user requirement specification (URS) must be used to evaluate available eQMS software solutions and stakeholders should be invited to demo the possible software options to identify the best-fit solution.
These software solutions generally have customisable processes using the available templates. The stakeholders, as SMEs would need to build the processes which aligns best with their business activities. Additionally, as part of the software validation, user testing will need to be undertaken by each process owning department together with the relevant procedures.
Quality is the business owner of an eQMS and must have oversight of the developed software. However, in order to ensure successful implementation and continued use of the eQMS solution, stakeholder buy-in is a must!
Regulatory Affairs Professionals Society (RAPS)5635 Fishers Lane, Suite 400Rockville, Maryland 20852
firstname.lastname@example.org+1 301 770 2920
JoinMy RAPS DashboardLearn More