WO2022201908A1

WO2022201908A1 - 医療情報処理システムおよび方法、医療情報処理サービス提供方法ならびにプログラム

Info

Publication number: WO2022201908A1
Application number: PCT/JP2022/004575
Authority: WO
Inventors: 大暉上原
Original assignee: 富士フイルム株式会社
Priority date: 2021-03-24
Filing date: 2022-02-07
Publication date: 2022-09-29
Also published as: DE112022000944T5; US20230409390A1; JPWO2022201908A1

Abstract

サーバ等の運用費を抑えつつ、救急系処理と非救急系処理との双方の処理要求について、それぞれ許容可能な待ち時間内で処理結果を提供可能な医療情報処理システムおよび方法、医療情報サービス提供方法ならびにプログラムを提供する。複数の仮想マシンを用いて構成されるサーバクラスターを備える医療情報処理システムであって、受け付けた処理要求の種別に応じて処理要求を非救急系処理要求キューまたは救急系処理要求キューに振り分ける第１の制御部と、非救急系処理要求キューに積まれた非救急系処理要求に対応した処理を行う非救急系処理モジュールと、救急系処理要求キューに積まれた救急系処理要求に対応した処理を行う救急系処理モジュールと、これら処理モジュールの個数を制御する第２の制御部と、を備え、第２の制御部による制御は、稼働中の複数の非救急系処理モジュールの一部を一時停止させ、かつ、新たに救急系処理モジュールを起動させることを含む。

Description

医療情報処理システムおよび方法、医療情報処理サービス提供方法ならびにプログラム

　本開示は、医療情報処理システムおよび方法、医療情報処理サービス提供方法ならびにプログラムに係り、特に複数の医療機関から医療情報の処理要求を受け付け、処理要求に応じた処理を実行して処理結果を要求元に返す医療情報処理に好適なコンピュータシステムおよび情報処理技術に関する。

　医療分野においては、ＣＴ（Computed Tomography）装置およびＭＲＩ（Magnetic Resonance Imaging）装置等の画像診断装置の進歩により、質の高い高解像度の医用画像を用いての画像診断が可能となってきている。特に、近年は深層学習により学習がなされたニューラルネットワークを利用した人工知能（Artificial Intelligence：ＡＩ）を用いることにより、画像から病変領域などを認識したり、病名などの分類を特定したりするための解析処理の精度が向上している。

　このようなコンピュータ支援診断（Computer Aided Diagnosis, Computer Aided Detection ：ＣＡＤ）等の解析処理は、例えば、肺、心臓、肝臓および脳等の部位毎に、さらには検出可能な病変毎に用意されることが多く、これらの解析処理を実行するためには、高性能なコンピュータが必要になる。特許文献１には、クラウドシステムを利用して医用画像の解析処理サービスを提供する仕組みが提案されている。

　特許文献２には、複数のジョブを同時に実行するコンピュータシステムにおいて、優先度の低いジョブを停止させ、その優先度が低いジョブが使用していたリソースを、優先度が高いジョブに割り当てて実行するためのジョブスケジューリング方法が開示されている。

特開２０１８－０９２３１１号公報特開２０２０－０２４６３６号公報

　例えば、肺ＣＡＤなど各種の医用画像処理機能をＷｅｂサービスとして提供するために各医療機関専用の画像処理サーバを確保すると、物理的サーバおよび仮想サーバを問わず、施設毎のサーバ運用費が高額になる。このため、画像処理については中央処理サーバのようなものを設けて、複数の医療機関で処理リソース（計算資源）を共有するような構成にすることが、運用コストを下げ、サービス提供をより安価に行えるようにするために必要である。

　複数の医療機関で処理リソースを共有する中央処理サーバ型の構成を採用すると、複数の医療機関から１つのシステムに対して処理要求が送信されるようになる。このような構成の問題点の１つは、例えば、緊急度の低い検査画像に対する処理によって中央処理サーバのリソースが逼迫している場合に、緊急度の高い救急現場からの画像処理要求が処理開始待ちになってしまい、緊急度の高い救急系の処理が、緊急度の低い通常系の処理によってなかなか実行できないという状況が発生し得ることである。

　このような課題に対して、緊急度の高い救急系の処理要求を優先して実行するという対応が考えられる。しかし、緊急度の高い処理要求ばかり優先して処理を実行すると、緊急度の低い処理が長期間実行されず、通常診療に影響を与えることも容易に予想される。

　特許文献２に記載の発明では、クライアントからの処理要求群の優先度に応じてどのように優先度が低いジョブを停止させ、より優先度が高いジョブへ計算資源を割り当てるかの方法が提案されている。しかし、特許文献２には、それぞれのジョブの許容最大待ち時間を担保するための仕組みがない。このため、特許文献２に記載の技術を、医療画像の解析処理サービスに適用した場合、例えば、優先度が低いジョブが通常診療系の処理要求であり、優先度が高いジョブが救急系の処理要求であるとした場合、救急系処理要求が連続して多数クライアントから送信された場合、通常診療系の処理が許容最大待ち時間を超えて待たされる可能性もあり、通常の診療等の業務に影響を与えてしまう。このため特許文献２に記載されている仕組みは、医療系処理には適さない。

　このような問題の解決策として、例えば、緊急度の高い救急向けの処理専用のサーバを用意しておき、救急系の処理要求はこの救急系処理専用サーバ宛に送信するというような対策が考えられる。しかし、救急系の処理は、その必要とされる頻度が散発的である場合が多く、常時救急向けの専用サーバを維持しておくと、確保した計算資源が余っているような状況が発生し、運用費が不必要に発生することでサービス利用料も結果的に高額になってしまうため望ましくない。

　また、別の解決策として、緊急度の高い処理要求が発生し次第、緊急度の高い処理用の仮想マシンを立ち上げるというような処理も考えられる。しかし、通常、仮想マシンの立ち上げには数分程度かかる場合もあるため、一刻を争う救急医療の現場等では望ましくない。

　本開示はこのような事情に鑑みてなされたものであり、サーバ等の運用費をできるだけ抑えつつ、緊急度の高い救急系処理と、緊急度の低い非救急系処理との双方について、それぞれ許容可能な待ち時間内で処理結果を提供することが可能となる医療情報処理システムおよび方法、医療情報サービス提供方法ならびにプログラムを提供することを目的とする。

　本開示の一態様に係る医療情報処理システムは、処理対象の医療情報と処理要求とを受け付け、処理要求に応じた処理を実行して処理結果を出力する医療情報処理システムであって、複数の仮想マシンを用いて構成されるサーバクラスターを備え、サーバクラスターは、処理要求を受け取り、処理要求が非救急に分類される処理を求める非救急系処理要求であるか、救急に分類される処理を求める救急系処理要求であるかに応じて、処理要求を非救急系処理要求キューまたは救急系処理要求キューに振り分ける第１の制御部と、非救急系処理要求キューを監視し、非救急系処理要求キューにスタックされた非救急系処理要求の指示内容に対応した非救急系の処理を行う非救急系処理モジュールと、救急系処理要求キューを監視し、救急系処理要求キューにスタックされた救急系処理要求の指示内容に対応した救急系の処理を行う救急系処理モジュールと、第１の制御部が受け取った救急系処理要求の数と稼働中の救急系処理モジュールの個数とに基づき、稼働させる非救急系処理モジュールの個数と救急系処理モジュールの個数とを制御する第２の制御部と、を備え、第２の制御部による制御は、稼働中の複数の非救急系処理モジュールのうちの一部を一時停止させ、かつ、新たに救急系処理モジュールを起動させて救急系処理モジュールの個数を増加させることを含む。

　本態様によれば、救急系処理要求の需要に応じて、サーバクラスター上で稼働する非救急系処理モジュールの個数と救急系処理モジュールの個数とを動的に調整することができる。救急系処理要求が増大した場合、稼働中の複数の非救急系処理モジュールのうちの一部を一時停止させて、そのリソースを用いて救急系処理モジュールの個数を増やし、救急系処理要求の需要に対処する。また、一時停止させる非救急系処理モジュールは一部の処理モジュールであり、他の一部の非救急系処理モジュールについては稼働状態が維持される。これにより、使用する計算資源を抑制しつつ、救急系処理と、非救急系処理との双方について、許容可能な待ち時間以内に処理結果を提供することが可能となる。

　本開示の他の態様に係る医療情報処理システムにおいて、第２の制御部は、第１の制御部が受け取った救急系処理要求の数と稼働中の救急系処理モジュールの個数とから、救急系処理要求に対する処理完了までの第１の処理待ち時間を計算し、第１の処理待ち時間が第１の許容待ち時間を超える場合に、第１の処理待ち時間を第１の許容待ち時間以内に収めるために救急系処理モジュールの個数を増加させる構成であってもよい。

　本開示の他の態様に係る医療情報処理システムにおいて、第２の制御部は、非救急系処理要求に対する処理完了までの第２の待ち時間が第２の許容待ち時間以内に収まる範囲で非救急系処理モジュールを一時停止させてよい個数の上限を動的に計算し、上限を超えない個数の非救急系処理モジュールを一時停止させ、代わりに救急系処理モジュールを新たに起動させる構成であってもよい。

　本開示の他の態様に係る医療情報処理システムにおいて、第２の制御部は、救急系処理モジュールの個数を増加させるために、仮想マシンの台数を増加させ、追加した仮想マシン上で複数の救急系処理モジュールを新たに起動させる構成であってもよい。

　本開示の他の態様に係る医療情報処理システムにおいて、第２の制御部は、処理待機中の救急系処理モジュールの個数が規定個数以上である状態が規定時間以上維持された場合に、救急系処理モジュールの個数を減少させる構成であってもよい。

　本開示の他の態様に係る医療情報処理システムにおいて、第２の制御部は、処理待機中の救急系処理モジュールの個数が第１の規定数以上である状態が第１の規定時間以上維持された場合に、非救急系処理モジュールの一時停止を伴って追加した救急系処理モジュールの個数を減少させ、かつ、一時停止させていた非救急系処理モジュールを再開させる構成であってもよい。

　本開示の他の態様に係る医療情報処理システムにおいて、第２の制御部は、処理待機中の救急系処理モジュールの個数が第２の規定数以上である状態が第２の規定時間以上維持された場合に、追加した仮想マシン上の救急系処理モジュールの個数を減少させ、追加した仮想マシンの台数を減少させる構成であってもよい。

　本開示の他の態様に係る医療情報処理システムにおいて、第２の制御部は、処理待機中の救急系処理モジュールの個数が第１の規定数以上である状態が第１の規定時間以上維持された場合に、非救急系処理モジュールの一時停止を伴って追加した救急系処理モジュールの個数を減少させ、かつ、一時停止させていた非救急系処理モジュールを再開させ、一時停止させていた非救急系処理モジュールを全て再開させた後に、追加した仮想マシン上の救急系処理モジュールの個数を減少させ、追加した仮想マシンの台数を減少させる構成であってもよい。

　本開示の他の態様に係る医療情報処理システムにおいて、サーバクラスターは、非救急系処理要求および救急系処理要求のそれぞれについて、処理要求を受け付けた場合の現在の処理待ち時間を計算し、現在の処理待ち時間の情報を、医療機関の利用端末に提供する構成であってもよい。

　本開示の他の態様に係る医療情報処理システムにおいて、非救急系処理要求に対する処理完了までの最大待ち時間が第３の待ち時間であり、かつ、救急系処理要求に対する処理完了までの最大待ち時間が第３の待ち時間よりも短い第４の待ち時間であることを約束する第１のプランと、非救急系処理要求に対する処理完了までの最大待ち時間および救急系処理要求に対する処理完了までの最大待ち時間の少なくとも一方が第１のプランの最大待ち時間よりも短い待ち時間であることを約束する第２のプランと、が用意され、サーバクラスターは、第１のプランを選択している医療機関からの処理要求の処理に割り当てられる第１のプラン用の非救急系処理モジュール、救急系処理モジュールおよび仮想マシンに加え、第２のプランを選択している医療機関からの処理要求の処理に割り当てられる第２のプラン用の非救急系処理モジュール、救急系処理モジュールおよび仮想マシンを備える構成であってもよい。

　この態様の場合、第１のプラン用の非救急系処理モジュール、救急系処理モジュールおよび仮想マシンは、第２のプランを選択している医療機関からの処理要求の処理にも使用されてよい。

　本開示の他の態様に係る医療情報処理システムにおいて、サーバクラスターは、第２のプランを選択する医療機関の数の増減に応じて、第２のプラン用の非救急系処理モジュールの個数、救急系処理モジュールの個数および仮想マシンの台数を増減させる構成であってもよい。

　本開示の他の態様に係る医療情報処理システムは、処理対象の医療情報と処理要求とを受け付け、処理要求に応じた処理を実行して処理結果を出力する医療情報処理システムであって、１つ以上のプロセッサと、１つ以上のプロセッサが実行するプログラムを記憶する１つ以上の記憶装置とを備え、１つ以上のプロセッサは、プログラムの命令に従い、複数の仮想マシンを用いて構成されるサーバクラスターとして動作し、サーバクラスターによって実行される処理は、処理要求を受け取り、処理要求が非救急に分類される処理を求める非救急系処理要求であるか、救急に分類される処理を求める救急系処理要求であるかに応じて、処理要求を非救急系処理要求キューまたは救急系処理要求キューに振り分ける処理要求分配制御と、非救急系処理要求キューを監視し、非救急系処理要求キューにスタックされた非救急系処理要求の指示内容に対応した非救急系の処理を行う非救急系処理モジュールとしての処理と、救急系処理要求キューを監視し、救急系処理要求キューにスタックされた救急系処理要求の指示内容に対応した救急系の処理を行う救急系処理モジュールとしての処理と、サーバクラスターが受け取った救急系処理要求の数と稼働中の救急系処理モジュールの個数とに基づき、稼働させる非救急系処理モジュールの個数と救急系処理モジュールの個数とを制御する計算資源使用状況制御と、を含み、計算資源使用状況制御は、稼働中の複数の非救急系処理モジュールのうちの一部を一時停止させ、かつ、新たに救急系処理モジュールを起動させて救急系処理モジュールの個数を増加させる処理を含む。

　本開示の他の態様に係る医療情報処理サービス提供方法は、本開示の医療情報処理システムを用いて実施される医療情報処理サービス提供方法であって、サーバクラスターが、通信回線を介して複数の医療機関から処理要求を受け付けることと、サーバクラスターが、処理要求に対応する処理を実行して処理結果を処理要求の要求元の医療機関に返すこととを含む。

　本開示の他の態様に係る医療情報処理方法であって、コンピュータが処理対象の医療情報と処理要求とを受け付け、処理要求に応じた処理を実行して処理結果を出力する処理を行うためにコンピュータによって実行される医療情報処理方法であって、コンピュータ上に構築される複数の仮想マシンを用いてサーバクラスターを構成することと、サーバクラスターが、処理要求を受け取り、処理要求が非救急に分類される処理を求める非救急系処理要求であるか、救急に分類される処理を求める救急系処理要求であるかに応じて、処理要求を非救急系処理要求キューまたは救急系処理要求キューに振り分ける第１の制御を行うことと、非救急系処理要求キューを監視し、非救急系処理要求キューにスタックされた非救急系処理要求の指示内容に対応した非救急系の処理を行う非救急系処理モジュールとしての処理を行うことと、救急系処理要求キューを監視し、救急系処理要求キューにスタックされた救急系処理要求の指示内容に対応した救急系の処理を行う救急系処理モジュールとしての処理を行うことと、サーバクラスターが受け取った救急系処理要求の数と稼働中の救急系処理モジュールの個数とに基づき、稼働させる非救急系処理モジュールの個数と救急系処理モジュールの個数とを制御する第２の制御を行うことと、を含み、第２の制御は、稼働中の複数の非救急系処理モジュールのうちの一部を停止させ、かつ、新たに救急系処理モジュールを起動させて救急系処理モジュールの個数を増加させることを含む。

　本開示の他の態様に係るプログラムは、コンピュータが処理対象の医療情報と処理要求とを受け付け、処理要求に応じた処理を実行して処理結果を出力する処理をコンピュータに実現させるためプログラムであって、コンピュータ上に構築される複数の仮想マシンを用いてサーバクラスターを構成し、サーバクラスター上において、処理要求を受け取り、処理要求が非救急に分類される処理を求める非救急系処理要求であるか、救急に分類される処理を求める救急系処理要求であるかに応じて、処理要求を非救急系処理要求キューまたは救急系処理要求キューに振り分ける第１の制御機能と、非救急系処理要求キューを監視し、非救急系処理要求キューにスタックされた非救急系処理要求の指示内容に対応した非救急系の処理を行う非救急系処理モジュールの機能と、救急系処理要求キューを監視し、救急系処理要求キューにスタックされた救急系処理要求の指示内容に対応した救急系の処理を行う救急系処理モジュールの機能と、第１の制御機能によりサーバクラスターが受け取った救急系処理要求の数と稼働中の救急系処理モジュールの個数とに基づき、稼働させる非救急系処理モジュールの個数と救急系処理モジュールの個数とを制御する第２の制御機能と、を実現させ、第２の制御機能は、稼働中の複数の非救急系処理モジュールのうちの一部を停止させ、かつ、新たに救急系処理モジュールを起動させて救急系処理モジュールの個数を増加させる機能を含む、プログラムである。

　本開示によれば、救急系処理要求の需要状況に応じて、サーバクラスター上で稼働する救急系処理モジュールと非救急系処理モジュールのそれぞれの個数を適応的に制御することができる。これにより、仮想マシンを含むシステムを構築するサーバ等の運用費を抑制しつつ、緊急度の高い救急系処理と、緊急度の低い非救急系処理との双方について、それぞれの許容可能な待ち時間内で処理結果を提供することが可能になる。

図１は、実施形態に係る医療情報処理システムの構成を示すブロック図である。図２は、実施形態に係る医療情報処理システムの動作の概要を示すブロック図であり、救急系処理要求が無く、かつ、通常プラン契約者のみである場合の例を示す。図３は、実施形態に係る医療情報処理システムの動作の概要を示すブロック図であり、救急系処理要求があり、計算サーバの増加処理が無く、かつ、通常プラン契約者のみである場合の例を示す。図４は、実施形態に係る医療情報処理システムの動作の概要を示すブロック図であり、救急系処理要求があり、計算サーバの増加処理があり、かつ、通常プラン契約者のみである場合の例を示す。図５は、実施形態に係る医療情報処理システムの動作の概要を示すブロック図であり、救急系処理要求があり、計算サーバの増加処理があり、かつ、高速プラン契約者が存在する場合の例を示す。図６は、医療情報処理システムを利用する複数の医療機関の医療機関内情報システムの例を示すブロック図である。図７は、実施形態に係る医療情報処理システムによって実行される医療情報処理方法の例を示すフローチャートである。図８は、図７のステップＳ２０に適用されるサブルーチンの例を示すフローチャートである。図９は、救急系処理要求の需要減に対応した救急系処理モジュールの個数削減制御の例を示すフローチャートである。図１０は、コンピュータのハードウェア構成の例を示すブロック図である。

　以下、添付図面に従って本発明の好ましい実施形態について説明する。

　《医療情報処理システムの概要》
　図１は、実施形態に係る医療情報処理システム１０の構成を示すブロック図である。医療情報処理システム１０は、通信回線２０を介して複数の医療機関から医用画像などの処理対象の医療情報と、その医療情報に対する処理要求とを受け付け、処理要求に応じた処理を実行して処理結果を要求元の医療機関へ返すＷｅｂサービスを提供する医療系処理サーバクラスターを含むコンピュータシステムである。

　本実施形態では、医用画像の処理サービスを提供するシステムを例示するが、処理対象の医療情報は、医用画像に限らず、ゲノムデータ、心電図の波形データ、血液検査データあるいは音声データなど、画像以外の医療データであってもよく、複数種類のデータの組み合わせであってもよい。

　医療系処理とは、救急系か、救急系以外の通常系かに分類できる医療機器向けアプリケーション関連処理のことを指す。本明細書において「通常」という用語は、「非救急」と同義である。医療系処理には、例えば、ＣＴ装置あるいはＭＲＩ装置などの医療機器を用いて撮影される医用画像を処理して病変の検出あるいはセグメンテーションもしくはラベリングなどを行う医用画像処理が含まれる。医療系処理は、医療情報処理の一例であり、医用画像は医療情報の一例である。

　通信回線２０は、インターネットを含むワイドエリアネットワークであってよい。図１に示す「医療機関１」、「医療機関２」・・・「医療機関Ｌ」の表示は、Ｌ個の医療機関が存在していることを表している。医療機関は、例えば、病院、診療所、医療研究センター、医療健診センターなどである。以下、各医療機関を識別するインデックスをｊとし、医療機関ＭＩｊのように表記する。ｊは１からＬまでの整数（ｊ＝１，２・・・Ｌ）を表す。

