Telehealth Visit Pipeline

A telehealth visit has more moving parts than an in-person one, and almost all of them sit outside the clinical encounter. The patient has to be booked into a slot that is actually licensed and staffed for remote care. They have to sign a telehealth-specific consent that an in-person patient never needs. They have to receive a join link that works on the device they will actually use. They have to be in a private place at the right minute. And when the visit ends there is usually a prescription, a referral, or a follow-up booking that has to reach them without a hallway handoff to make it happen.

When any one of those steps is manual, the visit degrades into a support call. The provider sits in an empty virtual room while a coordinator calls the patient to walk them through a link they never opened. Ten minutes evaporate, the session runs late, and the rest of the remote block slides with it. Multiply that across a day of virtual visits and the practice is paying clinical time to do technical support. The money leak is visible in the schedule: remote no-show rates in practices that deliver links by hand run noticeably worse than their in-person rates, and every no-show is a slot that could not be backfilled because nobody knew it was going to be empty until the start time passed.

The second leak is on the back end. Remote visits generate follow-up actions that nobody is physically present to catch. An in-person patient walks past the front desk and gets booked for the next visit; a remote patient hangs up and disappears. Continuity depends on someone remembering, and in a busy week that memory is the weakest link in the practice. What this build does is make the entire non-clinical wrapper around a remote visit automatic: consent captured before the link is issued, the link delivered on a schedule tuned to how people actually behave, a technical readiness check that surfaces problems the day before rather than at the start time, and a post-visit sequence that closes the loop whether or not anyone remembers to.

Pipeline and stages

One pipeline, Telehealth Visits, with one opportunity per scheduled remote visit.

• Requested: patient asked for a remote visit; eligibility not yet confirmed.
• Eligibility Confirmed: state of residence, visit type, and payer all support remote care.
• Scheduled: slot held on a telehealth calendar.
• Consent Pending: telehealth consent form sent, not yet signed.
• Consent Signed: consent captured and timestamped.
• Tech Check Sent: device and connection readiness prompt delivered.
• Ready to Join: consent signed, tech check passed, link issued.
• In Session: visit started.
• Completed: visit finished, post-visit sequence running.
• No-Show: patient did not join within the grace window.
• Failed to Connect: patient attempted to join but could not; distinct from a no-show because it needs a different follow-up.
• Converted to In-Person: the visit was better served in the office; closed with a reason.
• Canceled: closed with a reason captured.

Calendars

• Telehealth Visit: the primary calendar, one per provider or one shared with provider routing. Buffered on both sides so a session that runs long does not cascade. Availability restricted to hours the provider is licensed and credentialed for remote care.
• Telehealth New Patient: a longer slot type, separated so new remote patients get the extra time that consent, history, and orientation actually take.
• Tech Support Window: short internal slots a coordinator can offer a patient who fails the readiness check, so troubleshooting happens the day before rather than during clinical time.
• Post-Visit Follow-Up: the calendar the post-visit sequence offers, so continuity booking does not depend on anyone remembering.

Custom fields

• telehealth_eligible, patient_state_of_residence, provider_licensed_states, visit_type, telehealth_modality (video, audio-only, asynchronous)
• telehealth_consent_signed, telehealth_consent_signed_at, telehealth_consent_version, consent_signed_by (patient, parent, legal guardian, authorized representative)
• join_link_issued_at, join_link_opened_at, device_type (phone, tablet, desktop), tech_check_status (not sent, sent, passed, failed), tech_check_completed_at
• patient_location_at_visit (required in many jurisdictions; collected as a state, not an address), emergency_contact_on_file, local_emergency_number_confirmed
• visit_started_at, visit_ended_at, visit_outcome, follow_up_required, follow_up_interval, follow_up_booked
• copay_due, payment_collected, payment_collected_at
• consent_sms, consent_email, consent_captured_at, consent_revoked_at, preferred_contact_channel
• join_reminder_count, no_show_count_lifetime

Tags

