JP6465033B2 - 検査サーバ、通信端末、検査システム、および検査方法 - Google Patents

Description

本技術は、統計情報を用いた検査システム、その検査システムを構成する通信端末および検査サーバ、ならびにこの検査システムで用いられる検査方法に関する。

近年、臨床医療において行われる検査は、患者の治療を進める上で、ますます重要となっている。そして臨床検査のために、数多くの検査機器や検査キット、検査方法が開発されている。

検査システムをネットワークに対応したクライアント・サーバ・システムとして構築することも行われている。

例えば、特許文献１では、例えばコンピュータで構成されるインテリジェンスモジュール１０５が、試験システム１５０などのデータ収集モジュールから、患者試験結果を直接接続またはネットワーク１４０を介して受け取る。インテリジェンスモジュールは、患者試験結果を解析して患者資料が炎症性腸疾患またはその臨床的サブタイプと関連しているか否かを決定するための疾患分類処理を実行する。そして、処理により行われた決定は、クライアントシステム１３０に提供される。

特表２０１２−５０８３８３号公報

しかし、上述の検査システムでは、検査端末（検査システム）から収集した患者試験結果に基づき、解析を行い、その診断結果をクライアントに提供するのみであった。すなわち、医師が臨床検査を行う前に、その検査の陽性的中率および陰性的中率（後述）を予めその医師に提示し、医師がその検査を行うべきか中止すべきかの判断を助けるものではなかった。

また、ネットワークを介して、多くの国や地域に分散した、他の検査端末から検査結果や診断結果を取得し、地域ごとに、また経時的に変化する、有病率（後述）、陽性的中率、および陰性的中率を算出し、医師に提供する検査システムはなかった。
また、有病率の精度を向上させる為には、検査結果の総数が非常に多いことが重要であるが、これまでの検査システムでは、総数を増やすことには主眼が置かれていなかった。

また、感染症のパンデミックなどの感染拡大に対応した検査システムは無かった。

その他、上述の検査システムでは、より多数の情報を基に、提供する情報の精度を高めたり、更に付加価値を高めた情報を提供したりすることが出来ないなど、様々な問題があった。

以上のような事情に鑑み、本技術の目的は、臨床検査や治療を、品質やコストなど様々な面で向上させる検査サーバ、通信端末、検査システム、および検査方法を提供することにある。

上記目的を達成するため、本技術の一形態に係る検査サーバは、疾患の有無の検査を実行可能な検査機器と接続可能とされ、かつ当該検査に関する医師による前記疾患の有無の診断の結果の入力が可能な複数の通信端末とネットワークを介して通信する通信部と、前記複数の通信端末から、少なくとも前記検査の結果および前記診断の結果のうち少なくとも一方を検査情報としてそれぞれ前記通信部により取得し、前記取得された複数の検査情報を記憶部に記憶させ、前記記憶された複数の検査情報を統計処理し、前記医師による診断の前に前記通信端末から与えられる要求に応じて、前記統計処理の結果を前記通信部により応答させるように構成された制御部とを具備する。なお、ここでいう検査機器とは、本来の検査機器以外に、検査薬も含むものである。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記制御部は、前記記憶された複数の検査情報における、前記検査の結果および前記診断の結果が共に陽性である前記検査情報の数、前記検査の結果が陰性で前記診断の結果が陽性である前記検査情報の数、前記検査の結果が陽性で前記診断の結果が陰性である前記検査情報の数、および前記検査の結果および前記診断の結果が共に陰性である前記検査情報の数に基づいて、前記統計処理の結果として算出した、有病率、陽性的中率、および陰性的中率のうち少なくとも１つを前記通信部により応答させるように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記制御部は、前記有病率に加えて、前記有病率、前記検査機器の感度、および前記検査機器の特異度に基づいて算出した陽性的中率および陰性的中率を前記通信部により応答させるように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記制御部は、前記検査を行う患者における発症からの経過時間を前記通信端末から取得し、前記発症からの経過時間に対応する感度および特異度を取得し、前記取得された感度および特異度に基づいて前記陽性的中率および前記陰性的中率を算出するように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記制御部は、前記通信端末に接続された検査機器に、前記疾患の検査用の複数種類の検査を実行させ、前記検査機器から前記実行した複数種類の検査の結果を取得し、前記取得した複数種類の検査の結果に基づいて、前記疾患の有無を示す検査の結果を判定するように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記検査機器は、複数種類の検査が実行可能であり、前記制御部は、前記検査機器に前記複数種類の検査のうちの１つの検査を実行させた後、当該１つの検査に関し、陽性尤度比および陰性尤度比のうち少なくとも一方に基づいて、当該１つの検査での検査後オッズを算出して前記通信端末に送信し、前記通信端末から次の検査を行うか否かの情報を取得するように構成された検査システム。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記通信端末から取得される前記検査情報は、前記検査を受ける患者の属性を示す患者属性情報を含み、前記制御部は、前記通信端末から任意の前記患者属性情報を指定した統計情報絞り込み要求を受けたとき、前記患者属性情報の属性を有する検査情報を対象に絞り込んで前記統計処理を行うように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記通信端末から取得される前記検査情報は、前記検査を行う前記通信端末の属性を示す端末属性情報を含み、前記制御部は、前記通信端末から任意の前記端末属性情報を指定した統計情報絞り込み要求を受けたとき、前記端末属性情報の属性を有する検査情報を対象に絞り込んで前記統計処理を行うように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記制御部は、前記絞り込んだ検査情報に基づいて算出された前記統計処理の結果に、前記端末属性情報に基づく重み付けを行うように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記制御部は、陽性率を前記有病率の代わりに用いることが可能なように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記検査情報は、前記検査を行う方法を識別する情報を含み、前記制御部は、同一の前記疾患の前記検査を行う複数の前記方法について、前記各々の方法ごとに、予め与えられた各感度および各特異度のうち、これら感度および特異度が予め要求される所定の値を満足する方法により得られた複数の前記検査情報に対する前記統計処理の結果である前記陽性率を、他の前記方法によって得られた複数の前記検査情報に対する各々の前記統計処理の結果である各々の有病率の代わりに用いることが可能なように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記制御部は、前記陽性的中率を基に、前記検査の有効性を評価し、その評価結果を前記通信端末に送信し、前記通信端末に前記検査の推奨または非推奨のメッセージを提示させるように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記通信端末から取得される前記検査情報は、前記検査を行う前記通信端末の属性を示す端末属性情報として、前記通信端末が位置する地域の情報を含み、前記制御部は、前記検査が未実施である第１の地域における前記有病率を、前記有病率が得られた、前記第１の地域とは異なる１つ以上の第２の地域における各々の有病率と、前記第２の地域各々と前記第１の地域との間における、感染に影響を与える要因を基に推定するように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記制御部は、定期的に前記統計処理を行い前記有病率の履歴情報を作成し、前記履歴情報に基づいて、将来の有病率を予測するように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、前記制御部は、前記記憶された複数の検査情報に代わり、外部から取得した前記統計処理の結果を応答させるように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る検査サーバでは、制御部は、前記検査の結果、前記診断の結果、および前記統計処理の結果のうち少なくとも１つに基づいた薬剤のリストを前記通信端末に送信し、前記通信端末に投薬を推奨する薬剤として前記リストを提示させる、もしくは、前記検査機器で検査可能な前記検査の方法のリストと、前記リスト内で推奨される検査の方法を示す推奨マークと、前記検査を開始するためのユーザインターフェイスとを前記通信端末に表示させるように構成されてもよい。

上記目的を達成するため、本技術の一形態に係る通信端末は、疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報として複数個収集し、収集した複数の前記検査情報を統計処理した結果を提供する検査サーバとネットワークを介して通信する通信部と、医師であるユーザからの入力を受け付ける入力部と、前記検査サーバに前記統計処理の結果の要求を前記通信部により送信させ、検査機器に前記検査を実行させ、前記検査サーバから前記通信部により受信された前記統計処理の結果および当該実行された検査の結果を前記ユーザに提示し、当該実行された検査に関する前記診断の結果を、前記入力部を用いて前記ユーザに入力させ、当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、前記通信部により前記検査サーバへ送信させるように構成された制御部とを具備する。

上記目的を達成するため、本技術の一形態に係る検査システムは、検査サーバと複数の通信端末を具備する検査システムであって、前記検査サーバは、前記複数の通信端末とネットワークを介して通信する第１の通信部と、前記複数の通信端末から、少なくとも疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報としてそれぞれ前記通信部により取得し、前記取得された複数の検査情報を記憶部に記憶させ、前記記憶された複数の検査情報を統計処理し、前記医師による診断の前に前記通信端末から与えられる要求に応じて、前記統計処理の結果を前記通信部により応答させるように構成された第１の制御部とを具備し、前記通信端末は、前記検査サーバと前記ネットワークを介して通信する第２の通信部と、医師であるユーザからの入力を受け付ける入力部と、前記検査サーバに前記統計処理の結果の前記要求を前記通信部により送信させ、検査機器に前記検査を実行させ、前記検査サーバから前記通信部により受信された前記統計処理の結果および当該実行された検査の結果を前記ユーザに提示し、当該実行された検査に関する前記診断の結果を、前記入力部を用いて前記ユーザに入力させ、当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、前記通信部により前記検査サーバへ送信させるように構成された第２の制御部とを具備する。

上記目的を達成するため、本技術の一形態に係る検査方法では、制御部が、疾患の有無の検査を実行可能な検査機器と接続可能とされ、かつ当該検査に関する医師による前記疾患の有無の診断の結果の入力が可能な複数の通信端末から、少なくとも前記検査の結果および前記診断の結果のうち少なくとも一方を検査情報としてそれぞれ前記通信部により取得し、前記取得された複数の検査情報を記憶部に記憶させ、前記記憶された複数の検査情報を統計処理し、前記医師による診断の前に前記通信端末から与えられる要求に応じて、前記統計処理の結果を前記通信部により応答させる。

上記目的を達成するため、本技術の一形態に係る検査方法では、制御部が、疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報として複数個収集し、収集した複数の前記検査情報を統計処理した結果を提供する検査サーバとネットワークを介して通信する通信部により、前記検査サーバに前記統計処理の結果の要求を送信させ、前記検査サーバに前記統計処理の結果の要求を前記通信部により送信させ、検査機器に前記検査を実行させ、前記検査サーバから前記通信部により受信された前記統計処理の結果および当該実行された検査の結果を医師であるユーザに提示し、当該実行された検査に関する前記診断の結果を、前記ユーザからの入力を受け付ける入力部を用いて前記ユーザに入力させ、当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、前記通信部により前記検査サーバへ送信させる。

以上のように、本技術によれば、臨床検査や治療を、品質やコストなど様々な面で向上させることが出来る。なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

ある疾患の臨床検査を、ある検査方法により行った際の状態を表す図である。 陽性的中率および陰性的中率と有病率の関係を表したグラフである。 本技術を採用する検査システム１０が、検査端末２０と検査サーバ４０とを、ネットワークを介して接続した構成であることを示す図である。 検査サーバ４０が一般的なコンピュータにより構成される場合のブロック図である。 データベース４７ａを構成する各レコードにおける、各フィールド（項目）の例を示す図である。 検査端末２０が検査機器と一般的なコンピュータにより構成される場合のブロック図である。 検査システム１０における全体的な処理の流れについて説明するフローチャートである。 有病率を集計し算出する処理の詳細について説明するフローチャートである。 検査の実施について詳細を説明するフローチャートである。 検査の実施の処理において、発症からの経過時間に基づいた感度および特異度を用いる処理を説明するフローチャートである。 検査の実施の処理において、複数の検査を行い、それらの結果を総合的に利用する処理を説明するフローチャートである。 検査の実施の処理において、複数の検査を１つずつ実行し、１つの検査結果が出るたびに、検査を続行するか否かを判断する処理を説明するフローチャートである。 有病率の集計・算出処理において、行政区域および物理的距離に基づいて集計対象データの絞り込みを行ってから、有病率を集計・算出する処理を説明するフローチャートである。 有病率の集計・算出処理において、患者の性別および年齢区分に基づいて集計対象データの絞り込みを行ってから、有病率を集計・算出する処理を説明するフローチャートである。 データベース４７ａにおいて、登録患者数が少なくて遺伝子多型に応じた絞り込みが意味を持たない場合に、当該遺伝子多型に対する有病率を求めるのに、全体の有病率を所定の感度を用いて補正することにより算出する処理のフローチャートである。 感度情報を用いて有病率を補正できる検査サーバ４０ａの構成例を示すブロック図である。 ある行政区域において、データベース４７ａの集計により求まる有病率（診断結果有病率）を、その行政区域における予防接種普及率に基づいて、重み付け補正を行い、真の有病率を予測する処理のフローチャートである。 有病率の代わりに、有病率の代用となる近似的な指標を用いる処理を説明するフローチャートである。 感度および特異度を変化させた時の、有病率と陽性率の関係を示すグラフである。 有病率または有病率を代替する陽性率と、陽性的中率および陰性的中率との関係を示すグラフである。 変形例の構成を採用した場合の、有病率の集計・算出処理について説明するフローチャートである。 算出された陽性的中率の程度により、検査の実施を推奨したり、検査を実施しないことを推奨したりする処理のフローチャートである。 既に検査結果が蓄積されている複数の地域の有病率と、それら複数の地域からの距離に応じて、検査をまだ行っていない地域における有病率を推測する様子を示す図である。 現時点での有病率に加え、今後の予測有病率も提供する処理の流れを説明するフローチャートである。 所定の一定時間ごとの処理と検査実施ごとの処理を表すフローチャートである。 ＬＩＳを用いて診断結果等をアップロードする構成を示す図である。 検査端末２０に、疾患名、有病率、陽性的中率、および陰性的中率に加え、検査端末２０の検査機器２８で実施可能な検査方法のリストが提示され、さらに推奨される検査方法が表示されている具体例を示す図である。

以下、本技術に係る実施形態を、図面を参照しながら説明する。

［背景について］
臨床現場において用いられる検査機器や検査薬、検査キット（以下、まとめて検査機器と呼ぶ）には、検査機器が罹患患者を正しく陽性と判定できる精度（＝感度）と、非罹患者を正しく陰性と判定できる精度（＝特異度）が定義されている。これらの精度は、検査機器の製造時に特定できるものである。これまで、臨床検査では、これらの指標を参考にして、検査結果に対する医師の最終判断が行われてきた。

これに対し、検査機器が示す陽性または陰性という結果に対して、患者が実際に罹患しているか否かを示す確からしさを示す指標として、陽性的中率および陰性的中率という指標がある。

陽性的中率および陰性的中率は、臨床現場において検査機器を用いて疾患の診断を下す医師にとり、検査結果の確からしさを表す非常に重要な指標である。何故重要かは、後述する。この陽性的中率および陰性的中率は、検査機器の感度および特異度と、有病率とから計算することが出来る。逆に言えば、感染症などにおいて有病率が時々刻々と変化する場合、これらの指標の値も時々刻々と変化してしまう。

本技術では、この時々刻々と変化する有病率を適切に扱うことにより、例えば感染症のパンデミックに際して、検査端末を用いて医師がより的確な診断を下せるように助けることが、この検査システムの開発目的の一つである。

すなわち、感染に関する情報を公共機関が提供する例は既に存在するが、各検査機器や各患者に対応してきめ細かい情報を即時的に提供することは不可能であった。このようなきめ細かい情報を即時的に提供する事も、本検査システムの開発目的の一つである。

［有病率について］
ここで、有病率および有病率に関連する指標について、簡単に説明する。図１は、ある疾患の臨床検査を、ある検査方法により行った際の状態を表している。ここで、検査機器により陽性という結果が出て、かつ医師が確かにその患者が疾患に罹患していると最終判断を下したケース（真陽性）に該当する人数をａ人としている。また、検査機器により陽性という結果が出たが、医師によりその患者はその疾患に罹患していないという最終判断を下したケース（偽陽性）に該当する人数をｃ人としている。

また、検査機器により陰性という結果が出たが、医師によりその患者は罹患しているという最終判断が下されたケース（偽陰性）に該当する人数をｂ人としている。また、検査機器により陰性という結果が出て、かつ医師が確かにその患者がその疾患に罹患していないという最終判断を下したケース（真陰性）に該当する人数をｄ人としている。

