12 ms·

Death by a Thousand Clicks: Where Electronic Health Records Went Wrong

182 points by jatsign 8y ago

_bxg1 8y ago
If the U.S. doesn't get a first-world healthcare system by the time I'm forty, I'm leaving.
- omegaworks 8y ago
  Between then and now, please help us fight for it. https://medicare4all.org/ https://medicare4all.org/
raincom 8y ago
Epic systems is like gaint SAP. Shitty stuff forced on doctors, nurses, etc.
- adolph 8y ago
  Enterprise software is often [a.] optimized for needs not in alignment with a diverse user population's needs, and [b.] written, configured and customized by different groups of people each with an incomplete understanding of the user populations needs. I think of the situation as that of the "Blind men and the elephant." https://en.wikipedia.org/wiki/Blind_men_and_an_elephant https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
  - jrochkind1 8y ago
    Plus "workflow" -- humans doing certain things in certain orders, entering them in a computer in a process which has components that also involve interacting with other software, non-software organizational systems, humans, and offline tasks -- is one of the hardest things to automate. Because different people in different contexts will have different needs. Not just predilections. And not just because different individuals have idiosyncracies. But because they are inevitably doing _different kinds of work_ in _different organizational systems that are set up differently_, and you're trying to sell the same software to all of them, because it would not be cost effective to give each organization bespoke software. (And as we know, "customization" offers only limited escapes). Not all "enterprise" software might be workflow-centered. But "ERP" systems like SAP are, and so are Electronic Health Records. In spades.
- deleted 8y ago
  [deleted]
jackschultz 8y ago
I'll first say that I haven't read the full article, which frankly, is the same as most everyone who writes a comment. The title and intro reminded me of this piece from the New Yorker a few months ago that written by a doctor and his experiences and others with the computers in the doctor field. HN discussion here: https://news.ycombinator.com/item?id=18381969 https://news.ycombinator.com/item?id=18381969 The summary is that health care, in the US and other countries too, is a giant system where even little changes take time to go through and become accepted. People who say there's an easy solution for electronic records are in no way correct. It's a great read both in the information it gives, and also how good of a write the doctor is. I love his writing style.
- Scoundreller 8y ago
  I agree, not much more info than the New Yorker article. Lots of anecdotes, but what I really care is: do outcomes improve or not? The computer can screw up, but so can the human, so which is better now? Very US-centric too, other than the point about US doctor’s electronic notes being 3-4x as long as rest of world. Is the problem the EHR or the culture? I don’t care about clicks. It’s more crude than using BMI for obesity. Replacing the mouse with a giant scroll wheel won’t improve things despite eliminating clicks. We use mice because they’re excellent human-machine interfaces for most users. (I like keyboard shortcuts, but you shouldn’t design for me). How many minutes/seconds, or units of cognitive load, does it require to order that ibuprofen? And to get that ibuprofen to the from order to patient? Are all of the clicks 10x10 pixel checkboxes on a 2 megapixel display? Is it easy to do the right thing and hard to do the wrong thing? What’s the full-cycle error rate of EHR vs paper requisition? And cost?
  - repolfx 8y ago
    I noticed a lot of the complaints about "problems" with the EHR is in reality mistakes made by humans that the software could theoretically have caught, like bad drug combinations, but it didn't either because the app just wasn't that smart, or because it generated alerts the humans ignored due to warnings overload (presumably itself caused by the risk of lawsuits). This doesn't seem really like an issue with the software per se - paper can't catch mistakes in what you write on it.
dr_ 8y ago
The flaws with eCWs system aside, the larger problem with EHRs, and the fact that to date they have not improved outcomes in any significant way, lies with the fact that they are primarily designed to “optimize” revenue cycle management. Everything has to be documented correctly - or else it can’t be billed for or may get rejected on audit. Hospital staff, including physicians, are responsible for the accuracy of this documentation, but that’s a big responsibility to bear. The only way this may change is if we change how we pay for our care. This is not on the horizon at this time. Even the value based programs that CMS has implemented are really fee for service with a look back and adjustments to payments made based on savings that were encountered.
- will_brown 8y ago
  >Even the value based programs that CMS has implemented are really fee for service with a look back and adjustments to payments made based on savings that were encountered. And let’s not forget one of the more troubling aspects of EHRs and Medicare patients is that physicians are now required to turn over all patient EHR data to the government (CMS) every year for a reimbursement bonus and failure to turn over patient records results in a penalty. Government collecting patient digital health records...what could possibly go wrong?
  - CamperBob2 8y ago
    Was the parent post downvoted because it isn't true, or for some other reason? Explain, please.
  - mynameismonkey 8y ago
    Physicians are in no way required to turn over all patient EHR data. CMS collects quality measures in the aggregate, numerators and denominators. There may be vendors in the middle who are collecting the data to calculate the measures, but the patient-level data does not go to CMS. (Obviously, their claims do, they're a payor.)
  - ballenf 8y ago
    The parent comment gets this a little wrong, but there is truth to the data collection aspect. An increasing number of physicians have to be part of an integrated health network in order to get competitive reimbursement rates. Those networks upload individual patient data to state exchanges which in turn have started to upload to nationwide databases. The rollout of this is staggered and uneven, as of a couple years ago when I stopped working at a company with its own electronic health record product. As a sibling comments correctly notes, the CMS bonus (or absence of penalty) does not depend on direct uploading. It does, however, depend on using a system which has the capability of doing that uploading ('sharing'). Finally, I saw over the past 10 years a giant increase in the number of records audited by health insurers. Those audits involve giving the entire patient file to the insurer. I'm waiting for the day one of these large databases gets compromised and everyone acts shocked that the data was being collected.
adolph 8y ago
I'm glad this finally made it to the front page because it is an important story of how culture and true customers shape software development. Notice that government incentives spurred hospitals to quickly adopt software that physicians (and a whole host of other clinicians and supporting actors) use. Hospitals/Health Systems/etc != Physicians. Some reactions to the article I sent to my team: Bulletpoint summary: [1] “The article includes a brilliant comment from WellSpan SVP/CIO Hal Baker, MD: ‘Physicians have to cognitively switch between focusing on the record and focusing on the patient … I have yet to see the CEO who, while running a board meeting, takes minutes, and certainly I’ve never heard of a judge who, during the trial, would also be the court stenographer. But in medicine … we’ve asked the physician to move from writing in pen to [entering a computer] record, and it’s a pretty complicated interface.’” EPtalk by Dr. Jayne 3/21/19: [2] “The piece hooks the reader by opening with a story that details a patient’s death from a brain aneurysm, with the lack of diagnosis being influenced by failure of the head scan order to be transmitted by her physician’s EClinicalWorks EHR.” Reader Survey Results: How I Would Change EHRs: [3] “There is no perfect technology. Our ability to acknowledge data integration is key is tantamount.” Not related, but also interesting: [4] HIStalk Interviews Grahame Grieve, FHIR Architect and Interoperability Consultant: “A lot of doctors I talk to think about this as a technology problem, but it’s not a technology problem. It’s an information problem, and so technology can’t solve it. It needs clinicians to make clinical agreements in order to get clinical interoperability.” 1. https://histalk2.com/2019/03/19/news-3-20-20/ https://histalk2.com/2019/03/19/news-3-20-20/ 2. https://histalk2.com/2019/03/21/eptalk-by-dr-jayne-3-21-19/ https://histalk2.com/2019/03/21/eptalk-by-dr-jayne-3-21-19/ 3. https://histalk2.com/2019/03/24/reader-survey-how-i-would-change-ehrs/ https://histalk2.com/2019/03/24/reader-survey-how-i-would-ch... 4. https://histalk2.com/2019/03/25/histalk-interviews-grahame-grieve-fhir-architect-and-interoperability-consultant/ https://histalk2.com/2019/03/25/histalk-interviews-grahame-g...
- deleted 8y ago
  [deleted]
- pas 8y ago
  > Physicians have to cognitively switch between focusing on the record and focusing on the patient … I have yet to see the CEO who, while running a board meeting, takes minutes, Aren't doctors usually assigned an assistant? My GP has one, dentists have one. (I'm in Hungary.)
