Static reports, dynamic world

Reports are how patient test results are distributed. Paper versions have become less common because reports are now stored electronically in hospital information systems. Even if the way in which a report’s image is now stored, retrieved and distributed has changed, reports are still generated by our lab’s software systems and the ways in which this is done have not changed in any significant way for quite a while.

Reports are the public face of any pulmonary function lab and they should be designed to be readable and pertinent. It is critically important for any lab to create and manage reports correctly. So why does our lab software make it so hard to do this?

Over the last several months I’ve had the opportunity to compare the reporting systems of the three largest manufacturers of pulmonary function equipment in the US. There are differences of course between each reporting system since each has its own approach towards formatting, editing and printing reports. What they all share however, is a similar underlying model for reports that I call static report pages.

What I mean by static is that the report elements and their position on a report page are determined and fixed in place when the report is formatted. When the report is printed, regardless of whether the results are present or not, the report page does not change. This means that if you format a report to contain spirometry, lung volumes and DLCO, and the only test you perform is spirometry, when you print the report the sections for lung volumes and DLCO will contain no results but they will still appear.

The number of tests that need to be placed on a report will vary from lab to lab depending on what equipment they are equipped with. For example, these tests are available on one manufacturer or another’s test systems:

Spirometry

Lung Volumes – Plethysmography

Lung Volumes – N2 Washout

Lung Volumes – Helium Dilution

Diffusing Capacity

RAW/SGaw

MIP/MEP

MVV

SBN2

6MWT

FOT/IOS

There are probably other tests as well but even if there aren’t, there are other report elements such as demographics, text notes, flow-volume loops, trends etc. that also need to be managed.

A lab could create just one report format that would fit all of the tests it performs but in most instances this report would be at least several pages long (my lab has a report for research studies that has ALL the results from ALL tests and is 14 pages long). A report like this would neither be pertinent nor readable since many of the results would usually be blank. This means that multiple report formats need to be created and maintained. The number of possible combinations of tests can be calculated from 2^N where N equals the number of tests (and this doesn’t include the other report elements such as demographics, text notes, flow-volume loop graphs, trends, etc). There are 11 tests listed, so a lab that performed all of them could have 2^11 or 2048 different possible combinations of tests. Since most labs tend to perform only certain combinations of tests, this is a significant overestimate. Even so, in order to keep our reports pertinent and readable my lab has 12 different report formats and I know of a lab that has over 40 of them.

The first problem with this is that once a set of tests has been performed the lab staff has to choose the right report format. Really? Since the lab software “knows” what tests have just been performed, it also “knows” what tests are included in which report formats. So why isn’t the software able to select the right report format or at least suggest the formats that include the tests that have been performed? The technicians in my lab select report formats reasonably well, but mistakes happen and when they do it can take some time to discover them.

A second problem has to do with modifying or updating report formats. When a change needs to be made, say by something like adding the FEV3/FVC ratio or removing the FEF25-75 from the spirometry results, every single report format that has a section of spirometry results needs to be updated individually. Since the position of all report elements has to be explicitly specified, when one of them is re-sized all of the remaining ones also have to be re-positioned. This means that even simple changes to report formats can be tedious and time-consuming.

[Admittedly, reports usually don’t need to be modified frequently. Even so, the editing software for report formats is at best unsophisticated. I was modifying a report recently and the good thing was that the editing software gave me the option to select from a large number of report elements, the bad thing was that the selection had to be made from a tiny pop-up menu that only showed 4 options out of over 40 at any one moment and I had to spend an inordinate amount of time scrolling back and forth to find what I was looking for.

In addition, although most of the report editors allow you to place elements wherever you want them they also haven’t seemed to have heard of the “snap to grid” function. I work with a variety of graphics programs and several of them allow you to place a grid over your work and then place new elements according to the grid. This makes it easy to line things up. Without a grid, you have to place elements very carefully by eye and hope that they line up.]

The need to create, maintain and select from a large number of report formats is mandated by the decision of our lab equipment manufacturers to use static report pages. I agree that there are situations where the ability to specify the exact location of every report element is advantageous. But for my lab this would apply to only a very small minority of our reports and a better approach would be to use dynamic report pages. We used to have dynamic reports with the DOS version of software we used 15 years ago (newer isn’t always better). Specifically, within the report editor you formatted the specific sections (demographics, spirometry, etc.) and then added them (or not) to the final report format. We actually had only one primary report format at that time, and it had all of the possible tests we performed. When the report was printed only the sections that had results were printed.

There are multiple advantages with a dynamic report format. First, although this doesn’t mean that multiple report formats won’t be needed the number of report formats is substantially reduced. Second, when a report is printed there will never be any blank sections. Third, changes to report sections only have to be made in one place.

So why doesn’t our lab software use dynamic report pages? I really don’t know and I can’t think of a good reason why not. It may be that the feedback our equipment manufacturers have gotten in the past told them that labs wanted static pages. It may be that it is easier to write the software for static report pages (although since DOS-era software was able to print dynamic pages I’m not sure why this would be the case). It may also be that once a decision to go with static report pages has been made, there aren’t sufficient resources to develop more than one type of report.

I’d really prefer to have dynamic report pages and I think that if most PFT labs considered the extra labor that goes into creating, maintaining and selecting static report pages they might well feel the same. Barring that, I’d like to see our lab software at least have the ability to select the most appropriate reports when its time to print one. I would also prefer the ability to format a report section (demographics, spirometry etc) just once, and then place it into a report format.

Finally (although I suspect that the lab equipment manufacturers would disagree) the report formatting and editing functions in our lab software have always seemed to be an afterthought. I agree that reports aren’t something that need constant attention, but even so I’d really prefer to see more sophistication and less tedium in the report editing software we have to work with.

Creative Commons License
PFT Blog by Richard Johnston is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License

2 thoughts on “Static reports, dynamic world

  1. Hi, Richard.

    I completely agree; some vendors appear to put minimal effort into reporting. Clear reporting is so important; we work so hard to perform pulmonary measurements correctly, and then we make recipients of the data search around blank headers for what was done. In 2015, it is absolutely possible for pulmonary reports to be “smart”, i.e., only the headers for which measurements were performed are printed.

    Selecting a vendor for pulmonary equipment is almost always a compromise. Some have great hardware paired with archaic software, while some have good software but can’t reliably measure flow. At one time, I had a vendor that required 47 different report formats… never again. Dynamic report formatting is an essential feature for any system I purchase.

    Thanks for the great site!

  2. Thank you for this well presented article. I would agree with Mr. Johnson, that there is a challenge in the reporting of PFT results for transgender patients. There are not many medical testing scenarios where gender drives predicted equaltions, to such a degree with resulting clinically significant differences. It is imperative to discuss the topics with PFT staff, to educate and to ensure sensitive communications with our transgender patients.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.