Condition List

Abstract

Dev Resources

• GitHub : https://github.com/openmrs/openmrs-module-coreapps

• JIRA : https://issues.openmrs.org/browse/RA-209

Requirements

• Good Java, Spring and JavaScript skills

• Soft skills to interact with the community in order to gather requirements and technical feedback

• Testing – including writing unit tests

• Write clear technical and implementation documentation

Skills Needed

• Java

• Spring

• JavaScript

• HTML/CSS

• MySQL

Objectives

• Complete all the minimal work so Condition List can be used in production RA-209

• Complete these tickets: 

  • RA-1458 Only allow current and past dates for conditions

  • RA-1459 Onset and Inactive date should be displayed for inactive conditions

  • RA-1461 Remove "History_of" functionality

  • RA-1486 Configure list of valid condition lists for implementations 

  • EA-40 Condition List V1

    • EA-51 Extend EncounterTransaction to include conditions during save

  • RA-208 Allow some users to add Conditions directly from the Consult Note (extra checkbox in addition to primary/secondary and confirmed).  Design/add to the consult note, so that conditions can be displayed or added directly on the same pages as diagnoses. (see attachment for Bahmni diagnoses/condition list page)

• Write a RefApp ConditionList report in MySQL or CohortBuilder

Extra Credit

• Translate into other languages (ie. French) and make certain that all text labels are in message properties (Transifex).  If you are not a native French speaker, find someone who can translate.

• RA-1387 Upgrade FontAwesome from 3.x to latest (5+).   Find a great icon for the dashboard / condition list.    The current icon isn't ideal.

Progress TODO List

Primary Objectives

1. Fix error while saving condition- PR1 , PR2 , PR3 (Completed)

2. Onset date entry should allow past dates only (Completed)

3. Display end date for inactive conditions (Completed)

4. Remove ‘History Of’ functionality and add labels (Completed)

5. Add labels to Condition and Onset date field (Completed)

6. Fix radio buttons on ‘Add New Condition’ page (Completed)

7. Minor UI changes- PR1, PR2 (Completed)

8. Conditions should be limited to diagnosis,findings,etc (Completed)

9. Change hover message for ‘x’ icon in manage conditions (Completed)

10. Edit Conditions feature- PR1 , PR2 (Completed)

11. Add translations to french in Transifex (Completed)

12. Cohort Builder for Condition List (in progress)

Additional Objectives

1. End date validation (Completed)

2. Confirmation before deleting a condition (Completed)

3. Cosmetic tweaks for Manage Conditions UI (Completed)

4. Add Condition UI enhancement (Completed)

5. Upgrade Font Awesome to latest for reference application (Completed)

6. Upgrade Font Awesome to latest for uicommons (Completed)

7. Replace plus minus icons with labels (Completed)

8. Fix error on clicking ‘x’ icon on patient page (Completed)

9. Add onset date check for conditions to ConditionValidator (Completed)

Screenshots

Resources

• Project GitHub Link

• Project JIRA Link

• Final Report : GSoC 2019 - Condition List

• OpenMRS SDK

• Bahmni Condition List discussion

• Condition List User Documentation

• Tracking Progress of the Condition List Phase GSOC Project

• GSOC 2019: Condition List (MVP)

• Design forum notes

  • Notes from 2014-09-29 Design Forum

  • Notes from 2014-09-24 Design Forum

  • Notes from 2015-06-01 Design Forum

  • Notes from 2015-06-15 Design Forum

• Cohort Builder

• Condition List Mid Term Presentation

Definitions

• 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

Condition

• 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

Reports

Data In; Data Out. It's helpful to a clinician to view/modify the patient's condition list at point of care on the dashboard. It's equally helpful for data analysts/scientists/M&E (monitoring and evaluation) to see a list of patients within a period of time with chronic conditions along with the condition.

What is provided in the RefApp for reports. For example, Does the cohort builder (1 or 2) show anything from the condition list? (don't think so). What do other groups use to export data? Should it be an exported csv file? Should it be a webpage?  Nothing appears here: https://demo.openmrs.org/openmrs/reportingui/reportsapp/home.page.

For Partners In Health implementations, there are a ton of reports. Many are written in MySQL and export data in csv format.