X12 Administrative Policy and Procedure. External Code Lists (CAP12)

(1)

X12 Administrative Policy and Procedure

External Code Lists

(CAP12)

(2)

X12 ADMINISTRATIVE POLICY AND PROCEDURE CAP12v6

Table of Contents

External Code Lists ...4

1 Introduction...4

2 Authority ...4

3 Background ...4

4 External Code List Oversight Subcommittee ...5

4.1 ECO Mission ...5

4.2 ECO Structure ...5

4.3 ECO Constituents ...5

4.3.1 Appointed Constituents ...6

4.4 ECO Constituent Privileges ...6

4.5 Maintaining Constituent Status ...6

4.6 ECO Roles ...6

4.6.1 ECO Chair ...6

4.6.2 Subcommittee Internal Liaisons ...7

4.7 ECO Responsibilities ...7

4.8 The ECO as a Code Maintenance Group ...8

5 Establishing an External Code List ...8

6 Standing up an External Code List ...9

6.1 Identifying and Describing the ECL ...9

6.2 Defining the ECL Attributes ... 10

6.3 Assigning Maintenance Responsibility ... 10

7 ECL Guiding Policies ... 11

7.1 ECL List Attributes ... 12

7.2 ECL Grammar Rules for Descriptions ... 12

7.3 ECL Terminology for Descriptions ... 13

8 Maintenance Request Processing ... 13

9 CMG Operating Methodologies ... 14

9.1 Defined Representative Voting Panel ... 14

9.2 Material Interest Voting Panel ... 15

9.3 X12 Member Voting Panel ... 16

10 Establishing Code Maintenance Groups ... 17

11 Code Maintenance Groups... 18

11.1 CMG Responsibilities ... 18

(3)

11.2 CMG Roles ... 19

11.3 CMG Constituents... 20

11.3.1 Appointed Constituents ... 20

11.4 CMG Observers ... 20

11.5 CMG Charter ... 21

11.6 Sustaining Code Maintenance Groups ... 21

12 X12 Staff Responsibilities ... 22

13 X12 Terminology ... 22

14 Document History ... 22

External Code List Attributes Appendix ... 23

(4)

External Code Lists 1 Introduction

The X12 Board of Directors (Board) is responsible for this policy and the associated

procedures. X12 members agree to adhere to X12’s policies and procedures as a condition of membership. Non-member participants afforded specific collaboration privileges agree to adhere to X12’s policies and procedures as a condition of those privileges. Any party may submit a revision suggestion at x12.org/maintenance-requests.

2 Authority

X12 maintains corporate rules which define overall corporate policies and procedures. X12 committees are required to establish a committee operating manual and are generally permitted to establish other committee-level rules that apply only to that committee. In some cases, corporate policy is intended to stand-alone and lower-level rules are prohibited. A committee’s subordinate groups may be required or permitted to establish group-specific rules that supplement the committee rules except when lower-level rules are prohibited. All

supplemental rules shall provide more detail or be more restrictive than the higher-level governance. Supplemental rules are not permitted to duplicate, contradict, countermand, supersede, or overrule any higher-level rules. No accommodation is intended or provided to permit a committee or subordinate rule to override a higher-level rule with a more permissive requirement. In the case of any inconsistency between the corporate, committee, and

subordinate group rules, the higher-level governance shall always prevail.

X12’s primary organizational policies are established in the X12 Bylaws (CAP01). The governance established herein supplements the X12 Bylaws and may be augmented by supplemental rules as described above only when explicitly permitted herein.

3 Background

A code list is a set of codes with associated descriptions used to enable efficient, effective, and consistent communication between trading partners.

In many cases, X12 establishes and maintains a specific code list as part of the EDI Standard, each such list is referenced as an “internal code list”. These internal code lists are maintained by the Accredited Standards Committee (ASC). See the ASC’s Standards Development Manual (ASC02) for more information on internal code lists.

The EDI Standard also includes other code lists by reference; each such list is referenced as an “external code list”. External code lists are established and maintained outside of the X12 EDI Standard either by X12 itself or by other organizations, such as the United States Postal Service or the Regenstrief Institute. When X12 identifies that a code list requires frequent updates, a specific review and approval process, or meets other criteria, X12 designates the

(5)

code list as an external code list. Within this document, the term external code list (ECL) is specific to X12 maintained external code lists.

X12 external code lists are maintained within the External Code List Oversight (ECO) subcommittee of the Registered Standards Committee (RSC). Governance for the establishment, assignment, and maintenance of external code lists is described herein.

4 External Code List Oversight Subcommittee

The Board established the External Code List Oversight Subcommittee (ECO, pronounced echo) under the Registered Standards Committee. The ECO has responsibility for overseeing all aspects of maintenance for external code lists.

4.1 ECO Mission

See the External Code List Oversight Subcommittee Mission (RSC130).

4.2 ECO Structure

The ECO subcommittee establishes action groups, known specifically as code maintenance groups. Each code maintenance group (CMG) is responsible for maintaining one or more external code lists.

4.3 ECO Constituents

The ECO is open to any RSC stakeholder with a material interest in external code list oversight. Once an RSC stakeholder has met the specific requirements defined below, the stakeholder is entitled to be represented by one ECO constituent who represents their interests. As continuity is critical to the ECO’s work, alternates are neither intended nor accommodated.

The RSC stakeholder wishing to be represented on the ECO shall have one of their member representatives participate as an observer at an ECO session at two consecutive standing meetings. At the conclusion of the second standing meeting, the member representative who attended as an observer may submit the online request form found at x12.org/forms to request recognition as an ECO constituent.

After verifying the member representative meets the established criteria, the ECO chair shall present the statement of the member’s material interest in ECO activities to the ECO for consideration. Upon the ECO’s confirmation vote, the member

representative shall be recognized as an ECO constituent.

(6)

4.3.1 Appointed Constituents

Any time the ECO has fewer than five constituents, including the ECO chair, the RSC chair shall appoint additional constituents to ensure adequate representation. Appointees shall retain constituent status for one year unless the RSC chair specifies a different appointment period at the time of appointment. An appointee who meets the constituent

participation requirements during their appointment term is entitled to become a constituent in their own right at any time during the term.

4.4 ECO Constituent Privileges

In accordance with Section 4 of the RSC Operating Manual (RSC101), ECO constituent privileges include the right to vote, speak in meetings, participate in collaboration activities, and propose and second motions. Constituents may be eligible to hold elected or appointed offices within the ECO, based on the X12 member’s membership category in accordance with Membership (CAP04).

4.5 Maintaining Constituent Status

As continuity is very important to successful oversight, ECO constituents shall be required to participate in at least two of every three ECO meetings to maintain their constituent status. The ECO chair may excuse one or more absences based on a constituent’s medical or family circumstances. A constituent who fails to meet these requirements shall be considered to have resigned as an ECO constituent.

4.6 ECO Roles

Subcommittee roles, including qualifications and duties, are identified and governed by Section 11.2 of the RSC Operating Manual (RSC101). The ECO subcommittee utilizes two of the permitted roles.

4.6.1 ECO Chair

The ECO chair must possess certain skills and knowledge to successfully lead X12’s external code list activities. Therefore, in addition to the

qualifications called out in the RSC Operating Manual (RSC101), the ECO chair shall:

1. Have experience implementing or maintaining standardized codes, vocabulary, or terminology

2. Understand best practices for standardized codes, vocabularies, or terminologies

3. Be recognized as an industry expert or leader related to standardized codes, vocabularies, or terminologies 4. Have strong written and verbal communication skills

(7)

To ensure those requirements are met, the ECO chair is appointed by and serves at the pleasure of the RSC chair. Each appointment shall be for a two-year term, with no limit on the number of terms an individual is eligible to serve as the ECO chair.

If there is no member representative qualified and willing to serve as the ECO chair, the RSC chair may appoint a staff member as the ECO convener for an interim period until a qualified member representative is identified and appointed. A staff convener shall have all the authority of the ECO chair, except they shall not vote in ECO ballots.

In addition to the duties called out in the RSC Operating Manual (RSC101), the ECO chair shall have the following responsibilities.

1. Appointing code maintenance group chairs and constituents when CMGs are established, any time a CMG does not have a chair, and when a CMG does not have enough constituents to discharge their duties

2. Notifying staff of the establishment of a code maintenance group, the naming of any convener, the election of any chair, and any maintenance responsibility assignment or reassignment

3. Working with staff and code maintenance group chairs to ensure timely publication of external code lists

4.6.2 Subcommittee Internal Liaisons

External code lists may be especially significant to specific X12

committees or subcommittees. Accordingly, the ECO chair may designate an X12 committee or subcommittee officer as the group’s internal liaison to the ECO. The internal liaison shall provide information to the ECO as requested and shall communicate ECO positions and activities back to their group as appropriate. Internal liaisons shall not be recognized as ECO constituents. Internal liaisons shall have the right to speak in meetings and participate in collaboration activities but shall not have the right to vote, propose or second motions, or hold elected or appointed office within the ECO.

4.7 ECO Responsibilities

The ECO subcommittee shall have the following responsibilities.

1. Defining the initial statement of work for each CMG and any subsequent revision.

2. Ensuring a CMG publishes a charter within six months of establishment 3. Approving the initial charter for each CMG and any subsequent revision.

(8)

4. Ensuring a CMG’s activities align with the approved statement of work 5. Establishing metrics for monitoring CMG activities to ensure timely

maintenance and appropriate due process

6. Acting as the code maintenance group for an external code list when maintenance has not been, or cannot be, assigned to a specific code

maintenance group, see Section 4.8 The ECO as a Code Maintenance Group below.

4.8 The ECO as a Code Maintenance Group

Should it be necessary for the ECO to act as a code maintenance group, the ECO chair shall either act as the code maintenance group chair or name another ECO constituent to act as the code maintenance group chair. When functioning as a CMG, the ECO shall operate as a Defined Representative Voting Panel, with the ECO constituents as the defined voting panel.

5 Establishing an External Code List

Any X12 group, industry group, or organization may submit a proposal for the establishment of an external code list. The proposal may be to create a new standardized code list to meet a specific business need, or it may be to convert an existing code list currently managed by another entity into an X12 external code list. The X12 Board is responsible for reviewing each proposal for a new X12 external code list and deciding on the next step. The X12 Board bases its review and decision on the following process and criteria.

1. Any X12 group, industry group, or organization may submit a proposal for the

establishment of an external code list via the online request form found at x12.org/forms 2. If the proposal involves converting an existing code list to an external code list, the

proposal shall include one or more recommendations with business justification.

