Software in Medical Devices, by MD101 Consulting - Standards - 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:9c06172e7cd5ed0f5b192883b657eabbDotclearIEC 81001-5-1 Right Here Right Now - Mitchurn:md5:cfd95641de5fc681162e09d6dc86c5872024-02-28T17:30:06+01:002024-02-28T17:30:06+01:00Mitch<p>HI Peter,<br />
Thanks for your feedback.<br />
Yes, it was supposed to be harmonized by May 2024. But the MDCG WG on standards held a meeting the 19 January 2024. This report states that it is being postponed to 2028. There is no official information. But you can find it on lnkn.</p>IEC 81001-5-1 Right Here Right Now - Peter Olssonurn:md5:72d333446a9a6d0339d5ef7a968874b22024-02-26T13:56:48+01:002024-02-26T13:56:48+01:00Peter Olsson<p>Hi,</p>
<p>Interesting article! I have a consideration about the harmonzation of 81001-5-1 during 2028. I thought that 81001-5-1 was supposed to be harminized May 27th this year (2024)?</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>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 A, B or C? - Mitchurn:md5:1d2f32d1100d075d2687478bfb8ff9d82020-10-09T19:59:41+02:002020-10-09T18:59:41+02:00Mitch<p>Yes, definitely possible!</p>Is my software in class A, B or C? - Victorurn:md5:a001696df2da92796b265c818fb665e92020-10-08T17:07:26+02:002020-10-08T16:07:26+02:00Victor<p>Is it possible that device has class I but its software has class C? It is out of logic but 62304 does not exclude this case.</p>Is my software in class A, B or C? - Mitchurn:md5:3982c11ed161a27ee6a194877adae5902020-07-24T17:14:38+02:002020-07-24T16:14:38+02:00MitchToss a coin :-)Is my software in class A, B or C? - CAurn:md5:16c78eb1f5dc0e3385d95413509f82a22020-07-20T11:24:26+02:002020-07-20T10:24:26+02:00CA<p>Are baby incubators class B or class c medical devices</p>How to bring legacy software into line with IEC 62304? - part 1 - Mitchurn:md5:29976eed5d4d8f59637854720e3936092020-07-17T16:25:22+02:002020-07-17T15:25:22+02:00MitchHi Mike
I agree with you, the comment you mentioned makes the assumption that the software was legally placed on the market in the first case. If that's no the case, the only solution is reverse-engineering.How to bring legacy software into line with IEC 62304? - part 1 - Mikeurn:md5:c87f44b05a0c594bf3e04ed3c61992fe2020-07-16T19:26:38+02:002020-07-16T18:26:38+02:00Mike<p>Hi Mitch,</p>
<p>In your response of Wednesday 30 August 2017 you stated the possibility of using the Legacy Software requirements of IEC62304 Amd 1 2015 to bring R&D software up to the clinical version. However, how would this be allowed given that the definition of Legacy Software is "medical device software that was legally placed on the market ..."?</p>MD and IVD standards: IEC 60601-1 and IEC 61010-1, versus IEC 62304 - Part 1 - Mitchurn:md5:1d8fdeca8fff26c567ae45dfa251abba2020-03-18T11:19:10+01:002020-03-18T11:19:10+01:00MitchMany thanks for your very comprehensive comment!Got SOUP? - Part 6 - FDA Guidance and Conclusion - Mitchurn:md5:a3daa2d1ef295f73f5bb941baec72bcf2020-03-18T11:14:04+01:002020-03-18T11:14:04+01:00Mitch<p>Hi Mike,<br />
I don't have additional guidance coming from official documents.<br />
Usually we don't test SOUP in separated test cases. We can assume that when the test of a given function is passed, the behaviour of software items, including SOUPs, integrated to deliver that function is correct.<br />
Their example is a bit far-fetched but possible in some critical cases.</p>MD and IVD standards: IEC 60601-1 and IEC 61010-1, versus IEC 62304 - Part 1 - Jorge Diaz-Santiagourn:md5:a81021ec57020c3146245198ff42ad2d2020-01-09T18:00:11+01:002020-01-09T18:00:11+01:00Jorge Diaz-Santiago<p>1. FPGAs are configured not programmed. It is a misnomer to call an FPGA programmed.<br />
2. Tools (often misleadingly called compilers) are used to create a configuration file for an FPGA. These tools run in a computer completely separate from the FPGA. This is the same way tools are used to draw schematics and pcb layout. Using tools in a computer to create something does not make that something "software".<br />
3. This configuration file organizes the internal connections between transistors (or logical gates) inside the FPGA. There is no code running on anything (inside an fpga there is nothing like a processor running instructions, unless of course there is core inside the fpga).<br />
4. State machines are not processors.<br />
5. State machines do not run code, nor execute instructions.<br />
6. A processor is a very special type of state machine. For this reason a processor itself is verified/validated as hardware not software. Just ask Intel/AMD or any other microprocessor/microcontroller manufacturer.<br />
7. Most integrated circuits are designed using the same hardware description languages (VHDL or Verilog) that are used to configure FPGAs. Here the word "languages" is used the same way somebody would use it to say math is the language of numbers. They are not programming languages used to create programs/instructions that run in a processor. After VHDL or Verilog is "compiled" the output is not something that runs, is just a description of circuit connections (literally a schematic). In fact, because of this, only an extremely restricted subset of the "languages" can be used to describe hardware. How can anybody validate/verify a schematic like a program?<br />
8. An FPGA is not a software system. It is a hardware system, which can be used to create a software system, if and only if, a hard/soft core is present/instantiated inside the FPGA.<br />
9. IEC 62304 Amendment 1: 2015 makes this clear again: any instruction that runs on a processor is to be considered software. Unless there is a soft or hard core inside an FPGA, there are no instructions nor software running on a processor at all. Therefore the configuration file for an FPGA is not software.<br />
10. A processor with its code in ROM is a system that is defined completely in hardware and is immutable, but nobody in their right mind would consider it as an only hardware system. There are instruction (in the ROM) that are executed by the core/processor. This instructions are hard coded/wired, but nevertheless they are instructions to be executed by a processor/core.<br />
11. Both CPLDs and PFGAs are just ICs/ASICs whose internal connections are not fused, like in a ROM, but are (quite literally) placed in RAM. That fact confuses people who don't completely understand the difference between custom ICs, ASICs, CPLDs, and FPGAs. The configuration file is changing the way the transistors inside the FPGA are connected; is all electrical connections (literally shorts and opens).<br />
12. As mentioned before an FPGA can have a processor/core inside, and then the code running on that core would be software, not the configuration file that creates the core inside the FPGA. I hope it is clear enough that in this case there would be two files, one to configure the FPGA, the other would be the software being executed by the core inside the FPGA.<br />
13. Unfortunately many people writing standards, writing software, or managing (any of which could be electrical engineers) do not completely understand what is an FPGA and how it is used. They only see a file being created by a computer which is then transferred to the FPGA. All integrated circuits (even analog ones) are nowadays created in a computer that creates files that are eventually transferred to the integrated circuit. This transfer can be done in a volatile or non-volatile way, and using one or the other does not make the IC magically hardware or software. The same way burning code into ROM instead of RAM does not convert the program into something people would stop calling software/code/program. The fact that you can change the connections in an FPGA a lot quicker and cheaper than in a custom IC or an ASIC (which would require creating a new set of masks and running a new batch of chips at the fab), doesn't make the two processes any different.</p>