Revised and Voided Clarification

[TF-Mhelt]

Issue 51 Deleted Certificates and Issue 52 Ammended Certificates

Added ReplacesCviNumber and Voided the to XML schema.

<xs:attribute name="ReplacesCviNumber" type="nonNullString" use="optional"/>
<xs:attribute name="Voided" type="xs:boolean" default="false" use="optional">
      <xs:annotation>
            <xs:documentation>True indicates that the CVI named in ReplacesCviNumber has been revoked.
                              Voided certificates must include a copy of the human-readable--PDF, etc--
                              version of the certificate clearly marked as void.</xs:documentation>
      </xs:annotation>
</xs:attribute>

There seems some ambiguity on how this should be implemented. It seems to me ReplacesCviNumber should be used for amended CVIs and Voided for voided CVIs. But the documentation has Voided being used with ReplacesCviNumber.

Amended CVIs: There is a discussion about static vs incremental CVI numbers in #52 that I think was left unaddressed.

Would an amended CVI XML look like?

CVI number: CVI Number of the CVI being amended ReplacesCviNumber: CVI Number of the CVI being amended

or

CVI number: New CVI number ReplacesCviNumber: CVI Number of the CVI being amended

I think we would have to use a new CVI number for revised CVIs as the schema doesn't have a revision number.

Voided CVIs Would a voided CVI XML look like?

Cvi Number: CVI number of CVI being voided Voided: True ReplacesCviNumber: CVI number of CVI being voided

or

Cvi Number: New CVI number Voided: True ReplacesCviNumber: CVI number of CVI being voided

or

Cvi Number: CVI number of CVI being voided Voided: True

The last option makes the most sense to me as there is no new CVI being created or amended just the voiding of the original CVI.

[mkm1879]

A truth table added to the documentation element would go a long way to clearing this up.

[TF-Mhelt]

Seemed the general consensus was similar to:

Voided CVI: CVI Number: {Original CVI Number}-Void Voided: True Replaces CVI Number: Original CVI Number

Revised CVI: CVI Number: {Original CVI Number}-Amended Replaces CVI Number: Original CVI Number

[MichaelJRussell]

I created a Pull Request with suggested updates to the documentation around this: https://github.com/AAVLD-USAHA-ITStandards/eCVI/pull/66

My key takeaways from our conversation on Monday were:

• Communicating that a CVI is voided and that a CVI is amended/revised should be two separate operations (not sure we're all in agreement on this point)
• Voided, if present and set to true, indicates that this CVI void/invalid/revoked
• ReplacesCviNumber, if present (must be not empty), communicates to the receiver that this CVI is meant to replace the referenced CVI, and the referenced CVI is void/invalid

I believe that each attribute standing on its own succeeds in clearly communicating what it's meant to, and combining the two just complicates that message.

Edit: Wanted to acknowledge @ryanscholzdvm; @SusanCulp shared his thoughts on this topic which contributed heavily to this.

[SusanCulpDVM]

Thank you @TF-Mhelt and @MichaelJRussell for your work on this. We can discuss this issue today on our call to see if there is any additional feedback from committee members.

[StaceySchwabenlander]

I have a question on this aspect of the schema. My apologies if this is apparent to those more tech literate in the group.

• I understand that some (not all) eCVI platforms allow a CVI to be voided and I understand the schema outlines how this should work.

• I further understand that some (not all) eCVI platforms allow a CVI to be revised in the event a mistake is made and the veterinarian can re-issue the CVI using the original CVI they drafted and the 'ReplacesCVINumber' option above so issuing vets and SAHOs can track revised CVIs.

• Additionally, I understand no eCVI platform is required to allow CVIs to be void or re-issued, but if they do, they follow the schema on how to allow for these actions.

I believe the schema allows for a CVI to be voided and then a new CVI issued to correct a mistake. I.e. the schema doesn't dictate that when a CVI mistake occurs, the CVI must be revised, not voided with a new document issued. Revising would maintain the ability to track the original CVI number, whereas if the user would void and then issue a new CVI, the connection is lost between CVIs representing same animal(s) inspected. Question: either process is acceptable under the schema, correct?

[mkm1879]

I think Dr. Scholtz explained it best. What we need to be able to do is at least equal the best of the paper world. What we actually do when we revise a CVI is note that the first signed version was invalid for some reason and then issue a new one. Even if we do this in a way that looks like we just changed it electronically, that process must flow. So it actually takes two documents to revise one. (Computers are patient, they won't mind.) Keeping all that straight by using the common convention of retaining the CVI number and adding a "R" or "R1", etc. is icing on the cake. I think I got his logic right.

[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.