Regulatory Open Forum

 View Only

  • 1.  Design Input, Software Requirements and Software Design Specification

    Posted 20-Mar-2020 12:20
    Hello RAPs Community,

    I always get confused about how much information do we need to have in the Design input document, Software Requirements Specification, and Software Design document. I have read the QSR and ISO 13485 for Design input and got some ideas. Also, I read FDA guidance about Premarket submission for SW. Could you please help me in understanding this issue especially related to Software as a Medical Device. (SaMD)
    Also on a side note, for SaMD, I feel that you don't need to have Product requirement document and you can go directly to Design input.

    Thanks,
    Bhupinder Singh

    ------------------------------
    Bhupinder Singh
    QA/RA Manager (RAC)
    San Jose CA
    United States
    ------------------------------


  • 2.  RE: Design Input, Software Requirements and Software Design Specification

    Posted 21-Mar-2020 10:39

    I have worked at two different small companies that both had software controlling the device, so not specifically SaMD.  Several times we doubled up documents to be one.  As an example, a V&V report and plan was used as the Requirements document, perfectly legal.  In every case, as the Regulatory Manager I pushed, unsuccessfully, to separate them.  It was not a fight worth fighting.  However, do not assume you don't need a requirements document.  During an audit with a software engineer, I asked what the design inputs were and got a blank stare.  I asked for a written requirements document and got a blank stare.  I asked how they knew the software was done and was told when they said it was.  I was told by the programmer that the owner of the company said make something that does this, and the programmer was doing that.  My next person to audit was the programmer's boss.  The boss had no idea the programmer was working on it.  Turns out the programmer was using a language the company was trying to get away from because it did not do everything the company wanted and there was an older program that already did it.  About two weeks of work time was wasted because nobody thought it important to write up a requirements document that said what to do.  In my opinion, don't right up product requirements because regulations and standards say to.  Do it because it is the right way to design things.



    ------------------------------
    Philip Reece
    Regulatory Affairs Director
    Belvidere IL
    United States
    ------------------------------

    Original Message


  • 3.  RE: Design Input, Software Requirements and Software Design Specification

    Posted 21-Mar-2020 11:17
    I would start with reading this document from FDA:

    https://www.fda.gov/media/100714/download

    Along with this general page of background information from FDA concerning Software as a Medical Device.

    https://www.fda.gov/medical-devices/digital-health/software-medical-device-samd

    The amount of information or documentation you must gather is predicated on what the intended use of the software is, prevailing     regulatory requirements from FDA along with prevailing industry practice (ISPE/GAMP and ISO, as examples)

    If your company is developing software that is a medical device by definition, I doubt you would be able to just forgo preparing a product requirements document.  I'd be willing to bet that is a critical starting point vs. something that is optional.

    You also may want to consider getting the outside assistant of an independent expert consultant.  The questions you are posing suggest there are lots of regulatory requirements that will all need to be met.

    Hope this helps.

    Mark



    ------------------------------
    Mark Balboni
    Bend OR
    United States
    ------------------------------

    Original Message


  • 4.  RE: Design Input, Software Requirements and Software Design Specification

    Posted 21-Mar-2020 13:10
    For software, the design input requirements are your SRS.  I think the confusion starts when IEC 62304 has a different vocabulary from the standard/regulations. I think what's important is understanding the big picture and not getting too lost in the vocab.  

    By product requirements, you mean the user needs?

    ------------------------------
    Karen Zhou
    ------------------------------

    Original Message


  • 5.  RE: Design Input, Software Requirements and Software Design Specification

    Posted 22-Mar-2020 14:19
    Bhupinder,

    This is a little hard to answer in a few words and definitely not having a clear understanding of your device type, intended use, and what your product does.  The design inputs can be of various structures or methods depending on your company, the software device, and how you put together your own software life cycle development (SDLC).  I would say you could look at the FDA guidance, IEC 62304, but as for content you should try to see some best practices in industry that are used.  Personally, if you are planning to submit a 510(k) premarket notification, definitely use the documents described in the FDA guidance document as they expect to see these type of documents.  Then the actual content or structure of those documents is up to you.

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

    Original Message


  • 6.  RE: Design Input, Software Requirements and Software Design Specification

    Posted 23-Mar-2020 11:52
    Thank you, everyone, for your valuable feedback! I really appreciate your support and your feedback will definitely help me!

    Stay safe and Healthy!

    Regards,
    Bhupinder Singh

    ------------------------------
    Bhupinder Singh
    QA/RA Manager (RAC)
    San Jose CA
    United States
    ------------------------------

    Original Message


Related Content