Standard Curves (for 'Master Curves')

Development
,
1

Building off the conversation started by @NHizon this morning, I want to try to describe the issue with standard curves, one of the proposed solutions, and where there may still be some gaps.

Given the volume of samples that the PHAC-NML receives regularly, it is not really feasible to run a standard curve for each sample. So, instead, the lab runs a standard curve per batch of samples, using the same concentrations of reagents, etc. to try and control for differences that way

The ODM has capacity to record standard curve information in the form of measures, and all of the information about a single point on the curve could also be recorded as a measureSet. This way, too, we retain the crucial information about the sampleID, and the values for the curve. It’s not immediately clear, however, how we might like this information back then to other samples that also reference this curve. Adding a measureSet into the protocolSteps table would cause cycling, and would also corrupt the structure of that table somewhat. What was suggested is that the associated samples and standard curve information could be matched using the sampleRelationships table instead. With sampleRelationships providing a query-able framework for affiliated samples and standard curve aliquots, and measureSets providing the grouping for the measures on each point of the curve itself.

I think this would do the trick, but I worry that it’s a bit of a convoluted solution. In my ideal world, we would be able to have something like a protocolID that we could reference to link all the samples processed with a given curve. But, as @jeandavidt and Steven point out, the current protocols table (and its affiliates) are designed for wet lab protocols, not really calculation/data analysis protocols. @jeandavidt even went on to suggest that what we really need is a “calculation protocol” table. This is something we’ve discussed before but said we would push back to later releases (v3+) of the ODM (for talking about how 7-day moving average, of active cases were calculated).

After some thought, I think that the mixed-sampleRealtionships-measureSets approach to standard curves is sufficient right now (provided this works for you on your end, @NHizon !!) though perhaps this puts on some additional pressure for fleshing out and imagining what a “calculation protocols” table might look like, and how soon version 3 might need to be made.

Please add anything I’ve missed, or any additional thoughts folks have.

2

Not sure I fully understood the intricacies of determining the standard curve, but why this wouldn’t work?

  • 1 sampleID for the sample/subsample
  • 1 protocolID for the standard curve, named, say, “Standard curve / Lab name / Equipment / Date”
  • N measureIDs for all the measurements used in deriving the standard curve, using the sampleID and protocolID from above and the index field to iterate through the measurements of the same type
  • 1 measureSetRepID to group all the N measureIDs from above, using the same protocolID as above

Am I missing something?

3

@matthomson I think this captures our discussion well. Though I’m not sure a completely new table is needed for calculation protocols, I do think that they are substantially different from wet lab protocols.

  • In wet lab protocols, when we refer to a measure, we use it prescriptively (e.g., set the temperature of the oven to 50°C). The actual temperature measurement doesn’t necessarily happen in real life and is not necessarily recorded in measureReport table.
  • In calculations protocols, we make references to other actual measurements and prescribe mathematical operations on them (e.g., apply a seven-day window and produce an average, or take this measurement (some Ct with a measureReportID) and plot it onto this other measurement (the measureReportSetID of the standard curve) to obtain a concentration (which can also be stored in the MeasureReport table).

@Sorin One of the complexities of building the standard curve is that technically, each point is made from a different subsample (a dilution of the main standard sample). So for each point, you need two things: the concentration and (at least one) Ct value. In the current approach. In the setup you describe, there is no explicit way to associate a Ct with its dilution level.

My proposal would look like this:

  • 1 sampleID for the sample
  • 1 sampleID for each dilution of the main standard solution
  • (optional) n SampleRelationships to link the dilutions to the main standard solution
  • 1 protocolID for the standard curve, named, say, “Standard curve / Lab name / Equipment / Date”
  • n measureSetIDs (with (at least) two measure reports in them: one (or more if there are replicates) Cts, and one dilution level) for each point used in deriving the standard curve. Each use the sampleID of their subsample, but they all share the same protocolID.
  • 1 ‘main’ measureSetReportID to group all the N measureSetReportIDs from above, using the same protocolID as above
  • measureReports that use the standard curve as opposed to constructing it also have the sample protocolID, but we know they’re not part of the standard curve because their associated sample type is not “lab reference material”, it’s “raw wastewater” or whatever.

It’s basically the same as yours, but with sub-standard samples and measuresets for each of the subsamples

Does that capture everything we need to capture?