Software in Medical Devices, by MD101 Consulting - Tag - Guidance - 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: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>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>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>EU Guidances - What's new? - Claraurn:md5:5532be3ca1920df6244cf465521454092017-07-19T04:40:56+02:002017-07-19T03:40:56+02:00Clara<p>We are a gaggle of volunteers and starting a new scheme in our community.<br />
Your web site provided us with helpful information to paintings on. You have done a formidable task and our whole community will likely be grateful to you.</p>Cybersecurity in medical devices - Part 3 AAMI TIR57:2016 - Mitchurn:md5:b4e340eb24774a3aee1c8d9f602933ed2017-05-23T17:11:16+02:002017-05-23T16:11:16+02:00Mitch<p>Hi Ben,</p>
<p>No, it won't be harmonized, it is a US document. But it can be used as state-of-the-art for implementation of cybersecurity for other regulations.</p>
<p>The cybersecurity directive addresses security of networks of operators of vital importance: power plants, telco infrastructure, and possibly hospitals (I'm not a specialist). It's not directly applicable to MD manufacturers. </p>Cybersecurity in medical devices - Part 3 AAMI TIR57:2016 - benurn:md5:4b51b5dfbae9b5b45c5b6f722e9674852017-05-19T12:04:24+02:002017-05-23T16:06:09+02:00ben<p>Hi Mitch, thanks for the overview of AAMI TIR57:2016 Principles for medical device security — Risk management. A really easy to follow summary. Is this harmonised (EU MDR [pov), or do you think it will likely be harmonsied in the future?</p>
<p>Also i'd be interested to know whether you think the Security of Network & Informations Systems Directive 2016/1148 aka the Cybersecurity directive (to be implemented into member states by ~end 2018) will have a direct effect on medical device manufacturers?</p>MEDDEV 2.1/6 2016 - Mitchurn:md5:8afdf98f1462c5f8317054a735200e7b2016-09-23T22:52:30+02:002016-09-23T21:52:30+02:00Mitch<p>No, thanks for the tip!</p>MEDDEV 2.1/6 2016 - Benurn:md5:051ad92f212efd677753ca24e9fd12b52016-09-23T09:36:15+02:002016-09-23T21:45:19+02:00Ben<p>Useful summary as ever.</p>
<p>Have you seen the updated - and now interactive - MHRA guidance on standalone software and apps?</p>
<p>Thanks</p>Content of DHF, DMR and DHR for medical device software - Part 1 DHF - Mitchurn:md5:2de360001461c3b5957e7a9c60a711682016-02-26T17:15:26+01:002016-02-26T17:16:05+01:00Mitch<p>Hi Richman,</p><p>Thanks for you feedback.</p><p>If you do the integration at design time, then, yes, it goes to the DHF.</p><p>If you have tests to run every time you install software to verify its correct integration on the target platform</p><ul><li>the intallation test plan goes to the DMR,</li><li>the installation test reports of tets run on each target platform go to the DHR. </li></ul><p>Bye.</p>Content of DHF, DMR and DHR for medical device software - Part 1 DHF - Richman Manaliliurn:md5:8d7d8ed8b8417953175334eb50f31a492016-02-25T00:48:33+01:002016-02-26T17:11:58+01:00Richman Manalili<p>I found this article really valuable for me to understand the regulatory requirements pertaining to DHF. I would like to clarify, if a software integrates with other third party software (e.g. scribing software for radiology systems), the artifacts you produce (requirements, plans, test cases, results) in realizing that integration, will they be part of the DHF?</p><p>Thanks in advance.</p>Content of DHF, DMR and DHR for medical device software - Part 1 DHF - Mitchurn:md5:b5b6cf289c71a0041ed28b17da3e383d2015-10-04T22:14:59+02:002015-10-04T21:14:59+02:00Mitch<p>Many thanks Giuseppe for your comment. </p><p>The DHF is explicitly mentioned in design review, verification and validation. I agree. </p><p>But I found that the only way to be compliant with 820.30 (j) and especially to "demonstrate that the design was developed in accordance with the approved design plan" is to kepp in the DHF all other records I mentioned. </p><p> </p>Content of DHF, DMR and DHR for medical device software - Part 1 DHF - Giuseppeurn:md5:d3d1ac746edacf54234cf6fcb991b0d22015-10-02T12:39:08+02:002015-10-04T21:04:40+02:00Giuseppe<p>I'm sorry, but as for the records to put into a DHF I'm not sure that it is as you mentioned. In fact, only the claims (e), (f) and (g) of 820.30 explicitly assert to put the results of their activities into the DHF.<br />As far as I've understood, since the aforementioned claims refer to, resp., design review, verification, and validation, in my opinion, by putting only these results into DHF should be in line with the objective asserted in (j) "...to demonstrate that the design...".</p><p>I'd like to ask you what do you think about.</p><p>Let me take advantage of this comment to thank you for this precious blog.</p><p>Giuseppe</p>Validation of compiler and IDE - Why, when and how to? - Part 3 - Mitchurn:md5:629a50a6ae3cd240eedef36f0b8d96f12015-06-01T17:27:36+02:002015-06-01T16:35:30+02:00Mitch<p>Alas, if mgmt wants it, or if an auditor once asked for it, do it as minimal as it can be.</p>
<p>Buy AAMI TIR 36 guidance and do it as they write it in this guidance for compilers. It shouldn't be a massive expense.</p>
<p>But IMHO, this is not a way to validate compilers. It's just a way to make people happy with regulatory requirements.</p>
<p>One last thing, it should be necessary to validate software development tools if they contain records related to regulations. For example, using a tracker tool, like redmine, to manage software requirements and bugs. In this case, yes, it should be validated.</p>Validation of compiler and IDE - Why, when and how to? - Part 3 - zedurn:md5:bc9136afb2c96f009584d56400e031312015-05-21T14:16:40+02:002015-05-21T13:16:40+02:00zed<p>Hi-</p>
<p>So if mgmt has decided that we must validate all software development tools (compilers, make, etc), how might I go about convincing them this is not in the regulation? It is a massive expense, and it seems it is all because an auditor once asked if we had validated our compiler.</p>
<p>Thoughts?</p>Validation of compiler and IDE - Why, when and how to? - Part 3 - Mitchurn:md5:ef362fd62b7369e2cf1f7cc5d0036c932014-04-27T22:15:12+02:002014-04-27T21:15:12+02:00Mitch<p>Hello Heiko,</p>
<p>As I said in the article, these automated data processing systems shall be at first used in production processes, not development processes.</p>
<p>If you use Labview and NI Teststand to test printed circuit boards during production, to eliminate non-compliant batches, then this is an automated data processing system used in production and it is in the scope of ISO 13485 section 7.5 or 21 CFR 820.70. Thus you have to validate it to be compliant with regulations.</p>
<p>If you use Labview and NI Teststand to test a prototype at design time, then you are not in the case above. At design time, you are in section 7.3 of ISO or 21 CFR 820.30. And there is no such requirement to validate software tools used for design.</p>
<p>But:</p>
<p>If you product is very critical, for example a pacemaker, and if odds are not null that a failure of a tool used at design may result in a failure of the final product, then you will have to validate the tool.</p>
<p>For example, there is a chance that there are bugs in CUnit. If a unit test passes, instead of being failed, because of a possible bug in Cunit, then a bug could remain not detected by unit tests. In the case of software embedded in a pacemaker, such bug could result in a failure of the final medical device with severe consequences for the patient. Thus, given the severity of hazards generated by remaining bugs in CUnit, this tool should be validated.</p>Validation of compiler and IDE - Why, when and how to? - Part 3 - Heikourn:md5:b2710c643e0ec6e7a9bf19788044f08a2014-04-24T19:34:13+02:002014-04-24T18:34:13+02:00Heiko<p>Hello</p>
<p>your blog is very interesting for me. I am working as software team manager in a medical device company. Validation of software tools is always a big<br />
discussion.</p>
<p>Can you give me some examples of "automated data processing systems" ? Are for example CUnit, LabView, NI Teststand etc.. automated data processing systems ?</p>
<p>Thanks a lot !</p>MEDDEV 2.1/6 Guidelines on classification of standalone software released! - MassimoMurn:md5:de9333c017f3a6963a8a05df2ebc7bc02013-08-06T11:48:59+02:002013-08-06T13:40:49+02:00MassimoM<p>I think it's clear that it's up to the manufacturer to declare a product as a medical device. You can choose not to declare this. But probably no medical operators will use your system, as they must use only CE marked products</p>