
Death by a Thousand Clicks: Where Electronic Health Records Went Wrong - jatsign
http://fortune.com/longform/medical-records/
======
dr_
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
>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?

~~~
ballenf
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.

------
jrochkind1
> 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
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
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.

------
mjevans
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
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
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
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.

~~~
frosted-flakes
Have you tried to read your original post on mobile? It's a nightmare. Please
don't use code blocks for prose.

~~~
mjevans
I don't try to get real work done on mobile; it just isn't a good media for
reading or composing anything complex, and a large threaded forum IS complex.

Mobile is good for getting and sending small updates, and consuming videos at
lunch.

~~~
frosted-flakes
Reading HN is not "real work", it's entertainment.

~~~
TeMPOraL
OP is talking about _writing_ long-form comments on HN. I guess you could
consider this "entertainment" too, but it doesn't change the fact that
smartphones are bad for this task.

~~~
frosted-flakes
That's completely tangential to the fact that code blocks should not be used
for prose, because it makes it difficult to read.

------
Gatsky
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
>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
They are integrating multiple hospitals in the precinct. I guess the thought
is that the project complexity is best handled by outsourcing to Epic.

------
BWStearns
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.”

~~~
Scoundreller
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_.

------
jackschultz
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
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
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.

~~~
projektfu
I got the impression that people were complaining that such concerns are
easily hidden in the confusion of the interface. With paper records, perhaps
the hospital would have a system of making the summary page of the record
(which is supposed to be updated before it gets put away) have important
information about drug allergies, etc. In the EHR it may be 10 or 12 point
text tucked into one line at the top or bottom of the screen and may not be
visible on every page. Some physicians also have to deal with several
different EHRs depending on where they're working on a given day.

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.

------
adolph
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-
ch...](https://histalk2.com/2019/03/24/reader-survey-how-i-would-change-ehrs/)

4\. [https://histalk2.com/2019/03/25/histalk-interviews-
grahame-g...](https://histalk2.com/2019/03/25/histalk-interviews-grahame-
grieve-fhir-architect-and-interoperability-consultant/)

~~~
pas
> 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.)

~~~
classichasclass
An assistant to write my notes? Wow, that would be great. I've been practicing
for 12 years and haven't had one yet. (Primary care/public health.)

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.

~~~
hadlock
When I had an accident in Dallas in 2012, the specialist at Baylor general had
a foot pedal-activated recorder (one of those micro cassette tape deals), and
then sent off his recorded notes to be transcribed. 1970s technology. Seemed
pretty effective.

~~~
classichasclass
I used to dictate everything when I did hospitalist work. It seemed pretty
efficient and notes were in the chart within hours. There's a cost there too,
but it might be better borne by tertiary facilities and medical centers. It's
the small offices where the expense can only be spread over a couple docs.

------
caycep
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...

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

~~~
adolph
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
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.

------
0XAFFE
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_a...](https://media.ccc.de/v/35c3-9992-all_your_gesundheitsakten_are_belong_to_us#l=eng)

I highly can recommend this talk and would you should be against this kind of
apps.

------
Scoundreller
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
Perhaps soon...

[https://www.cnbc.com/2019/02/21/amazon-led-health-
ventures-a...](https://www.cnbc.com/2019/02/21/amazon-led-health-ventures-
ambitions-outlined-in-court-documents.html)

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

~~~
omegaworks
Between then and now, please help us fight for it.

[https://medicare4all.org/](https://medicare4all.org/)

------
specialist
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=945...](http://newsroom.questdiagnostics.com/press-
releases?item=94548)

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
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
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-...](https://www.icd10data.com/ICD10CM/Codes/V00-Y99/W50-W64/W58-#W58.01)
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.

~~~
nradov
It's a hierarchical code system so there's no additional complication for
payers. They can just set a single coverage policy and reimbursement rate for
all animal bites.

------
honksillet
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.

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

~~~
tuberelay
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?"

~~~
hackerDoc
That's the system we're building. We've been at it for over three years. Not
long before we leave stealth mode and switch from R&D to commercialization.
We're internally-funded, which means we don't answer to investors, we don't
have to live in SV, SFO or NYC, we don't have to hire people the VC firms
like/trust (we have senior executive experience at multi-nationals), and, most
importantly, we can focus strictly on what's best for our colleagues and our
patients.

------
fgonzag
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)

------
stmw
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)

------
oneepic
(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.

~~~
caycep
Counterpoints

> >\+ 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.

------
hackerDoc
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...

