Interoperable is a design term, not a class.

Two devices can share a product code, a classification regulation, and a predicate, and only one of them is built to hand its data to another device safely. FDA has a guidance document for exactly that difference. Classification has no field for it, and never has.

What the guidance actually asks for

FDA finalized Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices on September 6, 2017, under docket FDA-2015-D-4852 — a nonbinding guidance from CDRH and CBER, following a draft issued January 26, 2016. It defines interoperability plainly: the ability of two or more products, technologies, or systems to exchange information and to use the information that has been exchanged. For a device built to do that, the guidance asks a submission to cover three things. A device description naming every externally-facing electronic interface and who is expected to use it. A risk analysis that treats a bad or misread data exchange, and reasonably foreseeable misuse of the interface, as hazards in their own right — not folded silently into the device’s ordinary risk file. And verification and validation results for the interface itself, apart from whatever testing covers the device’s core function. On top of that, it expects labeling to say plainly what the device will and will not exchange data with.

What it doesn’t touch

None of that creates a new classification regulation, a new product code, or a separate review track. A glucose meter built to transmit to a specific insulin pump still clears under its own classification regulation, through its ordinary 510(k) or De Novo pathway, against its ordinary predicate if one exists — the guidance folds into that submission, it does not sit beside it as a second filing. 21 CFR 807.92 lists what a 510(k) summary has to contain, and nothing on that list, or in openFDA’s classification or 510(k) records, carries a field distinguishing an interoperable version of a device type from one that never talks to anything else. Regulation number, product code, device class, review panel, K-number, applicant, decision date — the schema doesn’t change because a device happens to have an interface.

Interoperability is a question the guidance asks inside a submission. It has never been a question the classification record answers from outside one.

The practice

Whether a specific cleared device was designed, tested, and labeled to this guidance’s recommendations is a fact that lives in its own submission file and its own labeling — not in its product code, not in its classification regulation’s text, and not in any of the four sources this product ingests: Federal Register notices, warning letters, device recalls, and 510(k) clearances. A buyer or integrator checking whether two cleared devices can safely exchange data is reading labeling and, where one exists, an interface specification — never a database field, because the field doesn’t exist. This is regulatory intelligence and method, never regulatory advice about whether a given interface is safe to build on.