Upon first reading of Harry Steck's letter, you might get the impression
that the U.S. Department of Defense (DOD) is in litigation because of
EDISIM; see the EDI-L archives at
http://www.mail-archive.com/[email protected]/msg02553.html.
Though he knows nothing of the facts of this supposed litigation, nor
can explain how in the world EDISIM has anything to do with the matter,
Harry is content to leave us believe some crisis ensues which could
bring down the entire edifice of HIPAA. And because of Mr. Steck's
unsuccessful struggle to form coherent ideas using the English language,
Dave Frenkel has, as many people would be expected to, interpreted his
harangue as "...the DOD is suing X12 in reference to HIPAA IG's."
Though Harry has identified himself as retired from the United States
Air Force - and some of us are deeply appreciative of his service to our
Nation - it would have been more professional and enlightening for him
to identify his present business affiliation in his signature, so we can
see why Jonathan Allen hides behind his skirt.
But perhaps I can address this issue because I am aware that Messrs.
James Wooten, of the DOD, and Bob Miller, of GEIS and the former X12C
chair, developed X12's answer to the Request for Interpretation (RFI) to
which Mr. Steck alludes, but is seemingly unable to articulate.
The DOD is in the rather unfortunate position of being sued by every
jackass nit-picker that comes down the pike. In this case, somebody
supposedly passed an X12 interchange to the DOD with the ISA
(Interchange Control Header) containing all underscore (_) characters in
one or the other - or both - of the ISA02 (Authorization Information) or
the ISA04 (Security Information) fields. The respective qualifiers
(ISA01 and/or ISA03) were set to '00', saying "No Meaningful
Information" was present in the respective Authorization or Security
fields.
Part 10 of the Federal Implementation Guidelines for Electronic Data
Interchange (EDI) - Federal Conventions for Using ASC X12 Transaction
Sets - clearly states that the Authorization or Security fields are to
be filled "with blank characters" in this case. See
http://snad.ncsl.nist.gov/fededi/guideline.html. Presently, the DOD's
translator must have checked the field(s) for blanks, and rejected the
interchange. Rather than simply fixing (or modifying) the ISA fields to
suit the Government, somebody wanted to make a "federal" case of this
nonsense.
More information on the RFI can be obtained from the October 2000
Trimester Meeting minutes of X12C (Communications and Controls). Go to
http://www.x12.org/, select the "Minutes Finder" feature, then check
both "X12C - Communications and Controls" and "October 2000 Trimester
Meeting". As Secretary pro tem of X12C, these notes were taken of my
own hand. Relevant passages refer to PP 786 - the project proposal
dealing with the DOD's Request for Interpretation, and DM 168300 - the
data maintenance item designed to fix the ambiguity in the X12 standard
related to the blanks problem in ISA02/ISA04:
We have an old Request for Interpretation on ISA02/ISA04
(PP 786), for which Mr. James Wooten is responsible - the
old blanks in the ISA sender and receiver fields bugaboo.
Mr. Miller says the BNF in X12.5 can override element type
restrictions. We laboriously discussed what the "00" code
to "ignore" in the ISA qualifier means. In a dispute like
this, syntax wins. But we should lock down everything by
explicitly allowing blanks. This matter will be discussed
in X12C TG1 this afternoon, and we'll bring the RFI letter
back to the full X12C subcommittee.
DM 168300 was presented by Mr. Miller, which allows all
blanks in the ISA sender and receiver fields. We chose not
to make changes disallowing negative control numbers,
which make the ISA not fixed length. A "00" code qualifier
in I01 means that no meaningful information is present in
the respective sender or receiver field, leading to
ambiguity. But the address is a mandatory fixed length
field, so people put spaces in it. X12.5 says in the BNF
that it must have non-blank in it, because it is a string.
Now to make the situation legal, and allow the blanks in
X12.5, we'll have the BNF explicitly allow the blanks in
addition to using <string>. And we only want to allow
blanks in event the qualifier is 00 - not in other
situations. Section 5.1.2 in X12.5 has changes to make
this clear. Lots of discussion ensued. Eventually we're
going to need a future DM to say the BNF has precedence.
X12C's dirty secret is the fact the ISA is NOT a fixed
length record. Most members in a straw poll do want to
fix the ISA control numbers to exclude negative numbers,
and there's already a BNF construct for unsigned integers.
We don't want to break existing systems, and the changes
to X12.5 that Mr. Miller proposes solely use BNF to fix
the problem. By way of background, Mr. Miller says we
extend element data values with blanks to get to the
minimum length - but the BNF says we need at least one
non-blank. We will continue to hair-split at the next
meeting, and Mr. Miller was thanked for his present
hair-splitting. A new motion was approved 11-0-0 to
remove the previous motion to pass this DM on, as we want
to deferit.
Status of letter on RFI: Mr. James Wooten wrote the letter
and Bob Miller will clean it up. We must get the RFI out by
the next meeting in Seattle to fit in the one year window
for returning interpretations. X12C writes the letter, and
then X12J TAS reviews and approves it. The RFI then goes to
PRB for due process considerations, which is subsequently
sent out with the X12 chair's (David Barkley) signature. In
fact, the Chair of X12C could sign, but really hot potatoes
should be signed by the big kahuna himself, in the person of
the X12 chair. Mr. Miller needs to get the RFI to Mr. Slater,
so the latter can discuss it in the interim X12J meeting.
Returning to the RFI, we discussed ambiguity in the standard.
The standard is not clear. Our clarification is to communicate
the intent, and to clarify that this is the normative behavior
in the industry. The RFI concerns the ISA sender and receiver
fields. The standard as written is not clear - rather, it's
ambiguous. However, the clear intent was in 004010 (and in all
previous versions) that this Current industry practice is
normative and proper. Other usage, such as filling out the
field with other characters is also correct, but shortening or
omitting the fields altogether is totally unacceptable, because
the ISA is treated as a fixed length record.
Apparently, my hand wasn't all that steady, since I erroneously reported
that the ISA sender and receiver fields were at issue, when, in fact,
the blank Authorization and Security fields were the culprit.
In summary, the U.S. DOD is not suing X12, and the ISA Request for
Interpretation has nothing to do with HIPAA. And in answer to Harry's
question, "...has Foresight been asked for comments in the DoD's
case?," I can only ask why the heck would the DOD ask us? The DOD asked
X12 in the form of an RFI.
William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600
Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
