Frequently Asked Questions - General Connectivity FAQs

  1. How does an entity determine which version of CAQH CORE Connectivity to use when implementing a set of CAQH CORE Operating Rules?
  2. What is the CAQH CORE Connectivity Safe Harbor?
  3. How should entities track X12 transactions when using another connectivity method, as permitted by the CAQH CORE Connectivity Safe Harbor?
  4. My organization’s security procedures require that clients use a digital certificate to identify themselves. Under the CAQH CORE Operating Rules, can we require that they use the certificate method?
  5. What is the recommended method for allowing entities to receive another entity's root public digital certificate?
  6. For the purposes of the re-transmission, what is the definition of a duplicate transaction?
  7. What happens if a provider's system continues to send duplicate transactions within 15 minutes?
  8. Is there a retention time period required for how long the source needs to maintain this transaction tracking information?
  9. Where can I get more information about exchanging data in HTTP/S?
  10. Can my vendor offer HTTP/S on my behalf?
  11. What is the payload identifier (ID)?
  12. Is the payload ID outside the X12 interchange?
  13. Is the payload ID generated and sent by the submitter?
  14. Does the responder need to return the payload ID on the X12 transaction response?
  15. Is the payload ID unique for each transaction sent by the Submitter?
  16. What should be expected from trading partners regarding the payload IDs, and how it should be used?
  17. Can a clearinghouse or vendor act on behalf of a health plan for the CAQH CORE Connectivity Rules?
  18. For real time transactions, our system does not automatically resend failed responses; however, the client can go in and send the same request manually. Do we have to prevent the client from resubmitting the same request (even manually) for 90 seconds aft
  19. Is there a more precise definition as to where user ID, password, date/time and payload ID should appear in the data stream? The document references “HTTP Message Body” and “HTTP Message Header Tags.”
  20. If I make changes to the WSDL to implement my client or server, can I still get CORE-certified?
  21. How did CAQH CORE decide that HTTP/S is secure and reliable enough to protect the delivery of healthcare information over the Internet?
  22. Can payers support other versions of HTTPS as well as v1.1?
  23. Is there a required format for the authorization, date/time, and payload ID to be sent in the HTTP message?
  24. Will all CAQH CORE-authorized testing vendors use the same certification test scripts and the same detailed connectivity method to test CAQH CORE Connectivity Rules?
  25. How should we respond to the transaction if the date/time and/or payload ID are not present?
  26. I am a Healthcare Provider. Do I need to support a Client or Server roles or both for exchanging the HIPAA-mandated transactions?
  27. I am a Health Plan. Do I need to support as a Client or as a Server or both for exchanging the HIPAA-mandated transactions?
  28. I am a Clearinghouse. Do I need to support a Client or Server or both for exchanging the HIPAA-mandated transactions?
  29. What are my SenderID and ReceiverID values? Where can I obtain them?
  30. Who issues the client certificates for the X.509 client certificate-based authentication?
  31. Are there any guidelines/restrictions on the use of specific certificate authorities?
  32. I have a suggestion to update field X or to add field Y to the envelopes defined in CAQH CORE Connectivity Rules. What is the process for doing this?
  33. The Entity-Specific Connectivity Guide states that details of the message format and supported transactions, such as returning a list of files to be picked up for batch transactions, can be specified in a Connectivity Companion Guide. Does this mean t
  34. Do the CAQH CORE Connectivity Rules require the use of the MAC address?
  35. What is the specific method for an entity to conform to the CAQH CORE Connectivity Rule audit log requirements?
  36. Will CAQH CORE help negotiate implementation differences between trading partners?
  37. Does “client” refer to a workstation or human user, i.e., can a client be an internal workstation or a web browser requesting a webpage from an Internet web server?
How does an entity determine which version of CAQH CORE Connectivity to use when implementing a set of CAQH CORE Operating Rules?

Submitted by msingh@caqh.org on Wed, 04/20/2022 - 15:05
How does an entity determine which version of CAQH CORE Connectivity to use when implementing a set of CAQH CORE Operating Rules?

All CAQH CORE Infrastructure Operating Rules require use of “most recent published and CAQH CORE adopted version of the CAQH CORE Connectivity Rule” (please see the CAQH CORE Connectivity webpage for more information).  

Per CORE Certification Policy, entities seeking CORE Certification are required at a minimum to implement the version of CORE Connectivity published two years prior from when pursuing certification testing. Optionally, entities can choose to implement any newer versions of CORE Connectivity published within the past two years and attain certification depending on testing availability.

Additionally, all HIPAA covered entities are required to support prior mandated versions of CAQH CORE Connectivity as specified in Table 1 (please see Mandated Operating Rules webpage for full list of federally mandated operating rules with original naming conventions).  

NOTE: HHS will determine if updates to CAQH CORE Connectivity Rule requirements will be included in any regulatory mandates.

Table 1

Connectivity FAQ Image

 

Back to Top
What is the CAQH CORE Connectivity Safe Harbor?

Submitted by eteneyck@caqh.org on Fri, 02/18/2022 - 10:12
What is the CAQH CORE Connectivity Safe Harbor?

The CAQH CORE Connectivity Safe Harbor requires a health plan to support the requirements in CAQH CORE Connectivity Rule if requested by a provider. The CAQH CORE Connectivity Safe Harbor is the connectivity method that application vendors, providers, healthcare clearinghouses, and health plans (or other information sources) can be assured is supported by any HIPAA covered entity for the mandated operating rules and/or a CORE-certified entity. Supporting the CAQH CORE Connectivity Safe Harbor means the entity is capable and ready at the time of the request from a trading partner to exchange the transaction using the CAQH CORE Connectivity Rules.

Please Note: The CAQH CORE Connectivity Rules do not require entities to remove existing connections that do not match the rule requirements, nor do they require HIPAA covered entities to use only the CAQH CORE Connectivity Safe Harbor for all new connections. In some circumstances, trading partners may decide to continue to use an existing, non-CAQH CORE connection; however, entities must implement the capability to use the CAQH CORE Connectivity Safe Harbor and be capable and ready to use it when requested.

The CAQH CORE Operating Rules Sets include three operating rules that specify the CAQH CORE Connectivity Safe Harbor requirements:

  • The Connectivity Rule vC1.1.0 and CAQH CORE Connectivity vC2.2.0 together specify business rules and technical specifications for the CAQH CORE Connectivity Safe Harbor for conduct of the following transactions:
    • ASC X12N v5010 270/271 Eligibility and Benefits Inquiry and Response
    • ASC X12N v5010 276/277 Claim Status Inquiry and Response
    • ASC X12N v5010 835 Claim Payment/Remittance Advice
  • The Connectivity Rule v3.1.0 specifies business rules and technical specifications for the CAQH CORE Connectivity Safe Harbor for the conduct of the following transactions:
    • ASC X12N v5010 278 Health Care Services Review - Request for Review and Response
    • ASC X12N v5010 820 Payroll Deducted and Other Group Premium Payment for Insurance Products
    • ASC X12N v5010 834 Benefit Enrollment and Maintenance
    • ASC X12N v5010 837 Health Care Claim

The Connectivity Rule v4.0.0 specifies business rules and technical specifications for the CAQH CORE Connectivity Safe Harbor for the conduct of all ASC X12 transactions addressed by CAQH CORE Operating Rules and can optionally be applied to additional payload types (e.g., C-CDA, .pdf, .doc, etc.) as the connectivity specifications are payload agnostic.

Back to Top
How should entities track X12 transactions when using another connectivity method, as permitted by the CAQH CORE Connectivity Safe Harbor?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 10:15
How should entities track X12 transactions when using another connectivity method, as permitted by the CAQH CORE Connectivity Safe Harbor?

When a health plan uses another connectivity method, as permitted by CAQH CORE Connectivity Safe Harbor, CAQH CORE recommends that the health plan still implement the audit log requirements. This log can be used to resolve any issues or concerns regarding compliance and to identify where a bottleneck may occur in meeting the 20-second maximum real time and batch response time requirements.

Back to Top
My organization’s security procedures require that clients use a digital certificate to identify themselves. Under the CAQH CORE Operating Rules, can we require that they use the certificate method?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:23
My organization’s security procedures require that clients use a digital certificate to identify themselves. Under the CAQH CORE Operating Rules, can we require that they use the certificate method?

