DailyMed API v2: Build a Versioned Drug Label Data Pipeline

DailyMed API v2 provides retrieval access to current Structured Product Labeling (SPL) information through versioned, GET-only web services. It is a distribution interface, not an approval-status database. DailyMed describes its labels as the most recent company submissions to the Food and Drug Administration (FDA), currently in use; FDA explains that such labeling can differ from the last FDA-approved labeling. A pipeline should therefore preserve the source and publication context of each retrieved document rather than infer approval from its presence. (^[1]) (^[2]) (^[3])

The central lineage key is SET ID plus SPL version, with the document identifier retained independently. FDA defines SET ID as constant through revisions and the version as a positive integer. Current downloads, archived responses, and historical versions are different retrieval concepts. DailyMed supplies a history resource and a version-specific ZIP mechanism; the historical file must be selected using both SET ID and version. Pagination also matters: the label-list documentation specifies 100 records as both the default and maximum page size. (^[4]) (^[5]) (^[6])

The recommended architecture separates raw files, immutable versions, identifier bridges, parsed sections, and retrieval observations. Composite database constraints can enforce the version key; namespace-aware XML parsing preserves element identity; application-specific comparison rules should sit above byte hashes. A changed hash establishes changed bytes, while canonical XML can still distinguish documents that an application considers equivalent. openFDA serves a different purpose: it converts SPL data into JSON and adds annotations whose harmonization requires exact matches. It can support discovery without replacing a source-file lineage store. (^[7]) (^[8]) (^[9]) (^[10]) (^[11])

As of October 6, 2026, the retrieved bulk-release page displayed archive modification dates of October 5, 2026. These are publisher file dates, not measured ingestion latency. Microsoft separately documents a connector allowance of 100 calls per connection per 60 seconds; that figure must not be presented as a DailyMed origin-service throttle. This report provides an endpoint map, a Python retrieval pattern, identifier reconciliation rules, and a change-data-capture design. It reports documented quantities and proposes formulas for local quality measurement, without inventing current coverage, retention guarantees, or live join-success statistics. (^[12]) (^[13])

DailyMed is useful when the question is: what public labeling document was available, which revision was retrieved, and where did a particular passage originate? Its description of current in-use labeling refers to company-submitted material. The National Library of Medicine (NLM) explicitly states that it does not review SPL content before publication. This distinction belongs in the data model and user interface, especially when search results become evidence supplied to medical-information or clinical-informatics teams. (^[14])

SPL supplies document structure rather than a ready-made enterprise governance workflow. HL7's historical SPL brief describes a markup standard for the structure and semantics of product information and identifies section-by-section version comparison as a benefit. That brief describes the standard's design; it should not be used to establish the current release supported by a deployment. A DailyMed ingestion service must supply its own storage policy, reconciliation process, parser controls, and review workflow. (^[15]) (^[16])

IntuitionLabs describes its information-layer work in terms of authoritative sources, identity, permissions, retrieval, and citations. Applied here, that means retaining the document behind a result, recording when it was observed, and allowing an analyst to reproduce the evidence shown. (^[17])

This report treats the following as distinct records: a label family, a document revision, an acquisition observation, a product identifier association, and an extracted section. The proposed separation makes warehouse responsibilities explicit. Namespace-aware interpretation then protects the element identities used during extraction, allowing an analyst to trace a search result back to retained source content. Recommendations below are design proposals unless explicitly attributed to a publisher's documentation. (^[8])

SET ID, document ID and version

A SET ID identifies a lineage across revisions. FDA's implementation guide says it remains constant through versions and revisions, while the document id is unique. The versionNumber sequences documents using a positive integer. FDA's listing instructions reinforce the distinction: retain the set ID and generate a new document ID when updating a listing. A title, brand name, ingredient string, or package code should therefore remain an attribute or association, not replace the lineage key. (^[4]) (^[18])

A proposed identity diagram can be expressed without assuming that every revision is locally available:

• Label family: SET ID identifies the continuing lineage.
• Document revision: SET ID plus version identifies the proposed warehouse record.
• Source document: Document ID records the distinct submitted XML document.
• Retrieval observation: Source URL, acquisition time, response metadata, and digest describe an encounter with that document.

In this proposed design, a composite database primary key can enforce the warehouse identity. Observation records should remain appendable even when the document is already stored, because a repeated acquisition is still evidence of a separate retrieval. (^[7])

Dates answer different questions

