iVIGILANCE SQUARE — Agile 개발 로드맵

목표. SaaS Tenant 모델과 운영자(Backoffice)가 고객 Org를 생성하고 Master Admin을 초대할 수 있다.

구현 항목

• Org / Workspace / App 3레벨 데이터 모델 + Org 상태 머신 (Pre-Active / Active / Terminated)
• Org 이름 필드 제약 (BOF-T-06): 최대 20자, 공백 포함, 시스템 전체 유니크
• Workspace 이름 필드 제약 (BOF-T-03): 동일 Org 내 유니크, 중복 시 오류 메시지("동일 Org 내 이미 사용 중인 이름입니다.")
• Contract 5-상태 머신 (Backoffice 기획 §1.1.6, BOF-C-01~21): SCHEDULED → ACTIVE → SUPERSEDED / EXPIRED / CANCELLED — BOF-C-17 배치 자동 전이(SCHEDULED→ACTIVE, ACTIVE→EXPIRED), BOF-C-18 취소(CANCELLED), 동일 버전 체인 SUPERSEDED 처리
• 계약 체결 안내 이메일 트리거 (BOF-C-01): 계약 생성 완료 시 안내 메일 발송 — 실제 배치/재시도/D-90·30·7·1 알림 등 전체 시스템은 신규 Phase A5(계약 알림 시스템) 에서 처리
• Workspace/App 활성화 플래그 (상태 머신은 Org에만 적용)
• 역할 매트릭스 (Backoffice Admin / Backoffice Operator / Master Admin / Org Admin / Org User / App Admin / App User / Viewer)
• External User는 모델 개념으로 예약하되, 실제 기능은 Release2/고도화에서 별도 정의
• Backoffice 로그인 + Org 생성 + Contract 생성 + Workspace App 활성화 + Master Admin 초대
• Org 한도(라이선스 슬롯 등) 데이터 모델
• 구조 한도 enforcement (LMT-01~07 일부): Backoffice가 Workspace 생성 / App 활성화 시 한도(Workspace 100/Org, App 10/Workspace) 차단 처리. 사용자 계정 한도 enforcement는 M2에서 처리
• 로그 발생 지점 정의 (A1 사전 작업): Backoffice 운영자 행위가 어떤 로그 분류(Backoffice Activity / Audit)로 기록되어야 하는지 식별. 실제 저장은 A1 인프라 완료 후
• Contract 정의 정합 (Multi-Org 1 Policy): Contract는 운영 주체가 아니고 Org 상태 전이 조건/기간/범위/이력만 정의. Contract 생성은 Backoffice Activity Log에 기록(이벤트 카탈로그는 A1)
• Backoffice 계정 비밀번호 정책 (v1.9, Backoffice 기획 §8.3): 비밀번호 복잡도만 고객 계정과 동일 적용. 180일 만료·재설정 기능은 미제공 (고객 계정 M1 정책과 분리)
• Terminated Org 접근 차단 정책 (v1.9, Backoffice 기획 §1.1.4, §2.3): Terminated(보존 기간 만료 전/후) 상태에서는 Backoffice Admin도 Org 내부 운영 데이터(앱 데이터 등) 조회 불가. 계약 정보·Org 기본 정보만 조회 가능, Break-Glass 포함 운영 데이터 접근 차단
• Safety DB 이니셜 케이스 사용량 연간 초기화 (v1.9, Backoffice §11.1): 1년 단위 집계, 매년 초기화 후 재카운트 (예: 2년 계약 200건이면 1년차 150건 사용 후 2년차 다시 200건으로 초기화). 1년 주기 초기화 배치 잡 구현
• BOF-T-03 기준 정보 범위 설정 주체 (v1.9, Backoffice §2.5): 추가 Workspace는 NEW Contract 생성 시 자동 생성되나 기준 정보(Study/Product) 범위는 Workspace 생성 후 고객사 Admin(Master Admin/Org Admin)이 후속 설정. Backoffice는 계약 시 생성 처리만 담당
• Workspace 폐쇄 데이터 Main 병합 (v1.9, Backoffice §2.7): 추가 Workspace 폐쇄 시 데이터 이관 완료 후 상위 Org의 Main Workspace에 결합되어 조회 가능. Org Terminated 시 자동 병합
• Backoffice MFA 변경 적용 시점 (v1.9, BOF-BAC-08): Backoffice MFA 활성화/비활성화 변경은 즉시 세션 종료 아닌 다음 로그인부터 적용, 변경 시 Audit Log 기록 (Org Admin MFA와 적용 시점 분리)
• Master Admin 최소 1명 유지 제약 (v1.9, Backoffice 기획 §7, BOF-U-05): Master Admin은 Org당 최소 1명·최대 1명 — 마지막 MA 계정의 비활성화 차단 enforcement (계약 종료 전)

참고

• confluence/기획 문서/00. Common (공통 정책)/Multi-Org 구조 및 관련 정책
• confluence/기획 문서/00. Common (공통 정책)/Backoffice 기획
• confluence/기획 문서/00. Common (공통 정책)/Audit Log, Activity Log, Audit Trail (로그 발생 지점 식별)

의존 없음 (모든 기능의 전제)

DoD Backoffice Admin이 신규 Org 1개를 생성하고 Master Admin 1명에게 초대 메일을 보낼 수 있다. Workspace/App 한도 초과 시 차단 메시지가 노출된다. Backoffice 운영자 행위의 로그 발생 지점이 A1 이벤트 카탈로그 후보로 식별된다. (v1.9 추가) A5 착수를 위해 SMTP/이메일 게이트웨이 계정·이메일 템플릿이 사전 확보된 상태로 인계된다 (A5와 병렬 가능하도록).

목표. 사용자가 초대 메일을 받아 계정을 활성화하고 로그인할 수 있다. 인증/계정 이벤트는 A1 인프라에 카탈로그로 편입한다.

구현 항목

• 초대 기반 계정 등록 (메일 토큰) + Invitation 5회 실패 시 링크 무효화 (ACC-09, Locked 미전이)
• 최초 비밀번호 설정 + 비밀번호 정책 + 비밀번호 재설정 30초 쿨다운(PWD-07/PW-06)
• 로그인 + 5회 실패 시 Locked + 60분 세션 + 비밀번호 재설정 메일
• 잠금 해제 경로 분리 (v1.8 정합): (a) 고객 측 — 본인 비밀번호 재설정 시 자동 해제(Account 26.04.17 정책) (b) Backoffice 측 — Backoffice Admin·Operator는 Master Admin 포함 전체 계정 잠금 직접 해제(BOF-U-07). Backoffice 해제 enforcement는 A4에서 양쪽 로그 기록 처리
• 비밀번호 180일 만료 화면(Login-004, LGN-40~LGN-44, PWD-04) — v1.9 정정: 만료 임박/만료 화면, 만료 시 유예 없이 즉시 강제 변경(Account 26.05.14 LGN-44 '나중에 변경 5회 유예' 삭제, LGN-45→LGN-44 번호 재부여로 유예 카운트 폐기). 강제 변경 흐름은 고라이브 시점 개발 (Soft Launch Gate 진입 조건)
• 비밀번호 복잡도 (v1.9 정정, PWD-01 26.05.14): 9~20자, 영대/소문자/숫자/특수문자 중 3종류 이상 조합 (구 "4종 모두 포함" 정책 폐지), 연속 4자 금지
• MFA (선택적 활성화) + MFA 재발급 카운트 초기화 규칙(MFA-05/06): 재발급 클릭 시 실패 카운트 미초기화, MFA 인증 성공 시에만 초기화
• MFA 정합 (v1.9, Account 26.05.14): (a) MFA 5회 초과 잠금 메시지 표시 위치 MFA 화면 → 로그인 화면으로 변경 (b) LGN-27 내용 재정의 — 구 정의(MFA 코드 만료 in-place 메시지)를 폐기하고 새 정의("5회 초과 시 계정 Locked 자동 전환 + 즉시 로그아웃 + 로그인 화면 잠금 안내")로 대체 (코드 번호 LGN-27 자체는 존재하므로 "삭제"가 아닌 "재정의" — v1.9 1차 검증 정정) (c) MFA 인증 시간 제한 10분(LGN-28) 신설 — 시간 초과 시 강제 로그아웃 트리거 (A1 카탈로그 편입)
• 계정 생명주기 (Pending Invite → Active → Locked → Inactive) + 비활성화 차단 조건(UM-50): 진행 중 케이스 Owner/Assignee 보유 시 비활성화 불가 (M4 케이스 도입 후 enforcement 활성)
• 인증 이벤트 카탈로그 편입: 로그인·로그아웃·비밀번호·MFA 이벤트 → Org Activity Log (Audit Log 문서 6.2.1)
• 계정 이벤트 카탈로그 편입: 초대·권한 변경·관리자 계정 조작 이벤트 → Org Audit Log

참고

• confluence/기획 문서/00. Common (공통 정책)/Account (+Login, Password)
• confluence/기획 문서/00. Common (공통 정책)/Audit Log, Activity Log, Audit Trail (6.2.1 인증/계정 이벤트)

의존 M0 (Org/Role 데이터 모델)

DoD 초대받은 Master Admin이 비밀번호 설정 후 로그인할 수 있다. 로그인/초대/권한 이벤트는 A1 이벤트 카탈로그 후보와 호출 훅으로 식별·연결되며, 실제 append-only 저장/조회는 A 트랙(A1/A2)에서 완성한다.

목표. 로그인 후 Org 홈 → Workspace → 앱 사이드바로 진입하고, Org Admin이 사용자/라이선스를 관리할 수 있다.

구현 항목

• Org 홈 / Workspace 홈 / 앱 사이드바 3단 네비게이션 — Workspace 홈 본체와 공지사항·다가오는 보고 마감일 등 위젯은 Home Navigation doc 1.3에서 "고도화"로 명시. Workspace 홈 위젯은 PLAN-G 결정 후 구체 Phase 배치
• 사이드바 디폴트 앱 표시 우선순위 (v1.9, Home Navigation 기획): Safety DB > LITUS > TUBE > SYNC. Workspace 내 다수 앱 활성화 시 본 순서로 표시
• Viewer Org 홈 사이드바 접근 (v1.9, Home Navigation 기획): Viewer 역할도 Org 홈 사이드바 "관리자(Admin)" 메뉴 접근 가능 (App 접근 없이 Org 단위 열람 신분)
• Org 홈 위젯: My Tasks(오너 케이스 5건 + 배정 업무 5건), 다가오는 보고 마감일(임박순 10건) — 필수(TEH-03~05). 단, M2에서는 빈 골격만 구현하고 데이터는 M4/M9 이후 채워짐
• 글로벌 헤더 + 세션 타이머 + My Profile + 딥링크 + 탭 정책
• 브라우저 탭 타이틀 정책 (Home Navigation 기획 §2.3): 로그인/Org 홈 = "iVigilance Square" / Workspace 홈 = "[WS명]" / 앱 화면 = "[WS명] - [앱명]"
• 프로필 드롭다운 메뉴 (Home Navigation §2.3): My Profile / Version / 로그아웃 — Version 항목은 솔루션 버전 정보 표시
• My Profile 모달 (Home Navigation §2.3, Account doc PRF-16/PRF-23): Profile 탭과 Password 탭 각각에 개인정보 처리방침 링크 노출, 클릭 시 별도 모달로 처리방침 페이지 열림
• 탭/세션 구조 정책(NAV-04): Org 홈 → Workspace 홈은 새 탭. Workspace 간 이동은 반드시 Org 홈 경유. SES-02 Soft Switch는 새 탭 구조 안에서 작동
• Workspace 전환 = Soft Switch (SES-02): 기존 세션 유지 + 대상 Workspace 신규 세션 발급. 전환 시점에 Workspace 접근 권한 + App 접근 권한 재검증 (SES-01/SES-03). 접근 가능 Workspace가 1개면 전환 메뉴 미노출
• 세션 초기화 대상 페이지·액션 정의 (Account doc 5.1 SES-02 미결 해소): M2 Gate에서 초기화 트리거 범위 확정 (현재 Account doc 줄 309 "추후 별도 기획 정의 예정" 상태)
• 다중 기기 동시 접속 제어 (SES-04, LGN-60): 동일 계정 다른 기기 신규 로그인 시 기존 세션 차단 팝업 — Account doc은 "추후 반영"으로 남겨두었으나 Phase 배치 명시 필요(현재 어느 Sub Stream에도 없음 → PLAN-G 묶음에 편입)
• Org Admin: 사용자 관리 (Org Admin / Org User 초대, 역할 변경, Lock은 시스템 자동 / Unlock은 본인 비밀번호 재설정으로만 — Org Admin/Master Admin 직접 해제 불가 — Backoffice Admin·Operator만 BOF-U-07로 직접 해제 가능 (v1.9 정정) — Multi-Org 26.04.29 정책 반영)
• 사용자 계정 한도 enforcement (LMT-01~07): Org Admin이 사용자 초대 시 한도 초과 차단 (Active+Locked 200/Org, MA 1, OA 3, AA 5/Workspace-App, External 50, Viewer 5). Inactive/Invitation은 카운트 제외
• Master Admin 최소 1명 유지 (v1.9, Backoffice §7 + BOF-U-05): 마지막 MA 계정 비활성화 차단 enforcement (계약 종료 전). MA 최소 1명·최대 1명
• Org Admin: MFA 강제 설정 (Org 단위 정책 — External User가 해당 Org에 들어올 때도 적용)
• MFA 멀티 Org 분기 (Account doc 줄 395 — PLAN-H): 단일 Org 로그인 후 즉시 MFA / 멀티 Org는 로그인 후 조직 선택 → 해당 Org MFA 진행. Main Stream의 M2는 단일 Org 전제, 멀티 Org MFA 흐름은 Release2 외부 사용자 고도화 범위 결정 후 정합
• Org Admin: MedDRA·WHODrug 라이선스 등록 + 주간 자동 만료 체크 (LIC-01~03) + 라이선스 자동 체크 → Org Audit Log 기록(Audit Log doc 6.2.3 줄 359-361)
• 라이선스 등록 화면 상세(TA-LIC-01~09): 버전별 MedDRA 드롭다운(지원 13개 버전), WHODrug 버전 고정 최신 1개, 빈값 시 버전 초기화, 타 Org 등록 ID 시 경고(TA-LIC-04) "이 ID는 [회사명]에 등록되어 있습니다"
• My Profile Name 필드 허용 문자 (D-1 정합 결정): PRF-13(한글/영문/숫자/공백/, . -) vs Home Navigation doc 2.3(영문/숫자/공백/, .) 문서 충돌 — Gate에서 한글·하이픈 허용 여부 단일 결정 필요
• App Admin 조회 전용 메뉴는 M3a/M3b 설정 데이터와 M10 SafetyDB Configuration Mirror 이후 활성화
• App Admin 메뉴 시점별 활성화 (v1.9, Org Admin App Admin 기획): M2에서 골격 생성 → 기준정보조회=M3b 완료 후 활성, ICSR설정조회=M3a 완료 후 활성, Audit Log 조회=A2 완료 후 활성 (단계별 flag 제거)
• 라이선스 관리 메뉴 고라이브 (v1.9, Org Admin App Admin 기획): TA-LIC-01~09 전체를 M2 범위에 포함 (계약 라이선스 현황, 만료 알림, MedDRA·WHODrug 등록·자동 만료 체크)

참고

• confluence/기획 문서/00. Common (공통 정책)/Home Navigation 기획
• confluence/기획 문서/00. Common (공통 정책)/Org Admin App Admin 기획
• confluence/기획 문서/00. Common (공통 정책)/Admin (Org Admin) (다이어그램 인덱스)
• confluence/기획 문서/00. Common (공통 정책)/Multi-Org 구조 및 관련 정책 (SES-01~03, LMT-01~07, LIC-01~03)

의존 M1 (로그인 완료)

DoD Master Admin이 Org Admin을 초대하고, Org Admin이 MedDRA 라이선스를 등록할 수 있다. 사용자 한도 초과 시 초대 차단되고, Workspace 전환 시 Soft Switch로 세션이 재발급되며 권한이 재검증된다.

목표. ICSR 케이스 보고에 필요한 식별자/발신자 설정이 가능하다.

구현 항목

• ICSR Config > Case ID 편집 화면 (조직 식별자, 연도, 보고 구분, 제품 약어, 일련번호 조합) - 자릿수 옵션 정합 (C-2 정정 필요): 본문(Case ID.md 110줄)은 3~9자리 7개 옵션, 와이어프레임 #5(289줄)는 5~9자리 5개 옵션. 본문 기준(3~9) 또는 와이어프레임 기준(5~9) 단일 결정 후 단위 테스트 입력 범위 확정 - 시작 번호 제한 정책 (Case ID.md 138~141): 시작 번호 ≤ (최대 가능 숫자 - 400) - 최후 번호 검증 (Case ID.md 128~132): 같은 조합의 기존 최후 번호보다 큰 값에서만 생성 시작. UI 입력값보다 시스템이 자동 보정 - 조합 변경 시 적용 시점 (Case ID.md 113): 자릿수/조합 변경은 이후 생성 케이스부터만 적용 - 연도 옵션 (v1.9 정정, Case ID.md 26.04.17 변경이력): 2-digit / 4-digit / N/A (Year+Month 조합은 26.04.17 삭제로 제외 — UI에 포함 금지) - 만료 임박 팝업 (Case ID.md 164~188): 남은 번호 ≤ 100일 때 케이스 생성(Manual/Import 완료) 시점 전체 사용자에게 팝업, "오늘 하루 보지 않기" 옵션, 자동 자릿수 확장 후 자동 미노출 - Import C.1.1/C.1.8.1 처리 옵션 A/B (Case ID.md 207~216): A(C.1.8.1만 유지) / B(C.1.1+C.1.8.1 유지). 기본값 A. 본 설정은 M3a 화면 범위, S4 Import 파이프라인 입력 - C.1.8.1 자동 복사 동기화 (Case ID.md 218~223): C.1.8.1 Null이면 C.1.1 값을 자동 복사 (Import 옵션과 별개, 상시 동작) - Case Level vs Report Level 노출 분리 (Case ID.md 226~234): Tracker/Case Edit은 일련번호만, ICSR 보고서(C.1.1/C.1.8.1)는 [국가]-[조직]-[일련번호] 형식
• Case ID 채번 엔진 (Zero-padding, 연도 리셋, 자릿수 자동 확장, 재사용 방지)
• ICSR Config > Sender 편집 화면 (Batch Sender ID, C.3.x 전체 필드, 국내 강제 계승 / 국외 선택적 계승) - Tenant Level 마스터 최대 1개 (Sender.md 31~43): Tenant Sender 마스터 단일 + Workspace Sender는 토글로 Tenant 상속/해제(국외만 토글 가능) - Sender 그룹 복사 (Sender.md 91~92): Batch Sender ID 제외 전체 필드 복사·붙여넣기 버튼 - C.3.1=7(Patient) 실시간 활성화 (Sender.md 120~122): C.3.1=7 즉시 C.3.2 필수 표시 해제
• Workspace Sender 화면 위치 (D-1 미결): Workspace Level Sender 편집이 Org Admin / App Admin / 별도 어디에 속하는지 M3a 착수 전 결정
• 이벤트 카탈로그 편입: Sender / Batch Sender ID / Case ID Rule 변경 → Org Audit Log (Audit Log doc 6.2.6, 6.2.7)

