Last week there were some emails regarding a lack of provider involvement
so I took the concerns about lack of provider (non retail pharmacy)
involvement to our billing office management (we have a central billing
office for 4 hospitals). They have offered to bring the issue of WEDI SNIP
involvement to our state AAHAM and Maryland Hospital Association
memberships.
What groups would you like more input in? Are there conference call
schedules available? Are there meetings or conferences that they should
plan to attend?
Please let me know so we can help to get the word out.
Tami Leaver
Sr. Application Analyst
Medstar Information Systems
410-933-6905
email: [EMAIL PROTECTED]
Jan Root
<janroot%uhin.com@interne To:
[EMAIL PROTECTED]
t.mhg.edu> cc:
Subject: Re: Data Downloads
from DDE Applications
05/13/02 10:11 AM
Chris
I too worry about under-representation of providers in the various
non-retail
pharmacy SDOs. I think that NCVHS is working on a standard for medical
records....
I can't recall if it's just for computerized/electronic medical records or
all
medical records.....? Kepa? Can you give us an update? Is that an
appropriate
thing to talk about on this list serve?
Jan Root
"Christopher J. Feahr, OD" wrote:
> Thanks, Jan! While this seems obvious, I've had payors react with
> disbelief and surprise when I make this assertion. But the other,
perhaps
> more malignant, aspect of this is that providers don't seem to be upset
> either! A very small # of them are aware of the labor-intensive aspect
of
> this and are "doing the math", but most just seem to regard DDE as a
small
> but positive step in the direction of automation. In net-$, however, it
> can be a step backwards... at best it's probably a lateral move. DDE
> systems will disappear overnight when doctors (and hospitals) stop using
> them and lean on their software vendors to provide real EDI solutions.
>
> This is one more reason to think about creating a national,
> provider-oriented SDO (for all non-retail-pharmacy providers). I can
hear
> the collective groan, but wait a second! This would not REQUIRE any
> attendance by members of the payor or CH industry. Representatives from a
> monolithic provider-SDO could, however, attend all the current DSMO
> meetings in sufficient numbers to populate any workgroup that even
remotely
> impacted providers. The vision industry has finally (this week,
> actually) acknowledged the need for an internal industry organizational
> structure for modeling/articulating our special data requirements for
> eyewear claims... and THAT organization (we still don't know what to call
> it) will be able to speak with a single voice to HL7 and X12 about HIPAA
> messaging standards...as well as to our manufacturers' association about
> related supply-chain transaction standards.
>
> The more I think about this, however, the more I believe that a parallel
> effort should be underway to represent ALL doctors, hospitals, labs, and
> DME providers. Virtually all types of providers have a need to share
> information amongst themselves and to aggregate information about
TREATMENT
> across the healthcare industry. So while we would all benefit from
> standard medical record structures, etc., I don't think we want 15
> different provider groups "standardizing" medical record formats
> individually. I'm not even sure which existing SDOs would want to tackle
> national EMR standardization. Does anyone know who might be working on
EMR
> standards now?
>
> Something else to think about... (like we don't have enough!)
> -Chris
>
> At 10:28 AM 5/10/02 -0600, Jan Root wrote:
> >All
> >I would second what Chris said. From the provider's perspective, DDE
> >systems are
> >not a very good solution - better than paper yes, but a lot of work.
It's
> >sort
> >of the electronic equivalent of having to deal with a proprietary form
for
> >each
> >payer, at least from the "I gotta handle each payer individually"
perspective.
> >Provider like a 'one-stop'shopping' solution to submitting claims,
> >eligibility,
> >etc and receiving RAs and other response transactions.
> >
> >Jan Root
> >
> >
> >"Christopher J. Feahr, OD" wrote:
> >
> > > Alan,
> > > Thank you for your comment. I think you are absolutely correct about
> > > provider DDE systems (and everything else) eventually morphing into
an XML
> > > version of "EDI". Given the huge pent-up desire to implement XML and
the
> > > interesting work that OASIS, X12, and others are doing today to
create
> > > hybrids of XML and EDI message/transport structures... I think its
very
> > > possible that most small providers will never actually see a classic
EDI
> > > message inside their offices. So, while I did suggest we "phase them
all
> > > out"... I didn't REALLY think that anyone would try to kill DDE with
a
> > > law. By the time such a law became enforceable, we'd be ready to
migrate
> > > from XML to the "next big thing"!
> > >
> > > My point, however, is that we should not make the mistake of thinking
that
> > > DDE systems are very useful to the provider... THEY ARE
LABOR-INTENSIVE,
> > > MANUAL SYSTEMS. The "electronic" advantages of DDE are ALL on the
payor
> > > end. In the doctor's offices, they still have $20/hr. employees
clicking
> > > around on websites with browsers and 33K dialup connections.
Doctors' idea
> > > of "automation" is to get a DSL line for the office! HIPAA done
entirely
> > > through a DDE interface doesn't improve doctors' live a bit (in my
> > > opinion), but it still allows payors to reduce the sizes of their
call
> > > centers and eliminate many data-entry positions.
> > >
> > > Best regards,
> > > -Chris
> > >
> > > At 04:37 PM 5/8/02 -0400, Hirth, Alan wrote:
> > > >
> > > >I don't support the idea of phasing out DDE. Forcing providers off
of a
> > > >browser/web based eligibility inquiry, claim status inquiry, and/or
claim
> > > >entry system and onto pure EDI is counter productive. Encouraging
DDE
> > as a
> > > >supplement to EDI and working to merge the two by developing HIPAA
XML
> > seems
> > > >like a better long term strategy.
> > > >
> > > >-----Original Message-----
> > > >From: Christopher J. Feahr, OD
> > > >To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > > >Sent: 5/8/02 3:37 PM
> > > >Subject: RE: Data Downloads from DDE Applications
> > > >
> > > >Rachel,
> > > >I would agree with your interpretation of the conventional usage of
> > > >terms
> > > >like "print screen" and "download"... but I do not see clear support
in
> > > >the
> > > >law for your definitions. In order to display data on a provider's
DDE
> > > >screen, I would argue that the payor is, in fact, "downloading" or
> > > >"transferring" data to the provider's system in a non-standard
> > > >format. There seems to be a need to better define not only the
details
> > > >of
> > > >this special type of transfer, but whether there are any
restrictions on
> > > >
> > > >what the provider can legally do with the data after it is
> > > >transferred...
> > > >whether it even HAS to wind up on a "screen" or display device...
> > > >whether
> > > >data could be pushed out to a provider's screen under this exception
> > > >without the provider requesting it immediately beforehand, etc.
> > > >
> > > >My suggestion (which, of course, would be pretty difficult to
implement)
> > > >is
> > > >that we tighten up the definition of "DDE" systems and then permit
them
> > > >to
> > > >be used for another 2 or 3 year transition period... and then phase
them
> > > >
> > > >all out!
> > > >
> > > >regards,
> > > >Chris
> > > >
> > > >At 04:04 PM 5/6/02 -0500, Rachel Foerster wrote:
> > > > >Kris,
> > > > >
> > > > >The core difference between a print screen and a file download is
just
> > > > >that -- when someone prints a screen no data is being downloaded
to the
> > > >
> > > > >local system for additional processing -- the screen (display) is
> > > >intended
> > > > >for a human-to-computer interface. On the other hand, a file
download
> > > >is
> > > > >not intended for a human-to-computer interface, but rather, is
intended
> > > >
> > > > >for automated processing or a computer-to-computer interface. Just
> > > >because
> > > > >there may be human intervention with a downloaded file, the data
in the
> > > >
> > > > >file is intended to be input into another application and not
viewable
> > > >"as
> > > > >is" by a human.
> > > > >
> > > > >Therefore, if a file of data is being downloaded, regardless of
the
> > > > >transport mode, e.g., HTTP, ftp, or even attached to an email, and
the
> > > > >data constitutes one of the covered HIPAA transactions, after
either
> > > > >10/16/02 or 10/16/03, the format of the data and the data content
must
> > > > >comply with the appropriate HIPAA implementation guide.
> > > > >
> > > > >Rachel
> > > > >-----Original Message-----
> > > > >From: Owens, Kris [mailto:[EMAIL PROTECTED]]
> > > > >Sent: Monday, May 06, 2002 9:06 AM
> > > > >To: '[EMAIL PROTECTED]'
> > > > >Cc: Goulart, Cesar; '[EMAIL PROTECTED]'
> > > > >Subject: RE: Data Downloads from DDE Applications
> > > > >
> > > > >Rachel,
> > > > >
> > > > >Thanks for the response, although it is not what I had hoped to
hear.
> > > > >
> > > > >Another thought (yes, I am still trying to justify giving this
ability
> > > >to
> > > > >the providers) how would this download be different (in concept)
from
> > > >the
> > > > >provider using a print screen option in their operating system?
> > > > >
> > > > >Kris Owens
> > > > >923-8108
> > > > >
> > > > >"There is no meaning in isolation"
> > > > >
> > > > >-----Original Message-----
> > > > >From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
> > > > >Sent: Saturday, May 04, 2002 1:15 PM
> > > > >To: [EMAIL PROTECTED]
> > > > >Subject: RE: Data Downloads from DDE Applications
> > > > >
> > > > >Kris,
> > > > >
> > > > >My understanding of the DDE exception plus the HHS FAQs on the
subject,
> > > >
> > > > >lead me to conclude that the download of the eligibility
information
> > > >would
> > > > >be a covered transaction under the electronic transaction final
rule,
> > > >and
> > > > >thus, must conform to the 271 specifications.
> > > > >
> > > > >Rachel Foerster
> > > > >
> > > > >-----Original Message-----
> > > > >From: Owens, Kris [mailto:[EMAIL PROTECTED]]
> > > > >Sent: Friday, May 03, 2002 4:12 PM
> > > > >To: [EMAIL PROTECTED]
> > > > >Cc: Goulart, Cesar
> > > > >Subject: Data Downloads from DDE Applications
> > > > >
> > > > >We have a web application for our healthplan that supplies
eligibility
> > > >and
> > > > >claims status information to providers. Once a provider has
displayed
> > > >the
> > > > >information, they have an option to "download" the information to
their
> > > >
> > > > >PC. My question - should we consider the download to be a covered
> > > > >transaction?
> > > > >I find the following in the regulations:
> > > > >
> > > > >160.103 Transaction means the exchange of information between two
> > > >parties
> > > > >to carry out financial or administrative activities related to
health
> > > >care.
> > > > >162.923 (a) General rule. Except as otherwise provided in this
part, if
> > > >a
> > > > >covered entity conducts with another covered entity (or within the
same
> > > >
> > > > >covered entity), using electronic media, a transaction of which
the
> > > > >Secretary has adopted a standard under this part, the covered
entity
> > > >must
> > > > >conduct the transaction as a standard transaction.
> > > > >(b) Exception for Direct data entry transactions. A health care
> > > >provider
> > > > >electing to use direct data entry offered by a health plan to
conduct a
> > > >
> > > > >transaction for which a standard has been adopted under this part
must
> > > >use
> > > > >the applicable data content and data condition requirements of the
> > > > >standard when conducting the transaction. The health care
provider is
> > > >not
> > > > >required to use the format requirements of the standard.
> > > > >162.1201 Eligibility for a health plan transaction (a) An inquiry
from
> > > >a
> > > > >health care provider to a health plan, or from one health plan to
> > > >another
> > > > >health plan to obtain...(1) Eligibility to receive health care
under
> > > >the
> > > > >health plan. (2) Coverage of health care under the health plan.
(3)
> > > > >Benefits associated with the benefit plan. (b) A response from a
> > > >health
> > > > >plan to a health care provider's (or another health plan's )
inquiry
> > > > >described in the paragraph(a) of this section.
> > > > >162.1402 Health care claims status transaction. (a) An inquiry to
> > > > >determine the status of a health care claim. (b) A response about
the
> > > > >status of a health care claim.
> > > > >OK, so I read all this and it would seem that the downloads are to
> > > >carry
> > > > >out administrative activities, and they are eligibility responses,
or
> > > > >claims status responses. My only hope is that the web application
has
> > > > >already done the request and response and that this is somehow
after
> > > >the
> > > > >fact, and therefore not covered... or perhaps the fact that this
is
> > > >from a
> > > > >DDE application gets us by the format requirements. If these
are in
> > > > >fact a covered transaction they become useless because the
providers
> > > >that
> > > > >are utilizing these are doing so because they have no technical
> > > >facility
> > > > >to handle an X-12 format.
> > > > >Any thoughts?
> > > > >
> > > > >
> > > > >
> > > > >Kris Owens
> > > > >Senior IS Project Manager - HIPAA Project
> > > > >Presbyterian Healthcare Services
> > > > >Albuquerque, NM
> > > > >505.923.8108
> > > > >[EMAIL PROTECTED]
