JP5922235B2 - 問題指向型の医療記録を容易にするためのシステム - Google Patents

Description

ヘルスケア業界では、プロバイダー（たとえば、医師、臨床医、看護師、または他の施術者）が、患者の電子カルテで診断または問題の内容を文書化するのが通例である。プロバイダーによって入力された文書をもとに、課金の目的で、エンカウンターを、（たとえば、符号化部によって）符号化できる。このような文書の正確さは、遵守すべき手順が十分に文書化されているにもかかわらず、プロバイダー毎に（特定の組織内ですら）異なり得る。

本開示は、正確な問題指向型の医療の記録づけを行うことを容易にして、プロバイダーの挙動に影響を及ぼすために利用可能な、システム、方法、およびグラフィカルユーザーインターフェース（ＧＵＩ）を提供する。

一例として、コンピューターで実行可能な命令および事業場データを格納するためのメモリーを、システムに含み得る。事業場データは、各顧客（たとえば、患者）に対して特定の事業場プロバイダーによって提供されたサービスを文書化するための情報を表す顧客データを含み得る。メモリーにアクセスし、コンピューターで実行可能な命令を実行するように、プロセッサーを構成することが可能である。これらの命令は、顧客データにおける（たとえば、問題リストにおける）プロバイダーによって文書化される問題に基づいて、１名以上のプロバイダーによって提供されたサービスに関する記述統計を計算するための、解析エンジンを含み得る。出力制御部が、記述統計の出力を作成可能である。

もうひとつの例として、文書化データにアクセスすることを含む方法を行うために、機械読み取り可能な命令を有する非一過性の媒体をプログラムすることが可能である。この文書化データは、患者に対する少なくとも１つの治療または管理に関して、ヘルスケアサービスプロバイダーによって入力される、あるいは、ヘルスケアサービスプロバイダーに代わって入力される情報を含む。プロバイダーによってあるいはプロバイダーに代わって入力される情報を含む文書化データの解析に基づいて、プロバイダーの文書化挙動についての記述統計を計算することができる。計算した記述統計の表現を提示するために、出力を生成することが可能である。

＝＝関連出願へのクロスリファレンス＝＝
本出願は、２０１１年８月１６日にファイルされ、発明の名称が「SYSTEM, METHOD AND GRAPHICAL USER INTERFACE TO FACILITATE ACCURATE PROBLEM-ORIENTED MEDICAL CHARTING（正確な問題指向型医療記録を容易にするためのシステム、方法、グラフィカルユーザーインターフェース）」である米国仮特許出願第６１／５２３，９１３号の優先権の利益を主張するものであり、その内容全体を本明細書に援用する。

実現可能なシステムの例を示す。 すべてのプロバイダーによる患者１人あたりの問題の平均数を表すグラフィカルユーザーインターフェースの一例である。 問題のアップデートを含む、すべてのプロバイダーによる患者１人あたりの問題の平均数を表すグラフィカルユーザーインターフェースの一例を示す。 選択されたサービスラインにおける患者１人あたりの問題の平均数を表すグラフィカルユーザーインターフェースの一例である。 選択されたプロバイダーについて選択された期間にわたる問題の平均数を表すグラフィカルユーザーインターフェースの一例を示す。 選択されたサービスラインについての比較統計を表すグラフィカルユーザーインターフェースの一例を示す。 選択された期間にわたる選択された患者について作成可能な記述統計を表すグラフィカルユーザーインターフェースの一例を示す。 選択された期間にわたる選択された患者について作成可能な記述統計を表すグラフィカルユーザーインターフェースの一例を示す。 選択された患者についての問題リストの詳細な表示を表すグラフィカルユーザーインターフェースの一例を示す。 選択された期間内にアップデートされた重篤度および問題のパーセンテージに関する記述統計の事業場レベルチャートを表すグラフィカルユーザーインターフェースの一例を示す。 事業場の選択されたサービスラインについて作成可能な記述統計を表すグラフィカルユーザーインターフェースの一例を示す。 選択された期間にわたる記述統計のトレンディングを表すグラフィカルユーザーインターフェースの一例を示す。 選択されたサービスライン（図１１から）についての記述統計を表すグラフィカルユーザーインターフェースの一例を示す。 作成可能な比較統計を表すグラフィカルユーザーインターフェースの一例を示す。 患者に対して作成可能な事業場レベルの記述統計を表すグラフィカルユーザーインターフェースの一例を示す。 レポートをカスタマイズするのに利用可能なツールを表すグラフィカルユーザーインターフェースの一例を示す。 計算された統計をもとに、特定の患者の状態についてユーザーにアラートをする目的で作成可能なインタラクティブなレポートを表すグラフィカルユーザーインターフェースの一例を示す。 プロバイダーレベルの比較統計のスコアカードを表すグラフィカルユーザーインターフェースの一例を示す。 プロバイダーレベルの比較統計のスコアカードを表すグラフィカルユーザーインターフェースのもうひとつの例を示す。 特定のプロバイダーが、どれだけ頻繁に問題をアップデートするかの統計を表すグラフィカルユーザーインターフェースの一例を示す。 プロバイダーの文書化挙動および課金挙動の評価を容易にするのに利用可能なルールベースのツールの例を示す。

本開示は、システム、方法、グラフィカルユーザーインターフェース（ＧＵＩ）を提供するものである。本明細書に開示の手法は、文書化挙動および／または課金挙動を含むプロバイダーの挙動を評価することで、正確な問題指向型の医療の記録づけを容易に行えるようにできる。

図１は、問題指向型医療記録を容易にするために利用可能な、システム１０の例を示す。システム１０は、１つ以上の事業場レポジトリで収集された事業場データをもとに、事業場のワークフローおよびそのプロバイダーについて解析を提供するよう実装可能である。システム１０は、顧客のためになされるサービスの従業者または従業者集団によって入力される、あるいは、こうした従業者または従業者集団のために入力される文書化を特徴付ける統計を作成するなど、たとえば事業場の従業者によって適切な文書化を推進する一助となるよう利用可能である。ヘルスケア業界での場合のように文書化が（直接的または間接的に）収入につながる事業場については、システム１０は、従業者の挙動に影響を与える一助となり得る出力（たとえば、レポート、グラフ、チャートなどを含む）を生成可能であり、このような出力がなければ従業者（ら）によってなされたサービスについての文書化が不正確または不完全なせいで失われていたかもしれない、潜在的な収入の機会を、事業場が獲得できるようになる。

ヘルスケア事業所の例でいえば、システム１０は、特定のプロバイダー（たとえば、医師、看護師などの施術者）が患者の治療および／または管理をいかにうまく文書化できるかを示す出力統計を生成できる。システム１０は、このような出力統計を個々のプロバイダーに対して生成してもよいし、プロバイダーまたはプロバイダーのグループが各々、他の各プロバイダーと比較して自らのサービスをどのように文書化しているかを示すよう、プロバイダーのグループに対して生成してもよい。これは、当該プロバイダーに影響を与えて、患者に対して実施される治療、管理、および他のサービスを一層正確に文書化させるためのモチベーションとして利用できる。財務上の検討事項に対処するだけでなく、システム１０は、評判に関する事項（たとえば、プロバイダー、サービスラインあるいは、より一般的に、全体としての事業場に関する事項など）にも対処できる。これの事項は、事業場データをもとにシステム１０で実施される分析によって識別することが可能である。

また、システム１０は、従業者または従業者のグループの異なるタイプの関連する挙動を比較して、異常を識別できる。一例として、システム１０は、文書化挙動（たとえば、従業者または従業者のグループによって入力される文書に従う）と課金挙動（たとえば、そのような従業者または従業者のグループに対する課金データに従う）とを比較して、このような挙動データ間の異常を識別する出力を生成できる。たとえば、システム１０は、糖尿病の診断を受けていないのに、薬物としてインスリンを処方されている患者を識別できよう。関連のあるデータを比較するための上記のタイプおよび他のタイプの分析は、システム１０内にインプリメントされたツールでユーザーがプログラム可能である。

図１の例に戻ると、システム１０は、プロセッサー１２およびメモリー１４を含む。このプロセッサー１２およびメモリー１４は、たとえば、サーバーなどのコンピューターまたはコンピューターのアレンジメントに実装可能である。メモリー１４は、コンピューター読み取り可能な命令およびデータを格納するよう構成される非一過性の媒体として実装可能である。プロセッサー１２は、たとえば本明細書に開示の機能および方法を実施するための、コンピューターで実行可能な命令を実行するために、メモリー１４にアクセスできる。

