### OpenEDI Specification: Defining EDI Syntax Rules

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Describes how intra-segment and intra-composite data element dependencies (syntax rules) are defined using the `x-openedi-syntax` extension property. It details the format of each rule item, including position formatting and condition designators.

```APIDOC
Schema Object Extension Property for EDI Syntax Rules:
  x-openedi-syntax:
    Description: An array of items representing syntax rules.
    Type: array
    Optional: true
    Item Format: "{condition designator}{start position}[other positions]{end position}"
    Position Format: Two-digit numeric values (00-99).
    Condition Designators:
      P: Paired - If any element in specified positions is not null, all must be not null.
      R: Required - At least one element in specified positions must not be null.
      E: Exclusion - Only one element in specified positions must not be null.
      C: Conditional - If first element is not null, all specified elements must be not null.
      L: List Conditional - If any element in specified positions is not null, at least one more must be not null.
```

--------------------------------

### OpenEDI Specification: Defining EDI Loops (Groups)

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Explains how EDI Loops, which are repeatable blocks of ordered EDI Segments, are defined as Schema objects. It specifies the required extension property for the loop ID.

```APIDOC
Schema Object Extension Property for EDI Loop:
  x-openedi-loop-id:
    Description: The loop ID.
    Required: true
```

--------------------------------

### OpenAPI Schema Structure for EDI Segment Conversion

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Conceptual OpenAPI Schema object structure for representing an EDI Segment. It demonstrates how simple data elements are mapped to string types, composite data elements to reference objects, and repeatable items to arrays with `minItems` and `maxItems`, along with the `x-openedi-segment-id` extension.

```APIDOC
# Conceptual OpenAPI Schema for an EDI Segment
type: object
x-openedi-segment-id: <Segment ID>
description: Optional description for the EDI Segment
properties:
  # Non-repeatable simple data element
  <simple_data_element_id>:
    type: string
    description: Optional description for the simple data element
  # Non-repeatable composite data element
  <composite_data_element_id>:
    $ref: '#/components/schemas/<CompositeDataElementSchemaName>'
    description: Optional description for the composite data element
  # Repeatable simple data element
  <repeatable_simple_data_element_id>:
    type: array
    minItems: <min_repetitions>
    maxItems: <max_repetitions>
    items:
      type: string
    description: Optional description for the repeatable simple data element
  # Repeatable composite data element
  <repeatable_composite_data_element_id>:
    type: array
    minItems: <min_repetitions>
    maxItems: <max_repetitions>
    items:
      $ref: '#/components/schemas/<CompositeDataElementSchemaName>'
    description: Optional description for the repeatable composite data element
```

--------------------------------

### OpenEDI Specification: Defining EDI Segments

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Details how EDI Segments, representing units of data (data elements), are defined as Schema objects. It outlines the required extension property for the segment ID.

```APIDOC
Schema Object Extension Property for EDI Segment:
  x-openedi-segment-id:
    Description: The segment ID.
    Required: true
```

--------------------------------

### Define EDI Situational Rules with x-openedi-situational (APIDOC)

Source: https://github.com/edination/openedi-specification/blob/main/README.md

The `x-openedi-situational` extension property defines intra-segment conditions for EDI data elements. It specifies rules where the existence or value of one data element dictates the conformance of another. These rules are applied at the segment or composite data element level.

```APIDOC
x-openedi-situational:
  type: array
  description: An array of items that represent all situational rules in the segment/composite data element.
  items:
    type: string
    description: |
      Format 1 (Not Used): {condition designator}{start position}[other positions]
      Format 2 (Conditional Required/Exclusion): {condition designator}{start position}{end position}_{value1}[_{other values}]

      Where:
      - {start position}, {end position}: Two-digit numeric values (00-99), padded with a leading zero if less than 10.
      - {value1}, {other values}: Underscore-separated values.
      - {condition designator}:
        R: Conditional Required. When the element in the second position is equal to one of the specified codes, then the first element must not be null.
        E: Conditional Exclusion. When the element in the second position is equal to one of the specified codes, then the first element must be null.
        N: Not used. When a "Not Used" data element's value is not null, it is marked as a validation error.
```

--------------------------------

### Group EDI Loops or Segments with x-openedi-group-type (APIDOC)

Source: https://github.com/edination/openedi-specification/blob/main/README.md

The `x-openedi-group-type` extension property defines additional grouping mechanisms for EDI segments or loops beyond standard EDI loop definitions. It allows for flexible arrangements where segments or loops can appear in the same position, with rules for presence (any, one, or sequential).

```APIDOC
x-openedi-group-type:
  type: string
  description: Defines how segments or loops are grouped when they can appear in the same position.
  enum:
    - anyOf
    - oneOf
    - seqOf
  enum_descriptions:
    anyOf: For segments or loops that can appear in the same position, in any order.
    oneOf: For segments or loops that can appear in the same position; however, only one of them must be present.
    seqOf: For segments that can appear in order, however, can't be represented as EDI Loops because the first segment is optional.
```

