DICOM을 다루다보면 Patient, Study, Series, Image라는 말을 많이 보게 됩니다.

아무래도 의료IT쪽에 익숙치 않다 보면 생소할 수도 있는 말인데요.

간단하게나마 위 용어들을 정리 해보려고 합니다.

Patient는 말그대로 환자를 나타내고요, Patient와 관련된 정보로는 Patient Name(0010,0010), Patient Sex(0010,0040), Age, …등과

같이 다양한 정보가 있습니다. Patient Sex(0010,0040)는 보통 사람일경우 Male, Female, Other 이렇게 구분을 많이 하고요, 실제 Tag에

Male, Female 이렇게 저장하는 경우도 있지만 보통은 M, F, O 이렇게 한글자만 저장합니다.

Patient를 구분하는 고유 번호는 Patient ID(0010,0020)이며 병원내부에서 사용하는 환자번호를 사용합니다.

Patient Name(0010,0010) Tag를 살펴보시면 VR이 PN으로 Person Name을 의미합니다. PN에 대한 자세한 설명은

DICOM Standard Part.5:Data Structure and Encoding을 한번 읽어보시기 바랍니다.

전에 언급했던 Patient First, Middle, Last Name의 구분자 code(‘^’)라던가 한글이름, 영어이름 혼합 사용법 등이 명시되어 있습니다.

한가지 Tip은 Konica CR초기 버전에서 DICOM Worklist시 영어이름은 보이지만 한글 이름으로만 보이지 않는경우

“English Name=한글이름” 형식으로 저장하시면 됩니다.혹 “=한글이름”이렇게만 입력하셔도 됩니다.

그리고 Patient Age는 Tag가 포함되지 않는 경우가 많으며, 대신 Patient BirthDate(0010,0030)를 삽입합니다. 환자의 나이는 BirthDate

만으로도 촬영시 나이, 현재 나이 등을 쉽게 계산해 낼수 있기 때문이죠.

이런 Patient에는 1개 혹은 그 이상의 Study를 가지게 됩니다. 그리고 하나의 Study는 한개 혹은 그이상의 Seires를 가지게 되고요.

Series도 1개 혹은 그 이상의 Image를 가지게 됩니다. 여기서 Image를 간혹 Instance라는 용어를 사용하기도 합니다.

아래 그림을 참고하시면 이해하는데 도움이 될 듯 합니다.

여기서 Series의 개념이 조금 이해하기 어려울 수 있습니다.

보통적으로 CT촬영을 한다고 했을때 조영제를 투약후 촬영하는 경우가 있습니다. 이때 조영제를 투약전에 한번 검사를 수행하고,

다시 조영제를 투약후 다시 재검사를 수행하게되면, CT촬영이라는 검사 자체가 1개의 Study가 되고, 조영제 투약전 CT촬영, 조영제

투약후 CT촬영 이렇게 2개의 Series가 생성되게 됩니다.

그렇다고 반드시 Series의 촬영장비(Modality)가 동일한 것은 아닙니다. 간혹 PET-CT촬영을 하는경우 한 환자에게 한번의 검사를 수행시

한번은 PET을 촬영하여 Series No.1로 저장하고 CT를 촬영하여 Series No.2로 저장하게 됩니다. 이렇게 되면 Seires No.1의 Modality는

PET이며, Sereis No.2의 Modality는 CT가 되게 됩니다. 하지만 Study의 Modalty는 PET-CT가 되겠네요.

이런식으로 개념적으로 Patient, Study, Series, Image를 구분하게 됩니다.

이번에 말씀드릴 내용은 SOP Class UID입니다.

하나의 DICOM파일이 있는경우 각각의 파일이 초음파 영상을 담고있는 DICOM인지, 내시경영상용 DICOM인지,

MR,CT용 인지 등등 각각의 DICOM이 담고있는 데이터의 종류(Class)를 나타내는 값이 있습니다.

그런 값을 UID형태로 저장되어 있는 Tag가 SOP Class UID(0008,1150) 입니다.

보통 아래와 같은 값을 가집니다.

(전체 목록은 DICOM Standard Part4.Service Class Specifications 를 참조)

즉 SOP Class UID(0008,1150) Tag의 값이 1.2.840.10008.5.1.4.1.1.1 이라는 값을 가진다면 이 DICOM 파일은 CR영상을

담고있다라고 인식하게 됩니다.

그럼 각 CR영상에서 필요한 정보를 해당 DICOM File에서 찾아 사용자에게 추가적인 정보를 얻을 수 있는겁니다.

DICOM에서는 SOP Class UID(0008,1150)과 같이 UID라는 값을 많이 사용하게 됩니다.

이기회에 하나씩 설명 드리죠.

SOP Instance UID(0008,0018)
DICOM 영상에서 가장 많이 보기도 하고 가장 중요한 Tag이기도 합니다. 즉 DICOM영상을 고유하게 해주는 식별 번호입니다.

해당 번호는 전세계 모든 영상과 구분되는 고유번호로 할당 되어야 합니다.

이 UID는 전세계 모든 영상과 구분되는 고유번호로 할당 되어야 합니다. 즉 DICOM을 만드는 입장 예를들어 의료영상 장비라던가

Gateway라 던가 새로운 DICOM 파일을 생성하는 소프트웨어에서 고유하게 이번호를 할당하여 제작하게 됩니다.

그렇다고 자기 하고싶은데로 막 만들지는 않고 나름 규칙이 있습니다.

보통 형태는 1.2.410.301000.1.2.101.2010101112.123.1212 이런 형태를 취합니다.

앞에 1.2 는 ISO 표준이라는 의미이며, 410은 ISO 표준 국가 코드 입니다. 미국은 840 입니다. 그래서 대부분의 Class UID, Transfer

Syntax 의 UID에 1.2.840 으로 시작하는 이유가 미국에서 제정된 UID값이기에 그런겁니다.

다음은 각 국가에서 DICOM UID 관련 인증 발급 기관에서 발급해 주는 번호 입니다. 저희는 과천에 기술 표준원인가??

오래되서 가물가물 하네요. 암튼 과천 정부 한 부서에서 발급해 줍니다. 수수료는 없구요.

즉 1.2.410.301000 까지는 거의 나름대로 규칙을 지켜주게 되구요. 그 이후 나머지는 각 회사에서 알아서 고유하게 UID를 생성하면

됩니다.

보통 제품의종류, 버전, 내부 개발구분코드와 같이 추후 유지보수가 용이하도록 나름 의미를 부여하게 됩니다.

여기에 SOP Instance UID(0008,0018) 는 전세계 고유한 번호로 생성되어야 하기에 Study Date와 Study Time을 포함하여

생성하는 경우가 많이 있습니다.

Study Instance UID(0020,000D) , Series Instance UID(0020,000E)
Study Instance UID(0020,000D)는 Study를 구분해주는 UID이며 Series Instance UID(0020,000E)는 Series를 구분해주는 UID입니다.

Series라는게 특정 Study에 종속되어 있다 보니 Series Instance UID(0020,000E) 생성시 보통 (Study Instance UID(0020,000D) +

Series Number 형식을 많이 사용합니다.

   Tip) 각 UID 생성시에 구분자 "." 뒤에 반드시 1~9 사이의 값이와야 합니다. 즉 0 이 오면 안됩니다.
   예를들어 Study Time을 UID에 포함시켜 오전 9시 10분 12초를 포함하여 만드는경우 
   1.2.410.301000.1.2.101.091012.1 와 같은형태로 만들면 안됩니다. 대신 0을 뺀 1.2.410.301000.1.2.101.91012.1 과
   같은 형태로 만들어야 합니다. 왜 그럴까요? 0을 붙여서 만들어도 다른 PACS나 대부분의 장비에서 인식하는데 별
   문제 없습니다. 대신 Global 업체의 PACS나 장비에서 오류가 발생됩니다. 
   애초에 넣지 말고 생성하세요. 그래야 정신 건강에 좋습니다. 

지금까지 DICOM File을 구성하는 Element에 대해 설명 했습니다.

그럼 실제 초음파 or 내시경 DICOM과 같이 이미지가 포함된 파일은 어떻게 저장될까요?

