0% found this document useful (0 votes)
329 views30 pages

837

This document outlines business requirements for implementing HIPAA 5010 compliance for processing health care claims (837) transactions at BCBSMA. Key requirements include: 1) Processing existing 4010A1 transactions while establishing protocols for 5010, 2) Maintaining high performance transaction processing within industry standards, and 3) Supporting increased transaction volume while ensuring system performance and recovery from failures. User acceptance testing will begin in July 2010 with the goal of achieving compliance levels by HHS deadlines of December 2010 and January 2012.

Uploaded by

Arijit Mitra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
329 views30 pages

837

This document outlines business requirements for implementing HIPAA 5010 compliance for processing health care claims (837) transactions at BCBSMA. Key requirements include: 1) Processing existing 4010A1 transactions while establishing protocols for 5010, 2) Maintaining high performance transaction processing within industry standards, and 3) Supporting increased transaction volume while ensuring system performance and recovery from failures. User acceptance testing will begin in July 2010 with the goal of achieving compliance levels by HHS deadlines of December 2010 and January 2012.

Uploaded by

Arijit Mitra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 30

Business Requirements

5010 EDI Transactions


837 – Health Care Claim
Version 1.5
5010 EDI Transactions Business Requirements - 837

1. PROJECT OVERVIEW.............................................................................4

1.1 Project Need / Purpose.....................................................................4

1.2 Expected Results...............................................................................5

1.3 Requested Dates...............................................................................5

2 BUSINESS REQUIREMENTS...................................................................6

2.1 Detailed Business Requirements.......................................................6

2.2 Security Requirements....................................................................19

2.3 Data Requirements.........................................................................20

2.4 Reporting Requirements..................................................................21

2.5 Non-Functional / perfromance Requirements..................................23

3 ASSUMPTIONS, EXCEPTIONS, RISKS, AND ISSUES.............................25

3.1 Assumptions....................................................................................25

3.2 Constraints......................................................................................26

3.3 Risks...............................................................................................27

3.4 Issues.............................................................................................27

Appendices.................................................................................................28

EDI Project Team Page 2 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

Document History

Version Create Date Modified By Section, Page(s)and Text Revised


1.0 1/13/2010 T. Madden  Initial template; first draft.
D. O’Donnell
1.1 1/20/2010 D. O’Donnell  Incorporate comments from initial review.

1.2 1/22/2010 D. O’Donnell  Incorporate comments from the preliminary


internal walk-through.
1.3 1/26/2010 D. O’Donnell  Corrected table of contents.
 Incorporate additional feedback from version 1.2
1.4 1/26/2010 D. O’Donnell  Added APPENDICES.
1.5 2/17/2010 D. O’Donnell  Attached the latest version of the As Is Current
State mapping documentation in the
APPENDICES
 Supplied more detail of the impacted “837 to
TRLog” mappings
 Expand upon transformed data for the NASCO
837 mappings
 Provide more detail on the four business edits.
 Added a new section for the non-functional
requirements
 Removed “Approval Date” and “Approved By”
columns from this Document History table
 Updated 2010 goals for First Pass Throughput
Rate. (received numbers from B. Lawler)

Contributors and Participants

Name Represents Role


Kathy Cumming EDI Project Team  Contributor
Ellen Curley IT  Contributor
Scott Harrington Business Strategy & Program Leadership  Contributor
Donna Jezierski EDI Project Team  Contributor
Kim Karbott Front End Data Services Team(s)  Contributor
Tom Madden EDI Project Team  Contributor
Deirdre O’Donnell EDI Project Team  Contributor
Charles Robertson EDI Project Team  Contributor
Carolyn Thomas SSI  Contributor
Colleen Timberlake EDI Project Team  Contributor
Janet Wholley EDI Project Team  Contributor

EDI Project Team Page 3 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

1 PROJECT OVERVIEW

1.1 PROJECT NEED / PURPOSE


The purpose of this document is to define business requirements that must be implemented
in order for BCBSMA to achieve HIPAA 5010 compliance. There will be separate documents
for each of the following HIPAA transactions:

 Health Care Claim: Institutional (837), Professional (837), Dental (837)


 Health Care Claim Payment/Advice (835)
 Health Care Eligibility Benefit Inquiry & Response (270/271)
 Health Care Claim Status Request & Response (276/277)
 Health Care Services Review – Request for Review & Response (278-13/278-11)

This document summarizes the required changes and highlights the functionality which
needs to be maintained.

The document, in conjunction, with the attached APPENDICES should provide a clear
understanding of what is required to process a HIPAA compliant 837 file through the
BCBSMA EFE.

As agreed upon, the 5010 mapping documents focuses on the specific changes for 5010.
They do no include any current mappings which were not impacted by 5010.

Please keep in mind, the production code is ever evolving. There will be addendum and/or
revisions made to the current state documentation.

EDI Project Team Page 4 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

1.2 EXPECTED RESULTS


1.2.1 Achieve HIPAA 5010 compliance.

1.2.2 Meet Health and Human Services (HHS), Medicare Crossover (COBA) and
BCBSA Key Dates (refer to ’Requested Dates’ section of this document).

1.2.3 Meet or exceed our transaction processing performance level, accuracy, and
timeliness metrics.

1.2.3.1 No degradation to the claims processing systems.

1.2.3.2 No increase in claim suspension rates.

1.2.4 Leverage the new EDI Processor and Transaction Processor to support
increased transaction volume, more atomic processing of transactions, and
improved operations management through transaction visibility.

1.3 REQUESTED DATES


1.3.1 Begin Internal User Acceptance Testing: July 2010

1.3.2 Meet the Health and Human Services Compliance Dates:

