Tomonoshin Aoki

Comment on Docket No. FDA-2026-N-7874

Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request for Feedback

Submitted via Regulations.gov

October 2026

Tomonoshin Aoki

Innovation Management and Policy Program, Hitotsubashi University, 2-1 Naka, Kunitachi, Tokyo 186-8601, Japan

ba249801@g.hit-u.ac.jp

ORCID: 0009-0008-4943-6557

The views expressed in this comment are my own and do not represent the position of Hitotsubashi University.

Why this matters
A medical device may use a foundation model supplied by another company, and several devices from different manufacturers may use the same one. If that shared model changes or develops a safety problem, the same fault could surface as separate incidents across those devices. Today FDA can receive reports about each device, but its public device-surveillance records provide no structured way to ask a basic cross-product question: which authorized devices use this model version, and what adverse events have been reported for them? The public records are indexed by product, not by the shared model.
FDA therefore needs two capabilities in addition to better reporting: it must be able to identify the configuration that produced each monitoring result, and to link devices that use the same upstream model. The immediate step is administrative: give the upstream model a structured identifier in FDA’s device records, starting with the AI-Enabled Medical Devices List. The next step is to make that identifier reachable from adverse event records. A commitment registry is one possible longer-term mechanism for making identity and lineage independently verifiable; it is proposed here as a pilot, not as a prerequisite. The recommendations in Section IX are ordered on that basis: immediate, near-term, pilot.

Summary of responses by question

Questions 18–26 are addressed. Sections III–VIII give the responses; Section IX lists the recommendations (R1–R7) in three tiers — immediate, near term, pilot; Appendix A reports the field inventories cited in Section II, and Attachment B and the public repository [18] carry the full computed outputs, reported in an accompanying manuscript under peer review [17].

Responses by question (response — section of the attached comment — recommendations):
Q18 — Reduced premarket evidence can be justified only where the configuration monitored is verifiably the configuration evaluated, and where the units the agency would act on are retrievable from its databases. — Section III — R1, R4
Q19 — Bind each monitoring artifact to a persistent, machine-verifiable identifier of the configuration that produced it (a cryptographic commitment is one implementation); a change of identifier is detected and classified against the change envelope, and reassessment follows only outside it. — Section VII — R1
Q20 — Registration identifies a supervisory agent but does not show that it performs well; the agent needs its own evaluation, and it is itself a shared upstream dependency. — Section VII — R1, R6
Q21 — A commitment registry allocates roles — sponsor declares, provider attests, agency verifies, institutions check — without diffusing accountability. — Section VII — R6
Q22 — Per-element commitments identify which component changed and let re-benchmarking scope be prespecified per element. — Section VI — R5
Q23 — Define the PCCP envelope by rules for admissible configurations rather than by a list; runtime verification then checks membership automatically, while safety remains the modification protocol’s job. — Section VI — R5
Q24 — Provider version attestations plus runtime binding make an unannounced model change either a detectable mismatch or a false attestation. — Section IV — R2, R7
Q25 — Key each Foundation Model MAF to a stable model-version identifier; a commitment registry is one minimal-disclosure implementation of the lineage index, and two administrative steps precede it. — Section V — R3, R4, R6
Q26 — Tools and external actions enter the manifest as additional elements; an orchestrating agent shared across deployments is an upstream component; traceability complements evaluation of whole action sequences. — Section VIII — R5, R6

[The full comment (Sections I–XI, References, Appendix A) is provided as an attached PDF; the computed outputs are provided as Attachment B (XLSX).]

Disclosure: The author is the inventor and applicant of a pending Japanese patent application (No. 2026-211413) that relates to the commitment-based mechanisms described in the attached comment, including the Configuration Commitment Registry (R6); the administrative step of R4 does not depend on them. Details are given under Disclosures in the attached PDF.

Comment on Docket No. FDA-2026-N-7874
Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper
and Request for Feedback
Submitted via Regulations.gov
October 2026
Tomonoshin Aoki
Innovation Management and Policy Program, Hitotsubashi University, 2-1 Naka, Kunitachi, Tokyo
186-8601, Japan
ba249801@g.hit-u.ac.jp
ORCID: 0009-0008-4943-6557
The views expressed in this comment are my own and do not represent the position of Hitotsubashi
University.

Why this matters
A medical device may use a foundation model supplied by another company, and several devices
from different manufacturers may use the same one. If that shared model changes or develops a
safety problem, the same fault could surface as separate incidents across those devices. Today FDA
can receive reports about each device, but its public device-surveillance records provide no structured
way to ask a basic cross-product question: which authorized devices use this model version, and what
adverse events have been reported for them? The public records are indexed by product, not by the
shared model.
FDA therefore needs two capabilities in addition to better reporting: it must be able to identify the
configuration that produced each monitoring result, and to link devices that use the same upstream
model. The immediate step is administrative: give the upstream model a structured identifier in FDA’s
device records, starting with the AI-Enabled Medical Devices List. The next step is to make that
identifier reachable from adverse event records. A commitment registry is one possible longer-term
mechanism for making identity and lineage independently verifiable; it is proposed here as a pilot, not
as a prerequisite. The recommendations in Section IX are ordered on that basis: immediate, nearterm, pilot.

Summary of responses by question
Questions 18–26 are addressed. Sections III–VIII give the responses; Section IX lists the
recommendations (R1–R7) in three tiers — immediate, near term, pilot; Appendix A reports the field
inventories cited in Section II, and Attachment B and the public repository [18] carry the full computed
outputs, reported in an accompanying manuscript under peer review [17].

Question Response Section Rec.

18 Reduced premarket evidence can be justified only where the configuration III R1, R4
monitored is verifiably the configuration evaluated, and where the units the
agency would act on are retrievable from its databases.

19 Bind each monitoring artifact to a persistent, machine-verifiable identifier of VII R1

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 1
Question Response Section Rec.

the configuration that produced it (a cryptographic commitment is one
implementation); a change of identifier is detected and classified against the
change envelope, and reassessment follows only outside it.

20 Registration identifies a supervisory agent but does not show that it performs VII R1, R6
well; the agent needs its own evaluation, and it is itself a shared upstream
dependency.

21 A commitment registry allocates roles — sponsor declares, provider attests, VII R6
agency verifies, institutions check — without diffusing accountability.

22 Per-element commitments identify which component changed and let re- VI R5
benchmarking scope be prespecified per element.

23 Define the PCCP envelope by rules for admissible configurations rather than by VI R5
a list; runtime verification then checks membership automatically, while safety
remains the modification protocol's job.

24 Provider version attestations plus runtime binding make an unannounced IV R2, R7
model change either a detectable mismatch or a false attestation.

25 Key each Foundation Model MAF to a stable model-version identifier; a V R3, R4, R6
commitment registry is one minimal-disclosure implementation of the lineage
index, and two administrative steps precede it.

26 Tools and external actions enter the manifest as additional elements; an VIII R5, R6
orchestrating agent shared across deployments is an upstream component;
traceability complements evaluation of whole action sequences.

I. Introduction and Summary
I am a researcher in innovation management and regulatory policy at Hitotsubashi University, Tokyo. My
research focuses on a practical question: can a regulator's databases retrieve the same units that its
policies are designed to oversee? I refer to this as visibility engineering [1]. This comment responds to
Questions 18–26, principally 24 and 25.
The discussion paper names the problem in its own words. Many GenAI-enabled devices are built on
third-party foundation models; the agency has “limited visibility into underlying third-party foundation
models”; and it is “difficult to attribute specific behaviors and errors to the device or its underlying
model” (Section II). The paper then asks whether greater premarket uncertainty could be accepted in
exchange for greater reliance on postmarket monitoring (Question 18). Greater reliance on postmarket
monitoring is useful only if that monitoring provides information that premarket review cannot.
Every mechanism in Sections VI and VII — periodic re-benchmarking, sample-based clinician review,
performance degradation monitoring, PCCPs, and the Foundation Model MAF — changes what is
reported or reviewed. None changes what the agency's databases can retrieve. Two gaps therefore stay
open. Identity: no party other than the sponsor can establish which configuration produced a monitored
output. Lineage: FDA's public records do not allow the agency or an external user to enumerate which
authorized devices depend on a given foundation-model version.

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 2
This comment proposes, first, two administrative steps that require no new program: an upstreammodel field in the AI-Enabled Medical Devices List, and a model-lineage element in adverse event
reporting for GenAI-enabled devices — optional at first, with its completeness monitored — so that
FDA's databases can link devices to the models they share. For the longer term it proposes one
mechanism that makes both identity and lineage independently verifiable at low content-disclosure
burden: a Configuration Commitment Registry, in which each deployed configuration is represented by
a cryptographic commitment — a short fingerprint that identifies the configuration without revealing its
contents — and dependencies among commitments are recorded as signed relations. The mechanism is
specified in a companion technical paper accepted for presentation at Blockchain Kaigi 2026 [10], and
the author has a pending patent application on it (see Disclosures); further technical detail is available
on request. Section IX lists seven recommendations in three tiers, mapped to the questions.

