Canadian DIN Database & DIN → RxNorm Crosswalk

What is a DIN?

A Drug Identification Number is an 8-digit number assigned by Health Canada to every drug product approved for sale in Canada. It identifies a specific manufacturer’s product by its active ingredients, strength, pharmaceutical form, and route of administration, and must appear on the product label. It is the primary key of Health Canada’s Drug Product Database (DPD).

The detail that trips up most integrations: a DIN does not encode package size. Unlike an NDC, whose final segment distinguishes a 30-count bottle from a 90-count bottle, one DIN covers every package size that manufacturer ships of that formulation. Package configurations live in a separate DPD table. That puts the DIN’s grain squarely between NDC and RXCUI — more specific than a clinical concept, less specific than a package.

Canadian DIN Database

Canada has one authoritative drug database and it is public. Health Canada’s Drug Product Database covers every product approved for sale in the country, searchable one product at a time on the web and downloadable in bulk as text extracts split by product status — marketed, approved, dormant, and cancelled. There is no licensing cost and no access gate. What there is, is a normalization problem.

The distinction matters when scoping work: if you need to look up one Canadian product, the public DPD is the right answer and this page is only context. If you need Canadian drug data to behave like a dimension table — grouped, classified, and joined to anything else — the normalization and the crosswalk are the work, and they are what this dataset is.

DIN vs NDC vs RXCUI

There is no arithmetic conversion between a DIN and an NDC. They are issued by different regulators — Health Canada, the US FDA, and the US National Library of Medicine respectively — for different markets, at different grains. The only route between them is a crosswalk through a shared clinical vocabulary.

For the US-only comparison, see RxNorm vs NDC and the RxNorm–NDC crosswalk.

Can You Convert a Canadian DIN to a US NDC?

No — not by conversion. A DIN and an NDC are assigned independently by two regulators for two markets, and neither encodes any part of the other, so no arithmetic, padding, or string transformation relates them. They also sit at different grains: a DIN is one manufacturer’s formulation, an NDC is one physical package. Even if the identifiers were related, one DIN could not correspond to one NDC.

The correct model routes through a clinical concept both markets can be normalized to:

DIN 02388081     AURO-AMOXICILLIN · amoxicillin 500 MG · CAPSULE · ORAL
   │
   │  resolve on ingredient set + dose form + per-ingredient strength
   ▼
RXCUI 308191     amoxicillin 500 MG Oral Capsule
   │
   │  expand to every US package code carrying that concept
   ▼
NDC 00093310905  Teva amoxicillin 500 mg capsule, 500-count bottle
NDC 00003010955  … and 452 others

The fan-out at each end is the point. RXCUI 308191 is carried by 10 Canadian DINs — NOVAMOXIN, APO-AMOXI, AURO-AMOXICILLIN and seven more, one per manufacturer — and by 454 US NDCs, which is every labeler × package size combination the US market lists for the same capsule. A DIN therefore maps to a set of NDCs, not to one, and the reverse holds too. Any integration that expects a one-to-one DIN↔NDC mapping is built on an assumption the data does not support.

Querying the Crosswalk

SELECT
    c.din,
    c.brand_name,
    c.strength_text,
    d.drug_name,
    d.ingredient,
    d.dose_form
FROM canada_drug_product c
JOIN drug_profile        d ON d.drug_id = c.drug_id
WHERE c.din = '02377233';

SELECT
    c.din,
    c.brand_name,
    c.schedule
FROM ndc_crosswalk        n
JOIN canada_drug_product  c ON c.drug_id = n.drug_id
WHERE n.ndc11 = '00093310905';

SELECT
    LEFT(c.atc_code, 3)   AS atc_class,
    COUNT(*)              AS dins,
    COUNT(DISTINCT c.drug_id) AS drug_concepts
FROM canada_drug_product c
WHERE c.is_prescription
  AND c.match_method = 'deterministic'
GROUP BY 1
ORDER BY dins DESC;

API endpoints

Full request and response shapes are in the API reference; the table and column definitions are on the schema reference.