図１の例では、メモリー１４は、解析エンジン１６を含む、コンピューターで実行可能な命令を含む。解析エンジン１６は、事業場データ、および入力により選択されたパラメーターに基づいて統計を計算するようプログラム可能な、計算部１８を含んでもよい。計算部１８は、（たとえば、選択された事業場データを特徴付ける概要を提供するための）記述統計、（たとえば、確率論に基づくなどして、選択された事業場データから結論を得るまたは推定するための）推測統計、あるいは、アプリケーション要件に応じて変わり得る異なるタイプの統計の組み合わせを計算するようプログラム可能である。

このような計算のためのパラメーターを選択するか、そうでなければ構築するために、解析エンジン１６は、パラメーター選択部２０を含んでもよい。パラメーター選択部２０は、ユーザー入力に応答して、出力統計を計算する際に計算部１８によって使用するためのパラメーターを選択および構成するために利用可能である。よって、システム１０は、解析エンジン１６を含むシステム１０によって実装される関連の機能および方法にユーザーがアクセスできるようにするグラフィカルユーザーインターフェース（ＧＵＩ）２２も含んでもよい。また、ＧＵＩ２２は、解析エンジン１６によって計算される出力統計の表現を含んでもよい。たとえば、（たとえば、１つ以上のデータソースや、抽出対象となるデータのタイプ、内容、範囲を識別するために）出力統計の表現を計算して表示するために用いられるデータソースから抽出されるデータのパラメーターを、権限のあるユーザーが定義する際に、ＧＵＩ２２を利用できる。

１人以上の権限のあるユーザーが、システム１０にローカルで、あるいはネットワーク２４を介して遠隔地から、アクセスできる。たとえば、ユーザーは、対応するユーザーインターフェース２８を含むユーザー装置２６を利用できる。そのユーザーが今度はユーザーインターフェース２８を利用して、データ抽出プロセスに関連した適切なパラメーターを設定して計算部１８を起動するためのパラメーター選択部２０を含む、システム１０によって提供される機能および方法にアクセスできる。たとえば、プロセッサー１２は、１つ以上のデータソースにアクセスし、このデータソースからデータを読み出すためにネットワーク２４に接続されたネットワークインターフェース２９を利用できる。ネットワーク２６は、インターネットまたは事業場のイントラネットなどのローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）を含んでもよい。ネットワーク２６はさらに、物理的な通信媒体（たとえば、光ファイバーまたは導電線など）、無線媒体、または物理的な通信媒体と無線の通信媒体との組み合わせを含んでもよい。

一例では、計算部１８は、事業場データから統計（たとえば、記述および／または推測）を計算するために、数学的および／または統計的な方法でプログラム可能である。計算された統計は、選択された事業場データの概要を表したり、関連のある事業場データ間の相関および比較を表したり、事業場データから引き出される影響を示すことができる。たとえば、記述統計は、事業場情報（たとえば、性能測定基準など）のカテゴリーについての単純化された概要に対応する出力を提供し、事業場内の従業者または他の識別可能な単位（たとえば、サービスライン、部門、プロバイダー、顧客など）にわたる比較を可能にすることができる。たとえば、性能測定基準は、事業場の顧客（たとえば、患者など）に対してあるいは事業場の顧客のために提供されたサービスを、従業者／プロバイダーがいかにうまく文書化するか、ということに関連してもよい。このサービスには、このような従業者／プロバイダーによって直接的または間接的に実施される（たとえば、彼／彼女の指示に基づいて他の人員によって実施される）サービスを含んでもよい。実施されるサービスに応じて費用を請求できるため、このようなサービスの文書化は、受け取ることのできる収入を生み出すのに用いられる重要な要素のひとつとなり得る。出力については、ＧＵＩ２２にグラフィカルに提示して、計算された統計を容易に識別できる方法で可視的に示すことができる。たとえば、特定の統計の孤立値をユーザーが容易に確認できるし、たとえば興味のある情報とリンクした対応するＧＵＩエレメントを選択するなど、ＧＵＩ２２によって掘り下げていくことで、このような孤立値（たとえば、統計的な異常）に関するさらなる詳細を得ることができる。

以下の例は、医療事業所（たとえば、病院、クリニックなどの機関）の文脈で本明細書に開示されており、この場合、たとえば、プロバイダーは医師、看護師、または他のケア従事者であり、顧客は患者であり、サービスラインは、事業場内におけるプロバイダーの業務エリアまたは他の論理的なグループに、それぞれ対応する。しかしながら、背景にある特徴を、本明細書に開示のさまざまなタイプの計算をするためにデータを収集することがある他のタイプの事業場、たとえば法律事務所、製造会社、保険会社などにも、等しく適用可能であることは、理解できよう。

図１の例では、計算部１８は、１つ以上のデータソースから事業場データを得られる。データソースとしては、たとえば、電子カルテ（ＥＨＲ）システム３０、課金システム３２や、３４で示す１つ以上の他のデータソースがあげられる。他のデータソース３４は、患者、患者の入院、患者の健康状態、ヘルスケア施設および／またはその人員または人数についての患者の意見に関連する情報を含み得るどのようなタイプの患者データを含んでもよい。

ＥＨＲシステム３０は、病院の事業場内で実現可能な１つ以上のどのようなＥＨＲシステムを含んでもよく、よって、集合的にＥＨＲデータ３６とする。ＥＨＲデータ３６は、複数の異なるカテゴリーについての情報を表すことができる。たとえば、ＥＨＲデータ３６における患者データのカテゴリーは、以下のものを含んでもよい。患者の人数データ、全患者を対象とした（ＡＰＲ）重篤度情報、ＡＰＲ診断群分類（ＤＲＧ）情報またはコード、問題リストコード、処方薬、臨床検査結果。

また、課金システム３２は、課金データ３８などの最終的な符号化データ３８を含んでもよい。最終的な符号化データ３８は、最終的な課金コード、最終的な手順コード、他の最終的な符号化データを含む、さまざまなカテゴリーのデータを含み得る。符号化部４０は、ＥＨＲデータ３６および／または他のデータ３４をもとに、最終的な符号化データ（たとえば、他のデータ３４として格納される）を生成できる。符号化部４０は、自動の方法、手動の方法、または手動と自動の方法の組み合わせとして実現可能である。たとえば、最終的な符号化データ３８は、国際疾病分類（ＩＣＤ）データ（たとえば、ＩＣＤ−９、ＩＣＤ−１０−ＣＭまたはＩＣＤ−１０−ＰＣＳ）、診断群分類（ＤＲＧ）データ、（たとえば、Medicare DRG、Refined DRG、all patient DRG、severity DRG、all patient severity-adjusted DRG、all patient refined DRGまたはInternational-refined DRG）を含み得る。最終的な符号化データ３８を導くのに利用できる他のタイプおよびカテゴリーの情報およびコーディングを、当業者であれば理解し、認識できよう。

解析エンジン１６は、データソースにアクセスするために、それぞれのインターフェース（たとえば、アプリケーションプログラムインターフェース）４２、４４、４６を利用できる。図１の例では、ＥＨＲインターフェース４２は、ＥＨＲシステム３０から関連のデータにアクセスするようプログラムされる。課金インターフェース４４は、課金システム３２から関連のデータにアクセスするためにプログラムされる。同様に、他のデータインターフェース４６は、他のデータソース３４にアクセスするためにプログラムされる。よって、解析エンジン１６は、対応の出力統計を計算するのに必要な選択されたパラメーターに従って、選択されたデータをそれぞれのデータソースから読み出すのに、１つ以上のこのようなインターフェース４２、４４または４６を利用できる。

また、システム１０は、解析エンジン１６によって計算される出力統計の表現を制御するようプログラムされる出力制御部４８も含む。出力制御部４８は、グラフィックスの見た目が特定タイプのディスプレイに合わせて設定されるような形で、ユーザーがパラメーター選択部２０を介して設定したパラメーターをもとに、出力統計のグラフィック表現を自動的に作成できる。その代わりにまたはそれに加えて、ユーザーは、パラメーターを選択して、ユーザーによって定義されるタイプと形態の出力を達成するためにＧＵＩ２２を利用できる。この出力は、ＧＵＩ２２内にインタラクティブに提供できるテキスト、グラフィックスまたはテキストとグラフィックスとの組み合わせを含むものとして提示可能である。