• Readiness: consent-pending, consent-signed, tech-check-passed, tech-check-failed, ready-to-join
• Outcome: visit-completed, telehealth-no-show, failed-to-connect, converted-in-person
• Routing: new-remote-patient, established-remote-patient, audio-only-visit, out-of-state-flag
• Follow-up: follow-up-due, follow-up-booked, repeat-no-show
• Consent: sms-opt-out, email-opt-out, all-outreach-paused

Forms

• Telehealth Eligibility Screener: the front door. Asks state of residence, whether the patient is established, the general nature of the visit in non-clinical terms, and device availability. Routes to booking or to an in-person path.
• Telehealth Informed Consent: the consent instrument specific to remote care: the nature and limits of a virtual visit, what happens if the connection fails, privacy considerations on the patient's own network, how to reach emergency services, and the right to withdraw and be seen in person instead. Captures typed name, date, relationship to patient, and version of the consent text shown. Writes telehealth_consent_signed_at and telehealth_consent_version.
• Device and Connection Readiness Check: short form confirming device type, camera and microphone access, and a usable connection, plus a one-tap test of the join flow. Writes tech_check_status and device_type.
• Pre-Visit Location and Contact Confirmation: confirms the state the patient will be physically in during the visit and an emergency contact. Short, and sent close to the visit because the answer can change.
• Post-Visit Experience Check: two or three questions on whether the technology worked and whether the patient would choose remote again. Deliberately separate from any clinical follow-up.

BO's role and guardrails

BO runs the logistics and the technology hand-holding. That is a genuinely useful job here, because most pre-visit friction is technical rather than clinical.

• BO confirms bookings, re-sends join links, walks a patient through enabling a camera or switching browsers, offers the Tech Support Window, and handles rescheduling.
• BO never gives clinical advice, triages symptoms, interprets anything the patient reports, or answers questions about medications or results.
• BO never discusses the reason for the visit, and never restates a visit type beyond neutral scheduling language such as "your appointment with Dr. [name]".
• BO escalates immediately on any message describing a symptom, worsening condition, medication problem, or anything suggesting an emergency, and the escalation path for urgency-signaling language is a live human plus an instruction to call emergency services, never a wait step.
• BO does not accept a verbal or text consent in place of the consent form. If a patient replies "yes I consent" by SMS, BO thanks them and re-sends the form, because the signed record with its version stamp is the artifact that matters.
• BO stops on all-outreach-paused and honors any opt-out phrasing.

Numbers and channels

• A dedicated local number for telehealth operational messaging, A2P 10DLC registered under the practice's entity, separate from marketing. Join reminders are time-critical, so deliverability on this number matters more than on almost any other build.
• Email from an authenticated practice subdomain for consent and link delivery, with subject lines that say only that an appointment is coming up.
• The video platform itself, which must be covered by a business associate agreement and configured for one-time or short-lived join links rather than a permanent room URL that could be forwarded or reused.
• Inbound voice routing to a coordinator who can answer during remote blocks, so a patient who cannot get in has a human to call.
• Internal notification channel for the "patient has not joined" alert, which is the single highest-value notification in this build.

