Rx360 Wearable Experience Spec¶

Functional & Clinical Review — Overlay¶

Date: May 1, 2026 Prepared by: Gene Lang, PharmD | Director of Pharmacy Operations For: Jack — Design / Cross-team Functionality Source spec: Rx360 Wearable Experience Spec — Device Interactions & Indicators (April 2026) Companion to: Wellness Lexicon Review (May 1, 2026) Classification: Internal — design feedback

How to read this document¶

This is a section-by-section overlay on the wearable experience spec. For each subsection in the original, this doc reproduces the User Story and the spec'd behavior verbatim, then adds:

🔴 Findings (Block) — issues that will harm the user or the product if shipped as-spec'd
🟡 Findings (Caution) — issues that need a decision before shipping
✅ Recommendations — concrete changes with rationale

The lexicon review (separate doc) covers regulatory language exposure. This doc covers functionality, clinical fit, and anticipated user response in the elderly demographic the wearable is targeting.

The two reviews are independent — language can be perfect while the experience fails users, and vice versa.

Table of Contents¶

0 · Global Interaction Rules
1 · Scheduled medication reminders (1.1 – 1.5)
2 · Battery (2.1 – 2.4)
3 · SOS — Sidekick (3.1 – 3.4)
4 · Fall Detection — Balance (4.1 – 4.4)
5 · Setup & System States (5.1 – 5.4)
6 · Cross-cutting concerns (new — not in original spec)
7 · Anticipated user response — week 1 → month 3 (new)
8 · Prioritized recommendations for tomorrow's meeting (new)

0 · Global Interaction Rules¶

As specified

Gesture	Action
1 Press	Snooze Medication Reminder, Yes
2 Presses	Dismiss Medication, No
Press and Hold for 3 seconds	Initiate SOS

(Implied from §5.3: 10-second hold = factory reset.)

🔴 FINDING — Single-button paradigm is the load-bearing UX choice and the riskiest one¶

Six distinct interactions on one button across four contexts: - 1 press → snooze (in reminder state) or wake (in idle state) - 2 press → dismiss - 3-second hold → SOS - 10-second hold → factory reset

Failure modes that will occur in normal use: - User holds button trying to wake device, doesn't see immediate response, holds longer → triggers SOS at 3s, then factory reset at 10s - User in actual SOS panics, holds longer than intended → factory reset mid-emergency - Tremor user means double-press, fires triple-press - User wants to dismiss reminder (2 presses), accidentally triggers SOS hold-down

Apple Watch resolved this with two buttons + a touchscreen. Lively Mobile2 and the rest of the senior PERS market keep interactions to 2–3 patterns max.

✅ RECOMMENDATIONS¶

At minimum: dedicated SOS button physically distinct from the general button — recessed, different texture, or different position. This is the highest-leverage hardware change in the spec.
Move factory reset to a paperclip pinhole or app-only. Same-button factory reset is a known dangerous pattern in medical-grade wearables.
Reduce gesture vocabulary on the general button to 1 press and long-press for "what is this?" (a help / status query). Push other interactions into voice or app.

1 · Scheduled medication reminders¶

Spec note: "Time-critical medications cannot be dismissed."

🔴 FINDING (section-level) — "Time-critical" is undefined and behaves like a clinical-decision-support trigger¶

The spec hard-codes a 20-minute grace period for time-critical meds and removes the dismiss option entirely. But: - Who marks a med time-critical? Pharmacist, algorithm, user, prescriber — all unspecified. - Time-critical in what sense? Insulin, levothyroxine, warfarin, eye drops, anti-Parkinson's, immunosuppressants — all "time-critical" but in fundamentally different ways. A 20-min window is wrong for most of them. - This is a clinical-decision-support behavior surfaced as a UX flag. Pharmacist sign-off is needed on the rule, or the category should be removed and configurable user snooze should handle the window.

🔴 FINDING (section-level) — Missing primitives¶

The spec defines reminder → snooze → dismiss → missed. The real-world med behaviors that aren't represented:

Missing	Frequency in geriatric polypharmacy	What's needed
"I already took it" (taken proactively before reminder fires)	Daily for >50% of disciplined users	Device-side or app-side mark-taken without a reminder firing first
"I can't take it now" (in shower, driving, NPO before procedure, gave to family member)	Multiple times/week	Acceptable defer/skip path, even on time-critical, with reason capture
"Skip this dose intentionally" (MD said skip BP med if SBP<100; held warfarin pre-procedure)	Weekly+ for poly-pharm patients	Distinguish skipped-on-purpose from missed; suppress family escalation
PRN handling (rescue inhaler, pain PRN, lorazepam PRN)	Universal in geriatric polypharmacy	Pull entirely off the scheduled-reminder model; treat as logged-on-use

Without these, "Missed Dose" becomes a noise channel. Most "misses" in real use aren't misses — they're the device not knowing what really happened.

🔴 FINDING (section-level) — No relationship to fill status, sleep, or wear state¶