II. Two Gaps, Two Layers, and What the Public Files Show
Identity. The postmarket approaches in Section VI.A rely on the sponsor to identify the configuration
that generated each monitoring result. The issue is independent verification, not whether sponsors
report in good faith. An authorization is a judgment about one configuration — the paper states that the
evaluated object is “the final user-facing device, as configured and intended to be deployed” (Section
V.A) — and that judgment carries over to the postmarket period only if the configuration running is the
configuration evaluated. The discussion paper defines the configuration evaluated before marketing, but
it does not specify how FDA or another party could verify that the same configuration generated later
monitoring data. The sponsor may know which configuration ran; the current mechanisms give no other
party a way to verify it.
Lineage. A defect inherited from a shared foundation model surfaces downstream as unrelated incidents
across manufacturers, because adverse event records index by product and no field records which
devices share a model. The first systematic audit of AI-device surveillance found that changes such as
training-data updates have no reporting channel in MAUDE and proposed flags for them; it also named
what stakeholders need to know — “what genealogical changes relevant to its safety have since
occurred” — but did not examine how such a genealogy could be queried across devices [2]. Neither the
agency nor an external user can answer, for the population of authorized devices, “which depend on
model X, version Y”: a provider knows its API customers, but not which authorized devices and versions
they deploy in regulated configurations, and the agency cannot query a provider's customer list.
Separately, public FDA records provide no way to enumerate the authorized devices that share a given
model version.
Two layers. Reporting rules specify what sponsors must provide; database schemas determine what FDA
can retrieve. I refer to these as the categorical and the infrastructural layer [1, 3]. Reporting
requirements, master files, change control plans, and monitoring cadences belong to the first; retrieval
belongs to the second. Cross-product visibility has three conditions at the second layer: a structured key
for the shared component, a signal definition stated over that key before events occur, and a scheduled
review that consumes aggregates keyed to it. A mechanism closes the lineage gap if and only if it
introduces or requires such a key that can be reached from postmarket event records — carried in the
record itself or reached from it through documented joins on structured keys with fixed semantics; a key
held only in a premarket dossier does not qualify.
What the public files show. The agency can settle the second layer from its own layouts, and the public
files, as downloaded on 30 August–2 September 2026, already answer part of the question (Appendix
A). Three findings matter here. First, across the 43 fields of the three files as analyzed in [2] — the MDR

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 3
master extract (15 fields), the 510(k) releasable database (22), and the AI-Enabled Medical Devices List
(6 columns) — the count of structured upstream-component identifiers is zero, and the full 86-field MDR
master export adds none. The structured fields name the report, the marketed article, the device type,
or the submission, and the list page itself states that the agency “will explore methods to identify and
tag medical devices that incorporate foundation models” [16]. Second, a software version can be
recorded only indirectly: FDA's definition of “lot or batch” includes devices of a single “software version”
(21 CFR 801.3) [14], and stand-alone software conveys its version number in the UDI production
identifier (21 CFR 801.50(a)) [15]. Among the 943 reports on AI-enabled devices analyzed in [2], versionlike strings appear in 137 (14.5%), spread across four different fields chosen by the reporter, none of
which a query can select (the detection is heuristic; the matched strings are deposited with Attachment
B). Third, even the premarket submission number — the one key that the event record and the device
identification database both hold — does not refer consistently to the same clearance: for the 943
reports, the two systems carry different 510(k) numbers for the same device identifier in 10 of the 21
cases where both are populated, because a submission number names one clearance in a device family's
succession of clearances. Field-by-field counts are given in Appendix A and Attachment B. The audit is
reported in full — with its codebook and a positive control, a vaccine surveillance system known to
aggregate across products that share a technology — in an accompanying manuscript under peer review
[17]; the codebook, recorded classifications, scripts, and outputs are deposited in the public repository
[18]. Figure 1 draws the documented join graph (a) and the two administrative steps proposed in
Section IX (b).
A completed precedent. The same problem arose for conventional software components and was
resolved. When the URGENT/11 vulnerabilities surfaced in IPnet, a network stack embedded across
manufacturers' devices, the agency's safety communication stated that it was “not aware of any
confirmed adverse events related to these vulnerabilities” while noting that “software to exploit these
vulnerabilities is already publicly available” [4]. Log4Shell then showed the cost of having no inventory:
the Cyber Safety Review Board's review found that the absence of any inventory of where the
component was integrated hindered response, and it recommended software bills of materials among
its measures [5]; organizations that held bills of materials identified the vulnerable component in hours,
against weeks for those that did not [13]. Premarket acceptance of cyber devices is now conditioned on
an SBOM under section 524B of the FD&C Act [6]. The SBOM requirement created a structured
inventory of software components and placed the obligation on the regulated manufacturer, who
obtains component identifiers from suppliers that are not themselves regulated. Machine-learning bills
of materials have offered the same kind of inventory for models since 2023 [7]. The analogy to section
524B is organizational — it shows where an obligation to obtain component identifiers can attach — and
not a claim that section 524B itself supplies authority for model-lineage requirements; whether each
step proposed below lies within existing authority is a question the discussion paper reserves, and this
comment does not resolve it. What follows describes the identifier scheme in its queryable form.

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 4
Figure 1. What the public files show. (a) Systems as boxes, documented structured join keys as solid arrows, unstructured
references as dashed grey arrows. Every structured path from an adverse event record ends at a box with a heavy border — the
submission, the marketed article, or the device type — and the upstream model (dashed, orange) is a node that no system
holds. Percentages give the share of records that can make a hop: the submission number is present in valid format in 75.1% of
2013–2023 master records; the UDI device identifier in 47.3% of the 943 reports on AI-enabled devices analyzed in [2]; the
GUDID submission number is present for 21 of 38 resolved identifiers and differs from the event record’s number for 10 of
them. (b) The two administrative steps of R4 (green, dashed): (1) an upstream-model field in the AI-Enabled Medical Devices
List makes lineage queryable across the devices the list covers; the existing submission-number join then gives conditional
traversal only; (2) a model-lineage element in the adverse event record lets reports pool on a shared model; (3) model-card
disclosures and any master file keyed to the same identifier become indexed entries. Drawn from the outputs deposited in [18];
join keys taken from public layout documentation.

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 5
III. Question 18 — Conditions Under Which Postmarket Monitoring Can Carry
Premarket Weight
Question 18 asks what characteristics of a monitoring program would need to be in place to justify
reduced premarket evidence. Two are necessary. First, FDA must be able to verify which configuration
produced each monitoring result: a benchmark result, a clinician-review sample, or a degradation metric
attests to a configuration only if the configuration can be named and a party other than the sponsor can
check that the named configuration is the one running. Second, the units on which the agency would act
must be retrievable from its databases; for devices built on shared foundation models, that includes the
model version as a cross-product key. Without the first, greater postmarket reliance rests on evidence
that only the sponsor can vouch for; without the second, the devices most in need of pooling — those
whose per-device event counts are too sparse to signal — cannot be pooled. A device whose monitoring
program lacks both should not qualify for reduced premarket evidence, wherever it sits in the risk
framework of Section IV.

IV. Question 24 — Detecting, Evaluating, and Responding to Third-Party Model
Changes
Question 24 asks how a manufacturer can detect, evaluate, and respond to changes initiated by a thirdparty model developer, and what mechanisms — contractual, technical, or through a PCCP — could
provide reasonable assurance. Contracts bind two parties but are invisible to the regulator: they can
require notification, but a breach of a notification clause leaves no trace that the regulator can see. The
technical mechanism that makes such changes visible is runtime configuration binding against a
registered commitment:
• The model provider publishes, for each released version, a commitment to that version, and
authenticates the running version at inference time — by signing its API responses with the
version identifier, or by an equivalent verifiable binding such as a signed session manifest or an
attestation endpoint (a version attestation).
• The device manufacturer registers a commitment to its deployed configuration, of which the
provider's model commitment is one element.
• At inference time, the device verifies the version attestation against the registered commitment,
and each monitoring artifact carries the commitment of the configuration that produced it.
With this arrangement, an unannounced model change would either produce a detectable mismatch or
require the provider to make a false attestation. Detection requires no disclosure by the provider
beyond a fingerprint and a signature. The guarantee has a limit: a signature attributes a claim about the
serving version to the provider and makes the claim non-repudiable, but it does not by itself prove that
the executed model is the version claimed. A false attestation, or a change made within a version the
provider continues to sign, would surface only through independent means — reference-output checks
against the committed version, audits, or attested execution — which is why R7 grades assurance rather
than treating a signature as proof of execution.
The level of assurance can vary according to who controls each element. Elements the sponsor holds —
prompts, retrieval configuration, guardrails, orchestration, interface — need only signed declarations.
API-served models need provider attestations as above. Where a model developer can support it, zeroknowledge proof techniques allow a stronger grade — proving that a committed model achieves a
committed evaluation result without revealing the model [8] — but current demonstrations sit below
frontier foundation-model scale, and proofs of fine-tuning derivations remain limited to parameterAoki — Comment on Docket No. FDA-2026-N-7874 — page 6
efficient methods [9]. Zero-knowledge proofs could provide a higher assurance tier in the future, but
they should not be required for initial implementation. Identity is thus established where the weights
reside — by the sponsor for locally executed models, by the provider for served ones — and attested
across the API boundary between them.
Evaluation and response follow from detection. Because the registered manifest commits to each
element separately, a detected change localizes to an element (Section VI), and a change that leaves the
sponsor's prespecified envelope can be treated as a hold-or-rollback condition on the day it appears. As
with section 524B, the obligation to obtain attestations would attach to the sponsor, who would procure
from providers able to supply them; a provider unwilling to attest its versions would be visible as such in
premarket review.

V. Question 25 — The Foundation Model MAF and a Complementary Registry
Question 25 asks whether voluntary Foundation Model MAFs would be practical, notes that developers
may have limited incentive to disclose safety-relevant information, and asks whether alternative
mechanisms exist. As described in Section VII.A, the MAF has three attributes that limit what it can do
for the lineage gap, whatever its value for review depth: it is voluntary; it is confidential and
authorization-gated, so shared dependency remains invisible in aggregate; and it is a reference channel
attached to individual submissions rather than an index. A master file has a file number that a
submission can reference, but it stops short of cross-product retrieval: no one can query which
authorized devices reference the same file, and no documented join reaches the file from a postmarket
record. Nor is a file number, as described, a model-version identifier: it names a dossier, which may
describe several versions, so it supplies a structured reference but not, by itself, a component identifier.
Referenceability is not component identity, and neither is surveillance queryability.
The MAF also raises an incentive problem, because participation is voluntary and disclosure is costly; a
commitment-based mechanism reduces that cost. A properly randomized commitment reveals nothing
about what it identifies — not weights, architecture, training data, or evaluation results — while any
change to any element yields a different commitment [10]. (A bare hash of a short prompt would lack
the first property; commitments must be salted.) What a registry does disclose, to the agency, is the
dependency relation itself — that device D incorporates model M at version V — and that relation is
what surveillance needs. Because dependency structure can be commercially sensitive, who may run
which query is part of the design: the natural default is that conformity lookups are open to the parties
to a configuration and lineage traversals are the agency's.
The alternative mechanism I ask CDRH to consider is the Configuration Commitment Registry. The
proposed registry uses two tables: a node table keyed on commitments (device configurations and
model versions), and an edge table of signed relations among them — composed_of, derived_from,
quantized_from. The registry supports two main functions: conformity — does this run's manifest lie in
the authorized set — and surveillance — ascend from a device to its model ancestor and descend to all
registered descendants, a single recursive query that returns affected devices across manufacturers. The
manifest's six elements — model, prompts, retrieval, guardrails, orchestration logic, user interface —
are the paper's own enumeration of what can change in a GenAI-enabled device (Section II).
The registry and the MAF are complements. The MAF could continue to hold detailed confidential
information for review teams, while the registry would contain only the identifiers needed for crossproduct queries. An MAF should in any case be keyed to a stable identifier of the model version(s) it
describes; where a registry is piloted, that identifier maps to a registered commitment, and the “update

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 7
notification commitments” and “audit log availability” contemplated in footnote 24 are naturally
implemented as version attestations against it.
The registry would also need an auditable history. It must be append-only with independently verifiable
history, because a commitment fixes what was registered but not when: an operator able to insert
entries retroactively could not distinguish a configuration declared before an adverse event from one
declared after. Transparency logs whose inclusion and consistency any party can verify without trusting
the operator are standard engineering (Certificate Transparency [11]). And because writers must be
legally identified for non-repudiation, and the parties motivated to audit the log — sponsors, providers,
the agency — are an enrolled set, a permissioned implementation is the natural fit. FDA would not need
to host or inspect the model itself; its technical role could focus on verifying identifiers, signatures, and
registry integrity, and it would not receive model weights or patient data. The registry need not be an
agency system; the consortia and standards bodies named in Section VI.B can operate it with CDRH as
verifier, and the manifest format can build on an existing machine-readable specification [7] that CDRH
could recognize as a consensus standard.

VI. Questions 22 and 23 — Categories of Change, and Prespecification Without
Enumeration
Question 22 asks how the extent of re-benchmarking might be scaled to the nature of a modification
and whether categories of change can be distinguished. A manifest that commits to each element
separately makes the category machine-identifiable: a modification that changes the interface
commitment and nothing else is a different category from one that changes the model commitment,
and the difference between the registered manifest and the running one names the category without
relying on the sponsor's characterization of it. Re-benchmarking scope can then be prespecified per
element — which benchmarking elements of Section V.B a change to prompts or guardrails re-triggers,
and which a model change re-triggers in full.
Question 23 asks how PCCP concepts might be adapted when the nature or scope of future
modifications cannot be fully prespecified. A PCCP need not list every future configuration individually. It
could instead define rules for which configurations are allowed — for example, “any configuration
whose model element is a version attested by provider P as derived from committed base B, with
guardrail and orchestration elements unchanged.” A configuration that satisfies those rules would still
need the re-benchmarking specified in the modification protocol, with the results bound to that
configuration's commitment. Runtime binding would then let the sponsor determine automatically
whether the deployed configuration falls within the approved set.

VII. Questions 19, 20, and 21 — Monitoring the Referent, Supervisory Agents, and
Shared Responsibility
On Question 19: the approaches in Section VI.A evaluate performance; none verifies which configuration
was evaluated. I ask CDRH to treat configuration identity as a cross-cutting layer beneath them. Each
monitoring artifact — a benchmark run, a clinician-review sample, a degradation metric — should carry
a persistent, machine-verifiable identifier of the configuration that produced it (a cryptographic
commitment is one implementation), consistent with the paper's intent that initial benchmarking serve
as the reference against which later changes are evaluated (Section V.B.2). Triggering events become
machine-detectable and classifiable: a change of identifier is detected and classified against the
authorized change envelope, and only a change outside the envelope, or within a prespecified safetyrelevant category, need trigger the re-benchmarking or reassessment the Section VI.A cadence language

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 8
contemplates (Section VI). And events too sparse per product can pool on a shared model ancestor,
enabling the cross-product signal detection that per-product indexing cannot provide.
On Question 20: a machine-based supervisory agent is a configuration like any other and should be
committed and indexed like any other. The supervisory agent itself needs a configuration identifier;
otherwise the monitoring system would reproduce the same identity problem one level higher.
Registration identifies the agent but does not show that the agent performs well. It does make one thing
visible that per-device monitoring cannot: a supervisory agent that monitors many devices is itself a
shared upstream dependency, and its defect would propagate across every device it monitors. Such
agents belong in the same edge table, as ancestors. Identity does not settle the agent's reliability, which
the question also raises. A supervisory agent should be evaluated like the function it performs: for its
sensitivity to the failures it is meant to detect, its false-alarm rate, and when it escalates to human
review. Its evaluation results, like any other monitoring evidence, should carry the identifier of the agent
version evaluated, so that a later change to the agent is itself detected.
On Question 21: a commitment registry allocates roles without diffusing accountability. The sponsor
declares its configuration and remains accountable for the device. The provider attests versions and is
accountable for its attestations. The agency verifies the attestations and runs the queries. Healthcare
institutions can check that the configuration they run is the one authorized, and the model-card
disclosures that certified health IT already carries under the ONC HTI-1 rule [12] could be keyed to the
same commitments, so that a local disclosure and a federal record name the same object. No role here
transfers the manufacturer's responsibility; each adds a party who can verify a claim that today only the
manufacturer can make.

VIII. Question 26 — Agentic Systems
Agentic devices extend the manifest. Tools, external actions, and the policies that gate them are
elements a sponsor holds and can commit to; the paper's own list of what can change (Section II) gains a
seventh entry. Where an agentic system's action sequences control another device, the controlled
device's configuration is a dependency and belongs in the edge table. The supervisory-agent point
applies with more force: an orchestrating agent shared across deployments is an upstream component,
and FDA should be able to identify all of the devices that use it before a safety problem occurs.
Configuration traceability complements, and does not replace, task-level evaluation. Benchmarking
element A.1 already names the behaviors to test, including accurate tool use, recognition of erroneous
tool outputs, and compliance with human-oversight checkpoints before irreversible or highconsequence actions (Appendix A of the discussion paper). The added risk of autonomous multi-step
action is best reflected in acceptance criteria by evaluating whole action sequences rather than single
steps, because an early error can propagate through later actions, and by setting thresholds in
proportion to the device's autonomy and the clinical consequences of its actions.

IX. Recommendations
Listed in three tiers by what each requires. Immediate and administrative, requiring no new program:
the first step of R4. Near term, through guidance or stated expectations: R1, R2, R3, R5, and the second
step of R4. Pilot and evaluation: R6, with the tiered assurance of R7. Whether a step lies within existing
authority is not asserted here; the discussion paper reserves that question, and the analogy to section
524B is organizational rather than legal. The table below lists the seven recommendations by tier; the
text that follows gives each in full.

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 9
Recommendations at a glance
Tier Rec. What it asks Instrument

Immediate — R4, step Add an “upstream foundation model” field (a version identifier List administration
administrative, 1 or registered commitment) to the AI-Enabled Medical Devices
no new program List, turning the planned tag into a key.

Near term — R1 Bind monitoring evidence to a persistent, machine-verifiable Postmarket monitoring
guidance or identifier of the deployed configuration (a cryptographic guidance
stated commitment is one implementation); classify a change of
expectations identifier against the change envelope.

R2 Expect providers of API-served models to supply per-version Guidance; premarket
commitments and authenticated runtime version metadata; expectations
the obligation to obtain them attaches to the sponsor.

R3 Key each Foundation Model MAF to a stable identifier of the MAF program design
model version(s) it describes, mappable to a registered
commitment if a registry is piloted.

R4, step Add a model-lineage element to device adverse event MDR data elements as
2 reporting — optional at first with completeness monitored; they migrate into AEMS
required where it serves as a basis for cross-product
surveillance.

R5 Express PCCP change envelopes as admissible sets of PCCP adaptation
configuration manifests, with re-benchmarking scope
prespecified per element.

Pilot and R6 Pilot a Configuration Commitment Registry with prespecified Consortium or
evaluation outcomes (time to enumerate, sensitivity of enumeration, standards body; CDRH
false-match rate, update latency, burden, participation) and as verifier
measured operating costs, against a conventional identifier
database as comparator.

R7 Tiered assurance for configuration identity: signed sponsor Guidance
declaration, provider version attestation, cryptographic
evaluation proof as an optional top grade.

R1 (Questions 18, 19, 20). In any future guidance on postmarket monitoring of GenAI-enabled devices,
provide that monitoring evidence be bound to a persistent, machine-verifiable identifier of the deployed
configuration that produced it — a cryptographic commitment is one implementation — and treat a
change of that identifier as a detection event to be classified against the authorized or PCCP change
envelope; only changes outside the envelope, or within prespecified safety-relevant categories, would
trigger re-benchmarking or regulatory reassessment.
R2 (Question 24). For devices built on API-served foundation models, establish the expectation that the
provider supplies per-version commitments and cryptographically authenticated runtime version
metadata — through per-response signatures or an equivalent verifiable binding mechanism — with the
obligation to obtain them attaching to the sponsor, as section 524B attaches the SBOM obligation to the
manufacturer.

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 10
R3 (Question 25). If a Foundation Model MAF program is established, key each MAF to a stable identifier
of the model version(s) it describes — one that can, if a commitment registry is piloted, be mapped to a
registered commitment — and implement the update-notification commitments of footnote 24 as
version attestations against that identifier.
R4 (Question 25; lineage). Add an “upstream foundation model” field — a version identifier or
registered commitment — to the AI-Enabled Medical Devices List. The list carries no such field today,
and CDRH has stated that it “will explore methods to identify and tag medical devices that incorporate
foundation models” and intends to identify devices incorporating LLM-based functionality in a future
update of the list [16]. A yes/no tag would not identify the model or its version; the proposed field
would. The step is administrative. Because the list is not a comprehensive resource of AI-enabled
devices [16], the field would make the lineage relation queryable only for the devices the list covers, and
only as completely as it is populated: from submissions for new authorizations, and retrospectively
where public summaries name the model. The field should identify the provider, the model, and the
version separately, allow more than one entry where a device combines models, and record a version
that is not disclosed as undisclosed rather than leave the field blank. Then add a model-lineage element
to device adverse event reporting — the MDR data elements as they migrate into the FDA Adverse
Event Monitoring System — so that reports can pool on a shared ancestor without disclosure of model
weights, training data, prompts, or other model contents. The element can be optional during a pilot,
with its completeness monitored. If it is to serve as a basis for cross-product safety surveillance,
standardized reporting should ultimately be required where applicable, because an incompletely
populated key reproduces the retrieval gap it is meant to close; the premarket submission number,
present in valid format in 75.1% of 2013–2023 reports, is the measure of that risk. The dependency
relation itself can be commercially sensitive, so access to lineage queries should be a stated design
choice.
R5 (Questions 22, 23, 26). In adapting PCCP concepts, permit change envelopes to be expressed as
admissible sets of configuration manifests, with re-benchmarking scope prespecified per element and
runtime binding as the conformity check. Identifying the changed element does not by itself establish
the clinical significance of a change; that remains a matter for the modification protocol's risk-based
rules.
R6 (Questions 20, 21, 25). Pilot a Configuration Commitment Registry with a small cohort of sponsors
and at least one foundation-model provider, operated by a consortium or standards body with CDRH as
verifier; evaluate the conformity and surveillance queries in enumeration drills of the Log4Shell type
(simulated cross-product incidents) with outcomes prespecified before the pilot — time to enumerate
affected devices, sensitivity (completeness) of affected-device enumeration, false-match rate, versionupdate latency, administrative burden on sponsors and the agency, and provider participation rate.
Compare the registry with a conventional identifier database holding the same dependency relations, so
that the pilot measures what signed relations and an append-only log add to retrieval (attributable
claims, tamper evidence, and independent auditability) and whether that addition justifies its cost.
Consider recognizing a machine-readable manifest specification as a consensus standard. Operating
costs — key management, provider integration, and administration — are not zero and should be
measured in the same pilot.
R7 (Question 24). Establish a tiered assurance framework for configuration identity — signed sponsor
declaration, provider version attestation, and cryptographic evaluation proof as an optional top grade
rather than an entry requirement — so that assurance scales with what each party can support today.

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 11
X. Limitations of the Proposal
This proposal has six limitations. First, no adverse event has yet been attributed across products to a
shared foundation model, no reporting field records one, and few, if any, GenAI-enabled devices have
yet been authorized; the claim is the absence of a detection mechanism, not the presence of the hazard.
Second, a registry covers only the parties that register; whether registration is expected or required is a
regulatory choice, not a technical one, which is why the mechanism is offered to this docket. Third, the
registry supplies the key, not the definition of platform-class safety signals or the review process that
uses them; those remain the agency's scientific work, and the key has little value without them. Fourth,
where reference is by approximation — a quantized deployment of a committed base — a measurable
residual remains, boundable as a decision-flip rate on held-out cases and treatable as graded assurance
rather than as defect. Fifth, the registry would identify the configuration being evaluated, but it would
not establish that the configuration is safe or effective. Sixth, a lineage key makes a cross-product signal
findable, not interpretable on its own: adverse event reports lack exposure denominators, are underreported, and come from devices with different intended uses, so pooled reports support signal
detection but not estimates of incidence or causation. The inventories in Appendix A describe public
files; internal systems may differ, and the agency can settle the question from its own layouts.

XI. Closing
The discussion paper asks, in effect, how postmarket evidence can be made trustworthy enough to
justify premarket flexibility. One part of the answer is straightforward: FDA needs a stable identifier that
links monitoring records to the configurations and shared models they concern, and that identifier can
be provided at low content-disclosure burden to model developers. I would welcome the opportunity to
provide further technical detail.

Disclosures
This work received no external funding. The author is the inventor and applicant of Japanese Patent
Application No. 2026-211413 (filed 25 September 2026; pending), which relates to the commitmentbased mechanisms described in this comment, including the Configuration Commitment Registry
proposed in R6; the application covers mechanisms for committing to and verifying the composition of
deployed software and product configurations and the dependencies between them, and for recording
and sharing safety knowledge across products that share a component. The administrative step of R4, an
upstream-model field in the AI-Enabled Medical Devices List, does not depend on these mechanisms.
From 2019 to 2025, the author was an official of the Ministry of Health, Labour and Welfare of Japan;
the views expressed are the author's own. The author declares no other competing interests. Claude
(Anthropic) was used to assist in drafting the text, to extract field lists and verbatim quotations from the
audited documents and apply the audit codebook's classification rules to them, to verify quotations and
bibliographic details against primary sources, and to write and execute analysis scripts; ChatGPT
(OpenAI) was used to generate critical reviews of drafts. The author takes full responsibility for the
content. No AI tool is an author.

References
[1] T. Aoki. Platform regulation as visibility engineering. In Proc. 60th Hawaii International Conference on System
Sciences (HICSS-60), 2027. In press.
[2] B. Babic, I. G. Cohen, A. D. Stern, Y. Li, and M. Ouellet. A general framework for governing marketed AI/ML
medical devices. npj Digital Medicine, 8:328, 2025.
[3] G. C. Bowker and S. L. Star. Sorting Things Out: Classification and Its Consequences. MIT Press, 1999.

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 12
[4] U.S. Food and Drug Administration. URGENT/11 cybersecurity vulnerabilities in a widely-used third-party
software component may introduce risks during use of certain medical devices: FDA safety communication.
October 1, 2019.
[5] Cyber Safety Review Board, U.S. Department of Homeland Security. Review of the December 2021 Log4j Event.
July 11, 2022. https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-112022_508.pdf (inventory finding: Executive Summary, p. iv, and Section 2.3, p. 13; SBOM
recommendation: Recommendation 12, p. 25).
[6] Federal Food, Drug, and Cosmetic Act §524B, Ensuring cybersecurity of devices (added by the Consolidated
Appropriations Act, 2023).
[7] OWASP Foundation. CycloneDX machine-learning bill of materials (ML-BOM). Specification v1.5, 2023.
[8] D. Kang et al. Scaling up trustless DNN inference with zero-knowledge proofs. arXiv:2210.08674, 2022.
[9] H. Akgul et al. Verifiable fine-tuning for LLMs: zero-knowledge training proofs bound to data provenance and
policy. arXiv:2510.16830, 2025.
[10] T. Aoki. Visibility engineering for the governance of GenAI-enabled medical devices: a configuration
commitment registry for verifiable configuration identity and model lineage. Blockchain Kaigi 2026 (BCK26),
Tokyo, December 2026; accepted for oral presentation.
[11] B. Laurie, A. Langley, and E. Kasper. Certificate Transparency. RFC 6962, IETF, 2013.
[12] Office of the National Coordinator for Health Information Technology. Health data, technology, and
interoperability: certification program updates, algorithm transparency, and information sharing (HTI-1). 89
Fed. Reg. 1192, 2024.
[13] N. Zahan, E. Lin, M. Tamanna, W. Enck, and L. Williams. Software bills of materials are required. Are we there
yet? IEEE Security & Privacy, 21(2):82–88, 2023. https://doi.org/10.1109/MSEC.2023.3237100
[14] 21 C.F.R. § 801.3, Definitions (“lot or batch”).
https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-801/subpart-A/section-801.3
[15] 21 C.F.R. § 801.50(a), Labeling requirements for stand-alone software. https://www.ecfr.gov/current/title21/chapter-I/subchapter-H/part-801/subpart-B/section-801.50
[16] U.S. FDA. Artificial Intelligence-Enabled Medical Devices (AI-Enabled Medical Device List; accessed 9 October
2026). https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-enabledmedical-devices
[17] T. Aoki. US medical device surveillance cannot retrieve adverse events across products sharing a foundation
model: an audit of identifier schemas and record linkage. Manuscript under review (2026); codebook,
recorded classifications and outputs deposited in [18].
[18] T. Aoki. visibility-audit: codebook (fixed 2 September 2026) and addenda (3 and 29 September 2026),
recorded classifications, computed outputs and code. GitHub, https://github.com/tomonoshin-lab/visibilityaudit; Zenodo, https://doi.org/10.5281/zenodo.23016646 (all versions).

