Requirements Document

GTT2017-04536
Healthcare Payment Integrity Platform (HPIP)
ETL Redesign
Version: 0.02

Contributors
Role Name Department
Owner
Contributor Matt Dickson Business
Contributor Mike Dunal MIS
Contributor Vamshi Kondela MIS
Reviewed By
Reviewed By
 Table of Contents

Project Overview ........................................................................................................................... 3

Purpose .....................................................................................................................................................3
Project - In Scope......................................................................................................................................3
Project - Out of Scope...............................................................................................................................4
Points of Contact ......................................................................................................................................4
Current System Summary ............................................................................................................ 5
Future System ................................................................................................................................ 6
Common Requirements (Applicable for all Clients) .................................................................. 8
Requirements: Consignment Application .................................................................................................8
Requirements: Pre-Check .......................................................................................................................12
Requirements: Data Masking .................................................................................................................13
Requirements: Design Guidelines .......................................................... Error! Bookmark not defined.
Requirements: Standardization – Validations.........................................................................................13
Requirements: Standardization – Diagnosis Codes Bypass....................................................................31
Requirements: Standardization – Formatting Rules ...............................................................................33
Client: CIGNA - PowerMHS (Client #860) .............................................................................. 34
EDI File Layout ......................................................................................................................................35
Requirements: Standardization – Bypass Rules for Client 860 ..............................................................36
Requirements: Standardization – Conversion Rules ..............................................................................37
Requirements: EDI Load Process ........................................................... Error! Bookmark not defined.
Requirements: Merge & CAP ................................................................. Error! Bookmark not defined.
Consignment Homepage ......................................................................... Error! Bookmark not defined.
Consignments by Client .......................................................................... Error! Bookmark not defined.
Consignment Search Page ...................................................................... Error! Bookmark not defined.
Consignment Detail Page ....................................................................... Error! Bookmark not defined.

Revision History
Date Version Reason For Change Author(s)
2/7/2018 0.01 Initial Draft Sai Salveru
04/04/2018 0.02 Dana Embery
9/20/2018 0.03 Source File information, bypass rules John Kasap
PROJECT OVERVIEW
PURPOSE
The document contains the requirements for TPL ETL process redesign efforts. Project ID: GTT2017 - 04536

Currently, TPL ETL (aka - EDI Process) is built 14+ years ago handled by different technologies stack (4GL,
DMExpress, COBOL, Python, C, and SSIS etc.). Over the years the system is maintained and/or upgraded as
per the business needs. Also, the lack of detailed documentation, the complexity of the current system code has
been a challenge to upgrade the systems and create a sustainable system to depend on.

The new ETL redesign effort is to fix the underlying and core problems of the current EDI solution and create a
robust ETL platform with following objectives.
1. Create ETL solution with technology stack and architecture that is easy to sustain, upgrade and modify.
2. Create ETL that is clearly documented, and component driven
3. Capture metrics that is required during the entire process. Setup KPIs and monitor each consignment
processing.
4. ETL Process that can handle multiple client(s) consignments at same time and improve processing.

PROJECT - IN SCOPE
The scope of the project will focus on the following modules (high level components):

 Standardize Client Consignment Data – This is the process that takes client consignment data and
turns the Conduent standard record layout. This process assumes that client data is provided in a single
record layout format.
o There can be clients where we receive client consignment in multiple files. In those cases, a pre-
processor program should be built to combine all files into single file.
o This process also identified new groups/policies for the client and create a file of policies that
shall be loaded into the system and notified to client services as new policies.

 Load Client Consignment Data – This is the process that takes the Conduent standard record layout
and load the data into TPL standard database (aka Claims Holding Area (CHA)).

 Capture Metrics - This focus on all the metrics we have to manage as part of the consignment
processing.

 Monitor KPIs and Alter Process – This features and metrics management will help operations
management team to monitor and also alert when we have issues any client consignment(s).

 Identify Potential Cases (Potential Incidents to Pursue) –

 Open Cases in Production –
 Pharmacy Claims Processing and Add Claims to Cases –
 Redesign TCI Application for New ETL Platform –
 Reporting Requirements and Modification to Current Reports – This task is to review all current
reports, analyze and fix the reports based on changes needed to display the information from new SSIS
process where needed. New reports/dashboards on new ETL process and based on new metrics/ KPIs
we capture.
PROJECT - OUT OF SCOPE
The details required are requirements that were discussed during the project analysis but were not considered
critical and are documented here. These requirements shall be handled and/or implemented when needed.
Alternate business/system processes required to handle this functionality will be documented as needed.

 SFTP and Job Automation – The feature will be looked at later point as the 1st phase is to focus on
implementing the new ETL and have 2 to 3 clients in the new process. As we move more clients to new
ETL process, then we can look at the automation of consignment handling. This task will be handled by
production support team until we complete the automation.

This module focus on requirements to kick off the ETL process when there are new client consignments.
The client consignments are either pushed to our SFTP or we have to download from client SFTP. This
automation will enable us to process files the moment they are available with minimal human
intervention. This is account for:
 Creating new consignment record and downloading the files
 Start the consignment process based on client configuration
 Monitor the process until completion
 Send out alerts to users when the consignment process is complete or even failed (with details).
 Changes in Bypass – Whenever client asks for removing a bypass that exists, this is a process we need
to run to check for all possible claims based on that bypass for the date range we can investigate and
load the cases accordingly. – We need to create a separate task for this task.

POINTS OF CONTACT
Project Team

Matt Dickson 801 352 5066

Business Owner (s): Phone:
Mathew Smith 801 352 5060
Vamshi Kondela 801 352 5093
MIS Delivery Owner (s): Mike Dunal Phone: 801 352 5083
Tejas Patel 801 352 5092
IT Project Manager: TBD Phone: TBD
Sai Kumar Salveru 971 244 2682
Business Analyst: Phone:
Dana Embery 801 563 3003
Developer(s): TBD Phone: TBD
QA Analyst(s): TBD Phone: TBD
Infrastructure Resource: TBD Phone: TBD
Production Resource: TBD Phone: TBD
CURRENT SYSTEM SUMMARY
The current EDI process receives data files from clients on a daily basis. The files are processed to extract
information needed for creating new TPL cases or updating existing ones. The TPL EDI process consists of four
distinct stages:
1) EXTRACT:
This process takes the raw data from the client (or data extracted from the COB EDI extract for TPL)
and formats the data into the Primax TPL EDI standard record layout. The morph program assumes
that all input file(s) to be processed are in a single record layout format. However, in some cases, the
client’s raw data also needs to be pre-processed before being morphed. An example of client data that
would need to be pre-processed would be if a client provides us separate files for eligibility, provider,
and claims. This would require a separate pre-processor step/program to combine these 3 separate
input files and merge them into one file format to be morphed. The morph process not only creates a
standard record layout file to be loaded, it also identifies any new groups/policies for the client and
creates a file of policies to be loaded

