SERVICES >HIPAA Compliant Application Software

HIPAA (Health Insurance Portability & Accountability Act) established in 1996 in the US as an amendment to Internal Revenue Service Code of 1986 was primarily promulgated to promote efficiency in health care data exchange as well as for ensuring protection of sensitive data by enforcing standards. HIPAA affects the HealthCare industry and most of its constituents like Providers, Hospitals, Billing agencies and Pharmacies etc.

By definition the Act can be broken down into 2 parts

Accountability >>> Administrative Simplification

Portability >>>Insurance Reforms

Accountability would involve :

Transaction Sets
National Identifiers
Security
Privacy

The term “Electronic Health Transaction” includes a wide variety of document types like Health Claims, Enrollment and Disenrollment, co-ordination of benefits etc. In the past, organizations had used many electronic formats and a standard was required to make the system simple and efficient. Post HIPAA, all health care organizations are supposed to exchange data using these electronic standards.

Some of the standard transactions used by providers are :

Claims or Encounters -- X12 837 Professional , Institutional and Dental
Remittance Advice -- X12 835
Eligibility Inquiry and Response -- X12 270/271
Prior Authorization and Referral -- X12 278
Claims Status Inquiry And Response: -- X12 276/277

Each transaction type has a detailed Implementation Guide published by the Washington Publishing Company which can be used by Organizations to produce HIPAA compliant EDI documents.

If health care organizations are incapable of establishing a system of their own they are required to contact a third party vendor to provide translation services.

We at Essel have helped many vendors to make their electronic transactions HIPAA compliant. The Product suite can be broadly divided into 2 categories

EDI Generation Services – these services help an organisation to generate HIPAA compliant EDI documents out of paper or electronic claims.

EDI Import Services - are applied if an organization receives inbound EDI documents. Clients use our EDI Import services to import the EDI documents into their existing claims processing workflow and even convert them into other formats – that may be as defined by their managements for internal decision processes or may even be other formats that are required statutorily.

Products

X12Export & X12Mapping

This represents a set of modules used to generate various electronic transactions like the X12 837 , X12 835 etc. The input to these modules could be any electronic document or even scanned images.

If they are scanned images, they are batch loaded into our claims processing workflow and after data capture operations and quality assurance validations, the validated data is converted into X12 documents for each source image.

If they are electronic documents in any custom format our EDI File import program would be used to be convert this data it into a batch document and processed.

The mapping application represents a powerful tool to map X12 Schema with that of Batch data. You can configure various aspects like specifying output formats copying data from other segments etc using the mapping tool.

EDI File Import

This is a powerful tool used to convert the inbound EDI transaction file into a Batch Document format for the Batch processing workflow suite. Currently it supports formats like :

X12 837/835
RIMS
CSV

Once the inbound EDI document is converted into the Batch workflow it can be converted into any outbound format by Export programs.
Also if you have custom Electronic documents which need to be converted to HIPAA compliant formats, it can be achieved using the extensibility feature of EDI file import Parser components.

DocuViewer

This is a EDI transaction file viewer which can be used to view the cryptic electronic file in a user friendly way. For e.g. if you want to view a X12 837 document, DocuViewer will overlay the claim information from the electronic file onto a HCFA image and populate such fields as Patient Name etc .

Resources

HIPAA Primer (http://www.hipaadvisory.com/regs/HIPAAprimer.htm)
Main CMS Site for HIPAA resources (http://www.cms.hhs.gov/HIPAAGenInfo)
Helpful hints is a site which offers some mapping guidelines for X12 837 EDI files
http://www.hipaa.org/hints/
HIPAA org site which has several links to useful HIPAA sites.
http://www.hipaa.org
If you want a copy of the Implementation Guides (IG), then you must buy it from.
Prior to 2006 it used to be free. But the IGs now cost you a few dollars.
http://www.wpc-edi.com/hipaa

Case Study

Case 1: Inbound EDI Processing

Case Summary

As HIPAA act is being enforced across Health care organizations, all transactions are becoming HIPAA compliant EDI documents. Legacy systems used for adjudication mechanisms cannot cope with the intrinsic complexities of EDI documents compliant with the transaction set standard corresponding to the scenario. For e.g. Insurance company might have a system which dealt with a custom fixed length file of claim data. With the advent of HIPAA, they will now receive X12 837 documents.

Developing a system to parse this file would require development effort and time.
Health care organizations required a mechanism by which they could parse and obtain relevant data and process it. They would also require a mechanism by which they could produce out bound EDI documents corresponding to the scenario.

Technical solution design

The technical solution would be to have an extensible system so that any type of EDI Documents could be processed by the system. The system would produce a Document compliant with the claims processing workflow after translating the inbound EDI document. For such translation services a Parser component would be used. Each EDI document processing would be performed by a dedicated parser registered with the system. As the system obtained data in a neutral format from the parser, it converted it into the Batch documents required by the Claims processing workflow. Since we can generate any type of EDI format by writing a Export program, the system had the extensibility to process and produce any type of EDI Document.






Implementation approach

Once again, active involvement with the client was considered to be a crucial aspect of the project. We started with developing support for processing X12 837 documents first. Since the system was highly modular it was possible to support only a particular format first and then go on to add support for other document types. Later on other document types like RIMS, CSV etc were developed. The iterative model helped the client to perceive how the system would be and at the same time obtain tangible results

Business results
By adopting the EDI File Import program vendors achieved significant Business results. The most important are :


Shortened time to market time scale
Obtained HIPAA compliant processing pipe line with the least effort.
Obtained a system which was extensible and could cater for any EDI scenario

Technologies covered

C++/ ATL/ COM, ADO, XML DOM.