너 1인분할수있어?

[DICOM] 파일 포맷, 보안/익명화, DICOMweb, Orthanc 실전

odod00 — Wed, 10 Jun 2026 15:20:40 +0900

Oleg Pianykh, Digital Imaging and Communications in Medicine (DICOM) (Springer, 2008) 정리 7편
참고 챕터: Ch 10, Ch 11 + 책에 없는 PS3.18 (DICOMweb)

시리즈 마무리 글

DICOM 파일 포맷 — DICM 헤더, Group 0002, DICOMDIR
보안 & 익명화 — HIPAA, 환자 데이터 보호의 함정
DICOMweb — 책에 없는 현대 PACS의 표준
Orthanc 실전 통합 시나리오 — AI 추론 앱 전체 파이프라인
시리즈 정리 + 다음 학습 방향

1. DICOM 파일 포맷 구조

1.1 전체 레이아웃

┌──────────────────────────────────────┐
│  Preamble (128 bytes, 보통 모두 0)    │
├──────────────────────────────────────┤
│  Magic: "DICM" (4 bytes)              │
├──────────────────────────────────────┤
│  File Meta Information (group 0002)   │  ← Explicit VR 강제
│  - Transfer Syntax UID                │
│  - SOP Class UID                      │
│  - SOP Instance UID                   │
│  - ...                                │
├──────────────────────────────────────┤
│  Data Object (group 0008 이상)         │  ← Meta에서 명시한 Transfer Syntax로
│  - Patient Name, ID, ...              │
│  - Image Pixel Data                   │
│  - ...                                │
└──────────────────────────────────────┘

1.2 Preamble (128 byte)

첫 128 byte는 자유롭게 사용
표준은 내용을 지정 안 함
대부분의 구현이 그냥 0으로 채움
TIFF 등 다른 포맷도 같은 관행

일부 응용에서 활용 가능: 예를 들어 이 영역에 small thumbnail BMP를 넣어두면 비-DICOM 뷰어에서도 미리보기 가능. 거의 안 쓰임.

1.3 "DICM" Magic Header

byte 129~132: 정확히 'D' 'I' 'C' 'M' 4글자
이게 DICOM 파일 식별의 유일한 신뢰 가능한 방법
파일 확장자도, UID도, 이름도 다 못 믿음

def is_dicom_file(path):
    with open(path, 'rb') as f:
        f.seek(128)
        return f.read(4) == b'DICM'

⚠️ 옛 ACR-NEMA 2.0 파일은 DICM 헤더 없음. 점점 드물어짐.

1.4 File Meta Information (Group 0002)

byte 133부터 시작. Explicit VR Little Endian으로 강제 인코딩.

Tag	이름	VR	필수	비고
`(0002, 0000)`	Group Length	UL	✅	group 0002 전체 길이
`(0002, 0001)`	File Meta Version	OB	✅	`0x00 0x01`
`(0002, 0002)`	Media Storage SOP Class UID	UI	✅	이 파일이 어떤 IOD인지
`(0002, 0003)`	Media Storage SOP Instance UID	UI	✅	이 인스턴스의 UID
`(0002, 0010)`	Transfer Syntax UID	UI	✅	데이터 영역 인코딩 방식 ⭐
`(0002, 0012)`	Implementation Class UID	UI	✅	누가 만들었나
`(0002, 0013)`	Implementation Version Name	SH	❌	≤16자! (6편 §7.2 함정)
`(0002, 0016)`	Source AET	AE	❌	어느 AE가 마지막 수정
`(0002, 0100)`	Private Info Creator UID	UI	❌
`(0002, 0102)`	Private Information	OB	❌

⭐ (0002, 0010) Transfer Syntax UID가 가장 중요. 이 값에 따라 그 뒤 Data Object를 Implicit/Explicit/압축 중 어떤 걸로 읽을지 결정.

1.5 Data Object (group 0008 이상)

우리가 2편에서 본 그 객체
Meta의 Transfer Syntax UID에 따라 인코딩
group 0008부터 시작 (group 0002 = meta, group 0004 = directory)

⚠️ 함정: 많은 DICOM 구현이 group 0002는 Explicit으로 잘 읽다가 Data 영역에서 Transfer Syntax 전환을 깜빡해서 깨짐.

1.6 ⚠️ 파일 이름 함정

DICOM 표준 PS3.10이 정의하는 File ID:

컴포넌트 8개, 각 8자 이내
대문자/숫자/언더스코어만 (A-Z 0-9 _)
컴포넌트는 \ 로 구분 (예: DIR1\SUBDIR\ABC123)

문제 1: 백슬래시 \ 는 DICOM 와일드카드!

"DIR1\SUBDIR\ABC123" = ?
  → 파일 경로?
  → 아니면 "DIR1 OR SUBDIR OR ABC123" ?
  → DICOM 소프트웨어가 헷갈림. 흔한 버그.

해결: 내부에서는 / 로 통일.

문제 2: .dcm 확장자

표준에 명시 안 됨 (어떤 곳은 prohibited, 어떤 곳은 required)
실무에선 다 쓰지만 공식적으로 모호함

문제 3: 실무에서는 SOP Instance UID를 파일명으로 쓰는 게 흔함

1.2.840.10008.234.2354.437345.79086.dcm
1.2.840.10008.5.1.4.1.1.4.20260601.103014.0042.dcm

장점: 항상 unique
단점: 너무 김 (Windows 경로 제한 260자 부딪힐 수 있음)

AI 추론 앱 / Orthanc 시 권장:

파일명에 환자 정보 절대 노출 X (보안)

SOP Instance UID 기반 (전역 유일)

디렉토리 구조로 정리: {StudyUID}/{SeriesUID}/{SOPInstanceUID}.dcm

2. DICOMDIR — 미디어 인덱스 파일

2.1 무엇인가

DVD/CD/USB 같은 이동식 미디어에 DICOM 영상을 담을 때 함께 들어있는 인덱스 파일.

DICOM_CD/
├── DICOMDIR          ← 이 파일이 인덱스
├── IMAGES/
│   ├── STUDY01/
│   │   ├── SERIES01/
│   │   │   ├── IMG001
│   │   │   ├── IMG002
│   │   │   └── ...
│   │   └── SERIES02/
│   └── STUDY02/
└── ...

DICOM CD를 PC에 넣었을 때 뷰어가 "환자 / 검사 / 시리즈 / 영상 목록" 을 트리로 보여주는 게 DICOMDIR을 읽어서 만든 것.

2.2 구조

DICOMDIR도 하나의 DICOM 파일. group 0002 + Basic Directory IOD.

DICOMDIR (자체도 DICOM 파일)
├── Preamble + DICM
├── Group 0002 (File Meta)
└── Data Object (Basic Directory IOD)
    ├── (0004, 1130) File Set ID
    ├── (0004, 1200) Offset of first root record
    ├── (0004, 1220) Directory Record Sequence (SQ)
    │   ├── Item 1: PATIENT record
    │   ├── Item 2: STUDY record
    │   ├── Item 3: SERIES record
    │   ├── Item 4: IMAGE record (파일 위치 포함)
    │   ├── Item 5: IMAGE record
    │   └── ...
    └── ...

2.3 Directory Record 종류

(0004, 1430) Directory Record Type:

PATIENT
STUDY
SERIES
IMAGE ⭐ — 실제 파일 위치 포함
OVERLAY, WAVEFORM, SR DOCUMENT, ...

각 IMAGE record에는:

(0004, 1500) Referenced File ID — 파일 경로
(0004, 1510) Referenced SOP Class UID
(0004, 1511) Referenced SOP Instance UID
(0004, 1512) Referenced Transfer Syntax UID

→ DICOMDIR만 읽어도 어떤 환자 / 검사가 들어있는지 빠르게 파악 가능.

2.4 AI 추론 앱에서의 활용

병원 외부에서 받은 CD/DVD에 담긴 영상을 AI 추론 앱이 처리해야 할 때:

import pydicom

# DICOMDIR 읽기
dcmdir = pydicom.dcmread("D:/DICOMDIR")

# 환자/검사/시리즈/영상 트리 순회
for patient_record in dcmdir.patient_records:
    print(f"Patient: {patient_record.PatientName}")
    for study in patient_record.children:
        print(f"  Study: {study.StudyDate}")
        for series in study.children:
            print(f"    Series: {series.Modality}")
            for image in series.children:
                # 실제 파일 위치
                rel_path = "/".join(image.ReferencedFileID)
                file_path = f"D:/{rel_path}"
                ds = pydicom.dcmread(file_path)
                # AI 추론 입력으로 사용

Orthanc 사용 시: REST API로 DICOMDIR 자동 생성 가능
GET /studies/{id}/media   → DICOMDIR + 영상 zip

2.5 한계

DICOMDIR 작성에는 모든 영상이 사전에 다 있어야 함 (length 미리 계산)
영상 추가/삭제 시 DICOMDIR 다시 빌드 필요
실무에서는 자동 생성에 맡기는 게 정신건강에 좋음 (Orthanc, dcm4chee 등)

3. DICOM 보안 — 평문 그대로 노출

3.1 ⚠️ 충격적 사실: DICOM 파일은 사실상 평문

저자의 hacking 데모. 메모장(WordPad)으로 열어도 환자 정보가 보임

(binary garbage) DICM (binary)
... SMITH^JOHN ... 19560423 ... M ... PATIENT123 ... DR.KIM ...

이름, ID, 생년월일이 그냥 ASCII로 박혀 있음.

3.2 평문 = 변조 가능

저자가 시연

WordPad에서 DICOM 파일 열기
SMITH^JOE 검색
같은 길이(9자)로 다른 이름 입력 (BETH^MARY)
저장 → DICOM 뷰어에서 환자 이름이 바뀌어 보임

→ VR length가 변하지 않게 같은 길이로 바꾸면 DICOM 구조 그대로 유지되면서 데이터 변조됨. 어떤 DICOM 검증도 못 잡음.

3.3 ⚠️ 픽셀 추출도 단순함

저자의 또 다른 시연:

CT/MR 영상이 보통 256×256 또는 512×512, 1 or 2 byte/pixel
파일 크기 보고 차원 추측
파일 끝에서 N×N×bytes 만큼 잘라내면 그게 픽셀
BMP로 변환 가능

→ DICOM 파일은 암호화되지 않으면 평문. PACS 시스템 전체를 보호망으로 둘러싸야 함.

4. Workflow 보안 — 환경 단단히

4.1 기본 원칙 (HIPAA 베스트)

전용 서버에 격리 — 영상 서버에 다른 서비스 X
물리적 보안 — 잠긴 방, 출입 통제
백업 매일 — 영상 손실은 회복 불가
다른 의료기관과 서버 공유 절대 금지
사용자별 권한 분리 — 각자 자기 데이터만
VPN + 방화벽
자동 화면 잠금 (15분 idle)

4.2 VPN vs 방화벽 — 자주 헷갈림

	방화벽	VPN
보호 범위	단일 컴퓨터	두 컴퓨터 간 통신 전체
통신 자체 암호화	❌	✅
외부 접근 차단	✅	✅

→ 방화벽만으로는 부족. 데이터가 공용망을 지나가면 평문 노출. VPN 필수.

4.3 ❌ 안티패턴

저자가 본 사고:

"그냥 우리 서버에 로그인해서 봐주세요" — 가장 흔하고 가장 위험
"옛날 DOS 컴퓨터가 보안이 낫다" — 정반대. 권한 관리 자체가 없음
"컴퓨터를 안 쓰면 보안이 좋다" — 잠긴 문 없는 은행

4.4 ⭐ HIPAA가 정의한 18가지 PHI (Protected Health Information)

DICOM에서 제거/익명화 대상:

이름 (Name)
지리 정보 (주보다 작은 단위, 우편번호 포함)
날짜 (생년월일, 입원, 퇴원, 검사 등 모든 날짜)
전화번호
팩스
이메일
사회보장번호
의료기록번호
보험 수혜자 번호
계좌번호
자격증/면허 번호
차량 식별번호
장비 시리얼 번호
URL
IP 주소
생체 식별자 (지문, 음성)
얼굴 전체 사진 (CT/MR head로 3D 재구성 가능!)
기타 식별 가능한 모든 코드

⚠️ 17번이 의외의 함정. Head CT/MR을 3D rendering하면 얼굴 복원됨. 진정한 익명화 어려움.

5. 익명화 (Anonymization) ⭐⭐⭐

PACS 통신 모듈에서 가장 중요한 보안 작업.

5.1 익명화 정의

원본 파일에서 PHI를 제거하거나 변환해 환자 식별 불가능하게 만드는 작업.

비가역적 (irreversible) — 일반적으로 원본 복원 불가
그래서 암호화보다 안전: 해커도 없는 데이터는 못 뽑음
단점: 임상 가치 손상 가능성

5.2 단순 wipe의 함정

❌ 잘못된 익명화: Patient ID를 빈 값으로

(0010, 0020) Patient ID = ""

결과:

DICOM 표준: Patient ID는 Type 1 (필수 + 값 필수)
빈 값 = 와일드카드로 해석될 수도 (3편 §2.2)
결과: 모든 환자가 한 명으로 merge → "Mr. Unknown" 사고

5.3 일관성 (Consistency) 함정

❌ 잘못된 익명화: 같은 환자를 다르게 매핑

Day 1:  Patient ID "12345" → "anon_001"
Day 2:  Patient ID "12345" → "anon_487"   ← 다른 값!

결과: 같은 환자의 시간순 검사가 분리 → 추적 불가, 임상 가치 0.

✅ 올바른 익명화: 결정론적 매핑 (deterministic)

# 같은 원본 → 항상 같은 가명
import hashlib

def anonymize_patient_id(original_id, salt):
    h = hashlib.sha256((original_id + salt).encode()).hexdigest()
    return f"ANON_{h[:12]}"

anonymize_patient_id("12345", salt="my_secret")
# → 항상 "ANON_a8f3c4d2e9b1"

→ 매번 같은 결과. 같은 환자 = 같은 가명. 다른 환자 = 다른 가명.

5.4 충돌 함정

해시 출력 공간이 좁으면 다른 환자 → 같은 가명 가능.

# ❌ 위험: 16비트만 사용 → 65,536명 넘으면 collision
short_id = h[:4]

# ✅ 안전: 충분히 긴 prefix
long_id = h[:16]   # 16^16 가지

5.5 픽셀에 박힌 정보 (Burned-in PHI) ⚠️

US, 일부 X-ray는 픽셀 데이터에 환자 이름이 그려져 있음.

┌──────────────────────────────────┐
│  PATIENT: SMITH^JOHN             │  ← 이 부분이 픽셀!
│  ID: 12345                       │  ← Tag로는 못 지움
│  DATE: 2026-06-10                │
│ ┌──────────────────────────────┐ │
│ │                              │ │
│ │      [Ultrasound]            │ │
│ │                              │ │
│ └──────────────────────────────┘ │
└──────────────────────────────────┘

태그만 익명화하면 픽셀의 텍스트는 그대로 남음.

해결책:

단순: 상단 N픽셀을 검은색으로 (US 헤더 영역) → 임상 정보 손실 위험
OCR로 텍스트 영역 인식 → 자동화 어려움
메타데이터 (0028, 0301) Burned In Annotation = "YES" 가 있는지 확인 + 사람 검수

실무 추천: Burned-in 가능 modality (US, 일부 X-ray) 는 반드시 사람 검수 단계 거치기.

5.6 임상 가치 균형

저자의 노하우: HIPAA 18가지를 다 지우면 임상 데이터로 못 씀.

Tag	HIPAA	임상적 가치	권장
Patient Name	❌	낮음	익명화
Patient ID	❌	낮음	결정론적 매핑
Birth Date	❌	나이 계산에 필요	연도만 남기거나 나이로 변환
Patient Age	❌	중간	보통 남김
Study Date	❌	시계열 추적에 필수	남기는 게 표준 (저자 권장)
Study Description	⚠️	높음 (예: "Prostate MR Protocol")	남김
Patient Weight	❌	임상 중요	남김
Patient Comments	⚠️	가변	검토 후 결정
Referring Physician	❌	낮음	제거
Institution Name	❌	낮음	제거 또는 일반화

저자: "Study Date를 지우면 진단 데이터로서 가치가 사라진다. read radiologist에게는 남기되, 공개 시에는 월 단위로 jitter (예: ±15일 random shift, 환자별 일관)."

5.7 ⚠️ 안 좋은 패턴 — 사설 태그로 숨기기

저자가 발견한 어처구니 없는 익명화 도구:

원본 (0010, 0010) Patient Name = "SMITH^JOHN"
→ 익명화 후:
  (0010, 0010) = "ANON_X1"        ← 가명
  (0099, 1010) = "SMITH^JOHN"     ← 원본을 사설 태그에 숨김 ⚠️

WordPad로 열면 그대로 보임. "숨기기"는 보안이 아니다.

5.8 권장 익명화 도구

표준 + 검증된 도구:

DICOM PS3.15 Annex E — 공식 익명화 가이드라인
gdcmanon (GDCM의 익명화) — 오픈소스
dcm4che dcm2dcm + 익명화 프로파일
pydicom-anonymizer (간단한 Python 도구)
Orthanc 익명화 API ⭐

Orthanc 익명화 예시

import requests

# POST: Study 단위 익명화
r = requests.post(
    "http://orthanc:8042/studies/{study_id}/anonymize",
    json={
        "Replace": {
            "PatientName": "ANON_001",
            "PatientID": "ANON_001"
        },
        "Keep": [
            "StudyDescription",
            "SeriesDescription",
            "StudyDate"     # 임상 가치 위해 유지
        ],
        "KeepPrivateTags": False,   # 사설 태그 제거
        "Force": True,
        "DicomVersion": "2021b"      # PS3.15 프로파일 버전
    }
)

# 결과: 새 익명 study가 생성됨
new_study_id = r.json()["ID"]

Orthanc는 PS3.15 Annex E 표준 프로파일을 자동 적용. 안전한 default.

6. 암호화 (Encryption)

6.1 익명화 vs 암호화

	익명화	암호화
가역성	비가역	가역 (키 있으면 복원)
목적	정보 자체 제거	정보 숨김
임상 손실	가능	없음
위험	키 분실 시 영구 손실	키 분실 시 복호화 불가

6.2 알고리즘 — DICOM이 채택한 것들

알고리즘	종류	용도
RSA	비대칭	키 교환, 디지털 서명
AES	대칭	대용량 데이터 암호화 (현대 표준)
DES, 3DES	대칭	(구식, 점점 비추)
SHA-1/256/512	해시	무결성 검증

6.3 공개키/개인키 — 돼지저금통 비유 ⭐

저자의 비유:

돼지저금통: 동전 넣기는 쉬움, 꺼내기는 키 없으면 어려움
같은 원리: 공개키로 암호화는 쉬움, 개인키 없이 복호화는 사실상 불가능

수학적 기반: 큰 소수 인수분해

두 큰 소수 A × B = N (곱셈은 빠름)
N에서 A, B 찾기 (인수분해는 매우 느림)
A를 알려주면 B = N / A (나눗셈은 빠름)

→ 이게 RSA의 핵심.

6.4 SHA 무결성 검증

원본 데이터 → SHA-256 → 짧은 hash 문자열 (32 byte)

데이터 + hash 를 같이 전송
받는 쪽에서 다시 SHA-256 돌려서 일치 확인
→ 1바이트라도 변조되면 hash 완전히 다름

5편 §8.1의 Storage Commitment와 결합 가능: "받았는데 무결한가?"

6.5 디지털 서명 vs 스캔 서명

디지털 서명 ≠ 스캔된 사인 이미지.

❌ 가짜 디지털 서명:
  - 사인을 사진으로 찍어서 PDF에 붙이기
  - "Signed by: 김의사" 텍스트
  - 단순 체크박스

✅ 진짜 디지털 서명:
  - 인증기관(CA)에서 발급한 인증서
  - 개인키로 서명
  - 공개키로 검증
  - 변조 시 무효화
  - 서명 시점/위치/이유 기록

DICOM PS3.15 Annex C에서 정의. SR(Structured Report) 에 서명 첨부 가능.

6.6 Secure DICOM File Format (Ch 10.2.2)

PS3.10이 정의하는 보안 파일 포맷:

전체 DICOM 파일을 하나의 암호화된 객체로 래핑
키 없이는 group 0002조차 못 봄
디지털 서명 첨부 가능

⚠️ 현실: 거의 모든 PACS가 미지원. 표준이 너무 모호. VPN + 안전한 저장 환경으로 보안하는 게 표준 패턴.

7. DICOMweb — 책에 없지만 현대 PACS의 표준 ⭐

Pianykh 책 2008년판에는 없음. 하지만 현대 PACS 통신에서 빠질 수 없는 표준 (PS3.18, 2011~).

7.1 등장 배경

DIMSE의 한계 (6편 §13):

점-대-점 정적 등록 (AE Title + IP + Port 사전 등록)
방화벽 친화적이지 않음 (특히 C-Move)
모바일/웹/클라우드와 잘 안 맞음

DICOMweb의 해결:

HTTP REST API 기반
정적 등록 불필요
방화벽 통과 (HTTPS 사용)
JSON 응답 가능 (XML/DICOM도 가능)

7.2 3개 핵심 서비스

DIMSE	DICOMweb	역할
C-Store	STOW-RS (Store Over the Web)	영상 업로드
C-Find	QIDO-RS (Query based on ID for DICOM Objects)	검색
C-Move / C-Get	WADO-RS (Web Access to DICOM Objects)	다운로드

7.3 QIDO-RS — 검색

GET /studies?PatientID=12345&StudyDate=20260601-
Accept: application/dicom+json

응답 (JSON):

[
  {
    "0020000D": {"vr": "UI", "Value": ["1.2.840.xxx"]},
    "00100010": {"vr": "PN", "Value": [{"Alphabetic": "SMITH^JOHN"}]},
    "00100020": {"vr": "LO", "Value": ["12345"]},
    "00080020": {"vr": "DA", "Value": ["20260601"]},
    "00080060": {"vr": "CS", "Value": ["MR"]}
  },
  ...
]

→ JSON으로 응답하니까 웹 프론트엔드에서 바로 사용 가능.

7.4 WADO-RS — 다운로드

Study 통째로

GET /studies/{StudyUID}
Accept: multipart/related; type="application/dicom"

→ Multipart 응답으로 모든 영상 받음.

단일 영상 메타데이터만 (JSON)

GET /studies/{StudyUID}/series/{SeriesUID}/instances/{SOPUID}/metadata
Accept: application/dicom+json

픽셀만 (rendered PNG/JPEG)

GET /studies/.../instances/.../rendered?window=400,40
Accept: image/jpeg

→ 브라우저에서 바로 표시 가능! 별도 DICOM 디코더 불필요.

7.5 STOW-RS — 업로드

POST /studies
Content-Type: multipart/related; type="application/dicom"

(여러 DICOM 파일을 multipart로 첨부)

7.6 DICOMweb의 장점

                  DIMSE                    DICOMweb
                ────────                  ──────────
연결            점-대-점 정적 등록         HTTP 호출 즉시
인증            AE Title whitelist         OAuth2, JWT, Bearer Token
방화벽          C-Move 특히 곤란            HTTPS 1포트만
프론트엔드      DICOM 라이브러리 필요       JSON + rendered JPEG
스케일링        제한적                     로드밸런서 / CDN
캐싱            없음                      HTTP 캐시
모니터링        custom                    표준 HTTP 로그

7.7 Orthanc의 DICOMweb 플러그인

Orthanc는 공식 DICOMweb 플러그인 제공:

// orthanc.json
{
  "Plugins": [
    "/usr/share/orthanc/plugins/libOrthancDicomWeb.so"
  ],
  "DicomWeb": {
    "Enable": true,
    "Root": "/dicom-web/",
    "EnableMetadata": true,
    "PublicRoot": "https://my-hospital.com/dicom-web/"
  }
}

→ 자동으로

/dicom-web/studies (QIDO-RS)
/dicom-web/studies/{uid}/series/... (WADO-RS)
POST /dicom-web/studies (STOW-RS)

