[DICOM] DICOM이란 무엇인가? — 데이터 표현(VR)까지

어쩌다 의료영상 데이터를 계속 접하고 개발하는 일을 하다보니..
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계층

까지 정리한다.

---

핵심 정리

1. DICOM = 의료영상 통신/저장/표시 종합 프로토콜 (단순 파일 포맷 X)
2. PACS = DICOM으로 작동하는 영상 시스템
3. 객체지향 모델: IOD = 객체 + 속성, 통신은 SCU↔SCP
4. 통신 단위는 AE, 서비스+객체 쌍은 SOP
5. Conformance Statement가 모든 DICOM 작업의 출발점
6. 모든 데이터는 27가지 VR 중 하나로 표현
7. 기본 Endian은 Little Endian, 모든 길이는 짝수
8. 환자 식별은 이름이 아니라 Patient ID

---

참고

• Pianykh, O.S. Digital Imaging and Communications in Medicine (DICOM). Springer, 2008.
• DICOM 공식: http://medical.nema.org