mHealth, or mobile health, narrows the broad field of digital health down to what happens on a mobile device: native smartphone apps, SMS reminder workflows, and the phone's own camera and sensors used in care or wellness. It is a subset of digital health defined by its delivery channel rather than by a particular clinical purpose, so an mHealth product can be anything from a medication-reminder text service to a camera-based skin-check app.
What makes mHealth distinctive for a product team is that two layers of rules apply at once. On top of the legal rules sit platform rules — Apple's App Store and Google Play health-data policies — which govern what an app may collect and how it must disclose that, independent of any health regulator. The legal rules, in turn, follow the data and the relationship, not the form factor. The same app can fall under very different regimes depending on who deploys it.
That last point is the one teams get wrong most often. HIPAA applies only when protected health information (PHI) is handled within a covered relationship — for example, an mHealth app a provider or health plan uses to deliver patient care is inside HIPAA, and its vendors need Business Associate Agreements (BAAs). But the very same app sold directly to consumers, with no covered entity involved, is typically not under HIPAA at all; instead it may fall under the FTC's Health Breach Notification Rule, which requires notifying users and the FTC after a breach of identifiable health data. The pitfall is assuming "health app" automatically means "HIPAA" — the correct question is always who is handling the data and in what relationship.
