Reproduction and lactation status values

[thomasd-gea]

For data exchange with a milk recording organization we need to be able to determine the current status of animals to report some data about them. In the current API there is no information about the animal status. I could imagine that one could derive the animal status from looking at the last animal actions, however, this seems quite cumbersome.

I'd propose to add an additional status to the AnimalCoreResource with enum values that reflect the current status. Possible enum values:

• other
• fresh
• early
• abort
• ready
• open
• inseminated
• pregnant
• pregnant2
• dry
• lead
• tbcull

[cookeac]

I agree with this concept, but I note that the suggested enumerations actually describe different types of status:

• lactation status (fresh, ?, dry)
• reproductive status (open, inseminated, pregnant, pregnant2?, abort, early)
• health status (tbcull, potentially others) In NZ we did some work on defining these a few years ago: https://github.com/Datalinker-Org/Farm-Data-Standards/blob/master/Animal%20Data%20Standards/ADS_Animal-Lifecycle-Data-Dictionary.md#animal-state

Would it be better to have separate fields for these? How do we deal with different health status and culling indicators in different species and countries?

[thomasd-gea]

I like the idea of separate fields, however, I don't know whether only one of these fields will have a really relevant value in real-world usage. Then I'd prefer only one field that virtually represents a status for each of the fields you mentioned. Also, there would be at least some semantically incorrect combination of values, I think. Unfortunately I'm a technician, so I don't have good examples to support either one or the other approach.

BTW: a health status (e.g. like ill, in treatment, healthy, …) would be great anyway.

[erwinspeybroeck]

Being an MRO ourselves, we like to calculate our own statusses based on the underlying information. There is some business logic involved and we rather know how it has been calculated. Can you give more info about the use case you're mentioning? We implemented an API returnign the reproduction status for an app, so they don't have to implement the business logic or even know the logic, but here we implemented this as a seperate API. Would that also be a solution?

[thomasd-gea]

In our use case we want to exchange the status set by the farmer for a specific cow, e.g. with a third party herd management system or to a system which needs to know the current status because they don't have the necessary data to calculate the status (e.g. no information about animal events). Using a service would also mean to externalize the business logic and, depending on how eager a farmer is to enter e.g. pregnancy checks, inseminations etc. it might be that the system cannot calculate the correct status because of missing data. In some cases, the farmer would even just set the status manually.

Example: we want to transfer milk sampling information to an MRO, however, they need to know which cows are currently set to "dry" so that they can be excluded from the sampling. I hope this is a valid example, maybe you get the idea.

[thomasd-gea]

We discussed this issue internally again and we'd like to propose the following:

Reproduction and lactation status should be put into one status field as they are very closely related. Health status should be separate as it is in general not related to the reproduction and laction status.

The new properties of an AnimalCoreResource could be named "reproducationLactationStatus" and "healthStatus" (but maybe you have better proposals, especially for the first one).

For reproduction and lactation status, we would see the following values (most likely an enum): Fresh Early Ready Inseminated Open Pregnant Dry Lead / Close up Other

For the health status we would see: Healthy Suspicious Ill In Treatment To be culled Other

Of course, each system can decide which status to return via the interface and how these values are mapped to internal status values. However, the status seem to represent the actual animal status detailed enough to support lots of use cases, but are (hopefully) not too detailed so that they cause large discussions in which status a cow is. "Other" could be left out in favor of just not returning a value.

Any comments?

[erwinspeybroeck]

We have currently the following status (reproduction)

UNKNOWN, OPEN, DO_NOT_BREED, INSEMINATION, NATURAL_SERVICE, IMPLANTATION, PREGNANT, NOT_PREGNANT, RUNNING_WITH_A_BULL, FLUSHED, ABORTION, IN_HEAT

[cookeac]

In NZ DataLinker we have a CurrentStatus sub-object which has properties for a number of derived or computed status values: Relevant ones are:

currentStatus: Alive, Dead, InTransit, [optionally extended to include: GrazingOff, GrazingOn, Lost] reproductiveStatus: Unknown (Null), Cycling, NotCycling, Pregnant, Involuting [I prefer the CRV list!] fertilityStatus: Fertile, Infertile, Neutered, Cryptorchid lactatingStatus: Dry, Fresh, Lactating

[MarvinGEA]

So here are the status we discussed internally:

