The Rendered Services feed is used by EVV Vendors and Billing Agencies with in-house EVV solutions to transmit schedule and visit information from 3rd parties to Netsmart and from Netsmart to 3rd parties.

Getting Started

It is important to read the Implementation Guide below first, this gives you the information that you need to get started.

File Specifications

See below documentation for this integration.   

Important: See below variations by state.

	File	Modified

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.

No files shared here yet.

Drag and drop to upload or browse for files

Upload file

File description

Developer Notes

• See type code/enumeration listing, you will see references to this document in the data map.  

• See listing of payers supported by Netsmart for this feed.

• Netsmart Staff: See also /wiki/spaces/ATESD/pages/608075805.

File Specification Variations by State

The file specifications above have some variation by state, primarily around required fields:

File Naming

Use the following filename convention when submitting flat-file or EDI rendered services files to Netsmart via SFTP:

<SourceID>_<FileType>_<DateTime>_<ProviderEIN>_<ProviderNPI>.<fileExtension>

where:

• <SourceID> = The 4-digit identifier that Netsmart assigned to designate the Third-Party Provider.

• <FileType> = Literal "SRVC" (Rendered Services)

• <DateTime> = Date & time that the file was generated formatted as YYYYMMDDHHMMSS

• <ProviderEIN> = The provider 9-digit numeric Federal Tax ID.

• <ProviderNPI> = The provider 10-digit numeric National Provider ID.

Inbound File Examples: 

• ABCD_SRVC_20200401105422_123456789_1098765432.TXT

• ABCD_SRVC_20200401105422_123456789_1098765432.XML

• ABCD_837P_20200401105422_123456789_1098765432.EDI  or  ABCD_SRVC_20200401105422_123456789_1098765432.EDI

Notes:

• Netsmart uses the EIN-NPI combination to uniquely identify each provider branch/location.

• This is our preferred identification in file naming, but any unique identifier for the provider agency location will work so long as it is placed after the <DateTime> field and before the extension, offset by underscore "_" characters. 

• Netsmart will then echo your file name, including the <ProviderEIN>_<ProviderNPI> combination in the reject file.  You can then use this information to route the response to the correct provider.

Response File Examples:

• ABCD_SRVC_20200401105422_123456789_1098765432_ACCEPTED.TXT

• ABCD_SRVC_20200401105422_123456789_1098765432_REJECTED.TXT

• ABCD_SRVC_20200401105422_123456789_1098765432_ACCEPTED.XML

• ABCD_SRVC_20200401105422_123456789_1098765432_REJECTED.XML

Support for Multi-Provider Using a Single Netsmart Endpoint

Background

Netsmart serves an eVV data aggregator for third-party eVV vendors (eVV vendors other than Netsmart).  In this capacity, Netsmart receives inbound Rendered Services feeds from 3rd Party Vendors and relays them to payers or payer clearinghouses.   In this scenario, it is the responsibility of the 3rd party vendor to deliver inbound Rendered Services transactions to a single Netsmart SFTP directory or HTTPS endpoint, and to handle any reject files/responses returned by Netsmart, returning the reject details to the party who will make any corrections and resubmit the rejected transaction.   The purpose of this section is to describe the process for identifying the individual providers for routing purposes.

For SFTP

See naming convention here.

For HTTPS

Netsmart currently processes HTTPS requests asynchronously, so does not respond immediately to the request with a response.  Netsmart is moving towards synchronous processing.  Until synchronous processing is in place, Netsmart will support a webhook mechanism to return reject files via HTTPS.   

To successfully integrate your webhook we at Netsmart ask for:

1. An HTTPS/HTTP Endpoint capable of receiving POST requests

   1. Ex: http://<your_api_endpoint>

   2. The response from Netsmart will be XML format.

2. Basic Authentication Credentials(Optional)

   1. Basic Authentication credentials can be configured client side. When you provide these credentials to Netsmart we will configure on our end for additional security,

3. A unique header or Query parameter representing your unique agency. We will call this unique field ProviderIdentifier

   1. The ProviderIdentifier will be used to route the resulting Accepted/Rejected to the appropriate provider agency.

   2. The ProviderIdentifier can be something like providerEin-providerNPI which will allow us to route successfully to the correct provider.

Custom Parameters and or headers may be accommodated based on client demand or scope of work.

Webhook API Response

When submitting files to Netsmart via API clients can optionally configure a webhook to receive per batch responses. These responses will determine whether your record was ACCEPTED or REJECTED into the Netsmart system.

To successfully integrate your webhook we at Netsmart ask for:

1. An HTTPS/HTTP Endpoint capable of receiving POST requests

   1. Ex: http://<your_api_endpoint>

   2. The response from Netsmart will be XML format.

2. Basic Authentication Credentials(Optional)

   1. Basic Authentication credentials can be configured client side. When you provide these credentials to Netsmart we will configure on our end for additional security,

