yshrestha

I have been a software consultant for 8 years now so I have a bit of experience to back up my suggestion. Talking to clients did not come easy for me and takes practice just like any other skill. You will learn from experience but I wish I read the book Trusted Advisor by David Maister earlier in my career.

The key is to have empathy and remember one golden rule: It is never about you, make it always about them.

I have a Moonlander keyboard. Here is my layout: https://configure.zsa.io/moonlander/layouts/wEX6q/latest/0

Anyone care to share theirs?

We are 12 (and hiring). All engineers. Each of our client projects only need 2-3 engineers.

We specialize in software only medical devices. Engineers handle the design controls with input from product owners. We even got a product implemented and a 510(k) cleared using RDM and a team of just 3 engineers.

https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPMN/pmn...

It adds a little bit of overhead but we think it results in a better product in the end because engineers are thinking more about building the right thing as opposed to just building the thing right. It also results in a safer product since engineers are thinking about risk as they design and implement the product. Automated documentation generation also cuts down on manual process that required non-technical folks in the first place.

I found this to be a very interesting take of Earth's history from birth to death.

Innolitics | Senior Full Stack Software Engineer | Full time REMOTE

We are a tightly knit group of engineers working to make a difference in patients lives through medical device software development. We are obsessed with code quality and take great pride in our work. We also invest heavily in our team's professional development.

Please see the full job ad here: https://innolitics.com/join/senior-developer

1) AFIAK there are no hard and set rules for this. I think this would have to be the manufacturer's judgement call. Good point though, with enough time you may end up just over-fitting to the test set.

2) The FDA's guidance on ML models is still in flux. Please see https://www.fda.gov/medical-devices/software-medical-device-...

I agree risk management should start at the patient and work backwards to the individual units that themselves can be inputs into an FMEA. When the design gets a bit further along, you can perform an FMEA and repeat the process several times over the course of the design. I am always surprised at how many more risks can be identified by doing the process iteratively and frequently.

Do you recommend any tools that have helped you perform risk analysis?

Good point. My cognitive bias towards SaMDs is standing out here. I am going to borrow your example of what a "configuration" is, if you don't mind.

I am not articulating myself correctly :)

As far as regulatory submissions go and the design outputs that get stored in your QMS, the SDLC appears waterfall because there are clearly defined design inputs, design outputs, and verification / validation checkpoints. In practice, however, the actual process can be agile.

Regulatory requirements usually does box you into a waterfall sdlc. However, that does not stop you from practicing an iterative sdlc internally.

I like to conceptualize it as having a "waterfall shell with an iterative core"

It is not uncommon for us to have new requirements added in the middle of a release. However, once safety testing and clinical validation are performed, changes are pushed to the next version unless a huge safety issue is detected.

Thank you for sharing. These are awesome AI nuggets.

In particular, I can relate to the author's suggestion to "visualize everything."

Agreed. The standards are designed to be impervious to time and the implementations used. This has the unfortunate consequence of being quite abstract and difficult to grasp at first.

For example "configuration management" was meaningless the first time I read it but really just translates to "version control"

I think having an open source example will really help the concepts make sense to engineers implementing this for the first time.

Interesting. I do agree 62304 seems to mostly codify what we would consider best software principles anyway.

Your statement about 14971 being the big shift in thinking is interesting. With a bit of clinical context, do you think developers can write code with risk management in mind?

Thank you for the suggestion!

I actually used the tool myself for my own house hunt. I disliked all the tools out there for the reason you mentioned. I will write an article about my journey in the future.

It certainly does require you to verify coverage. However, it is a good heuristic to see if you are in the right spot.

For my area in Denver it has been quite accurate. I recently found a 5 acre homestead property with fiber next door. I ended up trenching a line myself and I have gigabit speeds!

Indeed. The data is only on a census block level and could have false positives and negatives. Unfortunately, the data is not more granular than the census block level.

Yes. It is a more convenient way to search addresses in bulk. Also makes it easier to identify possible speeds within 500 feet. This is actually how I found my acreage homestead.

Bummer. Admittedly, it is working off of incomplete and possibly old data. The data requires ISPs to self report.

Unfortunately, I am using the FCC form 477 data which is only valid in the US. Do you know of a similar dateset in the UK?

Sure thing. I am using the FCC form 477 data. Unfortunately it relies on ISPs self reporting their coverage data so it may not be fully up to date.

I will have to check to see what the FCC provides. Are you interested in any data in particular?

Co-founder of Innolitics chiming in here

While this is undoubtedly one take on the subject, allow me to give you another perspective:

One of my friends had an MRI taken for suspected nasopharyngeal cancer. The physician that read the scan did not find cancer. Thankfully, his ENT physician did not believe the diagnosis and took another look at his MRI, which happened to be in DICOM format. He was able to load the images on a DICOM compliant image viewer and saw the tumor right away. My friend underwent surgery and was confirmed to have cancer by microscopy.

I think DICOM saved his life. It allowed his ENT physician to take another look, which would have probably been significantly harder with a proprietary file format.

Yujan Shrestha, MD