Hello all and welcome back to MedTech Compliance Chronicles. Following the previous two week’s posts about the requirements for planning for product realization, we are finally able to get into the meat of product realization: Design and Development. Design and development is one of the most important projects an organization will take on, particularly in the medical device industry. This post will cover primarily what is required in design and development from a documentation standpoint and what considerations are necessary for compliance with the US FDA and ISO 13485:2016. This post will not give a prescriptive design and development process or detailed explanation of the engineering concepts in design and development, as those topics are outside of the scope of this blog series.
The details of how you want to design your product is up to you. Specific tools and methods are not specified in regulation. What is prescribed by regulation are that activities are performed to ensure that your device is safe and effective for its intended use, with its intended patient population and that your organization is actually capable of producing it. This translates to having a logical, thought out design, testing your product to its requirements and providing the resources for production of the device.
Inputs & Outputs
Design inputs and design outputs are the bane of many engineering students first delving into an actual design project. For design inputs, it is most important that all possible considerations for the design are thought of as inputs. These will include your user needs, technical specifications, regulatory requirements specific to your product and outputs of risk management at a minimum. Essentially, all sources that provide requirements for the product must be considered and those requirements translated into design inputs.
Design inputs must also be unambiguous, able to be verified or validated and not in conflict with each other. This means that they must be as clearly defined as possible and must be considered both individually and as a whole. For example, an appropriate design input for a cylindrical object may be that its length be greater than 2” and its diameter greater than 1”. Another appropriate input for a similar object may be that its volume be no more than 1 cubic inch. Both of these are unambiguous and able to be verified. However, it would not be appropriate for both of these requirements to be put on the same cylindrical object because a cylindrical object that meets the length and diameter requirements specified by the first input would necessarily not meet the volume requirement specified by the second input. The completeness and interconnectivity of your inputs will be one of the more scrutinized aspects in review of your technical documentation, as they form the foundation for the entire design and development process that follows.
Design outputs make up the technical specifications of the product. For this reason, they must include acceptance criteria, i.e., how will it be verified that this output will be met? What tests will be done and what results indicate a passing result? It is also important to remember that design outputs include not just the specifications specific to the product but also the packaging and labeling of the product, process specifications for manufacturing the product and any other technical specifications related to producing the finished device. A good test to verify that your design outputs are complete is to see if they contain enough information to produce the product just by looking at the outputs. A complete set of design outputs should encompass everything from the specifications required for the purchasing of raw materials and components, the process requirements to manufacture the device and the packaging, handling and storage specifications.
The final requirement for design inputs and outputs is that they be traceable to each other. This means that each design input must be reflected in a design output and vice versa. This does not, however, have to be a one to one relationship. A design input may result in multiple design outputs and a design output may be the result of multiple inputs. As long as all inputs are traceable to outputs and all outputs the results of inputs, the requirement is met. In practice, this usually comes in the form of a table with design inputs on the left-hand side and their corresponding design outputs on the right-hand side.
Design Reviews
Design reviews are a particular requirement that tend to be ignored until it's time to submit an application for market clearance and you just start looking to check the boxes. This is where hatred for them tends to stem from as well. It is unfortunate too because regular, well executed reviews can significantly improve the results of any project. They are only a daunting task if left for the last minute. All that is required is that you review that the results of design and development are meeting the requirements (of the product, of regulations, etc.) and take any actions necessary to facilitate that. However, as will all things, the devil is in the details. All of the results of design and development must be reviewed, therefore, it is beneficial to do it in stages as the design progresses such that you don’t have to review 100’s or 1000’s of requirements in one meeting. As far as who is supposed to attend the review, it is required that representatives from all functions/departments involved with the design being reviewed be present as well as a person who does not have direct responsibility for the design being reviewed. Anyone else the company determines necessary, such as subject matter experts, may attend the review(s) as well.
Verification & Validation
Design verification and validation are where you confirm your device conforms to its requirements. Verification is performed for all design outputs. You must prove by objective evidence that the design outputs meet the requirements set forth in the design inputs, this is why each output needs an acceptance criteria. Validation is performed for user needs, it is where you prove your device is actually effective performing the functions it is designed to perform. Objective evidence is always best but not always possible for validation. Still, well designed surveys after use or simulated use by potential customers can give a lot of information. Whatever your approach, you must find some way of providing evidence that your device meets the needs of its users.
Both verification and validation are scientific processes by nature. They must be performed according to documented procedures with predetermined methods and acceptance criteria. All testing must also be performed on either final product or simulated (very close to, with no significant changes) final product and under appropriate use conditions if those conditions may affect the result. For example, a device that is supposed to work in combination with another device or a drug, the verification and validation activities shall include that other device or drug in the appropriate tests.
Depending on the risk classification of your device, you may also be required to perform clinical evaluation, which is a whole other set of regulations outside of the scope of this post. In general, for most class I devices you do not need clinical evaluation, for most class III you do and for class II it depends on what needs to be done to prove substantial equivalence.
Design Transfer
Often called transfer to manufacturing, the term began to fade with the rise of software as a medical device, design transfer is where you verify that your actual production capabilities are capable of producing a device that meets all of the requirements you have laid out. If it was not done along with the design process, this where you will formalize procedures for each process involved in production, specify settings on machines and train employees on all of the new processes.
Conclusion
Ultimately, how your design process is your own but it must output a safe and effective medical device. The requirements laid out are minimally prescriptive and really aimed at ensuring that every aspect of the design is adequately considered during the design process and that objective evidence is produced of the device actually meeting its requirements. Of course, it is easy to get caught up in the design process and forget that not everyone in the organization is an expert in what you have developed. You must not forget to adequately prepare your production capabilities for the new device you wish to bring to market.
Σχόλια