Monthly Archives: July 2013

WHAT CAN YOU DO IN LESS THAN 20 SECONDS?

I have been part of many healthcare solutions where you need to process large amount EDI data (such as 837 and 835). In this context ‘process’ is a overloaded term. Lot of things happen (or has to happen). After working on so many projects we have seen how things are done, what needs to happen, how fast things needs to done in a fault tolerant way etc. We have distilled all this and created our EDI platform.

 

When you build a product or a platform, first and foremost thing is the ‘functional requirements’. This product/platform has to solve the business problem and provide a business value. In many cases, non-functional requirements (such speed,fault tolerance and accuracy) become so many important that, lack of these features will render your solution practically useless. For example, you process EDI documents in a fantastic way but takes forever, then you cannot provide the business intelligence in time for that to be useful. How do you achieve this?

In our platform we process most complex EDI specifications in a very short amount of time. I cannot go into all the details of what all we do during this process (that is our secret recipe Winking smile). In addition our solution can scale to process any amount of data very easily.

20 SECONDS IS LOT OF TIME!

It is good that we can do lot of useful processing in 20 seconds. But, with the volume of information we produce today, this timing is won’t cut it.

image

As I mentioned earlier, our platform does lot of things in parallel. For example, one instance of our ISHIN server can process 20 records in parallel (I am assuming a small server without any fancy configuration).

image

 

You must be wondering why I am writing a whole blog talking about a few seconds. There are so many examples where this becomes very important. For example, in healthcare, there are times when you have to process ALL your remittance files or claim files to make some changes effective.

EDI CLAIM STATUS REQUEST AND RESPONSE

EDI 276 is used to send request for claim status and response for this request will be sent to the providers using EDI 277.

This article illustrates the flow involved at both payer and provider side. When provider side gets a 277, they have to process it and understand the claim status to take an appropriate action. 277 is a reasonably complex EDI specification. Our platform is capable of processing 277 and enables you focus on your business process. If you are provider IT or billing company working on behalf of many providers or a technology company providing revenue cycle management solutions to providers/hospitals, this platform can help.

 

 

WHAT HAPPENS WHEN A PROVDER SENDS A CLAIM STATUS REQUEST (276)?

Payer side has to parse 276 X12 file and apply their business process to generate 277. The flows likes this.

image

 

WHAT HAPPENS ON THE OTHER (PROVIDER) SIDE WHEN 277 IS RECEIVED?

When the provider side (practice or an hospital) receives 277 response from a payer, it needs to be parsed and analyzed to understand what is happening with a given claim. Do not try to reinvent the parsing (I am understating the work involved by using the word ‘parsing’. Lot of stuff happens here) technology. Consider buying a well proven solution. Instead, focus on your business process which will target the bad claims and fixes them. This should be your sole focus.

 

image

Tagged

WRITING server platform SOFTWARE is an art

Writing server side platform software is an art. We have built a platform to process vast amount of EDI (We will expand it to do the same with HL7 and other clinical data soon). Our platform has embraced parallel processing very effectively. I just wanted to graphically illustrate how some things work in the back ground. You cannot touch and see these things. But they play an extremely important role in the overall solution.

 

Imagine that, lot of work is being dumped on you and you are supposed to finish all the work in a very short amount of work. How do you do this?

As we all know, just dropping lot of people to work on this won’t solve the problem. You have to carefully analyze the problem and required outcomes to come up with an optimal solution.

 

image

Tagged ,