VDA (Verband der Automobilindustrie) - Document Structure

The VDA (Verband der Automobilindustrie) standard is widely used in the German automotive industry for Electronic Data Interchange (EDI). It is a structured data format used to facilitate communication between automotive manufacturers and their suppliers, enabling them to exchange business documents such as delivery schedules, purchase orders, and shipping instructions.

VDA messages differ from other standards like EDIFACT and ANSI X12 as they are flat-file formats, without the complex hierarchical structure seen in those other EDI formats. The VDA standard has multiple document types, each identified by a unique number.

1. Basic Structure of VDA Messages

Each VDA message consists of multiple lines of fixed-length data, with each line representing a record. The record type defines the content, and records have a predefined format with fixed positions for each data element.

VDA messages don't use delimiters like other EDI standards but rely on the fixed-length fields. The position and length of each field are pre-determined, making it necessary to follow the structure precisely.

2. Message Types

VDA documents are categorized by their message type, and each message type is identified by a specific VDA number. Common VDA messages include:

• VDA 4905: Delivery Schedule.
• VDA 4913: Despatch Advice (Shipping Instruction).
• VDA 4908: Invoice.

Each VDA message type is designed for a specific business transaction.

3. Structure Overview

A typical VDA message is composed of the following key elements:

• Header Record: Contains general information about the message, such as sender, receiver, and message date.
• Data Records: Contains the main content of the message (e.g., items, quantities, delivery dates).
• Footer Record: Contains summary information, such as total quantities or number of line items.

Each line or record type in a VDA message has a specific function, and the fields within each record type are fixed in both length and format.

3.1 Header Record

The first line of a VDA message is the header record. It provides general information about the message, such as the document type, sender, and recipient.

Example for VDA 4905 (Delivery Schedule Header):

0123456789012345678901234567890123456789012345678901234567890123456789
00123456ABC1234567890DEFGH00011234567890123051420240815

• 001: Record type (Header record).
• 23456: Message reference number.
• ABC1234567890: Supplier number.
• DEFGH: Customer number.
• 0001: Version number.
• 20240815: Creation date (in the format YYYYMMDD).

3.2 Data Records

Data records contain the detailed content of the message, such as line items, quantities, and dates. Each VDA message type has its own specific structure for data records, which corresponds to the type of transaction.

Example for VDA 4905 (Delivery Schedule Data Record):

0123456789012345678901234567890123456789012345678901234567890123456789
02200345PART00100000500000000000000000451000020240815

• 022: Record type (Data record).
• 00345: Line item number.
• PART001: Part number or material number.
• 000005: Quantity ordered.
• 00000000000451: Cumulative quantity (i.e., total quantity shipped so far).
• 20240815: Delivery date.

3.3 Footer Record

The footer record concludes the message and contains control information such as total quantities, number of line items, and checksums to verify the integrity of the data.

Example for VDA 4905 (Delivery Schedule Footer):

0123456789012345678901234567890123456789012345678901234567890123456789
88800001+0000050000000000451

• 888: Record type (Footer record).
• 00001: Total number of line items.
• +0000050000000000451: Summary of total quantity ordered and cumulative quantity.

4. Example of a Full VDA 4905 Delivery Schedule Message

A complete VDA 4905 delivery schedule might look like the following:

Header Record:

00123456ABC1234567890DEFGH00011234567890123051420240815

Data Records:

02200345PART00100000500000000000000000451000020240815
02200346PART00200001000000000000000000452000020240816

Footer Record:

88800002+0000150000000000451

5. VDA Message Examples

Below are some examples of common VDA message types and their structures:

5.1 VDA 4905 - Delivery Schedule

Used to communicate delivery schedules from customers to suppliers.

• Header Record: Contains message reference, supplier, and customer details.
• Data Record: Contains part numbers, delivery dates, and quantities.
• Footer Record: Contains summary information, such as total quantities.

5.2 VDA 4913 - Despatch Advice

Used to inform the recipient of a shipment.

• Header Record: Contains shipment details, such as reference numbers and dates.
• Data Record: Contains information on shipped items, including part numbers and quantities.
• Footer Record: Contains control information, such as total shipped quantities.

5.3 VDA 4908 - Invoice

Used for invoicing customers.

• Header Record: Contains invoice number, supplier, and customer information.
• Data Record: Contains details of items invoiced, such as part numbers and prices.
• Footer Record: Contains summary information, such as total amounts and taxes.

