JP2020098515A - 管理装置及び管理システム - Google Patents

Abstract

【課題】医用画像の画像解析に利用されるアプリケーションの使用実績を容易に把握する管理装置及び管理システムを提供すること。【解決手段】実施形態の管理装置は、収集部と、出力部とを有する。収集部は、医用レポートの作成に用いられた医用画像の画像解析に利用されたアプリケーションを特定する特定情報を、複数の前記医用レポートから収集する。出力部は、収集された複数の前記特定情報を用いて、前記アプリケーションの利用状況を示す情報を出力する。【選択図】図２

Description

本発明の実施形態は、管理装置及び管理システムに関する。

病院等において、医用画像の画像解析に利用されるアプリケーションの使用実績を把握したいという要望がある。この要望に応える技術として、例えば、診断や治療の目的に応じた医療画像処理システムの専用アプリケーションを提供するサービスセンタが、専用アプリケーションの使用実績に基づいて使用料を算出する技術が知られている。また、ユーザが必要としている医療情報の生成を行う上で適切なアプリケーションをワークフローマネージャが選択し、選択されたアプリケーションに関する情報を記憶する技術も知られている。

しかし、上記技術においては、医用画像の画像解析に利用されるアプリケーションの使用実績の把握が容易ではない場合がある。例えばサービスセンタから提供される使用実績と、病院における診療オーダ等とを対応付けることが難しい場合がある。また、ワークフローマネージャを用いた場合には、診療オーダの提出元である医師等ではなく、診療オーダの提出先である技師等により選択されたアプリケーションを特定できないことがある。

特開２００３−２７１９２４号公報 特開２０１５−１１４６９１号公報 特開２０１５−２２２４６９号公報

本発明が解決しようとする課題は、医用画像の画像解析に利用されるアプリケーションの使用実績を容易に把握することである。

実施形態の管理装置は、収集部と、出力部とを有する。収集部は、医用レポートの作成に用いられた医用画像の画像解析に利用されたアプリケーションを特定する特定情報を、複数の前記医用レポートから収集する。出力部は、収集された複数の前記特定情報を用いて、前記アプリケーションの利用状況を示す情報を出力する。

図１は、第１の実施形態に係る実績管理システムの構成の一例を示す図である。 図２は、第１の実施形態に係る実績管理システムの機能ブロックの一例を示す図である。 図３は、第１の実施形態に係るアプリテーブルの一例を示す図である。 図４は、第１の実施形態に係るオーダテーブルの一例を示す図である。 図５は、第１の実施形態に係るレポートテーブルの一例を示す図である。 図６は、第１の実施形態に係る日別の実績表示画面の一例を示す図である。 図７は、第１の実施形態に係る臨床アプリごとの実績表示画面の一例を示す図である。 図８は、第１の実施形態に係る個別の臨床アプリの実績表示画面の一例を示す図である。 図９は、第１の実施形態に係る想定症例別の実績表示画面の一例を示す図である。 図１０は、第１の実施形態に係る実績管理処理の流れの一例を示すシーケンス図である。 図１１は、第１の実施形態に係る目的判定処理の一例を示すフローチャートである。

以下に図面を参照して、管理装置及び管理システムの実施形態について詳細に説明する。本実施形態において、医用画像とは、例えばＸ線ＣＴ装置（ＣＴ；Computed Tomography）、ＭＲＩ（Magnetic Resonance Imaging）装置、超音波診断装置などの医用画像診断装置（モダリティ（Modality））により撮影された患者の画像を示す。また、本実施形態において、画像解析とは、例えば臨床において医用画像に対する読影を担当する医師（以下において「読影者」と表記する場合がある）や画像の確認をする技師による読影や確認を支援する等の目的で、医用画像に対する画像処理を行うことを示す。本実施形態における画像解析は、例えば医用画像から骨部分を除去したり、血管部分を抽出したりする処理や、３次元の情報を反映した２次元画像データを生成するボリュームレンダリング（ＶＲ：Volume Rendering）処理などを含むが、これらに限られない。また、以下において、医用画像の画像解析に利用されるアプリケーションを、「臨床アプリ」と表記する場合がある。

図１は、第１の実施形態に係る実績管理システムの構成の一例を示す図である。図１に示すように、本実施形態に係る実績管理システム１は、実績管理装置１０と、ＲＩＳ（Radiology Information System）２０と、ＰＡＣＳ（Picture Archiving and Communication System）３０と、ＰＡＣＳビューア３１と、アプリサーバ４０と、ＨＩＳ（Hospital Information System）５０とを有する。

図１において、実績管理装置１０は、例えば、医用画像に対する画像解析に用いられた臨床アプリに関する情報を収集して、画像解析における臨床アプリの利用状況に関する情報を出力する。ＲＩＳ２０は、各種のモダリティによる医用画像の撮影や、医用画像に基づく医用レポートのオーダを出力する。ＲＩＳ２０は、例えばＤＩＣＯＭ（Digital Imaging and Communications in Medicine）仕様のワークリストサーバにより実装される。

図１において、ＰＡＣＳ３０は、収集された医用画像を記憶したり、医用画像に対して各種画像処理を行ったりする装置である。ＰＡＣＳ３０は、各種画像処理を行う際に、外部の臨床アプリを用いる場合がある。ＰＡＣＳビューア３１は、例えばＰＡＣＳ３０に対する操作を受け付け、またＰＡＣＳ３０から出力される情報を表示する端末である。ＰＡＣＳビューア３１は、例えばＰＡＣＳ３０の管理者（不図示）や読影者（不図示）等により操作される。

