If I can sum up the last few days of discussion that I have just waded
through: as a transaction sender I should be able to follow the workflow
below, starting with the responsible party's insurance card:
1) Copy the payer's identifier information from the card into a query
transaction (note ther
William,
I think you are making an assumption that may not be true in all
organizations. Many large payers and Medicaid's run multiple systems
that may physically separate claims from eligibility onto separate
platforms. I think your assumption is there will be a single
translator/communications
Isn't the small size of these identifiers the main reason why we have to
"map" the identifiers into an address?
It is still trivial and reliable and cheap to do this using the currently
existing DNS, using a small XML tag in the TXT component of the DNS
directory, just like William has his set
well... the small size of the ISA08 field, combined with the variety of
application-specific addressing requirements, and the general reluctance to
require receivers to "drill" further in to ferret out more addressing
"clues"... would certainly seem to MANDATE the existence of one or more
regi
Now, as Rachel would say, I think I'm getting "wrapped around an axle"
with this ISA and GS stuff. After thinking about it, the GS should only
be used for internal routing by the recipient - something we all learned
in EDI 101. No intermediary or communications package should ever have
to "drill
Chris:
We probably shouldn't call ISA08 an "EDI Address." It's the recipient's
EDI Identifier. An "EDI Address," as Peter Barry would remind us, is
all the technical mumbo-jumbo that defines the protocols, port addresses
and other desiderata for moving EDI data to a particular point (e.g.,
FTP