(57)【要約】  縦断的なケアエピソードをグラフィックで管理して資料化するためのシステムおよび方法が開示される。一例として、患者のケアの縦断的なエピソードを管理するためのシステムは、患者についてのコンテキストデータを与えるようプロセッサーによって実行可能な患者データアグリゲーターを含んでもよく、コンテキストデータの少なくとも一部は、ケアの縦断的なエピソードにおける複数のフェーズに関連する患者データを含む。ツールマネージャーは、関連のグラフィカルユーザーインターフェース（ＧＵＩ）とのユーザーインタラクションを、対応の別々のコンセプトに翻訳することができる。対応の別々のコンセプトは、患者についての縦断的なエピソードデータの一部としてメモリーに格納可能であり、縦断的なエピソードデータは、コンテキストデータに基づいて、かつ、ケアの縦断的なエピソードの資料化と管理を容易にするためのＧＵＩとのユーザーインタラクションに応答して生成される。
2014533860.tif 000002
【特許請求の範囲】
【請求項１】
患者のケアの縦断的なエピソードを管理するためのシステムであって、
前記患者についてのコンテキストデータを与えるようプロセッサーによって実行可能な患者データアグリゲーターと、
関連のグラフィカルユーザーインターフェース（ＧＵＩ）とのユーザーインタラクションを、対応の別々のコンセプトに翻訳するよう前記プロセッサーによって実行可能なツールマネージャーと、を備え、
前記コンテキストデータの少なくとも一部は、前記ケアの縦断的なエピソードにおける複数のフェーズに関連する患者データを含み、
前記対応の別々のコンセプトは、前記患者についての縦断的なエピソードデータの一部としてメモリーに格納され、前記縦断的なエピソードデータは、前記コンテキストデータに基づいて、かつ、前記ケアの縦断的なエピソードの資料化と管理を容易にするための前記ＧＵＩとの前記ユーザーインタラクションに応答して生成される、システム。
【請求項２】
前記ツールマネージャーは、前記ケアの縦断的なエピソードにおける前記複数のフェーズそれぞれの全体で、前記縦断的なエピソードデータを表す秩序立った構成で、前記対応の別々のコンセプトを一緒にプログラム的にリンクするよう前記プロセッサーによって実行可能なコンセプトエンジンをさらに含む、請求項１に記載のシステム。
【請求項３】
前記縦断的なエピソードデータは、複数のデータエレメントを含み、データエレメントは、前記ケアの縦断的なエピソードにおける前記複数のフェーズのそれぞれのフェーズについて一緒にリンクされる、請求項１に記載のシステム。
【請求項４】
前記複数のデータエレメントは、前記患者に対する一組の懸案となっている問題のリストデータエレメントを含む、請求項３に記載のシステム。
【請求項５】
前記複数のデータエレメントは、あらかじめ定められたコード化データエレメントをさらに含み、前記コード化データエレメントは各々、規定のコード標準に従って、前記患者に対する前記ケアの縦断的なエピソードのそれぞれの態様を提示するようプログラムされる、請求項３に記載のシステム。
【請求項６】
前記ケアの縦断的なエピソードの前記複数のフェーズのうち連続したフェーズにおける対応のコード化データエレメントの比較に基づいて、前記連続したフェーズ間の逸脱を検出し、前記縦断的なエピソードデータの一貫性を強化するよう前記プロセッサーによって実行可能な逸脱検出部をさらに備える、請求項５に記載のシステム。
【請求項７】
前記逸脱検出部は、前記連続したフェーズの、ある対応のコード化データエレメントにおけるあらかじめ定められた最上位桁のサブセットを比較する、請求項６に記載のシステム。
【請求項８】
前記ＧＵＩを介してリクエストを発行するよう前記プロセッサーによって実行可能なリクエスト生成部をさらに備え、前記リクエスト生成部は、前記逸脱検出部が、前記連続したフェーズの前記縦断的なエピソードデータ間が不一致であると判断したことに応答して前記リクエストを発行するよう促され、前記リクエストに対する応答は、前記連続したフェーズの前記縦断的なエピソードデータ間の前記不一致をなくすために前記縦断的なエピソードデータとして前記連続したフェーズのうちの後のフェーズで格納される、請求項６に記載のシステム。
【請求項９】
カルテシステムにアクセスするためのカルテインターフェースをさらに備え、前記データアグリゲーターは、前記縦断的なエピソードデータを生成するのに利用される前記コード化データエレメントの少なくとも一部を前記カルテシステムから得るのに、前記カルテインターフェースを利用し、前記ツールマネージャーは、前記ケアの縦断的なエピソードにおける前記複数のフェーズ各々の態様を資料化するために、前記縦断的なエピソードデータから前記カルテシステムに選択されたデータエレメントを供給するのに前記カルテインターフェースを利用する、請求項５に記載のシステム。
【請求項１０】
前記複数のフェーズのうち少なくとも１つのフェーズについて予測出力をコンピューター計算するよう前記プロセッサーによって実行可能な予測エンジンをさらに備え、前記予測出力は、選択された少なくとも１つの予測モデルおよびそれぞれのフェーズに対する前記縦断的なエピソードデータに基づいて、少なくとも１つの各フェーズについてコンピューター計算され、前記予測出力は、前記予測出力ならびに前記患者の前記ケアの縦断的なエピソードにおける当該予測出力との関連のユーザーインタラクションを資料化するための関連のカルテシステムに供給される、請求項１に記載のシステム。
【請求項１１】
前記データエレメントは、あらかじめ定められたコード化データエレメントを含み、前記コード化データエレメントは各々、規定のコード標準に従って、前記患者に対する前記ケアの縦断的なエピソードのそれぞれの態様を提示するようプログラムされ、
前記予測エンジンは、
前記少なくとも１つのフェーズに対して格納された前記コード化データエレメントに基づいて、前記少なくとも１つの予測モデルを選択して構成するためのモデル選択部と、
前記予測出力を評価して、前記予測出力の分析を容易にするための精度レベルを割り当てるための評価部と、をさらに含む、請求項１０に記載のシステム。
【請求項１２】
前記予測出力の前記分析およびその関連の信頼値に基づいて、メモリーに格納される推奨行為データを生成するよう前記プロセッサーによって実行可能なリスクアナライザーをさらに備え、前記推奨行為データのインタラクティブな表現が、前記ＧＵＩを介してユーザーに対して表示される、請求項１１に記載のシステム。
【請求項１３】
カルテシステムにアクセスするためのカルテインターフェースをさらに備え、前記データアグリゲーターは、前記コンテキストデータを生成するのに利用される前記コード化データエレメントの少なくとも一部を前記カルテシステムから得るのに、前記カルテインターフェースを利用し、前記ツールマネージャーは、前記ケアの縦断的なエピソードに対する前記推奨行為データまたはその前記インタラクティブな表現とのインタラクションのうちの少なくとも１つを資料化するために、前記縦断的なエピソードデータから前記カルテシステムに選択されたデータエレメントを供給するのに前記カルテインターフェースを利用する、請求項１２に記載のシステム。
【請求項１４】
前記少なくとも１つのフェーズは、前記ケアの縦断的なエピソードにおける前記複数のフェーズの施術前フェーズを含み、前記ツールマネージャーは、前記施術前フェーズに対する前記縦断的なエピソードデータと、前記施術前フェーズに対してコンピューター計算された少なくとも１つの予測出力と、患者ＧＵＩとの患者のインタラクションに対応するデータが前記施術前フェーズに対する前記縦断的なエピソードデータに格納されるように前記インタラクティブな承諾書と対話するための前記患者ＧＵＩと、に基づいて、インタラクティブな承諾書を作成するための承諾作成部をさらに含む、請求項１０に記載のシステム。
【請求項１５】
前記施術前フェーズに対する前記縦断的なエピソードデータは、前記ＧＵＩとの前記ユーザーインタラクションを、前記施術計画を規定する一組の前記対応の別々のコンセプトに翻訳することで、前記施術前フェーズの間に前記ＧＵＩとのユーザーインタラクションに応答して作成された施術計画を含み、
前記複数のフェーズのうちもうひとつのフェーズは、前記施術前フェーズから前記施術計画をもとに導かれた施術中の縦断的なデータを含む施術中フェーズを含む、請求項１４に記載のシステム。
【請求項１６】
前記施術中の縦断的なデータは、データエレメントを含み、前記施術中フェーズのデータエレメントは、コード化データエレメントを含み、前記コード化エレメントは各々、規定のコード標準に従って、前記患者に対する前記ケアの縦断的なエピソードのそれぞれの態様を提示するようプログラムされ、前記ツールマネージャーは、前記施術中フェーズの前記縦断的なエピソードデータにおけるコード化エレメントと、前記施術前フェーズからの前記施術計画における対応のコード化データエレメントとの間の不一致を検出するようプログラムされ、前記検出された不一致の内容が、不一致データとして前記施術中の縦断的なデータに格納される、請求項１５に記載のシステム。
【請求項１７】
前記ツールマネージャーは、前記ＧＵＩを介して前記不一致データに基づいてインタラクティブなリクエストを生成するようさらにプログラムされ、前記インタラクティブなリクエストに対する応答は、前記施術中フェーズに対する前記検出された不一致を資料化するために、応答データとして前記施術中の縦断的なデータに格納される、請求項１６に記載のシステム。
【請求項１８】
カルテシステムにアクセスするためのカルテインターフェースをさらに備え、前記ツールマネージャーは、前記患者のカルテで前記検出された不一致を資料化するために、前記応答データを前記カルテシステムに供給するのに前記カルテインターフェースを利用する、請求項１７に記載のシステム。
【請求項１９】
前記データアグリゲーターは、前記カルテシステム以外の少なくとも１つの外部ソースから外部データを得るようさらに構成され、前記外部データは、前記ケアの縦断的なエピソードの施術中の態様に関する情報を与え、前記ケアの縦断的なエピソードの前記施術中の態様に関する前記情報は、補助データとして前記縦断的なエピソードデータに格納され、前記患者の前記カルテに、前記ケアの縦断的なエピソードの前記施術中の態様に関する前記情報を資料化するために、前記補助データを前記カルテシステムに供給するための前記ツールマネージャー、請求項１８に記載のシステム。
【請求項２０】
プロセッサーによって実行されると、前記プロセッサーに、
少なくとも一部がケアの縦断的なエピソードと関連した患者データを含む、患者のコンテキストデータを集めさせ、
ユーザーインタラクションに応答するグラフィカルユーザーインターフェース（ＧＵＩ）を与えさせ、
前記ＧＵＩとの前記ユーザーインタラクションを、対応の別々のコンセプトに翻訳させ、
前記コンテキストデータに基づいて、かつ、前記ＧＵＩとの前記ユーザーインタラクションに応答して、縦断的なエピソードデータを生成および格納させ、
前記対応の別々のコンセプトを、前記患者の縦断的なエピソードデータの一部としてメモリーに格納させる指示を含むことで、前記ケアの縦断的なエピソードの複数のフェーズの資料化と管理を容易にする、非一過性のコンピューター読取り可能な媒体。
【請求項２１】
前記指示はさらに、
電子カルテ（ＥＨＲ）システムの患者データにアクセスし、
前記縦断的なエピソードデータを前記ＥＨＲシステムに選択的に格納して、前記ケアの縦断的なエピソードにおける前記複数のフェーズ各々の態様を資料化するためのものである、請求項２０に記載の媒体。
【請求項２２】
前記指示はさらに、
前記少なくとも１つのフェーズの前記縦断的なエピソードデータに基づいて、前記複数のフェーズにおける少なくとも１つのフェーズに対する予測出力をコンピューター計算し、
前記予測出力ならびに前記予測出力に関連するユーザーインタラクションを、前記少なくとも１つのフェーズの前記縦断的なエピソードデータの一部として格納するためのものである、請求項２０に記載の媒体。
【請求項２３】
前記指示はさらに、前記予測出力および前記予測出力のコンピューター計算された精度に基づいて、前記ＧＵＩを介して推奨行為を生成するためのものである、請求項２２に記載の媒体。
【請求項２４】
前記指示はさらに、
前記複数のフェーズのうちの施術前フェーズに対する前記縦断的なエピソードデータと、前記施術前フェーズに対してコンピューター計算された少なくとも１つの予測出力とに基づいて、インタラクティブな承諾書を作成し、
前記インタラクティブな承諾書とのユーザーインタラクションに基づいて、患者のインタラクションデータを前記施術前フェーズに対する前記縦断的なエピソードデータに格納するためのものである、請求項２２に記載の媒体。
【請求項２５】
前記縦断的なエピソードデータは、コード化データエレメントを含み、前記コード化エレメントは各々、規定のコード標準に従って、前記患者に対する前記ケアの縦断的なエピソードのそれぞれの態様を提示するようプログラムされ、
前記指示はさらに、前記ケアの縦断的なエピソードの前記複数のフェーズのうち連続したフェーズにおける対応のコード化データエレメントの比較に基づいて、前記連続したフェーズ間の逸脱を検出し、前記縦断的なエピソードデータの一貫性を強化するためのものである、請求項２０に記載の媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、患者の縦断的なエピソードを管理するためのグラフィックツールに関する。
【発明の概要】
【発明が解決しようとする課題】
【０００２】
本開示は、患者の縦断的なエピソードを管理するためのグラフィックツールに関する。
【課題を解決するための手段】
【０００３】
一例として、患者のケアの縦断的なエピソードを管理するためのシステムは、患者についてのコンテキストデータを与えるようプロセッサーによって実行可能な患者データアグリゲーターを含んでもよく、コンテキストデータの少なくとも一部は、ケアの縦断的なエピソードにおける複数のフェーズに関連する患者データを含む。ツールマネージャーは、関連のグラフィカルユーザーインターフェース（ＧＵＩ）とのユーザーインタラクションを、対応の別々のコンセプトに翻訳することができる。対応の別々のコンセプトは、患者についての縦断的なエピソードデータの一部としてメモリーに格納可能であり、縦断的なエピソードデータは、コンテキストデータに基づいて、かつ、ケアの縦断的なエピソードの資料化と管理を容易にするためのＧＵＩとのユーザーインタラクションに応答して生成される。
【０００４】
もうひとつの例として、非一過性のコンピューター読取り可能な媒体は、プロセッサーによって実行されると、プロセッサーに、少なくとも一部がケアの縦断的なエピソードと関連した患者データを含む、患者のコンテキストデータを集めさせる指示を含んでもよい。また、この指示は、プロセッサーに、ユーザーインタラクションに応答するグラフィカルユーザーインターフェース（ＧＵＩ）を与えさせることができる。また、この指示は、プロセッサーに、ＧＵＩとのユーザーインタラクションを、対応の別々のコンセプトに翻訳させることができる。さらに、この指示は、プロセッサーに、コンテキストデータに基づいて、かつ、ＧＵＩとのユーザーインタラクションに応答して、縦断的なエピソードデータを生成して格納させ、なおかつ、対応の別々のコンセプトを、患者の縦断的なエピソードデータの一部としてメモリーに格納させることができる。このようにして、ケアの縦断的なエピソードの複数のフェーズの資料化と管理を容易にする。
＝＝関連出願へのクロスリファレンス＝＝
【０００５】
本出願は、発明の名称「GRAPHICAL TOOL FOR MANAGING A LONGITUDINAL PATIENT EPISODE（患者の縦断的なエピソードを管理するためのグラフィックツール）」で２０１１年１１月１７日にファイルされた米国仮特許出願第６１／５６０，９８５号の優先権の利益を主張するものであり、その内容全体を本明細書に援用する。
【図面の簡単な説明】
【０００６】
【図１】実装可能なグラフィックマネジメントツールの一例を示す。
【図２】患者に対するケアの縦断的なエピソードに対するドキュメントの一貫性を保ちやすくするためのシステムの一例を示す。
【図３】患者に対するケアの縦断的なエピソードに利用可能な予測システムの一例を示す。
【図４】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図５】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図６】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図７】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図８】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図９】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１０】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１１】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１２】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１３】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１４】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１５】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１６】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１７】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１８】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図１９】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図２０】本明細書に開示されているものなどのツールを実装するのに利用可能なグラフィカルユーザーインターフェースおよびワークフローの例を示す。
【図２１】コンピューティング環境の一例を示す。
【発明を実施するための形態】
【０００７】
本開示は、患者に対するケアの縦断的なエピソードを、グラフィックを用いて管理・資料化するためのシステムおよび方法に関する。本明細書で使用する場合、ある患者に対するケアの縦断的なエピソードは、その患者の１つまたは２つ以上の健康状態を包含してもよい。また、ケアの縦断的なエピソードは、患者の相談（たとえば、治療計画、検討または他の評価）、介入、検査、施術（たとえば外科手術などの施術）、施術後のケアのみならず、他の健康関連のやり取りに携わることのある、１人以上の任意数の介護者との長期間にわたるやり取りを含んでもよい。本明細書に開示のシステムおよび方法は、縦断的なケアにおけるそのような側面それぞれについて、正確で詳細な資料化を一層容易にするためのコンテキスト駆動型のグラフィカルユーザーインターフェース（ＧＵＩ）を提供する。あるケアの縦断的なエピソードにおける各フェーズのドキュメントは互いにリンクしているため、複雑な照会やユーザーとの面倒なやり取りを必要とせずに、ケアの過程で終始、詳細情報を容易に利用することができる。
【０００８】
図１は、ある患者に対する一定期間にわたる縦断的なケアを介護者が効果的かつ効率的に管理および資料化できるようにするためのツール１０２を含む、システム１００の一例を示す。ツール１０２は、１つまたは２つ以上の非一過性の機械読取り可能な媒体（たとえば揮発性メモリーまたは不揮発性メモリー）に格納された指示およびデータを含んでもよい。このツールの指示およびデータは、プロセッサーによってアクセス可能であり、本明細書に開示の機能および方法を行うよう実行可能である。また、ツール１０２の機能および方法を実装するよう、機械（たとえば専用コンピューター）をプログラムすることも可能である。
【０００９】
図１の例では、ツール１０２は、ある患者についてのコンテキストデータ１０４を利用する。このコンテキストデータ１０４がゆえに、ツールは、コンテキストに特化した適応型のグラフィカルユーザーインターフェース（ＧＵＩ）１２８を提供できる。ＧＵＩ１２８は、ユーザーと対話するためのＧＵＩエレメントからなる適切なセットを選択的に供給する。コンテキストデータ１０４は、ユーザーデータ１０６、エピソードコンテキストデータ１０８、患者データ１１０、オプションデータ１１２を含んでもよい。
【００１０】
一例として、患者データ１１０は、今受けている診察のための、患者に関連する問題リストデータを含んでもよい。問題リストデータは、あるエピソードの間に、患者の医療記録から（たとえばＥＨＲリポジトリから）あるいは患者自身からのみならず、介護者からも得られる。ある時の受診のための問題リストデータは、その時の受診のための、患者に関連する問題で、懸案となっているすべてのものを包含してもよい。これを、患者に関連する（たとえば問題リストにある）懸案となっている問題と、すでに解消した問題をはじめとする過去の他の問題とを含み得る、ＥＨＲから得られる患者の医療履歴全体と対比してもよい。たとえば、問題リストデータは、過去の診断と現行の診断、病態生理学的状態、潜在的に重要である異常な身体的兆候および検査所見、障害、普通ではない状況を含んでもよい。また、社会的な問題、精神医学的な問題、危険因子、アレルギー、薬物または食品に対する反応または挙動の問題などの他の要因あるいは、懸案となっている課題に関する他の健康上の注意事項も、問題リストデータに含まれていてもよい。
【００１１】
別の例として、コンテキストデータ１０４における懸案の問題のリストの項目に、１つまたは２つ以上の所有権のあるコードセットまたは標準化されたコードセットを含んでもよいおよび／または当該項目を上述したようなコードセットにリンクまたはマッピングしてもよい。このコードセットとしては、疾病及び関連保健問題の国際統計分類（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｌａｓｓｉｆｉｃａｔｉｏｎ  ｏｆ  Ｄｉｓｅａｓｅｓ（ＩＣＤ））コード（たとえば、ＩＣＤ−９および／またはＩＣＤ−１０コード）、国際医学用語（Ｓｙｓｔｅｍａｔｉｚｅｄ  Ｎｏｍｅｎｃｌａｔｕｒｅ  ｏｆ  Ｍｅｄｉｃｉｎｅ（ＳＮＯＭＥＤ））コード（たとえば、ＳＮＯＭＥＤ医学用語集（ＣＴ）コード）、医療行為用語（Ｃｕｒｒｅｎｔ  Ｐｒｏｃｅｄｕｒａｌ  Ｔｅｒｍｉｎｏｌｏｇｙ（ＣＰＴ））コード、ヘルスケア一般処置コード体系（Ｈｅａｌｔｈｃａｒｅ  Ｃｏｍｍｏｎ  Ｐｒｏｃｅｄｕｒｅ  Ｃｏｄｉｎｇ  Ｓｙｓｔｅｍ（ＨＣＰＣＳ））コード（たとえば、ＨＣＰＣＳレベルＩおよびＨＣＰＣＳレベルＩＩ）、耐久性医療器具（Ｄｕｒａｂｌｅ  Ｍｅｄｉｃａｌ  Ｅｑｕｉｐｍｅｎｔ（ＤＭＥ））コード、解剖学的相関などがあげられる。このように、場所または介護者の所属に応じて変わることもある上記のコードなどのコードを利用して、患者の、ある受診で懸案となっている問題のリストにおけるデータエレメントを表すことが可能である。また、これらのコードを用いて、患者に対する計画的な施術や医療サービスを特定するだけでなく、あるエピソードについて患者に対してなされた医療サービスおよび施術を特定することもできる。さらに、このようなコードに与えられる特異性と意味は、エピソードのフェーズ（たとえば、施術前、施術中、施術後）によっても変わることがある。これらのコードは各々、たとえばケアの縦断的なエピソード全体を通して変わることがある患者データ１１０のデータエレメントに対応してもよい。
【００１２】
コンテキストデータ１０４は、あるケアの縦断的なエピソードについて、複数の離散したソースから選択的に集められてもよい。たとえば、ツール１０２は、患者データを１つまたは２つ以上のソースから収集して組み合わせるようプログラムされた患者データアグリゲーター１１４を含んでもよい。患者データのソースは、１つまたは２つ以上の電子カルテ（ＥＨＲ）システム１１６を含んでもよい。患者データアグリゲーター１１４は、１つまたは２つ以上の任意数のＥＨＲシステム１１６からデータを取得するようプログラムされたＥＨＲインターフェース１１８（たとえば、一組のアプリケーションプログラムインターフェース）経由で、ＥＨＲシステム１１６から、ある患者についてのデータを得ることができる。ツール１０２は、どのようなタイプのＥＨＲシステムでも動作するよう構成可能である。
【００１３】
別の例として、患者データアグリゲーター１１４は、ある患者について関連のあるデータを検索するよう、ＥＨＲシステム１１６にインターフェース１１８経由で問い合わせることができる。この問い合わせは、コンテキストデータ１０４によって変わることもある。たとえば、患者データアグリゲーター１１４は、検索される情報のほうが、あるユーザーに対する関連性が高くなるようにして、ユーザーデータ１０６に基づいて、患者データおよび懸案となっている問題のリストデータを取得できる。たとえば、心臓弁置換を予定している胸部心臓外科医は、股関節置換術を予定している整形外科医とは異なる結果セットを必要とする場合がある。あるいは、コンテキストデータ１０４とは無関係に、詳細な患者データの包括的なセットを検索することも可能であり、ＧＵＩ１２６は、コンテキストデータ（たとえば、ユーザーデータ１０６を含む）に基づいて、情報およびオプションをユーザーに対して選択的に提示可能である。いくつかの例では、対応の標準（たとえば、ＩＣＤおよび／またはＳＮＯＭＥＤ）に沿ってコード化できるものなどの問題リストデータを、ＥＨＲシステム１１６から得ることが可能である。
【００１４】
また、患者データアグリゲーター１１４は、１つまたは２つ以上の他の外部ソース１２０用のデータも得ることができる。他の外部ソース１２０は、依頼元医師からの患者データを含んでもよい。この患者データは、たとえば、多岐にわたる形態およびファイルフォーマットで提供可能である。外部データの他のソースは、システム１００に入力できる形態などの情報をはじめとする関連のある患者データを個人が格納する先になり得るサムドライブ、電子メールメッセージまたは他のデータベースおよびリポジトリであってもよい。また、他のソース１２０は、スケジューリングシステム、在庫追跡システム、課金システムなどの他のシステムを含んでもよい。よって、患者データアグリゲーター１１４は、これらのソース１２０からデータを得て、これをＥＨＲシステム１１６から取得した患者データ（たとえば、懸案となっている問題のリストデータ）と組み合わせ、対応の患者データ１１０を出力することができる。
【００１５】
また、ツール１０２は、１人または２人以上のユーザーがツール１０２と対話できるようにする、１つまたは２つ以上のユーザー入力装置１２２を含んでもよい。ユーザー入力装置１２２は、ワークステーション、パーソナルコンピューター、手で持つことのできるコンピューティングデバイス（たとえば、スマートフォン、タブレットコンピューター、ＰＤＡなど）に対応してもよい。ユーザー入力装置１２２は、１２４で概略的に示すように、ツール１０２と直接またはネットワーク接続経由で通信可能である。ユーザー入力装置は、ＧＵＩ１２６を提示し、ユーザーインタラクションに対応するツールに供給されるユーザー入力を受信できるディスプレイを含んでもよい。
【００１６】
ＧＵＩ生成部１２８は、コンテキストデータ１０４に基づいてＧＵＩ１２６を生成するようプログラム可能である。たとえば、ＧＵＩ生成部１２８は、ユーザーデータ１０６、エピソードコンテキストデータ１０８、患者データ１１０、オプションデータ１１２に基づいて、ＧＵＩ１２６を構築可能である。ＧＵＩ生成部１２８は、汎用的なグラフィックフレームワークを採用できる。この汎用的なグラフィックフレームワークを採用できるは、一組のユーザーに対して一貫して維持されるが、エピソードコンテキストデータ１０８、患者データ１１０、オプションデータ１１２に基づいて、適応させることもできる。ユーザーデータ１０６は、たとえばシステム１００でのユーザーの役割（たとえば、医師、看護師、ナースプラクティショナーまたは他のヘルスケア提供者）や好みを含むなどして、ツール１０２のユーザーを特徴付けることが可能である。ユーザーデータ１０６またはエピソードコンテキストデータ１０８はさらに、ケアの縦断的なエピソードの、あるフェーズにおけるユーザーの役割に関する一層詳細な態様を特定することもできる。たとえば、ユーザーデータ１０６は、ユーザーが胸部心臓外科医であることを特定でき、エピソードコンテキストデータ１０８は、ユーザーが特定のタイプの施術を行うことを意図している旨のみならず、それぞれのエピソードのフェーズ（たとえば、最初は施術前フェーズ）も特定できる。このように、ＧＵＩ生成部１２８は、コンテキストデータ１０４から情報を選択し、適切な情報とオプションを用いてＧＵＩ１２６を生成可能である。もうひとつの例では、対応のＧＵＩ１２６と提供される情報をツール１０２の想定レシピエントおよびユーザーに応じて調節できるように、ユーザーが患者であってもよい。よって、ＧＵＩ生成部１２８は、コンテキストベースの制御を実装して、ユーザーの役割および好みのみならず、患者の状況に関する具体的な詳細内容に基づいて、対応のＧＵＩを構築することができる。
【００１７】
ツールマネージャー１３０は、コンテキストデータ１０４を管理するようプログラム可能である。たとえば、ツールマネージャー１３０は、それぞれの患者、患者が遭遇する問題（患者データ１１０から）を扱う際のユーザーの役割に応じて、エピソードコンテキストデータ１０８を関連のデータサブセットとして出力するようプログラム可能である。ツールマネージャー１３０は、ＧＵＩ生成部１２８がＧＵＩ１２６における一組の関連のＧＵＩエレメントを提供できるように、エピソードコンテキストデータ１０８に基づいてオプションデータ１１２を選択的に出力する。たとえば、ツールマネージャーは、コンテキストデータ１０４ならびに、コンテキストデータとの間のユーザーインタラクションに基づいて、どのオプション、情報、グラフィックをオプションＧＵＩエレメントとしてユーザーに提示するかを選択することができる。オプションＧＵＩエレメントは、たとえば、治療過程が外科的であるか外科的でないか、あるいは、他の介入がなされるかによって、ユーザーデータ１０６によって与えられるようなユーザーの役割をもとに変化してもよい。
【００１８】
また、ツールマネージャー１３０は、オプションデータ１１２用のオプションを選択するためのオプションセレクター１３１を含んでもよい。オプションは、患者に適用できるか患者から排除できるツール、施術、医薬品を含んでもよい。たとえば、オプションセレクター１３１は、ユーザーデータ１０６の一部として格納できるユーザーの役割やユーザーの好みのみならず、ＧＵＩ１２６の状態または状況を定義できるエピソードコンテキストデータ１０８にも基づいて、関連のあるオプションのサブセットを選択できる。一例として、ある外科医が、あるタイプのインプラントをオプションとして利用できるようにすることを好む場合があり、オプションセレクターは、この好みに基づくＧＵＩエレメントをＧＵＩ１２６に提示できる。当該好みは、ユーザーがＧＵＩ１２６を用いて操作できるものである。システム１００は、各ユーザーに、ユーザーの好みに応じて、関連の情報ならびに見た目と感じを与えることについて、時間をかけてユーザーの好みを学習することができる。
【００１９】
また、ツールマネージャー１３０は、コンテキストデータ１０４およびユーザーデータ１０６をもとに、かつ、ＧＵＩ１２６との間のユーザーインタラクションに応答して、別々のコンセプトに対応する縦断的なエピソードデータ１３２を出力して維持することができる。ツールマネージャー１３０は、ＧＵＩ１２６との間のユーザーインタラクションを対応する別々のコンセプトに翻訳するようプログラムされるコンセプトエンジン１３４を含んでもよい。こうして得られる別々のコンセプトは、縦断的なエピソードデータ１３２の一部として、メモリーに格納可能である。別々のコンセプトは、秩序立った構成で一緒にリンクして、患者ケアエピソードに関する詳細情報を提供する。たとえば、この秩序立った構成を用いると、フェーズおよびサブフェーズに応じて、エピソードの縦断的なデータを整列させることができる。コンセプトエンジン１３４によって、他の時間的構成（離散的または連続的な時間間隔）および論理構成を利用して、データを好適な構成にリンクしてもよい。コンセプトデータ１３６はさらに、エピソードの各フェーズについて、患者データ（たとえば、ＩＣＤおよび／またはＣＰＴコードなどのコードに対応するデータエレメントを含む）１１０のみならず、コンテキストデータ１０４の他の部分とプログラム的に関連させることが可能である。別々のコンセプトの具体的な内容は、ケアの縦断的なエピソードのフェーズによって変わることがあるだけでなく、縦断的なエピソードデータ１３２の生成に利用できるコンテキストデータによっても変わることがある。
【００２０】
別の例として、コンセプトエンジン１３４は、メモリーに格納されたコンセプトデータ１３６に基づいて別々のコンセプトを提供する、あるいは、ＧＵＩ１２６との間のユーザーインタラクションに応答してコンセプトを構築するようプログラム可能である。一例として、コンセプトエンジン１３４は、ＧＵＩ１２６を用いたユーザーインタラクションに応答して、対応する別々のコンセプトに対するコンセプトデータ１３６を検索するためのクエリーを構築可能である。このクエリーは、ユーザー入力（たとえば、ＧＵＩ上でインタラクションが生じた場所、インタラクションのタイプ）、エピソードコンテキストデータ１０８（たとえば、そのＧＵＩに対する施術のコンテキストを表している）、ユーザーデータ１０６をもとに構築されてもよい。いくつかの例では、コンセプトエンジン１３４は、ＧＵＩ１２６との間のユーザーインタラクションに応答して、（コンセプトデータ１３６に対応するナレッジベースから）別々のコンセプトを構築するよう（たとえば、推論エンジンを用いて）プログラムされるエキスパートシステムなどの人工知能を含むまたはこれにアクセスするものとして実装可能である。縦断的なデータ１３６を出力するためにコンセプトエンジン１３４が生成する別々のコンセプトも、ある患者に対する他のコンテキストデータ１０４（ＥＨＲシステム１１６から得られる、患者の懸案となっている問題のリストを含む）をもとに決定されてもよい。
【００２１】
一例として、ＧＵＩ１２６は、患者の解剖学的構造のインタラクティブなグラフィック表現を含んでもよく、ユーザーインタラクション（たとえば、ある解剖学的位置に線を引くこと）が、その位置に切開部を作るコンセプトに対応してもよい。もうひとつの例として、ユーザーは、インプラントのＧＵＩエレメント（オプションデータ１１２からＧＵＩ生成部１２８によって選択される）を、その時点でＧＵＩ１２６に表示されている特定の埋め込み部位にドラッグできる。コンセプトエンジン１３４は、ユーザーインタラクションに応答して、インプラントが何であるか、どこに埋め込むことになるのかを説明する対応のコンセプトを生成することが可能である。手術を予定する場合の例で説明を続けると、ＧＵＩエレメントとして異なるオプションを与えることができ、これらのオプションは、その時点での施術の段階に応じて（たとえば、ツールマネージャー１３０によって）選択可能である。また、これらのオプションは、たとえば患者データ１１０および他のユーザー入力から確認できる、手術や患者の病状のタイプによるものであってもよい。
【００２２】
別の例として、ツールマネージャー１３０は、ある患者エピソードに対する縦断的なエピソードデータ１３２を追跡し、維持するのに利用されるエピソード生成部１３７を含んでもよい。たとえば、エピソード生成部１３７は、ある患者に新たなエピソードを開始するオプションを選択するユーザー入力に応答して、縦断的なエピソードデータ１３２に新たなエピソードレコードを作ることができる。エピソードがすでに存在する場合、これを新たなコンセプトデータを既存のレコードに加えてもよい。維持され、縦断的なエピソードデータ１３２に格納されるデータのタイプは、ある施術のコンテキストとエピソードのタイプによって変わることがある。
【００２３】
さらに別の例として、ツール１０２を利用して、ある施術の計画を作ることもできる。ある施術に対する計画を立てるにあたり、エピソード生成部１３７は、ＧＵＩ生成部に、以後の施術を行う前に望ましい場合がある施術前検査などの介入を含むオプションを選択させることができる。このようなオプションは、ＧＵＩ１２６においてＧＵＩエレメントとして提示可能であり、これは、たとえば施術計画にドラッグするなどして、あるユーザーが選択またはアクティブにできるものである。もうひとつのオプションに、たとえば１つまたは２つ以上の別々のコンセプトのうち、口述、タイピングまたは他の形式の入力を可能にできるなど、自由形式のユーザー入力を含んでもよい。このようなオプションのタイプと詳細については、オプションデータ１１２に格納可能である。必要となり得る施術前イベントおよび検査をユーザーが完了したら、文書作成部１３８は、あるマネジメント治療の過程に対する縦断的なエピソードデータの一部として出力可能な、すべきことのリストなどの文書を作成可能である。また、ツールマネージャー１３０は、たとえばこのような事前の治療計画で要求されていることのある試験または介入をスケジュール調整するためのスケジューリングメッセージを生成してもよい。スケジューリングメッセージは、たとえば、スケジューリングシステムに（たとえば外部ソース１２０から外に）送信可能である。
【００２４】
ツールマネージャー１３０は、ＥＨＲモジュール１４０も利用可能である。このＥＨＲモジュール１４０は、患者の永久レコードの一部となるようＥＨＲシステム１１６まで逆順で並べられた対応の介入および要求を送信するのにインターフェース１１８を利用できる。ＥＨＲシステム１１６に返信することが可能な情報のタイプは、ＥＨＲシステムの構成と機能によって変わることもある。たとえば、詳細なレコードを、宛先のＥＨＲシステム用にＥＨＲインターフェース１１８によって指定される所望のフォーマットで提供することができる。あるいは、縦断的なエピソードの何か所かでテキストレコードまたはＰＤＦファイルを作成してＥＨＲシステム１１６に転送してもよく、その度合いがＥＨＲシステムの機能によって変わってもよい。
【００２５】
上記にて開示したように、どのような検査の結果でも、ツール１０２に入力またはデータソース（ＥＨＲシステム１１６または１つまたは２つ以上の外部ソース１２０など）から検索することができる。あるいはまたはそれに加えて、ユーザー入力装置１２２を使用して、ツール１０２に結果を直接入力してもよい。
【００２６】
縦断的なケアのもうひとつの面として、ＧＵＩ生成部１２８は、ある施術に関連する患者の承諾を得やすくすることもできる。ＧＵＩ生成部１２８は、提供者などのユーザーが、次に予定されている治療過程のステップをグラフィカルに示すことができるようにするためのＧＵＩ１２６を作成でき、ツールマネージャー１３０は、対応のコンセプトを、上記にて開示したような縦断的なデータとして格納できる。ツールマネージャー１３０は、承諾書を作成するための承諾作成部１４２を含んでもよい。この承諾書は、電子的な文書であってもハードコピーの文書であってもよく、電子的な文書と印刷した文書の組み合わせであってもよい。承諾書は、同一セットの縦断的なデータおよびユーザーインタラクションから、ツール１０２を用いて作成可能である。
【００２７】
たとえば、患者との話し合いの間、医師−ユーザーは、あるユーザー入力装置（たとえばタブレットコンピューターなど）を利用することができ、ある施術の個々のステップを追うことができる。ＧＵＩ生成部１２８は、ＧＵＩ１２６によってグラフィックを出力し、医師−ユーザーによるＧＵＩ１２６との間のインタラクションに応答して、アニメーションを含んでもよい施術の詳細な可視表示を提示することができる。ＧＵＩ１２６は、エピソードコンテキストデータ１０８、オプションデータ１１２、患者データ１１０、ユーザーデータ１０６に基づいて、（たとえば入力装置１２２を用いての）ユーザーインタラクションに応答して修正可能な解剖学的可視表示を利用できる。この計画フェーズでは、ＧＵＩ生成部１２８は、オプションをインタラクティブなグラフィックオブジェクトとして提示できる。これらのオブジェクトは、ＧＵＩ１２６の解剖学的グラフィックに対して移動可能となり得るものである。よって、コンセプトエンジン１３４は、ＧＵＩで、例証的なユーザーインタラクションに応答して、別々のコンセプトを作成できる。これは、ある施術に対する計画を集合的に形成する。さまざまなステップおよびオプションをすべて、ＧＵＩ１２６を用いてグラフィカルに精査および操作した後、各ステップを、縦断的なエピソードデータ１３２の一部としての別々のコンセプトとして、格納することができる。
【００２８】
承諾作成部１４２はさらに、承諾書を作成できる。たとえば、承諾書は、上述したように医師ユーザーによって患者に示される施術計画を含んでもよい。あるいは、承諾作成部１４２は、承諾書を他の形態（たとえば、グラフィックなスライドショー、パワーポイント、映像、印刷した文書など）で出力してもよく、これをユーザーが承認することも可能である。ユーザーは、施術の各ステップに関連するインフォームドコンセントを、ユーザー入力装置１２２を用いて電子的に示すことができる。これは、医師によるデモンストレーション後に行ってもよいし、施術時にステップごとに行ってもよい。あるいは、患者のインフォームドコンセントを１つまたは２つ以上の他の方法（たとえば、手書きの署名）で得るよう承諾書を作成してもよい。また、承諾書は、施術に関連するリスクを明示するものであってもよく、これも同じく患者が承認することが可能である。
【００２９】
いくつかの実施形態では、ツールマネージャー１３０は、予測エンジン１４４を利用して、リスクを明示することができる。予測エンジン１４４は、ユーザーが計画した、ある施術に対するリスクベースの評価を構成するのに利用可能である。たとえば、予測エンジン１４４は、モデル選択部１４６を含んでもよい。モデル選択部１４６は、作成された計画によってのみならず、患者データ１１０に基づいても変わり得る予測モデル１４８を選択するのに利用される。よって、モデル選択部１４６は、計画によって１つまたは２つ以上の予測モデルを選択して、想定されるリスクの評価を与えることができる。たとえば、リスク生成部は、対応のリスクの明示をコンピューター計算可能なリスク計算部１５０を含んでもよい。その内容は、ユーザーに提示可能である。リスクの明示は、たとえば承諾書内で、患者に提示されてもよい。リスクの明示は、特定タイプの施術についての対応のリスクを明示するのに利用できるパーセンテージや他の値などの多岐にわたるフォーマットで提示できる。
【００３０】
上述したように、術前計画に対応する一組の別々のコンセプトを、縦断的なエピソードデータ１３２に格納することが可能である。この計画は、たとえばある計画がどのようなものであったか理解するための精査用にアクセス可能である。また、たとえば計画された施術を行い、対応する施術記録を作るために、後の治療過程で計画を利用することも可能である。計画が逸脱することなく守られたら、すでに行った施術に関連する追加の詳細事項のエントリーと一緒に、施術内で当該施術の計画を利用してもよい。あるユーザーが計画から逸れたら、もとの計画を変更し、詳細事項を追加して対応の施術記録を与えるようにしてもよい。施術前の計画と施術記録との差を識別するために、比較用の記録を作成してもよい。施術で得られる追加の詳細事項と、計画と実際に行った施術との差を、縦断的なエピソードデータ１３２に加えてもよい。たとえば、詳細事項には、利用したインプラントの説明、独特な態様や合併症についての記録のみならず、施術に入れると望ましい場合がある他のコメントや記録を含んでもよい。
【００３１】
一例では、同一のツール１０２を利用して、施術記録を作成してもよい。ツールおよび施術前計画の縦断的な性質がゆえ、施術記録は、施術時または施術のすぐ後に容易に完成させられる。ツール１０２とのインタラクションを容易にするために、ユーザー入力装置１２２は、手の動きをリアルタイムで捕捉するためのオペレーティングルームでの検知用アレイ（たとえば、１つまたは２つ以上のカメラ）に対するジェスチャーまたは手の動きに応答してユーザー入力を受信するジェスチャー認識システムを含んでもよい。このように、ツール１０２を用いて、施術時または施術の直後に施術記録を構成することができる。
【００３２】
施術および施術記録の入力に続いて、ＥＨＲモジュール１４０は、上記にて開示したものと同様にして、記録などの関連の情報をＥＨＲシステム１１６に送信することができる。
【００３３】
また、ツール１０２は、施術後の治療過程およびスケジュール調整を容易にするだけでなく、患者用の退院指示を作成するのにも利用できる。たとえば、ツールマネージャー１３０は、たとえば、施術後に、医薬品の選択、リハビリテーションプロトコール、追加のフォローアップ診察のスケジューリングのために、以後のケアオプション（オプションデータ１１２に対応）を選択するためのルールを用いてもよい。ルールは、施術用に格納されている縦断的なエピソードデータのみならず、ユーザーデータ１０６に含まれる好みに基づいて変わることもある。
【００３４】
また、ケアの縦断的なエピソードの施術後フェーズを管理して資料化するのに、ツール１０２を用いることも可能である。たとえば、文書作成部１３８は、施術後の指示を作成できる。この施術後の指示は、患者が入院した状態にある間はもとより、退院時の患者に対する退院指示などである。これは、施術の後で、ある患者に対するコンテキストデータ１０４の施術後のインスタンスをもとに自動的に行うことができる。あるいはまたはそれに加えて、提供者からのユーザー入力に応答して、ケアの指示を作成してもよい。
【００３５】
治療計画、施術などのさまざまな態様は、別々のコンセプトとして縦断的なエピソードデータ１３２に格納されるため、対応の情報を利用して自動判断支援をすることができる。また、縦断的なエピソードデータ１３２として格納される情報の度合いがゆえに、ユーザーは、ツール１０２を用いて、あるいは、別のシステム（たとえば、ＥＨＲシステム）を経由したツールに対するアプリケーションインターフェースを用いて、このような情報を精査し、従来のメカニズムで容易に得られたり容易にアクセスしたりできるようなものではないことがある、特定のエピソードに対する関連の重要な患者ケアアイテムを得ることができる。このため、縦断的なデータ１３２は、施術前の計画、手術の計画、承諾情報、施術後のケアを含むケアの縦断的なエピソードのさまざまなフェーズを集合的に表す別々のエレメントの詳細なレコードを出力することができる。縦断的なケアのそれぞれのフェーズを資料化している対応のデータを、ＥＨＲシステム１１６に格納してもよい。
【００３６】
図２は、図１のシステム１００の一部として実装可能なフェーズ資料化マネジメントシステム２００の一例を示す。システム２００は、データの一貫性を維持し、患者ごとの縦断的なケア施術に関連する複数のフェーズ２０２、２０４、２０６間での追跡を容易にする一助となるようプログラムされる。図２の例では、システム２００は、それぞれの患者に関連する施術前フェーズ２０２、施術中フェーズ２０４、施術後フェーズ２０６のインスタンスを含む。この例では３つのフェーズを示してあるが、患者ケアの縦断的なエピソードを、これよりも多いまたは少ない異なる数のフェーズに分割してもよく、その各々のフェーズがサブフェーズを含んでもよい。いくつかの例では、施術前フェーズ２０２を、相談前フェーズ（たとえば、懸案となっている問題のリストデータに対応）、初期相談フェーズ、治療計画フェーズに細分化することができる。同様に、施術後フェーズ２０６を、退院前サブフェーズと退院後サブフェーズに分割してもよい。このようなサブフェーズは各々、たとえば患者の医療記録から、患者から、提供者から得られる当該サブフェーズ各々の入手可能なデータに従って患者データ（たとえば、懸案となっている問題のリスト）を反映したそれぞれのデータエレメントを含んでもよい。
【００３７】
各フェーズ２０２、２０４、２０６は、それぞれのフェーズに対するプロパティと属性とを規定する縦断的なデータ２０８、２１０、２１２を含む。特に、それぞれのフェーズ２０２、２０４、２０６に対する縦断的なデータ２０８、２１０、２１２は、縦断的なヘルスケアエピソードを集合的に特徴付ける複数のデータエレメント２１４、２１６、２１８を含む。いくつかの例では、データエレメント２１４、２１６、２１８は、各フェーズに対するＩＣＤコード、ＣＰＴコード、ＳＮＯＭＥＤコードなどのコード化データを含んでもよい。コード化データエレメント２１４、２１６、２１８は、（たとえば、ＥＨＲシステム）からの患者のレコードおよび／または本明細書に開示したような他のデータソースから得られる。いくつかの例では、ヘルスケア提供者のユーザーがエディター２２０を経由してデータエレメントの一部を提供してもよい。たとえば、ヘルスケア提供者は、エディター２２０の対応のＧＵＩ２２２を介してシステムと対話して、ある患者についてのデータエレメントを補助、修正または削除することができる。あるいはまたはそれに加えて、データエレメント２１４、２１６、２１８は、患者のレコードからおよび／またはユーザー入力に応答して取得されるデータおよび他の患者データソースから取得されるデータ由来の他のタイプおよび形態の縦断的な患者データ（たとえば、図１の縦断的なエピソードデータ１３２およびコンセプトデータ１３６）を含んでもよい。
【００３８】
また、フェーズ資料化システム２００は、縦断的なデータにおける連続するフェーズ間の逸脱を検出するための逸脱検出部２２４も含む。たとえば、逸脱検出部は、施術前フェーズ２０２のデータエレメント２１４と、次のフェーズすなわち施術中フェーズ２０４のデータエレメント２１６とを比較可能である。この比較によって、データエレメント間に、たとえば縦断的なケアの連続したフェーズ間のフェーズ間逸脱を反映した変更や削除または追加に相当するような不一致が認められたら、逸脱検出部２２４は、リクエスト生成部２２６に、ヘルスケア提供者から（たとえば、ＧＵＩ２２２経由で）検出された逸脱に関する追加の情報を要求させる。いくつかの例では、リクエストの正確な内容が、フェーズ２０２と２０４または２０４と２０６との間で検出されるフェーズ間逸脱によって変わることがある。
【００３９】
一例として、施術中フェーズ２０４の一部として、介護者は、施術前フェーズ２０２からのデータエレメント２１４がまず明確になり、施術中フェーズ２０４用のデータエレメント２１６として格納されるように、施術前の計画を受け入れることができる。施術中または施術後、介護者または他のユーザーは、エディター２２０を利用して、施術中に起きたことをもとに、１つまたは２つ以上のデータエレメント２１６を追加、削除および／または改変することができる。データエレメント２１６の編集のいくつかは、たとえば施術中フェーズ２０４の準備段階など、施術前になされてもよい。逸脱検出部は、施術前フェーズ２０２のデータエレメント２１４と、施術中フェーズのデータエレメント２１６とを比較して、当該データエレメント間で判断された差が説明を必要とするタイプの不一致であるか否かを判断し、リクエスト生成部２２６に、検出された不一致に関するさらなる詳細を要求させるようプログラム可能である。あるいは、データエレメント２１４と２１６との間の差が、そうでなければ一貫している記述子（たとえば、行動、機器、サービス、診断を表すデータエレメントなど）の具体的な内容のレベルに相当する状況では、逸脱検出部２２４は、リクエスト生成部にトリガーを出さずに、逸脱を存在させておくことができる。よって、逸脱検出部２２４は、想定される縦断的な標準のケアと一致したままのフェーズ間の一層高いレベルで特定することと比較して、あるフェーズから次のフェーズまで変化した、あるカテゴリーの診断または治療に関連する不一致のタイプを区別するようプログラム可能である。
【００４０】
一例として、データエレメント２１４、２１６、２１８が、複数の桁を有する本明細書に開示したようなコード化データエレメント（たとえば、ＩＣＤコード、ＤＲＧコード、ＣＰＴコードなど）であって、最初の（または最後の）桁部分が一般的なカテゴリーの記述子に関連し、桁の残りの部分が一層具体的な内容（たとえば、場所、解剖学的部位、病因、手法、使用する機器など）と関連するコード化データエレメントに対応する場合、逸脱検出部２２４は、情報のリクエストをさせることなく、さらに具体的な内容を説明する桁の一部に変更および追加を許容するようプログラム可能である。あるいは、逸脱検出部２２４は、リクエスト生成部に追加の情報をリクエストさせることなく、カテゴリー記述子の桁に対する変更、特定することを記載する記述子の、特別な（あらかじめ定められた）変更またはその両方を可能にするルール（たとえばロジック）をもとに、プログラム可能である。このような不一致のない検出された変更は通常、後のフェーズにおけるコードが想定される変更の範囲内にあるようなタイプのものではなく、代わりに、一貫性を維持するのに想定されるであろうよりも大きな量の変更を示している。変更量と不一致であるとして検出可能な具体的な変更内容は、（たとえばユーザー入力に応答して）組織の標準または他の標準に基づくなどしてプログラム可能である。さらに別の例として、逸脱検出部２２４は、リクエスト生成部に対して、カテゴリー記述子の桁に対する特定の変更、具体的な内容の記述子の桁に対する特定の（たとえば、あらかじめ定められた）変更またはその両方（これらは、当該変更各々に関する詳細事項のユーザー入力を要求させることにつながる）を検出するルールをもとにプログラム可能である。
【００４１】
別の例として、逸脱検出部２２４は、施術前フェーズ２０２のコード化データエレメント（たとえば、カテゴリー記述子に対応するあらかじめ定義された最上位桁のセット）２１４から桁のサブセットを選択するようプログラム可能である。逸脱検出部２２４は、選択されたサブセットの桁をテンプレートとして利用でき、そこでは、それぞれのコード化データエレメントの残りの桁（一層具体的な内容の記述子に対応）が施術中フェーズ２０４の対応のデータエレメント２１６に適用可能な「気にしない」値として作用する。たとえばＩＣＤ−９では、最初の３桁をテンプレートとして利用でき、この場合、残りの２桁が「気にしない」フィールドとして作用する。ＩＣＤ−１０標準のうちの１つに従ってコード化されたデータエレメントでは、逸脱検出部２２４によって、最初の３桁または４桁（たとえば、コードのカテゴリーの先頭）をテンプレートとして利用することができ、さらに詳細な内容を提供する残りの３桁または４桁が、後のフェーズ２０４で通常はさらに詳細なデータエレメント２１６に適用される気にしない値であってもよい。
【００４２】
たとえば、施術前フェーズ２０２に対応する計画の一部として、（たとえば１つまたは２つ以上のデータエレメント２１４における）縦断的なデータ２０８で特定タイプのインプラントが識別され、（たとえば１つまたは２つ以上の対応のデータエレメント２１６における）縦断的なデータ２１０にて指定される施術中フェーズ２０４に、異なるインプラントが実際に埋め込みされるおよび／または異なる位置に埋め込みされる場合、逸脱検出部２２４は、背景にあるデータエレメント（たとえば施術コード化データ）を比較して、比較結果をもとに不一致が存在するか否かを判断することができる。不一致が存在する場合、逸脱検出部２２４は、リクエスト生成部２２６に、ＧＵＩ２２２を介して、ユーザーに対するリクエストを提示させることができる。ＧＵＩ２２２は、なぜ異なるインプラントを使用したのかということについての説明を入力するようにとのリクエストをユーザーに与えることができる。ＧＵＩ２２２は、ユーザー入力に応答して、この説明をメモリーに格納できる。当該説明は、たとえば、不一致であると判断された対応のデータエレメントとプログラム的に関連したメモとして（たとえばテキストフィールドとして）追加できる。リクエスト生成部２２６は、不一致が存在することを逸脱検出部が判断する都度、対応のリクエストをリアルタイムで（たとえばポップアップウィンドウとして）発行するようプログラム可能である。あるいは、リクエスト生成部２２６は、後からのフェーズが終了した後に（たとえばユーザー入力に応答して）逸脱検出部２２４によって検出されたような複数の異なるフェーズ間不一致についての追加の詳細事項を与えるために、対応のリクエストをリアルタイムで（たとえばポップアップウィンドウとして）発行するようプログラム可能である。
【００４３】
施術中フェーズ２０４用の縦断的なデータ２１０を、施術中に、たとえばオペレーティングルーム内で実装可能な１つまたは２つ以上の他のデータソース（たとえば、在庫追跡システム、麻酔監視システムなど）によって、リアルタイムまたはほぼリアルタイムにアップデートしてもよい。このような他のデータソースは、図１のシステム１００にインターフェース可能であり、拡張すれば、対応のアプリケーションインターフェース（ＡＰＩ）を用いてシステム２００にもインターフェース可能である。よって、対応のデータエレメント２１６も、これらの他のデータソースからの情報のみならず、たとえばエディター２２０を用いてユーザーが入力する情報をもとに、アップデート可能である（たとえば、新たなデータエレメントを追加し、既存のデータエレメントを削除または改訂できる）。データエレメントがアップデートされたら、このアップデートによって逸脱検出部を起動することが可能であり、あるいは、バックグラウンドのプロセスとして検出部を連続的に動作させてもよい。本明細書で開示するように、データエレメントは、ＥＨＲに格納された患者のエピソードデータに対応可能である。よって、１つまたは２つ以上のデータエレメントに対してなされるアップデートに応答して、このようなアップデートを、ＥＨＲシステム（たとえば、図１のＥＨＲシステム１１６）に送信することができる。
【００４４】
図３は、図１の縦断的ケアシステム１００のさまざまなフェーズに関連して実装可能な予測システム３００の一例を示す。予測システム３００は、縦断的なケア施術に関連する複数のフェーズ３０２、３０４、３０６各々に関連するアウトカムおよびリスクの予測を助けるようプログラムされる。図３の例では、一貫性を保つために、フェーズ３０２、３０４、３０６は、図２の例におけるフェーズと実質的に同一のものとして示されている。簡単に説明すると、システム３００は、施術前フェーズ３０２、施術中フェーズ３０４、施術後フェーズ３０６を含む。各フェーズ３０２、３０４、３０６は、縦断的なヘルスケアエピソードを集合的に特徴付ける複数のデータエレメント３１４、３１６、３１８を含むそれぞれの縦断的なデータ３０８、３１０、３１２を含む。いくつかの例では、データエレメント３１４、３１６、３１８は、図２を参照して本明細書に開示されているものなどのコード化データを含んでもよい。たとえば、予測出力をコンピューターで求める際に予測エンジンによって利用されるデータエレメントは、たとえばＥＨＲシステム（たとえば図１のＥＨＲシステム１１６）から得られる、併存疾患、患者の病状、診断、医薬品などをはじめとして、縦断的なケアの、あるフェーズでの問題リストデータエレメントを含んでもよい。
【００４５】
システム３００は、予測エンジン３２０を含む。予測エンジン３２０は、ある患者についてのケアの縦断的なエピソードの各フェーズ３０２、３０４、３０６に対する１つまたは２つ以上の予測出力３２８をコンピューター計算するようプログラムされる。予測エンジン３２０は、１つまたは２つ以上の選択された予測モデル３２４を、ある患者についてのフェーズデータエレメント３１４、３１６、３１８に適用することで、予測値をコンピューター計算するようプログラム可能である。同一の予測をモデル３２４の共通のセットをもとにそれぞれのフェーズに対して行うことができるが、これらの同一の予測は、各フェーズで利用可能な縦断的なデータ３０８、３１０、３１２に従ってアップデート可能である。他の例では、ＧＵＩ３２２を介したユーザー入力に応答するなどして、たとえばそれぞれのフェーズでモデル３２４の独立に選択されるセットに従って、各フェーズ３０２、３０４、３０６での予測が異なっていてもよい。たとえば、予測出力３２８の最初のセットを、入院時に利用可能な縦断的なデータ（たとえば患者データエレメント）に基づくなどして、ある患者について入院時にコンピューター計算してもよい。各フェーズ３０２、３０４、３０６の間に、縦断的なデータをもとに、追加のコンテキストデータの収集に応答するおよび／または予測エンジンを起動するユーザー入力に応答するなどして、１つまたは２つ以上の追加の予測をコンピューター計算して、それぞれのアウトカムおよび／またはリスクを予測するためのモデルの１つを選択することができる。
【００４６】
別の例として、各モデル３２４は、データエレメントのあらかじめ定められたセットに対応する予測（predictor）変数と、あるモデルが作成された特定のアウトカムの尤度を予想するために求められた係数のセットを含んでもよい。よって、それぞれのフェーズに対するデータエレメント３１４、３１６または３１８は、予測をコンピューター計算すべく、あるモデルに入力可能である。上述したように、データエレメント３１４、３１６または３１８は、それぞれのフェーズに対する問題リストデータエレメントに対応してもよい。利用可能なデータエレメント３１４、３１６または３１８と選択された１つ以上のモデル３２４の予測（predictor）変数との一致度が大きいほど、コンピューター計算された予測出力３２８の精度も高い。いくつかの例では、予測（predictive）変数は、それぞれのフェーズ３０２、３０４、３０６に対して縦断的なデータ３０８、３１０、３１２を与える利用可能なデータエレメント３１４、３１６、３１８のサブセットに対応してもよい。予測モデル３２４は、３２６で示すデータベースまたは他のデータ構造で格納可能である。他の例では、モデルをネットワークに分散させ、分散モデルに対するアクセスを与える適切なインターフェースを実装しているシステム３００によってアクセス可能である。
【００４７】
図３の例では、予測エンジン３２０は、１つまたは２つ以上の予測モデル３２４を選択するためのモデル選択部３３０を含む。予測モデル３２４については、いくつあってもよい。モデル選択部３３０は、予測すると望ましい場合があるアウトカムのタイプおよびアプリケーションの要件に応じて、１つまたは２つ以上の予測モデル３２４を選択できる。関連のあるいくつかのアウトカムの例として、患者の入院期間（ＬＯＳ）、患者の満足度、患者の診断、患者の予後、主要な合併症のリスク、軽い合併症のリスク、死亡リスク、再入院リスク、患者のリソース利用あるいは、ヘルスケア提供者、患者またはヘルスケア施設に関連する場合がある他の任意の患者アウトカム情報があげられる。予測エンジン３２０は、あるフェーズ３０２、３０４または３０６に対して縦断的なデータ３０８、３１０、３１２をもとに識別可能な施術による合併症のリスクを含むなど、ある患者の状況に特有のアウトカムまたはリスクをコンピューター計算することもできる。また、あるアウトカムを予測するための、あるモデルのインスタンスが複数あってもよく、各インスタンスが、患者に対するケアの縦断的なエピソードの、あるフェーズの入力データエレメント３１４、３１６、３１８によって変わってもよい。よって、モデル選択部３３０は、データエレメントの利用可能なセットをもとにモデル３２４を（たとえば、重みおよび係数を用いて）選択し、構成することができる。
【００４８】
計算部３３２は、モデルインスタンスに入力されるデータエレメント３１４、３１６、３１８をもとに、選択された各モデルに対する予測出力３２８をコンピューター計算することができる。得られる予測出力３２８は、メモリーに格納可能である。いくつかの例では、各予測出力は、コンピューター計算の対象となったフェーズ３０２、３０４、３０６のデータエレメントとしても格納可能である。コンピューター計算される各予測出力３２８は、縦断的なケアのそれぞれのフェーズに利用される患者のレコードに格納されるドキュメントの一部となってもよい。よって、ケアの縦断的なエピソードの過去に遡るレビューに、関連のデータエレメントの評価のみならず、コンピューター計算された予測出力の評価を含んでもよい。
【００４９】
また、予測エンジン３２０は、予測出力３２８を評価するようプログラムされた評価部３３４を含んでもよい。たとえば、評価部３３４は、コンコーダンスインデックスまたは信頼値など、各予測出力３２８に対する精度の指標をコンピューター計算可能である。コンピューター計算された精度の指標は、予測出力３２８の一部として与えることが可能な予測に対する評価データを与えてもよい。そのコンピューター計算された評価を含む予測出力３２８は、予測出力と一緒にＧＵＩ３２２経由でユーザーに提示可能である。その評価を含む各予測出力は、コンピューター計算の対象となったフェーズ３０２、３０４、３０６のデータエレメントとしてメモリーにも格納可能であり、これは、（たとえば、図１のＥＨＲシステム１１６における）患者のレコードの一部に提供し、当該一部として格納可能である。
【００５０】
また、システム３００は、予測出力（たとえば、予測されたアウトカムおよび関連の精度の指標を含む）に基づいて、個々にまたはまとめて、１つまたは２つ以上の推奨行為３３８を決定するようプログラムされるリスクアナライザー３３６を含んでもよい。リスクアナライザー３３６は、予測出力をもとにリスクを求め、このリスクに応じて、関連の相談および／または指示群（たとえば、１つまたは２つ以上の検査室または他の試験用）に対する推奨３３８を自動的に生成するようプログラムされるアクション生成部３４０を含んでもよい。推奨行為３３８の内容は、ＧＵＩ３２２によってユーザーに提示できる。ユーザーはたとえば、ＧＵＩ３２２によってユーザー入力が入力されることに応答して、推奨内容を許容（たとえば承認）できる。たとえば、あらかじめ定められた信頼閾値内で心臓の問題の十分な尤度が予測出力によって示された場合に、ＧＵＩ３２２によって、心臓専門医に対する相談を推奨し、承認することができる。推奨行為に応じた権限のあるユーザー入力に応答して、承認または非承認のドキュメントを縦断的なケアのそれぞれのフェーズにおける新たなデータエレメントとしてメモリーに格納してもよい。このようなドキュメントをさらに、（たとえば図１のＥＨＲシステム１１６における）患者のレコードに与えることもできる。相談またはオーダーが承認されて許容されると、受け入れられたことの資料化だけでなく、承認によって、このような相談のスケジューリングをするようにとのリクエストをスケジューリングシステムに自動的に与えることができる。また、受け入れられた指示群または処方箋は、受け入れられた指示内の必要物と矛盾の無いように施行するための、規定の検査室または他の対応の施設（たとえば薬局）に自動的に提出されてもよい。自動作成用に利用可能な指示群がない場合、ユーザーは、ＧＵＩ３２２を利用し、ユーザー入力に応答して指示群または処方箋のリクエストを作成できる。得られる指示群および／または処方箋は、同一またはほぼ同一のリスクを示す将来の予測時における指示群としての推奨用にメモリーに格納可能である。
【００５１】
予測出力３２８を相応の精度ではコンピューター計算できない状況では、リスクアナライザー３３６は、システム３００が十分な確かさでリスクレベルを特定できないことを示す出力をＧＵＩ３２２に送信できる。これは、たとえば、患者が極めて稀な病状で、許容可能なモデルを生成するのに適切なサンプル集団が得られないような場合に起こり得る。送信される出力は、ある患者に対する縦断的なケアのそれぞれのフェーズ３０２、３０４、３０６を資料化するために、データエレメント３１４、３１６、３１８の一部として、メモリーに格納可能である。格納された出力は、好適なリスク評価をコンピューター計算できないことに関する状況を資料化するために、（たとえば、図１のＥＨＲシステム１１６の）患者のレコードにも格納可能である。
【００５２】
予測出力３２８およびリスク分析の結果を、施術前フェーズ３０２をもとに計画された施術に対する患者の承諾書３４８を作成する際に、承諾作成部３４６（たとえば図１の承諾作成部１４２に相当）によって利用することも可能である。上述したように、承諾書３４８は、プレインテキストの印刷文書には限定されず、１つまたは２つ以上の（たとえば、ＨＴＭＬのようなマークアップ言語に沿って作成されるものなどの）ウェブページといった電子文書を含んでもよい。それ自体、文書は、詳細情報、画像および／または映像へのリンク（たとえば、ＵＲＬまたは他のリソースロケーション）を含んでもよく、これは、施術前フェーズ３０２の患者の縦断的なデータ３１４をもとにデータライブラリーから具体的に選択して、その患者用にアセンブル可能である。
【００５３】
また、施術前フェーズ３０２に対してコンピューター計算される１つまたは２つ以上の予測モデル各々に対する予測出力３２８が、作成される承諾書３４８に含まれてもよい。本明細書で開示するように、承諾作成部３４６は、ヘルスケア提供者と患者との間の対面でステップバイステップでの施術前相談で導き出されるものを含む一組のデータエレメントをもとに、ユーザー入力に応答して、承諾書３４８を構成できる。よって、このような相談では、患者の懸案となっている問題リストや関連の検査結果などに対するグラフィックツール（たとえば図１のグラフィックツール１０２）のみならず、当該問題リストや検査結果などに基づくグラフィックツールも利用できる。承諾書は、ある患者に対する縦断的なデータ３０８をもとに作成される（これは、コンテキストデータ１０４に基づいて、図１のＧＵＩ１２６との間のユーザーインタラクションに応答してもよい）ため、得られる承諾書３４８および関連の予測出力３２８を、その患者に合わせて、当該患者のデータエレメント（たとえば、懸案となっている問題のリストデータ）３１４の独特なセットをもとにカスタマイズすることが可能である。本明細書で開示するように、患者のレコードの一部を形成するケアの縦断的なエピソードの施術前フェーズをドライブするデータエレメント３１４も完全かつ正確な入力データセットとなり、これに基づいて、承諾作成部３４６は承諾書３４８も構成する。
【００５４】
（たとえばデータエレメント３１４として）メモリーに格納され、施術前フェーズ３０２に対する患者のレコードの一部を形成する承諾書だけでなく、患者に代わって行動する患者または個人（たとえば家族のメンバー）も、患者のＧＵＩ３５０を介して承諾書に関わり合うことができる。複数のページ（たとえばウェブページ）の各々を閲覧することをはじめとしてＧＵＩ３５０による承諾書に対するユーザー入力のインタラクションに応答する縦断的なデータは、フェーズ３０２用のコンテキストデータエレメント３１４としてメモリーに格納可能および／またはＥＨＲシステムにおける患者のレコードに格納可能である。ユーザー入力のインタラクションに応答するデータは、あるページが閲覧されたこと、そのページが閲覧された時点、そのような閲覧にかかった時間のみならず、文書３４８に対する他のインタラクションを識別するデータを含んでもよい。承諾書３４８の閲覧と、承諾書に提示された情報に対する関連のユーザーインタラクションをさらに資料化するために、ページまたは段落に提示された内容の確認、映像および画像の閲覧も、ユーザー入力に応答して記録可能である。承諾書３４８の対応の印刷版も作成可能であり、そこには、施術計画と計画された施術に伴うリスクに対する患者の理解を書面で確認するための署名ラインを含んでもよい。文書を印刷することに関わるデータも、たとえば患者に対するケアの縦断的なエピソードのインフォームドコンセントフェーズに対応する関連の縦断的なデータの一部として格納可能である。
【００５５】
施術計画に対する承諾書の１つまたは２つ以上の部分が、ＧＵＩに対するヘルスケア提供者によるインタラクションを含んでもよいし、このようなインタラクションをもとに導かれるものであってもよい。本明細書で開示するように、たとえば、提供者−ユーザーインタラクションは、施術前フェーズ用のデータエレメント３１４として格納される縦断的なエピソードデータに変換される別々のコンセプトに対応してもよい。よって、提供者がＧＵＩを用いて施術についてグラフィカルにステップバイステップで説明する際に、対応のコンセプトおよび選択されたオプションを、相談中にリアルタイムで患者にグラフィカルに提示されるケアの縦断的なエピソードのデータエレメントに変換できる。メモリーに格納される、得られる縦断的なエピソードのデータエレメント３１４は、承諾作成部３４６によってアクセスして、開示されているものなどの格納されたデータエレメントから承諾書３４８を直接構成することが可能である。結果として、承諾書３４８は、少なくとも一部は、提供者のインタラクションに応答して施術前の入院患者との相談中に作成された同一のデータエレメント３１４（たとえば、患者特有の縦断的なケアエレメントに変換されるコンセプト）をもとに導き出されることになる。
【００５６】
上述したように予測エンジンを施術前フェーズ３０２に適用することに加えて、予測エンジン３２０はさらに、ケアの縦断的なエピソードの他のフェーズ３０４および３０６に対する（たとえば選択されたアウトカムおよびリスクの）予測をコンピューター計算するようプログラム可能である。いくつかの例では、施術前フェーズ予測のいくつかまたはすべてを、定期的に（たとえば、入院後毎日、４時間ごと）アップデートしてもよいし、患者の新たなヘルスケアデータまたはアップデートされたヘルスケアデータ（たとえば、新たな試験、試験間の傾向など）の取得に応答してアップデートしてもよい。また、予測エンジン３２０は、施術前フェーズから施術フェーズまたは施術フェーズから施術後フェーズなど、患者がひとつのフェーズから次のフェーズに移る際に、予測をコンピューター計算するようプログラム可能である。上述したように、コンピューター計算されるモデルおよび予測出力は、各フェーズで縦断的なデータおよび関連のコンテキストデータをもとに選択された、あらかじめ選択された予測セットであってもよい。あるいはまたはそれに加えて、ある患者に対する選択されたアウトカムまたはリスクを予測するために提供者が予測エンジンを呼び出すなどのユーザー入力に応答して、１つまたは２つ以上の予測を動的に実行してもよい。予測出力は各々、（たとえば図１のＥＨＲシステム１１６における）患者のレコードの一部として格納可能な、縦断的なケアの、あるフェーズに対する対応のデータエレメントとして、メモリーに格納可能である。
【００５７】
図１から図３のシステムおよび機能との関連で開示した例に対する追加のコンテキストを提供するために、図４から図２０は、ケアの縦断的なエピソードの施術前フェーズの一部など、施術計画を作成するのに使用可能な手法を示すためのＧＵＩの例（たとえば図１のＧＵＩ１２６）を示す。図４から図２０の例は、心臓手術すなわち心臓弁置換のコンテキストにおける単純な例を示している。図４から図２０に示す手法は、ＧＵＩオブジェクトとの間のユーザーインタラクションに応答して作成可能な例であり、たとえば、提供者と患者との間での入院患者との相談の一部であってもよい。このため、患者のインタラクションを、ケアの縦断的なエピソードにおけるインフォームドコンセントフェーズの一部として格納可能である。本明細書に開示のシステムおよび方法は、本例または外科手術計画の例に限定されるものではないことは、理解し、認識されたい。たとえば、本明細書に開示のシステムおよび方法を、他のタイプの外科手術に適用してもよく、入院患者および／または外来患者のケアを含む任意のタイプの医療的治療術のケアの縦断的なエピソードを管理および資料化しやすくするのにさらに等しく適用可能である。また、本明細書で開示するように、図４から図２０に示すＧＵＩとの間の各ユーザーインタラクションは、対応のコンセプトに変換される。これは、患者のケアの縦断的なエピソードに関連した口頭によるあるいは記述した文字列、グラフィックなどを含んでもよい。ＧＵＩによって各ユーザーインタラクションに応答して与えられる別々のコンセプトを、患者のケアの縦断的なエピソードにおける、あるフェーズに対するデータエレメントとしてメモリーに格納してもよく、このデータエレメントをさらに、患者用の電子カルテに加えてもよい。
【００５８】
図４は、胸腔の表現を示した例示的なＧＵＩ４００を示す。線４０２は、胸骨切開術用の切開部のコンセプトを示し、これはたとえば、入力装置（たとえば、タッチスクリーン、マウスなど）を用いて入力されるユーザー入力に応答してＧＵＩ４００上に引くことができ、所望の位置に動的に表すことができる。切開部をグラフィカルに表示するだけでなく、本明細書で開示するように、このような別々のコンセプトに対する対応のコード化データエレメントをメモリーに格納してもよい。
【００５９】
図５は、切開部に対応するユーザー入力に応答してＧＵＩ４００上に表現できる体内のいくつかの解剖学的構造を示す。切開線４０２付近の体内の解剖学的構造は、すべての患者に共通するものであってもよいし、患者データエレメントに基づく解剖学的構造のコンテキスト駆動型のセットを含んでもよい。
【００６０】
図６では、胸骨切開術の一部として、外科手術の対象となる心臓を表した部分に到達する空間を示すことで、胸骨を分割して（または「割って」）示してある。図４から図６へのＧＵＩの遷移は、たとえば複数のフレームでアニメーション表示可能である。胸骨切開術をグラフィカルに表示するだけでなく、この手法に対する対応のコード化データエレメント（たとえば、ＩＣＤ−９−ＣＭ、ＩＣＤ−１０またはＣＰＴコード）を、施術のこの部分に関連するメモリーに格納してもよい。
【００６１】
この例では施術が心臓弁置換を（たとえば、図１のエピソードコンテキストデータ１０８および関連のコンセプトデータ１３６において反映されるものとして）含むものであるが、図６に続いて、システムは、図７に示すような一組のツール４２４と一緒に心臓４２２のグラフィック表現を含んでもよいＧＵＩ４２０を作成できる。これらのツールは、本明細書に開示するように、縦断的なデータおよび提供者の好みのデータに基づいて、特定に対して選択可能な一組のオプションと対応してもよい。各ツール４２４は、心臓に関連する行為をするための（たとえば入力装置による）ユーザー入力に応答して操作可能なインタラクティブなＧＵＩエレメントであってもよい。たとえば、図８では、心臓にアクセスするための想定される手法をシミュレートするためなどで、メスのＧＵＩエレメント４２６を選択可能である。所望のツールがＧＵＩに示されていなければ、「その他」オプションのＧＵＩエレメント４２８をアクティブにして、さらに豊富なツールのリストを出力するようにしてもよい。
【００６２】
心臓にアクセスする、あるいは、ある施術の別の部分を行うなどのために、選択されたツールを使用した後、ＧＵＩ４３０は、図９に示すような心臓の解剖構造４３２の切断図を含むよう生成されてもよい。この段階で、異なる弁タイプ（たとえば、機械弁、生体弁、フリースタイル弁または同種弁）４３４に対応する一組のＧＵＩエレメントを、インタラクティブオブジェクトとして、ＧＵＩ４３０上に表示することができる。ユーザーは、患者データおよび患者との相談によって変わることがある、選択された弁タイプのＧＵＩエレメントをアクティブにすることで、所望のタイプの弁を選択して、選択された弁を所望の埋め込み部位（たとえば、大動脈弁輪）に配置することができる。ある弁タイプを選択すると、さらに、たとえば弁のタイプ、埋め込み位置、ユーザーが選択した手法の他の関連の記述子を指定するために、メモリーに格納可能な対応のコード化データが生成されてもよい。いくつかの例では、製造業者、型版、大きさなど、選択されたインプラントで想定される追加の詳細内容を、提供者から引き出すことができる。このような追加の情報を在庫管理システムに送信して、選択されたインプラントおよび関連の機器の在庫があり、スケジュールどおりの施術で確実に利用できるようにしやすくしてもよい。
【００６３】
図１０および図１１は、心臓４４２のグラフィック表現と、ユーザー入力に応答して選択可能なペーシングワイヤーを含むツール用の１つまたは２つ以上のＧＵＩエレメント４４４と、を含む、ＧＵＩ４４０の例を示す。たとえば、図１１に概略的に示すような洞房結節などで、計画された施術の一部としての患者の心臓ペーシングのコンセプトを表すよう心臓に配置可能なペーシングワイヤーのＧＵＩエレメント４４４。よって、本明細書で開示するように、ペーシングリードを選択して心臓にドラッグするグラフィックでのインタラクションに応答して、ペーシングの別々のコンセプトを求めることができる。この別々のコンセプトをさらに利用して、患者の心臓の計画されたペーシング用の対応のデータエレメント（たとえばＩＣＤまたはＣＰＴコード）のみならず、選択されたペーシングリードと施術のこのような部分を行うのに必要になり得る他の関連の機器用の１つまたは２つ以上のコードを生成する。
【００６４】
図１２は、心臓４５２のグラフィック表現のみならず、施術時に行うことができる異なる測定用の一組のオプションをリストにしたＧＵＩエレメント４５４も含む、ＧＵＩ４５０を示す。図１２の例では、ＧＵＩエレメントは、患者の心電図を得るための異なる手法を表すことができる。よって、ユーザーは、ユーザー入力に応答して、施術用に計画された測定手法を選択可能であり、こうしたユーザーによる選択によっても、選択された手法を行うための当該手法および機器を指定する１つまたは２つ以上の対応のコード化データエレメントを生成できる。コード化データエレメントは、メモリーに格納可能である。
【００６５】
図１３および図１４は、施術時に患者に薬剤を投与するか否かを選択するのに利用可能なＧＵＩ４６０を示す。ユーザーは、ユーザー入力に応答してオプションを選択可能である。図１４では、図１３でのユーザー入力に応答して、ＧＵＩ４６０は、使用してもよい１種または２種以上の異なるタイプの薬剤を識別するためのＧＵＩエレメント４６２を表示する（たとえば、ユーザーの好みに基づいて選択される）。選択された薬剤各々で想定される用量についても、必要があれば、当該薬剤に関連した入力ＧＵＩエレメント４６２を用いてユーザーが指定できる。ある薬剤が望ましいが図示されていない場合、ユーザーは、ＧＵＩ４６０に含まれていてもよいユーザー入力ダイアログボックスで、あるいは、他のオプションのリストから、その所望の薬剤を入力できる。選択される薬剤ごとに１つまたは２つ以上のデータエレメントを生成して、提供者によるその選択について示すドキュメントと一緒に、メモリーに格納可能である。
【００６６】
図１５から図１７は、施術の一部としての胸腔チューブの計画されている用途で使用可能なＧＵＩ４７０の異なる態様を示す。図１５の例では、ＧＵＩ４７０は、標準タイプの胸腔チューブ（たとえば、ネイティブライン（ＮＬ））または１つまたは２つ以上の他のタイプなど、胸腔チューブのタイプを選択するユーザー入力に応答してアクティブにできるＧＵＩエレメント４７２を含む。図１６に示されるように、たとえば、ＧＵＩエレメント４７２（図１５）で異なるタイプの胸腔チューブが選択されると、ＧＵＩ４７０は、（たとえばキーボードまたは口述で）対応の自由形式の説明を入力するためのダイアログボックス４７４を表示できる。ダイアログボックス４７４の情報は、ユーザーが選択したオプションについての詳細を決定するよう説明可能であり、これはさらに、施術計画のこの部分と関連するメモリーに格納される対応のコード化データエレメントに変換可能である。図１７に示されるように、図１５のＧＵＩ４７０で標準タイプのチューブが選択されると、ＧＵＩは、一組のＧＵＩエレメント４７６を表示できる。よって、ユーザーは、ＧＵＩエレメント４７６のうちの１つを選択して、所望のタイプのチューブを識別でき、この選択を、異なるチューブタイプのうち選択された１つを表すデータエレメント（たとえば、施術コードおよび１つまたは２つ以上の在庫コードを含む）に変換してもよい。
【００６７】
図１８および図１９は、施術用のクロージャーのタイプを計画するためのＧＵＩ４８０を示す。図１８の例では、ＧＵＩ４８０は、標準のクロージャーまたは標準ではないクロージャーなど、クロージャーのタイプを選択するためのＧＵＩエレメント４８２を含む。ＧＵＩによって提示されるクロージャーオプションのタイプは、患者および提供者の好みなどを含む本明細書に開示された縦断的なデータに基づいて選択可能である。標準ではないクロージャーが選択されると、ＧＵＩは、ダイアログボックスまたは他のユーザー入力メカニズム４８４を表示でき、これを使ってユーザーは、図１９に示すように計画されたタイプのクロージャーを指定することができる。この選択と他のユーザー入力を、計画された施術に対する１つまたは２つ以上のデータエレメントとしてメモリーに格納してもよい。
【００６８】
（たとえば図４から図１９に示すものなどの）計画された施術用の手法が完了したら、ユーザーは、計画を終了するためのＧＵＩを用いたユーザー入力に応答してそれを示すことができる。あるいは、ユーザーは、計画されたアイテムのいずれかに戻り、選択された手法を修正してもよい。ユーザーによって計画が終了し、患者によって受け入れられたら、システムは、終了した計画をメモリーに格納できる。本明細書で開示するように、これは、施術の異なる部分に対するさまざまなデータエレメント（たとえば施術コードおよび／または在庫コード）を含んでもよい。一例として、図２０は、計画プロセスの間にユーザーインタラクションに応答して施術の識別されたステップ４９２に対する対応の計画の表現を提示するＧＵＩ４９０を示す。識別されたステップ４９２は各々、たとえば、ユーザーがそれぞれを選択することに応答して、関連のグラフィックおよび／または映像にアクセスするのに利用できる実装可能なＧＵＩエレメントであってもよい。施術前の計画および関連のデータエレメントも、ケアの縦断的なエピソードデータの一部として（たとえば、施術前フェーズの一部を形成する）メモリーに格納可能である。施術中フェーズの間、施術時に用いられる実際の手法と機器を反映させるよう、さまざまなステップを許容または修正することができる。本明細書で開示するように、計画された施術からの逸脱を（たとえば図２の逸脱検出部２２４によって）検出して、計画からのそれぞれの逸脱に関する説明的なデータをヘルスケア提供者または関連の人物から集めるための方法および機能を呼び出すことができる。よって、システムは、不一致について説明し、ケアの縦断的なエピソードに対する患者のレコードの一部を形成するよう要求することによって、ひとつのフェーズから次のフェーズへのデータの矛盾を排除する助けとなる。
【００６９】
また、（たとえば図１の承諾作成部１４２または図３の承認作成部３４６によって）施術前の計画を利用して、本明細書に開示されているような患者の承諾書を作成してもよい。相談時に表示されるグラフィック表現およびビデオ画像が、承諾書の一部であってもよい。いくつかの例では、ライブでの患者の相談を記録して、記録された相談（またはそれを編集したもの）を承諾書の一部として提供してもよい。計画データ（計画された施術における手法に対するデータエレメントおよび縦断的な患者データ、たとえばコード化された患者データおよび他の関連の患者コンテキストデータを含む）に基づいて、１つまたは２つ以上の予測を（たとえば、図１の予測エンジン１４４または図３の予測エンジン３２０によって）コンピューターで計算し、承諾書に組み込むようにしてもよい。
【００７０】
上記の構造的または機能的な説明に鑑みて、本発明の一部を、方法、データ処理システムまたはコンピュータープログラム製品として実施してもよいことは、当業者であれば自明であろう。したがって、本発明のこのような一部は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態あるいは、図２１のコンピューターシステムで図示し、説明するような、ソフトウェアとハードウェアとを組み合わせた実施形態の形をとってもよい。さらに、本発明の一部が、媒体上にコンピューター読取り可能なプログラムコードを有する、コンピューター使用可能な記憶媒体上のコンピュータープログラム製品であってもよい。好適なコンピューター読取り可能な媒体であれば、どのようなものを利用してもよく、一例として、静的記憶装置および動的記憶装置、ハードディスク、光学記憶装置および磁気記憶装置があげられるが、これらに限定されるものではない。
【００７１】
本明細書では、方法、システムおよびコンピュータープログラム製品のブロック図を参照して、本発明の実施形態についても説明してきた。図示のブロックならびに、図示のブロックの組み合わせを、コンピューターで実行可能な指示によって実装してもよいことは、理解できよう。これらのコンピューターで実行可能な指示を、汎用コンピューター、専用コンピューターあるいは、マシンを製造するための他のプログラム可能なデータ処理装置（または装置と回路の組み合わせ）の１つまたは２つ以上のプロセッサーに対して、プロセッサーによって実行する指示が１つまたは複数のブロックに示される機能を実装するよう供給してもよい。
【００７２】
これらのコンピューターで実行可能な指示は、コンピューター読取り可能なメモリーに格納された指示が、フローチャートの１つまたは複数のブロックに示される機能を実装する指示を含む製品につながるように、コンピューターまたは他のプログラム可能なデータ処理装置を特定の方法で機能させることのできるコンピューター読取り可能なメモリーに格納されてもよい。また、コンピューターまたは他のプログラム可能な装置上で実行する指示によって、フローチャートの１つまたは複数のブロックに示される機能を実装するためのステップが得られるように、コンピュータープログラムの指示をコンピューターまたは他のプログラム可能なデータ処理装置にロードして、このコンピューターまたは他のプログラム可能な装置上で一連の動作ステップを実施させ、コンピューターに実装されるプロセスを生成してもよい。
【００７３】
この点に鑑みて、図２１は、たとえばグラフィックマネジメントツールを含む本発明の１つまたは２つ以上の実施形態を実行し、それによって生成される対応の情報およびグラフィックにアクセスするのに利用可能なコンピューターシステム５００の一例を示す。コンピューターシステム５００は、１つまたは２つ以上のネットワーク接続された汎用コンピューターシステム、組込型のコンピューターシステム、ルーター、スイッチ、サーバー装置、クライアント装置、さまざまな中間装置／ノードまたはスタンドアロンのコンピューターシステムに実装可能である。また、コンピューターシステム５００は、たとえば、携帯情報端末（ＰＤＡ）、ラップトップコンピューター、ポケットベルなどのさまざまなモバイルクライアントに、それが十分な処理能力を持つという前提で、実装可能である。
【００７４】
コンピューターシステム５００は、処理装置５０１と、システムメモリー５０２と、さまざまなシステム構成要素（システムメモリーを含む）を処理装置５０１に接続するシステムバス５０３とを含む。デュアルマイクロプロセッサーなどのマルチプロセッサーアーキテクチャを、処理装置５０１として使用してもよい。システムバス５０３は、多岐にわたるバスアーキテクチャーのうちのいずれかを用いる、メモリーバスまたはメモリーコントローラー、周辺機器用バス、ローカルバスをはじめとするさまざまなタイプのバス構造のうち、どのようなものであってもよい。システムメモリー５０２は、リードオンリーメモリー（ＲＯＭ）５０４と、ランダムアクセスメモリー（ＲＡＭ）５０５とを含む。コンピューターシステム５００内の要素間で情報を転送しやすくする基本ルーチンを含むＲＯＭ５０４に、基本入出力システム（ＢＩＯＳ）５０６を常駐させることが可能である。
【００７５】
コンピューターシステム５００は、ハードディスクドライブ５０７と、たとえばリムーバブルディスク５０９との間で読み書きするための磁気ディスクドライブ５０８と、たとえばＣＤ−ＲＯＭディスク５１１を読み取ったり、他の光学媒体との間で読み書きしたりするための光ディスクドライブ５１０と、を含んでもよい。ハードディスクドライブ５０７、磁気ディスクドライブ５０８、光ディスクドライブ５１０はそれぞれ、ハードディスクドライブインターフェース５１２、磁気ディスクドライブインターフェース５１３、光ドライブインターフェース５１４を介して、システムバス５０３に接続されている。ドライブと、これに関連するコンピューター読取り可能な媒体は、コンピューターシステム５００用のデータ、データ構造、コンピューターで実行可能な指示を格納する不揮発性の記憶装置となる。上述したコンピューター読取り可能な媒体の説明では、ハードディスク、リムーバブル磁気ディスク、ＣＤについて言及したが、この動作環境で、磁気カセット、フラッシュメモリーカード、デジタルビデオディスクなど、さまざまな形態で、コンピューターによって読取り可能な他のタイプの媒体を使用してもよい。さらに、このような媒体のいずれも、本発明の１つまたは２つ以上の部分を実現するためのコンピューターによって実行可能な指示を含んでもよい。
【００７６】
オペレーティングシステム５１５、１つまたは２つ以上のアプリケーションプログラム５１６、他のプログラムモジュール５１７、プログラムデータ５１８をはじめとして、多数のプログラムモジュールを、ドライブおよびＲＡＭ５０５に格納してもよい。アプリケーションプログラムおよびプログラムデータは、本明細書にて図示し、説明するような１つまたは２つ以上のセンサーからの電気データを取得し、処理し、表示するようプログラムされる機能および方法を含んでもよい。アプリケーションプログラムおよびプログラムデータは、縦断的なヘルスケアデータの計画と記録用にグラフィックベースのマネジメントツールを与えるようプログラムされる機能および方法を含んでもよい。
【００７７】
ユーザーは、１つまたは２つ以上の入力装置５２０を介して、コマンドおよび情報をコンピューターシステム５００に入力してもよい。入力装置５２０は、たとえば、ポインティングデバイス（たとえば、マウス、タッチスクリーン）、キーボード、マイク、ジョイスティック、ゲームパッド、スキャナーなどである。たとえば、ユーザーは、ドメインモデルを編集または修正するのに、入力装置５２０を用いることができる。これらの入力装置および他の入力装置５２０は、システムバスに接続された対応のポートインターフェース５２２を介して処理装置５０１に接続されることが多いが、パラレルポート、シリアルポートまたはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースによって接続されることもある。１つまたは２つ以上の出力装置５２４（たとえば、ディスプレイ、モニター、プリンター、プロジェクターまたは他のタイプの表示装置）も、ビデオアダプターなどのインターフェース５２６を介してシステムバス５０３に接続される。
【００７８】
コンピューターシステム５００は、リモートコンピューター５２８などの１台または２台以上のリモートコンピューターとの論理接続を使用して、ネットワーク環境で動作することもある。リモートコンピューター５２８は、ワークステーション、コンピューターシステム、ルーター、ピアデバイスまたは他の一般的なネットワークノードであってもよく、一般に、コンピューターシステム５００に関して説明した多くの要素またはすべての要素を含む。５３０で概略的に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）およびワイドエリアネットワーク（ＷＡＮ）を含んでもよい。
【００７９】
ＬＡＮネットワーク環境で用いる場合、コンピューターシステム５００は、ネットワークインターフェースまたはアダプター５３２を介してローカルネットワークに接続されてもよい。ＷＡＮネットワーク環境で用いる場合、コンピューターシステム５００は、モデムを含んでもよいし、ＬＡＮ上の通信サーバーに接続されてもよい。内蔵式であっても外付けであってもよいモデムは、適当なポートインターフェース経由でシステムバス５０３に接続できる。ネットワーク環境では、コンピューターシステム５００との関連で示したアプリケーションプログラム５１６またはプログラムデータ５１８あるいはこれらの一部を、リモートメモリー記憶装置５４０に格納してもよい。
【００８０】
上記にて説明してきたものは、例である。もちろん、構成要素または方法の想定できるあらゆる組み合わせを説明するのは不可能であるが、上記以外の組み合わせや順序が可能であることは、当業者であれば認識するであろう。したがって、本発明は、添付の特許請求の範囲を含めて本出願の範囲内に入る、このような変更、修飾、改変をすべて包含することを意図したものである。また、開示または特許請求の範囲で「不定冠詞ａ」「不定冠詞ａｎ」「第１の」または「もうひとつの」要素またはその等価物について言及する場合、それは、２つまたは３つ以上のこのような要素を必要とすることも排除することもなく、１つまたは２つ以上のこのような要素を含むものと解釈されるべきである。本明細書で使用する場合、「含む（includes）」という表現は、含むことを意味するが、これに限定されるものではなく、「含んで（including）」という表現は、含んでいることを意味するが、これに限定されるものではない。「もとにする、基づく（based on）」という表現は、少なくともある程度は基づいていることを意味する。
【図１】
2014533860.tif 000003
【図２】
2014533860.tif 000004
【図３】
2014533860.tif 000005
【図４】
2014533860.tif 000006
【図５】
2014533860.tif 000007
【図６】
2014533860.tif 000008
【図１０】
2014533860.tif 000009
【図１１】
2014533860.tif 000010
【図１３】
2014533860.tif 000011
【図１４】
2014533860.tif 000012
【図１５】
2014533860.tif 000013
【図１６】
2014533860.tif 000014
【図１７】
2014533860.tif 000015
【図１８】
2014533860.tif 000016
【図１９】
2014533860.tif 000017
【図２０】
2014533860.tif 000018
【図２１】
2014533860.tif 000019
【図７】
2014533860.tif 000020
【図８】
2014533860.tif 000021
【図９】
2014533860.tif 000022
【図１２】
2014533860.tif 000023
【手続補正書】
【提出日】平成26年8月1日(2014.8.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
患者のケアの縦断的なエピソードを管理するためのシステムであって、
前記患者についてのコンテキストデータを与えるようプロセッサーによって実行可能な患者データアグリゲーターと、
関連のグラフィカルユーザーインターフェース（ＧＵＩ）とのユーザーインタラクションを、対応の別々のコンセプトに翻訳するよう前記プロセッサーによって実行可能なツールマネージャーと、を備え、
前記対応の別々のコンセプトはそれぞれ、ＧＵＩ上でのユーザーインタラクションの場所とタイプに従って、あるユーザーインタラクションに由来する患者のケアの態様を表し、
前記コンテキストデータの少なくとも一部は、前記ケアの縦断的なエピソードにおける複数のフェーズに関連する患者データを含み、
前記対応の別々のコンセプトは、前記患者についての縦断的なエピソードデータの一部としてメモリーに格納され、前記縦断的なエピソードデータは、前記コンテキストデータに基づいて、かつ、前記ケアの縦断的なエピソードの資料化と管理を容易にするための前記ＧＵＩとの前記ユーザーインタラクションに応答して生成され、
前記ツールマネージャーは、前記ケアの縦断的なエピソードにおける前記複数のフェーズそれぞれの全体で、前記縦断的なエピソードデータを表す秩序立った構成で、前記対応の別々のコンセプトを一緒にプログラム的にリンクするよう前記プロセッサーによって実行可能なコンセプトエンジンをさらに含む、システム。
【請求項２】
前記縦断的なエピソードデータは、複数のデータエレメントを含み、データエレメントは、前記ケアの縦断的なエピソードにおける前記複数のフェーズのそれぞれのフェーズについて一緒にリンクされ、
前記複数のデータエレメントは、あらかじめ定められたコード化データエレメントをさらに含み、前記コード化データエレメントは各々、規定のコード標準に従って、前記患者に対する前記ケアの縦断的なエピソードのそれぞれの態様を提示するようプログラムされ、少なくとも前記コード化データエレメントのいくつかは前記対応の別々のコンセプトと前記コンテキストデータに基づいて決定され、
前記複数のデータエレメントは、前記患者に対する一組の懸案となっている問題のリストデータエレメントを含む、請求項１に記載のシステム。
【請求項３】
前記ケアの縦断的なエピソードの前記複数のフェーズのうち連続したフェーズにおける対応のコード化データエレメントの比較に基づいて、前記連続したフェーズ間の逸脱を検出し、前記縦断的なエピソードデータの一貫性を強化するよう前記プロセッサーによって実行可能な逸脱検出部をさらに備え、
前記逸脱検出部は、前記連続したフェーズの、ある対応のコード化データエレメントにおけるあらかじめ定められた最上位桁のサブセットを比較する、請求項２に記載のシステム。
【請求項４】
前記ＧＵＩを介してリクエストを発行するよう前記プロセッサーによって実行可能なリクエスト生成部をさらに備え、前記リクエスト生成部は、前記逸脱検出部が、前記連続したフェーズの前記縦断的なエピソードデータ間が不一致であると判断したことに応答して前記リクエストを発行するよう促され、前記リクエストに対する応答は、前記連続したフェーズの前記縦断的なエピソードデータ間の前記不一致をなくすために前記縦断的なエピソードデータとして前記連続したフェーズのうちの後のフェーズで格納される、請求項３に記載のシステム。
【請求項５】
前記複数のフェーズのうち少なくとも１つのフェーズについて予測出力をコンピューター計算するよう前記プロセッサーによって実行可能な予測エンジンをさらに備え、前記予測出力は、選択された少なくとも１つの予測モデルおよびそれぞれのフェーズに対する前記縦断的なエピソードデータに基づいて、少なくとも１つの各フェーズについてコンピューター計算され、前記予測出力は、前記予測出力ならびに前記患者の前記ケアの縦断的なエピソードにおける当該予測出力との関連のユーザーインタラクションを資料化するための関連のカルテシステムに供給され、
前記予測出力の前記分析およびその関連の信頼値に基づいて、メモリーに格納される推奨行為データを生成するよう前記プロセッサーによって実行可能なリスクアナライザーをさらに備え、前記推奨行為データのインタラクティブな表現が、前記ＧＵＩを介してユーザーに対して表示される、請求項１に記載のシステム。
【請求項６】
前記少なくとも１つのフェーズは、前記ケアの縦断的なエピソードにおける前記複数のフェーズの施術前フェーズを含み、前記ツールマネージャーは、前記施術前フェーズに対する前記縦断的なエピソードデータと、前記施術前フェーズに対してコンピューター計算された少なくとも１つの予測出力と、患者ＧＵＩとの患者のインタラクションに対応するデータが前記施術前フェーズに対する前記縦断的なエピソードデータに格納されるように前記インタラクティブな承諾書と対話するための前記患者ＧＵＩと、に基づいて、インタラクティブな承諾書を作成するための承諾作成部をさらに含む、請求項１〜５のいずれか１項に記載のシステム。
【請求項７】
前記施術前フェーズに対する前記縦断的なエピソードデータは、前記ＧＵＩとの前記ユーザーインタラクションを、前記施術計画を規定する一組の前記対応の別々のコンセプトに翻訳することで、前記施術前フェーズの間に前記ＧＵＩとのユーザーインタラクションに応答して作成された施術計画を含み、
前記複数のフェーズのうちもうひとつのフェーズは、前記施術前フェーズから前記施術計画をもとに導かれた施術中の縦断的なデータを含む施術中フェーズを含み、
前記施術中の縦断的なデータは、データエレメントを含み、前記施術中フェーズのデータエレメントは、コード化データエレメントを含み、前記コード化エレメントは各々、規定のコード標準に従って、前記患者に対する前記ケアの縦断的なエピソードのそれぞれの態様を提示するようプログラムされ、前記ツールマネージャーは、前記施術中フェーズの前記縦断的なエピソードデータにおけるコード化エレメントと、前記施術前フェーズからの前記施術計画における対応のコード化データエレメントとの間の不一致を検出するようプログラムされ、前記検出された不一致の内容が、不一致データとして前記施術中の縦断的なデータに格納される、請求項６に記載のシステム。
【国際調査報告】
2014533860.tif 000024
2014533860.tif 000025
2014533860.tif 000026