제6장
연구 한 건이 WIA-BIO-018 안에서 계획서 초안부터 종료까지 어떤 길을 걷는지 다룬다. 어느 심의 수준으로 배정되는지, 제출 기록이 어떤 상태를 거치는지, 위원회가 어떻게 회의하는지, 동의가 현장에서 어떤 순서로 이루어지는지, 그리고 승인 이후 이상사례 보고와 감사가 그 승인을 어떻게 유효하게 유지하는지를 살핀다.
제2장은 인간대상연구 보호의 제도를 다루었다. 동의서가 무엇을 설명해야 하는지, IRB에 누가 참여하는지, 위원회가 승인 전에 무엇을 판단해야 하는지가 그 내용이었다. 제4장과 제5장은 그 규칙을 기록과 SDK 함수로 옮겼다. 이 장은 두 관점을 시간 축 위에서 잇는다. 윤리 승인은 한 번의 사건이 아니라 과정이다. 첫 참여자에게 접근하기 전에 시작되고, 마지막 기록이 적용 법령이 요구하는 기간만큼 보관된 뒤에야 끝난다. WIA-BIO-018은 각 단계의 결정을 이름이 확인되는 사람이 내리고, 그 결정을 기록으로 남기며, 그 시점에 유효했던 계획서와 동의서의 판(version)에 연결하기를 요구한다.
이 장은 그 시간 순서를 따라간다. 각 단계마다 표준(명세서 §3.2, §4.3–§4.5, §9.1–§9.3)이 요구하는 것, 참조 SDK(index.ts의 submitIRBProtocol과 보조 함수)가 실제로 하는 일, 그리고 둘이 원래 따르려던 규정과 어긋나는 지점을 밝힌다. 모니터링 주기나 보고 기한처럼 표준이 제시한 수치가 법적 규칙이 아니라 설계상의 선택인 경우에는 그렇다고 적고, 구현자가 대신 설정해야 할 관할 규정을 제시한다.
BIO-018에서 인간대상연구 한 건은 여덟 단계를 거친다. 단계와 단계 사이의 경계는 관문이다. 현재 단계를 닫는 기록이 존재하지 않으면 소프트웨어상으로도 다음 단계에 들어갈 수 없어야 한다. 제1장에서 말한 "기계가 확인할 수 있는 윤리"의 실제 의미가 바로 이것이다.
| # | 단계 | 하는 일 | 단계를 닫는 기록 | 관문 책임자 |
|---|---|---|---|---|
| 1 | 설계 | 연구자가 계획서를 쓰고 위험과 이익을 식별하며 대상 집단을 정한다 | IRBProtocol 초안, RiskBenefitAnalysis | 연구책임자 |
| 2 | 연구 전 점검 | 명세서 §9.1의 8개 항목을 갖춘다(아래 참조) | 증거 링크가 달린 점검 기록 | 연구 코디네이터 |
| 3 | 제출 | 계획서를 제출하고 심의 수준을 제안받는다 | status: 'submitted'인 IRBSubmission | IRB 사무국 |
| 4 | 심의 | 면제 판정, 신속 심의위원 또는 소집 위원회가 결정한다 | IRBSubmission.decision, rationale, expirationDate | IRB 위원장 또는 위원회 |
| 5 | 동의 | 참여자마다 설명·평가·서명을 진행한다 | 참여자별 InformedConsent | 동의를 받는 사람 |
| 6 | 연구 수행 | 중재, 자료 수집, 안전성 보고 | AdverseEvent, ProtocolDeviation | 연구자, 의뢰자 |
| 7 | 지속 감시 | 지속 심의, 모니터링, 감사 | 갱신된 승인, AuditResult | IRB, 품질보증 부서 |
| 8 | 종료와 보관 | 최종 보고, 기록 보존, 보관 기간 기산 | 종료 보고서, 보관 일정 | 연구자, 기관 |
명세서 §9.1은 연구 시작 전에 갖추어야 할 8개 항목을 나열한다. 점검표로 읽으면 행정 절차처럼 보이지만, 관문으로 읽으면 6단계가 시작될 수 있는지를 결정하는 조건이다. 따라서 각 항목은 체크 표시가 아니라 증거를 가리켜야 한다.
| §9.1 항목 | 시스템이 보유해야 할 증거 | 해당 기록을 정의한 장 |
|---|---|---|
| IRB 승인 획득 | 승인 결정과 미래 시점의 expirationDate를 가진 IRBSubmission(또는 문서화된 면제 판정) | 이 장 6.3절 |
| 동의서 승인 | 동의서 양식 ID와 판, 그리고 승인 결정과의 연결 | 제4장 |
| 동의 절차 문서화 | 누가 어떤 환경에서 동의를 받는지, 어떤 이해도 평가 방법을 쓰는지, 언제 입회인이나 법정대리인이 참여하는지 | 이 장 6.5절 |
| 데이터 보안 계획 이행 | 자료 유형별 보호 수준, 암호화와 접근 통제 설정 | 제3장, 제7장 |
| 이상사례 보고 계획 수립 | 해당 연구의 관할에 맞게 설정한 보고 행렬 | 이 장 6.6절 |
| 연구진 교육 완료 | 업무 위임 목록에 오른 모든 사람의 교육 기록 | 제7장 |
| 취약 집단 보호 조치 마련 | 포함된 집단별로 IRB가 요구한 추가 보호 조치 | 제2장 |
| 위험-이익 분석 문서화 | RiskBenefitAnalysis 기록과 심의위원의 서술 의견 | 제4장, 제5장 |
이 가운데 두 항목은 "문서가 있다"보다 강한 확인이 필요하다. 참여자를 등록하는 바로 그날에도 승인이 유효해야 하고, 참여자가 서명하는 동의서는 위원회가 승인한 판이어야 한다. 두 조건은 말하기는 쉽지만 계획서 변경이 쌓이기 시작하면 어기기도 쉽다. 6.3절과 6.5절이 이 문제로 다시 돌아오는 이유이다.
계획서의 과학적 내용을 누군가 읽기 전에, IRB 사무국은 먼저 얼마나 강한 심의가 필요한지를 정한다. BIO-018 §4.3은 세 수준(exempt, expedited, full-board)을 정의하고, SDK의 submitIRBProtocol은 계획서의 두 필드, 곧 riskLevel과 participants.vulnerablePopulations로부터 수준 하나를 제안한다. 알고리즘의 핵심은 옮겨 적을 수 있을 만큼 짧다.
// 참조 SDK, BioEthicsSDK.submitIRBProtocol (요약)
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'; // 최소 위험 초과, 고위험, 또는 취약 집단 포함
}
// isExemptEligible: studyType 문자열에 아래 구절 중 하나가 들어 있어야 한다
// 'educational research', 'anonymous surveys',
// 'observation of public behavior', 'existing de-identified data'
이 배정 규칙은 결정표로 정리할 수 있다. RiskLevel은 네 값을 가지며(제4장), hasVulnerablePopulations는 배열이 존재하고 비어 있지 않으면 참이다.
riskLevel | 취약 집단 기재 | studyType이 면제 구절과 일치 | SDK 제안 | 비고 |
|---|---|---|---|---|
minimal | 없음 | 예 | exempt | 제안일 뿐이며 면제 판정은 기관이 한다 |
minimal | 없음 | 아니오 | expedited | 미국 실무에서는 공표된 신속 심의 범주에도 해당해야 한다 |
minor-increase | 없음 | 해당 없음 | expedited | 최소 위험에만 신속 심의를 허용하는 규정과 충돌한다(아래 참조) |
minimal 또는 minor-increase | 있음 | 해당 없음 | full-board | 일부 규정보다 엄격하며, 표준의 의도적 선택이다 |
greater-than-minimal 또는 high | 무관 | 해당 없음 | full-board | 규정과 일치한다 |
실무에서 중요한 차이는 세 가지이다. 첫째, "최소 위험을 약간 초과"라는 수준은 미국의 아동 대상 연구 규정(45 CFR 46.406)에서 온 개념이다. 거기서는 추가 조건을 충족할 때만 승인할 수 있는 연구를 가리키며, 공통규칙상 소집 위원회가 심의한다. 공통규칙(45 CFR 46.110)과 FDA 규정(21 CFR 56.110) 모두 신속 심의를 최소 위험 이하이면서 공표된 범주 목록에 해당하는 연구에만 허용한다. 따라서 minor-increase 계획서를 신속 심의로 보내는 것은 미국 규정을 충실히 옮긴 것이 아니다. 이 규정 아래에서 운영하는 구현자는 minor-increase를 full-board로 보내거나, 최소한 사람의 확인을 강제해야 한다.
둘째, 면제 판단이 자유 텍스트 필드에 대한 부분 문자열 일치에 기대고 있다. 연구 유형을 "non-anonymous surveys"(비익명 설문)라고 적으면 "anonymous surveys"라는 구절을 포함하므로 면제로 제안된다. 반대로 "questionnaire (anonymous)"라고 적으면 면제 후보에서 빠진다. 자유 텍스트는 규제 분류의 입력으로 적합하지 않다. 면제 범주는 연구자가 고르고 IRB 사무국이 확인하는 코드값으로 저장하고, 자유 텍스트는 설명으로만 다루는 설계가 낫다.
셋째, CLI(wia-bio-018 submit-irb)는 SDK와 다른 규칙을 구현한다. 최소 위험이고 취약 집단이 없는 계획서를 모두 expedited로 보내며 exempt는 한 번도 제안하지 않는다. 또한 표준 어디에도 정의되지 않은 예상 처리 기간을 출력한다. 따라서 표준의 배정 규칙을 재현해야 하는 시험이나 시연에서는 CLI가 아니라 SDK를 호출해야 한다.
어떤 알고리즘을 쓰든 심의 수준은 제안이지 판정이 아니다. 규정은 그 결정을 기관에 맡긴다. 연구자는 자기 연구를 스스로 면제로 선언할 수 없고, 판단이 서지 않는 지명 심의위원은 언제든 계획서를 정규 심의로 넘길 수 있다. 따라서 BIO-018에 부합하는 시스템은 세 가지를 저장해야 한다. 알고리즘이 제안한 수준, 이름이 확인되는 IRB 담당자나 위원장이 배정한 수준, 그리고 둘이 다를 때의 사유이다. 아래 래퍼는 그 설계의 골격이며, 참조 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('취약 집단 포함: BIO-018은 정규 심의를 요구한다');
return { proposed: 'full-board', reasons, requiresHumanConfirmation: false };
}
if (p.riskLevel === 'greater-than-minimal' || p.riskLevel === 'high') {
reasons.push(`위험 수준 ${p.riskLevel}`);
return { proposed: 'full-board', reasons, requiresHumanConfirmation: false };
}
if (p.riskLevel === 'minor-increase') {
// 45 CFR 46.110 / 21 CFR 56.110: 신속 심의는 최소 위험에 한정된다
const level = j.startsWith('US') ? 'full-board' : 'expedited';
reasons.push('최소 위험을 약간 초과: 현지 규정에 따라 수준을 확인할 것');
return { proposed: level, reasons, requiresHumanConfirmation: true };
}
// 최소 위험, 취약 집단 없음
const sdkLevel = new BioEthicsSDK().submitIRBProtocol(p).reviewLevel;
reasons.push(`최소 위험에 대한 SDK 제안: ${sdkLevel}`);
return { proposed: sdkLevel, reasons, requiresHumanConfirmation: sdkLevel === 'exempt' };
}래퍼가 최소 위험의 경우에는 여전히 SDK를 호출한다는 점에 주목하자. 표준이 타당한 곳에서는 표준과 어긋나지 않게 하기 위해서이다. 사람의 결정을 요구하는 것은 규정이 그 결정을 기관에 유보해 둔 두 상황, 곧 면제와 최소 위험 바로 위의 회색 지대뿐이다.
제출된 계획서는 IRBSubmission 기록이 되고, 그 status 필드가 심의 진행 위치를 나타낸다. types.ts의 타입은 submitted, under-review, approved, revisions-required, rejected, withdrawn의 여섯 값을 허용한다. (명세서 §8.2.3에 실린 짧은 인터페이스에는 withdrawn이 없다. 둘 중 TypeScript 타입이 더 완전하므로 여기서는 그것을 따른다.) SDK는 기록을 submitted 상태로 만들 뿐이며, 이후의 모든 전이는 기관의 업무 흐름에 맡긴다.
submitIRBProtocol()
|
v
+-------------+ 연구자 철회
| submitted |-----------------------------+
+-------------+ |
| 사무국 검토, 심의위원 배정 |
v v
+--------------+ 철회 +-------------+
+----->| under-review |-------------------->| withdrawn |
| +--------------+ +-------------+
| | | \
| | | \ 위원회 불승인
| v v v
| +-----------+ +--------------------+ +-----------+
| | approved | | revisions-required | | rejected |
| +-----------+ +--------------------+ +-----------+
| | |
| | | 연구자 재제출
+--------+-----------------+
변경 심의 또는 지속 심의
(새 심의 주기)
이 도식은 타입만으로는 드러나지 않는 두 가지 관례를 더한다. 승인된 계획서는 그 자리에서 under-review로 되돌아가지 않는다. 변경이나 지속 심의는 승인 기록을 참조하는 새 심의 주기를 열며, 그래야 무엇이 언제 승인되었는지의 이력이 덮어쓰이지 않는다. 또한 rejected와 withdrawn은 종결 상태이다. 불승인된 연구를 다시 설계하면 새 제출로 들어온다.
decision 필드는 다른 어휘인 IRBDecision을 쓰며 다섯 값을 가진다. 그중 두 값은 같은 이름의 상태가 없으므로 명시적인 대응 규칙이 필요하다. 아래 대응표는 일반적인 IRB 실무를 따른 이 책의 권고안이다.
IRBDecision | 의미 | 결과 status | 함께 기록할 것 |
|---|---|---|---|
approved | 제출된 그대로 승인 | approved | reviewDate, 지속 심의 대상이면 expirationDate |
approved-with-modifications | 위원장이나 지명자가 확인할 수 있는 구체적이고 경미한 수정을 조건으로 승인 | 수정 확인 전까지 revisions-required, 확인 후 approved | modifications[], 수정을 확인한 사람 |
revisions-required | 실질적 수정이 필요하며 수정본을 다시 심의 | revisions-required | modifications[], rationale |
deferred | 정보나 전문성 부족 등으로 위원회가 결정하지 못함 | under-review 유지 | rationale, 재상정할 회의 |
rejected | 불승인 | rejected | rationale, 연구자에게 통지하고 소명 기회 부여 |
가장 중요한 안전 속성은 status가 approved인 동안에만, 그리고 expirationDate가 있다면 그 날짜 이전에만 참여자를 등록할 수 있다는 것이다. 조건부 승인은 조건이 충족되기 전까지 승인이 아니다. 참여자를 등록하는 소프트웨어는 연구 개시 시점에 저장해 둔 플래그를 믿지 말고, 등록하는 순간마다 두 조건을 모두 확인해야 한다.
모든 연구에 만료일이 있는 것은 아니므로 타입에서 expirationDate는 선택 필드이다. 지속 심의가 필요한 연구(6.7절)에서는 그 날짜에 승인이 소멸하며, 이 소멸은 형식에 그치지 않는다. 미국 규정에서는 승인이 만료되면 연구 활동을 멈추어야 하고, 이미 등록된 참여자에게 중재를 계속하는 것이 그들의 최선의 이익이라고 IRB가 판단한 경우만 예외이다. 시스템은 만료 훨씬 전에 경고하고, 만료일이 지나면 신규 등록을 막아야 한다.
SDK는 제출 ID를 IRB- 뒤에 밀리초 단위 타임스탬프와 짧은 난수 문자열을 붙여 만든다. 읽기에는 편하지만 클라이언트에서 생성되며 유일성이나 순서를 보장하지 않는다. 운영 환경에서 공식 식별자는 IRB 자체 시스템이 발급하게 하고, SDK 형식의 ID는 연계 키로만 보관해야 한다.
full-board로 배정된 계획서는 소집된 회의에서 결정된다. BIO-018 §4.3.3은 네 조건을 둔다. 재적 위원 과반수의 정족수, 비과학계 위원의 출석, 지역사회 위원의 출석, 과반수 찬성이다. §4.1은 이해상충이 있는 위원과 자기 연구를 심의하는 위원의 참여를 금지한다. 이 조건들은 모두 표결을 기록하는 순간 소프트웨어로 확인할 수 있다.
| 규칙 | BIO-018 근거 | 확인 방법 | 규정상 유의점 |
|---|---|---|---|
| 정족수: 재적 위원 과반수 출석 | §4.3.3 | 출석하고 참여 자격이 있는 위원 수 > 표결권 있는 재적 위원의 절반 | 미국 공통규칙 45 CFR 46.108(b)도 같은 과반수 기준을 쓴다 |
| 비과학계 위원 출석 | §4.3.3 | 주된 관심사가 비과학적인 적격 위원이 1인 이상 | 46.108(b)상 회의가 의결하기 위한 요건이다 |
| 지역사회(기관 외부) 위원 출석 | §4.3.3 | 기관에 소속되지 않은 적격 위원이 1인 이상 | 미국 규정은 그런 위원을 위원회에 두도록 요구하지만(46.107(d)) 매 회의 출석까지는 요구하지 않는다. BIO-018이 더 엄격하다 |
| 과반수 찬성 | §4.3.3 | 찬성 수 > 출석한 적격 위원의 절반 | 공통규칙: 회의에 출석한 위원의 과반수 |
| 이해상충 회피 | §4.1 | 이해상충 위원은 토의와 표결 동안 퇴장하고 정족수 계산에서 제외 | 46.107(e): IRB가 요청한 정보는 제공할 수 있으나 심의에는 참여할 수 없다 |
| 최소 월 1회 회의 | §4.3.3 | 위원회별 설정값 | 보편적 규칙이 아닌 운영상 선택이며, 위원회는 업무량에 따라 일정을 정한다 |
회피는 정족수와 맞물려 놓치기 쉬운 결과를 낳는다. 표결권 있는 위원이 9명이고 그중 7명이 출석한 가상의 위원회를 생각해 보자. 7은 9의 절반보다 크므로 회의는 성립한다. 출석 위원 중 2명이 어느 계획서 의뢰자와 재정적 이해관계가 있다면 그 안건 동안 퇴장하고, 적격 위원은 5명이 남는다. 5는 여전히 4.5보다 크므로 안건을 다룰 수 있고, 승인에는 찬성 3표 이상이 필요하다. 이해상충 위원이 한 명 더 있다면 적격 위원은 4명이 되어 그 안건에 대해서는 정족수가 무너지고, 위원회는 결정을 보류해야 한다. 유일한 비과학계 위원이 이해상충 당사자인 경우도 마찬가지이다. 회의실에 위원이 충분히 있어도 그 안건은 의결할 수 없다.
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('회피 후 정족수 미달');
if (!eligible.some(m => m.nonScientist)) problems.push('적격 비과학계 위원 없음');
if (!eligible.some(m => m.unaffiliated)) problems.push('적격 지역사회 위원 없음(BIO-018 규칙)');
return { ok: problems.length === 0, eligibleCount: eligible.length, problems };
}
function isApproved(votesFor: number, eligibleCount: number): boolean {
return votesFor * 2 > eligibleCount; // 출석한 적격 위원의 과반수
}
소집 회의의 회의록도 감사자가 요구하는 기록이다(6.7절). 회의록에는 안건마다 출석자, 회피자와 그 사유, 표결 수(찬성·반대·기권), 결정, 요구한 수정의 근거, 그리고 취약 집단 연구라면 규정이 요구하는 구체적 판단이 담겨야 한다. 이 항목들을 구조화된 데이터로 남기면 감사 시점에 canActOnItem 확인을 다시 실행해, 모든 결정이 적법하게 구성된 위원회에서 내려졌음을 보일 수 있다.
IRB 승인은 참여자에게 접근해도 된다는 허가일 뿐 그들의 동의를 대신하지 않는다. 동의는 참여자마다 한 번 실행되며, 이미 등록된 사람에게 의미 있는 방식으로 승인 동의서가 바뀔 때마다 다시 실행된다. 표준은 단계의 순서를 명시하지 않지만 규칙들이 하나의 순서를 함축하고, SDK의 validateInformedConsent는 각 단계의 결과를 확인한다. 아래 순서도는 그 함축된 순서를 드러낸 것이다.
참여자 동의를 받는 사람 eConsent 시스템 IRB 기록
| | | |
| |-- 승인 확인 --------------+---------------------->|
| |<-- 승인됨, 동의서 vN, 미만료 ---------------------|
|<-- 1. 설명 (동의서 vN) ---| | |
|-- 질문, 답변 ------------>| | |
|<-- 2. 이해도 확인 --------|-- 점수 기록 ------------->| |
| | 점수 < 0.80 ? E002: 재교육 후 재평가 |
|<-- 틀린 항목 재설명 ------| | |
| |-- 3. 능력 구간 ---------->| |
| | diminished / severely-impaired ? E004 |
| | 법정대리인 동의 + 참여자 assent |
| |-- 4. 자발성 확인 -------->| 강압 ? E003 |
|-- 5. 서명 -------------->|-- 서명, 입회인 ------------>| |
| | |-- validateInformedConsent
| | | isValid && score >= 0.8
|<-- 6. 서명된 동의서 사본 ------------------------------| |
| | |-- 동의 기록 저장, 감사 기록approved이고 만료되지 않았는지, 제시하려는 동의서가 승인된 판인지를 확인한다. 폐기된 판의 동의서를 제시하는 것은 동의 감사에서 가장 흔한 지적 사항 가운데 하나이며, 소프트웨어로 완전히 막을 수 있다.ComprehensionAssessment.method의 방법 중 하나로 이해도를 측정한다. BIO-018의 통과 기준은 0.80이며, 그보다 낮으면 SDK는 오류 코드 E002에 해당하는 위반을 기록한다. 규정된 조치는 재교육 후 재평가이다. 기록에는 통과한 시도만이 아니라 모든 시도와 다시 설명한 항목을 남겨야 한다.ParticipantCapacity 구간을 기록한다. diminished나 severely-impaired인데 법정대리인 서명이 없으면 SDK는 이를 위반으로 본다(E004: 법정대리인 동의 확보). 이때도 참여자가 가능한 범위에서 assent를 구해야 한다. borderline이면 SDK는 경고를 남기고 주기적 재평가를 권고한다.E003에 해당하며, 조치는 메모를 남기고 진행하는 것이 아니라 압력을 제거하고 시간을 주는 것이다.full이 아니거나 이해도가 0.85 미만이면 입회인이 필요하고, 입회인이 있는데 서명하지 않은 경우에는 능력이 full이 아니거나 이해도가 0.90 미만일 때 위반으로 처리한다. 이 기준값들은 SDK의 설계 선택이므로, 글을 읽지 못하는 참여자에 대한 입회인 요건 같은 현지 규칙을 함께 설정해야 한다.validateInformedConsent를 호출하고, isValid가 참일 때만 동의를 받아들인다. 이는 위반이 없고 준수 점수가 0.80 이상이어야 한다는 뜻이다. 참여자는 서명된 동의서 사본을 받고, 동의 기록과 감사 기록이 저장된다.처음부터 넣어 둘 만한 개선이 두 가지 있다. 첫째, 검증 호출은 야간 일괄 처리가 아니라 참여자가 자리를 뜨기 전에 이루어져야 한다. 다음 날 발견된 입회인 서명 누락은 정직한 방법으로 바로잡기 어려운 경우가 많다. 둘째, 새로운 위험의 추가처럼 참여자의 계속 참여 의사에 영향을 줄 수 있는 방식으로 변경이 동의서를 바꾸면, 시스템은 이전 판에 서명한 참여자 목록을 뽑고 그들의 재동의를 옛 기록의 수정이 아니라 새 동의 기록으로 추적해야 한다.
연구가 진행되면, 그 연구가 여전히 수용 가능하다는 주된 근거는 안전성 보고에서 나온다. BIO-018은 이상사례를 AdverseEvent 기록(제4장)으로, 승인된 계획서에서 벗어난 일을 ProtocolDeviation으로 모델링한다. 보고를 올바르게 하려면 사건의 네 가지 속성을 구분해야 하는데, 표준 자체의 요약표는 이를 흐리는 경향이 있다.
| 속성 | 답하는 질문 | BIO-018에서 | 비고 |
|---|---|---|---|
| 중증도(severity) | 사건이 얼마나 강한가? | severity: mild, moderate, severe, life-threatening, fatal | 심한 두통은 강도가 높지만 대개 중대하지는 않다 |
| 중대성(seriousness) | 사망, 생명 위협, 입원, 지속적 장애, 선천적 기형, 기타 중요한 의학적 사건 등 규제상 "중대"의 정의에 해당하는가? | 별도 필드 없음 | ICH E2A에서 신속 보고를 결정하는 것은 중증도가 아니라 중대성이다. serious 플래그를 추가할 것 |
| 인과관계 | 중재가 원인일 가능성이 있는가? | causality: unrelated, unlikely, possible, probable, definite | 현지 규칙이 달리 정하지 않으면 possible 이상을 규제 보고상의 "의심"으로 대응시킨다 |
| 예측 가능성(expectedness) | 연구자 자료집 등 기존 위험 정보와 일치하는가? | 필드 없음 | 예상하지 못한 중대한 의심 이상반응을 가려내려면 필요하다. expected 플래그와 참조 문서 판을 추가할 것 |
명세서 §4.5는 사망·생명 위협 24시간, 중대 7일, 예상하지 못한 사건 15일, 기타 30일이라는 단일 일정표를 싣고 있다. 이 표는 어느 관할의 규제 일정도 아니며, 범주가 서로 겹친다(한 사건이 중대하면서 예상하지 못한 것일 수 있다). 연구자가 자기 연구팀과 의뢰자에게 얼마나 빨리 알려야 하는지에 관한 기관 내부 정책의 예시로 보는 것이 가장 적절하다. 법적 효력이 있는 기한은 누가 누구에게 보고하느냐에 따라 달라지며, 관할별로 설정해야 한다.
| 보고 경로 | 규칙(방향 잡기용이며 현행 조문을 확인할 것) | 기산 시점 |
|---|---|---|
| 연구자 → 의뢰자, 중대한 이상사례 | 즉시(미국 21 CFR 312.64(b), ICH E6 연구자 책임), 이후 상세 보고 | 연구자가 인지한 때 |
| 의뢰자 → FDA, 예상하지 못한 사망·생명 위협 의심 이상반응(IND) | 7일(역일) 이내(21 CFR 312.32(c)(2)) | 의뢰자가 정보를 처음 받은 때 |
| 의뢰자 → FDA, 그 밖의 중대하고 예상하지 못한 의심 이상반응(IND) | 15일(역일) 이내(21 CFR 312.32(c)(1)) | 의뢰자가 보고 대상임을 판단한 때 |
| 의뢰자 → EU 데이터베이스, SUSAR(EU CTR 536/2014 제42조) | 사망·생명 위협: 7일 이내, 그 밖: 15일 이내 | 의뢰자가 인지한 때 |
| 연구자 → IRB, 예상하지 못한 문제와 중대 사건 | 기관별로 다르다(미국 규정은 일수를 정하지 않고 "신속한" 보고를 요구한다) | IRB의 표준운영절차에서 정한다 |
| 우리나라와 그 밖의 관할 | 국가 규제기관과 기관 IRB 절차가 정한다. 현행 조문에서 설정할 것 | 현지 규정에 따른다 |
소프트웨어에서 가장 안전한 모델은 관할과 수신자를 키로 하는 보고 행렬이다. 인지 시점에서 기한을 계산하고, 각 보고를 실제로 보낸 시각을 기록한다. AdverseEvent 타입에는 reportedToIRB 플래그 하나와 reportDate 하나만 있어서, 의뢰자·규제기관·IRB에 대한 병렬 보고를 표현할 수 없다. 아래 예시는 이를 위해 기록을 확장한 것이며, 추가 필드는 이 책의 권고안이다.
{
"eventId": "AE-2026-0042",
"participantId": "P-10417",
"studyId": "STUDY-GT-007",
"description": "14일째 3등급 간효소 상승 (예시 기록)",
"onsetDate": "2026-03-02T00:00:00Z",
"severity": "severe",
"causality": "possible",
"outcome": "recovering",
"actionsTaken": ["시험약 투여 중단", "간 전문의 협진"],
"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" }
]
}
irb-sop-5bd(영업일 5일)로 표시한 IRB 규칙은 기관의 표준운영절차가 정한 내용을 넣을 자리이다. 규제기관 행은 의뢰자에게 맡겨 두었는데, 그 기한은 의뢰자가 정보를 받은 시점부터 기산되기 때문이다. 이 구조의 요점은 보고마다 이름이 붙은 규칙, 계산된 기한, 실제 발송 시각이 있다는 것이다. 그래야 늦은 보고가 감사자에게 발견되기 전에 데이터로 드러난다.
ProtocolDeviation은 major 또는 minor로 분류되며, none부터 significant까지의 participantImpact, 시정 조치, reportedToIRB 플래그를 가진다. BIO-018은 중대(major)와 경미(minor)의 경계를 정의하지 않는다. 일반적인 IRB 실무와 부합하는 실용적 규칙은, 참여자의 권리·안전·복지나 자료의 무결성에 영향을 준 이탈을 중대한 이탈로 보고, 중대한 이탈은 예상하지 못한 문제와 같은 종류의 기한으로 IRB에 보고하는 것이다. 이 규칙에 따르면 잘못된 판의 동의서로 참여자를 등록하거나 필요한 입회인 서명 전에 등록한 것은, 해가 없었더라도 동의 자체의 유효성에 관한 문제이므로 중대한 이탈이다. 경미한 이탈은 보통 기록해 두었다가 지속 심의 때 요약해 보고한다.
이탈과 이상사례는 생애주기로 되먹임된다. 서로 관련된 사건이 몰리면 계획서 변경이 필요해지고 이는 심의를 다시 연다(6.3절). 동의서에 새 위험이 추가되면 재동의가 시작된다(6.5절). 한 기관에서 중대한 이탈이 반복되는 양상은 감사(6.7절)가 찾아내도록 설계된 바로 그것이다.
승인은 그 시점에 알려진 사실을 근거로 내려진다. 지속 감시가 필요한 이유는 그 사실이 변하기 때문이다. 사건이 쌓이고, 연구 문헌이 바뀌고, 연구진이 교체되고, 동의서가 개정된다. BIO-018은 이를 세 곳에서 다룬다. IRB의 지속 심의(§4.4), 연구팀의 일상 모니터링(§9.2), 그리고 감사(§9.3)이다.
§4.4는 최소 연 1회, 고위험 연구나 이상사례·이탈이 있을 때는 더 자주 심의하도록 요구하며, 진행 보고, 이상사례 요약, 개정 동의서, 계획서 변경, 계속 진행 전 재승인을 포함하도록 한다. 연 1회 규칙에는 제2장에서 언급한 단서가 필요하다. 미국 공통규칙 2018년 개정은 신속 심의 대상인 최소 위험 연구 대부분과 자료 분석 단계만 남은 연구에 대해, IRB가 달리 정하지 않는 한 정기적 지속 심의를 없앴다. 반면 FDA 규제 대상 임상시험은 여전히 최소 연 1회 심의가 필요하다. 따라서 BIO-018 시스템은 심의 주기를 IRB가 승인 시 정하는 계획서별 값으로 보관하고, 연 1회를 보수적 기본값으로 두며, expirationDate를 그 값에서 도출해야 한다.
§9.2와 §9.3의 모니터링·감사 주기는 표준의 기본값이다. 출발점으로는 합리적이지만 어느 것도 그 자체로 법적 요건은 아니며, 의뢰자·IRB와 합의한 위험 기반 모니터링 계획이 다른 주기를 정당화할 수 있다.
| 활동 | BIO-018 기본값 | 점검 대상 | 생성되는 기록 |
|---|---|---|---|
| 동의 품질 검토 | 매월 동의서 표본 검토(§9.2) | 올바른 동의서 판, 모든 서명과 날짜, 이해도 평가 시도, 필요한 경우 법정대리인과 입회인 | 표본 추출 기록, AuditResult 지적 사항 |
| 이상사례 모니터링 | 실시간(§9.2) | 사건별 중대성, 인과관계, 예측 가능성, 보고 기한 | 보고 이력이 달린 AdverseEvent |
| 계획서 준수 | 분기별 감사(§9.2) | 선정 기준, 방문 일정, 이탈과 그 처리 | AuditResult |
| 데이터 보안 | 상시(§9.2) | 접근 로그, 암호화 상태, 공유 요청 | 보안 이벤트(제7장 참조) |
| 참여자 만족도 | 반기별 설문(§9.2) | 동의 과정과 연구 부담에 대한 참여자의 경험 | 지속 심의용 설문 요약 |
| 내부 감사 | 분기별(§9.3) | 아래 §9.3 범위 | complianceScore가 포함된 AuditResult |
| 외부 감사 | 연 1회 또는 의뢰자·규제기관 요구 시(§9.3) | 같은 범위를 독립된 주체가 점검 | AuditResult, 대응 계획 |
§9.3의 감사 범위는 동의 문서, IRB 교신, 계획서 준수, 자료 무결성, 안전성 보고, 규제 준수의 여섯 영역이다. 각 영역은 이 장에서 소개한 기록에 대응하며, 이것이 관문과 기록 방식의 실질적 효용이다. 감사자는 누구의 기억에도 의존하지 않고, 승인된 계획서 판에서 동의 기록과 그 검증 결과를 거쳐 모든 사건과 이탈에 이르기까지 참여자 한 사람의 경로를 재구성할 수 있다. AuditResult는 지적 사항마다 critical, major, minor 등급을 매기고 followUpRequired를 설정한다. 이 지적 사항을 적합성 증거로 바꾸는 방법은 제8장에서 다룬다.
종료 시점에 연구자는 최종 보고서를 제출하고, IRB는 제출 기록을 닫으며, 보관 기간이 기산된다. 명세서 §3.2.2는 연구 종료 후 최소 7년을 제시한다. 그러나 보편적인 단일 보관 기간은 없으며, 올바른 값은 연구의 종류와 관할에 따라 달라지므로 설정 가능해야 한다.
| 규칙 | 대상 기록 | 보관 기간 |
|---|---|---|
| 미국 공통규칙, 45 CFR 46.115(b) | IRB 기록 | 연구 종료 후 최소 3년 |
| 미국 FDA, 21 CFR 312.62(c) | IND 의약품 연구의 연구자 기록 | 판매 승인 후 2년, 또는 임상시험 중단 후 FDA 통지 시점부터 2년 |
| EU CTR 536/2014 제58조 | 임상시험 마스터 파일(TMF) | 임상시험 종료 후 최소 25년(다른 EU 법이 더 긴 기간을 요구하지 않는 한) |
| BIO-018 §3.2.2 | 동의 문서 | 최소 7년(표준의 하한이며, 적용되는 가장 긴 규칙을 따를 것) |
| 우리나라를 포함한 그 밖의 관할 | 국가 법령과 기관 절차가 정하는 기록 | 현행 조문에서 설정할 것 |
한 기록에 여러 규칙이 적용되면 가장 긴 기간이 우선한다. 개인정보가 관련되면 보관에는 상한도 있다. GDPR 같은 개인정보 보호법은 목적에 필요한 기간보다 오래 보관하지 않기를 요구한다. 따라서 좋은 보관 설계는 기록마다 맨 날짜 하나가 아니라, 어떤 규칙이 기간을 정했는지와 언제부터 삭제 검토 대상이 되는지를 함께 저장한다.
윤리 심의 프로토콜은 기록으로 닫히는 관문의 사슬이다. 연구 전 점검표는 연구의 시작을 통제한다. 심의 수준 배정은 사람이 확인해야 하는 제안이며, 특히 면제와, SDK가 미국 규정과 달리 신속 심의로 보내는 "최소 위험을 약간 초과" 구간에서 그렇다. 제출 기록의 상태 기계는 유효하고 조건 없는 승인만이 등록을 허용하며 승인이 그 자리에서 수정되지 않도록 보장한다. 소집 회의는 회피 후에도 정족수, 비과학계 위원, 그리고 BIO-018에서는 지역사회 위원이 남아 있을 때만 유효하다. 동의는 정해진 순서로 실행되고 참여자가 자리를 뜨기 전에 검증된다. 안전성 사건은 중증도·중대성·인과관계·예측 가능성으로 기술되며, §4.5의 표가 아니라 관할의 기한에 따라 보고된다. 지속 심의, 모니터링, 감사가 승인을 유효하게 유지하고, 기록 보관은 적용되는 가장 긴 규칙을 따른다.
제7장은 이 과정들을 실제로 동작하는 시스템으로 옮긴다. 명세서 §8.1의 6개 필수 구성 요소, 모든 관문을 검증 가능하게 만드는 감사 추적, 그리고 임상시험·병원 시스템과의 연동이 그 내용이다.
minor-increase로 표시되어 있다. SDK는 어떤 수준을 제안하며, 미국 공통규칙 아래에서 운영하는 시스템이 그 제안을 자동으로 받아들이면 안 되는 이유는 무엇인가?studyType에 대한 부분 문자열 일치가 면제 제안의 근거로 안전하지 않은 이유는 무엇인가? 거짓 양성의 예를 들어 보라.approved-with-modifications 결정 뒤 제출 기록의 status는 무엇이어야 하며, 등록은 언제 시작할 수 있는가?