Condition List - Clinical Status

Development
19

Thanks @burke . Is the following on the right track?

  • Add a new category property to Condition (an enum), with initial values of CONDITION_LIST, PAST_MEDICAL_HISTORY

  • The existing clinicalStatus property is independent of this. Something can have a clinicalStatus of ACTIVE with a category of PAST_MEDICAL_HISTORY, or a clinicalStatus of INACTIVE with a category of CONDITION_LIST

  • Change the Condition List tab and the Past Medical History tab to display the clinicalStatus along with the condition

  • When converting between OpenMRS ↔ FHIR, an OpenMRS CONDITION_LIST category maps to a FHIR problem-list-item category. An OpenMRS PAST_MEDICAL_HISTORY status map to a new OpenMRS FHIR extension. Practically this means that data incoming from FHIR that is not aware of the OpenMRS FHIR extension will be on the condition list by default.

  • In the UI shown above, the simplest changes in the short term would be:

    • Change the name of the tabs from “ACTIVE” and “INACTIVE” to “CONDITION LIST” and “PAST MEDICAL HISTORY”
    • Change the “Set Inactive” button to “Move to Past Medical History”
    • Change the “Set Active” button to “Move to Condition List”, or potentially a better option would be to have buttons for “Add recurrence to Condition List” and “Add relapse to Condition List”, which would keep the condition on the PMH and add a new Condition instance to the Condition List
    • Move the “X” (delete) button into the edit page, or add a modal confirmation popup, to discourage use to quickly remove conditions from the list

  • Support viewing / setting the full set of possible clinicalStatus values (recurrance, relapse, remission, resolved) in order to ensure accurate representation of any incoming data from FHIR. Could make it configurable as to which statuses the “Add Condition” screen should include.

  • Deprecate / change API method ConditionService#getActiveConditions

    • Ensure methods to “getActiveConditions” consider active, recurrence, and relapse statuses
    • Ensure methods to “getConditionList” and “getPastMedicalHistory” are supported by services (eg. query on category, not on clinicalStatus)

  • I’d also be interested in reviewing when Conditions should be voided and recreated on edit. Currently this is happening for any type of change (adding an onset date to an existing condition, for example). It would be good to review if all such changes should result in an audit history or only certain changes.

1 Like