즉, 이미지 파일은 어디 저장 될까요?

DICOM파일은 이미지 자체도 Element로 저장됩니다. 바로 Pixel Data(7FE0,0010) Tag에 저장됩니다.

여기에 저장되는 이미지의 형태는 다른 Tag를 통해 달라지게 됩니다.

여기서 부터 많이 복잡합니다. ㅡㅡ; 하나씩 보죠.

가장 먼저 압축된 영상과 압축되지 않은 영상으로 구분됩니다.

압축된 영상은 DICOM에서 지원하는 압축 알고리즘이 존재하며 그 종류는 다음과 같습니다.

실제로는 이거보다 더 많은 종류가 있지만 여기에는 몇개만 올려 놓았습니다. 전체는 DICOM Standard Part6.에서 확인하세요.

즉, 해당 DICOM영상의 압축 종류는 Transfer Syntax(0020,0010) Tag의 UID값으로 판단하게 됩니다.

만약 Transfer Syntax값이 “1.2.840.10008.1.2.4.50”인경우 해당 DICOM 영상은 Jpeg으로 압축되어 있다는 의미 입니다.

즉 Pixel Data(7FE0,0010) Tag에는 Jpeg으로 압축된 데이터가 저장되어 있습니다.

Bitmap형식으로 저장된것과 다르게 Pixel Data가 압축된 경우에는 해당 Header까지 같이 저장되어 있기에

Pixel Data만을 jpeg 파일로 저장 후에 이미지 뷰어를 통해 보게되면 실제 이미지를 볼수 있습니다.

한가지 Tip 입니다.^^

하지만 “1.2.840.10008.1.2.1” or “1.2.840.10008.1.2”와 같이 Raw Bitmap 형태로 저장되는 경우에는 Pixel Data(7FE0,0010)에

Header가 포함되어 있지 않아 다른 Element의 Tag를 이용하여 Image화 시킬 수 있습니다.

우선 Raw Bitmap 형태의 Data인 경우 Photometric Interpretation(0028,0004) Tag를 보시면,

MONOCHROM1, MONOCHROM2인경우는 Gray scale 이미지를 뜻합니다. 즉 흑백 영상이죠.

PALETTE_COLOR인경우 Palette를 가지는 Bitmap을 뜻하죠. 그럼 보통 Palette의 크기는 256개로 1byte크기이기에

8bit Raw bitmap 데이터가 저장되어 있습니다.

한가지 Tip은 보통 PALETTE_COLOR로 설정되어 있더라도 Red Palette Color Lookup Table Data(0028,1201)과 같은

Tag가 없는경우가 많습니다. 이런경우는 기본값 즉 Gray scale형태로 표현하면 됩니다.

만약 Red Palette Color Lookup Table Data(0028,1201)에 Data가 존재하는 경우는 Red Palette Color Lookup Table

Descriptor(0028,1101)을 참조하여 Palette를 해석하면 됩니다.

RGB인경우는 r,g,b 1byte씩 총 24bit Color Bitmap이 저장되어 있습니다.

기타 추가적인 Photometric은 DICOM Standard Part3. C.7.6.3.1.2 Photometric Interpretation에서 확인하세요.

영상이 MONOCHROM1, MONOCHROM2인 경우 Bits Stored(0028,0101) Tag가 보통 8, 12, 16 값을 가지게 됩니다.

즉 흑백영상의 bit 수를 의미하죠. 8bit grayscale은 일반적으로 알고있는 흑백 bitmap이미지이고요, 12bit grayscale

영상은 주로 CT영상에서 사용하는 의료에서 많이쓰는 Bitmap형식 입니다. Pixel 크기가 12bit 이기에 8bit는 어둡고

밝은 정도가 256단계 이지만 12bit는 4096 단계로 더 해상도가 높게 저장을 하지요. 하지만 추후 CT는 Pixel에 밝기라는

값의 형태라기보다는 HU(Hounsfiled Uniit)이라는 형태로 저장하기에 조금 다르긴 합니다.

