NYEIS IFSP and Service Authorization (SA) Workflow and Review Process Targeted Resource

Transcription

1 NYEIS IFSP and Service Authorization (SA) Workflow and Review Process Targeted Resource Background The purpose of this targeted resource is to outline the existing NYEIS workflow and review processes in place for IFSPs and Service Authorizations (SAs). It is highly recommended that all NYEIS users review this targeted resource and that municipalities and providers develop policies and procedures to ensure that IFSPs and SAs are thoroughly reviewed at each step in order to ensure accuracy and minimize data change requests. By the time an IFSP or SA has closed, there has been several municipal and/or provider staff that have created, reviewed and accepted the IFSP and SAs in NYEIS. Allowing data changes to closed IFSPs and SAs has become a risk for both auditing purposes as well as system/database stability. If a data entry error was made during the creation or review and acceptance of an IFSP/SA, NYEIS allows for changes to be made in live NYEIS prior to any claims being submitted against the SA. Once a claim has been submitted, the IFSP/SA can still be edited; however this will be recorded as an IFSP/SA amendment. In addition, if a SA is missing for an agreed upon service, the SA can be added as an amendment prior to the IFSP closing. The BEI feels that this established review process, as well as the edit ability within NYEIS (that can occur anytime the IFSP/SAs are approved/active) allows ample time and functionality to have IFSP and SA data entered correctly. Municipalities and Providers must fully review the IFSP and Service Authorization data before acceptance to ensure accuracy as per the child and family's IFSP. Additionally, the IFSP and SAs should also be reviewed to ensure accuracy prior to the first claim submission, prior to the IFSP/SA end date and/or prior to the child leaving Early Intervention. Step Responsible Role What to Review What to do if the SA EIO/D, All below MUST be reviewed PRIOR to submission of the draft Service Coordinator IFSP/SAs in order to ensure that data entered is reflective of the services as 1. IFSP/SA Creation roles that may create IFSPs and SAs. Any user that creates IFSPs and SAs must ensure agreed to at the IFSP meeting. Provider of Record (if known at the time of SA creation) Script Recommendation (if required for the service type) Start/end dates for the service ( these are pre-populated with the start/end Frequency and Duration for the service (X/week, for X/minutes) 1 As a user that creates IFSPs and SAs, when an IFSP and SAs are in draft status they may be edited as needed to make corrections. If needed, the SA can be deleted and a new SA created. Additional SAs may also be added. This must be done PRIOR to submitting the IFSP and SAs.