The SPL effectiveTime is a version-date reference expressed as YYYYMMDD in FDA's guide. It should not be renamed approval date or upload date. DailyMed separately defines UPLOAD_DATE in ZIP metadata as the upload date of the current active version. The history response also contains version-specific publication dates and a database publication timestamp. Preserve original date strings alongside parsed values, because a document date and an acquisition timestamp have different meanings. (^[19]) (^[20]) (^[21])

Use fields such as spl_effective_date, label_published_date, database_published_at, and retrieved_at. The first three retain the publisher's semantics; the last is generated by the pipeline. Python recommends aware datetimes for UTC timestamps. Do not invent a time of day for a date-only value, and do not silently interpret a source timezone abbreviation as the server's local timezone. (^[22])

Active, archived and historical

DailyMed documents current ZIP and PDF responses with 200 ACTIVE and 200 ARCHIVED statuses. The documented Content-Disposition header identifies the filename, and X-DAILYMED-LABEL-LAST-UPDATED reports the label's last update. Preserve that metadata and the documented status text; numeric HTTP success alone does not establish active labeling. Its archive interface also supports retrieving the label current on a given date. A historical revision is a document selected from a lineage; an archived label is a distribution-state observation. Record both dimensions rather than representing them with a single current flag. (^[23]) (^[24])

FDA approval remains a separate question. FDA identifies Drugs@FDA as a source of the most recent FDA-approved prescribing information and patient labeling. A labeling application should state which source supports an approval assertion and avoid deriving that assertion from an identifier join. (^[25])

Endpoint map and output formats

DailyMed's v2 documentation provides collection resources for drug names, classes, identifiers, application numbers, and labels, together with SET ID-specific resources. The reviewed documentation does not establish a numerical origin-service rate limit, a history-retention duration, or an availability service-level agreement. Those remain requirements for local monitoring and reconciliation. (^[1]) Treat response envelopes and the underlying SPL document as different structures. A proposed ingestion service should route each representation to a parser with explicit namespace expectations. (^[8])

Table 1 summarizes retrieval choices and their appropriate roles. It distinguishes document retrieval from discovery and annotations.

Resource or channel	Inputs and output	Pipeline role
DailyMed /spls	Filters, page and pagesize; JSON or XML label listings.	Discover candidates and retain pagination metadata. ([6])
/spls/{SETID}/history	SET ID; JSON or XML version history.	Enumerate publisher-listed revisions before historical acquisition. ([26])
/spls/{SETID}	SET ID; SPL XML.	Retrieve the specified lineage's document representation. ([27])
/spls/{SETID}/ndcs, /packaging, /media	SET ID; identifier, packaging and media resources.	Capture associations, nested packaging, and media references. ([28]) ([29]) ([30])
Latest ZIP/PDF and historical ZIP	Relative to the DailyMed site: downloadzipfile.cfm?setId={setid}, downloadpdffile.cfm?setId={setid}, and getFile.cfm?type=zip&setid={setid}&version={versionnumber}.	Use historical ZIP for version-specific parsing; date SET-ID-only resource observations separately. Historical PDF retrieval is not documented. ([5])
DailyMed bulk files	Daily, weekly, monthly updates or full releases.	Seed and reconcile broader collections without relying solely on paginated discovery. ([31])
openFDA label API	JSON transformed from SPL with added annotations.	Search structured fields and annotated identifiers, while retaining a separate original-document lineage. ([10])

For a bounded list of known labels, individual retrieval is a proposed starting point. For a broader collection, consider bulk acquisition followed by targeted reconciliation. The acceptance policy should require the original package whenever package-level provenance is needed, rather than infer that a search record supplies it. Composite keys and source digests help keep those acquisition paths connected. (^[7]) (^[32])

Filtering and pagination

The label-list resource documents filters for SET ID, NDC, RxCUI, UNII, application number, drug name, labeler, document type, classes, and other attributes. Publication-date filtering uses published_date with comparison operators lt, lte, gt, gte, and eq. These concern publication on DailyMed, rather than FDA approval or the SPL effective date. (^[33])

The documented page-size default and maximum are 100, with the initial page 1. Preserve total_elements, total_pages, current_page, next_page_url, and db_published_date when present. The history documentation illustrates these metadata separately from the label's version dates. Normalize documented string-like numeric values deliberately rather than letting inconsistent types enter database keys. (^[6])

Recommended traversal rules are:

• Follow pagination: Continue until the documented next-page marker ends.
• Record the scan: Keep its query, observed metadata, and completion state.
• Deduplicate candidates: Enforce the proposed composite version key.
• Bound decoding: Apply a configured response-size limit.
• Separate errors: Check HTTP status before trusting decoded JSON.
• Reconcile changes: Treat a completed traversal as an observation, not a guaranteed database snapshot.

These implementation rules use database uniqueness and Python's recommendation to limit JSON input size; Requests documents that successful JSON decoding alone does not establish HTTP success. (^[34]) (^[35]) (^[36])

Preserve relationships, not a flattened drug row

A proposed schema separates label, label_version, retrieval, identifier_edge, section, media_asset, and change_event. The version table's non-null composite key prevents ambiguous document identities; retrieval rows explain where and when bytes were acquired. PostgreSQL documents both multi-column keys and their uniqueness requirements. Different storage engines may implement the same logical model. (^[37]) (^[7])

Table 2 maps proposed records to source identifiers and reconciliation rules.

Record or association	Suggested key and retained fields	Reconciliation rule
Label version	SET ID, version, document ID, effective date, raw digest.	Keep lineage and document identity separately. ([4])
Label to NDC	SET ID/version, raw product or package NDC, role, source snapshot.	Multiple product/package NDCs can share labeling; preserve cardinality. ([38])
Label to RxCUI	SET ID, mapping SPL version, RxNorm concept identifier, mapping date.	DailyMed mapping describes current active versions and potentially multiple concepts. ([39])
Ingredient to UNII	Substance identifier, ingredient role, source section/product.	Use substance identity without converting it into approval status. ([40])
Product to application	Raw application value, marketing category, source document ID.	FDA describes application values as labeler-reported; preserve category context. ([41])
Product/package reconciliation	External product ID, NDC segments, source document ID.	FDA's product-file identifier combines product code and SPL document ID. ([42])
Parsed section and media	Version key, section code/path/order; media reference and digest.	Namespaced element identity and retained references keep extraction traceable. ([8])

The interpretive point is cardinality. The bridge should preserve every accepted association and let a downstream application choose an appropriate subset through an explicit, reviewable rule. Flattening that bridge into a single preferred code hides the choice. A database can enforce unique combinations of association fields without pretending that each individual field is unique. (^[34])

Identifier-specific cautions

The National Drug Code (NDC) is a three-segment identifier. NDC assignment does not establish FDA approval. (^[43]) Retain its original representation and product/package role. A proposed normalization should preserve its inputs, rule, and output so a reviewer can reproduce mismatches.

RxCUI means an RxNorm concept identifier. Date each proposed mapping snapshot. If it cannot establish an old revision's association, preserve that uncertainty rather than copying the latest join retrospectively. Store the snapshot identifier beside the edge.

UNII, the Unique Ingredient Identifier, addresses substance identity. FDA's substance registry bases identifiers on scientific identity characteristics. Keep ingredient roles and contexts separate from the identifier itself: a substance match alone should not resolve the choice of label family, product package, or indication. (^[40])

For a proposed pharmacologic-class bridge, retain class code, vocabulary, description, source snapshot, and associated version key. Preserve multiple classes rather than choose a preferred class implicitly. Enforce the combination of association fields as the unique edge, while allowing a class to appear against multiple labels. (^[34])

OpenFDA harmonization adds another layer. Its documentation says exact matches are required, so a search restricted to harmonized fields can return a subset of records. A missing annotated identifier is therefore not evidence that the original document lacks the underlying product or substance information. Store the join method and mapping source alongside the result. (^[44])

Paginated retrieval with connect and read timeouts

A DailyMed API Python example should expose pagination, errors, and timeouts. Requests supports separate connect and read timeout values, but those controls are not a total wall-clock deadline. The following documentation-derived fragment yields discovery records from a supplied publication date; it does not acquire SPL files. (^[45]) (^[46])

import requests

BASE = "https://dailymed.nlm.nih.gov/dailymed/services/v2"

def discovery_records(start_date, connect_timeout, read_timeout):
    params = {
        "published_date": start_date,
        "published_date_comparison": "gte",
        "pagesize": 100,
        "page": 1,
    }
    with requests.Session() as session:
        while True:
            with session.get(
                f"{BASE}/spls.json",
                params=params,
                timeout=(connect_timeout, read_timeout),
            ) as response:
                response.raise_for_status()
                payload = response.json()
            yield from payload["data"]
            marker = payload["metadata"].get("next_page")
            if marker in (None, "null", ""):
                break
            params["page"] = int(marker)

