This Perl success story was submitted by Dietrich Schmitz. He shows us one more example of Perl’s flexibility and power.
Here in upstate New York, Syracuse, I work for the SUNY Upstate Medical University where I support an Outpatient Provider-based Claims and Patient Billing system.
With Federal Mandated HIPAA compliancy, there have been many hurdles we needed to cross to become compliant, including migrating our existing Practice Managment system. With exception to only a few Insurance Carriers, most are now receiving the HIPAA-compliant ANSI X12 837 claim format.
A few years ago, I wrote a project that created ASCII flat file export data which was used for import to a third-party software application to perform batch Eligibility and Service Authorizations to an Upstate Insurance carrier. This process was used by our contracted ‘back-office’ Billing service weekly and had been working very nicely. But with HIPAA mandates, the proprietary submission format was due to expire and all transactions, to become compliant, had to be formatted to X12 ANSI 270 and 278 specifications. To make the issue even more crucial, the carrier would not adjudicate an 837 claim without submitting the needed 278 Service Authorization.
Extensive research showed there were no vendors out there that supported this format and the targeted carrier in question for 278 batch submission. There were plenty of interactive websites vis-a-vis WebMD for performing ‘real-time’ (one-by-one) transactions–but not batch.
The process we had in place for the last three years handled on average about 2000-3000 transactions in batch weekly, so replacing it with a manual card-swipe device, or web-based individual transaction based method was unacceptable.
Thus, I decided to write an ‘In-House’ application and effectively became ‘the software vendor’.
Fortunately, Perl came to the rescue.
I have found many uses for this amazing language and this was the biggest project by far that I have written with it. From start to finish, it took over a year to complete, including pilot group testing.
Basically, the process works the same way in terms of steps taken by staff, but is interfaced in a different way.
The user processes their claim transactions that qualify for either an Eligibility request (270) or a Service Authorization (278) from an AIX shell menu interface I wrote.
The shell menu in turn spawns the Perl module I wrote (UT.pm) to create the output file formatted as X12 270 or 278. When the process finishes, it e-mails the user the output file along with a log report.
The user then drops the output file(s) to their local share and dials up an authentication server at the Insurance Carrier host site.
Once this step is performed, the ip address to an authorized FTP server is exposed, and the user then logs onto the FTP server with a login/password and ftps the batch transactions directly to the carrier–a 5 minute process.
The Perl script/modules I wrote for creation of output files reside on our host AIX system.
All of the queries that pull together the needed data elements from our Informix database are performed by Perl/DBI–a ‘beautiful thing’.
ANSI X12 (verses ANSI National Standard Format) is in terms of the specification variable length segments, using an asterisk (*) to delimit fields and a tilde (~) to terminate each segment. Fine. For years, National Standard Format worked fine for me with fixed length fields and fixed length records terminated by a carriage return/line feed pair (0D/0A Hex), but if that’s what they want, Perl can do it–thanks largely to its inheritance of key C functions like printf and sprintf.
Ok, so far so good, they’ve created their output files and ftp’d them off to the carrier from their client Windows PC. The carrier specifies they wait a minimum of two hours before dialing back into retrieve their corresponding ‘Responses’.
The ‘Response’ from the carrier gives the user the answer to either an Eligibility (270) inquiry transaction or a confirmation (approval) for a Service Authorization Request (278).
Then, the second big problem to solve was how best to parse back the (271 and 278 Response) files into a ‘Human Readable’ report format that a user could use to process the information from the carrier.
Well, Perl came to the rescue again.
But I must also give credit where credit is due. Two supporting modules from authors at CPAN were of ‘tremendous’ help and I thank them for their intellectual efforts. They are:
X12::Parser (http://search.cpan.org/dist/X12/lib/X12/Parser.pm)
Spreadsheet::WriteEXCEL (http://search.cpan.org/dist/Spreadsheet-WriteExcel/)
I installed to the office dial-up PCs the Windows-based ActiveState Perl interpreter (www.activestate.com) and installed the two above modules.
Cobbled together with a few DOS batch files and supporting perl scripts, the users retrieve back their response files and ‘drag drop’ them to an Icon which transparently invokes a perl script I wrote (x12toxls.pl) that parses back the response files into an EXCEL spreadsheet and automatically starts up the spreadsheet for viewing/printing.
Everything fell into place and I was able to meet the HIPAA-complaincy deadline and now have some 10 Hospital sub-specialties running in production mode now with X12 270/278–thanks to Perl.
It is ’so true’ that Perl ‘makes the simple things easy and the hard things possible’.
Thank you Larry Wall.
Dietrich Schmitz
Syracuse New York
