Home > On-Demand Archives > Talks >
A Medical Device Primer for Embedded Software Engineers
Jeff Gable - Watch Now - Duration: 37:59
The medical device space is rapidly evolving and becoming more open to, and accepting of, technologies and practices from other industries. While the pace is slower and the documentation requirements are more extensive than for consumer electronics, the medical device industry is ripe for disruption and presents a great opportunity for embedded developers to bring skills they’ve honed elsewhere.
This talk is an introduction to what embedded developers should understand if they want to work on medical devices. I’ll introduce relevant safety standards and regulatory pathways, explain Design Controls and risk analysis, bust myths about using open source software, and give an insider view to the industry.
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.
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