1.3.2.1 Achieve Level 1 Compliance (Internal Testing): Completion by December


31, 2010

1.3.2.2 Achieve Level 2 Compliance (Provider/Partner Testing, 5010 Ready):


January 1, 2011 with full migration completed by January 1, 2012

1.3.3 COBA Medicare Crossover partner testing window June 2010 through
December 2010: BCBSMA target date is October 2010

EDI Project Team Page 5 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

2 BUSINESS REQUIREMENTS

EDI Project Team Page 6 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

2.1 DETAILED BUSINESS REQUIREMENTS


2.1.1 Process 4010A1 transactions on the existing platform (SeeBeyond).

2.1.2 *5010* Establish delivery protocols for 4010A1 transactions versus 5010
transactions.

2.1.3 *5010* Allow submitters at least 2-3 industry adopted Secure File Transfer
options for transaction transport. Do not require existing submitters to
change transport mechanism without a definitive business reason.

2.1.4 Maintain a mailboxing option for smaller/less technically proficient submitters


who need to be able to manually drop off and pick up files.

2.1.5 Continue to allow EDI Support staff full view of all submitters’ transactions
and the ability to perform any resubmission tasks on behalf of the submitter
as needed.

2.1.6 *5010* Produce a high performance end-to-end solution that exceeds


industry standard transaction processing times. All components of the
solution must work efficiently together.

2.1.6.1 Provide 24x7x365 access to submit claim files and meet/exceed the
available claim file processing times as outlined in the Current State
documentation (Appendix A).

2.1.6.2 Support three times our existing transaction volume.

2.1.6.3 Develop safeguards to ensure a high system performance.

2.1.7 Provide recovery capabilities for transactions in process at a failure point.


(Take action to resolve the problem at a failure point; once item is resolved;
allow the transaction to continue through its normal process flow.)

2.1.8 *5010* Provide an Enhanced Trading Partner Management solution

2.1.8.1 Create a process for inputting and maintaining Trading Partner


relationships.

2.1.8.2 Offer a Trading Partner Management solution which is user-friendly and


efficient.

2.1.8.3 Flexibility to support the long term end state goal of provider self service
(not required within the 5010 timeline).

2.1.9 *5010* Invoke new 837 DCN (document Control Number) numbering
sequence during the migration period to prevent assigning the same DCN to
different claims processed on different platforms.

EDI Project Team Page 7 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

2.1.9.1 Continue using the existing DCN assignment for transactions processed on
4010A1 platform.

2.1.9.2 *5010* Introduce a new in the DCN numbering sequence for transactions
processed on the new 5010 platform. (Possibly changing the second position
of DCN to be 5.)

2.1.10 *5010* Provide the EDI Support Team the ability to convert 4010A1
transactions into a 5010 transactions to use for testing purposes.

2.1.11 *5010* Implement a nationally recognized HIPAA standard validation tool


that includes timely maintenance releases supporting all code sets.

2.1.11.1 Comply with WEDI SNIP HIPAA edits

2.1.11.2 Provide the ability to ignore any HIPAA edit by transaction and trading
partner.

2.1.11.3 *5010* Edifecs will supply to the EDI Team the new/revised 5010 WEDI
SNIP HIPAA edits 1-5 for evaluation. The evaluation will determine if the
edits should be turned on or off for BCBSMA transactions.

2.1.12 Ensure existing functionality currently delivered through BlueDirect is


preserved. (Refer to Appendices F & G)

2.1.12.1 Provide the ability to compose, schedule, route, cancel, view, edit, clone,
re-queue broadcast messages to NEHEN and/or Direct Submitters (or any
given subset of NEHEN/Direct Submitters).

2.1.12.2 Provide the ability to maintain the submitter-billing relationship information.

2.1.12.3 Provide the ability to retrieve, view, and re-queue for delivery the
Submitter Report.

2.1.13 Maintain the existing EDI Transaction processing and functionality. Please
Refer to Appendix A for more detailed information pertaining to the 4010A1
Current State EDI processing. Highlighted below are some key process flows.

2.1.13.1 Retrieve and accept the HIPAA 837 claim transactions for processing.
Adhere to established frequency and schedules outlined in the 4010A1
Current State document.

2.1.13.2 Create an archive copy of the original input file.

2.1.13.2.1 The original 837 X12 needs to be retained for 10 years.

EDI Project Team Page 8 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

2.1.13.3 Perform Trading Partner validation.

2.1.13.4 Execute HIPAA validation edits. Preserve the existing edit exclusion logic
for each trading partner.

2.1.13.4.1 H1 – EDI Syntax Integrity

2.1.13.4.2 H2 – HIPAA Syntactical Requirements

2.1.13.4.3 H3 – Balancing

2.1.13.4.4 H4 – Situational Testing

2.1.13.4.5 H5 – External Code Set Testing

2.1.13.4.6 H6 – Product types or line of service

2.1.13.4.7 H7 – Implementation Guide-Specific Trading Partners

2.1.13.5 Execute the existing custom business validation edits. (Refer to APPENDIX
A: Current State mapping documents)

2.1.13.5.1 Perform Provider Validation.

2.1.13.5.2 Validate the Header Level Rendering Provider (2310B) is an


authorized BCBSMA NPI Provider

2.1.13.5.3 Validate Line Level Provider (2420A) is an authorized BCBSMA


NPI Provider.

2.1.13.5.4 Perform eligibility check on the submitted Subscriber ID (loop


2010BA, NM109)

3 Determine if the Subscriber ID belongs to BCBSMA member, FEP member, or another


Blues Plan’s member by reading the Plan Profile alpha prefix table.

4 BCBSMA alpha prefixes will have Station Code = BTSA AND Control Plan is 200 or 700
OR Station Code = NMAA AND Control Plan = 701.

5 FEP member is sub id first character = “R” and sub id length = 9

6 If no alpha prefix and the sub id is all numeric, then take then against the BCNSMA
Subscriber ID list.

7 Confirm the Subscriber ID is valid BCBSMA Subscriber ID.

8 Perform format validation on FEP Subscriber ID number (‘R’ followed by eight numeric).

EDI Project Team Page 9 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

9 Bypass the eligibility check on ITS Host Claims (membership belongs to another Blue’s
plan).

9.1.1.1.1 Perform Submitter Billing Relationship edits.

10 Confirm the incoming 837 Billing Provider is authorized to send an 837 for a specific
Submitter ID by evaluating the NPI in the Billing Provider Name loop (2010AA NM109)
and the Submitter ID (ISA06).

11 Validate the 837 data corresponds with data housed our Submitter Billing Relationship
table.

12 Ensure the processing date of incoming 837 is within the effective date range for that
specific Submitter Billing Relationship.

12.1.1.1 Generate and deliver the appropriate X12 acknowledgment(s) back to the
submitter based on the Trading Partner Profile. Currently, we return TA1,
997, 277U.

12.1.1.1.1 Interchange Acknowledgment (TA1); accepted or rejected

12.1.1.1.2 Functional Acknowledgment (997); accepted or rejected

12.1.1.1.3 Unsolicited Claim Status (277) against 4010A1 837 claims


transactions. (Accepted or rejected)

EDI Project Team Page 10 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

12.1.1.2*5010* Flexibility to generate 999 (accepted or rejected) instead of a 997


based on the submitters Trading Partner Profile

12.1.1.3*5010* Generate accepted or rejected Health Care Claim Acknowledgment


(277) for 5010 transactions based on the submitter’s Trading Partner Profile.

12.1.1.4 Generate and deliver the PDF Submitter Report to the submitter.

12.1.1.5*5010* Provide an option to generate and deliver a Submitter Report in a


text format to the submitter based on submitter preference.

13 Some clearinghouses and billing services would prefer to receive the submitter reports
in a text format so they parse the report to their clients

13.1.1.1 Ensure the Submitter Report is available to the EDI Support Team to view
and retransmit. (See Business Requirement 2.1.12.3)

13.1.1.2 Identify the source channel in the transaction tracking product. (e.g.
“NEHEN”, “DIRECT”, etc...)

13.1.1.3Ensure the transformed data contains the appropriate Legacy Provider ID(s)
as a result of the NPI call(s) to Portico Crosswalk.

13.1.1.4Ensure the following transformed data continues to be mapped on the


NASCO enhanced 837.

13.1.1.4.1 Document Control Number (DCN)

13.1.1.4.2 Billing Provider Legacy #

13.1.1.4.3 Claim Rendering Provider Legacy #

13.1.1.4.4 Attending Provider Legacy

13.1.1.4.5 Line Rendering Provider Legacy

13.1.1.4.6 BCBSMA Repository ID (currently, the HLM Rep ID)

13.1.1.4.7 Source of Input value

13.1.1.4.8 Present on Admission (POA) diagnosis information

EDI Project Team Page 11 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

13.1.1.5Translate the X12 transaction into the proper format of the receiving claim
processing system (e.g. TRLog for TPS, enhanced 837 for NASCO).

13.1.1.6Deliver the claim to the correct claim processing system on its defined
scheduled. (APPENDIX A: Current State mapping documents)

13.1.1.6.1 Identify ITS Host, Union Blue local and NASCO 837I and 837P
claims using the existing Plan Profile table and the submitted
Alpha Prefix on the claim record. Use Alpha prefix to compare
against the Plan Profile table for claims received after the
migration date. Alpha Prefix is the first 3 positions of the
2010BA NM109.

13.1.1.6.2 Route active prefixes to NASCO using the following criteria:

14 Program Code = 6 or

15 Program Code = 8 or

16 Control Plan not = 200 or 700

16.1.1.1.1 Route active prefixes to TPS using the following criteria:

17 Control Plan = 200 or 700

17.1.1.1.1 If a match is made on the plan profile table route claim to TPS
or NASCO as indicated and do not process through the
Integrated Data Store (IDS).

17.1.1.1.2 If the prefix is not found on the plan profile table, process
through the IDS to determine if the claim should route to
NASCO.

17.1.1.1.3 If the claim is submitted without a prefix, process through the


IDS to determine if the claim should route to NASCO.

18 *5010* the following are designated as NASCO group types: C1, C2, C3, D1, D2, A3,
H9, C8, NN, S4, S5, and S6.

EDI Project Team Page 12 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

18.1.1 *5010* Modify the ‘837 to TRLog’ mappings to incorporate the 5010
requirements. Unless otherwise noted, the 5010 mappings are the same as
the 4010A1 mappings. The 4010A1, mappings are contained at the end of
the Current State documentation in the Attachment section of Appendix A.
The detail for the 5010 ‘837 to TRLog’ mapping changes are located in
Appendix B. The 4010A1 transformed data mapping for the NASCO enhanced
837 is located in Appendix A. The 5010 mapping changes are highlighted
below:

18.1.1.1 *5010* Pull the ‘Present on Admission’ diagnosis information from the
‘Healthcare Information’ segment instead of the K3 File Information in the
2300 Loop.

Map 2300/HI01-9 to C05-POA-INDICATORS


When 2300/HI01-1 equals 'BK'
Else map spaces

Note: Need to check all occurrences of HIXX-9.

18.1.1.2 *5010* Calculate the Medicare Allowed amounts (C05-MED-ALLOWD; C08-


MED-ALLOWD-AMT). The AMT segment for allowed amount was removed in
5010. Both claims processing systems require these data elements to
correctly adjudicate the claim.

