Encounter Data Companion Guide - CSSC Operations

1.3 Major Updates1.3.1 EDIPPS EditsMAOs and other entities can now find the complete list of Institutional Processing and Pricing Edits inSection 10.0.1.3.2 Submission of Proxy Data in a Limited Set of CircumstancesSection 11.0 provides MAOs and other entities with operational guidance for the submission of proxydata in a limited set of circumstances.1.4 ReferencesMAOs and other entities must use the ASC X12N IG adopted under the HIPAA AdministrativeSimplification Electronic Transaction rule along with CMS’ Encounter Data Participant Guides, and CMS’EDS Companion Guidelines for development of EDS transactions. These documents are accessible at thefollowing:www.csscoperations.com.Additionally, the EDS submitter guidelines and application, testing documents, 5010 companion guides,and Encounter Data Participant Guides can be found at that location.MAOs and other entities must use the most current national standard code lists applicable to the 5010transaction. The code lists may be accessed at the Washington Publishing Company (WPC) website:http://www.wpc-edi.comThe applicable code lists are as follows:Claim Adjustment Reason CodeClaim Status Category CodesClaim Status CodesCMS provides X12 5010 file format technical edit spreadsheets for the 837-I and 837-P. The editsincluded in the spreadsheet are intended to clarify the WPC instructions or add Medicare specificrequirements. In order to determine the implementation date of the edits contained in thespreadsheet, MAOs and other entities will first need to refer to the spreadsheet version. The version isa 10 character identifier as follows:Positions 1-2 indicate the line of business:o EA – Part A (837-I)o EB – Part B (837-P)Positions 3-6 indicate the year (e.g. 2011)Position 7 indicates the release quarter month837 Institutional Companion Guide Version 9.0/August 20126

oooo1 – January release2 – April release3 – July release4 – October releasePositions 8-10 indicate the spreadsheet version iteration number (e.g. V01-first iteration, V02-second iteration)The effective date of the spreadsheet is the first calendar day of the release quarter month. Theimplementation date is the first business Monday of the release quarter month. Federal holidays whichcould potentially fall on the first business Monday must be accounted for when determining theimplementation date. For example, the edits contained in a spreadsheet version of EB20113V01 areeffective July 1, 2011 and will be implemented on July 5, 2011.2.0 Contact Information2.1 The Customer Service and Support Center (CSSC)The Customer Service and Support Center (CSSC) personnel are available for questions from 8:00A.M. –7:00P.M. EST, Monday-Friday, with the exception of federal holidays and can be contacted at 1-877-534-CSSC (2772) or by email at csscoperations@palmettogba.2.2 Applicable websites/emailThe following websites provide information to assist in EDS submission:RESOURCEEncounter Data ParticipantGuidesEDS EmailANSI ASC X12 TR3Implementation GuidesWashington Publishing CompanyHealth Care Code SetsCMS Edits SpreadsheetWEB ADDRESSwww.csscoperations.comeds@ardx.netwww.wpc-edi.comwww.wpc-edi.comhttp://www.cms.gov/MFFS5010D0/20_TechnicalDocumentation.asp3.0 File Submission3.1 File Size LimitationsDue to system limitations, the combination of all ST/SE transaction sets per file cannot exceed certainthresholds depending upon the connectivity method of the submitter. FTP and NDM users cannotexceed 85,000 encounters per file. Gentran users cannot exceed 5,000 encounters per file. For allconnectivity methods, the TR3 allows no more than 5000 CLMS per ST/SE segment. The followingdemonstrates the limits due to connectivity methods:837 Institutional Companion Guide Version 9.0/August 20127

CONNECTIVITYMAXIMUM NUMBER OFENCOUNTERSFTP/NDM 85,000 5,000Gentran 5,000 5,000MAXIMUM NUMBER OF ST/SENote: Due to system processing overhead associated with smaller numbers of encounters within theST/SE, it is highly recommended that larger numbers of encounters within the ST/SE be used.In an effort to support and provide the most efficient processing system, it is recommended that FTPsubmitters’ scripts should not upload more than one (1) file per five (5) minute interval to allowmaximum performance. Files that are zipped should contain one (1) file per transmission. MAOs andother entities should refrain from submitting multiple files within the same transmission. NDM andGentran users may submit a maximum of 255 files per day.3.2 File Structure – NDM/Connect Direct and Gentran Submitters Only80 byte fixed block is a common mainframe term. This means every line (record) in a file must beuploaded as 80 bytes/characters long. NDM/Connect Direct and Gentran submitters must use thisapproach.Files should be created in a manner where the segments are one continuous stream of information thatcontinues to the next line every 80 characters.Segments should be stacked in the files, using only 80 characters per line. At position 81, MAOs andother entities must create a new line. On the new line starting in position 1, continue for 80 characters,and repeat creating a new line in position 81 until the file is complete. If the last line in the file does notfill to 80 characters, it should be spaced out to position 80 and then save the file.NOTE:If MAOs and other entities are using a text editor to create the file, a new line can be created by pressingthe Enter key. If MAOs and other entities are using an automated system to create the file, create a newline by using a CRLF (Carriage Return Line Feed) or a LF (Line Feed).For example the ISA record is 106 characters long:The first line of the file will contain the first 80 characters of the ISA segment; the last 26 characters ofthe ISA segment will be continued on the second line. The next segment will start in the 27th positionand continue until column 80.ISA*00* *00* *ZZ* ENH9999*ZZ* 80881*120816*1144*^*00501*000000031*1*P*:~837 Institutional Companion Guide Version 9.0/August 20128

4.0 Control Segments/Envelopes4.1 ISA/IEAThe term interchange denotes the ISA/IEA envelope that is transmitted. Interchange control is achievedthrough several “control” components, as defined in Table 1. The interchange control number iscontained in data element ISA13 of the ISA segment. The identical control number must also occur indata element IEA02 of the IEA segment. All elements in the ISA/IEA interchange must be populated.There are several elements within the ISA/IEA interchange that must be populated specifically forencounter data purposes. Table 1 below provides EDS Interchange Control (ISA/IEA) specific elements.Note: Only those elements that provide specific details relevant to encounter data are presented inthe table. When developing the encounter data system, users should base their logic on the highestlevel of specificity. First, consult the WPC/TR3. Second, consult the CMS edits spreadsheets. Third,consult the Encounter Data Companion Guide. If there are options expressed in the WPC/TR3 or theCEM edits spreadsheet that are broader then the options identified in the Encounter Data CompanionGuide, the rules identified in the Encounter Data Companion Guide must be used.LegendSHADED rows represent segments in the X12N Implementation GuideNON-SHADED rows represent data elements in the X12N Implementation GuideISATABLE 1 – ISA/IEA INTERCHANGE ELEMENTSLOOP ID REFERENCE NAME CODES NOTES/COMMENTSISA01ISA02ISA03ISA04ISA05ISA06InterchangeControl HeaderAuthorizationInformationQualifierAuthorizationInformationSecurityInformationQualifierSecurityInformationInterchange IDQualifierInterchange SenderID00 No authorizationinformation presentUse 10 blank spaces00 No securityinformation presentZZUse 10 blank spacesCMS expects to seea value of “ZZ” todesignate that thecode is mutuallydefinedEN followed byContract ID837 Institutional Companion Guide Version 9.0/August 20129

TABLE 1 – ISA/IEA INTERCHANGE ELEMENTS (CONTINUED)LOOP ID REFERENCE NAME CODES NOTES/COMMENTSISAInterchangeControl HeaderISA07ISA08ISA11ISA13Interchange IDQualifierInterchangeReceiver IDRepetitionSeparatorInterchangeControl NumberZZ80881^CMS expects to seea value of “ZZ” todesignate that thecode is mutuallydefinedMust be fixed lengthwith nine (9)characters andmatch IEA02IEAISA14AcknowledgementRequestedISA15 Usage Indicator TPIEA02InterchangeControl TrailerInterchangeControl NumberUsed to identify filelevel duplicatecollectively withGS06, ST02, andBHT031 A TA1 will be sent ifthe file issyntacticallyincorrect, otherwiseonly a ‘999’ will besentTestProductionMust match thevalue in ISA13837 Institutional Companion Guide Version 9.0/August 201210

4.2 GS/GEThe functional group is outlined by the functional group header (GS segment) and the functional grouptrailer (GE segment). The functional group header starts and identifies one or more related transactionsets and provides a control number and application identification information. The functional grouptrailer defines the end of the functional group of related transaction sets and provides a count ofcontained transaction sets.All elements in the GS/GE functional group must be populated. There are several elements within theGS/GE that must be populated specifically for encounter data collection. Table 2 provides EDSfunctional group (GS/GE) specific elements.Note: Only those elements that require explanation are presented in the table.GSTABLE 2 - GS/GE FUNCTIONAL GROUP ELEMENTSLOOP ID REFERENCE NAME CODES NOTES/COMMENTSGS02GS03Functional Group HeaderApplication Sender’sCodeApplication Receiver’sCodeEN followed byContract ID Number80881 This value mustmatch the value inISA08GS06 Group Control Number This value mustmatch the value inGE02GEGS08Version/Release/IndustryIdentifier CodeFunctional Group Trailer005010X223A2Used to identify filelevel duplicatescollectively withISA13, ST02, andBHT03GE02 Group Control Number This value mustmatch the value inGS064.3 ST/SEThe transaction set (ST/SE) contains required, situational, and unused loops, segments, and dataelements. The transaction set is outlined by the transaction set header (ST segment) and thetransaction set trailer (SE segment). The transaction set header identifies the start and identifies thetransaction set. The transaction set trailer identifies the end of the transaction set and provides a countof the data segments, which includes the ST and SE segments. There are several elements that must be837 Institutional Companion Guide Version 9.0/August 201211

populated specifically for encounter data purposes. Table 3 provides EDS transaction set (ST/SE) specificelements.Note: Only those elements that require explanation are presented in the table.TABLE 3 - ST/SE TRANSACTION SET HEADER AND TRAILER ELEMENTSSTSTLOOP ID REFERENCE NAME CODES NOTES/COMMENTSTransaction SetHeaderST01ST02Transaction SetIdentifier CodeTransaction SetHeaderTransaction SetControl Number837This value mustmatch the value inSE02SEST03SE01SE02ImplementationConventionReferenceTransaction SetTrailerNumber ofIncludedSegmentsTransaction SetControl Number005010X223A2Used to identify filelevel duplicatescollectively withISA13, GS06, andBHT03Must contain theactual number ofsegments within theST/SEThis value must bematch the value inST025.0 837 Institutional: Data Element TableWithin the ST/SE transaction set, there are multiple loops, segments, and data elements that providebilling provider, subscriber, and patient level information. MAOs and other entities should referencewww.wpc-edi.com to obtain the most current Implementation Guide. EDS transactions must besubmitted using the most current transaction version.The 837 Institutional Data Element table identifies only those elements within the X12N ImplementationGuide that require comment within the context of EDS submission. Table 4 identifies the 837837 Institutional Companion Guide Version 9.0/August 201212

Institutional Implementation Guide by loop name, segment name and identifier, and data element nameand identifier for cross reference. Not all data elements listed in the table below are required, but ifthey are used, the table reflects the values CMS expects to see.TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIMLOOP ID REFERENCE NAME CODES NOTES/COMMENTSBHT Beginning of HierarchicalTransactionBHT03Originator ApplicationTransaction IdentifierMust be a uniqueidentifier across all filesBHT06 Claim Identifier CH Chargeable1000A NM1 Submitter NameUsed to identify file levelduplicates collectively withISA13, GS06, and ST02.NM102 Entity Type Qualifier 2 Non-Person EntityNM109 Submitter Identifier EN followed by ContractID Number1000A PER Submitter EDI ContactInformationPER03PER05PER07Communication NumberQualifierCommunication NumberQualifierCommunication NumberQualifierTEEMFXIt is recommended thatMAOs and other entitiespopulate the submitter’stelephone numberIt is recommended thatMAOs and other entitiespopulate the submitter’semail addressIt is recommended thatMAOs and other entitiespopulate the submitter’sfax number837 Institutional Companion Guide Version 9.0/August 201213

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)LOOP ID REFERENCE NAME CODES NOTES/COMMENTS1000B NM1 Receiver NameNM102 Entity Type Qualifier 2 Non-Person EntityNM103 Receiver Name EDSCMSNM109 Receiver ID 80881 Identifies CMS as the receiverof the transaction andcorresponds to the value inISA08 Interchange Receiver ID2010AA NM1 Billing Provider NameNM108NM109Billing Provider IDQualifierBilling Provider IdentifierXXNPI IdentifierMust be populated with a tendigit number, must begin with12010AA N4 Billing Provider City,State, Zip Code1999999976Institutional provider defaultNPI when the provider has notbeen assigned an NPIN403 Zip Code The full nine (9) digits of theZIP Code are required. If thelast four (4) digits of the ZIPcode are not available,populate a default value of“9999”.2010AA REF Billing Provider TaxIdentification NumberREF01REF02Reference IdentificationNumberBilling Provider TaxIdentification Number 1999999972000B SBR Subscriber InformationSBR01SBR09Payer ResponsibilityNumber CodeClaim Filing IndicatorCodeEISMAEmployer’s IdentificationNumber (EIN)Institutional provider defaultEINEDSCMS is considered thedestination (secondary) payerMust be populated with avalue of MA – Medicare Part A837 Institutional Companion Guide Version 9.0/August 201214

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)LOOP ID REFERENCE NAME CODES NOTES/COMMENTS2010BA NM1 Subscriber NameNM108 Subscriber Id Qualifier MI Must be populated with avalue of MI – MemberIdentification NumberNM109Subscriber PrimaryIdentifier2010BB NM1 Payer NameThis is the subscriber’s HealthInsurance Claim (HIC) number.Must match the value in Loop2330A, NM109NM103 Payer Name EDSCMSNM108 Payer ID Qualifier PI Must be populated with thevalue of PI – PayerIdentificationNM109 Payer Identification 808812010BB N3 Payer AddressN301 Payer Address Line 7500 Security Blvd2010BB N4 Payer City, State, ZIPCodeN401 Payer City Name BaltimoreN402 Payer State MDN403 Payer ZIP Code 2124418502010BB REF Other Payer SecondaryIdentifierREF01 Contract ID Identifier 2UREF02 Contract ID Number MAO or other entitiesContract ID Number2300 CLM Claim InformationCLM02CLM05-3Total Claim ChargeAmountClaim Frequency TypeCode1234789Must balance to the sum SV2service lines in Loop 24001=Original claim submission2=Interim – First Claim3=Interim – Continuing Claim4=Interim – Last Claim7=Replacement8=Deletion9=Final Claim for a HomeHealth PPS Episode837 Institutional Companion Guide Version 9.0/August 201215

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)LOOP ID REFERENCE NAME CODES NOTES/COMMENTS2300 REF Payer Claim ControlNumberREF01REF02Original ReferenceNumberPayer Claim ControlNumber2300 REF Medical Record NumberREF01REF02Medical RecordIdentification NumberMedical RecordIdentification NumberF8EAIdentifies ICN from originalencounter when submittingadjustment or chart reviewdata8 Chart review delete diagnosiscode only submission –Identifies the diagnosis codepopulated in Loop 2300, HImust be deleted from theencounter ICN in Loop 2300,REF02.Deleted DiagnosisCode(s)Diagnosis code(s) that must bedeleted from the encounterICN in Loop 2300, REF02 for“chart review – add anddelete specific diagnosiscodes on a single encounter”submissions only.2300 NTE Claim NoteNTE01 Note Reference Code ADDNTE02 Claim Note Text See Section 11.0 for the useand message requirements ofproxy data information2300 HI Value InformationHI01-2 Value Code A0 Required on all ambulanceencountersHI01-5 Value Code Amount Must include the ambulancepick-up location ZIP Code+4,when available, in thefollowing format: xxxxxxxx.x837 Institutional Companion Guide Version 9.0/August 201217

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)LOOP ID REFERENCE NAME CODES NOTES/COMMENTS2320 SBR Other SubscriberInformationSBR01SBR09Payer ResponsibilitySequence Number CodeClaim Filing IndicatorCode2320 CAS Claim AdjustmentCAS02Adjustment ReasonCode2320 AMT COB Payer Paid AmountPTP=Primary (when MAOs orother entities populate thepayer paid amount)T=Tertiary (when MAOs orother entities populate a trueCOB)16 Health MaintenanceOrganization (HMO) MedicareRiskIf a claim is denied in the MAOor other entities’ adjudicationsystem, the denial reasonmust be populatedAMT02 Payer Paid Amount MAO and other entity’s paidamount2320 OI Coverage InformationOI03Benefits AssignmentCertification Indicator2330A NM1 Other Subscriber NameNM108NM109Identification CodeQualifierSubscriber PrimaryIdentifier2330B NM1 Other Payer NameNM108NM109Identification CodeQualifierOther Payer PrimaryIdentifier2330B N3 Other Payer AddressN301Other Payer AddressLineMIXVPayer 01Must match the value in Loop2300, CLM08Must match the value in Loop2010BA, NM109MAO or other entity’sContract ID Number.Only populated if there is noContract ID Number availablefor a true other payerMAO or other entity’s address837 Institutional Companion Guide Version 9.0/August 201218

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)LOOP ID REFERENCE NAME CODES NOTES/COMMENTS2330B N4 Other Payer City, State,ZIP CodeN401 Other Payer City Name MAO or other entity’s CityNameN402 Other Payer State MAO or other entity’s StateN403 Other Payer ZIP Code MAO or other entity’s ZIPCode2430 SVD Line AdjudicationInformationSVD01Other Payer PrimaryIdentifier2430 CAS Line AdjustmentsCAS02Adjustment ReasonCodeMust match the value in Loop2330B, NM109If a service line is denied in theMAO or other entities’adjudication system, thedenial reason must bepopulated6.0 Acknowledgements and Reports6.1 TA1 – Interchange AcknowledgementThe TA1 report enables the receiver to notify the sender that problems were encountered with theinterchange control structure. As the interchange envelope enters the EDFES, the EDI translatorperforms TA1 validation of the control segments/envelope. You will only receive a TA1 if you havesyntax errors in your file. Errors found in this stage will cause the entire X12 interchange to be rejectedwith no further processing.MAOs and other entities will receive a TA1 interchange report acknowledging the syntacticalincorrectness of an X12 interchange header ISA and trailer IEA, and the envelope’s structure.Encompassed in the TA1 is the interchange control number, interchange date and time, interchangeacknowledgement code, and interchange note code. The interchange control number, date, and timeare identical to those that were populated on the original 837-I or 837-P ISA line, which allows for MAOsand other entities to associate the TA1 with a specific file previously submitted.Within the TA1 segment, MAOs and other entities will be able to determine if the interchange wasrejected by examining the interchange acknowledgement code (TA104) and the interchange note code(TA105). The interchange acknowledgement code stipulates whether the interchange (ISA/IEA) rejecteddue to syntactical errors. An “R” will be the value in the TA104 data element if the interchange wasrejected due to errors. The interchange note code is a numeric code that notifies MAOs and otherentities of the specific error. The TA1 interchange acknowledgment report is generated and returned837 Institutional Companion Guide Version 9.0/August 201219

within 24 hours after submitting the interchange if a fatal error occurs. If a TA1 interchange controlstructure error is identified, MAOs and other entities must correct the error and resubmit theinterchange file.6.2 999 – Functional Group AcknowledgementAfter the interchange passes the TA1 edits, the next stage of editing is to apply Implementation Guide(IG) edits and verify the syntactical correctness of the functional group(s) (GS/GE). Functional groupsallow for like data to be organized within an interchange; therefore, more than one (1) functional groupwith multiple claims within the functional group can be populated in a file. The 999 acknowledgementreport provides information on the validation of the GS/GE functional group(s) and their consistencywith the data contained. The 999 report provides MAOs and other entities information on whether thefunctional group(s) were accepted or rejected.If a file has multiple GS/GE segments and errors occurred at any point within one of the syntactical andIG level edit validations, the GS/GE segment will be rejected, and processing will continue to the nextGS/GE segment. For instance, if a file is submitted with three (3) functional groups and the secondfunctional group encounters errors, the first functional group will be accepted the second functionalgroup will be rejected and processing will continue to the third functional group.The 999 transaction set is designed to report on adherence to IG level edits and CMS standard syntaxerrors as depicted in the CMS edit spreadsheet. Three (3) possible acknowledgement values are:“A” – Accepted“R” – Rejected“P” – Partially Accepted, At Least One Transaction Set Was RejectedWhen viewing the 999 report, MAOs and other entities should navigate to the IK5 and AK9 segments. Ifan “A” is displayed in the IK5 and AK9 segments, the claim file is accepted and will continue processing.If an “R” is displayed in the IK5 and AK9 segments, an IK3 and an IK4 segments will be displayed. Thesesegments indicate what loops and segments contain the error that needs correcting so the interchangecan be resubmitted. The third element in the IK3 segment tells the loop that contains the error. Thefirst element in the IK3 and IK4 indicate the segment and element that contain the error. The thirdelement in the IK4 segment indicates the reason code for the error.6.3 277CA – Claim AcknowledgementAfter the file is accepted at the interchange and functional group levels, the third level of editing occursat the transaction set level within the CEM in order to create the Claim Acknowledgement Transaction(277CA) report. The CEM checks the validity of the values within the data elements. For instance, dataelement N403 must be a valid nine (9) digit zip code. If a non-existent zip code is populated, the CEMwill reject the encounter. The 277CA is an unsolicited acknowledgement report from CMS to MAOs andother entities.837 Institutional Companion Guide Version 9.0/August 201220

The 277CA is used to acknowledge the acceptance or rejection of encounters submitted using ahierarchical level (HL) structure. The first level of hierarchical editing is at the Information Source level.This entity is the decision maker in the business transaction receiving the X12 837 transactions(EDSCMS).The next level is at the Information Receiver level. This is the entity that expects the responsefrom the Information Source. The third hierarchal level is at the Billing Provider of Service level and thefourth and final level is done at the Patient level. Acceptance or rejection at this level is based on theWPC and the CMS edits spreadsheet. Edits received at any hierarchical level will stop and no furtherediting will take place. For example, if there is a problem with the Billing Provider of Service submittedon the 837, individual patient edits will not be performed. For those encounters not accepted, the277CA will detail additional actions required of MAOs and other entities in order to correct and resubmitthose encounters.If an MAO or other entity receives a 277CA indicating an encounter was rejected, the MAO or otherentity must resubmit the encounter until the 277CA indicates no errors were found.If an encounter is accepted, the 277CA will provide the ICN assigned to that encounter. The ICNsegment for the accepted encounter will be located in 2200D REF segment, REF01=IK and REF02=ICN.The ICN is a unique 13-digit number.If an encounter is rejected, the 277CA will provide edit information in the STC segment. The STC03 dataelement will convey whether the HL structures accepted or rejected. The STC03 is populated with avalue of “WQ”, if the HL was accepted. If the STC03 data element is populated with a value of “U”, theHL is rejected and the STC01 data element will list the acknowledgement code.6.4 MAO-002 – Encounter Data Processing Status ReportAfter a file is accepted through the EDFES, the file is then transmitted to the EDPS where further editing,processing, pricing, and storage occurs. As a result of EDPS editing, the EDPS will return the MAO-002 –Encounter Data Processing Status Report.The MAO-002 report is a fixed length report available in flat file and formatted report layouts thatprovide encounter and service line level information. The MAO-002 reflects two (2) statuses at theencounter and service line level: “accepted” and “rejected”. Lines that reflect a status of “accept” yetcontain an error message in the Error Description column are considered “informational” edits. MAOsand other entities are not required to take further action on “informational” edits.The ‘000’ line on the MAO-002 report identifies the header level and indicates either “accepted” or“rejected” status. If the ‘000’ header line is rejected, the encounter is considered rejected and MAOsand other entities must correct and resubmit the encounter. If the ‘000’ header line is “accepted” andat least one (1) other line (i.e., 001 002 003 004) is accepted, then the overall encounter is accepted.MAOs and other entities should note that MAO-002 reports for Institutional submissions are still underdevelopment.837 Institutional Companion Guide Version 9.0/August 201221

