Sam flagged that treatment call notes and call summaries should contain provider indicators, and questioned why an OriginalPrimaryTreatment... column appeared in the review files.
I live-validated the Litify metadata and reviewed the related call and activity objects.
There is only one Matter field for the primary provider:
litify_pm__Matter__cPrimary_Treatment_Provider__cPrimary Treatment ProviderLookup(Party)AccountPrimary_Treatment_Provider__rA live FieldDefinition search found no Matter field with Original in the API name. The OriginalPrimaryTreatmentProviderId and OriginalPrimaryTreatmentProviderName columns were generated only by the audit CSV from the first backfill script. They mean the pre-update value used for comparison and rollback. Future scripts should rename those columns to PreUpdatePrimaryTreatmentProviderId and PreUpdatePrimaryTreatmentProviderName so the report does not imply Litify has two provider fields.
Treatment-call and call-summary data can be mined from these source lanes:
SAIL_Call_Log__c, linked to Matter by Matter__c, with Call_Notes__c, Summary__c, and Next_Steps__c.Dialpad__Call_Log__c, linked to Matter by Matter__c, with Dialpad__Ai_Summary_RichText__c, Dialpad__Ai_Action_Items_RichText__c, Dialpad__Comments__c, and Dialpad__CallDispositionNotes__c.Task, where treatment-call activity appears under subjects such as Treatment Status Updated and Call: Client - Treatment Status Attempted; provider indicators are usually in Description.The Task lane looks strongest for the next pass. Live samples showed direct provider statements such as going to ExactaCare, Aptiva 2x per week, KORT PT in Brooks, Total Health chiro, scheduling with AllyMed, and other treatment-status updates.
This should be handled as a separate parser pass before any write, because the language can mean different things: active treatment, scheduled future appointment, referral/recommendation, released/MMI, or a nonspecific provider category. Those should not all be treated equally.