図１において、アプリサーバ４０は、例えば、臨床アプリを実行するコンピュータである。アプリサーバ４０は、ＰＡＣＳ３０の指示により臨床アプリを実行して医用画像に対する画像解析を行い、実行結果をＰＡＣＳ３０に出力する。ＨＩＳ５０は、電子カルテの生成や医事会計の管理など、病院全体の情報を管理するシステムである。なお、以下において、実績管理装置１０以外の各装置については公知のコンピュータにより実装されるため、詳細な説明は省略する。

図１において、まず、ＲＩＳ２０は、ＰＡＣＳ３０に対し、医用画像を用いた医用レポートの生成などのオーダを出力する（ステップＳ１１）。本実施形態において、ＲＩＳ２０は、医用画像に対する読影レポートの生成に関するオーダを出力する。この際、実績管理装置１０は、ＲＩＳ２０から出力された、オーダに関する情報を取得する（ステップＳ１２）。なお、本実施形態において、オーダは、医用画像の撮影をさらに要求するものであってもよく、また医用画像の撮影に関するオーダが、読影レポートの生成に関するオーダをさらに含むものであってもよい。

ＰＡＣＳ３０は、例えば読影者が操作するＰＡＣＳビューア３１から、臨床アプリを用いた画像解析の要求を受け付けると、当該臨床アプリを実行するアプリサーバ４０に、医用画像Ｐ１に対する画像解析を要求する（ステップＳ２１）。

アプリサーバ４０は、ＰＡＣＳ３０から画像解析の要求を受け付けると、医用画像Ｐ１に対して画像解析を行い、新たな医用画像Ｐ２を生成する。新たな医用画像Ｐ２は、例えば、医用画像Ｐ１に対し、臨床アプリが血管識別のための画像解析を施して生成された画像である。また、アプリサーバ４０は、新たな医用画像Ｐ２に、画像解析を実行した臨床アプリを識別する情報を示すタグを付して、ＰＡＣＳ３０に出力する（ステップＳ２２）。

ＰＡＣＳ３０は、例えば、ＰＡＣＳビューア３１に、医用画像Ｐ２を表示させる。ＰＡＣＳビューア３１は、例えば、医用画像Ｐ２を参照した読影者から、医用画像Ｐ２に対する読影レポートの文章の入力を受け付ける。そして、ＰＡＣＳ３０は、医用画像Ｐ２と、入力された文章とを含む読影レポートＲ１をＨＩＳ５０に出力する（ステップＳ３１）。その際、実績管理装置１０は、ＰＡＣＳ３０から出力された読影レポートＲ１に関する情報を取得する（ステップＳ３２）。実績管理装置１０は、取得した読影レポートＲ１に関する情報と、読影レポートＲ１に対応するオーダに関する情報とを用いて、読影レポート生成時に用いられた臨床アプリの利用状況を集計して出力する。

図２は、第１の実施形態に係る実績管理システムの機能ブロックの一例を示す図である。図２に示すように、実績管理システム１において、実績管理装置１０と、ＲＩＳ２０と、ＰＡＣＳ３０と、ＰＡＣＳビューア３１と、アプリサーバ４０ａ及び４０ｂと、ＨＩＳ５０とは、それぞれ有線又は無線による病院内のネットワークＮＷを通じて相互に接続される。なお、ネットワークＮＷには、モダリティ（Modality）等の病院におけるその他の各装置（不図示）も接続されている。なお、実績管理システム１に含まれるアプリサーバ４０の数は任意であり、アプリサーバ４０を１台だけ含むような構成でも、３台以上含むような構成であってもよい。また、以下において、アプリサーバ４０ａ及び４０ｂを区別せずに表現する場合は、単に「アプリサーバ４０」と表記する場合がある。

図２において、実績管理装置１０は、通信Ｉ／Ｆ（Interface）１１と、入力Ｉ／Ｆ１２と、ディスプレイ１３と、記憶回路１４と、処理回路１５とを有する。

通信Ｉ／Ｆ１１は、処理回路１５に接続され、ネットワークＮを介して接続された実績管理装置１０との間で行われる各種データの伝送及び通信を制御する。例えば、通信Ｉ／Ｆ１１は、ネットワークカードやネットワークアダプタ、ＮＩＣ（Network Interface Controller）等によって実現される。

入力Ｉ／Ｆ１２は、処理回路１５に接続され、実績管理装置１０の管理者（不図示）から受け付けた入力操作を電気信号に変換して処理回路１５に出力する。例えば、入力Ｉ／Ｆ１２は、スイッチボタン、マウス、キーボード、タッチパネル等である。

ディスプレイ１３は、処理回路１５に接続され、処理回路１５から出力される各種情報及び各種画像データを表示する。例えば、ディスプレイ１３は、液晶モニタやＣＲＴ（Cathode Ray Tube）モニタ、タッチパネル等によって実現される。

記憶回路１４は、処理回路１５に接続され、各種データを記憶する。例えば、記憶回路１４は、ＲＡＭ（Random Access Memory）、フラッシュメモリ等の半導体メモリ素子や、ハードディスク、光ディスク等によって実現される。本実施形態では、記憶回路１４は、例えば、図２に示すように、アプリテーブル１４１と、オーダテーブル１４２と、レポートテーブル１４３とを記憶する。

アプリテーブル１４１は、臨床アプリの利用目的等の情報を記憶する。ここで、アプリテーブル１４１に記憶される情報は、例えばアプリサーバ４０により入力され、又は実績管理装置１０の管理者により入力される。

図３は、第１の実施形態に係るアプリテーブルの一例を示す図である。例えば、アプリテーブル１４１は、図３に示すように、「アプリＩＤ」と、「検査目的」と、「対象病名」と、「対象モダリティ１」及び「対象モダリティ２」と、「パラメータ１」及び「パラメータ２」とを対応付けた情報である。ここで、図３における「アプリＩＤ」は、当該臨床アプリを一意に識別する識別子（IDentifier）を示す。「検査目的」は、当該臨床アプリによる画像解析の目的を示す。「対象病名」は、当該臨床アプリの画像解析の対象となる疾病の名称を示す。「対象モダリティ１」及び「対象モダリティ２」は、当該臨床アプリによる画像解析の対象となる医用画像が、どのモダリティにより撮影されたものであるかを示す。「パラメータ１」及び「パラメータ２」は、当該臨床アプリが適応する医用画像の属性を示す。なお、図３に示すテーブルには「対象モダリティ」及び「パラメータ」の欄が２つずつ設けられているが、欄の数はこれに限られない。また、検査対象の部位など、その他の情報をさらに含んでもよい。なお、以下において、データが登録されていない欄は「―」で示される。以下に説明するその他のテーブルにおいても同様である。

例えば、図３に示すテーブルの１段目のレコードは、アプリＩＤ「ＸＸＸＡ」の臨床アプリは、「癌」を対象とした「腫瘍識別」を目的とし、「ＣＴ」により「造影」して撮影された医用画像を対象とすることを示す。また、図３に示すテーブルの２段目のレコードは、アプリＩＤ「ＸＸＸＢ」の臨床アプリは、「梗塞」を対象とした「血管抽出」を目的とし、「ＣＴ」又は「ＭＲＩ」により撮影された「非造影」の医用画像を対象とすることを示す。

次に、オーダテーブル１４２は、例えばＲＩＳから出力された、読影レポート生成のオーダに関する情報を記憶する。ここで、オーダテーブル１４２は、例えば後に説明する収集機能１５１により設定される。

図４は、第１の実施形態に係るオーダテーブルの一例を示す図である。例えば、オーダテーブル１４２は、図４に示すように、「オーダＩＤ」と、「画像ＩＤ１」及び「画像ＩＤ２」と、「検査目的」と、「想定病名」と、「依頼元」と、「対象部位」と、「パラメータ」とを対応付けた情報である。ここで、図４における「オーダＩＤ」は、当該オーダを一意に識別する識別子を示す。「画像ＩＤ１」及び「画像ＩＤ２」は、当該オーダにおいて読影の対象となる画像を一意に識別する識別子を示す。「検査目的」は、当該オーダの対象となる読影レポートの検査目的を示す。「想定病名」は、当該オーダに含まれる、オーダを出力した段階で想定される疾病の名称を示す。「依頼元」は、当該オーダを出力した医師や病院等を示す。「対象部位」は、当該オーダにおいて読影対象とする部位を示す。「パラメータ」は、当該読影の対象とする医用画像の属性を示す。なお、図４に示すテーブルには「画像ＩＤ」の欄が２つ設けられ、「パラメータ」の欄が１つ設けられているが、欄の数はこれらに限られない。また、オーダが医用画像の撮影に関するものであるか又はレポートの生成に関するものであるか等のオーダの種別、モダリティの種別や装置、プロトコル、撮影方法、撮影を実施する技師の氏名など、その他の情報をさらに含んでもよい。

例えば、図４に示すテーブルの１段目のレコードは、オーダＩＤ「Ｏｒｄ０００１」のオーダは、画像ＩＤ「Ｐｉｃ０００１」及び「Ｐｉｃ００１１」の「造影」された「胸部」の医用画像に対する、「肺癌」を想定した「腫瘍識別」を目的とする読影を依頼するもので、「放射線科の●●医師」により依頼されたことを示す。また、例えば、図４に示すテーブルの２段目のレコードは、オーダＩＤ「Ｏｒｄ０００２」のオーダは、画像ＩＤ「Ｐｉｃ０００２」の「頭部」の医用画像に対する、「脳梗塞」を想定した「血管抽出」を目的とする読影を依頼するもので、「●●病院脳外科」により依頼されたことを示す。また、例えば、図４に示すテーブルの３段目のレコードは、オーダＩＤ「Ｏｒｄ０００３」のオーダは、画像ＩＤ「Ｐｉｃ０００３」の「下部消化器」の医用画像に対する、「膵腫瘤」を想定した「腫瘍識別」を目的とする読影を依頼するもので、「消化器科の●●医師」により依頼されたことを示す。

次に、レポートテーブル１４３は、オーダに対応して生成された読影レポートに関する情報を記憶する。ここで、レポートテーブル１４３は、例えば収集機能１５１により設定される。

図５は、第１の実施形態に係るレポートテーブルの一例を示す図である。例えば、レポートテーブル１４３は、図５に示すように、「レポートＩＤ」と、「オーダＩＤ」と、「画像ＩＤ１」及び「画像ＩＤ２」と、「アプリＩＤ１」及び「アプリＩＤ２」と、「所見」と、「目的外」と、「寄与」と、「生成日」とを対応付けた情報である。ここで、図５における「レポートＩＤ」は、オーダＩＤに対応して生成された読影レポートを一意に識別する識別子を示す。なお、「画像ＩＤ１」及び「画像ＩＤ２」は、当該読影レポートの対象となった、画像解析後の画像を一意に識別する画像ＩＤを記憶する。「アプリＩＤ１」及び「アプリＩＤ２」は、「画像ＩＤ１」及び「画像ＩＤ２」のいずれかの画像に対する画像解析に用いられた臨床アプリを特定するタグを示す。なお、本実施形態において、臨床アプリを特定するタグは、例えば画像解析の対象となった医用画像に付与される、当該臨床アプリのアプリＩＤである。「所見」は、当該読影レポートにおいて示される疾病の名称を示す。「目的外」は、当該読影レポートの生成の際に画像解析に用いられた臨床アプリが、当該臨床アプリの検査目的以外の目的において利用されたことを示すフラグである。「寄与」は、当該読影レポートの生成の際に画像解析に用いられた臨床アプリが、当該読影レポートにおける所見に寄与したことを示すフラグである。なお、各フラグには、条件に該当する場合は「Ｙ」が登録され、条件に該当しない場合には「―」となる。「生成日」は、当該読影レポートが生成された日を示す。なお、「アプリＩＤ１」及び「アプリＩＤ２」の欄の数は２つに限られない。また、読影レポートの生成に際し、臨床アプリが利用されなかった場合、「アプリＩＤ１」及び「アプリＩＤ２」の欄は「―」となる。