--------------------------------

### OpenEDI Specification: Defining EDI Composite Data Elements

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Describes how EDI Composite Data Elements, which are repeatable blocks of data elements, are defined as Schema objects. It specifies the required extension property for the composite data element ID.

```APIDOC
Schema Object Extension Property for EDI Composite Data Element:
  x-openedi-composite-id:
    Description: The composite data element ID.
    Required: true
```

--------------------------------

### Defining Repeatable and Non-Repeatable EDI Items in OpenAPI

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Explains how to define non-repeatable EDI items using direct `$ref` properties and repeatable items using OpenAPI array objects. For repeatable items, `minItems` and `maxItems` attributes are used to specify the repetition range.

```APIDOC
{
  "type": "object",
  "properties": {
    "nonRepeatableItem": {
      "$ref": "#/components/schemas/NonRepeatableItem",
      "description": "A single instance of an EDI item"
    },
    "repeatableItem": {
      "type": "array",
      "items": { "$ref": "#/components/schemas/RepeatableItem" },
      "minItems": 1,
      "maxItems": 99,
      "description": "An array of repeatable EDI items, with min/max occurrences"
    }
  }
}
```

--------------------------------

### OpenEDI Specification: Defining EDI Messages

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Describes how EDI messages, representing business documents like purchase orders or medical claims, are defined as Schema objects within the OpenEDI specification. It details the required extension properties for standard, ID, and version.

```APIDOC
Schema Object Extension Properties for EDI Message:
  x-openedi-message-standard:
    Description: The EDI standard (X12 or EDIFACT).
    Required: true
  x-openedi-message-id:
    Description: The message ID.
    Required: true
  x-openedi-message-version:
    Description: The EDI edition and release.
    Required: Only if multiple messages with the same ID are in the same definition.
```

--------------------------------

### Grouping Multiple EDI Segments or Loops in OpenAPI

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Explains how to group multiple EDI segments or loops that appear in the same position within an EDI guideline. A new OpenAPI Schema object is created for the group, marked with the `x-openedi-group-type` extension property to define its nature.

```APIDOC
{
  "type": "object",
  "x-openedi-group-type": {
    "type": "string",
    "description": "Type of grouping (e.g., 'Loop', 'SegmentGroup')"
  },
  "properties": {
    "NM1_Loop_1": { "$ref": "#/components/schemas/NM1Loop" },
    "NM1_Loop_2": { "$ref": "#/components/schemas/NM1Loop" }
  }
}
```

--------------------------------

### OpenEDI Specification: Defining EDI Data Elements

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Explains how EDI Data Elements, the actual units of data appearing in segments or composite data elements, are defined as primitive properties of a Schema object with type `string`. It details the required extension property for the data element ID.

```APIDOC
Schema Object Primitive Property for EDI Data Element:
  Type: string
  x-openedi-element-id:
    Description: The data element ID.
    Required: true
```

--------------------------------

### Define EDI Sequences with x-openedi-loop-seq (APIDOC)

Source: https://github.com/edination/openedi-specification/blob/main/README.md

The `x-openedi-loop-seq` extension property is used at the loop level to denote a segment within a repeating loop that requires its data elements to be sequential. This is typically used for service line numbers in X12, ensuring values like those in LX segments are sequential.

```APIDOC
x-openedi-loop-seq:
  type: integer
  description: |
    Denotes the segment within a repeating loop that needs to be checked for sequential numbers.
    The value is the position of the data element within the segment (e.g., 1 for the first data element).
  minimum: 1
  optional: true
```

--------------------------------

### Defining EDI Data Element Length Constraints in OpenAPI

Source: https://github.com/edination/openedi-specification/blob/main/README.md

This section explains how to apply minimum and maximum length constraints to EDI data element values within OpenAPI. The 'minLength' and 'maxLength' attributes are used directly on the property definition to enforce these constraints, ensuring data integrity according to EDI implementation guidelines.

```APIDOC
# OpenAPI attributes for minimum and/or maximum length:

# Use 'minLength' and 'maxLength' attributes on the property definition.

# Example OpenAPI property definition:
# type: string
# minLength: 1
# maxLength: 10
# x-openedi-element-id: "789"
```

--------------------------------

### Representing EDI Message as OpenAPI Schema Object

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Describes how to convert an EDI message into an OpenAPI Schema object, including required and optional extension properties for standard, version, and transaction set ID. These properties provide essential metadata for the EDI message.

```APIDOC
{
  "type": "object",
  "x-openedi-message-standard": {
    "type": "string",
    "description": "The EDI standard (e.g., X12, EDIFACT)"
  },
  "x-openedi-message-version": {
    "type": "string",
    "description": "The EDI version (e.g., 004010, D96A)"
  },
  "x-openedi-message-id": {
    "type": "string",
    "description": "The EDI transaction set ID (e.g., 850, ORDERS)"
  },
  "properties": {
    "ST": { "$ref": "#/components/schemas/STSegment" },
    "BHT": { "$ref": "#/components/schemas/BHTSegment" }
  },
  "required": [
    "x-openedi-message-standard",
    "x-openedi-message-id"
  ]
}
```

--------------------------------

### Representing EDI Codes as OpenAPI Enum Objects

Source: https://github.com/edination/openedi-specification/blob/main/README.md

This section describes how EDI Code properties, which represent a predefined list of allowed values for a data element, are converted into OpenAPI. They are modeled as 'enum' objects of type 'string' and referenced via an OpenAPI 'Reference' object, wrapped within an 'allOf' construct to combine the reference with the base string type.

```APIDOC
# OpenAPI representation for EDI Code properties:

# Data elements with EDI Code types are represented as a property
# of type 'string' with a 'Reference' object to the underlying
# EDI Code type, wrapped up in OpenAPI 'allOf'.

# Example OpenAPI property definition:
# type: string
# allOf:
#   - $ref: '#/components/schemas/EDICodeType'
# x-openedi-element-id: "456"

# Example of a referenced EDI Code Type schema:
# components:
#   schemas:
#     EDICodeType:
#       type: string
#       enum:
#         - "CODE1"
#         - "CODE2"
#         - "CODE3"
#       description: "Description of the EDI Code Type"
```

--------------------------------

### OpenAPI Schema Structure for EDI Composite Data Element Conversion

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Conceptual OpenAPI Schema object structure for representing an EDI Composite Data Element. It applies the same conversion principles as EDI Segments, utilizing string types, reference objects, arrays for repetitions, and the `x-openedi-composite-id` extension.

```APIDOC
# Conceptual OpenAPI Schema for an EDI Composite Data Element
type: object
x-openedi-composite-id: <Composite Data Element ID>
description: Optional description for the EDI Composite Data Element
properties:
  # Non-repeatable simple data element
  <simple_data_element_id>:
    type: string
    description: Optional description for the simple data element
  # Non-repeatable composite data element (if a composite contains another composite)
  <nested_composite_data_element_id>:
    $ref: '#/components/schemas/<NestedCompositeDataElementSchemaName>'
    description: Optional description for the nested composite data element
  # Repeatable simple data element
  <repeatable_simple_data_element_id>:
    type: array
    minItems: <min_repetitions>
    maxItems: <max_repetitions>
    items:
      type: string
    description: Optional description for the repeatable simple data element
  # Repeatable composite data element (if a composite contains repeatable nested composites)
  <repeatable_nested_composite_data_element_id>:
    type: array
    minItems: <min_repetitions>
    maxItems: <max_repetitions>
    items:
      $ref: '#/components/schemas/<NestedCompositeDataElementSchemaName>'
    description: Optional description for the repeatable nested composite data element
```

--------------------------------

### Mapping EDI Primitive Data Types to OpenAPI Formats

Source: https://github.com/edination/openedi-specification/blob/main/README.md

This section details the conversion of EDI data elements with primitive data types (not EDI Codes) into OpenAPI properties. It specifies the 'format' attribute values to be used for both X12 and EDIFACT standards, ensuring accurate representation of alphanumeric, numeric, date, time, and decimal types.

```APIDOC
# OpenAPI 'format' attribute values for primitive EDI data types:

# For X12 Standard:
#   X12_AN: X12 alphanumeric
#   X12_NX: X12 numeric with implied decimal (X can be 0-7)
#   X12_DT: X12 date
#   X12_TM: X12 time
#   X12_RX: X12 decimal (X is digits to the right of decimal, 0-7)

# For EDIFACT Standard:
#   EDIFACT_AN: EDIFACT alphanumeric
#   EDIFACT_A: EDIFACT alphabetic
#   EDIFACT_N: EDIFACT numeric

# Example OpenAPI property definition:
# type: string
# format: X12_AN
# x-openedi-element-id: "123"
```

--------------------------------

### Defining Mandatory EDI Segments/Loops in OpenAPI

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Illustrates how to mark an EDI segment or loop as mandatory within an OpenAPI Schema object. This is achieved by listing the property name in the `required` array of the parent schema.

```APIDOC
{
  "type": "object",
  "properties": {
    "mandatorySegment": { "$ref": "#/components/schemas/MandatorySegment" },
    "optionalSegment": { "$ref": "#/components/schemas/OptionalSegment" }
  },
  "required": [
    "mandatorySegment"
  ]
}
```

--------------------------------

### Representing EDI Loop as OpenAPI Schema Object

Source: https://github.com/edination/openedi-specification/blob/main/README.md

Details how to represent an EDI Loop as an OpenAPI Schema object, using the `x-openedi-loop-id` extension property to specify the Loop ID. If no explicit Loop ID exists, the ID of the trigger segment is used.

```APIDOC
{
  "type": "object",
  "x-openedi-loop-id": {
    "type": "string",
    "description": "The ID of the EDI loop (e.g., '2000A')"
  },
  "properties": {
    "HL": { "$ref": "#/components/schemas/HLSegment" },
    "NM1": { "$ref": "#/components/schemas/NM1Segment" }
  }
}
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.