Design Forum 2014-04-14

Owned by Burke Mamlin
Last updated: Apr 14, 2014

Problem Lists
Agenda
  • Burke, Jonathan, and others to give introduction/overview of common approaches to Problem Lists (15 minutes)
  • How problem lists are used (longitudinal data about active healthcare issues)
  • Difference between problem list and diagnosis lists
  • Modifiers – issues around "Presumed" vs. "Rule Out" vs. "Ruled Out"
  • Q&A about context (15 minutes)
  • Gather requirements from BAs/Devs representing implementations (30 minutes)
========== Background ================
Patient presents to doctor with symptoms and findings:
  • Cough
  • Fever
  • Aches
  • Elevated blood pressure
Doctor records diagnoses for the encounter:
  1. Presumed Pneumonia
  1. Hypertension
Diagnoses lists often combine symptoms, findings, and diagnoses:
  1. Cough
  1. Presumed Pneumonia
  1. Elevated Blood Pressure
Problem lists are used to track the issues being followed/treated for a patient:
  • Hypertension
  • Heart failure
  • Chronic cough
  • Leg numbness
  • Preventive Care
Items on a problem list reflect the current focus of care, which sometimes may include short-term or historic items:
  • Hypertension
  • Pregnancy
  • History of Stroke
In short:
  • A diagnosis list contains the reasons that you saw the doctor today.
  • A problem list contains those items that your doctor is following across visits.
Sometimes providers want to refer to modify diagnoses (to distinguish between a presumed diagnoses vs. a confirmed diagnosis) and want to refer to diagnoses that the patient is not even presumed to have or is know not to have:
  • Rule out Myocardial Infarction
  • Presumed Pneumonia
  • Confirmed HIV
  • Ruled out Tuberculosis
While shades of certainty for likely diagnoses ("Presumed" vs. "Confirmed") can safely be used in a problem list, modifiers like "Rule out" or "Ruled out" significantly change the meaning of the problem list from "things that the patient is being treated for" to "things that the patient may or may not be treated for", which has serious consequences for use of the data for decision support, billing, research, etc.
Jonathan comments:  
    Problem lists are longitudinal (generally long-term; they reflect your model of the patient) vs. diagnosis lists which usually refer to the diagnosis for a given visit  
    Problem lists reflect Problems, symptoms, diagnoses, other things such as history 
    How they are used:
  • 1. As a scan of who the patient is, his/her main medical issues (e.g. for a new provider seeing the patient for the first time)
  • 2. As source outline material for the Past Medical History
  • 3. Sometimes tied to orders for justification (e.g. ordering a lab test is only justified for billing purposes if the patient has a relevant problem)(linked to billing codes, like ICD)
  • 4. Preselection list for visit diagnoses.
    Entered:
        1. when the clinician feels like, at any visit or any time
        2. Sometimes rechecked at start of an admission  
        3. Sometimes elevated from visit diagnoses.
    Modifiers -- used for problems that you are considering:
        1. Rule-out: I need to rule out that this does or does not exist -- common 
        2. Presumed: a little more confident than rule-out
        3. Ruled out: (I wouldn't expect to see this in a live problem list)
Andy comments from below:
    Problems evolve:
  • First encounter: Chronic Cough (confirmed)
  • Second encounter: Pneumonia (probable)
  • Third encounter: Probable pneumonia (ruled-out), Congestive heart failure (confirmed)
Problems can be combined (fever + rash) in one visit becomes Parvovirus infection in latest encounter. How to track these prior problems when viewing history of Parvovirus?
There can be duplicates, Hypertension and elevated blood pressure might need to be collapsed to just Hypertension.
There can be non-diagnoses on the problem list. For example: DO NOT ATTEMPT CPR. Or Homeless. 
There can be items on the Problem list that don't come from diagnoses: for example, the splenectomy example below (test history) or allergy (PENICILLIN as an allergy on the allergy list, might ALSO appear as Allergy to Pencillins on the Problem List).
  • (Burke) I would not suggest supporting allergies on the problem list.  If people are not aware of the allergy, then we need to adjust how we communicate allergies so that it's not necessary to duplicate in the problem list.  (Jonathan) agree; don't want to duplicate allergies here.  For clarity and also for ease of use Andy: There are different codes for allergies (in ICD world) which are attached to the PL/Diagnoses and not from the drug name included as the allergen).
