iVigilance Square,
한 권으로 읽는 이야기

세상에 약(藥)이 나오면, 그 약을 먹은 사람의 몸은 의도하지 않은 방향으로 반응한다. 두통, 발진, 호흡 곤란, 때로는 사망까지. 이런 사건을 우리는 이상사례(Adverse Event, AE)라고 부른다. 그리고 제약회사는 법적으로, 이 모든 이상사례를 수집하고 평가하고, 정해진 기한 안에 규제기관(한국에서는 MFDS, 식약처)에 보고해야 한다.

이 일을 하는 부서를 PV(Pharmacovigilance, 약물감시) 부서라 부른다. PV 담당자는 매일 수십 건의 사례를 다룬다. 어떤 사례는 이메일로, 어떤 사례는 의사가 직접 쓴 종이로, 어떤 사례는 파트너사가 XML로 보낸다. 사례 하나마다 ICH가 정한 ICSR(Individual Case Safety Report)이라는 국제 표준의 수백 개 필드를 채워야 하고, 중대성/인과성/예측성을 판정해 SUSAR인지 ADR인지 분류해야 하고, 그에 따라 “7일 안에 보고할 사례인지, 15일 사례인지, 정기보고로 가는지”를 결정해야 한다.

보고가 끝나면 MFDS가 ACK(접수통지)를 회신하는데, 거기에서 또 오류가 나오면 다시 잠금을 풀고, 다시 평가하고, 다시 보고한다. 이 모든 것을, 한 화면에서, 감사 추적성(audit trail) 100%로, 멀티 조직 환경에서.

“이것이 iVigilance Square가 존재하는 이유다.”

이 플랫폼의 운영 주체는 셀타스퀘어(Seltasquare)이며, 코드네임으로는 IS(Information System)로 표기된다. 첫 릴리스의 메인 앱은 Safety DB이고, 그 뒤로 Tabulator, Sync, 그리고 AI App이 줄을 서 있다.

Org는 유일한 운영 주체다

Multi-Org 구조 및 관련 정책 문서는 단호하게 선언한다. “Org만 시스템 상태를 가진다.” Contract(계약)는 행동하지 않는다. Contract는 단지 Org가 어떤 상태로 전이될 수 있는지의 조건일 뿐이다.

Workspace는 독립 시스템이 아니다

Workspace는 Org 안의 데이터 범위 제한 레이어다. Org당 Main Workspace 1개는 자동 생성되고, 최대 100개까지 추가할 수 있다. Additional Workspace는 선택된 부분집합만 본다 — 복제가 아니라 범위 제한이다.

Application은 Workspace에 활성화되어 동작한다

3-Condition Gate — 접근을 허락받는 세 개의 문

어떤 사용자가 어떤 App을 쓰려면, 다음 세 조건이 동시에 충족되어야 한다. 하나라도 빠지면 접근은 거부된다. 이 원칙은 Master Admin/Org Admin에게도 예외가 아니다 — Org 관리 권한과 실제 Workspace/App 접근 권한은 명시적으로 분리된다.

역할의 위계

비밀번호 정책

길이

9~20자

조합

영대문자(A~Z), 영소문자(a~z), 숫자(0~9), 특수문자 중 3종류 이상. 사용 가능한 특수문자 31자가 별도 정의.

금지 패턴

순차 문자/숫자 4자 이상 금지(1234, abcd) 그리고 반복 문자/숫자 4자 이상 금지(aaaa, 1111) — 두 규칙은 분리되어 적용된다.

재사용

직전 비밀번호 재사용 불가

재설정 쿨다운

비밀번호 재설정 메일은 30초 쿨다운

강제 변경

180일 경과 시 유예 없이 강제 변경. 재설정 완료 전까지 서비스 진입 불가. 과거의 “나중에 변경” 유예는 폐지되었다.

MFA — 조직 단위로 켜고 끄는 이중 인증

계정 비활성화의 가드레일

“진행 중인 케이스의 Owner나 Assignee로 지정된 계정”은 비활성화할 수 없다. 케이스를 Close/Archive로 보내거나 다른 담당자에게 재배정한 뒤에야 가능하다. 데이터의 주인이 갑자기 사라지는 사고를 막기 위한 장치다.

“전 역할이 Org 홈으로 진입한다. Workspace는 새 탭으로 연다. 앱 간 전환은 사이드바에서.”

Org 홈 — 모두의 공통 진입점

Org 홈에는 다음 다섯 가지가 놓인다.

내비게이션의 방향성

글로벌 헤더와 사이드바

모든 화면에 고정되는 헤더에는 로고, Workspace명, 세션 시간(60분), 매뉴얼, CS, 프로필 드롭다운이 있다. 프로필을 누르면 My Profile, Version, 로그아웃이 펼쳐진다.

알림(Notification) — 인앱 채널 단일

보관

인앱 최대 100건, 패널에는 최근 20건만 표시. 보존 기간 2주.

읽음 처리

클릭 시 개별 읽음. [Mark all as read]는 확인 팝업을 거친 뒤, 같은 브라우저의 모든 탭에 즉시 동기화.

주요 트리거

라이선스 만료, 케이스 배정, 보고 시작/완료/실패, 케이스 상태 변경 ([Case ID] 상태가 변경되었습니다. [전] → [후]).

보고 기한 임박

D-3부터 매일 00:00–01:00 발송, D-Day까지. 당일에는 [Case ID]의 보고 기한이 오늘까지입니다.

딥링크와 세션

핵심 원칙

보존 정책 · 조회

Case Audit Trail의 3단 구조

각 Save Point에서 사용자/시스템 액션은 별개의 행으로 분리된다. 예: 사용자가 [Save] →CASE_CREATE로그(User), 동시에 시스템이 일련번호 부여 →FU Info로그(System) — 같은 시간, 두 줄. User Comment 이력도 포함되며 User Context > Comment 카테고리 아래 NEW / EDIT / DELETE 액션이 기록된다.

Safety DB의 다섯 메뉴

사례의 일생 — Tracker라는 무대

“목적: 이상사례(AE) 사례의 인입부터 종결까지 단일 화면에서 관리한다.”

Tracker는 한 줄이 한 케이스인 거대한 그리드다. 주요 컬럼은 다음과 같다.

사례를 만드는 두 가지 길

Manual Intake — 유효 ICSR의 4대 요소

ICH가 정한 ICSR의 4대 요소는 보고자 · 환자 · 약물 · 이상사례다. 이 넷 중 하나라도 없으면 유효한 케이스가 아니다. 필드는 셋으로 구분된다.

의약품 코딩의 이중화

사용자가 Product Master에서 ‘성분만’ 또는 ‘성분+제형’만 선택하는 경우, 시스템은 두 가지를 동시에 저장한다.

L1(성분) → L2(성분+용량) → L3(성분+제형) → L4(성분+제형+용량) → Lic(허가제품+국가)의 5단 계층 중, 사용자가 선택한 정밀도까지만 공식 코딩에 들어가고 나머지는 내부 메타로 보관된다.

Case ID Config 가드

Case Edit — 사례를 빚는 작업대

상단 헤더의 식별자들은 시스템이 자동 관리한다. 사용자는 손댈 수 없다. [+ Follow-up] 버튼은 FU(Follow-up, 후속보고) 자동 생성이다. 기존 사례의 모든 정보를 복사해 새 FU를 만들고 즉시 그 화면으로 전환된다. Case Complete는 별도 헤더 버튼이 아니라 Workflow 패널 안에서 명시적으로 누르는 액션이다.

충돌 처리

Lock과 Unlock

워크플로우가 Approved 또는 그 이후 단계에 들어가면 모든 필드는 Read-only. 수정하려면 [Unlock] 버튼을 누르고 모달에서 이동할 단계(Entry/QC/MA), 담당자, 사유(필수, 최대 1000자)를 입력해야 한다. Unlock 즉시 기존 Approved는 무효화된다.

삭제

보고 이력이 있는 케이스는 삭제할 수 없다. 다른 사용자가 편집 중이어도 안 된다. 삭제 가능한 경우라도 사유를 받는다.

룰과 로직 — 자동 분류의 엔진

“이 셋은 케이스 생성 시점에 자동 실행되고, 결과가 Tracker에 즉시 반영된다.”

중복과 후속 — 같은 사례인가, 새 사례인가

후속보고 순번은 시스템이 부여하며, 수정(Amend)/무효화(Null)도 같은 순번 안에서 표시된다.

단계와 상태 — Workflow의 큰 강

Entry

입력자가 데이터 최초 입력.

QC

리뷰어가 품질 검수 및 정합성 확인.

MA

Medical Assessor가 의학적 인과성 평가.

Approval (In Progress)

승인 대기.

Approval (Approved)

최종 승인. 즉시 Lock.

Reject

승인 거절. 역라우팅 단계와 사유를 받는다.

Complete

Case Complete 버튼을 명시적으로 누른 시점.

Archived

(고도화) 보관.

통합 커뮤니케이션 패널 — 채팅과 라우팅의 결합

[Send] 클릭 시 편집 권한(Assignee)이 즉시 새 담당자에게 이월되고 기존 담당자는 Read-only로 전환된다. 단계 변경, 코멘트, 저장 이력, Lock/Unlock이 모두 같은 타임라인에 시계열 순으로 적층된다.

데이터 허브 — XML Import

외부에서 E2B(R3) XML 파일이 도착하면 Data Hub가 그것을 받아들인다. Import 상태는 다음과 같이 진행된다.

Submission — 규제기관 보고의 전용 무대

보고 상태의 진화

신속 vs 정기

Submission List는 Expedited(신속, 디폴트)와 Periodic(정기) 두 페이지로 분리된다. 신속보고 여부 체크가 되어 있으면 Expedited, 안 되어 있으면 Periodic.

배치 단위 전송

사용자가 케이스를 선택해 [Submit]을 누르면, 동일 Receiver의 케이스끼리 묶여 하나의 배치(Batch)가 생성된다. Receiver는 MFDS의 10가지 코드 중 하나로 매핑된다.

Progress의 4단계

각 단계는 진행중/완료/오류로 흐름 상태가 표시된다. 이 흐름은 Progress 컬럼/필드 하나로 통일되어 노출된다 (과거 명칭 Submission Status에서 변경).

ACK — 규제기관의 응답

MFDS는 AS2 게이트웨이로 보낸 배치 XML에 대해 ACK 파일을 회신한다. ACK는 두 레벨로 평가된다.

CR이 발생한 케이스의 ACK.B.r.7에는 상세 사유 코드가 붙는다.

무결성 보장 · 정시 판정 · 영구 보관

Dashboard — Status와 QC

대시보드는 Safety DB를 단일 데이터 원천으로 1시간 주기 배치 갱신된다.

Org Admin 메뉴 8선

사용자 관리의 한도

Viewer는 Org당 최대 5명 (200명에 미포함). 한도 도달 시 생성 버튼은 비활성화되고 안내가 뜬다.

라이선스 관리 — MedDRA와 WHODrug

이 둘은 의약품/이상사례 코딩에 쓰이는 외부 라이선스다. ID 입력 → [Verify] → Status(Active/Expired) + Last Verified가 표시된다. 매주 월요일 자동 체크로 갱신된다.

MedDRA

사용자가 버전 선택 가능. 지원 버전 13종 — 29.0, 28.1, 28.0, 27.1, 27.0, 26.1, 26.0, 25.1, 25.0, 24.1, 24.0, 23.1, 23.0.

WHODrug

최신 버전 자동 적용.

중복 등록

다른 Org가 점유한 MedDRA ID로 등록 시:
“이 ID는 [회사명]에 등록되어 있습니다. 해당 조직의 구성원이십니까?”로 차단.

기능 게이트

라이선스가 있어야 자동 변환과 코드 자동 입력, 수동 코드 선택이 가능. 없으면 봉인.

Company Config — 기준 정보

ICSR Config

App Admin 영역

App Admin은 Workspace-App 단위로 다음만 한다 — 모두 조회 전용이다.

설정 변경 권한은 없다. Org 레벨 설정을 그저 본다.

이 모든 단계에서 발생한 변경은 Case Audit Trail에, 관리자 행위는 Audit Log에, 일반 사용자 행위는 Activity Log에, 공지·알림·세션 등은 별도 시스템 메시지로 잔존한다.

즉시 반영 — Release 1 개발에 포함

다음 버전 반영 — 멀티-국가 추가 시점

필드 분류 4타입 (Draft, 향후 정착)

이 사전 분리 덕분에, 다음 버전에서 EMA·FDA를 붙일 때 데이터 구조를 다시 갈아엎지 않아도 된다.

최우선 (Release 1, Go-live)

고도화

주요 미결 사항

1. 1

   격리(Isolation)에 대한 집착

   “Org는 유일한 운영 주체다. Workspace는 데이터 범위 제한 레이어다. Backoffice Admin은 고객 데이터에 직접 접근할 수 없다.”

   이 플랫폼은 처음부터 ‘여러 제약회사가 한 인프라 위에 올라가는’ SaaS로 설계되었고, 고객 데이터 격리는 가장 윗줄에 놓인 원칙이다. 그래서 Break-Glass라는 비상구가 별도로 정의되었다.

2. 2

   자동 분류 + 사람의 판단

   “AE Type 분류, 보고 출처 분류, RA Due 산출은 시스템이 한다. 단계 이동, Lock 해제, 보고 승인은 사람이 한다.”

   기계가 할 일과 사람이 할 일을 명확히 나눴다. 사용자는 ‘왜 이렇게 분류됐는지’를 이해할 수 있는 자리에 결과를 본다.

3. 3

   모든 행위는 기록된다 — Append-only

   “Audit Trail, Activity Log, Audit Log는 수정 API도 삭제 API도 없다.”

   규제 감사(Audit) 대응이 본질인 도메인이기에, 데이터의 진실성이 다른 모든 가치보다 우선한다.

4. 4

   잠금과 사유

   “Approval 즉시 자동 Lock. Unlock에는 사유가 필수. 보고 진행 중에는 System Freeze. 케이스 삭제, 단계 역라우팅, MFA 해제 — 모두 사유가 따라붙는다.”

   이 플랫폼은 ‘왜?’라는 질문에 항상 답할 수 있도록 만들어진다. 누가, 언제, 왜 그 변경을 했는가. 이 질문에 침묵하면 GxP 환경에서 살아남을 수 없다.

5. 5

   단일 진입점, 명확한 방향성

   “전 역할이 Org 홈으로 진입한다. 앱 간 이동은 같은 탭에서. Workspace 이동은 새 탭에서. Workspace 간 직접 이동은 차단. 반드시 Org 홈을 경유한다.”

   복잡한 멀티 차원 구조에 사용자가 길을 잃지 않도록, 방향성이 명확히 정의되어 있다.