[0018] 例示的な実施形態は、以下の説明及び関連する添付図面を参照することで更に理解され、図中、同様の要素には同じ参照番号が与えられている。例示的な実施形態は、病理事例を完了するためのワークフローを最適化するためのデバイス、システム及び方法に関する。例示的な実施形態は、ワークフローの経路に沿って複数の選択を自動的に決定するように構成される。特に、例示的な実施形態は、病理事例が完了する方式を決定する全体プロセスを提供する。全体プロセスに沿って、ワークフローは複数のタスクに分割され、これらのタスクに病理学者がアサインされる。例示的な実施形態は、タスクアサインメントのディスパッチに関連付けられた最適化目標が満たされる方式を定義するようにポリシが生成されるメカニズムを提供する。例示的な実施形態は、ポリシと、利用可能な病理学者の動的に決定された現在の特性とに基づいてタスクアサインメントが決定されるメカニズムを更に提供する。以下で更に詳細に説明するように、例示的な実施形態は、デジタル病理学手順を利用し、ワークフロー経路に沿って自動的な方式で決定される選択のための機能を提供する。
[0019] 例示的な実施形態は、病理事例を完了するためのワークフローを最適化することに関して説明されることに留意されたい。しかしながら、病理事例及びそれに関連付けられたワークフローの使用は単なる例にすぎない。例示的な実施形態は、特に、ワークフローに関連付けられたタスクを決定し、最適化目標を満たすようにユーザをタスクにアサインすることを通じて、事例を完了するためにワークフローが用いられる任意の医療事例(例えば、画像取得手順)又は医療に関係していない事例と共に用いられるように変更されてもよい。また、例示的な実施形態は、病理学者をタスクにアサインすることに関連付けられたポリシを生成することに関しても説明される。しかしながら、病理学者をタスクにアサインするためのポリシを生成するための実施は例示にすぎない。例示的な実施形態は、ポリシを達成するためにルール又はモデル間の競合が解消されるように任意のエンティティのためのポリシを生成する際に用いられるように変更されてもよい。例示的な実施形態は、病理学者がワークフロー内の異なるタスクにどのようにアサインされるかの決定に関して更に説明される。しかしながら、タスクへの病理学者のアサインメントは例示にすぎない。例示的な実施形態は、最適化目標を達成するためのマッチを決定する際に用いられるように変更されてもよい。また、例示的な実施形態は、任意のタスク実行者がワークフロー内の異なるタスクをどのようにアサインされるかも決定するが、病理学者のみに限定されない(例えば、実験助手、アーキビスト等)。しかしながら、説明の目的のため、本明細書においては、例示的な実施形態は特に病理学者のアサインに関連して説明される。
[0020]例示的な実施形態は、アナログ病理学手順の下では病理事例を完了する際に利用可能でなかった情報を生成し使用するメカニズムを提供する。特に、例示的な実施形態は、試料のデジタルスライドの利用可能性を活用することによって生成される追加の情報が利用されるデジタル病理学手順を対象とする。以下で詳細に説明するように、デジタルスライドに対しアルゴリズムを適用して、ワークフロー選択、ワークフロー実行及びリソースアサインメント(例えば、病理学者、機器等)を駆動する。例示的な実施形態は、ワークフロー判定を駆動又は最適化するのに用いられる、デジタルスライドの自動解析を提供する。例えば、3つの異なる領域、すなわち、(1)ワークフローの選択と、(2)ワークフローにおける判定ポイントにおける経路の選択と、(3)リソース要件(例えば、病理学者が要する診断時間)の評価とが区別される。
[0021] 例示的な実施形態は、アナログ病理学手順に関連付けられたロケーション分離を利用する。ロケーション分離は、実験室内でデジタルスライドが作成され、スキャンされた後に、病理事例のワークフローを変更及び最適化する機会を導入する。例えば、病理事例のワークフローは、更なる洞察が生成され、効率性及び品質を改善することを可能にする。更に、デジタル病理学スライドの解析を用いて、ワークフローが操作され、リソース割当てが改善される。また、ロケーション分離要件は、どの病理学者が試料を診断するか等の、事例の計画及びスケジューリングに対し影響を有する。デジタル病理学の実験室では、病理学エンティティに関連付けられた病理学者は、様々なソースから到来した事例を、病理学エンティティ内から内部的に評価し(例えば、ルーチン診断)、病理学エンティティ外から外部的に評価する(例えば、セカンドオピニオン要求)ように要求される。当業者は、ロケーション分離が、病理事例を完了する際の更なる柔軟性を可能にすることを理解する。しかしながら、従来の手法は、デジタル病理学手順のロケーション分離の態様しか利用することができず、アナログ病理学手順として病理事例を完了する全ての残りの方式を依然として維持する。
[0022] 例示的な実施形態は、病理事例を扱う粒度の変更も提供する。従来の手法は、病理事例全体を単一の病理学者にアサインすることに依拠している。したがって、選択された病理学者は、病理事例を完了するのに必要な全ての動作を実行するか、又は(例えば、特定の専門知識が必要であるときに)他の動作を決定し、委任する。しかしながら、例示的な実施形態は、(例えば、デジタルスライドから導出された情報に基づいて)病理事例に関連付けられた1つ又は複数のタスクを決定する方式を導入する。したがって、各タスクは、いずれの病理学者がタスクにアサインされるかを決定するのに用いられる、独自の検討事項及び判断基準を有する。
[0023] 以下で詳細に説明するように、例示的な実施形態は、病理学ワークフローにおけるタスクを実行するのに用いられるリソース(例えば、病理学者)を管理しかつ/又はアサインする自動リソースプランナーを提供する。リソースプランナーは、病理学スライドの自動解析からの情報を用いて、リソース要件をより良好に評価する。例えば、IHC HER2スコアリングアルゴリズムは、HER2 FISH試験の発注を伴うワークフローがトリガされ得るように、可能性の高い曖昧スコアを示す。その後、リソースプランナーは、この情報を用いて、この事例を診断するのに必要な予測診断時間をより良好に評価する(発注されたHER2 FISH試験は診断アクティビティに影響を有するため)。
[0024] また、自動リソースプランナーは、リソースをどのようにアサインするかを決定する際に原子レベルでモデルを組み込む。例示的な実施形態は、モデル化、実施、及びポリシの後続の適合を効率的にスケールアップし、ルール及び目標の再利用を増大させ、多数のルール及び目標を定義及び管理する際の誤りを回避するのに役立つ解決策を提供する。また、例示的な実施形態は、病理学エンティティのポリシ全体の実施態様を、別の病理学エンティティのために選択され適合されるテンプレートとして用いる。この代替的な手法において、例示的な実施形態は、ルール間の競合を検出し、最適化解に達することを可能にするスコア間の正しいトレードオフを設定し、更なる病理学エンティティのための適合解を検証/デバッグするように構成される。例示的な実施形態は、更に、病理事例又はタスクの自動アサインメントの基礎をなすドメインモデル及び制約値の精度を改善し、それによって、より高く、より信頼性のあるパフォーマンス利得につながる、より正確なパフォーマンス解析及び目標最適化を可能にする。
[0025] 例示的な実施形態は、病理事例を、ワークフロー及び対応するタスクに関連付けるためのメカニズムを更に提供する。従来の手法は、単一の事例ステータスが用いられる(例えば、準備中、レビュー準備完了、アクション要、終了等)病理事例の単一ビューを利用する。対照的に、例示的な実施形態は、この病理事例の特徴付けから離れて、ワークフロー及びタスクとの関連付けを行う。以下で更に詳細に説明するように、病理事例のこの関連付けは、従来の手法によって用いられる単一の特徴付けと比べて改善した方式での最適化目標の達成をもたらす。
[0026] 図1は、例示的な実施形態によるシステム100を示す。システム100は、病理事例を完了することに関与する様々なコンポーネント間の通信に関する。特に、システム100は、患者が診断される試料を提供するときのシナリオに関し、試料は、デジタルスライドを作成するために用いられ、デジタルスライドは診断において用いられ、システム100は、デジタルスライドに少なくとも部分的に基づいて、病理事例が完了されるべき方式を決定する。システム100は、医師デバイス105と、通信ネットワーク110と、収集エンティティ115とを備える。システム100は、病理事例を完了する際に用いられる様々な情報源へのアクセスも有する。医師デバイス105及び/又は収集エンティティ115から受信される任意の情報を含む様々な情報源は、医療データリポジトリ120によって表される。システム100は、特に、選択された病理事例に対応するワークフローと関連付けられたタスクのアサインメントを介して病理事例を完了する方式を決定するワークフローサーバ125を更に備える。ワークフローサーバ125は、その機能を実行する際、ワークフローリポジトリ130並びにモデル及びルールリポジトリ135に含まれるデータを利用する。
[0027] 医師デバイス105は、医師に関連付けられた機能を実行するように構成された任意の電子デバイスを表す。特に、医師デバイス105は、病理学者によって利用される。例えば、医師デバイス105は、タブレット、ラップトップ等のポータブルデバイス、又はデスクトップ端末等の固定デバイスである。医師デバイス105は、特に、ワークフローサーバとのデータ交換に基づいて病理事例を追跡する、医療処置に関連する様々な動作を実行するために必要なハードウェア、ソフトウェア、及び/又はファームウェアを含む。医師デバイス105は、システム100の他のコンポーネントとの接続を更に確立するために、通信ネットワーク110との接続を確立するのに必要な接続ハードウェア、ソフトウェア、及びファームウェア(例えば、送受信機)も含む。医師デバイス105は更に、試料のデジタルスライドを受けるように構成され、試料を診断する際に病理学者にデジタルスライドを示すように構成される。
[0028] 医師デバイス105は、病理学者が医療処置又は診断に関連する様々な動作を実行することを可能にするように構成される。例えば、医師デバイス105は、ワークフローサーバ125から、実行されることになる次回の診断のスケジュールを受信する。このようにして、病理学者は、診断される対応するデジタルスライドを受信する。別の例において、医師デバイス105を用いて、診断結果又は診断に関連付けられた他の情報をワークフローサーバ125に提供することができる。
[0029] 医師デバイス105は、病理事例が完了する方式を定義するためにワークフローサーバ125に入力を提供する、管理者デバイス又は他のユーザデバイスも表すことに留意されたい。以下で更に詳細に説明するように、ワークフローサーバ125は、事例完了の方式を定義する際に手動入力された入力を含む様々な情報を利用する。例えば、ワークフローサーバ125の管理者又はユーザは病理学者でもある。別の例では、ユーザは、例示的な実施形態の様々な特徴をどのように組み込むかの知識を有するプランナー又はエンジニアである。
[0030] 通信ネットワーク110は、データを交換するようにシステム100の様々なコンポーネントを通信可能に接続するように構成される。通信ネットワーク110は、システム100のコンポーネントによって互いに通信するために用いられる任意の単一又は複数のネットワークを表す。例えば、医師デバイス105が病院で用いられる場合、通信ネットワーク110は、医師デバイス105が最初に接続するプライベートネットワーク(例えば、病院ネットワーク)を含む。プライベートネットワークは、インターネットに接続するためにインターネットサービスプロバイダのネットワークに接続する。その後、インターネットを介して、他の電子機器との接続が確立される。例えば、ワークフローサーバ125は、病院から離れているがインターネットに接続されている。したがって、医師デバイス105は、ワークフローサーバ125に通信可能に接続されている。通信ネットワーク110、及び通信ネットワーク110に含まれ得る全てのネットワークは、任意のタイプのネットワークであることに留意されたい。例えば、通信ネットワーク110は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、仮想LAN(VLAN)、WiFiネットワーク、ホットスポット、セルラネットワーク(例えば、3G、4G、ロングタームエボリューション(LTE)等)、クラウドネットワーク、これらのネットワークの有線形式、これらのネットワークの無線形式、これらのネットワークの有線/無線形式の組合せ等である。
[0031] 収集エンティティ115は、試料を収集し、試料のデジタルスライドを生成する任意の人物又は組織を表す。例えば、収集エンティティ115は、医師の診療室、実験室等から試料を受け取る。収集エンティティ115は、試料をデジタル化して適切なスライドにする。例えば、組織試料は、照明及び/又は染色された断面図になるように方向付けられるか又は成形される。ビューの画像が取得され、フォーマット設定されてデジタルスライドにされる。当業者は、収集エンティティ115が、物理的試料をデジタルスライドに変換する任意のメカニズムを用いることを理解する。収集エンティティ115は、通信ネットワーク110との接続を確立し、システム100の他のコンポーネントとの接続を更に確立するのに必要な接続ハードウェア、ソフトウェア及びファームウェア(例えば、送受信機)を含む。例えば、収集エンティティ115によって作成されるデジタルスライドは、医療データリポジトリ120に保存されるか、又はワークフローサーバ125に送信される。
[0032] 医療データリポジトリ120は、患者に関する情報についてクエリされる医療データのリポジトリである。第1の例において、医療データリポジトリ120は患者履歴を対象とし、患者履歴において、各患者は、患者の異なる手順、処置、通院等を追跡し、病理事例の異なるタスクに関連付けられた診断も追跡するのに用いられる電子医療記録(EMR)をする。第2の例では、医療データリポジトリ120は、試料、画像又はデジタルスライド、及び関連情報の保存を対象とする。特定の例では、病理学に関するとき、医療データリポジトリ120のこの態様は、実験室情報システムに実質的に類似している。画像取得に関するとき、医療データリポジトリ120のこの態様は、放射線情報システムに実質的に類似している。第3の例において、医療データリポジトリ120は、プロトコルの追跡及びロギング、並びに/又は病理事例等に伴う特定の手順を実行する際のステップを対象とする。特定の例において、病理学に関するとき、医療データリポジトリ120のこの態様は、画像管理システムに実質的に類似している。画像取得に関するとき、医療データリポジトリ120のこの態様は、画像保管通信システムに実質的に類似している。
[0033] ワークフローサーバ125は、例示的な実施形態による、病理事例をどのように完了するかの決定に関連付けられた機能を実行するシステム100のコンポーネントである。以下で更に説明するように、ワークフローサーバ125は、関連ワークフロー及びワークフロー内の決定されたタスクを用いて病理事例を完了するために全体手順が行われるメカニズムを含む。病理事例を完了するプロセスにおいて、ワークフローサーバ125は、病理事例を完了させ、ワークフローの特定のタスクにアサインされる病理学者を選択するのに用いられる最適化目標及びポリシを定義することに関連付けられた更なるメカニズムを含む。
[0034] ワークフローサーバ125は、その機能を実行する際に、ワークフローリポジトリ130と、モデル及びルールリポジトリ135とを利用する。ワークフローリポジトリ130は、病理事例を完了する際に用いられる複数のワークフローを保存する。ワークフローは、マッチする特性を有する病理事例が選択されたワークフローの使用を示すように、様々な特性(例えば、キーワード)に関連付けられる。ワークフローリポジトリ130は、各ワークフローに関連付けられた複数のタスクも保存する。ワークフローリポジトリ130内に保存されるワークフロー及びタスクは、例えば、医療データリポジトリ120に保存された履歴の病理事例に基づいて決定される。モデル及びルールリポジトリ135は、特定された最適化目標を満たすように選択された原子ポリシモデル及び複合ポリシモデルを含む複数のモデル(及び/又はルール)を保存する。モデル及びルールリポジトリ135に保存されるモデル(及び/又はルール)は、例えば、処理されている現在の病理事例に関連するものとして更新される、病理事例及び病理学者の履歴パフォーマンスに基づいて生成及び/又は決定される。
[0035] システムは、複数の医師デバイス105、複数の収集エンティティ115及び複数のワークフローサーバ125を含み得ることに留意されたい。すなわち、多くの異なる医師及び収集エンティティが、システム100を利用するか又はシステム100に関連付けられてもよい。また、異なる医師デバイス105及び収集エンティティ115にサービス提供する多くの異なるワークフローサーバ125も存在してもよい。例えば、ワークフローサーバ125は、地理的領域又は特定の医療分野にリンク付けるされる。また、医療データリポジトリ120の保存能力及び任意の関連機能がシステム100の単一のコンポーネントにおいて実施されることは例示にすぎないことも留意されたい。別の例示的な実施形態によれば、医療データリポジトリ120の各機能及び対応する保存能力は、個々のシステムコンポーネントに組み込まれる。
[0036] 上記で説明したように、ワークフローサーバ125は、関連ワークフローを決定し、ワークフロー内のタスクを特定し、完了のためにタスクの各々に病理学者をアサインすることによって、病理事例を完了する方式を決定する。図2は、例示的な実施形態による図1のワークフローサーバ125を示す。ワークフローサーバ125は、病理事例を完了する際の様々な機能を提供する。ワークフローサーバ125はネットワークコンポーネント(特に、サーバ)として記載されるが、ワークフローサーバ125は、ポータブルデバイス(例えば、タブレット、スマートフォン、ラップトップ等)、固定デバイス(例えば、デスクトップ端末)等の多岐にわたるハードウェアコンポーネントにおいて具現化されること、医師デバイス105及び/又は収集エンティティ115に組み込まれること、ウェブサイトサービスに組み込まれること、クラウドデバイスとして組み込まれること等が可能である。ワークフローサーバ125は、プロセッサ205、メモリ構成210、表示デバイス215、入出力(I/O)デバイス220、送受信機225、及び他のコンポーネント230(例えば、撮像装置(imager)、オーディオI/Oデバイス、バッテリ、データ収集デバイス、ワークフローサーバ125を他の電子機器に電気接続するためのポート等)を含んでもよい。
[0037] プロセッサ205は、ワークフローサーバ125の複数のアプリケーションを実行するように構成される。プロセッサは、アサインメントエンジン235、解析エンジン240、計画エンジン245及び選択エンジン250を含む複数のエンジンを利用する。アサインメントエンジン235は、展開エンジン255及び効率性エンジン260も含む。アサインメントエンジン235は、タスクをアサインされる病理学者を選択するための様々な入力を受信する。この機能を実行する際、展開エンジン255は、病理学者をタスクにアサインする際に検討されるポリシ及び最適化目標を決定する。効率性エンジン260は、ポリシ及び最適化目標を利用して、タスクにアサインされる病理学者を特定する。解析エンジン240は、デジタルスライドを受信し、解析して、予測事例特性等の追加の情報を生成する。計画エンジン245は、アサインメント規則(例えば、最適化目標、リソース利用可能性等)に従うことによって、タスク割当て要求に基づいてタスク割当てを生成する。選択エンジン250は、病理事例に関連付けられるワークフローを決定し、ワークフローに関連付けられるタスクを決定する。
[0038] 各々がプロセッサ205によって実行されるアプリケーション(例えば、プログラム)である上記のアプリケーション及びエンジンは例示にすぎないことに留意されたい。アプリケーションに関連付けられる機能は、1つ又は複数の多機能プログラムのコンポーネント、ワークフローサーバ125の別個の組み込まれたコンポーネントとしても表されてもよく、又はワークフローサーバ125に結合されたモジュラコンポーネント、例えば、ファームウェアを有する若しくは有しない集積回路であってもよい。
[0039] メモリ210は、ワークフローサーバ125によって実行される動作に関連するデータを保存するように構成されたハードウェアコンポーネントである。詳細には、メモリ210は、エンジン235~260に関連するデータを記憶する。表示デバイス215は、ユーザにデータを表示するように構成されたハードウェアコンポーネントであってもよく、一方、I/Oデバイス220は、ユーザが入力を行うことを可能にするハードウェアコンポーネントであってもよい。例えば、ワークフローサーバ125の管理者は、I/Oデバイス220を用いて行われた入力により、表示デバイス215上に表示されるユーザインタフェースを介してワークフローサーバ125の機能を維持及び更新する。表示デバイス215及びI/Oデバイス220は別々のコンポーネントであってもよく、又はタッチスクリーン等のように一体化されてもよいことに留意されたい。送受信機225は、通信ネットワーク110を介してデータを送信及び/又は受信するように構成されたハードウェアコンポーネントであってもよい。
[0040] 例示的な実施形態によれば、ワークフローサーバ125は、病理事例を完了する方式を決定するための様々な異なる動作を実行する。詳細には、ワークフローサーバ125は、エンジン235~260を介して、所望の病理事例ワークフローの形式的かつ実行可能なモデルを利用する。このワークフローにおいて、モデルは対応するドメインに関連付けられている。病理学者にタスクをアサインするのに必要であり、リソース計画コンポーネントによって用いられる全ての関連情報(例えば、タスク特性及び病理学者情報)、画像解析コンポーネント、及びタスクアサインメントに関する制約/ポリシ/最適化目標を取得することによって、例示的な実施形態は、所望の複雑度の協働モデルをサポートするように、病理学者をアサインすることによってどのようにタスクが分散されるかを決定することが可能になる。
[0041] 最初に、ワークフローサーバ125は、病理事例、又は病理事例に関連付けられた少なくとも1つのデジタルスライドに関する指示を受信する。これは、ワークフローサーバ125が、病理事例を完了する方式を決定する機能を実行するためのトリガとなる。例えば、ワークフローサーバ125は、収集エンティティ115からのデジタルスライドを保存する医療データリポジトリ120を監視する。新たなデジタルスライドが特定されると、ワークフローサーバ125はデジタルスライドを要求する。デジタルスライドは、特定の病理事例に関連付けられる(例えば、病理事例のマーカ又は識別情報がデジタルスライドと関連付けられる)。別の方式では、ワークフローサーバ125は、医療データリポジトリ120(例えば、EMR)内の他の情報を参照することによって、デジタルスライドを解析し、関連する病理事例を特定する。別の例では、ワークフローサーバ125は、医師デバイス105又は収集エンティティから、病理事例に関する指示を受信し、この病理事例は、医療データリポジトリ120に保存された関連デジタルスライドを有する場合がある。病理事例は既に特定されているため、任意の関連デジタルスライドが要求され受信される。
[0042] ワークフローサーバ125の機能及びワークフローサーバ125によって用いられる任意の情報全体を通じて、手動の入力によって提供される手動の入力又は情報が組み込まれてもよいことに留意されたい。例えば、患者の医師は、臨床的質問又は試料が取得された理由に関する手動入力を提供する。特に、この手動入力は、患者のEMRにより入力される。手動入力される情報は、試料の型、試料がいつ取得されたか、試料がどのように取得されたか(例えば、用いられた器具又は技法)、試料がどのように保存されたか、優先度レベル、期限等も示す。別の例では、ワークフローサーバ125による自動決定に依拠する代わりに、任意の自動決定に優先する手動入力が入力される。このようにして、対応する病理事例は、手動入力からの追加情報を含んでもよく、この追加情報がワークフローサーバによって用いられてもよい。
[0043] 手動入力を利用する際、ワークフローサーバ125は、入力を解釈するための様々な機能を用いて構成される。第1の例では、標準化されたフォームを用いて、又はフォーム入力に実質的に類似した別の入力方式で手動入力が提供される。このようにして、ワークフローサーバ125はフォームを受信し、特定の情報に対応して行われる選択を特定する。第2の例では、ワークフローサーバ125は、自然言語処理又はパース動作により、自由形式のテキストを受信するように構成され、この自由形式のテキストを解析して手動入力に含まれる情報が決定される。第3の例において、ワークフローサーバ125は、手動入力に含まれる情報を特定するために手動入力を(例えばキーワードに)ノーマライズするように構成される。
[0044] デジタルスライド(及びデジタルスライド又は特定された病理事例に関連付けられた任意の付随情報)を受信すると、解析エンジン240は、その機能を実行するように構成される。上述したように、解析エンジン240は、デジタルスライドを受け取り、解析して、追加の情報を生成する。詳細には、デジタルスライドを解析して、事例特性(例えば、器官/組織の種類、抽出方法、試料を診断のために病理学者へディスパッチすることが可能な時点、スライドの数、優先度レベル、期限等)及び/又は予測事例特性(例えば、予測診断時間、必要な追加試験、事例評価の難易度等)が決定される。解析エンジン240は、この追加情報を生成する際に、(例えば、医療データリポジトリ120内に保存された情報に基づいて、又はワークフローサーバ125によって決定される情報に基づいて、)任意の利用可能な情報を利用する。
[0045] 解析エンジン240は、ワークフローサーバ125によって用いられる他の特性を決定する際に利用可能な情報を用いる機能を有して更に構成される。第1の例では、解析エンジン240は病理学者特性を決定する。詳細には、医療データリポジトリ120に保存された履歴の病理事例情報を用いて、解析エンジン240は、病理事例にアサインできる利用可能な病理学者に関連付けられた特性を特定する。病理学者の特性は、専門分野、利用可能性、役割等を含む。第2の例では、解析エンジン240は、ワークフロー内のタスクのステータスに関する暗黙的又は明示的情報を決定する。以下で更に詳細に説明するように、ワークフローは、ワークフローが少なくとも1つのタスクを含む病理学タスクについて選択される。これらのタスクの各々が追跡され、タスクのステータス(例えば、タスクが開始した、タスクが完了した、タスクが保留中等)が決定される。
[0046] 利用可能な情報、追加の情報、及び任意の他の情報源を用いて、病理事例のために用いられるワークフローが決定される。上述したように、選択エンジン250は、病理事例に関連付けられるワークフローを決定する。同様に上述したように、選択エンジン250は、病理事例を完了する際に用いられる複数のワークフローを保存するワークフローリポジトリ130を利用する。病理事例は1つ又は複数のワークフローを利用することに留意されたい。説明の目的で、単一のワークフローを用いることに関する例示的な実施形態が説明される。しかしながら、単一のワークフローに関連付けられたプロセスの別の反復が、病理事例に関連付けられた任意の更なるワークフローのために用いられ得る。
[0047] ワークフローを選択する選択エンジン250の特定の実施において、解析エンジン240を用いて(例えば、デジタルスライドに基づいて)導出された、生成された事例特性は、ワークフローの選択及び実行を可能にする。例えば、デジタルスライド(及び示された臨床的質問)を用いて、HER2 IHCスライドの尤度診断が曖昧であることを検出する。この決定に基づいて、病理事例の予測診断時間を増大させるHER2 FISH試験を事前発注するワークフローが選択される。この改善された効率性は、病理学者がIHCスライド及びFISH試験の結果を読み取ることを望む場合等にアサインされる病理学者に拡張される。別の例では、デジタルスライドを用いて、(例えば、予測診断結果に基づいて)病理事例の可能性の高い難易度が検出される。(以下で詳細に説明する)病理学エンティティのポリシに依拠して、選択エンジン250は、教育ワークフロー等の非ルーチンワークフロー、専任の専門家(例えば、非局所的)が関与しないワークフロー、2人以上の病理学者が(診断一致を見直すために)同じタスクにアサインされる品質保証ワークフロー等をトリガする。品質保証ワークフローは、特に、病理事例型の診断が困難である可能性が高い場合に、後続の病理事例解析のために用いられることに留意されたい。
[0048] 当業者は、用いられるワークフローを決定する際に用いられる多くのメカニズムが存在することを理解するであろう。例示的な実施形態に関して、解析エンジン240によって提供される情報に基づいて、選択エンジン250は、ワークフローの決定を実行する。例えば、解析エンジン240は、病理事例に関連付けられたデジタルスライド及び情報を解析して、1つ若しくは複数のキーワードを決定するか、又は病理事例によって解消されることになる臨床的質問を決定する。ワークフローリポジトリ130に保存されたワークフローは、キーワードに関連付けられるか、又は1つ若しくは複数の臨床的質問にリンク付けされる。このようにして、選択エンジン250は、デジタルスライドに関連付けられることになるワークフローを決定する。
[0049] ワークフローリポジトリ130は、多岐にわたる異なる方式で作成及び/又は更新されるワークフローによりポピュレートされることに留意されたい。例えば、ワークフローサーバ125は、完了した、履歴の病理事例等の利用可能な情報に基づいて、1つ又は複数のワークフローを生成するように構成される。別の例では、ワークフローリポジトリ130は、管理者によって作成されたワークフローによりポピュレートされる。更なる例では、ワークフローサーバ125は、(例えば、特定の病理学エンティティ、領域等を反映するために)ワークフローリポジトリ130に保存されたワークフローを更新する際に現在利用可能な情報を利用するように構成される。
[0050] 選択エンジン250は、選択されたワークフローに関連付けられたタスクを更に決定する。例示的な実施形態によれば、デジタルスライドが対応する病理事例に関連付けられたワークフローを特定すると、選択エンジン250は、このワークフローについて完了することになるタスクを決定する。例えば、選択エンジン250は、利用可能な情報及び(例えば、解析エンジン240から出力された)任意の決定された情報を利用して、病理事例の特定の条件/判断基準を所与としてワークフローを用いるのに必要なタスクを介してワークフローが実行される方式を決定する。特定の例において、特定されたワークフローは、試料を診断する特定の方式のために用いられる。このワークフロー及び臨床的質問(提供又は決定される)に基づいて、選択エンジン250は、必要とされるタスクを決定する。このようにして、ワークフローに関連付けられたタスクが特定される。
[0051] ワークフローは、タスクの異なるセットに関連付けられてもよいことに留意されたい。すなわち、所与のワークフローは、必ずしも病理事例間でタスクの同じセットを用いるわけではない。例えば、第1の病理事例及び第2の病理事例は、共通器官型のデジタルスライドを含む。したがって、同じワークフローが選択される。しかしながら、第1の病理事例が第1の臨床的質問に関するのに対し、第2の病理事例は第2の異なる臨床的質問に関する。したがって、同じワークフローを用いるのにもかかわらず、ワークフローについて実行されるタスクは異なる場合がある。しかしながら、ワークフローは、そのワークフローが選択されるときに常に実行されるタスクの基本セットを含んでもよいことにも留意されたい。この実施において、ワークフローが選択される度に、このタスクの基本セットが常に実行される。
[0052] ワークフローリポジトリ130が、特にワークフローサーバ125が病理事例のために用いられる際に、ワークフローと関連付けられたタスクを保存することに更に留意されたい。第1の例では、ワークフローがタスクの基本セットを含むとき、これらのタスクはワークフローに関連付けられる。第2の例では、ワークフローが選択されたとき、ワークフローは、そのワークフローが選択される病理事例の条件/判断技術が保存されるように、そのワークフローに関連付けられたデータベースを有する。このようにして、病理事例が完了すると、病理事例のために用いられることが決定されたタスクもデータベースに保存される。このため、病理事例がデータベース内の病理事例と実質的に類似した条件/判断基準を有するとき、及び同じワークフローが選択されるとき、以前に選択されたタスクが再び選択される(又は少なくとも選択を推奨される)。
[0053] 選択エンジン250によってタスクが決定されると、各タスクは病理学者をアサインされる。タスクごとにいずれの病理学者を選択するかを決定する際、ワークフローサーバ125は、複数のエンジンを利用する。詳細には、ワークフローサーバ125は、アサインメントエンジン235、計画エンジン245、展開エンジン255、及び効率性エンジン260を利用する。上述したように、計画エンジン245は、アサインメントルール(例えば、最適化目標、リソース利用可能性等)に従うことによってタスク割当て要求に基づいてタスク割当てを生成する。アサインメントエンジン235は、タスクをアサインされる病理学者を選択するための様々な入力を受信する。展開エンジン255は、病理学者をタスクにアサインする際に検討されるポリシ及び最適化目標を決定する。効率性エンジン260は、ポリシ及び最適化目標を利用して、タスクにアサインされる病理学者を特定する。
[0054] ワークフローについて複数のタスクが決定されるとき、これらのタスクにアサインされる1人又は複数人の病理学者が存在してもよいことに留意されたい。例えば、ワークフローサーバ125によって、単一の病理学者がタスクを実行するようにアサインされる決定、2人の異なる病理学者が各々、タスクのそれぞれを実行するようにアサインされる決定、又は別の複数の異なる病理学者が各々、タスクのそれぞれを実行するようにアサインされ、各病理学者がタスクのうちの1つ又は複数を実行する決定が行われる。したがって、タスクの各々が異なる病理学者にアサインされるか、全てのタスクが単一の病理学者にアサインされるか、又はこれらの両極端の間の任意のアサインメント決定が用いられる。
[0055] 病理学者にタスクをアサインする際、展開エンジン255は、病理学エンティティの最適化目標を鑑みて病理学者がどのように選択されるかを定義するための様々な動作を実行する。詳細には、展開エンジン255は、病理学エンティティにおける関連ポリシを定義するルール及び目標を原子モデルに分割するように構成される。原子モデルは、各々が単一の原子目標に対応するルールのサブセットを表し、競合しないルール(すなわち、別のルールに競合しない)を用いて表される。展開エンジンは、必要に応じて複雑なモデル又は複合モデルに組み合わされるこれらの原子モデルを定義することによって、病理学エンティティのポリシを構築し、管理する。
[0056] 例示的な実施形態による原子モデルは、競合せず、重複しないルールを含む。原子モデルは、対応するドメインモデルも含み、ドメインモデルは、エンティティ、属性、関係等を記述する特定の問題を管理する制約に加えて、この特定の問題に関連するトピックの概念モデルに関係する。原子モデルは、最適化されることになる明確に定義された目標にリンク付けすることもできる。定義されると、原子モデルは、病理学エンティティのためのポリシを実施する複合モデルに組み合わされる。原子モデルについて、複合モデルに組み合わせることを試み、原子モデルが適用されるドメインモデルにおける変動を特定することを試みるときに、原子モデル間の競合及び重複を検出するのに役立つ統合アノテーションが維持される。当業者であれば理解するように、複合モデルは、各々について定義されたスコア/重みを有する競合するスコアリングルールを含む場合がある。例示的な実施形態は、これらのスコアを利用して、最適化目標を達成するために、原子モデルに基づいてトレードオフを決定する。
[0057] 以下で更に詳細に説明するように、原子モデル及び複合モデルは、初期モデルに基づいて展開エンジン255によって展開される。したがって、原子モデル及び複合モデルを保存するモデル及びルールリポジトリ135は、対応する最適化目標にリンク付けされる。このようにして、原子モデル及び複合モデルは効率的に再利用され、更なる病理学エンティティのコンテキストに適用するために拡張される。
[0058] 展開エンジン260は、実質的に自動方式で動作するが、展開エンジン260はまた、ユーザ(例えば、管理者)が、原子及び/又は複合モデルを選択することを可能にするユーザインタフェースを用いて構成される。この機能を用いる際に、展開エンジン260は、ルール(例えば、自動検出及び手動特定)間の競合、及びユーザが特定の原子モデル又は複合モデルを組み合わせようとするときに示されるアノテーションとして保存される競合も視覚化する。展開エンジン260は、所望の場合に検査及び変更される複合モデルを作成する際に、ルール及びスコアが原子モデルと共に用いられることを更に可能にする。展開エンジン260は、新たな原子モデルが(手動又は自動で)作成されるように更に構成される。展開エンジン260は、原子モデルの選択を通じてユーザが所望の最適化目標に対するスコア/ペナルティ及びルールの変更の影響を試験し、複合モデルを作成するのを支援するための評価/検証機能を含む。
[0059] 展開エンジン260は、複数の動作を実行して、病理学エンティティのためのポリシを生成する。例えば、展開エンジン260は、病理事例を完了するとき、病理学エンティティによって達成される最適化目標の指示を受信する。最適化目標に関連付けられた特性又はキーワードを決定するために、最適化目標が処理される(例えば、自然言語処理又は形式特定)。例えば、最適化目標は、効率性、スループット、公平性、それらの組合せ、リソース割当て、適時性等に関する。
[0060] 最適化目標に基づいて、展開エンジン260は、最適化目標に対応する原子モデルを決定する。上記で説明したように、原子モデルは、対応する目標とリンク付けされる。例えば、第1の原子モデルは、効率性目標にリンク付けされる。第2の原子モデルも効率性目標にリンク付けされる。第3の原子モデルは公平性目標にリンク付けされる。したがって、原子モデルが更なる処理のために決定及び収集される。
[0061] 上述したように、原子モデルは、特定された最適化目標を対象とする複合モデルに組み合わされる。原子モデルは、競合せず、重複しないルールを用いて展開されるが、複合モデルに組み合わされると、第1の原子モデルからのルールが第2の原子モデルからのルールと競合する場合がある。このため、展開エンジン260は、複合モデルの作成により生じる競合を解消する。例えば、第1の競合ルールに関連付けられた第1の原子モデルが、第2の競合ルールに関連付けられた第2の原子モデルに対し解析されるスコアリング動作が用いられる。詳細には、競合する原子モデルを含むか又は除外する複合モデルが決定されるトレードオフが特定される。その後、最適化目標が達成されることを可能にするより良好な複合モデルが特定される。このようにして、複合モデルは、適切な原子モデル及び複合モデルを組み込むことによって最適化目標がどのように達成されるかの表現を提供する。複合モデルを用いて対応するポリシが生成される。
[0062] 上述したように、展開エンジン260を用いて、手動入力のためのユーザインタフェースを可能にすることもできる。このため、プロセスに沿って任意の段階で、ユーザは、展開エンジン260による任意の自動決定に優先する入力を提供してもよい。例えば、最適化目標はユーザによって提供される。最適化目標は、任意のフォーマット(例えば、自由形式のテキスト、標準化形式等)で提供される。別の例において、原子モデル又は複合モデルは、モデルの所定のリストから選択される。手動選択が入力されるとき、展開エンジン260は、選択されたモデルを、最適化目標に対し最大限まで組み込むように構成される。しかしながら、選択されたモデルが、解消されていない競合を含むように最終的に決定される場合、又は最適化目標を満たすことができない場合、展開エンジン260はユーザにアラートを返す。
[0063] 展開エンジン260は、利用可能な原子モデル及び複合モデルに基づいて、最適化目標が達成可能であるか又は不可能であるかを更に判断する。例えば、特に、展開エンジン260の早期の使用段階中、利用可能な原子モデル又は複合モデルの十分なリストがない場合がある。したがって、特定の最適化目標を達成するために、最適化目標を達成するポリシのために複合モデルに含まれる新たな原子モデルが作成される。
[0064] 展開エンジン260は、上記の動作を実質的に自動方式で行うが、ユーザの合意に基づいてポリシが作成されると、展開エンジン260は、原子モデル及び複合モデルに基づいて、ユーザに示される推奨としてポリシを生成する。このため、ユーザインタフェースを介して、ユーザは、展開エンジン260によって提供される推奨に基づいて、モデルのブラウズ、編集、組合せ等を行う。
[0065] 展開エンジン260は、ポリシの結果が検証されるフィードバック動作を用いて更に構成される。すなわち、展開エンジン260は、原子モデル及び複合モデルに基づいて用いられるポリシが、対応する最適化目標を最終的に達成したか否かを判断する。例えば、第1のポリシは、第1のポリシが選択されている時間の第1のパーセンテージにわたってその最適化目標を達成することに成功した。別の例では、第2のポリシは、第2のポリシが選択されている時間の第2のパーセンテージにわたって最適化目標を達成することに失敗した。これらの成功及び失敗に基づいて、展開エンジン260は、最適化目標を対象とする特定のポリシについて原子モデル及び複合モデルがどのように選択されるかをより正確に決定する。手動検出又は自動検出を通じて、モデル内の競合にアノテーションを付けるフィードバック動作も用いられる。展開エンジン260は、後に最適化目標を達成する際に用いるために、ポリシに対する変更の効果の基準を定める(benchmark)。
[0066] 上述したように、展開エンジン260は、最適化目標を達成するようにポリシを作成する際に用いられる原子モデル及び複合モデルを展開する機能を実行する。展開エンジン260の使用は、ポリシを解析し、特定の最適化目標にリンク付けされた原子モデルを構築することに焦点を当てる。初期段階における展開エンジン260の初期使用は、対応するアノテーションと共にモデル及びルールリポジトリ135を構築し、これは後の使用において再利用される。当業者であれば理解するように、ポリシをモデル化する労力は、展開エンジン260のより早期の使用においてより大きい。原子モデルの強力なライブラリが構築されると、展開エンジン260は、後続の実施のためにリポジトリ135を使用し、モデラの作業をより効率的かつ高速にする(例えば、利用可能な構築ブロックからポリシ全体を構成する、制約及びそれらのトレードオフを変更することによって競合に対処する、利用可能なモデルが病理学エンティティの全ての設定された目標及びポリシをサポートしないときにのみ新たなモデルを定義する等)。
[0067] 展開エンジン260の上記の実施に基づいて、ワークフローサーバ125は多岐にわたる特徴を提供する。例えば、ワークフローサーバ125は、病理学エンティティにおける様々なワークフローにおけるアサインメントポリシのための効率的なモデル化及びタスク実施を可能にするように構成される。別の例では、ワークフローサーバ125は、最適化目標を達成する際に、ポリシを構築、評価及び試験/検証する直感的な方式を提供するように構成される。更なる例において、ワークフローサーバ125は、最適化目標を達成する際に、テキストポリシをコンピュータ化されたモデルに変換するプロセスをサポートするように構成される。
[0068] ワークフローサーバ125は、病理学者にタスクをアサインする際に、効率性エンジン260も利用する。ここでもまた、効率性エンジン260は、(展開エンジン255で定義された)ポリシ及び最適化目標を利用して、タスクにアサインされる病理学者を特定する。効率性エンジン260は、所望の最適化目標を達成するために、所与のタスクにアサインされる利用可能な病理学者のうちの1人を選択するための様々な動作を実行する。効率性エンジン260は、タスクのための病理学者の選択が、現在の条件に基づくか、又は選択がタスクアサインメントのスケジュールにどのように影響を及ぼすかに基づくように、独立した手法又は全体論的手法も利用してもよい。
[0069] デジタル病理学を用いて、診断統計が決定される。したがって、ワークフローサーバ125は、事例型に基づいて病理学者ごとの実際の診断時間に効率的にアクセスしこれを解析し、病理学者のパフォーマンスの変化及び専門分野を特定する。病理事例の完了に対する従来の手法と対照的に、履歴の完了した病理事例のログの解析により、例示的な実施形態によれば、ワークフローサーバ125が、平均全体パフォーマンス属性を用いることから離れ、代わりに、動的に決定される、経時的に変化する変数を用いることが可能になる。これらの変数は、履歴のログのライブ解析に基づいて値を割り振られる。(作業負荷に関する)公平性を病理学者間で保持する必要があるとき、平均を用いてリソース利用を推定するが、収集されたアクティブティデータから導出されたより正確な診断時間値により、最適化目標(例えば、スループット、ターンアラウンド等)の達成が改善される。したがって、例示的な実施形態によるワークフローサーバ125は、所望の全体パフォーマンスをもたらす可能性を有するスケジュールを探す間、公平性を保つ(例えば、効率性の低い病理学者に、より少ない作業を与えないようにする)2つの手法を組み合わせる。
[0070] 以下に詳細に説明するように、ワークフロー(例えば、病理学者によって完了されるワークフローの一部)から収集したトレースを用いて、効率性エンジン260は、事例型に基づいて各病理学者の予測パフォーマンスを記述するタイミング特性を展開させ、これらの値の経時的な変化を考慮に入れるように構成される。タイミング特性は、2つのタイプの設定において用いられる。統計を用いて、所与の病理事例に病理学者をアサインする。例えば、アサインメントは、複数の病理学者を含む所与の病理学エンティティ、及び或る期間内に診断を要する病理学エンティティにおける現在の病理事例に対するものである。病理学者ごとのパフォーマンスを経時的に追跡するのに統計も用いられる。
[0071] 上述した機能を提供する際、効率性エンジン260は複数の動作を実行するように構成される。第1の動作において、効率性エンジン260は、ソルバ機能を含む。ソルバ機能は、ドメインモデル及びスコアリングルール、並びに特定の病理学エンティティの動作方式を、最適化目標を達成する際の入力パラメータとして用いるように選択された主要アクティビティを用いて記述する、アクティビティ推定テーブル及びワークフローモデルを利用する。したがって、ソルバ機能は、病理学者ごとに事例型ごとの診断時間を推定する。ソルバ機能は、他のアクティビティもカバーするように拡張されてもよいことに留意されたい。また、ドメインモデルは、アクティビティ推定テーブルによって埋められるパラメータ及び/又は変数を含んでもよいことに留意されたい。
[0072] 第2の動作において、効率性エンジン260は、ログ処理機能を含む。ログ処理機能は、(例えば、医療データリポジトリ120内の)画像管理システムから、選択されたアクティビティクラスにマッピングされるアクティビティのログを索出する。第3の動作において、効率性エンジン260は、解析機能を含む。解析機能は、ログを処理し、病理学者及び事例型ごとのアクティビティパラメータの現在の値を計算する。解析機能は、更なる処理のために(例えば、ルール/制約定義を更新するために)出力をフィードする。解析機能は、推定値の変更結果を処理し、達成される最適化目標に対する任意の影響を処理するフィードバック機能を含むことに留意されたい。第4の動作において、効率性エンジン260は最適化機能を含む。最適化機能は、ドメインモデル及びルール定義を考慮に入れて、所望の最適化目標(例えば、スループット又はターンアラウンド)を最適化する病理事例のアサインメントのための解を提案する。
[0073] 病理事例のためのワークフローのタスクをアサインされる病理学者の選択を決定するために、効率性エンジン260は、以前の病理事例及び関連タスクの履歴ログを受信し、見直す。詳細には、病理学者が病理事例/タスクを対応する事例特徴と共に読み取るために、ワークフローのトレースが収集される。特徴(例えば、臨床的質問、器官の種類、病理事例に関連付けられた病理学スライドの数及び型、疾病等)を用いて事例型を構築する。このようにして、病理学者、事例型、及び対応するタスクをリンク付けして、病理学者が類似の事例型について類似のタスクを実行する際に要する可能性が高い時間の推定値を決定する。詳細には、上記の動作を用いて、病理学者ごとに各事例型について予測読取り時間が計算される。更に、上記の動作を用いて、予測因子として用いられる他の関連アクティビティのためのタイミング推定が計算される。
[0074] 上述したように、タスクのスケジュールが病理学者による診断を要する時間窓が存在する場合がある。これらの既知のスケジューリングされたタスクに基づいて、効率性エンジン260は、タスクごとに病理学者の各々が要する予測時間を利用する。次に、満たされることになる任意の最適化目標、及び(例えば、展開エンジン255を介して)定義される任意のポリシに基づいて、効率性エンジン260は、タスクの各々について病理学者を選択する。このようにして、効率性エンジン260は、これらの推定を用いてタスクのためのスケジュールを計算し、このスケジュールにおいて、主要パフォーマンスインジケータのセットに基づいて任意の定義された最適化目標又はポリシを達成するとみなされるタスクが実行される。病理事例ごとに、効率性エンジン260は、病理事例/タスクがいずれの病理学者にアサインされるかを判定するのに用いられる、各適格な病理学者についての推定労力の平均値(例えば、時間単位)を与える。
[0075] 上記の機能は、履歴の病理事例、及び病理学者が特定の事例型又はタスクの診断において必要とする現在の予測時間に基づくことに留意されたい。しかしながら、十分なデータソースが利用可能でない最初の反復について、効率性エンジン260は、病理事例ごとの予測労力に割り振られる展開値を用いる。展開値は、平均、任意の利用可能データ、又はそれらの組合せに基づく。このため、システムが実行中であり、効率性エンジン260が用いられている間、トレース(例えば、履歴の病理事例において完了したタスク)が収集される際に展開値又は任意の更新値が更新される(又は更に更新される)。
[0076] 上述したように、効率性エンジン260は、フィードバック機能を含むことができる。したがって、値を更新するとき、病理事例及びタスクごとの実際のタイミング/労力が、病理学者にタスクをアサインする際に用いられる決定された推定値と比較される。それによって、アサインされた病理学者及び事例型のための推定(例えば、予測)値が更新される。標準偏差も計算され、推定診断時間に対する変更が必要とされる(例えば、外れ値が検出され、無視される)か否かを判断するのに用いられる。パラメータ/変数は、定義されたポリシに従って履歴ログの解析に基づいてドメインモデルにおいて更新される(例えば、事例型の平均診断持続時間を、その型の200個の新たな事例ごとに更新し、外れ値を除外する)。更新動作は、任意のタイミング判断基準に基づいて実行されることに留意されたい。例えば、時間又は病理事例/タスクの数に基づいた所定の間隔が用いられる。別の例では、動的間隔が用いられる。更なる例では、各病理事例/タスクが完了する際に一定の更新が用いられる。
[0077] 効率性エンジン260の上記の実施に基づいて、ワークフローサーバ125は、多岐にわたる特徴を提供する。例えば、ワークフローサーバ125は、病理事例の特定のタスクをアサインされることになる病理学者を示すアサインメント決定を行うように構成される。アサインメント決定は、事例型を所与として各病理学者の予測パフォーマンスに関する知識を含めることによって最適化される。これは、最適化機能におけるターンアラウンド及びスループットの正確な予測のために用いられる。別の例では、ワークフローサーバ125は、病理学者のパフォーマンスを追跡し、それによって、ピアとの比較を可能にし、異なる期間における病理学者のパフォーマンスを比較するように構成される。更なる例において、ワークフローサーバ125は、後続の繰り返しのために病理学者のパフォーマンスの変化を検出し、考慮に入れるように構成される。
[0078] 病理学者にタスクがアサインされると、ワークフローサーバ125は、アサインメントをディスパッチする。例示的な実施形態は、各病理学者が、病理事例のためのワークフローのタスクを完了する際にそれぞれの任務を実行するための、任意のディスパッチメカニズムを利用する。例えば、病理事例が、(例えば、病院の病理学部門、実験室等において)病理学エンティティによって実行される場合、ワークフローサーバ125は、アサインメントを病理学エンティティに提供する。病理学エンティティは、(例えば、アサインメントにおける任意のスケジューリング要件に基づいて)アサインメントをスケジューリングする。
[0079] ワークフローのタスクの各々が完了すると、例示的な実施形態はまた、フィードバック動作を有して構成され、このフィードバック動作において、結果又は後続のアクションもワークフローサーバ125によって受信される。フィードバックデータに基づいて、ワークフローサーバ125は、医療データリポジトリ120内の任意の情報を更新し、ワークフローリポジトリ130に保存されたワークフロー/タスクを更新し、かつ/又はモデル及びルールリポジトリ135に保存されたモデル/ルールを更新する。フィードバック動作を用いる特定の方式において、病理学者特性が更新され、ここで、病理学者のプロフィールを反映するように直近の経験が組み込まれる。このため、処理される任意の更なる病理事例は、各病理学者の同時期のプロフィールに依拠する。
[0080] 図3は、例示的な実施形態による、病理事例を自動的に完了するための全体的な方法300を示す。詳細には、方法300は、病理事例のためのワークフローが、病理学者にアサインされるタスクに分割される方式を決定することに関する。方法300は、ワークフローサーバ125が、デジタル病理学手順においてデジタル病理学スライドを用いることにより得られる追加の情報をどのように生成及び/又は利用するかにも関する。方法300は、ワークフローサーバ125及びエンジン235~260の観点から説明される。方法300は、図1のシステム100及び図2のワークフローサーバ125に関しても説明される。
[0081] 305において、ワークフローサーバ125は、病理事例に関連付けられたデジタルスライドを受信する。上記で説明したように、デジタルスライドは、収集エンティティ115によって取得される患者の試料のデジタルファイルである。例えば、試料は、組織又は体液である。収集エンティティ115(又は別の組織)は、試料をデジタル化してデジタルスライドにし、このデジタルスライドは、医療データリポジトリ120に保存される。ワークフローサーバ125は、収集エンティティ115(又はデジタルスライドを作成した組織)から直接的な方式でデジタルスライドを提供されるか、又は医療データリポジトリ120にデジタルスライドを要求する。ワークフローサーバ125は、デジタルスライドが関連する病理事例の指示を(上述したような)多岐にわたる方式で受信した場合があることに留意されたい。したがって、ワークフローサーバ125は、特定された病理事例に基づいてデジタルスライドを受信するように促された場合がある。
[0082] 310において、ワークフローサーバ125は、デジタルスライドが関連する病理事例を特定する。病理事例の特定が、デジタルスライドを索出する際に用いられた場合、ワークフローサーバ125は病理事例を既に特定している場合がある。しかしながら、ワークフローサーバ125が特定なしでデジタルスライドを受信した場合、ワークフローサーバ125がデジタルスライドを(例えば、解析エンジン240を介して)解析して、デジタルスライドに関連付けられた様々な特性を決定する。例えば、試料の型が特定される。特性に基づいて、ワークフローサーバ125は、医療データリポジトリ120(例えば、EMR)に保存された情報を参照して病理事例を特定する。315において、特定された病理事例に基づいて、ワークフローサーバ125は、関連情報を受信する。例えば、病理事例に関連付けられた臨床的質問が関連情報に含まれる。
[0083] 320において、ワークフローサーバ125は、解析エンジン240を介してデジタルスライドを解析する。上述したように、ワークフローサーバ125は、病理事例を完了する際にどのようにワークフローを用いるかを決定する際に用いられる、デジタルスライドからの追加の情報を決定するように構成される。詳細には、デジタルスライドが解析され、事例特性(例えば、器官/組織の種類、抽出方法、試料を診断のために病理学者へディスパッチすることが可能な時点、スライドの数等)及び/又は予測事例特性(例えば、予測診断時間、必要な追加試験、事例評価の難易度等)が決定される。
[0084] 325において、デジタルスライドに関連付けられた受信情報、及びデジタルスライドから導出された追加の情報に基づいて、ワークフローサーバ125は、病理事例を完了する際に用いられるワークフローを決定する。例えば、ワークフローサーバ125は、病理事例を完了するのに用いられる複数のワークフローを保存するワークフローリポジトリ130にアクセスする。330において、ワークフローサーバ125は、決定されたワークフローに関連付けられた1つ又は複数のタスクを決定する。上述したように、タスクは、ワークフローと密にリンク付けされる。すなわち、対応するワークフローが選択されるとき、選択されたタスクが常に用いられる。例えば、デジタルスライドの受信及び/又は追加情報に基づいて対応するワークフローについて動的に選択される他のタスクも存在する。
[0085] 335~340において、ワークフローサーバ125は、計画エンジン245及び選択エンジン250を介して、タスクを選択し、選択されたタスクにアサインされる病理学者を決定する。病理学者の選択については、展開エンジン255及び効率性エンジン260に関して更に詳細に説明される。345において、ワークフローサーバ125は、病理学者がアサインされることを必要とする任意の更なるタスクが存在するか否かを判断する。ワークフローに別のタスクが存在する場合、ワークフローサーバ125は335に戻る。しかしながら、全てのタスクが病理学者をアサインされたとき、350において、ワークフローサーバ125は、病理学エンティティが完了することになるタスクの次回の窓のためのスケジュール等においてアサインメントをディスパッチする。
[0086] 図4は、例示的な実施形態による、病理学者を病理事例にアサインするためのポリシを生成するための方法400を示す。詳細には、方法400は、病理学エンティティにおける最適化目標を達成するためのポリシの基礎を形成する複合モデルを作成する際に、原子モデルを生成及び利用することに関する。方法400は、ワークフローサーバ125及び展開エンジン255の観点から説明される。方法400も、図1のシステム100及び図2のワークフローサーバ125に関して説明される。
[0087] 405において、ワークフローサーバ125は、病理学エンティティのための最適化目標を受信する。例えば、最適化目標は、スループット、ターンアラウンド、公平性等に関する。最適化目標は、病理学エンティティの管理者等のユーザから手動で受信されるか、又は病理学エンティティが動作するように構成される所定の判断基準に基づいて自動的に決定される。最適化目標に基づいて、410において、ワークフローサーバ125は、最適化目標に対応する原子モデルを決定し、ここで、原子モデルは、競合せず、重複しないルールを用いて定義される。上述したように、ワークフローサーバ125は、原子モデルを保存するモデル及びルールリポジトリ135にアクセスし、原子モデルの各々は1つ又は複数の最適化目標に関連付けられている。このため、最適化目標に対応する原子モデルが決定される。モデル及びルールリポジトリ135が、展開エンジン255の少なくとも1つの前回の使用からの原子モデルを用いてポピュレートされている方法400が本明細書に記載されていることに留意されたい。
[0088] 415において、ワークフローサーバ125は、最適化目標に対応する原子モデルを1つ又は複数の複合モデルに組み合わせる。上述したように、原子モデルは、独立して及び組み合わせて成立するルールを含むが、複合モデルは、原子モデルの組合せを通じて、結果として原子モデルに含まれるルール間の競合を生じる場合がある。このため、420において、ワークフローサーバ125は競合を解消する。例えば、原子モデル間で、最適化目標が達成される方式を改善するためのトレードオフが決定される。
[0089] 425において、ワークフローサーバ125は、手動入力が受信されたか否かを判断する。最初に、手動入力が方法400に沿った任意の段階で受信されることに留意されたい。例えば、手動入力は最適化目標である。別の例では、手動入力は、手動で選択される原子モデルである。手動入力は、自動決定された入力に優先する。このため、手動入力が受信される場合、430において、ワークフローサーバ125は、手動入力を実施して410に戻り、410において、原子モデルが決定され、415において、複合モデルが作成される。
[0090] 手動入力が受信されない場合、435において、ワークフローサーバ125は、複合モデルが任意の競合を解消した結果として、最適化目標のうちのいずれかが達成されないことになるか否かを判断する。モデル及びルールリポジトリ135が適切なモデルを含めるように十分構築されていないときに特に、複合モデルへの組合せは、受信した最適化目標を達成できない場合がある。複合モデルを用いて少なくとも1つの最適化目標が達成可能でない場合、440において、ワークフローサーバ125は、逃した目標のための新たな原子モデルを定義し、これを複合モデルに組み込む。その後、ワークフローサーバ125は415に戻り、415において、新たな原子モデルを含む複合モデルが、420において競合を解消するように評価される。全ての最適化目標が原子モデルを含む複合モデルを用いて達成可能であるとき、445において、最適化目標に対応するポリシが生成される。
[0091] 図5は、例示的な実施形態による、病理学者を病理事例にアサインするための方法500を示す。特に、方法500は、ポリシ及び最適化目標を、病理学者に関連付けられた履歴の病理事例/タスク情報と共に利用することに関する。方法500は、ワークフローサーバ125及び効率性エンジン260の観点から説明される。方法500は図1のシステム100及び図2のワークフローサーバ125に関しても説明される。
[0092] 505において、ワークフローサーバ125は、完了した前回の病理事例/タスクのログを受信する。ログは、様々なタイプの情報を含む。このため、510において、ワークフローサーバ125は、ログにおいて事例型及び実行されたタスクを決定する。事例型は、様々な特性(例えば、器官の種類)に基づく。ログは、完了したタスクをアサインされた対応する病理学者、及び病理学者がタスクを完了させるのに用いた時間量に関するタイミング情報も含む。したがって、515において、ワークフローサーバ125は、特定の病理学者によって特定の事例型又はタスクを完了させる予測読取り時間を決定する。病理学者/事例型の予測時間を維持する際、ワークフローサーバ125は、次回のタスクを完了するスケジュールを決定する。
[0093]520において、ワークフローサーバ125は、次回のタスクのスケジュールを受信する。上述したように、ワークフローサーバ125は、時間窓について病理学者にアサインされるタスクを決定する。例えば、ワークフローサーバ125は、未来の時点の所与の日付(例えば、現在の日付から一週間後)に実行されることになるタスクを決定する。タスクは、1つ又は複数の病理事例の1つ又は複数のワークフローに関連付けられる。タスクのための時間窓の使用は例示にすぎないことに留意されたい。別の例示的な実施形態では、ワークフローサーバ125は、特定の病理事例のためのワークフローに基づいて病理学者にアサインされるタスクを決定する。このため、病理事例に関連付けられるタスクには、病理学者がアサインされる。
[0094] 525において、ワークフローサーバ125は、タスクのスケジュールのための最適化目標を受信する。上述したように、最適化目標は、関連付けられたポリシを有し、最適化目標を達成する際の原子及び/又は複合モデルを含む。このため、505~515の実行からの推定、及び最適化目標/ポリシにも基づいて、530において、ワークフローサーバ125は、スケジュールが最大の成功確率で最適化目標を達成するように、病理学者を各タスクにアサインする。
[0095] 例示的な実施形態は、ワークフローが完了する方式を最適化することによって、病理事例を完了するデバイス、システム及び方法を提供する。デジタル病理学手順のデジタルスライドから集めた追加情報を利用することによって、病理事例のワークフローにおいて完了するタスクが決定される。このようにして、例示的な実施形態は、1つ又は複数の病理学者を効率的な方式でタスクにアサインする。タスクが完了することになる時間窓から見たとき、例示的な実施形態はまた、1人又は複数人の病理学者を、効率的な方式で窓内のタスクにアサインする。このため、病理学者の病理学エンティティの最適化目標が達成される。
[0096] 当業者は、上記の例示的実施形態が、任意の適切なソフトウェア若しくはハードウェア構成、又はこれらの組合せにおいて実装されることを理解するであろう。例示的な実施形態を実装するためのハードウェアプラットフォームの例は、例えば、互換性のあるオペレーティングシステムを備えたIntel x86ベースのプラットフォーム、Windowsプラットフォーム、Macプラットフォーム及びMAC OS、iOS、Android等のオペレーティングシステムを有するモバイルデバイスを含む。更なる例では、上記方法の例示的な実施形態は、プロセッサ又はマイクロプロセッサ上で実行され得るコンピュータ可読記憶媒体に記憶された複数行のコードを含むコンピュータプログラム製品として具現化される。ストレージ媒体は、例えば、任意のストレージオペレーションを用いる上述したオペレーティングシステムと互換性のある、又はそのようなオペレーティングシステムと共に使用するためにフォーマット設定されたローカル又はリモートデータリポジトリである。
[0097] 当業者であれば、本開示の趣旨又は範囲から逸脱することなく、本開示において様々な変更を加えることができることは明らかであろう。したがって、添付の特許請求の範囲及び均等物の範囲内にある限り、本開示を改変及び変形した形態が本開示に包含されることが意図される。