Migrate from Henry Schein One to Odoo CRM

Henry Schein One patient records map directly to Odoo res.partner. Patient name, date of birth, contact information, address, and emergency contact map as-is. Provider assignment is stored as a custom partner field (x_provider_id) pointing to the treating provider's partner record. Multi-location patients get a single partner record with branch stored in a custom field.

Dentrix provider records (dentist, hygienist, office manager) migrate as Odoo res.partner records with a boolean custom field x_is_provider set to True. Provider license numbers (state-specific, e.g., NPI in the US) are stored as x_npi_number custom char fields. Provider specialty maps to res.partner function (e.g., 'Dentist', 'Hygienist').

Scheduled appointments in Dentrix Ascend become Odoo calendar.event records linked to the patient res.partner. The appointment status (confirmed, completed, no-show, cancelled) maps to a custom selection field x_appointment_status on the event. Future confirmed appointments also generate a crm.lead opportunity record with stage set to 'New' and a note referencing the appointment date, so the pipeline reflects upcoming patient activity.

Dentrix treatment plans — which list proposed procedures with CDT codes, surfaces, teeth involved, and fee estimates — map to Odoo sale.order (quotation) records. Each line item in the treatment plan becomes a sale.order.line with the CDT code stored in x_cdt_code and surfaces/tooth data in x_surface and x_tooth_number custom fields on the line. Treatment plan status (proposed, accepted, completed) maps to sale.order state.

Henry Schein One stores insurance plan name, group number, subscriber ID, and employer information per patient ledger. These have no native Odoo equivalent — we create four custom char fields on res.partner: x_insurance_plan_id, x_group_number, x_subscriber_id, x_employer_name. EDI eligibility status (active/inactive/pending) maps to a selection field x_edi_eligibility_status. Insurance EDI re-enrollment must be completed post-migration with your EDI clearinghouse.

Progress notes and clinical observations stored in Dentrix (free-text, per-visit) migrate as ir.attachment records linked to the patient res.partner, with the note body stored as the attachment description. We extract structured fields (chief complaint, diagnosis, treatment rendered) into custom char fields x_chief_complaint and x_diagnosis_code on the partner record. Plain-text notes are attached as .txt files. Rich-text formatting may not survive the round-trip.

Periodontal chart data — probing depths, recession measurements, BOP flags per tooth — has no Odoo native equivalent. We extract the most recent perio chart summary (e.g., 'Generalized Stage II Periodontitis') as a custom selection field x_perio_summary on res.partner and attach the full perio chart export as a PDF ir.attachment. Historical perio data is preserved but not queryable in Odoo's standard search.

Multi-location Dentrix setups store practice locations as separate databases or location codes. We map each location to an Odoo res.company record with the practice name, address, and phone. Provider assignments to locations are preserved via x_location_id custom field on the provider's res.partner record. For Odoo Community (no multi-company), we use a single company with x_location_id as a selection field on partners.

If the Henry Schein One setup includes supply inventory or in-office product records (used in OmsVision or DSO configurations), these map to Odoo product.product with type='product'. Unit of measure, SKU, and unit cost map directly. Restocking thresholds and reorder rules map as Odoo product_rule records.

Historical ledger balances (patient account balance in Dentrix) do not map to Odoo accounting (which is invoice-centric). We set the patient's opening balance as a custom decimal field x_account_balance on res.partner. The balance is for reference only — actual accounting records (invoices, payments) migrate separately under the Odoo Accounting app if included in scope. Open ledger items are flagged for manual reconciliation post-migration.

Oral surgery and specialty practices using OMSVision track lab cases and specialist referrals. Each lab case becomes a crm.lead with a linked project.task (created via Odoo's crm_project module). Case status (pending, in-lab, returned, referred) maps to the task stage. Referring provider information migrates as a separate res.partner contact with x_is_referring_provider set to True.

Henry Schein One automated recall workflows (hygiene recall, treatment follow-up, appointment reminder sequences) are platform-native automation logic that cannot be extracted as data. We export a CSV listing every active recall rule — trigger conditions, intervals, message templates — as a rebuild reference for Odoo's CRM automation studio. The rebuild is a separate engagement; we do not migrate the automation logic itself.