6. Key Points of the VDA Standard

• Fixed-Length Records: VDA messages are composed of fixed-length records. Each field in a record has a specific position and length, so there are no delimiters.
• Flat Structure: Unlike EDIFACT or ANSI X12, VDA messages are not hierarchical. Each message is essentially a flat list of records.
• Automotive Focus: The VDA standard is tailored to the automotive industry and is primarily used for logistics, ordering, and shipping transactions between manufacturers and suppliers.

ODETTE (Organisation for Data Exchange by Tele-Transmission in Europe) - Document Structure

The ODETTE (Organisation for Data Exchange by Tele-Transmission in Europe) standard is an EDI format used primarily in the European automotive industry for communication between manufacturers and suppliers. ODETTE's message structure focuses on the logistics, material ordering, and shipping processes, and it is built similarly to other EDI standards but with its own terminology and structure.

1. Message Structure Overview

The structure of an ODETTE document consists of multiple levels:

• Transmission Envelope: Contains all the messages.
• Message: Contains specific business transactions.
• Segment: Contains groups of related data elements.
• Data Elements: The smallest unit of information in a segment.

Each message in ODETTE is defined by a unique identifier and contains the following key components:

• Message Header: The beginning of a message.
• Message Body: Contains the actual business data.
• Message Trailer: Marks the end of a message and provides control information.

2. Transmission Structure

The transmission structure in ODETTE acts as the outer envelope for all messages being exchanged.

a. UNB Segment (Interchange Header)

• Purpose: Marks the start of a transmission.
• Key Data Elements:
  • Syntax Identifier (UNB01)
  • Sender's Identification (UNB02)
  • Recipient's Identification (UNB03)
  • Transmission Date and Time (UNB04, UNB05)
  • Interchange Control Reference (UNB06)

Example:

UNB+UNOA:2+SENDERID+RECEIVERID+240814:1530+000001'

b. UNZ Segment (Interchange Trailer)

• Purpose: Marks the end of the transmission.
• Key Data Elements:
  • Number of Messages (UNZ01)
  • Interchange Control Reference (UNZ02): Matches the reference in the UNB segment.

Example:

UNZ+1+000001'

3. Message Structure

An ODETTE message is a container for the transaction data, whether it's an order, delivery, or shipment-related information. Each message contains header, body, and trailer segments.

a. UNH Segment (Message Header)

• Purpose: Marks the start of the message.
• Key Data Elements:
  • Message Reference Number (UNH01)
  • Message Type Identifier (UNH02): Identifies the type of message, such as DELJIT (Delivery Just-in-Time) or ORDERS (Purchase Order).
  • Version and Release Number (UNH03, UNH04)

Example:

UNH+000001+DELJIT:D:96A:UN'

b. UNT Segment (Message Trailer)

• Purpose: Marks the end of a message.
• Key Data Elements:
  • Number of Segments (UNT01)
  • Message Reference Number (UNT02): Matches the number in the UNH segment.

Example:

UNT+10+000001'

4. Message Types and Examples

ODETTE provides different message types tailored to specific business processes within the automotive industry. Below are examples of common ODETTE messages:

a. ORDERS Message (Purchase Order)

• Purpose: Used to place orders for materials or components.

Example of an ORDERS Message:

UNH+000001+ORDERS:D:96A:UN'
BGM+220+ORD12345+9'
DTM+137:20240814'
NAD+BY+SENDERID'
NAD+SU+SUPPLIERID'
LIN+1++PARTID:BP'
QTY+21:100'
UNT+7+000001'

• BGM (Beginning of Message): Specifies the order number.
• DTM (Date/Time/Period): Specifies the order date.
• NAD (Name and Address): Identifies the buyer (BY) and supplier (SU).
• LIN (Line Item): Identifies the ordered part.
• QTY (Quantity): Specifies the quantity ordered.

b. DELJIT Message (Delivery Just-in-Time)

• Purpose: Informs the supplier of delivery schedules to ensure timely deliveries.

Example of a DELJIT Message:

UNH+000002+DELJIT:D:96A:UN'
BGM+241+DELJIT12345+9'
DTM+137:20240814'
NAD+BY+SENDERID'
NAD+SU+SUPPLIERID'
LIN+1++PARTID:BP'
QTY+21:50'
UNT+7+000002'

• BGM (Beginning of Message): Contains the delivery schedule reference number.
• DTM (Date/Time/Period): Specifies the date for delivery.
• NAD (Name and Address): Identifies the buyer (BY) and supplier (SU).
• LIN (Line Item): Identifies the item being delivered.
• QTY (Quantity): Specifies the delivery quantity.

c. RECADV Message (Receiving Advice)

• Purpose: Acknowledges the receipt of goods from the supplier.

Example of a RECADV Message:

UNH+000003+RECADV:D:96A:UN'
BGM+351+RECADV12345+9'
DTM+137:20240814'
NAD+BY+SENDERID'
NAD+SU+SUPPLIERID'
LIN+1++PARTID:BP'
QTY+21:50'
UNT+7+000003'

• BGM (Beginning of Message): Provides the receipt advice number.
• DTM (Date/Time/Period): Specifies the date of receipt.
• NAD (Name and Address): Identifies the buyer and supplier.
• LIN (Line Item): Identifies the received item.
• QTY (Quantity): Specifies the received quantity.

5. Segments and Data Elements

Each message in ODETTE is composed of segments, which in turn contain data elements. Segments are identified by a three-letter code, and data elements are separated by the plus sign (+). Sub-elements within a data element are separated by a colon (:).

• Segment Code: A three-letter identifier that defines the segment type.
• Data Elements: Pieces of information within a segment, separated by the + delimiter.
• Sub-elements: Additional data within a data element, separated by a colon (:).

Example of Segments:

• UNH Segment:

  UNH+000001+DELJIT:D:96A:UN'

  • 000001: Message Reference Number.
  • DELJIT: Message Type Identifier (Delivery Just-in-Time).
  • D:96A: Version and Release Number.
  • UN: Controlling Agency.

• LIN Segment (Line Item):

  LIN+1++PARTID:BP'

  • 1: Line Item Number.
  • PARTID
    : Part Number and Code.

• QTY Segment (Quantity):

  QTY+21:50'

  • 21: Quantity Qualifier (e.g., ordered or delivered quantity).
  • 50: Quantity.

6. Delimiters

Like other EDI standards, ODETTE uses delimiters to separate different elements in a message:

