Use of ISO8601

[StoneCypher]

You use the date-only format for ISO8601.

When not paired with a timezone, this is explicitly GMT, and is likely to lead to a lot of off-by-one errors, where some hospitals use the 1/3 day shift in date, and others do not.

It would be best to include a timezone.

[shaselton-usds]

Thanks for the feedback! The dates that are required at this point (e.g. within the file name, when the file was updated, when the contracts end, etc) aren't meant to be used in a way that requires the precision that you bring up.

We'd be interested in how would timezone information impact how the data in the file is used. Is there a specific use-case?

The ISO8601 date format requirement that is included in the name of the file will probably remain what it is.

[StoneCypher]

We'd be interested in how would timezone information impact how the data in the file is used. Is there a specific use-case?

If you attempt to roll up, by example, how prices change in response to availability, this will damage your understanding of response curves.

Consider the case for Denmark as of yesterday. They've permanently removed one of the four Covid vaccines, and are likely about to remove a second. As a result, supply has essentially dropped, and their cost of acquisition rises.

Consider the case of a new factory in America coming online, a primary approval of an off-label use, a more affordable SKU arriving, a government program supporting, &c.

The price transparency guide will likely soon become an essential tool for the dataset of how price impacts ripple out through the system in the real world.

Smearing the dates by 1/3 will actually be pretty damaging to things like lagged response curves and so on.

Also, it's just kind of a cleanliness thing.

.

The ISO8601 date format requirement that is included in the name of the file will probably remain what it is.

If so, could you at least mandate that all dates are GMT?

[sgpeter1]

The update cycles for these files in many cases will likely be the minimum required, which I believe is monthly. Also, pricing in healthcare contracts doesn't generally change very quickly (because of the contracting and negotiation involved).

Given this, I think the simple date form is adequate.

[StoneCypher]

Sure hope they just choose to say "all dates are GMT" in the readme, making the problem impossible, rather than unlikely.

Declining to do so is not a "simpler" form

I'll step back after this

[shaselton-usds]

@StoneCypher, as mentioned, at this point given the timing of the updates that are required (monthly) and potentially how the data is going to be used (most likely within a day's precision, though it would be silly to assume what industry actually does), keeping the broad, minimum requirement of YYYY-MM-DD should be accurate enough.

That said, after the go-live date we find that this requirement isn't strict enough, we can certainly revisit the issue.