Audit trail 기록 점검, 검토하는 방법

 

2021년 정도 부터 DI 업무 관련 인원, 인력을 채용하는 공고가 나오고 있습니다.

주변에서도 실제 DI 부서로 취업한 분들이 있고, 해당 직무에 대해서 관심을 갖는 취준생 분들도 늘어난 것 같고요.

 

사실, DI는 QC, QA, 생산 조직을 포함해 실제 GMP 업무를 하고 있는 재직자들에게도 쉽지 않은 개념인 만큼 취업 준비생분들이 DI 개념이나 실무를 파악하고 취업을 준비하는 데에는 분명 어려운 점이 있을 겁니다. 

 

DI 연관된 실무 인력이 필요한 업무는 크게 Audit trail 검토 또는 데이터 백업 정도가 있습니다. 

특히나, Audit trail 검토 업무는 의약품의 제조 및 품질 시험이 적합한 기준을 만족하고, 데이터완전성 문제가 없음을 평가하는 데 꼭 필요한 과정이므로 의약품의 특정 Lot(batch) 출하 전에 점검이 완료되어야 합니다. 

 

그동안 Blog 통해서 Audit trail 개념이나 범주에 대한 내용은 정리는 조금씩 했는데,

막상 어떻게 검토해야하는 지에 대해서는 글이 없었던터에 실제로 이 부분을 궁금해 하시는 분도 계셔서 생각을 남겨봅니다. 

 

 

---

 

[Audit trail 검토 방법은 무엇인가요?  어떻게 수행하는 건가요?]

라는 질문을 받았습니다. 

 

위 질문을 받았을 때, 처음 들었던 생각은

 

'Audit trail 검토 SOP 가 없거나, 혹은 아주 포괄적 수준에서의 형식적인 절차서만 있겠다' 라는 생각을 했습니다. GMP 에서 수행하는 모든 작업/활동들은 사전에 정의된 '표준 절차서' 에 따라서 해야하기 때문인데요.

 

Inspection 시에 Audit trail 검토 절차서(SOP) 가 있다고 하더라도 쉽게 코멘트 받는 사항 중에 하나였습니다. SOP 수준이 너무 rough 하다는 것입니다. 정리하면, SOP에 기술된 audit trail 검토 절차가 너무 빈약해서 개별적으로 형태나 검토 방식이 다양한 여러 system 의 audit trail 을 검토할 수 없다는 것입니다. 

 

이 경우 같은 시스템이라도 검토자 마다 보는 방법이 다르거나 보는 수준이 달라지기 때문에 '형식적인 활동'이 되기 쉽습니다. 

 

질문으로 돌아와서, 

 

Audit trail 검토 방법은 모든 system 마다 다릅니다.

어떤 기록이 남고, 어떤 요소를 포함하고, 어떤 편의 (예: 필터링) 기능이 있는지에 따라 검토 방법이 달라질 수 밖에 없습니다.

 

따라서, Audit trail 방법이 명확히 없다면,

 

1) 해당 system 의 audit trail 이 어떤 형태로 출력되고, 기록되는지, 어떤 event 에 대해서 기록이 남는지를 우선 확인해야합니다. (* Audit trail 기능 또한 CSV 과정에서 검증되어야 하므로 기능 검증되지 않은 audit trail 절차 또한 지적 대상이 됩니다)

 

2) Audit trail 형태와 기능을 파악했다면, 어떤 event 를 점검할지를 결정합니다.  (데이터의  변동사항, 시스템 설정의 변동사항, 사용자 권한 설정의 변동 사항 등) 

 

3) 점검 Event 목록을 결정하면, 해당 Event 를 점검하기 위한 세부 방법 (어떤 Audit trail 기록이 남았을 때 문제 사항으로 평가할 것인지)을 정합니다. (* 실제로 문제가 되는 Event 가 점검 중 발견 되었을 때의 후속 조치 절차로 사전에 정의합니다)

 

4) 점검을 수행하고 평가를 진행할 서식을 만듭니다. 

 

 

---

 

시스템, 장비, 설비, 기기의 S/W 수준이 다르기 때문에 Audit trail 기능이 없는 것 부터, 단순한 audit trail 기록만 제공하는 것 또는 아주 자세하고 점검 하기 용이한 기능까지 포함한 것까지 다양한 형태가 존재 합니다.

 

Audit trail 검토는 시스템이 제공하는 audit trail 기록/기능 범주에서 확인가능한 사항을 검토하면 큰 문제가 없습니다. 

 

예를들면, 

 

1) 분석 이력, 작동 이력만 남는 단순 기기

장비 사용 이력 로그북과 분석 이력(Audit trail or Log) 을 매칭 시켜 임의 사용을 하지 않았는지 수준에서 점검. 이때, 장비 사용 이력이 너무 많거나 일부 이력만 특정 기간 보관하는 시스템의 경우, 전수 점검 보다는 임의 점검 측면에서의 수행도 진행할 수 있겠습니다.

 

2) 날짜/시간 변경 이력이 남는 단순 기기 

변경을 불가능하게 하는 것이 가장 우선되어야 하나, 부득이하게 제어가 불가하다면 날짜/시간 변경 이력을 점검해 문제가 없는지를 주기적으로 체크 합니다. 

 

3) Raw data 가공을 통해 최종 데이터를 생성하는 분석기기 (예: GC, HPLC 등)

대부분의 QC 장비에 해당하며, 분석 데이터가 매우 많기도 하고, 가공된 데이터의 업데이트 상황 (예: 샘플정보 오기, 적분 파라미터 수정, 적분 재수행 등) 이 많기 때문에 해당 변경의 적합성을 판단할 수 있는 QC 부서에서 자체적인 Audit trail 검토가 선행되어야 하고, 이와 별개로 제 3의 부서에서 시스템 변경, 데이터 삭제, 이동 등의 중요 Audit trail 기록을 점검하는 방식이 적절하겠습니다. 

위와 같은 시스템들은 보통 Audit trail 점검을 위한 기능 (필터링, 검색 기능 등)을 제공하고, 시스템 연관 audit trail 과 데이터 연관 audit trail 항목이 나누어진 경우도 많으므로 시스템 확인을 통해 가장 효과적인 점검 방법을 강구해야 합니다.

 

---

 

신입 사원분들이 시스템 및 S/W 에 대한 이해 없이 audit trail 을 점검하는 것은 어려운 일입니다. 시스템과 해당 S/W 에 대한 경험을 축적하고, 여러번 확인하는 과정을 통해 익숙해 진다면 구체적인 audit trail 검토 절차를 만들고 이에 따라 Routine 하게 점검을 수행하는 것은 크게 어렵지 않은 일이 될 것입니다. (오히려, 문제 상황을 발견한 이후의 action 이 더 어렵다고 생각합니다)

 

Audit trail 관련해서 이전 포스팅도 참고하시기 바랍니다 :)

 

 

 

GMP inspection HPLC Audit trail 점검 사항

Audit trail (점검 기록) 검토 주체와 주기 결정