evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
10 - General Information About the Common Working File (CWF) System  (Rev. 4009, Issued: 03- 23-18, Effective: 04 -23-18, Implementation: 04- 23-18)  The Common Working File (CWF) is the Medicare Part A and Part B beneficiary benefits coordination and pre -payment claims validation system which uses localized databases maintained by designated contractors called CWF Hosts.  The CWF System software is duplicated and utilized by the nine CWF Hosts localized databases  to process claims.  Each Medicare beneficiary is assigned to only one Host site based on beneficiary geographic location.  CWF Hosts maintain total beneficiary claim history and entitlement information for the beneficiaries in their jurisdiction.   Each ju risdiction is a network of A/B Medicare Administrative Contractors (MACs) and Durable Medical Equipment Medicare Administrative Contractors (DME MACs),  termed Satellites,  and located in a defined geographic area (sector).  Each MAC within the sector is l inked to its Host via telecommunications through their respective CMS Virtual Data Center (VDC).   The Medicare Part A, B or DME processing system creates a nightly CWF file out of the MACs processing region, containing claims data. The corresponding MACs  VDC transmits these files to the CWF Host.  The CWF Host uses the CWF software and determines the beneficiary's eligibility and entitlement status and uses that information to decide what action should be taken on the claim.  The CWF software also checks incoming claims against all other claims types, referred to as A/B crossover, previously processed and stored in claims history to prevent duplicate payments.  The Host returns a response file back to the VDC and the file is loaded to the MACs processing r egion. The file will contain various disposition codes, trailers, and error codes, used by the processing systems in automatic processing during the batch cycle.  The responses are applied to the pending claim allowing appropriate system action. 20 - Commo n Working File (CWF) Operations                                         (Rev. 11427; Issued: 05- 20-22; Effective: 01 -01-23; Implementation: 01- 03-23)
(Medicare Claims Processing Manual)
NOTE:  CMS seeks to reduce burden and modernize processes to ensure a reduction in improper payments and an increase in customer satisfaction. The Certificate of Medical Necessity (CMN) form and DME Information Form (DIF) were originally required to help document the medical necessity and other coverage criteria for selected Durable Medical Equipment, Prosthet ics, Orthotics, and Supplies (DMEPOS) items. In the past, a supplier received a signed CMN from the treating physician or created and signed a DIF to submit with the claim. Due to improvements in claims processing and medical records management, the inform ation found on CMNs or DIFs is available either on the claim or in the medical record and is redundant. Therefore, to reduce burden and increase customer satisfaction, providers and suppliers no longer need to submit these forms for services rendered after  January 1, 2023.  For claims with dates of service on or after January 1, 2023  providers and suppliers no longer need to submit CMNs or DIFs with claims. Due to electronic filing requirements, claims received with these forms attached will be rejected and returned to the provider or supplier.  For claims with dates of service prior to January 1, 2023  processes will not change and if the CMN or DIF is required, it will still need to be submitted with the claim, or be on file with a previous claim. This statement applies throughout the Program Integrity Manual wherever CMNs and DIFs are mentioned.  This section is intended only to be a brief profile synopsis of CWF operations. The system and user documentation should be closely examined for further details.
(Medicare Claims Processing Manual)
The Common Working File system provides a single data source where the contractors can verify beneficiary eligibility to receive prepayment review and approval of claims.  Each Host site is responsible for processing those claims submitted for beneficiaries on its database.  These claims are processed through a shared  software system supplied to each Host by the CWF Maintenance Contractor (CWFM). Each change made to the CWF software is released to all Host sites in a uniform manner.  This software performs consistency and utilization editing on claims for corrective action by the MACs.  The CWF system ensures that:  1. The beneficiary is entitled to either Part A or Part B benefits, depending on the type of claim submitted.  2. The co -pay and/or deductible applied, if any, is accurate. 3. Services are allowed.  4. Benefits are available for the services submitted on the claim  The CWF system also ensures that the services on the claim have not been paid on another claim - either the same type or another type of claim. If any of these conditions occur, the CWF system returns a response and identifies the reason for the rejection. The response also includes one or more trailers that identify the correct information necessary for the Medicare contractor to take the necessary action.   Prior to adjudication of claims, the CWF Host will sen d the claim to Fraud Prevention System (FPS) for review. FPS will make a payment determination which will be sent to the CWF Host. The CWF Host will then process the claims through consistency and utilization to ensure beneficiary is entitled to either Par t A or Part B benefits, depending on the type of claim submitted.   Once the claim passes all of the edits, the CWF beneficiary master file is updated to reflect the benefits now available, as well as any changes to the deductible status. The claim is added to the CWF full claim history file.   CWF also provides eligibility and entitlement check via the beneficiary data streamlining (BDS) system which occurs earlier in the claims lifecycle to check for Medicare beneficiary identifier, eligibility and entitlement prior to the submission of the claim.
(Medicare Claims Processing Manual)
20.1 - Communication between Host and MACs Jurisdiction Sector    (Rev. 4009, Issued: 03- 23-18, Effective: 04-23-18, Implementation: 04-23-18) The local CWF database for each sector resides at a Host.  Each A/B and DME MAC within the sector is linked to its Host's database.  Communication between them is electronic, with claims ready for payment or denial communicated to the Host, and adjustments, approvals, rejects, and informational trailers returned from the Host via a daily process.  The A/B and DME MACs usually initiates this process.  On occasion, the CWF Host will initiate an "unsolicited response" to the A/B and DME MACs as a result of a new claims action that affects a previously processed claim act ion. Claims are processed by CWF in the same order that they are received, regardless of the dates of service or receipt date.  This first -in-first-out method of processing requests for payment facilitates prompt handling of claims.  Role of CWF Hosts:   Responsible for executing a common set of CWF software modules to maintain Beneficiary databases by adding or updating Beneficiary entitlement information provided by CMS  o These updates are processed by the enrollment database (EDB) and continue to update CWF Host records as the beneficiary's entitlement changes.   Perform consistency; utilization, A/B cross over and duplicate edit checks to provide authorization for MACs to pay claims;   Providing and controlling linkage of the MACs in the sector to the Hos t; Controlling and monitoring telecommunications network operations  Supplying MACs with inquiry and transmission software necessary to communicate with the Host and make full use of the CWF data inquiry features;   Receiving, installing, testing, and operating the CWF software system, including all changes developed by CWFM;   Role of A/B and DME Medicare Administrative Contractors (MACs):   Submission of claims via telecommunication in batch mode to a CWF Host for validation and payment approval;   Receive, control, and enter claims into an automated processing system.   Review, edit, and adjudicate claims through CWF system for determination of eligibility, coverage, and pricing.   Submission of online inquiries to a CWF Host to determine Beneficiary enrollment status and eligibility   Submit claims to the
(Medicare Claims Processing Manual)
 Review, edit, and adjudicate claims through CWF system for determination of eligibility, coverage, and pricing.   Submission of online inquiries to a CWF Host to determine Beneficiary enrollment status and eligibility   Submit claims to the CWF Host for pre -payment validation and authorization.  Issue payments to Providers or deny/develop claim is rejected by CWF; - Issue Explanation of Medicare Benefits and payments to Beneficiaries.
(Medicare Claims Processing Manual)
20.2 - Recor ds received by the CWF Hosts (Rev. 4009, Issued: 03- 23-18, Effective: 04-23-18, Implementation: 04-23-18) 20.2.1 - Beneficiary Data Streamlining (BDS)                                           (Rev. 4009, Issued: 03- 23-18, Effective: 04-23-18, Implementation: 04 -23-18) The BDS system provides access to a common eligibility service which occurs earlier in the claims lifecycle than the CWF eligibility check. The BDS transactions, 'HBDA' for Part A, 'HBDB' for Part B, and 'HBDD' for DME, will allow the Shared Systems claims processing to query eligibility edits for Part A, Part B, and DME claims. The BDS system uses the CWF data repository to provide eligibility and entitlement responses to the Shared Systems query. The information is returned on a BDS Basic Reply Record.  ( See 20.3.1)  BDS records can be of the following types:  A/B MAC (A)  Claim Record:   A/B MAC (A)  bills are input on the HBDA record.   A/B MAC (B)  Claim Record:  A/B MAC (B)  bills are input on the HBDB record.  DMEPOS Claim Record:  DMEPOS bills are input on the HBDD record.    20.2.2  Claims                                                                                             (Rev. 4009, Issued: 03- 23-18, Effective: 04-23-18, Implementation: 04-23-18) The CWF Claim Record is a record of a claim that the MAC has processed and is ready for payment or denial.  It is submitted in daily files to the Host for approval.  Prior to the approval CWF Host will send the claim to Frau d Prevention System (FPS) for review.  Role of FPS :  FPS interacts directly with the CWF Hosts and performs these functions:  Receive files submitted by CWF Hosts with claims approved for payment.  Process claims using proven predictive modeling tools to ide ntify high risk claims.   Make a payment determination that is returned to the CWF Hosts for appropriate action.  Only denied claims will be included in the returned file.
(Medicare Claims Processing Manual)
The Host clears the claim record through regular CWF consistency edits, utilization edits and A/B crossover edits, in that order, and makes its approval, adjustment or rejection determination.  The final determination is returned on a Claim Basic Reply Record.  (See 20.3.2)  Claim records can be of the following types:   Part B  Claim Record: Part B bills are input on the HUBC record.   DMEPOS Claim Record:  DMEPOS bills are input on the HUDC record.   Inpatient/Skilled Nursing Facility Claim Record:  Inpatient hospital and SNF bills are input on the HUIP record.   Outpatient Claim Record:  Outpatient bills are input on the HUOP record.   Home Health Claim Record:  Home health bills are input on the HUHH record   Hospice Claim Record:  Hospice bills are input on the HUHC record.
(Medicare Claims Processing Manual)
20.2.3 - Adjustments/Cancels to Posted Claims  (Rev. 4009, Issued: 03- 23-18, Effective: 04-23-18, Implementation: 04-23-18) Two actions can be taken on a claim that is already posted to CWF history.  These actions are the same whether submitted by an A/B MAC or DME MAC ; however, the codes used are different:   Void - Use a void to cancel original data on the beneficiary database and totally remove the dollar amounts.  To void a posted claim, send the claim with the original document control number and a "Full Credit" code (Entry Code 3 for A/B MACs (B) and DME MACs and Action Code 4 for A/B MACs (A, HHH)) ).  Change - Send a full claim with a "Replacement Debit" code (Entry Code 5 for A/B MACs (B) and DME MACs  and Action Code 3 for A/B MAC s (A, HHH) ) and the original document control number to make a change to a posted claim.  This code is used to change most claims information.  The old claim information will be backed out and replaced with the new claim information.  The CWF will keep a record of the old claim so that any investigation of the actions taken on the claim will include the fact that there was a replacement action taken.  20.2.4 - Claim Maintenance Records                                                         (Rev. 4009, Issued : 03-23-18, Effective: 04-23-18, Implementation: 04-23-18) The CWF Claim Maintenance Record is a record of a transaction that the Medicare Administrative Contractors are submitted in daily files to the CWF Host to update the related auxiliary file information that is used for claims processing approval.  The final determination is returned on a Basic Reply Record.  (See 20.2.2.)  Claim Maintenance records can be of the following types:  Medicare Secondary Payer (MSP): Medicare Secondary Payer information (Primary insurer data when Medicare is secondary) is input on the HUSP record.  End Stage Renal Disease (ESRD):  Beneficiary ESRD data input on the HURD record.   Certified Medical Necessity (CMN): Beneficiary Certified medical necessity data is input on the HUCM record.  Beneficiary Other Insurance Information
(Medicare Claims Processing Manual)
Beneficiary ESRD data input on the HURD record.   Certified Medical Necessity (CMN): Beneficiary Certified medical necessity data is input on the HUCM record.  Beneficiary Other Insurance Information (BOI): Beneficiary Other insurance information data is inp ut on the HUBO record.   Beneficiary Libby Montana (Libby): Beneficiary Libby information data is input on the HUEP record.  Beneficiary Prior Authorization (PRAU): Prior Authorization data is input on the HUPA record.   Intravenous Immune Global (IVIG): Benefi ciary Intravenous Immune Globulin information data is input on the HUIV record.
(Medicare Claims Processing Manual)
20.3 - Records received from the CWF Hosts  (Rev. 4009, Issued: 03- 23-18, Effective: 04 -23-18, Implementation: 04- 23-18)
(Medicare Claims Processing Manual)
20.3.1  BDS Basic Reply  (Rev. 4009, Issued: 03- 23-18, Effective: 04 -23-18, Implementation: 04- 23-18) When the Host receives a query from MACs requesting beneficiary eligibility and entitlement information, the informational record is sent in response to the BDS Transaction record sent to the host. It acknowledges the Host's receipt of the BDS Transaction  record and indicates any errors or informational data.   Following are the types of codes and other information associated with this record: These codes are returned on Basic Reply Trailer 08 and other reply trailers as appropriate   Disposition codes;   Error codes;  and  Basic Reply Trailers.  20.3.2 - Claims Basic Reply  (Rev. 4009, Issued: 03- 23-18, Effective: 04 -23-18, Implementation: 04- 23-18) When the Host receives each claim or adjustment, it searches the Beneficiary File to find the Beneficiary Record.  I f the Beneficiary Record is found, the record is processed and a reply record is transmitted to the MAC.  See 20.3.3, for an explanation of t he procedure if the Beneficiary Record is not found ("Not in File.")  The record type returned by CWF is dictated by the claim record type as follows:   A/B MAC (B)  Basic Reply Record -  Reply record for each CWF A/B MAC (B) bill (HUBC) processed.   DMEPOS Basic Reply Record -  Reply record for each CWF DMEPOS bill (HUDC) processed.   Inpatient/SNF Bill Basic Reply Record -  Reply record for each Inpatient/SNF bill (HUIP) processed.   Outpatient/Home Health Bill Basic Reply Record -  Reply record for each Outpatient/Home Health bill (HUOP and HUHH) processed   NOE/Hospice Bill Basic Reply Record -  Reply record for each Hospice Notice of Election and all subsequent Hospice bills (HUHC) processed.   Each reply record will contain a disposition code and error code  that indicates the action taken on the bill by the Host and what action the MAC should take next. The following is a list of actions that CWF may take on a claim record. Disposition codes, cross -reference/alpha search/NIF situations, their associated trai lers,
(Medicare Claims Processing Manual)
by the Host and what action the MAC should take next. The following is a list of actions that CWF may take on a claim record. Disposition codes, cross -reference/alpha search/NIF situations, their associated trai lers, and bill recycling instructions are also included:  20.3.2.1 - Accepted (as is) for Payment  (Rev. 4009, Issued: 03- 23-18, Effective: 04 -23-18, Implementation: 04- 23-18) The claim record is posted to CWF history as submitted to the Host.  The MAC pays the claim accordingly.   Disposition code 01.  Basic Reply Trailers -  These are informational trailers that contain entitlement, utilization, MSP, or other information, as appropriate, and are returned with the Reply.  They give the MAC the most recent inform ation available about the beneficiary's claim history and other important data.  MACs must use this information to update their own data to improve the accuracy of future claims processing.   Return Alerts -  These are sent to the MAC when CWF believes that there is a potential problem or error in the claim.  The presence of an alert indicates that the MAC should examine the information and make adjustments if necessary.  20.3.2.2 - Adjusted and Then Accepted f or Payment  (Rev. 4009, Issued: 03- 23-18, Effective: 04 -23-18, Implementation: 04- 23-18) The deductible and/or payment limitations field(s) on the claim record were in error and CWF recalculated the field(s).  The Host posts the record to CWF after these co rrections are made.  The MAC must make the same adjustments to its files using information from basic reply Trailers 07 and 11 and pay the claim accordingly.  MACs must not resubmit the claim to CWF.   Disposition code 02  Basic Reply Trailers (07 and 11)   A/B Crossover Alerts  20.3.2.3 - Cancel/Void Claim Accepted                                                               (Rev. 4009, Issued: 03- 23-18, Effective: 04 -23-18, Implementation: 04- 23-18) This action cancels or voids a previously processed claim post ed to CWF History.  All utilization and deductibles associated with the claim are backed out.  The MAC receives a disposition code informing it that the
(Medicare Claims Processing Manual)
04- 23-18) This action cancels or voids a previously processed claim post ed to CWF History.  All utilization and deductibles associated with the claim are backed out.  The MAC receives a disposition code informing it that the cancel/void action was accepted.   Disposition code 03  Basic Reply Trailers  20.3.2.4 - Rejected  (Rev. 4009, Issued: 03- 23-18, Effective: 04-23-18, Implementation: 04-23-18) The claim record contains errors that prevent CWF from posting the claim to history.  The claim is returned to the MAC with codes explaining the errors.  The MAC must correct the CWF Claim Record and resubmit it.   Disposition Code ER, UR, CR, or AA, as Appropriate -  There will never be a combination of ER, UR, CR, and AA error codes on the same reply.  Consistency Error Codes (ER) - Consistency edits examine the information on the claim itself.  The consistency error codes indicate the errors in consistency found on the claim.  These codes are returned on Basic Reply Trailer 08 and can contain up to four consistency error codes.  Utilization Error Codes (UR) - Utilization edits compare the  information on the CWF Claim Record with the information found on the CWF Beneficiary Master Record.  The utilization error codes indicate discrepancies between the CWF Claim Record and the CWF Beneficiary Master Record.  Since the CWF Beneficiary Master Record is presumed to be correct, these codes inform the MAC what corrections it must make.  The code is returned on basic reply Trailer 08 and contains only one utilization error code. FPS:  If FPS denies the claim record, CWF will stop processing the clai m and return a response back to the MAC with FPS error code.  Disposition Code UR  The utilization error code indicate the errors found on the claim. These codes are returned on Basic Reply Trailer 08, 48 and 49 indicating partial denial (FPSD) or full denial of the claim (FPSH).   A/B Crossover Edits (CR) - When the Host receives a Part A bill, CWF automatically checks the information in the record against the beneficiary's history files for both Part A and Part B utilization.  If there is a conflict (or "crossover") of services, CWF will generate an A/B Crossover error code.
(Medicare Claims Processing Manual)
the information in the record against the beneficiary's history files for both Part A and Part B utilization.  If there is a conflict (or "crossover") of services, CWF will generate an A/B Crossover error code.  These are returned on the reply Trailer 13 and will contain only one A/B crossover error code.  20.3.3 - Not in Host's File (NIF)  (Rev. 4009, Issued: 03- 23-18, Effective: 04-23-18, Implementation: 04-23-18) When the Host receives a claim record from a MAC, it first searches its beneficiary and cross reference files.  If it does not find the beneficiary's record in either place, it searches the Transfer Not in File (TNIF) file.  If the record is not found there, the Host puts a response on the reply record in the form of a disposition code 50 or 52, indicating that the Beneficiary Record for which the MAC submitted a claim record is not located at the MAC's Host.  The TNIF fil e contains a record of every beneficiary for whom the Host has received a claim, and whose records are located at another Host.  It shows at which Host the beneficiary file resides.  If the Beneficiary Record is located at another Host, the original Host c hecks the out -of-service area response file to see if the claim record response is already waiting there.  If there is not a response waiting, the claim is sent to the proper Host for processing.  If there is a response, the Host gives that information to the MAC.  There are many disposition codes that are returned to the MAC for various NIF situations.  Following is a list of codes and actions the MAC takes in response to each disposition code. 20.3.3.1 - Disposition Code 50 (Not in File)  (Rev. 4009, Issued : 03-23-18, Effective: 04 -23-18, Implementation: 04- 23-18) Disposition code 50 can come with any of the following seven error codes:  1. With Error Code 5052 -  Beneficiary Identification Incorrect -  The name and/or claim number shown on the bill is incorrec t or claim number is not in file.  If the TNIF file does not indicate another Host, the beneficiary's records may not
(Medicare Claims Processing Manual)
Identification Incorrect -  The name and/or claim number shown on the bill is incorrec t or claim number is not in file.  If the TNIF file does not indicate another Host, the beneficiary's records may not have been assigned to a Host and are still resident at CMS or the beneficiary was  assigned to another Host site and the TNIF File was not updated.  When the Host is not sure which is the case, it gives disposition code 50 and Trailer 08 with error code 5052 on the reply to the MAC.  A/B MACs and DME MACs  verify through inquiry to the Host that the HICN is correct on the bill.  If the bill is  correct, and the Host HIMR agrees with the reject (no record), A/B MACs and DME MACs  must notify the Host of the error.  The Host will contact CMS to determine eligibility.  2. With Error Code 5054 -  The Host returns code 50 with Trailer 08 and error code 5054 when an auxiliary indicator is present on the CWF Beneficiary Master Record, but no auxiliary record is found.  Concurrent with this response to the MAC, the Host sends a request for transfer to CMS requesting the beneficiary's records from CMS' Master  File.