Automation of the Duplicate Primary Payer (DPP) Process

20.5.1—Automation of the Duplicate Primary Payer (DPP) Process (Rev. 12438; Issued: 01-04-24; Effective: 02-06-24; Implementation: 02-06-24) As described in Section 20.5, prior to the automation of the DPP process, the A/B MACs and DME MACs handled DPPs manually. Through this process, one or both of the Medicare Secondary Payer (MSP) Contractors mailed a package of information that demonstrated a DPP situation. If the A/B MAC or DME MAC received enough detailed information about the primary payer’s action taken on various claims, the A/B MAC or DME MAC initiated DPP adjustments to recover the Medicare primary payment from the provider. To realize greater efficiencies in this process, CMS decided to automate the DPP process. Through the automated DPP process, which CMS implemented on March 13, 2023, two of the MSP Contractors within the Coordination of Benefits & Recovery (COB&R) program enter information from the primary payer’s explanation of benefits or remittance advices or other payment remittances into the Benefits Coordination and Recovery System (BCRS). The information (i.e., required data elements) that the Contractors enter into BCRS will normally result in one of two types of Health Utilization Duplicate Primary Payment (HUDP) transactions that the COB&R systems Contractor will create: one that contains a Claims Processing Indicator value of “F” (primarily for a non-group health plan (NGHP)transaction) or one that contains a Claims Processing Indicator value of “S” (for a Group Health Plan (GHP) transaction). If, for example, the information for an NGHP transaction that one of the COB&R Contractors enters is very limited, such as the beneficiary name (surname and first name), MSP Insurance Type Code, date of incident, and diagnosis code, the COB&R systems Contractor will build a HUDP transaction with the Claims Processing Indicator set to “F.” By contrast, the information for a GHP transaction that one of the COB&R Contractors enters may be very comprehensive, providing enough of the required claims data to enable the shared system maintainer representing an A/B MAC or DME MAC to create and complete a DPP secondary claim adjustment. Under this scenario, the COB&R systems Contractor will build a HUDP transaction with the Claims Processing Indicator set to “S.” Initiation of the Automated DPP Process Following the creation of the HUDP file containing various DPP records for multiple beneficiaries and case types, the COB&R systems Contractor shall transmit the file to the Common Working File (CWF). This action could occur on a daily basis. CWF shall review the incoming HUDP to determine if the Health Insurance Claim Number (HICN), A/B MAC or DME MAC Number, MSP Type Code, Claims Processing Indicator, and Claim-From Date and Claim-Through Date (also known as Dates of Service (DOS)) are present and valid. CWF shall also attempt to find a matching MSP auxiliary record (MSPA) when the incoming HUDP transaction Claims Processing Indicator is set to “S” or “F.” If CWF determines there are issues with the incoming HUDP transaction, the system shall return the applicable disposition code or error condition code to the COB&R systems Contractor for resolution. If CWF determines that a portion of the incoming HUDP DPP records contains errors while other segments of the DPP records do not, CWF shall allow the DPP records without detected issues to be transmitted to the shared system representing a given MAC. And CWF shall return the DPP records that failed validation to the COB&R systems Contractor. CWF shall transmit the HUDP DPP records that passed validation to the shared system representing a given MAC via the current daily Unsolicited Response (UR) file or daily CWF reply file, as applicable to the shared system. CWF shall return a disposition code 01, denoting acceptable of the record, to the COB&R systems Contractor. CWF shall also transmit a disposition code 01 to the shared systems and associated A/B MACs and DME MACs as part of the HUDP file. A/B MAC and DME MAC Shared Systems Actions Upon receipt of the HUDP DPP records, the shared system shall determine whether it can create either a full claim denial adjustment (or full claim adjustment, as applicable) when the HUDP DPP record Claims Processing Indicator is set to “F” or attempt to create a DPP secondary claim adjustment when the Claims Processing Indicator is set to “S.” To the greatest extent possible, the shared system shall auto-adjudicate the identified DPP claims where Medicare inappropriately paid as primary. For HUDP DPP records where the Claims Processing Indicator is set to “F,” the shared system, or, as applicable, the A/B MAC or DME MAC, shall: Fully deny the claim as a full claim denial adjustment. (Note: No matter how the shared systems or A/B MACs or DME MACs achieve the adjustment result or what terminology is used to describe the adjustment (i.e., a full claim denial, full claim adjustment, full replacement), CMS’s intention is that the shared systems or A/B MACs or DME MACs shall reverse the claim(s) to take back Medicare’s full payment from the provider.) Capture the MSP Type Code (Part B)/MSP Insurance Type Code (Part A) from the HUDP DPP record and associate it with the full claim denial adjustment. Ensure that MSP savings are appropriately captured under the reported MSP Type Code (Part B)/MSP Insurance Type Code (Part A). Initiate a full recovery from the provider. For HUDP DPP records where the Claims Processing Indicator is set to “S,” the shared system shall review the HUDP DPP record to ensure all required information is present. Additionally, the shared system shall review the A/B MAC or DME MAC’s on-line DPP claim to extract other required data elements needed to create a Health Insurance Portability and Accountability Act (HIPAA) 837 compliant outbound claim as well as a compliant outbound Electronic Remittance Advice (ERA). When the shared system cannot create and/or complete a DPP adjustment due to problems with the HUDP DPP record’s content (e.g., missing required data elements or information that conflicts with the online DPP claim), the shared system shall include the information from the DPP record on to a report for A/B MAC or DME MAC review/intervention. As part of the automated DPP process, the shared system shall create DPP reporting on a daily and monthly basis and make the reports available to the associated A/B MAC or DME MAC. All A/B MACs and DME MACs, with the assistance of their Virtual Data Centers (VDCs), as necessary, shall store/retain all HUDP DPP records received from CWF and the various reports created and display them on-line for twelve (12) months. A/B MAC and DME MAC Requirements When adjudicating DPP adjustments, the shared system shall always set the claim header Mass Adjustment Indicator field value to “O” before transmitting the claims to CWF for normal processing. Additionally, the shared systems shall always set the Beginning of the Hierarchical Transaction Reference Identification (BHT03) file value position 23 to “S” before creating outbound 837 coordination of benefits (COB) claims that result from DPP adjustments. The DME MAC shared system shall also include the value “S” in the 23rd byte 504-F04 (Message) field indicator when creating outbound National Council for Prescription Drug Programs (NCPDP) batch COB claims that result from DPP adjustments. All A/B MACs and DME MACs shall always process DPP adjustments as “935 adjustments.” An exception to this rule is provider-initiated or requested adjustments, which are not handled as 935 adjustments. (See Pub.100-06, Chapter 3, § 200 for more information.) For DPP adjustments, A/B MACs and DME MACs shall use the same reason/discovery codes as they have done under the manual DPP process. When incoming claims have dates of service that are five (5) or more years old, the shared system shall not create an automated DPP adjustment claim. The shared systems shall instead include the DPP records on a report for A/B MAC or DME MAC review/intervention. When the shared systems do not auto-adjudicate a DPP claim whose Claim Processing Indicator= S and, instead, include the claim on a report for A/B MAC or DME MAC review and intervention due to missing required elements, the A/B MAC or DME MAC shall contact the BCRC or CRC, as applicable, by phone or via fax to attempt a resolution to the issue. If the appropriate MSP Contractor is able to obtain the missing required information and enter it into BCRS, the COB&R systems Contractor shall transmit the claim, with missing elements, added to CWF to re-initiate the DPP process. When there is conflicting information between the data on the DPP record and the claim within the A/B MAC or DME MAC’s claims history (e.g., the procedure codes and modifiers do not match), the A/B MAC or DME MAC shall: 1) Cancel the DPP claim if created by the shared system; and 2) Contact the BCRC or CRC, as applicable, by phone or via fax to attempt a resolution to the issue. As with the missing required data scenario, if the appropriate MSP Contractor is able to resolve the conflicting DPP information and make the needed correction in BCRS, the COB&R systems Contractor shall transmit the corrected claim to CWF to re-initiate the DPP process. During the interval between CWF validating the incoming HUDP transaction and the time that the shared system receives an HUDP DPP record via the CWF UR daily response or daily CWF reply, it is possible that the primary payer may have deleted the MSP auxiliary record. When this occurs, it is important that all stakeholders involved take certain steps to address the deleted MSP auxiliary record. In this situation, the A/B MAC or DME MAC shall: Not attempt to create an MSP Investigational (“I”) record on CWF; Contact the appropriate MSP Contractor to request that the primary payer be notified regarding the discrepancy between the evidence it has submitted to confirm its primacy status and the action taken to 1. Delete the MSP auxiliary record; and 2. Cancel the DPP adjustment. Important: For the automated DPP process, all shared systems shall bypass their normal logic that requires the creation of an MSP “I” record when it has been determined that CWF does not contain an associated MSP auxiliary record. Once the appropriate MSP Contractor has re-established the MSP auxiliary file, the COB&R systems Contractor shall reinitiate the HUDP transaction, thereby restarting the DPP process.