DICOM은 왜 이런가요?

DICOM에서 정의한 specification들은 굉장히 복잡하며 구현하기도 쉽지 않습니다.

그렇다면 왜 healthcare 업계는 여전히 DICOM표준을 사용하고 있는 것일까요?

 

DICOM 데이터를 XML이나 JSON 형태로 구현하는 것도 충분히 가능한 일이며 더 나은 선택일 수 있습니다. 그런데도 여전히 DICOM이 정의한 데이터 형식을 버리지 못하는 이유는 DICOM표준의 Specification은 이미 너무나도 광범위 하게 사용되고 있기 때문입니다. 그 의미는 DICOM 표준에 따라 만들어진 병원 정보 시스템들 역시 이미 너무 많이 설치, 운영이 되고 있고 이 시스템들을 모두 한 번에 교체할 수가 없기 때문입니다. 또한 XML과 JSON 같은 대안이 대중화되기 훨씬 이전부터 DICOM 데이터의 형식이 이미 정해져 있었기 때문입니다.

그래서 영상을 획득하여 DICOM데이터를 생성하는 모든 시스템은 DICOM의 표준 데이터 형식을 지원해야 합니다.

 

DICOM Data의 일반적인 기본 구조를 살펴봅시다.

그림 - 3

 

언뜻 보기에 매우 잘 정리되고 깔끔한 구조라고 생각할 수 있습니다.

그런데 DICOM 파일이 영상을 포함하고 있고 그 영상을 다루어야 하는 개발자 입장에서 한 번 살펴보면 DICOM 파일과 다른 형태의 이미지 파일들(bmp, jpeg, png, tif)과 큰 차이점을 알 수가 있습니다.

 

일단 DICOM 데이터에서 영상 이미지를 나타내는 Pixel Data Tag는 (7FE0, 0010) 값을 가지며 이 값은 Pixel Data가 DICOM 데이터의 가장 마지막에 위치하게 된다는 의미 이기도 합니다.

 

문제는 일반 이미지 형식의 파일들은 Pixel data의 위치를 쉽게 찾아갈 수 있는 구조로 되어 있지만 DICOM 데이터는 Pixel Data의 위치를 쉽게 찾아갈 수가 없게 되어 있다는 것입니다.

 

DICOM은 영상을 읽고 쓰기에 좋은 구조인가?

DICOM데이터에서 Pixel data의 시작 위치를 찾기 위해서는 첫 Data Element 부터 읽고 Value Length를 읽은 후 다음 Date Element의 위치로 이동 후 다시 Value Length를 읽어서 이동하는 과정을 계속 반복해서 마지막 Pixel Data Element까지 찾아가야 합니다. 실제로 많은 3rd party library들이 이러한 방법으로 pixel data를 찾아 갑니다.

문제는 DICOM은 일반 이미지와는 달리 무수히 많은 Data Element를 가질 수 있다는 것입니다.

그 말은 Data Element가 많으면 많을수록 DICOM 데이터에서 Pixel data를 얻는 과정에 overhead가 생기게 된다는 의미입니다.

 

당연히 Data Element를 중간에 삽입하는 과정도 역시 overhead가 생기게 됩니다.

 

심지어 위 [그림 – 3]에서 보는 것과 같이 VR field는 Optional이라 Data Element의 크기도 항상 일정하지는 않습니다.

 

VR field 가 Optional이라는 의미는

예를 들어 DICOM Data를 전송하기 위해서는 송, 수신하는 Application Entity간에 negotiation 과정이 우선 필요한데 이 때에 서로 데이터 전송에 사용하는 transfer syntax 목록을 비교해 보고 일치하는 것을 찾는 단계가 있습니다. 이 경우에 만약 한 쪽이 implicit transfer syntax만 지원한다면

다른 한 쪽도 implicit transfer syntax를 지원해야 하며 이 경우에 DICOM데이터를 전송할 때에는 Data element의 VR 값을 제거하고 전송해야 합니다.

 

사실 이렇게 history가 오래된 specification들이 여전히 존재하기 때문에 DICOM 표준을 만족하는 시스템을 만드는 것은 어렵습니다.