Regulatory Open Forum

 View Only
  • 1.  eQMS implementation

    This message was posted by a user wishing to remain anonymous
    Posted 13 days ago
    This message was posted by a user wishing to remain anonymous

    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. 



  • 2.  RE: eQMS implementation

    Posted 12 days ago

    Hello Anon

    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.



    ------------------------------
    Anne LeBlanc
    United States
    ------------------------------



  • 3.  RE: eQMS implementation

    Posted 10 days ago

    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. 



    ------------------------------
    William Coulston PMP, MS, RAC
    Director of Quality & Regulatory Affairs
    Rochal Technologies
    San Antonio TX
    United States
    ------------------------------



  • 4.  RE: eQMS implementation

    Posted 10 days ago

    Anon,

    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.



    ------------------------------
    Robert Blanks RAC
    VP, Regulatory Affairs and Quality Assurance
    [Ardelyx]
    Auburndale MA
    United States
    ------------------------------



  • 5.  RE: eQMS implementation

    Posted 10 days ago
    Edited by Kevin Randall 10 days ago

    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 Consultant
    Ridgway, CO
    United States
    © Copyright by ComplianceAcuity, Inc. All rights reserved.
    ------------------------------



  • 6.  RE: eQMS implementation

    Posted 9 days ago

    "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.

    Ginger



    ------------------------------
    Ginger Glaser RAC
    Chief Technology Officer
    MN
    ------------------------------



  • 7.  RE: eQMS implementation

    Posted 9 days ago

    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.



    ------------------------------
    Kevin Randall, ASQ CQA, RAC (Europe, U.S., Canada)
    Principal Consultant
    Ridgway, CO
    United States
    © Copyright by ComplianceAcuity, Inc. All rights reserved.
    ------------------------------



  • 8.  RE: eQMS implementation

    Posted 10 days ago

    Hello, 

    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. 



    ------------------------------
    Stephanie Mantooth
    RA Specialist
    Bio-Techne
    Austin TX
    United States
    ------------------------------



  • 9.  RE: eQMS implementation

    Posted 10 days ago

    Hello Anon,

    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!

     



    ------------------------------
    Heather Tudor
    QRA Manager
    Biochrom Ltd
    Cambridge
    United Kingdom
    ------------------------------