Death Registration Form

Product Features and Functionality
, ,
1

We shall have a meeting on 2022-03-29T21:00:00Z focusing on Death Registration form flows. We will showcase the default configurations in our death forms, additional fields for consideration and establish what other fields should be configurable in the form.

5 Likes
2

Hello Product Council,
In this week’s meeting, we would like to discuss with you about the following questions in the death registration flow:

  1. Should we always capture the Mother, Father and Spouse details of the
    deceased?
  2. How should we capture the Manner and Cause of Death Details?
  3. What is the Full List of Supporting Documents we want to capture for the Death Registration?

Please reply with your comments to the questions as well as log into the Zoom session for further discussions. Thanks.

6 Likes
3

Thanks, @Anne_OpenCRVS.

My tuppence:

  1. Under Ghana’s recently repealed death registration law and procedure, details of the parents’ place of permanent residence were required only if the deceased person was aged below 15 years.

To the best of my knowledge, the subsidiary legislation ( the “Regulations”) necessary to give practical effect to our new 2020 Births & Deaths Registration Act has not yet been passed. Therefore, we’re technically in a state of legal BDR limbo, but I think the old law continues to apply in the interim.

From a professional database designer’s point of view, I don’t think these data attributes are strictly relevant anyway. What is absolutely crucial is a unique personal identifier, and I hope we’ll have a good discussion about the options for that.

If there’s a chance that details about spouse(s) and or parents might be mandatory, or otherwise useful, in some other country-specific context, then could the corresponding form fields be made optionally visible, perhaps?

  1. I would recommend that the Manner & Cause of Death input form should conform as rigidly as possible to the (2016 or later revision of the) WHO International Form of Medical Certificate of Cause of Death, even if the national form does not.

Beyond that, I’d suggest too that all input to the MCCD form should be restricted to lookup references drawn from built-in Lists of Values, based on the most appropriate standard glossary of medical terms, e.g. ICD (-9, -10 or -11) or SNOMed. This would give OpenCRVS the competitive advantage of generating pre-coded causes of death information, which I suspect the statistics and bio-informatics constituencies would find super-sexy. :grin:

  1. For the registration of a death, Ghanaian procedure demands the presentation of a “medical death certificate” or, where applicable, a coroner’s inquest report.

Although other personal data points about the deceased are requested — such as Name, Sex, Date of Birth, Marital Status, and Place of Usual Residence — no documentary proof of these details is required. (I consider this to be one of the fundamental defects in our national BDR process, by the way.)

OK, that’s it for now. I hope some of the above is helpful.

KAAM

PS. Fair warning: During the meeting, I might throw a big spanner in the works of this flow, in the form of a brainwave I had some months ago. If I do, please forgive me, but I hope it proves to be a big 24k gold spanner. :wink:

5 Likes
4

kin
kin1129Ă—345 72.5 KB

Configuration Master

2 Likes
5

Thanks to Anne, Ed and all. That was a great discussion.

Based on this morning’s exchanges of ideas, I think the ideal primary unique personal identifier for the deceased person in the death flow, which I referred to above, would be the corresponding Birth Certificate Number.

This requires no reference to external systems, but progressively enforces referential integrity with respect to births and deaths records.

:+1:

4 Likes
6

Hi :wave:t6: Access to the slide deck and recording below

Product Council_Death Registration Form Flow.pdf (323.4 KB). For the question regarding how to capture the manner and cause of death, please check out slide 7, the See Prototype link, to test the prototype options.

For the zoom recording click here Passcode: =A2Z=GWi

3 Likes
7

Thanks for participating in the discussion and the insights provided. I think the discussion on the personal identifier continues to be a topic of interest for many countries and we will continue to explore further. For now, we will use the feedback received today to improve the death forms design.

Best regards,

3 Likes
8

Thanks Ashish for this suggestion. It was also great to hear your suggestions for the form improvements during the call.

2 Likes
9

@Anne_OpenCRVS details of the deceased can always have any one of the father, mother or spouse though with a linked CRVS system for those with National ids linking birth and death to civil registration the information is already with the national Register so this could be automatic once the national identification number of the deceased is provided the update is automatic with links to father mother and spouse details already in the national register.

3 Likes
10

You’re welcome, Annina.

Just a clarification, if I may, of the desirability of a more generic (i.e. non-country-specific) user interface design for capturing optional information regarding the deceased person’s parents, spouse(s) etc. — about which I recall Emily and I both expressed agreement during the second PC session. I don’t think the meaning of my scribbling in the chat window there was necessarily obvious.

My suggestion was:

  1. The panel itself would have a general title e.g. “Relationships”.

  2. It would feature either a table or an extensible set of grouped fields, whichever was most easily accommodated in the display window.

  3. Each row or group would include the following input columns or fields (* = mandatory):
    a) Name*
    b) Unique ID
    c) ID Type
    d) Address
    e) Telephone number
    f) Relationship to the deceased* → Drop-down list of values: Mother | Father | Spouse | Next of Kin | Other (Specify)

This design would cater for all jurisdictions, regardless of which (if any) family members’ details were required by law; it would handle polygamy; and it would accommodate the input of interested parties other than blood relatives.

Incidentally, the implied data structure here is also equally well suited to relational and non-SQL database backends. (I hope there’ll be a conversation about databases at some stage, in the TC perhaps?)

I trust some of this is helpful.

KAAM

3 Likes
11

Regarding “MCCD form should be restricted to lookup references drawn from built-in Lists of Values, based on the most appropriate standard glossary of medical terms”, best would be to include the API to ICD-11 (Home Page ICD API).

As for making name mandatory, this may not always be available (e.g. infant death; unknown deceased).

3 Likes
12

I think global trends and research bodies are favoring random numbers with checksum digits for UINs… as per this article from the WORLD BANK… (pg 17-21)
https://thedocs.worldbank.org/en/doc/795091518546134883-0090022018/original/IntegratingUniqueIdentification.pdf

3 Likes
13

Thanks for the valuable API pointer, Martin.

Just FYI, the mandatory name designation refers not to the deceased but to each specified relation of the deceased.

Best regards.

KAAM

1 Like
14

thanks for clarifying, sorry i misunderstood

1 Like