Encounter Data System - CSSC Operations

_________________________________________________________________Encounter Data SystemStandard Companion Guide Transaction InformationInstructions related to the 837 Health Care Claim: InstitutionalTransaction based on ASC X12 Technical Report Type 3 (TR3), Version005010X223A2Companion Guide Version Number: 8.0Created: June 2012837 Institutional Companion Guide Version 8.0/June 20121

PrefaceThe Encounter Data System (EDS) Companion Guide contains information to assist Medicare AdvantageOrganizations (MAOs) and other entities in the submission of encounter data. The EDS CompanionGuide is under development and the information in this version reflects current decisions and will bemodified on a regular basis. All versions of the EDS Companion Guide are identified by a version numberwhich is located in the version control log on the last page of the document. Questions regarding thecontents of the EDS Companion Guide should be directed to eds@ardx.net.837 Institutional Companion Guide Version 8.0/June 20122

Table of Contents1.0 Introduction1.1 Scope1.2 Overview1.3 Major Updates1.3.1 Duplicate Logic1.3.2 EDIPPS Edits1.3.3 True COB1.3.4 EDFES Notifications1.3.5 Revised Business Case 9.10 – Bundled Institutional Encounter1.3 References2.0 Contact Information2.1 CSSC2.2 eds@ardx.net2.3 Applicable websites/email3.0 File Submission3.1 File Size Limitations3.2 File Structure4.0 Control segments/envelopes4.1 ISA-IEA4.2 GS-GE4.3 ST-SE5.0 Transaction Specific Information5.1 837-I Transaction Specific Table6.0 Acknowledgements and/or Reports6.1 TA16.2 9996.3 277CA6.4 MAO-002 – Encounter Data Processing Status Report6.5 File Naming Conventions6.5.1 Testing6.5.2 Production6.6 EDFES Notifications7.0 Front-End Edits8.0 Duplicate Logic8.1 Header Level8.2 Detail Level9.0 Institutional Business Cases9.1 Standard Institutional Encounter9.2 Capitated Institutional Encounter9.3 Chart Review Institutional Encounter – No Linked ICN837 Institutional Companion Guide Version 8.0/June 20123

Table of Contents9.4 Chart Review Institutional Encounter – Linked ICN9.5 Complete Replacement Institutional Encounter9.6 Complete Deletion Institutional Encounter9.7 Atypical Provider Institutional Encounter9.8 Paper Generated Institutional Encounter9.9 True Coordination of Benefits Institutional Encounter9.10 Bundled Institutional Encounter10.0 Encounter Data Institutional Processing and Pricing System Edits837 Institutional Companion Guide Version 8.0/June 20124

1.0 Introduction1.1 ScopeThe CMS Encounter Data System (EDS) Companion Guide for the 837-I transactions addresses howMAOs and other entities conduct Institutional claim HIPAA standard electronic transactions with CMS.CMS’ Encounter Data transaction system supports transactions adopted under HIPAA, as well asadditional supporting transactions described in this guide.The CMS EDS Companion Guide must be used in conjunction with the associated 837-I ImplementationGuide (TR3). The instructions in the CMS EDS Companion Guide are not intended to be a stand-alonerequirements document.1.2 OverviewThe CMS EDS Companion Guide includes information needed to begin and maintain communicationexchange with CMS. The information is organized in the sections listed below:Contact Information: This section includes telephone and fax numbers for EDS contacts.Control Segments/Envelopes: This section contains information needed to create the ISA/IEA,GS/GE, and ST/SE control segments for transactions to be supported by EDS.Acknowledgements and Reports: This section contains information on all transactionacknowledgements sent by EDS, including the TA1, 999, and 277CA.Transaction Specific Information: This section describes how X12N Implementation Guides (IGs)adopted under HIPAA will be detailed with the use of a table. The tables contain a row for eachsegment with CMS specific information in addition to the information in the IGs. Thatinformation can contain:oooooLimits on the repeat of loops, or segmentsLimits on the length of a simple data elementSpecifics on a sub-set of the IG’s internal code listingsClarifications of the use of loops, segments, composite and simple data elementsAny other information tied directly to a loop, segment, and composite or simple dataelement pertinent to trading electronically with CMS.In addition to the row for each segment, one (1) or more additional rows are used to describe EDS’usage for composite or simple data elements and for any other information.837 Institutional Companion Guide Version 8.0/June 20125

