Any self-respecting medical record (EMR) 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). OpenMRS RefApp needs Condition Lists. This functionality exists in Bahmni-style OpenMRS.
What is a Condition List? It is a chronic condition which is important for all clinical care of the patient and lasts 3 months or more. Chronic conditions include NCDs (Diabetes, hypertension, epilepsy, depression, asthma, COPD, arthritis, etc), cancers, infectious diseases (HIV, Hepatitis), and pregnancy. This wiki page provides additional information.
Initial development of this module was already completed (See here). This project must be completed before it can be used. There was a great start during the OMRS17 Hackathon in Malawi.
This would be implemented by Partners In Health (Haiti and other locations) when MVP (minimum viable product) is completed and tested. Other implementations are bound to use this when version 1 is completed.
- 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
- 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
- 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
- Fix error while saving condition- PR1 , PR2 , PR3 (Completed)
- Onset date entry should allow past dates only (Completed)
- Display end date for inactive conditions (Completed)
- Remove ‘History Of’ functionality and add labels (Completed)
- Add labels to Condition and Onset date field (Completed)
- Fix radio buttons on ‘Add New Condition’ page (Completed)
- Minor UI changes- PR1, PR2 (Completed)
- Conditions should be limited to diagnosis,findings,etc (Completed)
- Change hover message for ‘x’ icon in manage conditions (Completed)
- Edit Conditions feature- PR1 , PR2 (Completed)
- Add translations to french in Transifex (Completed)
- Cohort Builder for Condition List (in progress)
- End date validation (Completed)
- Confirmation before deleting a condition (Completed)
- Cosmetic tweaks for Manage Conditions UI (Completed)
- Add Condition UI enhancement (Completed)
- Upgrade Font Awesome to latest for reference application (Completed)
- Upgrade Font Awesome to latest for uicommons (Completed)
- Replace plus minus icons with labels (Completed)
- Fix error on clicking ‘x’ icon on patient page (Completed)
- Add onset date check for conditions to ConditionValidator (Completed)
- 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")
- 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.)
- 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)
- 0-to-n Conditions associated with an Encounter
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.
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.
There certainly can be ambiguity, but most things can be categorized into symptom, finding, or diagnosis:
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).