1. A patient lands on the telehealth booking page and completes the Telehealth Eligibility Screener. They give their state of residence, say whether they have been seen before, and confirm they have a device with a camera.
2. The screener evaluates eligibility. Their state is in provider_licensed_states and the visit type is one the practice handles remotely, so telehealth_eligible is set true and the booking calendar is shown. An ineligible answer routes to the in-person booking page instead, with a plain explanation and no dead end.
3. They pick a slot on Telehealth New Patient because the screener flagged them as new. An opportunity is created in Telehealth Visits at Scheduled, tagged new-remote-patient, and consent fields are captured from the booking form.
4. Within five minutes the booking confirmation goes out by text and email. It names the practice, the provider, the date and time with the time zone spelled out, and says that two short forms need completing before the visit. No join link yet. The link is issued only after consent, so a signed consent is a hard gate rather than a hope.
5. The stage moves to Consent Pending, the consent-pending tag lands, and the Telehealth Informed Consent form is sent. The patient reads what a remote visit can and cannot do, what happens if the connection drops, how to reach emergency services from where they are, and that they may ask to be seen in person instead.
6. They sign. telehealth_consent_signed, telehealth_consent_signed_at, telehealth_consent_version, and consent_signed_by are written. The version stamp matters: if the practice revises its consent text, the record shows which text this patient actually agreed to. Stage moves to Consent Signed.
7. Two days before the visit the Device and Connection Readiness Check goes out. The patient taps through a test join, confirms camera and microphone access, and the form writes device_type and tech_check_status. Stage moves to Tech Check Sent, then to Ready to Join on a pass.
8. The check fails: camera permission is blocked on their phone browser. tech_check_status is set to failed and tech-check-failed is applied. BO picks it up conversationally, identifies the browser, walks them through enabling the permission, and offers a Tech Support Window slot if that does not resolve it. This happens two days out, in daylight, with a coordinator available, not at the appointment minute.
9. The day before, the Pre-Visit Location and Contact Confirmation form asks which state the patient will physically be in during the visit and confirms an emergency contact. An out-of-state answer applies out-of-state-flag and alerts the coordinator, because licensure follows the patient's location, not their mailing address.
10. The join link is issued and delivered on a cascade: a reminder the evening before with the link, one two hours before, and one fifteen minutes before. join_link_issued_at is stamped, and join_link_opened_at is captured the moment the patient taps it. The single most useful signal in the build, because it tells you whether a patient is on their way or has gone missing.
11. At the start time the provider opens the session and visit_started_at is stamped. Stage moves to In Session. If the link has not been opened five minutes past the start time, the coordinator gets an alert with a record link, and the patient gets one short text with a direct link and the practice phone number.
12. The visit happens. Clinical documentation lives in the EHR; the platform records only non-clinical facts. That the visit occurred, when it started and ended, and the operational outcome.
13. The provider or coordinator closes the visit, writing visit_ended_at, visit_outcome, follow_up_required, and follow_up_interval. Stage moves to Completed. If a copay is due and not yet collected, a payment request goes out through the connected processor.
14. The post-visit sequence runs: a thank-you with a link to the visit summary in the portal rather than in the message body, a follow-up booking link if follow_up_required is yes, and two days later the Post-Visit Experience Check asking only whether the technology worked. The booking link keeps offering until follow_up_booked is true or the window closes, so continuity is enforced by the workflow rather than by anyone's memory.

Seven workflows. Every one checks consent and suppression state before its first send, and every one exits on cancellation or human takeover. Time references are relative to the scheduled visit start, in the patient's time zone.

1. Eligibility Screen and Booking Routing

Trigger: Telehealth Eligibility Screener submitted.

Conditions and branches:

• patient_state_of_residence is in provider_licensed_states and the visit type is remote-appropriate: set telehealth_eligible true, show the telehealth booking calendar.
• State not covered: route to the in-person booking page with the explanation "We're not able to see patients remotely in [state] right now, but we can see you in the office: here are available times." Tag out-of-state-flag and create a task for the coordinator, because this is useful demand data.
• Visit type not remote-appropriate: route to in-person booking with neutral copy. Do not name a clinical reason in the message.
• No camera-capable device: branch to the audio-only path if the practice offers it and the visit type permits, tagging audio-only-visit; otherwise route to in-person.
• New versus established: tag new-remote-patient or established-remote-patient, which selects the calendar and slot length.

Actions in order:

1. Write telehealth_eligible, patient_state_of_residence, visit_type, telehealth_modality, and the routing tag.
2. Create the opportunity in Telehealth Visits at Requested, then at Eligibility Confirmed on a pass.
3. Redirect to the matching booking calendar.
4. Wait 1 hour. If no booking exists, SMS: "Hi [first name], you started booking a virtual visit with [practice name] but didn't finish. Your spot isn't held yet. Pick a time here: [booking link]."
5. Wait 1 day. One email reminder on the same pattern, then stop.

Stop and exit: appointment booked, patient opts out, or the record is closed. Maximum two abandonment nudges. This is not a sales sequence.

2. Booking Confirmation and Consent Gate

