On 05 Apr 2003 16:23:29 -0600 Fred Trotter <[EMAIL PROTECTED]> wrote:
> > Hello, > It is time to announce a new project of the FreeMED Software > Foundation. The FreeMED Billing Project. It has become clear that this > Project should be a meta project. There are several FOSS Practice > Management systems, but no one has a really good implementation of a > Billing System. Like FreeMED the other projects seem to be implementing > billing in a piecemeal fashion, supporting whatever their particular > users request. This is not the fault of the Projects. Billing is > arbitrarily complex due to the whim of the insurance companies. A system > is needed that can quickly adapt to that system. Hi, It's a great idea! Here's a few disorganized thoughts that came to mind, I may be all wrong on some of it: The really important part is to map back and forth between XML and the EDI formats like ANSI X12. It doesn't matter what programming language it is written in. The most important thing is to concentrate on developing an XML mapping to the ANSI X12 EDI format that HIPAA now requires for electronic billing, and provided it runs on Linux. So just don't use Visual Basic! All viable programming languages have XML tools now, so they could work with the XML to EDI translating module like a "black box" just feeding it XML data or EDI data and getting ANSI X12 or XML back. The transmission protocol isn't that important either. Whatever package would reliably produce ANSI X12 EDI format from an XML feed would be adopted regardless of what format it uses, since it is now the main missing piece for electronic billing and would be so important you'd just accept whatever the programmer chose to use. EDI is a larger problem than just medical billing. The ANSI X12 EDI format is used in other industries besides medicine. The medical standards used now by HIPAA are just a specific implementation of ANSI X12 in which the trading partners - us and the payors - have "agreed" to use a certain subset of ANSI X12 . In Europe I read they use EDIFACT which appears to be similar. Is that correct? There appear to be numerous commercial products that exist to translate one format to another - EDI to EDIFACT, XML to EDI, EDI to XML etc. but I was not able to find any open source packages for this job. This EDI handling seems to be one of the most closley guarded trade secrets of the closed source programming community. I wrote to one programmer who did release a small open source utility for breaking the EDI file segments with a newline, so it was more easily readable for debugging their software. He responded "why should I want to help doctors when I just lost my job and have no health insurance?" Once you produce the properly formatted ANSI X12 EDI file, you probably don't need to worry too much about writing your own program to control the modem, because all you really need is a terminal program like minicom to dial up the Medicare intermediary which uses what amounts to an old fashioned bulletin board system and transfers the files by Xmodem or Zmodem. Also there are more insurance clearinghouses setting up web based transfer systems that upload and download files via SSL encrypted http protocol. Automating the direct modem serial connection could be done with expect, and while kind of nice, is not that critical. But mapping the 835 explanation of benefits EDI format you get back to XML, which could then be imported into the EMR project in an automated fashion would be very important. Regarding the "language" for filling out forms: I think you might want to check out ReportLab - In the Tkfp project we are doing paper forms billing using a PYTHON module called ReportLab. Report Lab is cool because it's an open source toolkit which the company makes a living on by providing service and support. They have a site on Sourceforge for it http://reportlab.sourceforge.net . ReportLab has a template Language for developing .pdf forms. Basically you have one template for the fixed part of the form and another for the data part. Then you just substitute your data into the data template using your favorite scripting language (Tcl). The original template language was not XML, but now they are developing an XML template specification for producing .pdf documents. In the Tkfp project we have a ReportLab template for the HCFA 1500 form. The HCFA 1500 form in the U.S. is more or less a universal claim form that can be used for office billing for both the Government and private insurors. For hospital billing or Federally qualified clinics, you need to produce a UB 92 form. For a simple way to do electronic claims, you can create a "print image" which is a simple text file with only the data fields from the HCFA 1500 form which can be extracted from the .pdf file. Then a clearinghouse uses their own "mapping" software to map your print image file to the ANSI X12 format and forwards it to the payors. However, to bill Medicare directly electronically, it is required to submit your data in the ANSI X12 format. The SolAce client program mentioned on the list recently functions to "map" your print image file to the ANSI X12 format . It is a very nice program. Unfortunately the client program that does that mapping is not open source. But it does run on Linux, since it is written in JAVA (I unzipped the Windows package on a Windows partition and ran it under Linux and it works fine) and might be good to use as a service to link into from your EMR, since it uses an XML format internally to store the data before translating to the EDI format. The SolAce server that IS open source is really a sort of like a "mailbox" for organizing the data files prior to transmission and storing reports you get back, I think. Correct me if I'm wrong. If you are billing multiple insurance companies, it's probably more practical to just use a clearinghouse instead of maintaining your own electronic relationship with each payor which requires testing, phone calls, maintaining passwords etc. The ANSI X12 format doesn't appear to be insurmountably complicated from reading of the specs and viewing some sample files. It is just a text file with some "fixed" segments that are present in every file and some variable segments that may or may not be present and can be repeated for batched claims files. It's just that since it gets read by a machine, it's rather fussy about errors in the format. Too bad they just didn't use XML, which is a lot easier for humans to read and has a lot of open source tools to work with than the X12 EDI format. I would like to help with testing with anybody interested in ANSI X12 EDI format. ANSI X12 837 files look like this, too bad they just didn't use XML. But they chose this, so we have to deal with it: ISA*00* *00* *12*Sender *12*ReceiverID *010821*0000*U*00401*000000001*0*P*:~ GS*HC*SenderDept*ReceiverDept*20010821*0000*000001*X*004010~ ST*837*0021~ BHT*0019*00*123*20010924*0932*RP~ REF*87*004010X098~ NM1*41*2*Premier Billing Service*****46*TGJ23~ PER*IC*JERRY*TE*3055552222*EX*231~ NM1*40*2*XYZ REPRICER*****46*66783JJT~ HL*1**20*1~ NM1*85*2*Premier Billing Service*****MI*587654321~ N3*234 Seaway St.~ N4*Miami*FL*33111~ NM1*87*2*Kildare Associates*****24*99878-ABA~ N3*2345 Ocean Blvd.~ N3*2345 Ocean Blvd.~ N4*Miami*FL*33111~ HL*2*1*22*0~ SBR*P*18*12312-A******HM~ NM1*IL*1*Smith*Ted****34*000221111~ N3*236 N. Main St.~ N4*Maimi*Fl*33413~ DMG*DB*19430501*M~ NM1*PR*2*Alliance Health and Life Insurance *****PI*741234~ N2*COMPANY~ CLM*26462967*100.00***11::1*Y*A*Y*Y*C~ DTP*431*D8*19981003~ REF*D9*17312345600006351~ HI*BK:0340*BF:V7389~ NM1*82*1*Kildare*Ben****34*112233334~ PRV*PE*ZZ*203BF0100Y~ PRV*PE*ZZ*203BF0100Y~ NM1*77*2*Kildare Associates*****24*581234567~ N3*2345 Ocean Blvd.~ N4*Miami*FL*33111~ LX*1~ SV1*HC:99213*40.00*UN*1***1**N~ DTP*472*D8*19981003~ LX*2~ SV1*HC:99214*15.00*UN*1***1**N~ DTP*472*D8*19981003~ LX*3~ SV1*HC:87072*10.00*UN*1***2**N~ DTP*472*D8*19981010~ LX*4~ SV1*HC:86663*35.00*UN*1***2**N~ DTP*472*D8*19981010~ LX*4~ SV1*HC:86663*35.00*UN*1***2**N~ DTP*472*D8*19981010~ SE*43*0021~ GE*1*000001~ IEA*1*000000001~