2) LOAD:
This process takes the data from the morph (in our standard record layout format) and loads it into the
TPL CHA. The following CHA tables are populated in the load: eims, dependents, claimheaders,
lineitems, claimcodes, & edi_remarks.
3) MERGE:
This process will group claims (claimheaders) to establish a period of care for each group of claims. A
group of claims is referred to as an episode. This process populates the episodes table and “links” one
or more claimheaders to an episode.
4) CAP (CLAIMS APPLIED TO PRODUCTION)
This process evaluates the “action code” on each episode to determine whether or not to open a new
case, add claim(s) to an existing case or to leave the claims in the CHA. This process is responsible for
inserting/updating all production database tables when new cases are opened and/or cases are updated
with new claims.
FUTURE SYSTEM
The future TPL EDI process will continue to receive the Client data files on a daily basis. The files will be
processed to pull (extract) the information needed to create new TPL cases and/or make updates to existing
cases. The future TPL EDI process will consist of four (4) distinct stages:
1) STANDARDIZATION
Standardization is the process that takes the Client Consignment data and converts it over to Conduent’
Standard Record Layout. The process assumes that the client data (i.e., eligibility, claim and provider) is
sent in a single file, when it is not, the separate files are run through a ‘pre-process’ program and
combined into a single file.
The standardization process also includes the following sub-processes:
 Login/Logout,
 Consignment creation (includes metrics/KPIs),
 Pre-check,
 Data masking,
 Validations,
 Bypass rules (DX and Client-specific), and
 Conversion (formatting rules)
When a new client and group/policy is identified during the standardization process, a policy file is
created and loaded into the system. Once complete, the standardized data is then processed in the later
stages to CHA DB.

A RCHITECTURE

Standard
Record
Pre-Check Validations
Layout
WWW FTP Mapping

Consignment
Source EDI File
Application
CHA

Client
Common
DX Bypass Specific
Bypass
ByPass

Masking
(offshore)
Standard Record Layout

Bypassed File
2) LOAD:
The Load process takes the standardized data and loads it into the TPL database, called CHA (Claims
Holding Area).

3) MERGE:

4) CAP (CLAIMS APPLIED TO PRODUCTION):

COMMON REQUIREMENTS (APPLICABLE FOR ALL CLIENTS)
REQUIREMENTS: CONSIGNMENT APPLICATION
The Consignment application will trigger the ETL process once we receive the source EDI files from the client.
Each run is tied up to a consignment ID which is auto generated when we trigger the ETL process.

Bu
sin
es
s Business Rule – Details and Acceptance Criteria
Ru
le
#
Source File Fetching:

The source EDI file will be downloaded by Production Support from multiple site sources either through
FTP or HTTPS may need PGP decryption and or decompressing. Once this is finished the file(s) are to be
placed in directories of the new ETL system for processing.

We can follow below folder structure OR any better approach suggested by IT.
../TPL/Prod/Data/Clients/SourceSystem/<Source EDI file>

After ETL Process is completed the Source EDI file should be moved automatically for later use.
CO We can follow folder structure as below OR any better approach suggested by IT.
N_ ../TPL/Prod/Data/Archive/SourceSystem/<MMDDYY>/<Source EDI file>
BR
1 Source System Name – Great West Facets (Client 712)
Source EDI File or Files Names – edi5:\hcr\data]clients\cl123\QW_ECSR
hv00017w.txt
hv00017x.txt
hv00017y.txt
hv00017z.txt

Files are received weekly. The file is fixed a fixed length file.
Directory is xprod_MMDDYYYY

Example edi5:/hcr/data/clients/cl123/GW_ECSR/xprod_08062018
The Great West data comes in the ASCII format. Great West has converted to the FACETS system.
These specifications are for the data coming from the new FACETS system. We will continue to receive
data from the old claims system as run out is being done on the old claim system… so for a while we will
be receiving Great West Denver and Great West St. Louis feeds from the old claim system as well as the
new claim system (FACETS).

Claims File:
Record Length: 355

Eligibility File:
Record Length: 282

Employer File:
Record Length: 198

Provider File:
Record Length: 222

Member Crosswalk File:

Record Length: delimited using “,”

There is a trailer record on every file that begins “ZZZZZZZZ”. ACSRS will bypass trailer records.

THE FOLLOWING ARE SPECIAL PROCESSING RULES:

A preprocessor will be required to process the Member Crosswalk file each month prior to
Claims processing. The purpose of the preprocessor is to load the Member Crosswalk table,
which determines the Insured ID Number (See below). EDI processing will abort if Crosswalk
processing has not been successfully completed prior to claims processing.

When processing the Claim file, the Conversion Effective Date on the Member Crosswalk file is
compared with the claim period on the Claim file. If no Conversion Effective Date on the
Member Crosswalk file is within the claim period, processing is placed on hold for review with
the message “Review Great West Member Crosswalk file – claim periods don’t match”.

Starting with the July 2010 data, a pre-processor program (edibgwpre.eco) will be required to
convert the new format data to the old format so the data will work with the existing FACETS
processing.
In addition to executing program edibgwpre.eco above, script edibgwpre.ksh will create and
maintain a table (rpt_gw_legal_ent) in the hcc@max_tcp database that is used in TPL
reporting. This table will contain unique Group Numbers (gw_group_id) with the earliest Paid
Date (gw_paid_date) for each group and the add date (gw_add_date) that the earliest Paid Date
was encountered. This table will also have a column for Legal Entity values (gw_legal_ent).
Currently the only value maintained in the table is “CHLIC”.

Eligibility File Access Information:

 The Key to Eligibility (Claims, field 3) has the following format and is matched to the Eligibility Key
(field 1) on the Eligibility file to retrieve Eligibility information:

Positions Definition
1–8 Employee Group ID
9 “-“
10 – 18 Subscriber ID (identifies the Family)
19 “-“
20 - 24 Member Suffix (identifies each unique member within a
family)

Subscriber

The Subscriber records are retrieved from the Eligibility file by utilizing Relationship Code field on the
Eligibility file. If the Relationship Code field is equal to a “SB” then this is a Subscriber record.

Spouse

The Spouse records are retrieved from the Eligibility file by utilizing the Relationship Code field on
the Eligibility file. If the Relationship Code field is equal to “SP” or “SS” then this is a Spouse
record.

Patient

The Patient records are retrieved from the Eligibility file by utilizing the Key to Eligibility (field 3) on
the Claim file and matching to the Key to Eligibility (field 1) on the Eligibility file. If the Relationship
Code field is not equal to “SB”, “SP” or “SS” then this is a Dependent record.

Provider File Access Information:

The key to the Provider file is Key to Provider File (Claims, field 4). This is a 12 position field that is

matched to the Provider ID (field 1) on the Provider file. Following is the information obtained from the

Provider file:

Provider ID (using Provider Number)

Provider Tax ID

Provider National Provider ID

Provider Name

Provider Address1

Provider Address2
 Provider City

Provider State

Provider Zip Code

Provider Phone

Employer File Access Information:

The key to the Employer file is Employee Group (Claims, field 5). This is a 8 position field that is

matched to the Employee Group ID (field1) on the Employer record. Following is the information

obtained from the Group record:

Employee’s Employer Name

Below is where the conversion and mapping specs can be found Conversion Specs: Great West FACETS
TPL Conversion Specs, Mapping Specs: Great West FACETS TPL Mapping Specs.

https://sp.services.conduent.com/hfi/sites/RSPortal/EDI/Forms/AllItems.aspx?Paged=TRUE&p_FS
ObjType=0&p_FileLeafRef=DATAREQ%2eXLS&p_ID=647&View=%7b9D1740DE%2d5283%2d4CF9
%2d8944%2dF0BECAC29E79%7d&RootFolder=%2fhfi%2fsites%2fRSPortal%2fEDI%2fProduct%20
Documentation%2fTPL%2fClient%20Conversion%20and%20Mapping%20Specs&FolderCTID=0x01
2000C5E8C215A3360D458EA605298EA8D903&PageFirstRow=201

*Note:
MMDDYY  Is the folder name which is intended to hold data for a specific week e.g., 29-Jan-2018, 22-
Jan-2018
Assumptions:
Production support (Raj or Linda) will continue manual download of the raw data for each client and they
will follow the existing schedule for download. This manual download process will continue and
automation is out of scope.
REQUIREMENTS: PRE-CHECK Commented [SS1]: Sai to fill this section when
converting to US.

Business
Business Rule – Details and Acceptance Criteria
Rule #
Pre-Check is the preliminary process which does high level validation whether to process
the client EDI file.
Should Validate
1) Presence of the Source EDI file in the respective clients folder
2) File Layout. <Record length greater or lesser than the average standard size for
the specific client>
3) File size <Should check the average historical size in last X months with the
current size>
4) Source File Name <Any deviation from the regular naming convention>
STD_PCHK_BR1
5) Frequency <Any deviation from the regular frequency >
6) Duplicate File <Is the file previously processed?>
7) Paid date range is against the frequency of expected date range <this step may
have to read the whole file before we can abort the process.>

All the validation should be configurable. Whether to perform these checks for a specific
client or not.

Metrics:

System should capture the below metrics

a) Start & End Timestamp each check performed
b) Type of check performed < File Layout check, File presence check, File Size,
Source File Name, Duplicate File, Paid Date Range etc>
STD_PCHK_BR2
c) Status of each check performed <Passed or Fail>
d) Overall Status of the Pre-check process <Passed, Aborted>
e) Issues created
f) Consignment ID
g) Source System
h) Client ID/Client Name
 If the Pre-check validation fails then the no further processing should be made and email
the operations for investigation. Also system should open an issue/Ticket and assign to
STD_PCHK_BR3
Production support when the Pre-check process is aborted and this issue should capture
the abort reason.

REQUIREMENTS: DATA MASKING Commented [SS2]: Sai to review and confirm if

additional fields should be added.

Business
Business Rule – Details and Acceptance Criteria
Rule #
DTMSK_BR1
All the PHI data should be masked before it is sent to offshore for development.
The data should be encrypted/decrypted in such a way that the identity of the data is
not lost without impacting the development efforts.
Attached the data masking list for <Client>

REQUIREMENTS: STANDARDIZATION – VALIDATIONS Commented [SS3]: Natasha or John to fill this section.

Expect to update field reference from source file so we

Business know what field to use and apply the validation.
Business Rule – Details and Acceptance Criteria
Rule #
As a part of Standardization validations the system should perform validations on all the
STD_VAL_BR1 fields listed in<BR8 to BR35> and when it fails the validation then the record should be
flagged either ERROR or WARN with the corresponding Error/Warning code.

The Master list of Error’s and Warning codes and its corresponding descriptions should
be maintained in the system. This master list should also have a flag which says whether
that particular validations should be performed or not for a specific client. During
validation process the code should check for this field and accordingly perform or not
perform the validation.
STD_VAL_BR2
Also the validation type i.e., Error and Warning should be configurable for each client and
claim source.

We will use ticket process to update the table. But we have to build an audit trail table
which will track whenever we make changes to the error or warning is changed
 The Error record counts should be aggregated and compared with threshold limit. If it
exceeds the threshold limit then the Standardization process should ABORT and inform
the operations for investigation.
STD_VAL_BR3
Similarly, the Warning record counts should be aggregated and compared with threshold
limit. If it exceeds the threshold limit then the Standardization process should ABORT and
inform the operations for investigation.

