Alternate EVV Vendor Integration

Owned by Pernicano, Christopher (Deactivated)
Last updated: May 11, 2023 by Josh Beale
10 min read

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

File Invalid file id - UNKNOWN_MEDIA_ID

May 11, 2023 by Josh Beale

PDF File Netsmart - Alternate EVV Vendor - Highmark Wholecare v3.pdf

Nov 14, 2023 by Josh Beale

Microsoft Excel Spreadsheet Netsmart Alternate EVV Test Scenarios.xlsx

Dec 07, 2021 by Leach, Brad

PDF File Netsmart Alternate EVV Vendor Implementation Guide 092023.pdf

Nov 14, 2023 by Josh Beale

Microsoft Excel Spreadsheet Rendered Service 2.0 Data Dictionary.xlsx

Oct 12, 2023 by Josh Beale

Text File Rendered Service 2.0 Pipe Delimited Sample.txt

Jan 26, 2022 by Leach, Brad

XML File Rendered Service 2.0 XML Accepted Response.xml

Jan 26, 2022 by Leach, Brad

XML File Rendered Service 2.0 XML Sample.xml

Jan 26, 2022 by Leach, Brad

XML File Rendered Service v2.0 XML File (Rejected Response) 20190912.xml

Sept 12, 2019 by Giannola, Giovanni - TELLUS

Text File Rendered Services 2.0 Flat File (Rejected Response) 20200807.txt

Dec 10, 2020 by Leach, Brad

PNG File WebHook Screenshot.png

Aug 26, 2020 by Pernicano, Christopher

Developer Notes

File Specification Variations by State

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

State

Variations

State

Variations

FL

  • Jurisdication = FL

  • Delivery System = FFFS

  • InvoiceUnits - Only whole number units allowed.

KY

  • Jurisdication = KY

  • Payer = CHFS

  • Plan = NONE

  • Program = (null)

  • Delivery System = FFFS

  • ProviderMedicaidId is a required field (CHFS Billing Provider Medicaid ID)

  • ProviderNpi is an optional field.

NE

  • Jurisdication = NE

  • Payer = NDHH

  • Plan = NONE

  • Program = (null)

  • Delivery System = FFFS

  • ProviderMedicaidId is a required field (8-character identifier for each location from DHHS N-focus)

  • ProviderNpi is an optional field.

  • RecipientMedicaidId - Set to DHHS N-focus ID

  • RecipientMemberId - Mandatory, set to DHHS N-focus ID

  • ServiceCode for these service codes, modifiers are mandatory to differentiate between service codes that have multiple possible rates:

    • 2639 G2 for Group of 2

    • 2639 G3 for Group of 3

    • 7494 G2 for Group of 2

    • 7494 G3 for Group of 3

    • 2656 D0 (0=zero) for Daily Rate

    • 2656 H0 (0=zero) for Hourly Rate

    • 5761 H0 (0=zero) for Hourly Rate

    • 5761 V0 (0=zero) for Per Visit/Occurrence Rate

    • 6496 H0 (0=zero) for Hourly Rate

    • 6496 V0 (0=zero) for Per Visit/Occurrence Rate

    • 9510 H0 (0=zero) for Hourly Rate

    • 9510 V0 (0=zero) for Per Visit/Occurrence Rate

    • 8148 D0 (0=zero) for Daily Rate

    • 8148 H0 (0=zero) for Hourly Rate

  • DiagnosisCode1 - Optional.  Set to R69 as default, according to DHHS.

  • Tasks - Mandatory for non DD programs

PA

  • Jurisdication = PA

  • Payer = GATE

  • Plan = NONE

  • Program = (null)

  • Delivery System = FFFS

  • ProviderMedicaidId is a required field (GateTech Vendor ID)

VA

  • Jurisdication = VA

  • Delivery System = FFFS

  • InvoiceUnits - Only whole number units allowed.

GA

  • Jurisdication = GA

  • Payer = GDCH

  • Plan = NONE

  • Program = 

    • 590-CCSP for Community Care Services (CCSP)

    • 660-ICWP for Independent Care Waiver Program (ICWP)

    • 680-NOW for New Options Waiver (NOW)

    • 681-COMP for Comprehensive Supports (COMP) Waiver

    • 930-SOURCE for Service Options Using Resources in a Community Environment (SOURCE)

    • 971-GAPP for GA Pediatric Waiver (GAPP)

  • Delivery System = FFFS

  • ProviderMedicaidId is a required field. Note: ProviderNPI is not required.

    • Georgia does not require visits that cross midnight to be split at midnight.