さらに別の例として、出力制御部４８は、表現を静的にまたはアニメ化して制御してもよい。アニメ化した出力は、ある期間における特定の事業場単位（たとえば、患者、プロバイダー、サービスライン、部門など）に対する、計算される統計の変化を示すための一組のパラメーターについて提供可能である。出力制御部４４は、アニメ化した出力の再生（たとえば、一時停止、巻き戻し、早送り、逆再生など）をユーザーが制御できるようにするツールを提供できる。このように、所望の統計での時間的な変化を、インタラクティブなＧＵＩ２２で可視化して、１つ以上の選択された期間における統計の変化を示すことができる。アニメーションを表示する時間または患者のエンカウンターの量を、たとえばパラメーター選択部２０を介して、特定のユーザーが設定可能である。

さらに別の例として、計算部１８は、プロバイダーによって入力される文書および対応する課金データをもとに、比較統計を計算するようプログラムされる機会計算部を含んでもよい。機会計算部は、比較統計を計算して、文書化データと課金データとの間の異常を識別することができ、出力制御部は、対応する出力を、特定のプロバイダーに対するグラフィックおよび／またはテキスト形式の出力の形で提供できる。機会計算部はさらに、特定プロバイダーのサービスを受ける一組の患者についての経時的な統計を計算することによって、実際の課金とは異なる場合もある文書化挙動の表示を提供できる。このように、プロバイダーの文書化挙動を修正するべく、彼／彼女に注意喚起（たとえば、レポートまたは他の通知の形で）する目的で、フィードバックを作成できる。出力制御部４８は、たとえば、課金データ３８に説明されているように、１以上の選択されたプロバイダーの文書を実際の課金挙動と比較するレポートを生成できる。レポートの作成に加えてまたはこれに代えて、出力制御部４８は、プロバイダーにメッセージ（たとえば、電子メール、テキスト、ページなど）を送信して、異常の検出をもとにＥＨＲシステム３０における患者の記録に対する可能性のあるアップデートを提案できよう。このように、プロバイダーは、たとえばメッセージ内に提供できる患者の記録とのリンクを介して、患者の記録をアップデートするか、そうでなければこの提案を確認または拒否することができる。

さらに別の例として、機会計算部は、文書化データ、課金データまたは文書化データと課金データとの組み合わせをもとに、潜在的な異常を識別するようプログラムされた代理人データまたはルールを利用するためにプログラム可能である。たとえば、代理人データは、ルックアップテーブルまたはルールエンジンを含むものとして実現可能なものなどのデータセットを含んでもよい。これは、一緒に存在すると決められた１つ以上の関連の診断または問題、薬物または検査を識別するために、施設の標準（たとえば、許容されている実務または最も良い実務）に基づいてプログラムされる。たとえば、特定の患者のエンカウンターに対する課金データ３８または文書化データは、代理人データを利用して、このような異常が存在するか否かを判断し、逃した可能性のある機会を識別する出力を生成できる、機会計算部への入力であってもよい。よって、機会計算部は、（代理人データにおいて規定されるような）一緒に存在するはずだとわかっている１つ以上の記述子またはコードが欠けていることの検出に応答して、異常だと識別するようにプログラムすることが可能である。一例として、特定の薬物（たとえば、インスリンなど）を処方されたか服用しているにもかかわらず、そのような薬物が付随することが知られているような対応する診断（たとえば、糖尿病など）が存在しない患者について、機会計算部は、このような診断がないことを異常であるとして識別できよう。よって、機会計算部は、文書化または課金されていなかったかもしれない各々の異常を、課金データまたは文書化データそれぞれの対応の代理人データとの比較をもとに、問題リストコード、ＤＲＧ情報などとして識別できる。この出力は、１名以上のプロバイダー各々について、逃した可能性のある機会を識別するテキスト（たとえば、コードまたは他の記述子による）および／または逃した可能性のある機会の回数の表示を含んでもよい。いくつかの例では、機会計算部は、記述統計を用いることによって、逃した機会の各々の尤度を判断することができる。これらの出力をプロバイダーごとにまとめ、本明細書に開示するようなユーザーによって規定される時間内での比較をすることが可能である。

図２から図１６は、ユーザー入力に応答して、（たとえば、図１のパラメーター選択部２０によって選択される）異なる構成パラメーターに対応するなど、図１のシステム１０によって作成可能なＧＵＩ（たとえば、図１のＧＵＩ２２に対応）の例としての実施形態を示す。図２から図１６の例では、特定の固有情報またはデリケートな情報が、図のいくつかから編集により省かれている。図２から図１６の例に示されたフォームおよびＧＵＩエレメントは例示目的であり、この開示は、（たとえば、図１のシステム１０によって計算されるものとして）提示されている背後の解析およびコンテンツに関連することは自明であろう。よって、図１のシステムは、問題指向型チャート作成を容易にするために、図２から図１６の例に示される異なるタイプおよび形態のＧＵＩを利用できる。

図２は、一組のプロバイダーについての患者一人あたりの問題の平均数を表すグラフィカルユーザーインターフェース５０の例を示す。この平均数は、たとえば、図１の計算部１８によって計算可能である。一組のプロバイダーは、たとえばすべてのプロバイダーから、または１以上の利用可能なプロバイダーの選択されたサブセット（たとえば所定のグループまたはサービスラインに対応してもよい）から選択可能である。よって、ＧＵＩは、ユーザーが選択可能な多岐にわたるデータレベルを含む。図２から図１６の例では、データレベルは、たとえば事業場レベルに対応するＨＶＩ、選択された部門またはプロバイダーのグループに対応するサービスラインデータレベル、プロバイダーデータレベル（個々のプロバイダーに対応）、１人以上の患者に対するデータを提示できる患者データレベルを含むものとして表されている。また、プロバイダーは、文字によって総称的に識別されているが、他の例では、実名を使用してもよい。選択された期間は、図２での場合のように、たとえば選択された期間での選択された一組のプロバイダー各々について、患者一人あたりの問題の平均数を表すために設定可能である。一組のプロバイダーは、たとえば提示される一組のプロバイダーをスクロールすることによって、表示上で拡大または縮小可能である。また、ＧＵＩ５０には、追加機能をアクティブにするためのＧＵＩエレメント（たとえば、期間を設定するためのものや、リフレッシュボタン、または「w/update（ｗ／アップデート）」ボタン５３など）も提供されてもよい。その代わりにまたはそれに加えて、本開示に基づく複数のインタラクティブな画面を用いて、データの動的な検索を可能にするための機能を実現できる。複数の色または他のグラフィックな区別を使用して、たとえば患者の平均数と対応する標準偏差など、ＧＵＩ５０について計算した統計的なデータを表示することが可能である。

図３は、「update」ボタン５３がアクティブになっている、図２のＧＵＩ５０の例を示す。「update」ボタン５３がアクティブになることに応答して、図３に示されるように（あるいは自動の動的なアップデートによって）、問題リスト中の問題に対するアップデートのタイミングを表す情報も、選択されたデータレベルのすべてのプロバイダーについて含まれる。たとえば、色コードでの目盛り５４を提供することによって、たとえば、１日以内、１〜２日以内または３日以上のアップデートなどを含む、問題に対する平均アップデート時間を可視的に表すことができる。目盛り５４を用いると、ユーザーは、リスト化されたプロバイダー各々についての平均アップデート時間を理解できる。この追加のアップデートタイミング情報は、各プロバイダーについて（たとえば、図１の解析エンジン１６によって）計算された統計を可視的に表す各々のバーに（たとえば、重ねた状態で）提示できる。

