Stream: committers
Topic: yearIsValid() in InstanceValidator
Patrick Werner (Feb 27 2019 at 17:49):
yearIsValid() currently checks if the year i is i >= 1800 && i <= 2100
The FHIR spec only has a regex to validate dates and doesn't has restrictions on min or max years, i propose to just get rid of yearIsValid() and do only the regex check.
GF#20480
Pull Request: https://github.com/hapifhir/org.hl7.fhir.core/pull/9
and could @James Agnew or @Grahame Grieve give me rights on fhir.core please, would make my PRs easier to create as i don't have to fork anymore.
Patrick Werner (Feb 28 2019 at 10:30):
@Lloyd McKenzie i updated my GF tracker to explain why this is a GF Tracker and not a hapi issue
Lloyd McKenzie (Feb 28 2019 at 15:36):
The issue doesn't appear to be obviously related to either specification publication or validation - either of those things would make it appropriate for a gForge item. @Grahame Grieve ?
Patrick Werner (Feb 28 2019 at 15:41):
it is related to validation, as this is a class used by the FHIR java validator to validate dates. I just saw that there are issues enabled on fhir.core (must been blind yesterday).
If @Grahame Grieve agrees i move the tracker there.
Lloyd McKenzie (Feb 28 2019 at 15:43):
I've removed the proposed disposition. Can you provide an update on how the proposed change impacts validation?
Patrick Werner (Feb 28 2019 at 16:15):
done.
Grahame Grieve (Mar 02 2019 at 19:39):
I don't agree with the change, actually. Just because the regex can't impose the checks doesn't mean that they're not valid. When would a date outside that range be valid?
Lloyd McKenzie (Mar 02 2019 at 19:49):
It's possible we'll start to hit coverage policies that have end dates in the 2100+ range in the not too distant future. And super-deep family histories could potentially have dates earlier than 1800s, though grant that would be pretty uncommon. In any event, seems like something that's more appropriate to be a warning than an error.
Grahame Grieve (Mar 02 2019 at 19:51):
coverages for 80 years? And family history >200 yrs? neither are realistic. I've only ever seen dates like this as a mis-typing e.g. 2109 instead of 2019
Lloyd McKenzie (Mar 02 2019 at 21:46):
Coverages can come into force and be set to expire automatically at a particular age (often age 75). We're approaching the point where employees could be starting to receive policies that have such expiry dates. The key thing is that such a date isn't a guarantee of an error - it should be a warning to double-check that you didn't mess something up.
Patrick Werner (Mar 04 2019 at 13:49):
i also would be fine with the change from error -> warning. I can update my PR and GF to this new resolution
Patrick Werner (Mar 04 2019 at 13:52):
The cause of this GF was a coder colleague getting validation errors and was wondering why. He had 2222-02-02 as a test date, the error only "The year 2222 does not have a valid year", i took a look into the code to understand the cause of it.
John Moehrke (Mar 04 2019 at 14:13):
coverages for 80 years? And family history >200 yrs? neither are realistic. I've only ever seen dates like this as a mis-typing e.g. 2109 instead of 2019
The USA VHA has retention and coverage lengths this long. Like death+75 years or something like that. Unusual yes, but because of their service to country they get unusual benefit
Last updated: Apr 12 2022 at 19:14 UTC
