Beaverlog Tips:  Volume 38 - October 22, 2007

Support Ended for Version 1.0

As of October 1, 2007, live technical support for The THERAPIST for Windows version 1.0 will no longer be available.  Our policy is to provide technical support for a product version for four years.  Version 2.0 came out on 9/16/2002 which would have meant the end of support for version 1.0 on 9/16/2006 but the policy didn't go into effect until this month.  For those of you still running version 2.0, your support will end in June 2008, in less than eight months.  If you have unused, prepaid support, we will continue to honor it until it is used up, even for version 1.0.

 

Clearinghouses Looking Better and Better

Electronic claims clearinghouses provide many useful services and because they make their money only when you are submitting claims, they work hard to make that as easy for you as possible.  Of course, there is a cost for this service, though it is usually less than what you would pay to process and send the same claims via paper.

Until recently, if you submitted any electronic claims to Blue Cross, you could use the THIN clearinghouse for free even for claims to other payers.  THIN, however, has been swallowed by Availity and those claims are no longer free.  We have heard that they are charging $0.42 per claim, on a par with other clearinghouses.  Some of our customers have reported to us that not only is their service no longer free, they are charging between $100 and $500 to migrate from providers from THIN to Availity.

If you have been following the Availity saga in our newsletters, you are aware that Availity is very different than other clearinghouses in at least one important way:  they seem to go out of their way to make it harder rather than easier for you to successfully submit your claims.  This makes other clearinghouses look better and better.  We have had the most success with the ET&T clearinghouse (www.ettch.com).  This company takes customer service to the next level and we have nothing but good things to say about them.

 

Give Support a Jingle

Jing is an interesting (and free for now) new product from TechSmith, makers of the popular and award winning Snagit and Camtasia programs.  We use Snagit to capture screen images for our documentation and technical support uses it to show users how to do something when a picture is more effective than words.  We also use Camtasia to record The THERAPIST as it is being used for our short video tutorials and we will be using it for the computer based training that is now in the planning stages.

The new program is both a software program and a service that lets you quickly and easily capture a screen image or video of anything on your screen.  Then, with a couple of clicks, you can send it technical support or to anyone you want.  This is a convenient (and did I say free?) way to communicate exactly what is happening to support so that they actually can see what is happening. Just send your capture to support@beaverlog.com.

Go to www.jingproject.com for more information and download the program.

 

Sleuthing a Bug

By Peter Gysegem

Several titles for this article suggested themselves.  Among the ones I considered were, "How I Found and Fixed a Major Problem," "Dumb Luck Outwits Overly Clever Programming," and "Good Detective Work Solves Intractable Problem."  Ok, the last one is somewhat too contrived and not a very good synopsis of the article either.  The first is not bad though a bit boastful but second is probably the most accurate.  In the end I opted for the simple title you see above.

This article is a bit of a mea culpa.  It is a slightly technical account of how blind fortune lead me to the source of a bug that has been plaguing us, not to mention users of The THERAPIST, for a couple of years.  The big mea culpa is that this was a problem that I introduced myself by being too clever while trying to be efficient.

If you have multiple practices and have been using The THERAPIST for awhile, you have probably experienced the problem of not being able to open the patient list after switching to a different practice.  A message came up that there were no providers so it couldn't open the patient list.  You also couldn't open the provider list or any other screen that used a practice data file.  Though this problem has been plaguing us for a long time, we had been unable to solve it, mainly because we couldn't reproduce it under controlled conditions.  Because of that, we couldn't determine the actual cause.

That changed in July 2006 while I was working on Pro release 2.5.017 and EZ release 2.5.012 and it happened almost by accident.  We were fairly certain that the problem was happening because one or more data files were being opened by one procedure or another but not closed when the process was finished.  A procedure in programming parlance is a piece of the program that does something, large or small, that is contained in one block of source code.  It could be something simple like taking a patients separate first and last names and combining them into a whole name or as complex as the patient list screen.  There are hundreds of procedures in The THERAPIST.

We believed un-closed files were the culprit because what happens when switching practices is that all of the practice files (but not the global files) were changed to refer to files of the same name but in a different folder.  This can happen only when the files are closed.  If they are not closed, weird stuff happens and weird stuff was most definitely happening.

We just couldn't figure out what part of the program was causing the problem, despite many hours going over the source code in minute detail.  I looked at every procedure that opened a file and found that it closed the file when it was finished.  Many procedures use a flag variable that is changed from 0 to 1 when files are opened.  The variable is then checked when exiting to see if the procedure opened the files.  This is because sometimes a procedure will exit early, before it ever opens any files.  If the flag was set to 1, then it was ok to close the files.  Our checking revealed that all the flags were being set properly and checked at the right place and time.  It was maddening.  According to all our testing, the problem should not have been happening but it was.  It felt like a doctor saying that the operation was successful but the patient died.

While working on an unrelated issue in the patient list procedure, I was viewing the progress of the program using a debugger, a program that lets me look under the hood while a program is running to see what is happening.  Quite by chance, I noticed that the flag variable used to indicate whether the procedure's files had been opened changed from 1, which it was supposed to be, to 0, definitely not what it was supposed to be.  What was even stranger, a search revealed that nowhere in the procedure was this change being made!

What the search did show, however, was that, in an apparently misguided attempt at efficiency, I had reused the flag variable as a an invisible place holder in a list.  I hadn't yet connected this issue with the problem in switching practices but somehow, this unexpected behavior seamed important even though it was having no negative impact on the list itself.  It was unexpected because a list wasn't supposed to change a variable displayed on the list, or so I thought.  In retrospect it is not too surprising.  Ordinarily, list elements are filled from a data file.  By using a variable not in a data file, even though it was not a visible element in the list, it makes sense that it is cleared (set to zero in the case of variables that hold numbers) before filling it with another record from the data file.  And since it wasn't a field from a data file, it would be cleared but not filled with anything.

It was at about this time that the ramifications of that simple oversight began to dawn on me.  Because I happened to use the flag variable that tracks opened files, and because it was being cleared, the files opened by that procedure would not be closed when the window was closed.  Eureka!  I may have even said that aloud.  Many pieces of an old puzzle suddenly fell into place.  The reason all my earlier searches for the cause of the practice switching problem had been unfruitful was that it was happening in a part of the program that is unrelated to the opening and closing of files.  The procedures that manage almost all of the lists in the program, including the one that cleared my variable, are in a separate set of files (class libraries, for those dying to know the technical details) and all these list management procedures know about that variable is that it is a thing I placed on a list.  They don't know or care what that thing is used for.  That was my job.  Mea culpa.

Now that I knew what was keeping the files from closing, it was easy to reproduce and confirm the problem in both Pro and EZ.  A simple search of all the source code showed that it occurred in several places and it took less than an hour to make the corrections and test it.  I was feeling lucky.  I was at the right place at the right time, looking in the right direction, and was poised to see the connection.  Most program problems are harder to find than to fix but this was one for our record books.  Needless to say, the rest of the technical staff and I were jubilant.  The fixes were proud additions to he July 2007 releases of both Pro and EZ.

P.S.  A relatively simple mathematical exercise proves that it is impossible to fully test all possible combinations of circumstances an any but the most rudimentary software programs.  The THERAPIST Pro has about half a million lines of source code.   If it took one second to test each of the possible execution paths, it would take much longer than the current age of the universe.  Email me if you want the details.