Home > On-Demand Archives > Q&A Sessions >
Live Q&A - A Medical Device Primer for Embedded Software Engineers
Jeff Gable - Watch Now - Duration: 25:12
Thanks Tim! Thankfully attitudes are changing -- I remember hearing people say "You can't use X because it's not validated for medical" when any reasonable, informed person would understand that the quality of the final product would be improved, sometimes greatly so, by using X. There's still a lot of inertia from those years.
Hi Jeff,
Thank you for such a well-researched and informative presentation. I will hang on to your slides for dear life! Also, I didn't realize that you have so many good resources on your website.
I have a question about certification for off-the-shelf software similar to an RTOS. That software is generic and medical device vendors integrate it with their application software for specific products. How shall I approach the Hazard & Risk Analysis in this case, for example? I understand that you cannot provide here any detailed answers, but perhaps you could outline a general strategy. (I mean, integrating something like an RTOS should be fairly common.) Also, what kind of documentation would be most useful and time-saving for the customers of such software? Perhaps you could point me to some resources that I could buy, borrow, or steal.
Thanks a lot!
--Miro
I was thinking similarly while listening to Mohamed Billoo's talk on Zephyr. I would approach it as a SOUP component in the terminilogy of IEC 62304 -- a Third Party Software Component in the terminology used in "Medical Device Cybersecurity for Engineers and Manufacturers" (A better term in my book). I would still have to write tests for the functionality I include, right? So if I include a USB driver on my Zephyr config, how extensively must I verify that subsystem? That could end up being very expensive! Or do I need to simply test for the functionality (and associated failures identified in my Risk Analysis) that I will use for my device?
Yes, I'm interested in how you'd approach your RTOS and vendor libraries, for example.
-dan'l
As extensively as necessary to satisfy yourself that it doesn't pose risk of harm! What harm comes if that USB driver fails in some way? For instance, if I have a user interface implemented on a tablet, and it's communicating with a hard-real-time application running on a microcontroller over USB, then the microcontroller code needs to be able to go to safe state as appropriate if it loses communication with the user interface. Which is something you'd need anyway, regardless of the form of communication. This covers any failure of the USB SOUP code. That one mitigation (go to safe state on loss of communications with the user interface, checked with periodic messages at the "application" level of the comm stack) is sufficient to mitigate many different possible failures. Make sense?
Makes sense.
My mind was harkening back to a USB driver for a DO-178C Level B project with a USB driver on a μC/OS-II runtime. When we looked at the complexity of writing unit tests for coverage, it became a daunting task -- and ultimately killed the project. Thankfully, it's very unlikely that my USB driver will be in a class 3 safety level module -- and the FDA doesn't specify decision coverage or condition coverage requirements.
This is one way that Medical Device is actually less stringent than aerospace.
Hi Miro, thanks for the great question. I realize that I promised you such a conversation a long time ago when you came on the Agile Embedded podcast, and we never had it!
You can see an example of what a RTOS supplier promises in their "safety certification package" here: https://www.plm.automation.siemens.com/global/en/products/embedded/nucleus-safetycert.html
Basically, they provide all the documents that are specified by IEC 62304. Since they (and presumably you, with the QP frameworks) want to target all safety-critical industries, not just medical, they will have documentation packages that reflect the unique requirements of each industry's particular safety standard (ISO 26262 for automotive, DO-178C for aerospace, etc).
There is a great deal of overlap in the requirements of all these standards. They would just format those documents according to each industry so they are easy to consume.
For the Hazard and Risk Analysis, there are two parts. First is the process you follow to make sure that your library (QP and its siblings) meets its requirements, and the documentation of all the risks you can think of internal to your software and how you mitigate them. Second is a "Safety Manual" which tells your customers/users what THEY must do when incorporating your software into theirs.
- Check return values and react appropriately (common sense, yes, but good to specify)
- Monitor event queue usage and ensure no overflow (as you mention, this is just as bad for Actor Model software as stack or heap overflow is for an RTOS)
I'm happy to talk again offline and go into specifics that fit your particular case.
Jeff, Thank you for a well ordered and fairly comprehensive overview of Medical Device development. You hit the nail omn the head over and over again with your comments on less-then-good practices you see -- I see many of the same.
I think this presentation could benefit from a reformation of the classic IEC 62304 process diagram. Something with that line of chevrons wrapping around on themselves and repeated per feature... per cycle. I think of Agile Medical Device Development in terms of many iterations of mini-V models, sometimes with some larger cycles at a slower pace.
I appreciate your methodical and well-ordered presentation -- it almost makes medical deveice development seem easy. :-)
Hope to be there tomorrow for Q&A.
-dan'l
Thanks for the kind words!
We mirrored your thoughts exactly on a recent episode of the Agile Embedded Podcast -- "Agile vs V-Model". The V-Model captures all the steps necessary to develop quality software, but you should never use it to describe the timing or sequence of those activities at the project level. It's great when you use the V-model many many times in an iterative fashion, per feature, per change, per cycle.
Listen to that episode here:
https://agileembeddedpodcast.com/episodes/agile-vs-v-model
Like I said in the Q&A, I wouldn't describe medical device development as "easy", but I do want to convey that it is "NOT MAGIC". It is a skill that can be learned and cultivated.
16:34:09 From Quantum Leaps : In your presentation you mentioned tools for requirements traceability. What are some of such tools popular among your customers in the medical business? 16:36:15 From Quantum Leaps : Also, speaking of tools, which static analysis tools are popular in medical? 16:36:27 From Quantum Leaps : Also, how important is MISRA-C compliance? 16:37:36 From Quantum Leaps : What do you think if HTML documentation? Would this be accepted? 16:38:31 From Dan Rittersdorf : Risk Analysis for Safety and Security are similar but not the same process. How resks are scored for Safety and Security is different. Verification for Cybersecurity requires a certain skillset also. Either way, those that do it need to be able to prove they're competent. What are some ways to get that training for each type of Risk Analysis, and what's re3ally needed to prove competence? Can you recommend training resources? Other ways to become and prove competence? 16:40:24 From Kate Stewart : Have you started seeing requests for SBOM generation? 16:42:04 From René Andrés Ayoroa : Hi Jeff, what do you think are required skills for junior embedded developers to get in the medical industry? 16:42:22 From Aaron Olowin : How detailed do your own processes need to be documented and is there a preferred format for that? 16:43:00 From BobF : Validation of any RTOS choice must be a headache - requires a significantly high level of due diligence? 16:43:25 From Dan Rittersdorf : Replying to "Risk Analysis for Sa..." Thanks! 16:44:29 From Quantum Leaps : How to help customers in generation of SBOM? Would the provision of SPDX-License-Identifier in the source code be helpful? Would it be sufficient? 16:44:52 From Kate Stewart : Side note: 1 config option change will create auto generated SPDX SBOMs for the entire build (including toolchain) for Yocto. 16:46:33 From Dan Rittersdorf : Comment: The FDA is already requiring Cybersecurity plans now. They're just handholding companies through the process between now and October. No free pass even now, but in October, the handholding will turn into RTA letters. 16:49:44 From Kate Stewart : Also SBOMs for Zephyr: see https://docs.zephyrproject.org/latest/develop/west/zephyr-cmds.html#software-bill-of-materials-west-spdx and video overview at https://www.zephyrproject.org/generating-sboms-for-iot-at-build-time/ 16:49:56 From BobF : Rings a bell .... 100% deterministic 16:50:56 From Quantum Leaps : SafeRTOS comes from Wittenstein High Integrity Systems 16:53:51 From Aaron Olowin : The time-triggered OS is likely based on: https://www.safetty.net/publications 16:54:25 From BobF : Got it ! 16:54:36 From Quantum Leaps : Do you see state machines used in medical? 16:55:16 From Keith J : agree - plan to use Miro's stuff in my next project 16:55:20 From Keith J : albeit non-medical :D 16:55:36 From Keith J : Thanks again Jeff! 16:56:06 From Quantum Leaps : Yes, thank you, Jeff! 16:56:07 From René Andrés Ayoroa : Thank you Jeff. 16:56:08 From Doinita Marcu : Thank you! 16:56:11 From Aaron Olowin : Thanks Jeff! Your podcast is good too. 16:56:21 From Dan Rittersdorf : Thank you, Jeff! 16:56:30 From Keith J : keep the podcast coming! 16:56:44 From Stephane to Jeff Gable(Direct Message) : Thank you Jeff!!! 16:56:48 From BobF : Very much about being on the ball, thanks!
Hi Jeff, thanks for a great presentation :) I recently joined a company working on medical devices and have been trying to rapidly familiarise myself these standards. It's quite interesting how some software techniques - such as unit testing and CI - have been pioneered in industries which are generally not seen as "safety critical". I think you explained clearly what the thoughts on this have been and why they are changing.
Cheers, Tim