Software in Medical Devices, by MD101 Consulting - Tag - software unit - CommentsBlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-29T12:42:03+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearClass A, B and C. When to do detailed design of software medical devices? - Mitchurn:md5:65425c292ee7ab5b147a01e417da2ed02022-05-20T22:32:53+02:002022-05-20T21:32:53+02:00MitchThanks for your question!
I agree with you about traceability.
You can do like what you wrote, because IEC 62304 is a recognized standard. Please also note that the word "likely" appears in the title of the table for major and moderate levels of concern.Class A, B and C. When to do detailed design of software medical devices? - TomTomurn:md5:42d603502358824819120cb72caeb0332022-05-17T16:45:00+02:002022-05-17T15:45:00+02:00TomTom<p>Hi !<br />
Thank you for content ! I highly appreciate it :)<br />
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.<br />
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.</p>
<p>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 :<br />
- Class A component : Requirement (SRS doc) -> test case (V&V)<br />
- Class B component : Requirement (SRS doc) -> Specification (SDS doc) -> test case (V&V).<br />
Is that correct?</p>
<p>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.)<br />
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 :<br />
- Class "MINOR" component : Requirement (SRS doc) -> test case (V&V)<br />
- Class "MODERATE" component : Requirement (SRS doc) -> Specification (SDS doc) -> test case (V&V).<br />
Plus, the IEC 62304 is a Recognised consensus standard so this can be justified ?</p>
<p>Any feedback would be so helpful !!!<br />
Thank you very much :)</p>What is a Software Unit? - Mitchurn:md5:6ad0b1ad5dd9aab648fe6205597bf3132021-06-12T21:21:52+02:002021-06-12T20:21:52+02:00MitchHi Onni,
Many thanks for your feedback.
Testing SW units without instanciating some other components can be a bit artificial. It's possible sometimes by using mock objects or similar artifacts. But it is very likely that you need some other components to test units the appropriate way. Especially when they depend on general-purpose libraries.What is a Software Unit? - Onniurn:md5:60db907eb4d84245914825b57def471e2021-06-11T13:53:52+02:002021-06-11T12:53:52+02:00Onni<p>Hi Mitch,</p>
<p>I really appreciate the work you have put down to decipher the IEC 62304!</p>
<p>The definition of UNIT seems to imply that a UNIT cannot depend on another UNIT. Also in B.5.4 the standard says "UNITS can be tested separately".</p>
<p>Surely it is good to minimize tight dependencies between UNITS. But how am I supposed to e.g. work with general purpose libraries/modules (which are UNITS on their own)? These libraries are usually used extensively everywhere. The standard seems to categorically mandate that UNITS should be implemented in such way that they can be tested in separation even from general purpose libraries/modules.</p>
<p>Please tell me that there's a less restrictive way to interpret the standard.</p>
<p>Any comments appreciated!</p>What is a Software Unit? - Mitchurn:md5:3e5f172dcb52553751987592893f54c72021-04-20T15:25:46+02:002021-04-20T14:25:46+02:00MitchHi Dan,
Thanks for your feedback and comment.
"It looks here that you are describing something similar to "Component based programming". Is that right?"
IEC 62304 doesn't talk about component-based programming. But it's true that the approach of SW items and SW units is similar to component-based programming.
"Is this article saying that the same approach would be useful for class C embedded medical devices?"
Yes, the same approach would be useful for class C embedded MD, since they are similar.
"Is 62304 saying that we must use Component Based Programming and design for class C medical devices?"
No, this is not written neither in the normative part, nor in the annexes.
"What if the amount of software was closer to being more easily represented using plain classes and OO? Would we still be required to "componentise" the software and add interfaces?"
That's possible to consider that the components are equal to the plain old classes and POO if the embedded SW is tiny enough to make the component level redundant or not useful. To make it short, if your software is tiny enough, you can have software units equal to classes. Then no "composentization" is required.
Hope it helpsWhat is a Software Unit? - Danurn:md5:468b4593119dca4dc21560bbbe3094b92021-04-19T12:17:19+02:002021-04-19T11:17:19+02:00Dan<p>Hi,</p>
<p>Thanks for the articles and the information you share, its great! I think this article is very interesting.</p>
<p>What is not clear to me is, 62304 talks about software units and specifying interfaces. It looks here that you are describing something similar to "Component based programming". Is that right? My understanding of component based programming was that it is useful for large scale enterprise systems and implementing micro-services architectures and such. I have read about it in the Ian Somerville books and in the "UML Component" book by Cheeseman and Daniels. Is this article saying that the same approach would be useful for class C embedded medical devices? Is 62304 saying that we must use Component Based Programming and design for class C medical devices? What if the amount of software was closer to being more easily represented using plain classes and OO? Would we still be required to "componentise" the software and add interfaces?</p>
<p>Thanks again!</p>
<p>Dan</p>Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices? - Mitchurn:md5:731139c74309320a3eb0df0e780646422018-02-17T16:56:02+01:002018-02-17T16:56:02+01:00Mitch<p>Hi Murielle,</p>
<p>The hardware risk control is required to downgrade form C to B or B to A without isolation/segregation. But according to 4.3.d, the segregation can be software/logical or hardware/physical. But you shall bring strong rationale for a logical segregation. Usually, it is better admitted to have logical separation between classes A and B, and physical between C and B.</p>
<p>Bye.</p>Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices? - Murielleurn:md5:540bfc56fcd2f03177a8bde98a5469162018-01-26T15:06:19+01:002018-02-17T16:49:05+01:00Murielle<p>Thank you for this post<br />
I have a question<br />
You write that the "The isolation may also be physical". So I assume that the interface may be done by software (for exemple with mutex, queue if using an OS).<br />
But when I read EN62304:2006 4.3.a, there is only hardware risk control measure which can reduce the software safety classification.<br />
So the interface can be only physical with consequence to run software items on separate hardware or I'm wrong in comprehension?<br />
Thanks for your response</p>Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices? - Mitchurn:md5:ebe4d8e4190f037be2f7e08ff14a4cf62017-12-08T16:00:41+01:002017-12-08T16:00:41+01:00Mitch<p>Thanks for your feedback.</p>
<p>Yes, it's possible to downgrade from class C to class A with two mitigation actions.</p>Class A, B and C. Is it possible to reduce the documentation of detailed design of software medical devices? - Mathieu Febvayurn:md5:09a67e0aebfc23cfe2a5d1cded2130112017-12-05T17:16:57+01:002017-12-05T17:16:57+01:00Mathieu Febvay<p>Thank you for this trick !</p>
<p>However, when you isolate your software like you did, is the interface manager mandatory class B ?</p>
<p>Is it possible to switch from class C item to class A with risk mitigation measures (CRC and another hardware/software checks the class C item) ? (EN62304:2006 4.3.a explains that is possible to switch from class C to class B AND from class B to class A)</p>
<p>Again, thank you for all your valuable informations.</p>
<p>Mathieu.</p>