What concept(s) are you using for cause of death for your implementations?


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.

Thanks in advance!


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.

It looks like we require a “cause of death” concept in order to get possible answers. In older versions of OpenMRS, there’s some funky code that creates an cause of death observation (presumably to allow for non-coded responses?). This has been removed and now we just update the date and cause of death on the person object as expected.

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:

  • Add PROBABLE CAUSE OF DEATH (1599) to OpenMRS Platform’s default dataset
  • Change the default value for the concept.causeOfDeath global property to 1599.
  • 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.
1 Like

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

Looks like the old logic that you’re talking about is still in openmrs-core: https://github.com/openmrs/openmrs-core/blob/2.1.3/api/src/main/java/org/openmrs/api/impl/PatientServiceImpl.java#L1052

It seems to be used in the legacyui, htmlformentry, and the mdrtb module: https://github.com/search?q=org%3Aopenmrs+processdeath&type=Code

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.

The current design lets a user set the cause of death concept in the global properties. Its not hard coded.

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

Is this a problem with the legacyui? Can we look at a screenshot?

that is what I get when I change the value of that question from a concept_id to concept_uuid

Are you able to reproduce this at? http://demo.openmrs.org/

Yes @dkayiwa when the Cause of death value set here is changed from concept_id to concept_uuid

even the concept_id supplied for that global property is NOT found on the openmrs demo server

On which screen do you get the reported error?

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

Can you put a good existing concept on the demo server to reproduce?

I have placed there 460AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA which has possible answers of YES/NO/Unkown. please check it out

Typing in the cause of death field does not throw any javascript error.

Check at the top of your screen @dkayiwa

Oh i see!

What kind of REST calls are you planning to do with the uuid? Or is it just a hypothetical use case?

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

Got you. You can create a ticket for this in the legacyui module JIRA project.

1 Like