Section title: neX12

Annual Release Cycle (ARC) FAQ

Overview

This section includes reoccurring questions that concern the overall Annual Release Cycle (ARC) initiative, including its goals and intended outcomes.

Question
Why do we need a streamlined or simplified process?
Answer

The ARC initiative was born from feedback, internal and external and from more than one of the industries that X12 supports, that the lack of an established and reliable schedule for updated versions of technical reports was putting the future of the X12 organization at risk.

Question
What does X12 hope to gain from moving to ARC?
Answer

X12 realizes the following benefits under ARC:

  • One maintenance process that applies to the EDI Standard and the technical reports that support its use
  • A predictable and reliable schedule for publishing updates to X12 work products
  • The EDI Standard and every product that supports its use is available in the most current version
  • Reduction of the burden on X12 member representatives
Question
In one sentence, why are we changing the current maintenance process for technical reports, what is the goal?
Answer

Integrating technical report maintenance into the mature and efficient existing maintenance request system (aka the DM process).

Question
How does consolidating the maintenance processes change anything?
Answer

Under ARC technical reports are published once a year, with zero to many maintenance requests (MRs) applied.

Question
How does this level the workload of an X12 group assigned maintenance responsibility?
Answer

The process is based on individual tasks, start to finish, instead of including all revision requests received over an extended period. This eliminates scope-creep and churning.

Question
It seems like much of the labor-intensive work of producing technical reports is moving to staff, is that true?
Answer

Yes, X12 will assign staff resources to complete some of the tasks that previously fell to the volunteers, freeing them up for activities that make better use of their subject matter expertise.

Question
What is the maximum number of changes or maintenance requests that can be applied in one ARC release?
Answer

There is no maximum number of changes or maintenance requests in one cycle. The maximum number is the total number of maintenance requests that X12 groups can complete in any given year.

Question
Does ARC apply to the Registered Standards Committee (RSC)?
Answer

This is an ASC initiative; the RSC maintains separate maintenance policies and processes.

Question
Is the entire process, from suggestion to publication or disapproval, reflected in the pilot version of ASC02?
Answer

No, as with all other committee-level policies and procedures, there are X12-level policies and procedures that govern some of the activities of ARC.

Question
When will this rollout?
Answer

The Steering Committee approved a pilot of the version of ASC02 (SD2) that covers ARC. The pilot is in effect now, new requests will be processed as maintenance requests (MRs).

Question
Why is this happening so quickly?
Answer

ARC is not moving that quickly, the initial discussion of a simplified and streamlined maintenance process that includes all of X12’s standard’s based products was during the General Session at the Fall 2018 standing meeting.

Question
How long will it take X12 to get this process perfected?
Answer

X12 leaders are focusing on progress, not perfection and expect that policies, procedures, and tools will evolve over the first couple of years of ARC.

What Doesn’t Change

ARC calls for technical reports to be maintained using the existing maintenance process that has governed maintenance to the EDI Standard for many years. Since the goal process is already mature and well-established, many activities and processes will work as they do today. This section lists reoccurring questions related to those items. 

Question
Will the guide numbers still stay the same between versions as was announced previously?
Answer

Yes.

Question
Are maintenance requests (MRs) assigned a tracking number that is consistent through the MR’s life cycle?
Answer

Yes.

Question
Who assigns the maintenance request (MR) tracking number and when?
Answer

X12 staff assigns the tracking number when they create the MR from the submitted suggestion.

Question
Who assigns the title and keywords for a maintenance request?
Answer

Staff assigns these when they create the MR from the submitted suggestion.

Question
Who determines the maintenance request (MR) assignment?
Answer

The Procedures Review Board (PRB).

Question
What if the X12 group assigned maintenance responsibility doesn’t agree with a maintenance request?
Answer

This is handled the same way it is now. X12 is committed to meeting the business needs of implementers across industries.  X12 groups are expected to analyze and entertain all revision requests submitted by any party. If the group has an objective rationale for disapproving the request, the subcommittee can vote to disapprove the MR subject to the X12J subcommittee’s agreement with the disapproval.

Question
How do we decide which maintenance requests (MRs) will be included in a specific version of the EDI Standard or a technical report?
Answer

Maintenance requests for the EDI Standard are not targeted for a specific version. Instead, maintenance requests are worked expeditiously and once approved are applied to the next release. Under ARC, maintenance to the technical reports will work the same way.

Question
Who decides what set of maintenance requests (MRs) will be applied to a specific version?
Answer

Under ARC, X12 groups don’t work on specific versions of a product, they work on individual functional enhancements (MRs). Once approved, the individual functional enhancements are applied to the next published version of the product.

Question
How does balloting work?
Answer

Just as is done today for revisions to the EDI Standard, consensus will be achieved in various ballots at different levels within the ASC committee.

Question
Will the X12 group assigned maintenance responsibility review the revised work product prior to the vote to approve or disapprove the maintenance request?
Answer

No, just as is done today for revisions to the EDI Standard, the X12 subcommittee assigned maintenance responsibility will vote to approve or disapprove the revision instructions for X12J technical review.

Question
Will there be absentee voting on maintenance requests?
Answer

X12 doesn’t permit proxy voting on any ballot at any level of the organization and doesn’t recognize absentee voting per se. A member representative eligible to vote in a meeting ballot must be present to cast their ballot. A member representative eligible to vote in an electronic ballot presents their vote in accordance with the electronic ballot’s instructions.

Question
How are changes to the EDI Standard applied under ARC?
Answer

There is no change to the existing process related to applying approved revisions.

Question
Are we still publishing sub-releases?
Answer

No, the decision to stop publishing sub-releases was made several years ago based on the results of outreach to ascertain how often the sub-releases were being used in implementations across the industries supported by X12.

Question
Will member representatives vote on this process?
Answer

Yes, once the Steering Committee is satisfied that the pilot procedures are concise and accurate, a committee-level electronic ballot will be issued to consider the approval of the pilot version of ASC02.

Timing

This section includes reoccurring questions related to timing.

Question
What is the timeline for a maintenance request (MR) under ARC?
Answer

Each MR will proceed through the process steps at its own pace, although the expectation is that most MRs will be approved within a year of the initial assignment for maintenance. The exact time required for each MR depends upon the complexity of the business requirement and the number of products impacted.

Question
What is the best and worst-case timing for a maintenance report that includes technical report changes?
Answer

Individual maintenance requests (MRs) could be processed via ARC in as little as three months, most are expected to be processed in 12 months, and some may take longer due to complexity. But all approved maintenance will be applied annually and there will be an updated version of each technical report once a year.

Question
How does the timing required to process changes to a technical report via a maintenance request compare to the current timing?
Answer

Currently, maintenance requests for technical report revisions are open-ended and vague, with no scope or timing limitations included, for example, “Create an 007030 version of the 005010 version of Technical Report A”. This can lead to scope-creep and perfection as the enemy of progress scenarios.

Comparatively, under ARC each maintenance request will be a quantified request for a revision, “Increase the number of characters allowed for a purchase order number as purchase order numbers in some mature systems are nearing the maximum length”. In many cases, the ARC process will result in faster completion as the maintenance requests will be for smaller bites of work, most of which are completed within one year.

Question
How does this improve the timeline?
Answer

We will publish both the standard and the technical reports once a year, with all approved maintenance requests (MRs) applied. If no maintenance requests are approved during the preceding year, “housekeeping” maintenance, such as version identification and factual corrections to external code list owner information, will be applied to the new version automatically.

Corporate Process Details

This section includes reoccurring questions related to corporate policies or processes.

Question
A suggestion seems like a business requirement and not a technical request, is that right?
Answer

Yes, every suggestion must be phrased as a business requirement or staff will work with the submitter to rephrase the suggestion as such. The public input period for suggestions is intended to verify whether other implementers concur with the stated business requirement.

Question
Can an X12 subcommittee, task group, or work group weigh in at the suggestion step?
Answer

Not as an X12 group, the group’s analysis comes later in the process. But an individual X12 member representative can present their input during the suggestion phase, just like any member of the public.

Question
If a suggestion is submitted with more than one business requirement and subsequently split into separate suggestions or separate maintenance requests (MRs), will those separate items be linked together for future reference.
Answer

No, separate business requirements will be considered separately throughout the maintenance process.

Question
Would a suggestion describing a complex but functionally singular business requirement be split?
Answer

No, one business requirement will be on one maintenance request.

Question
Who determines the number of days for public input on a suggestion and public feedback on a published version?
Answer

Processing Suggestions, Input, and Feedback (CAP11) calls for a 15 calendar day input period for each suggestion and a 15 calendar day feedback period for published technical reports. 

Question
Will two-way communication be possible during a suggestion’s public input period? Can a commenter ask for additional information or clarification?
Answer

No, the input is collected on suggestions via a survey-type form, two-way communication is not supported.

Question
When is an X12 group assigned a maintenance request (MR)?
Answer

Maintenance requests (MRs) are assigned to an X12 group after the public input period, PRB review, and X12J review.

Question
What is meant by “metered activation”?
Answer

