Hacker News new | past | comments | ask | show | jobs | submit login

There are no such things as 'minor surgical issues'. Any surgery can lead to complications, no matter how minor the original ailment. Not knowing anything more than what you've outlined above various risk calculators give between 5 and 10% risk of (serious) complications. Depending on the particulars that could go down, or up much further but since you're seeing this as 'minor' even the low band of that range (around 5%) is sufficiently high to make you pause.

Surgery is a risky thing, no matter how 'minor' you perceive it to be.




In this case all the issues were avoidable if they had followed procedure which they didn't. I have evidence of this.

When I did the first poat surgery BP obs run (6 hours later - nurses had skipped her in post op, doctors not seen her either!!!) and found she was 70/40 @ 149bpm with 93% o2 saturation then I assure you its juat negligence. Plus they picked the wrong surgical method and placed the ports too close together so the laparoscopy had no chance of success.

(I had another life before EE and software which was a little closer to the ground on this). I prefer to appear as ignorant as I can tell the difference between facts and fuzz.


I believe you. The problem is that surgery is complex and people are fallible. So things do tend to be forgotten and sometimes it's not a problem and in other cases it explodes into complications possibly even resulting in death.

The statistics outlined above reflect this, it includes the element labeled as 'human error' (assuming they are up-front about this, which is in a litigious society not usually the case).

A friend of mine almost had his wife bleed to death during delivery, she lost pretty much all her blood and was going out when they located a doctor capable of diagnosing the problem on the spot. He's a pretty tough guy and never at a loss for immediate solutions to whatever problems appear in life. He's never been so helpless. If not for one doctor out of a whole pile of people who happened to be there that seemed to be making things worse rather than better she'd have died. And that's 'routine childbirth' in the hospital (which they push you very much here to avoid, do it at home, so much more fun and natural)... Life is fragile, and as soon as you start cutting things or delivering babies or such then you're at risk. Routine tonsil surgery, hernias, gal bladders etc have left people with serious complications or in the morgue.

I've had more than I would like to do with the insides of hospitals in the last couple of years and I try to avoid having procedures done unless they are absolutely necessary. I don't play the lottery either...


The problem here is that we have a safeguard system which is a strictly defined set of processes and experience passed on from senior staff under the guise of "airway management", "infection control" etc.

When these processes are not followed and no effort is made to even acknowledge their existence then it is no longer within the realms of human error. It is just negligence.

This is the majority case when someone dies. They literally just left someone or skipped something or overlooked something they do every time successfully.

We expect risk but we expect reasonable mitigation strategies rather than none.

When this happens there is no excuse. None at all. Not a statistic, not a human error allocation, nothing. The same as if I can't be bothered to QA a change, roll it out and it screws up a client's financial data.


It is the similar. Lets take that as an example:

You make a change, start running tests to make sure nothing is broken. It's the end of Friday and you don't finish the testing. You close everything down and on Monday you forget you had a last few tests still to complete. You pass the change into your build process and it makes it into a release. You didn't follow the process… not because you maliciously decided to skip testing, it was simply a human mistake (slightly different to your comment, but let's be charitable and assume most people aren't purposefully breaking things).

Does tracing the problem and firing you stop it happening again? Does it even stop you from making the same kind of error again in ten years time when memory has dimmed? In the end you've lost your job and your company has lost someone who probably did good work for many years (and would no doubt continue to do so in the future) over a single easily made mistake (however big the fallout from that mistake). You're also much more likely to try and bury your mistake if you know it will cost you your job.

On the other hand what about adding a step to your build process where a second person runs the testing while they review your code? No one gets sacked, everyone learns something and the chances of this happening to anyone else are massively reduced. Is the person who made an understandable mistake any more to blame than the manager who oversees the process as a whole? They allowed flaws in the process that meant your mistake could get into a release. It’s rarely as simple as one person making a mistake.

I'm simplifying of course, if your build process is anything like ours there are multiple levels this would be caught at... which is kind of the point. In our development process there are four places this error would be caught before it made it to an official release. If our release goes wrong the worst that happens is we annoy the people using the software, yet we've built up a (reasonably) robust process in exactly the way described in the article.

It’s as the article says: When a space shuttle crashes or an oil tanker leaks, our instinct is to look for a single, “root” cause. This often leads us to the operator: the person who triggered the disaster by pulling the wrong lever or entering the wrong line of code. But the operator is at the end of a long chain of decisions, some of them taken that day, some taken long in the past, all contributing to the accident; like achievements, accidents are a team effort.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: