Why DIY CPET reports?

When I first started performing CPETs in the 1970’s a patient’s exhaled gas was collected at intervals during the test in Douglas bags and I had a worksheet that I’d use to record the patient’s respiratory rate, heart rate and SaO2. After the test was over I’d analyze the gas concentrations with a mass spectrometer and the gas volumes with a 300 liter Tissot spirometer and then use the results from these to hand calculate VO2, VCO2, Rq, tidal volume and minute volume. These results were then passed on to the lab’s medical director who’d use them when dictating a report.

Around 1990 the PFT lab I was in at the time acquired a metabolic cart for CPET testing. This both decreased the amount of work I had to do to perform a CPET and significantly increased the amount of information we got from a test. The reporting software that came with the metabolic cart however, was very simplistic and neither the lab’s medical director or I felt it met our needs so I created a word processing template, manually transcribed the results from the CPET system printouts and used it to report results.

Twenty five years and 3 metabolic carts later I’m still using a word processing template to report CPET results.

Why?

Well, first the reporting software is still simplistic and using it we still can’t get a report that we think meets our needs (and it’s also not easy to create and modify reports which is a chronic complaint I have about all PFT lab software I’ve ever worked with). Second, there are some values that we think are important that the CPET system’s reporting software does not calculate and there is no easy way to get it on a report as part of the tabular results. Finally, and most importantly, I need to check the results for accuracy.

You’d think that after all these years that you wouldn’t need to check PFT and CPET reports for mathematical errors but unfortunately that’s not true. For example, these results are taken from a recent CPET:

Time: VO2 (LPM): VCO2 (LPM): Reported Rq: “Real” Rq:
Baseline: 0.296 0.220 0.74 0.74
00:30 0.302 0.214 0.77 0.71
01:00 0.363 0.277 0.77 0.76
01:30 0.395 0.306 0.78 0.77
02:00 0.424 0.353 0.99 0.83
02:30 0.459 0.403 0.92 0.88
03:00 0.675 0.594 0.89 0.88
03:30 0.618 0.584 0.94 0.94
04:00 0.836 0.822 1.00 0.98

Time: Ve(LPM): VO2 (LPM): Ve/VCO2: “Real” Ve/VO2:
Baseline: 11.7 0.296 39 40
00:30 9.5 0.302 33 31
01:00 10.8 0.363 30 30
01:30 11.7 0.395 30 30
02:00 13.0 0.424 38 31
02:30 14.2 0.459 33 31
03:00 20.4 0.675 31 30
03:30 19.4 0.618 31 31
04:00 26.6 0.836 33 32
Time: Ti: Te: Ti+Te: RR: “Real” RR:
Baseline: 2.49 3.01 5.50 11 11
00:30 2.95 3.75 6.70 11 9
01:00 1.33 2.66 3.99 15 15
01:30 1.19 2.29 3.48 18 17
02:00 1.15 1.67 2.82 23 21
02:30 1.14 1.79 2.93 20 20
03:00 1.09 1.64 2.73 23 22
03:30 0.96 1.56 2.52 24 24
04:00 0.85 1.25 2.10 31 29

To be honest, the discrepancies between the results reported by the CPET system software and the re-calculated results are often minor and are possibly explained by hidden digits and rounding errors.

The hidden digit problem occurs when the results are stored with more numbers after the decimal point than are reported. For example, a VO2 value could be reported as 0.296 but could instead be stored as 0.296893. In this case, the software truncated the stored value when reporting it rather than rounding it up to 0.297. When the calculations are performed, they are performed on the entire number rather than the truncated number. Depending on whether the results from these calculations are rounded or truncated there can be a discrepancy when compared to the calculations performed on the reported values.

But this only explains some of the discrepancies. In particular, please note the Rq and Ve/VO2 values at the 2 minute mark. The Rq is reported as 0.99 but calculates from the reported VO2 and VCO2 as 0.83. The Ve/VO2 is reported as 38 but calculates from the reported VO2 and Ve as 31. Unless there is a bug in the software (not impossible) this is probably due to the algorithm that’s used to average results over the 30 second period.

Specifically, over any given time period (20 seconds, 30 seconds, 60 seconds) there usually isn’t an evenly matched number of inspirations and expirations. Ideally a time period would start and end at end-exhalation but since timing is arbitrary it could just as easily start mid-exhalation or mid-inspiration, and the same applies to the end of the timing period. A software algorithm that averages results therefore has to be able to extract and extrapolate data from partial breaths and I don’t know what solution the software engineers have applied to this problem.

In this case the averaging algorithm could have accumulated the calculated Rq and Ve/VO2 from each breath and then averaged them rather than calculating the Rq and Ve/VO2 from the averaged VO2, VCO2 and Ve. But this leads to another conundrum and that is how are the VO2, VCO2 and Ve averaged and are they any more (or any less) accurate than calculated values like the Rq, Ve/VO2 etc?

One point in favor of saying that VO2, VCO2 and Ve are at least somewhat more accurate is that the calculated Rq and Ve/VO2 at the 2 minute mark are outliers and don’t fit with the flow of data. You usually don’t expect that Rq or Ve/VO2 to suddenly change and then revert in the middle of a CPET. It’s not impossible, of course, but you’d also expect corresponding changes in VO2, VCO2 and Ve. This leads me to suspect that the problem lies primarily with the averaging algorithm for calculated values.

None of the companies that manufacture metabolic carts have ever published the algorithms they use to average results, however. These companies often compare their results to those obtained from the “gold standard” (such as it is) of Douglas bags, Tissot spirometers and stand-alone gas analyzers. Even this has its problems however, since the exhaled air collected in Douglas bags are almost always collected from a number of complete exhalations that occur over a period of time that is usually either less or more than that used by a metabolic cart. When this happens, the Douglas bag results that, for example, come from a 28 second or 35 second period need to be extrapolated in order to match a 30 second period from a metabolic cart.

The problems with both rounding and averaging errors is that I use these tabular results both to determine the anaerobic threshold and to calculate the Ve-VO2 and Ve-VCO2 slopes. At the moment I have to assume that the core values such as VO2 and Ve are reasonably correct (particularly since I have no way to verify them) and that derived calculations such as Rq and Ve/VO2 need to be checked and when necessary, re-calculated. Since there is no easy way to download CPET results from our CPET system in a format that can be inserted into a spreadsheet this means I do a lot of manual transcribing (so it’s a good thing that I type fast).

Most labs that I know that are performing CPETs use the reporting software that comes along with their metabolic cart. Aesthetics aside, this can be a problem since some values that I consider critical to interpreting a CPET are often not included. More problematic is that most labs also accept that all of the reported values are accurate and this unfortunately isn’t necessarily true (and I’m not even talking about things like determining the anaerobic threshold). To some extent this is routinely excused or overlooked since cardiopulmonary exercise testing is considered to be an order of magnitude more complicated than regular PFT testing but really, it’s not rocket science. You should never assume that the math on a CPET (or PFT) report is correct until you verify it and all I needed to verify these errors was a pocket calculator.

It would be helpful if the companies that manufacture CPET systems were more forthcoming about their averaging (and other) algorithms but realistically, even with the Douglas bag approach there are inherent limitations to accuracy. The best we can do is to be aware of the more obvious errors and to find work-arounds for them.

And yes, creating a CPET report from scratch takes more time and effort than using a canned report but like baking and cooking from scratch, I think the results are worth it.

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

5 thoughts on “Why DIY CPET reports?

  1. I’m curious what different CPET equipment you use, and what you’ve used in the past. 25 years ago there were several more options then there are now.

    I have pretty much the same background as you, and have been in the field just as long, since ’69. Curiously, you’ve never answered one of my responses or questions.

    Anyway, CPET was my main interest, and I had a role in developing the VMAX system, the ZAN, and the Cortex portable system. I agree with much you’ve said in this post, and yes, the calculations can vary on what is used, a ’rounded’ or ‘raw’ number, and not necessarily in a consistent fashion.

    I retired 6 years ago, and have lost touch with most of my former colleagues, who by now have also retired. Bob Jensen and I did some work on a CPET report for his lab in SLC you might find interesting.

    Cheers,
    Mike Mulligan

    • Mike –

      Our original system was from Collins, I don’t remember if it had a model number. Last two were/are Vmax systems from Sensormedics/Carefusion. Our newest CPET is 12 years newer than the one it replaced and I can’t see any difference in the software. Since you helped develop the Vmax and other systems maybe you can comment on the averaging algorithms.

      BTW, I’m not sure where you’re looking or not looking since I’ve responded to all of your comments (this is your fourth one, I believe) and they’re all on the website.

      Regards, Richard

  2. apologies, I’ve never seen them. mea culpa.
    I’ll go through my old files in the ‘spare’ room here. I live in SW Montana, around 6K feet, and I find my exercise capacity is vastly reduced. I’m trying to remember the guy I worked with at then Sensormedics. Vaughn somebody, sorry. Time takes it’s toll.

    I will look tomorrow for what I have, I guarantee it won’t be digital, so I’ll have to have it scanned. That’s no problem, I’ll let you know what I find.

  3. Hi, Mike, always good to see your name pop up. I believe you’re referring to Vahan Mashikian, MBS, BSEE. He was an engineer at SensorMedics and worked on their CPX systems.

  4. Jim
    Hey there! How many years has it been, 10 at least. You still in NYC? I’m in my sixth year of retirement, been travelling some, Europe for much of last year.

    My girls are grown, got two grandkids now, I’m still able to deal with Montana winters.

    Hows life with you?

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.