Regarding Mike's comment below: "I would have to also
contend that the HIPAA IGs are a subset of X12. If you can't get the X12
right, you're non-compliant, right?. " My understanding is that one CAN
get the X12 right and be out of compliance from a HIPAA perspective.
Specifically, in the HIPAA Implementation Guides, the data element attributes
to the right of the data element names and descriptions are X12; the "usage"
column to the left of the de names/descrips are HIPAA-specific. The
two sometimes contradict, in which case the "usage" column on the left takes
precedence.
For example: 837P IG, p. 172 shows "Claim Filing
Indicator Code" as "O" or Optional from the X12 perspective, but NOT USED
from the HIPAA perspective. That same page shows "Health Care
Service Location Information" as Optional from the X12 perspective, but
REQUIRED from the HIPAA perspective.
To summarize, my understanding is that it's the left hand
column that's the bible when it comes to USAGE (Required/Situational/Not
Used). If anyone believes that to be off base, please advise!
Can the 997 report errors in (HIPAA-specific)
USAGE? Thanks in advance...
----- Original Message -----
Sent: Thursday, April 18, 2002 3:16 PM
Subject: RE: questions on the appropriate way to reply when there
are error in a transaction request
Rachel,
I think I follow what you are
proposing and it makes sense to a point, but I don't totally get it. I
would have to also contend that the HIPAA IGs are a subset of X12. If you
can't get the X12 right, you're non-compliant, right?. You may be able to
distinguish, but what real value is there in doing so?
Also, the large scale translation software that my client has
purchased has HIPAA compliancy checking built in as an optional feature. An
incoming or outgoing transaction will be compliance checked and either pass or
fail. I'm not thoroughly proficient with the process yet, but I do not
believe there is any room for separating X12 compliance from HIPAA compliance.
I also believe that the idea is if the compliance check fails, the transaction
will be rejected with a 997.
And finally, although your scenario with the 824 in the middle
may be correct EDI-wise, isn't a little ironic that the method of reporting
HIPAA non-compliance would be with a non-HIPAA mandated transaction? Since
there is no HIPAA IG, then you would have to negotiate with each trading
partner that you are going to use the 824, and then specifically how it will
be populated, and that leads to details in a companion guide, which leads to
accepting or sending different 824 configurations for different trading
partners... It seems to continue some of the problems that having the industry
standard are supposed to reduce or eliminate. Perhaps the 824 should have been
included in HIPAA, but since it hasn't should we really move to standardize on
it?
I may be just missing some of the big picture. Please help me
out with where the flaws are in my reasoning.
Mike Augustine
Principal, SILC,
Incorporated
-----Original Message-----
From:
Rachel Foerster [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 16, 2002 11:13 PM
To: [EMAIL PROTECTED]
Subject: RE:
questions on the appropriate way to reply when there are
error in a transaction request
Don,
All things being equal (and when does that ever occur!) I
would tend to
agree with you. On the other hand, HIPAA
is especially unique in that there
are federal
economic penalties that apply for covered entities that conduct
non-standard transactions.
Now, we've all heard that HHS/CMS isn't anxious to wield the
economic ax,
but if/when penalties will apply (and I
would contend that legally that
would be either
on/after 10/16/02 or 10/16/03) then there must be a clear,
unambiguous boundary between X12 standards compliance and HIPAA
compliance.
Mixing some HIPAA "syntax" into the 997 does not give either
the receiver,
which applies the edits, nor the
originator, which created the non-complying
transaction, a clear statement of whether the transaction fails
X12
compliance or HIPAA compliance. I can argue that
X12 non-compliance would
not subject the covered
entity to any federal penalties, but most certainly
HIPAA non-compliance would.
It's for these reasons that I continue to argue strongly for
keeping the
boundary clear and unequivocal. If we
don't, the lawyers will have a
wonderful day in court
when some of this gets there....and I would bet a
day's consulting fee that it will....sooner or later.
If this gets "mushed" together (that's a technical term!!!)
sorting it out
becomes quite costly. Why not bite the
bullet now, develop the necessary
enabling functions
in the EDI management systems and move on. As a former
software developer I could even see where it could be a strong
competitive
advantage for an EDI management system's
vendor to offer a two-pass
validation totally within
the EDI interpretation/generation function,
automatically applying two maps with the first one being vanilla
X12
compliance and the second HIPAA guide compliance.
This is not rocket science
program design nor
logic.....it's actually not that much different from the
old two-pass code compilers in the old days. To me, this would be
a
no-brainer added new HIPAA feature that could blow
my competitors away....if
I was an EDI management
system developer, that is.
Rachel
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax:
847-872-6860
http://www.rfa-edi.com
**********************************************************************
To be removed from this list, send a message to:
[EMAIL PROTECTED]
Please note that it may take up to 72 hours
to process your request.
==================
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/.
Posting of
advertisements or other commercial use of this listserv is specifically
prohibited.
**********************************************************************
To be removed from this list, send a message to:
[EMAIL PROTECTED]
Please note that it may take up to 72 hours
to process your request.
=====================================================
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/.
Posting of
advertisements or other commercial use of this listserv is specifically
prohibited.
