# Smart task prioritization v1

**URL:** <https://forum.communityhealthtoolkit.org/t/smart-task-prioritization-v1/5718>\
**Category:** Squads\
**Created:** [August 6, 2026, 8:13pm UTC](https://forum.communityhealthtoolkit.org/t/smart-task-prioritization-v1/5718 "2026-08-06T20:13:27Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![diana](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/diana/32/2049_2.png) [@diana](https://forum.communityhealthtoolkit.org/u/diana)\
**Post date:** [August 6, 2026, 8:13pm UTC](https://forum.communityhealthtoolkit.org/t/smart-task-prioritization-v1/5718/1 "2026-08-06T20:13:27Z")

</div>

This project started with an ambitious goal: **bring AI inference into the way tasks get prioritized for CHWs**.

Several factors feed a task’s priority score. The main ones are severity or importance of the task (for example, high-risk pregnancy visits), proximity to the CHW’s current location, and closeness to the task due date or overdue status.

In our initial thinking, we envisioned a future where inference as capable as today’s commercial models would be available to CHWs. We have since discovered serious limitations.

First, scoring must work while the user is disconnected from the internet, potentially for days at a time. This rules out a server-side process, whether self-hosted or third-party. It also rules out a hybrid approach — computing scores online ahead of time — because priority depends on the CHW’s current location, which shifts through the day, and on local changes to documents that weren’t part of the initial calculation. Pre-computed scores go stale very quickly.

Second, the devices CHWs use are relatively low-spec, low-cost, and often running on low battery. Some open-source local models today work well on flagship phones, but expecting those same models to run on low-end devices several years old is unrealistic.

**Our goal is to improve the task page experience for all CHWs, not just those who have full connectivity or powerful devices.**

That means a trajectory shift: away from large LLMs, toward small models that can run on a low-spec device while it’s offline. This is less of a compromise than it first appeared. Task prioritization is a ranking problem over a handful of structured features — severity, distance, days overdue — and that is what small models are good at. The truly smart version can come later. For now, given team resource constraints, we are choosing to focus on a closer-term more  
feasible deliverable.

The new plan is to start in smaller steps and build everything in-house (or with external help, if that becomes available).

First step: a heuristic based on a set of rules, combining the factors above into a single score. The rules themselves aren’t defined yet — that’s the next piece of work. The point is that it’s deliberately simple, ships soon, and gives us a baseline to measure against.

From there: a local machine learning model, baked into the CHT-Android app as an optional build flavor. The heuristic won’t turn into the model, but the interaction tracking we’re shipping now produces the labeled data that would train one. We’ll experiment and choose a model we can prove works on most devices in use with the CHT, then improve it gradually, potentially adding smart functionality to other parts of the application.

How we’ll know it worked:

Time a CHW spends finding the task they need to act on next — should go down.  
Task completion rates — should go up, particularly for high-priority tasks.

Work developed so far:

- task interaction tracking (released recently)
- contact geolocation widget (in progress)

Both exist to gather the data that makes this project possible and its impact measurable — the interaction tracking is what lets us measure time-to-task at all.  
Neither has been collecting long enough to give us a usable baseline yet, so establishing one is a prerequisite for evaluating v1, not a parallel activity.

---

<div class="post-metadata">

**Author:** ![mrjones](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/mrjones/32/681_2.png) [@mrjones](https://forum.communityhealthtoolkit.org/u/mrjones)\
**Post date:** [August 6, 2026, 8:18pm UTC](https://forum.communityhealthtoolkit.org/t/smart-task-prioritization-v1/5718/2 "2026-08-06T20:18:37Z")

</div>

This is awesome to hear about - thanks for the update @diana! For those that want to attend the squad call, I see we have it Wednesdays per [the calendar on the docs site](https://docs.communityhealthtoolkit.org/community/events/).

However, I didn’t see any tickets in the [CHT Core repo](https://github.com/medic/cht-core/issues) - are these still outstanding or did I miss them?

Thanks again!

---

<div class="post-metadata">

**Author:** ![diana](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/diana/32/2049_2.png) [@diana](https://forum.communityhealthtoolkit.org/u/diana)\
**Post date:** [August 7, 2026, 6:14am UTC](https://forum.communityhealthtoolkit.org/t/smart-task-prioritization-v1/5718/3 "2026-08-07T06:14:42Z")

</div>

Just created the issue:

> <https://github.com/medic/cht-core/issues/11330>
>
> \*\*Is your feature request related to a problem? Please describe.\*\*
> The CHT alrea…dy supports sorting tasks by priority. Priority scores are set through app configuration, which means each deployment has to define them itself — and in practice most don't. The result is that the capability exists but the majority of CHWs never see a prioritized task list.
> 
> This issue adds a built-in heuristic that produces a reasonable default score from data already on the device, so deployments benefit without configuration work.
> 
> This does not replace the existing configured-priority mechanism. Deployments that have defined their own priority logic have done so deliberately, often encoding local clinical or programmatic judgment, and that must keep working exactly as it does today. The heuristic fills the gap where no configuration exists.
> 
> Fallback only design — the heuristic applies only when a task has no configured priority. Safest, zero behavior change for configured deployments, but a deployment that configures priority gets none of the proximity or due-date signal.
> 
> \*\*Describe the solution you'd like\*\*
> Define and implement a default scoring function over:
> 
> \- Severity / importance — e.g. high-risk pregnancy visits. 
> \- Proximity — distance from the CHW's current position to the household, using contact geolocation data.
> \- Due date — closeness to due, and how overdue.
> 
> Rules and weights are not yet defined; designing them is part of this work.
> 
> \*\*Out of scope:\*\* 
> \- Changing or deprecating configured priority.
> \- Any ML model — the heuristic is meant to be superseded later, but that's separate work.
> \- Server-side or hybrid scoring.
> \- Changes to task generation.
> 
> \*\*Requirements\*\*
> \- Runs entirely client-side, no network dependency.
> \- Configured priority behavior is unchanged for deployments that use it.
> \- Cheap enough for low-spec devices — no noticeable delay on task list load, no meaningful battery cost.
> \- Degrades gracefully with missing data: no geolocation permission, stale or absent device position, contacts without coordinates. Missing proximity data must not push an urgent task down.
> \- Weights configurable, so we can tune without a release.
> \- Reordering is explainable to the CHW.
> 
> \*\*Open questions\*\*
> \- Recalculation frequency — position changes continuously; recomputing on every update is likely too expensive.
> \- Feature flag or opt-in config, given this changes a core screen?
> \- Should deployments be able to disable the heuristic outright while keeping their own priority config?
> 
> \*\*Measurement dependency\*\*
> 
> Success is measured by time spent locating the next task and by completion rates, especially for high-priority tasks. Interaction tracking was released recently and hasn't accumulated enough data; the geolocation widget isn't released yet.
> 
> \*\*Describe alternatives you've considered\*\*
> We explored using AI inference for this and concluded it isn't viable in the near term: scoring must work fully offline for days at a time, and field devices are too low-spec to run local models of the required size. See \[forum post\](https://forum.communityhealthtoolkit.org/t/smart-task-prioritization-v1/5718).

---

<div class="post-metadata">

**Author:** ![hareet](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/hareet/32/3676_2.png) [@hareet](https://forum.communityhealthtoolkit.org/u/hareet)\
**Post date:** [August 24, 2026, 1:40am UTC](https://forum.communityhealthtoolkit.org/t/smart-task-prioritization-v1/5718/4 "2026-08-24T01:40:05Z")

</div>

## Using AI to author priority score configurations

This builds on the v1 post above, and is not an alternative to that plan, but aimed at a critical bottleneck.

#11330 says it plainly: the CHT already supports priority scoring through configuration, but most deployments never configure it, so most CHWs never see a prioritized task list.

From what we’ve seen, that’s not because partners don’t want it. It’s because authoring a good priority score is genuinely expensive. One partner’s effort ran to months of work across a sizable team of clinical and technical staff before the score was right. The cost isn’t typing `tasks.js` — it’s everything around it: getting clinicians to agree on relative urgency across workflows, mapping that judgment onto fields that actually exist in their docs, expressing it in the priority function, testing it, and iterating when the first version ranks something obviously wrong.

The default heuristic in #11330 fixes this for deployments that configure nothing. But there’s a second group: partners who **want** deployment-specific logic — their own disease burden, their own visit cadence, their MoH’s priorities — and are currently priced out of building it.

## The proposal: assist the authoring, not the runtime

Use AI at build time to make creating a deterministic priority score fast, and keep the runtime exactly as it is today.

Three pieces:

1. **A pattern library.** Opt-in, community-governed examples of how partners have weighted factors for common workflows — ANC, immunization, malnutrition follow-up. Not raw configs, but the reasoning: which factors, which weights, and why. A new partner starts from patterns instead of a blank page. The matching is what makes the corpus useful: a partner describes their workflows and setting, and the tool surfaces how comparable deployments weighted the same factors — “partners running ANC and malnutrition follow-up weighted overdue status like this, for these reasons; partners with dispersed walking catchments discounted distance like this.” Clinical weights are matched on workflow similarity, proximity weights on terrain and transport — always with provenance, always as a starting point for local clinical review, never a default.

2. **Elicitation.** A structured, AI-guided interview with a partner’s clinical and program staff: which task types exist, which patient factors matter, how they trade off. The kind of conversation that currently takes many workshop hours to converge.

3. **Generation.** From the elicitation, draft a priority function against the partner’s actual task schema, following the documented [simple priority score](https://docs.communityhealthtoolkit.org/building/tasks/simple-priority-score/) pattern — with unit tests covering the edge cases (missing data, ties, overdue extremes).

## The hard boundary

Nothing changes at runtime. No patient data is ever sent to a model. The output is plain, deterministic CHT config — reviewed by a clinician, versioned in `cht-conf`, deployed like any other config. If the AI drafts something wrong, it’s wrong in a diff a human reads before it ever touches a device.

That one property is what keeps this simple. It stays fully offline-first, because the device runs the same configured function it runs today. There’s no PHI question, because the model only ever sees workflow descriptions and clinical logic.

## How it fits the v1 plan

I see three layers, not competing options:

1. **Default heuristic** (#11330) — for the majority who configure nothing.

2. **Build-time authoring assistance** (this post) — for partners who want custom logic and can’t currently afford to build it. It also softens the fallback-only tradeoff noted in the ticket: if authoring a full config gets cheap, configured deployments stop missing out.

3. **On-device ML** (the forum post’s later phase) — personalization within a deployment, once the data foundations exist.

There’s also a direct feed into #11330 itself: the ticket notes the default heuristic’s rules and weights aren’t defined yet. A library of how real partners weighted these factors with their clinicians is the best evidence we have for choosing defaults.

## Starting cheap

We don’t need new infrastructure to test the hypothesis. The [CHT docs](https://docs.communityhealthtoolkit.org/ai/mcp-servers/cht-docs-mcp-server) and [code context](https://docs.communityhealthtoolkit.org/ai/mcp-servers/cht-code-context-mcp-server) MCP servers already exist. The increment is a priority-score-specific skill plus two or three worked examples, piloted with one partner who has this on their backlog.

Success is measurable without waiting on anything: time from kickoff to a clinician-approved working config, and how heavily the clinician has to revise the AI’s draft.

Writing out detailed existing scores as case studies and building a corpus of tasks knowledge and existing scoring seems like the first step.

## An ask

If you’ve built a priority score for your deployment — or started one and stalled — sharing how it went is the most useful thing you can do to support this path. What helps most: which workflows you scored, which factors and weights you landed on and why, roughly where the time went, and who had to be in the room to get clinical agreement. Reply here, or DM me if it’s easier to share privately. And if you’re open to it, we’d like to write a few of these up as proper case studies to potentially seed the corpus.