DICOM/UID

提供:メディカルウェア
ナビゲーションに移動 検索に移動

DICOMにおけるUID(ゆにーくあいでぃー,unique identifier)とは、DICOM製品の製造国や製造メーカー、製品番号、導入先などを識別するための数字とピリオドで構成された最大64文字のユニークな文字列である。

概要[編集 | ソースを編集]

ここで言う「ユニーク」とは、「世界中で絶対に重複してはならない」という意味である。そのためにも世に放つDICOM製品は必ず所定の登録機関から発行されたUIDをベースに使い、そのUIDの末尾に独自に管理している文字列を付け足すことで重複のないUIDを実現しなければならない。

基点となるUIDは米国商務省が米国内で使われている標準規格に付けた番号で、それらはアプリケーションコンテキスト名DICOM/Application Context Name)と呼ばれる。なお、名称に「Name」と付いてるくせに数字とピリオドだけという意味不明さなので、「Application Context Name」じゃなく「Application Context UID」という名前にしてくれればいいものをと思うかもしれないが、気にしてはならない。なお、アプリケーションコンテキスト名はDICOM専用という訳ではなく、SNMPなどの各種インターネットで用いられる標準規格にも割り振られている数字(とピリオド)であり、DICOMのアプリケーションコンテキスト名は「1.2.840.10008.3.1.1.1」となっている。

  1. 米国商務省が「1.2.840.10008.3.1.1.1」に国番号を付加して、各国の管理団体に渡す。
  2. 各国の管理団体は製造メーカー番号を付加して、製造メーカーに渡す。
  3. 製造メーカーは製品番号を付加して、製造する。
  4. 製造メーカーは納品番号を付加して、納品する。
  5. DICOM製品は何かしらの被らない数字を発行し、DICOMファイルなどに付与する。
DICOM製品での発行は一般的に、Study Instance UIDSeries Instance UIDSOP Instance UIDの3段階で発行することが多い。

これでユニークな番号のできあがりである。

なお、日本における管理団体は日本画像医療システム工業会JIRA)であり、その会員になると製造メーカーとして認定されUIDが発行される。

問題点[編集 | ソースを編集]

現実問題として、世の中には無差別に配布されるフリーソフトやオープンソースソフトウェアなどが無数に存在しており、それらは製造者や製品番号は識別されるようになっているが、その先の納品先(利用者側)を管理しておらず、当然のようにそれらのUIDという制度は崩壊している。

本来の意味で「DICOM規格に準拠する」というのであれば、たとえフリーソフトであっても、配布者は利用者にユニークなIDを割り振らなければならないのだが、そんなこと無視されまくりなのである。

もっと悪い例としては、製造業者でありながら、末端の設置作業員の知識不足により、出荷時設定のままで管理されていないことすら見受けられる。

関連項目[編集 | ソースを編集]

参考文献[編集 | ソースを編集]

外部リンク[編集 | ソースを編集]