Testing evidence and limitations: what MedCam can verify
MedCam is a privacy-first browser tool for photographing medical films and paper records. Publicly described testing is engineering validation of the code, not proof that a photographed X-ray, MRI, CT film, ECG or report is diagnostically sufficient. This page explains what the available test assets exercise, how to reproduce a basic check and what remains unknown.
What the automated checks actually cover
| Area | How it is tested | What that does not prove |
|---|---|---|
| Browser camera state | Simulated permissions, camera switching, muted/disconnected streams, timeouts and Auto/Manual state transitions. | Compatibility with every physical sensor or OS camera driver. |
| Film framing and quality | Generated pixel patterns with different blur, light, framing, borders, reflections and large obstructed regions. | Accuracy on every real X-ray, CT, MRI or medical document. |
| Device capabilities | Simulated camera track capability/settings combinations, including missing or failing advanced controls. | That a named handset implements each browser API correctly. |
| Image intake and exports | Encoded sample files, malformed file inputs and browser-based JPG/PNG/PDF/UMF handling. | That every recipient app can open, receive or understand each format. |
| Layout and interaction | Automated Chromium viewport checks, navigation and UI workflows. | Physical Safari, Firefox, Android or iOS rendering certification. |
Engineering test record — 3 November 2026
For this release, 25 existing MedCam v6.2 Node.js engineering test scripts were executed locally on Node.js 22. All 25 completed without errors. These checks are test harnesses with synthetic frames, mocked APIs and generated files; they are not an independent audit, real-hardware benchmark, clinical validation study or certification.
| Area tested | Reproduced local result | What remains unproven |
|---|---|---|
| Browser and camera capability handling | Mocked camera permissions, focus, torch, zoom, interrupted streams and missing features passed. | Physical camera behavior across Android/iOS and multiple sensors. |
| Quality, framing and retake rules | Unit tests, deterministic fuzz patterns and exposure/blur scenarios passed. | True sensitivity for important features in actual medical films. |
| Image intake and export | Mocked sharing, ZIP safety, UMF parsing and PDF output tests passed. | Receiving-app compatibility and physical-device file permission behavior. |
| Adaptive UI, download and privacy rules | Capability visibility, fallback logic and filename tests passed. | Cross-browser accessibility on every operating system and zero risks from future integrations. |
Truthful denominator: 25 software test scripts passed; no physical-device trial or clinical benchmark was executed as part of this release. Large simulated profile counts in script output represent synthetic cases, not individual phones or patient images.
Read the machine-readable test log (JSON). These results can be repeated with the corresponding archived v6.2 source scripts in a local Node.js environment. An actual-browser camera test requires permission and physical hardware.
Evidence and how to reproduce it
Development source packages include named test cases, such as quality-fuzz-10000.mjs, malformed-input-stress.mjs, device-profile-stress.mjs, capture-stability.test.mjs and browser smoke tests. These tests deliberately use synthetic data or simulated devices. A successful software test only means the particular asserted behaviors passed in that environment and version. Test counts are not a medical-quality accuracy percentage.
To check your own browser, visit Browser Self-Test, grant permission only if comfortable, and inspect camera capabilities locally. To compare quality suggestions with human decisions, use the local Validation Lab on authorized, de-identified photos. Neither lab uploads photos to MedCam's static hosting server. For independent validation, preserve the exact software version and record the device/browser details separately from patient identifiers.
What a proper real-photo validation study would require
A meaningful evaluation would include multiple device price tiers, camera sensors, browsers, operating systems and lighting conditions, with representative authentic photographs for each of the film and document types the tool supports. Qualified reviewers should label at least framing, blur, glare, readable labels and whether a retake is necessary for the photographic task. Any clinical suitability claims would require additional domain-specific medical assessment.
Measure false ready separately from false retake: a false ready occurs when software suggests a photograph can be kept but a reviewer determines it should be retaken; a false retake occurs when software warns yet the reviewer accepts the photograph. Record the number and type of samples behind each rate. Report uncertainty and reviewer disagreement, not just a single attractive percentage.
Known limitations and non-claims
- No guarantee of 100% photo-quality, clinical or diagnostic accuracy.
- No globally certified medical-image model and no claim that UMF is a recognized DICOM alternative.
- Photo positioning arrows provide approximate 2D framing assistance; they are not calibrated sensor-to-film distance measurements.
- Browser capability checks cannot identify every hardware feature or make unsupported controls work.
- Share sheets are controlled by the receiving operating system/app. MedCam cannot guarantee delivery or select recipients.
- A visually clear film photograph is not equivalent to original digital diagnostic imaging data.
Our publishing approach
This project currently describes independent technical testing, not independent clinical certification. If verifiable real-camera benchmark results or external reviews become available, they should state the device, browser, test protocol, number of observations, failures and the limits of each finding. Until then, users should follow their clinician's file requirements and seek original study data or formal reports when needed.
Publisher: MedCam — Powered by Sundo.live. Responsible operator and monitored public support details must be supplied before an advertising application. About this project · Medical disclaimer · Photo review checklist.
Representative scenarios and what we observed
Scenario A — camera control missing: synthetic device capability objects with no torch or manual focus were processed by the compatibility logic; tests verified that unsupported UI controls were not presented. This is evidence about feature-gating logic, not a claim about every actual browser.
Scenario B — unstable image: synthetic frame transitions representing movement were fed to capture-stability tests. The gate delayed Auto Capture under those conditions. Glare and fine-label readability on real films still require human checks.
Scenario C — malformed or unsupported file: image intake and container/ZIP parser tests exercised invalid data and rejected dangerous inputs. A successful parse does not prove that an exported file is accepted by any particular hospital workflow.
Not yet executed for this site: a documented real-device matrix on Android Chrome, Samsung Internet, iOS Safari, desktop browsers, low-memory handsets and authentic de-identified film photographs rated by independent reviewers. Do not interpret the automated test count as the percentage of real images MedCam handles correctly.
For a safe user-controlled capability check, open Browser Self-Test. For manual photographic review, follow the seven-step review checklist.