(57)【要約】【課題】一般的な画像データファイルをＤＩＣＯＭ規格準拠の医用画像データファイルとして、効率的に運用することができる医用画像管理システムを提供する。【解決手段】医用画像データファイルを作成し共有し管理する医用画像管理システム１において、特定の個人に関する医療関連の特定用途情報を送信する第１の情報端末装置１０と、医療関連特定用途情報を受信し医療関連特定用途情報に応じた撮像動作を行って画像データ及び一般メタデータを関連付けた一般画像データファイルを取得する第２の情報端末装置２０と、医療関連特定用途情報に基いて医療メタデータを生成し医療メタデータと一般画像データファイルとを関連付けて医用画像データファイルを生成するオブジェクト情報生成部３１ｄ，２１ｅａとを具備する。【選択図】図１
2020034999.tif 000002
【特許請求の範囲】
【請求項１】
医用画像データファイルを作成し共有し管理する医用画像管理システムにおいて、
特定の個人に関する医療関連の特定用途情報を送信する第１の情報端末装置と、
上記医療関連特定用途情報を受信し、当該医療関連特定用途情報に応じた撮像動作を行って画像データ及び一般メタデータを関連付けた一般画像データファイルを取得する第２の情報端末装置と、
上記医療関連特定用途情報に基いて医療メタデータを生成し、この医療メタデータと上記一般画像データファイルとを関連付けて医用画像データファイルを生成するオブジェクト情報生成部と、
を具備することを特徴とする医用画像管理システム。
【請求項２】
上記オブジェクト情報生成部は、上記第１の情報端末装置及び上記第２の情報端末装置との間でネットワークを介して接続されるファイルサーバーに設けられていることを特徴とする請求項１に記載の医用画像管理システム。
【請求項３】
上記オブジェクト情報生成部は、上記第２の情報端末装置に設けられていることを特徴とする請求項１に記載の医用画像管理システム。
【請求項４】
上記第２の情報端末装置は、
上記医療関連特定用途情報に応じた撮像動作を行って画像データ及び一般メタデータを関連付けた一般画像データファイルを取得する際に、取得される画像データが上記医療関連特定用途情報に対応する画像であるか否かの確認を行う確認部を、さらに具備することを特徴とする請求項１〜請求項３のいずれか一つに記載の医用画像管理システム。
【請求項５】
上記確認部による結果情報は、医用画像データファイルのメタデータとして関連付けて記録されることを特徴とする請求項４に記載の医用画像管理システム。
【請求項６】
特定の個人に関する医療関連の特定用途情報を受信する通信部と、
上記医療関連特定用途情報に応じて取得した画像データ及び一般メタデータを関連付けて一般画像データファイルを取得する画像取得部と、
上記医療関連特定用途情報に基いて生成した医療メタデータと、上記一般画像データファイルとを関連付けて医用画像データファイルを生成するオブジェクト情報生成部と、
を具備することを特徴とする医用画像取得装置。
【請求項７】
第１の情報端末装置は、特定の個人に関する医療関連の特定用途情報を送信し、
第２の情報端末装置は、上記医療関連特定用途情報を受信し、当該医療関連特定用途情報に応じた撮像動作を行って画像データ及び一般メタデータを関連付けた一般画像データファイルを取得し、
オブジェクト情報生成部は、上記医療関連特定用途情報に基いて医療メタデータを生成し、この医療メタデータと上記一般画像データファイルとを関連付けて医用画像データファイルを生成する
ことを特徴とする医用画像データファイルの取得方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、医用画像データファイルを作成し共有して管理する医用画像管理システムと、医用画像管理システムにおいて取り扱い得る医用画像データファイルを取得する医用画像取得装置と、医用画像データファイルの取得方法に関するものである。
【背景技術】
【０００２】
近年、電子画像データを含む各種の電子データを手軽に取り扱うことができ、かつ通信機能を備え、小型で携帯し得る形態の情報端末装置が一般に普及している。
【０００３】
この種の情報端末装置は、他の同種の情報端末装置との間で直接相互通信を行って各種の電子データの交換等を行うことができると共に、既存のネットワークを介して遠隔地にあるファイルサーバー等にアクセスし、当該ファイルサーバーとの間で各種の電子データ等の伝達（送受）を行うことができるように構成されている。
【０００４】
この場合において、複数の情報端末装置と、各種の電子データ等を蓄積したファイルサーバーとの間を、既存のネットワークを介して相互に接続するためには、各種の情報通信技術（ＩＣＴ；Information and Communication Technology）が利用される。これにより、各情報端末装置間で、さまざまな電子データ等を取り扱うことができ、これらの電子データ等を共有することができるようなネットワークシステムが構成されている。そして、この種のネットワークシステムは、各種の分野において一般に実用化され急速に普及しつつある。
【０００５】
この種のネットワークシステムの一形態としては、例えば医療分野において、医療従事者等（例えば医師，看護師，各種専門技師（機器の取り扱い有資格者等），介護福祉士等といった医療関係の各種の有資格者等）が情報端末装置を用いて、ネットワークを介して病院等の医療施設に設置されたファイルサーバーにアクセスし、当該ファイルサーバーとの間で相互通信を行って、医療関連情報（例えば電子カルテ情報や患者情報等）を共有し得るように構築されたデータ管理システムが実用化されている。
【０００６】
具体的には、例えば、病院情報システム（ＨＩＳ；Hospital Information System）は、診療受付や診療予約システム，電子カルテシステム，医事会計システム，入退院管理や薬局等の管理システム等、病院業務行うための各種のシステムを統括して管理するためのシステムである。
【０００７】
また、放射線科情報システム（ＲＩＳ；Radiology Information System）は、放射線検査オーダー管理，検査予約管理，撮影装置に対する患者情報や撮影実施情報の管理，フィルム管理等、病院内における放射線部門に関連する業務を管理するためのシステムである。
【０００８】
一方、近年の医療分野においては、医用画像を電子的なデジタル画像データとして扱う各種の形態の医用画像取得装置が実用化され広く普及している。
【０００９】
ここで、医用画像とは、具体的には例えば、放射線画像（Ｘ線画像），コンピュータ断層撮影（ＣＴ；Computed Tomography）画像，ＭＲＩ画像（magnetic resonance imaging），超音波断層画像，血管造影画像，内視鏡画像，サーモグラフィー，顕微鏡画像等がある。また、これらのほかにも、一般的な通信機能付き撮像装置（デジタルカメラ等）や撮像通信機能付き情報端末装置（スマートフォン，タブレットＰＣ等）等の画像取得装置を用いて取得される一般撮影画像等を含む場合もある。
【００１０】
そして、各種の医用画像取得装置によって取得された様々な形態の医用画像データファイルは、例えば、画像保存通信システム（ＰＡＣＳ；Picture Archiving and Communication Systems）等の医用画像管理システム等によって統括的に管理されるようになっている。
【００１１】
この種の医用画像管理システムは、複数の医用画像取得装置や情報端末装置等によって取得された複数の医用画像データファイルをネットワーク経由等によって受信して、システムに含まれる画像ファイルサーバーに保存してデータベース化すると共に、各種の端末装置からの要求に応じて当該画像ファイルサーバーに記録された各種のデジタルデータファイルのうち対応するデータファイルを、要求元の端末装置へと転送する機能等を有する。なお、これを受けた端末装置では、受信したデータファイルを所定の形態で表示する。
【００１２】
この種の医用画像管理システムにおいて、複数の医用画像取得装置等や複数の情報端末装置等との間でデジタル画像データを送受信するための標準的なネットワーク通信規格のひとつとして、例えばＤＩＣＯＭ（Digital Imaging and Communications in Medicine）規格とよばれるものが、近年、広く普及している。そして、ＤＩＣＯＭ規格に準拠した医用画像データ形式（以下、ＤＩＣＯＭ準拠データ形式という）のオブジェクト（画像データ）を閲覧（参照）したり管理するための医用画像観察装置が医療分野において広く普及している。
【００１３】
しかしながら、医療分野で扱われる電子データには、医用画像データ以外にも各種の電子データが存在しており、それらの中には、ＤＩＣＯＭ規格に準拠していないデータ形式（ＤＩＣＯＭ非準拠データ形式）のオブジェクト（電子データ）が多くある。
【００１４】
そこで、例えばＤＩＣＯＭ準拠データ形式のオブジェクト（電子画像データ）を閲覧（参照）したり管理するための医用画像観察装置を用いて、ＤＩＣＯＭ非準拠データ形式の各種オブジェクト（電子データファイル）を閲覧（参照）し得るようにし、また、それらのオブジェクトを管理するための医用画像管理システムが、例えば特開２０１６−３５７１７号公報等によって、種々の形態のものが提案されている。
【００１５】
上記特開２０１６−３５７１７号公報等によって開示されている医用画像管理システムは、ＤＩＣＯＭ非準拠データ形式の医用オブジェクトを、ＤＩＣＯＭ準拠データ形式の医用オブジェクトへと変換することで、ＤＩＣＯＭ規格の管理体系に従って各種の電子データの管理を行うことができるようしている。
【００１６】
これにより、診療情報提供書、診断書、病理検査結果、自院のペーパー類、他院からの紹介状、保険証のコピー、電子カルテ等の特定規格に非準拠のデータを特定規格で扱えるようにしているが、非準拠であるがゆえに、特定規格が求める要件を満たさない場合の挽回ができないという問題があった。
【００１７】
一方、従来の情報端末装置としては、例えば電子画像データを取得する撮像機能を備え通信機能をも備えたデジタルカメラ等の撮像装置や、スマートフォン，タブレットＰＣ等の撮像通信機能付き情報端末装置等、各種の形態の画像取得装置が広く普及している。
【００１８】
これら撮像通信機能付き情報端末装置（画像取得装置）は、撮像動作を行うことによって所定のファイルフォーマットに準拠した画像データファイルを取得し記録することができるように構成されている。
【００１９】
この種の情報端末装置（画像取得装置）によって取り扱われる画像データファイルの代表的なファイルフォーマットとしては、例えばＥｘｉｆ（Exchangeable image file format）規格とよばれるものが広く普及している。このＥｘｉｆ規格では、画像データ本体と、これに付随する付随情報であるメタデータとによって一つの画像データファイルを構築するように規定されている。この画像の規格も通常においては、上記特定規格を意識することなく、例えば医療画像用の規格などは満たしていない場合があり得る。
【先行技術文献】
【特許文献】
【００２０】
【特許文献１】特開２０１６−３５７１７号公報
【発明の概要】
【発明が解決しようとする課題】
【００２１】
通常の端末装置（一般画像取得装置）の画像の規格は、通常においては、例えば医療画像用の規格などは満たしていない場合があり得る。
【００２２】
ところが、上記特開２０１６−３５７１７号公報等によって開示されている医用画像管理システムは、電子画像データファイル以外のＤＩＣＯＭ非準拠データ形式の医用オブジェクト（即ち各種の電子データファイル、例えばワード（登録商標）形式，エクセル（登録商標）形式，テキスト形式，ＰＤＦ（Portable Document Format）形式等の電子文書ファイル等）を対象とし、これらを閲覧し参照し管理することを目的としている。
【００２３】
したがって、上記公報に開示されているシステムでは、一般的な電子画像データファイルのファイルフォーマット（例えばＥｘｉｆ規格等）についての言及は特になく、これを取り扱うことについては特段の記載がなく、考慮もされていない。
【００２４】
一般に、患者情報として正式に認められる医用画像は、医師から複数の指示を含む情報を受けて、所定の医療関係の有資格者（医療従事者）が、所定の医療画像機器を用いて、規定の設定やフォーマットに基づいて取得した画像情報のみとするのが前提となる。
【００２５】
したがって、所定の医療関係の資格を有しない人物（例えば患者の家族や近親者等の介護者若しくは患者本人等；以下、これらを非医療従事者というものとする）が、例えば一般的な形態の撮像装置等（例えばデジタルカメラ等）や、一般に普及している通信端末装置（例えばスマートフォン，タブレット型ＰＣ等）を用いて取得した患部や症状等を写した画像は、正式な医用画像として扱うことができないのが普通である。
【００２６】
しかしながら、近年、高解像度の画像を気軽に取得することができる撮像機能を有すると共に、通信機能を具備しかつ携帯に適した小型の通信端末装置（具体的には例えばスマートフォンやタブレット型ＰＣ等）が、一般に広く普及している。
【００２７】
さらに、デジタルカメラ等の撮像装置においても、通信機能を具備したものが実用化されている。以下の説明においては、これらの通信機能付き撮像装置や撮像機能付き通信装置等をまとめて情報端末装置又は画像取得装置、一般画像取得装置などというものとする。
【００２８】
このように、近年においては、誰もがいつでも高解像度の画像を取得することができ、かつ、取得された画像データは、同様の情報通信端末装置を所持する他者との間で、容易に共有することができる環境が整っている。
【００２９】
そこで、例えば医療従事者のみに限らず、非医療従事者が、例えば自己所有の一般的な形態の情報端末装置（例えばデジタルカメラやスマートフォン，タブレット型ＰＣ等）を用いて取得した画像データを、患者情報としての医用参照画像として取り扱うことができるようになれば至便である。
【００３０】
そのために、例えば、画像データのファイルフォーマット等（保存形式）を、既存の医療用ネットワーク規格（例えばＤＩＣＯＭ規格等）に準拠した形式とすることができれば、対応する既存の医療用ネットワークを用いて、医師等の医療従事者との間でデータ共有を行うことができるようになる。
【００３１】
一方、一般的な形態の通信機能付き撮像装置（デジタルカメラ等）や撮像通信機能付き情報端末装置（スマートフォン，タブレットＰＣ等）等の画像取得装置によって生成される電子画像データファイルは、通常、Ｅｘｉｆ規格に準拠したものが一般である。このＥｘｉｆ規格準拠のデータ形式は、ＤＩＣＯＭ規格に対して非準拠のデータ形式である。
【００３２】
したがって、一般的な形態の通信機能付き撮像装置（デジタルカメラ等）や撮像通信機能付き情報端末装置（スマートフォン，タブレットＰＣ等）等の画像取得装置を用いて取得されたＥｘｉｆ規格準拠のデータ形式のオブジェクト（画像データファイル）を、現在医療分野で広く用いられているＤＩＣＯＭ準拠データ形式に対応の医用画像観察装置を用いて、医用オブジェクト（医用画像データファイル）として取り扱おうとする場合、当該オブジェクト（画像データファイル）に付随する付随情報（メタデータ）を正確に取り扱うことができない場合があるという問題点がある。
【００３３】
なお、従来においては、例えば病院情報システム（ＨＩＳ）等で入力した患者情報等の各種の情報を、撮影済み画像データの付随情報（メタデータ）に付加したり、ＤＩＣＯＭ準拠データ形式の画像データを他のデータ形式（例えば画像保存通信システム（ＰＡＣＳ）準拠のデータ形式）に変換する等、電子画像データファイルについての編集操作を行って、各種のシステム同士の連携や画像データの一括管理等を、ＤＩＣＯＭ規格に準拠した装置を用いて実現するためのソフトウエアアプリケーション等も実用化されている。
【００３４】
しかしながら、データファイルの変換を行う手段では、画像データファイルの取得後に変換作業を行う必要があることから、取得した画像データファイルを即座に利用することができない。よって、そのようなシステムでは、画像データファイルを効率的に運用することができないという問題点がある。
【００３５】
本発明は、上述した点に鑑みてなされたものであって、その目的とするところは、一般に普及している画像取得装置（デジタルカメラ等の通信機能付き撮像装置やスマートフォン，タブレットＰＣ等の撮像通信機能付き情報端末装置等）を用いて取得された一般的な画像ファイルフォーマットのオブジェクト（画像データファイル）を、ＤＩＣＯＭ規格に準拠したデータ形式の医用オブジェクト（医用画像データファイル）として、効率的に運用することができる医用画像管理システム，医用画像取得装置，医用画像の取得方法を提供することである。
【００３６】
つまり、本発明は、通常の端末装置（一般画像取得装置）の画像の規格を、例えば医療画像用の規格が求める条件を満たすようにする医用画像管理システム，医用画像取得装置，医用画像の取得方法を提供することである。通常端末を医用画像取得装置のように扱うことも可能となり、より、自由度のある、より情報量を増やす対応を可能にしている。
【課題を解決するための手段】
【００３７】
上記目的を達成するために、本発明の一態様の医用画像管理システムは、医用画像データファイルを作成し共有し管理する医用画像管理システムにおいて、特定の個人に関する医療関連の特定用途情報を送信する第１の情報端末装置と、上記医療関連特定用途情報を受信し、当該医療関連特定用途情報に応じた撮像動作を行って画像データ及び一般メタデータを関連付けた一般画像データファイルを取得する第２の情報端末装置と、上記医療関連特定用途情報に基いて医療メタデータを生成し、この医療メタデータと上記一般画像データファイルとを関連付けて医用画像データファイルを生成するオブジェクト情報生成部と、を具備する。
【００３８】
本発明の一態様の医用画像取得装置は、特定の個人に関する医療関連の特定用途情報を受信する通信部と、上記医療関連特定用途情報に応じて取得した画像データ及び一般メタデータを関連付けて一般画像データファイルを取得する画像取得部と、上記医療関連特定用途情報に基いて生成した医療メタデータと、上記一般画像データファイルとを関連付けて医用画像データファイルを生成するオブジェクト情報生成部と、を具備する。
【００３９】
本発明の一態様の医用画像データファイルの取得方法は、第１の情報端末装置は、特定の個人に関する医療関連の特定用途情報を送信し、第２の情報端末装置は、上記医療関連特定用途情報を受信し、当該医療関連特定用途情報に応じた撮像動作を行って画像データ及び一般メタデータを関連付けた一般画像データファイルを取得し、オブジェクト情報生成部は、上記医療関連特定用途情報に基いて医療メタデータを生成し、この医療メタデータと上記一般画像データファイルとを関連付けて医用画像データファイルを生成する。
【発明の効果】
【００４０】
本発明によれば、一般に普及している画像取得装置（デジタルカメラ等の通信機能付き撮像装置やスマートフォン，タブレットＰＣ等の撮像通信機能付き情報端末装置等）を用いて取得された一般的な画像ファイルフォーマットのオブジェクト（画像データファイル）を、ＤＩＣＯＭ規格に準拠したデータ形式の医用オブジェクト（医用画像データファイル）として、効率的に運用することができる医用画像管理システム，医用画像取得装置，医用画像の取得方法を提供することができる。
【００４１】
つまり、本発明においては、通常の端末装置（一般画像取得装置）のサイドから見れば、その端末の例えば撮影画像や取得画像を、例えば医療画像用の規格が求める条件を満たすようにできる画像管理システム，画像取得装置，画像の取得方法を提供することができる。
【図面の簡単な説明】
【００４２】
【図１】本発明の一実施形態の医療支援システムの概要構成を示す概念図
【図２】本発明の一実施形態の医療支援システムの作用の第１使用パターンを説明する概念図
【図３】本発明の一実施形態の医療支援システムの作用の第２使用パターンを説明する概念図
【図４】本発明の一実施形態の医療支援システムの作用の第３使用パターンを説明する概念図
【図５】本発明の一実施形態の医療支援システムにおける情報端末装置の主要構成を示すブロック構成図
【図６】本発明の一実施形態の医療支援システムにおけるファイルサーバーの主要構成を示すブロック構成図
【図７】本発明の一実施形態の医用画像管理システムにおいて生成される画像データファイルの構成を概念的に示す図
【図８】本発明の一実施形態の医用画像管理システムにおいて第２端末で本人確認を行う際のようすを示す概念図
【図９】本発明の一実施形態の医用画像管理システムにおいて第２端末の「本人確認メニュー」の表示例を示す図
【図１０】本発明の一実施形態の医用画像管理システムにおいて各種の情報の流れを概念的に示す概念図
【図１１】本発明の一実施形態の医療支援システムにおける情報端末装置のうち情報端末装置のうち第２端末の作用を示すフローチャート（前半）
【図１２】本発明の一実施形態の医療支援システムにおける情報端末装置のうち情報端末装置のうち第２端末の作用を示すフローチャート（後半）
【図１３】本発明の一実施形態の医療支援システムにおける情報端末装置のうち情報端末装置のうち第１端末の作用を示すフローチャート
【図１４】本発明の一実施形態の医療支援システムにおけるファイルサーバーの作用を示すフローチャート（前半）
【図１５】本発明の一実施形態の医療支援システムにおけるファイルサーバーの作用を示すフローチャート（後半）
【発明を実施するための形態】
【００４３】
以下、図示の実施の形態によって本発明を説明する。以下の説明に用いる各図面は模式的に示すものであり、各構成要素を図面上で認識できる程度の大きさで示すために、各部材の寸法関係や縮尺等を構成要素毎に異ならせて示している場合がある。したがって、本発明は、各図面に記載された各構成要素の数量や各構成要素の形状や各構成要素の大きさの比率や各構成要素の相対的な位置関係等に関して、図示の形態のみに限定されるものではない。
【００４４】
［一実施形態］
本発明の一実施形態の医用画像管理システムは、例えば病院等の医療施設において利用されているネットワーク（既存の外部ネットワークまたは院内ネットワーク）と、情報端末装置や画像取得装置とによって、医療関連情報、特に医用画像データファイル（医用オブジェクト）の共有と管理を行う画像管理システムにおいて、一般に普及している通常形態の画像取得装置（例えばデジタルカメラ等の通信機能付き撮像装置やスマートフォン，タブレットＰＣ等の撮像通信機能付き情報端末装置等；以下、これらをまとめて一般画像取得装置という）によって取得されたＤＩＣＯＭ規格に準拠していないデータ形式（以下、ＤＩＣＯＭ非準拠データ形式という）のオブジェクト（画像データファイル）を、医用オブジェクト（医用画像データファイル）として取り扱うことができるようにして、医用画像データファイルの効率的な運用と管理を容易とするネットワークシステムの一例である。
【００４５】
このような環境を想定するにおいて、本発明の実施形態においては、一般画像取得装置の撮影画像や取得画像を、例えば医療画像用の規格が求める条件、例えば、医師の指示（患者情報なども含む）やその結果の画像、医用管理データセットの条件を満たすようにできる画像管理システム，画像取得装置，画像の取得方法を提供することができるように、一般画像と医用画像の大きな差異であるオーダー情報（上記、医師の指示による画像であることを示す情報を含む特定の個人に関する医療関連の特定用途情報）を付与できるようにしている。
【００４６】
医用画像データファイル（医用オブジェクト）は、医用管理データセットを構成するので、医用管理データセットを作成可能な画像ファイルを作成する一般画像取得装置において、医用管理データセットの第１の部分を構成する画像データを撮像する撮像部に加え、上記医用管理データセットの第２の部分を構成するオーダー情報（特定の個人に関する医療関連の特定用途情報など）を外部から取得する通信部を有し、上記医用管理データセットの第１と第２の部分をファイルとして記録する記録制御部を有することが好ましい。
【００４７】
つまり、本発明においては、通常の端末装置の画像の規格を、例えば医療画像用の規格が求める条件を満たすようにすることができる。
【００４８】
具体的には、本実施形態の医用画像管理システムは、従来のネットワークシステムにおいて実現している機能（即ち、「医用画像取得装置（＊１）」を用いて取得された「医用画像（＊３）」等の画像データを含む患者情報等の医療関連情報のデータ共有機能）に加えて、「一般画像取得装置（＊２）」を用いて取得された画像データのうち特定の用途（医療用途）に供するための情報としての画像データ（即ち「医用画像（＊３）」，「医用参照画像（＊４）」等の画像データ）を含む患者情報等の医療関連情報のデータ共有を実現して、医用画像データの管理を容易ならしめるためのネットワークシステムである。
【００４９】
（＊１「医用画像取得装置」）
ここで、「医用画像取得装置」とは、特定分野（ここでは医療分野）の現場で使用されることに特化して構成される画像取得用装置である。具体的には、例えば、Ｘ線撮影装置（ＣＴ撮影装置，血管造影撮影装置を含む），ＭＲＩ装置，超音波断層撮影装置，内視鏡装置，サーモグラフィー装置，顕微鏡撮影装置等の機器が相当する。
【００５０】
これらの医用画像取得装置は、主に医療分野の施設（例えば病院等）に設置され、医療関係の有資格者（例えば医師，看護師，各種専門技師等のいわゆる医療スタッフを指すものとする。以下、医療従事者という）のみが使用することによって「医用画像（＊３）」（後述）を取得するための機器である。
【００５１】
一般に、これらの医用画像取得装置は、医師を含む医療従事者以外の人物が使用することを想定していない。したがって、これらの医用画像取得装置によって取得される画像データファイルは、全て「医用画像（＊３）」（後述））として承認され、例えばＤＩＣＯＭ規格に準拠したデータ形式の医用オブジェクト（医用画像データファイル）として扱い得るものである。
【００５２】
（＊２「一般画像取得装置」）
「一般画像取得装置」とは、従来の「医用画像取得装置」以外の画像取得装置であって、かつ一般に普及している通常形態の画像取得装置（例えばデジタルカメラ等の通信機能付き撮像装置又はスマートフォン，タブレットＰＣ等の撮像機能付き情報端末装置等）を主に想定している。
【００５３】
この場合において、当該「一般画像取得装置」は、
（１）医療施設に常備され、その医療施設に所属する医療従事者が使用する場合と、
（２）医療従事者以外の人物（例えば患者の家族や近親者等の介護者若しくは患者本人等；以下、これらを非医療従事者というものとする）が所有し、その所有者若しくは近親者等の非医療従事者が使用する場合と、
を想定している。
【００５４】
したがって、「一般画像取得装置」によって取得される画像としては、医療従事者の使用により取得される「医用画像（＊３）」（後述）と、非医療従事者の使用により取得される「医用参照画像（＊４））」（後述）とがある。
【００５５】
（＊３「医療用画像」）
「医用画像」とは、医療従事者としての医師によって発行された「医療オーダー情報（＊５）」に従って、医師を含む医療従事者が、所定の医画像取得装置を使用して取得された画像情報をいう。この医用画像は、本実施形態の医用画像管理システムにおいて取り扱われる患者情報の一部として承認され得る画像情報である。その医用画像は、例えば患部，症状などを画像として表す画像データ本体と、当該画像データ本体に付随する「付随情報（メタデータ）（＊７）」を含んで形成される画像データファイルの形態を有する。
【００５６】
本実施形態のシステムで扱う医用画像のデータファイルとしては、具体的には、例えばＤＩＣＯＭ規格に準拠したデータ形式の医用オブジェクト（医用画像データファイル）の形態を想定している。
【００５７】
この医用画像が取得される際の状況としては、具体的には、次のような状況が考えられる。例えば、
（１）医療従事者としての医師が、自身の診療方針（「医療オーダー情報（＊５）」（後述）に対応する情報）に基づいて、自身で所定の医用画像取得装置を使用して画像を取得する場合（例：内視鏡画像，超音波断層画像等）、
（２）医療従事者としての医師が、他の医師の「医療オーダー情報（＊５）」（後述）に従って所定の医用画像取得装置を使用して画像を取得する場合（例：内視鏡画像，超音波断層画像等）、
（３）医師以外の医療従事者（主に専門技師等）が、医療従事者としての医師の「医療オーダー情報（＊）５」（後述）に従って所定の医画像取得装置を使用して画像を取得する場合（例：Ｘ線画像，ＣＴ画像，ＭＲＩ画像等）、等がある。
【００５８】
（＊４「医療用参照画像」）
「医用参照画像」とは、医師及び専門技師以外の医療従事者であって医画像取得装置を取り扱うための特定資格を有していない一般の医療スタッフ（例えば看護師，介護福祉士等；以下、一般医療スタッフという）や非医療従事者が、医師から受けた「医療オーダー情報（＊５）」（後述）又は「一般オーダー情報（＊６）」に従って、「一般画像取得装置」を使用して取得された画像情報をいう。
【００５９】
この医用参照画像は、本実施形態の医用画像管理システムにおいて取り扱われる患者情報として認められ得る程度の信頼性を備えた参照用の画像情報である。この医用参照画像は、医師が診断等の医療行為を行う際に、医用画像を含む正規の患者情報と共に参照される情報となる。
【００６０】
この医用参照画像は、上述したように、一般医療スタッフや非医療従事者によって取得された画像であることから、正式な患者情報としての「医用画像」としては承認され得ないものである。しかしながら、この医用参照画像は、医師が診療等の医療行為の際に参考とする情報としては充分な信頼性を備えているものと認定し得る画像情報であることから「参照」との文言を付して呼称するものである。
【００６１】
医用参照画像の画像情報には、医用画像と同様に、例えば患部，症状などを画像として表す画像データ本体と、当該画像データ本体に付随する「付随情報（メタデータ）（＊７）（後述）」を含んで形成される。
【００６２】
（＊５「医療オーダー情報」）
「医療オーダー情報」とは、例えば、以下に示すようなものである。即ち、通常の場合、医師は、治療，診療，検査等の対象とする患者（以下、対象患者という）に対し診察を行った後には、院内端末装置（例えば病院の診察室（医療施設）等に設置されたＰＣ等の端末装置）を用いて、病院内ネットワークを介して、当該病院等の医療施設に設置されているファイルサーバーにアクセスし、当該ファイルサーバーに蓄積されている電子カルテデータベースの中から、対象患者の電子カルテファイルを読み出し、この電子カルテファイルに対して本日の診察記録等を行う。その際に、当該医師は合わせて、次の検査等の一つ又は複数の指示を出すことがある。
【００６３】
そのために、医師は、当該院内端末装置を用いて所定のオーダー情報指示用メニュー画面を開き、このオーダー情報指示用メニュー画面から所望する検査等に対応する各種の指示情報を作成する。この場合において、特定の対象患者に対する特定の検査等に応じた複数の医療行為としての具体的な作業指示を含む指示情報群を「医療オーダー情報」というものとする。
【００６４】
この医療オーダー情報は、例えば、複数の撮影種別（例えばＸ線撮影，ＣＴ，ＭＲＩ，内視鏡検査，超音波検査，一般撮影など）の中から所望の撮影項目を選択指示したり、所望の撮影部位（例えば、胸部，腹部，頭部，肘関節等）を対象患者に応じて選択指示するほか、例えば、左膝の正面と側面等といった具体的な撮影に関する指示を行う。さらに、必要に応じて細かな指示がある場合には、例えばコメント欄等に詳細指示を記載する。
【００６５】
ここで、医療オーダー情報の詳細な指示の一例としては、次のようなものがある。
【００６６】
例えば、所定の対象患者についての「患部の傷口の経過を観察する画像を撮影する医療オーダー情報」とする場合、その詳細な指示は、
（１）マクロモード（撮影倍率１：２）で撮影する、
（２）肌の色を判断したいので、所定の色票（カラーチャート）を入れて撮影する、
などがある。
【００６７】
また、静止画像の撮影を行う指示のみではなく、例えば動画像の撮影を行う指示や、音声を含む静止画像又は動画像の撮影を行う指示等を行うことも考えられる。
【００６８】
このようして作成された医療オーダー情報は、対象患者の患者情報（患者ＩＤ等）に関連付けされた上で、検査を取り扱う対応部署に設置され、当該部署に所属する医療従事者等が使用する端末装置へ転送される。
【００６９】
ここで、医療現場における医療オーダー情報は、「いつ」「どこで」「誰が」「誰に対して」「どの様な装置で」「どの様な検査を」行うのか等の各種情報を含んで形成されるのが普通である。
【００７０】
上記「いつ」については、例えば年月日及び時間等の日時情報が相当する。
【００７１】
上記「どこで」については、院内若しくは関連医療施設等、行われる検査に対応する装置や機器が設置されている場所情報が相当する。
【００７２】
上記「誰が」については、院内における診療部門や検査担当者などが相当する。
【００７３】
上記「誰に対して」については、電子カルテに書かれているような対象患者に関する各種の情報、例えば生年月日，性別，血液型等の対象患者の患者基本属性情報や患者ＩＤ等である。
【００７４】
こうした情報は、院内システム若しくは医師等から発行されるものであるが、個人情報の取り扱い等を留意すると、全ての情報を医療オーダー情報に含める必要はなく、必要最小限の項目の情報だけでもよい。
【００７５】
上記「どの様な装置で」については、Ｘ線撮影装置，ＣＴ，ＭＲＩ，内視鏡，撮像装置（カメラ），情報端末装置（スマートフォン等）等が相当する。
【００７６】
「どの様な検査を」については、対象患者の部位（例えば胸部，脚部等）に対して、どの程度の範囲で、何枚の画像を取得するか等の情報である。
【００７７】
さらに具体的には、例えば、撮像装置や情報端末装置等を用いて所定患部に対する外観の一般撮影を行う場合を例示すると、画像撮影時の構図，患部までの距離，焦点距離（画角），撮影倍率，露出，ピント，絞り，シャッター速度，補助光の有無等の各種の撮影パラメータや、画質（解像度）設定，画像サイズ設定，ファイルフォーマット設定（圧縮画像，非圧縮画像等），撮影枚数の設定などが相当する。なお、これらの情報は、「どのような装置で」の項目情報に含めるようにしてもよい。
【００７８】
このように医療オーダー情報には様々な情報が含まれるが、医療オーダー情報を一覧としてまとめたオーダリングリスト等に従って、検査や処置を実施できるように、表示等を出しながら撮影を促し、当該オーダリングリストに従って、順次撮影していくといった撮影手順等を含めてもよい。この場合、撮り忘れや効率性の点でメリットがある。
【００７９】
なお、上記患者基本属性情報は、「管理用付帯情報」，「診療用付帯情報」，「診療管理情報」等と呼ぶこともできる。
【００８０】
例えば、同じ対象患者であっても、病気や怪我等の症状毎に異なる（スタディが異なる）場合があり、その都度、異なる状況の検査（撮影を含む対応）が必要になる場合がある。したがって、これらを、その都度、区別できるようにすることが必要になる。例えば、年度毎に健診を行うといった場合には、各年度毎に異なるスタディ情報として取り扱うことが考えられる。
【００８１】
以下に説明する実施形態においては、上記説明したような情報を一括して医療オーダー情報として説明している。しかしながら、その全ての情報が各状況単位毎に毎度毎度必須の項目となるわけではなく、対応する状況に応じて必要となる一部の情報のみを、適宜採用すればよい。
【００８２】
このように、医療行為的な一つ又は複数の指示をまとめた情報群を医療オーダー情報というものとする。そして、この医療オーダー情報は、医師により作成されるものである一方、この医療オーダー情報を受けて、この医療オーダー情報に含まれる指示を実行するのは医師を含む医療従事者のみである。
【００８３】
簡略に言うと、医療オーダー情報は、医療従事者としての医師が作成し、当該医師から他の医師を含む医療従事者（主に専門技師等）へ宛てて出される一つ又は複数の医療行為としての具体的な作業指示を含む指示情報群である。
【００８４】
（＊６「一般オーダー情報」）
「一般オーダー情報」とは、医療従事者としての医師が、特定の用途に供するために作成する情報群（具体的には医療行為的な一つ又は複数の指示をまとめて作成する情報群）のうち主に非医療従事者へ宛てて出される情報群である。一般オーダー情報は、上記医療オーダー情報に準拠する内容を持つ特定用途情報群であって、宛先が異なるものである。
【００８５】
一般オーダー情報は、医師が作成する情報群であり、その情報の内容は、上記医療オーダー情報と何ら異なるものではない場合もある。例えば、医師が出すオーダー情報には、特殊機材を用いることなく、特殊技能や専門知識がなくても、実行し得る指示もある。具体的には、例えば、一般的な外観写真を撮るといった指示などは、一般の非医療従事者であっても、比較的容易に実行し得ることである。
【００８６】
このような指示を含む情報群を、一般の非医療従事者に宛てて、医師が出す情報を、一般オーダー情報というものとしている。
【００８７】
一般に、上記医療オーダー情報は、一般の非医療従事者が受けたとしても、実行することが不可能な内容（機材面や専門知識、資格的な面において）が多い場合がほとんどである。その一方で、一般オーダー情報は、宛先対象として、はじめから一般の非医療従事者を想定しているので、限定的な指示内容のものになる。
【００８８】
したがって、例えば、一般オーダー情報を受信して実行する人物が、一般の非医療従事者ではなく、例えば医師若しくは専門技師等の医療従事者であっても構わない。このように、医師等の医療従事者が一般オーダー情報を受けて実行する場合には、その一般オーダー情報は、医療オーダー情報と呼んでも差し支えない。そして、この場合に取得される情報（例えば画像）は医用情報（画像）として扱うこともできる。
【００８９】
簡略に言えば、一般オーダー情報と医療オーダー情報との違いは、想定する主な受け手が異なる点にある。想定する受け手が異なるということは、その情報内容についても、受け手に応じて異なるものであるのは当然である。
【００９０】
（＊７「付随情報」）
上記「付随情報」とは、各種の画像データに付随する付随情報、即ちメタデータである。この付随情報は、画像データファイル内の所定の領域に一体に記録される。本発明で取り扱われる医用画像若しくは医用参照画像の画像データにおける付随情報は、画像データ本体に関する基本情報（例えば撮影時の機器設定情報，画像フォーマット情報等）のほか、画像データファイルの個別情報（患者情報，対象とする症例，患部に応じて予め設定されている撮影条件情報等）を含むように構成される。なお、画像データファイルは、画像データ本体と、当該付随情報とによって構成され、これらは、上述のしたように一体とされて、一つの画像データファイルの形態で存在する。また、これとは別の形態として、付随情報は、画像データファイルに関連付けた別ファイルとして記録するような形態であってもよい。
【００９１】
本実施形態の医用画像管理システムにおける情報端末装置の医療施設外での使用例としては、遠隔医療や訪問医療あるいは在宅医療を想定することができる。その場合、例えば症状などを記録するために、在宅患者の患部等を撮影し、画像データを取得するといった行為を医療行為のひとつとして行うことが考えられる。
【００９２】
例えば、自宅等の医療施設以外の場所に患者が存在する在宅医療の場合には、必要な医療機器を十分に揃えることができない状況であることが多い。それは、医療機器の多くは、医療施設等に固定して利用される形態の非可搬性の大型装置であるからである。また、可搬性を有する小型の医療機器であっても、医療機器は用途が限定された専用機器であることが多いため、医師や医療スタッフが、常に多種類の医療機器を持ち運ぶことは容易ではない。
【００９３】
したがって、在宅医療を支援するためには、例えば、一般的に普及しているコンシューマ製品（例えばデジタルカメラ等の通信機能付き撮像装置や撮像機能付きスマートフォン，タブレットＰＣ等の情報端末装置等の一般画像取得装置）を利用することが考慮される。なぜならば、この種の一般的な撮像通信機能付き情報端末装置は、近年、患者やその家族等が普通に所有しており、常に携帯しているものであるからである。
【００９４】
そのために、これらの情報端末装置を用いて医療行為に準じた患者の画像を取得しようというときには、上記医療オーダー情報や上記一般オーダー情報に含まれる情報を利用することができれば、撮影者が非医療従事者であったとしても、取得された画像データの信頼性を担保することができるようにもなる。
【００９５】
また、病院等の医療施設において、これらの一般的な撮像通信機能付き情報端末装置等の画像取得装置を備えておけば、医師や看護師等の医療従事者が患者宅への訪問時（往診時等）に、これを持ち出して使用することもできる。この場合には、当該情報端末装置を操作するのは医療従事者であるので、取得される画像の信頼性は充分に確保できる。
【００９６】
このような状況を想定した本発明の一実施形態の医用画像管理システムについての概念を、図１を用いて以下に説明する。図１は、本発明の一実施形態の医用画像管理システムの概要構成を示す概念図である。
【００９７】
本実施形態の医用画像管理システム１は、図１に示すように、複数の情報端末装置１０，２０と、ファイルサーバー３０と、これらを相互に接続するために設けられるネットワーク４０等によって主に構成されている。
【００９８】
この場合において、複数の情報端末装置１０，２０は、それぞれが相互に直接通信が可能であると共に、それぞれがネットワーク４０を経由してファイルサーバー３０との間でデータ通信を行うことができるように構成されている。
【００９９】
複数の情報端末装置１０，２０同士の直接通信手段としては、例えば、既存の近距離無線通信手段（Bluetooth：ブルートゥース（登録商標））若しくは有線通信手段（ケーブル接続による相互通信）等が適用される。
【０１００】
また、複数の情報端末装置１０，２０とファイルサーバー３０との間の通信を行うためのネットワーク４０は、例えば、インターネット等の既存の一般的なネットワークや、専用回線を用いた専用ネットワーク等を適用することができる。
【０１０１】
また、ファイルサーバー３０は、例えば既存の病院情報システム（ＨＩＳ；Hospital Information System）等に含まれるファイルサーバー等に相当するものである。つまり、このファイルサーバー３０は、例えば病院等の医療施設に設置され、患者情報等をはじめとした各種の医療情報を蓄積したデータ蓄積装置である。ファイルサーバー３０は、病院内の院内ネットワーク及びインターネット等の外部ネットワークを含むネットワーク４０に接続されている。
【０１０２】
複数の情報端末装置１０，２０は、それぞれが画像情報を取得することができる撮像機能を備えていると共に、各情報端末装置同士の直接通信機能のほか、ネットワーク４０を介した通信機能を具備し、小型でかつ携帯可能に構成される電子機器である。
【０１０３】
複数の情報端末装置１０，２０の具体的な形態としては、例えば通信機能付きの撮像装置（例えばデジタルカメラ等）や、撮像機能付きの通信装置（例えばスマートフォン，タブレット型ＰＣ等）を想定している。
【０１０４】
図１に示す例では、複数の情報端末装置１０，２０のうち、符号１０で示す情報端末装置を、符号１１０で示す人物（例えば医療従事者としての医師；以下、医師１１０というものとする）が使用する情報端末装置としている。以下の説明において、これを第１の情報端末装置であり第１端末１０と表記するものとする。また、図１において、第１端末１０は、例えばタブレット型ＰＣの形態として図示している。
【０１０５】
一方、複数の情報端末装置１０，２０のうち、符号２０で示す情報端末装置を、符号１２０で示す人物（例えば患者家族等の非医療従事者である人物、患者をケアする人、もちろん、医療従事者であってもよい；以下、わかりやすく患者家族等１２０というものとする）が使用する情報端末装置としている。以下の説明において、これを第２の情報端末装置であり第２端末２０と表記するものとする。また、図１において、第２端末２０は、例えば一般的な撮像装置である通信機能付きデジタルカメラの形態として図示している。
【０１０６】
ここで、複数の情報端末装置１０，２０は、タブレット型ＰＣ形態であっても、撮像装置（デジタルカメラ等）の形態であってもよい。また、その他の形態、例えばスマートフォン等の形態であってもよい。これらは、いずれの形態であっても、基本的には同様の機能を有しているものとする。
【０１０７】
つまり、本実施形態の医用画像管理システム１に適用し得る情報端末装置（１０，２０）は、少なくとも撮像機能及び通信機能を備えているものであれば、装置の形態に限られることなく同様に適用することができるものである。したがって、図１に図示される各情報端末装置１０，２０の形態は、単なる一つの例示である。
【０１０８】
なお、図１において、符号１３０は、診療対象とする人物である患者を示すものとする。また、図１において、符号１００は、医師１１０が存在している場所としての病院等の医療施設を示すものとする。そして、符号２００は、患者家族等１２０及び患者１３０が存在している場所としての自宅を示すものとする。
【０１０９】
ここで、図１において、符号３００で示す波線は、医療施設１００と自宅２００とが隔たった場所に存在していることを表しているものとする。
【０１１０】
このように構成される本実施形態の医用画像管理システム１の作用の概略は、次に示すようなものである。
【０１１１】
まず、例えば自宅２００等において、通常生活を行っている患者１３０と、患者家族等１２０がいるとする。この患者１３０は、医療施設１００に在籍する医師１１０を掛かり付け医としているものとする。したがって、医療施設１００に設置されたファイルサーバー３０には、当該患者１３０に関する患者情報等が蓄積されているものとする。そして、患者１３０の自宅２００は、医療施設１００からは遠隔地にあるものとしている。
【０１１２】
このような状況下において、例えば、患者家族等１２０が患者１３０の何らかの異変に気が附いたとする。そこで、患者家族等１２０は、自身が所有する手持ちの一般の撮像装置（デジタルカメラ）である第２端末２０を用いて、患者１３０の異変部（例えば患部等）の画像を撮影し、医師１１０に対して医用参照画像として提供することができれば至便である。
【０１１３】
しかしながら、当該第２端末２０は、個人所有の一般機器であり、当然のことながら医用画像取得装置としての認定を受けているものではない。したがって、このような一般機器を用いて取得された画像は、通常の場合は、医用参照画像として認定されることはない。
【０１１４】
そこで、本発明の医用画像管理システム１では、このような一般機器（第２端末２０）を用いて取得した画像を医用参照画像として、医師１１０が承認し得るように、かつ例えばＤＩＣＯＭ規格に準拠したデータ形式の医用オブジェクト（医用画像データファイル）として取り扱い得るように構成している。
【０１１５】
そのための手続きとして、患者家族等１２０は、次のような手続きを行う。即ち、上述したような状況下において、患者家族等１２０は、自身の所有する第２端末２０を用いて撮影した患者１３０の画像を医用参照画像として提供したいので、オーダーを出してもらえれば対応する旨のリクエスト情報を、医師１１０に対して発信する。この「リクエスト情報」と書いた部分は、「医師への相談情報」、あるいは「医師へのお伺い情報」という書き方も可能だが、本願の趣旨からすると、医師のオーダーをリクエストする形なので、内容は「オーダーリクエスト情報」ということになるが、簡単化してこう表現した。
【０１１６】
このリクエスト情報は、例えば患者１３０の診療に関する相談事項や近況情報等を含む情報である。リクエスト情報は、患者家族等１２０が第２端末２０を用いて、必要に応じて医師１１０の第１端末１０に対して所望のリクエスト情報を発信することができる。これは、身近にいる人が、患者を前にして、何か変化を感じることがあるからで、そうした場合に、いつでも、医師のところまで患者を連れて行って診察してもらうような事ができるとは限らず、また、患者も自覚症状がない場合には、こうした診察を拒否する場合があり得るからである。
【０１１７】
このときの状況では、患者１３０の異変の通知や、患者１３０の画像を送信するかどうかの相談などが、具体的に考えられる。医師１１０は、その異変に何らかの具体的追加情報を依頼することが考えられ、その場合の不足情報や追加情報を上記家族等１２０に、依頼する場合がある。「依頼する」という意味で、これを以下、「オーダー情報」として説明する。
【０１１８】
なお、ここで医師１１０から出される「オーダー情報」は、主に非医療従事者である患者家族等１２０に宛てたものとして例示しているので、この「オーダー情報」は、上述したように「一般オーダー情報」に相当する。
【０１１９】
第２端末２０と第１端末１０との通信は、ここで説明している状況下（図１）では、両者が互いに隔たった環境下にあるものとしているので、図１に示すように、ネットワーク４０を経由して行われる。なお、図示していない状況であるが、第２端末２０と第１端末１０とが近距離にあって直接通信することができる状況であれば、無線通信又は有線通信による直接通信をしてもよい。
【０１２０】
なお、第２端末２０を用いて、第１端末１０に向けてリクエスト情報を発信するのに際しては、例えば次のような操作が行われる。
【０１２１】
まず、患者家族等１２０は、医師１１０に対して送信すべき所望の情報を含むリクエスト情報を作成することになる。このリクエスト情報の作成は、基本的には第２端末２０で行われる。第２端末２０が、スマートフォンやタブレット端末等その他、多くの情報端末には、所定の入力操作を受け付けて任意の情報を含むデータファイルを作成することのできる機能があるので、それを利用すればよい。
【０１２２】
一方、第２端末２０が、一般的なデジタルカメラ等の撮像装置であれば、通常の場合、任意の情報データを作成する情報入力部材等は備えていない。そこで、このような場合には、例えば患者家族等１２０等が別に所有するスマートフォンやタブレットＰＣ等を活用して、リクエスト情報を作成し、作成されたリクエスト情報を第２端末２０として利用するデジタルカメラ等の撮像装置に転送し、この撮像装置の通信機能を用いて、当該リクエスト情報を第１端末１０に向けて送信するといった操作を行えばよい。
【０１２３】
また、これとは別に、第２端末２０としての撮像装置に対応するアプリケーションソフトウエア、例えば医用参照画像を取り扱うためのアプリケーションソフトウエアである「医用参照画像取得アプリ」等を用意し、これを使用するという手段も考えられる。
【０１２４】
この場合、第２端末２０としてのデジタルカメラ等の撮像装置に対して予め所定の「医用参照画像取得アプリ」をインストールしておく。このアプリケーションソフトウエアは、例えばリクエスト情報作成モード、リクエスト情報送信モード、一般オーダー情報受信モード，医用参照画像撮影モード、医用参照画像転送モード等の特定の用途に特化した動作モードで、デジタルカメラ等の撮像装置を動作させることができるプログラムソフトウエアである。したがって、これにより、第２端末２０としてのデジタルカメラ等の撮像装置のみを用いても、リクエスト情報を作成することが可能になる。
【０１２５】
この場合においては、例えば、第２端末２０としてのデジタルカメラ等の撮像装置を、リクエスト情報作成モードで動作させる。このリクエスト情報作成モードでは、例えば、アプリケーションに含まれるリクエスト情報一覧表（想定されるリクエスト情報の項目リスト等）が表示され、使用者はタッチパネル等を利用して所望の項目を選択するといった操作によって、所望のリクエスト情報を作成する。
【０１２６】
ここで、第２端末２０として、デジタルカメラ等の撮像装置というカテゴリーの装置を特筆しているのは、次のような理由による。
【０１２７】
即ち、デジタルカメラ等の撮像装置は、画像データの取得、即ち撮影に特化した様々な機能を備え、構図、露出、ピント、色などの撮影パラメータが簡単に変更可能で、画角や撮影距離の自由度が大きく、医師からの様々な要求（オーダー情報に入っていてもよい）に応えることができるからである。また、デジタルカメラ等の撮像装置は、ストロボやＬＥＤ照明などを照射した撮影などにも長け、特殊光で、特定の色情報などを取得することもできる。さらに、動画の撮影なども医師が必要とする情報を含む場合が多いが、これもデジタルカメラ等の撮像装置が得意とする機能である。また、デジタルカメラ等の撮像装置は、音声や心音、呼吸音などを記録し得るマイク機能なども備えている。もちろん、こうした音声情報だけで良い場合は、ＩＣレコーダ等の録音装置を第２端末と利用してもよい。
【０１２８】
このようにして作成されたリクエスト情報は、第２端末２０から第１端末１０へ向けて、直接通信により、若しくはサーバー３０を経由して送信することができる。
【０１２９】
第２端末２０からのリクエスト情報が医師１１０の第１端末１０に到達すると、これを受けて、医師１１０は、受信したリクエスト情報に応じた一般オーダー情報を発行する。これは、医療従事者以外の一般的な人が一般的な機材で取得する情報となるので「一般オーダー情報」となる。
【０１３０】
この場合において、第１端末１０には、こうした医療知識に乏しい一般の人からのリクエストに応えるために特別に設計されたアプリケーションソフトウエアである「一般オーダー情報作成アプリ」が、予めインストールされているものとする。この一般オーダー情報作成アプリには、第１端末１０の動作モードとして、専門家でなくとも意味のある情報が取得しやすくガイドした一般オーダー情報作成モードと、こうした一般の人の持ついわゆるコンシューマ機器にこうした専門的なニーズに応えてもらうための情報を送って（あるいは受信して）、相手に正しく伝えるように工夫した一般オーダー情報送信モード等が含まれている。例えば電話やメールやＳＮＳ（social networking service）的なやり取りをするには、受信も必要なので、一般オーダー情報通信モードと書いてもよい。
【０１３１】
医師１１０は「リクエスト情報」を受けると、追加情報依頼の必要性を考慮し、第１端末１０を操作して、必要か必要でないかを、そのリクエスト情報の発信相手に伝える。このような場合、相手が反論する場合もあって、やり取りを行う事が重要である（一般オーダー情報通信モード、あるいは（一般オーダー情報送受信モード））。例えば、メールなどテキストベースの情報だけでは、微妙なニュアンスが伝わらず、文章のうまい下手によって正しい判断や応答ができなくなる。したがって、必要なオーダーが出せなくなるおそれもある。
【０１３２】
この時、医師の判断で、もっと正確な情報、追加情報を必要とする場合などは、一般の人が一般のコンシューマ機器で取得可能な情報である必要があるので、それを考慮して設計された一般オーダー情報作成アプリを起動させるなどして、所定の操作を行って一般オーダー情報を作成し（一般オーダー情報作成モード）、作成した一般オーダー情報を第２端末２０へ向けて送信する（一般オーダー情報送信モード）。
【０１３３】
ここでのオーダーは、Ｘ線検査など、特別な資格、特別な装置などを必要とするものであってはならず、それを代用するような検査になるような、簡易情報的、補助検査、参考検査な情報をオーダーすることになる。したがって、そうしたオーダーしか選べないようなアイコン設計、メニュー構成によるユーザーインターフェース（ＵＩ）で操作されることを想定している。
【０１３４】
患者家族等１２０は、医療関係者でない場合が多いので、一般の人という設定で説明をしている。患者家族等１２０は、医師１１０から送られてくる一般の人用の一般オーダー情報を第２端末２０を用いて受信する（一般オーダー情報受信モード）。このとき医療用語が医療従事者以外にもわかる一般的な言葉に置き換えられている必要がある。そうでないと、医療専門用語によるオーダー情報を出されても、それを受けた非医療従事者（患者家族等）は、何をどうして良いかわからなくなるだけである。
【０１３５】
医師のオーダー情報としては、例えば、患者本人であることを確認すること、のほか、患者のここ（特定部分）の写真を撮るようにする等の、単純なオーダーしか出せないように、「一般オーダー情報作成アプリ」が工夫されて設計されている。つまり、「一般オーダー情報作成アプリ」からは、難しいオーダーが出せないようになっている。医師が難しいオーダーを出す場合は、この「一般オーダー情報作成アプリ」が医師の出した難解な文言（医療専門用語等）を一般的な簡単な文言に置き換えたり、単純な手順等に変換する等、非医療従事者でも対応できるような形態に変換する。しかしながら、それが困難な場合には、オーダーを出さないか、あるいは、何もせずに専門家に任せるように等の内容のオーダーとして、患者家族等１２０等へ医師１１０の意志として伝達する。
【０１３６】
また、作業の単純化の例として、いくつかの設定を少しずつ行わせるというオーダーの工夫などがあり得る。例えば、全身像の中で特定の部位がわかるように、全身画像と一部拡大画像とを順番で撮影するときの順番などもオーダー情報とするような工夫がある。
【０１３７】
また、具体的な活用技術の例として人工知能などがある。医師が仮に医療用語を使っても、それを一般的な用語に変換するような機能が、上記「一般オーダー情報作成アプリ」には含まれており、具体的には用語変換用のデータベースや人工知能による推論エンジンなどが採用される。これは、第１、第２端末のいずれにあっても、これらを結ぶネットワーク上に存在してもよい。
【０１３８】
もちろん、デジタルカメラ等の撮像装置などの機器に、こうした人工知能やデータベース機能があってもよい。以上のような工夫を行っているので、医師の要望（オーダー）は、誰にでも対応できるもの、あるいは、専門家に任せるアドバイスなど、一般の人がすぐに理解できる簡単な指示に置き換えられて表示、または音声等で伝達される。したがって、そうしたガイドなどを利用、あるいは参考にして、患者家族等１２０は、そのオーダーに即した対応が可能となり、当該第２端末２０を用いて患者１３０に対する所望の撮影を行うことが可能となる（医用参照画像撮影モード）。
【０１３９】
こうして、図１に示す状況下で、即ち医師１１０の要望（一般オーダー情報）に応える形で患者家族等１２０が第２端末２０を用いて取得した画像データファイルは、画像データ本体と、この画像データ本体に付随する付随情報（メタデータ）として、対応する一般オーダー情報に含まれる各種の情報が記録される（詳細後述）。したがって、これにより、当該画像データファイルは医用参照画像として承認され得るための所定の形式（例えば、ＤＩＣＯＭ規格に準拠したデータ形式）を備えた画像データファイルとして作成される（詳細後述）。
【０１４０】
つまり、患者家族等１２０が患者の状況を心配したり、不安に思ったりして、ほかにどのような情報を送付すればよいかの相談のような感じで、できることがあれば教えて欲しいという所望のリクエスト情報（ここに今、使える機器、道具などの情報を追記してもよい）を医師１１０へ発信し、そのリクエスト情報を受信した医師１１０がその状況を考慮して、その判断に応じて、しかるべき一般オーダー情報を発行すると、この一般オーダー情報を受信した一般機器（第２端末２０）は、医師が必要として、病院内で管理したり、医用情報として評価するに値する医用参照画像を取得することができるようになる。
【０１４１】
そして、こうして取得した医用参照画像（画像でなくとも音声でもよく、それ以外の体温や体重や血圧のような各種の情報でもよい）は、医師１１０のオーダーに応えたものと認められる。さらに、受け取った医師の判断も加味して医用参照画像としての所定の品質が確保される。
【０１４２】
これには、どのような状況で、どのような患者の情報を、どのような機器をどんな使い方で得たか、といった付随情報があることが好ましいが、それらのいくつかは、先のオーダー情報に含まれていたものを利用すれば効率的である。そして、当該画像データファイルは、第２端末２０からファイルサーバー３０等へと転送されて、対象とする患者１３０の患者情報の一部として蓄積される。
【０１４３】
なお、リクエスト情報は、正しい判断で、医師が適切にオーダーできるように、患者家族等がその時利用し得る機材、装置、システム、道具などを入力したり選択したりできることが好ましい。
【０１４４】
例えば、カメラと定規があれば、傷口に定規を当てて、その大きさの情報を含む画像を撮影することができる。また、通信システムが特定の性能を有し、安定しているなら、ストリーミング画像を利用した診断や、ＴＶ会議的な診断も可能となる。
【０１４５】
また、その人のスキル情報や、写真を送るとすれば撮影のテクニックの習得レベルなどの情報も有効である。同じ指示でも、絞りを絞って、という表現でオーダーするか、そのカメラのそのダイヤルを操作して、と指示するのでは異なるが、受け取る相手によって、どちらがわかりやすいか、迅速に作業できるかが異なる。
【０１４６】
こうしたいくつかのオーダー候補のどれを医師が選択するかは、十分な判断材料がリクエスト情報に含まれていなければ難しい。つまり、上記リクエスト情報は、対象とする患者と当該情報端末機器を利用する利用者本人の情報を含んでもよく、当該情報端末機器を利用する利用者が利用可能な機材情報を含んでもよく、上記リクエスト情報は、当該情報端末機器を利用する利用者の技能情報を含んでもよい。この技能は機器や道具（当該端末を含んでもよい）を使いこなす能力の他、性別、年齢や体調、言語能力や文章能力、通信やネットワークなどの設定能力などの技能情報のいずれかで良く、この情報によって医師が要求できる事項に違いが出る可能性がある。
【０１４７】
また、オーダー情報も前述のように、一般の人が一般の機材、あるいは道具を用いて、医師の要求（オーダー）に応えられるように、平易な表現で相手に伝わるものでなければならない。それには、図示を伴うグラフィックユーザーインターフェースなどの活用や、照明条件や距離条件を示した具体的指示であったり、専門家になら一言で言えるものを、複数のステップに分けて解説したものであったり、対話形式で進めるガイド情報となっていたりする事が、状況や難易度に応じて求められる。
【０１４８】
つまり、上記ガイド情報は、上記リクエスト情報に従って変更されたガイド情報と言い直すことができる。つまり、対象となる患者情報と、利用者の利用し得る機材情報を含むリクエスト情報を受信して上記リクエスト情報に応じたガイド情報を作成し、上記ガイド情報に従って取得された追加情報を取得する上記患者に関する情報を取得する患者情報取得方法の提案と言え、それを達成するための装置を含むシステムの発明と言うことができる。これは、第１の端末、第２の端末という表現を省いている表現であるが、同じ機器を使って同様の問題を同様に解決することも可能である。例えば、医師に患者家族が端末を渡すと、そこにリクエストが記録されており、それを見た医師が、同じ機器を上記患者家族に返すと、患者家族は、その端末に表示されたガイドを見ながら（オーダーに応じて）、患者と向き合って情報取得する、という変形例が考えられるからである。
【０１４９】
例えば、普通に昼間しか病院に来ることができない患者家族が夜勤の医師と相談するには、そうした解決策があり得る。医師が普通の勤務形態で、患者の病状が夜中に現れる場合も同様の解決方法がとれる。こうした方法は、その考え方を実現するシステム、機器などを提供することによって実現することができる。
【０１５０】
なお、図１に示す例では、患者家族等１２０が第２端末２０を使用する例を示しているが、この例示に限られることはなく、第２端末２０は、患者１３０自身が使用する状況であっても同様である。本実施形態の基本的な概略作用は以上である。
【０１５１】
このような条件もリクエスト情報に入れておけば、医師が下す判断も変わってくる可能性がある。例えば、背中の写真などは、患者本人が撮影することは困難で、鏡（上記道具に相当）があるかどうかによっても変わってくる。
【０１５２】
次に、本実施形態の医用画像管理システム１の作用を、具体的な使用状況（使用パターン）毎に、簡単に説明する。
【０１５３】
図２〜図４は、本実施形態の医用画像管理システムの作用の概略を、使用状況に応じて示す概念図である。このうち、図２は、本実施形態の医用画像管理システムの作用の第１使用パターンを説明する概念図である。図３は、本実施形態の医用画像管理システムの作用の第２使用パターンを説明する概念図である。図４は、本実施形態の医用画像管理システムの作用の第３使用パターンを説明する概念図である。
【０１５４】
（［第１使用パターン］）
まず、本実施形態の医用画像管理システム１の使用状況における第１使用パターンは、以下の通りである（図２参照）。
【０１５５】
ここで、第１使用パターンは、例えば医院（個人経営の小規模医療施設）等、かかりつけ医としての医師と患者（患者家族を含む）と間の繋がりが、比較的強い関係性を有している場合を想定している。
【０１５６】
最初に、患者家族等１２０が第２端末２０を用いて、医師１１０の第１端末１０へ向けて直接通信を行ってリクエスト情報を送信する（図２の矢印符号Ａ；リクエスト情報送信モード）。
【０１５７】
この場合において、リクエスト情報を受信する端末を、医師１１０の第１端末１０としているが、これに限ることはない。例えば、第１端末１０を管理するのは、医療施設１００であるものとした場合、当該第１端末１０を用いて最初にリクエスト情報を受信するのは、医師１１０が直接受信するケースのほかに、医療施設１００における受付担当者（一般医療従事者；例えば看護師若しくは医療事務の有資格者等）が受信操作を行って、当該受付担当者が医師１１０へと伝達するといった手続きになる場合もある。ここでは、説明を簡略化するために、医療施設１００での受信者の代表例として、医師１１０を例示している。
【０１５８】
なお、第２端末２０からのリクエスト情報を第１端末１０が受信したとしても、医師１１０若しくは受付担当者等が当該第１端末１０に届いたリクエスト情報を即座に（リアルタイムで）確認するとは限らない。したがって、第２端末２０からリクエスト情報を送信した後は、第２端末２０は、第１端末１０からの応答の待機状態となる。
【０１５９】
ここで、第２端末２０から発信されるリクエスト情報の内容としては、例えば、図２の符号２０ａで示すように、標題名「一般オーダーリクエスト」，依頼年月日，宛先医師名，患者名，撮影者名等の基本情報に加えて、コメントとして主訴情報等がある。この主訴情報として、今回のリクエスト情報を送信するに至った理由や、患者１３０の診療に関する相談事項や近況情報等を具体的に示せばよい。
【０１６０】
第２端末２０から発信されたリクエスト情報は、第１端末１０にて受信される。医師１１０は、例えば空き時間等に、第１端末１０を用いて、受信されたリクエスト情報を確認する。
【０１６１】
リクエスト情報を確認した医師１１０は、第１端末１０を用いてファイルサーバー３０にアクセスして（図２の矢印符号Ｂ）、受信したリクエスト情報の対象患者１３０に関するカルテデータ等を参照する（図２の矢印符号Ｃ）。
【０１６２】
医師１１０は第１端末１０を用いて、受信したリクエスト情報に応じた一般オーダー情報を作成する。その後、医師１１０は、第１端末１０を用いて第２端末２０と直接接続して、作成した一般オーダー情報を第２端末２０へと発信する（図２の矢印符号Ｄ）。
【０１６３】
ここで、第１端末１０において作成される一般オーダー情報の内容としては、例えば、図２の符号２０ａで示す表示画面のように、標題名「一般オーダー」，発行年月日，患者名，患者ＩＤ（Patient ID；患者固有識別情報），撮影者名，発行者名（主治医師名等を含む担当医師や医療機関に関する情報）等の基本情報に加えて、コメントとして主訴に応じた各種の情報（撮影指定部位，必要画像数，撮影手順，撮影条件等）等がある。
【０１６４】
なお、ここで、撮影条件とは、例えば、撮影フォーマット（ファイル形式），画像のアスペクト比情報等の各種設定や、画面内にスケールを写し込む等の指示情報が含まれる。さらに、撮影条件情報としては、撮影毎に毎回均等な類似の画像が撮影できるようにするための各種の撮影パラメータ等の設定情報等や、サンプル画像のサムネイル画像等も含まれる。
【０１６５】
なお、上記設定情報には、例えば、露出情報，ホワイトバランス情報，感度情報，光学系焦点距離情報，被写体までの距離情報，撮影倍率情報，アングル情報等、各種の撮像関連情報等が含まれる。
【０１６６】
なお、医療メタデータのほかに、従来一般的な画像ファイルとして利用されているＥｘｉｆ規格に準拠したデータ形式を持つ画像データファイル等に含まれる各種情報（例えば、撮影場所（GPS情報），日時情報，撮影条件情報等）が一般メタデータとして記録される。
【０１６７】
さらに、一般オーダー情報には、医用参照画像としての承認情報が付与される。図２に示す形態例では、「許可」を表すアイコン表示とチェックを入力した形態の許可表示１０ｂを例示している
第２端末２０は、このような一般オーダー情報を受信すると（一般オーダー情報受信モード）、その表示画面に、当該一般オーダー情報の内容を、例えば図２の符号１０ａに示す形態に準じた形態で表示する（なお、第２端末２０の受信表示は不図示（図２の符号１０ａ参照）。
【０１６８】
そして、撮影者としての患者家族等１２０は、患者１３０に対して、受信した一般オーダー情報に従った撮影を、第２端末２０を使用して実行する。
【０１６９】
第２端末２０は、一般オーダー情報に従った撮影を行う際に、各種の設定等を自動的に行って、適切な撮影動作を容易に実行することができるようにするための所定の撮影動作モードを具備していてもよい。撮影者は、所定の撮影動作モードに切り換えるのみで適切な撮影を行うことができる。ここで、所定の撮影動作モードとして、例えば、「医用参照画像撮影モード」等とする。この場合における第２端末２０の医用参照画像撮影モードも、例えば対応するアプリケーションを、予め第２端末２０にインストールしておけばよい。
【０１７０】
このようにして取得された画像データには、一般オーダー情報に含まれる各種の情報が付随情報（メタデータ）として記録される（詳細後述）。
【０１７１】
即ち、本実施形態の医用画像管理システム１において扱われる画像データファイルは、従来一般的な画像データファイル（例えばＥｘｉｉｆ（Exchangeable image file format）データ等）に含まれる一般的なメタデータ（一般メタデータという）に、オーダー情報又は一般オーダー情報に含まれる医療的な情報を含む医療メタデータを付随情報として記録されるように構成している。
【０１７２】
即ち、情報端末装置のうち第２端末２０（患者家族等１２０が使用する画像取得装置）によって取得される画像データファイルは、従来一般的に普及しているデータ形式であり、具体的には例えばＥｘｉｆ（Exchangeable image file format）準拠のデータ形式である。
【０１７３】
そして、本実施形態の医用画像管理システム１においては、第２端末２０によって取得された画像データファイル（Ｅｘｉｆファイル）に対して、さらに、対応する医療メタデータを付加した形態で記録するようにしている。この場合において、本実施形態のシステムにおいては、最終的に生成される画像データファイルの基本的なデータ形式としては、例えば、ＤＩＣＯＭ規格に準拠したデータ形式としている。
【０１７４】
ここで、図７は、本実施形態の医用画像管理システムにおいて生成される画像データファイルの構成を概念的に示す図である。
【０１７５】
通常の場合、一般的なＥｘｉｆ画像データファイルは、画像データ本体４０１と、サムネイル画像４０２と、メタデータ４０３とによって構成される画像データファイルとなっている（図７参照）。
【０１７６】
ここで、メタデータ４０３には、一般的な各種の情報、例えば、日時情報，撮影機材情報（ボディ名，レンズ名等），撮影条件情報（露出，ホワイトバランス，感度，光学系焦点距離情報等の設定情報のほか、被写体までの距離情報，撮影倍率情報，アングル情報等の被写体との関係情報等）等がある。これら一般的なメタデータを、以下、一般メタデータというものとする。
【０１７７】
本実施形態の医用画像管理システム１においては、情報端末装置（第２端末２０）を用いて一般オーダー情報に基づく撮影動作を行ったときには、取得されるＥｘｉｆ画像データファイルに対し、一般オーダー情報に含まれる医療的な情報がメタデータ４０３に付加して記録されるように構成している。
【０１７８】
即ち、本実施形態の医用画像管理システム１においては、図７に示すような構造の画像データファイル４００が生成される。この画像データファイル４００は、画像データ本体４０１と、サムネイル画像４０２と、メタデータ４０３とによって構成される画像データファイルである。このうち、メタデータ４０３には、一般メタデータ（Ａ）４０３ａと、一般メタデータ（Ｂ）４０３ｂと、医療メタデータ４０３ｃとが含まれている。
【０１７９】
ここで、一般メタデータ（Ａ）４０３ａは、ＤＩＣＯＭ規格準拠のデータ形式にも含まれるような汎用的な情報（例えば日時情報，撮影機材情報，撮影条件情報等）をいうものとする。また、一般メタデータ（Ｂ）４０３ｂは、Ｅｘｉｆ準拠のデータ形式に含まれるメタデータのうちＤＩＣＯＭ規格準拠のデータ形式には含まれないような情報（例えばＧＰＳ情報等）をいうものとする。そして、医療メタデータ４０３ｃは、一般オーダー情報に含まれる医療的な情報を取り込んだ情報群である。
【０１８０】
上記画像データファイル４００に含まれる各データ要素、即ち画像データ本体４０１，サムネイル画像４０２，一般メタデータ（Ａ）４０３ａ，一般メタデータ（Ｂ）４０３ｂ，医療メタデータ４０３ｃのそれぞれは、図７に示すように、データ要素タグ，値表現（ＶＲ），データ長さ，データ本体によって構成されるデータ構造を有する。
【０１８１】
データ要素タグは、そのデータ要素が何を表しているのかを表現するための情報を示す符号である。データ要素タグの詳細についてはＤＩＣＯＭ規格に規定されている。具体的には、例えば、検査日付（Study Date），検査時刻（Study Time），患者名（Patient's Name），患者ID（Patient's ID）等が規定されている。
【０１８２】
値表現（ＶＲ；Value Representation）は、データ要素がどのようなデータであるかを示す情報である。値表現（ＶＲ）は、２バイトの文字列であり、その詳細はＤＩＣＯＭ規格で規定されている。具体的には、例えば、年齢（AS；Age String），属性タグ（AT；Attribute Tag），コード列（CS；Code String），日付（DA；Date），日時（DT；Date/Time），長テキスト（LT；Long Text），人名（PN；Person Name），短テキスト（ST；Short Text），時間（TM；Time），固有識別子（UI；Unique Identifier）等がある。
【０１８３】
データ長さは、データ本体のバイト数のことである。
【０１８４】
データ本体は、目的のデータが格納されている領域である。
【０１８５】
なお、ＤＩＣＯＭファイルは、複数のデータ要素及びサービス種類情報から構成されているので、画像データファイル４００を構成する各データ要素を上記のように構成しておけば、容易にＤＩＣＯＭ規格準拠のデータ形式の医用オブジェクト情報に変換が可能となる。
【０１８６】
ＤＩＣＯＭファイルはＤＩＣＯＭデータにプリアンブルを付けてファイルとして保存したものをいうが、「ＤＩＣＯＭデータ」という場合は、ＤＩＣＯＭファイルのみならず、ＤＩＣＯＭ通信で内部的に用いるパケットのフォーマットなども含まれる。実際には、ここで示したものは、送られるコンテンツの中身を重視してファイルと表現したが、通信フォーマットも規格化されて決められるので、これを含んでもよく、「医用管理データセット」と言い直してもよい。
【０１８７】
つまり、ＤＩＣＯＭファイルは、上述したように複数のデータ要素及びサービス種類情報から構成されている。
【０１８８】
サービス種類情報は、格納されているデータ要素が、どのような機能（サービス種類）に対応したものかを示す情報である。
【０１８９】
サービスの種類としては、例えば、通信管理機能（Verification Service Class），装置間画像転送機能（Storage Service Class），各種医用情報の問い合わせや検索と画像転送機能（Query Retrieve Service Class），画像プリント機能（Print Management Service Class）等がある。
【０１９０】
そして、ＤＩＣＯＭ規格に準拠したデータファイルの通信を行う際には、クライアントであり端末側のサービス利用者（ＳＣＵ；Service Class User）が通信の確立を要求し、サーバー側のサービス提供者（ＳＣＰ；Service Class Provider）が、その要求に応答するＳＯＰクラス（サービスオブジェクトペアクラス）による通信機能が用いられる。そのために、ＤＩＣＯＭファイルには、サービス種類情報と複数のデータ要素情報とをセットしたデータ形式となっている。
【０１９１】
本実施形態においては、このようなＤＩＣＯＭ規格通信を実現するために、画像取得装置により取得された画像データファイルに、オブジェクト情報に対応したデータ要素を持たせるようにしている。
【０１９２】
なお、画像データファイルに含まれるメタデータ４０３には、上述の一般メタデータ（Ａ）４０３ａ，一般メタデータ（Ｂ）４０３ｂ，医療メタデータ４０３ｃに加えてさらに、取得された画像データがオーダー情報に応じた撮影がなされているかどうかの確認結果のデータ（後述）を含む第３のメタデータを含めるようにしてもよい。
【０１９３】
さらに、これらに加えて、所定の領域のセキュア領域を持つようにし、このセキュア領域に、医療メタデータ４０３ｃ等をはじめとした秘匿を要する重要情報（個人情報等を含む各種の情報）を記録するようにしてもよい。
【０１９４】
この場合において、セキュア領域に記録される情報は、特殊な暗号化処理を施して、セキュリティー対策が講じられた特定のシステム（例えば院内システム等）に含まれる機器でなければ、読み取りができないようにする。このようにすれば、本実施形態において取り扱われる医用画像データファイルが、例えば可搬型の記録媒体にコピーされたり、ネットワーク経由で外部に流出されたとしても、当該医用画像データファイルに非対応の機器を用いては、セキュア領域の情報を読み取ることができない。したがって、容易にセキュリティー管理を行うことができるという利点がある。
【０１９５】
なお、この医療メタデータ４０３ｃは、従来の一般メタデータ４０３ａ，４０３ｂに対して別ファイルの形態で存在する構成としてもよいし、上述の図７に示すように、一体に構成される形態であってもよい。しかし、いずれの形態を採るにしても、画像データ本体４０１と医療メタデータ４０３ｃとは関連付けられていることが重要である。画像データ本外４０１と医療メタデータ４０３ｃとが関連付けられていることにより、それぞれが単独データファイルで存在していたとしても、画像データ本体４０１に対する操作（例えば他の媒体への移動，複写若しくは削除操作）の際には、必ず関連付けされたメタデータ４０３を伴って所定の操作がなされることになる。したがって、例えば、医療メタデータ４０３ｃのみが単独で存在するようなことはないようにされている。
【０１９６】
また、メタデータ４０３には、上述のようにして、医師１１０が入力する一般オーダー情報に含まれる情報からなる医療メタデータ４０３ｃのほかに、例えば既存の一般メタデータと重複する項目、例えば撮影時点の日時情報，撮影機器情報（カメラ固有の情報等）等は、一般メタデータ（Ａ）４０３ａとして記録される。
【０１９７】
また、第１端末１０が、特定の患者家族等１２０の第２端末２０からのリクエスト情報を受信するのが初めてのことではなく、過去にも利用実績がある場合には、第１端末１０には、既に以前に受けたリクエスト情報が存在しているはずである。
【０１９８】
したがって、上述のようにして、第１端末１０が第２端末２０からのリクエスト情報を受信した時に、例えば対応する患者情報（例えば患者ＩＤ等）を自動的に検出することができる。したがって、医師１１０は、第１端末１０が検出した患者情報を利用して、ファイルサーバー３０の所望の情報を自動的にかつ迅速に検索することができる。
【０１９９】
そして、第２端末２０を用いて取得された画像データファイルは、図示を省略しているが、何らかの手段によって、ファイルサーバー３０へと転送される（医用参照画像転送モード）。
【０２００】
即ち、例えば、第２端末２０からネットワーク４０経由でファイルサーバー３０へと当該画像データファイルが送信されて、当該ファイルサーバー３０の所定の領域に記録される。すると、このとき、当該画像データファイルは、ファイルサーバー３０の所定の領域に記録されている複数の患者情報のうち対象患者１３０に関連する情報として関連付けられる。
【０２０１】
また、取得された画像データファイルは、患者家族等１２０又患者１３０が、第２端末２０を持参の上、医療施設１００を訪れた際、当該医療施設の受付部門を通してファイルサーバー３０に記録されるか、または、担当の医師１１０の第１端末１０へと提供される。
【０２０２】
このようにして、第２端末２０によって取得された画像データファイルに対して、医療オーダー情報又は一般オーダー情報に含まれる所定の医療メタデータ４０３ｃが付与されることによって、当該画像データファイルは、医師１１０によって承認され、例えばＤＩＣＯＭ規格に準拠したデータ形式の医用オブジェクト（医用画像データファイル）としての医用参照画像の画像データファイルとして取り扱うことができる。したがって、医師１１０は、当該画像データを医用参照画像として診療の参考とすることができる。
【０２０３】
なお、上述した説明では、撮影に関連する各種の情報（撮影条件情報）を、メタデータ４０３に含めるように説明しているが、これに限られることはない、撮影条件情報については、画像データファイルとは別個のデータファイルとして作成するようにしてもよい。そして、その撮影条件情報のデータファイルは、対応する画像データファイルに関連付けて記録されるものとする。したがって、例えば画像データが他の装置へと転送される際には、対応する画像データと共に、関連する撮影条件情報データファイルも、必ず同時にセットで転送されるようにする。
【０２０４】
また、患者家族等１２０が一般オーダー情報を受信した第２端末２０を用いて、患者１３０に対する所定の撮影を行う際に、患者１３０を特定するための本人確認情報を記録しておくようにしてもよい。
【０２０５】
この本人確認情報としては、例えば図８に示すように、患者家族等１２０が患者１３０に向き合って撮影する時に、患者１３０に対して声がけを行って、患者１３０に氏名を名乗らせる等によって本人の確認を行う。そのために、第２端末２０には、その音声を記録するための構成（マイクロフォン及び音声記録部）が設けられている。そして、このとき記録される音声データは、続いて取得される画像データに関連付けされるようにする。若しくは、所得される画像データファイルのメタデータに付加して記録されるようにしてもよい。
【０２０６】
また、音声によるなりすましを避けるために、動画を撮影しておいて、対話確認の様子を記録して証拠にしてもよい。このように、本来なら担当の医師や医療従事者が行うべき確認を端末装置や操作者に委任するので証拠保全が重要となる。したがって、いつの時点の医師のオーダーに基づく本人確認であるか、なども記録した方が良い。また、さらなる厳密性を求める場合は、その時のみ医師の端末と電話等の通信回線、ネットワークなどを利用して、医師や医療従事者と患者を直接対話させ、その記録を行ってもよい。
【０２０７】
また、本人確認情報としては、第２端末２０に備わる顔認識技術を用いることもできる。ここで、第２端末２０は、患者１３０の家族や近親者若しくは本人所有の情報端末装置を想定している。したがって、第２端末２０には、予め患者本人の顔画像を登録しておく。そうして、第２端末２０を用いて撮影を行えば、患者１３０本人を撮影対象としていることが容易に検出することができる。
【０２０８】
さらに、本人確認情報としては、第２端末２０に指紋認証技術や虹彩認証技術等を付加して構成し、これらを利用するようにしてもよい。
【０２０９】
さらに、第２端末２０におけるメニュー設定モードの中に、例えば「本人確認メニュー」等を設け、予め登録しておいた撮影者氏名（患者家族等の氏名）と、患者氏名とを選択設定するような形態も考えられる（図９参照）。
【０２１０】
図９に示す表示例では、例えば選択アイコン１５ａ，１５ｂを操作することにより、予め登録されている撮影者氏名（患者家族等の氏名）と患者氏名とが表示欄１５ｃ，１５ｄに順次表示される。そして、当該表示欄１５ｃ，１５ｄに所望の氏名が表示されたところで、決定アイコン１５ｅを操作すれば設定が完了する。こうして、撮影者氏名（患者家族等の氏名）と患者氏名とを選択し設定した後、戻るアイコン１５ｆを操作すれば、当該設定メニューを抜けて、撮影モードに戻ることができる。そうして、撮影モードにおいて所定の撮影動作を実行すれば、設定した氏名情報が、医療メタデータとして記録されることになる。
【０２１１】
このように第２端末２０は、患者本人を検出したときには、医用参照画像を撮影しようとしているものと判断して、対応する所定の撮影動作モード（医用参照画像撮影モード）に自動的に切り換えるといった制御を行うようにしてもよい。
【０２１２】
第２端末２０において、医用参照画像撮影モードに切り換えたときには、当該第２端末２０の制御部（後述する）は、受信済みの一般オーダー情報に含まれる撮影条件情報等を参照して、新たな医用参照画像を取得するために最適な撮影パラメータ（露出設定，ホワイトバランス設定，感度設定，焦点距離設定等）を自動設定する制御を行う。また、このときに、構図や撮影アングル，被写体までの距離等の撮影条件情報のガイド表示（アシスト表示）を、表示部に自動的に表示されるようにする。この表示は、例えば表示部におけるライブビュー画像に重畳表示するといった形態等が考えられる。
【０２１３】
なお、上述の説明では、リクエスト情報を発信する側の人物であり、撮影者として、患者家族等１２０を例に挙げて説明しているが、この例に限られることはない。患者１３０に対峙する撮影者としては、例えば、医師の往診若しくは訪問介護等の状況を考慮しても、同様に適用できる。その場合には、第２端末２０を操作する人物としては、患者の自宅を訪問する看護師，介護福祉士等が対応する。
【０２１４】
このようにして、一般医療従事者や医療従事者以外の患者家族等が、一般的な情報端末装置（第２端末２０）を用いて取得した画像データファイルを、医師１１０によって承認され、ＤＩＣＯＭ準拠のデータ形式とした医用参照画像として取り扱うようにすることができる。
【０２１５】
本実施形態の医用画像管理システム１の使用状況における第１使用パターンの概略は、以上である。
【０２１６】
（［第２使用パターン］）
次に、本実施形態の医用画像管理システム１の使用状況における第２使用パターンは、以下の通りである（図３参照）。ここで、第２使用パターンは、基本的には上述の第１使用パターンと略同様である。以下に説明する第２使用パターンでは、一般オーダー情報の作成の詳細は、医師によらずにシステムによる自動処理で行うようにした点が異なる。
【０２１７】
最初に、患者家族等１２０が第２端末２０を用いて、リクエスト情報を作成し（リクエスト情報作成モード）、これを医師１１０の第１端末１０へ向けて直接通信を行ってリクエスト情報を送信する（図３の矢印符号Ａ；リクエスト情報送信モード）ことは、上述の第１使用パターンと同様である。また、このとき第２端末２０から発信されるリクエスト情報の内容も、上述の第１使用パターンで説明したものと同様である。
【０２１８】
第１端末１０にて受信されたリクエスト情報を医師１１０が確認すると、当該医師１１０は、第１端末１０を用いてファイルサーバー３０にアクセスして、受信したリクエスト情報の対象患者１３０に対応する所定の指示情報をファイルサーバー３０へ出す（図３の矢印符号Ｂ）。
【０２１９】
ここで医師１１０から出される指示情報は、リクエスト情報を含む基本情報と、対象患者１３０に応じた極めて簡単な指示のみでよい。
【０２２０】
医師１１０の指示情報を受けてファイルサーバー３０の制御部３１（後述する図６参照）は、リクエスト情報に応じた一般オーダー情報を作成する。その後、ファイルサーバー３０は、第２端末２０に宛てて、作成された一般オーダー情報を発信する（図３の矢印符号Ｃ）。第２端末２０では、この一般オーダー情報を受信する（一般オーダー情報受信モード）。その後、受信した一般オーダー情報に準じて所定の撮影を行う（医用参照画像撮影モード）。そして、撮影結果の画像データをファイルサーバー３０へと転送する（医用参照画像転送モード）。
【０２２１】
ここで、ファイルサーバー３０において作成される一般オーダー情報の内容は、上述の第１使用パターンで説明したものと同様である。
【０２２２】
そして、この一般オーダー情報を受信した第２端末２０の作用もまた、第１使用パターンと同様である。
【０２２３】
このようにして、当該第２使用パターンにおいても、一般医療従事者や医療従事者以外の患者家族等が、一般的な情報端末装置（第２端末２０）を用いて取得した画像データを、医師１１０によって承認され得る医用参照画像として取り扱うようにすることができる点において同様である。
【０２２４】
また、第２使用パターンにおいては、一般オーダー情報の作成処理を、ファイルサーバー３０による自動処理に任せたことによって、医師の手作業を簡略化することができ、よって医師の負担を軽減することができる。
【０２２５】
なお、上述の第２使用パターンの説明では、ファイルサーバー３０の制御部３１（図６参照）が、リクエスト情報に応じて一般オーダー情報を作成するものとして説明しているが、この例に限られることはない。例えば、医師１１０からの指示情報は、ファイルサーバー３０を経由して医療施設１００における受付部門に設置されたＰＣ等の情報処理装置（不図示）へと転送されるようにして、一般オーダー情報の作成処理は、この受付部門の情報処理装置と、これを取り扱う受付担当者が行うようにしてもよい。
【０２２６】
また、第２使用パターンにおいて自動処理若しくは受付担当者の手によって作成された一般オーダー情報は、作成された後、すぐに第２端末２０へ発信されるのではなく、作成後、発信前に、一度、医師１１０の確認を取得するようにしてもよい。そうすれば、一般オーダー情報の信頼度を、さらに向上させることができる。
【０２２７】
本実施形態の医用画像管理システム１の使用状況における第２使用パターンの概略は、以上である。
【０２２８】
（［第３使用パターン］）
次に、本実施形態の医用画像管理システム１の使用状況における第３使用パターンは、以下の通りである（図４参照）。ここで、第３使用パターンは、基本的には上述の第１使用パターン等と略同様である。以下に説明する第３使用パターンは、例えば多数の医師と完備した病院システムを備えた大規模病院等の医療施設において運営される場合を想定している。
【０２２９】
この種の大規模医療施設では、一般に、まず、受付システムを通してから作業が始まる。また、特定の患者に対応する医師は、複数人の医師で構成されるチームによって組織的に対応するのが一般である。したがって、特定の患者に対して特定の医師が常に対応するわけではない。また、一人の医師が担当する患者数も多数存在する。
【０２３０】
したがって、特定の医師の第１端末１０に複数の担当患者の関連情報が直接送信されてきてしまっては、受信側の特定の医師は、到底、一人で対応しきれるものではない。このことを考慮して、第３使用パターンは、患者側から発信されるリクエスト情報は、まず、全てが院内システムの受付部門を経由してファイルサーバー３０に蓄積されるようにしている（図４の矢印符号Ａ）。
【０２３１】
リクエスト情報がファイルサーバー３０に入力されたときには、ファイルサーバー３０は、リクエスト情報に含まれる情報を参照して複数の担当医師へと同時配信する（図４の矢印符号Ｂ）。
【０２３２】
なお、図４に示す例示では、複数の担当医師として符号１１０，１１０Ａとして、二名を示しているが、さらに多くが存在していてもよい。
【０２３３】
これら複数の担当医師（１１０，１１０Ａ…）は、例えば勤務時間が異なっていたり、他の作業中（例えば手術中等）であったり等の理由により、当該リクエスト情報を確認するタイミングが異なる。したがって、当該リクエスト情報の対象患者に対応する複数の担当医師（１１０，１１０Ａ…）のうち、例えば、最初にリクエスト情報を確認できた一人の医師（図４に示す例では符号１１０Ａで示す医師）が一般オーダー情報を作成すればよい。
【０２３４】
ここで、医師１１０Ａが一般オーダー情報を作成する手順は、上述の第１使用パターンで説明した手順と同様である。こうして、医師１１０Ａによって作成された一般オーダー情報は、ファイルサーバー３０へと転送されて、対象患者に関連付けされて記録される（図４の矢印符号Ｃ）。
【０２３５】
このとき、リクエスト情報に対応する一般オーダー情報が作成されて、ファイルサーバー３０に登録されると、当該ファイルサーバー３０は、該当するリクエスト情報を同時配信した他の医師（図４に示す例では医師１１０が該当する）に対して「処理済み」である旨を表すステイタス（状況状態）情報を送る。これにより、ある一つのリクエスト情報に対して、複数の一般オーダー情報が作成されてしまうといった重複処理を防ぐことができる。
【０２３６】
ファイルサーバー３０に登録された一般オーダー情報は、受付部門を経た後、対応するリクエスト情報の発信者（第２端末２０）に宛てて送信される。
【０２３７】
このような構成により、大規模医療施設においても、同様に適用することができ、同様の効果を得ることができる。
【０２３８】
本実施形態の医用画像管理システム１の使用状況における第３使用パターンの概略は、以上である。
【０２３９】
上記のような作用を実現するために、本実施形態の医用画像管理システム１における情報端末装置（第１端末１０，第２端末２０）及びファイルサーバー３０の主要構成を、以下に説明する。
【０２４０】
図５は、本実施形態の医用画像管理システムにおける情報端末装置の主要構成を示すブロック構成図である。図６は、本実施形態の医用画像管理システムにおけるファイルサーバーの主要構成を示すブロック構成図である。
【０２４１】
まず、本実施形態の医用画像管理システム１における情報端末装置（１０，２０）の主要構成を説明する。情報端末装置は、上述したように、医師が使用する第１端末１０と、医師以外の人物（例えば医師以外の医療従事者又は患者家族等）が使用する第２端末２０とがある。これらは、それぞれの形態が異なっていたとしても、その主要構成は略同様である。したがって、第１端末１０と第２端末２０とは同じ構成を有するものとして、以下の説明をする。
【０２４２】
図５に示すように、情報端末装置（１０，２０）は、撮像部１１と、機器通信部１２と、ネットワーク通信部２３と、操作部１３と、タッチパネル１４と、表示部１５と、記録部１６と、確認センサ１７と、集音部２４と、時計部２２と、画像処理制御部２１と、リクエスト情報又はオーダー情報作成部１８と、メモリ２５等を主に備えて構成されている。
【０２４３】
なお、情報端末装置（１０，２０）の構成要素としては、ここで列挙した以外にも、種々の構成要素を具備している。しかしながら、それらの構成要素は、本発明の要旨には直接関連しない部分であるので、その図示及び説明は省略する。そして、図示及び説明を省略した各種構成要素は、従来一般的な形態の情報端末装置に適用されているものと同様のものが具備されているものとする。
【０２４４】
撮像部１１は、光学像を形成する光学系と、この光学系により形成される光学的な被写体像を電気的な信号に変換する光電変換素子等を含む回路等によって構成され、撮像機能を実現する構成ユニットである。
【０２４５】
なお、撮像部１１についての具体的な構成は、従来一般的な形態の撮像ユニットと略同様のものが適用される。この撮像部１１は、後述する撮像制御部２１ａによって制御される。
【０２４６】
機器通信部１２は、機器同士の間で行われる通信を実現する回路ユニット（例えば近距離無線通信手段等）を含んで構成される構成ユニットである。
【０２４７】
ネットワーク通信部２３は、ネットワーク４０経由でファイルサーバー３０との間の通信を実現する回路ユニットを含んで構成される構成ユニットである。
【０２４８】
なお、機器通信部１２及びネットワーク通信部２３に含まれる通信手段は、無線方式の通信手段に限らず、有線方式の通信手段も含まれる。また、機器通信部１２及びネットワーク通信部２３は、後述する通信制御部２１ｃによって制御される。
これら機器通信部１２及びネットワーク通信部２３（総称して通信部という）は、第２端末２０においては、リクエスト情報を第１端末１０若しくはファイルサーバー３０へと送信する送信機能と、第１端末１０若しくはファイルサーバー３０から送られてくる一般オーダー情報を受信する受信機能とを合わせ持っている。
【０２４９】
操作部１３は、使用者（ユーザ）によって行われる各種の操作を受けて、対応する各種の指示信号を発生させるための操作部材及び回路部を含む構成ユニットである。
【０２５０】
タッチパネル１４は、表示部１５の表示画面上に重畳させた形態で配置される操作部材である。当該タッチパネル１４は、使用者（ユーザ）の指等の操作指示を受けて対応する各種の指示信号を発生させる操作部材である。
【０２５１】
なお、このタッチパネル１４は、上記操作部１３に含まれるものであるが、近年、さまざまな電子装置において盛んに適用されている操作部材の一つでもあり、特に重要構成となるものであるので、操作部１３とは別に表記している。
【０２５２】
操作部１３及びタッチパネル１４は、後述する操作判定部２１ｂによって、いずれの操作部材が操作されたかが判定される。その判定結果に基づいて、画像処理制御部２１は、対応する所定の操作信号を対応する構成ユニットに向けて出力する。
【０２５３】
表示部１５は、表示パネル及びその駆動回路等（不図示）からなり表示機能を実現する構成ユニットである。表示部１５の表示パネルには、撮像部１１を用いて取得された画像データに基く画像や、各種設定プログラム等によって生成されるメニュー画像が表示される。この表示部１５は、表示制御部２１ｄによって制御される。
【０２５４】
記録部１６は、各種のデータファイルを記録するための構成ユニットである。この記録部１６に記録されるデータファイルとしては、例えば、画像データ及びメタデータ（一般メタデータ，医療メタデータ）を含む画像データファイルや、所定の撮影を行う際に必要となる設定項目の固有の設定等の各種設定をまとめてファイル化した設定情報（具体的には、例えば医用参照画像を取得する際に行うべき各種設定をまとめた設定情報等），当該端末装置（１０，２０）や通信相手の装置（端末又はファイルサーバー等）の装置情報等のほか、その他各種の情報がある。また、記録部１６は、集音部２４で取得された音声データなども記録する。
【０２５５】
時計部２２は、いわゆるリアルタイムクロック（Real-Time Clock；ＲＴＣ）などと呼ばれる内部時計回路である。この時計部２２は、例えば画像データファイル等に対して日時情報，時刻情報等を付与したり、制御処理中における所定の指示タイミング間の計時を行ったり、時間的制御等の際に利用される回路部である。
【０２５６】
集音部２４は、マイクロフォン及びその駆動回路等からなり、音声データを収集するための構成ユニットである。集音部２４は、画像処理制御部２１によって制御される。集音部２４で取得された音声データに基づいて、音声判定部２１ｈによる各種の判定が行われる。集音部２４によって取得された音声データは記録部１６に記録される。
【０２５７】
画像処理制御部２１は、本情報端末装置（１０，２０）を統括的に制御する制御回路と、各種の画像データに基く各種の画像処理を行う画像処理回路である。
【０２５８】
この画像処理制御部２１は、撮像制御部２１ａと、操作判定部２１ｂと、通信制御部２１ｃと、表示制御部２１ｄと、記録制御部２１ｅと、画像判定部２１ｆと、音声判定部２１ｈ等を備えて構成されている。
【０２５９】
撮像制御部２１ａは、撮像部１１を制御して、ライブビュー画像表示用データを取得したり、所定の操作を受けて静止画像データや動画像データを取得する撮像動作を実行する回路部若しくはプログラムソフトウエアである。
【０２６０】
操作判定部２１ｂは、操作部１３をからの入力を受けて、入力された操作指示信号を判定する回路部若しくはプログラムソフトウエアである。この操作判定部２１ｂによる判定結果を受けて、当該画像処理制御部２１は、対応する構成ユニットの制御を実行する。
【０２６１】
通信制御部２１ｃは、機器通信部１２及びネットワーク通信部２３を制御する回路部若しくはプログラムソフトウエアである。この通信制御部２１ｃは、操作部１３等からの指示信号を受けて、通信関連の制御、例えば、端末装置同士の間での通信を行うか、ネットワーク４０経由でファイルサーバー３０との間の通信を行うか等の選択や、選択された通信手段を制御して、対応する各種の通信制御を行う。
【０２６２】
表示制御部２１ｄは、表示部１５を制御する回路部若しくはプログラムソフトウエアである。この表示制御部２１ｄは、操作部１３等からの指示信号を受けて、表示関連の制御、例えば、表示部１５の表示パネルによって表示すべき表示内容の選択や切り換え制御を行う。
【０２６３】
記録制御部２１ｅは、記録部１６を制御する回路部若しくはプログラムソフトウエアである。この記録制御部２１ｅは、操作部１３等からの指示信号を受けて、記録関連の制御、例えば、記録部１６に記録する各種の情報を所定のデータ形式に変換し、所定の記憶媒体（不図示）の所定の領域に記録する制御を行う。
【０２６４】
また、記録制御部２１ｅは、一般オーダー関連付け部２１ｅａを有する。この一般オーダー関連付け部２１ｅａは、医師により若しくはファイルサーバー３０のオーダー情報作成部３１ｂにより作成された一般オーダー情報に含まれる情報を医療メタデータとして扱い、これを撮像部１１によって取得された画像データファイルに関連付けすることで、一つの画像データファイルを医用オブジェクトとしてを作成し、記録部１６に引き渡す役目をする構成部である。
【０２６５】
換言すると、記録制御部２１ｅの一般オーダー関連付け部２１ｅａは、画像データ，撮影関連情報，オーダー関連情報等を医用管理データ化（図７参照）できるように整理してファイル化し、これを記録部１６へと引き渡す役目を有する構成部である。
【０２６６】
なお、記録部１６に記録される医療メタデータに含まれる情報には、上述の説明で列挙した各種の情報に加えて、さらに、例えば通信に関する情報（通信情報），患者情報（対象情報），医師に関する情報，医師によるオーダーに関する情報（オーダー情報，依頼情報），患部の治療や検査に関する情報（条件情報），装置に関する情報（装置識別情報（ＧＳ１コード，ＪＡＮコード，装置シリアル番号等）等），カラーチャート（色票）情報，メジャー情報，装置の姿勢や位置に関する情報，医用画像又は医用参照画像としての承認情報や真贋情報等のほか、その他の各種情報等も含まれる。
【０２６７】
また、記録部１６には、医師により若しくはファイルサーバー３０のオーダー情報作成部３１ｂにより作成され、当該情報端末装置（１０，２０）にて受信した一般オーダー情報等も記録される。
【０２６８】
画像判定部２１ｆは、撮像部１１によって取得された画像データや、他の端末装置等から転送され入力された画像データ等に基づいて、各画像データを解析することにより得られる各種の情報の判定処理、例えば撮影環境の光源情報，被写体までの距離情報，被写体（例えば顔領域）情報等の判定処理を行う回路部若しくはプログラムソフトウエアである。
【０２６９】
音声判定部２１ｈは、集音部２４によって取得された音声データに基づいて所定の判定処理を行う構成部である。そのために、音声判定部２１ｈは、姓名判定部及び応答判定部等の処理回路を有する。ここで、姓名判定部は、例えば集音部２４によって取得された音声データに、人声を検出すると共に、人声である場合には、姓名を名乗るデータであるかを判定する。また、応答判定部は、同様に、例えば集音部２４によって取得された音声データに、人声を検出すると共に、人声である場合に、応答しているデータであるかを判定する。
【０２７０】
具体的には、例えば、医用参照画像撮影モードで患者の撮影を行う際には、上述したように、その撮影前、例えば撮影直前に、本人確認のための声がけなどが行われる。その場合に集音部２４によって取得される音声データに基づいて、姓名判定や応答判定などが行われる。
【０２７１】
確認部２１ｇは、撮像部１１によって取得された画像データファイルが、対応するオーダー情報に沿って撮影されているか否かの確認を行う回路部若しくはプログラムソフトウエアである。
【０２７２】
確認センサ１７は、取得された画像データファイルに基づいて上記確認部２１ｇによる確認を行う際に必要な関連情報を取得するためのセンサー部材及び電子回路等である。この確認センサ１７としては、例えば本人確認を行うための技術として、顔認識技術，指紋認証技術，虹彩認証技術等を実現するセンサー部材及び電子回路等がある。
【０２７３】
リクエスト情報／オーダー情報作成部１８は、当該情報端末装置が第１端末１０として利用される場合には操作部１３からの入力を受けてオーダー情報を作成し、当該情報端末装置が第２端末２０として利用される場合には操作部１３からの入力を受けてリクエスト情報を作成するための回路部若しくはプログラムソフトウエアである。
【０２７４】
メモリ２５は、撮像部１１によって取得されたデジタル画像信号や機器通信部１２を介して送受信される各種データ等のほか、当該装置（１０，２０）において実行される各種の制御プログラム等を一時的に記憶させるための半導体メモリである。このメモリ２５としては、例えば、書き換え可能な不揮発性の半導体メモリ（例えばＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）等）や、一時的な作業用途に用いられる揮発性の半導体メモリ（例えばＳＤＲＡＭ (Synchronous Dynamic Random Access Memory) 等）の一時メモリをも含むものとする。
【０２７５】
次に、本実施形態の医用画像管理システム１におけるファイルサーバー３０の主要構成を説明する。なお、このファイルサーバー３０は、例えば既存の病院情報システム（ＨＩＳ）等に含まれるファイルサーバー等に相当するものである。
【０２７６】
図６に示すように、ファイルサーバー３０は、制御部３１と、画像データベース３２と、オーダー情報等データベース３３と、患者情報データベース３４と、通信部３５等を主に備えて構成されている。
【０２７７】
制御部３１は、本ファイルサーバー３０を統括的に制御する制御回路である。この制御部３１は、患者判定部３１ａと、オーダー情報作成部３１ｂと、撮影条件情報作成部３１ｃ等を主に有して構成されている。なお、制御部３１としては、例えばＣＰＵ等のプロセッサあるいはＦＰＧＡ等によって構成される。
【０２７８】
患者判定部３１ａは、情報端末装置（１０，２０）から転送されてきたリクエスト情報若しくは一般オーダー情報に含まれる患者関連情報等に基づいて、当該リクエスト情報若しくは一般オーダー情報に対応する患者情報への関連付けのための回路部若しくはプログラムソフトウエアである。
【０２７９】
オーダー情報作成部３１ｂは、当該ファイルサーバー３０に医師がアクセスしてオーダー情報を作成するのに際して、画像データベース３２，オーダー情報等データベース３３，患者情報データベース３４等の各種情報を参照して、オーダー情報の作成を支援する回路部若しくはプログラムソフトウエアである。
【０２８０】
また、オーダー情報作成部３１ｂは、医師からの指示情報を受けてリクエスト情報に応じた一般オーダー情報を作成する回路部若しくはプログラムソフトウエアである（図３の第２使用パターン参照）。
【０２８１】
ここで、例えば、画像撮影に関する一般オーダー情報は、患部毎にある程度のフォーマットが規定されている。したがって、医師は、一般オーダー情報作成時に、所望する検査種別（例えば「画像撮影検査」等）と、所望の患部（例えば「顔」，「膝」等）等を選択することで、大まかな形態の一般オーダー情報を作成し得る。
【０２８２】
さらに、本実施形態の医用画像管理システム１においては、例えば、患者情報データベース３４から対象患者の電子カルテ情報や検査履歴情報等を参照し、過去に行った検査等のオーダー一覧から今回行う検査等（例えば「画像撮影検査」等）と同様若しくは類似のオーダーがあれば、その情報を読み込んで、新たな一般オーダー情報の作成をさせる等のことを行うことができる。
【０２８３】
このように、オーダー情報作成部３１ｂは、医師がオーダー情報（医療オーダー情報，一般オーダー情報のいずれでもよい）を作成する際に、入力作業の省略や効率化を行って、オーダー情報の作成を支援する構成部である。
【０２８４】
撮影条件情報作成部３１ｃは、医師からの指示に基づいてオーダー情報作成部３１ｂが作成したオーダー情報が、例えば画像撮影を伴うオーダーである場合に、その画像撮影指示に適切な撮影条件情報を作成する回路部若しくはプログラムソフトウエアである。
【０２８５】
この撮影条件情報作成部３１ｃは、オーダー情報作成時に参照した患者情報等に基づいて、過去に行われた同様の「画像撮影検査」時の過去のオーダー情報や、その検査結果（取得され記録されている画像データとその付随情報等）情報等を参照し、今回のオーダー情報に対応する画像撮影時に最適な撮影条件設定情報を作成する。
【０２８６】
通常の場合、医師がオーダー情報を作成する時には、医療行為的な指示を出すのみであるが、本実施形態の医用画像管理システム１においては、医師が作成した医療行為的な指示のみからなるオーダー情報に基づいて、撮影条件情報作成部３１ｃが、画像撮影を行う際の撮影条件情報を作成する。この撮影条件情報は、作成される一般オーダー情報を受けて画像データを撮影する（取得する）ための情報端末装置（１０，２０）に伝達されて、撮影時に利用される。
【０２８７】
オブジェクト情報生成部３１ｄは、例えばＤＩＣＯＭ規格準拠のデータ形式のオブジェクトとしての医用オブジェクト（医用画像データファイル）を作成するための回路部若しくはプログラムソフトウエアである。
【０２８８】
具体的には、オブジェクト情報生成部３１ｄは、医師から出された医療オーダー情報又は一般オーダー情報を受けて、これらのオーダー情報に対応する画像データファイル（オーダー情報に応じて取得された画像データ）に対して医療メタデータとして付与すべき各種の医療関連情報であるオブジェクト情報を抽出し、医療メタデータを生成する。
【０２８９】
また、オブジェクト情報生成部３１ｄは、医療オーダー情報又は一般オーダー情報に応じて情報端末装置（１０，２０）によって取得された後、当該ファイルサーバー３０の画像データベース３２へと転送されてきた画像データファイル（Ｅｘｉｆ画像データファイル）に対して、対応する医療オーダー情報又は一般オーダー情報から抽出した医療関連情報（オブジェクト情報）から生成した医療メタデータを関連付ける。
【０２９０】
そして、オブジェクト情報生成部３１ｄは、画像データ本体と、これに対応する一般メタデータ及び医療メタデータとを関連付けて一つの画像データファイルを医用オブジェクト化して作成する。
【０２９１】
一方、画像データベース３２は、画像データファイルを蓄積したデータベース部である。この画像データベース３２に蓄積された複数の画像データファイルは、固有の患者情報にそれぞれ含まれる各種の画像データファイル、例えば特定患者の患部や症状を撮影した医用画像又は医用参照画像や患者を特定するための顔を含む画像等のほか、特定患部や特定症状の画像を取得する際に参考とするために予め用意されたサンプル画像等がある。
【０２９２】
ここで、医用画像又は医用参照画像は、具体的には例えば、診察過程中において術前又は術後の経過を記録した画像データファイルや、手術中の患部の状態を記録した画像データファイル等がある。また、この場合の画像データファイルの形態としては、一般的な撮像装置で記録される画像データファイル（Ｅｘｉｆ画像データファイル）のほか、Ｘ線画像データ，超音波画像データ，内視鏡画像データ等がある。このうち、Ｘ線画像データ，超音波画像データ，内視鏡画像データ等は、医師のオーダー（依頼）を受けて、医療関係の各種有資格が、病院等の医療拠点に設置された専用装置を用いて取得される画像データであり、医師の承認を受けた医用画像である。これらの医用画像のデータファイルは、基本的にＤＩＣＯＭ規格に準拠したデータ形式を有している。
【０２９３】
画像データベース３２に蓄積されたこれら複数の画像データファイルのうちサンプル画像以外は、それぞれが各対応する医療関連情報（電子カルテ情報や患者情報等）に関連付けされた形態で記録されている。
【０２９４】
さらに、各画像データファイルには、撮影日時情報等をはじめとした一般メタデータと、患者ＩＤや電子カルテ情報に基づく各種の情報を含む医療メタデータとからなる付随情報（メタデータ）が画像データ本体に対して関連付けられて記録されている。
【０２９５】
他方、オーダー情報等データベース３３は、医師によって出されるオーダー情報に関する情報を蓄積したデータベース部である。このオーダー情報等データベース３３に記録される情報としては、例えば所定の患部や所定の症状に対応させて予め設定されたオーダー仕様書のサンプル情報がある。このオーダー仕様書には、例えば医師名（依頼者名），患者ＩＤ，使用装置情報，撮影条件情報等が記載される。
【０２９６】
一般に、医師が特定の患者の検査等を行うためには各医療部署に対して、画像データの取得を依頼する際には検査等の対象患者毎に、その患部や症状に合わせたオーダー情報を発行する必要がある。
【０２９７】
この場合において、オーダー情報等データベース３３が設けられていることによって、医師は新規に作成するべきオーダー情報をゼロベースで作成する必要がなくなるという利点がある。
【０２９８】
つまり、医師は、オーダー情報等データベース３３に記録されている複数のオーダー仕様書（サンプル）のなかから、今回行う対象患者の患部や症状に合致するものを参考とすることができ、よって、個々の対象患者の症状，患部等に応じてそれぞれに最適なオーダー仕様書を作成することができるようになる。
【０２９９】
患者情報データベース３４は、例えば患者ＩＤや電子カルテ情報等の患者情報を蓄積したデータベース部である。
【０３００】
通信部３５は、ネットワーク４０を介して複数の情報端末装置（１０，２０）との間で相互に各種のデータファイルの送受信を行う回路部若しくはプログラムソフトウエアである。この通信部３５は、制御部３１に含まれる通信制御部（不図示）によって、所定の通信が実行されるように制御されている。
【０３０１】
なお、上記の説明では、一般画像取得装置を用いて取得された画像オブジェクト（画像データファイル；Ｅｘｉｆファイル）を、ＤＩＣＯＭ規格に準拠したデータ形式の医用オブジェクト（医用画像データファイル）として記録するための構成として、ファイルサーバー３０の制御部３１に含まれるオブジェクト情報生成部３１ｄを用いる構成を示している。
【０３０２】
しかしながら、一般画像取得装置を用いて取得された画像オブジェクト（画像データファイル；Ｅｘｉｆファイル）を、ＤＩＣＯＭ規格に準拠したデータ形式の医用オブジェクト（医用画像データファイル）として記録するための構成としては、上記の例示に限られることはない。
【０３０３】
例えば、患者家族等１２０が使用する情報端末装置（第２端末２０）において、リクエスト情報に応じて医師１１０が発した一般オーダー情報に応じて行われる画像取得時に、記録制御部２１ｅの一般オーダー情報関連付け部２１ｅａによって医療メタデータが関連付けされた医用画像データファイルを作成するような構成としてもよい。この構成の場合、記録制御部２１ｅの一般オーダー情報関連付け部２１ｅａは、オブジェクト情報生成部として機能する。
【０３０４】
図１０は、本実施形態の医用画像管理システムにおいて、各種の情報の流れを概念的に示す概念図である。
【０３０５】
なお、図１０は、図面の煩雑化を避けるために、本実施形態の医用画像管理システムの構成を簡略に示している。例えば、図１において説明したネットワーク４０の図示を省略している。また、情報端末装置である第１端末１０，第２端末２０の構成についても、図示を簡略化している。
【０３０６】
図１０においては、各種の情報の流れとして、おおまかに二種の流れを示している。即ち、図１０において、実線で示す流れ（符号（Ａｘ）；ｘは数字）は、第１端末１０と第２端末２０との通信をファイルサーバー３０を介して行う際の情報の流れを概念的に示している。また、図１０において、破線で示す流れ（符号（Ｂｘ）；ｘは数字）は、第１端末１０と第２端末２０との間で直接通信を行う際の情報の流れを概念的に示している。
【０３０７】
なお、以下の説明では、第２端末２０を使用するのは、非医療従事者である患者家族等１２０であるものと想定した例示である。したがって、医師１１０が出すオーダー情報としては、一般オーダー情報とのみ記述している。
【０３０８】
しかしながら、例えば、医師の往診若しくは訪問介護等の状況であれば、第２端末２０使用するのは医療従事者の場合もあり得る。この場合には、第２端末２０からのリクエスト情報に応じる医師１１０が出すオーダー情報は、医療オーダー情報となる。
【０３０９】
本実施形態の医用画像管理システムにおいて、第１端末１０と第２端末２０との通信をファイルサーバー３０を介して行う際には、まず、患者家族等１２０が第２端末２０からファイルサーバー３０を介して第１端末１０に対してリクエスト情報を送信する（図１０符号（Ａ１））。
【０３１０】
これを見た医師１１０は、第１端末１０を操作して一般オーダー情報を作成し、作成した一般オーダー情報を第１端末１０からファイルサーバー３０を介して第２端末２０に対して送信する（図１０符号（Ａ２））。
【０３１１】
これを受けて第２端末２０は、受信した一般オーダー情報をメモリ２５に記録する（図１０符号（Ａ３））。
【０３１２】
次に、患者家族等１２０は、第２端末２０を使用して、受信した一般オーダー情報に応じた撮影動作を実行する。これにより、第２端末２０は、撮像部１１によって取得された画像信号に基づいてＥｘｉｆ規格に準拠した通常の画像データファイルを生成し、メモリ２５に記録する（図１０符号（Ａ４））。
【０３１３】
続いて、メモリ２５に記録された一般オーダー情報と、この一般オーダー情報に応じて取得された通常形態の画像データファイル（Ｅｘｉｆファイル）を、ファイルサーバー３０の制御部３１のオブジェクト情報生成部３１ｄへと送信する（図１０符号（Ａ５））。
【０３１４】
これを受けて、オブジェクト情報生成部３１ｄは、一般オーダー情報から所定の医療関連情報（オブジェクト情報）を抽出して医療メタデータを生成し、この医療メタデータを、対応する画像データファイル（Ｅｘｉｆ画像データファイル）に関連付けて、一つの医用オブジェクト（医用画像データファイル）を作成する。
【０３１５】
こうして作成された医用画像データファイルは、画像データベース３２へと送られて記録される（図１０符号（Ａ６））。
【０３１６】
一方、第２端末２０において、医用画像データファイルを生成する構成の場合には、次のようになる。
【０３１７】
一般オーダー情報と、この一般オーダー情報に応じて取得された通常形態の画像データファイル（Ｅｘｉｆファイル）が、メモリ２５に記録されるまでの経過は、上述の場合と同様である（図１０の符号（Ａ１）〜（Ａ４））。
【０３１８】
次に、画像処理制御部２１の記録制御部２１ｅは、メモリ２５に記録された一般オーダー情報と、この一般オーダー情報に応じて取得された通常形態の画像データファイル（Ｅｘｉｆファイル）に基づいて、医療メタデータを生成し、この医療メタデータを画像データファイルに関連付けして、画像データ本体と、一般メタデータ（Ａ）（Ｂ）と、医療メタデータとを一体にした医用画像データファイルを作成する（図１０の符号（Ａ８））。
【０３１９】
こうして作成された医用画像データファイルは、画像データベース３２へと送られて記録される（図１０符号（Ａ９））。
【０３２０】
他方、本実施形態の医用画像管理システムにおいて、第１端末１０と第２端末２０との通信を直接行う際には、まず、患者家族等１２０が第２端末２０から第１端末１０に対してリクエスト情報を直接送信する（図１０符号（Ｂ１））。
【０３２１】
これを見た医師１１０は、第１端末１０を操作して一般オーダー情報を作成し、作成した一般オーダー情報を第１端末１０から第２端末２０に対して直接送信する（図１０符号（Ｂ２））。
【０３２２】
これを受けて第２端末２０は、受信した一般オーダー情報をメモリ２５に記録する（図１０符号（Ｂ３））。
【０３２３】
次に、患者家族等１２０は、第２端末２０を使用して、受信した一般オーダー情報に応じた撮影動作を実行する。これにより、第２端末２０は、撮像部１１によって取得された画像信号に基づいてＥｘｉｆ規格に準拠した通常の画像データファイルを生成し、メモリ２５に記録する（図１０符号（Ａ４）と同様）。そして、以降の作用は、上述の符号（Ａ５）〜（Ａ９）と同じである。
【０３２４】
なお、図１０に示すように、ファイルサーバー３０と各情報端末装置（１０，２０）との間のネットワーク経由での通信を行う際には、ＳＯＰクラス（サービスオブジェクトペアクラス）が用いられている（図７参照）。
【０３２５】
このように構成された本実施形態の医用画像管理システム１の作用を、以下に説明する。なお、以下に説明する作用は、上述した各使用パターンのうち、例えば「第２パターン」又は「第３パターン」の作用を基本的に想定している。
【０３２６】
まず、本実施形態の医用画像管理システム１における情報端末装置のうちの第２端末２０の作用を説明する。図１１，図１２は、本実施形態の医用画像管理システムにおける情報端末装置のうち第２端末２０の作用を示すフローチャートである。
【０３２７】
本実施形態の医用画像管理システム１において、第２端末２０は、上述したように、例えば医師以外の人物、例えば患者家族が使用する情報端末装置であるものとしている。
【０３２８】
まず、第２端末２０は、電源オン状態とされて使用可能に起動している状態にあるものとする。
【０３２９】
この状態において、第２端末２０の画像処理制御部２１は、まず、図１１のステップＳ５１において、表示制御部２１ｄ等を制御して表示部１５の表示画面上に、現在設定されている動作モード表示を行う。例えば、ここで表示される動作モード、即ち当該第２端末２０によって実行可能な動作モードとしては、例えば通常の撮影モードや再生モード，各種設定モード，他の機器との通信モード等のほか、上述の「医用参照画像取得アプリ」によって実行される各種の動作モード、例えばリクエスト情報作成モード，リクエスト情報送信モード，一般オーダー情報受信モード，医用参照画像撮影モード，医用参照画像転送モード等がある。なお、当該第２端末２０の電源オン直後に標準で設定される動作モードは、通常の場合は撮影モードである。
【０３３０】
続いて、ステップＳ５２において、画像処理制御部２１は、現在設定されている動作モードの確認を行い、現在設定されている動作モードが、医用参照画像撮影モードであるか否かの確認を行う。ここで、現在設定されている動作モードが医用参照画像撮影モードである場合には、次のステップＳ５３の処理に進む。また、現在設定されている動作モードが医用参照画像撮影モード以外の動作モードである場合には、ステップＳ８１の処理に進む。
【０３３１】
ステップＳ５３において、画像処理制御部２１は、所定のログイン処理を実行する。このログイン処理は、当該第２端末２０から医師の第１端末１０への直接接続のためのログイン処理、若しくはファイルサーバー３０へネットワーク４０経由で接続するためのログイン処理を想定している。
【０３３２】
なお、上述のステップＳ５３の処理にて行われるログイン処理の操作手続きとしては、例えば予め医師や病院側のシステムから特定人（患者又は患者家族）に対して発行された情報（例えば診察券番号等の特定情報やログインＩＤ及びログインパスワード等）を入力する操作である。この場合における入力手段としては、具体的には、例えば入力操作部材としてのタッチパネルを用いて、表示画面に表示されたテンキー表示等をタッチ操作による直接入力等である。また、例えば医師や病院等から予め特定人（患者又は患者家族）に対して発行されたコード情報（診察券番号等の特定情報が含まれているバーコードやＱＲコード（登録商標）等の形態のコード）を第２端末２０のコード読み取りアプリ等を用いて読み取る等の画像認識入力による操作などでもよい。
【０３３３】
また、ここでのログイン処理としては、当該第２端末２０を用いた医用参照画像撮影モードによる一連の動作を実行するためのログイン処理としてもよい。つまり、当該第２端末２０において、ある特定の動作モードを実行するために、動作モードの実行時に所定のログイン処理を行うようにする。このような動作モードのためのログイン処理を設けることによって、予め医師や病院において認証された端末を用いて、本人確認がなされた人物のみが、当該医用参照画像撮影モードによる一連の動作を実行させることができるようにすることができる。
【０３３４】
ここで、ログイン処理が完了すると、次のステップＳ５４の処理に進む。また、ここでログイン処理が完了しない場合には、上述のステップＳ５２の処理に戻る。
【０３３５】
ステップＳ５４において、画像処理制御部２１は、リクエスト情報を発信するか否かの確認を行う。ここで、まだリクエスト情報を発信しておらず、かつリクエスト情報を発信しようとする場合には、次のステップＳ６１の処理に進む。また、既にリクエスト情報を発信済みの場合、若しくはリクエスト情報を発信しない場合には、図１２のステップＳ５５の処理に進む（図１１，図１２の丸数字符号１１参照）。
【０３３６】
上述のステップＳ５４の処理において、リクエスト情報を発信するものとして、ステップＳ６１に進むと、このステップＳ６１において、画像処理制御部２１は、動作モードをリクエスト情報作成モードに切り換えて、適宜使用者（ユーザ）により入力されるリクエスト情報のうちの基本情報の入力処理を受け入れる。続いて、ステップＳ６２において、画像処理制御部２１は、適宜使用者（ユーザ）により入力されるリクエスト情報のうちのコメント情報の入力処理を受け入れる。
【０３３７】
上述のステップＳ６１，Ｓ６２にて入力されるリクエスト情報は、例えば、患者を特定するための基本情報に加えて、コメントとして付する情報であって、医師に対する患者側の主訴等を含む現在の病状等を相談するための情報提供といったことを想定している。
【０３３８】
このようなリクエスト情報を受けた医師が、そのリクエスト情報に応じて一般オーダー情報を発信するか否かは、当該医師の判断によるものである。したがって、患者側からリクエスト情報を医師に向けて発信したとしても、医師からの応答、例えば画像に関する一般オーダー情報の発信等がない場合もあり得る。医師が患者の画像等を不要と考えれば、そのような一般オーダー情報は発信されない。
【０３３９】
したがって、上述のステップＳ６１，Ｓ６２において作成され、後述のように患者側から医師に向けて発信されるリクエスト情報は、医師に対する相談情報としての性格が強いものである。
【０３４０】
このようにしてリクエスト情報の入力処理が終了したら、次のステップＳ６３の処理に進む。
【０３４１】
ステップＳ６３において、画像処理制御部２１は、作成したリクエスト情報の送信処理を実行する否かの確認を行う。ここで、リクエスト情報の送信処理を実行する場合には、次のステップＳ６４の処理に進む。また、リクエスト情報の送信処理を実行しない場合、例えば、リクエスト情報の追加入力を行う等の場合には、ステップＳ６１の処理に戻り、以降の処理を繰り返す。
【０３４２】
ステップＳ６４において、画像処理制御部２１は、動作モードをリクエスト情報送信モードに切り換える。そして、画像処理制御部２１の通信制御部２１ｃは、機器通信部１２又はネットワーク通信部２３を制御して、医師の第１端末１０又は院内システムのファイルサーバー３０にアクセスして、リクエスト情報の送信処理を実行する。その後、画像処理制御部２１は、動作モードを一般オーダー情報受信モードに切り換えて、受信待機状態になる。
【０３４３】
次に、ステップＳ６５において、画像処理制御部２１は、一般オーダー情報を受信したか否かの確認を行う。この一般オーダー情報は、医師の第１端末１０又は院内システムのファイルサーバ−３０から、当該第２端末２０に向けて発信される情報である。
【０３４４】
ここで、一般オーダー情報を受信した場合には、図１２のステップＳ７１の処理に進む（図１１，図１２の丸数字符号１２参照）。また、一般オーダー情報を受信していない場合には、ステップＳ６６の処理に進む。
【０３４５】
ステップＳ６６において、画像処理制御部２１は、時計部２２を参照して所定時間経過したか否かの確認を行う。ここで、所定時間が経過した場合には、次のステップＳ６７の処理に進む。また、所定時間が経過しない間は、上述のステップＳ６５の処理に戻り、当該受信確認を繰り返す。
【０３４６】
上述のステップＳ６６の処理にて、所定時間の経過が確認されて、ステップＳ６７の処理に進むと、このステップＳ６７において、画像処理制御部２１は、オーダー受信待機モードを設定する。このオーダー受信待機モードとは、送信済みのリクエスト情報に対する応答としての一般オーダー情報を受信するための受信待機モードである。第２端末２０においては、この受信待機モードを設定することで、常に受信待機状態にありながら、並行して他の所望の作業処理を実行させることができるものとしている。オーダー受信待機モードの設定が完了すると、次のステップＳ６８の処理に進む。
【０３４７】
ステップＳ６８において、画像処理制御部２１は、ログアウト処理を行うか否かの確認を行う。ここで、ログアウト処理を指示する指示信号が確認された場合には、所定のログアウト処理を実行した後、上述のステップＳ５１の処理に進む。また、ログアウト処理を指示する指示信号が確認されない場合には、上述のステップＳ５４の処理に戻り、以降の処理を繰り返す。
【０３４８】
一方、上述のステップＳ５２の処理にて、現在設定されている動作モードが医用参照画像撮影モード以外の動作モードである場合にステップＳ８１の処理に進むと、このステップＳ８１において、画像処理制御部２１は、一般オーダー情報の受信がなされたか否かの確認を行う。ここで、一般オーダー情報の受信が確認された場合には、次のステップＳ８２の処理に進む。また、一般オーダー情報の受信が確認されない場合には、ステップＳ９１の処理に進む。なお、ここで一般オーダー情報の受信が確認される場合とは、上述のステップＳ６７の処理にてオーダー受信待機モードに設定されている場合である。
【０３４９】
ステップＳ８２において、画像処理制御部２１の表示制御部２１ｄは、表示部１５を制御して、所定のログイン警告を表示部１５の表示画面に表示する。このログイン警告とは、受信した一般オーダー情報を受信するために、第１端末１０又はファイルサーバー３０にログインするためのログイン操作を促す表示である。
【０３５０】
なお、上述のステップＳ８１の説明では、一般オーダー情報が受信されたという文言を用いて説明している。しかしながら、ステップＳ８１の処理は、実際には、当該情報の実体部分が受信されているわけではない。このステップＳ８１の時点では、例えば、医師又はファイルサーバー３０から第２端末２０に対して一般オーダー情報が発信された旨の通知を受信した程度のことを意味している。したがって、一般オーダー情報の実体を受信するために、上述のステップＳ８２においてログイン処理を行うようにしている。
【０３５１】
第２端末２０の使用者（ユーザ）は、適宜ログイン操作を行った後、所定の操作を行って一般オーダー情報を受信する。なお、上述したように、オーダー受信待機モードは、他の動作処理と並行に実行している。したがって、この一般オーダー情報の受信処理を終了したら、他の動作処理に戻るようにすればよい。
【０３５２】
即ち、上述のステップＳ５２の処理にて、現在設定されている動作モードが、医用参照画像撮影モード以外である場合に、ステップＳ８１の処理に分岐したので、上述のステップＳ８２の処理に続く、他の動作がステップＳ９１の処理移行で実行される。
【０３５３】
即ち、ステップＳ９１において、画像処理制御部２１は、現在設定されている動作モードが、端末認証モードであるか否かの確認を行う。ここで、端末認証モードとは、当該医用画像管理システム１において第２端末２０を使用可能とするための登録手続き等を行なう動作モードである。
【０３５４】
なお、この端末認証モードでの登録手続きは、当該医用画像管理システム１にて情報端末装置（第２端末２０）を使用するのに際し、最初に一回行えばよい操作である。登録済みの情報端末装置を二回目以降に使用する際には、最初の登録手続きによって設定され、取得済みのＩＤ，パスワードを用いることによって、医用画像管理システム１において利用可能となる。
【０３５５】
ここで、端末認証モードに設定されていることが確認された場合には、次のステップＳ９２の処理に進む。また、端末認証モードではない場合には、ステップＳ９４の処理に進む。
【０３５６】
そして、このステップＳ９４において、画像処理制御部２１は、その他の動作モードによる処理を実行する。なお、ここで、その他の動作モードとしては、例えば、撮像機能付き通信装置（スマートフォン等のデバイス）であれば電話通信モードやメール送受信モード等がある。また、通信機能付き撮像装置（デジタルカメラ等のデバイス）であれば通常撮影モードや再生モード，メニューモード（設定モード）等がある。
【０３５７】
しかしながら、これらその他の動作モードについては、本発明に直接関連しない部分であるので、その詳細説明及び図示は省略する。したがって、その後の処理としては、上述のステップＳ５１の処理に戻るものとしている。
【０３５８】
上述したように、端末認証モードに設定されていることが確認されて、ステップＳ９２の処理に進むと、このステップＳ９２において、画像処理制御部２１は、ＩＤ設定処理やパスワード設定処理等、端末認証に必要な登録手続きに関する処理を実行する。その後、ステップＳ９３の処理に進む。
【０３５９】
ステップＳ９３において、画像処理制御部２１の操作判定部２１ｂは、操作部１３又はタッチパネル１４から入力される操作指示信号に応じて、対象患者の患者情報等をファイルサーバー３０から取得する処理等を実行する。必要な処理を終えたら、終了指示信号を待って、上述のステップＳ５１の処理に戻り、以降の処理を繰り返す。
【０３６０】
他方、上述のステップＳ５４において、リクエスト情報の発信をしない場合に、図１２のステップＳ５５に進むと、このステップＳ５５において、画像処理制御部２１は、一般オーダー情報の受信がなされたか否かの確認を行う。ここで、一般オーダー情報の受信が確認された場合には、次のステップＳ７１の処理に進む。この場合においては、ログインが維持されている状態にあるので、一般オーダー情報は実体が受信されていることになる。
【０３６１】
また、一般オーダー情報の受信が確認されない場合には、ステップＳ５６の処理に進む。ここで、ステップＳ５６の処理に進む場合とは、次のような状況である。即ち、上述のステップＳ５２の処理にて、医用参照画像撮影モードであることが確認されており、かつ、上述のステップＳ５３の処理にて、ログインが完了しており、かつ、上述のステップＳ５４の処理にて、リクエスト情報の発信を行わないことが確認されており、かつ、上述のステップＳ５５の処理にて、一般オーダー情報の受信がないことが確認されている、という状況である。このような状況としては、例えば、既に医用参照画像撮影モードによる一連の動作（リクエスト情報の送信，一般オーダー情報の受信，医用参照画像撮影モードでの撮影）が行われており、所望の医用参照画像としての画像データファイルを取得した状態に、既にある場合などが考えられる。このような場合には、ステップＳ５６の処理に進み、医用参照画像転送モードでの動作処理が実行される（後述）。
【０３６２】
なお、ここで一般オーダー情報の受信が確認される場合とは、上述のステップＳ６７の処理にてオーダー受信待機モードに設定されている場合であることは、上述のステップＳ８１の処理と同様である。
【０３６３】
一般オーダー情報の受信が確認されると、第２端末２０の画像処理制御部２１は、動作モードを医用参照画像撮影モードへ切り換える。当該第２端末２０の使用者（患者家族）は、同第２端末２０を用いて、受信済みの一般オーダー情報に応じた所定の撮影動作を実行する。
【０３６４】
ステップＳ７１において、画像処理制御部２１は、所定の撮影処理が実行されて画像データファイルが取得されたか否かの確認を行う。ここで、画像データファイルの取得が確認された場合には、次のステップＳ７２の処理に進む。また、画像データファイルの取得が確認されない場合（まだ撮影していない場合）には、図１１のステップＳ６８の処理に戻る（図１１，図１２の丸数字符号１３参照）。
【０３６５】
画像データファイルの取得が確認されると、ステップＳ７２において、画像処理制御部２１は、受信済みの一般オーダー情報に含まれるガイド情報（例えば撮影手順や情報表示等）やコメント情報を表示すると共に、撮像部１１で取得される画像データファイルを順次表示するライブビュー表示を行う。この場合において、一般オーダー情報の表示とライブビュー表示とは、時系列に表示するようにしてもよいし、重畳表示するようにしてもよいし、適宜操作部材を操作することによって切換表示を行うようにしてもよい。
【０３６６】
続いて、ステップＳ７２Ａにおいて、画像処理制御部２１（確認部２１ｇ）は、一般オーダー情報に含まれる各種の情報と、ライブビュー表示画像の画像データファイルに含まれる各種の情報（確認センサ１７の検出）とに基づいて、当該一般オーダー情報に応じた撮影が行われようとしているか否か、つまり、一般オーダー情報に含まれる各種の情報が満たされているか否かの確認を行う。ここで、一般オーダー情報に含まれる各種の情報が満たされていることが確認された場合には、次のステップＳ７３の処理に進む。また、一般オーダー情報に含まれる各種の情報が満たされていないことが確認された場合には、ステップＳ７２Ｂの処理に進む。
【０３６７】
ステップＳ７２Ｂにおいて、画像処理制御部２１は、表示制御部２１ｄを介して表示部１５を制御して、オーダー情報が満たされていない旨を表す所定の警告表示を行う。その後、ステップＳ７２の処理に戻る。
【０３６８】
第２端末２０の使用者（患者家族）は、ここで、警告表示に対応すべく、オーダー情報に沿った撮影が行われるように操作を修正することになる。ここで、正しい操作が行われて、ステップＳ７２Ａの処理にてオーダー情報が満たされていることが確認されると、当該警告表示が消える。これにより、次のステップＳ７３の処理に進む。
【０３６９】
続いて、ステップＳ７３において、画像処理制御部２１は、受信済みの一般オーダー情報に含まれる撮影条件等の情報を加味して、当該第２端末２０における撮影パラメータ等の調整処理を実行する。
【０３７０】
次に、ステップＳ７４において、画像処理制御部２１は、一般オーダー情報に従った撮影（例えば患者の顔画像と患部画像など）が行われたか否かの確認を行う。
【０３７１】
ここで、例えば患者の顔画像を、所望の患部画像と共に取得しているのは、同時に撮影される所望の患部画像が患者本人であるか否かの確認を行うためである。このような本人確認画像を、医参照画像を取得する際に同時に取得することは、例えば一般オーダー情報に含まれるガイド情報等に含まれている各種の指示に基づいて、上述のステップＳ７２の処理等で使用者に通知される。使用者は、このガイド情報に従って撮影を行うので、上述のような本人確認画像を所望の患部画像と共に忘れずに取得することができる。
【０３７２】
上述のステップＳ７４の処理にて、画像処理制御部２１は、一般オーダー情報に従った撮影が行われたことを確認すると、次のステップＳ７５の処理に進む。また、一般オーダー情報に従った撮影が行われていないことが確認されると、ステップＳ７８の処理に進む。
【０３７３】
ステップＳ７５において、画像処理制御部２１の記録制御部２１ｅは、取得された画像データファイルの記録処理を実行する。
【０３７４】
続いて、ステップＳ７６において、画像処理制御部２１の記録制御部２１ｅは、取得された画像データファイルに対して、一般オーダー情報に含まれる各種情報を関連付けするための関連付け処理を実行する。
【０３７５】
ここで行う関連付け処理は、詳しくは、撮像部１１によって取得された画像データファイル（画像データ本体と一般メタデータとが一体のＥｘｉｆ画像データファイル）に対して、医療メタデータを関連付けて一体化した一つの画像データファイルであり、医用オブジェクト（医用画像データファイル）を生成する処理である。こうして生成される医用画像データファイルは、各種の情報が整理され集められた形態の例えばＤＩＣＯＭ準拠のデータ形式の画像データファイルとして記録される。
【０３７６】
次に、ステップＳ７７において、画像処理制御部２１は、医用参照画像の画像データファイルを送信する画像送信待機モードを設定する。この画像送信待機モードとは、受信した一般オーダー情報に従って撮影された画像データファイル（医用参照画像）を送信するための送信待機モードである。第２端末２０においては、この送信待機モードを設定することで、常に送信待機状態にありながら、並行して他の所望の作業処理を実行させることができるものとしている。画像送信待機モードの設定が完了すると、次のステップＳ７８の処理に進む。
【０３７７】
なお、上記画像送信待機モードが設定される状況としては、第１端末１０又はファイルサーバー３０との間の通信を行うことができない環境にある場合などが考えられる。このような場合は、画像送信待機モードを設定しておき、通信環境が整った場所に移動した際に通信を確保し送信を行えばよい。
【０３７８】
ステップＳ７８において、画像処理制御部２１は、時計部２２を参照して所定時間経過したか否かの確認を行う。ここで、所定時間が経過した場合には、図１１のステップＳ６８の処理に進む（図１１，図１２の丸数字符号１３参照）。また、所定時間が経過しない間は、上述のステップＳ７２の処理に戻り、以降の処理を繰り返す。
【０３７９】
また、上述のステップＳ５５の処理にて、一般オーダー情報の受信が行われずにステップＳ５６の処理に進むと、このステップＳ５６において、画像処理制御部２１は、取得した医用参照画像の画像データファイルの送信処理が実行されたか否かの確認を行う。なお、ここで確認されるのは、送信処理の実行ができるか否かの確認としている。ここで、送信処理の実行が可能である場合には、次のステップＳ５７の処理に進む。
【０３８０】
そして、ステップＳ５７において、画像処理制御部２１は、動作モードを医用参照画像転送モードに切り換えた後、所定の画像送信処理を実行する。その後、図１１のステップＳ６８の処理に戻る（図１１，図１２の丸数字符号１３参照）。
【０３８１】
一方、上述のステップＳ５６の処理にて送信処理の実行ができない場合にも、図１１のステップＳ６８の処理に戻る（図１１，図１２の丸数字符号１３参照）。
【０３８２】
次に、本実施形態の医用画像管理システム１における情報端末装置のうちの第１端末１０の作用を説明する。図１３は、本実施形態の医用画像管理システムにおける情報端末装置のうち第１端末１０の作用を示すフローチャートである。
【０３８３】
本実施形態の医用画像管理システム１において、第１端末１０は、上述したように、例えば医師が使用する情報端末装置（さらに具体的には例えばタブレットＰＣ）であるものとして説明する。
【０３８４】
まず、第１端末１０の画像処理制御部２１は、まず、図１３のステップＳ１５１において、表示制御部２１ｄ等を制御して表示部１５の表示画面上に、実行可能な各種のアプリケーションソフトウエアを示す複数のアイコンを表示したりして、様々なアプリケーションを使った業務に対応可能となっている。
【０３８５】
例えば、医療施設内外の事務職員や医療従事者や関係者との電話連絡やメール、チャット連絡などが可能になっており、この端末によってスケジュール管理や患者情報の読み出しのみならず、各種情報の検索などがアイコンから選べるようになっている。このようなアプリケーションを駆使して業務記録などの作成が容易にできるようになっている。近年では、ディクテーション用のアプリケーションなどがドキュメント作成に利用されることもあるので、こうした技術にも対応している。
【０３８６】
この状態に限らず、外部機器からのアクセスを可能としていることが好ましく、これによって医師は、この端末によって急患に対応したり、他の医療従事者からの問い合わせに応えられるようになっている。ここでは、Ｓ１５１に続く形で表現しているが、Ｓ１５１の中のアプリケーションの一つに以下の待ち受けの機能があるという表現で説明するが、並列にアプリケーションが作動しているという設計でも本願の目的は達成できる。
【０３８７】
ステップＳ１５２において、画像処理制御部２１は、例えば第２端末２０からのアクセスがあるか否かの確認を行う。Ｓ１５１のアプリケーションには、このアクセス確認以外の様々な機能があるが、ここでは説明を単純化している。Ｓ１５２以下で本発明の特徴部分が説明可能なので、以下、本願での特徴となる部分について特記した形で説明する。
【０３８８】
ステップＳ１５２において、第２端末２０からのアクセスが確認されると、次のステップＳ１５３の処理に進む。また、第２端末２０からのアクセスが確認されない場合には、ステップＳ１５１の処理に戻る。
【０３８９】
なお、第１端末１０は、待機状態にある時には、第２端末２０からのアクセスが確認されない場合であっても、その他、さまざまな種類の入力指示等を受け得る。しかしながら、それら、その他の入力指示等に対応する作用については、本発明に直接関連しない部分である。したがって、ステップＳ１５２の処理においては、第２端末２０からのアクセスが確認されない場合には、その他の入力指示等に対応する作用の説明は省略し、便宜的に、ステップＳ１５１の処理に戻るようにしている。
【０３９０】
続いて、ステップＳ１５３において、画像処理制御部２１は、第２端末２０からのログイン手続き処理（図１１のステップＳ５３のログイン処理）が正規のものであるか否か、即ちログインを受諾するか否かの確認を行う。ここで、ログインを受諾する場合には、次のステップＳ１５４の処理に進む。また、ログインを受諾しない場合には、ステップＳ１５１の処理に戻る。ここで、ログインを受諾しない場合とは、ログイン手続きに含まれる情報、例えばログインＩＤやパスワードが合致しない等の場合である。
【０３９１】
ログインが受諾されてステップＳ１５４の処理に進むと、ログインに続く情報の受信を待つが、不意の通信切断や、イレギュラーな情報が来る場合もあるので、所定時間だけ待つという設計にしてもよいし、何らかの警告を出すようにしてもよいがここでは単純化して表現している。画像処理制御部２１は、リクエスト情報を受信するためのリクエスト情報受信モードに切り換わる。そして、送信されてきたリクエスト情報を受信し、当該リクエスト情報が受信されたか否かの確認を行う（図１１のステップＳ５４の処理によるリクエスト情報送信に対応する処理）。ここで、リクエスト情報が受信されるまで受信確認処理を繰り返す。そして、リクエスト情報が受信された場合には、次のステップＳ１６１の処理に進む。なお、図１３のフローチャートには示していないが、リクエスト情報が受信されないまま所定の時間が経過した場合には、当該ループを抜けて上述のステップＳ１５１の処理に戻るようにしてもよい。
【０３９２】
次に、ステップＳ１６１において、画像処理制御部２１は、一般オーダー情報作成モードへと切り換えて、使用者の入力指示を待機する。使用者は、上述のステップＳ１５４の処理にて受信されたリクエスト情報に応じて、適宜対応する一般オーダー情報を入力する。
【０３９３】
続いて、ステップＳ１６２において、画像処理制御部２１は、適宜使用者により入力される一般オーダー情報のうちの任意のコメントを入力するコメント情報入力処理を受け入れる。
【０３９４】
上述のステップＳ１６１，Ｓ１６２にて入力される一般オーダー情報は、例えば、患者を特定するための基本情報に加えて、コメントとして付する情報であって、患者家族からのリクエスト情報に応じて、医師が発する情報や、画像撮影指示情報等を含む各種の情報である。
【０３９５】
このようにして一般オーダー情報の入力処理が終了したら、次のステップＳ１６３の処理に進む。
【０３９６】
ステップＳ１６３において、画像処理制御部２１は、作成した一般オーダー情報の送信処理を実行する否かの確認を行う。ここで、一般オーダー情報の送信処理を実行する場合には、次のステップＳ１６４の処理に進む。また、一般オーダー情報の送信処理を実行しない場合、例えば、作成済みの一般オーダー情報に対する追加入力を行う等の場合には、ステップＳ１６１の処理に戻り、以降の処理を繰り返す。
【０３９７】
ステップＳ１６４において、画像処理制御部２１は、動作モードを一般オーダー情報送信モードに切り換える。そして、画像処理制御部２１の通信制御部２１ｃは、機器通信部１２又はネットワーク通信部２３を制御して、患者家族の第２端末２０又は院内システムのファイルサーバー３０にアクセスして、作成した一般オーダー情報の送信処理を実行する。その後、画像処理制御部２１は、動作モードを通常の待機状態に切り換える。
【０３９８】
なお、第１端末１０は、上述した以外にも様々な動作モードで動作し得る。しかしながら、第1端末１０におけるその他の動作モードについては、本発明に直接関連しない部分であるので、その説明は省略する。
【０３９９】
また、図１３で示すフローチャートについても、本発明の作用を説明するのに必要な部分のみを示すのに留め、本発明に直接関係しない部分については、図示及びその説明を省略する。それら、説明を省略した部分の作用については、従来一般的な情報端末装置（本実施形態ではタブレットＰＣを想定している）と同様の作用を実現し得るものとする。
【０４００】
さらに、第１端末１０においても、インストールするアプリケーションソフトウエア次第で、各種さまざまな作用を実現し得ることは、従来の同種の情報端末装置と同様である。
【０４０１】
次に、本実施形態の医用画像管理システム１におけるファイルサーバー３０の作用を説明する。図１４，図１５は、本実施形態の医用画像管理システムにおけるファイルサーバーの作用を示すフローチャートである。
【０４０２】
まず、ファイルサーバー３０は起動状態にあり、外部情報端末装置及び内部端末装置等の他の機器からのアクセスを待機する待機状態にあるものとする。
【０４０３】
ここで、外部情報端末装置とは、第１端末１０，第２端末２０等を指すものとする。なお、図１４においては、単に外部端末装置と略記している。また、内部端末装置とは、医療施設内の受付部門や診察室等に設置されているＰＣ等を指すものとする（不図示）。したがって、当該ファイルサーバー３０は、外部情報端末装置（１０，２０等）のほかに、内部端末装置からのアクセスも許容する。
【０４０４】
ファイルサーバー３０が、この状態にあるとき、図１４のステップＳ３０１において、制御部３１の通信部３５は、外部情報端末装置（１０，２０等）からのアクセスが有るか否かの確認を行う。ここで、外部情報端末装置（１０，２０等）からのアクセスが確認された場合には、次のステップＳ３０２の処理に進む。また、外部情報端末装置（１０，２０等）以外からのアクセスが確認された場合には、図１５のステップＳ３３１の処理に進む（図１４，図１５の丸数字符号１４参照）。
【０４０５】
ステップＳ３０２において、制御部３１の通信部３５は、第２端末２０からのアクセスであるか否かの確認を行う。ここで、第２端末２０からのアクセスが確認された場合には、所定のログイン処理を実行した後、次のステップＳ３０３の処理に進む。また、第２端末２０以外（即ち第１端末１０）からのアクセスが確認された場合には、所定のログイン処理を実行した後、ステップＳ３２１の処理に進む。
【０４０６】
ステップＳ３０３において、制御部３１は、第２端末２０からのリクエスト情報が受信されたか否かの確認を行う。ここで、リクエスト情報が受信されたことが確認された場合には、ステップＳ３０４の処理に進む。また、リクエスト情報が受信されない場合には、ステップＳ３１１の処理に進む。
【０４０７】
ステップＳ３０４において、制御部３１は、受信したリクエスト情報に応じて、対応する医師への確認を行う。ここで行われる処理は、例えば対応する医師の第１端末１０へ、受信したリクエスト情報を転送する処理などが相当する。そして、図示を省略しているが、このリクエスト情報を受けた医師は、自身の第１端末１０を用いて所定の操作を行うことになる。
【０４０８】
次に、ステップＳ３０５において、制御部３１は、上述のステップＳ３０４の処理にて医師から受けた指示情報に基づいて一般オーダー情報を作成する。
【０４０９】
続いて、ステップＳ３０６において、制御部３１は、上述のステップＳ３０５の処理にて作成された一般オーダー情報を、上記受信したリクエスト情報の発信元の第２端末２０へと送信するか否かの送信指示信号の確認を行う。この送信指示信号は、医師から出される指示信号である。
【０４１０】
ここで、一般オーダー情報の送信指示信号が確認された場合には、次のステップＳ３０７の処理に進む。また、一般オーダー情報の送信指示信号が確認されない場合には、ステップＳ３０８の処理に進む。
【０４１１】
ステップＳ３０７において、制御部３１は、上述のステップＳ３０５の処理にて作成された一般オーダー情報を、上記受信したリクエスト情報の発信元の第２端末２０へと送信する送信処理を実行する。その後、ステップＳ３０１の処理に戻り、以降の処理を繰り返す。即ち、ファイルサーバー３０は、外部装置からのアクセス待機状態となる。
【０４１２】
一方、上述のステップＳ３０６の処理にて一般オーダー情報の送信指示信号が確認されずに、ステップＳ３０８の処理に進むと、このステップＳ３０８において、制御部３１は、送信許可の可否を確認する。この送信許可の可否とは、例えば、上述のステップＳ３０５の処理にて作成された一般オーダー情報に含まれる許可表示１０ｂ（図２〜図３参照）へのチェックの有無などによって確認できる情報である。
【０４１３】
ここで、送信を許可する旨の情報が確認された場合は、上述のステップＳ３０４の処理に戻り、以降の処理を繰り返す。また、送信を許可する旨の情報が確認されない場合、即ち、許可しない旨の情報がある場合には、ステップＳ３０９の処理に進む。
【０４１４】
ステップＳ３０９において、制御部３１は、許可しない理由等を付した情報を、受信したリクエスト情報の発信元となる第２端末２０へと送信する。その後、ステップＳ３０１の処理に戻り、以降の処理を繰り返す。即ち、ファイルサーバー３０は、外部装置からのアクセス待機状態となる。
【０４１５】
一方、上述のステップＳ３０１の処理にて外部情報端末装置（１０，２０等）以外からのアクセスが確認されて、図１５のステップＳ３３１の処理に進むと、このステップＳ３３１において、制御部３１は、内部端末装置（不図示；例えば医療施設内の受付部門や診察室等に設置されているＰＣ等の内部端末装置（不図示））からのアクセスがあるか否かの確認を行う。ここで、内部端末装置からのアクセスが確認された場合には、次のステップＳ３３２の処理に進む。また、内部端末装置からのアクセスが確認されない場合には、ステップＳ３４１の処理に進む。
【０４１６】
ステップＳ３３２において、制御部３１は、所定のログイン手続き処理を実行する。これに応じて、内部端末装置（不図示）は所定のログイン手続き処理を行う。これにより、当該ファイルサーバー３０へのログインが完了すると（ログインＯＫの場合）、制御部３１は、内部端末装置からの要求に応じて所定の情報を内部端末装置に転送する。これを受けて、内部端末装置は表示部（不図示）に当該所定の情報を表示する。また、内部端末装置からの情報入力を受けて情報記録処理を行う（例えば電子カルテの更新入力等）。その後、ステップＳ３３３の処理に進む。
【０４１７】
なお、図示を省略しているが、内部端末装置がファイルサーバー３０にログインできない場合には、当該ファイルサーバー３０は、以降の処理をキャンセルして、上述のステップＳ３０１の処理に戻って待機状態となる。
【０４１８】
ステップＳ３３３において、制御部３１は、内部端末装置からの操作指示を受けて、情報端末装置（１０，２０）等の登録設定処理などを実行する。
【０４１９】
続いて、ステップＳ３３４において、制御部３１は、アクセス先の装置からのログアウト指示の確認を行う。ここで、ログアウト指示が確認された場合には、所定のログアウト処理の実行後、図のステップＳ３０１の処理に戻り、以降の処理を繰り返す。
【０４２０】
一方、上述のステップＳ３３１の処理にて、内部端末装置からのアクセスが確認されない場合には、ステップＳ３４１の処理に進む。この時点においては、既に、上述のステップＳ３０１の処理（図１４）にて外部端末装置からのアクセスも確認されていない。
【０４２１】
したがって、この場合には、ファイルサーバー３０は、他の機器からのアクセスを待機している待機状態にある。
【０４２２】
これと同時に、ステップＳ３４１において、ファイルサーバー３０の制御部３１は、例えば、画像データベース３２に蓄積された複数の画像データファイルと、患者情報データベース３４に記録されている複数の患者情報とに基づいて、各種さまざまな分析などを行って、その分析結果を必要に応じて医師の第１端末へと通知する等の処理を実行する。
【０４２３】
具体的には、例えば、特定の患者情報に関連付けられた複数の画像データファイルに関し、経時的な変化などによる病状の進行などについての分析等を行う。このような分析処理は、例えばＡＩ等を利用することで実現し得る。
【０４２４】
他方、上述のステップＳ３０２の処理にて、第２端末２０以外（即ち第１端末１０）からのアクセスが確認されて、ステップＳ３２１の処理に進むと、このステップＳ３２１において、制御部３１は、該当情報検索処理を実行する。この該当情報検索処理とは、医師が第１端末１０を用いて、必要とする情報、例えば担当患者（この場合はリクエスト情報の発信元の患者等）に関する電子カルテ等の患者情報を検索するために出される指示に応じる処理である。
【０４２５】
続いて、ステップＳ３２２において、制御部３１は、リクエスト情報に応じた画像撮影のための撮影条件設定等を行う。ここでの処理は、医師が第１端末１０を用いて操作入力を行って、各種の設定の指示を行う場合と、ファイルサーバー３０の制御部３１（オーダー情報作成部３１ｂ）が自動的に各種設定を行う場合とがある。
【０４２６】
次に、ステップＳ３２３において、制御部３１は、医師の第１端末１０から一般オーダー情報を作成する旨の指示があるか否かの確認を行う。ここで、医師からの一般オーダー情報の作成指示が確認された場合には、次のステップＳ３２４の処理に進む。また、医師からの一般オーダー情報の作成指示が確認されない場合には、医師がリクエスト情報に応じて一般オーダー情報を発行しないものと判断して、上述のステップＳ３０１の処理に戻って待機状態となる。
【０４２７】
一方、上述のステップＳ３２３の処理にて、医師からの一般オーダー情報の作成指示が確認されてステップＳ３２４の処理に進むと、このステップＳ３２４において、制御部３１は、医師が対応するか否かの確認を行う。この場合において、医師による対応とは、例えば医師が第１端末１０を用いてリクエスト情報に対応する一般オーダー情報を作成する際に、各項目への入力を医師自身が行う場合をいうものとする。
【０４２８】
ここで、医師が対応する旨の指示信号が確認されたら、次のステップ３２５に進み、このステップＳ３２５において、制御部３１は、第１端末１０に対して、上記作成された一般オーダー情報を送信する。その後、上述のステップＳ３０１の処理に戻って待機状態となる。
【０４２９】
一方、医師が対応する旨の指示信号が確認されない場合には、ステップ３２６に進み、このステップＳ３２６おいて、制御部３１は、第２端末２０に対して、上記作成された一般オーダー情報を送信する。その後、上述のステップＳ３０１の処理に戻って待機状態となる。
【０４３０】
また、上述のステップＳ３０３の処理にてリクエスト情報が受信されずに、ステップＳ３１１の処理に進むと、このステップＳ３１１において、制御部３１は、第２端末２０からの画像データファイルを受信したか否かを確認する。また、画像データファイルの受信を確認した場合は、その画像データファイルが所定の条件に適合しているか否かの確認を行う。ここで、第２端末２０から送られてくる画像データファイルとは、一般オーダー情報に従って撮影された画像データファイルである。また、その画像データファイルにおける所定の条件とは、一般オーダー情報に従って撮影されていること、例えば所定の画像フォーマットであり、所定の付随情報が附されている等の条件である。
【０４３１】
ここで、画像データファイルを受信したことが確認され、かつその画像データファイルが所定の条件に適合していることが確認された場合には、次のステップＳ３１２の処理に進む。また、画像データファイルを受信したことが確認されない場合、若しくは画像データファイルを受信したことが確認されても、その画像データファイルが所定の条件を満たしていないことが確認された場合には、ステップＳ３１３の処理に進む。
【０４３２】
ステップＳ３１２において、制御部３１は、医用参照画像として所定の領域（例えば画像データベース３２）に、患者情報として記録する。その際、記録される画像データファイルは、対応する特定の患者情報（電子カルテ等）との関連付けが行われる。そして、一般オーダー情報に対応する医用参照画像が記録された旨の通知を、医師の第１端末１０へと送信する。その後、上述のステップＳ３０１の処理に戻って待機状態となる。
【０４３３】
一方、ステップＳ３１３において、制御部３１は、条件未達理由等を当該画像データファイルを送信してきた第２端末２０へ通知する。ここで、条件未達理由とは、上述のステップＳ３１１の処理における確認のうち、受信した画像データファイルが、医用参照画像として採用できない理由、即ち満たしていない所定の条件等である。その後、ステップＳ３０１の処理に戻って待機状態となる。
【０４３４】
以上説明したように上記一実施形態によれば、通信機能及び撮像機能を有し受信したリクエスト情報に応じた特定用途情報（一般オーダー情報）を送信する第１の情報端末装置（第１端末１０）と、少なくとも通信機能を有し入力されたリクエスト情報を送信する第２の情報端末装置（第２端末２０）とを具備し、上記第２の情報端末装置は、取得された画像データファイルを記録する際に、当該画像データファイルに対して上記第１の情報端末装置から受信した上記特定用途情報を関連付けて記録することによって、患者情報を共有して医療業務を支援する医用画像管理システム１を構成している。
【０４３５】
この医用画像管理システム１においては、患者家族等の非医療従事者が第２の情報端末装置（第２端末２０）を用いて所定のリクエスト情報を医師の持つ第１の情報端末装置（第１端末１０）若しくはファイルサーバー３０に送信すると、これを受けて、医師は第１情報端末装置（第１端末１０）を用いて受信したリクエスト情報に応じて所定の操作をする。これにより、第１の情報端末装置（第１端末１０）若しくはファイルサーバー３０において特定用途情報（一般オーダー情報）が作成される。
【０４３６】
こうして作成された特定用途情報（一般オーダー情報）は、第２の情報端末装置（第２端末２０）へと送信される。これを受けて、患者家族等の非医療従事者が第２の情報端末装置（第２端末２０）を用いて画像撮影を行って対象患者の画像データファイルを取得する。ここで、第２の情報端末装置（第２端末２０）は、取得した画像データファイルに第１の情報端末装置（第１端末１０）若しくはファイルサーバー３０から受信した特定用途情報（一般オーダー情報）を関連付けて記録する。
【０４３７】
つまり、第２端末２０は、取得した画像データファイル（画像データ本体と一般メタデータとが一体のＥｘｉｆ画像データファイル）に対して、一般オーダー情報に含まれる医療関連情報に基く医療メタデータを関連付けて一体化した一つの医用オブジェクト（医用画像データファイル）を生成する。これにより、取得された画像データファイルは、医用参照画像として承認され得る状態になると共に、例えばＤＩＣＯＭ規格に準拠したデータ形式の画像データファイルとなる。
【０４３８】
なお、取得画像データファイル（Ｅｘｉｆファイル）と医療メタデータとの関連付け処理は、第２端末２０で行う構成のほかに、例えばファイルサーバー３０において行う構成であってもよいことは、上述した通りである。
【０４３９】
このように、患者家族のリクエスト情報に応じて医師が出す特定用途情報としての一般オーダー情報（医療行為的な複数の指示等からなるオーダー情報に準拠する情報群）に画像撮影指示等を含む情報が含まれている場合に、この一般オーダー情報を受信した第２端末２０を用いて画像撮影を行うと、取得した画像データファイル（Ｅｘｉｆファイル）には、一般オーダー情報に含まれる各種の情報が医療メタデータとして関連付けられて、ＤＩＣＯＭ準拠のデータ形式の医用画像データファイルとして記録される。
【０４４０】
こうして作成された医用画像データファイルは、ファイルサーバー３０等へと転送されることにより、信頼性のある医用参照画像として共有される。
【０４４１】
したがって、これにより、遠隔地にある患者家族等は、所定のリクエスト情報を医師へ送信し、特定用途情報（一般オーダー情報）を受信すれば、この特定用途情報（一般オーダー情報）を受信した第２端末２０を用いて対象患者を撮影するのみで、高い撮影技術や所定の撮影知識等を有しておらずとも、容易にかつ確実に医師の指示（一般オーダー情報）に応じた患者画像を取得することができると同時に、画像データファイルに医療メタデータを付した形態の医用参照画像を取得することができる。
【０４４２】
本実施形態の医用画像管理システム１は、医療従事者が取得した患者情報としての画像情報のみならず、医療従事者以外の一般の人物（非医療従事者）が取得した画像情報をも患者情報としての医用画像若しくは医用参照画像として取り扱うことができ、医療行為の利便性を向上させることができる。
【０４４３】
この場合において、画像撮影時から画像データファイルに一般オーダー情報に含まれる医療用の基本情報等を含む医療メタデータとして関連付けた形態のＤＩＣＯＭ準拠のデータ形式の画像データファイルを作ることができるので、画像データファイルの取り違え等を防ぐことができると同時に、情報の信頼性を向上させることができ、かつ貴重な画像情報の管理が容易になる。
【０４４４】
また、第２の情報端末装置（第２端末２０）は、取得した画像データファイルに対して、一般オーダー情報に含まれる医療用の基本情報等を含む医療メタデータ（付随情報）として関連付けた形態の画像データファイルを作成するようにしたので、例えば、当該画像データファイルが他のデバイスへと転送された場合にも、付随情報を参照するのみで、どのような画像データファイルであるかを容易に判別することができる。例えば、一般オーダー情報に含まれる固有番号（オーダー番号等と呼称される番号）は、患者ＩＤや検査ＩＤ等に関連付けされていることから、患者の特定を容易にすると同時に、一連の検査スタディや特定の疾患／疾病の検査との関連付けが可能となる。
【０４４５】
なお、上述の一実施形態においては、情報端末装置（１０，２０）の一形態として、撮像機能と通信機能とを備えた一般的な携帯の撮像装置（カメラ）や、スマートフォン，タブレット型ＰＣ等を例に挙げて説明したが、本発明に適用し得る情報端末装置の形態としては、これらの形態に限られるものではない。
【０４４６】
例えば、近年においては、所定の場所（例えば対象患者の自宅や病院等の病室等）にカメラを据え付けて、当該カメラをネットワーク経由で遠隔操作し、所定の時間間隔毎の撮影画像を取得し、取得した撮影画像をネットワーク経由で他の機器（ファイルサーバーなど）へと転送することで、撮影する対象患者等の状況を、遠隔地から常時見守る（監視する）ことができるようにしたカメラシステム（いわゆる見守り（監視）カメラ，ウェッブカメラ等と呼称されるネットワークカメラシステム）が実用化され一般に普及しつつある。
【０４４７】
この種のネットワークカメラシステムに含まれるカメラを、本発明の情報端末装置として適用することもできる。
【０４４８】
また、上述の一実施形態においては、医療分野で利用されるシステムを例示しているが、この例に限られることはなく、医療分野以外の他の分野、例えば映像分野や科学研究分野等においても、本発明を適用することは容易に可能である。
【０４４９】
即ち、各種の分野における専門従事者の作成した特定用途情報を含む付随情報を、所定の手続きを経て、一般者が取得した画像データファイルに関連付けることのできるシステムを構築することは、上記一実施形態と同様に可能である。
【０４５０】
その場合において、専門従事者の作成した特定用途情報を含む付随情報を付して得られた画像データファイルを所定のファイルサーバーに記録してデータベース化すれば、個々の画像データファイルの信頼性を確保することができ、各分野における画像データベースの信頼性の向上に寄与することができる。
【０４５１】
なお、上述の一実施形態で説明した各処理シーケンスは、その性質に反しない限り、手順の変更を許容し得る。したがって、上述の処理シーケンスに対して、例えば各処理ステップの実行順序を変更したり、複数の処理ステップを同時に実行させたり、一連の処理シーケンスを実行する毎に、各処理ステップの順序が異なるようにしてもよい。即ち、特許請求の範囲，明細書及び図面中の動作フローに関して、便宜上「まず、」、「次に、」等を用いて説明したとしても、この順で実施することが必須であることを意味するものではない。また、これらの動作フローを構成する各ステップにおいては、発明の本質に影響しない部分について適宜省略することもできることは言うまでもない。
【０４５２】
また、ここで説明した技術のうち、主にフローチャートで説明した制御や機能は、多くがソフトウエアプログラムにより設定できることが多くあり、そのソフトウエアプログラムをコンピュータが読み取り実行することで上述した制御や機能を実現することができる。そのソフトウエアプログラムは、コンピュータプログラム製品として、予め製品製造過程において上記記憶媒体や記憶部等、具体的には例えばフレキシブルディスク ＣＤ−ＲＯＭ等 不揮発性メモリ等の可搬媒体やハードディスク 揮発性メモリ等の記憶媒体に、その全体あるいは一部を記憶又は記録されている電子データである。また、これとは別に、製品出荷時又は可搬媒体或いは通信回線を介して流通又は提供ができるものである。利用者は、製品出荷後であっても、自ら通信ネットワークやインターネット等を介して、それらのソフトウエアプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記憶媒体からコンピュータにインストールすることで、動作させるようにすることができ、これによって容易に本実施形態の医用画像管理システム及び情報端末装置を実現することができる。
【０４５３】
また、プログラムで構成した部分を適宜、回路に置き換えることも可能である。上述の一実施形態の説明中において、「部」（セクションやユニット）として記載した部分は、専用の回路や、複数の汎用の回路を組み合わせて構成してもよく、必要に応じて、予めプログラムされたソフトウェアに従って動作を行うマイコン、ＣＰＵなどのプロセッサ、あるいはＦＰＧＡなどシーケンサを組み合わせて構成されてもよい。また、その制御の一部または全部を外部の装置が引き受けるような設計も可能で、この場合、有線や無線の通信回路が介在する。通信は、ブルートゥース（登録商標）やＷｉＦｉ（登録商標）、電話回線などで行えばよく、ＵＳＢなどで行っても良い。専用の回路、汎用の回路や制御部を一体としてＡＳＩＣとして構成してもよい。機械的に位置制御される部位（例えば移動部など）は、様々なアクチュエータと、必要に応じて移動用の連結メカニズムによって構成されており、ドライバ回路によってアクチュエータが作動する。このドライブ回路もまた、特定のプログラムに従ってマイコンやＡＳＩＣなどが制御する。こうした制御は各種センサやその周辺回路が出力する情報によって、詳細な補正、調整などが行われても良い。
【０４５４】
本発明は上述した一実施形態に限定されるものではなく、発明の主旨を逸脱しない範囲内において種々の変形や応用を実施することができることは勿論である。さらに、上記一実施形態には、種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせによって、種々の発明が抽出され得る。例えば、上記一実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題が解決でき、発明の効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。この発明は、添付のクレームによって限定される以外にはそれの特定の実施態様によって制約されない。
【符号の説明】
【０４５５】
１……医用画像管理システム
１０……第１の情報端末装置
１１……撮像部
１２……機器通信部
１３……操作部
１４……タッチパネル
１５……表示部
１６……記録部
１７……確認センサ
１８……リクエスト情報／オーダー情報作成部
２０……第２の情報端末装置
２１……画像処理制御部
２１ａ……撮像制御部
２１ｂ……操作判定部
２１ｃ……通信制御部
２１ｄ……表示制御部
２１ｅ……記録制御部
２１ｅａ……一般オーダー情報関連付け部
２１ｆ……画像判定部
２１ｇ……確認部
２１ｈ……音声判定部
２２……時計部
２３……ネットワーク通信部
２４……集音部
２５……メモリ
３０……ファイルサーバー
３１……制御部
３１ａ……患者判定部
３１ｂ……オーダー情報作成部
３１ｃ……撮影条件情報作成部
３１ｄ……オブジェクト情報生成部
３２……画像データベース
３３……オーダー情報等データベース
３４……患者情報データベース
３５……通信部
４０……ネットワーク
【図１】
2020034999.tif 000003
【図２】
2020034999.tif 000004
【図３】
2020034999.tif 000005
【図４】
2020034999.tif 000006
【図５】
2020034999.tif 000007
【図６】
2020034999.tif 000008
【図７】
2020034999.tif 000009
【図８】
2020034999.tif 000010
【図９】
2020034999.tif 000011
【図１０】
2020034999.tif 000012
【図１１】
2020034999.tif 000013
【図１２】
2020034999.tif 000014
【図１３】
2020034999.tif 000015
【図１４】
2020034999.tif 000016
【図１５】
2020034999.tif 000017