この図の定義から、有病率は（ａ＋ｂ）／（ａ＋ｂ＋ｃ＋ｄ）により求められることが分かる。また、有病率に関連する各指標（陽性、陰性、陽性率、陰性率、陽性的中率、陰性的中率、疾患数、非疾患数、総数、感度、特異度、および正診率）の定義は、図に示すとおりである。なお、疾患や検査方法が複数ある場合は、疾患と検査方法の組み合わせごとに、この図のような表を作成することが出来る。

以上、有病率および有病率に関連する指標について説明した。

［有病率と陽性的中率、陰性的中率の関係について］
次に、有病率と陽性的中率、陰性的中率の関係について説明する。
まず、ベイズの定理により、ある検査を患者に対して行って、実際に罹患している確率（オッズ）は、その検査を行う前に、その検査で陽性になる検査前オッズと尤度比を用いて、以下の数式（１）のように表される。

検査後オッズ＝検査前オッズ×尤度比 （１）

また、オッズ（Ω）は、確率（ｐ）を用いて以下の数式（２）で表される。

Ω=ｐ／（１−ｐ） （２）

なお、数式（２）より、確率（ｐ）は、オッズ（Ω）を用いて以下の数式（３）で表される。

ｐ＝Ω／（１＋Ω） （３）

また、検査陽性後オッズ（後述）は、検査前オッズと陽性尤度比（後述）を用いて、以下の数式（４）で表される。

検査陽性後オッズ＝検査前オッズ×陽性尤度比 （４）

また、検査陰性後オッズ（後述）は、検査前オッズと陰性尤度比（後述）を用いて、以下の数式（５）で表される。

検査陰性後オッズ＝検査前オッズ×陰性尤度比 （５）

ここで、他の指標の関係についても、その定義式を、以下の数式（６）から数式（１１）で示しておく。

有病率＝疾患数／総数 （６）
検査前オッズ＝有病率／（１−有病率) （７）
検査陽性後オッズ＝陽性的中率／（１−陽性的中率） （８）
検査陰性後オッズ＝陰性的中率／（１−陰性的中率） （９）
陽性尤度比＝感度／（１−特異度）
＝（真陽性数／疾患数）／（偽陽性数／非疾患数） （１０）
陰性尤度比＝（１−感度）／特異度
＝（偽陰性数／疾患数）／（真陰性数／非疾患数） （１１）

以上の数式より、陽性的中率および陰性的中率は、感度、特異度、有病率を用いて下記の数式（１２）および数式（１３）により表される。

陽性的中率＝感度×有病率／(感度×有病率＋(1−有病率)(1−特異度)) （１２）
陰性的中率＝特異度×(１−有病率)／(特異度×(１−有病率)＋有病率×(１−感度)) （１３）

なお、上記の数式は、確率（ｐ）を用いて表しても、オッズ（Ω）を用いて表してもよく、得られる情報は同義のものとなる。

以上、陽性的中率および陰性的中率が、有病率の関数として表すことが出来ることを説明した。

次に、陽性的中率および陰性的中率と有病率の関係をさらに詳しく見ていく。図２は、陽性的中率および陰性的中率と有病率の関係を表したグラフである。なお、この検査で用いる検査機器では、感度９０％、特異度９０％であるとしている。

この図から、例えば有病率が５０％のとき、すなわち診断した患者のうち実際に罹患していた患者の数が半分程度のときには、陽性的中率および陰性的中率とも９０％程度であり、検査結果を信頼することが出来ることが分かる。

しかし、例えば、有病率が５％程度のとき、すなわち１００人診断して罹患者が５人程度のときには、陽性的中率が３０％程度であり、検査結果を信頼することは難しくなることが分かる。

この図には表していないが、診断の精度を上げるために、例えば感度が９９％である検査機器を用いた場合でも、有病率が極めて低い場合、陽性的中率が５０％を下回り、検査結果の信頼性が低くなってしまう。

このように、臨床検査の結果に基づいて疾患の診断を行う医師にとって、有病率は非常に重要な指標となる。

以上、有病率と陽性的中率、陰性的中率の関係について説明した。

［陽性的中率、陰性的中率に基づく治療方針の提示について］
次に、陽性的中率、陰性的中率に基づく治療方針の提示について説明する。ここでは、上述した検査端末において、計算された陽性的中率および陰性的中率に基づいて、検査後に次に採るべき検査方針および治療方針について提示する構成を説明する。

（ＭＲＳＡ感染での重要な指標について）
ここでは、ＭＲＳＡ（Methicillin-resistant Staphylococcus aureus、メチシリン耐性黄色ブドウ球菌）への感染を例に説明する。

院内感染を防ぐために、ＭＲＳＡ感染者に対しては個別管理を行う必要がある。個別管理では、個別部屋の費用などの感染防止対策費用や、医療従事者の手洗い、エプロン着用などの負担が必要になる。

これらの負担を極力減らす為には、本当にその患者がＭＲＳＡに罹患しているか否かを正しく診断することが重要である。検査方法には、遺伝子検査や、イムノアッセイ、培養検査などがある。これらの検査により、ＭＲＳＡへの罹患の有無を検査し、MRSA非感染者を正しくＭＲＳＡ陰性であると示すことが出来れば、個別管理しなければならない罹患者の数を減らすことが出来、感染防止対策費用を減らすことが出来る。この観点から、ＭＲＳＡ感染に関しては、陰性的中率が重要となる。

□（ＭＲＳＡ感染で提示する方針の例について）
次に、感度、特異度、有病率、および陰性的中率がどの程度であるときに、どのような方針を採るべきかについて、具体例を挙げる。

例えば、感度８５％、特異度９０％の検査方法を使用するとき、有病率が４０％以下であれば、この検査の陰性的中率は９０％以上となるので、検査端末は、その検査を実施する事を推奨する提示を行う。

有病率が４０％より高ければ、この検査の陰性的中率は９０％未満となるので、検査端末は、この検査を推奨せず、別のより高感度な検査方法を実行する事を推奨する提示を行うか、または検査はせず患者の個別管理を行う事を推奨する提示を行う。

同様に、感度９０％、特異度９０％の検査方法を使用するとき、有病率が５０％以下であれば、陰性的中率は９０％以上となるので、検査の実行が推奨される。もし有病率が５０％を超えていれば、陰性的中率は９０％未満となるので、その検査の実行を推奨せず、別のより高感度な検査方法を推奨するか、または患者の個別管理を行う事を推奨する。

同様に、感度９５％、特異度９０％の検査方法を使用するとき、有病率が６６．７％以下のとき、陰性的中率は９０％以上となるので、検査を推奨する。もし有病率が６６．７％より高ければ、陰性的中率は９０％未満となるので、検査を推奨せず、別のより高感度な検査方法を推奨するか、または患者の個別管理を推奨する。

（有病率に基づいた検査方法の推奨について）
次に、有病率に基づいて、検査端末はどのような検査方法を医師に推奨できるかを説明する。

上述のとおり、感度、特異性、有病率、および陰性的中率には、所定の関係がある。そこで、有病率が３０％のとき、陰性的中率を９０％以上としたい場合、感度７７％、特異度９０％以上の検査方法を使用すればよいことが分かる。

また、有病率が４０％のとき、陰性的中率を９０％以上としたい場合、感度８５％、特異度９０％以上の検査方法を使用すればよいことが分かる。

また、有病率が５０％のとき、陰性的中率を９０％以上としたい場合、感度９０％、特異度９０％以上の検査方法を使用すればよいことが分かる。

また、有病率が６０％のとき、陰性的中率を９０％以上としたい場合、感度９３％、特異度９０％以上の検査方法を使用すればよいことが分かる。

このことは、具体的な事例に当てはめると、例えば、実行すべき検査方法を検査端末は、医師に対し、次のように推奨することである。すなわち、有病率が３０％のときには、感度は低いがコストを抑えられるイムノクロマトキットの使用を推奨し、有病率が５０％のときには、高コストだが感度が高い遺伝子検査キットや、検査時間は長いが感度が高い培養検査を推奨することが考えられる。

なお、検査システムでは、検査を行う医療機関で実行可能な検査方法のリストを保持しておき、感度、特異度、有病率、および陰性的中率に基づいて、最適な検査方法を医師に推奨する様にしてもよい。

以上、検査端末において、計算された陽性的中率および陰性的中率に基づいて、検査後に次に採るべき検査方針および治療方針について提示する構成を説明した。

［有病率の具体例について］
次に、上述した有病率の具体例について説明する。ここでは、年代、地域、時期、年齢、コミュニティなどに応じて有病率が変化する例を説明する。

（年代に応じて有病率が変化する例）
まず、薬剤耐性菌の有病率が、年代を経るに従って変化している様子を説明する。ここでの説明は、米国のＣＤＣ（Centers for Disease Control and Prevention、アメリカ疾病管理予防センター）の作成した、薬剤耐性菌の罹患率の変化に関する情報に基づいている。なお、罹患率と有病率は類似の指標であり、ここでは有病率と読み替えて説明する。

米国における黄色ブドウ球菌のうちメチシリン耐性黄色ブドウ球菌（ＭＲＳＡ）の割合は、１９８０年では約５％であったのに対し、１９９０年では約３０％、２０００年では約５０％と変化している。同様に、腸球菌のうちのバンコマイシン耐性腸球菌（Vancomycin-resistant Enterococcus、ＶＲＥ）の割合や肺炎球菌のうちのフルオロキノロン耐性肺炎球菌（Fluoroquinolone-resistant Pseudomonas Aeruginosa、ＦＱＲＰ）の割合は、１９９０年には２％以下であったのに対し、２０００年では２０％以上と変化している。

このように、薬剤耐性菌の有病率は年代と共に変化しているため、診断の精度を高めるためには、検査を行う時に最新の有病率を把握していることは重要である。

（地域（国）に応じて有病率が変化する例）
次に、薬剤耐性菌の有病率が、地域（国）により変化する様子を説明する。ここでの説明は、European Antimicrobial Resistance Surveillance System (EARSS)のEuro Surveillance 2008 Nov 20 Volume 13, Issue 47の資料に基づいている。この資料は、ヨーロッパにおける国別の薬剤耐性菌の有病率を示したものである。

ＥＡＲＳＳの資料によると、２００７年における腸球菌のうちのＶＲＥの割合はアイルランド、ギリシャで３０％以上、イギリスで３０−２０％、チェコで２０−１０％、イタリア、ドイツ、ポルトガルで１０−５％、スペイン、フランス、スイス、オーストリアなどで５−１％、ノルウェー、スウェーデン、フィンランド、ポーランドなどで１％以下となっている。

このように、有病率は地域や国によっても異なるため、診断の精度を高めるためには検査を行う地域の有病率を把握していることは重要である。

（インフルエンザウイルスの有病率の例１）
次に、インフルエンザウイルスの有病率が、時期や地域によって変動する様子を説明する。ここでは、東京都健康安全研究センターの資料を用いる。この資料は、定点あたりのインフルエンザの患者数を時期ごとおよび年ごとに表したものである。

この資料によると、インフルエンザウイルスの有病率は、６月、７月に少ない一方、２月、３月は例年高い傾向がある。しかし、その傾向の中でも、流行開始時期は各年で異なり、その有病率も大きく異なる。さらに、２００９年に流行したパンデミック株(H1pdm) のように、例年は流行しない１０月、１１月、１２月に有病率が高くなる場合もある。

また、ここでは図示しないが、国立感染症研究所の病原微生物検出情報（IASR、http://idsc.nih.go.jp/iasr/influ.html）でも、地方衛生研究所から、感染症発生動向調査の報告として、定点およびその他の医療機関、保健所等における病原体の感染件数が報告されている。このＩＡＳＲによると、インフルエンザウイルスの流行時期および流行地域に差があることがわかる。さらには、インフルエンザウイルスの型によっても流行時期や流行地域に差があることがわかる。

このように、インフルエンザウイルスの有病率は、年によっても、時期によっても、ウイルス型によっても大きく異なる。そのため、診断の精度を高めるためには検査を行う際に、非常に迅速かつ継続的に、有病率情報を収集できる検査システムが有効になる。

（インフルエンザウイルスの有病率の例２）
次に、インフルエンザウイルスの有病率が、患者の年齢や所属するコミュニティによって変動する様子を説明する。ここでは厚生労働省と奈良県郡山保健所の資料を用いて説明する。この資料は、厚生労働省の感染症発生動向調査における、年齢階級別の推計受診者数を表したものである。

この資料によると、０−１４歳、特に５−９歳におけるインフルエンザウイルスの有病率が、他の年齢階級と比較して高い傾向にある。すなわち、有病率は、年齢階級によって、大きく変化していることがわかる。

そのため、被検者の年齢に応じて、最適な有病率を用いて検査結果を判断することが重要である。

また、患者が所属するコミュニティによっても、有病率は異なる。例えば、奈良県郡山保健所が報告している「２０１２−２０１３シーズンにおけるインフルエンザ発生状況について」では、小学生低学年におけるインフルエンザウイルスの有病率が高い、という報告例がある。例えば、２０１１−２０１２シーズンにおける、ある小学校の小学生１年生の有病率は３０％以上であった、という報告例がある。

一方、厚生労働省の入院サーベイランス、感染症発生動向調査によると、日本における２０１１−２０１２年シーズンにおけるインフルエンザウイルス様の有病率は、１６４８万人と推計されている。２０１０年の国勢調査の結果から、日本の人口を１億２８００万人とすると、インフルエンザウイルスの有病率は、最高値でも１２．９％となり、奈良県の例とは異なっている。すなわち、コミュニティによってインフルエンザウイルスの有病率が異なることが示唆されている。

そのため、被検者の所属するコミュニティに応じて、最適な有病率を用いて検査結果を判断することが重要となる。

以上、有病率の具体例について説明した。

［検査システムの構成について］
次に、本技術を適用する検査システムの全体構成について説明する。本技術を用いた検査システムでは、クライアント・サーバ構成を採る。図３は、本技術を採用する検査システム１０が、検査端末２０と検査サーバ４０とを、ネットワークを介して接続した構成であることを示す図である。この図にあるように、本技術を採用する検査システム１０では、クライアントとなる複数の検査端末２０が、各国、各地域、各施設に分散して配置されており、それらの検査端末２０が、ネットワーク３０を介して、検査サーバ４０と接続されている。

（クライアント・サーバ構成を採る理由）
まず、本技術を採用する検査システム１０が、クライアント・サーバ構成でなければならない理由について、説明する。

上述したとおり、本技術では、最新の有病率を用いることがポイントの一つである。この有病率は、上述の定義から分かるように、検査総数が大きければ大きいほど、計算される有病率の精度が高まる。

そして、検査総数を大きくするためには、１つの検査端末において数多く検査するアプローチと、数多くの検査端末から検査結果を収集するアプローチとがある。本技術では、数多くの検査端末から検査結果を収集するアプローチを実現するために、検査システム１０の構成として、検査サーバ４０と複数の検査端末２０からなる、クライアント・サーバ構成を採用している。

この構成を採ることにより、クライアントである検査端末２０の数をできる限り増やすことが可能となり、検査サーバ４０から検査端末２０に提供する有病率の精度を向上させることが出来る。

（検査サーバ４０の構成について）
次に、検査サーバ４０のハードウェア構成について説明する。検査サーバ４０は、専用のハードウェアやソフトウェアにより構成されていてもよいし、一般的なコンピュータにより構成されてもよい。検査サーバ４０が一般的なコンピュータにより構成される場合のブロック図を図４に示す。

同図に示すように、検査サーバ４０は、ＣＰＵ（Central Processing Unit、制御部、第１の制御部）４１、ＲＯＭ（Read Only Memory）４２、ＲＡＭ（Random Access Memory）４３、操作入力部４４、ネットワークインターフェイス部（通信部、第１の通信部）４５、表示部４６、及び記憶部４７を有し、これら各ブロックがバス４８を介して接続されている。

ＲＯＭ４２は、各種の処理を実行するためのファームウェア等の複数のプログラムやデータを固定的に記憶する。ＲＡＭ４３は、ＣＰＵ４１の作業用領域として用いられ、ＯＳ（Operating System）、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。

