<< Click to Display Table of Contents >> Navigation:  Introduction > The HIPAAsuite RealTime Server

What is the HIPAAsuite RealTime Server

Since the introduction of EDI (Electronic Data Interchange)transactions into healthcare with the ratification of the HIPAA (Health Insurance Portability and Accountability Act) law in 2003, an ever increasing part of the healthcare transactions between providers and payers is done using EDI transactions. This technology proved itself to reduce the costs of health care. It costs today only a fraction to file an electronic claim versus printing a claim form to paper and sending it to a the payer by mail.

EDI categorizes transactions between business partners into so-called "transaction sets". All expected content of such a transaction is standardized and precisely defined. The purpose is the fast and efficient communication by different computer systems without the interaction of human beings. Therefore, such transactions have to be flawless and predictable in composition. The National Institute of Standards (NIS) developed the X12 standards and through the workgroup of EDI monitors their guidelines. EDI is found in all sectors of American business, be it banking, retail, cellular phone billing, and many others.

Twelve initial sets of transactions were written into the 1996 HIPAA law. It was understood that this group of transactions was not complete and meant to be amended and further developed. The HIPAA EDI messages are designed to group transaction types by their identifiers. Transactions that start with the number '2'. are considered Real-Time transactions and meant to be answered in a short amount of time. Under HIPAA these are the 270/271 Eligibility and the 276/277 claim status transactions as well as the 278 Authorization and Review Request transaction. Until now the implementation of these transactions in production environments have been very spotty. Providers' practice management software systems and insurance carriers' EDI capabilities were often not able to create those response transactions within the 20 seconds that the standard identifies as Real-Time.

The File Transfer Protocol (FTP) that makes the back bone of the today's existing HIPAA EDI infrastructure is innately not designed to operate in Real-Time mode. Clearly, a different transport mechanism had to be found and many providers and payers worked on different methods to make it happen. An industry group, the Council for Affordable Quality Healthcare (CAQH), developed a precise standard to implement a workable and universally shared technology under the acronym of "CORE" (Committee on Operating Rules for information Exchange). The most promising technologies that were tried and tested are:

Those two standards are implemented in the CORE Phase I and II protocols. These protocols have been adopted as part of the ACA, the Affordable Care Act, also known as Obama Care. Payers are now obligated to provide Real-Time interfaces for claim status, eligibility and payment advice.

HIPAAsuite decided that this complex technological challenge needed a simple and cost-effective solution. In 2013 we started with the layout and process analysis and in 2014 did we decide to earnestly invest time and resources to develop the HIPAAsuite RealTime Server.

HIPAAsuite has applications that automatically create responses to 270 and 276 request files in batch mode, which means requests were delivered and a response was given in 24 hours, often less, to be picked up or transferred via FTP.

The HIPAA Claim Status Responder and the HIPAA Eligibility Responder can be used to automatically create the 271 or 277 response files in batch mode. And now, with the HIPAA RealTime Server, these applications together provide a CORE Phase I and II certified solution.

The HIPAAsuite RealTime Server implements both a MIME and a SOAP web server which interacts with these two applications to provide a valid response file using the appropriate protocol in less than 20 seconds.

MIME and SOAP are complex protocols. It took us many months to fully understand the logic and flow of data files. The following documentation is written with the intent to educate the reader on the back ground as much as possible to understand and appreciate the complexities involved.