X12 groups assigned maintenance responsibility are generally expected to work the requests in the order received. To ensure each request is given timely consideration, an X12 group assigned maintenance responsibility is only assigned a certain number of maintenance requests at any one time. Other maintenance requests for the group are held in a queue managed by X12 staff until the assigned maintenance requests are completed.

Question
How many maintenance requests can an X12 group have open at one time?
Answer

The exact number, or methodology for determining the number, is not finalized. It is expected that the number will vary by group depending on the number of constituents available to actively process requests and the group’s demonstrated ability to move maintenance requests through the process.

Question
When does an X12 group assigned maintenance responsibility receive the detailed maintenance request (MR) information?
Answer

Following PRB acceptance of the request and X12J concurrence with the developing subcommittee assignment.

Question
How does a group notify staff that they have completed a maintenance request and are ready for one or more queued requests to be activated?
Answer

The group does not need to notify staff they are ready for additional maintenance requests. When a maintenance request is approved via a subcommittee ballot, X12 staff will activate maintenance requests from the queue as appropriate.

Question
It seems like some subcommittees will need to revise their structure, policies, or processes to support ARC, is that a requirement?
Answer

The ASC subcommittees will need to evaluate their structure, policies, and procedures to ensure they align with ARC in an efficient and effective manner.

ASC Process Details

Questions related to the Accredited Standards Committee’s (ASC) corporate policies or processes are listed in this section. 

Question
If there are multiple maintenance requests (MRs), the X12 group assigned maintenance responsibility needs to prioritize them. How is this accommodated?
Answer

In general, work is expected to be completed on a first-in-first-out basis, however, an X12 group assigned maintenance responsibility for more than one maintenance request can prioritize among those requests so long as all maintenance requests are addressed in a timely fashion.

Question
Where is the step for updating OnlyConnect with revision instructions in the ARC process?
Answer

X12 groups assigned maintenance responsibility do not enter information into OnlyConnect under the ARC process. The revision instructions reside in the maintenance request system’s repository and staff is responsible for applying the revisions.

Question
What if the X12 groups assigned maintenance responsibility doesn’t agree with a maintenance request?
Answer

This is handled the same way it is now. X12 groups assigned maintenance responsibility are expected to analyze and entertain all revision requests submitted by any party with objectivity and an open mind. If the group has an objective rationale for disapproving the request, they can vote to disapprove the MR, subject to the X12J subcommittee’s agreement with the disapproval.

ASC Subcommittee-Specific Process Details: X12N Insurance

Questions related to the X12N-specific policies or processes in place today.

Question
Why does X12N need to change its maintenance process?
Answer

X12 has moved to the Annual Release Cycle for maintenance, which requires expedient turnaround times for development work. Because of this X12-level change, X12N must align with X12-level changes.

Question
X12N has implemented a proprietary, or subcommittee-specific, change process, is it applicable/permitted under ARC?
Answer

X12N's workflow under ARC is currently being developed to align with the requirements of the ARC process

Question
It seems like X12N will need to revise the subcommittee structure to support ARC, is that a requirement?
Answer

Like all the other subcommittees, X12N is evaluating its structure, policies, and procedures to ensure they align with ARC in an efficient and effective manner.

Question
Why are ad hoc work groups being proposed?
Answer

Ad hoc work groups are being proposed to ensure a small group of subject matter experts cover all aspects of the MR can be assembled to focus on the individual MR. This will allow quick turn-around of very defined and well-documented proposed revisions.

Question
What role do the existing work groups have in the proposed new process?
Answer

The ad hoc work groups are not replacing the current work groups. The current work groups have responsibilities above and beyond those of the ad hoc work groups.

Question
What determines whether the MR is assigned to an ad hoc work group or a standing work group?
Answer

Assignment varies depending upon the complexity of the MR and the number of transaction sets or implementation guides impacted.

Question
What type of training does a person need to have to be involved in an ad hoc work group?
Answer

There are no specific training requirements.

Question
What type of experience does a person need to have to be involved in an ad hoc work group?
Answer

Participants must have a vested interest in the work and the ability to share their knowledge/experience to help develop the solution. The goal is to have a variety of backgrounds in each ad hoc work group.

Question
How much time does a person need to devote to an ad hoc work group?
Answer

Similarly to the current process, the time and effort required to complete an MR varies based on many factors, like the complexity of the request, the meeting schedule, and the number of participants who take responsibility for the associated tasks.

Question
How do I sign-up to participate in an MR’s development activities?
Answer

To participate, make your interest known to the convener or chair. You will be asked to commit to actively participating by attending meetings and assisting in the development of the MR’s proposed revisions.

