Software in Medical Devices, by MD101 Consulting - Tag - IEC 62304 - 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-27T15:32:28+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearSoftware release vs design transfer - Mitchurn:md5:896ed021401e600aa25233dfa80457042022-12-13T14:24:23+01:002022-12-13T14:24:51+01:00Mitch<p>Hi Matt<br />
IEC 62304, IEC 82304 all are applicable. I totally agree with you.<br />
As you say, delivery is different. And this is exactly where 4.1.6 or, more precisely 7.5.6 is applicable. When the manufacturer puts the device into production on servers under their responsiblities, they shall verify that the installation went well. Thus something like an installation qualification is required.<br />
More, if manufacturer's personnel perform some service with the SaMD (e.g. medical images segmentation / analysis) then they shall be trained to the device, and some performance qualification shall be performed.<br />
Regards.</p>Software release vs design transfer - mattVurn:md5:df29c3230bbdef7d90dc4f7047b49ecd2022-12-05T15:12:44+01:002022-12-05T15:12:44+01:00mattV<p>Hi Mitch<br />
Thankyou for your articles. I do have two questions.<br />
1) 4.1.6 of ISO 13485 :<br />
Did not understand why 4.1.6 is required for SaMD in SaaS context.<br />
4.1.6 is about the validation of tools used in the development (non product software ?)</p>
<p>2) What would be different in the agile software development cycle for SaaS. Is there any difference at all? IEC 62304, IEC 82304 all are applicable i guess. Only the delivery/distribution is different ?</p>Is my software in class A, B or C? - Mitchurn:md5:8f49068be58b8057c2e9e4ffc707b0ae2022-09-21T18:34:50+02:002022-09-21T17:34:50+02:00MitchHi, the medical image database only for storage is not regulated as medical device. Regards.Is my software in class A, B or C? - Shubhangi Chouhanurn:md5:53e3ba58e251a621563da3e7ae04edea2022-09-19T15:24:37+02:002022-09-19T14:24:37+02:00Shubhangi Chouhan<p>My SW system has three items:</p>
<p>1) User Interface: used for user login, (Non medical)<br />
2) Data Storage: used for secure storage and retrieval of patients wound image Class ??<br />
3) Image analyzer: used to sizing and segmentation of wound to suggest treatment to nurse (classIIa)</p>
<p>My question is about the data storage platform Item, is that consider as MD, if this only for storage purpose?</p>
<p>Thank you</p>Class 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>Probability of occurence of a software failure - Aliurn:md5:7e8227ed3f3475cabe2387a313d05a9f2022-02-16T14:50:24+01:002022-02-16T14:50:24+01:00Ali<p>Thank you for this informative post. But I think, in some places you calculated the total probability by multiplication (if the events be dependent, you have to calculate the total probability by conditional probability formulas).</p>When Web meets SOUP - jeromeurn:md5:85b29e5300066352778286de3ea295892021-09-13T11:29:53+02:002021-09-13T10:29:53+02:00jerome<p>Thank you Mitch,</p>
<p>Your article is very interesting. I follow you completly about SOUP management and conclusion : change control, no automatic updates.<br />
This problem of SOUP management becomes very hard with new technologies (web, cloud, mobile...). It was easier when we had only microprocessor !</p>
<p>Don't forget to think about OTSS validation when you start cloud application, it can be so much time to spend. And think about silent update from cloud platform...</p>
<p>thx</p>When Web meets SOUP - Mitchurn:md5:4f8e8ab235ac5086c3386f01700e6bd32021-09-12T20:08:28+02:002021-09-12T19:15:18+02:00MitchThanks Yan for your feedback.<br/>
Qualifying a supplier usually relies on a purchase procedure somewhere else in the QMS, far from software design! The idea is to reuse this procedure and apply specific criteria to software vendors and/or open-source projects.<br/>
Criteria like:<br/>
<li>Is the supplier ISO 9001 or ISO 13485 certified?</li>
<li>Is the supplier ISO 27001 certified?</li>
<li>Does the supplier exist since more than 5 years?</li>
<li>Does the supplier supplies more than 3 software?</li>
<li>What is the turnover of the supplier?</li>
<li>Does the supplier answer our questions?</li>
<li>Does the supplier provide a list of known bugs?</li>
<li>Are the open major bugs acceptable?</li>
<li>Does the supplier provide updates of the software tool?</li>
<li>What is the delay between 2 updates?</li>
<li>Is the open-source project supported by a major player?</li>
<li>Are there frequent contributions to the open-source project?</li>
<li>What is the user-base of the open-source project?</li>
These criteria aim to ensure that the software is stable, reasonably free of bugs and that it won't be made obsolete in the near futureWhen Web meets SOUP - Yanurn:md5:dd7f6563b5b3b01d9e1e565f848bb3c52021-09-07T13:06:23+02:002021-09-12T19:03:39+02:00Yan<p>Thanks for the great article! Do you qualify SOUP suppliers? Some SOUP items like programming language and libraries may have a direct impact to the product, how do you qualify them?</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>IEC 62304:2019 or 2020 - Next Generation - Oliver Eidelurn:md5:832d83c0319257e8d88b0db58544ba9b2021-02-04T13:37:29+01:002021-02-04T13:37:29+01:00Oliver Eidel<p>Hey Mitch, this is a really, really good summary, thanks so much for writing this! :)</p>
<p>And I agree with you, the changes to the handling of legacy software are significant.</p>
<p>"The reason is obviously to make the standard more readable per se, and more readable by people who are not used to medical devices standards. Like medical device start-ups, or ... health software vendors."</p>
<p>Had a good laugh. So true. We consultants may be able to read this stuff, but for normal humans (or developers) it still is very hard.</p>Is my software in class I MDD: Stayin' alive - Mitchurn:md5:4ed2d8df45850de549b9d9de9eb1ce652020-12-04T11:40:18+01:002020-12-04T11:40:18+01:00MitchHi Kahina,
A MDD class I software can be placed on the market until May 2024. Thus, the deadline to implement a QMS is May 2024 and CE mark your software in class IIa. It means that you've initiated this work 24 months before!Is my software in class I MDD: Stayin' alive - Kahinaurn:md5:385e9b6401d3c87aafa5d26be5ce50012020-12-01T17:01:37+01:002020-12-01T17:01:37+01:00Kahina<p>Hey Mitch,<br />
Merci pour ce superbe travail!<br />
Un logiciel de classe I selon MDD passera en IIa selon MDR, quelle serait la date butoir pour mettre en place un SMQ ?<br />
Merci d'avance</p>Is my software in class I MDD: Stayin' alive - Mitchurn:md5:5c20c39a2c1a0bd90321237a964b7cdd2020-11-13T17:43:51+01:002020-11-13T17:47:25+01:00MitchIt's not a matter of class I. Regulatory requirements on risk management are exactly the same for every class.
ISO 14971:2019 isn't harmonized, this is why I didn't mention it in this article. There are lots of comments about ISO 14971:2019 not being harmonized on the web!
Just take it like this:
-ISO 14971:2012 is enough for the MDD/IVDD/AIMDD, with annexes ZA, ZB, ZC giving the deviations between the standard and the regulations.
-ISO 14971:2019 is for the MDR/IVDR, but is not enough. You also have to make your own assessment of deviations between the annex I of the MDR, which defines requirements on risk management, and ISO 14971:2019.
As soon as we have the annexes ZD, and ZE for the MDR and IVDR in EN ISO 14971:2019, this standard will be enough for the MDR/IVDR.Is my software in class I MDD: Stayin' alive - Oliverurn:md5:eaf6d6f5c90d8865f37d5068ae12b15d2020-11-10T23:01:47+01:002020-11-10T23:01:47+01:00Oliver<p>Hey Mitch, great post as always :)</p>
<p>Quick question: Why the ISO 14971:2012 (emphasis on 2012) for risk management and not the newer version from 2019? Is there anything specific to the old version which makes it more suitable for class I devices?</p>
<p>Thanks! :)</p>
<p>Oliver</p>Is my software in class A, B or C? - Mitchurn:md5:1d2f32d1100d075d2687478bfb8ff9d82020-10-09T19:59:41+02:002020-10-09T18:59:41+02:00Mitch<p>Yes, definitely possible!</p>