Tuesday, September 13, 2016

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






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; and
  • Require ‘validation’ (sic).
-- John E. Lincoln      jelincoln.com