HL7 - REFACTORED

Co Chair:	Kathleen Connor Book Zurman Incorporated
Co Chair	Mary Kay McDaniel Cognosante
Co Chair	Benoit Schoeffler almerys
Editor:	Beat Heggli HL7 Switzerland
Sponsoring TC	Financial Management
List Serve	fm@lists.hl7.org

Purpose

This document contains the HL7 messaging specifications to support Claims and Reimbursement (CR) for the electronic exchange of health invoice (claim) data. The document is intended for use by benefit group vendors, Third Party Administrators (TPA) and Payers who wish to develop software that is compliant with an international standard for the electronic exchange of claim data.

The content of this document is not intended to be an alternative to or replacement for those ASC X12 standards mandated for use in this domain in the United States

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.

Trigger Events and Message Definitions

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.

Processing Rules:

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).
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.
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.
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.
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.
If Authorization Information is entered (AUT segment), then either the Authorization Identifier on AUT or Name of Authorizer on AUT must be specified.
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.
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.
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.
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.
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).
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^E01^EHC_E01: Submit HealthCare Services Invoice

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E01
Segment	Cardinality	Must Implement	Status
EHC_E01
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
PRODUCT_SERVICE_SECTION	1..1	Yes	additional
PSS	1..1	Yes	additional
PRODUCT_SERVICE_GROUP	1..*	Yes	additional
PSG	1..1	Yes	additional
LOC	0..*		additional
PRT	0..*		additional
ROL	0..*		B
IPR	0..*		additional
PATIENT_INFO	0..*		additional
PID	1..1	Yes	additional
PRT	0..*		additional
PV1	0..1		additional
PV2	0..1		additional
ACC	0..*		additional
OBX	0..*		additional
PRT	0..*		additional
INSURANCE	1..*	Yes	additional
IN1	1..1	Yes	additional
IN2	0..1		additional
DIAGNOSIS	0..*		additional
DG1	1..1	Yes	additional
NTE	0..*		additional
PRODUCT_SERVICE_LINE_ITEM	1..*	Yes	additional
PSL	1..1	Yes	additional
NTE	0..*		additional
ADJ	0..*		additional
AUT	0..1		additional
LOC	0..*		additional
PRT	0..*		additional
ROL	0..*		B
PROCEDURE	0..*		additional
PR1	1..1	Yes	additional
NTE	0..*		additional
PRT	0..*		additional
ROL	0..*		B

Original Mode Acknowledgement Choreography for EHC^E01^EHC_E01

Send Application Ack: ACK^E01^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E01^EHC_E01

When the MSH-15 value of an EHC^E01^EHC_E01 message is AL or ER or SU, an ACK^E01^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E01^EHC_E01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E01^EHC_E01 message is AL or ER or SU, an ACK^E01^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E01^EHC_E01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E01^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E01^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E01-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E01 -->
  <!-- .. message definition EHC_E01 -->
  <xsd:complexType name="EHC_E01.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E01.INVOICE_INFORMATION_SUBMIT"
      minOccurs="1" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E01" type="EHC_E01.CONTENT" />
  <xsd:complexType name="EHC_E01.INVOICE_INFORMATION_SUBMIT.CONTENT">

    <xsd:choice>
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PYE" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="CTD" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="AUT" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="LOC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="PRT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="ROL" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E01.PRODUCT_SERVICE_SECTION"
      minOccurs="1" maxOccurs="unbounded" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="EHC_E01.INVOICE_INFORMATION_SUBMIT"
  type="EHC_E01.INVOICE_INFORMATION_SUBMIT.CONTENT" />
  <xsd:complexType name="EHC_E01.PRODUCT_SERVICE_SECTION.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSS" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E01.PRODUCT_SERVICE_GROUP"
      minOccurs="1" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E01.PRODUCT_SERVICE_SECTION"
  type="EHC_E01.PRODUCT_SERVICE_SECTION.CONTENT" />
  <xsd:complexType name="EHC_E01.PRODUCT_SERVICE_GROUP.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSG" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="LOC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="PRT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="ROL" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E01.PATIENT_INFO" minOccurs="0"
      maxOccurs="unbounded" />
      <xsd:element ref="EHC_E01.PRODUCT_SERVICE_LINE_ITEM"
      minOccurs="1" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E01.PROCEDURE" minOccurs="0"
      maxOccurs="unbounded" />
      <xsd:element ref="IPR" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E01.PRODUCT_SERVICE_GROUP"
  type="EHC_E01.PRODUCT_SERVICE_GROUP.CONTENT" />
  <xsd:complexType name="EHC_E01.PATIENT_INFO.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PID" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PV1" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="PV2" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="ACC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E01.INSURANCE" minOccurs="1"
      maxOccurs="unbounded" />
      <xsd:element ref="EHC_E01.DIAGNOSIS" minOccurs="0"
      maxOccurs="unbounded" />
      <xsd:element ref="OBX" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E01.PATIENT_INFO"
  type="EHC_E01.PATIENT_INFO.CONTENT" />
  <xsd:complexType name="EHC_E01.INSURANCE.CONTENT">
    <xsd:sequence>
      <xsd:element ref="IN1" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="IN2" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E01.INSURANCE"
  type="EHC_E01.INSURANCE.CONTENT" />
  <xsd:complexType name="EHC_E01.DIAGNOSIS.CONTENT">
    <xsd:sequence>
      <xsd:element ref="DG1" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E01.DIAGNOSIS"
  type="EHC_E01.DIAGNOSIS.CONTENT" />
  <xsd:complexType name="EHC_E01.PRODUCT_SERVICE_LINE_ITEM.CONTENT">

    <xsd:sequence>
      <xsd:element ref="PSL" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="ADJ" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="AUT" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="LOC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="PRT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="ROL" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E01.PRODUCT_SERVICE_LINE_ITEM"
  type="EHC_E01.PRODUCT_SERVICE_LINE_ITEM.CONTENT" />
  <xsd:complexType name="EHC_E01.PROCEDURE.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PR1" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="PRT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="ROL" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E01.PROCEDURE"
  type="EHC_E01.PROCEDURE.CONTENT" />
</xsd:schema>

Download

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:

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 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.
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).
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.
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).
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.
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
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
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
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".

EHC^E02^EHC_E02: Cancel HealthCare Services Invoice

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E02
Segment	Cardinality	Must Implement	Status
EHC_E02
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
PRODUCT_SERVICE_SECTION	1..1	Yes	additional
PSS	1..1	Yes
PSG	0..*		additional
PSG	1..1	Yes	additional
PSL	0..*		additional

Original Mode Acknowledgement Choreography for EHC^E02^EHC_E02

Send Application Ack: ACK^E02^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E02^EHC_E02

When the MSH-15 value of an EHC^E02^EHC_E02 message is AL or ER or SU, an ACK^E02^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E02^EHC_E02 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E02^EHC_E02 message is AL or ER or SU, an ACK^E02^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E02^EHC_E02 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E02^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E02^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E02-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E02 -->
  <!-- .. message definition EHC_E02 -->
  <xsd:complexType name="EHC_E02.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E02.INVOICE_INFORMATION_CANCEL"
      minOccurs="1" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E02" type="EHC_E02.CONTENT" />
  <xsd:complexType name="EHC_E02.INVOICE_INFORMATION_CANCEL.CONTENT">

    <xsd:choice>
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PYE" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="CTD" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E02.PRODUCT_SERVICE_SECTION"
      minOccurs="0" maxOccurs="unbounded" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="EHC_E02.INVOICE_INFORMATION_CANCEL"
  type="EHC_E02.INVOICE_INFORMATION_CANCEL.CONTENT" />
  <xsd:complexType name="EHC_E02.PRODUCT_SERVICE_SECTION.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSS" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E02.PSG" minOccurs="0"
      maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E02.PRODUCT_SERVICE_SECTION"
  type="EHC_E02.PRODUCT_SERVICE_SECTION.CONTENT" />
  <xsd:complexType name="EHC_E02.PSG.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSG" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PSL" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E02.PSG" type="EHC_E02.PSG.CONTENT" />
</xsd:schema>

Download

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:

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 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.
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).
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
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
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

QBP^E03^QBP_E03: Query HealthCare Services Invoice

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - QBP_E03
Segment	Cardinality	Must Implement	Status
QBP_E03
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
	1..1	Yes	additional
QPD	1..1	Yes	additional

RCP	1..1	Yes	additional

Original Mode Acknowledgement Choreography for QBP^E03^QBP_E03

Send Application Ack: RSP^E03^RSP_E03

Enhanced Mode Acknowledgement Choreography for QBP^E03^QBP_E03

When the MSH-15 value of a QBP^E03^QBP_E03 message is AL or ER or SU, an ACK^E03^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^E03^QBP_E03 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^E03^QBP_E03 message is AL or ER or SU, a RSP^E03^RSP_E03 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^E03^QBP_E03 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E03^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: RSP^E03^RSP_E03
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: QBP_E03-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE QBP_E03 -->
  <!-- .. message definition QBP_E03 -->
  <xsd:complexType name="QBP_E03.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="QBP_E03.QUERY_INFORMATION" minOccurs="1"
      maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="QBP_E03" type="QBP_E03.CONTENT" />
  <xsd:complexType name="QBP_E03.QUERY_INFORMATION.CONTENT">
    <xsd:choice>
      <xsd:element ref="QPD" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="RCP" minOccurs="1" maxOccurs="1" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="QBP_E03.QUERY_INFORMATION"
  type="QBP_E03.QUERY_INFORMATION.CONTENT" />
</xsd:schema>

Download

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:

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).
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.
A unique query identifier (Query Tag on QPD) must be generated for each query.

RSP^E03^RSP_E03: HealthCare Services Invoice Query Response

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - RSP_E03
Segment	Cardinality	Must Implement	Status
RSP_E03
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
MSA	1..1	Yes	additional
ERR	0..*		additional
	1..1	Yes	additional
QAK	1..1	Yes	additional

QPD	1..1	Yes	additional

IPR	0..*		additional

Original Mode Acknowledgement Choreography for RSP^E03^RSP_E03

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RSP^E03^RSP_E03

When the MSH-15 value of a RSP^E03^RSP_E03 message is AL or ER or SU, an ACK^E03^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^E03^RSP_E03 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^E03^RSP_E03 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^E03^RSP_E03 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E03^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack:
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: RSP_E03-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE RSP_E03 -->
  <!-- .. message definition RSP_E03 -->
  <xsd:complexType name="RSP_E03.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="MSA" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="ERR" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="RSP_E03.QUERY_ACK_IPR" minOccurs="1"
      maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="RSP_E03" type="RSP_E03.CONTENT" />
  <xsd:complexType name="RSP_E03.QUERY_ACK_IPR.CONTENT">
    <xsd:choice>
      <xsd:element ref="QAK" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="QPD" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="IPR" minOccurs="0" maxOccurs="unbounded" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="RSP_E03.QUERY_ACK_IPR"
  type="RSP_E03.QUERY_ACK_IPR.CONTENT" />
</xsd:schema>

Download

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:

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 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^E04^EHC_E04: Re-Assess HealthCare Services Invoice Request

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E04
Segment	Cardinality	Must Implement	Status
EHC_E04
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
PRODUCT_SERVICE_SECTION	1..1	Yes	additional
PSS	1..1	Yes	additional
PRODUCT_SERVICE_GROUP	0..*		additional
PSG	1..1	Yes	additional
PSL	0..*		additional

Original Mode Acknowledgement Choreography for EHC^E04^EHC_E04

Send Application Ack: ACK^E04^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E04^EHC_E04

When the MSH-15 value of an EHC^E04^EHC_E04 message is AL or ER or SU, an ACK^E04^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E04^EHC_E04 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E04^EHC_E04 message is AL or ER or SU, an ACK^E04^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E04^EHC_E04 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E04^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E04^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E04-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E04 -->
  <!-- .. message definition EHC_E04 -->
  <xsd:complexType name="EHC_E04.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E04.REASSESSMENT_REQUEST_INFO"
      minOccurs="1" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E04" type="EHC_E04.CONTENT" />
  <xsd:complexType name="EHC_E04.REASSESSMENT_REQUEST_INFO.CONTENT">

    <xsd:choice>
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E04.PRODUCT_SERVICE_SECTION"
      minOccurs="0" maxOccurs="unbounded" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="EHC_E04.REASSESSMENT_REQUEST_INFO"
  type="EHC_E04.REASSESSMENT_REQUEST_INFO.CONTENT" />
  <xsd:complexType name="EHC_E04.PRODUCT_SERVICE_SECTION.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSS" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E04.PRODUCT_SERVICE_GROUP"
      minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E04.PRODUCT_SERVICE_SECTION"
  type="EHC_E04.PRODUCT_SERVICE_SECTION.CONTENT" />
  <xsd:complexType name="EHC_E04.PRODUCT_SERVICE_GROUP.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSG" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PSL" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E04.PRODUCT_SERVICE_GROUP"
  type="EHC_E04.PRODUCT_SERVICE_GROUP.CONTENT" />
</xsd:schema>

Download

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:

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 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.
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.
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^E10^EHC_E10: Edit/Adjudication Results

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E10
Segment	Cardinality	Must Implement	Status
EHC_E10
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
MSA	1..1	Yes	additional
ERR	0..*		additional
INVOICE_PROCESSING_RESULTS_INFO	1..*	Yes	additional
IPR	1..1	Yes	additional
NTE	0..*		additional
PYE	1..1	Yes	additional
IN1	1..1	Yes	additional
IN2	0..1		additional
IVC	1..1	Yes	additional
PRODUCT_SERVICE_LINE_INFO	1..*	Yes	additional
PSS	1..1	Yes	additional
PRODUCT_SERVICE_LINE_INFO	1..*	Yes	additional
PSG	1..1	Yes	additional
PRODUCT_SERVICE_LINE_INFO	1..*	Yes	additional
PSL	1..1	Yes	additional
ADJ	0..*		additional

Original Mode Acknowledgement Choreography for EHC^E10^EHC_E10

Send Application Ack: ACK^E10^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E10^EHC_E10

