Regulatory Document Structure For NPI

I would like to get some input regarding the regulatory path,my current thinking is to capture the

Regulatory Strategy:
Document that aligns the regulatory activities to bring a new product to market with the business strategy and provide overall definition and direction to the project team for the product being developed by identifying the important regulatory elements to be addressed to market the device.

Regulatory Plan:
That describes the specific steps and action required to successfully meet the regulatory strategy objectives. It contains the specific elements required to assemble the regulatory submission. Some key components might include: specific country regulatory references, a list of guidance and standards to be used, predicate devices and comparisons, a matrix of claims and the supporting data, labeling, specific pre-clinical and clinical reports, literature references and information or commitments from pre-submission meetings with regulatory agencies.

Registration Strategy:
List of target countries and the time take the submission route etc

Questions:
1. Is this a good approach?
2.what will be the output for the regulatory plan...?

It would be of great help, if you can share with me the Regulatory document structure and a way to approach this maze?

Thanks

 

Light bulb moment:
Q2. Answer output: Regulatory report!

 

Despite this thread being in the FDA 21 CFR 820 sub-forum, I don't believe there's any specific requirement for any sort of "regulatory plan" or "regulatory report"...although I guess this could be incorporated into the design & development planning.

The question to really ask is: what is the value to you (and your organization)?

 

The value to our Organization: Clear business strategy which is cascaded down and translated as objectives and goals for different cross-functional team (in this case the RA objective) to achieve the goal ( i.e registration with regulatory agency).
The Value to the RA team: Clear picture of the regulatory drivers in order to fulfill the goal of registration following relevant regulatory requirements, applicable Standards and Guidance documents.

After I posted this question, I had a think overnight and now I feel I am confident about the needs of our business and a suitable structure to cater that needs. Thanks Mark for making me introspect and reflect on my question.

 

Hi, at an early stage in the R&D process we produce a very simple Regulatory Plan (attached). It has a couple of purposes, a) bring RA department into the process as early as possible and avoid last minute surprises, and b) it allows us to generate a "Pre-Sub" to FDA and get a response before the validation work starts.

Its been common in the past to get the response from FDA after the validation is underway. If any changes in validation are required as a result, it tends to be seen as "RA's fault", whereas if it is in very early, we can feed FDAs thinking into the validation plan.

 

@Vintage Goose - thanks for sharing that plan, I like the idea. One of the challenges I continue to see is defining the standards to which the product is expected to comply; e.g., 60601 (and the version, all the amendments, corrigenda, collateral standards, ...). I've worked with some test shops that provide great help on this. Just curious how others manage.

 

My approach for the Standards where using the different regulatory agencies consensus standard database ( Ex. FDA. Health Canda, PMDA etc) and IMDRF which has got the Recognized standards for different country as input, (http://www.imdrf.org/documents/documents.asp) for compliance.

Yes, I do acknowledge the changing climate in the Standards world i.e managing product development when standards change, transition period according to the FDA draft guidance (refer attached)



My 2C's, when a manufacturer registers the product and market them they comply to a set of standards and if there is any major changes in regulations/ law which can directly/ in-directly change/ add new scope to the standard, then we perform a risk assessment and take necessary actions (i.e LTF stating the rationale /justification of applicability the change etc or perform a test and update the doc register)