The threshold limits for Errors and Warnings for each Client/Claim Source should be
STD_VAL_BR4
maintained in the System.

When a validation fails on any field in the record then no further validations should be
STD_VAL_BR5 performed on that record. All the validation should be performed in the order of priority
See validation rules STD_VAL_BR6 to STD_VAL_BR35

All the validations conditions should be configurable and ETL code should not have any
hardcoding of the data. All the data comparisons like the Min Max values, Date Range,
Allowed value lists etc., should be driven by the table and configurable.

E.g., zip code can be 5 or 9 or 10 digits in length. So these valid length i.e 5, 9, 10 should
STD_VAL_BR6
be stored the table rather than hardcoded.

Similarly we are checking if either of the 4 DX codes are present or not but in future we
may want to check 8 DX codes. So number of DX codes that we are checking should be
configurable.

All the validations should allow client specific exceptions and should be configurable and
driven by the tables.

Eg: Patient DOB should be valid date but it can be blank if the Client ID is 345.
STD_VAL_BR7
Here we have exception for Client 345.

So all the validations should be designed to allow exceptions for clients <Whether we
currently have exception or not>

STD_VAL_BR8 SSN Validations <Source Field Name and Field Position (start/end position if fixed
 length)>: Position 9 of Eligibility, Length 25

Order of Priority: 1
Type: Error
Code#:
Code Description: Invalid SSN
Validation Rule(s):
1) Should not have all 0’s <000000000>
2) Should not have all 9’s <999999999>
3) Should not have the values <078051120, 219099999>
https://www.ssa.gov/history/ssn/misused.html
4) First three digits of SSN’s should not have 000’s, 666’s or in 900 series
5) The 4th and 5th digit should not be as 00
6) The last 4 digit should not be as 0000
https://secure.ssa.gov/poms.nsf/lnx/0110201035

EIM CO Number<Source Field Name and Field Position (start/end position if fixed
length)>: : Pos 80 of Claims, Length 2

Order of Priority: 2
Type: Error
Code#:
Code Description: Invalid Claim Office
Validation Rule(s):
1) The value of EIM CO Number should not be 0
2) The length should be greater than 0
STD_VAL_BR9
3) It should be a valid number

If Claim Office Number is blank, set Reimbursement Location to “002”

Claim Office Conversion:

Claim Office is set based on the Client’s Claim Office field… this is saved in the COB
tpl extract field
TPL-RPT-LOC.

Claim office TPL-RPT-LOC value

1 001
 1 002

2 CO

3 MO

4 KS

5 WY

6 SA

1 FI

10 NE

1 FP

1 SP

If an unknown value is encountered the morph will abort with the following message:
ABORT! Invalid Claim office encountered for Great West Facets.
Invalid Claim office value: %s (where %s is the value of claim office)

Client Group <Source Field Name and Field Position (start/end position if fixed
length)>:: Pos 54 of Claims, length 8

Order of Priority: 3
Type: Error
STD_VAL_BR10
Code#:
Code Description: Invalid Policy Number (pol_num)
Validation Rule(s):
The client group cannot be blank. i.e length of Client group number should greater than 0

Client Sub Group <Source Field Name and Field Position (start/end position if fixed
length)>:: Pos 80 of Claims, length 3

Order of Priority: 4
STD_VAL_BR11 Type: Error

Code#:
Code Description: Invalid Policy Number1 (pol_num1)
Validation Rule(s):
 Client Funding <Source Field Name and Field Position (start/end position if fixed
length)>:: Pos 83 of Claims, length 4

Order of Priority: 5
Type: Error
Code#:
Code Description: Invalid Funding
Validation Rule(s):
Valid Funding codes

Client Funding Code Description

Blank ASO ADMIN SERVICES ONLY

0001 FI FULLY INSURED

0004 FI FULLY INSURED

0008 FI FULLY INSURED

0006 ASO ADMIN SERVICES ONLY

STD_VAL_BR12
0015 ASOMT MONTHLY AGG ACCT
TERMS

0016 ASOSF MONTHLY AFF ACCT

TERM SF

0019 ASOG1 GRADED PRE

25/50/100/125

0022 ASOS2 MONTHLY AFF LEVEL

SURP

The funding is set to ‘FI’ or ‘ASO’ depending on the funding code.

If code is not found in the above list then abort the application with the following
message.

ABORT! Invalid client funding code encountered for Great West Facets!
Invalid funding code value: xxxx xxxx is the funding code value
 Client Group Name<Source Field Name and Field Position (start/end position if
fixed length)>:: Pos 302 of Eligibility, length 50

Order of Priority: 6
Type: Error
STD_VAL_BR13
Code#:
Code Description: Invalid Name
Validation Rule(s):

If the name is empty set to “Unknown – Current Date”.

EIM First Name<Source Field Name and Field Position (start/end position if fixed
length)>:: Position 50 of Eligibility, Length 15
Order of Priority: 7
Type: Error
Code#:
STD_VAL_BR14
Code Description: Invalid EIM First Name.
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD
The first name cannot be blank.
Set name to lowercase Example JANE  Jane
EIM Last Name<Source Field Name and Field Position (start/end position if fixed
length)>:: Position 66 of Eligibility, Length 35
Order of Priority: 8
Type: Error
Code#:
STD_VAL_BR15
Code Description: Invalid EIM Last Name.
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD
The first name cannot be blank.
Set name to lowercase Example JANE  Jane

EIM Sex<Source Field Name and Field Position (start/end position if fixed length)>:
Position 101 of Eligibility, Length 1 (Values provided ‘M’, ‘F’)
STD_VAL_BR16
Order of Priority: 9
Type: Warning
 Code#:
Code Description: Invalid EIM Sex
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD
1) If the client does not supply the EIM Sex then the field can be blank
Else if client supplies the EIM sex then it can only be “M” or ”F” or ”U”
EIM Date of Birth: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 102 of Eligibility, Length 8
Order of Priority:10
Type: Error
STD_VAL_BR17 Code#:
Code Description: Invalid EIM DOB
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD

EIM Address<Source Field Name and Field Position (start/end position if fixed
length)>: Position 110 + 150 of Eligibility, Length 40

Order of Priority:11
Type: Warning
Code#:
STD_VAL_BR18
Code Description: Invalid EIM Address

Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD

1) The length of the EIM address should be greater than 2.

2) Set to lowercase Example 908 CLINTON AVE  908 Clinton Ave

EIM City<Source Field Name and Field Position (start/end position if fixed length)>:
Position 190 of Eligibility, Length 19

Order of Priority:12
Type: Warning
STD_VAL_BR19
Code#:
 Code Description: Invalid City
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD
Set to lowercase Example BATAVIA  Batavia

EIM State: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 209 of Eligibility, Length 2

Order of Priority:13
Type: Warning
STD_VAL_BR20
Code#:
Code Description: Invalid State
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD
The length of the EIM State should be greater than 1 or the EIM State can be blank

EIM Zip Code: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 211 of Eligibility, Length 10

Cancatonate first 5 characters with a – followed by last 4 characters

Example 55555, 4444 would be 55555-4444

Order of Priority:14
STD_VAL_BR21 Type: Warning

Code#:
Code Description: Invalid Zip Code
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD
The EIM Zip code can be either “5” or “9” or “10” digits

Eim Home Phone: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 222 of Eligibility, Length 20

Order of Priority: 15
Type: Error
STD_VAL_BR22
Code#:
Code Description: Invalid Eim Home Phone
Validation Rule(s):
 THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD

Format should be set to (111)-111-1111

Eim Work Phone: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 242 of Eligibility, Length 24
Order of Priority: 16
Type: Error
STD_VAL_BR23 Code#:
Code Description: Invalid Eim Work Phone
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD

Format should be set to (111)-111-1111 With any remaining values at the end.

Relationship Code: <Source Field Name and Field Position (start/end position if
fixed length)>: Position 39 of Eligibility, Length 2
Order of Priority: 17
Type: Error
STD_VAL_BR24 Code#:
Code Description: Invalid Relationship Code
Validation Rule(s):
Patient Relationship Conversion:

ACSRS Relationship
TPL-CL-REL-CODE
Code
SB (Subscriber) 0
SP (Spouse) 1
SS (Surviving Spouse) 1
Otherwise 2
Patient First Name: <Source Field Name and Field Position (start/end position if
fixed length)>: Position 15 of Eligibility, Length 50
Order of Priority: 18
STD_VAL_BR25
Type: Error
Code#:
Code Description: Invalid Patient First Name
 Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE PATIENT RECORD
The first name cannot be blank.
Set name to lowercase Example JANE  Jane

Patient Last Name: <Source Field Name and Field Position (start/end position if
fixed length)>: Position 66 of Eligibility, Length 35

Order of Priority:19
Type: Error
Code#:
STD_VAL_BR25 Code Description: Invalid Patient Last Name

Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE PATIENT RECORD
The last name cannot be blank.
Set name to lowercase Example JANE  Jane

Patient SEX: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 101 of Eligibility, Length 1 (Format ‘M’, ‘F’)

Order of Priority: 20
Type: Warning
Code#:
STD_VAL_BR25
Code Description: Invalid Patient Sex
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE PATIENT RECORD
1) The Sex may be blank if the Client ID 590

For all others, EIM sex should be either “M” or ”F” or ”U”

Patient Date of Birth: <Source Field Name and Field Position (start/end position if
fixed length)>: Position 102 of Eligibility, Length 8

Order of Priority:21
STD_VAL_BR26
Type: Error
Code#: Code Description: Invalid Patient DOB
Validation Rule(s):
 Dependent Suffix: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 34 of Eligibility, Length 5

Order of Priority: 22
Type: Error
STD_VAL_BR27 Code#:
Code Description: Invalid Dependent suffix
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE PATIENT RECORD

Patient Discharge Status: <Source Field Name and Field Position (start/end
position if fixed length)>: Position 183 of Claims, Length 2

Order of Priority: 23
Type: Error
STD_VAL_BR28
Code#:
Code Description: Invalid Discharge Status
Validation Rule(s):

Claim Number: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 1 of Claims, Length 12

Order of Priority:24
Type: Error
STD_VAL_BR29
Code#:
Code Description: Invalid Claim Number
Validation Rule(s):
The length of the Claim number should be greater than 0 digits

Accident Date <Source Field Name and Field Position (start/end position if fixed
length)>: Position 108 of Claims, Length 8
STD_VAL_BR30
Order of Priority:25
Type: Error
 Code#:
Code Description: Invalid Accident Date
Validation Rule(s):

The Accident date can either be blank or it should be a valid date

Check Date: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 89 of Claims, Length 8

Order of Priority:26
Type: Error
STD_VAL_BR31
Code#:
Code Description: Invalid Check Date
Validation Rule(s):

The Check Date can either be blank or it should be a valid date

First Date of Service: <Source Field Name and Field Position (start/end position if
fixed length)>: Position 185 of Claims, Length 8

Order of Priority: 27
Type: Error
STD_VAL_BR32
Code#:
Code Description: Invalid First Date of Service
Validation Rule(s):
The First Date of Service should be a valid date

Last Date of Service: <Source Field Name and Field Position (start/end position if
fixed length)>: Position 193 of Claims, Length 8

Order of Priority: 28
Type: Error
STD_VAL_BR33
Code#:
Code Description: Invalid Last Date of Service
Validation Rule(s):
The Last Date of Service should be a valid date
Provider Name: <Source Field Name and Field Position (start/end position if fixed
STD_VAL_BR34
length)>: Position 32 of Provider, Length 55
 Order of Priority: 29
Type: Warning
Code#:
Code Description: Invalid Provider Name
Validation Rule(s):
The Provider Name can be blank only if the Claim System is “POWERSTEPP” & Client ID
is “784”. For all others the Provider Tax ID should be present. >length should be greater
than 1.>

Set name to lowercase Example JANE  Jane

Provider Tax ID: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 13 of Claim, Length 9
Order of Priority: 30
Type: Warning
Code#:
STD_VAL_BR35
Code Description: Invalid Provider Id

Validation Rule(s):
The Provider Tax ID can be blank only if the Client ID is “109”. For all other clients the
Provider Tax ID should be present. (Length should be greater than 0.)

