API Common Import Rejections

This topic integrates third-party EVV data into HHAeXchange for billing and compliance. It outlines the most common visit import rejections, why they happen, how to resolve them, and how to prevent them from recurring. Key questions to ask your software vendor are also included for optimizing your configuration and reducing long term errors.

Failure Reason Description Action to Take Vendor Talking Points
Another Visit is Using the Same Time in Full or in Part This rejection reason happens when the visit times overlap with another visit.

To fix the rejection, update visit times to avoid overlaps greater than 1 minute.

 

To prevent this rejection, use system alerts to flag overlaps before export.

Can we enable pre-export conflict detection for overlapping visits?

Can Occur if There is an Interruption in Service This error typically occurs due to a temporary connection interruption occurrence during transmission. As a result, the visit fails to import into HHAeXchange.

To fix the rejection:

  1. Review your failed visit logs or error reports to identify affected records.

  2. Resend any visits that failed due to the interruption.

While this type of error cannot be prevented, agencies should incorporate routine monitoring of failed visits into their standard workflow to ensure no data is missed.

 Can failed transmissions due to connection interruptions be automatically flagged and queued for retry?
Caregiver is not Found Based on Qualifier Value This rejection reason happens when the caregiver profile wasn’t processed before the visit file.

  1. To fix the rejection:
    Correct and resend the caregiver file.

  2. Confirm the caregiver exists in the portal.

To prevent this rejection, ensure Caregivers are loaded and active before visits are submitted.

Can you implement a check to prevent visit file exports if the caregiver profile has not yet been processed?
Edit Visit Action Code is Required This rejection reason happens when a visit update or correction was submitted without an Action Code, which is required.

To fix the rejection, refer to your state's API specifications and include the appropriate Edit Visit Action Code when resubmitting the visit.

To prevent this rejection, configure your EVV system to require this field any time a visit edit is made.

Can we enforce mandatory action codes for all visit edit transactions and prompt users to select one before submitting corrections?

Edit Visit Reason Code is Required This rejection reason happens when a visit update or correction was submitted without an Edit Reason Code, which is required.

To fix the rejection, refer to your state's API specifications and include the appropriate edit reason code when resubmitting the visit.

 

To prevent this rejection, configure your EVV system to require this field any time a visit edit is made.

Can we enforce mandatory action codes for all visit edit transactions and prompt users to select one before submitting corrections?

EVVMSID Does Not Belong to This Payer HHAeXchange generates a unique identifier called the EVVMSID. This rejection reason happens when the EVVMSID used in your visit file is already tied to a different patient profile in HHAeXchange. This often occurs when a visit was originally submitted under one payer, and an attempt to resend it to a different payer is sent without first clearing the original record.

To fix the rejection:

  1. Match the EVVMSID to the payer used during the original visit import.

  2. If the payer must be changed, first use the delete method to delete the visit associated with the incorrect payer, then resend the visit with the correct payer information.

To prevent this rejection, before resending visits with a changed payer, always check if the visit is already linked to another patient or payer. Coordinate internally to verify claim status before attempting to resend. Use your external visit ID consistently as the EVVMSID to avoid mismatches and simplify reconciliation.

Can we build a standard workflow for payer changes that includes deleting and resending visits?
EVVMSID is Required When Sending an Update to This Visit. Please Resend the Transaction with the EVVMSID HHAeXchange generates a unique identifier called the EVVMSID. When a new visit is initially sent, this ID must be included in any subsequent updates to that visit. If an update is submitted without the correct EVVMSID, or with a missing or invalid one, the system not match the update to the original visit, resulting in this error.

To fix the rejection:

  1. Locate and resend the update using the original EVVMSID from the initial import.

  2. Resend the update using the correct EVVMSID from the initial import.

To prevent this rejection, always use your external visit ID as the EVVMSID for all new visits to ensure consistency and reduce mapping errors later.

 Can we configure the integration to send the external visit ID as the EVVMSID?
Invalid Duties (Performed Task/Refused Task) Field Value This rejection reason happens when task codes provided are not listed in the API specifications.

To fix the rejection:

  1. Match all duty codes to your state's list.

  2. Correct mappings as needed.

To prevent this rejection, use system validations to restrict invalid task exports.

Can duty/task codes be validated at the point of entry or prior to export?
Invalid GPS Coordinates - Invalid Call Latitude/Longitude Value This rejection reason happens when the latitude or longitude values are 0 or invalid. This typically means the device failed to capture GPS data at clock-in or clock-out.

To fix the rejection:

  1. Ensure mobile devices have location services enabled and functioning.

  2. If GPS is not captured, send a visit edit with the appropriate visit edit codes and ensure the latitude or longitude are removed.

To prevent this rejection: Confirm that GPS is enabled and functional before each shift. Provide staff with device usage guidelines to reduce the risk of GPS capture failures.

 Can we configure the system to flag or hold visits with GPS coordinates of 0 before exporting them, so they can be reviewed and verified manually?
