X12 Logo

Compliance in X12

JANUARY 2023

Copyright © 2009-2023, X12, Format © 2009-2023 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner.

All rights reserved.

Intellectual Property
X12 holds the copyright on the Standards and associated publications designed to facilitate implementation of the Standards. Users of all X12 publications should be aware of the permissible uses, as well as the limitations on such usage, as outlined here: store.x12.org/store/ip-use.

R - Required

This item must be present in all data transactions. In the opinion of the implementation guide designers it is essential for this business use of the transaction set. Required may be used to identify Mandatory data when the implementation guide designers want to use a consistent designator for all data which must be present in all data transactions.

S - Situational

This item's usage depends on an associated business rule which is specified in the implementation guide and which clearly and unambiguously states the requirement designation under each anticipated condition.

X - Not Used

This item is not used in a data transaction - used to indicate data which must not be present in a data transaction.

 

The following rules apply for relating X12 Standard Requirements Designators to Implementation Guide Usage Designators:

  1. A Mandatory item must be Required; it must not be converted to any other usage designator value.

  2. An Optional item may be converted to Required, Situational, or Not Used.

  3. An Optional item may be converted to Situational only if an additional business rule is provided to describe the conditions for use within the implementation guide.

  4. A Conditional item may be converted to Required, Situational, or Not Used, provided that the original syntax rule is not violated; for example, two conditional elements, linked by an exclusive syntax rule (i.e. E0304) may be converted into Required and Not Used respectively (or vice versa).

  5. If a segment is Required, then at least one of the elements within the segment must also be Required, the subject of an 'R' Required syntax rule, or the subject of a situational rule that has the effect of requiring at least one of the elements to be present.

  6. If a composite is Required, then at least one of the elements within the composite must also be Required, the subject of an 'R' Required syntax rule, or the subject of a situational rule that has the effect of requiring at least one of the elements to be present.

Preface

General

This document is a Guideline. It was developed by ASC X12C[1], the Communications and Controls subcommittee.

This Guideline was prepared under the guidance of the Accredited Standards Committee (ASC) X12. Organized under the procedures of the American National Standards Institute, ASC X12 was charged with the development of transactions and structures for use in an Electronic Data Interchange (EDI) environment.

ASC X12 has the following subcommittees:

  • ASC X12C Communications and Controls

  • ASC X12F Finance

  • ASC X12G Government

  • ASC X12I Transportation

  • ASC X12J Technical Assessment

  • ASC X12M Supply Chain

  • ASC X12N Insurance

In developing X12 Guidelines, it is the aim of the ASC X12 subcommittees to facilitate the use and understanding of the standards developed by ASC X12. These Guidelines present information which is intended to assist the user with implementation of the standards.

Version and Release

This Reference Model is not based on or dependent on any particular version of the X12 Standards referenced; information is useful for applications ".....regardless of which version/release of the standards or the defining documents for the X12 syntax (X12.5 and X12.6) is being used."

Referenced and Related Standards

This standard is used with the ASC X12 series of standards on electronic data interchange.

The following material is from The Internet Engineering Task Force (IETF®). The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.

The following verbatim text is from the cited document as noted immediately below.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

Key words for use in RFCs to Indicate Requirement Levels

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Note that the force of these words is modified by the requirement level of the document in which they are used.

  1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

  2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

  3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

  4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

  5. MAY   This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

Comments

Suggestions for improvements to this document are welcome. They may be submitted at http://changerequest.x12.org.


[1] Within this Guideline, "ASC X12" refers to Accredited Standards Committee X12 and its subcommittees. "X12" labels the standards and other work products of ASC X12.

1. Purpose and Scope

This Guideline addresses the question of being in compliance with X12 EDI standards and is not intended to address any other standards. X12 Interactive EDI Standards that use ISO 9735 syntax are not addressed here. This Guideline is intended to provide a definition of compliance at least as far as X12 syntax and semantic issues are concerned, to be used in resolving conflicts, since that is clearly within the purview of X12. The document is intended to serve these major purposes:

  1. To disseminate information and define nomenclature related to the concept of compliance within X12.

  2. To provide guidance for determining whether data complies with the X12 standards.

  3. To provide guidance for determining whether an X12 Technical Report Type 3 or an industry implementation guideline (both hereinafter called implementation guides) complies with the X12 standards.

  4. To provide guidance for determining whether data complies with an implementation guide.

  5. To provide a complete set of rules by which syntactical compliance can be determined.

  6. To provide a minimum set of rules by which semantic compliance can be measured.

Compliance can be determined for any given data or implementation guide within a specified version and release of the transaction set, any related dictionaries, and the appropriate control documents.

This document addresses compliance with the X12 EDI standards, which for the purposes of this document are composed of:

  • X12.6 Application Control Structure

  • X12.59 Implementation of EDI Structures - Semantic Impact

2. Introduction

For the purposes of this Guideline, "compliance" means to be in agreement with the rules. "ASC X12" provides the rules, which are the X12 or American National Standards developed and approved by Accredited Standards Committee X12. The standards documents have sections which are marked for information purposes which are not officially part of the standard, and thereby not part of the "rules" considered in this Guideline. American National Standards Institute rules specify that footnotes, appendices, and the forewords are informative only and not part of the standard. It is important to note that these standards are voluntary standards although government agencies may mandate their use. The practice of further defining the standards and restricting options within the standards through implementation guides is where there is potential for confusion on what is really the standard and what is compliance.

It should be noted that there are two distinct areas of compliance: compliance of an implementation guide against its underlying standard; and compliance of a data transaction against an implementation guide and the underlying standard. Different criteria are used in the assessment of compliance in these two areas. This Guideline is concerned with both areas of compliance.

It should also be noted that there may be multiple levels of implementation guides. That is, there may be an implementation guide that refines and restricts a standard for use within a particular industry sector, but which requires a further restriction level in order to arrive at a final specification that could be used between trading partners. A guide containing further restrictions is often called an industry guideline or industry convention. The criteria for determining compliance for multiple levels of implementation guides are the same and this Guideline uses the term implementation guide to include all levels.

ASC X12 does not conduct compliance testing, although this service for both implementation guides and data messages is offered by independent firms. However, simply following this Guideline does not guarantee interoperability between systems. Interoperability means that two systems will be able to successfully transfer data. It is also possible that two systems may be interoperable and yet not be in compliance with X12 standards and/or implementation guides.

Finally, this Guideline is intended to augment, not replace, the appropriate X12 standards.

For the purpose of reviewing compliance, the version and release of the standards (or draft standards for trial use) is important. The changes that constitute a version and release will likely affect compliance. There is no assurance of either upward or downward compatibility between different versions and releases.

Notice that compliance is not addressed from any particular business perspective, except as allowed for by semantically based constraints. The X12 EDI standard specifies formats for the transmission of data between two points. It is unable to address any question of compliance with business methods or objectives. Compliance is an issue that determines whether the data can be successfully exchanged, and in some large measure whether it is internally consistent; it is not capable of addressing business purposes which remain an application task.

3. Definitions

3.1 Semantics

X12.59 Implementation of EDI Structures-Semantic Impact defines the term “semantics” as pertaining to the meaning of the information contained within a data structure, independent of the structure itself, such that the conversion from one structure to another would not change the meaning of the data.

The word 'semantics' is used to cover the meanings of the data transferred and the relationships between the data items that together build a complete transaction. Some semantic guidelines are provided in semantic notes within the X12 standards.

As a rule, semantic information is not directly conveyed in X12, nor is it carried in the component structures of the transaction sets, segments and elements. It is impossible within this Guideline to address questions such as the suitability of a particular series of components for conveying a function within a business transaction, or whether the data is conveyed with a sufficient precision for the application processes.

3.2 Syntax

Syntax is the set of rules for organizing data into a structure for electronic exchange.

This includes establishing the method of encoding a piece of data by its attributes and identifying that data in the transfer. The allowable attributes for the data determine how that data is represented in the transfer. The identification of the data can be done by physical positioning and/or by tags or labels for that data.

