When an NDC Isn’t Really an NDC: Untangling Medical Device Identifiers
You are looking at a claims or pharmacy dataset and find what appears to be an NDC (National Drug Code) for a continuous glucose monitoring device. Nothing unusual, until you remember that an NDC is supposed to identify a drug, and a glucose sensor is a medical device.
Does that mean medical devices also have NDCs?
We will answer that question through a fascinating real-world example, explain the historical context behind these identifiers, and leave you with a practical approach for storing, linking, and managing medical device identifiers.
We were recently working on compiling a comprehensive set of identifiers for continuous glucose monitoring (CGM) devices. As part of that work, we looked across clinical terminologies and drug information sources used throughout healthcare. RxNorm was one of them.
And there they were: CGM products in RxNorm data, along with source-provided labeled as NDCs. We identified 47 CGM devices or components associated with 58 NDC values. Since NDCs are part of RxNorm data, having NDC values associated with these devices initially appeared to solve at least part of our identification problem, and in a very convenient way.
RxNorm receives information from multiple source vocabularies and generally normalizes source-provided drug NDCs into the standard 11-digit format. For device content, however, these source-provided NDC values are not normalized, although the original values remain available in the release data and can be retrieved. The vast majority of the CGM identifiers in RxNorm come from the VA National Drug File (VANDF) and Elsevier’s Gold Standard.
Other commercial drug information databases also carry similar identifiers, often in fields associated with NDCs, because these values continue to play a practical role in identifying and reimbursing certain medical devices.
That is where pharmacy or claims data experts may pause and question the data. NDCs are deeply embedded in pharmacy, claims, reimbursement, and healthcare data-processing workflows, but the NDC system is fundamentally a drug-identification system. CGM sensors, readers, transmitters, and related equipment are medical devices.
More importantly, FDA policy has been moving away from the use of NDCs and NHRICs (National Health Related Item Codes) as identifiers for medical devices for more than a decade. The 2013 UDI Rule established the Unique Device Identification system, and FDA regulations rescinded legacy NDC and NHRIC identifiers assigned to medical devices as UDI requirements took effect. FDA also no longer assigns labeler codes for the purpose of creating NDCs for non-drug products.
So, What Exactly Are These Numbers?
To understand this, it helps to first look at the anatomy of an NDC. An NDC has three components:
- a labeler code assigned by the FDA
- a product code assigned by the labeler
- a package code assigned by the labeler
Take 60505-2578-0 as an example. The first segment, 60505, identifies the labeler, Apotex Corp. The next segment identifies the specific drug product, in this case atorvastatin 10 mg oral tablet, while the final segment identifies the packaging.
Now consider one of the identifiers tagged as an NDC in RxNorm for the FreeStyle Libre 3 Sensor Kit:
– 57599-0818-00
At first glance, it certainly looks like an NDC. One might therefore expect 57599 to be an FDA drug labeler code and the remaining digits to identify a drug product and package.
But a search of current FDA NDC data does not resolve this identifier as an NDC. Nor does 57599 resolve as a current labeler code. In fact, none of the 58 CGM identifiers tagged as NDCs in the RxNorm data we examined for CGM devices can be matched to a current NDC in FDA’s database.
That tells us what these identifiers are not, but we still need to understand what they really are.
The Clue Hidden in GUDID
The Global Unique Device Identification Database, or GUDID, is the FDA-administered reference catalog for devices with Unique Device Identifiers (UDIs). In GUDID, each device is identified by one Primary DI (device identifier) and may include additional identifiers.
When we looked up the FreeStyle Libre 3 Sensor Kit in GUDID, we found its Primary DI as:
00357599818005
Let’s put a few spaces in that number to make it more readable:
003 57599 818 00 5
This number looks remarkably similar to the “NDC” we were investigating. Interestingly, the same GUDID record contains another identifier tagged as NDC/NHRIC:
57599-0818-00
It is the very value we had encountered as an NDC in RxNorm. The number appearing in drug-oriented terminology and reimbursement data is not just an erroneous drug NDC attached to a medical device. It is a legacy or secondary device identifier associated with the same device that GUDID now identifies through the modern UDI framework.
The resemblance between the Primary DI and the secondary NDC/NHRIC is striking, and one might wonder whether the latter is a modification of the former, to manufacture a number that looks and even behaves like an ordinary NDC. But the important fact is that FDA’s device data explicitly connects the current UDI-based identity with the legacy NDC/NHRIC-style identifier.
Once the nature of these identifiers becomes clear, the next question becomes more obvious:
Why Were These Numbers Created in the First Place?
We like to call these numbers “NDC-like identifiers” to describe this family of device identifiers: numbers that may resemble NDCs in format or function and may still circulate through NDC-oriented systems, but do not represent drug products and should not be confused with current FDA NDCs.
Their existence makes much more sense when viewed historically. Before the UDI system, the medical device industry did not have the standardized national identification framework that exists today. Manufacturers and healthcare organizations still needed practical ways to identify devices for inventory management, ordering, reimbursement, pharmacy processing, and other operational purposes.
In some cases, manufacturers with FDA-assigned labeler codes used those codes to construct identifiers that were labeled as either NDCs or NHRICs on medical device packages. FDA itself describes this history in its guidance on legacy device identifiers.
These values became especially useful when devices were dispensed or reimbursed through pharmacy-oriented workflows. Pharmacy information systems were already built around NDCs, so identifiers that could travel through those same systems solved a very practical problem.
Over time, they became embedded in claims systems, pharmacy databases, payer rules, formularies, terminology products, historical datasets, and reimbursement processes.
And that explains why they have not simply disappeared. A regulatory framework can change much faster than the healthcare data ecosystem built around it.
Old or New: Which Identifier Should Be Used?
At first, the obvious solution might appear to be simple: stop using the old identifiers or the “NDC-like” numbers and move everything to UDI. But real healthcare data does not work that way.
Historical claims still contain legacy identifiers. Pharmacy systems continue to receive them. Payer rules and formularies still reference them. Terminology products and downstream analytics have years of logic built around them. Even when an identifier is no longer the preferred regulatory mechanism for identifying a device, it may remain highly relevant operationally.
At the same time, continuing to treat those legacy identifiers as the authoritative identity of a device creates a different problem. They belong to an older identification approach and provide only a limited view of the device compared with the richer information available through UDI and GUDID.
Therefore, the real challenge is not choosing between the old identifier and the new one, but establishing a reliable connection between them.
Apelon’s Recommended Device Identification Model
At Apelon, we believe GUDID should form the authoritative foundation for current U.S. FDA-regulated medical device identity, while legacy NDC-like identifiers should remain available as lookup keys that connect older or reimbursement-oriented data to the current device record.
Conceptually, the model is simple:
This approach allows an organization to accept the identifiers that arrive in pharmacy feeds, claims files, historical data, and third-party terminology sources while still normalizing the device to a current and authoritative device identity.
In some cases, as the FreeStyle Libre 3 example demonstrates, GUDID itself already contains the bridge by carrying an NDC/NHRIC value as a Secondary DI. In other cases, additional terminology work may be required to establish, verify, and govern the relationship. A mature terminology layer understands those relationships and allows multiple source systems to refer to the same underlying device without fragmenting it into apparently unrelated records.
Why This Matters
While CGMs happened to expose the problem, any organization ingesting device information from pharmacy systems, reimbursement feeds, historical datasets, or third-party terminology products will quite likely encounter the same problem: different systems know the same device by different identifiers.
Without an identity-resolution strategy, utilization can become fragmented across identifiers, historical claims can become difficult to reconcile with current device information, device value sets may be incomplete, and downstream systems may be forced to understand multiple generations of identification schemes independently.
Legacy data remains usable, modern GUDID identity remains authoritative, and downstream applications can work with a normalized representation of the device rather than having to understand every identifier that has ever been associated with it.
That supports cleaner analytics, more reliable device value sets, better historical continuity, and more consistent integration across healthcare systems.
In other words, we at Apelon see this as more of a terminology-management and semantic-normalization problem rather than an identifier-mapping exercise in isolation.
For healthcare data leaders, terminology experts, and healthcare IT architects facing this problem, Apelon can provide the terminology infrastructure and expertise needed to preserve legacy device identifiers, govern their relationships, retain provenance, and expose a normalized device identity to downstream systems.