Table 7 below provides a description of the file name components, which will assist MAOs and otherentities in identifying the report type.TABLE 7 –FILE NAME COMPONENT DESCRIPTIONRSPxxxxxX12xxxxxFILE NAMECOMPONENTTMMDDCCYYHHMMS999xxxxxRPTxxxxxEDPS_XXXXXXXXXXRPT/FILEDESCRIPTIONThe type of data ‘RSP’ and a sequential number assigned by the server ‘xxxxx’The type of data ‘X12’ and a sequential number assigned by the server ‘xxxxx’The Date and Time stamp the file was processedThe type of data ‘999’ and a sequential number assigned by the server ‘xxxxx’The type of data ‘RPT’ and a sequential number assigned by the server ‘xxxxx’Identifies the specific EDPS Report along with the report number (i.e., ‘002’, etc.)Seven (7) characters available to be used as a short description of the contents ofthe fileIdentifies if the file is a formatted report ‘RPT’ or a flat file ‘FILE’ layout6.5.2 Production Reports File Naming ConventionA different production reports file naming convention is used so that MAOs and other entities may easilyidentify reports generated and distributed during production. Table 8 below provides the reports filenaming conventions per connectivity method for production reports.TABLE 8 – PRODUCTION EDFES REPORTS FILE NAMING CONVENTIONSREPORT TYPE GENTRAN MAILBOX FTP MAILBOXEDFES Notifications P.xxxxx.EDS_RESPONSE.pn RSPxxxxx.RSP.REJECTED_IDTA1 P.xxxxx.EDS_REJT_IC_ISAIEA.pn X12xxxxx.X12.TMMDDCCYYHHMMS999 P.xxxxx.EDS_REJT_FUNCT_TRANS.pn 999xxxxx.RSP999 P.xxxxx.EDS_ACCPT_FUNCT_TRANS.pn 999xxxxx.RSP277CA P.xxxxx.EDS_RESP_CLAIM_NUM.pn RSPxxxxx.RSP_277CATable 9 below provides the production EDPS reports file naming conventions per connectivity method.TABLE 9 – PRODUCTION EDPS REPORTS FILE NAMING CONVENTIONSCONNECTIVITYMETHODGENTRANPRODUCTION NAMING CONVENTIONFORMATTED REPORTP.xxxxx.EDPS_001_DataDuplicate_RptP.xxxxx.EDPS_002_DataProcessingStatus_RptP.xxxxx.EDPS_004_RiskFilter_RptP.xxxxx.EDPS_005_DispositionSummary_RptP.xxxxx.EDPS_006_EditDisposition_RptP.xxxxx.EDPS_007_DispositionDetail_RptPRODUCTION NAMING CONVENTIONFLAT FILE LAYOUTP.xxxxx.EDPS_001_DataDuplicate_FileP.xxxxx.EDPS_002_DataProcessingStatus_FileP.xxxxx.EDPS_004_RiskFilter_FileP.xxxxx.EDPS_005_DispositionSummary_ FileP.xxxxx.EDPS_006_EditDisposition_ FileP.xxxxx.EDPS_007_DispositionDetail_ File837 Institutional Companion Guide Version 9.0/August 201223

The report format example is as follows:FILE NAME: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXFILE CONTROL: XXXXXXXXXNUMBER OF CLAIMS: 99,999FILE WAS NOT SENT TO THE EDPS BACK-END PROCESS FOR THE FOLLOWING REASON(S)XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXTable 10 provides the complete list of testing and production EDFES notification messages.TABLE 10 – EDFES NOTIFICATIONSAPPLIES TO ENCOUNTER TYPE NOTIFICATION MESSAGEAll files submittedAll files submittedAll files submittedAll files submittedEnd-to-End Testing– File 1All files submittedProduction filessubmittedProduction filessubmittedAllAllAllAllAllAllAllAllFILE ID (XXXXXXXXX) IS ADUPLICATE OF A FILE IDSENT WITHIN THE LAST 12MONTHSSUBMITTER NOTAUTHORIZED TO SENDCLAIMS FOR PLAN(CONTRACT ID)PLAN ID CANNOT BE THESAME AS THE SUBMITTERIDAT LEAST ONEENCOUNTER IS MISSING ACONTRACT ID IN THE2010BB-REF02 SEGMENTSUBMITTER NOT FRONT-END CERTIFIEDTHE DATE ON ALL CLAIMSMUST START IN THE YEAR2012SUBMITTER NOTCERTIFIED FORPRODUCTIONTHE INTERCHANGE USAGEINDICATOR MUST EQUAL‘T’NOTIFICATION MESSAGEDESCRIPTIONThe file ID must beunique for a 12 monthperiodThe submitter is notauthorized to send forthis planThe Contract ID cannotbe the same as theSubmitter IDThe Contract ID is missingThe submitter must befront-end certified tosend encounters forvalidationEncounters must containdates in the year 2012The submitter must becertified to sendencounters forproductionThe Professional Tier 2file is being sent with a ‘P’in the ISA15 field837 Institutional Companion Guide Version 9.0/August 201225

TABLE 11 - 837 INSTITUTIONAL PERMANENTLY DEACTIVATED EDFES EDITSEDIT REFERENCCE EDIT DESCRIPTION EDIT NOTESX223.084.2010AA.NM109.040X223.084.2010AA.NM109.050X223.087.2010AA.N301.070X223.090.2010AA.REF02.050X223.127.2010BB.REF.010X223.424.2400.SV202-7.025CSCC A8: “Acknowledgement/rejectedfor relational field in error”CSC 562: “Entity’s National ProviderIdentifier (NPI)”EIC 85: “Billing Provider”CSCC A8: “Acknowledgement/rejectedfor relational field in error”CSC 496: “Submitter not approved forelectronic claim submission on behalf ofthis entity””EIC 85: “Billing Provider”CSCC A7: “Acknowledgement/rejectedfor invalid information”CSC 503: “Entity’s Street Address”EIC 85: “Billing Provider”CSCC A8: “Acknowledgement/rejectedfor relational field in error”CSC 562: “Entity’s National ProviderIdentifier (NPI)”CSC 128: “Entity’s Tax ID”EIC 85: “Billing Provider”CSCC A7: “Acknowledgement/rejectedfor invalid information”CSC 732: “Information inconsistent withbilling guidelines”CSC 560: “Entity’s Additional/SecondaryIdentifier”EIC PR: “Payer”CSCC A8: “Acknowledgement/rejectedfor relational field in error”CSC 306: Detailed description of serviceValid NPI Crosswalk must beavailable for this edit.2010AA.NM109 must be a valid NPIon the Crosswalk when evaluatedwith 1000B.NM109.2010AA.NM109 billing providermust be “associated” to thesubmitter (from a trading partnermanagement perspective) in1000A.NM109.2010AA.N301 must not contain thefollowing exact phrases (not casesensitive): "Post Office Box", "P.O.BOX", "PO BOX", "LOCK BOX", "LOCKBIN", "P O BOX".Valid NPI Crosswalk must beavailable for this edit.2010AA.REF must be associatedwith the provider identified in2010AA.NM109.Non-VA claims: 2010BB.REF withREF01=”2U”, “EI”, “FY”, or “NF”must not be present. VA claims:2010BB.REF with REF01=”EI”, “FY”,or “NF” must not be present.2400.SV202-7 must be presentwhen 2400.SV202-2 contains a nonspecificprocedure code.8.0 Duplicate LogicIn order to ensure encounters submitted are not duplicates of encounters previously submitted, header,and detail level duplicate checking will be performed. If the header and/or detail level duplicatechecking determines the file is a duplicate, the file will be rejected as a duplicate, and an error reportwill be returned to the submitter.837 Institutional Companion Guide Version 9.0/August 201227

