OASIS State System

2202.12 - OASIS State System (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) The purpose of the OASIS State System is to provide computerized storage, access, and analysis of the OASIS data on patients in HHAs across the nation. The OASIS State System is intended to create a standard, nationwide system for connecting HHAs to their respective SAs for the purpose of electronic interchange of data, reports, and other information. The automated OASIS system is a critical component of SA and CMS operations. It is a key part of a fully integrated system of clinical data, facility demographics, survey findings, and SA operations information. The OASIS State System also provides the means for transmission of assessment data to CMS for validating payments under prospective payment for HHAs. The OASIS State System implementation involved a CMS-funded installation of standardized computer hardware and data management software at each SA to allow electronic transfer of OASIS data elements from all HHAs to the State. The data management software: Validates the basic accuracy of the data and rejects submission files (batches) with fatal file errors, such as a missing or invalid agency ID, incorrect record length, or missing headers or trailers; Validates individual assessment records and rejects those records with fatal record errors; Stores and reports non-fatal or warning errors on records that are accepted by the database; and Builds a database of OASIS information for all applicable patients of each HHA in the State. In accordance with the regulations, HHAs will collect SOC, ROC, follow-up, discharge to the community, transfer to an inpatient facility (with or without discharge), and death at home OASIS data on all patients (except those under 18; those receiving maternity services; and patients receiving only housekeeping or chore services) under the care of the HHA as of July 19, 1999, as applicable. The requirements for OASIS collection, encoding, and transmission apply to all Medicare and Medicaid patients, including Medicare and Medicaid HMO/Managed Care patients (with the exception of those listed above) receiving skilled services. The applicability of the comprehensive assessment and reporting regulations to patients receiving personal care only services, regardless of payer source, has been delayed until further notice. In addition, the collection, encoding and transmission requirement for non-Medicare and non-Medicaid patients receiving skilled care is also temporarily suspended until further notice. Until collection and submission of non-Medicare/non-Medicaid patient assessments is required, HHAs must meet all other requirements of the comprehensive assessment regulation including conducting SOC comprehensive assessments and updates at the required time points on all non-Medicare and non-Medicaid patients receiving skilled services, although the OASIS data items are not required. This means that only the requirement to collect, encode and transmit OASIS data is delayed. The completion of the comprehensive assessment and updates at the required time points is required in order to ensure quality of care for all patients and to encourage the use of OASIS as the basis for care planning. Effective August 24, 1999, and at least monthly thereafter, HHAs should transmit to the SA all applicable OASIS data collected and encoded from July 19, 1999, and monthly thereafter. Monthly transmissions should include all OASIS data encoded in the previous month. OASIS activities will provide enhanced analytical capabilities at the SAs; electronic transmission from the State databases to a national repository; integration with performance indicators for quality oversight and survey planning by the SA; a basis for maintaining prospective payment of HHAs; research directed at improving quality of care; feedback to providers; and dissemination of information to purchasers, beneficiaries, and others. 2202.12A - System Description (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) The CMS has provided each State with an OASIS State System composed of standardized hardware and software platforms scaled to meet each State’s anticipated processing volumes, and a standardized operating system. The hardware is comprised of a communications server, database server, the local area network, and other peripheral devices. The OASIS State System deployed to each State was specifically engineered and purchased to fulfill the OASIS requirements of §484 and §488, as well as to incorporate additional CMS provider assessment processes as they become effective, and operational support of Medicare and Medicaid Survey and Certification pursuant to §1864 of the Act. The system was designed with an emphasis on flexibility and integration, so that additional software components could be easily added to provide the States with new related functionality (such as outcome measures and expanded analytical reports), as well as applications that support future assessment processes for other provider types, and new capabilities to support survey and certification operations. Since each State’s OASIS system was specifically sized to accommodate these planned functions, the SA should not add other non-CMS prescribed applications or databases to it. 2202.12B - Administration Requirements (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) The OASIS State System in each State is part of a comprehensive, Quality Improvement and Evaluation System that will not only fulfill OASIS administration requirements, but also grow to support other assessment-based programs; quality and performance indicators; and new, integrated survey and certification data systems. The State should use the OASIS State System for editing, storing, and processing OASIS data to support CMS’ OASIS operating requirements within the State and to transmit the required OASIS data to the CMS OASIS repository. As noted above, the State may not add additional software applications to the OASIS system without a specific directive from CMS. The States are directly responsible for fulfilling requirements to operate the OASIS State System. However, the State may enter into an agreement with the State Medicaid agency, another State component, or a private contractor to perform day-to-day operations of the system. The State must obtain RO approval prior to entering into an agreement with another agency. Such agreements should address the following provisions: 1. Meets confidentiality requirements: Federal Privacy Act, 5 U.S.C. §522a; HIAA of 1996; other applicable Federal data acts; §1902(a)(7) of the Act; applicable State standards; and industry security standards; 2. Gives the SA real-time access to the system to fully support all OASIS-driven functions which will be required of the survey agency (e.g., quality indicator reporting, survey targeting, etc.), or if a contractor is performing analysis for SA contract, provides the details on how this is to be conducted; 3. Complies with the need for high capacity, fault-tolerant network connections to ensure reliable support for the SAs, CMS’ national database, and any other daily operations (e.g. Intermediary Medical Case Review, Office of the Inspector General or Department of Justice Fraud and Abuse activities), which will be affected by this system. Assures hardware will be properly maintained and upgraded as necessary to meet any future CMS or SA requirements. Assures adequate backup of all data; 4. Includes SA responsibilities for reporting OASIS data to a central repository at CMS. Designates responsibilities for edits and “cleanness” of data: • Designates responsibilities for generating and communicating facility error reports. • Describes what kinds of communication will be established, e.g., a State-specific Internet and/or Intranet web pages, newsletters, etc., their content, and who will produce/maintain/distribute these communications. If there is a separate database, designates who is responsible for operating and maintaining the CMS-provided equipment and who will assure the viability of the CMS database; 5. Lists responsibilities of contractor and/or State for training and support operations: Includes at least who will provide facility and OASIS software vendor startup training, and on-going customer/facility support/troubleshooting; provide internal training and daily user support within the SA; work with program staff to integrate the OASIS system into SA functions; train SA staff on aspects of analytical system (e.g., ASPEN upgrades and “performance measure/quality indicator” linked reports); handle System Operations - functions associated with transmission logging, error tracking and resolution, system archival, and process reporting; and designate who is responsible for determining facility transmission schedules; 6. Delineates how State will fund the monthly line charges associated with installation, maintenance, and transmission of the OASIS data from the facilities to the contractor and between the contractor and State, e.g., built into contract costs or is an outside ongoing cost to the SA; and 7. Specifies whether it is the contractor’s or the SA’s responsibility for systems maintenance for commercial “off-the-shelf” OASIS hardware and software components. NOTE: Standardized OASIS software components that are developed and distributed by CMS will be maintained and upgraded centrally by CMS. Under any such arrangement, the State must be guaranteed real-time, priority access to this system to fully support all OASIS functions. All CMS privacy and confidentiality requirements must be met. Off-site operation of the OASIS State System will require high capacity, fault-tolerant network connections to ensure reliable support for the State’s daily operations that will be affected by this system. The State also must use the OASIS State System for reporting OASIS data to the CMS central repository. To promote national consistency in OASIS system operations and troubleshooting, each State should designate one individual as the OASIS automation project coordinator. This person is CMS’ key contact within each State for managing OASIS State System issues and must be familiar with the use of the OASIS automation and transmission process. Technical knowledge of information systems is useful but far less critical than an understanding of the OASIS processes, good communication and project management skills, and the ability to educate and work with providers and vendors to ensure successful implementation of an automated process for all providers. The State should designate additional staff, including a System Administrator, to manage the technical aspects of running the OASIS State System and support staff to assist in processing corrections, answering routine user questions, assigning passwords, etc. With respect to systems maintenance, the OASIS State System installed in each State is comprised of commercial, off-the-shelf hardware, and software components that are generally covered under typical umbrella service agreements that the State may already have in place for maintenance of data processing equipment. Those OASIS software components that are developed and distributed by CMS will be maintained and upgraded centrally by CMS. The State will not be responsible for these software upgrades. To the extent that the State has developed customized external applications for using information obtained from the OASIS database (e.g., to support Medicaid payment), the costs of developing and maintaining these additional software applications (and any related hardware components) will not be funded through the survey and certification budget. 2202.12C - Validation and Editing Process (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) Each time an HHA accesses the OASIS State System and transmits an assessment file, it performs a series of three levels of validations: 1. Fatal File Errors • The first check examines the basic structure and integrity of the submission file. If there are fatal flaws in the file (batch of records), then the entire file is rejected and the HHA is notified of the reason for rejection in the “Initial Feedback Report.” In the event that a batch is rejected due to fatal file errors, the HHA will not receive a “Final Validation Report.” Fatal file errors are listed in the data specifications, which can be found on the OASIS Web site. Rejected files must be corrected and retransmitted. 2. Fatal Record Errors • If the file structure is acceptable, then each record in the file is examined individually for fatal record errors. These errors may cause an individual assessment within a submission to be rejected. Assessments that have fatal records are not stored in the database. The HHA is informed of fatal record errors on the “Final Validation Report.” OASIS data specifications outline the valid data requirements and are posted on the OASIS Web site. The Initial Feedback and Final Validation reports are available shortly following the submission of a file. 3. Non-Fatal or Warning Errors If there are no fatal record errors, the record is loaded into the State database and the record is further examined for non-fatal errors. Any non-fatal errors are reported to the facility in the “Final Validation Report.” Non-fatal errors include missing or questionable data of a non-critical nature, record sequencing, field consistency errors, invalid value, and range errors. The Initial Feedback Report is available immediately following the submission of a file. The HHA should obtain this report before logging off to ensure the submission has been processed. Since the Final Validation Report is not available for up to 48 hours after the Initial Feedback Report, the HHA may, based on experience, choose to obtain this report on a subsequent log on. The validations and edits described above fulfill all of CMS’ editing requirements under §488.68. Also, States may not modify any aspect of the CMS OASIS standard system, including these validations and edits, the Standard Record Layout, and the software code and specifications on which the system is based. States that use OASIS data for Medicaid payment may require additional assessment information not required by CMS’ OASIS system. Some States may impose additional edits on Medicaid assessments. However, a State may not interfere with, modify, or delay the transmission of records meeting CMS edit standards from a Medicare-certified or Medicaid-approved agency to the CMS OASIS standard system. Furthermore, the State may not impose any requirements that modify the clinical accuracy of CMS prescribed OASIS records, reports, or calculations. 2202.12D - Reports (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) The OASIS State System provides reports to both the State and the provider. These reports, which focus on errors in OASIS submissions, are particularly key to working with agencies to ensure successful transmission of OASIS data. Refer to the State OASIS Administration Manual available on the QTSO Web site (http://www.qtso.com/) for information about specific reports provided. Monthly validation of OASIS submission is highly recommended for both states and providers as OASIS is required for payment, pay for reporting, and medical review. 2202.12E - Replication to the CMS Repository (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) Each State’s OASIS database will be transmitted to the CMS central repository at least monthly using a data replication process initiated by CMS. Since the process will be managed by CMS through an automatic polling process, the States will not actually have to transmit the data. However, the State must ensure that the CMS data line established for this purpose is accessible to CMS at all times for testing and monitoring purposes. Actual access to the Oracle assessment data tables may be controlled by the States but in such cases, CMS recommends that a fixed schedule be established with CMS central office. The OASIS State System and CMS data line meet all industry security standards. However, if the State is concerned about security, it may establish a firewall (an electronic block) to restrict access to the State’s portion of the network. Access must not be restricted to the CMS-supplied OASIS System. 2202.12F - System Security (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) As distinguished from confidentiality and privacy, which primarily focuses on the rules for release of information when it is authorized, security relates to the means by which the information is protected from “unauthorized” access, disclosure, and misuse. As part of the new requirements under §488.68, States must ensure that electronic data in the OASIS State System are protected to the same degree that paper records containing any identifiable data must be safeguarded. Additionally, any printed copies of reports from the system must be maintained in a secure locked area while they are needed and properly disposed of when no longer needed. States must issue a policy that defines and limits the qualifications for an individual to access the OASIS State System. The System Administrator must issue passwords and user identifications in strict adherence to those requirements. State personnel who receive passwords must be aware of the requirements of the State’s security policies and those of the System of Records and the Privacy Act. Passwords must be protected by the System Administrator and those receiving passwords. Passwords must be disabled at the time an individual exits a position requiring OASIS State System access. SAs are likewise reminded of the secure nature of passwords for the HHAs and must use due process to ensure the security of those passwords. State personnel should not leave the OASIS State System in a logged-in status when leaving the area. If possible, the system hardware should be located in an enclosed area, preferably with a door having interior hinges that can be locked. Keys or a combination lock should be available to only a minimum group of individuals with need for access to the system. In addition to the specific guidance above, the safeguards must provide a level of security at least equivalent to that required by the Office of Management and Budget Circular A- 130 (revised), Appendix III, Security of Federal Automated Information Resources. 2202.12G - Security of Transmission (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) OASIS data is encoded and transmitted from HHAs to SAs via the CMSnet, a private communications network CMS purchased to ensure the security of OASIS and MDS transmissions to the State. This system replaces the previous process of direct dial-up by public telephone lines to the SA and reflects the latest technology available for securing the privacy of data during transmission. Standard industry authentication is employed at each SA. Further security is provided at the SA by isolation of the receiving communications server from the actual storage site at the State (the MDS/OASIS Database Server). This serves effectively as a security firewall. Transmission of OASIS data from the SAs to CMS occurs via the CMS Virtual Private Network (VPN), which allows only authorized CMS staff access within this secure CMS infrastructure. The CMS has determined that the transmission of OASIS data through the process described above is fully compliant with all current Federal, Department of Health and Human Services, and CMS information system’s security requirements. The applicable Federal guidelines include The Computer Security Act of 1987, Federal Information Processing Standards promulgated by the National Institute of Standards and Technology pursuant to the Computer Security Act of 1987, the Office of Management and Budget Circular A-130 (revised), and Appendix III, Security of Federal Automated Information Resources. Per CMS policy, in the CMS Information Systems Security Policy, Standards and Guidelines Handbook, it is a violation of the CMS Security policy to send via email or fax: patient personally identifiable information, IP addresses, and both ID and password in the same document. CMS Security policy prohibits saving the login information in the Internet browser or sharing the personal login ID or the password with anyone else. 2202.12H - Provider Relations (Rev. 1, 05-21-04) With CMS technical support and guidance, the States work closely with the provider community and their OASIS software vendors in providing information on specific requirements related to the submission of OASIS assessments to the OASIS State System. The CMS expects that some vendors will provide primary support to HHAs in terms of OASIS encoding and transmission to the State repository. The State, however, must work with HHAs and software vendors in educating them about this process. The States must also provide training and technical assistance in interpretation of OASIS reports provided to HHAs.