Software item classification and Detailed Design

[TomQA]

Hi,

I have a question concerning the 62304 classification (A,B and C) and the Software Detailed Design(SDS) of clause 5.4 of IEC 62304, so this would be for EUROPE.
For example, If I have 5 Software items that are class A and 1 Software item that is a class B, clause 5.4.1 specifies that the SDS is only necessary for class B components.

Therefore, in my SDS document we could have only the detailed specification of the Class B component, so therefore in terms of traceability we would have :
- Class A component : Requirement (SRS doc) -> test case (V&V)
- Class B component : Requirement (SRS doc) -> Specification (SDS doc) -> test case (V&V).
Is that correct?

Finally, in the US, the classification of the software is determined by the level of concern (which is similar to the 62304 but not exactly the same, which is the case for our device.)
The level of concern seems to give the software classification of the WHOLE software, per this guidance. However, is it possible to isolate each software component and evaluate their own class, like the IEC 62304? This would avoid us to document specifications for low class (MINOR - class A) software Items and we would have :
- Class "MINOR" component : Requirement (SRS doc) -> test case (V&V)
- Class "MODERATE" component : Requirement (SRS doc) -> Specification (SDS doc) -> test case (V&V).
Plus, the IEC 62304 is a Recognised consensus standard so this can be justified ?

Any feedback would be so helpful !!!
Thank you very much

 

[Tidge]

There was IIRC a draft guidance (issued for comments) in 2021 that suggested slightly moving the explicit requirements (for submission purposes) around SDS and Architecture such that for what we currently think of as Moderate LoC those would not be explicitly required (in the submission). The draft would do away with Minor/Moderate/Major and suggested just Basic/Enhanced... which I thought was a clever way to emphasize that this was for DOCUMENTATION FOR SUBMISSION only and didn't precisely align with deliverables in the 62304 classification scheme.

In my experience with "Class B"/Moderate LoC software systems, we have always generated both an Architecture and had something like Detailed Designs, and those both always got submitted to the FDA anyway. This was not overkill on our part, as we almost always had those elements appear in traceability for things that the FDA cared about, e.g. Risk Analysis and Software Verification... I've had questions from reviewers who thought that they needed such information to answer some (higher level) question and it is much more friendly to let them know the information they have asked for exists in a supplementary attachment to the submission than it would be to challenge the reviewer by waving the guidance at them.

In the category of "you can do more work than you have to show": An architecture will be necessary to

• demonstrate that the different classifications/LoC even make sense,
• motivate the verification work (and regression efforts) appropriately

EDIT: I should add this: I seem to recall that the LoC is also a "one time only" assessment made for the top level of the system, so decomposition into separate "units" would not be appropriate, as the FDA reviewers will likely be looking for a single submitted packet. You may be able to leverage 62304 classifications to "show less work" in some areas but I wouldn't recommend calling that out explicitly in the submission.

 

[yodon]

Therefore, in my SDS document we could have only the detailed specification of the Class B component, so therefore in terms of traceability we would have :
- Class A component : Requirement (SRS doc) -> test case (V&V)
- Class B component : Requirement (SRS doc) -> Specification (SDS doc) -> test case (V&V).
Is that correct?

Do you have any system-level requirements? Per the standard, there's an expectation that you trace software requirements back to system requirements (to demonstrate that you have implemented system requirements). Similarly, risk controls often drive software requirements so you would want to include those. While risk management isn't explicitly required by 62304 for Class A software, you should probably do it anyway to a) support your claim for Class A; and b) comply with 14971 (and especially if you take the tack to reduce all risks to the greatest extent possible).

Regarding the approach of classifying different software items in the system differently, that's a tough one. Clearly 62304 allows it and, as you note, it's an FDA recognized consensus standard. But inspectors / reviewers have not proven to be all that software-savvy and if they see your system is, for example, Class II, they may expect that ALL the software must be Class B at least. It's a balance of how much you're willing to fight the righteous fight -v- a quicker clearance. Oh, and FDA inspectors often fall back on the guidance document for the submission packet.

I agree with @Tidge that an architecture doc is recommended. By and large, all the sections in the standard are fundamentally good software engineering processes.

 

[TomQA]

Hi !
Thank you both for your response ! Yes I am on the same page with you concerning the Software Architecture !

Do you have any system-level requirements? Per the standard, there's an expectation that you trace software requirements back to system requirements (to demonstrate that you have implemented system requirements). Similarly, risk controls often drive software requirements so you would want to include those. While risk management isn't explicitly required by 62304 for Class A software, you should probably do it anyway to a) support your claim for Class A; and b) comply with 14971 (and especially if you take the tack to reduce all risks to the greatest extent possible).

Yes we do have a system-level requirements (listed in a Product Requirement Specification) and we've already linked them to software requirements. So we would have :
- Class A component : Product (system level requirement) requirement (PRS doc) -> Software Requirement (SRS doc) -> test case (V&V)
- Class B component : Product requirement (PRS doc)- > SoftwareRequirement (SRS doc) -> Specification (SDS doc) -> test case (V&V).

My real aim is to simplify the documentation which is linked to class A components.

I also have a question, this new DRAFT guidance has been released. With its "draft" status, can we still use it, or is there a way to know when it will be officially published ? Because under this new guidance, we not mention any more the level of concern and our device would require "basic documentation level" and therefore no SDS..

Last comment, our device is 510(k) exempt too

 

[Tidge]

I always thought the DRAFT guidances did a good job explaining that they reflect the current thinking (and training delivered to) the current set of agency employees. We outside of the agency simply can't use them as "get out of non-compliance" trump cards. It is a little like reading tea leaves, but that's part of the relationship.

I don't precisely know how the agency is going to view your communication with them, but they are going to expect a relatively straightforward risk analysis that aligns with your intended use. Where you (in this thread) have been offering discussion around "some is Class A, it won't have as much documentation as the stuff that is Class B" is essentially immaterial to agency discussions... it those areas are really class A, they simply won't be showing up (with details) in an accurately established risk management file, so there would not need to be those documents in your communication with the FDA. Picture sending someone into the wilderness with only a list of risks (the "class B" items) you think they will encounter... doesn't it seem reasonable to also include on such a list that the other things they encounter that you don't consider to be risk? (the "class A" items)

What follows is not meant to be cruel:This situation reminds me of someone trying to see how high the bar is set and that person is trying to jump just high enough to clear the bar. This has always been a bad strategy when dealing with regulators. The guidance(s) are about how much of the work a developer did should be submitted for the reviewers to adequately their job.... not about how much work the developer needs to do. Any slight change and there is a risk of not clearing the bar on the first attempt.

There is an additional twist: there is no guarantee that any particular FDA reviewer will have lots of experience and/or familiarity with your documents (or even product). In past years I worked on a submission that had a relative "rookie" who was very professional and by no means ill-informed, but had some basic questions that would have otherwise slowed down the review had we not already included material in the packet that some "rules lawyers" thought were not required per the guidance(s). I can barely begin to describe how much more reassuring it is to be on a 20-minute phone call with a reviewer and their more experienced peer/supervisor and to be able to say to the agents "That's a reasonable ask, the information you are looking for is in volume ____ of the packet" instead of "We didn't think you needed _____, do we really need to pull that together for you? Will this slow down the review?"