Electronic Claims Processing Software Development

Medical providers must file electronic claims conforming to The Health Insurance Portability and Accountability Act (HIPAA) enacted by the U.S. Congress in 1996. The Centers for Medicare and Medicaid Services (CMS) has mandated the Electronic Data Interchange (EDI) 837 Standard for processing health care claims with data such as billing, demographic, and diagnosis information. Each state implements its own version of the EDI 837 format. All medical providers must adhere to the standards of their respective states for filing claim information.

The Electronic Claims Submission Process

Each electronic claim file is subjected to various edits to before being submitted. These edits validate that the file conforms to the EDI 837 file format and that the file would not be rejected by the state. After each EDI submission, an acknowledgment receipt is sent to the submitter confirming a successful submission or a list of failed submissions.

Electronic claims processing software used in preparing the claim information should include fairly complex business rules, and must reflect a good understanding of the most recent HIPAA rules. In addition to conforming to HIPAA rules, the electronic claims processing software must also adhere to several privacy and security rules. Moreover, since HIPAA rules may change, the software should have the ability to easily update itself.

Software Implementation Technologies

An electronic claims processing software application may be implemented using Client-Server architecture so that multiple facilities can process their electronic claims concurrently. Since most of these clients are Windows-based machines, Microsoft .NET is often the preferred choice for developing a software solution for such an architecture. Most likely, these clients are smart clients (thick clients) that have the ability to function both in an online and offline mode.

Advantages of developing a smart client solution for EDI processing:

  • Utilization of local resources enables client to process the file locally before submitting to the central server, thereby putting less load on the server.
  • Intelligent update means that clients can be updated directly from the server.
  • Offline capability of the smart client makes it possible to work even when the client is not connected to a network. This is beneficial especially when the network connection is unreliable.

emr-edi837-architecture

An Architectural Overview of the Smart Client

Composite application block (CAB) is a good choice for implementing the smart client electronic claim processing software as it offers multiple advantages for developing the smart client solution. CAB is a framework that:

  • Is highly customizable for developing smart clients.
  • Is “pluggable” in that it enables the development of a variety of independent but cooperating modules such as authentication, exception handling, web-service handlers, etc.
  • Easily allows for the addition of new modules to the existing solution, making upgrades easier to implement.

The web service can be implemented using Windows Communication Foundation (WCF). The advantages of using WCF for developing services is:

  • Easy to achieve interoperability
  • Supports a large number of bindings (such as https, TCP/IP)
  • Provides good security and reliability

Developing an electronic claims processing software application to process the EDI 837 format is not an easy task and is better managed if specifications are well understood, the right technology is selected, and a good amount of time is put into planning the HIPAA compliant solution. In addition, electronic claims processing software requires constant updating as the format and rules for validating the format may frequently change. Therefore, it is of the utmost importance that the solution developed is extensible and is flexible toward future changes in HIPAA.