General Questions
Ans: For outpatient services there is one episode opened for a client at a Program of Admission, which associates one-to-one with the Legal Entity of our contract agencies. Directly Operated programs share a single Program of Admission. Outpatient Fee for Service clients are all admitted to the same program of admission shared among all FFS2 practitioners.
Please review to the Video presentation: ‘Rethinking Outpatient Episodes – A Key Concept’
URL: http://file.lacounty.gov/dmh/cms1_204348.wmv
Q2: Is there only one Episode per client/Legal Entity for their lifetime or do LE’s open and close programs as usual?
Ans: Outpatient episodes stay open as long as the individual is alive, whether or not they are continuing to receive services from one of the Programs of Service operated by that Legal Entity.
Mode 5 (inpatient/residential) episodes remain distinct; with a separate episode tied to each admission (inpatient facilities are Both Program of Admission and Program of Service).
Q3: What does the term “Program” mean? It seems to refer to the Legal Entity in the Web Services Companion Guide, but also refer to as program service level in the Claims Companion Guide.
Ans: The program referred in the Web Service is the Program of Admission and the program referred in the companion guide is the Program of Service.
Please listen to the Video presentation: ‘Rethinking Outpatient Episodes – A Key Concept’
Here is a URL: http://file.lacounty.gov/dmh/cms1_204348.wmv
Q4: The program field references D.22 in the dictionary – these values include Reporting Unit numbers and we have a code for each site. How do RU numbers used with IBHIS relate to the IBHIS episode/admission?
Ans: Episodes are opened to Admission program (ties to LE), while claims include the NPI of the Service Program (ties to Reporting Units/Service Locations). The outpatient episode is created at the Program of Admission/Legal Entity level regardless of which Service Program within that Legal Entity initiates the episode.
Q5: Dictionary Code Values vs IS Codes Manual. There are differences between these two documents. A few things noticed are: a) some field names have been changed so it’s hard to compare, and b) some fields are new and not included in the IS Codes Manual. For example: Data Dictionary – “Service Type” and IS Codes Manual – “Program Area”. These values look similar but are not identical. Customers are still relying on the IS Codes Manual because it’s familiar, but may need to refer them only to the Data Dictionary going forward. Is this the right direction? Will the IS Codes manual be discontinued?
Ans: Crosswalks between the IS values and IBHIS values have been provided. The IS Codes Manual will be discontinued once everyone is live on IBHIS. In its place, will be the data dictionaries provided for web services or the companion guide.
Q6: How do providers make sure that the client related data in IBHIS is matching with their own EHR system?
Ans: a) Prior to Go Live: The EFT extract provided with the client demographics (Refer Section –II, questions 3 and 4) should be validated against the provider’s EHR system to make sure that the data is in sync with IBHIS.
b) Once in LIVE: Use web services to make sure that the client data in the provider’s EHR system is in sync with IBHIS.
It is recommended that contractors do a web-service call to determine current IBHIS data on clients, and if necessary update incorrect and add missing information. Perform a get operation of the web services before doing a put operation, as the put operation basically overwrites the fields supplied in the web services call.
Note, since the web-service is a thick update, contractors should be careful not to overwrite accurate information in IBHIS with old, missing or inaccurate information.
Q7: We have both MAT and MH treatment programs, so when we open up a MAT case (we use the First Admission as the Type of Admission?) and if we refer to our own MH services for treatment within our own agency, what type of admission would we open up the treatment case since technically it’s the same episode?
Ans: As far as information that would be sent to DMH, you would initially set up an episode when you first see the client in any of the programs under your LE (in the case below, it would be the MAT program). Then when you refer to another one of your programs for the MH services, you will not need to do anything to open the episode. It would already be open based on the chosen MAT program. Therefore there would be no new type of admission. The treatment program would want to verify the client demographics, diagnosis, etc., are up to date.
Q8: Does a crosswalk exist between current IS Plans and IBHIS Funding Source?
Ans: A cross walk is published on the Provider website. Please <Click Here> to follow the link for accessing the cross walk.
Or use this actual URL Address: http://file.lacounty.gov/SDSInter/dmh/1061204_ISPlanstoIBHISFundingSourcesCrosswalk.pdf
Q9: Where can we obtain AID codes for Medi-Cal Programs, i.e. extended Medi-Cal and Katie A Medical?
Ans: The most recent Aid Code bulletin can be found at the state website. Please <Click Here> to get to the state website the aid code list.
Or use this actual URL Address: http://www.dhcs.ca.gov/services/MH/Pages/MedCCC-Library.aspx
However, always check the RMD Bulletins website <Click Here>
Or use this path for access
https://dmh.lacounty.gov
– Click the link ‘For Providers’ on the top bar
– Click the ‘Administrative Tools’ from the side bar
– Click ‘Revenue Management Division Bulletins’ from the right side ‘Bulletin’ Section to see if a more recent bulletin has been published.
Q10: What criteria will DMH use to establish whether or not a client is active in a particular LE if we are not discharging an episode until the client is deceased?
Ans: Service (claim) data can be used to determine whether the client is active or not in a particular program. Contractors can view this through the web service call function GetClientSvcHist.
Q11: This question is related to Reporting Units and Episodes. If the provider has multiple sites (and therefore multiple Reporting Units), if a client visits one location that belongs to one reporting Unit and later visits another location that belongs to another reporting Unit, Do they need to have separate episodes?
Ans: The provider will NOT need an episode under both, but the provider will need to make sure to submit claims under the current program of service (Reporting Unit). For outpatient and day treatment services, a client would have a single episode opened under the program of admission at the LE level to which all of that LE service programs (reporting unit) are associated. All services delivered by any of the service programs (RU’s) associated with that LE would be delivered to that client under that single episode.
Q12: TPA application and digital keys for testing –
a) How long will it take for us to receive our approved TPA once we submit it? Is this required to receive the testing keys?
Ans: If the application is complete and everything is in good order expect approximately one week to receive TPA approval.
b) Must we have the approved TPA prior to receiving the production digital keys to allow us to begin submitting claims at GO-LIVE? i.e. we cannot GO-LIVE until approval is received
Ans: Correct, approved TPA must precede the delivery of production digital keys.
Q13: Testing and Lessons learned in Pilot –
a) What information and lessons 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?
Ans: Lessons learned from Pilot 1b are incorporated into new policies and documentation that is published for all providers.
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?
Ans: This will need to be determined at the testing end-date based on the DMH resources available.
Q14: 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, PRM updates, and claims submission, for the most effective and accurate claims submitted by providers EHRS’?
Ans: Practitioner data should be kept up-to-date regardless of claiming activity. Client service updates are expected at client registration/time of service, or in other words real time. At a minimum Client Services must be submitted prior to claiming.
Conversion & Data Mapping
Ans: The conversion of client data from the IS into IBHIS is a relatively complex, one-time process that involved multiple intermediate steps associated with tasks including DMH medical records review to de-duplicate clients with multiple existing IS numbers, algorithms to “roll-up” existing IS episodes (at the reporting unit level) to the new IBHIS episode structure (at the Program of Admission/Legal Entity level). The original pull for this data was in late August 2013, and that dataset went through a rigorous de-duplication process. New IS client records created between then and December 18, 2013 were appended to that dataset and form the core of the client conversion dataset. The episodes of clients who had an open outpatient episode within a service location as of December 18, and who had been seen within that episode since 7/1/13 were included as episodes that were part of the rollup for new IBHIS episode creation.
Q2: What client information will be pushed from IS to IBHIS, and how long will we need to track changes to client information to update the data gap between what was pushed and what was not?
Ans: The IS push will involve processes run in DMH data warehouse comparing existing IBHIS client records against new IS client records created since December 18, 2013, and pushing only those client records that appear non-duplicative. The IS push is a daily operation that will create a new client record and an initial IBHIS episode (at the Admission Program/Legal Entity level) based on the initial IS episode created in IS for a new client. If the client information is already converted to IBHIS and a new IS episode is created for that client that should result in a new IBHIS episode, a new admission record will be created in IBHIS. This process is currently done intermittently but it will become a weekly process. If existing client/episode data is updated in IS, those updates will NOT be pushed to IBHIS. IBHIS client and diagnostic information should be verified and updated as needed on an ongoing basis once live in IBHIS. (Refer to Section I, question 6).
Q3: What data elements are being pushed from IS to IBHIS post-conversion?
Ans: Initial configuration of the Push includes the following elements. This may expand.
| Episode Information | Diagnosis Related information: |
| ClientID, | ClientID |
| Client First Name | episodeID |
| Client Last Name | DiagnosisDate |
| episodeProgram | DiagnosisTime |
| episodeAdmissionDate | DiagnosisType |
| episodeAdmissionTime | DiagnosisingStaffID |
| episodeAdmissionType | DiagnosisPrincipal |
| episodeAdmissionStaffID | DiagnosisAxisI |
| ClientGender | DiagnosisAxis1_2 |
| ClientDateOfBirth | DiagnosisAxis1_3 |
| ClientSocialSecurityNumber | DiagnosisAxisII_1 |
| ClientLivingArrangement | DiagnosisAxisIII_1 |
| ClientStreetAddress1 | DiagnosisTrauma |
| ClientStreetAddress2 | DiagnosisGeneralMedicalSummaryCd |
| ClientAddressZip | DiagnosisSubstanceAbuseDependence |
| ClientCity | DiagnosisSubstanceAbuseDependenceDiagnosis |
| ClientState | |
| ClientHomePhoneNumber | |
| ClientMaritalStatus | |
| ClientPrimaryLanguage | |
| ClientRace | |
| ClientEthnicOrigin | |
| ClientEducation | |
| ClientEmploymentStatus | |
| ClientAlias |
Q4: When will we get the EFT report (extract) that we are to reconcile against? Does this contain provider clinics data only (episode), or is this all client data (ie shared demographics that could come from another agency).
Ans: An EFT extract was provided after the conversion was completed with the client and diagnostic information in IBHIS. This included client information for all clients who had an IBHIS episode created within their admission program (Legal Entity) via the conversion routine (clients with open IS episodes as of Dec 18, 2013 with at least one service subsequent to 7/1/13). Due to client de-duplication, and episode structure rollup, the demographic & diagnostic information converted was based on survivor record algorithms and, in some instances LACDMH Medical Records staff review. Initial EFT file was posted on February 2014. This includes a list of patient IDs in instances where the IS IDs you are currently using was rolled into a different ‘Surviving’ ID. Subsequent reconciliation datasets will include IS Push created records.
Further information is as follows:
From the Reports Committee website (https://dmh.lacounty.gov/rc/), click on the Documentation Link (https://dmh.lacounty.gov/rc/c/documentation/). On the Documentation website, there two links regarding IBHIS data extracts:
1. Converted Data (from IS to IBHIS) Extract Information
a. This describes at a high level the individual tables in the Avatar Data Extract database and a list of how to work with the data provided
2. Legal Entity Extract Avatar Data Dictionary
a. This provides the description and layout of the Avatar Data Extract database
3. IBHIS Avatar Claims Flow
a. This provides a visual flow of the claims and their statuses through IBHIS
If you would like to receive training on how to work with the extract files, please send an email to Reporting@dmh.lacounty.gov.
Clinical Management and Documentation of Client Management
Ans: You will no longer need those forms. The data elements that are required by DMH are established through web-service and will be exchanged between the provider EHR system and IBHIS via this web-service. The information is required to be in the provider EHR system but there is no requirement for it to be on a paper form.
Q2: Can we use the “treatment planning” functionality within our EHRS, in place of the page one of the CCCP?
Ans: Regarding the treatment plan, per DMH policy 104.08, this is a required type of form which means in an EHRS you may have the data in your system however you choose as long as you have all the required data elements and can print them in a similar sequence to the paper form. So, yes, you can use your own treatment plan but make sure it has all the required data elements. Please refer to the Organizational Provider’s Manual for the required data elements of the treatment plan.
Q3: How can we obtain concrete DMH verification that we are meeting all DMH documentation standards throughout our EHRS, or in a specific section such as client treatment plans (CCCP)? What is the process for verifying that an agency is meeting DMH documentation standards within their EHRS before/after Go-live?
Ans: An updated Organizational Provider’s Manual is available on the DMH website (dmh.lacounty.gov) which clearly lists the required data elements for the treatment plan (as well as the Assessment). This will assist providers in identifying/ensuring they have all the required data elements. At this time, we are not able to verify/certify that you have all the required documentation data elements in your EHRS. It is up to the agency to make sure they are meeting all documentation requirements per the Organizational Providers Manual.
Q4: With more data collected in the EHR and exchanged thru web services to IBHIS, how will that impact the need for client signatures on financial forms? For example many fields from the PFI are now required in the EHR. Does this mean the requirement for the current PFI form will be eliminated, and if so, also the need for a client signature on this data?
Ans: A client’s signature is still required for the financial screening process/PFI. The signature can, for example, be captured on paper and retained in the EHR via scanning as long as it is available for review in case of audit. Also, a copy of the PFI should be given to the client for their records.
Q5: If a client is homeless is it still acceptable to put homeless in the street address and then use city, state and zip of the agency as the client’s address?
Ans: For homeless clients, providers should enter the address of the homeless shelter where the client stays, the address of the clinic where the client receives services, or a P.O. Box or address where the client receives mail.
Q6: Since the concept of SFPR is going away, our understanding is:
a. No single agency is responsible for coordinating services with agencies across LA County
b. If service occurs for out of county clients LA County agencies are no longer responsible for approving services
c. Each agency is responsible for creating, signing, and managing assessments and CCCPs without approval or signature from other agencies
Is this correct??
Ans: Yes that is correct.
Q7: How does a LE/Program release liability when a client is no longer under our care if the episode remains open (Some Providers we have an LE/agency level admit/discharge which is similar to IBHIS single episode, but we also admit/discharge within Programs and Services layers but this info does not appear to be exchanged thru web services)?
Ans: This is a legal issue to discuss with your own legal counsel. For Directly Operated programs, an episode being open or closed is generally not considered a significant determinant of liability. Clinical service delivery and the documentation of those services is typically the primary consideration regarding liability.
Q8: Provider Treatment Plan & DMH print view. Can we get written approval to replace the CCCP with Providers print view of the treatment plan?
Ans: 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. Unfortunately, we will not be able to look at every Providers print view to verify/approve it. It is up to the Provider to ensure it has the required data elements of a treatment plan.
Q9: FORMS – Will clinical forms requirements be changing for IBHIS GO-LIVE?
Ans: Not at this time. Please refer to the Clinical Forms Inventory, DMH Policy 104.08 and the Organizational Provider’s Manual for information regarding clinical form and clinical documentation data element requirements.
Q10: OMA – Will the OMA data entry procedures change with the changes in IBHIS episodes?
Ans: The Outcome Measures Application (OMA) for Full Service Partnership (FSP) and Field Capable Clinical Services (FCCS) as well as Prevention Early Intervention (PEI) OMA will remain unchanged at this point. Both OMAs will continue to exist outside of IBHIS and function normally. The two applications will be affected in different ways with the implementation in IBHIS. PEI OMA is not affected by the change in how episodes are defined in IBHIS. Episodes are not required for entering data for PEI OMA. PEI OMA is affected if the client doesn’t exist in the IS. Any clients that solely exist in IBHIS will not be visible to select in PEI OMA. CIOB is working on the solution to this problem, but at this point we don’t have an expected date for the fix. Data for clients that are not found in PEI OMA will need to be held and entered at a later date.
FSP and FCCS OMA is affected a bit more by the IBHIS transition. FSP/FCCS OMA requires an open episode for the provider to be able to enter outcomes. If the client had an IS open episode at the time the provider goes live on IBHIS, those episodes will remain open in the IS and will be available for providers to continue to select in OMA and continue to build on outcomes started in OMA. Clients that only exist in IBHIS or episodes that only exist in IBHIS are not currently visible in FSP FCCS OMA. If providers cannot locate clients and/or episodes in OMA that belong to them, they will need to hold data until OMA is modified. It is unclear at this time exactly how the change in the definition of episodes in IBHIS will affect OMA. More analysis needs to be done so that OMA can be modified to accommodate the IBHIS clients and IBHIS episodes. As soon as we have additional information, it will be released via one of our email list serves, through memorandums, or our project website www.dmhoma.pbworks.com
Q11: Is the PFI equal to the first date they became a DMH client with the first agency and does this follow the client through a lifetime?
Ans: The annual liability period is equal to the first date they become a DMH client with the first agency and it does follow the client year after year; however, if the client is not seen for several years, when they come back for services, the annual liability period would begin with the new admission date/initiation of services since the PFI has not been completed for the years that the client has not been seen.
Q12: With the concept of SFPR going away, how is the coordination of care managed across multiple LEs. What is the impact on cycle date?
Ans: Coordination across LEs and episodes should be done according to appropriate clinical practice. However, at this time, there will be no paperwork required for coordination. In light of Healthcare Reform, we are waiting to determine whether new requirements for formal coordination arise. Current policy is being updated to state that each LE is responsible for its own cycle date for clinical paperwork.
Q13: Is each CP/LE responsible for its own UMDAP dates?
Ans: The client’s annual charge period does not change when a client is open in different LEs at the same time. The initial UMDAP date will follow the client from provider to provider throughout the State. The only exception to this is when there is a significant lapse in service from any Mental Health Plan provider in California. Information regarding the responsible UMDAP provider is communicated throughout the system via the System wide Annual Liability fields in IBHIS.
Practitioner Management
Ans: Correct
Q2: There isn’t any provider/practitioner information exchanged through web services, correct?
Ans: Correct
Q3: Will Claims consistency checks be performed for NPI#, NPPES data, discipline, category, name, taxonomy, etc., against what is in IBHIS? Will claims be unable to be processed if the above data elements in IBHIS / Practitioner Registration and Maintenance Application do not match what is sent in the claim? Will claim result in a rejection or a denial or something else?
Ans: The Practitioner Registration and Maintenance (PRM) Application is matched to the NPPES data based on the practitioner’s NPI. It then verifies that the practitioner’s last name, first name and taxonomy code in PRM are consistent with NPPES. If these data fields are consistent, PSO staff will enter the practitioner information into IBHIS. LA County Claiming: IBHIS validates that the procedure code on the claim can be performed by the practitioner, based on the practitioner’s discipline in IBHIS. Claims that don’t pass this rule will be denied. The Addendum to Guide to Procedure Codes for IBHIS lists the disciplines that can use each procedure code.
State Claiming: 837P claims for Medi-Medi client services under MHS or Med Support where the rendering provider’s taxonomy code indicates that they are NOT a Psychologist, Social Worker, Physician, Nurse Practitioner, Physician Assistant, or Nurse Specialist do not require a Medicare COB. When the state adjudicates the claim for the Medi-Medi client and sees that there is no Medicare loop, it looks at the taxonomy code on the claim to see if it’s a code that can bypass Medicare claiming. If it’s not, the claim will be denied by the state. IBHIS will then re-adjudicate the claim resulting in a denial to the provider.
Q4: Will NPPES data or the IBHIS data need to be updated to resolve discrepancies before claims can be processed?
Ans: Yes, depending on where the discrepancy is.
Q5: Will DMH load the Practitioner Data from NPPES into IBHIS twice per month, and reflect providers as “inactive” if they do not match?
Ans: NPPES provides a weekly data extract which is loaded into the PRM Application. NPPES data is not used to inactivate providers. Providers need to inform DMH via the PRM Application when a practitioner is no longer active at their facility.
Q6: Will NPPES updates take up to 30 days to be reflected in IBHIS, so status will show “Pending NPPES Validation” until resolved, and claims will not be processed?
Ans: NPPES provides a weekly data extract which is loaded into the PRM Application. NPPES data is not used to change a provider’s taxonomy code or related values in IBHIS. Practitioners would make updates to the NPPES only if the information needs to be corrected or updated. This typically occurs when the practitioner’s last name changes or a practitioner’s taxonomy is updated. Claiming that’s dependent on the change should not be submitted until the changes are made in IBHIS. It is strongly recommended that legal entity staff responsible for adding new practitioners and/or updating practitioner information into PRM review the PRM User Manual.
Q7: Will there be a Practitioner taxonomy date history maintained in IBHIS to match to the date of service for each claim?
Ans: This functionality is currently being developed by the IBHIS vendor.
Q8: How often is the PRM data moved into IBHIS, and how is it moved?
Ans: On a flow basis, as PSO staff receive practitioner information from legal entities via PRM (Practitioner Registration and Maintenance) application, they will data enter new practitioners and/or updates to practitioner information into IBHIS.
DMH is currently working with the IBHIS vendor to develop web service functionality to allow the contract providers using the PRM application to update the IBHIS practitioner information as the data is entered into the PRM.
Provider Authorizations (P-Auth)
Ans: P-Authorizations are essentially the authorization numbers tied to budgeted maximum contract amounts by funding source for the entire fiscal year – thus they are determined by the contract and do not require separate requests by the provider and they are not tied prospectively to specific clients.
At the beginning of each Fiscal Year the provider authorizations (P-Auth’s) will be created by DMH and will be distributed via EFT folder. An RMD bulletin will be released to the providers informing about the availability of the new P-Auths.
Q2: Please clarify the structure and use of these 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.?
Ans: Please review the Business Rules section of the LACDMH 837 Companion Guide.
Client Service - General
Q1: When a provider goes live with web services, will there be an option on all required fields of unknown or something the Provider can default for those fields?
Ans: Trading Partners are expected to submit all fields when calling the Client Service. Required fields must be provided at a minimum in order to process any operation. Where applicable, Los Angeles County Department of Mental Health (LACDMH) has made accommodations for reporting unknown values, and has published guidelines in Companion Guide for reporting unknown information. Please note not all required fields allow for reporting unknown values. Trading Partners are expected to modify their existing Electronic Health Record systems if IBHIS requires data not captured currently. Trading Partners are also expected to accommodate workflow processes necessary to collect data. Ultimately, Trading Partners are responsible for ensuring the completeness and accuracy of all data submitted via Client Service for clients to whom they are actively providing services.
Q2: What is the process for going live with IBHIS interfaces?
Ans: Trading Partners must test and demonstrate a minimum core competency with interfaces by way of certification before being considered for Go-Live. In other words Trading Partners cannot be considered Go-Live ready until they can submit transactions using an interface successfully with minimal errors.
Q3: When will my organization have access to begin creating/updating client data in IBHIS via Client Service?
Ans: Trading Partners are able to create and update via Client Service once they are live with Production. Data exchanges with DMH APIs are real time.
Q4: Are DMH Interfaces dependent on other DMH Interfaces?
Ans: Yes in some cases are interfaces dependent on one another. For example, establishing and updating client administrative data via Client Services is a dependency for EDI Claiming. Another example of dependency is creating an SRL service request is a dependency for establishing a state mandated CSI Assessment. For more information on interface dependencies, please reference the interface companion guides https://dmh.lacounty.gov/pc/cp/ti/.
Q5: I’ve received an error while attempting to admit a client into IBIHS. The error message reads: “1000:Web service request failed: First Name, Last Name, and Date of Birth mates a client already in the system. Filing Canceled. Source: Avatar.” What is the problem?
Ans: This error is returned because there is already an existing client record with the same information as submitted. Trading Partners are not allowed to create duplicate client records. To avoid this error, DMH recommends performing a Search Client operation using Client’s demographics to retrieve the existing IBHIS Client ID. Once the ID for existing client is obtained, Trading Partners can perform an Admit Existing Client operation to create a new episode for the client under the treating program. Should the Search operation yield no match or multiple records with same information, please open a HEAT Self Service ticket documenting the response.
Client Service - Financial Eligibility
Q1: I am trying to Update Financial Eligibility for a Client; however I get the following error:
Business data error (99999) Existing Financial Eligibility record not found for client. How can I fix this error?
Ans: When a Client was admitted, the Financial Eligibility setup was not completed. Financial Eligibility is required and must exists for all episodes. Please open a HEAT Self Service ticket so that administrative action can be taken to create the required Financial Eligibility.
Q2: The Coverage Effective Date of a Client’s MediCal in our system is not matching with IBHIS. Why is this discrepancy and how can I fix it?
Ans: It is possible the Coverage Effective Date was overwritten by your agency when Updating Financial Eligibility. The Coverage Effective Date is taken into account when claims are adjudicated. If the service date is prior to the Coverage Effective Date, the service will be denied for lack of coverage. To correct the erroneous Coverage Effective Dates, please open a HEAT Self Service ticket, noting the ClientID, EpisodeID, and Coverage Effective Date.
Q3: I am trying to update an existing Financial Eligibility of a Client. However, I’m getting the following error:
The Following Fields Are Missing : Row:2: Subscriber Assignment Of Benefits Row:2: Subscriber Release Of Info Row:2: Coverage Effective Date Row:2: Guarantor Plan Row:2: Effective Date Of Contract Row:2: Eligibility Verified Row:2: Coordination Of Benefits Row:2: Subscriber’S Covered Days Row:2: Maximum Covered Dollars Row:2: Customize Guarantor Plan Source: Avatar. How can I get rid of it?
Ans: The error above is returned when a previously established guarantors is omitted from the update. When updating Financial Eligibility, guarantors previously established must be included. This means that if an Eligibility is being updated, which contained both LA County and Medi-Cal guarantor, then both LA County and Medi-Cal guarantors must be included in the update data submitted. To correct this error, modify the update to include all previously established guarantors.
Q4: I am trying to update an existing Financial Eligibility to delete MediCal guarantor. How should I submit the transaction?
Ans: Once you add the MediCal guarantor for a Client in IBHIS, there is no need to remove the guarantor, even when Client loses MediCal coverage.
Client Service - Clinical
Q1: When comparing a client’s IS episode admission date to their IBHIS admission date, the dates do not match. Is this a problem?
Ans: The episode Admission Date of 7/1/2013 was used to create IBHIS episodes for converted/surviving clients from the IS who had an admission date prior to 7/1/2013. For any converted/surviving client with an IS admission date subsequent to 7/1/2013, the IS Admission Date was used to create the IBHIS admission.
Q2: Should I use the “Substance Abuse Dependence” diagnosis fields in the CreateClientDiagnosis and UpdateClientDiagnosis operations to report dual diagnosis codes?
Ans: Yes, the “SubstanceAbuseDependence” and “SubstanceAbuseDependenceDiagnosis” fields should be used to report Dual Diagnosis.
Q3: What value should be submitted in the “TypeOfDiagnosis” field for the CreateClientDiagnosis operation?
Ans: When submitting the initial diagnosis for an Admission the expected value is “Admission”. Any subsequent diagnosis change for a given client’s same episode should be submitted through CreateClientDiagnosis with a diagnosis type of “Update”.
Q4: When do I use the “UpdateClientDiagnosis” operation?
Ans: The “UpdateClientDiagnosis” operation should be used to overwrite an existing diagnosis submission. This operation should only be used to correct a previously submitted diagnosis. Please note the original submission will be overwritten, as such all values, must be resubmitted through this operation, including corrections. Lastly, please note the originally submitted DateOfDiagnosis cannot be changed/updated through Update operation.
Q5: I am getting the following error when I tried to Update a Client’s diagnosis: Business data error (1000): Web service request failed with error: Duplicate Billing Order Found. Filing Cancelled. Source: Avatar. How can I fix the error?
Ans: This error typically occurs when a Trading Partner is updating Client Diagnosis by submitting a new Diagnosis code as the Primary diagnosis with Billing Order “1” which conflicts with the existing Primary Diagnosis that also has the Billing Order “1”. Please note ** The Create Client Diagnosis operation should be used to augment a diagnosis entry for a given client’s diagnosis record by adding a new set of Diagnosis records. Update Client Diagnosis should be used to correct any erroneous entry by overwriting originally submitted data with correction(s).
Client Service - Usage
Q1: The DischargeClient operation can be used when the client dies to end an Outpatient admission. Should the EpisodeDischargeComments field be used to describe the death?
Ans: There is no requirement to enter Discharge Comments. If the Discharge Comments field is used, it would NOT be appropriate to describe the client’s death in the field. The Discharge Comments would be more appropriate for administrative types of comments.
Q2: If the client’s Social Security Number (SSN) is unknown/not available at the time of intake, what value should be submitted?
Ans: If the client’s SSN is unknown/not available, the expected value is 999999999.
Q3: What is the expected type of admission for Outpatient admission?
Ans: The expected “TypeOfAdmission” for Outpatient admissions is Elective.
Q4: If my client’s address is unknown or not available, can my organization use 9999 Unknown?
Ans. A valid address is expected for all submissions. For clients whose address is unknown, please use the street address, and zip of the location where they receive mail (e.g. a DPSS office or a shelter) or your organization’s address. For more information please refer to RMD Bulletin 14-011 – Use ZIP Code + 4 in IBHIS.
Q5: Is “99999-9999” an acceptable value for Zip Code field?
Ans. The value 99999-9999 is not a valid Zip Code. A valid United States Zip Code is expected and must be provided. For clients whose address is unknown, please use the street address, and zip of the location where they receive mail (e.g. a DPSS office or a shelter) or your organization’s address. For more information please refer to RMD Bulletin 14-011 – Use ZIP Code + 4 in IBHIS.
Q6: Do Trading Partners need to modify their EHR systems to collect data for required fields to submit to LACDMH Client Service?
Ans: Yes, LACDMH expects all Trading Partners to make every effort to collect and submit all required data elements defined in the Client Service operations.
Q7: When I try to create UMDAP record, I get an error asking me to provide a UMDAP Unique ID. What should I do?
Ans: When successfully creating an UMDAP entry, a unique id for the submission is returned to the Trading Partner. All subsequent Update UMDAP submissions require a unique UMDAP ID. If your system is requesting an UMDAPID when creating an UMDAP entry; please contact your IT department or your IT vendor and explain them that your system needs to send a ‘Create’ UMDAP transaction for that particular submission.
Client Service - Certification
Q1: There are many optional fields listed in the Client Service certification testing scenarios. Are those optional fields “required” for testing?
Ans: Trading Partners are expected to submit all required fields when testing or certifying. LACDMH expects that all data be submitted. If a Trading Partner has a question regarding whether a particular workflow or dataset is relevant to their Program of Care please open a HEAT Self Service ticket to work with Integration Support.
Q2: What is the purpose of IBHIS TST environment (https://b2btst.dmh.lacounty.gov/*)?
Ans: The Test environment is intended for Trading Partners’ integration development. Release Candidates are deployed here to provide a preview of upcoming functionality in order for Trading Partners to analyze, develop, and test against an operational endpoint.
Q3: What is the purpose of the IBHIS QA environment (https://b2bqa.dmh.lacounty.gov/*)?
Ans: The QA environment is pre-production. This environment mirrors LACDMH’s production environment in terms of architecture and versioning. This is where trading partners can perform user acceptance testing and certification prior to promoting to production.
ProviderConnect and Member Authorizations
Ans: Yes, providers will use ProviderConnect for requesting Member Authorizations and receiving the response to the request.
Q2: ProviderConnect will be used for P-Authorizations?
Ans: No, only M-Auth’s.
Q2: Is there any connection between LE Extracts/EFT(SIFT) and ProviderConnect? Agencies will still need LE Extract/EFT(SIFT) for certain reporting functions?
Ans: There is no connection between LE Extracts/EFT and ProviderConnect. Agencies will have data extracts and reports in their EFT folder. ProviderConnect does not provide access to LE Extracts/EFT folder.
Q3: How will access be provided to ProviderConnect?
Ans:
Each ProviderConnect user will need to complete a set of access forms to receive access.
Provider must complete and submit (either previously or with the set) “Individuals Authorized To Sign Applications Access” form (New or Replace signatures on file form that includes e-mail address).
The other required forms for each user to complete include Application Access, Oath of Confidentiality, E-Signature Agreement and County of LA Agreement for Acceptable Use.
These are PDF fillable forms that (after the requestor completes the forms) will need to be printed, signed, scanned and submitted to DMH
Mailing address:
LA County–Department of Mental Health
Provider Support Office/Systems Access Unit
695 S. Vermont Avenue, Los Angeles, CA 90005
Email address: DMHPSO@dmh.lacounty.gov.
Q4: Can a provider use ProviderConnect, to look-up client’s status in day treatment across LE’s?
Ans: The provider can use the “Add New Client/Client Search” function in ProviderConnect to view all active or inactive episodes for the client. This would include admission and discharge date information. The details of the episode are not to be provided.
Q5: How long will it take to receive the approval for the M-Auth in ProviderConnect?
Ans: The Central Authorization Unit (CAU)’s turnaround time for authorizing new Client Care Plans (CCP) is 14 days for Day Rehabilitation (DR), and 7 days for Day Treatment Intensive (DTI). For reauthorizations, DR CCPs are to be submitted to the CAU at least 15 days prior to the current CCP ending and for DTI at least 7 days before the CCP end date. Remember to submit authorization request and CCP as soon as possible. Note, the number of days mentioned above are calendar days.
Q6: What types of services require member based authorizations?
Ans:
a) Provider needs to obtain member based authorization for all day treatment services.
b) Provider needs to obtain member based authorization for concurrent mental health services while the client is in a day treatment program.
c) Fee-For-Service providers need to obtain member based authorization, once the client is exhausted with their under-threshold services.
d) Fee-For-Service providers need to obtain member based authorization for Psychological Testing.
Claims Processing
Ans: You will send one claim. All reporting will be based on the P-Authorization used, which essentially is a plan.
Q2: Do we need to send an 837 for Medi-Cal and then a second 837 for DMH plans after we received the Medi-Cal 835?
Ans: No, only send one claim. All reporting will be based on the P-Authorization used.
Q3: If client has OHC, Medicare, and Medi-Cal, currently these pre-Medi-Cal payor responses are all indicated in the 837 to Medi-Cal/DMH; how will this change now with IBHIS?
Ans: This will not change. All OHC and Medicare adjudication information must be reported on the claims submitted to LA County DMH.
Q4: How will Medi-Cal funded clients and claims be differentiated from Medi-Cal Expansion clients and claims? Currently we have funding that differentiates Medi-Cal from Medi-Cal Expansion clients, so these are tracked separately by Aid codes that come back in the Medi-Cal state 835 from DMH. How will this change? Will there be separate P-Auth codes?
Ans: This will not change. You will use the same P-Auth for Medi-Cal and Medi-Cal Expansion clients, similar to how you use the same IS Plan for Medi-Cal and Medi-Cal Expansion clients. And you will continue to receive the SIFT/EFT Reports. RPT_FINCLAIMLIST will have the state approved aid code, as we did with the IS.
Also please refer to the RMD bulletin NGA 13-103 Short Doyle II Aid Codes Master Chart 11-25-13 for the Medi-Cal Expansion aid codes. Or click here to see the bulletin.
Q5: Is Katie A just certain procedure codes or a separate guarantor?
Ans: Katie A is a guarantor. For Katie A clients, there are additional allowable services: Intensive Care Coordination (ICC) and Intensive Home Based Services (IHBS). Claims for clients with the Katie A guarantor can use any appropriate procedure code including both ICC and IHBS and any other procedure codes allowed under the funding source.
Q6: 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?
Ans: Please review the Business Rules section of the 837 Companion Guide.
Q7: 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.
Ans: Please review the Business Rules section of the 837 Companion Guide.
Q8: 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.
Ans: There is no change to the way Share of Cost is reported on the 837 claims. Contract providers are obligated to collect the Share of Cost and it is not recorded in IBHIS system.
Q9: 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 need to be updated and vendors will need to make development changed to the 837?
Ans: Please review the Service Facility Location section of the 837 Companion Guide.
Q10: EBPs – Please clarify the EBP change in the 837. Do providers need to make any clinical, service delivery, or service recording / workflow changes for this EBP claim element?
Ans: IBHIS 837 contains single CSI EBP/SS or LACDMH specific EBP codes. It is up to the provider to decide whether to make any changes to their clinical or service recording/work flow.
Q11: Will there be a 277CA companion guide issued, as was for the IS? If not, what format assumptions do we make, IS or National standards?
Ans: No 277CA companion guide will be issued. Use the national standard for formatting requirements. In addition, the IBHIS 837 5010 Companion Guide includes the 277CA Claim Status codes that IBHIS uses when rejecting a claim prior to adjudication. Do not use the IS 277CA companion guide.
Q12: Must all Duplicate Override codes now be assessed and included by EHRS, rather than IBHIS? IBHIS will not include any duplicate override codes in the claims on behalf of the provider?
Ans: Correct. IBHIS will not make any modification to the 837 submission and hence will be accepted as submitted.
Q13: 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? Will we receive two 835’s for state denials?
Ans: Please review the Business Rules section of the 837 Companion Guide.
Q14: When will these be available?
a. Requirements for 837P – Residential claims;
Ans: The 837 Companion Guide has been updated for Residential and Inpatient claims.
b. 835 – Claim adjustment reason codes;
Ans: Published on Provider Website.
c. 277CA – Claim status codes;
Ans: The 837 Companion Guide includes the 277CA claim status codes that IBHIS generates.
Q15: When should we use non Medi-Cal Billable procedure codes?
Ans: The procedure codes with HX modifiers are not billable to Medi-Cal. The PC with HX modifier can be used in the following situations.
a) For the claims submitted with non Medi-Cal funding sources for a client who is Medi- Cal Eligible.
b) If the client does not have Medi-Cal eligibility, AKA indigent clients.
c) If the service is not Medi-Cal reimbursable
Q16: For a single client, provider bill Medicare first for certain procedure codes and staff. However there are some codes/staff for the same client where we don’t need to send claims to Medicare first.
a) When we submit these claims through IBHIS, what would be the client’s SBR code in 837? P? S? T?
Ans: The client’s SBR code in 837 would be Primary for those claims that are not submitted to Medicare.
b) Or in other words, does the SBR value in 837 depend on the billing code and/or rendering provider?
Ans: It depends on whether the claim was adjudicated by another payer before being sent to DMH. When DMH is the first payer to get the claim it’s treated as a Primary claim. If the claim goes to Medicare first, it makes DMH the Secondary payer on the claim. And that is dependent on the billing code and rendering provider.
Reports
Ans: Indefinite on both counts. Certainly as the data will be maintained through the final settlement process with the State for each FY. Beyond that there is no plan to purge or limit access to the data at this time.
Q2: 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?
Ans: Still being discussed internally in DMH and the information will be provided as soon as it is available.
Q3: How do I access the list of duplicated IS clients that have been merged in IBHIS?
Ans: You will need to use your EFT folder to access the IBHIS data extract. See the Reports Committee website for more information (https://dmh.lacounty.gov/rc/). If you do not have an EFT account, you will need to sign up to access this data. The website also contains those forms.
EDI FAQs
Q1: I am unable to login to my WinSCP (or any other FTP Client) and upload my files. Why?
Ans: Please check the cutoff date for processing EDI files. You will not be able to login and upload files during cutoff dates. DMH sends notifications to all Providers with the cutoff dates for FFS Providers and LE Providers.
Q2: It is not cutoff time and I am unable to login and upload my Claim files. Why?
Ans: Please contact your office IT staff to check your system and make sure that you are not experiencing internal technical issues. If the issue appears to be on DMH side please open a HEAT Self Service ticket.
Q3: I uploaded my 837 claim files but did not receive any response files. Why?
Ans: Please allow 24-48 hours for processing, checking periodically during the processing window. Once the processing window has passed and response files have not been generated by IBHIS, please create a HEAT Self Service Ticket and include the name of the 837 Claim file in question.
Q4: I uploaded my claim files and received my responses but claims were rejected/denied. Why?
Ans: For additional information on claim rejections or denials, please create a HEAT Self Service Ticket and include the name of the 837 Claim file in question.
Q5: Are there any documentation or guidelines related to the EDI Claim files?
Ans: Please follow this link https://dmh.lacounty.gov/pc/cp/edi/
HOW TO CONTACT DMH OR REPORT AN ISSUE
Ans: IBHISWSS@dmh.lacounty.gov
Q2: Who to contact when there is an issue related to Clinical Data (eg. Duplicate client records)?
Ans : DMHHIM@dmh.lacounty.gov
Q3: Who to contact when there is an issue related to Financial Eligibility?
Ans: RevenueManagement@dmh.lacounty.gov
Q4: Who to contact when there is a Billing Issue? Eg. Duplicate 999s, 277 files that don’t make sense, or 835 files that never arrive, or when they do arrive, they have rejections that we don’t understand.
Ans: HEAT Self-Service
Q5: Who to contact when a complete failure of the system occurs? Eg. 837 files we drop never get processed, or we get some “BizTalk” or “Avatar” error.
Ans : IBHISWSS@dmh.lacounty.gov
Q6: Who to contact when there is an issues related to EDI claims certification testing?
Ans: HEAT Self-Service