RxNorm and Medication Coding

The Problem: One Drug, Many Names

A single medication can be named in dozens of ways. A prescriber might type “metformin,” a pharmacy system might store “Glucophage 500 MG oral tablet,” a formulary spreadsheet might list “METFORMIN HCL 500MG TAB,” and a packaging catalog might identify the very same bottle by a manufacturer-assigned code. To a human these obviously refer to related things; to software they are unrelated strings. That mismatch is not a cosmetic annoyance. It blocks the tasks that make medication data clinically useful: checking for drug-drug interactions, aggregating how many patients are on a given drug, and driving decision support or formulary rules. If two records that mean the same drug cannot be recognized as the same, an interaction alert can silently fail to fire ¹.

The root issue is that ordinary drug names and manufacturer catalog codes were never designed to be a shared, computable vocabulary. They describe products for people, packaging, and commerce — not the underlying clinical concepts that safety logic needs to reason about.

What RxNorm Provides: A Normalized Naming Layer

RxNorm, produced by the US National Library of Medicine, addresses this by sitting between the many source vocabularies and the systems that consume drug data. It is a normalized naming layer: it ingests drug names from many sources and ties together the names that mean the same thing ¹. Each distinct drug concept is assigned an RxCUI, a concept unique identifier — a stable number that denotes the concept itself, not any one spelling of it. For example, the ingredient metformin is the RxNorm concept with RxCUI 6809 ². Software can compare, count, and look up drugs by RxCUI without parsing free text, in much the same way a clinical terminology lets systems reason by concept identifier rather than by wording.

The value is in the linking. Many source strings — a generic name, a brand name, an abbreviated formulary entry — can all resolve to the same RxCUI, so the normalized identifier becomes the common ground on which interaction checks and analytics operate.

Term Types: Building Concepts in Layers

RxNorm does not treat “a drug” as a single flat idea. It organizes drug concepts into term types (TTY) that describe what kind of concept each RxCUI represents, layered from the simplest building block up to fully specified products ¹.

The most basic layer is the ingredient (TTY: IN) — the active substance itself, independent of strength, form, or brand. Metformin is an ingredient concept, and the only RxCUI asserted in this lesson is its ingredient identifier, 6809 ². Richer concepts are built up from ingredients:

• A Semantic Clinical Drug (TTY: SCD) combines an ingredient with a strength and a dose form to describe a generic prescribable product — conceptually, a generic “metformin 500 mg oral tablet.”
• A Brand Name (TTY: BN) names a marketed brand associated with one or more ingredients.
• A Semantic Branded Drug (TTY: SBD) is the branded counterpart of an SCD: a brand name combined with strength and dose form.

Each of these concept layers has its own RxCUI in RxNorm. This lesson cites only the ingredient RxCUI 6809; the SCD, BN, and SBD examples above are described by their meaning, and no specific RxCUI is asserted for them ².

Term type   Example concept (described, not coded here)
---------   -------------------------------------------
IN          metformin                       (RxCUI 6809)
SCD         metformin 500 mg oral tablet    (generic; RxCUI not asserted)
BN          a brand name for metformin      (RxCUI not asserted)
SBD         brand 500 mg oral tablet        (branded; RxCUI not asserted)

These layers are related to one another inside RxNorm, so a branded product can be traced back to its underlying ingredient. That traceability is exactly what makes the next two jobs possible.

Bridging to NDC, and Why Normalization Enables Safety Logic

Below the level of clinical concepts sits the National Drug Code (NDC): a manufacturer-assigned code that identifies a specific drug package — a particular product, package size, and labeler. NDCs are essential for commerce and dispensing, but they are too granular and too commercial to reason with clinically. Many different NDCs can correspond to the same clinical drug, and the codes carry no built-in notion of shared ingredient. RxNorm bridges this gap by linking NDCs to RxNorm concepts, so a scanned package code can be resolved up to the normalized clinical concept it represents ¹.

This is what makes a normalized identifier so much more powerful than raw text or NDCs for safety and policy logic. Consider drug-drug interaction checking. An interaction rule is fundamentally a statement about ingredients — two active substances that should not be combined. If every prescription, no matter how it was named or which package it shipped in, can be resolved through RxNorm to its ingredient concept, then the interaction engine can compare ingredients reliably ¹. Trying the same thing against free-text names or NDCs would mean matching thousands of spellings and package variants by hand, with failures that are dangerous precisely because they are silent.

Formulary and decision-support logic benefit the same way. A formulary rule that says “prefer the generic” or “this class requires prior authorization” is far easier to express against stable RxNorm concepts and term types than against brand strings that change with marketing. Because the term-type layers connect brand to generic to ingredient, a rule written at the ingredient level can apply to every branded and generic product that rolls up to it.

Summary

RxNorm exists because the same drug is named many ways across pharmacies, EHRs, and NDC catalogs, and those names cannot be computed against directly. By assigning each drug concept a stable RxCUI and organizing concepts into layered term types — ingredient, then clinical drug, brand, and branded drug — RxNorm gives systems a shared, normalized vocabulary ¹. Anchored by verifiable concepts such as the ingredient metformin ², and bridged down to NDC packages, that normalization is what lets interaction checking, aggregation, and formulary logic work at all.