Trigger: telehealth appointment booked on any telehealth calendar.

Conditions and branches: branch on telehealth_consent_signed. Already signed and the consent version is current: skip to workflow 3. Signed against an older telehealth_consent_version: re-send the current version, because a signature against superseded text is not a signature against the text you are now relying on.

Actions in order:

1. Move stage to Scheduled. Wait 5 minutes.
2. SMS: "Hi [first name], your virtual visit with [provider name] at [practice name] is confirmed for [date] at [time] [time zone]. Two quick forms to complete first. Start here: [consent form link]. Reply STOP to opt out."
3. Email in parallel. Subject: "Your virtual visit is confirmed". Body carries the date, time with time zone, provider name, and the consent link. No visit reason.
4. Move stage to Consent Pending, add tag consent-pending. Explicitly do not issue a join link at this stage.
5. Wait 1 day. If unsigned, SMS: "Hi [first name], we still need your consent form before your [date] visit. It takes a minute: [link]."
6. Wait 2 days. If unsigned, email reminder plus a staff task if the visit is inside 72 hours.
7. Wait until 24 hours before the visit. If still unsigned, create an urgent coordinator task, "Call to complete telehealth consent or convert to in-person", and notify the internal channel. No link is issued.

Stop and exit: consent signed with the current version, appointment canceled, or the visit is converted to in-person. The gate is hard: no signed consent, no link.

3. Device and Connection Readiness Check

Trigger: stage moves to Consent Signed, or a scheduled check at 48 hours before the visit, whichever comes later.

Conditions and branches: branch on whether the patient has a passed tech check on a previous visit within the practice's reuse window. If so, send the short confirmation variant instead of the full check. Branch on telehealth_modality: audio-only visits get a phone readiness confirmation rather than a camera test.

Actions in order:

1. Move stage to Tech Check Sent. SMS: "Hi [first name], let's make sure your device is ready for [date]. This 60-second check saves headaches on the day: [tech check link]."
2. On submission, write device_type, tech_check_status, and tech_check_completed_at.
3. Pass branch: tag tech-check-passed, move stage to Ready to Join, and release to workflow 4.
4. Fail branch: tag tech-check-failed, hand to BO for conversational troubleshooting, and offer a Tech Support Window slot: "No problem. This is usually a two-minute fix. Want to grab a quick support slot before your visit? [booking link] Or reply here and I'll walk you through it."
5. Wait 4 hours after a fail. If tech_check_status is still failed, notify the coordinator with a record link.
6. No response branch: wait 1 day, send one reminder. At 24 hours before the visit with the check still unsent or unanswered, issue the link anyway but tag the record so the coordinator knows to watch it closely at the start time.

Stop and exit: check passed, coordinator resolves it manually, or visit canceled.

4. Pre-Visit Confirmation and Join Link Cascade

Trigger: 24 hours before the scheduled start, for records at Ready to Join or Consent Signed.

Conditions and branches:

• If consent_sms is false, run the email-only variant and create a coordinator task to confirm the link was received. This is the fallback branch that must exist explicitly.
• If the location confirmation returns a state outside provider_licensed_states, suppress link delivery, tag out-of-state-flag, and create an urgent coordinator task. The visit may not be able to proceed as scheduled, and that decision belongs to a human.
• If telehealth_modality is audio-only, the cascade delivers a dial-in rather than a video link.

Actions in order:

1. At 24 hours: send the Pre-Visit Location and Contact Confirmation form. "Hi [first name], one last thing before tomorrow. Confirm where you'll be joining from and who we should contact in an emergency: [form link]."
2. At 12 hours (evening before): issue the join link and stamp join_link_issued_at. SMS: "Hi [first name], your visit with [provider name] is tomorrow at [time] [time zone]. Join here at your appointment time: [join link]. Find a quiet, private spot and join a few minutes early."
3. At 2 hours: SMS reminder with the link. "Your visit with [provider name] is at [time] [time zone] today. Join link: [join link]"
4. At 15 minutes: SMS. "Starting in 15 minutes. You can join now: [join link]. Trouble getting in? Call [number]."
5. Capture join_link_opened_at on first open. Increment join_reminder_count at each send.
6. At 2 hours, if join_link_opened_at is empty, add the record to the coordinator's watch list for the day. This is the proactive save.

Stop and exit: visit_started_at stamped, cancellation, or opt-out mid-cascade (which switches to the email-only branch rather than going silent).

5. No-Join Alert and Grace Window

Trigger: scheduled start time reached with visit_started_at empty.

Conditions and branches: branch on join_link_opened_at. Opened but not connected suggests a technical failure and routes to Failed to Connect. Never opened suggests the patient is absent and routes toward No-Show. The distinction drives everything downstream.

Actions in order:

1. At start time plus 3 minutes: notify the coordinator on the internal channel with a record link and the join_link_opened_at value. No patient detail in the notification body.
2. At plus 5 minutes: SMS to the patient. "[Provider name] is waiting for you. Join here: [join link]. Having trouble? Call [number] now and we'll help."
3. At plus 7 minutes: trigger an outbound call task for the coordinator. A phone call at this point saves more visits than another text.
4. At plus 10 minutes: if join_link_opened_at is populated, move stage to Failed to Connect, tag failed-to-connect, and create a task to reschedule plus a technical note. Otherwise continue.
5. At the end of the practice's grace window: move stage to No-Show, tag telehealth-no-show, increment no_show_count_lifetime, and release the slot on the calendar.
6. If no_show_count_lifetime crosses the practice threshold, tag repeat-no-show and create a task to review whether this patient should be seen in person instead. Do not send an automated message about the pattern; that is a conversation.

Stop and exit: visit starts, or the record reaches a closed stage. Never send more than one patient message within the grace window. A patient dealing with a broken connection does not need a second text.

6. Post-Visit Follow-Up and Continuity

Trigger: stage moves to Completed, or visit_ended_at is stamped.

Conditions and branches:

• follow_up_required true: run the continuity branch and offer the Post-Visit Follow-Up calendar, with the offer timed to follow_up_interval.
• copay_due greater than zero and payment_collected false: run the payment branch through the connected processor.
• Visit outcome recorded as requiring in-person assessment: suppress the standard sequence and create a coordinator task instead. That booking is a phone call.

Actions in order:

1. Wait 30 minutes, so the message does not arrive before the provider has finished documenting.
2. SMS: "Thanks for joining today, [first name]. Your visit summary and any instructions are in your portal: [portal link]. Questions about what was discussed? Call [number]." The summary lives behind authentication; nothing clinical in the message.
3. Payment branch: send the payment request with a secure link. No amount in the SMS body. Stamp payment_collected_at on receipt.
4. Continuity branch: wait until follow_up_interval minus 14 days, then send "Hi [first name], [provider name] asked us to check in around now. Here are available times: [booking link]." Tag follow-up-due.
5. Wait 5 days. If follow_up_booked is false, one email reminder. Wait 7 more days, one final SMS, then stop and create a coordinator task.
6. At 2 days post-visit: send the Post-Visit Experience Check. "Quick one, [first name]: did the video and audio work well for you? Two questions: [form link]" Keep it strictly about the technology.

Stop and exit: follow-up booked, patient opts out, or the continuity window closes. Maximum three continuity touches.

7. Consent Revocation and Messaging Suppression

Trigger: opt-out keyword or opt-out intent on SMS; email unsubscribe; withdrawal submitted on the consent form; or a staff member setting consent_revoked_at.

Conditions and branches: this build has two distinct revocations and they must not be collapsed into one.

• Messaging consent withdrawn: suppress that channel, keep the visit, switch to the surviving channel, and create a coordinator task if no channel remains and a visit is scheduled.
• Telehealth consent withdrawn: this is a clinical-pathway decision, not a messaging one. Set telehealth_consent_signed false, suppress all join link delivery immediately, move the stage toward Converted to In-Person, and create an urgent coordinator task to call and rebook.

Actions in order:

1. Write the relevant consent field false and stamp consent_revoked_at with the exact time and the channel it arrived on.
2. Apply sms-opt-out, email-opt-out, or all-outreach-paused.
3. Remove the contact from every active sequence, including steps already queued inside a wait. Verify specifically that the join link cascade is canceled, since it is time-based and will otherwise fire.
4. Send one confirmation on the revoked channel where permitted, then nothing further on it: "You've been unsubscribed from texts from [practice name]. For anything you need, call [number]."
5. Create a record note stating which channels remain and whether a scheduled visit is affected, so the next person to open the record sees it immediately.
6. Telehealth-consent branch only: notify the provider as well as the coordinator, because a scheduled slot now needs a different plan.

Stop and exit: runs once per revocation. Re-consent requires a fresh affirmative submission against the current consent version. No workflow re-enables a consent field on its own.

Before launch, test the consent gate by trying to issue a link without a signature, test the no-join alert with a deliberately missed test appointment, test an opt-out fired between the 12-hour and 2-hour reminders, and test an out-of-state answer on the location form. Those four are where this build fails in practice.

The non-clinical wrapper around a remote visit stops consuming clinical time. Consent is signed before a link exists, device problems surface two days out rather than at the start minute, and the provider opens a session where the patient is already waiting. The remote block runs on time, which means the practice can schedule it as densely as an in-person block instead of padding it for chaos.

Consent becomes a record rather than an assumption. Every remote visit carries a signed telehealth consent with a timestamp, the signer's relationship to the patient, and the version of the consent text they actually read. When the practice updates that text, the history stays intact rather than being retroactively overwritten.

No-shows become visible before they happen. join_link_opened_at turns a silent empty room into an early signal: a patient who has not opened the link two hours out is a patient to call, and a slot you can still do something about. Equally important, the build distinguishes a no-show from a failed connection, because one needs a different conversation than the other and lumping them together hides a technology problem inside an attendance statistic.

Continuity stops depending on the hallway. A remote patient who needs to be seen again gets a booking link on a schedule, and the pipeline shows who has not taken it.

Metrics to watch

• Share of visits reaching Ready to Join before the appointment time: the readiness headline.
• Consent completion rate, and hours from booking to signature: a slow signature usually means the form is too long or the first message is unclear.
• Tech check completion and pass rate, segmented by device_type. A device type with a high failure rate is a copy problem you can fix.
• Join link open rate at each reminder, which tells you which reminder is actually doing the work and lets you cut the ones that are not.
• Telehealth no-show rate versus in-person no-show rate: the honest comparison, and the number this build exists to close.
• Failed-to-connect rate, tracked separately. If it is not falling, the problem is the video platform or the instructions, not the patients.
• Average minutes from scheduled start to visit_started_at: the direct measure of clinical time lost to logistics.
• Follow-up booking rate among visits with follow_up_required true, and days to booking.
• Converted-to-in-person rate, which validates whether the eligibility screener is set correctly. A high rate means the screener is letting through visits that were never suited to remote care.

Operational prerequisites

• Confirmed licensure and credentialing for every provider who will appear on a telehealth calendar, and a written list of the states each is licensed in. provider_licensed_states drives the eligibility gate, and a wrong value there is the most consequential error in this build.
• A decision about which visit types the practice will handle remotely, and which it will not. The screener enforces that decision; it cannot make it.
• Approved telehealth consent text, versioned, with a named owner. Give it a version identifier from day one, because you will revise it and you will need to know who signed what.
• A grace window policy: how many minutes past the start time before a visit is marked a no-show, and who places the call in between.
• A named coordinator available during every remote block. This build reduces the support load substantially but does not eliminate it, and the alert at five minutes past needs someone to receive it.
• A decision on audio-only visits: whether the practice offers them, under what circumstances, and how they are documented and billed differently.

Integrations

