NLM Drug Interaction API Discontinued: A Migration Guide for Development Teams

On January 2, 2024, the U.S. National Library of Medicine (NLM) discontinued the Drug-Drug Interaction API from its RxNav suite of services. The Interactions tab in the RxNav web interface was removed at the same time. This was a deliberate decision by NLM, not a temporary outage, and the service has not returned.

NLM did not publish a detailed rationale for the discontinuation. The Drug Interaction API had relied on two external data sources: ONCHigh, a curated list of high-priority drug-drug interactions maintained by an expert panel and supplemented with CredibleMeds data on drugs with known Torsades de Pointes risk; and DrugBank, whose non-commercial database provided a broader set of interaction pairs without severity information.

The dependency on external datasets that NLM did not control likely factored into the decision. Maintaining a public API that surfaces third-party clinical data carries ongoing curation, licensing, and accuracy responsibilities. Whatever the internal reasoning, the practical outcome for developers is clear: one of the few free, structured drug interaction APIs is gone, and it is not coming back.

The discontinued API offered two primary endpoints. The findDrugInteractions endpoint accepted a single RxCUI and returned all known interactions for that drug. The findInteractionsFromList endpoint accepted a list of RxCUIs and returned interactions between the drugs in that list. Both endpoints returned JSON or XML responses with interaction pair descriptions and source attribution.

The API accepted RxCUI identifiers at multiple concept levels: ingredients (such as simvastatin), brand names (such as Tylenol), and clinical drugs (such as Morphine 50 mg oral tablet). This flexibility made it relatively straightforward to integrate, because teams could pass the same RxCUIs they were already using for normalization tasks directly into the interaction endpoints.

For many development teams, this was the only free, programmatic source of structured drug interaction data. The combination of RxCUI-based input, JSON output, and zero cost made it a common building block in clinical decision support prototypes, pharmacy tools, and EHR integrations. Its removal left a gap that many teams are still working to fill more than two years later.

It is important to understand that only the Drug Interaction API was discontinued. The rest of the RxNav API family remains fully operational. RxNorm, RxClass, RxTerms, and the associated normalization endpoints continue to provide essential drug terminology services.

RxNorm's core value is drug name normalization: mapping messy, real-world drug inputs to canonical identifiers. The RxCUI (RxNorm Concept Unique Identifier) remains the most widely used public identifier for connecting drug names across systems. Endpoints like findRxcuiByString (for exact and normalized matching) and getApproximateMatch (for fuzzy, typo-tolerant resolution) are still available and actively maintained.

Any replacement interaction detection pipeline will almost certainly use RxNorm for its normalization layer. The discontinuation of the interaction API does not diminish RxNorm's role; if anything, it makes explicit that normalization and interaction detection are separate concerns that should be architected independently.

Replacing the RxNav Interaction API requires assembling capabilities from multiple public sources rather than relying on a single endpoint. The architecture naturally separates into layers: drug input normalization, label evidence retrieval, interaction text extraction, severity classification, and response formatting.

This layered approach is more work than calling a single endpoint, but it provides advantages that the original API did not offer. You control the extraction logic, you can tune severity classification to your clinical context, and you retain full traceability back to authoritative FDA label sources. The original RxNav API returned interaction descriptions, but the underlying evidence chain was opaque to consumers.

The trade-off is development and maintenance cost. Each layer introduces its own failure modes, caching requirements, and update schedules. Teams need to make deliberate choices about how much infrastructure they want to own versus consume as a managed service.

The primary public source for drug interaction evidence is the openFDA drug label API. FDA-approved drug labeling is required to include a Drug Interactions section (Section 7 in the structured USPI format) that describes known clinically significant interactions. This content is published in SPL format and indexed by openFDA as the drug_interactions searchable field.

Beyond Section 7, interaction-relevant information often appears in other label sections: contraindications may describe drug combinations that are absolutely prohibited, warnings and precautions may describe interactions that require monitoring, and boxed warnings may highlight the most severe interaction risks. A thorough extraction pipeline queries multiple label fields, not just drug_interactions alone.

openFDA labels can be queried using RxCUI (via the openfda.rxcui field), NDC codes, generic names, or brand names. The recommended approach is to resolve inputs to RxCUI via RxNorm first, then query openFDA by RxCUI. This provides the most reliable match path because RxCUI is a stable, normalized identifier. Fallback strategies using brand name or generic name searches handle cases where RxCUI mapping fails.

