Medicare Secondary Payer Manual (Pub. 100-05), Ch. 5 § 20.4.2

Policy Regarding ORM

Last amended: 2022Year: 2022Length: 963 wordsOfficial source
20.4.2 – Policy Regarding ORM (Rev. 11550; Issued: 08-12-22; Effective: 10-13-22; Implementation:10-13-22) Pursuant to §1862(b)(2)(A)(ii) of the Social Security Act (42 U.S.C. 1395y(b)(2)(A)(ii)), Medicare is precluded from making payment where payment “has been made, or can reasonably be expected to be made...” under liability insurance (including self-insurance), no-fault insurance, or a workers’ compensation law or plan, hereafter, referred to as Non-Group Health Plan (NGHP). Where ORM has been reported, the primary plan has assumed responsibility to pay, on an ongoing basis, for certain medical care related to the NGHP claim. Consequently, Medicare is not permitted to make payment for such associated claims absent documentation that the ORM has terminated or is otherwise exhausted. Systems Changes Made and A/B MACs and DME MACs Contractor Operational Responsibilities An ORM indicator field was added to CWF that will be populated with two values: “Y,” which denotes that ORM responsibility assumed/exists, or a “space,” which signifies that an RRE has not assumed ORM. Please note that where ORM is reported, the ORM indicator on associated MSP auxiliary records remains a “Y” even where the ORM is subsequently terminated. Important: A “Y” ORM indicator value denotes that the ORM existed for a particular period of time (not necessarily that it currently exists). All A/B MACs and DME MACs shall reference the modified CWF MSPD screen to determine if ORM exists in association with MSP D (No-Fault – 14), E (Workers Compensation -15), and L (Liability - 47) records for the date(s) of service at issue. After comparing the diagnosis code(s) on the claim with the diagnosis code(s) associated with the ORM record, all A/B MACs and DME MACs shall deny claims where the 1-byte ORM indicator on the MSPD screen equals “Y” and the diagnosis code(s) match(es) (or match(es) within the family of diagnosis codes). As stated, documentation from the RRE that the ORM terminated or is otherwise exhausted may require that the previously denied claim (s) be reprocessed. A/B MACs and DME MACs shall deny payment for claims with open ORM for the date of service for the associated diagnosis code(s) or family of diagnosis codes. The prompt payment rules do not override this requirement. However, as stated, the reported ORM is not a guarantee that medicals will be paid indefinitely or through a particular date. Consequently, if a claim is denied on the basis of ORM and the A/B MAC and the DME MAC receives information that the policy limit has been exhausted -- even though the claim in question is for services prior to the ORM termination date -- the claim may be paid if it is otherwise covered and reimbursable. This type of situation could occur where there has been a delay in billing to the RRE or where part of a group of claims submitted to the RRE was sufficient to exhaust the policy. A/B MACs and DME MACs may receive Congressionals or inquiries from providers physicians, other suppliers including beneficiaries, or authorized representatives, stating that Medicare claims were inappropriately denied because the services performed for an accident or injury are not related to the Liability, No-fault or Workers’ Compensation MSP record found on CWF. Even though the diagnosis codes on the claim are within the family of diagnosis codes found on the MSP NGHP record there are situations where the claim services are not related to the accident or injury. If evidence/documentation is later received and it demonstrates that the services performed are unrelated to the MSP NGHP record, the A/B MAC and DME MAC may make payment on the claim. NOTE: Unless otherwise mentioned, A/B MACs and DME MACs shall assume that normal MSP claims processing requirements (e.g., checking claim service dates against MSP auxiliary record effective and termination dates; matching diagnosis codes on the claim against those on CWF (including the family of diagnosis codes policy); and affording appeal rights on MSP claims) apply. The A/B MACs, DME MACs and shared systems shall only apply the prompt payment rules for liability insurance and the prompt payment rules for no-fault insurance and workers’ compensation if the ORM indicator on the MSPD screen equals a “space,” which means ORM does not exist for this MSP record. Special Circumstance for A/B MACs and DME MACs While it may not occur frequently, there may be situations where an RRE will continue to assume ORM for a particular injury/illness and at the same time have a lump sum type settlement or other payment with respect to other alleged injuries/illnesses for the same date of accident/injury/loss. Consequently, it is possible that CWF could have both an open ORM occurrence as well as an open Medicare Set-Aside (MSA) occurrence, just not for the same diagnosis code(s). Therefore, the A/B MACs shall determine which record on CWF is applicable in order to process the claim appropriately. For example, the A/B MAC may review the diagnosis codes on the claim and compare them to the diagnosis codes on the open ORM occurrence and the MSA occurrence, as well as any other open CWF occurrences that fall within the date perimeters being reviewed, to find the correct match for MSP claims processing purposes. Residual Payments on Claims Until future instructions are issued, A/B MACs and DME MACs shall follow existing procedures when they need to make a residual secondary payment in ORM situations (where an MSP D, E, or L records contain an ORM indicator of “Y,” but the primary payer did not make complete payment on the claim). For example, they may need to request permission from their CMS Contracting Officer Representative (COR) to pay the claim outside of CWF. In situations where the ORM has been exhausted, A/B MACs and DME MACs shall send an ECRS request to the MSP Contractor identifying the date when benefits were exhausted.
Medicare Secondary Payer Manual (Pub. 100-05), Ch. 5 § 20.4.2: Policy Regarding ORM | Justis AI