Maintenance Request FAQs
An MR is a request, submitted by an X12 member representative, implementer, or a materially interested member of the public, related to an enhancement of or revision to an X12 product
An MR is the basis, or reason, an X12 product is enhanced or revised in a way that improves efficiency, adds functionality, or addresses technology advancements. An MR is the only mechanism for substantive change to an X12 product.
An impact assessment defines the changes to the EDI Standard and technical reports that would satisfy the technical or business requirement described in the MR.
X12 staff develops an initial impact assessment that describes the X12 products thought to be impacted by the MR and the individual references that may require revision within each product. The developing group validates or refines the initial impact statement such that all required revisions are included and described before the developing subcommittee votes to move its proposed revisions forward to X12J's technical review.
A maintenance benefit statement describes how the revisions associated with the MR enhance or improve the impacted EDI Standard or technical reports.
Once the developing group completes its analysis and assessment and the impact assessment instructions are accurate, clear, and complete, the project delegate composes a brief, high-level, non-technical summary of the functional enhancement achieved by the maintenance request. This brief statement should not exceed three sentences and is the basis for X12 informational and educational materials and change summaries. The maintenance benefit statement is not a restatement of the business requirement, use case, or impact assessment but instead should describe the benefit realized by the revision.
To ensure consistent use of terms, definitions, and acronyms across X12 products and activities, X12 maintains the Wordbook, a comprehensive corporate glossary. The Wordbook can be referenced online at wordbook.x12.org.
Yes, the MR process is based on individual tasks, worked start to finish as opposed to grouping all MRs for a period of time and working them as a set. This eliminates scope-creep and churning.
There is no maximum number of maintenance requests in one annual cycle. The maximum number is the total number of maintenance requests that X12 groups can complete in any given year.
MR numbers are assigned during the submission process.
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 PRB’s agreement with the disapproval.
MRs are not targeted for a specific version. Instead, MRs are worked expeditiously and once approved are applied to the next release of the affected products.
Developing subcommittees are generally expected to work the requests in the order received. To ensure each request is given timely consideration, developing subcommittees are only assigned a certain number of maintenance requests at any one time. Other maintenance requests for the developing subcommittee are held in a queue managed by X12 staff.
Developing subcommittees are generally expected to work the requests in the order received. To ensure each request is given timely consideration, developing subcommittees are only assigned a certain number of maintenance requests at any one time. Other maintenance requests for the developing subcommittee are held in a queue managed by X12 staff.
In general, work is expected to be completed on a first-in-first-out basis, however, when a developing subcommittee is assigned more than one MR it may prioritize among those requests so long as all maintenance requests are addressed in a timely fashion.
X12 Member Representatives can view the online MR list and details about the MRs at mr.x12.org.
The website is updated twice a month, during the first and third weeks of each month. The date of the last update is listed after the webpage title.
The symbol is a visual indication of whether the MR impacts just the EDI Standard, just one or more technical reports, or both. The legend below explains each symbol.
Legend: ⊙=TR, ✱=Standard, ⊛= Both
- On Hold
MR is on hold until a precondition is met. The condition is noted on the MR's detail page. - PRB Review Period
PRB is reviewing and voting on whether to accept the MR and the developing subcommittee assignment. - X12J Initial Review
X12J is reviewing the MR to verify agreement with the developing subcommittee assignment. - Assemble Initial Impact Assessment
Staff are assessing and documenting the MR’s potential impact on the EDI Standard and associated technical reports. - In Development
The developing subcommittee is analyzing the MR and defining a proposed response or solution. - Work Group Approved
The developing subcommittee assigns MRs to a work or adhoc group and that group has agreed on a proposed response or solution. The response or solution is ready for a subcommittee ballot or a subcommittee comment period. - Subcommittee Comment Period
the developing subcommittee is reviewing the work or adhoc group’s proposed response or solution and providing feedback for consideration by the work or adhoc group. - Subcommittee Ballot in Process
The developing subcommittee is voting on a motion to move the proposed response or solution forward for technical review. - X12J Technical Review
X12J is reviewing the proposed MR solution for technical compliance. - Proposed for Ballot
X12J recommended PRB approve an ASC ballot on the proposed MR solution. - ASC Ballot in Process
The ASC is voting on a motion to move the accept the response or solution. - Approved by the ASC
The proposed solution has been approved by the ASC and the revisions identified in the MR's Impact Assessment will be applied to the next version of the appropriate X12 product(s). - Disapproved by the ASC
The proposed solution has been disapproved by the ASC. The MR either returns to the developing subcommittee for corrections or revisions to the proposed solution or the disapproval is final. If the disapproval is final, the submitter is notified of the disapproval and no further action is taken. - Cancelled
The MR has been cancelled by PRB based on a determination that the request is not under X12's purview, is not a viable request to revise an X12 product, as been withdrawn by the submitter, or otherwise doesn't conform to X12's definition of an appropriate maintenance request. The submitter will be notified and no further action will be taken. - Withdrawn
The MR has been withdrawn by the submitter and no further action is taken. - MR Applied
The revisions identified in the MR's Impact Assessment have been applied to the appropriate X12 product(s) in the version noted in the MR details.
The MR information at mr.x12.org is initially displayed as a summary list. Click on an MR in the list to view the details related to that MR.
All MRs are listed when the webpage opens. To view just the MRs in a particular status, click the "By Status" filter at the top of the MR list and then select a status from the list. To restore the complete list, select "All" from the "By Status" filter.
All MRs are listed when the webpage opens and when "All" is selected from the "By Status" filter. MRs are assigned to one subcommittee, known as the developing subcommittee. To view the MRs assigned to a specific subcommittee, click the "By Subcommittee" filter at the top of the MR list and then select a subcommittee from the list.
Per X12 policies and procedures, the developing group can begin working on an MR after certain preliminary steps are completed. MRs with a status of "In Development" are ready for an X12 developing group's action.
A subcommittee's primary X12J representative notifies the subcommittee chair or an assigned project delegate that an MR is assigned to the subcommittee and ready for subcommittee action.
X12 staff notifies the subcommittee's primary X12J representative via email when an MR is ready for subcommittee action.
As has long been the case, the developing subcommittee may seek technical assistance from X12J or X12C during development and may request an informal X12J or X12C review to discuss potential technical issues at any time. To request assistance or a review, the MR project delegate works with the developing subcommittee's X12J representative or X12C liaison who coordinates the collaboration between the subcommittees. In either case, X12 staff is available to assist with the coordination as requested.
Yes, once the developing group's analysis, assessment, and documentation are completed, the project delegate is responsible for ensuring a subcommittee-level ballot is conducted.
Once the developing group has approved an MR for X12J technical review, other ASC subcommittees have an opportunity to review the MR, including the impact assessment and maintenance benefit statement. The subcommittees follow their subcommittee-level processes related to reviewing an MR developed by another subcommittee.
Before an MR is moved to an "In Development" status, X12 staff develops an initial impact assessment. During the developing group's analysis and determination steps, the developing group validates or refines the initial impact statement.
It is the developing group's responsibility to ensure the impact assessment approved for X12J technical review is accurate, clear, and complete. This may include updating the initial impact assessment by adding or deleting rows or by changing the instructions entered for changing an individual reference in an X12 product.
If the group determines that the impact assessment needs to be updated, the MR's project delegate needs to inform staff of the necessary revisions. X12 expects to have a more direct way to update impact assessments in the future, but for now, the project delegate uses email to notify X12 of impact assessment revisions. A request to change an impact assessment submitted by someone other than the MR's project delegate will be disregarded.
To add, change or delete rows on an impact assessment, the project delegate sends an email to support@x12.org with the MR #, the impact assessment row number, and a clear description of the change to be applied. Note that the instructions entered into the impact assessment are neither a comparison of the current and new content nor a justification of the revision. The impact assessment only notes the new work product content that satisfies the MR's stated need or requirement.
The MR's project delegate submits the maintenance benefit statement to X12 staff. X12 expects to have a more direct way to update maintenance benefit statements in the future, but for now, the project delegate uses email to communicate with staff. A request to change maintenance benefit statement submitted by someone other than the MR's project delegate will be disregarded.
- The project delegate sends an email to support@x12.org with the MR number and the maintenance benefit statement.
- If necessary, staff will work with the project delegate to ensure the maintenance benefit statement wording can be used as intended if the MR is approved.
A subcommittee's primary X12J representative may need to change the project delegate assigned to an MR. X12 expects to have a more direct way to update project delegate information in the future, but for now the X12J representative uses email to notify X12 of such a change. A request to change an MR's project delegate submitted by someone other than the developing subcommittee's primary X12J representative will be disregarded.
To change an assigned project delegate, a primary X12J representative sends an email to support@x12.org with the MR number along with the name and email address of the new project delegate.
Staff makes an initial assignment as part of preparing the MR for PRB review. PRB has the final say on the assignment.
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 Standards Development Manual (ASC02) governs the process prior to and following X12N’s specific steps.
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 Standards Development Manual (ASC02) and X12N specific governance is detailed in section 5.3 of X12N Maintenance Request Processing (ASC95).
The ASC Standards Development 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 ensure a group of subject matter experts who cover all aspects of the MR focus on each 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.
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 committee ballot on each MR after X12J completes a technical review of the proposed solution and PRB confirms due process.
Because maintenance requests have a short timeline and focused scope, there is no public review step.
No, since an MR can be processed in as little as three months a “Fast Track” exception is not necessary.
You can enter a maintenance request with the Maintenance Request Form.
X12 member representatives can review MR information on mr.x12.org. The webpage help includes 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.
As is the case today, the developing subcommittee’s X12J representative is responsible for ensuring that 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.
X12’s processes related to HIPAA mandate recommendations are separate and outside the scope of the MR process.
MRs are voted on at several levels:
- The developing subcommittee votes to move the MR to X12J for technical review..
- X12J votes to recommend PRB approve an ASC committee ballot.
- PRB votes to approve the MR for an ASC committee ballot.
- ASC Stakeholders vote on the MRs proposed solution.