Correction Policy

2202.11 - Correction Policy (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) HHAs have the ability to electronically correct nearly all errors found in their production OASIS submissions. SAs should not be accepting requests for manual key field changes. Instead, HHAs should use the inactivation procedures to correct assessments containing key field errors. HAVEN 5.0 and above will give HHAs the ability to electronically correct nearly any kind of assessment errors. CMS strongly recommends that all HHAs install the most updated version of HAVEN. OASIS HAVEN software may be adjusted over time to incorporate changes in system components as well as incorporate bug fixes. Adjustments will be posted to the HAVEN Data Entry Software web page on the CMS Web site at: http://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment- Instruments/OASIS/index.html?redirect=/oasis/and on the OASIS State Systems. Key Fields and Non-Key Fields A description of key fields is below. Non-key fields are all other fields making up the OASIS data set that are not key fields. KEY FIELDS Patient Identifiers: M0040_PAT_LNAME Patient last name M0040_PAT_FNAME Patient first name M0064_SSN Patient social security number M0066_PAT_BIRTH_DT Patient date of birth M0069_PAT_GENDER Patient gender HHA Identifiers: HHA_AGENCY_ID Unique Agency ID code Assessment Event Identifiers: M0100_ASSMT_REASON Reason for completing assessment M0090_INFO_COMPLETED_DT Date assessment information completed (This is a key field only on recertification or follow-up assessments where RFA = 04 or 05) M0030_START_CARE_DT SOC date (This is a key field only on SOC assessments where RFA = 01) M0032_ROC_DT ROC date (This is a key field only on ROC assessments where RFA = 03) M0906_DC_TRAN_DTH_DT Discharge, transfer, death date (This is a key field only on transfer to inpatient facility assessments where RFA = 06 or 07, death at home assessments where RFA = 08 and discharge assessments where RFA = 09) HHAs can electronically correct key field errors in production records in addition to non- key field errors and also remove erroneous records using an automated methodology called inactivation. With the ability to inactivate erroneous OASIS assessments, as described below, HHAs will be able to remove assessments from the OASIS State System’s active database that have been submitted in error. These records are not actually deleted, but are moved from the active database to a history database that contains records that have been modified or inactivated. This approach keeps an audit trail of modified and inactivated records, but “hides” them from the normal OASIS State System reporting procedures. 2202.11A - Determining When to Inactivate an Assessment (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) If an error has been made in one or more key fields, or if an assessment was submitted in error, the HHA should electronically inactivate it. Use of the inactivation procedure is not applicable to correcting assessments with only non-key field errors. In other words, if an assessment contains errors in only non-key fields, then correction type 3 described at C.3. below should be used. In order to determine whether to submit an inactivation request, the user should apply the following rules: 1. Assessment Submitted in Error If an assessment was submitted in error (i.e., it should never have been submitted), it must be inactivated. For example, if a discharge assessment was submitted by the therapist; however, the patient is still being visited by the nurse, an inactivation request must be submitted for the erroneous discharge record. Another reason to inactivate an assessment would be if the submitted assessment contained the wrong patient name. 2. Error in Key Field If an assessment was submitted which contained an error in any of the key fields listed above, then an inactivation request must be submitted. Normally, the HHA will also submit a new, corrected assessment in this situation. For example, if the HHA discovers that the patient’s last name on the SOC assessment is spelled “Smyth,” while on the Follow-up assessment it is spelled “Smith,” it needs to make the appropriate correction. When the HHA determines the discrepancy, the incorrect record must be inactivated and a new corrected record must be submitted. 3. Submission of Incorrect Format Private Pay assessments are now rejected upon submission and do not require inactivation. NOTE: There is no automatic mechanism to reactivate a record that has been inactivated. Consider the case where a discharge assessment is submitted to the OASIS State System for a patient, but is inadvertently inactivated. There is no means to “undo” the inactivation and thereby “reactivate” this discharge. Instead the HHA must submit the discharge record again. An inactivated record can only be “undone” by the re-submission of the record. 2202.11B - Deleting Assessments (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) In certain infrequent situations, inactivation is not sufficient to correct assessment errors since inactivation alone does not remove the assessment record from the OASIS System. Two situations require deletion of an erroneous assessment, rather than inactivation. States will need to continue to submit deletion requests on behalf of HHAs, upon request, to the CMS Division of National Systems (DNS) contractor when the following situations occur. 1. Assessment Deletion The HHA submits identifiable data on patients not defined by the OASIS system of records. The OASIS repository is limited to the collection of identifiable data on patients who are Medicare and/or Medicaid patients receiving skilled care with certain exceptions, i.e., under 18 and maternity patients. In instances where the OASIS System has received OASIS data on patients not included as part of the OASIS System of Records, the data needs to be deleted. EXAMPLE: The HHA checks Response 1, 2, 3, and/or 4 in the Current Payment Source (M0150 field) for that assessment record and it should not have. The record is transmitted to the OASIS System and accepted. The HHA determines that the response for M0150 is in error. The patient was not a Medicare or Medicaid patient; therefore, this data should not be stored on the OASIS database. EXAMPLE: The HHA submits an incorrect birth date on a patient who is a year old, which was accepted because the birth year identified the patient as being over 18. The patient was actually under 18 and the assessment should be deleted. Deletion Request forms are located on the State password protected Page of the QTSO website. CMS requires the signature of the agency administrator and of the SA before the deletion will be processed. The HHA must send the Deletion Request Form in writing to the State OASIS coordinator to request deletion of an assessment. The State will then send in writing to DNS contractor, the reason this data should be removed from the State’s database. *Effective dates are: M0030_START_CARE_DT for RFA types 01; M0032_ROC_DT for RFA type 03; M0090_INFO_COMPLETED_DT for RFA types 04 & 05; and M0906_DC_TRAN_DTH_DT for RFA types 06, 07, 08, & 09. 2. File Deletion The HHA submits a file as “Production” data instead of “Test” data. The State must verify the HHA’s claim of “Production” data versus “Test” data. The HHA must send the following information in writing to the State coordinator to request deletion of a file: ● HHA Name; ● HHA ID; ● Submission Date/Time; ● Submission Batch ID; and ● Reason this data should be removed from the State’s database. The State will then send in writing to the CMS contractor following information to request deletion of a file: ● HHA Name; ● HHA ID; ● Submission Date/Time; ● Submission Batch ID; and ● Reason this data should be removed from the State’s database. The following events will then take place: The CMS DNS Contractor will create a report from the above listed information. This report will be sent to the State OASIS Coordinator for him/her to verify the accuracy of assessment(s) to be deleted from the State’s database. ● The OASIS Coordinator will notify the CMS DNS contractor that the information is accurate and should be deleted from the State’s database. ● The CMS DNS contractor will consult with CMS on any questionable deletion requests. ● The CMS DNS contractor will delete the data upon approval from CMS. ● The CMS DNS contractor will keep a log of all deleted data from each State’s database. The deletion request information should be communicated to the CMS DNS contractor by one of the following methods of communication: The Deletion Request Form directs states to forward the signed form to the CMS DNS contractor via certified mail to the address on the form. The deletion request sheets must be submitted to the CMS DNS contractor by the State. Requests received directly from HHA will not be accepted. NOTE: This information MUST NOT be sent via e-mail due to the confidentiality of the information. 2202.11C - Types of Corrections an HHA Can Make in HAVEN (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) HAVEN offers the following menu of corrections an HHA can make: 1. Assessment was Submitted to the State and was Rejected The HHA can unlock the assessment, make the necessary changes, and re-submit it. Because of the built-in edit checks, HHAs using the HAVEN software should not expect records to be rejected by the OASIS System for this reason. Note that the following examples are provided for illustration purposes to troubleshoot HAVEN-like software, but cannot occur in HAVEN. EXAMPLE 1: The HHA Agency ID field in one or more assessment records does not match the HHA Agency ID in the header record of the submission file. The entire submission file is rejected and no data is loaded into the state database. EXAMPLE 2: The patient’s last name was missing from the assessment file (data record). The HHA may have inadvertently left this field blank. The OASIS System must have the patient’s last name. The data record in this example would be rejected and no data from this record would be loaded into the state database. In these examples, the HHA would make the necessary corrections and re-submit the record. Since the OASIS System never accepted the original assessment, the correction number field IS NOT incremented in this situation. HHAs may still receive a warning if submission/timing guidelines have been exceeded. 2. Assessment was Submitted to the State and was Accepted. Correction to Key Fields is Necessary With the implementation of the OASIS System update, this option will display in HAVEN but will no longer be available and is disabled in the HAVEN software. To correct an assessment with key field errors, first inactivate the assessment, then create a new assessment for re-submission, as applicable. See correction type 4 below. 3. Assessment was Submitted to the State and was Accepted. Correction to Non-Key Fields is Necessary If an HHA determines that a correction(s) must be made to non-key fields only (i.e., any fields in the OASIS data set not contained in the key fields listed above), the HHA should re-open the assessment, revise the targeted non-key fields, and re-lock and re- submit the corrected record. The lock date changes to reflect the date the correction was made. NOTE: “CORRECTION_NUM” is a counter field contained in the programming of the HAVEN software used to track corrections made to an assessment record. The counter field is set to 00 when an assessment record is initially locked. The counter field is incremented in this case. Both the original assessment and the corrected assessment will be stored in the state database. 4. Assessment was Submitted to the State and was Accepted. Inactivation of the Assessment is Necessary This is an option in HAVEN that allows HHAs to correct key field errors by inactivating the assessment(s) containing key field errors and re-submitting a new, corrected assessment. Unlike making non-key field changes, as described in correction type 3 above, the HHA does not simply unlock the assessment record, make the necessary key field changes, re-lock the record, and re-submit it. Instead, the HHA is taken directly to the assessment in question where it can be viewed in a read-only format. While in read-only mode, when the HHA confirms that the assessment should be inactivated, HAVEN will ask the HHA to commit to this selection. The correction number field on the HAVEN Management screen displays an “X” and the assessment status is set to Export Ready.” The “value of ‘99’” indicates that this assessment has been inactivated. When the HHA selects this correction type, a copy of the original assessment record is created. To re-submit the assessment with the necessary corrections, the HHA first exports the assessment that is being inactivated. From the HAVEN Management screen, the HHA then selects the inactivated record in question and clicks on the “Correct Assessment” button. A pop-up box will appear asking if the HHA wants to create a new assessment containing data from the inactivated assessment. When the HHA clicks on the “OK” button, a copy of the original assessment appears. The HHA makes the necessary changes and re-submits the assessment. The correction number for this assessment is reset to 00. 2202.11D - Documentation of Corrected Assessments (Rev. 1, 05-21-04) When a comprehensive assessment is corrected, the HHA must maintain the original assessment record as well as all subsequent corrected assessments in the patient’s clinical record in accordance with current clinical record requirements at 42 CFR 484. If maintained electronically, the HHA must be capable of retrieving and reproducing a hard copy of these assessments upon request. It is acceptable to have multiple corrected assessments for an OASIS assessment, as long as the OASIS and the clinical record are documented in accordance with the clinical record requirements at 42 CFR 484. 2202.11E - Clinical Implications of Corrected Assessment Records (Rev. 1, 05-21-04) When corrections are made to an assessment already submitted to the OASIS State System, the HHA must determine if there is an impact on the patient’s current care plan. If there is an impact, in addition to the correction made to the assessment, the HHA must make corresponding changes to the current care plan. If there are any other records where the correction has an impact, for example, the Home Health Resource Group, the Plan of Treatment (CMS Form-485), or the Request for Anticipated Payment, the agency should make corresponding changes to that record, as applicable. The agency should establish a procedure to review the impact of any corrections made to assessment records and make corresponding changes to other records that are affected. 2202.11F - Regarding Corrections in Lieu of Required Assessments (Rev. 1, 05-21-04) Collection and submission of information on SOC, ROC, Follow-up, Other Follow-up, transfer, and discharge assessments are required by the comprehensive assessment requirements at 42 CFR 484. The correction process described here does not preclude the need for accurate patient assessment at the required time points. The inactivation of an assessment and subsequent correction and re-submission of a new assessment, or a correction to a non-key field cannot be used in lieu of the appropriate OASIS assessment for documenting an unanticipated change in patient condition that was not envisioned in the original plan of care. If there is an unexpected change in the patient’s clinical condition due to a major decline or improvement in health status that warrants a change in plan of treatment, the appropriate OASIS assessment is expected to document the change, i.e., the ROC or Other Follow-up assessment, as appropriate. This is in keeping with the regulation at 42 CFR 484.20(b) for accuracy of encoded OASIS data that states, “The encoded OASIS data must accurately reflect the patient’s status at the time of assessment.” The HHA should have one document for the patient’s assessment, care planning, and payment purposes. 2202.11G - Timeliness of Corrections (Rev. 125, Issued: 10-31-14, Effective: 10-31-14, Implementation: 10-31-14) HHAs are urged to make corrections and/or submit inactivations as quickly as possible after errors are identified so the state system will be as current and accurate as possible prior to HHA submission of the RAP. This also affects the data used to calculate the HHA’s OBQI and OBQM reports. 2202.11H - Multiple Corrections in a Record (Rev. 1, 05-21-04) Correcting assessments with key field errors can only be done by inactivating the incorrect assessments and replacing them with the corrected assessments, as previously described above. Correcting assessments with non-key field errors can only be done by re-opening the assessment, revising the targeted non-key fields, re-locking and re-submitting the assessment, as previously described above. “CORRECTION_NUM” (the counter field) is implemented in non-key field changes. For more specific information concerning the process of correction and inactivation, refer to the OASIS data specification notes on the OASIS web site. See below for a flow chart depicting the most common situations necessitating corrections