A Patient Acquisition Checklist Built Around Data and Privacy Risk

Use this as a release decision tree, not a scorecard. At each checkpoint, record the evidence artifact, accountable owner, review date, and decision. Follow the patient-facing path first, then test capacity, data, consent, vendors, and live behavior. If any mandatory control fails, stop release even when the remaining checks pass.

If the patient-facing facts or booking route cannot be verified

Then hold release until a current source verifies the entity, location, clinician, service, payer wording, hours, language, and accessibility. Confirm the fallback route for periods when online booking is unavailable. Patients need to understand the offer and reach care before the data path can be assessed.

Save a dated screenshot of the live page beside its source document, then make a synthetic booking and retain its timestamp. The image proves what content appeared, not that the appointment reached the schedule. The patient acquisition path starts with these patient-facing checks before moving inward to systems, records, and vendors.

• Rule of thumb: Verify what patients see and how they can book before moving on.

If campaign demand may exceed available capacity

Then defer promotion until service leadership confirms available slots and approves a written stop rule. Match each campaign to current capacity, retain a current schedule export as evidence, and review the capacity position monthly. Base promotion on slots actually available, not on an untested assumption about future capacity.

Reconcile the count of patients who arrived monthly. Contact and no-show rates may change before privacy complaints do; the patient outreach metrics can expose funnel drop-off and reveal when a booking has not reached the schedule. Use those measures as an early signal of a broken path.

• Rule of thumb: Do not promote capacity that the schedule cannot support.

If the purpose or route of a data field is unclear

Then map each captured field to its destination and retention period before choosing or configuring a tool. Record the process purpose, affected people, fields used, decision supported, and residual risk after controls. Treat the NIST Privacy Framework as a voluntary organizer, not a certification or legal conclusion.

Minimum necessary applies to uses and disclosures and can also guide collection. Ask whether each field is needed to schedule, treat, or bill; remove a field used only for a marketing segment or obtain written consent. Review the tested field-and-destination map whenever data changes, alongside healthcare marketing compliance.

• Rule of thumb: Collect only fields that serve the stated process purpose.

If a vendor or system can handle patient identifiers

If a patient identifier can be attached to a phone number, treat call analytics, chat widgets, and CRM synchronization as systems that handle electronic PHI.

The HIPAA Privacy Rule permits PHI use and disclosure for treatment, payment, and health care operations; those permissions do not automatically cover marketing. A covered entity generally must obtain an individual's written HIPAA authorization before using or disclosing PHI for marketing, unless a defined exception applies. Whether HIPAA applies also depends on whether the information is PHI and who uses or discloses it. Channel-specific laws may still govern outreach even when HIPAA authorization is not required.

Once electronic PHI is held by a system, the HIPAA Security Rule calls for administrative, physical, and technical safeguards. The FTC treats health data used in commercial analytics and advertising as sensitive; a campaign pixel firing on a page about a named condition is a routine failure. The FTC Act also covers deceptive health claims and consumer data.

Document vendor subprocessors, access, safeguards, incidents, and exit. Compare actual work with the business associate agreement; signing alone does not establish scope or live configuration. In the working system, verify transfers, retention, deletion, support, access, and safeguards using a configuration export plus a tested data flow.

• Rule of thumb: Check the live system and data path, not just the signed agreement.

If the basis for email or text outreach is unsettled

Then hold the message until its consent basis is documented and tested. Retain a timestamped opt-in record and complete an unsubscribe test; marketing owns this evidence, with an annual review.

U.S. marketing texts may be subject to the Telephone Consumer Protection Act (TCPA) and Federal Communications Commission (FCC) rules; texts within the applicable telemarketing rules generally require prior express written consent, and recipients must be able to revoke it. Commercial email is subject to the CAN-SPAM Act, including an opt-out mechanism and honoring opt-out requests. These channel rules are separate from HIPAA authorization: document which requirements apply to the message, retain the supporting consent record, and test the opt-out route. The patient texting consent rules provide a related review point.

Before release, identify the escalation route for privacy complaints and clinical corrections, and name who decides each issue. Consent evidence does not replace clinical review, and clinical accuracy does not establish the privacy basis. Keep those decisions separate in the release record, with a responsible owner assigned to each.

• Rule of thumb: Verify the consent basis and the message content separately.

If the evidence does not prove the live flow

Then require evidence from the live process, not just a signed contract, checked box, or static page. For every control, name an owner, set a review date, and record pass, fail, not applicable, or accepted exception; explain each not-applicable decision.

Write an actual next review date beside every decision, not only a review cadence. A checkbox without proof cannot protect the release. For access, retain a timestamped synthetic booking; for data fields, a tested field-to-destination map; for outcomes, a reconciled count of patients who arrived.

On a Tuesday, a clinic ran a synthetic end-to-end test: the widget confirmed a 3 p.m. slot and the schedule updated, but the confirmation email passed through the vendor marketing list before a patient record existed. The clinic stopped release. This was a routing error, not a contract gap, a concern reflected in common patient acquisition questions.

• Rule of thumb: Evidence must show what the live process actually did.

If a mandatory control fails

Then stop release if privacy, security, access, data quality, or accessibility fails as a mandatory condition. Passing other checks or achieving a strong total cannot offset that failure. Record the evidence location, reviewer, decision date, and next review date; retain rejected options because the original constraint may later change.

Name one release owner, while specialists remain accountable for clinical, legal, privacy, security, access, data, and finance decisions. An item without supporting proof is not a pass. Record an accepted exception as an explicit decision rather than hiding it in an overall score.

• Rule of thumb: One failed mandatory condition is enough to stop release.

If the service, channel, vendor, or rules change

Then rerun the relevant checklist after any change to a service line, claim, capacity, channel, data, vendor, subprocessor, workflow, or regulation. Bring review forward if complaints, contact rates, or access logs suggest a control failed. Set the next review date and identify the event that would trigger another early review.

Revisit the evidence and decision affected by the change, then repeat any live configuration or data-flow test that no longer matches the current arrangement. The medical practice marketing checklist addresses the campaign layer above this data gate and can be read alongside it.

• Rule of thumb: Recheck after a material change, or sooner when a control shows signs of failure.