Introduction > Real-Time and Batch

CORE regulations cover two process modes: Real-time and Batch.

Real-time transactions in EDI usually start with the number 2. For example 270/271 for eligibility, 276/277 for claim status and 278 for Authorizations in the health care industry. The prevalent transport mechanism in healthcare EDI is at this time the File Transfer Protocol (FTP). This specific internet protocol is not suitable for real-time transactions since it does not provide for a response. CORE defines real-time as less than 20 seconds and this is not achievable with FTP and the reason why the committee chose MIME and SOAP as transport protocols. Both of those protocols do exactly the same thing and do not influence the information flow.

There are two basic modes of transport defined in the CORE standard, true real-time transactions and batch transactions. We will explain the difference below.

The following graphic shows the data flow in a typical real-time transaction

Real-Time Flow

Data flow in a real-time transaction

This transaction is really simple, a request is sent out and a response is received back. No extra bit of information exchange is required.

Compare this to the composition of a batch transaction in CORE. Here we distinguish between four distinct information exchanges

Batch Flow

Data Flow in a batch transaction

•	First is the batch submission. Here the payload consisting of multiple requests is transmitted and a confirmation receipt is sent back.

•	Second, we have the retrieval of the functional acknowledgment, the 999 transaction which in more detail reports if all individual transaction sets have been accepted and/or how many have been rejected.

•	Third, we the response retrieval. A request for the response file is sent and the payer sends the response transaction(s) back to the provider.

•	Fourth, the provider acknowledges the receipt of the Batch Response with a 999 file that the payer receives and acknowledges.

We can see that the batch process is a lot more complex than the real-time process which is really compressed for the most efficient exchange of information. Also the time frame for the 4 part transactions is spread out. It is usually defined in the trading partner agreement how much time has to pass before the request for the acknowledgment and lastly the request for response retrieval can be sent. Usually an over-night period is required.

The HIPAAsuite RealTime Server supports both transmission modes. It reads and understands the envelope of the transaction and chooses the correct mode.