Eligibility Messaging

this section provides guidelines for the data messaging interfaces between the provider vendor or pharmacy and pbm/payers standard segments will be required for commonly transmitted data such as basic patient demographics and eligibility information the patient and eligibility data will be transmitted between the provider vendor or pharmacy system, surescripts, and pbm/payer using the currently accepted x12 envelope segments message formats used include the x12 eligibility request (health care eligibility benefit inquiry) and the x12 eligibility response (health care eligibility benefit response) the requester is a provider vendor or pharmacy system, and the eligibility responder is a pbm/payer see eligibility premium features docid\ hlxilexg0bksc0frwkbvk for more information relationship to the x12 eligibility request and eligibility response standard all eligibility requests and responses sent to surescripts by customers must comply with the x12 standard for eligibility for a health plan mandated under hipaa by the department of health and human services (the "270/271 implementation guide") the descriptions in this section of eligibility request transactions and the eligibility response transactions clarify the information that surescripts expects to be included in eligibility request and eligibility response messages exchanged with surescripts nothing in these specifications are intended or shall be deemed to (a) change the definition, data condition, or use of a data element or segment in a hipaa mandated standard; (b) add any data elements or segments to the maximum defined data set of a hipaa mandated standard; (c) use any code or data elements that are either marked "not used" in the 270/271 implementation guide; or (d) change the meaning or intent of the 270/271 implementation guide the guidelines for data messaging interfaces provided in this document are tailored to the needs of provider vendor system and pbm/payer customers related to prescription drug benefits and are a subset of the x12 standard the x12 standard covers a great number of other business scenarios that are not described in this section; however, surescripts will support the minimum requirements of the x12 eligibility request/eligibility response transaction see section 1 4 7 of the 270/271 implementation guide (“implementation compliant use of the 270/271 transaction set”) note even though surescripts has implemented a subset of the x12n 270/271 standard, customers should be able to handle receiving all the segments, elements and related codes contained in the hipaa x12n 270/271 standard refer to the document references docid\ hnuzt96dmj6k7yszygpbl for the exact reference guides needed if a provider vendor submits an eligibility request that does not comply with the x12 standard, surescripts will return a 999 response if a provider vendor system customer submits an eligibility request that complies with the x12 eligibility request/eligibility response transaction but contains information that is unexpected by surescripts, surescripts will return an eligibility response based on the information received by surescripts that was expected, but the response may include aaa segments if insufficient information expected by surescripts is submitted to generate a meaningful response if a pbm/payer customer submits an eligibility response that does not comply with the x12 standard, surescripts will return a 999 response to the pbm/payer the response to the pbm/payer should be responded to with an ack if a pbm/payer customer submits an eligibility response that complies with the x12 eligibility request/eligibility response transaction but contains information that is unexpected by surescripts, surescripts will pass the response to the requesting provider vendor system however, pbm/payer customers should be aware that such responses may not be understood or usable by the recipient provider vendor system patient match verification the specific fields that are used to match the patient are listed below only valid patient data should be entered invalid data or filler data may result in “patient not found” or an incorrect match last name nm103 first name nm104 – use formal name do not use preferred name or nickname middle name nm105 suffix nm107 – if relevant, the name suffix should be included in this field street address (line 1) n301 street address (line 2) n302 city n401 state n402 zip n403 dob dmg02 gender dmg03 insufficient information in the event that insufficient identifying elements are sent to surescripts to uniquely identify a patient, surescripts returns an eligibility response with an aaa segment identifying “subscriber/insured not found” or “patient not found” and sends recommendations for future searches, if appropriate patient not found with hint errors when ”patient not found with hint” error message is received in an aaa response, the provider vendor system should work to correct and resubmit, including those fields that would assist in identifying the patient the error is sent if patient is not found and one or more of the following fields are missing patient first name patient last name patient zip code patient date of birth sending all fields will aid in locating more patients, enabling more informed decision making during the prescribing process non unique match in the event that multiple patients are found for the submitted data elements and a unique match cannot be determined, surescripts returns an eligibility response with an aaa segment identifying “subscriber/insured not found or patient not found” and, if possible, lists the missing data elements needed to help identify an exact patient match pbm/payers assign a unique id to each covered member for this reason, customers should use the subscriber loop since each member is being treated as a subscriber according to the standard note pbm/payers should always return the data they had in their system in the eligibility response and not echo back what was sent in the eligibility request if any of the demographic fields listed above are different from what the provider vendor sent, a change flag is returned from the pbm/payer if a field comes in blank and the pbm/payer sends back a value, this is considered a change however, if the provider vendor sends a value in a field and the pbm/payer is unable to compare this field because they do not store this field in their patient data, the change flag must not be set and the data from the request must not be returned the change flag is in the ins segment ins03 = 001, ins04 = 25 in the case of error conditions including patient not found aaa error 75, contract /authorization error aaa error 41, and general system errors – aaa error 42, do not send back patient information from the eligibility request therefore, in these error conditions, no patient data should be sent back the provider vendor should disregard any patient information under these error scenarios examples this is an example where the pbm/payer should indicate that a change has been made and set the change flag in the ins segment provider vendor sends joe m doe, dob 19550412, gender male, and address 55 high street, seattle, wa 55111 pbm/payer returns joseph m doe, dob 19550412, gender male, and address 55 high street, st paul, mn 55111 in this example, the pbm/payer does not need to set the change flag because they have not changed any of the information returned, but the middle initial is blank due to the field not being supported in the pbm/payer’s system provider vendor sends joe m doe, dob 19550412, gender male, and address 55 high street, st paul mn, 55111 pbm/payer returns joe doe, dob 19550412, gender male, and address 55 high street, st paul mn, 55111 in this example, the pbm/payer looks up the information and finds a blank for the middle name (which is a supported field in the pbm/payer’s system) this is considered a change so the change flag needs to be set provider vendor sends joe m doe, dob 19550412, gender male, pbm/payer returns joe doe, dob 19550412, gender male, this is an example where the patient is not found, so none of the patient information is returned provider vendor sends joe m doe, dob 19550412, gender male, and address 55 high street, st paul mn 55111 pbm/payer returns no patient data and an aaa segment with error 75 – subscriber/insured not found 270 eligibility, coverage, or benefit inquiry this section contains a subset of information on the eligibility, coverage, or benefit inquiry transaction set (270) for use within the context of an e prescribing environment since pbm/payers uniquely identify each member, the subscriber level should be used instead of the dependent level however, receivers of the eligibility request are required to be able to handle patients at the dependent level since the standard allows it reference asc x12n/005010x279a1 health care eligibility benefit inquiry and response (270/271) sec 1 4 2 page 5 notes this guide only includes data elements where surescripts has specific requirements or further explains the field usage refer to x12n/005010x279a1 health care eligibility benefit inquiry and response (270/271) for a complete list of segments and elements in addition, comments below where codes are specified are either to call out surescripts notes and/or to show the code recommended by surescripts for a full list of codes, please refer to x12n/005010x279a1 health care eligibility benefit inquiry and response (270/271) unless specified otherwise, the information in the tables below apply to both eligibility and eligibility for pharmacy elements that are grouped together may be marked as mandatory; however, if the group itself is marked as conditional or recommended, then these are only required if you use the group requirement designation code description mandatory the element must be used per the specification (e g , xml schema validation) note the term mandatory applies to mandatory and required fields in the different standards business rule if sent, the element must be used per the surescripts business rule note not all business rules reside in this table conditional the element is to be used per the conditions specified note the term conditional applies to conditional and situational fields in the different standards for example, x12 uses the term situational recommended surescripts recommends sending the element as a best practice optional some fields do not have specific conditions data should be sent if available not used not used by surescripts header segment id (eligibility request) segment name (eligibility request) code comments isa interchange control header mandatory isa01 authorization information qualifier mandatory value 00 no authorization information present (no meaningful information in data element i02) isa02 authorization information mandatory not used fill with blanks isa03 security information qualifier mandatory code to identify the type of information in the security information value 01 password isa04 security information mandatory from the provider vendor, this is the password assigned by surescripts for the provider vendor from surescripts, this is the password surescripts uses when sending to the pbm/payer isa05 interchange id qualifier mandatory qualifier zz mutually defined isa06 interchange sender id mandatory from the provider vendor system, this is the participant id as assigned by surescripts from surescripts to the pbm/payer, this is surescripts’ id isa07 interchange id qualifier mandatory qualifier zz mutually defined isa08 interchange receiver id mandatory from the provider vendor system to surescripts, the provider vendor system must use the surescripts id designated by surescripts integration for the customer’s specific use case from the pharmacy to surescripts, the pharmacy system must use the surescripts id s00000000000010 from surescripts to the pbm/payer, this is pbm/payer's participant id for a full list of possible surescripts ids that relate to eligibility, see appendix c surescripts eligibility identifiers docid\ tjkqblgauejjwr7ajmq1c isa09 interchange date mandatory date format yymmdd required isa10 interchange time mandatory time format hhmm required isa11 repetition separator mandatory surescripts recommends using hex 1f isa12 interchange control version number mandatory this version number covers the interchange control segments 00501 – standards approved for publication by asc x12 procedures review board through october 2003 isa13 interchange control number mandatory from the provider vendor system, this is a unique id assigned by the provider vendor system for transaction tracking from surescripts, this is a unique id assigned by surescripts for transaction tracking this id will be returned on a ta1 if an error occurs providing a unique number will assist in resolving errors and tracking messages isa14 acknowledgement requested mandatory since these transactions are real time only, surescripts does not use this field to determine whether to create a ta1 acknowledgment value 0 no acknowledgment requested (recommended by surescripts) isa15 interchange usage indicator mandatory values p production data t test data isa16 component element separator mandatory surescripts recommends using hex 1c gs functional group header mandatory gs01 functional identifier code mandatory value hs gs02 application sender’s code mandatory from the provider vendor system, this is the participant id as assigned by surescripts from surescripts to pbm/payer, this is surescripts’ id gs03 application receiver’s code mandatory from the provider vendor system to surescripts, the provider vendor system must use the surescripts id designated by surescripts integration for the customer’s specific use case from the pharmacy to surescripts, the pharmacy system must use the surescripts id s00000000000010 from surescripts to pbm/payer, this is pbm/payer's participant id for a full list of possible surescripts ids that relate to eligibility, see appendix c surescripts eligibility identifiers docid\ tjkqblgauejjwr7ajmq1c gs06 group control number mandatory the control number should be unique across all groups within this transaction set this id will be returned on an ak102 of the 999 acknowledgment if an error occurs providing unique numbers will assist in resolving errors and tracking messages avoid using leading zeros in this field st transaction set header mandatory st02 transaction set control number mandatory identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set the transaction set control numbers in st02 and se02 must be identical this unique number also aids in error resolution research start with the number, for example "0001", and increment from there this number must be unique within a specific group and interchange, but can repeat in other groups and interchanges note this id will be returned on an ak202 of the 999 acknowledgment if an error occurs providing a unique number will assist in resolving errors and tracking messages bht beginning of hierarchical transaction mandatory bht02 transaction set purpose code mandatory value 13 request (surescripts customers utilize this option only ) bht03 reference identification mandatory because surescripts only supports real time, this element is required detail segment id (eligibility request) segment name (eligibility request) code comments loop id – 2000a information source level hl information source level (pbm/payer) mandatory loop id – 2100a information source name nm1 information source name mandatory nm101 entity identifier code mandatory value 2b third party administrator (recommended by surescripts) nm102 entity type qualifier mandatory value 2 non person entity (recommended by surescripts) nm103 name last mandatory from the provider vendor system, the source is unknown so this would be surescripts from surescripts, surescripts will place the source name here nm108 identification code qualifier mandatory value pi payer identification (recommended by surescripts) nm109 identification code mandatory from the provider vendor system to surescripts, the provider vendor system must use the surescripts id designated by surescripts integration for the customer’s specific use case from the pharmacy to surescripts, the pharmacy system must use the surescripts id s00000000000010 from surescripts to pbm/payer, surescripts will place the participant id of the pbm/payer's here for a full list of possible surescripts ids that relate to eligibility, see appendix c surescripts eligibility identifiers docid\ tjkqblgauejjwr7ajmq1c loop id – 2000b information receiver level hl information receiver level (physician) mandatory loop id – 2100b information receiver name nm1 information receiver name mandatory nm101 entity identifier code mandatory value 1p provider (recommended by surescripts) nm102 entity type qualifier mandatory indicates if the entity is an individual person or an organization value 1 person (recommended by surescripts for eligibility) 2 non person entity (recommended by surescripts for eligibility for pharmacy) nm103 name last or organization name mandatory if value "1" was sent in nm102, the individual’s last name (physician’s last name) is sent in this field if value "2" was sent in nm102, the organization name is sent in this field nm108 identification code qualifier mandatory qualifier xx centers for medicare and medicaid services national provider identifier nm109 identification code mandatory the npi is mandated surescripts will reject if the nm108 and the nm109 are not populated the npi will follow a two step validation process the npi check digit will be validated using the luhn formula for specific information see https //www cms gov/regulations and guidance/administrative simplification/nationalprovidentstand/downloads/npicheckdigit pdf https //www cms gov/regulations and guidance/administrative simplification/nationalprovidentstand/downloads/npicheckdigit pdf notes it may take up to one week for an npi to become active in the surescripts directory the nppes validation process is only applicable in the production environment ref information receiver additional identification (provider vendor system identification) conditional ref01 reference identification qualifier mandatory value eo – submitter identification number (a unique number identifying the submitter of the transaction set ) ref02 reference identification mandatory surescripts defined participant id for the provider vendor system business rule ref eo must match the isa 06 on the incoming eligibility request ref03 description conditional must not be used for the eo qualifier n3 information receiver address conditional required when the information receiver is a provider who has multiple locations and it is needed to identify the location relative to the request n4 information receiver city/state/zip code conditional required when the information receiver is a provider who has multiple locations and it is needed to identify the location relative to the request n401 city name mandatory n402 state or province code conditional this field is required if city name (n401) is in the u s or canada n403 postal code conditional this field is required if city name (n401) is in the u s or canada n404 country code conditional do not send the us country code loop id – 2000c subscriber level hl subscriber level mandatory trn subscriber trace number conditional loop id – 2100c subscriber name nm1 subscriber name mandatory nm103 name last or organization name recommended individual’s last name or organization name nm104 name first recommended individual’s first name use formal name do not use preferred name or nickname nm105 name middle recommended middle name or initial nm107 name suffix recommended suffix to individual’s name if applicable, the name suffix should be included in this field nm108 identification code qualifier conditional from the provider vendor system this is blank surescripts will put the qualifier "mi" into this field value mi member identification number nm109 identification code conditional from the provider vendor system this is blank surescripts will put the pbm unique member id into this field ref subscriber additional identification (ssn#, person code) conditional n3 subscriber address conditional n301 address information mandatory address information n4 subscriber city/state/zip code recommended surescripts strongly recommends sending this segment to aid in patient matching if this field is not sent, the patient may not be found n401 city name mandatory n402 state or province code recommended this field is required if city name (n401) is in the u s or canada n403 postal code recommended this field is required if city name (n401) is in the u s or canada n404 country code conditional do not send us country code dmg subscriber demographic information conditional dmg02 date time period recommended use this date for the date of birth of the individual dmg03 gender code recommended code indicating the sex of the individual values f – female m – male if the sex of the individual is unknown or other, do not send this field in the eligibility request dtp subscriber date conditional absence of a plan date indicates the request is for the date the transaction is processed and the information source is to process the transaction in the same manner as if the processing date was sent the eligibility date of service and the eligibility transmission date must be within three (3) days of the patient interaction (past and future) loop id 2110c subscriber eligibility or benefit inquiry eq subscriber eligibility or benefit inquiry information (health benefit plan coverage) conditional eq01 service type code conditional value 30 health benefit plan coverage (recommended by surescripts) instead of specifying a specific service type code, this code allows the information source to respond with all the relevant service types if other service types are sent, the responder will only respond to pharmacy related coverages an information source may support the use of service type codes other than “30" (health benefit plan coverage) in eq01 at their discretion trailer segment id (eligibility request) segment name (eligibility request) code comments se transaction set trailer mandatory ge functional group trailer mandatory iea interchange control trailer mandatory 271 eligibility, coverage, or benefit information this section contains a subset of information on the eligibility, coverage, or benefit information transaction set (271) for use within the context of e prescribing pbm/payer's uniquely identify each patient, thus the subscriber level should be used instead of the dependent level however, receivers of the eligibility request are required to be able to handle patients at the dependent level since the standard allows it also, when the patient is submitted in the dependent loop (in eligibility request) they must be returned in the subscriber loop (in eligibility response) this is due to the fact that pbm/payer's assign unique identifiers to all members thus they are deemed to be subscribers according to the standard notes this guide only includes data elements where surescripts has specific requirements or further explains the field usage refer to x12n/005010x279a1 health care eligibility benefit inquiry and response (270/271) for a complete list of segments and elements in addition, comments below where codes are specified are either to call out surescripts notes and/or to show the code recommended by surescripts for a full list of codes, please refer to x12n/005010x279a1 health care eligibility benefit inquiry and response (270/271) unless specified otherwise, the information in the tables below apply to both eligibility and eligibility for pharmacy elements that are grouped together may be marked as mandatory; however, if the group itself is marked as conditional or recommended, then these are only required if you use the group requirement designation code description mandatory the element must be used per the specification (e g , xml schema validation) note the term mandatory applies to mandatory and required fields in the different standards business rule if sent, the element must be used per the surescripts business rule note not all business rules reside in this table conditional the element is to be used per the conditions specified note the term conditional applies to conditional and situational fields in the different standards for example, x12 uses the term situational recommended surescripts recommends sending the element as a best practice optional some fields do not have specific conditions data should be sent if available not used not used by surescripts header segment id (eligibility response) segment name (eligibility response) code comments isa interchange control header mandatory isa01 authorization information qualifier mandatory value 00 no authorization information present (no meaningful information in i02) isa02 authorization number mandatory not used fill with blanks isa03 security information qualifier mandatory code to identify the type of information in the security information value 01 password isa04 security information mandatory from the pbm/payer to surescripts, this is the surescripts system assigned password to the pbm/payer from surescripts, this is the password surescripts uses when sending to the provider vendor isa05 interchange id qualifier mandatory qualifier zz mutually defined isa06 interchange sender id mandatory from the pbm/payer to surescripts, this is the pbm/payer's participant id from surescripts to the provider vendor system, this is surescripts’ id isa07 interchange id qualifier mandatory qualifier zz mutually defined isa08 interchange receiver id mandatory from the pbm/payer, this is surescripts’ id from surescripts to the provider vendor system, this is the provider vendor’s participant id isa09 interchange date mandatory date format yymmdd required isa10 interchange time mandatory time format hhmm required isa11 repetition separator mandatory surescripts recommends using hex 1f isa12 interchange control version number mandatory this version number covers the interchange control segments 00501 – standards approved for publication by asc x12 procedures review board through october 2003 isa13 interchange control number mandatory from the pbm/payer, this is the pbm/payer's unique identification of this transaction from surescripts, this is surescripts’ unique identification of this transaction this number is returned on a ta1 if an error occurs providing a unique number will assist in resolving errors and tracking messages isa14 acknowledgement requested mandatory the ta1 segment will only be transmitted in the event of a header or trailer error ta1 segments should not be returned for accepted transactions if there are no errors at the envelope level (isa, gs, ge, iea segments) then ta1 segments should not be returned since these transactions are real time only, surescripts does not use this field to determine whether to create a ta1 acknowledgment isa15 interchange usage indicator mandatory values p production data t test data isa16 component element separator mandatory surescripts recommends using hex ic gs functional group header mandatory gs01 functional identifier code mandatory value hb gs02 application sender’s code mandatory from the pbm/payer to surescripts, this is the pbm/payer's participant id from surescripts to the provider vendor system, this is surescripts’ id gs03 application receiver’s code mandatory from the pbm/payer to surescripts, this is surescripts’ id from surescripts to the provider vendor system, this is the provider vendor’s participant id gs06 group control number mandatory the control number should be unique across all functional groups within this transaction set this number is returned on an ak102 of the 999 acknowledgment if an error occurs providing a unique number will assist in resolving errors and tracking messages st transaction set header mandatory st02 transaction set control number mandatory this id will be returned on an ak202 of the 999 acknowledgment if an error occurs providing a unique number will assist in resolving errors and tracking messages bht beginning of hierarchical transaction mandatory bht03 reference identification mandatory because this implementation is real time, this number from the eligibility request is to be returned in this field detail segment id (eligibility response) segment name (eligibility response) code comments loop id – 2000a information source level hl information source level (pbm/payer) mandatory aaa request validation conditional aaa03 reject reason code mandatory value 42 unable to respond at current time note surescripts could not process the transaction loop id – 2100a information source name nm1 information source name mandatory nm101 entity identifier code mandatory value 2b third party administrator (recommended by surescripts) nm102 entity type qualifier mandatory value 2 non person entity (recommended by surescripts) nm103 organization name mandatory this is the name of the pbm/payer that provides the data it does not include surescripts at any point nm108 identification code qualifier mandatory surescripts will utilize pi to identify the payer (the pbm/payer) value pi payer identification (recommended by surescripts) nm109 identification code mandatory this is the pbm/payer’s participant id aaa request validation conditional aaa03 reject reason code mandatory values 41 authorization/access restrictions to the provider vendor system from surescripts, 41 would indicate that the provider vendor system cannot request transactions for the identified pbm/payer to surescripts from the pbm/payer, 41 would indicate that surescripts cannot request eligibility from this pbm/payer 42 unable to respond at current time pbm/payer cannot process at current time 79 invalid participant identification the pbm/payer will use this code to indicate that information source identified in loop 2100a is invalid loop id – 2000b information receiver level hl information receiver level (physician) conditional loop id – 2100b information receiver name nm1 information receiver name mandatory nm101 entity identifier code mandatory value 1p provider (recommended by surescripts) nm102 entity type qualifier mandatory value 1 person (recommended by surescripts) nm108 identification code qualifier mandatory qualifier xx centers for medicare and medicaid services national provider identifier nm109 identification code mandatory the npi is mandated surescripts will reject if the nm108 and the nm109 are not populated ref information receiver additional identification (provider vendor system identification) recommended surescripts defined participant id for the provider vendor system ref01 reference identification qualifier mandatory value eo submitter identification number (a unique number identifying the submitter of the transaction set ) ref02 reference identification mandatory surescripts defined participant id for the provider vendor system ref03 description conditional not used for the eo qualifier aaa information receiver request validation conditional aaa03 reject reason code mandatory values 15 required application data missing use this code only when the information receiver’s additional identification is missing (not enough information given to identify the provider vendor system ) 41 authorization/access restrictions (a contract does not exist between this provider vendor system and the pbm/payer to exchange eligibility information ) 43 invalid/missing provider identification (if there is an npi error, surescripts will send an error stating npi is not valid ) 79 invalid participant identification (surescripts cannot validate the receiver ) loop id – 2000c subscriber level hl subscriber level conditional trn subscriber trace number conditional echo the trace number back from the eligibility request in this field loop id – 2100c subscriber name nm1 subscriber name mandatory nm103 name last conditional this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request nm104 name first conditional this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request nm105 name middle conditional this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request nm107 name suffix conditional this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request nm108 identification code qualifier conditional value mi member identification number nm109 identification code conditional subscriber pbm unique member id send the full pbm unique member id ref subscriber additional identification (person code, cardholder id, ssn, patient account number) recommended ref01 reference identification qualifier mandatory value hj identity card number (cardholder id) strongly recommended by surescripts 49 family unit member (person code) sy social security number recommended to not send social security number social security number may not be used for any federally administered programs such as medicare ej patient account number echo the patient account number back from the eligibility request in this field n3 subscriber address conditional n301 address information mandatory this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request n302 address information conditional this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request n4 subscriber city/state/zip code conditional required to be sent when patient is the subscriber n401 city name mandatory this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request n402 state or province code conditional this field is required if city name (n401) is in the u s or canada this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request n403 postal code conditional this field is required if city name (n401) is in the u s or canada this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request n404 country code conditional do not send us country code aaa subscriber request validation conditional aaa03 reject reason code mandatory values 15 required application data missing at surescripts – not enough information for surescripts to identify patient at pbm/payer – wants more information than what was supplied 62 service date invalid sent if service date is greater than 3 days in the past or future of the transmission date of the message dmg subscriber demographic information conditional dmg02 date time period conditional this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request dmg03 gender code conditional this data is to be returned from the pbm/payer system, and should not be echoed back from the eligibility request values m – male f – female u – unknown or other ins subscriber relationship conditional ins01 yes/no condition or response code mandatory for the provider vendor system, this will always be yes (y), if supplied ins02 individual relationship code mandatory for the provider vendor system, this will always be self (18) ins03 maintenance type code conditional code identifying the reason for the maintenance change use this element (and code “25” in ins04) if any of the identifying elements for the subscriber have been changed from those submitted in the eligibility request value 001 change ins04 maintenance reason code conditional code identifying the reason for the maintenance change use this element (and code “001” in ins03) if any of the identifying elements for the subscriber have been changed from those submitted in the eligibility request value 25 change in identifying data elements use this code to indicate that a change has been made to the primary elements that identify a specific person such elements include but are not limited to first name, last name, patient gender, date of birth, and address dtp subscriber date conditional dtp02 date time period format qualifier mandatory value d8 date expressed in format ccyymmdd (surescripts recommends d8 ) loop id – 2110c subscriber eligibility or benefit information eb subscriber eligibility or benefit information recommended this segment indicates active and inactive coverage if the first iteration of the eb loop is set to “1” (active), then use subsequent eb loops for retail, for mail order, and optionally, for specialty pharmacy and/or ltc if the eb loop is set to “6” (inactive), then no other eb loops are required eb01 eligibility or benefit information mandatory code identifying eligibility or benefit information values 1 active coverage 6 inactive if the member is inactive, then no other eb loops are required to be sent v cannot process g out of pocket (stop loss) i non covered eb03 service type code conditional the eb loop repeats a value of “30” is sent in first iteration of the eb loop to determine if coverage is active for active coverage it is required to send subsequent eb 2110c loops for retail and for mail order subsequent 2110c loops may also be sent for specialty pharmacy and/or ltc for inactive coverage, then no other eb loops are required see acr e 103 in application certification requirements docid\ mnrieqkq0lo85h9ytmiro for more information values 30 health plan benefit coverage 88 pharmacy (retail benefit) 90 mail order prescription drug empty/null specialty pharmacy or ltc (see msg ) eb04 insurance type code recommended indicates type of insurance example values include but are not limited to c1 – commercial ma – medicare part a mc medicaid ot – medicare part d wc – workers comp eb05 plan coverage description conditional if eb03 contains 30 (active), then eb05 will contain the primary health plan name, if applicable if sent, surescripts requires applications to display this for prescribers and pharmacists see acr e 103 in application certification requirements docid\ mnrieqkq0lo85h9ytmiro for more information eb07 monetary amount conditional surescripts is utilizing this field for out of pocket accumulator eb01 set to g ref subscriber additional identification (plan id, group id/name, formulary id, alternative id, coverage list id, iin/pcn, and copay id) conditional when available, it is required that the pbm/payer sends iin/pcn/group id/group name/plan id and formulary file ids when this information is included on the eligibility response, the provider is able to select the most appropriate coverage for the patient and it is populated by the provider vendor downstream on prior authorization, real time prescription benefit, and newrx transactions see acr e 106 1 in the application certification requirements docid\ mnrieqkq0lo85h9ytmiro for more information iin note per ncpdp, since 8 digit iins are now being assigned, use the first 6 digits of the iin as the bin even if the first digit(s) is a zero once new version of the ncpdp telecommunication standard is adopted new, truncation will no longer be necessary refer to ncpdp iin/processor identification number (processor bin) use ncpdp processor id (bin) https //www ncpdp org/ncpdp/media/pdf/resources/ncpdp processor id (bin) pdf?ext= pdf for more information ref01 code qualifying the reference identification mandatory values 18 plan id 6p group number and group name als alternative list id cli coverage list id fo drug formulary number id ig insurance policy number (copay id) n6 plan network id (iin/pcn) (strongly recommended by surescripts ) ref02 reference identification mandatory reference information as defined for a particular transaction set or as specified by the reference identification qualifier use this information for the reference number as qualified by the preceding data element (ref01) note group number (6p) refers to the prescription benefit coverage group id (which is typically 15 characters or less), not the member plan group id number that refers to medical, dental, etc coverage ref03 description recommended sending this element is strongly recommended by surescripts and should only be used for group name and/or pcn number ref01=6p (ref03 will contain group name ) ref01=n6 (ref03 will contain pcn number ) dtp subscriber eligibility/benefit date conditional surescripts recommends sending back the date range of the health plan benefit for this patient’s coverage dtp02 date time period format qualifier mandatory value rd8 range of dates expressed in format ccyymmdd ccyymmdd (surescripts recommends rd8 ) aaa subscriber request validation conditional msg message text conditional msg01 free form message text mandatory this free text field is used to communicate specialty pharmacy or long term care coverage and will be populated by surescripts as a hint to the requester on what fields would assist in identifying the patient this is sent if patient is not found and one or more of the following fields are missing; first name, last name, zip code or date of birth loop id – 2115c subscriber eligibility or benefit additional information ls loop header conditional loop id – 2120c subscriber benefit related entity name nm1 subscriber benefit related entity name recommended this segment is used for mail only benefit, long term care, and determining primary, secondary, and tertiary eligibility coverages example of secondary coverage nm1 sep 2 pbm company pi pbm123 nm101 entity identifier code mandatory code identifying an organization entity, a physical location, a property, or an individual values 13 contracted service provider (use for mail only benefit used to further clarify benefits, including mail only, specialty and long term care ) prp – primary payer sep – secondary payer ttp – tertiary payer nm102 entity type qualifier mandatory value 2 non person entity (surescripts recommends using 2) nm108 identification code qualifier conditional value sv service provider number (recommended by surescripts) pi – payer identification (surescripts assigned id) use this code for the identification number assigned by the information source le loop trailer conditional trailer segment id (eligibility response) segment name (eligibility response) code comments se transaction set trailer mandatory ge functional group trailer mandatory iea interchange control trailer mandatory ta1 interchange acknowledgement requirement designation code description mandatory the element must be used per the specification (e g , xml schema validation) note the term mandatory applies to mandatory and required fields in the different standards business rule if sent, the element must be used per the surescripts business rule note not all business rules reside in this table conditional the element is to be used per the conditions specified note the term conditional applies to conditional and situational fields in the different standards for example, x12 uses the term situational recommended surescripts recommends sending the element as a best practice optional some fields do not have specific conditions data should be sent if available not used not used by surescripts ics interchange control structures the purpose of this standard is to define the control structures for the electronic interchange of one or more encoded business transactions including the edi (electronic data interchange) encoded transactions of accredited standards committee x12 this standard provides the interchange envelope of a header and trailer for the electronic interchange through a data transmission, and it provides a structure to acknowledge the receipt and processing of this envelope notes this guide only includes data elements where surescripts has specific requirements or further explains the field usage refer to asc x12n/005010x231a1 implementation acknowledgement for health care insurance (999) for a complete list of segments and elements in addition, comments below where codes are specified are either to call out surescripts notes and/or to show the code recommended by surescripts for a full list of codes, please refer to asc x12n/005010x231a1 implementation acknowledgement for health care insurance (999) unless specified otherwise, the information in the tables below apply to both eligibility and eligibility for pharmacy elements that are grouped together may be marked as mandatory; however, if the group itself is marked as conditional or recommended, then these are only required if you use the group segment id (ta1) segment name (ta1) code comments isa interchange control header mandatory isa01 authorization information qualifier mandatory value 00 no authorization information present (no meaningful information in i02) isa02 authorization information mandatory not used fill with blanks isa03 security information qualifier mandatory code to identify the type of information in the security information value 01 password isa04 security information mandatory password utilized by the sender to access the receiver system isa05 interchange id qualifier mandatory qualifier zz mutually defined isa06 interchange sender id mandatory the sender participant id participant id is the surescripts system participant id isa07 interchange id qualifier mandatory qualifier zz mutually defined isa08 interchange receiver id mandatory the receiver participant id participant id is assigned by surescripts isa09 interchange date mandatory date format yymmdd required isa10 interchange time mandatory time format hhmm required isa11 repetition separator mandatory surescripts recommends using hex 1f isa12 interchange control version number mandatory this version number covers the interchange control segments 00501 – standards approved for publication by asc x12 procedures review board through october 2003 isa13 interchange control number mandatory a unique number assigned by the sender used to communicate from the receiver back to the sender to identify this transaction isa14 acknowledgment requested mandatory no ta1s are returned for ta1s isa15 interchange usage indicator mandatory values p production data t test data isa16 component element separator mandatory surescripts recommends using hex 1c ta1 interchange acknowledgment conditional surescripts only supports the ta1 for errors it is not sent as an acknowledgment for successful messages iea interchange control trailer mandatory 999 implementation acknowledgement for health care insurance notes this guide only includes data elements where surescripts has specific requirements or further explains the field usage refer to asc x12n/005010x231a1 implementation acknowledgement for health care insurance (999) for a complete list of segments and elements in addition, comments below where codes are specified are either to call out surescripts notes and/or to show the code recommended by surescripts for a full list of codes, please refer to asc x12n/005010x231a1 implementation acknowledgement for health care insurance (999) unless specified otherwise, the information in the tables below apply to both eligibility and eligibility for pharmacy elements that are grouped together may be marked as mandatory; however, if the group itself is marked as conditional or recommended, then these are only required if you use the group requirement designation code description mandatory the element must be used per the specification (e g , xml schema validation) note the term mandatory applies to mandatory and required fields in the different standards business rule if sent, the element must be used per the surescripts business rule note not all business rules reside in this table conditional the element is to be used per the conditions specified note the term conditional applies to conditional and situational fields in the different standards for example, x12 uses the term situational recommended surescripts recommends sending the element as a best practice optional some fields do not have specific conditions data should be sent if available not used not used by surescripts header segment id(999) segment name(999) code comments isa interchange control header mandatory isa01 authorization information qualifier mandatory value 00 no authorization information present (no meaningful information in i02) isa02 authorization number mandatory information used for additional identification or authorization of the interchange sender or the data in the interchange; the type of information is set by the authorization information qualifier (i01) isa03 security information qualifier mandatory code to identify the type of information in the security information value 01 password isa04 security information mandatory password used by the sender to access the receiver system password assigned by surescripts isa05 interchange id qualifier mandatory qualifier zz mutually defined isa06 interchange sender id mandatory from surescripts to the pbm/payer, this is surescripts’ id isa07 interchange id qualifier mandatory qualifier zz mutually defined isa08 interchange receiver id mandatory the receiver participant id participant id is assigned by surescripts isa09 interchange date mandatory date format yymmdd required isa10 interchange time mandatory time format hhdd required isa11 repetition separator mandatory surescripts recommends using hex 1f isa12 interchange control version number mandatory this version number covers the interchange control segments 00501 – standards approved for publication by asc x12 procedures review board through october 2003 isa13 interchange control number mandatory the sender’s unique identification of this transaction isa14 acknowledgment requested mandatory no ta1s are returned for 999s isa15 interchange usage indicator mandatory values p production data t test data isa16 component element separator mandatory surescripts recommends using hex 1c gs functional group header mandatory gs02 application sender’s code mandatory the sender participant id participant id is assigned by surescripts gs03 application receiver’s code mandatory the receiver participant id participant id is assigned by surescripts gs08 version / release / industry identifier code mandatory value 005010x231a1 st transaction set header mandatory ak1 functional group response header mandatory loop id 2000 ak2 transaction set response header ak2 transaction set response header conditional ak203 implementation convention reference conditional required when the st03 value is available in the transaction set to which this 999 transaction set is responding since st03 is required the ak203 must be present loop id 2100 ak2/ik3 error identification ik3 error identification conditional ctx segment context conditional ctx business unit identifier conditional loop id 2110 ak2/ik3/ik4 implementation data element note ik4 implementation data element note conditional ctx element context conditional ik5 transaction set response trailer mandatory ik501 transaction set acknowledgment code mandatory value r rejected (surescripts recommends r ) ak9 functional group response trailer mandatory ak901 functional group acknowledgment code mandatory value r rejected (surescripts recommends use of r ) trailer segment id (999) segment name (999) code comments se transaction set trailer mandatory ge functional group trailer mandatory iea interchange control trailer mandatory hierarchical loops eligibility request hierarchical organization the diagram below depicts the hierarchical organization of all loops and includes those related specifically to the eq segment eligibility response hierarchical organization the diagram below depicts the hierarchical organization of all loops and includes those related specifically to the eb segments