OTHER Abuse

[mkm1879]

I've just received a complaint about a specific eCVI but I suspect this is fairly generic so I won't name names. Where we allow Other and a free text field, users are typing a value from the list into the free text of Other. This causes databases to misclassify the CVI. The product mentioned actually prioritizes previously typed Other values over the standard values.

I am going to see if I can find a schema language or regular expression that can say essentially "Anything not in the list above" to use as the values allowed in the free text box.

Any other ideas for how we can discourage abuse of Other? We see this I know in Purpose and ID Type but probably elsewhere.

[StaceySchwabenlander]

I can see how this would be a concern. A MN example - If an eCVI's XML file is sent with information in the 'Other' field that is required in a different field, such as 'Sex' - and if that results in the 'Sex' field causing the XML to not validate because of this, this would prohibit our CVI processing software from accepting any of the XML at all. This is a huge frustration for our office. We need to make any attempt we can to minimize XML not validating due to user mistakes (so much as we can).

[jconlon]

Related to #70

[SusanCulpDVM]

@mkm1879 - I like your suggestion: "I am going to see if I can find a schema language or regular expression that can say essentially "Anything not in the list above" to use as the values allowed in the free text box." @StaceySchwabenlander do you think the suggestion above will help with this?

[mkm1879]

Beware that there are different varieties of regular expressions. The ones supported by XPath for XML validation are somewhat limited. No look ahead negation, etc. That stumped me.

[mmcgrath]

I think it is better to encourage eCVI vendors to "do the right thing" by appraising them of the ramifications of this behavior as @StaceySchwabenlander pointed out in her comment above

I agree with @mkm1879 and think that the complexity of the technical solution to this isn't worth the headaches for users of the XML standard.

[mkm1879]

On the USAHERDS Technical Committee just now, it was suggested that removing the description fields that go with OTHER might help by making it more obvious to vendors that by entering "other" vets aren't providing useful information. One vendor in particular defaults to the most recent value used and so once a vet has picked "other" and typed a value that choice comes BEFORE the equivalent enumerated value.

[StaceySchwabenlander]

I agree @mkm1879 - This seems like it may be a valid solution. If there is no place to capture both the 'Other' choice and the additional information captured in the description field within a receiving system in a way that adds value, perhaps it is best to just discontinue to the availability of those description fields.

If the description fields were not an option, veterinarians may be more willing to utilize available options instead of 'other' when they are offered in the list. E.g. 'Personal Travel/Transit' is an option, but 'Vacation' is not. Instead of 'Other' and 'Vacation' perhaps without the description fields the veterinarian will choose the available option of 'Personal Travel/Transit'.

[Jodi-USDA]

I just have a few questions. Are there statistics/estimates on the "other" categories? What % of the time is the Other option selected? Among descriptions what % of the time can the actual description be mapped to an existing option? Are there specific "culpits" that can be identified and trained? Would the decision/action taken by this committee be different if the answer to these questions were: 85% and 90%, vs 3% and 2%? and if it were < 10 common offenders vs 300 random offenders? Also, how much value added does "other" contribute to the information collected vs the more descriptive options? If the change was made to exclude descriptions and the person's vacation was not mapped to Personal travel, is that a big deal? If they instead still put "other" with no description would that be a problem?

[Jodi-USDA]

Let me add a little more context to my questions. My former job involved developing electronic questionnaires. Clients always had "other, please specify" options to their questions. I also was the statistician who analyzed the data, and often they either never looked at the specify texts or spent hours /days recategorizing. In then end, neither option was ideal. Instead we came up with a cutoff, like "we want to try to get 90% of our responses to be one of the preset options, and then the rest can be lumped in other and we are not concerned about the details/descriptions". So they did pilot tests of the questions to get the list of specify values, and created categories. Sometimes the categories were vague like "other-travel related, other- not travel related, and none of the above". But at least it meant that 90% of their responses conformed to known options and 10% were none of the above which was also a preset option. I realize that eCVIs are different.., but I am wondering if the % of responses that use the other category is important for the CVIs

[SusanCulpDVM]

This issue was discussed at the November 30, 2022 meeting of the eCVI Data Standards Workgroup. Since this is outside of the scope of this Workgroup, the consensus was to close this issue and refer it to the NASAHO eCVI Approval Committee.