Chapter 8
How to prove that a biosensor and a WIA-BIO-011 implementation do what they claim: analytical validation studies, the glucose accuracy criteria of ISO 15197, the regulatory routes to market, the shape of conformance evidence, the errata a v1.0 implementer must handle, and where the field is heading.
Chapters 3 to 6 showed how to compute performance metrics, store them in WIA records, produce them with the SDK and keep them valid through calibration and quality control. None of that is yet proof. A regulator, a hospital laboratory or a buyer of a field monitor will ask a different question: how do you know? The answer is a validation file, a set of studies with defined designs, predefined acceptance criteria and traceable raw data, followed by a conformity assessment under the rules of the market where the device is sold. This chapter walks through that final stage.
Three kinds of source are involved, and the text keeps them apart. The first is WIA-BIO-011 itself. Spec §6–§7 sets targets and acceptance criteria, §9 lists regulations and guidelines, and the reference SDK offers validateSensor. The second is external standards and guidelines (CLSI, ISO, and the FDA and EU frameworks). The book describes them from their published scope and cites them by their real numbers, but the current edition of each document remains the authority. The third is the non-normative annexes of the PHASE documents, which suggest how conformance evidence could be packaged. The chapter uses them only as a recommended shape, and labels book commentary as such.
A metric such as CV or LOD is a number. A validation study is the experiment that produces that number under conditions that make it credible. The difference lies in the design: how many days, runs, reagent or electrode lots, operators and instruments are included, which sample matrix is used, and which acceptance limit was fixed before the data were seen. The Clinical and Laboratory Standards Institute (CLSI) publishes the evaluation protocols (EP documents) that clinical laboratories and IVD manufacturers most often use for this purpose. Spec §9.2.3 names five of them: EP05, EP06, EP07, EP09 and EP15. The book adds a sixth, EP17, because the standard reports LOD and LOQ but names no guideline for establishing them.
The table below turns these guidelines into a WIA-BIO-011 validation plan. The design column shows example designs of the kind the guidelines describe. Before using any of them in a regulatory file, check the current edition. The acceptance column quotes the spec value where one exists, and the last column states where the result lands in the WIA data model or why it cannot land there.
| Study | Guideline | Example design | Acceptance (source) | WIA/SDK field |
|---|---|---|---|---|
| Precision | CLSI EP05 | 2–3 levels; 20 days × 2 runs × 2 replicates | CV < 5 % (spec §6.8); RSD < 5 % per calibration level, n ≥ 3 (§7.2.2) | validateSensor → precision.cv; PerformanceMetrics.precision |
| Linearity | CLSI EP06 | 5–9 levels from admixed pools, 2–3 replicates each | R² > 0.99, target 0.995; random residuals (§7.2.1) | validateSensor → linearity.rSquared; residuals from CalibrationData.qualityControl |
| Trueness / recovery | CLSI EP15 (trueness part); spike recovery | Spikes at low, mid, high levels in the real matrix | Recovery 90–110 % (§7.2.3); relative error ±5 % (§6.7) | validateSensor → accuracy.recovery (mean only) |
| Interference / selectivity | CLSI EP07 | Paired samples with and without each interferent at a high physiological level | Kij > 100 (§6.5), as a ratio of sensitivities | validateSensor → selectivity.coefficients (raw signal ratio) |
| Method comparison | CLSI EP09 | Dozens to over a hundred samples across the interval, one comparative method | Allowable bias set by intended use; not defined in v1.0 | None; use BatchMeasurement plus an external analysis |
| Detection capability | CLSI EP17 (book addition) | Blank and low-level samples over several days and lots | LoD, LoQ claims; LOQ = 10σ/S (Ch3) | calculateLOD → LODResult; PerformanceMetrics.lod/loq |
| Stability | No CLSI EP named in the spec (real-time and accelerated studies) | Stored units tested at fixed intervals; operational use to end of life | Shelf life 3–12 months at 2–8 °C; 100–1000 measurements; drift < 5 %/month (§6.9) | ValidationParameters.stability is accepted but never evaluated |
| Response time | No guideline named | Step change in concentration, signal logged at high rate | No normative limit (the CLI prints "≤ 60 s") | updatePerformanceMetrics(…, responseTime), caller-supplied |
Chapter 3 derived LOD = 3.3σ/S and LOQ = 10σ/S from a calibration. EP17 frames detection capability in terms of two error rates. The limit of blank is the highest result expected from a blank with a given probability. The limit of detection is the lowest concentration that yields a result above LoB with a given probability. With 5 % false positives and 5 % false negatives and roughly Gaussian data, the parametric form is:
LoB = mean(blank) + 1.645 × SD(blank)
LoD = LoB + 1.645 × SD(low-level sample)
Applying this to the Appendix A.1 blanks gives a useful cross-check. The blank SD is 0.0070 µA, and the recomputed slope from Appendix A.2 is about 1.1585 µA/mM, so the LoB lies 1.645 × 0.0070 / 1.1585 ≈ 0.0099 mM above the blank mean. Suppose, as an example, that a low glucose sample measured over several days has an SD of 0.009 µA. The LoD is then 0.0099 + 1.645 × 0.009 / 1.1585 ≈ 0.023 mM. This is close to the 0.020 mM that the 3.3σ/S rule gives, but it rests on a stated error model and on low-level samples rather than on blanks alone. EP17 also applies a small-sample correction to the multiplier and asks for data across lots, and both details are omitted here. The LoQ is then the lowest level whose total error or CV meets a goal set by the manufacturer. For a WIA record, store the LoD and LoQ claims in PerformanceMetrics and record the method in the validation report. The LODResult.method enum has no value for EP17, so do not force the result into 'iupac' or 'epa'.
A correlation coefficient is the wrong tool for method comparison. Two methods can correlate almost perfectly and still differ by a constant 10 %. Two analyses answer the right question. A Bland–Altman plot places the difference (or percentage difference) of each pair against the mean of the pair. It reports the mean bias d̄ and the 95 % limits of agreement d̄ ± 1.96 SDd. Whether those limits are acceptable is a clinical decision made before the study. Deming regression fits a line when both methods carry measurement error, which ordinary least squares ignores. Its slope and intercept separate proportional from constant bias. Passing–Bablok regression is a common non-parametric alternative when outliers or non-Gaussian errors are expected. None of this exists in the SDK. The practical route is to collect the pairs as MeasurementResult records inside a BatchMeasurement, export them, and analyse them with a validated statistics package whose version is recorded in the report.
Chapter 5 described the mechanics of validateSensor. From a validation point of view, four gaps matter. Accuracy is judged on the mean recovery, so individual spikes outside 90–110 % can hide behind a good average. Selectivity divides raw signals and ignores the concentrations it asks for. The stability block is never evaluated. And method comparison, interference dose–response and detection capability have no fields at all. A thin wrapper can close the first three gaps without changing the SDK. The helper below is book code, not part of @wia/bio-011.
import { BiosensorSDK, ValidationParameters } from '@wia/bio-011';
// Book helper: stricter checks layered on top of validateSensor.
interface StrictReport {
sdkValidated: boolean;
recoveryPerSample: { expected: number; recovery: number; passed: boolean }[];
selectivityNormalized: Record<string, number>;
stability?: { retentionPct: number; halfLifeDays: number; driftPctPerMonth: number };
validated: boolean;
}
export function strictValidate(
sdk: BiosensorSDK,
p: ValidationParameters,
targetConcentration: number, // concentration behind targetSignal
): StrictReport {
const base = sdk.validateSensor(p);
let ok = base.validated;
// 1. Every spike must recover within the range, not just the mean.
const [lo, hi] = p.accuracy?.requiredRecovery ?? [90, 110];
const recoveryPerSample = (p.accuracy?.spikedSamples ?? []).map(s => {
const recovery = (s.measuredConcentration / s.expectedConcentration) * 100;
return { expected: s.expectedConcentration, recovery, passed: recovery >= lo && recovery <= hi };
});
if (recoveryPerSample.some(r => !r.passed)) ok = false;
// 2. Selectivity as a ratio of sensitivities (signal per unit concentration).
const selectivityNormalized: Record<string, number> = {};
if (p.selectivity) {
const sTarget = p.selectivity.targetSignal / targetConcentration;
for (const i of p.selectivity.interferents) {
const k = sTarget / (i.signal / i.concentration);
selectivityNormalized[i.name] = k;
if (k < p.selectivity.requiredSelectivity) ok = false;
}
}
// 3. Stability: first-order decay fitted to ln(signal) versus time (hours).
let stability: StrictReport['stability'];
const m = p.stability?.measurements ?? [];
if (m.length >= 3) {
const t = m.map(x => x.time), y = m.map(x => Math.log(x.signal));
const mt = t.reduce((a, b) => a + b) / t.length, my = y.reduce((a, b) => a + b) / y.length;
const k = -t.reduce((s, ti, j) => s + (ti - mt) * (y[j] - my), 0) /
t.reduce((s, ti) => s + (ti - mt) ** 2, 0);
const retentionPct = (m[m.length - 1].signal / m[0].signal) * 100;
stability = {
retentionPct,
halfLifeDays: Math.LN2 / k / 24,
driftPctPerMonth: (1 - Math.exp(-k * 730)) * 100, // 730 h ≈ one month
};
if (retentionPct < p.stability!.requiredStability) ok = false;
}
return { sdkValidated: base.validated, recoveryPerSample, selectivityNormalized, stability, validated: ok };
}Fed with three example spikes (2 mM measured as 1.78, 10 mM as 10.2 and 20 mM as 21.9), the SDK reports a mean recovery of 100.2 % and passes. The wrapper shows that the 2 mM spike recovered only 89 % and fails the file. Fed with the Appendix A.3 interference data and a target concentration of 5 mM, the wrapper reports K ≈ 39 for fructose, ≈ 1.5 for ascorbate and ≈ 4.9 for urate, so all three fail the §6.5 target of 100, while the SDK's raw ratios (39, 73, 49) also fail but by misleading margins. An example four-week stability series (signal 100, 98.9, 97.6, 96.8 and 95.5 at weekly intervals) gives a retention of 95.5 %, a fitted half-life of about 430 days and a drift of about 4.8 % per month, which is just inside the §6.9 target of 5 %. These are illustrative data, and a real stability claim needs several lots and the full claimed period.
ISO 15197:2013 specifies requirements for blood-glucose monitoring systems intended for self-testing. It is the best-known example of an accuracy standard for a biosensor product, and spec §9.2.1 quotes its core system-accuracy criteria. At least 95 % of results must lie within ±15 mg/dL (±0.83 mmol/L) of the reference value when the reference is below 100 mg/dL (5.55 mmol/L). At or above that concentration they must lie within ±15 %. In addition, 99 % of results must fall within zones A and B of the Consensus Error Grid for type 1 diabetes. Spec §9.2.1 names the Clarke Error Grid here, which is an error. The 2013 edition uses the Consensus (Parkes) grid. The system-accuracy study uses capillary samples from at least 100 subjects spread over prescribed concentration bands, measured with three reagent lots in duplicate, for at least 600 results. The standard also contains a user-performance evaluation with lay users, and it covers interference, hematocrit and other influence quantities. The zone boundaries of the error grid are published coordinates. Implement them from the source publication rather than approximating them.
The twenty pairs below are illustrative only. A real study has at least 600 results, but the arithmetic is the same. For each pair, the rule switches at a reference value of 100 mg/dL: below it, the absolute difference is compared with 15 mg/dL, and at or above it the relative difference is compared with 15 %.
| # | Reference (mg/dL) | Meter (mg/dL) | Difference | Within limit? |
|---|---|---|---|---|
| 1 | 45 | 52 | +7 mg/dL | yes |
| 2 | 62 | 70 | +8 mg/dL | yes |
| 3 | 78 | 66 | −12 mg/dL | yes |
| 4 | 88 | 95 | +7 mg/dL | yes |
| 5 | 95 | 112 | +17 mg/dL | no |
| 6 | 99 | 90 | −9 mg/dL | yes |
| 7 | 104 | 112 | +7.7 % | yes |
| 8 | 120 | 131 | +9.2 % | yes |
| 9 | 135 | 128 | −5.2 % | yes |
| 10 | 150 | 163 | +8.7 % | yes |
| 11 | 168 | 160 | −4.8 % | yes |
| 12 | 185 | 198 | +7.0 % | yes |
| 13 | 210 | 236 | +12.4 % | yes |
| 14 | 240 | 229 | −4.6 % | yes |
| 15 | 270 | 301 | +11.5 % | yes |
| 16 | 300 | 284 | −5.3 % | yes |
| 17 | 340 | 322 | −5.3 % | yes |
| 18 | 380 | 402 | +5.8 % | yes |
| 19 | 420 | 445 | +6.0 % | yes |
| 20 | 480 | 455 | −5.2 % | yes |
Nineteen of twenty results (95 %) are within the limits, so this set meets the first criterion exactly at the boundary. If pair 13 had read 244 mg/dL (+16.2 %) instead of 236, only 18 of 20 (90 %) would remain and the set would fail. Two lessons follow. First, a small study can pass or fail on a single result, which is why the standard fixes a large minimum sample. Second, the ±15 % criterion is a statement about the tails of the error distribution, not about the average bias. The mean difference in this table is small, yet one result decides the outcome. The error-grid criterion is checked separately. Errors of this size lie close to the identity line and would be expected to fall in zone A, but the zone of each point must be assigned from the published grid coordinates. Unit handling matters too. WIA records store glucose in mM by default, and the conversion factor is about 18.0 mg/dL per mmol/L. Convert with the unrounded factor and keep the reference and meter values in the same unit before comparing.
// Book helper: ISO 15197:2013 system-accuracy criterion 1 (mg/dL inputs)
export function iso15197Within(ref: number, meter: number): boolean {
return ref < 100 ? Math.abs(meter - ref) <= 15
: Math.abs(meter - ref) / ref <= 0.15;
}
export function iso15197Criterion1(pairs: [number, number][]): { pct: number; passed: boolean } {
const ok = pairs.filter(([r, m]) => iso15197Within(r, m)).length;
const pct = (ok / pairs.length) * 100;
return { pct, passed: pct >= 95 };
}ISO 15197 applies to self-testing meters. Continuous glucose monitors are evaluated under different frameworks. In the United States, FDA has defined special controls for integrated CGM systems. Their performance is usually summarized by the mean absolute relative difference (MARD) and by the percentage of readings within fixed agreement bands, broken down by glucose range and by time since insertion. Spec §8.1 gives a CGM accuracy figure ("90 % within Zone A") without a source, and this book does not use it. Hospital point-of-care glucose meters, used on critically ill patients, are commonly evaluated against tighter criteria than self-testing meters. The general point for implementers is that the accuracy goal comes from the intended use and the applicable regulation, not from the biosensor standard.
WIA-BIO-011 is not a regulatory standard. Following it does not clear or certify a device anywhere. What it can do is organize the evidence that regulators ask for. This section outlines the two frameworks that spec §9 names, corrects the examples it gives, and lists the horizontal standards that every IVD manufacturer meets sooner or later. Other jurisdictions, such as Korea's Ministry of Food and Drug Safety (MFDS), run their own classification and approval schemes. They are not covered here, and they need their own review.
FDA classifies IVDs, like other medical devices, into Class I, II and III by risk and by the controls needed to assure safety and effectiveness. Class I devices are subject to general controls, and many are exempt from premarket notification. Class II devices usually need a 510(k) premarket notification that shows substantial equivalence to a legally marketed predicate device, together with any special controls for the device type. Class III devices need premarket approval (PMA), supported by valid scientific evidence that usually includes clinical data. A novel device with no predicate but moderate risk can use the De Novo request to create a new Class II classification. Spec §9.1.1 gets the examples wrong. Glucose test systems, including test strips and meters, are Class II, not Class I. Cardiac troponin assays are also regulated as Class II. "Novel cardiac marker equals Class III" is not a rule, because the class follows the device type and its risk, not its novelty. Point-of-care use raises one more US question. Under CLIA, each test is categorized as waived, moderate complexity or high complexity, and this decides which sites may run it. A CLIA waiver, for example for use in a physician's office or a pharmacy, requires its own evidence that untrained users obtain accurate results.
Regulation (EU) 2017/746 on in vitro diagnostic medical devices (IVDR) sorts devices into classes A to D with the classification rules of its Annex VIII. It also requires performance evaluation, meaning scientific validity, analytical performance and clinical performance. Spec §9.1.2 gives two examples that need correction. Devices for detecting HIV infection belong to Class D, the highest class, because the classification rules place tests for life-threatening transmissible agents with a high risk of propagation, and blood-screening tests, in Class D. They are not Class C. For blood grouping, only some markers are Class D, and others fall into Class C. Self-testing devices are Class C by default. A short list of exceptions, including pregnancy and fertility tests, is Class B. The EU classification guidance (MDCG 2020-16) places blood-glucose self-testing systems in Class C. Specimen receptacles and general laboratory instruments are the typical Class A examples. Except for non-sterile Class A devices, conformity assessment involves a notified body, and the depth of its review grows with the class.
| Example device | US FDA | EU IVDR | Notes |
|---|---|---|---|
| Blood-glucose meter and strips for self-testing | Class II, 510(k) | Class C (self-testing; per MDCG 2020-16) | ISO 15197 is the usual performance reference in both markets |
| Integrated CGM | Class II with special controls (iCGM) | Not an IVD: an in-vivo sensor, regulated under the Medical Devices Regulation (EU) 2017/745 | Accuracy is judged by MARD and agreement bands, not by ISO 15197 |
| Cardiac troponin assay (professional use) | Class II, 510(k) | Usually Class C under Rule 3, depending on intended purpose | Clinical cutoffs are assay-specific (99th percentile of a reference population) |
| Pregnancy self-test (hCG, lateral flow) | Class II (many OTC) | Class B (explicit self-test exception) | Reader apps can change the regulatory scope when they interpret results |
| HIV antigen/antibody test | Regulated by FDA's biologics centre; often PMA or BLA | Class D | Spec §9.1.2 wrongly lists "HIV = Class C" |
| Environmental or food biosensor (non-medical) | Not an IVD | Not an IVD | Method validation follows sector schemes such as AOAC or national environmental methods |
The table gives typical outcomes for orientation. The legal classification of a real product depends on its exact intended purpose and claims, and it has to be confirmed against the current regulation and guidance. It cannot be inferred from this book.
Whichever route applies, the same horizontal standards appear. ISO 13485 defines the quality management system: design controls, supplier control, process validation, traceability, and post-market surveillance, as spec §9.3.1 lists. ISO 14971 governs risk management across the life cycle. For a biosensor, typical hazards include a false low glucose result that leads to an insulin overdose, an expired strip read as valid, a wrong unit on an exported value, and an interferent that raises the signal. Many of the WIA quality flags are risk controls in this sense. calibration-expired, sensor-expired and temperature-out-of-range each mitigate a specific hazard, which is why Chapter 5's observation that some of them never block a result matters. Software that computes a clinical value, including an app that runs BiosensorSDK, falls under IEC 62304 for its life cycle and usually under IEC 62366-1 for usability engineering. The ISO 18113 series sets out what the manufacturer must tell the user: intended use, performance characteristics, sample type and volume, storage, expiry and quality-control procedures (spec §9.2.2). Here the WIA records help directly. PerformanceMetrics, Biosensor.lifetime and QualityControlSample already hold most of the numbers that the labelling has to state, so labelling and data can come from a single source. Spec §9.3.2 adds manufacturing practice: cleanroom classification (ISO 14644), equipment qualification (IQ, OQ and PQ), process validation, change control and CAPA.
Regulatory clearance concerns a device. WIA conformance concerns an implementation: a reader firmware, an SDK port, or a cloud service that claims to create, store and interpret WIA-BIO-011 records correctly. Version 1.0 defines no certification programme, no conformance tiers and no pass rates. Any claim of such a scheme would be invented. The PHASE documents, however, contain non-normative annexes (G, I and J) that describe a reasonable shape for conformance evidence. Their surrounding text is generic template material, as noted in earlier chapters, so the book adopts only the evidence shape and fills it with biosensor content.
Annex G asks for at least one positive and one negative test vector for each requirement, run in CI, with the pass/fail matrix published. The directory that the annex names does not exist in the biosensor repository, so an implementer has to write the vectors. The Appendix A data make good seeds, provided the recomputed values are used. The requirement identifiers below (BIO011-CAL-01 and so on) are a book convention, because v1.0 does not number its requirements.
[
{
"id": "BIO011-CAL-01-pos",
"requirement": "Calibration uses at least 5 points and R² > 0.99 (spec 7.1, 7.2.1)",
"input": {
"standardConcentrations": [0, 1, 5, 10, 50, 100],
"measuredSignals": [0.05, 1.20, 5.85, 11.50, 58.20, 115.80],
"concentrationUnit": "mM", "signalUnit": "uA"
},
"expect": { "accepted": true, "slope": { "value": 1.1585, "tol": 0.0005 },
"intercept": { "value": 0.047, "tol": 0.001 }, "rSquaredMin": 0.9999 }
},
{
"id": "BIO011-CAL-01-neg",
"requirement": "Calibration with fewer than 5 points is rejected",
"input": { "standardConcentrations": [0, 5, 10, 50],
"measuredSignals": [0.05, 5.85, 11.50, 58.20] },
"expect": { "accepted": false, "errorCode": "BIO010" }
},
{
"id": "BIO011-LOQ-01-pos",
"requirement": "LOQ = 10 sigma / S (as the SDK computes; corrects spec 6.3)",
"input": { "blankSignals": [0.05, 0.06, 0.05, 0.07, 0.05, 0.06, 0.05, 0.06, 0.05, 0.06],
"sensitivity": 1.1585 },
"expect": { "lod": { "value": 0.0199, "tol": 0.0005 }, "loq": { "value": 0.0604, "tol": 0.001 } }
}
]
Negative vectors matter as much as positive ones. Annex G states that a skipped test without a recorded reason counts as a failure, and that negative results must be reported as faithfully as positive ones. For a biosensor implementation, useful negative vectors include a measurement on an expired calibration (expect BIO004), a measurement on an uncalibrated sensor (BIO003), a QC result 25 % above target (expect a failed control and the recalibration action), and a 37 °C sample processed with the 25 °C reference (expect the temperature-out-of-range flag).
Annex G describes the evidence package as an archive with four items: a software bill of materials (CycloneDX or SPDX), the OpenAPI document if a remote API exists, the test-vector matrix, and a signed manifest. Signing with a transparency-logged scheme such as Sigstore lets a consumer verify where the package came from without a private certificate authority. The annex also suggests re-publishing the package every quarter even without source changes, so that drift in compilers, dependencies or operating systems shows up. For a biosensor product, the book suggests adding three items that the generic annex could not foresee: the calibration and QC data behind the reported performance, the exact SDK version and any local patches for the errata in Section 8.6, and the risk-control mapping from quality flags to hazards.
Annex I proposes a signed JSON profile manifest in which an implementation lists each requirement as supported, partial (with a reason) or excluded (with a justification). This is the honest way to describe partial conformance, which is the normal state for a v1.0 implementation. Annex J adds a deployment topology field (single-tenant edge, multi-tenant gateway, federated mesh or air-gapped batch), which Chapter 7 discussed for the device-to-cloud architecture. A minimal manifest for an app built on the reference SDK might read as follows.
{
"implementation": "example-glucose-reader-app",
"standard": "WIA-BIO-011",
"standardVersion": "1.0.0",
"sdk": { "package": "@wia/bio-011", "version": "1.0.0", "localPatches": ["temp-comp-direction", "loq-10-sigma"] },
"topology": "single-tenant-edge",
"requirements": [
{ "id": "BIO011-CAL-01", "status": "supported" },
{ "id": "BIO011-CAL-02", "status": "partial",
"reason": "Residual randomness checked by app code; SDK only reports residuals" },
{ "id": "BIO011-ACC-01", "status": "supported" },
{ "id": "BIO011-SEL-01", "status": "partial",
"reason": "Selectivity normalized by concentration in app; SDK ratio not used" },
{ "id": "BIO011-STB-01", "status": "excluded",
"justification": "Shelf-life claim established by manufacturer study, not by software" },
{ "id": "BIO011-NLC-01", "status": "excluded",
"justification": "Non-linear (4PL) inversion not implemented in v1.0 SDK" }
],
"evidence": { "vectorMatrix": "vectors/results.json", "sbom": "sbom.cdx.json" }
}The manifest makes no claim that anyone has certified it. It is a structured statement that others can check against the vectors. That modesty is deliberate. Until the standard defines a certification body and its criteria, "WIA-certified" is not a meaningful label, and it should not appear in product literature.
The table below collects the quantitative requirements of spec §6–§7 and states, for each one, how to test it with the SDK or CLI and what the tool cannot do on its own. The spec words §6 values as "targets" and §7 values as minimum requirements and acceptance criteria. It does not use formal MUST or SHOULD keywords, so the "Status in v1.0" column records the wording.
| Requirement | Spec | Status in v1.0 | Test with SDK / CLI | Gap to close |
|---|---|---|---|---|
| At least 5 calibration points including a blank, duplicates at each level | §7.1 | Minimum requirement | calibrateSensor throws BIO010 below 5 points | The SDK counts array entries, so duplicates count as points and the blank is not required. Check the design separately. |
| R² > 0.99 (target 0.995), random residuals | §7.2.1 | Acceptance criterion | calibrateSensor (BIO011 below 0.99); validateSensor.linearity | Residual pattern is not tested. Apply a runs test or EP06-style deviation limits. |
| RSD < 5 % per level, n ≥ 3 | §7.2.2 | Acceptance criterion | validateSensor.precision per level (one call each) | No per-level loop and no variance components. Use an EP05 design for claims. |
| Recovery 90–110 % | §7.2.3 | Acceptance criterion | validateSensor.accuracy; CLI validate --accuracy | The SDK uses the mean recovery. Check each spike (Section 8.1.5). |
| Accuracy ±5 % relative error | §6.7 | Target | Compare MeasurementResult.concentration with reference values | No SDK method. Method comparison (EP09) is external. |
| CV < 5 % | §6.8 | Target | validateSensor.precision; CLI validate --precision | The CLI only compares the number you type with 5. |
| Kij > 100 | §6.5 | Target | validateSensor.selectivity | Raw signal ratio. Normalize by concentration. |
| Three-level QC within ±10 % of target and ±2 SD of history | §7.4 | Acceptance criterion | runQualityControl with acceptableRange set to the intersection of both windows | The z-score does not affect passed. CLI qc-report prints fixed demonstration values. |
| Recalibration: before first use, daily, QC every 20–50 samples, weekly or on QC failure | §7.3 | Procedure | SDK calibration validity is 24 h (BIO004 afterwards) | Sample-count QC trigger and weekly full recalibration must be scheduled by the application. |
| Shelf life 3–12 months at 2–8 °C; 100–1000 measurements; drift < 5 %/month | §6.9 | Target | Biosensor.lifetime expiry (BIO007) | maxMeasurements not enforced; stability not evaluated. |
| Temperature control ±1 °C for enzymatic sensors | README QA | Guidance | temperature-out-of-range flag | Flag is advisory. Decide whether it blocks release. |
Two warnings apply to the CLI in particular. The validate command prints an R² of 0.9995 and a response time of 15 s that are hard-coded, and qc-report prints three fixed control results. Both commands are demonstrations of the output format. Their output must never go into a validation file as measured evidence.
Earlier chapters pointed out each of these issues where it arose. They are collected here because an implementer or an auditor needs one list. The proposed fixes are book commentary. They are what this book recommends until a revised specification settles each point.
| Item | Where | What v1.0 says or does | Why it is wrong | Proposed fix (book commentary) |
|---|---|---|---|---|
| LOQ relation | Spec §6.3 | LOQ = 3.3 × LOD | With LOD = 3.3σ/S and LOQ = 10σ/S, the ratio is 10/3.3 ≈ 3.03 | State LOQ = 10σ/S; drop the multiplier form |
| QCM constant | Spec §4.3.1 | 2.26 × 10⁸ Hz·cm²/g for 5 MHz | That is the 10 MHz value; Sauerbrey scales with f₀² | 5.66 × 10⁷ Hz·cm²/g (56.6 Hz·cm²/µg) at 5 MHz |
| SPR relation | Spec §4.2.3 | Δθ = m × Δn × d as a law; 10⁻⁶–10⁻⁷ RIU as "sensitivity" | Not a standard physical relation; RIU figures are resolutions | Report sensitivity in deg/RIU and resolution in RIU |
| Temperature compensation direction | Spec §5.4 vs SDK/CLI | Spec multiplies by [1 + α(T − Tref)]; code divides | The two conventions give α opposite meanings | Pick the division form (as the SDK does) and define α as the fractional signal increase per °C |
| Selectivity normalization | Appendix A.3; validateSensor | Ratios of raw signals at unequal concentrations; 39:1 called "good" | Kij is a ratio of sensitivities; the spec's own target is > 100 | Divide each signal by its concentration; report ≈ 39, 1.5 and 4.9 |
| Appendix A.2 regression | Spec Appendix A.2 | Slope 1.157, intercept 0.043, R² 0.9998 | The data give ≈ 1.1585, 0.047 and 0.99999 | Publish recomputed values; use them in test vectors |
| README 37 °C example | README SDK example | Implied result matching the 20.3 mM of spec A.2 | Different data (5.8 vs 5.85) and 37 °C; the SDK returns ≈ 14.9 mM and a temperature flag | Separate the two examples; show the SDK output |
| Dynamic range definition | Spec §1.4 | "Range over which sensor responds linearly" | That is the linear range; dynamic range is log₁₀(Cmax/LOD) | Define both terms separately |
| "EPA" LOD method | SDK calculateLOD | Fixed multiplier 3.14 | t = 3.14 holds only for n = 7 at 99 % | Use t for n − 1 degrees of freedom or rename the method |
| Regulatory examples | Spec §9.1.1–§9.1.2 | Glucose strips Class I; novel cardiac markers Class III; HIV tests Class C | Glucose and troponin tests are FDA Class II; HIV tests are IVDR Class D | Replace with the Section 8.3 table |
| Error grid | Spec §9.2.1, §8.1 | Clarke Error Grid; "CGM 90 % in Zone A" | ISO 15197:2013 uses the Consensus (Parkes) grid; the CGM figure has no source | Cite the Consensus grid; drop the CGM figure |
| Troponin cutoff | Spec §8.2 | Universal cutoff 0.04 ng/mL | Cutoffs are assay-specific 99th-percentile limits | Store the cutoff per assay in POCTestResult.cutoff |
| Reference list | Spec §10.1 | Numbered 1, 3, 5 | Entries missing | Renumber; do not reconstruct missing entries |
| PHASE document identity | spec/PHASE-1..4 | Carry the ID WIA-BIO-010; titles do not match file names; looser generic thresholds | Template text from another standard | Replace with biosensor-specific PHASE documents; until then treat only the main spec as normative |
Implementers who patch the SDK locally should record each patch in the profile manifest (the localPatches field above). Otherwise an auditor who compares results against the unpatched reference will see differences that look like defects.
Biosensor research moves quickly, and much of it will eventually test the limits of a v1.0 data model. The directions below are well established in the research literature. Their timing and commercial scale are not predicted here.
TimeSeries structure can carry this, but it has no link to express that several series come from one device.POCTestResult better than the linear calibration path.
For a future revision of WIA-BIO-011, the preceding chapters suggest a practical list. It would include non-linear inversion for the 4PL and Michaelis–Menten models already present in the type system; drift compensation and filtering that match the fields SignalProcessingParams already declares; enforcement of maxMeasurements and of state transitions on failure; an evaluated stability block; numbered requirements with official test vectors; and a real transport protocol, with the PHASE documents rewritten for this standard. Each of these would turn a current gap into a checkable requirement, and that is the purpose of a standard.
Validation turns metrics into evidence. CLSI protocols give the study designs (EP05 precision, EP06 linearity, EP07 interference, EP09 method comparison, EP15 user verification, and EP17 detection capability as a book addition). The reference validateSensor covers only part of this, and a thin wrapper can close its accuracy, selectivity and stability gaps. For glucose, ISO 15197:2013 sets tail-based accuracy criteria that a worked example shows can hinge on a single result. Regulatory routes differ between the FDA and the IVDR, and the spec's examples need correcting: glucose and troponin tests are FDA Class II, and HIV tests are IVDR Class D. WIA conformance has no certification scheme in v1.0. The honest form of a claim is a set of positive and negative test vectors, an evidence package and a profile manifest that states partial conformance openly. The errata table lists what an implementer must fix or document before relying on v1.0, and the future list shows where the next version could turn today's gaps into requirements.