|
Amen!
Well said, Rachel!
The opinions expressed here are my own and not necessarily the opinion of
LCMH.
Douglas M. Webb Computer System Engineer Little Company of Mary
Hospital & Health Care Centers [EMAIL PROTECTED]
"This electronic message may contain information that is confidential
and/or legally privileged. It is intended only for the use of the individual(s)
and entity(s) named as recipients in the message. If you are not an
intended recipient of the message, please notify the sender immediately,
delete the material from any computer, do not deliver, distribute, or copy this
message, and do not disclose its contents or take action in reliance on the
information it contains. Thank you."
----- Original Message -----
Sent: Wednesday, December 11, 2002 01:56
PM
Subject: RE: Submitter Transaction
Identifier - 270/271
A
further thought on this issue of allowing various entities that "touch" the
transaction set to change/modify any data within it thus comprises the
integrity of **all** the data in the transaction set since there is now no
assurance that no other data value was changed along the route....what about
dollar amounts, identifiers, etc.
Modifying the data of any business transaction, whether an X12
transaction set or a proprietary file, is a major violation of data integrity
requirements and a major security violation. Once you engage in this practice,
there is no assurance of any data integrity.
Rachel
Foerster
John,
I'm
well aware of how the X12 control segments work and that the BHT03 is
"situational" under HIPAA. I've been an active member of the X12 Committee
since 1987, and also an active member of the X12C, X12K (purchasing SC
when it still existed), X12J Technical Assessment and now X12N
Subcommittees.
Regardless, I still believe that it's not appropriate to
change the business data within the transaction set. If the originator of
the 270 inserts a value in BHT03 that original value must be maintained
throughout the entire transaction set's lifecycle, from originator through
clearinghouse (or VAN) to the payer and should be returned by the payer. My
opinion is that this is a violation of data integrity requirements under any
reasonable security scheme. Thus, the original value inserted into BHT03 by
the originator should **not** be changed at every pit
stop.
Rachel
Foerster
Ellen..thanks for your response. That was very well explained.
Rachel...BHT03 is optional, assigned by the originator to identify the
transaction within the originator's business application system and
changed at every pit-stop. You don't have to use it if you don't need it.
But, if you receive it you have to return it back on 271.
A Transaction set control no.(ST02 - Header) is required, unique within
an interchange, and this is the no. which remains unchanged during the
entire transaction flow between payer and provider.
Hope that helps.
J
Rachel Foerster <[EMAIL PROTECTED]>
wrote:
What a mess! Why not just pass the originally received 270 intact
on to the payer and back without modifying the data received from the
originator? Actually, my opinion is that such a modification violates
the basic data integrity of any information security policy and
procedure: confidentiality, integrity, access.
The X12 standards have built into them in the various control
segments and control data (date/time stamps, identifiers, control
numbers) that clearinghouses, etc. can use for receiving, storing and
forwarding transactions to the intended receiver. Other industries,
including the medical products and pharmaceutical supply
chains, that make extensive use of the EDI X12 standards don't fool
around with the business data contained within a transaction set, and
health care administrative simplification under HIPAA shouldn't do it
either.
Rachel
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic
Commerce
39432 North
Avenue
Beach Park, IL
60099
Voice:
847-872-8070
Fax:
847-872-6860
eMail:
[EMAIL PROTECTED]
http://www.rfa-edi.com
Provider assigns a number (say, 123) to the
BHT03 and passes the 270 transaction to the clearinghouse.
Clearinghouse stores the provider's number and populates a new number
(say, 456) before passing the 270 transaction to the payer.
Payer returns the 271 response with the clearinghouse's number
(456). Clearinghouse grabs the 271 transaction, re-populates the
BHT03 with the provider's number (123) from the 270, and returns the
271 to provider. This also works if the transaction travels
through multiple clearinghouses. It allows the clearinghouse to
keep track of each response even when multiple providers assign the
same number (a likely scenario).
-----Original
Message-----
From: John Branwell
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 11,
2002 12:28 PM
To: WEDI SNIP Transactions Workgroup
List
Subject: Submitter Transaction Identifier -
270/271
My question is regarding Submitter Transaction Identifier(BHT03 -
Header). The guide notes states -
".. This identifier is to be
returned in the corresponding 271 transaction's BHT03. This identifier
will only be returned by the last entity to handle the 270. This
identifier will not be passed through the complete life of the
transaction. All recipients of 270 transactions are required to return
the Submitter Transaction Identifier in their 271 response if one is
submitted."
Considering the following two statements :
1> This identifier
will not be passed through the complete life of the
transaction.
2> This is the number assigned by the originator to
identify the
transaction within the originator's business
application system.
My question is that for statement <2> to happen the provider
needs to receive the same number back on 271. But, if the number
doens't get passed throughout the lifecycle of the transaction(as
stated in statement <1>), how will the provider receive it back
on 271?
I am certainly missing something out here. Please comment
and clarify.
Thanks in advance.
John ---
---
The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time.
You are currently subscribed to wedi-transactions as: [email protected]
To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED]
If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
|