16bit는 주로 MR혹은 Nuclear Imaging, 즉 핵의학 영상에서 주로 사용 됩니다.

여기서 MONOCHROM1, MONOCHROM2차이는 단지 Pixel값이 0인경우 흰색이냐 검정색이냐 차이만 다른겁니다.

간혹 영상을 Display했는데 반전된 영상이 나왔다면 MONOCHROM해석이 잘못된것일 확률이 높습니다.

다음은 Length 입니다.

여기서 Length는 Value의 길이를 byte 단위로 표시한 것입니다. Length 자체의 Byte길이는 4byte이고요.

그리고 실제 데이터는 Length뒤에 Length byte 만큼 위치하게 됩니다.

그럼 지금까지 Element구조를 아래와 같은 테이블로 나타냅니다. (DICOM Stadard에서 참조)

그런데 여기서 테이블 이름을 자세히 보시면 With Explit이라는 문구가 눈에 들어옵니다.

Explit이 있다면 반대인 Implicit이 존재하겠네요.

실제 Implicit 테이블 구조 입니다.

두 테이블의 차이점을 비교해보면 implicit인경우 VR이 빠져있습니다.

즉 Explicit은 명시적으로 File로 저장시에 VR을 포함하여 저장하고, Implicit인경우에는 VR을 빼고 저장합니다.

반대로 File을 읽을 때도 마찬가지고요.

그럼 만약 파일을 읽을 때 VR이 없으면 해당 Element의 Value가 나이 인지 날짜인지 데이터 타입이 뭔지 어찌 알까요?

그건 어차피 각 Element Tag에 대한 의미가 이미 정의가 되어 있기에 각 Element의 VR 종류도 정해져 있어서

뺀상태로 저장하는 겁니다. 아마 제 개인적인 생각으로는 파일저장 or DICOM 통신시에 데이터를 조금이라도 줄여보려는

목적인듯한데.. 실제 필드에서는 이런것 때문에 간혹 문제가 생기는 경우가 있습니다.
(각 Element Tag의 VR값은 DICOM Standard Part6. Data Dictionary 에서 확인 할 수 있습니다.)

한단계 더 전으로 가면 그럼 이 파일이 Explicit VR인지 Implicit VR인지 어떻게 구분할까요?

DICOM Tag중 Transfer Syntax UID(0020,0010)를 보고 판단 합니다.

위 표가 Transfer Syntax가 가지는 UID값의 종류입니다.
(전체는 DICOM Standard Part6. Data Dictionary에서 확인하세요)

해당 DICOM파일의 Transfer Syntax UID값이 1.2.840.10008.1.2 인경우 이 파일은 Implicit VR 형태의 파일이라는 의미입니다.

추가적으로 Little Endian 인지 Big Endian인지도 구분합니다.

간혹 GE장비 같이 Global 장비와 연동시 Linux Server를 사용하는경우 Big Endian을 사용하는경우가 아주 간혹 있습니다.

이런식으로 Little Endian과 Big Endian이 서로 호환되지 않아 문제가 생기면 CT영상같은경우 Pixel Data가 2byte이기에

서로 다른값으로 해석되게 되어 영상이 이상하게 깨지면서 하얗게 표시되거낭 영상이 깨지면서 너무 어둡게 표시되는 경우

Endian쪽을 의심해 볼만 합니다.

전 초기 GE PACS와 연동시 붉은색 계통의 내시경 영상이 푸른색 계통의 줄무늬가 가있는 형태의 영상으로 보이는

난감한 문제가 있었습니다.

결국 Pixel Data를 확인해 보니 byte의 순서가 다르게 저장되어 발생되는 거였죠. 근데 왜 그렇게 저장되는지는 원인을

찾을 수 없어서 무식하게 내부적으로 Byte Endian을 강제 변화 후 전송하는 방식으로 문제를 해결한 적이 있습니다.

한 참을 지난 후에야 근본적인 원인을 파악하여 해결 하였던 기억이 나네요.

그냥 제 개인적인 경험담 이었습니다.

다음은 VR입니다. VR은 Value Refresentation의 약자로 즉 Element가 가지고 있는 Data(Value)가 어떤형태인지를 나타냅니다.

