evekhm/cms_iom_500 huggingface dataset:
(Medicare Claims Processing Manual)
Transactions for Medicare Secondary Payer (MSP), End Stage Renal Disease (ESRD), Certificate of Medical Necessity (CMN), Beneficiary other insurance (BOI), Libby Montana (HUEP), Prior Authorization (HUPA),and IVIG error codes are also available.  Below are the list of high level error functions performed during the CWF processing  1. Inpatient, SNF, Outpatient, Home  Health, and Hospice consistency edits,  2. Part B/DMEPOS consistency edits,  3. Entitlement edits,  4. Duplicate edits,  5. Inpatient, SNF, Outpatient, Home Health, and Hospice utilization edits,  6. Part B/DMEPOS utilization edits,  7. A/B Crossover edits, 8. Medicare Secondary Payer (MSP) consistency/utilization edits, 9. MSP transaction (HUSP) edits,  10. Certified Medical Necessity (CMN) consistency/utilization edits,  11. CMN transaction (HUCM) edits,  12. End Stage Renal Decease (HURD) consistency/utilization edits,  13. ESRD transactio n (HURD) edits,  14. Beneficiary Other Information (BOI)/Claim based crossover edits,  15. BOI transaction (HUBO) edits,  16. Libby Montana (HUEP) project edits,  17. Prior Authorization (PRAU) consistency/utilization edits,  18. PRAU transaction (HUPA) edits,  19. Immune Globulin (I VIG) consistency/utilization edits,  20. IVIG transaction (HUIV) edits, and 21. BDS/FPS and other processing edits.  80.3 - Beneficiary Other Insurance Information (HUBO)  Maintenance Transaction Error Codes                                                                                           (Rev. 4009, Issued: 03- 23-18, Effective: 04 -23-18, Implementation: 04- 23-18) Effective January 2, 2007, the CWF shall accept and process a HUBO transaction that eithe r updates an existing Beneficiary Other Insurance (BOI) auxiliary record or  adds a new BOI auxiliary record occurrence.
(Medicare Claims Processing Manual)
If the CWF receives an incoming HUBO transaction whose COBA identification number (ID) and beneficiary supplemental eligibility -from date (CCYYMMDD) match the equivalent elements within an existing BOI auxiliary record, it shall overlay the existing record with the incoming record.  However, if the CWF receives an incoming HUBO transaction whereby the COBA ID and beneficiary supplemental -from date do not  match the equivalent elements within an existing BOI auxiliary record, it shall create a new BOI auxiliary record occurrence.   For purposes of applying COBA eligibility files to the BOI auxiliary file, the CWF maintainer shall redefine Action Type 0 - Add as 1 -Add/Update.  For purposes of applying COBA eligibility files to the BOI auxiliary record, th e CWF shall now accept and process only two Action Types 1 -  Add/Update and 2  Delete from the BCRC as part of the COBA crossover process.   The CWF shall continue to apply the applicable BO edits that would relate to add/update or delete actions accomplished via the HUBO transaction.  80.4 - Consolidated Claims Crossover Process  (Rev. 11396, Issued:05- 04-2022, Effective:10 -01-2022, Implementation:10- 03-2022)   A.  The Mechanics of the CWF Claims Selection Process and BOI and Claim -based Reply Trailers  1.  CWF Receipt and Processing of the Coordination of Benefits Agreement Insurance File (COIF)   Effective July 6, 2004, the Benefits Coordination & Recovery Center (BCRC)  began to send copies of the Coordination of Benefits Agreement Insurance File (COIF) to the nine CWF host sites on a weekly basis.  The COIF will contain specific information that will identify the beneficiaries other health insurance, also known as the COBA tra ding partner, including name, COBA ID, address, and tax identification number (TIN).  It will also contain each trading partners claims selection criteria exclusions (claim or bill types that the trading partner does not want to receive via the crossover process) along with an indicator (Y=Yes; N=No) regarding whether the trading partner wishes its name to be printed on the Medicare Summary Notice (MSN).
(Medicare Claims Processing Manual)
The CWF shall load the initial COIF submission from the BCRC  as well as all future weekly updates.   Upon receipt of a claim, the CWF shall take the following actions:  a. Search for a COBA eligibility record on the BOI auxiliary record for each beneficiary, unless there is a COBA ID in range 55000 through 55999 present on the incoming HUBC or HUDC claim (which identifies Medigap claim -based crossover), and obtain the associated COBA ID(s) NOTE:  There may be multiple COBA IDs;   b. Refer to the COIF associated with each COBA ID (NOTE:  CWF shall pull the COBA ID from the BOI auxiliary record) to obtain the COBA trading partners name and claims selection criteria;   c. Apply the COBA trading partners selection criteria; and  d. Trans mit a BOI reply trailer 29 to the A/B MAC or DME MAC  only if the claim is to be sent, via 837 COB flat file or National Council for Prescription Drug Programs (NCPDP) file, to the BCRC  to be crossed over. (See Pub.100-04, Chap. 28, 70.6 for more information about the claim file transmission process involving the A/B MAC or DME MAC  and the BCRC .)  Effective with the October 2004 systems release, CWF shall read the COIF submission to determine whether a Test/Production Indicator T (test mode) or P (production mode) is present.  CWF will then include the Test/Production Indicator on the BOI reply trailer 29 that is returned to the A/B MAC or DME MAC .  (See additional details below.)
(Medicare Claims Processing Manual)
Effective with July 7, 2009, at CMSs direction, the BCRC  modified  the CO IF so that the Test/Production indicator, originally created as part of the October 2004 release, is renamed the 4010A1 Test/Production indicator and a new field, the NCPDP-5.1 Test/Production indicator, is also reflected.  In turn, CWF shall 1) accept and process the BCRC -generated modified COIF on a weekly basis; and 2) accept the following values within the two newly defined COIF fields:  N (format not in use for this trading partner); P (trading partner in production); and T (trading partner in test mode). CWF shall also modify the BOI reply trailer (29) to reflect these changes, as further specified under BOI Reply Trailer 29 Processes below.   2.  BOI Reply Trailer 29 Processes  For purposes of eligibility file-based crossover, if CWF se lects a claim for crossover, it shall return a BOI reply trailer 29 to the  A/B MAC or DME MAC.  The returned BOI reply trailer 29 shall include, in addition to COBA ID(s), the COBA trading partner name(s), an A crossover indicator that specifies that the claim has been selected to be crossed over, the insurer effective and termination dates, and a 1- digit indicator [Y=Yes; N=No] that specifies whether the COBA trading partners name should be printed on the beneficiary MSN.  Effective with the October 2004 systems release, CWF shall also include a 1- digit Test/Production Indicator T (test mode) or P (production mode) on the BOI reply trailer 29 that is returned to the A/B MAC or DME MAC.   Effective with July 7, 2009, CWF shall modify the BOI reply trailer (29) to rename the existing Test/Production indicator as 4010A1 Test/Production indicator and rename the NCPDP Test/Production indicator as NCPDPD0 Test/Production indicator.  In addition, CWF shall include a new 1 -byte field NCPDP51 Test/Production indicator as part of the BOI reply trailer (29).   B.  MSN Crossover Messages
(Medicare Claims Processing Manual)
B.  MSN Crossover Messages   Beginning with the October 2004 systems release, when a n A/B MAC  or DME MAC receives a BOI reply trailer 29 from CWF that contains a Test/Production Indicator T (test mode), it shall ignore the MSN Indicator provided on the trailer.  Instead, the A/B MAC  or DME MAC shall follow its existing procedures for inclusion of trading partner names on MSNs for those trading partners with whom it has existing Trading Partner Agreements (TPAs).   Beginning with the October 2004 systems release, when a n A/B MAC or DME MAC  receives a BOI reply trailer 29 from CWF that contains a Test/Production Indicator P (production mode), it shall read the MSN indicator (Y=Yes, print trading partners name; N=Do not print trading partners name) returned on the BOI reply trailer 29.  (Refer to Pub.100- 4, chapter 28, 70.6 for additional details.)   Effective January 5, 2009, when CWF returns a BOI reply trailer (29) to a n A/B MAC  or DME MAC  that contains only a COBA ID in the range 89000 through 89999, the shared system shall suppress all crossover information, including name of insurer and generic message#35.1, from all beneficiary MSNs.  (See chapter 28, 70.6 for details regarding additio nal A/B MAC and DME MAC  requirements.)   In addition, the A/B MAC or DME MAC  shall not issue special provider notification letters following its  receipt of BCRC  Detailed Error Reports when the claims associated COBA ID is within the range 89000 through 89999 (see chapter 28, 70.6.1 for more details.)   C.  Electronic Remittance Advice (835)/Provider Remittance Advice Crossover Messages
(Medicare Claims Processing Manual)
C.  Electronic Remittance Advice (835)/Provider Remittance Advice Crossover Messages   Beginning with the Octobe r 2004 release, when CWF returns a BOI reply trailer (29) that contains a T Test/Production Indicator to the A/B MACs and DME MACs , they shall not print information received from the BOI reply trailer (29) in the required crossover fields on the 835 Elec tronic Remittance Advice or other provider remittance advice(s) that is/are in production.  A/B MACs  and DME MACs shall, however, populate the 835 ERA (or provider remittance advice(s) in production) with required crossover information when they have exist ing agreements with trading partners.   Beginning with the October 2004 release, when CWF returns a BOI reply trailer (29) that contains a P Test/Production Indicator to the A/B MACs and DME MACs , they shall use the returned BOI trailer information to tak e the following actions on the providers 835 Electronic Remittance Advice:   1.  Record code 19 in CLP -02 (Claim Status Code) in Loop 2100 (Claim Payment Information) of the 835 ERA (v. 4010- A1). [NOTE:  Record 20 in CLP -02 (Claim Status Code) in Loop 2100 (Claim Payment Information) when Medicare is the secondary payer.]   2.  Update the 2100 Loop (Crossover Carrier Name) on the 835 ERA as follows:    NM101 [Entity Identifier Code] Use TT, as specified in the 835 Implementation Guide.    NM102 [Entity Type Qualifier] Use 2, as specified in the 835 Implementation Guide.   NM103 [Name, Last or Organization Name] Use the COBA trading partners name that accompanies the first sorted COBA ID returned to you on the BOI reply trailer.    NM108 [Identification Code Qualifier] Use PI (Payer Identification.)    NM109 [Identification Code] Use the first COBA ID returned to you on the BOI reply trailer.  (See line 24 of the BOI aux. file record.
(Medicare Claims Processing Manual)
 NM109 [Identification Code] Use the first COBA ID returned to you on the BOI reply trailer.  (See line 24 of the BOI aux. file record.   If the 835 ERA is not in production and the A/B MAC or  DME MAC  receives a P Test/Production Indicator, the A/B MAC  or DME MAC  shall use the information provided on the BOI reply trailer (29) to populate the existing provider remittance advices that it has in production.  Effective January 5, 2009, if CWF re turns only a COBA ID range 89000 through 89999 on a BOI reply trailer (29) to a n A/B MAC or DME MAC , the associated shared system shall suppress all crossover information (the entire 2100 loop) on the 835 ERA.  Effective October 3, 2011, when a beneficiarys claim is associated with more than one COBA ID (i.e., the beneficiary has more than one health insurer/benefit plan tha t has signed a national COBA), CWF shall sort the COBA IDs and trading partner names in the following order:   1)  Eligibility -based Medigap (30000- 54999); 2) Claim -based Medigap (55000- 59999); 3) Supplemental (00001- 29999); 4) Other Insurer (80000- 80213); 5) Other Insurer (80215 -88999); 6) CHAMPVA (80214); 7) TRICARE (60000- 69999); 8) Medicaid (70000-79999); and 9) Other Health Care Pre -Payment Plan [HCPP] (89000- 89999).  When two or more COBA IDs fall in the same range (see item 24 in the BOI Auxiliary File table above), CWF shall sort numerically within the same range.   3.  CWF Treatment of Non- assigned Medicaid Claims
(Medicare Claims Processing Manual)
3.  CWF Treatment of Non- assigned Medicaid Claims   When CWF receives a non -assigned Medicare claim for a beneficiary whose BOI auxiliary record contains a COBA ID with a current effective date in the Medicaid eligibility -based range (70000 -77999), it shall reject the claim by returning edit 5248 to the A/B MAC (B) shared system only when the Medicaid COBA trading partner is in production mode (Test/Production Indicator=P) with the BCRC .  At the same time, CWF shall only return a Medicaid reply trailer 36 to the A/B MAC (B) that contains the trading partner s COBA ID and beneficiarys effective and termination dates under Medicaid when the Medicaid COBA trading partner is in production mode with the BCRC .  CWF shall determine that a Medicaid trading partner is in production mode by referring to the latest COI F update it has received.   If, upon receipt of CWF edit 5248 and the Medicaid reply trailer (36), the A/B  MAC (B) determines that the non- assigned claims service dates fall during a period when the beneficiary is eligible for Medicaid, it shall convert th e assignment indicator from non-assigned to assigned and retransmit the claim to CWF.  After the claim has been retransmitted, the CWF will only return a BOI reply trailer to the A/B MAC (B) if the claim is to be sent to the BCRC  to be crossed over.   Effective with October 1, 2007, CWF shall cease returning an edit 5248 and Medicaid reply trailer 36 to a DM E MAC.  In lieu of this procedure, CWF shall only return a BOI reply trailer (29) to the DME MAC  for the claim if the COBA Insurance File (COIF) for the State Medicaid Agency indicates that the entity wishes to receive non -assigned claims. NOTE:   Most Medicaid agencies will not accept such claims for crossover purposes.
(Medicare Claims Processing Manual)
If CWF determines via the corresponding COIF that the State Medicaid Agency does n ot wish to receive non -assigned claims, it shall exclude the claim for crossover.  In addition, CWF shall mark the excluded claim with its appropriate claims crossover disposition indicator (see 80.5 of this chapter for more details) and store the claim w ith the information within the appropriate Health Insurance Master Record (HIMR) detailed history screen.   DME MACs  shall no longer modify the provider assignment indicator on incoming non-assigned supplier claims for which there is a corresponding COBA ID  in the Medicaid range (70000 -77999).   4.  Additional Information Included on the HUIP, HUOP, HUHH, HUHC, HUBC and HUDC Queries to CWF   Beneficiary Liability Indicators on Part B and DMAC CWF Claims Transactions   Effective with the January 2005 release, the Part B and DM E MAC shared systems shall be required to include an indicator L (beneficiary is liable for the denied service[s]) or N (beneficiary is not liable for the denied service[s]) in an available field on the HUBC and HUDC queries to CWF for  claims on which all line items are denied.  The liability indicators (L or N) will be at the header or claim level rather than at the line level.   Currently, the DME MAC shared system is able to identify, through the use of an internal indicator, whether a submitted claim is in the National Council for Prescription Drug Programs (NCPDP) format.  The DME MAC shared system shall pass an indicator P to CWF in an available field on the HUDC query when the claim is in the NCPDP format.  The indicator P shal l be included in a field on the HUDC query that is separate from the fields used to indicate whether a beneficiary is liable for all services denied on his/her claim.   The CWF shall read the new indicators passed via the HUBC or HUDC queries for purposes of excluding denied services on claims with or without beneficiary liability and NCPDP claims.   Beneficiary Liability Indicators on Part A CWF Claims Transactions
(Medicare Claims Processing Manual)
Beneficiary Liability Indicators on Part A CWF Claims Transactions   Effective with October 2007, the CWF maintainer shall create a 1 -byte beneficiary liability indicator field within the header of its HUIP, HUOP, HUHH, and HUHC Part A claims transactions (valid values for the field=L or N).   As A/B MACs (A, HHH)  adjudicate claims and determine that the beneficiary has payment liability for any part of the fully denied services or service lines, they shall set an L indicator within the newly created beneficiary liability field in the header of their HUIP, HUOP, HUHH, and HUHC claims that they transmit to CWF.  In addition, as A/B MACs (A, HHH)  adjudicate claims and determine that the beneficiary has no payment liability for any of the fully denied services or service lines that is, the provider must absorb all costs for the fully denied claims they shall include an N beneficiary indicator within the designated field in the header of their HUIP, HUOP, HUHH, and HUHC claims that they transmit to CWF.   Upon receipt of an HUIP, HUOP, HUHH, or HUHC claim that contains an L or N beneficiary liability indicator, CWF shall read the COBA Insurance File (COIF) to determine whether the COBA trading partner wishes to receive original fully denied claims with beneficiary liability (crossover indicator G) or without beneficiary liability (crossover indicator F) or adjustment fully denied claims w ith beneficiary liability (crossover indicator U) or without beneficiary liability (crossover indicator T).
(Medicare Claims Processing Manual)
CWF shall deploy the same logic for excluding Part A fully denied original and adjustment claims with or without beneficiary liability as it now utilizes to exclude fully denied original and adjustment Part B and DME POS claims with and without beneficiary liability, as specified elsewhere within this section.  As of January 4, 2010, CWF shall read action code 8, in addition to action code  1, in association with incoming fully denied original HUIP and HUOP claims.  CWF shall continue to read action code 1 for purposes of excluding all other fully denied original HUHH and HUHA claims.  (See items J and K within this section for more specific s regarding revised logic for exclusion of fully denied HUIP and HUOP adjustment claims.)   If CWF determines that the COBA trading partner wishes to exclude the claim, as per the COIF, it shall suppress the claim from the crossover process.   CWF shall post  the appropriate crossover disposition indicator in association with the adjudicated claim on the HIMR detailed history screen (see 80.5 of this chapter).   In addition, the CWF maintainer shall create and display the new 1- byte beneficiary liability indic ator field within the HIMR detailed history screens (INPL, OUTL, HHAL, and HOSL), to illustrate the indicator (L or N) that appeared on the incoming HUIP, HUOP, HUHH, or HUHC claim transaction.   CWF Editing for Incorrect Values   If an A/B MAC (A, HHH) sends values other than L or N in the newly defined beneficiary liability field in the header of its HUIP, HUOP, HUHH, or HUHC claim, CWF shall reject the claim back to the A/B MAC (A, HHH) or DME MAC  for correction.  Following receipt of the CWF rejec tion, the A/B MAC (A, HHH)  shall change the incorrect value placed within the newly defined beneficiary liability field and retransmit the claim to CWF.   5.  Modification to the CWF Inclusion or Exclusion Logic for the COBA Crossover Process
(Medicare Claims Processing Manual)
5.  Modification to the CWF Inclusion or Exclusion Logic for the COBA Crossover Process   Beginning wit h the October 2006 release, the CWF or its maintainer shall modify its COBA claims selection logic and processes as indicated below.  The CWF shall continue to include or exclude all other claim types in accordance with the logic and processes that it had in place prior to that release.   D.  New A/B  MAC (B)  Inclusion or Exclusion Logic   The CWF shall read the first two (2) positions of the Business Segment Identifier (BSI), as reported on the HUBC claim, to uniquely include or exclude claims from state -specific A/B MACs (B) or DME MACs , as indicated on the COIF.   E.  Exclusion of Fully Paid Claims   The CWF shall continue to exclude Part B claims paid at 100 percent by checking for the presence of claims entry code 1 and determining that each claims allowe d amount equals the reimbursement amount and confirming that the claim contains no denied services or service lines.   The CWF shall continue to read action code 1 and determine that there are no deductible or co -insurance amounts for the purpose of excluding Part A original claims paid at 100 percent.  In addition, CWF shall determine that the Part A claim contained a reimbursement amount before excluding a claim with action code 1 that contained no deductible and co -insurance amounts and that the claim contained no denied services or service lines.   Claims with Fully Paid Lines, without Deductible or Co -insurance Remaining, and Additional Denied Service Lines   New HUBC Line -Level Indicator Field   Effective January 4, 2010, the CWF maintainer create d a new 1 -byte liability denial indicator (LIAB IND) at the service line level for individually denied claim lines in association with the HUBC claim transaction (valid values=B or spaces).   Part B Shared System Requirements
(Medicare Claims Processing Manual)
Part B Shared System Requirements   When the Part B shared system adjudicates claims where most of the claim service detail lines are fully [or 100 percent] paid (i.e., contain allowed amounts per line that are the same as the paid amounts per line and the lines do not carry deductible or co- insurance amounts) but where some detail lines are denied, it shall take the following actions: 1) Input a B value in the newly created 1 -byte LIAB IND field for each denied service line where the beneficiary has payment liability (NOTE:  there may be multiple instances where the B v alue will be applied, contingent upon whether the beneficiary is liable for each of the denied service lines);   2) Input spaces in the newly created 1- byte LIAB IND field for each denied service line where the provider, rather than the beneficiary, is contractually liable for the denied service; and   3) Transmit the HUBC claim to CWF for normal verification and validation processing.   CWF Requirements   The CWF system shall modify its logic for original fully paid claims, without deductible or co -insurance remaining, in association with Part B HUBC claims as follows:   1) Continue to verify the claims entry or action code for confirmation that the claim is an original;  2) Confirm that the claim contains service lines where the amount allowed per line equals the amount paid per line;   3) Check for the presence of a B line LIAB IND in association with any of the denied service lines on the claim;   4) Suppress the claim from the c rossover process if the claim does not contain a B line LIAB IND for any of the denied service lines; and   5) Select the claim for crossover if even one of the denied lines contains a B line LIAB IND.   Upon suppressing the Part B claim from the crossover  process, CWF shall annotate the claim on the Part B claim detail (PTBH) screen with a newly created AF (Fully reimbursable claim containing denied lines with no beneficiary liability) claims crossover disposition indicator.  (See  80.5 of this chapter for more details regarding crossover disposition indicators.)  F.  Claims Paid at Greater than 100 Percent of the Submitted Charge