When SBR09 at L 2320 is = equal to MA or MB, and SVD01 in L 2430 is


the same value as 2330B NM109 for the commercial payer: FOR each L
2430 where the SVD01 value is the same as the 2330B NM109 for the
commercial payer - ADD SVD02 and the sum of all line CAS amounts
meeting the following criteria: IF CAS01= PR and CAS 02, 05, 08, 11, 14
or 17 = 1, 2, 3, 122 or 187, add associated dollars from CAS 03, 06, 09,
12, 15 or 18; AND IF CAS 01 = OA and CAS 02, 05, 08, 11, 14 or 17 =
23 or 187, add associated dollars from CAS 03, 06, 09, 12, 15 or 18; AND
IF CAS01 = CO and CAS 02, 05, 08, 11, 14 or 17 = B4 or 104, add the
associated dollars from CAS03, 06, 09, 12, 15 or 18. The result at L 2430
is the C08-MED-ALLOWD-AMT. The sum of all lines C08-MED-ALLOWD-
AMT is moved to C05-MED-ALLOWD-AMT.

For inpatient 837I


L 2330 when SBR SBR 09 is MA or MB,
Add L 2320 AMT 02 Dollar Amount when AMT 01 = D, to the sum of L
2320 CAS amounts as defined:
the sum of all CAS amounts meeting the following criteria: IF CAS01= PR
and CAS 02, 05, 08, 11, 14 or 17 = 1, 2, 3, 122 or 187, add associated
dollars from CAS 03, 06, 09, 12, 15 or 18; AND IF CAS 01 = OA and CAS
02, 05, 08, 11, 14 or 17 = 23 or 187, add associated dollars from CAS 03,
06, 09, 12, 15 or 18; AND IF CAS01 = CO and CAS 02, 05, 08, 11, 14 or
17 = B4 or 104, add the associated dollars from CAS03, 06, 09, 12, 15 or
18.

Move the result to the C05 Medicare Allowed Amount

EDI Project Team Page 13 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

Note if AMT 01 = D is not present, add MIA04 dollar amount to the sum of
the L2320 CAS amounts as defined:
the sum of all CAS amounts meeting the following criteria: IF CAS01= PR
and CAS 02, 05, 08, 11, 14 or 17 = 1, 2, 3, 122 or 187, add associated
dollars from CAS 03, 06, 09, 12, 15 or 18; AND IF CAS 01 = OA and CAS
02, 05, 08, 11, 14 or 17 = 23 or 187, add associated dollars from CAS 03,
06, 09, 12, 15 or 18; AND IF CAS01 = CO and CAS 02, 05, 08, 11, 14 or
17 = B4 or 104, add the associated dollars from CAS03, 06, 09, 12, 15 or
18.

Move the result to the C05 Medicare Allowed Amount

18.1.1.3 *5010* Calculate the Other Insured allowed amounts (C02-OTHER-INSUR-


ALLOWD-AMT; C08-OTHER-INSUR-ALLOWD-AMT). The AMT segment for
allowed amount was removed in 5010. Both claims processing systems
require this data element to correctly adjudicate the claim.

When SBR09 at L 2320 is not equal to MA or MB, and SVD01 in L 2430 is


the same value as 2330B NM109 for the commercial payer: FOR each
L 2430 where the SVD01 value is the same as the 2330B NM109 for the
commercial payer - ADD SVD02 and the sum of all line CAS amounts
meeting the following criteria: IF CAS01= PR and CAS 02, 05, 08, 11, 14
or 17 = 1, 2, 3, 122 or 187, add associated dollars from CAS 03, 06, 09,
12, 15 or 18; AND IF CAS 01 = OA and CAS 02, 05, 08, 11, 14 or 17 =
23 or 187, add associated dollars from CAS 03, 06, 09, 12, 15 or 18; AND
IF CAS01 = CO and CAS 02, 05, 08, 11, 14 or 17 = B4 or 104, add the
associated dollars from CAS03, 06, 09, 12, 15 or 18. The result at L 2430
is the C08-OTHER_INSUR_ALLOWD. The sum of all lines C08-OTHER-
INSUR-ALLOWD is moved to C02-OTHER-INSUR-ALLOWD-AMT

For Inpatient 837I

When L 2320 SBR 09 is not MA or MB,


Add the L 2320 AMT 02 dollar amount when AMT 01 = D, to the sum of L
2320 CAS amounts as defined:
the sum of all CAS amounts meeting the following criteria: IF CAS01= PR
and CAS 02, 05, 08, 11, 14 or 17 = 1, 2, 3, 122 or 187, add associated
dollars from CAS 03, 06, 09, 12, 15 or 18; AND IF CAS 01 = OA and CAS
02, 05, 08, 11, 14 or 17 = 23 or 187, add associated dollars from CAS 03,
06, 09, 12, 15 or 18; AND IF CAS01 = CO and CAS 02, 05, 08, 11, 14 or
17 = B4 or 104, add the associated dollars from CAS03, 06, 09, 12, 15 or
18.

Move the result to the C02 Other Insured Allowed Amount

EDI Project Team Page 14 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

18.1.1.4 *5010* Update mappings to account for new segment and new values used
for lifetime reserve days (C04-LIFETIME-RES-DAYS). In 4010A1, this
information was located in the in L2300 QTY segment. The QTY segment
was deleted in 5010. The lifetime reserve days will now be reported in the
L2300 HI segment.

When L2300/HI01-01, HI02-01, HI03-01, HI04-01, HI05-01, HI06-01,


