Insurance Verification Workflow

In most practices, insurance verification happens at the worst possible moment: the patient is at the window, the schedule is already behind, and one front desk person is holding a card in one hand and a payer portal in the other. Verification done that way is rushed verification. Plan type gets guessed, the deductible is never actually read, nobody asks about secondary coverage, and prior authorization requirements are discovered after the visit has already happened. The patient gets checked in anyway, because the alternative is an argument in a full waiting room.

The money leaks in three predictable places. Eligibility and authorization denials are the most avoidable denials in the book and the most expensive to rework, because they come back weeks later when nobody remembers the encounter. Write-offs follow on balances the patient never agreed to in advance, because a cost conversation held after the service is a collections problem rather than a consent conversation. And the quiet leak is schedule attrition: patients who hear an unexpected number at check-in cancel the follow-up, the series, or the procedure, and that cancellation never gets attributed to the verification gap that caused it.

There is a compliance cost too. When verification is a scramble, protected health information moves through whatever channel is fastest. Card photos land in a personal text thread, benefit details get emailed in plain subject lines, and a sticky note with a member ID sits on a monitor until someone throws it away. The fix is not a better front desk person. It is moving the whole collection-and-verification sequence off the counter and into a tracked workflow that runs on its own days before the patient arrives, with every message scoped to the minimum necessary and every action timestamped.

Pipeline and stages

One pipeline, Insurance Verification, holding an opportunity per upcoming appointment rather than per patient, so a patient with three scheduled visits has three verification records.

• Appointment Booked: verification record created, nothing requested yet.
• Coverage Request Sent: pre-check form delivered, awaiting patient response.
• Coverage Details Received: form complete, card images attached, ready for staff.
• Verification In Progress: assigned to a verifier, eligibility check underway.
• Verified - Covered: active coverage confirmed, patient responsibility known.
• Verified - Prior Auth Required: coverage active but service needs authorization.
• Prior Auth Submitted: request filed, decision pending.
• Estimate Sent: patient responsibility communicated, acknowledgment pending.
• Cleared for Visit: verified and acknowledged, front desk has nothing left to do.
• Unverified - Unreachable: patient did not respond after the full attempt ladder.
• Self-Pay Path: no active coverage, or patient elected self-pay.
• Appointment Canceled: closed, with a reason captured.

Calendars

• Patient appointment calendars: the clinical calendars already in use. The verification record is created from the booking event, not maintained separately.
• Financial Counseling Call: a 15-minute internal calendar the automation can offer when a patient responsibility figure crosses the practice-set threshold, or when a patient replies with a question about cost.
• Verification Work Block: a daily internal calendar block assigned round-robin to the verification team, so the work queue has owned time rather than being squeezed between phone calls.

Custom fields

Build these on the contact record unless marked as belonging to the opportunity. Keep identifiers in the record and out of message bodies.

• payer_name, plan_type (commercial, Medicare, Medicare Advantage, Medicaid, managed Medicaid, marketplace, other), subscriber_relationship, coverage_effective_date, coverage_term_date
• member_id_on_file (yes/no switch), card_front_received, card_back_received, secondary_coverage_on_file
• verification_status, verification_checked_by, verification_checked_at, eligibility_reference_number, verification_source (clearinghouse, payer portal, payer phone)
• copay_confirmed, deductible_status (met, partially met, not met), coinsurance_percent, patient_responsibility_estimate (opportunity field)
• prior_auth_required, prior_auth_number, prior_auth_submitted_at, prior_auth_decision, prior_auth_expires_on
• estimate_sent_at, estimate_acknowledged_at, financial_discussion_completed
• consent_sms, consent_email, consent_captured_at, consent_source, consent_revoked_at, preferred_contact_channel
• outreach_attempts (number, incremented by the chase workflow), last_outreach_at

Tags

• Status: verification-pending, verification-complete, needs-prior-auth, auth-approved, auth-denied, cleared-for-visit
• Payer routing: payer-commercial, payer-medicare, payer-medicaid, payer-marketplace, self-pay
• Gaps: card-images-missing, member-id-missing, unreachable-ladder-exhausted, estimate-unacknowledged
• Consent: sms-opt-out, email-opt-out, all-outreach-paused

Forms

