--------Original Message-----
From: Marcallee Jackson [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 12, 2003 3:55 AM
To: WEDI SNIP Testing Subworkgroup List
Subject: RE: Meeting Minutes - 5/22/2003 -- who pays cost of testingWe all agree that completing compliance testing prior to conducting trading partner testing is a good thing but working with a TPT who issues a certificate at the end is not the only way to conduct that testing. We should not assume that just because an entity does not conduct their testing through a TPT they're testing has not been sufficient.
We've learned from experience that TPT compliance testing and certification is not portable. We hear stories on a regular basis of providers who test with a TPT and then run into compliance issues when they begin testing with trading partners. There are many of us working toward normalizing compliance validation but the industry isn't there yet. Since the validation edits of TPTs are constantly being refined, even trading partners that certify with the same TPT may run into compliance issues when they test with each other. That's not to say that TPT isn't a legitimate tool but that it is only one of many and has not been proven superior to any other.
It seems reasonable for every entity to expect a certain level of readiness on the part of their trading partners. An entity always has a choice of whether or not to continue testing if it's discovered that a partner has failed to meet a baseline of compliance. By establishing and publishing a policy that sets expectations in terms of readiness and sets consequences for trading partners who begin testing without that level of readiness (like submitters who fail types 1 & 2 move to the back of the line), payers can help control their costs. Payers can CHOOSE to require TPT, they can CHOOSE to use a fee-for-testing TPT or a free TPT, the can CHOOSE to work with partners who have no real level of readiness, they can CHOOSE to restrict testing to only those partners who are ready and they can CHOOSE a model for testing that allows submitters to test all they want without increasing the payer's cost. The point is they have a CHOICE. IF a payer mandates TPT, the provider has no choice.
I'll say again, I think our current answer could take us to places most of us do not want to go . . . Let's say one of the largest provider associations endorses a TPT vendor under a revenue share model that pays them a portion of the fees their members pay to the TPT vendor (this revenue share model is not made known to the public in general or the association's members.) The endorsement is widely touted and brings tremendous respect to the vendor's model which is said to be the one that can save the day. The association and the vendor begin to educate their members on this model (and only this model) driving their members to the TPT. Though many respond, it's not the volume they'd been hoping for.
So next, the association and TPT vendor, together, collaborate with state insurance commissioners and health plans to establish statewide testing programs that examine and endorse only the TPT model. Under this model providers pay for companion guide testing and payers outsource that testing at little if any cost to them. The vendor acts as the subject matter expert and guides the group away from the analysis of other models that might reduce the cost to providers and the healthcare industry overall, but also minimize the revenue it would earn and introduce greater competition. These players (TPT, association and payer) all have a financial stake in putting the focus on a TPT model where costs shift to the provider.
To further maximize their revenue, the TPT also offers a financial incentive thru a revenue share with plans that agree to mandate TPT and most do. The rest mandate but due to ethical issues, do not enter into the revenue share agreement. This way the vendor is assured maximum revenue, eliminates competition and further mainstreams the TPT model. All the players sign confidentiality agreements and the trading partners are none the wiser.
Assuming there is a total of 2,000 trading partners to be tested in the state and these entities pay on average $1,000 a piece for the test, the trading partners could pay over $2,000,000 to the vendor in the first year alone. The association gets its share of that revenue along with the payers and the payers get the tremendous added benefit of outsourced testing.
Think this all sounds like paranoia or the green eyed monster? It's not. The association's endorsement and revenue share agreement already exists. One of the association's state chapters and a TPT vendor have collaborated with payers on companion guides and a TPT model which is being aggressively rolled out to providers. Some payers have indicated they will mandate or are considering mandating TPT certification. What stops this from becoming a real business model folks? How do you know it isn't real already?
Is SNIP about to draft a response that would say that a certain class of entity (associations, TPT vendors and payers) can set the cost and method for testing for the rest of us while also forcing us to pay all the costs? Are we supporting a HIPAA tax for providers?
I hope not but given our history of strong support for TPT, I might not be surprised . . .
Marcallee Jackson
Director, Healthcare Solutions
Edifecs, Inc
Office (425) 452-0632
Cell: (714) 865-5059
[EMAIL PROTECTED]-----Original Message-----
From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 09, 2003 9:37 PM
To: WEDI Business Issues Subworkgroup List
Subject: Re: Meeting Minutes - 5/22/2003 -- who pays cost of testingThis is an interesting thread and I hope that throwing in my $.02 will not
generate too many flames.There are several issues to consider.
One issue is the difference between trading partner testing and EDI compliance
testing. The SNIP white paper recommends that EDI compliance testing be
completed before trading partner testing starts. Doing so is for the benefit
of the covered entity that is testing its own EDI compliance, and once EDI
compliance testing is complete, further testing with trading partners is much
simplified.When using trading partner testing in lieu of EDI compliance testing you are
making a choice. Trading partner testing is, by definition, trading partner
specific. Most likely it is not portable from one trading partner to
another. So, a provider that chooses to use trading partner testing with
payers, without having completed EDI compliance testing first, is likely to
have to repeat the testing from scratch with each payer.Of course, if the provider's EDI compliance testing also includes a component
of testing against multiple simultaneous payer specific EDI companion guides
under one testing umbrella, instead of having to repeat the entire EDI
testing with each trading partner from scratch, then they get the best of
both worlds. But that train of though would deviate from the core of the
discussion, so I will focus back on the problem.The second issue is cost shifting. The cost shifting of the EDI testing
occurs in both directions. Let me explain...In some cases the providers expect the payers to provide some sort of "free"
EDI testing as they have done in the past. In other cases the providers want
to make sure their EDI systems are compliant independent of one specific
payer. In some cases the payers desire to provide a "free" EDI testing
service to their providers. In other cases the payer does not want to pay
for the provider's EDI compliance testing. In some cases the payers do not
want to become the EDI trainers for the providers. In some cases they do.
In some cases the providers are sending test files that do not meet basic X12
syntax requirements. In other cases their files are very clean and doing
further payer testing is simple, easy, and effective. In some cases the
providers expect the payers to tell them what to do and how to fix the EDI
problems. In some cases the payers do not have the resources to do this. In
other cases they do. In some cases the payer specifies one payer specific
testing service and pays for it. In other cases the payer specifies one EDI
compliance verification service before starting the trading partner testing
and does not pay for it. In other cases the payer specifies more than one
EDI testing or compliance service and may or may not pay for it. In some
cases the provider prefers to test with multiple payers from scratch. In
other cases the provider prefers compliance testing prior to trading partner
testing. In some cases the provider can spell HIPAA, WEDI, SNIP and X12. In
other cases the provider cannot spell them.As you can tell from my tongue in cheek list, there are many tensions and a
multitude of reasons why the cost shifting is happening. Cost shifting is,
in theory, unfair. Some times the cost is shifted to the payer. Other times
it is shifted to the provider. If there was no cost shifting, everybody
would pay the share of the resources they consume. But reality is, cost
shifting is part of the nature of business. Market forces drive it.Take the clearinghouse as an example. Today, most clearinghouses are looking
at being Business Associates of both providers and payers. But, are the
costs allocated proportionately to the services being rendered for each
party? And, I don't mean to pick on clearinghouses. Ask a smoker and a
non-smoker what they think about the cigarette taxes and you will get two
different answers. Cost shifting is common business practice in free
markets.Having said all this, is SNIP about to put a response in the DSMO server
saying that cost shifting in a certain direction is more or less fair than in
another direction? Is SNIP about to stick its neck and say that a certain
kind of cost shifting is not allowed? Or, is SNIP going to say that a
certain class of trading partner (e.g. payer) should bear the burden of
testing all the other (e.g. provider) trading partners?I doubt it.
But, never say never...
Kepa Zubeldia
Claredi
On Monday 09 June 2003 09:41 pm, Marcallee Jackson wrote:
>
> I'm going to cross-post this message to the BI SWG because this question
> involves issues that are related to both testing and business decisions.
> For those who are new to this message string, the topic being discussed was
> submitted to the Issues Database. The question is, can a payer require an
> entity to test and certify through a particular third party tester (TPT)
> (against 1 - 6 HIPAA guidelines and/or their companion guides) and if so,
> are there any caveats? I've copied the original question at the bottom of
> this message along with some of the discussion that took place within the
> Testing SWG.
>
> In the interest of disclosure, I'll say that I was the individual who
> submitted this question to the Issues Database. Thank you to the Testing
> SWG for their initial discussion and response. When I posted this
> question, I was most interested in the caveats. I think for the most part,
> we're all in agreement that a payer can require that a provider test and
> certify with a TPT of the payer's choice, but I think there maybe certain
> conditions to that. Chiefly, can the payer allow the provider to incur the
> cost for that testing certification?
>
> I've discussed this issue with many people now and I'd like to share some of
> the main points that seem to come up:
>
> 1. Transaction testing is just one of the tasks in the implementation
> process. Completing trading partner agreements and testing communications
> would be two others and there are likely to be many more as well. If your
> answer to the question at hand is that yes, a payer can use a TPT(or TPTs)
> of their choice for testing and require (or not be concerned) that the
> provider pay for that certification, then my question to you is - can they
> also outsource other aspects of the implementation process and have the
> provider pay for that as well?
>
> If one of the vendors who has a solution for trading partner agreements and
> enrollment forms, contracts with a payer to manage the process of completing
> those forms on the payer's behalf and the payer requires that the provider
> now go to that vendor and complete those forms before testing, can they then
> charge the provider for using that service? If the payer couldn't manage
> the volume of communications testing, could they outsource that too and make
> the provider pay to test? No? Then why is transaction testing any
> different? Many different options exist for testing, both for the provider
> and payer. Why should the payer be allowed to force the provider to use
> their solution and also pay for it?
>
> 2. A health plan can contract with a clearinghouse to receive standard
> transactions on its behalf but cannot cause the provider to incur fees or
> costs for that decision. Presumably this requirement is meant to prevent
> payers from shifting the cost (or a portion of the cost) of using a
> clearinghouse from themselves over to the provider. Why would the authors
> of the Final Rule prevent the payer from charging for the clearinghouse but
> permit the payer to outsource testing to a third party and then allow them
> to shift the cost of that to the provider?
>
> 3. Often when answering this question, folks are looking at the third party
> testing market and solutions as they exist today and not projecting into the
> future. When they think of this situation they seem to be thinking that the
> provider would only have to test with one TPT. But providers who send
> direct might test with many payers. What if a provider has 20 payers, 15
> of which require TPT certification and between those 15 the provider had to
> test with 7 different TPT vendors who charged fees ranging from $50 - $500?
>
>
> 4. Another thing folks seem to have in mind is that the cost would be one
> time? What about when a provider initiates new transactions or new
> connections? Might they have to pay again each time?
>
> I do not believe the authors of the TCS Final Rule intended to allow the
> payer to outsource the tasks involved in exchanging standard transactions
> and then shift the cost of that outsourcing over to the provider simply
> because the vendor they've outsourced to doesn't meet the definition of a
> clearinghouse. In fact, if the entity used for TPT was also a clearinghouse
> the fee for testing would not be allowed.
>
> Before we draft I final response to this issue, I'd like to encourage more
> discussion.
>
> Thanks for you attention to the matter.
>
>
> Marcallee Jackson
> Director, Healthcare Solutions
> Edifecs, Inc.
> (714)865-5059
> www.edifecs.com
> www.hipaadesk.com
>
>
>
> From the Testing SWG Minutes:
>
>
> 2) Issue from Issues Database:
>
> The following issue was assigned to the Testing SWG and was discussed during
> the meeting -
>
> Can a health plan require that an entity certify with a third party testing
> service in order for the entity to begin testing with a plan. If so, can the
> health plan require that certification be obtained from a particular third
> party and if so, any caveats to that? Along these same lines, can a health
> plan require that an entity certify against its companion guidelines, with a
> third party testing service in order for the entity to begin testing with a
> plan. If so, can the health plan require that certification be obtained from
> a particular third party? Any caveats to these two items?
>
> This issue created a lot of discussion. The HIPAA legislation or ASCA does
> not mention certification or verification so the issue is pretty much left
> up to the formation of a best practice. The group agreed that requiring a
> third party validation/certification would need to be detailed in a Trading
> Partner Agreement (TPA). If a health plan does require this type of
> activity, they do have the right to require
> a particular third party for this purpose because certain business level
> editing would also probably be built into the software used by the third
> party that was specific to that particular payer. Not all third party
> vendors would have that specific editing functionality because they had not
> been working hand in hand with that specific health plan. The bottom line
> is that validation and/or certification is not required by the HIPAA
> legislation although it is recommended by the WEDI Testing white papers.
> Any requirement that is outside of the scope of the HIPAA legislation would
> need to be documented and agreed upon in a Trading Partner agreement.
>
>
> -----Original Message-----
> From: Christopher Feahr [mailto:[EMAIL PROTECTED]]
> ubject: Re: Meeting Minutes - 5/22/2003 -- cost of testing
>
> Dear Testing Group,
> As a provider, I would consider "testing" and any required
> "certification" to be components of the [necessary] process of "setting
> up a connection" with my trading partner. The term "enrollment" that is
> often used by payers or "communities" connotes the true, lop-sided
> nature of the process, in which the provider "asks" to be "enrolled" in
> the community and expects to be required to jump through ALL of that
> community's enrollment hoops... including any testing or certification
> hoops. All of this hoop-jumping is going to cost the provider $ and
> would simply be part of his cost of setting up and maintaining each
> trading partner relationship. I believe that HIPAA is silent on the
> specific elements of a TP-agreement and is also silent on how the costs
> [to both parties] of setting it up should be divided.
>
> I would not expect many provider complaints about enrollment costs,
> however... because only the most sophisticated providers will even
> attempt to manage direct EDI connections. Smaller providers who are not
> using DDE or dropping to paper will likely be enrolling with ONE
> clearinghouse... effectively pushing their "testing and certification"
> concerns onto the CH. If we do experience such provider complaints,
> they will be handled case-by-case anyway. So I think it's fine for the
> Testing white paper to remain silent on the ideal/fairest way to parse
> enrollment costs.
>
>
> ___________________
> From: "John Singer" <[EMAIL PROTECTED]>
> To: "WEDI SNIP Testing Subworkgroup List" <[EMAIL PROTECTED]>
>
>
> > Actually I believe Ellen is correct. A payer cannot pass the cost of
> testing onto the provider. If a payer designates a testing agency then
> the payer must also pay for this especially if the testing agency is
> charging for the testing of payer companion guides. Is there an attorney
> on this listserve that has reviewed the regulation? I remember reading
> somewhere that payers cannot pass costs to providers and clearinghouses.
> >
> > John
> >
> > --
> >
> > --------- Original Message ---------
> >
> > DATE: Wed, 28 May 2003 18:38:52
> > From: "Falbowski, Ellen" <[EMAIL PROTECTED]>
> > >
> > >I have a couple of comments on these minutes.
> > >1) Regarding the response to the testing issue submitted to the
> issues > >database, I think that if Party A requires Party B to use a
> particular
> > >third party's software for validation, Party A should pick up Party
> B's
> > >costs, if any, of using that third party's software. However, if
> Party
> > >A allows Party B to choose the validation software, Party A would not
> > >need to pay for the validation costs.
> > >
> > >2) X12N/TG2/SPWG2 (the work group that created the 824 Implementation
> > >Guide Reporting IG) was notified at the February X12 meeting that
> > >X12N/TG3 would be drafting a Type 1 Technical Report on which
> responses
> > >to use when. Not sure of the status of that work.
> > >
> > >-----Original Message-----
> > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > >Sent: Wednesday, May 28, 2003 3:14 PM
> > >
> > >Attendees:
> > >
> > >Brandi Wyatt - EDIFECS
> > >Ed Hafner - Foresight
> > >Miriam Paramore - PCI
> > >Kerry - EPIC Systems
> > >Lou Oliver - Advent Software
> > >Patrick Edwards - Arkansas Blue Cross
> > >Tim Collins - Kentucky Medicaid
> > >Dave Frankel - EDIFEG
> > >Suzan Ryder - Empire Blue Cross Blue Shield
> > >John Lilleston - Verizon
> > >
> > >Agenda Items:
> > >
> > >1) Review of Washington D.C. Conference:
> > >
> > > Ed Hafner reported that the Testing breakout session went very
> > >well. There were over 100 people in the room for the session and over
> 40
> > >surveys were completed and returned to Ed after the session. Brandi
> > >also said she overheard several positive comments about the session
> > >after it was over. Many people liked that we were presenting actual
> > >testing experiences and statistics but some felt that there was not
> > >enough time provided in the session to allow the attendees to digest
> the
> > >information and ask questions.
> > >
> > >2) Issue from Issues Database:
> > >
> > > The following issue was assigned to the Testing SWG and was
> > >discussed during the meeting -
> > >
> > > Can a health plan require that an entity
> > > certify with a third party testing service
> > > in order for the entity to begin testing
> > > with a plan. If so, can the health plan
> > > require that certification be obtained from
> > > a particular third party and if so, any
> > > caveats to that? Along these same lines, can
> > > a health plan require that an entity certify
> > > against its companion guidelines, with a
> > > third party testing service in order for the
> > > entity to begin testing with a plan. If so,
> > > can the health plan require that
> > > certification be obtained from a particular
> > > third party? Any caveats to these two items?
> > >
> > > This issue created a lot of discussion. The HIPAA legislation
> or
> > >ASCA does not mention certification or verification so the issue is
> > >pretty much left up to the formation of a best practice. The group
> > >agreed that requiring a third party validation/certification would
> need
> > >to be detailed in a Trading Partner Agreement (TPA). If a health
> plan
> > >does require this type of activity, they do have the right to require
> a
> > >particular third party for this purpose because certain business
> level
> > >editing would also probably be built into the software used by the
> third
> > >party that was specific to that particular payer. Not all third
> party
> > >vendors would have that specific editing functionality because they
> had
> > >not been working hand in hand with that specific health plan. The
> > >bottom line is that validation and/or certification is not required
> by
> > >the HIPAA legislation although it is recommended by the WEDI Testing
> > >white papers. Any requirement that is outside of the scope of the
> HIPAA
> > >legislation would need to be documented and agreed upon in a Trading
> > >Partner agreement.
> > >
> > >Please review the verbiage above as we would like to draft a final
> > >response to this issue during the next meeting and enter it on the
> SNIP
> > >website.
> > >
> > >4) Next Steps for Testing SWG:
> > >
> > > Sue and John had discussed a couple of topics that the Testing
> SWG
> > >may want to undertake as our next steps. One idea was to develop a
> > >white
> > >paper as to business scenarios when the 997, TA1, 824, etc.
> transactions
> > >would be used. Also, document the advantages and disadvantages of
> using
> > >standard transactions versus proprietary ones until the standards are
> > >mandated.
> > >
> > >Brandi Wyatt also came up with another testing idea and will document
> > >that idea to the group prior to the next meeting. We will devote an
> > >agenda item to this subject for the next meeting and try to make some
> > >decisions as a group.
> > >
> > >Thanks!!
> > >
> > >____________________________________________
> > >John D. Lilleston
> > >Section Manager - Healthcare EDI
> > >Verizon Information Technologies, Inc.
> > >Phone - (813)979-3225
> > >Fax - (813)978-5570
> > >[EMAIL PROTECTED]
> > >www.VerizonIT.com
> > >____________________________________________
---
The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time.You are currently subscribed to wedi-business as: [EMAIL PROTECTED]
To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED]If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org.
---
The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time.
You are currently subscribed to wedi-testing as: [EMAIL PROTECTED]
To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED]
If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time.
You are currently subscribed to wedi-testing as: [EMAIL PROTECTED]
To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED]
If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