HI07-01, HI08-01, HI09-01, HI10-01, HI11-01, or HI12-01 equals 'BE'
and corresponding HI##-02 equals '83' (Lifetime Reserve Days Under
Medicare) then map corresponding HI##-05 to C04-LIFETIME-RES-DAYS

18.1.1.5 *5010* Update mappings to account for new segment and new values used
for Co-insurance Days (C04-COINSUR-DAYS). In 4010A1, this information
was located in the in L2300 QTY segment. The QTY segment was deleted in
5010. The Co-insurance Days will now be reported in the L2300 HI
segment.

When L2300/HI01-01, HI02-01, HI03-01, HI04-01, HI05-01, HI06-01,


HI07-01, HI08-01, HI09-01, HI10-01, HI11-01, or HI12-01 equals 'BE'
and corresponding HI##-02 equals '82' (Co-insurance Days) then map
corresponding HI##-05 to C04-COINSUR-DAYS

18.1.1.6 *5010* Update mappings to account for new segment and new values used
for Covered Days (C04-COVERED-DAYS). In 4010A1, this information was
located in L2300 QTY segment. The QTY segment was deleted in 5010. The
Covered Days will now be reported in the L2300 HI segment.

When L2300/HI01-01, HI02-01, HI03-01, HI04-01, HI05-01, HI06-01,


HI07-01, HI08-01, HI09-01, HI10-01, HI11-01, or HI12-01 equals 'BE',
and corresponding HI##-02 equals '80' (Covered Days), then map
corresponding HI##-05 to C04-COVERED-DAYS

18.1.1.7*5010* Update mappings to account for new segment and new values used
for Non-Covered Days (C04-NON-COVERED-DAY). In 4010A1, this
information was located in L2300 QTY segment. The QTY segment was
deleted in 5010. The Non-Covered Days will now be reported in the L2300
HI segment.

When L2300/HI01-01, HI02-01, HI03-01, HI04-01, HI05-01, HI06-01,


HI07-01, HI08-01, HI09-01, HI10-01, HI11-01, or HI12-01 equals 'BE',
and corresponding HI##-02 equals '81' (Non-Covered Days), then map
corresponding HI##-05 to C04-NON-COVERED-DAY

18.1.1.8 *5010* L2000B SBR01 contains new values (A-H, U) to identify Payers 4-
11 and Unknown. Update the mapping for C02-OTHER-INSUR-IND.
If SBR01 = 'P' or 'U'

EDI Project Team Page 15 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

Map 'N' to C02-OTHER-INSUR-IND


Else
Map 'Y' to C02-OTHER-INSUR-IND

Overlay C02-OTHER-INSUR-IND after evaluating the following:

If L2320 SBR09 not = Medicare ('MA’ or 'MB'')


If AMT02 > 0
Map (Override) 'F' to C02-OTHER-INSUR-IND
Else If AMT02 = 0
Map (Override) 'D' to C02-OTHER-INSUR-IND

If L2320 SBR09 = Medicare ('MA’ or 'MB'')


Map (Override) 'N' to C02-OTHER-INSUR-IND

18.1.1.9 *5010* L2000B SBR01 contains new values (A-H, U) to identify Payers 4-
11 and Unknown. Update the mapping for C01-UNPROCESSED.

If SBR01 (2000B) = 'T', or 'A' through 'H'


Map 'T' to C01-UNP-REASON

18.1.1.10 *5010* L2320 SBR01 contains new values (A-H, U) to identify Payers
4-11 and Unknown. Update the mapping for ‘Other Subscriber Information’.

If 2000B SBR01 not = 'P' and


If 2320 SBR01 = 'P'
Map loop 2320 as per 4010A1
Else
Ignore loop 2320
Else
Ignore loop 2320

Note: If there is more than one occurrence of the 2320 loop and the
first is not for the Primary 'P', subsequent loops should be checked and
the Primary 'P' loop mapped if it is found.

18.1.1.11 *5010* The Medicare values have changed in 2330 SBR segment.
Update mapping from 2330A NM109 to C05-MED-HIC-NUM.

If SBR09 = Medicare ('MA' or 'MB')


Map 2330A NM109 to C05-MED-HIC-NUM

EDI Project Team Page 16 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

18.1.1.12 *5010* The insurance type code mappings changed from SBR05 to
SBR09. Map 2430 SVD02 and all CAS elements just as 4010A1 with only
exception being to interrogate the SBR09 Medicare values of ‘MA’ or 'MB'
instead of SBR05 value of 'CP', 'MB', 'MI', or 'MP' Bulleted below are
impacted TRLog fields

19 C02-OPL-OI-DEDUCT-A

20 C02-OPL-OI-COINS-A

21 C02-OPL-CO-PAY-AMT-A

22 C02-OTHER-INSUR-DOLR

23 C04-PRIOR-PYMTS-PRI-AMT

24 C05-MED-DEDUCT-AMT

25 C05-MED-COINSUR-AMT

26 C05-MED-PAID-AMT

27 C08-MED-PAID

28 C08-MED-DEDT

29 C08-MED-COIN

30 C08-OPL-OI-PAID-A

31 C08-OPL-OI-DEDUCT-A

32 C08-OPL-OI-COINS-A

33 C08-OPL-CO-PAY-AMT-A

34 C08-OTHER-INSUR-DOLLAR

34.1.1.1*5010* The insurance type code mappings changed from SBR05 to SBR09.
Update the professional mapping for C01-ICN-CLAIM-CLASS.

If SBR09 = 'MA' or 'MB'


Map '8' to C01-ICN-CLAIM-CLASS

Note: The value of '8' must also be populated to the same TRLog field
in records C02-C08.

EDI Project Team Page 17 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

34.1.1.2*5010* The insurance type code mappings changed from SBR05 to SBR09.
Update the professional mapping for C01-CLAIM-CLASS.

