Handle embryo/opu flush - add event for Flushing

[dirbSEGES]

Hi,

We have a need to handle when a animal have been "flushed" for embryos.

A simpel solution could be to add a new enum in inseminationType?

Then maybe EmbryouRessource should have a new property for numberOfEmbryos to set number of available embryos. And possible also and property for embryoType with enums OPU and EMBRYO.

[cookeac]

It might be appropriate to have an Embryo Flushing event which would have information about the facility, the number of embryos, quality, [age of the animal] etc.

• Craig to do some research; Andrew to ask the AI/RT WG.

[cookeac]

Presumably the properties of an icarReproFlushingEvent would have properties:

• embryoType (OPU, Embryo)
• collectionCentre (string)
• embryoCount
  [Plus all the normal event properties that identify date, animal, person responsible, etc]

[cvigorsICBF]

My research so far shows the following could be recorded as part of a flushing

sireIdentifiers - there can be 0 or more sires depending on the method used. For example, the 'OPU-IVF' can have the fertilization take place in the lab, while 'superovulation and flushing' can have the fertilization done via normal AI. Also, the AI straw used for insemination can consist of multiple bulls, or there could be multiple inseminations. The actual sire of any progeny can then only be determined by genotyping later.
embryoType - There are 2 methods of making embryos here at the moment,'superovulation and flushing' and 'OPU-IVF'.
collectionCentre
embryoCount - can be 0.

While I was asking about flushing, I also inquired about implanting, currently handled in the icarReproInseminationEventResource and icarReproEmbryoResource (I think)

• There may be a need to handle the fact that there may be multiple sires involved in the embyro. The current resource doesn't seem to cater for this.
• Some details could be recorded on the embryo used:
  • type - fresh or frozen
  • embryoType - 'Superovulation and flushing', 'OPU-IVF', possibly more as technology evolves
  • dateFertilized

If we need to cater for fresh or frozen, perhaps we need different naming for embryoType. Perhaps 'method'?

[cookeac]

Agreed we would like to add this event. Consider adding an array of potentialSire[] identifiers.

Useful fields for sires are identifier (scheme+ID), official name (but hard to keep up to date), URI or reference. These should be used in the potential sire array.

[cookeac]

At our meeting 2022-08-25 we agreed we should progress with this. Unless @cvigorsICBF wants to have a look at implementing this, or @dirbSEGES wants to pick it up, then @erwinspeybroeck will look when he gets time.

[cvigorsICBF]

I can pick this one up when I get a few minutes. If someone can give me a direction on how to generate those spec files, that would help.

[cookeac]

Discussed at the meeting on 2022-10-20, notes for @cvigorsICBF and others who are interested.

• Suggested that flushingType could be flushingMethod - just a little clearer.
• Long discussion about inclusion of sire details in the flushing event. Really this reflects one or more insemination events that (should have) been recorded beforehand AND data that should be transferred to generated icarReproEmbryoResource entities for each of the embryos.

Therefore several potential approaches to handling sire details:

1. Remove sire details entirely from this event - leaving it just with method, collection centre, and embryo count. Insist on recording sires against the donor dam with one or more insemination events.
2. Leave sire details in here, but minimise them - for instance, keeping the potentialSires array, but documenting that if the array only contains a single sire, this is the actual sire. This removes sireIdentifiers, sireOfficialName, and sireURI from the flushing event. We were also not convinced that the straw property was required in this case, so could also be removed.
3. Any other suggestions?

Separate from this but related, we discussed that there may be several potential sires:

• In an insemination event
• In a semen straw
  If agreed, a potentialSires array could be added to these as well. However, the existing sire fields would have to remain in those entities as removing them would be a breaking change.

[cookeac]

At the end of the meeting we discussed the v1.3 release. We would like to announce this at the wider ADE meeting 2022-10-20 (evening CET). Proposed that we would tag this issue and PR #337 with "next-minor-release" meaning they would target v1.4.

[cvigorsICBF]

Based on feedback this morning, my current view would be to remove all sire details including straw from the event.
These fields are more relevant to the embryo. Looking at some actual flushing data, the sire is known at time of flushing in 96% of cases, so the sire should be recorded somewhere. These fields already feature in icarReproEmbryoResource, so that should suffice.

The collectionCentre does seem to be more related to the embryo too, and already features in the icarReproEmbryoResource. Does that mean this can also be removed? If the need is to know where the flushing took place, this should be known by the location in icarEventCoreResource?

Therefore I propose that the flushing event consists of:

• flushingMethod
• embryoCount
• icarEventCoreResource

Should we provide a link to the embryo(s) [ icarReproEmbryoResource ] ?

There does seem to be a need to be able to handle multiple potential sires in an embryo.
There could be multiple potential sires due to using a mixed straw, or multiple inseminations. The icarReproEmbryoResource only handles the one sire.
I don't see this need as urgent, and to handle it well looks like a breaking change. Therefore, I propose that any changes required to handle multiple potential sires can wait until V2.

[cookeac]

Discussed at the meeting 2022-11-03 and agreed with Craig's recommendation to have less attributes (principally flushingMethod and embryoCount, and based on icarAnimalEventCoreResource.

Decided we did not need links to the embryo resources - as these might not be defined at the time of the flushing event, and they could later be linked back using the donor animal identifier and the collection date.

We decided to add back in collectionCentre (string). In theory an animal moved to a collection centre should have a movement and be at a new location, but not all recording systems may organise the events this way.