Kim, If I understand your comment correctly, I believe you have nailed one of the key challenge areas. The repository requirements and specific data elements being discussed for the CPP repository will attempt to address these one-many relationships. I suspect that routing messages to providers will be a much simpler, one address-to-one provider proposition... at least initially. Sending to payors, however, will require that provider EDI systems maintain a fairly elaborate local "partner profile" record... based on individual transaction "readiness", real-time vs. batch requirements, etc.
We must keep in mind that the apparent lack of "demand" for this admittedly secondary HIPAA solution is the direct result of a lack of small-provider acceptance of the primary HIPAA problem: enabling themselves to produce standard messages. If you give a mouse an EDI-cookie, he won't ask you for a glass of milk... he'll ask, "Where the hell am I supposed to send this?" Regards, Chris At 01:58 PM 6/14/02 -0400, Kim Peters wrote: >The problem I see going forward is one of the many to many relationships >which will have to be maintained by payers and providers as well as >clearinghouses for the id's to connect the relationships. One provider will >have to maintain one to many id's for each payer depending on how that >payer determines to set up his communication process. If we don't have a >process where there is one unique identifier for an entity, then a payer >may set up one id for the online process and another id for the batch >process so they can direct the transactions down different pipelines. They >could even go so far as to assign different id's for each transaction >within the environment (online vs batch). > >This is the main problem I feel would be addressed in this solution. It may >not address HIPAA compliance in the near term, but if it is not practical >to do electronic processing it is much less likely you will get the smaller >submitters to comply. > >Kim > > > > > "Rachel > > Foerster" To: "'Christopher J. > Feahr, OD'" <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED] "'WEDi SNIP 4 \(E-mail > 3\)'" <[EMAIL PROTECTED]> > om.com> cc: "'David Kibbe'" > <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]>, "'Ken Wood'" > 06/13/2002 > 01:53 <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > PM Subject: RE: HIPAA > Privacy, Security and the Intersection with > Please > respond EDI > > to > rachelf > > > > > > > > > > > >Chris, > >I agree that you've identified some issues here, but let's look at things >rationally as far as getting "compliant" with the HIPAA EDI requirements is >concerned by 10/16/03: > >1. The vast majority of physicians and dare I say dentists and other small >providers use a practice management system, most often licensed by a >commercial PMS vendor > >2. The small provider is at the mercy of their PMS vendor for HIPAA >transactions > >3. Most PMS vendors are struggling just to try to do something with HIPAA >claims, let alone anything else > >4. Most PMS vendors are not providing any specific details to their >customers about what their "HIPAA Compliant" (their term, not mine) system >will do. That is, will it recognize, collect, capture and store all of the >necessary data? Will it support the HIPAA EDI standard formats? Do they >even >truly understand the rules of the road here? And what about all of the >other >HIPAA transactions? Will it accept an 835 and autopost to open A/R? Will it >generate a 276? Will it receive a 277? And so on. My observations are this: >the vendors will be lucky to address a HIPAA compliant claim data >requirement; they'll do nothing regarding the X12 formatting; other >transactions are in the future. > >5. Most PMS vendors have tied their system to one or several billing >services/clearinghouses. > >6. Providers today don't deal with the routing issue and don't want to deal >with it tomorrow > >7. Payers are developing "companion documents" and many (most) have already >determined their communications and comm portal strategy for HIPAA >compliance. Making all of this stuff discoverable electronically, even with >authentication, digital certificates, etc., is not part of their >strategy....yet. > >So, would someone please tell me how on earth a "discoverable" CPP and a >registry is going to enable any covered entity, whether provider (small or >large), payer, or clearinghouse to achieve compliance with the HIPAA EDI >requirements by 10/16/03? > >And lastly, Bruce LeGrand hit the nail squarely: follow the money. If the >payers don't want it, don't require it, won't support it (which is >Strategic >Marketing 101 terms = market acceptance and buy-in) this "if we build it, >they'll come" concept is a pipe dream. I'm not saying that the current >business model of a "payer mailbox" is good or bad. Rather, it's the >dominant model and changing it is not a priority for HIPAA compliance. > >So.....again, I ask: what problem must be solved here in order to achieve >HIPAA EDI compliance? I don't see a multitude of providers, payers or >clearinghouses articulating the business problem, or the business >requirements to solve the business problem. What I do see are many >technical >people brainstorming about the newest technie kid on the block. The "Field >of Dreams" approach didn't work in the past, doesn't work now, and won't >work for the future. Businesses learned very painfully and expensively >during the decade of the 1990's that throwing dollars down the IT rabbit >hole didn't get what they wanted: increased top-line/bottom-line growth >(read more revenue, lower expenses, increased net profit.) And health care >has fewer dollars to lose down this rabbit hole than other industries. > >Lastly, nothing that I've seen discussed here will at all enable small >providers to "dodge" the HIPAA bullet as you describe it any time within >the >next 2-5 years at best. Your comment ... "The most fundamental problem, >however, is that small-to-medium-sized providers (SMPs), who generate half >of the encounter data, have no reasonable way to know if that data is >sufficient to populate a "clean" 837. Since most SMPs have systems built >around "creative" implementations of old paper and electronic formats, I >believe that 99% of them will be incapable of generating a HIPAA-compliant >data set on 10-16-03." ... is not a problem of electronic addressing and >routing. Rather, it's a problem of sourcing the data required. If this is >the core fundamental problem (and I agree with you that it is) then how on >earth does all this talk about electronically discoverable collaboration >profile protocols solve it? Spending scarce and expensive resources trying >to solve a problem that's not a major priority to achieving compliance is >not a good business decision. > >Rachel > >-----Original Message----- >From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] >Sent: Thursday, June 13, 2002 11:50 AM >To: [EMAIL PROTECTED]; WEDi SNIP 4 (E-mail 3) >Cc: David Kibbe; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Ken Wood; >[EMAIL PROTECTED] >Subject: Re: HIPAA Privacy, Security and the Intersection with EDI > > >Rachel, >I agree with virtually all of your observations regarding our near-term >business realities, but I must respectfully disagree with your [eminently >rational] conclusions... because they amount to letting small providers >"take the bullet" for HIPAA.... and I don't think HHS, the payor community, >or the American public will let that happen. I'll try to explain what I >mean by that. (As Kepa would say, "Get your popcorn"). > >It's becoming clear to me that small providers represent the Achilles Heel >of HIPAA in two important ways. One is this "routing/addressing" problem >we've been discussing for 5 months. The most fundamental problem, however, >is that small-to-medium-sized providers (SMPs), who generate half of the >encounter data, have no reasonable way to know if that data is sufficient >to populate a "clean" 837. Since most SMPs have systems built around >"creative" implementations of old paper and electronic formats, I believe >that 99% of them will be incapable of generating a HIPAA-compliant data set >on 10-16-03. Pushing their data through a CH will still not produce >anything that will be allowed through the front door of a "HIPAA certified" >payor... unless HHS gives payors permission to relax the standard for >SMPs. I suspect that HHS will have to do something like this temporarily, >because the SMP's only alternatives on H-Day will be non-std. DDE (horribly >expensive for the provider) or non-standard paper (horribly expensive for >everyone). > >BUT THIS RELAXATION CANNOT BE PERMANENT... that would amount to letting >SMPs "take the bullet". Not only would all standards-based escape routes >for the SMP be cut off by such a move, but it would effectively remove the >only remaining incentive for SMPs to organize themselves and their software >vendors around standards... the incentive to stay out of HIPAA-jail. This >is the tough nut. We really have to "wire up" the Little People, or the >whole effort becomes pointless. Who cares if hospitals can communicate >efficiently with payors if the SMPs can't communicate with hospitals, labs, >payors, or each other? And what would have been the point in the >multi-billion dollar payor and hospital (and CH/VAN) investment in standard >EDI, if these entities wind up only being able to talk to the same trading >partners they are talking to [efficiently] today? > >If we do successfully mobilize the SMP community around standards (and some >very encouraging movement is taking place within doctors' professional >associations... as we speak), then the PMS vendor community will have a >clear and convincing mandate to build EDI-enabled systems for doctors. If >they do that, then SMPs and payors will need what this group has been >attempting to write a specification for... a highly streamlined and secure >method for doing something that has [apparently] never been done since the >dawn of EDI: enable "open" connectivity for lots of small-volume >partners. There is no doubt that the world wants "open/easy" business >connectivity and this, in fact, is the cornerstone of ebXML and a >half-dozen other global e-biz movements. In healthcare, however, we have a >significant movement already underway (not to mention a federal mandate) to >organize "open connectivity" around 10 critical transactions and legacy >EDI. Even in retrospect, forcing compliance around a 30+ year-old >communication standard still looks like the most intelligent way to get the >industry on to the same page. Retrofitting the ebXML CPP/CPA concept to >work with legacy-EDI may very well turn out to be an excellent use-case for >ebXML and a nice boost to that initiative, as well. > >Back to the work of this group: Normally, when you have a business problem >as complex as the one before this group, you have a "client" with a head >full of fuzzy requirements and a bucket full of cash. What we have here is >a group of visionaries who are describing requirements that OTHERS >reportedly have (but have not realized)... and we have no cash! So, on its >face, this project doesn't look like something that an intelligent person >could be expected to pour hundreds of hours into. There is no money in the >project... and the supposed beneficiaries (some of whom are lurking on this >list) have not indicated any interest whatsoever in having or using such a >system. So, what do we do? > >Payors STAND TO LOSE big-time if we let the SMPs off the hook permanently >with regard to TCS. To see a return on their EDI investment of the last >8-10 years, payors need a way to plug SMPs directly into the standard >communication system. This also happens to be essential to the REAL agenda >of HIPAA, which is improvement in the overall quality of health care. As >Ronald Bowron pointed out, it will probably be no more attractive to the >CH/VAN community to embrace all these rag-tag SMPs than it would appear to >be for the payor community. Even if these folks did want to take on all >these low-volume customers, there will literally not be enough >technical-consultant hours to individually negotiate, test, and certify >each trading relationship, using our time-honored manual process... even if >you COULD persuade doctors to pay the exorbitant price of such negotiation. > >Clearly we have to light a fire under the SMP world. This began in earnest >on May 10th in the vision care world, thanks to AOA's official >acknowledgement of the SMP problems, and commitment to finding >solutions. Extremely encouraging movement is also taking place within the >95,000 member American Academy of Family Physicians and a couple other >groups. More meetings are expected this Summer. This Herculean effort >will require technical assistance and MONEY if we want it done [well] and >implemented before everyone on this listserve is dead or retired. The big, >long-term funding needs to come from the SMPs, themselves, via their >professional associations and a well organized SMP-data content >committee. The startup capital and initial outreach/education, however, >should probably come from the payor and DSMO communities... so that it >happens quickly. > >Meanwhile, his group should continue working on our assignment, a >streamlined way to enable the nouveau-EDI to find their partners and be >found by them. We're going to need this if we want to let the SMPs play in >the big sand-box. > >Thank you for listening... and I apologize for the "preachy" tone. >Best regards, >-Chris > > >At 11:35 AM 6/12/02 -0500, Rachel Foerster wrote: > >Fact 1: Almost all (if not all) of the currently mandated HIPAA EDI > >transactions contain protected health information > > > >Fact 2: Today's business model supports and enables protected health > >information to be stored redundantly by many intermediaries between a > >health care provider and payer at substantial cost > > > >Fact 3: It is highly probable that today's business model will continue > >for a substantial period of time unchanged following the HIPAA drop-dead > >compliance dates for either or all of privacy, security, EDI > > > >Fact 4: Data at rest is substantially more vulnerable to > >disclosure/access than data in transit...regardless of whether the data at > >rest is in a secured or unsecured environment > > > >Fact 5: HIPAA requires the implementation of appropriate safeguards for > >protected health information - today and tomorrow > > > >Question: Given these facts, how does one evaluate the effort of this > >group to developing a series of working papers on the topics of > >identifiers, addresses and delivery channels, elements of the Healthcare > >Collaboration-Protocol Profile (CPP), discovery of Healthcare CPPs via a > >Registry, address, solve or mitigate any of the issues and/or problems > >inherent in the current business model which I believe can reliably be > >predicted to continue for a substantial period of time into the future > >surrounding the electronic exchange of health information? > > > >Comments: It seems to me that this is a highly visionary model (one > >which has not yet been implemented in any other industry to date) only > >serves to add further complexity and confusion to an already highly > >complex and confused industry. There are solutions already commercially > >available and affordable that address these issues. So please, I'd > >appreciate some succinct words of explanation that one could use when > >talking to industry participants about how identifiers, addresses and > >delivery channels, elements of the Healthcare Collaboration-Protocol > >Profile (CPP), discovery of Healthcare CPPs via a Registry help any one > >or all of them implement an EDI capability that enables compliance with > >HIPAA by either April 14, 2003 (privacy....and security), October 16, > >2002, or testing by April, 2003, and full implementation by October 16, >3003. > > > >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 > > > >Christopher J. Feahr, OD >http://visiondatastandard.org >[EMAIL PROTECTED] >Cell/Pager: 707-529-2268 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
