Phase Where Validation Occurs What It Checks How Failure Is Returned Vendor Resolution Phase 1 Aggregation Manager API Payload can be received and has the basic required information to create the Client, Employee, or Visit record. API error response, such as 400, 401, 403, 409, or 500. Correct the payload, authentication, schema, format, duplicate identifier, or request conflict and resend. Phase 2 Aggregation Manager Record is complete and valid enough to submit to the Data Aggregator. Aggregation Manager status such as Incomplete or Unable to Submit. Correct incomplete Client, Employee, or Visit details in the vendor system and retransmit as needed. Phase 3 Data Aggregator / State rules Visit satisfies State-defined aggregation requirements, including valid payer, program, service, modifier, identifier, visit type, and reason code rules. Aggregation Result of Success or Failure with Result Description. Correct the State-specific issue in the vendor system and retransmit the corrected data.

Element Phase 1 Required Phase 2 Required Phase 3 Required Most Restrictive / Phase 3 Validation Focus clientIdentifier Y Y Y Oregon requires the client’s Medicaid Number. Client Identifier cannot already be present in the Aggregator. medicaidNumber N N N Not required as a separate element when Oregon uses Medicaid Number as the clientIdentifier. ssn N N N Not required for the Client object unless State-specific requirements change. firstName Y Y Y Required client demographic field for successful aggregation. middleName N N N Optional. lastName Y Y Y Required client demographic field for successful aggregation. timeZone N Y Y Required before submission to the Aggregator and required for Phase 3. addressLine1 N Y Y Required client address element for Phase 2 and Phase 3. addressLine2 N N N Optional. city N Y Y Required client address element for Phase 2 and Phase 3. state N Y Y Required client address element for Phase 2 and Phase 3. postalCode N Y Y Required client address element for Phase 2 and Phase 3. country N Y Y Required client address element for Phase 2 and Phase 3. addressType N N N Optional. phone N N N Optional. startDate N N N/A Not applicable for Phase 3. endDate N N N/A Not applicable for Phase 3.

Element Phase 1 Required Phase 2 Required Phase 3 Required Most Restrictive / Phase 3 Validation Focus employeeIdentifier Y Y Y Oregon requires the employee’s SSN. Employee Identifier cannot already be present in the Aggregator. firstName Y Y Y Required employee demographic field for successful aggregation. middleName N N N Optional. lastName Y Y Y Required employee demographic field for successful aggregation. email N Y Y Required before submission to the Aggregator and required for Phase 3. employeeNumber N N N/A Not applicable for Phase 3. ssn N N N Oregon uses SSN as the employeeIdentifier; do not rely on this as a separate required Phase 3 element unless directed. dateOfHire N N N/A Not applicable for Phase 3. endDate N N N/A Not applicable for Phase 3.

