A municipal health clinic app stores appointment notes that qualify as PHI. Ordinary public-works service tickets in another module do not. What should the team recognize when securing the clinic notes?
Select an answer to reveal the explanation.
Short Explanation
Clinic notes are not the same animal as a pothole ticket — PHI wears a brighter hazard vest. Classify it higher and tighten access, logging, and retention even if both modules live in one AWS account.
Full Explanation
Protected health information in a municipal health clinic module requires stricter classification and elevated handling than ordinary public-works service tickets, even when both modules share an AWS account and both store JSON. PHI drives tighter authorization, careful logging, retention aligned to health-data rules, and often stronger encryption and access review. Developers should recognize that encryption at rest alone does not make PHI out of scope; application design still owns who can read notes, what appears in logs, and how long copies live.
Treating PHI and service tickets as identical because both are JSON in the same account fails because shared tenancy does not equal equal sensitivity. Claiming PHI is out of scope once DynamoDB encryption at rest is enabled fails conceptually—at-rest encryption is necessary but not sufficient for access, logging, and retention controls. Posting PHI to an SNS topic without auth so partner clinics can subscribe anonymously fails because it removes authentication and broadcasts health data.
Exam caveat: exam scenarios may use PHI as the sensitivity cue without requiring deep HIPAA trivia; focus on stricter handling relative to ordinary civic tickets. Operational check: separate IAM roles and table permissions for clinic notes, scrub PHI from default logs, and set retention/lifecycle policies that match health-data requirements rather than pothole-ticket defaults.