![[PukiWiki]](image/../localimages/Atom.gif "[PukiWiki]")
Dicom tools †更新日2024-04-26 (金) 09:43:58
DCMTK-DICOMツールキット †Dicomファイルのタグを表示、変更など出来るコマンドツール ダウンロード †dcmtkの使い方 †設定 †
DCMDICTPATH=C:\usr\dcmtk-3.6.6-win64-dynamic\share\dcmtk\dicom.dic DCMTK=C:\usr\dcmtk-3.6.6-win64-dynamic\bin PATH=%PATH%;%DCMTK%;%DCMDICTPATH% タグの内容の変更例 †dcmodify -i (0010,0010)="DCMTK^TARO" XXX.dcm dcmodify -i (0010,0020)=5 XXX.dcm UIDの生成 †一般的なDICOMサーバやワークステーションはデータを重複させることを避けるように設定されています。この設定に利用されるのがUIDです。一枚一枚のDICOMファイルを世界に1つしかないデータとして一意性を持たせるためにこれらのUIDが付加されます。 dcmodify -gst -gse -gin xxx.dcm
参考 †一般社団法人 日本画像医療システム工業会【JIRA】 UIDのいろいろ †
(参考 https://www.konicaminolta.jp/healthcare/attached/pdf/P151YA111B_090627_Fix.pdf) 装置のサービスクラスがSCU側とSCP側両方にないとPACSデータは送れない。 (参考 https://www.jira-net.or.jp/dicom/file/dicom_2010+JSRT-SERIES-2-SOP.pdf)
アプリケーションコンテキスト名：基点となるUIDは米国商務省が米国内で使われている標準規格に付けた番号 SOP・SCP・SCUについて †サービス（機能）を利用する側をサービスクラスユーザ（SCU）、サービスを提供する側をサービスクラスプロバイダ（SCP）と言います。保存（Storage）というサービスを要求するのは通常モダリティで、提供するのは PACS などの保管装置です。PACS が CT と MR と CR の画像を保存できるのであれば、その PACS は 3 種類のオブジェクトに対してサービスできる、つまり３つの SOP クラスをサポートしていることになります
UID = <org root>.<suffix>
注：DICOMファイルで、（0002 0003）「メディアストレージSOPインスタンスUID」と（0008 0018）「SOPインスタンスUID」は同じ 注）Conquest Dicom サーバにデータの転送時の注意 †名前とIDを変更してConquestに転送しようしたら以下のように保存できない。 Studyインスタンスに一貫性がない [HOSPITAL1] ***Refused to enter inconsistent link PatientID into DICOMStudies:\ PatientID = '5' StudyInsta = '1.2.392.200036.9125.2.24963615215859.64966294736.5616347', Old='2711', Refused='5' ↑ ID 2711に同じ StudyInstanceUIDがあるので、保存できない。�� [HOSPITAL1] ***Error saving to SQL: 5\1.2.392.200036.9125.3.24963615215859.\ 64966300406.5792171_1001_001001_1616473545006b.dcm ↑ 上記のようなファイル名で保存しようとして�，里燭瓩任�なかった。 以下のコマンドでStudyInstanceUIDを変更する †dcmodify -gst -gse -gin * *はフォルダ内部をすべてのファイルを変更。この時変更される以下のフィリップスは同じになる 1.2.276.0.7230010.3.1.2.285293932.2544.1616474554.XXXXXX 注）このようにするとConquestに転送できるようになる。 例）以下のようになる そこで、StudyInstanceUID(0020,000d)がすべて異なるためこのような問題が生じる そこですべて同じStudyInstanceUID(0020,000d)に変更する。 Conquest Dicom Serverの患者表示氏名について †同じPatientIDでUpされた氏名は後からUpしたデータに書き換わる DB上のAccessTime †UNIXタイムスタンプで格納されている
mysql> SELECT FROM_UNIXTIME(1616461984); +---------------------------+ | FROM_UNIXTIME(1616461984) | +---------------------------+ | 2021-03-23 10:13:04 | +---------------------------+ 1 row in set (0.02 sec)
mysql> SELECT TIME_FORMAT(104937.977 , '%H:%i:%s'); +--------------------------------------+ | TIME_FORMAT(104937.977 , '%H:%i:%s') | +--------------------------------------+ | 10:49:37 | +--------------------------------------+ 1 row in set (0.03 sec) DICOMデータの一般的なファイル構造 †DICOMデータの中の１つの構造で、一般的には下に示すような構造になっている。
参考 †
Dicom Tips †異なるDicom画像を同じシリーズに入れるには †（確認は同一Study場合のみ、異なるStudyでは他の条件も必要かも→不明） Series Instance UID (0020,000e) ←変更 Series Number (0020,0011) ←この項目は必須ではないが同じにしたほうが良い 上記２つの項目が同じならば、同一シリーズに複数のイメージが入る Instance Number (0020,0013)が同一でも問題ないようだが変えてほうがわかりやすい。 Kpacs, Conquest DicomServerで確認がとれた KpacsでDicomファイル名を変更する †Media Storage SOP Instance UID(0002, 0003) を変更すると別シリーズとして取り扱えそう ユニークするとKPACSに同じ画像を別画像扱いでインポート出来る DICOMデータの患者の変更方法 †
を変更すると別患者として表示する。 一つのDICOM画像をコピーしてのDICOMタグを変更してどのようになるか試してみた †Kpacs, Conquest DicomServerで確認 元のDICOM画像
シリーズ内に別イメージにする †
上記の2項目を変更すると別イメージとして管理される
別シリーズのイメージする †
上記の３項目を変更すると別シリーズでのイメージになる。
別患者のイメージする †
を変更する
Conquest Dicom Server のDICOM File名 †(Series Instance UID)_(Series Number)_(Instance Number)_(ファイル作成日時)[序数].dcm
↑ ↑ ↑ ↑
4桁 0補完 6桁 0補完 10桁 16進
1.2.392.200036.9125.3.24963615215859.64894496856.5916455_1001_001001_1707183685001c.dcm
phpの以下のプログラムで確認
#! /usr/bin/php
<?php
print date("Y-m-d H:i:s", "1707183685");
print "\n";
?>
$ ./test.php 2024-02-06 10:41:25 Fujifilmのdicomサーバのファイル名 †以前(2018年まで)使用していたFujifileのDicomサーバのファイル名 Media Storage SOP Instance UID(0002, 0003) が主ファイル名になっていた |
別患者.png 15件
[詳細]
別シリーズ2-a.png 15件
[詳細]
別シリーズ1-a.png 14件
[詳細]
別イメージ2.png 16件
[詳細]
別イメージ1.png 17件
[詳細]
ORG0.png 13件
[詳細]
ORG.png 15件
[詳細]
