PROOF USA LEGISLATED FOR ANSI-X12 STANDARD

It is beginning to look like as if the Consultancy that won the contract to carry out the "National Interest Analysis"
into the Aus-USA FTA produced the document on the 24 March 2004 may have been negligent in their assessment of the
Legislation issues.  The NIA totally overlooked the issues of Legislation and Standards with Chapter 16: Electronic
 Commerce.

It is of more concern that the Joint Standing Committee of Treaties [JSCOT] totally missed the issue that the 
US has legislated for ANSI-X12 Electronic Commerce Standard while Australia is committed to the ISO
Standard with previous Treaties.

Fortunately it is not too late for the Senate Inquiry to review the implication of the conflicts as outlined
by these e-mails from the ebXML Electronic Commerce developers user Group.

It will be interesting to see if the people who carried out the research and prepared the reports for the 
Australian Government will refund their fees or will the Government sue them for negligence ?

Highly unlikely - the first rule of Consultancy is to ask the client what is the outcome that is required in the report !

So who commissioned the Reports ?


 E-MAILS FROM EBXML DEVELOPERS STATING ANSI-X12 IS US STANDARD


To:             	
Subject:        	RE: SV: [Fwd: Re: [xml-dev] Edi complexity, does ebxml really  reduce  it?]
Date sent:      	Tue, 13 Jul 2004 12:37:41 -0500
Organization:   	Rachel Foerster & Associates Ltd

[ Double-click this line for list subscription options ] 

And to further develop the health care aspect, Mike, as you know, in the United States, the use of the X12 standards is
now mandated by federal regulation as required under the HIPAA legislation.

What makes the use of ebXML and the Internet even more of an issue for the U.S. health care market is that the largest 
payer of health care (Medicare) currently prohibits any Medicare patient data to be sent over the Internet,
whether or not encrypted. 

Since the average health care provider derives in excess of 50% of total revenue by providing health care services to 
Medicare-covered patients, use of ebXML and the Internet is effectively stalled.

The second major hurdle is the HIPAA Security Regulation which requires that HIPAA covered entities must **address** the 
use of encryption when using insecure networks to transmit electronic protected health information
(ePHI). 

Given that more than 80% of health care organizations in the U.S. can be classified as small businesses, they are 
totally reliant on their application systems and other vendors to provide the enabling technologies at an affordable cost. 

Without a **standard** interoperable encryption solution that can be used by the hundreds of thousands of small healthcare
providers as easily as they use a fax today with diverse and disparate systems, exploiting the Internet and ebXML will 
remain a dream and a vision (although one that I've been dreaming of for years!!!)

Rachel

-----Original Message-----
From: Mike Rawlins [mailto:mcr@rawlinsecconsulting.com] 
Sent: Tuesday, July 13, 2004 11:25 AM
To: ebxml-dev@lists.ebxml.org
Subject: Re: SV: [Fwd: Re: [xml-dev] Edi complexity, does ebxml really
reduce it?]
At 05:16 PM 7/13/2004 +0200, Bryan Rasmussen wrote :

>Then, reading
>http://www.sterlingcommerce.com/PDF/ResourceCenter/RPA-032002-00008.pdf
>"The EDI market can be split into two logical units: general-purpose 
>EDI and health-care EDI. 
>
> For the most part, there is very little interplay between these  two groups and their internal dynamics are quite 
> different from one another. 
>
> For  example, the general-purpose EDI area is made up of participants in many  different vertical sectors that purchase 
> EDI software and services from a group  of established vendors that provide basic EDI functionality. 
>
> This is by far the  largest segment of the EDI market. The smaller health-care EDI area is unique in  that the vendors
> in this space do not sell EDI software, but rather charge their customers for access to hosted translation and document 
> exchange services that  are specific to the health-care industry. 
>
>Shielding the smaller businesses from the complexity and levelling the playing field.


>>Two points here - First, I do not necessarily agree with this characterization by the fine folks at Sterling.  
>>
>>The service provider model is gaining ground among smaller, "general-purpose" EDI users as well.  
>>
>>This is evident in the number of "web-based EDI" services that are available. 
>>
>>One thing that *is* different about health care is that the service providers tend to do a lot more than what EDI 
>>VANs do. 
>>
>>Reformatting and rerouting claims are just two examples of the added services.  

Question: WHo has to reformt and rerout faxes ?  Answer: No-one so why do you have to do it for EDI ?
>>
>>They are generally referred to as "clearing houses", and they were performing these functions long before health care 
>>in the U.S. started adopting X12 EDI formats.
>>
>>Second - Although it might happen in other countries, having government organizations in the U.S. provide ebXML 
>>services is a political non-starter.
>>
>>A model which might be more likely is for larger hubs to assist smaller partners in coming on board, in much the same 
>>way that they have with EDI.
>>
>>However, the most significant hurdle is for the vendors who sell applications to smaller businesses to get on board.   
>>
>>So far, most have been dragging their feet on even implementing nonproprietary XML documents, let alone things as 
>>complex as ebXML or web services.
>>
>>Cheers,
>>
>>Mike


The ebxml-dev list is sponsored by OASIS  

The list archives are at http://lists.ebxml.org/archives/ebxml-dev/

To subscribe or unsubscribe from this list use the subscription manager: