Requirements for Use of X12 Products in Artifacts including

X12 Ownership

All Artifacts must identify the X12 organization and its copyright in the applicable X12 Products, and include the following statement (or a substantially similar statement) in a reasonably prominent and fixed manner:

This document contains or references the X12 Standard and/or other proprietary materials of X12, Inc. (X12) and/or its licensors, including Washington Publishing Company (WPC) identified below (collectively, the “X12 Materials”). The X12 Materials are protected by copyright and are reproduced in this document with express permission from X12. ALL RIGHTS RESERVED TO X12 AND ITS LICENSORS. You may not extract, copy, reproduce, distribute, transmit or otherwise use the X12 Materials, in any form or by any means (including via photocopy, printing, email, download, upload, AI prompt, or digital storage system), without a license or other written permission from X12. For information on obtaining a license to the X12 Materials, please visit x12.org or contact ip@x12.org.

No Replication

Artifacts may not replicate the information presented in X12 Product, including by containing material duplication of a section of or other exact quotation from, the associated X12 Product, unless otherwise permitted by law (for de minimis amounts) or X12’s express written permission has been granted and, in each case, the Artifact includes the citations required in the following section.

X12 Product Controls

All Artifacts may not contradict or countermand any requirement of the associated X12 Product, and must conform to all requirements of the associated X12 Product and also include a disclaimer that the X12 Product retains ultimate authority over the requirements of the transmission.

Example: Every effort has been made by [ORGANIZATION NAME] to ensure consistency between this document and the [Full Title of X12 Product(s)]. However, if there is a discrepancy between the documents, the X12 Product is the final authority.

No Tutorials

Artifacts may not include tutorial information about X12 syntax, the underlying transaction set or related transaction sets, or the use or interpretation of any X12 Product. Artifacts must be used in conjunction with an associated X12 Product. Artifacts may not be stand-alone requirements documents or otherwise replace the need to reference or utilize the associated X12 Product.

• Add, modify or delete any requirements, including loop, segment or element names, notes or rules, examples, appendix, or code list subsets from the Implementation Guide.
• Use the unique identifier listed in GS08 unless the transaction conforms to the requirements documented in the associated Implementation Guide, within the parameters of the Compliance in X12 Guideline document.
• Add, modify or disallow any defining, explanatory, or clarifying content, example or Appendix within any associated Implementation Guide.

Citation to All X12 Products

All Artifacts must identify all X12 Products incorporated, quoted, cited, referenced or used in the Artifact or upon which the Artifact is otherwise based, and comply with the following citation requirements: 

• Citations must be used each time an X12 Product is quoted, referenced, used or otherwise relied upon, but may be placed in-line with text (or directly below a cited figure), in footnotes, or in a works-cited list in the Artifact.
   
• Exact quotes or citations from an X12 Product must also be clearly distinguished from other text, materials or commentary that may appear alongside or discuss such X12 Product.
   
• Include a full citation, using the below format, at the first reference to each X12 Product. You may thereafter use a shortened citation of either the unique identifier or full title of the X12 Product.
  
  X12, Inc. “Full name of X12 Segment/Section, Figure number [if applicable], [Segment ID [if applicable]." Full title of X12 Product (Transaction Set ID), Unique Identifier. Date of publication. <http://www.x12.org>. Page Number(s) [if applicable].
   
• Example:
  
  Full: X12, Inc. "1.4.1 Information Flows, Fig. 1.1." Health Care Claim Payment/Advice (835), 006020X258. June 2012. <http://www.x12.org>. 3.
  
  Short: 006020X258 or “Health Care Claim Payment/Advice” 

Your Information

Companion Guides may include your proprietary information or instructions that clarify the applicable Implementation Guide’s instructions for specific trading partners.

• You may also clarify an X12-provided example, based on your proprietary information or instructions. You may also [add examples specific to your proprietary information or instructions so long as they do not modify or disallow the X-12 provided example.

Trading Partner Instructions

Companion Guides may include information from X12 Requests for Interpretation (RFIs) as a reference for trading partner specific instructions, as long as you include a citation to the RFI as required in the above section.

• You may also identify trading partner information necessary to initiate or enable the communications between trading partners.
  
  Example: "GS02 – send your TPID in this element".

Repetitions

Companion Guides may indicate the number of repetitions which are allowed in your proprietary implementation or will otherwise be applied in the transaction processing application for loops or segments without repetition limitations in the Implementation Guide.

Processing Intentions

Companion Guides may clarify your specific processing intentions related to Implementation Guide requirements. Codes allowed in the Implementation Guide must be accepted if transmitted; however, you may note if one or more codes from the Implementation Guide’s code list are preferred or not processed.

• "Preferred" means that your internal processes require a specific value, it does not mean the transaction can be rejected if the specified code is not transmitted.
• "Not processed" means the code will not be recognized in your internal processing, it does not mean the transaction can be rejected if the code is transmitted.

Situational Rules

Companion Guides may clarify the use of loops/segments/elements identified in the Implementation Guide by including situational rules stating that trading partner requirements control usage:

Examples of such situational rules:

• "Required when the payer's adjudication is known to be impacted"
• "Required when such transmission is required under the insurance contract"