tabtab 8y ago
Which country(s) or company(s) do it the best? Let's learn from others.
- Someone1234 8y ago
  Unfortunately a lot of other countries do it better because they're in a completely different healthcare system. Which is to say that the focus of US EHR systems is billing, the focus in other countries is on patient care. That might sound like a trivial difference, but medical staff at US healthcare providers are required to record significantly more information in order for it to be reimbursed. For example in other countries you aren't recording supply usage on a "by patient" basis, but by ward or even by department. So patient charts are much simpler abroad. So you could copy a foreign EHR system but it would be completely unusable or require so much alteration you might have well start again. The issues are somewhat systemic. Even Medicare which is essentially socialized medicine in the US, has substantially higher documentation requirements than equivalent programs abroad.
  - Scoundreller 8y ago
    Fee-for-Service vs salary makes a difference too. In FFS, the quicker you finish, the quicker you go home for the same pay. When you’re salaried by the health system, it’s an easier sell to enter in your own orders and sell the downstream savings as funding your next pay increase.
- sixothree 8y ago
  Most of the innovation is happening in the FHIR space. And this is a very international space. As far as "interoperability" is concerned, we are all figuring this out together. edit: I should add that US budgeting funds for adding interoperability requirements sure does help.
- tuberelay 8y ago
  Doctor here - honestly, a paper record works great generally. The really useful low hanging fruit of EHR is an electronic portal for radiology results, blood results, discharge summaries and letters. If you have a way to link family doctor/pharmacy prescriptions with hospitals, thats great too. My ideal health IT system assuming perfect AI and everything else would be: - Automatic recording of everything discussed and done between nurses/doctors with no input from the doctor and producing a record which reads in a sensible way - Automatic prompting for things the doctor/nurse was likely missed or should discuss during a consult (but only to a sensible level of detail) - Automatic checking for common ommissions, or things that are being done that perhaps shouldn't be, so a patient who has a microcytic anaemia triggers a check to ask a doctor "do you want to order iron studies on this patient?"
specialist 8y ago
TLDR: Data sharing between competitors ain't gonna work. Data quality is abysmal, requiring more ETL & QA work than you can imagine. -- My team designed, implemented, and supported 5 exchanges. Here's a PR for three of our customers. http://newsroom.questdiagnostics.com/press-releases?item=94548 http://newsroom.questdiagnostics.com/press-releases?item=945... We handled labs, notes, scripts, etc. (Our product didn't touch any of the financials, billing, etc. So I can't speak firsthand to the fraud stuff mentioned in the article.) Everyone involved understood that data sharing between competitors would never be feasible. In other words, useful interchange requires someone with a big stick, such as single payer. The push for ICD-10 (from insurers & consultants?) was ridiculous, is a work multiplier, and has zero benefit for patient care. Our usability was pretty bad, but miles better than others (Epic, Cerner). We had the benefit of a clean slate, but too few resources to hire real, full time UI people. Also, working with (mid 2000s era) doctors was mostly brutal. That said, healthcare is just about one of the most complicated things I've worked on. And rapidly changing. Of course the user experience sucks. I wouldn't expect any of it to improve until the domain settles down. For example, since lab reporting is industry standardized, we were able to do a pretty good job on those UIs/reports.
- nradov 8y ago
  ICD-10 has some benefits for patient care in that it can be more specific than ICD-9. That helps when one provider sends a coded list of patient conditions to another, like for a specialist consultation. By the time ICD-10 was mandated, ICD-9 had been obsolete for years and remaining on that version was no longer tenable. Going forward the whole industry will probably have to upgrade to ICD-11 at some point. It's just a cost of doing business. Like if you write an application targeting Windows XP, eventually Microsoft stops supporting that platform and you have to expect to upgrade occasionally.
  - alligatorbite 8y ago
    ICD-9 had one code for animal bites. ICD-10 has too many codes. My favorite is alligator bites: https://www.icd10data.com/ICD10CM/Codes/V00-Y99/W50-W64/W58-#W58.01 https://www.icd10data.com/ICD10CM/Codes/V00-Y99/W50-W64/W58-... For statistical purposes and public health data, knowing what animal bit people is useful, but from a fee-for-service side, having to determine and adjust the amounts paid for all these new codes seems like unnecessary complications.
jrochkind1 8y ago
> He says Epic uses such insights to improve the client experience. But coming up with fixes is difficult because doctors “have different viewpoints on everything,” he says. This suggests to me they are doing UX design based on "what specific interfaces and interface changes the customer asks for." While common in "enterprise" sales, I think we all know this simply _does not work_. And it's not just an issue of the executives who make the decisions asking for different things than the end-users would. They say it's "doctors" who have "different viewpoints" we can charitably assume they really are getting UX feedback from the end-users not just from executives (I don't really believe it, but let's be charitable). It's that UI/UX design is hard, and "just doing what the customer tells me to do" never works. The customer is not a UX designer. What the customer thinks will help may be a "local miminum" or may not actually help at all. even if it is end-users telling you what they want. end-users may be experts on the problems and frustrations they are having, but not on the design solutions. > “We had all the right ideas that were discussed and hashed out by the committee,” says Mostashari, “but they were all of the right ideas.” > "“The industry was like, ‘I’ve got this check dangling in front of me, and I have to check these boxes to get there, and so I’m going to do that.’ ”" Yup, sounds like enterprise software alright. > “It’s like asking nine women to have a baby in a month.” That's even a paraphrase from Fred Brooks author of "The Mythical Man-Month", although the speaker may not have known it. (Brooks prob wasn't the first one to say it... but might have been about software?) https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law
- snarf21 8y ago
  It is and it is just like Salesforce or Oracle or SAP. It is the people who never have to use the software that buy it and force it on the people who do and they hate every minute of it.
  - LeftTurnSignal 8y ago
    This is exactly right. I used to work at a hospital and some clinics in a previous life. The administration went forward with a new EMR system without actually getting the users to "test" it beyond a webinar. I left before it started to be implemented. Not sure how it went, but it's been 4 years and they're still "working on it" according to some old co-workers still there.
deleted 8y ago
[deleted]
BWStearns 8y ago
Worked for one of these companies and I’m honestly surprised they don’t kill more people. Most of the time I go to a doctor using the one I work on I apologize, and frequently have to help them with a bug or nonsense interface thing. I recently had to get an MRI and forgot to watch the screen while doc was filling out an order. I would have noticed the form not save the second half appropriately (was an existing bug from when I worked there that I wanted to fix but was told no). Ended up delaying my head MRI for a couple weeks. Good thing it turns out there was nothing wrong. Learned my lesson about not giving up arguments where the other person insists a bug is “intended behavior.”
- _bxg1 8y ago
  > was an existing bug from when I worked there that I wanted to fix but was told no Yeesh, I'd quit too.
- Scoundreller 8y ago
  Ah yes, the whole “working as designed” excuse. It’s like ISO9001 approval for your concrete parachute company. Yes, they’re consistent, but they don’t actually work.
0XAFFE 8y ago
At the Chaos Communication Congress last year, there was this talk about electronic health record apps for patients and it shows how insecure they are and also how on an philosophical position they are a not so good idea: https://media.ccc.de/v/35c3-9992-all_your_gesundheitsakten_are_belong_to_us#l=eng https://media.ccc.de/v/35c3-9992-all_your_gesundheitsakten_a... I highly can recommend this talk and would you should be against this kind of apps.
mjevans 8y ago
Where Electronic Health Records went wrong... * Lack of standard, OPEN, free to implement formats; for everything. * That are required as a native format for all vendors considered for selection. * Ironically, HIPPA, which correctly makes collecting data a liability. However this also makes releasing that data to patients difficult. It makes patients authorizing the release to other entities even more difficult. It contributes to making critical data during emergency situations difficult to locate. - Some kind of standard civil contract singing PKI might be a technical solution, but That's beyond the scope of healthcare solutions, it's a national ID / notary issue * Lack of a central registry to at least annotate where patient records exist and can be located. * A multitude of private healthcare cost management organizations (HMOs)** * Artificially constrained supply in non-emergency contexts * No shopping at all during emergency contexts (nor should there be) (HMOs) which seem mostly to focus on for-profit results rather than actually improving quality of care, patient outcomes or actual medical costs; at least in most cases.
- SilasX 8y ago
  In fairness, even HN can't get people to stop using monospace for quoting or prose, so one can understand why it's hard to get providers to adhere to a consistent standard.
  - ams6110 8y ago
    Indeed. I think I am going to start downvoting posts that quote by (or otherwise use) indention. It's unreadable on mobile. Why is this so hard to fix?
    - mjevans 8y ago
      Mostly because HN has a custom markup solution and attempts to reformat single-line breaks, requiring the use of monospace for ANY level of control over formatting at all, and otherwise restricting everything to separated paragraphs that are difficult to read. If I'm wrong and it allow either limited BBcode, white-listed HTML entities for markup, or some flavor of Markdown please let me know. I would love to have ACTUAL bullet points and text that flow wraps per line, with any newline I enter becoming either a P block if it's a paragraph, or a <br> tag if it's not followed by a second newline.
stmw 8y ago
They went wrong, but they don't have to stay that way! Commure is working to make better software for doctors, and if you might be interested in helping fix this - here's our whoishiring post https://news.ycombinator.com/reply?id=19544133 https://news.ycombinator.com/reply?id=19544133
Scoundreller 8y ago
I think there will be a day where we beg to be taken to the Amazon hospital instead of the local hospital. Or maybe the Alibaba hospital. The computers will win, but we’re in Yahoo circa 1995 right now.
- phonon 8y ago
  Perhaps soon... https://www.cnbc.com/2019/02/21/amazon-led-health-ventures-ambitions-outlined-in-court-documents.html https://www.cnbc.com/2019/02/21/amazon-led-health-ventures-a...
Gatsky 8y ago
At my institution, they developed their own EMR in house. And it works really well, presumably because 1) incentives are as well aligned as they could be, and 2) it allows incremental improvement. This latter point is crucial - the basic system went out, everyone could use it and make suggestions, and then other services were gradually integrated (radiology, pathology). The same people working on the EMR keep working on it over (thus far) 7 years. It also was dramatically less expensive than say getting a product from Epic, which is what the next iteration will be. Everyone is worried.
- tim333 8y ago
  >Epic, which is what the next iteration will be. Everyone is worried. Why are they doing that? I'm curious as to the dynamics that make people drop "works really well" for systems that are widely disliked.
  - Gatsky 8y ago
    They are integrating multiple hospitals in the precinct. I guess the thought is that the project complexity is best handled by outsourcing to Epic.
