Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
Child pages
  • Condition List (Design Page)
Skip to end of metadata
Go to start of metadata


Any self-respecting medical record system needs to be able to track patient conditions (what is often called the patient's "Problem List").  We have chosen "Condition" instead of "Problem" to align with contemporary thinking (e.g., since "Pregnancy" isn't really a "Problem" for most people).


  • Chief Complaint – the reason the patient is seeking care, typically given as a symptom and duration (e.g., "Fever ⨉ 5 days"), but is sometimes given as an existing diagnosis for scheduled or routine visits (e.g., a patient coming to clinic for a scheduled iron injection to treat anemia might have the diagnosis "Iron-Deficiency Anemia" recorded as a chief complaint).
  • Condition – a symptom (something the patient has noticed), a finding (something that has been observed about the patient), or a diagnosis (clinical syndrome diagnosed through observation or testing)
  • Condition List – a longitudinal list of conditions that are relevant to the patient's health status, typically populated with chronic or recurring medical conditions (e.g., "Hypertension" or "Diabetes Mellitus") or prior conditions that continue to affect health care decisions for the patient (e.g., "History of Stroke" or "History of Breast Cancer")
  • Diagnosis – a condition pertaining to a particular encounter (e.g., one of the reasons that patient is being seen today)
  • Diagnosis List – a list of diagnoses pertaining to a particular encounter (i.e., the reasons that the patient was seen today or the list of diagnoses addressed during the clinical transaction)
  • Finding – something objective found physical exam or through testing (e.g., "Murmur" or "Expiratory Wheezes")
  • Symptom – something subjective the patient has noted and is not typically observed by physical exam (e.g., "Headache", "Fatigue", or "Wrist Pain")
  • Symptom/Finding –  some things can be noted by the patient as well as observed on physical exam (e.g., "Fever", "Rash", or "Weakness")

Design Ideas


  • Patient
  • Status/Modifier - History Of, Presumed (or Provisional), Confirmed
    • FHIR condition status is provisional, working, confirmed, refuted. But we don't want to include refuted conditions here
      • We propose that the best-practice approach of recording "today, I ruled out TB" is to record this as an observation during an encounter/visit, rather than a "refuted condition"
  • Concept (symptom or diagnosis, e.g. "Chest Pain" or "Pneumonia")
    • Should we allow free text answers? Yes. (But this is not best practice, and it's really best to avoid this if an implementation can. And we'd want a toggle that lets an implementation say it does not allow free-text answers.)
  • OnsetDate
  • Codes (0-to-n reference terms) <- Don't these come from the concept? Or is this something different?
    • Typically used for billing (e.g., ICD codes)
  • AdditionalDetail (String)
  • DateCreated
  • CreatedBy
  • Voided
  • VoidedBy
  • VoidReason

Condition List

  • 0-to-n Conditions assigned to a patient

  • You should have to explicitly ask for historical (voided) items

Diagnosis List

  • 0-to-n Conditions associated with an Encounter

Condition List 1

See Also



  • No labels


  1. Frankly, I find the distinction between symptom/finding and diagnosis as being ambiguous. It is possible that a finding is a diagnosis and a symptom, such as shortness of breath, certainly can also be a condition or a diagnosis. The most important thing from a design point of view is that conditions are different from diagnoses (even for the same thing). The reference codes associated with diagnoses are also different from conditions and moving a condition from the condition list to the diagnosis list requires some translation and vice versa. Also, there can be multiple "codes" associated with both conditions (for reporting) and diagnoses (for reporting and reimbursement). Not sure why there is both sequence and ordinality for diagnoses, but perhaps I have to review the FHIR page for those.

    1. There certainly can be ambiguity, but most things can be categorized into symptom, finding, or diagnosis:

      • Symptom is something the patient perceives and cannot be observed (e.g., pain, shortness of breath, palpitations, etc.).
      • Finding is something that can be observed (e.g., tenderness, dyspnea, irregular heart rhythm, etc.). Patients can report findings because, in many cases, they can observe them as well as the clinician.
      • Diagnosis represents identification of the nature of the illness or problem (e.g., fracture, pneumonia, atrial fibrillation, etc.).

      The distinction between symptom & finding becomes muddier when the definitions "reported by patient" and "observed by doctor" are used, respectively, since patients can report things that they observe. As for your example: shortness breath is a symptom, dyspnea is a finding, and a diagnosis would be the cause of the symptom & finding (pneumonia, pneumothorax, heart failure, asthma, etc.).

      We would promote terminology similar to SNOMED-CORE for the condition list concepts. Code(s) could be associated with any condition for billing purposes (e.g., ICD codes).

      We definitely want to sort diagnoses (i.e., using sequence_number or, if we followed the convention used elsewhere it would be sort_weight to accomplish the same thing). But I couldn't talk folks out of keeping ordinality, since supposedly some implementations want to support more than one primary diagnosis (e.g., list five items and have two of them as primary diagnoses).