Additional comments. (I've kept Wes's e-mail intact, with my additional
comments inserted). Wes, thanks for the valuable dialogue!
A) Wes wrote: "Agree with (1), map changes. This is pretty close to the
white paper, which recommends testing when software has been changed."
Cy's response: I would still add some language to subtopic 2 of the white
paper, to clarify that changes to files/maps that feed the Clearinghouse
would generate the need for business to business testing. Perhaps it's
sufficient to extend the first sentence of the last paragraph of subtopic 2
to say "However,
IF
1) the Clearinghouse (CH) is creating a custom translation program for
each client, OR
2) the CH's client or client vendor is changing the map for the files
that feed or are fed by the CH
AND
the custom programs create or feed the transactions that are sent to
the Receiver,
THEN testing could be required when the custom programs change. The extent
of testing needed will depend on the extent of the custom program changes
Too many providers who have not focused on HIPAA TCS would read B-to-B
White Paper section 2 as it stands and not realize that they have to worry
about the changes to the interface between their legacy systems and the
clearinghouse(s).
B) Wes continued: "(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"
Cy responds: absolutely agreed - I'd suggest that subtopic 4 of the white
paper be expanded to incorporate this and variation on the comments below.
B) Wes: " 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."
Cy suggests adding: "A prudent provider may also want to test differing
high-dollar-volume contractual arrangements even if they're with one trading
partner (e.g. fee-for-service vs. HMO arrangements, both with the same
payor) since the info systems used by any one payor to administer different
contractual arrangements will vary, as will the changes that must be made to
those systems to achieve HIPAA TCS compliance.
C) Wes continues: " 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."
D) Cy: I'd suggest adding something somewhere in the white paper, for
expectation-setting purposes, regarding the following.
It will be important to avoid beating up on test planners/testers/HIT
vendors/clearinghouses/executives charged with HIPAA TCS testing. During
testing, these brave souls will find many glitches and facilitate fixes.
But they will not find all of the glitches. Testers must be like mature and
well-rooted trees in a hurricane - they are blown around but remain firmly
rooted, and do not break. They may lose a branch or two from the winds
alone. It'll be nice if the folks depending on them keep chain saws out of
sight both during and after the hurricane. :^> - C
Cynthia Korman, CHE, MS, MBA
Principal
Strategic System Solutions, LLC
973 394-9529
[EMAIL PROTECTED]
www.healthcare-systems.com
----- 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
busine
ss
> 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.
>
**********************************************************************
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.
