Cybersecurity for Medical Devices - Draft Guidance

Cybersecurity (where required) -- September 13, 2016:

“ Postmarket Management of Cybersecurity in Medical Devices – Draft Guidance …”, dated January 22, 2016:

• Applies to devices susceptable to unauthorized access / vulnerabilities …
• Include cybersecurity in the product Risk Analysis (ID of threats / vulnerablities …) – Risks to          “essential  clinical performance”, both controlled and uncontrolled;
• Includes postmarket monitoring, assessing, detecting, impact determination, disclosure, deployment, et al;
• Incorporate NIST’s (included in the Guidance Appendix’s)  Identify, Protect, Detect, Respond,  and Recover;
• Device manufacturer is responsible to address (tied to 820.100 by FDA);
• Patches = design changes (820.30); not usually subject to FDA review; are “device  enhancements”, not “recalls”;
• But subject to K97-1 analysis by manufacturer (K-97 is now two Guidance documents on changes to a device and the 510(k)); and
• Require ‘validation’ (sic).

-- John E. Lincoln      jelincoln.com

Updated 09/06/2023

IEC 62304 Software Lifecycle Issues

IEC 62304  Consideratons -- September 13, 2016

International Electrotechnical Commission (2006). “Medical Device Software – Software Lifecycle Processes”; IEC 62304 

[Note:  Applying the FDA SW guidance documents ensures compliance with IEC 62304 – 62304 adds more specifics to lifecycle considerations -- “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices”, dated May 11, 2005, see Table 3 --

https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm089593.pdf ]:

•       Does not specify the content of the documentation to be developed.

•       Show traceability through all the elements; no set format specified.

•       Does not prescribe a specific lifecycle model – Waterfall, Iterative, Evolutionary.

             Up to company to define / document.

•       FDA accepts compliance to IEC 62304 as fulfilling the SW Development requirement of their

Guidance document (JEL - circular reasoning)

•       The software is classified into three classes in IEC 62304:

•       Class A: No injury or damage to health is possible;

•       Class B: Non-serious injury is possible;

•       Class C: Death or serious injury is possible.

                    [Remember FDA’s Minor, Moderate, and Major]

 INTERNATIONAL IEC STANDARD 62304 – Documentation Requirements (note similarity to U.S. FDA's Guidance Document on Device Software Documentation for 510(k)s):

Software Documentation		Class A		Class B		Class C
Software development plan		Must contain contents to sections IEC 62304:2006. The plan's content list increases as the class increases, but a plan is required for all classes.
Software requirements specification		Software requirements specification conforming to IEC 62304:2006. The content list for the software requirements specification increases as the class increases, but a document is required for all classes.
Software architecture		Not required.		Software architecture to IEC 62304:2006. Refined to software unit level for Class C.
Software detailed design		Not required.				Document detailed design for software units.
Software unit implementation		All units are implemented, documented and source controlled.
Software unit verification	Not required.		Define process, tests and acceptance criteria. Carry out verification		Define additional tests and acceptance criteria. Carry out verification
Software integration and integration testing	Not required.		Integration testing to IEC 62304:2006.
Software system testing	Not required.		System testing to IEC 62304:2006.
Software release -- John E. Lincoln	Document the version of the software product that is being released.		List of remaining software anomalies, annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors. jelincoln.com