A client wants to add status to a patient. The status has to be either of the follows:
“Active” - for patients who are being treated at the facility
a. “Dead” - for patients who are dead
b.“Transferred Out” - for patients who are transferred out from the heath facility for any reason
The approach which we have thought of is:
To first rename the “Death Information” section to “Patient Status”
Then make a field named “Closed Assistance” which will be a drop down box with 2 answers: “Dead” and “Transferred Out”
The “Reason” to be a coded/free-text field (configurable) and the “Date” field to be as it is
I reckon “Transferred Out” would only be a temporary closure since the patient can come back to that facility and seek care again as compared to “Dead” where the consultation shall never happen after the autopsy reports are submitted. However, the patient record should be searchable and dashboard should be accessible in both the cases.
The functional flow you have mentioned here seems fair to me. The status can be changed to “Active” when the patient returns for a consultation in future.
I am not sure about introduction of an attribute. Also please do not rename “death information” - that specific widget has specific behavior. If you select a “Reason for Death” (you can configure that in OpenMRS admin for possible reasons), then upon selection of a date and reason, the patient is marked as deceased. So I would not change the behavior there. Any changes in the way, you described will require to totally change the design and code, and more importantly the objective intended for that section.
If it is just about reporting, then I think you can easily get that (with the current data model)
- if a patient is deceased, (person.deaf = true)
- You can track an attribute or Observation form element - to check whether “transferred out”
- if none of the above, obviously “active” (I am guessing that by Active - it is irrespective of whether visit is active or not)
I don’t assume that you intend to make the registration person fill out such details - that would not be right - as this states are supposed to be driven from other parts of application - like filling out a transfer form. We can’t assume that registration clerks will fill up such details for “closed assistance”.
I can think of few approaches
- Add ability to show your own section (interacting with your custom api)
- make “death information” widget not visible at all. (introduce configuration, although there is a hacky way to not show that widget - just give a random non-existent concept name for “Reason for death” in settings)
- Enhance the current section
- A top level section, which also includes existing “death information” . [Whether you can modify the details is determined by patient.dead - even now]
- Add ability to capture other configurable attributes there, just like the current ability to group fields.
Regarding whether you can make “Reason for death” free text - will depend on the OpenMRS core model.
See relevant discussion here