Migrate from Zedmed to Twenty CRM

Clinical data has no native CRM equivalent — custom objects are mandatory

Zedmed stores clinical encounters, e-prescriptions, referral letters, and investigation results (pathology, imaging) with structured clinical metadata that Twenty CRM's standard People, Companies, and Opportunities objects cannot represent natively. FlitStack creates ClinicalEncounters, Prescriptions, Referrals, and InvestigationResults custom objects in Twenty's Settings → Data Model before importing data. This requires upfront planning: custom fields must exist before CSV import, and your team needs to configure field types (select, text, date, number) for each clinical property. Clinical notes with free-text formatting are stored as long-text fields — formatting from Zedmed's structured encounter records does not carry over as structured data.

Appointment records require a custom object — not an Opportunity

Zedmed appointments have appointment type, status, practitioner, date/time, duration, location, specialty, and clinical notes. Twenty CRM has no native appointment or scheduling object. We represent Zedmed appointments as a PatientAppointments custom object with fields for appointment type (New Patient, Standard, Care Plan), status (Booked, Attended, Did Not Attend, Cancelled), date, start/end time, duration in minutes, practitioner relation, location, and notes. The object links to the patient People record via a relation field. Each appointment links to the practitioner via a separate relation to the practitioner People record — not the standard Opportunity contact role model.

Billing items have no native equivalent in Twenty CRM

Zedmed's billing model integrates with Medicare Online claiming, DVA, WorkCover, TAC, and private health funds, tracking MBS item numbers, fee schedules (Medicare/DVA/private), payment status, and claiming history (paid, unpaid, bulk billed, patient billed). Twenty CRM has no native billing or invoice module. A custom BillingItems object is required, with fields for invoice number, MBS item number, Medicare fee, private fee, payment status, claim status, and payer type. FlitStack migrates billing history as read-only records for audit continuity. New billing entries must be created manually or via custom development post-migration.

Zedmed's export mechanisms are not API-first — data extraction requires direct database access or manual export

Zedmed's architecture is not designed around a public REST or GraphQL API for bulk data extraction. Export typically requires direct access to Zedmed's database (for on-premise deployments) or manual CSV exports through the Zedmed interface. On-premise Zedmed installations expose the underlying SQL Server or PostgreSQL database directly, which allows FlitStack to run structured SELECT queries. Cloud Zedmed instances may require the Zedmed team to provide a data export, and the Zedmed v35 migration documentation suggests support-assisted exports are the primary path. This adds time and coordination to the migration that API-first platforms do not require.

Australian healthcare-specific fields (Medicare/DVA) need custom fields in Twenty CRM

Zedmed's data model includes Medicare numbers (MBS reference number + individual number), DVA file numbers, and healthcare identifiers (IHI) used in Australian healthcare claiming. Twenty CRM has no native Medicare or DVA field — these must be created as custom text fields on the People object before migration. Medicare number format requires concatenation of reference number and individual number from separate Zedmed fields. DVA number field structure is different from Medicare. Practices need to decide whether inactive patient records (marked as inactive in Zedmed) are imported as inactive People records or archived separately.