8.1 Header LevelWhen a file (ISA – IEA) is received, the system assigns a hash total to the file based on the entire ISA/IEAinterchange. Hash totals are a method for ensuring the accuracy of processed data. The hash total is atotal of several fields or data in a file, including fields not normally used in calculations, such as accountnumber. At various stages in the processing, the hash total is recalculated and compared with theoriginal. If a file comes in later in a different submission or a different submission of the same file, andgets the same hash total, it will be rejected as a duplicate.In addition to the hash total, the system also references the values collectively populated in ISA13, GS06,ST02, and BHT03. If two (2) files are submitted with the exact same values populated as a previouslysubmitted and accepted file, the file will be considered a duplicate and the error message CSCC - A8 =Acknowledgement / Rejected for relational field in error, CSC -746 = Duplicate Submission will beprovided on the 277CA.8.2 Detail LevelOnce an encounter passes through the institutional or professional processing and pricing system, it isstored in an internal repository, the Encounter Operational Data Store (EODS). If a new encounter issubmitted that matches specific values to another stored encounter, the encounter will be rejected andwill be considered a duplicate encounter. The encounter will be returned to the submitter with an errormessage identifying it as a duplicate encounter. Currently the following values are the minimum set ofitems being used for matching an encounter in the EODS:Beneficiary Demographico Health Insurance Claim Number (HICN)o NameDate of ServiceType of Bill (TOB)Revenue Code(s)Procedure Code(s)Billing Provider NPIPaid Amount** The Paid Amount is the amount paid by the MAO or other entity and should be populated in LoopID-2320, AMT02.837 Institutional Companion Guide Version 9.0/August 201228

9.0 837 Institutional Business CasesIn accordance with 45 CFR 160.103 of the Health Insurance Portability and Accountability Act (HIPAA),Protected Health Information (PHI) has been removed from all business cases. As a result, the businesscases have been populated with fictitious information about the Subscriber, Medicare AdvantageOrganization (MAO), and provider(s). The business cases reflect 2012 dates of service.Although the business cases are provided as examples of possible encounter submissions, MAOs andother entities must populate valid data in order to successfully pass translator and CEM level editing.837 Institutional Companion Guide Version 9.0/August 201229

9.1 Standard Institutional EncounterBusiness Scenario 1: Mary Dough is the patient and the subscriber, and was admitted intoMercy Hospital because she was complaining of heart pain. Happy Health Plan was theMedicare Advantage Organization (MAO). Mercy Hospital diagnosed Mary with CongestiveHealth Failure as the primary diagnosis and diabetes as an additional diagnosis.File String 1:ISA*00* *00* *ZZ*ENH9999 *ZZ*80881 *120816*1144*^*00501*000000031*1*P*:~GS*HC*ENH9999*80881*20120816*1144*31*X*005010X223A2~ST*837*0034*005010X223A2~BHT*0019*00*3920394930203*20120814*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80881~HL*1**20*1~NM1*85*2*MERCY HOSPITAL*****XX*1299999999~N3*876 MERCY DRIVE~N4*NORFOLK*VA*235089999~REF*EI*344232321~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567******MA~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80881~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850REF*2U*H9999~CLM*22350578967509876984536578798A*200.00***11:A:1**A*Y*Y~DTP*096*TM*0958~DTP*434*RD8*20120330-20120331~DTP*435*D8*20120330~CL1*2*9*01~HI*BK:4280~HI*BJ:4280~HI*BF:25000~HI*BR:3121:D8:20120330~HI*BH:41:D8:20110501*BH:27:D8:20110715*BH:33:D8:20110718*BH:C2:D8:20110729~HI*BE:30:::20~HI*BG:01~NM1*71*1*JONES*AMANDA*AL***XX*1005554104~837 Institutional Companion Guide Version 9.0/August 201230

SBR*P*18*XYZ1234567******16~AMT*D*200.00~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~N3*705 E HUGH ST~N4*NORFOLK*VA*235049999~REF*T4*Y~LX*1~SV2*0300*HC:81099*200.00*UN*1~DTP*472*D8*20120330~SVD*H9999*200.00*HC:81099*0300*1~DTP*573*D8*20120401~SE*50*0034~GE*1*31~IEA*1*000000031~837 Institutional Companion Guide Version 9.0/August 201231

9.2 Capitated Institutional EncounterBusiness Scenario 2: Mary Dough is the patient and the subscriber, and went to Mercy Hospitalbecause she was experiencing leg pain. Happy Health Plan was the Medicare AdvantageOrganization (MAO) and has a capitated arrangement with Mercy Hospital. Mercy Hospitaldiagnosed Mary with diabetes and leg pain.File String 2:ISA*00* *00* *ZZ*ENH9999 *ZZ*80881 *120816*1144*^*00501*000000331*1*P*:~GS*HC*ENH9999*80881*20120816*1144*30*X*005010X223A2~ST*837*0021*005010X223A2~BHT*0019*00*3920394930203*20120814*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80881~HL*1**20*1~NM1*85*2*MERCY HOSPITAL*****XX*1299999999~N3*876 MERCY DRIVE~N4*NORFOLK*VA*235089999~REF*EI*344232321~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567******MA~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80881~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850REF*2U*H9999~CLM*22350578967509876984536578798A *0.00***11:A:1**A*Y*Y~DTP*096*TM*0958~DTP*434*RD8*20120330-20120331~DTP*435*D8*20120330~CL1*2*9*01~CN1*05~HI*BK:4280~HI*BJ:4280~HI*BF:25000~HI*BR:3121:D8:20120330~HI*BH:41:D8:20110501*BH:27:D8:20110715*BH:33:D8:20110718*BH:C2:D8:20110729~HI*BE:30:::20~837 Institutional Companion Guide Version 9.0/August 201232

HI*BG:01~NM1*71*1*JONES*AMANDA*AL***XX*1005554104~SBR*P*18*XYZ1234567******ZZ~AMT*D*100.50~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~N3*705 E HUGH ST~N4*NORFOLK*VA*235049999~LX*1~SV2*0300*HC:81099*0.00*UN*1~DTP*472*D8*20120330~SVD*H9999*100.50*HC:81099*0300*1~CAS*CO*24*-100.50~DTP*573*D8*20120401~SE*50*0021~GE*1*30~IEA*1*000000331~837 Institutional Companion Guide Version 9.0/August 201233

9.3 Chart Review Institutional Encounter – No Linked ICNBusiness Scenario 3: Mary Dough is the patient and the subscriber, and went to Mercy Hospitalbecause she was experiencing leg pain. Happy Health Plan was the Medicare AdvantageOrganization (MAO). Happy Health Plan performs a chart review at Mercy Hospital anddetermines that a diagnosis for Mary Dough was never submitted on a claim. The medicalrecord does not contain enough information to submit a full claim, yet there is enoughinformation to support the diagnosis and link the chart review encounter back to the medicalrecord. Happy Health Plan submits a chart review encounter with no linked ICN to add thediagnosis.File String 3:ISA*00* *00* *ZZ*ENH9999 *ZZ*80881 *120816*1144*^*00501*000000031*1*P*:~GS*HC*ENH9999*80881*20120816*1144*31*X*005010X223A2~ST*837*0034*005010X223A2~BHT*0019*00*3920394930203*20120814*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80881~HL*1**20*1~NM1*85*2*MERCY HOSPITAL*****XX*1299999899~N3*876 MERCY DRIVE~N4*NORFOLK*VA*235089999~REF*EI*344232321~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567******MA~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80881~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850REF*2U*H9999~CLM*22350578967509876984536578798A*0.00***11:A:1**A*Y*Y~DTP*096*TM*0958~DTP*434*RD8*20120330-20120331~DTP*435*D8*20120330~CL1*2*9*01~PWK*09*AA~HI*BK:4280~HI*BJ:4280~HI*BF:25000~837 Institutional Companion Guide Version 9.0/August 201234

HI*BR:3121:D8:20120330~HI*BH:41:D8:20110501*BH:27:D8:20110715*BH:33:D8:20110718*BH:C2:D8:20110729~HI*BE:30:::20~HI*BG:01~NM1*71*1*JONES*AMANDA*AL***XX*1005554104~SBR*P*18*XYZ1234567******16~AMT*D*0.00~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~N3*705 E HUGH ST~N4*NORFOLK*VA*235049999~REF*T4*Y~LX*1~SV2*0300*HC:81099*0.00*UN*1~DTP*472*D8*20120330~SE*49*0034~GE*1*31~IEA*1*000000031~837 Institutional Companion Guide Version 9.0/August 201235

9.4 Chart Review Institutional Encounter – Linked ICNBusiness Scenario 4: Mary Dough is the patient and the subscriber, and went to Mercy Hospitalbecause she was experiencing leg pain. Happy Health Plan was the Medicare AdvantageOrganization (MAO). Mercy Hospital submits the encounter to CMS and receives an ICN of1294598098746. Happy Health Plan performs a chart review related to ICN 1294598098746and determines that there is an incorrect NPI was populated for the Billing Provider.File String 4:ISA*00* *00* *ZZ*ENH9999 *ZZ*80881 *120816*1144*^*00501*000000031*1*P*:~GS*HC*ENH9999*80881*20120816*1144*31*X*005010X223A2~ST*837*0034*005010X223A2~BHT*0019*00*3920394930203*20120814*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80881~HL*1**20*1~NM1*85*2*MERCY HOSPITAL*****XX*1299999899~N3*876 MERCY DRIVE~N4*NORFOLK*VA*235089999~REF*EI*344232321~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567******MA~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80881~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850REF*2U*H9999~CLM*22350578967509876984536578798A*0.00***11:A:1**A*Y*Y~DTP*096*TM*0958~DTP*434*RD8*20120330-20120331~DTP*435*D8*20120330~CL1*2*9*01~PWK*09*AA~REF*F8*1294598098746~HI*BK:4280~HI*BJ:4280~HI*BF:25000~HI*BR:3121:D8:20120330~HI*BH:41:D8:20110501*BH:27:D8:20110715*BH:33:D8:20110718*BH:C2:D8:20110729~837 Institutional Companion Guide Version 9.0/August 201236

HI*BE:30:::20~HI*BG:01~NM1*71*1*JONES*AMANDA*AL***XX*1005554106~SBR*P*18*XYZ1234567******16~AMT*D*0.00~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~N3*705 E HUGH ST~N4*NORFOLK*VA*235049999~REF*T4*Y~LX*1~SV2*0300*HC:81099*0.00*UN*1~DTP*472*D8*20120330~SE*50*0034~GE*1*31~IEA*1*000000031~837 Institutional Companion Guide Version 9.0/August 201237

9.5 Complete Replacement Institutional EncounterBusiness Scenario 5: Mary Dough is the patient and the subscriber, and went to Mercy Hospitalbecause she was experiencing heart pain. Happy Health Plan is the Medicare AdvantageOrganization (MAO). Mercy Hospital diagnosed Mary with Congestive Heart Failure anddiabetes. Happy Health Plan submits the encounter to CMS and receives an ICN1122978564098. After further investigation, it was determined that Happy Health Plan shouldnot have paid for $120.00. Happy Health Plan submits a correct and replace adjustmentencounter to replace encounter 1122978564098 with the newly submitted encounter.File String 5:ISA*00* *00* *ZZ*ENH9999 *ZZ*80881 *120816*1144*^*00501*000000554*1*P*:~GS*HC*ENH9999*80881*20120816*1144*80*X*005010X223A2~ST*837*0567*005010X223A2~BHT*0019*00*3920394930203*20120814*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80881~HL*1**20*1~NM1*85*2*MERCY HOSPITAL*****XX*1299999999~N3*876 MERCY DRIVE~N4*NORFOLK*VA*235089999~REF*EI*344232321~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567******MA~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80881~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850REF*2U*H9999~CLM*22350578967509876984536578798A*200.00***11:A:7**A*Y*Y~DTP*096*TM*0958DTP*434*RD8*20120330-20120331~DTP*435*D8*20120330-20120331~CL1*2*9*01~REF*F8*1222978564098~HI*BK:4280~HI*BJ:4280~HI*BR:3121:D8:20120330~HI*BH:41:D8:20110501*BH:27:D8:20110715*BH:33:D8:20110718*BH:C2:D8:20110729~837 Institutional Companion Guide Version 9.0/August 201238

HI*BE:30:::20~HI*BG:01~NM1*71*1*JOHNSON*AMANDA*AL***XX*1005554104~SBR*P*18*XYZ1234567******16~CAS*CO*39*120.00~AMT*D*80.00~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~N3*705 E HUGH ST~N4*NORFOLK*VA*235048769~DTP*573*20120401~LX*1~SV2*0300*HC:81099*200.00*UN*1~DTP*472*D8*20120330~SE*49*0567~GE*1*80~IEA*1*000000554~837 Institutional Companion Guide Version 9.0/August 201239

9. 6 Complete Deletion Institutional EncounterBusiness Scenario 6: Mary Dough is the patient and the subscriber, and went to Dr. ElizabethA. Smart because she was experiencing abdominal pain. Happy Health Plan is the MedicareAdvantage Organization (MAO). Dr. Smart diagnosed Mary with abdominal pain. Happy HealthPlan submits the encounter to CMS and receives ICN 1212487000032. Happy Health Plan thendetermines that they mistakenly sent the encounter without it being adjudicated in theirinternal system, so they want to delete the encounter. Happy Health Plan submits anadjustment encounter to delete the previously submitted encounter 1212487000032.File String 6:ISA*00* *00* *ZZ*ENH9999 *ZZ*80882 *120430*1144*^*00501*000000298*1*P*:~GS*HC*ENH9999*80882*20120430*1144*82*X*005010X222A1~ST*837*0290*005010X222A1~BHT*0019*00*3920394930206*20120428*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80882~HL*1**20*1~NM1*85*1*SMITH*ELIZABETH*A**MD*XX*1299999999~N3*123 CENTRAL DRIVE~N4*NORFOLK*VA*235139999~REF*EI*765879876~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567**47****MB~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80882~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850~REF*2U*H9999~CLM*2997677856479709654A*100.50***11:B:8*Y*A*Y*Y~REF*F8*1212487000032~HI*BK:78901~SBR*P*18*XYZ1234567******16~CAS*CO*223*100.50~AMT*D*0.00~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~837 Institutional Companion Guide Version 9.0/August 201240

N3*705 E HUGH ST~N4*NORFOLK*VA*235049999~REF*T4*Y~LX*1~SV1*HC:99212*100.50*UN*1***1~DTP*472*D8*20120401~SVD*H9999*0.00*HC:99212**1~DTP*573*D8*20120403~SE*41*0290~GE*1*82~IEA*1*000000298~837 Institutional Companion Guide Version 9.0/August 201241

9. 7 Atypical Provider Institutional EncounterBusiness Scenario 7: Mary Dough is the patient and the subscriber, and receives services froman atypical provider. Happy Health Plan was the Medicare Advantage Organization (MAO).File String 7:ISA*00* *00* *ZZ*ENH9999 *ZZ*80881 *120816*1144*^*00501*000000032*1*P*:~GS*HC*ENH9999*80881*20120816*1144*35*X*005010X223A2~ST*837*0039*005010X223A2~BHT*0019*00*3920394930203*20120814*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80881~HL*1**20*1~NM1*85*2*MERCY SERVICES*****XX*1999999976~N3*876 MERCY DRIVE~N4*NORFOLK*VA*235089999~REF*EI*199999997~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567******MA~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80881~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850REF*2U*H9999~CLM*22350578967509876984536578799A*50.00***83:A:1**A*Y*Y~DTP*434*RD8*20120330-20120331~CL1*9*9*01~HI*BK:78099~NTE*ADD* NO NPI ON PROVIDER CLAIM NO EIN ON PROVIDER CLAIM~SBR*P*18*XYZ1234567******16~AMT*D*50.00~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~N3*705 E HUGH ST~N4*NORFOLK*VA*235049999~REF*T4*Y~837 Institutional Companion Guide Version 9.0/August 201242

LX*1~SV2*0300*HC:D0999*50.00*UN*1~DTP*472*D8*20120330~SVD*H9999*50.00*HC:D0999*0300*1~DTP*573*D8*20120401~SE*41*0039~GE*1*35~IEA*1*000000032~837 Institutional Companion Guide Version 9.0/August 201243

9.8 Paper Generated Institutional EncounterBusiness Scenario 8: Mary Dough is the patient and the subscriber, and receives services fromMercy Health Plan. Mercy Health Plan submits the claim to Happy Health Plan on a UB-04.Happy Health Plan is the Medicare Advantage Organization (MAO) and converts the paper claiminto an electronic submission.File String 8:ISA*00* *00* *ZZ*ENH9999 *ZZ*80881 *120816*1144*^*00501*000000032*1*P*:~GS*HC*ENH9999*80881*20120816*1144*35*X*005010X223A2~ST*837*0039*005010X223A2~BHT*0019*00*3920394930203*20120814*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80881~HL*1**20*1~NM1*85*2*MERCY SERVICES*****XX*1234999999~N3*876 MERCY DRIVE~N4*NORFOLK*VA*235089999~REF*EI*128752354~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567******MA~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80881~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850~REF*2U*H9999~CLM*22350578967509876984536578799A*50.00***83:A:1**A*Y*Y~DTP*434*RD8*20120330-20120331~CL1*9*9*01~PWK*OZ*AA~HI*BK:78099~SBR*P*18*XYZ1234567******16~AMT*D*50.00~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~N3*705 E HUGH ST~837 Institutional Companion Guide Version 9.0/August 201244

N4*NORFOLK*VA*235049999~REF*T4*Y~LX*1~SV2*0300*HC:D0999*50.00*UN*1~DTP*472*D8*20120330~SVD*H9999*50.00*HC:D0999*0300*1~DTP*573*D8*20120403~SE*42*0039~GE*1*35~IEA*1*000000032~837 Institutional Companion Guide Version 9.0/August 201245

9.9 True Coordination of Benefits Institutional EncounterBusiness Scenario 9: Mary Dough is the patient and the subscriber, and was admitted intoMercy Hospital because she was complaining of heart pain. Happy Health Plan was theMedicare Advantage Organization (MAO). Other Health Plan also provided payment for MaryDough. Mercy Hospital diagnosed Mary with Congestive Health Failure as the primary diagnosisand diabetes.File String 9:ISA*00* *00* *ZZ*ENH9999 *ZZ*80881 *120816*1144*^*00501*000000031*1*P*:~GS*HC*ENH9999*80881*20120816*1144*31*X*005010X223A2~ST*837*0034*005010X223A2~BHT*0019*00*3920394930203*20120814*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80881~HL*1**20*1~NM1*85*2*MERCY HOSPITAL*****XX*1299999999~N3*876 MERCY DRIVE~N4*NORFOLK*VA*235089999~REF*EI*344232321~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567******MA~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80881~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850REF*2U*H9999~CLM*22350578967509876984536578799A*712.00***11:A:1**A*Y*Y~DTP*096*TM*0958~DTP*434*RD8*20120330-20120331~DTP*435*D8*20120330~CL1*2*9*01~HI*BK:78901~NM1*71*1*JONES*AMANDA*AL***XX*1005554104~SBR*P*18*XYZ1234567******16~AMT*D*700.00OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~837 Institutional Companion Guide Version 9.0/August 201246

N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~N3*705 E HUGH ST~N4*NORFOLK*VA*235049999~SBR*T*18*XYZ3489388******16~CAS*CO*223*700.00~AMT*D*12.00~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*OTHER HEALTH PLAN*****XV*PAYER01~N3*400 W 21 ST~N4*NORFOLK*VA*235059999~DTP*573*D8*20120401~REF*T4*YLX*1~SV2*0300*HC:81099*712.00*UN*1~DTP*472*D8*20120330~SVD*H9999*700.00*HC:D0999*0300*1~CAS*CO*45*12.00~DTP*573*D8*20120401~SE*56*0034~GE*1*31~IEA*1*000000031~837 Institutional Companion Guide Version 9.0/August 201247

9.10 Bundled Institutional EncounterBusiness Scenario 10: Mary Dough is the patient and the subscriber, and was admitted intoMercy Hospital because she was complaining of heart pain. Happy Health Plan was theMedicare Advantage Organization (MAO). Mercy Hospital diagnosed Mary with CongestiveHealth Failure as the primary diagnosis and diabetes.File String 10:ISA*00* *00* *ZZ*ENH9999 *ZZ*80881 *120816*1144*^*00501*000000031*1*P*:~GS*HC*ENH9999*80881*20120816*1144*31*X*005010X223A2~ST*837*0034*005010X223A2~BHT*0019*00*3920394930203*20120814*1615*CH~NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~PER*IC*JANE DOE*TE*5555552222~NM1*40*2*EDSCMS*****46*80881~HL*1**20*1~NM1*85*2*MERCY HOSPITAL*****XX*1299999999~N3*876 MERCY DRIVE~N4*NORFOLK*VA*235089999~REF*EI*344232321~PER*IC*BETTY SMITH*TE*9195551111~HL*2*1*22*0~SBR*S*18*XYZ1234567******MA~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~DMG*D8*19390807*F~NM1*PR*2*EDSCMS*****PI*80881~N3*7500 SECURITY BLVD~N4*BALTIMORE*MD*212441850REF*2U*H9999~CLM*22350578967509876984536578798A*100.00***11:A:1**A*Y*Y~DTP*096*TM*0958~DTP*434*RD8*20120330-20120331~DTP*435*D8*20120330~CL1*2*9*01~HI*BK:4280~HI*BJ:4280~HI*BF:25000~HI*BR:3121:D8:20120330~HI*BH:41:D8:20110501*BH:27:D8:20110715*BH:33:D8:20110718*BH:C2:D8:20110729~HI*BE:30:::20~HI*BG:01~NM1*71*1*JONES*AMANDA*AL***XX*1005554104~837 Institutional Companion Guide Version 9.0/August 201248

SBR*P*18*XYZ1234567******16~AMT*D*9.48~OI***Y***Y~NM1*IL*1*DOUGH*MARY****MI*672148306~N3*1234 STATE DRIVE~N4*NORFOLK*VA*235099999~NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~N3*705 E HUGH ST~N4*NORFOLK*VA*235049999~REF*T4*Y~LX*1~SV1*HC:82374*50.00*UN*1***1~DTP*472*D8*20120401~SVD*H9999*9.48*HC:80051**1~CAS*CO*45*40.52~DTP*573*D8*20120403~LX*2~SV1*HC:82435*50.00*UN*1*11~DTP*472*D8*20120401~SVD*H9999*0.00*HC:80051**1*1~CAS*OA*97*50.00~DTP*573*D8*20120403~SE*57*0034~GE*1*31~IEA*1*000000031~837 Institutional Companion Guide Version 9.0/August 201249

