Software in Medical Devices, by MD101 Consulting - Tag - FDA - 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>AAMI TIR45 on the use of agile methods becomes new FDA recognized standard - Mitchurn:md5:878ea60c546034b19d11dc7fdbb8ff912021-10-06T20:08:48+02:002021-10-06T19:08:48+02:00Mitch<p>Sorry I didn’t have time to review it.</p>AAMI TIR45 on the use of agile methods becomes new FDA recognized standard - Sangeethaurn:md5:7073ec461c957ba259a8753f6bab87e72021-10-05T09:14:03+02:002021-10-05T08:14:03+02:00Sangeetha<p>What is the change between 2012 and 2018 version of TIR 45</p>Content of DHF, DMR and DHR for medical device software - Part 3 DHR - Marimuthu Durn:md5:2c154e6533a914dcf33118ab5e4235752020-07-22T01:12:37+02:002020-07-22T00:12:37+02:00Marimuthu D<p>This is a very useful note about DMR and DHR for me.</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>Validation of compiler and IDE - Why, when and how to? - Part 3 - Mitchurn:md5:124469200be89db79e3d1d12274ada192017-12-08T16:15:43+01:002017-12-08T16:24:44+01:00Mitch<p>Hi Chip,</p>
<p>Thank you for your comment, it is definitively relevant. This article is three years old and based on my experience since then, I have to agree with you. 21.CFR.870.i is applicable to software development tools. But, with a risk-based approach, I will always discard most of software development tools from validation, excepted bug trackers as said in comment #4.</p>
<p>I consider that the example on compilers in AAMI TIR 36 is a joke. And I'm polite. The fact that software development tools are in the scope of 21.CFR.870.i doesn't change my mind on validation of compilers. It's written there: http://blog.cm-dm.com/post/2014/03/28/validation-of-compiler-and-IDE-Why%2C-when-and-how-to-Part-2</p>
<p>I will never spend a second validating a compiler, even if I'm working on a critical life-sustaining medical device. For such device, I will set a mitigation action to manually review the assembly code. For other devices, I will do nothing.</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>Validation of compiler and IDE - Why, when and how to? - Part 3 - Chip Wellerurn:md5:b017fa556eb9e44ffcc7c26216b516252017-12-07T15:15:51+01:002017-12-07T15:15:51+01:00Chip Weller<p>The FDA has in multiple documents and presentations stated that 21 CFR 820.70(i) applies to software tools used during design and development. They have expressed that these tools fall under the "quality system" section. (I think there is a valid argument that the FDA retroactively interpreted this regulation, but they have been consistence on this interpretation at least since the GPSV.) One of the examples from AAMI TIR36:2007 is the validation of a C/C++ Compiler (Annex C, Example 4) where it states the compiler is used to partly automate the quality system process of "Software Implementation".</p>
<p>Based on this, I do not agree with your conclusion that from the FDA regulations "validating tools used in a software development process is not mandatory".</p>
<p>The FDA always requires validation, as does ISO 13485:2016. Based on risk this can be very simple, but there should always be a statement such as "tool XYZ has been determine acceptable for its intended use".</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>IEC 62366-1 becomes recognized by the FDA - Mitchurn:md5:600f7e00b0b40ff84cad940bb058b7bd2017-08-30T18:05:22+02:002017-08-30T17:05:22+02:00Mitch<p>I wish I had time to do so.</p>IEC 62366-1 becomes recognized by the FDA - jokourn:md5:54a33098b6b41d62512d1fa109dd560e2017-08-29T13:48:57+02:002017-08-30T17:04:27+02:00joko<p>Is the update of the template still on the todo list? I am looking forward to the updated version.</p>Validation of software used in production and QMS - Part 3 Validation Protocol and Reports - Mitchurn:md5:1450bff1d85a684349a85fca60784ff62017-01-02T22:18:58+01:002017-01-02T22:18:58+01:00Mitch<p>Hi BP,</p>
<p>Yes, definitely.</p>
<p>You can use a risk-based approach on the content of the update to do a light revalidation.</p>
<p>Cheers</p>Validation of software used in production and QMS - Part 3 Validation Protocol and Reports - BPurn:md5:632689c04d2adfb82270248f335c5d0b2016-12-22T10:02:15+01:002017-01-02T22:17:34+01:00BP<p>Mitch,<br />
Thanks a lot for this very interesting series, and for the useful templates.</p>
<p>You are not mentioning the necessary updates of software, especially the minor ones (example: from Atlassian Confluence 7.1 to 7.2). Would you go for a lighter process here?</p>Validation of software used in production and QMS - Part 2 Validation Master Plan - Mitchurn:md5:f1be81fe7fc9af67e34b58536d2654262016-09-19T02:18:38+02:002016-09-19T01:20:24+02:00Mitch<p>Thanks for your feedback!</p>
<p>I don't have such templates, unfortunately. </p>Validation of software used in production and QMS - Part 2 Validation Master Plan - Jamesurn:md5:6af1bd9a64bfb58d86edf3d7a9bbc5c12016-09-18T01:27:19+02:002016-09-19T01:17:03+02:00James<p>Hi Mitch,</p>
<p>You are spot on with the article. I am interested in understanding more broader software validation where ERP, QMS and AERS are intergrated, also requires Infrastructure validation , Do you have template for that type of software validation system. If you can share VMP template for more complex and prop software like trackwise, oracle or sap would be great help for us. I appreciate if you can share your thoughts and templates on it.</p>
<p>Thanks<br />
james</p>IEC 62366-1 becomes recognized by the FDA - Mitchurn:md5:6e0ab3044ad4bd895b5288dab4f60ef42016-06-23T21:06:13+02:002016-06-23T20:06:28+02:00Mitch<p>Thanks Luis for your feedback.</p>
<p>No, the actual template doesn't match the new requirements of IEC 62366-1 on formative and summative evaluation. I add to my todo list the action to update the template.</p>IEC 82304-1 - latest news about the standard on Health Software - Mitchurn:md5:47329a6b48178d9615b0435849466e2c2016-06-23T21:02:26+02:002016-06-23T20:02:51+02:00Mitch<p>Hi Andrew,</p>
<p>Thanks for your feedback.</p>
<p>Yes that what a typo, fixed.</p>IEC 62366-1 becomes recognized by the FDA - Luis Gurn:md5:eb47d86e7a883407131392691898ac6c2016-06-17T10:25:27+02:002016-06-23T20:04:05+02:00Luis G<p>You have posted a template for the Usability Specification Document, but since the norm has changed, does the document need to be updated or it can be used the same template?</p>
<p>You blog has been a lot of help</p>