Hacker News Reader

Comment by throwaway0a5e | Hacker News Reader

I can't be the only one that called it as soon as I read the word "pacemaker". Nice to see that the hospital still went through the troubleshooting flow chart though.

View on HN

Do you have a background in cardiology? It may be more likely that the pacemaker would jump out to you as the cause because you're not familiar with the other possible causes.

Purely binary performance, it's either working or it's not, is common for digital electronics and rare for body parts. Body parts tend to work less and less well and there's a threshold where it starts causing problems down the line. Body parts also don't tend to have intermittent failures where they can toggle between "working fine" and "not at all" rapidly whereas electronics do.

Once they stated that she had electronics in her that became obvious as a likely source of the problem.

Binary states aren't super rare in biological processes. All the causes the doctor outlines are plausible. My first thought was orthostatic hypotension (it's not at all uncommon for people to pass out almost instantly when they go from supine to standing), or some sort of obstructive shock (with cardiac tamponade being the most likely). Both of those conditions are massively more likely than the pacemaker being intermittently connected, so it make sense to rule out the higher probability options first.

What I'm not sure about is why they started doing diagnostic tests (especially ones where the patient was quite clear on what the outcome was going to be) without an IV in place...

The way I saw is it like doing a commit bisect. While there were other problems before, this particular problem started after the pacemaker operation, the other problems had stopped. It is like a one bug is fixed and another was created. Either the operation or the device itself was the most likely cause of the change in such a short time frame?

In software dev a bug being created as side effect solving another usually means QC missed it, perhaps here too?

I don't know if surgeons do checklists or some else normally verifies post op on the procedure( peer review?), and are there ways to verify the device before and after insertion , if it was software dev that's what I would recommend . While surgeries and medical practice has lot of regulations and it cannot be changed easily, the principles are sound, and other fields like airline pilots do similar things.

I totally get where you're coming from. I'm a full time developer, and part-time paramedic. There are definitely a lot of similarities between debugging a program and debugging a person.

The doctor in the post was also working off the base assumption that this was a bug that got shipped in the last release (surgical complication leading to interval bleeding, leading to hypotension; surgical complication leading to cardiac tamponade; etc). My original point was just that the answer that was obvious to the commenter was actually pretty low on the probability list, and it only seemed obvious because they had an incomplete mental model of the system as a whole (something that happens in software debugging as well). As it turns out, it was the correct answer, but the correct approach (on average) would still put "failure of the pacing leads" pretty low on the list of likely causes.

There are a lot of checklists used in surgery. For instance, immediately before any procedure, there is a "time out" to make sure everyone is on the same page with the right patient, right procedure, and right location. I'm not aware of any checklists specific to pacer leads, but I don't spend much time in the OR these days.

Same here, but then again, that article is from 2012 and I am sure I've read it before and connected the dots immediately.

I didn't call it, but I did guess some sort of electrical disconnect.

Reply on news.ycombinator.com