図４は、計算された解析をもとに出力制御部（たとえば、図１の出力制御部４８）によって生成可能なもうひとつのＧＵＩ５６の例をさらに示す。図４の例では、ＧＵＩ５６は、（たとえば、図１の解析エンジン１６によって計算される）解析をもとに選択されたサービスライン（本例では、イメージングサービスライン）について患者一人あたりの問題の平均数を示す。図４に示されるように、問題の平均数と標準偏差が、選択されたサービスラインのプロバイダーごとに、目盛り５８で示されるような異なる色でＧＵＩ５６にグラフィカルに表される。また、ＧＵＩ５６は、たとえば「refresh（リフレッシュ）」ボタン、問題アップデート（「PBL update」）ボタン、「scatter chart（散布図）」ボタン、「motion chart（モーションチャート）」ボタンを含むなど、追加の機能およびツールにアクセスするためにアクティブにできる複数のＧＵＩエレメント６０を含む。これらのＧＵＩエレメント６０は各々、出力制御部および情報の提示方法を変更するためのユーザー入力に応答して（または他のモードで自動的に）アクティブになってもよい。たとえば、「PBL update」ボタンは、患者ごとに各プロバイダーについてのアップデートタイミング情報を含むようアクティブにできる。scatter chartは、散布図を表すことができ、モーションチャートボタンは、ユーザーが選択した時間内に情報のアニメ化した出力を提供するのに利用できる。よって、サービスラインを細分化することで、その特定のサービスラインにおける特定のプロバイダーに関連する詳細を、ユーザーに対して表示される出力の中に提示できる。このように、管理者が、グループ内の潜在的に働きの低いもの（たとえば、患者についての問題リストにおける問題が十分に文書化されていないことなどに対応する）を容易に識別できる。

図５は、選択された期間について、プロバイダーレベルにデータレベルを設定することなどによって、プロバイダーによる患者レベル集合画面を表すＧＵＩ６２の例を示す。この例では、プロバイダーのリストから特定のプロバイダー（たとえば、Smith,K.）が選択され、選択された期間にわたるそのプロバイダーについての記述統計が計算されて（たとえば、図１の解析エンジン１６によって）、ＧＵＩ６２によって提示される。可視化された統計は、プロバイダーが、自身の患者全員を一画面で閲覧できる患者レベルの画面での問題の平均数や、患者ごとの問題の平均数ならびに、各患者に関連する健康状態の表示を含む。たとえば、グラフの上に（たとえば、カーソルなどのポインティング要素で）とどまることで、特定の問題についてのアップデートタイミングに関する追加情報をユーザーに提示できる。また、図５のＧＵＩ６２は、「refresh」ボタン、「PBL update」ボタン、「service line providers（サービスラインプロバイダー）」ボタンを含む追加のＧＵＩエレメントも含む。これらのＧＵＩエレメントは各々、追加情報を提示するための追加の機能にアクセスするためにアクティブにされてもよい。また、ＧＵＩ６２は、図１の計算部１８によって計算可能な選択されたパラメーター（たとえば、プロバイダー、期間、およびプロバイダーの患者）についての記述統計６５も提示できる。図５の例では、記述統計６５は、平均入院日数、プロバイダーによって入力されるＩＣＤ−９コード間の平均マッチアップ、重篤度指数に応じた最終的な課金コードや、最近の期間（たとえば、前週）に文書化された問題の比率を含む。

図６は、それぞれの事業場での選択されたサービスラインについて、最終的な入院日数に対する１日あたりの問題の平均数（たとえば、図１の解析エンジン１６の計算部１８によって計算されたもの）を表すＧＵＩ６６の例を示す。図６の例では、サービスラインは、イメージングとして選択されている。本明細書に開示するように、サービスラインのみならず、他のパラメーターも、（たとえば、図１のパラメーター選択部２０によって）選択できる。例示的なＧＵＩ６６は、１日あたりの問題の平均数を最終的な入院日数の関数として示す散布プロットを含む。グラフから明らかなように、ユーザーが孤立値を容易に識別し、対処できる。たとえば、あるプロバイダーの入院日数が多いのに問題数が少ない場合、ユーザーは、ＧＵＩ６６でプロットされたデータを選択し、（たとえば、グラフ中のデータエレメントをダブルクリックするなどして）これを掘り下げ、背後にあるデータに関連する一層詳細な情報を得ることができる。また、図６のＧＵＩ６６は、ボタンの形でのＧＵＩエレメント、たとえば、リフレッシュボタン、「PBL update」ボタン、「providers（プロバイダー）」ボタン、「motion charge（モーションチャージ）」ボタンや、システムに関連する他の機能にアクセスするのに利用できる「other（その他）」ボタン、などを含んでもよい。このように、このグラフは、選択された期間における特定のサービスラインのプロバイダーについて、背景にある挙動データを可視的に示す。

図７Ａおよび図７Ｂは、選択された入院日数（たとえば、図１の解析エンジン１６によってコンピューター計算される）での特定の患者（患者Ｘ）についての統計の例示的なＧＵＩ７０を示す。たとえば、図７ＡのＧＵＩは、特定の患者について日ごとに文書化された多数の問題の棒グラフ７２を示し、そこには、たとえば１日以内にアップデートされた、１日または２日の間にアップデートされた、あるいは、それぞれの問題のアップデートに３日以上などと示されるアップデート期間を示す色コードの凡例７３によって、当該問題と関連したアップデートの日付も含む。棒グラフ７４には、日ごとに問題の解決も示される。これは、解決された問題数と、このような問題が解決された時刻を可視的に表している。よって、グラフ７２および７４は、たとえば図１の計算部１８によって計算されるなど、特定の患者を治療しているプロバイダーについて、背景にある挙動データを可視的に示す。たとえば、プロバイダーは、ＥＨＲクライアントを利用して、（問題リスト内の）問題に対して、解決済みか、そうでなければ問題をアップデートするというステータスの変更を文書化でき、計算部は、ＥＨＲデータにアクセスして、選択された期間にわたる特定の患者についてのＥＨＲデータから記述統計を決定できる。

図７Ｂは、特定の患者について計算可能な出力統計のもうひとつのグラフ７６を示しており、ここには、入院日数に対する問題の数がプロットされ、日ごとにプロットされた問題に関連した診断重篤度スコアが含まれている。たとえば、図７Ａおよび図７ＢのＧＵＩは、ユーザーが、患者ごとに詳細を掘り下げて、入院日数に対して患者特有の追加情報を参照することを可能にできる。図示のように、これは、日ごとにアップデートされる問題数、日ごとの評価および管理課金データ、日ごとの診断重篤度スコアを含み得る。よって、このグラフは、プロバイダーによる問題指向型文書化用に、背景にある挙動データを可視的に示す。

図８は、特定の患者について図１のシステムによってアクセスできる追加の詳細を表しているＧＵＩ７８の例を示す。図８の例では、ＧＵＩは、特定の日についての問題リスト詳細レポートを示し、これはたとえば、図７Ａおよび図７Ｂで図示して説明したＧＵＩ７０からアクセスすることが可能である。よって、図８の例では、診断名と対応するＩＣＤ−９コードによる問題の詳細なリストを提供できる。また、課金記録についての評価および管理（Ｅ＆Ｍ）データも、そのようなデータが存在すれば提供できる。よって、詳細情報を精査することで、ユーザーは、背景にある証拠についての情報ならびに、他のＧＵＩで提供される統計的な情報を計算する際に用いられるデータを確認でき、これによってプロバイダーの挙動をさらに詳細に理解することができる。

図９は、特定の事業場についてのモーションチャート８２を表すＧＵＩ８０の例を示す。図９の例では、モーションチャート８２は、異なるサービスライン（たとえば、専門の領域など）についての平均総重篤度スコアを、平均としての選択された期間（１日あたり２４時間）以内にアップデートされる問題のパーセンテージの関数としてプロットすることで作成可能である。たとえば図９の例に示されるドロップダウンメニュー８４または他のＧＵＩエレメントによって、モーションチャートに別のタイプの情報を提示するために、軸に含まれる情報を修正し、ユーザーが選択できることは、理解し、認識できよう。また、モーションチャート８２は、専門ごとの色コードでの表現を含んでもよいが、他のタイプの情報を色コードで示すこともできる。

図９の例では、モーションチャートは、事業場におけるサービスラインによる統計を示す。これは、心臓胸郭手術、臨床、ＥＰ／ペースメーカー、心不全、イメージング、介入的な予防、研修医、胸郭および血管手術など、専門ごとに示される。このような専門各々のアイコンまたはグラフィックエレメントの大きさも、ユーザーが選択する基準をもとに可変であり、図９の例では、特定の日の退院患者数として示されている。さらに、モーションチャート８２の一番下にあるのは、たとえばスライドの形で示される時間的なＧＵＩエレメント８６であり、これは、モーションチャート８２に提示される情報に対応する選択された期間における時間（たとえば、日または時）を示す。たとえば、ユーザーは、プレイボタンを選択して、ユーザーにアニメ化した視覚表現を提供するためのモーションチャートをアクティブにしたり、チャートを一時停止したり、あるいは、そうでなければスライドエレメントを前後に移動させたりすることによって、期間を選択して関係を閲覧することができ、これによって経時的にデータがどのように変化するか理解することができる。また、ユーザーは、データに表される期間も変更できる。

図９のＧＵＩの右下隅において、ＧＵＩ８０は、縮小されたデータの全体図８８を提示することが可能であり、孤立値が特定のスケールまたはズームレベルの外に示されることがあるように、メインプロットに表示されているデータが計算されたすべてのデータを含んでいるとは限らないことを示すことができる。たとえば、ユーザーは、表示されているデータの相対的なサイズとデータの量を変更すべくズームインまたはズームアウトするためにユーザーインターフェースエレメントをアクティブにできる。よって、モーションチャートは、ユーザーが、経時的に変化し得る（たとえば、図１の解析エンジン１６によって）計算された分析をもとに選択されたサービスラインの背景にある挙動を可視的に理解するのを可能にする。

図１０は、図９を参照して図示し、説明した例に類似のサービスラインによるモーションチャートを表すＧＵＩ９０の例を示す。図１０の例では、データは、棒グラフ９２として表される。グラフの右上隅に９４で示される各タイプのプロットに関連するユーザーインターフェースエレメントによって、ユーザー入力に応答して、モーション表現のタイプ（たとえば、散布図プロット、棒グラフまたは時間ベースの傾向プロット）を選択できる。図１０の例におけるモーションチャート９２に関連する他のパラメーターも、たとえば図９を参照して上記にて開示したように、ユーザーによって選択可能である。図１０の棒グラフのＧＵＩ９０では、たとえば図１０のモーションチャートＧＵＩ用の１つ以上のサービスラインを選択する、表示パラメーターを設定するために、別のユーザーインターフェースエレメント９６が提供される。各サービスラインの各棒によって表される情報は、時間的なＧＵＩエレメント９８によって反映されるような、チャートが示される選択された期間内での時点に基づいて、経時的に変化していく。よって、グラフ９２の各棒は、ユーザーが選択した期間内で、時間が進むまたは戻るようアニメ化できる。

図１１は、サービスラインごとのトレンディングが表される、サービスラインによるさらにもうひとつのタイプのモーションチャート１０２を表すＧＵＩ１００の例を示す。図１１の例示的なＧＵＩ１００では、色コードを利用して、異なるサービスラインを区別することができる。この例では、トレンディングは、サービスラインごとに選択された期間にわたるデータの全体像を示す。図１１の例は、サービスライン１つあたりの経時的な平均総重篤度スコアを示している。各サービスラインのトレンディングは、ＧＵＩで選択してもよい重篤度スコアまたは他の基準に関連したサービスラインについて（たとえば、グラフに表される出力統計の計算にどのパラメーターを利用するか選択するためのドロップダウンのユーザーインターフェースエレメントを用いて）容易に識別可能である。また、ユーザーは、モーションチャート１０２に提示される対応する出力の上にとどまって追加情報を提供することができる。これは、例では、週４８の平均重篤度スコア２．８７を示す心臓胸郭手術重篤度プロットのプロットに沿った点を示す。追加情報は、本明細書に開示されているような追加の機能を掘り下げてアクティブにすることで、得るようにしてもよい。

図１２は、たとえばポインティングエレメントや他の入力装置を用いて分離すべきサービスラインを選択するというユーザー入力に応答して、図１１の例の他のサービスラインから分離された、選択されたサービスラインを表すＧＵＩ１０４の例を示す。図１２の例では、心臓胸郭手術サービスラインが他の情報から分離されているが、これは、たとえば事業場の利用可能なサービスラインの一覧（たとえば、心臓胸郭手術が選択されているグラフの右下隅にあるＧＵＩエレメント１０６に対応する）から心臓胸郭手術サービスラインを選択することによって行われる。サービスラインまたは一組のサービスラインを分離したら、グラフに沿って異なる点まで掘り下げることで、一層具体的な詳細を得ることができる。

図１３は、課金データおよびＥＨＲデータをはじめとする事業場データをもとに作成可能な比較統計を表すＧＵＩ１１０の例を示す。図１３の例でＧＵＩ１１０によって提示される情報は、文書化機会レポートとして参照できる。文書化機会レポートは、特定のプロバイダーまたはプロバイダーのグループについて、関連の文書化データを関連の課金データと比較する解析をもとに作成可能である。文書化機会レポートは、文書中の検出された異常（一つまたは複数）のせいで逃してしまった機会の１つ以上の事例を識別する情報を含んでもよい。（たとえば、図１の解析エンジン１６によって）逃した機会が識別されると、システムは、検出された不正確な文書の潜在的なコストについて報告できる。たとえば、潜在的なコストは、管理上の目的で利用でき、プロバイダーが自らの将来の挙動を変更する一助となるし、この挙動も、経時的な定量的解析によって評価することが可能である。

図１３の例では、ＧＵＩ１１０は、ＥＨＲデータをもとにした問題リスト診断に対応するマッチのない符号化課金データに基づく符号化診断レポート１１２を含む。レポート１１２に含まれる診断は、重篤度または他の関連のパラメーターに応じてフィルタリング可能である。よって、レポート１１２は、（存在する場合）どのサービスが、それぞれの課金コードのもとで課金されたのに、患者の記録に診断または他のサービスについての対応の文書を含まないのか、確認するために利用できる。同様に、ＧＵＩ１１０は、それぞれの患者のエンカウンターについての対応の課金コードとマッチしないＥＨＲデータから問題のレポートを提供できる。このレポート１１２は、診断および他のタイプのサービス（たとえば、介入、検査など）のうち、既に提供されて文書化されているかもしれないが、そのようなサービスについての対応の課金コードにつながっていないものを確認するために利用できる。

また、ＧＵＩ１１０は、特定の患者についての最終的な符号化課金データ（たとえば、図１の課金データ３８から得られる）に対応する診断に関する問題リスト診断（たとえば、図１の３６のＥＨＲデータから得られる）についての比較レポート１１４を含んでもよい。このようなデータを比較するために計算された解析に基づいて、たとえば、図１３のＧＵＩ１１０は、最終的な符号化課金データにおけるＩＣＤ−９コードに関する情報、最終的な符号化課金とＥＨＲデータに格納された問題リストとの間のマッチを示すＩＣＤ−９コードのリスト、および、問題リストのみからＩＣＤ−９コードが列挙された別のリストを提示できる。情報およびリストのタイプは、ユーザーが選択可能なものであってもよい。よって、ユーザーは、たとえば入力されたコーディングにおける潜在的な逃した機会を識別できるように、それぞれのリストを評価して、これがどこでマッチして、どこでマッチしていないかを判断できる。これは、詳細なレポートを提供することができ、それによって、ユーザーが、プロバイダー（またはプロバイダーのグループ）によって入力される問題リスト診断を、最終的な符号化データにおける対応する課金された診断との比較で自動的に閲覧し、ひいては、このような診断がどこでマッチし、どこでマッチしないかを理解することを可能にする。さらに別の例として、解析では、たとえばそれぞれのプロバイダーまたはプロバイダーのグループごとに、最終的な符号化課金データがＥＨＲからの問題リスト診断とマッチしない回数を計算することが可能である。この計算は、特定の患者のエンカウンターについて、あるいは、あらかじめ定められた期間またはその両方で実施可能である。比較は、ユーザーによって（たとえば、手作業で）開始されてもよいし、比較は、特定のプロバイダーまたはプロバイダーのグループ（サービスラインまたは事業場全体など）についての対応する文書化機会レポートを作成する自動処理であってもよい。

図１４は、作成可能なサンプルレポート１２０を表す例示的なＧＵＩ１１８を示す。たとえば、ＧＵＩからレポートボタン１２１をクリックすることで、たとえば専門性／サービスラインや、期間を含むユーザーが選択した基準をもとに、すべての患者について一組の問題リストデータまたは他の情報を識別できる。表内のさまざまな列をソートして、ユーザーによって選択される順序で詳細を提供することが可能である。レポート１２０は、選択されたレンジの患者のみならず、課金データおよびＥＨＲデータから得られる他の定量化されたデータごとに、（たとえば、図１の解析エンジン１６によって）計算することが可能な統計を含んでもよい。図１４の例では、計算され、レポート１２０に提供される統計は、問題数、診断の総数、入院日数、１日あたりのアップデートされる問題の平均数（ａ％）、１日あたりのアップデートされる問題の中央値％を含んでもよい。

図１５は、ユーザーが基準を選択し、このユーザーが選択した基準に応じてデータをフィルタリングしてカスタムレポートを作成できるようにするためのＧＵＩエレメント１２６および１２８が提供されるＧＵＩ１２４を示す。たとえば、ＧＵＩエレメント１２６は、ユーザーが、検索基準を設定できるようにすることが可能である。これはたとえば、サービスライン（たとえば、イメージング）、ＩＣＤコード、期間、ユニットを定義することを含んでもよい。検索基準は、フィルターＧＵＩエレメント１２８によってさらにフィルタリング可能である。フィルタリングでは、レポート用に対応のフィルターを作成するのにユーザーが選択および定義可能な、ブール論理および演算または他の式を利用できる。本明細書に開示の他のＧＵＩ（たとえば、図２から図１４および図１６から図１９の各々に含まれるもの）に関しても、同様のフィルタリングを実現できる。

図１６は、プロバイダー（またはグループ）の文書化挙動が、想定した動作パラメーター（ユーザーが定義するパラメーター（たとえば、施設で許容されている規範）であってもよい）の外にあるときに、ユーザーに警告またはアラートを提供するのに利用可能な、挙動レポート１３４のもうひとつの形態を表す例示的なＧＵＩ１３０を示す。ＧＵＩ１３０は、レポート１３４を作成する際にもとになる検索基準を規定するためのＧＵＩエレメント１３２を含んでもよい。レポート対象となる論点／情報の１つ以上の異なるカテゴリーに対応する、ユーザーによって規定される想定された動作パラメーターから外れる事例を計算するために、検索結果について、解析を実施可能である。これらのカテゴリーは、ユーザーの要件に応じて選択可能である、あらかじめ定められた一組のアラートカテゴリーを含んでもよい。また、ユーザーは、たとえば図１５を参照して本明細書に開示するような１つ以上のフィルターを構成することで、新たなアラートカテゴリーを作成できる。続いて出力制御部は、特定のカテゴリーおよび検索パラメーター各々について計算された解析をもとに、実施された解析に基づくそれぞれのアラートカテゴリーについての情報および統計を与える、対応のレポートを作成できる。

一例として、レポート１３４は、ユーザーによって規定される基準にマッチする問題を識別する論点カテゴリーを含むよう作成可能である。たとえば、論点カテゴリーは、あらかじめ定められた期間（たとえば２４時間を超えるなど）入院しているが、文書化された問題がないか、ＥＨＲデータに報告された問題数がユーザーによって規定される閾値未満である患者を識別できる。もうひとつの例として、カテゴリーは、あらかじめ定められた期間（たとえば、約４８時間を超えるなど）内に何らアップデートまたは解決のないまま一組の問題が問題リストに残っていることを識別できる。また、ＧＵＩ１３０は、管理者または監督者などのユーザーが、表示されたデータを掘り下げて、レポート１３４に提示される情報の１つ以上の選択された部分についての追加の詳細を得られるようにすることもできる。

図１６の例において図示するように、ユーザーによって規定されるレポートパラメーターをもとに、異なるアラートカテゴリーを報告できる。このタイプのアラートレポートは、プロバイダーが不十分な文書を（たとえば、ＥＨＲシステムで）提供しているかもしれない状況を識別して、入院日数がプロバイダーによってアップデートされることなく問題の存在していた期間を過ぎていることで証明される、特定の治療過程を保証するために利用可能である。

患者およびプロバイダーに対してテープで記録された事業場データ（たとえば、ＥＨＲデータおよび課金データ）に基づいて、さまざまなタイプのアラート報告に、他のタイプのパラメーターを設定可能であることは、理解し、認識できよう。また、特定のプロバイダーについて１つ以上のアラート条件が決まったことに応答して、電子メール、テキスト、ページなどのメッセージ伝達技術によって、１人以上の個人にメッセージを送るよう解析エンジンをプログラム可能である。この個人は、アラートが決定された対象であるプロバイダーおよび／またはプロバイダーの監督者を含んでもよい。この技術次第で、アラートメッセージは、適切な場合に、受信者（たとえば、プロバイダー）が記録をアップデートできるようにするための関連のレポートデータおよび／またはリンクを含んでもよい。

図１７は、１名以上のプロバイダーの問題指向型文書化について報告すべく作成可能な、構成可能なスコアカード１４２、１４４、１４６に対応するＧＵＩ１４２の例を示す。このようなスコアカードは、たとえば業界標準と比較したり、定義されたプロバイダーのピアグループ（たとえば、サービスラインまたは他のサブセットのプロバイダー内など）と比較した、１名以上のプロバイダーについての比較統計を提供できる。その代わりにまたはそれに加えて、比較は、（たとえば、異なる時間窓について）プロバイダー自身で比較した彼／彼女のものであってもよい。このような比較統計に使用されるパラメーターは、ユーザーによって定義されてもよいし、あらかじめ規定された一組のパラメーターからユーザーインターフェースエレメント（たとえば、ドロップダウンメニューなどであり、たとえば図１のパラメーター選択機能２０によるもの）を用いて選択されてもよい。

図１７の例では、３つのスコアカードレポート１４２、１４４、１４６が示されている。１つのレポートカード１４２は、日ごとにアップデートされる問題の平均数をグラフィカルに提示するための担当プロバイダーグラフに対応するグラフを含む。色目盛り１４３で示される、棒グラフの色コードは、文書化された問題を、それぞれのプロバイダーがいかにすみやかにアップデートしたかも示す（たとえば、１日以内、１〜２日以内など）。もうひとつのレポート１４４は、担当プロバイダーによるＥ＆Ｍ課金のグラフ（担当プロバイダーグラフ１４２の下に位置する）を含む。レポート１４４は、本例では心臓胸郭手術ラインである選択されたサービスラインでの各プロバイダーの課金の総数を示す。色コードは、色目盛り１４５で示されるように、プロバイダーそれぞれの課金タイプの分布を示すべく各プロバイダーに対する棒グラフにも利用できる。また、ＧＵＩ１４２は、看護師施術者（ＮＰ）サービスラインにおける各プロバイダーの課金の総数を提示する課金プロバイダーによるＥ＆Ｍ課金グラフのグラフを含むレポート１４６を含んでもよい。また、レポート１４６では、色目盛り１４７で示されるように、プロバイダーそれぞれの課金タイプの分布を示すべく各プロバイダーに対する色コードを利用できる。レポート１４６では、たとえば、比較例における他のプロバイダーを匿名にするために、１つを除くすべてのプロバイダーの名称が、あらかじめ規定された一般的な表示（たとえば、「＊＊＊」）に置き換えられる。よって、このレポートは、他のプロバイダーのアイデンティティを明らかにすることなく、比較例を提供する目的で、選択およびリスト化されたプロバイダーに送信可能である。

スコアカードＧＵＩ１４２のいくつかのパラメーターは、ユーザーインターフェースエレメント（たとえば、ダイアログボックス、ドロップダウンメニュー、ボタンなど）１４０によって設定可能である。たとえば、ユーザーインターフェースエレメント１４０は、スコアカード用にユーザー選択された期間の設定を可能にする。パラメーターは、担当サービスラインと課金サービスラインの両方（および／または他のライン）や、選択されたライン各々における１名以上のプロバイダーを選択するためのＧＵＩエレメント１４０によって設定可能である。この例では、担当プロバイダーはすべて、担当サービスライン（心臓胸郭手術）で選択され、プロバイダーによって比較するための比較が選択されている。課金サービスラインはＮＰに設定されており、選択された単一のプロバイダーを、課金プロバイダーとして設定可能である。このように、比較が容易になされるような方法で、（選択された課金プロバイダー以外の）他の各課金プロバイダーの匿名性が維持される。このタイプのスコアカードは、このようなプロバイダーの、サービスラインにおける他のプロバイダーとの比較基準を提供するために、メッセージ伝達システムによって、選択されたプロバイダーまたは他の権限のある人に送信可能である。

図１８は、ＧＵＩエレメント１５２によって選択されるように、担当サービスラインと課金サービスラインが同一（本例では「心不全」）であるようなスコアカードＧＵＩ１５０のもうひとつの例を示す。この例では、サービスラインの選択されたプロバイダーについて、（たとえば、図１の解析エンジン１６によって）担当プロバイダー問題アップデートグラフ１５４が作成されるのに対し、このサービスラインの他のプロバイダーは、図１７のグラフ１４６と同様にアスタリスクで表示される。よって、このようなレポートおよびグラフは、他のプロバイダーそれぞれのアイデンティティを明かすことなく、プロバイダーが、自分の問題指向型チャートおよび関連の課金が同じサービスラインの他の従業者と比較してどのようになっているのかわかるように、識別されたプロバイダーに（たとえば、メッセージサービスによって）送信することもできるし、印刷されたレポートとして配布することもできる。担当プロバイダーグラフ１５６によるＥ＆Ｍ課金が、選択された同じプロバイダーの課金総数や他の色コードでの課金タイプ情報や、サービスライン内の他のプロバイダー（その名前をアスタリスクに置き換えて）との比較も示す。課金プロバイダーグラフ１５８によるＥ＆Ｍ課金が、選択された課金プロバイダーに対する比較例を提供すべく、選択されたサービスラインにおけるプロバイダーごとの課金総数も示す。よって、スコアカード１５０は、プロバイダーによる正確な問題指向型文書化の改善を促すための、（たとえば、図１の出力制御部４８によって）作成可能な効果的なツールを提供する。

本明細書に開示のシステムおよび方法は、プロバイダーによって、あるいはプロバイダーの代わりに入力された文書および問題リストに関連する１つ以上の変数について収集されるデータを監視するための制御チャートを利用できる。図１９の例は、特定のプロバイダーが、提供されるヘルスケアサービスを文書化する頻度に関連するｘバーチャート１６２およびＲ−チャート１６４の形での統計を表すＧＵＩ１６０を示す。このような統計的な基準は、産業制御では比較的一般的であるが、文書化挙動および課金挙動に関する独特の情報を提供する。よって、ＧＵＩおよび対応のレポート１６２および１６４は、１名以上のヘルスケアプロバイダーについての挙動情報を提供するよう利用可能である。この情報はたとえば、このようなプロバイダー各々の文書化挙動および対応の課金挙動を含み得る。

図１９の特定の例では、ＧＵＩ１６０は、文書化されている問題を特定のプロバイダーがアップデートする頻度に関連する日平均および日範囲の（平均パーセンテージでの）グラフィック表現を提供する。１名以上のプロバイダーについて、他の文書化関連基準に同様のチャートを作成可能である。また、ＧＵＩ１６０は、（ユーザー入力に応答して）それぞれのグラフに表されているデータのタイプの範囲を選択するための期間ユーザーインターフェースエレメントを含んでもよい。

図２０は、事業場（たとえば、ヘルスケアまたは他のサービス指向の事業場）における１名以上のプロバイダーの文書化挙動および課金挙動の評価を容易にするのに利用可能なルールベースのツール２００の例を示す。ツール２００は、ルールエンジン２０２を含む。ルールエンジン２０２は、文書化挙動および／または課金挙動を評価するのに有用なパラメーター２０４を評価して識別するためのルール（たとえば、式）を作成し、コンフィギュレーションする目的でプログラム可能である。ルールエンジンは、たとえば、図１の解析エンジン１６の一部として実現されてもよいし、そうでなければ、本明細書に開示のさまざまな計算を計算するために解析エンジン１６によって利用されてもよい。たとえば、選択されたルールを、パラメーター２０４としてメモリーに格納可能である。このパラメーターは、（たとえば、図１のパラメーターセレクター２０によって）選択し、（たとえば、図１の計算部１８によって）本明細書に開示の対応する出力の作成に利用可能である。

ルールエンジン２０２は、ルールエンジンによる実行用にパラメーターセレクター２１０によって選択可能なルールを規定するルールデータ２０６を含む。ツール２００は、ルールデータ２０６によって規定されるルールに対応する式を規定するのに使用可能なユーザーインターフェース２１２を含み得る。たとえば、ユーザーインターフェース２１２は、ルールエンジン２０２によって、本明細書に開示するような関連の文書化および課金データ２１４に適用可能な患者データのタイプ、プロバイダーデータ、サービスラインデータ、このようなデータのサンプリング方法（たとえば、期間、グループまたはサービスライン、閾値など）などの式を規定する複数のフィールドを含んでもよい。式は、単一の式を含んでもよいし、あるいは、これには複数の式を含み得る。複数の式は、入れ子になった式であってもよい。各式は、ユーザーインターフェース２１２によって規定される基準に従って個々に構成可能である。それぞれの式とそれぞれのルールは、選択されたルールパラメーターに従って文書化および課金データ２１４に基づく出力を計算するために、ブール論理や、変数と式とを組み合わせる他の数学的および論理的な手段を利用可能である。

文書化および課金データ２１４は、ＥＨＲデータ２１６または他のデータ２１８を含んでもよい。このようなデータは、リアルタイムデータであってもよいし、その複製コピーであってもよい。後者の場合、たとえば、（ＥＨＲシステムの過剰な負荷を防ぐためなどで）解析用のＥＨＲシステムの外に保管されてもよい。他のデータ２１８は、プロバイダー、課金（たとえば、最終的な符号化課金データ）、患者ケアまたはそれに由来するデータ（たとえば、ヘルスケアダッシュボードシステムによるなど）に関する格納された情報を含んでもよい。よって、ルールエンジン２０２は、本明細書に開示するような１名以上のプロバイダーによって作成される文書化および課金データ２１４を評価するために、ユーザーによって規定されるルールを、多岐にわたる異なるタイプのデータに適用可能である。このようなルールエンジン２０２は、たとえば、関連の文書化および課金データの関係を探って理解する上でユーザーに大きな融通を持たせるものである。そこから発展する探索と理解を利用して、本明細書に開示のシステムおよび方法によって用いることが可能なパラメーター（たとえば、ルール）を規定することができる（たとえば、図１から図１９）。

このような探査の一部として、システム２００は、ユーザーが規定する制約に従ったデータ２１４についての、ルールエンジンによる計算を表す対応の出力２２２を作成するための出力生成部２２０を含み得る。出力２２２は、ユーザーに情報を提示するＧＵＩを含み得る。出力のタイプは、本明細書に開示したもののタイプ（たとえば、図１から図１９を参照のこと）そのものであってもよいし、類似の種類であってもよい。出力２２２は、ユーザーインターフェース２１２のコンテキスト内で作成可能であり、１つ以上の制約を変更するユーザー入力に応答して動的に（たとえば、リアルタイムまたはほぼリアルタイムで）アップデートできる。結果として、ユーザーは、データをどのようにして選択し、ソートし、比較し、あるいはルールエンジン２０２によって実施される計算に使用するかを制御する制約を規定する際に、大きな柔軟性を持つことになる。出力およびそれによって提供される情報を用いたユーザーの経験をもとに、選択されたルールおよびこのようなルールに関連する制約を、ユーザー入力に対する応答時などに、パラメーター２０４として格納可能である。ひいては、パラメーター２０４は、本明細書に記載の教示内容に基づいて、プロバイダーの関連の挙動を含む、ユーザーが構成可能なツールおよび文書化および／または課金に関連する比較統計を提供するためのワークフローで利用できる。

当業者であれば自明であるように、本発明の一部を、方法、データ処理システムまたはコンピュータープログラム製品として実施してもよい。したがって、本発明のこのような一部は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態あるいは、ソフトウェアとハードウェアとを組み合わせた実施形態の形態をとってもよい。さらに、本発明の一部が、媒体にコンピューター読み取り可能なプログラムコードを有する、コンピューター使用可能な記憶媒体上のコンピュータープログラム製品であってもよい。好適なコンピューター読み取り可能な媒体であれば、どのようなものを利用してもよく、一例として、静的記憶装置および動的記憶装置、ハードディスク、光学記憶装置および磁気記憶装置があげられるが、これらに限定されるものではない。

本明細書では、方法、システムおよびコンピュータープログラム製品のフローチャート図を参照して、本発明の特定の実施形態について説明してきた。図示のブロックならびに、図示のブロックの組み合わせを、コンピューターで実行可能な命令によって実装してもよいことは、理解できよう。これらのコンピューターで実行可能な命令を、汎用コンピューター、専用コンピューターあるいは、マシンを製造するための他のプログラム可能なデータ処理装置（または装置と回路の組み合わせ）の１つまたは２つ以上のプロセッサーに対して、プロセッサーによって実行する命令が１つまたは複数のブロックに示される機能を実装するように供給してもよい。

