Migrate from tab32 to HighLevel

tab32 Patient maps to HighLevel Contact for all standard demographics: name, date of birth, contact information, address, and primary provider. Insurance subscriber relationship and multi-location patient identifiers carry over as custom fields. The original patient create date is preserved as a custom datetime field since HighLevel's CreatedDate reflects the migration timestamp.

tab32 stores primary and secondary insurance as structured objects on the patient record: carrier name, group number, member ID, subscriber name, and relationship. These have no native HighLevel equivalent, so we create an Insurance custom object with a lookup relationship to Contact and populate carrier, group/member, subscriber, and effective date fields per source record.

tab32 tooth chart stores per-tooth conditions (Intact, Missing, Filling, Crown, Implant, Root Canal, etc.) in a structured grid. We translate this into a set of HighLevel custom fields — one per tooth surface or using a structured text field — and preserve the chart snapshot as of migration date. Historical chart changes do not carry forward; the final chart state is the migration record.

Periodontal probing measurements (6-point per-tooth probing depths) stored in tab32 map to a Perio_Exam custom field on the HighLevel Contact. We store the most recent exam date and a serialized JSON snapshot of the probing data as a long-text field. Perio trend history is not traversable in HighLevel's flat record model — the most recent exam snapshot is preserved.

tab32 treatment plans list procedures with CDT codes, tooth numbers, surfaces, fees, and provider. We map each treatment plan to a HighLevel Opportunity named by patient + plan date, with CDT codes stored as Opportunity custom fields and fee amounts mapped to the Opportunity Amount field. Incomplete treatment plans preserve recommended-but-not-started procedures as a custom field note.

Scheduled appointments map to HighLevel Calendar Events with the patient (Contact) linked, provider assigned, time block set, and operatory location tagged as a custom field. Past appointment records migrate as read-only Task entries with type='Completed Appointment' so the patient's activity history is visible in HighLevel's timeline.

tab32 providers (dentist, hygienist, assistant) and administrative staff are mapped to HighLevel users by email match. tab32 role assignments (Provider, Admin, Front Desk) map to HighLevel staff permissions and sub-account roles. Users without a matchable email are flagged before migration so they can be invited to HighLevel first.

Each tab32 practice location becomes a HighLevel sub-account. All patients, appointments, and contacts belonging to a location are assigned to that sub-account. The location's fee schedule, provider list, and operatory configuration are stored as custom fields on the sub-account settings page. This requires pre-creation of sub-accounts before data is loaded.

tab32 imaging file references (X-ray URLs, intraoral photos) are stored as file attachments linked to the patient record. We re-upload available images to HighLevel as Contact file attachments. Large imaging volumes may require a separate cloud storage reference field since HighLevel has per-file size limits for CRM attachments.

tab32 fee schedules vary per location and specialty. We create a Fee_Schedule custom object in HighLevel linked to the location's sub-account, storing CDT code, description, and fee amount. This preserves the schedule structure for future treatment plan报价 but is not automatically tied to Opportunities — it is a reference object for staff to consult.

tab32 appointment reminder rules, recall triggers (e.g., perio maintenance every 6 months), and recare campaign logic have no HighLevel equivalent. We export the rule definitions (trigger conditions, timing, message content) as a JSON reference document that maps directly to HighLevel Workflow triggers (Date/Time, Contact Field Change, Tag Added) so your admin can rebuild each automation in HighLevel's Workflow Builder.

tab32 A/R records, claim submission history, payment history, and remaining benefits data do not map into HighLevel's contact/opportunity model. We preserve this as a read-only Billing_History custom object for reference and audit continuity, but we do not attempt to render active claims or open balances in HighLevel. Active RCM should continue in tab32 or a dedicated billing system during the transition.