Migrate from Phreesia to Pipedrive

Direct map. Phreesia patient record maps to Pipedrive Person with name, email, phone, and address fields carried over verbatim. Primary insurance carrier is resolved separately as an Organization and linked via Pipedrive's person-to-organization association. Original Phreesia patient ID preserved as Source_System_ID__c custom field for delta-run de-duplication.

Phreesia insurance carrier stored per patient maps to Pipedrive Organization representing the payer. Carrier name becomes Organization name, and the Person record links to it via OrganizationId. When multiple patients share a carrier, Pipedrive deduplicates to a single Organization record. Self-pay patients have no carrier and no Organization link.

Phreesia appointments become Pipedrive Activities with Type='Appointment' or Type='Call' depending on visit modality. Original appointment date and time map to Activity due_date and start times. Visit type (new patient, follow-up, telehealth) is stored as a custom field on the Activity since Pipedrive's native Activity model does not include visit-type categorization. Provider name maps to the assigned Pipedrive user on the Activity.

Phreesia consent records have no direct Pipedrive equivalent. We migrate consent_type (e.g., HIPAA, financial policy, treatment consent) as a custom pick-list field on Person, and consent_timestamp as a custom datetime field. Electronic signature data is not transferable in a standard CRM migration — the consent form itself must be re-executed in the destination system or stored as a linked document.

Every custom field from Phreesia's intake form builder becomes a Pipedrive custom field on the Person object. Field types map as follows: text → varchar, number → int, date → date, checkbox → boolean, dropdown → picklist. Phreesia's conditional logic and branching rules are not migratable — we document the form structure so the practice can rebuild conditional rules as Pipedrive Automations or Smart Docs.

Phreesia payment records (amount, status, method, card on file) have no native Pipedrive equivalent. Payment status and last payment amount migrate as custom fields on the Person record. If payments are tied to a specific treatment plan, the plan migrates as a Pipedrive Deal with payment amount as the deal value and payment status as a custom field. Pipedrive's built-in invoicing is not used — payment history is a reference field, not a transactional record.

Phreesia's real-time eligibility verification results (coverage status, copay, deductible remaining) are healthcare-specific and have no Pipedrive equivalent. We preserve the last eligibility check date and status as custom fields on Person for reference, but active eligibility checking requires a third-party integration like VerifyODE or Waystar in Pipedrive's ecosystem — not a migration carry-over.

Phreesia clinical screening responses (PHQ-9, SDOH, substance use, social determinants) are structured data that does not map to standard Pipedrive fields. We migrate discrete screening scores as numeric custom fields on Person and store the full screening response as a Note attached to the Person record. Clinical decision-support logic tied to screening results is not migratable and must be rebuilt outside Pipedrive.

Phreesia referral tracking (referring provider, facility, source channel) migrates as a custom field on Person identifying the referral type. When a referring provider or facility is named, we create a corresponding Pipedrive Organization record and link it to the Person — similar to the insurance carrier pattern. Anonymous digital referrals (website, Google, walk-in) are stored as custom field text values.

Phreesia staff who own patient records are resolved to Pipedrive Users by email match. Unmatched owners are flagged before migration — the practice must invite those users to Pipedrive or assign their records to a fallback owner. Inactive Phreesia staff are not migrated as Pipedrive users; their records are reassigned to the specified fallback.

Phreesia registration events (check-in time, kiosk used, self-service vs. staff-assisted) are healthcare-specific and map to a custom Activity field in Pipedrive. These are logged as Activity records with Type='Registration' and a custom field capturing the registration method. The original registration timestamp is preserved as the Activity due_date for reporting on no-show rates and check-in efficiency.

Phreesia's HL7 and FHIR integrations with Epic, Athena, Cerner, and other EHR systems are not migratable to Pipedrive. Pipedrive does not natively support HL7 feeds. Practices must select and configure a separate integration solution (e.g., Mirth Connect, 1547 Group) to reconnect EHR data flows post-migration. This is surfaced as a rebuild item in the migration plan.