Preparing for Updated Race and Ethnicity Data Collection
The Office of Management and Budget (OMB) has revised federal race and ethnicity data standards by incorporating Hispanic and Middle Eastern or North African as options in the Ethnicity question. Institutions should plan updates to their data collection, integrations, and downstream systems before the September 28, 2029 compliance deadline.
Overview
OMB’s revised race and ethnicity data standards change how Hispanic origin and Middle Eastern or North African identity are collected:
- Hispanic is no longer collected through a separate Yes/No question.
- Hispanic is now a value within the broader Ethnicity question.
- Middle Eastern or North African is also a new Ethnicity value.
These changes affect the values your institution collects, stores, imports, and exports for applicant and constituent records.
Timeline
OMB has extended the implementation timeline for the updated Statistical Policy Directive No. 15 standards. Federal information collections are required to align with the revised race and ethnicity data standards no later than September 28, 2029.
The updated standards are already in effect, but organizations may be at different stages of adopting them. As a result, application providers, Common Application Services (CASs), institutions, and downstream systems may not all transition simultaneously.
Required Updates
When your institution is ready to adopt the updated format, review and update the following areas.
Update Ethnicity Picklist Values
Add the following values to the Ethnicity field you’re mapping values to and pulling your data from, such as TargetX_SRMb__Ethnicity__c or TargetX_SRMb__IPEDS_Ethnicities__c:
- Hispanic
- Middle Eastern or North African
Review any existing race and ethnicity fields, page layouts, record types, validation rules, flows, reports, and integrations that rely on the current values.
Update Data-Collection Sources
Update every source that collects race and ethnicity information to use the revised Ethnicity structure. This may include:
- Online applications, including TargetX, CAS applications, Common App, state applications, and other application sources.
- Inquiry or lead-capture forms.
- Data imports, such as name buys and other third-party prospect files.
- Custom forms, portals, and integrations that create or update Contact records.
Ensure that the selected values map consistently into the appropriate Ethnicity field in your CRM.
Verify Downstream Exports
Confirm that every downstream system that receives race and ethnicity data can accept the new values before enabling the updated configuration. This may include:
- Student information systems (SIS)
- Data warehouses and reporting platforms
- Enrollment-management tools
- Third-party integrations
- Custom export processes and scheduled data jobs
Coordinate with the owners of each destination system to determine whether they require updated field mappings, new accepted values, or data-transformation logic.
CAS Transition Considerations
Some Common Application Services are already moving to the revised format, including:
- NursingCAS
- PTCAS
- CASPA
- PharmCAS
- SOPHAS
- SOPHAS Express
If a CAS begins sending Hispanic as an Ethnicity value while your institution still uses the previous structure, additional data transformation may be necessary.
For example, if your current process uses a separate Hispanic Yes/No field, configure a transformation so that a CAS Ethnicity value of Hispanic also sets the legacy Hispanic field to Yes. This helps preserve existing reporting, integrations, and business processes until your institution is ready to fully transition to the updated model.
Before making changes, document the current mappings, identify all affected fields and integrations, test with representative records, and coordinate the change across the application, CRM, reporting, and SIS teams.
Plan for Data Overlap
During the transition to the updated race and ethnicity data model, your institution may receive active records in both the previous and revised formats. For example, some applications, forms, imports, or third-party sources may continue sending a separate Hispanic Yes/No value while other sources begin sending Hispanic and Middle Eastern or North African as Ethnicity values.
Before implementing the new model, establish a business process to identify, map, and maintain records received in the previous format. Determine whether legacy values should be transformed automatically into the new Ethnicity values, retained in legacy fields for reporting purposes, or reviewed manually. Document how the process will apply to new records, updates to existing records, duplicate-management processes, exports, and downstream integrations.
Your approach may be like the CAS transition process. For example, a record received from a legacy source with Hispanic set to Yes may need to populate the updated Ethnicity field with Hispanic. Conversely, if a source sends Hispanic as the Ethnicity value while your institution still relies on the legacy Hispanic field for a temporary period, you may need automation to also set the legacy Hispanic value to Yes.
Review this process regularly as additional sources transition to the new structure. Once all data-collection sources, integrations, and downstream systems support the revised format, determine when to retire temporary mappings, legacy fields, and transitional reporting logic.