Bug: Rule 602 - Rule inverted

[SLornieCYC]

Describe the bug Rule is currently flagging all children adopted in year (AD1) with an in-year episode <REC> = E11 or E12.

Expected behavior It should be flagging children in AD1 who don't have an in-year episode <REC> = E11 or E12.

Proposed fix Either:

• the mask needs reversing to return all episodes that didn't end <REC> = E11 or E12 in-year (will also need to add .unique() to the production of err_list), or
• err_list needs to have a .dropna() where <REC> is null (i.e. has no episode ending <REC> = E11 or E12).

[dezog]

By the looks of it, this shouldn't be happening (See below). We drop non-E11/E12 rows from Episodes before merging with AD1, but then keep only the 'left_only' rows

I've looking through some fake data and it appears to be working as intended. It might be worth checking for:

• the case-sensitivity issue we talked about in the today's meeting
• the collection year being set incorrectly

            mask1 = (epi['DEC'] <= collection_end) & (epi['DEC'] >= collection_start)
            mask2 = epi['REC'].isin(['E11', 'E12'])
            adoption_eps = epi[mask1 & mask2]

            adoption_fields = ['DATE_INT', 'DATE_MATCH', 'FOSTER_CARE', 'NB_ADOPTR', 'SEX_ADOPTR', 'LS_ADOPTR']

            err_list = (ad1
                        .merge(adoption_eps, how='left', on='CHILD', indicator=True)
                        .query("_merge == 'left_only'")
                        .dropna(subset=adoption_fields, how='all')
                        .index
                        .to_list())

            return {'AD1': err_list}

[SLornieCYC]

Tried again, making sure I changed the collection year to 20/21. There shouldn't be any issues with case sensitivity as I'm using last years' finalised return csvs as exported from the DFE portal.

And here are the rows as they appear in Notepad+ (deleted other rows from Episodes for screenshot only):

[tab1tha]

@SLornieCYC can we say the only cases where adoption values are provided and an error is not raised should be when REC of that child is found to be E11 or E12 OR when the child is observed to have an episode within the collection period?

If this is correct, then the error can be resolved by changing & to | in the line where mask 1 is combined with mask 2. That is,

            mask1 = (epi['DEC'] <= collection_end) & (epi['DEC'] >= collection_start)
            mask2 = epi['REC'].isin(['E11', 'E12'])
            adoption_eps = epi[mask1 | mask2]

            adoption_fields = ['DATE_INT', 'DATE_MATCH', 'FOSTER_CARE', 'NB_ADOPTR', 'SEX_ADOPTR', 'LS_ADOPTR']

            err_list = (ad1
                        .merge(adoption_eps, how='left', on='CHILD', indicator=True)
                        .query("_merge == 'left_only'")
                        .dropna(subset=adoption_fields, how='all')
                        .index
                        .to_list())

            return {'AD1': err_list}

I am drawing the interpretation from the pseudocode of the error as stated here: https://github.com/SocialFinanceDigitalLabs/quality-lac-data-beta-validator/issues/262

[SLornieCYC]

I think the only cases where an error should not be raised are where child has <REC> = E11 or E12 OR where child does not have an episode in the collection period.

[tab1tha]

That makes a lot of sense. Thank you.

[tab1tha]

This is not as intuitive as I earlier imagined, I am considering the possibility that the bug is coming from the display side. @SLornieCYC please can you confirm that the Child ID is the same in the first and second screenshot which you shared?.

Also, is the error raised only when one of the conditions is true and the other is false but not raised when both conditions are true?.

[SLornieCYC]

Tested again on the live site:

Collection year: 2020/2021 Files loaded (from last year's submitted return): Adoption, Episodes

Result is as shown in the screenshots provided above.

• Child IDs match between both files, which is evidenced by the fact the front-end is grouping them together under the same ID in the filter list (and both file tabs show together within the child group).
• Child has a valid and complete AD1 record.
• Child has a valid Episode record with <REC> = E11 which ended during the collection year (matches both mask1 and mask2).
• Columns and errors are highlighted as follows:
• • Episodes.RNE >> #498
• • Episodes.DECOM, Episodes.REC, AD1.DATE_MATCH >> Error code 331 (bug not yet reported)
• • AD1.CHILD >> Error code 602

As @dezog wrote above, it does look like the mask is the right way around already because mask1 and mask2 are working additively to return only in-year E11/E12 episodes (which are then joined to AD1 and discarded as "correct" to find the remaining errors). I'm really struggling to see why - or where - my data is failing here, because to me it looks right.

[dezog]

Thanks for that @SLornieCYC, that's pretty definitive: this rule is playing up !

[dezog]

@tab1tha:

@SLornieCYC can we say the only cases where adoption values are provided and an error is not raised should be when REC of that child is found to be E11 or E12 OR when the child is observed to have an episode within the collection period?

If this is correct, then the error can be resolved by changing & to | in the line where mask 1 is combined with mask 2. (...) I am drawing the interpretation from the pseudocode of the error as stated here: #262

That pseudocode is so confusing; it does seem to say that, but I think it's mistaken as the text of the rule seems clear that it's meant to be making sure that any child with AD1 info filled in has an episode with E11/E12 REC AND a DEC during the year:

The episode data submitted for this child does not show that he/she was adopted during the year (...) If the child has been adopted during the year code E11 or E12 should be recoded as being the reason the episode ceased

[dezog]

I think I've cracked it - we're using the index resulting from the merge - we need to save the original index by doing .reset_index() first, then .set_index('index') before the .index

[tab1tha]

Nice spot Desi. I have implemented that change. Thank you @SLornieCYC for all the help !. Merry Christmas