Project

General

Profile

Support #1184

informal care receipt in wave 7

Added by Sean Urwin almost 5 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
-
Start date:
04/11/2019
% Done:

100%


Description

Hi,

I am currently using the information regarding informal care receipt in the social care module of wave 7.

Those eligible for this module can indicate their relationship to up nine nominated informal care providers ('g_hlpinfa1…g_hlpinfa9') and the associated person number of these providers ('g_infano1…g_infano9'). Using the information provided in the g_egoalt data file of relationships between all household members I have found that 'g_hlpinfa1…g_hlpinfa9'and 'g_infano1…g_infano9' can provide conflicting information. For example, one case may be that a recipient indicates they receive informal care from their son, daughter and grandchild via 'g_hlpinfa2, g_hlpinfa3, g_hlpinfa4', however the person number given via 'g_infano2, g_infano3, g_infano4' is only of one of these. If I have correctly identified a discrepancy in reporting would it be appropriate to assume that the relationship information or the person number information is correct?

There are various other types of discrepancies similar to the one described where the relationship and person number information do not match. Would it be possible to have some information on how the person number via 'g_infano1-9' was inputted into the survey (or any other relevant information regarding these variables)?

Many thanks in advance
Sean Urwin

#1

Updated by Alita Nandi almost 5 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 30

Hello Sean,

I have looked into this and identified these discrepancies that you have mentioned.

The relationship information included in EGOALT files in the variable RELATIONSHIP is the information inputted by the interviewer. Sometimes, there is an error at this stage. After the data is delivered, our data team checks for inconsistencies and corrects it. That information is recorded in RELATIONSHIP_DV. So, that is one reason why the PNO in G_HINFANO* may be different from those you get using EGOALT. But this difference may also be due to mistakes made when inputting information in G_HINFANO*.

I have asked your question about how interviewers input the information in G_HINFANO* to our survey team and will get back to you when I hear from them.

Best wishes,
Alita

#2

Updated by Sean Urwin almost 5 years ago

Hi Alita,

Thankyou for looking into this so quickly.

In that case do the data team correct RELATIONSHIP_DV based on a respondents answers to other questions in the survey?

I neglected to mention that in some cases G_HINFANO can be a PNO of 16. When I check the PNO numbers no respondent has a pno of 16. Is there a reason behind this i.e a temporary resident? I imagine the survey team may know, but I just wanted to add this.

Apologies for the extra questions, your help is very much appreciated!
Sean

#3

Updated by Alita Nandi almost 5 years ago

  • Private changed from Yes to No

In that case do the data team correct RELATIONSHIP_DV based on a respondents answers to other questions in the survey?

YES

I neglected to mention that in some cases G_HINFANO can be a PNO of 16. When I check the PNO numbers no respondent has a pno of 16. Is there a reason behind this i.e a temporary resident? I imagine the survey team may know, but I just wanted to add this.

I have passed on this additional query to the data team.

Best wishes,
Alita

#4

Updated by Alita Nandi almost 5 years ago

  • Assignee changed from Alita Nandi to Sean Urwin
#5

Updated by Alita Nandi almost 5 years ago

There is a dropdown list of all household members with PNOs attached and the respondent chooses the carer from this list and their PNO gets assigned to HINFANO*.
The G_HINFANO* =16 was due to error.

#6

Updated by Alita Nandi almost 5 years ago

  • % Done changed from 30 to 90
#7

Updated by Understanding Society User Support Team about 3 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (Sean Urwin)
  • % Done changed from 90 to 100

Also available in: Atom PDF