The Problem List is the Problem
By Sam Bierstock, MD
![image image](http://histalk2.com/wp-content/uploads/2017/09/image-212.png)
Sam Bierstock, MD is president and founder of Champions in Healthcare, LLC. He developed and trademarked the concept of Thoughtflow.
For years we have heard that the goal is for complete interoperability of electronic health record systems (EHRs). While this must certainly be achieved in the ultimate attainment of confluent data availability, it is important to be sure that exchanged data from differing systems is consistent. In this regard, we have a huge problem – problem lists.
As an interesting exercise, ask any physician the difference between a diagnosis and a problem. It will readily be seen that very few know the difference, and those that offer an explanation of the difference will provide a wide variety of definitions. As a result, problem lists are loaded with a combination of current and inactive complaints, symptoms, and diagnoses, and generally are a mess. They are inconsistent, unmaintained, confusing. and vary between systems for the same patient. A patient who has been admitted to different hospitals using different EHRs will have a different problem list at each hospital, not to mention any problem lists that may exist in EHRs of physicians that they have seen as outpatients.
While I am unaware of any actual studies to assess the cost of inconsistent problem lists to the healthcare system, these costs must be enormous. Medical record departments and coders spend hours sorting out diagnoses since problem lists frequently populate discharge summaries from which billing data is extracted. Active and inactive problems must be identified and separated out. For instance, “Status Post Myocardial Infarction 1999” may be on the list but is not billable. Symptoms frequently appear and may confuse or diminish reimbursement or be entirely non-reimbursable. Productive cough for three days for instance is a symptom, not a diagnosis, and yet is typical of the types of problems currently listed.
In 1970, I was a medical student at the University of Vermont when a dynamic, energetic, brilliant, and visionary physician who had recently joined the university staff brought his radical ideas about computerizing patient histories and findings to the attention of the industry. His name was Larry Weed, MD, and his system, “The Problem-Oriented Medical Record”, was rapidly changing clinical documentation across the country. A level of logic and thinking that had been missing in the assessment, planning, and treatment of patients’ conditions was being recognized for its enormous value. Problems included medical diagnoses as well as social issues and all matters that need to be considered to treat patients in their entirety.
But Dr. Weed’s system got sidetracked in the ensuing years by the introduction of independent electronic record systems designed by corporate vendors. In general, these system designers had a very poor understanding of the Problem-Oriented Medical Record, and as a result, all tended to handle diagnoses and problem lists differently (if they had them at all). As a result, decades later, few physicians can differentiate between “problems” and “diagnoses” and problem lists have degenerated into a morass of confusion.
For more than a decade, I had been advocating an approach to EHR design that differed from the standard approach of existing systems which were based upon reproduction of text-book clinician “workflows.” Although they frequently followed the textbook workflows, these designs were inefficient and had nothing to do with the way physicians think and work and have historically been abysmally received. Most physicians use EHRs today primarily because of legislative mandates and Meaningful Use requirements, but there is almost universal agreement that they are cumbersome and reduce efficiencies.
Since 2003, I have advocated a different approach which I call (and have trademarked) Thoughtflow and which I first described in the literature in 2004 – supporting the way physicians access, assess, prioritize, and act upon data. In other words, how they think and act.
One of the areas that can be addressed using this approach is the Problem List. As a first step, I had to decide what made it to the list in the first place, what constitutes a “problem.” I picked up the phone and I called Larry Weed. Now well into his 90s, Dr. Weed was as brilliant as ever, and I quickly learned the answer to my question about the difference between a problem and a diagnosis.
A problem, Dr. Weed explained, is the highest level of the current diagnosis. Understanding this basic principal provides a path to cleaning up problem lists, keeping them consistent and updated and maintaining active and inactive problems. EHR system designers do not understand this any better than most physicians do, and as a result, each has a different approach to the construction of problem lists in their systems.
![image image](http://histalk2.com/wp-content/uploads/2017/09/image-213.png)
Consider the following scenario:
A patient is seen in the emergency room with a five-day history of abdominal pain and constipation of unknown origin, and subsequently admitted for evaluation. The diagnosis is constipation and abdominal pain, which may appear as a combined problem or two separate problems on the admitting history and physical.
Problem #1: Abdominal pain x 5 days
Problem #2: Constipation
The admitting doctor orders a GI consultation and some baseline studies including a flat plate x-ray of the abdomen. On the first day of admission, the x-ray shows an abdominal mass. The Problem List may now look like this:
Problem #1: Abdominal pain x 5 days
Problem #2: Constipation
Problem #3: Abdominal mass
On day 2, the patient has an exploratory laparotomy and is found to have carcinoma of the colon.
Problem #1: Abdominal pain x 5 days
Problem #2: Constipation
Problem #3: Abdominal mass
Problem #4: Carcinoma of the colon
At this point, and at the sole discretion of the attending physician, Problems 1, 2 and 3 may be removed entirely from the Problem List, may be moved to inactive problems, or may stay on the list. They may stay there for some time or be moved by a future physician providing care for a different problem. There are no fixed rules.
However, if Dr. Weed’s dictum is applied, consistency is attained.
On day 1, when the x-ray shows an abdominal mass, “Abdominal mass” becomes the highest level of the current diagnosis, and therefore replaces both “Constipation” and “Abdominal pain X 5 days,” becoming Problem # 1. In my system design, clicking on the updated Problem #1 “Abdominal mass” resulted in a drop-down menu showing, in chronological order, the previous problems leading to the most current and the dates. So clicking on “Problem # 1 Abdominal mass” produced a drop-down that looked like this:
![image image](http://histalk2.com/wp-content/uploads/2017/09/image-214.png)
On day 2, after a diagnosis of Carcinoma of the colon, Problem #1 is further updated:
![image image](http://histalk2.com/wp-content/uploads/2017/09/image-215.png)
Clicking on each drop-down menu reveals configurable granular data dependent on user preferences.
Consistent with the concept of Thoughtflow as opposed to workflow, the design minimized any requirement for the user to update the problem list. Using vocabulary standards, clinical decision support software, language processing, and automated ICD-10 coding, the Problem Lists can be automatically updated. They can also automatically exported to an evolving discharge summary from which the automated coding provided billing and reimbursement data. The potential savings in time spend scouring charts by coders can be appreciated, as well as the accuracy of coding and assurance of reimbursement.
In addition, updated and current Problem Lists can also populate any medical summary screens which may have displayed overall summary data such as medications, allergies, past surgeries, etc. This assures an accurate, consistent summary of past maximally updated problems, or in other words, the highest level of current diagnoses. Symptom and other extraneous data will then not appear to congest the list and add to assessment and billing confusion.
Rapid maintenance of the list can be attained by simply dragging a problem that was inactive or resolved to the corresponding list. A problem “Myocardial Infarction 1990” could be moved at a physician or coder’s discretion to an Inactive or Resolved Problem list, while “Atherosclerotic Coronary Vascular Disease” remains as an active problem. Problems could be prioritized in order by simply dragging them to the desired position, and numbers changed automatically as the new position was attained or as
problems were added or removed.
The inconsistency of Problem Lists is an inadequately discussed, but universally recognized issue with enormous costs to the healthcare system, both financial and with respect to quality of care. The issue also generates an enormous challenge to EHR design and to the assurance of interoperable, consistent patient information across the spectrum of healthcare systems, physician offices, disparate hospitals, and payers.
I appreciate the information you have shared via this blog. Your insights on school health IT are fascinating, and I…