Release Software

40.2 - Release Software (Rev.: 128, Issued: 11-01-19, Effective: 12-03-19, Implementation: 12-03-19) Shared System Maintainers (SSMs) shall obtain approval from their Government Task Leader (GTL) before quarterly release software can be scheduled and installed. Control of System Changes SSMs shall use the same quarterly release schedule, (i.e., on or about October 1, January 1, April 1, and July 1). CMS will schedule each quarterly release. All follow-up release changes (except emergencies) to the quarterly schedule shall be held and released on a predetermined schedule in coordination with CMS. Unscheduled emergency changes released as problems are identified without prior approval. The schedule for a follow-up release of changes shall be forwarded to your GTL for prior approval. When a system problem is identified, Medicare contractors (i.e. SSMs, the STC, MACs and CWF Hosts) shall submit documentation to their GTL outlining the problem and the reason correction is needed at this time. Section V of this instruction outlines the minimum information required by CMS for approval. Problem Priority Classifications for Follow-Up Releases Listed below are CMS’s problem priority classifications and examples. Priority 1 Classification Production: The problem prevents the accomplishment of a mission critical capability for which no acceptable workaround is known.* This priority also includes problems where code shall be fixed immediately in order for the normal production region functions or services to continue. For example, if the production region is down in a job resulting in an incomplete cycle or the system is pricing a significant volume of claims incorrectly causing over or under payment. These corrections shall be reported to the GTL the next business day. EXAMPLES: • ABENDS on-line or batch (Inability to run a cycle) • Inaccurate payment or no payment of claims (significant impact/high volume) • Necessary file updates cannot be accomplished (payment files, history files) • Interface failures affecting claims processing Beta/User Acceptance Testing: The problem would prevent the accomplishment of a mission critical capability if the current test software is moved into the production environment. This priority also includes problems where code shall be fixed immediately in order for the normal test region functions or services to continue. For example, if the test region is down in a job causing the cycle to not complete or the system is pricing claims incorrectly with a potentially significant claim volume or payment impact, the issue would be classified as a priority 1. EXAMPLES: • ABENDS; inability to run a cycle or test • Inaccurate payment or no payment of claims (potentially significant impact) • Necessary file updates cannot be accomplished (payment files, history files) • Interface failures affecting test conditions Priority 2 Classification Production: The problem adversely affects the accomplishment of a mission critical capability so as to degrade performance and for which no acceptable work-around is known.* This means the problem adversely affects the payment of benefits with a small claim volume or payment impact, the completion of CMS required reporting, or inaccurate information is being sent providers, beneficiaries or CMS. For example, if the information on an outgoing document to the provider community or Medicare Summary Notice is incorrect, the issue would be classified as a priority 2. EXAMPLES: • Inaccurate payment or no payment of claims (small impact/low volume) • Inaccurate CMS required report • Inaccurate messages to the beneficiary, provider or CMS • ABENDs with limited impact (e.g. one contractor) Beta/User Acceptance Testing: The problem would adversely affect the accomplishment of a mission critical capability so as to degrade performance if current test software is moved into the production environment. This means the problem adversely affects the payment of benefits with a potentially small claim volume or payment impact, the completion of CMS required reporting, or inaccurate information is being sent to providers, beneficiaries or CMS. For example, if the information on an outgoing document to the provider community is incorrect, the issue would be classified as a priority 2. EXAMPLES: • Inaccurate payment or no payment of claims (potentially small impact) • Inaccurate CMS required report • Inaccurate messages to the beneficiary, provider or CMS Priority 3 Classification Production: The problem adversely affects the accomplishment of mission critical capability so as to degrade performance and for which an acceptable workaround is known.* This means the problem could have significant impact but the work-around alleviates the impact. This allows the system maintainer adequate time to code a fix and sufficiently test before the corrected software is delivered for production installation. EXAMPLES: • Impact of problem could be significant or minimal • Problem correctable by contractor workaround* • ABENDs with an acceptable workaround* Beta/User Acceptance Testing: The problem would adversely impact the accomplishment of a mission critical capability so as to degrade performance if current test software is moved into the production environment. If moved into the production environment before correcting an acceptable workaround could be instituted to prevent the adverse impact. ** EXAMPLES: • Potential impact of problem could be significant or minimal • Problem affects CMS required reporting Priority 4 Classification Production: The problem is an operator inconvenience or annoyance, which does not affect a required mission essential capability. EXAMPLES: • Problems affects non-mission critical functions • Operational procedure with workload impact that should be automated • Impact of problem is minimal • Correctable by contractor workaround* Beta/User Acceptance Testing: The problem is a test inconvenience or annoyance, which does not affect a required mission essential or test capability. If moved into the production environment before correcting, an acceptable workaround could be instituted to prevent the inconvenience. ** EXAMPLES: • Problem affects non-mission critical functions • Operational procedure with workload impact that should be automated • Impact of problem is minimal • Correctable by contractor workaround* Priority 5 Classification Production: All other documented system problems. These could include operator errors, an inability to reproduce the reported problem, a problem with insufficient information, or documentation errors. The system maintainer should request approval from the (GTL) before coding and implementing any system enhancements. EXAMPLES: • A/B and DME MACs requested enhancements • Documentation errors • Problem affects non-mission critical functions • Minimal impact Beta/User Acceptance Testing: All other documented system test problems. These could include operator errors, an inability to reproduce the reported problem, a problem with insufficient information, or test documentation errors. The system maintainer should work to correct these issues as soon as possible but any system enhancements should be discussed with the GTL. EXAMPLES: • Test region or processing enhancements • Test documentation • Problem affects non-mission critical test functions • Minimal impact * An acceptable workaround is a temporary alternative solution to a confirmed problem in the shared system that will ensure the contractor is able to accomplish a mission critical capability. What makes the workaround “acceptable” is it shall be agreeable to both the maintainer and contractor and does not cause an excessive burden to the contractor. If the maintainer and A/B and DME MACs cannot come to an agreement on what is “acceptable” the decision will be made by CMS. ** CMS does not recommend using workarounds in the test region in order to “pass” test cases. The institution of a workaround should be used in order to implement a CMS mandate where the system maintainer may not have time to adequately code a fix before the software is delivered for production installation.