Fill status: if the user's prescription ran out, the reminder fires anyway → user stress + family escalation for an empty-bottle scenario.
Sleep: 8 PM statin reminder for a user who goes to bed at 7:30 → 10 minutes of beeping while they're asleep → missed-dose escalation at 8:30 PM. Designed-in false alarms.
Wear state: if the device is off the wrist (charging, in shower, on dresser) when the reminder fires, the device alarms an empty room and escalates to family. #1 unforced error in senior wearables.

1.1 Initial Alert¶

User Story — "User is alerted clearly when it is time to take medication."

As specified

Field	Details
Trigger	Scheduled medication time is reached
Device Behavior	Audio: Beep pattern (0.5s on/off ×5, repeat every 25s for 10 minutes) · Visual: Solid brand-colored light (10 minutes) · Haptic: Matching vibration pattern
User Interaction	1 Press → Snooze 5 minutes · 2 Press → Dismiss (if not time-critical)
System Outcome	Reminder modal appears in app · Initiate 60-minute grace period (20 minutes for Time-critical)

🔴 FINDING — Alert pattern is hostile to the demographic¶

Audio + visual + haptic simultaneously, beep bursts every 25s for 10 minutes = ~24 alert cycles. For elderly users with hearing aids, sensory sensitivity, or cognitive load issues, this reads as alarm clock, not reminder. Most common abandonment driver in the senior wearable category is "it beeps too much."

🔴 FINDING — 5-minute snooze is too short¶

Average elderly user's full med-taking workflow (rise from chair → kitchen → pill organizer → water → pill → return) often runs 8–12 minutes. A 5-minute snooze fires while they're still mid-task — perceived as nagging, increases stress, lowers trust.

🟡 FINDING — Two-press dismiss is fragile in this population¶

Single-vs-double press differentiation is a known accessibility failure mode for tremor and arthritic users. Apple's own accessibility guidance flags this. Combined with the single-button paradigm (§0), every interaction has a plausible neighbor.

✅ RECOMMENDATIONS¶

Switch to escalating modalities — haptic-only for first 60–90s; add visual at 2 min; add audio only after 3 min if still no acknowledgment. The user gets gentler reminders early and clearer ones late.
Default snooze to 10 minutes, configurable in app between 5 and 30.
Replace 5-beep burst with a single soft chime (audio signature unique to medication reminders, distinct from system states / SOS / fall).
Wear-detection gate — do not fire audio if device is off-wrist. Silent log only.
Tighten the dismiss gesture: long-press to dismiss, single-press to snooze. Eliminates the double-press misfire.

1.2 Grace Period¶

User Story — "User receives a persistent but less intrusive reminder."

As specified

Field	Details
Trigger	Initial alert begins Grace period clock
Device Behavior	Visual: Pulsing brand-colored light (1 hour)
User Interaction	None
System Outcome	(unspecified — implied: continues until user takes medication or grace expires)

🟡 FINDING — Pulsing light for 1 hour is not low-vision-friendly¶

A pulsing brand-color light is a passive cue that requires the user to look at the device repeatedly. For users with cataracts, macular degeneration, or simple inattention to the wrist, the grace-period signal is effectively invisible.

🟡 FINDING — Grace period has no user-action options¶

User Interaction = "None" means a user who sees the pulsing light and wants to mark the dose taken can't do anything from the device. They have to go to the app. This is the missing "I already took it" primitive surfaced specifically.

🟡 FINDING — The 60-min vs 20-min split is a clinical rule with no defined source¶

See section-level finding above. Until the time-critical rule is defined, the grace period boundary is arbitrary.

✅ RECOMMENDATIONS¶

Add a device-side "mark taken" gesture during grace period. A single press during pulsing-light state confirms taken, closes the loop, no app needed.
Pair the pulsing visual with an occasional gentle haptic — every 10–15 min during grace — so the cue isn't visual-only.
Resolve "time-critical" definition before locking grace-period durations in firmware.

1.3 Reminder After Snooze¶

User Story — "User is reminded again after snoozing the alert."

As specified

Field	Details
Trigger	Snooze period ends
Device Behavior	Same as Initial Alert pattern
User Interaction	1 Tap → Snooze again · 2 Taps → Dismiss
System Outcome	Reminder modal appears again

🔴 FINDING — Re-firing the same Initial Alert pattern compounds the hostile-pattern issue¶

If the Initial Alert is 10 min of beeping and the snooze re-fires the same pattern, the user gets two cycles of 24 alert bursts each within 15 minutes (10 min initial + 5 min snooze + 10 min repeat). This is a near-guaranteed device-removal trigger.

🟡 FINDING — Spec switches from "Press" to "Tap"¶

§1.1 says "1 Press / 2 Press." §1.3 says "1 Tap / 2 Taps." Either both are valid (and need to be both documented as such) or one is incorrect. The button paradigm should be consistent across all sections.

