Deprecating Lot Number Text

This is a process that was started at the CPM quarter at the San Antonio WGM January 2012 to explore how to manage the recording of "lot numbers" correctly, without using the lotNumberText attribute - which is noted in the CPM as being deprecated.

It was agreed that to record lot number text, using the id attribute with an II with a globally unique identifier is preferred.

Please feel free to make comments (and corrections) to the content below.

In CPM there is representation of an instance of a product, using R_ProductInstance (POCP_RM020100UV). The text for the instance says: A product instance is (a) an individual product instance, i.e., an individually identified thing with a serial number; (b) a product lot, i.e., a set of things of the same kind (e.g., 1000 for expressing a number of tablets) or an amorphous mass (e.g., 100 L of a liquid raw material), or (c) any subset, member, or portion of a product lot. The distinction between an individual thing and a lot is made in the quantity attribute, which is set to 1 (one) for individual items, or any number e.g., 1000 or amount 100 L for sets of things or amorphous masses respectively.

The entity that represents the product instance has the attribute lotNumberText, but this has the following design comments: <<DEPRECATED: The lot number for this instance. It identifies an amount of the product that has been produced or otherwise processed together. This attribute should NOT be used any more, as a product lot is represented as an instance of itself, and the individual (serialized) items, or sub-portions of the lot are represented as "members" of the lot instance.>>

Business Requirements

Lot numbers (aka batch numbers) are supposed to work for identification in some way.

The main business requirement is to be able to describe the lot number of an instance of a product - for example when a particular instance has caused an adverse reaction. This is the product instance as in example a) above, but with the proviso that not every type of product has an individual serial number/lot number/batch number. Many devices - and particularly implantable devices - will have an individual instance serial number which can be correctly described iin the id attribute using a root OID and extension - an perhaps also with a reliability identifier also. But for those products that do not have an individual instance serial number but which do have a lot or batch number (medicines, mass-produced devices such as syringes etc.) how should the id attribute and the II datatype be used to describe this information? In Lot Distribution Reporting – tracking each lot through the distribution chain –unique lot identifiers are required because a database must contain a unique record of each lot which is thereby unambiguously identified.

The following are the scenarios to be managed:

1) Products that have a globally unique lot/batch number, with a root and an extension, which is, as part of the general clincial process, always recorded - such as implantable devices.

2) Products that do have a globally unique lot/batch number, with a root and an extension, but where that information - particularly the root - is not generally known by the data enterer. Some devices and medicinal products may fall into this scenario.

3) Products that do not currently do not have a globally unique lot/batch number

Using the II (Instance Identifier) Datatype

The Instance Identifier (II) datatype is made up of several parts - the most important from this perspective being the ROOT and the EXTENSION; the reliability indicator may have some business value. The root part contains a unique identifier that guarantees the global uniqueness of the instance identifier. There are cases where the root alone may be the entire instance identifier. The root is essentially the "namespace" of the identifier given in the extension and is itself identified by a UID - a Unique Identifier String. There are a couple of different types of UID in use currently - ISO Object Identifiers (OIDs) and DCE Universally Unique Identifiers (UUID). The extension part is a character string that serves as a unique identifier within the scope of the identifier root. So it is the root + the extension that give the global uniqueness.

For those products which have a globally unique lot/batch number, with a root and an extension, such as implantable devices, the II mechanism works well and the relevant data can be correctly present in the id attribute for the entity.

But for medicinal products and other products, lot numbers and batch numbers are not currently globally unique, and currently few if any lot/batch numbers have any UID associated with them. It may be that there will never be a globally unique lot number system (for medicines). But lot numbers can be made unique and meaningful when the product item code is known as well. Here, "product item code" is a GS1 GTIN or NDC code, or an MPID i.e., a code identifying the product kind (as opposed to product instance).

PROPOSAL:

To produce a globally unique identifier for a medicinal product, you must concatenate:

1. a root
2. the product item code
3. the lot number 

