Patient Reviews Without the Compliance Risk

The question I get asked most often by practice managers is some version of "can we even ask for reviews?" The answer is yes, and most practices are more cautious than they need to be — but the caution comes from somewhere real, and the mistakes I see are specific and avoidable. This post lays out the line in plain terms: what a practice may safely do, what creates exposure, and a review workflow that holds up without ever touching protected health information. One note before any of that: I'm not a lawyer, and this isn't legal advice — talk to your compliance officer or counsel before you finalize a review policy. What follows is how we think about it on the marketing side, and it's the standard we hold every review program we build to.

The line in plain terms: PHI includes the fact of being a patient

The detail that trips up more practices than any other is this: protected health information isn't limited to diagnoses or treatment details. Under HIPAA, PHI includes the fact that a specific, identifiable person is or was a patient at a specific practice, connected to any health-related context at all. That means a review response that confirms someone was treated at your office — even without naming a condition — can itself be a disclosure, because it links an identifiable individual to the fact of receiving care there. This is the single most misunderstood part of the whole topic, and it's the reason a policy built only around "don't mention diagnoses" isn't actually safe.

What a practice may do

Practices can ask for reviews. They can ask every patient, consistently, through a neutral channel — a general follow-up message, a receipt-linked prompt, a sign at checkout — that invites a general reaction to the visit rather than a specific account of it. "How was your visit today?" is a safe prompt. "Tell us about your treatment" is not, because it invites the patient to describe care in identifiable terms in a public forum the practice doesn't control.

Practices can also respond to reviews, including negative ones, as long as the response stays general. A safe response acknowledges the reviewer's experience and invites them to continue the conversation offline — by phone, by a direct message, through the front desk — without confirming or denying that the person was a patient, and without referencing any visit, procedure, or outcome. "We're glad to hear this, thank you for taking the time to share it" is the shape of a safe response. "We're so glad your procedure went well" is not, because it confirms treatment took place.

What creates exposure

• Review responses that confirm treatment, a visit, a procedure, or an outcome — even in a warm, well-meaning tone. Confirmation is the exposure, regardless of intent.
• Testimonial pages on the practice site that name a condition, procedure, or outcome alongside an identifiable patient, even with the patient's enthusiastic consent — consent processes are easy to get wrong, and the downside if they are is severe.
• Incentivized reviews — offering a discount, a gift, or any other consideration in exchange for a review. This creates a paper trail linking a person to a visit, and separately, it violates Google's own review policies regardless of the compliance question.
• Review-request tools that auto-populate a message with anything tied to a specific appointment type, diagnosis, or visit date. If the request itself contains identifiable clinical context, the tool has already created the exposure before a single review is written.

This is also why this site's own policy is to run no testimonial quotes and no Review or AggregateRating schema anywhere — it removes the temptation to manage this case by case and simply takes the riskiest format off the table entirely.

A workable review-request workflow

The workflow we set up for practices has three characteristics: it's universal, it's generic, and it's disconnected from clinical data. Universal means every patient gets the same request, sent the same way, regardless of what brought them in — no segmenting by procedure type, which itself would require storing and acting on clinical data inside a marketing tool. Generic means the request asks about the experience of visiting the practice, not the outcome of any specific care. Disconnected means the request tool pulls only what it needs to send a message — a name and a contact method — and nothing from the clinical record.

In practice, that looks like a short delay after a visit, a neutral message asking whether the patient would share a review of their experience, and a direct link to the practice's Google Business Profile or preferred review platform. No mention of what the visit was for. No pre-filled draft. No distinction in the request based on visit type.

Safe response patterns, described in prose

I'm deliberately not handing over a block of copy-paste response templates here, because a template used without understanding why it's safe gets edited back into unsafe territory the first time a practice manager wants it to sound "less robotic." The pattern that stays safe is this: thank the reviewer, acknowledge their sentiment in general terms, and — for anything below a strongly positive review — invite them to continue the conversation through a private, practice-controlled channel rather than in the public review itself. Never restate what the review said if what it said included clinical detail; never confirm or deny that the reviewer was a patient; never apologize for a specific outcome, because an apology that references an outcome is itself a confirmation of one.

If a patient volunteers clinical detail in their own public review — describes a diagnosis, names a procedure, quotes a provider — the safest response still says nothing back that confirms or engages with that detail. The patient is free to disclose their own health information; the practice is not free to amplify, confirm, or build on that disclosure in its response.

Training the people who actually answer reviews

The policy only holds if the person typing the response understands why it's written the way it is. I've seen practices with a technically sound written policy get undermined in an afternoon because whoever was covering the front desk that week hadn't been part of writing it and didn't know why "so glad the procedure went well" was off-limits. Whoever responds to reviews — front desk staff, a practice manager, an outside marketing team — needs to know the underlying rule, not just a list of banned phrases, because a rule they understand travels to situations a canned list didn't anticipate. A one-page internal document explaining the PHI-includes-patient-status principle, with two or three worked examples of safe and unsafe responses, does more for actual compliance than a longer, more formal policy nobody reads twice.

I also tell practices to write down who has the authority to respond to reviews at all, and to keep that group small. Every additional person who can post a public response is another person who needs to understand the rule, and the risk scales with the number of people making judgment calls in the moment, not with the number of reviews coming in.

Where this connects to the rest of the site

This policy isn't a standalone rule — it's one piece of the larger trust picture Google evaluates on YMYL sites, which our post on YMYL and E-E-A-T covers in full, and it sits alongside the page-by-page standard in our medical practice website checklist. A practice that gets reviews right and gets its clinical content right is building the same kind of trust from two different directions.

Again — none of this is legal advice, and a practice's compliance officer or counsel should sign off on any policy before it goes live. What we can offer is the marketing side of that policy, built to stay inside the line rather than test it.