Bringing Legacy Devices Into Compliance

There are no standard guidelines for changing legacy medical products, but there are proven approaches. The best of these include the expectations of business, customers, and regulators. Assessing the state of a device when planning product improvement must include device performance, design documentation, and the impacts of change. Addressing project-risk factors during planning and safety risk throughout will more likely lead to a successful upgrade.

 

To illustrate, let’s say a recently acquired product needs design changes. The marketing department says new software will put the product ahead of its competition. How can we plan a new release so the product complies with FDA regulations, guidances, and our own SOPs?

 

First consider project risk and safety risk. Safety risk is the chance a device might harm a patient, operator, or bystander. Project risk factors are those that cause the project to miss objectives, such as technical and compliance challenges.

 

Then there is compliance risk. Many fail to consider, for instance, whether or not documentation will meet regulatory expectations as defined by regulations, design guidance, and company internal procedures.

 

Hardware changes can affect many functions. Each must be considered in a risk evaluation to determine its impact and how it affects the project. Therefore, considering each change, project risk is assessed as a function of the complexity of the changes, the ability of engineering to meet the marketing requirements for the project, and the likelihood that something else won’t be compromised in the process.

 

Document compliance for this legacy product reveals other risks. Suppose product-development procedures were recently updated, but, unfortunately, the current product documentation was developed under a vastly different set of procedures. Changing the current set of documents is easily done, provided the document deliverables for the product do not need rewriting. Project risk is now heavily impacted by engineering’s ability to meet design-compliance requirements for the project as well as the technical risks of each change. 

 

Before changing the code and modifying existing design documents, address document-compliance risk. When changing existing designs, follow design-controls regulations, including design planning, inputs, outputs, review, verification, validation, transfer, changes, and history file. There are no regulations that address legacy design, nor is there a “grandfather” clause for addressing the impact on the existing design-history file when making continuous improvements to the design control process. But the activities for a change or improvement to a product must follow similar process steps as those for new-product development.

 

Design documents include those that describe what the product, system, sub-system, software, or component does, or how the design does it. Document statements that describe what the design change should do are called inputs, and documents describing how the design is implemented are design outputs.

 

Assessing project risk comes down to understanding the full consequences of changes and assuring they are made correctly, including knowledge of how they relate to customer needs. The input requirements impacted by each change should include the targeted performance level and the interface constraints at the level of design where changes are made. Measurements help determine if the project risks were addressed. 

 

When assessing safety risk, consider hazards that may be affected by the change, the rationale for the change, and a description of the design solution. Without a clear understanding of the requirement for the changes, it will be difficult to determine if the product has addressed safety.

 

The best approach to reduce uncertainty depends on what currently exists. The amount of documentation that should be reverse engineered, (retrospectively created) is a function of project risk, or technical complexity of the change. Documentation should be revised or created to give developers adequate assurance to perform development-solution tasks without undue uncertainty. Therefore, the method of addressing documentation compliance risk is based on the project risk.