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/