엔드포인트 활성화.

7.8 ⚠️ DIMSE를 안 버리는 이유

기존 PACS / modality의 90%가 DIMSE만 지원
DICOMweb 지원 PACS는 신형/고급
현실의 통합 모듈은 DIMSE + DICOMweb 둘 다 지원해야 함

Orthanc는 양쪽 다 동시 지원. DIMSE로 받고 DICOMweb으로 노출 가능.

8. AI 추론 앱 전체 통합 시나리오 (실전)

이제까지 본 모든 개념을 종합한 현실적 배포 아키텍처.

8.1 아키텍처 다이어그램

                      ┌─────────────────────────────────┐
                      │       병원 내부 네트워크          │
                      │                                  │
   ┌───────────┐      │   ┌─────────────────────────┐  │
   │           │      │   │                          │  │
   │  CT/MR    │─DIMSE│   │   Hospital PACS          │  │
   │ Scanner   │─────→│   │   (DIMSE + DICOMweb)     │  │
   │           │      │   │                          │  │
   └───────────┘      │   └────────┬────────────────┘  │
                      │            │                    │
                      │            │ DIMSE (C-Store/Move)│
                      │            │ 또는 DICOMweb        │
                      │            ↓                    │
                      │   ┌─────────────────────────┐  │
                      │   │     Orthanc (게이트웨이)   │  │
                      │   │                          │  │
                      │   │  ┌─────────────────────┐ │  │
                      │   │  │  DIMSE SCP (4242)    │ │  │
                      │   │  │  DICOMweb (8042)     │ │  │
                      │   │  └─────────────────────┘ │  │
                      │   │                          │  │
                      │   │  Lua / Python plugin     │  │
                      │   │  └─→ AI 추론 트리거        │ │  │
                      │   └────────┬────────────────┘  │
                      │            │                    │
                      │            ↓                    │
                      │   ┌─────────────────────────┐  │
                      │   │   AI 추론 앱              │  │
                      │   │   (nnU-Net, etc.)        │  │
                      │   │                          │  │
                      │   │  ┌─────────────────────┐ │  │
                      │   │  │ Preprocessing       │ │  │
                      │   │  │ Inference (GPU)     │ │  │
                      │   │  │ Postprocessing      │ │  │
                      │   │  │ DICOM SC/SR 생성     │ │  │
                      │   │  └─────────────────────┘ │  │
                      │   └────────┬────────────────┘  │
                      │            │                    │
                      │            │ 결과 업로드          │
                      │            ↓                    │
                      │   ┌─────────────────────────┐  │
                      │   │     Orthanc             │  │
                      │   │  → DIMSE C-Store        │  │
                      │   │  → Hospital PACS         │  │
                      │   └──────────────────────────┘  │
                      └─────────────────────────────────┘

8.2 단계별 흐름

Step 1: 의사 트리거

PACS UI 또는 별도 시스템에서 "이 환자 AI 분석" 클릭.

Step 2: PACS → Orthanc로 영상 전달

방법 A (DIMSE):

PACS → DIMSE C-Store → Orthanc:4242
SOP Class UID: 1.2.840.10008.5.1.4.1.1.4 (MR)
Transfer Syntax: 1.2.840.10008.1.2 (Implicit VR LE)

방법 B (DICOMweb):

PACS → STOW-RS POST /dicom-web/studies → Orthanc:8042

Step 3: Orthanc Lua/Python 훅 → AI 트리거

-- orthanc.json: "LuaScripts": ["./on_store.lua"]
function OnStoredInstance(instanceId, tags, metadata)
    -- 어떤 modality + body part?
    if tags['Modality'] == 'MR' and
       string.find(tags['StudyDescription'] or '', 'PROSTATE') then
        -- AI 추론 앱 호출
        os.execute('curl -X POST http://ai-app:8080/infer?instance=' .. instanceId)
    end
end

Step 4: AI 추론

# AI 추론 앱 (Python)
@app.post("/infer")
def infer(instance: str):
    # Orthanc에서 영상 다운로드 (DICOMweb)
    r = requests.get(
        f"http://orthanc:8042/instances/{instance}/file",
        auth=("user", "pass")
    )
    ds = pydicom.dcmread(io.BytesIO(r.content))

    # 추론용 numpy array
    pixel_array = ds.pixel_array

    # 추론
    result = ai_model(pixel_array)
    segmentation_mask = result['mask']

    # Secondary Capture IOD 생성
    sc = create_secondary_capture(
        pixel_array=segmentation_mask,
        patient_id=ds.PatientID,            # 원본 유지
        study_uid=ds.StudyInstanceUID,      # 원본 유지!
        series_uid=generate_uid(),          # 새로 생성
        sop_instance_uid=generate_uid(),    # 새로 생성
        sop_class_uid="1.2.840.10008.5.1.4.1.1.7"  # SC
    )

    # Orthanc에 다시 업로드 → PACS로 자동 전달
    requests.post(
        "http://orthanc:8042/instances",
        data=sc.tobytes(),
        headers={"Content-Type": "application/dicom"}
    )

Step 5: Orthanc → PACS로 결과 송신

Orthanc에 자동 라우팅 규칙 설정

-- 결과 SC가 들어오면 자동 PACS 전송
function OnStoredInstance(instanceId, tags, metadata)
    if tags['Modality'] == 'SC' and
       string.find(tags['SeriesDescription'] or '', 'AI_RESULT') then
        SendToModality(instanceId, 'HOSPITAL_PACS')
    end
end

Step 6: PACS UI에 결과 표시

PACS UI에서 환자 study 펼치면:

SMITH^JOHN — 2026-06-10 — Prostate MR
├── Series 1: T2W axial
├── Series 2: DWI
├── Series 3: ADC
└── Series 99: AI_RESULT (Secondary Capture)   ← AI 추론 결과

8.3 익명화가 필요한 시나리오

연구 데이터로 외부 공유 시

# Orthanc 익명화 API
r = requests.post(
    f"http://orthanc:8042/studies/{study_id}/anonymize",
    json={
        "Replace": {
            "PatientName": deterministic_anonymize(name, salt),
            "PatientID": deterministic_anonymize(pid, salt)
        },
        "Keep": ["StudyDescription", "SeriesDescription"],
        "KeepPrivateTags": False,
        "Force": True
    }
)
# r.json()["Path"] = 익명화된 새 study의 URL

8.4 최종 체크리스트

배포 전 점검

☐ Orthanc + AI 앱이 분리된 네트워크 세그먼트
☐ Orthanc ↔ PACS DIMSE 양방향 등록 완료
☐ C-Echo 양방향 verify 통과
☐ Transfer Syntax 협상 OK (Implicit LE + 압축 옵션)
☐ Max PDU Length 조정 (필요시 65536)
☐ Orthanc DICOMweb 활성화
☐ AI 결과 SOP Class UID 올바름 (SC 또는 SR)
☐ 결과의 Patient/Study UID 원본 유지
☐ 결과의 Series/SOP Instance UID 새로 생성
☐ 익명화 (연구 데이터인 경우)
☐ 모든 통신 VPN 또는 HTTPS
☐ Orthanc 인증 활성화 (RegisteredUsers)
☐ 로그 보존 + 외부 SIEM 연동
☐ 백업 정책
☐ 장애 시 fallback (큐, 재시도, 알림)

9. 시리즈 마무리 — 전체 그림

큰 그림으로 정리한다.

9.1 7편 매핑

편	주제	핵심 개념
1편	DICOM 입문 + VR	27가지 VR, Endian, 짝수 길이
2편	Tag, Dictionary, Encoding	(group,element), Implicit/Explicit, SQ
3편	4계층 + IOD	Patient/Study/Series/Image, Module → IE → IOD
4편	C-Echo, C-Store, C-Find	AE Title, SCU/SCP, DIMSE
5편	C-Move, C-Get, MWL	Q/R, SC/SR (AI 결과 출력 포맷)
6편	Association ⭐	Abstract/Transfer Syntax 협상, PDU, 디버깅 본진
7편	파일, 보안, DICOMweb, Orthanc	DICM 헤더, 익명화, REST API

9.2 DICOM의 모순

아름다운 점:

1990년대 설계가 2026년에도 작동
객체지향 모델 (IOD/SOP)
모든 modality를 하나의 표준으로

불편한 점:

한 표준이 16권 문서로 분산
점-대-점 정적 등록의 한계
"No reason given" 거부 메시지
Implementation Version Name 16자 같은 사소한 함정
시간대 미지원
익명화 vs 임상 가치의 영원한 트레이드오프

9.3 책에서 다 못 다룬 것 (별도 학습 권장)

주제	학습 자료
DICOMweb	DICOM PS3.18, dicomweb.org
DICOM SEG (Segmentation 전용 SOP)	PS3.3 Annex A.51
DICOM SR Templates	David Clunie의 책
IHE Profiles (워크플로우 통합)	ihe.net
HL7 FHIR + DICOM	FHIRcast
DICOM 표준 매뉴얼 (공식)	dicomstandard.org

9.4 다음 단계 — 실전으로

이 시리즈가 이론 + 개념까지 줬다면, 다음은:

Orthanc 직접 설치 + 가지고 놀기
- DIMSE C-Echo, C-Store 보내보기
- DICOMweb 호출해보기
- Lua 스크립트로 자동화
pynetdicom 으로 작은 SCU/SCP 직접 짜보기
- 책의 표를 코드로 옮겨보기
Wireshark로 DIMSE 패킷 보기
- A-Associate-RQ/AC 까보기
- 6편의 PDU 구조가 진짜로 그렇게 생겼나 확인
PACS 벤더의 실제 Conformance Statement 읽기
- 시리즈 전체 개념이 어떻게 명세되어 있는지
DICOM 익명화 도구 비교
- PS3.15 Annex E 프로파일
- Orthanc vs gdcm vs custom

10. 핵심 정리 (전체)

┌─────────────────────────────────────────────────────────────────┐
│                        DICOM의 전체 구조                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  데이터 계층                                                       │
│  ├── VR (27가지)                          ─── 1편                 │
│  ├── Tag (group, element)                  ─── 2편                 │
│  ├── Encoding (Implicit/Explicit)          ─── 2편                 │
│  ├── Patient/Study/Series/Image            ─── 3편                 │
│  └── IOD (Information Object Definition)   ─── 3편                 │
│                                                                  │
│  서비스 계층                                                       │
│  ├── SOP = DIMSE + IOD                     ─── 4편                 │
│  ├── C-Echo / C-Store / C-Find             ─── 4편                 │
│  ├── C-Move / C-Get / MWL                  ─── 5편                 │
│  └── Storage Commitment / SR / SC          ─── 5편                 │
│                                                                  │
│  통신 인프라                                                        │
│  ├── Association                           ─── 6편                 │
│  ├── Abstract / Transfer Syntax            ─── 6편                 │
│  ├── Presentation Context                  ─── 6편                 │
│  └── PDU                                   ─── 6편                 │
│                                                                  │
│  파일 + 보안                                                        │
│  ├── DICOM File Format                     ─── 7편                 │
│  ├── DICOMDIR                              ─── 7편                 │
│  ├── 익명화 / 암호화                          ─── 7편                 │
│  └── DICOMweb (현대 표준)                    ─── 7편                 │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

DICOM은 이론은 단순하지만 실무가 까다로운 표준이다.

참고

Pianykh, O.S. Digital Imaging and Communications in Medicine (DICOM). Springer, 2008.
공식 표준:
- PS3.10 — Media Storage and File Format
- PS3.11 — Media Storage Application Profiles
- PS3.12 — Media Formats and Physical Media
- PS3.15 — Security and System Management Profiles ⭐
- PS3.18 — Web Services (DICOMweb) ⭐
라이브러리/도구:
- Orthanc — DICOM 서버 + DICOMweb 게이트웨이
- pydicom — Python DICOM 파일 처리
- pynetdicom — Python DIMSE
- dcm4che — Java DICOM 도구
- GDCM — C++ DICOM 라이브러리 + 익명화
참고 사이트:
- DICOM Standard 공식
- DICOMweb 가이드
- DICOM Tag 검색 — 시각화된 dictionary
학습 자료:
- Clunie, D. DICOM Structured Reporting (2000)
- IHE Profiles (워크플로우 통합)
- NEMA의 DICOM webinar / Working Group 문서

[DICOM] DICOM Association — PACS 통신 디버깅이 일어나는 곳

odod00 — Wed, 10 Jun 2026 14:53:28 +0900

Oleg Pianykh, Digital Imaging and Communications in Medicine (DICOM) (Springer, 2008) 정리 6편
참고 챕터: Ch 9

이전 편에서 우리는 얼버무리고 넘어온 것이 있다.

"두 AE가 통신하려면 먼저 Association 을 맺어야 한다"

이번 6편은 그 Association의 정체를 다룬다.

PACS 연동에서 가장 자주 마주치는 에러들

Association rejected (no reason given)
Abstract syntax not supported
Transfer syntaxes not supported
Implementation version name too long
Calling AE not in whitelist

이 모든 게 Association 협상 단계에서 일어난다.

저자가 말한 그대로

"DICOM association failures account for the vast majority of all DICOM networking problems."

이 글이 끝나면 Orthanc/pynetdicom 로그를 보고 직접 해석할 수 있다.

1. Association이란?

1.1 DICOM Upper Layer (DICOM UL)

DICOM Association은 TCP/IP 위에서 도는 DICOM 전용 통신 계층.

┌─────────────────────────────────────┐
│    DIMSE (Service messages)          │  ← 4-5편
├─────────────────────────────────────┤
│    DICOM Upper Layer (UL)            │  ← 6편 (이번 글)
│    = Association 협상 + PDU 전송      │
├─────────────────────────────────────┤
│    TCP / IP                          │
└─────────────────────────────────────┘

TCP는 그냥 "바이트 스트림 옮기는 통로"일 뿐.

DICOM UL이 그 위에

"우리가 통신할 수 있는 사이인지" 협상하고
"어떤 형식으로 데이터를 주고받을지" 합의하고
"실제 데이터를 PDU 단위로 흘려보낸다.

1.2 Association = "DICOM 핸드셰이크"

전화 비유:

TCP 연결 = 전화선이 깔림
Association 협상 = "여보세요, ○○입니다. △△ 하려고요" + "네, 가능합니다"
DIMSE 메시지 = 실제 대화
Association 종료 = "끊을게요" + "네 끊으세요"

Association 협상 실패하면 그 뒤 통신은 절대 안 됨. TCP는 살아있어도 의미 없음.

2. Association의 3막 (직관적 이해) ⭐

저자가 책에서 만든 비유. 이거 하나만 알고 있어도 50% 끝.

Act 1 — Association Establishment (협상)

MR scanner: "Hi, 나 MR scanner고 DICOM 할 줄 알아. 너도?"
ARCHIVE:    "응 나도 DICOM 함"

MR:         "너 MR Image Storage SCP 야?"
ARCHIVE:    "맞아"

MR:         "MR 영상 100장 있어. 압축 안 한 채로 보낼 수도 있고,
             JPEG2000으로 압축해서 보낼 수도 있고, JPEG-LS도 가능."
ARCHIVE:    "OK, MR 받을게. 압축 안 한 거로 받을게."

MR:         "좋아, 보낼게."
ARCHIVE:    "받을 준비 완료."

→ 이게 A-Associate-RQ ↔ A-Associate-AC 의 본질.

Act 2 — Data Transfer (전송)

MR:      "1번 영상." "2번." "3번..."
ARCHIVE: "1번 OK." "2번 OK..."

→ P-Data-TF PDU로 실제 영상 흐름.

Act 3 — Association Termination (종료)

MR:      "100장 다 보냈음. 0장 실패. 성공. 끝낼게."
ARCHIVE: "다 받았음. 끝!"

(연결 종료)

→ A-Release-RQ ↔ A-Release-RP.

3. Abstract Syntax — "어떤 서비스?"

협상 단계에서 가장 먼저 합의하는 것: 무슨 SOP에 대해 통신할 건지.

3.1 Abstract Syntax = SOP Class UID

"Abstract Syntax UID = SOP Class UID" 는 사실상 같은 말. 둘 다 같은 UID를 가리킨다.

Abstract Syntax 1.2.840.10008.5.1.4.1.1.4 = MR Image Storage SOP
                                              ↑
                                        이 SOP를 위해 협상하자

3.2 주요 Abstract Syntax UID

분류	Abstract Syntax 이름	UID
Verification	Verification	`1.2.840.10008.1.1`
Storage	CR Image	`1.2.840.10008.5.1.4.1.1.1`
Storage	CT Image	`1.2.840.10008.5.1.4.1.1.2`
Storage	MR Image ⭐	`1.2.840.10008.5.1.4.1.1.4`
Storage	US Image	`1.2.840.10008.5.1.4.1.1.6.1`
Storage	Secondary Capture ⭐	`1.2.840.10008.5.1.4.1.1.7`
Storage	Enhanced SR	`1.2.840.10008.5.1.4.1.1.88.22`
Q/R Find	Study Root	`1.2.840.10008.5.1.4.1.2.2.1`
Q/R Get	Study Root	`1.2.840.10008.5.1.4.1.2.2.3`
Q/R Move	Study Root	`1.2.840.10008.5.1.4.1.2.2.2`
Q/R Find	Patient Root	`1.2.840.10008.5.1.4.1.2.1.1`
MWL	MWL Find	`1.2.840.10008.5.1.4.31`

3.3 인코딩

A-Associate-RQ 메시지 안에서 Abstract Syntax는 이런 형식:

┌──────┬──────────┬─────────┬─────────────────────┐
│ 0x30 │ reserved │ Length  │  UID string         │
│ 1byte│ 1 byte=0 │ 2 bytes │  L bytes            │
└──────┴──────────┴─────────┴─────────────────────┘

예: 1.2.840.10008.5.1.4.1.1.4 (MR Image Storage, 25자 = 0x19)

30 00 00 19 31 2E 32 2E 38 34 30 2E 31 30 30 30 38 2E 35 2E 31 2E 34 2E 31 2E 31 2E 34

3.4 거부 시나리오

ARCHIVE가 MR Image Storage만 지원하고 CT Image Storage는 미지원이라면

CT 장비 → ARCHIVE: "1.2.840.10008.5.1.4.1.1.2 (CT Storage) SCP 야?"
ARCHIVE → CT 장비: "❌ 아니야. Abstract Syntax not supported."
                    → 또는 그 Presentation Context만 거부

Abstract Syntax는 협상 불가. 이건 장비 기능 자체. 합의가 아닌 매칭.

4. Transfer Syntax — "어떻게 인코딩?"

이게 DICOM 호환성의 마법. 1980년대 CT 스캐너가 2026년 Windows 노트북과 통신할 수 있는 이유.

4.1 Transfer Syntax가 다루는 것

Endian (Big/Little) — 1편 6번 참조
VR encoding (Implicit/Explicit) — 2편 4번
압축 알고리즘 (JPEG, JPEG-LS, JPEG2000, RLE)

4.2 주요 Transfer Syntax UID

Transfer Syntax	UID	의미
Implicit VR Little Endian ⭐	`1.2.840.10008.1.2`	DICOM 기본값. 무조건 지원 필수
Explicit VR Little Endian	`1.2.840.10008.1.2.1`	Explicit 안전성
Explicit VR Big Endian	`1.2.840.10008.1.2.2`	구 Mac 등 (거의 사용 안 함)
JPEG Baseline 8-bit Lossy	`1.2.840.10008.1.2.4.50`	일반 JPEG 손실
JPEG Baseline 12-bit Lossy	`1.2.840.10008.1.2.4.51`	12bit 의료영상용
JPEG Lossless	`1.2.840.10008.1.2.4.57`	JPEG 무손실
JPEG-LS Lossless ⭐	`1.2.840.10008.1.2.4.80`	의료영상에서 흔함
JPEG-LS Near-Lossless	`1.2.840.10008.1.2.4.81`	거의 무손실
JPEG 2000 Lossless ⭐	`1.2.840.10008.1.2.4.90`	최신, 권장
JPEG 2000 Lossy	`1.2.840.10008.1.2.4.91`	손실 압축
RLE Lossless	`1.2.840.10008.1.2.5`	Run-Length, 단순

4.3 핵심 규칙

✅ 모든 DICOM AE는 1.2.840.10008.1.2 (Implicit VR LE) 를 무조건 지원해야 함.

이게 안전망. 다른 압축 협상 다 실패해도 이걸로 fallback 하면 됨.

4.4 인코딩 (Abstract와 거의 동일)

┌──────┬──────────┬─────────┬─────────────────────┐
│ 0x40 │ reserved │ Length  │  UID string         │
│ 1byte│ 1 byte=0 │ 2 bytes │  L bytes            │
└──────┴──────────┴─────────┴─────────────────────┘

첫 바이트가 0x40 (Transfer Syntax)인 것만 다름.

4.5 ⚠️ 압축 함정 — 저자 사례

한 병원 US 장비가 영상을 압축 형식으로 저장 (디스크 용량 절약).
Archive 서버는 압축 미지원.
→ US가 영상 보내려 했을 때 → Transfer Syntax 불일치로 거부.

문제 진단:

US 기사가 자기도 모르게 압축 켬 → Transfer Syntax 바뀜
US 장비 펌웨어가 "압축 거부되면 압축 안 한 거로 fallback" 안 함 → 표준 위반

해결:

모든 AE는 거부당하면 Implicit VR LE로 fallback 해야 함
또는 Archive에서 그 압축 지원 추가

4.6 압축 옵션 함정

Transfer Syntax는 알고리즘 이름만 협상. 품질/비율 같은 파라미터는 협상 안 됨.
→ 받는 쪽은 "JPEG2000으로 압축됐다"만 알지 "품질 80%" 같은 건 모름.
→ 그래서 의료영상은 무손실 압축 (Lossless) 선호.

5. Presentation Context = Abstract + Transfer 묶음 ⭐⭐

여기가 핵심. 위 두 개념이 합쳐진다.

5.1 정의

Presentation Context = 1개의 Abstract Syntax + 여러 개의 Transfer Syntax 후보

┌─────────────────────────────────────────────────────────┐
│  Presentation Context (PrC)                              │
│  ├── Presentation Context ID (1, 3, 5, ... 홀수)         │
│  ├── Abstract Syntax: MR Image Storage                   │
│  └── Transfer Syntax 후보들:                              │
│      ├── 1.2.840.10008.1.2 (Implicit VR LE)              │
│      ├── 1.2.840.10008.1.2.4.80 (JPEG-LS Lossless)       │
│      └── 1.2.840.10008.1.2.4.91 (JPEG 2000 Lossy)        │
└─────────────────────────────────────────────────────────┘

비유: "이 일(Abstract)을 다음 언어들(Transfer) 중 어떤 걸로든 할 수 있어요" 라는 명함.

5.2 협상 과정

Calling AE → Called AE (요청)

여러 Presentation Context를 묶어서 보냄:

A-Associate-RQ
├── PrC ID=1: MR Storage / [Implicit LE, JPEG-LS, JPEG2000]
├── PrC ID=3: CT Storage / [Implicit LE]
├── PrC ID=5: Verification / [Implicit LE]
└── ...

Called AE → Calling AE (응답)

각 PrC에 대해 수락/거부 + 선택한 Transfer Syntax 1개

A-Associate-AC
├── PrC ID=1: ✅ Accept, Transfer Syntax = Implicit LE
├── PrC ID=3: ❌ Reject (reason 3: Abstract syntax not supported)
├── PrC ID=5: ✅ Accept, Transfer Syntax = Implicit LE
└── ...

→ PrC ID로 어떤 컨텍스트의 응답인지 매칭.

5.3 Acceptance Reason 코드

A-Associate-AC의 각 PrC 응답에 들어가는 "왜 수락/거부했나"

코드	의미
`0`	✅ Acceptance (성공)
`1`	❌ User-rejection
`2`	❌ No-reason (provider)
`3`	❌ Abstract syntax not supported
`4`	❌ Transfer syntaxes not supported

PACS 통신 디버깅의 진짜 핵심:
로그에서 PrC가 거부됐다면 reason 코드 먼저 확인.

