Migrate from Phreesia to HighLevel

Phreesia patients map directly to HighLevel Contacts. Demographics including name, DOB, address, phone, and email transfer as standard Contact fields. The original Phreesia patient ID is preserved in a custom field Source_System_ID__c for traceability and future delta runs. Multi-location patients are merged on email address uniqueness before import to prevent duplicate contact records in HighLevel.

Phreesia emergency contact details are preserved by mapping them to custom fields on the primary Contact record in HighLevel: Emergency_Contact_Name__c, Emergency_Contact_Phone__c, and Emergency_Contact_Relationship__c. Since HighLevel lacks a native emergency contact object or related-list structure, these fields are flattened directly onto the Contact, keeping all contact details accessible in one place for front-office staff.

Phreesia insurance fields (payer name, member ID, group number, subscriber relationship) map to custom text fields on the HighLevel Contact. Insurance verification status from Phreesia (eligible, not eligible, pending) maps to a custom pick-list field Insurance_Verification_Status__c. Note that HighLevel has no native insurance verification engine — this data is preserved for reference only.

Phreesia appointment records migrate as HighLevel Tasks. The appointment date and time become the Task due date, the appointment type becomes the Task subject, and provider notes migrate as Task descriptions. Appointment status (scheduled, completed, no-show, cancelled) is preserved in a custom pick-list field Appointment_Status__c.

Phreesia provider names are resolved by email match against HighLevel users. If a matching HighLevel user exists, the appointment Task is assigned to that user. If no match is found, the provider name is stored in a custom field Provider_Name__c and the Task is assigned to a migration fallback owner for manual routing.

Phreesia intake form responses (clinical screenings, consent signatures, social history) are evaluated for cardinality. Low-cardinality responses (yes/no, single-select) become custom pick-list fields on Contact. High-cardinality or free-text responses are grouped into a HighLevel Custom Object named Intake_Responses with a lookup relationship to the Contact record.

Phreesia consent records (HIPAA agreement, financial policy, treatment consents) map to a HighLevel Custom Object named Consent_Records. Each record stores the consent type, consent timestamp, and consent method (electronic signature, verbal) as custom fields. A lookup relationship links each Consent_Record to the corresponding Contact.

Phreesia payment transactions (amount, date, method, status) are aggregated into a summary on the Contact record (Total_Payments_Received__c, Last_Payment_Date__c) and, if linked to a service agreement, into a HighLevel Opportunity representing the client account. Individual transaction history is stored in a Payment_History__c custom field as JSON-formatted text for reference.

Phreesia eligibility verification results (payer response, coverage details, copay amount) do not have a native HighLevel equivalent. These are migrated into a Custom Object named Insurance_Eligibility_Checks linked to the Contact, storing payer name, check date, coverage status, and copay/coinsurance amounts as custom fields.

Phreesia multi-location configurations map to a Location__c custom pick-list field on Contact. Additionally, a HighLevel Tag named after each location (e.g., 'Location: Downtown Clinic') is applied to all contacts from that facility, enabling pipeline and reporting segmentation by location without requiring a separate object.

Phreesia referral source data (how the patient heard about the practice) maps to a custom pick-list field Referral_Source__c on Contact. Where Phreesia stores referring provider or facility names, those are stored as text in Referring_Provider__c and a corresponding Tag is applied for segmentation in HighLevel campaigns.