Home » Readers Write » Currently Reading:

Readers Write: The Problem List is the Problem

September 27, 2017 Readers Write 6 Comments

The Problem List is the Problem
By Sam Bierstock, MD

image

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

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

On day 2, after a diagnosis of Carcinoma of the colon, Problem #1 is further updated:

image
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.

View/Print Text Only View/Print Text Only


HIStalk Featured Sponsors

     

Currently there are "6 comments" on this Article:

  1. Not sure if I understood this correctly, but could this hide potentially critical problems that are unrelated to each other? What if there are different issues, resulting in different problems, and now you’re hiding crucial information under a drop down?

  2. Amen, Dr. Bierstock. I love this! The modern electronic record allows multiple providers to document against the same patient, and the coming world of interoperability will only increase the fundamental issue: Instead of being helpful for a problem-oriented record, the problem list has become an attic for every diagnosis or problem placed on a chart. Governance of who should put what where is impossible. The catch-22 is that the more cluttered a list becomes, the worse its clutter increases. What happens is that a long list of unorganized terms makes it impossible to figure out what is already on the list, so more terms just keep being added. And a disorganized list is too tedious to properly maintain—or even use. Problem lists are full of redundant and outdated terms, or else missing a key term entirely. If an outside list needs to be incorporated, the process of reconciling it line by line against an already-cluttered list is impossibly time-consuming. As a physician working for the company that provides terminology to 70% of the US market, I am keenly aware that non-useful problem lists are an issue across every EHR vendor. Since our obsession is to make terminology work for clinicians, we have expended a large amount of development effort to help solve this. Our approach is to take the million-plus terms we expose to a typical EHR for diagnoses and problems, and give every term a unique clinical “home” cluster, so that terms which a clinician needs to handle as a unit now group together. This is a surprisingly complicated thing to do, since every term needs to have one—and only one—clinical grouping. ICD codes do not create clinically-oriented categories very well. SNOMEDCT codes create multiple parent codes and leave hundreds of thousands of orphaned terms. So we tackled the sorting problem ourselves, and we can now create a problem list where “Abnormal thallium test” juxtaposes with “Elevated troponin” and “Postop myocardial infarction.” We can roll up these clinical clusters under specialty-based display categories that let clinicians rapidly see what is going on, and decide what should or should not be on the problem list. Because terms from the same clinical family group together, we enable clinicians to clean up, reconcile, and maintain a Problem List so that they can (finally!) have the Problem Oriented Medical Record in honor of Dr. Weed’s recent passing.

  3. AC
    No – every unrelated problem has its own progression in the drop down reflecting the history of how the top level evolved. In the example I gave constipation led to abdominal mass on X-ray which led to carcinoma of the colon. This took constipation and abdominal mass off the problem list but they are in the drop down to show how the highest related diagnosis was reached – and unclutters the problem list.
    A second problem could be chronic lymphocytic leukemia with a drop down containing the previous related problems leading to that diagnosis – fever and generalized fatigue of uncertain etiology (date), anemia (date), etc.
    So unrelated problems have their own progression to the highest level of the current diagnosis that they relate to
    I hope that helps
    Sam

  4. A million cheers for Larry Weed, may his soul rest in peace.

    However, AC brings up an important issue. Unfortunately, there are many other related issues. Notwithstanding his excellent Problem List change suggestions, Dr. Bierstock’s title said it all. The Problem List (analog or digital) IS and always has been THE PROBLEM.

    In the digital world (because it could have NEVER worked in the analog world), until our EHR platforms have a more Google search combined with a more FB-like look and feel, we will continue to offer suggestions and attempt solutions for the Problem List. In other words, the Problem List will continue to be THE PROBLEM.

  5. I also have to agree with most of what Dr. Bierstock has to say. I have also given this a great deal of thought over the past twenty-two years and published a bit about this with my colleagues (https://www.ncbi.nlm.nih.gov/pubmed/9929235). We even built an EHR (I-EMR) that implemented patented longitudinal problem list management that automated the summarization of each problem linking the superseded problems (the Orientation in the OHEAP model). We learned that it matters where in the care process the problem management occurs. Early on, problems change due to the diagnostic process. Once clinicians make a diagnosis, problems change as they are either mitigated/cured, or as complications set in. Ensuring that problems retain all the clinical intent during import and export is another critical failing of many systems. Using recently approved HL7 standards it is possible to include clinical interface terminology codes as translation codes in C-CDA and FHIR transmissions. That way, problems will be interoperable and all the clinical meaning can be transmitted regardless of which primary SNOMED or ICD code is mapped. Recognizing that problem list, assessment list and history lists are all separate and have different functions and required code mappings means that it is insufficient to simply pick a term from SNOMED or ICD and stick it in one bucket and then re-use it in another. Problems have different semantic content than billing diagnoses and knowing how to transform the concepts as they move from problem list to assessment, or from assessment to problem list (or past medical history) requires know-how and a good interface terminology. Once you have accurate and precise terminology in each of these buckets, clinicians can start to rely on the information in them. One point that will not be fixed by better definitions is more and more aggregation of content from different providers and different systems. With the greater interoperability described by Dr. Bierstock, more and more redundant and potential contradictory data will be placed in the record. We really do need a trusted source-of-truth of a patient’s problems if we are going to ensure that the health care system is truly working to fix them (or mitigate them).







Subscribe to Updates

Search


Loading

Text Ads


Report News and Rumors

No title

Anonymous online form
E-mail
Rumor line: 801.HIT.NEWS

Tweets

Archives

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Reader Comments

  • I'm in the Twilight Zone: Re: The White House’s Office of American Innovation will host a half-day meeting Tuesday on EHR interoperability, led ...
  • Betsy: It doesn't surprise me at all that patients wouldn't think of quality as part of value - I think that a lot of younger, ...
  • Seargant Forbin: Not all EPIC sites are live on carequality. From my understanding all NEW customers will automatically be part of the pr...
  • Vaporware?: ARWD, I don't think it's true that every Epic customer is live on Carequality. That said, I haven't seen Epic try to adv...
  • Lindy: With Kevin replacing Ed Marx as an employed (rather than contracted) CIO at NYCHHC; I guess the rule that Epic sites ca...

Sponsor Quick Links