Hello Kat,
Even with many guidance documents, information from GS1, best practices, there can still exist some ambiguity on what could or should actually be done for assignment of numbers. First remember GTIN is specific to GS1 which is a combination of the company prefix number and the Device Identifier (DI). The DI portion is crux of your situation because when you have a new model or version a new DI number would/should be assigned. Second always remember the UDI number is from the perspective of the user in order for them to have full traceability, identity, and true identity of a product. Therefore when making changes to a device, always look at the perspective of the user if Revision A and Revision B are in fact different products.
As a simple example, if the packaging of the device is changed from Version A as a unit of 10 with blue swirly colours to Version B as a unit of 5 with orange triangles, from a user these are different. It is simple example, but Version A and Version B are different to the user, so there should be different DI numbers (which would be different GTIN numbers). If they needed to contact the company Version A is "different" from Version B so when looking up the UDI number it should clearly indicate which version the user has in their hands.
Before looking at your examples, also note the part numbers, catalogue number, product code (number), or SKU for your products can be independent of the UDI. If you make a change to the product the part numbers, catalogue number, etc., can stay the same, but maybe there would be a new UDI number from Lot Number 130 and above. Internally you could link different DI numbers over time to the same catalogue number in an internal database. This way your customers would still be ordering part number 13X893 which internal would have a revision A, B, C, etc. Then depending on the lots made over time the UDI number might adjust so 2015 - 2018 DI number is X, 2019 - present DI number if Y.
Looking at your Example 1, indeed there should be a new DI assigned because Version A without a Mark compared to Version B with a Mark from a packaging perspective would be viewed differently. For me, it is a bit of a stretch to assign a new DI, but the look of the device would be different with a certification mark. Plus I would argue if applying a CE Mark this would have no relevance on the U.S. UDI assignment except for the packaging and labelling being different. However, as noted if you are selling catalogue #Abc123 - why would you have to change that? Internally, #Abc123 would be revision A non-CE Mark and revision B CE Mark, but the catalogue #Abc123 would still be the same.
Example 2 is even more of a stretch to assign a new DI because the actual product is not changing except maybe you are adding a new symbol on the labelling of the device. If the labelling is changing, take a view from the customer looking directly at the package/label would be different, but I would also argue this does not impact the identity or traceability of the device by adding a symbol. Again look at it from the perspective of the customer, if they have product in 2019 with UDI 1234 non-MRI compatible to the another product in 2020 with UDI 1234 MRI compatible - does this really impact the UDI number - more importantly does it impact the traceability of the product? Also again, the catalogue number can stay the same.
Utilise your quality management system to manage the UDI aspects including when and what would require changes to the DI number. In your document change control process document the reasons and justification from a risk perspective whether a new DI number would be assigned or not assigned; then clearly document this decision. Hopefully you can structure your UDI processes to accommodate having versions internally identified, but your customer is still ordering part number #Abc123 and the UDI number is available for them from a traceability perspective if there is identity concerns or issues with the quality of the product.
Oh, additional edit - concerning software definitely utilise an internal process and procedures to manage this. Software goes through many versions and clearly in your software change control system need to identify when a new DI would be assigned because from the user perspective Version 2.0 and Version 3.0 are indeed different, whereas Version 2.1 to Version 2.2 is not.
------------------------------
Richard Vincins RAC
Vice President Global Regulatory Affairs
------------------------------
Original Message:
Sent: 14-Sep-2020 16:30
From: Ted Heise
Subject: Med Device GTIN Changes vs. Product Code Changes
Dan, you made me curious. I've always said "Pro Code" too, so I went on a little search.
First source I checked was my beloved "Classification Names for Medical Devices and In Vitro Diagnostic Products," obtained from a DSMA training conference back in 1995 or thereabouts[1]. Though I thought it used such terminology, I was wrong.
Finding that, I did some web searching. Though I seem to recall FDA staff using the term, the only place I can quickly find its documented use is in 510(k) summaries prepared by industry. Today I think it's deprecated.
[1] I still use this book, because sometimes browsing it seems more effective than the online database (though I like it a lot too).
Best regards,
Ted
--
Theodore (Ted) Heise, PHD, RAC
Vice President Regulatory and Clinical Services
MED Institute Inc.
1330 Win Hentschel Blvd.
West Lafayette, IN 47906-4149 USA
765.463.1633 ext. 4444
http://medinstitute.com
theise@medinstitute.com
Original Message:
Sent: 9/14/2020 3:25:00 PM
From: Dan O'Leary
Subject: RE: Med Device GTIN Changes vs. Product Code Changes
This is a fuzzy situation at best.
The GS1 Concept is that the GTIN, the Global Trade Identification Number, is a unique number that could serve as the SKU. The customer could read the GTIN, put in on a PO, and get exactly what they want in the correct packaging configuration.
If the product were to change in a way that is significant to the customer, then the GTIN would change and the customer would receive the desired product.
In the UDI regulation, FDA made the concept explicit by stating that the UDI-DI represents a version or model and provided information on how to determine if a design change creates a new version or model and therefore requires a new UDI-DI. In the best of all possible worlds the GS1 rules and the FDA rules are equivalent.
I tell my clients that as a device manufacturer, the UDI system has no value. It is valuable to the customer only. If the product changes in a way that would be significant to the customer, then there should be a new UDI-DI.
I also believe this about the SKU. (At the finished good level, I call this the catalog number, but there are many names in use by many people.) If the product is different it should have a different SKU.
While I like to think that commercial software products have the flexibility to deal with these situations, I have been disappointed. Most software packages have a configuration. I usually schedule an annual review of the configuration settings to make sure they still meet the company needs. There may be a setting that allows you to do what you want.
Your Master Data Management team, however, seems to assert that if there is a difference between regulatory requirements and design of this OTC software, then the software wins. I think this is backward. (Will the software company write the response to the 483?) This raises the issue of software validation of the OTC software. I recommend that you review the purchasing specifications, the software validation protocol, and the software validation report. While you may have purchased the software before the FDA UDI rule, by now the software should be able to handle the regulatory requirements.
P.S. I say ProCode, but sometimes people don't know what I mean.
------------------------------
Dan O'Leary CQA, CQE
Swanzey NH
United States
Original Message:
Sent: 14-Sep-2020 14:17
From: Kat Crowder
Subject: Med Device GTIN Changes vs. Product Code Changes
Thank you for pointing that out! Yes, I mean the individual code representing a product model/item, like a SKU. I'm so used to saying "Pro Code" that I forget it's an abbreviation.
------------------------------
Kat Crowder
Lake Zurich IL
United States
Original Message:
Sent: 14-Sep-2020 11:02
From: Dan O'Leary
Subject: Med Device GTIN Changes vs. Product Code Changes
Just for clarity, there are two meanings for product code.
One is a three letter used by FDA. In GUDID you have the included the FDA Product Code.
The other is the part number of device.
When I started reading I thought it was about the FDA code. when I got to the end I thought it was about the part number.
------------------------------
Dan O'Leary CQA, CQE
Swanzey NH
United States
Original Message:
Sent: 14-Sep-2020 10:52
From: Kat Crowder
Subject: Med Device GTIN Changes vs. Product Code Changes
Dear All,
I would appreciate any and all feedback (named or anonymous) regarding your company's usage of GTINs (DIs) for UDI. From my perspective, GS1, as well as regulatory bodies, have rules when GTINs must change. All regulatory databases so far have the capability to indicate "previous DI" for an existing product code. The GTIN change is entirely unlinked to when product codes must change, which are generally changed only if you have to (or choose to) make a Marketing distinction between an existing product and a new product. Our Master Data Management team, however, says that their database has no way to track a GTIN change to a product code change, and therefore if you need a new GTIN, you must make a new product code. Their database system is a standard off the shelf system (their argument goes), so therefore this is normal practice and there should be no issue. I think there is a big issue, because you want to maintain your product code through product upgrades over time for customer traceability, as well as regulatory traceability in the jurisdictions that register by product code, as well as quality traceability for trending etc.
GS1's feedback has been that they have nothing to say about product codes. Other companies' experiences with GTINs changing vs. product codes changing would be valuable, historical experience and/or company/regulatory/data management policy.
Thanks in advance.
------------------------------
Kat Crowder
Lake Zurich IL
United States
------------------------------