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