OASIS Data Submission Specifications

In July, 2003 we published a draft of the version 1.40 OASIS data specifications. The final version of these specifications is now available below. Two changes have been made to the data specifications since publication of the draft version:

· A new section was added to page 22 of the data specifications notes (DS140.PDF). This new section ("Implementation of Version 1.40") clarifies the rule for implementation of the Version 1.40 specifications. This section was published as a "clarification note" on CMS's web site on June 19, 2003.

· A change was made to the consistency checks for the body record field VERSION_CD1. For details, refer to consistency note #1 for VERSION_CD1 in BD140.PDF.

In all other respects, this final version is identical to the draft version, except that the "draft" designation has been removed from all documents.

All assessment records with completion dates (M0090) on or after 10/1/2003 must conform to the version 1.40 specifications. Assessments with earlier completion dates must conform to the version 1.30 specifications (or to earlier versions, as appropriate).

When compared with earlier versions of the data specifications, version 1.40 incorporates two major features: (1) changes to the reporting of diagnosis codes, and (2) reporting of branch IDs. These changes are described below.

In order to insure that home health agencies can report ICD-9-CM diagnosis codes to be compliant with HIPAA, certain changes were made in V1.40 regarding the collection and encoding of diagnosis codes. These changes are planned for October 1, 2003. The table below summarizes the data specification changes that have been made.

Data Item	Data Specs Version 1.30	Changes in Data Specs Version 1.40
M0190	No E-codes or V-codes allowed (first character of code must be a space).	No change.
M0210	No E-codes or V-codes allowed (first character of code must be a space).	No change.
M0230	No E-codes or V-codes allowed (first character of code must be a space).	V-codes allowed (E-codes still not allowed).
M0240	No E-codes or V-codes allowed (first character of code must be a space).	V-codes and E-codes allowed.
M0245	Item added to printed copies of data set to illustrate how this new item will be used.� Not added to data specs.	Added to data specs. No E-codes or V-codes allowed (first character of code must be a space).

In prior versions of the data specifications, M0016 (branch ID) was an optional field. Even when reported by the HHA, there was no standardized numbering system for branches, so the information was not useful. CMS is in the process of assigning standardized branch IDs to every existing branch belonging to an HHA or subunit, and this process will be complete by the end of 2003. Version 1.40 of the data specifications requires that agencies report these standardized branch IDs in M0016 for all assessments with completion dates (M0090) on or after January 1, 2004.

The data specifications are being distributed in several zip files, each containing files in different formats:

Details are presented below about the contents of each of these files. Links below allow you to download each of these files.

The complete data specifications are presented in PDF format. The files included in each set are as follows:

Please read ds140.pdf first as this document provides background for all the other documents and files. The change document (ch140.pdf) describes all changes made since the prior version of the data specifications.

All of these documents are Adobe Acrobat(r) files. You must have the Adobe Acrobat(r) reader to view and print these files. The Adobe Acrobat(r) reader can be downloaded and distributed for free and is available from many sites on the Internet including the following:

In addition to the documents listed above, four files are included which may be helpful to programmers who need to implement the data submission specifications. All four of these files are in DBF format, which can be imported into most spreadsheet and database programs. Each DBF file contains one record for every field in the header, body, inactivation, or trailer record. For each field, the file lists the item name, the field length, and the starting and ending byte for the field. The files included are:

The HTML files enable you to view the OASIS data specs interactively on either a local drive or on a server using a standard browser.

The HTML files contain exactly the same information included in the PDF versions of the data specs. In addition, the HTML pages display the text and response options for each of the OASIS data items. An index list on the left-hand side of your browser screen allows you to move quickly from field to field, and the field summary allows you to view information such as field length and RFA requirements for all fields at once. Finally, any fields mentioned in consistency checks are hyperlinked, meaning that you can click on these references to view information about the field listed.

To use the HTML files, extract all of the files from the zip file into a new folder. You can then open the file INDEX.HTML to begin browsing the files. On most computers, you should be able to simply double-click on INDEX.HTML to activate your browser and open the file.

The HTML files have been tested with Microsoft Internet Explorer and Netscape Navigator. If you experience any problems using these files, please email the OASIS help desk for assistance.

The zip file A140.ZIP contains a single file: A140.MDB. This is a Microsoft Access database which was used to generate the data specification report files. This database is provided for programmers who may wish to use the tables for application development.

Each of these tables contains a field called Id which is a unique key. Users should be sure to sort these tables in ascending order by Id to get the records in their correct order.

Note that the SAS_only_fields table is used for CMS use and is not intended for use by outside developers.

P140.ZIP Data specifications in PDF format - 2.13 MB
D140.ZIP Data specifications in DBF format - 7K
H140.ZIP Data specifications in HTML format - 457K
A140.ZIP Data specifications in Access format - 216K