✅ RECOMMENDATIONS¶

Reminder-after-snooze should be gentler, not equal, to the Initial Alert. Single chime + brief haptic + visual; no 10-minute cycle.
Standardize gesture vocabulary — pick "press" or "tap" and use it everywhere.
Cap total alert time per dose at ~5 minutes across all cycles, not per cycle.

1.4 Success — Medication Taken¶

User Story — "User confirms medication was taken."

As specified

Field	Details
Trigger	User marks medication as taken in app
Device Behavior	Audio: Single beep · Visual: Solid green light (3 seconds) · Haptic: Single vibration
User Interaction	None
System Outcome	Medication marked complete. UI updates accordingly.

🔴 FINDING — Trigger is app-only¶

The only path to "taken" is the app. This forces every user interaction through phone/tablet, which: - Excludes users who don't have phones nearby (bedtime routine, morning bathroom, gardening) - Excludes users with low phone-fluency (a significant share of the demographic) - Misses the proactive "I already took it before the reminder" case entirely (see §1 missing primitives)

🟡 FINDING — Confirmation feedback is good, framing is right¶

The single beep + green light + single vibration is positive, distinct, and brief. ✅ Keep this pattern. The lexicon review noted this section is doing the right thing emotionally — quiet success, not loud completion.

✅ RECOMMENDATIONS¶

Add device-side "mark taken" gesture — single press during reminder state or grace period state. Most important missing primitive.
Allow proactive mark-taken — a long-press from idle state queries "did you just take a med?" and lets user confirm. Closes the "I already took it" loop without requiring a reminder to fire.
Keep the existing success feedback pattern.

1.5 Missed Dose¶

User Story — "System escalates when medication is missed."

As specified

Field	Details
Trigger	Grace period ends with no response
Device Behavior	Audio: Single beep · Visual: Red light (3 seconds) · Haptic: Single vibration
User Interaction	None
System Outcome	SMS sent to support circle. Logged in emergency history. Missed alert shown.

🔴 FINDING — Auto-SMS on missed dose is the most exposed item in the spec¶

Detailed in the lexicon review. Summary: this fires three lexicon rules simultaneously, mirrors the SeniorLife warning-letter pattern, and is the single change with the highest regulatory-risk reduction. Has to become user-configured opt-in or be removed.

🔴 FINDING — Missed-dose auto-SMS will produce family alert fatigue within weeks¶

Even setting aside the regulatory issue, the operational problem: most early "misses" will be false (device off-wrist, user took med proactively, user ate dinner late, time-zone glitch, sleep). Family receives 4–8 SMS in the first month. Within 60–90 days they desensitize. The first real miss arrives, family treats it as routine and waits. This is well-documented in the PERS literature.

🔴 FINDING — Wear-detection-gated logic is missing here specifically¶

If the device is off-wrist when the reminder fires, the missed-dose escalation will fire even though the device couldn't possibly have detected anything. Family receives SMS for a device on a dresser.

🟡 FINDING — "Logged in emergency history" couples a missed pill to a medical event¶

The lexicon review covers the language. The functional implication: any user audit of the "emergency history" log is going to see medication misses adjacent to actual SOS events and falls. This conflates two very different categories and makes the log harder to use clinically.

✅ RECOMMENDATIONS¶

Remove auto-SMS or convert to user-configured opt-in. See lexicon review for the two acceptable shapes.
Gate all missed-dose logic on wear-detection. No wear → no miss → no escalation.
Differentiate missed types in the log: intentionally skipped, deferred, no-response-to-reminder, device-off-wrist. Don't collapse them into one.
Rename log to "activity history" — not just for lexicon reasons; functionally these aren't all emergencies.
Add a "skip with reason" path triggered from the reminder or grace-period state.

2 · Battery¶

2.1 Battery > 6 Hours — Normal Operation¶

User Story — "Device operates normally with sufficient battery."

As specified

Field	Details
Trigger	Battery greater than 6 hours remaining
Device Behavior	None
User Interaction	None
System Outcome	No action required. Device operates normally.

🟡 FINDING — Normal-operation indicator is "none"¶

Users in this demographic frequently want to check a device's status. With no indicator at all, the user can't distinguish "off / dead / sleeping" from "working fine." Apple Watch and Lively both show a brief charge-status flash on tap from idle.

✅ RECOMMENDATION¶

Add a status-query gesture (single press from idle) that shows brief feedback: green = healthy battery, yellow = low, red = critical. Resolves "is this thing on?" anxiety with no ongoing power cost.

2.2 Battery < 6 Hours — Low Warning¶

User Story — "User is informed battery is getting low."

As specified

Field	Details
Trigger	Battery less than 6 hours remaining
Device Behavior	Visual: Solid white light
User Interaction	Recharge device
System Outcome	Low battery awareness communicated to user

🔴 FINDING — Threshold model assumes a user who's tracking battery state. They're not.¶