3.3 Interchange

Interchange is the actual transfer of the data between trading partners. As an analogy to paper-based information flows, the interchange is the envelope and its contents. The envelope is used by the post office. This requires information such as names or addresses for delivery. The envelope may also contain additional information concerning content, acknowledgements, and controls. There may be ancillary information or requests for additional services for timed delivery, copies, priority, etc.

4. Data Compliance With X12 EDI Standards

Compliance is defined as conformance with all the rules, and this Guideline defines the rules in conjunction with the X12 EDI standards. This means that compliance is based on these standards. According to ASC X12 policies and procedures and for the purposes of this document, the X12 EDI standards are X12.6 Application Control Structure, and X12.59 Implementation of EDI Structures - Semantic Impact. Implementation Guides published by ASC X12, referred to as Type 3 Technical Reports in ASC X12 policies and procedures, are not EDI standards.

4.1 Semantics

The business perspective of semantics is usually handled by the appropriate data processing application, although it is often found that semantic conditions such as dependent ranges of data values or code lists are specified as part of an implementation guide. From a business perspective, there are a number of considerations from either a compliance or a business aspect that need to be evaluated. Some of these are listed below.

  • Is the information sufficiently complete to conduct the business transaction?

  • Is the data accurate and at sufficient precision?

  • What are the common business practices and how are these translated into the EDI environment?

  • What information must be available to generate a business transaction?

  • What information can be expected from the receipt of a transaction set?

While it is impossible within this Guideline to address questions such as these, there are some areas in the X12 standards that directly impact semantics. Some of these are listed below:

  • The purpose and scope of each transaction set standard establishes the use of that transaction set.

  • Data segments within transaction sets and data elements within data segments have an order as established by the appropriate standards. Semantics may be associated with position within that order.

  • Some information provided by the sender may be ignored by the receiver if it is not necessary to complete the business transaction.

  • The data element definition within the data element dictionary establishes the meaning of the information represented by the data element. A code value in a data element may provide further semantics to other data elements, segments, or loops.

  • X12.59 describes rules for precedence between data used in different sections of a transaction set. This allows a transaction set to carry one set of data for one purpose (for example, a delivery address) in the header section which may be overridden when a different set of data for the same purpose is provided for an item in the detail section.

  • Notes at the transaction set level may be semantic notes and must be considered part of the measure of compliance, even if they cannot be measured or enforced mechanically.

4.2 Syntax

The following is a list of components of the ASC X12 standards that are required for syntax compliance. The data elements within the control segments must follow the syntax rules defined in the X12 standards.

  • The control number in the functional group header segment must match the corresponding data element in the functional group trailer segment.

  • The control number in the transaction set header segment must match the corresponding data element in the transaction set trailer segment.

  • A mandatory data element in the functional group trailer segment provides a count of the included transaction sets.

  • A mandatory data element in the transaction set trailer segment provides a count of the included segments.

  • The value used in the functional ID data element limits the type of transaction sets that may appear in that functional group.

  • The version and release data element in the functional group header specifies the only allowable version and release of the transaction sets and related dictionary which may be used for the exchange of information in that functional group.

  • The order of the data segments in a transaction set is established by the table and position number within the transaction set standard. The segments must appear in this order[2].

  • The table and loop are the only syntactic mechanisms to group segments together within a transaction set.

  • The number of occurrences of a segment or loop must not exceed the maximum number allowable occurrences specified in the transaction set standard.

  • The requirement designator for each data segment is specified in the transaction set standards and must be used as specified. A mandatory segment not in a loop must be present. A mandatory segment in a mandatory loop must be present. A mandatory segment in an optional loop must be present if the loop is present. A receiver must be able to accept any data segment in the transaction set.

  • If any segment in the loop appears, the first segment in the loop must appear. This first segment provides the marker for the instance of the loop.

  • The requirement designator for the first segment of the loop specifies the requirement designator for the loop as a whole. The requirement designators for the data segments within a loop only apply for the occurrences within the loop.

  • If the transaction set specifies the LS and LE segments to bound the loop, and if any segment in the loop appears, the LS and LE segments must appear. There is only one LS and LE segment for all of the successive repeat of the loop. The LS and LE segments bind multiple iterations of the contained bounded loop.

  • The position of data elements is set by the definition of the data segment, and the data elements must appear in the defined sequence.

  • The requirement designators for the data elements are specified in the segment directory standard and must be used as specified.

    • Mandatory means the data element is required.

    • An optional data element is generated at the discretion of the sender.

    • A conditional data element is established by the syntax note that specifies the conditions for the appearance of the data element.

  • The data segment ID is a label for the data segment and is not a data element. The data segment ID must appear as it does in the standard as to length and character representation.

  • Each data element has a length attribute that specifies the minimum and maximum length of a data element value. The Application Control Structure (X12.6) specifies, by data element type, the allowable characters and which characters are included in the length count (not all characters are counted in certain data element types).

  • Each data element has a type attribute. X12.6 specifies the allowable characters that shall be used to represent a value for each data element type. That standard also specifies the blank or zero filling for each data element type, if that is required in use.

  • The ID data element type mandates that a value may be selected only from the list of codes for that data element.

  • The allowable character set is specified in X12.6. This character set is specified in terms of the graphic representation and assumes no particular binary representation or collating sequence.

  • The delimiters are established for a particular interchange by the interchange header. The characters chosen for the delimiters shall not be used in a data element between the interchange header and the corresponding interchange trailer.


[2] In versions prior to 003070, the standards included floating segments which could appear at any point in the segment sequence order, after the beginning segment and before the SE segment. Floating segments were withdrawn from the standards in version 003070.

5. Implementation Guide Compliance with X12 EDI Standards

Implementation guides provide instruction in the use of an X12 standard. The standard messages are typically not implemented in full by any trading partners. Trading partners may agree to exchange messages based on a particular implementation guide. Implementation guides may be based on a current or past X12 standard.

This section describes operations that implementation guides may use to further define or restrict individual aspects of an underlying X12 standard transaction set.

Definition: Subset operations restrict the data to be conveyed in the transaction set within the boundaries set by the original standard.

An implementation guide may contain only subset operations. An instance message compliant with an implementation guide containing only subset operations will be fully compliant with its underlying standard.

5.1 Sequencing

An implementation guide may not alter any of the position numbers for the various loops, segments, composites and data elements in a transaction set.

Loops or segments that are used for different purposes in the same position may appear multiple times in the implementation guide as long as the number of repeats is allowed by the standard (see Section 5.6 - Repeat Counts). Each instance shall have the same position number(s).

Floating segments are allowed to appear at any point in a transaction set where permitted by the standard, but are always published in the standard as having a particular position number. An implementation guide must preserve that position number, and may not introduce extra position numbers to arbitrarily 'place' a floating segment. Floating segments were withdrawn from the standards in version 3070. Floating segments are now disallowed for insertion into any existing or new transaction sets and discouraged for use or implementation in older transaction sets.

5.2 Usage Designators

These values have been defined to further describe data usage in implementation guides. Implementation guide designers may, but are not required to, use any or all of these additional values to supplement the requirements designators defined in the transaction set. These additional values are detailed with their meanings below:

5.3 Data Element Types

X12 contains a number of different data element types. These may be restricted by an implementation guide as follows:

  1. An 'AN' element may be effectively converted to either 'N', 'R', or 'ID'.

  2. An 'R' element may be effectively converted to 'N'.

5.4 Data Element Lengths

X12 allows data elements to be of fixed or variable length, by specifying a minimum and maximum length. An implementation guide may restrict the length of an element in an implementation guide by varying the minimum and maximum length provided that the maximum stays larger than or equal to the minimum, and that both stay within the bounds set by the original values in the standard.

Additionally, an implementation guide may convert a variable length string to a fixed length string by making the minimum and maximum lengths the same, provided that that value is within the bounds set by the original values in the standard.

5.5 Coded Elements

For a coded element that is marked as used within an implementation guide (i.e. having a requirement designator which is other than 'Not Used'), in the absence of any other specifications any code from the list is valid. Alternatively, at least one valid code value from the named code list may be specified, or the value of the element may be specified as a value code (i.e. the code is an algorithmically or cryptographically produced value).

While compliant code values for each version of X12 are documented in the published standard, new emerging business requirements often necessitate that trading partners exchange code values that are published in versions of the X12 standard other than what is specified in the GS08 of the transmission. X12 recognizes that this business requirement is met by specifying those codes in an industry-approved implementation guide or by mutual trading partner agreement prior to use.

Code lists specified for use in a particular data element in an implementation guide must be noted as either external or internal.

5.5.1 Internal

If internal, then the code values must be drawn from the list of codes specified for that element in the standard and from the same version of the X12 Standard on which the implementation guide is based. The implementation guide must contain the individual code values and descriptions exactly as published in the X12 Standard.

5.5.2 External

If external, then the code values must be taken from one or more of the external code lists specified for that element. If the standard specifies a version of the external code list, the implementation guide must specify the same version as in the standard. If the standard does not specify a version of the code list, the implementation guide may specify a version of the code list.

5.6 Repeat Counts

Repeat counts in an implementation guide for data elements, segments and loops must be within the ranges specified in the standard. An implementation guide may not specify a value which exceeds the maximum repeat count, or falls below a minimum repeat count.

The standard uses the expression '>1' to specify that a segment or loop may occur any number of times. This is generally coupled with Optional as the requirement designator, allowing the implementation guide to set a more specific repeat count. The following rules apply when implementation guides set more specific repeat counts:

  1. Implementation guides can set a specific repeat count, a minimum repeat count, a maximum repeat count or both a minimum and a maximum repeat count. Valid repeat counts include '1' meaning that exactly one instance is required, 'min 3' meaning that at least 3 instances are required, 'max 10' meaning that no more than 10 instances are allowed, or 'min 2, max 4' meaning that 2, 3 or 4 instances are allowed.

  2. Normal arithmetic conventions may be used to express the repeat counts, so that '≤ 10' means 'max 10' and so on.

  3. The requirement designator and the repeat count must be consistent, so that the following sub-rules apply:

    1. If the repeat count specifies either a minimum or an explicit value greater than zero then the requirement designator must not be Not Used; conversely, if the requirement designator is any requirement designator other than Not Used, then an explicit non-zero minimum or range must be present.

    2. If the repeat count specifies a range, then any requirement designator other than Not Used may be used.

    3. If the requirement designator is Not Used then the repeat count must be zero.

5.7 Default Values

A default value is the value a receiver should assume for a data element if the element is empty in a data stream, or if the segment containing the data element is omitted from the data stream. An implementation guide may specify a default value for any data element. The following rules apply to default values:

  1. When a default value is used, its value must be specified in the implementation guide.

  2. The value must match its host data element in both data type and length (i.e., the default value must fit in the data element, and be of the right type).

  3. For a coded data element, the default value must not only be a value specified in the applicable code list, but must also be a permitted value within the implementation guide.

  4. For a non-coded data element, the default value must fall within any value criteria applied in the implementation guide for that data element.

  5. Implementation guides may only specify a single default value.

5.8 Syntax Rules

Usage of data elements in an implementation guide must comply with the syntax rules specified in the standard.

Additional syntax rules may be specified by the implementation guide, but they must not contradict or conflict with those in the standard. If additional syntax rules have been added by an implementation guide, then the data element usage must comply with both the syntax rules in the standard and those added by the implementation guide.

5.9 Value Criteria

An implementation guide is likely to impose value criteria for non-coded data elements. These may be in the form of patterns, specific values, ranges or a combination of one or more of all these. Where value criteria are specified, then the following rules apply:

  1. In the case of a pattern, although the characters used in the pattern itself may not match the data element's character type and the length of the pattern may well exceed the size of the data element itself, any resultant data value must match both the type and the size of the data element.

  2. In the case of a specific value, the value itself must match both the type and the size of the data element.

  3. In the case of a range, then both the upper and lower values must match both the type and the size of the data element.

5.10 Loop IDs