Yes. CAQH CORE Connectivity requires that entities use X.509 Certificates over SSL as the submitter authentication standards, with conformance requirements for the client (e.g., submitters/providers) and the server (health plans). If your organization’s policies require a higher level of security, CORE Connectivity implementation allows you to implement additional security mechanisms.

NOTE: These additional mechanisms, like any other additional requirements beyond the CAQH CORE Operating Rules, will not be tested by the CAQH CORE-authorized testing vendors as part of CORE Certification testing.

Back to Top
What is the recommended method for allowing entities to receive another entity's root public digital certificate?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:23
What is the recommended method for allowing entities to receive another entity's root public digital certificate?

CAQH CORE does not make recommendations for this process. Please discuss this with your individual trading partners.

Back to Top
For the purposes of the re-transmission, what is the definition of a duplicate transaction?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:24
For the purposes of the re-transmission, what is the definition of a duplicate transaction?

CAQH CORE does not define a duplicate transmission. Please refer to your own internal policies.

Back to Top
What happens if a provider's system continues to send duplicate transactions within 15 minutes?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:25
What happens if a provider's system continues to send duplicate transactions within 15 minutes?

CAQH CORE does not define the recourse for information sources in this case

Back to Top
Is there a retention time period required for how long the source needs to maintain this transaction tracking information?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:26
Is there a retention time period required for how long the source needs to maintain this transaction tracking information?

CAQH CORE recognizes that every organization has its own record-retention policies and does not mandate a strict requirement for retention of tracking information. To support ongoing tracking of response times and performance measurement, CAQH CORE recommends that entities keep this information for at least 18 months if that is in accord with the organization’s existing policies.

Back to Top
Where can I get more information about exchanging data in HTTP/S?
Back to Top
Can my vendor offer HTTP/S on my behalf?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:27
Can my vendor offer HTTP/S on my behalf?

CAQH CORE Operating Rules do not require an entity (provider or health plan) to implement the technology directly into their own data center. CAQH CORE Rules implicitly acknowledge that both providers and health plans use technology solutions provided by vendors to accomplish all that must be done. Neither do CAQH CORE Operating Rules require a "direct" connect – meaning that providers connect directly to the health plan's data center and do not connect to an intermediary, such as a clearinghouse. Thus, CAQH CORE Rules do not require any specific architecture. Rather, CAQH CORE Operating Rules specify the capabilities that need to be enabled by any CORE-certified entity.

  1. An entity seeking CORE Certification, working with or without their vendor providing the HTTP/S connectivity capability, must demonstrate conformance with CAQH CORE Connectivity Rule through the CORE Certification testing.
  2. CAQH CORE encourages payers who are using vendors to review their compliance to make sure that they are fully in compliance with both CAQH CORE and HIPAA, particularly the clause in HIPAA that says payers cannot charge more than the cost of telecommunications for handling the connectivity.
Back to Top
What is the payload identifier (ID)?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:29
What is the payload identifier (ID)?

Within the context of the CAQH CORE Connectivity Rules, the payload ID is an identifier that uniquely identifies the X12 interchange(s) transported by the HTTP message and is used to allow submitters and information receivers to easily reconcile their records of submissions and responses. CAQH CORE elected to use an ID outside of the X12 message for this purpose because many information receivers' systems separate the HTTP communication processing from the X12 message processing. The payload ID is generated and sent by the entity that initiates the HTTP communication session.

Usually this is the provider or clearinghouse that is sending the request to the health plan or other information source. It is one of the CAQH CORE-required HTTP message parameters (along with authorization information and date and time stamps) and it must be unique to each HTTP message and the X12 interchange(s) being transported by the HTTP message instance. All CORE-certified entities are required to capture, log, and be able to report on each HTTP message transporting an X12 interchange and to be able to link the X12 interchange to a specific HTTP message instance. The payload ID (Message Body identifier) is the mechanism used to associate a given instance of an X12 interchange to the HTTP message instance.

Back to Top
Is the payload ID outside the X12 interchange?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:29
Is the payload ID outside the X12 interchange?

Yes.

Back to Top
Is the payload ID generated and sent by the submitter?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:30
Is the payload ID generated and sent by the submitter?

