Home›Blog›Article
All Verticals

OASIS-E2 Is Live: What Changed in April 2026 and What Your Software Must Handle

Learn the key OASIS-E2 changes effective April 2026, software updates, EMR compliance requirements, and how to prevent iQIES errors and claim rejections. (157 characters)

S
Staffinc Editorial Team
Healthcare Staffing Technology
Aug 5, 2026 · 9 min read

OASIS-E2 became effective on April 1, 2026, and for many home health agencies, the change process appeared much more subdued compared to the previous year's OASIS-E1 transition. This update does not include a new all-payer mandate, item renumbering throughout the assessment, or an entire six months of hype at conferences.

This description fits the update quite well. However, that is precisely the reason why OASIS-E2 represents a significant risk regarding software updates and compliance. Minor changes always get overlooked. An item name change that your EMR did not update. A timeframe that now requires additional information. A discharge item that should no longer be there, but is. These changes will not come with any flashy headlines. Instead, you will discover them three weeks later when a claim gets rejected, your iQIES submission fails, or your Star Ratings don't add up anymore.

This blog outlines precisely what is different about OASIS-E2, the risks for claim rejection that these differences pose to you if your software isn't updated yet, and what you need to ask your software vendor now.

The Rule: Which Assessments Need OASIS-E2

Before going into the specifics of how the items have been updated, the important point of when the change occurs is crucial. If the M0090 (Date Assessment Completed) in any OASIS assessment is on or after April 1, 2026, then it has to be done by using the OASIS-E2 item set. This applies to all assessment types, which include Start of Care, Resumption of Care, Recertification/Follow-Up, Transfer and Discharge. This is an abrupt change that has to be implemented without a grace period and parallel submission window.

If your software still has a hardcoded item set, an outdated XML schema, or a cached validation logic pointing to E1 specifications, this is the primary issue that needs to be addressed first.

What Actually Changed in OASIS-E2

1. M0069 (Gender) Is Gone: A0810 (Sex) Replaces It

This is perhaps the most structurally significant change in this release. The legacy item M0069, which stood for "Gender," has been replaced with the A0810 item "Sex." While the data element itself is fundamentally the same, the field ID and coding rules as well as response instructions have been updated. Importantly, the previous language directing clinicians to action "if the patient does not self-identify" has been stripped from the E2 version.

For software, this is no minor issue. Anything that uses M0069_PAT_GENDER by field ID will now need to be updated to A0810. If your claims processing system, EMR demo intake form, or other downstream analytics interface continues to reference the old field ID, you will experience either a validation error or even worse, an invisible discrepancy that could only surface during an audit.

2. A1250 (Transportation) Is Replaced by A1255

The access to transportation question has not only changed its name; it has been completely rebuilt. In the new A1255, rather than being framed in a "select all that apply" manner, the revised form poses a single-response query about whether lack of transportation in the last 12 months has interfered with the patient's ability to attend medical appointments, other appointments, get to work, and to acquire items needed for daily living activities. Thus, the language becomes more consistent with what other standardized Social Determinants of Health (SDOH) screening instruments ask.

Also noteworthy for developers: A1255 has been revised to be asked only at Start of Care and Resumption of Care and is no longer asked on Discharges. Therefore, if the prompt asking about access to transportation pops up during the discharge assessment in your EMR, it should be removed because this is one of those items that you are supposed to collect at a certain time point but not at another time point.

3. Sensory and Language Items Now Required at Resumption of Care

Three fields that were previously gathered only at the Start of Care timepoint – A1110 (Language), B0200 (Hearing) and B1000 (Vision), now need to be collected again at the Resumption of Care timepoint. The justification is continuity of care: patients can undergo significant changes in their senses or ability to communicate during hospitalization and it is essential to collect them immediately upon discharge, instead of waiting until the next full assessment.

This is a true workflow alteration and not just mapping of information from one field to another. If your ROC assessment template does not contain these three fields, then either your clinicians won’t gather them at all or will have to do so using a different way – both situations increasing the likelihood of an incomplete assessment to be returned.

4. J1900 (Falls) Guidance Tightened, Star Ratings Exposure

The J1900 field - "Number of Falls Since SOC/ROC" - retains its format, but the rationale behind it has been updated based on information provided in the October 2025 Quarterly OASIS Q&As and the errata issued for OASIS-E1.

The main point here is "intercepted falls" and what should be recorded in terms of fall injury level, especially when it comes to J1900B and J1900C.

Why does it really matter? J1900 contributes to the Falls with Major Injury quality measure, which, in turn, influences HHVBP scoring and star ratings. In case you have outdated decision support information related to J1900 in your system, clinicians might end up either over-recording or under-recording injury severity level, which will affect your agency's quality measures.

5. D0150 Now Accepts a Dash (-) Response

Small but practical solution: The items under D0150 related to mood assessment frequency allow a dash as an acceptable value for the “not applicable” answer, making it unnecessary to develop any particular workaround related to skip logic, which the agencies have been doing before. If your program did not allow anything but numbers in these fields, this rigid validation rule must be changed.

6. Additional Items Added to RFA 03 (Resumption of Care)

Apart from the above-mentioned sensory items, CMS included additional data elements in the ROC assessment type (RFA 03). For agencies where the ROC process is less intensive than the SOC process, as a common design pattern in the older builds of the software, it is important to ensure that the ROC template includes all the currently existing items.

7. O0350 (COVID-19 Vaccination Status) Retired

The instrument now excludes the O0350 vaccination for COVID-19 variable completely. Any rule or skip pattern or reporting field attached with O0350 needs to be disabled. An outdated variable left enabled in a form not only adds unnecessary bulk, but, depending on the submission rules you have set up, can become a problem on its own by producing a validation edit.

Where the Claim-Rejection Risk Actually Lives

Each of the changes individually isn’t difficult. However, the complexity lies in the distance between “CMS publishes the spec” and “your software stack is aligned with it.” Here are some of the ways where the disconnect may be hidden:

Field mappings. Changing an item ID from M0069 to A0810 and from A1250 to A1255 is more than just renaming. There are cases when any of the parts of the workflow (the EMR’s data model, the HL7/CCD export, the billing interface, the state or referral interface) use the old item ID and/or old response structure. This results in data integrity issues rather than errors.

Templates by time point. Since the A1110, B0200, B1000, and RFA 03 additions are tied to the time points when previously they weren’t, there is an issue for a build that uses one generic template for SOC, ROC, and recertification builds, since it will fail to capture the items required for ROC or show items irrelevant to the time point.

Validation rules and edits. In relation to CMS's OASIS-E2 Data Submission Specifications (v 3.02.0), the accompanying set of edits was implemented in iQIES. Should your pre-submission validation in your system still be checking against E1 edits, the agency will pass your local validation, but be subsequently rejected or asked to correct something by CMS at the gateway, which is much more costly.

Leakage of retired items. O0350 needs to be retired completely; simply hiding the field from the clinician's interface, but providing a default value upon export, would create an unwanted edit at CMS's end. An unexpected edit can be generated in an E2 submission as a result of such a field's presence there.

Discharge time point specific logic. A1255 exclusion from the discharge time point can serve as an example of how hard it is to notice the changes made, since it involves the subtraction of a particular item, as opposed to its addition. Testing teams have an easier task testing new required items than testing their absence in the right place.

A Practical Checklist for Agencies and Software Teams

If you haven't already confirmed the following with your home health software vendor, now is the time:

Time point templates updated: ROC assessments now properly scope to include A1110, B0200, B1000, and the new RFA 03 items without double-scoping them to appear at other time points where they do not apply.

A1255 scoped properly: present at SOC and ROC, not included at Discharge time points.

J1900 decision support, help text updated to reflect current instructions for documenting an intercepted fall and the appropriate level of injury documentation.

D0150 accepts dash: validation logic updated to recognize dash as valid value and not data error.

O0350 fully retired: not only hidden from clinician view, but also not present in forms, skip logic, and export values anywhere in the tool.

Validation engine updated to current edit specs: pre-submission validation engine matches iQIES enforcement of edits, thus avoiding problems at CMS gateway.

Training provided based on the actual system, not just documentation: clinicians need to know where these changes are in their daily-use tool, not just in a policy document.

The Bottom Line

This release of OASIS-E2 from CMS may seem small relative to other releases, and herein lies the very pitfall. There are no reasons why anyone would have to overhaul their system, meaning that it is easy to consider this release an update of the guidance manual and not of the software. However, there is a high risk that claim rejections and distortions in the calculation of quality measures will not result from obvious changes but from minor changes that have happened along the way: a field with a new name but no remapping, a time point that requires one extra item, a retired field that still provides its default value.

The vendors who will pass this update smoothly will not be the ones to study the guidance manual extensively; they will be the vendors who know how each and every change in OASIS-E2 relates to their product.

Ready to cut your credentialing overhead?

We build custom healthcare staffing platforms with compliance built in from day one. Fixed price. 6–10 weeks to live.

Related Articles

Ready to cut your credentialing overhead?

Book a free call we'll show you exactly what automated credentialing looks like inside a Staffinc platform.