Looking for some help. Read an 837I and produce a 999

Aug 8, 2012 at 4:30 AM

Hello All,

As a second job, I contract for a small medical billing company.  I wrote and maintain their medical billing software.  The software is written in Borland C++ and tracks claims and can produce UB92s and UB04s.  Currently they have more work for me than I can handle.

I now need to get 5010 837Is into our system and I want to use this X12 Parser.  So far using this tool, I have been able to parse apart some sample 837s into a flat file* that I can load into my DB but I don't know how to go about being able to produce a 999.  If there is anybody that would like to do some contract programming and write me a program that can do that, or has a program that can read an 837 and produce a 999 using this parser that they would like to sell please contact me.  To be clear, I am asking for the source code.

If you are a decent C++ programmer please contact me as well.

Thanks, Doug


*I used a separate flat file because I ran into naming problems.  My DB has a table named Claim and when I hooked up my program using the parser and an ODBC driver to talk to my Paradox tables I kept getting a naming conflict on the Claim object.  The flat file was the quickest solution I could think of.

Aug 8, 2012 at 1:46 PM

Does the source code need to be in C++?  What if it's an xslt?

Do you have implementation specific validation or do you just need it to validation against the rules in the 837I specification?

Aug 8, 2012 at 2:15 PM
Good Morning dstrubhar,
Sorry for not being clear. The source code for the response tool should be in C#. The C++ experience is for the billing software.

This is not implementation specific and should just validate against the 837I spec. I would like the source so if and when it does need to be implementation specific I, or somebody else, would be able to make the modifications.

Thanks, Doug

On Wed, Aug 8, 2012 at 7:46 AM, dstrubhar <notifications@codeplex.com> wrote:

From: dstrubhar

Does the source code need to be in C++? What if it's an xslt?

Do you have implementation specific validation or do you just need it to validation against the rules in the 837I specification?

Read the full discussion online.

To add a post to this discussion, reply to this email (x12parser@discussions.codeplex.com)

To start a new discussion for this project, email x12parser@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Aug 9, 2012 at 4:05 AM
Edited Aug 9, 2012 at 4:12 AM
dstrubhar wrote:

Does the source code need to be in C++?  What if it's an xslt?

Do you have implementation specific validation or do you just need it to validation against the rules in the 837I specification?

Hi dstrubhar,

How would using an XSLT be different than using your x12 parser?  I've used C# and C++ but not XSLT.  Is it a language in itself or is it used in conjunction with another tool set?

As a side note, even if I end up paying for it I don't think it would be a problem to add this tool to your oopfactory X12 Parser project.  It would be a good addition to the tool set to have a program that can create a response file based on the config files that have been created.


Aug 9, 2012 at 2:35 PM

I don't think I would use the XSLT.  It would be useful if you were doing something simple like just sending acknowledgement that you received the files, but it is not ideal for looking for errors and adding the error segments.

I have been asked before for this feature and I've been thinking about the implementation.  I have recently added a X12StreamReader that will parse out one transaction at a time regardless of if the x12parser class was able to parse it or not.  This will be helpful in reporting errors in invalid transactions.

I wouldn't mind adding it as a separate assembly to the project, but I don't know how long it will take to finish.  I could at the least create an extendable class so that if you don't choose an OTS solution, you have a starting place.  I've been thinking I wanted to add another documentation page with a different use case of the parser, so this would be a perfect for that.

Aug 14, 2012 at 12:49 PM

I have added an assembly called OopFactory.X12.Validation with an X12AcknowledgmentService.

To see it's usage look at the OopFactory.X12.AcknowledgeX12 console application. This is provided for demonstrations purposes.  Since this is an acknowledgment you will want to make sure that the decision on each transaction is integrated with your intake process.

The service will return Accepted (A), Accepted with Errors (E) or Cannot Analyze Content (X).  You may choose to change some the "E" to Rejected "R".  This should be done after you actually verify that you have imported the transaction into your system and will be able to process them.  This can be done before the serialization to X12.

I still need to add some unit test and some minor validation.  I will get that checked in over the next couple of weeks.

You will be able to override the  ValidateSegmentAgainstSpec and ValidateContainerAgainstSpec to add your own custom validations or inject your own SpecificationFinder.  I'll do a write-up of how to do all this in the next couple of weeks also.