“왜 이 batch를 accept했는가?”를 설명하는 데이터 구조

– 결과가 아니라 판단을 남기는 시스템

Bioanalysis에서 batch acceptance는 늘 문서의 마지막에 위치한다.
QC table 아래, 작은 글씨로 이렇게 적힌다.

“Batch is acceptable.”

하지만 ICH M10 이후,
이 문장은 더 이상 결론이 아니다.
오히려 질문의 시작점이 된다.

“왜 acceptable한가?”

이 질문에 답하지 못하는 순간,
그 batch는 규정상 통과했어도 규제적으로는 불안한 데이터가 된다.

1️⃣ 과거의 batch acceptance는 ‘판정’이었다

전통적인 bioanalysis workflow에서
batch acceptance는 이렇게 처리됐다.

• QC ≥ 2/3 pass
• accuracy / precision 기준 충족
• 특별한 이슈 없음
• → accept

이 구조에서 acceptance는
👉 규칙의 결과였고
👉 사람의 판단이 개입될 여지는 거의 없었다.

그래서 문서에는
“acceptable”이라는 단어만 남고,
왜 괜찮았는지에 대한 설명은 남지 않았다.

2️⃣ ICH M10 이후, acceptance는 ‘의사결정’이 되었다

M10 이후 batch acceptance는
더 이상 자동 판정이 아니다.

이제 acceptance는 다음 질문들을 전제로 한다.

• 이 batch는 assay lifecycle 상 어디에 있는가?
• 최근 batch들과 비교했을 때 drift는 없는가?
• QC fail은 우연인가, 패턴의 일부인가?
• borderline 결과가 반복되고 있지는 않은가?

즉,
👉 acceptance는 숫자의 문제가 아니라
👉 리스크 평가의 결과가 되었다.

3️⃣ Reviewer가 진짜 보고 싶은 데이터 구조

Audit에서 reviewer가
“왜 이 batch를 accept했는가?”라고 묻는 순간,
그들이 원하는 건 말이 아니라 구조다.

① 단일 batch QC table ❌

② Batch 간 맥락을 보여주는 구조 ⭕

예를 들어:

• 최근 10개 batch QC trend
• QC 위치별 bias 분포
• slope / intercept 변화
• LLOQ 성능의 일관성

이 데이터들이 연결돼 있을 때,
batch acceptance는
👉 고립된 판단이 아니라 연속적인 관리의 일부가 된다.

4️⃣ Acceptance 판단을 지탱하는 4개의 데이터 레이어

1) Intra-batch performance

• QC accuracy / precision
• IS response consistency
• peak shape, S/N

→ “이 batch 자체는 안정적인가?”

2) Inter-batch trend

• QC bias 반복 여부
• calibration slope drift
• 특정 농도 구간 편향

→ “이 batch가 전체 흐름에서 이탈했는가?”

3) Exception handling history

• 재분석 이력
• integration 수정 빈도
• 동일 원인의 반복 여부

→ “이 batch는 예외의 일부인가?”

4) Risk assessment narrative

• known limitation
• method robustness
• intended use 적합성

→ “이 결과를 사용해도 되는가?”

이 네 레이어가 연결되어 있을 때만
acceptance는 설명 가능한 결정이 된다.

5️⃣ ‘판단의 흔적’이 없는 acceptance가 가장 위험하다

Audit에서 가장 위험한 상황은
batch 결과가 나쁜 경우가 아니다.

가장 위험한 건 이것이다.

• 결과는 좋아 보이는데
• borderline가 반복되는데
• 아무도 그걸 언급하지 않았고
• acceptance 이유가 남아 있지 않음

이때 reviewer는 이렇게 판단한다.

“이 조직은
문제가 없는 게 아니라
문제를 보지 못한다.”

 

6️⃣ Acceptance 문장은 이렇게 바뀌어야 한다

❌ “Batch is acceptable.”

⭕

“This batch was accepted based on predefined QC criteria,
evaluation of recent batch performance trends,
and assessment that no systematic bias affecting intended use was observed.”

이 문장의 핵심은
👉 기준 + 비교 + 판단이 모두 포함돼 있다는 점이다.

7️⃣ SOP에서 acceptance를 ‘결과’가 아닌 ‘프로세스’로 정의하라

ICH M10 이후 SOP에서
batch acceptance는 이렇게 정의돼야 한다.

• QC criteria 충족 여부
• Trend review 수행 여부
• Exception review 포함 여부
• 최종 reviewer 책임 명시

즉,
acceptance는 한 줄이 아니라
👉 검토 프로세스의 집합이어야 한다.

8️⃣ 자동화가 진짜 힘을 발휘하는 지점

R 기반 자동화, LIMS 연동, dashboard가
진짜 의미를 갖는 순간은 여기다.

• QC trend 자동 생성
• batch 간 비교 자동화
• borderline 감지
• reviewer 판단을 남길 공간 확보

자동화는
판단을 대체하는 게 아니라
👉 판단을 남길 수 있게 만드는 도구다.

마무리하며

“왜 이 batch를 accept했는가?”라는 질문은
분석팀을 공격하기 위한 질문이 아니다.

그 질문은
👉 데이터를 숫자로만 보고 있는지,
👉 아니면 시스템으로 관리하고 있는지를
구분하는 기준이다.

ICH M10 이후,
batch acceptance는 더 이상 결과가 아니다.

그것은
👉 조직의 과학적 사고가 남긴 흔적이다.

 

“왜 이 batch를 accept했는가?”를 설명하는 데이터 구조