Linkage resolution strategy

Based on linkage_analysis.csv and profiling report section 4.

DIRECT_CARECASE

• Use CareCaseCaseId on contact when valid in carecase_cases (referential integrity pass).
• Populate FactCareCase.SourceContactKey from SourceContactId when present.
• Orphan IDs (47): load contact fact with orphan_case_id_flag=1; do not join to case.

DIRECT_LEGENDARY

• Use LegendaryCareReferralId / LegendaryCareEncounterId on contact when populated.
• Facts load independently; optional link via SourceCareCallContactId on referral when present.

INFERRED_MATCH

Do not auto-promote to direct FK in facts.

1. Staging identifies candidate pairs: same PatientPseudoId, case OpenedDateTime within ±24h of ContactDateTime, no direct IDs.
2. Insert into BridgeCareCallInferredCase with inference_rule_id, confidence_score (demo: fixed 0.75).
3. Mart measures: report direct and inferred linkage counts separately.

AMBIGUOUS

1. Parse AmbiguousMatchIds (pipe-delimited) into BridgeCareCallReferralCandidate — one row per candidate.
2. No default winner; reporting uses primary candidate only after human mapping table (future) or highest ReferralDateTime proximity (documented assumption).

CALLBACK_DUPLICATE

• Preserve CallbackOfContactId on FactCareCallContact.
• Dedup policy for marts: count all contacts vs count distinct patient-day — human decision (see review pack).

NO_CASE

• No bridge rows; contact fact only.

CareCase without SourceContactId

• Load FactCareCase with null contact key.
• Set is_extract_inclusion_case from staging.
• Operational IUCS conversion metrics exclude these unless reviewer approves inclusion rule.