Your Information screen

Description

The patient's standing details: the one screen that is about who this journal
belongs to rather than about their care. Static profile, edited in place — these
are facts that change rarely, not dated entries (the same reasoning ADR 0011
applies to Section 8's profile half).

This screen carries sensitive-field exclusion logic, so it is not a good
first ticket — ADR 0008 deliberately keeps it out of the first slice. Pair it
with someone who has read 0006.

Fields

• Name
• Address
• Date of birth
• Phone
• Email
• Insurance — primary
• Insurance — secondary

Excluded, per 0006: Social Security number.
Not as a hidden field, not as an unused column, not as a "for later" placeholder
— Paul's sign-off note on 0006 is explicit that excluded means not collected,
not stored, and not in the data model. 0006 also treats SSN as effectively
closed rather than revisitable, because name + SSN is a breach-notification
trigger in every US state regardless of how well it is encrypted.

Insurance sub-fields (member ID, group number, plan name, phone) are not
specified anywhere. Decide their shape in this ticket and write it down.

Acceptance Criteria

• Single-record profile screen; editing updates in place rather than adding entries
• All seven fields above persist to the encrypted local database and survive a relaunch
• No SSN field anywhere in the UI, the schema, or the types
• Insurance sub-field shape decided and recorded in the PR description
• Sits behind the biometric unlock shell like the rest of Phase 1
• WCAG-aligned: screen reader labels on every field, no reliance on colour alone, adequate touch targets
• Copy works whether a patient or a caregiver is typing (0004)
• Covered by unit tests

Additional Info and Resources

• 0006 — excluded-field safety boundary — read the whole thing, including Paul's sign-off note
• 0004 — primary user and caregiver role — neutral phrasing, since either could be holding the phone
• Open question this ticket has to answer: the repository layer is built for repeatable entries. A single-record profile either reuses it with one fixed row or needs its own path. Whatever you pick, the next four profile screens (#44–#47) will copy it, so say why in the PR.

QA

• Enter every field, force-quit, relaunch, confirm all values are still there
• Edit a field and confirm it updates rather than creating a second record
• Search the diff for ssn, social, securityNumber — expect nothing
• Walk the screen with VoiceOver/TalkBack

Read docs/decisions/0006-excluded-field-safety-boundary.md in full, then review docs/decisions/0004-primary-user-caregiver-role.md and ADR 0011. Inspect the existing repository layer and biometric unlock shell before deciding how a single-record profile fits. Done means all listed fields persist across relaunch, update in place, exclude SSN everywhere, and have unit and accessibility coverage.