Yes, it is generated by the system that creates the HTTP request message. Typically, this is the provider’s system or the clearinghouse’s system that is working on the provider's behalf.

Back to Top
Does the responder need to return the payload ID on the X12 transaction response?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:31
Does the responder need to return the payload ID on the X12 transaction response?

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

Back to Top
Is the payload ID unique for each transaction sent by the Submitter?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:31
Is the payload ID unique for each transaction sent by the Submitter?

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

Back to Top
What should be expected from trading partners regarding the payload IDs, and how it should be used?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:32
What should be expected from trading partners regarding the payload IDs, and how it should be used?

An entity should expect to receive a long, possibly alphanumeric, payload ID from its trading partners and should be able to store that payload 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 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. CAQH CORE Operating Rules do not specify detailed requirements for the payload ID specifications.

Back to Top
Can a clearinghouse or vendor act on behalf of a health plan for the CAQH CORE Connectivity Rules?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:33
Can a clearinghouse or vendor act on behalf of a health plan for the CAQH CORE Connectivity Rules?

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

Back to Top
For real time transactions, our system does not automatically resend failed responses; however, the client can go in and send the same request manually. Do we have to prevent the client from resubmitting the same request (even manually) for 90 seconds aft

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:33
For real time transactions, our system does not automatically resend failed responses; however, the client can go in and send the same request manually. Do we have to prevent the client from resubmitting the same request (even manually) for 90 seconds after the original request was sent?

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 Connectivity Rule.

Back to Top
Is there a more precise definition as to where user ID, password, date/time and payload ID should appear in the data stream? The document references “HTTP Message Body” and “HTTP Message Header Tags.”

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:34
Is there a more precise definition as to where user ID, password, date/time, and payload ID should appear in the data stream? The document references “HTTP Message Body” and “HTTP Message Header Tags.”

There are no more precise specifications in CAQH CORE Connectivity Rules. This decision is left to the message originator.

Back to Top
If I make changes to the WSDL to implement my client or server, can I still get CORE-certified?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:35
If I make changes to the WSDL to implement my client or server, can I still get CORE-certified?

Only those changes to the WSDL that preserve the structure and syntax of the message envelope are allowed. All field names, data types and syntax of existing fields must stay the same.

Back to Top
How did CAQH CORE decide that HTTP/S is secure and reliable enough to protect the delivery of healthcare information over the Internet?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:35
How did CAQH CORE decide that HTTP/S is secure and reliable enough to protect the delivery of healthcare information over the Internet?

CAQH CORE solicited input on this topic during the rules-development process from the CORE Technical Work Group members and experts within healthcare and other industries, such as financial services. Based on this input, including the information that other healthcare industry projects, such as the Markle Foundation’s Connecting for Health project and the CMS Nationwide Health Information Network architecture prototypes, are using HTTP/S over the Internet, CAQH CORE determined that HTTP/S is an appropriate choice as the baseline standard for delivery of healthcare information. Email CAQH CORE at CORE@caqh.org for more background information.

Back to Top
Can payers support other versions of HTTPS as well as v1.1?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:36
Can payers support other versions of HTTPS as well as v1.1?

Yes. Payers may support other versions, but they must support HTTPS 1.1 to achieve CORE Certification. The intent of CAQH CORE Connectivity is to provide a safe harbor that application vendors can develop towards without needing to get detailed information from every potential payer with whom they would like to connect.

Back to Top
Is there a required format for the authorization, date/time, and payload ID to be sent in the HTTP message?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:36
Is there a required format for the authorization, date/time, and payload ID to be sent in the HTTP message?

No. CAQH CORE does not require a specific format for sending these data elements. Please speak with your CAQH CORE-authorized certification testing vendor on how they work with entities on CORE Certification testing given any current HTTP format requirements and those used by the certification testing vendor. 

Back to Top
Will all CAQH CORE-authorized testing vendors use the same certification test scripts and the same detailed connectivity method to test CAQH CORE Connectivity Rules?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:37
Will all CAQH CORE-authorized testing vendors use the same certification test scripts and the same detailed connectivity method to test CAQH CORE Connectivity Rules?