When the MSH-15 value of an EHC^E10^EHC_E10 message is AL or ER or SU, an ACK^E10^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E10^EHC_E10 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E10^EHC_E10 message is AL or ER or SU, an ACK^E10^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E10^EHC_E10 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E10^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E10^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E10-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E10 -->
  <!-- .. message definition EHC_E10 -->
  <xsd:complexType name="EHC_E10.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="MSA" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="ERR" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E10.INVOICE_PROCESSING_RESULTS_INFO"
      minOccurs="1" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E10" type="EHC_E10.CONTENT" />
  <xsd:complexType name="EHC_E10.INVOICE_PROCESSING_RESULTS_INFO.CONTENT">

    <xsd:sequence>
      <xsd:element ref="IPR" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="PYE" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="IN1" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="IN2" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E10.PRODUCT_SERVICE_SECTION"
      minOccurs="1" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E10.INVOICE_PROCESSING_RESULTS_INFO"
  type="EHC_E10.INVOICE_PROCESSING_RESULTS_INFO.CONTENT" />
  <xsd:complexType name="EHC_E10.PRODUCT_SERVICE_SECTION.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSS" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E10.PRODUCT_SERVICE_GROUP"
      minOccurs="1" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E10.PRODUCT_SERVICE_SECTION"
  type="EHC_E10.PRODUCT_SERVICE_SECTION.CONTENT" />
  <xsd:complexType name="EHC_E10.PRODUCT_SERVICE_GROUP.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSG" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E10.PRODUCT_SERVICE_LINE_INFO"
      minOccurs="1" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E10.PRODUCT_SERVICE_GROUP"
  type="EHC_E10.PRODUCT_SERVICE_GROUP.CONTENT" />
  <xsd:complexType name="EHC_E10.PRODUCT_SERVICE_LINE_INFO.CONTENT">

    <xsd:sequence>
      <xsd:element ref="PSL" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="ADJ" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E10.PRODUCT_SERVICE_LINE_INFO"
  type="EHC_E10.PRODUCT_SERVICE_LINE_INFO.CONTENT" />
</xsd:schema>

Download

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:

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.
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.
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.
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.
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.)
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.
All data supplied in the IVC, PSG, and PID segments must be identical to that in the original invoice or (pre) authorization request.
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.
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^E12^EHC_E12: Request Additional Information

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E12
Segment	Cardinality	Must Implement	Status
EHC_E12
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
RFI	1..1	Yes	additional
CTD	0..*		additional
IVC	1..1	Yes	Identifier
PSS	1..1	Yes	additional
PSG	1..1	Yes	additional
PID	0..1		additional
PRT	0..*		additional
PSL	0..*		additional
REQUEST	1..*	Yes	additional
CTD	0..1		additional
OBR	1..1	Yes	additional
PRT	0..*		additional
NTE	0..1		additional
OBX	0..*		additional
PRT	0..*		additional

Original Mode Acknowledgement Choreography for EHC^E12^EHC_E12

Send Application Ack: ACK^E12^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E12^EHC_E12

When the MSH-15 value of an EHC^E12^EHC_E12 message is AL or ER or SU, an ACK^E12^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E12^EHC_E12 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E12^EHC_E12 message is AL or ER or SU, an ACK^E12^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E12^EHC_E12 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E12^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E12^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E12-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E12 -->
  <!-- .. message definition EHC_E12 -->
  <xsd:complexType name="EHC_E12.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="RFI" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="CTD" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PSS" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PSG" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PID" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="PSL" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E12.REQUEST" minOccurs="1"
      maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E12" type="EHC_E12.CONTENT" />
  <xsd:complexType name="EHC_E12.REQUEST.CONTENT">
    <xsd:sequence>
      <xsd:element ref="CTD" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="OBR" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="OBX" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E12.REQUEST"
  type="EHC_E12.REQUEST.CONTENT" />
</xsd:schema>

Download

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:

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.
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.
All data supplied in the IVC, PSG, PID and PSL segments must be identical to that in the EHC^E12 Request message.
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.
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.
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.
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.
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^E13^EHC_E13: Additional Information Response

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E13
Segment	Cardinality	Must Implement	Status
EHC_E13
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
MSA	1..1	Yes	additional
ERR	0..*		additional
RFI	1..1	Yes	additional
CTD	0..*		additional
IVC	1..1	Yes	additional
PSS	1..1	Yes	additional
PSG	1..1	Yes	additional
PID	0..1		additional
PRT	0..*		additional
PSL	0..1		additional
REQUEST	1..*	Yes	additional
CTD	0..1		additional
OBR	1..1	Yes	additional
PRT	0..*		additional
NTE	0..1		additional
RESPONSE	1..*	Yes	additional
OBX	1..1	Yes	additional
PRT	0..*		additional
NTE	0..1		additional
TXA	0..1		additional

Original Mode Acknowledgement Choreography for EHC^E13^EHC_E13

Send Application Ack: ACK^E13^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E13^EHC_E13

When the MSH-15 value of an EHC^E13^EHC_E13 message is AL or ER or SU, an ACK^E13^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E13^EHC_E13 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E13^EHC_E13 message is AL or ER or SU, an ACK^E13^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E13^EHC_E13 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E13^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E13^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E13-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E13 -->
  <!-- .. message definition EHC_E13 -->
  <xsd:complexType name="EHC_E13.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="MSA" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="ERR" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="RFI" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="CTD" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PSS" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PSG" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PID" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="PSL" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="EHC_E13.REQUEST" minOccurs="1"
      maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E13" type="EHC_E13.CONTENT" />
  <xsd:complexType name="EHC_E13.REQUEST.CONTENT">
    <xsd:sequence>
      <xsd:element ref="CTD" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="OBR" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="EHC_E13.RESPONSE" minOccurs="1"
      maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E13.REQUEST"
  type="EHC_E13.REQUEST.CONTENT" />
  <xsd:complexType name="EHC_E13.RESPONSE.CONTENT">
    <xsd:sequence>
      <xsd:element ref="OBX" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="TXA" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E13.RESPONSE"
  type="EHC_E13.RESPONSE.CONTENT" />
</xsd:schema>

Download

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:

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 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.
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.
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.
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^E15^EHC_E15: Payment/Remittance Advice

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E15
Segment	Cardinality	Must Implement	Status
EHC_E15
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
	1..1	Yes	additional
PMT	1..1	Yes	additional

PYE	1..1	Yes	additional
PAYMENT_REMITTANCE_DETAIL_INFO	0..*		additional
IPR	1..1	Yes	additional
IVC	1..1	Yes	additional
PRODUCT_SERVICE_SECTION	1..*	Yes	additional
PSS	1..1	Yes	additional
PRODUCT_SERVICE_GROUP	1..*	Yes	additional
PSG	1..1	Yes	additional
PSL_ITEM_INFO	1..*	Yes	additional
PSL	1..1	Yes	additional
ADJ	0..*		additional
ADJUSTMENT_PAYEE	0..*		additional
ADJ	1..1	Yes	additional
PRT	0..1		additional
ROL	0..1		B

Original Mode Acknowledgement Choreography for EHC^E15^EHC_E15

Send Application Ack: ACK^E15^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E15^EHC_E15

