OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-dev] ebXML core components derivation by restriction


Edward, just one small nit to pick with your comments below regarding the
U.S. Health Insurance Portability & Accountability Act of 1996 (HIPAA).
While you are correct in saying that the actual legislation itself does not
adopt or mandate the use of a particular technology, unfortunately, the
enabling regulation - The HIPAA Electronic Transaction Final Rule - does. It
adopted implementation specifications based on the ASC X12 standards as well
as some based on the NCPDP standards. As a result, the use of the ASC X12
standards is now embedded in U.S. Federal Regulation for several financial
transactions, including health care claims, health care claim payments and
remittance advice, and several others.

The U.S. health care is now paying dearly to try to implement and deploy
just the health care claim transactions with dismal success and huge cost. 

Thus, what has and is happening in the U.S. is a prime example of the law of
unintended consequences when government, either through legislation or
regulation, mandates the use of a specific information technology on a major
sector of a country's economy in the blind hope that by doing so, the mere
use of a technology will optimize processes and remove cost. What a March of
Folly!

Rachel Foerster
Rachel Foerster & Associates, Ltd.
39432 North Avenue
Beach Park, IL 60099
Voice: 847-872-8070
www.rfa-edi.com

 

-----Original Message-----
From: Edward Lipski [mailto:ELipski@p21.com] 
Sent: Monday, August 02, 2004 9:36 AM
To: 'sggould@oic.org'; ebxml-dev@lists.ebxml.org
Cc: Australian Senator; OIC Management Committee
Subject: RE: [ebxml-dev] ebXML core components derivation by restriction

On Tuesday, August 03, 2004 11:15 AM Stephen Gould wrote:

>1	the US negotiated a Treaty while not disclosing in the treaty 
>	with a major ally (Australia) that the US had passed legislation 
>	that proved the US was implementing non-ISO standards so
>	that US companies could generate income from acting as 
>	Agents for"Document re-formating and re-routing"
>     http://www.oic.org/z/FZIG/A/ds/611BACE1.htm
>
>2	The US is using the Fear Factor of "Defence against Terrorism"
>	to co-erce allies into signing these agreements
>
>3	while at the same time aiding and assisting the Zionist 
>	Government to provoke Terrorism

1. The legislation pointed to by your link above - HIPA (Health Insurance
Portability and Accountability act) was passed in 1996 (under the Clinton
Administration), and as the name suggests only legislates health and medical
information. From my personal meetings with US legislators I can assure you
that they have no concept of X12, EDIFACT, or XML, and their Staffers who do
understand the differences wouldn't want either legislated (they want it
decided by the market). HIPA was meant only to address US-domestic health
privacy, and healthcare cost concerns, and it is still under some
controversy today.
Also, there are so many highly paid lobbyist in Washington DC (Many openly
employed by other Nations like China, and Australia) that I doubt that the
companies who could make money from "Document re-formatting and re-routing"
could possibly compete for the attention of the US Federal Government. 
The US has many times in the past modified previous legislation that has
been in conflict with recent Treaty obligations. 

2. and 3. I really don't see how this blind anti-American rubbish belongs on
a technology standards list. 

Moreover, the points made by Stephen Gould rely on a false premise. That
either the Australian government (and all non-US governments by implication)
is too incompetent to negotiate their own treaties, or that the US
government is much smarter, and more clever than other governments. Do you
really believe either to be true? 

Thank you.
Ed Lipski
Manager of Integration Technology
Prophet 21, Inc.




-----Original Message-----
From: Stephen GOULD [mailto:sggould@oic.org]
Sent: Tuesday, August 03, 2004 11:15 AM
To: ebxml-dev@lists.ebxml.org
Cc: Australian Senator; OIC Management Committee
Subject: RE: [ebxml-dev] ebXML core components derivation by restriction


Ron -  I agree with you that there needs to be a global non-profit
organisation "The UDEF tree structures need to be managed by a global
non-profit"

The key issue is that the rest of the world cannot afford for "the global
non-profit organisation" to be US based.

The recent deceitful behaviour by the US with the Australia-USA Free Trade
Agreement [Aus-USA-FTA] has shown that the US intentions are about
electronic imperialism and the US uses Standards to generate revenue for US
companies and US companies only

The deceitful behaviour is that:

1	the US negotiated a Treaty while not disclosing in the treaty 
	with a major ally (Australia) that the US had passed legislation 
	that proved the US was implementing non-ISO standards so
	that US companies could generate income from acting as 
	Agents for"Document re-formating and re-routing"
http://www.oic.org/z/FZIG/A/ds/611BACE1.htm

2	The US is using the Fear Factor of "Defence against Terrorism"
	to co-erce allies into signing these agreements

3	while at the same time aiding and assisting the Zionist 
	Government to provoke Terrorism

BACKGROUND

In 1991 I spent 3 months with the European Aerospace Association [AECMA]
discussing how to facilitate the exchange of information between
stake-holders in the Eurofighter Collaboration
http://www.halisa.net/9/9EAECFD1.gif

These meetings were supported by the Australian Trade Commission with
discussions on CALS http://www.halisa.net/C1/Austr91.jpg

15 years down the track the US is legislating for the US ANSI-X12 Standards
while the rest of the world moves towards ISO Standards which are supposedly
supported by the US.

Ron - a large number of people around the world are donating a lot of time,
effort and resources while the US is being very deceitful.

NEXT STEPS

I look forward to a simple explanation as to why:

1	the US is legislating for ANSI-X12 Standards while 

2	participating on ISO Standard committees like UN/EDIFACT and

3	negotiating Free Trade Agreements that do not reveal what 
	standards will be used in Electronic Commerce

Regards

Stephen GOULD
Chair - Management Committee
XML & E-commerce Special Interest Group
OPEN INTERCHANGE CONSORTIUM

E:	sggould@oic.org
T:	{61}(2) 9953-7412
W:	http://www.oic.org/3a4a.htm


On 30 Jul 04, at 11:05, Schuldt, Ron L wrote:

> Fred,
> 
> <Ron>How much lag time is possible between the time an extension is
requested and it gets approved by TBG17? Does the TGB17 Working Group meet
periodically to review proposed extensions or is it an ongoing process?
If
they meet periodically, what is the frequency? Are the procedures and
decision criteria published somewhere? Where is the current library of CCs
and BIEs published?</Ron>
> 
> <Fred>TBG17 now has telecons every week. As a matter of fact 
> yesterday,
during our mail-conversation we had one. The group is building up its
procedures, by assessing the first (eight?) submissions from industry
groups. As all this stuff is new to everybody we must find the best way by
just doing it. After next week we'll have a full week F2F. We envisage it is
ongoing work and we hope by finetuning the procedures and learning from
people like you who have experience in ontology-engineering in the future to
automize (or at least do an automatical pre-assessment of) most of the work.
Both the draft procedures and the first draft list of CC's have been
published in the UN/CEFACT community. Please contact Alan Stitzer
(Alan.Stitzer@marsh.com) who is leading the project.</Fred>
> 
> If a health and medical organization submits proposed extensions, does
TGB17 intend to consult neutral third party subject matter experts in the
health and medical field who are also knowledgeable of the total current
content in the CCs and BIEs library and therefore will assure all users that
there is no conflict? 
> 
> IMHO, the task that TGB17 is beginning to undertake will soon require 
> the
support of automation (software and an underlying database) and a solid
ontology and a commitment from neutral third party subject matter experts in

order to populate the library with artifacts that do not conflict with each
other. I also believe that the library needs to have a structured ID (like a
Dewey Decimal
ID) or the library will soon become useless due to its size. 
> 
> The UDEF is an approach that could satisfy all of the above 
> requirements -
an
ontology that is relatively simple to understand and can be easily mapped to

CCTS, software (that invokes a workflow that ties in to subject matter
experts and provides an initial screening for conflicts) and a database that
helps prevent semantic collisions within the ontology, and a built-in
structured ID that provides an indexing mechanism that computers can use
across the globe. The ID uses a

syntax very similar to an IP address (number.number.number) that computers
can handle quite readily and that can leverage DNS technology to convert the
ID to a name or vice versa.
> 
> The UDEF tree structures need to be managed by a global non-profit. At
this
point in time, the global non-profit that would take responsibility for
managing the UDEF tree structures has not been selected. Is TGB17 possibly
interested in becoming that global non-profit? If so, I will share the
specification that was developed by the aerospace industry that details the
requirements that the global non-profit must do in order to allow the
"library" (global registry) to succeed.
> 
> Ron Schuldt
> Senior Staff Systems Architect
> Lockheed Martin Enterprise Information Systems
> 11757 W. Ken Caryl Ave.
> #F521 Mail Point DC5694
> Littleton, CO 80127
> 303-977-1414




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC