2026 Physiology Logbook

What I actually track when recording physiological data

Most people treat physiology logbooks as a checklist. They grab a template, fill in the blanks, and move on to the next lab session. That approach works until you need to cross-reference a week of heart rate variability against a specific medication change, and your data is scattered across three different formats. I learned that the hard way during a 2026 research project where I needed to correlate sleep architecture with cortisol levels across forty-two subjects. The difference between a functional log and a useless spreadsheet usually comes down to one thing: the units and timestamps you agree on before you start collecting anything. Not the aesthetic. The timestamps.

Here is the basic structure I use. Every entry gets a session ID, a universal timestamp (ISO 8601, no exceptions), the subject identifier, and then the actual measurements. Keep it simple. You can always add columns later. Removing them is much harder. I keep mine in a flat CSV format with strict headers. The file starts with session_id, timestamp_utc, subject_code, measurement_type, value, unit, method, notes. Nothing more in the header row. All measurements go in one table rather than spreading them across sheets for heart rate, temperature, and respiratory rate. It sounds wrong at first, but pivot tables handle single-source data infinitely better than multi-sheet gymnastics. The measurement_type column is where most people waste time. Do not create separate rows for systolic and diastolic blood pressure. Use one row per reading with a method qualifier like "BP_systolic" and "BP_diastolic" as values in the same column. Your analysis script can filter by string prefix. Humans can scan the raw data without jumping between tabs.

Timestamps need to be in UTC. I used to convert everything to local time and then regret it when subjects traveled across zones during a longitudinal study. Converting back later introduces errors that do not surface until peer review asks you to validate a specific data point at a specific hour. Just store UTC. Display in local time when you actually look at the data. Method matters more than people admit. A heart rate measured by photoplethysmography on a wrist sensor reads differently than one from a chest-strap ECG. Not enough to change the number dramatically, but enough to invalidate meta-analysis when you combine datasets from different equipment. Put the device model in the notes column. Yes, it takes longer. No, you will not thank yourself later.

Common mistakes that silently corrupt your data

Unit inconsistency is the quiet killer. One day you record temperature in Celsius. Three weeks later a different lab person enters it in Fahrenheit because that is what their default app showed. The numbers look reasonable. They are not. I caught this once when a subject's "normal" 37.2 reading suddenly spiked to 99.0 across three consecutive sessions. The statistical outlier filter flagged it immediately, but the outlier turned out to be a unit error, not a physiological anomaly. That costs time to trace back. Empty cells are another problem. Some people leave temperature blank when it is not measured. Others put "N/A" or "-" or "0". In a CSV, blank means missing data. "-" means you recorded a dash. "0" means zero degrees, which is either dead wrong or an actual hypothermia event worth investigating. Standardize on truly empty cells for missing data. If you need to distinguish "not measured" from "measured and normal," add a binary column like temp_measured with values 0 or 1. Session IDs should be sequential and unguessable. Not for security reasons. For referential integrity. When you are joining this log with another dataset six months later, having "session_001" through "session_047" lets you verify the count matches without scanning every row. UUIDs look fancy. They make manual debugging nearly impossible when you are three sheets deep in an error log at 11 PM.

What happens when things go wrong

I encountered a specific edge case last spring that took me two days to resolve. A subject's galvanic skin response values were consistently negative. The sensor was a Biopac GSR100C, known to output microsiemens as signed integers. My export script assumed unsigned. The values were correct. They were just being interpreted as negative numbers because the most significant bit was set on readings above 127 µS. I had approximately thirty-two thousand rows to recalculate. The fix was adding a conditional column in the import script: if value > 127, subtract 256. That brought everything into the correct positive range. I learned from that experience to always check the sensor datasheet for signedness before writing any export logic. Also, I now run a validation pass on the first five minutes of imported data before processing the full file. Catches issues like this in seconds instead of hours. Another thing I deal with regularly: datetime mismatches between devices. An Empatica E4 and a Polar H10 often drift by a few seconds because they maintain independent clocks. If you are syncing heart rate with skin conductance for a stress reactivity study, that drift compounds. I resolve it by recording a synchronized start pulse. Both devices get a visible flash or audible tone at the same moment, and I use that as the alignment anchor in post-processing. Takes four seconds. Saves hours of manual calibration.

Practical workflow that actually sticks

Set up your log template before you collect a single data point. I know this sounds obvious, but I have seen people start recording, realize they forgot a column, and then either discard data or retroactively fabricate entries. Neither is acceptable. The template should include every measurement you think you might need plus three columns you think you do not. You will need them. Use validation rules at the point of entry if possible. If your logger is a human filling a form, constrain units to a dropdown. Constrain timestamps to only accept future-dated entries within a reasonable window. Constrain physiological ranges to exclude impossible values. A heart rate of 300 beats per minute is either a measurement error or a medical emergency. Your log should flag it immediately, not three months later when you are building figures for a publication. Back up your raw data before any transformation. I keep the original export from each device in a separate folder with an immutable timestamp in the filename. Everything I do after that—unit conversion, alignment, filtering—goes into derived folders. If I ever need to prove I did not manipulate the raw signal, the original files are there. This matters more in physiology than in most fields because reviewers increasingly ask for raw data access.

Document every deviation from the protocol. If a subject missed a session, if a sensor failed mid-recording, if you had to switch equipment because the original broke, write it down. Not in a separate document. In the log itself, in the notes column. Cross-referencing clean data that was collected under messy conditions creates hidden confounds. The notes column is your insurance against that.

When a logbook is not the right tool

Flat CSV logs work well for structured, repetitive measurements with a fixed set of variables. They break down quickly when you need free-form observations, image data, or signals that require proprietary preprocessing. I have moved high-density time-series data to HDF5 files with metadata stored alongside the measurements. The CSV becomes a summary index rather than the primary storage. That combination handles both human readability and machine efficiency without requiring you to maintain two completely separate systems. If you are doing continuous monitoring over weeks or months with multiple subjects, the logbook approach generates more administrative overhead than actual science. At that scale, a proper database with constraints and audit trails becomes necessary. Not because CSV is bad. Because the failure modes of flat files become probability statements rather than possibilities when you reach a certain volume. The 2026 Physiology Logbook I am describing here works for typical lab and field studies with fewer than fifty subjects and measurement frequencies up to hourly sampling. It will hold up through graduate thesis work. After that, you will likely outgrow it. That is normal. The discipline of good logging practices transfers regardless of the tool.