honksillet 8y ago
As a doctor I'm still waiting for the eMacs of EHRs/EMRs. Something with a bit a learning curve but where your hands rarely need to leave the keyboard. And where you have emmet like intellisense.
caycep 8y ago
On a side note - there are a ton of EMR startups, but do any implement a doctor/provider-friendly UI w/ some sort of native or web interface, that meets some minimum amount of HHS/medicare bullet points? Something designed to make writing a H&P or SOAP note (a typical clinical document describing a visit) as easy as possible? We use Allscripts and (when it's actually up and not crashing), it's painful to even type in the thing...the lag is so bad. Data support is terrible, and the thing suffers from "too much UI" syndrome in that to add any information requires too much button clicking to open dialog/selector boxes in a UI/architecture that clearly can't support it. (let's put it this way, they make you use Internet Explorer to launch some Active X app that fires up Remote Desktop into their app which runs on some underpowered instance of Windows Server 2003 or something) At this point I'd settle for something that shows the letters on the screen right when I type them...
deleted 8y ago
[deleted]
oneepic 8y ago
(disclaimer: I used to work on EHRs, hence the name...) This article is melodramatic and terrible, and I feel sorry for anyone who gets their opinion on EHRs from it. It reads like some kind of expose, like it's uncovering some disturbing truths and showing the reader that our system is totally broken, or something. Not true at all, it's just that some people have bad experiences that get sensationalized and put into an attention-grabbing news piece. And then people read it and only hear about the bad stuff. As someone who's worked in EHRs, I can tell you we're a lot better off with EHRs than ever before (particularly compared to hospitals that used to put everything on paper, in a freaking file cabinet...) and we're just improving with time. Granted, bad EHR software does exist out there, but as a whole we make patient care significantly better. I put some real examples below. I think we have tons of anecdotal evidence pointing to the positive impact of EHRs, but I'll admit we don't have many statistics either (good or bad). I think you basically have to work in the EHR/healthcare space to see the positive impacts for yourself, but I hope this post helps people see the good things we do, too. + Catching medication administration and other procedural errors that would lead to patient harm and death + Allowing patient info to be accessible at other hospitals, when it's needed to adequately care for a patient (real example that has happened countless times: patient comes into the ER unconscious, but has a nametag; nurse uses it to look up the pt in the system, but he's never been to that hospital before. No problem; nurse requests his record from the hospital he has been to, and gets his whole history, allergies, etc so they can better determine a cause and what treatment is OK for the patient) + Allowing anonymized patient data to be used for population health and other research; a doctor used this to catch the Flint, MI water crisis + Nurses/docs can just look up patient info in one system instead of searching through an ever-growing file cabinet, or having to go get their paper record from another department, etc. It's just all in one place. Hospital admins can more easily run anonymized reports/statistics on their patients, departments, etc. to see how everything's going. + EHRs are able to suggest tests or screens for the patient depending on their symptoms and their whole medical history (which, again, is all in one place). In some cases, this is just a nice reminder for the provider, but in other cases can indicate something deeper is going on with the patient that really needs to be tested. + Sending prescriptions to pharmacies is often automatic instead of needing a call, which essentially removes another point of failure. Sending information about specimens, like blood tests or scans, can also be automatic depending on the EHR. + Patients may have a patient portal with the EHR that gives them a view of their past history/visits and provides an easy way to request prescription refills, schedule appointments (no call required!), and receive test results.
fgonzag 8y ago
Mandate truly electronic record portability by making a common format, designed by a comitee of stake holders (doctors, EHR companies, etc). All EHR systems have to be able to massively import and export records from and to this format, by law. Reducing the friction to swap providers should give a good jolt of energy to the industry (reducing moats encourages new competition)
hackerDoc 8y ago
Y Combinator Posting, Death by a 1000 Clicks Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen then. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. You remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR stupid. Not an EHR. When we stared automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. You ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variable are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variable are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...
hackerDoc 8y ago
Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen then. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. You remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR stupid. Not an EHR. When we stared automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. You ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variable are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variable are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...
hackerDoc 8y ago
Y Combinator Posting, Death by a 1000 Clicks Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen then. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. You remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR stupid. Not an EHR. When we stared automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. You ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variables are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variables are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...
hackerDoc 8y ago
Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen then. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. You remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR stupid. Not an EHR. When we stared automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. You ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variables are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variables are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...
hackerDoc 8y ago
Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen them. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. Do you remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is: "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR, stupid. Not an EHR. When we started automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. Have you ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variables are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variables are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...

182 points by jatsign 8y ago

_bxg1 8y ago

If the U.S. doesn't get a first-world healthcare system by the time I'm forty, I'm leaving.

omegaworks 8y ago
Between then and now, please help us fight for it. https://medicare4all.org/ https://medicare4all.org/

raincom 8y ago

Epic systems is like gaint SAP. Shitty stuff forced on doctors, nurses, etc.

adolph 8y ago
Enterprise software is often [a.] optimized for needs not in alignment with a diverse user population's needs, and [b.] written, configured and customized by different groups of people each with an incomplete understanding of the user populations needs. I think of the situation as that of the "Blind men and the elephant." https://en.wikipedia.org/wiki/Blind_men_and_an_elephant https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
- jrochkind1 8y ago
  Plus "workflow" -- humans doing certain things in certain orders, entering them in a computer in a process which has components that also involve interacting with other software, non-software organizational systems, humans, and offline tasks -- is one of the hardest things to automate. Because different people in different contexts will have different needs. Not just predilections. And not just because different individuals have idiosyncracies. But because they are inevitably doing _different kinds of work_ in _different organizational systems that are set up differently_, and you're trying to sell the same software to all of them, because it would not be cost effective to give each organization bespoke software. (And as we know, "customization" offers only limited escapes). Not all "enterprise" software might be workflow-centered. But "ERP" systems like SAP are, and so are Electronic Health Records. In spades.
deleted 8y ago
[deleted]

jackschultz 8y ago

I'll first say that I haven't read the full article, which frankly, is the same as most everyone who writes a comment. The title and intro reminded me of this piece from the New Yorker a few months ago that written by a doctor and his experiences and others with the computers in the doctor field. HN discussion here: https://news.ycombinator.com/item?id=18381969 https://news.ycombinator.com/item?id=18381969 The summary is that health care, in the US and other countries too, is a giant system where even little changes take time to go through and become accepted. People who say there's an easy solution for electronic records are in no way correct. It's a great read both in the information it gives, and also how good of a write the doctor is. I love his writing style.

Scoundreller 8y ago
I agree, not much more info than the New Yorker article. Lots of anecdotes, but what I really care is: do outcomes improve or not? The computer can screw up, but so can the human, so which is better now? Very US-centric too, other than the point about US doctor’s electronic notes being 3-4x as long as rest of world. Is the problem the EHR or the culture? I don’t care about clicks. It’s more crude than using BMI for obesity. Replacing the mouse with a giant scroll wheel won’t improve things despite eliminating clicks. We use mice because they’re excellent human-machine interfaces for most users. (I like keyboard shortcuts, but you shouldn’t design for me). How many minutes/seconds, or units of cognitive load, does it require to order that ibuprofen? And to get that ibuprofen to the from order to patient? Are all of the clicks 10x10 pixel checkboxes on a 2 megapixel display? Is it easy to do the right thing and hard to do the wrong thing? What’s the full-cycle error rate of EHR vs paper requisition? And cost?
- repolfx 8y ago
  I noticed a lot of the complaints about "problems" with the EHR is in reality mistakes made by humans that the software could theoretically have caught, like bad drug combinations, but it didn't either because the app just wasn't that smart, or because it generated alerts the humans ignored due to warnings overload (presumably itself caused by the risk of lawsuits). This doesn't seem really like an issue with the software per se - paper can't catch mistakes in what you write on it.

dr_ 8y ago

The flaws with eCWs system aside, the larger problem with EHRs, and the fact that to date they have not improved outcomes in any significant way, lies with the fact that they are primarily designed to “optimize” revenue cycle management. Everything has to be documented correctly - or else it can’t be billed for or may get rejected on audit. Hospital staff, including physicians, are responsible for the accuracy of this documentation, but that’s a big responsibility to bear. The only way this may change is if we change how we pay for our care. This is not on the horizon at this time. Even the value based programs that CMS has implemented are really fee for service with a look back and adjustments to payments made based on savings that were encountered.

will_brown 8y ago
>Even the value based programs that CMS has implemented are really fee for service with a look back and adjustments to payments made based on savings that were encountered. And let’s not forget one of the more troubling aspects of EHRs and Medicare patients is that physicians are now required to turn over all patient EHR data to the government (CMS) every year for a reimbursement bonus and failure to turn over patient records results in a penalty. Government collecting patient digital health records...what could possibly go wrong?
- CamperBob2 8y ago
  Was the parent post downvoted because it isn't true, or for some other reason? Explain, please.
- mynameismonkey 8y ago
  Physicians are in no way required to turn over all patient EHR data. CMS collects quality measures in the aggregate, numerators and denominators. There may be vendors in the middle who are collecting the data to calculate the measures, but the patient-level data does not go to CMS. (Obviously, their claims do, they're a payor.)
- ballenf 8y ago
  The parent comment gets this a little wrong, but there is truth to the data collection aspect. An increasing number of physicians have to be part of an integrated health network in order to get competitive reimbursement rates. Those networks upload individual patient data to state exchanges which in turn have started to upload to nationwide databases. The rollout of this is staggered and uneven, as of a couple years ago when I stopped working at a company with its own electronic health record product. As a sibling comments correctly notes, the CMS bonus (or absence of penalty) does not depend on direct uploading. It does, however, depend on using a system which has the capability of doing that uploading ('sharing'). Finally, I saw over the past 10 years a giant increase in the number of records audited by health insurers. Those audits involve giving the entire patient file to the insurer. I'm waiting for the day one of these large databases gets compromised and everyone acts shocked that the data was being collected.

adolph 8y ago

I'm glad this finally made it to the front page because it is an important story of how culture and true customers shape software development. Notice that government incentives spurred hospitals to quickly adopt software that physicians (and a whole host of other clinicians and supporting actors) use. Hospitals/Health Systems/etc != Physicians. Some reactions to the article I sent to my team: Bulletpoint summary: [1] “The article includes a brilliant comment from WellSpan SVP/CIO Hal Baker, MD: ‘Physicians have to cognitively switch between focusing on the record and focusing on the patient … I have yet to see the CEO who, while running a board meeting, takes minutes, and certainly I’ve never heard of a judge who, during the trial, would also be the court stenographer. But in medicine … we’ve asked the physician to move from writing in pen to [entering a computer] record, and it’s a pretty complicated interface.’” EPtalk by Dr. Jayne 3/21/19: [2] “The piece hooks the reader by opening with a story that details a patient’s death from a brain aneurysm, with the lack of diagnosis being influenced by failure of the head scan order to be transmitted by her physician’s EClinicalWorks EHR.” Reader Survey Results: How I Would Change EHRs: [3] “There is no perfect technology. Our ability to acknowledge data integration is key is tantamount.” Not related, but also interesting: [4] HIStalk Interviews Grahame Grieve, FHIR Architect and Interoperability Consultant: “A lot of doctors I talk to think about this as a technology problem, but it’s not a technology problem. It’s an information problem, and so technology can’t solve it. It needs clinicians to make clinical agreements in order to get clinical interoperability.” 1. https://histalk2.com/2019/03/19/news-3-20-20/ https://histalk2.com/2019/03/19/news-3-20-20/ 2. https://histalk2.com/2019/03/21/eptalk-by-dr-jayne-3-21-19/ https://histalk2.com/2019/03/21/eptalk-by-dr-jayne-3-21-19/ 3. https://histalk2.com/2019/03/24/reader-survey-how-i-would-change-ehrs/ https://histalk2.com/2019/03/24/reader-survey-how-i-would-ch... 4. https://histalk2.com/2019/03/25/histalk-interviews-grahame-grieve-fhir-architect-and-interoperability-consultant/ https://histalk2.com/2019/03/25/histalk-interviews-grahame-g...

deleted 8y ago
[deleted]
pas 8y ago
> Physicians have to cognitively switch between focusing on the record and focusing on the patient … I have yet to see the CEO who, while running a board meeting, takes minutes, Aren't doctors usually assigned an assistant? My GP has one, dentists have one. (I'm in Hungary.)

tabtab 8y ago

Which country(s) or company(s) do it the best? Let's learn from others.

Someone1234 8y ago
Unfortunately a lot of other countries do it better because they're in a completely different healthcare system. Which is to say that the focus of US EHR systems is billing, the focus in other countries is on patient care. That might sound like a trivial difference, but medical staff at US healthcare providers are required to record significantly more information in order for it to be reimbursed. For example in other countries you aren't recording supply usage on a "by patient" basis, but by ward or even by department. So patient charts are much simpler abroad. So you could copy a foreign EHR system but it would be completely unusable or require so much alteration you might have well start again. The issues are somewhat systemic. Even Medicare which is essentially socialized medicine in the US, has substantially higher documentation requirements than equivalent programs abroad.
- Scoundreller 8y ago
  Fee-for-Service vs salary makes a difference too. In FFS, the quicker you finish, the quicker you go home for the same pay. When you’re salaried by the health system, it’s an easier sell to enter in your own orders and sell the downstream savings as funding your next pay increase.
sixothree 8y ago
Most of the innovation is happening in the FHIR space. And this is a very international space. As far as "interoperability" is concerned, we are all figuring this out together. edit: I should add that US budgeting funds for adding interoperability requirements sure does help.
tuberelay 8y ago
Doctor here - honestly, a paper record works great generally. The really useful low hanging fruit of EHR is an electronic portal for radiology results, blood results, discharge summaries and letters. If you have a way to link family doctor/pharmacy prescriptions with hospitals, thats great too. My ideal health IT system assuming perfect AI and everything else would be: - Automatic recording of everything discussed and done between nurses/doctors with no input from the doctor and producing a record which reads in a sensible way - Automatic prompting for things the doctor/nurse was likely missed or should discuss during a consult (but only to a sensible level of detail) - Automatic checking for common ommissions, or things that are being done that perhaps shouldn't be, so a patient who has a microcytic anaemia triggers a check to ask a doctor "do you want to order iron studies on this patient?"

specialist 8y ago

TLDR: Data sharing between competitors ain't gonna work. Data quality is abysmal, requiring more ETL & QA work than you can imagine. -- My team designed, implemented, and supported 5 exchanges. Here's a PR for three of our customers. http://newsroom.questdiagnostics.com/press-releases?item=94548 http://newsroom.questdiagnostics.com/press-releases?item=945... We handled labs, notes, scripts, etc. (Our product didn't touch any of the financials, billing, etc. So I can't speak firsthand to the fraud stuff mentioned in the article.) Everyone involved understood that data sharing between competitors would never be feasible. In other words, useful interchange requires someone with a big stick, such as single payer. The push for ICD-10 (from insurers & consultants?) was ridiculous, is a work multiplier, and has zero benefit for patient care. Our usability was pretty bad, but miles better than others (Epic, Cerner). We had the benefit of a clean slate, but too few resources to hire real, full time UI people. Also, working with (mid 2000s era) doctors was mostly brutal. That said, healthcare is just about one of the most complicated things I've worked on. And rapidly changing. Of course the user experience sucks. I wouldn't expect any of it to improve until the domain settles down. For example, since lab reporting is industry standardized, we were able to do a pretty good job on those UIs/reports.

nradov 8y ago
ICD-10 has some benefits for patient care in that it can be more specific than ICD-9. That helps when one provider sends a coded list of patient conditions to another, like for a specialist consultation. By the time ICD-10 was mandated, ICD-9 had been obsolete for years and remaining on that version was no longer tenable. Going forward the whole industry will probably have to upgrade to ICD-11 at some point. It's just a cost of doing business. Like if you write an application targeting Windows XP, eventually Microsoft stops supporting that platform and you have to expect to upgrade occasionally.
- alligatorbite 8y ago
  ICD-9 had one code for animal bites. ICD-10 has too many codes. My favorite is alligator bites: https://www.icd10data.com/ICD10CM/Codes/V00-Y99/W50-W64/W58-#W58.01 https://www.icd10data.com/ICD10CM/Codes/V00-Y99/W50-W64/W58-... For statistical purposes and public health data, knowing what animal bit people is useful, but from a fee-for-service side, having to determine and adjust the amounts paid for all these new codes seems like unnecessary complications.

jrochkind1 8y ago

> He says Epic uses such insights to improve the client experience. But coming up with fixes is difficult because doctors “have different viewpoints on everything,” he says. This suggests to me they are doing UX design based on "what specific interfaces and interface changes the customer asks for." While common in "enterprise" sales, I think we all know this simply _does not work_. And it's not just an issue of the executives who make the decisions asking for different things than the end-users would. They say it's "doctors" who have "different viewpoints" we can charitably assume they really are getting UX feedback from the end-users not just from executives (I don't really believe it, but let's be charitable). It's that UI/UX design is hard, and "just doing what the customer tells me to do" never works. The customer is not a UX designer. What the customer thinks will help may be a "local miminum" or may not actually help at all. even if it is end-users telling you what they want. end-users may be experts on the problems and frustrations they are having, but not on the design solutions. > “We had all the right ideas that were discussed and hashed out by the committee,” says Mostashari, “but they were all of the right ideas.” > "“The industry was like, ‘I’ve got this check dangling in front of me, and I have to check these boxes to get there, and so I’m going to do that.’ ”" Yup, sounds like enterprise software alright. > “It’s like asking nine women to have a baby in a month.” That's even a paraphrase from Fred Brooks author of "The Mythical Man-Month", although the speaker may not have known it. (Brooks prob wasn't the first one to say it... but might have been about software?) https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law

snarf21 8y ago
It is and it is just like Salesforce or Oracle or SAP. It is the people who never have to use the software that buy it and force it on the people who do and they hate every minute of it.
- LeftTurnSignal 8y ago
  This is exactly right. I used to work at a hospital and some clinics in a previous life. The administration went forward with a new EMR system without actually getting the users to "test" it beyond a webinar. I left before it started to be implemented. Not sure how it went, but it's been 4 years and they're still "working on it" according to some old co-workers still there.

deleted 8y ago

[deleted]

BWStearns 8y ago

Worked for one of these companies and I’m honestly surprised they don’t kill more people. Most of the time I go to a doctor using the one I work on I apologize, and frequently have to help them with a bug or nonsense interface thing. I recently had to get an MRI and forgot to watch the screen while doc was filling out an order. I would have noticed the form not save the second half appropriately (was an existing bug from when I worked there that I wanted to fix but was told no). Ended up delaying my head MRI for a couple weeks. Good thing it turns out there was nothing wrong. Learned my lesson about not giving up arguments where the other person insists a bug is “intended behavior.”

_bxg1 8y ago
> was an existing bug from when I worked there that I wanted to fix but was told no Yeesh, I'd quit too.
Scoundreller 8y ago
Ah yes, the whole “working as designed” excuse. It’s like ISO9001 approval for your concrete parachute company. Yes, they’re consistent, but they don’t actually work.

0XAFFE 8y ago

At the Chaos Communication Congress last year, there was this talk about electronic health record apps for patients and it shows how insecure they are and also how on an philosophical position they are a not so good idea: https://media.ccc.de/v/35c3-9992-all_your_gesundheitsakten_are_belong_to_us#l=eng https://media.ccc.de/v/35c3-9992-all_your_gesundheitsakten_a... I highly can recommend this talk and would you should be against this kind of apps.

mjevans 8y ago

Where Electronic Health Records went wrong... * Lack of standard, OPEN, free to implement formats; for everything. * That are required as a native format for all vendors considered for selection. * Ironically, HIPPA, which correctly makes collecting data a liability. However this also makes releasing that data to patients difficult. It makes patients authorizing the release to other entities even more difficult. It contributes to making critical data during emergency situations difficult to locate. - Some kind of standard civil contract singing PKI might be a technical solution, but That's beyond the scope of healthcare solutions, it's a national ID / notary issue * Lack of a central registry to at least annotate where patient records exist and can be located. * A multitude of private healthcare cost management organizations (HMOs)** * Artificially constrained supply in non-emergency contexts * No shopping at all during emergency contexts (nor should there be) (HMOs) which seem mostly to focus on for-profit results rather than actually improving quality of care, patient outcomes or actual medical costs; at least in most cases.

SilasX 8y ago
In fairness, even HN can't get people to stop using monospace for quoting or prose, so one can understand why it's hard to get providers to adhere to a consistent standard.
- ams6110 8y ago
  Indeed. I think I am going to start downvoting posts that quote by (or otherwise use) indention. It's unreadable on mobile. Why is this so hard to fix?
  - mjevans 8y ago
    Mostly because HN has a custom markup solution and attempts to reformat single-line breaks, requiring the use of monospace for ANY level of control over formatting at all, and otherwise restricting everything to separated paragraphs that are difficult to read. If I'm wrong and it allow either limited BBcode, white-listed HTML entities for markup, or some flavor of Markdown please let me know. I would love to have ACTUAL bullet points and text that flow wraps per line, with any newline I enter becoming either a P block if it's a paragraph, or a <br> tag if it's not followed by a second newline.

stmw 8y ago

They went wrong, but they don't have to stay that way! Commure is working to make better software for doctors, and if you might be interested in helping fix this - here's our whoishiring post https://news.ycombinator.com/reply?id=19544133 https://news.ycombinator.com/reply?id=19544133

Scoundreller 8y ago

I think there will be a day where we beg to be taken to the Amazon hospital instead of the local hospital. Or maybe the Alibaba hospital. The computers will win, but we’re in Yahoo circa 1995 right now.

phonon 8y ago
Perhaps soon... https://www.cnbc.com/2019/02/21/amazon-led-health-ventures-ambitions-outlined-in-court-documents.html https://www.cnbc.com/2019/02/21/amazon-led-health-ventures-a...

Gatsky 8y ago

At my institution, they developed their own EMR in house. And it works really well, presumably because 1) incentives are as well aligned as they could be, and 2) it allows incremental improvement. This latter point is crucial - the basic system went out, everyone could use it and make suggestions, and then other services were gradually integrated (radiology, pathology). The same people working on the EMR keep working on it over (thus far) 7 years. It also was dramatically less expensive than say getting a product from Epic, which is what the next iteration will be. Everyone is worried.

tim333 8y ago
>Epic, which is what the next iteration will be. Everyone is worried. Why are they doing that? I'm curious as to the dynamics that make people drop "works really well" for systems that are widely disliked.
- Gatsky 8y ago
  They are integrating multiple hospitals in the precinct. I guess the thought is that the project complexity is best handled by outsourcing to Epic.

honksillet 8y ago

As a doctor I'm still waiting for the eMacs of EHRs/EMRs. Something with a bit a learning curve but where your hands rarely need to leave the keyboard. And where you have emmet like intellisense.

caycep 8y ago

On a side note - there are a ton of EMR startups, but do any implement a doctor/provider-friendly UI w/ some sort of native or web interface, that meets some minimum amount of HHS/medicare bullet points? Something designed to make writing a H&P or SOAP note (a typical clinical document describing a visit) as easy as possible? We use Allscripts and (when it's actually up and not crashing), it's painful to even type in the thing...the lag is so bad. Data support is terrible, and the thing suffers from "too much UI" syndrome in that to add any information requires too much button clicking to open dialog/selector boxes in a UI/architecture that clearly can't support it. (let's put it this way, they make you use Internet Explorer to launch some Active X app that fires up Remote Desktop into their app which runs on some underpowered instance of Windows Server 2003 or something) At this point I'd settle for something that shows the letters on the screen right when I type them...