• Coverage and Benefits Pre-Check: the core form, delivered by link rather than by embedding identifiers in a message. Captures payer, plan type, subscriber details, member identifier, group number, secondary coverage, and front and back card images through a file upload field. Carries the consent block and a plain-language notice about how the information is used and stored.
• Card Image Upload: a short single-purpose form for the common case where everything else is on file and only the images are missing.
• Financial Responsibility Acknowledgment: presents the estimate and captures a typed name, date, and checkbox acknowledgment. Stamps estimate_acknowledged_at.
• Communication Preferences and Consent: standalone form a patient can be sent at any time to grant or withdraw SMS and email consent. Writes to consent_sms, consent_email, and consent_revoked_at.

BO's role and guardrails

BO handles the logistics layer of this build and nothing more. BO chases missing form fields and card images, answers questions about what the form is for and how to use it, confirms receipt, reschedules the financial counseling call, and routes anything else to a human.

• BO never states, confirms, interprets, or estimates coverage, benefits, deductibles, or patient responsibility. Those come from a verified record and a human sender.
• BO never restates clinical information, procedure names, diagnoses, or reason for visit in any outbound message.
• BO never asks for or echoes a member identifier, group number, or date of birth in SMS or email. Identifiers are collected only inside the form.
• BO escalates on any message containing a cost dispute, a coverage appeal, a complaint, or clinical content, and on any phrase suggesting urgency or distress. Escalation assigns to the verification lead and pauses all automated sends on that record.
• BO honors opt-out language in any form, not just the exact keyword, and stops the moment all-outreach-paused is applied.

Numbers and channels

• One dedicated local number for patient-facing verification messaging, registered for A2P 10DLC under the practice's own legal entity, kept separate from any marketing number so a marketing complaint cannot degrade clinical deliverability.
• Outbound email from a practice subdomain with authentication records in place. Subject lines carry no clinical or financial detail.
• A secure link channel for anything beyond scheduling logistics. Messages say that something is ready and where to go; the content lives behind authentication.
• Inbound voice routing so a patient who calls the number back reaches the verification queue rather than a dead end, with call outcome written to the opportunity.
• Internal notification channel (email or Slack) for the verifier queue, carrying record links rather than patient detail.

1. A patient books a visit three weeks out, either through the online booking page or by phone with a staff member. Either path creates the appointment on a clinical calendar.
2. The booking event creates an opportunity in Insurance Verification at Appointment Booked, linked to the contact and stamped with the appointment date and the owning provider. The appointment date drives every wait and deadline downstream.
3. Within fifteen minutes the first workflow checks consent. consent_sms is true from the booking form, so the patient gets a short text: no procedure name, no diagnosis, just a note that the practice needs coverage details before the visit and a link to the pre-check form. The stage moves to Coverage Request Sent.
4. The patient opens the form on their phone. They select their payer, enter the member identifier and group number, answer the subscriber relationship question, say whether there is secondary coverage, and photograph the front and back of the card. The identifiers and images are captured inside the form and written to the record; nothing is echoed back in a message.
5. Form submission writes payer_name, plan_type, member_id_on_file, card_front_received, and card_back_received, applies the matching payer- tag, moves the stage to Coverage Details Received, and drops the record into the verifier queue.
6. A verifier picks the record up during their work block. They run eligibility through the clearinghouse or the payer portal, then write verification_status, eligibility_reference_number, verification_source, copay_confirmed, deductible_status, coinsurance_percent, and prior_auth_required. The platform stamps verification_checked_by and verification_checked_at automatically, so the audit trail does not depend on anyone remembering to log it.
7. Coverage is active, and the scheduled service does require authorization. The verifier sets prior_auth_required to yes. The stage moves to Verified - Prior Auth Required, the needs-prior-auth tag lands, and the authorization track starts with its own deadline clock measured backward from the appointment date.
8. The authorization request goes out. prior_auth_submitted_at is stamped and the stage moves to Prior Auth Submitted. The track now nudges the assigned owner on a fixed cadence until a decision is recorded, and escalates to the verification lead if the appointment is close and nothing has come back.
9. Authorization is approved. prior_auth_number, prior_auth_decision, and prior_auth_expires_on are written. The auth-approved tag replaces needs-prior-auth.
10. With coverage and authorization settled, the estimate workflow builds the patient responsibility figure into the acknowledgment form and sends a notification, not the number itself, by text and email. The message says a coverage summary is ready and links to the secure form. The stage moves to Estimate Sent and estimate_sent_at is stamped.
11. The patient opens the form, sees the figure in context, and submits the acknowledgment with a typed name and date. estimate_acknowledged_at is written and the estimate-unacknowledged tag is removed if it had been applied.
12. With verification complete and the estimate acknowledged, the stage moves to Cleared for Visit and the cleared-for-visit tag is applied. The appointment reminder sequence now carries a line confirming that coverage is on file and what to bring, rather than asking the patient to arrive early for paperwork.
13. The day before the visit, a sweep workflow checks every appointment on tomorrow's schedule. Anything not at Cleared for Visit, Self-Pay Path, or Appointment Canceled is listed in a single internal digest so the team sees the real exception list before the day starts instead of discovering it one patient at a time.
14. After the visit, the opportunity closes and its fields stay attached to the contact. When the same patient books again, the next verification record pre-populates from the last one, and the pre-check form asks only whether anything has changed. Repeat patients answer one question instead of twelve.

