Why doesn't a US drug code work in a Canadian health system?

Two countries, two drug identifier systems, no shared key. Medication data is where cross-border health software quietly breaks.

The assumption that breaks

Health software ported into Canada usually survives the obvious problems. Spelling, date formats, provincial names, bilingual interface requirements - all visible, all budgeted for. The one that reliably surprises teams is medication identifiers, because the failure is invisible until it is clinical.

The assumption underneath is that a drug is a drug: that somewhere there exists a canonical identifier for, say, a particular strength of a particular molecule in a particular form, and that the two countries are using different labels for the same underlying thing. It is a reasonable assumption. It is wrong in a way that matters.

Two systems, built separately, for different jobs

In Canada, drug products authorized for sale are recorded in Health Canada's Drug Product Database, which is the source of the Drug Identification Number [1]. That DIN is what Canadian clinical and pharmacy systems key against.

In the United States, the identifier is the National Drug Code. The FDA describes it as a unique, three-segment number serving as the agency's identifier for drugs, with the directory built from structured product labeling electronic listing files submitted by labelers - where a labeler may be a manufacturer, repackager, relabeler, or the entity named on the product label - and published in a directory updated daily [2].

Read those two descriptions side by side and the structural difference emerges. The NDC is organised around the labeler and the package. It is a listing artifact: the FDA is explicit that drug establishments are required to provide a current list of all drugs manufactured, prepared, propagated, compounded or processed for sale at their facilities [2]. That is a registry of what is being marketed, not a certification of what is good.

The FDA presses this point unusually hard. Inclusion in the NDC Directory does not indicate that FDA has verified the information provided or that the products have been approved by the agency; assignment of an NDC number does not in any way denote FDA approval; and any representation that creates an impression of FDA approval because a product has an NDC number is misleading and violates federal law [2]. The directory also does not contain all listed drugs - animal drugs, blood products and certain contract-manufactured and kit-component products fall outside it [2].

So an NDC is not a statement about clinical status, approval, or coverage. Software that treats the presence of an NDC as evidence of any of those things has imported a misunderstanding, not just a mismatched key.

Why RxNorm does not rescue you

Teams that have worked in American health IT usually reach for RxNorm at this point, and it is a genuinely excellent piece of infrastructure. RxNorm provides normalized names for clinical drugs and links its names to many of the drug vocabularies commonly used in pharmacy management and drug interaction software, including those of First Databank, Micromedex, Multum and the Gold Standard Drug Database, and by providing those links it can mediate messages between systems not using the same software and vocabulary [3]. It now also includes the United States Pharmacopeia Compendial Nomenclature [3].

Notice what problem that solves. RxNorm exists because the American market has multiple competing commercial drug vocabularies, and systems using different ones cannot understand each other. It is a mediation layer across American vocabularies. The cross-border problem is a different problem wearing similar clothes, and a normalization layer scoped to one country's vocabularies does not span two countries' regulatory identifier systems.

What a mapping actually costs

It is possible to relate Canadian and American drug data. It is not possible to convert between the identifiers, and the distinction is the whole engineering estimate.

A mapping has to be built on clinical attributes - active ingredient, strength, dosage form, route, and often manufacturer and package - and matched across two datasets that were curated independently with different scope rules. The result is a curated dataset with three categories of outcome: clean matches, ambiguous matches where one identifier corresponds to several on the other side, and genuine absences where a product marketed in one country simply is not marketed in the other.

The third category is the one that undermines naive designs. A missing match is not a data-quality defect to be cleaned up later; it is a true fact about the world. Any schema that assumes every drug has a counterpart identifier will either drop rows or fabricate them, and in medication data both are unacceptable.

The mapping is also perishable. Both directories change continuously - the FDA updates its directory daily [2] - so a mapping is a maintained service with an owner and a refresh cadence, not a one-time import.

Where it shows up in the product

Almost every clinically useful medication feature keys off the drug identifier. Interaction checking, allergy and cross-sensitivity matching, duplicate-therapy detection, formulary and coverage logic, and the patient-facing medication list all resolve through that key.

When the key is wrong, these features do not throw errors. They return fewer results. An interaction check against an unmatched identifier returns no interactions, which is indistinguishable, on screen, from a genuine all-clear. That is the specific reason medication identifier mismatch deserves more architectural attention than its size suggests: the failure mode is silence where a warning belonged.

The design response is to make the unmatched state explicit rather than absent. A medication whose identifier could not be resolved should be visibly flagged as unresolved, so that "no interactions found" and "could not check" are never rendered the same way.

Modelling it properly in FHIR

FHIR gives you somewhere sensible to put this. Its Medications module covers Medication, MedicationRequest, MedicationDispense, MedicationAdministration, MedicationStatement and Immunization, with a separate Medication Definition area at the specification's highest level covering medicinal, packaged and administrable product definitions and regulated authorization [4].

The separation between definition and use is the useful part. Jurisdictional identifiers belong to the definition of the product, not to the record of a patient taking it. Modelled that way, a national identifier becomes one more coded identifier on a product definition, and a system can legitimately carry a DIN, an NDC, both, or neither, without the patient-facing record changing shape.

The provincial layer on top

One more Canadian wrinkle. Federal authorization to market a drug and provincial willingness to pay for it are separate decisions, since each province and territory determines which services it considers medically necessary and will cover [5]. A drug can therefore be perfectly valid nationally and still be handled differently depending on where the patient lives.

That means "is this drug real?" and "is this drug covered here?" are two different lookups with two different authorities behind them, and a product that collapses them into one field will be wrong for most of the country. MapleTriage is being built in Moncton, New Brunswick with that separation in the model from the start. It is in development and not generally available.

By Joel Gathercole · Published 2026-06-14