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. X12 has implemented an annual release cycle (ARC) for product maintenance and X12N must align with those policies and processes.
ASC95 defines X12N’s subcommittee-specifics related to the MR process. ASC95 is invoked when an MR is assigned to the X12N Subcommittee and is applicable until the MR’s proposed solution is moved to X12J for review. The ASC Maintenance Request and RFI Processing Manual (ASC02) governs the process prior to and following X12N’s specific steps.
Yes, the committee created an ASC95 process flow, that can be found on the X12N Proposed MR Process page.
The X12N subcommittee chair is responsible for all appointments within the subcommittee.
The committee-level criteria and responsibilities of Project Delegates are defined in section 2.1 of the ASC Maintenance Request and RFI Processing Manual (ASC02) and X12N specific governance is detailed in section 5.3 of X12N Maintenance Request Processing (ASC95).
The ASC Maintenance Request and RFI Processing Manual (ASC02) permits an individual to serve as Project Delegate for up to five maintenance requests simultaneously.
The constituents of a Development Group should have either implementation experience, X12 syntax/semantic expertise, or applicable business process knowledge. There is no qualification related to length of X12N participation, newcomers as well as long-term participants are welcome to be Development Group constituents. X12N leadership strongly encourages X12N constituents who are interested in participating in a Development group but need more experience with X12 and X12N policies to participate as an Observer first.
An individual may participate as a SME on as many Development Groups as they can actively contribute to, based on their available time and energy, at one time.
The time and effort required to complete work on 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.
A Development 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.
Development Groups are being proposed to ensure a group of subject matter experts who cover all aspects of the MR is assembled to focus on a particular MR. This will allow quick turn-around of very defined and well-documented proposed revisions.
The Development Groups do not replace the current work groups. The current work groups have responsibilities above and beyond those of a specific Development Group.
Like all the other ASC subcommittees, X12N is evaluating its structure, policies, and procedures to ensure they align with ARC in an efficient and effective manner.
Once an MR has been through the preliminary ASC02 steps, including preparation of the initial impact assessment, the X12N X12J representative will notify the MR Coordinator it is ready for assignment. Generally, an MR will be assigned to a Development Group soon after that notice. Occasionally, an MR may need to be held until a Development Group can be formed with representation from all the X12N groups with material interest in the MR. There is no specific maximum period.
The MR system contains information to describe the requested maintenance, impacted work products, and proposed solution(s), along with information needed for tracking the MR’s progress, including assignments, status, and the dates and results of ballots. Initial information is stored in the MR system prior to X12N assignment, and the information is updated and additional information is added as the MR progresses through the X12N process steps.
Once entered, MR information is stored permanently.
There are two opportunities for making comments:
- As the solution is being developed the SME(s) will solicit input from the associated workgroup.
- ASC95 calls for a subcommittee-wide comment period after the Development group finalizes their proposed solution.
X12N will conduct a subcommittee ballot on each MR after the subcommittee-wide comment period. The ASC will conduct a stakeholder ballot on each MR after X12J completes a technical review of the proposed solution and PRB confirms due process.
No, but information from the BRTS form was incorporated into the MR system.
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, once the ARC process is fully implemented, industry input will be solicited much earlier in the process, even before a suggestion becomes a maintenance request under ARC.
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.
You can enter a maintenance request with the Maintenance Request Form.
You can review MRs already in process on https://mr.x12.org. Be sure to review the webpage help for details about the presentation of the MR information. The information on the web page is updated periodically as the MR moved through X12’s process steps.
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.