Migrate from Quanum Practice Management to Salesforce Sales Cloud

Quanum patient records map directly to Salesforce Contacts using the patient's medical record number as an external identifier. First name, last name, date of birth, address, phone, and email transfer as standard Contact fields. The Quanum Patient_ID becomes Source_System_ID__c for deduplication in delta runs.

When the guarantor (responsible party) differs from the patient, the guarantor's name and address map to a Salesforce Account record. The Account record type is set to 'Practice' or 'Patient Guarantor' to distinguish it from commercial Account records. Patient Contacts are linked via AccountId lookup.

Quanum appointments contain provider name, appointment type, duration, and status. These map to Salesforce Events for scheduled visits with start/end times, or Tasks for unscheduled callbacks. Appointment status (Confirmed, Cancelled, No-Show) maps to Salesforce Task status or Event subject prefix for quick filtering.

Quanum stores insurance carrier, plan type, group number, and member ID per patient. We create a custom Insurance__c object with a lookup to Account (carrier) and to Contact (patient). Member_ID__c, Group_Number__c, Plan_Type__c, and Eligibility_Status__c are custom fields. Insurance carrier names load as Account records of type 'Insurance Carrier' first.

Quanum charge records, claim status, payment postings, and denial codes do not have a Salesforce standard equivalent. We create Billing_Claim__c with a lookup to Contact (patient), Account (guarantor), and Insurance__c (carrier). Fields include Claim_Number__c, Service_Date__c, Charge_Amount__c, Payment_Amount__c, Denial_Reason__c, and Status__c.

Quest Diagnostics lab orders attached to Quanum patients migrate to a custom Lab_Order__c object. The object links to Contact and includes Order_Date__c, Test_Code__c, Test_Name__c, Result_Value__c, Result_Date__c, and Result_Status__c. If Quest's Quanum Lab Services Manager API is active, we map the external lab order ID for traceability.

Quanum's referring provider list maps to Salesforce Contacts with a custom RecordType of 'Referring Provider'. Provider name, NPI number, specialty, address, and phone transfer as standard and custom Contact fields. The referring provider Contact is linked to the patient Contact via a custom Referring_Provider__c lookup on the patient Contact record.

Quanum exports patient Continuity of Care Documents as XML files. We download each CCDA, upload it as a Salesforce File (ContentVersion with FirstPublishLocationId pointing to the patient Contact), and store the original filename as a custom Content_Title__c field. This preserves the ONC-compliant clinical summary for reference without rebuilding it in Salesforce fields.

Quanum's practice or facility record maps to a Salesforce Account with a custom 'Facility' record type. Facility name, address, phone, and tax ID transfer as Account fields. Multiple locations create multiple Account records. Provider staff Contacts are associated to the relevant Facility Account via the AccountId field.

Quanum staff records lack email addresses in the standard export. We match staff by name against Salesforce Users if email is available, otherwise create Contact records with a custom 'Staff' record type. Staff Contacts without Salesforce User assignments receive a Staff_Role__c custom field and are flagged for manual user provisioning in Salesforce.

Clinical encounter notes from Quanum migrate as a custom Encounter__c object linked to Contact (patient) and Contact (provider). Fields include Encounter_Date__c, Chief_Complaint__c, Diagnosis_Codes__c (ICD-10), and Notes__c. If the note contains only free text with no structured data, it is stored as a Salesforce Note attached to the Contact.

Quanum prescription data (medication name, dosage, prescriber, date, pharmacy) migrates to a custom Prescription__c object with a lookup to Contact (patient) and Contact (prescriber). Fields include Medication_Name__c, Dosage__c, Frequency__c, Pharmacy__c, and Written_Date__c. Controlled substance details are stored in encrypted custom fields for HIPAA compliance.