HFCT is the acronym I’m using for a high-frequency cholesterol testing study I’m conducting on myself (along with a group of QS-ers conducting similar studies) in the fall of 2017. This is my 3rd blog post about it. Start back at the first to catch up.
In my last post, I already mentioned most of the equipment I’ll be using for blood testing, but I haven’t yet covered the totality of my “experiment stack” or protocols.
The protocols for the actual blood testing—that is, the actual interfacing with the devices—aren’t that interesting, I don’t think. For ketone testing, I’m trying to be a bit more rigorous than I usually am and actually wipe away the first drop of blood, a recommended practice with all capillary-sourced blood testing, don’t ask me why.
The CardioChek Plus itself is a pretty finicky machine, sensitive to temperature, humidity, and lighting conditions (because it’s reflectance based). It also requires 40μL of blood, considerably more than a typical blood glucose or ketone fingerstick test, and the blood has to be collected in a capillary tube and then squeezed out into a little window on each lipid panel test strip.
Perhaps I’ll dedicate an entire post to a walk-through of a CardioChek Plus test; in this post I’m more interested in describing the other aspects of my experimental protocols aside from the interactions with blood testing devices.
Data logging
For data logging outside of the passively collected sources of contextual data I’ll be including in my analysis, I’m using Google Forms. This is a popular strategy in the QS community. One way of thinking about it is a Google Form is a little custom UI for data logging accessible from any computer or smart phone. And it’s a custom UI that you can put together in a matter of minutes. I’ve saved all my Forms on the home screen of my iPhone and stuck them in a folder. I’ve also opened each of them in a tab in my mobile Safari. Every time I log something, I immediately click on the post-form submission “Submit another response” link to prepare the form for the next time I need it. I’ve made five forms total for this project:
- lipids (for recording all the outputs from the CardioChek Plus)
- food intake
- blood ketones
- hydration
- medication
The food intake form includes fields for item, portion size, and units (including a radio selector for “natural unit” for things that have obvious units, like eggs). The hydration form is a very rough approximation; I’m only tracking this to catch potential outliers since dehydration can skew the results of pretty much any kind of a blood test. Medication I’m tracking for similar reasons: just to spot outliers that perhaps may turn out to relate to heavy anti-inflammatory use or similar.
Food logging (😡)
My food log doesn’t include tracking “macros”: calories, carbs, protein, or fat. That’s right, I’m not actually logging my carbs in this series of dietary protocols revolving around carbs! I hate tracking macros. It’s tedious, time-consuming, and I feel like it skews what I actually eat because I’m far too conscious of how things are totaling up for the day as I go.
Not tracking macros also has another benefit: I’ll have a rich source of food data at the conclusion of this project that reflects the food I actually had a desire to eat. As is recommended with very low carb eating, I’m trying to eat to satiety but not past it and not to restrict my diet out of fear of too many calories or too much fat ingested. It turns out this is really easy when you don’t know how many calories you’re ingesting in the first place!
In the third dietary phase of my experiment when I’ll be aiming for ~75 grams of carbohydrate at each of three meals in the day, I don’t expect to see my calories fluctuating as much due to appetite, but I have a feeling I’ll be seeing some interesting fluctuation during the prior two low carb segments. In general, I feel like my appetite is rather variable. One day I can be happy skipping breakfast, have a normal lunch (perhaps a hearty salad), and then just a protein bar before an evening ballet class and have no desire to eat anything afterwards before I go to bed. Other days I want to start my day with 🥓 and 🍳s and have three square meals. The older I get, the more I’ve been just letting this kind of variation happen and accepting it as part of my own body’s idiosyncrasies. Both eating when you’re not hungry and being hungry when you could eat1 seem like unnatural and potentially counterproductive states to maintain. I’d rather just listen to my body2.
At the level of the nitty gritty details of how I food log when I hate food logging… I moved my sticky note dispenser from my desk to my kitchen counter, along with a pen.
As I put together a meal (whether for immediate consumption or packing today’s or tomorrow’s lunch), I weigh everything and write it down.
If I’m consuming a dip or tapenade3, I simply weigh the whole container before I start eating, then weigh it again afterwards and log the difference as the amount consumed.
This food scale has for ages occupied a front-and-center place on my kitchen counter; it’s original purpose was weighing carbohydrate-containing things like fruit, starchy vegetables, pasta, bread, &c for greater accuracy in carb-counting and insulin dosing, but these days it mostly weighs coffee beans (and hence deserves that front-and-center place of honor). If the meal isn’t for immediate consumption, the sticky gets applied to the container, and then I can log the food items and weights when I actually consume them, which brings me to…
Date & time logging
Whenever a response is submitted via a Google Form, the precise timestamp of the form submission is recorded and available in the spreadsheet of responses. Given this, it might be tempting to exclude fields for date and time logging entirely when using Google Forms for self-tracking. In my experience, however, this is a mistake. Sometimes you forget to log something you ate or drank in the moment, but you remember a few minutes or hours later. For this reason, all of my Forms for this project include optional fields for Date and Time, and I only fill these out if the time of my logging does not match the time of the event itself.
The only exception to this is my forms for each CardioChek Plus lipid panel test and Abbott Precision Xtra blood ketone test: on these forms, Date and Time are required fields because I want to enter the time as it appears on the device for each, so that later if necessary I can compare records against each device’s memory with full fidelity.
Backup logging
In truth, I don’t even trust the device memories of the devices I’m working with. On the CardioChek Plus, for example, it’s quite easy to navigate to a menu option “Clear Memory” when trying to exit from the Utility menu that contains the “Check Strip” procedure recommended before every test. So as a backup method of data logging—inspired by testing protocols to verify diabetes device data download drivers in use at Tidepool—I’m using pictures as a backup data logging mechanism. Every CardioChek Plus lipid panel test and Precision Xtra blood ketone test gets a snap. I’ve got an album on my iPhone (which itself backs up to iCloud) that holds all the pics, and should I need to retrace my data steps, the pics are there, including the data values, the timestamp from the device (which could be wrong if I set it wrong), and the timestamp when the photo was taken, from the photo’s Exif data. A pretty solid backup, in other words.
(I also take pictures of Nutrition Facts labels of things I’m eating that aren’t simple foods I can look up in any nutrients database. Again, I’m not tracking the actual grams of carbohydrate or fat or total calories I’m consuming now, but rather just ensuring that I have enough information to be able to calculate those things at the conclusion of my experiment.)
🤔…That’s all that I can think of for now. Stayed tuned for the lessons I’ve learned so far from the first of my three experimental segments.
Next
The next post reports on my progress—and particulary on the challenges I faced—in the first two thirds of my HFCT experiment.