.png)
CSV를 한다고 하면, 대부분의 제약사 분들은 컨설팅 의뢰를 하거나 자체적으로 진행합니다.
또한, CSV를 완료해야 시스템을 사용할 수 있다고 합니다.
CSV는 무엇일까요?
CSV는 Computer System을 Validation을 하는 것 입니다. Computer System에 대한 정의는 GAMP5 등 여러 가이드라인에서 언급하듯이 Life Cycle이 존재합니다. 흔히 저희가 생각하는 CSV를 완료해야 한다는 기준은 Project 단계에 한정되어 있죠! 여기서 CSV가 완료되었다면 Computer System은 잘 운영되고 문제 없을까요?
아마도 문제가 생기거나 업데이트, 변경관리 등의 이슈 때문에 재밸리데이션에 대한 고민들을 하게 될 거라 생각합니다.
그러면 어떻게 해야 할까요? 어떤 것이 중요한 Point 일까요?
CSV의 기준이 되는 가장 기본적인 문서인 URS는 언제 작성되는 것이 맞을까요?
Concept 단계겠죠?
우리가 가지고 있는 프로세스를 분석 해 구축하는 시스템의 적용 범위를 정하고, 다양한 시스템 중 어떤 시스템을 구축 할 것인가를 정하는 일일 겁니다.
Project 단계가 끝나면요?
Operation 단계에서는 처음에 정해놓은 요구사항대로 시스템이 운영되는지? 변경사항이 발생할 때 데이터의 완전성에 문제가 없는지 확인해야 하는 일을 끊임없이 해야 합니다. 때에 따라 현재 시스템이 적절하게 운영되고 있는지에 대해서 테스트를 해야 할 수도 있습니다.
예를 들어, 권한 변경에 대한 예를 들어보겠습니다. 사용자가 가지지 말아야 할 권한을 정의하여 프로젝트 단계에서 CSV를 진행할 때 그것이 잘 적용되었는지 확인을 하게 됩니다. 그 후 운영 단계에서 어떤 한 사용자에게 그동안 주던 권한이 아닌 추가로 권한을 줘야 할 사항이 생긴다고 가정했을 때 그 권한이 초기에 정의했던 가지지 말아야 할 권한인지에 대한 확인이 필요하지 않을까요?
그러기 위해서는 초기에 작성한 URS가 필요할 겁니다. 그 당시 작성한 사람이 현재 운영하는 동일인 일지라도 그 기간이 얼마나 되느냐에 따라 기억을 못할 수도 있고, 중요한 사항을 놓칠 수도 있기 때문이죠!
마지막으로 Retirement 단계를 살펴보겠습니다. 시스템을 운영하고 폐기 하기 전 이 시스템과 그 안에 데이터까지 완전히 폐기할 지 단순히 시스템만 폐기하고 데이터는 새로운 시스템으로 이관할 지 등에 대한 고민을 해야 할 수 있으며, 신규 시스템의 도입으로 기존 시스템을 통폐합하는 이유로도 현 시스템의 폐기를 논의해야 할 사항이 발생할 수 있습니다.
즉, 이 때에도 보관되어야 할 데이터, 이관 되어야 할 데이터, 삭제해도 될 데이터, 이 과정을 작업할 사람의 대한 관리 권한 부여 등 밸리데이션 영역에서 생각하고 결정해야 합니다. 그리고 이러한 사항 역시 초기 컨셉 단계에서 부터 결정되거나, 운영 단계에서 발생된 문제로 인해 연결되어 관리되곤 합니다.
결국, 컨셉 단계에서부터 폐기 단계까지 Computer System의 Life Cycle은 곧 CSV가 어디부터 어디까지 적용되어야 하는가를 말해주는 좋은 예라 할 수 있으며, 단순히 프로젝트 단계만을 바라보고 VP~VSR을 작성해 오던 기존 CSV 전략을 수정하여 확장해야 함을 말씀드리고 싶습니다.
더구나 최근 Data Integrity와 연결하여 CSV 항목 중 DI 관점에서 고려해야 할 사항들은 CSV를 진행함에 있어 매우 중요하게 확인해야 하고, 지속적으로 관리해야 할 사항임은 명백해지고 있습니다.
제 글을 읽어주시는 분들, 그리고 제약에 계신 분들이 CSV라는 활동을 다시한번 생각해주셨으면 하는 마음에 이 글을 씁니다.
감사합니다.