단지 Programming에서 정수형, 문자열, 소수점형 처럼 구분하지 않고 의미로 구분합니다.

예를들어, 고유이름, 정수형 문자, 소수점형 문자, 날짜, 시간, 나이…. 와 같은 형태를 가집니다.

DICOM Standard Part5. Data Structures and Encoding에 보시면 모든 종류의 VR이 나와있습니다.

대충 훓터 보면 총 20~30개의 VR이 존재하며 VR Name이 AS인경우 Age String을 의미합니다.

즉 VR이 AS인 Element에 Value값이 “32”라는 문자열이 저장되어 있다면 32세를 의미한다는 겁니다.

실제로는 AS는 나이를 표현할때 숫자를 적고 다음 y를 같이 적어줍니다.즉 32세라면 “32y”라는 형식으로

저장합니다. 여기서 y는 year를 의미하죠. 혹 아기의 나이를 적을때는 32개월인경우 Month의 약자인 “32m”이라고

적고, “32d”는 Day의 약자로 32일을 의미합니다.

아래의 그림과 같이 DICOM Standard Part5 에 보시면 각 VR값의 Value가 가질수 있는 Data의 범위, byte수 및 Max길이등등

자세히 나와있으니 참고하세요.

이 블로그 자체가 정리 및 기록의 목적을 두기에 이 아래부분은 제가 나름 생각나는데로 두서 없이 적은 내용이니

굳이 보시지 않으셔도 됩니다.

—————— 정 리 ————————
각 Value가 String형식중에 Item이 여러개인경우 Backslash (“\”)로 구분한다.
UID VR은 고유값을 의미하며, SOP Instance UID, Study Instance UID와 같은 값에서 사용.
여기서 구분자(.)의 다음 값은 ‘0’을 가지면 안됨
Date 같은 VR은 2010년 03월 02일시 “20100302”와 같이 다 붙여서 사용하고 03과 같이 총 8자리의 자리수를 맞춰주자
Person Name에서 구분자로 “^”(5EH)를 사용하자. space를 사용해도 되긴 함. 하지만 US장비와 같이
DICOM QR측에서 인식하지 못하는 경우가 자주 발생.

DICOM File은 확장자로 일반적으로 DCM, DIC 두가지를 사용합니다.

즉, 파일이름이 test.dcm 또는 test.dic는 일반적으로 DICOM파일을 의미합니다.

하지만 실제로 Programming에서 DICOM파일 여부는 파일내부에 Header를 보고 DICOM파일 여부를 확인합니다.
(이건 다시 자세히 설명 드리죠)

dic확장자는 좀 예전에 초기에 사용했었고, 요즘 대부분은 dcm을 사용하니 참고로만 알고 계세요.

그럼 DICOM파일의 안을 들여다 보면 우선 아래와 같은 구조를 가지고 있습니다.

DICOM파일은 Element라는 단위로 구성되어있습니다. 그림에서 보는바와 같이 많은 Element들이 모여 하나의

DICOM파일을 구성합니다.

다음은 Element 구조입니다.

하나씩 살펴보죠.

Tag는 이 Element를 구분하는 이름표 입니다. 쉽게 유니클로 같은 매장에서 각 옷의 종류를 구분하기위해서 붙여 놓은 상표 태그로

생각하 시면 되겠네요.

이 Tag는 다시 Group Tag와 Element Tag로 구분되죠.

Group Tag는 Tag가 너무 많다보니 비슷한 종류를 묶어 Group화 시켜 놓은겁니다. 예를들어 환자와 관련된 Tag, Image와 관련된

Tag, 초음파 검사와 관련된 Tag등을 Group화 한것이죠.

다음 Element Tag는 그 Group에서 고유하게 값을 가져서 다른 Tag와 구분하게 됩니다.

이런 Group Tag와 Element Tag는 각각 2byte씩의 크기를 가지며 보통 아래형식으로 표기합니다.

0010, 0020
여기서 의미는 0010이 Group Tag 입니다. 0010 Group은 Patient(환자)와 관련된 Group 을 뜻합니다.

0010, 0020은 Patient ID를 의미합니다.