Have a fixed II root, say "1.2.3.9999.4" (it's just one constant prefix for the US FDA lot tracking). Then concatenate the NDC code without dashes or leading zeroes (e.g., 0002-4321-89 becomes 2432198) to give 1.2.3.9999.4.2432189 and this becomes the root of the II for the product. The lot number goes into extension to make <id root="1.2.3.9999.4.2432189" extension="A024"/>

This root OID is therefore definitely not a "dummy root"; it is a functional root that has identification value and that can be produced by any product manufacturer and it is always a proper well defined root OID designating an identifier system.

It is important that everyone/anyone must be able to produce the root. The user entering lot number information for a product (for example in an adverse drug reaction report) can look at the product package, see the product code (NDC code) and enters that in to the system, then the user adds the lot number into its own field. Alternatively the system itself may populate the product code part (since it will have identified the medicinal product). The system itself will populate the fixed II root, and hence a full II is generated:

NDC: 0002-4321-89 Lot#: A023 Root (fixed): 1.2.3.9999.4

<id root="1.2.3.9999.4.2432189" extension="A024"/>

There may be variations on the tune of how to construct the OID. For instance, with NDC it would be possible to make 3 more steps on the OID at the point of the dashes (which would work with GTINs too):

<id root="1.2.3.9999.4.2.4321.89" extension="A024"/>

This has some advantages, because a fill-lot number will disregard the packaging, so for a fill lot we would need just:

<id root="1.2.3.9999.4.2.4321" extension="A024"/>

For other realms: If some country has their alpha-numeric product item code system, the alpha characters cannot be put into the root, so they must be pushed through to the extension:

Item Code: _AB-99X/2_ Lot#: _A023_

would make:

<id root="1.2.3.9999.8.7" extension="AB-99X/2#A024"/>

In this case the fixed root is 1.2.3.9999.8.7 and the item code and lot number are concatenated into the extension.

It is also possible to use this approach in cases when the product code is unknown, by having an OID with the explicit meaning of "lot number of product whose item code is unspecified". Even if 10 agencies pool their adverse event data and have not previously agreed to use a single OID, it is still better to have 10 OIDs with the meaning of "lot number of product whose item code is unspecified" than to have nothing.

Selected Commentary from the List

Jean-Henri: I agree with Gunther's proposal. I've had numerous cases where I have a set of IDs as he describes - where the "child" ID is only unique within the namespace of the parent ID. And the solutions I fell back on was exactly as he described - create a new OID by taking the parent ID OID, concatenating the parent ID onto it and then use the child ID as the extension. Or the equally valid way of concatenating the parent ID and the child ID (which I tend to use more often than the former).

Lloyd and Gunther: The "concatenate id to OID" approach only works if the id is numeric and doesn't have significant leading zeros. The concatenate extension works so long as there is a separator character that has no risk of appearing in the concatenated id. Note that if you use the concatenated id, the OID root should be distinct from the root for the parent id. (It's a distinct namespace.)

Lise and Bill (summarised): If the II attribute is mandatory (as in the diagram above) how should situations where no lot number is known be managed? These include literature reports etc. where lot number will remain permanently unknown. Also, this must handle the use case where information can flip-flop, i.e., follow-up information could provide previously missing lot number(s) or a response could nullify info previously thought to be correct and appropriate. 'Things' change over time.

Null flavors

Using a nullFlavor (an unrooted identifier) does not do much to help with that identification other than to allow a text string to be used in an attribute that requires an II datatype. Using a "dummy root" also does not provide any value to the identification process.

However, it is possible to send an II with an extension and no root. However, if this is done, it *must* specify a null flavor (even if it's NI). An II with no root is, by definition, null. In most situations, the proper null flavor is UNC - unencoded. This reflects the fact that there probably is a unique OID or UUID root out there. The sender just hasn't gone through the effort of finding/creating it and therefore the id isn't fully "encoded". Note that this null flavor applies to the entire id, not the root property. This also means that if an id attribute is mandatory in a design or template, that id attribute *must* have a root property. Implementations can be allowed to do this, but it is not recommended.

OUTSTANDING ISSUES:

1) The id attribute is currently shown as mandatory. In order to meet Lise/Bill's use case (lot number permanently unknown for a product instance in an ADR report) and Tom's statement that "the id of this entity should be at least required in implementations where the lot number needs to be supported (will remain optional in the UV model)", this will need to change. Is that acceptable? If so, that should be actioned.

21Mar12: Feedback from Pharmacy via Tom dJ: After some discussion, we agree. In the UV model, it should be optional. Specific restrictions (like SPL, Pharmacy CMETs, but also localizations) can then decide whether their business cases require support for an ID (making conformance required) or even a mandatory identifier

2) Are all agreed that lotNumberText can be removed from the CPM, if all the above is captured, including the example mechanism for root OID creation, in CPM documentation?

21Mar12: Feedback from Pharmacy via Tom dJ: Yes

3) Tom commented that: "sending a batch or lot ID would work by adding a 'part of' participation to a parent 'manufactured material' class, since the ID is *not* an instance identifier of the medicine (or other product) instance, but of the batch or lot that it was a part of". No one has picked up on this? Is it right that there are two alternative approaches?

21Mar12: Feedback from Pharmacy via Tom dJ: There is really only one approach. If you have an instance that represents the item being administered, then its ID should identify individual administered items (e.g. pill). A lot number however, is an identifier for the batch this item was a part of. So semantically, this should be handled by using the ID attribute of a class that has a PartOf relationship with the individual item instances. This position is semantically sound, but I realize it might seem complicated. We need to check if the PartOf relationship is covered by the CPM (I’m sure it is) and describe the method in a guideline.