3이면 → SOP Class 자체를 안 받는 거 (장비 호환성 문제)

4면 → SOP는 OK지만 압축 등 인코딩 형식이 안 맞는 거 (해결 가능)

5.4 실제 인코딩 — 두 가지 형식

A-Associate-RQ의 PrC: 첫 바이트 0x20. Abstract 1개 + Transfer 여러 개.

A-Associate-AC의 PrC: 첫 바이트 0x21. Abstract 없음. Transfer 1개만. PrC ID로 매칭.

→ AC에 Abstract Syntax 안 들어있어서 PrC ID 매칭이 유일한 방법. ID 잘못 맞추면 망함.

6. Application Context (대부분 무시)

A-Associate에 들어가지만 거의 안 봄.

표준 default: 1.2.840.10008.3.1.1.1
거의 모든 구현이 이 default 사용
이론상 "어떤 회사 소프트웨어인지" 식별 가능 — 사설 협상 트리거용
실무에서는 그냥 default 보내고 받는 쪽도 무시

⚠️ 가끔 악용: 일부 PACS가 "경쟁사 Application Context면 거부" 한다는 루머. 대부분 그냥 무시.

7. User Information — 작지만 까다로운 함정

A-Associate-RQ/AC에 들어가는 잡다한 추가 정보.

7.1 주요 subitem

Subitem	의미	기본값
Maximum PDU Length	PDU 최대 크기 (byte)	16384, 64KB 등
Implementation Class UID	구현 식별자	(벤더별)
Implementation Version Name	버전 문자열 (≤ 16자)	(벤더별)
Async Operations Window	비동기 큐 사이즈	1 (= 동기)
SCP/SCU Role Selection	역할 협상	RQ측=SCU 가정
Extended Negotiation	추가 협상 (relational query 등)	없음

7.2 ⚠️ 저자의 함정 사례 — 두 글자 때문에 하루 날림

CR ↔ Archive 연결이 안 됨. 하루 종일 디버깅.
원인: Archive의 Implementation Version Name이 18자 ("ArchiveVersion.123").
DICOM 표준상 최대 16자. CR이 그걸 엄격히 검사해서 통째로 거부.

교훈:

User Information의 모든 길이 제한 엄수
그래야 까다로운 벤더와도 호환

7.3 Maximum PDU Length

PDU(Protocol Data Unit) 한 번에 보낼 수 있는 최대 크기. 큰 영상은 여러 PDU로 쪼갬.

너무 작으면: 영상이 잘게 쪼개져 오버헤드↑
너무 크면: 메모리 부담, 네트워크 단편화

흔한 값: 16384 (16KB), 65536 (64KB), 131072 (128KB)

Orthanc/pynetdicom 기본값은 보통 16KB. 큰 영상 자주 주고받으면 늘려도 됨.

7.4 SCP/SCU Role Negotiation

기본 가정: RQ를 보낸 쪽 = SCU, 받는 쪽 = SCP.

예외: C-Get/C-Move 처럼 SCP가 SCU에게 거꾸로 C-Store 하는 경우. 이때 Role 명시 필요.

A-Associate-RQ
├── PrC: MR Storage
├── User Info:
│   └── SCP/SCU Role Selection: "나는 SCU 이자 SCP 역할 둘 다 함"

→ Calling AE가 "내가 보내준 영상을 받을 수도 있어요" 라고 알림.

8. PDU — Protocol Data Unit

Association 위에서 흐르는 7가지 메시지 단위.

PDU	1st Byte	역할
A-Associate-RQ	`0x01`	연결 요청
A-Associate-AC	`0x02`	연결 수락
A-Associate-RJ	`0x03`	연결 거부
P-Data-TF	`0x04`	실제 데이터 전송
A-Release-RQ	`0x05`	정상 종료 요청
A-Release-RP	`0x06`	정상 종료 응답
A-Abort	`0x07`	비정상 종료

8.1 전체 흐름도

Calling AE                    Called AE
   │                              │
   │  A-Associate-RQ (0x01)       │
   ─────────────────────────────→ │
   │                              │
   │       ┌────────────────────┐ │
   │       │ 협상 결과          │ │
   │       └────────────────────┘ │
   │                              │
   │  A-Associate-AC (0x02)       │
   ←───────────────────────────── │  ← 성공 시
   │                              │
   │      또는                    │
   │                              │
   │  A-Associate-RJ (0x03)       │
   ←───────────────────────────── │  ← 거부 시
   │                              │
   │  ─── 협상 성공한 경우 ───      │
   │                              │
   │  P-Data-TF (0x04) ↔  ↔  ↔   │
   ─────────────────────────────→ │  ← DIMSE 메시지들 흐름
   ←───────────────────────────── │
   │  ...                         │
   │                              │
   │  A-Release-RQ (0x05)         │
   ─────────────────────────────→ │
   │                              │
   │  A-Release-RP (0x06)         │
   ←───────────────────────────── │
   │                              │
   │  ─── 또는 비정상 종료 ───     │
   │                              │
   │  A-Abort (0x07)              │
   ─────────────────────────────→ │  (양방향 가능)

8.2 A-Associate-RQ 구조

┌────────────────────────────────────────────────────┐
│ PDU type = 0x01                                     │
│ Reserved (0x00)                                     │
│ Length (4 bytes)                                    │
│ Protocol version (2 bytes, = 0x0001)               │
│ Reserved (2 bytes)                                  │
│ Called AE Title (16 bytes, blank padded)            │
│ Calling AE Title (16 bytes, blank padded)           │
│ Reserved (32 bytes)                                 │
│                                                     │
│ ─── Variable items ─────────────────────────       │
│   Application Context Item                          │
│   Presentation Context Item(s) (여러 개 가능)        │
│   User Information Item                             │
└────────────────────────────────────────────────────┘

8.3 ⚠️ AE Title 16바이트 패딩

AE Title은 정확히 16바이트. 짧으면 공백(0x20) 으로 패딩.

"ORTHANC" → "ORTHANC         "  (앞 7자 + 공백 9개)

양쪽이 padding 처리 다르면 매칭 실패. 일부 PACS가 trailing space를 strip 안 하고 비교해서 거부하는 사례 있음. AE Title은 짧고 명확하게 (8자 이하 권장).

8.4 화이트리스트 검사

A-Associate-RQ 받자마자 Called AE가 하는 일:

# 의사코드
def on_associate_rq(rq):
    if rq.calling_ae_title not in self.whitelist:
        return A_Associate_RJ(reason="no reason given")  # 흔한 거부 사유
    ...

⚠️ 이게 4편 §2.4에서 본 "양방향 등록 함정" 의 정체. PACS의 whitelist에 AI 추론 앱 AE 등록 안 되면 무조건 거부.

9. A-Associate-RJ (거부)

A-Associate-RQ의 거부 응답. 단순 구조.

9.1 거부 메시지 필드

필드	값	의미
Result	`1`	Rejected-Permanent (영구)
	`2`	Rejected-Transient (일시)
Source	`1`	DICOM UL service-user
	`2`	DICOM UL service-provider (ACSE)
	`3`	DICOM UL service-provider (Presentation)
Reason	`1`	No reason given ← 가장 자주 봄
	`2`	Application context name not supported
	`3`	Calling AE Title not recognized
	`4-6`	(reserved)
	`7`	Called AE Title not recognized

9.2 "No reason given" 의 진실

DICOM 디버깅의 최대 적. 벤더가 정보 안 줘서 그런 거지 실제로는 명확한 이유가 있음. 가장 흔한 실제 원인

⭐ Calling AE Title이 whitelist에 없음
Abstract Syntax 미지원 (장비가 해당 SOP 모름)
Maximum PDU Length 협상 실패
Implementation Version Name 형식 위반
방화벽이 association 막음

저자 권고:
"No reason given" 받으면 자체 디버깅하지 말고 양쪽 벤더를 한자리에 모아라. 단독으로 X 벤더에게 물으면 Y 탓 하고, Y에게 물으면 X 탓 함.

10. P-Data-TF — 실제 데이터 전송

Association이 성공한 후 흐르는 데이터 PDU.

10.1 구조

┌──────────────────────────────────────────────────┐
│ PDU type = 0x04                                   │
│ Reserved (0x00)                                   │
│ PDU Length                                        │
│                                                   │
│ ─── PDV (Protocol Data Value) items ───          │
│   PDV Length (4 bytes)                            │
│   Presentation Context ID (1 byte)                │
│   MCH (Message Control Header, 1 byte) ↓          │
│   PDV Data (DIMSE message fragment)               │
│   ...                                             │
└──────────────────────────────────────────────────┘

10.2 MCH (Message Control Header) — 1바이트의 비밀

  Bit 7 6 5 4 3 2 1 0
            │   │ │ │
            │   │ │ └─ Command(1) or Data(0)?
            │   │ └─── Last fragment(1) or not(0)?
            └─── reserved

bit 0: 1이면 Command 객체 (group 0000), 0이면 Data 객체
bit 1: 1이면 이게 마지막 fragment, 0이면 더 옴

→ DIMSE 메시지를 PDU 크기에 맞게 쪼개고, 받는 쪽에서 다시 조립.

10.3 흐름 예시: C-Store 한 번

C-Store-Rq (Command Object, 작음)
  → 1개 PDV (MCH=0x03 = command + last)

영상 데이터 (큰 IOD, 10MB)
  → 여러 PDV로 쪼개짐:
    PDV 1: MCH=0x00 (data + 계속)
    PDV 2: MCH=0x00 (data + 계속)
    ...
    PDV N: MCH=0x02 (data + last)

→ C-Store 완료 → C-Store-Rsp 응답

10.4 PrC ID 매칭

각 PDV에는 Presentation Context ID 가 붙어 있음.
→ 받는 쪽이 "이 PDV는 Implicit LE로 해석해야 하나, JPEG 압축으로 해석해야 하나" 를 PrC ID로 결정.

11. Association 종료

11.1 정상 종료 — A-Release

SCU                            SCP
 │                              │
 │  A-Release-RQ (0x05)         │  ← 작업 끝, 끊자
 ────────────────────────────→  │
 │                              │
 │  A-Release-RP (0x06)         │  ← OK
 ←────────────────────────────  │
 │                              │
 ─── TCP 연결 종료 ───

11.2 비정상 종료 — A-Abort

오류 상황에서 즉시 끊기:

잘못된 PDU 받음
타임아웃
사용자가 강제 종료

A-Abort (0x07) → 한쪽이 일방적으로 보냄 → TCP close

11.3 Timeout 종료

상대가 응답 없으면 일정 시간 후 자동 종료. 보통 30-60초 설정.

너무 짧으면 느린 네트워크에서 끊김. 너무 길면 죽은 연결 감지 늦음.

11.4 ⚠️ 동시 Association 수 라이선스

일부 PACS 벤더는 동시 Association 수 라이선스로 판매. 10개, 50개 등.
→ 모든 Association을 반드시 A-Release로 정상 종료 해야 슬롯 회수됨.
→ 안 그러면 슬롯이 누적되어 새 Association 받을 수 없게 됨.

12. Association 디버깅 — 실전 가이드 ⭐⭐⭐

저자의 노하우 + 실무 베스트 프랙티스.

12.1 디버깅 순서

1. C-Echo (ping)
   ├── 성공 → AE Title, IP, Port, whitelist 모두 OK → 다음 단계로
   └── 실패 → 12.2 로

2. C-Store SCU (실제 영상 전송)
   ├── 성공 → 완료
   └── 실패 → Abstract/Transfer Syntax 협상 문제 → 12.3 로

3. C-Find / C-Move (검색/가져오기)
   └── ...

12.2 C-Echo 실패 트러블슈팅

증상	확인
TCP timeout	1) 네트워크 케이블/방화벽 2) IP/Port 오타 3) SCP 데몬이 안 돔
`Association rejected (no reason)`	1) Calling AE Title이 PACS whitelist에 있나? ⭐ 2) Called AE Title 오타 3) Implementation Version Name 16자 초과
`Abstract syntax not supported`	Verification SOP SCP 미지원 (Conformance 확인)
즉시 disconnect	일부 PACS는 whitelist 미등록 시 그냥 끊음

12.3 C-Store 실패 트러블슈팅

증상	확인
`Abstract syntax not supported`	SOP Class UID 확인. CT 영상 보내는데 PACS가 MR Storage만 받는 등.
`Transfer syntaxes not supported`	압축 형식 미지원. Implicit LE로 fallback 시도.
`Out of resources`	PACS 디스크/메모리 부족. 관리자에게
`Cannot understand`	IOD 형식 위반. Type 1 필드 누락 등
일부 영상만 실패	Patient ID 빈 값, 손상된 픽셀 등 개별 데이터 문제

12.4 로그 분석 핵심 키워드

Orthanc 로그

W [Orthanc Plugin]   Connection failed (rc = 0xc0001000, ...)
I [Orthanc Plugin]   ASSOCIATE-RQ from CT_SCANNER (10.0.0.5:11112)
I [Orthanc Plugin]   ASSOCIATE-AC sent
I [Orthanc Plugin]   P-DATA-TF: 1 PDV, ...
W [Orthanc Plugin]   Refusing presentation context (abstract syntax not supported)

pynetdicom 로그

import logging
logging.basicConfig(level=logging.DEBUG)
# 또는
from pynetdicom import debug_logger
debug_logger()

→ 모든 PDU/PDV 바이트 단위로 출력. RQ/AC 협상 내용 다 보임.

12.5 패킷 캡처 (Wireshark)

진짜 안 풀리는 경우 마지막 수단:

tshark -i any -f "port 4242" -w dicom.pcap

Wireshark는 DICOM dissector 내장. 모든 PDU/PDV/Abstract/Transfer Syntax를 트리로 보여줌. AE Title의 trailing space, PDU length 오류 같은 것도 한 번에 드러남.

12.6 ⚠️ 책의 황금률

DICOM 협상 실패는 거의 항상 양쪽 벤더 책임. 한쪽만 잡지 말고 둘을 마주 앉혀라.

명확한 로그/에러 표시 없는 PACS는 사지 말 것. 디버깅 불가.

Conformance Statement를 신뢰하되 검증하라. "지원한다"고 적힌 게 실제로는 미구현인 경우 흔함.

13. Point-to-Point의 한계

DICOM의 근본적 약점 하나 더.

13.1 정적 등록 강제

모든 AE는 통신할 상대의 (AET, IP, Port)를 미리 등록 해야 함.

변경되면 모든 곳을 다시 등록해야 함.
모바일/원격 접근 어려움.

13.2 저자의 허리케인 카트리나 사례

카트리나 후 정전 → 라우터 재부팅 → IP 주소가 공장 default로 리셋
→ PACS 서버 IP 바뀜 → 모든 AE가 PACS를 못 찾음 → 전체 마비
→ IP 복원하니 즉시 정상화

→ TCP/IP는 살아있는데 DICOM의 정적 등록 때문에 전체 시스템이 죽는 패러독스.

13.3 C-Move vs C-Get 와 연결

5편 §4.2에서 본 방화벽 함정과 같은 뿌리:

C-Move는 정적 등록 필수 (별도 association 열어야 하니까)
C-Get은 동적 가능 (같은 association으로 응답)

13.4 워크어라운드

방식	설명
VPN	가상 사설망으로 정적 IP처럼 보이게
DICOMweb (WADO/STOW/QIDO)	HTTP REST 기반, 정적 등록 불필요
Orthanc/dcm4chee gateway	외부에서 들어온 요청을 내부 PACS로 중계

현대 PACS는 DICOMweb 지원이 점점 표준화 중. DICOMweb은 책에 없지만 별도 학습할 가치 있음 (PS3.18).

14. AI 추론 앱 관점 — Orthanc 사용 시 ⭐

저수준 PDU는 Orthanc가 다 처리해줌. 하지만 설정과 디버깅에서 위 개념들이 그대로 등장.

14.1 Orthanc 설정 예시

// orthanc.json
{
  "DicomAet": "ORTHANC",
  "DicomPort": 4242,
  "DicomCheckCalledAet": false,
  "DicomCheckModalityHost": false,

  "DicomModalities": {
    "HOSPITAL_PACS": {
      "AET": "HOSPITAL_PACS",
      "Host": "10.0.0.50",
      "Port": 11112,
      "Manufacturer": "Generic",
      "AllowEcho": true,
      "AllowFind": true,
      "AllowGet": false,
      "AllowMove": true,
      "AllowStore": true
    }
  },

  // ⭐ Transfer Syntax 협상 제어
  "AcceptedTransferSyntaxes": [
    "1.2.840.10008.1.*"
  ],

  // ⭐ Abstract Syntax 협상 제어
  "DefaultEncoding": "Latin1",
  "MaximumPduLength": 16384,

  // ⭐ Whitelist
  "DicomAlwaysAllowEcho": true,
  "DicomAlwaysAllowStore": true
}

→ 위 설정의 거의 모든 필드가 이번 글에서 다룬 개념과 직접 대응

DicomAet = 우리 AI 추론 앱의 Calling AE Title
AET/Host/Port = 원격 PACS의 (AE Title, IP, Port) 사전 등록
AcceptedTransferSyntaxes = 협상 시 받아들일 Transfer Syntax UID 목록
MaximumPduLength = User Information의 Max PDU Length
DicomAlwaysAllowStore = whitelist 검사 우회 (개발 환경에서)

14.2 디버깅 명령

# C-Echo 테스트
curl -X POST http://orthanc:8042/modalities/HOSPITAL_PACS/echo

# 협상 로그 보기 (Orthanc verbose 모드)
Orthanc.exe --verbose orthanc.json
# 또는
Orthanc.exe --trace-dicom orthanc.json   # ← Association/PDU 레벨 로그

14.3 흔한 시나리오와 매핑

증상	원인 (이번 글의 개념)	해결
Orthanc에서 PACS로 C-Echo 실패	Whitelist 미등록	PACS에 ORTHANC AE 등록 요청
C-Store 시 `RejectedPresentationContext`	Transfer Syntax 미협상	`AcceptedTransferSyntaxes`에 압축 추가
C-Move 했는데 영상 안 옴	Move Destination 등록 안 됨	PACS에 우리 AE를 destination으로 등록
Implementation 16자 오류	User Info 길이 위반	Orthanc 버전 업데이트 또는 벤더 문의
큰 영상 전송 중단	Max PDU Length	`MaximumPduLength` 늘림 (e.g., 65536)

15. 핵심 정리

개념	한 줄
Association	DICOM Upper Layer 통신 단위. TCP 위 핸드셰이크
Act 1/2/3	Establishment / Data Transfer / Termination
Abstract Syntax	"어떤 SOP" — UID 형식. 협상 불가, 매칭만
Transfer Syntax	"어떤 인코딩" — Endian/Implicit/Explicit/압축. 여러 후보 협상
기본 Transfer Syntax	`1.2.840.10008.1.2` (Implicit VR LE) — 무조건 지원 필수
Presentation Context	Abstract 1개 + Transfer 후보 N개. PrC ID로 추적
A-Associate-RQ/AC	협상 요청/수락 PDU
A-Associate-RJ	거부. "no reason given"이 흔함 → 실제는 whitelist 문제 다수
A-Abort	비정상 즉시 종료
A-Release-RQ/RP	정상 종료 (라이선스 슬롯 회수)
P-Data-TF	실제 데이터 PDU. PDV로 쪼갬. MCH 1바이트로 command/data + last 표시
User Information	Max PDU, Version Name(16자!), Role Selection 등
PrC Reject Reason 3	Abstract Syntax 미지원 (SOP 자체 문제)
PrC Reject Reason 4	Transfer Syntax 미지원 (인코딩 문제, fallback 가능)
AE Title	16바이트, 공백 패딩. 짧고 명확하게
디버깅 순서	C-Echo → C-Store → 로그 → Wireshark
점-대-점 한계	정적 등록 강제. DICOMweb이 대안

16. 다음 글에서 다룰 것

DICOM 통신의 모든 기본기가 완성됐다.

마지막 7편은 운영 환경에서의 실전

7편: DICOM 파일/보안 + Orthanc 실전

DICOM File 포맷 — DICM 매직 헤더, Preamble, Meta Information
DICOMDIR — DVD/CD/USB 미디어 인덱스
익명화 (Anonymization) — HIPAA, 환자 데이터 보호 ⭐
암호화 — Secure DICOM, 디지털 서명
Orthanc 실전 통합 시나리오 — AI 추론 앱 전체 파이프라인
DICOMweb 맛보기 — WADO-RS, STOW-RS, QIDO-RS

참고

Pianykh, O.S. Digital Imaging and Communications in Medicine (DICOM). Springer, 2008.
공식 표준:
- PS3.7 (Message Exchange) — DIMSE
- PS3.8 (Network Communication Support) — 이번 글의 핵심: PDU, Association protocol
도구:
- Wireshark — DICOM dissector 내장. 패킷 단위 분석.
- pynetdicom — Python 구현 + DEBUG 로깅
- Orthanc — --trace-dicom 옵션으로 PDU 레벨 로그
- DCMTK dcmnet — storescu, findscu, echoscu 등 CLI 도구

[DICOM] 영상을 가져오는 방법 — C-Move, C-Get, Modality Worklist

odod00 — Wed, 10 Jun 2026 13:58:42 +0900

Oleg Pianykh, Digital Imaging and Communications in Medicine (DICOM) (Springer, 2008) 정리 5편
참고 챕터: Ch 7.5 – 7.10, Ch 8.1–8.3

C-Find로 "PACS에 뭐가 있는지" 알아냈으니, 이제 "그 영상을 실제로 가져오는" 방법을 다룰 차례.

이번 편의 핵심:

C-Get / C-Move — 영상 가져오기의 두 가지 방식
Modality Worklist (MWL) — RIS에서 일정 받기
DICOM 현장 용어 (ping/push/pull)
Conformance Statement의 진짜 의미 — SCU/SCP 역할 매칭
보너스: Storage Commitment, Secondary Capture, Structured Report

여기까지 다 보면 PACS 통신의 모든 기본기가 완성된다.

1. 왜 C-Find만으론 부족한가?

C-Find로 "Study UID 목록"은 얻을 수 있지만, 실제 픽셀은 못 받는다. C-Find는 메타데이터만 응답함.

C-Find → "John Smith의 MR Study UID = 1.2.840.xxx 가 PACS에 있어요"
        ↓
        그래서? 영상 자체는?

→ 영상을 실제로 가져오는 두 가지 방식이 있다:

C-Get — 단순. 같은 연결 위에서 영상 받아옴
C-Move — 복잡. PACS가 별도 연결로 보내줌

두 방식은 동일한 SOP Class 패밀리지만 동작이 완전히 다르다.

2. C-Get — 단순한 영상 가져오기

2.1 동작 원리

C-Get은 C-Find + C-Store를 한 묶음으로 처리한다. 같은 association(연결) 안에서 영상이 돌아온다.

SCU (워크스테이션)          SCP (PACS)
  │                            │
  │  C-Get-Rq (Study UID)      │
  ──────────────────────────→
  │                            │
  │  C-Store-Rq (영상 1)        │  ← SCP가 SCU에게 거꾸로 보냄!
  ←──────────────────────────
  │                            │
  │  C-Store-Rsp                │
  ──────────────────────────→
  │  C-Store-Rq (영상 2)        │
  ←──────────────────────────
  │  ...                        │
  │                            │
  │  C-Get-Rsp Status=0xFF00    │  ← 진행 상황 보고
  │  (suboperation 카운트 포함)  │
  ←──────────────────────────
  │  ...                        │
  │  C-Get-Rsp Status=0x0000    │  ← 완료
  ←──────────────────────────

⚠️ 핵심 포인트: 같은 association 위에서 SCU가 일시적으로 C-Store SCP 역할을 한다. 즉 영상을 받으려면 SCU도 C-Store SCP를 구현해야 함.

2.2 C-Get SOP Class UID

Query Root	SOP Class UID
Patient Root Q/R Get	`1.2.840.10008.5.1.4.1.2.1.3`
Study Root Q/R Get ⭐	`1.2.840.10008.5.1.4.1.2.2.3`
Patient-Study Root Q/R Get	`1.2.840.10008.5.1.4.1.2.3.3` (Retired)

