Bi-Weekly Help Desk Call with Municipalities
9/8/2011
Purpose: The purpose of these calls is to provide ongoing communication to the municipalities on key
pieces of information related to NYEIS. We receive questions, calls on many of the same topics from
users from different municipalities. Broadcasting these frequent questions, communicating the status of
new releases allows us to follow-up with all municipalities at once instead of contacting each of the
municipalities individually. This improved feedback to the municipalities should also improve call wait time
to talk to a Help Desk representative. These calls will be held biweekly and the agenda will be stored on
the NYEIS webpage for munis to access if they can’t attend the call.
Agenda Topics
Number
Topic
Topic Description
1
Review
Structure of
Meeting
2
Feature
Request
Process
We’ve implemented process improvements to provide more
availability for our Help Desk staff to answer your questions.
We are now re-directing Feature Requests to not go through
the Help Desk and instead go directly to DOH BEI via the HCS
secure file transfer. This form will be available beginning
Monday 9/12.
3
Data Change
Request
Process
We’ve implemented process improvements to provide more
availability for our Help Desk staff to answer your questions.
We are now re-directing data change requests to not go
through the Help Desk and instead go directly to DOH BEI via
the HCS secure file transfer. This form will be available
beginning Monday 9/12.
4
Bugs
We have implemented several fixes recently, to address
issues related to:
1. Ability for Providers to view closed SAs.
2. Ability for Munis from the originating muni to view
closed SAs for children that have transferred to another
muni
Number
Topic
Topic Description
3. Claiming contract error
4. Corrected Provider Payment File Error
5. Increased Upload File Size from 1.5MB to 15MB – We
increased the maximum file size for any individual
attachment in a childs case to 15MB.
5
User
Administration
1. HCS Account Management – We get a lot of calls from
provider users who have established HCS logins but not
NYEIS logins. Although a login to HCS is a prerequisite to
logging into NYEIS, and although you are not physically
logging in with 2 sets of credentials, NYEIS does have its
own security. When a user clicks on NYEIS production on
HCS, the HCS login credentials are passed thru to NYEIS.
If NYEIS does not recognize the user ID, the user will be
unable to login. A call to the help desk can confirm the
lack of a NYEIS user account, and the help desk can refer
the user to the appropriate person that can create the
NYEIS user account.
2. User Registration in NYEIS – Municipal Admins, don’t be
afraid to call the NYEIS help desk for assistance with
creating your first user. It’s easy and fun.
3. User Roles and Access to Work Queues - Access to work
queues is managed via user accounts and further
controlled by a user’s assigned role
4. Remember: NYEIS logins need to match HCS logins
down to the case – Although HCS logins will accept
either upper case or lower case format for logging into
HCS, NYEIS logins must match their case. This has
confused some people who were not aware their HCS
login was actually lower case.
Example: your HCS login is hcs123. you can login to HCS
using HCS123, and when creating a user account for NYEIS,
you convey upper case letters for your HCS login info. You
will have trouble logging into NYEIS
Number
Topic
Topic Description
6
Provider users
vs. provider
employees in
NYEIS
7
Notifications –
explanation of
broadcast
methodology
and suggestions
for managing
1. Difference between an employee name on an agency
employee list and a user account for that individual –
Being able to assign a rendering provider to services in
NYEIS, and that rendering provider’s ability to login to
NYEIS are NOT the same.
2. A provider can be listed as an employee or contractor
for multiple agencies, but can have only 1 login (i.e.,
User Account) – There is only one NYEIS user account per
user. Among other things, the provider’s User Account
establishes the provider work queues that a user is
subscribed to (if their user role includes work queue
access) and tasks / activities/ data that the provider has
access to. The provider can be associated with an agency
or themselves.
User Account also establishes the user’s NYEIS user role.
Therefore at any point in time, a provider’s user account
will only associate the individual with1) a single agency
or themselves, but not both, and not multiple agencies,
and 2) a single user role.
3. NYEIS logins may not be needed for individuals – If an
agency that employs therapists plans to do the data
entry/billing on behalf of their therapists, then a NYEIS
login may not be needed for those individuals.
4. Service Coordinators and rendering providers should
not be associated with an agency in their user account
– This is needed so that the SC or RP only sees children
assigned to them
1. Typically notifications are sent to a child’s EIOD, SC
or all users subscribed to X_work queue – Users
frequently call in asking why they receive
notifications for children with whom they have no
affiliation. This is because the methodology for
notifications is to send the notice to all users
subscribed to a given work queue. Refer to User
Manual Appendix H – Workflows for details.
2. Delete notifications for children you are not
involved with, leaving the pertinent notifications –
If you don’t stay on top of notifications, it can quickly
become difficult to see and manage only the
notifications that are important to you. Make it a
habit to periodically go through your notifications
and delete ones that don’t matter. When you delete
a notification, you only delete the copy sent to you
and not additional users who may have also received
the notification.
3. If message displays that you have reached
Number
Topic
Topic Description
8
Fiscal
maximum allowable for space allotted, it is a hint
that it is time to clear out older notifications. There
may be useful notifications waiting to get through –
NYEIS can only display a maximum of 100
notifications to a given user. Realize that once this
number is hit, there are unseen, potentially relevant
notifications waiting to get through.
Fiscal staff should actively review their fiscal work queues.
There are a lot of denied claims or errors from Medicaid that
need to be worked. One large Medicaid remittance issue is
due to Medicaid currently paying the incorrect rate. This
issue has been fixed for new claims, but the older claims will
need to be reconciled by the muni. These tasks are in the
muni_fiscalMGR work queue. The helpdesk will be sending
out detailed instructions on how to resolve these claims.
9
Additional Tips:
Search tips
Searching Providers – Always try first on provider’s last
name (or state id) only if searching for an individual provider
for a user account or if adding an employee – cast a wide net
to return any and all likely matches. If you see an identical
name with a unique reference number, that is a dupe record
and the help desk should be made aware.
Searching Children – Try last name, date of birth, or even
just a fraction of the last name in case there is a concern
regarding the spelling of child’s name. Often, just searching
on the first few letters of the child’s last name or first name
will suffice to return the results you are looking for, and/or
confirm that the child is not yet registered in the case of new
referrals
The pitfalls of an improper search
1. Potential to duplicate records –
The potential to duplicate a provider record is always a
concern. If when adding an employee, you do not see an
existing record when creating that employee, you create
a new provider record via the ‘Create Employee’ tool,
however if that provider record was already in existence
and simply missed because a thorough search was not
conducted, duplicate records can be created. This creates
an enormous potential for problems down the road
when one attempts to make use of that provider. The
Number
Topic
Topic Description
same applies for duplicate child records.
2. Effort to remove –
Once a record is duplicated, only the help desk or
sometimes CMA developers can remove the duplicated
record, and that requires BEI review and approval.
Performing this removal takes time away from other
value-added activities. Until removed, working with that
duplicated provider can be problematic
Referrals – We typically see 2 major issues with referrals:
1. Please be careful to make sure the referral date is
correct – We often field requests to edit referral
date. Why? Because the person entering the referral
entered the child’s DOB for the referral date. This
causes the 45 day clock to be off, considerably.
2. Duplicate referrals – going back to searching for a
moment, if processing a new referral you do not see
the child was already registered, you have the
potential to create a duplicate child record. This
creates unnecessary work for the receiving
municipality, who then has to assign an EIO/D and
ISC just to be able to close case. Duplicate referrals in
and of themselves are not really a problem as long
as the municipality working the referral correctly
associates that referral to an existing child. These
simply get logged as an additional referral.
3. Effort to remove is significant and time consuming as
mentioned above.