JP7440695B1 - 遠隔画像診断総合支援装置、遠隔画像診断総合支援方法及びプログラム - Google Patents

Abstract

【課題】情報の秘匿性を保ちつつ、より多くの医師が読影医として医療に参加できる遠隔画像診断総合支援装置、方法及びプログラムを提供する。【解決手段】遠隔画像診断総合支援システム１において、サービス提供サイトを構成する各種サーバの１又は２以上である医用画像の読影を外部に依頼する遠隔画像診断総合支援装置は、依頼者から読影の依頼を受け付け、依頼者による決済を実行して読影レポートをアップロードした受注者への振込を実行し、秘匿性の高い情報をセキュアに格納するための格納領域を作成し、そのアクセス権を依頼者へ付与して格納領域のアドレスを通知するとともに、格納領域へのアクセス権を受注者へ付与して格納領域のアドレスを受注者へ通知し、依頼者がアップロードした依頼情報を格納領域へ格納し、依頼情報を受注者へダウンロードするとともに、アップロードした読影レポートを格納領域へ格納し、読影レポートをダウンロードする。【選択図】図１

Description

本開示は、遠隔画像診断総合支援装置、遠隔画像診断総合支援方法及びプログラムに関する。

従来、レントゲン技術の発達、ＣＴ（Computed Tomography）やＭＲＩ（Magnetic Resonance Imaging）やＰＥＴ（Positron Emission Tomography）などの技術の進歩や普及等に伴い、それらの医療用検査装置で撮影された画像（以下、医用画像）に基づいて患者を臨床診断する医師（以下、臨床医ともいう）にかかる負担が増加している。

そのような状況に鑑み、近年では、臨床医が自己の負担を軽減し、且つ、より正確な診断を行うことを目的として、医用画像の読影を専門の医師（以下、読影医ともいう）に依頼するケースが増えてきている。

通常、患者を直接診断する臨床医やこの臨床医が所属する医療機関等（以下、これらをまとめて依頼者ともいう）から読影医や読影専門会社等（以下、これらをまとめて受注者ともいう）へ読影を依頼する場合、年齢や性別や既往歴などの患者の個人情報が医用画像とともに受注者へ提供される。そのため、従来では、情報の秘匿性を考慮して、依頼者と受注者との間を専用回線で接続し、この専用回線を介して情報の受け渡しが行われていた。

特開２０２３－１０２１５５号公報 特開２０２３－１１４２４２号公報

しかしながら、依頼者と受注者とを専用回線で接続する従来のシステムでは、これから読影医として開業等をしようとする医師などにとって導入時の費用や導入後の維持費などの費用、導入後の作業の容易性などの面におけるハードルが高く、せっかく読影のためのスキルを持っていたとしても、多くの医師が積極的に読影医として医療に参加するというまでには至っていなかった。

また、読影専門会社が窓口となって受注する場合では、読影専門会社において、各読影医への読影システムの頒布、各読影医への仕事の割り振り、依頼者に対する請求及び入金の確認、各読影医への給与の計算及び支払いなど、数多くの手間や中間コストが発生する。そのため、新規参入することに対するハードルが高く、より多くの医師が読影医として参加するための環境を整えることが難しかった。

そこで本開示は、上記問題に鑑み成されたものであり、情報の秘匿性を保ちつつ、より多くの医師が読影医として医療に参加することを可能にする遠隔画像診断総合支援装置、遠隔画像診断総合支援方法及びプログラムを提供することを目的とする。

本開示の一実施形態に係る遠隔画像診断総合支援装置は、所定のネットワークを介して外部に医用画像の読影を依頼する遠隔画像診断総合支援装置であって、依頼者から読影の依頼を受け付ける依頼受付部と、前記依頼に対して前記依頼者による決済を実行するとともに、前記依頼に対する成果物である読影レポートをアップロードした受注者への振込を実行する決済処理部と、前記医用画像を含む秘匿性の高い依頼情報をセキュアに格納するための格納領域を前記所定のネットワーク上に作成する格納領域作成部と、前記格納領域へのアクセス権を前記依頼者へ付与し、前記格納領域へアクセスするためのアドレスを当該依頼者へ通知するとともに、前記格納領域へのアクセス権を前記依頼を受注した前記受注者へ付与し、前記格納領域へアクセスするための前記アドレスを当該受注者へ通知するアクセス権付与部と、前記依頼者がアップロードした前記依頼情報を前記格納領域へ格納し、前記格納領域内の前記依頼情報を前記受注者からの要求に応じて当該受注者へダウンロードするとともに、前記受注者がアップロードした前記医用画像に関する前記読影レポートを前記格納領域へ格納し、前記格納領域内の前記読影レポートを前記依頼者からの要求に応じて当該依頼者へダウンロードする格納情報管理部とを備える。

本開示の一実施形態に係る遠隔画像診断総合支援方法は、所定のネットワークを介して外部に医用画像の読影を依頼する遠隔画像診断総合支援方法であって、依頼者から読影の依頼を受け付け、前記依頼に対して前記依頼者による決済を実行し、前記医用画像を含む秘匿性の高い依頼情報をセキュアに格納するための格納領域を前記所定のネットワーク上に作成し、前記格納領域へのアクセス権を前記依頼者へ付与し、前記格納領域へアクセスするためのアドレスを前記依頼者へ通知し、前記依頼者がアップロードした前記依頼情報を前記格納領域へ格納し、前記格納領域へのアクセス権を前記依頼を受注した受注者へ付与し、前記格納領域へアクセスするための前記アドレスを前記受注者へ通知し、前記格納領域内の前記依頼情報を前記受注者からの要求に応じて当該受注者へダウンロードし、前記受注者がアップロードした前記医用画像に関する読影レポートを前記格納領域へ格納し、前記読影レポートをアップロードした前記受注者への振込を実行し、前記格納領域内の前記読影レポートを前記依頼者からの要求に応じて当該依頼者へダウンロードすることを含む。

本開示の一実施形態に係るプログラムは、所定のネットワークを介して外部に医用画像の読影を依頼するプロセッサを機能させるためのプログラムであって、依頼者から読影の依頼を受け付ける処理と、前記依頼に対して前記依頼者による決済を実行する処理と、前記医用画像を含む秘匿性の高い依頼情報をセキュアに格納するための格納領域を前記所定のネットワーク上に作成する処理と、前記格納領域へのアクセス権を前記依頼者へ付与する処理と、前記格納領域へアクセスするためのアドレスを前記依頼者へ通知する処理と、前記依頼者がアップロードした前記依頼情報を前記格納領域へ格納する処理と、前記格納領域へのアクセス権を前記依頼を受注した受注者へ付与する処理と、前記格納領域へアクセスするための前記アドレスを前記受注者へ通知する処理と、前記格納領域内の前記依頼情報を前記受注者からの要求に応じて当該受注者へダウンロードする処理と、前記受注者がアップロードした前記医用画像に関する読影レポートを前記格納領域へ格納する処理と、前記読影レポートをアップロードした前記受注者への振込を実行する処理と、前記格納領域内の前記読影レポートを前記依頼者からの要求に応じて当該依頼者へダウンロードする処理とを前記プロセッサに実行させる。

本開示の第１の実施形態に係る遠隔画像診断総合支援サービスを実現するための遠隔画像診断総合支援システムの概略構成例を示す模式図である。 本開示の第１の実施形態に係る受注管理サーバの概略構成例を示す機能ブロック図である。 本開示の第１の実施形態に係る依頼管理テーブルの一例を示す図である。 本開示の第１の実施形態に係る情報格納サーバの概略構成例を示す機能ブロック図である。 本開示の第１の実施形態に係る決済サーバの概略構成例を示す機能ブロック図である。 本開示の第１の実施形態に係るユーザ管理サーバの概略構成例を示す機能ブロック図である。 本開示の第１の実施形態に係る依頼者ＤＢにおいて管理される項目の例を示す図である。 本開示の第１の実施形態に係る受注者ＤＢにおいて管理される項目の例を示す図である。 本開示の第１の実施形態に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である（その１）。 本開示の第１の実施形態に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である（その２）。 本開示の第１の実施形態に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である（その３）。 本開示の第１の実施形態に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である（その４）。 本開示の第１の実施形態に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である（その５）。 本開示の第１の実施形態に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である（その６）。 本開示の第１の実施形態に係る依頼プラン選択画面の一例を示す図である。 本開示の第１の実施形態に係るログイン画面の一例を示す図である。 本開示の第１の実施形態に係る依頼者新規登録画面の一例を示す図である。 本開示の第１の実施形態に係る診断目的の場合の読影依頼登録画面の一例を示す図である。 本開示の第１の実施形態に係る研究目的の場合の読影依頼登録画面の一例を示す図である。 本開示の第１の実施形態に係る検証目的の場合の読影依頼登録画面の一例を示す図である。 本開示の第１の実施形態に係る依頼情報の例を示す図である（その１）。 本開示の第１の実施形態に係る依頼情報の例を示す図である（その２）。 本開示の第１の実施形態に係る登録情報管理画面の一例を示す図である。 本開示の第１の実施形態に係る依頼概要確認画面の一例を示す図である。 本開示の第１の実施形態に係る読影レポートの一例を示す図である（その１）。 本開示の第１の実施形態に係る読影レポートの一例を示す図である（その２）。 本開示の第１の実施形態に係る読影レポートの一例を示す図である（その３）。 本開示の第１の実施形態に係る読影レポートの他の一例を示す図である（その１）。 本開示の第１の実施形態に係る読影レポートの他の一例を示す図である（その２）。 本開示の第１の実施形態に係る読影レポートの他の一例を示す図である（その３）。 本開示の第１の実施形態に係る読影レポートの他の一例を示す図である（その４）。 本開示の第１の実施形態に係る読影レポートの他の一例を示す図である（その５）。 本開示の第１の実施形態に係る読影レポートの他の一例を示す図である（その６）。 本開示の第２の実施形態に係る遠隔画像診断総合支援サービスを実現するための遠隔画像診断総合支援システムの概略構成例を示す模式図である。 本開示の第２の実施形態に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である。 本開示の第２の実施形態の変形例に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である。 本開示の第３の実施形態に係る依頼支援サービスを実現するための依頼支援システムの概略構成例を示す図である。 本開示の各実施形態に係る各情報処理装置の概略構成例を示すブロック図である。

以下、本開示に係る遠隔画像診断総合支援装置、遠隔画像診断総合支援方法及びプログラムについて、いくつかの実施形態を例示して詳細に説明する。

＜第１の実施形態＞
まず、本開示の第１の実施形態について、図面を参照して詳細に説明する。本実施形態では、臨床医（ただし、病理医や内科医や外科医などの他の医師が含まれてもよい）や医療機関など（以下、依頼者ともいう）が遠隔画像診断支援サービスを提供する読影医や会社（以下、受注者ともいう）へ読影を依頼することを支援する遠隔画像診断総合支援システムについて、例を挙げて説明する。

なお、依頼者と受注者との間には、読影を依頼・受注する上での所定の契約が存在していてもよいし、存在していなくてもよい。例えば、臨床医や医療機関などの依頼者は、所定の契約を交わしていない不特定の読影医若しくは読影専門会社に、又は、所定の契約を交わしている特定の読影医若しくは読影専門会社に、１件ごとに読影を依頼してもよいし、定期的（例えば、１週間に一度など）にまとまった件数の読影を依頼してもよい。すなわち、本実施形態は、依頼者と受注者との間で交わされた契約の内容に関係なく、依頼者と受注者との間を仲介するシステムに対して適用することが可能である。

また、医用画像の読影の目的としては、患者に対する診断目的、研究機関における研究目的、医療トラブルが生じた際や司法解剖などにおいて証拠を検証するための検証目的などが存在するが、本実施形態では、説明の簡略化のため、、患者に対する診断目的の場合を例に挙げる。

本実施形態では、１の受注者に対して１又は複数の依頼者が医用画像の読影を依頼する場合が例示される。以下では、明確化のため、受注者が個人の読影医である場合を例示する。また、依頼者は、患者に対して直接的に診断を行う個人の医師又はその補助スタッフであってもよいし、医師等が所属する病院や研究所などの医療機関であってもよい。以下では、明確化のため、受注者が医療機関である場合を例示する。

ここで、「医用画像」とは、レントゲン画像（エックス線画像）、ＣＴ画像、ＰＥＴ－ＣＴ画像、ＭＲＩ画像、エコー画像、内視鏡画像、心電図、病理画像など、医療用検査装置で取得される種々の画像データ又は映像データであってよい。ただし、これに限定されず、本実施形態に係る医用画像には、医師が診断に利用する種々の画像データ及び映像データが含まれてよい。また、医用画像のデータ形式として、以下の実施形態ではＤＩＣＯＭ（Digital Imaging and Communication in Medicine）形式を例示する。ただし、これに限定されず、ＪＰＥＧ、ＴＩＦＦ、ＧＩＦ、ＢＭＰ、ＭＰ４など、静止画や動画などの種々のデータ形式であってよい。

（システム構成）
まず、本実施形態に係る遠隔画像診断総合支援システムの概略構成例について、図面を参照して詳細に説明する。

・遠隔画像診断総合支援システム１
図１は、本実施形態に係る遠隔画像診断総合支援サービスを実現するための遠隔画像診断総合支援システムの概略構成例を示す模式図である。図１に示すように、遠隔画像診断総合支援システム１は、サービス提供サイト１００を構成する各種サーバ１１０、１２０、１３０及び１４０と、医療機関２００に設置された依頼者クライアント２１０と、読影医３００が所有する受注者クライアント３１０とが、ネットワーク４００を介して相互に通信可能に接続された構成を備える。ここで、サービス提供サイト１００を構成する各種サーバ１１０、１２０、１３０及び１４０のうちの１又は２以上は、本実施形態に係る遠隔画像診断総合支援装置を構成してよい。また、ネットワーク４００は、インターネットや移動体通信システムなどの広域のネットワークであってもよいし、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）などの制限されたネットワークであってもよいし、これらが組み合わされたネットワークであってもよい。

・・医療機関２００及び依頼者クライアント２１０
依頼者クライアント２１０は、例えば、病院や研究所などの医療機関２００に導入されたディスクトップ型やノート型やタブレット型などの種々のパーソナルコンピュータ（以下、単にＰＣともいう）であってよい。依頼者クライアント２１０は、例えば、医療機関２００内に構築されたＬＡＮを介してネットワーク４００に接続するための通信機能と、サービス提供サイト１００などがネットワーク４００上に公開するウェブページを閲覧するためのウェブブラウザ機能とを有している。医療機関２００に所属する医師やその補助スタッフは、依頼者クライアント２１０からサービス提供サイト１００にアクセスすることで、医用画像に対する読影を外部（例えば、遠隔地に存在する読影医３００）に依頼するとともに、依頼先の読影医３００により作成された読影レポートを取得する。なお、医用画像は、医療機関２００内に設置された医療用検査装置で取得された医用画像であってもよいし、外部の医療機関や研究所などに設置された医療検査装置で取得された医用画像であってもよい。

・・読影医３００及び受注者クライアント３１０
受注者クライアント３１０は、例えば、読影医３００の職場や自宅など（以下、仕事場という）に導入されたディスクトップ型やノート型やタブレット型などの種々のＰＣであってよい。受注者クライアント３１０は、例えば、仕事場内に構築されたＬＡＮを介してネットワーク４００に接続するための通信機能と、サービス提供サイト１００などがネットワーク４００上に公開するウェブページを閲覧するためのウェブブラウザ機能とを有している。読影医３００は、受注者クライアント３１０からサービス提供サイト１００にアクセスすることで、サービス提供サイト１００に登録された依頼を受注して、読影対象の医用画像を取得する。そして、読影医３００は、取得した医用画像を読影し、その結果として作成した読影レポートをサービス提供サイト１００に格納する。

・・サービス提供サイト１００
サービス提供サイト１００は、例えば、受注管理サーバ１１０と、情報格納サーバ１２０と、決済サーバ１３０と、ユーザ管理サーバ１４０とから構成され得る。なお、サービス提供サイト１００は、図１に示すように、複数のサーバ（クラウドサーバを含む）で構成されてもよいし、単一若しくはサーバ１１０、１２０、１３０及び１４０のうちの少なくとも２つが統合された２以上のサーバで構成されていてもよい。また、サービス提供サイト１００は、本実施形態に係る遠隔画像診断総合支援サービスの提供を目的に構築された専用のＥＣサイト（自社ＥＣサイトともいう）であってもよいし、不特定の利用者が様々な目的で利用可能なモール型のＥＣサイトであってもよい。このようなサービス提供サイト１００には、例えばＳｈｏｐｉｆｙ（登録商標）など、既存のＥＣ（Electronic Commerce）サイトが利用されてもよい。その場合、発注／受注のサービスだけでなく決済サービスも提供するＥＣサイトを利用することで、依頼者及び受注者に要求される手間を簡素化することが可能となる。

・・・受注管理サーバ１１０
図２は、本実施形態に係る受注管理サーバの概略構成例を示す機能ブロック図である。図２に示すように、受注管理サーバ１１０は、依頼受付部１１１と、依頼管理部１１２と、決済処理要求部１１３と、格納領域作成要求部１１４と、情報格納通知部１１５とを備え、依頼者である医療機関２００からの読影の依頼と、読影医３００による依頼の受注とを、後述する依頼管理テーブル１１６を用いて管理する。

依頼受付部１１１は、依頼者（本例では医療機関２００）からの依頼を受け付ける。

依頼管理部１１２は、依頼受付部１１１で受け付けられた依頼を依頼管理テーブル１１６に登録して管理する。

決済処理要求部１１３は、各依頼に対し、依頼者による支払い処理（決済）の実行と、受注者への振込処理の実行とを、後述する決済サーバ１３０へ要求する。

格納領域作成要求部１１４は、依頼者からの依頼を受け付けた際に、情報格納サーバ１２０に専用の格納領域の作成を要求する。

情報格納通知部１１５は、情報格納サーバ１２０に確保された格納領域（図４の格納領域１２５参照）へ情報が格納された際に、このことを依頼者及び／又は受注者へ通知する。

図３は、本実施形態に係る依頼管理テーブルの一例を示す図である。図３に示すように、依頼管理テーブル１１６では、例えば、依頼ＩＤ、依頼者ＩＤ、依頼基礎情報、受注者ＩＤが対応付けて管理される。

依頼ＩＤは、依頼を一意に識別するための識別情報であり、依頼者（本例では医療機関２００）より依頼が登録された際に受注管理サーバ１１０によって都度付与された値あってもよい。

依頼者ＩＤは、依頼者を一意に識別するための識別情報であってよい。この依頼者ＩＤは、後述するユーザ管理サーバ１４０が依頼者（本例では医療機関２００）を依頼者データベース（ＤＢ）に新規登録（事前登録を含む）する際に依頼者に対して付与した値であってもよい。なお、この依頼者ＩＤは、依頼者が後述する格納領域（図４の格納領域１２５及び図２３に示す登録情報管理画面参照）にアクセスするにアクセス用のＩＤ（ログインＩＤともいう）として使用される値であってもよい。

依頼基礎情報は、後述において説明するが、依頼者である医療機関２００の名称（個人の医師である場合は氏名）、読影対象である医用画像を診断する診療科（言い換えれば、患者が受診している診療科）、依頼医、患者年齢、患者性別、モダリティ、依頼日時などの情報を含んでよい。このほかにも、依頼基礎情報には、患者名、患者ＩＤ、患者生年月日、臨床経過、及び、特に読影してほしいポイントなどが含まれてもよい。ただし、少なくとも患者名、患者ＩＤ、患者生年月日、臨床経過、及び、特に読影してほしいポイントは、患者の個人情報に相当し得る情報であるため、暗号化されて依頼管理テーブル１１６に登録されてもよい。その場合、暗号化の対象には、医療機関２００の名称（個人の医師である場合は氏名）、読影対象である医用画像を診断する診療科（言い換えれば、患者が受診している診療科）、依頼医、患者年齢、患者性別、モダリティ、依頼日時、依頼ＩＤ、依頼者ＩＤ、受注者ＩＤのうちの少なくとも１つが含まれてもよい。

受注者ＩＤは、受注者を一意に識別するための識別情報であってよい。この依頼者ＩＤは、後述するユーザ管理サーバ１４０が受注者（本例では読影医３００）を受注者ＤＢに新規登録（事前登録を含む）する際に受注者に対して付与した値であってもよい。なお、受注者ＩＤは、受注者が未定である場合は空欄（Ｎｕｌｌ）であってよい。また、依頼者ＩＤは、受注者が後述する格納領域（図２３に示す登録情報管理画面）にアクセスするにアクセス用のＩＤ（ログインＩＤともいう）として使用される値であってもよい。

・・・情報格納サーバ１２０
図４は、本実施形態に係る情報格納サーバの概略構成例を示す機能ブロック図である。図４に示すように、情報格納サーバ１２０は、格納領域作成部１２１と、アクセス権付与部１２２と、格納情報管理部１２３と、記憶部１２４とを備え、依頼者から登録された読影対象の医用画像や、医用画像の読影結果として受注者により登録された読影レポートなどの各種データを格納する。

格納領域作成部１２１は、受注管理サーバ１１０から格納領域の作成を受け付けると、依頼ごとに依頼ＩＤに対応付けられた専用の格納領域（データボックス又はＢＯＸともいう）１２５を記憶部１２４に作成する。

アクセス権付与部１２２は、依頼ＩＤに対応付けられた格納領域１２５へのアクセス権を、当該依頼をした依頼者（本例では医療機関２００）及び当該依頼を受注した受注者（本例では読影医３００）へ付与する。

格納情報管理部１２３は、依頼者（本例では医療機関２００）からアップロードされた医用画像などの各種データ、及び、受注者（本例では読影医３００）からアップロードされた読影レポートなどの各種データの格納領域１２５への格納、並びに、受注者から要求された医療画像などの各種データ、及び、依頼者から要求された読影レポートなどの各種データの格納領域１２５からの読出し及びダウンロードを管理・実行する。

このような情報格納サーバ１２０は、例えば、クラウドストレージなど、情報をセキュアに格納することが可能なサーバであってよく、この情報格納サーバ１２０には、既存のクラウドサービスなどが利用されてもよい。

・・・決済サーバ１３０
図５は、本実施形態に係る決済サーバの概略構成例を示す機能ブロック図である。図５に示すように、決済サーバ１３０は、情報取得部１３１と、決済処理部１３２と、領収書発行部１３３とを備え、依頼者による支払いや、受注者への払い込みなどの決済処理を管理・実行する。また、領収書発行部１３３は、依頼者による決済が完了した際に、依頼者又は依頼者が所属する医療機関（本例では医療機関２００）に対して領収書を発行する。この決済サーバ１３０には、既存の決済サイトが利用されてもよい。

・・・ユーザ管理サーバ１４０
図６は、本実施形態に係るユーザ管理サーバの概略構成例を示す機能ブロック図である。図６に示すように、ユーザ管理サーバ１４０は、ユーザ管理部１４１と、依頼者ＤＢ１４２と、受注者ＤＢ１４３と、ユーザ認証部１４４とを備え、依頼者に関する情報や受注者に関する情報の管理、及び、依頼者及び／又は受注者の本システムへのログイン認証を実行する。

例えば、ユーザ管理サーバ１４０は、図７に例示するような依頼者ＤＢ１４２を用いて依頼者に関する情報を管理するとともに、図８に例示するような受注者ＤＢ１４３を用いて受注者に関する情報を管理する。ユーザ管理部１４１は、依頼者ＤＢ１４２への依頼者に関する情報の登録・更新・削除、及び、受注者ＤＢ１４３への受注者に関する情報の登録・更新・削除や、受注管理サーバ１１０や決済サーバ１３０等からの要求に応じて必要な情報の通知などの処理を行う。

また、ユーザ認証部１４４は、例えば、受注管理サーバ１１０からの要求に応じ、依頼者ＤＢ１４２又は受注者ＤＢ１４３に登録された情報を用いて、本システムへのアクセスを試みたユーザ（依頼者及び／又は受注者）の認証を実行する。

なお、読影の依頼主となり得る依頼者に関する情報は、予めユーザ管理サーバ１４０に登録されてもよい。依頼者に関する情報をあらかじめ登録しておくことで、言い換えれば、依頼者となり得る個人又は医療機関等を登録制とすることで、依頼主の身元保証が可能になるだけでなく、決済（支払い）時の手間軽減などのメリットを得ることも可能となる。

同様に、受注者に関する情報が予めユーザ管理サーバ１４０に登録されてもよい。受注者に関する情報をあらかじめ登録しておくことで、言い換えれば、受注者となり得る者を登録制とすることで、受注者の身元保証が可能になるだけでなく、決済（振込）時の手間軽減などのメリットを得ることも可能となる。

・・・・依頼者データベース（ＤＢ）
図７は、本実施形態に係るユーザ管理サーバで管理される依頼者ＤＢの一例を示す図である。図７に示すように、依頼者ＤＢ１４２では、登録された各依頼者に関し、依頼者ＩＤ、パスワード、医療機関、診療科、依頼医の氏名、連絡先、支払い情報、依頼実績などの情報が関連付けて管理される。

依頼者ＩＤは、上述したように、依頼者を一意に識別するための識別情報であってよい。この依頼者ＩＤは、本サービスにログインするためのログインＩＤとして使用されてもよい。

パスワードは、依頼者によって設定されたパスワードであってよく、本サービスにログインする際の認証に使用される情報であってよい。

医療機関は、依頼医が所属する医療機関の名称（又は、医療機関を一意に識別するための識別情報）であってよい。

診療科は、依頼医が所属する診療科、もしくは、読影を依頼する診療科に関する情報であってよい。例えば、依頼者である臨床医が放射線科に属する医師である場合は放射線科が指定されてよく、内科である場合は内科が指定されてよい。また、依頼者が総合病院など複数の診療科を設けている場合、読影を依頼する可能性のある１又は複数の診療科が指定されてよい。

依頼医の氏名は、依頼の責任者としての自然人を特定するための情報であってよい。

連絡先は、依頼者の住所、電話番号、電子メールアドレスなど、依頼者と連絡を取る際に必要となる情報であってよい。

支払い情報は、例えば、引き落とし口座やクレジットカード情報やＰａｙｐａｙ（登録商標）などのオンライン決済サービスに関する情報など、依頼者が決済（支払い）を行うための情報であってよい。サービス提供サイト１００において依頼者の支払い情報を予め管理しておくことで、依頼ごとに都度支払い情報を入力する手間やリスクを排除することが可能となる。なお、支払い情報は、１つに限定されず、複数の支払い情報が登録されてもよい。

依頼実績は、過去に読影を依頼した分野（例えば、診療科）ごとの依頼件数などに関する情報であってもよい。

・・・・受注者データベース（ＤＢ）
図８は、本実施形態に係るユーザ管理サーバで管理される受注者ＤＢの一例を示す図である。図８に示すように、受注者ＤＢ１４３では、登録された各受注者に関し、受注者ＩＤ、パスワード、氏名、連絡先、受注分野、受注実績、対応可能な医用画像解析ソフト、振込先情報などの情報が関連付けて管理される。

受注者ＩＤは、上述したように、受注者を一意に識別するための識別情報であってよい。この受注者ＩＤは、本サービスにログインするためのログインＩＤとして使用されてもよい。

パスワードは、依頼者によって設定されたパスワードであってよく、本サービスにログインする際の認証に使用される情報であってよい。

氏名は、受注者が個人の場合はその氏名、受注者が会社や企業などの組織の場合はその組織の名称などであってよい。

連絡先は、受注者の住所、電話番号、電子メールアドレスなど、受注者と連絡を取る際に必要となる情報であってよい。

受注分野は、読影を受注可能な分野、例えば診療科に関する情報であってよい。例えば、受注者である読影医３００が放射線科を専門とする医師である場合は放射線科が指定されてよく、内科である場合は内科が指定されてよい。また、受注者が複数の診療科に対応可能である場合には、複数の診療科が指定されてもよい。

受注実績は、過去に読影を受注した分野（例えば、診療科）ごとの受注件数や、読影の正確性のなどに関する情報であってもよい。なお、読影の正確性は、依頼者の評価などが反映されてもよい。

対応可能な医用画像解析ソフトは、受注者である読影医３００が読影に使用することが可能な医用画像解析ソフトのリストであってよい。例えば、読影医３００がOsiriX（登録商標）、DICOM Library、IMAIOS DICOM Viewer、PostDICOM、Voxelx、FViewerなどの医用画像解析ソフトのうちの１つ以上を使用可能である場合には、使用可能な１又は複数のソフトがリストアップされてもよい。

振込先情報は、例えば、振込先となる銀行口座やオンライン決済サービスに関する情報など、受注者が決済（振込）を受けるための情報であってよい。サービス提供サイト１００において受注者の振込先情報を予め管理しておくことで、受注ごとに都度振込先情報を入力する手間やリスクを排除することが可能となる。なお、振込先情報は、１つに限定されず、複数の振込先情報が登録されてもよい。

（動作例）
次に、本実施形態に係る遠隔画像診断総合支援システム１の動作例について、図面を参照して詳細に説明する。図９～図１４は、本実施形態に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である。

まず、図９に示すように、本動作では、最初に、医療機関２００が依頼者クライアント２１０を用いてサービス提供サイト１００の受注管理サーバ１１０が提供するウェブサイト（図１５に示す依頼プラン選択画面参照）にアクセスし、サービス提供サイト１００において予め用意されている依頼プランを選択する（ステップＳ２１０１→Ｓ１１０１）。依頼プランとは、依頼内容の大まかな種類（例えば、上述した診断目的、研究目的、検証目的など）や料金などに基づいてサービス提供サイト１００側が予め用意した商品であってよい。

なお、依頼内容の種類は、例えば、上述した診断目的、研究目的、検証目的などの目的ごとに区分けされていてもよいし、診療科ごとに区分けされてもよいし、医用画像の取得に使用したモダリティごとに区分けされてもよいし、読影対象の医用画像のデータ形式（ＤＩＣＯＭ、ＪＰＥＧ、ＴＩＦＦ、ＧＩＦ、ＢＭＰ、ＭＰ４など）ごとに区分けされてもよいし、読影に使用するアプリケーション（OsiriX、DICOM Library、IMAIOS DICOM Viewer、PostDICOM、Voxelx、FViewerなど）ごとに区分けされてもよいし、その他の要素に基づいて区分けされてもよいし、これらのうちの２以上を組み合わせたカテゴリごとに区分けされてもよい。

また、依頼プランの料金は、１回分に限定されず、例えば５回など、複数回の依頼がパッケージングされた料金であってもよし、例えば１月や１年など、期間ごとの料金であってもよい。期間ごとの料金とする場合、期間ごとの上限の依頼件数（例えば、１月であれば１０件など）が設定されていてもよい。

ここで、依頼プラン選択画面について、図１５を参照して説明する。図１５は、本実施形態に係る依頼プラン選択画面の一例を示す図である。図１５に示すように、依頼プラン選択画面には、１又は複数の依頼プランの一覧が表示されてよい。各依頼プランは、選択可能なアイコンとして表示されており、依頼者が目的の依頼プランのアイコンに対してダブルクリックするなどの操作を行うことで、依頼プランが選択されてもよい。

このように、依頼プランが選択されると、受注管理サーバ１１０の依頼受付部１１１は、依頼者クライアント２１０のウェブブラウザに、本サービスにログインするためのログイン画面（図１６参照）を表示させ、医療機関２００に本サービスへのログインを要求する（ステップＳ１１０２→Ｓ２１０２）。これに対し、医療機関２００は、依頼者クライアント２１０を用いて自己に付与されたログインＩＤ及びパスワードをログイン画面へ入力し、「ログイン」ボタンを選択することで、受注管理サーバ１１０に対してログイン認証を要求する（ステップＳ２１０３→Ｓ１１０３）。

なお、上述したように、ログインＩＤには、医療機関２００が依頼者として登録した際に付与された依頼者ＩＤが用いられてもよい。若しくは、ログインＩＤの代わりに、電子メールアドレスが使用されてもよい。また、医療機関２００が依頼者として本サービスに未登録である場合、受注管理サーバ１１０の依頼受付部１１１は、図１７に示すような、依頼者新規登録画面を依頼者クライアント２１０に表示させ、必要な事項を医療機関２００に入力させることで、医療機関２００を依頼者として依頼者ＤＢ１４２に登録してもよい。

次に、受注管理サーバ１１０の依頼受付部１１１は、医療機関２００によって入力されたログイン情報（ログインＩＤ及びパスワード）をユーザ管理サーバ１４０に通知し、医療機関２００に対する認証処理を要求する（ステップＳ１１０４→Ｓ１４０４）。これに対し、ユーザ管理サーバ１４０のユーザ認証部１４４は、通知されたログイン情報と、依頼者ＤＢ１４２に登録されているログイン情報（ログインＩＤ及びパスワード）とを照らし合わせることで、登録された正規の依頼者であるか否かを認証する（ステップＳ１４０５）。

次に、ユーザ認証部１４４は、認証結果を受注管理サーバ１１０へ通知する（ステップＳ１４０６→Ｓ１１０６）。これに対し、受注管理サーバ１１０の依頼受付部１１１は、ユーザ認証に成功した場合、医療機関２００（具体的には、依頼者クライアント２１０）に対してログインを許可する（ステップＳ１１０７→Ｓ２１０７）。なお、ステップＳ１４０５においてログイン認証に失敗した場合は、再度ログイン要求（ステップＳ１１０２→２１０２）が実行されてもよい。

依頼者クライアント２１０に対してログインが許可されると、図１０に示すように、依頼者クライアント２１０には、依頼内容の基礎情報（依頼基礎情報）を医療機関２００に入力させるための画面（図１８に示す読影依頼登録画面参照）が表示され、この読影依頼登録画面に従って医療機関２００により依頼基礎情報が登録される（ステップＳ２１０８→Ｓ１１０８）。読影依頼登録画面参照は、例えば、受注管理サーバ１１０の依頼受付部１１１によって生成されたネットワーク４００上に公開されてもよい。

ここで、医療機関２００が依頼時に登録する依頼基礎情報について、この依頼基礎情報を入力するための読影依頼登録画面を用いて説明する。図１８は、本実施形態に係る診断目的の場合の読影依頼登録画面の例を示す図である。図１８に示すように、読影依頼登録画面には、依頼者である医療機関の名称（個人の医師である場合は氏名）、診療科、依頼医の氏名、患者名、患者ＩＤ、患者生年月日、患者年齢、患者性別、モダリティ、臨床経過、及び、特に読影してほしいポイントをそれぞれ入力する欄が設けられている。なお、モダリティとは、読影対象の医用画像を取得した医療用検査装置の種別に関する情報であってもよい。このモダリティには、医用画像のファイルフォーマットに関する情報などが含まれてもよい。また、依頼日時は、依頼者（本例では医療機関２００）が読影依頼登録画面にアクセスしたタイミングや、「依頼」ボタンをクリックしたタイミングなど、依頼者により所定のアクションが行われた際に自動的に設定されてもよい。

ただし、患者名、患者ＩＤ、患者生年月日、臨床経過、及び、特に読影してほしいポイントは、患者の個人情報に相当し得る情報であるため、読影依頼登録画面ではなく、後述する読影依頼書（図２１及び図２２参照）において追加で登録されるように構成されてもよい。

また、図１９に、本実施形態に係る研究目的の場合の読影依頼登録画面の例を示し、図２０に、本実施形態に係る検証目的の場合の読影依頼登録画面の例を示す。図１９及び図２０に示すように、読影依頼登録画面において登録される依頼基礎情報の内容は、目的ごとに異なっていてもよい。その場合、図３に例示した依頼管理テーブル１１６で管理される項目は、目的ごとに異なっていてもよい。

このように読影依頼登録画面に入力された依頼基礎情報（依頼日時も含む）は、文字列として受注管理サーバ１１０へ入力され、受注管理サーバ１１０の依頼管理部１１２によって依頼管理テーブル１１６の所定のレコードに登録されて管理される。その際、依頼管理部１１２は、依頼ＩＤを生成して所定のレコードに格納してよい。また、依頼者ＩＤは、読影依頼登録画面に入力欄を設けて依頼者に入力させてもよいし、読影依頼医登録画面に入力された依頼基礎情報に基づきユーザ管理サーバ１４０で管理されている依頼者ＤＢ１４２から特定されてもよい。さらに、受注者ＩＤは、受注者が未定である場合は空欄（Ｎｕｌｌ）であってよく、受注者が決定された後はユーザ管理サーバ１４０で管理されている受注者ＤＢ１４３から特定されてもよい。

次に、受注管理サーバ１１０の決済処理要求部１１３は、依頼基礎情報に含まれる医療機関２００の名称、診療科、依頼医の氏名等に基づいてユーザ管理サーバ１４０にアクセスし、該当する医療機関２００に関して依頼者ＤＢ１４２に予め登録されている依頼者に関する情報を問い合わせる（ステップＳ１１０９→Ｓ１４０９）。これに対し、ユーザ管理サーバ１４０のユーザ管理部１４１は、受注管理サーバ１１０から通知された医療機関２００の名称、診療科、依頼医の氏名等に基づいて依頼者ＤＢ１４２（図７参照）を参照することで、該当する医療機関２００の依頼者に関する情報を取得し、取得した情報を受注管理サーバ１１０に通知する（ステップＳ１４１０→Ｓ１１１０）。

なお、依頼者である医療機関２００が未だ依頼者ＤＢ１４２に登録されていない場合（例えば、医療機関２００からの依頼が初めてである場合）、受注管理サーバ１１０が、医療機関２００に関する情報を登録するための画面を依頼者クライアント２１０へ提供し、この画面に入力された情報をユーザ管理サーバ１４０に通知し、ユーザ管理サーバ１４０のユーザ管理部１４１が通知された情報を新たに依頼者ＤＢ１４２に登録するステップが追加されてもよい。

次に、受注管理サーバ１１０の決済処理要求部１１３は、ユーザ管理サーバ１４０から通知された依頼者に関する情報に含まれる支払い情報に基づいて、今回の依頼に関する決済処理を決済サーバ１３０に要求する（ステップＳ１１１１→Ｓ１３１１）。この際、支払い情報については、受注管理サーバ１１０から決済サーバ１３０に通知されてもよいし、決済サーバ１３０の情報取得部１３１がユーザ管理サーバ１４０にアクセスして取得してもよい。

次に、決済サーバ１３０の決済処理部１３２は、決済画面を依頼者クライアント２１０へ提供することで、今回の依頼に関する決済を医療機関２００に要求する（ステップＳ１３１２→Ｓ２１１２）。この際、受注管理サーバ１１０は、依頼者クライアント２１０のアクセス先を決済サーバ１３０に自動的に切り替えることで、医療機関２００がスムーズに決済を行えるように誘導してもよい。

次に、医療機関２００は、依頼者クライアント２１０のウェブブラウザに表示された決済画面に従い所定の操作を入力することで、今回の依頼に関する決済を実行する（ステップＳ２１１３→Ｓ１３１３）。なお、本実施形態では、引き落とし口座やクレジットカード情報などの支払い情報がサービス提供サイト１００において予め管理されており、依頼者（本例では医療機関２００）は決済でこの管理されている支払い情報を使用することができる。そのため、依頼の度に依頼者に支払い情報を入力させることにより生じるリスクを回避することが可能となり、安全な取引を実現することが可能となる。

次に、決済サーバ１３０の領収書発行部１３３は、医療機関２００による決済手続の完了を確認すると、今回の依頼に関する領収書を依頼者クライアント２１０へ発行する（ステップＳ１３１４）。これに対し、医療機関２００は、依頼者クライアント２１０を用いて必要に応じて領収書を決済サーバ１３０からダウンロード（ＤＬ）することができる（ステップＳ１３１５→Ｓ２１１５）。なお、決済サーバ１３０において発行される領収書は、例えば、ＰＤＦ（Portable Document Format）などの電子ファイルであってもよい。また、サービス提供サイト１００は、要求に応じて紙の領収書を医療機関２００へ郵送してもよい。その後、決済サーバ１３０の決済処理部１３２は、医療機関２００による決済手続が完了したことを受注管理サーバ１１０に通知する（ステップＳ１３１６→Ｓ１１１６）。

次に、図１１に示すように、受注管理サーバ１１０の格納領域作成要求部１１４は、患者の氏名や生年月日、読影対象の医用画像など、秘匿性の高い情報を含む情報をセキュアに格納するための格納領域１２５の作成（確保を含む）を情報格納サーバ１２０に要求する（ステップＳ１１１７→Ｓ１２１７）。この際、受注管理サーバ１１０から情報格納サーバ１２０には、依頼者に関する情報の一部（例えば、依頼者ＩＤや電子メールアドレスなど）が通知されてよい。

次に、情報格納サーバ１２０の格納領域作成部１２１は、ネットワーク４００を介してアクセス可能な格納領域１２５を記憶部１２４内に作成（又は確保）する（ステップＳ１２１８）。つづいて、情報格納サーバ１２０のアクセス権付与部１２２は、作成（又は確保）された格納領域１２５に対するアクセス権を医療機関２００に付与する（ステップＳ１２１９）。例えば、情報格納サーバ１２０がクラウドストレージである場合、情報格納サーバ１２０は、ネットワーク４００を介してアクセス可能なデータボックスを作成し（ステップＳ１２１８参照）、このデータボックスに対するアクセス権を医療機関２００（依頼者クライアント２１０であってもよい）に付与してもよい（ステップＳ１２１９参照）。

次に、情報格納サーバ１２０のアクセス権付与部１２２は、作成（又は確保）した格納領域１２５へネットワーク４００を介してアクセスするためのアドレス（例えば、ＵＲＬ（Uniform Resource Locator））を医療機関２００へ通知する（ステップＳ１２２０→Ｓ２１２０）。なお、情報格納サーバ１２０による医療機関２００への格納先アドレスの通知は、電子メールなどを用いて実行されてもよい。

このように格納先アドレスが通知されると、医療機関２００は、依頼者クライアント２１０から格納先アドレスを用いて格納領域１２５にアクセスし、この格納領域１２５に依頼内容に関するより詳細な情報（以下、依頼情報ともいう）をアップロード（ＵＬ）する（ステップＳ２１２１→Ｓ１２２１）。なお、依頼情報は、電子カルテ（例えば、ＰＤＦとして出力された電子カルテ）などの情報も含まれてよい。また、依頼情報は、格納領域１２５内に格納される際に、ランダムに発生したパスワードで暗号化されてもよい。依頼情報の暗号化は、例えば、依頼者クライアント２１０において実行されてもよいし、情報格納サーバ１２０の格納情報管理部１２３において実行されてもよい。暗号化に使用されたパスワードは、依頼情報をアップロードした医療機関２００及び／又は当該依頼を受注した読影医３００へ適宜通知されてよい。例えば、後述する図１３のステップＳ１１３１→Ｓ３１３１の格納先アドレス通知の際にパスワードも通知されてよい。

ここで、格納領域１２５に格納される依頼情報について、図２１及び図２２を参照して詳細に説明する。図２１及び図２２は、本実施形態に係る依頼情報の例を示す図である。なお、図２１及び図２２では、医用画像を除く依頼情報の例が示されているが、本実施形態に係る依頼情報には、読影対象の医用画像が含まれてよい。

図２１及び図２２に示すように、医用画像を除く依頼情報は、例えば、「読影依頼書」というタイトルが付けられたファイルとして格納領域１２５内に格納されてもよい。この依頼情報には、例えば、「依頼者情報」、「患者情報」、「臨床経過」、「特に読影してほしいポイント」などの情報が含まれてもよい。

「依頼者情報」には、例えば、医療機関２００の名称、診療科、依頼医、依頼日時などの情報が含まれてよい。「患者情報」には、例えば、患者ＩＤ及びモダリティに関する情報の他、患者の氏名、生年月日、年齢、性別などの情報が含まれてもよい。なお、依頼者情報及び患者情報のうち、読影依頼登録画面に入力された依頼基礎情報に含まれる情報は、この情報から流用されてもよい。

また、「臨床経過」は、患者に対してこれまで行った治療行為等に関する情報であってもよく、「特に読影してほしいポイント」は、依頼医が読影医に対して望む特に読影してほしいポイントに関する情報であってもよい。

以上のような情報を含む読影依頼書は、例えば、テキストファイルやワードファイルやＰＤＦなどのドキュメント形式、ＪＰＥＧ、ＧＩＦ、ＴＩＦＦ、ＰＮＧなどの画像形式、ＭＰ４などの映像形式で保存されたファイルとして格納領域１２５に格納されてもよい。

格納領域１２５への依頼情報のアップロードは、例えば、情報格納サーバ１２０の格納情報管理部１２３が提供する登録情報管理画面を介して行われてもよい。図２３は、本実施形態に係る登録情報管理画面の一例を示す図である。

図２３に示すように、登録情報管理画面には、例えば、確保された格納領域１２５にアップロードするファイルを選択する欄と、選択されたファイルを確保された格納領域１２５へアップロードするための「アップロード」ボタンと、格納領域１２５に格納されているファイルの一覧を表示する欄と、この一覧から選択されたファイルを個別にダウンロードするための「ダウンロード」ボタンと、格納領域１２５に格納されているファイルを一括でダウンロードするための「一括ダウンロード」ボタンとが設けられてもよい。

医療機関２００は、自身に用意された格納領域１２５へ依頼情報をアップロードする場合、依頼者クライアント２１０のウェブブラウザ機能を用いて登録情報管理画面を閲覧し、この登録情報管理画面においてアップロードするファイル（読影依頼書、１以上の医用画像、音声ファイルなど）を選択して「アップロード」ボタンをクリックする。それにより、選択されたファイルが情報格納サーバ１２０へアップロードされ、格納情報管理部１２３によって指定の格納領域１２５に格納される。