When the MSH-15 value of an EHC^E15^EHC_E15 message is AL or ER or SU, an ACK^E15^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E15^EHC_E15 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E15^EHC_E15 message is AL or ER or SU, an ACK^E15^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E15^EHC_E15 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E15^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E15^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E15-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E15 -->
  <!-- .. message definition EHC_E15 -->
  <xsd:complexType name="EHC_E15.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E15.PAYMENT_REMITTANCE_HEADER_INFO"
      minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E15.PAYMENT_REMITTANCE_DETAIL_INFO"
      minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E15.ADJUSTMENT_PAYEE" minOccurs="0"
      maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E15" type="EHC_E15.CONTENT" />
  <xsd:complexType name="EHC_E15.PAYMENT_REMITTANCE_HEADER_INFO.CONTENT">

    <xsd:choice>
      <xsd:element ref="PMT" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PYE" minOccurs="1" maxOccurs="1" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="EHC_E15.PAYMENT_REMITTANCE_HEADER_INFO"
  type="EHC_E15.PAYMENT_REMITTANCE_HEADER_INFO.CONTENT" />
  <xsd:complexType name="EHC_E15.PAYMENT_REMITTANCE_DETAIL_INFO.CONTENT">

    <xsd:sequence>
      <xsd:element ref="IPR" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E15.PRODUCT_SERVICE_SECTION"
      minOccurs="1" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E15.PAYMENT_REMITTANCE_DETAIL_INFO"
  type="EHC_E15.PAYMENT_REMITTANCE_DETAIL_INFO.CONTENT" />
  <xsd:complexType name="EHC_E15.PRODUCT_SERVICE_SECTION.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSS" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E15.PRODUCT_SERVICE_GROUP"
      minOccurs="1" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E15.PRODUCT_SERVICE_SECTION"
  type="EHC_E15.PRODUCT_SERVICE_SECTION.CONTENT" />
  <xsd:complexType name="EHC_E15.PRODUCT_SERVICE_GROUP.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSG" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E15.PSL_ITEM_INFO" minOccurs="1"
      maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E15.PRODUCT_SERVICE_GROUP"
  type="EHC_E15.PRODUCT_SERVICE_GROUP.CONTENT" />
  <xsd:complexType name="EHC_E15.PSL_ITEM_INFO.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSL" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="ADJ" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E15.PSL_ITEM_INFO"
  type="EHC_E15.PSL_ITEM_INFO.CONTENT" />
  <xsd:complexType name="EHC_E15.ADJUSTMENT_PAYEE.CONTENT">
    <xsd:sequence>
      <xsd:element ref="ADJ" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PRT" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="ROL" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E15.ADJUSTMENT_PAYEE"
  type="EHC_E15.ADJUSTMENT_PAYEE.CONTENT" />
</xsd:schema>

Download

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:

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.
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.
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.
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).
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).
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^E20^EHC_E20: Submit Authorization Request

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E20
Segment	Cardinality	Must Implement	Status
EHC_E20
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
PAT_INFO	1..1	Yes	additional
PID	1..1	Yes	additional
PRT	0..*		additional
ACC	0..*		additional
OBX	0..*		additional
PRT	0..*		additional
INSURANCE	1..*	Yes	additional
IN1	1..1	Yes	additional
IN2	0..1		additional
DIAGNOSIS	0..1		additional
	1..*	Yes	additional
DG1	1..1	Yes	additional
NTE	0..*		additional

Original Mode Acknowledgement Choreography for EHC^E20^EHC_E20

Send Application Ack: ACK^E20^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E20^EHC_E20

When the MSH-15 value of an EHC^E20^EHC_E20 message is AL or ER or SU, an ACK^E20^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E20^EHC_E20 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E20^EHC_E20 message is AL or ER or SU, an ACK^E20^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E20^EHC_E20 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E20^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E20^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E20-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E20 -->
  <!-- .. message definition EHC_E20 -->
  <xsd:complexType name="EHC_E20.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E20.AUTHORIZATION_REQUEST"
      minOccurs="1" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E20" type="EHC_E20.CONTENT" />
  <xsd:complexType name="EHC_E20.AUTHORIZATION_REQUEST.CONTENT">
    <xsd:choice>
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="CTD" minOccurs="1" maxOccurs="unbounded" />
      <xsd:element ref="LOC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="ROL" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E20.PAT_INFO" minOccurs="1"
      maxOccurs="unbounded" />
      <xsd:element ref="EHC_E20.PSL_ITEM_INFO" minOccurs="1"
      maxOccurs="unbounded" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="EHC_E20.AUTHORIZATION_REQUEST"
  type="EHC_E20.AUTHORIZATION_REQUEST.CONTENT" />
  <xsd:complexType name="EHC_E20.PAT_INFO.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PID" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="ACC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E20.INSURANCE" minOccurs="1"
      maxOccurs="unbounded" />
      <xsd:element ref="EHC_E20.DIAGNOSIS" minOccurs="0"
      maxOccurs="unbounded" />
      <xsd:element ref="OBX" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E20.PAT_INFO"
  type="EHC_E20.PAT_INFO.CONTENT" />
  <xsd:complexType name="EHC_E20.INSURANCE.CONTENT">
    <xsd:sequence>
      <xsd:element ref="IN1" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="IN2" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E20.INSURANCE"
  type="EHC_E20.INSURANCE.CONTENT" />
  <xsd:complexType name="EHC_E20.DIAGNOSIS.CONTENT">
    <xsd:sequence>
      <xsd:element ref="DG1" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E20.DIAGNOSIS"
  type="EHC_E20.DIAGNOSIS.CONTENT" />
  <xsd:complexType name="EHC_E20.PSL_ITEM_INFO.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSL" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="ADJ" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="LOC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="PRT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="ROL" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E20.PSL_ITEM_INFO"
  type="EHC_E20.PSL_ITEM_INFO.CONTENT" />
</xsd:schema>

Download

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:

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.
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.
An Authorization Request can be cancelled regardless of its status with the Payer (i.e., whether approved, denied, pending or status unknown).
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).
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).
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).

EHC^E21^EHC_E21: Cancel Authorization Request

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E21
Segment	Cardinality	Must Implement	Status
EHC_E21
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
PSL_ITEM_INFO	1..1	Yes	additional
PSL	1..1	Yes	additional
NTE	0..*		additional
AUT	0..1		additional

Original Mode Acknowledgement Choreography for EHC^E21^EHC_E21

Send Application Ack: ACK^E21^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E21^EHC_E21

When the MSH-15 value of an EHC^E21^EHC_E21 message is AL or ER or SU, an ACK^E21^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E21^EHC_E21 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E21^EHC_E21 message is AL or ER or SU, an ACK^E21^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E21^EHC_E21 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E21^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E21^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E21-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E21 -->
  <!-- .. message definition EHC_E21 -->
  <xsd:complexType name="EHC_E21.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E21.AUTHORIZATION_REQUEST"
      minOccurs="1" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E21" type="EHC_E21.CONTENT" />
  <xsd:complexType name="EHC_E21.AUTHORIZATION_REQUEST.CONTENT">
    <xsd:choice>
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E21.PSL_ITEM_INFO" minOccurs="1"
      maxOccurs="unbounded" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="EHC_E21.AUTHORIZATION_REQUEST"
  type="EHC_E21.AUTHORIZATION_REQUEST.CONTENT" />
  <xsd:complexType name="EHC_E21.PSL_ITEM_INFO.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSL" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="NTE" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="AUT" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E21.PSL_ITEM_INFO"
  type="EHC_E21.PSL_ITEM_INFO.CONTENT" />
</xsd:schema>

Download

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:

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.
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.
A unique query identifier (Query Tag on QPD) must be generated for each query.
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).

QBP^E22^QBP_E22: Query Authorization Request

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - QBP_E03
Segment	Cardinality	Must Implement	Status
QBP_E03
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
	1..1	Yes	additional
QPD	1..1	Yes	additional

RCP	1..1	Yes	additional

Original Mode Acknowledgement Choreography for QBP^E22^QBP_E22

Send Application Ack: RSP^E22^RSP_E22

Enhanced Mode Acknowledgement Choreography for QBP^E22^QBP_E22

When the MSH-15 value of a QBP^E22^QBP_E22 message is AL or ER or SU, an ACK^E22^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^E22^QBP_E22 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^E22^QBP_E22 message is AL or ER or SU, a RSP^E22^RSP_E22 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^E22^QBP_E22 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E22^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: RSP^E22^RSP_E22
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: QBP_E22-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE QBP_E22 -->
  <!-- .. message definition QBP_E22 -->
  <xsd:complexType name="QBP_E22.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="QBP_E22.QUERY" minOccurs="1"
      maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="QBP_E22" type="QBP_E22.CONTENT" />
  <xsd:complexType name="QBP_E22.QUERY.CONTENT">
    <xsd:choice>
      <xsd:element ref="QPD" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="RCP" minOccurs="1" maxOccurs="1" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="QBP_E22.QUERY" type="QBP_E22.QUERY.CONTENT" />
</xsd:schema>

Download

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:

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).
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.
A unique query identifier (Query Tag on QPD) must be generated for each query.

RSP^E22^RSP_E22: Authorization Request Query Response

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - RSP_E22
Segment	Cardinality	Must Implement	Status
RSP_E22
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
MSA	1..1	Yes	additional
ERR	0..*		additional
AUTHORIZATION_INFO	1..1	Yes	additional
IVC	1..1	Yes	additional
PSG	1..1	Yes	additional
PSL_ITEM_INFO	1..*	Yes	additional
PSL	1..1	Yes	additional

Original Mode Acknowledgement Choreography for RSP^E22^RSP_E22

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RSP^E22^RSP_E22

When the MSH-15 value of a RSP^E22^RSP_E22 message is AL or ER or SU, an ACK^E22^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^E22^RSP_E22 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^E22^RSP_E22 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^E22^RSP_E22 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E22^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack:
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: RSP_E22-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE RSP_E22 -->
  <!-- .. message definition RSP_E22 -->
  <xsd:complexType name="RSP_E22.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="MSA" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="ERR" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="RSP_E22.QUERY_ACK" minOccurs="1"
      maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="RSP_E22" type="RSP_E22.CONTENT" />
  <xsd:complexType name="RSP_E22.QUERY_ACK.CONTENT">
    <xsd:choice>
      <xsd:element ref="QAK" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="QPD" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="RSP_E22.AUTHORIZATION_INFO" minOccurs="0"
      maxOccurs="1" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="RSP_E22.QUERY_ACK"
  type="RSP_E22.QUERY_ACK.CONTENT" />
  <xsd:complexType name="RSP_E22.AUTHORIZATION_INFO.CONTENT">
    <xsd:sequence>
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="PSG" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="RSP_E22.PSL_ITEM_INFO" minOccurs="1"
      maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="RSP_E22.AUTHORIZATION_INFO"
  type="RSP_E22.AUTHORIZATION_INFO.CONTENT" />
  <xsd:complexType name="RSP_E22.PSL_ITEM_INFO.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSL" minOccurs="1" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="RSP_E22.PSL_ITEM_INFO"
  type="RSP_E22.PSL_ITEM_INFO.CONTENT" />
</xsd:schema>

Download

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:

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.
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.
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).
If the AUT segment is specified, then either the Authorization Identifier on AUT or Name of Authorizer on AUT must be specified.
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^E24^EHC_E24: Authorization Response

Message Structure
Acknowlegment Choreography
v2.xml XSD

HL7 MessageStructure Table - EHC_E24
Segment	Cardinality	Must Implement	Status
EHC_E24
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..*		additional
MSA	1..1	Yes	additional
ERR	0..*		additional
PSL_ITEM_INFO	1..1	Yes	additional
PSL	1..1	Yes	additional
AUT	0..1		additional
ADJ	0..*		additional

Original Mode Acknowledgement Choreography for EHC^E24^EHC_E24

Send Application Ack: ACK^E24^ACK

Enhanced Mode Acknowledgement Choreography for EHC^E24^EHC_E24

When the MSH-15 value of an EHC^E24^EHC_E24 message is AL or ER or SU, an ACK^E24^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an EHC^E24^EHC_E24 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an EHC^E24^EHC_E24 message is AL or ER or SU, an ACK^E24^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an EHC^E24^EHC_E24 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^E24^ACK
MSH-15	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack: ACK^E24^ACK
MSH-16	NE, AL, ER, SU	(none)

