Deleted Certificates

[jill816]

Is there a method for dealing with the data for deleted certificates?

[mkm1879]

And is this more a technological question or a real-world one? Once a certificate is out in the wild, what does it mean to delete it?

There is currently nothing in the schema that would serve as a status flag.

[jill816]

On GVL's platform, we currently do not allow modifications to a CVI after it has been signed. If a vet realizes he/she misspelled the name or typed the wrong age, the only way to correct the mistake is to delete the certificate and create a new one with the altered information. Let's say the original certificate is created on 6/25/20. Let's also say that that same cert was deleted and another created on 6/30/20, using new information. It now looks like there are two shipments (with what data was sent). There are no tags to indicate that data is duplicated or deleted or altered. Now that I'm typing this, I'm realizing it relates to my next post about altered CVIs...please read that too so that we can discuss this at our July 9th meeting.

[mkm1879]

Ah, that is something I think we could support. Perhaps an optional attribute "ReplacesCVINumber" that would normally be absent but could be populated in the replacement scenario you raise. I'm not sure how that would work for deleted.

[ryanscholzdvm]

I think that the "ReplacesCVINumber" could be beneficial in the scenarios that many systems have where a "revision" is allowed after the CVI has been signed. In many cases, the original CVI has already been sent to the origin/destination states, and an attribute that allows the system to explicitly specify that the new revision is replacing the old one would be very helpful (rather than relying solely on document numbering or other conventions to imply a connection)

[SusanCulp]

I think that in reality there is a need for a void and a revision.

Void - example - DVM inspects a horse scheduled to travel in 5 days. After issuance of the CVI, the horse does not in fact travel. If it was scheduled to attend an event and the event had a disease outbreak, it would be best to have voided that CVI so it doesn't appear that the movement actually occurred.

Revision - animals move after hours and an after hours permit number is obtained. The next day, the after hours permit is replaced with the real permit number. It would be nice to be able to revise that issued CVI for that animal and that animal movement with a revised CVI that has the same number but some indicator that the revised CVI is the actual movement document, not the first issued CVI for the same animal and same animal movement.

[StaceySchwabenlander]

I like the idea discussed during this week's meeting. Have a CVI number field that stays static so 'duplicates' (void or revised CVIs) can be found and that same number would be on all 'versions' of that given CVI. Then we add an additional/supplemental field to note that the CVI has been voided or revised. That supplemental field would then be unique to each 'version'. I imagine it would need to be an alphanumeric field. Would we need to define the maximum number of characters allowable?

[SusanCulp]

@ryanscholzdvm @mkm1879, so a void is a form of revision - ie the originally issued cvi gets revised and retransmitted as a voided revision? an optional attribute indicating that it has been voided?

[ryanscholzdvm]

@SusanCulp That is how I would interpret this, but I think that is probably something that needs to be elaborated on a bit. Retransmitting the entire document with a voided attribute set to true could lead to some extra data being stored in our systems, but at the same time, I don't know that there is really a good way without creating an entirely new standard to be able to transmit the fact that a document has been voided.

[mkm1879]

In Jan 2021 release v2.3