meaning_of_principal_record wrong if imputed_start_of_pregnancy = 1. v5.0.1

[visama]

I'm running version 5.0.1. Main output table has "PERSON_RELATIONSHIP" as value for variables meaning_of_principal_record/origin if imputed_start_of_pregnancy = 1. This includes many birth registry cases we cannot now extract. Is this fixed for new versions of the algorithm?

@GiorgioLimoncella

[GiorgioLimoncella]

Hi @visama,

The algorithm also uses the "PERSON_RELATIONSHIP" table to identify pregnancies.

If a mother-child link is present in this table, a pregnancy is defined using the child's birth date (if present in PERSONS) as the end date of the pregnancy and imputing the start.

If necessary, I can modify the algorithm parameters so that the table "PERSON_RELATIONSHIP" is not used for THL, but in this case, you would no longer have the mother-child link available even for pregnancies included in the birth registry.

Otherwise, there is a parameter to filter out pregnancies that are not legally includible. We can exclude all the pregnancies identified by PERSON_RELATIONSHIP that are not in the registry.

I will make a new release (5.2.2) that includes your chosen modification.

[visama]

Hi,

those pregnancies should be recognized from survey_id table(PROMPT-stream). Now we have a pregnancy in survey_id with survey_meaning = "birth_registry", but if its missing length of pregnancy in survey observations table, meaning_of_principal_record/origin is "PERSON_RELATIONSHIP". Length of pregnancy is attached to child in survey_obs-table, that's why there is need for mother-child linkage.

Also for these cases imputed_end_of_pregnancy = 0, so I think they are not identified from PERSON_RELATIONSHIP.

[GiorgioLimoncella]

I think I understand now.

By default, the algorithm considers the child's date of birth found in the PERSON_REL table as more reliable information than the one found in survey_id when some information is missing. Therefore, meaning_of_principal_record is equal to "PERSON_RELATIONSHIP".

All pregnancies from PERSON_RELATIONSHIP have imputed_end_of_pregnancy = 0 since the pregnancy end date is specific and corresponds to the child's birth.

If pregnancy is found in survey_id and PERSON_RELATIONSHIP, and there is no complete information in survey_observation, would you want the primary record to be the survey_id? (this implies, for example, using the survey date as the pregnancy end date instead of the child's birth date when the pregnancy end date is missing)

If there is any doubt we can have a short meeting and check these pregnancies together.

[visama]

I think it would be better to use survey_id as primary record. At least for Dp5 we want to exclude all the pregnancies from malformation registry using meaning_of_principal_record/origin. Currently we can do this since meaning_of_principal_record = "PERSON_RELATIONSHIP", includes only pregnancies from birth registry. I need to discuss this with project lead and check whether any changes are needed.

[visama]

Is the type of pregnancy always fixed as LB for these cases? I noticed, that now we have some SB pregnancies labeled as LB although, they would have pregnancy type information in survey observations.

[GiorgioLimoncella]

Hi @visama, Yes, the type of end of pregnancy is equal to LB for all records coming from PERSON_RELATIONSHIP. I can easily modify the hierarchy for THL, defining the survey_id records as always more reliable than the PERON_REL record. This would change the meaning of the principal record. Let me know if you want me to do this modification!

[visama]

Hi,

i talked with Maarit and she agreed to use survey_id instead of PERSON_REL in case of missing data. So if you can do this modification, it would be great.

[GiorgioLimoncella]

Hi @visama,

I have just published release 5.2.2 which includes the change.

[visama]

Thank you Giorgio. It seems to be working now.