Extend IBM WebSphere Transformation Extender HIPAA Pack

Enrich the 277CA Acknowledgement

The IBM® WebSphere® Transformation Extender (WTX) Pack for HIPAA Electronic Data Interchange (EDI) includes artifacts for HIPAA compliance validation and generation of acknowledgements, including the X12 5010 Health Care Claim Acknowledgement, 277CA transaction. External code sets govern the claim status codes included within the 277CA acknowledgement. The external code sets are not delivered in the WTX Pack; however, the generated 277CA acknowledgements can be enriched to provide more granular reporting. This article shows you how to leverage the artifacts provided by the WTX Pack to create a custom solution that produces detailed status codes in the 277CA transaction.

Share:

Lori A. Napoli (lanapoli@us.ibm.com), Executive IT Specialist, IBM

Lori's photographLori Napoli is an Executive IT Specialist in IBM Software Group. She currently leads WebSphere Services for the healthcare industry. Lori's 25 years of experience in enterprise application software and middleware development includes roles in consulting, design, development, deployment, testing and quality assurance. As a consultant, she worked in architecture, development, and testing of Service Oriented Architecture (SOA), Business Process Management (BPM) and web application projects.



02 January 2013

Introduction

You can use the artifacts that are provided in the IBM WebSphere Transformation Extender (WTX) Pack for HIPAA EDI to improve the status reporting capabilities of the 5010 Health Care Claim Acknowledgement (277CA). The 277CA is generated using the WTX Pack; however, the WTX Pack does not reference the external code sets that govern the status codes in the generated 277CA. For this reason, the status codes in the 277CA are generic and sometimes do not adequately describe the status of the healthcare claim. This article provides an example in which two fields in the 277CA are enriched using the artifacts from the WTX Pack. To enrich the STC01-1 field and the STC01-2 field, follow these steps:

  1. Generate the 277CA using the WTX Pack for HIPAA EDI
  2. Identify and map compliance errors
  3. Enrich the 277CA

Frequently used abbreviations

  • 277CA: X12 5010 Health Care Claim Acknowledgement
  • WTX Pack: IBM WebSphere Transformation Extender (WTX) Pack for HIPAA Electronic Data Interchange (EDI)

Generate the 277CA using the WTX Pack for HIPAA EDI

The 277CA is an acknowledgement of the Health Care Claim (837) transaction. The 277CA contains information about the pre-process status of the healthcare claim. This section explains how to generate the 277CA so that it reports individual claim errors separately at the claim level. When you follow this process to generate the 277CA, the generated 277CA includes the Claim Level Status Information (STC) segment, which contains the following fields that are governed by external codes sets:

  • STC01-1 - This health care claim status industry code maps to the Code Source 507: Health Care Claim Status Category Code in the external code source (see Resources).
  • STC01-2 - This health care claim status industry code maps to the Code Source 508: Health Care Claim Status Code in the external code source (see Resources).

To generate the 277CA, perform these tasks:

  1. Specify parameter file settings for the compliance map
  2. Select a claim transaction with claim-level errors
  3. Run the claim transaction through the compliance map

Specify parameter file settings for the compliance map

You use the HIPAA compliance map to generate the 277CA and the parameter file to configure the compliance map. Table 1 shows the settings in the parameter file that are applicable to the 277CA.

Table 1. Compliance parameter settings for 277CA
Parameter File Setting Values
Claim_Level_Rejection Y – Enable Claim Level Rejection
N - Disable Claim Level Rejection
HIPAA_277CA_Enabled A – Generate Always
E – Generate only on Error
N - Never Generate
Clm_Lev_Rej_Level P – Report at Provider Level
C – Report at Claim Level

In this example, you generate the 277CA so that it reports each individual claim error separately at the claim level. To configure the compliance map, specify the following values in the parameter file:

  • Claim_Level_Rejection = Y
  • Clm_Lev_Rej_Level = C
  • HIPAA_277CA_Enabled = A or E

For more information about the parameter file, see the IBM WebSphere Transformation Extender Information Center (see Resources).

Select a claim transaction with claim-level errors

Next, select a claim transaction to run though the compliance map. When selecting a claim transaction, ensure that the claim transaction contains claim-level errors. You can use the sample 5010 Professional Claim (837) transaction that is supplied by the WTX Pack (install_dir/ packs/healthcare_v4.3.2/hipaa/data/837p_5010a1_examples.dat) and then modify the transaction so that the first claim is rejected at the claim level. The other claim in the transaction is compliant. Thus, the 999 acknowledgement reports "Accepted but Errors Noted". If you use a transaction that contains only rejected claims, the 999 acknowledgement reports "Rejected" and contains appropriate error information. Listing 1 shows the 5010 Professional Claim (837) transaction.

Listing 1. HIPAA 5010 Professional Claim Transaction (837)
ST*837*1323*005010X222A1
BHT*0019*00*244579*20061015*1023*CH
NM1*41*2*PREMIER BILLING SERVICE*****46*TGJ23
PER*IC*JERRY JAMES*TE*3055552222*EX*231
NM1*40*2*KEY INSURANCE COMPANY*****46*66783JJT
HL*1**20*1
PRV*BI*PXC*203BF0100Y
NM1*85*2*BEN SANGFORD SERVICE*****XX*9876543210
N3*234 SEAWAY ST
N4*MIAMI*FL*33111
REF*EI*587654321
NM1*87*2
N3*2345 OCEAN BLVD
N4*MIAMI*FL*33111
HL*2*1*22*1
SBR*P**2222-SJ******CI
NM1*IL*1*SMITH*JANE****MI*JS00111223333
NM1*PR*2*KEY INSURANCE COMPANY*****XV*999996666
N4*MAIMI*FL*33111
REF*G2*KA6663
HL*3*2*23*0
PAT*19
NM1*QC*1*LARKINS*THEODORE
N3*236 N MAIN ST
N4*MIAMI*FL*33413
DMG*D8*19730501*M
CLM*16463774*101***11:B:1*Y*A*Y*I**AA
REF*D9*17312345600006351
NTE*AD*WILL CAUSE T2 ERROR
HI*BK:0340*BF:V7389
LX*1
SV1*HC:99213*40*UN*1***1
DTP*472*D8*20061003
LX*2
SV1*HC:87070*15*UN*1***1
DTP*472*D8*20061003
LX*3
SV1*HC:99214*35*UN*1***2
DTP*472*D8*20061010
LX*4
SV1*HC:86663*10*UN*1***2
DTP*472*D8*20061010
CLM*26463774*100***11:B:1*Y*A*Y*I
REF*D9*17312345600006351
HI*BK:0340*BF:V7389
LX*1
SV1*HC:99213*40*UN*1***1
DTP*472*D8*20061003
LX*2
SV1*HC:87070*15*UN*1***1
DTP*472*D8*20061003
LX*3
SV1*HC:99214*35*UN*1***2
DTP*472*D8*20061010
LX*4
SV1*HC:86663*10*UN*1***2
DTP*472*D8*20061010
SE*58*1323

Run the claim transaction through the compliance map

After you configure the parameter file and modify the 5010 Professional Claim (837P), run the modified claim transaction through the compliance map. The 277CA is generated. Figure 1 shows the generated 277CA (line numbers are included in the figure).

Figure 1. 5010 Healthcare Claim Acknowledgement (277CA)
5010 Health Claim Acknowledgement (277CA)

Line 28 in Figure 1 displays the "TRN*2*16463774" code. This line is the Trace segment (TRN) that includes the claim submitter ID reference number from the claim (16463774). Line 29 displays the "STC*A1:19*20120724*U*101" code. This line is the STC segment (STC) that reports the status of the claim. The status information for the claim is mapped to the corresponding definitions in the external code sets, as shown in this example:

STC01-1 = A1

"Acknowledgement/Receipt-The claim/encounter has been received. This does not mean that the claim has been accepted for adjudication."

STC01-2 = 19

"Entity acknowledges receipt of claim/encounter."

Figure 2 shows the compliance map rules, where Logical IndustryCD Sub_Element="A1" and Status IndustryCD Sub_Element="19". The values for both STC01-1 and STC01-2 are governed by external code sets that are not supplied with the WTX Pack. Thus, STC01-1 and STC01-2 are hardcoded within the map to always return A1:19 For this reason, line 31 in Figure 1 also shows the status code values for the accepted claim as A1:19.

Figure 2. Compliance map claim status code rules
Compliance map claim status code rules

If you look at the translated acknowledgement generated from the WTX Pack for the compliance validation of this transaction, you see the particular errors for this claim. Listing 2 shows the translated acknowledgement with errors.

