-----Original Message-----
From: McLaughlin, Mark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 30, 2001 4:00 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Front end edits
Mark, What defines a front-end edit is one of the open items that this white paper asks to be resolved. In my mind a front-end edit as discussed in the paper would be a finite set of edits with standardized responses pertaining to the syntax and file structure of the file (see the matrix.) This finite set of standardized edits and responses still needs to be developed but wouldn't it be nice to give your systems the ability to auto-process responses because they are standardized? Pre-application level edits (i.e. IG external code set compliance) and adjudication, or application level edits would not be moved to the front-end. As you state, that would only muddy the water and you would not be able to have standardized front-end editing or reporting of responses.
> 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: Thursday, August 30, 2001 2:38 PM
To: [EMAIL PROTECTED]
Subject: RE: Front end edits
Jonathan, Mark (McLaughlin), Thanks for your responses.
My original question concerning FE edits was the result of the following
kinds of "musings" on my part. Your thoughts would be appreciated.What defines a front-end edit?
Is it simply an edit that occurs prior to entry into a formal adjudication
system?
Is it only X12 syntax and IG compliance editing? External codeset IG
compliance too?Is an adjudication edit allowed? Only certain forms?
May it be as low as the individual claim level? Line level?Does relocating an adjudication edit from within the adjudication system to
the front end (X12 translator), change the edit from an adjudication edit
into a front-end edit? (A rose by another name?)Do (should) front-end edits differ (other than in their location) from
adjudication edits? (apples and apples, or are they apples and oranges?)Should changing the location where the edit is performed, change the
response to the edit?.
i.e. If an adjudication edit normally results in an 835 reject, should the
response to the same edit (when relocated to the front end of the
adjudication system) be any different?Does moving the edit "up" also require we move "up" the transaction
response processing (835, 277, etc)It seems to me that EDI and adjudication are two distinct processes. Front
end edits, depending on what they are, may muddy the boundaries. I
appreciate any help sorting this out.Regards, Mark
"McLaughlin, Mark" <[EMAIL PROTECTED]> on 08/29/2001 03:25:31 PM
Please respond to <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Front end edits
RE: Front end edits
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 paperI 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 editsMark, 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 guideissues.
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 statustxn), 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.
**********************************************************************
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.
