JP2014210108A - 画像管理装置、画像管理方法、および画像管理システム - Google Patents

Abstract

【課題】医用画像データの保存や通信に際して、削除のための独自のプロトコルを用いることなく画像を削除する技術を提供する。【解決手段】画像管理装置において、送信部１７０は、医用画像の画像蓄積通信システムに所定の通信プロトコルを用いて医用画像を送信する。削除候補記憶部１７２は、画像蓄積通信システムに送信した医用画像の識別子と、当該医用画像が削除対象か否かを示す削除候補情報とを対応づけて記憶する。抽出部１７４は、削除候補記憶部１７２の削除候補情報を参照して、削除対象とされる医用画像の識別子を抽出する。送信部１７０は、送信する医用画像に抽出部１７４が抽出した識別子を対応づけて送信する。【選択図】図４

Description

本発明は、画像管理技術に関し、特に、内視鏡システムなどのモダリティで生成した医用画像の送信を管理する技術に関する。

医用画像データの保存や通信の世界標準規格として、ＤＩＣＯＭ（Digital Imaging and COmmunications in Medicine）が策定されている。ＤＩＣＯＭ（ダイコム）は、ＣＴ（Computed Tomography）やＭＲＩ（Magnetic Resonance Imaging）、内視鏡や超音波などの診療で撮影した医用画像ファイルのフォーマットと、医用画像ファイルを送受信する機器間の通信プロトコルを定義する。モダリティとＰＡＣＳ（Picture Archiving and Communication Systems）との間において、医用画像データは一般にＤＩＣＯＭの通信規格に則って送受信が行われる。

特開２００８−３６３５３号公報

ＤＩＣＯＭの通信規格において画像の送信時にＣ−ＳＴＯＲＥプロトコルが一般的に使用されているが、Ｃ−ＳＴＯＲＥプロトコルには画像の削除については規定されていない。したがって、モダリティからＰＡＣＳに画像を送信すると、モダリティ側から画像を削除することは困難であり、通常、ＰＡＣＳを直接操作してその画像を削除する。しかしながら、一般にモダリティとＰＡＣＳは別のシステムであり、それぞれのシステムの管理者も別であることが多く、画像の削除が煩雑となっている。

本発明はこうした課題に鑑みてなされたものであり、その目的は、医用画像データの保存や通信に際して、削除のための独自のプロトコルを用いることなく画像を削除する技術を提供することにある。

上記課題を解決するために、本発明のある態様の画像管理装置は、医用画像の画像蓄積通信システムに所定の通信プロトコルを用いて医用画像を送信する送信部と、画像蓄積通信システムに送信した医用画像の識別子と、当該医用画像が削除対象か否かを示す削除候補情報とを対応づけて記憶する削除候補記憶部と、削除候補記憶部の削除候補情報を参照して、削除対象とされる医用画像の識別子を抽出する抽出部とを備える。送信部は、送信する医用画像に抽出部が抽出した識別子を対応づけて送信する。

本発明の別の態様は、画像管理方法である。この方法は、医用画像の画像蓄積通信システムに所定の通信プロトコルを用いて医用画像を送信するステップと、医用画像の画像蓄積通信システムに送信した医用画像の識別子と、当該医用画像が削除対象か否かを示す削除候補情報とを対応づけて削除候補記憶部に記憶するステップと、削除候補記憶部の削除候補情報を参照して、削除対象とされる医用画像の識別子を抽出するステップと、送信する医用画像に抽出した識別子を対応づけて送信するステップとをプロセッサに実行させる。

本発明のさらに別の態様は、画像管理システムである。この画像管理システムは、第１画像管理装置と第２画像管理装置とを備える。第１画像管理装置は、第２画像管理装置から所定の通信プロトコルを用いて送信される医用画像を受信する受信部と、受信部が受信した医用画像と当該医用画像を識別する識別子とを対応づけて記憶する第１記憶部とを備える。第２画像管理装置は、第１画像管理装置に送信した医用画像の識別子と、当該医用画像が削除対象か否かを示す削除候補情報とを対応づけて記憶する第２記憶部と、第２記憶部の削除候補情報を参照して、削除対象とされる医用画像の識別子を抽出する抽出部と、第１画像管理装置に対して医用画像データをプロトコルを用いて送信する送信部とを備える。送信部は、送信する医用画像に抽出部が抽出した識別子を対応づけて送信し、第１画像管理装置の第１記憶部は、第２画像装置から医用画像および当該医用画像に対応づけられた識別子を受信し、受信した識別子で特定される医用画像を受信した医用画像で上書きする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、医用画像データの保存や通信に際して、削除のための独自のプロトコルを用いることなく画像を削除する技術を提供する技術を提供することができる。

本発明の実施の形態に係る医療情報管理システムの構成を示す図である。 本発明の実施の形態に係る送信装置の構成を示す図である。 ＤＩＣＯＭ規格に準拠した画像ファイルのフォーマット構成を示す図である。 本発明の実施の形態に係る画像管理部の内部構成を模式的に示す図である。 実施の形態に係る削除候補記憶部のデータ構造を模式的に示す図である。 実施の形態に係る画像管理部が実行する画像管理処理の流れを説明するフローチャートである。 実施の形態に係る画像管理部が実行する削除候補画像選択処理の流れを説明するフローチャートである。

図１は、本発明の実施の形態に係る医療情報管理システム１の構成を示す図である。医療情報管理システム１は、医用画像送信システム１０、画像保存通信システム３０、クライアント装置４０およびＭＷＭ（Modality Worklist Management）サーバ５０を備え、イントラネット、ローカルエリアネットワーク（ＬＡＮ）などのネットワークを介して通信可能に接続される。医療情報管理システム１において、少なくとも医用画像送信システム１０と画像保存通信システム３０の間のデータの送受信が、ＤＩＣＯＭ規格で定められた仕様にしたがって行われる。医用画像送信システム１０は、内視鏡システム１２および送信装置２０を有する。

内視鏡システム１２は、内視鏡装置、画像処理装置および表示装置を有する。内視鏡装置は、患者の体腔内に挿入され、先端のＣＣＤ（Charge Coupled Device）などの固体撮像素子により内部の画像を撮像し、撮像した像を撮像信号として画像処理装置に出力する。画像処理装置は、内視鏡装置から入力された撮像信号に対して、増幅、ノイズ除去、アナログ・デジタル変換、利得調整、輝度比の調整、フィルタ処理等を行い、固体撮像素子がとらえている画像をライブ画像として表示装置に表示する。医師が、表示装置の画面に表示されるライブ画像を見ながら、内視鏡装置の操作部を操作して撮影画像のキャプチャ指示を生成すると、画像処理装置は、画像キャプチャ指示をもとに、撮影画像データを生成し、送信装置２０に送信する。

送信装置２０は、ＤＩＣＯＭコンバータであり、内視鏡システム１２で生成された撮影画像データを、ＤＩＣＯＭ規格に準拠した画像データに変換し、またＤＩＣＯＭ規格に準拠した通信プロトコルにより画像保存通信システム（ＰＡＣＳ：Picture Archiving and Communication System）３０に送信する。医用画像送信システム１０において、送信装置２０による画像データ変換機能は内視鏡システム１２に設けられていてもよいが、内視鏡システム１２がＤＩＣＯＭ規格に対応していない場合には、ＤＩＣＯＭコンバータである送信装置２０が、内視鏡システム１２から撮影画像データを取得し、それをＤＩＣＯＭフォーマットに合わせた画像データに変換して、画像保存通信システム３０に送信する。

本実施の形態において、内視鏡システム１２は医用画像データを出力するモダリティの一例である。医療情報管理システム１においては、内視鏡システム１２の代わりに、コンピュータ断層撮影装置、磁気共鳴診断装置、デジタルＸ線撮影装置、コンピュータ・ラジオグラフィ、血管造影Ｘ線診断装置、超音波診断装置などのモダリティが設けられてもよい。

画像保存通信システム３０は、データベース３２を有し、医用画像送信システム１０から送信される医用画像データを蓄積する。クライアント装置４０は、医師等の医療従事者により使用され、データベース３２に蓄積された医用画像を閲覧・利用するための端末装置である。

なお、医用画像送信システム１０中の送信装置２０もまた、医用画像送信システム１０に送信した医用画像を記憶する画像データ記憶部を備える。医療従事者は、画像データ記憶部が格納する画像を参照しながら、医用画像送信システム１０を利用してレポート作成する。

内視鏡検査は、患者識別情報（以下、「患者ＩＤ」とよぶ）および検査種別等を特定する検査オーダにしたがって実施される。オーダは、内視鏡検査に限らず、他の種類の検査や手術を含む医療行為の実施内容を定めたものであり、医師は、オーダの存在を前提として医療行為を実施する。検査オーダはオーダリングシステムにより発行され、病院情報システム（ＨＩＳ）により管理される。内視鏡システム１２に検査オーダが通知されると、その表示装置に、検査オーダに含まれる患者氏名、患者ＩＤ、性別、年齢、検査種別、検査室名、検査開始予定時刻、検査終了予定時刻などの情報が表示され、医師により確認された上で、検査オーダの内容にしたがった検査が実施される。

ＭＷＭサーバ５０は、ＨＩＳから検査オーダを取得し、送信装置２０からの問い合わせに応じて、送信装置２０に検査オーダを送信する。ＤＩＣＯＭ画像フォーマットには、入力を必要とする複数のタグが規定されており、送信装置２０は、内視鏡システム１２から提供される医用画像データと検査オーダとを対応付けることで、タグの情報を検査オーダから取得し、ＤＩＣＯＭ画像ファイルに埋め込む。なお送信装置２０は、内視鏡システム１２から医用画像データとともに送信される患者ＩＤと、検査オーダに含まれる患者ＩＤとの一致を判定することで、医用画像データと検査オーダとの対応付けを行う。これにより、送信装置２０は、ＤＩＣＯＭ規格に準拠したフォーマットで医用画像ファイルを生成し、画像保存通信システム３０に送信する。

図２は、実施の形態に係る送信装置２０の構成を示す図である。送信装置２０は、検査情報取得部１００、オーダ取得部１３２、医用画像生成部１３４、記憶管理部１３６、画像管理部１４４、および記憶装置１５０を備える。検査情報取得部１００は、時刻情報取得部１０２、患者ＩＤ取得部１０４および画像データ取得部１０６を有し、内視鏡システム１２から検査情報を取得する機能をもつ。記憶装置１５０は、ハードディスクドライブ（ＨＤＤ）などで構成される大容量補助記憶装置である。

送信装置２０のそれぞれの構成は、ハードウェア的には、任意のプロセッサ、メモリ、その他のＬＳＩ（Large Scale Integration）で実現でき、ソフトウェア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組み合わせによっていろいろな形で実現できることは、当業者には理解されるところである。

まず、ＤＩＣＯＭコンバータとしての送信装置２０の基本動作について説明する。送信装置２０は、内視鏡システム１２から取得した医用画像データから、ＤＩＣＯＭ規格に準拠したデータフォーマットの医用画像ファイルを生成し、ＤＩＣＯＭ規格に準拠した通信プロトコルで画像保存通信システム３０に転送する。以下、詳細を示す。

内視鏡システム１２における検査の開始前、オーダ取得部１３２が、ＭＷＭサーバ５０から、内視鏡検査の検査オーダを取得する。たとえばオーダ取得部１３２は、最初の検査開始前に、１日分の検査オーダをＭＷＭサーバ５０から取得する。オーダ取得部１３２は、取得した１日分の複数の検査オーダを、オーダ記憶部１５２に格納する。各検査オーダは、オーダＩＤ、患者氏名、患者ＩＤ、患者の性別、患者の年齢、検査種別、検査室名、担当医氏名、担当医識別情報（以下、「担当医ＩＤ」とよぶ）、検査開始予定時刻、検査終了予定時刻などの情報を含む。

内視鏡システム１２において検査が開始されると、時刻情報取得部１０２が、内視鏡システム１２から、検査の開始時刻を示す情報を受け付け、その情報により特定される時刻に検査が開始されたことを判定する。なお時刻情報取得部１０２は、内視鏡検査の開始を示す情報を受け付け、受け付けた時刻に、検査が開始されたことを判定してもよい。また患者ＩＤ取得部１０４は、内視鏡システム１２から、検査を行う患者の患者ＩＤを取得する。

医用画像生成部１３４は、時刻情報取得部１０２から検査開始時刻を受け取り、また患者ＩＤ取得部１０４から患者ＩＤを受け取る。医用画像生成部１３４は、患者ＩＤを受け取ると、オーダ記憶部１５２に記憶された検査オーダを探索して、受け取った患者ＩＤを含む検査オーダを抽出する。これにより医用画像生成部１３４は、内視鏡システム１２にて実施される検査のオーダを特定できる。なお医用画像生成部１３４は、抽出した検査オーダに含まれる検査開始予定時刻を参照し、時刻情報取得部１０２から受け取った検査開始時刻との時間差が所定時間（たとえば１時間）内であったときに、抽出した検査オーダで間違いがないことを確認してもよい。

画像データ取得部１０６は、内視鏡システム１２から、撮影された内視鏡画像のデジタルデータを取得する。内視鏡システム１２は、撮影するたびに、内視鏡画像データを送信装置２０に送信してもよく、複数枚まとめて送信装置２０に送信してもよい。画像データ取得部１０６は、医用画像生成部１３４に、取得した画像データを提供する。

以下、ＤＩＣＯＭの画像データフォーマットについて説明する。ＤＩＣＯＭのデータフォーマットは、医用画像に関するメタ情報をヘッダ部分に保持する。ＤＩＣＯＭのメタ情報および画像データは、タグを利用して管理されており、タグの内容はＧｒｏｕｐ番号とＥｌｅｍｅｎｔ番号により特定される。４桁のＧｒｏｕｐ番号と、Ｇｒｏｕｐの情報内容の関係を例示する。
（0008）−画像に関する情報
（0010）−患者に関する情報
（0018）−収集に関する情報
（0020）−画像付帯情報
（0040）−手続に関する情報

以下、代表的なＤＩＣＯＭのタグと、その内容を例示する。タグ番号は、（Ｇｒｏｕｐ番号，Ｅｌｅｍｅｎｔ番号）で表現される。
（0008, 0020）−検査日付
（0008, 0030）−検査時刻
（0008, 0050）−オーダＩＤ
（0008, 0060）−モダリティ
（0010, 0010）−患者の名前
（0010, 0016）−ＳＯＰ Ｃｌａｓｓ ＵＩＤ
（0010, 0018）−ＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤ
（0010, 0020）−患者ＩＤ
（0010, 0030）−患者の誕生日
（0010, 0040）−患者の性別
（0010, 1010）−患者の年齢
（0018, 0015）−検査部位
（0020, 000D）−検査ＩＤ
（0020, 0011）−シリーズ番号
（0040, 0006）−担当医師の名前

なお、ＳＯＰはService Object Pairを意味し、ＵＩＤはUnique IDentifierを意味する。ＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤは、ＤＩＣＯＭ画像の生成時に世界で唯一の識別番号としてその画像のヘッダに格納される。

図３は、ＤＩＣＯＭ規格に準拠した画像ファイルのフォーマット構成を示す図である。画像ファイルは、ヘッダ（Ｈｅａｄｅｒ）と、画像データ（Ｉｍａｇｅ Ｄａｔａ）から構成され、ヘッダは、複数のデータエレメント（Ｄａｔａ Ｅｌｅｍｅｎｔ）を含んでいる。各データエレメントは、タグ番号を表現するＴａｇ、ＶａｌｕｅＦｉｅｌｄに含まれる数値、文字列、時刻などのデータ形式（値表現）を示すＶＲ、ＶａｌｕｅＦｉｅｌｄのバイト長を示すＶａｌｕｅＬｅｎｇｔｈ、値の領域を示すＶａｌｕｅＦｉｅｌｄから構成される。画像ファイルにおいて、入力されるべきメタ情報は、予め定められており、いずれのタグの入力を必要とするかは、病院施設ごとに定められてよい。

医用画像生成部１３４は、図３に示すデータフォーマットで、医用画像ファイルを生成する。なお医用画像生成部１３４は、必要であれば、画像データ取得部１０６で取得した画像データを、ＤＩＣＯＭ規格に準拠したフォーマットに変換する。医用画像生成部１３４は、オーダ記憶部１５２から抽出した検査オーダから、画像データフォーマットが必要とする情報、すなわちタグにより規定される情報を抽出して、画像ファイルに付加する。これにより、ＤＩＣＯＭフォーマットの画像ファイルが生成される。医用画像生成部１３４が、画像ファイルを生成すると、記憶管理部１３６は、生成された画像ファイルを、検査オーダに関連付けて画像データ記憶部１６０に記憶する。この関連付けは、検査オーダに、画像ファイルの格納場所を紐付けることで行われてよい。

画像管理部１４４は、画像データ記憶部１６０に記憶された画像ファイルを、画像保存通信システム３０に送信する。画像保存通信システム３０は、画像ファイルを受信すると、データベース３２に格納するとともに、受信したことを示すＡＣＫ信号を送信装置２０に返信する。これにより、画像保存通信システム３０は、モダリティで撮影された医用画像データをデータベース３２に蓄積できる。画像ファイルには、オーダＩＤが含まれているため、画像保存通信システム３０は、画像ファイルのオーダＩＤを参照して、同じオーダＩＤをもつ複数の画像ファイルをまとめてデータベース３２に格納するようにする。また、画像保存通信システム３０は、画像ファイルに含まれるＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを参照することで、各画像ファイルを一意に識別することができる。

画像管理部１４４は、画像ファイルの送信後、画像保存通信システム３０からＡＣＫ信号を受信しなければ、所定時間後に、同じ画像ファイルを再送する。以上が、送信装置２０がＤＩＣＯＭコンバータとして動作する手順である。

ここで、医用画像送信システム１０は、画像保存通信システム３０に画像を送信する際に、所定の通信プロトコルを用いる。以下本実施の形態では、所定の通信プロトコルとして医用画像機器間の通信プロトコルの標準規格であるＤＩＣＯＭ通信プロトコルを用いることを前提とする。

ＤＩＣＯＭ通信プロトコルにおいて、モダリティである医用画像送信システム１０から画像保存通信システム３０に画像を送信する場合、Ｃ−ＳＴＯＲＥと呼ばれる通信プロトコルが多く用いられる。Ｃ−ＳＴＯＲＥはＤＩＣＯＭ Ｐｕｓｈと呼ばれることもあり、現状Ｃ−ＳＴＯＲＥには、医用画像送信システム１０から画像保存通信システム３０に格納されている画像を削除するためのプロトコルは定義されていない。したがって、医用画像送信システム１０のユーザないし管理者が何らかの理由で画像保存通信システム３０に送信した画像を削除することを望む場合、画像保存通信システム３０を直接操作することになる。

しかしながら、例えば医用画像送信システム１０の管理者と、画像保存通信システム３０の管理者とが異なる場合等は、医用画像送信システム１０の管理者が画像保存通信システム３０の管理者に画像の削除を依頼することになり、手順が煩雑となり得る。また、削除対象となる画像を誤ってしまう危険性が上がりかねない。そのため、医用画像送信システム１０から画像保存通信システム３０が格納している画像を削除できると、医用画像送信システム１０の使い勝手が向上すると考えられる。一方で、ＤＩＣＯＭ通信プロトコルは標準規格であり、医用画像送信システム１０の製造者が自由に変更できる性質のものではない。

そこで実施の形態に係る画像管理部１４４は、ＤＩＣＯＭ通信プロトコルのＣ−ＳＴＯＲＥを変更することなく、画像保存通信システム３０が格納している画像を実質的に削除することを実現する。以下、この原理について説明する。

図４は、本発明の実施の形態に係る画像管理部１４４の内部構成を模式的に示す図である。画像管理部１４４は、送信部１７０、削除候補記憶部１７２、抽出部１７４、識別子生成部１７６、ユーザインタフェース１７８、および削除候補設定部１８４を備える。ユーザインタフェース１７８は、表示部１８０と入力部１８２とを備える。

削除候補記憶部１７２は、画像保存通信システム３０に送信した医用画像を識別するための識別子であるＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤと、その医用画像が削除対象か否かを示す削除候補情報とを対応づけて記憶する。抽出部１７４は、削除候補記憶部１７２の削除候補情報を参照して、削除対象とされる医用画像の識別子を抽出する。送信部１７０は、画像データ記憶部１６０に記憶された医用画像ファイルを、ＤＩＣＯＭ等の所定の通信プロトコルを用いて画像保存通信システム３０に医用画像を送信する。ここで、送信部１７０は、送信する医用画像のヘッダに、抽出部１７４が抽出した削除対象である医用画像のＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを格納して送信する。

前述したように、ＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤはＤＩＣＯＭ画像の生成時に世界で唯一の識別番号として生成される識別子である。したがって、画像保存通信システム３０はＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを用いて画像を識別することができる。その場合、既に画像保存通信システム３０に送信した画像に付されたＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤと同じＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを付して画像を送信すると、画像保存通信システム３０は後から送信された画像で元からある画像を上書きすることになる。したがって、実質的に画像保存通信システム３０に格納されている画像を削除することと同じ効果が得られる。これにより、Ｃ−ＳＴＯＲＥを変更することなく、画像保存通信システム３０が格納している画像を削除することが実現できる。

画像管理部１４４は、新たなＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを生成する識別子生成部１７６も備えており、送信部１７０は、抽出部１７４が削除対象とされる医用画像の識別子を抽出しない場合は、送信する医用画像に識別子生成部１７６が生成した新たなＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを対応づけて送信する。これにより、画像保存通信システム３０に削除したい画像がない場合には、画像保存通信システム３０に新たな画像が追加で格納される。

続いて、画像保存通信システム３０に上書させるＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを抽出する際に用いられる削除候補記憶部１７２のデータ構造について説明する。

図５は、実施の形態に係る削除候補記憶部１７２のデータ構造を模式的に示す図である。図５に示すように、削除候補記憶部１７２のデータ構造は、検査ＩＤを格納する検査ＩＤフィールド１９０、シリーズ番号を格納するシリーズ番号フィールド１９２、撮影日時を格納する撮影日時フィールド１９４、削除対象か否かを示す削除候補フラグを格納する削除候補フラグフィールド１９６、削除を実施したか否かを示す削除実施フラグを格納する削除実施フラグフィールド１９８、およびＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを格納するＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤフィールド２００を含む。

送信部１７０は、画像保存通信システム３０に送信する全ての画像について、その画像に付与されている検査ＩＤ、シリーズ番号、撮影日時、削除候補フラグ、削除実施フラグ、およびＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを削除候補記憶部１７２に格納する。

ここで削除候補フラグは、ＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤで特定される画像が削除対象であるか否、すなわち上書きの対象であるか否かを示す情報であり、具体的には０（オフ）または１（オン）の値を取るバイナリ値である。削除候補フラグが０の画像は削除対象ではなく、１の画像は削除対象の画像であることを示す。また削除実施フラグは、ＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤで特定される画像が既に削除（すなわち上書き）されたか否かを示す情報であり、削除候補フラグと同様に０または１の値を取るバイナリ値である。削除実施フラグが０の画像はまだ削除されていないことを示し、１の画像は既に削除されたことを示す。したがって、削除候補フラグが０の画像は、削除実施フラグも０である。

送信部１７０は、画像保存通信システム３０に画像を送信したのち、各フラグのデフォルトの設定値として、削除候補フラグの値を０、削除実施フラグの値を０に設定して格納する。なお、削除候補フラグの値や削除実施フラグの値が０から１に変更される場合については後述する。

図５に示す例では、検査ＩＤフィールド１９０には１００と１０１とのふたつの検査ＩＤが格納されており、ふたつの検査が存在することを示している。またシリーズ番号フィールド１９２はそれぞれの検査画像について通し番号が割り振られており、ふたつの検査はともに２つの画像を含むことが分かる。ＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤフィールド２００には、検査ＩＤとシリーズ番号、および撮影日時を利用して作成されたＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤが格納されている。

抽出部１７４は、削除候補記憶部１７２を参照して、削除候補フラグが１であり、かつ削除実施フラグが０であるＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを検索する。そのようなＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤが存在する場合、抽出部１７４はそのＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤで特定される画像を削除対象の画像と判定する。

図６は、実施の形態に係る画像管理部１４４が実行する画像管理処理の流れを説明するフローチャートである。本フローチャートにおける処理は、送信部１７０が画像を送信するときに開始する。

抽出部１７４は、削除候補記憶部１７２を参照して、削除候補フラグフィールド１９６の値が１であり、かつ削除実施フラグフィールド１９８の値が０である削除対象画像が存在するか否かを検索する（Ｓ２）。削除対象画像が存在する場合（Ｓ４のＹ）、抽出部１７４は、削除対象画像の削除実施フラグフィールド１９８の値を１に変更する（Ｓ６）。送信部１７０は、抽出部１７４が取得した削除対象画像のＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを、送信する画像に設定する（Ｓ８）。続いて送信部１７０は、削除候補記憶部１７２に送信する画像の情報を格納するとともに、削除候補フラグフィールド１９６および削除実施フラグフィールド１９８の値を０に設定する（Ｓ１０）。

削除対象画像が存在しない場合（Ｓ４のＮ）、識別子生成部１７６は、新たなＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを生成する（Ｓ１２）。送信部１７０は、識別子生成部１７６が生成したＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを送信する画像に設定する（Ｓ１４）。

送信部１７０は、削除対象画像のＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤまたは識別子生成部１７６が新規に生成したＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤが設定された画像を画像保存通信システム３０に送信する（Ｓ１６）。送信部１７０は、画像保存通信システム３０から画像を受信したことを示すＡＣＫ信号を受信しない場合、すなわち画像の送信が失敗した場合（Ｓ１８のＮ）、送信部１７０は、抽出部１７４が検索した削除対象画像の削除実施フラグフィールド１９８の値を１から０に戻す（Ｓ２０）。送信部１７０は次いで、送信する画像に設定したＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤをリセットし（Ｓ２２）、ステップＳ２に戻る。

画像保存通信システム３０から画像を受信したことを示すＡＣＫ信号を受信し、送信が成功した場合（Ｓ１８のＹ）、本フローチャートにおける処理は終了する。なお、送信部１７０は、画像保存通信システム３０から画像を受信したことを示すＡＣＫ信号を受信しない場合、すなわち画像の送信が失敗した場合には、その画像に関して削除候補フラグの値を１、削除実施フラグの値を０として削除候補記憶部１７２に格納する。送信部１７０は画像の送信が失敗した場合にはその画像を再送するが、仮に画像保存通信システム３０に画像が保存されているものの、何らかの理由でＡＣＫ信号を受信しなかった場合に、画像保存通信システム３０に重複して画像が保存されることを防ぐためである。削除候補フラグの値を１であれば、ＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤが再利用されるため、画像保存通信システム３０に保存されている画像は上書きされ、重複して画像が保存されることが防止できる。

次に、削除候補フラグおよび削除実施フラグの設定について説明する。医用画像送信システム１０のユーザは、表示部１８０に表示された画像を確認し、入力部１８２からその画像を削除対象とするか否かを指定することができる。

図４に示すように、実施の形態に係る画像管理部１４４は、表示部１８０と入力部１８２とを含むユーザインタフェース１７８を備える。ここで表示部１８０は、例えば液晶モニタ等であり、画像データ記憶部１６０が記憶する医用画像をユーザに提示することができる。また入力部１８２はマウス等のポインティングデバイスやキーボードである。

削除候補設定部１８４は、削除候補記憶部１７２が記憶する削除候補情報を、削除対象を示す情報に変更、すなわち削除候補フラグの値を０から１に変更する。より具体的に、削除候補設定部１８４は、画像データ記憶部１６０が記憶する医用画像を順次表示部１８０に表示する。このとき削除候補設定部１８４は、削除候補記憶部１７２を参照して、削除実施フラグフィールド１９８が１であるＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを持つ画像はスキップするようにしてもよい。削除実施フラグフィールド１９８が１であるＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤの画像は、既に画像保存通信システム３０から削除されている画像であるからである。

医用画像送信システム１０のユーザは、表示部１８０に表示された画像を画像保存通信システム３０から削除することを望む場合、入力部１８２を介してその旨を削除候補設定部１８４に指示する。削除候補設定部１８４は、表示部１８０に表示された画像のＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを特定し、削除候補記憶部１７２を参照して対応する削除候補フラグフィールド１９６の値を１に変更する。削除候補設定部１８４は削除候補フラグフィールド１９６の値を変更した後、表示部１８０に表示する画像を更新する。以上の操作を繰り返すことで、画像保存通信システム３０に送信した画像のうち削除を望む画像を、次に画像を送信するときの上書き対象画像とすることができる。

図７は、実施の形態に係る画像管理部１４４が実行する削除候補画像選択処理の流れを説明するフローチャートである。本フローチャートにおける処理は、例えばユーザが入力部１８２を介して削除候補設定部１８４に削除候補画像の選択開始を指示したときに開始する。

削除候補設定部１８４は、画像データ記憶部１６０が記憶する医用画像を順次表示部１８０に表示する（Ｓ３０）。ユーザから削除をすべき指示を受信した場合（Ｓ３２のＹ）、削除候補設定部１８４は、削除候補記憶部１７２を参照してユーザが削除を指示した画像の削除候補フラグフィールド１９６の値を１に変更する（Ｓ３４）。ユーザから削除をすべき指示を受信しない場合（Ｓ３２のＮ）、削除候補設定部１８４は表示部１８０に表示中の画像について特段の操作をしない。

削除候補設定部１８４は画像データ記憶部１６０中の画像データを全て表示するまでの間（Ｓ３６のＮ）、表示部１８０に表示する画像を更新し（Ｓ３８）、上述した処理を継続する。削除候補設定部１８４が、画像データ記憶部１６０中の画像データを全て表示部１８０に表示させると（Ｓ３６のＹ）、本フローチャートにおける処理は終了する。

以上説明したように、本発明の実施の形態に係る医用画像送信システム１０によれば、医用画像データの保存や通信に際して、削除のための独自のプロトコルを用いることなく画像を削除する技術を提供することができる。

以上、本発明を実施の形態にもとづいて説明した。本発明は上述の実施の形態に限定されるものではなく、実施の形態の各要素を適宜組み合わせたものも、本発明の実施の形態として有効である。実施の形態の組合せによって生じる新たな実施の形態は、組み合わされる実施の形態それぞれの効果をあわせもつ。また、当業者の知識に基づいて各種の設計変更等の変形を実施の形態に対して加えることも可能であり、そのような変形が加えられた実施の形態も本発明の範囲に含まれうる。

上記の説明では、入力部１８２を介して、医用画像送信システム１０のユーザが削除候補設定部１８４に削除を望む画像を明示的に指示する場合について説明した。これに加えて、所定の条件下においては、削除候補設定部１８４は自動的に削除すべき画像を選択してもよい。以下変形例として、このような場合について説明する。

例えば内視鏡検査において、検査中に医師または看護師が誤って内視鏡システム１２の終了キーを押下した場合、検査中のオーダがクローズしてしまう。この場合、オーダの追加発行が必要となる。追加発行されたオーダは、当初のオーダとは別のオーダとなるため、それらオーダ間の確認作業や、それらオーダの統合作業が必要となる。また、ひとつの内視鏡検査において、検査の途中で内視鏡のスコープを交換することもある。スコープの交換は、内視鏡システム１２をひとたび終了することを要する場合もあり、スコープ交換後にオーダの追加発行が必要となる。

このように、ひとつの検査において追加オーダが発行された場合、それらオーダの統合作業が行われる。ここで「オーダの統合」とは、本来ひとつの検査であるものが、医用画像送信システム１０上で異なる検査として扱われている複数の検査を、ひとつの検査にまとめる作業である。具体的には、本来ひとつの検査であるものが、医用画像送信システム１０上で異なる検査ＩＤが割り振られている複数の検査を、同一の検査ＩＤに統合し、画像のシリーズ番号を再度１から割り当てる作業のことをいう。

図５は、検査ＩＤが１００である画像および検査ＩＤが１０１である画像がそれぞれ２つ存在することを示している。いま、検査ＩＤが１００である検査と検査ＩＤが１０１である検査とは本来ひとつの検査であり、これらの検査のオーダ統合をする場合を考える。このとき、医用画像送信システム１０内の図示しないオーダ統合部は、例えば検査ＩＤが１０１である画像群の検査ＩＤを１００に変更し、シリーズ番号１の画像を３、２の画像を４に変更する。これにより、検査ＩＤが１００である検査と検査ＩＤが１０１である検査とは、検査ＩＤが１００であり、シリーズ番号が１〜４までの画像として統合される。

あるいは別の方法として、オーダ統合部は、検査ＩＤが１００である検査と検査ＩＤが１０１である検査との両者に新たに共通する検査ＩＤ（例えば１０２）を割り当て、シリーズ番号画像を撮像時刻順に昇順で割り当ててもよい。これにより、検査ＩＤが１０２、シリーズ番号が１〜４までの画像として統合される。いずれにしても、オーダ統合部は統合後の各画像のヘッダ領域に統合後の検査ＩＤまたはシリーズ番号を格納する。

送信部１７０は、オーダ統合部が統合した各画像を画像保存通信システム３０に送信することで、画像保存通信システム３０には統合後の各画像データが格納される。ここで送信部１７０は、モダリティから送信される画像データを、自律的にＤＩＣＯＭデータフォーマットに変換して画像保存通信システム３０に送信する。例えば送信部１７０は、モダリティから画像データが送信される度に、ＤＩＣＯＭデータフォーマットに変換して画像保存通信システム３０に送信する。あるいは、送信部１７０は、検査が終了する度に、その監査に含まれる画像をＤＩＣＯＭデータフォーマットに変換して画像保存通信システム３０に送信する。

いずれの場合にしても、オーダ統合部が統合する時点では、検査ＩＤが１００である検査に含まれる画像と検査ＩＤが１０１である検査に含まれる画像とは、既に画像保存通信システム３０に送信されている。したがって、送信部１７０が、オーダ統合後の各画像を画像保存通信システム３０に送信すると、画像保存通信システム３０上には検査ＩＤは異なるが同一の画像が重複して格納されることになる。これは画像保存通信システム３０のデータベース３２の記憶容量を圧迫し、また画像保存通信システム３０を利用してレポートを作成しようとするユーザに困惑を与えかねない。

そこで削除候補設定部１８４は、送信部１７０が既に画像保存通信システム３０に送信した１以上の医用画像を重複して画像保存通信システム３０に送信する場合は、削除候補記憶部１７２が記憶する１以上の医用画像に対応づけられた識別子の削除候補フラグフィールド１９６の値を１に変更する。これにより、送信部１７０は、オーダ統合後の画像を画像保存通信システム３０に画像を再送信するときは、先に送信した際に使用したＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤを、再送する画像のＳＯＰ Ｉｎｓｔａｎｃｅ ＵＩＤとして使い回すことになる。これにより、画像保存通信システム３０に格納されているオーダ統合前の画像はオーダ統合後の画像で上書きされ、同一の画像が重複して格納されることが防止できる。

１ 医療情報管理システム、 １０ 医用画像送信システム、 １２ 内視鏡システム、 ２０ 送信装置、 ３０ 画像保存通信システム、 ３２ データベース、 ４０ クライアント装置、 ５０ ＭＷＭサーバ、 １００ 検査情報取得部、 １０２ 時刻情報取得部、 １０４ 患者ＩＤ取得部、 １０６ 画像データ取得部、 １３２ オーダ取得部、 １３４ 医用画像生成部、 １３６ 記憶管理部、 １４４ 画像管理部、 １５０ 記憶装置、 １５２ オーダ記憶部、 １６０ 画像データ記憶部、 １７０ 送信部、 １７２ 削除候補記憶部、 １７４ 抽出部、 １７６ 識別子生成部、 １７８ ユーザインタフェース、 １８０ 表示部、 １８０ 順次表示部、 １８２ 入力部、 １８４ 削除候補設定部。

Claims (8)

1. 医用画像の画像蓄積通信システムに所定の通信プロトコルを用いて医用画像を送信する送信部と、
   前記画像蓄積通信システムに送信した医用画像の識別子と、当該医用画像が削除対象か否かを示す削除候補情報とを対応づけて記憶する削除候補記憶部と、
   前記削除候補記憶部の削除候補情報を参照して、削除対象とされる医用画像の識別子を抽出する抽出部とを備え、
   前記送信部は、送信する医用画像に前記抽出部が抽出した識別子を対応づけて送信することを特徴とする画像管理装置。
2. 前記識別子は、前記画像蓄積通信システムが医用画像を識別するための識別子であり、
   前記画像管理装置は、前記識別子を生成する識別子生成部をさらに備え、
   前記送信部は、前記削除候補記憶部に削除対象とされる医用画像の識別子がない場合、送信する医用画像に前記識別子生成部が生成した新たな識別子を対応づけて送信することを特徴とする請求項１に記載の画像管理装置。
3. 削除候補記憶部が記憶する削除候補情報を、削除対象を示す情報に設定する削除設定部をさらに備えることを特徴とする請求項１または２に記載の画像管理装置。
4. 前記送信部が前記画像蓄積通信システムに送信した医用画像を記憶する画像データ記憶部と、
   前記画像データ記憶部が記憶する画像を表示する表示部とをさらに備え、
   前記削除設定部は、削除候補記憶部が記憶する削除候補情報のうち、前記表示部が表示する医用画像の識別子に対応づけられた削除候補情報を、削除対象を示す情報に設定する指示をユーザから取得することを特徴とする請求項３に記載の画像管理装置。
5. 前記削除設定部は、前記送信部が既に前記画像蓄積通信システムに送信した１以上の医用画像を重複して前記画像蓄積通信システムに送信する場合、前記削除候補記憶部が記憶する前記１以上の医用画像に対応づけられた識別子に対応づけられた削除候補情報を、削除対象を示す情報に設定することを特徴とする請求項３または４に記載の画像管理装置。
6. 前記医用画像はＤＩＣＯＭ（Digital Imaging and COmmunication in Medicine）規格の画像であり、
   前記所定の通信プロトコルはＤＩＣＯＭ規格の通信プロトコルであり、
   前記識別子は、ＳＯＰ（Service Object Pair）インスタンスＵＩＤ（Unique IDentifier）であることを特徴とする請求項１から５のいずれかに記載の画像管理装置。
7. 医用画像の画像蓄積通信システムに所定の通信プロトコルを用いて医用画像を送信するステップと、
   医用画像の画像蓄積通信システムに送信した医用画像の識別子と、当該医用画像が削除対象か否かを示す削除候補情報とを対応づけて削除候補記憶部に記憶するステップと、
   前記削除候補記憶部の削除候補情報を参照して、削除対象とされる医用画像の識別子を抽出するステップと、
   送信する医用画像に抽出した識別子を対応づけて送信するステップとをプロセッサに実行させることを特徴とする画像管理方法。
8. 第１画像管理装置と第２画像管理装置とを備える画像管理システムにおいて、
   前記第１画像管理装置は、
   前記第２画像管理装置から所定の通信プロトコルを用いて送信される医用画像を受信する受信部と、
   前記受信部が受信した医用画像と当該医用画像を識別する識別子とを対応づけて記憶する第１記憶部とを備え、
   前記第２画像管理装置は、
   前記第１画像管理装置に送信した医用画像の識別子と、当該医用画像が削除対象か否かを示す削除候補情報とを対応づけて記憶する第２記憶部と、
   前記第２記憶部の削除候補情報を参照して、削除対象とされる医用画像の識別子を抽出する抽出部と、
   前記第１画像管理装置に対して医用画像データを前記プロトコルを用いて送信する送信部とを備え、
   前記送信部は、送信する医用画像に前記抽出部が抽出した識別子を対応づけて送信し、
   前記第１画像管理装置の第１記憶部は、第２画像装置から医用画像および当該医用画像に対応づけられた識別子を受信し、受信した識別子で特定される医用画像を受信した医用画像で上書きすることを特徴とする画像管理システム。

Images