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 ). 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.
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).
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.