SOP Class UID 패턴 기억하기:

C-Find: ...1.2.x.1

C-Get: ...1.2.x.3

C-Move: ...1.2.x.2

(x는 root 종류: 1=Patient, 2=Study, 3=Patient-Study)

2.3 C-Get IOD — 자유도가 낮다

C-Get은 C-Find와 달리 정확한 키만 받음. 와일드카드/range 매칭 안 됨.

(0008, 0052) Retrieve Level = "STUDY"
(0010, 0020) Patient ID = "12345"            ← 정확값
(0020, 000D) Study Instance UID = "1.2.84..." ← 정확값

→ 그래서 항상 C-Find를 먼저 해서 키를 얻고, 그 키로 C-Get 호출 하는 패턴이 표준.

사용자 검색어
   ↓ ("Smith 환자의 지난달 MR")
C-Find (wildcard, range 가능)
   ↓
Study UID 목록 받음
   ↓
C-Get (UID 정확값만)
   ↓
영상 다운로드

2.4 C-Get-Rsp의 진행률 필드

C-Get은 진행 상황을 상세히 보고:

Tag	의미
`(0000, 1020)`	Remaining Suboperations (남은 개수)
`(0000, 1021)`	Completed (성공한 개수)
`(0000, 1022)`	Failed (실패한 개수)
`(0000, 1023)`	Warning (경고로 끝난 개수)

→ PACS UI의 "다운로드 진행률 ████░░ 60%" 가 이걸로 만들어짐.

3. C-Move — 영상을 다른 곳으로 보내기

3.1 동작 원리 — 3주체

C-Move의 핵심 차이: 영상을 SCU가 아닌 제3의 AE로 보낼 수 있다.

   Workstation 1                Archive (PACS)              Workstation 2
   (C-Move SCU)                 (C-Move SCP)                (C-Store SCP)
       │                            │                            │
       │  C-Move-Rq                 │                            │
       │  Move Destination = WS2    │                            │
       ──────────────────────────→  │                            │
       │                            │                            │
       │                            │  새 association 열기        │
       │                            ──────────────────────────→  │
       │                            │                            │
       │                            │  C-Store-Rq (영상)         │
       │                            ──────────────────────────→  │
       │                            │  C-Store-Rsp                │
       │                            ←──────────────────────────  │
       │                            │                            │
       │  C-Move-Rsp Status=0xFF00  │                            │
       │  (진행률)                  │                            │
       ←──────────────────────────  │                            │
       │  ...                       │                            │
       │  C-Move-Rsp Status=0x0000  │                            │
       ←──────────────────────────  │                            │

3.2 C-Move SOP Class UID

Query Root	SOP Class UID
Patient Root Q/R Move	`1.2.840.10008.5.1.4.1.2.1.2`
Study Root Q/R Move ⭐	`1.2.840.10008.5.1.4.1.2.2.2`
Patient-Study Root Q/R Move	`1.2.840.10008.5.1.4.1.2.3.2` (Retired)

3.3 C-Move-Rq의 핵심 필드: Move Destination

(0000, 0600) Move Destination = "WORKSTATION_2"   ← AE Title

⚠️ 목적지는 AE Title만 적는다. IP/Port는 안 적음.
→ SCP가 자기 AE 목록에서 그 AE Title을 찾아서 IP/Port를 알아내야 한다.

3.4 ⚠️ 가장 큰 함정: SCP의 AE 등록부

C-Move SCP는 목적지 AE의 IP/Port를 미리 알고 있어야 한다.

❌ 시나리오:
AI 추론 앱 (= WS2) 가 PACS에 처음 연결
→ AI 추론 앱이 C-Find로 영상 검색 → 됨
→ AI 추론 앱이 C-Move로 자기 자신에게 보내달라고 요청
→ PACS: "AIAPP_AE가 누구야?" → ❌ 거부 (Unknown destination)

✅ 해결: PACS 관리자에게 AI 추론 앱의 (AE Title + IP + Port) 등록 요청 필수.

3.5 C-Move = C-Get 으로 쓰기

흔한 패턴: 자기 자신을 destination으로 지정

WS1                Archive             WS1 (= 자기 자신)
 │                   │                   │
 │ C-Move-Rq         │                   │
 │ Dest = WS1        │                   │
 ──────────────→    │                   │
 │                   │  C-Store-Rq      │
 │                   ──────────────→
 │                   │                   │

→ 효과상 C-Get과 동일. 그런데 굳이 별도 association을 여는 비효율.

3.6 실무 비밀

저자 의견:
대부분의 PACS가 C-Move를 사용하지만, 실제로는 자기 자신을 destination으로 지정해서 C-Get처럼 쓰는 경우가 대부분.

이유: C-Move SCP를 단순화하고, 진짜 3-주체 시나리오는 큰 PACS 내부 클러스터링에서만 쓰임.

4. C-Move vs C-Get 비교 ⭐

PACS 통신 모듈 개발 시 반드시 알아야 할 비교.

4.1 비교 표

	C-Get	C-Move
Association 수	1개 (반전 사용)	2개 (별도)
목적지 지정	불필요 (자기)	Move Destination 필수
사전 등록	SCP가 SCU만 알면 됨	SCP가 목적지 AE 사전 등록 필수
방화벽 친화성	✅ Outbound만	❌ Inbound 연결 필요
동적 환경	✅ 좋음	❌ 정적 환경에 적합
텔레라디올로지	✅ 적합	❌ 어려움
큰 PACS 내부 클러스터링	❌	✅
표준 위상	"Archaic" 취급	권장

4.2 방화벽 함정

회사/병원 방화벽 환경에서 흔히 발생:

회사 방화벽: outbound 허용, inbound 차단 (일반적 설정)

C-Echo (SCU → SCP): ✅ outbound, OK
C-Find (SCU → SCP): ✅ outbound, OK
C-Get  (SCU ↔ SCP, 같은 association): ✅ outbound로 시작, OK
C-Move (SCU → SCP, 그 다음 SCP → SCU의 새 연결): ❌ 두 번째가 inbound!

→ C-Move를 위해 방화벽 구멍을 뚫어야 함. 보안팀이 싫어함. VPN이 더 안전.

4.3 저자의 결론

"C-Move inside, C-Get outside"

큰 PACS 내부 (한 통제된 환경 안): C-Move

외부 시스템 (텔레라디올로지, 모바일): C-Get

4.4 AI 추론 앱 적용

AI 추론 앱은 병원 내부 시스템이라 C-Move 환경에 있을 가능성이 높다:

시나리오 1: 병원 내부 (가장 흔함)
  의사 워크스테이션이 PACS에 "이 환자 영상을 AIAPP_AE로 보내" 요청
  → PACS가 AI 추론 앱에 C-Store
  → AI 추론 앱은 단순히 "C-Store SCP"만 구현하면 됨

시나리오 2: AI 추론 앱이 직접 트리거
  AI 추론 앱이 C-Find로 영상 찾기 → C-Move로 자기에게 보내달라 요청
  → PACS에 AI 추론 앱 등록 필수
  → AI 추론 앱은 "C-Move SCU" + "C-Store SCP" 둘 다 구현

개발 우선순위:

C-Store SCP (영상 받기) — 무조건 필요

C-Echo SCU/SCP — 연결 테스트

C-Store SCU (결과 보내기) — 추론 후 PACS로 송신

C-Find SCU + C-Move SCU — AI 추론 앱이 능동적 검색하려면

5. Modality Worklist (MWL)

5.1 무엇인가?

MWL = "오늘 찍을 환자 명단을 modality에 미리 알려주는 서비스"

CT 기사가 출근하면 CT 화면에 오늘 검사할 환자 목록이 떠 있어야 한다:

환자 이름, ID, 생년월일, 성별
임신 여부, 알러지
검사 종류, 시작 시간
의뢰의, 판독의

이 데이터를 수동 입력하면 오타 폭격 → 큰 사고 원인. MWL로 자동 조회.

5.2 전체 데이터 흐름

[RIS / EMR]
    │  (환자 예약/오더)
    │  HL7 메시지
    ↓
[DICOM Broker / MWL Server]
    │  (HL7 → DICOM 변환)
    ↓
[MWL SCP]
    │
    │  C-Find-Rq (Modality=CT, AET=CT1)
    ←─────────────────────────────────  [CT Scanner = MWL SCU]
    │
    │  C-Find-Rsp (환자 목록)
    ─────────────────────────────────→
                                          ↓
                                       기사 화면에 환자 목록 표시
                                       기사가 환자 선택 → 자동 정보 입력

RIS는 보통 HL7 표준을 쓰고 DICOM이 아님. 그래서 중간에 변환 broker가 필요. (HL7은 14편급 주제, 이 책 Ch 14)

5.3 MWL SOP Class UID

1.2.840.10008.5.1.4.31

5.4 MWL DIMSE = C-Find DIMSE 그대로

"The MWL DIMSE is nothing more than our good old friend C-Find DIMSE"

MWL은 C-Find와 메시지 구조가 동일. 차이는 SOP Class UID와 IOD 내용뿐.

5.5 MWL IOD 핵심 필드

Tag	내용
`(0010, 0010)`	Patient Name
`(0010, 0020)`	Patient ID
`(0010, 0030)`	Birth Date
`(0010, 0040)`	Sex
`(0010, 21C0)`	Pregnancy Status
`(0008, 0050)`	Accession Number (RIS 오더 번호)
`(0032, 1032)`	Requesting Physician
`(0008, 0090)`	Referring Physician
`(0040, 0100)`	Scheduled Procedure Step Sequence (SQ)
→ `(0040, 0001)`	Scheduled Station AET (어느 modality에서 찍을지)
→ `(0040, 0002)`	Scheduled Start Date
→ `(0040, 0003)`	Scheduled Start Time
→ `(0008, 0060)`	Modality
→ `(0040, 0006)`	Scheduled Performing Physician

5.6 ⚠️ 흔한 함정

Modality가 요구하는 attribute가 위 목록보다 많을 수 있음. 누락되면 modality가 MWL 응답 자체를 거부.

→ 항상 modality의 Conformance Statement 확인:

"이 modality는 어떤 필드를 필수로 요구하나?"
"지원하지 않는 필드가 들어오면 어떻게 처리하나?"

5.7 MWL이 AI 추론 앱과 직접 관련 있나?

대부분 직접 안 씀. MWL은 modality(촬영 장비) → MWL 서버 사이의 일이고, AI 추론 앱은 영상이 다 찍힌 뒤 처리하는 단계.

예외: AI 추론 앱이 워크리스트 UI 를 제공해서 "오늘 분석할 환자 목록"을 보여주려면 MWL이나 그에 상응하는 정보를 RIS/PACS에서 받아야 함.

6. 현장 용어 — DICOM Ping / Push / Pull

PACS 엔지니어들은 표준 용어 안 씀. 다음 매핑 기억할 것:

현장 용어	표준
DICOM Ping	C-Echo (Verification SOP)
DICOM Push	C-Store (영상을 다른 AE로 보내기)
DICOM Pull	C-Move 또는 C-Get (영상을 다른 AE에서 가져오기)

⚠️ "Test connection" 버튼 함정:
PACS UI의 "Test Connection" 버튼이 진짜 C-Echo인지, 단순 TCP ping인지 확인할 것.
TCP ping만 통과시키고 C-Echo 안 되는 PACS = 진짜 연결 안 되는 PACS.

6.1 push vs pull 작동 차이

Push (C-Store): 자동화에 적합. modality → archive 흐름.
Pull (C-Move/C-Get): 사람이 골라서. 워크스테이션에서 옛 검사 보기.

→ "Pull은 사실상 smart push" — 결국 영상은 C-Store로 옴.

7. SCU/SCP 역할 매칭 — Conformance Statement의 진짜 의미

7.1 SCU/SCP는 클라이언트/서버가 아니다

흔한 오해: "SCP = 서버, SCU = 클라이언트". 틀림.

SCU/SCP는 특정 SOP 클래스에 대한 역할일 뿐.

Digital Archive의 진짜 모습:
  - CT Storage SCP (CT 받음)
  - CT Storage SCU (다른 곳으로 CT 전송)         ← 클라이언트 역할도 함!
  - Study Root Q/R Find SCP (검색 받음)
  - Study Root Q/R Move SCP (검색 후 보내기)
  - Storage Commitment SCP
  - ...

→ 같은 AE가 같은 SOP에 대해 SCU + SCP를 동시에 할 수도 있음.

7.2 Conformance Statement = SOP × Role 매트릭스

PACS 벤더가 주는 Conformance Statement는 결국 이런 표:

SOP	SCU	SCP
Verification	✅	✅
CT Image Storage	✅	✅
MR Image Storage	✅	✅
US Image Storage	❌	✅
Secondary Capture Storage	❌	✅
Study Root Q/R Find	❌	✅
Study Root Q/R Move	❌	✅
Patient Root Q/R Find	❌	❌
Modality Worklist	✅	✅
...

→ 두 AE가 통신하려면 한쪽이 SCU, 다른 쪽이 SCP를 같은 SOP에 대해 지원 해야 함.

7.3 ⚠️ 흔한 함정들

저자가 꼽은 사고 사례:

Verification SCP 미지원
→ 그 장비로 C-Echo가 안 됨. 디버깅 불가능.
MR Storage SCP만 지원, CT Storage SCP 미지원
→ 같은 archive인데 CT는 못 받음.
Q/R Find SCU만 있고 SCP 없음
→ 그 워크스테이션을 다른 곳에서 검색할 수 없음.
이미지 압축(Transfer Syntax) 미지원
→ 텔레라디올로지에서 압축 보낼 수가 없음.
저자의 황당 사례:
→ CR 장비가 "archive를 printer로 등록하라"고 요구. 즉 archive를 Print SCP로 인식하게 해야 동작.

7.4 PACS 모듈 개발 시 Conformance 체크리스트

PACS 벤더와 협의 시작 전 받아야 할 정보:

☐ Verification SOP (양방향)
☐ 받을 영상 SOP Class UID (CT/MR/US/...) - 어느 게 SCP인가?
☐ 보낼 결과 SOP Class UID (SC/SR) - 어느 게 SCP인가?
☐ Q/R Find/Move 지원 여부 + Root (Patient or Study)
☐ Transfer Syntax 지원 목록 (Implicit/Explicit, 압축)
☐ AI 추론 앱 AE를 destination으로 등록 가능한지
☐ 사설 Tag 처리 정책
☐ Storage Commitment 사용 여부
☐ Secondary Capture / Structured Report 지원 여부
☐ 최대 Association 수
☐ 권장 Timeout 값
☐ 에러 코드 (Status) 해석 문서

8. 보너스 — Beyond Basic SOP

AI 추론 앱 통신 모듈에서 추가로 알면 좋은 SOP들 (Ch 8).

8.1 Storage Commitment SOP

"진짜로 저장했어?" 를 확인하는 SOP.

1. AI 추론 앱 → PACS: C-Store (영상)
2. PACS: 받음 (C-Store-Rsp Status=0x0000)
   ↳ 하지만 진짜 영구 저장한 건지? 메모리에만 있고 곧 날아갈 수도?
3. AI 추론 앱 → PACS: Storage Commitment Request
4. PACS: "응, 영구 저장했어" 또는 "아니, 못 했어"

⚠️ 저자 경고:
Storage Commitment는 DICOM 프로토콜일 뿐, 실제 저장 보장은 운영 문제.
PACS 관리자가 디스크 비우려고 영상 삭제하면 어떤 SOP도 못 막음.

AI 추론 앱은 일반적으로 Storage Commitment 안 써도 됨. PACS 벤더가 요구하면 그때 구현.

8.2 Secondary Capture (SC) ⭐⭐

AI 추론 앱에서 가장 중요한 SOP.

SC = "modality에서 직접 찍은 영상이 아닌 영상" 을 DICOM으로 저장하는 형식.

용도:

필름 스캔
화면 캡처
AI 추론 결과 (segmentation 결과 등) ← AI 추론 앱 용도!
3D 재구성 결과

SC SOP Class UID: 1.2.840.10008.5.1.4.1.1.7

8.3 ⚠️ SC의 흔한 함정 — Modality 라벨링

저자 예시:

CT perfusion 분석 후 컬러맵 생성
→ 원본 CT study에 추가하고 싶음
→ Modality를 "CT"로 라벨링?
   ❌ CT IOD 요구사항 불만족 (Hounsfield 스케일, monochrome 등)
   → CT 처리 함수가 에러
→ Modality를 "SC"로 라벨링?
   ❌ 단순한 PACS가 CT study 전송 시 SC 빠뜨림

해결: AI 추론 앱은 SC IOD로 만들되, Series 단위로 별도 생성. Study UID는 원본과 동일하게 유지 (이미 전편에서 다룸).

8.4 Structured Report (SR)

텍스트 + 영상 참조 + 측정값 을 한 객체에 담는 SOP.

AI 추론 앱의 추론 결과를 SR로 표현 가능:

"PI-RADS score: 4"
"Lesion location: peripheral zone, left mid"
"Lesion volume: 1.2 mL"
- 해당 lesion이 보이는 영상 참조 (SOP Instance UID)

SOP	UID
Basic Text SR	`1.2.840.10008.5.1.4.1.1.88.11`
Enhanced SR	`1.2.840.10008.5.1.4.1.1.88.22`
Comprehensive SR	`1.2.840.10008.5.1.4.1.1.88.33`

SR은 검색 가능. SC 이미지는 이미지일 뿐이라 텍스트 검색 불가.
워크플로우에 SR을 적용하면 "PI-RADS 4 이상 환자 모두 찾기" 같은 쿼리 가능.

AI 추론 앱 출력 전략 옵션:

SC + 결과 텍스트 burn-in (단순, 모든 PACS 지원)
SC + SR (이상적, PACS가 SR 지원할 때)
DICOM SEG (segmentation 전용 SOP, 최신 PACS)

PACS 벤더의 SR/SEG 지원 여부를 Conformance에서 확인.

9. AI 추론 앱 영상 수신 파이프라인 (완성)

이제 전체 그림이 보인다.

9.1 시나리오 A: PACS가 AI 추론 앱에 push

┌──────────────────────────────────────────────────────────────────┐
│  의사: "이 환자 AI 분석 돌려" 버튼 클릭                            │
│  PACS UI → 내부 워크플로우                                         │
└──────────────────────────────────────────────────────────────────┘
                              │
                              ▼
   [PACS] ──── C-Store (MR Image Storage SOP) ───→ [AI 추론 앱]
                                                          │
                                                          │ 영상 누적
                                                          │ (한 시리즈 30장)
                                                          ▼
                                                   [추론 트리거]
                                                          │ AI 모델
                                                          ▼
                                                   [Segmentation 결과]
                                                          │
                                                          ▼
                              ┌───────────────────────────┴────────┐
                              ▼                                    ▼
                  [SC Image 생성]                       [Structured Report 생성]
                  (overlay된 영상)                       (PI-RADS score 등)
                              │                                    │
                              └────────────┬───────────────────────┘
                                           ▼
                  [AI 추론 앱] ── C-Store ──→ [PACS]
                                           (Patient/Study UID 원본 유지,
                                            Series/SOP UID 새로 생성)
                                           │
                                           ▼
                              ┌──────────────────────────┐
                              │  PACS UI에서 원본 옆에     │
                              │  "AI 결과" 시리즈 추가됨    │
                              └──────────────────────────┘

9.2 시나리오 B: AI 추론 앱이 능동적으로 pull

[AI 추론 앱 UI] "환자 검색"
        │
        ▼
[AI 추론 앱] ── C-Find (Study Root) ──→ [PACS]
                                          │
                                          │ Patient + Modality + Date
                                          │ 조건으로 검색
        ←── C-Find-Rsp (Study UID 목록) ──
        │
        │ 사용자가 Study 선택
        ▼
[AI 추론 앱] ── C-Move ──→ [PACS]
              Dest=AIAPP_AE
                                          │
                                          │ PACS가 별도 association 열기
                                          ▼
[AI 추론 앱] ←── C-Store (영상들) ── [PACS]
        │
        ▼
   (이후 추론 → 결과 송신은 시나리오 A와 동일)

구현 필요 SOP 역할 (시나리오 A+B 모두):

Role	SOP
SCU	Verification, C-Find, C-Move, C-Store (결과 송신)
SCP	Verification, C-Store (영상 수신)

9.3 Orthanc로 구현 시

Orthanc가 위 모든 SOP를 다 구현해줌. 우리는 HTTP REST로 조작:

import requests

# 1) PACS 등록 (Orthanc 설정)
# orthanc.json:
# "DicomModalities": {
#   "PACS": ["PACS_AE", "192.168.1.10", 104]
# }

# 2) C-Echo
r = requests.post("http://orthanc:8042/modalities/PACS/echo")

# 3) C-Find
r = requests.post(
    "http://orthanc:8042/modalities/PACS/query",
    json={"Level": "Study",
          "Query": {"PatientID": "12345",
                    "StudyDate": "20260601-",
                    "ModalitiesInStudy": "MR"}}
)
query_id = r.json()["ID"]

# 4) 결과 조회 → Study UID들 얻기
studies = requests.get(
    f"http://orthanc:8042/queries/{query_id}/answers"
).json()

# 5) C-Move (AI 추론 앱 = Orthanc 자기 자신에게)
r = requests.post(
    f"http://orthanc:8042/queries/{query_id}/retrieve",
    data="ORTHANC"   # Orthanc 자기 AE Title
)

# 6) 영상 도착 후 webhook으로 추론 트리거 가능
# orthanc.json:
# "LuaScripts": ["./on_store.lua"]

→ 저수준 DICOM 메시지는 Orthanc가 다 처리. 우리는 비즈니스 로직만.

10. 핵심 정리

개념	한 줄
C-Get	단일 association, SCP가 SCU에게 C-Store. 단순. 방화벽 친화
C-Move	별도 association, 제3 AE 가능. 정적 환경 권장. 방화벽 함정
C-Move Dest	AE Title만 적음. SCP가 IP/Port 미리 알아야 함
C-Get IOD	정확값만. Wildcard 안 됨. → C-Find로 키 먼저 얻음
저자 결론	"C-Move inside, C-Get outside"
MWL	C-Find DIMSE 그대로. RIS에서 환자 일정 자동 조회. SOP UID = `...5.1.4.31`
DICOM Ping/Push/Pull	C-Echo / C-Store / C-Move(Get) 의 현장 용어
SCU/SCP	클라이언트/서버 아님. SOP별 역할. 같은 AE가 둘 다 가능
Conformance Statement	SOP × Role 매트릭스. PACS 통신의 정답지
Storage Commitment	영구 저장 보장. 운영 문제. 보통 안 씀
Secondary Capture	AI 결과 영상 저장에 표준. SOP UID = `...1.4.1.1.7`
Structured Report	텍스트 + 측정값 + 영상 참조. 검색 가능. 권장 출력 형식
AI 추론 앱 필수 SOP	Verification (양), C-Store SCP (영상 받기), C-Store SCU (결과 송신)

11. 다음 글에서 다룰 것

여기까지 DICOM 응용 메시지 (DIMSE) 의 핵심을 다 봤다. 하지만 우리는 한 가지를 얼버무리고 넘어왔다:

"두 AE가 통신하려면 먼저 Association 을 맺어야 한다"

이 Association이 어떻게 협상되는지, Transfer Syntax, Abstract Syntax, Presentation Context, PDU 가 뭔지 — DICOM 통신 디버깅의 80%가 일어나는 곳.

6편: DICOM Association — 통신을 떠받치는 인프라

TCP 연결 → DICOM Association 협상 과정
Abstract Syntax (어떤 SOP) ↔ Transfer Syntax (어떻게 인코딩) 협상
Presentation Context
A-Associate-RQ / AC / RJ
PDU (Protocol Data Unit)
실제 Orthanc 로그 해석

여기를 알아야 "Association rejected", "Presentation context not accepted" 같은 흔한 에러를 직접 디버깅할 수 있다.

참고

