Rachel,
You make a great case, and very much in line with what the white paper
describes concerning the role of EDI as an isolation layer in front of
the application.
We are trying to draw a line in the sand for the Claredi test system,
and I am going to try to describe it here as this may help others
determine a course. We have divided our edits into two categories:
"HIPAA Requirements" and "Business Rules and Warnings". The HIPAA
requirements are requirements of the Implementation guide. Some are
explicit, some are not explicit in the guide. Let me give some
examples.
HIPAA Requirements examples: The guides are X12, so the transactions
must be fully compliant with the X12 syntax as a starting point. Very
explicit requirement. The IGs have other syntactical requirements for
repeat counts, used segments and elements, etc. Very explicit. The CR1
segment is required on all claims involving ambulance services (as
determined by the HCPCS code). That is an explicit requirement as long
as everybody agrees on what is an ambulance service. Secondary
Identification Numbers in general say something like "Required if
additional identification numbers other than the primary identification
number in NM108/09 in this loop are necessary..." We understand the
"other than the primary" to mean that you cannot send the Federal Tax ID
in both the NM108/09 and REF01/02. That is a not very explicit
requirement, but it is in the implementation guide nonetheless.
The "Business Rules and Warnings" are not expressed in the IGs. For
example, the IG does not say that the patient's date of death cannot be
before the date of birth, or that the date of service should be before
the date of the claim. These are standard edits that a lot of the
clearinghouses and payers implement in their EDI system or their
front-end. They are not required by HIPAA, but are part of the basic
healthcare integrity testing. But these vary greatly among trading
partners, and in fact some are so inconsistent that we call them
"warnings" instead of business rules.
The biggest difference is that the IGs state specific requirements that
are well known and predictable. Since they are predictable they could
be implemented by all trading partners in the same way. The "business
rules and warnings" are not required in the IG itself, and some of them
are not as predictable.
Since some of the implementers will best benefit from a "lax"
implementation, it is not necessarily true that all implementers must
implement all the predictable and explicit rules in the guide. For
example, it will be very acceptable to some trading partners (payers,
clearinghouses) to accept claims that have the same Tax ID both in the
NM1 and the REF segments. No real harm done here. Better to be relaxed
on this than to reject the claim. But the providers should build their
translator tables with this issue in mind, just in case, and not send
the Tax ID in both places.
So, probably the "front-end" is where all the IG specific rules go.
Then the additional business rules could be in the subsequent edits.
But even in this area, there is flexibility, and different ways to
approach it.
There are two opposite schools of thought: One says to make the
front-end as tight as possible and put as many rules in it as possible,
so only clean data comes through. This cuts down on the cost. The other
school of thought is to make the front-end as lax as possible, so the
data can be captured and something intelligent done with it rather than
just rejecting it. This drives cost up. As usual, there is a balance
somewhere between these two positions.
Then there is the difference of what you do in production as opposed to
what you do during the test phase. It may be OK to have a very strict
set of edits during the test phase in order to determine exactly where
the errors are. Then the production edits could be more lax, and
actually let data through that would have rejected during the test
phase. As long as the error ratio is low, it can be corrected without a
huge expense. At least a very strict test front-end lets you identify
the problem areas and let you make an informed decision on what to do.
Better to know where the problems are than to blindly accept garbage
into production.
So, in the Claredi test system we have built a very complete set of
HIPAA rules that test the IG requirements, a very large set of business
rules and warnings for things that are not in the IG, a method for the
transaction receiver to define what is it that they actually "need", and
a sophisticated proprietary method to match the EDI capabilities of the
submitter with the "needs" of the receiver.
We do not expect anybody to "need" every single HIPAA requirement and
every single business rule in a production system. Much less to build
every one of those in their front-end. They would get very little data
through such a system.
But, for somebody putting together the EDI aspects of HIPAA, there has
to be some predictable way to determine whether my transactions will be
acceptable to my trading partners, and whether my trading partners'
transactions will be acceptable to me. And I would like to do this
without having to repeatedly test with each of my trading partners. And
some of my trading partners may be very strict about HIPAA compliance
while other trading partners may be very lax about it.
Why am I saying all this? Because the key is "predictability". If we
can predict the requirements and capabilities of the trading partners,
we can then build systems that will operate in a predictable way, thus
reduce the cost for all. At the end it does not matter as much whether
the edit is built in the front-end or the back-end as long as the
behavior is predictable to both trading partners. We know how to write
programs to solve predictable problems. It is the unpredictability and
inconsistency of the edits in use today that causes problems.
Just my opinion.
Kepa
Rachel Foerster wrote:
>
> 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.
