Could the "Good ID" be better - II?

The September 25th blog entry, 'Could the "Good ID" be better?', looked at what this blogger considered weaknesses in the way the GUDID is proposed to be set up... Here are some additional observations regarding  the various packaging and unit of measure-related fields in the GUDID:

• The proposed draft guidance for the "Good ID" 'Package Type' field has the following rules: Description: "Text to describe the outer packaging of the product and enable users to understand higher level packaging configurations," Data Entry Notes: "Free Text," and Data Type & Length: "Alphanumeric, 20."  Is free text a good idea? No, what would greatly preferable would be the use of existing ANSI X12 standards... Rather than free text, all unit-of-measure fields should be 'Choose a value from the drop down' which would only offer ANSI X-12 Allowable Units of Measure and Codes. The entry would be the code and, if necessary, an additional 'Package Type Description' field that defaults could be added (for anyone e.g. patients) that might not know EA, BX, CT, CA, etc.






• The Primary DI level, which is for the base package, or "... lowest level of a medical device containing a full UDI..." has a Device Count field, but does not appear to have a Base Package Type field. Thus in the example syringe above we see 'Base Package Primary DI: 0084838035683' which corresponds to 'Oral/Enteral syringe, 60ml' with 'Device Count of 1.' Given the emphasis on base package in the assignment of the Primary DI, its role in defining the Device Count, etc. it would seem very useful to have a specific and separate defined Base Package Type field. In the syringe example, with a Device Count of 1 the Base Package Type value would be EA... In the blood collection tubes example with a Device Count of 100, the Base Package Type field value would be BX. In the database logic could be applied so that if EA is picked at the Base Package Type then the Device Count defaults to 1 and does not allow a change; while if any other ANSI X-12 UOM value is picked the Device Count field becomes user-defined.


• Related to and building on the above, the addition of a Base Package Type would also include logic so that a different packaging configuration with a Package DI could not reference a Package Type identical to the Base Package Type to avoid potential confusion.... For example, looking at example 3 on page 29 of the draft guidance. Here we have a Primary DI for a box of gloves... These are not individually wrapped and labeled and so the manufacturer will have a Primary DI for a box of 100 of these glove (and thus a corresponding Device Count of 100). The manufacturer also apparently sells its Primary DI Base Package in sets of 4, resulting in a  Package DI for that configuration i.e. a unit that contains 4 boxes of gloves, with each box containing 100 gloves. However, the lack of a Base Package Type in this case allows for an entry that shows this unit's Package Type to be Box. So, a Box of gloves that consists of four Boxes of gloves... Clearly an issue, since you shouldn't ever have 'larger' sale units of measure having their Package Type defined as the same (or lower) than the 'smaller' units of measure! A configuration like this (Stock/Standard UOM = BX, Purchase Unit of Measure = BX, Conversion Factor of 4) usually wouldn't be acceptable to a provider's ERP system... With a Base Package Type field and logic that prevents a Package DI from having a Package Type equal to the Base Package Type the unit-of-measure element of the database would be improved.

The bottom line? The "Good ID" should add a defined, separate Base Package Type field with the corresponding logic as detailed above, AND all fields that reference a unit of measure (Base Package Type, Package Type) should utilize ANSI X-12 defined values.

Previous related blog entries:

Could the "Good ID" be better? - Sept 25th, 2013

Additional brief GUDID observations: a) The clinically relevant size fields (Size Type, Size Value, Size Unit of Measure, and Size Type Text) appear to only consider length and total volume (the only values that appear to be able to be chosen from the Size Unit Of Measure field's drop-down). Often other, more important clinical sizes are included on the item label, for example an item often will have a defined length, but then also a specific french (gauge) size, and possibly a needle with its corresponding length and gauge as well.... b) It is unclear if the Storage and Handling fields (driven by the Storage and Handling Type selection from a drop-down list) allows only one set of requirements, or if more than one can be added (e.g. in the case that the item had both temperature and humidity handling or storage requirements).