Legal counsel for health tech and digital health

Digital health and health tech operate at the intersection of federal health privacy law (HIPAA), federal medical device law (FDA), state privacy and telehealth laws, and the rapidly evolving rules on AI in healthcare. The compliance map is wider than many founders expect — and the gap between "wellness product" and "regulated medical product" is narrower than it looks.

The HIPAA boundary is intent-based

HIPAA applies when you are a covered entity (provider, plan, clearinghouse) or a business associate (vendor processing PHI for a covered entity). Direct-to-consumer wellness apps usually fall outside HIPAA — but may still be subject to the FTC's Health Breach Notification Rule, state health privacy laws, and the rapidly expanding category of consumer health information statutes. Mapping which regime — HIPAA, HBNR, CMIA, Washington's My Health My Data Act, Texas's Data Privacy and Security Act, and others — applies to each data flow in your product is the foundational compliance exercise.

Business Associate Agreements are non-negotiable

Every vendor that handles PHI on behalf of a covered entity needs a signed BAA before data flows. Cloud providers, analytics platforms, communication tools, AI vendors — if they touch PHI, they need a BAA. Many SaaS vendors offer BAAs only on enterprise tiers or only after sales review, so vendor selection has to factor in BAA availability and terms. The BAA is also where indemnification, breach notification timelines, and audit rights get negotiated.

Software-as-a-Medical-Device is a real category

Software that diagnoses, treats, or makes clinical decisions is generally a medical device requiring FDA clearance (510(k)) or De Novo authorization. Software that supports general wellness, education, or administrative workflows usually isn't. The line is drawn by intended use claims — what your marketing, documentation, and product UI say the product does. Founders who use careful intended-use language can ship products that would be regulated if the same product were marketed differently.

Telehealth is state-by-state

The provider-patient relationship is generally governed by the state where the patient is located at the time of the encounter. A national telehealth offering requires either provider licensure in each state, compact membership (the Interstate Medical Licensure Compact and similar), a network strategy, or a service model that doesn't establish a provider-patient relationship in regulated states. The rollout plan needs to map to the regulatory map, not engineering convenience.

The 21st Century Cures Act applies to many digital health products

The Cures Act and the ONC interoperability rules require certified Health IT modules to support FHIR-based APIs, prohibit information blocking, and impose certification obligations. The penalties are real and the enforcement posture has stiffened. If your product exchanges patient data with EHRs or qualifies as a regulated Health IT module, build interoperability into the architecture, not as a downstream feature.

AI in healthcare is the fastest-moving regulatory front

The FDA's evolving framework for AI/ML-based SaMD (predetermined change control plans, post-market monitoring), the ONC's HTI-1 rule on algorithm transparency, state medical board guidance on AI-assisted clinical decision-making, and the FTC's posture on AI accuracy claims all apply to digital health AI features. Building AI features with the regulatory map in mind from day one is dramatically cheaper than retrofitting compliance after launch.