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:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: