59.3.1Matching Logic

59.3.1.1Overview

The patient matching functionality enables payers to accurately identify and match member records between systems during Payer-to-Payer data exchanges. This includes both single-member matching via $member-match and multi-member matching via $bulk-member-match operations.

59.3.1.2Default Matching Logic

By default, Smile executes very simple matching logic not suitable for production. It is simply intended to support testing of the operation.

Presently, only family name and birthdate from the MemberPatient parameter are used as matching criteria. The operation will return a success response only if there is one match against a Patient resource.

59.3.2$member-match: Single Member Match

Smile CDR supports the $member-match operation as defined in the HRex implementation guide.

The $member-match operation is a component of single record exchange and a required precursor to any subsequent record request via $export. It enables a requesting payer to submit member demographic and coverage information for one member to a source payer to identify matching members within their system. A successful operation returns record identifiers for matched members that can be used to request an access token and export data.

59.3.3$bulk-member-match: Multi-Member Match

Smile CDR supports the $bulk-member-match operation as defined in version 2.1.0 - STU1 of the Da Vinci Payer-to-Payer Data Exchange Implementation Guide (PDex IG).

The $bulk-member-match operation is a crucial component of multi-member record exchange and a required precursor to any subsequent record request via $davinci-data-export. It enables a requesting payer to submit a batch of member demographic and coverage information to a source payer to identify matching members within their system.

59.3.4Customizing Matching Logic

To make the $member-match operation adapt to business requirements unique to each customer, the System-to-System Data Exchange Module supports custom matching scripts that can be defined by clients in the form of JavaScript.

59.3.4.1Custom Script Template

The function signature must match the following template, where the first parameter contains the memberPatient and coverageToMatch parameters to the $member-match operation, and the second parameter contains details about the request that is about to be processed:

function matchPatient(theMemberMatchRequest, theRequestDetails) {
    // your implementation goes here
}

The function will return:

• Patient if a matching patient is found
• null if not found

Note: If null is returned, then the system will throw a 422 Unprocessable entity stating that the matching Patient is not found.

59.3.4.2Configuration for Matching

59.3.5Implementation Considerations

59.3.5.1Key Questions for Responding Payers

When implementing matching logic as a responding payer, consider:

• What matching rules will we implement for identifying the correct member record to share?
• How will we handle multiple potential matches?
• What level of confidence is required for a successful match?
• How will we handle partial matches or ambiguous results?

59.3.5.2Business Identifier Management

For multi-member matching with $bulk-member-match, it is essential to associate the group with a unique business identifier. This identifier allows Smile CDR to enforce fine-grained access control, ensuring that a client system can only access the data for which it has explicit permissions.