----- Forwarded by Kim Peters/Louisville/Humana on 06/14/2002 03:02 PM
-----
"NTList"
<[EMAIL PROTECTED] To: "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>
g> cc:
Subject: RE: HIPAA Privacy, Security
and the Intersection with
06/14/2002 01:57 EDI
PM
Your attached message has been delivered to the 391 members and
scheduled for 1 digests of the list [EMAIL PROTECTED] at 12:57:24
on 14 Jun 2002.
The text of the message follows:
----- Message from "Kim Peters" <[EMAIL PROTECTED]> on Fri, 14 Jun 2002
13:58:11 -0400 -----
To: [EMAIL PROTECTED]
cc: "'Christopher J. Feahr, OD'" <[EMAIL PROTECTED]>, "'David Kibbe'"
<[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED],
"'Ken
Wood'" <[EMAIL PROTECTED]>, "'WEDi SNIP 4 \(E-mail 3\)'"
<[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: RE: HIPAA Privacy, Security and the Intersection with EDI
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