Claim Charge Amount: <Source Field Name and Field Position (start/end position if
fixed length)>: Position 219 of Claim, Length 19

Order of priority: 31
Type: Error
STD_VAL_BR36
Code#:
Code Description: Invalid Charge Amount
Validation Rule(s):
The claim charge amount should be a valid number.

Claim Benefit Amount: <Source Field Name and Field Position (start/end position if
fixed length)>: Position 314 of Claim, Length 19

STD_VAL_BR37 Order of priority: 32

Type: Error
Code#:
 Code Description: Invalid Benefit Amount
Validation Rule(s):
The claim benefit amount should be a valid number.
Diagnosis Code1: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 116 of Claim, Length 10
Order of Priority: 33
Type: Error
STD_VAL_BR38
Code#:
Code Description: Invalid Primary Diagnosis code
Validation Rule(s):
At least one diagnosis code is present <out of 4 diagnosis codes>

Diagnosis Code2: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 126 of Claim, Length 10

Order of Priority: 34
Type: Error
STD_VAL_BR39
Code#:
Code Description: Invalid Diagnosis code2
Validation Rule(s):

At least one diagnosis code is present <out of 4 diagnosis codes>

Diagnosis Code3: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 136 of Claim, Length 10

Order of Priority: 35
Type: Error
STD_VAL_BR40
Code#:
Code Description: Invalid Diagnosis code 3
Validation Rule(s):

At least one diagnosis code is present <out of 4 diagnosis codes>

Diagnosis Code4: <Source Field Name and Field Position (start/end position if fixed

STD_VAL_BR41 length)>: Position 146 of Claim, Length 10

Order of Priority: 36
 Type: Error
Code#:
Code Description: Invalid Diagnosis code 4
Validation Rule(s):

At least one diagnosis code is present <out of 4 diagnosis codes>

TOS Type: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 203 of Claim, Length 4

Order of Priority: 37
Type: Warning
STD_VAL_BR42
Code#:
Code Description: Invalid TOS Type

Validation Rule(s):

Procedure Code: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 208 of Claim, Length 7

Order of Priority: 38
Type: Error
STD_VAL_BR43
Code#:
Code Description: Invalid Procedure Code
Validation Rule(s):

Cause Code: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 107 of Claim, Length 1

Order of Priority: 39
Type: Error
STD_VAL_BR44
Code#:
Code Description: Invalid Cause Code
Validation Rule(s):
 Payee Code: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 371 of Claim, Length 1

Order of Priority: 40
Type: Error
Code#:
Code Description: Invalid Payee Code
STD_VAL_BR45 Validation Rule(s):

Place of Service: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 201 of Claim, Length 2

Order of Priority: 41
Type: Error
STD_VAL_BR46
Code#:
Code Description: Invalid Place of Service
Validation Rule(s):

Client Remarks: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 74 of Claim, Length 4

Order of Priority: 42
Type: Error
Code#:
Code Description: Invalid Client Remarks
STD_VAL_BR47 Validation Rule(s):

Linie Checknumber: <Source Field Name and Field Position (start/end position if
fixed length)>: Position 97 of Claim, Length 10

STD_VAL_BR48 Order of Priority: 43

Type: Error
Code#:
 Code Description: Invalid Line Checknumber
Validation Rule(s):

Alternate Subscriber Number: <Source Field Name and Field Position (start/end
position if fixed length)>: Position 3 of Crosswalk, Length 25 (Not sure if this is used
anymore)

Order of Priority: 44
Type: Error
Code#:
Code Description: Invalid Line Checknumber
STD_VAL_BR49 Validation Rule(s):

Alternate ID Number:

The Great West Member Crosswalk file will be accessed to retrieve the Legacy Id
number for the member. This will be used to set the Alternate ID Number. The
Employee ID (Eligibility, field 2) is matched with the Facets Primary PTC ID on the
Crosswalk file where the Relationship to Insured CD is “EE” or “RR”. If a match is
found, the Alternate ID Number will be set to the Primary PTCPN ID on the Crosswalk
file.

Eim Suffix: <Source Field Name and Field Position (start/end position if fixed
length)>: Position 34 of Eligibility, Length 5

Order of Priority: 45
Type: Error
STD_VAL_BR50 Code#:
Code Description: Invalid eim suffix
Validation Rule(s):
THIS INFORMATION NEEDS TO BE FROM THE SUBSCRIBER RECORD

ICD Version Indicator: <Source Field Name and Field Position (start/end position if

STD_VAL_BR51 fixed length)>: Position 1062 of Claim, Length 1

Order of Priority: 46
 Type: Warning
Code#:
Code Description: Invalid ICD Version Indicator

Validation Rule(s):
0  ICD10

9  ICD9

POL ROR: <Source Field Name and Field Position (start/end position if fixed
length)>: Defaulted to Y, Not provided in file.

Order of Priority: 47
Type: Error
STD_VAL_BR52
Code#:
Code Description: Invalid Pol ROR
Validation Rule(s):
It can only have a value either “Y” or “N”

Metrics:

The system should capture the below metrics

a) Start & End Timestamp of Data Validation process
b) Source System
c) Client ID /Client Name
d) Consignment ID
e) No. of records validated
f) Total no. of records in source file
STD_VAL_BR39 g) Total No. of Error validations performed
h) Total No. of Warning validations performed
i) List of all Error validations performed
j) List of all warning validations performed
k) Total number of validation failures per each Error validation performed
l) Total number of validation failures per each warning validation performed
m) Percentage of Errors
n) Percentage of Warnings
o) Overall Validation Status <Abort, Success>
 An automated email/notification should be sent to Support team with the details <Client
ID, Client Name, Start time> when the validation process starts

An Automated email/notification should to Support team with the details. <Client ID, Client
Name, Start time, End Time, Total number of Records in Source file, Number of records
validated, Number of Errors/Warnings, Validation status(Success/Aborted)> when the
validation process completes

REQUIREMENTS: STANDARDIZATION – DIAGNOSIS CODES BYPASS Commented [SS4]: Sai to review for each client.

Business
Business Rule – Details and Acceptance Criteria
Rule #
DX Code Formatting:

Format the Diagnosis codes sent in the EDI source files.

