Home Forums Discussions General Discussion Superbill Software Needed

We use a billing service. I need software to send my superbills to them. Suggestions appreciated.

How do you currently send your superbill?

What kind of software did you have in mind? Can you provide an example?

we use WINSCP (secure FTP) to transfer our superbills to our billing company. It is free. We also send the EOB's to them as well. All correspondence (whether EOBs or our superbills) is sent via PDF to our billing company and put into folders with the appropriate date of transfer.

At first, we used the invoice generated directly from AC. However, the billing company wanted more information (such as secondary insurance, employer, group numbers, etc) so we needed to create our own invoice in PDF format.

We ended up doing regular extracts of our bills using AC and then putting them into CMS20007 format. After importing back into MSaccess, we created a custom report to print the PDF format we needed.

I would like to eventually do this directly from the AC database to eliminate the export/import steps. This is where an SDK (software developer kit) would be beneficial for AC. We could develop our own custom addon to overlay onto AC and then share these customizations with others.

Eric,
I would love to have access to the AC database because I do a little database work and my husband does software development in access, sql, and other languages. I would like to start with my AC note and devleop my own superbill program. May still do that.

Brian,
I would like a program that I can enter insurance info, copays, cpts and icds into and then transmit via secured server to my billing company. We are currently generating manual superbills on AC at the end of the day from my new flowsheet. There has to be a better way.

Eric, just realized more what you are saying-love the idea of being able to devleop addons and share with others. How amazing!!

I said the SDK, and I know others have too. Just look at Bert and FAP as one good example. I think Jon really needs to hear this one...

Another clarification-
I do not want to print superbills, I want to send them encrypted to my biller.

how does your billing company want to receive the invoices? will they accept a delimited text file as a submission or do they need a electronic printout (saved PDF)? this makes a difference in your approach to the problem.

Either way, secure FTP is necessary for either type of transfer. Printing to a PDF file is possible with programs like CutePDF or Adobe Acrobat Writer. This is how you get the "printout" into electronic format so you can send them encrypted via secure FTP. There are many products for secure FTP, WINSCP is just one of many. If they will accept a delimited file, this will save you a few steps.

I'm kind of new to the AC SDK idea- why would you want an SDK when AC is programmed using VBA in MS Office? It should be fairly easy to link a parallel app onto your backend AC tables I would think...

Just do a Google search for "MS Access Add-in" and you'll get articles like this: http://www.databasedev.co.uk/access-add-ins.html

That said, you don't really even need an add-in. Just make a form and link it to the AC backend tables. You might have to add a couple of tables for CPT and ICD lookup (I can help with that if you wish).

If you want to send your bill encrypted, just zip them with just about any software like WinZip, which is downloadable from www.cnet.com.

Sure, you could hack into the tables now if you wanted but your add-on wouldn't really be recognized or certified by AC as they don't have the SDK arrangement. I think many people on this board know how to do the hacking from previous posts but this is in no way supported by AC.

An SDK just would make it official that the add-on programs would be considered before future releases. Also, the relationship between the developers of the add-ons and AC would be made clear by this arrangement.

An SDK should also put into place a more structured release management process for dealing with db structure changes. Makes the programmers think twice before they make changes to the db structures that could screw up a person's addons.

My billing company can accept files in delimited form.
Would sure love to know the names of some of the software packages out there, with pros and cons please.

It's not a matter of "hacking" into tables, which makes the issue of add-ins somewhat shady. Remember, the information in your tables are those of your patients and are thus legally yours. I'm surprised that this issue wasn't covered recently in the AC convention, which Jon attended. You are correct that it is always best to get the original developers on-board, as they can not only give you their blessing, but they can help with certain technical aspects of any project. They even may need to add a section specifically focused on downloads to the forum!

I don't think that you'll ever get an "SDK", though. SDK's usually are used to provide an interface between 2 disparate platforms. Case in point: when I used to program for the Palm environment using Satellite Forms (SF), the SF developers provided an SDK so as to allow for add-ins that were programmed in Visual Basic (SF is programmed in a low-level "C" language). The add-in development became so robust that when SF was sold off, it was purchased by the largest add-in developer, Mr. Thacher. SDKs will be big business if and when the HL7 becomes the defacto standard, since it's both complicated and at times somewhat proprietary. The interoperability promised by our despised CCHIT could easily be made by offering a free government financed SDK interface without all the other "standards" stuff.

AC, written in MS Office, is based on a very popular platform. When an executable is made (i.e. an MDB is converted to an MDE shell), all the code is hidden and is essentially locked. The tables, however, are always available and easily retrievable, even when password protected. Password protection thus only serves to keep the casual user from damaging the underlying tables if they don't know what they are doing.

Anyhow, maybe Jon can give a "townhall" meeting on-line to discuss add-ins (the politically correct word, BTW) which would take his AC program to new heights.

Vicki- MS Access exports information in any number of file types-

-- MS Office/Access (s.a. *.mdb, *.adp)
-- MS Excel (versions 5-2003, *.xls)
-- HTML document
-- Text Files (*.txt, *.csv, *.tab, *.asc)
-- MS Active Server Pages (*.asp)
-- MS IIS 1-2 (*.htx, *.idc)
-- Rich Text File, *.RTF
-- for Access 2003 and 2007, *.XML
-- for Access 2007, *.PDF

It can also use the old, venerable ODBC for connection with enterprise backend databases, s.a. SQL, Oracle, etc... so you don't need to buy anything other program.

Alborg, I beg to differ with what you have written:

1) The information in your tables are those of your patients and are thus legally yours.

In a relational database design, the data that comprises a "record the user sees" is stored across multiple tables. So for example, while the basic patient record is stored in the PATIENT table, the PatientInsurer table holds the info about the insurance carrrier for a specific patient. These two tables are JOINED to PRESENT a patient record on the screen(User Interface).

Addendum:
If Vicki needs a CSV or other delimited file she will need to write those out ONE RECORD PER LINE. The Carriage Return (delimits) a record.

This means that she, Vicki, must now write a QUERY that produce in One Line, WITH CORRECT delimiter, all the information she needs, from the multiple tables that a "record" is comprised of in AC.
End Addendum

Most users do not know enough about database architecture to make sense of the tables in a RELATIONAL DATABASE. And most developers will not put there DATABASE SCHEMA in the public domain.

There is, however, a way for Jon to make AC accessible WITHOUT putting his schema in the public domain:

When the database is switched to SQL Server, AC can publish
a) the list of STORED PROCEDURES (SP) calls
b) the input parameters
c) the return parameters

The stored procedures can be ENCRYPTED so that the user cannot see the SP code, but still allowing a user/developer to interact with the database

2) SDK's usually are used to provide an interface between 2 disparate platforms.

This is not usually the case. SDK's are written to provide DEVELOPERS with a COMMON and STANDARD way to INTERFACE with an application which ensures the developer is going to be CONSTRAINED to using the standards/calls designed by the manufacturer.