Category: HIPAA

A reminder can move from treatment communication into HIPAA marketing when a third party pays the practice to promote its product or service. The HIPAA Privacy Rule contains a treatment-related exception for certain communications, but it also limits that exception when the covered entity receives financial remuneration from a third party for making the communication. The exact message, payment, recipient, and authorization language matter.

What is the treatment communication exception?

The HIPAA regulation describes communications by a covered entity about the entity’s own products or services and certain treatment communications. A message that helps coordinate, recommend, or manage care can fall within a permitted category when the regulatory conditions are met.

That does not make every appointment message a treatment communication. A reminder that confirms time, location, preparation, or a change requested by the patient has a different purpose from a message that sells a partner’s product. A template should state its operational purpose in plain terms.

The HIPAA access workflow shows why a vendor needs a purpose and role map before handling patient communications. The same map helps a practice separate care coordination from promotion.

When does remuneration change the analysis?

The regulation addresses communications where the covered entity receives financial remuneration from a third party whose product or service is being described or recommended. When that condition applies, the communication is not covered by the treatment exception in the same way. The practice generally needs an authorization that meets the rule’s requirements.

Remuneration can be easy to miss. It might be a referral fee, sponsorship, paid placement, revenue share, free service, or another financial arrangement. Do not assume that calling the message a reminder hides its promotional purpose. Examine the contract, the sender, the product, and who benefits.

This is a legal classification, not a copywriting preference. A reminder vendor should escalate an unclear sponsorship instead of silently sending the campaign.

What must a paid marketing authorization disclose?

The regulation requires an authorization for a use or disclosure of protected health information for marketing when the covered entity receives financial remuneration from a third party. The authorization must state that the communication involves remuneration. It must also satisfy the other authorization elements, including a description of the information, the purpose, the person or class authorized to make the disclosure, the recipient, expiration, signature, and revocation information.

Do not copy this paragraph into a form and call the form complete. The practice must use the current regulation, its notice and consent process, and advice for the facts at issue. A vendor can help enforce a configured authorization state, but it cannot decide whether the underlying authorization is valid.

What should a reminder contain?

For an ordinary appointment reminder, use the minimum information needed to identify and coordinate the appointment. The template may include date, time, location, preparation, contact route, and a neutral service reference when appropriate. Avoid adding a partner offer, discount, product endorsement, or unrelated clinical detail.

If a patient has authorized a specific marketing communication, keep the approved purpose and recipient narrow. Do not reuse that authorization for a different campaign, channel, service, or sponsor without checking the scope.

The authorization and advertising permission article covers a related boundary. A HIPAA authorization is not the same as a browser cookie choice, and a cookie choice is not the same as permission to send a sponsored health message.

How should a business associate enforce the boundary?

1. Receive a written purpose and audience from the covered entity.
2. Record whether a third party pays or otherwise remunerates the practice.
3. Require an authorization reference when the paid marketing rule applies.
4. Block templates whose purpose, sponsor, or fields are missing.
5. Keep message content, recipients, and delivery results in an access-controlled audit trail.
6. Support revocation and suppression before the next send.
7. Escalate a new sponsor, product, channel, or audience for review.

Do not put the full message or patient name into an ordinary application log. Log a template ID, recipient reference, authorization reference, decision, and timestamp. Keep protected content in the approved system with its retention and access controls. The healthcare cloud architecture comparison gives a related view of service boundaries and control ownership.

What claims should a practice reject?

• “It is only a reminder, so sponsorship does not matter.”
• “A privacy policy automatically authorizes paid health marketing.”
• “A cookie banner replaces HIPAA authorization.”
• “A vendor BAA allows the vendor to choose a promotional purpose.”
• “A patient who once opted in can receive every future sponsor campaign.”

FAQ

Is every reminder marketing?

No. Purpose, content, payment, and recipient determine the analysis. A neutral appointment coordination message is different from a paid promotion.

Does a BAA authorize the sponsor message?

No. A BAA allocates business-associate duties. It does not replace a required patient authorization or create a marketing purpose.

Can the practice include a partner discount in a reminder?

Only after the practice classifies the communication, analyzes remuneration, and obtains any required authorization.

Can this page approve my campaign?

No. Use qualified privacy and legal review for the actual contract, message, audience, and data.

References

• 45 CFR 164.501 definitions and marketing provisions
• 45 CFR 164.508 authorization requirements

Not legal advice: This is a plain-language explanation of a HIPAA boundary. It is not legal advice, a compliance certification, or approval for a sponsored communication.

Yes. A cloud provider can be a HIPAA business associate even when it stores only encrypted ePHI and never receives the decryption key. HHS bases the role on what the provider receives or maintains for a covered entity or another business associate. The ability to read the information is not the deciding test.

HHS calls this a “no-view” service. The label describes access to the key, not an exemption from HIPAA. The provider and customer still need a Business Associate Agreement, a documented allocation of applicable Security Rule work, and an incident process that distinguishes business-associate status from the narrower breach safe harbor.

What does “no-view” mean in the HHS cloud guidance?

HHS uses “no-view services” for a cloud service provider that maintains encrypted ePHI for a covered entity or business associate without access to the decryption key. The term describes a technical arrangement. It does not create a new category outside the Business Associate provisions.

The provider still receives and maintains ePHI on another regulated party’s behalf. HHS therefore treats the provider as a business associate even if its staff cannot view the plaintext. This role test is different from asking whether encryption was correctly configured or whether an incident exposed readable information.

Why does encryption not remove business-associate status?

Encryption protects confidentiality by making information harder to read without the key. HHS explains that this protection does not by itself preserve integrity or availability. Ciphertext can still be corrupted, deleted, held unavailable, or affected by compromised administrative systems.

That distinction explains why the legal role remains. A storage provider can affect whether the customer retrieves data during an emergency, whether backups remain available, and whether administrative tooling changes or removes resources. The provider may never see the plaintext and still perform a service that maintains ePHI.

Do not turn this into the opposite overstatement. No-view status does not mean every safeguard must be implemented twice in the same way. HHS describes the rules as flexible and scalable for the arrangement. It also says the parties can allocate certain controls according to their risk management plans and BAA.

The practical boundary is narrow: encryption without provider-held keys changes the risk and the division of work. It does not make the data cease to be ePHI, remove the provider’s role, or make the service compliant by itself. The encryption verification checklist covers key custody and technical evidence without treating encryption as a complete program.

How can the customer and cloud provider allocate Security Rule work?

HHS gives an example in which the customer controls who can view ePHI and implements user authentication, while the cloud provider handles encryption. The exact split depends on the parties’ security risk management plans and the BAA. A generic shared-responsibility diagram is not enough.

The provider remains responsible for controls that apply to its own systems. HHS specifically points to administrative tools that manage storage, memory, network interfaces, and processors. Unauthorized access to those tools can affect confidentiality, integrity, or availability even when the attacker never obtains a decryption key.

The customer also remains accountable for work assigned to it. If the contract says the customer will configure a security feature and the customer does not do so, HHS says that fact can matter in an investigation. Allocation must therefore connect each requirement to an owner, configuration, test, and escalation path.

What does the BAA need to settle for a no-view service?

HHS says a no-view provider is not exempt from otherwise applicable HIPAA requirements. Its BAA must govern permitted uses and disclosures and explain how the provider will support obligations that depend on the maintained ePHI. The agreement should reflect the actual service rather than copy an access model the provider cannot perform.

For example, the provider may make encrypted ePHI available to the customer so the customer can handle access or amendment work. That differs from promising that provider staff will open and edit records. The BAA should also address availability, return or termination, incident notice, subcontractors, and the controls each party operates.

Does encryption create an automatic HIPAA breach safe harbor?

No. Business-associate status and breach reporting are separate questions. HHS says a no-view provider remains a business associate and must follow applicable breach-notification duties. A particular incident can fall within the safe harbor only when the affected ePHI meets the encryption standards identified by HHS.

If the information was encrypted at a level that satisfies those standards, HHS says the incident can fall within the safe harbor and the provider need not report that incident to its customer as a breach. That conclusion is incident-specific. It does not cancel the BAA or the provider’s continuing Security Rule obligations.

HHS also names two important limits. If encryption does not meet the required level, or if the decryption key was compromised with the data, the incident must be reported to the customer as a breach unless an exception to the regulatory definition applies. “The files were encrypted” is therefore an incomplete incident finding.

What evidence should be collected before approving the service?

1. Confirm that the provider receives or maintains ePHI on behalf of a covered entity or business associate.
2. Record whether the provider can obtain a key through support, recovery, escrow, or another administrative path.
3. Map authentication, encryption, integrity, availability, contingency, and incident responsibilities.
4. Test access and recovery with synthetic records rather than patient information.
5. Verify how the provider makes encrypted information available for customer-led HIPAA workflows.
6. Review the BAA against the live configuration and named subcontractors.
7. Repeat the review when keys, products, regions, support, or recovery procedures change.

Which claims should a healthcare team reject?