Some client’s ICD codes may be missing the DOT in it. These codes should be formatted
before the system accepts them.
STD_DX_BR1

E.g., the source files ICD10 diagnosis code “S73101A” should be converted “S73.101A”
Similarly ICD9 code “8439” should be converted to “843.9”

Note: If the source file is already formatted then we can skip this BR.

DX Code Master List Maintenance:

The master list of ICD9 & ICD10 diagnosis codes with the corresponding short and long
descriptions and classification types as mentioned in STD_DX_BR3 should be maintained in
the system. Admin or any user with special privileges should be able to maintain <Update,
Add and Delete> this list.
STD_DX_BR2

The ICD maintenance interface should have provision to lookup codes and update its
attributes. And also be able to do bulk update by uploading an Excel or csv file.
Note: Excel/csv file should be in a predefined format to perform bulk upload.

Note: Every year ICD codes are updated to accommodate new diseases discovered & new
 medical procedures etc.

Business needs to review master DX codes and also all Unknown DX Codes should be fixed
before we roll out with new system.

DX Code Classification:

Compare all the diagnosis codes within each validated record in the source EDI file and
classify each DX code into an Investigation Status of:
1 Do Not Investigate,
2 Possibly Investigate,
3 Definitely Investigate, OR
4 Unknown Diagnosis Code / <Not Classified>
STD_DX_BR3

Note: To classify we have to look up the diagnosis code with the master list of codes as
mentioned in STD_DX_BR2

If the record is classified as “Do Not Investigate” then that record is candidate for Bypass. If
the Record is classified as “Possibly Investigate” or “Definitely Investigate” or “Unknown
Diagnosis Code” then those record should be converted to Standard Record Layout.

DX Codes Exception classification:

The system should allow exceptions in DX code classifications for some clients.
E.g., a particular DX code for a client may be classified as Do Not Investigate but the same
STD_DX_BR4
DX code for a different client can be classified as Possibly Investigate/ Investigate.

System should be designed to allow such classification of exceptions.

Unknown DX Codes Reporting to Business:

The system should periodically create a report of all unknown DX codes that various clients
transmitted and send this report to business team so that these unknown codes are fixed in
STD_DX_BR5 the master DX table.

*Note:
The frequency of sending this report should be configurable.
 DX Code Metrics / KPIs:

The system should capture the

a) Start & End Timestamp of DX Bypass process
b) Source System
c) Client ID /Client Name
d) Consignment ID
e) No. of records Processed
f) Total no. of records in source file
STD_DX_BR6 g) No. of records Bypassed
h) Number of records in each DX code classification i.e Do Not investigate, Possible
Investigate, Definitely Investigate, Unknown Diagnosis Code
i) Total Charges in each DX code classification i.e Do Not investigate, Possible
Investigate, Definitely Investigate, Unknown Diagnosis Code
j) Benefits in each DX code classification i.e Do Not investigate, Possible Investigate,
Definitely Investigate, Unknown Diagnosis Code
k) Each Diagnosis code aggregated to measure the number of records, total charges
& total benefits

Generate Email Notification:

An automated email/notification should be sent to Support team with the details <Client ID,
Client Name, Start time> when the DX Code rules process starts
STD_DX_BR7
An automated email/notification should sent to Support team with the details. <Client ID,
Client Name, Start time, End Time, Total number of Records in Source file, count of records
in each classification> when the validation process completes

REQUIREMENTS: STANDARDIZATION – FORMATTING RULES Commented [SS5]: Natasha and John to work on for
each client.

Business Business Rule – Details and Acceptance Criteria

Rule #
 Below are the list of common formatting and conversion rules that apply
Type Rule
Date Format MM/DD/CCYY
10 characters,
CC = Century, YY = Year, MM = Month, DD = Day
STD_FMT_BR1 Currency Format (-)9999999999.99
(sign)10(char).2(char) = 12 characters
Has a prefix of a ‘‘-‘, indicating a negative amount.
Positive amount do not have a sign
Text Format ASCII format.
Title Set to “M.”

Format Subscriber Address, Subscriber Name, Patient Name & Provider Name into correct
STD_FMT_BR2 title case, i.e. Upper/Lowercase

Example: if TIMOTHY or timothy or TimOthy, then format should be Timothy.

Policy Name when not supplied or is blank or Null should be defaulted to “New Unknown
STD_FMT_BR3 Account – MM/DD/YYYY” where MM/DD/YYYY is current date. Also the Policies ROR
(Right for Recovery flag) is defaulted to “Y”

Claim records that are negative adjustments i.e. Benefit Amount < 0 will have a Claim
STD_FMT_BR4
Status set to 2 otherwise it is 1.

Set the Diagnosis Code types as per below table

Code Type Condition
3 All ICD9 Numeric codes. Numeric codes classify diseases, injuries, poisonings and a wide variety of
signs and symptoms
4 ICD9 codes starting with “V”. This code group is supplementary classifications of factors influencing
STD_FMT_BR5 health status and contact with health services. Example “V01 - Contact or Exposure to communicable
diseases”
5 ICD9 codes starting with “E”. E codes describe the external causes of injuries and poisoning
205 ICD10 codes that start with V, Q, X and Y. These ICD10 codes describes causes of injuries.
203 All other ICD10 codes

