Member match configuration
SCE allows the configuration of multiple matching criteria via a series of decision tables to ensure that a unique member record is matched. The tables can be accessed by navigating to Configuration>Delegated rules via the left side menu in the portal.
The decision tables are under the Member match heading. The SCE provides configurations for the following areas:
- Search fields and criteria to support a match – This identifies the fields on the claim and member record that are used to support the primary and secondary searches.
- Fuzzy configuration – This identifies the configuration as to the degree of fuzziness that can be applied to each field used in the search and the prefix length of each field that needs to match
- Match tie breaker – When multiple members are matched via the search, the configuration of a tie breaker to see if a unique member from those matched can be found.
- Newborn and unwell child – Support for unenrolled newborn patients and situations where the newborn is unwell.
- Transplant recipient – Support for handling claims for recipients of transplants.
The SCE provides two configurations to support the fields used in the member search. The first is the Search property decision table. This decision table allows the addition (or removal) of search criteria in the Member search configuration decision table by allowing the addition/removal of the field name label and the property. The table can be accessed via Configuration->Delegated rules->Search property configuration in the portal.
As the member can have multiple previous names and potential nicknames stored in their record, the SCE uses a property (OtherName) to consolidate all the names stored for the member into a single page list for searching. If the member record only contains a single name, then this will be the only name available in that structure.
OtherName contains the following fields in the list each with any special characters removed:
- First name
- Middle name
- Last name
- Collective definition (concatenation of first name, middle name and last name separated by ‘!’)
The SCE member search functionality runs directly against the OtherName property for the name matching.
The second configuration is the member search decision table configuration. This table defines the fields that are required for each state based on the search type. The table can be accessed via Configuration->Delegated rules->Member search configuration in the portal.
The SCE has two searches; a primary search (“Primary with ID”), which always includes the submitted ID as a search criterion, and a secondary search (“Secondary without ID”), which does not include the ID. The secondary search is called if the primary search does not identify any matching records as detailed in the member match flow. Both primary and secondary search criteria are configurable by state using the member search configuration decision table above.
If no criteria are defined for a state, the decision table applies the matching criteria defined on the “otherwise” row as well as the global fuzziness and prefix length settings. SCE will iterate through the different types of searches until a match is found, no match is found, or multiple matches are found and respond appropriately.
The ability to configure matching criteria on a state-by-state basis allows compliance with state mandates requiring specific data elements for member matching.
The tables below detail the fields used in the configuration table:
Condition Field | Description |
State | Identifies the state to which the criterion applies. The state is sourced from the patient address received on the claim (Address1.State). |
Search type | For each state, both a primary and secondary search are configured. A primary search (“Primary with ID”) always includes the submitted ID as a search criterion and a secondary search (“Secondary without ID”) is called if the primary search fails to identify a unique record. |
The actions fields identify the weighting of the match, and which subscriber or patient fields on the claim must match the corresponding fields in the membership record to achieve a member match.
Actions Field | Description |
Weight | The weight column defines a total number that must be met or exceeded for SCE to consider the record a match. Each data element defined in the columns to the right of the “Weight” column must be defined as Mandatory, Optional or Ignore.
|
First name | The first name of the member |
Last name | The last name of the member |
Gender | The gender of the member |
Date of birth | The date of birth of the member |
Postal code | The zip or postal code of the member |
State | The address State of the member |
Configuration tips:
- The ID is always included and is not counted towards the defined weight in the “Primary with ID” search
- Each data element must be defined as Mandatory, Optional or Ignore
- Ensure that there are enough mandatory and optional data elements defined to meet the desired weight
Configuration example:
For the state of NY, you want the “Primary with ID” search to return a match when ID, Last Name, Date of Birth and either First name or Gender submitted on the claim are considered a match to the system of record.
You would configure the row as follows:
State: NY
Search type: “Primary with ID”
Weight: “3” (Keep in mind that the ID is considered included already and will not count towards the defined weight)
First name: “Optional”
Last name: “Mandatory”
Gender: “Optional”
Date of birth: “Mandatory”
Postal code: “Ignore”
State: “Ignore”
Bad configuration examples:
Using the scenario defined above (weight of 3), if you defined more than 3 fields as mandatory, the configuration would be invalid. Alternately, if you defined no mandatory fields, but less than 3 optional fields, the configuration would be invalid.
Fuzzy matchThe next three configurations identify the fuzziness and prefix length for each of the fields involved in the search.
Smart Claims Engine provides the ability to configure a degree of fuzziness to be applied to each data element used in the primary and secondary searches. Setting a fuzziness degree allows a preliminary match to occur even with the replacement, addition, or deletion of the specified number of characters. The introduction of fuzziness to the search is controlled through the Member fuzzy search settings. These settings enable fuzziness to be applied to the Primary or Secondary searches. To access the setting, navigate to Configuration>System settings and locate the Member fuzzy search settings.
The fuzziness can be set to On or Off for the primary and secondary fuzzy searches.
The degree of fuzziness can also be applied to each of the search fields. This is covered through the Fuzzy search configuration in the Member match delegated rules. In Pega the highest degree of fuzziness configurable is 2.
In the examples below, the City field is set to a fuzziness degree of 1. The search would return the result listed based on that setting.
Scenario | Search term | Search results include |
Substitute 1 character for another | Clearwoter | Clearwater |
Insertion of a new character | Clearwaters | Clearwater |
Deletion of a character | Clearater | Clearwater |
Transposition | Clearawter | Clearwater |
The final criteria supporting the fuzzy search is the Member search prefix configuration. This decision table allows the definition of the number of initial characters that must be an EXACT match between the submitted information and system of record to be considered in the member match logic. The fuzziness setting defined for the field would not be applied to the characters covered by the prefix length setting.
For example, if the prefix length for first name is set to 2, the first two characters of the first name submitted must match the first two characters of the first name in the system of record for SCE to consider the first name as a potential match. If any fuzziness setting applies to the first name field, it is applied to all the characters of the first name EXCEPT the first two.
Note: When member fuzzy search settings are Off, the prefix length configuration is ignored by SCE.
Member match tiebreaker settingsWhen multiple member records are identified by SCE during the member match routines, a tiebreaker can be configured and applied. The application of the tiebreaker is controlled in the System Settings. To access the settings, navigate to Configuration>System settings and locate the Member match tiebreaker settings.
The address tiebreaker compares the submitted member address to the address in the system of record. If a match is found that member record is selected for adjudication.
The address tiebreaker may be enabled for both the primary and secondary searches or for just one or the other.
The eligibility tiebreaker compares the earliest date of service on the claim to the eligibility spans of the matching member records. If a single active policy is found, SCE will select the member associated with that policy for adjudication. Note that this setting should be used cautiously as it may result in a “false positive”.
The eligibility tiebreaker may be enabled for both the primary and secondary searches or for just one or the other.
Newborn member configurationThe SCE provides the ability to match an unknown newborn member to the subscriber or mother’s policy for a defined period. To support this ability, the SCE provides three configurations. The first, the newborn state-wise days decision table configuration, allows the definition of the number of days newborn claims may be paid under the mother/subscriber’s policy before enrollment of the newborn is required for coverage. It further allows SCE to determine whether newborn claims may be paid under the subscriber (regardless of gender) or whether the claim must be paid under the mother’s policy. This configuration is found under Configuration->Delegated rules->Newborn state wise days configuration.
Newborn state-wise days decision table configuration allows the definition of the number of days newborn claims may be paid under the mother/subscriber’s policy before enrollment of the newborn is required for coverage. It further allows SCE to determine whether newborn claims may be paid under the subscriber (regardless of gender) or whether the claim must be paid under the mother’s policy.
If the configuration defines mother, SCE will check the subscriber gender billed on the claim
- If female, SCE will assume the subscriber is the mother of the newborn and adjudicate the newborn claim under the subscriber’s plan.
- If male, SCE will raise event code SMM-0007 (Newborn requires mother’s policy)
The second configuration enables the SCE to set an event code (SMM-0005, Patient is newborn) on every claim meeting the criteria in the state-wise days table; the event may be configured to suspend the claims for further review.
To access the setting, navigate to Configuration>System settings and locate the Newborn configuration settings. “On” instructs SCE to set the event code on every claim meeting the criteria.
The final configuration identifies if a newborn child meets the criteria for an unwell child. The decision table uses revenue and diagnosis codes to identify the unwell child. This table can be extended as necessary. The unwell child configuration decision table allows SCE to set an event code (Unwell Newborn, SMM-0006) on claims for patients meeting the defined criteria. This configuration is found under Configuration->Delegated rules->Unwell child configuration.
Users can choose to set an event code (Transplant Donor Claim, SMM-0008) for all claims billed with an individual relationship code of 39 (organ donor) or 40 (cadaver donor). This enables a client to manually review all these claims or hold them for external adjudication and management. To access the setting, navigate to Configuration>System settings and locate the Transplant configuration settings. “On” instructs SCE to set the event code on the claim.
Extending the member match fieldsIf the member search fields need to be extended to add other search properties, the following steps are required:
- Add the new referenced field on the Search property decision table.
- These fields are referenced from the PegaHC-Data-Party-Member class
- Extend the Member search decision table to add this new field in the actions columns with mandatory, optional or ignore
- Add a row for the field and fuzziness search configuration.
- If needed, add a prefix length setting for the field.
- Flush data page D_MemberSearchConfig
- Add the property to Custom Search Property rule type for PegaHC-Data-Party-Member
- Reindex Data class “PegaHC-Data-Party-Member”
Previous topic Member match module Next topic Member validation module