Hacker News Reader

Comment by not_the_fda | Hacker News Reader

I've worked on a variety of medical devices: CT scanners, patient monitors, infusion pumps, radiation therapy devices, contrast injectors, dialysis machines, assistive devices for the blind.

Last year I had to go to the ER it was pretty cool to see that some of the equipment was stuff I've worked on. I needed a CT scan with contrast, I had worked on the standards body that defined the protocol that allowed CT scanner talk to a contrast injector, and they were using the device I worked on with the feature I defined and implemented.

Its pretty cool to see your work keep you alive.

View on HN

I’ve worked on medical device stuff too, and it’s not like anything else. I’ll never forget the first time I found out that code I’d written had saved someone’s life. I’d done plenty of awesome things, and in that moment they all felt small.

That's fascinating. Sadly, based on the quality of software engineering I've witnessed (and produced) over my career, if I were to find myself having to trust my life with any of it, I would be terrified.

That's when you beat on the code until you aren't scared. Don't let the code out the door until you've unit tested, integration tested, QA'd it to hell and back.

If it's some random cat pic frontend website code and it breaks, yeah whatever, just fix it as it breaks because you have the luxury of hourly deploys. but on the other side of the spectrum, if you're writing firmware and it's isn't remotely updatable, you don't just sling the code over the wall in the same way. in that realm you have the luxury of an actual spec and a less complicated system.

everyone gets scared. what you do in the face of it is up to you.

Pick a good IDE, set it to the most pedantic mode you can, and work on the code until there are no errors, no warnings, and only acceptable info notifications.

Have a good test suite with realistic scenarios. Add more to that all of the time.

Get outside feedback on whether you documentation and diagrams are readable and keep them up to date.

If you can do that, you can write mission critical code.

I had to deal with some of projects you mention. At least where I'm from (italy), we rely on a bunch of old proprietary and very sh* technologies that I think it's really killing patients (metaphorically speaking... or maybe not...). The thing is that most of people aren't asking AI/the superb cure, but something that just works.

I'm fairly familiar with infusion pumps, where bad software regularly kills patients. Just look up "infusion pump software recall" and you'll find dozens and dozens of very recent examples of how bad software implementations have led to a lot of preventable deaths.

I have some friends trying to fix this[1] and they have amazing tech, but it's a difficult industry to break in to.

1. https://www.altrainfusion.com/

> protocol that allowed CT scanner talk to a contrast injector

was this part of the DICOM protocol?

i have worked with medical imaging devices as well, but was not fortunate enough to work with the CT modality. cool stuff!

No DICOM is more for imaging. This is a real-time control protocol over CAN-Open. https://www.can-cia.org/can-knowledge/canopen/cia425/

User name checks out

Reply on news.ycombinator.com