# AccessGUDID Implant Device Reference — DI Records, Per Record (`nexgensignal/gudid-implant-device-records`) Actor

FDA/NLM AccessGUDID implantable-device list as clean per-record implant reference - DI, brand, labeler company, model, GMDN term, MRI-safety status and latex flag for ~1.15M devices. No contact data. Public-domain, $0.05 per record.

- **URL**: https://apify.com/nexgensignal/gudid-implant-device-records.md
- **Developed by:** [NexGen Signal](https://apify.com/nexgensignal) (community)
- **Categories:** Business, Developer tools, Other
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $33.50 / 1,000 implant device records

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## 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.

# Actor input Schema

## `maxRecords` (type: `integer`):

Maximum implantable-device records delivered and billed. You are billed only for records delivered. The full implantable list is ~1.15M devices.

## Actor input object example

```json
{
  "maxRecords": 500
}
```

# Actor output Schema

## `results` (type: `string`):

The delivered AccessGUDID implant device record.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "maxRecords": 500
};

// Run the Actor and wait for it to finish
const run = await client.actor("nexgensignal/gudid-implant-device-records").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "maxRecords": 500 }

# Run the Actor and wait for it to finish
run = client.actor("nexgensignal/gudid-implant-device-records").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "maxRecords": 500
}' |
apify call nexgensignal/gudid-implant-device-records --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,nexgensignal/gudid-implant-device-records"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/fIra7noE5dY1IW0af/builds/ybspjpgByhRkzuJMw/openapi.json