업무를 시작하기 전에 알아둘 점
통계분석계획서(Statistical Analysis Plan, SAP)는 연구 질문에 어떤 자료와 방법으로 답할지 구체화합니다. 계획서보다 상세한 분석 집단·평가변수 도출·결측·민감도 분석·표시 방법을 정의합니다. 코딩 가능한 수준의 명확함이 필요하지만 분석자의 구현 사양과 의학적 해석을 한 문서에 무리하게 섞지는 않습니다.
현장에서 쓰는 말
| 용어 | 뜻 | 언제 쓰나 |
|---|---|---|
| SAP | 통계분석계획서 | DB lock 전에 확정 |
| Estimand | 추정 대상 | 무엇을 추정할지 정의(ICH E9(R1)) |
| ITT / PP | 분석 대상군 | 전체 배정군 / 계획서 준수군 |
| Sensitivity analysis | 민감도 분석 | 결과가 가정에 흔들리는지 확인 |
| Mock shell | 빈 표 틀 | TLF 형식 미리 정의 |
관련 규정
ICH E9 및 E9(R1)은 통계적 원칙과 estimand·민감도 분석을 다룹니다. 연구 질문과 추정·분석 방법을 정렬하는 것이 출발점입니다.
ICH E6(R3)의 분석 전 자료 확정 기준은 분석 목적에 맞는 데이터 검토·인계와 연결됩니다. SAP 확정과 데이터 확정은 같은 승인 절차가 아닙니다.
질문과 분석을 맞춰요
대상 집단, 평가할 결과, 치료 조건과 중간 사건 처리 등 연구 질문의 구성 요소를 명확히 하고 분석 방법과 연결합니다.
사전 계획과 변경 근거
분석 대상군·자료 처리·결측 자료·출력물 등을 구체화하고 적절한 시점의 검토·확정 및 변경 이력을 관리합니다. 시험별 눈가림 유지도 고려해요.
Estimand와 분석 프로그램을 구분합니다
무엇의 치료 효과를 알고 싶은지와 그 효과를 어떤 방법으로 추정할지는 구분합니다. 목표 집단·치료 조건·결과 변수·중간 사건 처리·집단 수준의 요약을 명확히 하고 분석 방법과 연결합니다. 치료 중단이나 구제약 사용을 단순 결측과 동일시하면 실제 연구 질문이 바뀔 수 있습니다.
자료 처리 규칙은 재현 가능해야 합니다
분석 대상군, 기준값·방문 창, 부분 날짜와 결측·이상값, 반복 측정 처리 등을 필요한 수준으로 정의합니다. 문장이 해석에 따라 달라지면 프로그래밍 사양과 분석 결과가 흔들립니다. 예외는 임의 수작업으로 처리하지 않고 결정 근거와 영향을 남기며 데이터 수집으로 확보 가능한 정의인지 확인합니다.
변경 시점과 정보 접근을 함께 봅니다
계획 수정의 이유와 시점, 결과·배정 정보에 대한 접근 상태를 고려해야 합니다. 눈가림 상태에서 해결한 정의 문제와 결과를 확인한 뒤 추가한 분석은 의미가 다릅니다. 사전 계획·변경·사후 분석의 경계를 문서와 보고에서 설명하고 버전 간 차이를 추적합니다.
실제 작업은 이런 순서로 진행해요
- 평가변수 도출은 방문 창·기준값·재검사·중복·구제치료·중단 이후 자료의 취급까지 구체화합니다. 실제 수집된 자료로 구현할 수 있는지 DM·프로그래밍 담당자와 시험합니다.
- 눈가림 상태에서 정할 수 있는 결정은 자료 검토 계획과 함께 사전에 관리합니다. 비눈가림 정보 접근과 분석 결정 변경의 관계를 기록해 결과를 본 뒤 유리한 방법을 골랐다는 오해를 줄입니다.
- 분석 산출물 검토에서는 수치뿐 아니라 집단·분모·단위·자료 기준일·주석을 봅니다. 사후 분석은 사전 계획 분석과 구분하고 요청 배경과 해석 제한을 보고서에 반영합니다.
| 담당 | 시점 | 수행 내용 | 전달·협업 | 산출물·기록 |
|---|---|---|---|---|
| STAT·임상 | 설계 검토 시 | 연구 질문·평가변수·estimand 정렬 | 계획서 작성팀 | 통계 설계 근거 |
| STAT·DM·프로그래밍 | 분석 계획 구체화 시 | 집단·처리·방법·출력 정의 검토 | 관련 검토자 | SAP·사양 초안 |
| STAT·승인자 | 확정 시 | 검토·눈가림·버전 상태 확인 | 분석 구현팀 | 승인본·변경 이력 |
| 프로그래밍·검증 | 구현 시 | 데이터·프로그램·출력을 대조 | STAT | 분석·검증 결과 |
| STAT·MW·임상 | 보고 시 | 추정·불확실성·한계를 해석 | CSR 작성팀 | 분석 설명과 근거 |
실무에서는 이렇게 나누어 운영해요
같은 업무라도 회사와 시험 규모에 따라 운영 방식이 갈려요. 많이 쓰는 방식을 비교하면 이렇습니다.
| 운영 방식 | 구체적인 모습 | 장점 | 주의할 점 |
|---|---|---|---|
| 계획서 연계 상세화 | 계획서의 원칙을 SAP에서 구체화합니다. | 설계 의도를 유지하며 구현을 명료하게 합니다. | 원래 가설과 충돌하는 변경을 조용히 추가하지 않아야 합니다. |
| 표·목록·그림 병행 | TFL 목업을 함께 검토합니다. | 분모·집계·주석의 모호함을 줄입니다. | 모양 검토가 분석 방법 검토를 대신하지 않습니다. |
| 분석 사양 분리 | SAP와 프로그래밍 사양을 연결합니다. | 통계 결정과 구현 세부를 관리하기 좋습니다. | 상호 참조와 개정 동기화를 유지해야 합니다. |
회사·시험마다 달라지는 부분
시험 설계
확증·탐색, 우월성·비열등성, 적응적 설계 등에 따라 가정과 분석 전략이 달라집니다. 하나의 표준 문장을 모든 시험에 적용하지 말고 설계 질문과 판단 기준에 맞춰 필요한 전문 검토를 거칩니다.
출력물과 구현 사양
SAP와 별도 사양의 상세 수준은 조직마다 다를 수 있습니다. TFL 모형·도출 규칙·메타데이터의 위치를 정하고 충돌 시 어떤 문서를 기준으로 결정하는지 명확히 합니다.
이런 상황이라면 어떻게 진행할까요?
가상의 시험에서 같은 방문에 재검사 결과가 여러 건 수집되었습니다. STAT는 계획서의 평가 목적에 맞춰 선택 규칙을 정하고 프로그래밍 담당자는 예시 자료로 구현 가능성을 시험합니다. DM은 실제 수집 시점과 재검사 사유가 충분한지 확인합니다. 합의된 규칙과 예외는 SAP 및 구현 사양에 연결하고, 기존 분석을 바꾸는 경우 이유와 영향을 기록합니다.
정의가 충돌하는 경우
계획서·SAP·프로그래밍 사양에 다른 표현이 있다면 구현자가 편한 쪽을 고르지 않습니다. 질문의 의도·승인된 변경과 데이터 확보 가능성을 확인해 책임 있는 결정을 받고 관련 문서를 정렬합니다. 분석 결과에 영향을 주는 해석은 회의 메모에만 남기지 않고 필요한 사양과 보고에도 연결합니다.
독립 검증과 해석 검토
프로그램이 사양대로 동작하는지와 분석 방법이 연구 질문에 적절한지는 다른 검토입니다. 검증에서 발견된 차이는 코드·사양·통계적 결정 중 어느 원인인지 구분하고 해결 근거를 남깁니다. 최종 결과를 설명할 때도 구현의 정확성만으로 임상적 의미나 가정의 타당성을 대신하지 않습니다.
실무에서 자주 묻는 질문
계획서에 분석이 있으면 SAP는 필요 없나요?
계획서의 상세 수준과 적용 요구에 따라 다르지만 구현·검토에 충분한 정의가 필요합니다. 별도 SAP를 사용하면 계획서와 충돌하지 않도록 문서의 관계를 관리합니다.
결측을 한 방법으로 처리하면 되나요?
평가 목적·결측 이유·가정과 자료 특성을 함께 검토해야 합니다. 통계 전문가가 적절한 방법과 민감도 분석을 정하며 모든 시험에 같은 처리법을 제시할 수는 없습니다.
추가 분석을 하면 안 되나요?
추가 질문에 대한 분석은 가능하지만 사전 계획과 구분하고 요청 시점·배경·방법·해석 한계를 투명하게 남겨야 합니다. 탐색 결과를 확증 근거와 같은 강도로 설명하지 않습니다.
실무 체크리스트
- 연구 질문과 estimand·분석 방법이 같은 목적을 설명하는가
- 집단·방문·기준값·결측·중간 사건의 정의가 명확한가
- 수집·외부자료로 구현 가능한 규칙인가
- 눈가림·사전 계획·변경 시점과 승인 근거가 남는가
- 민감도·보조 분석의 목적을 구분했는가
- 프로그램·출력·CSR로 이어지는 추적성이 있는가
자주 하는 실수
- 분석 집단 이름만 쓰고 선정 규칙을 생략하는 것
- 결측 처리와 중간 사건 전략을 같은 뜻으로 쓰는 것
- 출력물을 본 뒤 바꾼 내용을 사전 계획처럼 설명하는 것
- 코딩 구현에서 결정한 규칙을 SAP와 맞추지 않는 것
다음 담당자에게 넘길 것
분석 구현 인계에는 승인 SAP, 도출·출력 사양과 해석이 필요한 결정 사항을 포함합니다. 검토 질문은 단순 프로그램 오류와 통계적 의사결정을 구분해 처리하고, 최종 보고에서도 각 결과의 분석 근거를 확인할 수 있게 합니다.