Blog

How to launch a new telehealth treatment program without engineering

A launch checklist for a new telehealth program: clinical criteria, the flow, consent, pharmacy and EHR hookups, domain, tracking, soft launch and iteration.

Written for operators, growth leads and product managers at telehealth and DTC health brands adding a new condition or product line

You can launch a new telehealth treatment program without engineering if you treat it as a sequence of decisions rather than a software project. Your clinicians write the eligibility criteria, an operator turns them into an intake flow (from a template or an AI draft), and the pieces that touch other systems (consent, payment, pharmacy, EHR, tracking) are connected through integrations instead of custom code. The work that takes time is clinical and legal review, not building screens.

Below is the checklist for a new condition or product line: what has to exist, who owns each step, and the order to do it in.

What is a telehealth treatment program?

A telehealth treatment program is everything a patient goes through to get one treatment from your brand online. For a new line such as hair loss, HRT or a weight loss medication, it usually includes:

  • A landing page and an ad or email campaign that sends traffic to it.
  • An eligibility quiz that screens out patients the treatment is not right for.
  • A medical intake that collects the history a clinician needs.
  • Consent to treatment and to telehealth, plus your privacy terms.
  • Checkout, often a subscription.
  • A clinician review in your EHR or provider network.
  • Fulfillment through a pharmacy, then follow-ups and refills.

A brand that already runs one program has most of this in place. A new program mostly means new clinical criteria, a new flow and new connections for whatever changes.

What has to exist before launch

The pieces of a DTC telehealth stack in order

Before anyone builds a screen, confirm these are decided. Each one blocks a later step if it is missing.

PieceWho decidesWhy it blocks launch
Clinical protocol and eligibility criteriaYour medical director and cliniciansThe flow is a translation of these rules. Without them you are guessing.
Provider coverageClinical operationsYou can only accept patients where a licensed clinician can treat them.
Pharmacy or fulfillment partnerOperationsDetermines what the intake must collect and where the order goes.
EHR or clinician review toolClinical operationsDetermines where intake data has to land and in what shape.
Consent and terms languageClinical and legal teamsPatients must agree before treatment. Wording needs sign-off.
Pricing and plan structureGrowth and financeCheckout cannot be built until plans and prices are fixed.
Domain and brandMarketingThe flow URL and the tracking setup depend on it.
Marketing claimsMarketing and legalAds and landing copy need support before spend starts.

If you are still choosing an EHR, our comparison of EHRs for DTC telehealth covers what each one expects from intake. If the new line is a peptide or compounded product, the peptide brand playbook walks through the provider network and pharmacy side in more depth.

Step 1: get the clinical criteria in writing

The single biggest source of delay is building a flow before the clinical rules are final. Ask your clinicians for a written document, even a rough one, that answers:

  • Who is eligible. Age range, conditions, measurements (for example BMI for a weight program), states you serve.
  • Who is excluded, and why. Contraindications, medications, pregnancy, prior reactions. Each exclusion becomes a routing rule.
  • What needs a human decision. Answers that should not auto-disqualify but must be flagged for clinician review.
  • What the clinician needs to see. The history, labs, photos or ID they need to make a decision.
  • What to say to ineligible patients. A clear message, a waitlist, or another treatment you offer.

Eligibility is a clinical decision. The operator’s job is to encode it faithfully, not to set it. Keep the document versioned so the flow can be checked against it later.

Step 2: build the flow from a template or an AI draft

With criteria in hand, you need an eligibility quiz, an intake and a checkout that follow them. There are three common ways to get there.

ApproachGood forWatch out for
Start from a templateCommon programs (weight loss, aesthetics) where the structure is well knownYou still have to replace the criteria with your clinicians’ own
Ask an AI agent for a draftNew or unusual programs, or when you want a first version fastThe draft is a starting point. Every rule and every line of copy needs review
Build in a form tool by handSimple screeners with few branchesBranching, consent records and payments often need workarounds or code
Have engineering build itVery custom experiencesEvery later change waits for a sprint

Whichever route you pick, structure the flow the same way:

  1. Goal and context first. Open with what the patient wants, not their medical history.
  2. Hard stops early. Put the questions that most often disqualify near the start, so ineligible patients learn quickly and kindly.
  3. One topic per screen. Short screens are easier to answer on a phone and easier to measure.
  4. Medical history in groups. Medications, conditions, allergies, each as its own short section.
  5. Consent before checkout. The patient acknowledges before paying.
  6. Checkout last. Show the plan, the price and what happens next.

Our guides to patient psychology in intake flows and the GLP-1 intake flow go deeper on question order and copy.

Consent is not a checkbox in the footer. For a new program you usually need consent to treatment, consent to telehealth, and agreement to your privacy terms, each written or approved by your clinical and legal teams. In the flow:

  • Make it a step the patient must complete before continuing.
  • Store a timestamp and the exact version of the text they agreed to, with the intake record.
  • Keep marketing consent separate from treatment consent. A patient can agree to treatment without agreeing to ads or emails.

Step 4: connect payment, pharmacy and the EHR

This is where “without engineering” is won or lost. Map every place intake data has to go and pick an integration for each.

ConnectionWhat it carriesTypical options
PaymentCard, plan, subscriptionA payment processor such as Stripe or Authorize.Net
EHR or clinician reviewIntake answers, consent record, uploadsNative EHR integration, or a webhook into your EHR
Pharmacy or fulfillmentApproved order, shipping detailsUsually triggered from the EHR after a clinician approves
CRM and lifecycle emailContact, program, statusHubSpot, Klaviyo, Braze or similar
SchedulingConsult booking, if the program needs a live visitA booking tool such as Cal.com
ID verificationIdentity check, if required by your protocolA verification provider such as Persona

Two rules keep this clean. First, decide which system owns each piece of data (the EHR owns the clinical record, the CRM owns marketing status) and do not keep two copies that can drift. Second, test every connection with a fake patient end to end before launch, including the ineligible path and a declined card.

Step 5: set up the domain and the tracking

Run the flow on your own domain, or embed it on your site, so patients stay inside your brand.

Tracking is where new programs most often create privacy risk. In 2023 the FTC and HHS sent letters to about 130 hospital systems and telehealth providers warning that tracking technologies such as the Meta pixel and Google Analytics can send sensitive health data to third parties. Brands outside HIPAA are not off the hook either: the FTC says its Health Breach Notification Rule applies to most health apps and similar technologies that HIPAA does not cover.

For a new program, that means:

  • Do not drop third-party ad pixels on intake or checkout screens.
  • Send conversions server-side, with identifiers hashed and health details stripped.
  • Only send data for visitors who consented to marketing.
  • Capture click ids and UTMs on the visit so you can still attribute patients to campaigns.

Our guide to server-side conversion tracking in healthcare covers how this works in practice.

Step 6: review the marketing claims

Ads and landing pages for a new treatment need the same care as the flow. The FTC’s health products compliance guidance says health-related claims need “competent and reliable scientific evidence.” Have your clinical and legal teams sign off on landing copy, ad copy and any outcome language in the flow itself before you spend on traffic.

Step 7: soft launch, measure, iterate

Do not open the program to full ad spend on day one. A soft launch catches the problems that only real patients find.

  1. Internal run. Have staff complete the flow as several personas: eligible, ineligible, edge cases, mobile and desktop.
  2. Clinician check. A clinician reviews test submissions in the EHR and confirms they have what they need.
  3. Small traffic. Send a limited budget or an email to an existing list.
  4. Measure by step. Look at completion and drop-off for each screen, not only the overall conversion rate. A single screen losing patients is usually a wording or order problem.
  5. Fix and test. Change one thing at a time, ideally as an A/B test against the current version.
  6. Scale. Increase spend once the flow, the clinical queue and fulfillment all hold up.

Realistic timeline

How long this takes depends far more on decisions than on building. If clinical criteria, consent language, pharmacy and pricing are settled, the flow itself can be drafted, reviewed and connected quickly. If any of them are still open, that open item sets the pace. Plan the calendar around clinical and legal review, and start those conversations before anything else.

How to do it in PathwAI

PathwAI is an AI-native patient acquisition platform. An agent builds the flow and your team approves it. Here is how the steps above map to it:

  • Draft the flow. Describe the program in plain English to the PathwAI AI agent, including your clinicians’ criteria, and it generates a complete flow: steps, patient-facing copy and routing. The result is a draft; nothing publishes without your team’s explicit approval, and consent wording must be reviewed by your clinical or legal team. No patient data is used in generation prompts.
  • Or start from a template. The templates include a GLP-1 eligibility and intake flow and an aesthetics lead qualifier.
  • Encode the criteria. Routing rules branch on any answer or combination of answers. Eligible patients continue to intake and checkout; ineligible patients get a custom message, a waitlist or another treatment path.
  • Consent as a step. Patients must acknowledge before continuing, and consent is timestamped and stored with the intake data.
  • Payment, booking and ID. Steps can take payments (Stripe, Authorize.Net), book appointments (Cal.com) and verify ID (Persona).
  • Integrations. PathwAI has 34 integrations across payments, CRM, EHR, analytics and ads, including Healthie, CarePortals, HubSpot, Klaviyo, Braze, Segment, Zapier and webhooks.
  • Your domain. Flows run on your own domain or embedded on your website. Share preview links for team review before publishing.
  • Tracking. The Patient Data Platform sends conversions server-side to Meta, Google Ads, TikTok and Microsoft Ads, with identifiers SHA-256 hashed and PHI stripped, only for visitors who consented. It uses first-party cookies and no third-party ad pixels.
  • Measure and iterate. Step-level completion and drop-off show where patients leave, and A/B tests of copy, step order or routing run against a control.

Most teams ship a working first draft within a day or two of their demo call. A BAA is available on the Enterprise plan.

Launch checklist

  • Clinical criteria written, versioned and signed off by clinicians
  • Provider coverage confirmed for every state you will accept
  • Pharmacy or fulfillment partner and order handoff agreed
  • Flow built: eligibility, intake, consent, checkout
  • Every exclusion mapped to a routing rule, checked against the criteria
  • Consent and privacy text approved by clinical and legal teams
  • Payment, EHR, CRM and other integrations tested end to end
  • Ineligible path and declined card tested
  • Flow on your own domain or embedded on your site
  • No third-party ad pixels on intake or checkout; server-side conversions with consent
  • Ad and landing claims reviewed
  • Soft launch run, step-level drop-off reviewed, first fixes shipped

Frequently asked questions

Do I need engineers to launch a new telehealth program?

Not for the flow itself if you use a tool that handles branching, consent, payments and integrations. You may still want technical help for an unusual EHR or pharmacy connection that has no ready integration or webhook.

Who should set the eligibility criteria?

Your clinicians. The operator turns their written criteria into routing rules, and a clinician should check the finished flow against them before launch.

Can I reuse the intake from an existing program?

You can reuse the structure, such as contact details, medication history and checkout. The eligibility questions, exclusions and consent language should be rewritten for the new treatment and reviewed again.

How do I track ad performance without exposing health data?

Avoid third-party pixels on intake screens, send conversions server-side with hashed identifiers and no health details, and only for visitors who consented to marketing.

What usually delays a launch?

Open decisions: clinical criteria that keep changing, consent wording waiting on legal, an undecided pharmacy, or pricing that is not final. Settle those first and the build moves quickly.

Keep reading

Guide Managing patient intake for multiple telehealth brands
Guide How to build a telehealth intake funnel that converts
Best-of Best Formsort alternatives for digital health companies (2026)