これらのコンピューターで実行可能な命令は、コンピューターまたは他のプログラム可能なデータ処理装置を、コンピューター読み取り可能なメモリーに格納された命令が、フローチャートのブロックに示される機能を実装する命令を含む製品につながるように、特定の方法で機能させることのできるコンピューター読み取り可能なメモリーに格納されてもよい。また、コンピュータープログラムの命令を、コンピューターまたは他のプログラム可能なデータ処理装置にロードして、このコンピューターまたは他のプログラム可能な装置に一連の動作ステップを実施させ、コンピューターまたは他のプログラム可能な装置上で実行する命令によって、フローチャートの１つまたは複数のブロックに示される機能を実装するためのステップが得られるように、コンピューターで実装されるプロセスを生成してもてもよい。

以上説明してきたものは、例である。もちろん、構成要素または方法論の考えられるすべての組み合わせを説明するのは不可能であるが、多くの他の組み合わせおよび入れ替えが可能であることは、当業者であれば認識するであろう。したがって、本発明は、添付の特許請求の範囲を含めて本出願の範囲に入るこのような変更、修正および改変をすべて包含することを意図している。本明細書で使用する場合、「含む」という表現は、含むがこれに限定されるものではないことを意味し、「含んでいる」という表現は、含んでいるがこれに限定されるものではないことを意味する。「基づく」という表現は、少なくとも部分的に基づくことを意味する。また、開示内容または特許請求の範囲で「不定冠詞ａ」、「不定冠詞ａｎ」、「第１の」または「もうひとつの」要素あるいはこれと同等のものが用いられる場合、これは、このような要素が１つまたは２つ以上含まれると解釈されるべきであり、このような要素が２つまたはそれ以上であることを求めるものでもなければ、排除するものでもない。

Claims (16)

1. コンピューターで実行可能な命令と、１以上のプロバイダーによって顧客ごとに提供されたサービスに基づいて文書化された個別の問題にそれぞれ対応する複数のデータエレメントによって表される顧客データを含む事業場データと、を格納するためのメモリーと、
   前記メモリーにアクセスし、前記コンピューターで実行可能な命令を実行するよう構成されたプロセッサーと、を含むシステムであって、
   前記プロセッサーは、
   ある期間中に１以上のプロバイダーによって文書化された複数の個別の問題に対応する、ある数のデータエレメントにアクセスするための少なくとも一つのインターフェイスと、
   アクセスされた前記データエレメントの数に基づいて、前記期間中に１以上のプロバイダーによって文書化された、個別の問題の数を計算し、
   前記期間中に前記１以上のプロバイダーの文書化挙動を客観的に評価する記述統計を、前記個別の問題の数に基づいて計算する
   ための解析エンジンと、
   前記記述統計の出力を生成するための出力制御部と、を含む、システム。
2. 前記事業場は医療事業所であり、
   各プロバイダーはヘルスケアプロバイダーであり、各顧客は患者であり、
   前記顧客データは、特定のヘルスケアプロバイダーによって入力される、あるいは、特定のプロバイダーに代わって入力される患者データを含み、
   前記患者データは、電子カルテ（ＥＨＲ）システムに格納され、
   前記記述統計はさらに、前記医療事業所において少なくとも一つのヘルスケアプロバイダーに対する各患者についての問題の数を示す統計を含む、請求項１に記載のシステム。
3. 前記コンピューターで実行可能な命令は、前記記述統計を計算するために前記解析エンジンによって利用されるパラメーターを選択するようプログラムされる、パラメーター選択部をさらに含む、請求項２に記載のシステム。
4. 前記パラメーター選択部は、ユーザー入力に応答してデータレベルを選択するようプログラムされ、ここで、前記データレベルは、前記医療事業所、サービスライン、プロバイダー、および患者を含む群から選択されるか、または、
   前記パラメーター選択部は、前記記述統計を計算するために前記解析エンジンによって前記事業場データに適用される少なくとも１つのルールを選択するようプログラムされる、
   請求項３に記載のシステム。
5. 前記患者データは、前記ＥＨＲシステムに格納された問題リストデータを含み、
   前記問題リストデータは、前記特定のプロバイダーによる前記患者の治療または管理のうちの少なくとも１つを記載する、請求項２〜４のいずれか１項に記載のシステム。
6. 前記事業場データは、前記特定のプロバイダーによってあるいは前記特定のプロバイダーに代わって入力される前記顧客データに基づいて導かれるデータであって、患者のエンカウンターに関連する最終的な符号化文書を表す解釈されたデータをさらに含む、請求項５に記載のシステム。
7. 前記解析エンジンは、前記問題リストデータを含む選択された一組の前記患者データと、前記解釈されたデータとの間の比較統計を計算するようプログラムされる計算部をさらに含む、請求項６に記載のシステム。
8. 前記計算部は、前記一組の患者データと前記解釈されたデータとの間で計算される前記比較統計に基づいて、少なくとも１つの特定のプロバイダーの文書化挙動および課金挙動のうちの少なくとも１つにおける異常を識別するようプログラムされる、請求項７に記載のシステム。
9. 各患者について前記解釈されたデータは、あらかじめ規定された一組の予想コードを用いて前記プロバイダーによって入力される、前記患者データから導かれる最終的な患者符号化データを含み、
   前記あらかじめ規定された一組の予想コードは、国際疾病分類（ＩＣＤ）コード、診断群分類（ＤＲＧ）コード、問題リストコードのうちの少なくとも１つを含む、請求項８に記載のシステム。
10. 前記出力制御部は、前記記述統計の経時変化を動的に可視化するために、前記記述統計のアニメ化されたグラフィック表現を提供するようプログラムされる、請求項１〜９のいずれか１項に記載のシステム。
11. 前記出力制御部は、少なくとも２名のプロバイダーの文書化挙動または課金挙動のうちの少なくとも１つについての比較統計を示すスコアカード出力表現を提供するようプログラムされる、請求項１から９のいずれか１項に記載のシステム。
12. 前記解析エンジンは、文書化挙動に対応する前記事業場データと、前記プロバイダーのうちの選択された１名以上についての課金挙動に対応する別の一組の前記事業場データとの比較に基づいて、前記記述統計を計算するようプログラムされる、請求項１〜１１のいずれか１項に記載のシステム。
13. 前記解析エンジンは、ユーザーが規定するカテゴリーについて、逃した文書化の機会を計算するようプログラムされる計算部を含み、
    前記逃した文書化の機会は、前記文書化挙動と対応する前記事業場データと、前記課金挙動と対応する前記事業場データとの比較をもとに検出される、請求項１２に記載のシステム。
14. コンピューターで実行可能な命令と、特定の事業場プロバイダーによって顧客ごとに提供されたサービスを文書化するための情報を表す顧客データを含む事業場データと、を格納するためのメモリーと、
    前記メモリーにアクセスし、前記コンピューターで実行可能な命令を実行するよう構成されたプロセッサーと、を含むシステムであって、
    前記プロセッサーは、
    前記顧客データ中のプロバイダーによって文書化された顧客の問題に基づいて、１名以上のプロバイダーによって提供された前記サービスに関する記述統計を計算するための解析エンジンと、
    前記記述統計の出力を生成するための出力制御部と、を含み、
    前記出力制御部は、少なくとも２名のプロバイダーの文書化挙動または課金挙動のうちの少なくとも１つについての比較統計を示すスコアカード出力表現を提供するようプログラムされる、システム。
15. コンピューターで実行可能な命令と、特定の事業場プロバイダーによって顧客ごとに提供されたサービスを文書化するための情報を表す顧客データを含む事業場データと、を格納するためのメモリーと、
    前記メモリーにアクセスし、前記コンピューターで実行可能な命令を実行するよう構成されたプロセッサーと、を含むシステムであって、
    前記プロセッサーは、
    前記顧客データ中のプロバイダーによって文書化された顧客の問題に基づいて、１名以上のプロバイダーによって提供された前記サービスに関する記述統計を計算するための解析エンジンと、
    前記記述統計の出力を生成するための出力制御部と、を含み、
    前記解析エンジンは、文書化挙動に対応する前記事業場データと、前記プロバイダーのうちの選択された１名以上についての課金挙動に対応する別の一組の前記事業場データとの比較に基づいて、前記記述統計を計算するようプログラムされる、システム。
16. 前記解析エンジンは、ユーザーが規定するカテゴリーについて、逃した文書化の機会を計算するようプログラムされる計算部を含み、
    前記逃した文書化の機会は、前記文書化挙動と対応する前記事業場データと、前記課金挙動と対応する前記事業場データとの比較をもとに検出される、請求項１５に記載のシステム。