SfSkills Domains Docs GitHub

Home / data / clinical-data-quality

clinical-data-quality

Use this skill when configuring duplicate detection for Health Cloud patient records, managing Person Account merges in a clinical org, or designing pre-merge clinical record reassignment strategies. Trigger keywords:. NOT for generic Salesforce data quality or standard deduplication outside Health Cloud — use data/large-scale-deduplication.

Open the skill folder on GitHub

Clinical Data Quality

Use this skill when working with duplicate patient detection, Person Account merges, or clinical record integrity in a Salesforce Health Cloud org. It activates whenever a practitioner needs to configure Duplicate/Matching Rules for patients, perform Account merges while preserving clinical data, or evaluate MPI alternatives.

Before Starting

Gather this context before working on anything in this domain:

Core Concepts

No Native Master Patient Index (MPI)

Health Cloud does not ship with a native MPI. There is no out-of-the-box enterprise patient identity resolution engine. Duplicate detection relies entirely on standard Salesforce Duplicate Management: Duplicate Rules scoped to the Account object (which covers Person Accounts) backed by fuzzy or exact Matching Rules on fields such as FirstName, LastName, BirthDate, and SSN-equivalent custom fields. For healthcare organizations at enterprise scale or with complex identity-matching requirements (probabilistic matching, cross-system record linkage), a third-party ISV — such as Veeva, ReltioConnect, or Informatica MDM for Salesforce — is the only path to true MPI capability.

Person Account Merge Is Account Merge, Not Contact Merge

Person Accounts are Accounts with IsPersonAccount = true. The merge flow for Person Accounts is the Account merge flow, not the Contact merge flow. Attempting to invoke a Contact merge on the underlying Contact record of a Person Account is unsupported and will produce errors. The standard Salesforce UI (and the Merge Accounts API) merges exactly two Account records at a time: you select a master record, and the losing record is deleted after related records are reparented. This two-at-a-time constraint is a hard platform limit for the standard merge action.

Clinical Records Are NOT Automatically Reparented on Merge

This is the highest-risk behavior in Health Cloud deduplication work. When two Person Account records are merged, standard Salesforce reparenting logic moves related records that belong to the winning record. However, Health Cloud clinical objects — including EpisodeOfCare, PatientMedication, ClinicalEncounter, and custom objects with explicit Account lookup fields — are not automatically reparented. They remain associated with the losing (deleted) Account and become orphaned records. Orphaned clinical records are not surfaced on the winning patient's timeline, care plan, or clinical summary, creating silent patient data loss that is difficult to detect post-merge without explicit audit queries.

Common Patterns

Pattern 1: Configure Matching and Duplicate Rules for Person Account Patient Detection

When to use: Every Health Cloud org that stores patient records should have at least one Matching Rule and one Duplicate Rule scoped to the Account object to detect potential duplicates at record creation time.

How it works:

  1. Navigate to Setup > Duplicate Management > Matching Rules.
  2. Create a new Matching Rule on the Account object (not Contact — Person Account deduplication runs on Account).
  3. Add match criteria on FirstName, LastName, PersonBirthdate, and any identity field (e.g., MedicalRecordNumber__c). Use Fuzzy matching for name fields to catch typos. Use Exact matching for identifier fields.
  4. Activate the Matching Rule.
  5. Navigate to Setup > Duplicate Management > Duplicate Rules.
  6. Create a Duplicate Rule on Account, reference the Matching Rule, and set the action for matching records to Alert (not Block) during the initial rollout to avoid disrupting intake workflows. Switch to Block after validating match quality.
  7. Test by creating two Person Account records with overlapping fields and confirming the duplicate alert fires.

Why not the alternative: Applying a Duplicate Rule to the Contact object instead of Account does not cover Person Accounts. Person Account deduplication must be targeted at Account.

Pattern 2: Pre-Merge Clinical Record Reassignment via Apex Batch

When to use: Before merging any two Patient (Person Account) records, reassign all clinical records from the losing account to the winning account. This must happen before the merge DML — not after — because after the merge the losing Account ID no longer exists.

