Agree with (1), map changes. This is pretty close to the white paper, which
recommends testing when software has been changed.

(2) and (3) are problematical. There is no doubt that the best assurance
would be achieved by full-loop testing of every healthcare organization with
all of its trading partners. But that represents an awful lot of
combinations of providers and payers. The real goal for HIPAA implementation
has to be to define "good enough" testing that can be accomplished by the
deadline. One possible definition of "good enough" is that the error rates
are no more than is experienced with current EDI solutions. After the
initial rush to implementation is complete, healthcare organizations could
raise that bar to achieve some of the business benefits imputed to HIPAA.

It seems to me that (2), the business perspective, depends on the value that
the clearinghouse says it adds. If it does not offer full claims-scrubbing
capability, including the business edits that are associated with each line
of business for each payer that it services, then there is no real
alternative except to do full-loop testing. If it does, then the question
remains how accurate is its modeling of the business edits of the payers and
will it accept liability if claims are massively delayed or abandoned
because of its defects. There is also the issue of testing software that
represents unique contract arrangements between a specific provider and
payer.

A prudent provider would probably want full-loop testing with its
high-dollar-volume trading partners, but might be willing to forego it for
the 80 percent of its trading partners that represent twenty percent of its
dollar volume (or the seventy that represents 10 percent, or whatever). It
can still find and correct low-volume problems when claims are rejected or
wrongly denied in production.

Health plans will want to select the trading partners with which they do
full-loop testing based on similar considerations. They will decide based on
their confidence in a specific clearinghouse, the dollar volume of specific
providers (and hence their potential liability in case of a huge,
unjustified increase in rejections or denials), and the existence of
specific contractual provisions with the providers.

One additional comment with respect to (3). There are limits on the
assurance that is created by having a vendor test its system with a
clearinghouse or trading partner. Most patient accounting systems, for
example, are highly configured to the specifics of the provider's
organization. Vendor-testing can help to ensure that the basic software is
operational, and to handle the generic code set changes such as
claims-adjustment reason codes. But it cannot replace testing of the
software as configured with the clearinghouse or ultimate trading partner.



-----Original Message-----
From: Cynthia Korman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 21, 2002 7:50 PM
To: [EMAIL PROTECTED]
Subject: Fw: Full-loop vs Trading Partner Testing


 Business-to-business White Paper V2 subtopic 2 should be revised.  After
clearinghouse software has been proven to successfully process a particular
line of business, provider-to-payer or payer-to-provider testing would still
be required in many instances, including the following:
 1) when clearinghouse files come from "upstream" systems or go to
"downstream" systems and there's a new or significantly-changed map
associating the up- or downstream legacy files to the clearinghouse files
2) to confirm that the content of transactions is accurate from the business
perspective; for example
    a) to confirm that, on a particular claim, the different providers
(billing, pay-to, rendering, referring, attending etc.) are properly passed
through the clearinghouse and into the target system of the trading partner;
where payors use referral data to analyze provider practice patterns, this
can become especially of concern...
    b) to confirm that, for PPO claims, contracted disounts are not being
applied twice because of an error in the way billing data is picked up by
the clearinghouse
NOTE: a and b are only examples; what is important to test will vary based
on the character of each covered  entity.
3) When HIPAA-ready legacy systems are newly installed and those systems
have required significant change, for example to accomodate
newly-standardized claim adjustment reason codes  (Hopefully the legacy
system vendors will be open regarding the extent of changes to accommodate
HIPAA)

 At least one of the above items 1, 2, and 3 applies for just about every
covered entity,  right?  So trading partner testing will be more of a rule
than an exception - it will require less manpower to test as more partners
are tested.  But it'd be foolhardy for trading partners to not do any
trading partner-to-trading partner testing...

 Cynthia Korman, Principal
 Strategic System Solutions, LLC
 973 394-9529
 [EMAIL PROTECTED]
 www.healthcare-systems.com
 ----- Original Message -----
> From: "Rishel,Wes" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, May 21, 2002 5:05 PM
> Subject: Full-loop vs Trading Partner Testing
>
>
> > My reading of subtopic 2 in the Business to Business Transaction Set
> Testing
> > Version 2 white paper is that there is no need for provider-to-payer
> testing
> > where a clearinghouse is involved provided that the clearinghouse is not
> > using modified software to handle the provider and has previously
> > demonstrated that it can handle the lines of business that will be
> proffered
> > by the provider.
> >
> > Is that a correct interpretation? Is it pretty much the consensus?
> >
> > **********************************************************************
> > 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.

Reply via email to