Question
How long will each ad hoc work group exist?
Answer

Each ad hoc work group will be established when an MR is assigned and disbanded after PRB confirms due process was achieved related to the processing of the MR.

Question
X12N has a subcommittee-specific form known as the BRTS, is it applicable/permitted under ARC?
Answer

Subcommittees are not permitted to store information used to determine maintenance requests in proprietary or subcommittee-specific repositories or forms. However, information from the BRTS form was evaluated and incorporated into the MR system as necessary.

Question
Are there forms that will replace the current forms like the BRTS?
Answer

Not directly, there is an MR database to house all the information X12 collects or uses in an MR’s life cycle. Various views will be presented to specific audiences at different times during the MR’s life-cycle. X12N will not maintain physical or virtual documents related to the MR

Question
X12N has traditionally held a public review of draft versions of a technical report, is that part of the ARC process?
Answer

Because maintenance requests are processed quickly and with a much smaller scope under ARC, there won’t be a public review of draft versions. In response to industry feedback, industry input will be solicited much earlier in the process, even before a suggestion becomes a maintenance request under ARC. There is also a post-publication public feedback period included in the process so X12 can collect public feedback on the annual version of a technical report. Note that this feedback is not considered to be a maintenance suggestion, it is simply industry comment on the revised version.

Question
X12N currently has a “Fast Track” process available for “urgent” requests, will there be a similar exception process available under ARC?
Answer

No, under ARC a maintenance request (MR) can be processed in as little as three months, so a “Fast Track” exception is not necessary. It may be permissible for a subcommittee chair to request a specific maintenance request be moved to the front of the queue if it meets specific criteria still under discussion.

Question
X12N has a queue of change requests (CRs) that were planned for post 007030 consideration, what will happen to those CRs?
Answer

Each X12N work group is expected to review its outstanding CRs. Some of them will be converted into maintenance requests (MRs) for processing under ARC.

The Intersection Between Revisions to the EDI Standard and Technical Reports

This section clarifies how revisions that impact the EDI Standard and one or more technical reports are handled under ARC.

Question
Does ARC just cover revisions to the EDI Standard?
Answer

No, ARC covers the EDI Standard and the technical reports.

Question
A maintenance request (MR) that adds a segment may not get finished before the technical report is revised and approved, how will this work?
Answer

Revisions to the standard and technical reports are integrated under the ARC process, all the revisions connected with the business process represented by the maintenance request will be approved and applied at the same time, regardless of whether the revision applies to the EDI Standard or a technical report.

Question
Are changes to the EDI Standard and associated changes to technical reports still a 2-step process?
Answer

Revisions to the standard and technical reports are integrated under the ARC process, all the revisions connected with the business process represented by the maintenance request will be approved and applied at the same time, regardless of whether the revision applies to the EDI Standard or a technical report.

Question
It seems that the faster speed increases risk, what if a maintenance request isn’t fully completed by the cut-off for the version a maintenance request applies to?
Answer

Some of these concepts are obsolete under the ARC. There are no cut-off dates and the version to which a maintenance request will apply is not part of the request. Revisions will be applied to the next version following full subcommittee approval. All the revisions connected with the business process represented by the maintenance request will be approved and applied at the same time, so there is no “orphaned” work based on the timing. To ensure timely completion of maintenance requests under ARC, each subcommittee must have a streamlined process.

Question
Who monitors the approved maintenance requests to ensure that changes to the EDI standard and technical reports are applied?
Answer

As is the case today, the developing subcommittee’s X12J representative should ensure that all the subcommittee’s approved maintenance requests are applied. Depending on the volume of maintenance requests applied in any one version, the subcommittee’s X12J representative may coordinate with other subcommittee constituents to facilitate this confirmation.

Other

This section contains questions that don’t fit in another category.

Question
Will the public be able to see the in-process maintenance requests (MRs)?
Answer

Not immediately. Eventually, status information related to in-process MRs will be visible to the public.

Question
How does this fit in the regulatory process for HIPAA mandates?
Answer

X12’s processes related to HIPAA mandate recommendations are separate and outside the scope of the ARC process.

Question
Do we know how this new process will impact what versions are mandated for the HIPAA covered transactions?
Answer

X12’s processes related to HIPAA mandate recommendations are separate and outside the scope of the ARC process.

Question
How frequently does X12 envision they will be recommending a published version be mandated?
Answer

X12’s processes related to HIPAA mandate recommendations are separate and outside the scope of the ARC process. However, it should be noted that X12 will recommend new versions of mandated technical reports based on business function or technical solution considerations, not on a calendar-based schedule.