Death by a Thousand Clicks: Where Electronic Health Records Went Wrong
fortune.com
fortune.com
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.
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?
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.
The clue is right here. This is how complexity in the private health insurance market drives costs and inefficient outcomes into every other aspect of our health care. A thousand different plans each with different billing standards and the software reflects the need to focus on making sure you can meet all the billing standards.
Billing codes are already standardized.
The hospitals here mostly use US systems, minus the billing modules of course.
I'd much rather be paying for the time of my doctor to treat me instead of fighting my insurance company armed with a similarly high-overhead software package.
https://www.healthaffairs.org/do/10.1377/hblog20110920.01339...
"The private insurance equivalent of Medicare would cost almost 40 percent more in 2022 for a typical 65-year old."
Medicare for All would make medicare even more efficient.
Since Medicare reimbursements are so much lower than private insurance - the consequence of moving to all Medicare would have immense consequences, and the dollars removed would Largely need to be replaced, or quality and access to care would be dramatically impacted
And social security works today...
"European Vacation" is a real problem. The future is Greece, Italy and Spain.
Greece does have economic problems, but the ~3% of their GDP they spend on health care is almost laughable.
There might be some "encouragement-fees" for doctors necessary, but overall they seem to be fine.
disclaimer: I am not Greek and the rumors about corruption for services are just that: rumors.
edit: Not saying everything is dandy, there are some dark sides of some systems (insurance obligations etc.)
Government workers are cheap. The UnitedHealthcare ceo made $100M a few years ago.
The Administrator of the US Centers for Medicare and Medicaid Services has a salary of $165,000.
I don’t envy the person making that kind of money, but given that the government can do a similar task cheaper, I question the legitimacy of the boards decision to pay an excessive amount, which impacts the profitability of the firm.
Also, charts naturally had an efficiency, due to the space limitations on them. Now there are endless fields.
One more organization to sue, and one other entity for everyone else to blame.
Agree 100% on this. The incentives in a fee-for-service world are just so badly misaligned with the goals of functional healthcare system.
> 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.
So CMS is acutely aware that merit-based adjustments on top of a fee-for-service model is an incremental improvement (and a very modest increment at that). So within the Medicare's Quality Payments Program, there is MIPS (Merit-based Incentive Payment System) which is exactly what you describe and where most providers default to right now. But there are also several APMs (Alternative Payment Models) that providers can elect to participate in, some of which have full or partially-capitated payment mechanisms where there is a fixed fee per beneficiary, rather than the fee-for-service model. Everything I've heard from CMS suggests that APMs are the future and fee-for-service needs to go away. That's not going to happen over night but MIPS is the narrow end of the wedge to get us there.
I work in inpatient now, but I previously worked for a radiology group that was cashpay focused. The total cost for a brain MRI at most locations was over 10x less than the technical component alone for the hospital I'm currently working for.
What I would like to see is a comparison of truly foreign EHRs.
FTFA, non-US clinicians write up much shorter notes in the same EHR. So there’s something about the pressures on the US user that don’t exist elsewhere.
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
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.
This is the key here. We have continuously designed our healthcare system for “quick-fix” instead of the right solution that takes longer. Even the HITECH push for EHR adoption and Meaningful Use - twisted the arms of providers to find and use an EHR before they could be built to positively impact patient care.
* 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)
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.
Mobile is good for getting and sending small updates, and consuming videos at lunch.
The issues come down to:
* Issue 1...
* Issue 2...
* Issue 3...
(double newlines). Sure it's not as compact, but I'd take "less compact than it could be" over "entirely unreadable for 50% of users".
If they had just created all of those standards and central systems _before_ rolling out EHR to everyone, I doubt it would have gone any better, honestly.
The articles does go into some of the social/political influences that led to a requirement or incentives for everyone to have EHS before anyone knew what it was going to look like, at a speed that prevented incremental piece-by-piece development of the ecosystem and adjustments to requirements, standards, and best practices based on what was found.
Without such an incremental process, I think it would be doomed no matter what.
I was surprised when I talked to a doctor family member awhile back and learned that this was not part of the ACA. A big sweeping re-write of the health care regulatory structure would have been a good time to require data interoperability.
Maybe the new plans both parties are supposedly interested in getting done this time around will include this. I won't hold my breath though.
HL7 has had open standards for moving data between systems for 30+ years. But actually building those interfaces takes a lot of work. Every EHR has its own propriety internal data model so there's always some data mapping and conversion needed.
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.
Yeesh, I'd quit too.
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
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.
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?
This doesn't seem really like an issue with the software per se - paper can't catch mistakes in what you write on it.
Paper records are straightforward. You read through them completely and then go to work. If you don't do that, you're taking on a risk that you missed something important. EHRs can make that a little harder by obfuscating the history, only pulling up parts of the history at once, etc.
I think there's an interesting role to play for AI in creating useful, readable summaries of medical records that physicians can use. Probably too hard to get right to prevent accidentally censoring information that was important.
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/
2. 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-ch...
4. https://histalk2.com/2019/03/25/histalk-interviews-grahame-g...
Aren't doctors usually assigned an assistant? My GP has one, dentists have one. (I'm in Hungary.)
There are certainly scribes out there and some docs use them, but the practice is hardly universal nor is it without cost. And, of course, some are better and more accurate than others.
An assistant specifically for documentation is known as a "scribe." This person follows a physician and does all the typing into the EHR so the doc can focus on the patient. My children's pediatrician recently recently started using one and it does allow the physician to focus more on the patient. My understanding is that they have to pay for the scribe out of their own pocket.
GPs get money from our NHS thing (it's called Country Healthcare Treasury), after patient visits and after assigned patients (patients can choose their GP), but they have to bear the fixed costs (leasing an office, scribe, etc). Since the GP system is sort of overloaded, there seems to be enough money for every GP to afford a scribe.
It's much less common in hospitals though.
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...
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.
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.
Or maybe the Alibaba hospital.
The computers will win, but we’re in Yahoo circa 1995 right now.
--
My team designed, implemented, and supported 5 exchanges. Here's a PR for three of our customers.
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.
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.
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.
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.
edit: I should add that US budgeting funds for adding interoperability requirements sure does help.
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?"
Reducing the friction to swap providers should give a good jolt of energy to the industry (reducing moats encourages new competition)
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.
> >+ Catching medication administration and other procedural >errors that would lead to patient harm and death
Depends on the end user. EMR medication checking is only as good as the tech who put the bar codes on the bags. I've seen a number of med errors b/c nursing blithely scanned "correct" barcodes on wrong meds. Other meds are routinely ordered wrongly or the errors are so useless the ordering MD/RN just clicks through them to dismiss.
The best hedge against med errors are hiring dedicated pharmacists per floor double-checking the orders.
> + Allowing patient info to be accessible at other hospitals, when it's needed to adequately care for a patient (...)
This never happens. EMRS are not routinely interoperable with each other. Especially EPIC who prides itself on lock in and exclusivity.
We always get records printed out and faxed.
>+ Allowing anonymized patient data to be used for population health and other research; a doctor used this to catch the Flint, MI water crisis
Maybe if you're the head honcho w/ top level access and a bunch of EPIC minions to do this for you. For the average med student/resident/grad student....eh. Did you ever try and get broad clinical data out of EPIC or Cerner or anything else? It takes a huge amount of technical head scratching the way everything is implemented. Most pilot projects w/ academic centers still have a fellow or resident click through each record and gather data manually for their research. Otherwise a huge committee is required to wave their arms to...download data from a MUMPS database.
+ 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.
It's one system but the data is hidden away in a thousand clicks. There have been attempts to make "dashboard/portal" interfaces in EPIC but I suspect the API's and toolkits are not really there...no self respecting MD trusts those.
+ 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.
Again - depends on the implementation. Maybe in the ideal world, but most of the errors and suggestions that pop up are considered nuisances and not correct.
+ 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.
For e-scribe, this is gradually getting better - we still have to sometimes resort to fax or phone scripts for a lot of this.
For lab tests - it's still an issue, we never reliably get "e-results" that automagically pop into our EHR. It's still fax. A lot of it may rest of implementations of lab providers (Quest, LabCorp, etc) but whatever the reason, this still sucks.
+ 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.
We paid our megacorp EHR for this feature but it's "down" most of the time. Other companies may have better uptime. AT least for test results and records. YMMV also for scheduling...calls are still pretty much required in that we have to screen insurances for patients who are actually allowed to see us, rather than have them show up at appointment time and get denied by their HMO.
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...