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
