LIMS System Owner의 역할

 

LIMS는 단순 시험 시스템이 아니라, 규제 환경에서 데이터 무결성을 통제하는 핵심 플랫폼입니다. (LIMS: Laboratory Information Management System, 실험실 정보 관리 시스템)

• 검체 등록
• 시험 분석
• 결과 보고
• 데이터 저장 및 기기 연동 

 

직무의 본질

GMP 환경에서 LIMS의 기술적 안정성과 데이터 무결성을 책임지는 System Owner 

 

System Owner는 모든 레이어를 관통하는 역할을 합니다.

GMP는 위에 있는 게 아니라 전체를 감싸는 통제 계층입니다.

(GMP: Good Manufacturing Practice, 제조 및 품질관리 전 과정에서 데이터의 무결성, 추적 가능성, 일관성을 보장하기 위한 기준)

[ Business Layer ]
시험실 프로세스 / QC 업무 / 배치 Release 판단
                ↓
────────────────────────────────
[ Application Layer ]
                LIMS Core
  - 시험 관리
  - 결과 저장
  - 승인 프로세스
  - 재시험 관리
────────────────────────────────
                ↓
[ Integration Layer ]
  장비 인터페이스 ↔ MES ↔ ERP ↔ 기타 시스템
────────────────────────────────
                ↓
[ Data Layer ]
  DB (시험 결과, 원본 데이터, Audit Log)
────────────────────────────────
                ↑
[ GMP Control Layer ]
  - Data Integrity 통제
  - Change Control
  - Validation
  - Audit 대응

 

 

데이터 흐름 중심 구조 

모든 단계와 변경점에 대해 기록하고 제어하는 역할이 매우 종요합니다. 

[ 분석 장비 ]
     ↓ (Raw Data)
[ Interface Module ]
     ↓ (Validation & Parsing)
[ LIMS Core ]
     ↓
[ DB 저장 ]
     ↓
[ 승인/Release 프로세스 ]
     ↓
[ ERP / MES 연계 ]

모든 단계 → Audit Log 기록
모든 변경 → Change Control 대상

 

 

System Owner 의 역할

Owner는 코딩 담당자가 아니라 QA와 IT 사이의 기술적 책임자역할을 수행합니다. 

 

변경 통제 및 Validation 책임

• 시스템 변경 요청 검토
• 변경 영향도 분석
• 인터페이스 로직 수정 검토
• 테스트 범위 정의 
•  Validation(OQ/PC) 참여 
• Change Control 승인 프로세스 참여 
• 변경 이력 관리

데이터 무결성 및 인터페이스 관리

• 장비 ↔ LIMS 데이터 수집 구조 검토
• 인터페이스 오류 모니터링
• 데이터 누락/중복 방지 설계
• Audit Trail 점검
• DB 정합성 확인
• 장애 발생 시 Root Cause 분석

Audit 대응 및 대내외 기술 창구

• Audit 시 시스템 설명
• 접근 권한 구조 설명
• 변경 이력 제출
• 인터페이스 구조 설명
• 벤터 기술 검토
• 글로벌 기준 정렬

 

Risk-Based Approach(위험 기반 통제)

System Owner는 모든 변경을 동일하게 보는 것이 아니라, 품질에 미치는 영향 수준에 따라 통제 강도를 조절해야 합니다.

• 모든 기능이 동일한 Critial Level은 아님
• 시험 결과 계산 로직은 High Risk
• UI 문구 변경은 Low Risk
• 인터페이스 자동 승인 로직은 High Risk

 

Part 11 / 전자기록 · 전자서명 개념 

LIMS는 대부분 전자 기록 시스템입니다.

• Electronic Record
• Electronic Signature
• 접근 권한 분리
• 계정 공유 금지
• 비밀번호 정책

 

Master Data 통제

운영 데이터 외에 Master Data 통제가 더 중요합니다.

• 시험 항복 정의
• 허용 기준값(Spec)
• 계산 공식
• 시험 방법 버전

Deviation CAPA 개념

실제 GMP 환경에서는 장애를 "버그"라고 하지 않고 "Deviation(일탈)" 이라고 부릅니다. 

System Owner는 장애를 기술적으로 해결하는 것뿐 아니라 Deviation 기록 근거를 제공하는 역할을 합니다. 

• 원인 분석
• 재발 방지 조치(CAPA)
• 문서 기록

Backup / Disaster Recovery (DR)

• DB  백업 정책
• 복구 테스트
• 데이터 손실 허용 범위
• 이중화 구성

 

Lifecycle 관점 

• 기획
• 요구사항 정의
• 설계
• Validation
• 운영
• 변경
• 폐기(Decommissioning)

폐기란, 시스템 사용 종료 / 데이터 보존 전략 수립 / 규제 요건 충족 상태 유지 / 감사 대응 가능 상태 유지 를 의미합니다. 

즉, 기능은 종료 하지만, 책임은 종료되지 않습니다.

 

폐기 단계에서는 데이터 보존 전략 / 전급 통제 유지 / Validation 종료 문서화 / 인터페이스 정리 를 해주어야 합니다. 데이터의 삭제가 아닌 언제든 접근 가능한 상태를 유지해야 합니다. 

 

KPI 기반 운영

• 인터페이스 실패율
• 승인 지연 시간
• 재시험 발생 빈도
• Audit Finding 건수

 

Traceability Matrix 의 본질 

GMP 프로젝트에서는 요규사항 정의 → 설계 명세 → 테스트 케이스 → 실행 결과 → 변경 이력 .. 이 모든 것을 연결해서 증명해야 합니다. 

 

"이 요구사항이 어디에 구현되었고, 어떻게 검증되었는가?"를 한눈에 보여주는 지도입니다. 

 

Audit 시 가장 많이 받는 질문에 대응하기 위해 Traceability Matrix가 반드시 필요합니다.

• 이 기능이 어떻게 검증되었는가?
• 이 요구사항이 누락되지 않았는가? 
• 테스트되지 않은 기능이 있는가?
• 변경 후 재검증 되었는가? 

LIMS에서 아래와 같은 형식으로 관리하게 됩니다.

URS	Risk	FS	Config	OQ	PQ	Status
URS-001	High	FS-03	Role Rule	TC-05	PQ-02	Validated

 

• URS - 사용자 요구사항 고유 번호 
• FS Ref - 설계 문서의 어느 항목에 반영되었는지
• Config - 설정값 or 계산 로직 or 인터페이스 모듈
• QQ Test - 운영 검증 테스트 케이스 번호
• PQ Test - 실제 업무 시나리오 기반 검증

Traceability의 핵심 3가지는 아래와 같습니다. 

1. Completeness - 모든 URF가 FS에 반영되었는가? 
2. Coverage - 모든 High Rish 항목이 QQ 테스트되었는가?
3. Revalidation - 변경 시 영향 받는 URS는 재검증 되었는가? 

 

Bidirectional Traceability  

• Forward Traceability: URS(요구사항) → FS/DS(설계) → Config/Code → IQ/OQ/PQ(시험) → Evidence(증빙)
• Backward Traceability: Evidence(증빙) → 테스트케이스  → 설정 → 코드 → 어떤 URS를 만족 / URS 없는 기능이 있는가?

규제 관점에서 실패 패턴은 두 가지가 있습니다.

역방향 추적성은 이 두 가지를 구조적으로 방지할 수 있습니다.

1. URS는 있는데 테스트가 없는 경우 → 검증되지 않은 요구사항(Audit에서 바로 걸림)
2. 테스트/기능은 있는데 URS가 는 경우 → 승인되지 않은 기능(Shadow Function, 통제 위반)

 

GMP / 규제 관련 용어

약어/용어	Full Name	의미	System Owner 관점 핵심
GMP	Good Manufacturing Practice	제조 및 품질관리 기준	시스템 설계 원칙
ALCOA	Attributable, Legible, Contemporaneous, Original, Accurate	데이터 무결성 원칙	Audit Trail 필수 근거
CSV	Computer System Validation	컴퓨터 시스템 검증	문서 기반 검증 체계
URS	User Requirement Specification	사용자 요구사항 문서	모든 검증의 출발점
FS	Functional Specification	기능 명세	URS를 기술적으로 풀어쓴 문서
DS	Design Specification	설계 명세	실제 구현 구조 정의
IQ	Installation Qualification	설치 검증	시스템이 올바르게 설치되었는지
OQ	Operational Qualification	운영 검증	기능이 요구대로 동작하는지
PQ	Performance Qualification	성능/실사용 검증	실제 업무 환경에서 검증
RTM	Requirements Traceability Matrix	요구사항 추적 매트릭스	URS↔검증 연결 지도
OOS	Out Of Specification	허용 기준 초과	품질 리스크 발생 이벤트
Deviation	일탈	규정 위반/예외 발생	원인 분석 필요
CAPA	Corrective and Preventive Action	시정 및 예방 조치	재발 방지 체계
Change Control	변경 통제	시스템 변경 승인 절차	배포 통제 핵심
Risk-Based Approach	위험 기반 접근	위험도에 따른 통제	검증 범위 결정 기준
Part 11	21 CFR Part 11 (FDA)	전자기록/전자서명 규정	전자 승인/로그 설계 기준

 

 

LIMS / 시스템 관련 용어

약어/용어	의미	설명	Owner가 보는 포인트
LIMS	Laboratory Information Management System	시험 데이터 관리 시스템	데이터 허브
QC	Quality Control	품질 관리 부서	사용자
QA	Quality Assurance	품질 보증 부서	규제 통제 주체
Master Data	기준 데이터	시험항목, Spec, 계산식 등	변경 시 High Risk
Spec	Specification	허용 기준값	합/부 판정 기준
RBAC	Role-Based Access Control	역할 기반 접근 제어	권한 통제 핵심
Audit Trail	변경 이력 로그	누가 언제 무엇을 변경했는지	Data Integrity 핵심
Electronic Signature	전자서명	승인 인증 절차	Part 11 대상
Interface	시스템 간 연동	장비↔LIMS↔MES↔ERP	데이터 정합성
Raw Data	원본 데이터	장비에서 생성된 최초 데이터	삭제 금지
Archive	데이터 보관	시스템 폐기 시 보존	Read-Only 유지
Revalidation	재검증	변경 후 재검증	Change Control 연결