• “The provider cannot read the files, so it is not a business associate.”
• “The customer holds the key, so the provider has no Security Rule duties.”
• “Encryption proves integrity and availability.”
• “Every encrypted-data incident is exempt from breach reporting.”
• “The cloud contract alone proves the application complies with HIPAA.”

Each claim collapses separate tests. Role follows the service performed. Safeguards follow the real division of systems and responsibilities. Safe harbor follows the incident facts and the applicable encryption standard. Compliance depends on the regulated organization’s full program and actual operation.

Frequently asked questions

Is a cloud provider a business associate if it stores only ciphertext?

Yes, when it receives and maintains encrypted ePHI on behalf of a covered entity or another business associate. HHS says lack of a decryption key does not remove business-associate status.

Can the customer handle authentication while the provider handles encryption?

It can, depending on the service, risk management plans, and BAA. HHS allows a fact-specific allocation, while the provider remains responsible for applicable controls over its own administrative systems.

Does a BAA require provider staff to view the ePHI?

No. A no-view BAA can describe how the provider makes encrypted data available so the customer performs workflows that require access. The agreement should match technical capability and assigned duties.

Does customer-managed encryption guarantee breach safe harbor?

No. HHS ties safe harbor to qualifying encryption and the incident facts. If the encryption level is insufficient or the key was also compromised, notification duties may apply unless a regulatory exception fits.

References

• U.S. Department of Health and Human Services, “If a CSP stores only encrypted ePHI and does not have a decryption key, is it a HIPAA business associate?”, retrieved August 16, 2026, https://www.hhs.gov/hipaa/for-professionals/faq/2076/if-a-csp-stores-only-encrypted-ephi-and-does-not-have-a-decryption-key-is-it-a-hipaa-business-associate/index.html

A HIPAA-covered dental practice should answer a Google review without confirming that the reviewer is a patient or discussing care, billing, dates, staff interactions, insurance, or records. Google makes business replies public and tells businesses never to share a reviewer’s private information. Use a brief, generic response and invite the person to contact an approved private channel.

Do not assume that a reviewer’s public statement permits the practice to add protected health information to the conversation. The HIPAA Privacy Rule generally limits a covered entity’s use or disclosure of protected health information to permitted or required circumstances. The practice should have privacy counsel approve its response policy and escalation path.

Why is a public reply a separate privacy decision?

A review and the business’s reply appear publicly on Google. The reviewer controls what the reviewer chooses to post. The dental practice controls its own response. Those are separate actions, so a patient revealing information does not by itself establish that the practice may confirm, correct, or expand that information.

Google’s guidance is direct on platform behavior: never share a reviewer’s private information, and ask the reviewer to contact the business privately when an issue is complex. For a HIPAA-covered practice, the analysis also includes the federal Privacy Rule. The general rule in 45 CFR 164.502 says a covered entity or business associate may not use or disclose protected health information except as permitted or required by the subpart.

The answer for a particular response depends on facts, roles, and applicable exceptions. The safe operating default is narrower: do not use the public reply to authenticate the reviewer, discuss the account, or defend the clinical record.

What should the first public response contain?

Keep the reply short. Acknowledge that the practice takes feedback seriously, avoid stating whether the event occurred, and provide an approved general phone or email route for private follow-up. Do not ask the reviewer to post more details.

A neutral response can say: “Thank you for sharing feedback. Our office takes concerns seriously. Please contact our practice manager at the number listed on our website so we can discuss this directly.” It does not say the person received care, attended on a certain date, has an account, or experienced a particular outcome.

Avoid personalized openings that connect the public name to the practice’s records. Do not quote the review’s treatment description in an attempt to show empathy. Do not correct the service date, provider, balance, diagnosis, procedure, medication, or insurance status. Even a factual correction can disclose more than the practice is permitted to say publicly.

What language creates unnecessary exposure?

Confirmation often appears in ordinary customer-service phrases. “When you came in,” “your treatment,” “your appointment,” or “we reviewed your chart” ties the reviewer to the practice and a health-care interaction. “Your insurer denied the claim” adds financial and coverage detail. Naming the treating dentist or procedure can deepen the disclosure.

Defensive detail creates the same problem. A public reply is not the place to litigate the record. Keep the internal investigation separate from the public text.

Do not paste the review, screenshot, profile name, or case notes into advertising or reputation dashboards that have not been approved for that data. The review is public on Google, but that does not make every downstream use suitable. The privacy gates described in health conversion tracking outside HIPAA illustrate why collection context and later use must be reviewed separately.

How should the practice move the matter to a private channel?

Offer one general route and identify the responsible role, not a clinical conclusion. The practice manager or privacy contact can receive the inquiry through a phone number or email process the practice has approved. Google specifically recommends asking the reviewer to contact the business privately by email or phone for complex situations.

A private channel is not automatically compliant. Verify identity before discussing records, follow the practice’s policy, limit access, and document the case in the proper system. Never ask the reviewer to publish identifying details.

The public response can remain generic even after the practice resolves the complaint. If the person chooses to edit or remove a review, that is the person’s decision. Do not condition assistance, refund review, or complaint handling on changing the public rating.

When should the practice report a review to Google?

Google says only reviews that violate its policies are eligible for removal. The practice should not report a review merely because it disagrees with the account, dislikes the rating, or believes the criticism is unfair. Review the relevant Google policy, identify the specific violation, and submit the report through the documented process.

Keep the platform decision distinct from the internal complaint review. A review can remain online while the practice finds a process problem. A review can also be removed for a platform violation without resolving the underlying concern. Do not tell the public that Google’s decision validates the clinical record.

If Google decides that the review does not violate policy, its help page describes a one-time appeal. Use that path only with a clear policy basis and concise evidence. Do not include clinical records or unnecessary patient information in the submission. If a threat, legal demand, or safety issue exists, follow the practice’s approved escalation route rather than improvising in the reply.

What internal workflow supports consistent replies?

1. Capture the public URL, date, and review text in the approved case system.
2. Do not match the reviewer to a patient in a general marketing tool.
3. Route the case to the trained practice owner, manager, or privacy lead.
4. Classify whether it is feedback, a possible Google policy violation, or a matter needing legal or safety review.
5. Draft a generic reply without confirming the relationship or facts.
6. Have the required reviewer approve high-risk or ambiguous language.
7. Publish from the authorized Business Profile account.
8. Move any case-specific conversation to the approved private channel.
9. Record the response and next operational action without copying unnecessary details.

Use templates as guardrails, not automatic messages. Automated replies can miss allegations, threats, accessibility needs, or wording that requires escalation.

Review access to the Business Profile as carefully as other public links. The guide on Business Profile booking-link ownership shows why agencies, vendors, and practice accounts need explicit responsibility. Public response authority deserves the same clarity.

How does HIPAA permission differ from marketing consent?

HIPAA analysis does not collapse into a website checkbox, advertising permission, or general privacy notice. The practice must identify the actor, information, purpose, recipient, and applicable permission. A public Google reply is one disclosure context; using review content for an ad, audience, testimonial, or conversion record is another.

The comparison of HIPAA authorization, privacy consent, and Google Ads permission explains why separate gates need separate evidence. Passing one gate does not establish the others. Do not turn a complaint response into promotional content simply because the original review is favorable or publicly visible.

A dental practice that is not a HIPAA covered entity may still face state privacy, professional, contract, and platform requirements. This article’s specific HIPAA framing is for covered practices. Every practice should confirm its actual status and obtain guidance for the laws and professional duties that apply.

How should positive reviews be handled?

A positive review creates the same confirmation risk. Avoid language about treating the person, a procedure result, or a next appointment. Thank the reviewer in general terms without relying on the clinical record.

Do not treat a positive review as permission to advertise a condition, procedure, or result. Republishing it raises separate authorization, professional, advertising, and platform questions.

Keep health details out of campaign URLs, conversion payloads, and audience lists. A public review can reveal sensitive context, but copying it into Google Ads is a new data action. The discussion of healthcare tracking after AHA v. Becerra reinforces the need to analyze the actual disclosure rather than rely on a broad label.

What should staff do during a difficult review incident?

Pause before replying. Preserve the public evidence, restrict internal discussion to people with a need to know, and check for an existing complaint, safety, privacy, or legal process. If the review includes enough detail to identify a person, do not repeat it in chat tools or tickets merely to ask for help.

Decide separately whether to reply, contact the person privately, report a policy violation, or investigate the event. A public reply should not carry the whole incident response.

Review the final response for unnecessary confirmation, confirm the private channel is monitored, and record the approval and any remaining action.

Frequently asked questions

Can the practice say that it cannot find the reviewer in its records?

That statement still describes the practice’s record search and may invite a public exchange about identity. Use generic language and offer an approved private contact route. Ask privacy counsel to approve any exception.

Can the practice correct a false treatment claim?

Do not disclose protected information merely to win the factual dispute. Preserve the claim, investigate internally, use Google’s reporting process when a policy violation exists, and obtain qualified advice for any public correction.

Does a public review waive HIPAA protections?

Do not rely on that assumption. The reviewer controls the review, while the covered practice remains responsible for its own uses and disclosures. Determine the applicable Privacy Rule permission with qualified counsel.

Should every review receive the same response?

No. A controlled set of generic patterns can reduce risk, but threats, policy violations, accessibility concerns, and legal matters may need different escalation. Each public version should remain free of patient confirmation and case details.

References

• Google Business Profile Help, “Manage customer reviews,” retrieved 2026-08-16, https://support.google.com/business/answer/3474050?hl=en
• Google Business Profile Help, “Tips to get more reviews,” retrieved 2026-08-16, https://support.google.com/business/answer/3474122
• Google Business Profile Help, “Report inappropriate reviews on your Business Profile,” retrieved 2026-08-16, https://support.google.com/business/answer/4596773?hl=en
• Electronic Code of Federal Regulations, 45 CFR 164.502, “Uses and disclosures of protected health information: General rules,” current through 2026-08-13, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502

A HIPAA business associate can help fulfill a patient access request, but the covered entity remains responsible for the individual’s right of access. The current rule gives the covered entity no later than 30 calendar days after receipt to act on a request. Retrieving records from a business associate does not create a second clock.

The business associate agreement should say who receives requests, what records the associate must make available, whether it may send an electronic copy directly, and how it returns the request to the covered entity for decisions outside its assigned role. Software should support that allocation without inventing the designated record set or a reason to deny access.

Who is responsible for the access request?

Section 164.524 places the access duty on the covered entity. Subject to stated exceptions and denial provisions, an individual has a right to inspect and obtain a copy of protected health information about that individual in a designated record set for as long as the information is maintained there. The rule also tells the covered entity how to receive a request, act on it, provide access, handle denials, and retain required documentation.

HHS’s business associate FAQ uses the same allocation. It says covered entities are responsible for Privacy Rule rights, including access, amendment, and accounting. It also says the right includes information in a designated record set held by a business associate unless that information merely duplicates what the covered entity already maintains.

The business associate still has duties. Legal responsibility, contract allocation, and operational work must remain distinct. A covered entity cannot treat the vendor’s queue as a pause button for the request.

What records can the business associate hold?

The question is whether protected health information sits in a designated record set covered by section 164.524. The covered entity must identify those record sets and document who receives and processes access requests.

A health software vendor may hold records that the covered entity uses to make decisions about individuals. The result depends on the system, contract, and record use. A generic product rule should not decide whether logs, derived fields, support notes, duplicates, or metadata belong. The covered entity needs a documented determination that the associate can implement.

Do not confuse this determination with permission to reuse the records for another purpose. A BAA defines permitted and required uses and disclosures; it is not a general data license. The review of cross-tenant clinic benchmarking under a BAA explains why contract scope and a separate use remain different questions.

How does the 30-day clock work?

The current text of 45 CFR 164.524 requires the covered entity to act on an access request no later than 30 days after receipt. If the covered entity grants the request, it must inform the individual and provide the requested access under the rule. If it denies the request in whole or in part, it must issue the required written denial.

The rule allows one extension of no more than 30 days when the covered entity cannot act within the initial period. Within the first 30 days, it must give the individual a written statement explaining the delay and the date by which it will complete its action. The extension is not automatic, and only one is available.

A vendor handoff should preserve the original receipt time. An operational record can contain the request ID, received timestamp, due date, assigned action, status, and escalation owner. This editorial workflow does not authorize the associate to grant itself an extension.

What must the business associate agreement cover?

Section 164.504 requires a business associate contract to establish permitted and required uses and disclosures. Among its listed terms, the contract must provide that the associate will make protected health information available in accordance with section 164.524. If the associate carries out a covered entity’s obligation under the Privacy Rule, it must comply with the requirements that apply to the covered entity in performing that obligation.

The HHS FAQ says the parties may agree that the associate will provide access directly to individuals. This can fit a situation where the associate is the only holder of all or part of the designated record set. Direct delivery should not be inferred from technical capability. The agreement and procedure need to say whether the associate sends to the covered entity, the individual, or the individual’s designee.

HHS’s direct-liability fact sheet adds another boundary. It identifies a business associate’s failure to provide a copy of electronic protected health information to the covered entity or to the individual or designee, whichever the BAA specifies, as a matter for which OCR may have direct enforcement authority under the cited provisions. That agency explanation should be presented as guidance about enforcement, alongside the regulation and contract.

What should the software workflow do?

If a request reaches the associate, the system should connect it to the covered entity’s contract-defined process. It should preserve receipt time, requested scope, possible record set, and response owner. Identity checks and communication should follow the approved procedure without creating unreasonable barriers.

The export step should use the requested form and format when readily producible. For electronic records and an electronic-copy request, section 164.524 describes the requested electronic form and format when readily producible, or a readable electronic form and format agreed with the individual when it is not. The associate should not silently substitute a summary. The rule permits a summary or explanation only under its stated agreement and fee conditions.

Keep access records inside the approved health-data boundary. Do not copy request contents into advertising or unrelated analytics systems. The article on health conversion tracking outside HIPAA explains why another product boundary can add risk.

Where should decisions and denials remain?

Section 164.524 contains specific unreviewable and reviewable grounds for denial. It also requires access to other requested protected health information, where possible, after excluding material for which a denial ground exists. A written denial must use plain language and include the basis, applicable review rights, and complaint information.

A software vendor should not translate those provisions into a universal “sensitive record” switch. Some reviewable grounds depend on professional judgment by a licensed healthcare professional. The covered entity must designate the reviewer required by the rule when a review is requested. The associate can present status, collect the approved determination, produce the permitted portion, and preserve an audit record.

When the request is broader than the associate’s holdings, route it back instead of marking it complete. When the covered entity knows another location maintains the requested information, section 164.524 addresses informing the individual where to direct the request. Product behavior should reflect the approved process, not generate legal conclusions from incomplete inventory.

An evidence checklist for covered entities and vendors

• List the covered entity, business associate, applicable agreement, and current access procedure.
• Identify designated record sets and the systems that maintain them.
• Record the original receipt timestamp and current 30-day due date.
• Assign intake, identity verification, record search, export, delivery, denial, review, and complaint responsibilities.
• State whether the associate sends records to the covered entity or directly to the individual or designee.
• Test requested electronic formats with synthetic records and document any format agreement.
• Prove that duplicate copies are not produced unnecessarily and that partial access remains possible when approved.
• Escalate missing records, uncertain scope, delivery failure, or a possible denial before the deadline expires.

This checklist is editorial advice, not text from HHS. It makes the contract executable and the request traceable. A signed BAA alone does not prove that the workflow can find, export, and deliver the right records on time. The broader product-boundary review for BAAs applies the same evidence discipline to another vendor context.

Frequently asked questions

Does a business associate have to answer every patient directly?

No universal rule in these sources assigns every request directly to the associate. The covered entity remains responsible. The BAA and procedure may require the associate to provide records to the covered entity or to deliver an electronic copy directly to the individual or designee.

Does asking the vendor for records restart the 30-day clock?

No. The rule gives the covered entity no later than 30 days after receipt to act. Internal retrieval from a business associate should preserve that original deadline.

Can the business associate decide that a record is outside the designated record set?

It should not invent that decision. The covered entity should document its designated record sets and give the associate rules it can implement. Uncertain cases need escalation to the responsible privacy or legal reviewer.

Can the associate send a summary instead of the records?

Not by default. Section 164.524 permits a summary or explanation in place of access only when the individual agrees in advance to it and to any associated fee allowed by the rule.

References

• Electronic Code of Federal Regulations, “45 CFR 164.524, Access of individuals to protected health information,” retrieved August 16, 2026, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.524
• Electronic Code of Federal Regulations, “45 CFR 164.504, Uses and disclosures: Organizational requirements,” retrieved August 16, 2026, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504
• U.S. Department of Health and Human Services, “Does the HIPAA Privacy Rule require a business associate to provide individuals with access to their protected health information or an accounting of disclosures, or an opportunity to amend protected health information?” retrieved August 16, 2026, https://www.hhs.gov/hipaa/for-professionals/faq/246/do-business-associates-have-obligations/index.html
• U.S. Department of Health and Human Services, “Direct Liability of Business Associates,” retrieved August 16, 2026, https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/factsheet/index.html

The court decision in American Hospital Association v. Becerra did not give healthcare organizations general permission to use tracking pixels. The court vacated one specific position in HHS guidance: that an IP address combined with a visit to an unauthenticated public page about a condition or provider automatically triggers HIPAA obligations because that combination is individually identifiable health information.

The holding does not classify every other page or payload. Authenticated pages, appointment forms, symptom tools, user-entered details, and vendor disclosures need fact-specific review.

What did the district court actually vacate?

The June 20, 2024 opinion came from the United States District Court for the Northern District of Texas. The dispute focused on HHS guidance for online tracking technologies used by HIPAA covered entities and business associates. The court called the challenged part the “Proscribed Combination.” It joined two facts: an individual’s IP address and a visit to an unauthenticated public webpage that addressed a specific health condition or listed healthcare providers.

The court held that this combination fell outside the statutory definition of individually identifiable health information when HHS treated it as sufficient based on the visitor’s unknowable subjective reason for viewing the page. The final order declared that position unlawful because HHS had acted beyond its HIPAA authority. It denied a permanent injunction but granted vacatur of the Proscribed Combination.

The order was precise about scope. A footnote said the vacatur was not intended to limit the legal operation of other guidance in the bulletin. HHS later moved to dismiss its own appeal, and the Fifth Circuit dismissed it on September 4, 2024 under Federal Rule of Appellate Procedure 42(b). That left the district court’s vacatur operative, but the Fifth Circuit issued no merits opinion controlling later tracking disputes.

What the decision did not decide

The court did not hold that IP addresses can never be part of protected health information. It did not decide that every public healthcare page is outside HIPAA. It did not approve a particular pixel, analytics vendor, advertising platform, consent banner, business associate agreement, or data flow.

The opinion also did not erase the definitions in 45 CFR 160.103. Individually identifiable health information still turns on whether information is created or received by a listed actor, relates to health, healthcare, or payment, and identifies the individual or supplies a reasonable basis to identify the individual. Protected health information remains individually identifiable health information transmitted or maintained in a covered form, subject to stated exclusions.

Those definitions make the payload and context decisive. A page view carrying only the vacated combination differs from a request containing an email address, appointment date, selected service, symptom response, patient portal identifier, or other information tied to care. The article on health tracking outside HIPAA explains why falling outside one federal definition does not resolve every privacy or platform question.

How the current HHS bulletin should be read

HHS keeps its online tracking bulletin available and now opens it by describing the court order. The bulletin states that the court vacated the guidance to the extent it treated the Proscribed Combination as triggering HIPAA obligations. It also says HHS is evaluating next steps.

The bulletin separately discusses authenticated pages, public pages, mobile apps, permitted disclosures, business associate agreements, security safeguards, and breach analysis. HHS says trackers on authenticated pages generally have access to protected health information. It also gives appointment and symptom-checker examples involving information entered on public pages.

That material is agency guidance, not the court’s holding. The bulletin itself says its contents do not have the force and effect of law and are intended to clarify existing requirements or agency policy. A careful article should therefore label each proposition. The court’s order controls the vacatur. The regulations supply the underlying legal rules. The HHS bulletin describes OCR’s current guidance and enforcement perspective.

Why page labels alone are unreliable

Calling a page “public” does not describe everything a tracker can receive. A public location page may expose only a URL and ordinary device information. A public appointment page may add a chosen clinician, visit reason, date, contact detail, or confirmation state. Both are unauthenticated, but their payloads are different.

The same problem appears when teams classify a whole website at once. Shared scripts can run on pages with different purposes and inputs. A tag rule may include URL parameters, element text, entered values, or identifiers that a screenshot does not reveal. A server relay can add context later.

Use a page and payload inventory instead. For each route, record whether the person is authenticated, what the page reveals, what the person can enter, which scripts execute, which fields leave, who receives them, and why. This is an editorial control method, not a test prescribed by the court. It gives legal, privacy, and engineering reviewers facts they can evaluate.

How vendor and purpose analysis still applies

When a tracker receives protected health information on behalf of a regulated entity for a covered function or specified service, the business associate question remains. A signed agreement does not create a business associate relationship when the regulatory definition is not met, and the absence of an agreement does not change a vendor’s actual role. The relationship, information, and purpose need to be mapped.

Section 164.502 continues to govern permitted and prohibited uses and disclosures of protected health information. It also applies the minimum necessary standard to many uses, disclosures, and requests, subject to listed exceptions. The court did not replace those rules with a general permission for tracking.

Authorization and product permission remain separate gates as well. A cookie banner is not automatically a HIPAA authorization, and an authorization does not compel an advertising platform to accept health-related conversion data. See HIPAA authorization, privacy consent, and Google Ads permission for that boundary. Hashing also does not settle purpose or eligibility, as explained in the clinic form hashing review.

A practical review sequence after the case

1. Identify the regulated entity and the exact website, app, or embedded flow under review.
2. Inventory routes individually instead of assigning one label to the domain.
3. Capture the actual outbound request with synthetic data and list every field, header, parameter, identifier, and value added by later processing.
4. Separate the vacated IP plus public-page combination from any additional fact that may relate the visit to a person’s health or care.
5. Map each recipient, its role, the proposed purpose, and any business associate agreement or other contract.
6. Review the use or disclosure under the current regulation, then consult current HHS guidance without presenting it as a judicial holding.
7. Keep delivery disabled while a material fact, permission, contract, or destination remains unresolved.
8. Retest when page content, tag configuration, vendor behavior, URL structure, or event meaning changes.

This sequence is editorial advice. It prevents two opposite errors: treating the vacated position as if it still controlled every public page, or treating the decision as permission to send any healthcare interaction to a third party.

What evidence should support a deployment decision?

A defensible record connects the legal question to observed behavior. Keep the route inventory, synthetic capture, tag configuration, destination, vendor terms, agreement status, purpose, reviewer, source date, and approval limits together.

Use claim-specific language. A team may document that a request lacked health-related information during a defined test. It should not turn that result into “the website is HIPAA compliant.” A vendor’s promise to remove data later does not answer whether the initial disclosure was permitted.

If the proposed route reaches Google advertising products, remember that a Google Cloud agreement does not extend to Google Ads. The Google Cloud BAA boundary shows why provider, product, and destination evidence must remain separate.

Frequently asked questions

Did the court make healthcare tracking pixels legal?

No. The court vacated one HHS position about a specific combination of information. Whether another tracker use is permitted depends on the actual information, actors, purpose, rule, and facts.

Is an IP address never protected health information after the decision?

The decision does not establish that rule. It rejected automatic treatment of the Proscribed Combination. An IP address can appear with other information and in other contexts that require separate analysis under 45 CFR 160.103.

Can a hospital keep trackers on authenticated pages?

The case did not approve that practice. HHS guidance says authenticated pages generally expose protected health information to tracking technologies. Review the actual disclosure, permission, safeguards, vendor role, and contract before deployment.

Does the HHS bulletin still matter?

Yes, as current agency guidance subject to the court’s vacatur. It is useful evidence of OCR’s published position, but it is not the court’s holding and says it does not have the force and effect of law.

References

• United States District Court for the Northern District of Texas, “Opinion and Order, American Hospital Association et al. v. Xavier Becerra et al.,” retrieved August 16, 2026, https://www.aha.org/system/files/media/file/2024/06/opinion-order-in-aha-et-al-v-xavier-becerra-et-al-6-20-2024.pdf
• United States Court of Appeals for the Fifth Circuit, “Motion to Voluntarily Dismiss Appeal Under Federal Rule of Appellate Procedure 42(b),” retrieved August 16, 2026, https://sponsors.aha.org/rs/710-ZLL-651/images/Final%20Motion%20to%20Dismiss%20AHA%20v.%20Becerra%20Filed.pdf?version=0
• United States Court of Appeals for the Fifth Circuit, “Clerk’s dismissal order, No. 24-10775,” retrieved August 16, 2026, https://benefitslink.com/src/ctop/aha-v-becerra-5cir-09042024.pdf
• U.S. Department of Health and Human Services, “Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates,” retrieved August 16, 2026, https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html
• Electronic Code of Federal Regulations, “45 CFR 160.103, Definitions,” retrieved August 16, 2026, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103
• Electronic Code of Federal Regulations, “45 CFR 164.502, Uses and disclosures of protected health information: General rules,” retrieved August 16, 2026, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502

A finding that HIPAA does not apply to a particular actor or activity answers only the HIPAA question. It does not establish that health conversion tracking is low risk. The same flow may still require a separate assessment under the FTC Health Breach Notification Rule, a state consumer health law such as Washington’s My Health My Data Act, and the policy for the specific Google Ads feature receiving the data.

Each test has its own definitions, exemptions, and duties. Do not turn “not a HIPAA covered entity” into a release gate. Map actor, data, action, recipient, jurisdiction, and advertising product, then record evidence and an owner for each branch.

Build four gates, not one compliance label

A conversion flow can begin with a booking form, pass through a CRM or server, and end in an advertising product. Each step can change the relevant actor, purpose, and disclosure. A clinic, wellness app, software vendor, agency, and ad platform should not be grouped under one label. Nor should every value called a “conversion” be treated alike.

Create one record per flow: source, fields, identifiers, transformations, recipients, purpose, retention, population, jurisdiction, and exact destination feature. A generic destination like “Google” is too broad for a policy decision. A branch may be applicable, exempt, prohibited, conditional, or unresolved, but evidence from one branch does not prove another.

Gate 1: HIPAA asks who is acting and in what role

45 CFR 160.103 defines covered entities through categories including health plans, clearinghouses, and providers that transmit health information electronically in covered transactions. It defines business associate through specified functions and services involving protected health information on behalf of a covered entity or another business associate, with stated exceptions.

A company outside the covered-entity definition for one product may be a business associate elsewhere. A provider can also have activities outside a HIPAA-regulated flow. Assess the specific actor, service, activity, and information. Medical vocabulary or a health-related audience does not decide status.

If HIPAA does not govern the examined flow, record that narrow scope. Do not write “HIPAA does not apply to the company” when the analysis covered one app or marketing pathway, and do not infer that the data is safe to disclose.

