Johathan,
Just a small question. What happens when the patient is no longer
covered by your insurance (and the member ID is no longer in your
eligibility files) but the provider needs to get a denial 835 from you
in order to file the claim with another payer? A front-end rejection
will not be enough. Even duplicate claims are sometimes sent
intentionally as "tracers".
Don't take this wrong, but this is a very tricky issue. For every
opinion, you are going to find a counter-opinion. The debate is
something we can all learn from.
I wish there was "one" soluton to this issue. Even a consensus solution
that satisfies most parties would be great!
Kepa
[EMAIL PROTECTED] wrote:
>
> 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.
