Scope

The scope of the Claims and Reimbursement informative document defines the HL7 messaging and technical standards for:

• Electronic transmission of healthcare invoices, with supporting documents and reports, to authorized individuals and/or organizations;

• Inclusion of diagnostic and preventative intervention codes with each healthcare invoice;

• A query mechanism to allow authorized users to electronically inquire about information they have previously provided to a Payer;

• Minimum data sets;

• Minimum display and print standards; and

• Minimum data storage.

As used in this document the domain of Claims and Reimbursement excludes:

• Payer and benefit group specific processing and implementation rules;

• Jurisdictional specific processing and implementation rules;

• Processes for the submission of supporting documentation by third parties to Payers.

• Processes for the capture and processing of healthcare invoice data by a Provider;

• Processes for the adjudication, payment and reconciliation of healthcare invoices by a Payer;

• Referrals between Providers;

• Electronic funds transfer (EFT) messages; and,

• Implementation of the standard.

EHC^E01 – Submit HealthCare Services Invoice (event E01)

This message is used to submit a HealthCare Services Invoice to a TPA/Payer for processing and payment. A HealthCare Services Invoice may have 1 or more Product/Service Line Items (detail lines), grouped as a Product/Service Group. Each Product/Service Line Item represents a specific fee item. Refer to the beginning of this section for more information on the structure of a HealthCare Services Invoice.

This message can be used to submit a HealthCare Services Invoice or to resubmit a previously submitted HealthCare Services Invoice (in case it was not properly acknowledged the first time that it was submitted). This message cannot be used to update an Invoice (e.g., add or cancel Product/Service Line Items) or cancel a HealthCare Services Invoice. To cancel a HealthCare Services Invoice, use the EHC^E02 – Cancel HealthCare Services Invoice message. To update a HealthCare Services Invoice it must first be cancelled (see EHC^E02 – Cancel HealthCare Services Invoice) and then re–submitted using this message with new Invoice numbers.

This message can also be used as a Pre-Determination message. This allows a Provider Application to submit a HealthCare Services Invoice to a Payer Application and run it through the Payer's edit and adjudication engine. The only difference between a Pre-Determination Invoice and a regular Invoice is the Payer will not pay the Pre-Determination Invoice. Setting the Invoice Control on IVC to "PD" identifies a Pre-Determination Invoice.

Note that an EHC^E12 – Request Additional Information (pending) is a valid response for an EHC^E01 – Submit HealthCare Services Invoice. In this case, the interactions would be EHC^E01 -> EHC^E12 (pending).

Processing Rules:

1. Where multiple Payers can pay Invoices, they must be sent to Payers in the order identified as primary, secondary, tertiary, etc. Rules for determining primary, secondary, tertiary, etc. are not set in this document; these are set out by agencies in various jurisdictions.
   In addition, an Invoice must only be sent to a subsequent Payer (e.g., secondary) once Edit/Adjudication results have been received from a prior Payer (e.g., primary).

2. The Provider Application and the Payer Application must uniquely identify each Invoice, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Invoice, group or line item between the Provider Application and Payer Application.
   The Provider Invoice Number and Payer Invoice Number must be echoed on any subsequent interactions for the Invoice between the Provider Application and Payer Application.

3. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   If the Payer Application accepts the Invoice, the Provider Application must store 2 tracking numbers for each Product/Service Line Item, if present in the message pair. The Payer Application must also store 2 tracking numbers for each Product/Service Line Item, if present in the message pair.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

4. Each Product/Service Line Item must reference Location Identification information, which is defined by the LOC segment. Location Identification information may be specified with the Invoice, Product/Service Group and/or Product/Service Line Item.
   If specified with the Invoice Information, then the Location Identification information acts as a default for all Product/Service Line Items in the Invoice.
   If specified with the Product/Service Group Information, then the Location Identification information acts as a default for all Product/Service Line Items in the Product/Service Group.
   If specified with the Product/Service Line Item, then the Location Identification information supersedes (replaces) any defaults set by specifying Location Identification information with the Invoice or Product/Service Group.
   Location Identification information must be specified with the Product/Service Line Item if it has not been defaulted for the Invoice or Product/Service Group.

5. Some Payers require Provider Information to be included with an Invoice, which is defined by the ROL segment. In these situations, the ROL segment may be specified with the Invoice, Product/Service Group and/or Product/Service Line Item (note that the ROL segment also appears with Procedure Information, which is not covered by this processing rule).
   If specified with the Invoice Information, then the Provider Information acts as a default for all Product/Service Line Items in the Invoice.
   If specified with the Product/Service Group Information, then the Provider Information acts as a default for all Product/Service Line Items in the Product/Service Group.
   If specified with the Product/Service Line Item, then the Provider information supersedes (replaces) any defaults set by specifying Provider information with the Invoice or Product/Service Group.
   Provider Information, if required by the Payer, must be specified with the Product/Service Line Item if it has not been defaulted for the Invoice or Product/Service Group.

6. If Authorization Information is entered (AUT segment), then either the Authorization Identifier on AUT or Name of Authorizer on AUT must be specified.

7. The Billed Amount on PSG must be equal to the sum of all Product/Service Billed Amounts on PSL for all Product/Service Line Items for the particular Product/Service Group.

8. Procedures: If a PR1 segment (procedure/service) is specified for a particular patient, then the Provider performing the Procedure must be specified (using the corresponding ROL segment) if different from the Primary Care Provider specified for the same Product/Service Line Item.

9. The Product/Service Billed Amount on PSL must be equal to the Product/Service Gross Amount on PSL + sum of all Adjustment Amount on ADJ for all Provider Adjustments for the particular Product/Service Line Item. That is, the gross amount + any adjustments such as taxes, mark ups, dispensing fees, etc. must equal the billed amount.
   The Product/Service Billed Amount on PSL should be the amount the Provider is billing and should include all adjustments and all unit cost multipliers.

