I’m working on submitting a case report for a patient and I need to submit death info about them specifically the cause of death, in OpenMRS in order to mark a patient as dead, you need to specify the cause death and you’d need to first configure what the question concepts is, I’m curious to know what concept(s) implementations are using out there.
Base on this thread, it looks like cause of death is a bit confusing in OpenMRS.
The data model supports time and cause of death (coded) as attributes for a person. There has been some recent discussion in the Bahmni distribution about allowing free text as well.
In CIEL, one can find a CAUSE OF DEATH (5002) concept, but it has been voided. From what I’ve seen, folks are using PROBABLE CAUSE OF DEATH (1599). While this is technically different than the purpose of the Person.cause_of_death attribute (“probable” is used to record what family or caretakers believe might have caused death), it’s probably fair to assume the choice lists (possible answers) could be the same.
We should probably make a ticket for fixing this. Something like:
Consider whether or not to add some default answers so patients can be marked as dead within OpenMRS without needing to first create concept and set a global property.
Why not just have a proper concept with default coded answers added to CIEL? That way we don’t use PROBABLY CAUSE OF DEATH is which technically not appropriate
It seems that in the emrapi module (for the reference application) someone actively decided not to carry this code forward, based on the code comment:
TODO implement an API method for recording a patient’s death in this module (based on, but cleaner than, the PatientService.processDeath method)
Also, taking a step back, are we talking about the platform and API, or the reference application here? Because the platform/API already allows you to set person.causeOfDeath to any value.
I guess that the legacy UI and the reference application do limit you to a concept, but:
Currently the OpenMRS platform only includes two concepts, True and False. I don’t think we should add another one for this purpose unless we’re 100% sure it’s modeled right.
We should, however, include the correct CIEL cause-of-death set from CIEL in the Reference Application.
When the value of concept.causeOfDeath global property is altered from concept_id to concept_uuid, it blocks one from marking the patient as deceased because the list for reason of death can’t be displayed for selection. Are we NOT flexible to infer either from concept_id, name or concept_uuid? @dkayiwa do we have a workaround for this in latest releases, in my use case, if I SET that value to uuid, I get flexibility of doing REST calls but NOT able to mark a patient as deceased through OpenMRS UI. The version and testing against is 1.11.5
https://demo.openmrs.org/openmrs/admin/patients/patient.form?patientId=524 Just try mark that patient as deceased and try supplying the cause of death, when typing for the reason, the javascript error is displayed at the top of the page. For this server, since there is no concept_id 5002 which is mapped for that global property, the error is displayed explains it all, but if that concept could be existing and you alternate the value of that global property to a concept_uuid, you will a javascript error that I reported ealier
I currently do REST call by passing uuid of that Global property value, which works well for my javascript project, but when someone gets back to legacy UI to mark that patient as deceased, that error comes up blocking further business. My thought were, the call to that global property value should be generic enough to detect concept_id, concept_uuid or even concept mappings as opposed to Integer string values, that way if one decides to use it on the legacy UI all will be fine regardless of the string passed as long as validations are done to those options