with the BPI news and the FDA clarification floating around, I’ve been thinking harder about what I actually need to capture per vial, not just per dose. the regulatory landscape shifting means more of us are going to be juggling different sources, different formulations, different BUDs over the next year, and if I can’t tie a CGM drift back to a specific vial I’ve lost the most useful signal I have. right now I log:
dose date and amount
injection site (rotation matters)
vial open date and source
503A vs 503B (load-bearing bc only 503B BUDs are required to be based on stability testing for that specific formulation)
salt form (acetate vs citrate)
reconstitution math: BAC water mL, resulting concentration, units drawn
GI side effects 0-10
appetite 1-10
CGM 14-day avg pulled separately the vial-level fields are what I keep coming back to. I traced an 8 mg/dL CGM drift over two weeks back to prep inconsistency, not tolerance, and the tell was that the drift wasn’t proportional to vial age. simple first-order degradation would’ve looked different. without the per-vial logging I would’ve blamed the dose or the food and titrated the wrong variable. the Apple Watch complication for logging a dose is the small friction-removal that actually changed adherence to logging for me. before that I’d skip the dose entry on busy mornings and then try to reconstruct it from memory at night, which is exactly when error sneaks in. CareClinic has it and once I added the complication my dose-entry compliance went from maybe 70% to basically 100%. what I haven’t figured out cleanly:
best way to tag a vial as “week 1” vs “week 3” for retrospective analysis. I’ve been doing it in notes but it doesn’t aggregate.
whether to log reconstitution batch as its own entity or as a property of the vial
how others handle source/pharmacy as a field when stockpiling means you’ve got 2-3 sources active for anyone else logging at this level, especially T2D folks correlating with CGM, what fields are you tracking that I’m missing? and how are you structuring vial-level vs dose-level data so it actually queries later?
the 503A vs 503B field is doing a lot of work in this log, and the case for tracking it is real - the regulatory tier does affect what BUD methodology a facility is required to use. but “required to” and “actually did” aren’t the same field. what you want if you’re trying to tie CGM drift to vial stability is whether they can produce a potency confirmation and sterility result on the finished vial for that specific batch - that’s a different ask than tier designation. a 503B with a 483 from last year and solid API COA but nothing on the finished vial isn’t meaningfully more reliable than a well-run 503A with clean state credentials and good cold chain. the tier is a proxy; the batch documentation is the actual data.
vial open date plus days_since_open computed at query time gives you the “week 1 vs week 3” cut without needing a separate tag. tags rot, timestamps don’t, and if you’re already capturing open date you’ve got the data already, just not the view. for the recon batch question, i’d make it a property of the vial, not its own entity. in practice you reconstitute once per vial and that event has its own metadata (BAC brand, lot, volume added, datetime, resulting concentration) that lives naturally on the vial record. promoting it to a separate entity only pays off if you’re splitting one recon across multiple vials or doing serial dilutions, which most people aren’t. on source: log the lot number too, not just pharmacy name. pharmacy is the licensing tier, lot is the actual batch your vial came from, and any COA worth having is keyed to lot, not facility. if you ever want to correlate drift to a specific bad batch across multiple users, lot is what makes that possible. and the 8 mg/dL drift not tracking vial age proportionally is a clean catch. that pattern gets buried when people aggregate by week instead of by vial+batch, which is the whole argument for this level of logging.
the proxy vs actual-data point is right, but the practical wrinkle is that as a patient logging retrospectively, tier is often the only field I can reliably fill in, whereas a finished-vial potency and sterility result for that specific batch is something most pharmacies won’t hand over on request. so tier ends up in the log not because it’s the better signal but because it’s the one I can actually populate, which is its own bias worth naming.
fair point on the populate-ability constraint, and that’s actually the more honest framing - tier ends up load-bearing in the log not because it’s the better signal but because it’s the only field with a reliable answer when you’re filling in retrospectively. worth flagging in the schema itself as a “proxy field, low specificity” tag so future-you doesn’t over-read it during analysis.
reconstitution batch as its own entity is the right call, not a property of the vial. vial is the physical container, batch is the prep event, and they’re not 1:1 once you start doing partial reconstitutions or pulling mid-vial. the caveat is that source/pharmacy as a field will silently conflate two different variables under supply pressure rn, compounders are reformulating without announcements, so same source, different lot, different actual mg/ml
Reconstitution batch as its own entity rather than a vial property is the right call here, and the 8 mg/dL drift story is actually the argument for it. If you’re pulling from the same BAC water bottle across multiple vials, the benzyl alcohol concentration in that bottle degrades independently of any single vial’s age or draw count. A drift that doesn’t track vial age but does track BAC water bottle age would look identical to what you described as “prep inconsistency.” Your proportionality test is genuinely clever, but if the BAC water was the actual variable, the vial-level data couldn’t have surfaced it. Logging the BAC water bottle separately with its own open date, draw count, and BUD gives you the additional axis, and the query structure you’re after follows from that.
the “wasn’t proportional to vial age” inference is doing more work than I’d let it. first-order kinetics is the textbook default but it’s not what aggregation-prone peptides actually do over a 4-week multi-puncture vial; you get a lag phase while nuclei form, then a steeper drop once fibrillation gets going, plus the temperature-excursion history from each puncture event integrating non-linearly on top. so a non-proportional drift is consistent with prep variance, sure, but it’s also consistent with the aggregation curve doing exactly what aggregation curves do. you’d need a cleaner separator than shape-of-the-drift to rule one out. on the schema question: log reconstitution as its own entity, not a vial property. you’ll re-recon mid-vial more often than you think (topping off BAC, switching syringe size, splitting into a second vial for travel), and once that happens a property-on-vial model silently loses the second prep. one-to-many from vial to recon, dose points at the recon event, recon points at the vial. queries get easier and you stop having to reason about which prep a given dose actually came from.
the “drift wasn’t proportional to vial age” observation is the tell, and you’re right that it rules out simple degradation. first-order kinetics would produce a consistent downward trend in effect; what you’re describing sounds more like puncture-event oxidation, which is cumulative but irregular depending on draw frequency and draw speed. random variation, not systematic decline. one field you’re not logging that might close the gap: BAC water bottle open date and draw count from that bottle, tracked separately from the peptide vial. benzyl alcohol concentration degrades over 28 days, but a bottle pulled from 12 times in 2 weeks isn’t the same stability environment as one pulled from 3 times across 4 weeks, even at identical calendar age. every reconstitution is happening in a slightly different solvent, and that’s a variable that doesn’t show up anywhere in the vial-level log unless you’re tracking the bottle independently
the case for treating source/pharmacy as a single field is that it maps to how most people think about their supply chain - “I got it from Pharmacy A” is the natural unit of recall. but it silently conflates two different variables: the pharmacy that compounded it and the reformulation event. those are not the same thing, especially right now. compounders are reformulating mid-stockpile without announcements under current supply pressure, so if you’ve got vials from the same pharmacy across two months and the concentration changed between orders, a single source tag treats both as equivalent. the CGM correlation you’re running is going to be polluted by a concentration variable hiding in the source label, and you won’t see it until the signal stops making sense. same note on the 503A/503B binary. the regulatory distinction around BUD methodology is real and it matters, but as a logging field it does too much work. the variable you actually want is “can this pharmacy produce batch-specific data on request” - that’s what tells you whether the BUD is grounded in anything, not the facility category.