For every rule, each CAQH CORE-authorized testing vendor uses the same test scripts by stakeholder. Additionally, each CORE-certified entity is responsible for complying with the rules, understanding that not all aspects of rules compliance are tested during CORE Certification testing, e.g., maintaining system availability.

Because the CAQH CORE-authorized testing vendors each operate a little differently with regard to how they connect to their clients, they may use different approaches to test for the detailed CORE Connectivity Test Scripts. The CAQH CORE-authorized testing vendor selected to work with to conduct your CORE Certification testing provides organization with the details necessary to complete the CAQH CORE Connectivity Rule certification tests.

Back to Top
How should we respond to the transaction if the date/time and/or payload ID are not present?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:38
How should we respond to the transaction if the date/time and/or payload ID are not present?

Such a message would represent a CAQH CORE non-conformant message. CAQH CORE Connectivity 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-conformant message.

Back to Top
I am a Healthcare Provider. Do I need to support a Client or Server roles or both for exchanging the HIPAA-mandated transactions?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:38
I am a Healthcare Provider. Do I need to support a Client or Server roles or both for exchanging the HIPAA-mandated transactions?

The CAQH CORE Operating Rules define minimum technical roles for a HIPAA-covered health plan or its agent. The CAQH CORE Connectivity vC3.1.0 defines message interactions between providers and health plans which require that at a minimum a provider support a Client role as described in the CAQH CORE Connectivity vC3.1.0 for exchanging the HIPAA-mandated transactions addressed in the CAQH CORE Operating Rules. 

Back to Top
I am a Health Plan. Do I need to support as a Client or as a Server or both for exchanging the HIPAA-mandated transactions?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:39
I am a Health Plan. Do I need to support as a Client or as a Server or both for exchanging the HIPAA-mandated transactions?

The CAQH CORE Operating Rules require a HIPAA-covered health plan to support the Server requirements at a minimum. A HIPAA-covered health plan may optionally support a Client role.

Back to Top
I am a Clearinghouse. Do I need to support a Client or Server or both for exchanging the HIPAA-mandated transactions?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:40
I am a Clearinghouse. Do I need to support a Client or Server or both for exchanging the HIPAA-mandated transactions?

Given that a Clearinghouse may be acting as an agent (e.g., Business Associate) of either a HIPAA-covered health plan or a HIPAA-covered provider, it must support either a Client or a Server or both roles in the CAQH CORE Operating Rules based on which HIPAA-covered entity on whose behalf it is acting.

Back to Top
What are my SenderID and ReceiverID values? Where can I obtain them?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:40
What are my SenderID and ReceiverID values? Where can I obtain them?

SenderID and ReceiverID Values are unique identifiers associated with your organization. They are intended for message routing and processing, transaction auditing and as a reference to a business agreement by a message receiver. CAQH CORE recommends using OIDs from organizations like HL7 or IANA, but you may use other forms of organizational identifiers. Section 6.2 of CAQH CORE Connectivity RulevC2.2.0 has the URLs of HL7 OID Registry and the IANA OID registration page where organizations can obtain the OIDs.

Back to Top
Who issues the client certificates for the X.509 client certificate-based authentication?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:41
Who issues the client certificates for the X.509 client certificate-based authentication?

Client Certificates may be issued by a trusted third party called a Certificate Authority (CA) such as VeriSign or Entrust, or by the entity that is receiving connections.

Back to Top
Are there any guidelines/restrictions on the use of specific certificate authorities?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:42
Are there any guidelines/restrictions on the use of specific certificate authorities?

CAQH CORE has not specified guidelines/restrictions on the use of certificate authorities at this time. Client certificates used for node authentication over SSL can be issued by the organization that is receiving connections, or by a third-party certificate authority that is trusted by the organization to issue these certificates on its behalf.

Back to Top
I have a suggestion to update field X or to add field Y to the envelopes defined in CAQH CORE Connectivity Rules. What is the process for doing this?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:43
I have a suggestion to update field X or to add field Y to the envelopes defined in CAQH CORE Connectivity Rules. What is the process for doing this?

Please submit your request to CAQH CORE. Your request will be considered by the CORE membership for inclusion in a future version of CAQH CORE operating rules

Back to Top
The Entity-Specific Connectivity Guide states that details of the message format and supported transactions, such as returning a list of files to be picked up for batch transactions, can be specified in a Connectivity Companion Guide. Does this mean t

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:43
The Entity-Specific Connectivity Guide states that details of the message format and supported transactions, such as returning a list of files to be picked up for batch transactions, can be specified in a Connectivity Companion Guide. Does this mean that we can make any custom extensions to the envelope metadata and message exchanges, and if such extensions are specified in a Companion Guide, can we get certified for CAQH CORE Connectivity?

No. By design, the CAQH CORE Connectivity Rules are highly prescriptive in the envelope metadata and message interactions because the CORE Participants need a Connectivity Rule that provides a high degree of interoperability. Entities may implement custom extensions which must be described in a Companion Guide, but such extensions are not compliant with the CAQH CORE Connectivity Rules’ normative specifications (i.e., XSD, WSDL) and are therefore considered as non-CAQH CORE connectivity interfaces. Consistent with the Safe Harbor principle (defined extensively in CAQH CORE Connectivity Rules), a CORE-certified entity can implement custom extensions and/or support additional connectivity methods if it has implemented one connectivity interface that is fully and exactly as specified in the CAQH CORE Connectivity Rule. This gives CORE-certified partners the assurance they can use their CAQH CORE Connectivity interfaces to connect.

Back to Top
Do the CAQH CORE Connectivity Rules require the use of the MAC address?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:44
Do the CAQH CORE Connectivity Rules require the use of the MAC address?

Yes. The field constraints or value-sets for PayloadID are specified in Section 4.4.2, Table of CORE Envelope Metadata of each CORE Connectivity Rule. Specifically, the requirement specifies “PayloadID will conform to ISO UUID standards (described at ftp://ftp.rfc-editor.org/in-notes/rfc4122.txt), with hexadecimal notation, generated using a combination of local timestamp (in milliseconds) and the hardware (MAC) address, to ensure uniqueness.”

Back to Top
What is the specific method for an entity to conform to the CAQH CORE Connectivity Rule audit log requirements?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:45
What is the specific method for an entity to conform to the CAQH CORE Connectivity Rule audit log requirements?

The CAQH CORE Connectivity Rule does not specify a method for capturing and logging data. The rule only specifies what data must be captured and logged. The method for how to capture and log is determined by the implementer. CAQH CORE Connectivity RulevC2.2.0 Section 4.3.4 requires that, to comply with the associated CAQH CORE Operating Rules’ message response requirements, receivers must track the date, time, and payload ID of any received inbound messages and respond with the outbound message for that Payload ID. Additionally, message senders must include the CAQH CORE Envelope Metadata element Time Stamp (as specified in the CAQH CORE Connectivity vC2.2.0, Section 4.1.2). Other data may be required for auditing purposes; however, this data can be determined by each entity. CAQH CORE Rule recommends that to uniquely identify an X12 payload, entities store the ISA06, ISA08, ISA13, GS02, GS03, GS06, ST02, TRN02, and if sent in the transaction, the BHT03.

While the CAQH CORE Connectivity Rules do not require entities to deliver this information to any other entity, the data required to be logged would be used to resolve any issues or concerns regarding the overall response time. The CAQH CORE Rules do not specify how long an entity is to retain the data for auditing purposes.

Back to Top
Will CAQH CORE help negotiate implementation differences between trading partners?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:45
Will CAQH CORE help negotiate implementation differences between trading partners?

No. CAQH CORE does not provide negotiation assistance between trading partners. CAQH CORE does provide implementation resources and education events and will clarify the rules if there are questions. 

Back to Top
Does “client” refer to a workstation or human user, i.e., can a client be an internal workstation or a web browser requesting a webpage from an Internet web server?

Submitted by kcooper@caqh.org on Fri, 02/18/2022 - 12:46
Does “client” refer to a workstation or human user, i.e., can a client be an internal workstation or a web browser requesting a webpage from an Internet web server?

The CAQH CORE Connectivity Rules apply to Business to Business (B2B) transactions. The term “Client” refers to software that is initiating, submitting/sending a request to a receiving “Server." 

Back to Top