Needing to comply with EU FMD? Don't miss this critical GS1 Guidance on the proper use of NTINs in EPCIS

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.