Post on 11-Oct-2020
AuthentiCare®
Data Aggregator Interface
Guide
Version: 4.0
October 21, 2020
P a g e 2 | 24
Contents Revision History .............................................................................................................................. 3
Acronyms ........................................................................................................................................ 3
The AuthentiCare® Data Aggregator .............................................................................................. 4
1.1 Claims and Encounters .................................................................................................... 4
1.2 Arkansas Model - Claims and Encounters ...................................................................... 5
1.3 Arkansas Specific Data .................................................................................................... 5
1.4 Services and Activity Codes ............................................................................................ 6
1.5 Aggregator Support .......................................................................................................... 7
1.6 Receiving Access to Import Data ..................................................................................... 7
1.6.1 New User .................................................................................................................. 7
1.6.2 Existing User ............................................................................................................. 7
1.7 File Layout Designer ........................................................................................................ 7
1.7.1 Access a Standard File Layout in File Layout Designer .......................................... 8
1.7.2 Create a Custom File Layout in File Layout Designer ............................................. 9
1.8 Importing Data from External Systems .......................................................................... 14
1.8.1 Importing via the AuthentiCare Website ................................................................. 14
1.8.2 Importing via Web Services Data Transfer ............................................................ 16
1.8.3 Importing via SFTP using First Data File Gateway (FDFG) ................................... 17
1.9 File Import Guidelines .................................................................................................... 18
1.10 File Layout for Claim Data Imports ................................................................................ 19
1.11 File Layout for Encounter Data Imports ......................................................................... 21
1.11.1 Sample Files ........................................................................................................... 23
P a g e 3 | 24
Revision History
Table 1 lists this document’s revision history.
Table 1 – Revision History
Date Version Reason for Revision
07/22/2020 1.0 Arkansas Guide Document
08/25/2020 2.0 Addition of additional field
10/16/2020 3.0 Updating of File Layouts
10/26/2020 4.0 Updated comments
Acronyms
Acronym Name
EVV Electronic Visit Verification
FDFG First Data File Gateway
FLD File Layout Designer
JSON JavaScript Object Notation
MCO Managed Care Organizations
SFTP Secure File Transfer Protocol
XML Extensive Markup Language
P a g e 4 | 24
The AuthentiCare® Data Aggregator
The Fiserv (formerly known as First Data) AuthentiCare Data Aggregator is the interface engine
that collects visit data from third-party (non-AuthentiCare) EVV systems and feeds that
information into AuthentiCare®. This feature provides an open specification for all third-party
software providers and Managed Care Organizations (MCOs) to integrate with the Aggregator
and to assure the claim adjudication process is seamless.
This document describes the AuthentiCare Data Aggregator, which supports importing claims
and encounters from external sources into the AuthentiCare system. AuthentiCare interfaces
with various client systems via import and export methods to import visit data and provide
acknowledgement, respectively.
This AuthentiCare Data Aggregator document is based on a standard AuthentiCare specification. Data can be securely transferred to the AuthentiCare system via the AuthentiCare website, SFTP, or web services.
Visit data can be added, updated – claims or encounters.
Provider, Worker(s), Client, and Service on each record must exist in the AuthentiCare Database for the data to be imported.
The import process will communicate successful results and errors via a results file (or a JSON response transaction for web services) as an acknowledgement to the user. Import results file for data imported via the AuthentiCare website and SFTP will only include the failed records. For data imported via web services, all transactions in the batch succeed or fail in their entirety if errors are present.
The AuthentiCare Data Aggregator includes a File Layout Designer (FLD) application that interfaces with AuthentiCare during the file import process. The purpose of the FLD is to provide users with the flexibility to submit a data file using an existing file layout from their EVV System rather than creating a new one just for AuthentiCare. The design is saved and associated with the user so it only needs to be set up once. Future imports for that user will reference the saved file layout.
The AuthentiCare Data Aggregator houses all visit information and demographics including Service, Provider, Client, Worker, and Claims Source, just as AuthentiCare does. Claims and Encounters can be uploaded from the File Upload page.
Files that include claim data that will be processed and exported by the AuthentiCare system for adjudication are grouped as Claims. Files of non-billable claims are imported and grouped as Encounters.
State Admin users, Payers and Providers can run AuthentiCare reports on visits imported from external EVV systems into the Claims Data Aggregator.
1.1 Claims and Encounters
A single file imported into AuthentiCare can include either billable claims (Claims) or non-billable
claims (Encounters), but not both. Each line item in the file represents a visit. There needs to be
a line item in the file for each multi-client or multi-service claim.
P a g e 5 | 24
Claims (Billable Claims) are files that include claim data that will be processed and exported for billing by AuthentiCare are grouped as Claims. These claims will go through all the claim workflows before they are inserted into the AuthentiCare database.
Encounters (Non-Billable Claims) are files that include claim data that are not processed and exported for billing by AuthentiCare are grouped as Encounters. Encounters will go through Electronic Visit Verification (EVV) workflows only before they are inserted into the AuthentiCare database. Encounters are visits that were already billed by another EVV system but the data needs to be in AuthentiCare for reporting purposes only.
1.2 Arkansas Model - Claims and Encounters
All Medicaid Providers using a Third Party EVV System Vendor will have their Third Party EVV
System Vendor transfer/upload a billable claims (Claims) file on a daily basis to AuthentiCare on
their behalf. The Third Party EVV System Vendor can transfer the file, but it is the responsibility
of the Provider to ensure the data is transmitted and received to ensure processing for payment
by the MMIS System. The Provider is responsible for logging into AuthentiCare to clear
exceptions and confirm billing for all claims submitted by the Third Party EVV System Vendor
before any claims will be transmitted to MMIS for payment.
All MCOs will be required to transfer/upload a Paid Visit (Encounters) file on a daily basis to
AuthentiCare. Only visits that are considered paid should be included in the file.
Transmitting data using the AuthentiCare Aggregator will be completed by a Third Party EVV
System Vendor or MCO.
1.3 Arkansas Specific Data
All Visits submitted from Third Party Vendors should contain the following fields: Check-In and
Check-Out Times, Check-In and Out Phone Number if IVR was used, Latitude and Longitude
coordinates if Mobile was used, activity codes if applicable. For Auth Units on a Respite Claim,
please use the same value that is being populated in the Actual Units field.
All Visits submitted from the MCOs should contain the following fields: Authorization Number (if
no Authorization please use “99999”, Check-In and Check-Out Times, Check-In and Out Phone
Number if IVR was used, Latitude and Longitude coordinates if Mobile was used, activity codes
if applicable,
Visits should not span more than 12 hours for Personal Care and Attendant Care and not span
more than 24 hours for Respite Care.
All Visits should round using the logic below:
Minutes Units
0 min–7 mins 0 units
8 mins–22 mins 1 unit
P a g e 6 | 24
23 mins– 37 mins 2 units
38 mins– 52 mins 3 units
53 mins–67 mins 4 units
68 mins–82 mins 5 units
83 mins – 97 mins 6 units
1.4 Services and Activity Codes
Arkansas Services
Service ID Service Description
ARKT1019 Personal Care Under 21
ARKT1019U3 Personal Care Over 21
ARKS5150 In Home Respite
ARKS5125U2 Agency Attendant Care
Activity Codes
Service Activity Code
T1019, T1019U3 Personal Grooming 41
T1019, T1019U3 Bathing 42
T1019, T1019U3 Meal Prep 43
T1019, T1019U3 Toileting 44
T1019, T1019U3 Housekeeping 45
T1019, T1019U3 Ambulation 46
T1019, T1019U3 Medication 47
T1019, T1019U3 Shopping 48
T1019, T1019U3 Dressing/ Undressing 49
T1019, T1019U3 Laundry 50
S5125U2 Bathing / Grooming 70
S5125U2 Dressing / Undressing 71
S5125U2 Toileting 72
S5125U2 Mobility 73
S5125U2 Eating 74
S5125U2 Meal Preparation 75
S5125U2 Shopping 76
S5125U2 Laundry / Housekeeping 78
S5125U2 Management of Meds / Treatments 79
P a g e 7 | 24
1.5 Aggregator Support
For support with the AuthentiCare Aggregator, please email
AuthentiCareAggregatorSupport@firstdata.com or call the AuthentiCare Client Service Team at
(800) 540-5126 during Standard Business Hours 8 am to 7 pm Monday through Friday Central
Time excluding holidays.
1.6 Receiving Access to Import Data
Users with the Vendor or MCO role have the ability to access FLD and import data on the
AuthentiCare website. Fiserv will provide a single user login to import claims.
Users use the Data Aggregator need to:
Receive a user login from Fiserv.
Log in to AuthentiCare website with the user login and password.
Follow the steps to access the FLD.
Define a standard or custom file layout for the files to be imported.
Import file via the AuthentiCare website, SFTP or web services.
Receive acknowledgement of the data imported.
1.6.1 New User
If the user is using the FLD for the first time, a new Customer ID is created in FLD. The FLD
Home Page displays the options to create a standard or custom file layout for Claims or
Encounters.
1.6.2 Existing User
If the user is an existing user, the FLD Home page displays the list of all previously defined file
layouts, both active and inactive. Users have the ability to edit or delete their file layouts. The
page also allows existing users to define a new file layout. Refer to 1.7.2 Create a Custom File
Layout in File Layout Designer for instructions on how to create an additional file layout.
1.7 File Layout Designer
File Layout Designer (FLD) interfaces with the AuthentiCare Data Aggregator during the file
import process. All the methods of import require the use of the FLD. Users access the FLD
from the AuthentiCare website (Home Page > Administration > File Layout Designer). The FLD
launches in a new browser window. Once users have chosen which file layout format to use and
have defined their file layouts specific to their agency, users may use the File Upload page to
import visit data into AuthentiCare.
Users can create one or more file layouts to import visits using FLD. Users have the flexibility to
choose the Standard File Layout or to create a Custom File Layout to import the file.
P a g e 8 | 24
Standard File Layout – a user would create a visit file in one of the specified formats with only
the fields requested by AuthentiCare
Custom File Layout – a user would use an existing file layout (file already created that has all
the required fields) and modify the File Layout in AuthentiCare to match the existing file layout in
their existing file
Users have to define their file layout(s) in FLD before they can import data. Users can import
multiple files into AuthentiCare in a day.
FLD supports comma delimited, tab delimited, pipe delimited, XML, and fixed-length flat file
formats. However, all these files need to have a .txt extension. The application will support a
ZIP file as long as it includes only one import file within the ZIP file. That one import file within
the ZIP must have .txt extension.
A user cannot log in to the FLD website directly. If a user attempts to log in to FLD directly, an
error message is displayed in Figure 1. Users must access FLD from the AuthentiCare website
(Home Page > Administration > File Layout Designer).
Figure 1 – Error Message for User Attempting to Log In to FLD Directly
Note: File Layout Designer supports the latest publicly available versions of Microsoft EDGE,
Mozilla Firefox and Google Chrome browsers. There is a known issue with Internet Explorer 11.
Google Chrome and Microsoft EDGE are the preferred browers.
1.7.1 Access a Standard File Layout in File Layout Designer
Once a Claims Administrator logs in to AuthentiCare and selects the FLD, the user can choose
the Standard File Format.
P a g e 9 | 24
1.7.2 Create a Custom File Layout in File Layout Designer
Users with the Claims Administrator user role take the following steps to create a Custom File
Layout.
1.7.2.1 Step 1: Select File Layout Designer
Select the File Layout Designer option under the Administration tab on the AuthentiCare toolbar
as shown in Figure 2.
Figure 2 – Selecting the File Layout Designer (FLD) menu option
1.7.2.2 Step 2: Define New Claim or Encounter
AuthentiCare then launches a new browser window and the user is navigated to the FLD Home
Page, shown in Figure 3. If the user has not previously defined a file layout, the page will
display the following message: You do not have any layouts defined. Click “Define new” button
to create new layout.
P a g e 10 | 24
Figure 3 – FLD Home Page
Clicking on the Define New button on the Claims section (For Third Party EVV Systems
Vendors Only) opens the standard file layout for Claims. Clicking on the Define New button on
the Encounters section (For MCOs Only) opens the standard file layout for Encounters.
1.7.2.3 Step 3: Define a New File Layout
Users navigate to this page by clicking the Define new button on the Home page. The user
must assign a name to the file layout and also specify the time period during which the import
process can use the file layout.
After clicking Define new, the File Layout Designer page displays. The Layout Details on this
page are pre-populated based on the import process type selected on the Home Page. All the
necessary fields to process a claim or encounter are pre-populated. Users are required to add
the effective dates to the defined file layout (for Claims or Encounters) to be used by the import
process. Users will only see the file layouts defined by them in AuthentiCare.
Figure 4 – File Layout Designer, also known as the File Layout Designer page
P a g e 11 | 24
Each line item on the import file is a visit record. Users can list the contents of the visit record in
the Name field and map those against the AuthentiCare defined fields listed under Mapped
Field. The page also provides a Help screen that displays the acceptable format for the
contents of the claim record. Users can define a custom file layout by using the arrow buttons
and adjusting the order of the contents of the claim record to match the import file, as shown in
Figure 5. All required fields have to be mapped before the layout can be saved.
Figure 5 – Mapping Claim Fields
Additional fields in the import file can be added by clicking the Add New field button. The fields
can then be moved up as required to match its position in the claim record, as shown in Figure 6
Note: Any additional fields beyond the Standard File Layout that are mapped will not be
imported into the AuthentiCare Database.
Note: Layout Details will not display the Length column for the comma delimited, pipe delimited,
tab delimited, and XML file types.
P a g e 12 | 24
Figure 6 – Adding New Field
Once users have defined the file layout, they are ready to import data into AuthentiCare, shown
in Figure 7.
Figure 7 – With two defined layouts, the provider is ready to import visit data
1.7.2.4 Step 4: Editing an Existing File Layout
Users can edit an existing file layout by clicking the Edit button next to the file layout on the FLD
Home page. The user is navigated to the Layout Designer page. If the file layout is currently
active, then only the end date can be edited. All other fields are read only.
If the file layout has the start date in the future, then users can make any of the following edits
on the page, shown in Figure 8
Edit the Layout Header or Layout Details
Delete one or more optional fields
Change the order of the input fields
P a g e 13 | 24
Figure 8 – Editing File Layout Details
1.7.2.5 Step 5: Accessing the Help Page
The Help page assists the users in defining or editing the layout details of the import file. The
page can be accessed by clicking on the Help link on the right corner of the layout details
section, as indicated in Figure 9.
Figure 9 – Access the Help Page by Clicking “Help”
1.7.2.6 Step 6: Logout of FLD
Users access the FLD Logout page by clicking Logout in the FLD screen banner, indicated in
Figure 10.
Figure 10 – Logout Banner
The FLD Logout page displays, as shown in Figure 11.
P a g e 14 | 24
Figure 11 – Successful Log Out
1.8 Importing Data from External Systems
Users can import claims via the AuthentiCare Website, SFTP or Web Services.
1.8.1 Importing via the AuthentiCare Website
AuthentiCare users can upload a file using the AuthentiCare Website.
Users will have to login to AuthentiCare web and define the file layout for the import file
using File Layout Designer.
User can initiate the import on the File Upload page on the AuthentiCare web by
selecting the file type.
User can drop the claims file on the File Upload page on the AuthentiCare website by
selecting the file layout name defined in FLD, as shown in Figure 12.
Users will also need to add an email address on the page to receive notifications when
the file is processed.
A scheduled batch process runs every eight (8) minutes to import the data.
The File Upload web page provides a web acknowledgement of the file that was
uploaded.
P a g e 15 | 24
Figure 12 – Select the File Layout Name for Claims to Upload
When the import process is successful, the user receives an email notification to the
email address that was entered on the upload page. The process is said to be
successful when visits are passed to the claim queue.
The email notification will include the total records processed, total records successful,
and total records failed within the import process.
If a Claim or Encounter file is uploaded on the web, the Aggregator will provide a
standard XML Import Results file as a report.
The file will be available in the View Reports section of the Reports page on
AuthentiCare website, as shown in Figure 13. The user must have access to reports to
view the results report.
P a g e 16 | 24
Figure 13 – The View Reports Section of the AuthentiCare Website
1.8.2 Importing via Web Services Data Transfer
AuthentiCare interfaces with various client systems via import and export methods to import
claim data and provide a JSON response transaction to the user. Claims and Encounters can
be added or updated (marked inactive in AuthentiCare). Web service restricts the external
systems from sending transaction batches with more than 500 records.
Users will have to login to AuthentiCare web and define the file layout for the import file
using File Layout Designer.
Users are able to perform secure data transfer from their systems into AuthentiCare
system after a one-time setup of the file layout in AuthentiCare using the File Layout
Designer.
This web service creates the claims or encounter file and pushes it to the CIP (claim
import process).
All transactions succeed or fail in their entirety if there are errors or all the tags are not
present.
Web service will provide an acknowledgement to the users system with the status of the
data transmission, number of records received, and the batch ID.
If errors are found in a visit record, File Processor will reject the record and errors are
written to the results file which is accessed by logging into the web for reports.
P a g e 17 | 24
The Message Processor will move the claims from the queue to the database, this is
controlled by a scheduled batch process.
The File Processor will then generate a standard visit import xml and pass it to the claim
queue.
The process is said to be successful when claims are passed to the claim queue.
1.8.3 Importing via SFTP using First Data File Gateway (FDFG)
Users can also securely import claims into AuthentiCare via SFTP through the standard batch
process using First Data File Gateway. The import process can process multiple files from a
user in a day. Fiserv needs to be notified if the user decides to use a new file layout so that that
the mapping can be updated in AuthentiCare.
Users will have to login to AuthentiCare web and define the file layout for the import file
using File Layout Designer.
Users are able to perform secure data transfer from their systems into AuthentiCare
system after a one-time setup of the file layout in AuthentiCare using the File Layout
Designer.
File transfers though First Data File Gateway (FDFG) require a set up and testing
process. A request form must be submitted and processed and it will take approximately
thirty (30) days to setup, configure and test. It is recommended to all users to start by
uploading data via the File Upload page via the AuthentiCare website.
The FDFG team will assign a Job name/Class ID for each external Client. This tells
FDFG how to receive and route the submitted visit files.
The claim import process will prefix the External Claim ID with a mnemonic to prevent
collisions with the claim ID’s generated in AuthentiCare.
FDFG validates the input parameters with the mapping present in AuthentiCare
database.
If errors are found in a claim record, File Processor will reject the record and errors are
written to the results file.
The results file will be placed on FDFG to be picked by External Client.
If a valid mapping exists in AuthentiCare database, between the Class ID and a defined
file layout, File processor moves the import file to the specified input folder to be
accessed by Claims Import process.
The File Processor will then generate a standard claims import xml for the accepted
claim records and pass it to the claim queue. The claims import process is said to be
successful when claims are passed to the claim queue.
P a g e 18 | 24
1.9 File Import Guidelines
When importing files, users must follow these guidelines:
Files must be named in the following convention:
o From a Third Party Vendor:
SFTP - ARAG01AI.Claims_VENDOR_MMDDCCYYHHMSSS.txt
AuthentiCare Website –
Claims_VENDOR_MMDDCCYYHHMSSS.txt
Please substitute Vendor with appropriate Vendor Name
o From an MCO –
SFTP–
Empower Healthcare Solutions- ARAGGEMI.Encounters_ID223649727_MMDDCCYYHHMMSS.txt
Arkansas Total Care – ARAGGAMI.Encounters_ID223658727_MMDDCCYYHHMMSS.txt
Summit Community Care - ARAGGSMI.Encounters_ID224446727_MMDDCCYYHHMMSS.txt
AuthentiCare Website –
Empower Healthcare Solutions- Encounters_ID223649727_MMDDCCYYHHMMSS.txt
Arkansas Total Care – Encounters_ID223658727_MMDDCCYYHHMMSS.txt
Summit Community Care - Encounters_ID224446727_MMDDCCYYHHMMSS.txt
The format of the import file must match the file type selected on the File Upload page in AuthentiCare.
Claims cannot be imported with a file layout that has start date in the future. Claim dates cannot be in the future.
External claims coming through the import will be processed only for Clients who exist in AuthentiCare. Otherwise, the claims file will be rejected.
Providers must have have an existing relationship established in AuthentiCare with Clients and Workers.
AuthentiCare Claim Aggregator will prefix the external claim ID with a mnemonic followed by a hyphen in the AuthentiCare system. The mnemonic is unique to a Provider office. Prefixing the external claim ID with the mnemonic is to prevent collisions with claim ID's generated in the AuthentiCare system.
The ExternalClaimGroupID Field has an intended use to tie together cases where there are two or more services rendered in one visit with one check-in and one checkout. Since each claim record only documents one service, it takes a collection of them with the same check-in and checkout to document a visit with more than one service. In those cases we ask to
P a g e 19 | 24
be given a unique group id on all of the associated claims. In authenticare, the claim id of the first claim is used as the group id for the claims in the collection. This value in that field links all of the claims together as a group.
1.10 File Layout for Claim Data Imports
Table 2 – Import Fields for Claims (Third Party EVV Systems) defines each field.
Table 2 – Import Fields
Field Name Req Maximum Characters
Description Standard Content Validation
ExternalClaimID Y 56 Foreign Claim ID Alphanumeric
(Foreign key )
ExternalClaimGroupID N 56 If Claim Collection contains
more than one claim; External
Claim id of the first claim in the
collection
Alphanumeric
DeleteFlag Y 1 Insert/Update Insert/Update=0
Check-InTime Y 14 Check-in date time Jurisdiction time zone
YYYYMMDDHHMMSS
Check-OutTime Y 14 Check-out date time Jurisdiction time zone
YYYYMMDDHHMMSS
ServiceID Y 64 AuthentiCare Service Identifier Alphanumeric
ConsumerID Y 64 Medicaid ID for Client 10 digit ID
ProviderID Y 64 Medicaid ID for Billing Provider 9 digit ID
WorkerID Y 64 Medicaid ID for Worker 9 digit ID
Check-InBiometricFailed N 1 1 if Check-in biometric did not
match
0 – Match
1 – No match
Check-OutBiometricFailed N 1 1 if Check-out biometric did not
match
0 – Match
1 – No match
Check-InPhone N 10 IVR Check-in ANI 10 digit number with no
hyphens or parentheses
Check-OutPhone N 10 IVR Check-out ANI 10 digit number with no
hyphens or parentheses
Check-InAddressDesc N 56 Description for address location
at check-in.
Alphanumeric
Check-InLatitude N Decimal(11,8) Latitude of Check-in Location 999.99999999. If mobile
claim this is required.
Otherwise default to
000.000000000
Check-InLongitude N Decimal(11,8) Longitude of Check-in Location 999.99999999. If mobile
claim this is required.
P a g e 20 | 24
Field Name Req Maximum Characters
Description Standard Content Validation
Otherwise default to
000.000000000
Check-InMobile Card ID N 64 Identifier from Client Q/R Card
or other fixed Id device
gathered at check-in
Alphanumeric
Check-OutAddressDesc N 56 Description for address location
at check-out.
Alphanumeric
Check-OutLatitude N Decimal(11,8) Latitude of Check-out Location 999.99999999. If mobile
claim this is required.
Otherwise default to
000.000000000
Check-OutLongitude N Decimal(11,8) Longitude of Check-out
Location
999.99999999. If mobile
claim this is required.
Otherwise default to
000.000000000
Check-Out MobileCardID N 64 Identifier from Client Q/R Card
or other fixed Id device
gathered at checkout
Alphanumeric
Mileage N 3 Travel miles entered on IVR or
Mobile
Int
TravelTime N 3 Travel minutes entered on IVR
or Mobile
Int
ActualUnits Y 4 Actual completed units of
service
Int
AuthUnits Y 5 Units of service authorized for
billing Required field, enter the
same value entered in the
actual units field (Is this correct?
What are you expecting here?
How is this data used?)
Int
UnitsEntered N 5 Manually entered units for unit
based services.
Defaults to 0
ActualAmount N Decimal(15,2) Actual value of service 9999999999999.99
AuthAmount N Decimal(15,2) Amount authorized for billing 9999999999999.99
ActivityCode N Varchar(max) Activity code(s) and/or
observation code(s) entered by
worker, multiple activity codes
must be separated by ‘~!~’
Alphanumeric
ConsumerSignatureAvailable N 1 Indicates if the signature of the
consumer is on file
0 – Signature not on file
1 – Signature on file
Defaults to 0
ClientAttestation Y 1 Attestation received on the visit Alphanumeric
P a g e 21 | 24
Field Name Req Maximum Characters
Description Standard Content Validation
Yes = Y
No = N
VisitModification Y 1 Visit was modified before
submittal
Alphanumeric
Yes = Y
No = N
OriginalSystemClaimFilingSo
urce
Y 4 Filing Source of the Claim on
the Third Party EVV System
1=Web
2=IVR
4=Mobile
1.11 File Layout for Encounter Data Imports
Table 2 – Import Fields for Encounters (MCOs) defines each field.
Table 3 – Import Fields
Field Name Req Maximum Characters
Description Standard Content Validation
ExternalClaimID Y 56 Foreign Claim ID Alphanumeric
(Foreign key )
ExternalClaimGroupID N 56 If Claim Collection contains
more than one claim; External
Claim id of the first claim in the
collection is used in order to
represent a group of claims.
Alphanumeric
DeleteFlag Y 1 Insert/Update Insert/Update=0
Check-InTime Y 14 Check-in date time Jurisdiction time zone
YYYYMMDDHHMMSS
Check-OutTime Y 14 Check-out date time Jurisdiction time zone
YYYYMMDDHHMMSS
AuthorizationID Y 64 Authorization Identifier – If no
authorization is used, enter
99999
(Foreign key)
Alphanumeric
ServiceID Y 64 AuthentiCare Service Identifier Alphanumeric
ConsumerID Y 64 Medicaid ID for Client 10 digit ID
ProviderID Y 64 Medicaid ID for Billing Provider 9 digit ID
WorkerID Y 64 Medicaid ID for Worker 9 digit ID
Check-InBiometricFailed N 1 1 if Check-in biometric did not
match
0 – Match
1 – No match
Check-OutBiometricFailed N 1 1 if Check-out biometric did not
match
0 – Match
1 – No match
P a g e 22 | 24
Field Name Req Maximum Characters
Description Standard Content Validation
Check-InPhone N 10 IVR Check-in ANI 10 digit number with no
hyphens or parentheses
Check-OutPhone N 10 IVR Check-out ANI 10 digit number with no
hyphens or parentheses
Check-InAddressDesc N 56 Description for address location
at check-in.
Alphanumeric
Check-InLatitude N Decimal(11,8) Latitude of Check-in Location 999.99999999. If mobile
claim this is required.
Otherwise default to
000.000000000
Check-InLongitude N Decimal(11,8) Longitude of Check-in Location 999.99999999. If mobile
claim this is required.
Otherwise default to
000.000000000
Check-InMobile Card ID N 64 Identifier from Client Q/R Card
or other fixed Id device
gathered at check-in
Alphanumeric
Check-OutAddressDesc N 56 Description for address location
at check-out.
Alphanumeric
Check-OutLatitude N Decimal(11,8) Latitude of Check-out Location 999.99999999. If mobile
claim this is required.
Otherwise default to
000.000000000
Check-OutLongitude N Decimal(11,8) Longitude of Check-out
Location
999.99999999. If mobile
claim this is required.
Otherwise default to
000.000000000
Check-Out MobileCardID N 64 Identifier from Client Q/R Card
or other fixed Id device
gathered at checkout
Alphanumeric
Mileage N 3 Travel miles entered on IVR or
Mobile
Int
TravelTime N 3 Travel minutes entered on IVR
or Mobile
Int
Rate N Decimal(15,2) Billing rate per unit Defaults to 0
9999999999999.99
ActualUnits Y 4 Actual completed units of
service
Int
AuthUnits Y 5 Units of service authorized for
billing
Int
UnitsEntered N 5 Manually entered units for unit
based services.
Defaults to 0
P a g e 23 | 24
Field Name Req Maximum Characters
Description Standard Content Validation
ActualAmount N Decimal(15,2) Actual value of service 9999999999999.99
AuthAmount N Decimal(15,2) Amount authorized for billing 9999999999999.99
ActivityCode N Varchar(max) Activity code(s) and/or
observation code(s) entered by
worker, multiple activity codes
must be separated by ‘~!~’
Alphanumeric
ConsumerSignatureAvailable N 1 Indicates if the signature of the
consumer is on file
0 – Signature not on file
1 – Signature on file
Defaults to 0
Client Attestation Y 1 Attestation received on the visit
Alphanumeric
Yes = Y
No = N
VisitModification Y 1 Visit was modified before
submittal
Alphanumeric
Yes = Y
No = N
CheckDate Y 8 Date paid YYYYMMDD
PaidUnits Y 4 Number of units paid Int
PaidAmount Y Decimal(15,2) Amount paid 9999999999999.99
OriginalSystemClaimFilingSo
urce
Y 4 Filing Source of the Claim on
the Third Party EVV System
1=Web
2=IVR
4=Mobile
1.11.1 Sample Files
XML
<Claim><ExternalClaimID>1120</ExternalClaimID><ExternalClaimGroupID>1120</ExternalCla
imGroupID><DeleteFlag>0</DeleteFlag><Check-InTime>20190721080000</Check-
InTime><Check-OutTime>20190721090000</Check-
OutTime><ServiceID>HCFES5150</ServiceID><ConsumerID>222222222222</ConsumerID><
ProviderID>10000302</ProviderID><WorkerID>072080</WorkerID><Check-
InBiometricFailed>0</Check-InBiometricFailed><Check-OutBiometricFailed>0</Check-
OutBiometricFailed><Check-InPhone>4025551212</Check-InPhone><Check-
OutPhone>4025551212</Check-OutPhone><Check-InAddressDesc>ADDR</Check-
InAddressDesc><Check-InLatitude>0.00000000</Check-InLatitude><Check-
InLongitude>0.00000000</Check-InLongitude><Check-InMobileCardID>400</Check-
InMobileCardID><Check-OutAddressDesc>ADDR</Check-OutAddressDesc><Check-
OutLatitude>0.00000000</Check-OutLatitude><Check-OutLongitude>0.00000000</Check-
OutLongitude><Check-OutMobileCardID>420</Check-
OutMobileCardID><Mileage>5</Mileage><TravelTime>20</TravelTime><ActualUnits>1</Actua
lUnits><AuthUnits>1</AuthUnits><UnitsEntered>1</UnitsEntered><ActualAmount>1</ActualA
mount><AuthAmount>1</AuthAmount><ActivityCode>99</ActivityCode><ConsumerSignatureA
vailable>0</ConsumerSignatureAvailable><ClaimAttestation>Y</ClaimAttestation><VisitModific
P a g e 24 | 24
ation>N</VisitModification><OriginalSystemClaimFilingSource>1</OriginalSystemClaimFilingS
ource></Claim>
Pipe Delimited
1111|1111|0|20190721080000|20190721090000|HCFES5150|222222222222|10000302|07208
0|0|0|4025551212|4025551212|ADDR|0.00000000|0.00000000|400|ADDR|0.00000000|0.00000
000|420|5|20|1|1|1|1|1|99|0|Y|N|1|
1112|1111|0|20190721090000|20190721100000|HCFES5120|222222333333|10000302|07208
0|0|0|4025551212|4025551212|ADDR|0.00000000|0.00000000|400|ADDR|0.00000000|0.00000
000|420|5|20|1|1|1|1|1|100|0|Y|N|2|
1113|1111|0|20190721100000|20190721110000|HCFES5130|222222333333|10000302|07208
0|0|0|4025551212|4025551212|ADDR|0.00000000|0.00000000|400|ADDR|0.00000000|0.00000
000|420|5|20|1|1|1|1|1|100|0|Y|N|4|
1114|1111|0|20190721110000|20190721120000|HCFES5135|222222333333|10000302|07208
0|0|0|4025551212|4025551212|ADDR|0.00000000|0.00000000|400|ADDR|0.00000000|0.00000
000|420|5|20|1|1|1|1|1|100|0|Y|N|2|
1115|1111|0|20190721120000|20190721130000|HCFES5130|222222444444|10000302|07208
0|0|0|4025551212|4025551212|ADDR|0.00000000|0.00000000|400|ADDR|0.00000000|0.00000
000|420|5|20|1|1|1|1|1|100|0|Y|N|2|
1116|1111|0|20190721130000|20190721140000|HCFES5150|222222444444|10000302|07208
0|0|0|4025551212|4025551212|ADDR|0.00000000|0.00000000|400|ADDR|0.00000000|0.00000
000|420|5|20|1|1|1|1|1|99|0|Y|N|2|
1117|1111|0|20190721140000|20190721150000|HCFES5120|222222555555|10000302|07208
0|0|0|4025551212|4025551212|ADDR|0.00000000|0.00000000|400|ADDR|0.00000000|0.00000
000|420|5|20|1|1|1|1|1|100|0|Y|N|2|
1118|1111|0|20190721150000|20190721160000|HCFES5135|222222555555|10000302|07208
0|0|0|4025551212|4025551212|ADDR|0.00000000|0.00000000|400|ADDR|0.00000000|0.00000
000|420|5|20|1|1|1|1|1|100|0|Y|N|2|
1119|1111|0|20190721160000|20190721170000|HCFES5150|222222555555|10000302|07208
0|0|0|4025551212|4025551212|ADDR|0.00000000|0.00000000|400|ADDR|0.00000000|0.00000
000|420|5|20|1|1|1|1|1|99|0|Y|N|2|