Recently I highlighted
an important GS1 guidance which aimed to correct a common
misuse of GLN/SGLNs in EPCIS events. Next in our series is another
GS1 guidance focusing on the proper encoding of NTINs in EPCIS events.
The full position paper can be found here.
As a general note, GS1 authors numerous position papers which are immensely helpful yet unfortunately often don't get the visibility/attention they deserve. Check out the full set of position papers to ensure your implementations are in line with GS1 standards.
What is the root
issue? NTINs (National Trade
Identification Number) are product identifiers which are the result of country
or market specific identifiers being incorporated into GS1's GTIN
construct. The NTIN concept is certainly not new but has seen increased
significance given its broad use across Europe and thus its key role in
ensuring compliance with EU FMD regulations.
While there is a significant push to have companies transition from the use of NTINs to GTINs in any market where it is allowed, the purpose of GS1's
latest position paper is to ensure in scenarios where NTINs must be used they are encoded correctly when
populated in EPCIS events. This is a critical concept as EPCIS is the de
facto standard used to transfer serialization/traceability information between
packaging sites/CMOs and MAHs- which in turn is the
foundation for the regulatory required notifications to the EMVS (a.k.a EU Hub system).
While NTINs do inherit some attributes of its GTIN counterpart- such as ensured global uniqueness- NTINs have one significant difference in their makeup. Unlike GTINs, NTINs do not incorporate a GS1 Company prefix. Most serialization software solutions depend on the GS1 company prefix to properly convert GTINs from their 'human readable' format, such as you would see printed next to a barcode, to its equivalent (GTIN+SN) SGTIN 'URN' format which is required when populating in EPCIS. Thus, NTINs not having an explicit GS1 company prefix makes it problematic for software solutions when then trying to encode the NTIN+SN into the standard SGTIN URN format.
What ambiguity does the position paper clear up? Most importantly the position paper clearly states that NTINs are to be encoded as GS1 SGTINs when populated in EPCIS events and more specifically "an NTIN must be encoded as a 'one-off' GTIN with a GCP length of 12 digits". The position paper also provides clear instruction as to how to convert an NTIN+SN into the SGTIN URN format.
 |
| Source: GS1- Guidance on using NTIN in EPCIS visibility events |
How can I determine if
my implementation is following GS1's guidance? Watch for these key indicators that your
implementation may NOT be meeting this GS1 guidance:
- Any reference or mention by your vendor to the concept of
an 'SNTIN'. SNTIN is a fictional term because, as the position
paper notes, an NTIN in serialized form takes on the construct of a
standard SGTIN.
- EPC values which use prefixes such as
'urn:epc:id:ntin:...' or 'urn:epc:id:sntin:...' are not compliant.
GS1 does not sanction any prefix under its namespace that includes 'ntin' or 'sntin'.
- A lack of GS1 Company prefix configuration in your
serialization solution. Serialization solutions must allow for
configuration of known or valid GS1 company prefixes in order to properly
translate between an NTIN/GTIN +SN human readable format and its
corresponding SGTIN URN format. Without a GS1 Company prefix
configuration solutions will force users to duplicate its GTIN/NTIN entry
in both human readable and URN formats. This adds significant
overhead to master data management/configuration as well as an increased
quality risk that the entered human readable and URN formats do not
properly correlate.
When made
aware of GS1's position paper this week one top pharma indicated (in regards to
feedback provided from their serialization solution provider) that "everything we’ve been told previously goes against
this." This is
concerning feedback as it indicates many companies are already down the path of
mishandling NTINs encoded in their EPCIS integrations.
As noted in prior posts, when non-compliant practices become
widespread the greatest consequences ultimately fall back on the industry
itself in the form of additional time/effort/cost. By not enforcing Standards compliance, serialization solutions have to adapt to support both the compliant and non-compliant approaches- and this comes at the expense of the industry (e.g. customers) who end up having to pay for new integration 'maps' or platform 'enhancements' to the same solution providers who incorrectly handled NTINs in the first place.
As before the message to the industry is simple-
increase the oversight of your implementations and leverage the wealth of
readily-accessible, free content available to you. Leaving your implementations
unchecked will result in highly customized and/or non-compliant partner
integrations costing you more money in the long run.
