WIXLIB

277ClaimAcknowledgement(004010H01)IMPLEMENTATION GUIDE HEALTH CARE INFORMATION STATUS NOTIFICATIONHighmark EDI OperationsDecember 1, 2008

This page was intentionally left blank.

Highmark277 Claim Acknowledgement1 Purpose and BusinessOverview1.1 Document PurposeThe purpose of this implementation guide is to provide data requirements and content forreceivers of Highmark’s version of the 277 - Claim Acknowledgement Transaction (ANSI ASCX12.317). This implementation guide focuses on use of the 277 as an acknowledgement toreceipt of claim submission(s). This implementation guide provides a detailed explanation of thetransaction set by defining data content, identifying valid code tables and specifying valuesapplicable for the business focus of the 277 claim submission acknowledgement.Throughout this implementation guide the reference to "claim(s)" means individual claims orencounters or groupings of claims or encounters.Entities receiving this application of the 277 include, but are not limited to, hospitals, nursinghomes, laboratories, physicians, dentists, allied health professional groups, and supplemental(i.e., other than primary payer) health care claims adjudication processors.Other business partners affiliated with the 277 include billing services; consulting services;vendors of systems; software and EDI translators; EDI network intermediaries such as healthcare clearinghouses, value-added networks and telecommunication services.1.2 Version and ReleaseThis Highmark implementation guide is based on the October 1997 ASC X12 standard referredto as Version 4, Release 1, Sub-release 0 (004010). This is the first Highmark guide for thisbusiness function of the 277 Transaction set. For purposes of this business use, Highmark willidentify the Version of this Transaction in the GS08 data element as ‘004010H01’.1.3 Business UseThis implementation guide only addresses the business use of the 277 Claim Acknowledgement.The purpose of this transaction is to provide a system (application) level acknowledgement ofelectronic claims or encounters. This implementation guide is to be used specifically as anapplication acknowledgement response to the ASC X12N 837 Institutional and Professionalclaim/encounter submission transactions.This 277 Claim Acknowledgement transaction will only be used to acknowledge 837Institutional and Professional transactions where ISA08 54771. See the Payer ID Charts in theProfessional Claim (837P) and Institutional Claim (837I) sections of the Provider EDI ReferenceGuide for more specific payer information.1.3.1 Claim System AcknowledgementThe first level of acknowledgement by Highmark for the ASC X12 837 transactions will be theASC X12 Functional Acknowledgement (997) transaction. The 997 transaction is designed toRevised: 12/01/20083

Highmark277 Claim Acknowledgementnotify the submitter of the receiver’s ability or inability to process the entire 837 transactionbased on ASC X12 syntax and structure rules.The second level of acknowledgement by Highmark for the ASC X12 837 transaction will be the277 Claim Acknowledgement. This is a system (application) acknowledgement of the businessvalidity and acceptability of the claims. The level of editing in pre-adjudication programs willvary from system to system. Although the level of editing may vary, this transaction provides astandard method of reporting acknowledgements for claims. The application acknowledgementidentifies claims that are transferred to another entity, accepted for adjudication, as well as thosethat are not accepted. The 277 transaction is the only notification of pre-adjudication claimstatus. Claims failing the pre-adjudication editing process are not forwarded to the claimsadjudication system and therefore are never reported in the ASC X12 Health Care ClaimPayment/Advice (835) transaction. Claims passing the pre-adjudication editing process areforwarded to the claims adjudication system and handled according to claims processingguidelines. Final adjudication of claims is reported in the ASC X12 Health Care ClaimPayment/Advice (835) transaction.Revised: 12/01/20084

Highmark277 Claim Acknowledgement2 Data OverviewThis section introduces the structure of the 277 Claim Acknowledgement and describes thepositioning of the business data within the structure. Familiarity with ASC X12 nomenclature,segments, data elements, hierarchical levels, and looping structure is recommended. Refer toAppendix A of any national transaction set implementation guide named in the HIPAAAdministrative Simplification Electronic Transaction rule for information on ASC X12nomenclature, structure, etc.2.1 Overall Data ArchitectureThe implementation view provided at the beginning of Section 3 displays only the segments andtheir designated health care names described in this implementation guide. The intent of theimplementation view is to clarify the purpose and use of the segments.The 277 Transaction set is divided into two levels, or tables. Table 1 (Heading) containstransaction control information, which includes the ST and BHT segments. The ST segmentidentifies the start of a transaction’s business purpose. The BHT segment identifies thehierarchical structure used. Table 2 (Detail) contains the detail information for the businessfunction of the transaction. See Section 2.3 - Claim Status Theory for specific information onthe status reporting detail.2.2 Data ‘Usage’ DefinitionsWithin the Transaction detail, ‘Usage’ for the various Loops, Segments and Elements will bedefined as follows:Required - This item will always be used.Sit. (Situational) - The use of this item varies, depending on data content and business context.The defining rule is generally documented in syntax or usage notes attached to the item. *Theitem is used whenever the situation defined in the note is true; otherwise, the item is not used.Not Used - This item is not used. NOTE: If no situational note is present, the item may be sent if the data is available.Loop Usage: Loop usage within ASC X12 transactions can be confusing. Care must be used toread the loop requirements in terms of the context or location within the transaction. The usagedesignator of a loop’s beginning segment indicates the usage of the loop. Segments within a loopcannot be sent without the beginning segment of that loop.If the first segment is Required, the loop must occur at least once unless it is nested in a loop thatis not being used. A note on the Required first segment of a nested loop will indicate dependencyon the higher level loop. If the first segment is Situational, there will be a Segment Noteaddressing use of the loop. Any required segments in loops beginning with a Situational segmentonly occur when the loop is used. Similarly, nested loops only occur when the higher level loopis used.Revised: 12/01/20085

