Rules
Part of Patient Acquisition: The Version That Survives Contact With Reality
Patient Acquisition Programs: From Telehealth Prep to Referral Follow-Up
Nine named patient acquisition programs, from telehealth preparation to referral follow-up, detailing the types of evidence each program produces.
What to take away
- Nine named programs cover care entry from first search to referral follow-up, and each one produces a countable result.
- Tools do the plumbingBright Local for listings, SOCi for reviews, Klara for intake, ReferralMD for referral tracking.
- Every program needs a named owner, a review date, and a defined failure case before it goes live.
- Community data from CDC PLACES frames questions; it never identifies a patient or proves demand.
- Federal telehealth and privacy guidance sets the floor, not the local rule. Confirm details with your state board and counsel.
Patient acquisition programs work when each one owns a single care-entry problem and reports a single number. The nine below are named tools and named designs, not client results or promised returns.
The nine programs
| Program | What it is | Evidence it produces |
|---|---|---|
| Telehealth prep kit | Instructions built from Telehealth.HHS.gov guidance | Completed visits, support tickets per visit |
| CDC PLACES service review | County and tract estimates read against service records | A documented decision to add, keep or drop a service |
| Local listings control | Google Business Profile plus Bright Local or Yext | Calls and direction requests from the profile |
| Review response desk | SOCi or Birdeye routing reviews to a named responder | Median response time, rating trend |
| Digital intake | Klara, Phreesia or a form built on your EHR | Forms completed before arrival |
| Referral tracking | ReferralMD or a shared referral log | Referrals accepted complete, first try |
| Cost question path | A scripted route for price questions | Requests resolved without a callback |
| Capacity throttle | A spend cap tied to open slots | Wait time stays inside the limit you set |
| Correction desk | A log for wrong service facts | Time from report to verified fix |
Example: prepare patients for telehealth
Telehealth.HHS.gov publishes patient preparation guidance covering setup, privacy, connection failure and what a patient should have on hand. Turn those categories into tested instructions your own clinicians and accessibility reviewers sign off on.
Send them through the route the patient already approved, state the fallback, and test the first connection with synthetic data. Count completed visits and support burden, not link clicks. Teams building this still hit common patient acquisition questions about consent and capacity.
Example: read place data without stereotyping
CDC explains how to use the PLACES Data Portal to pull modeled estimates at county, place, census tract and ZIP Code Tabulation Area levels. Those estimates describe populations, not people. They cannot diagnose a patient or prove demand for a service.
Pair them with service records, referral evidence, listening and an accessibility review. Never target an individual from a community estimate, and never treat a postal code as a condition. State the geography, release, measure and method whenever you cite one.
Build the test case
The NIST Privacy Framework starting guide gives a voluntary process for finding and managing privacy risk. Use it to name a data owner and a response owner for each program. It is not legal clearance.
The W3C guidance on information and relationships holds that visual structure must also exist in code. Check each program's output against it, then test the real page with the users and technology in scope.
- Name the one care-entry problem the program solves
- Name the service owner and the eligible population
- Test with representative users and synthetic data
- Record the outcome window and the failure case
Keep the evidence beside the decision
Write down the audience, source data, identity rule, business constraint, decision and outcome window before you copy a program anywhere. Swap in local inputs. Run one failure case on purpose.
Record rejected options too. The constraint that killed an option may change, and the note is what lets you reopen it without starting over. Use the same definitions in the interface, the export, the meeting note and the correction log.
Common questions
Which program should a new practice start with?
Verified service facts, a working contact path, capacity control and a correction process come before any promotion. Those four keep the phone answered and the schedule honest while you test everything else.
Can a team copy these programs exactly?
No. Service scope, patient population, state law, systems, staffing and accessibility all change the design. Copy the structure and the measurement, then rebuild the content locally.
Do these programs prove financial return?
No. Return needs full cost and reconciled outcomes under your own conditions. Track cost per completed visit in your own ledger rather than borrowing a benchmark from a vendor page.
Who signs off before launch?
Your privacy officer for anything touching patient data, your compliance lead for marketing claims, and qualified healthcare counsel for state and provincial rules. Name them in the plan, not after a complaint.
