To me, it would make sense to grandfather old documentation into the new system, as it is. In my previous experience when Quality Systems were changed, it was required that all previous, in-process projects be updated to fit the new system. In hindsight, this seemed like the direction to go since it would save time later, but ultimately it did not. A great deal of time and money was spent on updating the information from in-process projects but unfortunately, a majority of these projects did not make it through the pipeline to production or launch. Updating these files only caused a waste of time that could have been better spent on other activities. Unless there is a major reason to change to the new Quality System (for example, changing from a paper process to an electronic one), it may not be efficient to spend time on updating paperwork for products that may not make it to market.

Hi All,

I think the best way to make this change is to grandfather in some projects, but making a specific completion percentage for the projects. For example if a DHF is complete and Design Transfer is complete then the project would be grandfathered into the old system, but if it were in earlier stages than that it would not be. This would avoid significant delays on projects that are basically completed on the old quality system, but still allowing for the new changes to be implemented.

-Andrew Nashed

Hi All,

This situation is usually handled on a case by case basis. In some cases, when the regulation is changed or updated, guidance documents are issued to explain the timeframe of implementation and the criteria that must be met for devices to be grandfathered into the old regulation. From my experience, if the regulation changes before design freeze, the manufacturer MUST implement the new regulation and no grandfathering is allowed. The situation is different if the regulation changes after design freeze. In some cases where the regulation changes before the device is filed for approval with the regulatory agencies, A gap analysis is required with a rationale of whether the new regulation will be implemented or not. If the regulation changes after the approval is obtained, based on the regulation, the manufacturer may be eligible for grandfathering.

-Fady Khalla

I agree that is a change in the quality system occurs, the projects would have to be evaluated and see if the change will completely change the parameters of the project or allow them to be grandfathered in. If a change would need to be created between multiple project, it is imperative that the company creates a strategy that provides different details and cascades from upper management to the operators to maintain open communication of the change occurring. In addition, with any drastic changes, making time to properly inform via trainings or regular meetings will allow to employees to fully grasp the change with more confidence since they will have the correct tools to understanding what is occurring and why it is important, and what they can do to help with the process overall.

I agree with Fady that this should be a case by case scenario. Depending on how far along the products are. If it is not handled like that a lot of money and time will be spent and it won't be beneficial to anyone.

I feel that existing product and documentation should be grandfathered in, since the time and money to extend these changes could lead down a many different paths and endless changes, revisions and updates. Projects that have been started already should be assessed on a case by case basis. A risk analysis should be done to determine if these projects would ultimatly benefit or falter from these changes and their associated updates.

In my opinion, and as mentioned prior by some of the users, this situation is handled differently case-by-case. There are only certain situations when documents from previous product can be grandfathered into a new product, if and only if, the product is closely similar to the predicate. As an example, device A and device B, device B is the second version of device A, and they simply build upon the foundation of device A, the company can reuse the original documents since device B conducts the same actions but adds some more uses. However, as defined by the FDA, if the medical device is drastically different from the predicate, that would mean that the new device would be a brand new medical device and require new written documentation and testing etc. There are moments when grandfathering documentation from an old device and a new one can be problematic when companies uses resources to edit and revised old documentation. Sometimes for new product development, it is sometimes better to not grandfather in documentation.

At my company, we recently updated our design control procedures, and in the updated procedure there was a clause that said that this procedure update applied to newly chartered projects or projects where the team decided to migrate to the new version. I think it was smart that they added this statement, because it allows projects that were already chartered to continue using the old design controls, but for projects that were just started and the team feels that they would like to use the new procedures, it also gives them this option.

As previous posts have stated, the decision depends mainly at the situation at the time and the company’s policies. Depending on the stage that the project is at, the project can either be grandfathered with the previous system or if it had to updated for the new changes made. If the project has completed the DHF and Design Transfer, it would seem to make more sense and convenient to consider the project as grandfathered and use the previous system that was set. However, if the project is still in the beginning stages and there is a major change in the Quality System, then the project should follow the new principles. There are many other factors that also need to be taken into consideration when determining which system to follow.

Grandfathering a project due to changes in a quality system usually consider the following components: project scope (ex. changes to processes, documentation, drawings, validations) + area of grandfathering (document control, quality, engineering) + Date.

The date aspect is key because when moving over changes to a new quality system you are saying anything before this date may be scrutinized as it doesn't follow our new updated system changes. In reality there is no right time to have the cut off date from moving from the previous system to the new system as most companies have many high priority high impact projects going on simultaneously. I would believe, the best way to handle this challenge, is to outline all the projects that are being done and segregate them into which projects have the highest impact and priority. From there look at estimated date of completion of the projects. The highest impact and priority project with the furthest completion date, should be the date in which you move to the new system. This idea works for a company in which the time constraint to switch over is willing to be flexible to wait that length of time.