Active Forum Topics | Getting Started | Interviews | EMR Forum | Medical | Billings | Press & News | Voice Recognition | The Water Cooler
Introduction
Templates work well when we need to select from short lists of discrete quantitative and semi-quantitative data. They do not work nearly so well when we need to express detail, complexity, temporal or spatial relationships, or contingency in documenting an actual patient’s history and exam, or in recording our clinical assessment and plan. From the standpoint of usability, I believe that templates have two fundamental problems:
1) After we have formulated what we want to say, templates rarely allow us to use our own words. What should be a relatively effortless transcription task becomes instead the more difficult cognitive task of translation, inevitably leading to oversimplification, distortion, and omission.
2) Templates encourage or require us to conceptualize data as hierarchically-ordered, discrete ‘granular’ bits of information, while we humans instead use language to organize and structure data. Human language, with its innate underlying rules of generative grammar and syntax, effortlessly allows us to construct a single entity – a phrase, out of what would otherwise be multiple, hard-to-remember, discrete data elements. Furthermore, using our natural language faculties, we can combine these discrete data elements in an infinite number of ways, each conveying a different shade of meaning.
I would like to propose a design idiom, the EMR Phrase Processor, as an alternative to templates. The phrase processor is a language-based idiom that makes it easy to construct phrases expressing exactly what we want to say. As an example, consider a patient who presents with a chief complaint of knee pain. Compare the phrase-based history below with a template-based list of history elements:
Phrase version:
-- notes gradual onset of severe, throbbing, bilateral knee pain, left > right, almost every day for the past 3 months.
Template version:
Problem: knee pain
Onset: gradual
Duration: 3 month(s)
Frequency: almost daily
Location: bilateral knee
Right/Left: left greater than right
Severity: severe
Quality: throbbing
I believe that the phrase-based version has significant usability advantages over the template-based version. For instance, as a thought experiment, close your eyes and try to recall the information above in the two different forms. Also, in the template example I have assumed that these particular picklist choices (such as ‘almost daily’) happen to be available for the user.
Even if the EMR software reformats the template elements as simple declarative sentences, it doesn’t really solve the problem. All too often, this reformatting merely results in obtuse, information-sparse constructions such as the following:
Text version constructed from template elements:
Patient complains of knee pain. The onset is gradual. The duration is 3 month(s). The frequency is almost daily. Location is bilateral knee. The knee pain is on the left greater than right. The severity is severe. The quality is throbbing.
As always, I look forward very much to exploring this design concept with the emrupdate community. The example below is a basic EMR Phrase Processor design for the HPI. Here’s how it works:
EMR Phrase Processor
A Basic Design for History of the Present Illness
Phrase Box:
A phrase box (shaded blue box in the upper left corner of the screen) displays the text string as it is being built. I can directly enter free text into the phrase box. For instance, I can use a keyboard, or use handwriting or speech recognition software to directly enter the text string “— notes gradual onset of severe, throbbing, bilateral knee pain, left > right, for the past 3 months.”
knee pain: notes gradual onset of severe, throbbing, bilateral knee pain, left > right, for the past 3 months.
But, I can also build this same text string by sequentially selecting words from individual cells of the phrase processor. As I click on individual words in sequence, they are concatenated in the phrase box. In order to make the text more readable and to reduce my workload, the program has built-in punctuation rules, such as automatically separating sequential adjectives by a comma.
Text selected from cells can be combined with free text. For instance, I could be building a text string in the phrase box by sequentially clicking on cells. If I needed a word or series of words that didn’t exist in cells, or I couldn’t readily find the desired cells, I could just add those words to the text string by typing them directly into the phrase box. If I wanted, I could then go back again to building the text string by clicking on cells.
In addition, any text previously entered anywhere in the patient’s record can also be added to the text string by clicking on it. For instance, I could click on a pertinent item from the problem list, or click on a medication prescribed at the last office visit, in order to add these data to the text string as it is being built.
Frequently Used Words and Symbols:
Cells for frequently used word and symbols surround the phrase box. Cells for frequently used words, including function words such as common conjunctions and prepositions, are designated by a light yellow background. Cells for frequently used symbols (>> , > , = , etc.) are designated by a light green background.
Combo Boxes:
An array of combo boxes forms the backbone of the phrase processor. Each combo box is a single column wide, is generally 5-8 rows deep, and is framed by a black border:
rate
▼
slow
gradual
rapid
sudden
fulminant
Each combo box consists of:
1) a name (in blue italic font) designating a category (for instance, rate)
2) a picklist
3) a word box (cell with blue-shaded background)
-- for paging down through the picklist items
-- for alphabetical searching of the picklist
-- and for new word entry
I intentionally kept the number of rows in each combo box to a minimum so that I can find the word I’m looking for by quick scanning, rather than by having to read down a long list. In order to minimize navigation, I packed multiple combo boxes as tightly as possible into a single screen view.
The spatial location of the combo boxes on the screen helps me easily find the desired category. For instance, in the example above, I know that the rate combo box is located at the bottom left of the screen. I also arranged the combo boxes, as much as possible, so that phrases tend to flow from left to right and from top to bottom, in keeping with the conventions of written English.
Picklists:
Each combo box has an associated picklist which is available in a full form and a short form.
The full form of the picklist is an exhaustive list of words pertaining to the combo box category. For instance, the full form of adjectives describing the quality of pain could easily have several hundred entries. It is sorted alphabetically.
The short form is a selective subset of the full picklist. It contains only the most frequently used words (see above). So that I can find the word I’m looking for with a minimum of effort, the short form of the picklist is generally ordered systematically rather than alphabetically. For instance, in the example above, I ordered the words in the short form of the rate picklist by rapidity: (slow, gradual, rapid, sudden, fulminant).
Word Boxes:
Each combo box contains a blue-shaded word box:
The word box has three functions:
1) If the number of words in the short form of the picklist exceeds the number of cells in the combo box, I can click on the downward pointing arrow (▼) to rapidly page down through the short form choices.
2) I can also alphabetically search the full form of the picklist for any word I have in mind by entering its first one or two letters into the word box. Only the matching words will be displayed (see example below). I can then click on the word I want from this limited list.
s ▼
stuttering
swift
3) If, however, the word I want doesn’t already exist in the full form of the picklist, I can just continue typing the rest of its letters to spell a new word it in the word box. This new word (in this example, steady) will be added to the text string being built in the phrase box and, if desired, can also be automatically added to the full form of the picklist.
steady ▼
Convention for rapid construction of phrases:
In order to streamline phrase construction, I applied the following convention: If I click on any part of the black text in a cell, all the black text (but no purple text) gets added to the text string. But, if I click on any part of a block of purple text, all black text (if any) plus the selected purple text (but not other purple text) gets added to the text string.
For example:
history of
Clicking on ‘history’ adds just the word history to the text string.
Clicking on ‘of’ adds history of to the text string.
help(ing) (s) (ed)
Clicking on ‘help’ adds help to the text string.
Clicking on ‘(ing)’ adds helping to the text string.
Clicking on ‘(s)’ adds helps to the text string.
Clicking on ‘(ed)’ adds helped to the text string.
has had
Clicking on ‘has’ adds just the word has to the text string.
Clicking on ‘had’ adds just the word had to the text string.
I have to click on ‘has’ and then again on ‘had’ in order to add has had to the text string.
More Detailed Designs:
The example above is a basic Phrase Processor design for the HPI. In order to present the Phrase Processor concept as succinctly as possible, I have for now omitted several elements frequently found in the HPI. Even this basic design is more versatile than a template-based user interface. For instance, I can construct phrases such as:
-- episodes of pain start in early a.m. and last until mid-day.
-- noted sudden worsening of symptoms last night.
-- 2 weeks ago, had sharp right knee pain every morning for 4 days.
I will present more detailed HPI examples later. The phrase processor idiom works equally well for data entry into other parts of the patient’s record, including the past medical, social, and family history, ROS, allergies, current medications, physical exam, assessment, plan, prescriptions, and so forth. Surprisingly, the idiom also turns out to be quite efficient for entry of quantitative data.
Design options:
1) Learning Aids: As a novice user, I could start out for the first few weeks by just entering free text directly in the phrase box. As a learning aid, whenever a word of free text matched a word in a combo box picklist, that combo box and the cell containing the match would be highlighted.
2) Keeping track of discrete data elements: If desired, the phrase processor has the ability to automatically store data as discrete elements. Words selected from picklists or entered into a specific word box would already be associated with the appropriate category. In addition, however, by the same mechanism described above, whenever a word entered directly into the phrase box matched a word in a combo box picklist, that word would also automatically be assigned to the appropriate category. The program could also keep track of non-matching free text words and allow me the option of assigning them to the appropriate category, either during data entry or at a later time.
Thus, even if I entered the entire history directly into the phrase box as free text, each data element could be matched and assigned to the appropriate category, but the operation would be transparent to me.
3) Customization and Modular Design: The user should have the option of easily adding words to and deleting words from both the short and the full forms of the picklists, as well as being able to designate the order of words in the short form of the picklist. At the higher-order design level, the combo boxes themselves should be modular and easily customizable. In other words, the user should be able to design new modules for the EMR by specifying new categories of combo boxes, populating their picklists, and arranging their spatial layout on the screen.
Rick Weinhaus, M.D.
Watertown, MA
Rick - We have been using "phrase picking" for years with TurboDoc EMR. It works well. - equindlen
Office Practicum has phrase construction. I've played with it, and it's very flexible and configurable. (I am a pediatrician, planning on implementing that EMR in the near future).
Jim
Constructing sentences like this is a greater cognitive load on the physician than checking some boxes.
My preference would be that the processor construct decent sentences from the results of the checkboxes.
Graham http://www.synapse-ehr.com/ Synapse - the EMR for the superior physician
Another fantastic post - very exciting stuff.
I always find it quite fascinating when I start to recognize patterns between physician designs.
The best EMRs of the future will come from synergy of Physicians providing these kind of requirements and software developers able to deliver software that meets the vision (note I say the vision, too often developers duplicate the requirements in code without taking the opportunity to optimize the design through implementation).
As soon as I can I'll get you access to an environment where you can trial out these ideas - so keep them coming!
Greg
Greg--Principal at PatientOS Inc. (888)-NBR1-EMR
Graham: My preference would be that the processor construct decent sentences from the results of the checkboxes.
I agree with Graham. The cognitive load is divided between "telling the story" and "constructing sentences". You want as few synapses devoted to constructing sentences.
If you watch users for any length of time, what is apparent is that fast recognition followed by a click is important in documenting quickly. The term shown on the screen should be as simple as "vomiting"; the sentence automatically constructed should be complete, "John complains of vomiting." or "The patient denies vomiting." Or with multiple symptoms, the sentence construction should be automatic and more complex: "John complains of nausea, vomiting, and chills, but denies fever." (Pertinent negatives are also important.)
Especially for the specialist, the ability of the user to determine how the software constructs sentences is important. Consider that some physicians may not even want sentences, but rather, have the items bulleted in a certain part of the H-and-P, such as ROS. Others may want pertinent positives to be automatically bolded, or made an alternative color (such as listing allergies in a bright red font).
The method we use to address this issue is to assign formatting (ie, sentence structuring) to each of the many thousands of items in the "clinical store" of Medtuity. Any user can change the formatting rules for any clinical items. It allows for significant sentence variation. Most users employ the defaults. Specialists are most likely to change the sentence formatting, but it is their choice.
rweinhaus:Templates encourage or require us to conceptualize data as hierarchically-ordered, discrete ‘granular’ bits of information, while we humans instead use language to organize and structure data. Human language, with its innate underlying rules of generative grammar and syntax, effortlessly allows us to construct a single entity – a phrase, out of what would otherwise be multiple, hard-to-remember, discrete data elements. Furthermore, using our natural language faculties, we can combine these discrete data elements in an infinite number of ways, each conveying a different shade of meaning.
I agree with your premise entirely. I think it is also one reason we communicate with numbers and letters. Numbers are for quantifiable, granular data, while letters combine into words and phrases to achieve those shades of meaning. I am glad you recognize that fact. Stiil, I'm not sure I really understand your proposed solution to the problem. My goal is to focus on the content of my HPI, rather than the process of note construction. Is your system easier than the traditional templates?
Rick - We have been using "phrase picking" for years with TurboDoc EMR. It works well. – equindlen
Equindlen: Thanks. I have had a chance to go to your website and looked at the demo – the phrase picking looks great. Your paradigm is a little different, but it essentially the same idea. I look forward very much to having some time to trying it on the full program that you make available.
*************************
Jim: I went to Office Practicum and looked at the demo for a “sick visit” but I didn’t see anything that looked like a phrase processor. Could you or anyone at Office Practicum post some screen shots? BTW, I’ve been following you EMR deliberations with great interest.
**********************
caultonpos
Greg,
I would love to trial out some of these ideas. I agree with you that the implementation is as critical as the concept, and that best EMR solutions come from the snyergy between physicians and software developers. I am very glad you like the ideas.
Imemod
I agree with your premise entirely. I think it is also one reason we communicate with numbers and letters. Numbers are for quantifiable, granular data, while letters combine into words and phrases to achieve those shades of meaning. I am glad you recognize that fact. Still, I'm not sure I really understand your proposed solution to the problem. My goal is to focus on the content of my HPI, rather than the process of note construction. Is your system easier than the traditional templates?
Immemod:
I agree. My goal is also to focus on the content of the HPI, not the process of note construction, which should be as automatic as possible. Clearly, becoming familiar with an idiom like the phrase processor would require more of a learning curve than templates. On the other hand, EMRs are applications that clinicians use many hours per day, so it might be worth going through a learning curve if the end result makes for a easier data entry or a better HPI. I think that the phrase processor idiom may have some advantages over templates because of its flexibility (see below).
**********************************
ghchiu
Graham—
I think which is the greater cognitive load sometimes depends on the context.
Suppose you are seeing your knee pain patient for follow-up and that you had prescribed ibuprofen 600 TID at the last office visit and want to know if it’s helping. The patient might tell you that the ibuprofen was helping or not helping, but maybe he’s not sure, and says that it’s probably helping or probably not helping or definitely helping or definitely not helping, etc. Also, what if he took the ibuprofen for a week but that it definitely did not help so he stopped taking it. In this case, you would want to say definitely did not help, to indicate that he was not currently taking it.
With the phrase processor, you could constuct all those ideas with relatively little cognitive effort.
*****
With a picklist, you would have to go through all the permutations below:
not helping
definitely not helping
probably not helping
possibly not helping
possibly helping
probably helping
definitely helping
helping
did not help
definitely did not help
probably did not help
possibly did not help
possibly helped
probably helped
definitely helped
helped
does not help
definitely does not help
probably does not help
possibly does not help
possibly helps
probably helps
definitely helps
helps
Also, what is the best way to order the permutations – by probability, or by whether helps or not, or by time frame?
*********************
Matt Chase Medtuity:
The term shown on the screen should be as simple as "vomiting"; the sentence automatically constructed should be complete, "John complains of vomiting." or "The patient denies vomiting." Or with multiple symptoms, the sentence construction should be automatic and more complex: "John complains of nausea, vomiting, and chills, but denies fever." (Pertinent negatives are also important.)
Matt,
A phrase like "John complains of nausea, vomiting, and chills, but denies fever."
is exactly the kind of focused, information-dense construction that the HPI should be composed of, and I agree that it might take about 7 clicks with the phrase processor as opposed to about 4 with templates.
Suppose, however, that you ask your patient if he has had any fever, and he tells you that he’s not sure, that he felt a little warm one day last week. How do you handle this with templates? It seems like these kinds of issues come up all the time with the HPI. Neither denies fever nor complains of fever is really accurate. With the phrase processor, you could construct a phrase like: -- possible mild fever one day last week.
***********
Best, Rick
Bryan D. Uslick, MD CFCDD (Gastroenterologist) eMDs user since 3/3/2006. Currently using version 6.1 (Prior Praxis user.)
Provation MD endoscopy report writer
Rick,
That is common with fever ("I think so but didn't take temp") and so that is a choice that can be clicked on.
Medtuity has another neat feature to answer the problem of "modifying information". In the example of "John complains of nausea, vomiting, and chills, but denies fever", you can double click on the control to have it take that text and add it to an editbox so you can modify it. Now you have "John complains of nausea, vomiting and chills but denies fever." where you can type in, " though he admits to not taking his temperature."
My preference is to simply click, "took temperature at home" as negative.
Hi Doctor Rick,
I commend you for taking strides to address EMR usability issues. I completely agree with the effort. It seems many EMR company have not given any effort to the their UI. They simply just packed feature on top feature leading to feature creep. Their are a few exceptions out their.
However its about time people start really looking at the UI aspect of things and we want to help with that effort. We are actually at this stage architecting a ground breaking web services framework for the healtchare IT industry and we want at some stage to have a couple of different killer medical apps on top of our web services framework. We see usability as one the most important factors.
Anyways glad to see your post,
Thanks
Parag
Rick - What you are talking about is a lot like Allscripts MyWay. Here is a link http://bit.ly/3xGQBV
In designing any kind of EHR chart note-creation tool, there is always the balance between capturing discrete data elements, and capturing narrative text. The template structure of many leading EHRs is very click-oriented, and results is stiff output that loses narrative flexibility. Those EHRs tend to have their underlying database tables mapped to their template forms, so that the data captured is very granular – often to the point of overkill, actually. This makes interoperability between different systems using different templates difficult.
In designing the Practice Fusion EHR, we implemented a “phrase picking” approach that allows the physician to pick frequently-used phrases from templates found in a template library, and then edit them as desired on-the-fly. These templates are type-of-visit specific (e.g. diabetes, back pain, headache, etc), and are modifiable by the physician at-will. You can also pick sentences from prior chart notes (sentences are parsed into pick-lists automatically). As the phrases are “picked from the library,” they can be modified as desired in the chart-note text by simple typing over (although a good template will need little auxiliary typing). This approach seems to be the most usable way of quickly creating chart notes, which appear in a narrative form, but which contain standardized-enough data to allow for creating reports (e.g. disease registries, or reports based on HEDIS data points).
Welcome to emrupdate Dr. Rowley.
Here is my thinking:
Margalit
Margalit Gur-Arie
My brand new Blog: On Healthcare Technology
Thank you for the welcome, Margalit -
I think all of us (especially physicians such as myself who are both a practitioner using EHRs and also a participant in an EHR app development team) are trying to find the "right" balance between discreet-data and free-text on the one hand, and ease-of-use on the other. I look at all EHRs as experiments in trying to achieve the ideal balance. Our own focus is on a facile UI experience, so that the tool (the EHR) does not slow down the pace of clinical workflows, yet at the same time is able to quickly capture accurate and robust documentation. This is an ever-evolving process, and I welcome all lessons and collegeal inputs on this. An advantage of a web-based EHR, such as ours at Practice Fusion, is that we can add enhancements quickly, and immediately deploy them to the entire user community without having to worry about "version control" (as is the case with locally-installed applications).
In response to your comments:
I thoroughly agree that HPI is very difficult to document discreetly. Free text, hopefully somewhat standardized, is what is most often used, and a narrative is most useful to other practitioners when reading someone else's notes.
agreed
this is why the "sentence builder" model introduced in this thread might be more tedious than useful when applied in a busy workflow. I'd be interested in seeing what the experience with this type of UI turns out to be. There might be some lessons for us there.
The sentence-picker tool is essentially a shortcut to creating free text. Modifications in template-created text do pose difficutly in turning text into discrete data, but as noted above, HPI is probably one place where free text is fine.
the phrase-picker tool(s) in our EHR are intended as shortcuts to help physicians create frequently-used sentences without having to type, or dicate. They are not "forced" on the user, but instead are simply text-creation shortcuts to be used as desired. Alternative methods of text entry, such as simple typing or use of speech-recognition technologies are also ways that users can create chart note information in our app. You can mix-and-match from whatever combination of tools works for you. You may want to sign up at www.practicefusion.com and try the tools we have built in order to tell me your experience, and suggest improvements. My desire is to help build a UI that is useful, clean and fast, and at the same time thorough enough to result in good data capture (sort of a "holy grail" of software, I know) -- collegial commentary in this forum is welcome.
Narrative HPI sections do pose a challenge with automated E&M-suggestion software, but with intelligent sentence parsing, even this can be done with some degree of sophistication.
Again, agreed. HPI is best as narrative. Other elements (Dx and Rx, immunizations, allergies, uploaded scanned documents, for example) are better as discrete data, so that tagging (e.g. for HEDIS queries) can be done.