If you have say four claim adjudication systems that you are routing to then
you must build logic four times to check for invalid member id.. once per
claim adjudication system.. if you have one central place to do this checking
before routing it to the various claim adjudication systems then you have to
only maintain the logic in one central place.
Thanks!
Jonathan Showalter
Omaha NE USA
402-343-3381
[EMAIL PROTECTED]
------------------( Forwarded letter 1 follows )---------------------
Date: Fri, 31 Aug 2001 11:45:03 -0400
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: RE: Front end edits
First, thank you all for your responses.
Jonathan (with respect and regard for your opinions),
I think your use of the term "front-end" is causing unnecessary confusion.
The "front-end" as you describe it, is (to me) the initial edits of the
adjudication system. Member ID and Dup Claims ought to be checked at the
front end... but front end of what? What system right now has the data
available to it to do these edits? The adjudication system.
Additionally I think Rachel spoke to this (edit early as possible) issue
with her "intermediate subsystem".
Regards, Mark
[EMAIL PROTECTED] on 08/31/2001 11:20:00 AM
Please respond to <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: RE: Front end edits
Rachel.... I have read your post on other lists for a couple of years now
and
normally agree with you 110%.. this time I have to respectfully disagree.
I just want to take two edits to illustrate the point. If an electronic
claim
comes in with an invalid member id, why pass it to the subsystem. Why not
allow a piece of software on the "front-end" check each member number on
the
claim. If it is invalid, filter out that claim and return it to the sender
in
a standard transaction (Most people today use some type of report that they
build themselves) noting the error with a standard code which indicates the
member id is invalid. Another very strong candidate for an edit is
duplicate
claim check at the claim level. I have seen this one edit alone save
hundreds
of hours of work by the business users. The folks in the Clearinghouse
industry add this kind of value for their customers..as you already know.
Note that I did not say in the translator...I always use the term
"front-end"
which (to me) is the zone from the com link back to the place where the
message is routed to the destination system. Translators used to really
only
do x12 mapping and could be very clunky to do anything else so many older
systems have COBOL edit programs that run just after the translator
translates
the file and create an edit report that can be sent back to the trading
partner.
In contrast, many of today's translators are now rather robust EAI tools
that
allow developers to work with a kind of 4 GL language rather than a 3 GL
language like COBOL, C, etc. The result is that developers can build
systems
that do much more than transform data from one format to another. They can
now build highly automated centralized routing and editing functions that
clean the messages flowing through the enterprise. This results in data
that
is cleaned to some specific level before allowing it back to the
destination
system where it comes in contact with even more stringent edits. I have
personally used some of these new tools...as I know you have.. and believe
that we built processes in days and weeks that would have taken us weeks to
months to build in a third generation language (3GL) like COBOL.
There was a time when systems allowed users to enter anything they wanted
on a
green screen. At night, a batch program ran and then created an edit
report.
The users then read the report and corrected the errors. If they made a
new
error while trying to fix the old, this process was repeated. Now, we have
systems that edit the data after the users has entered it and gives an
immediate response back. This saves time a prevents some (not all) dirty
data
from entering the system. It is this save basic principle that I believe
needs to be applied to any machine to machine communication.
Thanks!
Jonathan Showalter
Omaha NE USA
402-343-3381
[EMAIL PROTECTED]
------------------( Forwarded letter 1 follows )---------------------
Date: Thu, 30 Aug 2001 18:16:53 -0500
To: [EMAIL PROTECTED]
From: Rachel.Foerster[rachelf]@ix.netcom.com
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: RE: Front end edits
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.
**********************************************************************
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.