Element Phase 1 Required Phase 2 Required Phase 3 Required Most Restrictive / Phase 3 Validation Focus visitIdentifier Y Y Y New: no other successfully aggregated New visit can exist with the same identifier. Update: a New visit with this identifier must already be successfully aggregated. Cancel: a New visit with this identifier must exist. employeeIdentifier N Y Y Visit will not submit unless the Employee has a Valid status. Must match a valid employee using Oregon SSN identifier rule. employeeName N N N Optional. liveInCaregiver N N N Optional unless State-specific rules change. groupCode N N N Optional. clientIdentifier N Y Y Visit will not submit unless the Client has a Valid status. Must match a valid client using Oregon Medicaid Number identifier rule. clientName N N N Optional. payerIdentifier Y Y Y Agency must have an active Contract with this Payer. For Oregon, use valid payer ID from the payer/program table. payerName N N N Optional. programIdentifier Y Y Y Must be a valid Oregon Program Identifier. Agency must have an active Contract with this Program, and Program must be linked to the Payer on the visit. programName N N N Optional. serviceCode Y Y Y Must be a valid Oregon Service Code and must be associated with an active Contract for the Agency, Payer, and Program on the visit. modifier1 N N N If supplied, must be a valid Modifier per State specifications and linked to the Service Code on the visit. modifier2 N N N If supplied, must be a valid Modifier per State specifications and linked to the Service Code on the visit. modifier3 N N N If supplied, must be a valid Modifier per State specifications and linked to the Service Code on the visit. modifier4 N N N If supplied, must be a valid Modifier per State specifications and linked to the Service Code on the visit. clockInTimeZone N Y Y Required for Phase 2 and Phase 3. clockOutTimeZone N Y Y Required for Phase 2 and Phase 3. clockInDateTime N Y Y Required visit time element for Phase 2 and Phase 3. clockOutDateTime N Y Y Required visit time element for Phase 2 and Phase 3. clockInAddress N N N Optional unless required by State-specific verification method rules. clockInCity N N N Optional unless required by State-specific verification method rules. clockInState N N N Optional unless required by State-specific verification method rules. clockInLatitude N N N Optional unless required by State-specific verification method rules. clockInLongitude N N N Optional unless required by State-specific verification method rules. clockInLocationName N N N Optional. clockOutAddress N N N Optional unless required by State-specific verification method rules. clockOutCity N N N Optional unless required by State-specific verification method rules. clockOutState N N N Optional unless required by State-specific verification method rules. clockOutLatitude N N N Optional unless required by State-specific verification method rules. clockOutLongitude N N N Optional unless required by State-specific verification method rules. clockOutLocationName N N N Optional. callTypeIn N Y Y Required call / verification method element for Phase 2 and Phase 3. callTypeOut N Y Y Required call / verification method element for Phase 2 and Phase 3. otherCallType N N N Optional unless required to explain the call type used. mobileLogin N N N Optional. originatingPhoneNumber N N N Optional unless required for telephony verification. telephonyPin N N N Optional unless required for telephony verification. reasonCode1 - reasonCode5 N N N / Conditional Oregon requires reason codes for manual or edited entries. Missing required reason codes result in aggregation failure. reasonCode1Note - reasonCode5Note N N N / Conditional Required when the selected Oregon reason code requires a note, such as Provider-Other or Provider Agency-Other. diagnosisCode N N N Optional unless State-specific program requirements change. visitType Y Y Y New visit must be unique or previously failed aggregation. Update must reference an original successfully aggregated visit. Cancel must reference a prior New or Update with the same visit identifier.

Oregon Phase 3 validation determines whether a visit reaches Aggregation Success or Aggregation Failure after submission to the Data Aggregator. Vendors should focus on the rules below because these are the most restrictive requirements and may not fail at the initial API response stage. Data Type Rule Result if Missing or Invalid Vendor Resolution Visit Manual or edited entries must include required Oregon reason code values. Aggregation Failure. Add the appropriate reason code and note when required, then retransmit corrected visit data. Visit Payer, Program, and Service Code must match Oregon-approved values and active Agency contracts. Aggregation Failure or visit not submitted successfully. Correct payer, program, service, and contract alignment. Visit Modifiers, if submitted, must be valid for the State specification and linked to the service code. Aggregation Failure. Correct modifier order/value or remove invalid modifiers if not applicable. Visit Client and Employee referenced on the visit must exist and be Valid. Visit remains incomplete or fails to aggregate successfully. Correct and submit valid Client and Employee records before resubmitting the visit. Visit Visit Type rules must be followed for New, Update, and Cancel. Aggregation Failure or conflict response. Verify visit history and submit the correct visit type using the same visit identifier rules. 💡 Phase 1 API success does not guarantee Phase 3 Aggregation Success. Vendors must continue monitoring the visit result and result description after submission.

Reason Code Description Note Required 10 Provider-Clocked In/Clocked Out Mistakenly N 20 Provider-Forgot to Clock In/Clock Out N 30 Provider-Manual Entry Due to FOB Error N 40 Provider-Manual Entry Services in Community N 50 Provider-No Internet/System Issues N 60 Provider-Telephony Unavailable N 70 Provider-Other Y

The reason codes below are only for use by In-Home Care Agencies (IHCAs) on behalf of an employee/provider. Reason Code Description Note Required 80 Provider Agency- No Plan of Care N 90 Provider Agency- No Service Authorization N 100 Provider Agency- Other Y

Scenario Group Examples Expected Evidence Phase 1 general validation Happy path Client, Employee, and Visit; authentication failure; server error; invalid schema; missing required fields; invalid formats. API response code and returned object GUID or error message. Object create/update validation Client, Employee, and Visit create/update scenarios, including duplicates and invalid updates. Record identifier, response code, and corrected retransmission where applicable. Phase 2 scenarios Incomplete object creation, valid object creation, update flows, and readiness for aggregation. Aggregation Manager status showing Valid, Incomplete, Ready for Aggregation, Unable to Submit, or Submitted as applicable. Phase 3 scenarios End-to-end visit aggregation success and failure paths. Aggregation Result and Result Description confirming Success or explaining Failure.