1.3 Major Updates1.3.1 Duplicate LogicAs testing has progressed, it has been determined that revenue code(s) are necessary to performduplicate checking rather than procedure code(s). Further information is provided in Section 8.2.1.3.2 EDIPPS EditsMAOs and other entities can now find the complete list of Institutional Processing and Pricing Edits inSection 10.0.Edit 03102 – Provider Type or Specialty Not Allowed to Bill For Procedure is temporarily “informational”.1.3.3 True COBTwo (2) edits are not functioning correctly for true COB encounter submissions. As a result, EDS hastemporarily deactivated the following edits:Edit ReferenceX223.143.2300.CLM02.080X223.424.2400.SV203.060Edit DescriptionCSCC A7: "Acknowledgement /Rejected for Invalid Information…"CSC 400: "Claim is out of Balance"CSC 672 "Payer's payment information is out of balanceCSCC A7: "Acknowledgement /Rejected for Invalid Information…"CSC 400: "Claim is out of balance:CSC 583:"Line Item Charge Amount"The Fee-For-Service (FFS) CEM Maintainers are reviewing these edits to determine if they can bepermanently corrected.1.3.4 EDFES NotificationsThe Encounter Data Front-End System (EDFES) provides notifications to inform MAOs and other entitiesof the reason the submitted file was not sent to the Encounter Data Processing System (EDPS). Theseare in addition to the EDFES acknowledgement reports, including the TA1, 999, and 277CA and to theEDPS Reports. All EDFES notifications will begin with the following notification: “FILE WAS NOT SENT TOTHE EDPS BACK-END PROCESS FOR THE FOLLOWING REASON(S)”. Section 6.6, Table 9 provides thecomplete list of testing and production EDFES notification messages.1.3.5 Revised Business Case 9.10 – Bundled Institutional EncounterBusiness Case 9.10 (Bundled Institutional Encounter) was revised to reflect the original code populatedin SV1 and the bundled procedure code in SVD. In addition, the monetary amounts were changed toallow the encounter to balance appropriately.837 Institutional Companion Guide Version 8.0/June 20126

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 montho 1 – January releaseo 2 – April releaseo 3 – July releaseo 4 – 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.7837 Institutional Companion Guide Version 8.0/June 2012

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: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 and837 Institutional Companion Guide Version 8.0/June 20128

other 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*:~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,837 Institutional Companion Guide Version 8.0/June 20129

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/CommentsISA01ISA02ISA03ISA04ISA05ISA06ISA07ISA08ISA11InterchangeControl HeaderAuthorizationInformationQualifierAuthorizationInformationSecurityInformationQualifierSecurityInformationInterchange IDQualifierInterchange SenderIDInterchange IDQualifierInterchangeReceiver IDRepetitionSeparator00 No authorizationinformation presentUse 10 blank spaces00 No securityinformation presentZZZZ80881^Use 10 blank spacesCMS expects to seea value of “ZZ” todesignate that thecode is mutuallydefinedEN followed byContract ID NumberCMS expects to seea value of “ZZ” todesignate that thecode is mutuallydefined837 Institutional Companion Guide Version 8.0/June 201210

ISATABLE 1 – ISA-IEA INTERCHANGE ELEMENTS (CONTINUED)Loop ID Reference Name Codes Notes/CommentsISA13InterchangeControl HeaderInterchangeControl NumberMust be fixed lengthwith nine (9)characters andmatch IEA02IEAISA14AcknowledgementRequestedISA15 Usage Indicator TPInterchangeControl TrailerIEA02InterchangeControl NumberUsed to identify filelevel duplicatecollectively withGS06, ST02, andBHT031 A TA1 will be sent ifthe file issyntacticallyincorrect, otherwiseonly a ‘999’ will besentTestProductionMust match thevalue in ISA134.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 EDS functionalgroup (GS-GE) specific elements.Note: Only those elements that require explanation are presented in the table.837 Institutional Companion Guide Version 8.0/June 201211

TABLE 2 - GS-GE FUNCTIONAL GROUP ELEMENTSLoop ID Reference Name Codes Notes/CommentsGSGS02GS03Functional 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 bepopulated 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 ELEMENTSLoop ID Reference Name Codes Notes/CommentsSTST01Transaction SetHeaderTransaction SetIdentifier Code837837 Institutional Companion Guide Version 8.0/June 201212

TABLE 3 - ST-SE TRANSACTION SET HEADER AND TRAILER ELEMENTS (CONTINUED)Loop ID Reference Name Codes Notes/CommentsSTST02Transaction SetHeaderTransaction SetControl NumberThis value mustmatch the value inSE02SEST03SE01SE02ImplementationConventionReferenceTransaction SetTrailerNumber ofIncludedSegmentsTransaction SetControl Number005010X223A2Used to identifyfile levelduplicatescollectively withISA13, GS06, andBHT03Must contain theactual number ofsegments withinthe ST-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 837Institutional 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.837 Institutional Companion Guide Version 8.0/June 201213

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 NumberQualifier1000B NM1 Receiver NameTEEMFXIt 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 numberNM102 Entity Type Qualifier 2 Non-Person EntityNM103 Receiver Name EDSCMSNM109 Receiver ID 80881 Identifies CMS as thereceiver of the transactionand corresponds to thevalue in ISA08 InterchangeReceiver ID2010AA NM1 Billing Provider NameNM108 Billing Provider IDQualifierXXNPI Identifier837 Institutional Companion Guide Version 8.0/June 201214

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)Loop ID Reference Name Codes Notes/CommentsNM109 Billing Provider 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 A2010BA NM1 Subscriber NameNM108 Subscriber Id Qualifier MI Must be populated with avalue of MI – MemberIdentification NumberNM109Subscriber PrimaryIdentifier2010BB NM1 Payer NameNM103 Payer Name EDSCMSThis is the subscriber’s HealthInsurance Claim (HIC) number.Must match the value in Loop2330A, NM109NM108 Payer ID Qualifier PI Must be populated with thevalue of PI – PayerIdentification837 Institutional Companion Guide Version 8.0/June 201215

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)Loop ID Reference Name Codes Notes/CommentsNM109 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 TypeCode2300 DTP Date – AdmissionDate/HourDTP02 Date Time Period FormatQualifier1234789D8DTMust 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 EpisodeD8=CCYYMMDDDT=CCYYMMDDHHMMDTP03 Admission Date/Hour Hours (HH) are expressed as“00” for midnight, “01” for1A.M., and so on through “23”for 11P.M.Minutes (MM) are expressedas “00” through “59”. If theactual minutes are not known,use a default of “00”.This is only required fororiginal or final bills837 Institutional Companion Guide Version 8.0/June 201216

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)Loop ID Reference Name Codes Notes/Comments2300 PWK Claim SupplementalInformationPWK01 Report Type Code 09Populated for chart reviewsubmissions onlyOZPopulated for encountersgenerated as a result of paperclaims onlyPWK02AttachmentTransmission Code2300 CN1 Contract InformationPYAAPopulated for encountersgenerated as a result of 4010submission onlyPopulated for chart review,paper generated, and 4010generated encountersCN101 Contract Type Code 05 Populated for capitated/ staffmodel arrangements2300 REF Payer Claim ControlNumberREF01REF02Original ReferenceNumberPayer Claim ControlNumber2300 HI Value InformationF8Identifies ICN from originalencounter when submittingadjustment or chart reviewdataHI01-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 8.0/June 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 8.0/June 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 other837 Institutional Companion Guide Version 8.0/June 201219

entities of the specific error. The TA1 interchange acknowledgment report is generated and returnedwithin 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“E” – Accepted with Non-Syntactical Errors“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 8.0/June 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 8.0/June 201221

6.5 Reports File Naming ConventionsIn order for MAOs and other entities to receive and identify the EDFES acknowledge reports (TA1, 999,and 277CA) and EDPS MAO-002 Encounter Data Processing Status Report, specific reports file namingconventions have been used. The file name ensures that the specific reports are appropriatelydistributed to each secure, unique mailbox. The EDFES and EDPS have established a unique file namingconvention for reports distributed during testing and production.6.5.1 Testing Reports File Naming ConventionTable 5 below provides the EDFES and EDPS reports file naming conventions according to connectivitymethod. MAOs and other entities should note that Connect:Direct (NDM) users’ reports file namingconventions is user defined.TABLE 5 – TESTING REPORTS FILE NAMING CONVENTIONSReport Type Gentran Mailbox FTP Mailbox – Text FTP Mailbox - ZippedEDFESEDFESEDFESEDFESEDFESEDPSEDPST.xxxxx.EDS_RESPONSE.pnT.xxxxx.EDS_REJT_IC_ISAIEA.pnT.xxxxx.EDS_REJT_FUNCT_TRANS.pnT.xxxxx.EDS_ACCPT_FUNCT_TRANS.pnT.xxxxx.EDS_RESP_CLAIM_NUM.pnT.xxxxx.EDPS_002_DataProcessingStatus_RptT.xxxxx.EDPS_002_DataprocessingStatus_FileRSPxxxxx.RSP.REJECTED_IDX12xxxxx.X12.TMMDDCCYYHHMMS999xxxxx.RSP999xxxxx.RSPRSPxxxxx.RSP_277CARPTxxxxx.RPT.EDPS_002_DATPRS_RPTRPTxxxxx.RPT.EDPS_002_DATPRS_FILERSPxxxxx.RSP.REJECTED_IDX12xxxxx.X12.TMMDDCCYYHHMMS999xxxxx.RSP999xxxxx.RSPRSPxxxxx.RSP_277CARPTxxxxx.ZIP.EDPS_002_DATPRS_RPTRPTxxxxx.ZIP.EDPS_002_DATPRS_FILE* Note: There is a limit of 20 characters on the description of the file. The description starts after RPT.Or ZIP.Table 6 below provides a description of the testing file name components, which will assist MAOs andother entities in identifying the report type.TABLE 6 – TESTING FILE NAME COMPONENT DESCRIPTIONFile Name ComponentRSPxxxxxX12xxxxxTMMDDCCYYHHMMS999xxxxxRPTxxxxxDescriptionThe 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’837 Institutional Companion Guide Version 8.0/June 201222

TABLE 6 – TESTING FILE NAME COMPONENT DESCRIPTION (CONTINUED)File Name ComponentRPT/ZIPEDPS_XXXXXXXXXXRPT/FILEDescriptionDetermines if the file is a plain text ‘RPT’ or compressed ‘ZIP’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 7 below provides the reports filenaming conventions per connectivity method for production reports.TABLE 7 – PRODUCTION REPORTS FILE NAMING CONVENTIONSReport Type Gentran Mailbox RISC Mailbox – Text RISC Mailbox - ZippedEDFES P.xxxxx.EDS_RESPONSE.pn RSPxxxxx.RSP.REJECTED_ID RSPxxxxx.RSP.REJECTED_IDEDFES P.xxxxx.EDS_REJT_IC_ISAIEA.pn X12xxxxx.X12.TMMDDCCYYHHMMSEDFESEDFESEDFESEDPSEDPSP.xxxxx.EDS_REJT_FUNCT_TRANS.pnP.xxxxx.EDS_ACCPT_FUNCT_TRANS.pnP.xxxxx.EDS_RESP_CLAIM_NUM.pnP.xxxxx.EDPS_002_DataProcessingStatus_RptP.xxxxx.EDPS_002_DataProcessingStatus_File999xxxxx.RSP999xxxxx.RSPRSPxxxxx.RSP_277CARPTxxxxx.RPT.EDPS_002_DATPRS_RPTRPTxxxxx.RPT.EDPS_002_DATPRS_FILEX12xxxxx.X12.TMMDDCCYYHHMMS999xxxxx.RSP999xxxxx.RSPRSPxxxxx.RSP_277CARPTxxxxx.ZIP.EDPS_002_DATPRS_RPTRPTxxxxx.ZIP.EDPS_002_DATPRS_FILE* Note: There is a limit of 20 characters on the description of the file. The description starts after RPT.Or ZIP.Table 8 below provides a description of the production file name components, which will assist MAOsand other entities in identifying the report type.TABLE 8 – PRODUCTION FILE NAME COMPONENT DESCRIPTIONFile Name ComponentRSPxxxxxX12xxxxxTMMDDCCYYHHMMS999xxxxxDescriptionThe type of data ‘RSP’ and a sequential number assigned by the RISC ‘xxxxx’The type of data ‘X12’ and a sequential number assigned by the RISC ‘xxxxx’The Date and Time stamp the file was processed by the RISCThe type of data ‘999’ and a sequential number assigned by the RISC ‘xxxxx’837 Institutional Companion Guide Version 8.0/June 201223

TABLE 8 – PRODUCTION FILE NAME COMPONENT DESCRIPTION (CONTINUED)File Name ComponentRPTxxxxxRPT/ZIPEDPS_XXXXXXXXXXRPT/FILEDescriptionThe type of data ‘RPT’ and a sequential number assigned by the RISC ‘xxxxx’Determines if the file is a plain text ‘RPT’ or compressed ‘ZIP’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.6 EDFES NotificationsThe Encounter Data Front-End System (EDFES) provides notifications to inform MAOs and other entitiesof the reason the submitted file was not sent to the Encounter Data Processing System (EDPS). Theseare in addition to the EDFES acknowledgement reports, including the TA1, 999, and 277CA and to theEDPS Reports. Table 9 below provides the file type, EDFES notification message, and EDFES notificationmessage description.The file has an 80 character record length and contains the following record layout:1. File Name Recorda. Positions 1 – 7 = Blank Spacesb. Positions 8 – 18 = File Name:c. Positions 19 – 62 = Name of the Saved Filed. Positions 63 – 80 = Blank Spaces2. File Control Recorda. Positions 1 – 4 = Blank Spacesb. Positions 5 – 18 = File Control:c. Positions 19 – 27 = File Control Numberd. Positions 28 – 80 = Blank Spaces3. File Count Recorda. Positions 1 – 18 = Number of Claims:b. Positions 19 – 24 = File Claim Countc. Positions 25 – 80 = Blank Spaces4. File Separator Recorda. Positions 1 – 80 = Separator (----------)5. File Message Recorda. Positions 1 – 80 = FILE WAS NOT SENT TO THE EDPS BACK-END PROCESS FOR THEFOLLOWING REASON(S)6. File Message Recordsa. Positions 1 – 80 = File Message837 Institutional Companion Guide Version 8.0/June 201224

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 9 provides the complete list of testing and production EDFES notification messages.All files submittedAll files submittedAll files submittedAll files submittedTABLE 9 – EDFES NOTIFICATIONSApplies To Notification Message Notification Message DescriptionFILE ID (XXXXXXXXX) IS A DUPLICATE OFA FILE ID SENT WITHIN THE LAST 12MONTHSSUBMITTER NOT AUTHORIZED TO SENDCLAIMS FOR PLAN (CONTRACT ID)PLAN ID CANNOT BE THE SAME AS THESUBMITTER IDAT LEAST ONE ENCOUNTER IS MISSINGA CONTRACT ID IN THE 2010BB-REF02SEGMENTThe file ID must be unique for a 12month periodThe submitter is not authorized tosend for this planThe Contract ID cannot be the sameas the Submitter IDThe Contract ID is missingEnd-to-End Testing – File 1 SUBMITTER NOT FRONT-END CERTIFIED The submitter must be front-endcertified to send encounters forvalidationAll files submittedProduction files submittedProduction files submittedTier 2 file submittedEnd-to-End Testing – File 1End-to-End Testing –Additional File(s)THE DATE ON ALL CLAIMS MUST STARTIN THE YEAR 2012SUBMITTER NOT CERTIFIED FORPRODUCTIONTHE INTERCHANGE USAGE INDICATORMUST EQUAL ‘T’PLAN (CONTRACT ID) HAS (X,XXX)CLAIMS IN THIS FILE. ONLY 2,000 AREALLOWEDFILE CANNOT CONTAIN MORE THAN 26ENCOUNTERSEncounters must contain dates in theyear 2012 (excluding TOB 11X)The submitter must be certified tosend encounters for productionThe Institutional Tier 2 file is beingsent with a ‘P’ in the ISA15 fieldThe number of encounters for aContract ID cannot be greater than2,000The number of encounters cannot begreater than 26837 Institutional Companion Guide Version 8.0/June 201225

TABLE 9 – EDFES NOTIFICATIONS (CONTINUED)File Type Notification Message Notification Message DescriptionEnd-to-End Testing – File 1End-to-End Testing –Additional File(s)PATIENT CONTROL NUMBER IS MORETHAN 20 CHARACTERS LONG THE TC#WAS TRUNCATEDThe Claim Control Number, includingthe Test Case Number, must notexceed 20 charactersEnd-to-End Testing – File 1End-to-End Testing –Additional File(s)End-to-End Testing – File 1End-to-End Testing –Additional File(s)End-to-End Testing – File 1End-to-End Testing –Additional File(s)FILE CANNOT CONTAIN BOTH UNLINKEDAND LINKED TEST CASESCANNOT SEND LINKED TEST CASESUNTIL ALL UNLINKED TEST CASES HAVEBEEN ACCEPTEDFILE CONTAINS (X) TEST CASE (X)ENCOUNTER(S)ADDITIONAL FILES CANNOT BEVALIDATED UNTIL AN MAO-002 REPORTHAS BEEN RECEIVEDThe test cases from File 1 and File 2cannot be in the same fileThe test cases for File 2 cannot besent before all File 1 test cases areacceptedThe file must contain two (2) of eachtest caseThe MAO-002 report must bereceived before additional files can besubmitted7.0 Permanently Deactivated Front-End EditsSeveral CEM edits that are currently active in the Fee-For-Service CEM edits spreadsheet will bepermanently deactivated in order to ensure syntactically correct encounters pass front-edit editing.Table 10 provides the current EDS front-end edits that will be deactivated. The edit reference columnprovides the exact edit reference that will be deactivated. The edit description column provides theClaim Status Category Code (CSCC), the Claim Status Code (CSC), and the Entity Identifier Code (EIC),when applicable. The notes column provides a description of the edit reason. MAOs and other entitiesshould reference the WPC website at www.wpc-edi.com for a complete listing of all CSCCs and CSCs.TABLE 10 - 837 INSTITUTIONAL PERMANENTLY DEACTIVATED CEM EDITSEdit Reference Edit Description Edit NotesX223.084.2010AA.NM109.040 CSCC A8: “Acknowledgement/rejectedfor relational field in error”CSC 562: “Entity’s National ProviderIdentifier (NPI)”EIC 85: “Billing Provider”Valid NPI Crosswalk must beavailable for this edit.2010AA.NM109 must be a valid NPIon the Crosswalk when evaluatedwith 1000B.NM109.837 Institutional Companion Guide Version 8.0/June 201226

TABLE 10 - 837 INSTITUTIONAL PERMANENTLY DEACTIVATED CEM EDITS (CONTINUED)Edit Reference Edit Description Edit NotesX223.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 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 service2010AA.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.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 the837 Institutional Companion Guide Version 8.0/June 201227

original. 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)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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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~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~LX*1~837 Institutional Companion Guide Version 8.0/June 201242

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 8.0/June 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 8.0/June 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 8.0/June 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 8.0/June 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~Added the DTP segmentREF*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 8.0/June 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 8.0/June 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 8.0/June 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 11 below.The EDIPPS edits are organized in nine (9) different categories, as provided in Table 11, Column 2. TheEDIPPS edit categories include the following:ValidationProviderBeneficiaryReferenceLimitConflictPricingDuplicateNCCIThere are two (2) edit dispositions: Informational and Reject, which are provided in Column 3 of Table11 below. Informational edits are being reviewed and further guidance will be provided in a futurerelease of the Companion Guide. Informational edits will cause an informational flag to be placed onthe encounter; however, the Informational edit will not cause processing and/or pricing to cease.Reject edits will cause an encounter to stop processing and/or pricing, and the MAO or other entitymust resubmit the encounter through the EDFES. The encounter must then pass translator and CEMlevel editing prior to the data being transferred to the EDIPPS for reprocessing. The EDIPPS editmessage, as provided in Column 4 in Table 11 below, will be provided on Encounter Data ProcessingSystem (EDPS) transaction reports to provide further information to the MAO or other entity of thespecific reason for the edit generated.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 11 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 8.0/June 201250