CLIENT: GREAT WEST FACETS (CLIENT #712) Commented [SS6]: Natasha/John to update for each
client

Client # Format Length Schedule Size Current Processing Time

712 ASCII 946 Weekly 1000-1200MB ?? Commented [SS7]: Natasha/John to Update for each
The Great West data comes in the ASCII format. Great West has converted to the FACETS system. These client
specifications are for the data coming from the new FACETS system. We will continue to receive data from the
old claims system as run out is being done on the old claim system… so for a while we will be receiving Great
West Denver and Great West St. Louis feeds from the old claim system as well as the new claim system
(FACETS).

Claims File:
Record Length: 355

Eligibility File:
Record Length: 282

Employer File:
Record Length: 198

Provider File:
Record Length: 222

Member Crosswalk File:

Record Length: delimited using “,”

There is a trailer record on every file that begins “ZZZZZZZZ”. ACSRS will bypass trailer records

The source file is converted to multiple Standard record files as a part of Standardization and consumed
thereafter during Load, Merge etc.

REQUIREMENTS: IDENTIFYING CLIENT SPECIFIC DATA FROM CONSIGNMENT

<SECTION TO DOCUMENT BASED ON THE GROUP NUMBERS, CLAIM OFFICE, AND ADDITIONAL
CLIENT DATA ATTRIBUTES, WHAT CLIENT ID’S WE MAP THE DATA TO.>

EDI FILE LAYOUT

EDI Source Layout & Standard Record Mapping
REQUIREMENTS: STANDARDIZATION – BYPASS RULES FOR CLIENT 860 Commented [SS8]: Natasha/John to fill up this section
with client Specific ByPass rules

Business
Business Rule – Details and Acceptance Criteria
Rule #
As a part of Bypass rules validation, system should perform checks as listed in <
STD_ByPass_BR3 to STD_ByPass_BR6> and when any specific record satisfies the
STD_ByPass_BR1
check then the record should be flagged as bypassed and the corresponding bypass
code should be set for that record

Bypass Master List:

The Master list of all the bypass codes and its corresponding descriptions should be
maintained in the system. This master list should also have a flag which says whether
STD_ByPass_BR2
that particular bypass should be performed or not for a specific client. During bypass
process the code should check for this field and accordingly perform or not perform
the bypass.

All the Bypass conditions should be configurable and ETL code should not have any
hardcoding of the data. All the data comparisons should be driven by the table.
E.g., in STD_ByPass_BR4 Sullivan & Cromwell LLP bypass, the SSNs to be
STD_ByPass_BR3
bypassed should be maintained in the table and also the account number and
Subscriber names should be maintained in the table so it is easy to configure in the
future

** Bypass claim records where Funding Indicator (Claims, field 11) is blank
STD_ByPass_BR4
Note:

** Bypass claim records if any of the Diagnosis Codes (Claims, fields 17, 18, 19
or 20)
are equal to:
STD_ByPass_BR5 367.0 367.22 367.4 367.53
367.1 367.3 367.5 367.8
367.2 367.31 367.51 367.81
367.21 367.32 367.52 367.89

** Bypass claim records where the first position of Plan Id Number (Claims, field
STD_ByPass_BR6
7)
is equal to “D” (dental claims)
STD_ByPass_BR7 N/A

STD_ByPass_BR8 N/A

STD_ByPass_BR9 N/A

Check Date:

STD_ByPass_BR10 If the Check Date <PIDATE> has a value 00/00/0000 or is blank then that record

should be skipped.

Metrics:

The system should capture the

a) Start & End Timestamp of Client Bypass process
b) Source System
c) Client ID /Client Name
d) Consignment ID
e) No. of records Processed
f) Total no. of records in source file
g) No. of records Bypassed
STD_ByPass_BR11 h) Number of records Bypassed for each Bypass rule
i) Total Charges for each bypass rule
j) Benefits for each bypass rule

An automated email/notification should be sent to Support team with the details

<Client ID, Client Name, Start time> when the Bypass rules process starts

An automated email/notification should sent to Support team with the details. <Client
ID, Client Name, Start time, End Time, Total number of Records in Source file, count
of records in each classification> when the validation process completes

REQUIREMENTS: STANDARDIZATION – CONVERSION RULES Commented [SS9]: Natasha/John to Fill up this section
with client Specific Conversion rules

Business
Business Rule – Details and Acceptance Criteria
Rule #
STD_CNV_BR1 Claim Office:
Claim Office Conversion:

Claim Office is set based on the Client’s Claim Office field… this is saved in the COB
tpl extract field
TPL-RPT-LOC.

Claim office TPL-RPT-LOC value

1 001

1 1

1 002

1 2

2 CO

3 MO

4 KS

5 WY

6 SA

1 FI

10 NE

1 FP

1 SP

7 WZ

If an unknown value is encountered the morph will abort with the following message:
ABORT! Invalid Claim office encountered for Great West Facets.
Invalid Claim office value: %s (where %s is the value of claim office)
 Patient Relationship:

Use the below table for Patient Relationship conversion

Client Dta value<RELCOD> ACS Relationship Code

STD_CNV_BR2
SB (SUBSCRIBER) 0
SP (SPOUSE) 1
SS (SURVIVING SPOUSE) 1
Any other value 2

Valid Funding codes

Client Funding Code Description

Blank ASO ADMIN SERVICES ONLY

0001 FI FULLY INSURED

0004 FI FULLY INSURED

0008 FI FULLY INSURED

STD_CNV_BR3 0006 ASO ADMIN SERVICES ONLY

0015 ASOMT MONTHLY AGG ACCT

TERMS

0016 ASOSF MONTHLY AFF ACCT

TERM SF

0019 ASOG1 GRADED PRE

25/50/100/125

0022 ASOS2 MONTHLY AFF LEVEL

SURP

ICD Version:
STD_CNV_BR4
If the first character of the FILLER field is 0 then the client source file uses ICD10 else
if the value is 9 then the client source file uses ICD9 version.
Claim Status Conversion:

If the Benefit Paid amount (TPL-BEN-AMT) is a negative value:

set Claim Status to 2 (Reversal)
STD_CNV_BR5
otherwise
set it to 1 (Claim).
STD_CNV_BR6
STD_CNV_BR7

Capitated Claim & Benefit Paid:

STD_CNV_BR8
If CAPIND =”Y” then this is a Capitated Claim. Set the Benefit Paid Amount to $0.00

Service Code & CPT Code:

STD_CNV_BR9
If the first 5 positions of Service Code <SVCCOD> are digits then it should be treated as
CPT-4 Code type otherwise it is treated as Client’s unique Service Code

Case Reference Policies Table:

Create an entry for new Group Numbers in Policies table and default the ROR as Yes.
STD_CNV_BR10
For an existing Policy if the ROR is set to “N” EDI will not open new cases for this group
but it will accumulate claims in the CHA.

Metrics:

The system should capture the below metrics

a) Start & End Timestamp of Client Bypass process

STD_CNV_BR11 b) Source System

c) Client ID /Client Name
d) Consignment ID
e) No. of records Processed
f) Total no. of records converted for each conversion rule