If SBR09 = 'MA' or 'MB'


Map '8' to C01-CLAIM-CLASS

Note: The value of '8' must also be populated to the same TRLog field
in records C02-C08.

34.1.1.3*5010* Update the institutional mapping for C01-CLAIM-CLASS (This might


only be a documentation update to include the Note – need HP technical to
verify.)

If SBR09 = 'MA' or 'MB'


Map '7' to C01-CLAIM-CLASS

Note: The value of '7' must also be populated to the same TRLog field
in records C02-C08.

34.1.1.4*5010* The insurance type code mappings changed from SBR05 to SBR09.
Update the professional mapping for C08-OPL-OI-PAID-A

If SBR09 not = Medicare ('MA’ or 'MB')


Map SVD02 to C08-OPL-OI-PAID-A

If SVD02 > 9 bytes (including decimal value)


Default C08-OPL-OI-PAID-A to all 9's

34.1.1.5*5010* The insurance type code mappings changed from SBR05 to SBR09.
Update the professional mapping for C08-OTHER-INSUR-DOLLAR

If 2320 SBR09 not = Medicare ('MA’ or 'MB')


Map SVD02 C08-OTHER-INSUR-DOLLAR

If SVD02 > 9 bytes (including decimal value)


Default C08-OTHER-INSUR-DOLLAR to all 9's

34.1.1.6*5010* The insurance type code mappings changed from SBR05 to SBR09.
Update the professional mapping for C08-MED-PAID

If 2320 SBR09 = Medicare ('MA' or 'MB'')


Map C08-MED-PAID

If SVD02 > 9 bytes (including decimal value)


Default C08-MED-PAID to all 9's

EDI Project Team Page 18 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

34.1.1.7*5010* The Other Payer Patient Responsibility Amount segment was deleted
in 5010. A new Remaining Patient Liability segment was created in its place.
Update the mappings for C02-OPL-OI-SUB-LIAB-A.

Map AMT02 (Loop 2320) Monetary Amount - Remaining Patient


Liability to C02-OPL-OI-SUB-LIAB-A when AMT01 = ‘EAF’ (Amount
Owed).

34.1.1.8*5010* In 4010A1, 2300 - Principal, Admitting and E-Code and Patient


Reason For Visit Diagnosis Information were all in the same segment. In
5010, they each have the own segment.

34.1.1.8.1 Update mapping for C04-E-DIAGNOSIS-CODE

If HI01-1 = BN
Map HI01-2 to C04-E-DIAGNOSIS-CODE

34.1.1.8.2 Update the mapping for C04-PRIMARY-DIAG and


If HI01-1 = BK
Map HI01-2 to C04-PRIMARY-DIAG

34.1.1.8.3 Update the mapping for C08-DIAGNOSIS-CODE


If HI01-1 = BK
Map HI01-2 to C08-DIAGNOSIS-CODE

34.1.1.9*5010* New codes were added to Dental PAT01. Update the mapping for
C02-PAT-RELATION to accommodate the new values.

For 5010, map the default of '4' to C02-PAT-RELATION for the new 5010
values. Otherwise, maintain 4010A1 mapping.

EDI Project Team Page 19 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

34.1.2 *5010* Modify the enhanced NASCO 837P mappings (Refer to APPENDIX A)

34.1.2.1Replace REF01 qualifier ‘1B’ with ‘G2’ when populating a legacy id


numbering in REF02.

34.1.3 *5010* Modify the enhanced NASCO 837I mappings. (Refer to APPENDIX A)

34.1.3.1Replace REF01 qualifier ‘1A’ with ‘G2’ when populating a legacy id


numbering in REF02.

34.1.4 *5010* Support both 4010A1 and 5010 formats during the dual use
migration period.

34.1.4.1Ability to retrieve, accept, and process a 4010A1 version of the 837 claim
record on the existing platform.

34.1.4.2*5010* Ability to retrieve, accept, and process a 5010 version of the 837
claim record on the new platform.

34.1.5 Reject any 4010A1 transaction received after the transition period (currently
defined as being on or after January 1, 2012.)

34.2 SECURITY REQUIREMENTS


34.2.1Provide Identity and Access Management (Security Requirements)

34.2.1.1Ensure submitters only have access to their information.

34.2.1.2Make certain submitters can only conduct transactions for which they have
been approved. (These would be the transactions designated in their
Trading Partner Agreement with BCBSMA.)

34.2.1.3Create a solution that is not or does not become overly cumbersome (e.g.
minimal work effort required by BCBSMA to add a new transaction type to
an existing submitter).

34.2.1.4Create a process that does not impose an undue burden on the submitter
(e.g. excessively frequent password resets etc…).

34.2.1.5Avoid recommending an “all submitter” solution if our current submitters are


not capable of supporting the recommended solution.

EDI Project Team Page 20 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

34.3 DATA REQUIREMENTS


34.3.1As part of this project, no new data elements are being added to the TRLog to
adjudicate a claim which was submitted via the 837 5010 format.

34.3.2Other projects which request new data element TRLOG mappings will be
included in this project.

34.3.3Read Portico Crosswalk table to obtain the legacy numbers

34.3.4NPI list from Portico

34.3.5Plan Profile extract to determine claim routing.

34.3.6Local Plan Prefix table for used for the business edits to determine if the
Subscriber ID is BCBSMA or ITS Host. (True source of the data is the Plan
Profile extract job run out of TPS.)

34.3.7Listing for BCBSMA Subscriber ID from Integrated Data Store (IDS).

34.3.8 Read to IDS for the claim routing logic if no alpha prefix was submitted on
the 837.

34.3.9Submitter Billing Relationship table

EDI Project Team Page 21 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

34.4 REPORTING REQUIREMENTS


34.4.1Produce an extract of the Submitter Billing Relationship entries.
(Implemented with ALDEA # 189951, production date – January 29, 2010.)

34.4.1.1This extract has many different purposes; one of being it is used as an audit
tool to evaluate claim submission rate by submitter and/or NPI.

34.4.1.2Refer to Appendix C for test example of extract file.

34.4.2Generate an email notification to the EDI Team indicating the Submitter


Billing Relationship table extract is available to be picked up from the
Tumbleweed server.

34.4.2.1Refer to Appendix D for test example of email notification.

34.4.3Capability of Transaction tracking

34.4.3.1Allow in-flight transaction visibility which enable the business to see the
transaction process flows and proactively manage (in conjunction with
IT/HP/etc) bottlenecks, performance issues, and connectivity failures.

34.4.3.1.1 Send alerts for unplanned situations, backlogs, connectivity


concerns etc…

34.4.3.1.2 Provide visibility and reporting on transactions of all types.

34.4.4Provide the capability to perform transaction tracking, balancing, and


reporting against stored X12 transactions.

34.4.4.1Perform updates at the different phases of processing to allow operations to


track the progress of the claim.

34.4.4.2Institute an ACR (Automatic Controls Reporting) process which


acknowledges every record that is passed from one component to another
component. The records sent balances with the records received.

34.4.4.3Link related transactions (e.g. 837 and 835)

34.4.5Allow users to search and view X12 transactions

34.4.5.1Enable a variety of search mechanisms to retrieve transactions.

34.4.5.1.1 By individual transactions (e.g. DCN/ICN or Trace Number)

34.4.5.1.2 By a list of 20 individual transactions

34.4.5.1.3 By receipt date or date range

34.4.5.1.4 By Error Code

EDI Project Team Page 22 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

34.4.5.1.5 By 837 claim data element fields

34.4.5.1.6 By Submitter ID for receipt date/date range and/or Error Code,


and/or transaction type

34.4.5.1.7 By Transmission ID

34.4.5.1.8 By Billing Provider NPI for receipt date/date range and/or Error
Code

34.4.5.1.9 By any combination of these parameters

34.4.6 Store all versions of X12 transactions:

34.4.6.1Native format received from submitter.

34.4.6.2User-friendly format for internal use

34.4.6.3Enhanced transformation format (i.e. the enhanced 837 transaction sent to


NASCO) when applicable.

34.4.6.4A transformation transaction will be stored independently. For example:

34.4.6.4.1 X12 native format sent in by submitter.

34.4.6.4.2 Enhanced 837 transaction sent over to NASCO

34.4.7Track daily claims receipts from the various channels/submitters. (See


appendix H for example of current reports)

34.4.7.1Identify the number of total claims received, the number of claims accepted,
and the number of claims that error’d.

34.4.7.2Sub total of those daily claim counts by transaction type (837I, 837P, and
837D) within each channel.

34.4.7.3Roll-up daily counts into weekly, monthly, yearly claims counts.

EDI Project Team Page 23 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

34.5 NON-FUNCTIONAL / PERFROMANCE REQUIREMENTS


34.5.1Maintain or exceed the current EDI rates for claims submissions

34.5.1.1 2010 Goal for Professional: 93.0%

34.5.1.2 2010 Goal for Institutional: 96.5%

34.5.1.3 2010 Goal for Dental: 45%

Note: For reference purposes only, bulleted below are actual numbers:
 Month of August 2009 for Professional: 92.7%
 Month of August 2009 for Institutional: 95.4%
 Month of August 2009 for Dental: 44.7%
 Month of August 2009 Overall: 91.8%
 2009 YTD through August for Professional: 92.3%
 2009 YTD through August for Institutional: 95.7%
 2009 YTD through August for Dental: 45.1%
 2009 YTD through August Overall: 91.6%

EDI Project Team Page 24 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

34.5.2 Meet or exceed our transaction processing performance timeliness metrics.

34.5.2.1 Current response for NEHEN/Direct submitters is within 20 minutes.

34.5.2.2 Provider expects a maximum of 1 hour turnaround time.

34.5.3 Meet or exceed our industry leading claims First Pass Throughput Rate.

34.5.3.1 2010 Goal for TPS FPR: 81.5%

34.5.3.2 2010 Goal for TPS Operational FPR: 86.5%

34.5.3.3 2010 Goal for NASCO FPR: 85%

34.5.3.4 2010 Goal for NASCO Operational FPR: 90%

Note: For reference purposes only, bulleted below are actual numbers:

35 August 2009 TPS FPR: 84.23%

36 August 2009 TPS Operational FPR: 89.4%

37 August 2009 NASCO FPR: 82.3%

38 August 2009 NASCO Operational FPR: 86.7%

38.1.1Produce, update, maintain audit log of all changes, and distribute to the EDI
Support Team the “new current state documentation” for all X12 EDI
processing.

38.1.2 Assure the transition to the new EDI Platform has minimal impact to our
business partners (submitters, vendors, etc…).

EDI Project Team Page 25 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

39 ASSUMPTIONS, EXCEPTIONS, RISKS, AND ISSUES

39.1 ASSUMPTIONS
39.1.1Joint requirement session(s) will be held with all impacted parties (System
Integrator, HP, Edifecs, BCBSMA EDI Support, and BCBSMA IT) to review,
finalize, and sign-off on the content of within this document.

39.1.2Tumbleweed will still be used as one of the delivery protocols for


NEHEN/Direct submitters.

39.1.3EDI Support Team will have the ability to resubmit an 837 file on behalf of the
submitter.

39.1.4NASCO will provide specifications defining “where, when, and how” to send
4010A1 transactions vs. 5010 transactions.

39.1.5There are no known changes to Portico needed to support transaction


processing.

39.1.6Out of scope for 5010 - ICD-10.

39.1.7Out of scope for 5010 - Scanner claims. Migrating Scanner off 4010A1 will be
addressed with the shutdown of the SeeBeyond platform.

39.1.8Out of scope for 5010 - Enhancement to process Dental claims on scanner


(837D). This will be addressed with the Scanner migration off SeeBeyond.

39.1.9 Out of scope for 5010 - the business opportunity to automate EDI
adjustments. This will be pursued at a later date.

39.1.10 Out of scope for 5010 – on an 837D, there is an opportunity to map


diagnosis in support of the diabetes and heart disease benefit - cleaning every
3 months, map to header medical diagnosis fields. It might be addressed at a
later time, if at all.

39.1.11 IT will ensure quality software delivery with no major defects

39.1.12 Any IP address changes, the information needs to be communicated


the EDI Team to circulate to the submitters as well as publish updated to
Companion Guides.

39.1.13 A Trading Partner web set up and management tool will be


productionalized to meet the 5010 Mandate.

39.1.13.1 This application may need interface with BlueDirect (EDI Support web
application tool.

EDI Project Team Page 26 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

39.1.14 Need to support SSI and FEP Service Center with ITS, BlueSquared,
or FEP 5010 requirements. These requirements are expected to be published
at the end of 2010.

39.1.15 Testing requirements will be defined in the Master Test Strategy


Document(s).

39.1.15.1 BCBSMA will test with our Trading Partners to ensure HIPAA
compliance with 5010 requirements

39.1.15.2 Front-end user-friendly test tool will be made available to BCBSMA


users. This test tool should point to the UA/Test environment which

39.2 CONSTRAINTS
39.2.1Vendor must be 5010 ready within project timelines:

39.2.1.1Emdeon will remediate their platform to be HIPAA 5010 compliant.

39.2.1.2BCBSMA will work with our business associates such as our pharmacy
benefit manager to ensure they are meeting HIPAA 5010 compliance

39.2.1.3NASCO 5010 ‘837 to TRLog’ mappings were submitted in November 2009.


Any changes made to these mappings will need to go through the Change
Control process. Any Plan making changes to these mappings will incur
additional costs to implement those changes.

39.2.2The new EDI platform must be designed and developed to meet the 5010
Mandate timelines.

EDI Project Team Page 27 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

39.3 RISKS
 The new EDI infrastructure to support 5010 may not be available in test/production
to meet the compliance timelines.
 Hewlett Packard (HP) contract termination.
 Leaning curve on all sides. BCBSMA adapting to the new vendors methodologies.
New vendors learning our business practices.

39.4 ISSUES
 Establish SLAs for each function/vendor.
 Contingency plan needed in the event the new EDI platform will not be in place to
meet the 5010 Mandate timelines.
 Identify an EDI POC (Point of Contact).
 Current production state is always evolving. Need effective measures in place to
ensure upcoming production changes are relayed to the 5010 project team.
 Establish a timely process to install the new/revised 5010 WEDI SNIP HIPAA edits
level 1-5. (Ongoing process)
 Establish a Change Control process to track any changes/modifications to the
business requirements.
 Possible cut-over issues for transactions received and/or processed from December
31, 2011 - January 1, 2012.
 The plan is to onboard Mass Medicaid as a direct submitter. Outstanding question is
will we be required to pursue a change for Medicaid subrogation claims (BTH03 =
31).

EDI Project Team Page 28 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

APPENDICES
APPENDIX A: Current State mapping documents (V 1.4 dated February 3, 2010)

M:\CLAIMS\EDI
TEAM\5010 information\4010A1 - Current State documentation from HP\837\Hipaa 4010 837 Current State v1.4.zip

APPENDIX B: 5010 ‘837 to TRLog’ mappings

M:\CLAIMS\EDI
TEAM\5010 information\Business Requirements\837\Attachments\Appendix B - 4010A1 to 5010 mappings.zip

APPENDIX C: Extract of the Submitter Billing Relationship table entries from the Test
environment

M:\CLAIMS\EDI
TEAM\5010 information\Business Requirements\837\Attachments\Appendix C - billing_providers_01052010.zip

APPENDIX D: Test environment email notification indicting Submitter Billing Relationship


table extract is available to be picked up from the Tumbleweed server.

M:\CLAIMS\EDI
TEAM\5010 information\Business Requirements\837\Attachments\Appendix D - email notification v1.msg

APPENDIX E: Coordination of Benefits Agreement (COBA) HIPAA 5010 Companion Guide

M:\CLAIMS\EDI
TEAM\5010 information\Business Requirements\837\Attachments\Appendix E - COBA-HIPAA-5010CompanionGuide.zip

APPENDIX F: Business Requirements for PIV activity 20001 which created the EDI Support
web tool (BlueDirect)

M:\CLAIMS\EDI
TEAM\5010 information\Business Requirements\837\Attachments\Appendix F - SMR for web tool.zip

APPENDIX G: Use case for BlueDirect web tool implemented with activity 20001

M:\CLAIMS\EDI
TEAM\5010 information\Business Requirements\837\Attachments\Appendix G - Use cases for BlueDirect.zip

APPENDIX H: Reporting examples (Cognos, HML, Ad hoc reports)

EDI Project Team Page 29 of 30 07/31/2019


5010 EDI Transactions Business Requirements - 837

M:\CLAIMS\EDI
TEAM\5010 information\Business Requirements\837\Attachments\Appendix H - report examples.zip

EDI Project Team Page 30 of 30 07/31/2019

You might also like