Prepared by the scanO editorial team. Editorial draft prepared 2 November 2026; independent specialist review pending.
Quick answer: Evaluate an AI dental screening device using its intended use, product-specific evidence, clinician review, complete workflow and data/commercial terms. Require written answers and a practical test. A high score on convenience must not compensate for an unsupported clinical claim or an essential privacy gap.
A demonstration naturally highlights successful captures and attractive reports. Procurement must also test uncertainty, failed images, disconnected systems and staff changes. The fifteen questions below turn a promotional conversation into a reviewable buying process.
1. What is the exact intended use? Ask which input and conditions the system supports, who should use it and in which setting. Screening, diagnosis, treatment planning and patient education are different claims.
2. Which version is being supplied? Record hardware, software and model identifiers where relevant. Evidence from an earlier or different model should not automatically be transferred to the offered system.
3. What evidence supports that use? Request the population, reference standard, independent evaluation and limitations. A general AI research paper is not product validation. Performance should include meaningful denominators and uncertainty rather than an isolated accuracy percentage.
4. What happens with poor images? Ask for failed-capture and unable-to-assess examples. A product should not force confidence where the input is outside scope.
5. How does the dentist review and disagree? The clinician needs a clear record of the machine output and their own assessment. No flag should automatically become a treatment instruction.
6. What is the fallback? Test the process when capture, connection or report delivery fails. Clinical assessment and appropriate referral should remain available independently of the device.
7. How is the correct record maintained? Run a synthetic encounter, correct an intentional identification error and retrieve the audit trail. An attractive report attached to the wrong person is a serious workflow failure.
8. What does the patient receive? Test understandable language, private delivery and an alternative for someone without a smartphone. Confirm how limitations are explained.
9. How much staff time is required? Observe permission, registration, capture, retries, clinical review and handover. Do not use analysis time as total encounter time or publish invented throughput.
10. Which entities process the information? Obtain the relevant contract, purpose and vendor/subprocessor information where applicable. Do not infer data residency or training use from a generic security slogan.
11. How are permissions and records controlled? Test roles, exports, retention arrangements and departure of a staff member. A feature is useful only if the clinic operates it appropriately.
12. How will the vendor support legal readiness? The government's DPDP explanation describes a phased framework; a vendor label cannot settle every clinic obligation. Request evidence and have the relevant legal questions reviewed.
13. What changes after an update? Ask for release/change information, version continuity and access to historical reports. Clarify whether new claims require new evidence or training.
14. Who handles service? Verify installation, training, warranty components, support route, local response and replacement arrangements. Ask the team to demonstrate how a complaint is logged.
15. What is the full commitment? Obtain acquisition, taxes, recurring costs, data export and exit terms. Confirm separately priced products and the consequences of ending a subscription.
The scanO air product page provides public product context. Ask the same evidence, workflow and commercial questions as for another vendor. Do not waive an unanswered requirement because a device has an appealing report or a familiar brand.
This guide does not describe scanO air as a cancer diagnostic device, a replacement for radiographs or an independent source of treatment decisions. Product suitability must be assessed against the exact supported use and clinic workflow.
First review essential clinical, regulatory and data questions. Next test the operating workflow with synthetic records and, where appropriately approved, a supervised local pilot. Finally compare the full commercial terms and implementation responsibilities.
Record accept, retest or reject with reasons. Do not calculate a final recommendation while a mandatory requirement is unanswered. Use the AI equipment capability test and DPDP clinic checklist as supporting tools, then keep the completed vendor answers with the purchase decision.
Send the checklist before the demonstration and ask the supplier to identify the documents available for each question. This gives the meeting a practical structure and reduces the chance that missing evidence is hidden by a long feature presentation. Keep unanswered items on the record rather than treating the meeting itself as verification.
Use the exact proposed setting in the request. A fixed clinic, a school event and a multi-site outreach programme can have different access, staffing and record needs. Ask the vendor to distinguish currently supported functions from roadmap items. A planned feature should not be scored as delivered.
Where documentation is confidential, agree an appropriate review route rather than inventing its contents. The clinic can record that evidence was reviewed by the responsible specialist without publishing proprietary detail. However, a claim of confidentiality should not become a reason to accept an unsupported clinical promise.
An acceptance record should state the approved configuration, intended use, observed tests and unresolved conditions. If approval depends on a role-control fix or a revised report label, name the required change and retest. Do not write accepted with no issues while the same document lists a mandatory gap.
Separate delivery, commissioning and clinical deployment. A unit can arrive correctly while staff training or data review remains incomplete. Identify who authorises each stage and what evidence is required. This makes the rollout easier to manage without asking staff to infer readiness from the presence of equipment in the reception area.
Plan an early operating review after staff have used the workflow. Check whether the failure process, record matching and patient explanation work outside the demonstration. Document support requests and the vendor's response. A procurement decision should remain open to relevant evidence from ordinary use.
Finally, preserve the boundary of the approved claim in marketing and staff training. New creative, a revised sales script or an influencer demonstration can accidentally expand what the clinic says the device does. Use the acceptance record as a reference so the public promise stays aligned with the evidence and supported clinical role.
Question groupRequired evidenceDecision rule1–3: intended use/version/evidenceWritten scope and product-specific evidenceStop if the proposed clinical claim is unsupported4–6: failures/clinician/fallbackDemonstrated uncertainty and independent clinical pathwayRetest if failure handling is unclear7–9: records/patient/staff timeSynthetic end-to-end task with observed effortDo not infer throughput from analysis time10–12: data/control/legal readinessRelevant documentation and role/access testEscalate unresolved legal and privacy questions13–15: updates/service/costWritten support, change, export and commercial termsCompare only complete offers
One row per vendor answer: question number; answer; source/document; version; verified by; observation date; PASS/PENDING/FAIL; missing evidence; owner; target date; final resolution. A pending essential requirement remains visible even when other answers pass.
For further practical context, see how AI dental screening works. These resources support planning; adapt decisions to your clinic and review clinical requirements with qualified professionals.