• A video platform covered by a business associate agreement, configured for per-visit links rather than a static room. Confirm whether it supports waiting rooms, whether sessions are recorded by default (and turn that off unless the practice has a documented reason and consent for it), and whether join links expire.
• The EHR or practice management system, natively or through Zapier or Make, so visits appear on the clinical schedule and completion status flows back. Keep clinical documentation in the EHR; the platform holds operational fields only.
• Google Calendar or Outlook for provider availability, so a remote calendar cannot double-book against an in-person one.
• Stripe or your existing processor for copay collection, if collecting at the time of visit.
• Slack or email for the no-join alert.

Numbers and messaging setup

• Provision a dedicated local number and complete A2P 10DLC brand and campaign registration under the practice's own legal entity before launch. Register the campaign to reflect the actual use case: appointment and care coordination messaging, not marketing. Filtered join reminders are worse here than in any other build, because a reminder that arrives late is a missed visit.
• Keep this number separate from any marketing sender, and do not reuse a number that has carried promotional traffic.
• Configure opt-out handling for STOP, STOPALL, UNSUBSCRIBE, CANCEL, END, and QUIT, plus natural-language variants. An opt-out must stop all automated sends on the record immediately, including sequences already mid-wait.
• Here is the tension this build has to resolve deliberately: a patient who has opted out of SMS still needs their join link. Decide the fallback before launch (email only, a phone call from the coordinator, or declining to schedule remotely) and build it as an explicit branch rather than letting the patient fall silently through the gap.
• Set quiet hours in the patient's own time zone, and confirm them against your state's rules. Then write a narrow, documented exception for same-day join reminders tied to a confirmed appointment time, and have that exception reviewed before you rely on it. An appointment reminder for a visit the patient booked is treated differently from promotional messaging in most frameworks, but the scope of that difference is not something to assume.
• Spell out the time zone in every reminder. Remote visits cross time zones constantly and "2pm" is not a time.

Protected health information and consent

• Keep clinical content out of SMS bodies and email subject lines. No visit reason, no symptom, no diagnosis, no medication name, no result. A reminder needs the practice name, the provider name, the date and time with time zone, and a link: nothing else.
• Apply the minimum necessary standard to the link delivery too. A join link should be single-use or short-lived and tied to the specific visit. A permanent room URL sitting in a text thread is a standing exposure, and it can be forwarded, screenshotted, or opened by the next person who picks up the phone.
• Treat the telehealth consent as distinct from every other consent in the system. Consent to receive text messages is not consent to a remote visit, and neither is consent to treatment in general. Separate fields, separate forms, separate timestamps. Version the consent text and store the version with the signature.
• Build revocation for both kinds of consent. A patient may withdraw messaging consent, which changes how you reach them, or withdraw telehealth consent, which means the visit should be converted to in-person. Those are different actions with different consequences, and the workflow needs a branch for each. Withdrawal of telehealth consent should stop link delivery and create a task, not simply fail silently.
• Record who consented when the patient is not the signer. consent_signed_by exists because parents, guardians, and authorized representatives sign on behalf of others, and the record needs to show that rather than implying the patient signed.
• Capture the patient's physical location for the visit and keep the audit trail. Licensure generally follows where the patient is, not where they live. Store it as a state, which is what the requirement usually turns on, rather than collecting a full address you have no operational use for.
• Preserve a complete audit trail of consent signatures with versions and timestamps, link issuance and first open, every message sent with its channel and the consent state at the time, and who marked the visit complete. Confirm the retention period and confirm that workflow history cannot be quietly deleted.
• Put a signed business associate agreement in place before the first live patient, covering the platform, the video provider, the messaging carrier, the email sender, the payment processor if it touches patient data, and any automation bridge such as Zapier or Make. The video platform is the one people most often get wrong here: a general-purpose consumer video tool is not a clinical channel, whatever its marketing says.
• Do not record sessions by default. If the practice has a reason to record, that is a separate consent, separately captured, with its own retention rules and its own storage under the BAA.

This is operational guidance, not legal advice. Telehealth rules vary substantially by state and change often. Licensure, consent requirements, modality restrictions, documentation, and what may be said in a text message are all state-dependent. Confirm the specifics for every state you serve with the practice's own compliance counsel before going live, and re-confirm when you add a state or a provider. To scope this build for your practice, book a call at bookings.appbo.io.