Allow any date to be entered in manual entry, not necessarily confirmed date

[Mougk]

Describe the issue There are plenty of sources (Argentina, Colombia, ..) that may not have the case confirmation date but instead onset of symptom, clinical consultation or other.

Expected behavior Make requirement that ONE of the dates is entered but not necessarily date of case confirmation.

[sratcliffe118]

@Mougk if the clinical consultation is the event that confirms the case as Covid-19 is this not the case confirmed date? When we discussed this previously we scoped the dataset MVP to only confirmed cases, not suspected or discarded.

So in the below scenarios the entry would be:

Onset of symptom: These would not be included until it was a confirmed case. Once confirmed the case could be added to the dataset Clinical consultation: If this was the event that confirmed this was a case of covid-19 then the case could be given the the case confirmed date of the consultation and there is a confirmation type match this. Other: Need more information to comment on this one.

[sratcliffe118]

@Mougk assigning back to you

[Mougk]

Good points.

In a scenario where we have: a) no date of confirmation b) database indicates the case to be confirmed c) date of onset is known

We have no way of entering it into the database without making a strong assumption on when the case was confirmed. Not sure what the best solution is but we could remove the 'required' on date of confirmation and allow data to be ingested with one of the alternative dates (as long as the original database indicates that the case is confirmed).

Agreed, in MVP we do not consider suspected/discarded/negatives but will have to scope for that of course moving forward.

PS: Confirmation date is date of laboratory result or when assessment is made based on clinical symptoms.

[sratcliffe118]

Confirmation date is date of laboratory result or when assessment is made based on clinical symptoms. Although technical this may be true, this is not how the current standard data model works. We allow a case to be created as a confirmed case based on clinical diagnosis, if the case is later found to be negative, then the case 'should' be removed from the dataset.

If we wish to pivot the data model to only record confirmed lab result cases, then this will be a change to the underlying model.

We could remove the 'required' on date of confirmation and allow data to be ingested with one of the alternative dates (as long as the original database indicates that the case is confirmed). This is a big change as it means that any suspected cases could be added and users of the data would need to know that only those cases with a confirmed data are lab confirmed. It also changes the dataset narrative

Given the size of the change here, I suggest that this decision is paused to post MVP and then a review session held with the G.h team to bring a recommendation proposal to the group for discussion and decision.

[Mougk]

Let's pause here. I will develop doc for post fellowship to make these changes to allow flexibility and adaptability for general use.

[allysonjp715]

One option could be to have a "confirmed" field with values yes/no and selecting yes is required rather than entering the date. Similar to how we have a "hospital admission" yes/no field and a separate "hospital admission date"

This would fit into the existing data structure as "yes" could be the value of the confirmation event.

[Mougk]

I like that solution :)

[sratcliffe118]

SG, we do need to look at this more holistically as well e.g. what would you expect to see in the maps etc.

On Mon, Sep 21, 2020 at 10:29 AM Moritz Kraemer notifications@github.com wrote:

I like that solution :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/globaldothealth/list/issues/1142#issuecomment-696003431, or unsubscribe https://github.com/notifications/unsubscribe-auth/APCG7P5AS6NSEZGNDHZDLATSG4MHXANCNFSM4RTRQIVA .