Eight workflows carry this build. Every one of them opens with the same consent and suppression check, and every one of them exits the moment a human takes over. Wait durations assume an appointment booked at least seven days out; the scheduling logic below compresses the ladder for short-notice bookings.

1. Coverage Pre-Check Request

Trigger: appointment booked on any clinical calendar, or an opportunity created in Insurance Verification at Appointment Booked.

Conditions and branches:

• Exit immediately if all-outreach-paused is present, or if the appointment is a same-day urgent slot (those route to a staff task instead).
• Branch on days until appointment. Seven or more days: run the full ladder below. Two to six days: compress all waits to roughly a third and notify the verifier lead at the start. Under two days: skip the patient-facing ladder entirely, create a staff task to call, and tag verification-pending.
• Branch on payer_name presence. If coverage was verified within the practice's reuse window, send the short "confirm nothing has changed" variant instead of the full form.

Actions in order:

1. Add tag verification-pending. Set outreach_attempts to 0.
2. Wait 15 minutes, so a patient who booked by phone is not texted while still on the call.
3. If consent_sms is true, send SMS: "Hi [first name], this is [practice name]. Before your visit on [appointment date] we need your insurance details so there's nothing to sort out at the front desk. It takes about two minutes: [form link]. Reply STOP to opt out."
4. Move stage to Coverage Request Sent. Stamp last_outreach_at. Increment outreach_attempts.
5. Wait 2 hours. If consent_email is true and the form is still incomplete, send email. Subject: "Before your upcoming visit". Body repeats the ask and the link, with no appointment reason and no identifiers.

Stop and exit: form submitted, stage advanced past Coverage Request Sent, appointment canceled, opt-out received, or any inbound reply (which hands off to BO).

2. Pre-Check Chase Ladder

Trigger: opportunity has sat at Coverage Request Sent for 48 hours.

Conditions and branches: exit if days-until-appointment is 1 or fewer (the day-before sweep owns those). Branch on preferred_contact_channel where set; otherwise text first, email second, call third.

Actions in order:

1. Attempt two: SMS: "Hi [first name], just a reminder from [practice name] that we still need your insurance details before [appointment date]. Here's the link again: [form link]." Increment outreach_attempts.
2. Wait 3 days. If still incomplete, attempt three. Email, subject "Still need a couple of details", with the link and a line offering a phone alternative: "If it's easier, call us at [number] and we'll take these over the phone."
3. Wait 2 days. If still incomplete, attempt four. Create a staff task, "Call to collect coverage details before [appointment date]", assigned to the verifier on duty, due same day. Add tag unreachable-ladder-exhausted.
4. Wait 1 day. If the task is closed with no contact and the form is still incomplete, move stage to Unverified - Unreachable and notify the verification lead.

Stop and exit: form submitted, opt-out, cancellation, or stage change. Hard cap at four attempts regardless of time remaining. The ladder never loops.

3. Partial Submission and Card Image Recovery

Trigger: pre-check form submitted with card_front_received false, card_back_received false, or member_id_on_file false.

Conditions and branches: branch on what is missing. Images only, identifier only, or both. Each branch sends a different single-purpose ask so the patient is never told to redo the whole form.

Actions in order:

1. Add tag card-images-missing or member-id-missing as applicable. Hold the stage at Coverage Request Sent rather than advancing. A partial submission is not a submission.
2. Wait 30 minutes. SMS: "Thanks [first name]. We have most of what we need. We're just missing a photo of your insurance card, front and back. You can add it here: [card upload form link]."
3. Wait 1 day. If still missing, BO follows up conversationally and offers to answer questions about the upload, without ever asking the patient to send an image by text.
4. Wait 2 days. If still missing, create a staff task to collect at check-in and add a visible note on the appointment, so the front desk knows exactly which one item to ask for.

Stop and exit: the missing fields are filled, or a staff member marks the gap as resolved on the record. Never send an image request by SMS reply thread; always a form link.

4. Verifier Queue Assignment and Aging

Trigger: stage changes to Coverage Details Received.

Conditions and branches: branch on plan_type to route to the verifier who owns that payer group where the team is specialized; round-robin otherwise. Branch on days-until-appointment to set priority: under 72 hours is flagged urgent.

Actions in order:

1. Assign the opportunity owner by the routing rule. Move stage to Verification In Progress.
2. Create an internal task, "Verify coverage for [appointment date] appointment", due the earlier of 24 hours from now or 48 hours before the appointment. The task carries a record link only. No patient detail in the notification body.
3. Notify the assigned verifier on the internal channel.
4. Wait 24 hours. If verification_checked_at is still empty, re-notify the verifier and the lead together.
5. Wait 24 hours. If still empty and the appointment is inside 72 hours, escalate to the verification lead as urgent and add the record to the day-before digest regardless of its stage.

Stop and exit: verification_checked_at is populated and the stage moves to a Verified stage, or the appointment is canceled.

5. Prior Authorization Track

Trigger: prior_auth_required set to yes, or stage moved to Verified - Prior Auth Required.

Conditions and branches: branch on days-until-appointment. Fourteen or more days runs the standard cadence; under fourteen days runs an accelerated cadence and notifies the lead at the start; under five days also creates a scheduling review task, because the honest answer may be to move the appointment.

Actions in order:

1. Add tag needs-prior-auth. Create task "Submit prior authorization" assigned to the authorization owner, due within 1 business day.
2. On prior_auth_submitted_at being stamped, move stage to Prior Auth Submitted and start the follow-up cadence.
3. Wait 3 business days (1 business day on the accelerated branch). If prior_auth_decision is empty, create a task to follow up with the payer and log the contact attempt on the record.
4. Repeat step 3 every 3 business days, to a maximum of four follow-ups, then escalate to the lead.
5. At 5 days before the appointment, if prior_auth_decision is still empty, notify the lead and the scheduler together with a reschedule recommendation. No patient message fires from this branch. That conversation is a phone call from a human.
6. On decision approved: write prior_auth_number and prior_auth_expires_on, swap needs-prior-auth for auth-approved, and release the record to workflow 6.
7. On decision denied: add auth-denied, create an urgent task for the lead covering appeal or self-pay discussion, and do not send any automated patient message. A denial is always delivered by a person.

Stop and exit: a decision is recorded, the appointment is canceled, or the lead closes the track manually.

6. Patient Cost Estimate and Acknowledgment

Trigger: stage moves to Verified - Covered, or auth-approved is applied with verification already complete.

Conditions and branches:

• If patient_responsibility_estimate is at or below the practice threshold, send the standard estimate notification.
• If above the threshold, branch to the financial counseling path: offer a booking link for the Financial Counseling Call calendar instead of a bare figure.
• If plan_type is Medicaid or managed Medicaid, branch to the practice's own cost-sharing rules for that program rather than the standard estimate copy.

Actions in order:

1. Generate the acknowledgment form pre-filled from the verified fields. Stamp estimate_sent_at, move stage to Estimate Sent, add tag estimate-unacknowledged.
2. Send SMS (standard branch): "Hi [first name], your coverage for the [appointment date] visit is confirmed and your cost summary is ready. Review and confirm here: [secure form link]. Questions? Call [number]." No figure in the message body.
3. Send email in parallel. Subject: "Your coverage summary is ready". No figure in the subject line.
4. Counseling branch instead of steps 2 and 3: "Hi [first name], your coverage is confirmed. We'd like to walk you through the cost before your visit so there are no surprises. Pick a time that works: [booking link]."
5. Wait 2 days. If estimate_acknowledged_at is empty, send one reminder on the same no-detail pattern.
6. Wait 3 days. If still unacknowledged and the appointment is inside 5 days, create a staff task to confirm by phone and leave the estimate-unacknowledged tag in place so the day-before digest catches it.
7. On acknowledgment: remove estimate-unacknowledged, add cleared-for-visit, move stage to Cleared for Visit, and write back to the practice management system if that integration is live.

Stop and exit: acknowledgment received, appointment canceled, or a human sets financial_discussion_completed to yes. Maximum two automated reminders.

7. Self-Pay and No-Coverage Path

