We were on a call with a practice manager last month who wanted a new website because the old one "looked dated". Fair enough; it did. But when we asked what the website did for the practice, the answer was nothing. Patients found the phone number on it and called. The front desk answered the same eight questions all day. Balances were paid by mail or at the next visit. New patients filled out a clipboard. The site was a brochure with a phone number, and a new brochure with a new phone number would have changed nothing.
The websites we build and the ones we admire do three operational jobs. They take in new patients, they take money, and they answer the questions that would otherwise be phone calls. Everything else, the photos and the mission statement, is fine but secondary. This article is about the three jobs, what each one needs to work, the rules that apply, and how to tell whether the site is doing them.
Key takeaways
- A website earns its keep through intake, payments and answered questions. Judge every design decision and every vendor against those three jobs.
- Every job needs an integration that writes to the practice management system or EHR. A form that produces a PDF for the front desk to retype has moved the work, not removed it.
- Any form that asks about health is collecting PHI, which means a business associate agreement with whoever receives it and no advertising pixels on that page.
- Measure with a one-week call tally by reason before and after. If the "are you open Friday" calls did not fall, the hours are not findable.
Job one: intake
A new patient who finds the practice online should be able to request or book an appointment, complete registration and consent forms, upload an insurance card and be checked for eligibility before anyone at the practice picks up a phone. That requires:
- Online scheduling connected to the practice management system, or at minimum a structured request form that creates a task rather than an email.
- Digital intake forms that write to the EHR, with the same fields as the paper forms, including the guarantor and the consent to text and email.
- Insurance card capture by photo, feeding an eligibility check.
- A clear statement of which insurance plans are accepted, kept current, because "do you take my insurance" is the number one call.
The revenue cycle payoff is upstream data quality. Eligibility problems, wrong guarantors and missing consents are all cheaper to prevent at intake than to fix as denials. A practice that moves from clipboard to digital intake usually sees its registration-related rejections fall within a quarter, because the patient types their own member ID and the form will not submit without it.
The intake form is also where the consents that make the rest of the workflow legal get collected: consent to text, consent to email statements, acknowledgment of the notice of privacy practices, and the card-on-file authorization if you use payment plans. Put them on the digital form with a checkbox each, and the front desk never has to chase a signature again.
Job two: payments
A patient with a balance should be able to pay it from a text link or from the website in under a minute, without creating an account, and the payment should post to the account automatically. That is a payment processor integrated with the practice management system, a hosted payment page (so card data never touches your server), and a statement design that puts the link and a QR code where people see them.
Patient balances paid within days of the first statement are the difference between a healthy patient AR and a growing pile of small balances that eventually get written off. The website's job is to make paying the easiest thing a patient does that day. Test it yourself: take a statement, open the site on your phone, and time how long it takes to pay. If it is more than a minute or requires a login, the design is costing you money.
Job three: fewer phone calls
Write down the ten questions the front desk answers most. Ours from practices we have surveyed: hours and location, accepted insurance, how to get a refill, how to get records, how to get test results, what to bring to a first visit, parking, whether telehealth is available, how to reach the billing office, and what to do after hours. Every one of those should be answered on the site in plain language, findable in two clicks, and current. A frequently asked questions page that was written in 2021 and mentions a provider who left in 2024 makes things worse, not better.
The measure is simple: count the calls by reason for a week before the site changes and a week after. If the "are you open Friday" calls did not fall, the hours are not findable. Assign the page to someone with a quarterly reminder, because the answers change and the page will not update itself.
The rules that apply
| Rule | What it means for the site |
|---|---|
| HIPAA Privacy and Security Rules | Any form that collects health information must be transmitted and stored securely, and the form vendor must sign a business associate agreement. A generic contact form that asks "reason for visit" is collecting PHI. |
| Tracking technologies | OCR's guidance on web tracking, first issued in December 2022 and revised in March 2024, treats analytics and advertising pixels on authenticated pages such as portals and scheduling as a potential disclosure of PHI; a federal court narrowed the guidance for unauthenticated pages in June 2024. Keep third-party tracking off portal, scheduling and intake pages, and review the rest. |
| Accessibility | The ADA applies to public accommodations including medical offices, and the widely used standard for websites is WCAG 2.1 level AA: text alternatives, keyboard navigation, sufficient color contrast, readable forms. Health systems have been sued over inaccessible sites; small practices are not exempt. |
| Notice of Privacy Practices | Must be posted on the site if the practice has one. |
| Payment card security | Use a hosted payment page from a PCI-compliant processor. Never store card numbers in the practice's own systems. |
| Price transparency for self-pay | Good faith estimates for uninsured and self-pay patients under the No Surprises Act; the site should explain how to request one. |
Measuring whether the site is doing its jobs
A website project without a before-and-after measurement is a design project. These are the numbers we ask practices to capture for the month before launch and the third month after.
| Job | Measure | Where it comes from |
|---|---|---|
| Intake | Share of new patients who completed registration online before arrival | Practice management system, new patient report |
| Intake | Registration-related clearinghouse rejections per 100 claims | Clearinghouse rejection report |
| Payments | Share of patient payments made online or by text link | Payment processor report by channel |
| Payments | Median days from first statement to payment | Patient AR report |
| Fewer calls | Front desk calls per day by reason, one-week tally | A tally sheet at the desk; no software needed |
| All three | Front desk overtime hours | Payroll |
In a two-location pediatric practice we worked with, the online registration share went from nothing to a little over half of new patients in the first quarter after launch, and the calls about hours and insurance fell by roughly a third on the tally. The payment channel shift took longer, because it depended on statements being redesigned to carry the link. Results vary with the patient population and how hard the front desk pushes the new path at the phone, and we would treat any vendor's promised numbers with the same caution.
What we think practices should skip
A patient app of their own. A chatbot that cannot actually book or answer billing questions. Stock photography of models in white coats. A blog that will be updated twice and abandoned. Any feature the vendor cannot connect to the practice management system, because a feature that creates work for the front desk to re-enter is a cost, not a tool.
Questions we hear
Our EHR vendor offers a patient portal. Isn't that enough?
The portal is for established patients who have logged in. The website is for everyone else, including the new patient who has never heard of your portal. They need to work together, and the website should hand off to the portal at the right moment, but one does not replace the other.
Do we need to take the analytics off the whole site?
Not necessarily. The pages that matter are the ones where a visitor is identifiable and health information is implied: the portal, scheduling, intake and anything behind a login. Keep general analytics on the home page and the hours page if you want them, but know what each script sends and to whom, and write it down in the risk analysis.
How much of this can a small practice afford?
The three jobs do not require an expensive site. They require the right integrations and a clear structure. We build practice websites around exactly these three jobs as part of healthcare website development; rates are on the pricing page. If you are evaluating vendors, judge them on the three jobs and the rules table above, not on the design mockup.
What to do this month
- Tally front desk calls by reason for one week. This is your requirements document.
- Check every form on the current site: what does it collect, where does it go, and is there a BAA with whoever receives it?
- List every third-party script on the scheduling, intake and portal pages and remove the ones that are not essential.
- Run a free accessibility checker on the home page and the scheduling page and read the top five findings.
- Test paying a balance from your own statement as a patient would. Time it.
- Confirm the insurance list and provider list on the site match reality, and assign an owner for keeping them that way.