deleted 8y ago

[deleted]

oneepic 8y ago

(disclaimer: I used to work on EHRs, hence the name...) This article is melodramatic and terrible, and I feel sorry for anyone who gets their opinion on EHRs from it. It reads like some kind of expose, like it's uncovering some disturbing truths and showing the reader that our system is totally broken, or something. Not true at all, it's just that some people have bad experiences that get sensationalized and put into an attention-grabbing news piece. And then people read it and only hear about the bad stuff. As someone who's worked in EHRs, I can tell you we're a lot better off with EHRs than ever before (particularly compared to hospitals that used to put everything on paper, in a freaking file cabinet...) and we're just improving with time. Granted, bad EHR software does exist out there, but as a whole we make patient care significantly better. I put some real examples below. I think we have tons of anecdotal evidence pointing to the positive impact of EHRs, but I'll admit we don't have many statistics either (good or bad). I think you basically have to work in the EHR/healthcare space to see the positive impacts for yourself, but I hope this post helps people see the good things we do, too. + Catching medication administration and other procedural errors that would lead to patient harm and death + Allowing patient info to be accessible at other hospitals, when it's needed to adequately care for a patient (real example that has happened countless times: patient comes into the ER unconscious, but has a nametag; nurse uses it to look up the pt in the system, but he's never been to that hospital before. No problem; nurse requests his record from the hospital he has been to, and gets his whole history, allergies, etc so they can better determine a cause and what treatment is OK for the patient) + Allowing anonymized patient data to be used for population health and other research; a doctor used this to catch the Flint, MI water crisis + Nurses/docs can just look up patient info in one system instead of searching through an ever-growing file cabinet, or having to go get their paper record from another department, etc. It's just all in one place. Hospital admins can more easily run anonymized reports/statistics on their patients, departments, etc. to see how everything's going. + EHRs are able to suggest tests or screens for the patient depending on their symptoms and their whole medical history (which, again, is all in one place). In some cases, this is just a nice reminder for the provider, but in other cases can indicate something deeper is going on with the patient that really needs to be tested. + Sending prescriptions to pharmacies is often automatic instead of needing a call, which essentially removes another point of failure. Sending information about specimens, like blood tests or scans, can also be automatic depending on the EHR. + Patients may have a patient portal with the EHR that gives them a view of their past history/visits and provides an easy way to request prescription refills, schedule appointments (no call required!), and receive test results.

fgonzag 8y ago

Mandate truly electronic record portability by making a common format, designed by a comitee of stake holders (doctors, EHR companies, etc). All EHR systems have to be able to massively import and export records from and to this format, by law. Reducing the friction to swap providers should give a good jolt of energy to the industry (reducing moats encourages new competition)

hackerDoc 8y ago

Y Combinator Posting, Death by a 1000 Clicks Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen then. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. You remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR stupid. Not an EHR. When we stared automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. You ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variable are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variable are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...

hackerDoc 8y ago

Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen then. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. You remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR stupid. Not an EHR. When we stared automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. You ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variable are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variable are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...

hackerDoc 8y ago

Y Combinator Posting, Death by a 1000 Clicks Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen then. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. You remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR stupid. Not an EHR. When we stared automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. You ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variables are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variables are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...

hackerDoc 8y ago

Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen then. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. You remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR stupid. Not an EHR. When we stared automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. You ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variables are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variables are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...

hackerDoc 8y ago

Fair warning: put on your flame-retardant suits; the following rant contains adult content and is for mature audiences only. I started my career as a professional software engineer, where I worked on porting the UNIX kernel to an SMP machine, then I went to grad school in CS, with a focus on database theory and AI, back when AI was unfashionable and NOT funded by the NSF or DARPA, and then I went on to medical school. I'm also an industry insider, having worked for one of the larger (marketshare-wise) EMR companies. So I'm a doc. A real one. As in I spent 4 years busting my ass at a top college, where I graduated phi beta kappa, while all the privileged white frat boys spent most of their college time getting drunk and fucking all the cheerleaders. Then I spent another five sleep-deprived years as an underpaid resident. Now that you know my credentials, let's get a few things straight: 1. Physicians HATE Epic. It's responsible for an epidemic of physician burnout. I personally know physicians who have refused to work for the companies that acquired their practices because they were told they'd have to use Epic after the acquisition was finalized. And I personally know physicians who have left the practice of medicine AFTER being forced to use Epic. It just wasn't worth it to them. 2. The non-disparagement clauses are true. I've seen them. You are not allowed to talk about the very real patient harm and threats to patient safety that Epic has caused. Epic's CareEverywhere merges the wrong patient data across health systems way too often. These are HIPAA violations. But the health systems refuse to report the HIPAA violations because of the civil and criminal fines they would face, not to mention the violation of the non-disparagement clauses. I've seen it first-hand. It's all too real. And patients have been harmed. But no one has ever outed this problem. 3. Do you remember the old trope: "No one gets fired for buying IBM"? The modern equivalent is: "No one gets fired for buying Epic." In reality, the health systems' C-Suites are clueless; they don't listen to their physicians. Their only concern is their job security; not their patient's welfare, and not the mental health of the physicians that they employ. To them, physicians are replaceable commodities. 4. Health systems purchased Epic in the FALSE belief that it would pay for itself via Medicare bonus payments. Bullshit. It never did, and it never will. Magical thinking is too fucking prevalent in the health systems' C-Suites. And there's no sign of it ending. 5. It's an EMR, stupid. Not an EHR. When we started automating the paper chart (medical record), we called it an ELECTRONIC MEDICAL RECORD. Then some suit -- a non-clinically-trained MBA/marketing bozo -- came along and decided to rebrand it as an EHR (Electronic Health Record). Guess what. It's an ELECTRONIC version of the MEDICAL RECORD. I really don't give a shit if some magical-thinking homeopathy-prescribing naturopath, or some nurse practitioner who wants to play doctor, is offended because we are using the term MEDICAL rather than HEALTH. It's an electronic version of the fucking medical record. Get fucking used to it. 6. Have you ever heard of MUMPS, as in the Multi-User Medical Information System? It's what Epic is based on. MUMPS was designed in 1966 at the MGH Laboratory for Computer Science by a team working under the direction of Dr. Octo Barnett, a physician/computer scientist. Dr. Barnett is (was) a fucking genius. He figured out how to build a database-enabled multi-user OS and run it on a DEC PDP 6 with only 128K of RAM and 5MB of disk storage. Think about it. That's K, as 128x1024 bytes of RAM. And 5MB, not 5GB, not 5TB, but 5MB of disk storage. Way the hell less RAM and non-volatile storage than in that computer in your pocket that wants you to think it's nothing more than a phone on steroids. Could you write a multi-user OS with persistent storage that run in 128K RAM? I didn't think so. A few fun facts about MUMPS, the engine that powers Epic: a) MUMPS uses a hierarchical database design, and was developed four years before Dr. Edgar Codd published his seminal paper on the set-theoretical relational model for data. No self-respecting professional software engineer uses a hierarchical database. b) MUMPS variable names are/were limited to three characters in length. Imagine writing a complex piece of software where your variable naming scheme is limited to three-character variable names. But remember, this had to run within 128K of RAM. c) All variables are global in scope. There is no encapsulation. Um. Ever tried to implement recursion where all variables are global in scope? Or how about RPN notation, as in the shunting yard algorithm? Not happening. d) All character data values are limited in length to 1024 Bytes. So a text note that is 1500 characters has to be stored in a linked list. Or not. Epic just truncates long notes to 1K. e) All variables are persistent. As in -- they represent data storage elements on the disk. Huh? Again, this was a great design for a PDP 6 with 128K RAM and 5MB disk. But not for today's architectures. f) No such thing as a transaction. So no commit or rollback or ACID compliance. g) None of the first tier computer science programs teach their students how to program in MUMPs. Why would they? But I'll bet you can find an open-enrollment "university" -- a diploma mill where your ability to pay tuition is the only requirement for matriculation -- that is willing to teach MUMPS programming skills. Bottom line: Epic is the technological equivalent of the 1966 Corvair. Advanced for its time. But that was more than 50 years ago. Wouldn’t you rather own and drive a 2019 Tesla Model S? Flame off...