Oregon EVV Specifications
Oregon EVV Vendor Documentation
This page is the single source for Oregon Alternate EVV Vendor integration requirements. It combines Oregon-specific program rules, onboarding, API setup, shared API reference sections, required data elements, Phase 3 validation focus, reason codes, payers, programs, services, and testing expectations.
How to use this page
Use Program Overview and Onboarding for Oregon-specific business and implementation requirements.
Use API Setup to build the sandbox endpoints and understand what is shared across all states.
Use Shared API Reference for embedded API documentation maintained in one place.
Use Data Elements & Phase Validations as the vendor checklist for required fields, especially Phase 3 aggregation requirements.
Use Oregon State-Specific Tables for identifiers, reason codes, payer/program values, and service codes.
Program Overview
Introduction
In compliance with Centers for Medicare and Medicaid Services (CMS) Electronic Visit Verification (EVV) regulations, Acumen collaborates with the Oregon Department of Human Services (ODHS) and the Oregon Health Authority (OHA) to provide State of Oregon EVV Data Aggregation. The Direct Care Innovations (DCI) Data Aggregator receives, consolidates, validates, and processes EVV data from multiple providers, vendors, and agencies, then submits the information to the appropriate oversight entity.
This guide supports project management and technical teams at designated Alternate EVV Vendors implementing the Oregon EVV interface. Updates are distributed as system functionality, onboarding expectations, or State requirements change.
Key Contacts and Support
Contact Type | Details |
|---|---|
EVV Aggregation Support Team | |
Testing specifications | Oregon EVV Third Party Vendor Testing Specifications |
Vendor onboarding |
Transmission Method
DCI provides an Application Programming Interface (API) for Alternate EVV Vendors. Vendors are contacted by the EVV Aggregation Support Team to begin onboarding, complete validation, receive test credentials, complete testing, and move into production once approved.
Transmission Frequency and Limits
DCI utilizes a single transaction API. For optimal system performance, DCI recommends that visit data is sent in near real-time as it is added, changed, or deleted in the Alternate EVV Vendor data collection system. Data that is unchanged should not be resent to DCI.
Oregon Identifier Rules
Object | Identifier | Oregon Requirement | Validation Impact |
|---|---|---|---|
Client |
| Use the client’s Medicaid Number. | Required for Phase 1, Phase 2, and Phase 3. Must be unique and must match the client referenced on visits. |
Employee |
| Use the employee’s Social Security Number (SSN). | Required for Phase 1, Phase 2, and Phase 3. Must be unique and must match the employee referenced on visits. |
Visit |
| Use a unique EVV visit identifier from the vendor system. | Required for Phase 1, Phase 2, and Phase 3. New, Update, and Cancel visit rules depend on this value. |
Onboarding Process
Oregon Department of Human Services sends an introduction email to the EVV Vendor.
Acumen sends the Oregon EVV Vendor Specifications and a link to the online Vendor Onboarding Form.
EVV Vendor completes the Vendor Onboarding Form online.
Acumen provides the implementation wave start date and estimated duration.
Acumen generates test environment login credentials and distributes Oregon PTC Phase 3 Alternate EVV Vendor Test Specifications.
EVV Vendors and provider agencies complete testing requirements and request production credentials.
Acumen and the State review and accept the Test Completion Report.
Acumen distributes production credentials and live data submission begins.
📌 Quick Links
Oregon PTC Phase 3 Alternate EVV Vendor Test Specification
Oregon EVV Third Party Vendor Testing Specifications
EVV Aggregation Support: EVVaggregationsupport@acumen2.net
API Setup
API setup is shared across state implementations. Oregon-specific values, such as payer, program, service, identifier, and reason code requirements, are documented later on this page.
Sandbox Environment and Endpoint Examples
Item | Value | Notes |
|---|---|---|
Sandbox base URL | Use this base environment for vendor testing. | |
Base API path |
| Append the object route for client, employee, or visit. |
Client endpoint |
| Create or update client records. |
Employee endpoint |
| Create or update employee records. |
Visit endpoint |
| Create, update, or cancel visit records. |
Update endpoint pattern |
| Use the applicable object and identifier pattern from the API reference. |