Software item classification and Detailed Design

TomQA

Starting to get Involved
#1
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 :)
 
Elsmar Forum Sponsor

Tidge

Trusted Information Resource
#2
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.
 
Last edited:

yodon

Leader
Super Moderator
#3
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

Starting to get Involved
#4
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

Trusted Information Resource
#5
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?"
 
Thread starter Similar threads Forum Replies Date
B Tabular Traceability by Software Item ID - IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 3
G Software verification vs. system verification IEC 62304 - Medical Device Software Life Cycle Processes 3
S Process Monitoring using SPC software Quality Assurance and Compliance Software Tools and Solutions 3
J Megger MIT520/2 adjustment software? Calibration and Metrology Software and Hardware 0
M Product Acceptance Software (PAS) PROCEDURE (BOEING D6-51991) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
M 3D Scanner Software validation ISO 13485:2016 - Medical Device Quality Management Systems 7
Y Software to Manage IEC 62304 Traceability Requirement IEC 62304 - Medical Device Software Life Cycle Processes 3
T Software Unit definition - IEC 62304 - Medical Device Software Life Cycle Processes 3
T Software user interface - definition of hazards ISO 14971 - Medical Device Risk Management 15
T Classification Accessory Software medical device EU Medical Device Regulations 4
G Software Medical Device Classification EU Medical Device Regulations 7
D Software Validation Question ISO 13485:2016 - Medical Device Quality Management Systems 10
C. Tejeda Computer system validation approach for Minitab Statistical software Software Quality Assurance 7
B Can a software that receive data from a MD be classified as Class I?or is not a MD? EU Medical Device Regulations 5
A What JIRA Software workflows you use for your software lifecycle? IEC 62304 - Medical Device Software Life Cycle Processes 4
G Software change management Design and Development of Products and Processes 2
G IATF 7.1.5.2.1 Calibration/verification records :Program/software verification IATF 16949 - Automotive Quality Systems Standard 7
John C. Abnet ...validation of computer software ISO 13485:2016 - Medical Device Quality Management Systems 14
N Free statistical software Reliability Analysis - Predictions, Testing and Standards 7
T ISO quality system software such as MQ1 (which is what we currently use) Document Control Systems, Procedures, Forms and Templates 8
X Looking for 17025 auditor to perform internal audit on IT software testing laboratory ISO 17025 related Discussions 3
B ERP software validation - risk assessment vs validation scope ISO 13485:2016 - Medical Device Quality Management Systems 11
D Guidance for Medical records software/template ISO 13485:2016 - Medical Device Quality Management Systems 1
M MDSW Software importer distributor CE Marking (Conformité Européene) / CB Scheme 2
B Software as a Medical Device - Language Requirements EU Medical Device Regulations 6
B Software as a NON-medical device Medical Information Technology, Medical Software and Health Informatics 23
qualprod 8.3 for software development. ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
S Software design document NMPA guidance and consultant China Medical Device Regulations 4
C How to place software version for SaMD product in HIBC secondary data structure (UDI-PI)? Other US Medical Device Regulations 4
L Acquiring software from 3rd party company IEC 62304 - Medical Device Software Life Cycle Processes 8
R Validation of Software used in Verification Testing ISO 13485:2016 - Medical Device Quality Management Systems 2
A FMEA Software IATF 16949 - Automotive Quality Systems Standard 6
A Medical Device Software POC Medical Device and FDA Regulations and Standards News 6
C Discus Software for First Article Inspection Inspection, Prints (Drawings), Testing, Sampling and Related Topics 1
D One Software as Medical Device product or two? EU Medical Device Regulations 4
V Internal Audit Software IATF 16949 - Automotive Quality Systems Standard 5
Watchcat New Draft Guidance on Content of Premarket Submissions for Software Device "Functions" Other US Medical Device Regulations 2
Watchcat Software validation vs design V&V? Other US Medical Device Regulations 27
M Initial Importer/Distributor and Software Validation IEC 62304 - Medical Device Software Life Cycle Processes 1
F Configurator for a power unit - Software or other solution? Manufacturing and Related Processes 0
D Test Management Software Software Quality Assurance 1
E ISO 13485 software validation ISO 13485:2016 - Medical Device Quality Management Systems 7
D Tracking software versions used with instruments ISO 13485:2016 - Medical Device Quality Management Systems 0
dgrainger Informational MHRA's Software and AI as a Medical Device Change Programme UK Medical Device Regulations 0
S Do you follow your QMS for non-device software features? Medical Information Technology, Medical Software and Health Informatics 4
J Can we register non-device clinical decision support software under draft guidance? Other US Medical Device Regulations 5
I Software (SaMD) mobile application verification testing: objective evidence Medical Information Technology, Medical Software and Health Informatics 2
J EU equivalent to Clinical Decision Support Software EU Medical Device Regulations 3
Y ISO 13485:2015 Software Validation IQ/OQ/PQ ISO 13485:2016 - Medical Device Quality Management Systems 13
S Recommended software to send Quality scorecards to suppliers (external providers) Supplier Quality Assurance and other Supplier Issues 3

Similar threads

Top Bottom