a. Whether the existing codes should be grandfathered into the external code list or new codes values should be assigned to the descriptions

b. Whether the existing code descriptions should be grandfathered into the external code list or the existing descriptions should be revised to align with the rules established in Section 7 ECL Guiding Policies below

3. Staff shall evaluate and investigate each proposal to provide the Board with necessary and relevant information. Once the evaluation and investigation activities are complete, staff shall present the proposal to the Board.

4. The Board shall consider all properly submitted proposals for the establishment of an external code list.

5. Consideration criteria shall include:

a. Submission of compelling evidence of a need for a consensus-based code list b. Submission of compelling evidence that the impacted trading partners will implement

the resultant code list

c. The existence of any equivalent or competing code list(s)

(9)

d. Start-up and ongoing costs compared to potential revenue e. Anticipated requirements for staff support

6. After considering a proposal, the board shall vote on the establishment of the proposed external code list.

a. If approved, the Board shall assign maintenance of the external code list to the External Code List Oversight (ECO) subcommittee and staff shall notify the ECO chair of the establishment and assignment.

b. If disapproved, the Board shall provide the basis of the disapproval.

7. Staff shall notify the submitter of the determination and any next steps.

6 Standing up an External Code List

When a new X12 external code list (ECL) is assigned to the ECO, the subcommittee shall review the submitted proposal and any additional information gathered before or during the Board’s assessment. Following the review, the ECO shall stand up the ECL as follows.

6.1 Identifying and Describing the ECL

The ECO chair shall request staff to assign a unique numeric identifier for the ECL.

The ECO shall approve a descriptive name and scope statement for each ECL. The ECO shall consider, but shall not be obligated to adopt, any previously used or recommended name or scope statement.

The descriptive name of the ECL shall adhere to the following norms.

1. The name shall be specific enough to provide a meaningful reference to the intended use of the codes on the list.

2. The name shall not represent an acronym, initials, or short-hand.

3. The name shall be grammatically correct.

4. The name shall be as short as possible to facilitate online display, footnoting, citations, and reporting.

5. The name shall support broad use within or across industries.

a. The name shall not explicitly reference an X12 transaction set or element.

b. The name shall not explicitly reference another organization’s standard.

6. Potential acronyms based on the name shall be carefully considered and inappropriate, offensive, and unfortunate acronyms shall be deliberately avoided.

The scope of each ECL shall adhere to the following norms.

1. The scope shall not reiterate or rephrase the ECL’s descriptive name.

2. The scope shall be grammatically correct.

3. The scope shall be succinct, meaningful, clear, and unambiguous.

4. The scope shall support broad use within or across industries.

a. The scope shall not explicitly reference a particular X12 transaction set or element.

(10)

b. The scope shall not explicitly reference another organization’s standard or standard component.

c. The scope shall not contain jargon or wording that is only meaningful to the experts or insiders of a particular industry.

6.2 Defining the ECL Attributes

The ECO shall define the ECL attributes, including but not limited to the following.

1. If the ECL was a functioning code list converted to an X12 ECL, the ECO shall consider, but shall not be obligated or constrained to, any grandfathering requests related to retention of the current codes or descriptions.

2. The operating methodology to be utilized for maintenance decisions. The operating methodology options are defined in Section 9 CMG Operating Methodologies below. One operating methodology shall be utilized for all maintenance activities for an ECL.

3. Whether extended descriptions shall be supported for the ECL.

4. The publication schedule for the ECL.

The ECL may revise these attributes at any time as necessary to ensure the ECL is effectively maintained and providing a substantial benefit to implementers. Revisions may be based on a Board recommendation, an ECO assessment, or a

recommendation from the assigned code maintenance group.

6.3 Assigning Maintenance Responsibility

As soon as it is feasible, the ECO shall assign a CMG with responsibility for the ECL’s maintenance based on the criteria established below. The ECO may reassign

maintenance responsibility for an external code list at any time; however, such a reassignment must be well-coordinated to ensure ongoing maintenance activities are not adversely impacted. Such reassignment may occur based on the request of the current CMG or at the discretion of the ECO.

1. Long-term assignment to an existing CMG, if all the following criteria are met.

a. The existing CMG’s operating methodology is the same as the operating methodology assigned for the ECL.

b. The existing CMG’s statement of work either accommodates the ECL’s scope or could be reasonably expanded to accommodate the ECL’s scope.

c. The existing CMG’s constituents have the knowledge, skill set, or experience to effectively evaluate maintenance requests and ensure the integrity of the ECL.

d. The existing CMG’s constituents represent the ECL’s intended stakeholders.

e. The existing CMG has the capacity to manage the maintenance of the ECL efficiently and effectively.

(11)

2. Long-term assignment to a new CMG, if all the following criteria are met.

a. An X12 member representative who is qualified and willing to serve as chair of the CMG through start-up is identified.

b. X12 member representatives or non-member who are qualified and willing to serve as the CMG’s constituents are identified.

c. The willing individuals shall each have the knowledge, skill set, or experience to effectively evaluate maintenance requests and ensure the integrity of the ECL.

d. The willing individuals shall collectively represent the ECL’s intended stakeholders.

3. Temporary assignment to CMG01 (the ECO operating as a CMG), in the following situation.

a. No established CMG meets the criteria established in #1 above.

b. The appropriate individuals described in #2 above have not been identified to act as a new CMG.

c. Maintenance activities need to commence and cannot be postponed until a new CMG can be established.

d. The ECO will establish an appropriate CMG to maintain the ECL as soon as possible.

7 ECL Guiding Policies

To ensure consistency between external code lists and efficient use of organizational resources, the policies in this section shall apply to all external code lists. Grievances or complaints related to the policies, procedures, or activities herein shall be handled per Grievances and Complaints (CAP22).

The following high-level operational rules shall apply to each ECL.

• All documentation related to ECL maintenance, including collaboration notes, shall reside in X12’s official ECL repository

• Each ECL shall operate using

o One operating methodology for all maintenance activities, see Section 9 CMG Operating Methodologies

o One maintenance process, see Section 8 Maintenance Request Processing

o One of the board-approved distribution mechanisms, for example in Glass or the X12 Store

o One of the board-approved notification options, such as email notices to member representatives, listserv notices to members and non-members, or website posts o One of the board-approved value-add tools, such as the Reviewer, the Commenter,

iMeet, or Glass

• An ECL’s codes shall be assigned sequentially with no implied intelligence in the codes themselves.

(12)

• ECL integrity shall be retained by restricting revisions such that a substantively different description cannot be assigned to a code. Once a code has been assigned a description, only clarifying, non-substantive revisions to the approved description are permissible.

• Approved codes shall have an activation date, which is the date the trading partners must begin to support the code. Willing trading partners may support the code after the publication date and in advance of the activation date.

• Approved deactivations shall have a deactivation date, which is the date the trading partners must desist using the code.

• Once established, a code cannot be deleted, it can only be deactivated.

7.1 ECL List Attributes

To simplify the use of the external code lists by trading partners across and within the various industries, to increase efficiency, and to reduce the cost of maintaining the lists, each external code list shall contain the same information and shall be governed by the same usage and constraint rules. These rules are established in the External Code List Attributes Appendix herein.

7.2 ECL Grammar Rules for Descriptions

Each ECL description and any extended description shall adhere to the following:

• Descriptions that are well-formed sentences shall begin with a capital letter and end with a period.

• Descriptions that are not well-formed sentences shall begin with a capital letter and shall not end with a period.

• By definition, a description is brief so it shall be limited to one sentence.

• An extended description shall consist of one or more well-formed sentences.

• X12 Segment or element names are discouraged. If used, they shall not be capitalized.

• The use of an explicit named reference to any other standard is strongly discouraged. If unquestionably required for clarity, it shall not be capitalized.

• Proper nouns shall be capitalized.

• Nouns other than proper nouns, roles, titles and other types of descriptors shall not be capitalized.

• Excepting the above, X12’s customary capitalization, grammar, and spelling rules shall apply.

• When X12 has no specific rules, grammatical best-practices shall apply.

(13)

7.3 ECL Terminology for Descriptions

Descriptions shall use the following terminology consistently:

• Inappropriate – used to describe two or more pieces of transmitted data that cannot be combined to describe an item, action, or outcome accurately.

• Invalid - Information that was transmitted doesn’t meet the expected criteria.

• Missing – Information is necessary that was not transmitted.

• Not found – The submitted information cannot be matched with a corresponding record in the receiver's stored information.

• Not matched – A corresponding record was found in the receiver's stored information however the transmitted data does not match the stored data.

• Not processed - Information that can be transmitted by a sender but will not be used in any internal processes by the receiver.

• Not supported - Information that cannot be transmitted in a compliant X12 transaction as identified in GS08 of the transmission.

8 Maintenance Request Processing

To ensure consistency, the policies in this section shall apply to maintenance activities for all external code lists.

All maintenance requests shall be submitted via an online form and may be submitted by any materially interested party, regardless of X12 membership status.

The following high-level operational rules apply to each CMG.

• A CMG shall consider all submitted code maintenance requests that align with the ECL’s approved purpose.

• A CMG shall administer all requests consistently, with no preference given to requests submitted by an X12 member, an X12 group, or a recognized industry group.

• A CMG shall approve code maintenance requests only when:

o The intended use of the code and the wording of the description are clearly within the ECL’s approved purpose.

o The approved code and description fully comply with Section 7 ECL Guiding Policies

• A CMG’s maintenance activities shall be conducted via the ECO-approved toolset.

o Maintenance requests are presented to the code maintenance group via an iMeet workspace

o The written collaboration and final determination on each request shall be recorded in the same iMeet workspace

• A CMG shall publish the ECL at regular intervals per a defined schedule that meets the business needs of code users.

o The permitted schedules are annual (once per year), semi-annual (twice per year), tri-annual (three per year), or quarterly (four per year).

(14)

o The publication schedule will not be changed more frequently than once every two years.

o Exception: When requests for a new list are being vetted before the initial

implementation by the intended code list users, the CMG may temporarily publish the list on a more frequent interval, subject to ECO approval.

9 CMG Operating Methodologies

To ensure consistency between external code lists and efficient use of organizational resources, all CMGs shall operate under one of the following methodologies. The CMG’s charter shall explicitly identify the group’s operating methodology.

9.1 Defined Representative Voting Panel

Under this methodology, a CMG’s make-up shall be representative of the trading partners that communicate via its code lists and standards organizations who develop messages that rely on the code lists. When establishing the CMG, the ECO identifies the users of the CMG’s assigned code lists by category (known or anticipated) and determines how many constituents will represent each category on the panel. The ECO shall ensure the panel is balanced based on the identified categories. Balanced does not imply numerical equality but ensures that no one category constitutes a majority or exerts undue influence.

The ECO then identifies a specific set of organizations, each of which officially

represents the opinions or positions of a significant portion of the category they would represent. Identified organizations willing to commit to participating in the CMG’s code list maintenance activities for at least a two-year period are named to the

representative voting panel. Each organization named on the representative voting panel shall be entitled to one and only one vote on any matter. Specific individuals shall not be named to any representative voting panel. The voting panel shall be explicitly identified in the CMG’s charter.

A recognized authority (such as the chair, formal liaison, president, or executive director) of each organization named to the representative voting panel shall identify one representative to serve as their constituent on the voting panel. Constituent status vests in the named organization, not the named constituent. If permitted by the CMG’s charter, a CMG may allow a voting entity to name one representative as an alternate constituent. The recognized authority of a named organization may change its

constituent at any time by completing the online request form found at x12.org/forms.

An individual does not retain constituent status in the CMG when the individual no longer represents the organization named to the representative voting panel.

A constituent is eligible for all privileges, including voting rights, immediately upon being named, however, the constituent must participate in two of the last three CMG

(15)

meetings and meet any other constituent criteria established by the CMG to maintain their voting privilege.

CMG ballots may be conducted via meeting vote or electronic vote. All actions of a Defined Representative Voting Panel CMG, including maintenance decisions, shall be determined by a majority vote of the voting panel, excluding abstentions.

9.2 Material Interest Voting Panel

Under this methodology, a CMG comprised of materially interested parties facilitates maintenance decisions. A material interest voting panel CMG is open to any RSC stakeholder with a material interest in a group’s statement of work that intends to provide an active and responsible constituent to represent its interests on the CMG.

Once an RSC stakeholder has met the specific requirements defined below, the stakeholder is entitled to be represented on the CMG by one constituent with one and only one vote. As continuity is critical to the ECO’s work, alternates are neither

intended nor accommodated on a material interest voting panel.

The RSC stakeholder wishing to be represented on the CMG shall have one of their member representatives participate as an observer at one CMG session. At the conclusion of the session, the member representative who attended as an observer may submit the online request form found at x12.org/forms to request recognition as a CMG constituent.

After verifying the member representative meets the established criteria, the CMG chair shall approve the request and recognize the member representative as a CMG constituent. Constituent status vests in the RSC stakeholder not in the constituent.

The RSC stakeholder’s primary member representative may change its constituent at any time by completing the online request form found at x12.org/forms. All rights and responsibilities are assigned to the stakeholder; an individual does not retain

constituent status in the CMG when the individual no longer represents the stakeholder.

A materially interested individual who is not an X12 member may also petition the CMG chair for constituent status in the CMG, using the non-member request form at x12.org/forms. The petition shall articulate the individual’s material interest and confirm an intention to be an active and responsible participant in the CMG’s

collaborations. The CMG chair shall review the petition and approve or disapprove the petition. Non-member constituents shall be assessed a nominal annual participation fee. If approved, the petitioner shall be recognized as a CMG constituent once the annual participation fee has been paid.

(16)

Constituent status for non-members vests in the petitioner. Each petitioner granted constituent status is entitled to one and only one vote on any matter.

Once recognized, a constituent is eligible for all privileges, including voting rights;

however, the constituent must participate in two of the last three CMG meetings and meet any other constituent criteria established by the CMG to maintain their voting privilege.

CMG ballots may be conducted via meeting vote or electronic vote. All actions of a material interest voting panel CMG, including maintenance decisions, shall require a quorum, and be determined by a majority vote of the constituents who cast a ballot, excluding abstentions

9.3 X12 Member Voting Panel

Under this methodology, a CMG uses X12’s Code Maintenance Request (CMR) process to facilitate maintenance decisions. Since X12’s CMR process is used to approve or disapprove the maintenance requests, the CMG only votes to approve requests for the CMR process and on other administrative matters.

An X12 member voting panel CMG is open to any RSC stakeholder with a material interest in a group’s statement of work when that stakeholder intends to provide an active and responsible constituent to represent its interests on the CMG. Once an RSC stakeholder has met the specific requirements defined below, the stakeholder is entitled to be represented on the CMG by one constituent with one and only one vote.

Alternates are neither intended nor accommodated on an X12 member voting panel.

The RSC stakeholder wishing to be represented on the CMG shall have one of their member representatives participate as an observer at one CMG meeting. After the meeting, the member representative who attended as an observer may submit the online request form found at x12.org/forms to request recognition as a CMG constituent.

After verifying the member representative meets the established criteria, the CMG chair shall approve the request and the member representative shall be recognized as a CMG constituent. Constituent status vests in the X12 member, not in the named constituent.

The RSC stakeholder’s primary member representative may change its constituent at any time by completing the online request form found at x12.org/forms. All rights and responsibilities are assigned to the stakeholder; an individual does not retain

constituent status in the CMG when the individual no longer represents the stakeholder.

(17)

Once recognized, a constituent is eligible for all privileges, including voting rights;

however, the constituent must participate in two of the last three CMG meetings and meet any other constituent criteria established by the CMG to maintain their voting privilege.

CMG ballots may be conducted via meeting vote or electronic vote. All actions of a material interest voting panel CMG, including maintenance decisions, shall require a quorum, and be determined by a majority vote of the constituents who cast a ballot, excluding abstentions

10 Establishing Code Maintenance Groups

The ECO shall establish code maintenance groups (CMGs) as necessary to support external code list maintenance. As part of the establishment process the ECO shall do each of the following.

• Define the CMG’s initial statement of work

• Determine the CMG’s operating methodology

• Determine whether non-members are permitted as CMG constituents. When permitted, non-member participation shall be limited per the RSC Operating Manual (RSC101).

• Assign the CMG with responsibility for one or more specific ECLs

o Maintenance responsibility is assigned separately for each external code list.

o A CMG may be responsible for multiple external code lists, so long as all the code lists adhere to the same code maintenance methodology.

• Delegate the CMG with the authority to maintain its assigned ECLs

• Ensure the CMG publishes a group charter within 6 months of establishment. The charter shall conform to organizational requirements for form, content, wording, and style. The ECO shall have final approval over the charter.

o At the discretion of the ECO, a CMG that does not publish a charter timely shall give up responsibility for the maintenance of its ECLs until a charter is completed and published.

The ECO chair shall appoint a qualified initial chair for the CMG. The appointed chair shall serve a one-year or two-year term at the ECO chair’s discretion. Subsequent chairs will be elected by the code maintenance group per Section 11.2 CMG Roles.

The ECO chair shall appoint at least 5 and not more than 25 individuals as CMG constituents, per Section 9 CMG Operating Methodologies. Appointees shall retain constituent status for one year unless the ECO chair specified a different appointment period at the time of appointment.

Appointees who wish to continue as constituents are expected to meet the group’s established constituent criteria during their appointed term.

(18)

11 Code Maintenance Groups

The ECO establishes a code maintenance group as necessary to support external code list maintenance. A code maintenance group processes code maintenance requests for one or more external code lists accurately, timely, and efficiently.

CMGs are established to manage external code list maintenance activities. They are not intended to be information dissemination forums, presentation forums, nor discussion forums related to the state of various programs, activities, or events. CMGs do not supersede any other ASC or RSC subcommittee, task group, work group, or action group and shall not assume responsibilities officially assigned to those groups as part of their establishment or governance. The chair shall strictly limit CMG activities within the defined statement of work and per the applicable corporate and committee policies.

A CMG may request business process input or recommendations from any stakeholder group;

however, such input or recommendations shall not be binding on the CMG.

11.1 CMG Responsibilities

A CMG chair shall have the following responsibilities.

1. Reporting CMG activities to the ECO Chair as requested.

2. Ensuring the duties and responsibilities of the CMG are met.

3. Ensuring voting is limited to the appropriate constituents based on the CMG methodology.

4. Scheduling CMG meetings as necessary to accomplish the group’s tasks and activities, including setting the agenda.

5. Ensuring CMG activities align with the group’s statement of work, are conducted per all applicable policies and procedures, and relate to maintenance of the code list. Other X12 groups have responsibility for defining instructions for use of the code list within other X12 work products.

6. Working with staff and the ECO chair to ensure timely publication of external code lists.

7. Communicating the group’s decisions to staff.

a. When requests are determined by code maintenance group ballot, the chair of the code maintenance group shall notify staff of approved maintenance per the established publication schedule. For CMG’s using the iMeet database maintenance process, this is accomplished by submitting the online form.

For CMG’s using another process during a transition period, this is accomplished via assignment of one or more iMeet tasks which shall reference or detail all maintenance decisions to be applied to the next release of the external code list.

b. When requests are determined by X12 members, the chair of the code maintenance group shall notify staff a CMR is needed per the established publication schedule. Such notice will be accomplished via assignment of in

(19)

iMeet task which shall reference or detail the candidate codes to be balloted.

8. Appointing a CMG secretary, if necessary.

9. Unless explicitly appointed as an X12 formal liaison, the chair shall not have the authority to speak on behalf of X12 in any matter.

A CMG shall have the following responsibilities.

1. Maintaining one or more external code lists

2. Drafting revisions to the group’s statement of work if necessary. Such revisions shall be subject to approval by the ECO.

3. Confirming the Charter once every two (2) years.

4. Operating under the assigned methodology as defined in Section 9 CMG Operating Methodologies.

5. Administering all requests consistently, with no preference given to requests submitted by an X12 member or a recognized industry group.

6. Considering non-member input in the determination process.

11.2 CMG Roles

Each CMG shall have a chair and may have a vice-chair.

A CMG chair shall be an X12 member representative eligible to hold elected office and shall be a constituent of the CMG. An individual shall not concurrently serve as chair for more than one CMG, or for a CMG and another RSC committee or action group, except that the ECO chair may concurrently serve as the chair of CMG01. An individual shall not concurrently serve as CMG chair and as chair of an ASC

subcommittee, task group, or work group with a material interest in an external code list maintained by the CMG.

Each CMG chair shall be elected for a two-year term by a majority vote of the group’s constituents. There are no term limits. In the absence of an elected chair, the ECO chair shall appoint a chair to serve until the next scheduled election.

Based upon their Charter, a CMG may also have a vice-chair, who shall meet the same criteria as the chair and who shall be elected for a two-year term by a majority vote of the group’s constituents. There are no term limits. The chair and vice-chair shall not both represent the same X12 member.

Each CMG may also have a secretary who shall not be considered an officer. The secretary shall be appointed by the CMG chair for a two-year term, with no term limit.

If a CMG does not have a secretary and does have a vice-chair, the vice-chair shall be responsible for the secretary’s duties. If a CMG does not have a secretary or a vice-chair, the chair shall be responsible for the secretary’s duties.

(20)

11.3 CMG Constituents

CMG constituents participate in collaboration, straw polls, and ballots. Eligibility depends on the constituency methodology selected for the CMG, see Section 9 CMG Operating Methodologies for more information.

CMG Constituents shall have the following responsibilities.

1. Reviewing materials before meetings.

2. Attending scheduled meetings.

3. Actively participating in meetings and online collaborations.

4. Casting an informed vote in CMG ballots.

Maintaining Constituent Status

Active and consistent participation is critical to CMG success. Participation requirements set forth in Section 9 CMG Operating Methodologies herein require that all CMG

constituents participate in two of the last three CMG meetings to maintain constituent privileges.

Termination of Constituent Status

Constituents who do not meet the participation requirements shall be considered to have resigned. An individual whose constituent privileges have been terminated due to participation shall be entitled to re-establish constituent status in the future by meeting the requirements established in Section 9 CMG Operating Methodologies again.

11.3.1 Appointed Constituents

Any time the CMG has fewer than five constituents, including the CMG chair, the ECO chair shall appoint additional constituents to ensure adequate representation. Appointees shall retain constituent status for one year unless the ECO chair specifies a different appointment period at the time of appointment. Appointees are expected to meet the constituent participation requirements during their appointment.

11.4 CMG Observers

A named representative of an X12 member shall be allowed to attend as an observer at any CMG maintenance meeting.

At the discretion of the CMG chair, and on a case-by-case basis, observers may be allowed speaking privileges but shall not have any other constituent privileges.

If a CMG operates as a material interest voting panel that permits non-member constituents, a materially interested individual who is neither an X12 member nor a

(21)

non-member constituent may petition the ECO chair for permission to observe a CMG meeting to determine their interest in becoming a non-member constituent.

11.5 CMG Charter

Following establishment, the ECO will provide the CMG with a draft charter which shall conform to organizational requirements for form, content, wording, and style. The CMG shall review the draft and modify it as necessary. A CMG charter is reviewed and approved as described below. Thereafter, the CMG shall either revise or confirm the charter once every two (2) years. Any proposed change to the CMG’s

methodology, publication schedule, or representative voting panel shall be presented to the ECO for consideration prior to revisions being drafted to the Charter. The proposal shall describe the change(s) being considered and the justification for the change(s).

Following CMG approval to present the draft for ECO approval, the CMG chair shall submit the draft to the ECO chair at [email protected]. The ECO shall review the draft and either approve it or return it to the CMG chair with required or suggested revisions.

An initial or revised charter is effective immediately upon ECO approval. The ECO chair shall notify the CMG chair of the approval and shall email [email protected] to request the approved version be posted on the X12 website.

The ECO retains ultimate responsibility for all CMG policies and procedures and may initiate revisions to such with or without the approval of the CMG.

11.6 Sustaining Code Maintenance Groups

If at any time a CMG has no elected chair, the ECO chair shall appoint a CMG chair to serve until the next scheduled election.

If at any time a CMG has fewer than five constituents, the ECO chair shall appoint the number of individuals necessary to bring the group to five constituents. Appointees shall retain constituent status for one year unless the ECO chair specified a different appointment period at the time of appointment. Appointees who wish to continue as constituents are expected to meet the group’s established constituent criteria during their appointed term.

The ECO shall timely entertain CMG requests to revise their statement of work, charter, or maintenance methodologies.

(22)

12 X12 Staff Responsibilities

Staff shall support the ECO and its external code list policies and processes. Support may include the following.

1. Vetting maintenance requests for accuracy and completeness.

2. Assigning maintenance requests to the appropriate code maintenance group.

3. Maintaining one or more external code list repositories, which shall be the official source for all X12 external code lists.

4. Monitoring adherence to organizational policies and procedures and escalating issues 5. Timely publication of external code lists following a request to publish.

6. Ensuring policies and procedures conform to established organizational styles.

7. Maintaining the official source for each ECO or CMG policy and procedure.

8. Ensuring that approved policies and procedures are presented on an X12 website.

9. Providing distribution mechanisms, notification options, and value-add tools as determined by the Board.

13 X12 Terminology

To ensure consistent use of terms, definitions, and acronyms across X12 products and activities, X12 maintains the Wordbook, a comprehensive corporate glossary. The included terms are either proprietary to X12, cite definitions published by another authority, or represent common terms and definitions that are relevant to X12’s work. The terms and definitions defined in the Wordbook shall be used in X12 work products when applicable, without modification or revision. The Wordbook can be referenced online at wordbook.x12.org.

14 Document History

Revisions are effective on the approval date.

Approved Description

04/21/2020 V6: Removed duplication with the RSC Operating Manual (RSC101),

reordered and reorganized the information, and streamlined where possible.

03/30/2019 V5: Minor clarifications based on suggestions from the ECO subcommittee.

09/25/2017 V4: Revisions, including revisions suggested by the ECO subcommittee.

04/18/2017 V3: Simplified Section 6 and other minor revisions.

