Migrate from DGL Practice Manager to Odoo CRM

DGL patient demographics (name, date of birth, contact details, address) map directly to Odoo res.partner. We store the patient's NHS number or private health membership as a custom Char field since Odoo has no native NHS reference field. DGL's patient photo, if stored, is re-uploaded as an ir.attachment linked to the partner record.

DGL appointment slots have a practitioner, patient, slot type (initial, follow-up, procedure), start/end time, and booked/free status. We map to Odoo calendar.event with user_id = practitioner (resolved by email), partner_ids = patient, start/datetime from DGL slot times, and custom fields for slot_type and appointment_status. Odoo's kanban stage for calendar events is not used — the event records carry all slot metadata in custom fields.

DGL practitioners (consultants, secretaries, admin staff) map to Odoo res.users. Name, email, role, and specialty migrate. DGL's practitioner diary configuration is noted as a setup reference for Odoo calendar access rights — your Odoo admin assigns calendar visibility per user based on this mapping. Inactive practitioners become inactive Odoo users.

DGL invoices (patient invoices, insurer bills, NHS submissions) map to Odoo account.move with type='out_invoice'. Invoice number, date, amount, tax, and line items migrate. DGL's EDI submission reference attaches as a custom Char field on the account.move record. Status mapping: DGL submitted → Odoo posted; DGL paid → Odoo paid; DGL rejected → Odoo open with a note.

DGL insurer records map to Odoo res.partner with partner_type='company' and a custom insurer_reference field. The insurer's billing contact (email, address) migrates to the partner's contact records. Multiple insurer contacts per company map to multiple res.partner.contact records linked to the same parent company partner.

DGL clinical letters, reports, and dictated documents store file metadata (filename, author, date, patient link) but not the actual file binary in most DGL API exports. We migrate the metadata as documents.document records in Odoo with the original filename and author preserved. Your team re-uploads the actual document files to Odoo Documents post-migration using the metadata list as a reference guide.

DGL EDI insurance submissions (insurer ID, policy number, claim amount, status, submission date) have no Odoo native equivalent. We create x_dgl_edi_claim as a custom model in Odoo with fields mirroring DGL's EDI record: insurer_id, policy_number, claim_amount, claim_status, submission_date, and original_xml (stored as text for reference). Odoo's ir.actions.server can be configured to regenerate EDI submissions from this data.

DGL stores NHS service codes and billing codes per appointment or invoice. Odoo has no native NHS code field. We create a custom Char field (nhs_billing_code) on calendar.event and a selection field on account.move.line (billing_code_type) with the relevant code values. Your Odoo admin populates the pick-list values based on the NHS code set used in your DGL configuration.

DGL clinical notes and dictation references (author, date, patient, content snippet) migrate as Odoo mail.message records linked to the patient res.partner for audit trail continuity. The full dictated content, if exportable, stores as plain text in the message body. DGL's Microsoft Word letter template outputs are not portable — we provide a document mapping guide for your admin to recreate them in Odoo's report designer.

DGL stores insurer policy details per patient (policy number, coverage type, expiry, excess amount). Odoo has no native insurance policy object. We create x_dgl_insurance_policy as a custom model linked to res.partner (patient) with fields: policy_number, insurer_id, coverage_type, excess_amount, renewal_date, and status. This provides the audit trail for insurance billing even though EDI submissions are rebuilt separately.