I only have anecdotal evidence, but every physician I talk to, hates the EMR software he has to deal with.

Ye old Enterprise IT

One particularly tech savvy young resident in an area hospital, says, “… too many clicks, too many clicks“. These are folks that live in their iPhones and iPads every spare moment they have.

As he did book-keeping on his laptop, I peaked over his shoulder at the EMR program he was using.  Also, a couple of months ago, I had occasion to spend a few days at Johns Hopkins, helping take care of a family member, and I took every chance to watch the staff at work at their monitors, which now seem to be stashed into every available corner (each patient’s room had a desktop, monitor, keyboard, and mouse).  I was a little taken aback to see that they were all using Windows desktop applications.  Seen through eyes drunk on modern touch-screen mobile devices, these apps look old-fashioned – poor, tired, windows, boxes, lists and buttons, huddled together in an unappealing jumble.

My doctor friend said his EMR was cumbersome to use, and it took too long to enter all the data that he is prompted for.  He seemed to unconsciously separate information that is vital to patient care, from information that is just “for billing“. Often, he enters only the patient care information that he thinks is necessary, and ignores what he called, “fluff“.

The word “fluff” struck a chord.  Design for mobile first.  That forces you to identify the “fluff“, and drop it.

Essentially, what I saw was classic Enterprise IT interfaces.  They serve some bare business purpose, with little thought to ease of use.  Users, doctors, and nurses, in the midst of their high-stress workdays, just deal with it, because, well, they have to.

There were more tell-tale signs of Enterprise IT.

"Yea, they improve things, but everybody hates the changes. You 
manage to learn one thing, and then they make you learn something 
new all over again."

"They never ask the doctors.  They try to keep us away from what 
they are doing.   They build something and show it to us, and it 
is not great, but then it is too late to change anything."

Impenetrable domain knowledge

The doctor is looking at lab results.  He sees that haemoglobin is low.   In that situation he is taught to then look at past iron levels, and vitamin levels, which are results of other tests.   In the interface he showed me, the iron levels, and vitamin levels were hard to find.  The lab results were a long Excel like table, and he had to scroll far and wide to find them.  They were not close to the haemoglobin levels.  The interface was not smart enough to offer the iron levels and vitamin levels when it detects that the haemoglobin is low. The doctor said he sometimes surrenders to fatigue and irritation and simply orders the tests for iron levels and vitamin levels again.   Of course that is duplicated effort for someone, not to mention a wasted expense.

The business analyst who modeled the diagnostic processes obviously did not know how medical personnel are expected to react to low haemoglobin.    The UI designer did not know that a relationship exists between low haemoglobin, and iron, and vitamin levels.   The interface they built does not reflect that knowledge.  The EMR software did not make the physician’s job easier.  In fact, it made the whole process more inefficient, and wasteful.

There must be so many other little use-cases like this.  I imagine the patient care domain is vast, varied, and complex.   A doctor spends years acquiring all that training, and knowledge.   How can you expect a business analyst, or UI designer to absorb all that information?   Even in the best of circumstances, there are so many ways for domain knowledge to get lost in the translation, from business user through business analyst, to system designer, and finally to the developer.  I imagine that this exercise is even more error-prone in a complex and information-heavy field like patient care.

Are we barking up entirely the wrong tree?  Is it a fool’s errand to try to model the patient care domain in order to produce a structured interface that makes the doctor’s job easier?

 

A simple-minded EMR

I wonder if something like this would be a viable EMR system?

A universal key

You must be able to uniquely identify a patient, a human being.   In other words, you need a universal key for their records, which you can apply at any health-care organization they are visiting.  Say, fingerprints.  Would that work?

A simple collection of documents

Medical records themselves are just a collection of documents.  They can be anything at all – plain text, HTML, WORD, EXCEL, PDF, audio, photos, video, etc.  Each provider simply creates whatever records makes them happy, in any format at all.

Each document is characterized by very simple, non-medical meta-data.

• Who created them?
• When were they created?
• etc.

The documents are all stored together against that universal key.   You have the patient’s fingerprint, you have her records.

Searchable

You need the ability to search through a patient’s medical records – the collection of heterogenous documents. You must be able to return results ranked by relevance.

Transferable

You must have the ability to simply transfer the records of a particular person between providers.  And even to the patient herself.   This is a simple transfer, because there is little structure to speak of.   It could be as simple as an email with attachments.

Start Minimal

That’s it.   There is your minimal, but possibly complete, EMR.  In capability, it probably matches what folks are able to do with paper records, with added sugar due to the fact that the records are native citizens of the digital world.

The system is simple enough that it can be quickly adopted by organizations.  This is what every institution must be able to do, off the blocks.  No complex analysis effort.   No errors that are introduced simply by the act of creating the new system.

And build on it

Once the system is on-line, slowly build on it.

• Improve identity tracking, if necessary.

• Improve entry, generation, and visualization of data.   As we saw above, this means applying knowledge that only physicians have.   Business analysis must come directly from the physicians.   Work on one specialty at a time.  Work on one disease at a time.  Or something like that.

• Improve search.  Which is really ‘data analysis‘ aka ‘analytics‘ aka ‘big data‘.

• Improve data storage, and data transfer.

And so on.

 

Many Whys

So why are EMR systems not as simple as the one described above?

Are there considerations that I still have not learned about?

Why is there so much structure, which is hard to get right, and much of it un-intuitive to physicians?   Are these related to ‘accountability‘, and ‘billing‘?

I mentioned HL7 standards, and SNOMED taxonomies to a couple of young doctors – a resident, and a fellow.  They had never heard of them.  This is medical knowledge that software engineers are basing EMR software on, and doctors have little knowledge of them?  I was about to sign up for an expensive week-long seminar on HL7.   Is that a waste?   What is going on?

I went to a meet-up of the local Health 2.0 chapter.  Folks spoke with enthusiasm about many things, but EMR systems did not come up at all.

There seem to be a lot of startups doing healthcare related work in Pittsburgh.   However, everybody I met is working on devices, and solutions for use by individuals to get control of their personal health .  No one said anything about making a doctor’s day to day work easier, and more effective.

There is something interesting going on here.   Are enterprise concerns, like EMR, simply  un-cool?  Or are they considered a done deal?   Is it too late, and well-nigh impossible, to enter the field now, and improve on matters?