Skip to main content
Version: v1

Source Code Matching in Customer Identification

As part of customer identification logic, there are some use cases where we search with search_keys in EIMP, which may return data from any source system. This can result in creating enterprise users from mixed-identity service data (e.g., multiple members sharing the same policy number or member ID).

Data Accuracy & Source Code Matching​

To improve data accuracy and resolve ambiguities (such as when multiple wallets are found), matching the source code against EIMP (Enterprise Identity Management Platform) is recommended. This approach helps ensure the correct wallet is associated with the correct customer.

What is Source Code?​

Source Code

In the context of CCG and EIMP, source code is a unique identifier that represents the origin or system from which a particular piece of customer data (such as a member ID or policy number) was issued. It is used to distinguish between similar identifiers that may exist across different systems, lines of business, or data sources.

For example, two different insurance providers might issue the same policy number to different individuals, but each will have a distinct source code indicating its origin.

Key Points about Source Code​

  • Prevents identity collisions and data mismatches when multiple systems use overlapping identifier formats.
  • Critical for accurate customer matching, especially in healthcare and insurance, where members may share policy numbers or member IDs across different payers or lines of business.
  • Typically provided by the merchant or fetched by CCG based on other identifiers (like groupId, patientId, etc.).
  • Ensures that only records from the same origin are considered for wallet or identity resolution, reducing the risk of mixed-identity data.

Example​

policyNumber = 0215825 with sourceCode = CDB_CS (Care Database, Commercial Segment)
policyNumber = 0215825 with sourceCode = ABC (Another payer or system)

In this case, even though the policy number is the same, the source code ensures that only the correct record is matched and returned.

Note: Multiple records even after source code matching should result in an error.

Why Source Code Matching?​

  • Narrow Search Results: Combining source code with other identifiers (like groupId, patientId) narrows down the search, increasing the likelihood of returning the right wallet to the right customer.
  • Enterprise Settings Driven: Source code matching can be configured and driven through enterprise-level settings for flexibility and control.

Implementation Considerations​

1. Merchant-Driven Source Code Matching​

Approach 1: Source Code as Request Parameter​

The merchant, who knows their customer and the source system, can include the source code in the customer object sent to CCG. The source code can be made a parameter under metadata as a mandatory or optional param based on merchant requirements.

Why is the source code in the request parameter preferred?​
  • Source code is context-dependent and can differ for each customer or transaction. By embedding the source code in the request, we ensure that the most precise and pertinent value is supplied for every operation. This practice accurately reflects the true origin of the identifier and diminishes the risk of mismatches or ambiguities.

Approach 2: Static Source Code in Enterprise Settings​

Merchants with one or two source codes associated in their system can request CCG to configure it with precedence.

For Example: UHC Community Plan (Michigan) and UnitedHealthcare IFP (Non-Michigan) in Production

2. CCG Fetching Source Code​

CCG attempts to infer or match the source code internally, which can simplify onboarding but may lead to incorrect matches if business context is missing.

Scenario 1: One record with Source Code from Same Origin​

merchant sends customer request with subcriberId: 123 and dependentCode: 345

  • Original Customer : subcriberId: 123 and dependentCode: 345 WITH source_code as UMR

Scenario 2: One record with Source Code from different Origin​

merchant sends customer request with subcriberId: 123 and dependentCode: 345

  • Original Customer : subcriberId: 123 with source code as CSP_FACETS and dependentCode: 345 WITH source_code as UMR

⚠️ OutCome: Customer is accessing wrong wallet

Pros and Cons of Merchant-Driven vs. CCG-Driven Source Code Matching​

Merchant-Driven Source Code Matching​

Pros​

  • Merchants have the most context about their own data and business rules, leading to more accurate and intentional source code assignment.
  • Reduces ambiguity, as the merchant can ensure the correct source code is sent with each request.
  • Easier to support merchant-specific workflows and customizations.
  • Less processing overhead for CCG, as validation is performed upstream.

Cons​

  • Merchants need to update the integration to send the source code parameter as part of the request.

CCG-Driven Source Code Matching​

Pros​

  • Reduces the burden on merchants, simplifying integration and reducing onboarding friction.

Cons​

  • CCG may lack full business context, increasing the risk of incorrect matches if data is ambiguous or incomplete.
  • May require additional data or configuration from merchants to enable accurate matching.

While having CCG fetch and match source code internally can centralize logic and reduce merchant integration complexity, it introduces several scalability considerations:

  • This approach may require CCG to process large volumes of data and perform additional lookups, potentially impacting performance and maintainability.

Summary​

  • Merchant-driven matching offers flexibility and accuracy for merchants with strong data governance but increases integration complexity.
  • CCG-driven matching provides ease of integration but less accurate without full business context.

Recommendations for Choosing a Source Code Matching Approach​

When deciding between merchant-driven, CCG-driven, or a hybrid approach for source code matching, consider the following:

Approach 1: Merchant-Driven Source Code Matching (Preferred)

Merchants are responsible for providing the correct source code with each request. This approach ensures the highest data quality and leverages the merchant's business knowledge.

  • Ensures the highest data quality and leverages the merchant's business knowledge.
  • CCG will validate the provided source code but will not attempt to infer or guess it.
  • Merchants should be supported with clear documentation, onboarding, and technical guidance to update their integration logic.
Approach 2: CCG-Driven Source Code Matching (Not Recommended)

CCG-driven source code inference or matching leads to the risk of incorrect matches and lack of business context. This approach should only be considered as a last resort.

  • CCG may lack full business context, increasing the risk of incorrect matches if data is ambiguous or incomplete.
  • May require additional data or configuration from merchants to enable accurate matching.

Scenarios Where CCG-Driven Matching Falls Short​

  1. Multi-LOB Merchants: For merchants operating across multiple lines of business (LOBs) where the same identifiers might be used in different contexts.

    • Example: A healthcare organization operating both Medicare and Commercial plans might use similar member IDs across both lines, but they represent different members.

  2. Multiple System Integrations: When merchants use multiple backend systems with overlapping identifier schemes.

    • Example: After a merger or acquisition, a merchant might have two different claims systems with overlapping policy numbers.

  3. High-Volume Transaction Processing: In high-throughput environments where performance degradation from additional lookups could impact user experience.

    • Example: A large provider portal processing thousands of eligibility checks per minute would face significant latency if CCG needed to perform source code inference for each transaction.
Approach 3: Hybrid Approach - Merchant driven with Static source code configured in enterprise settings (Transitional)
  • Configure the source code in enterprise settings with precedence (CCG supports composite match).
  • This approach is preferred only if merchant has customers from one or two source code

For Example:

  • Example 1:
    • Policy number can be configured with “ABC” source code
    • Group Number can be configured with “CDE” source code
    • Use Case: When a member has different policy numbers for different services (e.g., dental and vision), but the group number remains constant.
  • Example 2:
    • Policy number can be configured with “ABC” source code
    • Group Number can be configured with “ABC” source code
    • Use Case: When all services for a member are under the same policy, and the source code is uniform across the board.