Sample Chain-of-Custody(CoC) 자동화 시스템 구현 전략

 

Sample Chain-of-Custody(CoC) 자동화 시스템 구현 전략

 

1. Chain-of-Custody는 왜 항상 audit 포인트가 되는가

규제기관이 CoC를 보는 이유는 단순하다.

“이 결과가 정말 그 샘플에서 나온 것이 맞는가?”

이 질문은
샘플 무결성, 데이터 신뢰성, 환자 안전까지
모두 연결된다.

하지만 현실의 분석 현장에서는
CoC가 종종 이렇게 취급된다.

• 샘플 수령 시 서명
• 냉동고 위치 기록
• 분석 완료 후 결과 보고

겉보기에는 문제가 없어 보이지만,
샘플이 ‘움직이는 순간’의 기록은 대부분 비어 있다.

바로 이 공백이
audit에서 집중적으로 파고드는 지점이다.

2. 수작업 CoC의 구조적 한계

2.1 CoC 문서는 “사후 기록”이 되기 쉽다

수작업 CoC의 가장 큰 문제는
행위와 기록이 분리된다는 점이다.

• 샘플을 옮기고
• 바쁘니까 나중에 적는다
• 기억에 의존해 시간과 담당자를 채운다

이 순간, CoC는
사실 기록이 아니라 서술문이 된다.

2.2 Multi-handler 환경에서 책임이 흐려진다

CRO나 대형 분석 조직에서는

• 샘플 수령 담당자
• 전처리 담당자
• 장비 분석 담당자
• 보관 담당자

가 모두 다르다.

수작업 CoC에서는
“누가 마지막으로 책임졌는지”가
항상 애매해진다.

자동화가 필요한 이유는
사람이 아니라 시스템이 책임을 기억하게 하기 위해서다.

3. CoC 자동화의 본질: 기록 자동화가 아니라 “행위 귀속”

많은 조직이 CoC 자동화를
이렇게 오해한다.

“종이 대신 전자서식 쓰면 자동화 아닌가요?”

아니다.

CoC 자동화의 핵심은 이것이다.

샘플에 가해진 모든 행위를
사람·시간·장소와 자동으로 연결하는 것

즉,

• 사람이 “기록하는” 시스템이 아니라
• 행위가 발생하면 기록이 따라붙는 구조

여기까지 가야
진짜 CoC 자동화다.

4. CoC 자동화 설계의 출발점: 샘플을 ‘객체’로 정의하라

자동화를 하려면
샘플을 단순한 튜브가 아니라
상태를 가진 객체(object)로 봐야 한다.

4.1 샘플 객체가 가져야 할 최소 정보

• Unique Sample ID
• 현재 상태 (Received / Stored / In-prep / Analyzed / Archived 등)
• 현재 위치
• 현재 책임자

이 정보가
항상 하나의 truth로 유지되어야 한다.

5. 상태 전이(State transition) 기반 CoC 모델

CoC 자동화의 핵심 개념은
상태 전이다.

샘플은 가만히 있지 않는다.
항상 어떤 상태에서 다른 상태로 이동한다.

예를 들면,

• Received → Stored
• Stored → Checked-out for prep
• In preparation → Ready for analysis
• Analyzed → Returned to storage

중요한 점은
상태가 바뀔 때마다 CoC 이벤트가 자동 생성되어야 한다는 것이다.

6. 이벤트 기반 CoC 자동화 구조

6.1 CoC 이벤트에 반드시 포함되어야 할 요소

각 이벤트는 최소한 다음을 포함해야 한다.

• Event type (이동, 인계, 사용, 보관 등)
• Timestamp (자동 기록)
• Actor (로그인 사용자 또는 장비)
• Location (냉동고, 랩, 장비 등)
• 이전 상태 → 이후 상태

이 다섯 가지가 빠지면
그 CoC 이벤트는 audit에서 취약해진다.

7. 바코드·RFID는 도구이지 해답이 아니다

많은 조직이
CoC 자동화 = 바코드 도입
이라고 생각한다.

하지만 바코드는
트리거일 뿐이다.

중요한 건

• 스캔 시 어떤 이벤트가 생성되는가
• 그 이벤트가 샘플 상태에 어떤 영향을 주는가

바코드를 찍었는데
시스템에는 아무 변화가 없다면
그건 단순 확인일 뿐 CoC가 아니다.

8. LIMS와 CoC 시스템의 역할 분리

실제 구현에서
가장 많이 실패하는 부분이 이것이다.

• LIMS에 모든 걸 넣으려다
• CoC가 애매해진다

현실적인 구조는 다음과 같다.

• CoC 엔진: 상태 전이와 이벤트 관리
• LIMS: 샘플 메타데이터와 결과 관리

CoC는 흐름을 관리하고,
LIMS는 결과를 관리한다.

이 역할이 섞이면
시스템은 무거워지고, 현장은 우회한다.

9. 사람의 판단이 개입되는 지점 처리 전략

자동화에서 가장 어려운 건
예외 상황이다.

• 샘플 파손
• 온도 이탈
• 라벨 훼손
• 계획 외 이동

이때 중요한 원칙은 이것이다.

예외는 숨기지 말고
표준화된 선택지로 기록하게 하라

• 자유 텍스트만 허용 ❌
• 사유 코드 + 설명 필수 ⭕

이렇게 해야
예외도 CoC chain 안에 남는다.

10. CoC 자동화의 완성 조건: “역질문이 가능해야 한다”

시스템이 제대로 작동한다면
다음 질문에 즉시 답할 수 있어야 한다.

• 이 샘플은 언제 누구에게서 누구로 넘어갔는가
• 특정 시간 동안 어디에 있었는가
• 어떤 상태에서 분석되었는가
• 계획 외 이동은 있었는가

이게 된다면
그 CoC 시스템은
audit 대응이 아니라 사전 방어 수준이다.

11. CoC 자동화는 IT 프로젝트가 아니라 운영 설계다

많은 조직이
CoC 자동화를 IT팀에 맡긴다.

하지만 성공하는 조직은
이렇게 접근한다.

• 분석 현장의 동선부터 다시 그린다
• “언제 기록이 빠질 수 있는가”를 먼저 찾는다
• 그 지점에 자동 이벤트를 심는다

CoC는
시스템이 아니라 일하는 방식의 반영이다.

12. 마지막으로, 규제기관이 진짜 보고 싶은 것

FDA나 EMA가 CoC에서
진짜로 확인하고 싶은 건 이것이다.

“이 샘플은
한 번도 정체를 잃은 적이 없는가?”

자동화 CoC 시스템은
이 질문에 대한 가장 강력한 답변이다.

마무리

Sample chain-of-custody는
부가 업무가 아니다.

그건
데이터가 데이터로 인정받기 위한 최소 조건이다.

그리고 자동화는
편의를 위한 선택이 아니라
multi-site, high-throughput 환경에서
유일하게 지속 가능한 해법이다.