VENDOR FEED CHECKLIST-SA, DEV & QA

VENDOR FEED CHECKLIST – SA, DEV & QA

Version 1.0

System Documentation – CES- 2008

Cognizant
Technology
Solutions

Cognizant Technology Solutions

 VENDOR FEED CHECKLIST-SA, DEV & QA

Revision History Page

Date Version Description Author

01/07/2008 V1.0 Initial

Cognizant Technology Solutions

 VENDOR FEED CHECKLIST-SA, DEV & QA
Table of Contents

VENDOR FEEDS CHECKLIST FOR SA, DEV AND QA:...............................................................4

CHECKLIST-SA.....................................................................................................................................4
1.BUSINESS SCENARIOS: ............................................................................................................................................4
NEW FEED:..................................................................................................................................................................4
EXISTING FEED:.........................................................................................................................................................5
2.FIELD LEVEL INFORMATION & LAYOUT: ...........................................................................................................6
3.IMPLEMENTATION.....................................................................................................................................................6
Sort & Merge process:..................................................................................................................................................6
FTP process:.................................................................................................................................................................7
CHECKLIST-QA....................................................................................................................................7
Generic checks:.............................................................................................................................................................7
Trans Feeds:.................................................................................................................................................................8
Sort & Merge and FTP process:...................................................................................................................................9
Integration Testing:.......................................................................................................................................................9
CHECKLIST-DEV................................................................................................................................10

Cognizant Technology Solutions 3

 VENDOR FEED CHECKLIST-SA, DEV & QA

VENDOR FEEDS CHECKLIST FOR SA, DEV and QA:

CHECKLIST-SA
1. BUSINESS SCENARIOS:

NEW FEED:
Generic:
1. Is the business reason for the introduction of new vendor feed clearly defined?

2. The selection criteria for a record to be written to the output clearly defined?

3. Are there any issues/queries around setting the data for the selection criteria?
E.g. The feed is valid for all Standard and Non standard Medical coverage
with an IPLAN indicator of 5. But for Non standard Medical Coverage IPLAN
cannot be set other than Spaces. Is there a need to enhance the copybooks,
online & Bridges to handle such scenarios?

4. Does the frequency of the job running in production clearly defined?

5. Does a logical delete (start date =stop date) line qualify to be sent on the report?

6. Does a physically deleted member record need to be sent on the report?

7. Is there a need to send the terminated or physically deleted coverage, benefit sets,
Market sites etc.?

8. Does a terminated/future eligibility line required to be sent on the report? In other words
among past, current and future eligibility lines what all does the vendor require to be
sent on the report?
E.g. Current date is 01/01/2008 and there are three eligibility lines for a
member.
• Line 1: 1st Jan 2007 – 1 Aug 2007
• Line 2: 2nd Aug 2007 – 2nd Oct 2008
• Line 3: 3rd Oct 2008 – Open.
Considering that other criteria are satisfied, what are the lines that need to
be sent on the report?

9. Should the Vendor consider the data which has been sent multiple times in different
days?
E.g.: If a field is set to Y for an employee and sent to the Vendor for the first
time. And if the same field is set to Spaces the next time, should the Vendor consider
the changed data or the earlier one?

10. If the new field is sent in multiple feeds (say Full and transaction feeds), and it has
different values, then which value should be considered.

Cognizant Technology Solutions 4

 VENDOR FEED CHECKLIST-SA, DEV & QA

11. Are the New Production and Test File names identified?

12. Is TEST and PRODUCTION FTP process defined?

For Trans Feeds:

13. Are all of the trigger fields defined?

14. Are the sources of changing the triggering field clearly defined?

15. Is the action code required for the vendor? If so, is the action code defined clearly for
all kind of transactions? Transactions may be either stand alone or combination of Add,
Key field change, logical delete. Are the fields mapped for each of the different action
codes, i.e. Changes to what fields will be sent with what action codes?

16. Is there a need to trigger the entire family to the output for a change to the
EE/Dependents? Is there a need to trigger the EE record to the output for a change in
dependent record?

17. If there is a change in the EE ID, then does the new EE id be considered as a new
record or sent as already existing?

18. When applicable for dependents, have the special scenarios like SS, NB, etc been
considered?

19. Is there separate processing for member level field change, and eligibility level field
change?
E.g.: If there is an eligibility line change, then the lines going forward from that
the changed date need to be sent and if there is a member level change, then all
the eligibility lines should be sent.