Elderly users typically don't build an internal model of "I have 6 hours of battery left." Senior wearables that succeed pair charging to a daily ritual ("plug it in when you brush your teeth before bed"), not a hours-remaining counter.

🔴 FINDING — Solid white is unparseable for low-vision users and conflicts with charging¶

White is also used during charging (§2.4) and during setup (white spinning is implied for §5.x). Cataracts and age-related contrast loss make solid-white-vs-pulsing-white-vs-spinning-white-vs-white→green hard to differentiate. Multiple states sharing a color family is the accessibility miss.

✅ RECOMMENDATIONS¶

Use yellow (or amber) for low battery, not white. Reserve white for charging-in-progress only.
Pair the visual with a single soft chime once when the threshold crosses — not continuous, just one cue at threshold.
Reframe charging as a daily ritual in onboarding — not a battery-percentage management task. Suggest a charge cue (e.g., "charge while you eat breakfast") and time the device's daily summary around that ritual.

2.3 Battery < 1 Hour — Critical Warning¶

User Story — "User is warned battery is critically low."

As specified

Field	Details
Trigger	Battery less than 1 hour remaining
Device Behavior	Visual: Blinking white light · Haptic: Single vibration
User Interaction	Recharge device immediately
System Outcome	Critical battery warning communicated to user

🔴 FINDING — No anticipatory bedtime warning¶

If the threshold crosses while the user is asleep, they wake to a dead device. Morning meds reminder doesn't fire. SOS coverage is gone. Fall detection is off. The most dangerous state for the user is one this spec doesn't proactively prevent.

🟡 FINDING — Single haptic at threshold is easy to miss¶

A user gardening, watching TV, or in conversation will not register a single vibration. The critical state lasts up to an hour but the warning fires once.

✅ RECOMMENDATIONS¶

Add a "won't-last-the-night" anticipatory warning at bedtime. If the device estimates it can't reach the user's typical morning wake time, fire a clear "charge tonight" cue ~1 hour before bedtime — not when battery hits 1 hour remaining.
Use red, not blinking white, for critical battery. (See §2.2.)
Repeat the haptic + visual every 10 minutes during critical state until charging engaged.

2.4 Charging¶

User Story — "User can see charging status at a glance."

As specified

Field	Details
Trigger	Device plugged in to charger
Device Behavior	White light while charging → turns green when fully charged
User Interaction	None
System Outcome	Charging feedback provided to user

🔴 FINDING — No positive confirmation of charge engagement¶

Magnetic charging pucks routinely don't seat correctly. Users put device on charger, walk away, return to dead device. Without a clear "yes, you connected it" cue, this will be a top support issue.

🟡 FINDING — White-vs-charging-white-vs-low-battery-white redundancy¶

See §2.2. Same color family across multiple states.

✅ RECOMMENDATIONS¶

Positive engagement cue: brief chime + brief haptic when charge contact engages. The user gets immediate confirmation that the puck is seated.
Use a distinct color or animation for charging — amber pulsing or a "breathing" white, not steady white. Reserves steady white for nothing else.
Keep the white→green completion pattern; it's intuitive.

3 · SOS — Sidekick¶

3.1 Initiation¶

User Story — "User can request emergency help."

As specified

Field	Details
Trigger	User presses and holds button for 3 seconds
Device Behavior	Voice prompt: "Do you want me to call your support circle? Press once for yes, Press twice for no" · Light: Pulsing brand color for duration
User Interaction	1 Press → Yes (confirm SOS) · 2 Presses → No (cancel)
System Outcome	System awaits user confirmation

🔴 FINDING — 3-second press-and-hold is hard for arthritic and tremor users¶