　各医療機関ＭＩｊは医療機関内ネットワークを有し、医療機関ＭＩｊ毎に、１つ以上の利用端末３０がそれぞれの医療機関内ネットワークに接続される。利用端末３０は、各医療機関内ネットワーク内に存在する情報処理装置であって、医療情報処理システム１０の医療系処理サーバクラスターによって提供される処理サービスを利用するための端末である。ここで利用端末３０とは、安全に医療機関内のデータにアクセスできるネットワーク内に存在する計算資源を指しており、その利用端末３０は物理的に医療機関内に存在しなくてもよい。利用端末３０は、物理マシンであってもよいし、仮想マシンであってもよく、具体的な形態は限定されない。利用端末３０は、ワークステーションであってもよいし、パーソナルコンピュータであってもいし、タブレット端末などであってもよい。

　利用端末３０には、医療情報処理システム１０の処理機能を利用するためのクライアントソフトウェアが構築される。ここでクライアントソフトウェアとは、医療情報処理システム１０の医療系処理サーバクラスターが提供する画像処理サービスを利用できるものであればよく、その形態は問わない。クライアントソフトウェアは、専用のアプリケーションであってもよいし、汎用的なＷｅｂブラウザーなどであってもよい。

　医療情報処理システム１０として機能する医療系処理サーバクラスターは、仮想マシンを用いて構成される。この仮想マシンの展開先は、仮想マシン群をホスティングできる環境であればよく、例えば、クラウドコンピューティング環境であってもよい。図１には、複数の仮想マシンＶＭ０，ＶＭ１，ＶＭ２・・・ＶＭｋ・・・を含む仮想マシンクラスターを示す。以下、各仮想マシンを識別するインデックスをｋとし、仮想マシンＶＭｋのように表記する。ｋは０以上の整数である。仮想マシンの台数は必要に応じて増加させたり、減少させたりすることが可能である。仮想マシンクラスターは１台の物理マシン上に構築されてもよいし、複数台の物理マシン上に構築されてもよい。

　仮想マシンＶＭｋを用いて医療系処理サーバクラスターを構築後、このクラスター上に、医用画像処理のＷｅｂサービスを提供するために必要な処理要求分配制御部１０２と、計算資源使用状況制御部１０４と、通常系処理要求キュー１０６と、救急系処理要求キュー１０８と、通常系処理モジュールＮＭと、救急系処理モジュールＥＭとが展開される。なお、これらのモジュールを展開直後で医療情報処理システム１０が救急系処理要求を受信していない状況においては、救急系処理モジュールＥＭはその起動に必要な構成のインストールのみが行われており、起動自体はされていない。

　処理要求分配制御部１０２は、各医療機関ＭＩｊの利用端末３０からの処理要求を受け付け、その処理要求の種別に応じて、通常系処理要求キュー１０６または救急系処理要求キュー１０８に処理要求を振り分ける。すなわち、処理要求分配制御部１０２は、受信した処理要求が通常系の処理を求める処理要求であるか、救急系の処理を求める処理要求であるかを判別し、判別した処理要求の種別に応じて、通常系処理要求キュー１０６または救急系処理要求キュー１０８に処理要求を送信する。

　通常系処理要求キュー１０６は、救急系の処理要求以外の処理要求を一時的に格納（スタック）するキューである。救急系処理要求キュー１０８は、救急系の処理要求を一時的に格納するキューである。

　本明細書において、救急現場などからの緊急度の高い救急系の処理要求を「救急系処理要求」といい、通常診療の検査などのように緊急度の低い通常系の処理要求を「通常系処理要求」という。緊急度は「優先度」と言い換えてもよい。利用端末３０から発せられる処理要求は、通常系処理要求または救急系処理要求のいずれかに分類される。救急系処理要求に対応する救急系の処理を「救急系処理」といい、通常系処理要求に対応する通常系の処理を「通常系処理」という。救急系処理の処理内容と、通常系処理の処理内容とは異なるものであってよい。例えば、通常系処理は、肺ＣＡＤ処理を含み、救急系処理は、気胸領域の検出処理、脳梗塞検出処理、あるいは脳出血検出処理などを含む。

　計算資源使用状況制御部１０４は、処理要求分配制御部１０２に送信されてくる処理要求の種別と、通常系処理要求キュー１０６および救急系処理要求キュー１０８のそれぞれの処理要求キューに滞留している処理要求数とを監視し、救急系処理要求の要求状況および処理状況に応じて、稼働中の通常系処理モジュールＮＭの一時停止および救急系処理モジュールＥＭの追加起動、さらには、計算ノードの追加などを制御する。ここでの計算ノードとは、仮想マシンを用いた計算サーバである。

　図１では、仮想マシンＶＭ０に、処理要求分配制御部１０２、計算資源使用状況制御部１０４、通常系処理要求キュー１０６および救急系処理要求キュー１０８を展開し、仮想マシンＶＭ１，ＶＭ２・・・ＶＭｋ・・・に通常系処理モジュールＮＭおよび／または救急系処理モジュールＥＭを展開する例が示されている。

　通常系処理モジュールＮＭは、通常系の医用画像処理を行う処理モジュールである。図１に示す「通常系処理モジュール１」「通常系処理モジュール２」・・・「通常系処理モジュールＮ」の表示は、各計算ノード内にＮ個の通常系処理モジュールが展開されていることを示している。

　救急系処理モジュールＥＭは、救急系の医用画像処理を行う処理モジュールである。図１では「救急系処理モジュール１」のみが示されているが、救急系処理要求の要求状況および処理状況によって、各計算ノード内に複数個の救急系処理モジュールＥＭが展開され得る。

　通常系処理モジュールＮＭと救急系処理モジュールＥＭのそれぞれは、対応する処理要求キューを監視して、実行指示が届き次第、実行指示に応じた処理を行う。通常系処理モジュールＮＭは、通常系処理要求キュー１０６にスタックされた通常系処理要求の指示内容に対応した通常系の処理を行う。救急系処理モジュールＥＭは、救急系処理要求キュー１０８にスタックされた救急系処理要求の指示内容に対応した救急系の処理を行う。

　《本サービスの利用契約のタイプ》
　医療情報処理システム１０を用いて提供される医用画像処理サービスには、通常プランと高速プランとが用意されている。通常プランは、医療情報処理システム１０を使用するサービスを利用するプランの一種であり、後述の高速プランよりも多数の医療機関間で計算資源を共有するため、利用料金は高速プランよりも安価だが処理要求を出してから処理完了まで（処理結果を受け取るまで）の最大待ち時間が長い仕様のプランである。

　高速プランは、医療情報処理システム１０を使用するサービスを利用するプランの一種であり、上記の通常プランよりも利用料金は高価だが処理要求を出してから処理完了までの最大待ち時間が短い仕様のプランである。高速プラン契約者からの処理要求に対しては、通常プラン契約者よりも多く計算資源を割り当てることにより、待ち時間の短縮を図る。

　例えば、通常プランの場合、通常系処理の最大待ち時間は１０分、救急系処理の最大待ち時間は３分とし、高速プランの場合には、通常系処理の最大待ち時間は３分、救急系処理の最大待ち時間は１分とするなど、契約内容にて最大待ち時間を定める。

　通常プランにおいて定める救急系処理の最大待ち時間の３分と、高速プランにおいて定める救急系処理の最大待ち時間の１分とのそれぞれは本開示における「第１の許容待ち時間」の一例である。通常プランにおいて定める通常系処理の最大待ち時間の１０分と、高速プランにおいて定める通常系処理の最大待ち時間の３分とのそれぞれは本開示における「第２の許容待ち時間」の一例である。通常プランにおいて定める通常系処理の最大待ち時間の１０分と、救急系処理の最大待ち時間の３分とは本開示における「第３の待ち時間」と「第４の待ち時間」との一例である。

　高速プランにおける通常系処理および救急系処理のそれぞれの最大待ち時間が、通常プランのそれぞれの最大待ち時間よりも短いことが好ましい形態であるが、高速プランにおける通常系処理および救急系処理のうち少なくとも一方の最大待ち時間が通常プランのものよりも短い設定であればよい。

　各医療機関ＭＩｊは、通常プランまたは高速プランのいずれかのプランを選択して本サービスの提供者との間で利用契約を結ぶことにより、医療情報処理システム１０による医用画像処理サービスを利用することができる。通常プランは本開示における「第１のプラン」の一例である。高速プランは本開示における「第２のプラン」の一例である。

　《システム挙動の概要》
　まず、本サービスの利用者（医療機関）が通常プラン契約者のみである場合のシステム挙動について図２～図４を用いて説明する。

　〈例１〉救急系処理要求無し、通常プラン契約者のみの場合
　図２は、実施形態に係る医療情報処理システム１０の動作の概要を示すブロック図である。図２は、どの医療機関ＭＩｊからも救急系処理要求が送信されてきていない場合の例であり、通常系と救急系の２種類の処理モジュールのうち通常系処理モジュールＮＭのみがＭ台の計算サーバ上で稼働し、通常系処理要求のみが医療系処理サーバクラスター内部で処理されているときの一連の流れを表す図である。図２において、各医療機関ＭＩｊは通常プランを契約しているものとする。

　図２に示す「通常プラン用サーバ１」、「通常プラン用サーバ２」・・・「通常プラン用サーバＭ」の表示は、処理モジュール展開用の計算サーバであって、通常プラン契約者間で共有されるサーバを表す。Ｍ台の計算サーバのそれぞれを計算サーバＮＰＳ１、ＮＰＳ２・・・ＮＰＳＭと表記する。それぞれの計算サーバＮＳＰｋにおいてＮ個の通常系処理モジュールＮＭが稼働している。なお、Ｎ個の通常系処理モジュールＮＭの処理モジュール群は、異なる種類の処理を実行する処理モジュールが混在してもよい。また、異なる計算サーバ上に展開される処理モジュールの種類の組み合わせは同じであってもよいし、異なっていてもよい。

　図２中の手順［１］～[７]の流れを例に、利用者が本システムをどのように利用するかの具体例を説明する。

　手順［１］：手順［１］にて、利用者は利用端末３０上にインストールされた、本システム利用のためのクライアントソフトウェアを使用して、医療情報処理システム１０に向けて医用画像の処理要求を行う。このとき、利用端末３０から送信する処理要求が通常の検査等に関する処理要求（通常系処理要求）なのか、それとも救急現場の検査等に関する処理要求（救急系処理要求）なのかの判別は、利用者が処理要求の種別を指定することにより行ってもよいし、使用されるクライアントソフトウェア種別等を用いてプログラム的に行ってもよい。図２の例では、通常系処理要求のみが送信されて来ている想定で説明を進める。

　手順［２］：手順［２］にて、利用端末３０から医療情報処理システム１０宛に送信された処理要求は、最初に処理要求分配制御部１０２にて受信され、要求内容が解釈される。

