
Medical Device Design Documentation Risk Management, Verification & Validation (V&V), and Standards Tips
Zig Ziglar said “Some of us learn from other people’s mistakes and the rest of us have to be other people.” The aim of this article and my previous blog on Documentation Planning, Input, and Architecture tips is to try and prevent readers from being “other people”.
Below are three Risk Management, Verification & Validation (V&V), and Standards tips for Medical Device Design Documentation that anyone developing an early stage medical device should adopt. They make the transition from prototype to product less effort, reducing development timescales and cost.
Regulatory
As mentioned in an earlier blog, Medical Device products are classified by the FDA according to Risk – Class I is low risk, Class III is the highest risk. The FDA requires that Class II devices or higher, certain Class I devices and unclassified device follow Design Controls, as specified the Food, Drug and Cosmetic Act, Quality System Regulations, specifically 21 CFR 820.30. Similar requirements are specified in ISO13485 Section 7, Product Realization, in particular section 7.3. If you have heard of ISO9001, then 13485 is the equivalent for Medical Devices, and is the mandatory Canadian and European standard for Quality Systems for Medical Devices.
Documentation Tips
Reviewing the FDA 21 CFR 820 QSR regulations would be time well spent for anyone developing Healthcare technology, as it sets the required groundwork.
Risk Management
Risk Management can be difficult for engineers to understand, since one is taught at University to automatically design out hazards (like using insulating enclosure rather than metal), or design in mitigations (like fuses or watchdog timer for software), as part of good design practice. However, the purpose of risk management is to systematically identify all risks to the operator or patient from using the device, quantify those risks, and then implement mitigations if the risks are deemed too high. The Architecture and Requirements Documents are reviewed, but we assume that there are no safety features present at all in the design, imagining what could happen to the operator or patient, then ensuring the safety features are implemented and effective as part of verification. I don’t have space here to go into detail, but ISO14971 specifies the systematic process to be followed, which even includes recording hazards that do not apply. Resulting mitigations are inserted into the Technical Spec, and formally verified for safety.
Note there are many risk management webinars available, some for free, and an hour spent attending one of these would be well worth the effort.
Verification & Validation (V&V)
Formal V&V is often considered tedious and time consuming, but is essential for Medical Devices. The aim of Verification is to confirm the technical specifications have been met. When we said ’20watts at 4Mhz’ in the Technical Spec, the Verification Protocol defines a suitable test procedure, the verification data confirms this test was undertaken, and the verification report confirms all requirements in the technical spec have been met. Note the risk mitigations must also be verified for effectiveness, such as fuses, over temperature shutdown etc.
Validation is confirmation that the User Requirements have been met, and the device does what the Intended use says it does. Engineers are generally even worse at validating than verifying, but the FDA is especially interested in validation activities. Validation usually consists of pre-clinical and clinical validation, whereby preclinical validation follows a protocol (like verification), and may require a focus group to hold, switch on and use the device according to the protocol, which documented as Usability Validation report. Clinical validation is performed with clinical studies to demonstrate effectiveness, with a corresponding Clinical Evaluation Report.
Standards
The good thing about Standards is there are so many to choose from, the other good thing for consumers is compliance is not optional. A basic understanding of the standards that your device must comply with will go a long way. I already mentioned ISO13485 and ISO14971, but here are a few super important ones, left as an exercise for the reader to review and determine applicability (most electrical medical devices with software must comply):
ISO10993-1 – Biological Evaluation of Medical Devices. A colleague posted more on this in an earlier blog.
IEC60601-1 – Medical Electrical Equipment: General Requirements for Electrical Safety and Essential Performance. Tips on this were given in a previous blog.
IEC60601-1-2 – Medical Electrical Equipment: Electromagnetic compatibility. A colleague posted tips for EMC compliance in an earlier blog.
EN62304 – Medical device software – Software life cycle. How to develop software for medical devices – very different from AGILE methods. Also see UCM089543 – Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, which is a compliment to EN62304 by the FDA.
IEC62366 – Application of usability engineering to Medical Devices. A colleague posted on usability engineering in an earlier blog.
Conclusion
The more rigour applied at an early stage, the easier the transition into an actual product will be, reducing development costs and timescales. With a good document base, it is much more straightforward to take prototypes to a product. One can start product realization much more quickly without requiring a long ‘Product Definition’ Phase.
Vincent Crabtree, PhD is a former Regulatory Advisor & Project Manager at StarFish Medical.
Image: wpclipart.com