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!