記憶部４７は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリ、その他の固体メモリ等の不揮発性メモリである。当該記憶部４７には、ＯＳや各種アプリケーション、各種データに加え、後述するデータベース４７ａが記憶される。

ネットワークインターフェイス部４５は、検査端末２０と情報のやりとりを行う為のネットワーク３０と結ばれており、検査端末２０から情報を収集したり、検査端末２０に加工した情報を提供したりする。

ＣＰＵ４１は、ＲＯＭ４２や記憶部４７に格納された複数のプログラムのうち、操作入力部４４から与えられる命令に対応するプログラムをＲＡＭ４３に展開し、当該展開されたプログラムにしたがって、表示部４６及び記憶部４７を適宜制御する。

また、ＣＰＵ４１は、ネットワーク３０およびネットワークインターフェイス部４５を介して検査端末２０から収集した情報に基づき、データベース４７ａを更新する。そして、ＣＰＵ４１は、検査端末２０から受信した情報の要求が指定する条件に基づき、データベース４７ａから必要な情報を抽出し、集計して各検査端末２０に返信する。

操作入力部４４は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の操作装置である。

表示部４６は、例えば液晶ディスプレイ、ＥＬ（Electro-Luminescence）ディスプレイ、プラズマディスプレイ、ＣＲＴ（Cathode Ray Tube）ディスプレイ等である。当該表示部４６は、検査サーバ４０に内蔵されていてもよいし、外部接続されていてもよい。

以上、検査サーバ４０の構成について説明した。

（データベース４７ａについて）
次に、データベース４７ａ内に格納されるレコードの構成例について説明する。図５は、データベース４７ａを構成する各レコードにおける、各フィールド（項目）の例を示す図である。なお、これらの項目を検査情報と呼ぶ。

この図の例では、左から順に、Instrument ID（機器ＩＤ）、Patient ID（患者ＩＤ）、Sample ID（検体ＩＤ）、Date（検査日付）、Address（住所、行政区域）、Country（国）、Gender（性別）、Age（年齢）、Assay result（検査結果）、Diagnosis（医師の診断結果）の項目が並んでいる。

これらの項目は、例示であり、検査サーバ４０が収集、抽出、および集計する情報の種類により、より多くの項目を設けたり、より少ない項目に絞ったりしてもよい。項目を増やす場合、例えば、疾患ＩＤ、検査方法ＩＤなどを加えることが考えられる。これらの疾患ＩＤや検査方法ＩＤを加えることにより、本検査システムを、複数の疾患や複数の検査方法に対応させることが出来る。なお、これらの項目の使用方法は、後述する。

（検査端末２０の構成について）
次に、検査端末２０のハードウェア構成について説明する。検査端末２０は、専用のハードウェアやソフトウェアにより構成されていてもよいし、検査機器と一般的なコンピュータにより構成されてもよい。検査端末２０が検査機器と一般的なコンピュータにより構成される場合のブロック図を図６に示す。

同図に示すように、検査端末（通信端末）２０は、ＣＰＵ（制御部、第２の制御部）２１、ＲＯＭ２２、ＲＡＭ２３、操作入力部（入力部）２４、ネットワークインターフェイス部（通信部、第２の通信部）２５、表示部２６、記憶部２７、および検査機器２８を有し、これら各ブロックがバス２９を介して接続されている。なお、検査サーバ４０の構成要素と同じ機能を持つ構成要素については、説明を省略する。

ネットワークインターフェイス部２５は、検査サーバ４０と情報のやりとりを行う為のネットワーク３０と結ばれており、検査サーバ４０に情報を送信したり、検査サーバ４０で加工された情報を受信したりする。

ＣＰＵ２１は、ネットワーク３０およびネットワークインターフェイス部２５を介して検査サーバ４０から受信した情報を表示部２６を介してユーザである医師に提示したり、受信した情報に基づき後述する様々な処理を行ったりする。また、ＣＰＵ２１は、検査機器２８での検査結果や疾患の診断を行った医師の最終的な診断結果を、ネットワーク３０およびネットワークインターフェイス部２５を介して、検査サーバ４０に送信する。

検査機器２８は、実際に疾患の検査を行う機器である。検査の結果は、ＣＰＵ４１により読み取られ、検査を行った医師に表示部２６を介して提示されたり、ネットワーク３０を介して検査サーバ４０に送信されたりする。なお、検査機器として検査キットを使用する場合、検査端末２０が自動で検査結果を読み取ってもよいし、検査結果が手動で検査端末２０に入力されてもよい。

以上、検査端末２０の構成について説明した。

［検査システム１０の処理の流れについて］
次に、検査システム１０にて行われる処理の流れについて説明する。最初に全体的な流れを説明し、次に個々の処理の詳細について説明し、最後に、応用例または変形例としても処理の流れについて説明する。

（全体的な処理の流れ）
まず、検査システム１０における全体的な処理の流れについて説明する。図７は、検査システム１０における全体的な処理の流れについて説明するフローチャートである。

最初に、検査サーバ４０のＣＰＵ４１が、検査サーバ４０において、データベース４７ａを用いて、１つの疾患、１つの検査方法に対する有病率を集計し算出する（ステップＳ１０）。なお、この集計算出処理については詳細を後述する。なお、この集計算出処理は、一定時間ごと（例えば１時間や１日ごと）に処理が開始されてもよいし、医師がこれから検査を実施しようとしている検査端末２０からのリクエスト（要求）をトリガとして開始されてもよい。

次に、これから検査を実施する検査端末２０において、その検査端末２０のＣＰＵ２１が、検査サーバ４０において算出された有病率のダウンロードを行う（ステップＳ２０）。なお、ダウンロードは、検査端末２０からのプル通信により行われてもよいし、検査サーバ４０からのプッシュ通信により行われてもよい。

次に、有病率をダウンロードした検査端末２０において、ＣＰＵ２１が、上述した数式（１２）および数式（１３）に従い、陽性的中率および陰性的中率の算出を行う（ステップＳ３０）。なお、数式を再度示すと、以下のとおりである。また、感度および特異度の値は、予め検査端末２０が保持しているものとする。

陽性的中率＝感度×有病率／(感度×有病率＋(1−有病率)(1−特異度)) （１２）
陰性的中率＝特異度×(１−有病率)／(特異度×(１−有病率)＋有病率×(１−感度)) （１３）
なお、陽性的中率および陰性的中率は、有病率を用いずに、それぞれ直接、式ａ／（ａ＋ｃ）およびｄ／（ｂ＋ｄ）から求めてもよい。

次に、有病率をダウンロードした検査端末２０において、ＣＰＵ２１が、表示部２６を介して、有病率、陽性的中率、および陰性的中率をユーザである医師に提示する（ステップＳ４０）。

次に、有病率をダウンロードした検査端末２０の検査機器２８において、ユーザの指示により、検査が実施される（ステップＳ５０）。この検査の処理の詳細は後述する。

次に、有病率をダウンロードした検査端末２０において、ＣＰＵ２１が、検査端末２０に入力された診断結果等（検査情報）の検査サーバ４０へのアップロードを行う（ステップＳ６０）。なお、ここでアップロードする検査情報は、上述したデータベース４７ａのレコードを構成する項目と同じものであってよい。また、アップロードは、検査端末２０から直接行われてもよいし、院内情報システム（ＬＩＳ、Laboratory Information System）やスマートフォンを経由して行われてもよい。アップロード方法の詳細については、後述する。

次に、検査サーバ４０において、ＣＰＵ４１が、アップロードされた診断結果等の検査情報を、データベース４７ａに登録する（ステップＳ７０）。

ステップＳ７０でのデータベース４７ａへの登録後、処理はステップＳ１０に戻り、上記の処理が繰り返される。

以上、検査システム１０における全体的な処理の流れについて説明した。

（有病率の集計・算出処理について）
次に、上述した有病率を集計し算出する処理の詳細について説明する。図８は、有病率を集計し算出する処理の詳細について説明するフローチャートである。

最初に、検査サーバ４０のＣＰＵ４１は、集計時にカウントアップに用いる変数である、診断総件数および疾患件数をゼロクリアして初期化する（ステップＳ１１）。

次に、ＣＰＵ４１は、データベース４７ａのレコードを全て読んだか否かを判断する（ステップＳ１２）。なお、全て読んだか判断するのは、データベース４７ａが、１つの疾患、１つの検査方法に関するレコードから構成されている場合である。複数の疾患、複数の検査方法に関するレコードがデータベース４７ａに含まれている場合は、集計の対象となる疾患や検査方法に関するレコードの全てを読んだか判断してもよい。

この時点では、まだデータベース４７ａの全レコードを読み終わっていない（ステップＳ１２のＮ）ので、次に、ＣＰＵ４１は、データベース４７ａからレコードを１件読み込む（ステップＳ１３）。

次に、ＣＰＵ４１は、診断総件数を１だけカウントアップする（ステップＳ１４）。

次に、ＣＰＵ４１は、読み込んだレコードの１つのフィールドである、医師の「診断結果」が陽性であるか否かを判断する（ステップＳ１５）。

陽性である場合（ステップＳ１５のＹ）のみ、疾患件数を１だけカウントアップする（ステップＳ１６）。

ステップＳ１５で陰性であった場合（ステップＳ１５のＮ）、またステップＳ１６で疾患件数をカウントアップした後、ＣＰＵ４１は処理をステップＳ１２に戻して処理を続行する。

ステップＳ１２において、データベース４７ａ内の全レコードの読み出しが終了した場合（ステップＳ１２のＹ）、次に、ＣＰＵ４１は、数式（６）に従い、診断総件数および疾患件数から有病率を算出する（ステップＳ１７）。なお、数式（６）は以下のとおりである。

有病率 ＝ 疾患数 ／ 総数 （６）

以上、有病率を集計し算出する処理の詳細について説明した。なお、上記の説明では、データベース４７ａ内の全てのレコードを処理対象としたが、これに限らず、例えば、レコードに「データ登録日時」の項目を設け、過去の一定期間内に登録されたレコードのみを処理対象とする構成でもよい。

また、上記の説明では、有病率を求めるためにデータベース４７ａ内のレコードをカウントしたが、これに限らず、検査システム１０の外部から有病率の値を取得する構成でもよい。取得する方法は、ネットワーク３０を経由したものでもよいし、論文などから有病率の数値を抽出し、検査サーバ４０に手入力する方法でもよい。論文などから数値を手入力する際には、入力を簡略化するための規格があることが望ましい。

（検査の実施について）
次に、上述した検査の実施について詳細を説明する。図９は、検査の実施について詳細を説明するフローチャートである。

最初に、ユーザが、検査端末２０の操作入力部２４などを介して、患者情報の入力を行う（ステップＳ５１）。

次に、ユーザまたは検査端末２０のＣＰＵ２１の指示により、検査機器２８において、検査が実行される（ステップＳ５２）。

次に、ＣＰＵ２１が、検査機器２８での検査結果を読み取り、表示部２６を介して、ユーザである医師に検査結果を提示する（ステップＳ５３）。

次に、医師が、検査端末２０に表示された、有病率、陽性的中率、陰性的中率、および検査結果に基づいて、最終的な診断結果を検査端末２０に入力する（ステップＳ５４）。診断結果の入力に際し、医師は、有病率、陽性的中率、および陰性的中率を参照することで、より高精度に最終的な診断を下すことが出来る。

以上、検査の実施について詳細を説明した。

（変形例１ 検査サーバ４０での陽性的中率等の算出）
上記の説明では、検査端末２０が、その検査端末自身の感度および特異度の情報を持っており、検査サーバ４０からは有病率のみをダウンロードして、検査端末２０側で、陽性的中率および陰性的中率を計算する処理を説明した。

これに対し、ここで説明する変形例では、検査サーバ４０が、様々なタイプの検査機器２８の感度および特異度の情報を保持している。なお、ここでいう感度および特異度の値は、検査機器２８の性能として検査機器２８のメーカーにより提供された、検査機器２８に固有の値を用いることが出来る。検査端末２０は、有病率などの情報を要求する前に、自身の機器ＩＤなどを検査サーバ４０に通知し、検査サーバ４０は、通知された機器ＩＤに紐付けられた感度および特異度の値を用いて、検査サーバ４０上で、陽性的中率および陰性的中率を算出する。検査端末２０は、有病率、陽性的中率、および陰性的中率を検査サーバ４０からダウンロードし、ユーザに提示する。

この構成を採ることにより、検査端末での陽性的中率および陰性的中率の計算処理を省略することが出来る。また、検査端末２０ごとの感度および特異度を検査サーバ４０側で任意に調整することが出来るようになる。

（変形例２ より多くの情報のダウンロードと提示）
上記の説明では、検査サーバ４０から検査端末２０に、有病率のみ、または、有病率、陽性的中率、および陰性的中率の３つをダウンロードする構成とした。これに対し、ここで説明する変形例では、より多くの情報をダウンロードし、ユーザに提示してもよい。例えば、診断総件数や疾患件数などである。これらもユーザに提示することにより、算出された陽性的中率および陰性的中率の妥当性を判断することが出来る。

（変形例３ 適切な感度・特異度による的中率の向上）
上記の説明では、感度および特異度は、検査機器２８において一意に決定されるものとした。これに対し、ここで説明する変形例では、感染症などの病気を発病してからの経過時間によって、感度および特異度を変化させる構成について説明する。

例えば、呼吸器感染症の場合、鼻腔や咽頭に存在する病原体の数は、病気を発症してからの経過時間と共に変動することが知られている。病原体の数の変化と共に、検査の感度および特異度も変動する。そのため、患者が発症してからの経過時間に基づいて、適切な感度および特異度の値を用いることにより、求める陽性的中率および陰性的中率の精度を向上させることが出来る。

図１０は、上述した検査の実施の処理において、発症からの経過時間に基づいた感度および特異度を用いる処理を説明するフローチャートである。

最初に、ユーザが、検査端末２０に患者情報の入力を行う（ステップＳ５１ａ）。この患者情報の入力の際に、発症からの経過時間も入力される。

次に、検査端末２０のＣＰＵ２１が、入力された、発症からの経過時間に基づいた感度および特異度を取得する（ステップＳ５１ｂ）。なお、取得する感度および特異度は、予め検査端末２０に保持されていてもよいし、それら感度および特異度を保持している検査サーバ４０からダウンロードしてもよい。

感度および特異度を取得し易くするための規格があることが望ましい。例えば、診断キットのパッケージにバーコードを表示させ、このバーコードをスキャンすることにより、特定の感度および特異度を検査システム１０に取り込むようにしてもよい。

また、検査システム１０内に、検査機器２８ごとの感度および特異度に関するデータベースを構築し、検査機器２８の医療機器認証番号から、検査機器２８の感度および特異度、発症時間ごとの感度および特異度、患者の年齢ごとの感度および特異度などが取得できるようにしてもよい。

次に、ＣＰＵ２１は、取得した有病率、感度、および特異度を用いて陽性的中率および陰性的中率を算出する（ステップＳ５１ｃ）。

次に、ＣＰＵ２１は、算出した陽性的中率および陰性的中率をユーザに提示する（ステップＳ５１ｄ）。なお、陽性的中率および陰性的中率をユーザに提示する際には、取得した有病率、感度、および特異度も一緒に提示してもよい。

ステップＳ５１ｄ以降の処理は、上述したものと同じなので、説明を省略する。

以上、感染症などの病気を発病してからの経過時間によって、感度および特異度を変化させる構成について説明した。

（変形例４ 複数の検査の組み合わせ（検査結果の統合））
上記の説明では、疾患の検査として、１つの検査を実行する構成を説明した。これに対し、ここで説明する変形例では、複数種類の検査を実行し、それらの結果を総合して最終的な検査結果（最終的な診断結果ではない）を出力する構成を説明する。この変形例の構成では、複数種類の検査を行い、すべての検査で陽性となった場合のみ最終的な検査結果を陽性としてもよい。これにより、尤度（感度および特異度）の精度を向上させることが出来、最終的に算出される陽性的中率および陰性的中率の精度も向上させることが出来る。

図１１は、上述した検査の実施の処理において、複数の検査を行い、それらの結果を総合的に利用する処理を説明するフローチャートである。

