Occasionally a user will accidentally create a new instance of an existing child during recorder assignment and transfer, resulting in one child's LENA data being spread across two or more participants.

In these cases, and when the birth dates and gender for both/all entries with processed data agree, you may be able to reassign the file(s) to one primary instance of the child, and then delete the extra instances of that same child.  This approach is sufficient for users who will not be using ADEX to mine the ITS file.  (Note that if the birth dates do not agree, you should consult LENA Support before reassigning the files as some of the data will have been processed with incorrect algorithms.)

Users who will use ADEX to mine the ITS file must take additional measures to ensure that ADEX output can be matched to the correct child.  Why?  Reassigning a file through the LENA Report List view does not overwrite the file's header, from which ADEX pulls the Child Key value (as well as DOB, age, and gender).  The ADEX output will always display the original Child Key - which, if you have deleted that "extra" child as above, no longer exists in your LENA database.  The only other identifier of the file's subject is the ChildID, which will reflect the current assignment.  See image below for details about which fields ADEX pulls from the original assignment versus the current assignment.

If you have files assigned to duplicate instances of the same child and will be using ADEX to analyze your ITS data, please contact [email protected] to determine the best option.