It’s always fascinating how a simple problem can blossom into something much more complicated. Ninety-five percent of the time when we need to report post test results for spirometry they are for post-bronchodilator. The remaining times they are for supine or post-exercise spirometry. At least once or twice a month however, we need to report two post results, not just one and this is where we run into problems.
The most common scenario for this is when we need to report a baseline result and then both a post-exercise result and then a post-bronchodilator result. We need to do this when a patient bronchospasms during or following an exercise test and we find need to give them a bronchodilator after performing the post-exercise spirometry. Less commonly we are occasionally requested to perform both supine and post-bronchodilator spirometry as part of the same visit. Whenever either of these situations occurs we need to perform a number of work-arounds that end up taking extra time and effort.
The problems start in the spirometry test module. In post test mode it is possible to put different labels (“Albuterol”, “Combivent”, “Supine”, “Exercise”) on post spirometry test results. This means that each post test result can have a different label but it is only possible to select one and only one result (which can be a composite but can only have one label) to be reported. This problem is reflected in the Reports module of our lab software which does not permit more than one post result to be placed on a report.
These limitations mean that we need to create two “visits” in the lab database and two reports in order to capture the two post results. This also means that whichever post result is performed as part of the second “visit” there is no baseline to compare it to and that when interpreted changes from baseline have to be calculated manually.
If all we had to deal with was two reports this wouldn’t be a real problem. It gets more complicated very quickly. There is an intimate connection between our hospital’s appointment scheduling system, the hospital’s billing system for PFTs, the physician billing system for PFT interpretations and reports. There is a one-to-one relationship between appointments, bills and reports. So in order to get two reports uploaded into the hospital’s computer system there has to be two appointments. Because there are two appointments there are two sets of bills (hospital and professional, one for each appointment) but we can’t bill for supine or post-exercise spirometry. So only one report can have spirometry with bronchodilator billed and the second report can’t be billed at all which means we have to manually generate an exception for the hospital and professional billing systems. It also means that if an additional post test is unexpectedly “added-on” for any reason that we need to go back and create another appointment for the patient.
We’re not going to stop performing combinations of supine, post-exercise and post-bronchodilator spirometry simply because we can’t bill for them and because of the problems they cause in dealing with reports, appointments and billing. This is just part of taking care of our patients. It does mean that the lab staff need to pay close attention when making appointments and billing for any patient testing that will have two post spirometry results however.
These procedural problems could be solved right where they started, in our lab software’s spirometry and reporting modules. If multiple post spirometry results could be selected and reported then there would be no need for the appointment and billing work-arounds. I can think of several different ways to select multiple post results within the spirometry test module without altering our lab database so this is the easy part, relatively speaking. Reports are a far more complicated problem.
When thinking about reporting multiple post results in the same report I can think of of two different approaches. First, increase the width or number of columns in the spirometry module of the report so that the baseline and two sets of post results can be reported.
The second approach would be to duplicate the spirometry report module so that the baseline and first post results appear in the first table, and the second post results appear in the second module.
Reports remain problematic however, because when designing a report with our lab software you are required to place the report elements in specific locations on each page. We have created a single report that can contain all possible tests and all possible results that we perform but this report is 12 pages long and for almost all patients there are a lot of empty result modules and it is very confusing and difficult to read. We save this report for those times we need to provide results to researchers. For everybody else we have created another eight different report formats that are much shorter and contain the most common combinations of tests we perform. Even so, no report is less than three pages long and a few are as much as five pages long. Given the current state of the reporting software we would have to add at least a couple new report formats in order to handle multiple post spirometry results in a single report.
I am not happy with our reporting software. This static approach to report formatting is very cumbersome because when we need to change even just one element on the report then nine different report formats need to be individually updated. Since it is not possible for the lab software to select the appropriate report format automatically this also means that report formats have to be manually selected and if the wrong format is selected then results will likely be missing from the printed report.
The static report formatting approach, where the report elements have to be placed in specific locations on a page, is not unique to our equipment manufacturer’s lab software and in fact, it appears to be the most common approach and I just don’t get it.
A large part of the reason I don’t get it is that I remember 15 years ago when the DOS version of our lab’s software used dynamic report formatting. A report was made up of modules, one module for each possible report element (demographics, spirometry, DLCO, graphs etc). Once each module had been customized and the order of the modules specified, that was it, you were done. There was only one report format so you only had to make changes once. When a report was printed then only the tests the patient performed would appear on the report which also meant the length of the report changed as well. Reports were always simple and readable with no blank spaces.
I guess I could understand the static approach if you wanted to create a standardized single-page spirometry report but once you have a PFT lab that provides many different tests in many different combinations then either you have to create a single, hard to read report that contains everything including the kitchen sink or you have to create and maintain many different report formats. Like I said, I don’t get it. Unfortunately our equipment manufacturer “improved” our reports when we went to the first Windows version of our lab software and we lost this simple functionality. If our lab equipment manufacturer ever goes back to dynamic report formatting then printing multiple post spirometry results will be easy and straightforward.
In a sense this problem really starts with the assumption that there will never be a need to select and report more than one post spirometry result. This is just not true and we’ve had to develop a complicated set of work-arounds to get it to happen. I suspect that we are not alone in this but I also suspect that hardly anybody considers this a big enough problem to bother really fixing it and that’s too bad.
PFT Blog by Richard Johnston is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.