Annual Release Cycle (ARC) FAQ
This section includes reoccurring questions that concern the overall Annual Release Cycle (ARC) initiative, including its goals and intended outcomes.
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.
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
Integrating technical report maintenance into the mature and efficient existing maintenance request system (aka the DM process).
Under ARC technical reports are published once a year, with zero to many maintenance requests (MRs) applied.
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.
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.
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.
This is an ASC initiative; the RSC maintains separate maintenance policies and processes.
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.
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).
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.
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.
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.
Yes.
Yes.
X12 staff assigns the tracking number when they create the MR from the submitted suggestion.
Staff assigns these when they create the MR from the submitted suggestion.
The Procedures Review Board (PRB).
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.
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.
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.
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.
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.
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.
There is no change to the existing process related to applying approved revisions.
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.
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.
This section includes reoccurring questions related to timing.
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.
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.
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.
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.
This section includes reoccurring questions related to corporate policies or processes.
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.
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.
No, separate business requirements will be considered separately throughout the maintenance process.
No, one business requirement will be on one maintenance request.
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.
No, the input is collected on suggestions via a survey-type form, two-way communication is not supported.
Maintenance requests (MRs) are assigned to an X12 group after the public input period, PRB review, and X12J review.
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.
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.
Following PRB acceptance of the request and X12J concurrence with the developing subcommittee assignment.
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.
The ASC subcommittees will need to evaluate their structure, policies, and procedures to ensure they align with ARC in an efficient and effective manner.
Questions related to the Accredited Standards Committee’s (ASC) corporate policies or processes are listed in this section.
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.
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.
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.
Questions related to the X12N-specific policies or processes in place today.
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.
X12N's workflow under ARC is currently being developed to align with the requirements of the ARC process
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.
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.
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.
Assignment varies depending upon the complexity of the MR and the number of transaction sets or implementation guides impacted.
There are no specific training requirements.
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.
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.
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.
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.
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.
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
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.
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.
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.
This section clarifies how revisions that impact the EDI Standard and one or more technical reports are handled under ARC.
No, ARC covers the EDI Standard and the technical reports.
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.
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.
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.
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.
This section contains questions that don’t fit in another category.
Not immediately. Eventually, status information related to in-process MRs will be visible to the public.
X12’s processes related to HIPAA mandate recommendations are separate and outside the scope of the ARC process.
X12’s processes related to HIPAA mandate recommendations are separate and outside the scope of the ARC process.
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.