Doesn't the standard for state-issued LIDs restrict to at least 6 characters? The pattern now allows 4 to 10.

We suggest adding a signature element like <xs:attribute name="Signature" type="xs:base64Binary" use="required"> in the vet node and the origin node.

The schema uses XML date data type. "YYYY-MM-DD" We will need to be sure to document that in the human-readable documentation. It was a pet peeve of mine that the USDA document specified one form in the schema and another in the text.

These get translated to a LargeAnimalGroup with quantity 1 in my translation from the eCVI. This is because our definition of LargeAnimal has Tag and TagNumber required. Not all individual large animals actually require a "tag number."

Proposed solutions:

1. Allow description as alternative to tag number in Large Animal.
2. Make sure LargeAnimalGroup includes the concept of a single animal without official ID tag (or chip).
3. Put horse description as AnimalTag/Number even when listed as "other ID" in source.

First of all I apologize for my lack of participation in the standards development process to date. I had scheduling conflicts for the first couple meetings, then I was out for a couple weeks due to personal issues and I've been playing catch-up for the past week. Thank you for allowing Kaylen to stand in for me in my absence.

One of the conversations that it appears that I missed along the way was a discussion regarding whether to develop an open or a closed standard. Maybe that ship has already sailed so this may be a moot point but I wanted to at least put our position out there on the chance that it may not be to late for consideration.

Specifically I want to discuss the issue of enumerated values ("restriction" definitions in the xsd). GlobalVetLINK is in favor of a more open standard with companion documentation that enumerates "preferred" values.

My assumption is that our desire would be to define a standard that would be as widely adopted in the industry as possible. Thus we want to define a standard that doesn't discourage parties from implementing it. Our experience has been that, while it places more of a burden on us as a company to validate the data that we receive, openness encourages adoption of a standard.

Our experience has been that a closed standard discourages adoption in the following ways:

1. There are cases where we are interested in a senders data even if it isn't 100% compliant with a standard. There may be some sub-set of information that we need and while the whole document may not be 100% compliant it may have all or most of the information we need or are interested in for the given scenario. We would much rather receive the document and have access to the data we want then to turn it away because it isn't 100% compliant and have nothing. In such a scenario we will need to define a different standard just for that scenario thus discouraging adoption of the committee's standard.
2. There will be cases where "UNK" or "OTH" isn't sufficient. If the animal in question is a shark or a snake, that information is useful to us. If the sender has that information but has no way to send it to us, we will again need to define a standard just for that scenario - again discouraging adoption of the committee's standard.
3. There are parties that we have need to exchange information with that have development departments that are less sophisticated than our own. We've found that a closed standard makes it more difficult for us to assist these parties with their development. Schema validators generally return messages that are cryptic in nature and have required us to get more intimately involved in there development efforts than would be necessary otherwise. While a more open standard requires us to do more work initially in terms of message validation, it allows us to provide better feedback to the sender which helps them solve their own development problems. This means there is less need for us to get involved and solve their problems for them. In short, it's more work for us up front, but it pays off in the long run.

I believe I understand the reasons behind the desire for a closed standard, but our practice has been to find other ways to address those issues. I assume that one of the main objectives of having a closed standard is to control the quality of the data. Another possible way to address this goal would be to provide a "test suite" or possibly even a test web site where parties could upload files to determine their level of compliance. An example of this would be the Java programming language. In essence, Java isn't actually a language but rather an open standard. There are several vendors that provide implementations of this standard and there are programs available that will test and report on the level of compliance of each implementation.

Once again, I'm sorry for this late entry into the discussion, and if we are already beyond the point of considering a more open standard then I apologize.

The one part of this standard that almost certainly will need maintenance as we move forward is the lists of terminology, especially those that are more content than "structural".

As an example, I just stumbled upon the fact we don't have AVI in species to allow avian CVIs. While we do almost all of these on NPIP forms instead of traditional CVIs, some do move that way.

I would ask everyone "testing" the standard to be especially careful to look for these terminology issues so they can be discussed and appropriate (but not excessive) amendments made.

The test result uses xs:all to combine the various potential types (integer, string, and float) of result data. This allows any combination of of the types zero or one of each in any order. Is that what we want? I assume this is to allow the kinds of things like a value (numeric) plus units (text) or interpretation (text). Or do we really expect the behavior of xs:choice? To completely model the universe of possible result formats is complicated. It is an entire data model in HL7. The existing solution may, in fact be what we want, but I would like everyone to see how this maps to their implementations.

This may be tied up with my issue about the format of the PremID type. This element is currently required. It would be great if we got PINs or LIDs on all CVIs, but I don't think that can be absolutely required?

Suggestions?

Hi, I'm a software developer for Fort Supply Technologies, and am trying to get my program to export an xml file to match the XSD discussed here. The program collects information that allows vets to fill out an eCVI certificate, and so we've used this certificate as our requirements for collecting data. I've included (hopefully -- I'm new to this site) a screenshot of the pertinent part of the certificate that appears to have diseases that aren't enumerations in the XSD. I would suggest adding these as enumeration values for the ProgramStatusType, listed as:
Johne’s (herd)
NPIP (herd)
Scrapie (herd)
PRV (herd)
PRV (Area)
Trichomoniasis (herd)
EIA (herd)

Or have some kind of "Other" choice that could be definable in the field.

Thanks,
Jason Bingham

The traceablity rule allows lists of animal IDs to be included in the form of an attachment. Because this schema allows attachments do we want to add a DocType of IDList and allow that as part of the data structure?

I think I personally prefer that the sending application process the attached list and include them as Animals.

As we look at the current xsd, a brand inspection is per animal, which is practical if each animal has a different brand, and sometimes, rarely this might be the case. But for the case where the brand is the same on all animals within a group, would it be practical to also have the brand located on an "Animals" node that is a parent node to all the individual animals. We might be able to do this with other elements that are the same too. The practical concern is if 1000 animals are on a CVI and each has the same brand, the way that it currently is that the base64 representation of the brand is against each animal, making a overly bloated file. IF we move it into the Animals above the individual level as an option, it would only be necessary to send the brand once, making the files much more compact.

Not every animal will need testing for anything. Should the Test element in Animal be optional (minOccurs="0" not optional in the sense that a reasonable application would not support it.)

In the field we are not assigning an accession number like a lab would. However, the accession ID is required for any of the test data. We should consider making the accession ID independent of the ID so that in field testing can occur.

Very hidden technical issue:

We will most likely want to change the default namespace for the schema from "StateVet" to something not trademarked by any one member of the subcommittee.

Based on our meeting today in Denver, I propose that the actual inspection date (if known) of the animal also be included as an optional animal attribute. Thx. Nephi

We have lots of places where geopoint is an element, for instance Vet, Destination, etc. The only practical point to collect the geopoint is at the time of the inspection. Should we be muddying up the xdd with geopoint elements where they will not be needed or used?

Specifically how do we map Official Vaccination Tags? Do we make a distinction from other NEUS9 tags? They do have different markings and the information could be useful.

Breed Registration Numbers? Here we get into that issue of the number type vs. the thing carrying the number. Other examples 840 numbers in visual tags, rfid tags, or microchips.

Should we add MIME type to the attributes of AttachmentType?

Most standards that include base 64 content include mime type to allow applications to know what do do with the content. This information can be inferred from DocType, but some uses might find it more straightforward to get the file type directly.

in PurposeOfMovementType all the enumeration values are lower-case and 'other' is included rather than 'OTH'. (I much prefer spelling out the word FWIW). Making the enumerations more consistently styled throughout the document would be a nice touch.

Also where 'other' or 'OTH' is an option should there always be an option for including the other value/ValueOther? Similar to what is available in ProgramStatusType > Value

Quoting from Suzanne's email of 7/10/13:

"We should discuss transmitting the reason the animal is being
moved via standard codes rather than a string as stated
in the USDA document. Something like the list of movement
purpose types represented in FortSupply's XML would be good"

Practically in the field, when collecting data, the vet does not want to spend much time determining the tag type. For instance, NUES8, NUES7, EIN (840 vs non840), etc. While the programs collecting data can have some logic to guess at the tag type, can we add a "other" enumeration to the tag type?

Actually, we see the "OTH" type, but can we change it to "OTHER"?

Also, in the case where multiple ID's are recorded, for instance three on a particular animal, should we provide a label as an attribute for each of the ID's recorded?

There should be a property AnimalCount (integer > 0) on the Animal element. Some CVIs do not have animals enumerated per head - like swine or poultry, where the animals by "groups". Even Bovine CVIs are sometimes filled in on the CVIs as a group and not individually - right, wrong or indifferent.

I have seen GVL animal entries for cattle where
count = 486
Animal ID = 32BBE5001 to 32BBE5486 (486 animals)

How do we plan to map State and Herd disease statuses?
Same question for general statements required.

I didn't notice this until I started translating.

In the AgeType, one of the two allowable formats is for data of birth. It looks like the format specified "[01][0-9]/[0123][0-9]/[12][0-9]{3}" (MM-DD-YYYY) is different from the XML date datatype YYYY-MM-DD.

It would be simpler if all actual dates followed the same format. Just rearrange the regular expression and change the separator character.

This issue is an action item from the Nov 18, 2013 conference. Intent is to help identify who is adopting the eCVI standard as a Producer or a Consumer of eCVI XML documents.

I believe we really need to expand the species list to include at least the full range of USDA three letter codes.

We are working on using the standard to file CVIs in USAHERDS. It is clear that the standard list will never include all the subdivisions that an application might support but it should at least have a parent of any given group. If I remember the discussion correctly, we had planned to revisit this list at some time anyway and just never got to it.

Do we need state of issue on Veterinarian LicenseNumber? Or do we assume the license number included is from the state of in Origin/Address? That should always be the case.

Line 550: <xs:enumeration value="Johne’s (herd)"/>

contains an apostrophe surrounded by invisible characters

It should be a single quote:
<xs:enumeration value="Johne's (herd)"/>

<xs:enumeration value="Johne’s (herd)"/>
contains an apostrophe surrounded by invisible characters
It should be a single quote:
<xs:enumeration value="Johne's (herd)"/>

See also AAVLD-USAHA-ITStandards/eCVI#18

We will need to address the odd CVI that deals with things other than live, born animals. CVIs are routinely used for semen, hatching eggs, etc.

Hatching eggs could have a negative age, I guess! Semen is a little different.

Really, I think a field is needed to call out these things that are not specific living animals. Or, modify our scope to make this out of scope, but that might limit utility.

Should not the Species information be a property of the Animal - not the CVI? This would allow multiple species on the CVI (for those entities that allow it) without having a separate Species enumeration. Will also make it easier to identify/link the animal to the species rather than derive the species from the breed.

If the species on the CVI is needed, it can always be derived from the distinct species on the the Animals.

I was just reviewing our state's cattle movement requirements document and was struck by the phrase "Any exemptions from Official ID must be noted." On paper this is usually written in the ID field itself. That doesn't seem like good data management. Do we want to modify AnimalTag to allow an explicit reason why tags are not recorded when the ADT rule allows them to be left off?

Most would probably be in GroupLot. Do we need to add a field for the note about why these are allowed to move as GroupLot?

Hello All:
We have been working on a test XML creation from our software and have identified the following eCVI fields that we are collecting and printing on the eCVI that currently have no associated tags in the standard. Comment is welcome. Thanks,
Nephi

FIELDS THAT I CAN’T FIND IN THE XSD THAT WE HAVE IN THE MOBILE PROGRAM:
Tests And Results -> Vaccination
Tests And Results -> Treatment-Date, Product and Reason
Legible Copies (Area Tab)
Test Record Numbers (Area Tab)
Herd Flock # (Flock Tab)
Bruc Vac (Animal Tab)
Tube# (animal Tab)
(All CARRIER INFORMATION AT ALL – CARRIER TAB)
Intra-Inter State travel CHB (Carrier)
Carrier Method AIR/RAIL/CAR/Other (Carrier)
Carrier Method Other (Carrier)
Vet Email (Preferences)
Vet Comments (Comments)

Why is this not ID and IDREF so that the schema would enforce it?

Doing some additional mapping attempts, I'm seeing issues with how lab results and accessions are handled. I think the schema we started with--with the ID/IDREF change--is the RIGHT way to do it. But given the information that makes up most eCVIs, I'm not sure having every test required to be linked to an accession is the most practical or efficient design. I'm not saying it isn't, just that we should discuss it.

As systems consume CVIs from different sources there can be certificate number collisions. For these to be treated as unique identifiers, receiving systems need a way to identify the source of the Certificate Number. When these are received directly from the source system, this can be inferred from the source, but if the data are stored, forwarded, etc. the identity of the generating system is lost.

I would suggest adding a Certificate Number Namespace attribute. This would ideally be a universally unique ID such as an OID, or we could just have an agreed upon list that we maintain.

Alternatively, if we could get consensus on a prefix pattern say paper always start with State code, mCVI start with mcvi, eCVI always start with ecvi. This would mean all electronic CVI vendors update their numbering schemes. I don't like this much. Just a thought.

In writing my translator I'm finding that we need to improve the internal documentation in the schema. One example is we should define each of the values in enumerations such as TagType. What is SGFLID? (Scrapie Flock ID? Wouldn't that be SCFLID?) Does N840RFID also include 840 visual tags? (I don't know why that option ever got added or if anyone is foolish enough to use them.)

Most but not all of the schema is fairly self-explanatory, but we should try to make sure no one will misinterpret any of it.

As I understand it, currently age is only reported in months and years. I think we need to allow for the reporting of age in weeks for those animal types (note MMa I didn't say "species :) ) that need age in weeks, such as swine and poultry.

Some users translating from the States eCVI PDF have run into problems with the 200 character limit on the GroupLot description. Are any of the other string lengths causing problems that we need to address?

I like the way ZipCode uses two distinct pattern entries to show the five and nine digit versions. Compare that with the way the AgeType puts them all in one, more complicated, regular expression. For regular expression nerds this is fine. (I've always done them this way, but I'm going to steal the idea from ZipCode from now on.)

Should the number of days the certificate is valid for be calculated from the valid date and expiration date element entries or is this determined by the type of certificate?

Looks like http://www.usaha.org/xmlns/ecvi is no longer available for public usage. I'm using to use https://github.com/tracefirst/usaha_committee/blob/master/ecvi.xsd.

I find it confusing even as much XML as I do that the default value for attributes is optional (use="optional") while the default for elements in required (minOccurs="1")

I notice that in a few places redundant minOccurs="1" and use="optional" designations are included. I think this is good practice for human readability.

All
I've had a couple of queries recently asking about the meaning of the tag types - I will prepare a modification that adds annotations explaining what the short codes mean.

Michael.

Some CVIs include vaccination information (Bruc, TB, Rabies- for small animals):
Type = ex: Brucellosis, TB, Rabies, etc
Date = date of vaccination; optional most probably, if vaccination date is unknown

Should the enumeration of values for SexType include castrated male and spayed female or should there be a "GenderStatus" field for that. Some applications will need to differentiate a steer from a bull, etc. I've seen it argued each way fairly convincingly.

In the code segment below:

<xs:complexType name="AccessionType">
xs:sequence
<xs:element name="Laboratory" minOccurs="1" maxOccurs="1">
xs:complexType
xs:sequence
<xs:element name="LabName" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="PremId" type="PremIdType" minOccurs="0" maxOccurs="1">
xs:annotation
xs:documentationThis is the Premises ID for the Laboratory. If it is an in-field test, then the premises ID of the farm on which the tests were performed should be used./xs:documentation
/xs:annotation
/xs:element

The implication that the PremID should be used for the lab id for in field tests. Many (I dare say most) locations don't have a PremID. If we box ourselves into this restriction, what about the exceptions. We don't need to actually enter any value as minOccurs="0", but comments would be welcome.

In the PhoneNumber simple type the number of digits is 9 instead of 10. This is correct in the Number attribute of the ComplexType PhoneNumType. Just a typo I suspect. However I'm not sure how the redefinition was supposed to work. Number could just be of type PhoneNumber it looks like.

 <xs:attribute name="Number" use="required">
        <xs:simpleType>
            <xs:restriction base="PhoneNumber">
                <xs:pattern value="[0-9]{10}"/>
            </xs:restriction>
        </xs:simpleType>
 </xs:attribute>
 . . .
 <xs:simpleType name="PhoneNumber">
    <xs:annotation>
        <xs:documentation>Must be a 10-digit number without spaces, dashes etc.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
        <xs:length value="10"/>
        <!-- Error in Regex -->
        <!--<xs:pattern value="[0-9]{9}"/> change needed to get 8885551212 to be a valid phone number -->
        <xs:pattern value="[0-9]{10}"/>
    </xs:restriction>
 </xs:simpleType>