最初に、ユーザが患者情報の入力を行う（ステップＳ５１）。このステップは、上述したものと同じである。

次に、検査端末２０は、複数種類（この例では検査Ａ、Ｂ、Ｃの３種類）の検査を実行する（ステップＳ５２ａ，５２ｂ，５２ｃ）。検査の実行は、同時並行して行われてもよいし、順に一つずつ行われてもよい。ただし、検査結果の判断は、全ての検査結果がそろってから行われる。

次に、検査端末２０のＣＰＵ２１は、各検査の検査結果は全て陽性であるか否かを判断する（疾患の有りを示す検査の結果を判定する）（ステップＳ５２ｄ）。

全て陽性である場合（ステップＳ５２ｄのＹ）、ＣＰＵ２１は、最終的な検査結果を陽性とする（ステップＳ５２ｅ）。なお、ここでは、検査結果が全て陽性である場合に、最終的な検査結果を陽性としたが、各検査の感度などの条件では、ＣＰＵ２１は、必ずしも全て陽性でなくても最終的な検査結果を陽性と判断する場合もある。

１つでも陰性がある場合（ステップＳ５２ｄのＮ）、ＣＰＵ２１は、最終的な検査結果を陰性とする（疾患の無しを示す検査の結果を判定する）（ステップＳ５２ｆ）。

ステップ５３以降の処理は、上述したものと同じなので、説明は省略する。なお、ここで求めた「最終的な検査結果」を上述した「検査結果」として、以降の処理は行われる。

以上、複数の検査を実行し、それらの結果を総合して最終的な検査結果を出力する構成を説明した。

（変形例５ 複数の検査の組み合わせ（段階的な検査の実行））
上記の、複数の検査を組み合わせる変形例では、全ての検査を行った後に、全ての検査結果を統合して処理する構成を説明した。これに対し、ここで説明する変形例では、複数の検査を１つずつ実行し、１つの検査結果が出るたびに、検査を続行するか否かを判断する。この変形例では、段階的に検査を行うことにより、有病率に基づいた最終的な診断結果の精度を向上させることが出来る。

この変形例の構成では、例えば、検査Ａ、検査Ｂ、検査Ｃを順に行う場合、それぞれの検査で陽性との結果が出るにつれ、患者が本当に陽性であるオッズが上昇する。それぞれの検査の検査後オッズ（検査陽性後オッズおよび検査陰性後オッズ）に応じて、次の検査のコストや引き起こされる可能性がある副作用とのトレードオフを考慮することが出来る。そして、場合によっては次の検査は行わずに、患者は陽性であると診断して、患者の治療を進めるという選択も可能になる。

図１２は、上述した検査の実施の処理において、複数の検査を１つずつ実行し、１つの検査結果が出るたびに、検査を続行するか否かを判断する処理を説明するフローチャートである。ここでは、複数の検査として、検査Ａ、検査Ｂ、検査Ｃが順に行われる構成としている。

最初に、検査端末２０のＣＰＵ２１が、検査サーバ４０からダウンロードした有病率に基づいて、数式（７）を用いて検査前オッズを算出する（ステップＳ４９ａ）。

次に、ＣＰＵ２１は、表示部２６を介して、算出した検査前オッズをユーザである医師に提示する（ステップＳ５３ａ）。

次に、医師は、検査Ａを実行する必要があるか否かを判断する（ステップＳ５５）。

実行は不要であると判断された場合（ステップＳ５５のＮ）、何も検査は行わない。

検査Ａの実行は必要であると判断された場合（ステップＳ５５のＹ）、次に、操作入力部２４が、ユーザから患者情報の入力を受け付ける（ステップＳ５１）。

次に、検査端末２０の検査機器２８が、検査Ａを実行する（ステップＳ５２ａ）。

次に、ＣＰＵ２１は、検査Ａの結果と、検査Ａに関する検査前オッズおよび陽性尤度比に基づいて、数式（４）を用いて検査Ａでの検査陽性後オッズを算出する（ステップＳ４９ｂ）。なお、ここでは陽性尤度比を用いているが、これに限らず、陽性尤度比および陰性尤度比のうち少なくとも一方を用いる構成でもよい。

次に、ＣＰＵ２１は、検査陽性後オッズをユーザに提示する（ステップＳ５３ｂ）。

次に、医師は、提示された検査陽性後オッズを参照して、追加の検査が必要か否かを判断する（ステップＳ５６）。

追加の検査は不要であると判断された場合（ステップＳ５６のＮ）、検査Ｂおよび検査Ｃは行われない。処理は、医師の診断結果の入力（ステップＳ５４）に進む。

追加の検査が必要であると判断された場合（ステップＳ５６のＹ）、次に、ＣＰＵ２１は、検査機器２８に検査Ｂを実行させる（ステップＳ５２ｂ）。

次に、ＣＰＵ２１は、検査Ａの検査結果、検査Ｂの検査結果、および検査Ｂに関する検査前オッズおよび陽性尤度比に基づいて、ステップＳ４９ｂと同様に、検査Ｂでの検査陽性後オッズを算出する(ステップＳ４９ｃ)。

次に、ＣＰＵ２１は、算出した検査陽性後オッズをユーザである医師に提示する（ステップＳ５３ｃ）。

次に、医師は、さらに追加の検査が必要か否かを判断する（ステップＳ５７）。

更なる追加の検査は不要であると判断された場合（ステップＳ５７のＮ）、検査Ｃは行われない。処理は、医師の診断結果の入力（ステップＳ５４）に進む。

更に追加の検査が必要であると判断された場合（ステップＳ５７のＹ）、次に、ＣＰＵ２１は、検査機器２８に検査Ｃを実行させる（ステップＳ５２ｃ）。

次に、ＣＰＵ２１は、検査Ｃの検査結果をユーザに提示する（ステップＳ５３ｄ）。

次に、医師が、検査結果を参照して、最終的な診断結果を検査端末２０に入力する（ステップＳ５４）。

以上が、複数の検査を１つずつ実行し、１つの検査結果が出るたびに、検査を続行するか否かを判断する処理について説明した。

（変形例６ 検査端末の属性による対象データの絞り込み）
上記の説明では、データベース４７ａに格納している全てのレコード、すなわち全ての検査結果を対象として、有病率を集計し算出した。これに対し、ここで説明する変形例では、検査端末２０の属性（端末属性情報）に基づいて、有病率の集計と算出の基となる検査結果を絞り込む構成を説明する。

ここで説明する例では、有病率を要求する検査端末２０の属する行政区域（例えば東京都）で行われた検査の結果のみに、有病率の算出に用いる検査結果を絞り込んだり、その検査端末２０からの物理的な距離（例えば５０ｋｍ）の範囲内で取得された検査の結果のみに絞り込んだりしている。すなわち、検査端末２０の属性による絞り込みである。なお、ここでいう絞り込みとは、ある条件に合致する検査結果のみを有病率の集計に使用するということである。

このように、有病率の算出に際して、様々な絞り込みを行うことにより、個々の検査端末２０に対して、より適切な情報を提供することが出来る。

図１３は、上述した有病率の集計・算出処理において、行政区域および物理的距離に基づいて集計対象データの絞り込みを行ってから、有病率を集計・算出する処理を説明するフローチャートである。

最初に、検査サーバ４０のＣＰＵ４１が、有病率などの情報提供先となる検査端末２０から、その検査端末２０の属する行政区域と、現在位置および求めたい範囲の物理的距離（半径）を取得する（ステップＳ９ａ）。

次に、ＣＰＵ４１は、集計時にカウントアップを行う為の変数である、同一行政区域の診断総件数と疾患件数、および指定距離内の範囲において検査された検査結果の診断総件数と疾患件数をゼロクリアして初期化する（ステップＳ１１ａ）。

次に、ＣＰＵ４１は、データベース４７ａのレコードを全て読んだか否かを判断する（ステップＳ１２）。

この時点では、まだデータベース４７ａの全レコードを読み終わっていない（ステップＳ１２のＮ）ので、次に、ＣＰＵ４１は、データベース４７ａからレコードを１件読み込む（ステップＳ１３）。

次に、ＣＰＵ４１は、読み込んだレコードの行政区域と、検査端末２０の行政区域が同一であるか否かを判断する（ステップＳ１８ａ）。なお、ここで使う「行政区域」の項目は、データベース４７ａ内の「住所」の項目の一部として導き出すことが出来る。

行政区域が同一の場合（ステップＳ１８ａのＹ）、次に、ＣＰＵ４１は、同一行政区域の診断総件数を１だけカウントアップする（ステップＳ１４ａ）。

次に、ＣＰＵ４１は、読み込んだレコードの１つのフィールドである、医師の「診断結果」が陽性であるか否かを判断する（ステップＳ１５）。

陽性である場合（ステップＳ１５のＹ）のみ、同一行政区域の疾患件数を１だけカウントアップする（ステップＳ１６ａ）。

ステップ１８ａで行政区域が異なっている場合（ステップＳ１８ａのＮ）、ステップＳ１５で陰性であった場合（ステップＳ１５のＮ）、またはステップＳ１６ａで疾患件数をカウントアップした後、ＣＰＵ４１は処理をステップＳ１８ｂに進めて処理を続行する。

次に、ＣＰＵ４１は、読み込んだレコード内の検査が行われた位置と、検査端末２０の現在位置の距離が指定範囲内か否かを判断する（ステップＳ１８ｂ）。

距離が指定範囲内の場合（ステップＳ１８ｂのＹ）、次に、ＣＰＵ４１は、指定距離内の診断総件数を１だけカウントアップする（ステップＳ１４ｂ）。

次に、ＣＰＵ４１は、読み込んだレコードの１つのフィールドである、医師の「診断結果」が陽性であるか否かを判断する（ステップＳ１５）。

陽性である場合（ステップＳ１５のＹ）のみ、指定距離内の疾患件数を１だけカウントアップする（ステップＳ１６ｂ）。

ステップ１８ｂで指定距離内ではない場合（ステップＳ１８ｂのＮ）、ステップＳ１５で陰性であった場合（ステップＳ１５のＮ）、またはステップＳ１６ｂで疾患件数をカウントアップした後、ＣＰＵ４１は処理をステップＳ１２に戻して処理を続行する。

ステップＳ１２において、データベース４７ａ内の全レコードの読み出しが終了した場合（ステップＳ１２のＹ）、次に、ＣＰＵ４１は、数式（６）に従い、同一行政区域の、診断総件数および疾患件数から、同一行政区域の有病率を算出し、指定範囲内の、診断総件数および疾患件数から、指定範囲内の有病率を算出する（ステップＳ１７ａ）。

以上、検査端末２０の属性に基づいて、有病率の集計と算出の基となる検査結果を絞り込む構成を説明した。

（変形例７ 患者属性による対象データの絞り込み）
上記の絞り込みを行う変形例では、検査端末２０の属性に基づいて、有病率の集計と算出の基となる検査結果を絞り込む構成を説明した。これに対し、ここで説明する変形例では、検査端末２０の属性に代わり、検査を受ける患者の属性（患者属性情報）に基づいて、有病率の集計と算出の基となる検査結果を絞り込む構成を説明する。

ここで説明する例では、有病率を要求する検査端末２０により検査を行う患者の性別や年齢に基づいて、集計対象とする検査結果を絞り込み、有病率を集計・算出する。但し、ここで説明する絞り込みの例では、上記の検査端末２０の属性による絞り込みとは異なり、正確には、属性の内容ごとの分別である。

例えば、性別での絞り込みでは、患者の性別と同一の性別のみを集計するのではなく、男性、女性、それぞれの集計を行い、それぞれの値を保持しておく。そして、性別の有病率が要求される場合、検査サーバ４０は、男性、女性それぞれの有病率をまとめて、検査端末２０に提供する。

なお、上記の検査端末２０の属性による絞り込みの例と同様に、最初に、検査する患者の性別情報を取得し、データベース４７ａから、性別が男性だけのレコードを抽出して集計し、男性の有病率のみを算出する構成も採ることができることは言うまでもない。一般的ではない、あまり検査端末２０から求められることがない属性に関する有病率を算出する場合は、その要求が発生する度に、毎回その属性に関する抽出を行うほうが効率的である。

このように、有病率の算出に際して、様々な絞り込みを行うことにより、個々の患者に対して、より適切な情報を提供することが出来る。

図１４は、上述した有病率の集計・算出処理において、患者の性別および年齢区分（例えば、０歳から９歳、１０歳から１９歳など、１０歳ごとの区分）に基づいて集計対象データの絞り込みを行ってから、有病率を集計・算出する処理を説明するフローチャートである。なお、このフローチャートの説明では、上記の検査端末２０の属性での絞り込みと同様の処理に関しては、説明を省略する。

最初に、検査サーバ４０のＣＰＵ４１が、集計時にカウントアップに用いる、属性の区分毎の、診断総件数と疾患件数の変数をゼロクリアにより初期化する（ステップＳ１１ｂ）。

次に、ＣＰＵ４１は、データベース４７ａのレコードを全て読んだか否かを判断する（ステップＳ１２）。

この時点では、まだデータベース４７ａの全レコードを読み終わっていない（ステップＳ１２のＮ）ので、次に、ＣＰＵ４１は、データベース４７ａからレコードを１件読み込む（ステップＳ１３）。

次に、ＣＰＵ４１は、性別の区分ごとに、診断総件数と陽性と診断された件数をカウントアップする（ステップＳ１８ａ）。

次に、ＣＰＵ４１は、年齢区分ごとに、診断総件数と陽性と診断された件数をカウントアップする（ステップＳ１８ｂ）。その後、ＣＰＵ４１は処理をステップＳ１２に戻して処理を続行する。

ステップＳ１２において、データベース４７ａ内の全レコードの読み出しが終了した場合（ステップＳ１２のＹ）、次に、ＣＰＵ４１は、属性の区分ごとの、診断総件数および疾患件数から、属性の区分ごとの有病率を算出する（ステップＳ１７ｂ）。

なお、ここでは、患者の属性として、性別および年齢を例として説明したが、これら以外の属性を用いて絞り込みを行ってもよい。但し、その際には、その属性に対応した項目がデータベース４７ａのレコードに設けられ、その項目に対応するデータが集積されていることが前提となる。

患者の他の属性の例としては、（１）問診情報、（２）現在・過去の投薬情報、（３）既往症、（４）体温、血圧、体重などの身体情報、（５）運動の程度、食事の量や種類、睡眠時間などの生活習慣に関する情報を挙げられる。

また、さらに別の例として、（６）生殖細胞系遺伝子系や体細胞系遺伝子系の、Genomic Variants、SNPs（Single Nucleotide Polymorphism、一塩基多型）、GWAS（Genome-wide Association Study、ゲノムワイド関連解析）、indel（insertion-deletion、挿入欠失）、CNV（Copy Number Variation、コピー数多型）、mRNA（messenger RNA）、Epigenetics、miRNA（micro-RNA）などを含む遺伝子型も挙げられる。

また、（７）患者に属する微生物叢（腸内細菌など）や（８）人種などの属性を用いることも出来る。

以上、検査端末２０の属性に代わり、検査を受ける患者の属性に基づいて、有病率の集計と算出の基となる検査結果を絞り込む構成を説明した。

（変形例８ 患者属性による絞り込みが行えない場合）
上記の絞り込みを行う変形例では、検査端末２０の属性や患者の属性を用いて絞り込みを行った。これに対し、ここで説明する変形例では、絞り込みを行った結果、対象とする検査結果の数が不足し、検査結果の集計からは意味のある有病率を導き出せない場合の解決策の１つを説明する。

ここで挙げる解決策では、データベース４７ａの全件から求めた、絞り込みを行う前の有病率に対し、検査システム１０の外部から取得した補正情報に基づいて補正をすることにより、対象とする条件に絞り込んだ場合の有病率を算出する。

なお、以下の説明では、絞り込みを行う条件として、患者の属性のうち、遺伝子多型を例として説明する。

図１５は、データベース４７ａにおいて、登録患者数が少なくて遺伝子多型に応じた絞り込みが意味を持たない場合に、当該遺伝子多型に対する有病率を求めるのに、全体の有病率を所定の感度を用いて補正することにより算出する処理のフローチャートである。すなわち、検査サーバ４０には、該当遺伝子多型を持つ患者の数が十分登録されていないが、その遺伝子多型での有病率を算出するための感度の補正情報があるときには、全体の有病率から該当遺伝子多型の有病率を補正により算出するということである。

最初に、検査サーバ４０のＣＰＵ４１が、情報提供先の検査端末２０において入力された患者の遺伝子多型の情報を取得する（ステップＳ９ｂ）。なお、患者の遺伝子多型情報は、検査端末２０へ直接入力されてもよいし、検査端末から受信された患者ＩＤ（Patient ID）に基づいて、他のサーバなど外部から取得されてもよい。

次に、ＣＰＵ４１は、集計時にカウントアップに用いる、同一遺伝子多型の診断総件数と疾患件数の変数をゼロクリアして初期化する（ステップＳ１１ｃ）。

次に、ＣＰＵ４１は、データベース４７ａのレコードを全て読んだか否かを判断する（ステップＳ１２）。

この時点では、まだデータベース４７ａの全レコードを読み終わっていない（ステップＳ１２のＮ）ので、次に、ＣＰＵ４１は、データベース４７ａからレコードを１件読み込む（ステップＳ１３）。

次に、ＣＰＵ４１は、読み込んだレコードの遺伝子多型と、検査端末２０から取得した遺伝子多型が同一であるか否かを判断する（ステップＳ１８ｃ）。

遺伝子多型が同一の場合（ステップＳ１８ｃのＹ）、次に、ＣＰＵ４１は、同一遺伝子多型の診断総件数を１だけカウントアップする（ステップＳ１４ｃ）。

次に、ＣＰＵ４１は、読み込んだレコードの１つのフィールドである、医師の「診断結果」が陽性であるか否かを判断する（ステップＳ１５）。

陽性である場合（ステップＳ１５のＹ）のみ、同一遺伝子多型の疾患件数を１だけカウントアップする（ステップＳ１６ｃ）。

ステップ１８ｃで遺伝子多型が異なっている場合（ステップＳ１８ｃのＮ）、ステップＳ１５で陰性であった場合（ステップＳ１５のＮ）、またはステップＳ１６ｃで疾患件数をカウントアップした後、ＣＰＵ４１は処理をステップＳ１２に戻して処理を続行する。

ステップＳ１２において、データベース４７ａ内の全レコードの読み出しが終了した場合（ステップＳ１２のＹ）、次に、ＣＰＵ４１は、同一遺伝子多型の診断総件数は充分か否かを判断する（ステップＳ１９ａ）。

充分な場合（ステップＳ１９ａのＹ）、ＣＰＵ４１は、同一遺伝子多型の診断総件数と疾患件数に基づき、同一遺伝子多型の有病率を算出する（ステップＳ１７ｂ）。

充分ではない場合（ステップＳ１９ａのＮ）、次に、ＣＰＵ４１は、患者の遺伝子多型に対応した、有病率補正用の情報があるか否かを判断する（ステップＳ１９ｂ）。

有病率補正用の情報が無い場合（ステップＳ１９ｂのＮ）、ＣＰＵ４１は、患者の遺伝子多型に対応した有病率の算出は不可能であるとして、エラーを返す（ステップＳ１９ｃ）。

有病率補正用の情報がある場合（ステップＳ１９ｂのＹ）、次に、ＣＰＵ４１は、同一遺伝子多型に絞り込まない場合の有病率（一般的な有病率）を算出する（ステップＳ２１）。

次に、ＣＰＵ４１は、有病率補正用の情報（感度情報）を用いて、算出した一般的な有病率を補正して、患者の遺伝子多型の有病率を算出する（ステップＳ１７ｃ）。

このように、検査サーバ４０には、送信された遺伝子多型での患者数が充分登録されていない場合でも、当該遺伝子多型の情報に応じた、有病率の補正に用いる感度の情報がある場合は、補正した有病率を検査端末に返信することが出来る。

なお、上記の説明では、一般的な有病率を補正する補正値を外部から取得したが、これに限らず、端末属性や患者属性のそれぞれの区分に応じた有病率そのものを外部から取得してもよい。例えば、性別年齢区分別の有病率情報を、ＸＭＬ（eXtended Markup Language）などの書式で外部から取得してもよい。

次に、本変形例で用いる検査サーバ４０ａの構成について説明する。図１６は、上記の感度情報を用いて有病率を補正できる検査サーバ４０ａの構成例を示すブロック図である。上述した検査サーバ４０との相違は、外部データインターフェイス部４９が追加されている点である。

疾患と遺伝子多型に基づいた補正に用いる感度情報が、ユーザにより操作入力部４４を介して入力されるか、感度情報を格納したメモリカードなどから外部データインターフェイス部４９経由して取得される。なお、感度情報は、ネットワークインターフェイス部４５を介してネットワーク３０越しに取得されてもよい。

補正用の感度情報を取得することにより、検査サーバ４０ａは、有病率等を提供するサービスの運用中に、有病率の補正を行い、特定の遺伝子多型に応じた有病率を提供することが可能となる。

（変形例９ 重み付けによる有病率の補正）
上記の説明では、有病率を求めるための集計を行う際に、１つの検査結果の重みを１としてカウントする（単純に陽性の件数をカウントする）構成について説明した。これに対し、ここで説明する変形例では、検査が行われた環境の条件（例えば、特定地域での予防接種普及率）を考慮して、カウントアップした陽性の件数に重み付けを行って補正し、真の有病率を予測する構成を説明する。なお、重み付けは、例えば、所定の条件に応じて係数を乗じることにより行う。

図１７は、ある行政区域において、データベース４７ａの集計により求まる有病率（診断結果有病率）を、その行政区域における予防接種普及率に基づいて、重み付け補正を行い、真の有病率を予測する処理のフローチャートである。なお、ここで説明する処理では、予防接種普及率ｆ（ｋ）を用いて、以下の数式（１４）が成立するものとしている。

（予測される真の有病率）＝ｆ（ｋ）×（診断結果有病率） （１４）

また、具体的な予防接種普及率ｆ（ｋ）の値は、過去に計測された真の有病率と、過去に算出された診断結果有病率との関係から、数式（１４）を用いて算出することが前提である。

最初に、検査サーバ４０のＣＰＵ４１が、有病率などの情報提供先となる検査端末２０から、その検査端末２０の属する行政区域を取得する（ステップＳ９ｃ）。

次に、ＣＰＵ４１は、集計時にカウントアップを行う為の変数である、同一行政区域の診断総件数と疾患件数をゼロクリアして初期化する（ステップＳ１１ｄ）。

次に、ＣＰＵ４１は、データベース４７ａのレコードを全て読んだか否かを判断する（ステップＳ１２）。

ここで、データベースの全件を読み込むまでに行われる、ステップＳ１３、ステップＳ１８ａ、ステップＳ１４ａ、ステップＳ１５、ステップＳ１６ａの処理は、上述したものと同じであり、同一行政区域における診断総件数と疾患件数を求めるものなので、説明を省略する。

ステップＳ１２において、データベース４７ａ内の全レコードの読み出しが終了した場合（ステップＳ１２のＹ）、次に、ＣＰＵ４１は、数式（６）に従い、同一行政区域の、診断総件数および疾患件数から、同一行政区域の有病率（診断結果有病率）を算出する（ステップＳ１７ｄ）。

次に、ＣＰＵ４１は、検査端末２０が属する行政区域における予防接種普及率ｆ（ｋ）を取得する（ステップＳ９ｄ）。なお、ＣＰＵ４１は、予防接種普及率ｆ（ｋ）の情報を、予め検査サーバ４０内に保持していてもよいし、検査システム１０の外部から取得してもよい。また、予防接種普及率ｆ（ｋ）の値は、検査サーバ４０上で、随時更新されてもよい。

次に、ＣＰＵ４１は、数式（１４）を用いて、予測される真の有病率を算出する（ステップＳ１７ｅ）。ここで算出された、予測される真の有病率を、上述した有病率に読み替えて、以降の処理が行われる。

上記の説明では、行政区域を重み付けの条件として用いたが、これ以外に、重み付けの条件である地域特性として、国、人口、人口密度、検査端末２０の位置、検査端末２０からの距離、環境の特異性、貧困度合い、検査端末２０周辺の交通状況、検査端末２０周辺の１日当りの人口変動などが挙げられる。

上述した絞り込みの変形例で用いられる絞り込みの条件と、ここで説明した重み付けの変形例で用いられる重み付けの条件から分かるように、行政区域などの条件は、絞り込みにも重み付けにも用いることが出来る。

なお、上記では、検査端末２０の属性に基づいた重み付けについて説明したが、患者属性、例えば、患者の体温、血圧、遺伝子型などの属性に基づいて重み付けを行ってもよい。

以上、検査が行われた環境の条件を考慮して、カウントアップした陽性の件数に重み付けを行って補正し、真の有病率を予測する構成を説明した。

（変形例１０ 診断結果が入手困難な場合に有病率の代用となる指標（その１））
上記の説明では、有病率を算出するために、過去の検査結果においては、必ず医師の診断結果も得られることを前提としていた。これに対し、ここで説明する変形例では、検査端末２０による検査の際に医師による最終的な診断結果の入力がなされないことがあるという前提に立つ。医師による最終的な診断結果が入力されないことがあると、データベース４７ａの「診断結果」欄に空白のものが発生し、集計して求める有病率の精度が低くなってしまう。そのため、本変形例では、有病率の代わりに、有病率の代用となる近似的な指標を用いる。

例えば、近似的な指標として、陽性率を用いることが考えられる。陽性率は、以下の数式（１５）から分かるように、検査端末２０で検査を行うと、自動的に取得出来る検査陽性の数から求めることが出来る。そのため、医師の最終診断結果が入力されていないレコードがデータベース４７ａ内に存在し、有病率の算出が適切に行えない場合でも、陽性率により代用した指標を用いることにより、適切な有病率の近似値を、検査端末２０に提供することが出来る。

（陽性率）＝（検査陽性数）／（診断総件数） （１５）

なお、以下の処理のポイントは、データベース４７ａ内で医師の診断結果が記入されたレコードの数が不十分である場合でも、有病率が陽性率で置き換え可能な範囲であり、検査結果が陽性であるレコードの数が充分あるときは、陽性率で有病率を代替することである。

図１８は、有病率の代わりに、有病率の代用となる近似的な指標を用いる処理を説明するフローチャートである。

最初に、検査サーバ４０のＣＰＵ４１は、集計時にカウントアップに用いる変数である、診断総件数、疾患件数、診断結果記入数、および検査結果陽性数をゼロクリアして初期化する（ステップＳ１１ｅ）。

次に、ＣＰＵ４１は、データベース４７ａのレコードを全て読んだか否かを判断する（ステップＳ１２）。

この時点では、まだデータベース４７ａの全レコードを読み終わっていない（ステップＳ１２のＮ）ので、次に、ＣＰＵ４１は、データベース４７ａからレコードを１件読み込む（ステップＳ１３）。

次に、ＣＰＵ４１は、診断総件数を１だけカウントアップする（ステップＳ１４）。

次に、ＣＰＵ４１は、読み込んだレコードの１つのフィールドである、医師の「診断結果」欄が記入されているか否かを判断する（ステップＳ１８ｄ）。

「診断結果」欄が記入されている場合（ステップＳ１８ｄのＹ）、次に、ＣＰＵ４１は、診断結果記入数を１だけカウントアップする（ステップＳ１４ｄ）。

次に、ＣＰＵ４１は、読み込んだレコードの１つのフィールドである、医師の「診断結果」が陽性であるか否かを判断する（ステップＳ１５）。

陽性である場合（ステップＳ１５のＹ）、疾患件数を１だけカウントアップする（ステップＳ１６）。

ステップＳ１８ｄで「診断結果」欄が記入されていない場合（ステップＳ１８ｄのＮ）、ステップＳ１５で陰性であった場合（ステップＳ１５のＮ）、またステップＳ１６で疾患件数をカウントアップした後、ＣＰＵ４１は処理をステップＳ１８ｅに進めて処理を続行する。

次に、ＣＰＵ４１は、検査機器２８の検査結果が陽性であるか否かを判断する（ステップＳ１８ｅ）。

検査結果が陽性である場合（ステップＳ１８ｅのＹ）のみ、ＣＰＵ４１は、検査結果陽性数を１だけカウントアップする（ステップＳ１６ｄ）。

ステップＳ１８ｅで陰性であった場合（ステップＳ１８ｅのＮ）、またはステップＳ１６ｄで疾患件数をカウントアップした後、ＣＰＵ４１は処理をステップＳ１２に戻して処理を続行する。

ステップＳ１２において、データベース４７ａ内の全レコードの読み出しが終了した場合（ステップＳ１２のＹ）、次に、ＣＰＵ４１は、数式（６）に従い、診断総件数および疾患件数から有病率を算出する（ステップＳ１７）。

次に、ＣＰＵ４１は、診断結果記入数が所定の閾値以上であるか否かを判断する（ステップＳ１９ｄ）。

診断結果記入数が所定の閾値以上である場合（ステップＳ１９ｄのＹ）、ステップＳ１７で算出された有病率は適切な値であるとして、以降の処理で利用する。

診断結果記入数が所定の閾値未満である場合（ステップＳ１９ｄのＮ）、ステップＳ１７で算出された有病率は、以降の処理で利用するには不適切な値であるとし、次に、ＣＰＵ４１は、求めた有病率が陽性率で置き換え可能な範囲にあるか否かを判断する（ステップＳ１９ｅ）。

陽性率で置き換え可能な範囲にある場合（ステップＳ１９ｅのＹ）、次に、ＣＰＵ４１は、検査結果陽性数が所定の閾値以上であるか否かを判断する（ステップＳ１９ｆ）。

検査結果陽性数が所定の閾値以上である場合（ステップＳ１９ｆのＹ）、次に、ＣＰＵ４１は、数式（１５）を用いて、陽性率を算出する（ステップＳ１７ｄ）。

次に、ＣＰＵ４１は、有病率を陽性率で代替する（ステップＳ１７ｅ）。有病率の値は陽性率で代替され、以降の処理で利用される。

なお、ステップＳ１９ｅで有病率が陽性率で置き換え可能な範囲にない場合（ステップＳ１９ｅのＮ）およびステップＳ１９ｆで検査結果陽性数が所定の閾値未満である場合（ステップＳ１９ｆのＮ）、ＣＰＵ４１は、有病率を陽性率で代用することは不可能であるとして、エラーを返す（ステップＳ１９ｇ）。

以上、有病率の代わりに、有病率の代用となる近似的な指標を用いる処理を行う変形例について説明した。

（特定の感度・特異度における、有病率と陽性率の関係について）
ここでは、有病率を陽性率の関係が、感度および特異度により変化することについて説明する。

図１９は、感度および特異度を変化させた時の、有病率と陽性率の関係を示すグラフである。この図では、診断機器２８の感度および特異度を、それぞれ８０％（陽性率１で示す線）から、５％刻みで、８５％（陽性率２で示す線）、９０％（陽性率３で示す線）、９５％（陽性率４で示す線）、１００％（陽性率５で示す線）まで変化させた時の、有病率と陽性率の関係を示している。

この図から言えることは、有病率と陽性率の関係がもっともずれている陽性率１の線から始まり、感度・特異度が上がるに従い有病率と陽性率が一致するようになり、陽性率５の線では、有病率と陽性率が一致しているということである。このことから、感度および特異度の高い診断機器による検査結果に基づく陽性率のほうが、有病率に近い値を示すということである。

つまり、より高感度・高特異度の検査の検査結果に基づく陽性率のほうが、より正確な陽性的中率および陰性的中率をユーザに提示出来るということである。

ここで、有病率の代わりに陽性率を用いた場合の、陽性的中率と陰性的中率について説明する。図２０は、有病率または有病率を代替する陽性率と、陽性的中率および陰性的中率との関係を示すグラフである。

この図では、感度８０％、特異度８０％の検査機器２８による検査を行う際の、有病率（または陽性率）と、算出される、陽性的中率および陰性的中率との関係が分かる。陽性的中率１および陰性的中率１の線は、本来の有病率を用いて算出された陽性的中率と陰性的中率を表している。

陽性的中率２および陰性的中率２の線は、有病率の代わりに、感度８０％、特異度８０％の別の検査の陽性率を用いた場合に算出される陽性的中率と陰性的中率を表している。また、陽性的中率３および陰性的中率３の線は、有病率の代わりに、感度９５％、特異度９５％の別の検査の陽性率を用いた場合に算出される陽性的中率と陰性的中率を表している。

例えば、陽性的中率３（感度・特異度９５％）の線は、陽性的中率２（感度・特異度８０％）の線に比べて、本来の陽性的中率である陽性的中率１の線に近いものとなっている。

このように、有病率を陽性率で代替する場合、より高感度、高特異度の診断機器に基づく陽性率を用いたほうが、本来の有病率から算出される陽性的中率、陰性的中率により近くなり、より有効であることが分かる。

以上、有病率を陽性率の関係が、感度および特異度により変化することについて説明した。

（変形例１１ 診断結果が入手困難な場合に有病率の代用となる指標（その２））
上記の、有病率を陽性率で代用する変形例では、ある検査方法に対する有病率の代わりに、その検査方法出られる陽性率を用いた。これに対し、この変形例では、上述した、有病率を陽性率で代替する場合、より高感度、高特異度の診断機器に基づく陽性率を用いたほうが、本来の有病率から算出される陽性的中率、陰性的中率により近くなるという点を考慮する。なお、ここでいうより高感度、高特異度とは、信用するに足るほど充分に大きいという意味であり、別の言い方をすれば、予め要求される所定の値を満足するということである。

そこで、本変形例の構成では、データベース４７ａには、感度および特異度の異なる複数の検査方法に基づく検査結果が格納されているという前提で、感度・特異度の低い検査方法（第１の検査方法）に関する有病率を他の指標で代替しなければならない場合に、感度・特異度の数値が高い検査方法（第２の検査方法）に関する陽性率を用いる。

このような構成を採りうる例として、インフルエンザウイルスの検査が挙げられる。インフルエンザウイルスの検査方法には、感度・特異度の低いイムノクロマト法と、感度・特異度の高いＰＣＲ（Polymerase Chain Reaction）法がある。

そこで、医師の診断結果が未入力であることにより、イムノクロマト法での有病率の算出が困難な場合に、ＰＣＲ法での陽性率を有病率の代用として用いる。これにより、イムノクロマト法での有病率の算出が困難な場合でも、本来の陽性的中率および陰性的中率により近い値を算出することが出来る。

なお、算出する陽性的中率および陰性的中率は、イムノクロマト法の感度（感度i）、特異度（特異度i）、およびＰＣＲ法の陽性率（陽性率p）を用いて、以下の数式（１６）および（１７）で表される。

陽性的中率＝感度i×陽性率p/(感度i×陽性率p＋(1−陽性率p)(1−特異度i)) (16)
陰性的中率＝特異度i×(１−陽性率p)/(特異度i×(１−陽性率p)＋陽性率p×(１−感度i)) (17)

ここで、本変形例の構成を採用した場合の、有病率の集計・算出処理について説明する。図２１は、本変形例の構成を採用した場合の、有病率の集計・算出処理について説明するフローチャートである。

なお、このフローチャートは、上述した、ある検査方法の有病率をその検査方法の陽性率で代用する変形例でのフローチャートと殆ど同じ（ステップＳ１１ｅからステップＳ１９ｆまでが同一）である。そこで、ここでは、上記で説明したフローチャートと、本変形例の、ある検査方法の有病率をその検査方法より高精度（高感度、高特異度）検査方法の陽性率で代用する処理のフローチャートとで、異なる部分のみを説明する。

検査結果陽性数が所定の閾値以上である場合（ステップＳ１９ｆのＹ）、次に、ＣＰＵ４１は、高精度な検査方法に基づく陽性率を取得する（ステップＳ１７ｆ）。
次に、ＣＰＵ４１は、有病率を陽性率で代替する（ステップＳ１７ｅ）。有病率の値は、より高精度な検査方法に基づく陽性率で代替され、以降の処理で利用される。

以上、ある検査方法の有病率をその検査方法より高精度（高感度、高特異度）検査方法の陽性率で代用する変形例について説明した。

なお、データベース４７ａ内に、１つの疾患に関する複数の検査方法の結果が登録されている場合、それぞれの検査方法の、登録されているレコード件数に基づいて、感度および特異度を加重平均して、総合的な感度および特異度を求めてもよい。また、１つの検査方法の感度および特異度を、データベース４７ａに登録している全ての検査方法に適用してもよい。また、検査方法ごとにグループ分けを行い、グループごとに重み付けをして総合的な感度および特異度を求めてもよい。また、上記では有病率を代替する別の指標について述べたが、データベース４７ａに基づく有病率に代わり、地域を代表する機関における有病率を用いることも出来る。

（変形例１２ 検査実施の有効性の提示）
上記の構成では、検査を行う医師に対し、検査端末２０が有病率、陽性的中率、および陰性的中率、すなわち医師が最終的な診断を行うにあたり参考となる情報の表示を行った。それに対し、ここで説明する変形例では、検査端末２０が、例えば、算出した陽性的中率が現実的な値か否かを判断し（有効性を評価し）、現実的（有効）であれば、医師に検査の実施を推奨する。

医師が検査を実行する前に、検査で陽性結果が得られた場合に本当に陽性である確率（陽性的中率）や検査で陰性結果が得られた場合に本当に陰性である確率（陰性的中率）を医師に提示することは、医師が検査の実行を判断する上で有用である。

検査の実施は、常に、検査の実行による副作用や検査のコストとの兼ね合いである。例えば、有病率が極めて低く、算出された陽性的中率も現実的ではないほど低い値となった場合、検査を実施しないことも選択肢となる。

このように、検査端末２０が、検査前に、陽性的中率が極めて低く現実的ではない場合は検査を実施しない事を推奨したり、陽性的中率が充分高い場合は検査を実施する事を推奨したりすることが出来る。

図２２は、算出された陽性的中率の程度により、検査の実施を推奨したり、検査を実施しないことを推奨したりする処理のフローチャートである。

最初に、検査サーバ４０のＣＰＵ４１が、検査サーバ４０において、データベース４７ａを用いて、１つの疾患、１つの検査方法に対する有病率を集計し算出する（ステップＳ１０）。

次に、これから検査を実施する検査端末２０において、その検査端末２０のＣＰＵ２１が、検査サーバ４０において算出された有病率のダウンロードを行う（ステップＳ２０）。

次に、有病率をダウンロードした検査端末２０において、ＣＰＵ２１が、陽性的中率および陰性的中率の算出を行う（ステップＳ３０）。

次に、ＣＰＵ２１が、表示部２６を介して、有病率、陽性的中率、および陰性的中率をユーザである医師に提示する（ステップＳ４０）。

次に、ＣＰＵ２１が、検査実施が現実的ではなくなる陽性的中率の閾値Ａを取得する（ステップＳ４１）。

次に、ＣＰＵ２１が、検査実施が現実的となる陽性的中率の閾値Ｂを取得する（ステップＳ４２）。なお、閾値Ａや閾値Ｂは、予め検査端末２０に保持されていてもよいし、検査サーバ４０からダウンロードされてもよいし、その他の方法により外部から取得されてもよい。

次に、ＣＰＵ２１が、算出された陽性的中率は閾値Ａ以下であるか否かを判断する（ステップＳ４３）。

算出された陽性的中率が閾値Ａ以下である場合（ステップＳ４３のＹ）、ＣＰＵ２１は、検査しない事を推奨する表示を、表示部２６を介してユーザである医師に対して行う（ステップＳ４４）。

算出された陽性的中率が閾値Ａを超えている場合（ステップＳ４３のＮ）、ＣＰＵ２１は、次に、算出された陽性的中率は閾値Ｂ以上であるか否かを判断する（ステップＳ４５）。

算出された陽性的中率が閾値Ｂ以上である場合（ステップＳ４５のＹ）、ＣＰＵ２１は、検査する事を推奨する表示を、表示部２６を介してユーザである医師に対して行う（ステップＳ４６）。

ステップＳ４４またはステップＳ４６において推奨表示を行った後、またはステップＳ４５において算出された陽性的中率が閾値Ｂ未満である場合（ステップＳ４５のＮ）、次に、ＣＰＵ２１は、医師に検査を実施するか否かを判断させる（ステップＳ４７）。

医師が検査を実施すると判断しその旨を検査端末２０に指示した場合（ステップＳ４７のＹ）、次に、検査端末２０の検査機器２８において、検査が実施される（ステップＳ５０）。

次に、ＣＰＵ２１が、検査端末２０に入力された診断結果等の検査サーバ４０へのアップロードを行う（ステップＳ６０）。

次に、検査サーバ４０において、ＣＰＵ４１が、アップロードされた診断結果等の情報を、データベース４７ａに登録する（ステップＳ７０）。

ステップＳ７０でのデータベース４７ａへの登録後、または、ステップＳ４７において検査を実施しないと判断された場合（ステップＳ４７のＮ）、処理はステップＳ１０に戻り、上記の処理が繰り返される。

以上、検査端末２０が、算出した陽性的中率が現実的な値か否かを判断し、現実的であれば、医師に検査の実施を推奨する変形例について説明した。

（変形例１３ 検査未実施地域での有病率の予測）
上記の説明では、検査を実施する地域における過去の検査結果を集計することにより、その地域における有病率を算出した。これに対し、ここで説明する変形例では、これまで検査を実施していない地域の有病率を、他の地域で算出された有病率から推測する。

図２３は、既に検査結果が蓄積されている複数の地域の有病率と、それら複数の地域からの距離に応じて、検査をまだ行っていない地域における有病率を推測する様子を示す図である。

この図において、都市Ａ、都市Ｂ、都市Ｃにおいては、過去に検査を実施しており、検査結果が蓄積されており、有病率が算出されている。しかし、都市Ｄでは、まだ検査は行われておらず、過去の検査結果の集計からは、有病率を算出することが出来ない。ここで、都市ＡとＤの距離を距離ＡＤとし、都市ＢとＤの距離を距離ＢＤとし、都市ＣとＤの距離を距離ＣＤとして、都市Ａ、Ｂ、およびＣの有病率と、推測する都市Ｄの有病率の間には図の数式で示す関係があると仮定する。

すると、検査端末２０を用いて、都市Ａ、Ｂ、およびＣの有病率を求め、検査端末２０に都市間の距離を入力し、検査端末２０に図の数式に基づいて計算を行わせることにより、都市Ｄにおける有病率を推測することが出来る。

このように、検査が未実施の地域における有病率が推測できると、例えば、移動病院等が、次に、どの地域で診断や治療を行うべきかの指針を得ることが出来る。
なお、ここでは、ある地域の有病率は、他の地域からの距離の２乗に反比例すると仮定したが、これ以外に、感染に影響を与える要因、すなわち、都市間の交通状況や地形を加味した距離、測定時刻、人口密度、および医療レベルのうち少なくとも一つに基づいて重みづけ補正を行ってもよい。

以上、これまで検査を実施していない地域の有病率を、他の地域で算出された有病率から推測する変形例について説明した。

（変形例１４ 今後の有病率の予測）
上記の説明では、検査システム１０は、現時点での有病率を提供した。これに対し、ここで説明する変形例では、現時点での有病率に加え、今後の予測有病率も提供する。なお、今後の予測有病率を提供するための処理は、検査サーバ４０において行われてもいし、検査端末２０において行われてもよいし、両者の間で分担する形で処理が行われてもよい。ここでは、検査サーバ４０において処理が行われるものとして説明を行う。

図２４は、現時点での有病率に加え、今後の予測有病率も提供する処理の流れを説明するフローチャートである。この処理では、現在までの一定時間における有病率の変化率に基づいて、今後一定時間後の予測有病率を算出する。また、この処理では、予測有病率が所定の閾値を超えると警告表示も行う。なお、このフローチャートでは、ここで説明した処理に関する部分のみを表示することとし、処理の前提となる過去の有病率を履歴情報として記憶部４７に保存するステップについては省略している。

最初に、検査サーバ４０のＣＰＵ４１が、現時点での有病率を算出する（ステップＳ１００）。この処理は、上述した方法により行われる。

次に、ＣＰＵ４１は、記憶部４７から、一定時間前の有病率を履歴情報から読み出す（ステップＳ１０１）。一定時間前とは、例えば２４時間前などである。

次に、ＣＰＵ４１は、一定時間前の有病率と現時点での有病率とから、単位時間当りの有病率の変化率を算出する（ステップＳ１０２）。単位時間当りの有病率の変化率は、例えば、以下の数式（１８）により求めてもよい。

（単位時間当りの有病率の変化率）＝（（現時点の有病率）−（２４時間前の有病率））／２４ （１８）

なお、一時的な有病率の変動による誤処理の可能性を低減するために、以下のような計算を行ってもよい。
（ａ）現時点の有病率や一定時間前の有病率として、より細かい時間単位（例えば１時間ごと）で取得した複数の有病率の平均を用いる。
（ｂ）より短い時間単位での変化率を求め、それらの変化率の平均を取る。

次に、ＣＰＵ４１は、現時点での有病率と単位時間当りの有病率の変化率から、一定時間後の予測有病率を算出する（ステップＳ１０３）。例えば、２４時間後の予測有病率は、以下の数式（１９）により求めてもよい。

（２４時間後の予測有病率）＝（現時点の有病率）＋（単位時間当りの変化率）×２４ （１９）

次に、ＣＰＵ４１は、予測有病率が所定の閾値を超えているか否かを判断する。（ステップＳ１０４）。

予測有病率が所定の閾値を超えている場合（ステップＳ１０４のＹ）のみ、ＣＰＵ４１は、今後の感染拡大をユーザに警告する（ステップＳ１０５）。ここで行う警告はどのような方法により行ってもよい。例えば、検査端末２０の表示部２６に警告表示を行ってもよいし、電子メールやインターネット上のＷｅｂページ、各種ＳＮＳ（Social Networking Service）経由で行ってもよい。

以上、現時点での有病率に加え、今後の予測有病率も提供する変形例について説明した。

（変形例１５ 通信の最適化）
上記の説明では、検査端末２０側で検査を行う度に検査サーバ４０から有病率などの情報をダウンロードする構成を説明した。これに対し、この変形例では、検査サーバ４０の負荷を減らし、検査サーバ４０および検査端末２０間の通信料を削減するために、有病率などダウンロードした情報を検査端末２０上でキャッシュする。検査端末２０は、検査の度に有病率などの情報を検査サーバ４０に要求するのではなく、一定時間の間は、検査端末２０にキャッシュされた有病率などの情報を利用する。

そのため、この変形例の構成では、処理の頻度により、全体の処理を大きく２つの処理グループに分割する。１つの処理グループは、所定の一定時間ごとに行う、検査サーバ４０での有病率の集計から、有病率のダウンロード、有病率等のキャッシュまでの処理である。もう１つの処理グループは、検査の度に行う、キャッシュされた有病率等の読み出しから検査の実施、検査結果のデータベース４７ａへの反映までの処理である。なお、所定の一定時間は、例えば、３０分おきであったり、３時間おきであったり、１日おきであったりしてもよい。

図２５は、所定の一定時間ごとの処理と検査実施ごとの処理を表すフローチャートである。

まず一定時間ごとの処理について説明する。なお、ステップＳ１０からＳ３０までは、上述したものと同じなので、簡単に説明する。

最初に、検査サーバ４０のＣＰＵ４１が、検査サーバ４０において、データベース４７ａを用いて、有病率を集計し算出する（ステップＳ１０）。

次に、有病率等の情報をキャッシュする検査端末２０において、その検査端末２０のＣＰＵ２１が、検査サーバ４０において算出された有病率のダウンロードを行う（ステップＳ２０）。

次に、有病率をダウンロードした検査端末２０において、ＣＰＵ２１が、陽性的中率および陰性的中率の算出を行う（ステップＳ３０）。

次に、ＣＰＵ２１が、ダウンロードした有病率、算出した陽性的中率および陰性的中率を記憶部２７に格納（キャッシュ）する（ステップＳ３１）。

ステップＳ３１の処理が完了した後、所定の一定時間が経過後、ステップＳ１０に戻って、処理が繰り返される。

以上が、一定時間ごとの処理の流れである。

次に、検査実施ごとの処理について説明する。なお、ステップＳ４０からＳ７０までは、上述したものと同じなので、簡単に説明する。

最初に、検査端末２０のＣＰＵ２１が、記憶部２７内のキャッシュから、有病率、陽性的中率、および陰性的中率を読み出す（ステップＳ３２）。

次に、ＣＰＵ２１が、表示部２６を介して、有病率、陽性的中率、および陰性的中率をユーザである医師に提示する（ステップＳ４０）。

次に、検査端末２０の検査機器２８において、ユーザの指示により、検査が実施される（ステップＳ５０）。

次に、ＣＰＵ２１が、検査端末２０に入力された診断結果等の検査サーバ４０へのアップロードを行う（ステップＳ６０）。

次に、検査サーバ４０において、ＣＰＵ４１が、アップロードされた診断結果等の情報を、データベース４７ａに登録する（ステップＳ７０）。

以上が、検査実施ごとの処理の流れである。

なお、この変形例の構成は、上述したように、検査端末２０が表示する情報が、有病率、陽性的中率、および陰性的中率のみである場合には、記憶部２７のキャッシュ容量を低く抑えられるので有効である。また、上述した、患者属性による対象データの絞り込みを行う変形例に適用する場合も、同じ理由により、ある属性における区分の数が少ない場合に有効である。例えば、性別ごとの有病率をキャッシュする場合、記憶しなければならない有病率は、２種類だけである。

このように、この変形例の構成を用いることにより、検査実施ごとに検査サーバ４０にて有病率等を集計し集計結果をダウンロードする構成に比べ、検査サーバ４０の負荷を低減したり、検査サーバ４０と検査端末２０間の通信料を低減したりすることが出来る。

なお、上記の構成では、一定時間ごとに検査端末２０が有病率などの情報をダウンロードするとしたが、これに限らず、例えば、一定時間ごとに、検査サーバ４０が、検査端末２０に対して、有病率などの集計結果を配信する構成を採ってもよい。

以上、有病率などダウンロードした情報を検査端末２０上でキャッシュする変形例について説明した。

（変形例１６ 診断結果等のアップロード形態）
上記の説明では、最終的な診断結果等は、医師が検査端末２０に入力し、検査端末２０が検査サーバ４０にアップロードする構成を説明した。これに対し、ここで説明する変形例では、病院内のＬＩＳ（Laboratory Information System）などのローカルシステムや、インターネット上のクラウドシステムを介して、診断結果等の情報を検査サーバ４０にアップロードする構成を説明する。

図２６は、ＬＩＳを用いて診断結果等をアップロードする構成を示す図である。図の左側は、検査サーバ４０から有病率等をダウンロードし、検査端末２０から診断結果等を検査サーバ４０に直接アップロードする構成であり、上述したものである。図の中央は、医師が診断結果をＬＩＳに入力し、ＬＩＳが診断結果等を検査サーバ４０にアップロードする構成である。図の右側は、医師が診断結果をＬＩＳに入力し、ＬＩＳは診断結果を検査端末２０に転送し、検査端末２０が検査サーバ４０に診断結果をアップロードする構成である。

なお、図示はしないが、医師が最終的な診断結果を、インターネット上のクラウドシステムなど広範囲にアクセスできるシステムに、例えばスマートフォンやタブレット型ＰＣを使用して、入力する構成でもよい。この場合、診断結果等は、クラウドシステムから検査サーバ４０に転送される。

以上、病院内のＬＩＳなどのローカルシステムや、インターネット上のクラウドシステムを介して、診断結果等の情報を検査サーバ４０にアップロードする変形例について説明した。

（変形例１７ 投薬の推奨）
上記の説明では、検査端末２０において、医師などのユーザに対し、算出された有病率や陽性的中率、陰性的中率などの提示を行う構成を説明した。これに対し、ここで説明する変形例では、検査端末２０が、ユーザに対し、投薬の推奨を行う。

投薬の推奨は、有病率、陽性的中率、および陰性的中率の高さに基づいて行われてもよいし、実施された検査の結果に基づいて行われてもよいし、医師の最終診断結果に基づいて行われてもよい。

なお、投薬の推奨とは、具体的には、例えば、投薬の必要性の有無や、投薬すべき薬剤名、投薬の候補となる薬剤のリストを、表示部２６上に表示することをいう。

もちろん、この変形例を実現するためには、検査端末２０上、検査サーバ４０上、または検査システム１０の外部に、疾患と投薬に関する知識ベース（knowledge base）が構築されていることが前提となる。

以上、検査端末２０が、ユーザに対し、投薬の推奨を行う変形例について説明した。

（変形例１８ ユーザインターフェイス）
上記の説明では、検査端末２０の表示部２６上に、一般的な有病率や、属性による絞り込みを行った結果の有病率、重み付けを行った結果の有病率、有病率の代用となる陽性率、検査実施／不実施の推奨、予測有病率、投薬の推奨、患者の個別管理の推奨などの表示を行う構成について個別に説明した。これに対し、ここで説明する変形例では、これらの表示を統合して行う構成などについて説明する。

図２７は、検査端末２０に、疾患名、有病率、陽性的中率、および陰性的中率に加え、検査端末２０の検査機器２８で実施可能な検査方法のリストが提示され、さらに推奨される検査方法が表示されている具体例を示す図である。

この図では、ＰＣＲ法が、推奨マーク２６ａと共にハイライト表示されている。また、各検査方法の名前の横には、この表示画面から直接検査の開始を検査端末２０に指示するための検査開始ボタン２６ｂなどのＵＩ（User Interface）が表示されている。なお、検査開始を指示するＵＩは、ボタン以外に、なぞり操作などにより指示が行われる構成でもよい。

また、情報を提示する際の画面ではないが、以下の操作を行うＵＩが表示される画面を設けてもよい。

例えば、検査終了時に表示する画面に、検査結果を検査サーバ４０にアップロードする指示を行うためのＵＩを表示してもよい。

また、医師の最終的な診断結果を自動的に検査サーバ４０にアップロードする代わりに、診断結果の入力完了を示す画面に、診断結果を検査サーバ４０にアップロードする指示を行うためのＵＩを表示してもよい。

また、検査終了後、医師の診断結果等が検査サーバ４０にアップロードされた後、次の検査を開始する指示を行うためのＵＩを画面上に表示させてもよい。

また、検査終了時に表示する画面に、有病率、陽性的中率、および陰性的中率などの統計情報を閲覧する画面に遷移するためのＵＩを設けてもよい。

また、医師の最終的な診断結果の入力後、検査端末２０に患者が治療に対して希望する様々な条件を入力させ、それらの条件に応じた病院や薬局を紹介する画面を表示してもよい。

また、医師の最終的な診断結果の入力後、検査端末２０に患者が治療に対して支払う治療費を入力させ、その治療費の額に応じた治療法を紹介する画面を表示してもよい。

以上、表示を統合して行う変形例などについて説明した。

（変形例１９ 検査端末２０の単純化）
上記の説明では、検査システム１０がクライアント・サーバ構成を採り、クライアントである検査端末２０とサーバである検査サーバ４０とが、分担して処理を行う構成を説明した。これに対し、ここで説明する変形例では、検査端末２０が行う処理を必要最低限のものに限定し、殆どの処理を検査サーバ４０で行う変形例について説明する。

例えば、検査端末２０の機能を、検査サーバから受信した情報の表示や、患者情報等の入力と入力データの検査サーバ４０への送信、検査の実行、検査結果の表示と検査サーバ４０への送信、医師の診断結果の入力と検査サーバ４０への送信に限ってもよい。

集計や、計算処理、判断処理などを検査サーバ４０に行わせることにより、検査端末２０の構成を簡略化し、低コスト化することが出来る。

また、この構成では、新しい機能を追加する場合、検査サーバ４０のみ構成を変更すればよく、検査端末２０は何も変更する必要が無いので、数多く存在する検査端末２０を改変する手間を省くことが出来る。

以上、検査端末２０が行う処理を必要最低限のものに限定し、殆どの処理を検査サーバ４０で行う変形例について説明した。

［本技術の構成のまとめ］
ここでは、本技術に係る検査システム１０、検査サーバ４０、および検査端末２０の構成と機能の概略についてまとめる。

本技術の検査サーバ４０は、疾患の有無の検査を実行可能な検査機器と接続可能とされ、かつ当該検査に関する医師による前記疾患の有無の診断の結果の入力が可能な複数の検査端末２０とネットワーク３０を介して通信するネットワークインターフェイス部４５と、複数の検査端末２０から、少なくとも前記検査の結果および前記診断の結果のうち少なくとも一方を検査情報としてそれぞれネットワークインターフェイス部４５により取得し、前記取得された複数の検査情報を記憶部４７に記憶させ、前記記憶された複数の検査情報を統計処理し、前記医師による診断の前に検査端末２０から与えられる要求に応じて、前記統計処理の結果をネットワークインターフェイス部４５により応答させるように構成されたＣＰＵ４１とを具備する。

本技術の検査端末２０は、疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報として複数個収集し、収集した複数の前記検査情報を統計処理した結果を提供する検査サーバ４０とネットワーク３０を介して通信するネットワークインターフェイス部２５と、医師であるユーザからの入力を受け付ける操作入力部２４と、検査サーバ４０に前記統計処理の結果の要求をネットワークインターフェイス部２５により送信させ、検査機器２８に前記検査を実行させ、検査サーバ４０からネットワークインターフェイス部２５により受信された前記統計処理の結果および当該実行された検査の結果を前記ユーザに提示し、当該実行された検査に関する前記診断の結果を、操作入力部２４を用いて前記ユーザに入力させ、当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、ネットワークインターフェイス部２５により検査サーバ４０へ送信させるように構成されたＣＰＵ２１とを具備する。

本技術の検査システム１０は、検査サーバ４０と複数の検査端末２０を具備する検査システム１０であって、検査サーバ４０は、複数の検査端末２０とネットワーク３０を介して通信するネットワークインターフェイス部４５と、複数の検査端末２０から、少なくとも疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報としてそれぞれネットワークインターフェイス部４５により取得し、前記取得された複数の検査情報を記憶部４７に記憶させ、前記記憶された複数の検査情報を統計処理し、前記医師による診断の前に検査端末２０から与えられる要求に応じて、前記統計処理の結果をネットワークインターフェイス部４５により応答させるように構成されたＣＰＵ４１とを具備し、検査端末２０は、検査サーバ４０とネットワーク３０を介して通信するネットワークインターフェイス部２５と、医師であるユーザからの入力を受け付ける操作入力部２４と、検査サーバ４０に前記統計処理の結果の前記要求をネットワークインターフェイス部２５により送信させ、検査機器に前記検査を実行させ、検査サーバ４０からネットワークインターフェイス部２５により受信された前記統計処理の結果および当該実行された検査の結果を前記ユーザに提示し、当該実行された検査に関する前記診断の結果を、操作入力部２４を用いて前記ユーザに入力させ、当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、ネットワークインターフェイス部２５により検査サーバ４０へ送信させるように構成されたＣＰＵ２１とを具備する。

［本実施形態による効果について］
本実施形態の検査システム１０により、例えば、以下の様な効果を得ることが出来る。
（１）多数の検査端末２０から得られた情報に基づき、有病率等、診断の指標となる情報を提供することにより、医師が下す最終的な診断結果の精度を向上させることが出来る。
（２）データベース４７ａに蓄積された情報に対して絞り込みや重み付けを行って、有病率等、提供する情報の精度をさら高めることが出来る。
（３）検査システム１０内には無い情報を外部から取得することにより、有病率などに加えて、さらに有用な情報を医師に提供することが出来る。
（４）検査サーバ４０側を変更するだけで、新規機能に基づく新しい情報を医師に提供することが出来る。
（５）典型的な検査システムとは異なり、即時性をもって感染症などに対応することが出来る。

［補足事項］
その他、本技術は、上述の実施形態にのみ限定されるものではなく、本技術の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。

［本技術の別の構成］
なお、本技術は以下のような構成もとることができる。
（１）
疾患の有無の検査を実行可能な検査機器と接続可能とされ、かつ当該検査に関する医師による前記疾患の有無の診断の結果の入力が可能な複数の通信端末とネットワークを介して通信する通信部と、
前記複数の通信端末から、少なくとも前記検査の結果および前記診断の結果のうち少なくとも一方を検査情報としてそれぞれ前記通信部により取得し、
前記取得された複数の検査情報を記憶部に記憶させ、
前記記憶された複数の検査情報を統計処理し、
前記医師による診断の前に前記通信端末から与えられる要求に応じて、前記統計処理の結果を前記通信部により応答させる
ように構成された制御部と
を具備する検査サーバ。
（２）
前記（１）に記載の検査サーバであって、
前記制御部は、
前記記憶された複数の検査情報における、
前記検査の結果および前記診断の結果が共に陽性である前記検査情報の数、
前記検査の結果が陰性で前記診断の結果が陽性である前記検査情報の数、
前記検査の結果が陽性で前記診断の結果が陰性である前記検査情報の数、および
前記検査の結果および前記診断の結果が共に陰性である前記検査情報の数に基づいて、
前記統計処理の結果として算出、有病率、陽性的中率、および陰性的中率のうち少なくとも１つを前記通信部により応答させる
ように構成された検査サーバ。
（３）
前記（２）に記載の検査サーバであって、
前記制御部は、
前記有病率に加えて、
前記有病率、前記検査機器の感度、および前記検査機器の特異度に基づいて算出した陽性的中率および陰性的中率を前記通信部により応答させる
ように構成された検査サーバ。
（４）
前記（２）または（３）に記載の検査サーバであって、
前記制御部は、
前記検査を行う患者における発症からの経過時間を前記通信端末から取得し、
前記発症からの経過時間に対応する感度および特異度を取得し、
前記取得された感度および特異度に基づいて前記陽性的中率および前記陰性的中率を算出する
ように構成された検査サーバ。
（５）
前記（１）から（４）のうちいずれか１つに記載の検査サーバであって、
前記制御部は、
前記通信端末に接続された検査機器に、前記疾患の検査用の複数種類の検査を実行させ、
前記検査機器から前記実行した複数種類の検査の結果を取得し、
前記取得した複数種類の検査の結果に基づいて、前記疾患の有無を示す検査の結果を判定する
ように構成された検査サーバ。
（６）
前記（１）から（４）のうちいずれか１つに記載の検査サーバであって、
前記検査機器は、複数種類の検査が実行可能であり、
前記制御部は、
前記検査機器に前記複数種類の検査のうちの１つの検査を実行させた後、
当該１つの検査に関し、陽性尤度比および陰性尤度比のうち少なくとも一方に基づいて、当該１つの検査での検査後オッズを算出して前記通信端末に送信し、前記通信端末から次の検査を行うか否かの情報を取得する
ように構成された検査システム。
（７）
前記（１）から（６）のうちいずれか１つに記載の検査サーバであって、
前記通信端末から取得される前記検査情報は、前記検査を受ける患者の属性を示す患者属性情報を含み、
前記制御部は、
前記通信端末から任意の前記患者属性情報を指定した統計情報絞り込み要求を受けたとき、
前記患者属性情報の属性を有する検査情報を対象に絞り込んで前記統計処理を行う
ように構成された検査サーバ。
（８）
前記（１）から（７）のうちいずれか１つに記載の検査サーバであって、
前記通信端末から取得される前記検査情報は、前記検査を行う前記通信端末の属性を示す端末属性情報を含み、
前記制御部は、
前記通信端末から任意の前記端末属性情報を指定した統計情報絞り込み要求を受けたとき、
前記端末属性情報の属性を有する検査情報を対象に絞り込んで前記統計処理を行う
ように構成された検査サーバ。
（９）
前記（８）に記載の検査サーバであって、
前記制御部は、
前記絞り込んだ検査情報に基づいて算出された前記統計処理の結果に、前記端末属性情報に基づく重み付けを行う
ように構成された検査サーバ。
（１０）
前記（２）から（４）のうちいずれか１つに記載の検査サーバであって、
前記制御部は、
陽性率を前記有病率の代わりに用いることが可能な
ように構成された検査サーバ。
（１１）
前記（１０）に記載の検査サーバであって、
前記検査情報は、前記検査を行う方法を識別する情報を含み、
前記制御部は、
同一の前記疾患の前記検査を行う複数の前記方法について、
前記各々の方法ごとに、予め与えられた各感度および各特異度のうち、
これら感度および特異度が予め要求される所定の値を満足する方法により得られた複数の前記検査情報に対する前記統計処理の結果である前記陽性率を、
他の前記方法によって得られた複数の前記検査情報に対する各々の前記統計処理の結果である各々の有病率の代わりに用いることが可能な
ように構成された検査サーバ。
（１２）
前記（２）から（４）のうちいずれか１つに記載の検査サーバであって、
前記制御部は、
前記陽性的中率を基に、前記検査の有効性を評価し、その評価結果を前記通信端末に送信し、前記通信端末に前記検査の推奨または非推奨のメッセージを提示させる
ように構成された検査サーバ。
（１３）
前記（２）から（４）のうちいずれか１つに記載の検査サーバであって、
前記通信端末から取得される前記検査情報は、前記検査を行う前記通信端末の属性を示す端末属性情報として、前記通信端末が位置する地域の情報を含み、
前記制御部は、
前記検査が未実施である第１の地域における前記有病率を、前記有病率が得られた、前記第１の地域とは異なる１つ以上の第２の地域における各々の有病率と、前記第２の地域各々と前記第１の地域との間における、感染に影響を与える要因を基に推定する
ように構成された検査サーバ。
（１４）
前記（２）から（４）のうちいずれか１つに記載の検査サーバであって、
前記制御部は、
定期的に前記統計処理を行い前記有病率の履歴情報を作成し、
前記履歴情報に基づいて、将来の有病率を予測する
ように構成された検査サーバ。
（１５）
前記（１）から（１４）のうちいずれか１つに記載の検査サーバであって、
前記制御部は、
前記記憶された複数の検査情報を統計処理する代わりに、外部から取得した前記統計処理の結果を応答させる
ように構成された検査サーバ。
（１６）
前記（１）から（１５）のうちいずれか１つに記載の検査サーバであって、
前記制御部は、
前記検査の結果、前記診断の結果、および前記統計処理の結果のうち少なくとも１つに基づいた薬剤のリストを前記通信端末に送信し、前記通信端末に投薬を推奨する薬剤として前記リストを提示させる、
もしくは、
前記検査機器で検査可能な前記検査の方法のリストと、
前記リスト内で推奨される検査の方法を示す推奨マークと、
前記検査を開始するためのユーザインターフェイスと
を前記通信端末に表示させる
ように構成された検査サーバ。
（１７）
疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報として複数個収集し、収集した複数の前記検査情報を統計処理した結果を提供する検査サーバとネットワークを介して通信する通信部と、
医師であるユーザからの入力を受け付ける入力部と、
前記検査サーバに前記統計処理の結果の要求を前記通信部により送信させ、
検査機器に前記検査を実行させ、
前記検査サーバから前記通信部により受信された前記統計処理の結果および当該実行された検査の結果を前記ユーザに提示し、
当該実行された検査に関する前記診断の結果を、前記入力部を用いて前記ユーザに入力させ、
当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、前記通信部により前記検査サーバへ送信させる
ように構成された制御部と
を具備する通信端末。
（１８）
検査サーバと複数の通信端末を具備する検査システムであって、
前記検査サーバは、
前記複数の通信端末とネットワークを介して通信する第１の通信部と、
前記複数の通信端末から、少なくとも疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報としてそれぞれ前記通信部により取得し、
前記取得された複数の検査情報を記憶部に記憶させ、
前記記憶された複数の検査情報を統計処理し、
前記医師による診断の前に前記通信端末から与えられる要求に応じて、前記統計処理の結果を前記通信部により応答させる
ように構成された第１の制御部と
を具備し、
前記通信端末は、
前記検査サーバと前記ネットワークを介して通信する第２の通信部と、
医師であるユーザからの入力を受け付ける入力部と、
前記検査サーバに前記統計処理の結果の前記要求を前記通信部により送信させ、
検査機器に前記検査を実行させ、
前記検査サーバから前記通信部により受信された前記統計処理の結果および当該実行された検査の結果を前記ユーザに提示し、
当該実行された検査に関する前記診断の結果を、前記入力部を用いて前記ユーザに入力させ、
当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、前記通信部により前記検査サーバへ送信させる
ように構成された第２の制御部と
を具備する
検査システム。
（１９）
制御部が、
疾患の有無の検査を実行可能な検査機器と接続可能とされ、かつ当該検査に関する医師による前記疾患の有無の診断の結果の入力が可能な複数の通信端末から、少なくとも前記検査の結果および前記診断の結果のうち少なくとも一方を検査情報としてそれぞれ前記通信部により取得し、
前記取得された複数の検査情報を記憶部に記憶させ、
前記記憶された複数の検査情報を統計処理し、
前記医師による診断の前に前記通信端末から与えられる要求に応じて、前記統計処理の結果を前記通信部により応答させる
検査方法。
（２０）
制御部が、
疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報として複数個収集し、収集した複数の前記検査情報を統計処理した結果を提供する検査サーバとネットワークを介して通信する通信部により、前記検査サーバに前記統計処理の結果の要求を送信させ、
前記検査サーバに前記統計処理の結果の要求を前記通信部により送信させ、
検査機器に前記検査を実行させ、
前記検査サーバから前記通信部により受信された前記統計処理の結果および当該実行された検査の結果を医師であるユーザに提示し、
当該実行された検査に関する前記診断の結果を、前記ユーザからの入力を受け付ける入力部を用いて前記ユーザに入力させ、
当該実行された検査の結果および当該入力された診断の結果を前記検査情報として、前記通信部により前記検査サーバへ送信させる
検査方法。

１０ … 検査システム
２０ … 検査端末
２１ … ＣＰＵ
２２ … ＲＯＭ
２３ … ＲＡＭ
２４ … 操作入力部
２５ … ネットワークインターフェイス部
２６ … 表示部
２７ … 記憶部
２８ … 検査機器
３０ … ネットワーク（インターネット）
４０ … 検査サーバ
４１ … ＣＰＵ
４２ … ＲＯＭ
４３ … ＲＡＭ
４４ … 操作入力部
４５ … ネットワークインターフェイス部
４６ … 表示部
４７ … 記憶部
４７ａ… データベース

Claims (20)

1. 疾患の有無の検査を実行可能な検査機器と接続可能とされ、かつ当該検査に関する医師による前記疾患の有無の診断の結果の入力が可能な複数の通信端末とネットワークを介して通信する通信部と、
   前記複数の通信端末から、少なくとも前記検査の結果および前記診断の結果のうち少なくとも一方を検査情報としてそれぞれ前記通信部により取得し、
   前記取得された複数の検査情報を記憶部に記憶させ、
   前記記憶された複数の検査情報を統計処理し、
   前記医師による診断の前に前記通信端末から与えられる要求に応じて、前記統計処理の結果を前記通信部により応答させる
   ように構成された制御部と
   を具備する検査サーバ。
2. 請求項１に記載の検査サーバであって、
   前記制御部は、
   前記記憶された複数の検査情報における、
   前記検査の結果および前記診断の結果が共に陽性である前記検査情報の数、
   前記検査の結果が陰性で前記診断の結果が陽性である前記検査情報の数、
   前記検査の結果が陽性で前記診断の結果が陰性である前記検査情報の数、および
   前記検査の結果および前記診断の結果が共に陰性である前記検査情報の数に基づいて、
   前記統計処理の結果として算出した、有病率、陽性的中率、および陰性的中率のうち少なくとも１つを前記通信部により応答させる
   ように構成された検査サーバ。
3. 請求項２に記載の検査サーバであって、
   前記制御部は、
   前記有病率に加えて、
   前記有病率、前記検査機器の感度、および前記検査機器の特異度に基づいて算出した陽性的中率および陰性的中率を前記通信部により応答させる
   ように構成された検査サーバ。
4. 請求項３に記載の検査サーバであって、
   前記制御部は、
   前記検査を行う患者における発症からの経過時間を前記通信端末から取得し、
   前記発症からの経過時間に対応する感度および特異度を取得し、
   前記取得された感度および特異度に基づいて前記陽性的中率および前記陰性的中率を算出する
   ように構成された検査サーバ。
5. 請求項１に記載の検査サーバであって、
   前記制御部は、
   前記通信端末に接続された検査機器に、前記疾患の検査用の複数種類の検査を実行させ、
   前記検査機器から前記実行した複数種類の検査の結果を取得し、
   前記取得した複数種類の検査の結果に基づいて、前記疾患の有無を示す検査の結果を判定する
   ように構成された検査サーバ。
6. 請求項１に記載の検査サーバであって、
   前記検査機器は、複数種類の検査が実行可能であり、
   前記制御部は、
   前記検査機器に前記複数種類の検査のうちの１つの検査を実行させた後、
   当該１つの検査に関し、陽性尤度比および陰性尤度比のうち少なくとも一方に基づいて、当該１つの検査での検査後オッズを算出して前記通信端末に送信し、前記通信端末から次の検査を行うか否かの情報を取得する
   ように構成された検査サーバ。
   
   
7. 請求項１に記載の検査サーバであって、
   前記通信端末から取得される前記検査情報は、前記検査を受ける患者の属性を示す患者属性情報を含み、
   前記制御部は、
   前記通信端末から任意の前記患者属性情報を指定した統計情報絞り込み要求を受けたとき、
   前記患者属性情報の属性を有する検査情報を対象に絞り込んで前記統計処理を行う
   ように構成された検査サーバ。
8. 請求項１に記載の検査サーバであって、
   前記通信端末から取得される前記検査情報は、前記検査を行う前記通信端末の属性を示す端末属性情報を含み、
   前記制御部は、
   前記通信端末から任意の前記端末属性情報を指定した統計情報絞り込み要求を受けたとき、
   前記端末属性情報の属性を有する検査情報を対象に絞り込んで前記統計処理を行う
   ように構成された検査サーバ。
9. 請求項８に記載の検査サーバであって、
   前記制御部は、
   前記絞り込んだ検査情報に基づいて算出された前記統計処理の結果に、前記端末属性情報に基づく重み付けを行う
   ように構成された検査サーバ。
10. 請求項２に記載の検査サーバであって、
    前記制御部は、
    陽性率を前記有病率の代わりに用いることが可能な
    ように構成された検査サーバ。
11. 請求項１０に記載の検査サーバであって、
    前記検査情報は、前記検査を行う方法を識別する情報を含み、
    前記制御部は、
    同一の前記疾患の前記検査を行う複数の前記方法について、
    前記各々の方法ごとに、予め与えられた各感度および各特異度のうち、
    これら感度および特異度が予め要求される所定の値を満足する方法により得られた複数の前記検査情報に対する前記統計処理の結果である前記陽性率を、
    他の前記方法によって得られた複数の前記検査情報に対する各々の前記統計処理の結果である各々の有病率の代わりに用いることが可能な
    ように構成された検査サーバ。
12. 請求項２に記載の検査サーバであって、
    前記制御部は、
    前記陽性的中率を基に、前記検査の有効性を評価し、その評価結果を前記通信端末に送信し、前記通信端末に前記検査の推奨または非推奨のメッセージを提示させる
    ように構成された検査サーバ。
13. 請求項２に記載の検査サーバであって、
    前記通信端末から取得される前記検査情報は、前記検査を行う前記通信端末の属性を示す端末属性情報として、前記通信端末が位置する地域の情報を含み、
    前記制御部は、
    前記検査が未実施である第１の地域における前記有病率を、前記有病率が得られた、前記第１の地域とは異なる１つ以上の第２の地域における各々の有病率と、前記第２の地域各々と前記第１の地域との間における、感染に影響を与える要因を基に推定する
    ように構成された検査サーバ。
14. 請求項２に記載の検査サーバであって、
    前記制御部は、
    定期的に前記統計処理を行い前記有病率の履歴情報を作成し、
    前記履歴情報に基づいて、将来の有病率を予測する
    ように構成された検査サーバ。
15. 請求項１に記載の検査サーバであって、
    前記制御部は、
    前記記憶された複数の検査情報を統計処理する代わりに、外部から取得した前記統計処理の結果を応答させる
    ように構成された検査サーバ。
16. 請求項１に記載の検査サーバであって、
    前記制御部は、
    前記検査の結果、前記診断の結果、および前記統計処理の結果のうち少なくとも１つに基づいた薬剤のリストを前記通信端末に送信し、前記通信端末に投薬を推奨する薬剤として前記リストを提示させる、
    もしくは、
    前記検査機器で検査可能な前記検査の方法のリストと、
    前記リスト内で推奨される検査の方法を示す推奨マークと、
    前記検査を開始するためのユーザインターフェイスと
    を前記通信端末に提示させる
    ように構成された検査サーバ。
17. 疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報として複数個収集し、収集した複数の前記検査情報を統計処理した結果を提供する検査サーバとネットワークを介して通信する通信部と、
    医師であるユーザからの入力を受け付ける入力部と、
    前記検査サーバに前記統計処理の結果の要求を前記通信部により送信させ、
    検査機器に前記検査を実行させ、
    前記検査サーバから前記通信部により受信された前記統計処理の結果および当該実行された検査の結果を前記ユーザに提示し、
    当該実行された検査に関する前記診断の結果を、前記入力部を用いて前記ユーザに入力させ、
    当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、前記通信部により前記検査サーバへ送信させる
    ように構成された制御部と
    を具備する通信端末。
18. 検査サーバと複数の通信端末を具備する検査システムであって、
    前記検査サーバは、
    前記複数の通信端末とネットワークを介して通信する第１の通信部と、
    前記複数の通信端末から、少なくとも疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報としてそれぞれ前記通信部により取得し、
    前記取得された複数の検査情報を記憶部に記憶させ、
    前記記憶された複数の検査情報を統計処理し、
    前記医師による診断の前に前記通信端末から与えられる要求に応じて、前記統計処理の結果を前記通信部により応答させる
    ように構成された第１の制御部と
    を具備し、
    前記通信端末は、
    前記検査サーバと前記ネットワークを介して通信する第２の通信部と、
    医師であるユーザからの入力を受け付ける入力部と、
    前記検査サーバに前記統計処理の結果の前記要求を前記通信部により送信させ、
    検査機器に前記検査を実行させ、
    前記検査サーバから前記通信部により受信された前記統計処理の結果および当該実行された検査の結果を前記ユーザに提示し、
    当該実行された検査に関する前記診断の結果を、前記入力部を用いて前記ユーザに入力させ、
    当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、前記通信部により前記検査サーバへ送信させる
    ように構成された第２の制御部と
    を具備する
    検査システム。
19. 制御部が、
    疾患の有無の検査を実行可能な検査機器と接続可能とされ、かつ当該検査に関する医師による前記疾患の有無の診断の結果の入力が可能な複数の通信端末から、少なくとも前記検査の結果および前記診断の結果のうち少なくとも一方を検査情報としてそれぞれ通信部により取得し、
    前記取得された複数の検査情報を記憶部に記憶させ、
    前記記憶された複数の検査情報を統計処理し、
    前記医師による診断の前に前記通信端末から与えられる要求に応じて、前記統計処理の結果を前記通信部により応答させる
    検査方法。
    
    
20. 制御部が、
    疾患の有無の検査の結果および当該検査に関する医師による前記疾患の有無の診断の結果のうち少なくとも一方を検査情報として複数個収集し、収集した複数の前記検査情報を統計処理した結果を提供する検査サーバとネットワークを介して通信する通信部により、前記検査サーバに前記統計処理の結果の要求を送信させ、
    前記検査サーバに前記統計処理の結果の要求を前記通信部により送信させ、
    検査機器に前記検査を実行させ、
    前記検査サーバから前記通信部により受信された前記統計処理の結果および当該実行された検査の結果を医師であるユーザに提示し、
    当該実行された検査に関する前記診断の結果を、前記ユーザからの入力を受け付ける入力部を用いて前記ユーザに入力させ、
    当該実行された検査の結果および当該入力された診断の結果のうち少なくとも一方を前記検査情報として、前記通信部により前記検査サーバへ送信させる
    検査方法。

Images