PHI in mobile apps: where it leaks through logs, crash reports and analytics

When people picture a healthcare data breach they imagine an attacker. In mobile apps, the more common cause is a convenience tool quietly sending identifiers somewhere. We review the same places on every release.

Logs and crash reports

Crash reporters often capture breadcrumbs, screen names and network payloads. A request body with a patient name that fails once can end up in a third party dashboard. We scrub known fields, disable body capture, and test with a seeded record.

Analytics and advertising SDKs

Product analytics are useful and risky. We use de-identified event names such as "visit_booked" with no patient fields, strip device advertising IDs where we can, and remove any SDK that collects more than we need. If a vendor will not sign a BAA and the data could include PHI, it does not ship.

Push notifications

Lock screens show everything. Notification text stays neutral, for example "You have a new message", and the detail appears after sign-in.

Screenshots and the app switcher

We blur sensitive screens in the app switcher, block screenshots on the most sensitive views where the platform allows it, and clear clipboard content on logout.

Storage on the device

• Tokens go in the secure keystore, never in plain preferences.
• Cached PHI is encrypted, short lived and wiped on logout and on repeated failed unlocks.
• Photos are captured in app and uploaded directly, never written to the gallery.
• Biometric unlock is offered, with a clear fallback.

Release checklist

• Every third party SDK has a reason, an owner and a data review.
• A seeded test record is run through every screen, then searched for in logs and vendor dashboards.
• Certificate pinning is enabled where the platform allows it.
• Jailbreak and root detection are considered, with a risk based response.

Mobile apps are part of the covered system. Treat them as production infrastructure and keep the review part of every release.