의료기관에서 촬영된 한 건의 CT 검사에는 수십에서 수백 장의 영상이 포함된다.
하지만 이 영상들은 단순히 파일 여러 개로 저장되는 것이 아니라,
환자 정보부터 시작해 검사 단위, 촬영 시리즈, 개별 이미지까지 명확한 계층 구조로 정리된다.
이 구조를 제대로 이해하지 못하면 영상의 연관성을 파악하지 못하거나, AI 학습용 데이터셋 구성에서 오류가 발생할 수 있다.
DICOM은 이 문제를 해결하기 위해 **4단계 계층 구조(Patient–Study–Series–Instance)**를 따르며, 각 단계는 고유한 UID를 통해 서로 연결된다.
이번 글에서는 이 구조가 실제 DICOM 데이터 안에서 어떻게 구현되는지, 각 계층이 어떤 정보를 포함하고 어떤 역할을 하는지를 쉽게 설명한다.
1. DICOM의 계층 구조 요약
DICOM 데이터는 다음과 같은 4단계로 계층화되어 있다:
[1] Patient
└── [2] Study
└── [3] Series
└── [4] Instance (Image)
계층 | 설명 | 대표 태그 |
Patient | 환자 단위 정보 | (0010,0010), (0010,0020) |
Study | 하나의 검사 단위 | (0020,000D), (0008,0020) |
Series | 동일 조건으로 연속 촬영된 영상 묶음 | (0020,000E), (0008,0060) |
Instance | 실제 DICOM 이미지 한 장 | (0008,0018), (7FE0,0010) |
1-1. Patient – 환자 단위
가장 상위 계층은 **환자(Patient)**이며,
해당 환자가 병원에서 어떤 검사들을 받았는지의 시작점이 된다.
대표 태그:
태그 | 설명 |
(0010,0010) | Patient’s Name (환자 이름) |
(0010,0020) | Patient ID (환자 식별자) |
(0010,0030) | Patient’s Birth Date |
(0010,0040) | Patient’s Sex |
1-2. Study – 검사 단위
한 번의 진료 또는 검사를 나타낸다. 예를 들어 2025년 6월 10일 오전에 촬영한 복부 CT 전체가 하나의 Study가 된다.
대표 태그:
태그 | 설명 |
(0020,000D) | Study Instance UID (검사 고유 ID) |
(0008,0020) | Study Date |
(0008,0030) | Study Time |
(0008,1030) | Study Description |
📌 PACS에서 영상 목록을 조회하면, Study 단위로 목록이 묶여서 보인다.
1-3. Series – 동일 설정 영상 묶음
Study 안에는 여러 개의 Series가 있을 수 있다.
예: 복부 CT를 찍을 때, 조영제 주입 전 / 후로 나뉜 2개의 시리즈가 있을 수 있다.
대표 태그:
태그 | 설명 |
(0020,000E) | Series Instance UID |
(0008,0060) | Modality (CT, MR 등) |
(0020,0011) | Series Number |
(0008,103E) | Series Description |
📌 시리즈마다 촬영 방식, 파라미터, 장비 조건이 다를 수 있다.
1-4. Instance – 실제 DICOM 이미지
가장 하위 계층은 하나의 **DICOM 파일(Image Instance)**이다.
보통 1개의 Instance = 1장의 CT 단면 이미지라고 보면 된다.
대표 태그:
태그 | 설명 |
(0008,0018) | SOP Instance UID (파일 고유 ID) |
(7FE0,0010) | Pixel Data (이미지 바이너리 데이터) |
(0020,0013) | Instance Number (순서) |
(0028,0010/0011) | Rows, Columns (이미지 해상도) |
📌 하나의 Series에 수십~수백 개의 Instance가 존재할 수 있다.
2. 예시로 보는 구조
예를 들어, 다음은 한 환자가 복부 CT를 받은 경우의 구조다.
Patient: 홍길동 (ID: P12345)
└─ Study: 2025-07-25 복부 CT 검사 (UID: 1.2.3...)
├─ Series 1: 조영제 없음 (UID: 1.2.3.1...)
│ ├─ Instance 1 (SOP UID: 1.2.3.1.1)
│ ├─ Instance 2 (SOP UID: 1.2.3.1.2)
│ └─ ...
└─ Series 2: 조영제 주입 후 (UID: 1.2.3.2...)
├─ Instance 1 (SOP UID: 1.2.3.2.1)
├─ Instance 2 (SOP UID: 1.2.3.2.2)
└─ ...
3. 실무 적용 포인트
작업 | 계층 활용법 |
AI 학습 데이터 구성 | Study 단위로 묶고, Instance 정렬하여 이미지 스택 생성 |
PACS에서 영상 조회 | Study → Series → Instance 순으로 탐색 |
환자 데이터 익명화 | Patient 계층의 태그만 제거하면 Study, Series는 유지 |
영상 필터링 | Series Description, Modality, Instance Number 기준으로 필터링 가능 |
4. 계층 간 UID 연결 구조
계층 | UID 태그 |
Study | (0020,000D) |
Series | (0020,000E) |
Instance | (0008,0018) |
👉 모든 파일은 이 UID로 계층적으로 연결되어 있어야 PACS에서 정확한 구조로 인식된다.
결론
DICOM은 단순한 이미지 저장 포맷이 아니라, 환자 → 검사 → 시리즈 → 이미지 파일까지 연결되는 정교한 계층 구조를 가지고 있다.
이 구조는 영상 파일을 올바르게 분류하고 해석하며, PACS 연동, AI 학습, 익명화 처리, 진단 시스템 통합 등 모든 실무 영역에서 기본이 되는 개념이다.
다음 편에서는 이 구조에 저장된 구체적인 정보 중, 날짜, 시간, 성별, 환자 ID와 같은 데이터의 저장 방식과 포맷을 설명할 예정이다.
'개발 > DICOM 이야기' 카테고리의 다른 글
13. DICOM 이미지 형식(Pixel Data)과 압축 방식 (0) | 2025.07.29 |
---|---|
12. DICOM에서의 날짜, 시간, 성별, 환자 ID 처리 방식 (2) | 2025.07.29 |
10. DICOM 파일 내부 구조 분석 예제 (2) | 2025.07.29 |
09. DICOM 헤더 정보 해석하기 – 주요 태그 설명 (0) | 2025.07.29 |
08. Little Endian vs Big Endian – DICOM 데이터의 바이트 순서 (0) | 2025.07.29 |