Premature Enforcement of CDRH’s Draft Cybersecurity Guidance

By Allyson B. Mullen –

Earlier this summer, CDRH issued a new Draft Guidance for the Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (the “Draft Guidance”).  We have previously posted on the Draft Guidance here.  As noted in our earlier post, we considered the Washington Post’s assertion that the Draft Guidance imposed new “tightened standards” which would “allow the FDA to block approval of devices if manufacturers don’t provide adequate plans for protecting them” to be a bit dramatic.  However, it appears as though the Post may have been right. 

We have learned through industry contacts that even before the comment period has even closed on the Draft Guidance (closed on September 12, 2013), FDA has already invoked it as a basis for rejecting at least one 510(k) submission under its relatively new “Refuse to Accept Policy for 510(k)s.”  FDA, Guidance for Industry and FDA Staff, Refuse to Accept Policy for 510(k)s (December 2012).  The particular 510(k) refuse to accept notification that we learned of came less than two months after CDRH issued the Draft Guidance.  As anyone in industry knows, at that point the applicant is usually putting the final touches on the submission, not completely overhauling the software design to address a draft guidance document.  Therefore, it seems unreasonable (let alone unlawful) for FDA to impose compliance with a draft guidance document as part of its Refuse to Accept Policy.

As discussed in our previous post regarding FDA’s Refuse to Accept Policy (here), we raised the concern that in order to assess the “completeness” of a 510(k) submission, the reviewer may perform a substantive review.  The checklist in the Refuse to Accept Policy for a Traditional 510(k) (the “RTA Checklist”) includes three specific questions with respect to software: 1 – does the submission contain a statement that the device contains software or not; 2 – does the “[s]ubmission include[] a statement of software level of concern and rationale for the software level of concern;” and 3 – is “[a]ll applicable software documentation provided based on level of concern identified by the submitter, as described in Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, or the submission includes information to establish that the submitter has otherwise met the applicable statutory or regulatory criteria through an alternative approach (i.e., the submitter has identified an alternate approach with a rationale).”  Refuse to Accept Policy at 35. The RTA Checklist never mentions the Draft Guidance.  Thus, during the acceptance review of this particular submission, it appears as the reviewer must have performed at least a cursory substantive review to determine that the 510(k) was not sufficiently complete due to its failure to address the Draft Guidance. 

It is important not to forget that the standard for 510(k) clearance is whether the device is substantially equivalent to a predicate device, not does the device comply with FDA’s new Draft Guidance.  However, as FDA issues more and more policies and guidance documents, the standard for 510(k) clearance seems to move further from being equivalent to a device currently on the market to meeting FDA’s new heightened standards, including those communicated through draft guidance documents.

In sum, it seems as though devices which contain or use software will not just have a more difficult time getting cleared based on the Draft Guidance, but applicants may have difficulty just getting their 510(k) submissions accepted for review.  Equally, if not more, concerning though is FDA’s expansion of the Refuse to Accept Policy to require compliance with draft guidance documents not even specifically referenced in the RTA Checklists.