Pianykh, O.S. Digital Imaging and Communications in Medicine (DICOM). Springer, 2008.
공식 표준 매핑:
- PS3.4 (Service Class Specifications) — Q/R, MWL 정의
- PS3.7 (Message Exchange) — DIMSE 메시지 구조
라이브러리:
- pynetdicom — Python으로 C-Move/C-Get/C-Store/MWL 직접 구현 시
- Orthanc REST API — 추상화된 인터페이스
DICOM SR 깊이 학습:
- Clunie, D. DICOM Structured Reporting (2000) — 저자 추천

[DICOM] DICOM 통신의 시작 — C-Echo, C-Store, C-Find

odod00 — Wed, 10 Jun 2026 13:40:03 +0900

Oleg Pianykh, Digital Imaging and Communications in Medicine (DICOM) (Springer, 2008) 정리 4편
참고 챕터: Ch 7.1 – 7.4

이번 글부터는 "그 데이터가 어떻게 네트워크를 타고 흘러가는가" 의 세계로 진입이라고 볼 수 있다.

이번 편의 목표는

AE Title / IP / Port — 네트워크에서 DICOM 단위를 식별하는 법
SCU ↔ SCP 모델, DIMSE 프로토콜
가장 기본 3개 서비스: C-Echo, C-Store, C-Find
진짜 PACS 통신 모듈을 짜기 위한 토대

여기까지 알면 Orthanc 로그에서 일어나는 일을 80% 해석할 수 있다.

1. DICOM Networking의 위치

DICOM은 새로운 네트워크 프로토콜이 아니다. TCP/IP 위에서 도는 응용 계층 프로토콜이다.

┌─────────────────────────────────────┐
│    DIMSE (DICOM 응용 메시지)         │  ← 7-9편에서 다룰 것
├─────────────────────────────────────┤
│    DICOM Upper Layer (UL) Protocol   │  ← Association (6편)
├─────────────────────────────────────┤
│    TCP                                │
├─────────────────────────────────────┤
│    IP                                 │
├─────────────────────────────────────┤
│    Ethernet / WiFi                    │
└─────────────────────────────────────┘

HTTP가 80번 포트, SMTP가 25번 처럼
DICOM 기본 포트는 104번 (옛날에 NEMA가 받아둠)

흥미로운 역사: DICOM은 인터넷이 보급되기 전 부터 설계됐다. 옛 PS3.9는 "Point-to-Point 케이블 통신"용이었음. 지금은 폐기되고 TCP/IP만 사용.

2. AE / AE Title / IP / Port

2.1 AE (Application Entity)란?

⚠️ 헷갈리기 쉬운 포인트:
AE는 컴퓨터(장비)가 아니라 그 위에서 도는 "DICOM 애플리케이션" 이다.

한 PC에 여러 AE가 돌 수 있다.

PC 1대 (IP: 192.168.1.10)
  ├─ AE "ORTHANC_MAIN"     포트 4242
  ├─ AE "AI_INFERENCE"      포트 11112
  └─ AE "BACKUP_SCP"        포트 11113

→ 같은 IP라도 AE Title + Port 조합으로 구분.

2.2 AE를 식별하는 3종 세트

PACS 네트워크에서 어떤 AE와 통신하려면 3가지 정보가 필요하다:

항목	설명	예시
AE Title (AET)	DICOM 상의 이름 (`AE` VR, 16자 이내)	`ORTHANC`
IP Address	네트워크 주소	`192.168.1.10`
Port Number	TCP 포트	`4242` (또는 104)

비유

컴퓨터 이름 = 거리 이름

포트 번호 = 집 번호

AE Title = 거기 사는 사람 이름

2.3 AE Title 명명 규칙

표준은 느슨하지만 실무 컨벤션:

✅ 대문자, 영숫자, _ 만 사용 (PACSSERVER, CT_WORKSTATION1)
❌ 공백, 한글, 특수문자, 소문자 ❌ (벤더마다 대소문자 구분이 다름)
✅ 역할/위치를 의미있게 (MR1FLOOR, RADIOLOGY_ARCHIVE)
❌ 의미 없는 이름 (AE1, XYZ) ❌

2.4 ⚠️ 양방향 등록 함정

표준상: AE X가 AE Y로 보내려면 X가 Y의 (IP/Port/AET)을 알면 됨.

현실: 많은 PACS가 양방향 등록 을 요구한다. Y도 X를 알아야 함.

❌ 문제 상황 예시
PACS 서버 Y의 화이트리스트에 AI 추론 앱 (X)이 등록 안 됨
→ AI 추론 앱이 보낸 C-Store를 PACS가 거부 ("Unknown AE")

PACS 모듈 개발 시 체크리스트:

AI 추론 앱의 AE 정보를 PACS 벤더에게 알려서 등록 요청

PACS의 AE/IP/Port를 AI 추론 앱 설정에 넣기

C-Echo로 양방향 verify (둘 다 응답해야 함)

2.5 포트 번호 베스트 프랙티스

✅ 104 (DICOM 공식 포트)
✅ 11112 (pynetdicom 기본값, Orthanc 기본 DICOM port와 다름)
✅ 4242 (Orthanc DICOM 기본값)
✅ 10000번대 (충돌 적음)

❌ 80 (HTTP가 잡음)
❌ 22 (SSH)
❌ 25 (SMTP)

Orthanc의 흔한 포트 구성 (참고):

4242: DICOM (DIMSE) 포트
8042: HTTP REST API / 웹 UI
둘 다 따로 설정함

3. SCU ↔ SCP 모델

DICOM의 모든 통신은 클라이언트–서버 구조다.

역할	의미
SCU (Service Class User)	서비스를 요청하는 쪽 (클라이언트)
SCP (Service Class Provider)	서비스를 제공하는 쪽 (서버)

   "이미지 저장해줘"
SCU ─────────────────→ SCP
              ← ─────  "저장 완료"

3.1 같은 AE가 양쪽 다 할 수 있다

한 AE가 여러 서비스에서 SCU, SCP 둘 다 가능. 흔한 패턴:

AE	C-Echo	C-Store	C-Find	C-Move
CT 장비	SCP	SCU	–	–
PACS 서버	SCU/SCP	SCU/SCP	SCP	SCP
판독 워크스테이션	SCU	–	SCU	SCU
AI 추론 앱	SCU/SCP	SCU/SCP	SCU	SCU

PACS 모듈 개발 시:
AI 추론 앱은 보통 C-Move SCU(영상 가져오기) + C-Store SCP(가져온 영상 받기) + C-Store SCU(결과 다시 보내기) 의 세 역할을 동시에 함.

4. DIMSE — DICOM의 응용 메시지 프로토콜

DIMSE = DICOM Message Service Elements

AE끼리 주고받는 메시지의 표준 형식.

4.1 메시지 구조 — Command + (선택적) Data

┌─────────────────────────────┐
│   Command Object             │  ← 항상 있음 (group 0000)
│   - 어떤 서비스인지            │
│   - Message ID                │
│   - Status                    │
├─────────────────────────────┤
│   Data Object (선택)          │  ← 있을 때도, 없을 때도
│   - 실제 IOD (영상, 환자 정보 등)│
└─────────────────────────────┘

핵심 필드: (0000, 0800) Data Set Type

0x0101 = NULL (Data 없음, Command만)
그 외 = Data가 뒤따라옴

4.2 DIMSE-C vs DIMSE-N

	다루는 IOD	예시
DIMSE-C (Composite)	Composite IOD (영상 등)	C-Echo, C-Store, C-Find, C-Move, C-Get
DIMSE-N (Normalized)	Normalized IOD	N-Set, N-Get, N-Action, ... (Print, MPPS 등)

→ 거의 모든 영상 작업은 DIMSE-C. PACS 통신 시 99%가 이쪽.

4.3 Rq / Rsp 패턴

요청(Request)과 응답(Response)이 짝지어 다님:

C-Store-Rq (요청) ↔ C-Store-Rsp (응답)
Command Field 값으로 구분:
- 0x0001 = C-Store-Rq
- 0x8001 = C-Store-Rsp (Rsp는 항상 8___ 패턴)

4.4 Message ID — 요청/응답 짝맞추기

바쁜 PACS는 초당 수십 개의 DIMSE를 받음. Message ID 로 짝을 맞춤:

SCU                                SCP
 │                                  │
 │ C-Store-Rq  Msg ID = 42         │
 ───────────────────────────────→
 │                                  │
 │  Msg ID Being Responded To = 42  │
 │  C-Store-Rsp                     │
 ←───────────────────────────────

(0000, 0110) Message ID (요청) → (0000, 0120) Message ID Being Responded To (응답)

5. C-Echo — DICOM의 ping

5.1 왜 필요한가?

연결 확인은 일반 ping으로도 되지 않나? 안 된다. 이유는

ICMP ping은 TCP/IP만 확인 — DICOM 소프트웨어 안 돌고 있어도 성공
AE Title, Port가 잘못돼도 ping은 성공
방화벽이 DICOM 포트만 막아도 ping은 성공

C-Echo만이 "이 AE가 진짜 DICOM 말 할 줄 안다" 를 증명 한다.

5.2 C-Echo 동작

SCU                                 SCP
 │                                   │
 │  C-Echo-Rq                        │
 │  (0000,0002) UID=1.2.840.10008.1.1│
 │  (0000,0100) Command=0x0030       │
 │  (0000,0110) MessageID=42         │
 │  (0000,0800) Data Set Type=0x0101 │
 ───────────────────────────────→
 │                                   │
 │  C-Echo-Rsp                       │
 │  (0000,0100) Command=0x8030       │
 │  (0000,0120) Resp to=42           │
 │  (0000,0900) Status=0x0000        │ ← 0 = 성공
 ←───────────────────────────────

구현해야 할 건 단 하나 — Message ID 생성/매칭. 나머지는 다 고정값.

5.3 C-Echo-Rq 바이트 덤프

실제 네트워크에는 68 byte가 흘러간다 (Implicit VR + Little Endian):

Byte #	값	의미
1–8	`00 00 00 00 04 00 00 00`	`(0000,0000)` Group Length 태그 + length=4
9–12	`38 00 00 00`	Group Length 값 = 56 (이후 바이트 수)
13–20	`00 00 02 00 12 00 00 00`	`(0000,0002)` + length=18
21–38	`"1.2.840.10008.1.1\0"`	SOP Class UID (18 byte)
39–48	`00 00 00 01 02 00 00 00 30 00`	`(0000,0100)` + length=2 + value=`0x0030`
49–56	`00 00 10 01 02 00 00 00`	`(0000,0110)` + length=2
57–58	(생성한 ID)	Message ID
59–66	`00 00 00 08 02 00 00 00`	`(0000,0800)` + length=2
67–68	`01 01`	Data Set Type = `0x0101` (NULL)

→ 정말 단순함. wireshark로 캡처하면 이대로 보임.

5.4 C-Echo 실패 시 트러블슈팅

증상	원인
Timeout	1. 네트워크 케이블/방화벽
	2. 잘못된 IP/Port
	3. SCP가 안 도는 중
`0x0211` Unrecognized Operation	SCP가 Verification SOP 미지원 (벤더 문제)
`Association rejected`	AE Title이 화이트리스트에 없음

PACS 통신 디버깅의 첫 단계는 무조건 C-Echo. Orthanc UI에 "Test Echo" 버튼 있음. 거기서 시작.

5.5 ⚠️ Verification SCP 미지원 = 위험 신호

저자가 겪은 실제 사례:
한 CR 장비 벤더가 Verification SCP를 일부러 끄고 "보안" 이라고 주장.
→ C-Echo는 데이터 전송하지 않음. 보안과 무관. 그냥 게으름.
Verification SCP 안 되는 장비는 사지 말 것 (저자 추천).

6. SOP — Service-Object Pair 의 정확한 의미

SOP = DIMSE 서비스 + IOD 를 한 묶음으로 정의한 것.

SOP = "이 IOD에 이 서비스를 적용한다" 의 표준화된 단위

예시:

Verification SOP = C-Echo + (IOD 없음)
CT Image Storage SOP = C-Store + CT Image IOD
MR Image Storage SOP = C-Store + MR Image IOD
Study Root Query/Retrieve SOP = C-Find/C-Move + Patient-Study 키 IOD

각 SOP는 고유 UID 를 가짐:

1.2.840.10008.1.1 = Verification SOP Class UID
1.2.840.10008.5.1.4.1.1.2 = CT Image Storage SOP Class UID

Conformance Statement는 SOP Class UID 목록의 형태로 작성 된다.
"우리 장비는 이런 SOP들을 지원하고, 어떤 건 SCU, 어떤 건 SCP다" 식으로.

7. C-Store — 영상 저장

가장 자주 쓰이는 서비스. 영상을 한 AE에서 다른 AE로 보낸다.

7.1 IOD 타입별 SOP Class UID

Modality / Type	SOP Class UID
CR Image	`1.2.840.10008.5.1.4.1.1.1`
CT Image	`1.2.840.10008.5.1.4.1.1.2`
Enhanced CT	`1.2.840.10008.5.1.4.1.1.2.1`
MR Image ⭐	`1.2.840.10008.5.1.4.1.1.4`
Enhanced MR	`1.2.840.10008.5.1.4.1.1.4.1`
US Single Frame	`1.2.840.10008.5.1.4.1.1.6.1`
US Multiframe (cine)	`1.2.840.10008.5.1.4.1.1.3.1`
NM (Nuclear Medicine)	`1.2.840.10008.5.1.4.1.1.20`
PET	`1.2.840.10008.5.1.4.1.1.128`
Secondary Capture ⭐	`1.2.840.10008.5.1.4.1.1.7`
Basic Text SR	`1.2.840.10008.5.1.4.1.1.88.11`
Enhanced SR	`1.2.840.10008.5.1.4.1.1.88.22`
Comprehensive SR	`1.2.840.10008.5.1.4.1.1.88.33`

AI 추론 앱 입장:

수신: MR Image Storage SOP (...1.4) — MR 받음

송신: Secondary Capture (...1.7) 또는 Enhanced SR — 추론 결과 보냄

7.2 C-Store 한 번 = 영상 1개

핵심 규칙: 한 C-Store는 1개의 IOD instance만 보낸다.

CT 시리즈 2000장 → C-Store 2000번 호출

예외: Multi-frame IOD (US cine, multi-frame CT 등) 는 한 객체 안에 여러 frame 가능 → 1번 호출.
오버헤드는 좀 있지만 각 영상의 성공/실패를 개별 추적 할 수 있음.

7.3 C-Store-Rq 핵심 필드

Tag	내용	비고
`(0000,0002)`	Affected SOP Class UID	위 표의 UID
`(0000,0100)`	Command Field = `0x0001`	C-Store-Rq
`(0000,0110)`	Message ID
`(0000,0700)`	Priority	low/med/high (대부분 무시)
`(0000,0800)`	Data Set Type	`≠ 0x0101` (데이터 있음)
`(0000,1000)`	Affected SOP Instance UID	이미지의 UID
`(0000,1030)`	Move Originator AET	C-Move로 호출됐을 때만
`(0000,1031)`	Move Originator Message ID	위와 같음

→ 그 뒤에 실제 영상 IOD (Data Object) 가 붙어서 전송됨.

7.4 C-Store-Rsp Status 값

Status	의미
`0x0000`	성공
`0xFF00`	진행 중
`0xA700`, `0xA900`, `0xC000~`	에러 (벤더별 코드, Conformance 참조)

7.5 ⚠️ C-Store 실무 함정

저자 사례:

한 CR 장비가 Patient ID 빈 영상 1건의 C-Store가 reject되자 그 이후 모든 전송을 중단. 며칠 만에 로컬 디스크 가득 차서 환자 못 받음.

PACS 모듈 개발 원칙:

개별 실패가 전체 큐를 중단시키면 안 됨

실패 영상은 별도 큐로 빼고 나머지는 계속 진행

재시도는 backoff 로 (즉시 재시도 ❌)

모든 실패를 로그에 남김 (Status 코드, SOP Instance UID 포함)

8. C-Find — 영상 검색

PACS에서 "무엇이 있는지" 질의하는 서비스.

8.1 Query Root 3종 (사실상 2종)

SOP Class	UID	비고
Patient Root Q/R Find	`1.2.840.10008.5.1.4.1.2.1.1`	Patient부터
Study Root Q/R Find ⭐	`1.2.840.10008.5.1.4.1.2.2.1`	Study부터 (가장 흔함)
Patient-Study Root	`1.2.840.10008.5.1.4.1.2.3.1`	Retired (사용 금지)

현대 PACS의 99%는 Study Root. 환자 단위가 아니라 검사 단위로 워크플로우가 돌기 때문.

8.2 Query Level — 4계층 어디서 검색?

3편의 Patient→Study→Series→Image 4계층. C-Find는 이 중 어느 레벨에서 검색할지 명시:

(0008, 0052) Query/Retrieve Level    CS
값: "PATIENT" | "STUDY" | "SERIES" | "IMAGE"

→ 보통 단계별 drill-down:

STUDY 레벨에서 환자/날짜로 검색 → Study UID 목록
그 Study UID + SERIES 레벨로 검색 → Series UID 목록
그 Series UID + IMAGE 레벨로 검색 → SOP Instance UID 목록

8.3 매칭 방식 4가지