Andy: Current medical record systems are generally a disaster as far as Problem Lists go, and we should really do better. They don't allow management of problems, clean-up, etc. and so they grow and become unusable and contradictory.
Jonathan: Agree.  I am calling for making sure this stays usable; making sure that we don't expect the clinicians to be computer scientists -- but at the same time, making a problem list that is usable for various functions.
Burke: Modeling != User Interface
   -- (true.  Just wanted to make sure it didn't dictate the UI.)
========== PRE-CALL NOTES ==========
(Document your implementation's Problem List-related requirements here. Be concise, and say who you are.)
Data model for Problem Lists introduced in OpenMRS 1.7:
    person
    concept
    startDate, endDate
    startObs, stopObs // obs that triggered this entry to be created/stopped
    comments ← need to be careful to avoid confusion between this "customization of the name/description" vs. a problem note.
    modifier ("Rule Out", "History of") ← we'd prefer "Presumed" to "Rule Out", since only likely problems should be on this list
    sortWeight
AMPATH (Burke)
Problem List Requirements
  • Maintain a list of diagnoses representing "active problems" for a patient. (i.e. "where the focus of care is")
  • An easy way for items to be added or removed from that list.
  • Burke: "the only way we could [get our list under control] was to let you remove a problem with a single click"
  • The ability to use the problem list when creating a list of encounter diagnoses
  • Additional metadata for each problem:
  • Onset date
  • Billing code – e.g., map to ICD code(s).
  • Detail (short free text modifier – e.g., "left > right" or "chronic") (AK> Think laterality are also included in the concept and the same applies to acute v chronic, and this is not a good example as you can have conflicting information between concept and free text detail) (Burke> that assumes that you've convinced your providers to dig through a million ICD codes... more than happy to have these codified when codifying them is the easiest path) Andy: Interface terminology captures the right level of specificity. The fact is that the underlying codes are different based on what modifiers are added, and this can be a problem downstream. I recommend that the detail be more of a narrative summary of the problem (over time) rather than modifiers.
  • Certainty ("presumed", "confirmed", "history of")
  • If this is included, it is critical that modifiers do not negate or allow problems that are unlikely to be included on the problem list.
  • Burke: it's okay to merge "rule out" with presumed+confirmed in the UI, but we shouldn't store them in the same DB table
  • (Jonathan) Thinking ahead to the design, if we do separate these in the database but make them look together in the user's view, that may address this problem
  • Jonathan: if we don't give people a way to do "rule out" many of them will find a way to sneak it in
Bahmni
"Cured", i.e. had TB 4 years ago, treated and cured, patient comes back, doctor wants to know about that history.
  • This sounds like a "History Of" entry in the problem list -- (JT) yes. 
"Ruled Out", i.e. to communicate between different doctors who may see the patient, that some investigation has already been done and shouldn't be duplicated
  • How long does this last?  It surely means nothing 2 years later. (Mujir): a couple of months MAX, maybe just a couple weeks.
  • => as discussed on the list, this should be stored as its own observation of "ruled out" = "(some diagnosis)"
A typical note (plan) built on a problem list (problems in bold)...
  1. Hypertension. Will continue metoprolol.... sorry it is a note, not meant to be modifiers)
  1. Cough.  Persistent despite stopping ACE-inhibitor. Will check chest x-ray.
  1. History of Stroke. Continue daily aspirin.
  1. Smoker. Given cessation materials at last visit.
  1. Prevention. Colonoscopy due in 2018.
Under the hood:
  • Problem list (presumed, confirmed, history of)
  • "Workup" list (rule out)
  • Recently ruled out (collection of observations of ruled out diagnoses + date ruled out)
User experience:
  • Problem list (presumed, confirmed, history of, rule out, recently ruled out)
CIEL (Andy)
I think we need to model all the states of problems, including those that are episodic and terminate naturally (pregnancy), those that are chronic and perhaps become inactive, but not cured, and those that are acute and terminated via treatment. I think those are separate from the diagnostic/treatment problem management workflow that also needs to be discussed. We don't have to include all of these functions initially, but it would be good to design for it.
I think problem management is a key feature that CIEL is interested in supporting. At the Problem List active list functional level, it would seem possible to modify the diagnosis certainty based on the current encounter confirmation. In some situations, the modification of the diagnosis will not involve only changing the certainty, but might actually involve having the concept be ruled-out and a new diagnosis (confirmed or probable) put in it's place. For example:
First encounter: Cough (confirmed)
Second encounter: Pneumonia (probable)
Third encounter: Probable pneumonia (ruled-out), Congestive heart failure (confirmed)
Etc.
Lastly, there is the lifecycle of the problem within the EHR that should also be at least modeled. An example is a procedure which is ORDERED (SNOMED code?), then PERFORMED (CPT), then REPORTED/BILLED (CPT), then appears on the patient's SURGICAL HISTORY list (SNOMED again?) and then may be elevated as a PROBLEM (ICD/SNOMED).  
Ordering a laparotomy for trauma, ends up with a splenectomy being performed and reported, which then shows up as s/p splenectomy or just splenectomy in the surgical history or procedure history, and then goes up on the problem list as H/O splenectomy...
The current Visit Diagnosis set includes:
    
  • Visit Diagnoses (159947)
  • DIAGNOSIS LIST (1284)
  • Diagnosis or problem, non-coded (161602)
  • Diagnosis certainty (159394)
  • Diagnosis order (159946)
  • Diagnosis date (159948)
When a visit diagnosis gets moved to the problem list, what should be included? What about retaining links to prior versions of the problem (see above for example of Cough -> CHF)?
Here is the CIEL concept for Diagnosis Certainty:
    
  • Name Diagnosis certainty
  • Short Name 
  • Description The level of the certainty of the diagnosis made.
  • Class Finding
  • Datatype Coded
  • Answers:
  • Confirmed diagnosis (159392)
  • Presumed diagnosis (159393)
  • Provisional diagnosis (160249)
  • Final diagnosis (160250)
  • Patient-reported (161908)
  • Mappings SNOMED CT: 106230009 
  • org.openmrs.module.emrapi: Diagnosis certainty 
  • CIEL: 159394 
==================
(Jonathan) Desiderata from a number of sites:  
    1. Easy problem encoding -- matching to text entered by the provider  (I type "miliary Tb" -- dictionary offers up "miliary tuberculosis" as the approved and coded equivalent)  
  •     a. Strive for coded problems whenever possible -- but I estimate there will still be 10-15% of entries that don't fit a coded scheme, because the problem list is used for a number of other summary items
    2. Right granularity: a problem list should not have the detail of ICD, i.e., "hypertension" may be one problem, or at least a very small number, not the dozens of hypertension-related ICD codes
    3. Temporality is difficult.  Trying to attach a field to a problem to make it "short-term" (like a strep throat), or "ruled out" (but it may come up again sometime) vs. "lifetime" (hypertension) has been attempted once or twice but never successfully used, in my experience.  On the other hand, "hisotry of" is very useful for things that did happen but are completed -- "history of stroke", "history of total knee replacement".
    
Mujir:
how is a 'history of' problem list added?  explicit adding 'history of'. Would a 'cured' disease automatically get added to 'history of' problem list? only chronic diseases?
Andy Kanter: PL (Problem List) is not the same as PMH (Past Medical History)
Jonathan: only things of longitudinal interest should be added as "History Of" items in the problem list, and this should not happen automatically.
Burke: Generally, we want to make it easy, but have items explicitly (not automatically) added to the problem list.  If someone enters a diagnosis for hypertension in an encounter, then it's likely we would want to add it to the problem list as well (but that decision may vary by implementation).
Jonathan: It's tricky determining which visit diagnoses belong on the problem list -- doing it automatically leads to a great deal of clutter.