HIPAA and Medicare Lead Generation: When It Applies — and When It Doesn't
"Are you HIPAA compliant?" is one of the first questions Medicare technology vendors receive from compliance teams. The question is reasonable but frequently conflates two different legal questions: whether HIPAA applies at all, and what HIPAA requires if it does. This guide answers both — with primary source citations and a practical framework for Medicare lead generation programs.
Not legal advice. This guide draws on primary regulatory sources and is provided for educational purposes. Consult qualified counsel for compliance determinations specific to your organization's data flows and contractual relationships.
Who HIPAA Governs
HIPAA regulates two, and only two, categories of organizations:[1],[2]
- Covered Entities (CEs): Health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically in connection with certain transactions. The "health plans" category includes health insurance issuers, self-insured employer health plans, and Medicare Advantage plans — not insurance brokers or agents.
- Business Associates (BAs): Persons or entities that, on behalf of a Covered Entity, create, receive, maintain, or transmit Protected Health Information (PHI), or that perform certain services for a CE involving PHI disclosure. A vendor to a BA is a "subcontractor BA" and is likewise bound.
If an organization is not a Covered Entity and does not handle PHI on behalf of a Covered Entity or BA, HIPAA simply does not reach it — regardless of how sensitive the data it holds may be. The same health information that would be PHI in a hospital's hands is not PHI in the hands of an unrelated technology vendor with no CE in its data chain.
What Is Protected Health Information (PHI)?
Under 45 C.F.R. § 160.103,[1] PHI is individually identifiable health information that is:
- Created or received by a health care provider, health plan, employer, or health care clearinghouse, and
- Relates to the past, present, or future physical or mental health of an individual, provision of health care, or payment for health care, and
- Identifies the individual or provides a reasonable basis to identify them.
The definition requires that the information be held by a covered person. A consumer who tells a broker their medications and current plan is sharing health information. That information is PHI in the carrier's system (if the carrier is a health plan CE). It is not automatically PHI in the broker's CRM, because the broker is not a Covered Entity for this data flow — unless a carrier has contractually made the broker a Business Associate.
This matters practically: the same data can simultaneously be PHI for one party in a transaction and not PHI for another, depending on who holds it and under what contractual relationship.
Insurance Brokers and the Covered Entity Analysis
The "health plans" category that makes an entity a Covered Entity includes health insurance issuers, self-insured employer group health plans, Medicare Advantage plans offered by private carriers, and Medicare prescription drug plans. It does not include the agents, brokers, TPMOs, and general agencies who distribute those plans.
The HIPAA applicability analysis for a Medicare broker program
A brokerage can become a Business Associate in other lines of its business — for example, if it administers group health benefits and directly handles a carrier's PHI in that capacity. In that context, the brokerage is a BA for that specific data flow, and a subcontractor BAA is appropriate for any vendor it engages with that PHI. But that BA status in one context does not automatically carry over to the brokerage's Medicare sales activity.
When HIPAA Does Apply to Medicare Technology
Medicare technology vendors are in HIPAA scope when one or more of the following is true:
- The vendor processes enrollment data that flows into a carrier's (CE's) systems — at that point the vendor is handling PHI on behalf of the CE.
- The vendor's system receives or stores plan-specific health data (diagnosis codes, formulary-specific medication data, enrollment-specific health screens) that originates from or returns to a CE.
- The carrier's contract with the broker or technology vendor explicitly designates them as a Business Associate and requires a BAA.
- The vendor operates within a distribution partnership that routes data directly through the CE's systems rather than collecting independent lead data.
In these scenarios, a Business Associate Agreement is required before the vendor can receive PHI, and the vendor must operate within HIPAA's Security Rule framework — access controls, audit logging, encryption, breach notification, and subprocessor BAAs for any subcontractors that handle the PHI.
Business Associate Agreements: What They Cover and What They Don't
What a BAA must contain
Under 45 C.F.R. § 164.504(e),[3] a BAA must:
- Establish the permitted and required uses and disclosures of PHI by the Business Associate — the BA may not use PHI for any purpose not authorized by the BAA or required by law.
- Require the BA to implement appropriate safeguards to prevent unauthorized use or disclosure consistent with the HIPAA Security Rule.
- Require the BA to report breaches and security incidents to the CE without unreasonable delay and no later than 60 days after discovery.
- Require the BA to subcontract BAAs with any subcontractors that receive or handle PHI on the BA's behalf.
- Require the BA to return or destroy PHI upon termination of the relationship, or demonstrate that return or destruction is infeasible.
What a BAA does not do
- A BAA does not make a vendor HIPAA compliant. Compliance comes from the vendor's implemented technical and organizational controls, not from the contract alone.
- A BAA does not waive breach notification requirements — it establishes them contractually between the parties; regulatory notification to HHS and affected individuals remains required under the Breach Notification Rule.
- A BAA does not substitute for the vendor's own Security Rule compliance assessment. The BA must independently evaluate and implement required and addressable Security Rule specifications.
HIPAA and SMS: The Actual Rule
HHS Office for Civil Rights has addressed the SMS question directly in FAQ guidance.[4] The answer is that CEs may communicate with individuals by unencrypted channels — including SMS and email — provided:
- The individual has been warned of the privacy and security risks of the unencrypted channel, and
- The individual still prefers or consents to that channel for communication.
The Security Rule's transmission-encryption standard is classified as "addressable" — not "required." Under 45 C.F.R. § 164.312(e)(2)(ii), a covered entity may implement an alternative measure if it documents why the alternative is reasonable and appropriate given the entity's risk analysis. Documented consent and risk disclosure is an established alternative.
Common HIPAA Myths in Medicare Technology
Several misconceptions recur in Medicare compliance conversations. Each creates unnecessary friction — or, in the opposite direction, false confidence:
Myth: Any health data is PHI
Reality: PHI is a defined legal term. Health information is PHI only when held by or on behalf of a Covered Entity. The same information in a non-CE's hands is personal data governed by other laws (TCPA, state privacy statutes) — not PHI.
Myth: Insurance brokers are automatically subject to HIPAA
Reality: Brokers are not Covered Entities. They can become Business Associates under specific contractual arrangements with carriers, but that BA status must be affirmatively established — it is not automatic based on the broker's line of business.
Myth: A BAA means the vendor is HIPAA compliant
Reality: A BAA is a contract, not a compliance certification. A vendor can sign a BAA and be completely non-compliant with the Security Rule. BAAs allocate responsibility — they don't substitute for implemented controls.
Myth: You can't text PHI
Reality: HHS OCR says you can, with informed consent. The standard is warn + document, not prohibit. The platform infrastructure (HIPAA-eligible transport with a BAA) is the control — not the channel prohibition.
Myth: HIPAA is the primary risk for Medicare SMS programs
Reality: For most Medicare SMS programs, TCPA is the more immediate litigation risk. TCPA violations support private class actions at $500–$1,500 per message; HIPAA enforcement is government-initiated and typically targets CEs with major breaches. See the TCPA guide for the consent framework that governs SMS risk in practice.
Frequently Asked Questions
Common HIPAA questions from brokers, carriers, and compliance teams.
Does Medicare lead generation require HIPAA compliance?
Not automatically. HIPAA applies only when a Covered Entity or Business Associate relationship exists for the specific data flow. Consumer Medicare lead data collected directly from an individual by a non-covered intermediary — such as an insurance broker or lead technology vendor — is typically not PHI under HIPAA. The analysis turns on who holds the data and in what organizational relationship, not on how sensitive the data is.
Are insurance brokers HIPAA Covered Entities?
Generally no. HIPAA's Covered Entities are health plans (insurance issuers, HMOs, certain employer plans), healthcare clearinghouses, and providers that transmit health information electronically in specific transactions. Insurance agents and brokers who sell Medicare Advantage and supplement plans are not themselves health plans. A brokerage can become a Business Associate in specific contexts — such as administering group health benefits and handling a carrier's PHI — but that BA status in one context does not automatically extend to the brokerage's Medicare sales activity.
Is Medicare lead data Protected Health Information (PHI)?
It depends on who holds it. PHI under 45 C.F.R. § 160.103[1] is individually identifiable health information held by or on behalf of a Covered Entity or Business Associate. Lead data a consumer volunteers directly to a broker or technology vendor — without a Covered Entity in the data chain — is personal data governed by other laws (state health privacy statutes, TCPA, CCPA), not PHI. The same data becomes PHI if it flows into or is processed on behalf of a Covered Entity.
When is a Business Associate Agreement (BAA) required?
A BAA is required under HIPAA when: (1) a Covered Entity shares PHI with a vendor or contractor that will create, receive, maintain, or transmit that PHI on the CE's behalf; or (2) a Business Associate shares PHI with a subcontractor for those same purposes. If no PHI is involved — because no Covered Entity is in the data chain — no BAA is required under HIPAA. A data processing agreement is still appropriate under CCPA (service-provider agreement) and state health privacy laws, but that is a different legal instrument than a HIPAA BAA.
Does HIPAA prohibit SMS communication of health information?
No. HHS OCR has stated explicitly[4] that covered entities may communicate with individuals by unencrypted text or email when the individual is informed of the risks and still prefers that channel. The obligation is to warn and document — not to prohibit the channel. The Security Rule's transmission-encryption standard is "addressable," not mandatory, meaning documented consent and risk acknowledgment is an established alternative to requiring end-to-end encryption for the carrier hop.
Can a technology vendor operate in both HIPAA-scope and non-HIPAA-scope contexts?
Yes. A vendor can maintain HIPAA-eligible infrastructure and signed BAAs for clients where the data flow involves a Covered Entity or BA relationship, while serving other clients whose data flows do not involve a CE (and therefore are not subject to HIPAA). Many Medicare technology platforms operate this way — offering a BAA-backed, HIPAA-eligible deployment for carrier-connected programs and standard DPA-based agreements for broker-direct programs. The applicable compliance framework is determined by each client's specific data chain, not by the vendor's product category.
What is the HIPAA Security Rule and what does it require?
The HIPAA Security Rule (45 C.F.R. Part 164, Subpart C)[5] requires Covered Entities and Business Associates to implement administrative, physical, and technical safeguards to protect electronic PHI (ePHI). Key requirements include: access controls and unique user identification; audit controls and activity logging; transmission security (addressable encryption); integrity controls to protect against improper modification; and workforce training and security management. The Security Rule distinguishes between "required" specifications (mandatory) and "addressable" specifications (must be implemented or an equivalent alternative documented). Transmission encryption is addressable.
What is the HIPAA Breach Notification Rule?
The Breach Notification Rule (45 C.F.R. Part 164, Subpart D)[6] requires that Covered Entities notify affected individuals, HHS, and in some cases prominent media outlets following a breach of unsecured PHI. Business Associates must notify the CE of a breach without unreasonable delay and within 60 days of discovery. Individual notification must be provided within 60 days of the CE discovering the breach. Breaches affecting 500 or more individuals in a state require media notice in addition to individual notice.
Sources
25 primary regulatory sources verified as of June 2026. Organized by regulatory domain.
HIPAA Applicability & Scope
- 1 HIPAA Definitions — 45 C.F.R. § 160.103 Statutory definitions of "covered entity," "business associate," and "protected health information" — the threshold terms that determine whether HIPAA applies.
- 2 HIPAA Privacy Rule — 45 C.F.R. Part 164, Subpart E The complete Privacy Rule governing permissible uses and disclosures of PHI by Covered Entities and Business Associates.
- 3 De-identification Standard — 45 C.F.R. § 164.514(a)–(b) HHS guidance on Expert Determination and Safe Harbor methods for de-identifying health data so it falls outside PHI and HIPAA scope.
- 4 Business Associate Guidance — HHS OCR HHS guidance on who qualifies as a Business Associate and what triggers the BA relationship — the primary mechanism by which software vendors enter HIPAA scope.
- 5 BAA Required Elements — 45 C.F.R. § 164.504(e) Required provisions in Business Associate Agreements, including permitted uses, safeguard obligations, and subcontractor flow-down.
- 6 HIPAA Marketing Restrictions — 45 C.F.R. § 164.508 Authorization requirements for marketing communications using PHI; exceptions for treatment, operations, and first-party communications.
HIPAA Security, Breach & Enforcement
- 7 HIPAA Security Rule — 45 C.F.R. Part 164, Subpart C Administrative, physical, and technical safeguard requirements for electronic PHI.
- 8 HIPAA Breach Notification Rule — 45 C.F.R. Part 164, Subpart D Breach notification requirements for Covered Entities and Business Associates following a breach of unsecured PHI.
- 9 HITECH Act — 42 U.S.C. §§ 17901–17954 (2009) Made HIPAA's Privacy and Security Rules directly applicable to Business Associates and substantially increased civil penalty tiers — foundational to modern BA liability analysis.
- 10 HHS OCR — Resolution Agreements & Enforcement Actions HHS OCR's public library of HIPAA settlement agreements, providing precedent on how OCR interprets BA obligations, minimum necessary, and access controls.
- 11 HHS OCR Guidance — Use of Online Tracking Technologies (2022, revised 2024) OCR guidance clarifying that third-party tracking pixels embedded in health-related web pages may constitute HIPAA-regulated disclosures of PHI.
- 12 HHS OCR FAQ — HIPAA and Electronic Communication FAQ confirming covered entities may communicate by unencrypted text or email with patient awareness and consent, subject to appropriate safeguards.
FTC Authority Over Non-HIPAA Health Data
- 13 FTC Act — Section 5, 15 U.S.C. § 45 Prohibits unfair or deceptive acts in commerce. FTC applies Section 5 to health data practices of entities not covered by HIPAA, including non-covered lead aggregators.
- 14 FTC Health Breach Notification Rule — 16 C.F.R. Part 318 Requires health apps, wearables, and personal health record vendors not covered by HIPAA to notify consumers of unauthorized disclosure of personal health records.
- 15 FTC Policy Statement on Health Data (2022) FTC statement expanding enforcement focus to commercial surveillance of health data, including data gathered outside HIPAA-covered contexts such as insurance lead generation.
- 16 HHS & FTC Joint Warning — Hospital & Telehealth Tracking Technologies (2023) Joint letter to ~130 hospitals and telehealth providers warning that use of tracking pixels on health websites may violate both HIPAA and FTC Act — illustrates overlapping jurisdiction.
CMS Medicare Marketing & TPMO Rules
- 17 Medicare Advantage Marketing — 42 C.F.R. § 422.2274 CMS regulation governing Third-Party Marketing Organizations (TPMOs); requires disclaimer language, restricts lead generation practices, and subjects TPMOs to MA plan oversight.
- 18 CMS Medicare Communications & Marketing Guidelines (MCMG) Annual CMS guidance document specifying permissible and prohibited marketing activities for MA plans and their downstream TPMOs, including lead generation and scope of appointment rules.
- 19 CMS 2024 Final Rule — Contract Year 2025 MA and Part D (89 Fed. Reg. 30448) Final rule adding new TPMO oversight requirements, stricter beneficiary call recording rules, and restrictions on unsolicited contact — materially affects lead generation workflows.
TCPA & SMS Consent
- 20 Telephone Consumer Protection Act — 47 U.S.C. § 227 Federal law requiring prior express written consent for autodialed or prerecorded calls and texts to cell phones; applies to Medicare lead follow-up regardless of HIPAA scope.
- 21 FCC Order — One-to-One Consent Rule (89 Fed. Reg. 7532, 2024) FCC order requiring consumer consent to be obtained separately for each seller (not bundled across aggregators), effective January 2025 — directly affects Medicare lead gen consent flows.
State Consumer Health Privacy
- 22 California Confidentiality of Medical Information Act (CMIA) — Cal. Civ. Code §§ 56–56.37 California law broader than HIPAA: applies to any business that maintains medical information, regardless of covered-entity status; restricts use of medical information for marketing without explicit authorization.
- 23 Washington My Health My Data Act — RCW § 70.372 (2023) Applies to "consumer health data" collected by non-HIPAA-covered entities; requires consent for collection and prohibits selling consumer health data without opt-in. Effective March 2024.
Implementation Guidance
- 24 NIST Special Publication 800-66 Rev. 2 — Implementing the HIPAA Security Rule (2023) NIST guidance for organizations implementing the HIPAA Security Rule safeguards, including risk analysis methodology, access controls, and audit controls relevant to any BA.
- 25 ONC 21st Century Cures Act Final Rule — 85 Fed. Reg. 25642 (2020) Prohibits information blocking by health IT developers and health information networks; defines "electronic health information" broadly and establishes interoperability obligations relevant to health data vendors.
MediMatch
About MediMatch
MediMatch is a white-label SMS Medicare lead intake tool for benefits brokers and General Agents. It operates in both HIPAA-scope and standard-DPA modes, supports BAA execution when applicable, and maintains HIPAA-aligned controls regardless of formal scope.
Questions about the HIPAA analysis for your specific program?
This guide is educational and is not legal advice. Consult qualified HIPAA counsel for determinations specific to your organization's data flows and contractual relationships.