　手順［３］：図２における手順［３］は、計算資源使用状況制御部１０４が、処理要求分配制御部１０２に入って来る処理要求の種別を監視していることを示している。計算資源使用状況制御部１０４がその機能を発現させるのは、後述する図３および図４に示した救急系処理要求を受信した場合であるので、図２の例では計算資源使用状況制御部１０４は特に動作していない。

　手順［４］：手順［４］にて、処理要求分配制御部１０２は、受信した処理要求の種別に対応するキュー（通常系処理要求キュー１０６または救急系処理要求キュー１０８）に、処理要求の内容を送信する。ここでキューはメッセージキューやリレーショナルデータベースなど、ある処理要求が処理モジュールによって処理されるまでに一時的に保存出来ればよく、その形態は問わない。処理要求分配制御部１０２は、通常系処理要求または救急系処理要求に応じて、対応するキューに処理要求を積む。

　手順［５］：手順［５］にて、通常系処理モジュールＮＭｎは通常系処理要求キュー１０６から通常系処理要求を受信する。この受信方法としては、通常系処理モジュールＮＭｎが通常系処理要求キュー１０６に新着の処理要求があれば処理開始を行えるような実装となっていれば、その実現方法は問わない。なお、通常系処理モジュールＮＭｎの表記における添字のｎは、計算サーバ上にて起動されている通常系処理モジュールを識別するインデックスである。図２の例ではｎは１からＮまでの整数を表す。

　手順［６］：通常系処理要求キュー１０６から通常系処理要求を受信した通常系処理モジュールＮＭｎは、手順［６］にて処理要求に対応する必要な処理を行う。図２の例では、通常系処理を担当する通常系処理モジュールＮＭが通常系処理要求キュー１０６から処理要求を取得して処理を行う。

　ここで、各計算サーバ上にて起動されている処理モジュールの最大数は、各処理モジュールに割り当てる必要があるＣＰＵ数およびメモリ量と、各計算サーバのＣＰＵコア数およびメモリ量の上限によって決定される。これは計算サーバ上にて起動されている処理モジュールが通常系処理モジュールＮＭであるか、救急系処理モジュールＥＭであるかといった処理モジュールの種別によらない。図２においては、各計算サーバ上で起動されている処理モジュールの最大数がＮ個である場合の例が示されている。なお、計算サーバ上で起動される処理モジュールの最大数がサーバごとに異なる構成であってもよい。

　手順［７］：手順７にて、処理要求の送信元（要求元）である利用端末３０は、医療情報処理システム１０から処理結果を取得する。各利用端末３０は、処理結果が取得可能かどうかを定期的に医療系処理サーバクラスターに問い合わせ、処理結果の取得可能であったら医療系処理サーバクラスターから結果取得を開始してもよいし、医療系処理サーバクラスター側から利用端末３０に結果取得可能になった旨を通知し、利用端末３０はその通知を受けて結果取得を開始してもよい。利用端末３０の利用者は、利用端末３０に解析結果が取得され次第、その結果を閲覧することができる。

　通常系処理要求は、通常診療などで発生するため、医療機関ごとに通常系処理要求の数は異なるものの、各医療機関における通常系処理要求の数が１日のうちに大きく増減するということはあまりなく、利用する医療機関の数が固定されれば定常的にどの程度の数の通常系処理要求が送信されるかがおおよそ固定される性質のものである。このため、本実施形態に係る医療情報処理システム１０が定常的に稼働させる計算サーバの台数の最小値は、利用契約中の医療機関の数と、ピーク時に見込まれる各医療機関の最大通常系処理要求数と、ピーク時の通常系処理要求に対する処理完了までの最大許容待ち時間とを勘案し、必要十分な台数を求め、これを最小値として採用する。

　図２に示す通常プラン用サーバの台数（Ｍ台）のＭは、このような観点から求まった最小値を表しており、救急系処理要求がない状況において、常時Ｍ台の計算サーバは稼働させていることを示している。

　この通常系処理要求に対する処理完了までの最大許容待ち時間に関しては、各医療機関と事前に合意しておく。この最大許容待ち時間をより一層短縮したい医療機関は、後述の高速プランを契約することにより、待ち時間を短縮できるようにする。

　なお、Ｍ台の計算サーバを稼働させておく必要があるのは、医療機関が通常の外来診察受け付け時間中（通常診療業務時間中）の例えば日中８:００～１８:００とし、それ以外の時間帯にはＭ台よりも常時稼働台数を少なくしてもよい。

　〈例２〉救急系処理要求あり、通常プラン契約者のみの場合
　図３および図４は、医療機関ＭＩから救急系処理要求が送信されて来ている状態でのシステム動作の一連の流れを表すブロック図である。図３は、後述の図４とは異なり、救急系処理要求の数が医療系処理サーバクラスターの計算サーバＭ台で処理可能な数よりも少ないため、Ｍ＋１台目の計算サーバを追加する必要がない状況を表している。

　これに対し、図４は、Ｍ台の計算サーバで起動出来る救急系処理モジュールＥＭの個数では救急系処理要求を処理しきれない場合を表しており、Ｍ＋１台目の計算サーバを追加することにより、救急系処理要求に対する処理能力を増強する場合のシステム動作の一連の流れを表している。

　図３における手順［１］では、通常系処理要求に混ざって救急系処理要求が利用端末３０から送信される。利用端末３０から送信された通常系処理要求及び救急系処理要求は、処理要求分配制御部１０２にて受信される（手順［２］）。

　手順［３］にて、計算資源使用状況制御部１０４は、処理要求分配制御部１０２を監視している。処理要求分配制御部１０２が救急系処理要求を受信すると同時に、計算資源使用状況制御部１０４は以下の動作を行う。

　処理要求分配制御部１０２が受信した救急系処理要求の数が、救急系処理モジュールＥＭを増加させる閾値を超えた場合、計算資源使用状況制御部１０４は稼働中の通常系処理モジュールＮＭの一部を一時停止させ、救急系処理モジュールＥＭを代わりに起動させる。図３において、ドットパターンを付して塗りつぶした通常系処理モジュールＮＭは一時停止させた処理モジュールであることを表している（図４および図５においても同様）。

　この時、起動準備にかかる時間ロスを可能な限り抑える為、救急系処理モジュールＥＭを運用費の負担にならない範囲で常時待ち受けさせておいてもよい。例えば図３におけるＭ台目の通常プラン用サーバＮＰＳＭのように、１台の計算サーバを全て救急系処理モジュールＥＭ１～Ｎに常時占有させているのは、救急系処理要求が少ない場合にはサーバ運用費が必要以上にかかってしまうが、通常プラン用サーバＮＰＳ２のように救急系処理モジュールＥＭを通常系処理モジュールＮＭと同じサーバに相乗りさせる程度であれば、少数の救急系処理モジュールＥＭを常時待機させることも、運用費の観点から許容可能な場合がある。

　ここで、救急系処理モジュールＥＭを増加させる閾値とは、例えば、受信した処理要求数と現在稼働中の救急系処理モジュールＥＭの個数から処理待ち時間を動的に求め、救急系処理モジュールＥＭの最大許容待ち時間を超えた場合とする。

　稼働中の通常系処理モジュールＮＭの一時停止とは、Ｌｉｎｕｘ（登録商標）またはＷｉｎｄｏｗｓ（登録商標）ＯＳ（Operating System）等により提供される、プロセスを一時停止する仕組みを使用してもよいし、処理途中の状態を一時ファイル等に保存し、それを再度処理する際に読み込んで再開するというような形式をとってもよい。

　計算資源使用状況制御部１０４が通常系処理モジュールＮＭを一時停止可能な数には上限を設定する。これは仮に大量の救急系処理要求が行われた際に、ほとんどの通常系処理モジュールが停止されてしまうことで通常系処理要求の処理が最大許容待ち時間を超えて待たされることを防ぐためである。

　通常系処理モジュールＮＭを一時停止させることが可能な上限数の決め方は、通常系処理要求の単位時間当たりの受信数に対して、通常系処理モジュールＮＭが何個稼働していれば、各処理要求が処理完了になるまでの時間が何分になるかという値を事前に計測して統計値的に取得しておき、医療機関と事前に合意した、何分間の滞留時間なら許容可能かという最大許容待ち時間を計算資源使用状況制御部１０４に対して設定値として与えることによって、計算資源使用状況制御部１０４によって動的に決定する。つまり、計算資源使用状況制御部１０４は、通常処理要求に対する処理完了までの待ち時間（「第２の待ち時間」の一例）が最大許容待ち時間以内に収まる範囲で通常系処理モジュールＮＭの一時停止可能個数の上限を動的に計算する。

　計算資源使用状況制御部１０４は、通常系処理モジュールＮＭを一時停止可能な上限数まで一時停止させ、代わりに複数の救急系処理モジュールＥＭを起動させても救急系処理要求に対する処理完了までの待ち時間が最大許容待ち時間を超えることが見込まれる場合、計算資源使用状況制御部１０４は、図４に示すように、Ｍ＋１台目の計算サーバを起動し、そのＭ＋１台目の計算サーバにて救急系処理モジュールＥＭを起動する。

　ここでＭ＋１台目にて起動される救急系処理モジュールの数は、追加された計算サーバＭ＋１にて起動出来る救急系処理モジュールＥＭの最大数であることが望ましい。一般に、処理モジュールを一時停止させて起動させる処理は数秒から、長くても数十秒程度で完了するが、計算サーバの追加起動はＯＳの起動等も必要となるため数分程度かかる。このため、計算サーバの追加動作を開始するタイミングは、稼働中の救急系処理モジュールＥＭの数が足りなくなるよりも前から開始していることが望ましい。したがって、計算サーバの追加動作を開始する閾値は、救急系処理要求数の増加率などを指標とし、計算サーバの追加処理を、余裕を持って行えるような閾値とすることが望ましい。
　なお、図４では一例として、Ｍ＋１台目の計算サーバを１台追加する例を挙げたが、１台の計算サーバの追加だけでは不足する場合は、Ｍ＋２，Ｍ＋３・・・と、追加する計算サーバの台数を増やしていってもよい。

　また、図３および図４の例にて、救急系処理要求を受信次第、計算サーバを追加するのではなく、通常系処理モジュールＮＭを一時停止させることで一時的に対応しようとした理由は、計算サーバを追加すると運用費が増加するため、可能な限り計算サーバの台数を増加させずに、救急系処理要求の需要増に対応することが望ましいためである。

　図４の説明において、計算サーバを追加していくと述べたが、追加出来るサーバ台数には上限を設けることが望ましい。この上限数を定めるために、事前に救急系処理要求の需要ピークを計測値等から試算し、ピーク時に救急系処理要求の最大待ち時間がどの程度になるかを計算しておき、医療機関と事前に合意しておく。この最大待ち時間をより短縮したい医療機関は、後述の高速プランを契約することにより待ち時間を短縮できるようにする。

