Dave,
There will be some changes to some of the final HIPAA rules, most notably
the privacy rule (Tommy Thompson has already made that statement), and there
will be some modifications to the HIPAA EDI implementation guides. But HIPAA
and the current regs will not be gutted.
I personally don't believe there will be any wholesale change to the EDI
implementation guides, especially in any major move away from the X12 syntax
towards something else, XML, for example. And don't forget, not all of the
mandated EDI transactions are based on X12. The retail pharmacy claims
transactions use the NCPDP formats, which are not even a close cousin to X12
syntax. Furthermore, there's too many additional transactions/implementation
guides in the development pipeline, both at X12 and HL7, for there to be a
major official abandonment of the X12-based transaction formats to something
else.
Lastly, I don't perceive any grass roots groundswell demanding a different
transaction format, such as XML. There's already too big of an installed
base by some very major enterprises for them to now push for abandonment of
their EDI infrastructure in favor of something new. They have sunk costs
they want to recover if they can.
There is also a possibility that the final compliance deadline might be
extended.
Rachel
Rachel,
The US Congress, besides being in turmoil at the moment, is a little
unpredictable and very open to the concerns of lobbyists. It is interesting
that the HIPAA legislation was passed the same year as the
Telecommunications
deregulation act. There is legislation in Congress to essentially gut the
1996
Teleco act and has strong backing. I'm not predicting but don't be
surprised
what may happen with HIPAA.
Dave Frenkel
----- Original Message -----
From: Rachel Foerster <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 24, 2001 9:38 AM
Subject: Re: Dual 997's
> Paul,
>
> As I said, I too, used to argue strongly for independence and separation
of
> function. However, the real world is that one's clients don't always agree
> and they want (no demand) a down and dirty solution. Anyone who's been in
IT
> for a while has most likely been caught between the rock of "good design"
> and the hard place of "expediency."
>
> One could starve and see one's home foreclosed by standing on the beach of
> "proper design", etc. and not help your clients solve their problems in a
> way that works but is also acceptable to them. I could be a purist all the
> way to the poorhouse.
>
> Don't worry too much about new/emerging technologies for the health care
> claims (administrative processes). In its utter wisdom our Congress
decided
> to embed in legislative concrete the use of the X12 EDI syntax! Go figure!
>
> Rachel
>
> --------------------------------------------------------------------------
--
> ---
>
> Rachel:
>
> I believe that business rules should always be separated, even for
> non-volatile, bureaucratic stuff like health-care claims. Because then you
> have flexibility to quickly adapt your business to external forces such as
> new programming tools (think Java, VB.Net) or to new communications
> protocols (think HTTP, XML).
>
> In business application software design, the holy grail is to separate
> business logic from any other factor - presentation, data access method,
or
> protocol. Additionally, this functional separation does not entail any
time
> delays. What's not to like ?
>
> Cheers,
> Paul
>
> |-----Original Message-----
> |From: Electronic Data Interchange Issues
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster
> |Sent: Wednesday, May 23, 2001 11:48 AM
> |To: [EMAIL PROTECTED]
> |Subject: Re: Dual 997's
> |
> |
> |Paul,
> |
> |I too used to argue strongly for not applying any business
> |rules during the
> |transaction process. However, over time I'm come to realize
> |that there are
> |benefits to doing so. I'm not saying that ALL application
> |edits are moved
> |into the EDI system, but rather a subset of them. One of the
> |reasons used in
> |the past for not trying to apply business rules in the EDI
> |system was that
> |yesterday's EDI systems were inadequate to the task. Today's
> |systems are
> |not. The sooner one identifies errors and returns acks back to the
> |originating system is a better approach. Else, why have
> |pre-order processing
> |systems that handle dialogue directly with customers prior to passing a
> |complete and correct order in to the order management system?
> |
> |But, I'm not at all advocating that everyone take any one
> |approach. Let each
> |enterprise determine what makes best business sense for itself and its
> |trading partners. I'm all for flexibility and agility and less
> |rigidity.
> |
> |Rachel
> |
> |
> |Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
> =======================================================================
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
> =======================================================================
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