Attachments
Attachment B. Field inventories and identity-audit outputs (computed 30 August–2 September 2026): an
XLSX workbook containing the field inventories underlying Appendix A, the DEVICE-file fill rates and
version-pattern scan for the 943 reports, the export layouts of the MDR master and DEVICE files, the
population rates of the premarket submission number in the MDR master file by year, and the
AccessGUDID resolution results. The scripts reproduce these outputs end-to-end from the FDA public
files and the public replication repository of reference [2]; outputs, scripts, codebook, and data manifest
are deposited in the public repository visibility-audit [18]; the outputs in this attachment are those
deposited in its out/ folder (unchanged since release v1.0).

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 13
Appendix A. Field inventories of three public FDA files (computed 30 August 2026)
File Fields Field content Device- Structured
identifying field upstreamcomponent field

MDR master record 15 Report keys, dates, flags, reporter codes, None in the None
(15-field extract as event type (full file adds reporter, extract; article
used in [2]; 86 fields manufacturer, premarket submission identity resides
in the current public number) in linked DEVICE
export) records

510(k) releasable 22 K number, applicant identity and address, Article (K None; the indicator
database receipt and decision dates, decision, number, device locates component
advisory committee, product code, device name) information in
name, statement-or-summary indicator unstructured
summary documents

AI-Enabled Medical 6 Decision date, submission number, device, Article None
Devices List (as company, lead panel, primary product code (submission
updated through number, device)
2026)

Total 43 0
Note. Inventories were computed from FDA public files and the public replication repository of reference [2]; the AIEnabled Medical Devices List was inventoried from the snapshot archived in that repository and its six columns
confirmed against the list as updated in 2026. Judgments concern the presence of structured fields, not the
completeness of their population.

Aoki — Comment on Docket No. FDA-2026-N-7874 — page 14

Attachment B — Field inventories and identity-audit outputs (computed 30 Aug–2
Docket
Sep FDA-2026-N-7874. Submitted by Tomonoshin Aoki, Innovation Management and Policy Program,
2026)
Hitotsubashi University.
Sheets
r1a_summary — field counts of the three systems (15/22/6 = 43 fields; 0 structured upstream-component
identifiers) and missingness replication for the 943 reports of the source study (Babic et al. replication
S1_computed_fields
repository). — the 43 fields with referent class and component-relatedness (computed).
fill_rates — MAUDE DEVICE-file identifier fields for the 943 reports: populated / 'not applicable' / blank /
placeholder, with fill rates
version_pattern_scan — (r1b).
version-like tokens found inside identifier fields not designated for versions (r1b);
137 of 943 reports carry at least one such token across MODEL_NUMBER, CATALOG_NUMBER,
layouts — actualOTHER_ID_NUMBER,
LOT_NUMBER, field layouts of the FDAUDI-PUBLIC.
export files as downloaded: MDR master (mdrfoiThru2025.txt, 86
fields; PMA_PMN_NUM at position 81 = documented field 80) and DEVICE files 2013–2023 (34 fields each).
population_fill_by_year — population-wide fill of the premarket submission number field (PMA_PMN_NUM) in
the MDR master: per file and by year of receipt (r1c). 2013–2023 window: 15,463,770 reports, regulatorygudid_lookup_results
format fill 0.7505. — AccessGUDID resolution of the 39 distinct UDI-DIs carried by the 943 reports (2 Sep
2026): 38/39 resolved; premarket submission number present for 21/39; of those 21, 10 differ from the MDR
master's PMA_PMN_NUM for the same reports; production-identifier flags (lotBatch / serialNumber /
manufacturingDate / expirationDate).
Provenance
All sheets are verbatim exports of files in the public repository visibility-audit (out/r1a, out/r1b, out/r1c,
out/gudid); data sources and SHA-256 checksums are listed in data/MANIFEST.md of that repository.
Computations are deterministic and involve no judgment. FDA source files: MAUDE DEVICE 2013–2023 and
MDR master (mdrfoi.zip 2026-08-04 release; mdrfoithru2025.zip), downloaded 2 Sep 2026; AccessGUDID
API v3, queried 2 Sep 2026.
item value
field_counts / MDR master record (943-report extract) 15
field_counts / 510(k) releasable database (pmn96cur) 22
field_counts / FDA AI-enabled device list (May 2024 snapshot) 6
field_counts / total_fields 43
field_counts / structured_upstream_component_identifiers 0
field_counts / candidate_fields_matching_component_terms (none)
missingness_replication / n_reports 943
missingness_replication / event_location_missing_blank_or_I 943
missingness_replication / health_professional_missing_blank_or_I 690
missingness_replication / date_of_event_missing 298
missingness_replication / reporter_occupation_missing 283
missingness_replication / event_type_counts / M 857
missingness_replication / event_type_counts / IN 84
missingness_replication / event_type_counts / D 2
missingness_replication / date_received_years / 2013 2
missingness_replication / date_received_years / 2014 62
missingness_replication / date_received_years / 2015 16
missingness_replication / date_received_years / 2016 1
missingness_replication / date_received_years / 2017 70
missingness_replication / date_received_years / 2018 100
missingness_replication / date_received_years / 2019 224
missingness_replication / date_received_years / 2020 139
missingness_replication / date_received_years / 2021 47
missingness_replication / date_received_years / 2022 57
missingness_replication / date_received_years / 2023 225
missingness_replication / unique_devices_idnumber 51
missingness_replication / mdr_report_key_unique 943
system field_name

MDR master record (943-report extract) idnumber
MDR master record (943-report extract) mdr_report_key
MDR master record (943-report extract) report_source_code
MDR master record (943-report extract) date_received
MDR master record (943-report extract) adverse_event_flag
MDR master record (943-report extract) product_problem_flag
MDR master record (943-report extract) date_report
MDR master record (943-report extract) date_of_event
MDR master record (943-report extract) reporter_occupation_code
MDR master record (943-report extract) health_professional
MDR master record (943-report extract) event_location
MDR master record (943-report extract) date_manufacturer_received
MDR master record (943-report extract) remedial_action
MDR master record (943-report extract) event_type
MDR master record (943-report extract) type_of_report
510(k) releasable database (pmn96cur) KNUMBER
510(k) releasable database (pmn96cur) APPLICANT
510(k) releasable database (pmn96cur) CONTACT
510(k) releasable database (pmn96cur) STREET1
510(k) releasable database (pmn96cur) STREET2
510(k) releasable database (pmn96cur) CITY
510(k) releasable database (pmn96cur) STATE
510(k) releasable database (pmn96cur) COUNTRY_CODE
510(k) releasable database (pmn96cur) ZIP
510(k) releasable database (pmn96cur) POSTAL_CODE
510(k) releasable database (pmn96cur) DATERECEIVED
510(k) releasable database (pmn96cur) DECISIONDATE
510(k) releasable database (pmn96cur) DECISION
510(k) releasable database (pmn96cur) REVIEWADVISECOMM
510(k) releasable database (pmn96cur) PRODUCTCODE
510(k) releasable database (pmn96cur) STATEORSUMM
510(k) releasable database (pmn96cur) CLASSADVISECOMM
510(k) releasable database (pmn96cur) SSPINDICATOR
510(k) releasable database (pmn96cur) TYPE
510(k) releasable database (pmn96cur) THIRDPARTY
510(k) releasable database (pmn96cur) EXPEDITEDREVIEW
510(k) releasable database (pmn96cur) DEVICENAME
FDA AI-enabled device list (May 2024 snapshot) Date of Final Decision
FDA AI-enabled device list (May 2024 snapshot) Submission Number
FDA AI-enabled device list (May 2024 snapshot) Device
FDA AI-enabled device list (May 2024 snapshot) Company
FDA AI-enabled device list (May 2024 snapshot) Panel (Lead)
FDA AI-enabled device list (May 2024 snapshot) Primary Product Code
designated_meanin data_type referent_class structured controlled_values
g
join_key_to component_relate source_doc notes
d
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Babic et al. repository computed
Denominator n_reports = 943; 'na_populated' = literal 'NA'/'N/A' entries counted separately; placeholder = NI/UN

field n_reports reports_with_device_row populated

BRAND_NAME 943 943 943
GENERIC_NAME 943 943 943
MODEL_NUMBER 943 943 588
CATALOG_NUMBER 943 943 119
LOT_NUMBER 943 943 113
OTHER_ID_NUMBER 943 943 81
DEVICE_REPORT_PRODUCT_CODE
943 943 943
EXPIRATION_DATE_OF_DEVICE
943 943 68
UDI-DI 943 943 446
UDI-PUBLIC 943 943 446
ounted separately; placeholder = NI/UNKNOWN/etc.

na_populated blank placeholder fill_rate_incl_NA fill_rate_excl_NA

0 0 0 1.0 1.0
0 0 0 1.0 1.0
82 273 0 0.7105 0.6235
7 817 0 0.1336 0.1262
80 749 1 0.2047 0.1198
3 859 0 0.0891 0.0859
0 0 0 1.0 1.0
0 875 0 0.0721 0.0721
0 497 0 0.473 0.473
0 497 0 0.473 0.473
Version-like token regex applied to non-blank values of each field (first DEVICE row per report). 137/943 report

field n_nonblank version_like_tokens share_of_nonblan
k
MODEL_NUMBER 670 77 0.1149
CATALOG_NUMBER
126 0 0.0
LOT_NUMBER 194 2 0.0103
OTHER_ID_NUMBER
84 44 0.5238
UDI-PUBLIC 446 89 0.1996
(first DEVICE row per report). 137/943 reports have >=1 token in any of the five fields.

examples

MERGE PACS 8.1, 8.1.1, 8.1.2; FFRCT 2.60.1.1; 2.62.1.1; MERGE PACS 8.0.2; 8.1.4; 2.57.0.6; RAYSTATION

SW V. 1.1.5; SOFTWARE VERSION 2.0
2.0.2.1; SW VERSION 1.1; SW VERSION 2.0; SW VERSION 2.0.2.1; SW VERSION 2.0; 1.0.6; SW VERSION
(01)00842000100409(10)7.2.0.157060(11)180115; (01)00853341006039(10)FFRCT_2.60.1.1(11)2020-12-21;
4; 2.57.0.6; RAYSTATION/RAYPLAN VERSION 4-11A, INCLUDING SERVICE PACKS; 3.18.1.5

2.0; 1.0.6; SW VERSION 3.0; SW VERSION: 1.0
_2.60.1.1(11)2020-12-21; (01)00853341006039(10)FFRCT_2.62.1.1(11)2021-03-13; (01)00842000100737(10)8.0.2.16611
100737(10)8.0.2.166115(11)190708; (01)00842000100805(10)8.1.4(11)201110; (01)00842000100935(10)8.2.0(11)21082
0935(10)8.2.0(11)210826; (01)00853341006039(10)FFRCT_2.57.0.6(11)2020-09-25; (01)00853341006060(10)FFRCT_3.1
1006060(10)FFRCT_3.18.1.5(11)2023-01-20
Header rows of the pipe-delimited FDA export files as downloaded (2 Sep 2026). MDR master: FDA's data-file

