Health Claims Data (835 file) in Access?

[groleau]

Is anyone on the list in health care using Access to store claims data from 835 files?

If your work environment requires that you treat these questions as "private" or "secret" info, I understand and
am not offended. But if not, ...

1. Can you give a "ballpark" formula for the size of the
database file? i.e., Ax + B where x is number of claims.

2. Are you capturing _everything_ in the claims, or just
certain particularly needed segments?

3. If your volume is too big for one file, what scheme do
you have for handling multiple files?

4. Are you willing and able to share code for parsing 835s?
(I haven't asked, but I suspect my boss would agree to
a mutual sharing--but I admit I don't have anything
sophisticated.)

5. Can you cite one or more websites dealing with this
sort of thing?

6. Is this the wrong forum for this sort of question?

There is a free tool from Medicare done in C#.net which
I was able to decompile into VB.Net with "Reflector"
(

http://www.aisto.com/roeder/dotnet).

But combining the
complicated design with the differences between VBA and VB.net and the quirks that are normal with any decompiler, it was not practical to use any of it, at least for our purposes.

However, if anyone else thinks they could use it, you can get "EZPrint" from your FI. Since tax dollars paid for it, it is not subject to copyright restrictions.

--
Wes Groleau

http://www.Parkview.com/

 

[hneal98]

My suggestion would be to store that data in SQL Server. Access seems to have problems with performance once you hit around the 50-60,000 record number.

As for your 835 format, I would not store that in Access, Claims can get real big real fast. If you have anyone who can work with SQL Server or similar datbase, that is the way to go.

 

[groleau]

Thanks. I haven't noticed any performance problems with 50-60 K records, but I had an application not long ago where Access went absolutely bonkers every time I got past about 250,000 records. I had to start over pasting my VB & SQL into a new blank database and then it would crap out again.
Blew up each time at a different spot in the code, with the same input data. Anyway, ....

We wouldn't store the 835 format in Access--I was considering parsing it and organizing just the fields we need in Access.

SQL Server is probably best for our volume (or Oracle) but Access is a little easier to work with for me. But if I do use Access, I have to split the collection up into several (MANY) databases and I'm not sure of the best way. Probably
I'll end up with what some folks call "a REAL database" IF I actually do it at all.

--
Wes Groleau

http://www.Parkview.com/

 

[hneal98]

Well, the important thing to start with would be setting up the tables. you would basically set the tables up based on the loops. Anything segments that only appear once would go in the main table and then all the children tables from there would be based on the loops in the file. From what little I know about the 835, I would think you might end up with around 10 to 15 tables. I have worked more with the 820 which is Premium Payments. I got about 10 tables from that one.

Good luck in whatever you choose. Personally, I would want to work with SQL Server. I worked with Access for a long time and like you said, at some point it just doesn't work right.