Highmark277 Claim Acknowledgement2.3 Claim Status TheoryThe level of information potentially available for a Claim Status Response may vary drasticallyfrom Payer to Payer. The primary vehicle for the claim status information in the 277 transactionis the STC segment.The STC segment contains three iterations of the Health Care Claim Status composite (C043)within elements STC01, STC10 and STC11. The standardized codes used in the compositeacknowledge the acceptance of the claim or specify the reason(s) for rejection. The compositeelements use industry codes from external Code Source 507, Health Care Claim Status CategoryCode, and Source 508, Health Care Claim Status Code. The primary distribution source for thesecodes is the Washington Publishing Company World Wide Web site (www.wpc-edi.com).Within the STC segment, composite element STC01 is required; STC10 and STC11 aresituational and used to provide additional claim status when needed. The composite elementconsists of three sub-elements.The first element in the composite is the Health Care Claim Status Category Code, Code Source507. The category code indicates the level of processing achieved by the claim. This element isRequired for use when the composite is used. For the business purpose of this implementationguide, only codes from the ‘Acknowledgment’ category are supported. The ‘Acknowledgment’Category Codes all begin with ‘A’.The second element is the Health Care Claim Status Code, Code Source 508. This elementprovides more detailed information about the rational for the claim or line item being in thecategory identified in the first element. This element is Required for use when the composite isused. Examples of status messages include "entity acknowledges receipt of claim/encounter,""missing/invalid data prevents payer from processing claim," and "business application currentlynot available."The third element in the composite is the Entity Identifier Code. The code in this elementidentifies the entity referred to in the second element (Status Code). The code list identifies anorganizational entity, a physical location, property, or an individual. This element is Situationalfor use when the composite is used. A list of appropriate Entity Identifier Code values is withinthe STC segment in Section 3.Revised: 12/01/20086

Highmark277 Claim Acknowledgement3 Transaction Set277 - Claim ameFunctional Group .IDSTBHTNameTransaction Set HeaderBeginning of Hierarchical TransactionReq.Des.RRMax.Use1112040NM1LOOP ID - 1000Submitter NameRPageNo.Pos.No.Seg.ID13010HLNameLOOP ID - 2000AInformation Source Hierarchical Level14050NM1LOOP ID – 2100AInformation Source NamePageNo.Pos.No.Seg.ID15010HLNameLOOP ID - 2000BInformation Receiver Hierarchical Level16050NM1LOOP ID – 2100BInformation Receiver NamePageNo.Pos.No.Seg.ID17010HLNameLOOP ID - 2000CProvider Hierarchical LevelNM1LOOP ID – 2100CBilling Provider eat1R1R11Detail:18050Revised: 12/01/2008Req.Des.Max.UseR1R1LoopRepeat 117

Highmark277 Claim 40HLDMGNameLOOP ID - 2000DSubscriber Hierarchical LevelDemographic Information22050NM1LOOP ID – 2100DSubscriber Name232427090100110TRNSTCREF2829110120REFDTPLOOP ID – 2200DClaim IdentificationStatus InformationClaim Identification Number forClearinghouses and Other TransmissionIntermediariesPayer Claim NumberDate or Time or Period30323536180190200210SVCSTCREFDTPLOOP ID – 2220DService InformationStatus InformationService IdentificationDate or Time or PeriodPageNo.Pos.No.Seg.ID3738010040HLDMGNameLOOP ID - 2000EDependent Hierarchical LevelDemographic Information39050NM1LOOP ID – 2100EDependent Name404144090100110TRNSTCREF4546110120REFDTPLOOP ID – 2200EClaim IdentificationStatus InformationClaim Identification Number forClearinghouses and Other TransmissionIntermediariesPayer Claim NumberDate or Time or s.Max.UseRS11R1SRS1 11SR12SRRR1 111LoopRepeat 11 1 1Detail:Req.Des.Max.UseSR11R1RRS1 11SR12LOOP ID – 2220EService InformationStatus InformationService IdentificationDate or Time or PeriodSRRR1 111SETransaction Set TrailerR1Seg.IDGENameFunctional Group TrailerReq.Des.RLoopRepeat 11 1 1Summary:PageNo.55Pos.No.280Revised: 12/01/2008Max.Use1LoopRepeat8