방식	예시	설명
Wildcard	`Smit*`	`*` = 임의 문자열, `?` = 한 글자
List	`Smith\Graham`	`\` = OR
Universal	`""` (빈값)	모든 값 매칭 (필드를 받아오고 싶을 때)
Range	`20060101-20070101`	`-` = 범위 (날짜/시간용)

8.4 C-Find IOD — 자주 쓰는 필드

Tag	이름	예시	매칭
`(0008,0052)`	Query Level	`STUDY`	필수
`(0010,0010)`	Patient Name	`Smit\Grah`	Wildcard + List
`(0010,0020)`	Patient ID	`12345`	보통 정확 매칭
`(0008,0020)`	Study Date	`20260101-20260601`	Range
`(0008,0030)`	Study Time	`080000-180000`	Range
`(0008,0050)`	Accession Number	`ABC789`	정확 매칭 (RIS 연동)
`(0020,000D)`	Study Instance UID		정확 매칭
`(0008,0061)`	Modalities in Study	`MR\CT`	List
`(0008,1030)`	Study Description	`chest`	Wildcard
`(0010,0030)`	Birth Date	`19560101-19860101`	Range

⚠️ Universal Matching의 미묘함:

빈 값으로 보냄 → "이 필드 매칭하고 응답에 값 받고 싶음"

필드 자체를 안 보냄 → "필요 없음"

둘이 다름! 응답에서 받고 싶은 필드는 빈 값이라도 반드시 포함 해야 함.

8.5 ⚠️ Modality 함정

대부분 사람들이 "Modality는 Study의 속성"으로 생각하지만:

(0008, 0060) Modality → 실제로는 Series 레벨 속성
(0008, 0061) Modalities in Study → Study 레벨 (옵션, 지원 안 하는 PACS 많음)

→ Study Root에서 modality로 필터하고 싶으면:

Modalities in Study 시도 (안 될 수 있음)
안 되면 Study 받아서 → Series 레벨 추가 쿼리

8.6 C-Find Response — Multi-response 패턴

C-Find는 응답이 여러 번 온다.

SCU                                     SCP
 │                                       │
 │  C-Find-Rq                            │
 ────────────────────────────────────→
 │                                       │
 │  C-Find-Rsp  Status=0xFF00 (pending)  │
 │  + IOD #1                             │
 ←────────────────────────────────────
 │  C-Find-Rsp  Status=0xFF00 (pending)  │
 │  + IOD #2                             │
 ←────────────────────────────────────
 │  ...                                  │
 │                                       │
 │  C-Find-Rsp  Status=0x0000 (done)     │
 │  (마지막, IOD 없음)                    │
 ←────────────────────────────────────

매치마다 Status=0xFF00 (pending) + IOD 1개
마지막에 Status=0x0000 (success) + IOD 없음
매치 0건이면 첫 응답이 곧장 success
에러 시 다른 Status 코드

8.7 C-Cancel — 검색 중단

너무 광범위한 쿼리(e.g., wildcard도 안 주고 검색)는 영원히 안 끝남.

C-Cancel-Find (Command = 0x0FFF) 로 중단
(0000, 0120) 에 중단할 메시지 ID 적음

PACS 모듈 개발 시: Find 함수에는 timeout + max_results 가드 필수. 50,000개 결과 받다가 메모리 터지는 사고 흔함.

8.8 C-Find 에러 흔한 원인

AE 미등록 — SCU AET가 SCP 화이트리스트에 없음 (제일 흔함)
Hierarchical 규칙 위반 — Series 검색하면서 Study UID 안 줌
Query Root 미스매치 — Study Root만 지원하는데 Patient Root SOP로 요청
C-Find SCP 미지원 — 일부 modality는 C-Store SCU만 함 (Find 안 받음)

9. AI 추론 앱 관점 — 실전 시나리오

9.1 시나리오: 추론 큐 처리

1. 의사가 PACS UI에서 "AI 분석" 버튼 클릭
   → PACS가 AI 추론 앱으로 C-Store (MR 시리즈)

2. AI 추론 앱 (= C-Store SCP) 영상 수신
   → 로컬 디스크 저장 → AI 모델 추론 시작

3. 추론 완료 → Secondary Capture IOD 생성
   - Patient ID: 원본 유지
   - Study UID: 원본 유지       ← 같은 검사 하위로 묶이게
   - Series UID: 새로 생성
   - SOP Class UID: 1.2.840.10008.5.1.4.1.1.7 (SC)

4. AI 추론 앱 (= C-Store SCU)
   → PACS로 C-Store
   → PACS UI에서 원본 옆에 "AI 결과" 시리즈로 보임

9.2 시나리오: AI 추론 앱이 직접 PACS 쿼리

1. AI 추론 앱 UI에서 환자 검색
   → PACS로 C-Find (Study Root)
   - Query Level: STUDY
   - Patient ID: "12345"
   - Modality: "MR"
   - Study Date: "20260601-"

2. PACS가 C-Find-Rsp 여러 번 응답
   → AI 추론 앱 UI에 Study 목록 표시

3. 사용자가 특정 Study 선택
   → PACS로 C-Move (5편에서)

9.3 Orthanc 사용 시 추상화 레벨

Orthanc를 쓰면 위 작업이 HTTP REST 호출로 간략화:

# C-Find (Study Root) → REST
import requests

r = requests.post(
    "http://orthanc:8042/modalities/PACS/query",
    json={"Level": "Study",
          "Query": {"PatientID": "12345",
                    "ModalitiesInStudy": "MR"}}
)
query_id = r.json()["ID"]

# 결과 조회
studies = requests.get(
    f"http://orthanc:8042/queries/{query_id}/answers"
).json()

→ Orthanc가 내부적으로 진짜 DICOM C-Find를 PACS에 보냄.
하지만 디버깅하려면 결국 위 표들을 알아야 한다. Orthanc 로그에 똑같이 나옴.

10. 핵심 정리

개념	한 줄
AE	DICOM 애플리케이션 (≠ 컴퓨터). AET + IP + Port 3종 세트로 식별
SCU/SCP	클라이언트/서버. 한 AE가 양쪽 다 가능
DIMSE	DICOM 응용 메시지 프로토콜. Command + (옵션) Data
DIMSE-C / DIMSE-N	Composite IOD용 / Normalized IOD용. 거의 다 C 씀
Rq / Rsp	요청/응답. Message ID로 짝맞춤. Rsp는 Command Field `0x8___`
C-Echo	DICOM ping. 연결 확인. 데이터 없음. 디버깅의 시작
SOP	DIMSE + IOD 묶음. 각 SOP는 고유 UID
C-Store	영상 저장. IOD 종류마다 다른 SOP Class UID
C-Find	영상 검색. Study Root (`...2.2.1`) 가 표준
Query Level	PATIENT / STUDY / SERIES / IMAGE
매칭 방식	Wildcard, List, Universal, Range
Multi-response	C-Find는 매치마다 응답. 마지막은 Status=`0x0000`

11. 다음 글에서 다룰 것

C-Find로 "무엇이 있는지" 알아냈으니, 이제 실제로 가져와야 한다.

5편: C-Move, C-Get, Modality Worklist

C-Move — 가장 흔한 영상 가져오기 (C-Store를 trigger)
C-Get — 직접 가져오기 (덜 쓰이지만 단순함)
C-Move vs C-Get 비교
Modality Worklist (MWL) — RIS에서 환자 일정 받기
AI 추론 앱 영상 수신 파이프라인 완성

여기까지가 DICOM 통신 서비스의 본진. 6편 Association이 그 통신을 떠받치는 인프라.

참고

Pianykh, O.S. Digital Imaging and Communications in Medicine (DICOM). Springer, 2008.
공식 표준 매핑:
- PS3.4 (Service Class Specifications) — Verification, Storage, Q/R 정의
- PS3.7 (Message Exchange) — DIMSE 메시지 구조, Command Field 코드
라이브러리:
- Python: pynetdicom (DICOM 네트워크), pydicom (DICOM 파일)
- 구현 시 거의 표준
Orthanc 관련:
- https://orthanc.uclouvain.be/book/users/rest.html (REST API 매핑)

[DICOM] Patient/Study/Series/Image 4계층 + IOD — DICOM 정보 모델의 완성

odod00 — Tue, 2 Jun 2026 17:23:51 +0900

Oleg Pianykh, Digital Imaging and Communications in Medicine (DICOM) (Springer, 2008) 정리 3편
참고 챕터: Ch 5.6 – 5.7

1. Patient-Study-Series-Image — DICOM의 4계층 정보 모델

DICOM은 모든 영상 데이터를 4단계 계층으로 조직한다.

Patient (환자)
  └── Study (검사) — 1명에게 여러 검사 가능
       └── Series (시리즈) — 1검사에 여러 시리즈
            └── Image (영상) — 1시리즈에 여러 영상 (= Instance)

1.1 실제 임상 워크플로우 매핑

  환자 John Smith (Patient)
   │
   ├──   2026-05-26 검사 (Study 1)
   │    ├──   MR T2W axial (Series 1)
   │    │    ├── slice 1
   │    │    ├── slice 2
   │    │    └── ... slice 30
   │    ├──   MR DWI (Series 2)
   │    └──   MR ADC (Series 3)
   │
   └──   2026-08-15 추적검사 (Study 2)
        └──   MR T2W axial (Series 1)
             └── ...

1 환자 → 평생 동안 여러 번 병원 옴 (Study가 쌓임)
1 검사 → 한 번의 방문에서 여러 modality, 여러 sequence를 찍을 수 있음 (Series로 나뉨)
1 시리즈 → 같은 protocol로 찍은 영상 묶음 (slice들이 Image로)

1.2 각 계층의 식별자

계층	식별자	Tag	VR
Patient	Patient ID	`(0010, 0020)`	`LO`
Study	Study Instance UID	`(0020, 000D)`	`UI`
Series	Series Instance UID	`(0020, 000E)`	`UI`
Image	SOP Instance UID	`(0008, 0018)`	`UI`

Patient ID만 LO(Long String)이고 나머지는 다 UI(globally unique identifier). 왜? Patient ID는 사람이 손으로 입력하기 때문에 자유 형식이 필요. 나머지는 장비가 자동 생성하니까 엄격한 UID 형식 사용.

1.3 핵심 규칙

같은 UID = 같은 객체
Study UID가 같으면 같은 검사. Series UID가 같으면 같은 시리즈.
이게 깨지면 PACS가 데이터를 못 묶음.

2. Patient ID의 현실적 문제들 ★

이름 대신 Patient ID를 쓰는 이유는 명확하다.

이름은 오타 가능 (John Smith vs Jhon Smith)
결혼/개명으로 바뀜
영문 시스템에 한글/일본어 입력 어려움
프라이버시 위반

하지만 Patient ID에도 문제가 많다.

2.1 표준화 부재

전 세계 통일 Patient ID 체계가 없다. 각 병원이 자기 정책으로 부여:

사회보장번호 사용 (재방문 시 일관)
단순 일련번호 (이 병원에서만 유효)
환자 이름 자체를 ID로 사용 (의미 없음)
검사 종류/판독의에 따라 123.ForDrSmith, 123.Followup 등으로 변형

2.2 실제 사고 사례

저자가 경험한 케이스들:

Case 1: "W/I" 환자
한 병원이 ID 없는 환자를 모두 "W/I" (Without ID)로 등록 → DICOM은 다 같은 환자로 봄 → 수백 명이 한 명으로 merge.

Case 2: 3자리 ID 한계
ID를 3자리(000–999)로만 부여하던 영상센터 → 1000명 넘어가니 ID 재사용 → 서로 다른 환자가 merge.

Case 3: 쌍둥이 자매
같은 의사에게 같은 발목 문제로 동시 방문. 성이 20자 길이 한국식 풀네임이라 first name이 잘림. 의사도 누구 영상인지 구분 불가.

2.3 PACS의 방어 로직

좋은 PACS는 Patient ID 하나만 믿지 않는다. 추가 검증 로직:

# 의사코드
def is_same_patient(record_a, record_b):
    if record_a.patient_id == record_b.patient_id:
        # ID 같다고 끝이 아니라 cross-check
        if (record_a.name == record_b.name and
            record_a.birth_date == record_b.birth_date and
            record_a.sex == record_b.sex):
            return True
        else:
            flag_for_human_review()  # 같은 ID인데 다른 사람?

    # ID 다르지만 다른 정보 일치 시
    if (record_a.name == record_b.name and
        record_a.birth_date == record_b.birth_date):
        suggest_merge()

→ patient merge / split 기능이 모든 PACS의 필수.

⚠️ 자동 merge/split은 금지. 사람이 확인해야 함. 잘못 merge하면 진단 정보 오염.

2.4 AI 추론 앱 입장에서

AI 추론 앱은 PACS에서 영상을 받아 처리할 때:

[PACS] ──C-Move──> [AI 앱] ──추론──> [Orthanc] ──C-Store──> [PACS]
                       │
                       └── Patient ID + Name + Birth Date 다 보고
                           "동일 환자" 검증 후 처리

받은 영상의 Patient ID만 믿지 말고 cross-check
추론 결과를 PACS에 보낼 때 원본 Study/Patient UID 그대로 유지 (그래야 PACS가 같은 검사에 묶어줌)

3. Study/Series/Image UID의 문제들

Patient ID와 달리 이 셋은 장비가 자동 생성한다. 그래서 비교적 안정적이지만 함정도 있음.

3.1 흔한 사고: Series UID 깨짐

CT 한 시리즈가 2,000장인데, 어떤 기술적 이유로 각 슬라이스마다 Series UID가 다르게 생성되는 경우 발생.

❌ 잘못된 경우:
slice 1 → Series UID: 1.2.3.4.1
slice 2 → Series UID: 1.2.3.4.2   ← 달라짐!
slice 3 → Series UID: 1.2.3.4.3
...

→ PACS가 2,000개의 "1장짜리 시리즈"로 인식
→ 3D 재구성, 뷰어에서 슬라이스 묶음 안 됨

해결책은 거의 없음. modality(장비) 쪽에서 고쳐야 한다. PACS는 Series UID만 보고 묶기 때문에 사후 복구가 어려움.
(Patient ID와 달리 Series에는 merge 기능이 없는 경우가 많음)

3.2 UID는 인스턴스마다 달라야 한다

영상을 조금이라도 수정하면 (crop, rotate, lossy compression):

임상 정보는 같아 보여도
SOP Instance UID 새로 부여 필요 (2편 10.2 참조)

원본:        SOP UID = ...1.1
JPEG 압축:   SOP UID = ...1.2  ← 새 UID!
크롭됨:     SOP UID = ...1.3   ← 또 새 UID!

PACS에 똑같이 생긴 영상이 두 개 따로 저장돼 있다면 → 둘 중 하나가 수정본일 가능성.

3.3 Secondary Capture의 함정

필름을 스캔하거나 외부 영상을 DICOM으로 변환할 때:

디지타이저는 "이 영상들이 같은 환자/검사/시리즈인지" 모름
사용자가 수동으로 Study/Series UID 부여 해야 함
→ 이 기능이 부실한 SC 장비를 사면 영상이 다 흩어짐

AI 추론 앱이 secondary capture(추론 결과 영상)를 만들 때도 같은 문제. 원본 Study UID를 유지하고, Series UID는 새로 생성해야 같은 검사 하위에 묶임.

4. Hierarchical vs Relational Query

DICOM은 데이터 조회 방식을 두 가지 정의한다.

4.1 Hierarchical Query (계층적, 필수)

위에서부터 차근차근 내려가야 한다.

"John Smith의 지난달 CT 영상 찾기"

1. Patient Level:  Patient Name="Smith*" → Patient ID 획득
2. Study Level:    그 Patient ID + StudyDate=last month → Study UID 획득
3. Series Level:   그 Study UID + Modality="CT" → Series UID 획득
4. Image Level:    그 Series UID → Image UID 목록

모든 DICOM 장비 필수 지원. 간단하고 효율적이지만 4번 왕복.

4.2 Relational Query (관계형, 선택)

상위 정보 없이 바로 검색:

"Modality=CT AND Date=last month AND Series Description='axial'"
→ 바로 매칭되는 Series UID 반환

DB의 WHERE 절처럼 자유롭게 조건 조합. 한 번에 끝.

	Hierarchical	Relational
지원	필수 (Mandatory)	옵션 (Optional)
쿼리 단계	4단계	1단계
효율	단순함	유연함
Conformance Statement	항상 있음	명시되어야 함

PACS 모듈 개발 시: PACS 벤더의 Conformance Statement에서 "Relational Query 지원하는지" 꼭 확인. 지원 안 하면 무조건 hierarchical로 짜야 함.

5. Module, Information Entity, IOD — 데이터 조직화

2,000개의 데이터 element를 그냥 막 쓸 수는 없다. 의미 있는 단위로 묶어야 함. DICOM은 3계층 조직화를 정의:

┌─────────────────────────────────────────────┐
│  IOD (Information Object Definition)         │  ← 가장 큰 단위
│  ┌─────────────────────────────────────────┐ │
│  │ IE (Information Entity)                  │ │  ← 실세계 엔티티
│  │  ┌──────────────────────────────────┐    │ │
│  │  │ Module                            │   │ │  ← 속성 묶음
│  │  │   ├─ Data Element                │   │ │
│  │  │   ├─ Data Element                │   │ │
│  │  │   └─ Data Element                │   │ │
│  │  └──────────────────────────────────┘    │ │
│  └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘

5.1 Macro Attributes — "함수처럼 재사용"

여러 곳에서 똑같이 쓰이는 속성 묶음. 매번 풀어 쓰지 않고 매크로처럼 참조.

예: "Referenced Series Sequence" 매크로

(0008, 1115)  Referenced Series Sequence    SQ
   >(0020, 000E) Series Instance UID
   >(0008, 114A) Referenced Instance Sequence  SQ
      >>(0008, 1150) Referenced SOP Class UID
      >>(0008, 1155) Referenced SOP Instance UID

> 깊이로 중첩 표현. 다른 IOD에서 "이 매크로 포함" 한 줄로 가져올 수 있음.

5.2 Information Module — 기본 빌딩 블록

관련 속성을 묶은 단위. 약 100개의 표준 모듈 존재.

예시 1: Patient Identification Module

Attribute	Tag
Patient Name	`(0010, 0010)`
Patient ID	`(0010, 0020)`
Other Patient IDs	`(0010, 1000)`
Other Patient Names	`(0010, 1001)`
Patient's Birth Name	`(0010, 1005)`
Patient's Mother's Birth Name	`(0010, 1060)`
Medical Record Locator	`(0010, 1090)`

→ "환자 식별과 관련된 모든 속성"을 한 묶음으로.

예시 2: Cine Module (동영상 재생용)

Attribute	Tag	설명
Frame Time	`(0018, 1063)`	프레임 간 시간 (ms)
Cine Rate	`(0018, 0040)`	FPS
Preferred Playback Sequencing	`(0018, 1244)`	Loop or Sweep
Start Trim / Stop Trim	`(0008, 2142/2143)`	재생 시작/끝 프레임

→ 초음파 cine loop 같은 multiframe 영상에서만 필요. CT/MR에는 없음.

5.3 Module의 사용 분류

코드	의미
M	Mandatory (필수)
C	Conditional (조건부 필수)
U	User-defined (선택, 옵션)

→ Modality(영상 종류)마다 어떤 Module이 M/C/U인지 정의.
예: Patient Identification Module은 모든 modality에서 M.

5.4 ⚠️ Module은 정규화돼 있지 않다

DB 설계자라면 놀랄 부분: 여러 모듈이 같은 attribute를 중복으로 포함한다.

Patient Name (0010,0010) 이 Patient Module, Patient Identification Module 등 여러 곳에 등장
Cine Module 안에 Frame Time과 Cine Rate가 둘 다 있음 (Cine Rate = 1000 / Frame Time)

이게 좋은 설계는 아니지만, 표준이 25년에 걸쳐 진화하면서 누적된 결과.

DICOM 개발자 조언 (저자 인용):
"DICOM 모듈을 기본 데이터 빌딩 블록으로 사용하라. base Module 클래스를 만들고, 각 모듈마다 자식 클래스로 확장. 객체지향의 힘을 활용하면 코드가 깔끔해진다."
대부분의 DICOM 소프트웨어가 모듈 무시하고 element 직접 다루다가 버그 양산 중.

6. Information Entity (IE) — 실세계 엔티티

Module이 "속성 묶음"이라면, IE는 실세계 엔티티(객체) 다.

Common Patient IE     =  Patient Module
                         + Specimen Identification Module
                         + Clinical Trial Subject Module

Common Study IE       =  General Study Module
                         + Patient Study Module
                         + Clinical Trial Study Module

6.1 DICOM의 IE들 (약 20개)

Patient ─── Study ─── Series ─── Image
                   │            │
                   │            ├── Waveform (음성/심전도)
                   │            ├── SR Document (구조화 리포트)
                   │            └── Presentation State
                   │
                   ├── Frame of Reference (3D 좌표계)
                   └── Equipment (장비 정보)

각 박스가 IE. 이 모델이 바로 DICOM의 "세계관"이다.

6.2 4계층 vs IE

5.1에서 본 Patient/Study/Series/Image 4계층은 IE 중 핵심 4개의 hierarchy. 실제로는 더 많은 IE가 존재 (Waveform, SR, Frame of Reference 등).

7. IOD (Information Object Definition) — 최종 객체

여러 IE를 모아 실제 DICOM 객체 타입을 정의한 것이 IOD.

7.1 CT Image IOD 분해 예시

CT 영상 하나를 만들기 위해 필요한 IE + Module 조합:

IE	Module	Usage
Patient	Patient	M
	Clinical Trial Subject	U
Study	General Study	M
	Patient Study	U
	Clinical Trial Study	U
Series	General Series	M
	Clinical Trial Series	U
Frame of Reference	Frame of Reference	M
Equipment	General Equipment	M
Image	General Image	M
	Image Plane	M
	Image Pixel	M
	Contrast/Bolus	C (조영제 사용 시)
	CT Image	M
	Overlay Plane	U
	VOI LUT	U
	SOP Common	M

→ 이 모든 모듈을 합쳐서 하나의 CT Image IOD 완성.

MR Image IOD는 이 중 CT Image 모듈만 MR Image 모듈로 교체하면 거의 됨. NM(핵의학)은 multiframe 등 더 많이 바꿔야 함.

7.2 Normalized vs Composite IOD

DICOM은 IOD를 두 종류로 분류.

Normalized IOD: 단일 실세계 엔티티만 표현

예: Study IOD → Study 고유 속성(검사 날짜, 시간 등)만
"그 Study의 환자 이름"은 포함 안 함 (그건 Patient의 속성)
DB 정규화 개념과 같음

Composite IOD: 여러 엔티티를 섞어 통합

예: CT Image IOD → 환자 정보 + Study 정보 + 장비 정보 + 영상 자체
한 객체 안에 다 들어있어서 자기 완결적
DICOM 영상 객체는 거의 다 Composite

[Composite CT Image IOD]
├── Patient 정보 (Name, ID, Birth Date)
├── Study 정보 (Study UID, Date, Description)
├── Series 정보 (Series UID, Modality)
├── Equipment 정보 (제조사, 모델)
├── Image 정보 (Rows, Columns, Pixel Spacing)
└── Pixel Data ← 실제 영상

→ 그래서 CT 영상 한 장(.dcm 파일 하나)에 환자 이름까지 다 들어있는 것.

7.3 IOD ↔ Class / Instance 관계

IOD            =  추상 클래스 (e.g., "CT Image 타입")
DICOM Object   =  그 클래스의 인스턴스 (실제 영상 데이터)
SOP Class UID  =  어떤 IOD 타입인지 가리키는 UID
SOP Instance UID = 그 인스턴스의 UID (= Image UID와 동일)

객체지향 비유

class CTImageIOD:           # IOD = Class
    patient_name: str
    study_uid: str
    pixel_data: bytes
    # ... 약 50~100개 속성

my_image = CTImageIOD()     # DICOM Object = Instance
my_image.patient_name = "Smith^John"
my_image.pixel_data = b"..."

→ 2편에서 본 "DICOM Object"는 사실 모두 IOD의 instance.

7.4 SOP Class UID로 IOD 식별

DICOM 영상마다 (0008, 0016) SOP Class UID 가 있어서 "이게 어떤 IOD인지" 알려준다.

SOP Class UID	IOD
`1.2.840.10008.5.1.4.1.1.2`	CT Image Storage
`1.2.840.10008.5.1.4.1.1.4`	MR Image Storage
`1.2.840.10008.5.1.4.1.1.6.1`	US Image Storage
`1.2.840.10008.5.1.4.1.1.88.22`	Enhanced SR Storage
`1.2.840.10008.5.1.4.1.1.7`	Secondary Capture Image Storage

→ AI 추론 앱이 추론 결과를 PACS에 보낼 때, 올바른 SOP Class UID를 선택해야 함. CT 결과를 MR Image Storage로 보내면 PACS가 reject.

8. 전체 그림 — 모든 개념의 연결

┌─────────────────────────────────────────────────────────┐
│              DICOM Information Model                    │
└─────────────────────────────────────────────────────────┘

    Data Dictionary (2,000+ 표준 attribute)
        │
        ▼
    Module (관련 attribute 100여 묶음)
        │
        ▼
    Information Entity (Patient, Study, Series, Image, ...)
        │
        ▼
    IOD (CT Image, MR Image, SR, ...)
        │  (추상 Class)
        ▼
    DICOM Object = IOD Instance
        │
        ▼
    DICOM File (.dcm) ← 디스크에 저장됨
        OR
    DICOM Network ← Association으로 전송됨

┌─────────────────────────────────────────────────────────┐
│  계층 구조 (조회 시 사용)                                  │
│  Patient ID → Study UID → Series UID → SOP Instance UID │
└─────────────────────────────────────────────────────────┘

9. AI 추론 앱 관점에서의 정리

AI 추론 앱이 PACS와 상호작용하는 시나리오 정리

9.1 영상 수신 (PACS → AI 앱)

PACS                                AI 앱
 │                                   │
 │  ① C-Find: Modality=MR            │
 │     ←──────────────────────────── │
 │  ② Study UID 목록 응답              │
 │  ──────────────────────────────→  │
 │  ③ C-Move: Study UID 지정          │
 │     ←──────────────────────────── │
 │  ④ C-Store: 영상 전송 (Composite IOD)│
 │  ──────────────────────────────→  │
                                        │
                                        ▼
                          [Orthanc 또는 로컬 디스크]
                          Patient/Study/Series 계층으로 저장
                          → SOP Class UID 확인
                          → Pixel Data 추출 →  입력

9.2 추론 결과 전송 (AI 앱 → PACS)

   결과
    │
    ▼
[Secondary Capture IOD 또는 SR IOD 생성]
    │
    ├─ Patient ID: 원본과 동일 ✅
    ├─ Study UID: 원본과 동일 ✅      ← 같은 검사 하위로 묶이게
    ├─ Series UID: 새로 생성 ✅       ← 별도 시리즈로 구분
    ├─ SOP Instance UID: 새로 생성 ✅
    └─ SOP Class UID: 1.2.840.10008.5.1.4.1.1.7 (SC) 또는 SR
    │
    ▼
C-Store → PACS

핵심 원칙:

상위 식별자(Patient, Study)는 절대 바꾸지 말 것 → 안 그러면 같은 검사로 묶이지 않음
Series/Image UID는 새로 생성 → 원본과 구분
그래야 PACS 뷰어에서 환자 검사 펼쳐보면 "원본 시리즈들 + AI 결과 시리즈" 가 같이 보임

10. 핵심 정리

개념	한 줄
4계층	Patient → Study → Series → Image. 모든 PACS 데이터의 뼈대
Patient ID	표준화 안 됨. 병원/장비마다 천차만별. Cross-check 필수
Study/Series/Image UID	장비 자동 생성. globally unique. 한번 부여되면 불변
Hierarchical Query	4단계로 내려가는 필수 쿼리 방식
Relational Query	DB WHERE처럼 자유 쿼리. 옵션
Module	관련 attribute 묶음 (약 100개). M/C/U 분류
Information Entity (IE)	실세계 엔티티 (Patient, Study, Image 등). 약 20개
IOD	여러 IE를 조합한 최종 객체 타입 (= 추상 Class)
DICOM Object	IOD의 instance
Normalized IOD	단일 엔티티만 (정규화)
Composite IOD	여러 엔티티 통합. 영상 IOD는 대부분 이것
SOP Class UID	"이게 어떤 IOD인지" 알려주는 UID

11. 다음 글에서 다룰 것

4편: DICOM SOP — C-Echo, C-Store, C-Find

AE Title (Application Entity Title) — PACS 등록 시 필수
DIMSE (DICOM Message Service Elements)
Service-Object Pair (SOP) 의 정확한 의미
C-Echo — 연결 테스트
C-Store — 영상 저장
C-Find — 쿼리

참고

Pianykh, O.S. Digital Imaging and Communications in Medicine (DICOM). Springer, 2008.

[DICOM] Tag, Data Dictionary, Object Encoding — DICOM 데이터를 바이트로 푸는 법

odod00 — Wed, 27 May 2026 17:14:53 +0900

Oleg Pianykh, Digital Imaging and Communications in Medicine (DICOM) (Springer, 2008) 정리 2편
참고 챕터: Ch 5.4 – 5.5

이번 글에서는 "데이터가 무엇을 의미하는지" 를 알려주는 Tag와 Data Dictionary, 그리고 실제 바이트로 어떻게 직렬화되는지 까지 본다.

1. Tag — DICOM의 "주소"

DICOM의 모든 데이터 요소(element)는 16진수 4자리 두 개로 식별된다.

(0010, 0020)
  ↑      ↑
 Group  Element

Group (2 byte): 비슷한 속성들의 묶음
Element (2 byte): 그 그룹 안에서 개별 항목

예시:

(0010, 0010) = Patient Name (환자 이름)
(0010, 0020) = Patient ID
(0008, 0060) = Modality (CT, MR ...)
(7FE0, 0010) = Pixel Data (실제 이미지)

그룹은 주제별로 묶임

Group	주제
`0008`	SOP Common, 검사 식별 정보
`0010`	Patient (환자)
`0018`	Acquisition (촬영 파라미터)
`0020`	Image (인스턴스/슬라이스 위치 등)
`0028`	Image Pixel (가로/세로/비트 깊이)
`7FE0`	Pixel Data (픽셀 데이터)

✅ 짝수 group = 표준 / ❌ 홀수 group = Private(제조사 독자)
→ 그래서 GE 장비에서 (0009, ...) 같은 odd-group이 나오면, "아, GE 사설 태그구나" 알 수 있음.

2. Data Dictionary — DICOM의 "사전"

DICOM Data Dictionary는 약 2,000개 이상의 표준 속성을 모은 사전.

(Group, Element)	Attribute Name	VR	VM
`(0008, 0005)`	Specific Character Set	CS	1-n
`(0010, 0010)`	Patient Name	PN	1
`(0010, 0020)`	Patient ID	LO	1
`(0010, 0030)`	Patient's Birth Date	DA	1
`(0010, 0040)`	Patient's Sex	CS	1
`(0010, 1001)`	Other Patient Names	PN	1-n

각 항목은

Tag: 식별자
Attribute Name: 사람이 읽는 이름
VR: 값의 형식 (1편 참조)
VM (Value Multiplicity): 값 개수 (1, 1-n, 2, 3-5 등)
RET: 폐기된 속성 표시

"DICOM 문장" 만들어보기

"환자 John Smith, 남자, 1954년 8월 6일 출생" 을 DICOM 표현으로 옮기면,

(0010,0010) Smith^John          ← PN
(0010,0030) 19540806            ← DA
(0010,0040) M                   ← CS

이게 바로 DICOM이 데이터를 인코딩하는 방식. 단순한 (tag, value) 쌍의 나열이다.

VM (Value Multiplicity) — 한 속성에 여러 값

VM이 1-n인 경우 여러 값을 백슬래시(\) 로 구분해서 한 필드에 넣는다.

예: 환자의 가명이 둘이면

(0010,1001) Dr^Jekyll\Mr^Hide   ← VM=2

1편에서 본 와일드카드 \ = OR이 여기 다시 등장. \는 무조건 구분자 역할이라 파일명·텍스트에 쓰면 안 됨.

VM (Value Multiplicity) 표기법

VM은 한 데이터 요소에 들어갈 수 있는 값의 개수를 나타내. 의료 데이터는 종류에 따라 값 개수가 천차만별이라 단순히 "1개" 가 아니라 다양한 패턴을 표현해야 함.

  ┌──────┬─────────────────────────────────┬─────────────────────────────────────────────────────┐
  │  VM  │              의미               │                        예시                         │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 1    │ 정확히 1개 (가장 흔함)           │ Patient Name                                        │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 2    │ 정확히 2개                       │ Patient Orientation (row, column)                   │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 3    │ 정확히 3개                       │ Image Position (x, y, z 좌표)                       │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 6    │ 정확히 6개                       │ Image Orientation (row vector 3개 + col vector 3개) │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 1-n  │ 1개 이상 무제한                  │ Other Patient Names                                 │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 0-n  │ 0개 이상 무제한 (있어도 없어도)   │ 보통 retired 속성                                   │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 1-2  │ 1개 또는 2개                     │ (드물게 사용)                                       │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 2-n  │ 2개 이상 무제한                  │                                                     │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 3-3n │ 3의 배수만 (3, 6, 9, 12 ...)     │ 여러 3D 좌표 묶음                                   │
  ├──────┼─────────────────────────────────┼─────────────────────────────────────────────────────┤
  │ 2-2n │ 2의 배수만 (2, 4, 6 ...)         │ 여러 쌍 데이터                                      │
  └──────┴─────────────────────────────────┴─────────────────────────────────────────────────────┘

Private Data Dictionary (제조사 사설 사전)

표준 2,000개로 부족할 때 제조사는 자기 odd group에 사설 속성을 정의한다.

예: 우리가 환자 "중간 이름"을 추가하고 싶다면

(0009, 0010) Patient's Middle Name   PN   1   ← 우리 사설 사전

문제는 다른 회사도 (0009, 0010)을 다른 의미로 쓸 수 있다는 것. → 사설 태그 충돌(private tag collision).

DICOM은 이를 막기 위해 Private Creator Element 라는 메커니즘을 두지만, 실무에서는 여전히 PACS 호환성 문제의 단골손님.

⚠️ PACS 모듈 개발 시 명심: 알 수 없는 사설 태그를 받으면 무조건 무시(skip). 절대 추측해서 해석하지 말 것.

3. Command Dictionary — DICOM의 "명령어"

Print, Store, Move, Get 같은 명령은 어디 있을까?

→ Group 0000 이 명령 전용 그룹. Data Dictionary와 똑같은 형식이지만 명령용.

예시:

(0000, 0100) = Command Field (명령 타입)
(0000, 0110) = Message ID
(0000, 0800) = Command Data Set Type

이 명령들은 뒤에서 자세히 다룸.

4. Element Encoding — 실제 바이트로 어떻게 쓰이나

이게 이번 글의 핵심. DICOM은 두 가지 인코딩 방식이 있다.

4.1 Implicit VR Encoding (암묵적)

VR을 명시하지 않음. 받는 쪽이 Data Dictionary를 찾아봐서 알아내야 함.

┌─────────┬──────────┬──────────┬──────────────┐
│  Group  │ Element  │  Length  │    Value     │
│ 2 bytes │ 2 bytes  │ 4 bytes  │  L bytes     │
└─────────┴──────────┴──────────┴──────────────┘

예시: Patient Name = "Smith^Joe" (9자 → 짝수 맞추려 공백 패딩 → 10자)

Byte#	1	2	3	4	5	6	7	8	9
Hex	`10`	`00`	`10`	`00`	`0A`	`00`	`00`	`00`	`53`
의미	Group `0010`		Element `0010`		Length `0x0A`=10				`'S'`
9	10	11	12	13	14	15	16	17	18
53	53	69	74	68	5E	4A	6F	65	20
'S'	'm'	'i'	't'	'h'	'^'	'J'	'o'	' e'	' '

Little Endian이라 group 0010이 메모리에는 10 00 으로 거꾸로 쓰임. 헷갈리지 말 것.

4.2 Explicit VR Encoding (명시적) — 일반 VR

VR을 직접 같이 보냄.

┌─────────┬──────────┬────┬────────┬──────────────┐
│  Group  │ Element  │ VR │ Length │    Value     │
│ 2 bytes │ 2 bytes  │ 2  │   2    │  L bytes     │
└─────────┴──────────┴────┴────────┴──────────────┘

예시: 같은 "Smith^Joe " 를 Explicit으로

Byte#	1	2	3	4	5	6	7	8	9~18
Hex	`10`	`00`	`10`	`00`	`50`	`4E`	`0A`	`00`	`Smith^Joe`
의미	Group		Element		`'P'`	`'N'`	Length=10		Value

VR 자리에 "PN" 의 ASCII 코드 50 4E 가 들어감.

4.3 Explicit VR Encoding — 특수 VR (`OB`, `OW`, `OF`, `SQ`, `UT`, `UN`)

이 6가지 VR은 데이터가 클 수 있어서 Length를 4 byte로 늘리고 그 앞에 2-byte 예약 공간을 둔다.

┌─────────┬──────────┬────┬──────────┬──────────┬──────────────┐
│  Group  │ Element  │ VR │ Reserved │  Length  │    Value     │
│ 2 bytes │ 2 bytes  │ 2  │ 2(=0000) │ 4 bytes  │  L bytes     │
└─────────┴──────────┴────┴──────────┴──────────┴──────────────┘

예시: 256×256 픽셀 이미지 (OB, 1 byte/pixel = 65,536 bytes = 0x00010000)

Byte#	1	2	3	4	5	6	7	8	9~12	13~65548
Hex	`E0`	`7F`	`10`	`00`	`'O'`	`'B'`	`00`	`00`	`00 00 01 00`	(픽셀 65536개)
의미	Group `7FE0`		Elem `0010`		VR=OB		reserved		Length=`0x00010000`	Pixel Data

→ (7FE0, 0010) Pixel Data 가 어떻게 바이트로 표현되는지 보였음.

4.4 Implicit vs Explicit — 언제 뭘 쓰나?

	Implicit	Explicit
디폴트 여부	DICOM 기본값 (Little Endian + Implicit)	옵션
크기	작음	약간 큼
안전성	사전 의존	VR 정보 보존
사설 태그	UN으로 처리해야	VR 명시 가능

⚠️ 두 방식을 한 객체에서 섞을 수 없음. 한 가지로 통일해야 함. 어느 걸 쓸지는 Association 단계에서 합의

4.5 Implicit ↔ Explicit 변환

Explicit → Implicit: VR만 떼면 됨 → 쉬움
Implicit → Explicit: 모든 태그를 사전 lookup → 어렵고, 사설 태그는 UN으로 처리

PACS 게이트웨이나 변환 도구 만들 때 이 비대칭성 주의.

5. Group 단위 인코딩 + 정렬 규칙

5.1 element는 tag 순서대로 정렬

DICOM object 안의 element는 (group, element) 오름차순으로 정렬돼야 한다.

(0008, 0012) → (0008, 0014) → (0010, 0010) → (0010, 0020) → (0028, 0010) → ...

이게 깨지면 → 데이터 손상으로 간주, 거부.

PACS 개발 팁: 파일 읽다가 tag 번호가 역행하면 즉시 reject. validation의 첫 단계.

5.2 Group Length Tag `(gggg, 0000)`

각 그룹의 첫 element는 그 그룹 전체 길이를 담는 group length 용으로 예약돼 있다.

예: (0010, 0000) = group 0010 (Patient) 의 총 byte 수

장점: 그룹 통째로 skip 가능 → partial parsing (사설 그룹 무시할 때 유용)

단점:

on-the-fly로 객체를 쓰기 어려움 (먼저 length 계산 필요)
element 하나만 바꿔도 group length 다시 계산 → 귀찮음

현실: 대부분의 DICOM 소프트웨어는 group length를 무시하거나 잘못 쓴다. 표준상으로도 group length는 optional. 그래도 읽을 줄은 알아야 함.

PACS 개발 팁: group length는 쓰지 말고 (덜 깨짐), 받을 때는 무시하고 직접 파싱. 이게 가장 안전한 패턴.

6. DICOM Object 전체 구조

DICOM Object = data element들의 정렬된 시퀀스.

┌──────────────────────────────────────────────────┐
│  (0008, 0005)  CS   "ISO_IR 100"                 │
│  (0008, 0016)  UI   "1.2.840.10008.5.1.4.1.1.2"  │   ← SOP Class
│  (0008, 0018)  UI   "1.2.3.4.5..."               │   ← SOP Instance
│  (0008, 0060)  CS   "CT"                         │   ← Modality
│  (0010, 0010)  PN   "Smith^John"                 │   ← Patient Name
│  (0010, 0020)  LO   "12345"                      │   ← Patient ID
│  (0028, 0010)  US   512                          │   ← Rows
│  (0028, 0011)  US   512                          │   ← Columns
│  (7FE0, 0010)  OB   <pixel data>                 │   ← Pixel Data
└──────────────────────────────────────────────────┘

DICOM 파일(.dcm)도 본질적으로는 이 object를 디스크에 dump한 것. 따로 "DICOM header" + "DICOM image" 가 나뉘어 있는 게 아니다. 처음부터 끝까지 element의 연속일 뿐.

7. SQ (Sequence) — 객체 안에 객체

VR SQ 는 DICOM object를 통째로 또 담는 특수 VR. 이걸로 트리 구조 표현 가능.

Parent Object
├─ (0008, 0005) Specific Character Set
├─ (0008, 1115) Referenced Series Sequence   ← SQ!
│   ├─ Item 1
│   │   ├─ (0020, 000E) Series Instance UID
│   │   └─ (0008, 114A) Referenced Instance Sequence  ← 또 SQ
│   │       └─ Item 1
│   │           ├─ (0008, 1150) Referenced SOP Class UID
│   │           └─ (0008, 1155) Referenced SOP Instance UID
│   └─ Item 2
└─ ...

7.1 SQ 인코딩 — 핵심 마커들

마커	의미
`(FFFE, E000)`	Item 시작 (sequence 안의 각 객체)
`(FFFE, E00D)`	Item 종료 (Item Delimitation)
`(FFFE, E0DD)`	Sequence 종료 (Sequence Delimitation)

7.2 길이 지정 방법 두 가지

(1) Explicit Length (명시적 길이)

SQ ─ Length: 0x00000A00 (2560 byte)
   ├─ (FFFE,E000) ─ Length: 0x04F8 ─ DICOM object
   └─ (FFFE,E000) ─ Length: 0x04F8 ─ DICOM object

빨리 skip 가능
미리 길이 계산 필요

(2) Undefined Length (미정 길이) — `0xFFFFFFFF`

SQ ─ Length: 0xFFFFFFFF (undefined)
   ├─ (FFFE,E000) ─ Length: 0x1234 ─ DICOM object
   ├─ (FFFE,E000) ─ Length: 0xFFFFFFFF ─ DICOM object ─ (FFFE,E00D) ─ 0x00000000
   └─ (FFFE,E0DD) ─ 0x00000000   ← Sequence Delim.

streaming 가능, 구현 쉬움
skip은 불가

7.3 SQ는 XML과 같다

생각해보면:

(gggg, eeee) SQ ≈ <sequence>
(FFFE, E0DD) ≈ </sequence>
(FFFE, E000) ≈ <item>
(FFFE, E00D) ≈ </item>

→ DICOM SQ는 사실상 XML의 nested 구조와 같다.

PACS 개발 팁:
쓸 때는 undefined length (간단하고 안전)
읽을 때는 둘 다 지원해야 함 (다른 벤더의 것)
재귀(recursion)로 구현하면 깔끔

8. Attribute Type — Required / Optional

모든 데이터를 다 넣을 필요는 없다. PS3.3 (IOD)에서 각 SOP Class마다 어떤 속성이 필수인지 정의.

Type	의미
1	Required, 값 필수 (비울 수 없음)
1C	Required, 조건 충족 시 (Conditional)
2	Required, 모르면 빈 값 OK
2C	Required, 조건 충족 시, 모르면 빈 값 OK
3	Optional (있어도 되고 없어도 됨)

예시 (CT Image SOP)

(0010, 0020) Patient ID → Type 1 (필수)
(0010, 0010) Patient Name → Type 2 (필수지만 모르면 빈 값)
(0028, 2110) Lossy Compression → Type 1C (압축한 경우에만)

⚠️ 위험한 함정: 빈 Patient ID

Patient ID가 빈 값으로 들어오면 DICOM 검색에서 와일드카드(any) 로 해석될 수 있음.
→ 서로 다른 환자가 한 명으로 merge되는 사고 발생.

PACS 운영자가 가장 많이 겪는 사고 중 하나. Patient ID는 절대 빈값으로 두면 안 됨.
검증 도구 추천: DVTk (DICOM Validation Toolkit) — http://www.dvtk.org

9. Image Data — 픽셀은 어떻게 저장되나

이미지도 일반 element와 똑같이 저장됨.

핵심 속성

Tag	Attribute	의미
`(0028, 0010)`	Rows	세로 픽셀 수
`(0028, 0011)`	Columns	가로 픽셀 수
`(7FE0, 0010)`	Pixel Data	실제 픽셀 (보통 `OB` 또는 `OW`)

Pixel Data가 DICOM object 전체 크기의 95% 정도 차지. 의료 영상은 크다.

Multi-frame (동영상도 됨!)

여러 프레임을 한 객체에 담을 수 있음. 초음파 cine loop, fluoroscopy 등.

(0028, 0008) Number of Frames
(0018, 0040) Frames Per Second

예: 10초짜리 25 FPS US cine = 250 프레임을 한 DICOM 객체에 저장.

단, DICOM 자체는 비디오 코덱이 아님. 250장의 정지영상 + "FPS" 메타데이터를 같이 저장할 뿐. 재생은 viewer의 몫.

10. UID (Unique Identifier) — 글로벌 식별자

DICOM에서 가장 중요한 개념 중 하나.

10.1 UID란?

전 세계적으로 유일한 문자열 식별자. VR은 UI, 형식은:

UID = <org root> . <suffix>

예: 1.2.840.10008.1.2

<org root>: 조직 식별자 (NEMA가 발급/관리)
<suffix>: 조직 내에서 유일하게 부여

예약: 1.2.840.10008 = DICOM 표준 트랜잭션 전용 (남의 UID prefix로 못 씀)

10.2 인스턴스(Instance) 개념

같은 영상이라도 어디 저장돼 있느냐, 누가 편집했느냐에 따라 별개의 instance.

원본 영상 (UID: ...1.1)
  ├── 복사본 1 (UID: ...1.2)   ← 다른 곳에 저장
  ├── 크롭한 버전 (UID: ...1.3) ← 편집됨
  └── 어노테이션 추가 (UID: ...1.4)

→ 모두 다른 UID. 인스턴스마다 UID는 반드시 새로 발급.

10.3 DICOM에서 UID가 쓰이는 곳

Study Instance UID (0020, 000D) — 검사 단위
Series Instance UID (0020, 000E) — 시리즈 단위
SOP Instance UID (0008, 0018) — 개별 이미지
SOP Class UID (0008, 0016) — "어떤 종류 객체인지" (CT, MR ...)
Transfer Syntax UID — 인코딩 방식
그 외 거의 모든 글로벌 식별자

10.4 UID 생성 규칙

조직 내 유일성을 보장하기 위한 흔한 패턴

<org root>.<patient ID>.<study ID>.<current date>.<timestamp ms>

⚠️ 절대 UID를 파싱하지 말 것. 환자 정보가 들어있는 것처럼 보여도 추출 금지. DICOM 표준이 명시적으로 금지함. UID의 유일한 용도는 인스턴스 구별.

10.5 UID로 DICOM 파일 식별하기

알 수 없는 파일이 DICOM인지 확인하는 법:

DICM 매직 헤더: 파일 129~132 byte 위치에 "DICM" 4글자
UID prefix 검색: 파일 안에서 "1.2.840.10008" 문자열 찾기

Windows라면 WordPad나 hex editor로 열어서 둘 중 하나 확인.

내부에서 파일명을 UID로 짓는 경우도 흔함

1.2.804.114118.2.20040909.125423.3692976692.1.1.1.dcm

이런 파일명 보이면 거의 100% DICOM.

11. 핵심 정리

개념	한 줄 요약
Tag	`(group, element)` 16진수 4자리 두 개. 짝수 group=표준, 홀수=사설
Data Dictionary	2,000개 표준 속성 사전. 각 항목에 VR/VM/Type 정의
Command Dictionary	Group `0000` 전용. DIMSE 명령들
Implicit VR	`(g,e) + length(4) + value`. DICOM 기본값
Explicit VR	`(g,e) + VR(2) + length(2/4) + value`. 안전성↑
정렬 규칙	tag 오름차순. 위반 시 corrupted
Group Length	옵션, 쓰지 말고 읽을 줄만 알 것
SQ	객체 중첩. `(FFFE,E000)` item, `(FFFE,E0DD)` seq 끝
Type 1/1C/2/2C/3	필수/조건부필수/필수(빈값)/조건부빈값/옵션
Pixel Data	`(7FE0, 0010)`. 보통 `OB`/`OW`, 객체의 95%
UID	글로벌 유일 식별자. `<org root>.<suffix>`. 파싱 금지

12. 다음 글에서 다룰 것

DICOM Information Hierarchy (Patient/Study/Series/Image 4계층) 와 IOD (Information Object Definition)

왜 4계층인가? 실제 임상 워크플로우와 매핑
Patient ID, Study UID, Series UID, SOP Instance UID — 각각의 역할
Module / Macro / Information Entity / IOD — 어떻게 조합되나
CT Image IOD를 예제로 끝까지 분해

여기까지 가면 "왜 C-Find가 4단계로 쿼리하는지", "왜 SOP Class라는 단위가 필요한지" 가 자연스럽게 이해될 수 있다.

참고

Pianykh, O.S. Digital Imaging and Communications in Medicine (DICOM). Springer, 2008.
공식 표준 매핑: PS3.5 (Data Structures and Encoding), PS3.6 (Data Dictionary), PS3.7 (Command set)
DVTk (DICOM Validation Toolkit): http://www.dvtk.org

[DICOM] DICOM이란 무엇인가? — 데이터 표현(VR)까지

odod00 — Tue, 26 May 2026 17:54:21 +0900

어쩌다 의료영상 데이터를 계속 접하고 개발하는 일을 하다보니..
DICOM 관련 문서를 제대로 읽고 정리해보고자 한다.

Oleg Pianykh, *Digital Imaging and Communications in Medicine (DICOM): A Practical Introduction and Survival Guide* (Springer, 2008) 정리

참고 챕터: Ch 1–4 + Ch 5.1–5.3

이 글에서는 "DICOM이 도대체 뭔가?" 부터 시작해서,
DICOM의 가장 기본 단위인 VR (Value Representation, 데이터 표현 방식) 까지 정리할 예정이다.

1. DICOM이란?

DICOM = Digital Imaging and COmmunications in Medicine

흔한 오해부터 짚자. DICOM은 단순히 이미지 파일 포맷이 아니다.

DICOM은 의료영상의

저장 (Storage)
전송 (Transfer)
표시 (Display)

이 모든 것을 다루는 종합 프로토콜이다. 파일 포맷은 그 결과물 중 하나일 뿐.

"DICOM is an all-encompassing data transfer, storage, and display protocol built and designed to cover all functional aspects of digital medical imaging."

왜 만들어졌나?

1980년대만 해도 CT, MR 제조사마다 자기들만의 독점 포맷을 썼다. GE 영상은 GE 워크스테이션에서만, Siemens 영상은 Siemens에서만 볼 수 있는 식이었고, 환자가 다른 병원으로 가면 영상이 무용지물이었다.

이를 해결하려고 ACR(American College of Radiology) + NEMA(National Electrical Manufacturers Association)가 1983년에 위원회를 만들어 DICOM을 탄생시켰다.

2. DICOM과 PACS

PACS = Picture Archiving and Communication System (영상 저장 전송 시스템)

PACS는 다음 세 구성요소로 이뤄진 시스템이다

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│  Modality   │ ───→ │   Archive   │ ───→ │ Workstation │
│ (CT, MR..)  │      │ (저장소/DB)  │      │  (판독실)   │
└─────────────┘      └─────────────┘      └─────────────┘
       ↑                                          ↓
    영상 촬영                                  영상 판독

Modality: 영상 획득 장치 (CT, MR, US, X-ray ...)
Archive: 디지털 저장소 (PACS 서버)
Workstation: 판독의가 영상을 보는 단말

이 세 요소를 연결하는 언어가 DICOM. PACS는 DICOM으로 작동하고, DICOM은 PACS를 통해 현실에 구현된다.

비유: 디지털카메라(modality)로 사진 찍어서 → 컴퓨터(archive)에 저장 → 친구(reviewer)에게 보내기. 같은 모델인데 의료용으로 훨씬 복잡해진 것.

핵심 문서: Conformance Statement

모든 DICOM 장비/소프트웨어는 DICOM Conformance Statement(적합성 명세서) 라는 문서를 제공해야 한다. 이 문서가 말한다:

어떤 DICOM 기능을 지원하는지
어디까지 지원하는지 (SCU만? SCP만? 둘 다?)

PACS 벤더와 통신 모듈 개발 시 가장 먼저 받아야 할 문서. 이거 없이는 어떤 호환성 문제도 해결 못 한다.

3. DICOM은 어떻게 동작하는가?

DICOM의 핵심 개념을 압축하면 다음과 같다.

3.1 모든 것은 "객체(Object)"

DICOM은 현실의 모든 것을 객체(Object) + 속성(Attribute) 으로 본다. 객체지향 프로그래밍의 것과 같다.

현실 객체	DICOM 속성 예시
환자(Patient)	이름, ID, 성별, 생년월일, 체중
스터디(Study)	검사일, 검사 종류, 의뢰의
이미지(Image)	가로, 세로, 픽셀 데이터, 슬라이스 두께

각 객체의 속성 모음을 표준화한 것이 IOD (Information Object Definition).

3.2 표준 사전: Data Dictionary

DICOM은 의료에 필요한 약 2,000개 이상의 표준 속성을 정의한 DICOM Data Dictionary 를 유지한다. 모든 속성은 27가지 VR(Value Representation, 값 표현 방식) 중 하나로 표현된다.

3.3 통신 모델: SCU / SCP

DICOM 네트워크에서 통신하는 단위를 AE (Application Entity) 라고 한다.

AE끼리 서비스를 주고받는 모델:

SCU (Service Class User): 서비스를 요청하는 쪽 (클라이언트)
SCP (Service Class Provider): 서비스를 제공하는 쪽 (서버)

예시: CT 스캐너가 영상을 PACS 서버에 저장

CT 스캐너 = Storage SCU (저장해줘!)
PACS 서버 = Storage SCP (저장해줄게)

3.4 SOP (Service-Object Pair)

서비스(Service)와 객체(Object)를 묶은 게 SOP. 예를 들어 "CT 이미지를 저장" = CT Image Storage SOP. 이런 SOP들이 모여 SOP Class 를 이룬다.

3.5 Association: 통신의 시작

두 AE가 통신하려면 먼저 Association(연결) 을 맺어야 한다. TCP 연결 후 "나는 누구고, 이런 서비스 지원하고, 이런 인코딩 쓴다" 하고 서로 자기소개를 한다. 이걸 Presentation Context 라고 부른다.

→ 이게 맞으면 통신 시작, 안 맞으면 연결 거부.

Association은 DICOM 디버깅의 80%가 일어나는 곳.

4. "DICOM-Compatible" vs "DICOM-Ready" 함정

장비를 살 때 주의할 점.

DICOM-Compatible: 실제로 DICOM 기능이 탑재됨
DICOM-Ready: 돈을 추가로 내면 DICOM 기능을 켤 수 있음 (= 안 사면 못 씀)

장비 제조사들은 종종 DICOM 기능을 유료 옵션으로 판매한다. "DICOM-Ready 장비를 샀더니 정작 DICOM은 못 쓰더라" 가 흔한 함정.

장비 살 때 견적서에 "DICOM functionality"가 명시적으로 포함됐는지 확인할 것.
또한 직접 패치하려 하지 말 것. 무조건 제조사를 통해 해결. (보증 날아감)

5. 간략한 역사

연도	이벤트
1983	ACR + NEMA 위원회 발족
1985	ACR-NEMA 1.0 발표
1988	ACR-NEMA 2.0
1993	DICOM 3.0 (현재까지 사용 중)
이후~현재	DICOM 3.0의 연간 개정판 (PS3.X-YYYY 형식)

DICOM 4.0은 없다. DICOM 3.0이 매년 개정될 뿐. 그래서 "DICOM 2008"은 정확히는 "DICOM 3.0의 2008년 개정판"을 의미한다.

중요: 의료기기는 수명이 길기 때문에 (15~20년) 1990년대 기능 세트를 가진 장비가 아직도 현역에서 돌아간다. 하위 호환성이 항상 최우선 이다.

6. 컴퓨터 기초 복습 (DICOM 이해를 위한)

DICOM을 이해하려면 비트/바이트/16진수에 익숙해야 한다.

Bit / Byte

bit: 0 또는 1
byte: 8 bit = 256가지 값 (0~255)

16진수 (Hexadecimal)

2바이트(16비트) = 4자리 16진수 (예: 0x007F)
표기: 0x 접두사 또는 H 접미사
DICOM의 거의 모든 숫자 식별자는 16진수

0x007F  =  0×16³ + 0×16² + 7×16¹ + 15×16⁰  =  127

Endian (바이트 순서) ⚠️

Little Endian: 낮은 자리 바이트 먼저 (Intel/Windows)
Big Endian: 높은 자리 바이트 먼저 (구 Mac, 네트워크 표준)

같은 숫자 0x007F (127)가

Little Endian: 7F 00 으로 저장
Big Endian: 00 7F 으로 저장

→ 두 시스템이 통신할 때 이게 안 맞으면 127이 32,512로 잘못 읽힘.

DICOM 기본값은 Little Endian. 모든 DICOM 구현체는 무조건 Little Endian을 지원해야 한다.

Text vs Binary

DICOM은 두 가지 데이터 형식을 다 쓴다
- Text: 이름, ID, 날짜 등 → Endian 영향 없음, 사람이 읽기 쉬움
- Binary: 픽셀 데이터, 좌표 등 → 공간 효율적이지만 Endian 영향 받음

DICOM 파일을 메모장에서 열면 텍스트와 깨진 문자가 섞여 보이는 이유.

7. VR (Value Representation) — DICOM의 어휘

DICOM은 모든 데이터를 27가지 VR 중 하나로 표현한다.

각 VR은:

2글자 약어 (예: PN, DA, UI)
허용되는 문자
최대 길이

를 정해두고 있다. PACS 호환성 문제의 상당수가 "VR 길이 초과" 또는 "VR 형식 위반"에서 나온다.

7.1 텍스트형 VR (Text VRs)

VR	이름	최대 길이	예시
`CS`	Code String	16자	`"CT"`, `"MR"`, `"CD123_4"` (대문자/숫자/_/공백만)
`SH`	Short String	16자	전화번호, ID
`LO`	Long String	64자	`"Introduction to DICOM"`
`ST`	Short Text	1,024자	1~수 문단
`LT`	Long Text	10,240자	긴 문단
`UT`	Unlimited Text	거의 무제한	매우 긴 텍스트

7.2 이름과 식별자

VR	이름	최대	예시
`AE`	Application Entity (장비/프로그램 이름)	16자	`"MYPACS01"`
`PN`	Person Name (사람 이름)	64자	`"SMITH^JOHN"`
`UI`	Unique Identifier (UID)	64자	`"1.2.840.10008.1.1"`

PN의 표준 형식 (caret ^ 로 구분)

FamilyName^GivenName^MiddleName^NamePrefix^NameSuffix

실제 임상 환경에서는 "John Smith", "Smith^John", "Smith, John" 가 막 섞여서 들어와 혼란이 잦다.

→ 환자 식별은 항상 Name이 아니라 Patient ID로 해라.

7.3 날짜와 시간

VR	이름	형식	예시
`DA`	Date	`YYYYMMDD`	`"20050822"` (2005년 8월 22일)
`TM`	Time	`HHMMSS.FRAC`	`"183200.00"` (18:32:00.00)
`DT`	Date Time	`YYYYMMDDHHMMSS.FFFFFF`	`"20050812183000.00"`
`AS`	Age String	`nnnD/W/M/Y`	`"018M"` (18개월)

⚠️ DICOM은 시간대(Time Zone)를 지원하지 않는다. 텔레라디올로지에서 여러 나라를 연결할 때 함정이 됨.

7.4 숫자 (텍스트 형식)

VR	이름	예시
`IS`	Integer String	`"-1234567"`
`DS`	Decimal String	`"12345.67"`, `"-5.0e3"`

7.5 숫자 (바이너리 형식)

VR	이름	크기
`SS`	Signed Short	2 byte
`US`	Unsigned Short	2 byte
`SL`	Signed Long	4 byte
`UL`	Unsigned Long	4 byte
`FL`	Floating Point Single	4 byte
`FD`	Floating Point Double	8 byte
`AT`	Attribute Tag (group, element 쌍)	4 byte
`OB`	Other Byte String (1 byte씩)	가변
`OW`	Other Word String (2 byte씩)	가변
`OF`	Other Float String (4 byte씩)	가변

OB, OW, OF 가 픽셀 데이터(이미지) 를 담는 데 쓰임. 압축 영상은 보통 OB 사용.

7.6 특수 VR

VR	이름	용도
`SQ`	Sequence of Items	객체 안에 객체 (중첩 구조)
`UN`	Unknown	알 수 없는 데이터 (가능하면 쓰지 말 것)

SQ 는 DICOM의 트리 구조를 만들 때 사용. 예를 들어 "여러 시리즈를 참조하는 리스트" 같은 것. 처리가 복잡해서 버그가 자주 발생하는 부분이기도 함.

8. VR의 중요한 규칙들

8.1 짝수 길이 규칙

모든 DICOM 데이터 요소는 짝수 바이트 길이여야 한다.

홀수 길이면:

텍스트 → 공백(' ') 한 칸 패딩
바이너리 → NULL(0x00) 한 바이트 패딩

예: "Smith^Joe" (9자) → 내부 저장은 "Smith^Joe " (10자, 끝에 공백 추가)

비DICOM 시스템(SQL DB 등)으로 데이터 옮길 때 trailing space를 안 잘라내면 "Smith^Joe" 와 "Smith^Joe " 가 다른 환자로 인식되는 사고 발생.

8.2 와일드카드

DICOM 텍스트 검색에서

* : 임의 문자열 (asterisk)
? : 임의 한 글자
\ : OR 연산자

예: 모달리티 검색 "CT\MR" = "CT 또는 MR"

→ 따라서 파일명이나 텍스트에 \ 를 쓰면 안 됨. 검색 쿼리로 오해받음.

8.3 단위

DICOM은 미터법(SI 단위) 만 쓴다 (mm, kg, ...)
화면 표시는 사용자가 알아보기 쉽게 변환할 것 (예: 20080201 → 2008-02-01)

9. 다음 글에서 다룰 것

VR이 DICOM의 "어휘"라면, Tag와 Data Dictionary는 "단어장"이다.

다음 글(2편)에서는

DICOM Tag (group, element) 구조
Data Dictionary — 2,000개 표준 속성
Private Tag (제조사 독자 확장)
DICOM Object Encoding — Implicit/Explicit VR
Patient/Study/Series/Image 4계층

까지 정리한다.

핵심 정리

DICOM = 의료영상 통신/저장/표시 종합 프로토콜 (단순 파일 포맷 X)
PACS = DICOM으로 작동하는 영상 시스템
객체지향 모델: IOD = 객체 + 속성, 통신은 SCU↔SCP
통신 단위는 AE, 서비스+객체 쌍은 SOP
Conformance Statement가 모든 DICOM 작업의 출발점
모든 데이터는 27가지 VR 중 하나로 표현
기본 Endian은 Little Endian, 모든 길이는 짝수
환자 식별은 이름이 아니라 Patient ID

참고

Pianykh, O.S. Digital Imaging and Communications in Medicine (DICOM). Springer, 2008.
DICOM 공식: http://medical.nema.org

[디지털 하나로] 금융 서비스개발 수료 후기

odod00 — Sat, 20 Sep 2025 23:49:50 +0900

졸업유예를 하기로 결정하고 요놈의 공백기를 어떻게 보내야할까.. 라는 고민끝에

금융권 부트캠프에 지원했었고, 6개월 간 기나긴 대장정이 끝나 수료후기를 써본다.

신한DS, KB 등등 많은 금융권 부트캠프가 존재했고 내 상황과 시기상 알맞았던 '디지털 하나로'에 지원했다.

6개월 과정이고 수료했을때 최우수, 우수 수료생에 있어서 하나은행 서류면제 또는 코딩테스트 면제권이 주어진다

요즘 같은 시기에 이런 기회를 놓칠 수 없었고 사실상 혜택을 보고 지원한거나 다름 없다.

부트캠프 지원이라 그런지 생각했던 것보다 1차 서류는 무난하게 붙었다.

기초역량평가는 html, css, java, python 등이 나온다고 적혀있었지만 오히려 적혀있지 않았던 js 문제가 많이 나왔다.

html, css, java, python, js 에서 다룰 수 있는 헷갈릴 수 있는 문제들이랑 코테 3문제가 나왔고

생각했던 것보다 어려웠어서 합격할 수 있을지 불안했다...

그래도 합격! 막상 합격하고보니 지원자들 전부 실력적으로 비슷비슷하지 않았을까라는 생각이 들었다

너무 쫄지 않아도 됐을듯?

면접을 위해 하나은행 본사를 방문했다...

면접이라는걸 본지 너무 오래돼서 사시나무 떨듯 떨면서 봤던 면접..

스타벅스 쿠폰까지 야무지게 받고

내 프로젝트에 대한 질문, 기술적인 질문이 많이 나올거라 예상하고 봤던 면접인데

사실 기술질문은 아예 들어오지 않았다. 근데 다른 동기들은 기술질문도 있었다고 하니 면접관 바이 면접관이 아니었을까..

대충 기억해보자면

'하나은행은 영업점 근무가 1년에서 1년반정도 필수인데 이런 부분에 있어 괜찮은지?'

'6개월이 꽤 긴 시간인데 중간에 취업해서 나갈 생각이 있는지?'

'이 부트캠프를 통해 얻어가고 싶은부분이 무엇인지 (기술적인 성장 제외하고)'

'금융권 부트캠프를 지원한 이유가 무엇인지'

등등 이었고 막 어려운 질문은 아니었어서 그냥그냥 무난하게 대답했었던 것 같다.

원래는 6:1 면접이었는데 사람들이 많이 안와서 2:1 면접으로 진행했다.

그덕에 면접시간이 남들보다 2배는 길었던 것 같은데 대신 분위기는 조금 더 편했던 부분도 있었다.

다행히 합격!!!

설레는 마음으로 입학식도 들었었다..

중간에 2번의 프로젝트를 진행했다

2개월 반정도 js, ts, next.js 등을 배우고 1개월간 next.js 로 진행하는 풀스택 개발 프로젝트와

1개월 반정도 java, spring 등을배우고 1개월간 next.js 와 spring으로 진행하는 풀스택 개발 프로젝트

두개의 프로젝트를 진행했다.

해당 과정은 나한테 기술적인 성장에 있어서 매우 유익했던 것 같다. 원래 프론트엔드 쪽이기도 했고

백엔드보다는 프론트엔드를 좀 더 깊이 있게 배우는 느낌이라 내 커리어에는 잘 맞았던 교육이 아니었나 라고 생각했다.

하지만 나는 무조건 백엔드개발자!! 프론트는 필요없다 이런 사람은 안듣는게 좋을지도....

길고 길었던 6개월이 지나고 마지막 수료식..

이 과정을 다른 사람에게 추천하는가? 라고 물었을때

공백기를 줄이고 싶다, 금융권 스펙 한줄이라도 추가하고싶다. 라고 한다면 추천

아니면 추천하지 않을 것 같다

일단 6개월이라는 시간이 정말 너무 길다.

근데 과정 하나하나가 시간도 들고 노력도 드는 거라 취준을 병행하기도 힘들다.

그래도 다같이 으쌰으쌰해서 나름 자격증도 3개나 따고 유익했지만 당장 취업이 급한사람에게는 굳이.. 싶다.

그시간에 내 실력을 갈고닦는게 더 빠른 길일지도..

또 일반, 우수, 최우수를 가리는 기준이 정말 모호하다.

실력적으로 우수하거나 성실하거나 내가 얼마나 프로젝트를 열심히 임했는지는 중요하지 않다.

강사님에게 내가 얼마나 어필할 수 있는가, 얼마나 맘에 들었는가 밉보이지는 않았는가 가 더 중요한 과정이었던 것 같다.

프로젝트에 있어서도 공식적으로 정해진 기준이 아니라 강사의 선호도에 따라 팀별로 평가기준이 달라진다.

어떤 팀은 단순구현만으로 칭찬을 받는 반면 어떤 팀은 엄격한 평가기준으로 진행된다.

따지자면, 얼마든지 강사의 입맛에 따라 1, 2, 3등을 뒤바꿀 수 있다는 뜻이다.

이 모든 과정들을 견디고 사회생활을 배운다는 마음으로 열심히 어필한다면 좋은 성적을 받을 수 있다고 생각한다.

근데 실력으로 평가받고 공정하게 평가받고 싶은 분들은 듣지 않는 것을 추천한다.

모든 것이 끝나고 나니 깨달은 것은 내가 뒤에서 아무리 열심히 한다고 한들 아무도 알아주지 않는다.

본인 어필을 하고 내가 뭘했는지 얼마나 적극적인지 드러내야 알아준다는 것이다.

참 사회생활이 이런건가.. 라는 걸 깨달은 것도 배운거라면 배운거라고 볼 수 있을 것 같다.

그래도 과정에서 만난 동기들과도 너무 즐거운 시간을 보냈고 좋은 사람들을 얻었다는 점에서 후회되지는 않는 6개월이었던 것 같다.

이제는 진짜 취업시장으로 뛰어들어갈 일만 남았다... 아자잇!

[Next.js] Suspense

odod00 — Mon, 26 May 2025 17:46:29 +0900

Suspense가 무엇인고...?

Suspense란?

Suspense는 React 컴포넌트를 잠시멈추고 기다릴 수 있도록하는 기능이다.

로딩 중인 컴포넌트 대신 사용자에게 일시적인 UI(fallback)을 보여주고 준비가 되었을 때 실제 컴포넌트를 보여준다.

Suspense 기본 문법

import { Suspense } from 'react';

<Suspense fallback={<p>로딩 중...</p>}>
  <MyComponent />
</Suspense>

MyComponent 가 로드 중일 경우 대신 fallback{<p>로딩 중...</p>}을 대신 보여주고 로드가 완료되면 <MyComponent /> 로 대체된다.

Suspense가 사용되는 경우

1️⃣ React.lazy()로 지연 로딩을 하는 경우

import { Suspense, lazy } from 'react'

const LazyComponent = lazy(() => import('./HeavyComponent'))

function App() {
  return (
    <Suspense fallback={<p>Loading...</p>}>
      <LazyComponent />
    </Suspense>
  )
}

2️⃣ Next.js 의 use() 사용 시 (비동기)

Suspense를 명시하지 않고도 자동으로 사용할 수 있는 방법이 있다.

loading.tsx를 만들어 해당 loading을 사용할 page.tsx 와 같은 파일경로 내에 위치시키면 use()호출이 Promise Pending 상태일 때 loading.tsx를 자동으로 fallback으로 사용한다. => Suspense를 내부적으로 자동 사용한다.

app/
├─ dashboard/
│  ├─ page.tsx
│  ├─ loading.tsx

// page.tsx
export default function DashboardPage() {
  const data = use(fetchData())  // 서버에서 데이터 fetch
  return <div>{data.title}</div>
}

//loading.tsx
export default function Loading() {
  return <p>로딩 중입니다...</p>
}

3️⃣ RCC와 함께 쓰일 경우

React Client Component는 서버에서 렌더링 되지 않기 때문에 서버 컴포넌트가 Suspense로 감싸야한다.

Suspense로 감싸면 Client Component가 JS로 로딩될 때까지 fallback UI가 먼저 보여진다.

// layout.tsx
<Suspense fallback={<h1>로딩 중...</h1>}>
  <ReactClientComponent />
</Suspense>

[Next.js] Next.js 는 뭘까..?

odod00 — Mon, 26 May 2025 17:04:59 +0900

Next.js 란?

React 기반의 FullStack 웹 프레임워크이다. React 는 오직 화면을 그리는 렌더링 로직만 담당하기 때문에 라이브러리지만

Next.js 는 React 위에 서버 사이드 렌더링, 라우팅, 데이터 로딩, 정적 생성 등을 얹은 풀스택 도구를 제공하기 때문에 프레임워크이다.

특징

React 기반의 풀스택 프레임워크로 프론트와 백엔드를 통합해서 개발이 가능하다.
PageRouter 와 AppRouter 를 모두 지원한다.
Nested Layout (layout.tsx - page.tsx) 구성이 가능하다.
다양한 렌더링 방식을 지원한다. (SSG, CSR, SSR, ISR)
Tailwind, Typescript를 지원하며, Core Web Vitals에 최적화되어있다.

PageRouter vs AppRouter

PageRouter

pages/ 폴더 기반 라우팅 시스템이다.

파일 기반 라우팅 (pages/index.js, pages/about.js → /, /about) 이다.
getStaticProps, getServerSideProps, getInitialProps 등 데이터 페칭 메서드를 사용한다.
useEffect, useState 등 기본 React Hook 사용 가능하다.
Next.js 13 이전까지의 기본 방식이다.

파일구조

pages/
├── index.tsx       => /
├── about.tsx       => /about
└── blog/[id].tsx   => /blog/:id (동적 라우팅)

AppRouter

app/ 폴더 기반의 컴포넌트 중심 라우팅이며, 서버 컴포넌트를 지원한다.

기본이 Server Component 이다.
폴더 기반 중첩 라우팅(Nested Routing) 구조 이다.
layout.tsx, page.tsx, loading.tsx, error.tsx, template.tsx 등 구성요소를 명확하게 분리한다.
fetch()와 revalidate 등으로 데이터 처리를 한다. (getStaticProps, getServerSideProps는 사용 불가)
RSC (React Server Components) 기반으로 클라이언트에 불필요한 JS 전송을 최소화 한다.

app/
├── layout.tsx          ← 전체 레이아웃
├── page.tsx            ← /
├── about/
│   └── page.tsx        ← /about
├── blog/
│   ├── [id]/
│   │   └── page.tsx    ← /blog/:id
│   └── layout.tsx      ← /blog 관련 공통 레이아웃

❓ React Server Component란? (RSC)

React 컴포넌트를 서버에서 렌더링하고 HTML만 클라이언트에 보내는 방식이다.
브라우저에 JS 가 번들되지 않으며 더 가볍고 빠르다.
DB 쿼리, 파일 시스템 접근, API 호출 등 서버 전용 작업이 가능하다.
클라이언트와는 달리 useState, useEffect 같은 hook 사용이 불가능하다.
Next.js App Router에선 기본이 Server Component이다.
따라서 인터렉션이 필요없는 부분에서만 Server Component 를 사용하는 것이 가장 이상적이다.

❓ React Client Component란? (RCC)

컴포넌트 상단에 'use client' 선언이 필요하다.
클라이언트에서 실행되므로 Hook 사용과 이벤트 처리가 가능하다.
fs 접근이나 직접적인 DB fetch도 불가능하다.

cf. Server Action

클라이언트에서 서버 함수를 직접 호출할 수 있게 해주는 Next.js 기능이다.
POST API 를 따로 만들지 않고도 서버에서 실행되는 함수를 클라이언트에서 바로 호출하거나 <form>으로 전송할 수 있다.

// server action 예시

// app/actions.ts (Server Action)
'use server'

import { revalidatePath } from 'next/cache'

export async function addTodo(prevState: any, formData: FormData) {
  const title = formData.get('title') as string
  await db.todo.create({ data: { title } })
  revalidatePath('/')
}


// app/page.tsx (Server Component)
'use client'

import { useFormState } from 'react-dom'
import { addTodo } from './actions'

export default function Page() {
  const [state, formAction] = useFormState(addTodo, null)

  return (
    <form action={formAction}>
      <input type="text" name="title" />
      <button type="submit">추가</button>
    </form>
  )
}

Next.js 의 렌더링 방식 4가지

✔️ SSG (Static Site Generation)

정적페이지를 미리 생성하여, 빌드 시점에 HTML을 만들어 배포한다.
사용자 요청 시 HTML 파일을 즉시 응답할 수 있다.
빠르고 CDN 캐싱이 가능하고 성능과 SEO에 매우 유리하다.
PageRouter에서만 getStaticProps()를 사용할 수 있다.

❓ getStaticProps() 가 뭔데?
해당 페이지에서 사용할 데이터를 미리 가져와 HTML 에 반영하는 함수이다.
빠른 페이지 로딩과 SEO 최적화에 매우 유리하다.
대신 AppRouter 에서는 사용이 불가하다.

✔️ SSR (Server Side Rendering)

매 요청마다 서버에서 HTML을 생성한다.
항상 최신데이터를 보여줄 수 있다.
요청마다 서버 렌더링이 필요하므로, 상대적으로 느리다.
PageRouter에서만 gerServerSideProps()를 사용할 수 있다.

✔️ ISR (Incremental Static Regeneration)

정적페이지를 일정 주기마다 갱신한다.
SSG의 성능과 SSR의 최신성 장점을 절충하였다.
초기엔 SSG처럼 정적 생성하고 이후에는 revalidate 설정에 따라 주기적으로 새 HTML을 생성한다.
App Router에서는 fetch(..., { next: { revalidate: n } })로 설정한다.

✔️ CSR (Client Side Rendering)

브라우저에서 React가 JS를 통해 직접 렌더링한다.

HTML은 텅 빈 상태로 전달하고 자바스크립트로 렌더링을 진행한다.
클라이언트에서 fetch 요청하여 데이터를 처리한다.
초기 로딩은 느릴 수 있고, SEO에 불리하다.
대신 사용자 상호작용이 많은 부분에 적합하다.
'use client'로 클라이언트 컴포넌트를 명시해야한다.