Making EMRs Fast, Easy and Intuitive to Use: Removing the Burden of Structured Data

9/27/2016 11:42 AM

I was cruising around last week and came across "The Burden of Structured Data: What can Healthcare Learn From The Web Experience" from Andy Oram who's writing I have quoted here before.  In the second part of the article (the second part is the reason I didn't respond to it last week) he states "ICD should be replaced with something that embodies semantic meaning" and then goes on to say "A big problem in electronic health records is their insistence that certain things be filled out for every patient." resulting in a "Cartesian explosion" and "bloated records."


As we have found before, Andy makes some good observations, but like the healthcare industry in general, he has no clue how to solve the problem or that the problem has already been solved.  It seems to me that Google, Bing, and all the other major search engines pretty much licked this problem a long time ago.  They give you a two stage search where what you type in generates suggestions AS YOU TYPE with popular searches.  That isn't quite the entire solution for healthcare, but that is a great place to start.


The entire solution is to use a purpose built database like SNOMED CT that is designed from the outset for documenting patient encounters and combining it with Bing style searches.  That is precisely what we have done here at Sentia Systems, for our sister company Sentia Health. Our solution takes it a bit farther even.  We took all the concepts in the SNOMED and made a word table with the number of unique occurrences of every word in every concept.  When the user picks a word out of the autocomplete list, we insert that word and a space making compound word searches possible.  For example, "abd" would give you "abdominal" and "pa" would give you "pain" and f course we are bright enough to return the matching word with the highest number of occurrences first.  Then we do the bing/google thing and search the appropriate concept type for places where "abdominal" is near or next to "pain."  This isn't just a wildcard search either.  For you techies out there, it is a full text index, meaning that we search for words that SOUND LIKE "abdominal" and "pain" in case the user didn't pick from the list, and in reverse order and NEAR each other, not just next to, or in the same description.

Here are a few pictures to illustrate what we mean:

First we navigate to the appropriate record, open the search window and type "lo":

Then we pick (or continue typing) lower and continue with "ab":

Then we continue typing (or pick) "pa":

Finally, we click the Populate button to actually do the search:

There are quite a few things to notice here:

1. The autocomplete doesn't give you popular searches, like Google does.  It simply corrects your spelling.  This allows you to only get 25 results with two letters instead of scrolling through thousands of results that would take a long time up load in any case.
2. You can type your entire entry with out picking anything.  If you don't want to use the mouse or the scroll buttons, don't.
3. The thing you actually wanted to see is at the top, number one position.  Other things that might be similar are ranked below.
4. If you choose to type, without picking anything in the autocomplete, the spell checking still kicks in.  If you search 'hedayk' you still get a list of things with headache in the title, just like Bing.

So yes, Andy (or is it Mr. Oram?), we have conquered the structured data challenge.  We document our cases in regular SOAP Notes that are in English (SNOMED also supports many other languages and will translate them automatically) with modifiers (like "left" or "severe") indented and prefaced with a dash.

This is what software is supposed to do: solve problems.  We believe that we can enter in a note as fast as we could have typed it in and with far fewer typographical errors.  Even better, we now can search for patients with a diagnosis, or with certain symptoms because those things are captured in a structured way. 

So tell your Cerners and your Epics and every other vendor of electronic health records out there that they are just doing it wrong.  When you factor in the fact that an Epic or a Cerner installation will cost hundreds of millions of dollars to implement, the response time is abysmal, the patient encounter still has to be coded to be paid by the insurance company, and our sister company Sentia Health will do all this, and do it better than the competition can even imagine, and do it for $10/month I think the choice is clear.

So no, Andy, there is no burden, you just need a few good programmers to show you how to do it.