Mark,
You raise extremely valid points regarding where various types of edits
should be performed: within the EDI management system or in the application
system, and there are arguments pro and con. As a general rule I advise my
clients not to bring a large number of application edits into an EDI system
based on the principle of functional isolation. The other issue, as you've
identified, is when you bring many of the application edits into the EDI
management system, there is no real good way to notify the originator of
validation errors, etc.
The EDI management system as a matter of course should always validate and
report on any X12 syntax standards violations. But how do you effectively
report business rules, IG validation, and other edit failures directly out
of the EDI management system. You really can't. It's for this reason that
over the last 20 years the X12 Committee has created many transactions that
are in effect the turn-around transaction for a received transaction, for
example 850/855, 860/865. On the other hand, there are many transactions
that do not have a paired turn-around transaction, e.g., 810, 845, 867, 834
and so on and its for these that the 824 has played a useful role.
So what's the appropriate solution? My personal opinion is that to try to
move a substantial number of application edits into the EDI management
system will ultimately cause more problems than it will solve. For one
thing, I feel that if you take this course you then have the EDI management
system and the application system much too tightly coupled, thereby
increasing the support and maintenance burden and also making it extremely
costly just to bring in a new system. I'd much prefer independence of
function and modularity so that either system can be replaced with minimal
impact to the other.
There are two other options: 1) - keep as much of the application edits
within the application system itself and report out of that system any edit
failures, using either appropriate EDI transactions if available or other
mechanisms, such as secure email messages, secure web form access, etc. or
2) - develop an intermediate subsystem architecturally sitting between the
EDI management system and the application system in order to pre-validate
data going in to the application system. I've been part of design and
development teams for major systems well over 20 years ago that took this
architecture approach and in my opinion it was a far superior approach than
moving pre-validation into the EDI management system.
Food for thought.....
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 <http://www.rfa-edi.com>
-----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 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.
**********************************************************************
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.