<?xml version="1.0"?>
<!--   v2.xml Message Definitions for Version 2.8.2 - here: EHC_E24-->
<!--   Copyright (c) 1999-2019, Health Level Seven. All rights reserved.   -->
<!--   (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml"
targetNamespace="urn:hl7-org:v2xml" version="1.1">
  <!-- import segment definition for version -->
  <xsd:include schemaLocation="segments.xsd" />
  <!-- MESSAGE EHC_E24 -->
  <!-- .. message definition EHC_E24 -->
  <xsd:complexType name="EHC_E24.CONTENT">
    <xsd:sequence>
      <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="UAC" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="MSA" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="ERR" minOccurs="0" maxOccurs="unbounded" />
      <xsd:element ref="EHC_E24.AUTHORIZATION_RESPONSE_INFO"
      minOccurs="1" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E24" type="EHC_E24.CONTENT" />
  <xsd:complexType name="EHC_E24.AUTHORIZATION_RESPONSE_INFO.CONTENT">

    <xsd:choice>
      <xsd:element ref="IVC" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="EHC_E24.PSL_ITEM_INFO" minOccurs="1"
      maxOccurs="unbounded" />
    </xsd:choice>
  </xsd:complexType>
  <xsd:element name="EHC_E24.AUTHORIZATION_RESPONSE_INFO"
  type="EHC_E24.AUTHORIZATION_RESPONSE_INFO.CONTENT" />
  <xsd:complexType name="EHC_E24.PSL_ITEM_INFO.CONTENT">
    <xsd:sequence>
      <xsd:element ref="PSL" minOccurs="1" maxOccurs="1" />
      <xsd:element ref="AUT" minOccurs="0" maxOccurs="1" />
      <xsd:element ref="ADJ" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="EHC_E24.PSL_ITEM_INFO"
  type="EHC_E24.PSL_ITEM_INFO.CONTENT" />
</xsd:schema>

Download

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.

Message Segments

RFI - Request For Information Segment

HL7 Attribute Table - RFI - Request for Information Segment
Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length
RFI
1	Request Date	DTM	R		[1..1]	01910
2	Response Due Date	DTM	R		[1..1]	01911
3	Patient Consent	ID	O	0136(R) Yes/no Indicator(Required)	[0..1]	01912	[1..1]
4	Date Additional Information Was Submitted	DTM	O		[0..1]	01913

RFI-1: Request Date (DTM) 01910

FIXME

RFI-2: Response Due Date (DTM) 01911

FIXME

RFI-3: Patient Consent (ID) 01912

FIXME

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

FIXME

IVC - Invoice Segment

The Invoice segment is used for HealthCare Services Invoices and contains header style information for an invoice including invoice numbers, Provider Organization and Payer Organization identification.

HL7 Attribute Table - IVC - Invoice Segment
Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length	C.LEN	Flags
IVC
1	Provider Invoice Number	EI	R		[1..1]	01914
2	Payer Invoice Number	EI	O		[0..1]	01915
3	Contract/Agreement Number	EI	O		[0..1]	01916
4	Invoice Control	CWE	R	0553(S) Invoice Control Code(Suggested)	[1..1]	01917
5	Invoice Reason	CWE	R	0554 Invoice Reason Codes	[1..1]	01918
6	Invoice Type	CWE	R	0555 Invoice Type	[1..1]	01919
7	Invoice Date/Time	DTM	R		[1..1]	01920
8	Invoice Amount	CP	R		[1..1]	01921
9	Payment Terms	ST	O		[0..1]	01922		80	#
10	Provider Organization	XON	R		[1..1]	01923
11	Payer Organization	XON	R		[1..1]	01924
12	Attention	XCN	O		[0..1]	01925
13	Last Invoice Indicator	ID	O	0136(R) Yes/no Indicator(Required)	[0..1]	01926	[1..1]
14	Invoice Booking Period	DTM	O		[0..1]	01927
15	Origin	ST	O		[0..1]	01928		250	#
16	Invoice Fixed Amount	CP	O		[0..1]	01929
17	Special Costs	CP	O		[0..1]	01930
18	Amount for Doctors Treatment	CP	O		[0..1]	01931
19	Responsible Physician	XCN	O		[0..1]	01932
20	Cost Center	CX	O		[0..1]	01933
21	Invoice Prepaid Amount	CP	O		[0..1]	01934
22	Total Invoice Amount without Prepaid Amount	CP	O		[0..1]	01935
23	Total-Amount of VAT	CP	C		[0..1]	01936
24	VAT-Rates applied	NM	O		[0..*]	01937		1..5	#
25	Benefit Group	CWE	R	0556 Benefit Group	[1..1]	01938
26	Provider Tax ID	ST	O		[0..1]	02038		20	#
27	Payer Tax ID	ST	O		[0..1]	02039		20	#
28	Provider Tax Status	CWE	O	0572 Tax status	[0..1]	02040
29	Payer Tax Status	CWE	O	0572 Tax status	[0..1]	02041
30	Sales Tax ID	ST	O		[0..1]	02042		20	#

IVC-1: Provider Invoice Number (EI) 01914

FIXME

IVC-2: Payer Invoice Number (EI) 01915

FIXME

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

FIXME

IVC-4: Invoice Control (CWE) 01917

FIXME

IVC-5: Invoice Reason (CWE) 01918

FIXME

IVC-6: Invoice Type (CWE) 01919

FIXME

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

FIXME

IVC-8: Invoice Amount (CP) 01921

FIXME

IVC-9: Payment Terms (ST) 01922

FIXME

IVC-10: Provider Organization (XON) 01923

FIXME

IVC-11: Payer Organization (XON) 01924

FIXME

IVC-12: Attention (XCN) 01925

FIXME

IVC-13: Last Invoice Indicator (ID) 01926

FIXME

IVC-14: Invoice Booking Period (DTM) 01927

FIXME

IVC-15: Origin (ST) 01928

FIXME

IVC-16: Invoice Fixed Amount (CP) 01929

FIXME

IVC-17: Special Costs (CP) 01930

FIXME

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

FIXME

IVC-19: Responsible Physician (XCN) 01932

FIXME

IVC-20: Cost Center (CX) 01933

FIXME

IVC-21: Invoice Prepaid Amount (CP) 01934

FIXME

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

FIXME

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

FIXME

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

FIXME

IVC-25: Benefit Group (CWE) 01938

FIXME

IVC-26: Provider Tax ID (ST) 02038

FIXME

IVC-27: Payer Tax ID (ST) 02039

FIXME

IVC-28: Provider Tax Status (CWE) 02040

FIXME

IVC-29: Payer Tax Status (CWE) 02041

FIXME

IVC-30: Sales Tax ID (ST) 02042

FIXME

PYE - Payee Information Segment

This segment is used to define payee information.

HL7 Attribute Table - PYE - Payee Information Segment
Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length
PYE
1	Set ID – PYE	SI	R		[1..1]	01939	[1..4]
2	Payee Type	CWE	R	0557(S) Payee Type(Suggested)	[1..1]	01940
3	Payee Relationship to Invoice	CWE	C	0558 Payee Relationship to Invoice	[0..1]	01941
4	Payee Identification List	XON	C		[0..0]	01942
5	Payee Person Name	XPN	C		[0..0]	01943
6	Payee Address	XAD	C		[0..0]	01944
7	Payment Method	CWE	O	0570 Payment Method Code	[0..1]	01945

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

FIXME

PYE-2: Payee Type (CWE) 01940

FIXME

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

FIXME

PYE-4: Payee Identification List (XON) 01942

FIXME

PYE-5: Payee Person Name (XPN) 01943

FIXME

PYE-6: Payee Address (XAD) 01944

FIXME

PYE-7: Payment Method (CWE) 01945

FIXME

PSS - Product/Service Section Segment

The Product/Service Section segment is used to form a logical grouping of Product/Service Group segments, Patients and Response Summaries for a particular Invoice.

HL7 Attribute Table - PSS - Product/Service Section Segment
Seq#	Data Element Name	DataType	Usage	Cardinality	Item #	Length	C.LEN	Flags
PSS
1	Provider Product/Service Section Number	EI	R	[1..1]	01946
2	Payer Product/Service Section Number	EI	O	[0..1]	01947
3	Product/Service Section Sequence Number	SI	R	[1..1]	01948	[1..4]
4	Billed Amount	CP	R	[1..1]	01949
5	Section Description or Heading	ST	R	[1..1]	02043		254	#

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

FIXME

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

FIXME

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

FIXME

PSS-4: Billed Amount (CP) 01949

FIXME

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

FIXME

PSG - Product/Service Group Segment

The Product/Service Group segment is used to form a logical grouping of Product/Service Line Items, Patients and Response Summaries for a particular Invoice. For example, a Product/Service Group can be used to group all Product/Service Line Items that must be adjudicated as a group in order to be paid.

HL7 Attribute Table - PSG - Product/Service Group Segment
Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length	C.LEN	Flags
PSG
1	Provider Product/Service Group Number	EI	R		[1..1]	01950
2	Payer Product/Service Group Number	EI	O		[0..1]	01951
3	Product/Service Group Sequence Number	SI	R		[1..1]	01952	[1..4]
4	Adjudicate as Group	ID	R	0136(R) Yes/no Indicator(Required)	[1..1]	01953	[1..1]
5	Product/Service Group Billed Amount	CP	R		[1..1]	01954
6	Product/Service Group Description	ST	R		[1..1]	02044		254	#

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

FIXME

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

FIXME

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

FIXME

PSG-4: Adjudicate as Group (ID) 01953

FIXME

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

FIXME

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

FIXME

PSL - Product/Service Line Item Segment

The Product/Service Line Item segment is used to identify individual product/service items that typically are aggregated into an Invoice. Each instance of a Product/Service Line Item corresponds to a unique product delivered or service rendered.

HL7 Attribute Table - PSL - Product/Service Line Item Segment
Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length	C.LEN	Flags
PSL
1	Provider Product/Service Line Item Number	EI	R		[1..1]	01955
2	Payer Product/Service Line Item Number	EI	O		[0..1]	01956
3	Product/Service Line Item Sequence Number	SI	R		[1..1]	01957	[1..4]
4	Provider Tracking ID	EI	O		[0..1]	01958
5	Payer Tracking ID	EI	O		[0..1]	01959
6	Product/Service Line Item Status	CWE	R	0559(S) Product/Service Status(Suggested)	[1..1]	01960
7	Product/Service Code	CWE	R	0879 Product/Service Code	[1..1]	01961
8	Product/Service Code Modifier	CWE	O	0880 Product/Service Code Modifier	[0..0]	01962
9	Product/Service Code Description	ST	O		[0..1]	01963		80	#
10	Product/Service Effective Date	DTM	C		[0..1]	01964
11	Product/Service Expiration Date	DTM	O		[0..1]	01965
12	Product/Service Quantity	CQ	C	0560 Quantity Units	[0..1]	01966
13	Product/Service Unit Cost	CP	C		[0..1]	01967
14	Number of Items per Unit	NM	C		[0..1]	01968		10	#
15	Product/Service Gross Amount	CP	C		[0..1]	01969
16	Product/Service Billed Amount	CP	C		[0..1]	01970
17	Product/Service Clarification Code Type	CWE	O	0561 Product/Services Clarification Codes	[0..0]	01971
18	Product/Service Clarification Code Value	ST	O		[0..0]	01972		40	#
19	Health Document Reference Identifier	EI	O		[0..0]	01973
20	Processing Consideration Code	CWE	O	0562 Processing Consideration Codes	[0..0]	01974
21	Restricted Disclosure Indicator	ID	R	0532(R) Expanded Yes/no Indicator(Required)	[1..1]	01975	[1..4]
22	Related Product/Service Code Indicator	CWE	O	0879 Product/Service Code	[0..1]	01976
23	Product/Service Amount for Physician	CP	O		[0..1]	01977
24	Product/Service Cost Factor	NM	O		[0..1]	01978		5	#
25	Cost Center	CX	O		[0..1]	01933
26	Billing Period	DR	O		[0..1]	01980
27	Days without Billing	NM	O		[0..1]	01981		5	#
28	Session-No	NM	O		[0..1]	01982	[1..4]
29	Executing Physician ID	XCN	O		[0..1]	01983
30	Responsible Physician ID	XCN	O		[0..1]	01984
31	Role Executing Physician	CWE	O	0881 Role Executing Physician	[0..1]	01985
32	Medical Role Executing Physician	CWE	O	0882 Medical Role Executing Physician	[0..1]	01986
33	Side of body	CWE	O	0894(S) Side of body(Suggested)	[0..1]	01987
34	Number of TP's PP	NM	O		[0..1]	01988		6	#
35	TP-Value PP	CP	O		[0..1]	01989
36	Internal Scaling Factor PP	NM	O		[0..1]	01990		4	#
37	External Scaling Factor PP	NM	O		[0..1]	01991		4	#
38	Amount PP	CP	O		[0..1]	01992
39	Number of TP's Technical Part	NM	O		[0..1]	01993		6	#
40	TP-Value Technical Part	CP	O		[0..1]	01994
41	Internal Scaling Factor Technical Part	NM	O		[0..1]	01995		4	#
42	External Scaling Factor Technical Part	NM	O		[0..1]	01996		4	#
43	Amount Technical Part	CP	O		[0..1]	01997
44	Total Amount Professional Part + Technical Part	CP	O		[0..1]	01998
45	VAT-Rate	NM	O		[0..1]	01999		3	#
46	Main-Service	ID	O		[0..1]	02000	[1..20]
47	Validation	ID	O	0136(R) Yes/no Indicator(Required)	[0..1]	02001	[1..1]
48	Comment	ST	O		[0..1]	02002		255	#

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

FIXME

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

FIXME

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

FIXME

PSL-4: Provider Tracking ID (EI) 01958

FIXME

PSL-5: Payer Tracking ID (EI) 01959

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

PSL-20: Processing Consideration Code (CWE) 01974

FIXME

PSL-21: Restricted Disclosure Indicator (ID) 01975

FIXME

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

FIXME

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

FIXME

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

FIXME

PSL-25: Cost Center (CX) 01933

FIXME

PSL-26: Billing Period (DR) 01980

FIXME

PSL-27: Days without Billing (NM) 01981

FIXME

PSL-28: Session-No (NM) 01982

FIXME

PSL-29: Executing Physician ID (XCN) 01983

FIXME

PSL-30: Responsible Physician ID (XCN) 01984

FIXME

PSL-31: Role Executing Physician (CWE) 01985

FIXME

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

FIXME

PSL-33: Side of body (CWE) 01987

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

PSL-38: Amount PP (CP) 01992

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

PSL-43: Amount Technical Part (CP) 01997

FIXME

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

FIXME

PSL-45: VAT-Rate (NM) 01999

FIXME

PSL-46: Main-Service (ID) 02000

FIXME

PSL-47: Validation (ID) 02001

FIXME

PSL-48: Comment (ST) 02002

FIXME

ADJ - Adjustment Segment

This segment describes Provider and/or Payer adjustments to a Product/Service Line Item or Response Summary. These include surcharges such as tax, dispensing fees and mark ups.

X12 REF: Similar to CAS segment, with a few new fields.

HL7 Attribute Table - ADJ - Adjustment Segment
Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length	C.LEN	Flags
ADJ
1	Provider Adjustment Number	EI	R		[1..1]	02003
2	Payer Adjustment Number	EI	R		[1..1]	02004
3	Adjustment Sequence Number	SI	R		[1..1]	02005	[1..4]
4	Adjustment Category	CWE	R	0564 Adjustment Category Code	[1..1]	02006
5	Adjustment Amount	CP	O		[0..0]	02007
6	Adjustment Quantity	CQ	O	0560 Quantity Units	[0..1]	02008
7	Adjustment Reason PA	CWE	C	0565 Provider Adjustment Reason Code	[0..1]	02009
8	Adjustment Description	ST	O		[0..1]	02010		250	#
9	Original Value	NM	O		[0..1]	02011		16	#
10	Substitute Value	NM	O		[0..1]	02012		16	#
11	Adjustment Action	CWE	O	0569 Adjustment Action	[0..1]	02013
12	Provider Adjustment Number Cross Reference	EI	O		[0..1]	02014
13	Provider Product/Service Line Item Number Cross Reference	EI	O		[0..1]	02015
14	Adjustment Date	DTM	R		[1..1]	02016
15	Responsible Organization	XON	O		[0..1]	02017

ADJ-1: Provider Adjustment Number (EI) 02003

FIXME

ADJ-2: Payer Adjustment Number (EI) 02004

FIXME

ADJ-3: Adjustment Sequence Number (SI) 02005

FIXME

ADJ-4: Adjustment Category (CWE) 02006

FIXME

ADJ-5: Adjustment Amount (CP) 02007

FIXME

ADJ-6: Adjustment Quantity (CQ) 02008

FIXME

ADJ-7: Adjustment Reason PA (CWE) 02009

FIXME

ADJ-8: Adjustment Description (ST) 02010

FIXME

ADJ-9: Original Value (NM) 02011

FIXME

ADJ-10: Substitute Value (NM) 02012

FIXME

ADJ-11: Adjustment Action (CWE) 02013

FIXME

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

FIXME

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

FIXME

ADJ-14: Adjustment Date (DTM) 02016

FIXME

ADJ-15: Responsible Organization (XON) 02017

FIXME

PMT - Payment Information Segment

This segment contains information that describes a payment made by a Payer organization.

HL7 Attribute Table - PMT - Payment Information Segment
Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	C.LEN	Flags
PMT
1	Payment/Remittance Advice Number	EI	R		[1..1]	02018
2	Payment/Remittance Effective Date/Time	DTM	R		[1..1]	02019
3	Payment/Remittance Expiration Date/Time	DTM	R		[1..1]	02020
4	Payment Method	CWE	R	0570 Payment Method Code	[1..1]	02021
5	Payment/Remittance Date/Time	DTM	R		[1..1]	02022
6	Payment/Remittance Amount	CP	R		[1..1]	02023
7	Check Number	EI	O		[0..1]	02024
8	Payee Bank Identification	XON	O		[0..1]	02025
9	Payee Transit Number	ST	O		[0..1]	02026	4	#
10	Payee Bank Account ID	CX	O		[0..1]	02027
11	Payment Organization	XON	R		[1..1]	02028
12	ESR-Code-Line	ST	O		[0..1]	02029	100	#

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

FIXME

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

FIXME

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

FIXME

PMT-4: Payment Method (CWE) 02021

FIXME

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

FIXME

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

FIXME

PMT-7: Check Number (EI) 02024

FIXME

PMT-8: Payee Bank Identification (XON) 02025

FIXME

PMT-9: Payee Transit Number (ST) 02026

FIXME

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

FIXME

PMT-11: Payment Organization (XON) 02028

FIXME

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

FIXME

IPR - Invoice Processing Results Segment

The Invoice Processing Results (IPR) segment provides summary information about an adjudicated Product/Service Group or Product/Service Line Item.

HL7 Attribute Table - IPR - Invoice Processing Results Segment
Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	C.LEN	Flags
IPR
1	IPR Identifier	EI	R		[1..1]	02030
2	Provider Cross Reference Identifier	EI	R		[1..1]	02031
3	Payer Cross Reference Identifier	EI	R		[1..1]	02032
4	IPR Status	CWE	R	0571 Invoice Processing Results Status	[1..1]	02033
5	IPR Date/Time	DTM	R		[1..1]	02034
6	Adjudicated/Paid Amount	CP	O		[0..1]	02035
7	Expected Payment Date/Time	DTM	O		[0..1]	02036
8	IPR Checksum	ST	R		[1..1]	02037	10	#

IPR-1: IPR Identifier (EI) 02030

FIXME

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

FIXME

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

FIXME

IPR-4: IPR Status (CWE) 02033

FIXME

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

FIXME

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

FIXME

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

FIXME

IPR-8: IPR Checksum (ST) 02037

FIXME

Outstanding Issues

The following items are being discussed in the Financial Management committee for addition to future versions of HL7:

Events E10 (Edit/Adjudication Response), E24 (Authorization Response) and E12 (Request Additional Information) assume that the Payer application is able to process the requests on-line. Future versions of the Standard would include provisions for deferred responses where the Payer responds to the request once it has processed the request offline. In this use case, the Payer would either send the response as unsolicited results, or store the responses on a queue for the Provider application. If left on a queue for the Provider application, then the QVR^Q17^QVR_Q17 (Query for previous events) message might be used by the Provider application to poll the Payer application.

Draft Website - For Review Purposes Only

Claims and Reimbursement

Purpose

Scope

Trigger Events and Message Definitions

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

Original Mode Acknowledgement Choreography for EHC^E01^EHC_E01

Enhanced Mode Acknowledgement Choreography for EHC^E01^EHC_E01

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

Original Mode Acknowledgement Choreography for EHC^E02^EHC_E02

Enhanced Mode Acknowledgement Choreography for EHC^E02^EHC_E02

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

Original Mode Acknowledgement Choreography for QBP^E03^QBP_E03

Enhanced Mode Acknowledgement Choreography for QBP^E03^QBP_E03

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

Original Mode Acknowledgement Choreography for RSP^E03^RSP_E03

Enhanced Mode Acknowledgement Choreography for RSP^E03^RSP_E03

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

Original Mode Acknowledgement Choreography for EHC^E04^EHC_E04

Enhanced Mode Acknowledgement Choreography for EHC^E04^EHC_E04

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

Original Mode Acknowledgement Choreography for EHC^E10^EHC_E10

Enhanced Mode Acknowledgement Choreography for EHC^E10^EHC_E10

EHC^E12 – Request Additional Information (event E12)

Original Mode Acknowledgement Choreography for EHC^E12^EHC_E12

Enhanced Mode Acknowledgement Choreography for EHC^E12^EHC_E12

EHC^E13 – Additional Information Response (event E13)

Original Mode Acknowledgement Choreography for EHC^E13^EHC_E13

Enhanced Mode Acknowledgement Choreography for EHC^E13^EHC_E13

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

Original Mode Acknowledgement Choreography for EHC^E15^EHC_E15

Enhanced Mode Acknowledgement Choreography for EHC^E15^EHC_E15

EHC^E20 – Submit Authorization Request (event E20)

Original Mode Acknowledgement Choreography for EHC^E20^EHC_E20

Enhanced Mode Acknowledgement Choreography for EHC^E20^EHC_E20

EHC^E21 – Cancel Authorization Request (event E21)

Original Mode Acknowledgement Choreography for EHC^E21^EHC_E21

Enhanced Mode Acknowledgement Choreography for EHC^E21^EHC_E21

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

Original Mode Acknowledgement Choreography for QBP^E22^QBP_E22

Enhanced Mode Acknowledgement Choreography for QBP^E22^QBP_E22

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

Original Mode Acknowledgement Choreography for RSP^E22^RSP_E22

Enhanced Mode Acknowledgement Choreography for RSP^E22^RSP_E22

EHC^E24 – Authorization Response (event E24)

Original Mode Acknowledgement Choreography for EHC^E24^EHC_E24

Enhanced Mode Acknowledgement Choreography for EHC^E24^EHC_E24

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

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

Message Segments

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