MT

  • Jurisdication = MT

  • Payer = MTMC

  • Plan = NONE

  • Program = 

  • Delivery System = FFFS

  • ProviderMedicaidId is a required field, the Provider’s Payer ID. Note: ProviderNPI is not required.

  • Montana does not require visits that cross midnight to be split at midnight.

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 3rd party to be grouped into a single claim.  Sometimes the 3rd 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 3rd 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 3rd 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.

FIELD

ERROR CODE

ERROR DESCRIPTION

837P NOTES

FIELD

ERROR CODE

ERROR DESCRIPTION

837P NOTES

VisitId

000

MRTH SRVC 000 Invalid Visit-Already-Completed-In-System

 

Recipient

001

MRTH SRVC 001 Invalid Recipient-Does-Not-Exist-In-System

 

Payer

002

MRTH SRVC 002 Invalid Payer-Not-Exist-In-System

 

Provider

003

MRTH SRVC 003 Invalid Provider-Does-Not-Exist-In-System

 

SourceSystem

710

MRTH SRVC 710 Invalid SourceSystem

 

Jurisdiction

720

MRTH SRVC 720 Invalid Jurisdiction

 

Payer

730

MRTH SRVC 730 Invalid Payer

 

Plan

740

MRTH SRVC 740 Invalid Plan

 

Program

750

MRTH SRVC 750 Invalid Program

 

DeliverySystem

760

MRTH SRVC 760 Invalid DeliverySystem

 

ProviderName

770

MRTH SRVC 770 Invalid ProviderName

 

ProviderMedicaidId

780

MRTH SRVC 780 Invalid ProviderMedicaidId

 

ProviderNPI

790

MRTH SRVC 790 Invalid ProviderNPI

 NM1*85 Position 9, length 10

ProviderNPITaxonomy

800

MRTH SRVC 800 Invalid ProviderNPITaxonomy

PRV*03

ProviderNPIZipCode

810

MRTH SRVC 810 Invalid ProviderNPIZipCode

 

ProviderEin

820

MRTH SRVC 820 Invalid ProviderEin

 

CaregiverFirstName

830

MRTH SRVC 830 Invalid CaregiverFirstName

NM1*DQ Position 4

CaregiverLastName

840

MRTH SRVC 840 Invalid CaregiverLastName

NM1*DQ Position 3

CaregiverLicenseNumber

850

MRTH SRVC 850 Invalid CaregiverLicenseNumber

REF*DQ Position 2

RecipientMedicaidId

860

MRTH SRVC 860 Invalid RecipientMedicaidId

NM1*IL Position 9, length < 14, no spaces or decimals

RecipientMemberId

870

MRTH SRVC 870 Invalid RecipientMemberId

 

RecipientFirstName

880

MRTH SRVC 880 Invalid RecipientFirstName

NM1*IL Position 4

RecipientLastName

890

MRTH SRVC 890 Invalid RecipientLastName

NM1*IL Position 3

RecipientDob

900

MRTH SRVC 900 Invalid RecipientDob

DMG02 

ServiceAddress1

910

MRTH SRVC 910 Invalid ServiceAddress1

N3*PW Position 1 No special chars ie. (*,#,-)

ServiceAddress2

920

MRTH SRVC 920 Invalid ServiceAddress2

N3*PW Position 2 No special chars ie. (*,#,-)

ServiceCity

930

MRTH SRVC 930 Invalid ServiceCity

N4*PW Position 1

ServiceState

940

MRTH SRVC 940 Invalid ServiceState

N4*PW Position 2

ServiceZip

950

MRTH SRVC 950 Invalid ServiceZip

N4*PW Position 3, length 5 or 9

VisitId

960

MRTH SRVC 960 Invalid VisitId

 

ServiceCode

970

MRTH SRVC 970 Invalid ServiceCode

SV1.01.2

ServiceCodeMod1

980

MRTH SRVC 980 Invalid ServiceCodeMod1

SV1.01.3

ServiceCodeMod2

990

MRTH SRVC 990 Invalid ServiceCodeMod2

SV1.01.4

ServiceCodeMod3

991

MRTH SRVC 991 Invalid ServiceCodeMod3

SV1.01.5

ServiceCodeMod4

992

MRTH SRVC 991 Invalid ServiceCodeMod4

SV1.01.6

DiagnosisCode1

1000

MRTH SRVC 1000 Invalid DiagnosisCode1

HI.01.2

DiagnosisCode2

1010

MRTH SRVC 1010 Invalid DiagnosisCode2

HI.01.3

DiagnosisCode3

1020

MRTH SRVC 1020 Invalid DiagnosisCode3

HI.01.4

DiagnosisCode4

1030

MRTH SRVC 1030 Invalid DiagnosisCode4

HI.01.5

StartVerificationType

1040

MRTH SRVC 1040 Invalid StartVerificationType

 

EndVerificationType

1050

MRTH SRVC 1050 Invalid EndVerificationType

 

SheduledStartDateTime

1060

MRTH SRVC 1060 Invalid SheduledStartDateTime

Date = DTP.02  Time = SV1.01.7  before dash

ScheduledStartDateTime

1061

MRTH SRVC 1061 Unable to Parse ScheduledStartDateTime

 

ScheduledEndDateTime

1070

MRTH SRVC 1070 Invalid ScheduledEndDateTime

Date = DTP.03  Time = SV1.01.7  after dash

ScheduledEndDateTime

1071

MRTH SRVC 1071 Unable to Parse ScheduledEndDateTime

 

ScheduledLatitude

1080

MRTH SRVC 1080 Invalid ScheduledLatitude

 

ScheduledLongitude

1090

MRTH SRVC 1090 Invalid ScheduledLongitude

 

StartDatetime-After-EndDatetime

1099

MRTH SRVC 1099 Invalid StartDatetime-After-EndDatetime

 

ActualStartDateTime

1100

MRTH SRVC 1100 Invalid ActualStartDateTime

Date = DTP.02  Time = SV1.01.7  before dash

ActualStartDateTime

1101

MRTH SRVC 1101 Unable to Parse ActualStartDateTime

 

ActualEndDateTime

1110

MRTH SRVC 1110 Invalid ActualEndDatetime

Date = DTP.03  Time = SV1.01.7  after dash

ActualEndDateTime

1111

MRTH SRVC 1111 Unable to Parse ActualEndDateTime

 

ActualStartLatitude

1120

MRTH SRVC 1120 Invalid ActualStartLatitude

 

ActualStartLongitude

1130

MRTH SRVC 1130 Invalid ActualStartLongitude

 

ActualEndLatitude

1140

MRTH SRVC 1140 Invalid ActualEndLatitude

 

ActualEndLongitude

1150

MRTH SRVC 1150 Invalid ActualEndLongitude

 

UserField1

1160

MRTH SRVC 1160 Invalid UserField1

CLM01.1

UserField1

1162

MRTH SRVC 1162 Invalid UserField1 Length > 17 Characters

UserField1 is transmitted in 837 and returned in 835 using the following fields, which are 20 characters in length.

837P: 2300|CLM01-2 --> 835RA: 2100|CLP|CLP01-2

Netsmart reserves the last 3 characters to add a suffix that is necessary for return file transaction matching.   See "Special Handling of UserField1" section above for additional details.

UserField2

1170

MRTH SRVC 1170 Invalid UserField2

 

UserField3

1180

MRTH SRVC 1180 Invalid UserField3

 

ReasonCode1

1190

MRTH SRVC 1190 Invalid ReasonCode1

 

ReasonCode2

1200

MRTH SRVC 1200 Invalid ReasonCode2

 

ReasonCode3

1210

MRTH SRVC 1210 Invalid ReasonCode3

 

ReasonCode4

1220

MRTH SRVC 1220 Invalid ReasonCode4

 

TimeZone

1230

MRTH SRVC 1230 Invalid TimeZone

 

VisitNote

1235

MRTH SRVC 1235 Invalid VisitNote

 

EndAddress1

1240

MRTH SRVC 1240 Invalid EndAddress1

 

EndAddress2

1241

MRTH SRVC 1241 Invalid EndAddress2

 

EndCity

1242

MRTH SRVC 1242 Invalid EndCity

 

EndState

1243

MRTH SRVC 1243 Invalid EndState

 

EndZip

1244

MRTH SRVC 1244 Invalid EndZip

 

VisitStatus

1250

MRTH SRVC 1250 Invalid VisitStatus

 

MissedVisitReason

1251

MRTH SRVC 1251 Invalid MissedVisitReason

 

MissedVisitActionTaken

1252

MRTH SRVC 1252 Invalid MissedVisitActionTaken

 

InvoiceUnits

1253

MRTH SRVC 1253 Invalid InvoiceUnits

 

InvoiceAmount

1254

MRTH SRVC 1254 Invalid InvoiceAmount

 

InvoiceRate

1255

MRTH SRVC 1255 Invalid InvoiceRate

 

ScheduledEndLatitude

1260

MRTH SRVC 1255 Invalid ScheduledEndLatitude

 

ScheduledEndLongitude

1261

MRTH SRVC 1256 Invalid ScheduledEndLongitude

 

PaidAmount

1265

MRTH SRVC 1260 Invalid PaidAmount

 

CareDirectionType

1270

MRTH SRVC 1270 Invalid CareDirectionType

 

Tasks

1280

MRTH SRVC 1280 Invalid Tasks

 

CaregiverType

1282

MRTH SRVC 1282 Invalid CaregiverType

 

StartAddressType

1283

MRTH SRVC 1283 Invalid StartAddressType

 

EndAddressType

1284

MRTH SRVC 1284 Invalid EndAddressType

 

ReferringPhysicianFirstName

1300

MRTH SRVC 1300 Invalid ReferringPhysicianFirstName

 

ReferringPhysicianLastName

1305

MRTH SRVC 1305 Invalid ReferringPhysicianLastName

 

ReferringPhysicianNPI

1310

MRTH SRVC 1310 Invalid ReferringPhysicianNPI

 

ReferringPhysicianNpiTaxonomy

1315

MRTH SRVC 1315 Invalid ReferringPhysicianNpiTaxonomy

 

ProviderAddress

1320

MRTH SRVC 1320 Invalid ProviderAddress

 

ProviderAddress2

1325

MRTH SRVC 1325 Invalid ProviderAddress2

 

ProviderCity

1330

MRTH SRVC 1330 Invalid ProviderCity

 

ProviderState

1340

MRTH SRVC 1340 Invalid ProviderState

 

ProviderZip

1350

MRTH SRVC 1350 Invalid ProviderZip

 

RecipientGender

1355

MRTH SRVC 1355 Invalid RecipientGender

 

AuthorizationID

1360

MRTH SRVC 1360 Invalid AuthorizationID

 

ICNPayerClaimNumber

1370

MRTH SRVC 1370 Invalid ICNPayerClaimNumber

 

ProviderInvoiceNumber

1380

MRTH SRVC 1380 Invalid ProviderInvoiceNumber

 

TransactionControlNumber

1390

MRTH SRVC 1390 Invalid TransactionControlNumber

 

ClaimType

1400

MRTH SRVC 1400 Invalid ClaimType

 

InvoiceStartDateTime

1410

MRTH SRVC 1410 Invalid InvoiceStartDateTime

 

InvoiceStartDateTime

1411

MRTH SRVC 1411 Unable to Parse InvoiceStartDateTime

 

InvoiceEndDateTime

1420

MRTH SRVC 1420 Invalid InvoiceEndDateTime

 

InvoiceEndDateTime

1421

MRTH SRVC 1421 Unable to Parse InvoiceEndDateTime

 

CaregiverEvvId

1430

MRTH SRVC 1430 Invalid CaregiverEvvId

 

CaregiverDob

1440

MRTH SRVC 1440 Invalid CaregiverDob

 

CaregiverDob

1441

MRTH SRVC 1441 Unable to Parse CaregiverDob

 

CaregiverSsn

1450

MRTH SRVC 1450 Invalid CaregiverSsn

 

RecipientSsn

1460

MRTH SRVC 1460 Invalid RecipientSsn

 

TransactionId

1470

MRTH SRVC 1470 Invalid TransactionId

 

CaregiverEmail

1480

MRTH SRVC 1480 Invalid CaregiverEmail

 

SOCPaid

1490

MRTH SRVC 1490 Invalid SOCPaid

 

TPLPaid

1500

MRTH SRVC 1500 Invalid TPLPaid

 

TPLPaidDate

1510

MRTH SRVC 1510 Invalid TPLPaidDate

 

TPLPayerType

1520

MRTH SRVC 1520 Invalid TPLPayerType

 

TPLPayerName

1530

MRTH SRVC 1530 Invalid TPLPayerName

 

TPLPayerID

1540

MRTH SRVC 1540 Invalid TPLPayerID

 

TPLPayerAddress1

1550

MRTH SRVC 1550 Invalid TPLPayerAddress1

 

TPLPayerAddress2

1560

MRTH SRVC 1560 Invalid TPLPayerAddress2

 

TPLPayerCity

1570

MRTH SRVC 1570 Invalid TPLPayerCity

 

TPLPayerState

1580

MRTH SRVC 1580 Invalid TPLPayerState

 

TPLPayerZip

1590

MRTH SRVC 1590 Invalid TPLPayerZip

 

TPLDeduct

1600

MRTH SRVC 1600 Invalid TPLDeduct

 

TPLDeductDate

1610

MRTH SRVC 1610 Invalid TPLDeductDate

 

TPLDeniedAmount

1620

MRTH SRVC 1620 Invalid TPLDeniedAmount

 

TPLDeniedDate

1630

MRTH SRVC 1630 Invalid TPLDeniedDate

 

ServiceCode + modifiers

1640

MRTH SRVC 1640 Procedure Code Not Configured

 

 

1650

MRTH SRVC 1650 Unable to Match to Unique Payer Provider (Pending CO NTSTEVV-NTSTEVV-3229)