The page controls follow DailyMed's documented values; the timeout values are deliberately supplied by the caller. The status check follows Requests' documented error handling. This is a documentation-derived example, not evidence of a successful live service traversal. A production wrapper should also retain each response's metadata, constrain response sizes, implement a total job deadline, and reconcile duplicate discoveries. (^[6]) (^[36]) (^[35])

For ZIP acquisition, stream the body into controlled storage while calculating a SHA-256 digest. Python documents that repeated hash updates equal hashing their concatenation. Requests leaves a streamed connection open until the body is consumed or the response is closed, so use a managed response scope. Its normal iteration also decodes HTTP transfer compression; record whether the stored digest represents decoded response bytes or another representation. (^[32]) (^[47]) (^[48]) (^[49]) (^[50])

Parse namespaces and retain section provenance

XML identity depends on namespace URI plus local name. The visible prefix is a placeholder, not the identity itself. ElementTree expands qualified tags using the full namespace URI and accepts a namespace mapping for searches. The parser should therefore locate SPL elements by namespace-aware paths rather than searching for unqualified names that happen to match a particular rendering. (^[8]) (^[51]) (^[52]) (^[53])

For each extracted section, retain:

• Document context: Version key and source digest.
• Section identity: Code, code system, title, hierarchy and occurrence.
• Narrative representation: Original XML subtree plus a searchable text rendering.
• Media context: References and their document locations.
• Parser context: Parser release, extraction configuration and execution time.
• Review context: Extraction errors and unresolved references.

This proposed record structure allows a text renderer to change without overwriting source XML. Section paths, ordering, and retained subtrees give reviewers the evidence needed to evaluate an extraction change. Use namespace-aware search mappings explicitly, so a parser's chosen prefix does not become an accidental dependency of the searchable representation. (^[53])

Inspect packages and configure parsers explicitly

Python warns against extracting archives without prior inspection and notes that zipfile.Path does not sanitize member names. Inspect member paths, enforce locally selected size bounds, and avoid automatic extraction into a shared directory. These are ingestion controls, not claims that any particular DailyMed package is problematic. (^[54]) (^[55])

Configure XML handling explicitly. lxml documents no_network and resolve_entities=False controls, while OWASP recommends disabling document type definitions where possible and restricting external access during validation. Do not enable huge_tree simply to bypass a parsing error: lxml says it disables security restrictions. Pin a reviewed schema locally and record validation outcomes; schema validity establishes structural conformance, not FDA approval or clinical correctness. (^[56]) (^[57]) (^[58]) (^[59]) (^[60]) (^[61]) (^[62])

Change-data capture is a reconciliation design

Change-data capture (CDC) here means detecting changes through repeated public-data observations. It should not imply a publisher-supplied transactional event stream. The proposed process uses an overlapping discovery window and periodic broader reconciliation. A candidate scan is an input to local acceptance checks, rather than an assertion that all desired documents have been acquired. Unique version keys make repeated discovery manageable. (^[34])

A practical state machine separates discovered, acquired, validated, parsed, published, and quarantined. The names are proposed local states. Store raw content first, create immutable version records after identity checks, and expose parsed results only after acceptance checks. A database transaction can make the accepted metadata and its events visible together; PostgreSQL describes an all-or-nothing transaction whose changes remain invisible to other transactions until completion. (^[63]) (^[64])

Suggested processing steps are:

• Discover: Persist candidate identities and scan metadata.
• Acquire: Record URL, response information and stored-file digest.
• Enumerate: Compare publisher-listed history with locally held versions.
• Validate: Check document identifiers, parsing and reviewed schema rules.
• Commit: Insert accepted version, associations and event records together.
• Checkpoint: Advance the scan watermark only after required work commits.
• Reconcile: Revisit incomplete histories, archive observations and missing assets.

Composite uniqueness protects revision identity, and conflict handling can prevent duplicate inserts during replay. However, ON CONFLICT DO NOTHING should follow a digest comparison: silently ignoring a different payload under an existing version key would hide an unresolved discrepancy. Preserve the second observation and send the difference for review. (^[34]) (^[65])

Retry requests without duplicating business events

HTTP defines GET as safe and idempotent with respect to its intended server effect. That does not promise identical response bodies across requests as a label database changes. A retry policy should distinguish retryable transport failures from invalid payloads; honor Retry-After when actually returned, without assuming that DailyMed always supplies that header. The HTTP specification permits either a date or a delay in seconds. (^[66]) (^[67])

A proposed event key combines the lineage, compared revisions, section identity and event class. Database constraints enforce the chosen uniqueness rule; PostgreSQL's conflict handling supports atomic insert-or-update outcomes under its documented conditions. SQLite is a possible local-store alternative: its transaction and UPSERT documentation describe atomic changes and uniqueness-driven conflict handling. Neither engine automatically coordinates an external object store with a database commit. (^[68]) (^[69]) (^[70])

Treat archive transitions as their own evidence

When a retrieval indicates archived status, retain the label and append a status observation. Do not delete the historical document or interpret disappearance from a query as sufficient proof of an archive transition. Current download routes document archived responses, while the history resource documents version enumeration; they support different observations. Missing responses require reconciliation rather than a guessed regulatory explanation. (^[23])

Keep source status, latest observed version, and latest accepted local version separately. The accepted version may lag acquisition because validation has not completed. PostgreSQL rollback semantics support keeping incomplete metadata changes out of accepted views, while append-only acquisition records preserve the evidence needed to diagnose and replay the job. (^[71])

Compare bytes, structure and clinical meaning separately

A source digest detects byte differences. A canonical XML representation addresses some serialization differences, but W3C states that character-content whitespace is retained and that different canonical forms may still be equivalent under application-specific rules. Therefore, a canonical-hash change is not itself a clinically meaningful labeling change. Keep byte comparison, structural comparison, and expert interpretation as separate outputs. (^[32]) (^[72]) (^[9])

Proposed change classes include:

• New revision: Previously unseen publisher-listed version.
• Section addition or removal: A changed coded-section inventory.
• Narrative change: Text differs within a retained section identity.
• Identifier change: A product, package or ingredient association differs.
• Media change: A reference or stored asset digest differs.
• Distribution-state change: A changed active/archive observation.
• Extraction change: A different local parser or rendering produces different output.

A change event should retain both source revisions, comparison configuration, affected location, before/after content references, and review state. The categories are implementation proposals; the rationale for comparing sections is consistent with HL7's description of SPL's comparison benefit. (^[16])

Use section codes as a map, with repeated occurrences retained

The verified extraction map includes LOINC 34067-9, the indications and usage section, and LOINC 34068-7, the dosage and administration section. These codes give a stable way to identify content without relying on capitalization or localized headings. Preserve code system and hierarchy as well as the code; a document may require more precise subsection identification than a flat heading inventory. (^[73]) (^[74])

For safety-label review queues, compare the appropriate sections selected from the reviewed terminology and route changed narrative to a qualified reviewer. The event should say that source labeling text changed, not that a safety conclusion has been established. Preserve the original content; canonicalization must not rewrite namespace prefixes indiscriminately because W3C describes cases where doing so changes meaning. (^[75])

Acceptance tests should protect the lineage

Recommended quality checks are:

• Identity match: Acquired document belongs to the requested version key.
• Required keys: Accepted revisions have non-null, unique identifiers.
• Schema result: Record validator outcome and exact schema revision.
• Parser failure: Quarantine malformed content instead of indexing a partial result.
• Join provenance: Retain external mapping source and acquisition date.
• Media resolution: Flag referenced assets absent from accepted storage.
• Replay behavior: Reprocessing a stored observation does not duplicate events.

The key checks can use database constraints; lxml supplies explicit schema validation and exception-producing assertion methods. OWASP recommends stopping additional processing after fatal XML parsing errors. These controls test the pipeline's acceptance policy, while leaving clinical interpretation to the appropriate review process. (^[37]) (^[76]) (^[77]) (^[78])

Reproducibility also requires configuration checks. OWASP advises treating unsupported security settings as configuration failures. A release should consequently record its actual parser settings and reject a deployment that cannot apply its required controls. This is more reliable than inferring behavior from a library name when documentation or installed versions differ. (^[79])

What was observed, and what was not

The verified quantitative evidence consists of documentation limits and publisher file metadata. The retrieved full-release artifacts and mapping downloads displayed October 5, 2026 modification dates. (^[12]) (^[80]) Those observations establish dated distribution artifacts, not successful downloads, independently counted labels, or a guaranteed release hour. Record the listed file identities and retrieval outcomes separately before calculating operational metrics.

Microsoft's connector publishes 100 API calls per connection in 60 seconds, a connector-specific control. OpenFDA separately documents a 1,000-record maximum per call. These quantities govern different interfaces and cannot be combined into a DailyMed throughput benchmark. No live API benchmark or production ingestion measurement was performed for this report. (^[13]) (^[81])

Table 3 defines proposed local metrics. Their formulas are measurement specifications, not observed numerical results.

Metric	Proposed calculation	Interpretation and evidence boundary
Discovery reconciliation	Accepted discovered version keys / distinct discovered version keys.	Measures the scanned candidate set, not every label ever distributed; enforce distinct keys. ([34])
Historical completeness	Locally acquired listed revisions / publisher-listed revisions for the selected SET IDs.	Scope the denominator to the recorded observation; preserve unique acquired version keys. ([7])
Orphan-join rate	Unmatched mapping edges / evaluated mapping edges.	Keep unmatched edges and reasons; uniqueness checks alone cannot establish association validity. ([82])
Freshness lag	Acceptance timestamp minus comparable source publication timestamp.	Keep dates and timestamps distinct; use timezone-aware acquisition values. ([22])
Version churn	Distinct newly observed version keys / tracked lineages in the observation window.	Define the selected collection and window, using unique accepted keys. ([34])
Replay duplication	Duplicate accepted event keys after replay / events emitted during replay.	A local test of constraints and conflict handling, not a publisher performance statistic. ([82])

These denominators matter more than an unsupported headline percentage. Report the query, observation window, mapping snapshot, accepted-record policy, and excluded records beside any measured result. A zero denominator should produce an undefined metric rather than a fabricated perfect score. For reproducibility, preserve stored bytes and their digest; repeated SHA-256 updates allow hashing streamed content without changing the concatenation's digest. (^[47])

Freshness requires comparable clocks. A date-only effective value cannot support a precise acquisition-lag calculation, while an aware local UTC timestamp can support internal processing-lag measurement. Keep the original source date and record timestamp precision in the measurement definition. Do not subtract the SPL version date from a retrieval time and call the result publication latency. (^[22])

The principal decision is whether the application needs search convenience, original-document evidence, or historical comparison. The proposed interface should expose which representation supports each result, while retaining a reproducible comparison path. Section-by-section analysis provides a useful document-level frame for that requirement. (^[16])

IntuitionLabs describes data-engineering work spanning pipelines, integration, warehousing, and business intelligence. For a labeling program, the relevant recommendation is to make ownership explicit: assign responsibility for acquisition, mapping refresh, accepted-version policy, and expert review. (^[83])

Identifiers also evolve independently of local database design. FDA documents a uniform 12-digit NDC rule taking effect March 7, 2033. As of this report's publication anchor, that is a future effective date. Retaining raw identifiers, their source formats, and versioned normalization rules is a practical way to support future changes without retrospectively rewriting the evidence associated with old documents. (^[84])

A useful rollout can proceed through the following proposed acceptance milestones:

• Acquisition: Reproduce a requested document from stored source evidence.
• Lineage: Retrieve accepted and historical versions by their explicit keys.
• Reconciliation: Explain unmatched identifiers with their mapping snapshots.
• Comparison: Separate byte, narrative and distribution-state changes.
• Operations: Demonstrate replay after interrupted acquisition or commit.
• Review: Trace a retrieved passage to its source revision and extraction configuration.

The milestones rest on explicit keys and transaction semantics, rather than a claimed operational guarantee from the publisher. (^[7]) (^[63])

Finally, public labeling should remain evidence input under appropriate expert review. OpenFDA tells users to assume its API results are unvalidated. (^[85]) A proposed interface should display source boundaries and retrieval dates alongside results, so a convenient search result does not acquire a stronger evidentiary status than its source supports.

A dependable DailyMed pipeline begins with the question a record must answer. SET ID describes a continuing document lineage; a revision and document identifier preserve the specific source. Retrieval observations then explain where the document came from and when it was acquired. The proposed architecture builds on those distinct meanings rather than collapsing every identifier into a single drug row. (^[4])

Implementation should keep raw packages, accepted versions, identifier bridges, parsed sections, media, and reviewable change events connected through explicit keys. Namespace-aware parsing protects element identity, and section comparison supplies a practical unit of analysis. Immutable source bytes allow the team to revisit extraction choices without losing the evidence originally retrieved. (^[8]) (^[16])

The refresh process should be replayable and reconcilable. Database constraints and transactions support consistent accepted records, while acquisition observations preserve incomplete work for recovery. Quality metrics should name their actual denominators and clocks; documentation limits and static examples should never be promoted into unmeasured throughput or completeness claims. (^[34]) (^[63])

For labeling owners and application architects, the resulting design provides a concrete boundary between public-source acquisition and downstream interpretation. It supports searching, comparing, and citing labels while preserving the revision behind each result. Approval assertions and clinical conclusions remain separate decisions supported by the appropriate authoritative evidence and expert review.