Anyone else run into these issues in Version 10.
ammllc01
we continue to encounter using Version 10.14.
Now they are begining to tout Version
11.00 ..............................
Claim filing indicators
You stated “the claim filing indicator is, by default, determined from
within the ANSI format by looking at the insurance type on the bill.”
I completely disagree with you. By “default”, the claim filing
indicator/ insurance type is “determined” in each insurance company
file. When an insurance company is added to a patient file, the
insurance type is populated based on the type selected in the
insurance company file. When a bill is created for a patient, the
insurance information is populated from what exists in the patient
file. The ANSI form pulls the claim filing indicator from the bill,
but it does not “by default” “determine” the indicator. Version 7
housed the claim filing indicator in the insurance company file only,
with the exception of being able to over-ride it manually in the
bill. From what I can gather, I believe the initial problem was
caused by two issues in the conversion.
First, since V7 has no field in the patient file for the claim filing
indicator and V10 does. The conversion mapping apparently did not
account for this. I’m not stretching it when I say that at least 80%
or more patients converted with no claim filing indicator at all and
the remaining 20% that did, had one that was wrong. Some Medicaid
patients had a BCBS indicator, some BCBS patients had Medicare &
Medicaid indicators or “other”, some Medicare patients had “other” or
Medicaid or Medical Group, etc.
The second issue deals with the account numbering that occurred during
the conversion. It seems that the account numbering in V10 is not a
separate “per table” function, but is sequentially read as a whole.
The patient files are obviously converted first. As everything
followed, anything or anyone that had an account number from V7 that
was the same as a patient account number, the conversion assigned a
new account number to the record, using the next sequentially
available number…whether guarantor, employer, insurance company,
physicians. The only problem is that it only changed the account
number in the table or file that the specific account resided in. To
be clear; if an insurance company was assigned a new account number,
the change occurred only in the insurance company file. Patient files
and/or bills still had the “old” V7 account number, which left a link
to a file that no longer existed…a blank record.
NPI numbers
The second issue that I detailed above created a massive issue with
the NPI numbers. The scenario is basically the same as the one above,
only to much larger degree. So, any referring physician that was
assigned a new account number was still listed in the patient file and
transaction screen in each and every existing instance with the “old”
V7 account number. When we began to receive rejections from the
clearing house we started the process of figuring out why. I
mistakenly took for granted that when the conversion error log gave me
a message that an account number had changed, it meant changed.
For the record, your comment “…help us to determine IF and where the
problem exists” (emphasis mine), is insulting at best! You can rest
assured that a call to Alta Point technical support is not on my
“things I enjoy doing”. If I place a call to technical support, it is
because there is a problem. If I am unable to convey the problem to
you or anyone else adequately enough for you to understand the problem
in no way negates the fact that there is a problem! Furthermore,
whether you have or have not had other reports, besides my own, of
these issues or any other issues that may arise doesn’t concern me in
the least.
Insurance Claim Forms
You stated that “the insurance claim forms will work out of the box
with some clearinghouses”. I would like to make a point regarding
“some clearinghouses”. ANSI is a transaction standard, mandated by
the Federal Health Insurance Portability & Accountability Act
(HIPAA). The standards for electronic transactions under HIPAA were
intended to have all necessary data elements included in one file for
complete processing. Having a software or clearinghouse that is
“HIPAA compliant” means nothing as far as a provider being compliant
if the necessary data is not being captured. HIPAA EDI is not just
about EDI format but also about the data content in those EDI
transactions. HIPAA requires all electronic claims be submitted in a
standard format & comply with all required data elements & those
situational elements that are applicable based on various conditions
that are detailed in the implementation guide. My point is this: a
clearinghouse that will not accept any and/or all data fields won’t be
a clearinghouse for long! On the other hand, proprietary adaptations
are made by payers to the standard. Yes, modifications are needed at
times to the ANSI form to accommodate certain payer requirements but
in my experience these are limited to such things as requiring a
taxonomy code in the referring provider loop or rendering provider
loop, or having a legacy provider number in a certain loop, even
requiring the mailing address listed in the billing provider loop to
precede the physical address. I do not expect those modifications to
be accommodated for in Alta Point forms. However, the V7 forms & the
V6 forms required so many modifications that I lost count! To say
they even met “most requirements” (as you put it) would be like filing
only the 1st page of your 1040 tax return form and believing that
would satisfy the IRS!! I copied my modified V6 form to V10 and only
had to make a couple of changes because of the table/field name
differences in the two versions. Since V10 (as well as V8 & V9) is
really just V6 on various enhancing drugs, I wasn’t expecting my V6
ANSI forms to require much in the way of tweaking. Your ANSI form for
Medicare 2ndry’s is not even close to meeting “most requirements”.
Medicare requires providers that have certain claim volumes to file
their claims electronically and their position is that if you are able
to file your primary claims electronically that you should be able to
file your secondary’s electronically as well; if you can’t then you
should find a new software vendor. The only alternative Pam and I
have had is to use Medicare’s software to transmit the secondary
claims, which means manually entering everything related to that claim
into an another software. This is a time consuming task that should
not have to be done when I should be able to use the software I paid
for to transmit the claim with a couple of mouse clicks. Maybe you
would like to provide a reason why many of the other forms that Alta
Point provides are unusable “out of the box”. Print an “Insurance
Billed Summary” so, you can tell me how that form works for you. Why
doesn’t the Insurance Aging report list the patient’s date of service
but lists the billing date instead and why doesn’t it give the
patient’s date of birth…the first thing an insurance company asks for
when they call is for the patient’s ID, date of birth and date of
service. In V7, at least we could save our SQL query results and
create our own reports from Excel. Oh, sure, the Report Builder in
V10 looks like it will create some great looking reports…just as soon
as someone can find the time to read the 100+ page download and figure
out how to BUILD them!!
Finally, Alta Point’s continued lack of communication to its end-users
in general is beyond frustrating. The website has not one mention of
the fact that bugs can be reported via email. Updates that are posted
on the website are not broadcast to end-users via email as you would
expect from a software company that you have invested such a large
amount of money into – but we are tasked with checking the website to
see if there are any updates available. The “bug” in the ANSI form
related to family members in the same batch was apparently not news to
tech support, so why then was it news to me? What about the problems
with the Spotlight feature? If Alta Point is aware of a problem,
wouldn’t it be prudent to make end-users aware of it so steps can be
taken to avoid encountering it or at the very least minimize the
errors as best possible until a fix is released? The same would apply
to the forms and reports. Please point out to me where Alta Point
specifies to the end-user that any form, much less specific forms may
require modifications? Where is the notation that would clarify that
“electronic claims submission” capability does not include secondary
claims to Medicare? These are not rhetorical questions, although I
won’t hold my breath for an answer. After all, Pam & I are the only
ones experiencing any of these problems.