Lactating: Dry, Lead (Close Up), Fresh, Early, Lactating Reproduction: Ready, Inseminated, Open, Pregnant, Calved

[MarvinGEA]

Since the current status property already exists in the AnimalCoreResource, I'll focus on the other status for now.

I'd say we should prefer to have more status value, over a very limited list, because clients with a smaller internal status list, can map them more easy.

If we combine all the lactation status values from @cookeac and us, we end up like follows:

Lacatating:

• Dry [NZ DataLinker, GEA]
• Lead / Close Up [GEA]
• Fresh [NZ DataLinker, GEA]
• Early [GEA]
• Lactating [NZ DataLinker, GEA]

What do you think about that status values?

[MarvinGEA]

For the reproduction status, it's more difficult. Let me explain the meaning of our status values and maybe we can find a way together:

Ready: The cow is ready to be inseminated.

Maybe this is the same like the CRV OPEN status?

Inseminated: The cow is inseminated, but not yet proved pregnant.

This probably overlaps with the CRV status values INSEMINATION, _NATURALSERVICE, IMPLANTATION. Which describes more the way how the insemination was made, which is already covered in the ReproInseminationEventResource?

Open:

Preg check was not successful and the cow is open to be inseminated again.

Is this the same like the CRV _NOTPREGNANT status? I guess then the CRV name might be more intuitive.

Pregnant:

Preg check was successful.

I guess that's the same like the CRV PREGNANT and the Datalinker pregnant status.

Calved

When a cow calved it turns into the Calved status.

I guess that's the same like the Datalink Involuting status.

So in a first place I'd suggest the following reproduction status values:

• Unknown
• Open (like the CRV OPEN, not the GEA Open)
• Inseminated
• Pregnant
• Not Pregnant (the GEA Open status and CRV _NOTPREGNANT status)
• Calved

I didn't cover the _RUNNING_WITH_ABULL, FLUSHED and _INHEAT status values. Do we need those or are they already covered by other ICAR resources?

[cookeac]

Excellent work @MarvinGEA. I agree with the Lactation status values you have proposed.

In terms of Reproduction status, I have a couple of questions:

1. Calved - unfortunately in English calving is very specific to cows, with kidding used for goats, lambing for sheep and fawning for deer. I was trying to find a better term for this, and the best I could come up with was birthing and hence the status value birthed. This is not ideal but better than involuting! We have used Parturition for the birth event, but there is no verb equivalent.

2. If an animal has an abortion, presumably it can return to Not Pregnant, and then when cycling again become Open?

[MarvinGEA]

Regarding Calving: I agree with your concerns. Even though the status birthed sounds funny to me :D, I don't have any better suggestion. Maybe someone has a sudden inspiration on Friday.

Regarding Not Pregnant: In our case the animal stays in the Not Pregnant status until it's pregnant again. Because we don't track an event, when it starts cycling again. But I'm not sure if we need to define the status transition in this case. Maybe this can be up to the server?

[cookeac]

At our meeting on 14 August 2020 we reviewed the codes and decided on:

• lactationStatus - Dry, Lead, Fresh, Early, Lactating
• reproductionStatus - Ready, Inseminated, Open, Pregnant, Birthed (generic replacement for Calved)

Our preference was two separate status values, but we asked participants to consult with their organisations to see if this could cause problems.

[thomasd-gea]

In scope of this ticket we should also implement two status change events. I would propose two events because this indicates clearly that you want to change that status. If we would do one status change event for both status it is not clear what was intended if one of the status fields is "null": "no change" or "change to null".

And just to be sure: we leave the lactation or reproduction field empty (i.e. not transmitted) instead of having explicit "unknown" status values, correct?

And I'm confused: the values that @cookeac listed differ from the ones that @MarvinGEA described. "Ready" was not in Marvins list, however, "Not Pregnant" was?!

And last, not least: What about the health status?

[thomasd-gea]

@MarvinGEA and I created a pull request for the basic status fields based on the original proposal by Marvin.

Now for us still the question remains: how do we change the values (I also opened #140 for this topic in a more general view):

• Do we need animal repro/lact status change events?
• Do we need an event per status (similar to dry-off, which hasn't any specific fields)?
• Do we just us PUT for updating the status value?

So more generally speaking: Do we need to exchange information about animal status changes apart from the ones that already exist (calving, dry-off, ...)?