As with data tables that allow us to sort, or links that allow us to drill down, our clinical documents have interactive features. Or should have.
So let me propose a model for the Four-Layer EMR. It would use some kind of "hide/reveal" technology. Show me the level of detail I, the reader, need right now, in this context.
The top layer I call the "one-line summary". What few words characterize this encounter. I am thinking of ambulatory physician visits. Perhaps other readers can translate this into other kinds of clinical encounters.The one-line summary would be a terse description like: "diabetes, A1C 8.2, start metformin 500 BID" or "acute sinusitis > amoxicillin 875 BID 7 days" or "well woman exam > Gardisil, Yasmin".
The benefit? I can look at a list of all the visits chronologically and see what happened.
Like this:
Brenda Star..........Acct No: 309144869
- 02/11/07......acute sinusitis > amoxicillin 875 BID 7 days
- 04/29/07.....well woman exam > Gardisil, Yasmin
- 09/02/07.....diabetes, A1C 8.2, start metformin 500 BID
The next layer down, the "Executive Summary", is what I would communicate to a surgery consultant. It is a 3-4 sentence description of this encounter in a depth adequate for a consultant or other peer not needing a complete picture of this patient.For example, it might say "57 year old type 2 diabetic recently started on metformin with good control, needing evaluation of chronic cough, not on an ACE inhibitor".
Next, the 3rd layer, the "Working Layer" is the layer clinicians would like to work in for the details they need. That is, before we started documenting to cover our assess.It would include only the pertinent history elements necessary to understand the diagnosis and treatment. In the Review of Systems, it would only include the positive elements, with a few negatives (e.g. "no murmur" if that is pertinent to note).
In the Assessment and Plan, only the parts that are not assumed. I do need to know which antibiotic was used. I don't need to read that the patient was told to take tylenol and come back if they don't get better as expected.
The fourth layer would make my attorney, my risk-manager, and my chart reviewers happy. All the wealth of detail is there that would only annoy the rest of us. All the detail that makes my record look more like a contract, and less like a story about a person.Parenthetically, there are layers deeper than these four. These layers include the security/audit trails that record who recorded what and when. We'll ignore them for our purposes here.
So, how do we bring this concept about?
- Identify the elements that define each layer.
- Choose a technology that supports it in your particular product.
- Work out the details that specify the contents of each layer within a specific document. Could the software identify key words for Layer 1 (One-line summary) in context? Would the provider need to supply these in the beginning or end of document production?
4 comments:
Just thought I would address this idea more carefully, as someone who develops a FOSS EHR and could implement these ideas...
The problem here is that there is no clear way to get the one line summary from the underlying data in a programmatic way. You have to have the knowledge of a doctor to know what portions of the record are relevant. i.e. should every script show up? Which risk factors really are relevant?
One thing I could do is have the last note show up on the patient search. Essentially allowing the notes to serve as the place were a doc could create such a summary. Of course notes like "wrong phone number in record" would also often show up....
Good point that Fred makes about the one-line summary. In fact, this would be the job of the doctor or whoever creates that record entry.
Like adding an appropriate, terse subject to your email.
That's what I've been doing.
I love this idea and am thinking about how to make it work without adding further burden to the physician:
While I am fundamentally opposed to re-work and to redundancy of information in general, I suspect the extra time required to create the terse subject line would save more than enough time at future visits to offset the effort.
Better yet, I would like to have a combination scribe/health coach in the room with me, to assist with the charting in real time while I interact with the patient. (She would then stay in the room to operationalize the decisions.) This skilled assistant would soon become very good at extracting the essential sound bites for the visit into the first layer as well as completing layers 2 and 3.
Depending on your EHR, you could do this by creating a template that extracts the CC or Primary diagnosis. You could also have some hierarchy as to what else could be displayed given the space limitations. The problem is that if you are in multi-provider environment, that summary can be untrustworthy as different clinician documentation tendencies will alter the ordering of data. Ideally, wouldn't the problem list be the place for this?
Post a Comment