例えば、図５に示すテーブルの１段目のレコードは、オーダＩＤ「Ｏｒｄ０００１」のオーダに対応するレポートＩＤ「Ｒｅｐ０００１」の読影レポートは、アプリＩＤ「ＸＸＸＢ」の臨床アプリにより画像解析された、画像ＩＤ「ＰｉｃＢ００１」及び「ＰｉｃＢ０１１」の画像に関するもので、所見が「肺癌」であることを記憶する。また、図５に示すテーブルの１段目のレコードは、例えば、当該読影レポートが「２０１８年９月７日」に生成され、アプリＩＤ「ＸＸＸＢ」の臨床アプリは目的外に利用されており、かつ所見に寄与していないことを記憶する。なお、本実施形態において、画像ＩＤ「ＰｉｃＢ００１」の画像は、画像ＩＤ「Ｐｉｃ０００１」の画像に対してアプリＩＤ「ＸＸＸＢ」の臨床アプリにより画像解析されて生成された画像であり、画像ＩＤ「ＰｉｃＢ０１１」の画像は、画像ＩＤ「Ｐｉｃ００１１」の画像に対してアプリＩＤ「ＸＸＸＢ」の臨床アプリにより画像解析されて生成された画像である。また、例えば、図５に示すテーブルの２段目のレコードは、オーダＩＤ「Ｏｒｄ０００２」のオーダに対応するレポートＩＤ「Ｒｅｐ０００２」の読影レポートは、アプリＩＤ「ＸＸＸＡ」及び「ＸＸＸＣ」の各臨床アプリにより画像解析された画像ＩＤ「ＰｉｃＡＣ０２」の画像に関するもので、所見が「脳梗塞」であることを記憶する。また、図５に示すテーブルの２段目のレコードは、例えば、当該読影レポートが「２０１８年９月７日」に生成され、アプリＩＤ「ＸＸＸＡ」及び「ＸＸＸＣ」の臨床アプリを用いた画像解析は目的外利用には該当せず、かつ所見に寄与していないことを記憶する。さらに、例えば、図５に示すテーブルの段目のレコードは、オーダＩＤ「Ｏｒｄ０００３」のオーダに対応するレポートＩＤ「Ｒｅｐ０００３」の読影レポートは、アプリＩＤ「ＸＸＸＡ」の臨床アプリにより画像解析された画像ＩＤ「Ｐｉｃ０００３」の画像に関するもので、所見が「副脾」であることを記憶する。また、図５に示すテーブルの３段目のレコードは、例えば、当該読影レポートが「２０１８年９月８日」に生成され、アプリＩＤ「ＸＸＸＡ」の臨床アプリを用いた画像解析は目的外利用には該当せず、かつ所見に寄与したことを記憶する。

図２に戻って、処理回路１５は、収集機能１５１と、判定機能１５２と、出力機能１５３とを実行する。ここで、収集機能１５１は、収集部の一例である。判定機能１５２は、判定部の一例である。また、出力機能１５３は、出力部の一例である。ここで、例えば、図２に示す処理回路１５の構成要素である収集機能１５１、判定機能１５２及び出力機能１５３の各処理機能は、コンピュータによって実行可能なプログラムの形態で記憶回路１４に記録されている。処理回路１５は、各プログラムを記憶回路１４から読み出し、読み出した各プログラムを実行することで各プログラムに対応する機能を実現する。換言すると、各プログラムを読み出した状態の処理回路１５は、図２の処理回路１５内に示された各機能を有することとなる。

なお、収集機能１５１、判定機能１５２及び出力機能１５３の全ての処理機能がコンピュータによって実行可能な１つのプログラムの形態で、記憶回路１４に記録されていてもよい。例えば、このようなプログラムは、実績管理プログラムとも称される。この場合、処理回路１５は、実績管理プログラムを記憶回路１４から読み出し、読み出した実績管理プログラムを実行することで実績管理プログラムに対応する収集機能１５１、判定機能１５２及び出力機能１５３を実現する。

処理回路１５における収集機能１５１は、臨床アプリやオーダ、読影レポートに関する各種の情報を収集する。例えば、収集機能１５１は、アプリサーバ４０から、導入された臨床アプリに関するアプリＩＤ、検査目的、対象病名等の情報を収集し、アプリテーブル１４１に格納する。又は、収集機能１５１は、実績管理装置１０の管理者から、入力Ｉ／Ｆ１２を通じて入力された、臨床アプリに関するアプリＩＤ、検査目的、対象病名等の情報を収集し、アプリテーブル１４１に格納する。また、収集機能１５１は、例えば、ＲＩＳ２０がＰＡＣＳ３０に読影レポートを要求するオーダを送信する際に、当該オーダに関するオーダＩＤ、画像ＩＤ、検査目的、想定病名等の情報を収集し、オーダテーブル１４２に格納する。換言すると、オーダテーブル１４２のレコードは、収集機能１５１がオーダに関する情報を収集するごとに１つずつ増加する。さらに、収集機能１５１は、例えば、ＰＡＣＳ３０がＨＩＳ５０に読影レポートを送信する際に、当該読影レポートに関するレポートＩＤ、画像ＩＤ、所見等の情報を収集し、レポートテーブル１４３に格納する。この際、収集機能１５１は、例えば、ＰＡＣＳ３０にアクセスして、画像ＩＤに対応する画像にタグ情報が付されている場合、当該タグ情報を取得し、レポートテーブル１４３に格納する。換言すると、レポートテーブル１４３のレコードは、収集機能１５１がオーダに関する情報を収集するごとに１つずつ増加する。

収集機能１５１は、例えば、オーダや読影レポートに含まれるタグを取得し、タグに対応付けられたオーダＩＤや画像ＩＤ等の情報を特定して収集するが、実施の形態はこれに限られない。例えば、収集機能１５１は、読影レポートに用いられる構造化レポートを解析することにより、医用レポートの記載内容を特定してもよい。また、収集機能１５１は、読影レポートの記載内容に対する形態素解析を行うことにより、読影レポートに記載された所見により特定される疾病の名称等を特定するような構成であってもよい。

判定機能１５２は、オーダに関する情報と、アプリに関する情報又は読影レポートに関する情報とを比較して、条件に合致するか否かを判定する。判定機能１５２は、例えば、図５に示すようなレポートテーブル１４３に記憶された「オーダＩＤ」並びに「アプリＩＤ１」及び「アプリＩＤ２」を読み出す。次に、判定機能１５２は、オーダテーブル１４２を参照し、レポートテーブル１４３の「オーダＩＤ」に合致するレコードの「検査目的」を取得する。次に、判定機能１５２は、アプリテーブル１４１を参照し、レポートテーブル１４３の「アプリＩＤ１」又は「アプリＩＤ２」に合致するレコードの「検査目的」を取得する。そして、判定機能１５２は、オーダテーブル１４２から取得した「検査目的」と、アプリテーブル１４１から取得した「検査目的」とが一致するか否かを判定する。判定機能１５２は、双方の「検査目的」が一致しないと判定した場合、レポートテーブル１４３の該当するレコードの「目的外」に「Ｙ」を登録する。

例えば、図５に示すようなレポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００１」のレコードのオーダＩＤ「Ｏｒｄ０００１」に対応するオーダテーブル１４２のレコードの「検査目的」は、図４に示すように「腫瘍識別」である。一方、レポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００１」のレコードのアプリＩＤ１「ＸＸＸＢ」に対応するアプリテーブル１４１のレコードの「検査目的」は、図３に示すように「血管抽出」である。この場合、判定機能１５２は、双方の「検査目的」が一致しないと判定するので、レポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００１」のレコードの「目的外」に「Ｙ」を登録する。一方、例えば、図５に示すようなレポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００３」のレコードのオーダＩＤ「Ｏｒｄ０００３」に対応するオーダテーブル１４２のレコードの「検査目的」は、図４に示すように「腫瘍識別」である。一方、レポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００３」のレコードのアプリＩＤ１「ＸＸＸＡ」に対応するアプリテーブル１４１のレコードの「検査目的」は、図３に示すように「腫瘍識別」である。この場合、判定機能１５２は、双方の「検査目的」が一致すると判定するので、レポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００３」のレコードの「目的外」には何も登録しない。

また、判定機能１５２は、例えば、図５に示すようなレポートテーブル１４３に記憶された「オーダＩＤ」及び「所見」を読み出す。次に、判定機能１５２は、オーダテーブル１４２を参照し、レポートテーブル１４３の「オーダＩＤ」に合致するレコードの「想定病名」を取得する。そして、判定機能１５２は、オーダテーブル１４２から取得した「想定病名」と、レポートテーブル１４３から取得した「所見」とが一致するか否かを判定する。判定機能１５２は、「想定病名」と「所見」とが一致しないと判定した場合、例えば、画像解析後の医用画像を読影することにより「所見」が変化したと考えられる場合、レポートテーブル１４３の該当するレコードの「寄与」に「Ｙ」を登録する。

例えば、図５に示すようなレポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００１」のレコードの所見「肺癌」と、当該レコードのオーダＩＤ「Ｏｒｄ０００１」に対応するオーダテーブル１４２のレコードの想定病名「肺癌」は一致する。この場合、判定機能１５２は、「想定病名」と「所見」とが一致すると判定するので、レポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００１」のレコードの「寄与」には何も登録しない。一方、レポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００３」のレコードの所見「副脾」と、当該レコードのオーダＩＤ「Ｏｒｄ０００３」に対応するオーダテーブル１４２のレコードの想定病名「膵腫瘤」とは一致しない。この場合、判定機能１５２は、「想定病名」と「所見」とが一致しないと判定するので、レポートテーブル１４３のレポートＩＤ「Ｒｅｐ０００３」のレコードの「寄与」に「Ｙ」を登録する。

次に、出力機能１５３は、レポートテーブル１４３に記憶された、医用画像の画像解析に用いられた臨床アプリに関する情報を用いて、読影レポート生成時における臨床アプリの利用状況に関する情報を生成して出力する。その際、出力機能１５３は、臨床アプリの利用状況を、臨床アプリが利用された日付や、読影レポートの対象部位、検査目的等、各種の条件により絞り込み、又は分類する。また、出力機能１５３は、各種の条件により絞り込まれ、又は分類された臨床アプリの利用状況を、例えばグラフ化して、実績管理装置１０の管理者の端末（不図示）の画面等に出力する。

例えば、出力機能１５３は、図５に示すようなレポートテーブル１４３のうち、「生成日」によって臨床アプリの利用状況を分類することにより、図６に示すようなグラフを出力する。図６は、第１の実施形態に係る日別の実績表示画面の一例を示す図である。図６に示す画面９０ａには、画面のタイトル９１ａと、日付ごとの臨床アプリの利用状況のグラフ９２ａと、メッセージ欄９３ａとが表示される。図６に示すように、画面のタイトル９１ａは、「各臨床アプリの日別利用状況」である。また、グラフ９２ａは、「９月７日」に「６件」の読影レポートが生成され、そのうち「４件」の読影レポートで臨床アプリが利用され、「２件」の読影レポートには臨床アプリが利用されなかったことを示す。同様に、グラフ９２ａは、「９月８日」に「２件」の読影レポートで臨床アプリが利用され、「２件」の読影レポートには臨床アプリが利用されなかったことを示す。さらに、グラフ９２ａは、「９月９日」に「５件」の読影レポートで臨床アプリが利用され、「１件」の読影レポートには臨床アプリが利用されなかったこと、「９月１０日」に「１件」の読影レポートで臨床アプリが利用され、「４件」の読影レポートには臨床アプリが利用されなかったことをそれぞれ示す。なお、図６に示すように、メッセージ欄９３ａにはメッセージは表示されない。

また、例えば、出力機能１５３は、図５に示すようなレポートテーブル１４３のうち、「アプリＩＤ１」又は「アプリＩＤ２」が登録されているレコード、すなわち読影レポートの生成に臨床アプリが利用されたレコードを絞り込んでもよい。この場合、出力機能１５３は、絞り込まれたレコードを、「アプリＩＤ１」又は「アプリＩＤ２」によって分類することにより、図７に示すようなグラフを出力してもよい。図７は、第１の実施形態に係る臨床アプリごとの実績表示画面の一例を示す図である。図７に示す画面９０ｂには、画面のタイトル９１ｂと、臨床アプリの種類ごとの利用状況のグラフ９２ｂと、メッセージ欄９３ｂとが表示される。図７に示すように、画面のタイトル９１ｂは、グラフ９２ｂが、９月７日から１０日の期間における「各臨床アプリの利用内訳」を示すグラフであることを示す。グラフ９２ｂは、当該期間において、「臨床アプリＡ」が「４件」の読影レポートで利用されたことを示す。同様に、グラフ９２ｂは、当該期間において、「臨床アプリＢ」が「２件」の読影レポートで利用され、「臨床アプリＣ」が「５件」の読影レポートで利用され、「臨床アプリＤ」が「１件」の読影レポートで利用されたことを示す。なお、図７に示すように、メッセージ欄９３ｂにはメッセージは表示されない。

また、例えば、出力機能１５３は、図５に示すようなレポートテーブル１４３のうち、「アプリＩＤ１」又は「アプリＩＤ２」に「ＸＸＸＡ」が登録されているか否かにより、レコードを分類してもよい。この際、出力機能１５３は、分類されたレコードを、さらに「目的外」及び「寄与」により分類することにより、図８に示すようなグラフを出力してもよい。図８は、第１の実施形態に係る個別の臨床アプリの実績表示画面の一例を示す図である。図８に示す画面９０ｃには、画面のタイトル９１ｃと、臨床アプリＡの利用状況のグラフ９２ｃと、メッセージ欄９３ｃとが表示される。図８に示すように、画面のタイトル９１ｃは、グラフ９２ｃが、９月１日から７日の期間における「臨床アプリＡの利用状況」を示すグラフであること、及び臨床アプリＡのアプリＩＤが「ＸＸＸＡ」であることを示す。グラフ９２ｃは、当該期間において、「臨床アプリＡ」が「９件」の読影レポートで利用され、そのうち「１件」では所見に寄与したことを示す。同様に、グラフ９２ｃは、当該期間において、「臨床アプリＡ」は「２１件」の読影レポートでは利用されなかったことを示す。なお、図８に示すように、メッセージ欄９３ｃには、レポートＩＤ「Ｒｅｐ０００１」の読影レポートの生成の際に、臨床アプリＡが目的外において利用されたことを示すメッセージが表示される。

また、例えば、出力機能１５３は、図５に示すようなレポートテーブル１４３のうち、「アプリＩＤ１」又は「アプリＩＤ２」が登録されているレコードに絞り込み、さらにオーダテーブル１４２に登録された「想定症例」によって分類することにより、図９に示すようなグラフを出力してもよい。図９は、第１の実施形態に係る想定症例別の実績表示画面の一例を示す図である。図９に示す画面９０ｄには、画面のタイトル９１ｄと、想定症例別の臨床アプリの利用状況のグラフ９２ｄと、メッセージ欄９３ｄとが表示される。図９に示すように、画面のタイトル９１ｄは、グラフ９２ｄが、９月１日から７日の期間における「各臨床アプリの想定症例別利用状況」を示すグラフであることを示す。グラフ９２ｄは、当該期間において、「肺癌」を想定症例とするオーダに対して、「臨床アプリＡ」が「４件」の読影レポートで利用され、「臨床アプリＢ」及び「臨床アプリＣ」がそれぞれ「２件」の読影レポートで利用され、「臨床アプリＤ」が「１件」の読影レポートで利用されたことを示す。同様に、グラフ９２ｄは、当該期間において、「肝癌」を想定症例とするオーダに対して、「臨床アプリＡ」及び「臨床アプリＣ」がそれぞれ「２件」の読影レポートで利用され、「臨床アプリＢ」が「４件」の読影レポートで利用され、「臨床アプリＤ」が「１件」の読影レポートで利用されたことを示す。同様に、グラフ９２ｄは、当該期間において、「大腸癌」を想定症例とするオーダに対して、「臨床アプリＡ」、「臨床アプリＢ」及び「臨床アプリＣ」がそれぞれ「２件」の読影レポートで利用され、「臨床アプリＤ」が「１件」の読影レポートで利用されたことを示す。同様に、グラフ９２ｄは、当該期間において、「その他」の想定症例であるオーダに対して、「臨床アプリＡ」及び「臨床アプリＣ」がそれぞれ「１件」の読影レポートで利用され、「臨床アプリＢ」が「２件」の読影レポートで利用され、「臨床アプリＤ」が「４件」の読影レポートで利用されたことを示す。なお、図９に示すように、メッセージ欄９３ｄにはメッセージは表示されない。