The drug_interactions field in openFDA labels contains free-text prose written by pharmaceutical manufacturers and reviewed by FDA. The text varies significantly in structure, length, and specificity across different labels. Some labels provide well-organized subsections with clear drug-by-drug interaction descriptions. Others contain dense paragraphs that discuss multiple interactions, pharmacokinetic mechanisms, and clinical recommendations in a single block.

A practical extraction approach combines deterministic text processing with LLM-based structuring. The deterministic layer handles sentence segmentation, keyword detection (terms like 'contraindicated,' 'concomitant use,' 'dose adjustment,' 'monitor'), and named entity recognition for drug names within the text. This layer is fast, predictable, and easy to test.

The LLM layer handles the harder problem of structuring nuanced prose into discrete interaction records. Given a block of interaction text, the model extracts individual interaction pairs with target drug, severity, mechanism, clinical recommendation, and the specific text snippet that supports the classification. Using the source snippet as a required output field ensures that every extracted interaction can be traced back to its evidence.

FDA drug labels do not change frequently. Most labels are updated quarterly or less often, and the effective_time field on each label indicates when it was last revised. This makes aggressive caching both safe and important for performance.

A well-designed caching strategy keys cached labels on the spl_set_id, which is the stable identifier for a drug's labeling across versions. When a label is fetched from openFDA, the response includes the effective_time, which serves as a version indicator. Cache entries can be refreshed on a weekly or biweekly schedule, which is more than sufficient to capture label updates while keeping API call volume well below openFDA's rate limits of 240 requests per minute and 120,000 requests per day.

Extraction results should be cached separately from raw label text. This allows you to re-run extraction logic against cached labels when your extraction model improves, without re-fetching from openFDA. The cache key for extracted interactions is typically the combination of spl_set_id and extraction model version, so upgrading your extraction logic automatically invalidates stale results.

The complete replacement pipeline connects RxNorm and openFDA in a deliberate sequence. An input drug name arrives as free text. RxNorm's findRxcuiByString endpoint attempts an exact or normalized match. If that fails, getApproximateMatch provides fuzzy resolution that handles misspellings and partial names. The result is one or more RxCUI candidates.

With an RxCUI in hand, the pipeline queries openFDA using search=openfda.rxcui:{rxcui} with a sort on effective_time to retrieve the most current label. The drug_interactions, contraindications, warnings, and boxed_warning fields are extracted from the response. These text blocks are then processed through the extraction and classification layers to produce structured interaction records.

For a multi-drug interaction check (the equivalent of the old findInteractionsFromList endpoint), the pipeline retrieves labels for each input drug and performs cross-matching. Drug A's interaction text is checked for mentions of Drug B, and vice versa. This cross-match approach can surface interactions that are documented on only one drug's label, which is common when one drug is well-studied and the other is newer or less widely prescribed.

The RxNav Interaction API provided simplicity: one endpoint, one call, structured results. That simplicity came with trade-offs that were easy to overlook. The API returned interaction descriptions without source citations to specific label sections. It did not provide severity levels from the DrugBank source. The ONCHigh dataset, while expert-curated, covered a narrow set of high-priority interactions rather than comprehensive label-derived coverage.

A label-based replacement pipeline trades that simplicity for depth and traceability. Every interaction result points back to a specific label, section, and text passage. Severity classification can be calibrated to your use case. Coverage is as broad as the FDA labeling corpus, which includes every approved prescription drug. The cost is engineering effort: building, testing, and maintaining the pipeline infrastructure.

For teams that need a quick solution, managed APIs that implement this pattern already exist. For teams that want full control over their extraction and classification logic, the building blocks are publicly available. The right choice depends on your timeline, regulatory requirements, and how central interaction detection is to your product.

RxLabelGuard implements the architecture described in this guide as a managed API service. It handles RxNorm-based drug name normalization, openFDA label retrieval, interaction extraction via deterministic analysis and AWS Bedrock LLM structuring, severity classification, and evidence-cited response formatting. Labels and extraction results are cached by spl_set_id with effective_time tracking.

It is not the only way to fill the gap left by the RxNav Interaction API. Teams with the engineering capacity to build and maintain their own pipeline can do so using the same public data sources. Teams that need curated, editorially maintained interaction databases may find commercial offerings from DrugBank, First Databank, or Elsevier more appropriate for their clinical and regulatory requirements.

The RxNav discontinuation removed a convenient single endpoint, but it did not remove the underlying public data. The normalization layer (RxNorm) and the evidence layer (openFDA labels) remain available. What changed is that teams now need to assemble these components themselves or choose a service that does it for them.