Migrate from Pulse Digital Clinic to HighLevel

Pulse patient records map directly to HighLevel contacts. Full name from Pulse is split into FirstName and LastName on the HighLevel contact. Gender, blood group, allergies, and chief complaint migrate as custom fields (custom_Gender, custom_BloodGroup, custom_Allergies, custom_ChiefComplaint). Original patient ID is preserved as custom_PulsePatientId for traceability and delta-run de-duplication.

Pulse appointment slots map to HighLevel Events (for calendar display with start/end times) and Tasks (for follow-up tracking). Appointment status maps via value-mapping: scheduled → Not Started, completed → Completed, cancelled → Cancelled, no-show → Deferred. Physician/doctor name migrates as a custom field (custom_AssignedPhysician) since HighLevel contacts do not have a native physician-assignment attribute.

Pulse clinic/company profile maps to HighLevel Company. Clinic name becomes Company Name, clinic address maps to the HighLevel address fields, phone maps to Phone, and the clinic website domain maps to the Website field. Multi-branch setups where Pulse stores parent-clinic and sub-clinic relationships require mapping via custom_BranchParentId custom fields on each Company record.

Pulse billing records have no native equivalent in HighLevel's standard object model. Bill amount, payment status, and outstanding balance migrate as custom fields on the Contact record (custom_BillAmount, custom_PaymentStatus, custom_OutstandingBalance). Practices that track billing per visit can alternatively model outstanding invoices as HighLevel Opportunities with zero monetary value and a custom status pick-list.

Pulse physician and staff records resolve to HighLevel user accounts by email match. Unmatched staff members are flagged before migration — the practice must invite them to HighLevel or assign their patient records to a fallback user. Physician names also migrate as custom_AssignedPhysician on appointment records so the assignment is preserved regardless of user account status.

Pulse patient categories or labels (e.g. 'VIP', 'Follow-up Required', 'Dental', 'Homeopathy') map to HighLevel Tags on the contact record. HighLevel supports multiple tags per contact, matching Pulse's label flexibility. Tags migrate as a string array and are applied to the corresponding contact during migration.

Pulse EMR notes and medical history stored per patient have no native HighLevel equivalent. These migrate as a long-text custom field (custom_EMRNotes) on the HighLevel contact. Practices with large note volumes may prefer to store a reference link or PDF attachment note rather than full text to avoid HighLevel field-length constraints.

Pulse prescription templates and the prescription records attached to patient visits have no direct HighLevel equivalent. We preserve prescription data as a custom_EMRNotes text field on the contact. Practices that need structured prescription records should rebuild document templates using HighLevel's Document feature and attach them to contacts post-migration.

Pulse patient attachments (lab reports, X-rays, ID documents) re-upload to HighLevel as contact attachments. HighLevel file size limits apply (25 MB per file). Inline images from Pulse notes are downloaded and rehosted. Files without a valid patient match are held in a staging area for manual assignment.

Pulse dashboard configurations and report settings do not have a migration path to HighLevel. The underlying data (patient counts, appointment volumes, billing totals) migrates into HighLevel contacts, tasks, and custom fields where it can be reported on using HighLevel's built-in reporting and Opportunities analytics. Report rebuilding is scoped separately.

Appointment reminder automations, WhatsApp notification triggers, and follow-up sequences built in Pulse are not transferable. We export workflow definitions as a written reference document (trigger types, action steps, conditions) so the practice's HighLevel admin can rebuild them as Workflow recipes. HighLevel's Workflow Builder supports the same trigger-action model but requires manual configuration.

Any Pulse custom objects (e.g. InsuranceProvider, ReferralSource) map to HighLevel Custom Objects via the HighLevel Custom Objects API. The custom object schema (field names, field types) must be pre-created in HighLevel before migration. N:N relationships between Pulse custom objects require junction custom objects in HighLevel — this is surfaced in the pre-migration schema plan.