IBHIS GO-LIVE - Claims & Revenue Risk Mitigation Topics

Now that there is an updated LACDMH IBHIS GO-LIVE roll-out schedule and there have been a couple of update calls, I have been getting a lot of questions around the topic of claiming, reimbursement timing, revenue risks, etc.

 I have been assisting my customers lately with IBHIS Risk Mitigation planning .... Here are some topics to consider for your GO-LIVE plans.


·    Cash flow advances – Agencies going live between July – September will receive 3 months’ cash flow advances; others will receive the standard cash flow advance stated in their DMH contract (I understand that this is being modified in the FY16-17 contract to allow for additional cash flow advances should there be any IBHIS claiming issues.)


·    Timeline Example – If your GO-LIVE date were January 2017, mid-fiscal year, then DMH assumes you will stop sending claims to the IS by the end November 2016 and hold all further claims until the end of December and no later than the claims cut-off on January 6^th. All claims ready for submission after your IS cut-off date of Nov 31^st, will be submitted to IBHIS as soon as you are ready, which is estimated to be in late December. Here is a rough timeline of what that might look like:

•        July 2016 – EHRS Vendor must be ready for IBHIS, with most up to date Client Web Services (CWS) and 837/835 changes.

•        August 2016 – check on TPA modification request with DMH / ACHSA. (There is a pending request to modify the TPA agreement to be more mutual, and to remove some of the high risk terms for Legal Entities (LE))

•        Sept. 2016 – LE staff begin preparedness for IBHIS.... PRM updates, sign TPA, Vendor readiness, etc.

•        Nov. 2016 – LE's final push to have all claims submitted to the IS. CWS GO-LIVE, make client data updates in IBHIS using CWS. (Some vendors are doing this for their customers with bathing, others require lots of key strokes by LE staff, be sure you plan staffing time for this!)

•        *Nov. 31^st, LE's IS cutoff – last day to submit new claims using the IS.

•        Dec. 1^st thru approx. Dec. 25^th – HOLD all new claims; continue PRM and CWS updates; work with DMH to validate initial batch of IBHIS claims (on paper); DMH will create MCA estimates and set amounts for P-Auth codes (LE and DMH to agree on P-Auth amounts & MCA buffer %!). 

•        **Approx. Dec. 26^th – IBHIS Claims GO-LIVE, begin submitting new claims in IBHIS;

•        Jan. 6^th – last day to submit IBHIS pending claims for next month’s reimbursement check.

•        Dec 2017 – Current IS shut-down date.

*Dec. and beyond - You will continue working previously submitted IS claims using the IS, i.e. voids, replacements, etc. until IS shut down.

       ** Your IBHIS Claims GO-LIVE can be sooner if ready (once DMH has issued P-Auths), or later. As long as you submit all pending claims before the Jan. 6^th cut-off, you should have no gap in cash flow.

Note: The standard LACDMH IBHIS timeline assumes agencies will not miss any claims cut-off dates for monthly reimbursement, and therefore, should not need additional cash advances for IBHIS reasons. This may not be the case for everyone, you must map our your timeline and determine risks and plan mitigation if you miss these dates!


Here are some ways to mitigate:

•      DMH will allow LE’s to request a MCA “buffer”, a percentage above the MCA for the fiscal year, to avoid unnecessary denials. E.g. If LE voids a group of IS claims after the IBHIS GO-LIVE and does not replace them in the IS, then you may see claims incorrectly denied in IBHIS at the end of the fiscal year, unless DMH moves the voided claims’ funds from the IS to IBHIS P-Auths. Another example would be if IS claims are denied by Medi-Cal several months after your IBHIS GO-LIVE, and you prefer to re-issue these claims using IBHIS, then you will need these funds moved from the IS to IBHIS P-Auths to avoid these being denied for lack of funds toward the end of the fiscal year. The “buffer” will give you some cushion in IBHIS to avoid denials for lack of funding, however, you will need to carefully track your utilization to avoid over spending to plan.
  
  Question for DMH: How will DMH handle denied claims in IBHIS and the P-Auth amounts? e.g. Will DMH deduct the Medi-Cal fund amounts each time a claim is forwarded to the State, or wait until they have a response from the State? If the former, then will DMH add back the IBHIS denied claim amounts to your IBHIS P-Auths as soon as a denial comes from the State?
  
•      Maximum Contract Allowance (MCA) & P-Auth amounts – During the above claims HOLD time, DMH will calculate the LE’s remaining funding by plan based on their IS data (Maximum Contract Allowance - MCA). DMH will issue the IBHIS P-Auth codes that reflect their remaining funding by plan.  In IBHIS, any claims sent once the plan’s P-Auth code reflects that funding has been depleted, will be denied real-time. If the LE’s MCA is being shared in FY1617 between the IS and IBHIS, it is critical that the LE create their own estimate of their remaining MCA by fund to compare to the DMH MCA calculations prior to issuing P-Auth codes.
  
•      Claims validation just prior to GO-LIVE – DMH will provide a claims validation (paper Excel based method) just prior to your GO-LIVE, which is voluntary. I recommend you take advantage of this step. You will need to complete a DMH Excel template with all claims data for the initial set of claims you intend to submit to IBHIS in your first go-live month, and DMH staff will review the claims data for any issues that would cause rejections of denials. This will assure a smoother GO-LIVE. For large LE’s I recommend you take this approach for 2 months if you find significant changes needed in the first month validated.

As always, hope this provides some clarity and guidance to you! Call me if you need help.

IBHIS Pilot Updates - Lessons Learned, 3/26

Foothill Family Services and Welligent are now in full production with IBHIS, they have submitted ~ 3000 claims, with  some being rejected for assorted issues and now recently they have begun receiving 835's from DMH (none yet from the state).  In general, they feel Welligent has done a nice job of staying on top of the issues and getting them into production. They also are seeing efficiencies using Web Services to exchange client data with IBHIS, eliminating double data entry into the IS.

Although Group 3 was scheduled to begin testing in early March, that is not the case for most. Some have not yet been able to successfully connect during Provisioning are awaiting assistance from DMH.

Here are some Lessons Learned the Pilot participants asked me to share with you....

Testing Lessons Learned:

• PRM testing
• Best practice: You must use test practitioners that you already updated in PRM last June and DMH validated against NPPES. You cannot use new practitioners that did not get updated and validated in IBHIS last year.
        
• Client Web Services (CWS) and EDI Testing
• You will create a test client in IBHIS using the AdmitNewClient CWS (‘put’) command see guide HERE and you will get back the Client Name, Client ID, and Episode ID in the data IBHIS returns via CWS. Then you will update your EHRS with this data, either by manually typing it in, or preferably your EHRS will allow you to populate your client record with this data. Then you will use the other CWS commands to complete the Admit data, and other CWS testing scenarios. see testing requirements HERE. Note: this requires several CWS commands, so unless your EHRS automates these steps for you, you will need to do each in sequence to complete the Admit.
• If you use your production EHRS system for testing with IBHIS (rather than a testing or training EHRS system), be careful with the client ID’s. During testing, you will be communicating with DMH’s ‘sandbox’ or test database, not the production IBHIS client data. DMH will provide client ID’s to update your EHRS client record before testing claims for each test client, but these ID’s will not be the valid IBHIS ID’s you need during IBHIS production, they also should not be considered valid ID’s for IS claims.  
• Best practice: Use a test client database, rather than production.
• Best practice: if you use your production system / client data to test, after certification and before production / GO-LIVE, remove all the client ID’s you created in your EHRS during testing, and use CWS in production IBHIS to ‘get’ the real client IDs.
• Best practice: remove any test clients from your production EHRS, or disable them from exchanging data using CWS, before you GO-LIVE.
• For EDI testing you will need to send a test claim for each of your valid billing scenarios, Medi-Cal only, DMH plan only (indigent), OHC, Medi-Medi, etc. The Pilot agencies may not have tested all these scenarios, so Group 3 may experience ‘new’ errors or discover issues that were not uncovered in the Pilot. You will need to develop and test a workflow to update all required client data in the EHRS and IBHIS, before you create claims in your EHRS.
• Best practice: Use the exact same test clients for both CWS and EDI Claims testing scenarios and only send one claim line for each client.
• Best practice: develop a workflow or work with your vendor to automate a billing rule or method to prevent creating and sending claims before you have completed the CWS updates to client Financial Eligibility using UpdateClientFinEligibility _Input  command, see HERE.  This should include all required data, including Diagnosis updates as well.
• DMH will send you test P-Auth numbers to use during testing (I get asked this a lot now).
• Best practice: develop a workflow or work with your vendor to automate a method to prevent creating and sending claims before you have entered the P-Auth numbers into your EHRS.
• Depending on your EHRS program and paysource set-up, you may need the P-Auth numbers at the client / paysource level or at the agency plan level. Different P-Auth numbers are associated with Medi-Cal versus non-Medi-Cal claims. So if you need to submit claims for a PEI client, for example, who has Medi-Cal eligibility one month, but no eligibility a subsequent month, your EHRS needs to pull the right P-Auth # based on the client’s plan and eligibility combination. Depending on your set-up this could require your staff to enter the P-Auth every time the client’s paysources are changed, or to modify your set-up in its entirety prior to July in order to avoid this and have the paysources aligned with the P-Auth numbers. Each agency will need to assess this to meet their maintenance and reporting needs and trade-offs.
• Best practice: ask your EHRS vendor to allow for P-Auths at whatever level works best for you.
  

After GO-LIVE, Production Lessons Learned:

• Submitting your first production EDI Claims
• Give yourself enough time to submit a small 837 production ‘test’ batch that contains several different billing scenarios (recommend no more than 10 different clients). This will allow your staff to check the 837 before submission of the claims and it will not overwhelm your staff or the DMH staff as each side validates these.
• HX modifiers - Production
• Best practice: Make sure the modifier goes out on all non-Medi-Cal claims.
• P-Auths in the correct position
• Best practice: Make sure your P-Auth codes are all loaded and in the correct position in the 837 file. Pay particular attention to the separate P-Auths for the same plan, Med-Cal P-Auths are different from Non- Med-Cal P-Auths for the same DMH plan.
• Practitioners in PRM
• You will see data fields that are read-only/ grayed out in PRM, after DMH staff manually enters your practitioner data updates into IBHIS from PRM. These fields reflect what is in the ‘data of record’ in IBHIS, so if you see a mismatch between your PRM data and these fields, this may reflect a DMH data entry error as IBHIS does not match PRM. The data in IBHIS (read only/ grayed out in PRM), is what is being used to validate your Practitioner data for each claim.
• Best practice: if you see a read-only field that contains the wrong practitioner data, then resubmit your changes in PRM and wait for DMH to update IBHIS again.
• Client Financial Eligibility and Diagnosis
• During the Pilot, DMH did not have a mechanism to prevent claims without client financial eligibility and diagnosis data, from being submitted to the state Medi-Cal system.
• Best practice: same as during testing , develop a workflow or work with your vendor to automate a billing rule or method to prevent creating and sending claims before you have completed the CWS updates to client Financial Eligibility using UpdateClientFinEligibility _Input  command, see HERE.  This should include all required data, including Diagnosis updates as well. You or your EHRS should validate the data in IBHIS using the ‘get’ commands to review it.
• Cutover to Production
• You will not have access to update client data in the production IBHIS until you complete testing and obtain DMH certification and the production digital keys.  So, you will need to hold your production claims until all data is updated in IBHIS.
• Best practice: Make sure you hold all your claims when moving into production, until you can assure all clients have been created / admitted and all data in IBHIS has been updated using CWS commands.
• Clients that you need to bill to the IS, for service dates prior to July 2014, will have the same client ID in IBHIS if you allow DMH to create the client in IBHIS after you create them in the IS.  Clients that you create in IBHIS yourself, will have a new Client ID starting with #3000, and you cannot use this ID to bill these clients; services to the IS.
• Best practice: Make sure that you if you have a new client who received services before your cut-over date, July 1^st, 2014, (even if it is one day before), that you create the client in the IS first, and submit these claims to the IS. Then wait until DMH creates this client in IBHIS and you see the IS Client ID in IBHIS, by using CWS commands to check.  Once the ID is created in IBHIS, which should match the IS Client ID (unless this is a duplicate client in the IS or IBHIS) you can begin using this Client ID to claim to IBHIS for services delivered beginning July 1^st. If you do not see the client ID established in IBHIS and you create the client in IBHIS yourself, you may end up with a different client ID in IBHIS versus the IS and will be unable to claim to one or the other system depending on which ID you use in your EHRS.
• Best practice: Use CWS commands to search IBHIS for any new clients, before adding the client into the IS. (I know this leads to more questions, please ask DMH)

Hope this helps. Thanks to the Pilot agencies who are working all this out before you have to!

IBHIS Pilot Update

News Updates 2/26:

Five Acres and Welligent received DMH IBHIS certification for Web Services today and plans to go live with this feature on Friday 2/28.

Foothill Family Services and Welligent received DMH IBHIS certification, the first to do so. They went live with Web Services on Monday this week,  and are creating clients, financial eligibility, UMDAP, and client diagnosis records etc.  Planning on going live with billing on Thursday 2/27.

Certification does not mean that all required features are good to go though, everyone still making modification based on testing and production experiences.

Don't forget to thank these agencies for going before you!

If you have news on other pilot participants that you want to share, just let me know.

QUESTIONS AND ANSWERS updated

Check out updates to Q&A's HERE