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) — 저자 추천
'Dev > DICOM' 카테고리의 다른 글
| [DICOM] 파일 포맷, 보안/익명화, DICOMweb, Orthanc 실전 (0) | 2026.06.10 |
|---|---|
| [DICOM] DICOM Association — PACS 통신 디버깅이 일어나는 곳 (0) | 2026.06.10 |
| [DICOM] DICOM 통신의 시작 — C-Echo, C-Store, C-Find (0) | 2026.06.10 |
| [DICOM] Patient/Study/Series/Image 4계층 + IOD — DICOM 정보 모델의 완성 (0) | 2026.06.02 |
| [DICOM] Tag, Data Dictionary, Object Encoding — DICOM 데이터를 바이트로 푸는 법 (0) | 2026.05.27 |