The X12 Standards publish a Loop ID for each loop in any transaction set. This Loop ID is commonly either the Segment ID of the first segment of an unbounded loop, or a numeric value. The earliest versions of the standard did not specifically annotate the electronic distribution form of the standards with this information. These Loop IDs can be used by compliance and translation software to synchronize implementation guides and their underlying standard.

If the loop ID in the standard is non-numeric, an implementation guide may specify an appropriate numeric value. An implementation guide may also append a suffix to the Loop ID to distinguish different loop instances.

6. Data Compliance with Implementation Guides

In general, data compliance with an implementation guide falls within the requirements for data compliance already outlined for the X12 Standards themselves. An implementation guide that is compliant with the underlying standard can only further restrict the characteristics of data carried. However, certain extra burdens are imposed on data compliance as a result of extra properties and characteristics that an implementation guide can define while still remaining within the original X12 standard.

6.1 Sequencing

Data must be presented in the X12 ordered sequence outlined in both the X12 standard and the implementation guide. Although the implementation guide may vary the presentation order of the loops, segments and elements in the EDI data stream must always be constructed in X12 ordered sequence allowing for normal loop structures.

If optional loops or segments are not used, then they are simply not present in the data stream, and the subsequent segments follow on in X12 ordered sequence.

If the implementation guide explicitly specifies an order, the loops in the data stream must comply with that order. If the implementation guide does not specify an order, iterations of a loop with the same position number may be transmitted in any order at that position in the data stream. The subordinate elements must occur in the order specified in the implementation guide for each loop instance.

If the implementation guide explicitly specifies an order, the repeated segments in the data stream must comply with that order. If the implementation guide does not specify an order, repeated segments may be transmitted in any order at that position in the data stream.

If the implementation guide explicitly specifies an order, the repeating elements in the data stream must comply with that order. If the implementation guide does not specify an order, repeating elements with the same position number may be transmitted in any order at that position in the data stream.

Floating segments were withdrawn from the standards in version 3070. For transaction sets of previous versions, floating segments are allowed to appear at any point in the data stream between the ST and SE segments, unless otherwise specified in the implementation guide.

6.2 Requirement Designators

The presence of data must comply with the full set of requirement designators outlined in Section 5.2 - Usage Designators above.

Note that the receiver may not be able to determine solely from the transmitted data stream whether a situational item was actually populated in compliance with the business rule specified in the implementation guide. That is, the business rule may depend on data that is not transmitted.

6.3 Data Element Types

The characters used to represent each element must comply with the fully restricted representation as specified in the implementation guide.

6.4 Data Element Lengths

The length of each data value must comply with the fully restricted length as specified in the implementation guide.

6.5 Coded Elements

Data present in a coded element must be one of the values listed in the implementation guide. If there are no values listed, than all of the code values in the X12 standard are acceptable. For an external code list, the values must be present on the external list. If the X12 standard or the implementation guide specifies a version of the external list, the data must be one of the values in the specified version. If neither the standard nor the implementation guide specifies a version of the external list, the data must be one of the values in the version of the external list that is agreed to by the trading partners. Data values for an element that is defined as a value list may take any value which uses valid X12 characters. Coded elements must comply with the full set of requirements outlined in Section 5.5 - Coded Elements.

6.6 Repeat Counts

The count of repeating segments, loops and elements must fall within the range specified in the implementation guide.

6.7 Default Values

Default values may be applied by the receiver, when the element is empty in the data stream and the implementation guide specifies a default value.

6.8 Semantic Rules

The data stream must comply with the semantic rules specified in both the standard and the implementation guide.

6.9 Syntax Rules

The data stream must comply with the syntax rules specified in both the standard and the implementation guide.

6.10 Value Criteria

A data value for a non-coded data element must match any value criteria imposed by the implementation guide:

  1. Where a data pattern has been specified, the characters must match the pattern itself; if several patterns have been specified, then the data must match at least one pattern.

  2. In the case of specific values, the data value itself must match one of the values specified.

  3. In the case of ranges, then the data value must fall between both the upper and lower values of at least one range.