Regulatory Open Forum

 View Only

  • 1.  Software as Medical Device

    Posted 08-Feb-2019 13:58
    Hello!

    Hope you're all doing well.

    My firm's product is  a Software as a Medical Device. Their Design Controls are split into 4 parts: 2 accessories and 2 components.
    So subpart 1 has a separate set of design inputs and outputs Same goes for subpart 2, component 1 and component 2.
    Is this Multi-level Design Controls?

    This is the first time I'm coming across a split up Design Controls. Would this be acceptable for a 510 (k) and is this recommended?


    Thanks

    Regards,
    Anjali Nair

    ------------------------------
    Anjali Nair

    ------------------------------


  • 2.  RE: Software as Medical Device

    Posted 09-Feb-2019 03:16
    Anjali,

    I am sorry that not really following what you mean by multi-level Design Controls.  From a 510(k) submission perspective, there is one section 16 - Software where you need to have the software documentation outlined in the FDA guidance document.  You could have two design control streams or processes within your company.  How you present the information in the Software section of the 510(k) might get a little tricky and need to be well-defined so the FDA reviewer understands how the design process occurs for the SaMD.  If these 4 parts can all be done independently or the 2 parts done independently, then it will be critical in the validation portion to test how these all fit together.  The FDA is quite aware of interconnectivity, relationship of modules of software, and different software "talking" to each other.  A basic answer is split up Design Controls is fine for a 510(k) submission, it will just be important how your present the information to the FDA reviewer in the actual submission.  Remember as much detail as possible - companies do not like to give out confidential information readily, but this reviewer has never seen your product before, so there needs to be enough information and detail that you do not get an AI request that is 30 items long.

    ------------------------------
    Richard Vincins RAC
    Vice President Global Regulatory Affairs
    ------------------------------

    Original Message


  • 3.  RE: Software as Medical Device

    Posted 10-Feb-2019 06:17
    Don't overlook Richard's point about Design Validation, this step must include the entire device as seen by the user and cannot be split into multiple streams. Also if you Device is electrical, which is presume it is, since it includes software, your test house will test the entire device for certification.

    While you have chosen to do so, I really don't see the utility of a split stream design controls as you have to maintain all of the documents regardless of how many streams. All of the documents, regardless of streams, are subject to investigation by FDA, even those you believe to be confidential or trade secret. There are protections in the law for those documents, you cannot hide them from FDA. A split stream may lead to a longer inspection, too, as FDA investigators try to determine compliance to regulations in a complex set of files. 


    ------------------------------
    Edwin Bills MEd, CQA, RAC, BSc, CQE, ASQ
    Principal Consultant
    Overland Park KS
    United States
    elb@edwinbillsconsultant.com
    ------------------------------

    Original Message


  • 4.  RE: Software as Medical Device

    Posted 11-Feb-2019 12:40
    Thank you Edwin.

    Regards,

    ------------------------------
    Anjali Nair
    Los Angeles, CA
    ------------------------------

    Original Message


  • 5.  RE: Software as Medical Device

    Posted 11-Feb-2019 12:37
    Got it. Thank you, Richard. 

    Regards,

    ------------------------------
    Anjali Nair
    Student
    Boston MA
    United States
    ------------------------------

    Original Message


  • 6.  RE: Software as Medical Device

    Posted 11-Feb-2019 00:05
    Edited by Ivan Vecerina 11-Feb-2019 00:08
    Dear Anjali,

    Your (software) product can have independent components or modules. But ultimately it has one intended use, one set of claims on what it does. When it comes to validating your product - confirming safety and performance, assessing risks, and possibly ensuring information security etc - your product also needs to be considered as a whole.

    As you give very little information about the functionality, role, or users of each of the "parts" you describe, one has to make guesses to try to help. I have the impression that you may need to consider the "parts" as being components of a system, and to create system-level documentation: requirements, achitecture/design, risk management, etc.
      The requirements of each part need to fit in / come from this system-level documentation. Then each part can be developed and verified independently. Then in the end, you need again system-level integration tests and validation.

    You may find some inspiration in standards such as 62304, or in reading FDA's GPSV (General Principles of Software Validation).

    I hope this helps !
    Ivan

    ------------------------------
    Ivan Vecerina, MD
    CSO, Clinical Business Intelligence
    Lausanne, Switzerland
    ------------------------------

    Original Message


  • 7.  RE: Software as Medical Device

    Posted 11-Feb-2019 12:43
    Got it. 
    Thank you, Ivan. 

    Regards,

    ------------------------------
    Anjali Nair
    Los Angeles, CA
    ------------------------------

    Original Message


Related Content