When a cloud product is involved, remember that contract coverage is also product specific. The article on why a Google Cloud BAA does not cover Google Ads illustrates why a contract for one service cannot authorize a separate advertising use.

Gate 2: FTC HBNR has its own coverage and breach analysis

The FTC Health Breach Notification Rule appears in 16 CFR Part 318. It applies to covered vendors of personal health records, PHR related entities, and third-party service providers rather than using the HIPAA covered-entity test. The current rule and the 2024 final rule define key terms, including PHR identifiable health information, personal health record, covered health care provider, and breach of security.

The 2024 rulemaking clarified the FTC’s view of health apps and similar technologies, including certain unauthorized disclosures. That does not make every tracking event a reportable breach. Coverage, authorization, recipient, event, and exceptions still require fact-specific review.

Ask whether the product offers a personal health record under the rule, whether it has the technical capacity to draw information from multiple sources, what role each vendor plays, and whether an acquisition or disclosure was unauthorized. Assess notice duties only if the preceding elements hold. Use the Federal Register preamble for agency interpretation and the eCFR for current regulatory text.

Do not close this branch with “outside HIPAA.” The HBNR was designed for a different coverage boundary. Conversely, do not assume that using a health app proves HBNR applicability. Document the definition analysis.

Gate 3: Washington consumer health data law is a separate test

Washington RCW 19.373, commonly associated with the My Health My Data Act, defines consumer health data, regulated entities, processors, consumers, collection, sharing, and sale for its own purposes. It contains jurisdictional provisions and exemptions that must be reviewed before applying an obligation to a particular organization or dataset.

Where the law applies, its requirements include a consumer health data privacy policy and specific rules for collection, sharing, sale, access, deletion, processors, and security. Consent for collection or sharing and a separate signed authorization for sale are distinct concepts in the statute. An ordinary cookie banner should not be assumed to satisfy either without comparing its wording and interaction to the applicable requirement.

Start with person and geography, then classify entity and data. Check statutory exemptions. Determine whether the flow is collection, sharing, or sale under the statute, then test the matching notice, consent or authorization, processor, rights, and security provisions.

Neither “the user lives in Washington” nor “the company is a clinic” completes the statutory analysis. Preserve the facts and section supporting the conclusion.

Gate 4: Google policies depend on the exact advertising feature

Google’s Customer Data policies apply to enhanced conversions for web, enhanced conversions for leads, store sales uploads, and Google-engaged audiences. The policy prohibits uploading conversion information related to sensitive categories, including health or medical information, for the covered Customer Data products. This is a product-policy test, not a HIPAA definition or a determination that every health advertiser is prohibited from measuring any result.

Google’s personalized advertising policy separately treats health as a sensitive interest category and limits advertiser-curated audiences for that content. Customer Match belongs in this separate personalized-advertising and Customer Match policy branch, not in the four-product scope stated above. This policy does not ban all health advertising, but consent, hashing, or a lawful source cannot be assumed to make an audience or upload eligible.

Test the current product and configuration. Review every field and derived value, including URL parameters, event labels, list names, variables, and free text. A neutral event name can carry sensitive meaning when combined with its page or source. Hashing changes representation, not the underlying category or product rule.

For a narrower data design, see the clinic booking outcome taxonomy. If the proposed route uses a server or data manager, the Google Ads Data Manager clinic-form architecture helps identify boundaries, but architecture alone cannot make a prohibited payload eligible.

Consent is not a bridge across independent gates

Consent is not a universal override. The FTC branch may ask whether an acquisition or disclosure was authorized. Washington law specifies consent and sale authorization for covered activities. Google policy can prohibit a use even when the advertiser believes it has valid consent.

Keep booking consent separate from advertising choices. A person may request care without agreeing to a health-related conversion upload. Preserve notice, choice, version, time, and purpose instead of only a boolean called consent.

This is an editorial implementation recommendation. Determine the relevant consent standard under each law; this does not replace legal review or current platform terms.

A safer implementation review for health conversions

After the four gates, review the data path. Many reports can measure booking requested, confirmed, attended, or canceled without diagnosis, treatment, clinician notes, page titles, or free text. The internal treatment-value model explains why internal value and an advertising payload should remain separate.

• Allowlist fields: reject unexpected values instead of forwarding the full form.
• Separate destinations: do not reuse a clinical event object as an advertising event object.
• Remove free text: keep symptoms, procedures, notes, and detailed URLs out of marketing connectors.
• Log decisions: store gate results, policy version, owner, and evidence without logging health content.
• Fail closed: pause transmission when classification, consent evidence, or product eligibility is unresolved.
• Recheck changes: review new fields, destinations, jurisdictions, and policy revisions before release.

A clean technical payload does not cure an inapplicable consent or an unauthorized disclosure. Equally, a valid legal basis does not cure a product-policy prohibition. The implementation review reduces exposure after the independent decisions; it does not merge them.

Document a decision matrix that can be audited

For each flow, create four rows: HIPAA, FTC HBNR, Washington law, and Google policy. Record definitions, facts, conclusion, unresolved questions, source version, approver, and review date. Add other states when needed. “Compliant” alone is not an auditable result.

Require every relevant row to be resolved. HIPAA can be out of scope while HBNR remains open. Law may permit an activity that Google policy prohibits, or policy may allow an approach that lacks required legal authorization. In each case, keep the upload blocked.

Frequently Asked Questions

If a clinic is not a HIPAA covered entity, can it send health conversions to Google Ads?

That conclusion is insufficient. Test FTC HBNR, applicable state consumer health laws, other duties, and the exact Google Ads policy. Any one branch can stop or change the proposed flow.

Does hashing make a health conversion non-sensitive?

No general conclusion follows from hashing. It can transform an identifier, but the event, source, and combination may still relate to health, remain identifiable, or be prohibited by the selected product policy.

Does the FTC HBNR apply to every health app?

No. Apply the rule’s definitions to the product, data sources, actors, and event. The 2024 final rule provides relevant interpretation, but the facts still determine coverage and duties.

Is Washington consent the same as a cookie banner choice?

Do not assume so. Compare the interaction to the statute’s requirements for the classified collection, sharing, or sale, including the separate authorization provisions where applicable.

Does Google’s sensitive-interest policy ban all healthcare ads?

No. It restricts specified personalized advertising uses and targeting for sensitive interests. The Customer Data policy separately governs covered uploads. Review the exact feature and current policy.

References

• 45 CFR 160.103, Definitions
• 16 CFR Part 318, Health Breach Notification Rule
• Federal Trade Commission, 2024 Health Breach Notification Rule final rule
• Revised Code of Washington, Chapter 19.373
• Google Ads, Customer Data policies
• Google Ads, Personalized advertising policy

HIPAA Authorization, Privacy Consent, and Google Ads Permission Are Different Gates. A clinic can satisfy one gate and still fail another. A HIPAA authorization addresses a use or disclosure of protected health information under a specific federal rule. A privacy consent may address a separate purpose or legal duty. Google Ads then applies its own product policies to the proposed data use.

Review each gate independently. Do not treat a checkbox, signed authorization, privacy notice, vendor contract, or tag as universal approval. The official sources document different questions, and none says that one answer settles the others.

Why do these permissions need separate decisions?

Each permission answers a different question. HIPAA governs whether a covered entity may use or disclose protected health information for a defined purpose. Other privacy rules may require notice or a valid choice. Google decides whether its advertising product accepts the proposed data and use.

A single form can touch all three questions without producing the same answer. The clinic might have authority to keep information for treatment while lacking authority for a marketing disclosure. It might have a legally valid authorization while Google policy still excludes the conversion from a specific measurement product.

This separation also prevents a technical test from becoming a policy decision. A tag that fires or an interface that accepts a field proves only that a technical step occurred. The enhanced conversions audit proof guide explains why configuration, processing, reporting, and business outcomes are different proof layers.

What does 45 CFR 164.506 document about consent?

Section 164.506 permits covered entities to use or disclose protected health information for treatment, payment, or health care operations under the conditions stated in the rule. It also says a covered entity may obtain an individual’s consent for those permitted uses and disclosures. The word “may” matters because this is not a general authorization form for every purpose.

The same section states that this consent is not effective when section 164.508 requires an authorization or when another condition must be met. In other words, consent under 164.506 cannot be stretched to cover a use or disclosure that belongs behind another gate.

That is the documented rule. An editorial recommendation follows from it: label any 164.506 consent by its actual treatment, payment, or operations purpose. Do not name it “marketing consent” or “Google Ads consent” unless a qualified review has established a separate basis and the label accurately describes the choice.

When does 45 CFR 164.508 require authorization?

Section 164.508 provides the general rule for uses and disclosures that require authorization. It states that, unless another provision permits or requires the action, a covered entity may not use or disclose protected health information without a valid authorization. When authorization exists, the use or disclosure must remain consistent with it.

The section also addresses marketing uses of protected health information, with stated exceptions for certain face-to-face communications and promotional gifts of nominal value. It lists core authorization elements, including a meaningful description of the information, the authorized sender and recipient, the purpose, an expiration date or event, and a signature with date.