file_type file n_fields position field_name
MDR master mdrfoi.zip 86 1 MDR_REPORT_KEY
MDR master mdrfoi.zip 86 2 EVENT_KEY
MDR master mdrfoi.zip 86 3 REPORT_NUMBER
MDR master mdrfoi.zip 86 4 REPORT_SOURCE_CODE
MDR master mdrfoi.zip 86 5 MANUFACTURER_LINK_FLAG_
MDR master mdrfoi.zip 86 6 NUMBER_DEVICES_IN_EVENT
MDR master mdrfoi.zip 86 7 NUMBER_PATIENTS_IN_EVENT
MDR master mdrfoi.zip 86 8 DATE_RECEIVED
MDR master mdrfoi.zip 86 9 ADVERSE_EVENT_FLAG
MDR master mdrfoi.zip 86 10 PRODUCT_PROBLEM_FLAG
MDR master mdrfoi.zip 86 11 DATE_REPORT
MDR master mdrfoi.zip 86 12 DATE_OF_EVENT
MDR master mdrfoi.zip 86 13 REPROCESSED_AND_REUSED_FLAG
MDR master mdrfoi.zip 86 14 REPORTER_OCCUPATION_CODE
MDR master mdrfoi.zip 86 15 HEALTH_PROFESSIONAL
MDR master mdrfoi.zip 86 16 INITIAL_REPORT_TO_FDA
MDR master mdrfoi.zip 86 17 DATE_FACILITY_AWARE
MDR master mdrfoi.zip 86 18 REPORT_DATE
MDR master mdrfoi.zip 86 19 REPORT_TO_FDA
MDR master mdrfoi.zip 86 20 DATE_REPORT_TO_FDA
MDR master mdrfoi.zip 86 21 EVENT_LOCATION
MDR master mdrfoi.zip 86 22 DATE_REPORT_TO_MANUFACTURER
MDR master mdrfoi.zip 86 23 MANUFACTURER_CONTACT_T_NAME
MDR master mdrfoi.zip 86 24 MANUFACTURER_CONTACT_F_NAME
MDR master mdrfoi.zip 86 25 MANUFACTURER_CONTACT_L_NAME
MDR master mdrfoi.zip 86 26 MANUFACTURER_CONTACT_STREET_1
MDR master mdrfoi.zip 86 27 MANUFACTURER_CONTACT_STREET_2
MDR master mdrfoi.zip 86 28 MANUFACTURER_CONTACT_CITY
MDR master mdrfoi.zip 86 29 MANUFACTURER_CONTACT_STATE
MDR master mdrfoi.zip 86 30 MANUFACTURER_CONTACT_ZIP_CODE
MDR master mdrfoi.zip 86 31 MANUFACTURER_CONTACT_ZIP_EXT
MDR master mdrfoi.zip 86 32 MANUFACTURER_CONTACT_COUNTRY
MDR master mdrfoi.zip 86 33 MANUFACTURER_CONTACT_POSTAL
MDR master mdrfoi.zip 86 34 MANUFACTURER_CONTACT_AREA_CODE
MDR master mdrfoi.zip 86 35 MANUFACTURER_CONTACT_EXCHANGE
MDR master mdrfoi.zip 86 36 MANUFACTURER_CONTACT_PHONE_NO
MDR master mdrfoi.zip 86 37 MANUFACTURER_CONTACT_EXTENSION
MDR master mdrfoi.zip 86 38 MANUFACTURER_CONTACT_PCOUNTRY
MDR master mdrfoi.zip 86 39 MANUFACTURER_CONTACT_PCITY
MDR master mdrfoi.zip 86 40 MANUFACTURER_CONTACT_PLOCAL
MDR master mdrfoi.zip 86 41 MANUFACTURER_G1_NAME
MDR master mdrfoi.zip 86 42 MANUFACTURER_G1_STREET_1
MDR master mdrfoi.zip 86 43 MANUFACTURER_G1_STREET_2
MDR master mdrfoi.zip 86 44 MANUFACTURER_G1_CITY
MDR master mdrfoi.zip 86 45 MANUFACTURER_G1_STATE_CODE
MDR master mdrfoi.zip 86 46 MANUFACTURER_G1_ZIP_CODE
MDR master mdrfoi.zip 86 47 MANUFACTURER_G1_ZIP_CODE_EXT
MDR master mdrfoi.zip 86 48 MANUFACTURER_G1_COUNTRY_CODE
MDR master mdrfoi.zip 86 49 MANUFACTURER_G1_POSTAL_CODE
MDR master mdrfoi.zip 86 50 DATE_MANUFACTURER_RECEIVED
MDR master mdrfoi.zip 86 51 MFR_REPORT_TYPE
MDR master mdrfoi.zip 86 52 DEVICE_DATE_OF_MANUFACTURE
MDR master mdrfoi.zip 86 53 SINGLE_USE_FLAG
MDR master mdrfoi.zip 86 54 REMEDIAL_ACTION
MDR master mdrfoi.zip 86 55 PREVIOUS_USE_CODE
MDR master mdrfoi.zip 86 56 REMOVAL_CORRECTION_NUMBER
MDR master mdrfoi.zip 86 57 EVENT_TYPE
MDR master mdrfoi.zip 86 58 DISTRIBUTOR_NAME
MDR master mdrfoi.zip 86 59 DISTRIBUTOR_ADDRESS_1
MDR master mdrfoi.zip 86 60 DISTRIBUTOR_ADDRESS_2
MDR master mdrfoi.zip 86 61 DISTRIBUTOR_CITY
MDR master mdrfoi.zip 86 62 DISTRIBUTOR_STATE_CODE
MDR master mdrfoi.zip 86 63 DISTRIBUTOR_ZIP_CODE
MDR master mdrfoi.zip 86 64 DISTRIBUTOR_ZIP_CODE_EXT
MDR master mdrfoi.zip 86 65 REPORT_TO_MANUFACTURER
MDR master mdrfoi.zip 86 66 MANUFACTURER_NAME
MDR master mdrfoi.zip 86 67 MANUFACTURER_ADDRESS_1
MDR master mdrfoi.zip 86 68 MANUFACTURER_ADDRESS_2
MDR master mdrfoi.zip 86 69 MANUFACTURER_CITY
MDR master mdrfoi.zip 86 70 MANUFACTURER_STATE_CODE
MDR master mdrfoi.zip 86 71 MANUFACTURER_ZIP_CODE
MDR master mdrfoi.zip 86 72 MANUFACTURER_ZIP_CODE_EXT
MDR master mdrfoi.zip 86 73 MANUFACTURER_COUNTRY_CODE
MDR master mdrfoi.zip 86 74 MANUFACTURER_POSTAL_CODE
MDR master mdrfoi.zip 86 75 TYPE_OF_REPORT
MDR master mdrfoi.zip 86 76 SOURCE_TYPE
MDR master mdrfoi.zip 86 77 DATE_ADDED
MDR master mdrfoi.zip 86 78 DATE_CHANGED
MDR master mdrfoi.zip 86 79 REPORTER_STATE_CODE
MDR master mdrfoi.zip 86 80 REPORTER_COUNTRY_CODE
MDR master mdrfoi.zip 86 81 PMA_PMN_NUM
MDR master mdrfoi.zip 86 82 EXEMPTION_NUMBER
MDR master mdrfoi.zip 86 83 SUMMARY_REPORT
MDR master mdrfoi.zip 86 84 NOE_SUMMARIZED
MDR master mdrfoi.zip 86 85 SUPPL_DATES_FDA_RECEIVED
MDR master mdrfoi.zip 86 86 SUPPL_DATES_MFR_RECEIVED
MDR master mdrfoithru2025.zip 86 1 MDR_REPORT_KEY
MDR master mdrfoithru2025.zip 86 2 EVENT_KEY
MDR master mdrfoithru2025.zip 86 3 REPORT_NUMBER
MDR master mdrfoithru2025.zip 86 4 REPORT_SOURCE_CODE
MDR master mdrfoithru2025.zip 86 5 MANUFACTURER_LINK_FLAG_
MDR master mdrfoithru2025.zip 86 6 NUMBER_DEVICES_IN_EVENT
MDR master mdrfoithru2025.zip 86 7 NUMBER_PATIENTS_IN_EVENT
MDR master mdrfoithru2025.zip 86 8 DATE_RECEIVED
MDR master mdrfoithru2025.zip 86 9 ADVERSE_EVENT_FLAG
MDR master mdrfoithru2025.zip 86 10 PRODUCT_PROBLEM_FLAG
MDR master mdrfoithru2025.zip 86 11 DATE_REPORT
MDR master mdrfoithru2025.zip 86 12 DATE_OF_EVENT
MDR master mdrfoithru2025.zip 86 13 REPROCESSED_AND_REUSED_FLAG
MDR master mdrfoithru2025.zip 86 14 REPORTER_OCCUPATION_CODE
MDR master mdrfoithru2025.zip 86 15 HEALTH_PROFESSIONAL
MDR master mdrfoithru2025.zip 86 16 INITIAL_REPORT_TO_FDA
MDR master mdrfoithru2025.zip 86 17 DATE_FACILITY_AWARE
MDR master mdrfoithru2025.zip 86 18 REPORT_DATE
MDR master mdrfoithru2025.zip 86 19 REPORT_TO_FDA
MDR master mdrfoithru2025.zip 86 20 DATE_REPORT_TO_FDA
MDR master mdrfoithru2025.zip 86 21 EVENT_LOCATION
MDR master mdrfoithru2025.zip 86 22 DATE_REPORT_TO_MANUFACTURER
MDR master mdrfoithru2025.zip 86 23 MANUFACTURER_CONTACT_T_NAME
MDR master mdrfoithru2025.zip 86 24 MANUFACTURER_CONTACT_F_NAME
MDR master mdrfoithru2025.zip 86 25 MANUFACTURER_CONTACT_L_NAME
MDR master mdrfoithru2025.zip 86 26 MANUFACTURER_CONTACT_STREET_1
MDR master mdrfoithru2025.zip 86 27 MANUFACTURER_CONTACT_STREET_2
MDR master mdrfoithru2025.zip 86 28 MANUFACTURER_CONTACT_CITY
MDR master mdrfoithru2025.zip 86 29 MANUFACTURER_CONTACT_STATE
MDR master mdrfoithru2025.zip 86 30 MANUFACTURER_CONTACT_ZIP_CODE
MDR master mdrfoithru2025.zip 86 31 MANUFACTURER_CONTACT_ZIP_EXT
MDR master mdrfoithru2025.zip 86 32 MANUFACTURER_CONTACT_COUNTRY
MDR master mdrfoithru2025.zip 86 33 MANUFACTURER_CONTACT_POSTAL
MDR master mdrfoithru2025.zip 86 34 MANUFACTURER_CONTACT_AREA_CODE
MDR master mdrfoithru2025.zip 86 35 MANUFACTURER_CONTACT_EXCHANGE
MDR master mdrfoithru2025.zip 86 36 MANUFACTURER_CONTACT_PHONE_NO
MDR master mdrfoithru2025.zip 86 37 MANUFACTURER_CONTACT_EXTENSION
MDR master mdrfoithru2025.zip 86 38 MANUFACTURER_CONTACT_PCOUNTRY
MDR master mdrfoithru2025.zip 86 39 MANUFACTURER_CONTACT_PCITY
MDR master mdrfoithru2025.zip 86 40 MANUFACTURER_CONTACT_PLOCAL
MDR master mdrfoithru2025.zip 86 41 MANUFACTURER_G1_NAME
MDR master mdrfoithru2025.zip 86 42 MANUFACTURER_G1_STREET_1
MDR master mdrfoithru2025.zip 86 43 MANUFACTURER_G1_STREET_2
MDR master mdrfoithru2025.zip 86 44 MANUFACTURER_G1_CITY
MDR master mdrfoithru2025.zip 86 45 MANUFACTURER_G1_STATE_CODE
MDR master mdrfoithru2025.zip 86 46 MANUFACTURER_G1_ZIP_CODE
MDR master mdrfoithru2025.zip 86 47 MANUFACTURER_G1_ZIP_CODE_EXT
MDR master mdrfoithru2025.zip 86 48 MANUFACTURER_G1_COUNTRY_CODE
MDR master mdrfoithru2025.zip 86 49 MANUFACTURER_G1_POSTAL_CODE
MDR master mdrfoithru2025.zip 86 50 DATE_MANUFACTURER_RECEIVED
MDR master mdrfoithru2025.zip 86 51 MFR_REPORT_TYPE
MDR master mdrfoithru2025.zip 86 52 DEVICE_DATE_OF_MANUFACTURE
MDR master mdrfoithru2025.zip 86 53 SINGLE_USE_FLAG
MDR master mdrfoithru2025.zip 86 54 REMEDIAL_ACTION
MDR master mdrfoithru2025.zip 86 55 PREVIOUS_USE_CODE
MDR master mdrfoithru2025.zip 86 56 REMOVAL_CORRECTION_NUMBER
MDR master mdrfoithru2025.zip 86 57 EVENT_TYPE
MDR master mdrfoithru2025.zip 86 58 DISTRIBUTOR_NAME
MDR master mdrfoithru2025.zip 86 59 DISTRIBUTOR_ADDRESS_1
MDR master mdrfoithru2025.zip 86 60 DISTRIBUTOR_ADDRESS_2
MDR master mdrfoithru2025.zip 86 61 DISTRIBUTOR_CITY
MDR master mdrfoithru2025.zip 86 62 DISTRIBUTOR_STATE_CODE
MDR master mdrfoithru2025.zip 86 63 DISTRIBUTOR_ZIP_CODE
MDR master mdrfoithru2025.zip 86 64 DISTRIBUTOR_ZIP_CODE_EXT
MDR master mdrfoithru2025.zip 86 65 REPORT_TO_MANUFACTURER
MDR master mdrfoithru2025.zip 86 66 MANUFACTURER_NAME
MDR master mdrfoithru2025.zip 86 67 MANUFACTURER_ADDRESS_1
MDR master mdrfoithru2025.zip 86 68 MANUFACTURER_ADDRESS_2
MDR master mdrfoithru2025.zip 86 69 MANUFACTURER_CITY
MDR master mdrfoithru2025.zip 86 70 MANUFACTURER_STATE_CODE
MDR master mdrfoithru2025.zip 86 71 MANUFACTURER_ZIP_CODE
MDR master mdrfoithru2025.zip 86 72 MANUFACTURER_ZIP_CODE_EXT
MDR master mdrfoithru2025.zip 86 73 MANUFACTURER_COUNTRY_CODE
MDR master mdrfoithru2025.zip 86 74 MANUFACTURER_POSTAL_CODE
MDR master mdrfoithru2025.zip 86 75 TYPE_OF_REPORT
MDR master mdrfoithru2025.zip 86 76 SOURCE_TYPE
MDR master mdrfoithru2025.zip 86 77 DATE_ADDED
MDR master mdrfoithru2025.zip 86 78 DATE_CHANGED
MDR master mdrfoithru2025.zip 86 79 REPORTER_STATE_CODE
MDR master mdrfoithru2025.zip 86 80 REPORTER_COUNTRY_CODE
MDR master mdrfoithru2025.zip 86 81 PMA_PMN_NUM
MDR master mdrfoithru2025.zip 86 82 EXEMPTION_NUMBER
MDR master mdrfoithru2025.zip 86 83 SUMMARY_REPORT
MDR master mdrfoithru2025.zip 86 84 NOE_SUMMARIZED
MDR master mdrfoithru2025.zip 86 85 SUPPL_DATES_FDA_RECEIVED
MDR master mdrfoithru2025.zip 86 86 SUPPL_DATES_MFR_RECEIVED
DEVICE device2013.zip 34 1 MDR_REPORT_KEY
DEVICE device2013.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2013.zip 34 3 IMPLANT_FLAG
DEVICE device2013.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2013.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2013.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2013.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2013.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2013.zip 34 9 DATE_RECEIVED
DEVICE device2013.zip 34 10 BRAND_NAME
DEVICE device2013.zip 34 11 GENERIC_NAME
DEVICE device2013.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2013.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2013.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2013.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2013.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2013.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2013.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2013.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2013.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2013.zip 34 21 DEVICE_OPERATOR
DEVICE device2013.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2013.zip 34 23 MODEL_NUMBER
DEVICE device2013.zip 34 24 CATALOG_NUMBER
DEVICE device2013.zip 34 25 LOT_NUMBER
DEVICE device2013.zip 34 26 OTHER_ID_NUMBER
DEVICE device2013.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2013.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2013.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2013.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2013.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2013.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2013.zip 34 33 UDI-DI
DEVICE device2013.zip 34 34 UDI-PUBLIC
DEVICE device2014.zip 34 1 MDR_REPORT_KEY
DEVICE device2014.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2014.zip 34 3 IMPLANT_FLAG
DEVICE device2014.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2014.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2014.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2014.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2014.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2014.zip 34 9 DATE_RECEIVED
DEVICE device2014.zip 34 10 BRAND_NAME
DEVICE device2014.zip 34 11 GENERIC_NAME
DEVICE device2014.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2014.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2014.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2014.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2014.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2014.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2014.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2014.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2014.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2014.zip 34 21 DEVICE_OPERATOR
DEVICE device2014.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2014.zip 34 23 MODEL_NUMBER
DEVICE device2014.zip 34 24 CATALOG_NUMBER
DEVICE device2014.zip 34 25 LOT_NUMBER
DEVICE device2014.zip 34 26 OTHER_ID_NUMBER
DEVICE device2014.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2014.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2014.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2014.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2014.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2014.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2014.zip 34 33 UDI-DI
DEVICE device2014.zip 34 34 UDI-PUBLIC
DEVICE device2015.zip 34 1 MDR_REPORT_KEY
DEVICE device2015.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2015.zip 34 3 IMPLANT_FLAG
DEVICE device2015.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2015.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2015.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2015.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2015.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2015.zip 34 9 DATE_RECEIVED
DEVICE device2015.zip 34 10 BRAND_NAME
DEVICE device2015.zip 34 11 GENERIC_NAME
DEVICE device2015.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2015.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2015.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2015.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2015.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2015.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2015.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2015.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2015.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2015.zip 34 21 DEVICE_OPERATOR
DEVICE device2015.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2015.zip 34 23 MODEL_NUMBER
DEVICE device2015.zip 34 24 CATALOG_NUMBER
DEVICE device2015.zip 34 25 LOT_NUMBER
DEVICE device2015.zip 34 26 OTHER_ID_NUMBER
DEVICE device2015.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2015.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2015.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2015.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2015.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2015.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2015.zip 34 33 UDI-DI
DEVICE device2015.zip 34 34 UDI-PUBLIC
DEVICE device2016.zip 34 1 MDR_REPORT_KEY
DEVICE device2016.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2016.zip 34 3 IMPLANT_FLAG
DEVICE device2016.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2016.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2016.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2016.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2016.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2016.zip 34 9 DATE_RECEIVED
DEVICE device2016.zip 34 10 BRAND_NAME
DEVICE device2016.zip 34 11 GENERIC_NAME
DEVICE device2016.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2016.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2016.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2016.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2016.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2016.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2016.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2016.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2016.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2016.zip 34 21 DEVICE_OPERATOR
DEVICE device2016.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2016.zip 34 23 MODEL_NUMBER
DEVICE device2016.zip 34 24 CATALOG_NUMBER
DEVICE device2016.zip 34 25 LOT_NUMBER
DEVICE device2016.zip 34 26 OTHER_ID_NUMBER
DEVICE device2016.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2016.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2016.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2016.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2016.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2016.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2016.zip 34 33 UDI-DI
DEVICE device2016.zip 34 34 UDI-PUBLIC
DEVICE device2017.zip 34 1 MDR_REPORT_KEY
DEVICE device2017.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2017.zip 34 3 IMPLANT_FLAG
DEVICE device2017.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2017.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2017.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2017.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2017.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2017.zip 34 9 DATE_RECEIVED
DEVICE device2017.zip 34 10 BRAND_NAME
DEVICE device2017.zip 34 11 GENERIC_NAME
DEVICE device2017.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2017.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2017.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2017.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2017.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2017.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2017.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2017.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2017.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2017.zip 34 21 DEVICE_OPERATOR
DEVICE device2017.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2017.zip 34 23 MODEL_NUMBER
DEVICE device2017.zip 34 24 CATALOG_NUMBER
DEVICE device2017.zip 34 25 LOT_NUMBER
DEVICE device2017.zip 34 26 OTHER_ID_NUMBER
DEVICE device2017.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2017.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2017.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2017.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2017.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2017.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2017.zip 34 33 UDI-DI
DEVICE device2017.zip 34 34 UDI-PUBLIC
DEVICE device2018.zip 34 1 MDR_REPORT_KEY
DEVICE device2018.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2018.zip 34 3 IMPLANT_FLAG
DEVICE device2018.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2018.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2018.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2018.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2018.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2018.zip 34 9 DATE_RECEIVED
DEVICE device2018.zip 34 10 BRAND_NAME
DEVICE device2018.zip 34 11 GENERIC_NAME
DEVICE device2018.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2018.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2018.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2018.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2018.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2018.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2018.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2018.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2018.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2018.zip 34 21 DEVICE_OPERATOR
DEVICE device2018.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2018.zip 34 23 MODEL_NUMBER
DEVICE device2018.zip 34 24 CATALOG_NUMBER
DEVICE device2018.zip 34 25 LOT_NUMBER
DEVICE device2018.zip 34 26 OTHER_ID_NUMBER
DEVICE device2018.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2018.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2018.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2018.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2018.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2018.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2018.zip 34 33 UDI-DI
DEVICE device2018.zip 34 34 UDI-PUBLIC
DEVICE device2019.zip 34 1 MDR_REPORT_KEY
DEVICE device2019.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2019.zip 34 3 IMPLANT_FLAG
DEVICE device2019.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2019.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2019.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2019.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2019.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2019.zip 34 9 DATE_RECEIVED
DEVICE device2019.zip 34 10 BRAND_NAME
DEVICE device2019.zip 34 11 GENERIC_NAME
DEVICE device2019.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2019.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2019.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2019.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2019.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2019.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2019.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2019.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2019.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2019.zip 34 21 DEVICE_OPERATOR
DEVICE device2019.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2019.zip 34 23 MODEL_NUMBER
DEVICE device2019.zip 34 24 CATALOG_NUMBER
DEVICE device2019.zip 34 25 LOT_NUMBER
DEVICE device2019.zip 34 26 OTHER_ID_NUMBER
DEVICE device2019.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2019.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2019.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2019.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2019.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2019.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2019.zip 34 33 UDI-DI
DEVICE device2019.zip 34 34 UDI-PUBLIC
DEVICE device2020.zip 34 1 MDR_REPORT_KEY
DEVICE device2020.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2020.zip 34 3 IMPLANT_FLAG
DEVICE device2020.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2020.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2020.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2020.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2020.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2020.zip 34 9 DATE_RECEIVED
DEVICE device2020.zip 34 10 BRAND_NAME
DEVICE device2020.zip 34 11 GENERIC_NAME
DEVICE device2020.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2020.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2020.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2020.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2020.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2020.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2020.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2020.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2020.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2020.zip 34 21 DEVICE_OPERATOR
DEVICE device2020.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2020.zip 34 23 MODEL_NUMBER
DEVICE device2020.zip 34 24 CATALOG_NUMBER
DEVICE device2020.zip 34 25 LOT_NUMBER
DEVICE device2020.zip 34 26 OTHER_ID_NUMBER
DEVICE device2020.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2020.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2020.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2020.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2020.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2020.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2020.zip 34 33 UDI-DI
DEVICE device2020.zip 34 34 UDI-PUBLIC
DEVICE device2021.zip 34 1 MDR_REPORT_KEY
DEVICE device2021.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2021.zip 34 3 IMPLANT_FLAG
DEVICE device2021.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2021.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2021.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2021.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2021.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2021.zip 34 9 DATE_RECEIVED
DEVICE device2021.zip 34 10 BRAND_NAME
DEVICE device2021.zip 34 11 GENERIC_NAME
DEVICE device2021.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2021.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2021.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2021.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2021.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2021.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2021.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2021.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2021.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2021.zip 34 21 DEVICE_OPERATOR
DEVICE device2021.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2021.zip 34 23 MODEL_NUMBER
DEVICE device2021.zip 34 24 CATALOG_NUMBER
DEVICE device2021.zip 34 25 LOT_NUMBER
DEVICE device2021.zip 34 26 OTHER_ID_NUMBER
DEVICE device2021.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2021.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2021.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2021.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2021.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2021.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2021.zip 34 33 UDI-DI
DEVICE device2021.zip 34 34 UDI-PUBLIC
DEVICE device2022.zip 34 1 MDR_REPORT_KEY
DEVICE device2022.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2022.zip 34 3 IMPLANT_FLAG
DEVICE device2022.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2022.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2022.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2022.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2022.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2022.zip 34 9 DATE_RECEIVED
DEVICE device2022.zip 34 10 BRAND_NAME
DEVICE device2022.zip 34 11 GENERIC_NAME
DEVICE device2022.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2022.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2022.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2022.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2022.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2022.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2022.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2022.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2022.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2022.zip 34 21 DEVICE_OPERATOR
DEVICE device2022.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2022.zip 34 23 MODEL_NUMBER
DEVICE device2022.zip 34 24 CATALOG_NUMBER
DEVICE device2022.zip 34 25 LOT_NUMBER
DEVICE device2022.zip 34 26 OTHER_ID_NUMBER
DEVICE device2022.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2022.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2022.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2022.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2022.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2022.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2022.zip 34 33 UDI-DI
DEVICE device2022.zip 34 34 UDI-PUBLIC
DEVICE device2023.zip 34 1 MDR_REPORT_KEY
DEVICE device2023.zip 34 2 DEVICE_EVENT_KEY
DEVICE device2023.zip 34 3 IMPLANT_FLAG
DEVICE device2023.zip 34 4 DATE_REMOVED_FLAG
DEVICE device2023.zip 34 5 DEVICE_SEQUENCE_NO
DEVICE device2023.zip 34 6 IMPLANT_DATE_YEAR
DEVICE device2023.zip 34 7 DATE_REMOVED_YEAR
DEVICE device2023.zip 34 8 SERVICED_BY_3RD_PARTY_FLAG
DEVICE device2023.zip 34 9 DATE_RECEIVED
DEVICE device2023.zip 34 10 BRAND_NAME
DEVICE device2023.zip 34 11 GENERIC_NAME
DEVICE device2023.zip 34 12 MANUFACTURER_D_NAME
DEVICE device2023.zip 34 13 MANUFACTURER_D_ADDRESS_1
DEVICE device2023.zip 34 14 MANUFACTURER_D_ADDRESS_2
DEVICE device2023.zip 34 15 MANUFACTURER_D_CITY
DEVICE device2023.zip 34 16 MANUFACTURER_D_STATE_CODE
DEVICE device2023.zip 34 17 MANUFACTURER_D_ZIP_CODE
DEVICE device2023.zip 34 18 MANUFACTURER_D_ZIP_CODE_EXT
DEVICE device2023.zip 34 19 MANUFACTURER_D_COUNTRY_CODE
DEVICE device2023.zip 34 20 MANUFACTURER_D_POSTAL_CODE
DEVICE device2023.zip 34 21 DEVICE_OPERATOR
DEVICE device2023.zip 34 22 EXPIRATION_DATE_OF_DEVICE
DEVICE device2023.zip 34 23 MODEL_NUMBER
DEVICE device2023.zip 34 24 CATALOG_NUMBER
DEVICE device2023.zip 34 25 LOT_NUMBER
DEVICE device2023.zip 34 26 OTHER_ID_NUMBER
DEVICE device2023.zip 34 27 DEVICE_AVAILABILITY
DEVICE device2023.zip 34 28 DATE_RETURNED_TO_MANUFACTURER
DEVICE device2023.zip 34 29 DEVICE_REPORT_PRODUCT_CODE
DEVICE device2023.zip 34 30 DEVICE_AGE_TEXT
DEVICE device2023.zip 34 31 DEVICE_EVALUATED_BY_MANUFACTUR
DEVICE device2023.zip 34 32 COMBINATION_PRODUCT_FLAG
DEVICE device2023.zip 34 33 UDI-DI
DEVICE device2023.zip 34 34 UDI-PUBLIC
DR master: FDA's data-file description states 82 fields and enumerates 85; the export has 86 (MFR_REPORT_TYPE inser

