Yes, whether it is an automated or manual re-send, the re-send attempts cannot occur more frequently than what is specified in the CAQH CORE Operating Rule.

For consistency and ease of development, CAQH CORE decided that it was important to have a single standard. Based on that decision, and the fact that many batch processing information sources cannot commit to having the ASC X12 Implementation Acknowledgement (999) available in 20 seconds, CAQH CORE elected to mandate that the ASC X12 Implementation Acknowledgement (999) not be provided in the HTTP response.

There are no more precise specifications in the Phase I CAQH CORE 153: Connectivity Rule. This decision is left to the message originator.

Such a message would represent a CAQH CORE non-compliant message. The Phase I CAQH CORE 153: Connectivity Rule does not require such a message to be either rejected or accepted by the receiver. It is the receiver's decision regarding acceptance of a non-compliant message.

An XML-based eligibility inquiry and response equivalent to the X12 270/271 cannot be used in place of HIPAA-mandated standard form as specified in the X12 270/271 TR3. However, your organization can accept the X12 270 into its EDI system either directly from a provider or through a clearinghouse and then convert it into another format for internal processing, e.g., XML or some other proprietary format. Also, for the purposes of the CAQH CORE Connectivity Rule, organizations can specify an XML based message "wrapper" around the X12 Interchange of 270 and 271 transactions.

Yes. Each health plan seeking CORE Certification would have to work with its clearinghouse and/or vendor to jointly complete CORE Certification testing in order for the health plan to be awarded the CORE Certification Seal. A clearinghouse or vendor would not be able to certify “generically” as a health plan and then transfer such certification to any health plan.

Under the CAQH CORE Operating Rules, information sources must provide a programmatic interface to allow an automated task whereby the provider's system requests the batch of X12 271 responses be transferred to the provider's system without a need for human intervention.

An entity should expect to receive a long, possibly alphanumeric, ID from its trading partners and should be able to store that ID and associate it with each X12 real time messages processed from the trading partner through the supported HTTP communication system. From a technical perspective, most submitters will use some sort of globally unique ID or universally unique ID (GUID or UUID) as their payload ID so receivers should allocate a data field that can contain at a minimum the 128 bits required to store a GUID/UUID.

No. It is unique to each HTTP message instance and the payload being transported by HTTP.

The payload ID does not get carried through to the content of the X12 271 response. In the real time usage, the submitter can link the X12 271 response to the payload ID because the X12 271 response in the real time mode is passed within the same communication session used to send the payload ID and requesting the X12 270. In the batch usage, the acknowledging response to the submission is sufficient to record that a particular payload was successfully delivered.