Migrate your tab32 data

Patient demographics, contact information, insurance details, and clinical history map 1:1 into tab32's patient record schema. We preserve lifecycle data including first visit, recall dates, and referring provider attribution. Multi-location patients are deduplicated across offices so the single patient record reflects all visits.

Tab32 uses a standard graphical tooth chart. We export the chart state (existing conditions, missing teeth, restorations) and reconstruct it in the target system using the odontogram's structured per-tooth and per-surface notation.

Periodontal exam data — probing depths, recession, furcation involvement, mobility — is stored as structured clinical measurements per tooth site. We preserve the full perio history so the target system retains disease progression or improvement over time.

Scheduled appointments including date, time, provider, operatory, procedure codes, and status map directly. We flag recurring appointments to ensure the recurrence pattern is reconstructed at the destination rather than landing as isolated single instances.

Treatment plans with proposed procedures, CDT codes, fee amounts, and acceptance status vary in how individual PMS platforms store plan versions. We extract the most current approved plan, map CDT codes explicitly, and flag any custom or provider-specific codes that may need re-approval at the destination.

Claims history including submitted amounts, payer, status, and payment postings can be extracted but most platforms do not expose the full 837P/835 remittance data via export. We bring what is available and flag gaps in payment history that may affect A/R reporting continuity.

Patient ledger entries — co-pays, adjustments, write-offs, and payment history — are often stored in flattened or proprietary formats. We reconstruct the ledger as a sequence of dated entries, preserving outstanding balances and applying any payment-plan structures the customer has configured.

Provider records including name, credentials, NPI, taxonomy, and practice location assignments map 1:1. We maintain the relationship between providers and the offices they serve for multi-location migrations.

Each office location has its own set of configurations — fee schedules, operating hours, operatory assignments, and user permissions. We treat locations as first-class migration objects and preserve the full office configuration tree so the DSO lands with all locations structurally intact.

tab32 strongly recommends normalizing fee schedules across locations before migration. We audit the source fee schedule for duplicate specialty codes, negotiate one unified schedule per payer, and flag any existing fee schedules in the source that deviate significantly from DSO-negotiated rates.

Dental imaging files (DICOM, JPEG, TIFF) are stored in a separate cloud imaging layer and cannot be reliably exported via tab32's standard export mechanisms. We recommend a separate imaging migration workflow coordinated with the practice's imaging hardware vendor.

Two-way text message history, appointment reminders, and e-form completion records live in tab32's patient engagement layer. We extract the metadata (dates, message direction, delivery status) but not message content, which is stored in a separate communication log not accessible via standard export.

Custom e-forms and intake documents created by the practice use practice-specific field configurations. We extract form response data and map it to the destination's form structure, flagging any conditional logic or required-field constraints that may differ between systems.