avniproject / avniproject/tanuh-webapp

Tanuh clinician review screen: show every captured site photo

Open
#2 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

**As a** reviewing physician, **I need** every captured photo visible on the review screen, **so that** no site is silently dropped.

This is bigger than it first looked. The review screen, the doctor's per-photo decisions, and the way the review is saved are all built around a fixed set of eight photo positions. Showing every photo — however many there are — means reworking all of that, not just the on-screen list. The estimate for this card needs revisiting.

### Acceptance Criteria
- [ ] The review screen shows every photo captured in an encounter, with no upper limit. An encounter with 14 photos shows all 14. An encounter with 16 photos shows all 16. Today only the first 8 show and the rest are dropped.
- [ ] Photos taken beyond the 14 protocol sites are also captured and feed the AI. The review screen shows those too, so no photo is dropped for being late or beyond the usual set.
- [ ] If it is easy, show each photo's site name beside it. If not, note on this card that the site name was skipped.
- [ ] Retest the review screen against the updated form, then redeploy it. Record the redeploy on this card.

### Technical Details
- Repo: `avniproject/tanuh-webapp` (the custom Tanuh clinician webapp; local checkout `../avni-tanuh-physician-app`). Main file: `src/forms/ReviewForm.tsx`.
- This is not a render cap alone. `PHOTO_SLOTS = [1..8]` (`src/constants/tanuhConcepts.ts:49-50`) defines a fixed slot *type* `PhotoSlot`, and the whole review path is keyed by it:
- `collectPhotos` stops at `if (photos.length >= PHOTO_SLOTS.length) break` (`ReviewForm.tsx:120`), so only the first 8 images are ever collected — 9+ are dropped before render.
- Per-photo state is keyed by `PhotoSlot`: `photoVerdicts` / `photoQuality` as `Partial>` and `highestRiskSlot: PhotoSlot | null` (`ReviewForm.tsx:80-83`).
- `deriveClassification` rolls up over `presentPhotos: PhotoSlot[]`.
- The save path maps each shown photo to a review-form Images row keyed by `slot` (`ReviewForm.tsx:372-386`); the render maps by `photo.slot` (`ReviewForm.tsx:543-578`).
- Make the photo identity N-generic end to end: replace the fixed `PhotoSlot` (1..8) key with the collected photo's index across collection, per-photo verdict/quality/highest-risk state, the classification roll-up, the save path, and the render. Iterate the media observations rather than hardcoding `[1..14]`.
- Keep the flat legacy `Photo N (image)` fallback in `collectPhotos` for older encounters.

### Testing Gotchas
- Older encounters with fewer than 8 photos must still show correctly.
- Check an encounter with more than 14 photos (for example 16) shows every one of them.

### Visual Design (mock)

```
Screening review — Patient ……

┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐
│ 1 │ │ 2 │ │ 3 │ │ 4 │ │ 5 │ │ 6 │ │ 7 │ …14 …16 ← no cap; 16 photos = 16 tiles
└────┘ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘
each tile: photo · AI verdict · quality flag · physician verdict
highest-risk photo: chosen across ALL photos, not the first 8
```

_Full mock set: `analysis/guided-capture/mockups.md` in avni-product-ops._

---
**Epic:** https://github.com/avniproject/avni-product/issues/1888

---
_Moved here from avniproject/avni-product-ops#244 on 22 Jul 2026 — coding cards belong in the code repo, not the ops repo._

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in src/forms/ReviewForm.tsx, then read PHOTO_SLOTS and PhotoSlot in src/constants/tanuhConcepts.ts. Trace collectPhotos, per-photo state, deriveClassification, the save mapping, and the render path before retesting the review screen against the updated form. Done means encounters with fewer than 8, 14, and 16 photos retain every image, including legacy Photo N fallbacks, and the redeploy is recorded on the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.