Migrate from Henry Schein One to Mailchimp

Patient first name, last name, email address, phone number, and mailing address map directly to Mailchimp's standard contact fields. This is the foundational data layer of the migration — every patient record containing an email address generates a corresponding Mailchimp subscriber entry. We validate email format before write and skip records with missing or malformed addresses. Physical mailing addresses populate Mailchimp's structured address fields for campaigns that include direct mail integrations or location-based segmentation.

Mobile phone numbers that exceed the standard phone field format require a custom phone-type merge field in Mailchimp. We create SMS-capable merge fields for patients who have opted in to text communications, since Mailchimp's SMS feature requires a separate consent workflow.

Henry Schein One's recall engine stores the next hygiene-appointment date per patient. We map this to a date-type merge field (e.g., NEXT_RECALL_DATE) so Mailchimp automations can trigger appointment-reminder campaigns when the recall date is within a configurable window. Original recall-set timestamp is preserved as a text field.

The most recent completed-appointment timestamp from the patient record maps to a Mailchimp date-type merge field (LAST_VISIT). This single timestamp enables powerful segmentation scenarios: practices can create audience segments for patients whose last visit exceeds 6 or 12 months without importing the full clinical appointment history. Reactivation campaigns target this segment directly, driving lapsed patients back into the recall schedule. The date field is stored in ISO format for reliable automation triggering.

Insurance billing responsible-party information from the patient record maps to a text merge field (GUARANTOR_NAME). A corresponding Mailchimp tag (GUARANTOR) is applied to associate the contact with its responsible party. When multiple family members share a single responsible party for billing purposes, the tag enables efficient grouping for consolidated family outreach campaigns — a parent or guardian receives one communication covering all dependent family members rather than separate messages per patient.

Insurance carrier name from Henry Schein One's coverage tables maps to a text merge field (PRIMARY_INSURER). A corresponding Mailchimp tag is applied per carrier so campaigns can be segmented by insurance provider — useful for benefits-coverage reminders or seasonal flu-shot outreach tied to specific plans.

The most recent active treatment plan description migrates as a text merge field. Because Mailchimp caps text merge fields at 255 characters, detailed treatment plans are truncated — we include a truncation note and preserve the full description in an internal reference field not synced to Mailchimp.

The current patient account balance from the billing ledger migrates as a number-type merge field (ACCOUNT_BALANCE). This property enables segmentation for targeted balance-reminder campaigns, payment-plan outreach, or collections sequences. We capture a snapshot of the balance at migration time — Mailchimp does not maintain a live connection to the billing ledger, so the figure represents a static value that becomes progressively stale as the PMS ledger continues updating post-migration.

The assigned primary provider name from the patient record maps to a text merge field (PRIMARY_PROVIDER) and applies a corresponding Mailchimp tag. Segmentation by provider enables targeted referral-thank-you campaigns, provider-specific newsletters, and specialty care announcements — for example, orthodontic updates for patients under an ortho provider or periodontal maintenance reminders for perio-attributed contacts.

The procedure type associated with the patient's most recent completed appointment — such as hygiene, restorative, oral surgery, or emergency visit — maps to a Mailchimp tag applied at migration time. This tag drives downstream segmentation logic for follow-up campaign routing: hygiene patients receive recare-focused recare reminders while restorative patients are enrolled in post-operative care sequences and surgical patients get recovery-check communications.

For multi-location dental service organizations and group practices, the practice or location name associated with each patient record maps to a text merge field (PRACTICE_NAME). This prevents misdirected outreach when a single Mailchimp audience serves multiple locations — staff can filter by practice name to ensure appointment reminders and marketing campaigns reach patients at the correct location without cross-contamination.

Any custom patient properties defined in Dentrix Ascend (e.g., loyalty program status, referral source, membership tier) map to individual Mailchimp merge fields created during setup. Each custom field requires manual creation in Mailchimp's audience settings before the migration map can resolve.

Full appointment history — dates, providers, procedure codes, clinical notes per visit — has no equivalent in Mailchimp's flat contact model. We do not migrate appointment history lists. The last-appointment date is preserved as a single timestamp; the full clinical timeline stays in the PMS.

Detailed treatment plans including procedure codes, surfaces, materials, and clinical notes do not migrate. The most recent plan summary (255-char capped) migrates as a reference field. Clinical treatment plans must remain in the PMS; Mailchimp has no clinical data model.

Billing ledger history — including all charges, payments, adjustments, insurance payments, and write-offs organized by procedure — does not migrate to Mailchimp. The email marketing platform provides no accounting or ledger data model. We migrate only the current account balance snapshot as a static contact property (ACCOUNT_BALANCE) for segmentation purposes. Practices should note that this balance figure represents a point-in-time snapshot that will diverge from the live PMS ledger as billing activity continues after migration.