Trigger: verification_status set to no active coverage, coverage terminated, or patient elected self-pay; or stage moved to Self-Pay Path.

Conditions and branches: branch on whether coverage was expected. A patient who believed they were covered gets a phone call first, not a text. That is a human conversation. A patient who booked as self-pay from the outset gets the direct path.

Actions in order:

1. Remove payer- tags, add self-pay, move stage to Self-Pay Path.
2. Unexpected-loss branch: create an urgent task, "Call patient about coverage status before [appointment date]", assigned to the verification lead, and suppress all automated patient messaging on this record until the task is closed.
3. Known self-pay branch, wait 1 hour, then SMS: "Hi [first name], we've confirmed how billing will work for your [appointment date] visit. Here's what to expect and how to confirm: [secure form link]."
4. Wait 1 day. Email the same notification if unacknowledged.
5. On acknowledgment, move to Cleared for Visit and tag cleared-for-visit.
6. Wait until 2 days before the appointment. If still unacknowledged, add to the day-before digest and create a phone task.

Stop and exit: acknowledgment received, appointment canceled, or coverage subsequently verified (which returns the record to workflow 4).

8. Consent Capture, Opt-Out and Revocation

Trigger: any of. Inbound SMS matching an opt-out keyword or opt-out intent; email unsubscribe; submission of the Communication Preferences and Consent form; or a staff member setting consent_revoked_at.

Conditions and branches: branch by channel. An SMS opt-out suppresses SMS only; an email unsubscribe suppresses email only; a full withdrawal on the consent form suppresses both and applies all-outreach-paused.

Actions in order:

1. Write the relevant consent field to false. Stamp consent_revoked_at with the exact time. Record consent_source as the channel the revocation arrived on.
2. Apply sms-opt-out, email-opt-out, or all-outreach-paused.
3. Immediately remove the contact from every active sequence, including ones already mid-wait. This is the step most builds get wrong: suppressing future triggers is not enough if a wait step is already queued.
4. Send one confirmation on the channel being revoked, if the channel permits it: "You've been unsubscribed from text messages from [practice name]. You won't get further texts. If you need to reach us, call [number]." Nothing further on that channel after this.
5. Create a staff note on the record stating which channels remain available, so anyone who opens the record sees it without hunting.
6. If the patient has an upcoming appointment and no channel remains, create a task to reach them by phone or mail for anything the verification flow still needs.

Stop and exit: runs once per revocation event and ends. Re-consent requires a fresh affirmative submission of the Communication Preferences and Consent form. No workflow may re-enable a consent field on its own, and no sequence may treat silence as renewed permission.

Before launch, test workflows 1, 2, 6 and 8 end to end with a test contact, including an opt-out triggered mid-sequence, a partial form submission, and a booking made inside the two-day window. Those four paths are where this build most often leaks.

Verification stops being a check-in activity. By the time a patient reaches the window, coverage has been confirmed, authorization is either secured or known to be missing, and the patient has already seen and acknowledged what they owe. The front desk conversation becomes a greeting rather than a negotiation, and the schedule stops absorbing the five to ten minutes per patient that live verification costs.

Authorization stops being a surprise. Because the requirement is discovered when the record is verified rather than when the claim is denied, there is runway to file, follow up, and escalate. Services that genuinely cannot be authorized in time get rescheduled deliberately instead of performed and written off.

Cost conversations move to the right side of the service. A patient who acknowledged a figure in writing a week before the visit is a patient who either shows up prepared or cancels early enough for the slot to be refilled. Both outcomes are better than a balance nobody expected.

The record also becomes defensible. Every verification carries who checked it, when, against which source, and with what reference number. Every patient message carries the consent state at the time it was sent. That is the difference between believing the process is sound and being able to show it.

Metrics to watch

• Share of appointments reaching Cleared for Visit before the appointment date: the headline number for whether the build is working.
• Pre-check form completion rate, and days from request to completion: tells you whether the chase ladder is tuned or annoying.
• Eligibility and authorization denial rate, tracked against the same measure from before the build.
• Authorization lead time: days between verification and a recorded decision, and how many decisions land inside the appointment window.
• Estimate acknowledgment rate and days from estimate sent to acknowledged.
• Unreachable rate: records exhausting the attempt ladder, segmented by payer and by referral source, since a high rate usually points at bad contact data upstream.
• Day-before exception count: should fall steadily; it is the clearest signal of whether the earlier stages are catching work.
• Cancellation rate after estimate sent: watch it, do not panic at it. Early cancellations are cheaper than late ones, but a spike means the estimate copy needs work.

