Migrate from axiUm Dental to Mailchimp

Patient record is the primary migration unit. Mailchimp contacts store email as the primary identifier; axiUm patient email maps directly. Names split into Mailchimp FNAME and LNAME merge fields. Original patient creation date preserved as a custom merge field. and serves as a reference for reporting and de-duplication in future delta runs.

Mailchimp supports a structured address field (ADDR1, ADDR2, CITY, STATE, ZIP, COUNTRY). axiUm patient address components map into Mailchimp's address merge field format. Multiple addresses per patient collapse to the primary address. If multiple addresses exist, we select the most recent or the one marked as preferred for billing.

axiUm patient phone numbers migrate to Mailchimp's PHONE merge field. Mobile and home phone numbers from axiUm's separate phone table merge into one PHONE field; the type annotation (mobile vs. home) is preserved as a tag. This tag enables targeted messaging based on patient contact preferences.

Appointment history generates Mailchimp tags (e.g., 'recall-due-2024', 'active-patient', 'lapsed-over-12-months') rather than a native appointment object. Recall intervals from axiUm inform tag-based segmentation for customer journey triggers in Mailchimp. These tags can be combined with date-based automation to send timely reminders, and they help track patient engagement over time.

Mailchimp has no native insurance field. Insurance carrier name from axiUm migrates as a custom merge field (INSURANCE_CARRIER) or as a tag for segment filtering by insurance provider, depending on how many unique plans the practice manages. This approach enables targeted outreach such as benefits reminders, provider-specific newsletters, or insurance renewal campaigns.

axiUm provider and student identifiers (faculty, resident, student names) have no Mailchimp equivalent. These map to custom merge fields (PRIMARY_PROVIDER, STUDENT_ID) for reference and future segmentation by assigned provider. This allows outreach to be filtered by provider for follow-up communications, provider-specific promotions, or academic research cohorts.

Treatment notes, procedure codes, odontogram data, periodontal charts, and clinical narratives are PHI and have no Mailchimp equivalent. These remain in axiUm. We flag these records for exclusion from the export scope during migration planning. The exclusion prevents inadvertent PHI exposure and ensures the migration audience stays within the email marketing use case defined by the BAA.

Insurance claims, payments, and ledger entries are billing data with no Mailchimp counterpart. They do not migrate. We extract patient balance summary as an optional custom field (OUTSTANDING_BALANCE) only if the practice requests it and it does not constitute PHI.

Scanned consents, custom clinical forms, and attachment records stored in axiUm's attachments module have no Mailchimp equivalent. These stay in axiUm and should be audited for email consent status separately for HIPAA BAA compliance. This audit ensures that only patients with documented marketing consent are included in future Mailchimp campaigns, supporting both regulatory compliance and sender reputation.

Clinic-defined custom properties in axiUm (e.g., referral source, preferred appointment time, treatment interest) map to Mailchimp merge fields. Merge field type (text, number, date, checkbox) is chosen based on axiUm field data type. Mailchimp supports up to 40 merge fields per audience.

axiUm internal do-not-contact flags export as a Mailchimp suppression list. Any patient marked as do-not-contact in axiUm is pre-suppressed in Mailchimp before the migration commits, ensuring CAN-SPAM compliance from day one. This pre-suppression also protects sender reputation by preventing bounces from contacts that have opted out, and it aligns with the BAA requirement for honoring patient communication preferences.