2 submitting the IFSP. Make up visits (Will they be allowed, if so how many and how often?) participate) **Co-visits must be created on the SA of any service where more than one provider will see the same child for more than 9 minutes. Ensure all SAs for services agreed to have been added to the IFSP. EIO/D All below MUST be reviewed PRIOR to the acceptance of the submitted IFSP/SAs in order to ensure that data entered is reflective of the services agreed to at the IFSP meeting. 2. IFSP/SA Approval additional municipal roles that may review and accept the IFSP and SAs. Any user that accepts IFSPs and SAs must ensure accepting the IFSP and SAs. 3. SA Acceptance Provider of Record **PLEASE NOTE ** The acceptance of a SA may be done by any provider role that has access to the SA work queue Provider of Record (if known at the time of SA creation) Script Recommendation (if required for the service type) Start/end dates for the service (these are pre-populated with the start/end Make up visits (Will they be allowed, if so how many and how often?) Ensure all SAs for services agreed to have been added to the IFSP. All below MUST be reviewed PRIOR to the acceptance of the SA in order to ensure that data entered is reflective of the services agreed to at the IFSP meeting. The user MUST ensure that the SA that is being accepted reflects the services that were agreed to be provided. 2 As a user that will approve IFSPs and SAs, if there are errors found in the IFSP and/or SA data, you must make the corrections PRIOR to approving the IFSP/SAs. In addition if there are SAs missing for services that were agreed to, they must be added PRIOR to accepting the IFSP. Any corrections that have been made should be brought to the attention of the creator of the IFSP/SAs. As a user that will be accepting the SA, if errors are found the SC and/or the EIO/D should be contacted to confirm the the SA should be rejected and the EIO/D can make needed edits to correct the

3 for the provider of record. Any user Rendering Provider (may be assigned during the SA acceptance process) be created that accurately that will accept SAs Script Recommendation (if required for the service type) and agency providers in Start/end dates for the service ( these are pre-populated with the start/end can then be accepted. particular must ensure that staff assigned to accept The EIO/D will receive a task to SAs are aware of Make up visits (Will they be allowed, if so how many and how often?) reassign the provider of record the information for the SA, from this task they must make the needed changes reviewed PRIOR to to the SA and re-assign the accepting the SA. provider of record. The corrected SA will then be sent to the provider of record to accept. 4. Delivery of Services as outlined on a SA Service Coordinators and Rendering Providers with access to NYEIS Rendering providers with access to NYEIS will be able to view the SAs that they are assigned to. Agency providers are encouraged to provide rendering provider staff with access to NYEIS so that they may All below should be reviewed by the rendering provider PRIOR to delivering services in order to ensure that data entered is reflective of the services agreed to at the IFSP meeting. The rendering provider should ensure that the SA that has been accepted reflects the services that they are going to provide. Rendering Provider Script Details (should be entered by the rendering provider or provider of record as a data entry error when a script is required for the service to be delivered) Start/end dates for the service (these are pre-populated with the start/end 3 As the service coordinator or rendering provider that will be delivering services as outlined in the SA, if errors are found the SC and/or the EIO/D should be contacted to confirm the a data entry error can be completed to correct the be created that accurately can then be accepted by the provider of record and available to the rendering provider to view.

4 review the SAs for Make up visits (Will they be allowed, if so how many and how often?) the service that they will provide. 5. Claiming Provider of Record, Municipal users entering claims on behalf of providers. 6. Municipal Invoice **PLEASE NOTE ** roles that may create claims. Any user that creates claims must ensure submitting claims. Municipal Fiscal Staff Ensure all SAs for services agreed to have been added to the IFSP. All below should be reviewed by the provider role creating claims PRIOR to creating a claim in order to ensure that data entered is reflective of the services agreed to at the IFSP meeting. In addition, provider roles that will be responsible for claiming need to verify the supporting information received for the claim (session notes, time in/out, etc) reflect the data on the SA. Rendering Provider Script Details (should have been entered by the rendering provider or provider of record as a data entry error when a script was required for the service to be delivered) Start/end dates for the service (these are pre-populated with the start/end Make up visits (Will they be allowed, if so how many and how often?) Upon receipt and review of the required supporting information for submitted claims (progress notes, time in/out, parent signature, ect.) municipal users that 4 As a user that will be creating claims for the SA, if errors are found on the SA a claim should not be created and the SC and/or the EIO/D should be contacted to confirm the a data entry error can be completed to correct the be created that accurately can then be accepted by the provider of record and available to create claims against. The creation of the claim is the last possible point of review to correct errors in a SA as a data entry error. If an error is found once a SA has been billed against, and the SA needs correction, any claims will need to be voided and the SA change will be an amendment. As a municipal user that will be reviewing invoices if errors are

5 Review review invoices have an additional opportunity to compare supporting ** PLEASE NOTE** information to the information on the SA including: roles that may review invoices. Any user that reviews invoices Rendering Provider must ensure that Script Details (should have been entered by the rendering provider or they are aware of provider of record as a data entry error amendment to the SA when a script the information was required for the service to be delivered) Start/end dates for the service ( these are pre-populated with the start/end approving claims on invoices. Visits appropriate/day for the service (Would it ever be appropriate to deliver Make up visits (Will they be allowed, if so how many and how often?) Co-visits (will they be allowed, if so how many, how often, what QP will found on a claim with supporting information (progress notes, time in/out, parent signature, ect.) that conflicts with the information on a SA, the claim should be rejected and the provider of record contacted to void the claim. In addition if needed, the EIO/D or SC should be contacted to complete an SA amendment if the IFSP and or SA are not closed. ** PLEASE NOTE** If the IFSP and/or SA are closed then there is no ability to reopen and make the correction. Any IFSP/SA error must have been corrected prior to the IFSP and/or SA closing. 5