REUSED_FLAG
TION_CODE

ANUFACTURER
NTACT_T_NAME
NTACT_F_NAME
NTACT_L_NAME
NTACT_STREET_1
NTACT_STREET_2
NTACT_CITY
NTACT_STATE
NTACT_ZIP_CODE
NTACT_ZIP_EXT
NTACT_COUNTRY
NTACT_POSTAL
NTACT_AREA_CODE
NTACT_EXCHANGE
NTACT_PHONE_NO
NTACT_EXTENSION
NTACT_PCOUNTRY
NTACT_PCITY
NTACT_PLOCAL

STREET_1
STREET_2

STATE_CODE
ZIP_CODE_EXT
COUNTRY_CODE
POSTAL_CODE
R_RECEIVED

ANUFACTURE

ON_NUMBER

_CODE_EXT
UNTRY_CODE
STAL_CODE
 REUSED_FLAG
TION_CODE

ANUFACTURER
NTACT_T_NAME
NTACT_F_NAME
NTACT_L_NAME
NTACT_STREET_1
NTACT_STREET_2
NTACT_CITY
NTACT_STATE
NTACT_ZIP_CODE
NTACT_ZIP_EXT
NTACT_COUNTRY
NTACT_POSTAL
NTACT_AREA_CODE
NTACT_EXCHANGE
NTACT_PHONE_NO
NTACT_EXTENSION
NTACT_PCOUNTRY
NTACT_PCITY
NTACT_PLOCAL

STREET_1
STREET_2

STATE_CODE

ZIP_CODE_EXT
COUNTRY_CODE
POSTAL_CODE
R_RECEIVED

ANUFACTURE
ON_NUMBER

_CODE_EXT
UNTRY_CODE
STAL_CODE

ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE
 IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR

ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR
ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR

ARTY_FLAG
DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR

ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE
_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR

ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR
ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR

ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR

ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR
ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR

ARTY_FLAG

DDRESS_1
DDRESS_2

TATE_CODE

IP_CODE_EXT
COUNTRY_CODE
OSTAL_CODE

_MANUFACTURER
ODUCT_CODE

BY_MANUFACTUR
R_REPORT_TYPE inserted at position 51), so documented field 80 'PMA 510(K) Number' = export position 81 PMA_PMN_
position 81 PMA_PMN_NUM. DEVICE: description lists 48; export has 34 (the 17 'Baseline …' fields are not exported).
ds are not exported).
Per-file summary (PMA_PMN_NUM = premarket submission number field). fill_rate_any counts any non-placeh

file n_fields submission_field reports_in_file populated_any

mdrfoi.zip 86 PMA_PMN_NUM 2078651 1823495
mdrfoithru2025.zip 86 PMA_PMN_NUM 23636517 18242779

By year of receipt (DATE_RECEIVED); rows with unparseable dates are in the file totals but not here.