10. Product/Service Clarification Codes: Each Product/Service Line Item allows a number of clarification codes to be specified. These are specified as 2 fields: Product/Service Clarification Code Type and Product/Service Clarification Code Value. Both of these fields repeat within the PSL segment and must repeat the same number of times. For example, if 2 clarification codes are specified, then 2 repetitions of each field is required, the first repetition corresponding to the 1st clarification code, the second repetition corresponding to the 2nd clarification code.

11. Re-submitting an Invoice: If an Invoice or component is resubmitted with corrections (this rule does not apply to Invoices re-submitted in whole, without modification, due to network problems, etc.), new Invoice, Product/Service Group and Product/Service Line Items must be specified (for the subsequent Invoice).

12. A single group cannot have both multiple Patients and multiple Product/Service Line Items for the same Product/Service Group. In this situation, the multiple Patient and Product/Service Line Item must be split into multiple Product/Service Groups.

EHC^E02 – Cancel HealthCare Services Invoice (event E02)

This message is used to cancel one HealthCare Services Invoices or one Product/Service Group in an Invoice or one Product/Service Line Item in an Invoice that have previously been submitted to a TPA/Payer for processing and payment. Invoice Control codes are used to indicate the specific action being requested of the Payer (CN for Cancel Invoice, CG for Cancel Product/Service Group and CI for Cancel Product/Service Line Item). An Invoice that is cancelled must be marked as cancel only and not purged from the Payer Application's database.

The Payer may/may not be able to cancel the Invoice/Product/Service Line Item, and will indicate processing results in the response message. In some situations, the Payer has already paid the Product/Service Line Item, and therefore will hold a debit amount for the Payee until subsequent billing from the Payee utilizes the debit amount.

This message cannot be used to cancel or remove ancillary information for an Invoice and/or Product/Service Line Item such as Authorization or Contact information or any referenced health documents.

Processing Rules:

1. The Provider Application and the Payer Application must uniquely identify each Invoice, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Invoice, group or line item between the Provider Application and Payer Application.

2. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

3. At least one NTE segment must be included with this message to describe the cancellation reason for each Product/Service Line Item. The NTE segment may be specified with the Invoice (following the IVC segment) and applies to all Product/Service Line Items for that Invoice. If not specified with the Invoice, then it must be specified for each Product/Service Line Item (following the PSL segment).

4. Sending Organization and Sending Application on input message must be the same as the Sending Organization and Sending Application from the original Invoice (submitted via the EHC^E01 – Submit HealthCare Services Invoice message) for the specified Invoice being queried.

5. Provider reference numbers and Payer reference numbers must exist on Payer Application's database and must point to the same Invoice, Product/Service Group or Product/Service Line Item, otherwise an error must be generated (mismatched Invoice and/or Product/Service Line Item).

6. Product/Service Clarification Codes: Each Product/Service Line Item allows a number of clarification codes to be specified. These are specified as 2 fields: Product/Service Clarification Code Type and Product/Service Clarification Code Value. Both of these fields repeat within the PSL segment and must repeat the same number of times. For example, if 2 clarification codes are specified, then 2 repetitions of each field is required, the first repetition corresponding to the 1st clarification code, the second repetition corresponding to the 2nd clarification code.

7. To cancel an Invoice, use Invoice Control Code on IVC of "CN". In addition, the following fields must be supplied and must match the original Invoice submitted:
   HDR.Sending Organization
   IVC.Provider Organization
   IVC.Invoice Amount
   IVC.Provider Invoice Number
   IVC.Payer Invoice Number
   PYE.Payee Identification List

8. To cancel a Product/Service Group within an Invoice, use Invoice Control Code on IVC of "CG". In addition, the following fields must be supplied and must match the original Invoice submitted:
   HDR.Sending Organization
   IVC.Provider Organization
   IVC.Invoice Amount
   IVC.Provider Invoice Number
   IVC.Payer Invoice Number
   PYE.Payee Identification List
   PSG.Provider Product/Service Group Number
   PSG.Payer Product/Service Group Number

9. To cancel a Product/Service Line Item within an Invoice, use Invoice Control Code on IVC of "CI". In addition, the following fields must be supplied and must match the original Invoice submitted:
   HDR.Sending Organization
   IVC.Provider Organization
   IVC.Invoice Amount
   IVC.Provider Invoice Number
   IVC.Payer Invoice Number
   PYE.Payee Identification List
   PSG.Provider Product/Service Group Number
   PSG.Payer Product/Service Group Number
   PSL.Provider Product/Service Line Item Number
   PSL.Payer Product/Service Line Item Number
   PSL.Product/Service Code
   PSL.Product/Service Effective Date
   PSL.Billed Amount

10. This message must not be used to cancel a Product/Service Line Item in a Product/Service Group which was submitted with Adjudicated as Group = "Y".

QBP^E03 – Query HealthCare Services Invoice Status (event E03)

This message is used to query the status of a HealthCare Services Invoice. There are 3 types of queries handled by this message: 1) a specific Invoice, 2) a specific Product/Service Group or 3) a specific Product/Service Line Item. If a Provider wants to obtain information on a group of invoices (e.g., submitted in a date range), each individual Invoice must be queried.

This message may also be used to query an Invoice submitted at another Network Application ID and Network Facility ID, as long as sufficient identification information is provided to qualify the request and requestor. These are noted as Processing Rules for this message.

Note that the response to this query has the same content as an EHC^E10 – Edit/Adjudication Results message.

Processing Rules:

1. The Provider Application and the Payer Application must uniquely identify each Invoice, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Invoice, group or line item between the Provider Application and Payer Application.

2. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

3. A unique query identifier (Query Tag on QPD) must be generated for each query.
   Provider Invoice Number + Payer Invoice Number + Product/Service Line Item Number on input message must exist on Payer Application's database and must point to the same Product/Service Line Item, otherwise an error must be generated (mismatched Invoice and/or Product/Service Line Item).

4. To query an Invoice, the following fields must be supplied and must match the original Invoice submitted:
   QPD.Sending Organization
   QPD.Provider Organization
   QPD.Invoice Amount
   QPD.Provider Invoice Number
   QPD.Payer Invoice Number
   QPD.Payee Identification List

5. To query a Product/Service Group within an Invoice, the following fields must be supplied and must match the original Invoice submitted:
   QPD.Sending Organization
   QPD.Provider Organization
   QPD.Invoice Amount
   QPD.Provider Invoice Number
   QPD.Payer Invoice Number
   QPD.Payee Identification List
   QPD.Provider Product/Service Group Number
   QPD.Payer Product/Service Group Number

6. To query a Product/Service Line Item within an Invoice, the following fields must be supplied and must match the original Invoice submitted:
   QPD.Sending Organization
   QPD.Provider Organization
   QPD.Invoice Amount
   QPD.Provider Invoice Number
   QPD.Payer Invoice Number
   QPD.Payee Identification List
   QPD.Provider Product/Service Group Number
   QPD.Payer Product/Service Group Number
   QPD.Provider Product/Service Line Item Number
   QPD.Payer Product/Service Line Item Number

RSP^E03 – HealthCare Services Invoice Status Query Response (event E03)

This message is used to respond to a QPB^E03 – Query HealthCare Services Invoice. It provides Invoice and invoice processing information to a Provider.

A QBP^E03 – Query HealthCare Services Invoice can be used to query against an Invoice or a specific Product/Service Line Item in an Invoice. The same response message, RSP^E03 – HealthCare Services Invoice Query Response, is used for both types of query.

Processing Rules:

1. Provider Invoice Number + Payer Invoice Number + Product/Service Line Item Number on input message must exist on Payer Application's database and must point to the same Product/Service Line Item, otherwise an error must be generated (mismatched Invoice and/or Product/Service Line Item).

2. Sending Organization and Sending Application on input message must be the same as the Sending Organization and Sending Application from the original Invoice (submitted via the EHC^E01 – Submit HealthCare Services Invoice message) for the specified Invoice being queried.

3. A unique query identifier (Query Tag on QPD) must be generated for each query.

EHC^E04 – Re-Assess HealthCare Services Invoice Request (event E04)

This message is used to submit a single Re-Assess HealthCare Services Invoice Request to a TPA/Payer for processing. The Re-Assess HealthCare Services Invoice Request is used by a Provider, to request review of a previously adjudicated HealthCare Services Invoice, with optional specification of a Product/Service Line Item within that Invoice. Note that the HealthCare Services Invoice need not necessarily be sent to a TPA/Payer using the EHC^E01 – Submit HealthCare Services Invoice: it may be manually submitted.

Adjudication for a HealthCare Services Invoice may be re-assessed either because background information, such as a Provider's billing rate may have changed or if some of the adjudication rules have changed since original adjudication of the Invoice.

This message cannot be used to change or delete information from the HealthCare Services Invoice. The only information allowed in this message are Provider Invoice Number and Payer Invoice Number, and optional notes to assist in the re-assessment by the TPA/Payer.

Processing Rules:

1. The Provider Application and the Payer Application must uniquely identify each Invoice, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Invoice, group or line item between the Provider Application and Payer Application.

2. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

EHC^E10 – Edit/Adjudication Results (event E10)

This message is used to send edit and/or adjudication results for a HealthCare Services Invoice. Edit/Adjudication results are sent to the same Network Application ID that originated the Invoice, which was specified as the Sending Application on MSH on the original HealthCare Services Invoice.

This message is returned to a Provider Application each time an EHC^E01 – Submit HealthCare Services Invoice message is successfully processed by a Payer Application. As a minimum, the EHC^E10 – Edit/Adjudication Results message will contain the Payer Applications' Invoice number (Payer Invoice Number on IVC), status codes for each Product/Service Line Item in the Invoice and optionally, a tracking number for the Payer Application (Payer Tracking Number on PSL).

Note that an EHC^E12 – Request Additional Information (pending) is a valid response for an EHC^E01 – Submit HealthCare Services Invoice. In this case, the interactions would be EHC^E01 -> EHC^E12 (pending). If the Payer Application is able to process the Invoice on-line, the EHC^E10 – Edit/Adjudication Results message will contain the Invoice Processing Results portion completely filled out, indicating the results of the adjudication (e.g., paid as submitted, paid partial, etc.).

Processing Rules:

1. The Provider Application and the Payer Application must uniquely identify each Invoice, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Invoice, group or line item between the Provider Application and Payer Application.

2. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

3. The EHC^E10 – Edit/Adjudication Results message must only report against one HealthCare Services Invoice within a message. In other words, each IPR in this message must have the same Provider Invoice Number on IVC and the same Payer Invoice Number for all repetitions of the IVC segment in this message.

4. The Provider Invoice Number on IVC must be the same as the Provider Invoice Number on IVC as specified on the EHC^E01 input message. In other words, this message must be used to respond to the incoming EHC^E01 and not a previous EHC^E01 HealthCare Services Invoice. Only IPRs for the Invoice specified on the EHC^E01 may be included in the EHC^E10 response.

EHC^E12 – Request Additional Information (event E12)

A Payer or TPA uses this message to request additional information in support of an Invoice or a (Pre) Authorization Request. Normally, this request would be sent following receipt of an E01 or E20 message. However, it can also be sent following receipt of an E04 Re-Assess HealthCare Services Invoice Request. In this latter case the request for additional information still has as its object the original invoice (which is now under review) rather than the Re-assessment request per se.

The E12 can only be used to initiate a request for information and cannot be used to modify, place on hold or cancel an earlier request. This message cannot be used to convey information on the status of a claim and/or adjudication results (i.e., cannot be used in place of an E10 Edit/Adjudication Results message).

The scope of the request for additional information is defined through the inclusion of contextual data from the original Invoice or (Pre) Authorization Request. By specifying a particular Product/Service Group, patient and/or Product/Service Line item the requested information (e.g., a discharge narrative) is deemed to apply to those particular service events and not to any others which may have been part of the original Invoice or (Pre) Authorization Request.

In terms of absolute limits the E12 request is restricted to a single Product/Service Group from the original Invoice or (Pre) Authorization Request. Thereafter, the context can be more narrowly defined by inclusion of patient and/or Product/Service Line item information from within the same Product/Service Group. Thus, if a particular P/S Line Item is included, the message recipient must interpret this to mean that the request is related to that one line item. If the P/S Line Item is excluded the request is related to any and all line items in the original Product/Service Group. Similarly for patients: identification of a particular patient restricts the request to that patient alone, whereas omission of patient information means that the request applies to any and all patients identified in the original Product/Service Group.

The E12 message is restricted to zero or one patients and to zero or one Product/Service Line items. One consequence of these limits is that a Payer requiring information about a variety of patients or products/services from an original invoice may have to generate multiple (E12) requests.

The E12 message requires the use of LOINC classification standard to describe the information being requested (as do the E13/14 response messages). The codified request can also be supplemented by free-form text if greater specificity is required.

This message supports the use of pre-defined responses. That is, the sender specifies both the request as well as a range of possible answers for the recipient to choose from. This is an optional usage that is designed for real-time environments in which the Payer employs an adjudication engine to both solicit the additional information and manage the responses.

Processing Rules:

1. The Payer application must have already received an Invoice, (Pre) Authorization Request or Re-assessment request before a Request for Additional Information can be issued.

2. The Payer Application must uniquely identify each request. The Payer Application specifies its unique Request number as the Placer Order Number in the OBR segment. The number is comprised of the Payer Application's NAID + a unique sequence number.

3. Interpretative Rule: Patient Consent. If Patient Consent in the RFI segment is marked "Y" (Yes) the Payer is signifying possession of proof of patient consent for release of confidential information.

4. This request message is restricted to zero or one patients. If information is required for multiple patients in an original invoice or (pre) authorization request, a separate message is required for each individual.

5. Interpretative Rule: If the optional PID segment is omitted, the receiving system will interpret this to mean that the information request applies to any and all patients associated with the Product/Service Group in the original Invoice or (Pre) Authorization request. (See E01 message for rules governing the construction of Product/Service Groups.)

6. The Provider Organization, as identified in the IVC segment is normally responsible for responding to the request for additional information. However, the sender may identify an alternate individual or department as responsible for responding to the Request for Additional Information using the CTD segment of the Information Request. In such a case the Kept for backwards compatibility only. PRT and ROL should not both be used. field must be set to "FL" = Filler.

7. All data supplied in the IVC, PSG, and PID segments must be identical to that in the original invoice or (pre) authorization request.

8. With the exception of "Payer Tracking Number" and "Product/Service Line Item Status" all data supplied in the PSL segment must be identical to that in the original invoice or (pre) authorization request.

9. Interpretive Rule: Inclusion of Product/Service Line item information implies that the request is directly related to the Product/Service described in PSL. Omitting this optional segment implies that the request is related to all product/service line items in the original Product/Service Group. (See E01 message for rules governing the construction of Product/Service Groups.)

EHC^E13 – Additional Information Response (event E13)

This message is used by a Provider to immediately respond to an EHC^E12 Request for Additional Information, in other words an automated response. The EHC^E13 message cannot be sent unsolicited.

The EHC^E13 message supports three types of response modalities:

• Free-form ASCII text. This is generally brief, descriptive text that is formulated to be read by a human recipient.

• Attachments. The primary content is a multimedia attachment containing the information that has been requested. Depending upon agreements between the Provider and Payer this attachment may contain human-readable information, codified data that can be manipulated by an application, or some combination of the two.

• Pre-defined responses. The Payer has posed both a question and a range of possible answers that the responder chooses from when formulating the reply. The question and answers are codified so that they can be manipulated by an application.

The structure of the EHC^E13 message closely follows that of the EHC^E12 request, which in turn is patterned on the Invoice or (Pre) Authorization which preceded the request for additional information. The hierarchical structural of the message indicates the context of the request for additional information and the data being supplied in the response. More specifically, the EHC^E12 request is formulated against a particular Product/Service Group (from the earlier Invoice or (Pre) Authorization Request) and may be further circumscribed by reference to a particular patient and/or Product/Service Line Item from within that Product/Service Group. The parameters set by the EHC^E12 request are re-iterated in the EHC^E13 response message so that the receiving system can interpret the return data in the appropriate context without necessarily having to refer to the original Invoice or (Pre) Authorization request.

Parties to the Request for Additional Information and the Response:

• The individual or organization that initiates the request for additional information is described as the "Placer". (Normally, this would be the individual in the Payer organization that has placed the Invoice or (Pre) Authorization Request in suspense pending the return of the additional information that is being requested.)

• The individual or organization that is responsible for the information being sent in reply is described as the "Filler". (Normally, the Primary Care Provider would be responsible for supplying the requested information however, in some cases the Payer and/or Provider may stipulate some other party as the Filler.)

• The individual or organization that the response is to be directed to is described as the "Payer Contact".

