DEATH EVENT LOCAL IDs AND DEATH CODE MAPPING

 

Contact support@Species360.org

Overview of the changes to death event local IDs:

• In historically migrated studbooks, death codes entered in the local ID field in SPARKS/PopLink were migrating into the local IDs field of the transaction record in ZIMS. All death codes were mapped (and will continue to map) to the Death Information section of the death event.
• Species360 has now changed the migration process and fixed previously migrated studbooks by replacing the death code that was displaying in the death event local ID field with the local ID from the previous transaction (with some exceptions) for all the studbooks.
• This change has been implemented for studbooks that have previously migrated into ZIMS and all future studbook migrations.
• See below for a more detailed description on how the death event local IDs are populated for studbooks that migrate from SPARKS and PopLink.
• Additional information on how legacy data is mapped to ZIMS can be found in the Data Migration Comparison document.

EM-01 Duplicate Local ID Data Quality Error:

• In situations where the death local ID has not been replaced and a death code remains in the death event local ID field, you may receive a data quality error informing you that multiple animals have the same local ID.
• In this case, it is recommended that you edit the death code that is displayed in the death event local ID to reflect the local ID at the time of the animal’s death.  Once the local ID is changed to a unique ID then the error will no longer be displayed.
• Watch the Data Quality Duplicate Local ID video .

SPARKS Studbooks:

• In SPARKS there is no option to enter a local ID for the death transaction. The user instead is prompted to enter a death code when entering a death event – in the SPARKS database, this death code is held in the local ID field which is why historically after migration to ZIMS the death code was displaying in the local ID field. 
• All Death codes from SPARKS mapped into the Death Information box in the death transaction view/edit screen in ZIMS during migration so no information held within the death code field is lost during migration.
• Changes to the SPARKS migration Process:
  • Local ID is a required field when entering a death event in ZIMS. Since there was no local ID entered in SPARKS for death events death local IDs are created during migration in the following way:
    • ZIMS populates the death local ID with the local ID from the previous transaction event (if the death event and the transaction prior to the death event are at the same location). 
    • See example below where the location of the transfer and death match. The transfer local ID has been populated in the death local ID.

• The local ID will always populate from the transaction prior to the death transaction unless:
  • The previous transaction and the death transaction location do not match. If this is the case, then the local ID will remain the death code that was entered in SPARKS and the user can edit the local ID if desired.
  • See example below where the location of the transfer and the death do not match. The death ID has not replaced the death code in the local ID field.

PopLink Studbooks:  

• In PopLink, the convention is to enter the death code as the local ID for an animal for the death transaction. There is no other place for death codes within PopLink, other than notes section (if there is a note for an animal, this note is migrated to the animal notes box in the animal detail).
• SPARKS studbooks that have been transferred to PopLink have the death code entered in the local ID.
• In many cases, the studbooks in PopLink are a hybrid of death codes and true local IDs entered in the death event field.
• The ZIMS migration process determines if the local ID entered in the death event is a death code and if it meets the criteria for a death code then the code is mapped to the Death information within the death event accordingly so no information held within the death code field is lost during migration.
• Changes to the PopLink Migration Process:
  • If the local ID entered in the death event is a local ID and not a death cod6,e the local ID entered in PopLink migrates to the death event local ID field.  
  • If the local ID entered in death event is a death code, then:
    • ZIMS migrates the death code to the Death Information field and the local ID for the death event will populate from the prior transaction.
    • See example below where the location of the transfer and death match. The transfer local ID has been populated in the death local ID.

 

 

 

 

• The local ID will always populate from the transaction prior to the death transaction unless:
  • The previous transaction and the death transaction location do not match. If this is the case, then the local ID will remain the death code that was entered in SPARKS and the user can edit the local ID if desired.
  • See example below where the location of the transfer and the death do not match. The death ID has not replaced the death code in the local ID field.

 

 

 

 

 

 

 

Revised 5 March 2025