AccessGUDID Implant Device Reference — DI Records, Per Record

Turn NLM's AccessGUDID implantable-device list into clean, per-record implant-identifier reference data - one row per device identifier (DI) with brand, labeler company, model and device attributes, ready for hospital procurement and compliance teams to resolve implant identifiers.

Each device in NLM's AccessGUDID implantable-device list becomes one clean, flat record with the boolean normalized to a real boolean, array terms joined to readable strings, a stable record_id (the Device Identifier), and provenance stamped on every row: source, source endpoint, the public-domain notice, attribution, a UTC retrieval timestamp and an interpretation caveat.

What one record represents

The source is the U.S. FDA / National Library of Medicine AccessGUDID database — specifically the implantable-device list endpoint (/api/v2/devices/implantable/list). Each record is one implantable device identifier (DI): its issuing agency, brand name, labeler company, model number, DUNS number, MRI-safety status, whether the labeling indicates natural rubber latex, its GMDN and SNOMED terms, the record status and version, and creation date. This is the reference you use to resolve an implant identifier to its device, brand and company — the job hospital procurement and compliance teams do when reconciling implant logs, purchase orders and recalls against a canonical identifier.

Coverage and volume

The live implantable-device list holds about 1.15 million device identifiers across every implantable-device brand and labeler in the FDA GUDID - that is the record capacity of a full pull.

Live count: 1,147,787 implantable devices (the API's reported totalResults); the Wave-3 index figure of 1,147,750 was captured slightly earlier - the database grows over time. This README states the difference; the capacity line is the live count.

The Actor pages the list API (page / per_page) and stops as soon as your Maximum records cap is met. The API is keyless; the Actor identifies itself with a transparent User-Agent and honours the live robots policy on each run.

Licence and attribution

AccessGUDID / GUDID is provided by FDA and NLM as a U.S. Government resource in the public domain for open use. The full notice travels on every record:

FDA/NLM AccessGUDID (GUDID). U.S. Government work, public domain; the Global Unique Device Identification Database is provided by FDA/NLM for open use. Reproduced verbatim from the AccessGUDID implantable-device list API.

The required attribution — U.S. FDA / National Library of Medicine, AccessGUDID (GUDID) — is present on every record. The developer terms for this endpoint are published by NLM at the implant-list API resource page, which the Actor cites as the usage reference.

Interpretation caveat

One record per implantable device identifier (DI). company_name is the labeler organisation and duns_number its company id; no customer-contact, phone or email field is read. This is the implant-identifier reference, not a clearance/approval or recall feed.

Values are reproduced verbatim from the API: the Actor never rescales, re-derives or editorialises a field. The boolean contains_natural_rubber_latex is normalized to a real true/false/null, and the gmdn_terms / snomed_terms arrays are joined with "; " for flat consumption.

Person-data policy

The implantable-list endpoint carries device x brand x company data only. company_name is the labeler organisation and duns_number is that company's DUNS — neither is a person. There is no customer-contact, phone, email, or personal-address field in the list response, and the Actor enforces that structurally: the field map is a fixed allow-list, and a per-device guard rejects any source object that even contains a contact/person key (verified with a planted-contact test). No natural-person data is processed.

Data quality and freshness

Every run re-reads the live API, so the data is as fresh as AccessGUDID itself, and each record's observed_at stamp records when it was retrieved. Delivery is in the API's list order and keyed on the stable DI, so a capped sample and a later full pull agree on their overlap, and the dataset is safe to diff, deduplicate or upsert into a warehouse. The run's RUN_RECEIPT records the API's reported totalResults alongside how many records were delivered and charged, giving you a per-run reconciliation.

Provenance and compliance

Every run reads the exact host's robots.txt at runtime; the gate result (URL, status, byte length, SHA-256 of the policy) is written to the run's RUN_RECEIPT. The Actor never bypasses a block or fetches through a mirror.

Inputs

• Maximum records (maxRecords) — hard cap on device records delivered and billed. The full implantable list is about 1.15 million devices.

Output

Records land in the Actor's default dataset and export as JSON, CSV, Excel or via the Apify API. A tabular overview view surfaces the DI, brand, company, model, GMDN term, MRI-safety status, latex flag and record status.

Fields in detail

The record leads with record_id and device_id (both the DI), then the identifier and labeler fields (issuing_agency, brand_name, company_name, version_model_number, duns_number, public_record_key, public_version_number, public_version_date), the device attributes (mri_safety_status, contains_natural_rubber_latex, gmdn_terms, snomed_terms), and the lifecycle fields (device_record_status, creation_date). The provenance block closes every record. Because the DI is globally unique, this dataset joins cleanly onto any system that already stores device identifiers.

Scaling and limits

Set Maximum records low to sample the leading devices cheaply, or high to pull the whole implantable list (about 1.15 million devices). The Actor pages the API and delivers incrementally, so memory stays flat regardless of how many records you request, and you are billed only for what is delivered. Because the GUDID grows as labelers publish new devices, a scheduled run keeps a downstream reference table current; each run re-stamps observed_at and records the live totalResults, so you always know how complete and how fresh your snapshot is. For a one-time reference build, a single full run is enough; for ongoing reconciliation, a weekly top-up keeps you aligned with new publications.

Identifier structure

The Device Identifier (DI) is the globally unique key at the centre of this dataset, issued under one of the FDA-accredited agencies named in issuing_agency (GS1, HIBCC or ICCBBA). Because the DI is the same identifier printed on device labels and carried through purchasing, inventory and recall systems, this reference joins directly onto the identifiers your own systems already hold — no fuzzy brand-name matching required. Pair the DI with company_name and duns_number to roll device counts up to the labeler, or with gmdn_terms to group devices by clinical device type.

Sibling Actors

This Actor is the implant-identifier reference. It is distinct from the fleet's device event cells: the fleet-1 accessgudid-device-release-feed is a feed of newly released GUDID records (a delta/watch product), while fda-510k-device-clearances and the fleet-3 fda-device-clearance-records carry 510(k)/PMA clearance and approval events. Reference list versus release feed versus clearance events - three different jobs on the medical-device landscape. This Actor also shares its engineering — the runtime robots gate, push-then-charge billing and verbatim-value discipline — with the fleet's other public-data records Actors.

Pricing

This Actor uses Apify's pay-per-event model: a flat $0.05 per record actually delivered to the dataset, and nothing else — no monthly rental, no per-run base fee, no compute charge. Deliver 40 records and you pay $2.00; deliver 10,000 and you pay $500.00. Billing is wired after delivery — each record is pushed first and only then does the per-record event fire — so a mid-run failure can only ever under-charge you, never over-charge. Use Maximum records to cap spend precisely.

Typical uses

Resolve an implant DI to its device, brand and labeler; reconcile implant logs, purchase orders and recalls against a canonical identifier; screen implantable devices by GMDN term, MRI-safety status or latex flag; build a procurement or compliance reference table; or feed a hospital-supply or device-tracking system with clean implant-identifier records.

What this Actor does not do

It does not deliver clearance/approval events, adverse-event reports, or recalls — those are separate FDA feeds and separate Actors; it is the implant-identifier reference. It does not include any customer-contact or personal data, and it does not alter any published field. It gives you a faithful, public-domain, analysis-ready implant-device reference — one row per DI — with an auditable provenance trail.