Regulatory Open Forum

ย View Only
  • 1.  SaMD Software Requirements

    This message was posted by a user wishing to remain anonymous
    Posted 14-Jan-2022 13:48
    This message was posted by a user wishing to remain anonymous

    Hi RAPS,

    Instead of following a hierarchical model for requirements (User Reqs > System SW Reqs > Unit SW Reqs), is it possible to use a flat Software Reqs document? My company wants to use this method as our JIRA to QMS setup does not allow for more than 2 levels of traceability.

    As an example, if A, B, C, and D are software reqs for a software with two units - 
    1. Unit Level Verification - A&B are verified (one unit), C&D are verified (second unit)
    2. Integration Verification - A&B + C&D is verified
    3. System Level Verification - ABCD is verified (a software run is verified)

    While I'm not a fan of this approach, I have been through 62304 and the FDA validation guidance a couple of times and can't find anything that goes for or against. Will it simply be a case of being able to provide a strong justification on why this verification approach works (I'm aware the QMS limitation won't be a strong justification and am trying to convey that)?

    Any help, pointers, recommendations are appreciated!

  • 2.  RE: SaMD Software Requirements

    Posted 15-Jan-2022 11:50
    Hi, I'm not aware of any requirements for a hierarchical documentation model. You are expected to define software requirements; how you choose to document and keep track of them is up to your organisation's preferences.

    As an example, in IEC 82304-1, there is a note indicating that product system requirements for a SaMD might be the same as software requirements in the context of IEC 62304:
    "NOTE 4 There is not necessarily a difference between SOFTWARE SYSTEM requirements of IEC 62304:2006, 5.2.1 and and HEALTH SOFTWARE PRODUCT system requirements."

    So, I don't find anything wrong with your approach. But, just make sure to keep an eye on what high-level requirements you want to reference in your validation. ๐Ÿ˜‰ (I assume that will be your "User Reqs"?)

    Christian Kaestner

  • 3.  RE: SaMD Software Requirements

    Posted 17-Jan-2022 05:00
    Hello Anon,

    Indeed you can have a "flat" software requirements where the Software Requirements Specifications (SRS)/System or User level can be combined together with the Software Detailed Specifications (SDS)/Unit level.  (Just a note the unit and system integration can be subsets of either of those or sitting somewhere in the middle.)  If the SaMD is "simple" it might be acceptable to have the SRS/System and SDS/Unit combined together into one document.  This also means the verification and validation can be done together.  There are positive and negatives with this approach.  As example, if you are making a submission to a regulatory authority, it is better they see clear demarcation between verification and validation, thus a separate Unit level requirements and System level requirements.  The more complicated the SaMD is, the more requirements document you will have and potentially more layers of requirements.  Though this can be completely set up by your company as you comment there is nothing in the standard or guidance documents that says you can or can not do it this way.

    If you wanted to have a '2 levels of traceability' I would recommend having the SRS defined as the User/System requirements - this would be in relation to all the validation testing.  Then the second level is the SDS defined as the Module/Unit requirements - this would be in relation to all the verification testing.  Therefore you keep 2 levels SRS and SDS.  Keep in mind this does not mean you can not have more than one SRS or SDS as well.  Depending on the SaMD, I have done in the past creating 1 SRS document which was at the User/System level and then having 4 or 5 SDS documents for the different modules or components.  It was still 2 levels, then the SRS had the linkages down to the different SDS documents.  There is no hierarchal requirement defined by IEC 62304, thought this is sort of "built-in" the standard having the different levels, thus why during regulatory reviews they want to see the different levels.  If you create a flattened structure of software documentation, just make sure you clearly describe this in your system and make sure the traceability is clear.

    Richard Vincins ASQ-CQA, MTOPRA, RAC
    Vice President Global Regulatory Affairs

  • 4.  RE: SaMD Software Requirements

    This message was posted by a user wishing to remain anonymous
    Posted 23-Jan-2022 16:24
    This message was posted by a user wishing to remain anonymous

    OP here.

    Thank you so much, Christian and Richard!