TABLE 11 - ENCOUNTER DATA INSTITUTIONAL PROCESSING AND PRICING SYSTEM (EDIPPS) EDITSEDIPPSEdit#EDIPPS EditCategoryEDIPPS EditDisposition837 Institutional Companion Guide Version 8.0/June 2012EDIPPS Edit Error Message00010 Validation Reject From Date Of Service Is Greater Than TCN Date00012 Validation Reject Date Of Service Is Less Than 01-01-201200025 Validation Reject To Date Of Service Is After Date Of Claim Receipt00265 Validation Reject Adjustment Or Void ICN Not Found In History00699 Validation Reject Void Submission Must Match Original EncounterUnable To Void Due To Different Billing Provider On Void00761 Validation Reject From Original01405 Provider Reject Sanctioned Provider01415 Provider Informational Rendering Provider Not Eligible For Date Of Service02106 Beneficiary Informational Invalid Beneficiary Last NameBeneficiary Health Insurance Carrier Number (HICN) Not02110 Beneficiary Reject On File02112 Beneficiary Reject Date Of Service Is After Beneficiary Date Of Death02120 Beneficiary Informational Beneficiary Gender Mismatch02125 Beneficiary Reject Beneficiary Date Of Birth MismatchBeneficiary Not Enrolled In Medicare Advantage02240 Beneficiary Reject Organization For Date Of Service02255 Beneficiary Reject Beneficiary Not Part A Eligible For Date Of Service02256 Beneficiary Reject Beneficiary Not Part C Eligible For Date Of Service03015 Reference Reject DOS Spans Procedure Code Effective/End DateInvalid Case Mix Group For Inpatient Rehabilitation03022 Pricing Reject Facility Claim03101 Reference Reject Invalid Gender For Procedure Code03102 Pricing Informational*Provider Type Or Specialty Not Allowed To Bill ForProcedure17085 Validation RejectInpatient/SNF Same Day Transfer Must Have ConditionCode 4017100 Validation Reject Type Of Bill - Home Health Claim Missing Date Of Service17110 Validation Reject TOB 74X Or 75X Requires HCPCS And Revenue Code17257 Validation Informational Revenue - Revenue Code 910 Not Allowed17285 Validation Reject Billed Lines Require Charges (Few Exceptions)17295 Conflict RejectInpatient Claim Missing Revenue Code or OutpatientClaim Missing Either Revenue Code or HCPCS Code17310 Validation RejectSurgical Revenue Code 036X Requires Surgical ProcedureCode17330 Reference Reject Adjustment Not Allowed for A RAP* temporarily informational and will be changed to reject upon further analysis51

TABLE 11 - ENCOUNTER DATA INSTITUTIONAL PROCESSING AND PRICING SYSTEM (EDIPPS) EDITS(CONTINUED)EDIPPSEdit#EDIPPS EditCategoryEDIPPS EditDisposition17404 Validation RejectEDIPPS Edit Error MessageProcedure - HCPCS Code Cannot Be Duplicated And MaxUnit Of 1 Per Visit17407 Validation Reject Procedure - HCPCS Modifier Without HCPCS CodeValue Code – Code 5 Not Present Or Conflicts With Dollar17590 Validation Reject Amount17595 Validation Reject Value Code – Code 5 And Revenue Codes Not Allowed17735 Validation Reject Modifier - Not Within Effective Date18010 Reference Informational Age Conflict with Diagnosis18012 Reference Informational Gender – Inconsistency With Diagnosis Code18018 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 DuplicateDiagnosis – Principal Diagnosis Code Is A Manifestation18135 Reference Reject 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 RevenueCode 57X20270 Validation RejectAdmit From And Thru Dates Are Same; Day Count DoesNot Equal 120455 Validation Informational Operating Provider Is Sanctioned20500 Conflict Reject Valid Service Date For Revenue Code Billed20505 Conflict Reject Accurate Ambulance HCPCS and Revenue Code Required52837 Institutional Companion Guide Version 8.0/June 2012

TABLE 11 - ENCOUNTER DATA INSTITUTIONAL PROCESSING AND PRICING SYSTEM (EDIPPS) EDITS(CONTINUED)EDIPPSEdit#EDIPPS EditCategoryEDIPPS EditDispositionEDIPPS Edit Error Message20510 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 PickupService Line Date Of Service Must Be Valid And Within20835 Pricing Reject Header Date of Service20980 Pricing Informational Provider Not Eligible To Bill TOB 12X or 22X21925 Pricing Reject Conditions For Swing Bed SNF PPS Claim Are Not Met25000 NCCI Informational Corrective Code Initiative Error98325 Duplicate Reject Claim Is An Exact Duplicate Of A Previously Priced Claim837 Institutional Companion Guide Version 8.0/June 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 Table 4 – Added PWK01=’PY’ for 4010 submissions8.0 6/22/2012 Section 6.2 - Added to ‘P’ – Partially Accepted, At LeastOne Transaction Set Was Rejected8.0 6/22/2012 Section 6.6 – Added EDFES Notifications8.0 6/22/2012 Section 8.2 - Updated duplicate logic to removeprocedure code(s) and add revenue code(s)8.0 6/22/2012 Section 9.9 - Updated the True COB Business Case toinclude the DTP segment (Claim Check or RemittanceDate)8.0 6/22/2012 Section 9.10 – Updated the Bundled InstitutionalEncounter Business Case to include the original andbundled procedure code and revised the amounts tobalance appropriately8.0 6/22/2012 Table 11 - Updated the EDIPPS Edits to include additionalreject edits and all informational edits837 Institutional Companion Guide Version 8.0/June 201254