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!
No comments:
Post a Comment