The Type of Service is just one example of miss use... here's
another from PA-Medicaid. They require encoded into the loop
2010AA REF02 element this info:
"Description of Loop:
Loop 2000A, Segment PRV, Data Element PRV01 (Page
Number 71) must contain the value 'BI', which is the only
acceptable value for Inpatient claims.
Loop 2010AA contains information about the billing provider.
Using the Loops:
Loop 2000A, Segment PRV, Data Element PRV01 must
contain the value 'BI'. Loop 2010AA, Segment REF, Data
Element REF01 (Page Number 83) must contain the value
'1D', indicating a Medicaid ID Number.
Data Element REF02 must contain the provider information.
Data Element REF02 will be in 'TTPPPPPPP' format, where:
TT is the two-digit Provider Type.
PPPPPPP is the seven-digit Provider MAID Number.
For the 837 Institutional Inpatient claims, the two-digit
Provider Address Code and the one-digit QSB Indicator
(Qualified Small Business) does not apply."
Which... according to their desires this is to be a "1D" value... i.e.
the Medicaid Provider number. Now I dont know about what the
rest may have seen so far... but that looks and reads to me like
multiple values in one element. And this is but one example I offer.
Another is CT-Medicaid is using the loop 2400 DTP qualifier 472
for a Room and Board start date.
Miss use or corruption of element use is becoming more and more
common. And as a vendor... my only recourse is make the system
work or else I dont get paid because my clients does not get paid.
My only hope is that it will over time get better.
BCY
Brian C. Young
Accu-Med Services Inc.
An Omnicare Company
300 TechneCenter
Milford, OH 45150
513.831.1207
-----Original Message-----
From: Stacy Trease [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2003 3:41 PM
To: WEDI SNIP Transactions Workgroup List
Subject: RE: Type of Service still needed?
I have been asked to add this information to lots of areas - all of
which I am extremely leery of implementing past 10/16/03.
One of the proposed "fixes" for this issue was to request of us to
send the TOS in a REF segment in the 2400 loop which the payer has
interpreted as "able to be used at their discretion" - although the
qualifier would really not apply to the information in the segment, so I'm
not sure that's a good idea.
It has also been requested of us to send this info as a line note in
the 2400 loop, but that concerns me because it would override any
possibility of a true line note.
Another request was asking us to send it in the line item control
number REF segment in the 2400 loop, but that's not an option either in my
opinion because payers are required to return this number in the remittance
advice transaction (835) if the providers sends it to them in the 837.
Most commonly, we are being asked to send the TOS in SV106.
Is there really any way for payers to be able to get around
rewriting their adjudication systems if they are currently dependent on type
of service?
Stacy M. Trease
EDI Programmer/Analyst, Gateway EDI Inc.
Co-Chair, MO SNIP TCS Subcommittee
(800) 969-3666 Ext 224
[EMAIL PROTECTED]
---
The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions
on this listserv therefore represent the views of the individual participants, and do
not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If
you wish to receive an official opinion, post your question to the WEDI SNIP Issues
Database at http://snip.wedi.org/tracking/. These listservs should not be used for
commercial marketing purposes or discussion of specific vendor products and services.
They also are not intended to be used as a forum for personal disagreements or
unprofessional communication at any time.
You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED]
To unsubscribe from this list, go to the Subscribe/Unsubscribe form at
http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED]
If you need to unsubscribe but your current email address is not the same as the
address subscribed to the list, please use the Subscribe/Unsubscribe form at
http://subscribe.wedi.org
