Chapter 8
What WIA-BIO-010 v1.0 actually obliges an implementation to do, how to turn those obligations into test vectors, what the reference SDK does when you run them, and how the result fits into computerized-system validation, inspection and the next revision of the standard.
The previous seven chapters took WIA-BIO-010 apart one layer at a time. This chapter asks the question that comes last in any standards project and first in any audit: how do you show that an implementation does what the standard says?
The honest starting point is that v1.0 gives very little help. It lists required components, interfaces, validation limits and error codes, but it defines no conformance levels, no test suite and no certification procedure. This book does not invent tier names, pass rates or certification counts to fill the gap. What it offers instead is more useful: a set of requirements you can trace to clauses, a set of test vectors whose expected values you can check by hand, and a clear record of where the reference code passes and where it does not. The same material is what an auditor or inspector will ask to see.
Read strictly, the obligations in WIA-BIO-010 v1.0 sit in §8, with supporting definitions in §3.4 (21 CFR Part 11), §4 (statistical methods), §5 (adverse-event reporting), §7 (data models) and §9 (safety protocols). Section 8.1 opens with the sentence "Any WIA-BIO-010 compliant system must include" and then names five components. Sections 8.2 to 8.4 describe interfaces, validation limits and error codes. Nothing else uses the language of obligation, so the rest is best read as guidance.
| Clause | What it requires | How it can be verified |
|---|---|---|
| §8.1 (1) | Trial registration module: protocol and metadata management | Create, amend and read a trial record carrying the §7.1 fields; protocol version is tracked across amendments |
| §8.1 (2) | EDC system with validation | Entry of the §7.2 visit data; §8.3 limits enforced; queries raised and closed with an audit trail |
| §8.1 (3) | Safety reporting: SAE detection and reporting | Seriousness derived from the §5.4 criteria; expedited-report clock computed from the correct day 0 |
| §8.1 (4) | Statistics engine: sample size, power, analysis | Results match the §4 formulas and the Appendix A examples (corrected, see 8.2) |
| §8.1 (5) | Regulatory submission: CDISC export and eCTD generation | SDTM/ADaM datasets with define.xml pass an external conformance check; eCTD packaging is produced by a validated tool |
| §8.2 | Three interfaces: register trial, collect patient data, calculate statistics | Interface-level tests with the input and output shapes of §8.2.1–8.2.3 or a documented mapping to them |
| §8.3 | Validity limits for five vital signs and four laboratory values | Boundary tests at, just inside and just outside each limit |
| §8.4 | Error codes B001–B006 and the action each implies | Each code can be provoked by a defined input and is returned rather than silently ignored |
Two clauses outside §8 deserve to be pulled into any serious claim even though they are not phrased as obligations. Section 3.4 names 21 CFR Part 11, and a system that captures trial data without an audit trail or access control cannot be used for regulated work regardless of what the standard says. Section 9.1 lists the consent elements of 21 CFR 50.25, and §8.4 makes "missing informed consent" (B006) a reason to refuse data collection. Chapter 7 showed how both are implemented; here they become test cases.
package.json declares a Jest configuration, but there are no test files in the package. The simulator is a generic template with no trial logic, and the CLI prints demonstration output (Chapter 5). None of them is a conformance test.spec folder carry a different standard number and describe biomarker-assay criteria. They should not be cited as requirements of WIA-BIO-010.The practical consequence is that a conformance statement for v1.0 should name the clauses it covers and point to the evidence for each, rather than claim a level. The rest of this chapter builds that evidence.
Before writing tests you must decide which contract you are testing. The §8.2 interfaces and the @wia/bio-010 types are close but not identical, and a test written against one will fail against the other for reasons that have nothing to do with correctness.
| Item | Spec §8.2 / §7 | SDK (types.ts) | Test consequence |
|---|---|---|---|
| Trial identifier | id (§8.2.1), trialId (§7.1) | id | Map §7.1 JSON on input; do not compare field names literally |
| Primary endpoint | String in §8.2.1, object in §7.1 | String on input, Endpoint object on output | Test the object; timepoint is derived from duration |
| Sample size | Number in §8.2.1, object in §7.1 | Number on input, SampleSizeInfo on output | Check sampleSize.planned |
| Trial status | Five values in §8.2.1 | Six values, adds suspended | Accept suspended as an extension |
| Data-collection response | dataId always present | dataId undefined on failure; adds timestamp | Assert dataId only when success is true |
| Statistics parameters | No standard deviation or event rates | Requires one of them for sample size | §8.2.3 input alone cannot produce a sample size |
| Error codes | B001–B006 | B001–B010 | B007–B010 are SDK extensions |
The last-but-one row matters most. The §8.2.3 StatisticalParameters shape has an effectSize but no variance and no event rates, so it does not contain enough information to compute a sample size. The SDK's standalone calculateStatistics follows the spec shape and therefore throws B005 when asked for a sample size, and it falls back to a heuristic when asked for power. A test suite should record this as a specification defect, not only an implementation one.
A test vector is a fixed input with an expected output that someone other than the implementer can reproduce. Record a stable identifier, the exact input, the expected output with its tolerance, the clause that justifies it, and how the expected value was obtained (hand calculation, independent library, regulatory text). A vector whose expected value was copied from the implementation proves only that the implementation is deterministic.
The vectors below use four groups: statistics (ST), validation limits (VA), safety reporting (AE) and informed consent (IC). Statistical expectations use the two-decimal Z convention of the specification (1.96, 0.84, 1.28) unless stated otherwise, and every sample size is rounded up per group before doubling, as Chapter 2 explained. Dates are calendar days.
| ID | Input | Expected result | Basis |
|---|---|---|---|
| TV-ST-01 | Continuous; α 0.05 two-sided; power 0.80; σ 1.2; Δ 0.5 | 90.3 → 91 per group, 182 total; with 20% dropout 114 per group, 228 total | §4.1, App. A.1 (spec prints 113/226 by inflating the unrounded value) |
| TV-ST-02 | As ST-01 with σ 1.5 | 141.12 → 142 per group, 284 total; 284 / 0.8 = 355 total | §4.1 example, corrected (spec prints 141/282/353) |
| TV-ST-03 | Binary; p₁ 0.25, p₂ 0.15; α 0.05 two-sided; power 0.80 | 249.7 → 250 per group | §4.1 binary formula, computed in Chapter 2 |
| TV-ST-04 | As ST-02 with α 0.01 | Z1−α/2 2.576; 210.0 → 211 per group | §4.1 with the correct critical value |
| TV-ST-05 | As ST-02 with power 0.85 | Z1−β 1.036; 161.6 → 162 per group | §4.1 with the correct critical value |
| TV-ST-06 | Power; n 100 per group; σ 1.5; α 0.05 two-sided; Δ 0.3 / 0.5 / 0.7 / 1.0 | 0.29 / 0.65 / 0.91 / 0.997 (±0.005) | Φ(Δ/(σ√(2/n)) − 1.96); replaces the §4.2 table |
| TV-ST-07 | Power; n 100 per group; standardized effect 0.5; no σ | 0.94 if the effect is read as Cohen's d; otherwise the call must be rejected | Same formula with σ = 1 |
| TV-ST-08 | App. A.2 table (30/200 vs 50/200) | RR 0.60; SE(log RR) 0.208; 95% CI 0.40 to 0.90 | §4.4, App. A.2 corrected |
| TV-VA-01 | Systolic BP 59 mmHg | Out-of-range finding (B007), distinct from a normal-range flag; never accepted silently | §8.3 lower limit 60 |
| TV-VA-02 | Systolic BP 60 mmHg | Accepted without a B007 finding; clinical flag (below the 90 mmHg reference range) | §8.3; VITAL_SIGNS_RANGES |
| TV-VA-03 | Systolic BP 250 mmHg | Accepted without a B007 finding; clinical flag (above the reference range) | §8.3 upper limit 250 |
| TV-VA-04 | Systolic BP 251 mmHg | Out-of-range finding (B007), distinct from a normal-range flag; never accepted silently | §8.3 |
| TV-VA-05 | Diastolic BP 151; temperature 43 °C; respiratory rate 61 | A B007 finding for each value | §8.3 |
| TV-VA-06 | HbA1c 15.1%; glucose 19 mg/dL; creatinine 15.1 mg/dL; ALT 2001 U/L | A B007 finding for each value | §8.3 |
| TV-AE-01 | SAE, fatal, suspected, unexpected; onset 2026-03-02; sponsor aware 2026-03-05 | Expedited report due 2026-03-12 (day 0 + 7) | §5.4; 21 CFR 312.32(c)(2) |
| TV-AE-02 | SAE, hospitalization, suspected, unexpected; same dates | Expedited report due 2026-03-20 (day 0 + 15) | §5.4; 21 CFR 312.32(c)(1) |
| TV-AE-03 | SAE, hospitalization, causality "unlikely", expected | Recorded and reviewed; no expedited IND safety report | 21 CFR 312.32(c)(1) |
| TV-AE-04 | hospitalization: true with serious: false | Rejected as inconsistent, or serious derived as true | §5.4 definition |
| TV-IC-01 | Enrollment without a consent date | B006; no subject record created | §8.4, §9.1 |
| TV-IC-02 | Visit data for a subject with no enrollment | B002; nothing written | §8.4 |
Rounding conventions. The Z convention changes some answers by one subject. With two-decimal critical values, 90% power for TV-ST-02 gives (1.96 + 1.28)² × 18 = 188.96, which rounds up to 189 per group; with full-precision values (1.95996 and 1.28155) the product is 189.13 and rounds up to 190. Neither is wrong, but a vector must say which convention it uses. When a protocol is involved, the full-precision figure is the safer choice because it is never smaller.
Dropout on odd totals. TV-ST-02 inflates the total, 284 / 0.8 = 355. Applied per group the same inflation gives 142 / 0.8 = 177.5, rounded to 178, or 356 in total. With 1:1 randomization a total of 355 cannot be split equally, so a design document would normally state 178 per group. A test that expects 355 is checking the specification's arithmetic; a test that expects 178 per group is checking a usable design. Decide which question the vector answers and name it accordingly.
Validity limits versus reference ranges. TV-VA-02 and TV-VA-03 are accepted values that should nevertheless be flagged. The §8.3 limits separate impossible or implausible entries from possible ones; the reference ranges in VITAL_SIGNS_RANGES separate normal from abnormal. A systolic pressure of 250 mmHg is a plausible and alarming value, not a data-entry error. Tests must check both outcomes: accepted, and flagged. Whether a value outside the §8.3 limits is then blocked or stored with an open query is a documented edit-check policy; Chapter 7 recommends storing it with a query, because the EDC must be able to record what the source document says. The vectors require only that the finding is raised as B007 and cannot be mistaken for a normal-range flag.
Safety dates. The AE vectors separate onset from sponsor awareness by three days, because a system that counts from onset passes any vector in which the two coincide. The dates are illustrative, and the vectors assume the case qualifies for reporting on the day the sponsor becomes aware of it.
The vectors were run against the TypeScript sources of @wia/bio-010 1.0.0 as found in the repository, compiled without modification. The table reports what the code returned, not what its documentation says.
| ID | Expected | SDK 1.0.0 returns | Verdict |
|---|---|---|---|
| TV-ST-01 | 91 / 182 / 228 | 91 / 182 / 228 | Pass |
| TV-ST-02 | 142 / 284 / 355 | 142 / 284 / 355 | Pass (spec text fails) |
| TV-ST-03 | 250 per group | 146 per group | Fail: binary terms squared separately |
| TV-ST-04 | 211 per group | 142 per group | Fail: Z fixed at 1.96 |
| TV-ST-05 | 162 per group | 142 per group | Fail: any power below 0.90 uses 0.84 |
| TV-ST-06 | 0.29 / 0.65 / 0.91 / 0.997 | 0.293 / 0.654 / 0.910 / 0.997 | Pass |
| TV-ST-07 | 0.94 or rejection | 0.70 (heuristic 0.5 + 0.4·(n/100)·Δ) | Fail |
| TV-ST-08 | RR and CI | No RR function | Not implemented |
| TV-VA-01 | B007 finding | success: true, warning "out of normal range" | Fail: the same warning as any value below 90 |
| TV-VA-02 | Accepted, flagged | success: true, warning | Pass |
| TV-VA-03 | Accepted, flagged | success: true, no warning | Partial: no flag between 141 and 250 |
| TV-VA-04 | B007 finding | success: true, warning "critically high" | Fail: a clinical-flag message, no validity finding |
| TV-VA-05 | B007 findings | Not checked; no warning | Fail |
| TV-VA-06 | B007 findings | HbA1c 15.1 and creatinine not checked; glucose and ALT produce warnings only | Fail |
| TV-AE-01 | 2026-03-12 | 2026-03-09 (onset + 7) | Fail: wrong day 0 |
| TV-AE-02 | 2026-03-20 | 2026-03-17 (onset + 15) | Fail: wrong day 0 |
| TV-AE-03 | No expedited report | reportingRequired: true | Fail: causality and expectedness ignored |
| TV-AE-04 | Rejected or derived | reportingRequired: false | Fail: flags not cross-checked |
| TV-IC-01 | B006 | Enrollment record returned | Fail: no consent check |
| TV-IC-02 | B002 | Data accepted (SDK keeps no enrollment state) | Fail: out of SDK scope |
Four passes and one partial pass out of twenty vectors is not a verdict on the value of the SDK. The continuous-endpoint arithmetic, the power formula when a standard deviation is supplied and the descriptive statistics (apart from their fixed 1.96 intervals) are correct, and they are the parts most people will call first. The failures cluster in three places: statistical parameters the code does not really accept (any α other than 0.05, any power other than 0.80 or 0.90, binary endpoints), validation that cannot tell an implausible value from an abnormal one, and safety logic that counts from the wrong day and ignores the two attributes that decide whether a report is due.
The package is configured for Jest with ts-jest. The suite below encodes a subset of the vectors. Tests that the current code fails are written with test.failing, available since Jest 28, which passes while the assertion fails and turns red when the defect is fixed. That keeps the build green today, records every known defect in executable form, and forces whoever fixes a defect to promote its test to an ordinary one.
// __tests__/conformance.test.ts
import { ClinicalTrialSDK, ClinicalTrialErrorCode } from '../src';
const sdk = new ClinicalTrialSDK();
const base = { alpha: 0.05, power: 0.8, testType: 'two-tailed' as const };
const noFlags = {
serious: false, death: false, lifeThreatening: false, hospitalization: false,
disability: false, congenitalAnomaly: false, other: false,
};
describe('Statistics (TV-ST)', () => {
test('TV-ST-01 App. A.1: 91 per group, 228 after dropout', () => {
const r = sdk.calculateSampleSize({ ...base, effectSize: 0.5, standardDeviation: 1.2 });
expect(r.sampleSizePerGroup).toBe(91);
expect(r.adjustedSampleSize).toBe(228);
});
test('TV-ST-02 §4.1 corrected: 142 per group', () => {
const r = sdk.calculateSampleSize({ ...base, effectSize: 0.5, standardDeviation: 1.5 });
expect(r.sampleSizePerGroup).toBe(142);
});
test.failing('TV-ST-03 binary 25% vs 15%: 250 per group', () => {
const r = sdk.calculateSampleSize({
...base, effectSize: 0.1, controlRate: 0.25, treatmentRate: 0.15,
});
expect(r.sampleSizePerGroup).toBe(250);
});
test.failing('TV-ST-04 alpha 0.01 uses Z = 2.576: 211 per group', () => {
const r = sdk.calculateSampleSize({
...base, alpha: 0.01, effectSize: 0.5, standardDeviation: 1.5,
});
expect(r.sampleSizePerGroup).toBe(211);
});
test.each([
[0.3, 0.293], [0.5, 0.654], [0.7, 0.910], [1.0, 0.997],
])('TV-ST-06 power at delta %p is %p', (delta, expected) => {
const r = sdk.calculatePower({
sampleSize: 100, alpha: 0.05, effectSize: delta,
standardDeviation: 1.5, testType: 'two-tailed',
});
expect(r.power).toBeCloseTo(expected, 2);
});
});
describe('Validation limits (TV-VA)', () => {
const vitals = (systolicBP: number) =>
sdk.collectPatientData({ trialId: 'T', patientId: 'T-001', visit: 'V1',
vitalSigns: { systolicBP } });
test('TV-VA-02 SBP 60 accepted and flagged', () => {
const r = vitals(60);
expect(r.success).toBe(true);
expect(r.warnings.length).toBeGreaterThan(0);
});
// A §8.3 breach must surface as a B007 finding, in either channel
const hasB007 = (r: { validationErrors: string[]; warnings: string[] }) =>
[...r.validationErrors, ...r.warnings].some((m) => m.includes('B007'));
test.failing('TV-VA-01 SBP 59 raises a B007 finding', () => {
expect(hasB007(vitals(59))).toBe(true);
});
test.failing('TV-VA-04 SBP 251 raises a B007 finding', () => {
expect(hasB007(vitals(251))).toBe(true);
});
});
describe('Safety reporting (TV-AE)', () => {
test.failing('TV-AE-01 fatal SUSAR: day 0 is sponsor awareness', () => {
const r = sdk.recordAdverseEvent({
subjectId: 'T-001', trialId: 'T', term: 'Sudden death',
startDate: '2026-03-02', ongoing: false, severity: 'death',
causality: 'possible', outcome: 'fatal',
seriousness: { ...noFlags, serious: true, death: true },
// awareness date is not part of the v1.0 type; see 8.6
} as any);
expect(r.reportingDeadline?.toISOString().slice(0, 10)).toBe('2026-03-12');
});
});
describe('Consent (TV-IC)', () => {
test.failing('TV-IC-01 enrollment without consent throws B006', () => {
let err: unknown;
try {
sdk.enrollPatient({ trialId: 'T', demographics: { age: 58, sex: 'M' } } as any);
} catch (e) {
err = e;
}
expect(err).toMatchObject({ code: ClinicalTrialErrorCode.MISSING_CONSENT });
});
});Two casts are deliberate. The AE test needs as any because v1.0 has nowhere to put a sponsor-awareness date, so it cannot pass until the type gains one. The consent test needs one because the type makes consentDate required while the runtime never checks it; compile-time protection vanishes once data arrive as JSON, so the runtime check is the one that matters.
Fixed critical values. calculateSampleSize chooses 1.96 or 1.645 for α according to the test type alone, and 0.84 or 1.28 for power by comparing it with 0.9. Any other α or power is silently answered as if it were 0.05 and 0.80 or 0.90. The output then echoes the requested power back in its power field, so a caller who asked for 85% power receives a result labelled 0.85 that was computed for 80%. This is more dangerous than an exception, because nothing downstream can tell.
Heuristic power. Without a standard deviation, calculatePower returns 0.5 + 0.4 × (n/100) × Δ, capped at 0.99. It is not a power function: it gives 0.70 for any trial with n = 100 and Δ = 0.5, whatever the variability, and it rises in a straight line with n. Any call made through the spec-shaped calculateStatistics wrapper reaches this branch, because that wrapper has no way to pass a standard deviation.
Deadline base date. recordAdverseEvent adds 7 or 15 days to the event's startDate. Onset is the wrong day 0, and whether any expedited report is due depends on causality and expectedness, which the method ignores. Chapter 4 gave a corrected calculation; the vectors make sure it stays correct.
Validation that only warns. collectPatientData never fills validationErrors from a range check. Only non-numeric measurement values produce errors. Vital signs outside the §8.3 limits produce the same kind of warning as abnormal but valid values, and diastolic pressure, temperature, respiratory rate and creatinine are not checked at all. A value of zero skips the systolic check entirely, because the code tests the value for truthiness before comparing it.
Identifier collisions. Not a vector in the table, but worth a test: enrollPatient builds the subject identifier from the trial ID and a random number between 0 and 999. The chance that at least two of 60 subjects receive the same identifier is about 84% (1 − ∏(1 − i/1000) for i from 0 to 59). Identifiers must come from a sequence or a registry, never from a random draw.
To use the SDK today, apply the pattern of Chapters 5 and 7: a thin wrapper that rejects inputs the SDK mishandles, raises B007 findings for values outside the §8.3 limits, checks consent and enrollment, and computes safety deadlines from an awareness date. Run the vector suite against the wrapper. When upstream fixes land, the test.failing entries show which parts of the wrapper can be retired.
Passing a test suite is necessary but not sufficient. Regulators expect computerized systems that create, modify or store trial records to be validated, with documented evidence that the system consistently does what it is intended to do in its actual environment. Part 11 requires this directly (21 CFR 11.10(a)), ICH E6 requires it for any system used in a trial, and the Korean KGCP carries the same expectation for trials conducted under MFDS oversight. The widely used industry framework is ISPE's GAMP 5, which scales the effort to the risk the system poses to subject safety and data integrity.
The classic breakdown is into three qualification stages.
Test hardest where a failure would hurt a subject or corrupt a primary endpoint. For WIA-BIO-010 the high-risk functions are easy to name: safety-report clocks, consent enforcement, validation limits on primary-endpoint data and the sample-size engine if it is used to set enrollment targets.
A traceability matrix connects each requirement to the tests that verify it and to the evidence those tests produced. It lets an auditor start from any clause and reach a signed result, or start from any failed test and see which requirement is at risk. A few rows show the pattern.
| Requirement | Source | Risk | Test(s) | Evidence |
|---|---|---|---|---|
| Raise B007 for systolic BP outside 60–250 mmHg | §8.3 | Medium | TV-VA-01 to 04 | OQ run log, build ID, reviewer signature |
| Expedited-report clock from sponsor awareness | §5.4; 21 CFR 312.32 | High | TV-AE-01 to 03 | OQ run log; PQ case file from the mock study |
| No data write without documented consent | §8.4 (B006); §9.1 | High | TV-IC-01; PQ scenario "consent withdrawn" | OQ log; PQ script signed by site user |
| Sample size for continuous endpoint | §4.1; App. A.1 | Medium | TV-ST-01, 02, 04, 05 | OQ log; independent calculation sheet |
| Audit trail on every data change | §3.4; 21 CFR 11.10(e) | High | Part 11 OQ set | Audit report extract compared with change script |
Keep the matrix under version control with the code, so that a revised requirement shows at once which tests and evidence must be redone.
The fifth required component, CDISC export and eCTD generation, cannot be tested with the SDK, because the SDK does not produce datasets: generateSubmission returns a record with status draft and whatever list of dataset names was passed in. Dataset conformance is checked on the datasets themselves, with tools outside this standard. The usual checks are the following.
No certificate for a data standard substitutes for inspection readiness. A sponsor audit, a regulatory GCP inspection (for example under the FDA Bioresearch Monitoring program, by EU member-state inspectorates, or by MFDS in Korea) looks at how the trial was run and whether the records can be trusted. For the data systems that means a fairly stable list.
Every item on that list is outside the scope of a JSON schema or an SDK, which is why no implementation of a data standard makes a trial inspection-ready by itself. What it can do is make the evidence easy to produce.
Since v1.0 defines no conformance procedure, the most defensible statement an implementer can make is a self-assessment: a table of requirements, the clause each comes from, the evidence held and a status. The template below covers the normative core of 8.1 plus the Part 11 and consent requirements that any regulated use needs. The status column is left for the implementer; "Met", "Partly met" and "Not met" are sufficient, with a note for anything short of "Met".
| # | Requirement | Spec § | Evidence to hold | Status |
|---|---|---|---|---|
| 1 | Trial registration with §7.1 fields and protocol versioning | 8.1, 7.1 | Interface tests; sample record; amendment history | |
| 2 | Registry identifiers stored as issued, not generated locally | 7.1 | Field definition; test rejecting self-generated NCT numbers | |
| 3 | EDC capture of visits, measurements, labs and vitals | 8.1, 7.2 | OQ log; CRF specifications | |
| 4 | §8.3 validity limits raise B007 findings (blocked or queried per documented policy) | 8.3 | TV-VA-01 to 06 results | |
| 5 | Reference-range flags kept separate from validity limits | 8.3; 9.2 | TV-VA-02, 03 results; flag specification | |
| 6 | Seriousness derived from §5.4 criteria and cross-checked | 5.4 | TV-AE-04 result | |
| 7 | Expedited-report clock from sponsor awareness, only for qualifying cases | 5.4 | TV-AE-01 to 03 results; safety SOP | |
| 8 | MedDRA and CTCAE versions recorded with each coded term | 5.1, 5.2 | Data dictionary; coding report | |
| 9 | Sample size and power match §4 for supported inputs; others rejected | 4.1, 4.2 | TV-ST-01 to 07 results; statement of supported range | |
| 10 | Hypothesis tests and CIs use exact distributions or state their approximation | 4.3, 4.4 | TV-ST-08; small-sample test | |
| 11 | SDTM/ADaM export with define.xml passing external checks | 8.1, 3.1–3.3 | Validator report; define.xml | |
| 12 | Error codes B001–B006 returned for their conditions | 8.4 | One test per code | |
| 13 | No data write without documented consent | 8.4, 9.1 | TV-IC-01 result; consent SOP | |
| 14 | Audit trail, electronic signatures, access control | 3.4 | Part 11 OQ set; access review | |
| 15 | System validated for intended use | 3.4 | Validation plan, matrix, report |
A self-assessment is only as good as the evidence column. Rows 4, 6, 7, 9 and 13 cannot be marked "Met" for a system that relies on the SDK without the wrapper described in 8.3; the vector results say so, and an honest assessment should repeat it.
The README names a WIA certification web address, but v1.0 describes no procedure behind it, so this book treats it as a point of contact only. Any future scheme can at most attest that an implementation handles the standard's formats and interfaces as specified. It cannot attest to the validation of a sponsor's system or the conduct of a trial, which remain the sponsor's responsibility.
A version 1.0 is a first draft that has been published. The directions below come from developments in clinical-trial regulation and practice that the current text does not yet reflect. They are proposals for the next revision, not features of v1.0.
The ICH GCP guideline was revised as E6(R3), adopted in 2025, which replaces the E6(R2) text cited in the specification's references. It moves further toward quality by design and risk-proportionate oversight: identify the factors critical to quality, focus monitoring on them, and use centralized, data-driven monitoring alongside site visits. For a data standard this means flagging critical data explicitly and supporting key risk indicators computed from the data, such as query rates, visit-window deviations and SAE reporting delays. v1.0 has none of these.
The E9(R1) addendum of 2019 asks trials to state precisely what treatment effect they estimate, including how intercurrent events such as treatment discontinuation or rescue medication are handled. The specification's §1.4 still lists LOCF among its core terms, while current practice discourages it as a default way of handling missing data. A future data model needs fields for intercurrent events, their dates and the strategy (treatment policy, hypothetical, composite, while-on-treatment or principal stratum) applied to each, so that the analysis datasets can be traced back to the estimand the protocol declared.
Home visits, patient-entered electronic outcome assessments and wearable devices turn a visit from a single date with a list of values into a stream with device identity, firmware, sampling rate and time zone. The v1.0 measurements map cannot represent that provenance, and the §8.3 limits were written for single clinic readings. A revision would need a source attribute on every observation (site, home nurse, patient app, device), device metadata and aggregation rules that say how a stream becomes an analysis value.
Post-marketing studies increasingly draw on electronic health records, registries and claims data, which arrive in clinical-care formats such as HL7 FHIR rather than CDASH. WIA-BIO-010 could define a mapping layer and, above all, the provenance and quality metadata a reviewer needs to judge whether real-world data are fit for the question. This is the natural place for the WIA-OMNI-API link the README names, once its interface is specified.
The README lists adaptive, basket and umbrella designs as use cases, but the data model assumes one trial, one protocol version at a time and two arms. Platform trials add and drop arms under a master protocol, and adaptive designs change allocation or sample size at interim analyses. Supporting them needs arm-level lifecycle states, a record of each adaptation decision with the interim data cut it used, and randomization lists versioned by adaptation. ICH has an adaptive-design guideline (E20) in development, which a revision should track.
The README pairs the standard with WIA-AI for "AI-powered clinical analytics". In a trial, a model's output is either support for a human decision or a measurement that must be validated like any other. A revision should require, at minimum, model identity and version on every output, a record of the data the model was trained and validated on, and a rule that no model output alone changes a subject's record, a seriousness classification or an analysis population. The same test-vector discipline applies: fixed inputs, expected outputs, and documented tolerance.
| Area | Gap in v1.0 | Suggested change for the next revision |
|---|---|---|
| Conformance | No levels, test suite or procedure | Publish normative test vectors with expected values and a conformance statement template |
| Statistics | Fixed Z values; binary formula defect; heuristic power; §4.2 and App. A.2 numbers wrong | Exact quantiles; correct binary formula; reject unsupported inputs; corrected worked examples |
| Safety | No awareness date or expectedness; clock from onset | Add sponsorAwarenessDate and expectedness; derive expedited status |
| Validation | Limits produce warnings; four limits unchecked | Normative error semantics for §8.3; separate reference-range flags |
| Quality management | No critical-data or risk-indicator model | Critical-data flags and standard key risk indicators, aligned with E6(R3) |
| Estimands | LOCF listed; no intercurrent events | Intercurrent-event records and estimand strategy per endpoint, per E9(R1) |
| Decentralized data | No provenance or device metadata | Source and device attributes; stream-to-value aggregation rules |
| Designs | Two-arm, single-protocol assumptions | Arm lifecycle, adaptation log, versioned randomization |
| References | Superseded guideline versions; EudraCT | Cite E6(R3), E9(R1), EU CTR 536/2014 and CTIS; state dictionary versions as "as used" |
test.failing so they stay visible and flip when fixed.This book set out to make WIA-BIO-010 usable: to explain the clinical and statistical ideas behind it, to correct its errors where the arithmetic or the regulations say otherwise, and to show which parts of its reference code can be trusted. The standard's value lies less in any single formula than in the discipline it asks for, a shared model for trials, subjects, visits and adverse events that can be checked end to end. That discipline is only real when it is tested. The vectors, checklists and traceability matrix in this chapter are the means to make it so, and a place to start the next revision of the standard.