10.0 Encounter Data Institutional Processing and Pricing System EditsAfter an Institutional encounter passes translator and CEM level editing and an ICN is received on a277CA, the Encounter Data Front-End System (EDFES) then transfers the encounter to the EncounterData Institutional Processing and Pricing System (EDIPPS), where editing, processing, pricing, andstorage occurs. In order to assist MAOs and other entities in submission of encounter data through theEDIPPS, the current list of the EDIPPS edits is provided in Table 12.The EDIPPS edits are organized in nine (9) different categories, as provided in Table 12, Column 2. TheEDIPPS edit categories include the following:ValidationProviderBeneficiaryReferenceLimitConflictPricingDuplicateNCCIThere are two (2) edit dispositions: Informational and Reject, which are provided in Column 3 of Table12. Informational edits are being reviewed and further guidance will be provided in a future release ofthe Companion Guide. Informational edits will cause an informational flag to be placed on theencounter; however, the Informational edit will not cause processing and/or pricing to cease. Rejectedits will cause an encounter to stop processing and/or pricing, and the MAO or other entity mustresubmit the encounter through the EDFES. The encounter must then pass translator and CEM levelediting prior to the data being transferred to the EDIPPS for reprocessing. The EDIPPS edit message, asfound in Column 4 in Table 12, is included on Encounter Data Processing System (EDPS) transactionreports and gives further information to the MAO or other entity of the specific reason for the editgenerated.If there is no reject edit at the header level and at least one of the lines is accepted, then the encounteris accepted. If there is no reject edit at the header level, but all lines are rejected, then the encounterwill be rejected. If there is a reject edit at the header level, the encounter will be rejected.Table 12 reflects only those edits that are currently programmed in the EDIPPS. MAOs and otherentities should note that as testing progresses, it may be determined that the current edits requiremodifications, additional edits may be necessary, or edits may be temporarily or permanentlydeactivated. MAOs and other entities must always reference the most recent version of the CompanionGuide to determine the current edits in the EDIPPS.837 Institutional Companion Guide Version 9.0/August 201250

EDIPPSEDIT#TABLE 12 - ENCOUNTER DATA INSTITUTIONAL PROCESSING AND PRICING SYSTEM (EDIPPS) EDITS(CONTINUED)EDIPPS EDITCATEGORYEDIPPS EDITDESCRIPTIONEDIPPS EDIT ERROR MESSAGE17407 Validation Reject Procedure - HCPCS Modifier Without HCPCS Code17590 Validation RejectValue Code - Code 05 Not Present Or Conflicts With DollarAmount17595 Validation Reject Value Code - Code 05 And Revenue Codes Not Allowed17735 Validation Reject Modifier - Not Within Effective Date18010 Reference Informational Age Conflict With Diagnosis18012 Reference Informational Gender – Inconsistency With Diagnosis18018 Reference Informational Gender - Inconsistency With Procedure Code18120 Reference Reject ICD-9 Diagnosis Code Error18121 Reference Reject ICD-9 Procedure Code Error18130 Reference Reject Diagnosis - Principal Diagnosis Code Is A Duplicate18135 Reference Reject Diagnosis - Principal Diagnosis Code Is A Manifestation Code18140 Reference Reject Diagnosis - Principal Diagnosis Is An E-Code18145 Reference Reject Diagnosis - Unacceptable Code18260 Reference Reject Revenue - Code Not Recognized18265 Reference Informational Revenue - Diagnosis Code V70.7 Required18270 Validation Informational Revenue Code and HCPCS Code Required On Outpatient18495 Validation Reject Procedure - Invalid Digit18500 Conflict Informational Procedure - Multiple Codes For The Same Service18540 Reference Informational Procedure – Service Unit Out Of Range On Same Claim18705 Validation Reject Discharge Status Is Invalid18710 Validation Reject POA Indicator - Missing Or Invalid18730 Reference Reject Modifier - Invalid Format18905 Validation Reject Age Is 0 Or Exceeds 12420035 Validation RejectOutpatient Claim Requires Date Of Service For Revenue Code57X20270 Validation RejectAdmit From And Thru Dates Are Same; Day Count Does NotEqual 120450 Validation Reject Attending Physician is Sanctioned20455 Validation Informational Operating Provider Is Sanctioned20500 Conflict Reject Valid Service Date For Revenue Code Billed20505 Conflict Reject Accurate Ambulance HCPCS and Revenue Code Required20510 Conflict Reject Revenue Code 540 Requires Specific HCPCS Codes20520 Validation Reject Invalid Ambulance Pickup Location20530 Validation Reject Zip Code Cannot Be 0 or Blank For Ambulance Pickup20835 Pricing RejectService Line Date Of Service Must Be Valid And Within HeaderDate of Service20980 Pricing Informational Provider Not Eligible To Bill TOB 12X or 22X837 Institutional Companion Guide Version 9.0/August 201252

EDIPPSEDIT#TABLE 12 - ENCOUNTER DATA INSTITUTIONAL PROCESSING AND PRICING SYSTEM (EDIPPS) EDITS(CONTINUED)EDIPPS EDITCATEGORYEDIPPS EDITDESCRIPTIONEDIPPS EDIT ERROR MESSAGE21925 Pricing Reject Conditions For Swing Bed SNF PPS Claim Are Not Met21950 Pricing Reject Line Level DOS Is Required For Outpatient Claim25000 NCCI Informational Correct Code Initiative Error32001 Validation Reject Bill Type Not Implemented for Processing at This Time98325 Duplicate RejectExact Duplicate of a Service Line within this Claim or aPreviously Priced Claim11.0 Submission of Proxy Data in a Limited Set of CircumstancesMAOs and other entities will be allowed to submit proxy data in a limited set of circumstances for datesof service in 2012 as identified and explained in the table below. MAOs and other entities cannotsubmit proxy data for any circumstances, other than those listed in the table below. CMS will use thisinterim approach for the submission of encounter data for 2012 and will provide additional guidance forthe submission of 2013 encounter data. In each circumstance where proxy information is submitted,MAOs and other entities are required to indicate in Loop 2300, NTE01=’ADD’, NTE02 field the reason forthe use of proxy information. If there is any question about the submission of proxy encounter data andwhen it may be used, CMS should be contacted for clarification. CMS will provide MAOs and otherentities with additional guidance concerning proxy data in the near future.PROXY DATATo submit encounters with 2011 Dates of Service(DOS), the “from” and “through” dates must berevised to show DOS on January 1, 2012 or later,with an exception of TOBs 11X, 18X, and 21XRejected Line ExtractionMedicaid Service Line ExtractionEDS Acceptable Anesthesia ModifierDefault NPI for atypical, paper, and 4010 claimsDefault EIN for atypical providersChart Review Default Procedure CodesTABLE 13 – PROXY DATAPROXY DATA MESSAGE (NTE02)DOS CLAIM CHANGE DUE TO 2011 DOS DURING EDSIMPLEMENTATION PERIODREJECTED LINES CLAIM CHANGE DUE TO REJECTEDLINE EXTRACTIONMEDICAID CLAIM CHANGE DUE TO MEDICAID SERVICELINE EXTRACTIONMODIFIER CLAIM CHANGE DUE TO EDS ACCEPTABLEANESTHESIA MODIFIERNO NPI ON PROVIDER CLAIMNO EIN ON PROVIDER CLAIMDEFAULT PROCEDURE CODES INCLUDED IN CHARTREVIEW837 Institutional Companion Guide Version 9.0/August 201253

REVISION HISTORYVERSION DATE DESCRIPTION OF REVISION2.1 9/9/2011 Baseline Version3.0 11/16/2011 Release 14.0 12/9/2011 Release 25.0 12/20/2011 Release 36.0 3/8/2012 Release 47.0 5/9/2012 Release 58.0 6/22/2012 Release 69.0 8/31/2012 Section 6.2 – Removed “E” as a 999 acknowledgementreport option9.0 8/31/2012 Section 8.2 – Added procedure code(s) to the duplicatelogic9.0 8/31/2012 Section 11 – Added for the submission of proxy data in alimited set of circumstances9.0 8/31/2012 Table 4 – Added guidance for the deletion of diagnosiscodes as a result of a chart review, as well as proxy datasubmission in NTE fields9.0 8/31/2012 Table 9 – Revised FTP EDPS Production file namingconvention (changed EDPS in naming convention to PROD)9.0 8/31/2012 Table 10 – Revised EDFES Notifications9.0 8/31/2012 Table 12 – Revised to include the finalized EDIPPS edits837 Institutional Companion Guide Version 9.0/August 201254