02/21/2017 V2: Fully integrate ADP24 into CAP12 as Steering voted that the ASC would decline maintenance responsibilities.

01/23/2017 The initial version which partially supersedes ADP24.

(23)

External Code List Attributes Appendix

External Code List Attributes Appendix

X12’s external code lists shall be defined and constrained in accordance with the table listed below, without exception.

Field Explanation Usage Constraints Source of the Information Exceptions

Code The value transmitted between trading partners to convey a specific

message.

Always required Once published, the code shall never be revised.

Assigned by staff based on the attribute type and length based on the pattern described below.

Regardless of the length of the code, the enumeration pattern shall start with 01 and increment by 1, with A1 following 99, B1 following A9, and AA following Z9.

If a code list was established outside of X12 and is being transitioned into an X12 ECL, the previous enumerations may be grandfathered based on the express approval of the ECO.

Codes added after the transition shall conform to the enumeration pattern described in the previous column except when that would cause conflicts with grandfathered codes. In the case of conflict, the ECO shall determine the new enumeration pattern.

Description A brief statement of the meaning the code is intended to convey to the receiver.

It must align with the ECL’s published scope.

It must stand-alone to communicate a useful message that can be interpreted consistently by various trading partners.

Follow-up information, next step instructions, and limitations based on a scenario or a subset of the implementers are not permitted.

Always required Each code shall have one description which shall apply to all uses of the code.

Once published, the meaning of the description shall never be revised. However minor wording adjustments for grammar, clarity, or consistency may be permitted based on the express approval of the ECO.

There shall be one, and only one, code/description pair to describe any one scenario, situation, or explanation. Multiples which could be used interchangeably based on wording preference are strictly prohibited.

Approved by the CMG If a code list was established outside of X12 and is being transitioned into an X12 ECL, the previous descriptions may be grandfathered based on the express approval of the ECO if those descriptions align with the published scope of the ECL.

However, follow-up or next step instructions shall never be included in an otherwise grandfathered description. And multiple code/description pairs which introduce inconsistency between trading partners shall never be permitted in a grandfathered list.

(24)

Activation Date

The date all trading partners must begin to support the code.

Willing trading partners may support the code after the publication date and in advance of the activation date.

Always required Each code shall have one activation date, which is either the date the code is initially published or a date no more than 6 months later than the initial publication date. The activation date shall not be earlier than the publication date.

Once published, the date shall never be revised.

Determined by the CMG.

The date may be defined in the CMG’s policies or on a case-by- case basis as part of the approval determination.

If a code list was established outside of X12 and is being transitioned into an X12 ECL any code with a future activation date shall have its activation date changed to equal the initial publication date of the X12 ECL.

Technical Note

A comment intended for a programmer or application developer but not intended to be part of the message to the receiver.

Example: “This code replaces deactivated code

####”.

Optional Each code shall have zero or one technical note.

A technical note shall apply to all uses of the code.

A technical note shall not contain implementation instructions specific to any syntax, standard, transaction set, or implementation guide.

Approved by the CMG If a code list was established outside of X12 and is being transitioned into an X12 ECL, any previous technical notes shall be individually considered and may be grandfathered based on the express approval of the ECO if those descriptions align with the intentions and constraints noted here.

Deactivation Date

When a code has been deactivated, this is the date trading partners must discontinue using the code, unless an exception for transmissions describing past activity has been granted in a federal regulation.

Required if a code has been deactivated

Each code shall have zero or one deactivation date, which shall either be the date the deactivation was published if the deactivation is immediate or a later date.

Once a deactivation date has been established for a code, the decision is final and the date shall never be revised.

Determined by the CMG.

The date may be defined in the CMG’s policies or on a case-by- case basis as part of the approval determination.

If a code list was established outside of X12 and is being transitioned into an X12 ECL any code with a future deactivation date shall retain the previously determined deactivation date.

(25)

Last

Maintenance Date

If a code’s description or an associated technical note has ever been revised, this is the publication date of the latest revision.

Required if a code’s description or an associated technical note has ever been revised

Each code shall have zero or one last maintenance date.

Once published, the date can be revised based on maintenance activity but shall never be removed.

Determined by staff as part of the publication process

None

Maintenance Type Code

If a code’s description or an associated technical note has ever been revised, this identifies the field that was last revised.

Required if a code’s description or an associated technical note has ever been revised

Each code shall have zero or one maintenance type code.

Value “D” signifies the last maintenance was to the Description field.

Value “T” signifies the last maintenance was to the Technical Note field.

Determined by staff as part of the publication process

None

Extended Description

A detailed clarification that supplements a code’s description. The clarification shall not change the meaning of the description or limit the use of the code.

The clarification is not intended to be interpreted separately from the associated description.

Only permitted when already associated with a grandfathered code from a code list established outside of X12 and transitioned into an X12 ECL.

If supported, each code shall have zero or one extended descriptions. An extended description shall apply to all uses of the code.

Once published, non-substantive wording changes may be applied but a substantive revision shall be prohibited.

An extended description shall not contain implementation

instructions specific to any syntax, standard, transaction set, or implementation guide.

** A grandfathered code list If a code list was established outside of X12 and is being transitioned into an X12 ECL, and that code list supported two description fields, any previous second descriptions shall be individually considered and may be grandfathered based on the express approval of the ECO if those descriptions align with the intentions and constraints noted here.

Codes added after the transition shall not include an extended description.