I believe the level of editing you are talking about would fall into the pre-application level edits Jonathan. Those are more detailed level edits than what could be provided for through a 997 or 824 response. I am not disputing the reasoning nor the need, I believe your points are well founded. Other opinions?
> Mark
>
> Mark McLaughlin
> Regulatory Policy Analyst
> McKesson
> 700 Locust St. Suite 500
> Mail stop IADU-7
> Dubuque, IA 52001
> (563) 557-3654 phone
> (563) 557-3334 fax
> [EMAIL PROTECTED]
> Confidentiality Notice: This e-mail message, including any
> attachments, is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies of the original message.
>
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 29, 2001 1:48 PM
To: [EMAIL PROTECTED]
Subject: RE: Front end edits
I have to confess that I have not read the paper for a long time... please
keep that in mind and correct me where I am wrong about the paper
I believe that there are a number of edits that can and should be done on the
"front-end" (what does that mean.. to me it is after the com link but before
the destination system.. for example the claims adj system...is it in the
translator.. maybe.. maybe not...) such as valid member id, valid provider,
duplicate claim, can this sex of patient have these procedures, does this
member have insurance for this time period, etc.
Having the "front-end" do more than file integrity checks is where a lot of
value is added to the process. It filters the data and only lets cleaner data
pass to the destination system. Many people do not do that today because they
feel like the edits in the subsystem will catch it so why do it up front. The
reason is so that the Error Que in the subsystem is as small as possible
because that normally requires a human being to look at them If you pass 100's
or 1000's of claims through to the subsystem that are in error, it requires a
person to look at them and act on them. I have seen 100's (one time I saw an
accident that produced several thousand) of dup claims sneak past the
"front-end" because they did duplicate file checking but not duplicate claim
level checking. If you build a list of edits (it won't be all possible edits)
that you let your "front-end" handle automatically for you then you prevent
the users from having to do it and the provider knows about it right away...
this requires sending back a proprietary report which is why having a
transaction to do it would be great. My concern is that people will read the
statement quoted from the paper and use it as a reason not to deploy edits
anywhere but the destination system. I don't think that is a best practice.
Thanks!
Jonathan Showalter
Omaha NE USA
402-343-3381
[EMAIL PROTECTED]
------------------( Forwarded letter 1 follows )---------------------
Date: Wed, 29 Aug 2001 14:04:42 -0400
To: transactions.wedi.org[transactions]@wedi.org
From: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: RE: Front end edits
Mark, there is going to be an update to the front-end white paper. The
issue of responses is still disputed within X12 itself. Some members
believe that the 997 is enough others believe it is the combination of
the 997 coupled with the 824 that provide for the level of syntax
checking necessary to properly report on pre-application-level
discrepancies. We are going to add the 824 back into the front-end edit
white paper with the caveat that the decision on which of the two ways
mentioned above is actually the right way for the industry to go. Given
that, I believe there will be the capability of reporting back
syntactical problems at the claim level. X12 people, correct me if I am
wrong. The reason we kept application level editing out of this paper is
because in the front end we were only concerned with the file integrity.
Will this file be able to be processed in our application without
creating problems? Getting into application level editing is a much more
diverse and complex discussion and I don't think we want to go there
with this particular paper.
> Mark
>
> Mark McLaughlin
> Regulatory Policy Analyst
> McKesson
> 700 Locust St. Suite 500
> Mail stop IADU-7
> Dubuque, IA 52001
> (563) 557-3654 phone
> (563) 557-3334 fax
> [EMAIL PROTECTED]
> Confidentiality Notice: This e-mail message, including any
> attachments, is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies of the original message.
>
-----Original Message-----
From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
Sent: Wednesday, August 29, 2001 12:46 PM
To: [EMAIL PROTECTED]
Subject: Front end edits
The SNIP white paper on front-end edits refers to different levels of
edits. The paper attempts to classify appropriate use of front-end
edits.
The edits (according to SNIP) fall roughly into 2 broad categories.
X12/IG
and application edits. X12 and IG edits relate to syntax and
implementation guide compliance editing. Application level edits (both
pre
and during adjudication) are not considered appropriate
for front-end edits.
One of the reasons for using standard EDI transactions is to provide
a
layer of
isolation between the transmission of data and the processing of data
by
the
application or adjudication systems. Therefore, front-end edits
should
only
relate to EDI transaction syntax and transaction implementation guide
issues.
Application-level edits should be kept separate and communicated
using
the
appropriate EDI transaction for each application.
Is this view of front-end edits, the consensus of this group?
Assuming front-end edits were extended to include some "application
level"
edits, and given the "draft" status of the 277 (unsolicited claim status
txn), what responses to an edit in an incoming 837 (other than an 835)
are
available at the claim level?
Regards, and thank you,
Mark
**********************************************************************
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.
**********************************************************************
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.
**********************************************************************
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.
**********************************************************************
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.