각 Tag는 DICOM Standard라는 표준집에 정의되어 있습니다. 즉 0010,0020 Tag를 가진 Element는

Patient ID를 뜻하는 Element
라고 이해하게 되는겁니다.

Group Tag(2byte) + Element Tag (2byte) 가 총 4byte이기에 Element가 가질수 있는 Tag는

0000, 0000 ~ FFFF, FFFF 까지의 Tag를 가지게 됩니다.

추가적으로 DICOM Standard에서 정의된 Tag는 Group Tag값이 짝수를 가지며 (이걸 Public Tag라고 구분지어 얘기합니다.)

개별적으로 작성한 Tag는 Group Tag가 홀수 입니다.(이걸 Private Tag라고 구분합니다.)

이런 모든 Tag의 정의는 DICOM Standard Part3. Information Object Definitions를 참조하시던가,

DICOM Standard Part 6.Data Dictionanry를 참조하세요.

각 Tag에 대한 구체적인 설명 및 사용법은 Part3를 보시고, 일반적인 Tag의 제목 및 형식 같은 구조만

보시길 원하시면 Part.6를 참조하시면 됩니다.

또한, Element와 관련된 자세한 설명은 DICOM Standard Part 5. Data Structures and Encoding을 참조하세요.

항상 어느 주제를 가지고 말하다보면 첫 마디에 “OOOO란?” 식의 글이 나타납니다.

저도 어쩔수 없이 첫 시작은 “DICOM이란?” 주제를 가지고 시작 하려고 합니다.

우선 DICOM이란 약자입니다. 이 Full Name이 뭘까요? 아래와 같습니다.

• Digital Imaging and Communications in Medicine

하나씩 풀어 볼까요?

Digital Imaging은 영상을 뜻합니다. 맨 뒤에 In Medicine이 붙어 있기에 의료영상이라는

분류를 하게 됩니다. 의료영상이라는것은 의료장비에서 나오는 이미지 데이터를 뜻하지요.

의료 장비는 CT, MR, 내시경, 초음파… 등등 영상이 나오는 모든 장비를 뜻합니다.

새로 개발되는 의료장비인 PET 혹은 심지어 적외선 카메라도 의료장비로 사용됩니다. 즉 적외선 카메라로 획득된 영상을

의료 영상 이라고 할 수 있습니다.

다음 Digital Imaging에는 저장이라는 의미가 함축되어 있습니다. 의료영상을 저장 하는 방식 이라고 생각하면 쉬울까요?

아니면 의료영상을 저장하는 파일형식 이라고 생각해도 이해하기 쉽겠네요.

다음 Communications는 통신입니다. 즉 의료영상의 통신을 의미하죠. 여기에 DICOM이 왜 사용하는지 궁극적인

목적이라고 할 수 있습니다.

DICOM의 사용목적을 대충 자료를 찾아보면

이 기종간의 의료영상 장비간의 영상데이터의 자료교환을 위한 표준
이런식으로 얘기를 하죠.

즉 이말은 전세계에 CT, MR등 많은 의료장비들이 있고 또한 각 CT장비에도 Toshiba, GE, Simense와 같이

많은 업체들이 있습니다. 그럼 이런 모든 업체들의 장비들끼리 데이터를 공유한다면 하나의 규칙이 필요하게 됩니다.

보통 사진 찍는 카메라가 보통 JPEG이라는 표준으로 사용하듯이 의료장비들은 DICOM이라는 표준을 따르는 것이지요.

그런데 여기서 JPEG과 다른점은 DICOM은 마지막 통신에 대한 규칙도 정의되어 있다는 겁니다. 장비와 장비끼리

혹은 장비와 PACS끼리 이 영상데이터를 주고 받는데 필요한 규칙까지도 같이 정의 되어있는겁니다.

그래서 DICOM은 아래처럼 나타낼 수도 있겠네요.

DICOM 파일 포맷 + DICOM 통신 프로토콜

앞으로 정리 할 내용도 먼저 DICOM 파일 포맷에 대해 설명하고, DICOM 통신에 대해서도 정리하고자 합니다.