Listing 2. Translated acknowledgement
INTERCHANGE Sequence: 1 Control Number: 000000001
TYPE 2: ERRORS NOTED TYPE 3: ERRORS NOTED TYPE 4: ERRORS NOTED
 FUNCTIONAL GROUP Sequence: 1 ID: HC Control Number: 42
  TYPE 2: ERRORS NOTED TYPE 3: ERRORS NOTED TYPE 4: ERRORS NOTED
   TRANSACTION SET Sequence: 1 TransactionSetID: 837 Transaction Set Control Number: 1323
    TYPE 2: REJECT TYPE: REJECT TYPE 4:REJECT
     SEGMENT At position: 29 NTE{Note/Special Instruction} in loop 2300
      TYPE 2: error
       ELEMENT NTE01 {Note Reference Code}
        TYPE 2: error
        Error Code: 4{Data element too short.}
        Data Content: AD
     Segment At position: 27 CLM {Health Claim} in loop 2300
      Type 3: error
       Element CLM02 {Monetary Amount}
        TYPE 3: error
        Error Code: 010 {Total Out of Balance}
        Error Description: 34703 2300 CLM02 = SUM(2400 SV102)
        Data Content: 101
      SEGMENT At position: 27 CLM {Health Claim} in loop 2300
       TYPE 4: error
        ELEMENT CLM11 {Related Causes Information}
         Type 4: error
         Error Code: 848 {Incorrect Data}
         Error Description: 34707 2300 DTP01="439" must be present when CLM11-01="AA","OA"

Although the status information reported in the 277CA is correct, the 277CA does not provide enough description about the error causing the rejection. In subsequent sections of this article, you learn how to enrich STC01-1 and STC01-2 to provide the following more detailed error messages:

Claim Note Error:

  • STC01-1 = A7

    "Acknowledgement/Rejected for Invalid Information - The claim/encounter has invalid information as specified in the Status details and has been rejected."

  • STC01-2 = 704

    "Claim Note Text"

Monetary Amount Error:

  • STC01-1 = A7

    "Acknowledgement/Rejected for Invalid Information - The claim/encounter has invalid information as specified in the Status details and has been rejected."

  • STC01-2 = 400

    "Claim is out of balance"

Related Causes Information Error:

  • STC01-1 = A6

    "Acknowledgement/Rejected for Missing Information - The claim/encounter is missing the information specified in the Status details and has been rejected."

  • STC01-2 = 727

    "Accident date"


Identify and map compliance errors

Some errors that are generated by the compliance map are defined in the hipaa_X12_qualifer.dat file. These errors are identified by a five-digit error identifier. Other errors are defined by the tack_codetable.dat file. This section explains how to identify compliance errors and map compliance errors to claim status category codes and claim status codes. Perform these tasks:

  1. Identify errors defined in hipaa_X12_qualifer.dat
  2. Map hipaa_X12_qualifer.dat file errors to claim status category codes and claim status codes
  3. Identify errors defined in tack_codetable.dat
  4. Map tack_codetable_dat file errors to claim status category codes and claim status codes

Identify errors defined in hipaa_X12_qualifer.dat

Start by identifying the compliance errors that must be reported in the 277CA. To identifiy the errors, examine the output of card 2 in the compliance_check map. The merged_segment_check blocks of the compliance summary contain error information. Listing 3, Listing 4, and Listing 5 show the merged_segment_check blocks from the compliance summary (The code samples are truncated in Listing 4 and Listing 5.).

Listing 3. merged_segment_check (1) from compliance summary
<merged_segment_check>
  <result>000000002900000NTE   8   2300
          000000002900100NTE   4
  </result>
</merged_segment_check>
Listing 4. merged_segment_check (2) from compliance summary
<merged_segment_check>
<result>000000002700200CLM   010    2300  824  TED  34703  2300  CLM02 = SUM(240
        000000000000000      010          824  TED  CTX
</result> 
</merged_segment_check>
Listing 5. merged_segment_check (3) from compliance summary
<merged_segment_check>
   <result>000000002701100CLM   848    2300  824  TED  34707  2300  DTP01="439" mu
           000000000000100DTP   848    2300  824  TED  CTX
   </result>
</merged_segment_check>

The compliance summary contains three separate merged_segment_check blocks that are reported by type of error: type 2, type 3 and type 4. The WTX Pack provides a type tree that defines this data (install_dir/packs/healthcare_v4.3.2/hipaa/trees/compliance_check.mtt, under Segment Segment_Error Loop Data).

Listing 6 shows the pack type tree definition for the segment_error loop.

Listing 6. HIPAA pack tree definition for segment_error loop
1#SegmentError (segment Segment_error Loop Data) 
SegmentError
   Segment Segment_Error Record (0:1)
      Segment_Position Segment_Error Field
      Element_Position Segment_Error Composite
         Element_Position Segment_Error Field
         Sub_Element_Postion Segment_Error Field
      Segment_Name Segment_Error Field
      Error_Code Segment_Error Field
      Error_Loop_ID Segment_Error Field 
      Error_Trans_Set Segment_Error Field
      Error_Segment Segment_Error Field
      Error_Message Segment_Error Field
      Element_Text Segment_Error Field
   CTX_Element Record (0:1)
   Element (s)
      Element Segment_Error Record (0:1)
         Segment_Position Segment_Error Field
         Element_Position Segment_Error Composite
         Segment_Name Segment_Error Field
         Error_Code Segment_Error Field
         Error_Loop_ID Segment_Error Field
         Error_Trans_Set Segment_Error Field
         Error_Segment Segment_Error Field
         Error_Message Segment_Error Field
         Element_Text Segment_Error Field
      Sub_Element Segment_Error Record (s)
         Segment_Position Segment_Error Field
         Element_Position Segment_Error Composite
         Segment_Name Segment_Error Field
         Error_Code Segment_Error Field
         Error_Loop_ID Segment_Error Field
         Error_Trans_Set Segment_Error Field
         Error_Segment Segment_Error Field
         Error_Message Segment_Error Field
         Element_Text Segment_Error Field
      CTX_Element Record (0:10)

The errors are separated by:

  • Segment Errors
  • Element Errors within a Segment
  • Subelement Errors within an Element

Segment positions, element positions, subelement positions, error codes, and error messages are included in this information.

Some errors are defined within the install_dir/packs/healthcare_v4.3.2/hipaa/data/hipaa_X12_qualifer.dat file. You can identify these errors by a five-digit numeric indicator at the beginning of the error message. In this example, the 34703 error and the 34707 error are defined in the hipaa_X12_qualifer.dat file.

The compliance map reports these errors using the five-digit numeric identifiers used in the hipaa_X12_qualifer.dat file. In the next section, you learn how to create a reference file that maps all identifiers in the hipaa_X12_qualifer.dat file to specific status codes in the external code sets.

Map hipaa_X12_qualifer.dat file errors to claim status category codes and claim status codes

As explained in Identify errors defined in hipaa_X12_qualifer.dat, errors in the hipaa_X12_qualifier.dat file are identified by a five-digit error ID. You can map the corresponding errors to claim status category codes and claim status codes by defining a lookup file. The format of the lookup file can be a simple delimited record containing the five-digit error ID from the hipaa_X12_qualifer.dat file. You map its corresponding claim status category code and claim status codes from the external code sets. For the five-digit errors described in this article, the mapping is:

  • 34703,A7,400
  • 34707,A6,727

Identify errors defined in tack_codetable.dat

All other errors are defined in the install_dir/packs/healthcare_v4.3.2/hipaa/data/tack_codetable.dat file, which is supplied with the WTX Pack. To identify these errors, use the information in the merged segment data. In this case, refer to the error_segment information.

Map tack_codetable.dat file errors to claim status category codes and claim status codes

Refer to the tack_codetable.dat file to locate the values for TED01, AK304 and AK403, and then create a second reference table where these values are mapped to a Claim Status Category Code (STC01-1) value. The rules for lookup are as follows:

  • All errors where error_segment=TED, use TED01 lookup values
  • Segment Errors without error_segment=TED, use AK304 lookup values
  • Element Errors without error_segment=TED, use AK403 lookup values
  • Subelement errors, use AK403 lookup values

Listing 7 shows the error in this article that corresponds to the pattern.

Listing 7. Type 2 error without unique five-digit identifier
<merged_segment_check>
   <result>000000002900000NTE    8   2300
           000000002900100NTE    4
   </result>
</merged_segment_check>

Listing 7 shows an element error that does not contain error_segment=TED. For this reason, use the AK403 values for lookup. AK403 value 4 is defined as follows in the tack_codetable.datfile:

AK403|4|Data element too short.

"Data element is too short" reports an error with invalid data. You can map this error to Claim Status Category Code A7 - "Acknowledgement/Rejected for Invalid Information - The claim/encounter has invalid information as specified in the Status details and has been rejected." Then, create a lookup file for the data. For the lookup file format, you can use a delimited record containing the Error_Segment (TED01, AK403, AK304) and the Error_CD from tack_codetable.dat. Use the corresponding claim status category code from the external code set that you mapped. In this example, use the following mapping:

AK403,4,A7

Next, map errors that are defined in the tack_codetack.dat file to claim status codes. You can start by reviewing the claim status code external code set. You might find some values correlate directly to elements and subelements within the claim. You can map the segment, element, subelement and, in some cases, qualifiers, which are particularly useful for date errors, to the claim status values. In the rule, extract the appropriate information from the error and perform a lookup. If the error is not defined in the reference, you can provide a default claim status code.

In this article, the type 2 error is reported on the NTE segment, element 1. This segment/element correlates to the 704 claim status code value from the external code set.

Now, create a third reference file that maps segment NTE, element 1, which is the only defined element in the NTE segment, to claim status code 704. For the file format, use delimited records that consist of the segment identifier (NTE), the element position (1), and the claim status code value that you mapped from the external code set (704). In this example, use the following mapping:

NTE,1,704


Enrich the 277CA

After creating the reference files, you enrich the original 277CA. You must create a new map that uses the original 277CA, the compliance check results, and the lookup files.

The 277CA reports errors using the claim submitter ID. The compliance results file reports errors using segment position. You must map the compliance errors to the matching claims. This mapping is completed in the first output card of your new map. Next, enrich the status codes in the 277CA. To enrich the status codes, use a second output card. For a claim with multiple errors, you must add additional STC segments, in which case you must also recalculate the Number of Included Segments element in the SE segment. To enrich the original 277CA, perform these tasks:

  1. Map compliance errors to claims (Claim Submitter ID)
  2. Map compliance errors to detailed claim status category codes and claim status codes

Map compliance errors to claims (Claim Submitter ID)

In this section, you learn how to map compliance errors to claims (claim submitter ID). The 277CA denotes each claim by its claim submitter ID (CLM01) value. The error information in the compliance_check map results file is reported by segment position. First, you map each error to a claim submitter ID and then you map each error to specific status codes.

Examine the compliance_check results file and locate the block per transaction with segments positions. Listing 8 shows the runsegpos from the compliance summary.

The runsegpos data in the compliance_check results file is defined by a type tree in the WTX Pack (install_dir/packs/healthcare_v4.3.2/hipaa/trees/x12_skeleton.mtt as type Transaction_Set WithSegPosition ClaimLevelRejection Loop EDI).

Listing 8. runsegpos from from compliance summary
<runsegpos_return>*^:
1*ST**837*1323*005010X222A1
2*BHT**0019*00*244579*20061015*1023*CH
3*NM1*1000A*41*2*PREMIER BILLING SERVICE*****46*TGJ23
4*PER*1000A*IC*JERRY JAMES*TE*3055552222*EX*231
5*NM1*1000B*40*2*KEY INSURANCE COMPANY*****46*66783JJT
6*HL*2000A*1**20*1
7*PRV*2000A*BI*PXC*203BF0100Y
8*NM1*2010AA*85*2*BEN SANGFORD SERVICE*****XX*9876543210
9*N3*2010AA*234 SEAWAY ST
10*N4*2010AA*MIAMI*FL*33111
11*REF*2010AA*EI*587654321
12*NM1*2010AB*87*2
13*N3*2010AB*2345 OCEAN BLVD
14*N4*2010AB*MIAMI*FL*33111
15*HL*2000B*2*1*22*1
16*SBR*2000B*P**2222-SJ******CI
17*NM1*2010BA*IL*1*SMITH*JANE****MI*JS00111223333
18*NM1*2010BB*PR*2*KEY INSURANCE COMPANY*****XV*999996666
19*N4*2010BB*MAIMI*FL*33111
20*REF*2010BB*G2*KA6663
21*HL*2000C*3*2*23*0
22*PAT*2000C*19
23*NM1*2010CA*QC*1*LARKINS*THEODORE
24*N3*2010CA*236 N MAIN ST
25*N4*2010CA*MIAMI*FL*33413
26*DMG*2010CA*D8*19730501*M
27*CLM*2300*16463774*101***11:B:1*Y*A*Y*I**AA
28*REF*2300*D9*17312345600006351
29*NTE*2300*AD*WILL CAUSE T2 ERROR
30*HI*2300*BK:0340*BF:V7389
31*LX*2400*1
32*SV1*2400*HC:99213*40*UN*1***1
33*DTP*2400*472*D8*20061003
34*LX*2400*2
35*SV1*2400*HC:87070*15*UN*1***1
36*DTP*2400*472*D8*20061003
37*LX*2400*3
38*SV1*2400*HC:99214*35*UN*1***2
39*DTP*2400*472*D8*20061010
40*LX*2400*4
41*SV1*2400*HC:86663*10*UN*1***2
42*DTP*2400*472*D8*20061010
43*CLM*2300*26463774*100***11:B:1*Y*A*Y*I
44*REF*2300*D9*17312345600006351
45*HI*2300*BK:0340*BF:V7389
46*LX*2400*1
47*SV1*2400*HC:99213*40*UN*1***1
48*DTP*2400*472*D8*20061003
49*LX*2400*2
50*SV1*2400*HC:87070*15*UN*1***1
51*DTP*2400*472*D8*20061003
52*LX*2400*3
53*SV1*2400*HC:99214*35*UN*1***2
54*DTP*2400*472*D8*20061010
55*LX*2400*4
56*SV1*2400*HC:86663*10*UN*1***2
57*DTP*2400*472*D8*20061010
58*SE**58*1323
<runsegpos_return>

You can use the listing of segments with positions to locate the CLM segment for the corresponding error and then retrieve the claim submitter ID (CLM01) value.

The data file, compliance check results, is defined by the compliance_check type tree. The runsegpos data in the compliance check results file contains data that is defined by the x12_skeleton type tree. To access this data correctly, create two maps. The first map uses the compliance_check type tree to read the compliance check results data. This map then calls a second map with two arguments. The first argument is the entire compliance check results file, and the second argument is the runsegpos data. Since the runsegpos data is present for each separate transaction, the second map is called once per transaction. The second map reads the compliance check results file using the compliance_check type tree and the runsegpos data using the x12_skeleton type tree.

When parsing error information, you must define how to map segment errors, element errors, and subelement errors. To ensure you are mapping one error for each individual error, suppress the parent errors. For example, if you examine the output that is generated from this transaction, you see that each error has two entries - one segment (where element pos is 0), and one element. You can determine the necessary information from the element error and suppress the segment error.

To process segment, element, or subelement errors, use the rule that is shown in Listing 9 to look up the highest segment position from the runsegpos data that is associated with a CLM segment, where the segment position of the segment in runsegpos data is less than or equal to the segment position of the error. The rule maps the error to its corresponding claim submitter ID.

Listing 9. Map rule to extract CLM01 value for each error
=LOOKUP(CLM01 ClaimLevelRejection Field:CLM_SegmentWithSegPostition ClaimLevelRejection
Record:CLM_Loop IN Subscriber:Provider:RunSegPos, Segment_Position ClaimLevelRejection
Field:CLM_SegmentWithSegPosition ClaimLevelRejection Record:CLM_Loop IN 
Subscriber:Provider:RunSegPos = 

MAX(EXTRACT(Segment_Position ClaimLevelRejection Field:CLM_Segment WithSegPositon ClaimLevelRejection Record:CLM_Loop IN Subscriber:Provider:RunSegPos, Segment_Position ClaimLevelRejectionField:ClM_SegmentWithSegPositon ClaimLevelRejectionRecord:CLM_Loop IN Subscriber:Provider:RunSegPos <= Segment_Position Segment_Error Field:SegmentError)
) )

Map compliance errors to detailed claim status category codes and claim status codes

In this section, you learn how to use the lookup files that map compliance errors to values for the claim status category codes and claim status codes in the external code sets.

To map the Claim Status Category Code TED01, AK403, AK304 using the correct pattern and lookup reference, use the rules that are shown in Listing 10, Listing 11, and Listing 12.

Listing 10. Map rule for claim status category code at segment error level
=IF(SIZE(LEAVENUM(LEFT(Error_Message Segment_Error Field:SegmentError,5))) = 5,
EITHER(LOOKUP(STC01_1:Record_Qualifier:STCLookup, ErrorCD:Record_Qualifier:STCLookup = LEFT(Error_Message Segment_Error Field:SegmentError,5)),"A3"),
LOOKUP(STC01_1:Record_Qualifier:STCLookup, ErrorCat:Record_Qualifier:STCLookup = IF(Error_Segment Segment_Error Field:SegmentError = "TED", "TED01", "AK304")& ErrorCd:Record_Qualifier:STCLookup = Error_Code Segment_Error Field:SegmentError) )
Listing 11. Map rule for claim status category code at element error level
=IF(SIZE(LEAVENUM(LEFT(Error_Message Segment_Error Field:ElementError,5))) = 5,
LOOKUP(STC01_1:Record_Qualifier:STCLookup, ErrorCD:Record_Qualifier:STCLookup = LEFT(Error_Message Segment_Error Field:ElementError,5)),
LOOKUP(STC01_1:Record_Qualifier:STCLookup, ErrorCat:Record_Qualifier:STCLookup = IF(Error_Segment Segment_Error Field:ElementError = "TED", "TED01", "AK403")& ErrorCd:Record_Qualifier:STCLookup = Error_Code Segment_Error Field:ElementError) )
Listing 12. Map rule for claim status category code at Sub-Element error level
=IF(SIZE(LEAVENUM(LEFT(Error_Message Segment_Error Field:SubElementError,5))) = 5,
LOOKUP(STC01_1:Record_Qualifier:STCLookup, ErrorCD:Record_Qualifier:STCLookup = LEFT(Error_Message Segment_Error Field:SubElementError,5)),
LOOKUP(STC01_1:Record_Qualifier:STCLookup, ErrorCat:Record_Qualifier:STCLookup = "AK403"& ErrorCd:Record_Qualifier:STCLookup = Error_Code Segment_Error Field:SubElementError) )

To map the Claim Status Code TED01, AK403, AK304 using the correct pattern and lookup reference, use the rule shown in Listing 13.

Listing 13. Map rule for claim status code
=IF(SIZE(LEAVENUM(LEFT(Error_Message Segment_Error Field:ElementError,5))) = 5,
LOOKUP(STC01_2:Record_Qualifier:STCLookup, ErrorCD:Record_Qualifier:STCLookup = LEFT(Error_Message Segment_Error Field:ElementError,5)),
LOOKUP(ErrorCd:Record_Segment:SegmentLookup, SegName:Record_Segment:SegmentLookup=Segment_Name Segment_Error Field:ElementError & Qual'fr:Record_Segment:SegmentLookup = TEXT(Element_Position Segment_Error Field:Element_Position Segment_Error Composite:ElementError)) )

Conclusion

Listing 14 shows the enriched 277CA. If you look at claim submitted ID 16463774 (line 28), you see the status codes for the three STC segments are updated. These errors report more detailed information than the original errors about the conditions that caused the claim rejection for the recipient.

Listing 14. Enriched 277CA
ST*277*0001*005010X214
BHT*0085*08*277X2140001*20120724*0942*TH
HL*1**20*1
NM1*PR*2*KEY INSURANCE COMPANY*****46*66783JJT
TRN*1*1323
DTP*050*D8*20120724
DTP*009*D8*20120724
HL*2*1*21*1
NM1*41*2*PREMIER BILLING SERVICE*****46*TGJ23
TRN*2*244579
STC*A1:19*20120724*WQ*201
QTY*90*1
QTY*AA*1
AMT*YU*100
AMT*YY*101
HL*3*2*19*0
NM1*85*2*BEN SANGFORD SERVICE*****XX*9876543210
TRN*1*0
STC*A1:19**WQ*201
QTY*QA*1
QTY*QC*1
AMT*YU*100
AMT*YY*101
HL*4*3*PT*0
NM1*QC*1*LARKINS*THEODORE
TRN*2*16463774
STC*A7:704*20120724*U*101
STC*A7:400*20120724*U*101
STC*A6:727*20120724*U*101
TRN*2*26463774
STC*A1:19*20120724*WQ*100
SE*32*0001

As demonstrated in this article, the WTX Pack for HIPAA EDI provides valuable artifacts that you can use to create a customized solution. In this article, you enriched the 277CA transaction to leverage external code set information and provide more granular level reporting to recipients. This article describes just one example of leveraging the assets that are provided by the WTX Pack to meet custom requirements. Explore all the artifacts that are supplied and enjoy building your own custom solutions.


Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Commerce on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Commerce, Big data and analytics
ArticleID=859151
ArticleTitle=Extend IBM WebSphere Transformation Extender HIPAA Pack
publish-date=01022013