HHAs have the ability to electronically correct nearly all errors found in their production OASIS submissions. State Agencies do not make manual deletions. HHAs are instructed to use the inactivation procedures available since May 2001 to correct assessments containing key field errors.�

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.�

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 can remove assessments from the 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 state system reporting procedures.

If an error has been made in one or more key fields, or if an assessment was submitted in error, the HHA will no longer need to notify the state OASIS coordinator.� The erroneous assessment can and should be inactivated by the HHA. The inactivation procedure should be used if it is necessary to correct an assessment with errors in key fields.� 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 listed below should be used.

In order to determine whether to submit an inactivation request, HHAs should apply the following rules:

A. 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.

B. 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 start of care (SOC) assessment is spelled “Smyth,” while on the follow-up (FU) 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.

C. If an assessment was erroneously submitted in a masked format, that is, it was later discovered that the patient was a Medicare or Medicaid patient but was not originally indicated as such at M0150, then an inactivation must be submitted.�Normally, the HHA will also submit a new, corrected assessment in this situation.� For example, if the value at M0150 for a submitted and accepted assessment is not equal to 1, 2, 3, or 4, and it should have been, then an inactivation request should be submitted

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 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.

In certain infrequent situations, inactivation is not sufficient to correct assessment errors since inactivation alone does not remove the assessment record from the OASIS state system.� Two situations requiring deletion of an erroneous assessment, rather than inactivation..� States will continue to need to submit deletion requests on behalf of HHAs as per current policy. The following situations require deletion.

A. If an assessment exists on the state’s database that should never have been stored there, according to current policy it must be deleted.� For example, if an assessment was erroneously submitted in an un-masked format (i.e., it was marked at M0150 as 1, 2, 3 or 4) and later it was discovered that the patient was not a Medicare or Medicaid patient because one of these pay sources was incorrectly selected on M0150 (i.e., it should not have been marked 1, 2, 3, or 4), the assessment must be deleted from the OASIS state system.

B. If test files and/or batches have been erroneously submitted as production files and/or batches in error, they must be deleted.

If you need to request a deletion, please contact your State OASIS automation coordinator for future instructions.

1. Assessment was Submitted to the State and was Rejected. The HHA can unlock the assessment (the lock date changes to reflect the date the correction was made), make the necessary changes, re-lock the assessment, 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 state 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 state 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 state 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.� To correct an assessment with key field errors, first inactivate the assessment, then create a new assessment for re-submission, as applicable.� See option 4.

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 correction number field is incremented in this case.� Both the original assessment and the corrected assessment will be stored in the state database.� When this type of correction occurs, the rule requiring the lock date to be within 7 days of the assessment’s completion date (M0900) is waived for the corrected record.

4. Assessment was Submitted to the State and was Accepted.�Inactivation of the assessment is necessary.�� This 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 number 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 “Locked (Export Ready).”� The ‘X’ indicates that this assessment has been prepared for inactivation.

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 popup box will appear asking if the HHA wants to make any corrections to this 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.� The lock date changes to reflect the date the correction was made.

The flow chart here (PDF 13K) depicts the most common situations necessitating correction.

For step-by-step instructions on making key field corrections, go to the HAVEN Data Entry Software page.

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 for five years, or longer, in accordance with the clinical record requirements at 42 CFR 484.48.� 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 requirements at 42 CFR 484.48, Clinical records.�

Currently there are no requirements regarding the timeliness of correcting and inactivating assessment records, either in terms of when they must be completed (locked) or submitted.� However, we urge HHAs 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.� This affects the data used to calculate the HHA’s Outcome-Based Quality Monitoring reports.

When corrections are made to an assessment already submitted to the 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 (HCFA 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.

Collection and submission of information on SOC (Reason for Assessment (RFA) 1), Resumption of Care (ROC) (RFA 3), FU (RFA 4), Other FU (RFA 5), Transfer (RFA 6, 7) and Discharge (RFA 8, 9) assessments are required by the comprehensive assessment requirements at 42 CFR 484.55.� 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 FU assessment, as appropriate. This is in keeping with the regulation at 42 CFR 484.20 (b), accuracy of encoded OASIS data that states, “The encoded OASIS data must accurately reflect the patient's status at the time of assessment.”� It is necessary to have one consistent document for the patient's assessment, care planning, and payment purposes.

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 in correction type #4 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 in correction type #3 above.� The ‘Correction_num’ is implemented in non-key field changes.� For more specific information concerning the process of correction and inactivation, please refer to the Version 1.40 OASIS data specification notes found on this page.

Search Frequenty Asked Questions

OASIS Data Submission Specifications