We have created an AI screening tool for oral cancer that works like this:
CHW fills a form
If eligible, the client’s oral photos are taken to screen for oral cancer
The device runs a lightweight inference to determine the risk of cancer
If high risk is detected, the images are synced when online for review during referral
I want to know the difficulty of achieving these steps with CHT. The user will need to capture 6 to 8 photos for accurate risk scoring. Would syncing them succeed eventually even with patchy internet or keep retrying from scratch and failing? Is it possible to add logic for selectively syncing photos for only those cases where the risk is high?
What an exciting use case — using CHT to support oral cancer screening at the community level is exactly the kind of high-impact application we love to see. Happy to walk through the feasibility of each step.
Workflow feasibility
Capturing multiple photos in a form — This is supported. Whether the number of photos needs to be fixed (e.g., always 6) or variable (6–8), there may be some core work involved, but this is fine-tuning rather than a fundamental limitation. Uploading multiple images is already possible.
Passing form data to an external Android app for inference — Launching an external Android application and passing data to it from CHT is technically possible, though it’s not a common workflow today. It would need to be prototyped and tested to confirm it works reliably end-to-end.
Conditionally storing images based on the inference result — Selectively retaining images only for high-risk cases should be achievable within CHT’s existing form logic capabilities. This would be an important optimization and is worth designing for from the start.
Sync behavior and important considerations
The good news is that sync in CHT is resilient — it will keep retrying until it succeeds, so a patchy connection won’t cause data to be permanently lost. That said, there are a few real constraints worth planning around:
Payload size limit — Our server has a 32MB maximum per sync request. Binary data (like images) is sent as base64 encoded text within JSON documents, which increases file size. If a batch exceeds 32MB, CHT will automatically retry with a smaller batch, down to a minimum of one document. This means a single screening report with all its images must stay under 32MB — something worth validating with your expected photo sizes and count.
On-device storage — All attached media is stored on the device unless documents are explicitly deleted. For CHWs conducting regular screenings, storage usage can grow significantly over time and can also affect performance.
Initial sync on new devices — This is the most important consideration to plan for. When a CHW logs in on a new device, CHT-Webapp downloads all data assigned to them — including every previously submitted report and its media. For a CHW who has screened many patients, this initial sync could involve hundreds of reports with images, making unusable to start, especially on poor connectivity.
The standard solution for this is purging — a process that removes older documents from the device and initial sync (while keeping them safely on the server). If you anticipate CHWs conducting screenings regularly, designing a purging strategy early is strongly recommended.
Overall, I think the workflow you’ve described is achievable with CHT, with the sync and storage considerations being the most important factors to validate early in your build. Would love to dig deeper into any of these areas.