EXISTING FEED:

1. Is the business reason for the change to existing vendor feed clearly defined?

2. Is the change applicable for all customers or specific customers only?

3. If a particular feed for a vendor is undergoing a change, then whether the change
impacts all other feeds to that vendor in any way?
E.g.: If the Medco supplemental feed is being changed, we need to have an
action item to research the other Medco feeds (batch and real-time)

4. If a new field is introduced in the Feed, Is the trigger field or not?

5. If new fields are introduced in the Feed, are the valid values identified for the
same? i.e., if the field is in CES and has 3 valid values, are all three values
applicable for the vendor or only few.

Cognizant Technology Solutions 5

 VENDOR FEED CHECKLIST-SA, DEV & QA

2. FIELD LEVEL INFORMATION & LAYOUT:

1. Is the source of information of the fields in the output layout clearly defined?
Is it in any of CES files, or is it in the feed (i.e. is it a derived field). A derived field is a
field whose value is derived based upon certain other parameters depending on the
requirement.

2. Formatting of the fields in the layout:

When the length in CES and report is not the same:

CES Data Length of data Formatting

Length field in report
More Less Truncate Data (leading or Trailing?)
Less More Justify (Left or right?)

3. For the Date fields, format in which the date needs to be sent?
E.g.: CES date may be in Julian format and in the report the required format may be
Gregorian. And if a date is 9’s in CES should it be sent as 9’s or spaces on the report?

4. For Trans Feeds, Are all of the triggering fields, part of the output report? If a particular
trigger field is not the part of the report then what is the reason for a record to be
triggered for the change to that particular field.
E.g. If UCS SEQ No is given as one of the fields that should trigger a
record in the transactional feed it has to be a part of the report. If it is listed in the
triggering fields but not a part of report layout the vendor may not change that
triggered the data.

5. Does the feed have action code in the output layout? In case of Trans Feeds, is it
clearly defined as to what action code needs to be sent in case of a combination of
transaction happening on the same day?
E.g.: It may be required to report a change of last name with action code C and
change of Alt ID/Employee ID, with action code K. If both change for a
member on a single day, what action code will be sent on the report and how the
data records will appear in the report?
In case of Full feeds using same layout as Trans feeds, what is the value of action
code Field?

6. If a new field is added in the feed, then where does the new field reside? Is it in any of
CES files, or is it in the feed (i.e. is it a derived field). A derived field is a field whose
value is derived based upon certain other parameters depending on the requirement.

3. IMPLEMENTATION
Sort & Merge process:
1. What should be the order in which records should be sorted in the report?

Cognizant Technology Solutions 6

 VENDOR FEED CHECKLIST-SA, DEV & QA
E.g. A sort order may be customer no., Employee Id, Eligibility start date,
Eligibility stop date.

2. What is the data that should be populated in the header record and trailer record?

3. Is the cycle date a part of both the header and trailer record or just the header?

4. The record count in the trailer record includes only the data records or it should
include the header and trailer as well?

5. Is there a naming convention to be followed for the merged file? Does this include
date of creation?

6. If the vendor feed track the changes of inforce, extension & PCP using separate
programs, which one is given high priority when duplicates are to be eliminated in the
merge process(For ex in MAHP : structure, inforce, extension and PCP).

7. If the merge process involves the merge of both Trans and Full file, which is to be
given higher priority during duplicate elimination?

FTP process:

8. For FTP, is the required site name, user id and password information provided? Is
there a naming convention required to be followed for the destination file?

CHECKLIST-QA
Generic checks:
1. Whether all possible data (UNET policies, PRIME policies (numeric and
alphanumeric), HMO, Medica, ACIS, GHMO, HPHC, M, RX, V etc., ) combinations
used for testing?

2. Whether M* coverage’s have been used for testing?

3. Use membership data having multiple eligibility lines having different coverage’s.
Ex: Member having 3 eligibility lines i.e., one with M coverage, one with RX and one
with Vision.

4. Whether all possible data sources such as Onlines, foundation views, Group tape,
bridges & E3 have been used for testing?

5. Does the scenario involving logically deleted members, physically deleted members,
coverage, benefit set, market site etc are tested?

6. Does the scenario involving terminated members, coverage, benefit set, Market site
etc are tested?

7. Are all the negative scenarios related to the selection criteria tested?