How it works:

  1. Identify all clinical objects with Account/Patient lookups (see references/examples.md for a full list).
  2. Write a pre-merge Apex batch that queries each clinical object for records pointing to the losing Account ID and updates them to point to the winning Account ID.
  3. Call the batch synchronously (or chain it) before invoking the merge DML statement.
  4. After batch completion, execute merge masterAccount duplicateAccount; in Apex.
  5. Run post-merge audit queries to confirm zero records remain on the deleted Account ID.

Why not the alternative: Performing the merge first and trying to reassign clinical records afterward is not possible — the losing Account record no longer exists after merge, and its ID is tombstoned. Queries against the deleted Account ID will return no rows.

Decision Guidance

SituationRecommended ApproachReason
Small org, low duplicate volume, single source of truthNative Duplicate Rules + Matching Rules on AccountSufficient for controlled intake; no ISV cost
Enterprise scale, multi-source patient data, probabilistic matching neededThird-party MPI ISV (ReltioConnect, Veeva, Informatica)Native rules only support field-level exact/fuzzy; no cross-system record linkage
Merging 2 known duplicates interactivelyStandard Account Merge UI or Apex merge DMLSupported path for Person Accounts
Bulk merge of hundreds of duplicate pairsApex Batch with pre-reassignment loop + merge DML pairsOnly way to handle volume; two-at-a-time limit applies per DML call
Clinical records already orphaned post-mergeApex data fix script querying by known losing Account IDsNo platform-native fix; must reassign via code

Step-by-step instructions for an AI agent or practitioner working on this task:

  1. Identify clinical objects in scope. Query the org schema for all objects that have a lookup to Account (or a field named PatientId, MemberId, or IndividualId). Include Health Cloud standard objects: EpisodeOfCare, PatientMedication, ClinicalEncounter, CareObservation, CoveredBenefit, and any custom objects. This list drives the pre-merge reassignment batch.
  2. Configure Duplicate and Matching Rules on Account. Build at minimum one Matching Rule on Account covering FirstName, LastName, and PersonBirthdate. Attach a Duplicate Rule set to Alert mode. Activate both. Do NOT target the Contact object for Person Account deduplication.
  3. Build and test the pre-merge clinical record reassignment batch. The batch must accept a losing Account ID and a winning Account ID, query each clinical object in scope, and bulk-update the lookup fields before merge. Test in a sandbox with realistic patient data including all clinical object types.
  4. Execute merge in the correct order. Run pre-merge reassignment batch first — confirm zero errors and zero remaining records on losing Account — then execute the Account merge DML. Never reverse this order.
  5. Run post-merge audit queries. For each clinical object, confirm record count on the winning Account equals the expected sum of both pre-merge counts. If any discrepancy exists, investigate before releasing the patient record as clean.

Review Checklist

Run through these before marking work in this area complete:

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

  1. Clinical records orphaned silently on merge — Health Cloud clinical objects (EpisodeOfCare, PatientMedication, ClinicalEncounter) are NOT reparented when Person Accounts are merged. They remain on the deleted Account ID and disappear from the winning patient's record permanently unless explicitly reassigned before the merge DML executes.
  2. Person Account merge is two-at-a-time only — The standard Salesforce merge operation (UI and Apex merge DML) merges exactly two Account records per call. There is no bulk merge API. Attempting to merge three-way or pass a list of duplicates to a single merge call will throw a compile or runtime error.
  3. Duplicate Rules on Contact do not cover Person Accounts — Person Accounts are hybrid records. Their deduplication must be configured on the Account object, not the Contact object. A practitioner who creates a Contact Duplicate Rule expecting it to catch duplicate Person Account patients will find it has no effect.

Output Artifacts

ArtifactDescription
Matching Rule + Duplicate Rule configurationAccount-scoped matching with fuzzy name + exact identifier fields, set to Alert mode for initial rollout
Pre-merge clinical record reassignment batchApex batch class that accepts losing/winning Account IDs and reassigns all clinical object records before merge
Post-merge audit SOQL queriesPer-object queries to confirm zero orphaned records after a merge operation

Package files