A device on a register is a device that may be sold. Whether it
works here, for these patients, on the version currently running, is decided by
everything that happens after. The second half of the battle, in small
pieces.
“Approved” is a statement about a dossier.
“Working” is a statement about your department.
Registration is a real bar: a dossier of evidence, examined by a regulator,
against a declared intended use, with obligations that continue after
clearance. What it cannot tell you is how the device behaves in your
department. Does it work on our patients? Does it fit our workflow? Is the
version running today the version we validated? Is it still performing this
year? Those questions are answered locally, after registration. Or, if nobody
owns them, never.
I keep a register of AI-enabled medical devices
cleared for supply in Singapore. It is a record of start lines. What happened
next has a public trail only when something goes wrong: a safety alert, a
recall, a corrective action. Which tools are in routine use, and how they
perform day to day, has none; quiet successes and quiet shelvings leave no
trace. That silence is the subject of this page.
Day one
What approval settles, and what it can't
This is not a failing of the regulator. It is the scope of the instrument.
A registration examines evidence gathered before the device reached you,
usually from populations, and almost always from departments, that are not
yours. Some
questions can only be answered locally, because the answer is different in
every department.
Settled at registration
The device may legally be supplied
An intended use is declared and bounded
Safety and performance evidence passed central review; significant changes go back through it
A manufacturer with a quality system stands behind it
Answered centrally, for everyone
Still open on day one
Performance on your population, scanners and protocols
Where the output lands, and who acts on it
What happens when it is wrong, in either direction
Whether next year's version still deserves last year's trust
Answered only locally, by you
The snapshot that matters is yours: whatever the regulator reviews, your
department validates one version at one moment, and nothing around that
measurement stays still:
Population
Scanner fleet
Protocols
Disease mix
Referral patterns
The software itself, at each update
“Your validation is a snapshot.
Nothing it measured holds still.”
The deployment half
Five pieces of work before the tool touches care
Deployment done seriously is not installation. It is a sequence of decisions,
each carrying the questions worth asking, in writing, before go-live. The
numbering starts here and does not restart in the next section: it is
one lifecycle, not two projects.
01 · Validate before go-live
The silent run
The model reads your cases; nobody acts on its output yet
However good the development evidence, it was not gathered
in your department: different patients, different scanners, different
disease prevalence. A shadow period, with the tool running silently
against your own readers on your own casework, is how you learn how it
behaves here; a small site cannot settle every subgroup question, but it
measures what its volume allows.
“On our cases, how often does it disagree with our readers, and when it does, who was right?”
“Which of our subgroups did the vendor's validation see least?”
02 · Integrate the plumbing
Where the output lands
A correct result in the wrong place is an incorrect system
An algorithm can be right and still useless if its
result arrives after the report is signed, on a screen nobody watches, or
in a worklist nobody sorts by. Integration is not an IT afterthought; it
decides whether the tool's output ever meets a decision it could improve.
“Which screen does the result appear on, and at what point in the read?”
“If the interface between the tool and the PACS fails silently, who notices, and how fast?”
03 · Design the human half
What a person does with it
Every output needs a defined action, including the wrong ones
The workflow question is not “what does the tool
say?” but “what does a human do when it says it?” That
must be defined for the false positive and the false negative separately,
because they fail differently: one costs attention, the other costs a
finding. Automation bias is a workflow property, not a user flaw.
“What exactly happens on a false positive? On a false negative? Are those answers different?”
“Who may overrule the tool, and where is the overrule recorded?”
04 · Gate in writing, in advance
Acceptance criteria
Decide what failure looks like before you have a reason to excuse it
A pilot without pre-agreed thresholds cannot fail; it
can only be reinterpreted. The gate must be written before the silent run
begins: what performance, on what metric, over what period, admits the tool
to clinical use, and what result stops the project. Unwritten criteria
protect nobody.
“What result would make us stop, and did we write it down before we started?”
“Who signs the go-live decision, by name?”
05 · Train then go live
The users know the edges
Intended use is a boundary, and every user should be able to draw it
Training that only covers how to use a tool trains half a
user. The other half is knowing what the tool was not built for: the
populations it hasn't seen, the question it doesn't answer, the confidence
it doesn't deserve outside its intended use. That boundary was declared at
registration; deployment is where people must learn it.
“Can every user say what this tool was not approved to do?”
“Do new joiners get the same briefing a year from now, or only the launch cohort?”
The forever half
Five pieces of work that never finish
Go-live is where the tense changes, not where the work ends. Everything
before this line happens once; everything after it happens for as long as the
tool runs.
Monitor
→
Detect
→
Investigate
→
Act
→
Re-validate
→
again, for every year it runs
06 · Watch continuous
Drift has no announcement
Performance decays quietly, under a tool that looks exactly the same
A new scanner, a protocol tweak, a shift in referral
patterns: the model meets data it wasn't validated on, and its
output stays fluent while its accuracy moves. Drift is found by
measurement, never by impression: the interface looks identical the day
it works and the day it doesn't. And measurement needs ground truth;
someone has to read a sample of current cases against the tool, so that
work must be planned, not assumed.
“Which metric do we watch monthly, and who looks at it?”
“Would we notice a slow decline, or only a crash?”
07 · Control every update
The version you validated may not be the version running
Software moves; each update is a small act of re-deployment
Vendors version and document their releases; regulators
plan for change. But locally, the thing running in eighteen months may
not be the thing your silent run measured. An update should re-enter the
lifecycle at step 01, in proportion to its size; last year's trust does
not transfer by itself.
“Do we know, today, which version is running, and which version we validated?”
“What size of update sends the tool back to a silent run?”
08 · Report whenever it happens
An incident route people will actually use
“The AI got this one wrong” needs somewhere to go
Departments have long had reflexes for reporting a contrast
reaction or a mislabelled specimen. A wrong AI output needs the same:
a route that is known, fast, and blame-free, feeding the vendor,
the governance committee, and where required the regulator. The
post-market reporting regime is real and enforced; a local reporting
culture is what feeds it.
“If a reader catches the tool being wrong tomorrow, does she know where to send it?”
“Is reporting an error easier than ignoring it?”
09 · Audit yearly
The annual question
Is it still doing what we admitted it for?
Launch-month numbers age. A periodic re-measurement against
current casework, the same discipline as the silent run at a smaller dose,
is what separates “we deployed it properly” from
“we deployed it properly, once.” The audit also catches the
quieter failure: a tool that still works but is no longer used.
“Would this tool pass its own acceptance gate today?”
“Is anyone still acting on its output, or is it running for nobody?”
10 · Retire eventually
The off switch is part of the plan
Decommissioning criteria are written at adoption, not at the funeral
Every deployed tool will one day be switched off:
outperformed, unsupported, unused, or no longer worth its integration
burden. Writing the retirement criteria on the day you adopt, and holding
them in view for as long as it runs, is what makes switching off an act
of governance rather than an admission of failure. A tool retired on its
stated criteria is the lifecycle working.
“What usage floor, performance floor, or support event retires this tool?”
“When it goes, what happens to the workflow that grew around it?”
The owners
Whose job is all this?
All of them, and none alone. Vendor duties are real and continue after
sale, through surveillance and corrective action, but no vendor can own your
workflow or your clinical accountability. IT keeps the tool alive; readers
catch it being wrong; the champion who brought it in supplies the drive.
All of that is necessary. None of it, alone, is the structure that holds
the ten pieces together.
The work above crosses professions and runs up and down the hierarchy,
radiographer to reader to department head to institution, clinical to
technical to administrative. Accountability has to travel the same way:
diagonally. I make that point at SGCR 2026, the Singapore Congress of
Radiology; the one-page version lives at
/diagonal.
“Enthusiasm is not
a governance structure.”
The consensus
None of this is contrarian
The lifecycle view is not a niche opinion; it is the stated position of the
bodies that think about this for a living. The register measures the start
line because that is what a register is for. The same institutions say,
in writing, that the race is longer.
Singapore's AI in Healthcare Guidelines, jointly
issued by the Ministry of Health, HSA and the national health-tech agency,
extend well beyond development into implementation and ongoing
monitoring. The local rulebook already assumes a second half.
HSA's own regulatory guidelines for software as a medical
device are explicitly a lifecycle approach, built on the IMDRF
framework: they follow the software past clearance and already provide for
pre-agreed change management.
The US FDA's total-product-lifecycle approach points
the same way: a predetermined change control plan lets one approval cover
an agreed scope of future change, reviewed in advance.
The WHO's guidance on AI for health places
post-deployment monitoring and auditing among the core obligations of anyone
running these systems, not the optional extras.
The caveats
What this page is not claiming
No product, and no site, is being assessed. This page
describes a process, not any device on the register and not any department;
institutions carry governance duties of their own, and good sites already
do much of this. A map of the work, not an audit of anyone.
Half is not small. Registration is real work against a
real bar. The argument is about what the instrument measures, not
about effort or rigour.
This is not a compliance manual. Which metrics, what
thresholds, what committee shape: institution-specific, and the dose scales
with the site; a cluster and a small practice do different amounts of the
same ten things. One clinician's map, not a standard issued by anyone,
and not regulatory advice.
The examples lean radiology. Because that is my
workshop. The lifecycle argument is general: the same second half
exists for every AI-enabled device on any register, in any specialty.
The register
The start lines, listed
The AI-enabled medical devices registered for supply in Singapore,
described in plain language: what each reads, what it claims, where it
sits in the workflow. A record of first halves.
The interesting question about every entry on it is the one a register
cannot answer: what happened next. That answer doesn't live in any dossier.
It lives in departments, in silent runs, acceptance gates, monthly
metrics and honestly written off switches. Registration is the half you can
look up. This page is about the half you have to do: not to slow adoption,
but to make it stick.