looking for a program to read and parse EDI files or 837i.

The processing and mapping of EDI files to another format is fairly complex.

You really want to try and buy something commercial rather than re-invent the wheel, unless your just doing some data extraction and are not planning on doing the main processing of doucments.

Biztalk Server from Microsoft is one such, and there are other translators out there, such as Sterling Gentran or GIS.

Jim.

Ditto what Jim said. Working with EDI stuff is very, very complex. I do a LOT of this in my day-to-day work, and it's not something for the faint of heart!

Also - 837 is HIPPA stuff, so be careful dealing with that in Access. It's nowhere near secure enough to make it through a HIPPA audit.

<<It's nowhere near secure enough to make it through a HIPPA audit. >>

 Good point, I should have mentioned that.

Jim.

I am currently working with creating the 837P and reading the 835.  I'm not sure how different the I and P formats are.  If you can tell me a little more about what you need, I might be able to share one of the tools I created for testing. When I created the 837P, I used the curmudgeon method.  Each record type is a separate sub.  For example:

Public Function Create_SV1(pCode As String, BillAmt As Currency, Quantity As Long) As String
''page 353
    Dim strSV1 As String
    
    strSV1 = "SV1"                                          'rec id
    strSV1 = strSV1 & "*HC:" & pCode                        'SV101 Composite Medical Procedure
    strSV1 = strSV1 & "*" & BillAmt                         'SV102 Monitary Amount      -- same as in CLM
    strSV1 = strSV1 & "*UN"                                 'SV103 Unit or Basis for Measurement Code
    strSV1 = strSV1 & "*" & Quantity                        'SV104 Quantity
    strSV1 = strSV1 & "*"                                   'SV105 Facility Code Value
    strSV1 = strSV1 & "*"                                   'SV106 Service Type Code
    strSV1 = strSV1 & "*1"                                  'SV107 Composite Diagnosis Code Pointer
    strSV1 = strSV1 & "~"                                   'rec terminator
    
    Create_SV1 = strSV1
End Function

Select allOpen in new window

Hi Experts,

Just to clarify, I am not trying to do billing system from access or store any highly sensitive info in a access db.
I am trying to help a user who has an old Cobol system for billing, while some parts come from a web app that is being sent to vendor for billing in 837 format, now users account receivable dep is having difficulties matching up records from two systems...

Therefore I came up with this theory to have a program read and save the web info (from 837 file) in a temp table (or excel file), which will be imported into the Cobol system, and there it will eventually be mapped in a way that will not require such extensive users resources.

While doing some google research I came across the following site, which seems to do the desired work, for a reasonable fee, wonder if any of you heard of them or have any experience with it?

http://download.cnet.com/HIPAA-837-to-Excel/3000-20411_4-76181366.html

Thanks,
Ben

@Pat,

Attaching a portion of the 837 file, just altered some parts that (may had) contained personal info.
let me know if this would be any help,

Thanks,
Ben
1-19-15.txt

I should add that where EDI gets more complex is in formulating documents, checking the elements (some can only be used when others are used, can only be certain values, etc.) and handling the interchanges and groups, all of which are numbered and controlled.

But with just having to extract data, you can ignore all that.

Jim.

Hi Experts,

@Jim, Scott,
I really appreciate your work, however at the present time, this looks like something that would be very time consuming for me to apply your code and then try to figure out all the specs of this document, therefore my manager decided first to give it a try that software I mentioned above.

I guess, if that does not turn out to function well I will have to come back and try the hard way (for me, maybe for you guys these is easy stuff..)

@Pat,
I did test your code as it sounded more specific to our need, and attached is what I got in result, wondering how can I pull out a full scheduling record?

P.S. I will accept all your suggestions, as the fact that I didn't get approval does not mean the suggestions failed to solve the problem:)

Thanks,
Ben
Untitled.png

Even with Pat's suggestion (or mine), you'd have to "figure out" how to pick out the bits and pieces from that record. In most cases, you can find an EDI "schematic" somewhere online, or you can contact the place supplying you with the document and ask them for the layout/format.

In other words, getting the file broken down to the elemental puzzle pieces is only the first (and generally easiest) part of the battle. After that, you've got to put the puzzle together - and sometimes it feels like you're doing that without the picture on the top of the puzzle box!

Unfortunately, there is a company that controls the EDI formats and if you want the format for a specific transaction, you have to purchase the manual which runs around $500!!!!  A few years ago they were $35 printed.  Now they are $500 as a pdf.

I can't tell you how to pull out a scheduling record.  All I have is the documentation for the 837P.  It might be a "CRC" with "ST" in the third column.  Also, keep in mind that you might actually need several tran types to pull together something meaningful that includes a client number, etc.  In the code I posted, you can see that I save columns from some records and copy the values into others so I can end up with a set of records that I can identify as a "transaction".  There is nothing in the record layout that provides the ability to connect one record to another which is really what makes the EDI files so hard to works with.  The record layouts were obviously developed by someone without a clue regarding how to make them program logic/query logic friendly.  I just had my first file rejected because the service date which is entered as a range had spaces around the dash.  Why start and end dates are not in separate fields is beyond me.  No "programmer" worth his salt would have done that.

You also have to be aware of the source of that file. If it came from a VAN or other 3rd party system in place between you and the trading partner, then the output may be in THEIR specific format.

EDI transactions are purposely designed to be autonomous and platform independent and, to me, are fairly logical. They are structured, and can contain nested elements which are "related", and while they cannot be queried in the traditional ways, you can write code to get the data in a structured fashion. There are most definitely some oddities, but once you figure out how to work with them it becomes fairly straight forward.

EDI formats for X12 (the predominant format in North America) are managed by the Data Interchange Standards Association:  http://www.disa.org/index.cfm. You can join the organization, but you'll spend around $500 to do so.

Ben,

 As Pat and Scott said, you need the spec for the document.  You probably don't have to buy anything, but just go to people that produced the document.

 They should have a specific for what their using and how they used it.

 One of the thing you'll find quickly in the EDI world is that even though it is based on a standard, there's nothing standard about the way various companies implement the standards.

 For example, a SAC is a Service/Allowance charge segment and when someone hand your an 850 (Purchase Order), the SAC should pertain to the PO.   But I've seen a number of cases where info is passed that pertains to their customer and has nothing to do with the PO.   That's a misuse of the standard.

If you can't get a document spec for whatever reason, what you generally can do is a Google search and find someone that has their spec available that you can get at it.  That will give you an idea of what the segments are.

For example, I just Google'd "837i EDI" and came up with Empire Blue's:

http://www.empireblue.com/edi/noapplication/f5/s0/t0/pw_b157810.pdf?refer=ehpprovider

Jim.

Hi Experts,

You will be surprised that the software I mentioned above is very likely doing the job I need w/o any programming or mapping involved, and for the price of $165.

I am just waiting for final user confirmation that the info is 100% accurate.

Basically all I needed is to get the PatientID, Name, Date and time Of Service, Control Number, Amt Charged and perhaps one or two additional fields, and these is what is showing me in that results.
It gives me an option to save in a text delimited format, so from there the Cobol programmer will handle the mappings..

It turned out like Jim quoted above

You really want to try and buy something commercial rather than re-invent the wheel

Its always good to know that in case I do have to work with insides of EDI (or any technical issue), I can count on such high valuable resources as you guys!!

Thanks a million.
Ben

I can build an 837 pipe delimited export file if you're interested.

FYI, I know your set for now, but future readers might want to checkout Liaison's EDI NotePad, which I discovered not too long ago:

http://www.liaison.com/products/integrate/edi-notepad/

 The free version has quite a bit built-in.   For $179, you can get a command line feature and some other stuff, which would probably satisfy the needs of most who are going to cobble something together.

 Even the top of the line version is only $249, and that tosses in a EDI dictionary.

and BTW, no ties to the company.  Just something I was made aware of by someone else.

Jim.