Hire people who aren’t proven

Sorry if I went afield. I think my answer got a bit rambly. I appreciate you clarifying what you're aiming for, and I'll try to edit this response to the same level of clarity. Hopefully.

I'm going to have to give my response in a couple of posts, since HN says it was too long.

> My outside knowledge is that a medical facility focuses on: diagnosis, confirmation of diagnosis, selection of treatment along with annotations about EXCEPTIONS to standard treatment, finally actual treatment

The first thing to clarify is: there are a number of different types of medical facilities, ranging from private primary care to massive, regional specialty care hospitals, and the modifications to the above really depend on what type we're discussing. I'll pitch my answer to small-to-mid-sized secondary care (bread and butter specialty care like cardiology; general surgery, some onco surgery; little or no sub-specialty care) because that's the most commonly encountered facility. That's with the caveat that, again, the answer to that is different from other facilities (e.g., your family care practice) that are just as important to discuss.

Your list of things facilities focus on is correct except for your idea of annotations of exceptions. Our documentation focuses on the entirety of the patient encounter, all of the physical and laboratory exam findings we consider pertinent, our treatment choices, and often some degree of our treatment rationale. Outside observers often think "well, don't you just give a standard CHF treatment to someone with CHF, unless there's an exception?" A large purpose of our standard documentation is to provide an outside observer the chance to recreate how we came to our conclusions regarding diagnosis and the best course of treatment. In short, we document to cover our asses from malpractice.

Second, we document so that the hospital can bill insurers. Insurers create increasingly specific requirements for what must have been done or detected before a service can be provided - and those things must be in our note (or else the insurer assumes it didn't happen), and must be linked in our writing (Patient had finding X therefore we did Y). Increasingly, if one doesn't link it, they argue that they couldn't infer that Y was because of X. (That comes up more with performance metrics - oh, you told the patient to lose weight? We didn't realize that was meant to be an intervention for being overweight. We can't just assume what you mean to be treating.)

Lastly, we document for government and insurer mandated performance metrics. For instance, I need to do a depression screening for all over-65s annually. So, a helpful person working on our EMR built-in a reminder tab - did you do a depression screening today? I have to go through a drop-down to select "No", and then another for reason why ("Already Performed", "Patient Not Eligible", "Patient Already Diagnosed with Depression") about 30 times a day. That's our simplest metric, and one of dozens (because there's not a consistent set of metrics across all insurers.) You're about to suggest a way that this can be automated to suck less. I can suggest that, too, but as you may have noticed, this program is paid for by the hospital, to benefit the hospital's performance with insurers and the government. Physicians aren't the customers. Dev time is committed to making it suck less for us only enough to keep us from storming the hospital with pitchforks and catapults hurling ICD10 printouts.

And, lastly, something I truly didn't understand when I worked in health insurance but I do now: there's absolutely no such thing as a standard patient, plus or minus exceptions. The reason for that is because there's no such thing as "a patient with CHF". There's "a patient with history X, which leads me to believe they have CHF subtype 2C, with complications X, Y, Z, and complicating factors 1 and 2." Good doctors keep all diagnoses provisional, because the evolution over time will absolutely change your understanding of the patient - whether to CHF subtype 1Zebra or because what you thought was Complication Y and Z was actually parallel disease Ampersand. This is why we constantly communicate the story of the patient's history to one another, and why every doc takes their own history. Accepting a diagnosis from someone at hand-off is called a "chart rumor," and making a habit of it is a fantastic way of mis-treating patients. I cannot possibly tell you how many times I've improved patient care by just starting over from zero rather than accepting a chart rumor.

3.

> The NTSB...

We have what are called "morbidity and mortality conferences." If something goes to shit, the doc responsible gets to take the stage in front of his and all related departments next week, and explain the entire course of the medical episode and the decisions taken at each step, while being monday-morning quarterbacked by every doctor they're even vaguely familiar with. The episode is also forward to Quality Improvement, which is a hospital-led group looking to address systemic and process errors. And, lastly, malpractice suits are the final inspection.

When docs fuck up, there isn't a shortage of post-mortem. None of that does anything to shield physicians from malpractice liability.

(An exception: if you operate in a FQHC - federally qualified health center - for the underprivileged, and you maintain a QI program that meets government standards and audits, the government assumes your facility's liability risk. But physicians are still fire-able at the end of the day as part of the QI process, so the incentive for Cover Your Ass medicine remains.)

"Bad Doctors" are a rarity, in my experience. What is more an issue is "doctors good enough to practice good medicine under modern time constraints, and those that aren't." Not everyone can manage a complex patient in 3 minutes. In fact, most can't. But with everyone squeezing down hard on reimbursement, that's become a necessity. No one wants to pay for the time that good care requires. So, docs default to shotgun medicine - throw all the tests at the patient so you can't be accused of overlooking something, and hope that something comes back unambiguously positive. Next patient.

> In your specific case, I believe having a single payer system would improve the outcome related to the above considerations. Affected individuals would still be covered by 'the system', good doctors would not be burdened by specific negative outcomes that happened to occur under their care, and bad workers of any type would be removed.

I think I should clarify what a single payor is. It's often abused in popular literature to mean something like "government monopoly on healthcare." It's more literal than that, though: it's a single payor. So that can mean things like:

a) A government monopoly on healthcare, where all healthcare facilities and providers are owened by the government, paid by the government, etc. HC is distributed as a utility, and people assume it is covered by their taxes (UK) or they pay a nominal fee (Canada, if I'm not mistaken).

b) Government monopoly on health insurance, but healthcare facilities and providers remain private competitive entities. Healthcare provision remains fragmented as a competitive market, but at least these facilities can expect uniform negotiations and documentation across all their patients, since they're all coming in with the same insurer. Patients expect their care to be covered by their taxes, premiums, or some combination of the two. This is closest to "Medicare for All."

c) Regional monopolies on health insurance. As per "b", except that inter-state entities continue to see some heterogeneity in payors. This regional monopoly might be governmental (e.g., Medicaid For All) or private (such as areas where only one private insurer is available.)

None of these things change the liability landscape directly, although in "a" malpractice liability is usually assumed by the government as hc providers are employees. This doesn't eliminate CYA concerns, but does shift them from "do everything the patient wants, whether or not it's best for them" to "follow local policy and guidelines, whether or not it's best (for the patient)."

> Also of note is that for a 'single payer' system the costs SHOULD be divorced from the actual treatment; though might be a considered criteria when a given standard of treatment is selected.

Why is that? Regardless of who the single payor is, they have budgetary constraints. The appetite for healthcare is infinite compared to resource inputs. Someone is going to be squeezed to make those resource allocations. Currently it's the physicians, but if not physicians, someone else.

Honest question, I’m not trying to denigrate anyone who takes an interest in software development for its own sake.

But would you consider someone passionate if they said that they only care about learning a language/technology/framework that is marketable and doesn’t believe in learning for its own sake?

Unless the Python developer is actually writing C++, I don’t think he would ever need to learn the intricacies of C to be a good developer.

But take that opinion with a large grain of salt. I spent 12 years bit twiddling in C/C++, 10 in C#, and have been doing Python for a grand total of 6 months so I definitely haven’t done anything complicated with Python.

Passion => interest => knowledge.

Nah obviously not. I just listed what I know. I mean looking at the list you could maybe tell that I'm mostly interested in programming language implementation (I forgot to list all my Linux and Windows sysops skills that I've gained from years of managing said systems).

The end result is, that (1) my knowledge and skills extend way beyond any of my past or present job descriptions, and (2) (this is probably even more important for employers/productivity) that I'm capable of, and curious enough to actually want to, learning quickly/deeply and solving hard problems that might not have an obvious instant-knowledge-based solution.

I think that anyone that has ever had an interest to go "beyond" (in any way) the obvious, or immediately what's necessary in his/her day job, would built such a knowledge base - but could of course be completely unrelated to mine (e.g. networking specialist, cryptography geek, hardware/embedded engineer, ...).