• Segment Terminator: Apostrophe ('), marking the end of a segment.
• Data Element Separator: Plus sign (+), separating individual data elements.
• Sub-element Separator: Colon (:), separating sub-elements within a data element.

Example: Full Structure of an ODETTE DELJIT Message

UNB+UNOA:2+SENDERID+RECEIVERID+240814:1530+000001'
UNH+000001+DELJIT:D:96A:UN'
BGM+241+DELJIT12345+9'
DTM+137:20240814'
NAD+BY+SENDERID'
NAD+SU+SUPPLIERID'
LIN+1++PARTID:BP'
QTY+21:50'
UNT+7+000001'
UNZ+1+000001'

7. Common ODETTE Message Types

• ORDERS: Purchase Orders.
• DELJIT: Delivery Just-in-Time.
• RECADV: Receiving Advice.
• DESADV: Despatch Advice (Shipping Notice).
• INVOIC: Invoice.

TRADACOMS - Document Structure

The TRADACOMS (TRAding DAta COMmunications Standards) standard was widely used in the UK for electronic data interchange (EDI) before being mostly replaced by EDIFACT. TRADACOMS is particularly used in the retail industry and was originally developed by the UK Article Number Association (ANA). Its structure is different from both ANSI ASC X12 and EDIFACT, with a specific organization of segments, groups, and data elements.

1. Message Structure Overview

A TRADACOMS message is composed of multiple levels:

• Transmission (envelope for the entire transmission)
• Interchange (contains multiple messages or groups of messages)
• Message (the individual transaction, such as an order or invoice)
• Segment (a unit containing data elements)
• Data Elements (the smallest units of data in a segment)

2. Transmission Structure

At the highest level, a TRADACOMS document contains transmission envelopes. The transmission envelope consists of the following segments:

a. STX Segment (Start of Transmission)

• Purpose: Marks the start of the entire transmission.
• Key Data Elements:
  • Transmission Reference Number (STX01)
  • Sender's Identification (STX02)
  • Receiver's Identification (STX03)
  • Transmission Date (STX04)
  • Transmission Time (STX05)
  • Transmission Control Number (STX06)

Example:

STX=ANA:1+SENDERID+RECEIVERID+240814:1530+1'

b. END Segment (End of Transmission)

• Purpose: Marks the end of the transmission.
• Key Data Elements:
  • Transmission Control Number (END01): Should match the control number in the STX segment.

Example:

END=1'

3. Interchange Structure

An interchange can contain one or more related messages. It's essentially a grouping mechanism within the transmission, similar to EDIFACT's functional group. The group is made up of a header and trailer:

a. MHD Segment (Message Header)

• Purpose: Marks the start of an interchange.
• Key Data Elements:
  • Message Type Identifier (MHD01): Identifies the type of message (e.g., ORDHDR for Purchase Order Header).
  • Message Version Number (MHD02)
  • Message Number (MHD03)

Example:

MHD=ORDHDR:9+0001'

b. MTR Segment (Message Trailer)

• Purpose: Marks the end of an interchange or a group of messages.
• Key Data Elements:
  • Total Number of Segments (MTR01)
  • Message Number (MTR02): Should match the number in the MHD segment.

Example:

MTR=15+0001'

4. Message Structure

The message is the core of the TRADACOMS standard and contains the business transaction. A message is typically divided into three parts:

• Header: Contains identifying information about the message.
• Body: Contains the actual business data, such as items in an order or invoice.
• Footer: Contains summary or control information.

For example, in a purchase order (ORDHDR message), the message structure could be divided as follows:

a. ORDHDR Message (Purchase Order Header)

• Purpose: Represents the beginning of a purchase order.

Header Segments:

• TYP Segment (Transaction Type): Indicates the type of transaction.
• SDT Segment (Supplier Details): Identifies the supplier.
• BDT Segment (Buyer Details): Identifies the buyer.

Example:

TYP=0350+ORDHDR'
SDT+SUPPLIERID'
BDT+BUYERID'

Body Segments:

• LIN Segment (Line Item): Details individual items in the order.
• QTY Segment (Quantity): Specifies the quantity of the line item.
• PRI Segment (Price): Specifies the price of the line item.

Example:

LIN+1+ITEMID'
QTY+10'
PRI+25.00'

Footer Segments:

• SST Segment (Summary Totals): Provides summary information, such as total quantity and value.
• TRL Segment (Transaction Trailer): Indicates the end of the message.

Example:

SST+TOTALQTY:100+TOTALVALUE:2500.00'
TRL+1'

5. Segments

Segments are the building blocks of TRADACOMS messages, similar to other EDI standards. Each segment contains one or more data elements. Segments in TRADACOMS are identified by a three-letter code and contain data elements separated by the equals sign (=) or plus sign (+).

• Segment Name: Always begins with a three-letter code.
• Data Elements: Contain the actual information and are separated by +.

Example Segments:

• ORDHDR Segment (Order Header):

  ORDHDR+ORDERID+DATE'

• LIN Segment (Line Item):

  LIN+1+ITEMID'

• QTY Segment (Quantity):

  QTY+10'

6. Data Elements

Each segment in TRADACOMS consists of data elements that provide the specific details for that segment. Data elements are separated by plus signs (+), and sub-elements (if any) are separated by colons (:).

a. Example of Data Elements:

• TYP Segment:

  TYP=0350+ORDHDR'

  • 0350: Transaction Type Code
  • ORDHDR: Message Identifier

• LIN Segment:

  LIN+1+ITEMID'

  • 1: Line Item Number
  • ITEMID: Unique Item Code

7. Delimiters

Delimiters are special characters used to separate components within TRADACOMS messages. These include:

• Segment Separator: Typically the apostrophe ('), marking the end of each segment.
• Data Element Separator: Typically the plus sign (+), separating individual data elements.
• Sub-element Separator: Typically the colon (:), separating sub-elements within a data element.

Example : Full Structure of a Purchase Order

STX=ANA:1+SENDERID+RECEIVERID+240814:1530+1'
MHD=ORDHDR:9+0001'
TYP=0350+ORDHDR'
SDT+SUPPLIERID'
BDT+BUYERID'
LIN+1+ITEMID'
QTY+10'
PRI+25.00'
LIN+2+ITEMID2'
QTY+5'
PRI+50.00'
SST+TOTALQTY:15+TOTALVALUE:500.00'
TRL+1'
MTR=9+0001'
END=1'

8. Key Message Types

• ORDHDR: Purchase Order
• INVOIC: Invoice
• DELHDR: Delivery Note
• PRICAT: Price Catalogue

EDIFACT - Document Structure

The UN/EDIFACT (United Nations/Electronic Data Interchange for Administration, Commerce, and Transport) standard is an international EDI standard that facilitates the exchange of business information between different organizations. The structure of an EDIFACT document is hierarchical, similar to ANSI ASC X12, but with different terminology and format. Here’s a detailed overview of the EDIFACT document structure:

1. Interchange Envelope

The interchange envelope wraps around the entire EDIFACT message and consists of UNA (optional), UNB, and UNZ segments.

a. UNA Segment (Service String Advice)

• Purpose: Defines the separators used in the message. This segment is optional and, when present, must appear at the beginning of the interchange.
• Components:
  • Component Data Element Separator: Typically +
  • Data Element Separator: Typically :
  • Decimal Mark: Typically .
  • Release Character: Typically ?
  • Reserved (space): Typically
  • Segment Terminator: Typically '

Example:

UNA:+.? '

b. UNB Segment (Interchange Header)

• Purpose: Identifies the sender, receiver, date, time, and control information for the interchange.
• Key Data Elements:
  • Syntax Identifier (UNB01)
  • Syntax Version Number (UNB02)
  • Sender Identification (UNB03)
  • Recipient Identification (UNB06)
  • Date (UNB08)
  • Time (UNB09)
  • Interchange Control Reference (UNB10)
  • Application Reference (UNB11)
  • Processing Priority Code (UNB12)
  • Acknowledgment Request (UNB13)
  • Test Indicator (UNB14)

Example:

UNB+UNOA:1+SENDERID+RECEIVERID+240814:1530+000000001'

c. UNZ Segment (Interchange Trailer)

• Purpose: Marks the end of the interchange and provides control totals.
• Key Data Elements:
  • Interchange Control Count (UNZ01)
  • Interchange Control Reference (UNZ02): Matches the control reference in the UNB segment.

Example:

UNZ+1+000000001'

2. Functional Group (Optional)

The functional group groups related messages, though this is not always used in EDIFACT.

a. UNG Segment (Functional Group Header)

• Purpose: Groups related messages together.
• Key Data Elements:
  • Functional Group Identifier (UNG01)
  • Application Sender's Identification (UNG02)
  • Application Receiver's Identification (UNG03)
  • Date (UNG04)
  • Time (UNG05)
  • Group Reference Number (UNG06)
  • Application Password (UNG07)
  • Application Level (UNG08)

Example:

UNG+ORDERS+SENDERID+RECEIVERID+240814:1530+1'

b. UNE Segment (Functional Group Trailer)

• Purpose: Marks the end of a functional group and provides control totals.
• Key Data Elements:
  • Number of Messages (UNE01)
  • Group Reference Number (UNE02): Matches the reference number in the UNG segment.

Example:

UNE+1+1'

3. Message

Each functional group (if used) contains one or more messages, each representing a specific business transaction, such as an order or invoice. The message starts with the UNH segment and ends with the UNT segment.

a. UNH Segment (Message Header)

• Purpose: Identifies the beginning of the message.
• Key Data Elements:
  • Message Reference Number (UNH01)
  • Message Type Identifier (UNH02): Identifies the type of message (e.g., ORDERS for Purchase Order).
  • Message Type Version Number (UNH03)
  • Message Type Release Number (UNH04)
  • Controlling Agency (UNH05)
  • Association Assigned Code (UNH06)
  • Common Access Reference (UNH07)

Example:

UNH+0001+ORDERS:D:96A:UN'

b. UNT Segment (Message Trailer)

• Purpose: Marks the end of the message and provides control totals.
• Key Data Elements:
  • Number of Segments (UNT01)
  • Message Reference Number (UNT02): Matches the reference number in the UNH segment.

Example:

UNT+15+0001'

4. Segments

Segments are the building blocks of the message, each containing related data elements. Segments begin with a three-character identifier and end with a segment terminator (').

a. Example Segments in an ORDERS Message:

1. BGM Segment (Beginning of Message)

   • Purpose: Indicates the start of the purchase order message.
   • Key Data Elements:
     • Document/Message Name (BGM01)
     • Document/Message Number (BGM02)
     • Message Function Code (BGM03)

   Example:

   BGM+220+123456789+9'

2. DTM Segment (Date/Time/Period)

   • Purpose: Specifies dates relevant to the message.
   • Key Data Elements:
     • Date/Time/Period Qualifier (DTM01)
     • Date (DTM02)
     • Date/Time/Period Format Qualifier (DTM03)

   Example:

   DTM+137:20240814:102'

3. NAD Segment (Name and Address)

   • Purpose: Identifies the parties involved in the transaction, such as the buyer and seller.
   • Key Data Elements:
     • Party Qualifier (NAD01)
     • Party Identification (NAD02)
     • Party Name (NAD04)

   Example:

   NAD+BY+12345::16++BUYER NAME+123 BUYER STREET+BUYER CITY++ZIP'

4. LIN Segment (Line Item)

   • Purpose: Specifies details about individual items being ordered.
   • Key Data Elements:
     • Line Item Number (LIN01)
     • Item Number Type (LIN02)
     • Item Number (LIN03)

   Example:

   LIN+1++1001:BP'

5. QTY Segment (Quantity)

   • Purpose: Specifies the quantity of items ordered.
   • Key Data Elements:
     • Quantity Qualifier (QTY01)
     • Quantity (QTY02)

   Example:

   QTY+21:10'

5. Data Elements

Data elements are the smallest units of information in an EDIFACT document. Each data element is defined by its data element number and can contain alphanumeric, numeric, or date values.

a. Types of Data Elements:

• Simple Data Element: Contains a single piece of data.
• Composite Data Element: Contains multiple components, which are further broken down into simple data elements.

6. Delimiters

Delimiters are special characters used to separate different parts of the document:

• Component Data Element Separator: Typically a colon (:).
• Data Element Separator: Typically a plus sign (+).
• Decimal Mark: Typically a period (.).
• Release Character: Typically a question mark (?).
• Segment Terminator: Typically an apostrophe (').

Example: Full Structure

Here’s a summarized view of a simple EDIFACT ORDERS Purchase Order document:

UNA:+.? '
UNB+UNOA:1+SENDERID+RECEIVERID+240814:1530+000000001'
UNH+0001+ORDERS:D:96A:UN'
BGM+220+123456789+9'
DTM+137:20240814:102'
NAD+BY+12345::16++BUYER NAME+123 BUYER STREET+BUYER CITY++ZIP'
LIN+1++1001:BP'
QTY+21:10'
UNT+15+0001'
UNZ+1+000000001'

ANSI ASC X12 - Document Structure

The ANSI ASC X12 document structure is a well-defined format used for Electronic Data Interchange (EDI) in North America. It allows businesses to exchange standard documents electronically, ensuring that the data is structured in a consistent and machine-readable format. The structure of an ANSI ASC X12 document is hierarchical, consisting of envelopes, segments, and data elements. Below is a detailed breakdown of each component:

1. Interchange Envelope

The highest level of the structure, the interchange envelope, wraps around the entire EDI document. It consists of the ISA and IEA segments.

a. ISA Segment (Interchange Control Header)

• Purpose: Identifies the sender, receiver, and control information for the entire interchange.
• Key Data Elements:
  • Authorization Information Qualifier (ISA01)
  • Authorization Information (ISA02)
  • Security Information Qualifier (ISA03)
  • Security Information (ISA04)
  • Interchange ID Qualifier (ISA05): Identifies the type of sender ID.
  • Interchange Sender ID (ISA06)
  • Interchange ID Qualifier (ISA07): Identifies the type of receiver ID.
  • Interchange Receiver ID (ISA08)
  • Interchange Date (ISA09)
  • Interchange Time (ISA10)
  • Interchange Control Standards Identifier (ISA11)
  • Interchange Control Version Number (ISA12)
  • Interchange Control Number (ISA13)
  • Acknowledgment Requested (ISA14)
  • Usage Indicator (ISA15): Indicates whether the data is test or production.
  • Component Element Separator (ISA16): Specifies the delimiter for sub-elements.

Example:

ISA*00*          *00*          *ZZ*SENDERID      *ZZ*RECEIVERID    *240814*1530*U*00401*000000001*0*T*:~

b. IEA Segment (Interchange Control Trailer)

• Purpose: Marks the end of the interchange and provides control totals.
• Key Data Elements:
  • Number of Included Functional Groups (IEA01)
  • Interchange Control Number (IEA02): Matches the control number in the ISA segment.

Example:

IEA*1*000000001~

2. Functional Group

The functional group encloses a group of related transaction sets. It consists of the GS and GE segments.

a. GS Segment (Functional Group Header)

• Purpose: Groups related transactions, such as all purchase orders or invoices, under a single functional group.
• Key Data Elements:
  • Functional Identifier Code (GS01): Identifies the type of transactions (e.g., PO for Purchase Order).
  • Application Sender's Code (GS02)
  • Application Receiver's Code (GS03)
  • Date (GS04)
  • Time (GS05)
  • Group Control Number (GS06)
  • Responsible Agency Code (GS07)
  • Version/Release/Industry Identifier Code (GS08)

Example:

GS*PO*SENDERID*RECEIVERID*20240814*1530*1*X*004010~

b. GE Segment (Functional Group Trailer)

• Purpose: Marks the end of a functional group and provides control totals.
• Key Data Elements:
  • Number of Transaction Sets Included (GE01)
  • Group Control Number (GE02): Matches the control number in the GS segment.

Example:

GE*1*1~

3. Transaction Set

Each functional group contains one or more transaction sets, each representing a specific business document, such as a purchase order or invoice. It consists of the ST and SE segments.

a. ST Segment (Transaction Set Header)

• Purpose: Identifies the beginning of a transaction set.
• Key Data Elements:
  • Transaction Set Identifier Code (ST01): Identifies the type of transaction (e.g., 850 for Purchase Order).
  • Transaction Set Control Number (ST02): Unique number for tracking the transaction set.

Example:

ST*850*0001~

b. SE Segment (Transaction Set Trailer)

• Purpose: Marks the end of a transaction set and provides control totals.
• Key Data Elements:
  • Number of Included Segments (SE01)
  • Transaction Set Control Number (SE02): Matches the control number in the ST segment.

Example:

SE*15*0001~

4. Segments

Segments are the building blocks of the transaction set, each containing related data elements. Segments begin with a two- or three-character identifier.

a. Example Segments in an 850 Purchase Order:

1. BEG Segment (Beginning Segment for Purchase Order)

   • Purpose: Indicates the start of the purchase order.
   • Key Data Elements:
     • Transaction Set Purpose Code (BEG01)
     • Purchase Order Type Code (BEG02)
     • Purchase Order Number (BEG03)
     • Date (BEG05)

   Example:

   BEG*00*SA*123456789**20240814~

2. REF Segment (Reference Identification)

   • Purpose: Provides additional identifying information.
   • Key Data Elements:
     • Reference Identification Qualifier (REF01)
     • Reference Identification (REF02)

   Example:

   REF*DP*1234~

3. N1 Segment (Name)

   • Purpose: Identifies a party involved in the transaction.
   • Key Data Elements:
     • Entity Identifier Code (N101)
     • Name (N102)
     • Identification Code Qualifier (N103)
     • Identification Code (N104)

   Example:

   N1*BY*BUYER NAME*92*12345~

4. PO1 Segment (Purchase Order Line Item)

   • Purpose: Provides details about individual items being ordered.
   • Key Data Elements:
     • Assigned Identification (PO101)
     • Quantity Ordered (PO102)
     • Unit of Measure (PO103)
     • Unit Price (PO104)
     • Product/Service ID Qualifier (PO106)
     • Product/Service ID (PO107)

   Example:

   PO1*1*10*EA*25.00*PE*BP*1001*VP*5678~

5. PID Segment (Product/Item Description)

   • Purpose: Provides a description of the item.
   • Key Data Elements:
     • Item Description Type (PID01)
     • Description (PID05)

   Example:

   PID*F****BLUE WIDGET~

5. Data Elements

Data elements are the smallest units of information in an EDI document. Each data element is defined by its data element number and can contain alphanumeric, numeric, or date values.

a. Types of Data Elements:

• Simple Data Element: Contains a single piece of data, such as a number or text.
• Composite Data Element: Contains multiple components, which are further broken down into simple data elements.

6. Delimiters

Delimiters are special characters used to separate different parts of the document:

• Data Element Separator: Typically an asterisk (*), used to separate individual data elements within a segment.
• Sub-element Separator: Often a colon (:), used within composite data elements to separate individual components.
• Segment Terminator: Typically a tilde (~), used to indicate the end of a segment.

Example: Full Structure

Here’s a summarized view of a simple ANSI ASC X12 850 Purchase Order document:

ISA*00*          *00*          *ZZ*SENDERID      *ZZ*RECEIVERID    *240814*1530*U*00401*000000001*0*T*:~
GS*PO*SENDERID*RECEIVERID*20240814*1530*1*X*004010~
ST*850*0001~
BEG*00*SA*123456789**20240814~
REF*DP*1234~
N1*BY*BUYER NAME*92*12345~
N3*123 BUYER STREET~
N4*BUYER CITY*STATE*ZIP~
N1*ST*SHIP TO NAME*92*54321~
N3*456 SHIPPER AVENUE~
N4*SHIPPER CITY*STATE*ZIP~
PO1*1*10*EA*25.00*PE*BP*1001*VP*5678~
PID*F****BLUE WIDGET~
SCH*10*20240820*010*AL~
CTT*1~
SE*15*0001~
GE*1*1~
IEA*1*000000001~

EDI Standard - HIPAA EDI (Health Insurance Portability and Accountability Act Electronic Data Interchange)

HIPAA EDI (Health Insurance Portability and Accountability Act Electronic Data Interchange) refers to the standards and regulations governing the electronic exchange of healthcare-related information in the United States. These standards are essential for ensuring the secure, accurate, and efficient transmission of healthcare data between entities such as healthcare providers, insurers, and clearinghouses.

Overview of HIPAA EDI

1. Background and Purpose:

   • HIPAA Legislation: The Health Insurance Portability and Accountability Act (HIPAA) was enacted in 1996 to improve the efficiency and effectiveness of the U.S. healthcare system. One of the key aspects of HIPAA is the standardization of electronic transactions in healthcare.
   • EDI Standards: Under HIPAA, specific EDI standards are mandated for the electronic exchange of healthcare data. These standards help streamline transactions, reduce paperwork, and ensure the confidentiality and security of sensitive health information.

2. Key HIPAA EDI Transactions: HIPAA mandates several standard EDI transaction sets, each identified by a unique transaction code. These transaction sets are used for different types of healthcare-related communications:

   • 837: Health Care Claim (Institutional, Professional, Dental)
     • Used to submit claims for services rendered by healthcare providers to insurers.
   • 835: Health Care Claim Payment/Advice
     • Used by insurers to make payments and provide explanations of benefits (EOBs) to providers.
   • 270/271: Eligibility Inquiry and Response
     • 270 is used by providers to inquire about a patient’s insurance eligibility and coverage, and 271 is the response from the insurer.
   • 276/277: Claim Status Inquiry and Response
     • 276 is used to inquire about the status of a claim, and 277 is the response with the claim’s status.
   • 278: Health Care Services Review – Request for Review and Response
     • Used for prior authorization or referral requests and responses.
   • 834: Benefit Enrollment and Maintenance
     • Used by employers or plan sponsors to enroll or update employee health plan information with insurers.
   • 820: Premium Payment
     • Used to send premium payments from employers or plan sponsors to insurers.
   • 999: Implementation Acknowledgment
     • Used to confirm the receipt and validation of EDI transactions.

3. HIPAA Compliance Requirements:

   • Privacy and Security: HIPAA EDI standards must be implemented in compliance with HIPAA’s Privacy Rule and Security Rule, which protect the confidentiality, integrity, and availability of Protected Health Information (PHI).
   • Transactions and Code Sets: HIPAA requires the use of standardized code sets (e.g., ICD-10, CPT, HCPCS) for diagnoses, procedures, and services, ensuring consistency in healthcare data across the industry.
   • Covered Entities: HIPAA EDI standards apply to covered entities, including healthcare providers, health plans, and healthcare clearinghouses. Business associates that handle PHI on behalf of covered entities must also comply with HIPAA regulations.

4. Benefits of HIPAA EDI:

   • Efficiency: HIPAA EDI streamlines the processing of healthcare transactions, reducing administrative burdens and speeding up claims processing and payments.
   • Accuracy: Standardized data formats help minimize errors in transactions, leading to more accurate and reliable data exchanges.
   • Cost Savings: By automating transactions, HIPAA EDI reduces the need for manual processing and paper-based communications, resulting in cost savings for healthcare organizations.
   • Security: The mandated standards ensure that sensitive healthcare information is transmitted securely, protecting patient privacy and reducing the risk of data breaches.

5. Implementation of HIPAA EDI:

   • EDI Software: Healthcare organizations use EDI software to convert their internal data into HIPAA-compliant EDI formats. This software also facilitates the transmission and receipt of EDI transactions.
   • Clearinghouses: Many healthcare providers use clearinghouses to manage their EDI transactions. Clearinghouses act as intermediaries that receive, process, and forward EDI transactions between providers and insurers.
   • Testing and Validation: Before full implementation, EDI transactions must be tested to ensure they meet HIPAA standards. The 999 Implementation Acknowledgment is used to confirm the successful receipt and validation of transactions.