The EHC^E13 message uses the LOINC classification standard to describe the information being sent. Local codes are also supported. The message allows the use of free-form text to supplement the coding schemes if greater specificity is required.

The EHC^E13 message supports the use of attachments. All attachments must follow the HL7 Claim Attachments implementation guide for additional information to support a healthcare claim or encounter standard that is described in Health Level Seven (HL7) Version 2.4 Standard; Implementation Guide: "Additional information message implementation guide, HL7 version 2.4 Standard, Release 1.0, NPRM Draft, December 11, 2001".

The EHC^E13 message supports the inclusion of multiple attachments, i.e., multiple instances of the ESDA, through repetition of the OBX segment. However, this use is NOT recommended. The ESDA specification permits multiple objects (documents, images etc.) to be imbedded in the attachment, so, when responding to a single OBR, a single OBX (with attached multi-part ESDA) should be the preferred method of returning the additional information.

Processing Rules:

1. The Provider Application must uniquely identify each request. The Provider Application specifies its unique Request number as the Filler Order Number in the OBR segment. The number itself is comprised of the Provider Application's NAID + a unique sequence number.

2. The Person or organization supplying the additional information is described as the "Filler" and must be identified in the CTD segment of the Information Request. When another party is responsible for producing a particular piece of data (e.g., an external laboratory) that Person or organization is described in the OBX fields: "Producer's ID" and/or "Responsible Observer".
   Usage: The Producer's ID field can be used to identify an external agency or organization that is responsible for the observation, e.g., a laboratory. The Responsible Observer field is used to describe the individual who either performed or verified the observation.
   If these fields are null the receiving system assumes that the Filler produced the results.

3. All data supplied in the IVC, PSG, PID and PSL segments must be identical to that in the EHC^E12 Request message.

4. Interpretive Rule: the presence of the PSL segment in the message indicates that the information supplied in the response message is directly related to the Product/Service described in the PSL segment.

5. Interpretive Rule: the presence of the PID segment in the message indicates that the information supplied in the response message is directly related to the Patient described in the PID segment.

6. If the Placer has supplied a set of pre-defined responses (i.e., the EHC^E12 message contains one or more OBX segments) then Observe Results Status must be completed. Valid value is "F" - Final value (an Affirmative response). Only OBX segments containing an Observe Results Status = "F" are included in the message.

7. When attaching multimedia documents: OBX.2 is set to "ED", the mime-encoded document (per ESDA specification) is inserted in OBX.5 and the TXA segment must be completed. The Unique Document Identifier in TXA must be identical to the Health Document Reference Identifier in the ESDA header.

8. Informative Rule: Document Confidentiality Status on TXA. When this optional field is completed it indicates that the Payer is to restrict access to the attached document according to the Payer's established policies and/or in accordance with prior business agreements between the Provider and Payer.

EHC^E15 – Payment/Remittance Advice (event E15)

This message is used to send a payment/ remittance advice to a Payee for the payment of HealthCare Services Invoices and/or other adjustments. The Payment/Remittance Advice can be sent to the originating Provider Application (Network Application ID) or alternately to the Payee's Network Application ID, depending on how the Payee has been configured by the Payer. If a Payment/Remittance Advice is paid by check, it typically has a 1 to 1 correspondence with a check number. However, there are occasions when one check number covers multiple Payment/Remittance Advices. This message does not enforce a 1 to 1 relationship between check number and Payment/Remittance Advice. That is, the same check number (Check Number on PMT) can be used on multiple Payment/Remittance Advices.

A Payment/Remittance Advice may not be generated if a Payee is a Person and not an organization (Payee Type on PYE = "PERS" or "PPER").

Once an EHC^E15 message is prepared (which may be on a regular basis such as monthly or bi-weekly), it is either sent to the Provider Application (if the Provider Application is able to receive unsolicited results) or stored on a queue for the Provider Application. If left on a queue for the Provider Application, then the QBP^E99 message must be used by the Provider Application to poll the Payer Application for the EHC^E15.

Processing Rules:

1. The Provider Application and the Payer Application must uniquely identify each Invoice, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Invoice, group or line item between the Provider Application and Payer Application.

2. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

3. The Payer Application must uniquely identify each Payment/Remittance Advice. The unique Payment/Remittance Advice identifier must be specified as Payment/Remittance Advice Number on PMT.

4. At least one of Payment/Remittance Detail Information or Adjustment(s) to Payee block must be specified with this message (see EHC^E15 – Message Summary for details) to describe the details of the Payment/Remittance Advice.

5. The Payment/Remittance Amount on PMT must equal to the sum of all Adjudicated/Paid Amount for all IPR segments PLUS the sum of all Adjudication/Paid Amounts for all ADJ segments in the Payment/Remittance Advice, excluding information adjustment types (Adjustment Category on ADJ = "IN").

EHC^E20 – Submit Authorization Request (event E20)

This message is used to submit a single Authorization Request to a TPA/Payer for authorization (for payment). An Authorization Request is made for one or more patients and may include 1 or more Product/Service Line Items (detail lines), each of which represents a specific, billable item or Payer allowed Treatment Plan.

If the Authorization is approved, then the Payer Application will return either an Authorization Number (Authorization Identifier on AUT) or individual who has authorized the Authorization Request (Name of Authorizer on AUT). The Authorization Number is not the same number as the Authorization Request Number; the latter indicates the number used to identify the request for authorization. The presence of the AUT segment in the EHC^E24 – Authorization Request Response message implies authorization. However, the Authorization may be restricted, which is described as Payer Adjustments.

This message can be used to submit an Authorization Request or to resubmit an Authorization Request (in case it was not properly acknowledged the first time that it was submitted). This message cannot be used to update an Authorization Request (e.g., add or cancel Product/Service Line Items) or cancel an Authorization Request. To cancel an Authorization Request, use the EHC^E21 – Cancel Authorization Request message. To update an Authorization it must first be cancelled (see EHC^E21 – Cancel Authorization Request) and then re–submitted using this message with new Provider control numbers.

Processing Rules:

1. The Provider Application and the Payer Application must uniquely identify each Authorization Request, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Authorization Request, group or line item between the Provider Application and Payer Application.

2. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   If the Authorization Request is successfully accepted by the Payer Application, the Provider Application must store up to 2 tracking numbers for each Product/Service Line Item, if present in the message pair. The Payer Application must also store up to 2 tracking numbers for each Product/Service Line Item, if present in the message pair.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

3. This message can contain only one Authorization Request, directed to a single Payer Organization, with multiple patients and multiple insurance policies for each patient. If there are multiple insurance policies and/or Payers identified for authorization, the EHC^E20 – Submit Authorization Request message must be sent to each TPA/Payer.

4. Location Identification information, defined by the LOC segment, may be specified with the Authorization Request (header) or Product/Service Line Item.
   If specified with the Authorization Request (header), then the Location Identification information acts as a default for all Product/Service Line Items in the Authorization Request.
   If specified with the Product/Service Line Item, then the Location Identification information supersedes (replaces) any defaults set by specifying Location Identification information with the Authorization Request (header).

5. Some Payers require Provider information to be included with an Authorization Request, which is defined by the ROL segment. In these situations, the ROL segment may be specified with the Authorization Request (header) and/or Product/Service Line Item.
   If specified with the Authorization Request (header), then the Provider Information acts as a default for all Product/Service Line Items in the Authorization Request.
   If specified with the Product/Service Line Item, then the Provider Information supersedes (replaces) any defaults set by specifying Provider information with the Authorization Request (header).
   Provider Information, if required by the Payer, must be specified with the Product/Service Line Item if it has not been defaulted for the Authorization Request (header).

6. Product/Service Clarification Codes: Each Product/Service Line Item allows a number of clarification codes to be specified. These are specified as 2 fields: Product/Service Clarification Code Type and Product/Service Clarification Code Value. Both of these fields repeat within the PSL segment and must repeat the same number of times. For example, if 2 clarification codes are specified, then 2 repetitions of each field is required, the first repetition corresponding to the 1st clarification code, the second repetition corresponding to the 2nd clarification code.

EHC^E21 – Cancel Authorization Request (event E21)

This message is used to cancel an Authorization Request, as a result of a previously submitted EHC^E20 – Submit Authorization Request message.

This message can be used to cancel the entire Authorization Request, or an individual Product/Service Line Item within an Authorization Request.

This message cannot be used to update ancillary information in an Authorization that has been submitted to a Payer. The original request must be cancelled, and a new Authorization Request submitted to the Payer.

Processing Rules:

1. The Provider Application and the Payer Application must uniquely identify each Authorization Request, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Authorization Request, group or line item between the Provider Application and Payer Application.

2. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

3. An Authorization Request can be cancelled regardless of its status with the Payer (i.e., whether approved, denied, pending or status unknown).

4. At least one NTE segment must be included with this message to describe the cancellation reason for each Product/Service Line Item. The NTE segment may be specified with the (Pr) Authorization Request (following the IVC segment) and applies to all Product/Service Line Items for that Authorization Request. If not specified with the Invoice, then it must be specified for each Product/Service Line Item (following the PSL segment).

5. Sending Organization and Sending Application on input message must be the same as the Sending Organization and Sending Application from the original request (submitted via the EHC^E20 – Submit Authorization Request message).

6. Provider reference numbers must exist on Payer Application's database and must point to the same Invoice, Product/Service Group or Product/Service Line Item; otherwise, an error must be generated (mismatched Invoice and/or Product/Service Line Item).

QBP^E22 – Query Authorization Request Status (event E22)

This message is used to query the status of an Authorization Request. There are 2 types of queries handled by this message: 1) a specific Authorization Request or 2) a specific Product/Service Line Item. If a Provider wants to obtain information on a group of Authorization Requests (e.g., submitted in a date range), each individual Authorization Request must be queried.

Note: The response to this query has the same content as an EHC^E24 – Authorization Response message.

Processing Rules:

1. The Provider Application and the Payer Application must uniquely identify each Authorization Request, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Authorization Request, group or line item between the Provider Application and Payer Application.

2. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

3. A unique query identifier (Query Tag on QPD) must be generated for each query.

4. Selection criteria for one of the 2 supported methods must be entered as below:

Query for a specific Authorization Request:

• Sending Application on MSH.

• Sending Organization from original Authorization Request (Sending Organization on QPD).

• Provider Organization from original Authorization Request (Provider Organization on QPD).

• Payer Organization from original Authorization Request (Payer Organization on QPD).

• Provider Invoice Number on QPD.

• Payer Invoice Number on QPD.

Query for a specific Product/Service Line Item - same as Query for a specific Authorization Request PLUS:

• Product/Service Line Item (Product/Service Line Item Number on QPD).

• Sending Organization and Sending Application on input message must be the same as the Sending Organization and Sending Application from the original Authorization Request (submitted via the EHC^E20 – Submit Authorization Request message).

• Provider Invoice Number + Payer Invoice Number + Product/Service Line Item Number on input message must exist on Payer Application's database and must point to the same Product/Service Line Item, otherwise an error must be generated (mismatched Authorization Request and/or Product/Service Line Item).

RSP^E22 – Authorization Request Status Query Response (event E22)

This message is used to respond to a QPB^E22 – Query Authorization Request Status. It provides Authorization status information to a Provider.

A QBP^E22 – Query Authorization Request Status can be used to query against a Authorization Request or a specific Product/Service Line Item in a Authorization Request. The same response message, RSP^E22 – Authorization Request Query Response, is used for both types of query.

Processing Rules:

1. Provider Invoice Number + Payer Invoice Number + Product/Service Line Item Number on input message must exist on Payer Application's database and must point to the same Product/Service Line Item; otherwise, an error must be generated (mismatched Authorization Request and/or Product/Service Line Item).

2. Sending Organization and Sending Application on input message must be the same as the Sending Organization and Sending Application from the original Authorization Request (submitted via the EHC^E20 – Submit Authorization Request message) for the specified Authorization Request being queried.

3. A unique query identifier (Query Tag on QPD) must be generated for each query.

EHC^E24 – Authorization Response (event E24)

This message is used to send results of an Authorization Request to a Provider Application. Authorization results are sent to the same Network Application ID that originated the Authorization Request, which was specified as the Sending Application on MSH on the original Authorization Request.

If the Payer Application is able to process the Authorization Request on-line, the EHC^E24 – Authorization Response message will contain the results of the authorization (e.g., approved, not approved).

If the Payer Application is not able to process the Authorization Request on-line, it creates an EHC^E24 – Authorization Response message once it has processed the Authorization Request (which may be the next day following receipt of the EHC^E20). Once prepared, the EHC^E24 is either sent to the Provider Application (if the Provider Application is able to receive unsolicited results) or stored on a queue for the Provider Application. If left on a queue for the Provider Application, then the QBP^E99 message must be used by the Provider Application to poll the Payer Application for the EHC^E24. If the Authorization is approved, then the Payer Application will return either an Authorization Number (Authorization Identifier on AUT) or individual who has authorized the Authorization Request (Name of Authorizer on AUT). The presence of the AUT segment in the EHC^E24 – Authorization Request Response message implies authorization has been granted. However, the Authorization may be restricted. Restrictions are specified under Payer Adjustments.

Processing Rules:

1. The Provider Application and the Payer Application must uniquely identify each Authorization Request, Product/Service Group, Product/Service Line Item and Adjustment.
   These numbers appear as a pair on the IVC, PSG, PSL and ADJ segments and must be echoed on any subsequent interactions for the Authorization Request, group or line item between the Provider Application and Payer Application.

2. The Provider Application and/or Payer Application may also supply a tracking number for each Product/Service Line Item it processes, specified as the Provider Tracking Number or Payer Tracking Number.
   The Provider Tracking Number and Payer Tracking Number must be echoed on any subsequent interactions for the Product/Service Line Item between the Provider Application and Payer Application.

3. The presence of the AUT segment in the EHC^E24 – Authorization Response message indicates the Payer's approval of the Authorization Request (with or without Payer Adjustments).

4. If the AUT segment is specified, then either the Authorization Identifier on AUT or Name of Authorizer on AUT must be specified.

5. The Provider Invoice Number on IVC must be the same as the Provider Invoice Number on IVC as specified on the EHC^E20 input message. In other words, this message must be used to respond to the incoming EHC^E20 and not a previous EHC^E20 Authorization Request.

EHC^E30 – Submit Health Document related to Authorization Request (event E30)

Not yet defined.

EHC^E31 – Cancel Health Document related to Authorization Request (event E31)

Not yet defined.

RFI - Request For Information Segment

RFI-1: Request Date (DTM) 01910

RFI-2: Response Due Date (DTM) 01911

RFI-3: Patient Consent (ID) 01912

RFI-4: Date Additional Information Was Submitted (DTM) 01913

IVC - Invoice Segment

IVC-1: Provider Invoice Number (EI) 01914

IVC-2: Payer Invoice Number (EI) 01915

IVC-3: Contract/Agreement Number (EI) 01916

IVC-4: Invoice Control (CWE) 01917

IVC-5: Invoice Reason (CWE) 01918

IVC-6: Invoice Type (CWE) 01919

IVC-7: Invoice Date/Time (DTM) 01920

IVC-8: Invoice Amount (CP) 01921

IVC-9: Payment Terms (ST) 01922

IVC-10: Provider Organization (XON) 01923

IVC-11: Payer Organization (XON) 01924

IVC-12: Attention (XCN) 01925

IVC-13: Last Invoice Indicator (ID) 01926

IVC-14: Invoice Booking Period (DTM) 01927

IVC-15: Origin (ST) 01928

IVC-16: Invoice Fixed Amount (CP) 01929

IVC-17: Special Costs (CP) 01930

IVC-18: Amount for Doctors Treatment (CP) 01931

IVC-19: Responsible Physician (XCN) 01932

IVC-20: Cost Center (CX) 01933

IVC-21: Invoice Prepaid Amount (CP) 01934

IVC-22: Total Invoice Amount without Prepaid Amount (CP) 01935

IVC-23: Total-Amount of VAT (CP) 01936

IVC-24: VAT-Rates applied (NM) 01937

IVC-25: Benefit Group (CWE) 01938

IVC-26: Provider Tax ID (ST) 02038

IVC-27: Payer Tax ID (ST) 02039

IVC-28: Provider Tax Status (CWE) 02040

IVC-29: Payer Tax Status (CWE) 02041

IVC-30: Sales Tax ID (ST) 02042

PYE - Payee Information Segment

PYE-1: Set ID – PYE (SI) 01939

PYE-2: Payee Type (CWE) 01940

PYE-3: Payee Relationship to Invoice (CWE) 01941

PYE-4: Payee Identification List (XON) 01942

PYE-5: Payee Person Name (XPN) 01943

PYE-6: Payee Address (XAD) 01944

PYE-7: Payment Method (CWE) 01945

PSS - Product/Service Section Segment

PSS-1: Provider Product/Service Section Number (EI) 01946

PSS-2: Payer Product/Service Section Number (EI) 01947