Cognizant Technology Solutions 7

 VENDOR FEED CHECKLIST-SA, DEV & QA
E.g.: If only medical record will be processed by the vendor, check that the
members with Pharmacy, vision coverage etc. without medical are not processed.
Also verify the members with both medical and other coverage are being to the
output with medical eligibility lines only.

8. Are the production customer, plan and membership details used for testing rather than
the mocked up the data in the test region? Does production journal files used for
testing the regression conditions? Is Production data used as far as possible rather
than preparing data in test region?

9. Is there any special processing required for Prime members? Will there be any
differences in the fields in report for Prime members? For Example, if group number
field is present in the output, then for Prime members alone this value will be retrieved
from segmentation file in most cases.

10. If the fields to be tested are at occurrence level in Inforce or PCP etc, does the
scenario wherein members having multiple occurrences (with difference values/data in
occurrences) is tested? Also whether the member with maximum occurrences is
tested as well?

11. If the eligibility lines are sent in a feed, whether the eligibility lines having past current
and future timelines are tested?

12. Are all of the fields in the output file are populated with appropriate values in
appropriate format? This verification should include all the existing fields also.

13. Are the date fields populated correctly in the output (date format in CES and output file
may be different)?

14. Is verification done properly for each member in output files?

Ex: If a scenario is tested for employee. Apart from verifying employee data, is
verification done for the corresponding dependent data. I.e. either dependent should
not be written/dependent should be written with out any changes or with proper data.

15. Does the output of the program, run with new load is compared with that of the
production code?

16. When there is a change to a particular type of feed (say transactional feed), then
whether all the other feeds for the vendor regression tested?

17. Verification of Information displayed on the spool:

i) Are the messages meaningful and counters having the right number of digits?
ii) Are there any impertinent messages being displayed in the spool?
iii) Do the counters displayed in the spool match the number of records produced
in the report under each transaction?

Trans Feeds:
1. Is proper date and timestamp used in the Endseg file?

2. Does the test JCL also include the source program which creates the journal input for
the main vendor feed program (in most cases it’s LJS & LJT)?

Cognizant Technology Solutions 8

 VENDOR FEED CHECKLIST-SA, DEV & QA

3. Data Combinations at Employee level:

New fields introduced in vendor Feed: -

a. All valid values should be used while testing.

b. Employee with valid value for new field and dependents with a BLANK in new
field and vice versa.
c. Change the new field for the EE alone, Dependent alone and the family

4. Whether the entire list of trigger and non-trigger fields is known and the program
tested for both scenarios? For new feed, whether the program is tested for all trigger
fields and non-trigger fields?

5. Are the Multiple change scenarios tested? For eg: Family with 4 members, make key
field changes only to one member, multiple members at the same time etc. Different
combinations of changes in the family should be tested.

6. Are the multiple changes on the SAME DAY scenarios tested? This includes different
type of changes.
E.g.: Key field change and Non key field change, Demographic data change and
Eligibility data change, Structure change and Inforce change on the SAME day.
Whether all different combinations are tested?

7. If the vendor has Action code then whether the action code is verified for all kind of
transactions? Transactions may be either stand alone or combination of Add, Change,
Key field change or logical delete?

Sort & Merge and FTP process:

1. Is merge JCL tested for Vendor Feeds?

2. If the vendor feed track the changes of inforce, extension & PCP using separate
programs, does the scenario wherein changes to all the key fields all four on the same
day tested? Whether the latest record is always picked up and duplicates are
removed?

3. Are the fields in the header and trailer records are according to the layout?

4. Is the date and count of the record in the header/ trailer are correct?

Integration Testing:
1. Does the scenario list for the Integration testing received from feed system? Whether
these scenarios are sent in multiple cycles and the data provided are according to
these scenarios?

2. Is the verification of the Integration files done at the feed side? Whether the sign off
mail is received for each of the file verification done at their side. (Its better to send
some few records daily in 1 file and feed system verifies signs off the files. This way,
we can ensure that thorough verification is done at both the ends).

3. Is the data used for System testing and integration testing different?

Cognizant Technology Solutions 9

 VENDOR FEED CHECKLIST-SA, DEV & QA

4. Is the FTP process tested? It is mandatory to FTP the files to the Feed system as in
production instead of sending the integration files in a notepad. This to be followed for
upstream files as well.

CHECKLIST-DEV

Cognizant Technology Solutions 10