Invalid Payer ID Value This rejection reason happens when the payer ID doesn't match accepted values in the API specifications.

To fix the rejection:

  1. Review state-specific Payer ID values in the API specifications.

  2. Adjust mappings in your system.

To prevent this rejection, confirm payer ID mappings are kept up to date and align with the API specifications for your designated state.

Can you implement a validation rule to only allow exports with valid Payer IDs as defined in the current specifications?
Location Type field is Required on EVV Clock in and Clock Out, Please Add Location Type and Resend Visit This rejection reason happens when the location type (e.g., Home, Community) is missing.

To fix the rejection

  1. Add the missing field.

  2. Resend any rejected visits.

To prevent this rejection, work with your vendor to automate population of this field post-verification.

Can we configure the system to require the Location Type upon visit verification?
Member is not Found Based on Qualifier Value This rejection reason happens when the Medicaid ID submitted in the visit file doesn’t match any member profile in HHAeXchange for the specified payer ID and office. This can occur if the member isn’t yet loaded into the portal, the wrong ID was entered, or there is a mismatch in payer or office configuration.

To fix the rejection:

  1. Search for the member by name in the HHAeXchange portal to confirm if the member exists.

  2. Double-check that the correct Medicaid ID was submitted.

  3. Confirm the Payer ID and Office NPI/UPMI match the configuration in the HHAeXchange portal. Refer to the API specification for your state to verify the correct payer ID.

  4. If the member is found, verify which office they are assigned to and ensure your visit file uses the correct office NPI or UPMI.

  5. If the member is not loaded, contact your payer contract representative to request that the authorization be added so the member can be created.

To prevent this rejection:

  1. Ensure your EVV system is configured to validate member eligibility before exporting visits.

  2. Confirm that Medicaid IDs are accurate and that payer and office mappings are up to date.

 Ask your EVV vendor to validate member eligibility and ID before exporting.
Member (Qualifier and Identifier) is Required This rejection reason happens when required fields (e.g., Medicaid ID) are blank.

To fix the rejection:

  1. Add missing identifiers.

  2. Resend all rejected visits.

To prevent this rejection, make these fields mandatory in your EVV system.

Can we configure mandatory field rules to block exports that are missing required identifiers?
Missing Latitude or Longitude with GPS Confirmed This rejection reason happens when clock in/out is confirmed by GPS, but latitude or longitude is missing.

To fix the rejection, if GPS is not captured, send a visit edit with the appropriate Visit Edit Codes and ensure the Latitude or Longitude are removed.

 

To prevent this rejection, confirm that GPS is enabled and functional before each shift. Provide staff with device usage guidelines to reduce the risk of GPS capture failures.

Can we configure the system to flag or hold visits with missing GPS coordinates before export, so they can be manually reviewed and verified?
Multiple Member Records Found Based on Qualifier Value. Please Provide Unique Identifier. This rejection reason happens when multiple patient profiles match the same Medicaid ID.

To fix the rejection:

  1. Update your integration logic to include the HHAeXchange Admission ID as a unique identifier in visit exports, as outlined in the API specifications. This ensures the visit is assigned to the correct patient profile.

  2. Resend any rejected visits.

This issue can’t be fully prevented by the agency or vendor, but including the Admission ID in every visit file helps reduce the error when duplicate profiles exist.

Can we update our integration to always send the admission ID in User Field 4 to make sure visits are matched to the right patient?
Multiple Office Records Found Based on Qualifier Value. Please Provide Unique Identifier This rejection reason happens when the same NPI or UPMI is assigned to multiple offices.

To fix the rejection:

  1. Go to Admin > Office Setup in the HHAeXchange portal and review your office configurations.

  2. Identify and remove duplicate NPI or UPMI entries from office records to ensure each office has a unique identifier.

  3. If members are assigned to the incorrect office:

    1. Navigate to Member > Search, and use the filters to find members associated with the wrong office.

    2. Select the member, go to the General tab, and under Office Move, choose the correct destination office.

  4. Once cleanup is complete, resubmit the visit.

To prevent this rejection, always assign unique identifiers to each office during setup. If you must share an NPI across offices, coordinate closely with HHAeXchange Support Team to ensure it's configured correctly.

There is limited action your EVV vendor can take here since office setup is managed within the HHAeXchange portal. However, it is recommended to establish a regular review process with your internal admin team to identify and resolve duplicate office mappings proactively.
Office is Not Found Based on Qualifier Value This rejection reason happens when the NPI or UPMI doesn’t match an office in your portal.

To fix the rejection:

  1. Go to Admin > Office Setup.

  2. Verify the NPI sent is configured in your HHAeXchange portal.

  3. If using a UPMI, make sure it is listed in the Secondary Identifier field.

  4. If the office does not exist or is missing the correct NPI, submit a ticket to have it created and linked to the appropriate payer contract.

To prevent this rejection, align the NPI or UPMI values in your EVV system exactly with those configured in your portal. If the portal has incorrect or outdated values, update them to reflect what your system is sending.

Can you run a report showing which NPIs are failing so we can ensure our portal is configured with only the accepted office identifiers?
Procedure Code Not Found This rejection reason happens when the procedure code sent doesn't match state-approved codes.

To fix the rejection:

  1. Check the list of valid procedure codes in the API specifications.

  2. Update your internal mappings to ensure you're only using approved codes.

To prevent this rejection, validate all procedure codes at the point of entry or prior to export to confirm they align with the API specifications. If your code includes formatting (e.g., colons), ensure it exactly matches the required format, do not include a colon unless the state-approved code does.

Can we add a validation step to flag unsupported or incorrectly formatted procedure codes before visit export?
Provider is not Found Based on Provider Tax ID

This error occurs when the Provider Tax Identification Number (TIN) sent in the visit file does not match what is configured in the HHAeXchange. This typically happens for one of the following reasons:

  • The TIN in the visit file does not match the TIN listed in the HHAX agency portal.

  • Agencies can verify their TIN under Admin > Office Setup. The Client ID used in the file is incorrect or not mapped to the expected provider record. Contact your vendor to verify the Client ID being used.

To fix the rejection:

  1. Log into the HHAeXchange portal and navigate to Admin > Office Setup.

  2. Review the Tax ID listed for the provider and confirm it matches the value sent in the visit file.

  3. If the TIN is correct but the error persists, confirm with your EVV vendor that the correct Client ID is being used in the export file.

  4. Update and resubmit the visit once the TIN and Client ID are confirmed to match system expectations.

To prevent this rejection, agencies should verify that their TIN in the HHAeXchange portal matches what is configured in their EVV system.

 Can we coordinate with your vendor during implementation or payer onboarding to confirm the correct Client ID and TIN are mapped?
Schedule Duration is 0 This error occurs when the schedule shows the same timestamp for start and end times, resulting in a duration of 0 minutes.

To fix the rejection, review the visit and update the clock-in and clock-out times to reflect the actual time the caregiver is scheduled with the member.

 

To prevent this rejection, ensure your EVV system only exports visits after both timestamps have been recorded and verified. Avoid sending placeholder or incomplete time data.

Can we enforce a minimum duration threshold and block visits with 0-minute durations from being exported? Can we stop visits from exporting until they have been manually verified?
There is No Active Contract for This Visit This error occurs when no valid authorization is active during the visit date. This usually means the member does not have an approved contract or their eligibility has lapsed.

To fix the rejection:

  1. Review the member’s authorization record in the portal.

  2. Contact your payer or contract manager to request that the necessary authorization be added or renewed.

To prevent this rejection, agencies should maintain an internal process to track expiring authorizations and review schedules against known eligibility periods.

Can we develop tools or reports that help agencies monitor visit schedules against their internal authorization data to better align and reduce rejections?
Visit date is Not in Range of Eligibility Start and End Date This rejection reason happens when the visit date falls outside the member’s Start of Care (SOC) or Discharge Date. This can occur when the SOC date in our system is outdated or incorrect, or when the member is no longer eligible for services on the date of service (DOS).

To fix the rejection:

  1. Search for the patient in the HHAeXchange portal.

  2. Navigate to MCOs > Insurance to view the patient’s SOC and Discharge Date.

  3. If the visit falls before the SOC date:

    1. Go to MCO Placements > Actions (three dots menu) and select Edit Service Start Date.

    2. Update the SOC to match the earliest visit start date.

    If the visit falls after the discharge date:

    1. Confirm the member’s eligibility with the payer or your contract manager.

    2. If eligible, request an updated authorization to reflect continued service.

To prevent this rejection, regularly audit member records to ensure SOC and discharge dates are aligned with current eligibility. Maintain communication with your payer to confirm member status, especially for patients with lapses or recent changes in eligibility.

Can we explore workflow enhancements to notify when a patient is discharged or approaching their discharge date, so action can be taken before submitting visits that fall outside the valid service period?
Visit Duration is 0 This rejection reason happens when the visit shows the same timestamp for both clock-in and clock-out, resulting in a duration of 0 minutes. This typically occurs when a Caregiver clocks in and out at the same time, or when one of the timestamps was not properly captured.

To fix the rejection, review the visit and update the clock-in and clock-out times to reflect the actual time the Caregiver was with the member.

 

To prevent this rejection, ensure your EVV system only exports visits after both timestamps have been recorded and verified. Avoid sending placeholder or incomplete time data.

Can we enforce a minimum duration threshold and block visits with 0-minute durations from being exported? Can we stop visits from exporting until they have been manually verified?
Visit Start Time Cannot be Greater than Current Date The visit start time is in the future, which is not permitted for verified visits. This often results from scheduling or verifying a visit ahead of the actual date of service.

To fix the rejection: review and correct the visit’s start time to reflect today or an earlier date.

To prevent this rejection, ensure visits are not verified until after the actual clock-in occurs.

Can we prevent verified visits from being submitted if the start time is in the future, and flag them for manual review before processing?