IBHIS Readiness & Go-Live Phases

Although DMH has provided a Readiness Checklist on their site HERE. I have a little different view of the phases from a contract provider's perspective. For example, GO-LIVE is not an event, it is a phase that requires holding all claims, taking some readiness steps, then releasing some "test" claims, before you open your flood gates.

I am preparing a detailed readiness checklist for my clients, to use with their vendors and internal staff, so email me if you need help in that area. I am also doing some workshops on the same topic.

Here are some summary recommendations for your project planning by phase:

Provisioning & Testing Readiness

• Develop a Client Web Services (CWS) interface, with review capabilities
• Make required data collection changes in EHRS, forms / fields
• Modify EHRS set-up for procedures codes, Auths, EBP’s, drop downs, etc.
• Modify Medi-Cal &  DMH HIPAA EDI transaction sets for claims, 837, 835 etc.
• Develop COS HIPAA EDI claim transaction sets , 837, 835 etc. (this is new)
• Obtain Dun & Bradstreet Number (DUNS)
• Obtain Legal Entity Payee NPI
• Upload electronically to DMH, a signed Trading Partner Agreement
• Receive, Install & Test  Testing Digital Keys for : Claims (including COS), & CWS
• Complete Practitioner Data Verification & Updates, in EHRS &  PRM
• Select Clients for testing, based on DMH guidelines; develop test cases (extensive)
• Modify internal reports for new IBHIS SIFT extracts
• Update client records for surviving ID's (as needed)

Go-Live Readiness

Successful Application & Workflow Testing, DMH certification obtained (see testing requirements on DMH site HERE:

• PRM - Practitioner data entry into IBHIS, using PRM;
• Client Web Services  - new client data capture in EHRS; client data "gets" &  "puts" from/to IBHIS; and data posting of "gets" in EHRS; validate any data review processes EHRS allows for;
• Provider Connect - client look-up; M-Auth. request and receipt; enter M-Auth in EHRS; Day Treatment forms completion and submission;
• EDI Claims -  processing & submission (including COS); submission report validation;  EDI response retrieval &  posting to EHRS (including COS); response report validation; including transfers, voids, etc.; test new workflow including PRM, CWS, and Medi-Cal Financial data that is pulled into claims;
• Reporting and SIFT Extracts – download data, validate format and data; test modified internal reports;
• Receive, Install & Test Production Digital Keys: Claims, COS, & Web Services;
• Obtain DMH Certification for Claims & CWS;
• Users trained on all above;

Go-Live Phase

• Hold all FY14-15 Claims;
• Complete Client Data Verification & Web Services Updates, in EHRS & IBHIS;
• Complete Practitioner Data Verification & Updates, in EHRS & PRM;
• Request & Enter Day Treatment Authorizations into EHRS, using Provider Connect;
• Obtain  & Enter P-Auth Codes into EHRS;
• Submit Final Test Claims; Complete Integrated Testing of all workflows;
• Test / Validate Reports;
• Fix any Open Issues;
• GO-LIVE!

Hope this helps, email me if I left anything out.

Some important IBHIS Concepts and Concerns

Here are the IBHIS system components that you should understand, along with some operating principles. There are some workflows changes you need to consider, in order to prevent claiming issues.

First, what exactly is IBHIS (Integrated Behavioral Health Information System)? It is a "system", not just one product or application, but a group of applications, technology, and interfaces that, as a whole will enable LA County DMH (LACDMH) to collect and share client and practitioner records, and also to process your claims.

The IBHIS system of products/interfaces is comprised of:

(this is not a perfect technical explanation, but enough to understand the potential impact on your organization):

1.    Electronic Healthcare Record System (EHRS)

Every contract provider must have an EHRS with specific capabilities to interface with IBHIS. LACDMH is implementing their new EHRS ......Netsmart's Avatar product.
New concepts and operating principles:

·         Your EHRS must have bi-directional Web Services capabilities.

·         Your EHRS must have the new 837 transaction set. See below.

·         Your EHRS must collect the new required client and provider data elements, and map to the new data codes.

·         Your EHRS must allow you to enter the new P-Auth and M-Auth codes and pull them into each claim.

2.    Practitioner Registration Maintenance (PRM)

The LACDMH Practitioner database application, used to track data such as taxonomy and NPI #. Contract providers must login and manually enter new practitioner data and update existing practitioner data, one by one, in order to enable claims for their services to be successfully processed. This is very similar to what your staff currently enters manually into the LACDMH IS.
New concepts and operating principles:

• Beginning with your IBHIS Group's provisioning phase, your staff will need to manually update all practitioner records to be current, and keep these current going forward (double data entry in PRM and the LACDMH IS until all IS claims have been processed). There are two new practitioner data fields that must be maintained in your EHRS and PRM, discipline and category. These are tied to procedure codes the practitioner may bill for and their taxonomy.
• Each practitioner has been identified with a “Primary Provider” / Agency in PRM e.g. if the practitioner is associated to a directly-operated provider and a legal entity, the directly-operated provider is the primary provider. Only the primary provider may edit the practitioner data in PRM.
  
  
• PRM is not connected to IBHIS/Avatar, so once your staff manually enters your practitioner data into PRM, DMH staff in the Provider Support Office (PSO) will then manually copy this data into an IBHIS comparison database or Avatar (a little unclear still). DMH will then use this data they entered, to compare to the national practitioner database, NPPES.  DMH will download data from NPPES for comparison weekly (every Friday). The PRM data must have consistent practitioner data for job function / description, scope of practice, and the NPPES data. DMH staff will indicate practitioner records as “Pending NPPES Validation” in IBHIS, if they do not match NPPES, which will result in claim denials.
  
  
• Each claim’s practitioner will be validated against IBHIS, if the practitioner record is marked pending due to a mismatch, the claim will be denied. The practitioner on the claim must be associated with the Legal Entity in the IBHIS Contracting Provider table. The Practitioner’s Discipline will be determined based on the information stored in the IBHIS Practitioner/Performing Provider table. IBHIS validates that the Practitioner (837 Rendering Provider) is allowed to perform the procedure code on the claim, based on the discipline stored in the IBHIS Practitioner/Performing Provider table.
  
  
• CONCERN: Practitioner taxonomy history will not be tracked in PRM / IBHIS initially (they are working on it for post Go-Live), which means you must process all your claims for dates of service prior to the practitioner’s taxonomy changes, BEFORE you update the taxonomy in PRM, otherwise the claims will be sent by your EHRS with the correct taxonomy, but they will be validated against the current codes in IBHIS and get denied.
  
  
• Coordination and timing of Practitioner data updates in your EHRS and PRM, vs. claims processing days/times, to assure both systems are current prior to claiming.

3.   Provider Connect

      A web portal into IBHIS for requesting and obtaining Member-Authorizations for services, currently only for Day Treatment and concurrent Mental Health services, when client is in Day Treatment. This is very similar to the Day Treatment authorization systems used now. It can also be used for manual client look up, but not all data is exposed as with Web Services requests for information.

4.   Client Web Services (CWS)

A web based method to exchange client data between your EHRS and IBHIS.
New concepts and operating principles:

·         New client data elements are required for IBHIS and must be electronically “put” into IBHIS using Web Services. Therefore, your EHRS must be updated to collect these new data elements, and your provider staff must be trained to enter these in your EHRS.

·         Client data can be sent and retrieved, using search/modify/add functions in order to update the client record in either IBHIS or the provider’s EHRS. Staff must be identified and trained to exchange the client data via Web Services. How your EHRS vendor implements the Web Services interface is important, you may want some type of review mechanism and should discuss this with your vendor. Each EHRS should allow provider staff to review and approve client data prior to sending & posting updates, if you prefer this controlled workflow. CONCERN: Without CWS capabilities in your EHRS by July, you cannot issue claims.

·         In IBHIS, client episodes will be opened once and remain open for the life of the client. A single episode is created within the legal entity over time (despite movement between LE sites).

·         Some shared clients were merged in IBHIS (from the IS) and were given new “surviving” identifiers in IBHIS, and these new client” identifiers must be entered into your EHRS. Keeping in mind that pre-IBHIS claims must use an acceptable ID, and it is not yet clear how this will be managed.

·         Your EHRS must have Web Services capabilities to exchange the required data bi-directionally.

·         CWS data dictionary codes are different than the IS Codes Manual, so your EHRS vendor must map existing EHRS drop down values for client data collection, to the new CWS data dictionary codes, and you may need to change your drop down configuration.

·         Client demographic data will be shared between Legal Entities (LE) in the IBHIS client record, i.e. each LE shares approximately 18 client data elements and can overwrite each in IBHIS using CWS, (similar to shared data in the IS). Several of these data elements are also used in IBHIS to validate claims.

·         In July 2014, you will be provided Web Services access to update your client data in IBHIS, to assure it matches your EHRS before you submit claims to IBHIS. You may not have access prior to Go-Live, and claims should not be submitted until this data is updated.

·         Coordination and timing of Client data updates in your EHRS and IBHIS, vs. claims processing days/times, to assure both systems are current prior to claiming.

·         For some contract providers, this may entail new EHRS transaction fees.

5.   New HIPAA EDI Claims Transactions

For Medi-Cal, DMH, and COS Claims – the EDI 837 transactions have changed for IBHIS and your EHRS vendor must make these changes.

New concepts, and operating principles:

·         COS claims will be submitted via HIPAA EDI transactions, 837s, and your EHRS must support collection of the required claims data and the ability to load / track the EDI responses for these claims.

·         Client financial data will be pulled from the client’s IBHIS record into each claim, e.g. Medi-Cal eligibility data. This data is “put” in the IBHIS client record using CWS.

·         Claim data will be validated against the PRM and Client data in IBHIS, and result in denials if data does not validate or match. The client data being validates includes Client ID, DOB, and gender, (which are also shared LE data elements). See above for PRM data validation details.

·         835’s will use standard federal adjustment codes which will replace the existing specific DMH error descriptions.

·         Duplicate override codes are being processed differently, not clear yet. I believe your EHRS needs to make some changes in the claims incorporation of these codes.

·         Procedure Code modifiers and modifier combination changes must be identified in claims. e.g. telephone modifier. You or your EHRS vendor must modify these in your EHRS configuration, allowing for these to be pulled in by date of service, continuing to use current codes for claims prior to July 2014.

·         Only single EBP codes can be included in claims now, single State CSI EBP/SS or LACDMH-specific EBP.

·         The P-Auth and M-Auth Codes must be included in each claim, so your EHRS vendor must enable you to enter these annually and by client service, respectively, and pull them into each claim.

·         Claim void/replace workflow must change, to assure responses were loaded into your EHRS before voids are created.

·         Coordination and timing of PRM and Client data updates in your EHRS and IBHIS, prior to claims creation and submission to IBHIS. Here are my thoughts on this... you need to understand how these applications work together and how the claims validation routines work, in order to plan your workflows to minimize denials. There are several areas that will increase your denial rate, if you do not plan for these changes. Some information that should be considered include:

o    IBHIS will pull client financial data from IBHIS, into each Medi-Cal claim before sending to the state. State will compare claim data to their database and deny for mismatches. (see latest 837 companion guide, section 6.2.6); So, need to assure that your EHRS data is in synch with the state's database....

§  Contract providers can assure their EHRS database matches the states’ by using an automated 270/271 batch eligibility verification process that avoids data entry into the EHRS, BEFORE creating claims. Unless another LE has changed your shared client's data element that is compared, such as Name and DOB (see below).

o    DMH will use IBHIS data to compare to each claim, prior to sending to the state, and deny claims for mismatches. Data elements being compared include: client ID, DOB, gender, and financial info. (I think this is all, check the latest 837 companion guide, section 6.1.8). So need to assure that your EHRS data is in synch with IBHIS....

§  Contract providers can assure their EHRS database matches IBHIS, by using Client Web Services PRIOR to creating claims in the EHRS. If you have a high % of shared clients, then you should 'get' the data first, review it, determine if you should overwrite your EHRS with this data, or 'put' it to overwrite it in IBHIS, BEFORE you create claims.

o    Data elements in IBHIS that are shared across Legal Entities (LE) in IBHIS,  when the client is being served by multiple LE's, based on DMH presentations posted HERE, include:

1.        Client First Name

2.        Client Last Name

3.        Gender

4.        Date of Birth 

5.        Social Security Number

6.        Street Address 1

7.        Street Address 2

8.        City

9.        State

10.     ZIP Code

11.     Client's Home Phone

12.     Marital Status

13.     Primary Language

14.     LACDMH Detail Race/Ethnicity

15.     Education

16.     Employment Status

17.     Alias

18.     Email

6.    Reports

IS reports being replicated for IBHIS in a data warehouse. Not all tables currently provided for LE Extracts downloads will be provided with IBHIS, TBD.

OK, it’s a start! Email me if you see anything here that is inaccurate or incomplete and I will update it as soon as I know!

IBHIS Pilot Status

Wow, a lot has changed in 10 days time! I am doing a series of articles today and tomorrow, to address a number of topics I get questions about.... open questions, clarity around DMH answers provided, issues I see for providers, and status...

First, IBHIS testing status.....

Today we learned that 2 of the 3 vendors in the Pilot will not be ready to Go-Live on Feb 20th as planned, Clinivate and Exym. Now, that could just be due to their Pilot customers not being quite ready, or technical challenges, or both.

We also learned that Welligent will have only 1 customer ready on Feb 20th, so several contract providers are not quite ready on their end (yes, there is a lot for you to do too, this isn't just about the vendor development). So sounds like technically Welligent is ready to start testing.

Just waiting on official status from DMH on their site.

Important Contract Provider Questions regarding the July IBHIS Implementation

I am updating this post with the answers I believe we have , hope this helps! See below for updates........ red A: means I haven't read or heard an answer to date....... blue A: is the answer given verbally, in email, or the document posted now.
............as always, send email for any corrections or add-ons.

LACDMH has been holding regular CPTT meetings to address Contract Provider, EHRS vendor, and FFS Provider questions regarding the imminent July 1st GO-LIVE for their new IBHIS system. Since many providers aren't sure what to ask, I have been reviewing all the materials provided and compiling questions on your behalf.

The questions below I have provided to LACDMH and hope to see written responses via their FAQ page HERE, and/or updates to the companion and technical guides posted HERE. Be sure you collaborate with your EHRS vendor to address each topic below.

1.       Web Services

a.       What is the Client data exchange contingency plan if a vendor’s Web Services solution is not ready in time for Go-Live? (This is a new function and interface that must be developed by each EHRS vendor; without this interface functioning, on either the providers EHRS end or the IBHIS end, providers cannot open/update clients in IBHIS to enable claims processing.)

–        A:

 

 

 

b.      What is back-up plan if the Web Services solution goes down, on either end, after Go-Live?  Can the Provider Connect portal be used in some way for this? e.g. for manual look up of clients, for manual client data updates?

–        A:

c.       Since the IBHIS procedures include more stringent and less forgiving claims validation procedures, i.e. the comparison of claims data to IBHIS data and the PRM comparison to NPPES and claims….  Can DMH make some recommendations for the timing and sequence of Web Services client data updates (the  sequence of “gets and puts”), PRM updates, and claims submission, for the most effective and accurate claims submitted by providers EHRS’?

–        A:

Although no answer on this as yet, see my thoughts under #5 in an updated previous article HERE

 

 

 

2.       IS Client Data migration to IBHIS

 

 

a.        When and how will client data be moved into IBHIS from the IS, and when and how will we have access to begin updating client data in IBHIS?

–        A: Data was migrated from the IS, and de-duplicated. There will not be another migration, although new clients opened in the IS will be opened in IBHIS. Providers must use Web Services to update their data, and this access will not be available until after provider GO-LIVE. see DMH FAQ Q23 for details.

–        Note: This means providers will need to use Web Services to update client data prior to issuing claims to IBHIS, so should hold claims until this can be completed.

b.      For COS  clients, should we set-up a universal client in IBHIS for these claims;?

–        A: No, DMH already created COS episodes for all clients with LE’s that have these in their contract;

 

 

3.       Practitioner Registration Maintenance   Application (PRM)

 

 

a.       When will we be given access to update Practitioner data prior to our Go-Live?  How will access be obtained, via RSA Card and IS Logon ID?

–        A:  Just prior to each provider Group’s IBHIS testing phase, i.e. during the Group’s Provisioning phase, after your Readiness meeting; i

–        A:  If you already had PRM access in June, you may need only to have your password reset, no application needed. Otherwise an application for access must be submitted.

–        Note: this means that once you have this access and can begin updating practitioner records in PRM, you must arrange for staff to manage the triple data entry in your EHRS, the IS, and IBHIS, until your FY13-14 IS claims processing is completed.

b.      Will there be a Practitioner taxonomy date history maintained in IBHIS to match to the date of service for each claim?

–        A:  No, developers working on this, but not ready for Go-Live!

–        Note: at GO-LIVE you may have to time your taxonomy updates in PRM and claims submissions, to synch with any providers taxonomy changes, IBHIS does not track by date of service… yet.

c.       How often is the PRM data moved into IBHIS, and how is it moved?

–        A:  it is manually entered by DMH Provider support office, POS staff, weekly, no timeline commitment can be given.

d.      Will we receive an electronic file of all practitioners in PRM that have been marked “pending” or show a mismatch with NPPES? Will we be able to print a report showing all practitioners “pending”?

–        A:

4.       PATS prescriptions

a.       Please clarify what we need to do in the IS for indigent medication clients being served after IBHIS GO-LIVE on 7/1/14 when PATS  is being used.

–        A: Until PATS is decommissioned, now delayed until at least December 2014, clients must be opened with an active episode in the IS in order for PATS to authorize the medication. (PATS is connected to the IS, not to IBHIS);

–        Note: Do not close episodes in IBHIS or IS if using PATS for that client.

b.      Should providers continue to open new clients and episodes in the IS for PATS authorized medications, and these clients must also be opened in IBHIS via Web Services? However, if they are opened in the IS, and also opened in the provider’s EHRS and pushed to IBHIS via Web Services, won’t the client have two different client ID’s, one in IS and one in IBHIS? How to avoid this?  e.g. open the client in the IS only (this enables the PATS medication to be authorized), and wait for the new client to be pushed from the IS to IBHIS and an ID created there. Then use this ID in your EHRS for claiming. How often will the new client records be pushed from IS to IBHIS?

–        A: if you are live in IBHIS, and you have an indigent client using PATS, you must create an episode in the IS and in IBHIS for claiming;

c.       If a provider implements an e-prescribing solution, can they avoid using PATS before it is decommissioned?  or does DMH need their PBM implementation first, to replace PATS, DMH FAQ’s:

–        For DMH directly operated programs, PATS functionality will ultimately be replaced by a combination of OrderConnect (ePrescribing) and a Pharmacy Benefits Manager for indigent client (PBM for formulary management, claims adjudication, etc). Once a PBM is implemented, pharmacies dispensing medications for indigent clients prescribed by an LACDMH contracted agency will leverage the PBM service in lieu of PATS to determine eligibility.

–        A: No, providers must continue to use PATS until DMH has a PBM in place.

5.       Program P- Auths

a.       Please clarify the structure and use of these authorization codes in each claim. i.e. the 2400 loop states “Report the Provider, Member or Fee-for-Service Authorization # in the Prior Authorization field”, does that mean we only report the M-Auth, and if no M-Auth we report the P-Auth, or do we include both here? what is the format, string length, separator to be used, etc?

–        A: P-Auth include a “P” + 4-5 digits; they should not exceed 5 digits;

a.       When will we receive our P- Auths  codes for FY14-15, specifically? i.e., during provisioning phase so we can test them? Or, will we need to hold claims on 7/1/14 until they are provided and can be entered in the EHRS, so we will need to test with dummy codes?

–        A: DMH will provide these for Go-Live (no date specified) and then annually at start of the fiscal year. A cross walk between current IS plans and IBHIS P-Auths #’s is being developed by Zena. We can also provide an example.

–        Note: you cannot send claims to IBHIS until you have these P-Auths in your EHRS and in every claim.

6.       Member M-Auths

a.       How will access be provided to ProviderConnect?

–        A:

b.      Please clarify how we will determine if a client is being seen for Day Treatment at another Legal Entity (LE) prior to enrolling them in concurrent MH services, which we understand would require an authorization for concurrent services using the ProviderConnect portal.  

–        A: Web Services should be used to determine if the client is enrolled in Day Treatment and requires a M-Auth request be issued via the ProviderConnect portal, for concurrent services. You will not be able to use this portal to see if clients are enrolled in a Day Tx program.

c.       Will we be able to export the Auth data electronically, to import into our EHRS, or must we manually type it from the screen?

–        A: The Provider Connect response will be on the screen in Provider Connect and must be manually recorded in your EHRS to enable it to be pulled into the 837 claim files.

d.      How long will it take to receive the approval for the M-Auth in Provider Connect?

–        A: commitment is one week, but we expect it to be within one day.

e.      Please confirm that we will not need to use this application if we do not deliver Day Tx services and do not deliver concurrent services to a client receiving Day Tx elsewhere.

–        A: yes, this is correct for the current fiscal year. FY14-15 is TBD, and may require this system for other authorization types to be determined.

f.        When will this be determined for FY14-15, and will it be implemented retroactively if announced after GO-LIVE?

–        A:

 

7.       Claims Denials based on data validation against IBHIS  (client and PRM)

a.       Will every data element sent in each 837 claim be validated by comparison to the data in the client and practitioner records in IBHIS?  If not, which data will be used for comparison? Will the comparison / matching algorithm call for an exact match of every data element being compared, in order for the claim to be processed further? What can cause the match to fail? Will claim with these mismatches result in a rejection or a denial or something else?

–        A: see updated companion guide.

b.      Which data elements required in the claim transaction will be pulled from the client record in IBHIS and put into the 837 file by IBHIS? Will this only occur on Medi-Cal claims? We need to understand this in order to refine our data entry and Web Services workflows to assure they enable accurate claims.

–        A: see updated companion guide.

–        Note:  no reference to Medi-Cal in the 837; do not send the Medi-Cal info in claim, only the Medi-Cal  P-Auth code. DMH will pull Medi-Cal data into your claims before forwarding to the state.

c.       Will Claims consistency checks be performed against PRM Practitioner data? Which elements will be used to compare? i.e. NPI#, NPPES data, discipline, category, name, taxonomy. Will claims be unable to be processed if these data elements in IBHIS / PRM do not match what is in the claim? Will claim result in a rejection or a denial or something else?

–        A: see updated companion guide.

8.       Claims Cut-off schedule

       Can we submit claims to IBHIS, for service dates July 2013 forward (FY13-14), if not sent to IS already?  (there was a slide that eluded to this)

–     A: no, you cannot send claims with date of service (DOS) prior to 7/1/14 to IBHIS;

9.       Share of Cost (SOC)

       Is this process changing with IBHIS? for example, will SOC amounts collected be included in financial client data in IBHIS, updated via Web services in client record?, or via the claim….please clarify

–        A: no changes in SOC; used with Medi-Cal P-auths only;  UMDAP data is updated with Web Services.

10.   Location of a service

      Has the decision been made for providing the location of a service? If this is required, how will we provide this, in the 837? if so, will the companion guide ned to be updated and vendors will need to make development changed to the 837?

–        A: HIPAA requires that each claim include the location of service, so you should be collecting this data and transmitting it in each claim; DMH does not yet have the ability to validate that this was sent, but we will in the future.

11.  EBPs

       Please clarify this EBP change in the 837….i.e. Do providers need to make any clinical, service delivery, or service recording / workflow changes for this EBP claim element?

–         per DMH slides: IBHIS 837 contains single State CSI EBP/SS or LACDMH-specific EBP

–        A: With IBHIS you can only send one EBP with each IBHIS claim; There are 3 state reportable  EBP’s , and if you are not delivering one of these 3, but are delivering one of the MHSA DMH endorsed EBPs, then this is your EBP priority; if none of these, report a service strategy , or 99.

12.   Reports 

a.       How long will DMH maintain the IS archival data and reports and how long will we have access to it?

–        A:

b.      Will providers be able to pull reports for FY13-14 and prior, as well as FY14-15 from the same database? or will this require two different databases be accessed to get FY13-14 vs 14-15?

–        A: data will be combined and you will be able to pull bot IS and IBHIS data from the same source.

 

13.   COS HIPAA claims

a.       Since the decision was just announced on 1/21 that the COS files will not be via a pipe delimited format, but rather via 837…. when will we received the companion guide as our vendor has already begun development work on the other format? A: posted in site.

b.      Will we receive the HIPAA 277 response file, or just a 999 and 835 for COS, as stated in the recent IBHIS alert? A: Yes, same as all other EDI claims.

c.       Will we have a new testing schedule timeframe issued for COS via 837 since our vendors have not yet been able to start development? A: No

d.      Will these claims use the same FTP site and digital key as the other IBHIS 837 files?

–        A:

e.      How will the 837 work when there is no specific client for the service.  Does the 837 allow for no client?  i.e. will DMH be assigning a MIS/IBHIS number? do we need to use  a fake client as we do now in the EHRS (Eg - COS_FSP, etc.)? 

–        A: DMH already created COS episodes for all clients with LE’s that have these in their contract; the companion guide specifies the universal text to use to specify these clients.

14.   HIPAA EDI claims

a.       Will there be a 277 companion guide issued, as was for the IS? if not, what format assumptions do we make, IS or National standards?

–        A: no 277 companion guide will be issued, use the national standard format, do not use the IS companion guide.

b.      Must all Duplicate Override codes now be assessed and included by EHRS, rather than IBHIS? i.e. IBHIS will not include any duplicate override codes in the claims on behalf of the provider.

–        A: TBD

c.       Will Medi-Cal Claim transaction flow change, e.g. will we receive an “approved” 835 before the state adjudicates claim, and then a second denied 835 if the state then denies the claim during adjudication? i.e. Will we receive two 835’s for state denials?

–        A: Yes, you will received an “approved” 835 before the state has adjudicated your claims, then you will received a “denial” 835 if state denies the claim; if state approved the claim, you will not receive another 835.

15.   TPA application and digital keys for testing

a.       How long will it take for us to receive our approved TPA once we are permitted to submit it? Is this required to receive the testing keys?

–        A: it took approximately 1.5 months for the Pilot 1B provider to receive their TPA approvals. You cannot submit your TPA application until your Group is enabled to do so, however, DMH will provide you with the keys and access for testing as scheduled. It took only a few days for Group 3 to receive their approved TPA.

–        Note: approval  for Group 3 was fast, ~ one day.

b.      Must we have the approved TPA prior to receiving the production digital keys to allow us to begin submitting claims after 7/1/14? i.e. we cannot GO-LIVE until approval is received.

–        A: correct, you cannot go-live without an approved TPA and the production digital keys that come with it.

16.   Testing and Lessons learned in Pilot

a.       What information and learnings will be shared with non-Pilot providers and vendors, from the Pilot providers and vendors?  I.e. what did they learn and would have done differently?

–        A:

b.      Will we be cut-off from IBHIS testing on our testing end date? What if we have further testing of fixes to do, will exceptions be made and access provided?

–        A:

c.       What Practitioners will we use to test if we do not have access to the Client data via Web Services until after Go-Live?

–        A: we have a testing environment called “sandbox” which was loaded with the initial PRM providers entered in June, and approved for services (meaning NPPES match), these should be used for testing.

 

17.   OMA

Will the OMA data entry procedures change with the changes in IBHIS episodes?

–        A:

18.   FORMS

a.       Will clinical forms requirements be changing for IBHIS GO-LIVE?

–        re DMH FAQ: As long as the Providers print view has the data elements noted in the Organizational Provider’s Manual page 1-11 (http://file.lacounty.gov/dmh/cms1_159846.pdf) then it is approved. … It is up to the Provider to ensure it has the required data elements …..

–        A: not initially, required forms continue to be required with IBHIS, but requirements will change to allow for providers to print out their EHRS data for each form, as long as the required data is on the form and in the required sequence, however, a required sequence has not been issued.

b.      The DMH forms meetings have been verbally announcing form changes, but nothing has been communicated in writing or give to the IBHIS CPTT groups, when and what should we plan for?

–        A:

 

19.   Surviving Client ID

a.       If a New client comes to a contract provider A who is part of IBHIS Pilot 1 for the first time.  Client is created in IBHIS with and IBHIS client ID. Same client later comes to another contract provider B, who creates the client in IS with an IS Client ID. Will the nightly push from IS to IBHIS discover the duplicate?  If so, what will occur?  Will it notify us, or just not migrate the IS client into IBHIS?  Can we modify the client ID in the IS to be the IBHIS ID instead of that generated by the IS?  Or will DMH do the AKA match automatically for us?

–        A:

20.   Missing Documentation

When will these be available please:

a.       Requirements for 837P – residential claims, A: more info end of March

b.      835 - Claim adjustment reason codes; A:

c.       277CA – Claim status codes;  A: