Updates - Essential guidelines

Whenever working on Pending Updates in ZIMS for Studbooks, keep the following in mind:

• Although the screen is called “Pending Updates”, just after migration it may as well have been called “ Differences with ZIMS for Husbandry data ”. Essentially it is the software saying that it cannot make a direct match the studbook records for an individual, with the records entered by the institution for this individual.
• Differences with the institutional data are OK. Updates should only be accepted if this improves the data quality. Having matching data is not a goal in itself.
• Especially for historical data, be careful to only accept updates that improve your studbook data. Otherwise, reject them. Check after accepting new data for historic individuals if the studbook records of the individual still make sense.
• At times, it will not be possible to get the studbook data correctly entered by accepting updates. Therefore, it may be required to reject one or all updates and enter or correct the studbook records manually. The goal is to have correct (true) and reliable studbook data.
• To receive Pending updates, an individual’s studbook records need to be linked to the records in ZIMS for Husbandry. Individuals that do not have a GAN in their studbook records are not linked, so either need to be linked or their data needs to be manually updated.

Updates – Where to start

• For an explanation on how adding data and individuals to the studbook and accepting/rejecting Pending Updates in ZIMS for Studbooks works, see Species360’s studbook updates document and data entry presentation .
• Immediately after migration there will be many Pending Updates, mainly consisting of differences found between the institutional and studbook records. Filter or sort on updates of living individuals first, these are the most important and need to be cleaned up so that it is easy to identify new Updates for living individuals. Updates of historic individuals can improve data quality but are more of a long-term project to work on when time allows.
• If an update provides information that is
  • reliable and new (not yet included in an animal’s records), it can be accepted into the studbook as new data. This may require contacting the relevant institution to verify data.
  • already recorded in the studbook, but the software is not able to match it properly, it should be rejected. It can be counterintuitive to have to reject correct data, but this is not a problem as long as the studbook data contains all the best-known data.
  • not yet recorded in the studbook but is deemed incorrect or unreliable, it should be rejected or accepted and edited afterwards so that it reflects only true data.
  • more correct than the existing studbook records, the studbook records need to be manually updated to reflect the best-known data. Usually this will lead to a match in studbook and institutional data and the update should disappear. If this does not happen, the institutional update needs to be rejected.
• New updates for living individuals will pop up each time an institution makes a relevant change in ZIMS for Husbandry. Individual identifiers (e.g. transponders) entered by the institution automatically populate into the studbook for linked animals. New updates are more likely to be true updates that can be accepted into the studbook.

Maintaining your studbook in ZIMS

Transactions

• Realise that the Institutional records on the right screen may have been added by several different institutions (the institution lights up when hovering over the transaction).
• An added functionality compared to SPARKS is that individuals can now not only go Lost-to-Follow-up (LTF), but can also return from LTF. In SPARKS, an LTF event always had to be the last known event of an individual. The combination of a LTF event followed by a return to LTF event can be used to show that during that time you do not know what happened to this individual, so it theoretically could have been at other locations or produced offspring without you knowing it.
• Other transactions that are now possible are release and recapture events.
• Wild born individuals now also need a birth location entered. As a general rule, the location where it has been caught can be entered here, except if more accurate information is known.

Parentage

• Updates of UND parentage can be rejected.

• Accepting suggested parents into the studbook can be tricky if the suggested parent
  1. Is not yet linked to its studbook counterpart. In this case, note down the GAN of the parent and link the parent first.
  2. Has not yet been entered/imported into the studbook. In case you are certain that this parent is not in the studbook (rather than not yet linked), import the individual via the Suggested Animals list.
  3. It is of course possible that an individual has been entered as parent by the institution for which no records exist in ZIMS for Husbandry. In this case, a studbook record of this parent will need to be manually entered into the studbook with all the data available on this individual. The suggested parent will need to be rejected.

• If the parent suggested in the update is different than the parent recorded in the studbook, check if both the parent recorded in the studbook and the parent recorded by the institution were indeed theoretically able to be the sire or dam of this individual. If both are theoretically possible, work with the institution to determine which data is correct.

Sex

What is it? Different from SPARKS, sexing events in ZIMS for Studbooks can be tracked over time.

What is its use? For studbooks where the sex of an individual is usually correctly recorded before adulthood, keeping track of sexing events over time will add little to no useful information. In species where sex is often wrongly recorded for long periods of time, e.g. vultures, it may be useful to know that a species was wrongly identified for e.g. the first 20 years of its life.

How to use it: In order for the individual to be recorded correctly, the right sex needs to be recorded as last sexing event (with the most recent date). Whenever adding a sexing event, it is best to check if the sex type recorded for an individual is still correct.

Contraception

What is it?

• Different from SPARKS, more detailed (and analysable) information can be maintained on the reproductive opportunities than an individual had and will have.
• Historically, it has already been common to keep track of medical methods of contraception. Similarly, you can now keep track of Animal Management methods of contraception. This typically means keeping records in this screen for individuals when these were not being kept together or eggs were shaken.

What is its use?

• On an individual level, this information can be useful to keep and help you answer, e.g . Why did this individual not breed?
• On a population level, this information can be invaluable and help you answer, e.g. What is the effect of contraception on the ability to reproduce at a later stage? How many offspring should I expected in my population if all females would get to breed?

How to use it:

• For this information to be useful for population analyses it needs to be maintained consistently for the entire population. This may mean working closely with the institutions so that they enter their contraception data (start and end date) and animal management information (when were they separated for a long period, start and end date). As such, these will appear as Updates.
• The Contraception status that was tracked in the Master record of SPARKS have migrated to this screen. Contraception notes have migrated to the notes section, but note that the original creation data of the contraception note has been lost and replaced by the birth date of the individual. It is necessary therefore to manually re-enter these dates in ZIMS for Studbooks to avoid losing this information. To be able to take the information in these notes into account for analyses in the future, these will need to be entered as Contraception records.

Rearing

What is it? Different from SPARKS, it is now possible to keep track of a start and end time of rearing type.

What is its use? Rearing is a default field for an individual’s records. An end-date does not necessarily need to be entered. Whether it is relevant to keep track of an end-time of rearing differs per studbook. For example, if you would like to record that an individual was first parent reared until the age of three months, but after that hand-reared, you would record that here. This can be useful if you would like to analyse the effects of hand-rearing and want to take into account at which age hand-rearing started.

How to use it: Only keep track of the end-dates of rearing-events in a population where this is useful. It may be the case that you only do this for particular individual’s that have an unusual rearing case. You will want to keep track of rearing events on population level only if this is something that you will use for management or research at a later stage and will consistently keep track of.

Taxonomy

What is it? Different than in SPARKS, taxonomy is now a default field in every individual’s records. Studbooks can only migrate under one taxonomy, which means that if several different taxonomic names are used (e.g. to distinguish between subspecies), that many updates for taxonomy will appear in the studbook.

What is its use? Similar to keeping this information in a User Defined Field (UDF), keeping track of taxonomy can be useful when more than one taxon is recorded in the studbook to allow taxon-specific analyses.

How to use it:

• A tool is in development that will allow UDFs for taxonomy to be translated into taxonomy, after migration. Therefore, if this is the case for your studbook, it is best to wait with correcting taxonomic information until the more time-efficient tool is available to enter this data for all historic individuals. For now, continue to track taxonomy as a UDF.
• If only one taxonomy is used in the studbook (i.e. the taxonomy is irrelevant for analysis of your studbook), it is of course possible to choose to not update taxonomy because this will not affect analyses.