EMR Physician Builder Day 1 - discreet elements
/
Kryptonite - from Justice League room at Epicenter (photo by Rob Schertzer)
I have died and gone to geek heaven. That was my first thought when I entered the "Epicenter" and read my room assignment off of the wall of monitors in the grand foyer. My room, the Superheroes Justice League, with the X-Men on one side and the Jedi on the other. This super hero was in heaven, though kind of warn out by day's end some nine hours later. It must have been the Kryptonite threatening from above - no joke.
What was more exciting? Unravelling the mysteries of the underpinnings of the EMR? The hallway talk of the never to be resolved battle between discreet data elements and a time efficient and patient-doctor friendly narrative? The daydreaming of the first thing to tackle when I get back? Or could it have been all of the above?
I can't give away specific details about the database underpinnings but the complexity of what you would think would be more simple helps to explain why this EMR can be such a beast to customize. It also means though that so much can be customized if you learn enough about it. Today we covered seven of the flat file structured static/build databases and four of the also flat structured dynamic/patient databases. Some values are networked together (linked to each other); other values are written in one location but get populated in other databases. Once you learn where to find the data, you can figure out how to create custom form, flowsheets and phrases that can have embedded lists and text. All of these can help improve patient flow if done right. You would think that as long as you stick to values in the database for the patient data that this would yield searchable data for reporting and would therefore avoid the pitfalls of free text...but it turns out that you still don't necessarily have searchable data to carry out your analytics because, ready for this? - the data has to actually be clearly defined discreet elements from yet another database!
Hence the engaging discreet element discussion during one of the breaks. Nothing could get a group of computer savvy physicians to bond more than this topic. It's a dilemma that may never be resolved to anyone's satisfaction and is why any EMR continues to be a source of much frustration and a matter of compromise. In three sentences one doctor can summarize their clinical impression and express why they might refer the patient to another doctor. All of this goes along with how we use pattern recognition to put the whole picture together and even words are an approximation and a man-made construct of what's going on. However, just asking someone how their vacation was can be summarized in a few sentences but if you try to document it in a series of discreet data elements, you will be clicking boxes and selecting from drop down lists for 10-15 minutes by which point you will have lost track of the whole gestalt. This is the reality of using an electronic medical record today; we spend so much time staring at a computer trying to capture discreet elements and can miss the narrative that is the person with a problem to solve.
An editorial written by Richard L. Byyny, MD, FACP called The Tragedy of the Electronic Health Record in the Summer 2015 issue of The Pharos really summarizes the feeling many of us currently have with EMR systems.
We need to break down these artificial barriers that are interfering with patient care. The hope is that if more physicians learn to be physician builders like we are doing, then we will have a better chance of adding back some of the human element to the EMR, capturing what we need in terms of discreet elements with a better interface so that we can somehow translate our pattern recognition to a machine in order to improve patient care. We need to improve patient flow to have the EMR help us capture the full story. The quest continues!