Don't 'manage' denials - Prevent them.
by Stefani Daniels, Managing Partner
Published on Dec 22, 2016
In enacting the Health Insurance Portability and Accountability Act (HIPAA) of 1996, Congress mandated the establishment of Federal standards for the security of protected health information (PHI). The purpose of the Security Rule is to ensure that every covered entity has implemented safeguards to protect the confidentiality, integrity, and availability of electronic protected health information and gives patients an array of rights with respect to that information. At the same time, HIPAA expressly permits disclosure of PHI needed for patient care treatment, payment, or health care operations.
But that was not the primary purpose of HIPAA: Administrative simplification was the original intent of the HIPAA regulations. HIPAA required the Secretary of HHS to adopt standards to support the electronic exchange of administrative and financial healthcare transactions. These transactions primarily occur between healthcare providers and health insurance plans or clearinghouses. The standards,specified by HIPAA 5010 requirements for the electronic transmission of healthcare payment and benefit information, enabled health information to be exchanged computer-to-computer through an electronic data interchange (EDI).
Two electronic data submission standards were adopted of interest to those of us involved in utilization review activities. The EDI Health Care Claim Transaction set (EDI 837) is used to submit the hospitals' claim billing information, either directly or via intermediary billers and claims clearinghouses. It can also be used to transmit healthcare claims and billing payment information between payers with different payment responsibilities where co-ordination of benefits is required.is the stardard submission of a hospital claim form.
EDI Health Care Claim Payment / Advice Transaction Set (EDI 835) is used by the payer to make a payment, send an Explanation of Benefits (EOB), send an Explanation of Payments (EOP) remittance advice, or make a payment and send an EOP remittance advice only from a health insurer to a health care provider either directly or via a financial institution.
These transaction sets can be quite complicated to set up and its not unusual that many hospitals outsource this function to an established 3rd party EDI provider like our EDI partner CentraMed. The insurance plan uses the 835 to detail the payment for each claim. A particular 835 document may not necessarily match up one-for-one with a specific 837. In fact, it is not uncommon for multiple 835 transactions to be used in response to a single 837, or for one 835 to address multiple 837 submissions. As a result, the 835 is important to the patient financial service (PFS) office, to track what payments were received for services which the hospital provided and billed, including
- What charges were paid, reduced or denied
- Whether there was a deductible, co-insurance, co-pay, etc.
- Any bundling or splitting of claims or line items
- How the payment was made, such as through a clearinghouse
Among the data contained in the 835 are Claim Adjustment Reason Codes and Remittance Advice Remark Codes (CARCs and RARCs). The CARC conveys information about remittance processing meaning that the payer must communicate why a claim was paid differently than it was billed. If there is no adjustment to a claim/line, then there is no adjustment reason code. The RARCs are used to provide additional explanation explaining the CARC.
The CMS maintains the CARC and RARC lists which are updated 3 times a year – in early March, July, and November - and are available on the Washington Publishing Company (WPC) website. There are hundreds of codes explaining why a claim was denied whether for technical errors, benefit limitations, or clinical issues. Here are a few examples of the CARCs:
N208 | Missing/incomplete/invalid DRG code. |
MA66 | Missing/incomplete/invalid principal procedure code. |
MA96 | Claim rejected. Coded as a Medicare Managed Care Demonstration but patient is not enrolled in a Medicare managed care plan. |
N143 | The patient was not in a hospice program during all or part of the service dates billed. |
MA36 | Missing/incomplete/invalid patient name. |
MA43 | Missing/incomplete/invalid patient status. |
M141 | Missing physician certified plan of care. |
M100 | We do not pay for an oral anti-emetic drug that is not administered for use immediately before, at, or within 48 hours of administration of a covered chemotherapy drug |
M60 | Missing Certificate of Medical Necessity. |
M42 |
The medical necessity form must be personally signed by the attending physician |
Obtaining denial information is probably one of the most challenging aspects of a fully successful revenue cycle. Without that information, there is very little that can be done to prevent the denials in the first place. However, the 835 report that comes to the hospital is very complex and without the help of a contracted outsource or on-site technical capability to access and interpret the data, the organization is at a major disadvantage. It is unfortunate that many CFOs have not given this valuable source of information the technical attention it requires. The 835 data is the primary tool to track and trend denial patterns so that action can be taken to avoid them in the first place.
We hope that this post will spark interest to investigate your organization's use of the 835 data and to persist with requests to the exec team to invest in the needed talent or technical resources that are needed to get the data, organize it and learn from it so that future denials can be prevented or mitigated promptly. There is a compelling business case to be made about the value of knowing where the hospital is hemorrhaging revenue. Be persistant and someone will listen!