Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 2 HIPAA Transaction Configuration : HIPAA Transaction Configuration

HIPAA Transaction Configuration
HIPAA Transaction Guidelines
All of the HIPAA guidelines provided by TIBCO BusinessConnect EDI Protocol HIPAA Edition powered by Instream are organized into subdirectories under BC_HOME/protocols/tibedi/samples/sampleDocs/guidelines according to the version of the guideline. For example, version 5010 guidelines are located in the following directory:
BC_HOME/protocols/tibedi/samples/sampleDocs/guidelines/5010_txns
Table 5 lists the HIPAA transactions and their associated guidelines:
Guidelines that are designated as real-time transactions have limits applied as follows:
270 Transaction - number of patients limited to 1
276 Transaction - number of claims limited to 1
Guidelines that are designated as batch transactions have limits applied as follows:
270 Transaction - number of patients limited to 99
276 Transaction - number of claims limited to 99
Simplification of HIPAA Guideline Configuration
The HIPAA transactions are standard, therefore the same transaction guideline should be used for all Trading Partners unless you need to work around a situation in which one of your Trading Partners cannot yet send or receive HIPAA compliant transactions.
To facilitate the configuration of HIPAA transactions, it is not necessary to upload the .std files for the guidelines listed in Table 5.
By not uploading the guidelines, the size of your repository will be reduced. If you have created transaction bindings for any of your trading partner configurations, the guidelines will not be exported with the trading partner configuration unless you have overridden the guideline. Therefore, not uploading the HIPAA transaction guidelines can also have the effect of reducing the size of your trading partner configuration exports.
CAQH Compliant HIPAA Transactions
The Committee on Operating Rules for Information Exchange (CORE®) Connectivity & Security Subgroup of the Council for Affordable Quality Healthcare (CAQH) has defined envelope, submitter authentication, and error processing standards to improve interoperability and utilization between healthcare providers, clearinghouses, health plans as part of its CORE Phase II and Phase IV Connectivity Rules.
The CAQH CORE Connectivity Rule was developed using a consensus-based approach, and is designed to facilitate interoperability, improve utilization of administrative transactions, enhance efficiency, and lower the cost of information exchange in healthcare. The key goal of the Connectivity Rule is to:
The Phase II Connectivity rule applies to the following batch and real-time transactions sent with the X12 protocol over the HTTPS transport:
The Phase IV Connectivity rule applies to the following administrative transactions when trading partners are exchanging any transaction specified in the third set of the Affordable Care Act (ACA) 1104 over SSL based authentication:
Organizations may apply this rule to other X12 transactions, but are not required to do so to be considered CORE-compliant. If this is the case, both trading partners must agree to adhere to the rule outside of the scope defined above.
The complete rules for Phase II and Phase IV are available in the following docs: https://www.caqh.org/sites/default/files/core/phase-ii/policy-rules/270-v5010.pdf
https://www.caqh.org/sites/default/files/core/phase-iv/470-connectivity-rule.pdf
CAQH CORE Envelope Standards
The CAQH CORE Connectivity Rule requires that health providers, clearinghouses, and health plans support sending, receiving, and processing and SOAP message envelopes. Further, the rule requires that these message envelopes follow specified normative (for SOAP+WSDL envelopes) schemas. These schemas require that fields such as PayloadID, PayloadType, and CORERuleVersion be included in the message envelope. TIBCO BusinessConnect EDI Protocol HIPAA Edition powered by Instream supports CORE-compliant transactions sent using the X12 protocol over HTTPS by packaging private process messages according to these requirements. See Chapter 5 Setting Up Trading Partners, CAQH Tab in the TIBCO BusinessConnect EDI Protocol powered by Instream X12 Configuration document for more information about configuring BusinessConnect to package messages in conformance to CAQH CORE requirements.
 
 
 
 
Private process messages sent to BusinessConnect require the following fields to conform to CAQH CORE standards:
Initiator Outbound Request (INITIATOR.REQUEST)
enableCAQHPackage   This boolean field specifies if it is a CAQH or non-CAQH package. You set the value to 1 to enable if it is a CAQH package or set the value to 0 to specify that it is not a CAQH package.
CAQHOperationID   This string field describes the pre-defined CAQH operation ID.
PayloadType   This conversational field describes the type of document (request, response, confirmation, or acknowledgement) and the type of transaction. You must define this field in the private process message for CORE-compliant packaging.
PayloadID   This string field is the ID for the payload of the message.
SenderID   This string field is the ID of the sender of the message.
ReceiverID   This string field is the ID of the receiver of the message.
authenticationToken   This field combines the user name and password fields.
userName   This string field is the user name that is entered to validate at the responder side.
password   This string field is the password that is entered to validate at the responder side.
Initiator Inbound Response (INITIATOR.RESPONSE)
CAQHOperationID   This string field describes the pre-defined CAQH operation ID.
PayloadType   This conversational field describes the type of document (request, response, confirmation, or acknowledgement) and the type of transaction. For Initiator Response messages, the payload type is received from the trading partner as part of an actual request.
ProcessingMode   This field describes the type of transaction - real-time or batch.
PayloadID   This string field is the ID for the payload of the message received from a trading partner.
TimeStamp   This string field indicates the time at which the message is sent.
SenderID   This string field is the ID of the sender of the message.
ReceiverID   This string field is the ID of the receiver of the message.
ErrorCode   This string field is the error code that is displayed.
ErrorMessage   This string field is the error message that is displayed against the corresponding error code.
Responder Inbound Request (RESPONDER.REQUEST)
CAQHOperationID   This string field describes the pre-defined CAQH operation ID.
PayloadType   This is the payload type received from a the trading partner when an actual request is received from the partner.
ProcessingMode   This field describes the type of transaction - real-time or batch.
PayloadID   This string field is the ID for the payload of the message received from a trading partner.
TimeStamp   This string field indicates the time at which the message is sent.
SenderID   This string field is the ID of the sender of the message.
ReceiverID   This string field is the ID of the receiver of the message.
ErrorCode   This string field is the error code that is displayed.
ErrorMessage   This string field is the error message that is displayed against the corresponding error code.
Responder Outbound Response (RESPONDER.RESPONSE)
CAQHOperationID   This string field describes the pre-defined CAQH operation ID.
PayloadType   This string field describes the type of the response file that is sent back to BusinessConnect.
PayloadID   This string field is the ID for the payload of the message.
SenderID   This string field is the ID of the sender of the message.
ReceiverID   This string field is the ID of the receiver of the message.
CAQH CORE Submitter Authentication Standards
The CAQH CORE Connectivity Rule requires that clearinghouses, health plans, health providers, and other organizations that act as a server support an authentication method to enforce access control. Organizations that act as clients must authenticate themselves to the server. TIBCO BusinessConnect EDI Protocol HIPAA Edition powered by Instream supports authentication by populating the user name and password fields of outbound SOAP message envelopes. The trading partner—generally a clearinghouse or health plan—that receives such messages uses these fields to authenticate against its external authentication system. See Chapter 4 Setting Up Trading Hosts, General Tab in the TIBCO BusinessConnect EDI Protocol powered by Instream X12 Configuration document for more information about configuring BusinessConnect to package messages in conformance to CAQH CORE requirements.
CAQH CORE determined that converging on the use of the X.509 digital certificate as the single authentication standard in the CAQH CORE Phase IV Connectivity Rule v4.0.0.
 
HIPAA Transaction Configuration
HIPAA transactions are specialized versions of X12 transactions and are, therefore, configured in the same way. Using the TIBCO BusinessConnect Operations Editor, you can:
For detailed information on how to configure X12 transactions see Chapter 3, Managing X12 Interchanges, Functional Groups, and Transactions, in the document TIBCO BusinessConnect EDI Protocol powered by Instream, X12 Configuration.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved