Messages Overview

18 min

note for the purposes of this guide, the health care eligibility, coverage, or benefit inquiry (270) will be referred to as the eligibility request and the health care eligibility, coverage, or benefit information (271) will be referred to as the eligibility response message descriptions eligibility request/response eligibility request and eligibility response messages are used to request and respond to a patient eligibility check these messages enable customers to supply a patient’s name and demographic information to surescripts and get back some or all of the following information from each pbm/payer that covers the patient health plan number/name cardholder id relationship code person code group number, group name formulary id alternative list id coverage list id copay list id iin (formerly bin) pcn type of coverage primary secondary tertiary type of prescription benefit pharmacy (retail) mail order specialty pharmacy long term care (ltc) interchange acknowledgment this x12 specification, ta1, is utilized to acknowledge receipt/header errors for unrecognizable messages and errors in real time for the surescripts message set, it only applies to the eligibility request and eligibility response none of the other specifications utilize this message implementation acknowledgement the implementation acknowledgement, or 999, informs the submitter that the functional group arrived at the destination and is required as a response to receipt of an x12 message, and only for errors with real time messages surescripts only supports a real time environment for the eligibility request and eligibility response messages, so the 999 will only be sent if there are errors the 999 reports on errors generated due to data or segment issues that do not comply with x12n/005010x279a1 health care eligibility benefit inquiry and response (270/271) eligibility message flow the following steps depict the eligibility message flow a requester sends an eligibility request to surescripts surescripts validates the format of the transaction surescripts locates the patient based on demographic information surescripts determines to which pbm/payers the eligibility request should be directed the pbm/payer verifies the patient and responds to surescripts with an eligibility response indicating the patient’s eligibility status surescripts validates the format of the incoming eligibility response, consolidates all eligibility responses and sends the information back to the requester eligibility detailed message flow scenarios the following diagrams depict various scenarios where nak, ta1, 999, and ack messages are sent in response to an eligibility message scenario 1 surescripts cannot recognize message or system error 1a) eligibility request message is sent to surescripts 1b) surescripts cannot recognize the message and sends error text back to the provider vendor errors include cannot validate the sender’s participant id and/or password cannot identify the message a system error occurs before the message is being processed scenario 2 surescripts recognized message format but errors found 2a) eligibility request message is sent to surescripts 2b) surescripts finds an error within the header and reports errors with the ta1 scenario 3 surescripts recognized message format but errors found 3a) eligibility request message is sent to surescripts 3b) surescripts finds a syntax error within the message and reports errors with the 999 scenario 4 pbm/payer cannot recognize message or system error 4a) eligibility request message is sent to surescripts 4b) surescripts forwards the message on to the pbm/payer 4c) the pbm/payer cannot recognize the message or system error and sends error text to surescripts 4d) surescripts creates an eligibility response with errors and returns it to the provider vendor scenario 5 pbm/payer validates message and returns eligibility response with aaa segment in the eligibility response showing business error to provider vendor 5a) eligibility request message is sent to surescripts 5b) surescripts forwards the message on to the pbm/payer 5c) the pbm/payer returns the eligibility response business error in aaa segment 5d) surescripts forwards the eligibility response message on to the provider vendor scenario 6 pbm/payer returns non compliant eligibility response (i e , syntax error or header error) 6a) eligibility request message is sent to surescripts 6b) surescripts forwards the message on to the pbm/payer 6c) the pbm/payer returns an eligibility response with syntax error or header error 6d) surescripts creates an eligibility response with aaa (request validation), indicating the type of error, and returns it to the provider vendor 6e) surescripts sends ta1 or a syntax error acknowledgment (999) to pbm/payer 6f) pbm/payer returns ack general interface description the message specifications have been defined to follow hipaa standards where available and to allow the most effective processing delimiters separate components, data elements, and segments (see subsection appendix b dynamic delimiters docid\ vt vmhbmeumoogijcuazq for clarification) for the x12 specifications, the delimiters are defined in the isa segment of the message if a data element in the middle of a segment is omitted, the separator acts as a “place holder” the significant characters must be left justified leading spaces, if used, are assumed to be significant characters trailing spaces should be suppressed dynamic delimiters x12 utilizes delimiters to separate component, segments, elements, etc or as indicators (i e , for segment repetition ) these delimiters are defined within specified segments of the messages customer's systems need to be able to dynamically set and handle these delimiters surescripts recommends the use of unprintable characters as delimiters rather than the entire full character set (refer to appendix b dynamic delimiters docid\ vt vmhbmeumoogijcuazq for a full list of acceptable characters) for x12 messages, the delimiter set is defined within the isa segment the following is an example \isa 00 01 pwphy12345 zz pocid zz s00000000000001 091217 0309 ^ 00501 000000001 1 p \[ \ in the example above, the asterisk ( ) is a delimiter based on its position immediately following isa the segment delimiter is determined by calculating the last character of the fixed width row the row is 106 total bytes; therefore, the segment delimiter is the 106th character \choosing a delimiter\ surescripts has published a list of allowed delimiters for the x12 messages (refer to appendix b dynamic delimiters docid\ vt vmhbmeumoogijcuazq for a full list of acceptable characters) the customers may choose any allowed delimiter desired for the messages they create however, it is important that customers communicate which delimiters they are using to ensure they will not cause issues with their trading partners’ messages surescripts recommends the following delimiters for x12 data data element separator – hex 1d, decimal 29 segment terminator – hex 1e, decimal 30 component element separator (isa 16) – hex 1c, decimal 28 repetition character (isa11) – hex 1f, decimal 31 \using dynamic delimiters\ a surescripts customer can expect to receive delimiters that are different than the set they define for their messages the customer needs to determine the delimiters dynamically when the message is processed according to the rules listed in the above section see appendix b dynamic delimiters docid\ vt vmhbmeumoogijcuazq for a complete list of acceptable characters delimiter examples the delimiters used in the examples below are the for segment separation and the for element separation \example 1 \ nm1 il 1 smith john l 34 444115555 elements 6 and 7 are not included; therefore, the asterisks ( ) act as placeholders for the omitted elements when data elements are omitted from the end of a segment, the data element delimiters do not need to be used the segment is ended with a segment terminator \example 2 \ elements 8 and 9 can be omitted in the same segment as example 1 the new segment would become nm1 il 1 smith john l and not nm1 il 1 smith john l \example 3 \ surescripts does not publish segments that are hipaa compliant but not utilized by surescripts if a message contains these segments, it will still be valid and accepted; but the data within the segment may not be utilized abc abc01 abc02 abc03 abc04 abc05 abc06 if elements abc02 and abc03 are not used (not shown on the surescripts edi specifications) then no value should be sent however, the elements must be represented with a place holder because there are used elements (abc04, 05 and 06) after them this is the correct representation abc abc01 abc04 abc05 abc06 abc02 and abc03 must be represented so that it is known that the next data value is abc04 this is the incorrect representation abc abc01 abc04 abc05 abc06 if the placeholders for abc02 and abc03 are removed, abc04 would be mistaken for abc02 representation the following table lists the field type notation used within the messages type x12 notation alphanumeric an date dt decimal r id number id numeric nn string an time tm each element, if sent, has a minimum and maximum length for example\ an 1/3 means an alphanumeric with range from one to three characters an 3/3 means an alphanumeric with three characters numeric representation the decimal point is represented by a period and should be used as follows only when there are significant digits to the right of the decimal when there is a digit before and after the decimal point not with whole numbers for example, consider the following possible values for a 5 digit field correct 2 515 251 5 25 15 2515 0 2515 2 5 incorrect 2515 2515 3 00 character set the character set contains ascii values 32 – 126, which include symbols ! " # $ % & ' ( ) + , / ; < = > ? @ \[ \ ] ^ ` { | } numerals ø to 9 letters, upper and lower case a to z, a to z notes to assist in successful message processing, surescripts recommends not hardcoding the greater than symbol (>) in eligibility messages formulary ids are case sensitive see eligibility response fields docid\ zddrptevwemkwt3sz9gtr for more information for id file load only the decimal 94 ^ cannot be used in the id load process message validation surescripts will ensure that customers are in compliance with the message specifications outlined in this guide during testing and will continue to enforce once in production at a minimum, surescripts validations include the sender identification and authentication the recipient identification syntax of the message, including field lengths, data types, and code values surescripts business rules note surescripts acrs are not enforced as part of validations, but instead through the certification process failure mode/response approach surescripts’ error processing approaches are defined below error processing for eligibility request and eligibility response when a network communication or system failure occurs between the originating customer and surescripts, an error message will not be returned to the customer customers should establish a timeout parameter to allow their system to recover in the event that surescripts does not respond surescripts has defined four different levels of failure for exchanging errors with the customer \nak\ \ in instances where surescripts or a customer receives a message that is unrecognizable or a system error occurs, the recipient will send back an xml formatted nak \ the nak is an xml formatted message error (nak) \<nak status=”n”>text message\</nak> message type status error message nak 1 invalid syntax transaction cannot be identified nor processed nak 3 transaction timeout transaction timeout nak 4 system error system error an example of a nak \<nak status=”4”> system error \</nak> \ta1\ \ the ta1 acknowledges the receipt of a message it validates the syntax of the interchange isa and iea segments it notifies the sender that the receiver got the message, or it \ \reports errors so the sender is aware of interchange problems surescripts utilizes the ta1 to only report errors surescripts only utilizes the ta1 to report errors when an error occurs within the header \ \999\ \ the 999 message reports functional problems to the sender the sender will receive a 999 when a syntax error occurs in the body of the message or if the sender participant id is invalid \ ack the ack message is a small xml file, containing \<ack status=”y”/>, which serves as the pbm/payer’s acceptance of the 999 message \271\ \ when a non syntax error occurs during processing of an eligibility request message, aaa segments in the eligibility response will be used to report the errors \