← Latest papers
💻 computer science

Public regulatory data infrastructure for lifecycle oversight of AI medical devices

This paper argues that current public regulatory records for AI medical devices are inadequate for lifecycle oversight due to a lack of structured, queryable data on software changes and AI-specific attributes, and proposes a new data specification to address these critical deficits across major global jurisdictions.

Original authors: Yu Han, Aaron Ceross

Published 2026-06-29
📖 6 min read🧠 Deep dive

Original authors: Yu Han, Aaron Ceross

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Picture: The "Living" Device vs. The "Static" List

Imagine you buy a smart thermostat. When you first buy it, the store gives you a receipt saying, "Yes, this device is approved to be sold." That's great. But a smart thermostat is different from a toaster. A toaster doesn't change; a thermostat gets software updates, learns your habits, and changes how it works over time.

AI medical devices (like software that helps doctors read X-rays) are like that smart thermostat. They are "living" things that evolve after they enter the hospital.

The problem this paper identifies is that the public records (the official lists where hospitals and researchers check if a device is safe) are still built like old-fashioned filing cabinets for static toasters. They tell you:

  • "Yes, this device was approved."
  • "Here is the company name."
  • "Here is the date it was approved."

But they fail to tell you the things that actually matter for a living, changing AI:

  • "What version of the software is currently running?"
  • "Did the AI learn something new last month that changed how it works?"
  • "What kind of data was used to train it?"
  • "If there was a safety warning, does it link back to this specific version?"

The authors argue that while regulators (like the FDA in the US) have started thinking about these devices as "living" things that need lifecycle oversight, the public databases haven't caught up. They are stuck in the past, designed only to confirm a device is legal to sell, not to help people manage it safely while it's being used.


The Audit: Checking the Filing Cabinets

The authors acted like building inspectors. They looked at the public regulatory databases in five major places: the USA, the European Union, China, Japan, and Australia.

They created a "checklist" of 20 things a modern, safe database should have to manage AI devices. They called these Five Governance Functions:

  1. Identity: Who is this thing? (Is it AI? Is it software?)
  2. Version & Change: Has it changed? (What version is running? What updates happened?)
  3. Evidence: Why do we trust it? (What proof was used to approve it?)
  4. Linkage: Can we connect the dots? (If there's a recall, can we instantly find the specific device?)
  5. AI Specificity: What kind of AI is it? (Is it a deep learning model? What data was it trained on?)

The Result:
They found that 94% of the boxes on their checklist were empty or filled with messy notes.

  • Only 6% of the information was available in a clean, computer-readable format (like a spreadsheet cell you can search).
  • Most information was hidden in long PDF reports, unsearchable text, or completely missing.
  • The biggest gap was AI Specificity. The databases don't have fields to say "This device uses a Neural Network" or "This was trained on MRI scans from 2020." It's like a car registry that lists the car's color but doesn't list the engine type.

The Three "Stress Tests"

To prove this wasn't just a theory, they ran three specific tests:

  1. The "Find the AI" Test (USA): They took a list of 1,400 known AI devices from the FDA's own special list and tried to find them in the main public database using only the standard search fields.

    • Result: They could only find 2.5% of them using standard search terms. The other 97.5% were invisible unless you knew exactly which "special list" to look at. The main database didn't even have a box to check "Is this AI?"
  2. The "Bulk Data" Test (China): China has a massive database of medical device IDs that you can download.

    • Result: While the data is downloadable, it's "AI-blind." It has no specific fields for AI. To find an AI device, you have to guess by reading the free-text description, which is like trying to find a specific book in a library by reading the title of every single book on the shelf.
  3. The "Family Tree" Test (USA): They looked at 70 different versions of AI devices from the same companies to see if the database showed how they were related (e.g., "Version 2.0 is an update of Version 1.0").

    • Result: Zero of the 70 records had a structured field linking them. You can't see the family tree; you just see a list of unrelated names.

The "Five Types of Missing Pieces"

The authors realized that "missing data" isn't always the same problem. They created a new way to categorize the gaps, like a mechanic diagnosing a car:

  1. Schema Gap (The Missing Slot): The database literally doesn't have a box for this information. (e.g., No box for "Training Data"). Fix: Add a new box.
  2. Publication-Access Gap (The Locked Drawer): The regulator has the data, but they haven't put it on the public website. Fix: Open the drawer.
  3. Structuring Gap (The Messy Note): The data is public, but it's written in a long paragraph or a PDF. You can read it, but a computer can't search it. Fix: Turn the paragraph into a checklist.
  4. Linkage Gap (The Broken String): You have the device record and the safety warning, but there is no unique ID to tie them together. Fix: Add a connecting string (a unique ID).
  5. Population Gap (The Empty Box): The box exists, but it's left blank by the manufacturer. Fix: Enforce rules to fill the box.

The Solution: A "Minimum Viable" Upgrade

The paper doesn't ask for the impossible (like releasing secret source code or patient data). Instead, they propose a Minimum Public Data Extension.

Think of it as adding 20 new, simple fields to the existing registration forms.

  • Instead of a paragraph describing the software, add a dropdown menu: "Deep Learning," "Rule-Based," or "Hybrid."
  • Instead of a PDF summary, add a link to the specific evidence.
  • Add a "Version Number" field that updates every time the software changes.

Why this matters:
Currently, a hospital buying an AI tool has to guess if the tool they are buying is the same one that was tested. They can't easily see if the tool has changed since approval, or if it was trained on data that matches their own patients.

The paper concludes that until these public records are upgraded from "static approval lists" to "dynamic lifecycle trackers," hospitals and safety officers cannot reliably govern these devices. They can verify the device entered the market, but they cannot manage it while it is in the market.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →