Starting with section I, the form captures two sets of data:
The disease/condition directly leading to death, (a).
Two possible antecedent causes, (b) and (c).
The existing DHIS2 tracker (see reference 1) goes up to four possible antecedent causes numbered (b), (c), (d) and (e).
In OpenMRS terms I would tend to see this as five obs constructs for (a), (b), (c), (d) and (e) that share the same questions:
Cause of death (Question/Coded), eg. ICD10-K720.
Interval between onset and death (Question/Numeric), eg. 1.
Units of interval between onset and death (Question/Coded), eg. Hours.
Underlying cause of death (Question/Boolean), eg. True.
Hopefully there is a more elegant way to that but I would basically end up with five convenience sets to record those five “same” obs constructs (same in the sense that they are made of the same questions):
(a) Disease or condition directly leading to death
(b) First antecedent disease or condition leading to death
(c) Second antecedent disease or condition leading to death
(d) Third antecedent disease or condition leading to death
(e) Fourth antecedent disease or condition leading to death
162569 is the current cause of death list which can be used to capture Causes of death from a death certificate. I am not sure the need to include the “underlying cause of death” as opposed to contributor to cause of death as the ordering on the death certificate is usually sufficient. Can someone clarify if that is truly required?
I agree that the interval and units would need to be added.
I think people expect that the ordering of the top three are the causes of death and >3 are just associated. I don’t know if specifying one “underlying cause of death” has any meaning and why we would need to capture that element on each diagnosis.
@mksd I think so but this also assumes that the person filling in the death certificate enters cause(s) of death in the correct order (which is how it’s done on paper anyway…).
If the cause of death is ‘unknown’ then the underlying cause of death is also ‘unknown’.
I think DHIS2 modeled it that way to allow ‘easy’ data analysis. As it was designed in a tracker program, it has a program rule that takes the data from a data element that has the check next to the ‘underlying cause of death’ and pushes the data value to the question: Underlying cause of death. Which allows for generating a list of ‘underlying causes of death’.
Wow, I had no idea about all of this. We hadn’t needed to include SMoL or the one underlying cause. Since there is no way to know what the ultimate cause is from just the list, I do think we need a flag concept which would be applied to the last diagnosis on the list within Section I. I will look into whether CIEL should have SMoL codes as maps.
I don’t know what the actual user demand is for these codes. Since CIEL has more specific codes, those are what are supposed to be used. The SMoL codes can be calculated from the ICD-10 codes so capturing them in CIEL is a large overhead that probably is not warranted (unless I hear otherwise). As for underlying cause, I think we do need to add a new boolean flag which would be set for the primordial cause in section I.