　また、一時停止された通常系処理モジュールＮＭは、他の稼働中の通常系処理モジュールＮＭの処理が終了次第、通常系処理要求キュー１０６にて処理待ちとなっている他の処理要求よりも優先して処理を再開させる。処理の再開方法としては一時停止時に、一時停止させた処理を通常系処理要求キュー１０６の先頭に配置する等の方法が考えられる。

　図３または図４に示す手順［４］にて、処理要求分配制御部１０２は受信した処理要求の種別に応じて、受信した処理要求を通常系処理要求キュー１０６または救急系処理要求キュー１０８に分配する。

　手順［５］にて、通常系処理モジュールＮＭと救急系処理モジュールＥＭとは、通常系処理要求キュー１０６または救急系処理要求キュー１０８からそれぞれ対応する処理要求を受信する。

　通常系処理要求キュー１０６から通常系処理要求を受信した通常系処理モジュールＮＭと、救急系処理要求キュー１０８から救急系処理要求を受信した救急系処理モジュールＥＭとは、手順［６］にてそれぞれの処理要求に対応する必要な処理を行う。図２の例では、通常系処理を担当する通常系処理モジュールＮＭが通常系処理要求キュー１０６から処理要求を取得して処理を行う。

　手順［７］にて、各利用端末３０は、医療系処理サーバクラスターから処理結果を取得する。各利用端末３０は、処理結果が取得可能かどうかを定期的に医療系処理サーバクラスターに問い合わせ、結果取得可能であったら医療系処理サーバクラスターから結果取得を開始してもよいし、医療系処理サーバクラスター側から利用端末に結果取得可能になった旨を通知し、利用端末はその通知を受けて結果取得を開始してもよい。端末利用者は利用端末に解析結果が取得され次第、その結果を閲覧する。

　〈救急系処理要求の需要が減少した場合のシステム挙動〉
　図３および図４では、救急系処理要求の需要増に対して、医療情報処理システム１０がどのように動作して救急系処理要求に対する処理能力を増強させるかについて説明してきた。以下に、救急系処理要求の需要減に対する本システム動作を説明する。なお、救急系処理要求の需要減に対するシステム挙動は、図２～図４で説明した需要増に対するシステム挙動について関する図２～図４と重複する部分が多いため図示を割愛する。

　処理要求分配制御部１０２を監視している計算資源使用状況制御部１０４は、救急系処理要求の受信数が減少すると、処理待機中となっている救急系処理モジュールＥＭがあることを検知する。計算資源使用状況制御部１０４は、各計算サーバにおける救急系処理モジュールＥＭの稼働状況を示す情報を取得してもよい。

　処理待ち受け状態のままとなっている救急系処理モジュールＥＭの個数が一定時間維持された場合、計算資源使用状況制御部１０４は救急系処理モジュールＥＭに対する計算資源割当量を減らすための動作を開始する。その際のシステム動作について以下に述べる。

　なお、この救急系処理モジュールＥＭに対する計算資源割当量を減少させる動作の開始条件となる「一定時間」という規定時間および処理待機中の救急系処理モジュールＥＭの「個数」についての規定個数などの条件について、外部から設定できるようにすることが好ましい。

　処理待ち受け状態のままになっている救急系処理モジュールＥＭの個数が規定個数以上である状態が規定時間以上維持された場合、まず、計算資源使用状況制御部１０４は、通常系処理要求に対する処理能力を回復させることを優先する。図４を例に説明すると、図４中に示す通常プラン用サーバＮＰＳ２～ＮＰＳＭの各計算サーバにて立ち上がっている救急系処理モジュールＥＭのうち、処理待ち受け状態となっているものを順次停止させ、停止させた救急系処理モジュールＥＭの代わりに、通常系処理モジュールＮＭを立ち上げていき、図１の状態に近づけていく。

　計算サーバＮＰＳ２～ＮＰＳＭ上に立ち上げた救急系処理モジュールＥＭを全て通常系処理モジュールＮＭと入れ替えた状態で、さらに処理待ち受け状態となっている救急系処理モジュールＥＭが計算サーバＮＰＳＭ＋1，ＮＰＳＭ＋２,・・・に存在する場合は、これら処理待ち受け状態となっている救急系処理モジュールＥＭの個数がＮ個(各計算サーバに立ち上げられる救急系処理モジュールの最大数)よりも多くなり次第、そのＮ個の単位でＭ＋１台目以降の計算サーバを１台ずつ停止させていく。

　上記のとおり、救急系処理要求の需要減により計算サーバを停止させている最中に救急系処理要求の需要増が発生した場合には、図３および図４の手順［３］で説明した流れに従い、再度救急系処理モジュールＥＭの個数を増やしていく。

　〈例３〉高速プラン契約者が本システムを利用する場合のシステム挙動の例
　図５は、図４に示す状況に加えて、高速プラン契約者が要素として加わり、医療情報処理システム１０に高速プラン用サーバが加わった例が示されている。図５に示す「高速プラン用サーバ１」、・・・「高速プラン用サーバＲ」の表示は、処理モジュール展開用の計算サーバであって、高速プラン契約者間で共有されるサーバを表す。Ｒ台の計算サーバのそれぞれを計算サーバＨＰＳ１、・・・ＨＰＳＲと表記する。高速プラン用サーバとしての計算サーバＨＰＳ１，・・・ＨＰＳＲは、仮想マシンを用いて構成される。高速プラン用サーバの台数Ｒは、通常プラン用サーバの台数Ｍと同様に、高速プランにて約束する最大許容待ち時間を実現するように決定される。

　図５を用いて、高速プラン契約者も医療系処理サーバクラスターを使用するようになった場合のシステム動作について説明する。

　利用端末３０には通常プラン契約者、高速プラン契約者に関わらず、通常系処理要求および救急系処理要求の双方の処理完了までの推定待ち時間が表示される。この推定待ち時間は、事前に通常系処理要求キュー１０６と救急系処理要求キュー１０８とのそれぞれで処理待ちの処理要求件数が何件で、稼働中の処理モジュール個数が何個だと待ち時間がどの程度となるかを計測して統計的に求めておき、その値を元に計算される。計算された推定待ち時間の情報は、医療系処理サーバクラスターから各利用端末３０が取得できるようにしておく。

　各医療機関の利用者は、利用端末３０に表示される推定待ち時間を確認し、より早く処理できるようにしたいかどうかを判断する判断材料に使用することができる。

　図５では、医療機関Ｌが高速プランを契約したことを表している。医療機関Ｌが高速プランを契約した情報は、利用端末から医療系処理サーバクラスターに対して送信される。その情報を受信した計算資源使用状況制御部１０４は高速プラン用サーバＨＰＳを起動し、高速プラン契約者の医療機関Ｌに対して追加の計算サーバ（高速プラン用サーバＨＰｓ１、・・・ＨＰＳＲ）が割り当てられるようにする。図５では、医療機関Ｌが高速プランを契約した例が示されているが、複数の医療機関が高速プラン契約者となり得る。

　高速プラン用サーバＨＰＳ１、・・・ＨＰＳＲは、高速プランを契約した複数の医療機関によって共有され得る。ただし、ここで高速プラン用サーバを共有できる医療機関の数の上限は、高速プランの契約の際に合意した最大許容待ち時間を超えない範囲の数とする。この上限を超えた数の医療機関が高速プランを契約する場合、計算資源使用状況制御部１０４は、さらに追加の高速プラン用サーバＨＰＳＲ＋１、ＨＰＳＲ＋２・・・を起動する。

　高速プラン用サーバは、通常プラン用サーバを使用した際の処理能力に対して、処理能力を追加するという位置づけのものとし、高速プラン契約者にも通常プラン用サーバ上の処理モジュールを割り当てることが望ましい。これは計算サーバを共有する医療機関数が少なくなるほど、１つの医療機関が負担しなければならないサーバ運用費が増加し、結果としてサービス利用料が高額になってしまうためである。

　計算資源使用状況制御部１０４が常時用意する高速プラン用サーバの台数Ｒは、高速プランにおいて約束する通常系処理の最大許容待ち時間内での処理完了を達成するために、現在高速プランを契約中の医療機関数に対して、通常プラン用サーバに加えて何台計算サーバを用意すればよいかという値を動的に求めることで決定する。このため、高速プラン契約者数の増減に応じて、高速プラン用サーバＨＰＳの常時稼働台数も増減する。

　高速プラン契約者から通常系処理要求に混ざって救急系処理要求が送信されて来た場合、医療情報処理システム１０は、図２から図４を用いて説明した処理の流れに従い、救急系処理要求の需要に応じて、救急系処理モジュールＥＭの増減および計算サーバの増減を行う。

　仮想マシンＶＭｋを用いて構成される医療用処理サーバクラスターは本開示における「サーバクラスター」の一例である。処理要求分配制御部１０２は本開示における「第１の制御部」の一例である。処理要求分配制御部１０２が行う処理は本開示における「処理要求分配制御」および「第１の制御」の一例である。処理要求分配制御部１０２の機能は本開示における「第１の制御機能」の一例である。計算資源使用状況制御部１０４は本開示における「第２の制御部」の一例であり、計算資源使用状況制御部１０４が行う処理は本開示における「計算資源使用状況制御」および「第２の制御」の一例である。計算資源使用状況制御部１０４の機能は本開示における「第２の制御機能」の一例である。通常系処理要求は本開示における「非救急系処理要求」の一例であり、通常系処理要求キュー１０６は本開示における「非救急系処理要求キュー」の一例である。通常系処理モジュールＮＭは本開示における「非救急系処理モジュール」の一例である。

　《医療機関内情報システムの例》
　図６は、医療情報処理システム１０の処理サービスを利用する複数の医療機関の医療機関内情報システム３００の例を示すブロック図である。図６では、図示を簡単にするために、複数の医療機関におけるそれぞれの医療機関内ネットワークに同様のシステム構成の医療機関内情報システム３００が構築されている例を示すが、医療機関ごとに異なるシステム構成が採用され得る。

　医療機関内情報システム３００は、モダリティ３４０と、ＤＩＣＯＭ（Digital Imaging and Communications in Medicine）サーバ３５０と、画像処理管理端末３２０Ａと、ビューワ端末３２２と、電子カルテシステム３２４と、構内通信回線３２６とを含むコンピュータネットワークである。

　モダリティ３４０は、検査画像を撮影する装置である。モダリティ３４０には、被写体の検査対象部位を撮影することにより、その部位を表す検査画像を生成し、その画像にＤＩＣＯＭ規格で規定された付帯情報を付加して出力する装置が含まれる。モダリティ３４０の具体例としては、ＣＴ装置（Computed Tomography：コンピュータ断層撮影装置）、ＭＲＩ装置（magnetic resonance imaging：磁気共鳴画像撮影装置）、血管造影Ｘ線診断装置、ＰＥＴ装置（Positron Emission Tomography：陽電子放射断層撮影装置）、超音波装置、平面Ｘ線検出器（Flat Panel Detector：ＦＰＤ）を用いたＣＲ装置（Computed Radiography：コンピュータＸ線撮影装置）、マンモグラフィ装置、および内視鏡装置等が挙げられる。

　医療機関内情報システム３００には、複数種類のモダリティ３４０が含まれてもよい。医療機関内ネットワーク上に存在するモダリティ３４０の種類および台数は、医療機関ごとに様々な組み合わせがありうる。

　ＤＩＣＯＭサーバ３５０は、ＤＩＣＯＭの仕様にて動作するサーバである。ＤＩＣＯＭサーバ３５０は、モダリティ３４０を用いて撮影された画像を含む各種データを保存および管理するコンピュータであり、大容量外部記憶装置およびデータベース管理用プログラムを備えている。ＤＩＣＯＭサーバ３５０は、構内通信回線３２６を介して他の装置と通信を行い、画像データを含む各種データを送受信する。ＤＩＣＯＭサーバ３５０は、モダリティ３４０によって生成された画像データその他の含む各種データを構内通信回線３２６経由で受信し、大容量外部記憶装置等の記録媒体に保存して管理する。

　画像処理管理端末３２０Ａは、利用端末３０として機能する情報処理装置である。画像処理管理端末３２０Ａは、医療情報処理システム１０と通信するための通信機能を有し、通信回線２０を介して医療情報処理システムと接続される。画像処理管理端末３２０Ａは、構内通信回線３２６を介してＤＩＣＯＭサーバ３５０等からデータを取得することができる。また、画像処理管理端末３２０Ａは、医療情報処理システムから取得した処理結果をＤＩＣＯＭサーバ３５０およびビューワ端末３２２に送ることができる。画像処理管理端末３２０Ａは、ビューワ端末３２２と兼用されてもよい。

　ＤＩＣＯＭサーバ３５０のデータベースに保存された各種データ、並びに画像処理管理端末３２０Ａが取得した処理結果を含む様々な情報は、ビューワ端末３２２に表示させることができる。

　ビューワ端末３２２は、ＰＡＣＳ（Picture Archiving and Communication Systems）ビューワ、あるいはＤＩＣＯＭビューワと呼ばれる画像閲覧用の端末である。医療機関内ネットワークには複数のビューワ端末３２２が接続され得る。ビューワ端末３２２の形態は特に限定されず、パーソナルコンピュータであってもよいし、ワークステーションであってもよく、また、タブレット端末などであってもよい。ビューワ端末３２２に組み込まれるソフトウェアは、専用の閲覧ソフトであってもよいし、Ｗｅｂブラウザーなどであってもよい。ビューワ端末３２２は、医療情報処理システム１０にアクセスするための利用端末３０として機能してもよい。

　医療情報処理システム１０は、通信回線２０を介して、各医療機関の画像処理管理端末３２０Ａおよび／またはビューワ端末３２２と通信を行う。図１から図５を用いて説明したとおり、医療情報処理システム１０は、複数の医療機関からの処理要求に応じて医療情報処理サービスを提供する。医療情報処理システム１０を用いて実現される医療画像処理サービスの提供方法は本開示における「医療情報処理サービス提供方法」の一例である。

　《医療情報処理方法の例》
　図７から図９は、実施形態に係る医療情報処理システム１０によって実行される医療情報処理方法の例を示すフローチャートである。図７から図９に示す各ステップは、医療情報処理システム１０として機能するコンピュータによって実行される。医療情報処理システム１０は、１台または複数台の物理マシンを含むコンピュータシステムによって実現され得る。また、医療情報処理システム１０は、分散コンピューティングによって実現することができる。医療情報処理システム１０として機能するコンピュータとは、１台のコンピュータに限らず、複数台のコンピュータの集合体である場合も含む。

　図７のステップＳ１０において、医療情報処理システム１０は、複数の医療機関の利用端末３０から処理対象の医用画像と処理要求とを受け付ける。

　ステップＳ１２において、処理要求分配制御部１０２は、処理要求を受信したか否かを判定する。ステップＳ１２の判定結果がＮｏ判定である場合、処理要求分配制御部１０２は、ステップＳ１０に戻る。処理要求分配制御部１０２が処理要求を受信し、ステップＳ１２の判定結果がＹｅｓ判定である場合、ステップＳ１４に進む。

　ステップＳ１４において、処理要求分配制御部１０２は、受信した処理要求の種別を判定する。受信した処理要求が通常系処理要求である場合、処理要求分配制御部１０２はステップＳ１６に進み、通常系処理要求を通常系処理要求キュー１０６に送る。

　その一方、ステップＳ１４の種別判定の結果が救急系処理要求である場合、処理要求分配制御部１０２はステップＳ１８に進み、救急系処理要求を救急系処理要求キュー１０８に送る。

　また、ステップＳ１４の種別判定の結果が救急系処理要求である場合、計算資源使用状況制御部１０４は、ステップＳ２０に示す処理モジュール増減制御を行う。ステップＳ２０のサブルーチンについては図８を用いて後述する。

　ステップＳ１６にて通常系処理要求キュー１０６に通常系処理要求がスタックされると、ステップＳ２２において、順次に通常系処理要求が通常系処理モジュールＮＭに送られ、通常系処理モジュールＮＭにて通常系処理が行われる。

　一方、ステップＳ１８にて救急系処理要求キュー１０８に救急系処理要求がスタックされると、ステップＳ２４において、順次に救急系処理要求が救急系処理モジュールＥＭに送られ、救急系処理モジュールＥＭにて救急系処理が行われる。

　ステップＳ２２およびステップＳ２４にて稼働する通常系処理モジュールＮＭおよび救急系処理モジュールＥＭのそれぞれの処理モジュールの個数は、ステップＳ２０の処理モジュール増減制御によって調整される。

　ステップＳ２２またはステップＳ２４の後、ステップＳ２６において、医療情報処理システム１０は、処理結果を要求元の医療機関の利用端末３０に提供するために出力する。

　図７では、処理要求の受信から処理結果の送信までの１サイクルのフローチャートを示すが、図７のステップＳ２６の後、医療情報処理システム１０は、ステップＳ１０に戻って、図７のフローチャートを繰り返してよい。

　図８は、図７のステップＳ２０に適用されるサブルーチンの例を示すフローチャートである。

　ステップＳ２０２において、計算資源使用状況制御部１０４は、処理要求分配制御部１０２が受信した救急系処理要求数と、稼働中の救急系処理モジュールＥＭの個数から救急系処理要求に対する処理完了までの処理待ち時間を算出する。ステップＳ２０２にて算出される処理待ち時間は本開示における「第１の処理待ち時間」の一例である。

　ステップＳ２０４において、計算資源使用状況制御部１０４は、算出した処理待ち時間が閾値Ｔｈ１を超えるか否かを判定する。閾値Ｔｈ１は、許容可能な最大待ち時間（最大許容待ち時間）であり、具体的には、契約プランにおいて約束する最大許容待ち時間である。通常プランを契約している医療機関からの処理要求に対する閾値Ｔｈ１をＴｈ１＿ＮＰとし、高速プランを契約している医療機関からの処理要求に対する閾値Ｔｈ１をＴｈ１＿ＨＰとすると、Ｔｈ１＿ＨＰ＜Ｔｈ１＿ＮＰである。閾値Ｔｈ１は本開示における「第１の許容待ち時間」の一例である。

　ステップＳ２０４の判定結果がＹｅｓ判定である場合、計算資源使用状況制御部１０４は、ステップＳ２０６に進む。ステップＳ２０６において、計算資源使用状況制御部１０４は、契約プランで約束している最大許容待ち時間以内で処理完了するために追加が必要な救急系処理モジュールＥＭの個数を算出する。

　その後、ステップＳ２０８において、計算資源使用状況制御部１０４は、現状の計算サーバ台数のまま、通常系処理モジュールＮＭの一時停止で対応可能であるか否かを判定する。

　ステップＳ２０８の判定結果がＹｅｓ判定である場合、計算資源使用状況制御部１０４は、ステップＳ２１０に進む。ステップＳ２１０において、計算資源使用状況制御部１０４は、稼働中の通常系処理モジュールの一部を一時停止させ、代わりに、ステップＳ２１２において、新たに必要個数の救急系処理モジュールＥＭを起動させる。

　一方、ステップＳ２０８の判定結果がＮｏ判定である場合、計算資源使用状況制御部１０４は、ステップＳ２１６に進む。ステップＳ２１６において、計算資源使用状況制御部１０４は、一時停止中の通常系処理モジュールＮＭの個数が一時停止可能な上限数未満であるか否かを判定する。

　ステップＳ２１６の判定結果がＹｅｓ判定である場合、計算資源使用状況制御部１０４は、ステップＳ２２０に進む。ステップＳ２２０において、計算資源使用状況制御部１０４は、稼働中の通常系処理モジュールＮＭを上限数まで一時停止させ、代わりに、ステップＳ２２２において、新たに救急系処理モジュールＥＭを起動させる。

　ステップＳ２２２の後、計算資源使用状況制御部１０４は、ステップＳ２３４に進む。また、ステップＳ２１６の判定結果がＮｏ判定である場合もステップＳ２３４に進む。

　計算資源使用状況制御部１０４は、計算サーバの追加が必要な場合の追加動作のタイミングを早めるために、ステップＳ２０２の処理と並行してステップＳ２３０において、救急系処理要求数の増加率を監視している。処理要求数の増加率は、単位時間当たりの処理要求の受信数から求めることができる。

　ステップＳ２３２において、計算資源使用状況制御部１０４は、救急系処理要求数の増加率が閾値Ｔｈ２を超えているか否かを判定する。閾値Ｔｈ２は、通常プランと高速プランとで異なる閾値が設定されてよい。通常プランを契約している医療機関からの救急系処理要求数の増加率に対する閾値Ｔｈ２をＴｈ２＿ＮＰとし、高速プランを契約している医療機関からの救急系処理要求数の増加率に対する閾値Ｔｈ２をＴｈ２＿ＨＰとすると、Ｔｈ２＿ＨＰ＜Ｔｈ２＿ＮＰであってよい。

　ステップＳ２３２の判定結果がＮｏ判定である場合、計算資源使用状況制御部１０４はステップＳ２０４に進む。なお、計算資源使用状況制御部１０４は、ステップＳ２３２の判定結果がＮｏ判定である場合にステップＳ２０４に進む代わりに、ステップＳ２３０に戻ってもよい。

　一方、ステップＳ２３２の判定結果がＹｅｓ判定である場合、計算資源使用状況制御部１０４は、ステップＳ２３４に進む。

　ステップＳ２３４において、計算資源使用状況制御部１０４は、計算サーバの追加が可能か否かを判定する。計算サーバを追加できる台数には上限が定められており、計算資源使用状況制御部１０４は、その上限の範囲内で、計算サーバのさらなる追加が可能か否かを判定する。

　ステップＳ２３４の判定結果がＹｅｓ判定である場合、計算資源使用状況制御部１０４は、ステップＳ２３６に進み、計算サーバを追加する。そして、ステップＳ２３８において、計算資源使用状況制御部１０４は、追加した計算サーバ上で新たに救急系処理モジュールを起動させる。

　ステップＳ２１２またはステップＳ２３８の後、図８のフローチャートを終了し、図７のフローチャートに復帰する。

　また、ステップＳ２３４の判定結果がＮｏ判定である場合、計算サーバの追加ができないため、図８のフローチャートを終了し、図７のフローチャートに復帰する。

　図９は、救急系処理要求の需要減に対応した救急系処理モジュールＥＭの個数削減制御の例を示すフローチャートである。図９のフローチャートは、救急系処理モジュールＥＭを追加する処理を行った場合に実行される。

　ステップＳ４０において、計算資源使用状況制御部１０４は、処理待ち受け状態の救急系処理モジュールＥＭの個数と、それらの待機状態継続時間とを取得する。

　ステップＳ４２において、計算資源使用状況制御部１０４は、規定個数以上の救急系処理モジュールＥＭが処理待ち受け状態のまま規定時間以上維持されたか否かを判定する。

　ステップＳ４２の判定結果がＮｏ判定である場合、計算資源使用状況制御部１０４は、現状の救急系処理モジュールＥＭの個数を維持し、ステップＳ４０に戻る。

　ステップＳ４２の判定結果がＹｅｓ判定である場合、計算資源使用状況制御部１０４は、余剰な救急系処理モジュールＥＭを停止させるために、ステップＳ４４に進む。

　ステップＳ４４において、計算資源使用状況制御部１０４は、救急系処理要求の需要増への対処のために一時停止している通常系処理モジュールＮＭが存在するか否かを判定する。

　ステップＳ４４の判定結果がＹｅｓ判定である場合、計算資源使用状況制御部１０４は、一時停止した通常系処理モジュールＮＭの代わりに起動させた救急系処理モジュールを停止させる。そして、ステップＳ４８において、計算資源使用状況制御部１０４は、一時停止している通常系処理モジュールを再開させる。ステップＳ４８の後、計算資源使用状況制御部１０４はステップＳ４０に戻る。

　一方、ステップＳ４４の判定結果がＮｏ判定である場合、計算資源使用状況制御部１０４は、ステップＳ５０に進み、追加した計算サーバの単位で救急系処理モジュールＥＭを停止可能か否かを判定する。

　ステップＳ５０の判定結果がＮｏ判定である場合、計算資源使用状況制御部１０４は、ステップＳ４０に戻る。ステップＳ５０の判定結果がＹｅｓ判定である場合、計算資源使用状況制御部１０４は、ステップＳ５２に進み、余剰な救急系処理モジュールＥＭが展開されている計算サーバについて、計算サーバの単位で（Ｎ個の単位で）救急系処理モジュールＥＭを停止させ、計算サーバを停止させる。

　その後、ステップＳ５４において、計算資源使用状況制御部１０４は、追加した計算サーバを全て停止させたか否かを判定する。ステップＳ５４の判定結果がＮｏ判定である場合、計算資源使用状況制御部１０４はステップＳ４０に戻る。一方、ステップＳ５４の判定結果がＹｅｓ判定である場合、図９のフローチャートを終了する。

　なお、一時停止させた通常系処理モジュールＮＭを再開させるか否かの判定の際に適用される判定基準となる処理待ち受け状態の救急系処理モジュールＥＮの規定個数および規定時間（第１の規定個数および第１の規定時間）は、追加した計算サーバを停止させるか否かの判定の際に適用される判定基準となる処理待ち受け状態の救急系処理モジュールＥＮの規定個数および規定時間（第２の規定個数および第２の規定時間）と同じ設定であってもよいし、異なる設定であってもよい。

　《コンピュータのハードウェア構成の例》
　図１０は、コンピュータのハードウェア構成の例を示すブロック図である。コンピュータ８００は、サーバコンピュータであってもよいし、パーソナルコンピュータであってもよいし、ワークステーションであってもよい。コンピュータ８００は、既に説明した医療情報処理システム１０、利用端末３０、ＤＩＣＯＭサーバ３５０、電子カルテシステム３２４、画像処理管理端末３２０Ａ、ビューワ端末３２２のいずれかの一部または全部、あるいはこれらの複数の機能を備えた装置として用いることができる。

　コンピュータ８００は、ＣＰＵ（Central Processing Unit）８０２、ＲＡＭ（Random Access Memory）８０４、ＲＯＭ（Read Only Memory）８０６、ＧＰＵ（Graphics Processing Unit）８０８、ストレージ８１０、通信部８１２、入力装置８１４、表示装置８１６およびバス８１８を備える。なお、ＧＰＵ８０８は、必要に応じて設ければよい。

　ＣＰＵ８０２は、ＲＯＭ８０６またはストレージ８１０等に記憶された各種のプログラムを読み出し、プログラムの命令に従い、各種の処理を実行する。ＲＡＭ８０４は、ＣＰＵ８０２の作業領域として使用される。また、ＲＡＭ８０４は、読み出されたプログラムおよび各種のデータを一時的に記憶する記憶部として用いられる。

　ストレージ８１０は、例えば、ハードディスク装置、光ディスク、光磁気ディスク、もしくは半導体メモリ、またはこれらの適宜の組み合わせを用いて構成される記憶装置を含んで構成される。ストレージ８１０には、各種プログラムやデータ等が記憶される。ストレージ８１０に記憶されているプログラムがＲＡＭ８０４にロードされ、これをＣＰＵ８０２が実行することにより、コンピュータ８００は、プログラムで規定される各種の処理を行う手段として機能する。

　通信部８１２は、有線または無線により外部装置との通信処理を行い、外部装置との間で情報のやり取りを行うインターフェースである。通信部８１２は、処理対象のデータおよび処理要求等の入力を受け付ける情報取得部としての役割を担うことができる。また、通信部８１２は、処理結果等を出力する情報出力部としての役割を担うことができる。

　入力装置８１４は、コンピュータ８００に対する各種の操作入力を受け付ける入力インターフェースである。入力装置８１４は、例えば、キーボード、マウス、マルチタッチパネル、もしくはその他のポインティングデバイス、もしくは、音声入力装置、またはこれらの適宜の組み合わせであってよい。

　表示装置８１６は、各種の情報が表示される出力インターフェースである。表示装置８１６は、例えば、液晶ディスプレイ、有機ＥＬ（organic electro-luminescence:ＯＥＬ）ディスプレイ、もしくは、プロジェクタ、またはこれらの適宜の組み合わせであってよい。

　《コンピュータを動作させるプログラムについて》
　上記の実施形態で説明した医療情報処理システム１０における各種の処理機能のうち少なくとも１つの処理機能の一部または全部をコンピュータに実現させるプログラムを、光ディスク、磁気ディスク、もしくは、半導体メモリその他の有体物たる非一時的な情報記憶媒体であるコンピュータ可読媒体に記録し、この情報記憶媒体を通じてプログラムを提供することが可能である。

　またこのような有体物たる非一時的なコンピュータ可読媒体にプログラムを記憶させて提供する態様に代えて、インターネットなどの電気通信回線を利用してプログラム信号をダウンロードサービスとして提供することも可能である。

　《各処理部のハードウェア構成について》
　医療情報処理システム１０における処理要求分配制御部１０２、計算資源使用状況制御部１０４、通常系処理要求キュー１０６、救急系処理要求キュー１０８、通常系処理モジュールＮＭおよび救急系処理モジュールＥＭなどの各種の処理を実行する処理部（processing unit）のハードウェア的な構造は、例えば、次に示すような各種のプロセッサ（processor）である。

　各種のプロセッサには、プログラムを実行して各種の処理部として機能する汎用的なプロセッサであるＣＰＵ、画像処理に特化したプロセッサであるＧＰＵ、ＦＰＧＡ（Field Programmable Gate Array）などの製造後に回路構成を変更可能なプロセッサであるプログラマブルロジックデバイス（Programmable Logic Device：ＰＬＤ）、ＡＳＩＣ（Application Specific Integrated Circuit）などの特定の処理を実行させるために専用に設計された回路構成を有するプロセッサである専用電気回路などが含まれる。

　１つの処理部は、これら各種のプロセッサのうちの１つで構成されていてもよいし、同種または異種の２つ以上のプロセッサで構成されてもよい。例えば、１つの処理部は、複数のＦＰＧＡ、あるいは、ＣＰＵとＦＰＧＡの組み合わせ、またはＣＰＵとＧＰＵの組み合わせによって構成されてもよい。また、複数の処理部を１つのプロセッサで構成してもよい。複数の処理部を１つのプロセッサで構成する例としては、第一に、クライアントやサーバなどのコンピュータに代表されるように、１つ以上のＣＰＵとソフトウェアの組み合わせで１つのプロセッサを構成し、このプロセッサが複数の処理部として機能する形態がある。第二に、システムオンチップ（System On Chip：ＳｏＣ）などに代表されるように、複数の処理部を含むシステム全体の機能を１つのＩＣ（Integrated Circuit）チップで実現するプロセッサを使用する形態がある。このように、各種の処理部は、ハードウェア的な構造として、上記各種のプロセッサを１つ以上用いて構成される。

　さらに、これらの各種のプロセッサのハードウェア的な構造は、より具体的には、半導体素子などの回路素子を組み合わせた電気回路（circuitry）である。

　《本実施形態による利点》
　実施形態に係る医療情報処理システム１０によれば、次のような利点がある。

　［１］救急系処理要求の需要の増減に応じて、稼働する通常系処理モジュールＮＭの個数と救急系処理モジュールＥＭの個数とを動的に調整することができる。これにより、使用する計算資源の最適化を図ることができ、サーバ運用費をできるだけ抑えつつ、救急系処理と、通常系処理との双方について、それぞれの最大許容待ち時間以内に処理結果を返すことが可能である。

　［２］通常プランと高速プランとの２種類のプランを用意することで、処理待ち時間のさらなる短縮を希望する医療機関のニーズに応えることができる。

　《その他》
　以上説明した本発明の実施形態は、本発明の趣旨を逸脱しない範囲で、適宜構成を変更、追加、または削除することが可能である。本発明は以上説明した実施形態に限定されるものではなく、本発明の技術的思想内で当該分野の通常の知識を有する者により、多くの変形が可能である。

１０　医療情報処理システム
２０　通信回線
２６　構内通信回線
３０　利用端末
４０　モダリティ
５０　ＤＩＣＯＭサーバ
１０２　処理要求分配制御部
１０４　計算資源使用状況制御部
１０６　通常系処理要求キュー
１０８　救急系処理要求キュー
３００　医療機関内情報システム
３２０Ａ　画像処理管理端末
３２２　ビューワ端末
３２４　電子カルテシステム
３２６　構内通信回線
３４０　モダリティ
３５０　ＤＩＣＯＭサーバ
８００　コンピュータ
８０２　ＣＰＵ
８０４　ＲＡＭ
８０６　ＲＯＭ
８０８　ＧＰＵ
８１０　ストレージ
８１２　通信部
８１４　入力装置
８１６　表示装置
８１８　バス
ＶＭ０，ＶＭ１，ＶＭｋ　仮想マシン
ＮＭ　通常系処理モジュール
ＮＭ１，ＮＭ２，ＮＭＮ　通常系処理モジュール
ＥＭ　救急系処理モジュール
ＥＭ１，ＥＭ２，ＥＭＮ　救急系処理モジュール
ＮＰＳ１，ＮＰＳ２，ＮＰＳＭ，ＮＰＳＭ＋１　通常プラン用サーバ（計算サーバ）
ＨＰＳ１，ＨＰＳＭ　高速プラン用サーバ（計算サーバ）
ＭＩ１，ＭＩ２，ＭＩＬ　医療機関
Ｓ１０～Ｓ２６　実施形態に係る医療情報処理方法のステップ
Ｓ２０２～Ｓ２３８　処理モジュール増減制御のステップ
Ｓ４０～Ｓ５４　救急系処理要求の需要減に対応した救急系処理モジュールの個数削減制御のステップ

Claims

　処理対象の医療情報と処理要求とを受け付け、前記処理要求に応じた処理を実行して処理結果を出力する医療情報処理システムは、
　１つ以上のプロセッサを備え、
　プロセッサは、複数の仮想マシンを構成し、
　前記処理要求を受け取り、前記処理要求が非救急に分類される処理を求める非救急系処理要求であるか、救急に分類される処理を求める救急系処理要求であるかに応じて、前記処理要求を非救急系処理要求キューまたは救急系処理要求キューに振り分ける処理要求分配し、
　前記非救急系処理要求キューを監視し、前記非救急系処理要求キューにスタックされた前記非救急系処理要求の指示内容に対応した非救急系の処理を行い、
　前記救急系処理要求キューを監視し、前記救急系処理要求キューにスタックされた前記救急系処理要求の指示内容に対応した救急系の処理を行い、
　前記受け取った救急系処理要求の数と稼働中の前記救急系処理の数とに基づき、稼働させる前記非救急系処理の数と前記救急系処理の数とを制御する計算資源使用状況制御を行い、
　前記計算資源使用状況制御は、稼働中の複数の前記非救急系処理のうちの一部を一時停止させ、かつ、新たに前記救急系処理を起動させて前記救急系処理の数を増加させる処理を含む、
　医療情報処理システム。
　プロセッサは、
　前記受け取った救急系処理要求の数と前記稼働中の救急系処理の数とから、前記救急系処理要求に対する処理完了までの第１の処理待ち時間を計算し、前記第１の処理待ち時間が第１の許容待ち時間を超える場合に、前記第１の処理待ち時間を前記第１の許容待ち時間以内に収めるために前記救急系処理の数を増加させる、
　請求項１に記載の医療情報処理システム。
　プロセッサは、
　、前記非救急系処理要求に対する処理完了までの第２の待ち時間が第２の許容待ち時間以内に収まる範囲で前記救急系処理を一時停止させてよい数の上限を動的に計算し、前記上限を超えない数の前記非救急系処理を一時停止させ、代わりに前記救急系処理を新たに起動させる、
　請求項１または２に記載の医療情報処理システム。
　プロセッサは、
　、前記救急系処理の数を増加させるために、前記仮想マシンの台数を増加させ、追加した仮想マシン上で複数の前記救急系処理を新たに起動させる、
　請求項１から３のいずれか一項に記載の医療情報処理システム。
　プロセッサは、
　前処理待機中の前記救急系処理の数が規定数以上である状態が規定時間以上維持された場合に、前記救急系処理の数を減少させる、
　請求項１から４のいずれか一項に記載の医療情報処理システム。
　プロセッサは、
　処理待機中の前記救急系処理の数が第１の規定数以上である状態が第１の規定時間以上維持された場合に、前記非救急系処理の一時停止を伴って追加した前記救急系処理の数を減少させ、かつ、前記一時停止させていた前記非救急系処理を再開させる、
　請求項１から４のいずれか一項に記載の医療情報処理システム。
　プロセッサは、
　処理待機中の前記救急系処理の数が第２の規定数以上である状態が第２の規定時間以上維持された場合に、前記追加した仮想マシン上の前記救急系処理の数を減少させ、前記追加した仮想マシンの台数を減少させる、
　請求項４に記載の医療情報処理システム。
　プロセッサは、
　処理待機中の前記救急系処理の数が第１の規定数以上である状態が第１の規定時間以上維持された場合に、前記非救急系処理の一時停止を伴って追加した前記救急系処理の数を減少させ、かつ、前記一時停止させていた前記非救急系処理を再開させ、
　前記一時停止させていた前記非救急系処理をすべて再開させた後に、
　前記追加した仮想マシン上の前記救急系処理の数を減少させ、前記追加した仮想マシンの台数を減少させる、
　請求項４に記載の医療情報処理システム。
　プロセッサは、
　前記非救急系処理要求および前記救急系処理要求のそれぞれについて、処理要求を受け付けた場合の現在の処理待ち時間を計算し、前記現在の処理待
ち時間の情報を、医療機関の利用端末に提供する、
　請求項１から８のいずれか一項に記載の医療情報処理システム。
　プロセッサは、
　前記非救急系処理要求に対する処理完了までの最大待ち時間が第３の待ち時間であり、前記救急系処理要求に対する処理完了までの最大待ち時間が前記第３の待ち時間よりも短い第４の待ち時間であることを約束する第１のプランと、
　前記非救急系処理要求に対する処理完了までの最大待ち時間および前記救急系処理要求に対する処理完了までの最大待ち時間の少なくとも一方が前記第１のプランの最大待ち時間よりも短い待ち時間であることを約束する第２のプランと、
　を用意し、
　前記第１のプランを選択している医療機関からの処理要求の処理に割り当てられる第１のプラン用の前記非救急系処理、前記救急系処理および前記仮想マシンに加え、
　前記第２のプランを選択している医療機関からの処理要求の処理に割り当てられる第２のプラン用の前記非救急系処理、前記救急系処理および前記仮想マシンを備える、
　請求項１から９のいずれか一項に記載の医療情報処理システム。
　プロセッサは、
　前記第２のプランを選択する医療機関の数の増減に応じて、前記第２のプラン用の前記非救急系処理の数、前記救急系処理の数および前記仮想マシンの台数を増減させる、
　請求項１０に記載の医療情報処理システム。
　請求項１から１１のいずれか一項に記載の医療情報処理システムを用いて実施される医療情報処理サービス提供方法であって、
　医療情報処理システムが
　通信回線を介して複数の医療機関から前記処理要求を受け付け、
　前記処理要求に対応する処理を実行して処理結果を前記処理要求の要求元の医療機関に返す、処理を含む
　医療情報処理サービス提供方法。
　コンピュータが処理対象の医療情報と処理要求とを受け付け、前記処理要求に応じた処理を実行して処理結果を出力する処理を行うために前記コンピュータによって実行される医療情報処理方法であって、
　前記コンピュータ上に複数の仮想マシンを構成し、
　前記処理要求を受け取り、前記処理要求が非救急に分類される処理を求める非救急系処理要求であるか、救急に分類される処理を求める救急系処理要求であるかに応じて、前記処理要求を非救急系処理要求キューまたは救急系処理要求キューに振り分ける第１の制御を行い、
　前記非救急系処理要求キューを監視し、前記非救急系処理要求キューにスタックされた前記非救急系処理要求の指示内容に対応した非救急系の処理を行う非救急系処理を行うことと、
　前記救急系処理要求キューを監視し、前記救急系処理要求キューにスタックされた前記救急系処理要求の指示内容に対応した救急系の処理を行う救急系処理を行い、
　前記受け取った前記救急系処理要求の数と稼働中の前記救急系処理の数とに基づき、稼働させる前記非救急系処理の数と前記救急系処理の数とを制御する第２の制御を行うことと、を含み、
　前記第２の制御は、稼働中の複数の前記非救急系処理のうちの一部を停止させ、かつ、新たに前記救急系処理を起動させて前記救急系処理の数を増加させる、処理を含む、
　医療情報処理方法。
　コンピュータが処理対象の医療情報と処理要求とを受け付け、前記処理要求に応じた処理を実行して処理結果を出力する処理を前記コンピュータに実現させるためプログラムであって、
　前記コンピュータ上に複数の仮想マシンを構成し、
　前記処理要求を受け取り、前記処理要求が非救急に分類される処理を求める非救急系処理要求であるか、救急に分類される処理を求める救急系処理要求であるかに応じて、前記処理要求を非救急系処理要求キューまたは救急系処理要求キューに振り分ける第１の制御機能と、
　前記非救急系処理要求キューを監視し、前記非救急系処理要求キューにスタックされた前記非救急系処理要求の指示内容に対応した非救急系の処理を行う非救急系処理の機能と、
　前記救急系処理要求キューを監視し、前記救急系処理要求キューにスタックされた前記救急系処理要求の指示内容に対応した救急系の処理を行う救急系処理の機能と、
　前記第１の制御機能により受け取った前記救急系処理要求の数と稼働中の前記救急系処理の数とに基づき、稼働させる前記非救急系処理の数と前記救急系処理の数とを制御する第２の制御機能と、を実現させ、
　前記第２の制御機能は、稼働中の複数の前記非救急系処理のうちの一部を停止させ、かつ、新たに前記救急系処理を起動させて前記救急系処理の数を増加させる機能を含む、
　プログラム。