Operational prerequisites

• A named owner for the verifier queue and a named escalation lead. This build creates a work queue; a queue without an owner silently fills up.
• Agreement on which services require authorization under which payers, written down somewhere the verifier can check. The automation routes; it does not know your payer rules.
• A practice-set threshold above which a patient responsibility figure triggers a financial counseling call rather than a plain estimate send.
• Decided language for the estimate: whether the figure is presented as an estimate subject to final adjudication, and what the acknowledgment form says. Have the person who owns patient financial policy approve that copy before launch.
• A clean contact dataset. Verification outreach dies on wrong cell numbers, so run a data quality pass on phone and email fields first.

Integrations

• The practice management or EHR system, connected either natively or through Zapier or Make, so appointment bookings create verification records and verified fields can be written back. Decide early which system is the source of truth for coverage data; two systems both believing they own it is the most common failure in this build.
• An eligibility source: clearinghouse API where available, payer portals otherwise. Where the check is manual, the build tracks and times the work rather than performing it.
• Google Calendar or Outlook for the financial counseling and verification work block calendars.
• Stripe or your existing payment processor if you intend to collect patient responsibility in advance.
• Slack or email for the internal verifier queue notifications.

Numbers and messaging setup

• Provision a dedicated local number for verification messaging and complete A2P 10DLC brand and campaign registration under the practice's own legal entity before any volume goes out. Register it as a conversational or customer care campaign reflecting the real use case; an unregistered or mis-registered number will be filtered, and in this build a filtered message means an unverified patient.
• Keep this number separate from marketing numbers. Clinical operational messaging and promotional messaging should never share a sender.
• Configure opt-out handling for STOP, STOPALL, UNSUBSCRIBE, CANCEL, END, and QUIT, plus a natural-language catch so a patient who writes "please stop texting me" is honored the same way. Opt-out sets consent_sms false, stamps consent_revoked_at, applies sms-opt-out, and must suppress every workflow on the record, not just the one that sent the message.
• Set quiet hours in the patient's own time zone and confirm them against your state's rules, which are sometimes tighter than the federal baseline. Hold sends outside the window rather than dropping them, so a Friday evening trigger goes out Saturday morning instead of vanishing.
• Give opted-out patients a path that still works: a mailed or portal route to the same form, and a note on the record so staff know to call rather than text.

Protected health information and consent

Treat every outbound message in this build as if it will be read by someone other than the patient, because it may be.

• Keep clinical and financial detail out of SMS bodies and email subject lines entirely. No procedure names, no diagnoses, no reason for visit, no dollar figures, no member identifiers, no dates of birth. The message's job is to say something is ready and where to go.
• Apply the minimum necessary standard to every template. Before a message goes live, ask what the smallest amount of information is that still makes it actionable, and cut to that. Most verification messages need only the practice name, the fact that coverage details are needed, the appointment date, and a link.
• Capture consent explicitly and separately by channel. SMS consent and email consent are distinct, each with its own field, its own timestamp, and its own recorded source. Consent to appointment messaging is not consent to marketing; keep them in different fields and never let a marketing workflow read the clinical consent field.
• Make revocation immediate and global. A revocation must stop every automated send on the record, including sequences already in flight. Test this before launch by opting a test contact out mid-sequence and confirming nothing further fires.
• Preserve the audit trail. Verification actions should be attributable: who checked coverage, when, against what source, with what reference. Every message send should be retrievable with its timestamp, channel, recipient, and the consent state at the time. Confirm your retention period and make sure nobody can quietly delete workflow history.
• Put a signed business associate agreement in place before the first live patient record enters the system, covering the platform and every subprocessor that touches patient data in this build. The messaging carrier, the email sender, file storage for card images, and any automation bridge such as Zapier or Make. A tool without a BAA in place does not belong anywhere in this flow. Verify that file uploads containing card images are stored under that agreement and not in a general-purpose bucket.
• Restrict access by role. Verifiers need coverage fields; schedulers generally do not need card images. Set permissions so the record is visible at the level each role actually requires.

This section describes operational practice, not legal advice. Requirements vary by state, by payer contract, and by the practice's own risk posture. Confirm the specifics. Message content limits, consent language, retention periods, and which agreements you need with whom: with the practice's own compliance counsel before going live. To scope this build for your practice, book a call at bookings.appbo.io.