|
Thanks, Doug. I've been racking my brain for
weeks now trying to think of ways to get a normal-human-understandable view of
the problem and solution in front of the employer community. I
think I can tell the story... just can't think of the right venue.
Does anyone have Michael Moore's email address or phone #? Perhaps he
would like to make a movie for us... but not quite as angry and confrontational
as his other films! I don't want to beat anyone up over
this... least of all our friendly gorillas, who are just doin' what gorillas
do. But... it would be sobering for the general public to consider the
100-250 people who die each DAY in this country as the result of preventable
medical error. That's one jumbo-jet-full per day, folks!
Hey, maybe Michael's the right guy, after
all! He could certainly get this onto the Big Radar
Screen!
----- Original Message -----
Sent: Wednesday, June 04, 2003 6:25
AM
Subject: Re: Now that we are all speaking
the same language.Can you hear m e?
Christopher,
You've hit the nail on the head! Now, are any of these
$ sources listening?
The opinions expressed here are my own and not necessarily the opinion of
LCMH.
Douglas M. Webb Computer System Engineer Little Company of Mary
Hospital & Health Care Centers [EMAIL PROTECTED]
"This electronic message may contain information that is confidential
and/or legally privileged. It is intended only for the use of the
individual(s) and entity(s) named as recipients in the message. If you
are not an intended recipient of the message, please notify the sender
immediately, delete the material from any computer, do not deliver,
distribute, or copy this message, and do not disclose its contents or take
action in reliance on the information it contains. Thank you."
----- Original Message -----
Sent: Tuesday, June 03, 2003 01:57
PM
Subject: Re: Now that we are all
speaking the same language.Can you hear m e?
Dear Dave, et al.
Good to hear from all you folks
again! The only thing I'd like to add
to this discussion is that we
are NOT bound to wait for what "Uncle is
unwilling or unable to
provide"... nor does Uncle even WANT us to wait
around for a change in
the regulation. He expects "industry" to get off
its butt and build
what it needs. To the extent our industry can do
that FAIRLY (to
patients and providers), we can keep the standards
process more
disconnected from the regulatory process. Nobody
WANTS
regulation... certainly not the feds who have to expend all this
effort
to figure out how to enforce it and justify its cost to
OMB.
Politicians and bureaucrats do not understand or care about this
crap
anyway!
Here is my present "gospel" in a nutshell:
1.
The present standards are not being implemented by providers (for
a
variety of sound and unsound or confused reasons)... but providers
are
by and large ignoring EDI.
2. Until we develop a new suite of
standards and agree on standard
approaches to basic connectivity,
providers will experience increased
costs and decreased cash flow.. due
in part to the vert rule that was
intended to reduce provider
costs. This will be in several forms,
including forced reliance on
CHs and fallout from a global increase in
paper claim submissions.
Providers will certainly not be saving
money... until we have created a
set of little-person-implementable
standards and the [likely, new] PMS
vendor community has sold providers
XML-standards-compliant
systems.
3. Therefore, we MUST get new HIPAA transaction (and supply
chain)
projects underway within HL7 now. This work should have
started a year
ago and it must get going ASAP. X12 is not set up to
handle massive
provider input... and all it really MUST care about are
the needs of the
Insurance Industry. With the exception of a band
of incredibly
hard-working zealots and UML-visionaries in N/TG3, I can't
see that X12
is even remotely interested in process modeling or in a
process-driven
message development framework. But that what
providers NEED... because
this big, global PMS play is going to have to
solve nearly all of their
internal and external problems, in order for
them to see lower costs and
less double-data-entry (DDE).
Nothing
stands in our way here except the fact that no one has a clue
how to pay
the people who would actually accomplish this work on behalf
of
providers. Providers, themselves, and their
professional
associations do not appear to grasp the importance of any of
this. It
is foreign to them and highly technical. A small
core of PAID experts,
however, can get the standards dev. work started on
their behalf and
then pull selected/volunteer providers into the vetting
process via a
program of ACTIVE/MANAGED outreach and technical
review. Doctors are
NOT going to have to attend SDO meetings in
order for the SD-process to
be fair... only their trusted [paid, probably
full-time] technical
advocates need attend. Anything requiring
grass roots provider input or
review can be pushed out to them via the
managed vetting network (of
practicing physicians, hospital IT gurus,
etc.), published on the
website for comment, etc.
This basic
standards development machine that I envision is different
from the
spotty, all-part-time, all-volunteer-labor model that operates
in SDOs
today. The all-volunteer model ensures
all-gorilla-friendly
standards. If we want high quality standards
supporting the needs of
large and small stakeholders... brought to market
in a reasonable time
frame... we will need to get VERY serious about
building a high-powered,
well-oiled SD Machine.
I believe that HL7
can support this sort of infrastructure and is
undoubtedly thinking about
this. HL7 will probably have to alter its
pricing/licensing model
for its standards deliverables... so that the SD
Machine can be supported
by its own revenue. Initially, however, we
will need startup
capital.
So the real "square one" issue is where to get that infusion
of capital
to start the necessary SIGs in HL7, commence the process and
data
modeling work, establish the networks of provider domain experts
to
comprise the vetting pool, build the outreach mechanism, etc.
I'm not
sure how far along HL7 might be in setting up registries
and
repositories for reusable standards components, CPP information,
etc....
but, again, I'm sure that HL7 is thinking about this because it
is
essential to the new Ver 3 RIM-based development framework that
is
rapidly making its way through the ballot process.
So... where
do we find the startup $? Logic would suggest going to
providers
and payers, the most immediate beneficiaries of the
standards... but
providers are [oddly] not the least bit interested. I
can fully
understand payers' lack of interest, but the absence of
provider interest
is the result of a collection of complex factors that
I will not go into
here. But trust me... providers are a DRY HOLE and
so are
payers. Forget CHs too, because what we are talking about
will
eventually wreck the existing CH service model.
Forget the
existing small-provider PMS community, too. Most little PMS
vendors
are too small to play on a global level, which is where you'd
have to be
to see any ROI serving the small provider's needs. Big PMS
vendors
who would be interested in this space [if it were only a little
more
standardized] MIGHT be willing to help... but more likely, they
will
continue to wait in the wings until the problem space ripens a
little
more... or until much larger numbers of small providers are
filing for
bankruptcy and these guys wake up to the pain they are in.
I think
that leaves us with Employers who are presently stuck with the
monthly
bill for this pile of do-do. Employers stand to win almost
as
immediately as payers and providers, if we can successfully remove
cost
and error from healthcare processes. Do you think we can
connect the
dots for Large Employers and persuade them to jumpstart
this?
Federal grants would be a last resort, but are also a
possibility.
...or maybe we will need a little from all of the
above. I can see what
we have to do and what we have to
build. I just can't see the money.
Christopher J. Feahr,
O.D.
Optiserv Consulting (Vision Industry)
Office: (707)
579-4984
Cell: (707) 529-2268
http://Optiserv.com
http://VisionDataStandard.org
-----
Original Message -----
From: "Dave Minch" <[EMAIL PROTECTED]>
To:
"WEDI SNIP Routing Subworkgroup List" <[EMAIL PROTECTED]>
Sent:
Monday, June 02, 2003 6:18 PM
Subject: RE: Now that we are all speaking
the same language.Can you hear
m e?
> William, Dick, Chris
& all,
> We've been here before, and are left at the same point -
wanting for a
> commonality that Uncle is unwilling or unable to
provide. That is
simply a
> mandate on how transactions are to be
communicated over the internet.
>
> At the HIMSS conference
several months back (Feb) I had the
opportunity to
> talk to folks
who said they had been involved in framing the
regulations. I
> put
the question to them: "why did you not continue the
regulations
into
> what technology must be used for communication"
or something to that
effect,
> and the response (and it was,
interestingly enough, quite uniform) was
that
> they wanted the
regulations to be "technology independent". I find
that
> quite
interesting - a highly technical regulation, clearly dependent
on
>
technology, but, nonetheless, "technology independent". Does that
sound
odd
> to anyone else or is it just me??...
>
> Well,
congratulations to all the folks that drafted the
regulations,
you
> really managed to create something that will be
impossible for all but
the
> most technically sophisticated and
incredibly determined to truly
implement.
> All the others
(providers) will simply go to the CHs and say "uncle"
(with
> all
that that implies). I just hope that all providers document
along
the
> way which plans use which CHs as the Plan's primary BA
for receiving
> transactions so the providers can avoid the
transaction fees (of
course,
> we're still wasting healthcare
dollars, but I guess that's not
> important...).
>
> And
then mother WEDI comes forward with the "train wreck" memo
and
offers
> the CHs as the interim solution. Give me a break - as
if we weren't
already
> aware of the end game here, do they have to
rub our noses in it? I
> personally think that they should rename the
Adminsimp part of the
> regulation the "administrative waste"
regulation, or perhaps the
"assure CHs
> survival" regulation,
because without strong regulatory mandates for a
> specific
communication method (e.g. EDIINT-AS2), that's exactly what
it
is.
>
> By the way, we now have 8 TPAs completed and more in the
works, and as
of
> now only two are communicating batch using the
same method (push-pull
using
> FTP over SSL), and none of them have
reached agreement with us yet on
how
> the real-time transactions
are to be exchanged. For anyone whose
counting,
> that's 7
different methods, and we only signed our first agreement
3
months
> ago...
> Dave
>
> Dave Minch
>
T&CS Project Manager
> John Muir / Mt. Diablo Health
System
> Walnut Creek, CA
> (925)
941-2240
>
>
> -----Original Message-----
> From:
Dick Brooks [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 30, 2003
10:08 AM
> To: WEDI SNIP Routing Subworkgroup List
> Subject:
RE: Now that we are all speaking the same language.Can you
hear
me?
>
>
> William,
>
> I believe we are in
agreement. Clearly, the facilities to accomplish
> reliable, secure
data exchange are readily available both in browser
and
> e-mail
forms. You have identified one of the practical and bigger
>
"challenges" for HIPAA implementers; managing the variations of
each
trading
> relationship (transactional, data exchange,
etc.)!
>
> This is where I believe a Clearinghouse service
provides real value,
by
> abstracting away all the "implementation
differences".
>
>
> Dick Brooks
> Independent
Consultant
> B2B Integration and Cyber Security
>
Mobile:602-684-1484
> eFax:240-352-0714
>
>
>
-----Original Message-----
> From: William J. Kammerer
[mailto:[EMAIL PROTECTED]
> Sent: Friday, May 30, 2003 9:31
AM
> To: WEDI SNIP Routing Subworkgroup List
> Subject: Re: Now
that we are all speaking the same language.Can you
hear
me?
>
>
> Dick, your demo is simple and elegant,
indeed. And I trust that you
could
> get it to be as fancy as
you please, with SSL and auto-population. And
if I
> had to
exchange files with my ONE bank or broker or whatnot, it
wouldn't
be
> too hateful to learn those few Web interfaces in order to
exchange
data.
>
> But this is the very same problem we have
with DDE. You don't just
have one
> payer you deal with, but
potentially dozens or hundreds. Every payer
would
> expect you to
learn his own DDE eligibility or remittance system. No
matter
> how
nice each one individually may be, it's still a pain to learn
them
all.
> That's why standard EDI transactions were invented: you
can exchange
> standard HIPAA transactions, which everyone is expected
to understand
and
> pretty much use the same way.
>
>
No, you really need just one way to get interchanges to your trading
>
partners, and be done with it. Today, the VAN or Clearinghouse
serves
that
> purpose quite nicely, albeit with horrendously
expensive tolls,
including
> monthly charges and per-kilobyte
charges. But those tolls are
nonetheless
> probably cheaper
than trying to bypass the intermediary and learning
each
> payer's
proprietary upload system.
>
> William J. Kammerer
>
Novannet, LLC.
> Columbus, US-OH 43221-3859
> +1 (614)
487-0320
>
> ----- Original Message -----
> From: "Dick
Brooks" <[EMAIL PROTECTED]>
> To:
"WEDI SNIP Routing Subworkgroup List"
<[EMAIL PROTECTED]>
>
Sent: Friday, May 30, 2003 10:14 AM
> Subject: RE: Now that we are all
speaking the same language.Can you
hear me?
>
>
>
William,
>
> IMO, the world already has a 10-10-EDI capability.
All of the
commercial
> browsers I've used have the ability to send
a file to a server using
nothing
> more than a browser. You can see
an example of this at:
> http://www.tech-comm.com/simpleupload.html
>
>
Try it out for yourself.
>
> One can easily "enhance" the
security of this by adding SSL (https)
and a
> username/password
for access control. Add a little "smarts (database)"
to
> the
backend and the provider ID field could automatically be
populated
with
> the provider ID assigned to the username/password that "logs
in".
>
> Last, but not least - add a link to this form that will
let the user
> retrieve files that the payer has waiting to send to
the provider.
>
> We have a simple, reliable, secure messaging
solution with no cost to
the
> provider (10-10-EDI) and the payer
has total control over the feature
by
> allowing as much or as
little functionality as they wish to the form
that is
> presented
to the user.
>
> I know - this will never work - it's way
toooooo simple.
>
>
> Dick Brooks
> Independent
Consultant
> B2B Integration and Cyber Security
>
Mobile:602-684-1484
> eFax:240-352-0714
>
>
>
-----Original Message-----
> From: William J. Kammerer
[mailto:[EMAIL PROTECTED]
> Sent: Friday, May 30, 2003 6:41
AM
> To: WEDI SNIP Routing Subworkgroup List
> Subject: Re: Now
that we are all speaking the same language.Can you
hear
me?
>
>
> Chris, good points all. But I would still call
EDI-INT AS1 (e-mail)
> "peer-to-peer" since just about everyone in the
world "polls" his POP3
> server multiple times throughout the day. In
a technical sort of way,
the
> user's ISP is the "hub" - but at
least he's only dealing with a few
hubs in
> this case (depending
on how many e-mail providers one has). And he's
not
> only
extracting his EDI messages from one account, but probably
also
the
> accounts for business and personal e-mail at the same
time. That's a
darn
> sight better than having to poll a multitude
of payers, constantly
adding
> and changing payers, protocols and
logon procedures to an ever-growing
> Procomm script!
>
>
EDI-INT software is getting better at the maintenance bit - but
it's
still
> not any easier than getting digital IDs to work in
Outlook Express.
This
> stuff really isn't going to take off until
we have something like the
> "10-10-EDI" of B2B transport. It should
be as simple as "dumping" your
EDI
> into a funnel, and having your
interchanges arrive at their intended
> destinations - based on
receiver ID - safely, securely and reliably.
You
> shouldn't have
to jack around with trading partner maintenance, X.509
> digital
certificates, certification authorities, and expensive
software
with
> onerous annual maintenance fees.
>
> William J.
Kammerer
> Novannet, LLC.
> Columbus, US-OH 43221-3859
>
+1 (614) 487-0320
>
> ----- Original Message -----
> From:
"Christopher Feahr" <[EMAIL PROTECTED]>
> To:
"WEDI SNIP Routing Subworkgroup List"
<[EMAIL PROTECTED]>
>
Cc: <[EMAIL PROTECTED]>
> Sent:
Thursday, 29 May, 2003 05:59 PM
> Subject: Re: Now that we are all
speaking the same language.Can you
hear me?
>
>
>
William,
> Thanks for posting this interesting paper (and thanks for
writing it,
Dan!).
> While email is functionally peer-to-peer, it
would still be a sort-of
> hub-spoke model for the small provider who
did not maintain his own
mail
> server... requiring his system to
repeatedly poll his POP mailbox
throughout
> the day. But
this still seems like a reasonably workable approach
that
> could
produce near-real-time responsiveness with anyone-to-anyone
>
connectivity assured by the ubiquitous SMTP standard. As long as
every
> sending system was programmed to look for a TA1-type ACK
response
(which
> could be a coded response in the subject line),
and every receiver was
able
> to send one, then the occasionally
dropped or corrupted emails would
not be
> a
problem.
>
> I assume that the user could be completely
insulated from the email
> management processes and that the creation
of "signed" and "encrypted"
> outgoing messages, management of
certificates, etc. could be
completely
> automated within the PMS
application... right? When I first heard
about
> using email
as the secure transport layer, it conjured up an image of
my
>
staff fiddling around manually with conventional email
clients,
manually
> moving email attachments, spam, etc. But
a very specific email
handler
> could be imbedded into a PMS,
designed to accept only email addresses
from
> known/registered
senders... automatically parsing the header
information
> from each
email into the system's communication log, and maybe using a
>
mutually agreed upon message ID numbering system in the "subject"
field
to
> link response messages and acknowledgements to the original
message.
>
> So, what's the down-side... is there any? I
would think that the PMS
> community would be VERY happy to implement
this in the short term.
Given the
> rather obvious ability of
payers (and providers) to use this as a
> CH-fee-avoidance strategy,
why would payers oppose it? Compared even
to the
> cost of
managing EDI connectivity to the CH community, the cost to
a
payer
> of setting up a dedicated email server seems trivial. We
would have to
agree
> on how to use the subject line most
effectively and payers would have
to
> integrate the special mail
system with their existing applications...
but it
> still seems WAY
easier than maintaining all these brittle EDI
>
direct-connections.
>
> Is anyone doing this
now??
>
> -C
> Christopher J. Feahr, O.D.
> Optiserv
Consulting (Vision Industry)
> Office: (707) 579-4984
> Cell:
(707) 529-2268
> http://Optiserv.com
> http://VisionDataStandard.org
>
>
----- Original Message -----
> From: "William J. Kammerer" <[EMAIL PROTECTED]>
>
To: "WEDI SNIP Routing Subworkgroup List"
<[EMAIL PROTECTED]>
>
Sent: Wednesday, 28 May, 2003 05:17 PM
> Subject: Now that we are all
speaking the same language.Can you
hear
me?
>
>
>
> Dan Kazzaz has a new whitepaper
extolling the virtues of EDIINT for
what
> ails Healthcare.
It's entitled "Now that we are all speaking the same
> language. Can
you hear me?" and is available from the "Resources"
page at
>
http://www.novannet.com/.
>
>
The Health Insurance Portability and Accountability Act
of
> 1996 (HIPAA) contains provisions designed to
reduce health
> care administrative costs. HIPAA
mandates that all payers
> and providers be able to
exchange electronic administrative
> messages
including claims, authorizations, eligibility
>
verification, etc. in a common format. This is a huge
leap
> over today's Tower of Babel mode where every
organization
> sets their own data rules. Even with
standardized messages,
> the healthcare industry
will not be able to exchange data
> smoothly unless
both data communication and encryption
> standards
are set and followed. Fortunately, healthcare
> does
not need to create a new standard; AS1 already
exists
> and is becoming increasingly popular in
corporate America.
>
> While you're there, make sure you also
check out the newly revamped
> WEDI/SNIP Identification and Routing
Special Interest Group's web
page,
> available also from the
"Resources" page. Unfortunately, the Archives
of
> the ID
& Routing Listserve discussions, maintained at The Mail
Archive,
are
> temporarily unavailable .
>
> William J.
Kammerer
> Novannet, LLC.
> Columbus, US-OH 43221-3859
>
+1 (614) 487-0320
>
>
>
> ---
> 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-routing 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-routing 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-routing 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-routing 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-routing
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-routing 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
|