Apple lets users configure SOS hold duration for a reason. The senior demo has high arthritis and tremor prevalence. 3 seconds is too long for some users (can't sustain) and too short for others (accidental triggers).

🔴 FINDING — "Press once for yes / press twice for no" is the wrong cognitive task in an emergency¶

A scared, possibly post-fall, possibly disoriented person being asked to choose between a single press and a double press is being asked to do fine-motor differentiation under stress. Two cleaner alternatives:

Voice confirm: "Say yes to call. Say no to cancel." — voice recognition is reliable for two-word inputs and removes the dexterity requirement entirely.
Single-action default with abort: "I'll call your circle in 10 seconds. Press anywhere to cancel." — the absence-of-input-equals-act pattern is what most clinical alarm systems use.

🟡 FINDING — Voice prompt has no language/accessibility variants spec'd¶

Will it speak Spanish if user prefers Spanish? Volume override for hearing impairment? Spec is silent.

✅ RECOMMENDATIONS¶

Make hold-duration configurable (default 2s, range 1–5s) based on a brief setup interview about user dexterity.
Replace the press-pattern logic with voice confirm — "Say yes" / "Say no" — or a single-action-default-with-abort model.
Spec language and volume preferences in §5.1 setup mode.

3.2 Confirmed — Yes¶

User Story — "System confirms and contacts support."

As specified

Field	Details
Trigger	User presses button once to confirm
Device Behavior	Voice prompt: "Ok, I'm calling your support circle now" · Light: Pulsing brand color for duration
User Interaction	None
System Outcome	Support circle contacted. SOS Event logged in app.

🔴 FINDING — "Support circle" is treated as singular¶

What seniors actually have: - Primary contact: usually a daughter or son, often working / in another city - Backup: another adult child or a spouse - Local: a neighbor, friend, or building manager - Last resort: 911

The right model is a cascade with timing, not one "circle": 1. Call primary; if no answer in 30s → 2. Try backup; if no answer in 60s → 3. Try local; if no answer in 90s → 4. Call 911 with location

Spec doesn't say what happens if the support circle doesn't answer — which is the #1 SOS failure mode in PERS systems.

🔴 FINDING — Location handling is not specified¶

Does the SOS message include GPS coordinates? Indoor/outdoor location? Does it interface with 911-grade location services (e911 / RapidSOS)? This is foundational and must be explicit, not implied.

🟡 FINDING — No status feedback during the call attempt¶

User confirms SOS and hears "I'm calling your support circle now." Then what? If the call fails, the user has no indication. If the call connects, no confirmation. The user may need to repeat the SOS unnecessarily.

✅ RECOMMENDATIONS¶

Cascading contact model with explicit timing. Spec the cascade in firmware; configure contacts and timings during setup.
Specify location handling explicitly — what's sent, in what format, to whom.
Add per-stage status feedback: "Calling Mary now." → "Mary didn't answer. Trying David." → "David's on the way."

3.3 Cancelled — No¶

User Story — "User cancels SOS request."

As specified

Field	Details
Trigger	User presses button twice to cancel
Device Behavior	Voice prompt: "I'm glad you're ok, canceling request." · Light: Pulsing brand color for duration
User Interaction	None
System Outcome	Event logged. No contact initiated.

🟡 FINDING — Two-press cancellation under stress is the documented failure mode¶

Same as §1.1 but in a higher-stakes context. A user who triggered SOS accidentally and is panicking will press repeatedly trying to cancel and may inadvertently re-confirm. Per §3.1 recommendation, voice-confirm or single-action-default-with-abort solves this.

✅ RECOMMENDATION¶

Voice cancel: "Say cancel." Or any-press-cancels per §3.1.

3.4 No Response — Auto-Escalation¶

User Story — "System escalates automatically when no response is given."

As specified

Field	Details
Trigger	No user input after 10 seconds
Device Behavior	Voice prompt: "I'm calling your support circle now" · Light: Pulsing brand color for duration
User Interaction	None
System Outcome	Support circle contacted. Event logged in app.

🟡 FINDING — 10-second window is not configurable¶

For a real emergency, 10 seconds is reasonable (you want fast escalation). For a tremor user who triggers SOS accidentally three times a week, 10 seconds isn't enough to find and cancel before family gets called. This is a setup-time configuration item.

🟡 FINDING — Auto-escalation mode is silent on cascade¶

Same issue as §3.2. Who specifically is "support circle" in auto-escalate mode? In what order? With what timing?

✅ RECOMMENDATIONS¶

Configurable auto-escalation window (default 10s, range 5–30s) set during setup based on user dexterity profile.
Cascade defined in §3.2 also applies here.
Visual + haptic countdown during the 10 seconds — pulsing light intensifying, vibration every second — so user knows they have time to cancel.

4 · Fall Detection — Balance¶

4.1 Detection¶

User Story — "Device detects a fall and checks on the user."

As specified

Field	Details
Trigger	Fall detected (≥ 60G threshold)
Device Behavior	Voice prompt: "I detected a fall, do you want me to call your support circle? Press once for yes, Press twice for no" · Light: Pulsing brand color for duration
User Interaction	1 Press → Yes (confirm fall) · 2 Presses → No (false alarm)
System Outcome	System awaits confirmation

🔴 FINDING — 60G simple-threshold detection is the wrong algorithm¶

Apple Watch uses ~50G plus signal-shape analysis (impact + tumble + post-impact stillness). Simple G threshold has two failure modes simultaneously:

Misses slow slumps — actually the most common geriatric fall mechanism (orthostatic hypotension, syncope, weak knees giving way mid-step). Slumps often peak at 30–45G but produce extended post-event immobility. Detecting these is the actual clinical value.
Catches false impacts — slamming a car door, dropping the device while taking it off, vigorous gardening, grandchild yanking arm.

You will get the worst of both: the falls you'd most want to catch (slumps), you'll miss; the events you'd want to ignore (impacts), you'll over-detect.

🔴 FINDING — Sleep / horizontal scenarios will produce nighttime false positives¶

Device on wrist, user rolls over hard during sleep, hits 60G, no response within 10s → SMS to family at 3 AM. This will happen multiple times per week per user without explicit nighttime gating.

🔴 FINDING — Same press-pattern UX problems as SOS¶

(See §3.1.) Worse here because the user is more likely to be disoriented.

✅ RECOMMENDATIONS¶

Move from threshold-only to threshold + signal shape + post-event immobility. Industry standard. Cost is firmware/algorithm, not hardware.
Gate fall detection during detected sleep (or default-off overnight, configurable). Pair with wear-detection.
Voice confirm or any-press-cancels — same pattern as §3.1 SOS recommendation.
Internal ≥60G threshold is fine — just don't surface that number to consumer copy (lexicon review).

4.2 Confirmed — Yes¶

User Story — "System escalates fall event."

As specified

Field	Details
Trigger	User presses once to confirm fall
Device Behavior	Voice prompt: "Ok, I'm calling your support circle now" · Light: Pulsing brand color for duration
User Interaction	None
System Outcome	Support Circle contacted. Event logged in app.

🔴 FINDING — Same singular-support-circle issue as §3.2¶

Cascading contacts with timing required. Especially important here because falls often happen alone and the response window is shorter than user-initiated SOS.

🟡 FINDING — Spec says "Support Circle" (capitalized) here vs "support circle" elsewhere — minor consistency.¶

✅ RECOMMENDATIONS¶

Apply §3.2 cascade model to fall-detection escalation.
Standardize capitalization.

4.3 Cancelled — No¶

User Story — "User cancels fall alert."

As specified

Field	Details
Trigger	User presses twice to indicate false alarm
Device Behavior	Voice prompt: "I'm glad you're ok, canceling request." · Light: Pulsing brand color for duration
User Interaction	None
System Outcome	Event logged in app. No contact initiated.

🟡 FINDING — Same two-press cancellation issue as §3.3 — apply same fix.¶

🟡 FINDING — False-alarm log is valuable, treat it as such¶

If users are correcting false fall detections via the cancel button, that's high-quality training data. The log should feed back into algorithm tuning. Spec is silent on whether/how this happens.

✅ RECOMMENDATIONS¶

Voice cancel / any-press cancel.
Pipe false-alarm cancellations to algorithm-improvement data feed (consent-gated).

4.4 No Response — Auto-Escalation¶

User Story — "System escalates automatically."

As specified

Field	Details
Trigger	No user input after 10 seconds
Device Behavior	Voice prompt: "I'm calling your support circle now" · Light: Pulsing brand color for duration
User Interaction	None
System Outcome	Support contacted. Event logged.

🔴 FINDING — 10-second auto-escalation is too aggressive for fall detection specifically¶

SOS is user-initiated, 10s is fine. Fall detection is device-initiated, often false positive, often the user is mid-recovery. A senior who tripped, caught themselves on furniture, and is still upright will get auto-escalated to family while they're standing in the kitchen.

Standard practice: gate auto-escalation on detected post-fall immobility for 30–60 seconds, not on no-response-to-prompt in 10 seconds.

🔴 FINDING — Recovery should cancel auto-escalation¶

If the device detects movement post-event (walking, sitting up, climbing stairs), the user is fine and the alarm should stand down without requiring them to find and press a button. Spec is silent. This is a high-leverage false-positive killer.

🔴 FINDING — False-positive escalations are catastrophic for adoption¶

Two false escalations to family within the first month and the user takes the device off for good. Family becomes anxious, then desensitized. The first real fall, family treats the SMS as another false alarm and waits. Well-documented in PERS literature.

✅ RECOMMENDATIONS¶

Gate fall-detection auto-escalation on post-fall immobility detection, not just no-response-to-prompt.
Movement post-event automatically cancels the escalation cascade.
Default escalation window 30s for fall, configurable. SOS can stay tighter.
Log false-positive cancellations (per §4.3).

5 · Setup & System States¶

5.1 Setup Mode¶

User Story — "Device indicates it is being configured."

As specified

Field	Details
Trigger	Device in setup mode
Device Behavior	Spinning brand-colored light
User Interaction	None
System Outcome	Setup in progress

🟡 FINDING — Setup mode is the right time to capture accessibility profile¶

Spec doesn't address what setup captures — just that the light spins during it. Critical setup-time configuration:

Visual: large light? haptic-only fallback? high-contrast color set?
Hearing: voice-prompt volume? visual fallback if hearing-aided?
Dexterity: SOS hold duration? auto-escalation window?
Cognitive: caregiver-set-up-then-locked mode? simplified UX?
Hand preference: left wrist / right wrist (affects fall detection signal interpretation)
Language: voice-prompt language, written language
Wear schedule: when does the user typically remove the device? (informs charging cue timing, sleep gating)

✅ RECOMMENDATION¶

Define a structured setup interview that captures the above. Output a per-user accessibility/preference profile that drives runtime defaults across all sections.

5.2 Bluetooth Connection¶

User Story — "Device indicates Bluetooth pairing is underway."

As specified

Field	Details
Trigger	Connecting via Bluetooth
Device Behavior	Spinning blue light
User Interaction	None
System Outcome	Connection in progress

🟡 FINDING — Pairing failure modes are unspecified¶

Bluetooth pairing fails routinely with senior devices (range, interference, app version mismatches, the user's phone Bluetooth being off). Spec covers the success path only.

✅ RECOMMENDATIONS¶

Add states for pairing failed, out of range, paired but disconnected. Each needs a distinct cue and a recovery path.
Voice prompt on pairing failure: "I couldn't connect. Open the Rx360 app and tap reconnect." — gives the user a concrete next action.

5.3 Factory Reset¶

User Story — "Device resets to factory settings."

As specified

Field	Details
Trigger	Long press button for 10 seconds
Device Behavior	Spinning light during reset + single beep on completion
User Interaction	None
System Outcome	Device reset complete

🔴 FINDING — Same-button factory reset is a known dangerous pattern¶

Same button does: - 1 press → snooze / wake - 2 press → dismiss - 3-second hold → SOS - 10-second hold → factory reset

Failure modes that will occur: - User holds button to "make sure it's on," doesn't see immediate response, holds longer → SOS at 3s, then factory reset at 10s — losing all setup - User in actual SOS panics, holds longer than intended → factory reset mid-emergency - Caregiver pressing-and-holding to test the device wipes it

This is not a hypothetical. It happens to wearables that share button paths between SOS and reset.

✅ RECOMMENDATIONS¶

Move factory reset off the SOS button entirely. Two acceptable shapes:
Paperclip pinhole in the back of the device (medical-grade-wearable standard)
App-only — factory reset only available from the paired app, requires confirmation
Keep the spinning-light + beep-on-completion feedback.

5.4 Wake up¶

User Story — "User wakes up device from idle state."

As specified

Field	Details
Trigger	User press button 1 time
Device Behavior	Light: Green flash
User Interaction	None
System Outcome	(unspecified)

🟡 FINDING — Single press is overloaded¶

In idle state, single press = wake. In reminder state, single press = snooze. In grace period, single press = (currently nothing; recommended in §1.2 = mark taken). State-dependent button mapping is workable but needs a clear state-transition spec.

🟡 FINDING — System Outcome row is empty¶

What does "wake" produce beyond the green flash? Does the device start reading sensors? Begin a status query? Just illuminate? Should be spec'd.

✅ RECOMMENDATIONS¶

Spec the state machine explicitly — what gestures are valid in what states, what they do. (See Wearable_Firmware_v0.2_State_Machine.md in this folder if it covers this; cross-reference.)
Wake from idle should also be a status query opportunity — green flash plus brief battery-status indicator (per §2.1 recommendation).

6 · Cross-cutting concerns¶

(Not covered by any specific subsection in the original spec.)

6.1 Wear detection is missing and is foundational¶

Without wear detection: - Device alarms an empty room when user takes it off - "Missed dose" fires when user is in the shower, bathing, or at the gym - Fall detection fires when device is dropped during removal - Battery degradation patterns are misattributed

This is table-stakes for the senior wearable category and should be a Section 0-level concern in the spec. Apple Watch, Garmin, and every PERS device on the market includes wear detection.

Recommendation: add a wear-detection sensor (capacitive or optical) and gate all device-initiated alerts on wear state. Off-wrist → silent log only; no audio, no escalation.

6.2 No accessibility configuration framework¶

The user demographic has high prevalence of: - Visual impairment (cataracts, macular degeneration, glaucoma) - Hearing impairment (presbycusis, hearing aids) - Dexterity (arthritis, tremor, Parkinson's) - Cognitive (MCI, dementia, post-stroke)

The spec assumes a baseline-able user. Captured in §5.1 setup-mode recommendations — flagged here because it cuts across every section.

6.3 The interaction language is supportive; the interaction design is alarmist¶

Compare: - Spec User Stories: "alerted clearly," "persistent but less intrusive," "confirms medication was taken," "checks on the user" — gentle, supportive, calm - Spec interaction design: beeping for 10 minutes, blinking lights, escalating to family on no-response, alarm-clock-style audio patterns

Real users will experience what's designed, not what's described. The mismatch is the largest single risk factor for adoption. Recommend a tone audit of interaction design against the User Stories — every audio, visual, and haptic should be defended against the User Story it supports.

6.4 Specs that aren't addressed but must be¶

Item	Why it matters
Hand/wrist preference	Affects fall-detection signal interpretation; affects button reach
Water rating (IP code)	Determines whether device can stay on during shower/swim — directly affects 24/7 wear feasibility
Skin sensitivity / band material	Many seniors have thin skin, eczema, latex sensitivity, contact dermatitis
Dual-device coexistence	What if user has Apple Watch already? Bluetooth conflicts? Dual-fall-detection events?
Removal during sleep	Many seniors don't wear watches to bed. Spec should address whether overnight wear is required or optional, and what happens to morning meds reminders if device is on charger
Multi-language support	Voice prompts, written app copy
Dosing instruction integration	Does the device know "with food" / "morning only" / "every 6h PRN"? Or just clock times?

6.5 No graceful degradation when phone/app is unavailable¶

Spec implies a paired phone/app for "Reminder modal appears in app," "Marked complete in app," etc. If the phone is dead, in another room, or the app crashed, what does the device do? Does it still function autonomously? Spec is silent.

Recommendation: define the device's autonomous-mode behavior — what works without phone proximity, what degrades, what's blocked.

7 · Anticipated user response — week 1 → month 3¶

What I expect to see if the spec ships as-currently-written, based on the geriatric demographic and the PERS / senior-wearable literature:

Week 1 — onboarding

"It beeps too much. It startled me when I was watching TV." (#1 abandonment driver in senior wearable market.)
First "I already took it" frustration: user took morning meds at 7:50, scheduled for 8:00, device beeps at 8:00 anyway. Repeated daily.
Charging confusion: user puts on charger but it's not seated; returns to dead device. Calls family for help.

Week 2 — first false events

First false-positive fall detection (30–45G slump-style fall missed; gardening or door-slam caught). Family receives SMS. User is embarrassed.
First accidental SOS from press-and-hold timing miss. Family receives second SMS.
First nighttime missed-dose escalation (device on dresser, alarm clock for empty room, family SMS at 9 PM).

Week 3 — alert fatigue setting in

User starts to remove device during specific activities (cooking, gardening, bathing). Removal pattern tells you which interactions are most aversive.
Family begins discussing internally whether SMS alerts mean anything.
"Time-critical cannot be dismissed" creates first real frustration — user can't get to the bathroom without the wearable beeping.

Week 4 — fork in the road

Either (a) charging ritual stuck + alert tolerance built up + perceived value > friction → continued use; or (b) device goes in the drawer.
Drawer rate at this point is roughly 25–35% based on PERS norms.

Month 2 — among continued users

Family has received 4–8 SMS alerts, of which 1–2 were real. Family alert fatigue is real and measurable.
User notices family takes longer to respond to alerts. This degrades the value proposition of the device — they feel less safe than before they had it.

Month 3 — drawer rate stabilizes

Drawer rate at ~40–60% based on PERS market norms unless the design specifically engineers against it.
The savable surface area is in:
False-positive rate of fall detection (algorithm + post-event-immobility gating)
"I already took it" friction (device-side mark-taken)
Family alert quality (cascade + wear-detection gating)

These three items account for most early abandonment. Fix them and you move drawer rate from ~50% to ~25%.

8 · Prioritized recommendations for tomorrow's meeting¶

If Jack has 30 minutes for design changes, in priority order:

Priority 1 — must change before any user interaction¶

Wear detection. Gate all device-initiated alerts on wear state. Without this, every other improvement is undermined by off-wrist false alarms.
Move factory reset off the SOS button. Paperclip pinhole or app-only. Trivial cost, removes a known-dangerous pattern.
Missed-dose auto-SMS → user-configured opt-in or remove. (Lexicon review covers regulatory; this covers operational alert fatigue.)
Fall detection algorithm. Move from threshold-only to threshold + signal-shape + post-fall immobility. Same hardware, different policy.

Priority 2 — high leverage on adoption¶

Reminder pattern softened. Escalating modalities, 10-min default snooze, single chime instead of 5-beep burst. Caps total alert time per dose.
Add "I already took it" device-side gesture. Most common missed primitive; daily frequency for disciplined users.
Cascading support-circle contact list with timing. Replace singular "support circle."
Anticipatory bedtime battery warning. Prevent overnight dead-device scenarios.

Priority 3 — accessibility / robustness¶

Define accessibility profile in setup. Visual / hearing / dexterity / cognitive flags drive runtime defaults.
Distinct color+pattern+audio for each system state. Low-vision-friendly differentiation.
Cascade and location handling spec'd for SOS and fall-detection escalation.
"Skip with reason" path on medication reminders.

Priority 4 — naming and tone (covered in Lexicon Review)¶

Drop Rx- prefix on consumer-facing product names.
Rename "Fall Detection" and "Missed Dose" per lexicon review.
Tone audit: interaction design vs User Story language.

Closing thought¶

The spec is well-structured and the User Stories are right. The interaction design has not yet been pressure-tested against the actual demographic. The single highest-leverage change is wear detection, because it prevents an entire category of false positives. The single highest-risk shipped-as-written item is missed-dose auto-SMS, both regulatorily and operationally.

Most of these are firmware/policy changes, not hardware. Moving factory reset and adding wear detection are the only hardware items.

The product can succeed in this market — but it has to feel like a wellness companion, not an alarm-clock-with-911-button. The current spec is the second; the User Stories want the first. Bridging that gap is the work.

Companion document: Wellness Lexicon Review (May 1, 2026) — covers regulatory language exposure. Read alongside.