December 3, 2002
Group Insurance Resource Team (GIRT),
Here are some more Questions with Answers. I have tried to include all
questions received through November 26. If you sent your question before
December 1 and don't see your question or if you don't understand an answer
to any question (whether it was yours or not), please let me know. Please
note, the layout is changing slightly due to some of the questions we've
sent to and answers we've received from FlexBen. A new layout is attached
and updated on the EGI/IS sight.
The EGI managers and FlexBen seem receptive to pushing the deadline to
February 1, however, I'd still like testing to begin as soon as possible.
Header Record
H1) Q) Can we report the employees from UT Austin and UT System
Administration under the one State Agency Code "721"?
A) My preference is to
have the component code 720 on the detail records for UTSADMIN employees,
but I don't see any problem with them being on the same dataset and using
the UTAUS state agency code (721) on the header. For that matter, if you
want to send all of the components on the same dataset that would be fine
also. In EGI's system we use the term "Processing Agency" to denote when
one component sends data for another component. In order to be considered a
"Processing Agency" EGI will need to denote such in its system. If you are
currently a "Processing Agency" for either eligibility or premium billing,
then no new designation is needed.
H2) Q) Payroll Date - What do you mean by this? what we call payroll date
is the last day of the pay-period (ie. always the 15th or the end of the
month), is that what you mean? if so, we'll have 2 different payrolls, the
2nd semi-monthly (which pays for the 16th through the end of the month) and
the monthly which will both have the same payroll date ... is this ok? If
you need a unique date, we could either use run date (ie. transmission date)
or check-date (ie. the date the payroll is payable).
A) The end of the pay
period such that two payrolls end on the same date is fine since there is a
code for pay frequency on the detail records. If the dataset contains data
from two payroll dates with two different payroll dates, use the last
payroll date on the header field.
H3) Q) Implementation Date - Can the deadline be moved to February 1, 2003?
A) FlexBen has agreed to move the required implementation date to February
1, 2003, however, we still want to begin testing in December 2002. This
means the first production files are expected with February deductions.
Detail Record
D1) Q) Dir Deposit fields - We don't currently store this data
electronically nor do we remit it as part of the payroll processing ... ok
to skip these and keep processing it as we do now?
A) Agreed. To my
knowledge there has been no discussion between FlexBen and UT regarding UT
tracking direct deposit info. I left these fields for future consideration
since FlexBen had them on their layout.
D2) Q) Employment Status - This will always be "active" for us because we
won't be collecting Flex deductions from leave or terminated employees, ok?
A) My understanding is that some components take credits after termination.
If so, then the "T" code should be used. When I inquired to FlexBen about
the three byte length of this field (while only asking for one byte values
on the dataset), the response was that this field is "flexible" and that we
could setup our own values for active, termination, and leave. Since one
byte seems adequate for our purpose, I have modified the layout to reflect
this as a one byte field (see layout).
D3) Q) Date of Hire - We currently fill this with the flex begin date
(usually 9/1 of the current FY), ok? A) I'm not sure why Date of Hire would
be a problem for the campuses to provide and think it will be more valuable
than 9/1. Please use date of hire (continuous employment).
D4) Q) Eligibility Date - We currently fill this with the flex begin date
(usually 9/1 of the current FY), ok? A) I'm okay with 9/1 as the eligibility
date so long as that is the first date of the fiscal year for that
subscriber to participate. If it is a new hire that starts after September
1, then the date should reflect the employment date. It is okay to also
leave this date the same as the Date of Hire so long as the employee has
been continuously eligible to participate in the Flex plan.
D5) Q) Date of Termination - Since we'll only be reporting for active
employees, this should always be blank; we currently fill it with zeros for
FlexBen ... how do you want us to represent a blank date? A) Again, if you
are requesting a credit due to termination, then the termination date should
be used. My preference for a blank date is all blanks, however, since
several campuses use all zeros, I usually also code for all zeros.
D6) Q) Pay Frequency - We use "M" (monthly) for everyone for current
reporting; do you want us to use "S" (semi-monthly)? A) Please use "M" only
for those monthly paid employees. "M" should have been included in the list
of valid values. Please use the appropriate corresponding code for
B(iweekly), W(eekly), and S(emi-Monthly), and M(onthly). Regardless of the
Pay Frequency, if the deduction is to only occur monthly, then the frequency
should also be M(onthly). The Pay Frequency should really reflect the
frequency of deductions, not the frequency of pay checks.
D7) Q) Pay Cycle Code - Ok, I'm baffled by this one ... 15 bytes ... what is
this for and what are our options? A) When I inquired of FlexBen about the
use of this field I was again told it is a "flexible" field and they
suggested we use it for number of deductions expected. Therefore, my
preference for values is to use it that way as a two byte field and in
concert with the Pay Frequency field. If the employee has a Pay Frequency
of "M"(monthly) then our most common values will be "09" and "12". If they
are paid monthly but new employees, then the number of months may be
something other than "09" or "12". If they are paid weekly, and there will
be a weekly deduction, then this Pay Cycle Code should reflect the number of
weeks during the plan year that deductions will be made. The dataset layout
has been modified to reflect this is now only a two byte field.
D8) Q) FSC fields - Again, this is data we don't currently track ... can you
derive it from the eligibility data we already send you? A) Again, the
response from FlexBen is that this field is not required and "flexible". I
looked into the HIPAA 834 "Maintenance Code", which corresponds most
directly to family status change codes, and they only use a two byte field.
While we will not be requiring this field this year (and maybe never) I do
want to preserve the two bytes for possible future use. The dataset layout
has been modified to show the change of the "FSC Code" field to two bytes.
D9) Q) Dep Care fields - Based on a video conference comment, I (JSC) recall
that we agreed to begin to reference this field as the "Day Care" Flex
election for UTTouch, therefore A) I have changed the field names on this
dataset to also use "Day Care" instead of "Dep Care".
D10) Q) Dep Care Election fields - I understand the "deduction fields", but
what are the "election" fields? I'm guessing it's the amount the employee
has chosen to have deducted ... if so, is the amount monthly or annual? A)
The Election Amount is the annualized election.
D11) Q) Dep Care Election Stop Date - we assume this to be 8/31 of the
current FY, is that what you want? We fill the field with all zeros for our
current reporting. A) We are only required to populate the field when a
participant terminates from the plan before the end of the plan year.
However, it is my preference that we use the end date of the last pay period
when we receive the last payment for that person. This means that for
twelve month employees we should see 8/31 of the current FY with the last
dataset for that pay period and for the nine month employees we should see
5/31 of the current fiscal year for the May Monthly deduction file. It is
okay with EGI if you want to populate the end date with the expected last
pay period date on every dataset if you wish.
D12) Q) If an employee is paid semi-monthly do you want the semi-monthly
deduction amount in the DEP CARE PER PAY DEDUCTION AMT and HTLH CARE PER PAY
DEDUCTION AMT fields? Or do you want the total amount deducted for that
particular pay period (which would be reported monthly). A) We will want
the PAY DEDUCTION AMT fields to reflect the amount of money being wired for
that employee. If you plan to wire the money semi-monthly, then use the
semi-monthly deduction amount. However, if you plan to only wire the money
to EGI once a month, then please use the sum of the deductions for all
deductions during the month in these fields.
D13) Q) Employee/Component paid Fee - fair to assume these are for potential
future use? As far as we know, no one is paying a fee now. A) Yes, the
paid fees are reserved for next fiscal year if we need them. They should be
zero filled.
D14) Q) Can the employee's name be included in the file layout?
A) As I've
studied the dataset layout for whether and where to place a name field I
continue to find myself staring at the "EE ID" field. Since neither EGI nor
FlexBen intend to use this field any time soon, I think this would be the
best field for each component to use however they choose. If we do ever
decide to use a standard ID other than the subscriber's reference number (or
SSN) then we can easily make the change at that time. For now though, the
"EE ID" field can be used as a name or whatever free form value you would
like. Keep in mind, this information will not be stored on the EGI Flex
file, but since a copy of the dataset will be maintained for 12 months, we
will be able to reference the components' use of that field when needed.
However, it is not EGI's intention to transmit this data to FlexBen.
D15) Q) Where are the codes located for Dep Care Election Sign, and
Dependent Care Election Amount? A) The Election Sign fields should be either
a "+" or a "-". If the value for the Election amount is zero ("000000")
then a blank sign field is also acceptable. The amount fields should be
zero filled with the decimal implied, thus, $23 would be 002300.
General Questions
Finally, a few general questions:
G1) Q) In your instructions, you say we'll encrypt and send the file to
your FTP server. Ok for us to skip this step as we do with all our other
processing and just copy it straight to whatever name you want it to be
called on the mainframe? If you do want us to FTP it to your server, that's
fine, but the encryption part is going to be a problem (because as far as I
know, we're still not running any kind of mainframe encryption software and
we're not going to make this a manual process that has to go through
someone's desktop). A) It is still our preference, not our requirement, that
encryption be used on datasets prior to the FTP to our server.
G2) Q) There are going to potentially be some timing issues. We currently
send Flex data with each payroll, which means that some months there's only
going to be 24 hours between our files. For example, this month we're
running a semi-monthly payroll on 11/19 and the monthly on 11/20. What are
your suggestions for making sure we don't overlay the first file with the
second? If we have a semi-monthly and a monthly file created on the same
date, can they be combined or separated? A) EGI will code to handle these
timing issues, even if multiple datasets are sent from one component on the
same date. However, in order to prevent overlaying the first dataset with
subsequent datasets, the component should use a unique name in the
"freeform" section of the dataset name. Just to be clear, with timing as an
issue, each dataset should have a unique name when transmitted to EGI. EGI
will also code to handle one dataset from one component on a date that
contains data from two different payroll runs. If the dataset contains data
from two payroll dates with two different payroll dates, use the last
payroll date on the header field.
G3) Q) What information do you want to see on a termed employee?
A) I have
sent this question to FlexBen, but my assumptions are 1) Employment Status
should be sent as "T". 2) Date of Termination should be populated. 3)
Deduction may be a positive amount if another deduction is being
transmitted. Deduction may be zero if this is simply reporting a
termination with anticipation of no more deductions. Deduction may be
negative if an over-deduction was reported on the prior dataset(s) but the
termination had just not been updated in the component's system yet. 4) The
election stop date should be modified to show the end of pay period for the
last day of employment (or last day of active status).
G4) Q) Can definitions be added to the field layout? A) I am currently
working to get all values added to the layout.
G5) Q) Can I send a test file? If so, do I need to change the V2 to T2?
Also, do I send it to the same directory as the EGI file?
A) Yes, you can
send a test file using T2 instead of V2. Thus, the Component Remittance to
EGI would be SG.FLXFCRT2.compabbr.freeform. When reviewing my last email it
seems I left the component abbreviation out of the naming standard. The
standard, much like the eligibility dataset should include the component
abbreviation in the third label of the dataset name. The standard for
Component Remittance to EGI is SG.FLXFCRV2.compabbr.freeform thus for UT
System Administration the dataset name might be SG.FLXFCRV2.UTSADMIN.M021130
(I believe the limit is 36 characters).
G6) Q) What does RAPS stand for? A) RAPS stands for Reimbursement Account
Processing System. RAPS is FlexBen's next generation claims payment system.
It's enhanced features include: 1) Real-time web access to account
information 2) Real-time IVR access to account information 3) Improved data
auditing and load validation.
G7) Q) Do you prefer numbers or blanks for filler? A) I prefer blanks for
filler. If the field contains a null value, I prefer blanks for
alpha/numeric (Type A/N) and data (Type D) fields and zeros for numeric
(Type N) fields.
G8) Q) What is the process for requesting refunds when we have submitted
money for more deductions than we actually deducted in the payroll run?
A)
Credits may be taken for either the "Day Care" or "Health Care" deductions
by using the negative sign byte. They should only be taken for funds
already sent to FlexBen.
G9) Q) What do we do about retro payments for missing deductions?
A) You can
handle it either by combining all deductions into a single deduction on the
file or by sending individual deductions.
New version of dataset layout
If you have any additional questions please contact me via
email.
Thank you,
John Cotton, Manager of Information Systems
UT System, Employee Group Insurance