動作の説明に戻る。上述のように、記憶部１２４内の格納領域１２５に依頼情報が格納されると、図１２に示すように、情報格納サーバ１２０の格納情報管理部１２３は、受注管理サーバ１１０へ依頼情報が格納されたことを通知する（ステップＳ１２２２→Ｓ１１２２）。

次に、受注管理サーバ１１０の情報格納通知部１１５は、受注者となる読影医の情報（受注者に関する情報）をユーザ管理サーバ１４０に問い合わせる（ステップＳ１１２３→Ｓ１４２３）。その際、情報格納通知部１１５は、依頼基礎情報又はその一部の情報をユーザ管理サーバ１４０へ通知する。これに対し、ユーザ管理サーバ１４０のユーザ管理部１４１は、問い合わせの際に受注管理サーバ１１０から通知された情報に基づいて受注者ＤＢ１４３を参照することで、今回の依頼の受注者となる読影医３００（具体的には、受注者に関する情報）を特定し、特定した受注者に関する情報のうちの少なくとも連絡先（例えば、電子メールアドレス）を受注管理サーバ１１０へ通知する（ステップＳ１４２４→Ｓ１１２４）。

次に、受注管理サーバ１１０の情報格納通知部１１５は、ユーザ管理サーバ１４０から通知された読影医３００（具体的には、その連絡先）へ、依頼があったことを通知する（ステップＳ１１２５→Ｓ３１２５）。例えば、ユーザ管理サーバ１４０から受注管理サーバ１１０へ読影医３００の連絡先として電子メールアドレスが通知された場合、情報格納通知部１１５は、そのアドレス宛に依頼があったことを通知するための電子メールを自動送信する。この電子メールには、例えば、受注者である読影医３００が依頼内容の概要を確認するための依頼概要確認画面（図２４参照）へ誘導するためのＵＲＬが添付されていてもよい。

ここで、図２４は、本実施形態に係る依頼概要確認画面の一例を示す図である。図２４に示すように、依頼概要確認画面は、受注者（本例では読影医３００）が依頼の概要を理解するための情報（例えば、依頼基礎情報）を表示する領域と、受注者が当該依頼を受注するか受注しないかを選択するためのボタンとが設けられてもよい。このような依頼概要確認画面は、医療機関２００が依頼者クライアント２１０を用いて依頼基礎情報を登録した際（ステップＳ２１０８→Ｓ１１０８参照）に、受注管理サーバ１１０の情報格納通知部１１５において自動的に生成されてもよい。

依頼があったことが通知された読影医３００は、受注者クライアント３１０を用いて通知されたＵＲＬから依頼概要確認画面を確認し（ステップＳ３１２６→Ｓ１１２６）、受注するか否かを判断する。そして、受注する場合、読影医３００は、例えば、依頼概要確認画面における「受注する」ボタンをクリックすることで、受注を承認する（ステップＳ３１２７→Ｓ１１２７）。なお、読影医３００が「受注しない」ボタンをクリックした場合、読影医３００により依頼が受任されなかったことが受注管理サーバ１１０を介して依頼者クライアント２１０へ通知されてもよい。

読影医３００により依頼が受任されると、図１３に示すように、受注管理サーバ１１０の情報格納通知部１１５は、確保された格納領域１２５へのアクセス権を読影医３００へ付与することを情報格納サーバ１２０に要求する（ステップＳ１１２８→Ｓ１２２８）。その際、情報格納通知部１１５は、受注者に関する情報のうちの少なくも受注者ＩＤを情報格納サーバ１２０へ通知する。これに対し、情報格納サーバ１２０のアクセス権付与部１２２は、読影医３００（例えば、読影医３００に割り当てられた受注者ＩＤ）に対して格納領域１２５へのアクセス権を付与し（ステップＳ１２２９）、アクセス権の付与が完了したことを受注管理サーバ１１０へ通知する（ステップＳ１２３０→Ｓ１１３０）。この際、情報格納サーバ１２０から受注管理サーバ１１０へは、格納領域１２５のアドレス（例えば、ＵＲＬ）が改めて通知されてもよい。

次に、受注管理サーバ１１０の情報格納通知部１１５は、依頼を受注した読影医３００の受注者クライアント３１０へ、格納領域１２５へネットワーク４００を介してアクセスするためのアドレス（例えば、ＵＲＬ）を通知する（ステップＳ１１３１→Ｓ３１３１）。この際、上述のように、依頼情報が暗号化されている場合は、この暗号化に使用されたパスワードも通知されてよい。

次に、読影医３００は、受注者クライアント３１０を用いて通知されたＵＲＬから登録情報管理画面（図２３参照）へアクセスし（ステップＳ３１３２→Ｓ１２３２）、格納領域１２５に格納されているファイル（依頼情報）をダウンロード（ＤＬ）する（ステップＳ３１３３→Ｓ１２３３）。なお、読影医３００が受注者クライアント３１０を用いて登録情報管理画面（図２３参照）へアクセスする際、例えば、依頼者（本例では医療機関２００）に対するログイン認証処理（ステップＳ１１０２～Ｓ２１０７）と同様に、受注者ＩＤ及びパスワードなどを用いたログイン認証処理が行われてもよい。

このように、依頼情報（読影依頼書、１以上の医用画像、音声ファイルなど）を取得した読影医３００は、依頼の内容に従い１以上の医用画像を読影し、読影レポートを作成する（ステップＳ３１３４）。なお、医用画像の読影に用いられる情報処理装置は受注者クライアント３１０に限定されず、種々の情報処理装置を用いて行われてもよい。

ここで、読影医３００によって作成される読影レポートについて、具体例を用いて説明する。図２５～図２７、及び、図２８～図３３は、本実施形態に係る読影レポートの例を示す図である。

図２５～図２７、及び、図２８～図３３に示すように、読影レポートは、例えば、依頼者情報と、患者情報と、臨床経過と、所見と、総括とを含む。依頼者情報、患者情報及び臨床経過は、読影依頼書に含まれるそれらを引用したものであってもよい。所見は、患者情報や臨床経過などに基づき医用画像を読影した結果として読影医３００が作成したものであってよく、総括とは、読影医３００がその他の情報を含めて全体的に判断した結果として作成したものであってよい。

また、読影レポートには、必要に応じて、読影レポート（特に、所見や総括）の理解を容易にするための１以上の医用画像が張り付けられていてもよい。この医用画像には、読影時に注目した箇所、所見や総括で触れた個所などを指し示すために、矢印や囲いや色付け／色分けなどの編集がなされていてもよい。なお、読影済みの医用画像は、読影レポートへの貼り付けに限定されず、例えば別ファイルとして格納領域１２５に格納されてもよい。

動作の説明に戻る。以上のように、読影レポートを作成すると、図１４に示すように、読影医３００は、受注者クライアント３１０を用いて通知済みのＵＲＬから登録情報管理画面（図２３参照）へアクセスし、作成した読影レポートを情報格納サーバ１２０の記憶部１２４に確保されている格納領域１２５へアップロードする（ステップＳ３１３５→Ｓ１２３５）。これに対し、情報格納サーバ１２０の格納情報管理部１１２３は、受注管理サーバ１１０へ読影レポートが格納されたことを通知する（ステップＳ１２３６→Ｓ１１３６）。なお、読影レポートは、格納領域１２５内に格納される際に、ランダムに発生したパスワードで暗号化されてもよい。読影レポートの暗号化は、例えば、受注者クライアント３１０において実行されてもよいし、情報格納サーバ１２０の格納情報管理部１２３において実行されてもよい。暗号化に使用されたパスワードは、読影レポートをアップロードした読影医３００及び／又は当該依頼を発注した医療機関２００へ適宜通知されてよい。例えば、後述する図１４のステップＳ１１４０→Ｓ２１４０の読影レポート格納通知の際にパスワードも通知されてよい。

次に、受注管理サーバ１１０の決済処理要求部１１３は、読影医３００への支払い処理を決済サーバ１３０に依頼する（ステップＳ１１３７→Ｓ１３３７）。この際、振込先情報については、受注管理サーバ１１０から決済サーバ１３０に通知されてもよいし、決済サーバ１３０がユーザ管理サーバ１４０にアクセスして取得してもよい。受注管理サーバ１１０から支払い依頼を受け付けると、決済サーバ１３０の決済処理部１３２は、支払い情報に従い、今回の依頼に設定されている金額の支払い（振込）処理を実行する（ステップＳ１３３８）。そして、決済処理部１３２は、支払い処理が完了すると、支払い処理が完了したことを受注管理サーバ１１０へ通知する（ステップＳ１３３９→Ｓ１１３９）。

また、受注管理サーバ１１０の情報格納通知部１１５は、格納領域１２５に読影レポートが格納されたことが情報格納サーバ１２０から通知（ステップＳ１２３６→Ｓ１１３６参照）されると、依頼者に関する情報における連絡先に基づいて、読影レポートが格納領域１２５に格納されたことを医療機関２００へ通知する（ステップＳ１１４０→Ｓ２１４０）。この際、上述のように、読影レポートが暗号化されている場合は、この暗号化に使用されたパスワードも通知されてよい。

次に、医療機関２００は、依頼者クライアント２１０を用いて登録情報管理画面（図２３参照）へアクセスし（ステップＳ２１４１→Ｓ１２４１）、格納領域１２５に格納されている読影レポートをダウンロードする（ステップＳ１２４２→Ｓ２１４２）。これにより、依頼者である医療機関２００によって今回の依頼に対する読影レポートが取得される。

以上の動作により、セキュアに情報を格納することが可能な格納領域１２５を介して依頼者（医療機関２００）と受注者（読影医３００）との間で患者の個人情報や読影レポートなどの秘匿性の高い情報の受け渡しが可能となるため、情報の秘匿性が保たれたセキュアの遠隔画像診断総合支援システム１を実現することが可能となる。そして、本実施形態によれば、サービス提供サイト１００において依頼の受注から決済、読影レポートの登録（納品）までを一貫して支援することが可能となるため、医師が読影医として医療行為に参加するハードルを大幅に低減することが可能となる。それにより、より多くの医師が読影医として医療に参加することを可能にする遠隔画像診断総合支援装置、遠隔画像診断総合支援方法及びプログラムを提供することが可能となる。

さらに、本実施形態によれば、サービス提供サイト１００が提供する受注管理サービスや決済サービスを利用することで、依頼者及び受注者における依頼・受注処理の手間や会計処理の手間を大幅に削減することが可能となるため、人件費や管理費用などの中間コストを大幅に削減することが可能となる。さらにまた、本実施形態によれば、読影医３００などの受注者は、依頼者である医療機関２００などと直接契約して依頼を受けることが可能となるため、営業費などの中間コストを大幅に削減することも可能となる。

また、従来では、臨床医もしくは診断を依頼したい医療機関は読影専門会社との初期費用および月額利用料などを支払う定期契約が必要であり、診断を依頼したいときだけ依頼するというオンデマンドサービス存在していなかった。また、読影依頼側である臨床医は診断が困難な症例や複雑な症例などをその診断を得意とする読影医を選んで依頼したいところであるが、読影医が自由に参入しにくい環境、読影専門会社が仕事を割り振る権利を有するなどの問題から、所望する読影医への依頼ができない場合があり、診断を困難にする状況があった。

これに対し、本実施形態によれば、臨床医および診断を依頼する医療機関２００、読影医３００がオンデマンドベースで仕事をすることを可能にするため、診断依頼側及び読影側が自由に営業することが可能となる。その場合でも、診断依頼側及び読影側それぞれでの会計を自動で行うことが可能であるため、中間コストを大幅に引き下げることが可能である。

なお、本実施形態では、格納領域１２５への読影レポートの格納毎、すなわち、依頼を受注して遂行した度に、読影医３００へ報酬を支払う場合を例示したが、読影医３００への報酬の支払いは、このような形態に限定されない。例えば、受注管理サーバ１１０において、所定の期間（例えば、１月）毎に読影医３００毎及びプラン毎の受注件数を管理しておき、所定の期間経過時又は経過後（例えば、月末など）に、受注件数に応じた金額を読影医３００へ支払うように構成されてもよい。

また、本実施形態では、医療機関２００が依頼をする度に、選択したプランに応じた金額を請求する場合を例示したが、医療機関２００への請求は、このような形態に限定されない。例えば、受注管理サーバ１１０において、所定の期間（例えば、１月）毎に医療機関２００毎及びプラン毎の依頼件数を管理しておき、所定の期間経過時又は経過後（例えば、月末など）に、依頼件数に応じた金額を医療機関２００へ請求するように構成されてもよい。

（第１の実施形態の変形例）
上述した第１の実施形態では、受注者が個人の読影医３００である場合を例示したが、例えば、受注者が複数の読影医を抱える読影専門会社などである場合、この読影専門会社内で各読影医に受注した依頼を割り当てる作業が発生する。そこで、本変形例では、読影専門会社内において各読影医への依頼の割り当てを自動化する構成について、例を挙げて説明する。

各読影医への依頼の自動割当ては、例えば、受注者クライアント３１０において実行されてもよい。その場合、受注者クライアント３１０は、読影医ごとの識別番号（読影医ＩＤともいう）、診療科、得意分野（頭部、胸部、腹部など）、読影実績（読影した医用画像の分野や回数など）、得意なモダリティ（レントゲン、ＣＴ、ＰＥＴ－ＣＴ、ＭＲＩなど）、読影に使用するアプリケーション（OsiriX、DICOM Library、IMAIOS DICOM Viewer、PostDICOM、Voxelx、FViewerなど）などの情報（読影医情報ともいう）を管理しておき、依頼情報から読影医情報に基づいて、各依頼に対して適切な読影医を自動的に割り当ててもよい。例えば、受注者クライアント３１０は、数字で構成されている読影医ＩＤの順に依頼を割り当ててもよいし、得意分野に基づいて依頼を割り当ててもよいし、得意なモダリティに基づいてに基づいて依頼を割り当ててもよいし、読影医情報における２つ以上の項目に基づいて依頼を割り当ててもよい。

サービス提供サイト１００からの依頼情報のダウンロードは、読影専門会社の受注者クライアント３１０から実行されてもよいし、依頼が割り当てられた読影医のクライアントから実行されてもよい。読影医のクライアントから実行される場合、格納領域１２５へのアクセス権は、このクライアントにも付与されてよい。

同様に、読影専門会社からサービス提供サイト１００への読影レポートのアップロードは、読影専門会社の受注者クライアント３１０から実行されてもよいし、依頼が割り当てられた読影医のクライアントから実行されてもよい。読影医のクライアントから実行される場合、格納領域１２５へのアクセス権は、このクライアントにも付与されてよい。

その他の構成、動作及び効果は、上述した第１の実施形態と同様であってよいため、ここでは詳細な説明を省略する。

＜第２の実施形態＞
次に、本開示の第２の実施形態について、図面を参照して詳細に説明する。なお、以下の説明では、明確化のため、第１の実施形態に係る遠隔画像診断総合支援システム１との相違に着目する。

本実施形態では、複数の受注者に対して１又は複数の依頼者が医用画像の読影を依頼する場合が例示される。以下では、第１の実施形態と同様に、明確化のため、複数の受注者それぞれが個人の読影医であり、受注者が医療機関である場合を例示する。

（システム構成）
図３４は、本実施形態に係る遠隔画像診断総合支援サービスを実現するための遠隔画像診断総合支援システムの概略構成例を示す模式図である。図３４と図１とを比較すると明らかなように、第１の実施形態に係る遠隔画像診断総合支援システム１では、依頼者（例えば、医療機関２００）と受注者（例えば、読影医３００）との関係が一対一として構成されている場合が例示されていたのに対し、本実施形態に係る遠隔画像診断総合支援システム２では、依頼者（例えば、医療機関２００）と受注者（例えば、読影医３００Ａ～３００Ｃ）との関係が一対複数として構成されている場合が例示される。

本実施形態に係るサービス提供サイト１００を構成する各種サーバ１１０、１２０、１３０及び１４０並びに医療機関２００の依頼者クライアント２１０の構成は、第１の実施形態に係るそれらと同様であってよい。また、本実施形態に係る読影医３００Ａ～３００Ｃそれぞれの受注者クライアント３１０Ａ～３１０Ｃの構成は、第１の実施形態に係る読影医３００の受注者クライアント３１０と同様であってよい。

（動作例）
次に、本実施形態に係る遠隔画像診断総合支援システム２の動作例について説明する。図３５は、本実施形態に係る遠隔画像診断総合支援システムの動作の一例を示すシーケンス図である。なお、以下の説明において、第１の実施形態に係る遠隔画像診断総合支援システム１の動作と同様のステップについては、それらを引用することで重複する説明を省略する。ただし、本実施形態に係る遠隔画像診断総合支援システム２の動作例では、第１の実施形態では１台であった受注者クライアント３１０が、複数台の受注者クライアント３１０Ａ～３１０Ｃに置き換えられている。

本実施形態では、先ず、第１の実施形態において図９～図１１を用いて説明した動作と同様の動作を実行することで、情報格納サーバ１２０の記憶部１２４内に確保された格納領域１２５に依頼情報が格納される。そして、図３５に示すように、情報格納サーバ１２０の格納情報管理部１２３が、受注管理サーバ１１０へ依頼情報が格納されたことを通知する（ステップＳ１２２２→Ｓ１１２２）。

次に、受注管理サーバ１１０の情報格納通知部１１５は、受注者の候補となる１以上の読影医の情報（受注者に関する情報）をユーザ管理サーバ１４０に問い合わせる（ステップＳ１１２３－１→Ｓ１４２３－１）。その際、図１２のステップＳ１１２３→Ｓ１４２３と同様に、情報格納通知部１１５は、依頼基礎情報又はその一部の情報をユーザ管理サーバ１４０へ通知する。これに対し、ユーザ管理サーバ１４０のユーザ管理部１４１は、問い合わせの際に受注管理サーバ１１０から通知された情報に基づいて受注者ＤＢ１４３を参照することで、今回の依頼の受注候補者となる１以上の読影医３００Ａ～３００Ｃ（具体的には、受注者に関する情報）を特定し、特定した１以上の受注候補者者に関する情報それぞれのうちの少なくとも連絡先（例えば、電子メールアドレス）を受注管理サーバ１１０へ通知する（ステップＳ１４２４－１→Ｓ１１２４－１）。

次に、受注管理サーバ１１０の情報格納通知部１１５は、ユーザ管理サーバ１４０から通知された１以上の読影医３００Ａ～３００Ｃ（具体的には、その連絡先）それぞれへ、依頼があったことを通知する（ステップＳ１１２５→Ｓ３１２５Ａ、Ｓ３１２５Ｂ及びＳ３１２５Ｃ）。なお、通知により１以上の読影医３００Ａ～３００Ｃそれぞれが誘導される依頼概要確認画面は、図２４に例示したものと同様であってよい。

依頼があったことが通知された１以上の読影医３００Ａ～３００Ｃそれぞれは、受注者クライアント３１０Ａ～３１０Ｃを用いて通知されたＵＲＬから依頼概要確認画面を確認し（ステップＳ３１２６Ａ→Ｓ１１２６Ａ、Ｓ３１２６Ｂ→Ｓ１１２６Ｂ、及び、Ｓ３１２６Ｃ→Ｓ１１２６Ｃ）、受注するか否かを判断する。そして、受注する場合、読影医（本例では、読影医３００Ａ）は、例えば、依頼概要確認画面における「受注する」ボタンをクリックすることで、受注を承認する（ステップＳ３１２７Ａ→Ｓ１１２７Ａ）。なお、図３５には、読影医３００Ａが最初に受注を承認した場合が例示されている。

次に、受注管理サーバ１１０の情報格納通知部１１５は、１以上の受注候補者の中から最初に受注を承認した読影医（この場合は読影医３００Ａ）を特定し、この読影医３００Ａを受注者として決定する（ステップＳ１１２７－１）。そして、情報格納通知部１１５は、受注者として決定された読影医３００Ａ以外の読影医３００Ｂ及び３００Ｃに対し、受注者が決定済みであることを通知する（ステップＳ１１２７－２→Ｓ３１２７Ｂ／Ｓ３１２７Ｃ）。

このように、１以上の受注候補者の中から１の受注者が決定されると、本実施形態では、第１の実施形態において図１３～図１４を用いて説明した動作と同様の動作を実行することで、読影医３００Ａにより作成された読影レポートが、情報格納サーバ１２０の記憶部１２４内に確保された格納領域１２５を介して依頼者である医療機関２００へ提供される。

以上のように、本実施形態によれば、受注候補者が複数である場合でも、セキュアに情報を格納することが可能な格納領域１２５を介して依頼者（医療機関２００）と受注者（読影医３００Ａ、３００Ｂ又は３００Ｃ）との間で患者の個人情報や読影レポートなどの秘匿性の高い情報の受け渡しが可能となるため、情報の秘匿性が保たれたセキュアの遠隔画像診断総合支援システム２を実現することが可能となる。

その他の構成、動作及び効果は、第１の実施形態に係るそれらと同様であってよいため、ここでは詳細な説明を省略する。

（第２の実施形態の変形例）
次に、第２の実施形態の変形例、すなわち、１の依頼者に対して１以上の受注候補者が存在する場合の他の形態について、図面を用いて説明する。本変形例に係る遠隔画像診断総合支援システムは、図３４に例示した遠隔画像診断総合支援システム２と同様であってよい。ただし、本変形例では、図３５に例示した動作が、図３６に例示する動作に置き換えられてよい。

図３６に示すように、本実施形態では、先ず、第１の実施形態において図９～図１１を用いて説明した動作と同様の動作を実行することで、情報格納サーバ１２０の記憶部１２４内に確保された格納領域１２５に依頼情報が格納される。そして、第２の実施形態において図３５のステップＳ１２２２～Ｓ１１２４－１を用いて説明した動作と同様の動作を実行することで、今回の依頼の受注候補者となる１以上の読影医３００Ａ～３００Ｃ（具体的には、受注者に関する情報）に関する情報それぞれのうちの少なくとも連絡先（例えば、電子メールアドレス）が受注管理サーバ１１０へ通知される。

次に、受注管理サーバ１１０の情報格納通知部１１５は、ユーザ管理サーバ１４０から通知された１以上の読影医３００Ａ～３００Ｃに対する優先順位を決定する（ステップＳ１１２４－２）。なお、優先順位は、例えば、依頼内容や受注者ＤＢ１４３において管理されている受注者ごとの受注分野や受注実績や対応可能な医用画像解析ソフトなどに基づいて情報格納通知部１１５が決定してもよいし、予め決定されて受注者ＤＢ１４３において管理されていてもよい。

優先順位が決定されると、情報格納通知部１１５は、先ず、最も優先順位の高い読影医（本例では読影医３００Ａ）へ、依頼があったことを通知する（ステップＳ１１２５Ａ－２→Ｓ３１２５Ａ－２）。なお、通知により読影医３００Ａが誘導される依頼概要確認画面は、図２４に例示したものと同様であってよい。

依頼があったことが通知された読影医３００Ａは、受注者クライアント３１０Ａを用いて通知されたＵＲＬから依頼概要確認画面を確認し（ステップＳ３１２６Ａ－２→Ｓ１１２６Ａ－２）、受注するか否かを判断する。そして、受注しない場合、読影医３００Ａは、例えば、依頼概要確認画面における「受注しない」ボタンをクリックすることで、受注しないことを受注管理サーバ１１０へ通知する（ステップＳ３１２７Ａ－２→Ｓ１１２７Ａ－２）。

このように、優先順位が１つ高い受注候補者が受注を拒否した場合、受注管理サーバ１１０の情報格納通知部１１５は、次に優先順位の高い読影医（本例では読影医３００Ｂ）へ、依頼があったことを通知する（ステップＳ１１２５Ｂ－２→Ｓ３１２５Ｂ－２）。これに対し、読影医３００Ｂは、受注者クライアント３１０Ｂを用いて通知されたＵＲＬから依頼概要確認画面を確認（ステップＳ３１２６Ｂ－２→Ｓ１１２６Ｂ－２）して受注するか否かを判断し、受注する場合は、例えば、依頼概要確認画面における「受注する」ボタンをクリックすることで、受注を承認する（ステップＳ３１２７Ｂ－２→Ｓ１１２７Ｂ－２）。

このように、１以上の受注候補者の中から１の受注者が決定されると、本実施形態では、第１の実施形態において図１３～図１４を用いて説明した動作と同様の動作を実行することで、読影医３００Ｂにより作成された読影レポートが、情報格納サーバ１２０の記憶部１２４内に確保された格納領域１２５を介して依頼者である医療機関２００へ提供される。

以上のように、本実施形態によれば、受注候補者が複数である場合でも、セキュアに情報を格納することが可能な格納領域１２５を介して依頼者（医療機関２００）と受注者（読影医３００Ａ、３００Ｂ又は３００Ｃ）との間で患者の個人情報や読影レポートなどの秘匿性の高い情報の受け渡しが可能となるため、情報の秘匿性が保たれたセキュアの遠隔画像診断総合支援システム２を実現することが可能となる。

その他の構成、動作及び効果は、第１又は第２の実施形態に係るそれらと同様であってよいため、ここでは詳細な説明を省略する。

＜第３の実施形態＞
次に、本開示の第３の実施形態について、図面を参照して詳細に説明する。なお、以下の説明では、明確化のため、第１又は第２の実施形態若しくはその変形例に係る構成、動作及び効果と同様の構成、動作及び効果については、それらを引用することで重複する説明を省略する。

上述した実施形態及びその変形例では、医療分野において依頼者と受注者との間で患者の個人情報などの特に機密性の高い情報をやり取りする場合を例示した。これに対し、本実施形態では、上述した実施形態を一般化してｅコマース市場に適用した場合について、例を挙げて説明する。

なお、一般化とは、依頼者を一般消費者（プロフェッショナルとアマチュアとを問わない）とし、受注者を専門家とし、依頼内容を一般的な内容とすることであってよい。一般化することにより、例えば、ピアノやギターやバイオリンなどの楽器のレッスンやコーチングの依頼、ゴルフや野球やサッカーやビリアードやクラシックバレーや社交ダンスなどのスポーツのレッスンやコーチングの依頼、絵画や書道やカラオケなどのレッスンやコーチングの依頼、英会話や英語スピーチなどの外国語のレッスンの依頼、作詞や作曲や編曲などの依頼、小説や漫画などの製作や編集や校閲の依頼、アプリの製作やデバッグの依頼など、画像データや映像データや音声データや文書データなどの種々のデータを依頼者と受注者との間でやり取りし得る種々のカテゴリのｅコマースに対して、本実施形態に係る依頼支援システムを適用することが可能となる。

従来、小説や漫画や楽曲（以下、製作物ともいう）の校閲や編集などを受ける場合、作者は製作物をＣＤ（Compact Disc）－ＲＯＭ（Read Only Memory）やＵＳＢ（Universal Serial Bus）メモリなどの記憶メディアに保存し、この記憶メディアを編集者へ直接又は郵送で届けるか、若しくは、メールなどに添付して送付していた。しかしながら、このような方法では、記憶メディアの紛失や盗難、メールからの漏洩などにより、発表前の著作物が消失したり意図せずに公表されてしまったりする可能性があるという問題が存在した。

また、近年では、上述したようなスポーツや音楽などのレッスンやコーチングをビデオ通話などを利用して行う、いわゆるオンラインレッスンが普及し始めている。ただし、オンラインレッスンは、先生と生徒とを同じ時間拘束するという課題が存在する。そこで、生徒がスポーツや音楽などを実演している動画や自作した絵画や書道など又はそのコピーや写真を先生へ送付し、これを視聴した先生から後ほどレッスンやコーチングを受ける、いわゆるオフラインレッスンに対する需要が増してきている。しかしながら、オフラインレッスンでは、製作物の校閲や編集などの依頼と同様に、記憶メディアの紛失や盗難、メールからの漏洩などにより、本人が公表を望まないものが意図せずに公表されてしまう可能性があるという問題が存在した。

そこで本実施形態は、上記問題に鑑み成されたものであり、オフラインでのレッスンやコーチングの依頼における情報の秘匿性を高めることが可能な依頼支援装置、依頼支援方法及びプログラムを提供することを目的とする。

図３７は、本実施形態に係る依頼支援サービスを実現するための依頼支援システムの概略構成例を示す図である。図３７に示すように、本実施形態に係る依頼支援システム３は、例えば、図１に例示した遠隔画像診断総合支援システム１と同様の構成において、医療機関２００が一般消費者５００に、読影医３００が専門家６００に、それぞれ置き換えられた構成を備える。一般消費者５００は依頼者クライアント５１０を用いてサービス提供サイト１００へアクセスし、専門家６００は受注者クライアント６１０を用いてサービス提供サイト１００へアクセスすることができる。依頼者クライアント５１０及び受注者クライアント６１０は、第１の実施形態に係る依頼者クライアント２１０及び受注者クライアント３１０と同様であってよい。

以上のような構成において、依頼者である一般消費者５００は、第１又は第２の実施形態における医療機関２００と同様に、依頼者クライアント５１０を用いて専門家６００への依頼をサービス提供サイト１００に登録する。一方、受注者である専門家６００は、第１又は第２の実施形態における読影医３００と同様に、受注者クライアント６１０を用いて専門家６００からの依頼を受注し、成果物をサービス提供サイト１００に格納する。そして、一般消費者５００は、依頼者クライアント５１０を用いてサービス提供サイト１００へアクセスし、登録された成果物を取得する。

一般消費者５００からサービス提供サイト１００への依頼の登録から、専門家６００による依頼の受注及びサービス提供サイト１００への成果物の格納、及び、一般消費者５０によるサービス提供サイト１００からの成果物の取得までの流れは、第１若しくは第２の実施形態又はその変形例と同様であってよい。

ただし、本実施形態では、第１の実施形態において読影対象とされた医用画像が、楽器の演奏やスポーツ（例えば、ゴルフのスイング）を行っている映像データや、歌声や演奏などの音声データや、小説や漫画やプログラムなどの文書データなど、専門家６００が解析してアドバイスなどをする対象となるデータ（依頼データともいう）に置き換えられてよい。

また、第１の実施形態において例示した依頼管理テーブル１１６、依頼者ＤＢ１４２及び受注者ＤＢ１４３に格納される各項目が、依頼内容のカテゴリに応じて適宜変更されてよい。

以上のように、一般化した場合でも、セキュアに情報を格納することが可能な格納領域１２５を介して、依頼者（一般消費者５００）と受注者（専門家６００）との間で、個人情報などの秘匿性の高い情報や、映像データなどの依頼者が秘密にしたい情報などの受け渡しが可能となるため、情報の秘匿性が保たれたセキュアの依頼支援システム３を実現することが可能となる。

その他の構成、動作及び効果は、第１若しくは第２の実施形態又はその変形例に係るそれらと同様であってよいため、ここでは詳細な説明を省略する。

＜ハードウエア構成＞
上述してきた実施形態及びその変形例に係る受注管理サーバ１１０、情報格納サーバ１２０、決済サーバ１３０、ユーザ管理サーバ１４０、依頼者クライアント２１０及び５１０、受注者クライアント３１０、３１０Ａ、３１０Ｂ、３１０Ｃ及び６１０等は、例えば図３８に示すような構成の情報処理装置１０００によって実現され得る。図３８は、受注管理サーバ１１０、情報格納サーバ１２０、決済サーバ１３０、ユーザ管理サーバ１４０、依頼者クライアント２１０及び５１０、受注者クライアント３１０、３１０Ａ、３１０Ｂ、３１０Ｃ及び６１０等の機能を実現する情報処理装置１０００の一例を示すハードウエア構成図である。情報処理装置１０００は、ＣＰＵ１１００、ＲＯＭ（Read Only Memory）１２００、ＲＡＭ（Random Access Memory）１３００、記録装置１４００、入出力インタフェース（Ｉ／Ｆ）１５００、及び、通信部１６００を有する。情報処理装置１０００の各部は、バス１７００によって接続される。

ＣＰＵ１１００は、ＲＯＭ１２００又は記録装置１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。例えば、ＣＰＵ１１００は、ＲＯＭ１２００又は記録装置１４００に格納されたプログラムをＲＡＭ１３００に展開し、各種プログラムに対応した処理を実行する。

ＲＯＭ１２００は、情報処理装置１０００の起動時にＣＰＵ１１００によって実行されるＢＩＯＳ（Basic Input Output System）等のブートプログラムや、情報処理装置１０００のハードウエアに依存するプログラム等を格納する。

記録装置１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を非一時的に記録する、コンピュータが読み取り可能な記録媒体である。具体的には、記録装置１４００は、プログラムデータの一例である本開示に係る各動作を実行するためのプログラムを記録する記録媒体である。

通信部１６００は、情報処理装置１０００が外部ネットワーク１６５０（例えばインターネット）と接続するためのインタフェースである。例えば、ＣＰＵ１１００は、通信部１６００を介して、他の機器からデータを受信したり、ＣＰＵ１１００が生成したデータを他の機器へ送信したりする。

入出力Ｉ／Ｆ１５００は、入出力デバイス１５５０と情報処理装置１０００とを接続するためのインタフェースである。例えば、ＣＰＵ１１００は、入出力Ｉ／Ｆ１５００を介して、キーボードやマウス等の入力デバイスからデータを受信する。また、ＣＰＵ１１００は、入出力Ｉ／Ｆ１５００を介して、ディスプレイやスピーカやプリンタ等の出力デバイスにデータを送信する。また、入出力Ｉ／Ｆ１５００は、所定の記録媒体に記録されたプログラム等を読み取るメディアインタフェースとして機能してもよい。

例えば、情報処理装置１０００が上述の実施形態に係る受注管理サーバ１１０、情報格納サーバ１２０、決済サーバ１３０、ユーザ管理サーバ１４０、依頼者クライアント２１０及び５１０、受注者クライアント３１０、３１０Ａ、３１０Ｂ、３１０Ｃ及び６１０等として機能する場合、情報処理装置１０００のＣＰＵ１１００は、ＲＡＭ１３００上にロードされたプログラムを実行することにより、受注管理サーバ１１０、情報格納サーバ１２０、決済サーバ１３０、ユーザ管理サーバ１４０、依頼者クライアント２１０及び５１０、受注者クライアント３１０、３１０Ａ、３１０Ｂ、３１０Ｃ及び６１０等の機能を実現する。また、記録装置１４００には、本開示に係るプログラム等が格納される。なお、ＣＰＵ１１００は、プログラムデータを記録装置１４００から読み取って実行するが、他の例として、外部ネットワーク１６５０を介して、他の装置からこれらのプログラムを取得してもよい。

１、２ 遠隔画像診断総合支援システム
３ 依頼支援システム
１００ サービス提供サイト
１１０ 受注管理サーバ
１１１ 依頼受付部
１１２ 依頼管理部１１２
１１３ 決済処理要求部
１１４ 格納領域作成要求部
１１５ 情報格納通知部
１１６ 依頼管理テーブル
１２０ 情報格納サーバ
１２１ 格納領域作成部
１２２ アクセス権付与部
１２３ 格納情報管理部１２３
１２４ 記憶部
１２５ 格納領域
１３０ 決済サーバ
１３１ 情報取得部
１３２ 決済処理部
１３３ 領収書発行部
１４０ ユーザ管理サーバ
１４１ ユーザ管理部
１４２ 依頼者データベース
１４３ 受注者データベース
１４４ ユーザ認証部
２００ 医療機関
２１０、５１０ 依頼者クライアント
３００、３００Ａ、３００Ｂ、３００Ｃ 読影医
３１０、３１０Ａ、３１０Ｂ、３１０Ｃ、６１０ 受注者クライアント
４００ ネットワーク
５００ 一般消費者
６００ 専門家

Claims (8)

1. 公開されたインターネットを介して外部にＤＩＣＯＭ（Digital Imaging and Communication in Medicine）形式の医用画像の読影を依頼する遠隔画像診断総合支援方法であって、
   依頼者から読影の前記依頼を受け付けると共に、前記依頼者の氏名又は名称、前記医用画像を診断する診療科、依頼医の氏名、患者名、患者年齢、患者性別、及び、モダリティを含む依頼基礎情報を前記依頼医に登録させ、
   前記依頼者により登録された前記依頼基礎情報を依頼管理テーブルに登録して前記依頼を管理し、
   前記依頼に対して前記依頼者による決済を実行し、
   前記医用画像を含む秘匿性の高い依頼情報をセキュアに格納するための格納領域を前記依頼管理テーブルを保持するサーバとは異なる前記インターネット上のサーバの記憶部に作成し、
   前記格納領域へのアクセス権を前記依頼者へ付与し、
   前記格納領域へアクセスするためのアドレスを前記依頼者へ通知し、
   前記依頼者がアップロードした前記依頼情報を前記格納領域へ格納し、
   前記格納領域へのアクセス権を前記依頼を受注した受注者へ付与し、
   前記格納領域へアクセスするための前記アドレスを前記受注者へ通知し、
   前記格納領域内の前記依頼情報を前記受注者からの要求に応じて当該受注者へダウンロードし、
   前記受注者がアップロードした前記医用画像に関する読影レポートを前記格納領域へ格納し、
   前記読影レポートをアップロードした前記受注者への振込を実行し、
   前記格納領域内の前記読影レポートを前記依頼者からの要求に応じて当該依頼者へダウンロードする
   ことを含み、
   前記決済は、前記依頼者が所定の期間内に発注した１以上の依頼の件数を管理し、前記所定の期間内に前記依頼者が発注した前記１以上の依頼の金額をまとめて当該依頼者へ請求することを含み、
   前記振込は、前記受注者が所定の期間内に受注した１以上の依頼の件数を管理し、前記所定の期間内に前記受注者が受注した前記１以上の依頼の金額をまとめて当該受注者へ振り込むことを含む、
   遠隔画像診断総合支援方法。
2. 公開されたインターネットを介して外部にＤＩＣＯＭ（Digital Imaging and Communication in Medicine）形式の医用画像の読影を依頼する遠隔画像診断総合支援方法であって、
   依頼者から読影の前記依頼を受け付けると共に、前記依頼者の氏名又は名称、前記医用画像を診断する診療科、依頼医の氏名、患者名、患者年齢、患者性別、及び、モダリティを含む依頼基礎情報を前記依頼医に登録させ、
   前記依頼者により登録された前記依頼基礎情報を依頼管理テーブルに登録して前記依頼を管理し、
   前記依頼に対して前記依頼者による決済を実行し、
   前記医用画像を含む秘匿性の高い依頼情報をセキュアに格納するための格納領域を前記依頼管理テーブルを保持するサーバとは異なる前記インターネット上のサーバの記憶部に作成し、
   前記格納領域へのアクセス権を前記依頼者へ付与し、
   前記格納領域へアクセスするためのアドレスを前記依頼者へ通知し、
   前記依頼者がアップロードした前記依頼情報を前記格納領域へ格納し、
   複数の受注候補者の優先順位を決定し、
   前記優先順位の高い受注候補者から順に前記依頼があったことを通知し、
   最初に受注を承認した受注候補者を前記依頼を受注した受注者として決定し、
   前記格納領域へのアクセス権を前記受注者へ付与し、
   前記格納領域へアクセスするための前記アドレスを前記受注者へ通知し、
   前記格納領域内の前記依頼情報を前記受注者からの要求に応じて当該受注者へダウンロードし、
   前記受注者がアップロードした前記医用画像に関する読影レポートを前記格納領域へ格納し、
   前記読影レポートをアップロードした前記受注者への振込を実行し、
   前記格納領域内の前記読影レポートを前記依頼者からの要求に応じて当該依頼者へダウンロードする
   ことを含む遠隔画像診断総合支援方法。
3. 前記依頼者がアップロードした前記依頼情報を前記格納領域へ格納することは、前記依頼者がアップロードした前記依頼情報をランダムに発生した第１パスワードを用いて暗号化した後に前記格納領域へ格納するとともに前記第１パスワードを前記受注者へ通知することを含み、
   前記受注者がアップロードした前記医用画像に関する読影レポートを前記格納領域へ格納することは、前記受注者がアップロードした前記読影レポートをランダムに発生した第２パスワードを用いて暗号化した後に前記格納領域へ格納するとともに前記第２パスワードを前記依頼者へ通知することを含む
   請求項１又は２に記載の遠隔画像診断総合支援方法。
4. 前記依頼者によって前記依頼に対する前記決済が実行された場合、前記依頼者へ領収書を発行することをさらに含む請求項１又は２に記載の遠隔画像診断総合支援方法。
5. 前記依頼者に関して前記決済を実行するための支払い情報を含む第１情報を予め管理するとともに、前記受注者に関して前記振込を実行するための振込先情報を含む第２情報を予め管理することをさらに含み、
   前記決済は、管理されている前記支払い情報を用いて実行され、
   前記振込は、管理されている前記振込先情報を用いて実行される
   請求項１又は２に記載の遠隔画像診断総合支援方法。
6. 前記受注者には、複数の読影医が所属し、
   前記読影医ごとの診療科、得意分野、読影実績、得意なモダリティ、及び、読影に使用するアプリケーションのうちの少なくとも１つの情報を含む読影医情報を管理し、
   前記格納領域からダウンロードされた前記依頼情報と管理されている前記読影医情報とに基づいて、受注した前記依頼の割り当てを前記複数の読影医から決定する
   ことをさらに含む請求項１又は２に記載の遠隔画像診断総合支援方法。
7. 公開されたインターネットを介して外部にＤＩＣＯＭ（Digital Imaging and Communication in Medicine）形式の医用画像の読影を依頼するプロセッサを機能させるためのプログラムであって、
   依頼者から読影の前記依頼を受け付けると共に、前記依頼者の氏名又は名称、前記医用画像を診断する診療科、依頼医の氏名、患者名、患者年齢、患者性別、及び、モダリティを含む依頼基礎情報を前記依頼医に登録させる処理と、
   前記依頼者により登録された前記依頼基礎情報を依頼管理テーブルに登録して前記依頼を管理する処理と、
   前記依頼に対して前記依頼者による決済を実行する処理と、
   前記医用画像を含む秘匿性の高い依頼情報をセキュアに格納するための格納領域を前記依頼管理テーブルを保持するサーバとは異なる前記インターネット上のサーバの記憶部に作成する処理と、
   前記格納領域へのアクセス権を前記依頼者へ付与する処理と、
   前記格納領域へアクセスするためのアドレスを前記依頼者へ通知する処理と、
   前記依頼者がアップロードした前記依頼情報を前記格納領域へ格納する処理と、
   前記格納領域へのアクセス権を前記依頼を受注した受注者へ付与する処理と、
   前記格納領域へアクセスするための前記アドレスを前記受注者へ通知する処理と、
   前記格納領域内の前記依頼情報を前記受注者からの要求に応じて当該受注者へダウンロードする処理と、
   前記受注者がアップロードした前記医用画像に関する読影レポートを前記格納領域へ格納する処理と、
   前記読影レポートをアップロードした前記受注者への振込を実行する処理と、
   前記格納領域内の前記読影レポートを前記依頼者からの要求に応じて当該依頼者へダウンロードする処理と
   を前記プロセッサに実行させ、
   前記決済を実行する処理は、前記依頼者が所定の期間内に発注した１以上の依頼の件数を管理し、前記所定の期間内に前記依頼者が発注した前記１以上の依頼の金額をまとめて当該依頼者へ請求することを前記プロセッサに実行させ、
   前記振込を実行する処理は、前記受注者が所定の期間内に受注した１以上の依頼の件数を管理し、前記所定の期間内に前記受注者が受注した前記１以上の依頼の金額をまとめて当該受注者へ振り込むことを前記プロセッサに実行させる
   プログラム。
8. 公開されたインターネットを介して外部にＤＩＣＯＭ（Digital Imaging and Communication in Medicine）形式の医用画像の読影を依頼するプロセッサを機能させるためのプログラムであって、
   依頼者から読影の前記依頼を受け付けると共に、前記依頼者の氏名又は名称、前記医用画像を診断する診療科、依頼医の氏名、患者名、患者年齢、患者性別、及び、モダリティを含む依頼基礎情報を前記依頼医に登録させる処理と、
   前記依頼者により登録された前記依頼基礎情報を依頼管理テーブルに登録して前記依頼を管理する処理と、
   前記依頼に対して前記依頼者による決済を実行する処理と、
   前記医用画像を含む秘匿性の高い依頼情報をセキュアに格納するための格納領域を前記依頼管理テーブルを保持するサーバとは異なる前記インターネット上のサーバの記憶部に作成する処理と、
   前記格納領域へのアクセス権を前記依頼者へ付与する処理と、
   前記格納領域へアクセスするためのアドレスを前記依頼者へ通知する処理と、
   前記依頼者がアップロードした前記依頼情報を前記格納領域へ格納する処理と、
   複数の受注候補者の優先順位を決定する処理と、
   前記優先順位の高い受注候補者から順に前記依頼があったことを通知する処理と、
   最初に受注を承認した受注候補者を前記依頼を受注した受注者として決定する処理と、
   前記格納領域へのアクセス権を前記受注者へ付与する処理と、
   前記格納領域へアクセスするための前記アドレスを前記受注者へ通知する処理と、
   前記格納領域内の前記依頼情報を前記受注者からの要求に応じて当該受注者へダウンロードする処理と、
   前記受注者がアップロードした前記医用画像に関する読影レポートを前記格納領域へ格納する処理と、
   前記読影レポートをアップロードした前記受注者への振込を実行する処理と、
   前記格納領域内の前記読影レポートを前記依頼者からの要求に応じて当該依頼者へダウンロードする処理と
   を前記プロセッサに実行させるためのプログラム。
   

Images