Before asking how quickly a computer can classify a skin image, a research team needs to decide what the image represents and what the experiment is meant to measure. A dermatoscopic image of a pigmented lesion and an ordinary camera photograph have different acquisition conditions. Combining them without a clear plan can make a test result difficult to interpret.
For AINA and SupraWorx Workbench, a local skin-image workflow remains a research proposal. The software includes generic image intake, file storage and links to measurement records. A dedicated skin classifier, its dataset and a Clara AGX integration would need to be specified and implemented separately.
Put the computing platform in context
NVIDIA introduced Clara AGX in 2020 as a development platform for medical-device algorithms, combining computing hardware with software libraries and example applications. That provides historical context for the proposed architecture. A development platform does not itself establish which skin conditions a model can classify, how its labels were obtained or whether it is suitable for a clinical task.
Choose one research question and image type
A manageable first study could examine how a specified classifier performs on a defined set of existing research images. Describe the target labels, accepted image formats, acquisition method and exclusions before running the model. Keep experimental outputs separate from clinical decisions.
The HAM10000 dataset described by Tschandl, Rosendahl and Kittler (2018) illustrates why these details matter. It contains dermatoscopic images of common pigmented lesions assembled from different sources, with several methods used to establish reference labels. It is a research dataset with a particular scope, not a complete collection of skin conditions or a substitute for testing ordinary photographs.
For each dataset considered, review its permitted uses, image provenance and label-confirmation process. Record whether a label comes from pathology, follow-up, expert consensus or another method. Keep repeated images of the same lesion—and, where identifiers allow, the same person—within one data split to avoid testing on closely related examples already used during development.
Test beyond the development data
Choose a final test set that was not used to select the model, tune it or choose its decision thresholds. Report the number of examples and errors for each target class. Where a score is turned into a binary decision, show both the missed target cases and the incorrectly flagged cases at the chosen threshold.
Daneshjou and colleagues (2022) found substantial limitations in existing dermatology models on their Diverse Dermatology Images benchmark, particularly for darker skin tones and uncommon diseases. The study used a retrospective, biopsy-selected clinical-image collection; it does not describe every setting. It does show why an overall score on familiar data is an incomplete evaluation.
Examine relevant subgroups and acquisition conditions, with sample counts and uncertainty rather than a claim of equal performance based on very few examples. Include blurred images, unexpected image types and labels outside the intended scope. Decide how the research workflow will mark inputs it cannot evaluate rather than forcing every image into a familiar category.
Trace the image and the result
A proposed Workbench connection should retain a stable research identifier, source-image checksum, preprocessing settings, model version and raw output. Keep researcher corrections and exclusion reasons separate from the original output so the experiment can be repeated and compared fairly.
Local inference also needs an explicit data-flow design. Check where uploads, temporary files, logs, backups and results are stored and which services can receive them. The existing generic intake path supports server uploads; an on-device model alone would not establish that images remain on the device. Access, retention and permitted research use must be addressed for the actual configuration.
Measure the complete workflow
Benchmark image loading, preprocessing, inference and result storage together, including failures and concurrent requests. Record the hardware and software configuration with the measurements. A useful first deliverable is a reproducible research report covering accuracy limits, subgroup results and operational behaviour. Clinical readiness or improved patient outcomes would require separate evidence from an appropriately designed evaluation.