A valid authorization must also contain required statements, use plain language, and be copied to the individual when the covered entity seeks it. These requirements make authorization a defined document and process. A generic website checkbox or an acceptance of advertising cookies should not be relabeled as a HIPAA authorization without a qualified review against the rule.

Editorial recommendation: keep the signed authorization, its scope, revocation status, and disclosure record in the clinic’s approved environment. Do not copy the authorization, its text, or the underlying protected information into advertising fields.

Where does purpose-specific privacy consent fit?

“Privacy consent” is not a substitute term for either HIPAA provision. It can describe a choice required by another law, a website consent mechanism, or a clinic’s own permission workflow. The three registry sources do not define every state, federal, or international privacy requirement, so the exact duty must be assessed for the clinic’s jurisdiction and proposed use.

Separate every consent record by purpose. A choice about analytics does not automatically cover advertising. A choice about receiving messages does not automatically authorize disclosure of protected health information. A HIPAA authorization does not erase separate notice, consent, contract, or platform obligations.

Document the privacy gate in plain language: what data is involved, who receives it, why it is used, what choice the person has, and which rule or policy supports the decision. If the team cannot answer those points, pause the external use instead of borrowing approval from another checkbox.

What permission does Google Ads require?

Google’s Customer data policies apply to enhanced conversions for web, enhanced conversions for leads, store sales uploads, and Google-engaged audiences. They require advertisers to disclose relevant third-party sharing, obtain consent where legally required, comply with applicable laws, and use approved upload methods. Those requirements do not create eligibility by themselves.

The policy separately says advertisers may not upload conversion information related to sensitive categories. It identifies health or medical information as sensitive and says conversions related to sensitive categories cannot be measured through enhanced conversions or store sales uploads. A signed HIPAA authorization does not appear as an exception to that product restriction.

This is a documented platform fact, not an editorial preference. For a health-related clinic conversion within the stated policy scope, do not proceed because the patient signed a form. The article on why hashing does not establish eligibility applies the same policy boundary to clinic forms.

Google permission must be evaluated for the exact product and use. A customer-data policy for enhanced conversions does not answer every question about ordinary aggregate campaign reporting. Likewise, a successful API request does not grant permission. The clinic form Data Manager architecture keeps collection and delivery as separate decisions.

How should a clinic record the four gates?

The following table is an editorial control model. It is not language taken from the regulations or Google, and it is not a claim that every clinic faces the same legal duties. Its purpose is to stop one approval from silently standing in for another.

Gate	Question to record	Evidence	What it cannot prove
HIPAA treatment, payment, or operations consent	Does 45 CFR 164.506 apply to this use or disclosure?	Scoped review and consent record, if used	Authorization for a use that requires 164.508
HIPAA authorization	Does the authorization meet 164.508 and cover this exact use?	Valid, current authorization and disclosure scope	Eligibility for a Google product
Other privacy consent	What separate notice or choice applies to this purpose?	Applicable rule, notice, choice, and timestamp	HIPAA authorization or platform approval
Google Ads permission	Does the current policy permit this data and use?	Product, policy version, event classification, reviewer	Compliance with HIPAA or another law

Give each row an owner and review date. Legal counsel assesses the relevant law. Privacy staff assess purpose and notice. Advertising and engineering teams describe the product, payload, and technical route. A completed implementation ticket does not record every approval.

What is a safe review sequence?

1. Describe the proposed use or disclosure in ordinary language.
2. Identify whether protected health information or health-related conversion information is involved.
3. Review 45 CFR 164.506 and 164.508 separately where HIPAA applies.
4. Identify any other purpose-specific privacy requirement without assuming it duplicates HIPAA.
5. Classify the exact Google Ads product, data, destination, and intended use.
6. Stop when any required gate fails or remains unresolved.
7. Record the decision, source date, owner, and conditions for another review.

This sequence is an editorial recommendation. The regulations and Google policy supply the rules described above, but they do not prescribe this seven-step clinic workflow. The workflow makes the reasoning inspectable and keeps ambiguous health data out of advertising while the answer remains unresolved.

Internal analysis can continue without turning every clinic record into an advertising event. Aggregate reporting and clinic-owned outcome models can answer operational questions inside an approved boundary. See the internal treatment-acceptance value model for a related separation between internal economics and an external payload.

Frequently asked questions

Does a HIPAA authorization permit an enhanced conversion for a clinic?

Not by itself. A valid authorization addresses the use or disclosure described under 45 CFR 164.508. Google separately prohibits health-related conversion information in the enhanced-conversion measurement covered by its Customer data policies. Both gates must be evaluated, and a failure at either gate stops that use.

Is consent under 45 CFR 164.506 the same as authorization?

No. Section 164.506 says a covered entity may obtain consent for treatment, payment, or health care operations. It also says that consent is ineffective where 164.508 requires authorization or another condition remains unmet.

Can a website privacy checkbox serve as a HIPAA authorization?

Do not assume so. Section 164.508 requires specific elements and statements, plain language, a signature and date, and a copy for the individual when the covered entity seeks authorization. A qualified reviewer must assess the actual mechanism and proposed disclosure.

Can one approval record cover all four gates?

Do not assume it can. One record may hold links to separate decisions, but each gate still needs its own purpose, governing source, scope, owner, and outcome. A combined record must not blur a failed or unresolved gate.

References

• Electronic Code of Federal Regulations, “45 CFR 164.506, Uses and disclosures to carry out treatment, payment, or health care operations,” retrieved 2026-08-16, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.506
• Electronic Code of Federal Regulations, “45 CFR 164.508, Uses and disclosures for which an authorization is required,” retrieved 2026-08-16, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.508
• Google Advertising Policies Help, “Customer data policies,” retrieved 2026-08-16, https://support.google.com/adspolicy/answer/7475709?hl=en

No, not by itself. A business associate agreement can authorize a SaaS vendor to perform defined services with protected health information, and it may permit a specific form of data aggregation. It does not give the vendor blanket permission to reuse every clinic’s data for product benchmarking, product development, sales, or marketing.

A cross-clinic comparison can fit HIPAA’s data aggregation provision only when the vendor combines information received as the business associate of different covered entities to permit analyses related to their respective health care operations. Calling a feature a benchmark does not settle that test.

What a BAA permits, and what it cannot create

Under 45 CFR 164.504(e), a business associate contract must establish the permitted and required uses and disclosures of PHI. It must also provide that the business associate will not use or further disclose the information except as the contract permits or requires, or as required by law. The contract generally cannot authorize the business associate to do something that would violate the Privacy Rule if the covered entity did it.

The rule has bounded provisions for the business associate’s management, administration, legal responsibilities, and data aggregation services. Management and administration is not a catch-all for commercial analytics. The use must be necessary for that stated purpose, and disclosures outside the business associate have added conditions.

HHS’s sample provisions let parties list permissible purposes or refer to a services agreement. They may separately include optional language for management and administration, data aggregation, or de-identification.

Scope follows the product and purpose, not the vendor name. For example, a Google Cloud BAA does not extend to Google Ads merely because one company operates both products.

HIPAA data aggregation is a narrow cross-entity service

45 CFR 164.501 defines data aggregation as a business associate combining PHI received for one covered entity with PHI received in its business associate capacity for another covered entity. The purpose must be to permit data analyses related to the health care operations of the respective covered entities. The definition does contemplate information from more than one clinic. It does not approve every use of the resulting pool.

Suppose two clinics ask their shared scheduling vendor for an attendance comparison so each clinic can review its own operations. That purpose may fit regulatory data aggregation if the contracts permit it and the activity qualifies as health care operations.

A vendor might want the same pool to set its pricing, publish a clinic ranking, support a sales claim, or build a product for unrelated customers. The data aggregation provision does not establish permission for those independent purposes. The contract and service description should say what the vendor calculates, for whom, and why.

Aggregated is not the same as de-identified

A chart of percentages may look anonymous, but presentation format is not the HIPAA test. Under 45 CFR 164.514, information is de-identified only when it does not identify an individual and there is no reasonable basis to believe it can.

Expert Determination requires a person with appropriate statistical and scientific knowledge to determine and document that the risk of identification is very small for anticipated recipients, considering the information alone and in combination with other reasonably available information. Safe Harbor requires removal of the listed identifiers and no actual knowledge that the remaining information could identify an individual.

Small clinic populations, narrow time windows, or detailed filters can make aggregate output revealing. Teams should not invent a fixed cell-size threshold and present it as HIPAA law.

HHS recommends specifying whether the business associate may de-identify PHI, the method, and permitted uses of the result. Contractual permission is not proof that an output passed either method. Hashing or removing names does not establish de-identification, as explained in the article on why hashing does not change an underlying data-use boundary.

A limited data set remains PHI

A limited data set is a different path under 45 CFR 164.514(e). It omits specified direct identifiers but may retain information that Safe Harbor would remove. It remains PHI and may be used or disclosed only for research, public health, or health care operations under a data use agreement.

A vendor cannot call a limited data set de-identified or treat it as unrestricted product data. The data use agreement does not create a marketing license. A benchmark using this path needs both the BAA analysis and data use agreement controls.

