Radiology AI and CDSCO: A Buyer's Verification Checklist

Software intended for a medical purpose falls within the definition of a medical device under the Medical Device Rules 2017, framed under the Drugs and Cosmetics Act, and the regulatory framework has progressively brought all such devices into scope. Devices are placed into risk classes A through D, where A is lowest risk and D is highest, based largely on the potential harm arising from a failure. The class determines which authority licenses it and what evidence the manufacturer had to hold.

Radiology AI typically sits in the middle of that range. A tool that flags a study for prioritisation is generally reasoned about differently from one that proposes a diagnosis on which a report may rest, and a tool that is used without a radiologist in the loop is different again. Ask the vendor to state the class, and then ask them to explain the reasoning, because a supplier who cannot articulate why their product is Class B rather than Class C has probably not been through the exercise properly.

Domestic manufacturers and importers follow different routes, and knowing which applies tells you what to ask for. A manufacturer holds a manufacturing licence issued by the state licensing authority for lower classes or by the central authority for higher ones. An importer holds an import licence issued centrally, obtained on the strength of the overseas manufacturer's approvals and a registration by the Indian agent. In either case a specific document exists, with a number and a validity, and you are entitled to see it.

Vendor presentations use regulatory language loosely, and some of the loosest phrasing is not dishonest so much as imprecise. CE marked, FDA cleared, CDSCO approved and CDSCO registered mean different things, and a product may hold one and not the others. Ask for the actual certificate or licence document rather than a claim on a slide, then check that the entity named on it is the entity you are contracting with and that the product name and model on it match what you are buying.

Check the scope carefully. An approval covering a chest radiograph triage application does not extend to the same company's head CT product, and a licence issued to an importer for one version does not automatically cover a substantially changed successor. Where the product is delivered as a cloud service that updates continuously, ask specifically how the regulatory position is maintained across model updates, because a model retrained after approval raises a question the vendor should have a documented answer to.

Where a product is genuinely outside the device framework, that can still be a legitimate purchase, but it changes what you may use it for. A tool that reorders a worklist without asserting anything clinical about the images is a different proposition from one that annotates a finding. Be explicit internally about which you have bought, and write that into the clinical governance approval, so that the department cannot later drift into using a workflow tool as a diagnostic aid.

The intended use statement is short, dull and decisive. It says what the software is for, on which patient population, on which image types, and in what role relative to the clinician. Everything you are permitted to expect from the product and everything your liability position rests on flows from it. Read it before the brochure, and read it as though a lawyer will read it back to you after an adverse event, because that is exactly the circumstance in which it will next be read.

Pay attention to the role wording. Concurrent read, second read, triage and autonomous operation are different claims with different consequences. A tool intended as a second read is designed on the assumption that a radiologist has already formed an opinion, and using it as a first pass in a busy session changes the risk profile in a way its validation may not support. If the department intends to use it differently from the stated role, that is a decision requiring clinical governance sign-off and a documented rationale.

Check the population and image scope against your reality. A product validated on adults may state that paediatric use is outside its intended use, which matters if your emergency department scans children on the same machine. A product validated on particular scanner manufacturers and acquisition protocols may perform differently on your ten-year-old CT. These constraints are usually stated honestly in the instructions for use and almost never mentioned in the demonstration.

Ask what data the model was trained and validated on, in terms of geography, demographics, disease prevalence and scanner mix. This is a fair question and a serious vendor will answer it. Performance figures generated on a population with a different prevalence of the target condition will not transfer directly, and the practical effect usually shows up as a positive predictive value that looks nothing like the demonstration, which is a workload problem as much as a clinical one.

The ICMR ethical guidelines for the use of artificial intelligence in biomedical research and healthcare set out expectations around validation, transparency and accountability that are worth reading before you evaluate any tool, and they are a more useful framing document than most vendor white papers. Where a product has been validated in India, ask for the details: which sites, how many studies, what the reference standard was and who adjudicated disagreements.

Then run your own silent evaluation before the tool influences any report. Have it process studies in parallel for a defined period with outputs invisible to the reporting radiologist, and compare against the signed reports. This costs a few weeks and some effort to set up. It is the single most informative thing you will do, because it tells you how the product behaves on your scanners, your protocols and your case mix rather than on someone else's, and it gives you a baseline against which to detect drift later.

An AI result has to arrive somewhere a radiologist will see it at the moment it is useful, and this is where many deployments quietly die. If the output appears in a separate portal requiring a second login, it will be checked for a fortnight and then ignored. If it is burned into the images as an overlay that cannot be turned off, radiologists will resent it and it may complicate the archived record. The integration question deserves as much attention as the accuracy question.

Decide how the output is recorded. There is a meaningful difference between an AI finding that informs the radiologist and one that is quoted in the signed report, and the second requires a policy on attribution: does the report state that a computer-assisted tool was used, and if the radiologist disagrees with the tool, is that disagreement recorded. Departments that leave this to individual preference end up with inconsistent reports and no way to audit the tool's contribution.

Also decide what happens when the service is unavailable. A cloud-hosted tool that becomes part of the triage process creates a dependency, and a department that has reorganised its worklist around AI prioritisation needs a defined fallback for the morning the link is down. Write it into the downtime procedure alongside your PACS and RIS contingencies rather than discovering it live.

Contract for the things that will actually go wrong. Where studies leave your premises for processing, the vendor is processing personal data on your behalf and the DPDP Act 2023 obligations follow, which means a written arrangement covering purpose limitation, security, sub-processing, breach notification and deletion on termination. Ask specifically whether your images are used to train the vendor's models, and if so, on what basis and with what de-identification, because the default answer in many contracts is more permissive than hospitals expect.

Build monitoring into the arrangement rather than bolting it on. Agree what performance data you will receive, how model updates will be notified in advance, and what right you have to re-run your silent evaluation after a significant update. A tool that is never re-evaluated after go-live is being trusted on the strength of a six-week trial conducted on a version that no longer exists.

Finally, agree the exit. What happens to your data on termination, in what format outputs already generated are retained, and whether historical AI annotations remain readable once the licence ends. This is unromantic contracting and it is the part you will be grateful for. The honest overall trade-off with radiology AI today is that the useful products are genuinely useful and the diligence is genuinely more work than buying ordinary software, and doing the diligence badly transfers the risk to the radiologist signing the report.