AAVLD-USAHA-ITStandards / eCVI

eCVI Data Exchange Standard (Starting with version 2)
12 stars 9 forks source link

NUES9 (and NUES8) regular expression validator does not validate MO, CO and other state codes #74

Closed YdaMitzyTorres closed 1 year ago

YdaMitzyTorres commented 2 years ago

Current:

Should it be: or even enumerate all state codes + US? Same issue for NUES8 - for sheep/goats that can have State Code not 2-digit numeric State code. Can this fix be applied immediately? [ADT_eartags_criteria.pdf](https://github.com/AAVLD-USAHA-ITStandards/eCVI/files/8248382/ADT_eartags_criteria.pdf)
SusanCulpDVM commented 2 years ago

@YdaMitzyTorres, I checked with @mkm1879 for history on this.

He indicated that that regex was very specifically created because the experts on the committee said those were the only states that used state letters instead of the numeric code on their NUES tags. So step one is confirm that that was wrong or changed.

SusanCulpDVM commented 2 years ago

@YdaMitzyTorres, we only do immediate "fixes" on editorial changes to things that don't affect validation.

SusanCulpDVM commented 2 years ago

To providers who complied with the current eCVI schema, how did you address the current pattern requirement?

YdaMitzyTorres commented 2 years ago

Thanks for the quick response @@.***>. What type of supporting documentation do we need to provide to allow other state codes other than what is currently enumerated?

From: SusanCulpDVM @.> Sent: Tuesday, March 15, 2022 10:07 AM To: AAVLD-USAHA-ITStandards/eCVI @.> Cc: Mitzy Torres @.>; Mention @.> Subject: Re: [AAVLD-USAHA-ITStandards/eCVI] NUES9 (and NUES8) regular expression validator does not validate MO, CO and other state codes (Issue #74)

@YdaMitzyTorreshttps://github.com/YdaMitzyTorres, I checked with @mkm1879https://github.com/mkm1879 for history on this.

He indicated that that regex was very specifically created because the experts on the committee said those were the only states that used state letters instead of the numeric code on their NUES tags. So step one is confirm that that was wrong or changed.

— Reply to this email directly, view it on GitHubhttps://github.com/AAVLD-USAHA-ITStandards/eCVI/issues/74#issuecomment-1068029539, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOLQ7LZW6VJVXXEH4EGXLSTVACKR3ANCNFSM5QWWDA2A. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.**@.>>

SusanCulpDVM commented 2 years ago

@YdaMitzyTorres, as Mike indicated, we could either add states to the list that use state codes (if that has changed or was wrong) or we could go with your proposed pattern or even enumerate all state codes + US. This would be a discussion for the members of the eCVI Data Standards Working Group. Our next working group meeting is scheduled on April 13, 2022 at 11AM Central Time.

SusanCulpDVM commented 2 years ago

@YdaMitzyTorres - historical discussions in GitHub about NUES8 and NUES9 can be found in closed issue #39. https://github.com/AAVLD-USAHA-ITStandards/eCVI/issues/39 This doesn't address your initial question, but does provide some background discussion.

jconlon commented 2 years ago

Do we have a current list of the additional states that use State Codes?

Adding the pattern:

<xs:pattern value="(\d{2}|[A-Z]{2})[A-Z]{3}\d{4}">

would allow erroneous state codes.

rmunger commented 2 years ago

Restricting to "current" states using State Codes would imply that a process would need to be implemented so that if a State started using the State Code format it would need first be added to the pattern. I find that going a little far in restricting what data would be "allowed" in a message. The same could be said for State Numeric values for NUES. There is no restrictions on using the numerals that are not assigned to States, such as 0-9, 17, 20, 36... If the information makes it into a system of record, sharing the information that was received by the accredited vet, and what is on any physical paperwork is probably more important than rejecting something because it was recorded incorrectly. If it is found to be erroneous information then the accredited vet needs to be consulted, not a rejection of the information. VS has used the RegEx pattern below for many years and it has not seemed to be a problem.

I don't understand the concept of having the message enforce business rules that should be enforced in the UI of the originating systems if deemed critical. If a system wants to restrict the capture of NUES IDs that only have the assigned numeric and postal codes that is great.

Randy D. Munger, DVM Mobile Information USDA APHIS VS Strategy & Policy Center For Informatics 2150 Centre Ave. Bldg. B Mail Stop 2E6 Fort Collins, CO 80526 Office 970-494-7339 Mobile 970-217-1432

From: John Conlon @.> Sent: Wednesday, May 4, 2022 9:58 AM To: AAVLD-USAHA-ITStandards/eCVI @.> Cc: Subscribed @.***> Subject: Re: [AAVLD-USAHA-ITStandards/eCVI] NUES9 (and NUES8) regular expression validator does not validate MO, CO and other state codes (Issue #74)

Do we have a current list of the additional states that use State Codes?

Adding the pattern:

would allow erroneous state codes. - Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>> This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
mmcgrath commented 2 years ago

Changing the regex would not require a coding change for us (Trace First) in our systems so we could implement the change immediately.