なお、上述した各種の条件は一例であり、また各種の条件は組み合わせて用いられてもよい。例えば、分類の条件として確定診断のついた疾患を用いて、臨床アプリの利用状況に関する情報を分類し、さらに検査目的や想定病名の条件により臨床アプリの利用状況に関する情報を絞り込んでもよい。

次に、第１の実施形態に係る実績管理システム１による処理の手順について、図１０及び図１１を用いて説明する。図１０は、第１の実施形態に係る実績管理処理の流れの一例を示すシーケンス図である。

例えば、図１０に示すように、本実施形態に係る実績管理システム１では、まず、ＲＩＳ２０が、ネットワークＮを通じて、ＰＡＣＳ３０に読影レポートの生成に関するオーダを出力する（ステップＳ１１）。ＲＩＳ２０が出力するオーダは、例えば、画像ＩＤ、検査目的、医師や病院等の依頼科、対象部位、モダリティ、パラメータ等の情報を含む。また、実績管理装置１０は、ＲＩＳ２０が出力したオーダに関する情報を取得し（ステップＳ１２）、オーダテーブル１４２にオーダ情報を登録する（ステップＳ１３）。

続いて、ＰＡＣＳ３０は、読影レポートの生成に際し、臨床アプリによる画像解析の処理要求を、アプリサーバ４０に出力する（ステップＳ２１）。処理要求は、例えば、アプリＩＤや画像ＩＤを含む。これに応じて、アプリサーバ４０は、画像解析を行った後の画像データに、当該臨床アプリを一意に識別するタグ情報を付与したＤＩＣＯＭ形式のデータを、ＰＡＣＳ３０に出力する（ステップＳ２２）。その後、ＰＡＣＳ３０は、アプリタグが付けられた画像データを含む読影レポートを、ＨＩＳ５０に出力する（ステップＳ３１）。ＰＡＣＳ３０が出力する読影レポートは、例えば、アプリタグが付された画像データ以外に、画像ＩＤ、レポートＩＤ、レポートの本文のテキストデータ等を含む。この際、実績管理装置１０は、ＰＡＣＳ３０が出力した読影レポートに関する情報を取得し（ステップＳ３２）、レポートテーブル１４３に読影レポートに関する情報を登録する（ステップＳ３３）。

そして、実績管理装置１０は、目的判定処理を実行する（ステップＳ６）。図１１は、第１の実施形態に係る目的判定処理の一例を示すフローチャートである。ここで、図１１におけるステップＳ６０は、例えば、処理回路１５が判定機能１５２に対応するプログラムを記憶回路１４から読み出して実行することにより実現される。また、ステップＳ６１からＳ６５までの各処理は、例えば、処理回路１５が判定機能１５２に対応するプログラムを記憶回路１４から読み出して実行することにより実現される。

例えば、図１１に示すように、本実施形態に係る実績管理システム１では、まず、処理回路１５は、ＰＡＣＳ３０から読影レポートに関する情報を取得したか否かを判定する（ステップＳ６０）。処理回路１５は、読影レポートに関する情報を取得していないと判定した場合（ステップＳ６０否定）、読影レポートに関する情報を取得するまで待機する。処理回路１５は、読影レポートに関する情報を取得したと判定した場合（ステップＳ６０肯定）、読影レポートに関する情報をレポートテーブル１４３に登録する。

次に、処理回路１５は、レポートテーブル１４３に登録された当該レコードの「検査目的」と、当該レポートのアプリＩＤに対応する、アプリテーブル１４１に登録された当該臨床アプリの「検査目的」とが合致するか、すなわち臨床アプリの利用目的が合致するか否かを判定する（ステップＳ６１）。処理回路１５は、臨床アプリの利用目的が合致すると判定した場合（ステップＳ６１肯定）、ステップＳ６３に移行する。

一方、処理回路１５は、臨床アプリの利用目的が合致しないと判定した場合（ステップＳ６１否定）、レポートテーブル１４３に「目的外」フラグを登録する（ステップＳ６２）。その後、ステップＳ６３に移行する。

次に、処理回路１５は、オーダテーブル１４２を参照し、レポートテーブル１４３に登録されたオーダＩＤに対応するオーダの「想定病名」を特定する（ステップＳ６３）。そして、処理回路１５は、「想定病名」と、レポートテーブル１４３に登録された「所見」とが合致するか否かを判定する（ステップＳ６４）。処理回路１５は、「想定病名」と「所見」とが合致すると判定した場合（ステップＳ６４肯定）、処理を終了する。

一方、処理回路１５は、「想定病名」と「所見」とが合致しないと判定すると（ステップＳ６４否定）、レポートテーブル１４３に「寄与」フラグを登録し（ステップＳ６５）、処理を終了する。

上述したように、第１の実施形態に係る実績管理システム１は、医用画像の画像解析に利用されるアプリケーションの使用実績を容易に把握することができるので、例えば読影レポートの生成に際し、臨床アプリがどれだけ寄与しているか、また適切な目的に利用されているかを容易に特定できる。

（変形例）
上述した実施形態では、医用レポートの一例として、読影医により作成される読影レポートを用いる構成について説明したが、実施の形態はこれに限られない。例えば、ＨＩＳにおいて生成される、ＨＩＳに登録された電子カルテや、ＶＮＡ（Vendor Neutral Archives）に登録された患者の情報等を医用レポートとして用いるような構成であってもよい。例えば、電子カルテに記載された診断病名が、ＲＩＳから出力されたオーダに記載された想定病名から変化したか否かを判定することにより、電子カルテに対応付けられた医用画像の画像解析に用いられた臨床アプリが、診断病名の特定に寄与したか否かを特定することができる。

また、臨床アプリの使用実績を、ＤＩＣＯＭ画像に付されたタグ情報を用いて収集する構成について説明したが、実施の形態はこれに限られない。例えば、臨床アプリが、ＤＩＣＯＭ画像に付すタグ情報とは別個に、画像解析に利用されたことを示す情報を出力する場合、出力された情報を用いて、画像解析に利用された臨床アプリを特定するような構成であってもよい。また、画像解析に利用された臨床アプリに関する情報を医用画像と対応付けて記憶するデータベースを参照して、医用レポートに対応付けられた医用画像の画像解析に利用された臨床アプリを特定するような構成であってもよい。さらに、医用レポートには用いられていない、ＰＡＣＳに登録された医用画像に含まれるタグ情報を用いて、医用画像の画像解析に利用された臨床アプリを特定してもよい。このように、複数のソースから臨床アプリの使用実績に関する情報を取得することにより、より精度よく臨床アプリの使用実績を特定することができる。

また、上述した実施形態では、ＲＩＳから取得した、放射線科によるオーダに基づく臨床アプリの利用状況を特定する構成について説明したが、実施の形態はこれに限られない。例えば、ＨＩＳから取得した、臨床診療科による診療オーダに基づいて、臨床アプリの利用状況を特定するような構成であってもよい。これにより、放射線科以外の診療科についても、臨床アプリの使用実績を特定することができる。

上述した各実施形態の説明で用いた「プロセッサ」という文言は、例えば、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、或いは、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、プログラマブル論理デバイス（例えば、単純プログラマブル論理デバイス（Simple Programmable Logic Device：ＳＰＬＤ）、複合プログラマブル論理デバイス（Complex Programmable Logic Device：ＣＰＬＤ）、及びフィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ））等の回路を意味する。ここで、メモリにプログラムを保存する代わりに、プロセッサの回路内にプログラムを直接組み込むように構成しても構わない。この場合には、プロセッサは回路内に組み込まれたプログラムを読み出し実行することで機能を実現する。また、本実施形態の各プロセッサは、プロセッサごとに単一の回路として構成される場合に限らず、複数の独立した回路を組み合わせて一つのプロセッサとして構成され、その機能を実現するようにしてもよい。

ここで、プロセッサによって実行されるプログラムは、ＲＯＭ（Read Only Memory）や記憶部等に予め組み込まれて提供される。なお、このプログラムは、これらの装置にインストール可能な形式又は実行可能な形式のファイルでＣＤ（Compact Disk）−ＲＯＭ、ＦＤ（Flexible Disk）、ＣＤ−Ｒ（Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記憶媒体に記録されて提供されてもよい。また、このプログラムは、インターネット等のネットワークに接続されたコンピュータ上に格納され、ネットワーク経由でダウンロードされることにより提供又は配布されてもよい。例えば、このプログラムは、各機能部を含むモジュールで構成される。実際のハードウェアとしては、ＣＰＵが、ＲＯＭ等の記憶媒体からプログラムを読み出して実行することにより、各モジュールが主記憶装置上にロードされて、主記憶装置上に生成される。

また、各実施形態における管理システムの構成は上記したものに限られず、例えば、ＰＡＣＳ３０が処理回路１５の一部又は全部の機能を実装してもよく、また記憶回路１４が記憶する内容の一部又は全部を記憶してもよい。例えば、ＰＡＣＳ３０が処理回路１５の全部の機能を実装し、記憶回路１４が記憶する内容の全部を記憶することにより、ＰＡＣＳ３０上において実績管理装置１０と同様の構成を実装することができる。また、実績管理装置１０の処理回路１５が有する各機能がクラウド上に実装され、記憶回路１４が記憶する内容がクラウド上に記憶されてもよい。

以上説明した少なくとも一つの実施形態によれば、医用画像の画像解析に利用されるアプリケーションの使用実績を容易に把握することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１ 実績管理システム
１０ 実績管理装置
１１ 通信Ｉ／Ｆ
１２ 入力Ｉ／Ｆ
１３ ディスプレイ
１４ 記憶回路
１４１ アプリテーブル
１４２ オーダテーブル
１４３ レポートテーブル
１５ 処理回路
１５１ 収集機能
１５２ 判定機能
１５３ 出力機能
２０ ＲＩＳ
３０ ＰＡＣＳ
３１ ＰＡＣＳビューア
４０ａ、４０ｂ アプリサーバ
５０ ＨＩＳ

Claims (5)

1. 医用レポートの作成に用いられた医用画像の画像解析に利用されたアプリケーションを特定する特定情報を、複数の前記医用レポートから収集する収集部と、
   収集された複数の前記特定情報を用いて、前記アプリケーションの利用状況を示す情報を出力する出力部と
   を備える管理装置。
2. 前記収集部は、前記画像解析により生成された解析済画像に含まれる、当該画像解析に利用されたアプリケーションを特定できるタグ情報を収集する請求項１に記載の管理装置。
3. 前記医用画像の撮影目的と、前記医用画像の画像解析に利用されたアプリケーションの利用目的とが合致するか否かを判定する判定部をさらに備え、
   前記出力部は、前記撮影目的が前記アプリケーションの利用目的と合致しないと判定された場合、前記アプリケーションが目的外利用されたことを示す情報を出力する請求項１又は２に記載の管理装置。
4. 前記収集部は、前記医用画像の撮影を指示するオーダに関する情報をさらに収集し、
   前記判定部は、前記オーダに含まれる想定病名と、前記医用レポートに含まれる診断病名とが合致するか否かを判定し、
   前記出力部は、前記想定病名と前記診断病名とが合致しないと判定した場合に、前記アプリケーションが診断に寄与したことを示す情報を出力する請求項３に記載の管理装置。
5. 医用レポートの作成に用いられた医用画像の画像解析に利用されたアプリケーションを特定する特定情報を、複数の前記医用レポートから収集する収集部と、
   収集された複数の前記特定情報を用いて、前記アプリケーションの利用状況を示す情報を出力する出力部と
   を有する管理システム。

Images