제7장
WIA-BIO-005가 사이토카인 방출 증후군, 신경독성, 그 밖의 투여 후 이상사례를 어떻게 부호화하는지, SDK가 관찰값을 등급과 위험 수준으로 어떻게 바꾸는지, 그리고 안전성 모니터(Safety Monitor)가 병원·제조사의 여러 시스템 사이에서 어디에 자리하는지를 다룬다.
먼저 읽을 것. 이 장은 표준과 참조 SDK가 무엇을 부호화하고 있는지를 설명한다. 아래에 나오는 약물·용량·간격·기준값은 엔지니어가 구현을 규격과 대조할 수 있도록 옮겨 적은 것이며, 어느 것도 치료 지시가 아니다. 현재 사용 중인 제품의 허가사항, 승인된 위해성 관리 자료, 해당 기관의 프로토콜이 언제나 우선하며, 임상적 판단은 치료팀의 몫이다.
제2장부터 제6장까지는 공여자의 정맥에서 환자의 정맥에 이르는 제품의 여정을 따라갔다. 투여 순간부터 주인공은 제품에서 환자로 바뀐다. 세포는 이제 몸 안에서 증식하며, 세포가 효과를 내게 하는 바로 그 성질, 곧 표적 항원을 만났을 때의 강한 활성화가 이 분야를 특징짓는 독성의 원천이기도 하다. WIA-BIO-005 적합성을 주장하는 시스템은 반드시 안전성 모니터를 포함해야 하며(규격 §8.1), 이 장은 그 구성요소가 알아야 할 내용을 정리한다. 곧 정확히 재현해야 할 등급 체계, 관찰값을 담는 데이터 모델, SDK가 수행하는 위험 집계, 그리고 병상의 관찰 한 건을 약물감시 사례로 옮기고 다시 제조 로트로 되돌려 연결하는 통합 구조이다.
이 장에는 두 가지 주제가 흐른다. 첫째는 충실성이다. 표준이 ASTCT 2019 등급처럼 공개된 합의 척도를 채택했다면 소프트웨어는 그 척도를 그대로 재현해야 하며, 규격이나 SDK가 원래 척도와 어긋나는 부분이 있으면 이를 인지하고 처리해야 한다. 둘째는 책임이다. SDK는 등급과 긴급도 표지, 권고 문자열을 내놓지만 결정은 하지 않는다. 7.7절은 이 원칙을 구체적인 설계 규칙으로 옮긴다.
CAR-T 세포가 표적 항원, 예컨대 악성 B세포의 CD19와 결합하면 활성화·증식하면서 인터페론-γ 같은 효과 사이토카인을 분비한다. 이 신호는 주변의 골수계 세포, 주로 단핵구와 대식세포를 불러 모아 활성화하고, 이들이 다량의 인터루킨-6과 인터루킨-1 등을 내어 반응을 증폭한다. 증폭된 염증은 혈관 내피를 활성화해 모세혈관 투과성을 높이고, 체액 이동과 혈압 저하, 산소화 장애로 이어질 수 있다. 임상적으로는 대개 발열이 가장 먼저 나타나고, 중증인 경우 저혈압과 저산소증이 뒤따른다. 발현 시점은 대체로 투여 후 처음 며칠 안이지만 제품, 질병 부담, 환자에 따라 다르다. 이 증후군은 치료 자체의 기전에서 비롯되므로 제조 결함의 징후가 아니며, 모니터링 시스템은 이를 품질 실패가 아니라 예상 가능하고 등급화할 수 있는 독성으로 기록해야 한다.
WIA-BIO-005 §7.1.1은 미국이식세포치료학회(ASTCT)가 2019년에 발표한 합의 등급을 채택한다. 이 척도는 의도적으로 단순하다. CRS 진단에는 38 °C 이상의 발열이 필요하고, 등급은 저혈압과 저산소증이라는 두 소견 가운데 더 심한 쪽이 정한다. CRS와 함께 나타나는 장기 독성은 별도로(흔히 NCI 이상사례 공통용어기준, CTCAE로) 등급을 매기며 CRS 등급을 바꾸지 않는다.
| 등급 | 발열 | 저혈압 | 저산소증 | 이를 표현하는 필드 값 |
|---|---|---|---|---|
| 1 | ≥ 38 °C | 없음 | 없음 | hypotension: false, oxygenRequirement: 'none' |
| 2 | ≥ 38 °C | 승압제 불필요 | 저유량 비강 캐뉼라(≤ 6 L/min) 또는 블로바이(blow-by) | 저혈압이면서 vasopressors: 'none', 또는 'low-flow' |
| 3 | ≥ 38 °C | 승압제 1종(바소프레신 병용 여부 무관) | 고유량 비강 캐뉼라(> 6 L/min), 안면 마스크, 비재호흡 마스크, 벤투리 마스크 | vasopressors: 'single' 또는 'high-flow' |
| 4 | ≥ 38 °C | 승압제 여러 종(바소프레신 제외) | 양압 환기(CPAP, BiPAP, 삽관 및 기계환기) | vasopressors: 'multiple' 또는 'ventilator' |
합의문의 세부 사항 가운데 구현자에게 중요한 것이 세 가지 있다. 첫째, 해열제나 항사이토카인 치료로 발열이 억제되었다고 해서 에피소드가 끝나지는 않는다. 일단 발열이 기록되었다면 이후 체온이 정상이라도 등급은 저혈압과 저산소증을 따른다. 둘째, 등급은 언제나 두 축 가운데 더 심한 쪽이다. 승압제 없이 교정되는 저혈압(혈압 축 2등급)이 있으면서 고유량 산소가 필요한(산소 축 3등급) 환자는 3등급이다. 셋째, 3등급과 4등급을 가를 때 바소프레신은 추가 승압제로 세지 않는다.
규격 본문에 대한 정오표. 규격 §7.1.1은 2등급에 “FiO2 <40%”, 3등급에 “FiO2 ≥40%”를 덧붙이고 있다. 이 FiO2 기준은 ASTCT 2019 합의에 없는 내용이다. 합의는 2등급과 3등급을 산소 공급 장치와 유량(≤ 6 L/min 저유량 비강 캐뉼라 대 고유량 또는 마스크 공급)으로 나눈다. “ASTCT 2019에 따라” 등급을 매긴다고 주장하는 구현은 장치와 유량으로 등급을 매겨야 하며, FiO2는 부가 관찰값으로 저장하되 등급 결정에는 쓰지 않는 것이 옳다.
CRSAssessment 타입과의 대응SDK 타입 CRSAssessment는 척도에 필요한 입력을 정확히 담고 있다. 섭씨 단위의 temperature, hypotension 플래그, 세 값을 갖는 vasopressors('none' | 'single' | 'multiple'), hypoxia 플래그, 네 값을 갖는 oxygenRequirement('none' | 'low-flow' | 'high-flow' | 'ventilator')가 그것이다. 이 밖에 0–4로 제한된 grade 필드, 선택 항목인 biomarkers, 선택 항목인 CRSTreatment 레코드가 있다.
대응 과정의 미묘한 점 두 가지는 명시적으로 처리해야 한다. 열거값 'ventilator'는 “양압 환기 지원”으로 읽어야 한다. 비침습적 CPAP나 BiPAP만으로도 이미 4등급에 해당하기 때문이다. 또 'multiple'은 바소프레신이 아닌 승압제가 두 종 이상 투여될 때에만 입력해야 한다. 노르아드레날린 주입에 바소프레신을 더한 경우는 등급 판정상 여전히 'single'이다. 두 규칙을 문서에만 적지 말고 입력 화면에 반영하면 가장 흔한 과대 등급 오류를 막을 수 있다.
반면 이 타입에는 에피소드 초기에 발열이 있었는지를 기록하는 칸이 없는데, 발열이 가려진 경우 합의 기준은 바로 그 정보를 필요로 한다. 7.2절의 예시는 이 사실을 별도 인자로 넘기며, 실제 운영 시스템이라면 에피소드 이력에서 도출해야 한다.
규격 §7.1.3은 “중증 CRS 예측 인자”라는 제목 아래 CRP, 페리틴, IL-6, IFN-γ, 젖산의 최고치 값을 나열하며, CRSAssessment.biomarkers에는 CRP(mg/dL), 페리틴(ng/mL), IL-6과 IFN-γ(pg/mL)를 담는 칸이 있다. 규격은 이 기준값들의 출처를 밝히지 않았으므로, 검증된 절단값이 아니라 표준 안의 예시 값으로 다루어야 한다. 검사법, 참고 범위, 단위는 기관마다 다르다. mg/dL로 12인 CRP는 mg/L로는 120이다. 따라서 안전성 모니터는 바이오마커를 단위와 함께 저장하고 시간 추이로 보여 주어야 하며, 바이오마커 기준값만으로 CRS 등급을 매기거나 치료 알림을 띄워서는 안 된다. 합의 등급은 검사값이 아니라 임상 징후에 따라 정해진다.
규격 §7.1.2는 등급별 관리 알고리즘을 담고 있고, SDK 메서드 assessCRS는 등급을 치료 문자열과 긴급도 표지로 바꾼다. 구현을 검증할 수 있도록 그 내용을 아래에 요약하며, 장 첫머리의 주의 사항이 그대로 적용된다.
| 등급 | 규격이 부호화한 내용 | urgency |
|---|---|---|
| 0 | 치료 불필요, 모니터링 지속 | routine |
| 1 | 보존적 치료, 해열제, 면밀한 관찰 | routine |
| 2 | 토실리주맙 8 mg/kg 정맥 투여(최대 800 mg), 24시간 내 호전이 없으면 코르티코스테로이드 고려, 8시간 후 토실리주맙 반복 가능 | urgent |
| 3–4 | 토실리주맙 즉시 투여와 코르티코스테로이드(메틸프레드니솔론 1–2 mg/kg/일 또는 덱사메타손 10 mg 6시간마다) 병용, 중환자 관리 | emergency |
토실리주맙은 인터루킨-6 수용체에 대한 단일클론항체이며, 그 역할은 7.1.1절의 병태생리에서 곧바로 나온다. IL-6 증폭 고리를 끊는 것이다. 코르티코스테로이드는 더 넓은 면역억제를 제공하며, CRS가 중증이거나 반응하지 않을 때 알고리즘에 들어온다. 규격의 용량 세부 사항 가운데 두 가지는 표현이 느슨하므로, 이를 화면에 표시하는 시스템이라면 정확히 적어야 한다.
assessCRS 문자열은 “Repeat tocilizumab q8h PRN”이라고만 하고 한도를 전혀 두지 않으므로, 한도는 처방 시스템이 책임져야 한다. 처방 시스템은 CRSTreatment.tocilizumab.doses를 이 한도와 비교해 차단하거나 경고할 수 있다.이 값들은 모두 현행 제품 허가사항과 기관 프로토콜에 따를 때에만 적용된다. 이 책은 검증을 위해 옮겨 적었을 뿐 권고하지 않는다.
아래 코드는 관찰 한 건을 SDK에 통과시키는 과정을 보여 준다. assessCRS가 하는 일과 하지 않는 일을 정확히 구분해야 한다. 이 메서드는 호출자가 넘긴 grade 필드를 읽어 그 값으로 분기할 뿐, 체온·승압제·산소로부터 등급을 계산하지 않는다. 관찰값에 먼저 등급을 매기지 않고 SDK가 CRS를 “평가”해 줄 것이라 믿는 시스템은 누군가 입력한 등급을 그대로 되돌려 줄 뿐이다. 보조 함수 gradeCRS는 표 7-1을 필드에 적용해 이 빈틈을 메운다.
import { CellularTherapySDK, CRSAssessment } from '@wia/bio-005';
// 예시: 투여 후 3일차 병상 관찰 1건
const obs: CRSAssessment = {
patientId: 'PT-7F3A21', // 가명 식별자 - 이름·등록번호 금지
timestamp: new Date('2025-03-14T02:00:00Z'),
daysPostInfusion: 3,
grade: 0, // 아래 gradeCRS()가 채운다
temperature: 38.9, // 섭씨
hypotension: true,
vasopressors: 'none', // 수액 볼루스에 반응
hypoxia: false,
oxygenRequirement: 'none',
biomarkers: { crp: 12.4, ferritin: 2150 }, // 예시 값
notes: '정질액 1 L 후 수축기 혈압 회복'
};
type Grade = 0 | 1 | 2 | 3 | 4;
/**
* CRSAssessment 필드로부터 ASTCT 2019 CRS 등급을 계산한다.
* feverInEpisode: 이번 에피소드에서 이미 발열이 기록되었는지
* (해열제나 항IL-6 치료로 현재 체온에서는 가려질 수 있다).
*/
function gradeCRS(a: CRSAssessment, feverInEpisode: boolean): Grade {
const fever = a.temperature >= 38 || feverInEpisode;
if (!fever) return 0; // 발열이 없으면 CRS 등급 없음
const byPressure: Grade =
!a.hypotension ? 1 :
a.vasopressors === 'none' ? 2 :
a.vasopressors === 'single' ? 3 : 4;
const byOxygen: Grade =
a.oxygenRequirement === 'none' ? 1 :
a.oxygenRequirement === 'low-flow' ? 2 :
a.oxygenRequirement === 'high-flow' ? 3 : 4; // 'ventilator' = 양압 환기
return Math.max(byPressure, byOxygen) as Grade; // 더 심한 쪽이 등급을 정한다
}CRSAssessment 관찰값과 ASTCT 2019 등급 계산 보조 함수(예시 값).const sdk = new CellularTherapySDK();
obs.grade = gradeCRS(obs, true);
const rec = sdk.assessCRS(obs);
console.log(rec);
// 출력 (SDK 1.0.0):
// {
// grade: 2,
// treatment: 'Tocilizumab 8 mg/kg IV (max 800 mg). Consider corticosteroids
// if no improvement in 24h. Repeat tocilizumab q8h PRN.',
// urgency: 'urgent'
// }assessCRS를 호출한 결과. 출력은 SDK 1.0.0으로 확인하였다.이 예에서 38.9 °C의 체온이 발열을 확정하고, 수액에 반응한 저혈압이 혈압 축을 2등급으로 두며, 산소 축은 1등급에 머문다. 전체 등급은 2이고 SDK는 긴급도 urgent를 돌려준다. CLI도 같은 대응을 축약된 형태로 제공한다. wia-bio-005 monitor-safety --patient PT-001 --days 3 --crs 2 --icans 0을 실행하면 2등급 경고와 한 줄짜리 치료 메모가 출력된다(README에는 플래그가 --day로 적혀 있으나 스크립트가 실제로 해석하는 것은 --days이다). SDK와 마찬가지로 CLI도 등급을 입력으로 받을 뿐 계산하지 않는다.
면역효과세포 연관 신경독성 증후군(ICANS)은 CRS와 함께 또는 그 뒤에 나타나거나 단독으로 생길 수 있다. 흔히 미묘한 변화로 시작한다. 낱말이 잘 떠오르지 않거나, 글씨가 흐트러지거나, 주의력이 떨어진다. 중증이면 혼동, 의식 저하, 경련, 운동 약화로 진행할 수 있고 드물게 뇌부종이 생긴다. 지치고 열이 나는 환자에게서 초기 징후는 놓치기 쉽기 때문에, 합의 접근법은 짧고 반복 가능한 병상 선별 도구인 ICE 점수에 의식 수준과 특정 신경학적 소견의 평가를 결합한다.
ICE(Immune Effector Cell-associated Encephalopathy) 점수는 ASTCT 2019 합의와 함께 발표된 10점 도구이다. 10점이 정상이며 점수가 낮을수록 장애가 크다.
| 영역 | 과제 | ASTCT 배점 | 규격 §7.2.1 / SDK iceComponents |
|---|---|---|---|
| 지남력 | 연도, 월, 도시, 병원 | 4 | 4 (orientation 0–4) |
| 이름 대기 | 사물 세 가지 이름 대기(예: 시계, 펜, 단추) | 3 | 3 (naming 0–3) |
| 명령 수행 | 예: “손가락 두 개를 보여 주세요”, “눈을 감고 혀를 내밀어 보세요” | 1 | 2 (following 0–2) |
| 쓰기 | 표준 문장 한 줄 쓰기 | 1 | 1 (writing 0–1) |
| 주의력 | 100부터 10씩 거꾸로 세기 | 1 | 없음 |
| 합계 | 10 | 10 | |
정오표. 규격의 표와 SDK의 iceComponents는 “명령 수행”에 2점을 주고 주의력 영역을 빠뜨렸다. 합계가 10점으로 같기 때문에 차이를 놓치기 쉽지만, 개별 점수는 달라질 수 있다. 지시는 따르지만 거꾸로 세지 못하는 환자는 ASTCT 기준으로 9점인데, 규격의 방식으로는 10점으로 기록될 수 있다. ICE 10점과 9점은 ICANS 없음과 1등급을 가르는 경계이므로 이는 표기상의 문제가 아니다. 이 책은 ASTCT 정의를 따른다. 구현은 ASTCT의 다섯 영역을 입력받아 합계를 계산하고, 코드 7-3처럼 그 결과를 SDK 구조에 옮겨 담아야 한다.
/** ASTCT 2019가 정의한 ICE 영역 (합계 0-10) */
interface IceAstct {
orientation: number; // 0-4: 연도, 월, 도시, 병원
naming: number; // 0-3: 사물 세 가지
commands: number; // 0-1: 간단한 지시 수행
writing: number; // 0-1: 표준 문장 쓰기
attention: number; // 0-1: 100부터 10씩 거꾸로 세기
}
const clamp = (v: number, max: number) => Math.min(Math.max(Math.round(v), 0), max);
function iceScore(c: IceAstct): number {
return clamp(c.orientation, 4) + clamp(c.naming, 3) + clamp(c.commands, 1)
+ clamp(c.writing, 1) + clamp(c.attention, 1);
}
/** 'attention' 항목을 잃지 않고 SDK 레코드 옆에 ASTCT 영역을 보관한다. */
function toSdkComponents(c: IceAstct) {
return {
iceComponents: {
orientation: clamp(c.orientation, 4),
naming: clamp(c.naming, 3),
following: clamp(c.commands, 1), // SDK는 0-2를 허용하지만 ASTCT는 1점 만점
writing: clamp(c.writing, 1),
},
iceScore: iceScore(c), // 합계에는 주의력 1점이 포함된다
iceAstct: c, // 자체 저장소에 두는 확장 필드
};
}ICE 과제를 수행할 수 없는 어린 소아에 대해 ASTCT 합의는 ICE 대신 소아 섬망 평가 도구(Cornell Assessment of Pediatric Delirium, CAPD)를 쓴다. 규격과 SDK는 이를 모델링하지 않으므로, 소아 프로그램이라면 확장 필드와 별도의 등급 규칙이 필요하다.
ICANS 등급은 ICE 점수, 의식 수준, 경련, 운동 소견, 두개내압 상승 또는 뇌부종이라는 다섯 영역 가운데 가장 심한 것이 정한다. 다른 원인으로 설명되는 소견은 제외한다.
| 영역 | 1등급 | 2등급 | 3등급 | 4등급 |
|---|---|---|---|---|
| ICE 점수 | 7–9 | 3–6 | 0–2 | 0(ICE 수행 불가) |
| 의식 수준 | 자발적으로 깨어 있음 | 목소리에 깨어남 | 촉각 자극에만 깨어남 | 각성 불가, 또는 강하거나 반복적인 자극이 필요함, 혼미·혼수 |
| 경련 | — | — | 빠르게 소실되는 임상적 경련, 또는 중재로 소실되는 뇌파상 비경련성 발작 | 생명을 위협하는 지속 경련(> 5분) 또는 기저 상태로 돌아오지 않는 반복 경련 |
| 운동 소견 | — | — | — | 편마비·하반신마비 같은 심한 국소 운동 약화 |
| 두개내압 상승 / 뇌부종 | — | — | 신경영상의 국소 부종 | 미만성 뇌부종, 제뇌·제피질 자세, 제6뇌신경 마비, 유두부종, 쿠싱 삼징 |
합의문의 각주 하나는 코드로 명시해 둘 가치가 있다. ICE 0점이라도 깨어 있으나 전반적 실어증이 있는 환자는 3등급이고, 각성시킬 수 없는 환자의 ICE 0점은 4등급이다. 따라서 ICE 점수만으로는 두 등급을 가를 수 없고 consciousness 필드를 함께 보아야 한다.
SDK의 ICANSAssessment 타입은 이 표의 대부분을 담는다. iceScore, consciousness('awake' | 'awakens-to-voice' | 'awakens-to-touch' | 'unresponsive'), 불리언 seizures, 자유 텍스트 motorFindings, 불리언 cerebralEdema가 그것이다. 합의와 비교하면 규격 §7.2.2의 등급 본문은 “임상적이든 준임상적이든 모든 경련”을 지속 경련과 구분하지 않고 3등급에 두며, 3등급의 국소 부종을 빠뜨렸다. 불리언 필드도 이 거친 구분을 물려받는다. seizures: true 하나로는 경련이 빠르게 소실되었는지(3등급) 지속되었는지(4등급) 알 수 없고, cerebralEdema: true로는 국소(3등급)인지 미만성(4등급)인지 알 수 없다. 등급을 신뢰성 있게 매겨야 하는 시스템은 경련 지속 시간과 부종 범위를 담는 구조화 필드를 추가해야 한다. CRS와 마찬가지로 assessICANS도 등급을 계산하지 않고 넘겨받은 값을 읽는다.
규격 §7.2.3과 assessICANS의 3–4등급 문자열은 모두 토실리주맙을 피하라고 한다. 이유는 기전에 있다. 토실리주맙은 IL-6 수용체를 차단하는데, 수용체가 막히면 IL-6이 수용체를 통해 제거되지 못해 혈중 IL-6이 일시적으로 올라갈 수 있다. 반면 항체 자체는 중추신경계로 잘 들어가지 못하는 것으로 여겨진다. 약은 뇌에 닿지 못하는데 유리 IL-6은 더 많이 닿을 수 있다는 우려이다. 그래서 CRS를 동반하지 않은 ICANS에서는 합의 이후의 접근법에서 항IL-6 치료가 아니라 코르티코스테로이드가 중심이 된다. 표준은 2등급에 덱사메타손과 항경련 예방(레베티라세탐) 고려를, 3–4등급에 고용량 코르티코스테로이드, 항경련제, 중환자 관리를 부호화하고 있다. 이 장 전체에서와 같이, 이 요법들은 현행 제품 허가사항과 기관 프로토콜에 따를 때에만 적용된다.
여기서 구현상의 요점이 하나 나온다. CRS와 ICANS가 동시에 있을 때 assessCRS는 토실리주맙을 권고하고 assessICANS는 이를 피하라고 경고할 수 있다. SDK는 두 출력을 조정하지 않는다. 두 결과를 나란히 보여 주는 사용자 화면은 충돌을 드러내어 임상의에게 넘겨야 하며, 조용히 한쪽을 골라서는 안 된다.
처음 며칠은 CRS와 ICANS에 관심이 쏠리지만, 규격 §7.3은 몇 주, 때로는 몇 달에 걸쳐 모니터링을 좌우하는 세 범주를 더 다룬다.
| 범주 | 표준이 요구하는 모니터링 | 규격이 나열한 지지 조치 | SafetyEvent.type |
|---|---|---|---|
| 혈구감소증 | 4주 동안 최소 주 1회 전혈구검사, 호중구·혈소판감소증과 빈혈 | G-CSF, 혈소판·적혈구 수혈, 감염 예방 | cytopenia |
| 감염 | 처음 30일에 위험이 가장 높음, 세균·바이러스(CMV, EBV, HHV-6)·장기 호중구감소 시 진균 | 항바이러스·PJP 예방, 중증 호중구감소 지속 시 항진균제, IgG < 400 mg/dL이면 IgG 보충 | infection |
| 종양용해증후군 | 고위험 환자에서 6–12시간마다 전해질, 요산, LDH, 인 | 수액 공급, 알로퓨리놀 또는 라스부리카제, 전해질 교정 | other |
혈구감소증. 세포치료 후의 혈구 감소에는 여러 요인이 겹친다. 투여 전에 시행한 림프구제거 화학요법(제6장), CRS 동안의 염증, 그리고 일부 환자에서는 첫 달을 넘겨 이어지거나 두 번에 걸쳐 나타나는 경과가 있다. 규격의 주 1회 전혈구검사는 하한이지 상한이 아니다. 데이터 측면에서 쓸모 있는 기록은 투여일에 연결된 혈구 수치의 시계열이며, 그래야 “혈구 회복”을 주장이 아니라 계산으로 보일 수 있다.
감염. 림프구제거, CD19 또는 BCMA 표적 치료에 따른 B세포 무형성, 낮은 면역글로불린 수치, 코르티코스테로이드 노출은 모두 감염 위험을 높인다. 규격은 바이러스 가운데 거대세포바이러스(CMV), 엡스타인-바 바이러스(EBV), 인간 헤르페스바이러스 6(HHV-6)을 들고 범주별 예방법을 나열한다. 면역글로불린 400 mg/dL 기준은 이 절에서 몇 안 되는 수치 기준이며, SDK는 활성 감염 사례가 있으면 이를 권고 문자열로 되풀이한다. 호중구감소 중의 발열과 CRS에 의한 발열은 병상에서 똑같이 보인다는 점에 유의해야 한다. 안전성 모니터가 규칙만으로 발열을 CRS라고 표지해서는 안 되는 이유 가운데 하나이다.
종양용해증후군. 큰 종양 부담이 빠르게 파괴되면 세포 안의 칼륨, 인, 핵산이 신장이 처리할 수 있는 속도보다 빨리 방출될 수 있다. 규격은 고위험 환자에 대해 예방적 수액, 요산 강하제, 잦은 검사를 나열한다. SDK에는 이를 위한 전용 타입이 없어 type: 'other'와 설명 텍스트로 기록해야 하는데, 화면 표시에는 충분하지만 분석에는 약하다. 통제 용어로 사례를 부호화하면(7.6절 참조) 이 약점을 보완할 수 있다.
모든 범주에 같은 주의 사항이 적용된다. 규격은 범주별 지지 조치를 나열할 뿐이며, 그 조치는 현행 제품 허가사항과 기관 프로토콜에 따를 때에만 적용된다.
SafetyEvent: 이상사례 한 건에 레코드 하나CRSAssessment와 ICANSAssessment가 반복되는 관찰을 기록한다면, SafetyEvent는 사례 전체를 기록한다. 필드는 eventId, patientId, type('CRS' | 'ICANS' | 'infection' | 'cytopenia' | 'other'), severity(1–5), description, onsetDate, 선택 항목인 resolutionDate, 선택 항목인 자유 텍스트 treatment, 선택 항목인 outcome('resolved' | 'resolving' | 'ongoing' | 'fatal'), serious, related이다.
이 가운데 세 필드는 규제상의 의미를 지니므로 구현 지침에서 신중하게 정의해야 한다.
severity는 1부터 5까지의 강도 척도이다. CRS와 ICANS라면 ASTCT 등급(1–4)을 그대로 옮기고 5는 해당 사례로 인한 사망에 남겨 두는 것이 자연스러우며, 이는 다른 사례에 쓰는 NCI CTCAE의 관례와도 맞는다. 평가 레코드의 SDK 타입은 0–4만 허용하므로 대응 관계를 명시해야 한다.serious는 “중증”과 같은 말이 아니다. 약물감시에서 “중대한(serious)” 사례는 ICH E2A가 정의한 규제 범주로, 예컨대 사망을 초래하거나, 생명을 위협하거나, 입원을 요하거나 연장하거나, 지속적인 장애를 남기는 사례를 말한다. 3등급 검사 이상은 중증이지만 중대하지 않을 수 있고, 입원을 연장시킨 2등급 사례는 중대할 수 있다. 타입처럼 두 필드를 독립적으로 두는 것이 옳고, 한쪽에서 다른 쪽을 도출하는 것은 옳지 않다.related는 'definite'부터 'unrelated'까지 다섯 단계의 인과성 척도이다. 이 평가는 대개 연구자나 담당 의사가 내리는 임상적 판단이므로, 누가 언제 판단했는지를 함께 저장해야 한다.monitorSafety의 집계 방식monitorSafety(patientId, daysPostInfusion, events)는 위험 수준, 활성 사례, 권고 문자열 목록을 돌려준다. 논리가 짧아서 전부 적을 수 있다.
resolutionDate가 없는 사례를 활성으로 본다.critical이다. 그렇지 않고 중대한 활성 사례가 있거나 CRS와 ICANS가 동시에 활성이면 high, 그렇지 않고 활성 사례가 하나라도 있으면 moderate, 아니면 low이다.import { CellularTherapySDK, SafetyEvent } from '@wia/bio-005';
const sdk = new CellularTherapySDK();
const events: SafetyEvent[] = [
{ eventId: 'AE-0001', patientId: 'PT-7F3A21', type: 'CRS', severity: 2,
description: 'CRS 2등급 (ASTCT 2019)', onsetDate: new Date('2025-03-14'),
serious: false, related: 'probable' },
{ eventId: 'AE-0002', patientId: 'PT-7F3A21', type: 'cytopenia', severity: 3,
description: '호중구감소증', onsetDate: new Date('2025-03-13'),
serious: false, related: 'possible' },
{ eventId: 'AE-0003', patientId: 'PT-7F3A21', type: 'other', severity: 1,
description: '투여 당일 오심', onsetDate: new Date('2025-03-11'),
resolutionDate: new Date('2025-03-12'), serious: false, related: 'possible' },
];
const report = sdk.monitorSafety('PT-7F3A21', 3, events);
// report.riskLevel -> 'moderate'
// report.activeEvents -> AE-0001, AE-0002 (AE-0003은 resolutionDate가 있음)
// report.recommendations ->
// 'Patient should remain hospitalized with continuous monitoring'
// 'Assess for CRS and ICANS at least q4-6 hours'
// 'Tocilizumab should be readily available'
// 'Monitor inflammatory markers (CRP, ferritin, IL-6)'
// 'Monitor CBC at least weekly'
// 'G-CSF support for neutropenia'
// 'Transfusion support as needed'monitorSafety에 사례 세 건을 넣은 예. 출력은 SDK 1.0.0으로 확인하였다.이 집계에는 통합 시 주의할 동작이 몇 가지 있다. outcome: 'fatal'이지만 resolutionDate가 없는 사례는 계속 활성으로 남고, 사망 사례에 해소일을 넣으면 집계에서 아예 빠진다. 사망은 또 하나의 사례가 아니라 환자 기록의 종결 상태로 다루어야 한다. 또 ICANS 사례가 활성이기만 하면 “항경련 예방 권고” 문자열이 나오는데, 이는 2등급에서 “고려”라고 한 규격보다 강한 표현이다. 그리고 날짜 기준은 표준의 과거 기본값을 반영한다. 6.8절에서 다룬 것처럼 승인된 자가 CAR-T 제품에 대한 최근 FDA 허가사항·REMS 개정으로 투여 후 근접 거주 및 운전 제한 기간이 2주로 단축되었고, 최소 10일 입원은 규제 요건이 아니다. 따라서 모니터링 기간은 상수가 아니라 제품별·기관별로 정하는 설정값이어야 한다.
규격 §6.4.1은 초기 기간에 매일 평가할 항목을 나열한다. 활력징후(체온, 혈압, 심박수, 호흡수), ICE를 포함한 신경학적 검사, 전혈구검사, 종합 대사 검사, CRP·페리틴·피브리노겐, 가능하면 사이토카인 패널이며, 활력징후와 신경학적 확인은 4–6시간마다 한다. 데이터 모델로 옮기면 이는 하나 이상의 CRSAssessment·ICANSAssessment 관찰과 검사 결과를 묶는 환자-일 레코드가 된다. 각 항목에는 시각이 붙고 투여일에 연결되어, daysPostInfusion은 손으로 입력하지 않고 계산된다. 피브리노겐이 목록에 있는 것은 중증 CRS에 응고병증이 동반될 수 있기 때문이다. SDK 타입에는 이를 위한 필드가 없으며, 다른 검사값과 마찬가지로 모니터링 레코드가 참조하는 EHR 결과 저장소에 두는 것이 맞다.
규격 §8.1의 다섯 필수 구성요소가 한 애플리케이션에 모두 들어가는 경우는 드물다. 실제 배포 환경에서는 제조사, 치료 병원, 안전성 보고를 받는 기관에 나뉘어 있다. 표준은 §10.3에서 관련 WIA 표준 네 가지를 든다. WIA-INTENT(의도 기반 치료 선택), WIA-OMNI-API(의료 상호운용성), WIA-HEALTH(전자건강기록), WIA-PHARMA(약물 안전성 모니터링)이다. 표 7-6은 각 구성요소를 흔히 연동하는 시스템과 나란히 놓은 것이다.
| 구성요소(규격 §8.1) | 일반적인 호스트 시스템 | SDK 메서드 | 주요 연동 대상 |
|---|---|---|---|
| 제조 추적기(Manufacturing Tracker) | 제조사 MES / LIMS | trackManufacturing | 장비·환경 모니터링, 배치 기록 |
| 품질 평가기(Quality Assessor) | QC 시험실과 QMS | assessQuality, generateCertificate, assessPostThawQuality | 출하 승인, 병원 세포처리실(해동 후 데이터) |
| 용량 계산기(Dose Calculator) | 병원 약제부 / 처방 입력 | calculateDose | EHR(체중, 처방), 세포처리실(제품 세포 수) |
| 안전성 모니터(Safety Monitor) | EHR에 통합된 임상 모듈 | assessCRS, assessICANS, monitorSafety | 관찰·검사 결과는 WIA-HEALTH, 보고 대상 사례는 WIA-PHARMA |
| 규정 준수 점검기(Compliance Checker) | QA·인허가 도구 | SDK 1.0.0에 전용 메서드 없음 | 감사 추적을 통해 위의 모든 시스템(제8장) |
아래 흐름은 제품 하나와 이상사례 하나가 조직 경계를 넘어 이동하는 과정을 따라간다. 투여 이전 단계는 제3·5·6장에서 다루었으며, 여기서는 연결 관계를 보이기 위해서만 나타낸다.
제조사 병원 세포처리실 병동 / EHR 약물감시
(LIMS/MES, QMS) (동결 재고) (WIA-HEALTH) (WIA-PHARMA)
| | | |
[1] 출하 승인 ------------> | | |
(CoA 서명, 제3·5장) | | |
| [2] 입고 + 관리 연속성 | |
| (StorageInfo, C008/C009) | |
| | [3] 해동·불출 -------> | |
| | (신원 확인, 제6장) | |
| | [4] 투여 기록 |
| | 0일차 시계 시작 |
| | [5] 4~6시간 간격 관찰 |
| | CRSAssessment / |
| | ICANSAssessment |
| | [6] SafetyEvent --------------> |
| | | [7] 사례 평가,
| | | 관할별 보고
| <----------------------------------- [8] 제품 단위 신호 |
| (product_id / 배치로 로트 연결) | |
| | | |
모든 메시지는 상호운용 계층(WIA-OMNI-API)을 거치며,
각 구간은 감사 기록(누가, 무엇을, 언제, 어느 product_id)을 남긴다.세 가지 식별자가 이 흐름을 묶는다. 세포 제품 레코드(제4장)의 product_id는 병동에서 투여된 백을 배치 기록과 시험성적서에 연결한다. 가명 patientId는 병원 안에서 관찰과 사례를 잇는다. 이를 실제 신원과 대응시키는 일은 병원 자체 시스템 안에서만 이루어진다. 그리고 각 SafetyEvent의 eventId는 약물감시가 후속 정보를 추적하는 키가 된다. 안전성 신호에서 제조 로트로 돌아가는 8단계야말로 신원 연속성을 유지하는 이유이다. 비슷한 로트의 제품을 받은 여러 환자에게서 예상치 못한 양상이 보이면 제조사는 해당 로트를 찾아낼 수 있어야 한다.
SDK 타입은 최소한의 내부 모델이다. 레코드가 조직 경계를 넘을 때는 확립된 용어 체계를 써야 다른 시스템이 활용할 수 있다. 이상사례 용어는 규제 보고에서 흔히 MedDRA로 부호화하고, 개별 이상사례 보고는 ICH E2B(R3) 형식으로 전자 교환하며, 의료 IT 영역에서는 HL7 FHIR가 AdverseEvent 리소스와 활력징후·검사 결과용 관찰 리소스를 제공한다. WIA-BIO-005는 이 가운데 어느 것도 의무화하지 않으며, 이들과 SDK 타입 사이의 변환은 통합 계층에서 하는 것이 옳다. 실무 규칙은 원래의 임상 표현, 부호화된 용어, 등급 척도를 레코드 안에 함께 두는 것이다. 그래야 나중에 읽는 사람이 무엇이 관찰되었고, 어떻게 부호화되었으며, 어느 척도로 등급이 매겨졌는지를 언제나 확인할 수 있다.
규제기관 보고 기한은 관할권, 제품의 지위(임상시험인지 시판 중인지), 사례의 중대성과 예상 가능성에 따라 다르다. 그 의무는 제8장에서 정리하며, 안전성 모니터의 일은 모든 사례가 그 판단에 필요한 필드를 갖추도록 하는 것이다.
이 영역에서 SDK가 내놓는 것은 모두 권고이다. assessCRS와 assessICANS는 문자열과 긴급도 표지를, monitorSafety는 위험 수준과 권고를 돌려준다. 이 가운데 어느 출력도 스스로 처방을 내거나 용량을 바꾸거나 사례를 종결해서는 안 된다. 안전성 모니터의 가치는 알맞은 정보를 알맞은 사람에게 알맞은 때에 보이게 하고, 그 사람이 무엇을 했는지 기록하는 데 있다.
| 발생 조건 | 수신자 예 | 기대하는 확인 | 확인이 없을 때 |
|---|---|---|---|
urgency: 'routine' | 병상 간호사 작업 목록 | 다음 정기 평가 때 | 에스컬레이션 없음 |
urgency: 'urgent' 또는 riskLevel: 'high' | 당직 담당 의사 | 기관이 정한 시간 안에 | 세포치료 담당 전문의에게 상향 |
urgency: 'emergency' 또는 riskLevel: 'critical' | 의사와 신속대응팀 또는 중환자실팀 | 즉시 | 재호출 후 병원 응급 정책에 따라 상향 |
| 상충하는 출력(예: CRS는 토실리주맙 제시, ICANS는 회피 경고) | 담당 의사 | 명시적 결정 기록 | 열린 상태로 계속 표시 |
시간 기준은 의도적으로 기관에 맡겼다. 이 표는 에스컬레이션 설계의 구조를 보인 것이지 권장 값을 제시한 것이 아니다.
알림 피로는 모든 모니터링 시스템의 실제 위험이며, 세포치료 병동은 환자 한 명당 하루에도 많은 관찰을 만들어 낸다. 알림의 의미를 지키는 설계 선택이 몇 가지 있다. 이미 알려진 상태를 되풀이하는 관찰마다가 아니라 상태가 바뀔 때(새 등급, 새 사례, 높아진 위험 수준) 알림을 낸다. 한 환자에 대해 동시에 나온 출력은 하나의 알림으로 묶고 충돌을 강조한다. 날짜 기반 알림은 해당 환자·날짜에 대해 한 번 확인되면 중복을 억제한다. 그리고 7.1.4절에서 설명한 이유로 바이오마커 기준값만으로는 결코 알림을 띄우지 않는다.
모든 등급 판정, 확인, 재정의(override)는 감사 항목을 남겨야 한다. 누가 어떤 역할로, 언제, 어느 환자와 어느 제품에 대해 행동했는지, 그 순간 시스템이 무엇을 보여 주었는지(SDK 버전과 반환된 문자열 포함), 그리고 그 사람이 무엇을 결정했는지가 기록되어야 한다. 표시된 문자열을 저장하는 것이 중요한 까닭은 권고 문구가 SDK 릴리스마다 바뀔 수 있기 때문이다. 감사자는 임상의가 실제로 본 것을 확인할 수 있어야 한다. 같은 추적 기록은 조직이 사례를 처음 인지한 시점이 언제인가라는 약물감시의 질문에도 답한다. 많은 관할권에서 보고 기한이 바로 그 시점부터 계산된다.
severity와 serious를 독립적으로 입력하고, related에는 인과성을 평가한 사람을 함께 기록한다.장 요약. 안전성 모니터는 병상의 관찰을 등급이 매겨지고 감사 가능한 사례로 바꾼다. CRS와 ICANS는 ASTCT 2019 합의의 정의 그대로 등급을 매겨야 하며, 이를 위해서는 규격 본문의 두 지점, 곧 CRS의 FiO2 기준과 ICE 점수의 구성을 바로잡아야 한다. SDK의 assessCRS와 assessICANS는 호출자가 넘긴 등급을 권고 문구로 대응시키고, monitorSafety는 활성 사례를 네 단계의 위험 수준과 날짜 기반 알림으로 집계하는데, 그 기간은 설정 가능해야 한다. 이 메서드들을 둘러싼 통합 계층은 제조사, 병원, 약물감시 사이에서 제품·환자·사례 식별자를 연결하고, 알림 설계는 모든 결정을 임상의가 내리도록 보장한다. 제8장은 같은 레코드를 규제 준수와 적합성 시험으로 이어 간다.