The term Common Working File (CWF) is about as old as any IT terminology in our industry. I have used it myself since we began the company in 1986. Despite our common understanding of this concept, I have to admit that I was not really sure what it was, where it was stored, or how it was maintained. I decided to do a little research. Here are the results.
The CWF is specific to Medicare. It is a collection of records maintained on behalf of each Medicare beneficiary that covers these four general areas of information:
Medicare Secondary Payer (MSP)
Health Maintenance Organization (HMO)
This information is stored in a separate record for each beneficiary for each of these data categories.
Although we think of the CWF as a single database, it is actually comprised of 9 databases called Hosts. Each beneficiary is assigned to only one host. This is determined by where the person signs up for their SSA benefits. Here are the host sites and the states that are assigned to each:
All claims are processed against these records for payment and the records are updated daily from the data in the adjusted and approved claims. These databases are not accessed directly by providers, but by the Medicare contractors that process provider claims. These Medicare contractors are referred to as “Satellites” by CMS. Satellites are located in geographic sectors called “Jurisdictions”, but each satellite and jurisdiction uses the same procedure to process Medicare claims.
Providers, or their representatives, submit Medicare claims electronically to their Medicare contractor with a submitter ID associated with their claims. This is done through a dedicated connection between a provider or provider vendor that transfers the file through secure FTP.
The Medicare contractor is responsible for adjudicating these claims to the point of payment. We refer to this as “front end processing”. In this part of the process, the contractor validates the file as being a HIPAA compliant ANSI 837 file and returns the result as an ANSI 999 file. This file either states that the file was compliant and the batch was accepted, or that it was rejected. If the file was rejected, the 999 will included details about why the file was considered to be non-compliant including the specific location in the file where the error occurred. These files are usually created just a few minutes after the receipt of batch. They are returned to the provider through the same connection used to submit the claims batch.
Any errors should be reported to the vendor that created this file immediately since all claims in this file are rejected until the file can be resubmitted correctly. Most providers are unable to correct these formatting errors without vendor assistance.
If the batch is accepted, the contractor then runs the next step of validation on the claims. These are at the claim level and determine which individual claims are rejected or accepted by the Medicare claims processing system. This is done through a software system running on IBM mainframe computers dedicated to this task. Each Medicare contractor maintains their own system for this purpose, but the processing for each contractor is identical. The results of this process are included in another ANSI file – the unsolicited claim status response report or 277CA for short. This file is normally created about four to six business hours after the submission of the claims. Claims that fail these edits must be resubmitted by the provider in a future batch. This makes it essential that each provider submitting claims through this process has the tools to retrieve and view the results of the 277CA so that they know which claims were rejected the next business day and can take corrective action quickly.
The claims that are deemed “accepted” in the 277CA are referred to as “Approved” claims. Approved claims are forwarded to the appropriate Host for the Medicare beneficiary for nightly processing. We refer to this as “back end processing”.
The Host then uses the CWF master record information to determine if the claim should be approved for payment. There are 3 options:
Accept claim as submitted
Accept claim with adjustments
Reject for corrective action by Satellite
Hosts are responsible for processing claims submitted for beneficiaries in its database. These claims are processed through shared software supplied to each Host by the CWF Maintenance Contractor (CWFM). When changes are made to this software, it is released to all Hosts at the same time. This software performs edits on claims for corrective action by the Satellite.
Each Satellite in a jurisdiction is linked to a host database. Claims ready for payment or denial are sent to the host. The host returns adjustments, approvals, rejects and informational messages through a daily process. This is initiated by the Satellite, on rare occasions, the host will send back informational records unsolicited. Claims are processed first in first out by the hosts.
When the host receives an individual claim from a satellite for processing, the host processes the claim through CWF consistency edits, MSP consistency edits, CWF utilization edits, and MSP utilization edits, in that order. Based on these edits, it makes an approval adjustment or rejection determination. This determination is returned in a Basic Reply Record.
Records sent by Satellites to the host
Claim records can be the following types:
Part B Claim record
DMEPOS Claim Record
Inpatient/SNF Claim Record
Hospice Notice of Election
Records can also be sent that either void (replace) or change claims already in the CWF
Records sent by Host to Satellites
When the host receives a claim or adjustment, it searches the Beneficiary file to find the Beneficiary record. If the record is found, the claim is processed and a reply record is sent to the satellite. The record type returned is dictated by the claim type. The reply record contains a disposition code that indicates the action taken on the bill by the host. These are the codes and actions that may be taken:
01 – Accepted as is for payment
02 – Adjusted and then accepted for payment. This occurs when the deductible and/or payment limitations on the claim record were in error and the host posts the claim to the CWF after these corrections are made. The adjustments are returned to the satellite. This also includes crossover alerts.
03 – Cancel/Void claim accepted. This confirms that a cancel or void claim request has been processed and the original information in the claim has been replaced or backed out.
04 – Rejected. There are four error codes:
ER – Consistency Error Code. Consistency edits examine the information on the claim itself. These codes are contained in the Basic Reply Trailer.
UR – Utilization edits compare the information on the CWF claim record with the information found in the CWF Beneficiary Master Record. The error code indicates discrepancies between the Claim Record and the Master Record. Since the CWF Master Record is presumed correct, these codes inform the Satellite what corrections must be made.
In addition to this process between Medicare contractors and the Host systems, the CWF is also accessible by providers through terminal access to mainframe computer systems created for this purpose. These systems were previously available via dial up connection, but now are only available through vendors providing a connectivity service. The provider uses a terminal emulation program along with their secure connection to create a session on the host system. Through this connection, CWF data can be viewed, pending claims can be modified, and claims can be entered manually for low volume providers. This system is referred to as Direct Data Entry or DDE and is available to all approved Medicare providers through their Medicare contractor.
If you need to connect to the CWF through this method, please try our PayerLink product and get a login from your Medicare contractor. For more detailed information on how the CWF works and how to use DDE, one of the Medicare contractors, PGBA, has written an excellent manual that applies to all Medicare providers. You can access the manual through this link:
By Kalon Mitchell – President, MEDTranDirect