Case Studies

The case study demonstrates how we implemented an enterprise solution for one of our health care clients.

 

Project Background

Hospitals make claims to insurance companies and in return they receive checks and Explanation of Benefits (EOB) for each claim. The claim can contain multiple patient cases. The insurance company must provide EOB for each patient claim. It explains about the treatment and services for which it is paid and the reason for the unpaid amount.

HIPAA, the Health Insurance Portability And Accountability Act of 1996, was created to protect a person’s health information. ANSI 835 is the American National Standards Institutes Health Care Claims Payment and Remittances Advice Format, which is recommended by HIPAA for electronic exchange of EOBs.

Our client needs software which can ingest thousands of Lockbox files on a daily basis and generate 835 files out of it. A Lockbox file contains check(s) and its corresponding EOB images.

Challenging Non Functional Requirements (NFR)

In addition to business requirements, there was a series of non-functional requirements which are vital for the very existence of the business. Some of the major NFR are the following

  • The data of one hospital should not mix up with the data of another hospital
  • Must be able to handle large volumes of Lockbox files.
  • Must handle 200-300 concurrent users
  • Must be able to process and generate 835 for all the lockbox files within 24 hours
  • Must be able to generate custom 835 based on complex client rules
  • Must be able to rearrange images based on EOBs to be returned back to the client.
  • The software must be up and running 24×7, 6 days a week.
  • The performance must not degrade based on data volume.
  • At any point of time, production system must maintain six months of data which can run into hundreds of gigabytes and millions of records in each table
  • Software must be configurable for each client and must be flexible to add new clients without impacting existing production work.
  • There must be a monthly revision of the software based on the change request either due to new clients or changes in existing client rules

 

Software Process

Framework: Ruby on Rails (RoR)

We used RoR for software development due to following reasons

  1. Popular MVC framework
  2. Fast development
  3. Easiness to make changes
  4. Availability of ready-made solutions as Gems
  5. Developers can focus more on business logic as framework cares about the middleware implementation using feature like Active Records.

Software Engineering Process: Agile Scrum

Agile Scrum was chosen as the Software Engineering process and its major advantages are

  1. Focused on developing modules based on customer priority
  2. Release software as multiple iterations
  3. Scrum brings team work and thereby improves productivity
  4. Immediate feedback and taking corrective measures.
  5. Adjusting the product roadmap based on business changes.

 

Open Source Software

We believe in open source as there is an large enthusiastic community maintaining it and it is also cost effective to the customer.

In addition to RoR, we also used other open source software

  1. MySql for relational database
  2. Sphinx for indexing and searching
  3. Memcache for caching
  4. JQuery for scripting
  5. Linux and Apache for deployment

 

Deployment Architecture

Deployment architecture is designed to scale horizontally with respect to the business growth.

  1. Users connect to Application over internet using a Web Browser. It is a secured connection over https
  2. The incoming request is routed to a Rails Application server with the help of a Load Balancer. We can add “N” number of applications to the load balancer based on the business growth.
  3. All application servers will communicate with a single database server which consists of different schema for each client. This is to segregate client data and also improves performance.
  4. High volume data which needs to be searched as indexed and maintained in Sphinx for easy retrieval.
  5. The commonly used data set and pages are cached in Memcache.

 

Product Progression

  • Deployed to production in Sept., 2008
    • Ruby 1.x Rails 1.x
    • One client
    • 10,000 EOBs per/month
  • As of Sept. 2014
    • Rails 2.x, Rails 4.x
    • 12 clients
    • 2.3 million EOBs per/month
    • Sphinx search for fast retrieval of data.