file year_rec reports populated_any populated_nu
eived mber
mdrfoi.zip 2026 2078302 1823495 1710695
mdrfoithru2025.zip 1900 1 0 0
mdrfoithru2025.zip 1991 15 0 0
mdrfoithru2025.zip 1992 3098 0 0
mdrfoithru2025.zip 1993 4409 0 0
mdrfoithru2025.zip 1994 11272 0 0
mdrfoithru2025.zip 1995 9758 0 0
mdrfoithru2025.zip 1996 32789 0 0
mdrfoithru2025.zip 1997 77691 3 0
mdrfoithru2025.zip 1998 61652 3 0
mdrfoithru2025.zip 1999 52909 3 1
mdrfoithru2025.zip 2000 52569 3 1
mdrfoithru2025.zip 2001 58391 23 15
mdrfoithru2025.zip 2002 69596 21 14
mdrfoithru2025.zip 2003 77009 22 13
mdrfoithru2025.zip 2004 81806 45 30
mdrfoithru2025.zip 2005 98939 165 97
mdrfoithru2025.zip 2006 119642 16275 15265
mdrfoithru2025.zip 2007 171342 71068 67080
mdrfoithru2025.zip 2008 194475 101817 93525
mdrfoithru2025.zip 2009 241972 138994 129169
mdrfoithru2025.zip 2010 303302 201932 190316
mdrfoithru2025.zip 2011 445371 311657 295398
mdrfoithru2025.zip 2012 486300 351900 329069
mdrfoithru2025.zip 2013 679725 507262 460191
mdrfoithru2025.zip 2014 862112 668309 596982
mdrfoithru2025.zip 2015 861798 682139 596341
mdrfoithru2025.zip 2016 867439 733203 656278
mdrfoithru2025.zip 2017 936901 759295 692701
mdrfoithru2025.zip 2018 1048080 791331 736946
mdrfoithru2025.zip 2019 1328954 1000852 953024
mdrfoithru2025.zip 2020 1564999 1222134 1172431
mdrfoithru2025.zip 2021 2028312 1618132 1567826
mdrfoithru2025.zip 2022 2945648 2379024 2327627
mdrfoithru2025.zip 2023 2339802 1925919 1845315
mdrfoithru2025.zip 2024 2627111 2254775 2143466
mdrfoithru2025.zip 2025 2887987 2506473 2311417
_rate_any counts any non-placeholder value; fill_rate_number counts values matching the regulatory number format (K/P/D

populated_submission_num exempt fill_rate_any fill_rate_number
ber
1710695 108256 0.8772 0.823
17180538 556123 0.7718 0.7269

file totals but not here.

fill_rate_any fill_rate_
number
0.8774 0.8231
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0.0001 0
0.0001 0
0.0004 0.0003
0.0003 0.0002
0.0003 0.0002
0.0006 0.0004
0.0017 0.001
0.136 0.1276
0.4148 0.3915
0.5235 0.4809
0.5744 0.5338
0.6658 0.6275
0.6998 0.6633
0.7236 0.6767
0.7463 0.677
0.7752 0.6925
0.7915 0.692
0.8453 0.7566
0.8104 0.7394
0.755 0.7031
0.7531 0.7171
0.7809 0.7492
0.7978 0.773
0.8076 0.7902
0.8231 0.7887
0.8583 0.8159
0.8679 0.8004
hing the regulatory number format (K/P/DEN/N/H/BK/BP/BN/D + digits, optional /S supplement); 'exempt' counts values beg

distinct_submission_number matched_943_ro
s ws
8744 0
36518 943
nt); 'exempt' counts values beginning EXEMPT.
One row per distinct UDI-DI (39). n_reports = reports among the 943 carrying that DI (first DEVICE row per rep

udi_di n_reports idnumbers_in_source_stud resolved http_status
y
03573026359119 250 DEN130013 Y 200
00853341006015 90 K161772 Y 200
00869770000210 27 K181502;K222389 Y 200
00884838105508 12 K212441 Y 200
00853341006060 7 K213857 Y 200
00887517990792 6 K180038 Y 200
00690103200942 4 K183646 Y 200
00842000100805 3 K192455 Y 200
00853341006039 3 K203329 Y 200
00888867265813 3 K183268 Y 200
04056869006697 3 K221733;K231560 Y 200
04056869230740 3 K220939 Y 200
07290017652085 3 K183593 Y 200
00814932020001 2 K193087 Y 200
00850043907046 2 K222389 Y 200
00856128007007 2 K171056 Y 200
00884838104112 2 K223442 Y 200
04056869230719 2 K203443;K221733 Y 200
50690103200947 2 K183646 Y 200
00183739000678 1 K210458 Y 200
00842000100409 1 K192455 Y 200
00842000100737 1 K192455 Y 200
00842000100935 1 K192455 Y 200
00853341006053 1 K213857 Y 200
00859509006019 1 K161834 Y 200
00859591006065 1 K182616 Y 200
00862011000369 1 K192665 Y 200
00887517994127 1 K180038 Y 200
04056481132422 1 K223288 Y 200
04056869006659 1 K220151 Y 200
04056869006710 1 K220589 Y 200
04056869039176 1 K231560 Y 200
04056869044538 1 K223343 Y 200
04056869245188 1 K220939 Y 200
04056869297330 1 K231560 N 404
07290017652108 1 K183593 Y 200
07350002010310 1 K210645 Y 200
09353278000113 1 K181574 Y 200
15099590192242 1 K120771 Y 200
ng that DI (first DEVICE row per report). master_pma_pmn = PMA_PMN_NUM values in the MDR master for those reports;

brand_name version_or_model catalog_numbe
r
VITEK® MS 410895
FFRct v2.1
ZIO AT Patch A100A100X
Incisive CT Incisive CT 728144
HeartFlow Analysis FFRct version 3
PULSE 1881500
Acumen IQ AIQS85 AIQS85
Merge PACS 8.1
HeartFlow Analysis FFRct version 2
Arthrex® AR-5207 AR-5207
MAGNETOM Aera 10432914
MAGNETOM Lumina 11344916
LungVision System Core LV1055002
UroLift UL400-4 UL400-4
Zio ECG Utilization Software (ZEUS) System FG0401US
WAVE Clinical Platform NG
MR 7000 Series MR 7700 782120
MAGNETOM Altea 11344915
Acumen IQ AIQS85 AIQS85
ILUMIEN™ C408650 C408650
Merge PACS 7.2
Merge PACS 8.0
Merge PACS 8.2
HeartFlow Analysis FFRct version 3
One Drop 8000-10465
NvisionVLE Marking Probe 17mm 95301-M-17 95301-M-17
Accelerate PhenoTest® BC kit 10102018
PULSE 5050130
Navigation SW Cranial EM 1.1 22240-06B
MAGNETOM Avanto 10849579
MAGNETOM Skyra 10849580
MAGNETOM Vida 11060815
MAGNETOM Sempra 10840816
MAGNETOM Vida Fit 11410481

LungVision Tool Bridge LV2055011
RayStation 10.1
EchoNous Bladder Probe P005600
UniCel DxH 600 B23858
the MDR master for those reports; gudid_matches_master = Y/N/no_submission_in_gudid. PI flags are the GUDID record's

company_name

BIOMERIEUX SA
Heartflow, Inc.
IRHYTHM TECHNOLOGIES, INC.
Philips Healthcare (Suzhou) Co., Ltd.
Heartflow, Inc.
Nuvasive, Inc.
Edwards Lifesciences LLC
MERGE HEALTHCARE SOLUTIONS INC.
Heartflow, Inc.
ARTHREX, INC.
Siemens Healthcare GmbH
Siemens Healthcare GmbH
BODY VISION MEDICAL LTD
NEOTRACT, INC.
IRHYTHM TECHNOLOGIES, INC.
EXCEL MEDICAL ELECTRONICS LLC
Philips Medical Systems Nederland B.V.
Siemens Healthcare GmbH
Edwards Lifesciences LLC
LIGHTLAB IMAGING, INC.
MERGE HEALTHCARE SOLUTIONS INC.
MERGE HEALTHCARE SOLUTIONS INC.
MERGE HEALTHCARE SOLUTIONS INC.
Heartflow, Inc.
INFORMED DATA SYSTEMS INC.
NINEPOINT MEDICAL, INC.
ACCELERATE DIAGNOSTICS, INC.
Nuvasive, Inc.
Brainlab SE
Siemens Healthcare GmbH
Siemens Healthcare GmbH
Siemens Healthcare GmbH
Siemens Shenzhen Magnetic Resonance Ltd.
Siemens Healthcare GmbH

BODY VISION MEDICAL LTD
Raysearch Laboratories AB (Publ)
ECHONOUS, INC.
Beckman Coulter, Inc.
hes_master = Y/N/no_submission_in_gudid. PI flags are the GUDID record's lotBatch / serialNumber / manufacturingDate /

submission_numbers

DEN130013
K161772

K213857
K180038
K152980
K192455
K190925

K111242;K132951;K133435;K140253;K141977;K142515;K153343;K163312;K173592;K182299;K190138;K191

K202527;K222389
K171056

K152980

K082144

K203329

K153479
DEN160032
K180038
K092467;K213989;K223288
K130885;K151579;K162102;K181613;K190757;K232494
K130885;K140253;K141977;K142515;K151579;K162102;K173592;K232494

K172955

K181574
record's lotBatch / serialNumber / manufacturingDate / expirationDate booleans.

supplement_numbers
000
000
000
000;000;000;000;000;000;000;000;000;000;000;000;000;000

000;000
000
000
000
000;000;000
000;000;000;000;000;000
000;000;000;000;000;000;000;000
000
nDate booleans.

submission_matches_source_stu product_codes
dy
Y PEX
Y PJA
no_submission_in_gudid DQK;DSI;DXH;DSH;QYX
no_submission_in_gudid JAK
Y LLZ;PJA
Y HAW;GWF;ETN;IKN;LLZ;OLO;JAA;PDQ;OWB
N DRS
Y LLZ
N PJA
no_submission_in_gudid HWC
Y LNH;MOS;LNI
no_submission_in_gudid LNH;MOS;LNI
no_submission_in_gudid LLZ
no_submission_in_gudid PEW
Y DQK;DXH;DSI
Y MWI
no_submission_in_gudid LNH;LNI
no_submission_in_gudid LNH;LNI;MOS
N DRS
no_submission_in_gudid NQQ
N LLZ
no_submission_in_gudid LLZ
no_submission_in_gudid LLZ
N PJA
no_submission_in_gudid NBW
N NQQ
N PRH
Y ETN;JAA;GWF;HAW;PDQ;OLO;OWB;IKN;LLZ
Y HAW
N LNH;MOS;LNI
N MOS;LNH;LNI
no_submission_in_gudid LNH;MOS;LNI
no_submission_in_gudid LNH;LNI;MOS
no_submission_in_gudid LNI;LNH;MOS

N EOQ
no_submission_in_gudid MUJ
Y ITX
no_submission_in_gudid GKZ
regulation_number device_class pi_lot_batch pi_serial pi_manufacturing_date

866.3361 2 False True False
870.1415 2 True True True
870.1425 2 False True True
892.1750 2 False True False
892.2050 2 True True True
882.4560 2 True True False
870.2850 2 True False True
892.2050 2 True False True
870.1415 2 True True True
888.3040 2 True False False
892.1000 2 False True False
892.1000 2 False True False
892.2050 2 False True True
876.5530 2 True False False
870.1425 2 False False False
870.2300 2 True False False
892.1000 2 False True False
892.1000 2 False True False
870.2850 2 True False True
892.1560 2 False True True
892.2050 2 True False True
892.2050 2 True False True
892.2050 2 True False True
870.1415 2 True True True
862.1345 2 False True False
892.1560 2 True False False
866.1650 2 True True True
874.1820 2 True False False
882.4560 2 True False False
892.1000 2 False True False
892.1000 2 False True False
892.1000 2 False True False
892.1000 2 False True False
892.1000 2 False True False

874.4680 2 True False True
892.5050 2 False False True
892.1570 2 False True True
864.5220 2 False True True
pi_expiration_date device_record_status public_version_numbe
r
False Published 4
False Published 6
True Published 4
False Published 5
False Published 1
False Published 3
True Published 1
False Published 1
False Published 3
True Published 4
False Published 10
False Published 5
False Published 2
True Published 3
False Published 3
False Published 4
False Published 7
False Published 6
True Published 1
False Published 4
False Published 4
False Published 2
False Published 1
False Published 3
False Published 4
True Published 3
True Published 2
False Published 3
False Published 11
False Published 8
False Published 7
False Published 9
False Published 5
False Published 4

True Published 2
False Published 2
False Published 1
False Published 5
public_version_date device_publish_date lookup_date n

2024-04-29T00:00:00.000Z 2016-11-09T00:00:00.000Z 2026-09-02 250
2022-12-21T00:00:00.000Z 2016-12-06T00:00:00.000Z 2026-09-02 90
2026-03-25T00:00:00.000Z 2019-04-23T00:00:00.000Z 2026-09-02 27
2025-07-04T00:00:00.000Z 2021-12-30T00:00:00.000Z 2026-09-02 12
2022-12-29T00:00:00.000Z 2022-12-21T00:00:00.000Z 2026-09-02 7
2025-06-11T00:00:00.000Z 2019-07-10T00:00:00.000Z 2026-09-02 6
2019-02-04T00:00:00.000Z 2019-01-04T00:00:00.000Z 2026-09-02 4
2019-12-05T00:00:00.000Z 2019-11-27T00:00:00.000Z 2026-09-02 3
2022-12-21T00:00:00.000Z 2020-04-08T00:00:00.000Z 2026-09-02 3
2020-08-05T00:00:00.000Z 2019-06-07T00:00:00.000Z 2026-09-02 3
2026-01-15T00:00:00.000Z 2016-09-24T00:00:00.000Z 2026-09-02 3
2022-05-05T00:00:00.000Z 2019-02-11T00:00:00.000Z 2026-09-02 3
2022-05-27T00:00:00.000Z 2021-04-13T00:00:00.000Z 2026-09-02 3
2018-09-26T00:00:00.000Z 2015-09-14T00:00:00.000Z 2026-09-02 2
2025-11-20T00:00:00.000Z 2024-07-26T00:00:00.000Z 2026-09-02 2
2018-11-08T00:00:00.000Z 2018-01-29T00:00:00.000Z 2026-09-02 2
2026-03-17T00:00:00.000Z 2022-04-08T00:00:00.000Z 2026-09-02 2
2025-11-24T00:00:00.000Z 2020-03-04T00:00:00.000Z 2026-09-02 2
2019-02-04T00:00:00.000Z 2019-01-04T00:00:00.000Z 2026-09-02 2
2020-11-16T00:00:00.000Z 2016-03-23T00:00:00.000Z 2026-09-02 1
2026-08-05T00:00:00.000Z 2017-10-25T00:00:00.000Z 2026-09-02 1
2019-05-09T00:00:00.000Z 2018-11-15T00:00:00.000Z 2026-09-02 1
2021-09-29T00:00:00.000Z 2021-09-21T00:00:00.000Z 2026-09-02 1
2022-12-21T00:00:00.000Z 2021-06-08T00:00:00.000Z 2026-09-02 1
2018-12-03T00:00:00.000Z 2017-04-07T00:00:00.000Z 2026-09-02 1
2018-07-06T00:00:00.000Z 2016-09-22T00:00:00.000Z 2026-09-02 1
2020-12-21T00:00:00.000Z 2020-07-15T00:00:00.000Z 2026-09-02 1
2025-06-11T00:00:00.000Z 2019-08-23T00:00:00.000Z 2026-09-02 1
2026-03-19T00:00:00.000Z 2017-08-09T00:00:00.000Z 2026-09-02 1
2026-01-15T00:00:00.000Z 2016-09-24T00:00:00.000Z 2026-09-02 1
2026-01-15T00:00:00.000Z 2016-09-24T00:00:00.000Z 2026-09-02 1
2022-03-18T00:00:00.000Z 2017-07-25T00:00:00.000Z 2026-09-02 1
2024-10-07T00:00:00.000Z 2018-03-06T00:00:00.000Z 2026-09-02 1
2026-01-08T00:00:00.000Z 2020-03-23T00:00:00.000Z 2026-09-02 1
2026-09-02 1
2022-05-27T00:00:00.000Z 2021-04-11T00:00:00.000Z 2026-09-02 1
2023-05-18T00:00:00.000Z 2021-09-30T00:00:00.000Z 2026-09-02 1
2019-03-11T00:00:00.000Z 2019-02-18T00:00:00.000Z 2026-09-02 1
2024-05-16T00:00:00.000Z 2016-09-23T00:00:00.000Z 2026-09-02 1
master_pma_pmn gudid_matches_master

DEN130013 Y
K161772 Y
K163512;K181502;K222389no_submission_in_gudid
K212441 no_submission_in_gudid
K213857 Y
K180038 Y
K183646 N
K192455 Y
K203329 N
K183268 no_submission_in_gudid
K221733;K231560 Y
K220939 no_submission_in_gudid
K183593 no_submission_in_gudid
K193087 no_submission_in_gudid
K222389 Y
K171056 Y
K223442 no_submission_in_gudid
K203443;K221733 no_submission_in_gudid
K183646 N
K210458 no_submission_in_gudid
K192455 N
K192455 no_submission_in_gudid
K192455 no_submission_in_gudid
K213857 N
K161834 no_submission_in_gudid
K182616 N
K192665 N
K180038 Y
K223288 Y
K220151 N
K220589 N
K231560 no_submission_in_gudid
K223343 no_submission_in_gudid
K220939 no_submission_in_gudid
K231560 no_submission_in_gudid
K183593 N
K210645 no_submission_in_gudid
K181574 Y
K120771 no_submission_in_gudid