(General Information, Eligibility, and Entitlement Manual)

Notes  Reference ( and )  Comments                                 Facility Standards for Records Storage Facilities  Supplemental Check Lists: Appendix A and Appendix B   Compliance with Federal Facility Security Standards, Level III  (36 CFR Part 1228 Appendix A) (Complete for ALL facilities)  Citation  Requirement  OK No Part S1 Control of facility parking     S2 Receiving/shipping procedures     S3 Intrusion detection system with central monitoring     S4 Meets Life Safety Standards     Citation  Requirement  OK No Part S5 Adequate exits from records storage areas     S6 High security locks on entrances/exits     S7 Visitor control/screening system     S8 Prevent unauthorized access to utility areas     S9 Provide emergency power to critical systems     S10 Conduct background security checks and/or establish security control procedures for service contract personnel      Compliance with 36 CFR Part 1228 Appendix B  (Complete this section ONLY if the facility claims to be using the system described in Appendix B)  Paragraph  Requirement  OK No Part 2a. The records storage height must not exceed the nominal 15 feet (+/ -3 inches) records storage height.     2b. All records storage and adjoining areas must be protected by automatic wet pipe sprinklers.     2c.1 1. The sprinkler system must be rated at no higher than 285 degrees Fahrenheit utilizing quick response (QR) fire sprinkler heads.     2c.2 2. The sprinkler system must be designed by a licensed fire protection engineer to provide the specified density for the most remote 1,500 square feet of floor area at the most remote sprinkler head in accordance with NF PA 13 (1996), Standard for the Installation of Sprinkler Systems.     2c.3 3. Installation of the sprinkler system must be in accordance with NFPA 13 (1996), Standard for the Installation of Sprinkler Systems.     2c.4 4. Contractors Material and Test Certificates per NFPA 13 chapter 8.     2c.5 5. Hydraulic Calculations.     2d.1 1. Maximum spacing of the sprinkler heads must be on a 10-foot grid.     Paragraph  Requirement  OK No Part 2d.2 2. The positioning of the heads must provide complete, unobstructed coverage, with a clearance of  not less than 18 inches, but not more than 60 inches, from the top of the highest stored materials.     2e. The sprinkler system must be equipped with a water -flow alarm connected to a continuously staffed fire department or central station, with responsibility for immediate response.     2f.1 1. A manual fire alarm system must be provided with central station services or other automatic means of notifying the municipal fire department.     2f.2 2. A manual alarm pull station must be located adjacent to each exit.     2g. All water cutoff valves in the sprinkler system must be equipped with automatic closure alarm connected to a continuously staffed station, with responsibility for immediate response.     2h. A dependable water supply free of interruption must be provided.  This normally requires a backup supply system having sufficient pressure and capacity to meet both fire hose and sprinkler requirements for 2 hours.    2i. Interior stand- pipe stations equipped with 1  inch diameter hose m ay be provided in the records storage areas if required by the local fire department, enabling any point in the records storage area to be reached by a 50-foot hose stream from a 100- foot hose lay.  If hose is provided, the cabinets must be marked For Fir e Department Use Only.     2j. Where fire hose cabinets are not required, stand -pipes must be provided at each floor landing in the building core or stair shaft.  Hose outlets must have easily removable adapter and cap.  Threads and valves must be compati ble with the local fire departments equipment.  Spacing must be so that any point in the records storage area can be reached with a 50 -foot hose stream from a 100-foot hose lay.     Paragraph  Requirement  OK No Part 2k. In addition to the designated sprinkler flow demand, 500 gpm must be provided for hose stream demand.  The hose stream demand must be calculated into the system at the base of the main sprinkler riser.     2l.1 1. Fire hydrants must be located within 250 feet of each exterior entrance or other access to the records center that could be used by fire -fighters.     2l.2 2. All hydrants must be at least 50 feet away from the building walls and adjacent to a roadway usable by fire apparatus.  Fire hydrants must have at least two 2 - inch hose outlets and a pumper connection.  Al l threads must be compatible with local standards.     2m. Portable water -type fire extinguishers (2 gallon stored-pressure type) must be provided at each fire alarm striking station (see also NFPA 10).     2n.1 1. Where provided, the walking surface of the catwalks must be of expanded metal at least 0.09- inch thickness with a 2 -inch mesh length. The surface opening ratio must be equal or greater than 0.75.    2n.2 2. The sprinkler water demand for protection over bays with catwalks where records are not  oriented perpendicular to the aisles must be calculated to give 0.3 gpm per square foot for the most remote 2,000 square feet.     Notes  Reference  Comments              Reference  Comments             40  Shared System Maintainer, Part A/Part B (A/B)/Durable Medical Equipment (DME) Medicare Administrative Contractor (MAC) and the Single Testing Contractor (STC) Responsibilities for System Releases  (Rev. 97, Issued: 01- 15-16, Effective: 09 -21-15, Implementation: 09- 21-15)  40.1  Standardized Terminology for Cl aims Processing Systems (Rev. 97, Issued: 01- 15-16, Effective: 09- 21-15, Implementation: 09- 21-15) (Rev. 105 , Issued: 06 -02-17, Effective: 07- 03-17, Implementation: 07- 03-17)  The SSMs, MACs and the STC shall use standardized terminology to refer to common systems maintenance elements in all discussions, reporting, and documentation. Using common terminology will minimize confusion and misunderstanding for CMS, SSMs, MACs and the STC.  The MACs and the STC shall examine their use of the system status inform ation issued by the SSMs to determine if they have internal applications that need to be adjusted to adopt the standardized terminology. If they have internal systems or processes that must be modified to reflect the standardization required by this instru ction, they shall make those changes to coincide with the shared system changes.   40.1.1 - Standard Terminology Chart  (Rev. 105, Issued: 06 -02-17, Effective: 07- 03-17, Implementation: 07- 03-17)   STANDARD TERMINOLOGY  DESCRIPTION  QUESTION (QCN)  Request for assistance and/or reported potential system problem. For questions, the MACs and the STC shall contact the SSMs helpdesk to log their question.  PROBLEM  Confirmed system and/or documentation problem  Change Request (CR)  Any software modification made to the system as a result of a CMS mandate or maintainer initiated action  CMS STATUS  CMS needs take action by answering a question, finalizing an instruction, etc.  NSC (non- system change) STATUS  CMS CR does not require shared system change. May require A/B MAC maintenance  RESEARCH STATUS  The SSM completes high level review of required changes by analyzing them and determining the intent of the change request  REQUIREMENTS (REQS) STATUS  The SSM finalizes the business requirements  WALKTHROUGH STATUS  The SSM presents the systems solution to the CR in a structured walkthrough discussion with CMS and Beta testers  WORK STATUS  The SSM completes technical design, coding and unit testing the system change     STANDARD TERMINOLOGY  DESCRIPTION  ALPHA TESTING  Functional testing performed by the SSM, after successful unit testing of the new or modified code; which   starts approximately ninety (90) days prior to the implementation of the Change Request.  The testing verifies all changed components function appropriately within the full environment at the SSM site in a controlled environment.    BETA TESTING  This is the second phase of testing after Alpha testing. The goal of Beta testing is to identify and resolve any remaining defects before a product/software is released to a production environment. Beta testing begins eight weeks prior to the production implementation date of a quarterly release. The Beta tester continues to test all iterations of the code through the UAT testing phase until the release moves to production. The Beta tester continues to test for two weeks post production or until they are 100% completed, whichever comes first.  User Acceptance Testing (UAT)  MACs and DME MACs perform UAT testing during the four weeks prior to the production impl ementation date of a quarterly release.    USER STATUS  The SSM returns question to user to provide more information or examples, assess solution    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.  Uns cheduled 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 C lassifications for Follow -Up Releases   Listed below are CMSs 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 incomplet e 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 pay ment 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.     EXAM PLES:    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   Priori ty 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