PSS-3: Product/Service Section Sequence Number (SI) 01948

PSS-4: Billed Amount (CP) 01949

PSS-5: Section Description or Heading (ST) 02043

PSG - Product/Service Group Segment

PSG-1: Provider Product/Service Group Number (EI) 01950

PSG-2: Payer Product/Service Group Number (EI) 01951

PSG-3: Product/Service Group Sequence Number (SI) 01952

PSG-4: Adjudicate as Group (ID) 01953

PSG-5: Product/Service Group Billed Amount (CP) 01954

PSG-6: Product/Service Group Description (ST) 02044

PSL - Product/Service Line Item Segment

PSL-1: Provider Product/Service Line Item Number (EI) 01955

PSL-2: Payer Product/Service Line Item Number (EI) 01956

PSL-3: Product/Service Line Item Sequence Number (SI) 01957

PSL-4: Provider Tracking ID (EI) 01958

PSL-5: Payer Tracking ID (EI) 01959

PSL-6: Product/Service Line Item Status (CWE) 01960

PSL-7: Product/Service Code (CWE) 01961

PSL-8: Product/Service Code Modifier (CWE) 01962

PSL-9: Product/Service Code Description (ST) 01963

PSL-10: Product/Service Effective Date (DTM) 01964

PSL-11: Product/Service Expiration Date (DTM) 01965

PSL-12: Product/Service Quantity (CQ) 01966

PSL-13: Product/Service Unit Cost (CP) 01967

PSL-14: Number of Items per Unit (NM) 01968

PSL-15: Product/Service Gross Amount (CP) 01969

PSL-16: Product/Service Billed Amount (CP) 01970

PSL-17: Product/Service Clarification Code Type (CWE) 01971

PSL-18: Product/Service Clarification Code Value (ST) 01972

PSL-19: Health Document Reference Identifier (EI) 01973

PSL-20: Processing Consideration Code (CWE) 01974

PSL-21: Restricted Disclosure Indicator (ID) 01975

PSL-22: Related Product/Service Code Indicator (CWE) 01976

PSL-23: Product/Service Amount for Physician (CP) 01977

PSL-24: Product/Service Cost Factor (NM) 01978

PSL-25: Cost Center (CX) 01933

PSL-26: Billing Period (DR) 01980

PSL-27: Days without Billing (NM) 01981

PSL-28: Session-No (NM) 01982

PSL-29: Executing Physician ID (XCN) 01983

PSL-30: Responsible Physician ID (XCN) 01984

PSL-31: Role Executing Physician (CWE) 01985

PSL-32: Medical Role Executing Physician (CWE) 01986

PSL-33: Side of body (CWE) 01987

PSL-34: Number of TP's PP (NM) 01988

PSL-35: TP-Value PP (CP) 01989

PSL-36: Internal Scaling Factor PP (NM) 01990

PSL-37: External Scaling Factor PP (NM) 01991

PSL-38: Amount PP (CP) 01992

PSL-39: Number of TP's Technical Part (NM) 01993

PSL-40: TP-Value Technical Part (CP) 01994

PSL-41: Internal Scaling Factor Technical Part (NM) 01995

PSL-42: External Scaling Factor Technical Part (NM) 01996

PSL-43: Amount Technical Part (CP) 01997

PSL-44: Total Amount Professional Part + Technical Part (CP) 01998

PSL-45: VAT-Rate (NM) 01999

PSL-46: Main-Service (ID) 02000

PSL-47: Validation (ID) 02001

PSL-48: Comment (ST) 02002

ADJ - Adjustment Segment

ADJ-1: Provider Adjustment Number (EI) 02003

ADJ-2: Payer Adjustment Number (EI) 02004

ADJ-3: Adjustment Sequence Number (SI) 02005

ADJ-4: Adjustment Category (CWE) 02006

ADJ-5: Adjustment Amount (CP) 02007

ADJ-6: Adjustment Quantity (CQ) 02008

ADJ-7: Adjustment Reason PA (CWE) 02009

ADJ-8: Adjustment Description (ST) 02010

ADJ-9: Original Value (NM) 02011

ADJ-10: Substitute Value (NM) 02012

ADJ-11: Adjustment Action (CWE) 02013

ADJ-12: Provider Adjustment Number Cross Reference (EI) 02014

ADJ-13: Provider Product/Service Line Item Number Cross Reference (EI) 02015

ADJ-14: Adjustment Date (DTM) 02016

ADJ-15: Responsible Organization (XON) 02017

PMT - Payment Information Segment

PMT-1: Payment/Remittance Advice Number (EI) 02018

PMT-2: Payment/Remittance Effective Date/Time (DTM) 02019

PMT-3: Payment/Remittance Expiration Date/Time (DTM) 02020

PMT-4: Payment Method (CWE) 02021

PMT-5: Payment/Remittance Date/Time (DTM) 02022

PMT-6: Payment/Remittance Amount (CP) 02023

PMT-7: Check Number (EI) 02024

PMT-8: Payee Bank Identification (XON) 02025

PMT-9: Payee Transit Number (ST) 02026

PMT-10: Payee Bank Account ID (CX) 02027

PMT-11: Payment Organization (XON) 02028

PMT-12: ESR-Code-Line (ST) 02029

IPR - Invoice Processing Results Segment

IPR-1: IPR Identifier (EI) 02030

IPR-2: Provider Cross Reference Identifier (EI) 02031

IPR-3: Payer Cross Reference Identifier (EI) 02032

IPR-4: IPR Status (CWE) 02033

IPR-5: IPR Date/Time (DTM) 02034

IPR-6: Adjudicated/Paid Amount (CP) 02035

IPR-7: Expected Payment Date/Time (DTM) 02036

IPR-8: IPR Checksum (ST) 02037