

How to build a good EMR - helwr
http://www.quora.com/Jae-Won-Joh/How-to-build-a-good-EMR-part-1

======
phren0logy
I am an MD, and I'll offer my 2¢ on the EMRs I have used:

1\. They seem to be sold to hospital administrators, who hold the wallet but
don't have to use them.

2\. This flows from point 1. Given the target buyer, they seem to be made for
the purpose of billing, and not for the purpose of facilitating patient care.

3\. Doctors are all over the map with regard to tech savvy. Some are truly
awful. Most of the EMR solutions I have seen are focused on slavishly re-
creating a paper chart. Which is dumb.

There is a lot of room for innovation here.

~~~
Radix
As an MD I'd like to hear your opinion on some of the EMRs you've used.
Particularly Greenway, which I've heard from a consultant, not a physician, is
good, or at least a good company. Or Epic, which I've heard is both okay and
awful, and lastly Amazing Charts.

~~~
niels_olson
Epic has potential, I used it on the trauma service at Norfolk General, and my
wife uses it at Rady Children's in San Diego, but their custom markup language
to create note templates, and how all that gets rendered, sucks. What should
be a smart 1 page ICU note becomes a 4 page cluster.

It's about the notes. Screw the trendlines and all that tarted up crap. We
want the same thought process no matter what tool we use to write and record
it. And that thought process puts maximum information in the eyespan, and
should flow well. Yeah, we might be doing it at 5 am, and you can ridicule our
handwriting, or the mis-spelling after we get sick of fighting a spell-checker
that doesn't recognize "leptospirosis" but the cognitive dissonance of
wrestling with the machine at 5 am with a sick patient and some other cranky
doctors just sucks.

------
8273me
The EMR/EHR market is actually a collection of different markets.

The institutional one is a lost cause -- you are not going to get Kaiser to
back out of its $5B investment in Epic. These are enterprise systems with
ancient cores who are largely sold on the golf course, under cover of RFPs and
checklists so buyers can compare "apples to apples". No usability or modern
technology considerations apply. You will take your Citrix and love it. Like
most enterprise apps they have to do it all (billing, HR, compliance,
security, and on yeah, some sort of medical charting) simply to be
competitive, and as developers we know how that works out.

The small-practice market is where a lot of innovation is happening --
PracticeFusion, DrChrono, athenaHealth, eClinicalWorks, etc. It's competitive
but the dollar amounts tend to be fairly low and the small-practice market is
drying up as doctors ally themselves with hospital groups in advance of the
freight train that is health reform.

The really bloody (and interesting) battle is in specialty EHRs, as others
have mentioned. Generic records just don't fit for optometrists and dentists
and therapists and the like. There's huge opportunity here for competition and
the markets can be small and cozy enough that UX, SaaS, good service, etc
becomes a big differentiator.

Jae doesn't get into constraints against ground-up reinvention too much, which
are almost comically enormous. For example HIPAA (and "Son of HIPAA" from
ARRA) is married to a wide variety of state-specific privacy regulations that
go above and beyond the Federal regulations. The biggest constraint of them
all is something called "Meaningful Use" (ONC-ATCB EHR Certification), which
determines if your software makes you (the doctor) eligible for federal
incentive dollars. It's the primary driver of EHR sales at the moment and
creates a bunch of onerous and potentially user-unfriendly requirements on the
part of the vendors who have to spend hundreds of thousands of dollars to
comply, taking R&D budget away from actual innovation. Just to give one
example, Jae says "Your EMR does not need to have every single drug and its
dosages installed in its database, with an automatic checker to make sure
there are no negative drug reactions" -- as a matter of fact ONC EHR
Certification (which, again, is driving the industry) calls for exactly that.

While I certainly agree with almost every one of Jae's suggestions, it's
difficult to see them getting adopted under todays' market incentives.
Clinicians don't buy EHRs. Administrators aren't interested the things he
lists. And even when clinicians do purchase the systems, the game is heavily
rigged towards large, legacy vendors pushing shitty, ugly software with their
huge sales forces who can spend money complying with complicated regulations.

In closing, it's all sort of a clusterfuck.

~~~
nradov
Here is some detailed information about ONC certification requirements.
[http://www.cchit.org/get_certified/ONC-ATCB-
Certified-2011-2...](http://www.cchit.org/get_certified/ONC-ATCB-
Certified-2011-2012) Any EHR which isn't certified isn't likely to get many
sales.

As for drug dosages and reaction / interaction checking, all of the EHR
vendors license their drug databases from just a couple of data vendors.
<http://www.medi-span.com/master-drug-database.aspx>
<http://www.firstdatabank.com/Products.aspx> So if you're going to include any
of that drug data it's just as easy to include the entire set.

------
famousactress
As someone who's spent over a decade building systems for clinicians, I'm
thrilled that there finally seems to be an awakening brewing, and that
clinical users are beginning to demand more from their tools (and realize that
more is possible!).

Also, semi-shameless plug but we're working really, really hard to build a
much better EMR and much of what Jae says in this post is exactly why we
started working on it. If you're interested in joining us, we'd love to hear
from you! <http://elationemr.com/>

------
Nate75Sanders
EMR = Electronic Medical Record

I thought this article was going to be about MapReduce.

~~~
squidsoup
In New Zealand we call these PMSs, or Patient Management Systems. This is not
confused with Pre-Menstrual Syndrome here as we use the acronym PMT, or Pre-
Menstrual Tension instead. When speaking to colleagues in the US however, I
always have to remember to use EMR/EHR!

------
baran
"The EMR is dead." - Lyle Berkowitz, MD
[http://www.youtube.com/watch?v=oSVIAG11OXM&feature=playe...](http://www.youtube.com/watch?v=oSVIAG11OXM&feature=player_embedded)

EMRs were originally built for data legibility, ordering, patient continuity
of data (OK, we still dont have this), and better financial tracking. The
large EMR vendors have largely already created this functionality, but to an
interesting conclusion - the realized value was not nearly as great as the
perceived value. As a result, the opportunity for startups is NOT to built a
better mousetrap! For the foreseable future docs are going to be stuck with
Epic, like it or not. The perceived value of a "better" EMR is not strong
enough for institutions to adopt your software. You can only sell on that
failed promise once.

The opportunity IMHO lies in small applications that solve the problems of
docs (or nurses). Pick a niche market (primary care, ortho, peds, nursing,
etc.), talk to them, find their pain points, and build software that makes it
easier.

------
waterside81
For those in Ontario (Canada), our province actually outlines exactly what an
EMR should do, the format the input and outputs should be, and defines how
data must be imported & exported. It's actually not bad as far as specs go.
There are about 16 or so certified EMRs in Ontario that have to meet the
requirements to be sold to hospitals and docs.

[https://www.ontariomd.ca/portal/server.pt?space=CommunityPag...](https://www.ontariomd.ca/portal/server.pt?space=CommunityPage&cached=true&parentname=CommunityPage&parentid=4&in_hi_userid=2&control=SetCommunity&CommunityID=553&PageID=1763#specification)

For aspiring devs out there who want to build an EMR and aren't sure where to
start, implement this spec. I'm sure it'll overlap with many requirements that
US health agencies might need. Except for complex billing with an array of
insurance companies, but that's for another thread :)

------
incomethax
Jae is thinking in exactly the right direction. The challenge I feel is not
building a better EMR - but rather its convincing hospitals that their EMRs
really really suck and the $MMs they spent on "Traditional EMR" was all a
waste.

I think in this industry its all about understanding the environment of
current medical practice and re-engineering it piece by piece.

------
wallflower
I was just talking to an ex-HIPAA software manager the other day.

The complexities are ridiculous. For example, who can edit a patient record,
when can they update it, why should they be able to edit it. Who can add
information about drugs a patient is taking, which departments are allowed to
update certain sections of a patient record...

~~~
frisco
Congratulations! You've found a problem that can't be solved in a weekend
spent hacking! Despite the intricacies, it is still almost entirely a CRUD
app, though: which means you have the skill set to implement it. No PhD in
machine learning necessary!

Just because it can't be solved by one person in 72 hours doesn't mean it's
impossible, as your comment seems to be implying (or at least, Very
Difficult). That should say "defensible" to you, not "too hard, won't
bother.". As far as technology goes, EMR is easy. It's the product design and
enterprise sales that will kill you.

------
aksbhat
EMR's are just one part of healthcare, What we need is for all EMR's to follow
standards which would make extracting/reusing information from them
straightforward.

on a related note: <http://challenge.gov/HHS/134-smart-apps-for-health>

------
utoku
I discovered last year that this is still a field where good honest money can
be made since everyone is bitching about the fact that there is not a good
solution.

I just wanted to keep my MRI and digital X-ray scans. I wanted to send them to
the doctors to get their opinions on them and pay them for the time.

I still haven't done much on this myself, but lately I did use
<http://www.webpax.com> to send some scans to several doctors. Their ideas
saved me from a "recommended" operation by a previous doctor. Uploading DICOM
could be easier, but still at least there is someplace on the web that enables
it for me.

------
dr_
A hospital when implementing an EMR is looking for some cost benefit in doing
so. One obvious one is reducing medical errors. The other is reducing staff
size. If the physician has to do all the work in entering the medication
(drug, dosage, start/stop time, a reason, etc.), someone in the pharmacy
department of the hospital is probably not doing it - reduced staff size =
more profit for the hospital.

------
phlux
I am a healthcare systems designer -- I design various technology aspects used
in a hospital from the physical cable plant, the way technologies interact and
information is displayed and consult on how data is accessed and consumed. I
designed technology systems for both El Camino Hospital [1] and San Francisco
General Hospital.

I was also co-founder of Contineo [2], with which we applied to YC in 2009 and
were rejected.

Contineo was an attempt to answer many of these issues - and we had a hell of
a time trying to get traction.

This post is good - but there are a lot of other factors that are at play in
an organization which result in their deployment of whichever EMR they are on.

My answer was - and still is - an HL-7 Compliant, back-end agnostic client
which can be deployed on iOS and Android devices.

We built this client and a demo for El Camino on top of both MedSphere's Open
Vista EMR (We needed a schema to demo against) and we did a demo on El Camino
Hospital's (ECH) implementation of Microsoft Amalga.

We built this as an iPod Touch application for a range of reasons but the two
main ones at the time were the iPad didnt exist yet - though we were expecting
it and the iPod touch is wifi and cheap. A $200 device for the use made good
sense.

After having no traction or interest from YC or angels who all told us we
needed paid pilots, and having a fallout with my co-founder it died...

But the idea is still valid, as are the main challenges.

Ill discuss each point in here - and again while this is a good post - it is
actually made by someone who really isn't too familiar with how healthcare
organizations are run, especially from an IT perspective and even more so from
an EMR perspective.

There is an eternal battle between medical staff trying to always bring in
some technology that will help them in their care and the IT organizations who
are expected to manage and maintain all systems that peoples lives depend on.

This is further complicated by the fact that hospitals, and their staff ARE
NOT IT ORGANIZATIONS and they most often outsource their IT operations to
companies like Eclipsys, Perot systems (dell), and others.

This is the biggest issue. Because of this fact - orgs that outsource to
Eclipsys get the Eclipsys EMR, Perot uses Epic, Others use Siemens etc...

And guess what -- these IT organizations are under strict contracts and WORK
FOR A PROFIT so they have ZERO incentive to make changes, be fluid, "design
for the web" or any other nice things we all take for obvious and granted.

The EMRs that are in place represent MILLIONS of dollars of inertial
entrenchment behind such systems.

In this article he makes the following claims:

Build for the web

Build for ipad

Simple design

Design for small screen

Dream big

Leave it open ended

\---

Build for the web: THESE SYSTEMS ARE NOT ON THE WEB. They are either run in
house - or via the IT providers datacenter through PPP tunnel. Every hospital
has a number of BSA IT Folks on staff FULL TIME to manage the EMR for JUST
THAT SITE. So to simply say that an EMR should be "on the web" is not thinking
about the long term support of that EMR - and the organizations individual
workflows that are built around two things: their staff and the physical
layout of their facility.

Workflows account for the actual environment within the hospital and how that
effects their ability to perform their duties.

\---

Build for the ipad:

The ipad is a beautiful luxurious device. Docctors make lots of money. Doctors
are smart. Doctors like to buy luxurious things with their money. The ipad
fits into this really really well. What it does not fit nicely into is a
close-minded IT organizations view of a critical device that i easily
maintained, managed and supported.

The ipad's environment is OWNED by APPLE. Apple takes a cut of the profit
(30%) of your app. The case is not rugged, it is not hermetically sealed. And
the device does not have a good multi-device charging station. The device
cannot take external peripherals.

I love the iPad -- and I do think it is the future of medicine - but until
Apple stops douching about with their iron grip on the thing, and make some
concessions for enterprise, it is still hard for the iPad to be the device we
all want it to.

The IT organizations in a hospital don't feel they can manage the iPad - and
having years of experience in IT, the mantra will always be the same when an
IT org is operating in fear mode "We don't have the resources" -- they will
always say this. They don't like change.

And to the parent company, the IT org in each hospital is minimal staff to
perform the requirements of the contract -- they are not there for anything
else.

(Personally, I am working on a project (alternate YC application project to
what I applied for) which is a medical information content management
platform, but based on Android. The issue is that hospitals spend millions on
hardware: computers, carts, tablets, televisions etc.. there is yet a single
platform that can work for both patients (patient entertainment and education
in-room) and staff (role based access to medical systems. I think that this is
achievable through android.)

\---

Make it simple:

I agree with this, however just because it takes 6 hours to learn an
application does not make one suck at making software... Autodesk makes
AMAZING software that takes a lot more than 6 hours.

The issue here is that every organization has individualized workflows. You
need to spend a lot of time boiling them down to their essence. Certain
aspects should be able to be made simple and consistent - like medication
administration.

Design for the small screen: This was actually the biggest push back! There
are almost 3 million registered nurses in the US. At El Camino alone they had
more than 900 ON SHIFT at any given moment - with an employee population
nearing 6000.

The AVERAGE age of their nursing staff was 47 years old. They did NOT want a
small screen.

Even with all the reasons why the iPod touch was a great device, even the
typical 15" screens in the facility were too small for them.

This is correct - you must design for a small screen - but what this means is
that you need to really understand the workflow so you can only put the UI
elements on screen that must be there for each step - big buttons.

Dream Big: Every big EMR player out there is going to try and stop you. We
were asked by Thrasys (who makes sorian med suite for Siemens) if we would OEM
our product to them, they had us come in and meet with them, review our
capabilities etc... under the guise of them wanting to OEM - but really they
were phishing for ideas to steal.

Epic didn't want to work with us because they dont want any agnostic clients
touching their system.

Eclipsys is barely technically capable. They don't even fully implement HL-7
making it difficult to get the interactions you need.

\---

Leave it open ended:

You will need to be able to make custom workflows for any client. Every client
will be different.

The EMR really needs to be addressed - but with the current state of EMRs, the
closed minded stance that their creators have and the incentive to defend like
mad their territory -- there are other ways to make in-roads into the
healthcare space that might work a bit easier. This is why I am going after
the patient entertainment space -- the patient room is where you can really
make headway in this battle - because the EMR folks wont see you coming. But
it is at the bedside, the experience that the patient has and the affect you
can have on staff, that one can start to take on the big players.

All the other EMR apps built on iPad are really targeted to the small practice
physicians. Dr Chrono is doing well at this angle.

\--

[1] <http://www.popsci.com/bown/2009/product/el-camino-hospital> [2]
[http://medsphere.org/community/project/ovid/blog/2009/11/25/...](http://medsphere.org/community/project/ovid/blog/2009/11/25/announcing-
openvista-rest)

