Chapter 6
How a study moves through WIA-BIO-018 from the first protocol draft to close-out: which review level it is routed to, which states its submission passes through, how the board meets, how consent is executed at the bedside, and how safety events and audits keep the approval honest after it is granted.
Chapter 2 described the institutions of human-subjects protection: what a consent form must disclose, who sits on an IRB and what the board must find before it approves. Chapters 4 and 5 turned those rules into records and SDK functions. This chapter joins the two views along the time axis. An ethics approval is not a single event; it is a process that starts before the first participant is approached and ends only when the last record has been retained for as long as the applicable law requires. At each step, WIA-BIO-018 expects a decision to be made by a named person, captured in a record, and linked to the version of the protocol and consent form that was in force at the time.
The chapter follows that timeline. For each step it states what the standard (spec §3.2, §4.3–§4.5, §9.1–§9.3) requires, what the reference SDK (submitIRBProtocol and its helpers in index.ts) actually does, and where the two diverge from the regulations they are meant to serve. Where the standard prints a number that is a design choice rather than a legal rule, such as a monitoring interval or a reporting deadline, this chapter says so and names the jurisdictional rule an implementer should configure instead.
A human-subjects study under BIO-018 passes through eight stages. The boundaries between them are gates: a study should not be able to reach the next stage in software unless the record that closes the current stage exists. That is the practical meaning of "machine-checkable ethics" introduced in Chapter 1.
| # | Stage | What happens | Record that closes the stage | Gate owner |
|---|---|---|---|---|
| 1 | Design | Investigators write the protocol, identify risks and benefits, choose the population | Draft IRBProtocol, RiskBenefitAnalysis | Principal investigator |
| 2 | Pre-study checklist | The eight items of spec §9.1 are prepared (see below) | Checklist record with evidence links | Study coordinator |
| 3 | Submission | Protocol is submitted and a review level is proposed | IRBSubmission with status: 'submitted' | IRB office |
| 4 | Review | Exempt determination, expedited reviewer or convened board decides | IRBSubmission.decision, rationale, expirationDate | IRB chair or board |
| 5 | Consent | Each participant is informed, assessed and signs | InformedConsent per participant | Person obtaining consent |
| 6 | Conduct | Interventions, data collection, safety reporting | AdverseEvent, ProtocolDeviation | Investigator, sponsor |
| 7 | Continuing oversight | Continuing review, monitoring and audits | Renewed approval, AuditResult | IRB, quality assurance |
| 8 | Close-out and retention | Final report, archive, retention clock starts | Close-out report, retention schedule | Investigator, institution |
Spec §9.1 lists eight items that must be in place before a study starts. Read as a checklist, they look like administrative housekeeping. Read as a gate, they determine whether stage 6 may begin at all, so each item should point to evidence rather than to a ticked box.
| §9.1 item | Evidence a system should hold | Chapter where the record is defined |
|---|---|---|
| IRB approval obtained | IRBSubmission with an approving decision and a future expirationDate (or a documented exemption) | This chapter, 6.3 |
| Informed consent form approved | Form template ID and version, linked to the approving decision | Chapter 4 |
| Consent process documented | Who obtains consent, in which setting, which comprehension method, when a witness or LAR is involved | This chapter, 6.5 |
| Data security plan implemented | Protection level of each data class, encryption and access-control configuration | Chapters 3 and 7 |
| Adverse event reporting plan established | Reporting matrix configured for the study's jurisdictions | This chapter, 6.6 |
| Staff training completed | Training records for everyone on the delegation log | Chapter 7 |
| Vulnerable population protections in place | The additional safeguards the IRB required for each included group | Chapter 2 |
| Risk-benefit analysis documented | RiskBenefitAnalysis record and the reviewer's narrative | Chapters 4 and 5 |
Two of these items deserve a stronger check than "a document exists". The approval must still be current on the day a participant is enrolled, and the consent form a participant signs must be the version the board approved. Both conditions are easy to state and easy to violate once amendments start to accumulate, which is why sections 6.3 and 6.5 return to them.
Before anyone reads the scientific content of a protocol, the IRB office decides how much review it needs. BIO-018 §4.3 defines three levels (exempt, expedited, full-board), and the SDK's submitIRBProtocol proposes one from two fields of the protocol: riskLevel and participants.vulnerablePopulations. The core of the algorithm is short enough to reproduce.
// Reference SDK, BioEthicsSDK.submitIRBProtocol (simplified)
if (protocol.riskLevel === 'minimal' && !hasVulnerablePopulations(protocol)) {
reviewLevel = isExemptEligible(protocol) ? 'exempt' : 'expedited';
} else if (protocol.riskLevel === 'minor-increase' && !hasVulnerablePopulations(protocol)) {
reviewLevel = 'expedited';
} else {
reviewLevel = 'full-board'; // greater-than-minimal, high, or any vulnerable group
}
// isExemptEligible: studyType must contain one of these phrases
// 'educational research', 'anonymous surveys',
// 'observation of public behavior', 'existing de-identified data'
The resulting routing can be written as a decision table. RiskLevel has four values (Chapter 4), and hasVulnerablePopulations is true whenever the array is present and non-empty.
riskLevel | Vulnerable group listed? | studyType matches an exempt phrase? | SDK proposal | Comment |
|---|---|---|---|---|
minimal | No | Yes | exempt | Proposal only; the institution makes the exemption determination |
minimal | No | No | expedited | In US practice the activity must also fall in a listed expedited category |
minor-increase | No | n/a | expedited | Conflicts with regulations that allow expedited review only for minimal risk (see below) |
minimal or minor-increase | Yes | n/a | full-board | Stricter than some regulations; a deliberate choice of the standard |
greater-than-minimal or high | Any | n/a | full-board | Consistent with the regulations |
Three differences matter in practice. First, the "minor increase over minimal risk" level comes from the US rules for research involving children (45 CFR 46.406), where it describes research that may be approved only under additional conditions and, under the Common Rule, by a convened board. Under both the Common Rule (45 CFR 46.110) and FDA's rules (21 CFR 56.110), expedited review is available only for research that is no more than minimal risk and fits a published list of categories. Routing minor-increase protocols to expedited review is therefore not a faithful encoding of US regulation. An implementer who operates under those rules should route minor-increase to full-board, or at least force a human confirmation.
Second, the exempt check is a substring match on a free-text field. A study type written as "non-anonymous surveys" contains the phrase "anonymous surveys" and would be proposed as exempt; a study type written as "questionnaire (anonymous)" would not. Free text is the wrong input for a regulatory classification. A better design stores the exemption category as a coded value chosen by the investigator and confirmed by the IRB office, and treats free text only as a description.
Third, the CLI (wia-bio-018 submit-irb) implements a different rule from the SDK. It routes every minimal-risk, non-vulnerable protocol to expedited and never proposes exempt; it also prints expected timelines that are not defined anywhere in the standard. Tests and demonstrations should therefore call the SDK, not the CLI, when they need to reproduce the standard's routing.
Whatever the algorithm, the review level is a proposal, not a determination. Regulations place the decision with the institution: an investigator cannot declare their own study exempt, and a designated reviewer who is unsure can always refer a protocol to the full board. A conformant system should therefore store three things: the level the algorithm proposed, the level a named IRB staff member or chair assigned, and the reason when the two differ. The wrapper below is a sketch of that design. It is the book's recommendation, not part of the reference SDK.
type Jurisdiction = 'US-CommonRule' | 'US-FDA' | 'EU-CTR' | 'KR-Bioethics' | 'other';
interface RoutingProposal {
proposed: IRBReviewLevel;
reasons: string[];
requiresHumanConfirmation: boolean;
}
function proposeReviewLevel(p: IRBProtocol, j: Jurisdiction): RoutingProposal {
const reasons: string[] = [];
const vulnerable = (p.participants.vulnerablePopulations ?? []).length > 0;
if (vulnerable) {
reasons.push('Vulnerable population listed: BIO-018 requires full-board review');
return { proposed: 'full-board', reasons, requiresHumanConfirmation: false };
}
if (p.riskLevel === 'greater-than-minimal' || p.riskLevel === 'high') {
reasons.push(`Risk level ${p.riskLevel}`);
return { proposed: 'full-board', reasons, requiresHumanConfirmation: false };
}
if (p.riskLevel === 'minor-increase') {
// Expedited review is limited to minimal risk under 45 CFR 46.110 / 21 CFR 56.110
const level = j.startsWith('US') ? 'full-board' : 'expedited';
reasons.push('Minor increase over minimal risk: confirm level under local rules');
return { proposed: level, reasons, requiresHumanConfirmation: true };
}
// minimal risk, no vulnerable group
const sdkLevel = new BioEthicsSDK().submitIRBProtocol(p).reviewLevel;
reasons.push(`SDK proposal for minimal risk: ${sdkLevel}`);
return { proposed: sdkLevel, reasons, requiresHumanConfirmation: sdkLevel === 'exempt' };
}Note that the wrapper still calls the SDK for the minimal-risk case, so that it stays aligned with the standard where the standard is sound. It asks for a human decision in exactly the two situations where the regulations reserve that decision to the institution: exemptions, and the grey zone just above minimal risk.
Once submitted, a protocol becomes an IRBSubmission record whose status field tracks where it is in review. The type in types.ts allows six values: submitted, under-review, approved, revisions-required, rejected and withdrawn. (The shorter interface printed in spec §8.2.3 omits withdrawn; the TypeScript type is the more complete of the two and is used here.) The SDK creates the record in the submitted state and leaves every later transition to the institution's workflow.
submitIRBProtocol()
|
v
+-------------+ investigator withdraws
| submitted |-----------------------------+
+-------------+ |
| office screens, assigns reviewer |
v v
+--------------+ withdraws +-------------+
+----->| under-review |-------------------->| withdrawn |
| +--------------+ +-------------+
| | | \
| | | \ board disapproves
| v v v
| +-----------+ +--------------------+ +-----------+
| | approved | | revisions-required | | rejected |
| +-----------+ +--------------------+ +-----------+
| | |
| | | investigator resubmits
+--------+-----------------+
amendment or continuing review
(new review cycle)
The diagram adds two conventions that the type alone does not express. An approved protocol does not change back to under-review in place; an amendment or a continuing review opens a new review cycle that references the approved record, so that the history of what was approved, and when, is never overwritten. And rejected and withdrawn are terminal: a rejected study that is redesigned comes back as a new submission.
The decision field uses a different vocabulary, IRBDecision, with five values. Two of them have no status of the same name, so a system needs an explicit mapping. The mapping below follows common IRB practice and is the book's recommendation.
IRBDecision | Meaning | Resulting status | What must also be recorded |
|---|---|---|---|
approved | Approved as submitted | approved | reviewDate, expirationDate if continuing review applies |
approved-with-modifications | Approved on condition of specified, minor changes that the chair or designee can verify | revisions-required until the changes are verified, then approved | modifications[]; name of the person who verified them |
revisions-required | Substantive changes needed; the revised protocol returns for review | revisions-required | modifications[], rationale |
deferred | The board could not decide, for example for lack of information or expertise | stays under-review | rationale, the meeting at which it will return |
rejected | Disapproved | rejected | rationale, communicated to the investigator with an opportunity to respond |
The essential safety property is that participants may be enrolled only while status is approved, and, if expirationDate is set, only before that date. An approval with conditions is not an approval until the conditions are met. Software that enrols participants should check both conditions at the moment of enrolment rather than trusting a flag cached when the study was activated.
expirationDate is optional in the type because not every study has one. Where continuing review is required (section 6.7), the approval lapses on that date, and a lapse is not a formality: under US rules, research activities must stop when approval expires, except where the IRB finds that continuing an intervention is in the best interests of already-enrolled participants. A system should warn well before expiry and block new enrolment on the day it passes.
The SDK builds submission IDs as IRB- followed by a millisecond timestamp and a short random string. That format is readable, but it is generated on the client and gives no guarantee of uniqueness or ordering. In production the identifier of record should be issued by the IRB's own system, and the SDK-style ID kept only as a correlation key.
For protocols routed to full-board, the decision is made at a convened meeting. BIO-018 §4.3.3 states four conditions: a quorum of a majority of members, a non-scientist present, a community member present, and approval by majority vote. §4.1 adds that members with a conflict of interest, or members reviewing their own research, must not take part. These conditions can all be checked by software at the moment a vote is recorded.
| Rule | Source in BIO-018 | How to check it | Regulatory note |
|---|---|---|---|
| Quorum: majority of members present | §4.3.3 | Members present and eligible > half of the voting roster | Common Rule 45 CFR 46.108(b) uses the same majority test |
| Non-scientist present | §4.3.3 | At least one eligible member whose primary concerns are non-scientific | Required by 46.108(b) for the meeting to take action |
| Community (unaffiliated) member present | §4.3.3 | At least one eligible member not affiliated with the institution | US rules require such a member on the board (46.107(d)) but not at every meeting; BIO-018 is stricter |
| Majority approval | §4.3.3 | Votes in favour > half of eligible members present | Common Rule: majority of members present at the meeting |
| Conflict-of-interest recusal | §4.1 | Conflicted members leave for deliberation and vote and are excluded from the quorum count | 46.107(e): may provide information requested by the IRB but not participate in review |
| Meeting at least monthly | §4.3.3 | Configured per board | An operating choice, not a universal rule; boards schedule by workload |
Recusal interacts with quorum in a way that is easy to miss. Consider a hypothetical board of nine voting members, of whom seven attend. Seven is more than half of nine, so the meeting is quorate. If two attending members have a financial interest in the sponsor of one protocol, they leave the room for that item, and only five eligible members remain. Five is still more than 4.5, so the item can proceed, and approval needs at least three votes in favour. If a third member were conflicted, four eligible members would remain, the quorum would be lost for that item, and the board would have to defer it. The same arithmetic applies if the only non-scientist is the one who is conflicted: the item cannot be acted upon even though enough members are in the room.
interface Member { id: string; nonScientist: boolean; unaffiliated: boolean; }
function canActOnItem(roster: Member[], present: Member[], conflicted: Set<string>) {
const eligible = present.filter(m => !conflicted.has(m.id));
const problems: string[] = [];
if (eligible.length * 2 <= roster.length) problems.push('no quorum after recusals');
if (!eligible.some(m => m.nonScientist)) problems.push('no eligible non-scientist');
if (!eligible.some(m => m.unaffiliated)) problems.push('no eligible community member (BIO-018 rule)');
return { ok: problems.length === 0, eligibleCount: eligible.length, problems };
}
function isApproved(votesFor: number, eligibleCount: number): boolean {
return votesFor * 2 > eligibleCount; // majority of eligible members present
}
The minutes of a convened meeting are themselves a record that auditors will ask for (section 6.7). For each item they should show who was present, who was recused and why, the vote count (for, against, abstaining), the decision, the basis for any required changes, and, for research with vulnerable groups, the specific findings the regulations require. When those fields are captured as structured data, the canActOnItem check can be re-run at audit time to demonstrate that every decision was taken by a properly constituted board.
IRB approval makes it permissible to approach participants; it does not replace their consent. Consent is executed once per participant, and again whenever the approved form changes in a way that matters to people already enrolled. The standard does not spell out an order of steps, but its rules imply one, and the SDK's validateInformedConsent checks the outcome of every step. The sequence below makes that implied order explicit.
Participant Person obtaining consent eConsent system IRB record
| | | |
| |-- check approval ---------+---------------------->|
| |<-- approved, form vN, not expired ----------------|
|<-- 1. disclose (form vN) -| | |
|-- questions, answers ---->| | |
|<-- 2. comprehension check-|-- record score ---------->| |
| | score < 0.80 ? E002: re-educate, reassess |
|<-- re-explain missed items| | |
| |-- 3. capacity band ------>| |
| | diminished / severely-impaired ? E004 |
| | obtain LAR consent + participant assent |
| |-- 4. voluntariness check->| coercion ? E003 |
|-- 5. signs -------------->|-- signatures, witness --->| |
| | |-- validateInformedConsent
| | | isValid && score >= 0.8
|<-- 6. copy of signed form ------------------------------| |
| | |-- store consent record, audit entryapproved, not expired, and that the form about to be presented is the approved version. Presenting a superseded form is one of the most common findings in consent audits, and it is entirely preventable in software.ComprehensionAssessment.method. BIO-018 sets the pass mark at 0.80; below it, the SDK raises a violation that corresponds to error code E002, whose prescribed action is to re-educate and reassess. The record should keep every attempt, not only the passing one, together with the items that were re-explained.ParticipantCapacity band. For diminished or severely-impaired, the SDK treats a missing LAR signature as a violation (E004: obtain LAR consent), and the participant's assent should still be sought where they are able to give it. For borderline capacity the SDK adds a warning and recommends periodic reassessment.E003, and the action is to remove the pressure and allow time rather than to proceed with a note.full or comprehension is below 0.85, and when a witness is present but has not signed, the SDK treats that as a violation whenever capacity is not full or comprehension is below 0.90. These thresholds are the SDK's design choices; local rules on witnesses (for example, for participants who cannot read) must be configured alongside them.validateInformedConsent; the consent is accepted only if isValid is true, which requires no violations and a compliance score of at least 0.80. The participant receives a copy of the signed form, and the consent record and an audit entry are written.Two refinements are worth building in from the start. First, the validation call should happen before the participant leaves, not in an overnight batch; a missing witness signature discovered the next day often cannot be repaired honestly. Second, when an amendment changes the consent form in a way that could affect a participant's willingness to continue, such as a new risk, the system should list the participants who signed an earlier version and track their re-consent as a new consent record, not as an edit to the old one.
Once a study is under way, the main evidence that it remains acceptable comes from safety reporting. BIO-018 models an adverse event with the AdverseEvent record (Chapter 4) and a departure from the approved protocol with ProtocolDeviation. Getting the reporting right depends on keeping four properties of an event apart, which the standard's own summary table tends to blur.
| Property | Question it answers | In BIO-018 | Note |
|---|---|---|---|
| Severity | How intense is the event? | severity: mild, moderate, severe, life-threatening, fatal | A severe headache is intense but usually not serious |
| Seriousness | Does it meet the regulatory definition of serious (death, life-threatening, hospitalisation, persistent disability, congenital anomaly, other important medical event)? | Not a separate field | Seriousness, not severity, drives expedited reporting under ICH E2A; add a serious flag |
| Causality | Is the intervention a plausible cause? | causality: unrelated, unlikely, possible, probable, definite | Map possible and above to "suspected" for regulatory reporting unless local rules differ |
| Expectedness | Is the event consistent with the known risk information (for example, the investigator's brochure)? | Not a field | Required to identify unexpected suspected serious reactions; add an expected flag and the reference document version |
Spec §4.5 prints a single schedule: fatal or life-threatening events in 24 hours, serious in 7 days, unexpected in 15 days, others in 30 days. That table is not a regulatory schedule of any jurisdiction, and its categories overlap (an event can be serious and unexpected at the same time). It is best treated as an example internal policy for how quickly investigators should notify their own study team and sponsor. The clocks that carry legal weight depend on who is reporting to whom, and they must be configured per jurisdiction.
| Reporting path | Rule (for orientation; verify current text) | Starts when |
|---|---|---|
| Investigator to sponsor, serious adverse event | Immediately (US 21 CFR 312.64(b); ICH E6 investigator responsibilities), followed by a detailed report | Investigator becomes aware |
| Sponsor to FDA, unexpected fatal or life-threatening suspected adverse reaction (IND) | No later than 7 calendar days (21 CFR 312.32(c)(2)) | Sponsor's initial receipt of the information |
| Sponsor to FDA, other serious and unexpected suspected adverse reactions (IND) | No later than 15 calendar days (21 CFR 312.32(c)(1)) | Sponsor determines the information qualifies |
| Sponsor to EU database, SUSARs (EU CTR 536/2014, Art. 42) | Fatal or life-threatening: no later than 7 days; others: no later than 15 days | Sponsor becomes aware |
| Investigator to IRB, unanticipated problems and serious events | Institution-specific (US regulations require "prompt" reporting without a fixed number of days) | Defined in the IRB's written procedures |
| Korea and other jurisdictions | Set by the national regulator and the institution's IRB procedures; configure from the current text | As defined locally |
In software, the safest model is a reporting matrix keyed on the jurisdiction and the recipient, which computes due dates from the moment of awareness and records when each report was actually sent. The AdverseEvent type has only one reportedToIRB flag and one reportDate, which cannot represent parallel reports to a sponsor, a regulator and an IRB. The example below extends the record for that purpose; the extra fields are the book's recommendation.
{
"eventId": "AE-2026-0042",
"participantId": "P-10417",
"studyId": "STUDY-GT-007",
"description": "Grade 3 elevation of liver enzymes on day 14 (example record)",
"onsetDate": "2026-03-02T00:00:00Z",
"severity": "severe",
"causality": "possible",
"outcome": "recovering",
"actionsTaken": ["study drug interrupted", "hepatology consult"],
"reportedToIRB": true,
"reportDate": "2026-03-05T09:30:00Z",
"serious": true,
"seriousnessCriteria": ["hospitalisation"],
"expected": false,
"referenceSafetyInformation": "IB v4.1",
"awareAt": "2026-03-03T16:10:00Z",
"reports": [
{ "to": "sponsor", "rule": "immediate", "dueAt": "2026-03-03T16:10:00Z", "sentAt": "2026-03-03T17:05:00Z" },
{ "to": "IRB", "rule": "irb-sop-5bd", "dueAt": "2026-03-10T23:59:00Z", "sentAt": "2026-03-05T09:30:00Z" },
{ "to": "regulator", "rule": "US-IND-15d", "dueAt": null, "sentAt": null, "owner": "sponsor" }
]
}
The IRB rule shown as irb-sop-5bd (five business days) is a placeholder for whatever the institution's written procedures say, and the regulator row is left to the sponsor, whose clock starts on its own receipt. The point of the structure is that each report has a named rule, a computed deadline and an actual send time, so a late report is visible as data rather than discovered by an auditor.
A ProtocolDeviation is classified as major or minor and carries a participantImpact from none to significant, the corrective actions and a reportedToIRB flag. BIO-018 does not define the boundary between major and minor. A workable rule, consistent with common IRB practice, is to treat a deviation as major if it affected participants' rights, safety or welfare, or the integrity of the data, and to report major deviations to the IRB on the same kind of clock as unanticipated problems. Enrolling a participant with the wrong consent version, or before a required witness signed, is a major deviation by that rule even if no harm followed, because it goes to the validity of consent itself. Minor deviations are usually logged and summarised at continuing review.
Deviations and adverse events feed back into the lifecycle. A cluster of related events may trigger an amendment, which reopens review (6.3); a new risk added to the consent form triggers re-consent (6.5); and a pattern of major deviations at one site is exactly what an audit (6.7) is designed to find.
Approval is granted on the basis of what was known at the time. Continuing oversight exists because that knowledge changes: events accumulate, the literature moves, staff turn over and forms are amended. BIO-018 addresses this in three places: continuing review by the IRB (§4.4), routine monitoring by the study team (§9.2), and audits (§9.3).
§4.4 requires review at least annually, more often for high-risk studies or after adverse events or deviations, and asks for progress reports, adverse event summaries, updated consent forms, amendments and re-approval before continuation. The annual rule needs the qualification already noted in Chapter 2: the 2018 revision of the US Common Rule removed routine continuing review for most minimal-risk studies eligible for expedited review and for studies that have progressed to data analysis only, unless the IRB decides otherwise, while FDA-regulated clinical investigations still require review at least once a year. A BIO-018 system should therefore hold the review interval as a per-protocol value set by the IRB at approval, with annual review as the conservative default, and should derive expirationDate from it.
The monitoring and audit intervals in §9.2 and §9.3 are the standard's defaults. They are reasonable starting points, but none of them is a legal requirement in itself, and a risk-based monitoring plan agreed with the sponsor and IRB may justify different intervals.
| Activity | BIO-018 default | What is examined | Record produced |
|---|---|---|---|
| Consent quality review | Monthly sample of consents (§9.2) | Correct form version, all signatures and dates, comprehension attempts, LAR and witness where required | Sampling log; findings as AuditResult entries |
| Adverse event monitoring | Real time (§9.2) | Each event's seriousness, causality, expectedness and report deadlines | AdverseEvent with report trail |
| Protocol compliance | Quarterly audits (§9.2) | Eligibility, visit schedule, deviations and their handling | AuditResult |
| Data security | Continuous (§9.2) | Access logs, encryption status, sharing requests | Security events; see Chapter 7 |
| Participant satisfaction | Semi-annual surveys (§9.2) | Participants' experience of consent and study burden | Survey summary for continuing review |
| Internal audit | Quarterly (§9.3) | The §9.3 scope below | AuditResult with complianceScore |
| External audit | Annually or as sponsors or regulators require (§9.3) | The same scope, by an independent party | AuditResult, response plan |
The §9.3 audit scope names six areas: informed consent documentation, IRB correspondence, protocol adherence, data integrity, safety reporting and regulatory compliance. Each maps onto records introduced in this chapter, which is the practical payoff of the gate-and-record approach: an auditor can reconstruct any participant's path from the approved protocol version, through the consent record and its validation result, to every event and deviation, without relying on anyone's memory. AuditResult grades each finding as critical, major or minor and sets followUpRequired; Chapter 8 discusses how to turn those findings into conformance evidence.
At close-out, the investigator submits a final report, the IRB closes the submission, and the retention clock starts. Spec §3.2.2 states a minimum of seven years after study completion. There is no single universal retention period, and the correct value depends on the kind of study and the jurisdiction, so it must be configurable.
| Rule | Records concerned | Retention |
|---|---|---|
| US Common Rule, 45 CFR 46.115(b) | IRB records | At least 3 years after completion of the research |
| US FDA, 21 CFR 312.62(c) | Investigator records for drug studies under an IND | 2 years after marketing approval, or after the investigation is discontinued and FDA notified |
| EU CTR 536/2014, Art. 58 | Clinical trial master file | At least 25 years after the end of the trial, unless other EU law requires longer |
| BIO-018 §3.2.2 | Consent documents | Minimum 7 years (the standard's floor; apply the longest applicable rule) |
| Other jurisdictions, including Korea | As defined by national law and institutional procedures | Configure from the current text |
When several rules apply to the same record, the longest governs. When personal data are involved, retention also has an upper bound: data protection law such as the GDPR expects data to be kept no longer than necessary for the purpose. A good retention design therefore stores, for each record, which rule set its period and when it becomes eligible for review for deletion, rather than a bare date.
The ethics review protocol is a chain of gates, each closed by a record. The pre-study checklist gates the start of the study. Review-level routing is a proposal that must be confirmed by a person, particularly for exemptions and for the "minor increase" band that the SDK routes to expedited review against US rules. The submission state machine ensures that only a current, unconditional approval permits enrolment, and that approvals are never edited in place. Convened meetings are valid only if quorum, a non-scientist and, under BIO-018, a community member remain after recusals. Consent is executed in a fixed order and validated before the participant leaves. Safety events are described by severity, seriousness, causality and expectedness, and reported on clocks that belong to the jurisdiction, not to the table in §4.5. Continuing review, monitoring and audits keep the approval honest, and retention follows the longest applicable rule.
Chapter 7 turns these processes into a running system: the six required components of spec §8.1, the audit trail that makes every gate verifiable, and the integration with clinical-trial and hospital systems.
minor-increase with no vulnerable populations. What does the SDK propose, and why should a system operating under the US Common Rule not accept that proposal automatically?studyType an unsafe basis for an exemption proposal? Give an example of a false positive.status should a submission have after the decision approved-with-modifications, and when may enrolment begin?