참고

• confluence/기획 문서/00. Common (공통 정책)/Admin (Org Admin)/ICSR Config/Case ID
• confluence/기획 문서/00. Common (공통 정책)/Admin (Org Admin)/ICSR Config/Sender
• confluence/기획 문서/00. Common (공통 정책)/Audit Log, Activity Log, Audit Trail (6.2.6/6.2.7 이벤트)

의존 M2 (Org Admin 화면)

DoD Org Admin이 Case ID 규칙 + Sender 1건 이상 등록할 수 있다. 변경 이벤트는 A1 이벤트 카탈로그 후보로 식별된다. Case ID 채번 엔진이 단위 테스트로 검증된다.

목표. 제품 마스터 3계층(Family/Products/Licenses)이 작동하고 RSI MedDRA Term을 코드+버전으로 등록할 수 있다.

구현 항목

• Product Config > Family (성분/브랜드군 등록, RSI 데이터시트 그룹, MedDRA Term 등록, Effective Date) - RSI 버전 일관성 경고 (Family.md 122~126): 기등록 MedDRA 버전과 현재 입력 버전 불일치 시 시각적 경고 아이콘 - RSI 일괄 Template 업로드 (Family.md 137): [추후 고도화 예정] — 섹션 6 트래킹 필요
• Product Config > Products (제형·규격·모델, Manufacturer Creatable Dropdown)
• Product Config > Licenses (국가별 허가, License Type, RSI 데이터시트 매핑, MFDS 성분코드) - 추가 필드 (Licenses.md 26~38): Biologic / Vaccine, Biosimilar, Not in Tradename Lookup / Not Auto-Scheduled 체크박스, Brand Information(MAH, 크리에이터블) 필수 — Products의 Manufacturer와 동일 드롭다운 마스터 공유
• M3b 내 최소 MedDRA Lookup 선행 구현: RSI Term 등록에 필요한 검색/선택/버전 저장 계약. 전체 Case Edit 팝업 UX는 M6에서 완성
• Family/Products/Licenses 삭제 제약 (Product_Config.md 72~76): 하위 계층 존재 시 상위 삭제 차단 + 상황별 오류 메시지
• 이벤트 카탈로그 편입: Family / RSI 그룹 / RSI Term / Product / License → Org Audit Log (Audit Log doc 6.2.4)

참고

• confluence/기획 문서/00. Common (공통 정책)/Admin (Org Admin)/Company Config/Product_Config
• confluence/기획 문서/00. Common (공통 정책)/Admin (Org Admin)/Company Config/Product_Config/Family
• confluence/기획 문서/00. Common (공통 정책)/Admin (Org Admin)/Company Config/Product_Config/Products
• confluence/기획 문서/00. Common (공통 정책)/Admin (Org Admin)/Company Config/Product_Config/Licenses
• confluence/기획 문서/00. Common (공통 정책)/Audit Log, Activity Log, Audit Trail (6.2.4 Product 이벤트)

의존 M3a (Sender/Case ID 기반 설정), MedDRA 라이선스/버전 데이터 최소 적재

DoD Org Admin이 Family/Products/Licenses 각 1건 이상 등록하고, RSI MedDRA Term 1건을 코드+버전과 함께 등록할 수 있다. 등록 이력이 Audit Log에 기록된다.

목표. 사용자가 Tracker 그리드에서 케이스 1건을 수동으로 생성할 수 있다.

구현 항목

• Tracker 그리드 컬럼 (전체, Tracker.md 4.1): Case ID(일련번호), C.1.8.1 (Approved 후 검은색/이전 회색), FU No (Null/Amend 필터 옵션 포함), Day0, AE Type, Report Type (C.1.3, Study일 경우 계획서 번호), Study ID (C.5.1.r.1, Tracker.md 26.05.14 추가, C.1.3=2일 때만 노출, Release2 Study Config 연동 필터), Product (내부 Drug Key 기반, Product Config 필터), Reported AE (E.i.1.2), RA Due (Day-N/D-Day/Missing/On Time/Overdue/NA/Late 구분 표시), Workflow 단계(Archived [추후] 옵션 포함), Owner (최초 생성 User) + Assignee (현재 단계 담당자) — Owner와 Assignee는 별개 컬럼
• Tracker.md 2.2절 'Assignee' 오기 정정 (v1.9): Tracker.md 2.2절 "최초 케이스 생성 시 — 생성한 사람이 담당자(Assignee) 컬럼에 자동 표시"는 4.1절 컬럼 표 및 Manual Intake.md 2.6절과 충돌 — '생성자 → Owner'가 정합. 기획서 본문 정정 필요 (M4 Gate)
• PLAN-AF (Tracker 필터 'Close' vs Workflow 'Complete' 용어 정합): Tracker.md 4.1 Workflow 컬럼 필터 옵션 "Close" vs Workflow.md 단계 "Complete" 용어 충돌. Close=Complete 동일 표기인지, 별도 상태인지 본 Phase 착수 전 결정 (PLAN-K 케이스 Close/Archived 상태 구현 Phase와 연계)
• 컬럼별 필터/검색, Date Range, 페이징 (목록 + 페이지네이션 backend 구현, 컬럼별 필터/검색 미확인)
• + New Case > Manual Intake 진입점 + 우클릭 컨텍스트 메뉴(Tracker.md 5): Case ID 우클릭 → Follow-Up 메뉴 → Case Edit FU 생성 페이지 진입
• Manual Intake 모달: 4대 요소 (보고자 / 환자 / 의약품 / 이상사례) + 보고 관리 필수값 입력
• 보고 구분(C.1.3), 최초 발생인지일(C.1.4), Day0/C.1.5, 원보고자 국가(C.2.r.3)
• Case ID Configuration 미설정 시 진입 차단 팝업 (Manual Intake.md 2.7.1, L92~95): "Organisation Home에서 Case ID Configuration을 먼저 진행해주세요…" — M10 SafetyDB Configuration 화면 차단과 별개로 Manual Intake 진입 시점에도 차단
• Product 불러오기 모달 (Licenses 연동) — PhPID 계층형 선택 UX (Manual Intake.md 4-1): L1(성분)/L2(성분+용량)/L3(성분+제형)/L4(전체)/Lic(허가제품명+국가) 선택, 공식 보고서 코딩 데이터 + 내부 식별 메타데이터 이중 저장 구조
• MedDRA-coded Event(E.i.2.1b) (M4에서는 필드/저장 경로를 먼저 구성하고, 검색 팝업 연동은 M6에서 후속 연결), 중대성(E.i.3.2a~f) 6개 체크박스, Reporting Criteria
• Reporting Criteria 3종 옵션 (v1.9, Manual Intake.md 3.1 L130): Related / Unknown / Not Related — Unknown은 AE Type 분류 시 M5b 인과성 보수적 처리(인과성 있음 간주) 원칙과 정합
• 인과성 3종 필드 (Manual Intake.md 3.1, L128~131) — v1.8 정정: - KRCT 평가 결과(G.k.9.i.2.r.3.KR.2) — 국내외 임상/치료목적 사용승인 건 기록 (L128) - WHO-UMC 평가 결과(G.k.9.i.2.r.3.KR.1) — 자발보고 및 시판 후 조사 건 기록 (L129) — Unlikely → Not Related 자동 매핑 - Result of Assessment(G.k.9.i.2.r.3) — 해외 파트너/국외 문헌 [선택] (L131) - 상호 비활성화 규칙: KRCT 입력 시 WHO-UMC 비활, WHO-UMC 입력 시 KRCT 비활
• E.i.3.2c/f 연동 옵션 필드 (Manual Intake.md, L122~127): 입원 시작/종료일, 기타 의학적으로 중요한 상황 설명 — E.i.3.2c/f 활성화에 연동
• 저장 → Toast + Case Edit 바로가기 / Tracker 복귀
• Manual FU 생성 ([+] 버튼): Tracker 행에서 [+] 클릭 시 기존 케이스의 후속보고(FU)를 수동 생성. Manual FU 생성 진입점과 C.1.5 입력/상속 경로 구성. FU No 자동 증가와 SEQ 정렬은 M5c 로직 완료 후 연동. 자동 FU 생성(XML/Amendment/Nullification 기반)은 S4에서 처리 — Main Stream의 Happy Path는 수동 FU만 지원
• PLAN-AD (Manual FU 3종 유형 모달 Main Stream 범위): 후속보고 순번 부여.md L84~88은 [+] 클릭 시 3종 유형(Follow-up / Amendment / Nullification) 선택 모달 명시. M4에서 모달 전체 노출 후 Amendment/Nullification는 S4 위임 처리할지, M4는 Follow-up 진입점만 처리할지 본 Phase 착수 전 결정
• PLAN-AB (Manual Intake 인과성 KRCT/WHO-UMC [필수] vs [선택] 충돌): Manual Intake.md 3.1 필드 명세는 KRCT/WHO-UMC를 [선택]으로 표기하나 5절 제안 구조는 [필수]로 표기. 동일 문서 내 충돌 — M4 착수 전 결정
• D-6 미결: Tracker Study ID 컬럼 vs Release2 Study 의존성: Tracker.md 최신(26.05.14)은 Study ID 컬럼을 신설하나 Study Config는 Release2. M4는 (a) Release2 이후로 컬럼 추가 미루기 또는 (b) M4에서 컬럼 자리만 비워두기 결정 필요

참고

• confluence/기획 문서/01. SafetyDB/Tracker
• confluence/기획 문서/01. SafetyDB/Tracker/Manual Intake
• confluence/기획 문서/01. SafetyDB/Rule & Logic/중복 후속 판별 로직/후속보고 순번 부여 및 탐지 로직 (Manual FU SEQ 부여)

의존 M3b (Product Master, License)

DoD (1) Manual Intake로 케이스 1건을 생성하면 C.1.3/C.1.4/C.1.5/C.2.r.3/E.i.2.1b/Reporting Criteria가 저장되고, Tracker에 새 행이 추가된다. AE Type/RA Due 자동 계산 표시는 M5b 엔진 완료 후 연동된다. (2) 기존 케이스 행에서 [+]로 Manual FU를 생성하면 Manual FU 생성 진입점에서 부모 케이스 데이터 상속 경로가 준비된다. FU No 자동 증가/SEQ 정렬은 M5c 완료 후 연동된다.

목표. ICSR 케이스의 데이터 스키마와 보고 출처 분류 로직이 작동한다.

구현 항목

• E2B(R3) 케이스 데이터 스키마 확정 (C/D/E/F/G/H 블록 DB 설계)
• 보고 출처 분류 (Main 범위) — 국내 자발보고/시판후 중심. C.1.3=2 Study 세부 분류(C.5.3/C.5.4)는 Release2 Source/Study Config에서 완성
• 보고 출처 fixture (자발보고 / 시판후 / 의료기관 등) 단위 테스트
• '분류 불가(Unclassifiable)' 처리 (보고 출처 분류.md / 보고 기한 설정.md 31~32): 명시된 규칙 외 조합은 Unclassifiable로 분류 → 관리자 검토 트리거 + Group A로 분류(AE Type 분류.md 56)
• 의약품 매칭 로직 미적용 처리 (보고 출처 분류.md 29, 38): Source a(국내 자발보고)·h(국외 자발보고)의 의약품 매칭 로직은 "추후 적용". 현재는 우선 분류, M3b 의약품 매칭 완성 시점에 재처리 경계 명시
• Receiver 10종 코드 ↔ Source Type 매핑 (D-3 정합 결정): M11a Receiver 코드(MFDS-O-CT/T-CT/...)가 Source Type 분류 결과에서 자동 결정되는 규칙. M5a/M11a/M11b 어디에 매핑 로직이 위치할지 본 Phase 착수 전 확정

참고

• confluence/기획 문서/01. SafetyDB/Rule & Logic (인덱스)
• confluence/기획 문서/01. SafetyDB/Rule & Logic/AE Type 분류 로직/보고 출처 분류

의존 M3a/M3b (Product Master, Case ID, Sender 스키마 동결)

DoD 국내 자발보고/시판후 fixture에 대해 보고 출처가 정확히 분류된다. C.1.3=2 Study fixture는 Release2로 분리한다.

목표. AE Type 6종 결과값(SUSAR/SADR/SAE/ADR/AE — SUSAR는 사망/치명적 + 기타 2분기로 보고 기한 7CD/15CD 분리)과 RA Due 산정 엔진이 작동한다. (v1.8 정정: "6종"은 결과 분류 개수, 보고 기한 경로는 7개)

구현 항목

• AE Type 분류 엔진 — 중대성(E.i.3.2a~f) → 인과성(보수적 처리) → 예측성(RSI 기반) → Group A/B 분기 → SUSAR(사망/치명적) / SUSAR(기타) / SADR / SAE / ADR / AE 결과 (SUSAR는 2분기로 7CD/15CD가 다름 — v1.6 표기 "6종"은 결과 값 수, 보고 기한 분기로는 SUSAR 2종 포함 7개 경로)
• 인과성 보수적 처리 원칙 (AE Type 분류.md 34, 41): 자체 평가 / KRCT / WHO-UMC 어느 하나도 값이 없을 때 안전을 위해 '인과성 있음'으로 간주
• 인과성 판정 코드값 (v1.9, AE Type 분류.md L37~42): - 자체 평가(G.k.9.i.2.r.3): Related 시 인과성 있음 - KRCT(G.k.9.i.2.r.3.KR.2): =1 (Related) 시 인과성 있음 - WHO-UMC(G.k.9.i.2.r.3.KR.1): 1, 2, 3, 5, 6 중 하나일 때 인과성 있음
• PLAN-AC 미결 (Source k 정기보고 기준일): Source k(국외 출처불명 파트너사)는 Group B에 속해 SADR 신속보고 15CD 대상이나, SAE/ADR/AE의 정기보고 기준일이 보고 기한 설정.md L42~45 매트릭스에서 누락. a/f/g와 동일 처리인지, 별도 기준일인지, 보고 대상 아님인지 본 Phase 착수 전 결정 필요
• 예측성 자사 의약품 한정 (AE Type 분류.md 45): 자사 의약품에 대해서만 예측성 평가 적용
• Group A/B 정확한 Source Type 매핑 (AE Type 분류.md 56, 69): Group A = b, c, i, 분류 불가 4종 / Group B = a, d, e, f, g, h, j, k 8종
• 보고 기한 (RA Due) 산정 — AE Type × Source Type 매트릭스, 신속 7CD/15CD/정기, C.1.5 기준 (보고 기한 설정.md 31)
• SADR + Source b/c/i 보고 제외 (보고 기한 설정.md 40): 임상/연구 출처의 SADR은 보고 대상 아님 → Submission List 노출 제외
• 정기보고 기준일 3종 (보고 기한 설정.md 42~44): - Source d(재심사): PBRER 제출일 기준 분기 종료 후 1개월 - Source e(미승인 연구): CSR 완료일 기준 분기 종료 후 1개월 - Source a/f/g(자발/문헌): 가장 최근 C.1.5 기준 분기 종료 후 1개월

참고

• confluence/기획 문서/01. SafetyDB/Rule & Logic/AE Type 분류 로직 (인덱스)
• confluence/기획 문서/01. SafetyDB/Rule & Logic/AE Type 분류 로직/AE Type 분류
• confluence/기획 문서/01. SafetyDB/Rule & Logic/AE Type 분류 로직/보고 기한 설정

의존 M5a (보고 출처 분류 + 스키마), M3b (RSI Term — Expectedness)

DoD 국내 자발보고/시판후/사망/예상성 차이/SUSAR 후보 fixture에서 AE Type + RA Due가 정확히 산출된다.

목표. 케이스 라이프사이클 상태 머신과 수동 중복 판별, 후속 SEQ 부여 로직이 작동한다.

구현 항목

• 케이스 상태 머신 — Entry→QC→MA→Approval→Completion + Draft/Validated/Ready to Submit + Lock/Unlock 역라우팅 (스키마/상태 전이 정의만, UI는 M9)
• 중복 로직 Logic B (Manual) — 주요 정보 필드 전수 일치 검증, 사용자 컨펌 모달 (Logic A XML 기반은 S4) - C.1.5 비교 정밀도 (중복 로직.md 27): YYYYMM까지만 비교 - Related Case ID 반환 (중복 로직.md 68): 신규 아님 판정 시 매칭된 기존 케이스 ID 함께 반환 - 컨펌 모달 액션 규칙 (중복 로직.md 93~96): "신규로 케이스 생성" → Case Edit 이동 / "입력 취소 후 Tracker 이동" → 데이터 비저장 - 중복 매칭 필드 비교 표시 UI (v1.9, 중복 로직.md 와이어프레임 #2 L100~104): 중복 판별 시 어떤 필드가 매칭되었는지 시각적 비교 표시(모달이 아니라 페이지 내 표시 허용) - 신규 케이스 생성 Toast + Case Edit 바로가기 버튼 (v1.9, 중복 로직.md 와이어프레임 #3 L104): 컨펌 모달 "신규로 케이스 생성하기" 선택 후 생성 완료 시 Toast 알림 + 알림창 내 Case Edit 바로가기 버튼 표시 - Logic B 시나리오 2 (C.1.8.1 입력 값이 있을 때) 공백 처리 — PLAN-AA로 격상: 중복 로직.md는 시나리오 1(C.1.8.1 없을 때)만 정의 — 시나리오 2 처리 방향(Logic A 동등 처리 vs Logic B 필드 전수 비교) 본 Phase 착수 전 결정 (PLAN-AA, M5c/M4 차단 가능성)
• 후속보고 SEQ 부여 (Initial = 'Initial', Tracker 표시 '0') — 내부 값은 'Initial' 문자열, Tracker 노출만 '0' (후속보고 순번 부여.md 42~43) - C.1.5 기준 정렬, 자사 수집 2단계 우선순위. Amendment/Nullification/재전송 5단계는 S4 - Tracker FU 표시 규칙 (후속보고 순번 부여.md 51): FU는 0/1/2..., Amendment는 'A', Nullification은 'N' - Follow-up 생성 모달의 C.1.5 입력 (후속보고 순번 부여.md 95~97): Follow-up 선택 시 date picker로 YYYY.MM.DD HH:MM:SS 입력 → 해당 케이스 C.1.5에 매핑 - Amendment/Nullification 선택 시 C.1.5 자동 상속 (v1.9, 후속보고 순번 부여.md L99~105): 사용자 입력 없이 이전 버전 C.1.5 값을 그대로 복사하여 생성 (Follow-up의 date picker 입력 흐름과 분리)

참고

• confluence/기획 문서/01. SafetyDB/Rule & Logic/중복 후속 판별 로직/중복 로직
• confluence/기획 문서/01. SafetyDB/Rule & Logic/중복 후속 판별 로직/후속보고 순번 부여 및 탐지 로직
• confluence/기획 문서/01. SafetyDB/Rule & Logic/케이스 상태

의존 M5b (AE Type 결과를 상태 머신 입력으로 사용)

DoD 케이스 상태 전이가 단위 테스트로 정확히 산출되고, Logic B Manual 중복 매칭과 Manual FU SEQ가 fixture에서 검증된다.

목표. Case Edit/Product 설정에서 MedDRA(이상사례/진단/적응증), WHODrug(글로벌 의약품/MPID), NeDrug/MFDS 국내 의약품 코딩이 가능하다.

🚨 선결 사항 (M6 착수 전 완료)

• MedDRA 라이선스 계약 + 분기별 버전 동기화 파이프라인 구축
• WHODrug Vendor Dictionary 라이선스/DB 또는 API 연동 방식 확정
• NeDrug API 또는 DB 파일 연동 방식 확정 (식약처 협의)
• MedDRA/WHODrug/NeDrug 팝업 3종의 UX/API/Data 계약 승인

Gate-M6-Coding-Popup-Spec

• UX 계약: 검색 조건, 결과 컬럼, 선택 후 부모 폼 반영 규칙, no-result/error/loading 상태 승인
• 데이터 계약: MedDRA hierarchy/version, WHODrug dictionary version/MPID·Drug Code, NeDrug source/version, Effective Date 저장 정책 승인
• API 계약: 검색 paging, exact/contains 검색, timeout/error response, 캐시 정책 승인
• 버전 정책: MedDRA/WHODrug/NeDrug 버전 전환 시 기존 케이스 display/validation 규칙 승인

구현 항목

• MedDRA 검색 팝업 (5계층 SOC>HLGT>HLT>PT>LLT)
• WHODrug 검색 팝업 (글로벌 의약품명/성분/WHODrug Code/MPID 검색, 국가코드 표시)
• NeDrug 검색 팝업 (국내 약품명/성분명/MFDS 코드 검색)
• 공통 팝업 컴포넌트 (검색 결과 그리드, 선택 후 부모 폼 반영)
• 외부 DB 버전 관리 (Dictionary Version / Effective Date 기반)

참고

• confluence/기획 문서/01. SafetyDB/검색 팝업 (인덱스)
• confluence/기획 문서/01. SafetyDB/검색 팝업/MedDRA 검색 팝업
• confluence/기획 문서/01. SafetyDB/검색 팝업/WHODrug 검색 팝업
• confluence/기획 문서/01. SafetyDB/검색 팝업/NeDrug 검색 팝업

의존 M2 (Org Admin 라이선스 등록), M3b (RSI MedDRA Lookup 계약), M4 (Manual Intake 연동 지점)

DoD 임의의 단어로 MedDRA PT, WHODrug 제품/MPID, NeDrug 약품/성분을 검색·선택해서 부모 폼 필드에 코드+버전/source가 반영된다. 검색 결과 0건, timeout, 라이선스 만료 상태가 구분된 메시지로 처리된다.

목표. Case Edit 화면의 골격(헤더/플로팅 Save/미저장 경고)과 Case 섹션이 작동한다.

구현 항목

• 고정 헤더 (Case ID, FU No, C.1.1, C.1.8.1, 단계, Delete + Unlock(Locked 조건부) + Close 버튼) — Case Complete는 Workflow 패널 3.2.5에 별도 위치(C-1 정정). v1.6 표기 "헤더 Case Complete"는 Case Edit.md 2.1과 충돌이므로 헤더에서 제거하고 Workflow 패널로 이동
• Close 버튼 동작 (v1.9, Case Edit.md §4.8 L132~134): 변경 사항이 있는 경우만 §4.6 미저장 경고 모달 표시, 변경 없으면 즉시 세션 종료(Tracker 복귀). 기획서 §4.8의 "변경 없이 Close 시 경고 표시" 서술은 §4.6과 충돌이며 실제 동작은 변경 시에만 경고
• FU 드롭다운 이탈 시 경고 (v1.9, Case Edit.md §2.1 FU 정보 비고): FU No 드롭다운에서 다른 케이스 선택 시 저장하지 않은 변경이 있으면 §4.6 미저장 경고 발생
• 스크롤 섹션 + 플로팅 Save + 미저장 경고
• 섹션 단위 저장 정책 (Case Edit.md 4.9, L142~144): Save는 6-섹션(Case/Patient/Event/Drug/Assessment/Narrative) 단위. 변경 없을 시 버튼 비활성. Assessment/Narrative 섹션의 Save 버튼 단위는 M8에서 구현하되, 6-섹션 단위 저장 정책 전체는 M7a에서 확정 (v1.9)
• 동시 편집 감지 (Case Edit.md 4.1, L83): 타 사용자 편집 중일 때 "[User Name]이 현재 편집 중입니다. 읽기 모드로 진입하시겠습니까?" Read-only 진입 모달
• 삭제 사유 모달 + 보고 이력 차단 (Case Edit.md 4.5, L113~122): 보고 이력 있는 케이스 / 타 사용자 편집 중 삭제 불가. 삭제 가능 케이스도 사유 필수 입력
• 외부 Validation 룰 의존 (Case Edit.md 1, L19): Case Edit 내 모든 MFDS 필드 Validation은 [MFDS 약물이상반응 및 이상사례 개별 항목 검증 룰] Excel 파일을 따른다 — 본 Excel 확보가 M7a~c/M8 착수 Gate 조건
• Case > Identification — C.1.1/C.1.8.1 Preview→Approval 확정, 인지일 선후 검증, C.1.7 자동 입력 (Identification.md 2.1, L37): C.3.4.5(Sender Country)=KR일 때 AE Type 기반 SUSAR/SADR→True, 그 외 False, KR 아닐 시 직접 입력
• Awareness date 자체 필드 (v1.9, Identification.md §2.1 L35): C.1.4/C.1.5와 별개의 인지일 필드(자체, 옵션, Date Picker YYYY MM 최소)
• C.1.11.1 자동 처리 로직 (v1.9, Identification.md §2.1 L39): 최초 Case 생성 시 비활성. FU Report 생성 시: Amendment=2, Nullification=1, Follow-up=값 없음 (M5c FU/Amendment/Nullification SEQ 로직과 연동)
• C.1.11.2 다국어 부가 입력 (v1.9, Identification.md §2.1 L40): 보고 무효화/수정 이유는 Free text + 언어 추가 입력 필드 지원
• C.1.6.1 추가 자료 그룹 (Identification.md 2.1, L41~44): C.1.6.1 자동(하위 값 존재 시 True), Document Type 13종 자체 필드, Documents Held by Sender(C.1.6.1.r.1), Included Documents(C.1.6.1.r.2 — PDF/JPEG/DICOM/TXT). 자동 True 처리 (v1.9 명시): C.1.6.1.Selta.1 / C.1.6.1.r.1 / C.1.6.1.r.2 중 하나라도 값이 있으면 True 자동 입력 → C.1.6.1.r.1 묶음 섹션 활성화
• C.1.9.1 이전 보고자관리번호 + C.1.10.r 연결 보고 (Identification.md 2.1, L46~51): C.1.9.1.r.2는 파트너사 Import 시 원본 C.1.1 자동 추가
• Report FU No from previous sender 자체 필드 (v1.9, Identification.md §2.1 L49): 이전 전송에서의 추적보고 연번. 용도 — Reconciliation Module 검증 시 사용 (S4 Import 고도화와 연계)
• Type of Report Link + C.1.10.r 조건부 필수 (v1.9, Identification.md §2.1 L50~51): Type of the Report Link(참조 보고 유형, 6종 옵션) 선택 시 C.1.10.r(Identification Number of the Report Which Is Linked) 필수 입력 검증
• C.1.1/C.1.8.1 불변 정책 (Identification.md 4.4, L116): Approval(Approved) 확정값은 승인 취소 후에도 변경 불가
• Case > Reporter — C.2.r.3 Intake 연동, C.2.r.4 자격 → E.i.8 동적 활성화 (주의: Reporter.md §4.2 표의 "Reporter's City" 오기는 실제 C.2.r.4(Qualification)를 지칭. 구현 시 C.2.r.2.4(City)와 혼동 금지 — v1.9 정정 주석) - 주소 3필드 1+ 필수 (Reporter.md 4.3, L103~108): Street(C.2.r.2.3) / City(C.2.r.2.4) / State or Province(C.2.r.2.5) 중 1개 이상 - C.2.r.4.KR.1 Other Health Professional Type (Reporter.md 2.1, L53): C.2.r.4=3일 때만 활성 (Nurse/Other) - Sender 정보 불러오기 버튼 (v1.9, Reporter.md §3.1 L88~107): 버튼 클릭 시 ICSR Config > Sender 등록 Batch ID 리스트 팝업 → 선택 시 C.3.x 매핑 필드 자동 입력 (기존 입력값 Overwrite)

참고

• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Case (컨테이너)
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Case/Identification
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Case/Reporter

의존 M4 (Tracker/Intake)

DoD Manual Intake로 생성된 케이스가 Case Edit에서 열리고, Case 섹션(Identification + Reporter)을 입력·저장할 수 있다. 미저장 상태 이탈 시 경고가 노출된다.

목표. Case Edit에서 환자/의약품 핵심 필드를 입력·수정할 수 있다.

구현 항목

• Patient > Patient — D.1 Intake 연동, D.2 연령 그룹 상호 배타, D.5→D.6 동적 제어 - D.2 XML 출력 우선순위 (Patient (1).md 4.1, L80~84): D.2.1 → D.2.2 → D.2.2.1 → D.2.3 순으로 1개만 XML 출력
• Drug 컨테이너 + 탭 — Drug 시퀀스 단위 일괄 저장 (Drug.md L19~22): Drug 1/2/3/4가 각각 저장되지 않고 한 의약품(시퀀스) 단위로 전체 저장. v1.6 "탭 단위 일괄 저장" 표현은 시퀀스 단위로 정정 (D-1 정합). Product 불러오기 위치
• Drug 시퀀스 내 탭 이동 미저장 경고 정책 (v1.9, Drug.md L19~22): Drug 1~4 탭 이동 시 미저장 경고 미발생(동일 시퀀스 내 이동). 다른 섹션 이탈 시에는 §4.6 경고 발생
• Drug 1 — G.k.2.2 Intake 연동, G.k.1 구분, MFDS/NeDrug 팝업, G.k.3 허가 (WHODrug는 Release2) - [Release 2 예정] G.k.2.5 Investigational Product Blinded 처리 (v1.9, Drug/1.md §4.2 L88~93): Console > Company > Study Info > Blinding ≠ Open-Label AND C.5.Selta.1 Value=Blinded일 때만 True 전송, 그 외 XML 미포함. Release2 Study Config 완료 후 활성화 — 본 Phase에서는 미구현 표기만
• Drug 2 — G.k.2.3.r 성분 반복, NeDrug 팝업, UCUM 단위 - PLAN-M 확장 (v1.9): Drug 2의 G.k.2.3.r.2a/b TermID(WHODrug 의존)도 Medical History/Parent WHODrug 의존 필드와 동일 패턴 — PLAN-M 결정 범위에 편입
• Drug 3 — G.k.4.r 투여 반복, 날짜 선후 검증, 제형·투여경로 EDQM - Frequency 17종 자체 필드 (Drug/3.md 2.1, L33): QD/BID/TID/QID 등 17종 - nullFlavor 처리 (Drug/3.md 4.3, L122): 날짜 미상 시 MSK/ASKU/NASK 대체 가능 - G.k.4.r.3 특수 단위 시 G.k.4.r.2 공란 처리 (v1.9, Drug/3.md §4.2 L109~113): G.k.4.r.3이 {cyclical} / {asnecessary} / {total} 중 하나일 때 G.k.4.r.2 수치는 공란 처리 - G.k.4.r.4/5 미래 일자 입력 차단 (v1.9, Drug/3.md §4.3 L119~123): 투여 시작일/종료일 미래 일자 입력 금지 (날짜 선후 검증과 별도 규칙) - EDQM Dose Form/Route ID↔Term 매핑 표시 (v1.9, Drug/3.md §2.1 L43, L46): G.k.4.r.9.2b/G.k.4.r.10.2b는 XML에 ID 입력, 화면에서는 Term으로 표시. EDQM 코드 테이블 조회 방식은 PLAN-W 확장 범위에서 결정
• Drug 4 — G.k.5~G.k.11 누적/적응증/조치 - G.k.8 조건부 필수 (Drug/4.md 2.1, L36) - G.k.6 노출 시 임신 기간 (Drug/4.md 4.2, L86~90): Patient 섹션 임신 기간 정보 존재 시에만 활성화 (교차 섹션 조건부) - G.k.5a 누적 투여량 자동 제안 (Drug/4.md 3, 4.3): G.k.4.r.1a 합산값을 G.k.5a로 자동 제안

참고

• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Patient (컨테이너)
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Patient/Patient (1)
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Drug
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Drug/1
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Drug/2
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Drug/3
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Drug/4

의존 M7a (Case Edit 공통 layout)

DoD Patient(1)는 섹션 단위 저장, Drug는 시퀀스(의약품 1건) 단위로 1~4 섹션 일괄 저장(Drug.md L19~22)되고, NeDrug/EDQM/UCUM 매핑이 정확히 반영된다.

목표. Case Edit Event 섹션과 케이스 필드 변경 시 최소 Audit Trail 원장 기록이 작동한다.

구현 항목

• Event — E.i 반복 탭, MedDRA 코딩, 6개 중대성+NI 자동, Intake 연동, E.i.4~7 - E.i.1.1a/E.i.1.1b 원보고자 현지언어 + E.i.9 발현 국가 (Event.md 2.1, L34~35, L58) - E.i.3.1 Term Highlighted by Reporter (Event.md 2.1, L39): 4종 옵션 - Special Situation 자체 필드 16종 (Event.md 2.1, L40): Lack of efficacy / Medication errors / Overdose / Misuse / Abuse / Counterfeit 등 - Severity + CTCAE 자체 필드 (Event.md 2.1, L50~51): Severity 4종, CTCAE 6종 - 교차 섹션 Completion Check (Event.md 3, L118): E.i.3.2a=True OR E.i.7=5 → Death 섹션(D.9) 입력 필요 트리거 - Hospitalization 날짜 검증 (v1.9, Event.md §4.3 L147~150): E.i.3.2c 선택 시 확장되는 Hospitalization Start/End 날짜는 Start ≤ End 역전 불가 + 최소 일(Day) 단위까지 입력 필수
• 최소 Case Audit Trail 훅 — 케이스 필드 저장 시 변경 전/후 값, 사용자, 시간, Revision Sequence 기록 (조회/Export 고도화는 S1)
• Audit Trail은 A1 인프라와 별도 원장 — Case Audit Trail은 케이스 필드 변경 전용
• PLAN-O 결정 필요(Lock 시점): Workflow.md 3.2.4는 "Approval 단계 진입 시 Lock" / Case Edit.md 4.1은 "Approved 이후 Read-only". 본 Phase 또는 M9 착수 전 단일 기준 결정

참고

• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Event
• confluence/기획 문서/01. SafetyDB/Case Audit Trail (최소 훅 부분만)

의존 M7b (Drug/Patient 섹션 완료)

DoD Event 1+ 입력 시 6중대성/NI 자동 계산이 작동하고, 케이스 필드 변경 시 Audit Trail 원장에 변경 전/후 값이 기록된다.

목표. 인과성 평가 매트릭스가 자동 생성되고 Narrative를 입력하면 케이스가 보고 준비 상태에 도달할 수 있다.

구현 항목

• Assessment: Drug-Event 매트릭스 자동 생성 (E.i.2.1b 기반)
• Intake → Assessment 1행 자동 생성 (Assessment.md 3, L96): Intake에서 Reported Causality 입력 시 자동 1행 생성 (Source=Qualification, Method=Global introspection, Causality=Intake 값)
• 시간 간격 자동 계산 — 두 쌍 분리 (Assessment.md 4.1, L101~107): - G.k.9.i.3.1a: E.i.4 − G.k.4.r.4 (투여 시작 → 발현) - G.k.9.i.3.2a: E.i.4 − G.k.4.r.5 (최종 투여 → 발현)
• MFDS Method of Assessment 자동 입력 — 3단계 우선순위 (Assessment.md 4.2, L110~127): - ① 원보고자 국가코드 ≠ KR → 비활성 - ② C.1.3=2 AND (C.5.4=1 또는 2) → "2" KRCT 자동 - ③ 나머지 → "1" WHO-UMC 자동
• Reporting Criteria Intake 연동
• Event Expectedness + RSI 자동 비교 (Family RSI 의존)
• 인과성 평가 반복 (G.k.9.i.2.r) — 자체 평가 + KRCT + WHO-UMC
• G.k.9.i.4 재투여/재발현 여부 필드 (Assessment.md 2.1, L38)
• Narrative: H.1 필수 자유 텍스트, H.2 Reporter's Comments(Narrative.md 2.1, L32), H.3.r Sender's Diagnosis (MedDRA LLT + PT + SOC 삼원 자동 표시 — v1.9 정정: H.3.r.1b MedDRA 코드 입력 시 LLT Term/PT Term/SOC Term 동시 자동 표시. 기존 표기는 PT 누락), H.4, H.5.r 다국어

참고

• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Assessment
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Narrative

의존 M7c (Event/Drug 섹션), M5b (AE Type 엔진 — Expectedness)

DoD 케이스에 의약품 1+ 이상사례 1+ 를 입력하면 Assessment 매트릭스 1행이 자동 생성되고 시간 간격이 계산된다.

목표. 케이스가 단계별 사용자에게 이송되어 승인까지 도달한다.

🚨 선결 사항 (M9 착수 전 기획팀 결정 필요)

• RA Triage 단계의 위치 확정: Submission.md v78 2절/3.1절은 "Workflow 단계 'RA Triage'가 완료되면 Submission 상태가 'Draft'로 변경" 으로 명시하나, Tracker/Workflow.md v11은 Entry/QC/MA/Approval/Completion 5단계만 정의 — RA Triage가 (a) QC 또는 MA의 하위 액션인지 (b) MA와 Approval 사이의 별도 6번째 단계인지 미정. 본 결정에 따라 M9 단계 수, M11a 트리거 시점, Submission Status 머신이 변경됨. (섹션 6 미결 #PLAN-A 참조)

Gate-M9-RA-Triage-Decision (M9 착수 차단 게이트)

• 결정 없이는 M9 개발 착수 불가.
• 결정 영향 범위: Workflow state machine, Submission Draft trigger, Ready to Submit eligibility, Audit event taxonomy, Notification event, Tracker column semantics, M11a Submission List 노출 조건.

구현 항목

• 단계 이송 (Send to QC/MA/Approval) — RA Triage 정합성 결정 후 단계 수 확정
• 담당자 미지정 시 Send 차단 (Workflow.md 4.2, L143~145)
• 채팅형 코멘트 + 타임라인 — 타임라인에 단계 변경/코멘트/저장 이력/Lock·Unlock 시계열 기록 (Workflow.md 4.6, L173~174)
• 케이스 의견(User Context Comment) Audit Trail 자동 기록 (v1.10, Case Audit Trail.md 26.05.15 감사 로그 카테고리 표): 코멘트 NEW/EDIT/DELETE 발생 시 M7c Case Audit Trail 훅을 통해 Category=User Context, Classification=Comment, Element=Comment, Value=해당 코멘트 입력 값, Performer=행위자 유저 이름으로 기록. Workflow Chat 타임라인 저장과 별개 저장소 — D-5 결정 결과와 정합. 실제 조회/Export UI는 S1
• App User 전원 Chat/Workflow 접근 가능 (Workflow.md 4.7, L178~180): Case Lock 상태에서도 Chat Room과 Workflow에 접근 및 액션 가능
• Lock 시작 시점 — PLAN-O 결정 후 확정 (현재 미결): Workflow.md 3.2.4 "Approval 단계 진입 시 Lock" vs Case Edit.md 4.1 "Approved 이후 Read-only" 충돌. 본 Phase 착수 전 단일 기준 결정 필수. 다음 두 항목은 PLAN-O 결정 결과에 따라 채택 (현재 두 시점 모두 표기, 결정 후 1개만 활성): - (옵션 A — Workflow.md 기준) MA → Approval 라우팅 시 자동 Lock, Approval(In Progress) 표시 - (옵션 B — Case Edit.md 기준) Approval(Approved) 확정 시 Lock
• Approve / Reject → Approved 시 Lock 유지, Reject 시 Entry/QC/MA 선택 라우팅
• Unlock 시 기존 승인 Invalidated 처리 + Entry/QC/MA 선택 라우팅 + 수정 사유 필수
• Case Complete 버튼 (Completion 단계) — Workflow 패널 위치 (C-1 정정)
• Tracker Workflow 컬럼 + Lock 아이콘
• 상태 변경 → Submission Status 자동 동기화: Gate-M9 결정 결과에 따라 Draft 전환 트리거를 구현 / 케이스 Validation 통과 → 내부 상태 Validated (화면에는 여전히 Draft 표시) / Approval(Approved) + 최소 Validation 통과 → Ready to Submit
• RA Triage 완료 → Submission Status Draft 전환 트리거 구현 (v1.9, Submission.md §3.2 L68): PLAN-A(RA Triage 위치) 결정 결과에 따라 본 Phase에서 Submission Status Draft 전환 트리거를 명시적으로 구현. M11a 화면 노출 조건의 시작점
• Workflow 타임라인 저장 이력 vs Case Audit Trail 분리 (D-5): "Workflow 타임라인의 저장 이력"이 Case Audit Trail과 동일 저장소를 사용하는지 별개 저장소인지를 본 Phase 착수 전 결정 (M7c 훅과 경계 명시)

참고

• confluence/기획 문서/01. SafetyDB/Tracker/Workflow
• confluence/기획 문서/01. SafetyDB/Rule & Logic/케이스 상태 (상태머신 재참조)
• confluence/기획 문서/01. SafetyDB/Submission (RA Triage 트리거 명시)

의존 M8 (Assessment 완료 후 Validation 가능), M5c (상태 머신 스키마)

DoD Entry에서 시작한 케이스가 QC, MA를 거쳐 Approval 단계에서 PLAN-O 결정에 따른 단일 Lock 시점에 Locked 상태가 되고, Approve 후 Approval(Approved) 상태로 표시된다. Unlock 시 승인 무효화와 역라우팅 사유가 기록된다. RA Triage 완료 시점이 정의되어 Submission Status가 Draft로 자동 전환된다. (v1.9 검증 정정: PLAN-O 미결 동안 DoD는 단정하지 않고 결정 후 단일 시점으로 확정)

Acceptance Criteria / Verification

• RA Triage 결정안에 따라 Draft 전환 이벤트가 정확히 1회만 발생한다.
• PLAN-O 결정에 따른 Lock 시점(Approval 진입 / Approved 완료 / Case Edit Approved 이후 중 1개)에 정확히 1회만 Lock이 적용된다.
• Reject/Unlock 시 사유가 필수이며 이전 승인 상태는 Invalidated로 남는다.
• Ready to Submit 전이는 Approved + 최소 Validation 통과 조건을 모두 만족할 때만 가능하다.
• Verification: 상태 머신 unit test + workflow E2E + audit event integration test (Lock 시점 시나리오는 PLAN-O 결정 후 fixture 확정).

목표. SafetyDB 앱 내에서 Org Admin의 Case ID / Sender 설정을 Read-Only로 확인할 수 있다.

구현 항목

• SafetyDB Configuration > Case ID — Org Admin Case ID 미러 (제약사는 Read-Only)
• SafetyDB Configuration > Sender — Org Admin Sender 미러 (제약사 Read-Only / CRO는 다르게 적용 — Sender (Safety Config).md 17~19). CRO 케이스 처리 방식 본 Phase 착수 전 결정
• Case ID 미설정 시 Import/케이스 생성 차단 팝업 (XML Import 2.7 정책)
• (v1.11) 참고 기획서 3건은 spec-by-reference shell 상태 — Configuration.md 본문 1줄 / Case ID (Safety Config).md "Org Admin 미러" 한 문장 / Sender (Safety Config).md "제약사 Read Only / CRO 다름" 두 문장. M10 착수 전 CRO 분기 사양 본문 작성 선행 필요 (Gate 차단 조건, §6 참조).

참고

• confluence/기획 문서/01. SafetyDB/Configuration
• confluence/기획 문서/01. SafetyDB/Configuration/Case ID (Safety Config)
• confluence/기획 문서/01. SafetyDB/Configuration/Sender (Safety Config)

의존 M3a (Org Admin Case ID/Sender 원본)

DoD SafetyDB Configuration 메뉴 진입 시 Org Admin이 설정한 Case ID와 Sender가 그대로 표시된다.

목표. Approved 케이스가 Submission List에 노출되고 Submission Status 머신이 정확히 동작한다. 실제 배치 생성·MFDS AS2 전송은 M11b에서 다룬다.

구현 항목

• Submission Status 상태 머신: 내부 상태 3종 (Draft / Validated / Ready to Submit) - 화면 표시 규칙 (Submission.md 3.2 명시): 화면 표시 상태는 Draft / Ready to Submit 2종만. Validated는 내부 추적용이며 List/필터 UI에서는 Draft로 표시. Submission Status 필터 최대 2개 선택 가능. - RA Validation 정의 (Submission.md 39, 69): Draft → Validated 전환은 "RA Validation 완료(문제 없음)" 시점. Validated 뱃지는 is_validated boolean 조건. RA Validation에 포함되는 Validation set은 M11a 착수 전 정의 필요 (현재 미정 — Main 최소 Validation slice와 정합 결정)
• Submission List 화면 — Expedited / Periodic 탭, 필터/검색, Due Date 정렬 - 페이지당 25건, Due Date(RA) 가장 임박순 → Case ID 오름차순 동률 처리 - Periodic 탭 필터 조건 (Submission.md 70, 198): RA 값이 있고 신속보고 여부에 체크되어 있지 않은 케이스만 노출 - 필터: C.1.1/C.1.8.1 키워드, Case Owner(다중 5), Workflow Status(다중 3), Submission Status(다중 2), Receiver(단일 1) - 'Validated만 보기' 체크박스 (v1.9, Submission.md 2026-05-13 신설): Submission Status 필터 Draft 선택 시 'Validated만 보기' 체크박스 활성화 (is_validated boolean 조건 필터)
• Receiver 10종 코드 (MFDS-O-CT/T-CT/O-CF/T-CF/O-CU/T-CU/O-KR/T-KR/O-FR/T-FR) — 화면 표시명 매핑 ("임상 시험 국내", "시판 후 국내 (TEST)" 등)
• PLAN-I 미결: Study N.2.r.3 ↔ Receiver 코드 연계 (D-3): Study Config에 사전 설정된 N.2.r.3(Message Receiver Identifier)이 M11a Receiver 선택을 자동 결정/Override하는 규칙. 임상 케이스(C.1.3=2) Submission 흐름에 직접 영향
• Submit 버튼 + 확인 팝업 (UI만, 실제 배치 생성은 M11b)
• 배치 생성 조건: Ready to Submit 단일 조건 (Draft/Validated 케이스 선택 시 에러 "Submission Status가 Ready to Submit 일때만 보고 할 수 있습니다.")

참고

• confluence/기획 문서/01. SafetyDB/Submission
• confluence/기획 문서/01. SafetyDB/Submission/Submission List (메타)

의존 M9 (Workflow Approved 상태), M10 (Sender 확인)

DoD Ready to Submit 케이스가 Submission List에 노출되고 필터/페이징이 정상 동작한다. Submit 버튼 클릭 시 확인 팝업까지 진행된다(실 전송은 M11b 완료 후).

🚨 선결 사항 (M11b 착수 전 완료)

• MFDS AS2 게이트웨이 Test 환경 계정 발급
• 공휴일 마스터 데이터 테이블 구축 (2영업일 ACK Timeout 계산용)
• 최소 Validation Slice 완료: 필수 필드, E2B 구조, Receiver별 rule, Draft/Validated/Ready to Submit 전이 조건

목표. 선택된 케이스들이 E2B 배치 XML로 묶여 MFDS AS2 Test 환경에 전송 성공한다(ACK 수신 전).

구현 항목

• 배치 생성 엔진 (Receiver 유효성, 동시 25건 제한, N.1.5만 배치 생성 시점 타임스탬프로 세팅 — N.2.r.4 / C.1.2는 건드리지 않음. C.1.2는 케이스별 ICSR 버전 타임스탬프이며 케이스 내용 변경 시에만 갱신, 배치 재생성은 케이스 변경이 아니므로 갱신 불필요 (Submission.md 2026-04-28 정정 정책), N.1.3 Sender 삽입)
• N.1.x 배치 메타데이터 전수 처리 (Submission.md 156~158, 표 1): N.1.1/N.1.2/N.1.3/N.1.4/N.1.5 각 필드 세팅 규칙 — N.1.5만 갱신 정책 외 N.1.1/N.1.2/N.1.4 처리 규칙도 본 Phase에서 정의
• 동일 Receiver만 한 배치로 묶음 — 상이한 Receiver 혼재 시 자동 차단 (IS-1678)
• System Freeze (보고 진행 케이스 수정 잠금, List에서 제외) — 해제 시점은 ACK 수신 또는 Timeout 시
• 영업일 계산 단위 (Submission.md 191, 표 4): 1영업일 = 8시간, 토·일·공휴일 제외. 2영업일 ACK Timeout 계산에 적용
• E2B(R3) XML 생성 (모든 케이스 필드 매핑)
• MFDS AS2 게이트웨이 전송 — Queued → Transmitting → Waiting ACK

참고

• confluence/기획 문서/01. SafetyDB/Submission
• confluence/기획 문서/01. SafetyDB/Tracker/Case Edit/Case Edit_Field Type (E2B 필드 분류 — 일부 참조)

의존 M11a (List + 상태 머신), MFDS AS2 Test 계정, 공휴일 데이터

DoD Approved 케이스 1건이 Submit 버튼으로 MFDS Test 환경에 전송 성공한다 (ACK 수신 전).

Acceptance Criteria / Verification

• Ready to Submit 케이스만 선택 가능하다. Draft/Validated 선택 시 지정 문구로 차단된다.
• Receiver가 다른 케이스는 같은 배치로 묶이지 않는다.
• 25건 초과 선택, Sender 미설정, Case ID/Sender 설정 불일치, XML validation 실패가 각각 별도 오류로 기록된다.
• 배치 생성 시 N.1.5만 갱신하고 N.2.r.4/C.1.2는 변경하지 않는다.
• System Freeze 적용 후 케이스 수정/삭제/재제출 중복 클릭이 차단된다.
• Verification: XML golden fixture, Receiver 혼재 integration test, 25건 제한 E2E, MFDS Test AS2 sandbox 전송 증적.

Failure / Recovery / Observability

• 실패 경로: XML validation fail, AS2 connection fail, AS2 timeout, duplicate submit click, partial batch creation fail.
• 재시도 정책: 전송 전 실패는 배치 폐기 후 Draft 유지, 전송 후 실패는 Submission Monitoring에서 수동 재시도/운영자 개입 경로로 처리.
• 중복 전송 방지: batch idempotency key를 생성하고 동일 케이스+Receiver+N.1.5 조합 재전송을 차단한다.
• 운영 지표: XML validation failure count, AS2 transmit failure count, duplicate submit blocked count, batch stuck duration.
• Runbook 기준: AS2 connection fail은 3회까지 5분 간격 재시도, 15분 이상 Transmitting 지속 시 stuck batch로 분류.

목표. 전송한 배치의 ACK를 수신하여 결과(Success/Fail)를 자동 매핑하고, 전체 보고 흐름이 감사 추적된다.

구현 항목

• Submission Monitoring 화면 — 2-depth Expandable Row (배치 + 케이스)
• Progress 단계 (Queued / Transmitting / Waiting ACK / Receive ACK)
• ACK 수신 파서 (AA/AE/AR/CA/CR + R/P/C/N 상세)
• ACK Comment 툴팁 (Submission.md 132): AA/AE/AR/CA/CR/R/P/C/N 각 코드에 한국어 설명 툴팁 UI
• ACK 자동 매핑 (배치 레벨 / 케이스 레벨 분기)
• 접수 완료 조건 (Submission.md 126): ACK.A.4=AA AND ACK.B.r.6=CA → 접수 완료. 그 외(AR/AE/CR)는 재보고 후 접수 완료 시점에서 다시 판단
• 배치 Fail 시 케이스별 Result 분기 표시 (Submission.md 129): 배치 Fail이지만 문제 없는 케이스(CA)는 Result '-', 문제 있는 케이스(CR)는 'Fail'. On-Time/Late 전체 케이스는 '-'
• 오류 시 케이스 Draft 복귀 자동 처리
• On-Time / Late 자동 판정 (Due Date vs ACK 시간) — 재보고 케이스의 On-Time/Late 재판정 시점 규칙 본 Phase에서 정의
• ACK Timeout (2영업일) → Draft 복귀 배치 잡 — 영업일=8시간, 토·일·공휴일 제외
• 전송 파일 + ACK 파일 영구 보관 (변조/삭제 불가)
• 이벤트 카탈로그 편입: Submission 이벤트는 A1 인프라에 분류 규칙에 맞게 등록

참고

• confluence/기획 문서/01. SafetyDB/Submission (SSoT, 7단계 흐름 재참조)
• confluence/기획 문서/01. SafetyDB/Submission/Submitting Monitoring (메타)

의존 M11b (전송 성공)

DoD MFDS Test 환경에서 ACK 수신 후 Submission Monitoring에 Success/Fail이 자동 매핑되어 표시된다. Submission 이벤트는 A1 이벤트 카탈로그 후보로 식별되고, 케이스 상태/필드 변경은 Audit Trail 원장과 연결된다.

Acceptance Criteria / Verification

• ACK AA/AE/AR/CA/CR 및 R/P/C/N 상세가 배치/케이스 레벨에 정확히 매핑된다.
• ACK Fail 또는 Timeout 시 System Freeze가 해제되고 케이스가 Draft로 복귀하며 실패 사유가 남는다.
• ACK 파일, 전송 XML, 사용자 조작, 시스템 상태 전이는 삭제/변조 불가 저장소에 보관된다.
• On-Time/Late 판정은 공휴일 마스터 데이터 기준 2영업일 timeout 규칙과 일치한다.
• Verification: ACK fixture parser unit test + timeout batch job integration test + Submission Monitoring E2E + audit evidence review.

Failure / Recovery / Observability

• 실패 경로: ACK parse fail, partial ACK, ACK timeout, storage write fail, Draft 복귀 실패.
• 수동 개입: 운영자가 batch stuck 상태를 확인하고 재처리/수동 종료/고객 공지를 결정하는 runbook을 작성한다.
• 운영 지표: ACK timeout count, ACK parse failure count, stuck batch count, Draft recovery failure count, audit evidence write failure count.
• 알림 경계: 사용자 업무 알림은 Release2 알림 트랙에서 확장하되, 운영 장애 알림은 M12의 최소 관측성 범위에 포함한다.

우선순위 근거. 개인정보 처리방침과 최소 운영 증적은 운영 고도화가 아니라 서비스 공개 선결 조건이다. 법인명, 개인정보 보호책임자, 연락처, 시행일이 미정이면 제한 고객 Pilot도 진행할 수 없다.

구현/확정 항목

• 개인정보 처리방침 법인명/책임자/연락처/시행일 확정
• My Profile / Footer / 약관 링크 연결 — PRF-16(My Profile 모달), PRF-23(Password 탭 링크) 구체 구현 본 Gate에 포함
• 180일 비밀번호 만료 화면(M1 PWD-04) 활성화 확인: 고라이브 시점 개발 항목, Pilot 진입 시 실제 만료 카운트 동작 검증
• 로그 보존 정책과 개인정보 보존 정책 정합성 확인 (A3 enforcement 결과 검증) — App/Workspace 단위 D+60 잡 동작 포함
• 최소 Case Audit Trail 원장 동작 확인 (M7c에서 구현한 field before/after 기록)
• MFDS Test AS2 전송/ACK evidence 보관
• 제한 고객/제한 케이스 범위 명시, known issue 승인
• 장애 대응 연락망 + M11b/M12 운영 runbook 초안
• Pilot success metrics: 제한 고객 1곳, 자발보고 케이스 3건 이상 end-to-end 성공, ACK timeout/parse failure P1 이상 0건, P0/P1 open issue 0건
• Go/No-Go 기준: P0/P1 미해결, 개인정보/권한/감사 증적 결함, MFDS Test evidence 부재 시 No-Go

참고

• confluence/기획 문서/00. Common (공통 정책)/개인정보 처리방침 (초안)
• confluence/기획 문서/00. Common (공통 정책)/Audit Log, Activity Log, Audit Trail

우선순위 근거. GA는 기능 완료가 아니라 운영 책임 인수다. 규제 SaaS는 제출 Happy Path만으로 일반 고객 사용을 열면 안 된다.

필수 승인 항목

• Security verification: tenant isolation, cross-org denial, role matrix, break-glass 접근 차단/감사 증적
• Backup/restore drill: 케이스, XML, ACK, Audit Trail 복구 리허설
• Incident response: MFDS AS2 장애, ACK timeout 급증, XML validation failure 급증 runbook
• Production monitoring: M11b/M12 운영 지표 dashboard/alert
• Access review: Backoffice/Admin 권한 점검, 퇴사/잠금/Inactive 처리 확인
• Data retention/deletion test: Terminated D+60 삭제/추출 정책 검증 (A3 enforcement 결과)
• UAT sign-off: 제한 고객 담당자 승인