Category Archives: EDI

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 ,

EDI: WHAT AFTER PARSING?

Our platform can process any EDI document. You do not have to worry about mapping or versions (4010 or 5010). We will enable your business process to consume this EDI in a very convenient way. The following picture shows some of the integration options.

When you are working with EDI documents, it will be nice, if I can just focus on my business process instead of worrying about EDI specifications, loops, segments etc. Let me take a concrete example in healthcare. You organization is getting thousands of claims (837) you want to make sure that they have valid provider details, diagnosis codes and so on. Our platform will enable you to accomplish this without ever worrying about mapping or having to know anything about loops/segments. We have built some sample rules (which reside in boxes named BPM/Custom rule engine in the following picture) which will test the validity of NPI, route the claims based on the claim amount and/or provider address. These are just samples, you can do whatever you want with the incoming records(in this case of 837, they are claims).

Also, for processing remittance advices, we have built some sample rules which will route the denied claims certain way, if the paid amount v/s charge amount falls below certain threshold, we route it differently.

ishin integration

Goal of our X12 platform is to enable your organization to focus on business process and never worry anything about processing EDI documents. This platform can process any EDI specification. If you’re an enterprise responsible for processing large volume of EDI documents, our platform can handle this very easily. It is a very fault tolerant enterprise grade EDI processing platform.

If you have any questions, contact me at shanthu@palisha.com

EDI PROCESSING: FAULT TOLERANT HANDOFF CREATION AND ACKNOWLEDGEMENT

Your business receives high volume of EDI documents (example: Purchase Orders) in a very small window (Say, at the end of day). Business requirements dictate that you have to process all them (without missing a single request), create handoff data so that your in- house applications (such as ERP) can process them and also send the acknowledgements back the sender (say, before next morning).

If you receive few hundred requests at the end of the day, you can somehow accomplish this. But, when your business receives 1000’s or millions of EDI records, accomplishing this in a fault tolerant manner becomes very challenging.

In this context, handoff means, you take the incoming EDI document flatten it so that it becomes easy for your applications to consume the message. Most of today’s solutions involve complex mapping process to accomplish this. We have come up with a very innovative ZERO-MAPPING concept. Our solution will let you generate handoff messages with breeze for any kind of EDI messages. Our X12 platform will let you accomplish this in a very fault tolerant manner.

If you are facing above mentioned challenge in your business, contact us. We will work with you to create a POC for FREE.

 

For more details contact me at shanthu@palisha.com

Tagged

EDI PROCESSING: HAS EVOLUTION STOPPED ?

I have seen great evolution in programming languages and productivity in last 10 years. I started with assembly language. I cannot imagine writing present day complex applications using such languages. However, when it comes to EDI processing, we still do the complex mapping and talk segments and elements. There must be a better way to handle/process EDI documents.

WE WANT TO CHANGE THE WAY WE PROCESS EDI DOCUEMNTS. WE WANT TO BE THE CATALYSTS FOR THIS CHANGE!

MAPPING – WHY WHY WHY?

The following picture summarizes everything I want to say in this post.

mapping-complexity

(Image taken from the book:BizTalk 2010 EDI for Health Care)

I still remember my shift from C/Assembly language to C++. I was very excited with all the good and powerful things OOP/OOD brought to the table. It helped to model complex software better and increasing the productivity by multiple folds.

evolution of programming languages

I have been working with EDI documents for quite sometime now. Most of the EDI processing solutions still talk in terms segments, loops, separators etc.. IMO, there is a big scope for taking this concept to the next level (just like we moved from ASSEMBLY->C++). Once this happens, productivity will shoot up.

language-evolution

Our new solution will attempt to bring the same level of power and productivity as that of  OOP brought to the software world. When an application developer working on a EDI, for example purchase order (850), he/she should not in terms of segments/loops, instead talk about business terms such as Product.Color (this product’s color), Product.Weight (weight of the product) etc. This brings more meaning to the business process (and that’s how it SHOULD be).

We are looking for all sorts of channels to market this idea/product. If you think you can make a difference, let me know and contact me at shanthu@palisha.com

BTW, in addition to bringing new way of looking at EDI documents, our EDI processing platform is designed for scale (bring it on!), fault tolerance, friendly operations.

Tagged ,

SCALEABLE AND EXTENSIBLE EDI PROCESSING

Take the example of claim processing (either on the provider side or at the payer side. There are so many variables. Every payer has their own customizations, 4010A /5010A, professional/institutional.

I have seen many applications (on payer and provider side) doing so much work to process these claim documents to extract the application specific information.

Our design goal was to remove all these complexities make the processing very simple and let the consumers of these EDI documents focus on application specific business logic. Scalability and Extensibility were must have requirements.

Our design is already validated and we have done some POC. You just drop the EDI files and everything happens magically. If you are an enterprise processing large number of EDI documents, our solution supports multiple nodes handling the load. Out of the box, all the claim information is extracted and stored in relational tables (supports SQL Server,Oracle and any other major database). In addition to all this, we have built an extension point which will let you inject your application specific business rules (ordered list of rules executes in the specified order). You do not have to worry about mapping EDI fields. Instead, a detailed object model and/or loops (of EDI specification) will be passed onto the business rule. People who write business rules will have access to rich object model and/or loops.

The following picture gives a good idea about what happens to EDI records in this system:

Tagged