Custom Parameters and or headers may be accommodated based on client demand or scope of work.

Special Handling of UserField1

When third-party EVV vendors send visits to Netsmart in the Rendered Services feed, they include a field called “UserField1” that they use to group multiple visits into a single claim/invoice.  Netsmart transmits this value to the payer (in the 837P: 2300|CLM01-2) and the payer returns this same value directly to the billing provider (in the 835RA: 2100|CLP|CLP01-2), and to Netsmart in 277 file lay out.  The billing provider needs this value to auto-post the claim payment based on the 835 response. 

As an example, these service lines are expected by the 3^rd party to be grouped into a single claim.  Sometimes the 3^rd Party vendor groups 100+ lines with a single Userfield1 value.

• Service Line 1    Userfield1 123

• Service Line 2    Userfield1 123

• Service Line 3    Userfield1 123

Netsmart also needs this value to uniquely match a 277 response from a payer back to the claim record in the Netsmart database when updating claim status (paid, denied, partially paid) returned from a payer.

The problem arises because Netsmart runs payer-required claims matching rules on each of the service lines, and allows the provider to release the service lines individually, so a situation like this may occur:

• Service Line 1    Userfield1 123    Sent in Claim 1  3/1/2020

• Service Line 2    Userfield1 123    Sent in Claim 1  3/1/2020

• Service Line 3    Userfield1 123    Sent in Claim 2  3/2/2020

This results in service lines that were intended for a single claim to be released separately and submitted in two (or more) claims.  

When the Claim 1 277 is returned to Netsmart, we rely on Userfield1 to match the inbound 277 to the claim record in our database.   We find 3 matching records for the claim 1 277 and update all three records in our database.  When the Claim 2 277 is later returned, it will not update the matching records because the system will detect that they are already updated.  This means that some of the records may end up with the incorrect status values, including a claim-service showing as accepted when it should be rejected.

Solution:

Netsmart will add a unique value as a prefix to each Userfield1 value in our database before sending the value to the payer, so the records would look like this, with the counter incrementing if multiple claim files were sent in a single day (In the example, “100” is the Netsmart Value, “123” is your UserField1 value):

• Service Line 1    Userfield1 10;123     Sent in Claim 1  3/1/2020

• Service Line 2    Userfield1 10;123     Sent in Claim 1  3/1/2020

• Service Line 3    Userfield1 11;123     Sent in Claim 2  3/2/2020

This approach would allow for accurate matching in Netsmart even when the service lines with same Userfield1 from 3^rd party is released by the billing provider on different days for different claim files.    

IMPORTANT:  The CLM01 segment has a field limitation size of 20 characters.   Netsmart will require 3 of those characters (including the separator value), leaving 17 characters for the vendor to pass in userfield1.

Action Required: 

As a result of this change the 3^rd Party EVV vendors may need to alter their matching logic to read only the value after the ";" in order to strip out the data that Netsmart has added.   

Handling of Authorization ID's Included in the Feed:

The following use case explains how Netsmart EVV handles authorization ID's that are passed in the AuthorizationID field:

3rd Party Vendor may pass the AuthorizationID to Netsmart via the Rendered Services feed.  

1. The Auth ID that is passed in from the third-party will be displayed on the Claims Work List in the “Manual Override Auth No.” field. This is separate from the “System-Assigned Auth No.” field that is used if the Netsmart EVV system identifies the authorization ID via the claims-to-authorization matching algorithm.

1. Netsmart will attempt to match the visit from the Rendered Services inbound feed to a PA that Netsmart has received from the payer using the following matching logic:

   1. If PA Number received in RS feed: Match on AuthorizationID AND all normal matching values, including modifiers. 

   2. If PA Number not received in RS feed: Match on all normal matching values.

   3. If PA Number received in RS feed and Payer = NDDS and Source = THSR (special case for NE Therap): Match based on Auth ID + normal matching values (recipient, provider, service code, dates) but exclude modifiers.

      1. Note: This is an alteration to standard Netsmart EVV behavior to meet the Therap/DD use case,

2. If a matching PA is not found, then Netsmart EVV will display Authorization Not Found (PNOT) claims matching error if the PNOT error is configured for the payer.

3. If a matching PA is found, then Netsmart will check if there are enough remaining units on the PA.

4. If there are not enough remaining units for the visit, then Netsmart will throw Authorization Not Enough Units (PUNT) claims matching error if the PUNT error is configured for the payer.

5. Once all errors are addressed Netsmart EVV will place the claim in a MATCHED status and will decrement the claimed units from the PA.

6. When the PA is submitted to the Payer, then the authorization number that was passed in on the Rendered Services feed will be transmitted in the 837 message.

Error Codes Returned by Netsmart

Netsmart will return the following error codes in Reject files.   See above samples for location of the codes in the file layout.