Minimum necessary applies before the chart appears

A benchmark may publish only rates while its pipeline reads entire records. Minimum necessary review covers uses, disclosures, and requests for PHI, not only the final chart. 45 CFR 164.514(d) calls for reasonable efforts to limit PHI to what the purpose needs. HHS’s sample BAA ties this work to the covered entity’s policies or specific contract limits.

Document the measures, required fields, detail, time window, recipients, and retention. An attendance rate may need event counts and a bounded cohort label rather than the complete booking record. The method in measuring show rate without appointment details separates a reporting question from unnecessary record content.

Minimum necessary is not a substitute for purpose authority. A small unauthorized data set is still unauthorized, while an authorized purpose does not excuse unneeded fields.

A BAA is not individual authorization

A BAA governs the relationship between a covered entity and business associate. It is not an authorization signed by an individual. Under 45 CFR 164.508, a covered entity generally needs a valid authorization for a PHI use or disclosure not otherwise permitted or required by the Privacy Rule.

Do not jump from an uncertain benchmark purpose to the blanket statement that every patient must sign an authorization. Health care operations and other provisions may supply authority for some uses. Conversely, an authorization does not automatically rewrite a vendor’s contract or answer whether the vendor is acting as a business associate for that purpose.

Marketing has a specific regulatory meaning and generally concerns communications that encourage purchase or use, subject to exceptions. Internal product analysis is not necessarily marketing, but calling it internal does not make it data aggregation. If PHI supports marketing or another use outside existing permissions, identify the Privacy Rule basis and contract authority first.

A practical review before launching a benchmark

1. Write the purpose. Name the covered entities whose health care operations the analysis supports. Do not use the data aggregation label for an unrelated vendor program.
2. Trace contractual authority. Read the BAA with incorporated service terms. Do not infer ownership from access.
3. Map inputs and outputs. Record fields, time ranges, clinic partitions, calculations, recipients, exports, and retention. Test tenant boundaries with synthetic records.
4. Classify the output. State whether it remains PHI, is a limited data set under a data use agreement, or passed a documented de-identification method.
5. Apply minimum necessary. Remove fields and detail that do not serve the approved analysis.
6. Review other authority. Check for another HIPAA permission or valid authorization, then assess applicable state law, contracts, confidentiality promises, and specialized rules.

Record a decision for a named use and audience, not a claim that every future benchmark is compliant. Reopen it when the purpose, data, recipients, output detail, or contract changes.

Frequently asked questions

Does a signed BAA permit cross-clinic benchmarking by default?

No. The agreement must permit the use, and any reliance on data aggregation must satisfy the regulatory definition and support health care operations of the respective covered entities.

Can a vendor benchmark clinics after removing patient names?

Removing names alone does not establish de-identification. The output must satisfy Expert Determination or Safe Harbor, and the contract should authorize the business associate to perform that de-identification and define permitted uses.

Is a limited data set enough for any benchmark?

No. It remains PHI, is limited to research, public health, or health care operations, and requires a compliant data use agreement. The stated benchmark purpose must still fit.

Does de-identification remove every restriction?

No. Properly de-identified information is no longer PHI under the HIPAA Privacy Rule, but contracts, state law, consumer-protection rules, confidentiality commitments, and governance controls may still restrict its use.

Can an individual authorization fix an otherwise unsupported use?

A valid authorization may supply Privacy Rule authority for a specifically described use or disclosure, but it is not a blanket data license. The vendor still needs matching contractual authority and must comply with other applicable duties.

References

• Electronic Code of Federal Regulations, 45 CFR 164.501, Definitions, retrieved August 16, 2026, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.501
• Electronic Code of Federal Regulations, 45 CFR 164.504, Uses and disclosures: Organizational requirements, retrieved August 16, 2026, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504
• Electronic Code of Federal Regulations, 45 CFR 164.508, Uses and disclosures for which an authorization is required, retrieved August 16, 2026, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.508
• Electronic Code of Federal Regulations, 45 CFR 164.514, Other requirements relating to uses and disclosures of protected health information, retrieved August 16, 2026, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514
• U.S. Department of Health and Human Services, Sample Business Associate Agreement Provisions, retrieved August 16, 2026, https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html

A Google Cloud Business Associate Agreement applies to the Google Cloud services and conditions identified in that agreement. It does not travel with information when a workload sends an event to Google Ads. Google Ads is a separate product destination with its own terms, customer data policies, account configuration, and approval path.

This boundary matters because an architecture can be technically sound inside Google Cloud and still create an unapproved advertising disclosure at its final step. A covered runtime, database, queue, or secret store does not extend the provider agreement to an Ads API. Review each destination independently before connecting it.

What the Google Cloud BAA actually scopes

Google Cloud’s HIPAA compliance page states that customers subject to HIPAA who use Google Cloud with protected health information must review and accept Google’s BAA. The page describes coverage for Google Cloud’s infrastructure and the listed covered products. It also makes shared responsibility explicit: the agreement does not, by itself, make a customer’s application compliant.

That is a product boundary, not a corporate halo. Record the legal entity, billing account, organization, projects, named services, features, regions, support path, and agreement version. Then connect those provider facts to customer controls such as identity, tenant isolation, encryption, logging, backups, retention, incident response, and workforce access. The Google Cloud covered-product review explains how to preserve that evidence chain.

A useful statement is narrow: “This workload uses named Google Cloud services listed in the current provider scope under the accepted agreement.” It should not become “Anything this workload calls is covered.” Once information crosses to another product, the team must evaluate the new recipient and purpose.

Why Google Ads stays outside that boundary

Google Ads is an advertising platform, not a service added to the Google Cloud BAA because the same vendor operates both brands. The Google Cloud compliance page defines its own covered products. Google Ads publishes separate customer data policies. Procurement, credentials, support, data use, retention, and enforcement also follow different product systems.

Layer	Question	Evidence to preserve
Google Cloud	Is the exact service in the current BAA scope?	Agreement, covered-product page, project and feature list
Application	Does configuration enforce the intended data boundary?	Data-flow map, access tests, logs and retention settings
Google Ads	Does policy permit this exact conversion use and field set?	Current policy, destination configuration and written approval
Transfer	What leaves Cloud, and why?	Serializer allowlist, queue record and delivery evidence

Do not combine those rows into one compliance claim. A contract review can establish provider scope. A technical test can establish observed behavior. A policy review can establish whether an advertising use is permitted under the published rules at that date. Counsel can assess legal duties. None substitutes for the others.

Google Ads customer data policy changes the decision

Google’s customer data policy applies to features including enhanced conversions, store sales uploads, and other customer data uses identified on the page. It prohibits uploading conversion information related to sensitive categories. The policy lists health and medical information, including purchases of medical services, among those categories.

A generic event label does not necessarily remove the context. “Lead,” “booking,” or “qualified” may still represent a health-related interaction when joined to the source, campaign, account, timing, or destination. Hashing an email address does not change the purpose or sensitivity of the underlying conversion. An API success response proves transport, not policy permission.

This is why a health organization should start with internal measurement. Keep detailed outcomes inside the approved environment. Use aggregated reporting where it answers the business question. If any Ads conversion route is proposed, review the exact feature, event meaning, identifiers, timestamps, click references, consent state, account type, and current policy. The Google Ads health conversion policy review provides a focused checklist.

Where the Data Manager API fits

Google describes the Data Manager API as a way to send audience and conversion data to multiple Google advertising products. That makes it a transport and destination-management surface for advertising. It does not make Google Ads part of Google Cloud’s covered-product list, and it does not convert a Cloud BAA into permission for the event.

approved internal application
  -> explicit event decision
  -> minimum field allowlist
  -> policy and consent gate
  -> outbound queue
  -> Data Manager API
  -> named Google advertising destination

Every arrow after the internal application deserves its own owner. The event decision defines what the record means. The allowlist prevents a full operational object from leaking into advertising. The policy gate confirms a current written decision. The queue preserves suppression and retry state. The destination record shows where the API sent the event.

For a bounded implementation pattern, see the server-side clinic form architecture. Its central safeguard is fail-closed behavior: no external delivery when policy, approval, field eligibility, or destination is unknown.

A decision gate before any Ads connection

1. Name the Google Cloud boundary. List services, features, projects, regions, agreement version, and administrative accounts.
2. Name the advertising destination. Record the exact Google Ads customer, conversion action, API surface, data owner, and purpose.
3. Describe the event in plain language. State what real-world action it represents. Do not rely on a generic technical label.
4. Inspect every field. Include identifiers, hashes, click references, timestamps, values, URLs, metadata, logs, and retry payloads.
5. Review current policy and law separately. Preserve retrieval dates, questions, approvals, and unresolved limits.
6. Test suppression first. With synthetic events, prove that missing approval, unexpected fields, wrong destination, or denied consent stops before the outbound queue.
7. Reconcile delivery. If the route is approved, distinguish queued, sent, accepted, rejected, suppressed, and reported states.

This gate should produce a bounded decision, not a permanent certificate. Reopen it when the form changes, an Ads feature changes, a new identifier is added, ownership moves, policy is revised, or the meaning of the conversion changes. The separate BAA scope evaluation method can be reused for the Cloud side without blurring the advertising side.

Common boundary failures

• Treating “Google” as one product scope across Cloud, Analytics, Ads, support, and third-party integrations.
• Assuming a Cloud Run or storage configuration controls what Google Ads does after receipt.
• Sending the full form or operational record because the server already has it.
• Calling hashed contact details anonymous without assessing linkability, purpose, and policy.
• Using a successful Data Manager response as evidence of contractual or policy approval.
• Leaving a browser tag active beside a reviewed server-side route.
• Logging rejected payload contents instead of a safe reason code.

The smallest defensible design has one internal event definition, one explicit outbound gate, one allowed field set, one named Ads destination, and one reconciliation record. If the external use is not approved, stop at internal or aggregate measurement. Technical capability is not a reason to widen the flow.

What can be claimed after review?

Use evidence-specific language. You may be able to say that the provider page listed a Google Cloud service on a given date, that the organization accepted an agreement, or that a synthetic test blocked an unexpected field. You may separately document that counsel and the policy owner reviewed a named advertising use against current sources.

Avoid claiming that Google Cloud, Google Ads, the Data Manager API, or the architecture is compliant in the abstract. Product lists, policies, configurations, contracts, and uses change. Keep the source date beside the conclusion, preserve open questions, and make reapproval a deployment condition when the boundary changes.

Frequently asked questions

Does accepting Google Cloud’s BAA cover a Google Ads account?

No. The Google Cloud agreement applies to its stated Google Cloud scope. Google Ads is a separate destination with separate terms, policies, configuration, and review.

Does running the connector on Cloud Run change that answer?

No. The runtime may sit inside the reviewed Cloud boundary, but the API destination remains Google Ads. Assess the outbound event and recipient independently.

Does the Data Manager API approve health-related conversions?

No. Its documentation describes how data reaches advertising products. Eligibility depends on current product policy, the exact use, contracts, consent requirements, and applicable law.

What should happen when the policy answer is unclear?

Keep external delivery disabled. Measure internally or in aggregate while qualified policy, privacy, security, and legal reviewers assess the exact event and field set.

References

• Google Cloud, HIPAA Compliance on Google Cloud, retrieved August 16, 2026, https://cloud.google.com/security/compliance/hipaa-compliance
• Google Ads, Customer Data Policies, retrieved August 16, 2026, https://support.google.com/adspolicy/answer/7475709?hl=en
• Google for Developers, Data Manager API overview, retrieved August 16, 2026, https://developers.google.com/data-manager/api

A breach-notification tabletop should test roles, facts, evidence, risk assessment, communications, recovery, and post-exercise actions without using a real person’s record. The exercise is successful when the team can identify what it knows, what it does not know, who decides, which clock applies, and how it preserves continuity. It is not successful merely because the team reaches a fast answer.

Use a fictional but plausible scenario involving a booking event, support access, export, vendor notice, or backup restore. Label current rules, contract deadlines, and internal targets separately. HHS breach guidance, eCFR business associate notification, and NIST incident-handling practice provide the source framework; qualified counsel decides the legal outcome.

Detection, triage, and current duty

Start the exercise with one controlled inject: a monitoring alert, vendor email, user report, unexpected export, or support-access anomaly. The facilitator should reveal facts in stages. The team must record discovery time, source, systems, tenant scope, data class, and uncertainty before proposing a public statement.

1. Declare the exercise and assign an incident commander.
2. Open a restricted record with an opaque scenario reference.
3. Identify security, privacy, legal, operations, vendor, and customer owners.
4. Preserve logs and configuration evidence.
5. Contain ongoing access without destroying evidence.
6. Set the next decision time.

Do not use a real booking record, customer name, contact detail, service detail, or production export. Synthetic data should resemble the shape of the system while remaining fictional. Keep exercise communications in a clearly labeled channel.

Containment and evidence preservation

Give the team a failure that tests a real control: a support role accessed the wrong tenant, a queue replayed an event, a backup restored to the wrong region, or an export reached an unapproved destination. Ask what action stops the exposure and what evidence must be captured before taking it.

Inject	Expected question	Evidence
Wrong tenant access	Which identity and scope were used?	Access and membership events
Queue replay	Was a duplicate side effect created?	Event key and processing state
Backup restore	Where was the copy created?	Restore job and authorization
Vendor export	Who received the data and why?	Job, destination, and vendor notice
Support ticket	What content entered the ticket?	Redaction and access evidence

Use opaque references and metadata in the exercise log. Do not “prove” the incident by copying sensitive content. The healthcare incident response runbook provides the first-day sequence.

Risk assessment and notification decision

After the facts are revealed, apply the four-factor breach risk assessment: nature and extent of the information, who received or may have accessed it, whether it was acquired or viewed, and the extent of mitigation. Require the team to identify evidence and confidence for each factor.

Then introduce the contract. A customer may require notice sooner than the statutory outer limit. Ask the team to write two clocks: operational contract notice and legal notification deadline. Ask who contacts counsel, the covered entity, individuals, the regulator, or the media. Do not let the facilitator reveal the correct legal conclusion.

Business associate notification duties and individual notification rules should be checked against current official text. If the team says “the BAA makes the platform compliant” or “encryption ends the incident,” stop the exercise and correct the premise. A BAA creates obligations; it does not transform the software or erase breach analysis.

Use HIPAA breach risk assessment for the decision worksheet and encryption at rest and in transit for evidence about keys and coverage.

Communications and recovery

Test internal and external communications separately. Internal responders need facts, owner, next action, and evidence. Customers and individuals need approved content, timing, contact route, and legal review. Public relations should not publish a technical guess. Keep health detail out of general chat, email subject lines, and exercise screenshots.

Introduce a recovery inject: the affected service is isolated, a backup is available, but a key or vendor dependency is uncertain. Ask who approves restore, where the data goes, which role can access it, how the booking source remains authoritative, and how stale queues are reconciled.

The contingency plan and restore article gives a recovery sequence. Require post-restore authorization and cleanup evidence. A restore test that leaves a copy in a shared environment is a failed exercise.

Facilitator guide and scoring

Set objectives before the session. Possible objectives are: identify the incident commander within a short target, locate the vendor agreement, calculate the contract clock, preserve evidence, complete the four-factor worksheet, or prove that a restore stays in the home region. These are internal exercise targets and should be labeled as such.

Capability	Pass condition	Follow-up if missed
Roles	Owner named for each decision	Update contact tree
Facts	Known and unknown separated	Improve evidence access
Containment	Action stops exposure safely	Test runbook and permissions
Notification	Clocks and approvers correct	Review contract and training
Recovery	Restore and cleanup controlled	Run technical drill

Do not score legal judgment as a trivia contest. Score whether the team recognized the question, found the source, escalated, and recorded the decision. A team that pauses for counsel can demonstrate stronger control than one that guesses quickly.

After-action plan

Within the agreed exercise window, write findings as facts, risks, and actions. Each action needs an owner, due date, priority, evidence, and retest condition. Separate policy changes, code changes, vendor requests, contract changes, training, and future exercises.

• Correct missing incident contacts.
• Remove content from alerts, tickets, and logs.
• Test tenant and region denial paths.
• Update vendor notice and subprocessor records.
• Run a restore and key-recovery test.
• Review conversion and support gates.
• Repeat the tabletop after material changes.

Keep the exercise report free of real records. Link to evidence by opaque reference and store it under the approved retention policy. The security monitoring alerts article can help turn findings into focused controls.

Tenant approval checklist

Before running the exercise, approve scenario, participants, data handling, facilitator, objectives, communications, evidence location, and legal observer. After the exercise, obtain sign-off on findings and dates. Do not use a live customer or production event as an exercise input.

1. Scenario and injects approved.
2. Only synthetic data used.
3. Roles and contact tree current.
4. Contract and statutory clocks included.
5. Risk assessment and notification owners present.
6. Containment and restore actions tested safely.
7. Findings assigned with deadlines.
8. Retest date scheduled.

FAQ

What is the first verification step for a HIPAA breach notification tabletop?

Approve a synthetic scenario, assign the incident commander, and define the exercise objectives. Then test discovery, evidence preservation, containment, and decision ownership.

Which source or configuration detail could change this answer?

Current breach rules, business associate contract terms, notification contacts, vendor scope, access controls, and restore behavior can change the exercise. Recheck before each session.

What must be approved before a production claim or outbound action?

The tenant, incident commander, privacy owner, security owner, and qualified counsel should approve scenario handling and any real-world communication. Exercise outputs must not trigger production actions without a separate decision.

References

• U.S. Department of Health and Human Services, Breach Notification Rule, retrieved 2026-08-15, https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html
• National Institute of Standards and Technology, SP 800-61 Revision 2 Incident Handling, retrieved 2026-08-15, https://csrc.nist.gov/pubs/sp/800/61/r2/final
• Electronic Code of Federal Regulations, 45 CFR 164.410 Business Associate Notification, retrieved 2026-08-15, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D/section-164.410