Amended Certificates

[jill816]

How does the standard deal with amended CVIs? Is this something the committee needs to look at?

[SusanCulp]

I'll copy and paste my comment to Issue #51 here.

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.

[jconlon]

The schema is a static state model. If after initial instantiation changes are made to the schema instance, they need to be recorded with a timestamp and notation of the attribute that changed and what it changed from and who changed it.

Some systems are doing this with nethooks at the system level managing the schema instances as they are changed. But if the schema instance document needs to record these changes a revisions element with referencing the changes, when they happened will have to modeled in the schema.

[mkm1879]

I'm not sure if you are addressing changes to the schema or the revision certificate.

The "revision" certificates would each have its own IssueDate when the revision is signed.
Schema versions are tracked by release date with the individual changes noted in comments and commit messages.

[jconlon]

I was referring to the 'revision certificate' or a certificate that was revised/amended/voided. In reviewing both this and #52 I see that your idea of an optional attribute "ReplacesCVINumber" for a second CVI would solve this problem without needing to add the kind of 'change logging' with timestamps and all that complication to the CVI that I mentioned. Issuing a new one that refers to the original is a nice and simple fix. (That is unless I am missing some edge cases ??)

[mkm1879]

But you are correct from the perspective of the receiving system. Ideally, it will retain the revised/amended/voided certificate data but exclude it from counts, analysis, display, etc., other than in the context of audit logging. It does add a level of complexity.

[jconlon]

Don't know if this creates a problem or not - while the newer revised/amended or voided certificates reference the old certificate, one cannot definitely know from a single certificate if it was revised/amended or voided without having received the subsequent certificates. There may even be more than two certificates issued for the same inspection.

[StaceySchwabenlander]

(Comments also captured in Issue #51 ) 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?

[mkm1879]

Thach Winslow has a neat idea about these. Any scheme for revisions or voids will have to have some indication on the "printed" copy of where to look for any revisions or voids. You can do cool things electronically that you couldn't with paper.

[dlkdvmphd]

My main thought is that we need to force these revisions to be within 10 days of inspection date. Dating will be an important component as discussed in August call. Agree with Dr. Stacy Schwabenlander comment above.

[mkm1879]

I agree with the 10 day limit but don't know of a way, using schema language, to enforce that.

[ryanscholzdvm]

Being that the 10 (or 30 day with approved heard health plan) limit is really a functional thing that would need to be applied by the CVI vendor application, I wonder if the limit would be better implemented by the NASAHO eCVI vendor approval committee? There is a list of policy-type requirements that each vendor is evaluated by, and this could probably be included in the next revision of that requirements document. This may also be the place to specify how a revision or void is indicated on the PDF document.

[StaceySchwabenlander]

Good thought @ryanscholzdvm - I was just thinking that vendors should all be intimately familiar with all requirements in 9CFR related to CVI issuance if they are CVI vendors. It seems this would be something pretty straight forward to implement by each vendor (kind of surprising that it isn't already, really). All CVIs should be required to be issued within 10 days of the inspection date, unless there is a clear way to indicate a reg health maintenance plan exists - in which case, if that is clearly indicated by an available field, the issue date could be up to 30 days from inspection. Though CVI vendors are not regulatory authorities as animal health officials are, they still have to follow the law and if they are offering a service to accredited veterinarians, helping to ensure their platform is compliant with federal rules seems something any veterinarian using their system would likely expect.

The issue for this committee then would be - does there need to be a field (yes/no) that can be used to capture/indicate the accredited vet has established a 'regular health maintenance program' as defined in 9CFR1, 160.1, 161.4(a)?

I will add this as a possible topic/consideration for the next iteration of the eCVI standards (maintained be a subcommittee under the NA, not this subcommittee under USAHA).

[VSsrydberg]

Stacey, we built the 10 and 30 day logic into VetSentry. We also allow multiple revisions by incrementing the last digit in the CVI number by one digit, so the largest last digit is always the most current. All revisions are reported via xml.

[mkm1879]

In Jan 2021 release v2.3