(57)【要約】【課題】ＤＩＣＯＭ規格ＵＩＤ同士の比較処理を高速化する。【解決手段】ＤＩＣＯＭ規格のオブジェクト識別子であるＵＩＤについて、第１ＵＩＤおよび第２ＵＩＤを取得するＵＩＤ取得部と、第１ＵＩＤおよび第２ＵＩＤをそれぞれ上位からＮ文字毎（Ｎ＞１）の単位文字列に区切り、それぞれ上位から単位文字列毎に数値化し、数値化した単位文字列同士を比較する処理を、相違が生じるまであるいは比較対象の単位文字列がなくなるまで繰り返すことで第１ＵＩＤと第２ＵＩＤの大小または同一を判定する判定処理部と、を備える。【選択図】図１
2020154981.tif 000002
【特許請求の範囲】
【請求項１】
ＤＩＣＯＭ規格のオブジェクト識別子であるＵＩＤについて、第１ＵＩＤおよび第２ＵＩＤを取得するＵＩＤ取得部と、
前記第１ＵＩＤおよび前記第２ＵＩＤをそれぞれ上位からＮ文字毎（Ｎ＞１）の単位文字列に区切り、
それぞれ上位から単位文字列毎に数値化し、数値化した単位文字列同士を比較する処理を、相違が生じるまであるいは比較対象の単位文字列がなくなるまで繰り返すことで前記第１ＵＩＤと前記第２ＵＩＤの大小または同一を判定する判定処理部と、
を備えることを特徴とするＤＩＣＯＭ規格ＵＩＤ比較装置。
【請求項２】
前記判定処理部は、
比較対象の単位文字列がなくなった場合、残りの文字列を１文字毎比較することで前記第１ＵＩＤと前記第２ＵＩＤの大小または同一を判定することを特徴とする請求項１に記載のＤＩＣＯＭ規格ＵＩＤ比較装置。
【請求項３】
前記判定処理部は、
前記単位文字列に区切るのに先立ち、前記第１ＵＩＤおよび前記第２ＵＩＤとが、前記単位文字列の整数倍で同じ桁になるように、大小判定に影響を与えないダミー文字を下位側に付加すること特徴とする請求項１に記載のＤＩＣＯＭ規格ＵＩＤ比較装置。
【請求項４】
ＤＩＣＯＭ規格のオブジェクト識別子であるＵＩＤについて、第１ＵＩＤおよび第２ＵＩＤを取得するＵＩＤ取得部と、
前記第１ＵＩＤおよび前記第２ＵＩＤをそれぞれ上位からＮ文字毎（Ｎ＞１）の単位文字列に区切り、
それぞれ上位から単位文字列毎に数値化し、数値化した単位文字列同士を比較する処理を、相違が生じるまであるいは比較対象の単位文字列がなくなるまで繰り返すことで前記第１ＵＩＤと前記第２ＵＩＤの同一／非同一を判定する単位文字列判定処理を行なう判定処理部と、を備え、
前記判定処理部は、
前記第１ＵＩＤと前記第２ＵＩＤとの桁数が不一致の場合、あるいは、前記第１ＵＩＤおよび前記第２ＵＩＤの最下位側所定数の文字同士が不一致の場合、前記単位文字列判定処理を行なわずに、前記第１ＵＩＤと前記第２ＵＩＤとが非同一であると判定することを特徴とするＤＩＣＯＭ規格ＵＩＤ比較装置。
【請求項５】
ＤＩＣＯＭ規格のオブジェクト識別子であるＵＩＤについて、第１ＵＩＤおよび第２ＵＩＤを取得するＵＩＤ取得部と、
前記第１ＵＩＤおよび前記第２ＵＩＤをそれぞれ上位からＮ文字毎（Ｎ＞１）の単位文字列に区切り、
それぞれ上位から単位文字列毎に数値化し、数値化した単位文字列同士を比較する処理を、相違が生じるまであるいは比較対象の単位文字列がなくなるまで繰り返すことで前記第１ＵＩＤと前記第２ＵＩＤの大小または同一を判定する判定処理部として、コンピュータを機能させるコンピュータプログラム。
【請求項６】
ＤＩＣＯＭ規格のオブジェクト識別子であるＵＩＤについて、第１ＵＩＤおよび第２ＵＩＤを取得するＵＩＤ取得部と、
前記第１ＵＩＤおよび前記第２ＵＩＤをそれぞれ上位からＮ文字毎（Ｎ＞１）の単位文字列に区切り、
それぞれ上位から単位文字列毎に数値化し、数値化した単位文字列同士を比較する処理を、相違が生じるまであるいは比較対象の単位文字列がなくなるまで繰り返すことで前記第１ＵＩＤと前記第２ＵＩＤの同一／非同一を判定する単位文字列判定処理を行なう判定処理部としてコンピュータを機能させるコンピュータプログラムであって、
前記判定処理部は、
前記第１ＵＩＤと前記第２ＵＩＤとの桁数が不一致の場合、あるいは、前記第１ＵＩＤおよび前記第２ＵＩＤの最下位側所定数の文字同士が不一致の場合、前記単位文字列判定処理を行なわずに、前記第１ＵＩＤと前記第２ＵＩＤとが非同一であると判定することを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＤＩＣＯＭ（Digital Imaging and COmmunications in Medicine）規格のオブジェクト識別子であるＵＩＤ同士を高速に比較する技術に関する。
【背景技術】
【０００２】
医用画像の国際規格であるＤＩＣＯＭでは、画像（イメージ）、シリーズ、検査（スタディ）等のオブジェクトを識別するための識別子としてＵＩＤが定義されている。ここで、シリーズは、一連のイメージの集合であり、スタディは、シリーズの集合である。ＵＩＤは、０−９の数字と「．」（ピリオド）のみの１１文字種から構成される文字列であり、最大６４桁と決められている。
【０００３】
ＵＩＤとしては、１枚の画像を一意に識別するための「SOP Instance UID」、シリーズを一意に識別するための「Series Instance UID」、スタディを一意に識別するための「Study Instance UID」等が規約で定められている。ＵＩＤにより、イメージ、シリーズ、スタディ等のオブジェクトを世界中で一意に特定することができる。
【０００４】
例えば、SOP Instance UIDであれば、「1.2.392.200045.8842.5.123456.157・・・・・・・・0.3028793133301234」等のように表される（なお、一部の数字を「・」で表している）。ＵＩＤの規則として、「．」で区切られた区間に、「０」から始まる数字は許可されない等が決められているため、ＵＩＤが取り得る文字列は単純に１１の６４乗種類にはならないが、非常に多くの組合せが得られる。
【０００５】
ＤＩＣＯＭ規格の医用画像ファイルを扱うソフトウェアとして画像ビューアソフトウェア、画像サーバソフトウェア、検像アプリケーション等が用いられている。
【０００６】
例えば、画像ビューアソフトウェアで医用画像を表示する際には、多量の画像を対象として、ＵＩＤを基準とした並べ替えや探索処理が必要となる。ここで、並べ替えは、ＵＩＤの大小評価に基づいた画像のソートである。探索は、対象とする画像が一群の画像に含まれるかの判定である。いずれの場合も、ＵＩＤ同士を比較して、大小や同一／非同一を判断する処理が基本となる。
【０００７】
ＵＩＤは、多くの数字を含んでいるが、複数個のピリオドも含んでいるため、全体を１つの整数や小数として扱うことができない。このため、ＤＩＣＯＭ規格のＵＩＤは、コンピュータプログラム上では文字列として扱われる。
【０００８】
一般に、ＵＩＤ同士を比較する場合には、それぞれ先頭（左端）が最上位の桁、末尾（右端）が最下位の桁と考え、最上位から１文字ずつ数字あるいはピリオドを比較していく。ここで、各桁の文字は、ＡＳＣＩＩコード（１バイトの正整数）として０−２５５の範囲の符号無しの数値として評価されるため、大小関係は、小さい方から「．］「０」「１」…「８」「９」の順となる。
【０００９】
ＵＩＤ同士の比較では、最上位の左端から開始して最初に大小関係が決定付けられる桁が表れると、その時点で大小関係が決まることになる。一方で、正整数同士の比較であれば、桁数が異なっていれば、桁数の大きい方が必ず大きいと判断できるが、ＵＩＤ同士の比較では、桁数で大小関係を判断することはできない。
【００１０】
図７は、ＵＩＤ同士を比較して大小または同一を判断する処理の従来の例を示すフローチャートである。まず、比較を行なう２つのＵＩＤとして、ＵＩＤ＿ＡとＵＩＤ＿Ｂとを取得する（Ｓ５０１）。
【００１１】
変数ｋを初期値１として（Ｓ５０２）、ＵＩＤ＿ＡとＵＩＤ＿Ｂのｋ文字目同士を比較する（Ｓ５０３）。ｋ＝１のときは、最上位である左端の文字同士が比較されることになる。
【００１２】
ｋ文字目が一致していなければ（Ｓ５０４：Ｎｏ）、ＵＩＤ＿ＡとＵＩＤ＿Ｂの大小関係が確定する（Ｓ５０５）。すなわち、ｋ文字目の文字が大きい方のＵＩＤが大きいと判定する。なお、一方のＵＩＤの桁が他方より短く、一方のＵＩＤのｋ番目の文字が存在しないときも、ｋ文字目が一致しない場合に含められる。
【００１３】
ｋ文字目が一致している場合は（Ｓ５０４：Ｙｅｓ）、ＵＩＤ＿ＡとＵＩＤ＿Ｂともｋ文字目が最終文字であれば（Ｓ５０６：Ｙｅｓ）、全桁が一致していることになるため、ＵＩＤ＿ＡとＵＩＤ＿Ｂとが同一であると判定する（Ｓ５０８）。
【００１４】
ＵＩＤ＿ＡとＵＩＤ＿Ｂの少なくとも一方が、ｋ文字目が最終文字でなければ（Ｓ５０６：Ｎｏ）、ｋ＝ｋ＋１として（Ｓ５０７）、処理（Ｓ５０３）以降を繰り返し、次の桁の比較を同様に行なう。
【００１５】
実装上は、例えば、コンピュータプログラムにおいて、２つのＵＩＤをそれぞれ文字型配列や文字列クラスの変数に格納し、ライブラリとして提供される比較関数等を利用してＵＩＤ同士の比較を行なっている。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開２０１６−３５７１７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１７】
従来のＵＩＤ比較処理は、上の桁から下の桁へ、順にポインタを進め、１文字（１バイト）ごとに比較していたため、１バイトの文字の比較を最大で６４回繰り返す必要がある。
【００１８】
近年では、ＣＴ（Computed Tomography）のようなモダリティの撮影技術の発達により、１検査が数千枚もの画像から構成されることもあり、画像表示において、ＵＩＤを対象とした並べ替え、探索が処理負荷として無視できなくなってきた。画像ビューアソフトウェアでは、一般に、表示のための画像処理に関しては色々な工夫がなされているが、ＵＩＤの比較処理は、高々６４文字の比較であることからそれほど着目されず、特段の高速化の工夫がなされていないのが現状である。
【００１９】
そこで、本発明は、ＤＩＣＯＭ規格ＵＩＤ同士の比較処理を高速化することを目的とする。
【課題を解決するための手段】
【００２０】
上記課題を解決するため、本発明の第１の態様であるＤＩＣＯＭ規格ＵＩＤ比較装置は、ＤＩＣＯＭ規格のオブジェクト識別子であるＵＩＤについて、第１ＵＩＤおよび第２ＵＩＤを取得するＵＩＤ取得部と、前記第１ＵＩＤおよび前記第２ＵＩＤをそれぞれ上位からＮ文字毎（Ｎ＞１）の単位文字列に区切り、それぞれ上位から単位文字列毎に数値化し、数値化した単位文字列同士を比較する処理を、相違が生じるまであるいは比較対象の単位文字列がなくなるまで繰り返すことで前記第１ＵＩＤと前記第２ＵＩＤの大小または同一を判定する判定処理部と、を備えることを特徴とする。
ここで、前記判定処理部は、比較対象の単位文字列がなくなった場合、残りの文字列を１文字毎比較することで前記第１ＵＩＤと前記第２ＵＩＤの大小または同一を判定することことができる。
また、前記判定処理部は、前記単位文字列に区切るのに先立ち、前記第１ＵＩＤおよび前記第２ＵＩＤとが、前記単位文字列の整数倍で同じ桁になるように、大小判定に影響を与えないダミー文字を下位側に付加することができる。
【００２１】
上記課題を解決するため、本発明の第２の態様であるＤＩＣＯＭ規格ＵＩＤ比較装置は、ＤＩＣＯＭ規格のオブジェクト識別子であるＵＩＤについて、第１ＵＩＤおよび第２ＵＩＤを取得するＵＩＤ取得部と、前記第１ＵＩＤおよび前記第２ＵＩＤをそれぞれ上位からＮ文字毎（Ｎ＞１）の単位文字列に区切り、それぞれ上位から単位文字列毎に数値化し、数値化した単位文字列同士を比較する処理を、相違が生じるまであるいは比較対象の単位文字列がなくなるまで繰り返すことで前記第１ＵＩＤと前記第２ＵＩＤの同一／非同一を判定する単位文字列判定処理を行なう判定処理部と、を備え、前記判定処理部は、前記第１ＵＩＤと前記第２ＵＩＤとの桁数が不一致の場合、あるいは、前記第１ＵＩＤおよび前記第２ＵＩＤの最下位側所定数の文字同士が不一致の場合、前記単位文字列判定処理を行なわずに、前記第１ＵＩＤと前記第２ＵＩＤとが非同一であると判定することを特徴とする。
【００２２】
上記課題を解決するため、本発明の第３の態様であるコンピュータプログラムは、ＤＩＣＯＭ規格のオブジェクト識別子であるＵＩＤについて、第１ＵＩＤおよび第２ＵＩＤを取得するＵＩＤ取得部と、前記第１ＵＩＤおよび前記第２ＵＩＤをそれぞれ上位からＮ文字毎（Ｎ＞１）の単位文字列に区切り、それぞれ上位から単位文字列毎に数値化し、数値化した単位文字列同士を比較する処理を、相違が生じるまであるいは比較対象の単位文字列がなくなるまで繰り返すことで前記第１ＵＩＤと前記第２ＵＩＤの大小または同一を判定する判定処理部として、コンピュータを機能させる。
【００２３】
上記課題を解決するため、本発明の第４の態様であるコンピュータプログラムは、ＤＩＣＯＭ規格のオブジェクト識別子であるＵＩＤについて、第１ＵＩＤおよび第２ＵＩＤを取得するＵＩＤ取得部と、前記第１ＵＩＤおよび前記第２ＵＩＤをそれぞれ上位からＮ文字毎（Ｎ＞１）の単位文字列に区切り、それぞれ上位から単位文字列毎に数値化し、数値化した単位文字列同士を比較する処理を、相違が生じるまであるいは比較対象の単位文字列がなくなるまで繰り返すことで前記第１ＵＩＤと前記第２ＵＩＤの同一／非同一を判定する単位文字列判定処理を行なう判定処理部としてコンピュータを機能させるコンピュータプログラムであって、前記判定処理部は、前記第１ＵＩＤと前記第２ＵＩＤとの桁数が不一致の場合、あるいは、前記第１ＵＩＤおよび前記第２ＵＩＤの最下位側所定数の文字同士が不一致の場合、前記単位文字列判定処理を行なわずに、前記第１ＵＩＤと前記第２ＵＩＤとが非同一であると判定する。
【発明の効果】
【００２４】
本発明によれば、ＤＩＣＯＭ規格ＵＩＤ同士の比較処理を高速化することができる。
【図面の簡単な説明】
【００２５】
【図１】本実施形態のＤＩＣＯＭ規格ＵＩＤ比較装置の構成を説明するブロック図である。
【図２】ＵＩＤの比較例を示す図である。
【図３】ＵＩＤの大小あるいは同一の判定を行なう処理について説明するフローチャートである。
【図４】単位文字列を説明する図である。
【図５】大小の判定は行なわず、同一／非同一の判定のみを行なう処理について説明するフローチャートである。
【図６】ＵＩＤの大小あるいは同一の判定を行なう処理の別例について説明するフローチャートである。
【図７】従来のＵＩＤの比較処理を説明するフローチャートである。
【発明を実施するための形態】
【００２６】
本発明の実施の形態について図面を参照して説明する。図１は、本実施形態のＤＩＣＯＭ規格ＵＩＤ比較装置１００の構成を示すブロック図である。本図に示すように、ＤＩＣＯＭ規格ＵＩＤ比較装置１００は、ＵＩＤ取得部１１０と判定処理部１２０とを備えている。
【００２７】
ＵＩＤ取得部１１０は、医用画像格納装置２００から比較判定の対象となる２つのＤＩＣＯＭ規格ＵＩＤを取得する。医用画像格納装置２００は、医用画像データベース、モダリティ等とすることができる。ただし、ＵＩＤの取得先は医用画像格納装置２００に限られない。他装置からの入力や手動入力等であってもよい。また、画像を識別するＵＩＤに限られず、シリーズ、スタディ等を識別するＵＩＤであってもよい。
【００２８】
判定処理部１２０は、ＵＩＤ取得部１１０が取得した２つのＵＩＤ同士の比較判定処理を行なう。比較判定処理では、例えば、大小あるいは同一の判定を行なうことができる。また、大小の判定は行なわず、同一／非同一の判定のみを行なうことも可能である。
【００２９】
ＤＩＣＯＭ規格ＵＩＤ比較装置１００は、例えば、パーソナルコンピュータ等で画像ビューアソフトウェアを実行することにより構成される医用画像閲覧装置に組み込むことができる。この場合、パーソナルコンピュータ等をＤＩＣＯＭ規格ＵＩＤ比較装置１００として機能させるためのコンピュータプログラムをＵＩＤ比較モジュールとして画像ビューアソフトウェアに含めることができる。また、ＤＩＣＯＭ規格ＵＩＤ比較装置１００は、画像サーバ、検像装置等にＵＩＤ比較機能部として組み込むようにしてもよい。
【００３０】
ここで、ＤＩＣＯＭ規格ＵＩＤの特性について説明する。ＵＩＤの発番規則は、一定の規約の範囲でベンダごとに異なるが、一般に、１つのシリーズ内の連続する画像は、上位の桁が同じで最下位側の桁のみが連番で異なっている場合が多い。例えば、図２に示すＵＩＤ＿ＡとＵＩＤ＿Ｂのように、最下位桁のみが異なり、他の桁は一致するような具合である。また、図２に示すＵＩＤ＿ＡとＵＩＤ＿Ｃのように、一致しているＵＩＤの一方の最下位側に文字が付加されて桁数が相違する場合もある。なお、本図では、一部の数字を「・」で表している。
【００３１】
このＵＩＤの特性およびコンピュータにおける比較処理の効率化を考慮して、本実施形態のＤＩＣＯＭ規格ＵＩＤ比較装置１００は、以下に示すような手順でＵＩＤ同士の比較判定処理を行なう。
【００３２】
まず、図３のフローチャートを参照して、２つのＵＩＤの大小あるいは同一の判定を行なう処理について説明する。２つのＵＩＤの大小あるいは同一の判定は、例えば、ＵＩＤを基準とした画像の並べ替えを行なう際に連続的に実行される。
【００３３】
本処理では、ＵＩＤ取得部１１０が医用画像格納装置２００から比較判定の対象となる２つのＤＩＣＯＭ規格ＵＩＤを取得する（Ｓ１０１）。ここでは、２つのＵＩＤをＵＩＤ＿Ａ、ＵＩＤ＿Ｂとする。
【００３４】
そして、判定処理部１２０が以降の処理を行なう。まず、ＵＩＤ＿Ａ、ＵＩＤ＿Ｂを上位の桁からＮ文字毎（Ｎ＞１）の単位文字列に区切って、それぞれの区切数を取得する（Ｓ１０２）。ここでは、Ｎ文字は８文字とする。単位文字列を８文字としたのは、１つの単位文字列を６４ビット符号無し整数として表現できるようにするためである。すなわち、１文字１バイト（８ビット）が８文字で６４ビットとなる。
【００３５】
ＵＩＤ＿Ａの区切数をＡｎ、ＵＩＤ＿Ｂの区切数をＢｎとしたとき、Ａｎ、Ｂｎのうち小さい方をＭとする（Ｓ１０２）。
【００３６】
図４（ａ）（ｂ）に示した例では、ＵＩＤ＿Ａの区切数Ａｎ、ＵＩＤ＿Ｂの区切数Ｂｎとも７であり、それぞれ２桁分の文字が単位文字列に含まれず残っている。この場合、Ｍ＝７となる。なお、図４においては、一部の数字を「・」で表している。この部分は、ＵＩＤ＿ＡとＵＩＤ＿Ｂとで同じ数字列であるものとする。
【００３７】
変数ｋを初期値１として（Ｓ１０３）、ＵＩＤ＿ＡとＵＩＤ＿Ｂのｋ番目の単位文字列同士を数値化して比較する（Ｓ１０４）。ここでは、ｋ番目の単位文字列をそれぞれＵＩＤ＿Ａ（ｋ）、ＵＩＤ＿Ｂ（ｋ）と表すものとする。
【００３８】
すなわち、本実施形態では、１文字毎に比較するのではなく、８文字毎の単位文字列に区切り、単位文字列を６４ビットの符号無し整数として扱って比較を行なう。このようにすることで、従来手法では最大６４回の比較が必要であったところ、数値の大小の比較を最大８回行なえばよいことになる。しかも、汎用的なＣＰＵにおいて、６４ビットの符号無し整数の型は、一般的に高速に演算することができる。
【００３９】
単位文字列を６４ビットの符号無し整数（例えば、汎用的な処理系におけるＵＮＩＴ６４等）で表現する場合について説明する。「.」（ピリオド）のＡＳＣＩＩコードが０ｘ２Ｅ、「２」のＡＳＣＩＩコードが０ｘ３２、「１」のＡＳＣＩＩコードが０ｘ３１等を利用すると、図４（ａ）に示したＵＩＤ＿Ａの最初の単位文字列ＵＩＤ＿Ａ（１）の６４ビットの符号無し整数は、０ｘ２Ｅ＋（０ｘ３２）＊８＾１＋…＋（０ｘ３１）＊８＾７と表すことができる。
【００４０】
すなわち、単位文字列の各桁の値を、１バイト（８ビット）を単位とした累乗の重みづけで積算すればよい。ＵＩＤ＿Ｂ（１）についても同様である。
【００４１】
この整数を比較することにより、８文字をまとめて比較することができる。なお、ビッグエンディアンの処理系では単にキャストすればよいが、リトルエンディアンの処理系の場合には、メモリ配置の上下の桁を反転してからキャストするか、０ｘ２Ｅ＋（０ｘ３２）＊８＾１＋…＋（０ｘ３１）＊８＾７という積和演算を行なう必要がある。
【００４２】
ＵＩＤ＿Ａ（ｋ）とＵＩＤ＿Ｂ（ｋ）とを比較した結果、両者が一致していなければ（Ｓ１０５：Ｎｏ）、ＵＩＤ＿ＡとＵＩＤ＿Ｂの大小関係が確定する（Ｓ１０６）。すなわち、ｋ番目の単位文字列が大きい方のＵＩＤが大きいと判定する。
【００４３】
ＵＩＤ＿Ａ（ｋ）とＵＩＤ＿Ｂ（ｋ）とが一致している場合は（Ｓ１０５：Ｙｅｓ）、ｋがＭに達していなければ（Ｓ１０７：Ｎｏ）、ｋ＝ｋ＋１として（Ｓ１０８）、処理（Ｓ１０４）以降を繰り返し、次の単位文字列の比較を同様に行なう。なお、本例では、処理（Ｓ１０２）であらかじめ単位文字列に分割していたが、比較を行なう際に、その都度単位文字列に分割してもよい。
【００４４】
ｋがＭに達していれば（Ｓ１０７：Ｙｅｓ）、単位文字列としての比較を終了し、残りの文字列を１文字毎に比較して大小あるいは同一を判定する（Ｓ１０９）。すなわち、残りの文字列を上位の桁から比較し、不一致の段階で大小が確定する。両者の桁が同じで最下位の桁まで一致すればＵＩＤ＿ＡとＵＩＤ＿Ｂとが同一であると判定することができる。この比較は最大で７回繰り返される。
【００４５】
例えば、図４（ａ）に示した例では、ｋがＭに達するＵＩＤ＿Ａ（７）、ＵＩＤ＿Ｂ（７）まで単位文字列同士が一致するため、残りの文字列を上位から順に比較することで大小が決定する。また、図４（ｂ）に示した例では、ＵＩＤ＿Ａ（２）、ＵＩＤ＿Ｂ（２）が一致しないため、この時点で大小が確定する。
【００４６】
上述のように、ＤＩＣＯＭ規格ＵＩＤは、上位側の桁が一致して、下位側の桁が相違する場合が多いため、上位側の桁から順番に比較するよりも、単位文字列にまとめて比較することが高速化に有効である。
【００４７】
次に、図５のフローチャートを参照して、２つのＵＩＤについて大小の判定は行なわず、同一／非同一の判定のみを行なう処理について説明する。２つのＵＩＤの同一／非同一の判定は、例えば、ＵＩＤを基準とした画像の探索を行なう際に連続的に実行される。この場合、一方のＵＩＤを固定し、他方のＵＩＤを比較対象とし、ＵＩＤの非同一が確定次第、比較対象のＵＩＤを順次入れ替えることができるため、非同一であることを早く判定することで高速化を図ることができる。
【００４８】
まず、ＵＩＤ取得部１１０が医用画像格納装置２００から比較判定の対象となる２つのＤＩＣＯＭ規格ＵＩＤを取得する（Ｓ２０１）。ここでは、２つのＵＩＤをＵＩＤ＿Ａ、ＵＩＤ＿Ｂとする。上述のように、一方のＵＩＤは固定とすることができる。この場合も便宜的に取得と称する。
【００４９】
そして、判定処理部１２０が以降の処理を行なう。まず、ＵＩＤ＿Ａ、ＵＩＤ＿Ｂの桁数が一致するかを判定する（Ｓ２０２）。桁数が一致していない場合は（Ｓ２０２：Ｎｏ）、ＵＩＤ＿Ａ、ＵＩＤ＿Ｂの非同一が即座に確定する（Ｓ２０４）。
【００５０】
桁数が一致している場合は（Ｓ２０２：Ｙｅｓ）、ＵＩＤ＿Ａ、ＵＩＤ＿Ｂの最下位桁の文字が一致するかを判定する（Ｓ２０３）。最下位桁の文字が一致していない場合は（Ｓ２０３：Ｎｏ）、ＵＩＤ＿Ａ、ＵＩＤ＿Ｂの非同一が即座に確定する（Ｓ２０４）。
【００５１】
なお、最下位桁のみならず、最下位側の複数桁が一致するかを判定してもよい。例えば、Series Instance UIDは、下の４桁程度が連番になっている場合が多いため、この範囲の桁を使えば効率良く処理できる。
【００５２】
上述のように、ＤＩＣＯＭ規格ＵＩＤは、上位側の桁が一致して、下位側の桁が相違する場合が多いため、この時点で非同一が確定する場合が多い。このため、同一／非同一の判定処理を高速化することができる。
【００５３】
最下位桁の文字が一致している場合は（Ｓ２０３：Ｙｅｓ）は、大小判定と同様に単位文字列での判定を行なう。すなわち、ＵＩＤ＿Ａ、ＵＩＤ＿Ｂを上位の桁からＮ文字毎（Ｎ＞１）の単位文字列に区切って、区切数をＭとする（Ｓ２０５）。ここでは、処理（Ｓ２０２：Ｙｅｓ）の判定により、ＵＩＤ＿Ａ、ＵＩＤ＿Ｂの桁数が一致していることが判明しているため、区切数も一致する。
【００５４】
変数ｋを初期値１として（Ｓ２０６）、ＵＩＤ＿ＡとＵＩＤ＿Ｂのｋ番目の単位文字列同士を数値化して比較する（Ｓ２０７）。ＵＩＤ＿Ａ（ｋ）とＵＩＤ＿Ｂ（ｋ）とが一致していなければ（Ｓ２０８：Ｎｏ）、ＵＩＤ＿ＡとＵＩＤ＿Ｂの非同一が確定する（Ｓ２０９）。
【００５５】
ＵＩＤ＿Ａ（ｋ）とＵＩＤ＿Ｂ（ｋ）とが一致している場合は（Ｓ２０８：Ｙｅｓ）、ｋがＭに達していなければ（Ｓ２１０：Ｎｏ）、ｋ＝ｋ＋１として（Ｓ２１１）、処理（Ｓ２０７）以降を繰り返し、次の単位文字列の比較を同様に行なう。
【００５６】
ｋがＭに達していれば（Ｓ２１０：Ｙｅｓ）、単位文字列としての比較を終了し、残りの文字列を１文字毎に比較して同一を判定する（Ｓ２１２）。すなわち、残りの文字列を上位の桁から比較し、不一致の桁が現われた段階で非同一が確定する。両者の桁が同じで最下位の桁まで一致すればＵＩＤ＿ＡとＵＩＤ＿Ｂとが同一であると判定することができる。
【００５７】
次に、２つのＵＩＤの大小あるいは同一の判定を行なう処理の別例について図６のフローチャートを参照して説明する。本別例でも、ＵＩＤ取得部１１０が医用画像格納装置２００から比較判定の対象となる２つのＤＩＣＯＭ規格ＵＩＤを取得する（Ｓ３０１）。
【００５８】
次いで、判定処理部１２０が以降の処理を行なう。まず、桁数の大きい方のＵＩＤが８×Ｍ桁となるようにダミー文字を下位側に付加する（Ｓ３０２）。そして、桁数の小さい方のＵＩＤも８×Ｍ桁となるようにダミー文字を下位側に付加する（Ｓ３０３）。
【００５９】
すなわち、本別例では、桁数の大きい方のＵＩＤが単位文字列で割り切れるようにダミー文字を付加し、桁数の小さい方のＵＩＤも同じ桁数となるようにダミー文字を付加する。これにより、２つのＵＩＤの桁を揃えるとともに、単位文字列の比較処理だけで大小または同一の判定を行なうことができるようになる。ここで、ダミー文字は大小比較に影響を与えないように「．」（ピリオド）よりもＡＳＣＩＩコードが小さい文字とする。
【００６０】
変数ｋを初期値１として（Ｓ３０４）、ＵＩＤ＿ＡとＵＩＤ＿Ｂのｋ番目の単位文字列同士を数値化して比較する（Ｓ３０５）。ＵＩＤ＿Ａ（ｋ）とＵＩＤ＿Ｂ（ｋ）とが一致していなければ（Ｓ３０６：Ｎｏ）、ＵＩＤ＿ＡとＵＩＤ＿Ｂの大小が確定する（Ｓ３０７）。
【００６１】
ＵＩＤ＿Ａ（ｋ）とＵＩＤ＿Ｂ（ｋ）とが一致している場合は（Ｓ３０６：Ｙｅｓ）、ｋがＭに達していなければ（Ｓ３０８：Ｎｏ）、ｋ＝ｋ＋１として（Ｓ３０９）、処理（Ｓ３０５）以降を繰り返し、次の単位文字列の比較を同様に行なう。
【００６２】
ｋがＭに達していれば（Ｓ３０８：Ｙｅｓ）、ＵＩＤ＿ＡとＵＩＤ＿Ｂとが同一であると確定する（Ｓ３１０）。
【００６３】
以上、本発明の実施形態について説明した。ここで、図５に示した手順により、ＵＩＤの一致／不一致判断の演算が何倍くらい高速化されるか、定量的に期待値を評価する。
【００６４】
比較元の１個のＵＩＤに対して、多数の異なる比較先ＵＩＤがあり、これらのうちから一致するものを線形探索する場合を想定する。簡単のため、いずれのＵＩＤも６４桁とし、比較先ＵＩＤは最下位側の桁が連続で発番されたものがランダムに並んでいるものとする。
【００６５】
まず、右端の１文字を比較することにより、１０回中９回は、１文字のみの比較で非同一と判定できる。従来手法では６４文字全体を比較していたため、比較に要する時間は１／６４になる。
【００６６】
１０回中１回の割合で最下位桁の値が同じ数字になるので、その場合には全ての桁を比較することになる。この場合も、８桁毎の単位文字列にまとめることで高速に比較することができる。比較回数の減少による演算時間の減少の理論的な期待値ｆは、発生確率をｐ、その場合の所要時間の短縮（高速化の利得の逆数）をｇとすると、１０回に９回は６４倍速、１０回に１回は１文字比較した後に８回の数値の比較となるため、［数１］に示すように評価することができる。
【数１】
2020154981.tif 000003
以上から、図５に示した手法は、比較回数の評価による理論値では、約３５倍超の高速化になる。実際には、８バイトごとに文字列を整数へ変換する処理のオーバヘッド等があり、また、ＣＰＵのアーキテクチャや実装方法に依存する部分もあるため、理論値通りにはならない場合もある。
【００６７】
また、最近の汎用的なＣＰＵでは、複数の数値を同時に演算するベクトル演算器が備わっている。最新のＣＰＵでは、５１２ビット幅のベクトル演算器があるため、６４ビット幅の数値は、８個同時に比較することができる。上記の評価では、ベクトル演算の利用は考慮していないが、仮に、全ての桁を比較する際に８個の６４ビット符号無し整数をベクトル演算で比較できるとすると、比較回数は１回相当となり、下のような期待値を計算することができる。
【数２】
2020154981.tif 000004
理論的には、比較回数の減少による速度向上は５８倍超になると期待できる。ベクトル化の効果で、上記の３５倍よりも高い効率になるが、こちらについても、比較回数に限った評価であり、実際の速度向上率は実装に依存する。
【００６８】
上記の実施形態で、単位文字列を８文字としたが、これは現在広く利用されている６４ｂｉｔのＣＰＵ実装を想定したためであり、単位文字列の文字数は実装の際のＣＰＵ等に応じて適切に設定することで、最適化することができる。
【００６９】
ＵＩＤに用いられる文字は１１通りであるため、４ビットでこれらの文字全体を表現することができ、ＡＳＣＩＩコード（８ビット）全体を用いる必要はない。このため、ＡＳＣＩＩコードの代わりに独自の４ビットのコードを用いれば、ＵＩＤの１桁を表現するために、半分のビット数で済むことになる。そうすると、６４桁を８桁ごとに区切って数値に変換する処理について、汎用的な処理系の６４ビット符号なし整数型であるＵＩＮＴ６４で、一度に６４／４＝１６桁を扱うことができるようになる。この場合、６４桁全体の比較を行なうために、８回では無く４回で済むことになり比較回数を半分にできる。この手法により、１／２の省メモリ、かつ、高速化を行なうことができる。ただし、実際には、元の表現からの変換等のオーバヘッドが発生する。
【００７０】
独自の文字コードを使わず、ＡＳＣＩＩコードをそのまま用いる場合でも、メモリを節約することができる。「．」と数値のうち、ＡＳＣＩＩコードで最小になるのは、「．」（ピリオド）であり、０ｘ２ｅ＝００１０１１１０である。また、最大になるのは「９」であり、０ｘ３９＝００１１１００１である。
【００７１】
ＵＩＤに用いられる文字列では、上位の２ビットは常に０で、下位の６ビットのみでＵＩＤの文字列を表現できる。従って、６４ｂｉｔの符号無し整数を使う場合、８個ずつでは無く、６４／６＝１０個ずつ扱うことができる。結果的に、ＵＩＤ全体は、ＵＩＮＴ６４を８個では無く、ＵＩＮＴ６４を７個で表現することができる。この手法により、ＡＳＣＩＩコードをそのまま用いる場合でも、７／８の省メモリ、かつ、高速化を行なえる。ただし、実際には、元のコードからの変換等のオーバヘッドが発生する。
【符号の説明】
【００７２】
１００…ＤＩＣＯＭ規格ＵＩＤ比較装置
１１０…ＵＩＤ取得部
１２０…判定処理部
２００…医用画像格納装置
【図１】
2020154981.tif 000005
【図２】
2020154981.tif 000006
【図３】
2020154981.tif 000007
【図４】
2020154981.tif 000008
【図５】
2020154981.tif 000009
【図６】
2020154981.tif 000010
【図７】
2020154981.tif 000011