ウィジェット型アプリケーションにおける臨床要素の抽出、保持、及び送信のシステム及び方法
【課題】ウィジェット型アプリケーションにおいて臨床要素の抽出、保持、及び送信を提供する。
【解決手段】臨床データ要素通信システムが、利用者へのグラフィック表示のために複数の臨床情報源から検索される臨床コンテンツを含むユーザ・インタフェイスを含む。ユーザ・インタフェイスは、アプリケーション及び患者データを含む表示されている臨床コンテンツとの利用者相互作用を容易にする。システムは、臨床コンテンツの保持エリアと、臨床コンテンツを受取者へ送信する送信ユニットとを含んでいる。保持エリアは、ユーザ・インタフェイスの一部として表示されて、利用者によって選択されて当該保持エリアに投入された臨床コンテンツを保持する。臨床要素送信ユニットは、保持エリアに投入された臨床コンテンツを受け取り、臨床コンテンツをパッケージ化して、臨床コンテンツを電子的データ・メッセージとして受取者へ送信する。
【解決手段】臨床データ要素通信システムが、利用者へのグラフィック表示のために複数の臨床情報源から検索される臨床コンテンツを含むユーザ・インタフェイスを含む。ユーザ・インタフェイスは、アプリケーション及び患者データを含む表示されている臨床コンテンツとの利用者相互作用を容易にする。システムは、臨床コンテンツの保持エリアと、臨床コンテンツを受取者へ送信する送信ユニットとを含んでいる。保持エリアは、ユーザ・インタフェイスの一部として表示されて、利用者によって選択されて当該保持エリアに投入された臨床コンテンツを保持する。臨床要素送信ユニットは、保持エリアに投入された臨床コンテンツを受け取り、臨床コンテンツをパッケージ化して、臨床コンテンツを電子的データ・メッセージとして受取者へ送信する。
【発明の詳細な説明】
【背景技術】
【０００１】
病院又は診療所のような健康管理環境は、病院情報システム（ＨＩＳ）、放射線科情報システム（ＲＩＳ）、臨床情報システム（ＣＩＳ）、及び心血管情報システム（ＣＶＩＳ）のような情報システムや、画像保管及び通信システム（ＰＡＣＳ）、図書館情報システム（ＬＩＳ）、及び電子カルテ（ＥＭＲ）のような記憶システムを含む。記憶される情報としては、例えば患者の医療履歴、撮像データ、検査結果、診断情報、管理情報、及び／又は予定情報等がある。これらの情報は、集中型で記憶されてもよいし、複数の位置に分割されていてもよい。医師は、健康管理ワークフローの様々な点において患者情報又は他の情報を入手することを欲する場合がある。例えば、手術時及び／又は手術後に、医療従事者は、医療情報システムに記憶されている患者の解剖学的構造の画像のような患者情報にアクセスすることができる。放射線科医及び／又は他の臨床医は、例えば記憶されている画像及び／又は他の情報を検討することができる。
【０００２】
ＰＡＣＳ及び／又は他のワークステーションを用いて、放射線科医のような臨床医は画像読影のような多様な活動を行なって臨床ワークフローを促進することができる。放射線処置又は心臓医療処置での読影のような解釈は、放射線科医又は心臓医のように患者のディジタル画像を観察する医師の工程である。医師は診断画像の内容に基づいて診断を行ない、電子的に（例えば口述若しくは他の方法を用いて）又は書面で結果を報告する。放射線科医又は心臓医のような医師は典型的には、診断を行なうために他のツールを用いる。他のツールの幾つかの例としては、事前検査及び関連する過去の（履歴）検査及び検査結果、検査室での検査（血液検査等）、アレルギー、病理学検査結果、投薬、注意事項、文書画像、並びに他のツール等が挙げられる。例えば、放射線科医又は心臓医は典型的には、検査結果を解釈するときには検査室情報、電子カルテ、及び健康管理情報のような他のシステムを調べる。
【０００３】
現在のＰＡＣＳ及び／又は他の検討用システムは、全ての利用可能な医療情報を利用者のために画面に提供する。しかしながら、この情報は整理されていない。加えて、現状では、これらのデータ要素の何れが重要で何れが重要でないかを利用者に伝える方法が存在しない。データの単なる拾い読み（ブラウジング）は医師のワークフローの著しい妨げとなり、しばしば所望の末端利用者の成果を挙げることができないため、大きな問題を孕む。
【０００４】
様々な臨床情報システムを通じて多様な臨床データ及び医療文書記録が入手可能であるが、医療の或る点において情報を見出し、整理して、医師及び他の医療従事者に実効的に提示することは現状では困難である。この課題に関連する無数の困難が存在する。現在のシステム及び方法は、単一のデータ・ソースに対して静的な問い合わせ（クエリ）を行ない、これにより一般的には、関連しているかも知れないし関連していないかも知れず、典型的には不完全な情報を返す。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
近年の研究に基づくと、計算機での医師の指示入力の誤りがこの約５年で増大している。２００６年の“The Journal of the American Medical Informatics Association”によれば、コンピュータ入力誤りによる意図しない不都合な結果は、次の九つの範疇に大別される（頻度の降順で）。すなわち、１）臨床医のさらなる業務／新たな業務、２）好ましくないワークフロー問題、３）際限のないシステム要求、４）書面の永続性に関連する問題、５）連絡パターン及びの慣行の厄介な変更、６）負の情動、７）新たな種類の誤りの発生、８）権力構造の予期しない変化、並びに９）技術への過剰依存である。利用し難さ及び不十分なユーザ・インタフェイス設計が、これらの範疇の全てではないにせよ殆どに寄与している。
【課題を解決するための手段】
【０００６】
本発明の幾つかの実施形態の例は、ウィジェット型アプリケーションにおける臨床要素の抽出、保持、及び送信を提供するシステム及び方法を提供する。
【０００７】
幾つかの例は、適応型ユーザ・インタフェイスを介して適応型の業務中心（work-centered）健康管理サービスを提供するシステム及び方法を提供する。臨床データ要素通信システムの一例が、利用者へのグラフィック表示のために複数の臨床情報源から検索される臨床コンテンツを含むユーザ・インタフェイスを含んでいる。ユーザ・インタフェイスは、アプリケーション及び患者データを含む表示されている臨床コンテンツとの利用者相互作用（対話）を容易にする。このシステムの例はまた、臨床コンテンツの保持エリアと、臨床コンテンツを１又は複数の受取者へ送信する送信ユニットとを含んでいる。保持エリアは、ユーザ・インタフェイスの一部として表示されて、利用者によって選択されて当該保持エリアに投入された臨床コンテンツを保持する。臨床要素送信ユニットは、保持エリアに投入された臨床コンテンツを受け取り、臨床コンテンツをパッケージ化して、臨床コンテンツを電子的データ・メッセージとして１又は複数の受取者へ送信する。
【０００８】
また、臨床データ要素通信の方法の一例が、複数の臨床情報源から検索されて利用者に対してグラフィック表示される臨床コンテンツを選択する利用者入力を受け入れるステップであって、臨床コンテンツは臨床アプリケーション及び患者データを含んでいる、受け入れるステップを含んでいる。この方法の例はまた、利用者によって選択されて、ユーザ・インタフェイスの一部として表示される保持エリアに投入された臨床コンテンツを一時的に記憶するステップを含んでいる。この方法の例はさらに、保持エリアから一時的に記憶された臨床コンテンツを含む電子的データ・メッセージを生成するステップを含んでいる。加えて、この方法の例は、電子的データ・メッセージを１又は複数の受取者へ送信するステップを含んでいる。
【０００９】
また、コンピュータ可読の媒体の一例が、実行されるとデータ要素通信システムを具現化するコンピュータでの実行のための一組の命令を含んでいる。この一組の命令によって具現化されるシステムは、利用者へのグラフィック表示のために複数の情報源から検索される電子的データ要素を含むユーザ・インタフェイスを含んでいる。ユーザ・インタフェイスは、表示されている電子的データ要素との利用者相互作用を容易にする。このシステムはまた、ユーザ・インタフェイスの一部として表示される保持エリアを含んでいる。保持エリアは、利用者によって選択されて当該保持エリアに投入された１又は複数の電子的データ要素を保持する。システムはさらに、保持エリアに投入された１又は複数の電子的データ要素を受け取り、１又は複数の電子的データ要素をパッケージ化して、１又は複数の電子的データ要素を電子的データ・メッセージとして１又は複数の受取者へ送信するデータ要素送信ユニットを含んでいる。
【図面の簡単な説明】
【００１０】
【図１】本発明の幾つかの実施形態による適応型の業務中心健康管理サービスを提供するワークフローを示す図である。
【図２】本発明の一実施形態による適応型ユーザ・インタフェイスの一例を示す図である。
【図３】図２に関連して記載されるユーザ・インタフェイスのようなユーザ・インタフェイスを含むモバイル装置の一例を示す図である。
【図４】本発明の一実施形態による周産期診療における適応型の業務中心ユーザ・インタフェイスのユース・ケースの一例を示す図である。
【図５】本発明の幾つかの実施形態によるユーザ・インタフェイス・アーキテクチャを示す図である。
【図６】本発明の一実施形態によるアクティブ・リスニング及び応答能力を含む適応型ユーザ・インタフェイス・システムの一例を示す図である。
【図７】本発明の幾つかの実施形態による適応型の業務中心ユーザ・インタフェイス及び支援アーキテクチャを介した健康管理コンテンツへのアクセスの方法の流れ図である。
【図８】本発明の幾つかの実施形態による１又は複数の臨床要素の選択、選択された要素（１又は複数）の保持、及び選択された臨床要素（１又は複数）の１又は複数の受取者への送信を可能にする保持エリア及びツールの一例を示す図である。
【図９】本発明の幾つかの実施形態による受取者によって受け取られるメッセージであって、図８のツールを介して利用者によって選択された被選択臨床要素に関する展開された詳細を含むメッセージの一例を示す図である。
【図１０】本発明の幾つかの実施形態による１又は複数のアプリケーション又はウィジェットからの１又は複数の臨床要素の選択、保持、及び１又は複数の受取者への送信を容易にするウィジェット・システムの一例を示す図である。
【図１１】本発明の幾つかの実施形態による１又は複数のアプリケーション又はウィジェットからの１又は複数の臨床要素の選択、保持、及び１又は複数の受取者への送信を容易にする方法の流れ図である。
【図１２】本書に記載されるシステム及び方法を具現化するのに用いられ得るプロセッサ・システムの一例のブロック図である。
【発明を実施するための形態】
【００１１】
以上に述べた概要、及び本発明の幾つかの実施形態の以下の詳細な説明は、添付図面と共に読まれるとさらに十分に理解されよう。本発明を説明する目的で、幾つかの実施形態を図面に示す。但し、本発明は添付図面に示されている構成及び手段に限定されないことを理解されたい。
【００１２】
幾つかの実施形態は、複数の事業体（エンタープライズ）システムに跨がる末端利用者による情報へのアクセスを提供する。幾つかの実施形態は、末端利用者が健康管理網を横断してシームレスに医療情報にアクセスし、医療情報を入力し、また検索することを可能にする探索主導型、ロール・ベース、ワークフロー・ベース、及び／又は疾患ベースのインタフェイスを提供する。幾つかの実施形態は、個々の需要に合わせて特化され業務ドメイン（work domain）の変化に応答する業務中心インタフェイスを通じて適応型ユーザ・インタフェイス能力を提供する。幾つかの実施形態は、二つの新規の概念を具現化した適応型の業務中心ユーザ・インタフェイス技術ソフトウェア・アーキテクチャを導入する。第一の概念は、「業務中心」の活動の観点からの業務ドメイン、及び「業務中心」の活動を支援する具現化形態を達成する計算機構を特徴付けるために、オントロジー・モデル生成アプローチを用いるものである。第二の概念は、業務中心の特徴付け、及びエンタープライズ・レベルのアプリケーションへのユーザ・インタフェイスの提示機構において、適応型相互作用を利用者指向型及び自動型の両方で提供するものである。
【００１３】
健康管理情報システムは、利用者が患者診療の時間線にわたって関連情報を見出して活用し得るときに最も実効的になる。適応型ユーザ・インタフェイスは、セマンティック技術を強化して、例えばドメイン概念、利用者のロール（役割）及びタスク（作業）、並びに情報関係をモデル化することができる。セマンティック・モデルによって、アプリケーションが、利用者及びタスクのコンテキスト情報に基づいてさらに実効的に情報を見出し、整理して、利用者に提示することを可能にする。アプリケーションは、マルチ・コンテンツ及びマルチ・メディア情報を表示する情報ウィジェットのライブラリで構成され得る。加えて、この枠組みによって、利用者が、ウィジェットのレイアウトを特化して、基礎となるデータと相互作用することを可能にする。
【００１４】
一例では、新たなレベルの適応型ユーザ・インタフェイス設計が、セマンティック・ウェブ技術を利用することにより達成される。ドメインの概念及び関係はオントロジーの階層として特徴付けられ、上位レベルのオントロジー型構成体に関連付けられて適応型の推論及び拡張性を可能にする。
【００１５】
このように、幾つかの実施形態は、個々の需要に合わせて特化され業務ドメインの変化に応答する業務中心アプリケーションを利用者に提示するために、オントロジーのメタデータについて「推論」し得る制御器の利用を介して適応型ユーザ・インタフェイス能力を提供する。目標とされる情報は、アプリケーション・コンテキスト感受型の態様で「外部」データから送り届けられ得る。
【００１６】
人間−コンピュータ間の相互作用では、ユーザ・インタフェイス・データ、イベント、及び頻度を表示し、記録して、エピソードとして整理することができる。画面でのデータ配置、エピソード頻度、及び含意関係を算出することにより、幾つかの実施形態の例は、特定アプリケーション向けのエピソード連関を自動的に導いて、従ってアプリケーション・インタフェイスが利用者に対し時宜に適った援助を適応的に与えることを可能にすることができる。相互作用追跡、エピソード識別、利用者パターン認識、利用者意図予測、及び利用者プロファイル更新を含めた適応型ユーザ・インタフェイスを設計することに関連する問題を識別することにより、利用者のために動作して幾つかの認識された計画に基づいてアプリケーションと相互作用し得るインタフェイスが生成される。様々な利用者の需要に適応するために、インタフェイスは、例えば利用者プロファイル及び特定疾患向けワークフローを学習することにより援助を個人別に構成することができる。
【００１７】
幾つかの実施形態では、適応型ユーザ・インタフェイス・システムが、例えば検索エンジン、ウェブ・サーバ、アクティブ・リスナ（能動的聴取者）、情報編成（information composition）エンジン、クエリ・エンジン、データ集計器、文書要約器、プロファイル・コンテキスト・マネージャ、並びに臨床及び管理用ダッシュボードを含んでいる。幾つかの実施形態は、特定利用者向け、特定ロール向け、特定疾患向けの態様で一つの患者カルテ記録全体の完全な像を提供する。幾つかの実施形態では、ユーザ・インタフェイスはまた、データの操作像、データの財務像を提供するように構成されることができ、また任意の形式のデータ集計のためのダッシュボードとなり得る。
【００１８】
幾つかの実施形態は、適応型の業務中心ユーザ・インタフェイス技術ソフトウェア・アーキテクチャを提供する。このアーキテクチャは、「業務中心」の活動の観点からの業務ドメイン、及び「業務中心」の活動を支援する具現化形態を達成する計算機構を特徴付けるために、オントロジー・モデル生成アプローチを用いるものである。このアーキテクチャはまた、業務中心の特徴付け、及びエンタープライズ・レベルのアプリケーションへのユーザ・インタフェイスの提示機構において、適応型相互作用を利用者指向型及び自動型の両方で提供する。
【００１９】
業務中心型ソリューションは、業務を達成する設定されたコンテキストに従って利用者相互作用をカスタマイズすることにより、柔軟で適応自在の態様で業務への支援を提供する統合され特化されたシステムを提供することを支援する。業務中心アプローチの下で、目標とされる業務ドメイン全体の理解を発展させる。例えば、業務ドメインの理解を発展させるのに用いられる質問として、業務ドメインが含んでいるものは何か、業務の目標は何か、業務ドメインに誰が参加しているか、及び参加者はローカルなコンテキストが与えられたときに業務ドメインの目標を如何にして達成するか等が挙げられる。この業務ドメインの理解を用いて、参加者の日々の活動を特徴付けし、従って支援することができる。
【００２０】
幾つかの実施形態では、アクティブ・リスナ・エージェントが、コンピュータ装置、及び／又はユーザ・インタフェイスのようなソフトウェア・アプリケーションのフォアグラウンド及び／又はバックグラウンドで動作して、利用者及びプログラムの活動を監視する。例えば、アクティブ・リスナ・エージェントは、ユーザ・インタフェイスのウィジェットに関係する情報を集めることができる。また、アクティブ・リスナ・エージェントは、例えばユーザ・インタフェイス及びユーザ・インタフェイスのコンテンツに関して利用者によって生成される行動（アクション）に関係する情報を集めることができる。
【００２１】
幾つかの実施形態では、アプリケーション（例えばウィジェット）情報及び利用者相互作用に基づいて、アクティブ・リスナ・エージェントは、現在のコンテキストに基づいて利用者にとって重要な情報及び／又は作用内容（functionality）を識別することができる。一実施形態では、ユーザ・インタフェイスに表示されている１又は複数のデータ要素が予め決められた閾値に達したことをアクティブ・リスナ・エージェントが検出した場合には、アクティブ・リスナは、利用者が十分な情報に基づく決定を下すことを可能にするのを補助する付加的な関連情報を含む１又は複数のウィジェットをユーザ・インタフェイスに自動的に配置する。もう一つの実施形態では、アクティブ・リスナ・エージェントは、アプリケーションとの利用者相互作用に反応することにより利用者を補助することができ、また利用者の行動の結果として表示されているユーザ・インタフェイスにウィジェット（１又は複数）の形態にある付加的な情報及び／又は他の情報を表示することにより付加的な見識を提供する。例えば、利用者が何らかのデータ要素を一つのウィジェットからもう一つのウィジェットへドラッグする（例えばマウス装置を用いた該当要素のカーソル選択及び表示されているインタフェイスを横断する移動を介して）と、アクティブ・リスナ・エージェントはこの情報を、表示されているインタフェイスにおいて、データ要素の構成が利用者が結論（例えば患者の診断及び／又は治療に関する）に到達するのを補助するのに有用な異なるレベルの情報を意味するように再配置することができる（例えば大きさ及び／又は位置）。次いで、アクティブ・リスナ・エージェントは、特定のシナリオにおいて有用であり得る既製の関連ウィジェットをインタフェイスに配置することもできるし、且つ／又はユーザ・インタフェイスにおいてデータ・コンテキストに加えて利用者が変更したウィジェットのコンテンツに基づいて、新たなウィジェットを作成することもできる。
【００２２】
予め決められたワークフローに焦点を合わせるよりも寧ろ、アクティブ・リスナは利用者に対し、既知のワークフロー又はプロトコルが存在しないような幾つかの状況において利用者にとって助けとなる付加的な情報を提供する。履歴データ及び／又は他の入力に基づいて、システムは、利用者が情報に基づいた決定を下すのに関連する付加的な情報及び／又は作用内容を利用者に対して表示する。例えばアプリケーション及び／又はインタフェイスのバックグラウンドにおいて、アクティブ・リスナは、表示されているインタフェイスでのデータ要素の活動を監視することができる。これらのデータ要素が何らかの閾値に達すると、アクティブ・リスナは、利用者が情報に基づいた決定を下すのを補助する付加的な情報を、表示されているインタフェイスに配置する。代替的に又は加えて、アクティブ・リスナは、利用者がアプリケーションに変更を加えたときを検出することができる（例えばデータ要素を一つのウィジェットからもう一つのウィジェットにドラッグ＆ドロップする、検索を行なう、及び診断を変更する等による）。利用者相互作用のコンテキストを表示されているユーザ・インタフェイスのコンテンツと組み合わせることにより、例えば利用者に関連情報及び／又は作用内容を提供することができる。
【００２３】
図１は、本発明の幾つかの実施形態による適応型の業務中心健康管理サービスを提供するワークフロー１００を示す。ワークフロー１００は、医師、病院及び診療所等への患者の来診１０５を含む。患者来診１０５から、クエリ（query）１１０が、検査医及び看護師等のような臨床担当者によって発生される。クエリ１１０は、例えば観察される刺激１１２と患者コンテキスト１１４とを含み得る。クエリ１１０はクエリ・ドライバ１１５に渡される。クエリ・ドライバ１１５は、例えば１又は複数のデータ・ソース１２０及び／又は知識管理サブシステム１６０に問い合わせることができる。データ・ソース（１又は複数）１２０は、検査室結果、診断検査（例えばＸ線、磁気共鳴画像及び超音波等）、患者履歴、保険情報、及び支払請求情報等の１又は複数を含み得る。
【００２４】
幾つかの実施形態では、クエリ・ドライバ１１５は、クエリ強化エンジン（「ＱＵＥＥＮ」）を含み、且つ／又はクエリ強化エンジンと通信することができる。情報は、テキスト（例えば報告及び書面）、テーブル（例えばデータベース）、画像（例えばＸ線及び計算機式断層写真法による走査）、及び動画（例えば手術手順）を含めた複数の形式として表わされ得る。さらに、情報はしばしば、様々なシステムに存在して、ヘテロな（異種のものから成る）環境において記憶され且つ／又は計算される。
【００２５】
クエリ強化エンジンは、情報需要（例えば刺激１１２）及びコンテキスト１１４に基づいて各種の情報源１２０から情報を検索するのに用いられ得る。先ず、元のクエリ１１０及びコンテキスト１１４に基づいて、ＱＵＥＥＮは、情報レジストリに照会することにより、要求された情報を検索するのに何れの情報源（１又は複数）１２０が最も適当であるかを決定する。
【００２６】
一旦、情報源候補（１又は複数）１２０が識別されたら、クエリ１１０が発生されて（クエリ強化エンジン１１５によって）、情報源１２０に渡されて検索される。異なるデータ・リポジトリ（repository）（ファイル・システム及びデータベース等）が、当該リポジトリの内部のデータを検索するために異なる機構を利用する。情報源１２０はこれらの検索機構を包含する。
【００２７】
検索結果の精度を高めるために、検索に先立ってクエリを修正すると有利な場合がある。クエリ強化は、結果を改善する付加的な項をクエリに加えることを含み得る。クエリの精緻化は、性能を高めるためにクエリに対して項を除去する又は項を置換することを含み得る。ＱＵＥＥＮ１１５は、初期クエリを用いて情報を要求し、次いで、例えば性能を高めるためにクエリを強化し又は精緻化することができる。
【００２８】
クエリ１１０は、１又は複数のデータ・ソース１２０からのデータと組み合わされて、情報編成エンジン（「ＩＣＥ」）１２５に与えられ、クエリ１１０に応答してデータ・ソース（１又は複数）１２０からのデータをコンパイルし又はバンドルする。ＩＣＥ１２５は、多数の各種データ・ソース１２０から提示（プレゼンテーション）のための情報をバンドルすることができる。
【００２９】
例えば、所与の情報需要について、目下の特定の作業についてセマンティックに意味のある情報のバンドルを形成するために、幾つかの異なる形式の情報が望ましい場合がある。一つのバンドルが１又は複数の形式の情報を含む（例えば患者履歴及び検査室結果）。様々な情報項目を複数の意味単位として整理することを情報編成又はバンドル化と呼ぶ。ＩＣＥ１２５は、データ・ソース（１又は複数）１２０から検索された情報をまとめて、利用者にとって意味のある一つのバンドルとして編成することを担当する。バンドルは、利用者のセマンティックな必要に基づいて編成されることができ、また例えば利用者のプレファレンス（選好）、及び／又はドメインに適した他の知識によって主導され得る。
【００３０】
幾つかの実施形態では、ＩＣＥ１２５は、編成器（コンポーザ）を用いて、データ・ソース（１又は複数）１２０から検索された情報を編成する。編成器は、例えば編成判定論理（「ＣＤＬ」）を用いて情報を編成する。ＣＤＬの幾つかの実例としては、例えば集計、冗長な情報の消去、情報の軽量要約、及び結果の融合等が挙げられる。
【００３１】
例えばアクティブ・リスナ構成要素を含む制御器が、ＱＵＥＥＮ１１５とＩＣＥ１２５との間の相互作用を管理することができる。ＱＵＥＥＮ１１５が情報を検索したら、この情報はＩＣＥ１２５に渡されて編成及びバンドル化を施された後に、アプリケーション又は利用者に送り届けられる。アクティブ・リスナ構成要素は、例えばＱＵＥＥＮ１１５によって検索されてＩＣＥ１２５に渡された情報を監視してこの情報に反応することができる。
【００３２】
編成時に、何らかの情報が欠落している又は不十分であると決定される場合がある。この場合には、ＩＣＥ１２５は、情報が欠落している／不十分であることを制御器に伝えることができる。次いで、制御器は、検索性能を高めるために１又は複数のクエリ１１０を強化し又は精緻化すべきであるとクエリ・エンジン１１５に伝えることができる。クエリ（１又は複数）１１０が再び行なわれて、結果がＩＣＥ１２５に返されて編成及びバンドル化を施された後に、例えば利用者に返される。
【００３３】
次いで、ＩＣＥ１２５は、クエリ１１０からのコンテキスト情報１１４に基づいて、要求した利用者のために編成されて特化された関連情報を含むバンドル１３０を生成する。バンドル１３０は要約エンジン１３５に渡される。要約エンジン１３５は、バンドル１３０のコンテンツについて多文書要約を提供する。要約については、後にあらためて詳述する。
【００３４】
要約エンジン１３５からの要約による注釈付きの改訂済みバンドル１４０を用いて、プレゼンテーション１４５を生成する。プレゼンテーションは、データ・ソース（１又は複数）１２０のメタデータ検索から返されたテキスト、動画及び画像から成るマルチ・メディア・バンドルを含むことができ、このバンドルは、要約エンジン１３５からのコンテキスト要約を含む。利用者は、プレゼンテーション１４５を通じて細部まで深く検討することができる。医師及び／又は看護師のような利用者は、プレゼンテーション１４５からの情報を用いて、患者をさらに詳細に診断し且つ／又は治療することができる。プレゼンテーション１４５情報からの利用者の反応及び／又は他のフィードバック１５０は、後の利用に備えて知識管理サブシステム１６０に戻され得る。幾つかの実施形態では、知識管理サブシステム１６０に対するアクティブ・リスナ構成要素が、例えば利用者の反応／フィードバック１５０に基づいて付加的なコンテンツ及び／又はアプリケーションを更新し且つ／又は提供する。
【００３５】
ここで、知識管理サブシステム１６０についてさらに詳細に説明する。知識管理サブシステム１６０は、クエリ・ドライバ１１５がデータ・ソース（１又は複数）１２０から関連情報を抽出するためのクエリを形成するのを支援する１若しくは複数のツール及び／又は付加的な情報を含んでいる。刺激１１２及びコンテキスト１１４のようなクエリ１１０情報を知識管理サブシステム１６０に入力して、関連ツール及び／又は情報をクエリ・ドライバ１１５に提供することができる。代替的に及び／又は加えて、臨床医の反応及び／又は他のフィードバック１５０をサブシステム１６０にフィードバックして、さらなる情報を与え、且つ／又は知識管理サブシステム１６０からのさらなる結果を改善することができる。
【００３６】
例えば図１に示すように、知識管理サブシステム１６０は、１又は複数のダッシュボード１６１、１又は複数のオントロジー１６３、手続き及びガイドライン１６５、共通データ・モデル１６７、並びに解析部１６９を含んでいる。知識管理サブシステム１６０は、知識及び用語管理基盤構造（Knowledge and Terminology Management Infrastructure、「ＫＴＭＩ」）をワークフロー１００に与えることができる。オントロジー１６３は、一つのドメインの内部での概念集合、及びこれらの概念の間の関係の形式的な表現を詳細に記述する。オントロジー１６３を用いて、ドメインを定義して、当該ドメインの特性を評価することができる。共通データ・モデル１６７は、特定の環境の内部での各種のデータ・エンティティの間の関係を定義し、データ・エンティティが意味を有するようなコンテキストを確立する。共通データ・モデル１６７は、ワークフロー１００において各アプリケーション及び各データ・ソースをカバーするデータ・モデルを与えて、ワークフロー１００の内部でのデータの関係及び意味を定義する。例えば、解析部１６９を用いて、サブシステム１６０は、共通データ・モデル１６７に基づいてダッシュボード（１又は複数）・コンテンツ１６１、オントロジー（１又は複数）１６３、及び手続き／ガイドライン１６５にアクセスして、クエリ・ドライバ１１５に出力を与えることができる。
【００３７】
ここで、要約エンジン１３５の活動についてさらに詳細に説明する。多文書要約は、同じ主題について書かれた多数のテキストからの情報の抽出（例えば多数の患者にわたる疾患）を目的とした自動式手順である。得られる要約報告によって、検査医及び看護師等のような個々の利用者が、多量の文書に含まれる情報を速やかに知悉することを可能にする。このように、要約エンジン１３５は、ＩＣＥ１２５を補完して、例えば参照をし易くするためにコンテンツを要約して註釈することができる。
【００３８】
多文書要約は、未処理データの検討よりも簡潔で包括的な情報報告を作成する。異なる意見をまとめて骨子を作成し、単一の文書の内部で多数の視点から主題を記述する。簡単な要約の目標は、最も関連するソース文書を指示することにより、情報検索を単純化して時間を短縮することにあるが、包括的な多文書要約は要約自体が要求された情報を含むべきであり、従って精緻化が必要とされる場合に元のファイルにアクセスする必要性を限定する。自動要約は、偏りのない結果を与える試みとして、如何なる編集加筆も主観的な人間の介在もなくアルゴリズム的に多数の情報源から抽出される情報を提示する。
【００３９】
しかしながら、多文書要約はしばしば、大きい文書集合の範囲内で扱われるテーマが多様であるため、単一の文書を要約するよりも複雑である。要約技術は、主文書の各テーマを完全性、読み易さ及び簡潔さと組み合わせることを目的とする。例えば、米国標準技術局によって毎年行なわれているDocument Understanding Conferencesを通じて開発された多文書要約の評価規準を用いることができる。
【００４０】
幾つかの実施形態では、要約エンジン１３５は、ソース・テキストを単に短縮するばかりでなく、ソース・テキストの主要な観点を巡って整理された情報を提示して、所与の主題についてのさらに多様な視点を表わす。かかる品質を達成すると、所与の主題の概要にさらに類似した自動式多文書要約を用いることができる。
【００４１】
多文書要約規準は、次の１又は複数を含み得る。すなわち、全テキスト・セクションをナビゲートすることを容易にする主コンテンツの骨子を含めた明確な構造、各セクションの内部のテキストが意味のある段落に分割されていること、一般的な観点から特定テーマの観点への緩やかな移行、及び読み易さ等であり、読み易さに関して述べると、自動式概要作成は、例えばそれぞれの文書（例えばウェブ・ページ）からの書面に無関係な「情報雑音」が存在しないこと、概要に述べられても説明されてもいない主題への懸垂参照（参照先のない参照）が存在しないこと、一つの文章を横断するテキスト分断が存在しないこと、及び意味論的な冗長性が存在しないこと等を呈し得る。
【００４２】
幾つかの実施形態では、要約アプローチは次の三つのステップを含んでいる。すなわち、１）セグメント分割、２）クラスタ生成／分類、及び３）要約生成である。最初のテキストのセグメント分割は、既存の段落境界に基づいて文書を段落に分割する又は「チャンキング（chunking）」することにより行なわれる。例えば副題及び一行段落はマージされ得る。段落境界が存在しない場合には、例えばＮ語毎（例えば２０語毎）に分割することによりチャンキングを実行することができる。
【００４３】
クラスタ生成について述べると、１又は複数の自然言語処理（「ＮＬＰ」）手法を適用して、例えば二つの語集合の間の類似性を測定することができる。例えば、類似した連語（例えばＮグラム）を含む段落を識別し、二つの節（パッセージ）が類似しているか否かを決定する類似度を定義する。例えば、類似度は、余弦関数に似た出力を与えることができる（例えば値が１に近い結果ほど類似性が大きいことを示す）。これらの尺度を用いて、節の対の全てについて節類似性スコアを算出することができる。
【００４４】
幾つかの実施形態では、多くの節が存在するときにはクラスタの全ての組み合わせを検査すると計算コストが高くなる。従って、クラスタ生成は、シード・クラスタ生成及び分類の二段階で行なわれ得る。シード・クラスタ生成では、標的数のクラスタが見出されるまで完全リンク（complete-link）アルゴリズムを用いることができる。例えば、標的数のクラスタはｌｏｇ（文書数）に等しくすることができる。次いで、分類では、最もよくマッチするシード・クラスタを見出すことにより残りの節を分類する。節が類似性を有しない場合には、この節はごみクラスタに配置される。
【００４５】
次いで、要約生成のために、最も特徴的な段落を各々のクラスタから取り出して、「メタ文書」を形成する。次いで、単一文書要約器を用いて、集合全体についての「要約」を作成する。要約は、情報とバンドルされて、バンドル１４０として与えられる。
【００４６】
作動時のワークフロー１００の一例として、患者に手術を行なうに先立って、医師が患者は如何なるアレルギーを有するかを知りたいと想定する。患者のアレルギーについての情報は、様々なシステムにおいて文書リポジトリ、ファイル・システム、及びデータベース１２０の組み合わせを用いて記憶され得る。ＩＣＥ１２５を用いて、患者のアレルギーについての多様な情報を見出し、バンドルして、医師に提示する。幾つかの文書の段落の内部に埋め込まれている情報もあれば、例えばデータベースのテーブルに見出される情報もある。システムのデータベースが公開されたときに（例えば連結性フレームワーク（Connectivity Framework）を通じて）、ＩＣＥ１２５及びＩＣＥ１２５のＱＵＥＥＮエンジンは、データベース１２０に接続して情報について問い合わせることができる。データベースが特定のシステムについては利用可能でないときにも、このシステムのための文書リポジトリを依然として探索することができる。文書要約器１３５を用いて、検索された文書の要約を与えて、検索された文書から関係する節をクラスタ化して、関係する患者情報を得る。情報はバンドル１４０として整理された後に利用者に届けられる。情報は、例えば基礎となるリポジトリから、情報形式、意味性、情報関連性、及び信頼性スコアに基づいて整理され得る。
【００４７】
幾つかの実施形態では、ワークフロー１００は、クエリ生成エンジン１１５を用いて連結性フレームワーク構成要素から関連情報を継続的に探索することにより利用者を支援する。続いて、利用者に対する適当なプレゼンテーションのために情報を変換する情報編成エンジン１２５を通じてこれらの結果を分類してバンドル化する。
【００４８】
幾つかの実施形態では、適応型ユーザ・インタフェイス（「ＵＩ」）設計が、セマンティック・ウェブ技術を利用することにより達成される。例えば、ドメインの概念及び関係をオントロジーの階層として特徴付けて、上位レベルのオントロジー型構成体に関連付けて適応型の推論及び拡張性を可能にする。
【００４９】
コア・オントロジーが、１又は複数の業務中心設計原理から導かれ得る。例えば、実効的なインタフェイスは、特定の形式の問題を解くために設定された業務ドメインに対して利用者が必要とする視点を表わす情報を表示することができる。もう一つの例として、現在の業務コンテキストにおいて利用者にとって最も重要な情報を焦点エリアに表示して、利用者の注意を引くことができる。コンテキストを保存して業務管理を支援するために、表示器の辺縁に参照情報を提供することができる。さらにもう一つの例として、利用者自身の業務オントロジー（例えば用語及び意味）が、インタフェイス表示の情報要素についての一次ソースであるものとする。
【００５０】
このように、幾つかの実施形態は、個々の需要に合わせて特化され業務ドメインの変化に応答する業務中心アプリケーションを利用者に提示するために、オントロジーのメタデータについて「推論」し得る制御器の利用を介して適応型ユーザ・インタフェイス能力を提供する。かかるユーザ・インタフェイス能力は、アプリケーション・コンテキスト感受型の態様で目標とされる情報を送り届けるインタフェイスを提供することにより、連結性フレームワークがアクセスし得る「外部」データを拾い読みすることに関連する問題を回避するのを補助する。
【００５１】
人間−コンピュータ間の相互作用では、ユーザ・インタフェイス・データ、イベント、及び頻度を表示し、記録して、エピソードとして整理することができる。表示画面に配置されるデータ、エピソード頻度、及び含意関係を算出することにより、特定アプリケーション向けエピソード連関を自動的に導いて、アプリケーション・インタフェイスが利用者に対し時宜に適った援助を適応的に与えるのを可能にすることができる。例えば相互作用追跡、エピソード識別、利用者パターン認識、利用者意図予測、及び利用者プロファイル更新を含めた適応型ユーザ・インタフェイスを設計することに関連する問題を識別することにより、インタフェイスは、利用者のために動作して幾つかの認識された計画に基づいてアプリケーションと相互作用することができる。様々な利用者の需要に適応するために、インタフェイスは、例えば利用者プロファイル及び特定疾患向けワークフローを学習することにより援助を個人別に構成することができる。
【００５２】
図２は、本発明の一実施形態による適応型ユーザ・インタフェイス（「ＵＩ」）２００の一例を示す。ＵＩ２００は、ログイン及び利用者識別エリア２０５、患者識別エリア２１０、警告２１２、及びウィジェット表示エリア２１５を含んでいる。利用者識別エリア２０５は、ＵＩ２００にアクセスするために現在ログインしている利用者を識別する。患者識別エリア２１０は、氏名、識別番号、年齢、性別、生年月日、社会保険番号、及び連絡先情報等のような目標患者についての識別情報を提供する。警告２１２は、患者はアレルギーを有しないという指標のように利用者に注意を促すための患者情報を提供し得る。ウィジェット表示エリア２１２は、ＵＩ２００を介して利用され利用者によって配置可能な１又は複数のウィジェットを含む。
【００５３】
例えば、図２に示すように、ウィジェット表示エリア２１２は、ウィジェット２２０、２３０、２４０、２５０、２６０、２８０を含んでいる。ウィジェットは、多様な情報、臨床判定支援、探索能力、及び臨床的作用内容等を提供し得る。例えば図２に示すように、ウィジェット２２０は、生命徴候／検査室ウィジェットである。生命徴候ウィジェット２２０は、患者についての１又は複数の生命徴候及び／又は検査室検査結果の視覚的指標を与える。例えば、指標は、血圧２２１、尿検査２２３、体重２２５、ブドウ糖２２７、及び体温２２９を含み得る。各々の指標が、型及び値を含む。例えば、血圧指標２２１は、型２２２（例えば血圧）及び値２２４（例えば２００／１３０）を含む。各々の指標２２１、２２３、２２５、２２７、２２９が、当該指標から成分情報の重要性を示すための何らかの色及び／又は何らかの大きさを有する。例えば、血圧指標２２１は、ウィジェット２２０において最も寸法が大きい指標であって、利用者に対し、他の結果を凌ぐ血圧測定値２２１の相対的な重要性を視覚的に示している。尿検査２２３は次に重要であり、以下同様である。もう一つの例として、血圧２２１を赤色とし、尿検査２２３を橙色とし、体重２２５を黄色とし、ブドウ糖２２７及び体温２２９の両方を緑色とする。色を用いて、成分値の重篤度又は重要度を示すことができる。例えば、赤色にした血圧２２１は最大の重要性を意味し、橙色にした尿検査２２３は次に重要であり、以下同様である。このように、指標の大きさ及び／又は色を共に及び／又は別個に用いて、利用者に対し、患者の生命徴候及び検査室結果の調査に置かれるべき優先順位の直接的な視覚的指標を与えることができる。幾つかの実施形態では、指標の選択によって、指標についての情報を生成するのに用いられたデータ、結果、及び／又は文書（１若しくは複数）を検索する。
【００５４】
ウィジェット２３０は、面談要約、報告、及び画像解析等のような患者に関係する臨床文書の一覧を提供する。文書情報は、文書型２３１、文書作成者２３２、文書日付２３３、文書からの評価２３４、文書状態２３５、及び文書に対する行動２３６を含み得る。例えば、文書ウィジェット２３０のエントリは、来診要約型２３１であり、アマンダ・ミラー医師の作成者２３２によって２００８年３月１２日の日付２３３に生成され、子癇前症の可能性との診断２３４であって、状態２３５が署名済みであり、行動２３６が検討であり得る。利用者は、文書エントリを選択して、ウィジェット２３０に参照されている実際の文書を検索して表示することができる。
【００５５】
ウィジェット２４０は、利用者による検討のための１又は複数の撮像検査を提供する。撮像検査ウィジェット２４０は、１又は複数の画像２４４を撮像型２４６及び評価２４８と共に含んでいる。例えば、図２に示すように、ウィジェット２４０は、正常と評価された頭部ＣＴ及び正常と評価された胎児超音波画像を含んでいる。
【００５６】
ウィジェット２５０は、患者について識別された１又は複数の問題２５２、２５４の視覚的表現を提供する。生命徴候ウィジェット２２０と同様に、問題指標２５２、２５４は、何らかの色及び／又は何らかの大きさを有して、問題指標からの成分情報の重要性を示すことができる。例えば、高血圧問題指標２４２は赤色にされて他の問題指標２５４よりも大きい。このように、指標の大きさ及び／又は色を共に及び／又は別個に用いて、利用者に対し、患者問題の調査に置かれるべき優先順位の直接的な視覚的指標を与えることができる。幾つかの実施形態では、問題指標の選択によって、指標についての情報を生成するのに用いられたデータ、結果、及び／又は文書（１若しくは複数）を検索する。
【００５７】
ウィジェット２６０は、患者の来診の１又は複数の理由を利用者に提供する。来診理由ウィジェット２６０は、理由２６２と、利用者が付加的な詳細を表示するために理由２６２を展開する又は付加的な詳細を隠すために理由２６２を収縮させることを可能にするアイコン２６４とを含んでいる。理由２６２は、ウィジェット２２０、２５０からの指標と同様に色分けされて、優先順位、重要性、及び重篤性等の視覚的指標を与えることができる。
【００５８】
ウィジェット２７０は、患者に処方された薬物の一覧を提供する。薬物ウィジェット２７０は、薬物の型２７２、当該薬物の量２７４、及び当該薬物の送達機構２７６を含んでいる。幾つかの実施形態では、薬物の選択は、例えば当該薬物についてのさらなる詳細及び関連する指示を展開することができる。
【００５９】
例えば図２に示すように、利用者はカーソル２８０を操作して、ウィジェットを選択して、ウィジェットを位置２８５に配置することができる。このように、利用者は表示のためのウィジェットを選択し、次いで、ＵＩ２００のウィジェット表示エリア２１５での各ウィジェットのレイアウトを構成することができる。代替的に及び／又は加えて、利用者は、ウィジェット表示エリア２１５においてウィジェットを再配置して、ＵＩ２００のレイアウトを修正することができる。例えば、カーソル２８０を用いて、利用者は、ウィジェット表示エリア２１５の何らかの地点２８５に来診理由ウィジェット２６０を配置することができる。
【００６０】
ＵＩ２００はまた、利用者別ダッシュボード２９２、患者一覧２９４、及び設定／プレファレンス・パネル２９６等のような他の臨床作用内容への１又は複数のリンクを提供することができる。
【００６１】
幾つかの実施形態によって、健康管理情報システムが患者診療の時間線を横断して関連情報を見出して活用することを可能にする。例えば、探索主導型ロール・ベースのインタフェイスによって、末端利用者が、健康管理網を横断してシームレスに医療情報にアクセスし、医療情報を入力し、また検索することを可能にする。適応型ユーザ・インタフェイスが、個々の需要に合わせて特化され、例えば業務ドメインの変化に応答する業務中心インタフェイスを通じて諸能力を提供する。セマンティック技術を強化して、ドメイン概念、利用者のロール及びタスク、並びに情報関係をモデル化することができる。セマンティック・モデルによって、アプリケーションが、利用者及びタスクのコンテキスト情報に基づいてさらに実効的に情報を見出し、整理して、利用者に提示することを可能にする。クエリ及び結果生成のための枠組みを形成する構成要素としては、アプリケーションを構築するためのユーザ・インタフェイス・フレームワーク／構成要素、セマンティック情報及びコンテキストに基づくさらに効率のよい検索、集計、及び情報の編成を可能にするサーバ構成要素、並びにヘテロな情報源を分散環境において接続するデータ・アクセス機構等が挙げられる。
【００６２】
Microsoft（商標）ASP.NET、Ajax（商標）、Microsoft（商標）Windows Presentation Foundation、Google（商標）Web Toolkit、Microsoft（商標）Silverlight、Adobe（商標）、及び他を含めた多様なユーザ・インタフェイスのフレームワーク及び技術を用いてアプリケーションを構築することができる。アプリケーションは、例えばマルチ・コンテンツ及びマルチ・メディア情報を表示するための情報ウィジェットのライブラリから構成され得る。加えて、フレームワークによって、利用者が、ウィジェットのレイアウトを特化して、基礎となるデータと相互作用することを可能にする。
【００６３】
健康管理情報は、多様なデータベース及び記憶（ストレージ）技術、並びにデータ型を用いて多数のアプリケーションに分散され得る。これらのアプリケーションを横断して存在するデータへの共通のインタフェイス及びアクセスを提供するために連結性フレームワーク（「ＣＦ」）を提供し、連結性フレームワークは、共通データ・モデル及び共通サービス・モデル（「ＣＤＭ」及び「ＣＳＭ」）、並びにエンタープライズ・サービス・バス（ＥＳＢ）のようなサービス指向型技術を強化してデータへのアクセスを提供する。
【００６４】
図３は、図２に関連して説明したユーザ・インタフェイスのようなユーザ・インタフェイスを含むモバイル装置の例を示す。図３に示すように、モバイル装置３１０が、グラフィック・ユーザ・インタフェイス３２０、ナビゲーション装置３３０、及び例えばインタフェイス３２０のコンテンツとの相互作用のための１又は複数のツール３４０を含み得る。モバイル装置３１０は、携帯電話、携帯情報端末（ＰＤＡ）、ポケット・パーソナル・コンピュータ、及び／又は他の可搬型計算装置を含み得る。モバイル装置３１０は、例えば外部システムとデータを交換するための通信インタフェイスを含んでいる。
【００６５】
モバイル・サービスとウェブ・サービスとの組み合わせを用いて、モバイル装置３１０を介した情報の送達を行なうことができる。モバイル・ウェブ技術を用いると、ポータビリティ、ユビキタスな連結性、及び位置に基づくサービスを加えて、ウェブに存在する情報及びサービスを強化することができる。アプリケーション及び様々な媒体は別個の貯蔵所（silo）に常駐していなくてもよい。代わりに、これらの装置３１０に搭載されているアプリケーションは、例えばウェブ２．０アプリケーション、従来のデスクトップ・アプリケーション、マルチ・メディア動画及び音声、並びにモバイル装置（例えば携帯電話）の各要素を収集することができる。適応型ユーザ・インタフェイス・アーキテクチャを用いて、利用者が、例えば必要なときに必要な場所で重要な臨床情報を作成し又は消費することを可能にするモバイル装置用のウィジェットを設計することができる。
【００６６】
図４は、本発明の一実施形態による周産期診療における適応型の業務中心ユーザ・インタフェイス４００のユース・ケースの一例を示す。図４の例では、３５歳の妊婦パトリシア・スミスが３回目の妊娠の３４週目にある。診療の全過程を通じて、パトリシアは、初期検査室検査、生命徴候、三次元（「３Ｄ」）胎児超音波、及び他の常套検査を含めて典型的な精密検査を受けている。妊娠性糖尿病を除けばパトリシアは正常な妊娠をしており、全ての指標が、出産予定日に健康な男児を出産するであろうことを示す。
【００６７】
しかしながら、３４週目の予約診療時に、パトリシアの担当産婦人科医は、血圧が以前の測定値１４５／９５に比べて高く、血圧に幾分懸念を感じる。アマンダ・ミラー医師は、心電図（「ＥＫＧ」）及び尿検査（「ＵＡ」）を指示する。パトリシアのＥＫＧは正常洞調律を示すが、ＵＡが、子癇前症を示唆する痕跡量のアルブミンを含めて返ってくる。ミラー医師は、血圧及び腎作用を監視するためにパトリシアに次回の予約を今日から１週間後に入れるように求める。
【００６８】
次の週に、パトリシアの血圧は前回の値（１５０／９８）よりも高く、ミラー医師はもう一度尿検査を指示する。ＵＡは再び陽性と返ってくるが、前回と略同じレベルにある。ミラー医師は、念のため血圧が正常なレベルに下がるまで毎週の来診を続けた方がよいと考える。また、ミラー医師はパトリシアに、子癇の一つの警戒徴候は、突然の激しい頭痛であり、頭痛を起こした場合には診療のための直ちに救急病棟に来診するように伝える。
【００６９】
週末に開かれた息子の５歳の誕生日パーティで、パトリシアは激しい頭痛を起こす。夫のトムは、直ちに妻を地域の病院の救急病棟（「ＥＤ」）に連れて行く。ＥＤの職員は、例えば長期時間線カルテを介してパトリシアのカルテの全てを入手し、パトリシアの症例の様相の全てについて情報を得る。パトリシアの血圧（「ＢＰ」）は２００／１３０まで急上昇し、ＥＤの医師は一連の検査すなわちＵＡ、ＥＫＧ、化学検査（Chem panel）、及び頭部ＣＴを指示する。化学検査及び頭部ＣＴは両方とも正常であるが、ミラー医師が危惧した通り、ＵＡはアルブミン・レベルの上昇（２＋）を示す。これらの検査結果及びパトリシアの状態から鑑みて、ＥＤの医師及びミラー医師は、最善の行動の進路は、パトリシアの血圧が治まり次第、帝王切開で分娩を行なうことであると決断する。パトリシアは、高血圧を制御するためのヒドララジン（静注を介して）、及び頭痛のためのタイレノール３を投与されて、手術準備室に搬送される。
【００７０】
帝王切開は成功し、パトリシア及びトムは６ポンド４オンスの健康な男児エヴァンを無事授かる。１週間の入院の後に、パトリシア及びエヴァンは退院する。パトリシア及びエヴァンの両者は１週間後にミラー医師の診察を受ける。パトリシアのアルブミン及び血圧は正常に戻っており、血糖レベルも正常になっている。
【００７１】
ユーザ・インタフェイス４００を用いて、ミラー医師は、患者の識別４０５に基づいてパトリシアの経過、検査室結果、及び生命徴候等を容易に検討し、入力し、修正することができる。ＵＩ４００は、パトリシアの生命徴候４１０を表示し、パトリシアの血圧に懸念があることを大きい赤のアイコン４１５を通じて視覚的に示す。加えて、異常のある尿検査結果４１７が医師に対して視覚的に強調される。尿検査の臨床詳細情報４１０は、陽性４２５又は陰性４２７の結果を示すように主要な結果を強調した状態で容易に検討され得る。ミラー医師は、パトリシアについて指示した放射線検査４３０及び心臓検査４４０を検討することができ、パトリシアの経過を評価するために以前の経過メモ４５５を含めて文書４５０を調べることができる。ミラー医師（及び／又は例えば補助の看護師）はまた、パトリシアの来診の理由４６０を入力して検討することができる。ヒドララジン及びタイレノール３を処方した後に、ミラー医師は、薬物ウィジェット４７０を介して投与量及び送達方法を確認すると共に、帝王切開の後に修正することができる。ミラー医師がさらに疑問を感じ、且つ／又は追加情報を検索したい場合には、検索欄４８０によって検索を行なうことができる。
【００７２】
図５は、本発明の幾つかの実施形態によるユーザ・インタフェイス・アーキテクチャ５００を示す。アーキテクチャ５００は、ユーザ・インタフェイス変換エンジン５０２、クエリ生成／展開エンジン５０３、情報編成エンジン５０９、多文書要約エンジン５１４、及び連結性フレームワーク５４５への１又は複数のコネクタ５１９を含む。アーキテクチャ５００のこれらの構成要素は、コンピュータ又は掌中型装置のような処理装置に設けられたユーザ・インタフェイス５０１を介して利用者によってアクセス可能である。利用者は、例えばユーザ・インタフェイス５０１を介して情報についてのクエリを発行することができる。
【００７３】
クエリ生成／展開エンジン５０３は、刺激５０４、１又は複数のクエリ生成器５０５、並びにクエリ及び収集された文書５０８を生成するために１又は複数のデータ・ソース５０７を探索する１又は複数のアクセス機構５０６を含む。クエリ及び収集された文書５０８は、アプリケーション５１０、５１１、５１２、５１３を含む情報編成エンジン５０９に渡されて、これらのアプリケーションが例えば処理を行なって認知推論を適用し、クエリ及び収集された文書５０８を整理して、例えばセマンティック・ガイドライン、利用者プレファレンス、及びドメイン関連情報の１又は複数に基づいて、要求を出した利用者にとって意味のある１又は複数のユニットにまとめる。編成器を含むツールセットが、集計、冗長な情報の消去、情報の軽量要約、及び結果の融合のような編成判定論理（「ＣＤＬ」）を用いて情報を編成することができる。アプリケーションは、例えば１又は複数のデータ主導型アプリケーション５１０、エンタープライズ・アプリケーション・インタフェイス５１１、作業／工程主導型アプリケーション５１２、及び特定データ構造向けアプリケーション５１３を含み得る。アプリケーション５１０、５１１、５１２、及び／又は５１３は、新たなデータ型、新たなデータ構造、特定ドメイン向け作業／工程、及び新たなアプリケーション・インタフェイス等に関係する１又は複数のひな型を含み得る。クエリ及び収集された文書５０８の編成及び処理によって、利用者クエリに応答して情報のバンドル５５０が生成される。
【００７４】
多文書要約エンジン５１４は、文書のバンドル５５０を受け取って、文書を節５１５に分割する。節５１５は、類似の概念５１６に基づいてクラスタ化される。次いで、メタ文書５１７が概念５１６から形成される。要約５１８がメタ文書５１７から生成される。クエリ結果５５０、メタ文書５１７、及び／又はメタ文書要約５１８は、ユーザ・インタフェイス５０１を介して利用者に与えられ得る。
【００７５】
連結性フレームワーク５４５へのコネクタ５１９を介して、ユーザ・インタフェイス５０１及びユーザ・インタフェイス５０１の各エンジン５０３、５０９、５１４は、例えばインタフェイス５０１を介した利用者クエリに応答して情報を送受することができる。例えば、クエリ・エンジン５０３は、連結性フレームワーク５４５にアクセスして１又は複数のデータ・ソース５０７に問い合わせを行なうことができる。
【００７６】
連結性フレームワーク５４５は、クライアント・フレームワーク５２０を含む。クライアント・フレームワーク５２０は、１又は複数のプロダクト５２２のためのコンテキスト・マネージャ５２１、患者検索５２３、レジストリ・ナビゲータ５２４、及びビューア５２５を含む。このようにして、幾つかの実施形態では、連結性フレームワーク５２０は、ユーザ・インタフェイス５０１を介して、またユーザ・インタフェイス５０１とは別個に、情報を観察して情報にアクセスするのを容易にすることができる。連結性フレームワーク５４５を介して、クエリ・エンジン５０３、及び／又はユーザ・インタフェイス５０１の他の部分が、複数の階層を通じて情報及び／又はサービスにアクセスすることができる。
【００７７】
階層は、例えばクライアント・フレームワーク階層５２６、アプリケーション階層５２８、及び統合階層５３０を含み得る。クライアント・フレームワーク階層５２６は、例えば情報の入出力を容易にする１又は複数のクライアント・ウェブ・サーバ５２７を含む。アプリケーション階層５２８は、ビジネス・アプリケーション、電子カルテ、エンタープライズ・アプリケーション、及び電子健康管理ポータル等のような事業体及び／又は部署利用に関係する１又は複数のアプリケーション５２９を含む。統合階層５３０は、ウェブ・サービス（「ＷＳ」）、Ｘ１２、及び健康管理規格レベル７（「ＨＬ７」）等のような多様なメッセージ形式を用いた既定インタフェイス及び／又は特化型インタフェイスのような１又は複数の既製インタフェイス５３６及び／又はカスタム・インタフェイス５３７を介して顧客情報技術（「ＩＴ」）５４３と通信する相互運用性強化型プラットフォーム・サーバ５３５を含む。相互運用性強化型プラットフォーム５３５は、例えば共通サービス・モデル（ＣＳＭ）を介してアプリケーション階層５２８の１又は複数のアプリケーション５２９と通信することができる。
【００７８】
例えば図５に示すように、相互運用性強化型プラットフォーム５３５は、例えばエンタープライズ・サービス・バス（「ＥＳＢ」）５３１、レジストリ、データ及びサービス集合５３２、構成情報５３３、及び臨床コンテンツ・ゲートウェイ（「ＣＣＧ」）・インタフェイス・エンジン５３４を含む。ＥＳＢ５３１は、例えばJava（商標）ビジネス・インテリジェンス（「ＪＢＩ」）準拠型ＥＳＢであってよい。ＥＳＢ５３１は、Ｘ１２、ＨＬ７、及びＳＯＡＰ（単純オブジェクト・アクセス・プロトコル）等のような特定のプロトコル／データ型を用いて例えばメッセージ及び／又は他のデータを送信するウェブ・サービスにアクセスする１又は複数の端点又は位置を含み得る。ＣＳＭを用いて、ＥＳＢ５３１は、例えばアプリケーション階層５２８のアプリケーション５２９との通信を容易にする。ＥＳＢ５３１を介して、各レジストリの情報、データ及びサービス・リポジトリ５３２の情報を、例えばクエリに応答してアプリケーション階層５３１に与えることができる。構成情報５３３を用いて、権限を有する利用者、個々の利用者及び／又は利用者のグループ／形式の権限のレベル、セキュリティ構成情報、プライバシー設定、並びに監査情報等のような１又は複数のパラメータを指定することができる。ＣＣＧインタフェイス・エンジン５３１は、顧客のＩＴフレームワーク５４３からデータを受け取って、例えばレジストリ５３２、及び／又はアプリケーション階層５３１のアプリケーション５２９にデータを与える。
【００７９】
例えば図５に示すように、顧客ＩＴ５４３は、サード・パーティの電子メッセージ伝達インタフェイス（「ｅＭＰＩ」）５３８のためのサポート、地域健康情報機関（「ＲＨＩＯ」）５３９のためのサポート、１又は複数のサード・パーティのアプリケーション５４０、事業体間文書共有（「ＸＤＳ」）リポジトリ５４１のためのサポート、及びＸＤＳレジストリ５４２のためのサポート等を含む。相互運用プラットフォーム５３５と共に顧客ＩＴ５４３を用いて、ＲＨＩＯゲートウェイ及びサード・パーティのアプリケーション統合を、連結性フレームワーク５４５への１若しくは複数のインタフェイス及び／又はユーザ・インタフェイス５０１のクエリ生成／展開エンジン５０３を介して提供することができる。
【００８０】
顧客ＩＴフレームワーク５４３は、複数の機関に跨がって健康管理情報の記憶、アクセス及び検索自在性を提供するように構成され得る。顧客ＩＴフレームワーク５４３は、地域社会、地方、国家、及び関連健康管理施設群等にサービスを提供し得る。例えば、顧客ＩＴフレームワーク５４３は、ＲＨＩＯ５３９、国民健康情報網（「ＮＨＩＮ」）、及び医療品質向上協会（「ＭＱＩＣ」）等によって具現化され得る。幾つかの実施形態では、顧客ＩＴ５４３は各健康管理情報システムを接続して、安全、持続可能で且つ規格に基づいた態様で各システムを相互運用することを支援する。
【００８１】
幾つかの実施形態では、顧客ＩＴフレームワーク５４３は、例えばＥＭＲ能力及び集団調査型（population-based）臨床品質報告システムを含めて、技術的アーキテクチャ、ウェブ・アプリケーション、データ・リポジトリを提供する。このアーキテクチャは、ＸＤＳレジストリ５４２及びリポジトリ５４１のような文書記憶、クエリ発行、及び連結性のための構成要素を含む。幾つかの実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、例えば医師のための会員制方式のＥＭＲへの選択肢を含み得る。幾つかの実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、患者及び権限を有する医療診療所にとってアクセス可能な患者カルテ・データ及び関連する監査ログを暗号化された形態で記憶するように構成されているデータベース又は他のデータ記憶部として具現化される。一実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、サーバ又はサーバ群として具現化され得る。ＸＤＳレジストリ５４２及びリポジトリ５４１はまた、別個の物理的位置にある他のサーバ又はサーバ群に接続された一つのサーバ又はサーバ群であってよい。ＸＤＳレジストリ５４２及びリポジトリ５４１は、単一の単位、別個の複数の単位、又は別個の形態にある単位の群に相当することができ、ハードウェア及び／又はソフトウェアとして具現化され得る。ＸＤＳレジストリ５４２及びリポジトリ５４１は、複数の情報源から医療情報を受け取ることができる。
【００８２】
例えばＸＤＳ規格を顧客ＩＴフレームワーク５４３において用いると、さらに効率よく一様な情報交換のために文書クエリ発行及び記憶を統合することができる。顧客ＩＴ５４３を用いると、品質報告及び調査は、ＲＨＩＯ５３９及び／若しくは他の環境において、且つ／又はＲＨＩＯ５３９及び／若しくは他の環境と共に、統合され得る。顧客ＩＴ５４３は、例えば他の規格に基づくシステムと統合してかかるシステムに適応し得る単一ベンダの統合型システムを提供することができる。
【００８３】
顧客ＩＴフレームワーク５４３を介して、ＥＭＲ利用者群は、ＸＤＳレジストリ５４２及びリポジトリ５４１にデータをプールすることに合意し得る。次いで、顧客ＩＴフレームワーク５４３は、この群に研究用集計データ、患者診断及び治療の最善の実行、並びに品質向上ツール等へのアクセスを提供することができる。
【００８４】
ＸＤＳは、患者ＥＭＲを形成する臨床文書に対して登録、配信、及びアクセスを複数の健康管理事業体に跨がって提供する。ＸＤＳは、スケーラブルなアーキテクチャを介して患者文書の記憶、索引作成、及びクエリ／検索のためのサポートを提供する。但し、幾つかの実施形態は、多数の連携ドメイン（共通の方針集合及び単一のレジストリを介して互いに医療コンテンツを共有する方針について合意した健康管理事業体（エンタープライズ）システムの群として定義される）を、各々の連携ドメインが別個の連携ドメインとして自律性を保つが他の関係する連携ドメインとハードウェア及びソフトウェアの一方を共有するようにしてサポートする。ＸＤＳレジストリ５４２及びリポジトリ５４１は、各々の連携ドメインに参加する臨床システムを記述するのに用いられる連携ドメイン関係テーブルを保持し得る。一旦、文書への要求が発行されたら、要求発行元は既知であり、この発行元を用いてリポジトリ５４１の何れの文書（１又は複数）が要求した利用者に公開されるかを決定し、このようにして連携ドメインの自律性を保つ。
【００８５】
幾つかの実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、利用履歴を含めた患者カルテについての暗号化された更新トランザクションを記憶する中央データベースに相当する。一実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１はまた、患者カルテを記憶している。ＸＤＳレジストリ５４２及びリポジトリ５４１は、暗号化された情報へのアクセスを記憶して制御する。一実施形態では、カルテに特定的な論理構造を用いずにカルテを記憶することができる。かかる態様では、ＸＤＳレジストリ５４２及びリポジトリ５４１は検索可能でない。例えば、患者のデータを、データのソースにおいて一意の患者所有キーによって暗号化することができる。次いで、データはＸＤＳレジストリ５４２及びリポジトリ５４１にアップロードされる。患者のデータは、例えばコンピュータ・ユニットにダウンロードされて、暗号化キーによってローカルで解読され得る。一実施形態では、アクセス用ソフトウェア、例えば患者によって用いられるソフトウェア及び診療所によって用いられるソフトウェアが、暗号化／解読を行なう。
【００８６】
幾つかの実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、患者の登録及び診療所の登録を保持する。診療所は、ＸＤＳレジストリ５４２及びリポジトリ５４１に名称、住所、及び他の識別情報によって登録され得る。診療所は、免許に関連付けられる電子的キーを発行されている。診療所はまた、セキュリティ範疇を認められている。セキュリティ範疇は典型的には、診療所の形式に基づく。幾つかの実施形態では、診療所から送られる要求及びデータは、診療所の免許によってディジタル的に署名されて、ＸＤＳレジストリ５４２及びリポジトリ５４１によって権限を与えられる。患者は、患者識別子及びパスワード・ハッシュによってＸＤＳレジストリ５４２及びリポジトリ５４１に登録され得る。患者はまた、氏名、住所、及び他の識別情報によってＸＤＳレジストリ５４２及びリポジトリ５４１に登録されてもよい。典型的には、登録された患者は、一意の患者識別子及び暗号化キーを含むトークンを発行される。トークンは、例えば磁気カード、フォブ・カード（fob card）、又は患者を識別するのに用いられ得る他の何らかの装置であってよい。患者は、自分のトークン、並びに一実施形態では利用者識別子及びパスワードを用いて、ＸＤＳレジストリ５４２及びリポジトリ５４１にアクセスすることができる。
【００８７】
幾つかの実施形態では、ユーザ・インタフェイス・アーキテクチャ５００の設計は、システムの相互作用性に関係する複数の要因によって誘導される。例えば、一つの要因はシステム状態の可視性である。システムは、妥当な時間内に適当なフィードバックを通じて何が進行しているかについて利用者が情報を得られる状態にすることができる。加えて、もう一つの要因は、システムと「現実世界」との間の一致である。システムは、システム指向の用語ではなく、語、句及び概念が利用者にとって馴染みのある利用者の言語を発することができる。例えば、情報は、現実世界の慣行に従って自然で論理的な順序で現われ得る。加えて、一貫性及び標準に関して述べると、利用者は、異なる語、状況、又は行動が同じ物事を意味するか否かを疑問に感じなくても済むものとする。インタフェイス・アーキテクチャは、例えばプラットフォームの慣行に従うことができる。
【００８８】
もう一つの要因例は、利用者の制御及び自由に関するものである。利用者はしばしば、誤ってシステム作用を選択して対話（ダイアログ）を引き延ばさずに望まない状態から去るために分かり易く標識された「非常口」を必要とする。幾つかの実施形態は、例えばシステム・パラメータの構成設定及び情報クエリに関する動作のアンドゥ（取り消し）及びリドゥ（やり直し）をサポートする。
【００８９】
もう一つの要因は誤りの予防である。誤り易い条件を解消してもよいし、システムが誤りの状態を調べて、利用者に確認の選択肢を提示してから救済行動を実行してもよい。加えて、幾つかの実施形態は、利用者が誤りを認識し、診断して、修復するのを補助することができる。エラー・メッセージを分かり易い言語（例えばコードは用いない）で表現し、問題を正確に指摘して、例えば解決策を建設的に示唆することができる。システムをドキュメンテーションなしに用いることができる方がよい場合でも、ヘルプ及びドキュメンテーションを提供することが必要な場合がある。あらゆるかかる情報が、例えば検索し易く、利用者の作業に焦点を合わせ、実行されるべき具体的なステップを列挙して、且つ過度に膨大でないものとすることができる。
【００９０】
利用者相互作用の容易さに関して述べると、システムは、目的、行動、及び選択肢を可視化することにより利用者の記憶の負担を減少させ又は最小にすることができる。利用者は、対話の一つの部分からもう一つの部分まで情報を覚えておかずに済む。システムの利用のための命令は、可視であるか、適当なときに何時でも容易に検索可能であり得る。さらに、初心者にはしばしば見えない加速器によって、熟練利用者のために相互作用をしばしば加速することができ、システムが非熟練利用者及び熟練利用者の両方の要求を満たし得るようにしている。幾つかの実施形態では、利用者は、頻度の高い行動を特別に構成することができる。加えて、表示される対話は、無関係な情報又は滅多に必要とされない情報を含めないように構成され得る。対話のあらゆる余分な情報単位は、関連のある情報単位と競合して、相対的な見易さを低下させる。
【００９１】
幾つかの実施形態は、視覚化方策として、一つの事業体を横断する大きな臨床データ集合にわたる各種のデータ型のためのグラフィック・ユーザ・インタフェイスを提供する。従って、設計要素は、例えば施設構成要素、単一のアクセス探索点、１又は複数の構成要素／ウィジェット、１又は複数のカルテのグリッド／フォーム、予定、臨床データ結果、グラフ、作業一覧、メッセージ発行／共同作業構成要素、マルチ・スケール画像（例えばディープ・ズーム）、１又は複数の外部構成要素、メール、ＲＳＳフィード、外部ウェブに基づく臨床ツール（例えばＷｅｂＭＤ）等を含み得る。サーバ構成要素は、例えば検索エンジン、ウェブ・サーバ、アクティブ・リスナ、情報編成エンジン、クエリ・エンジン、データ集計器、文書要約器、プロファイル・コンテキスト管理、並びに１又は複数のダッシュボード（例えば臨床及び管理用）等を含み得る。
【００９２】
図６は、本発明の一実施形態によるアクティブ・リスニング及び応答能力を含む適応型ユーザ・インタフェイス・システム６００の一例を示す図である。システム６００は、例えばアクティブ・リスナ・エージェント６１０、ユーザ・インタフェイス６２０、コンテンツ６３０、及び入力６４０を含む。システム６００の構成要素は、例えばソフトウェア、ハードウェア、及び／又はファームウェアの様々な別個の及び／又は統合された組み合わせとして具現化され得る。
【００９３】
コンテンツ６３０は、ユーザ・インタフェイス６２０を介して利用者に表示される。コンテンツ６３０は、図２及び図４に関して上述したウィジェットのような１又は複数のウィジェット、アプリケーション、データ表示、及び画像等を含み得る。ユーザ・インタフェイス６２０を介して、利用者は、インタフェイス６２０に表示されるコンテンツ６３０に影響を与える入力６４０を与えることができる。アクティブ・リスナ・エージェント６１０は、表示されたコンテンツ６３０及び利用者入力６４０をユーザ・インタフェイス６２０のバックグラウンドにおいて監視する。コンテンツ６３０に基づく利用者入力６４０に応答して、アクティブ・リスナ・エージェント６１０は、ユーザ・インタフェイス６２０を介して既存のコンテンツ６３０及び入力６４０に関係するさらに他のコンテンツ６３０を与えることができる。アクティブ・リスナ・エージェント６１０は、例えば利用者及び利用者の作業についてのコンテキスト情報に基づいて、情報を見出し、整理して、利用者に提示することができる。
【００９４】
例えば、図２に示すように、ユーザ・インタフェイス２００は、生命徴候ウィジェット２２０及び患者問題ウィジェット２５０のようなコンテンツ６３０を表示する。利用者が患者の来診理由２５０を入力する６４０と、アクティブ・リスナ・エージェント６１０は、患者の現在の薬物が、患者の問題及び来診理由を検討する医師にとって関心があると決定して、付加的なコンテンツ６３０を薬物情報ウィジェット２７０の形態で提供する。
【００９５】
もう一つの例として、図４に移り、ユーザ・インタフェイス４００は、特に生命徴候／検査室ウィジェット４１０、薬物ウィジェット４７０、及び来診理由ウィジェット４６０のようなコンテンツ６３０を表示する。アクティブ・リスナ・エージェント６１０は、コンテンツ６３０及び利用者入力６４０を監視することができる。生命徴候／検査室ウィジェット４１０からの尿検査情報４１７に基づいて、アクティブ・リスナ・エージェント６１０は、利用者が尿検査及び関係する検査室結果に関するさらなる臨床詳細情報４２０に関心を持つ可能性が高いと決定する。このように、例えば臨床検査室詳細パネル４２０をインタフェイス４００を介して提供することができる。
【００９６】
幾つかの実施形態では、ウィジェット／アプリケーションのライブラリ及び患者情報から検索される付加情報６３０を表示することに加え、例えばアクティブ・リスナ・エージェント６１０は既存のコンテンツ６３０及び／又は入力６４０に基づいて新たなコンテンツ６３０を生成することができる。例えば、利用者が薬物ウィジェット又はアプリケーション（図２に示す薬物ウィジェット２７０等）から患者薬物情報をドラッグして、この情報を患者問題ウィジェット又はアプリケーション（図２に示す問題ウィジェット２５０等）まで移動させた場合には、新たなウィジェットを生成して（且つ／又は問題ウィジェットを修正して）、高血圧のような患者問題と、ヒドララジンのような患者によって摂取されている薬物との間の相関を示して、問題に対処することができる。
【００９７】
幾つかの実施形態では、修正された及び／又は新たに作成されたウィジェット及び／又は他のアプリケーションを後の利用に備えて保存することができる。例えば、利用者がウィジェットを保存することもできるし、且つ／又はシステムがウィジェットを自動的に保存することもできる。例えば、ウィジェットを一般的に保存することもできるし、且つ／又は特定の利用者、モード、及びグループ等に関して保存することもできる。
【００９８】
図７は、本発明の幾つかの実施形態による臨床コンテンツとの適応型ユーザ・インタフェイス作用のための方法の流れ図７００を示す。
【００９９】
ブロック７１０では、利用者による検討のためにコンテンツを表示する。例えば、患者に関係する臨床コンテンツを、患者の電子カルテ情報へのアクセスのような利用者要求に応答してユーザ・インタフェイスを介して利用者に表示することができる。
【０１００】
ブロック７２０では、利用者入力を受け入れる。例えば、ユーザ・インタフェイスを介して、利用者は、表示されている情報を修正し、表示されているアプリケーションと相互作用し、情報を追加し、さらなる情報を要求する等を行なうことができる。例えば、利用者入力は、患者についての情報の要求、ウィジェットの起動、及びユーザ・インタフェイスの表示での情報の配置等を含み得る。利用者入力は、刺激及びコンテキストのような患者面談に関する情報を含み得る。利用者入力は、利用者によって直接提供されることもできるし、且つ／又は例えばインタフェイスを介して利用者のために表示されている他のアプリケーション若しくはウィジェットを介して抽出されることもできる。
【０１０１】
ブロック７３０では、コンテンツ及び入力を監視する。例えば、アクティブ・リスナが、ユーザ・インタフェイスを介してコンテンツ及び活動を「聴取」し又は監視して、利用パターン、関心のある主題、並びに表示されているアプリケーション及び／又はコンテンツに対する変更等を識別することができる。
【０１０２】
ブロック７４０では、付加的なコンテンツを提供する。例えば、表示されているコンテンツ及びコンテンツとの利用者相互作用に基づいて、アクティブ・リスナは、利用者にとって有用であると考えられる付加的なコンテンツを提供する。
【０１０３】
ブロック７５０では、コンテンツを修正する。例えば、表示されているコンテンツ（例えばアプリケーション及びデータ）との利用者相互作用に基づいて、コンテンツを修正することができる。例えば、患者データを、インタフェイスを介して利用者によって更新することができる。もう一つの例として、利用者は、一つのアプリケーションからもう一つのアプリケーションへ情報を入力し且つ／又は伝達して、新たなアプリケーション（例えば新たなユーザ・インタフェイス・ウィジェット）を作成し、且つ／又は既存のアプリケーションを修正することができる。
【０１０４】
ブロック７６０では、修正後のコンテンツを利用者に提供する。例えば、更新済み患者データ、新たなアプリケーション、及び修正後アプリケーション等をユーザ・インタフェイスを介して利用者に提供する。例えば、サムネール、リンク、要約、及び／又は他のデータ表現をユーザ・インタフェイスを介して利用者にグラフィック的に提供することができる。サムネール、リンク、及び要約等の選択によって、例えば利用者による検討のためのさらなるレベルの詳細情報、並びに／又はソース文書の検索及び表示を生成することができる。加えて、新たなウィジェットを、監視されているコンテンツ及び／又は行動に基づいてライブラリから選択して表示することができる。代替的に又は加えて、インタフェイスを介した利用者による利用のために既存のウィジェット及び／又は他の情報から新たなウィジェットを作成することができる。修正後の情報は、例えば後の利用に備えて保存され得る。
【０１０５】
方法７００の各ステップの１又は複数は、例えばハードウェア、ファームウェア、及び／又はソフトウェアの一組の命令として、単独で又は組み合わせて具現化され得る。幾つかの例は、メモリ、ハード・ディスク、ＤＶＤ、又はＣＤのようなコンピュータ可読の媒体に常駐して汎用コンピュータ又は他の処理装置において実行される一組の命令として提供され得る。
【０１０６】
幾つかの例は、これらのステップの１又は複数を省いていてもよいし、且つ／又は列挙されている順序とは異なる順序で各ステップを実行してもよい。例えば、幾つかのステップは幾つかの例では実行されない場合がある。さらにもう一つの例として、幾つかのステップを、上で列挙したものとは異なる同時を含めた時間的な順序で実行してもよい。
【０１０７】
このように、幾つかの実施形態は、例えば単一のアクセス点、モダリティ交差型のデータ・アクセス、ＸＤＳ準拠、プッシュ・プル能力、合意型構築、透明性、利用によって強化される知識管理、プラットフォーム交差型（ウェブ及びモバイル等）のアクセス容易性、並びに利用者の情報空間のシステム・レベル像を含めた複数の利点を提供する。
【０１０８】
幾つかの実施形態は、多様な臨床アプリケーションのためのアーキテクチャ及びフレームワークを提供する。このフレームワークは、限定しないがグラフィック・ユーザ・インタフェイス（ＧＵＩ）等を含むフロント・エンド構成要素を含むことができ、また様々な程度までシン（thin）・クライアント・システムであってもシック（thick）・クライアント・システムであってもよく、例えば幾つか又は全てのアプリケーション及び処理が、クライアントのワークステーションにおいて、サーバにおいて、且つ／又は部分的にクライアントのワークステーションにおいて及び部分的にサーバにおいて、実行される。
【０１０９】
本書に記載されるユーザ・インタフェイス・システム及び方法の例は、病院情報システム（「ＨＩＳ」）、放射線情報システム（「ＲＩＳ」）、画像保管及び通信システム（「ＰＡＣＳ」）、心血管情報システム（「ＣＶＩＳ」）、図書館情報システム（「ＬＩＳ」）、事業体臨床情報システム（「ＥＣＩＳ」）、電子カルテ・システム（「ＥＭＲ」）、及び検査室結果／指示システム等のような１又は複数の臨床情報システムと共に用いられ得る。かかるシステムは、例えばソフトウェア、ハードウェア、及び／又はファームウェアとして具現化され得る。幾つかの具現化形態では、これらのシステムの１又は複数は、シン・クライアント及び／又はダウンロード可能なソフトウェアという解決策を介して遠隔で具現化され得る。さらに、１又は複数の構成要素を共に組み合わせ且つ／又は具現化することができる。
【０１１０】
幾つかの実施形態では、アクティブ・リスナ・エージェントが、コンピュータ装置、及び／又はユーザ・インタフェイスのようなソフトウェア・アプリケーションのフォアグラウンド及び／又はバックグラウンドで動作して、利用者及びプログラムの活動を監視する。例えば、アクティブ・リスナ・エージェントは、ユーザ・インタフェイスにおけるウィジェットに関係する情報を集めることができる。また、アクティブ・リスナ・エージェントは、例えばユーザ・インタフェイス及びユーザ・インタフェイスのコンテンツに関して利用者によって生成される行動に関係する情報を集めることができる。
【０１１１】
幾つかの実施形態では、アプリケーション（例えばウィジェット）情報及び利用者相互作用に基づいて、アクティブ・リスナ・エージェントは、現在のコンテキストに基づいて利用者にとって重要な情報及び／又は作用内容を識別することができる。一実施形態では、ユーザ・インタフェイスに表示されている１又は複数のデータ要素が予め決められた閾値に達したことをアクティブ・リスナ・エージェントが検出した場合には、アクティブ・リスナは、利用者が十分な情報に基づく決定を下すことを可能にするのを補助する付加的な関連情報を含む１又は複数のウィジェットをユーザ・インタフェイスに自動的に配置する。もう一つの実施形態では、アクティブ・リスナ・エージェントは、アプリケーションとの利用者相互作用に反応することにより利用者を補助することができ、また利用者の行動の結果として表示されているユーザ・インタフェイスにウィジェット（１又は複数）の形態にある付加的な情報及び／又は他の情報を表示することにより付加的な見識を提供する。例えば、利用者が何らかのデータ要素を一つのウィジェットからもう一つのウィジェットへドラッグする（例えばマウス装置を用いた該当要素のカーソル選択及び表示されているインタフェイスを横断する移動を介して）と、アクティブ・リスナ・エージェントはこの情報を、表示されているインタフェイスにおいて、データ要素の構成が利用者が結論（例えば患者の診断及び／又は治療に関する）に到達するのを補助するのに有用な異なるレベルの情報を意味するように再配置することができる（例えば大きさ及び／又は位置）。次いで、アクティブ・リスナ・エージェントは、特定のシナリオにおいて有用であり得る既製の関連ウィジェットをインタフェイスに配置することもできるし、且つ／又はユーザ・インタフェイスにおいてデータ・コンテキストに加えて利用者が変更したウィジェットのコンテンツに基づいて、新たなウィジェットを作成することもできる。
【０１１２】
予め決められたワークフローに焦点を合わせるよりも寧ろ、アクティブ・リスナは利用者に対し、既知のワークフロー又はプロトコルが存在しないような幾つかの状況において利用者にとって助けとなる付加的な情報を提供する。履歴データ及び／又は他の入力に基づいて、システムは、利用者が情報に基づいた決定を下すのに関連する付加的な情報及び／又は作用内容を利用者に対して表示する。例えばアプリケーション及び／又はインタフェイスのバックグラウンドにおいて、アクティブ・リスナは、表示されているインタフェイスでのデータ要素の活動を監視することができる。これらのデータ要素が何らかの閾値に達すると、アクティブ・リスナは、利用者が情報に基づいた決定を下すのを補助する付加的な情報を、表示されているインタフェイスに配置する。代替的に又は加えて、アクティブ・リスナは、利用者がアプリケーションに変更を加えたときを検出することができる（例えばデータ要素を一つのウィジェットからもう一つのウィジェットにドラッグ＆ドロップする、検索を行なう、及び診断を変更する等による）。利用者相互作用のコンテキストを表示されているユーザ・インタフェイスのコンテンツと組み合わせることにより、例えば利用者に関連情報及び／又は作用内容を提供することができる。
【０１１３】
幾つかの実施形態では、データ要素通信（「ＤＥＣ」）ウィジェット（例えば「ベルクロ」ウィジェット）によって、利用者が、ユーザ・インタフェイスの画面の他の任意のウィジェットから任意の臨床要素（１又は複数）を選択し又は引き出して、選択された臨床要素（１又は複数）をＤＥＣウィジェットの「保持ビン」又は保持エリアに投入することを可能にする。臨床要素は、例えば患者情報、他の臨床詳細情報、及び／又は要約表現の背後に隠されている詳細データの要約表現を表わし得る。臨床要素（１若しくは複数）及び／又は関連情報の選択及び送信は、単独で、且つ／又は例えば上述のアクティブ・リスナ・エージェントのようなアクティブ・リスナ・エージェントと共に実行され得る。例えば、幾つかの実施形態では、アクティブ・リスナ・エージェントは、幾つかの規則、規準、及び観察された利用パターン等に基づいて保持エリア８００を自動的に埋めることができる。
【０１１４】
例えば図８に示すように、ＤＥＣウィジェットの保持エリア８００が、ＥＣＧ表現８０５、脳ＭＲ画像又は画像系列８１０、及び臨床詳細情報８１５等を含んでいる。表現８０５、８１０、８１５等は、例えば基礎となる臨床コンテンツへのグラフィック参照及び／又はリンクを提供する（図１〜図７に関して上に記載されるウィジェットの１又は複数に関して等）。保持ビン又はエリア８００と共に動作するツール又はウィジェットによって、利用者が、保持エリア８００の情報を電子メール及び／又は他の方法で送信する適当な人物（１又は複数）を選択することを可能にする。宛先（１又は複数）８２０を指定して、送ろうとしているデータを記述する付加的な情報又は詳細８２５を与えることができる。利用者は、「メッセージ送信（Send Message）」を選択してメッセージを受取者（１又は複数）に送信することができる。幾つかの実施形態では、保持エリア８００は、メッセージ・エリア８２５を含んでいてもよいし、メッセージ・エリア８２５に含まれていてもよい。
【０１１５】
受取者がメッセージを受け取るときには、電子メール及び／又は他の送信は、送信側利用者が選択した情報、並びに幾つかの実施形態ではウィジェット・オブジェクト８０５、８１０、８１５等によって表わされるメッセージに埋め込まれている詳細情報を含み得る。メッセージを、利用者の電子メール受信ボックスにおいて受け取ることもできるし、データベース・レコードとして追加することもできるし、ユーザ・インタフェイス・ウィジェット等として生成することもできる。メッセージはまた、健康管理情報システム、電子カルテ、電子的指示システム、電子的処理システム、データ記憶部又はアーカイブ等に転送され得る。
【０１１６】
幾つかの実施形態では、グラフィック表現（例えば様々な大きさの色付きの四角形）を詳細データと置き換える。例えば、図９に示すように、受取者に送信される電子メール９００が、図８に示す保持エリア８００からのＥＣＧ表現８０５、脳ＭＲ画像８１０、及び臨床詳細情報８１５に関する展開された詳細を含む。電子メール９００は、患者情報９０５、臨床詳細情報９１０、ＭＲ画像９１５、及び患者ＥＣＧデータ９２０を含んでいる。
【０１１７】
幾つかの実施形態では、メッセージ９００からの情報を、例えば他のアプリケーション又はインタフェイスへ転送することができる。例えば、受取者は、メッセージ９００から内容を抽出して、この内容をユーザ・インタフェイス・ウィジェット、記憶、他の送信、及び／又は他のアプリケーションへ転送して処理させることができる。もう一つの例として、メッセージ９００はウィジェット又はアプリケーションによって受け取られてもよく、ウィジェット又はアプリケーションは内容を受取者のために表示し、且つ／又は／メッセージ９００の内容を処理して、１又は複数のアプリケーション及び／又は記憶に配信する。
【０１１８】
図１０は、本発明の幾つかの実施形態による１又は複数のアプリケーション又はウィジェットからの１又は複数の臨床要素の選択、保持、及び１又は複数の受取者への送信を容易にするウィジェット・システム１０００の一例を示す。システム１０００は、コンテンツ１０２０を含むユーザ・インタフェイス１０１０を含む。コンテンツ１０２０は、アプリケーション／ウィジェット、臨床データ、及び外部システム／情報へのリンク／接続等を含み得る。インタフェイス１０１０はまた、臨床要素送信ユニット１０３０を含み、且つ／又は臨床要素送信ユニット１０３０への接続を有する。臨床要素送信ユニット１０３０は、利用者選択、並びに／又は１若しくは複数の規則及びプレファレンス等を用いた自動選択の何れかを介してコンテンツ１０２０を受け取る。臨床要素送信ユニット１０３０は、単独で、且つ／又は例えば上述のアクティブ・リスナ・エージェントのようなアクティブ・リスナ・エージェントと共に用いられ得る。臨床要素送信ユニット１０３０は選択されたコンテンツ１０２０をパッケージ化して、受取者１０４０へ送信する。選択されたコンテンツ１０２０の送信は、例えば臨床データ要素の表現及び／若しくは基礎となる詳細、並びに／又は他の情報を含み得る。受取者１０４０は、１又は複数の医師（例えば医師のコンピュータ）、アプリケーション／ウィジェット、インタフェイス、及びデータ記憶部等を含み得る。システム１０００の各構成要素は、例えばハードウェア、ソフトウェア、及び／若しくはファームウェアとして、単独で且つ／又は様々な組み合わせで具現化され得る。システム１０００がソフトウェアのみにおいて具現化される範囲まででは、システム１０００の構成要素（例えばユーザ・インタフェイス１０１０、コンテンツ１０２０、臨床要素送信ユニット１０３０、及び／又は受取者１０４０）の１又は複数が、有形の媒体に記憶されている機械可読の命令を含む。また、例えばシステム１０００の構成要素の任意のものが、特定応用向け集積回路（「ＡＳＩＣ」）及び／又は他の論理回路のようなハードウェアによって具現化され得る。
【０１１９】
図１１は、本発明の幾つかの実施形態による１又は複数のアプリケーション又はウィジェットからの１又は複数の臨床要素の選択、保持、及び１又は複数の受取者への送信を容易にする方法１１００の流れ図を示す。
【０１２０】
ブロック１１１０では、利用者が、ユーザ・インタフェイスを介して表示され且つ／又はアクセス可能な要素を選択する。臨床要素は、例えば患者情報、他の臨床詳細情報、及び／又は要約表現の背後に隠されている詳細データの要約表現を表わし得る。例えば、利用者は、ユーザ・インタフェイスの放射線ウィジェットからＭＲ画像系列（例えば図８に示す脳ＭＲ画像８１０）の表現を選択することができる。
【０１２１】
ブロック１１２０では、利用者は、選択された臨床要素をユーザ・インタフェイス画面の保持用又は一時的記憶エリアに投入する。例えば、利用者は、ＭＲ画像系列の表現のような選択された臨床要素を、ＤＥＣウィジェットのようなユーザ・インタフェイスのウィジェットの保持エリアにドラッグ＆ドロップすることができる。
【０１２２】
ブロック１１３０では、利用者は、選択された臨床要素の送信のための１又は複数の受取者を選択する。例えば、ユーザ・インタフェイス・ツール又はウィジェットによって、利用者が保持ビン（例えば図８に示す保持エリア８００）の情報を電子メール及び／又は他の方法で送信する適当な人物（１又は複数）を選択することを可能にする。宛先（１又は複数）を指定して、例えば送ろうとしている臨床要素（１又は複数）及び／又は他の情報を記述する付加的な情報又は詳細を与えることができる。
【０１２３】
ブロック１１４０では、選択された臨床要素を選択された受取者（１又は複数）へ送信する。例えば、利用者は、ユーザ・インタフェイスのウィジェットを介して「メッセージ送信」を選択して、１若しくは複数の選択された臨床要素及び／又は付加的な情報を含むメッセージを所期の受取者（１又は複数）に送信することができる。
【０１２４】
ブロック１１５０では、受取者が、送信された臨床要素を受け取る。受取者がメッセージを受け取るときには、電子メール及び／又は他の送信は、送信側利用者が選択した情報、並びに幾つかの実施形態ではメッセージに埋め込まれている詳細情報（例えば図８に示すウィジェット・オブジェクト８０５、８１０、８１５によって表わされる情報等）を含み得る。幾つかの実施形態では、メッセージにドラッグ＆ドロップされたグラフィック表現（例えば様々な大きさの色付きの四角形）を基礎となる詳細データと置き換えてもよい。例えば、図９に示すように、受取者に送信された電子メール９００は、図８に示す保持エリア８００からのＥＣＧ表現８０５、脳ＭＲ画像８１０、及び臨床詳細情報８１５に関する展開された詳細を含む。電子メール９００は、例えば患者情報９０５、臨床詳細情報９１０、ＭＲ画像９１５、及び患者ＥＣＧデータ９２０を含んでいる。このように、幾つかの実施形態では、臨床要素のグラフィック表現を送信メッセージに含めることにより、表現の基礎となるコンテンツが含められて、情報を観察する権限を有する１又は複数の人物、情報システム、アーカイブ、及び電子カルテ等を含めて１又は複数の受取者に送信される。幾つかの実施形態では、メッセージからの情報を、例えば他のアプリケーション又はインタフェイスに転送することができる。
【０１２５】
方法１１００の１又は複数の構成要素は、例えばハードウェア、ファームウェア、及び／又はソフトウェアの一組の命令として、単独で又は組み合わせて具現化され得る。幾つかの例は、メモリ、ハード・ディスク、ＤＶＤ、又はＣＤのようなコンピュータ可読の媒体に常駐して、汎用コンピュータ又は他の処理装置において実行される一組の命令として提供され得る。
【０１２６】
幾つかの例は、これらのステップの１又は複数を省いていてもよいし、且つ／又は列挙されている順序とは異なる順序で各ステップを実行してもよい。例えば、幾つかのステップは幾つかの例では実行されない場合がある。さらにもう一つの例として、幾つかのステップを、上で列挙したものとは異なる同時を含めた時間的な順序で実行してもよい。
【０１２７】
図１２は、本書に記載されるシステム及び方法を具現化するのに用いられ得るプロセッサ・システム１２１０の一例のブロック図である。図１２に示すように、プロセッサ・システム１２１０はプロセッサ１２１２を含んでおり、プロセッサ１２１２は相互接続バス１２１４に結合されている。プロセッサ１２１２は、例えば任意の適当なプロセッサ、処理ユニット、又はマイクロプロセッサであってよい。図１２には示していないが、システム１２１０はマルチ・プロセッサ・システムであってもよく、従ってプロセッサ１２１２と同等又は類似しており相互接続バス１２１４に結合されて連絡する１又は複数の付加的なプロセッサを含み得る。
【０１２８】
図１２のプロセッサ１２１２は、メモリ制御器１２２０及び入出力（「Ｉ／Ｏ」）制御器１２２２を含むチップセット１２１８に結合されている。周知のように、チップセットは典型的には、Ｉ／Ｏ作用及びメモリ管理作用、並びにチップセット１２１８に結合されている１又は複数のプロセッサによってアクセス可能であり又は用いられる複数の汎用及び／又は特殊目的のレジスタ及びタイマ等を提供する。メモリ制御器１２２０は、プロセッサ１２１２（又は多数のプロセッサが存在する場合には複数のプロセッサ）がシステム・メモリ１２２４及び大容量記憶メモリ１２２５にアクセスすることを可能にする作用を果たす。
【０１２９】
システム・メモリ１２２４は、例えば、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、フラッシュ・メモリ及び読み取り専用メモリ（ＲＯＭ）等のような所望の任意の形式の揮発性及び／又は非揮発性メモリを含み得る。大容量記憶メモリ１２２５は、ハード・ディスク・ドライブ、光学式ドライブ、及びテープ記憶装置等を含めた所望の任意の形式の大容量記憶装置を含み得る。
【０１３０】
Ｉ／Ｏ制御器１２２２は、プロセッサ１２１２が、Ｉ／Ｏバス１２３２を介して周辺入出力（「Ｉ／Ｏ」）装置１２２６及び１２２８、並びに網インタフェイス１２３０と通信することを可能にする作用を果たす。Ｉ／Ｏ装置１２２６及び１２２８は、例えばキーボード、ビデオ・ディスプレイ又はモニタ、及びマウス等のような所望の任意の形式のＩ／Ｏ装置であってよい。網インタフェイス１２３０は、プロセッサ・システム１２１０がもう一つのプロセッサ・システムと通信することを可能にする例えばイーサネット（商標）装置、非同期転送モード（「ＡＴＭ」）装置、８０２．１１装置、ＤＳＬモデム、ケーブル・モデム、及び携帯電話用モデム等であってよい。
【０１３１】
メモリ制御器１２２０及びＩ／Ｏ制御器１２２２は図１２ではチップセット１２１８の内部の別個のブロックとして示されているが、これらのブロックによって果たされる作用は、単一の半導体回路の内部で一体化されていてもよいし、２以上の別個の集積回路を用いて具現化されてもよい。
【０１３２】
このように、幾つかの実施形態は、複数の事業体（エンタープライズ）システムに跨がる末端利用者による情報へのアクセスを提供する。幾つかの実施形態は、末端利用者が健康管理網を横断してシームレスに医療情報にアクセスし、医療情報を入力し、また検索することを可能にする探索主導型、ロール・ベース、ワークフロー・ベース、及び／又は疾患ベースのインタフェイスという技術的効果を提供する。幾つかの実施形態は、個々の需要に合わせて特化され業務ドメインの変化に応答する業務中心インタフェイスを通じて適応型ユーザ・インタフェイス能力を提供する。幾つかの実施形態は、適応型の業務中心ユーザ・インタフェイス技術ソフトウェア・アーキテクチャを導入し、このアーキテクチャは、「業務中心」の活動の観点からの業務ドメイン、及び「業務中心」の活動を支援する具現化形態を達成する計算機構を特徴付けるために、オントロジー・モデル生成アプローチを用いると共に、業務中心の特徴付け、及びエンタープライズ・レベルのアプリケーションへのユーザ・インタフェイスの提示機構において、適応型相互作用を利用者指向型及び自動型の両方で提供する。幾つかの実施形態は、単純化されたグラフィック・ベースの保持エリア及びメッセージ伝達システムを介して臨床コンテンツを権限を有する利用者へ転送するという技術的効果を提供する。幾つかの実施形態は、臨床データのグラフィック指標を、基礎となる臨床データ自体を含むメッセージへ変換して、もう一つのシステムへのメッセージ伝達及び／又は送信を行なう。
【０１３３】
幾つかの実施形態は、セマンティック技術を強化して、例えばドメイン概念、利用者のロール及びタスク、並びに情報関係をモデル化する適応型ユーザ・インタフェイスを提供する。セマンティック・モデルによって、アプリケーションが、利用者及びタスクのコンテキスト情報に基づいてさらに実効的に情報を見出し、整理して、利用者に提示することを可能にする。アプリケーションは、マルチ・コンテンツ及びマルチ・メディア情報を表示するための情報ウィジェットのライブラリから構成され得る。加えて、この枠組みによって、利用者が、ウィジェットのレイアウトを特化して、基礎となるデータと相互作用することを可能にする。
【０１３４】
幾つかの実施形態は、アプリケーションからの１又は複数の臨床要素の抽出、保持、及び受取者への送信を容易にするシステム及び方法を提供する。幾つかの実施形態は、ユーザ・インタフェイスにおける臨床コンテンツのグラフィック表現を電子的メッセージを介して受取者に与えられる詳細な臨床コンテンツへ変換するという技術的効果を提供する。
【０１３５】
幾つかの実施形態は、以上に述べた作用内容を具現化する方法、システム、及び任意の機械可読の媒体におけるコンピュータ・プログラムを思量している。幾つかの実施形態は、既存のコンピュータ・プロセッサを用いて、又はこの目的若しくは他の目的のために組み入れられた特殊目的のコンピュータ・プロセッサによって、又は例えば結線システム及び／若しくはファームウェア・システムによって具現化され得る。
【０１３６】
以上に述べたシステムの構成要素及び／又は方法のステップの１又は複数は、例えばハードウェア、ファームウェア、及び／又はソフトウェアの一組の命令として、単独で又は組み合わせて具現化され得る。幾つかの実施形態は、メモリ、ハード・ディスク、ＤＶＤ、又はＣＤのようなコンピュータ可読の媒体に常駐して、汎用コンピュータ又は他の処理装置において実行される一組の命令として提供され得る。本発明の幾つかの実施形態は、方法ステップの１又は複数を省いていてもよいし、且つ／又は列挙された順序とは異なる順序で各ステップを実行してもよい。例えば、幾つかのステップは本発明の幾つかの実施形態では実行されない場合がある。さらにもう一つの例として、幾つかのステップを、上で列挙したものとは異なる同時を含めた時間的な順序で実行してもよい。
【０１３７】
幾つかの実施形態は、コンピュータ実行可能な命令又はデータ構造を担持し又は記憶したコンピュータ可読の媒体を含んでいる。かかるコンピュータ可読の媒体は、汎用若しくは特殊目的のコンピュータ、又はプロセッサを有する他の機械によってアクセスされ得る任意の利用可能な媒体であってよい。例として述べると、かかるコンピュータ可読の媒体は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ、ＣＤ−ＲＯＭ若しくは他の光学的ディスク記憶装置、磁気ディスク記憶装置若しくは他の磁気記憶装置、又は所望のプログラム・コードをコンピュータ実行可能な命令若しくはデータ構造の形態で担持し若しくは記憶するのに用いることができ、汎用若しくは特殊目的のコンピュータ、又はプロセッサを有する他の機械によってアクセスされ得る他の任意の媒体を含み得る。上述の組み合わせもまたコンピュータ可読の媒体の範囲に含まれる。コンピュータ実行可能な命令は例えば、汎用コンピュータ、特殊目的コンピュータ、又は特殊目的処理機械に、何らかの作用又は作用群を果たさせるような命令及びデータを含んでいる。
【０１３８】
一般的には、コンピュータ実行可能な命令は、特定のタスクを実行し又は特定の抽象的なデータ型を具現化するルーチン、プログラム、オブジェクト、コンポーネント及びデータ構造等を含んでいる。コンピュータ実行可能な命令、関連するデータ構造、及びプログラム・モジュールは、本書に開示された幾つかの方法及びシステムのステップを実行するプログラム・コードの例を表わしている。かかる実行可能な命令の特定の系列又は関連するデータ構造は、かかるステップに記載された作用を具現化する対応する動作の例を表わしている。
【０１３９】
本発明の各実施形態は、プロセッサを有する１又は複数のリモート・コンピュータへの論理的接続を用いて網化された環境で実施され得る。論理的接続は、本書において限定ではなく例示のために提示される構内網（ＬＡＮ）及び広域網（ＷＡＮ）を含み得る。かかる網環境は、オフィス内又は企業内コンピュータ網、イントラネット及びインターネットとして普及しており、広範な異なる通信プロトコルを用いることができる。当業者は、かかる網計算機環境が典型的には、パーソナル・コンピュータ、掌中型装置、マルチ・プロセッサ・システム、マイクロプロセッサ方式又はプログラム可能型の消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、及びメインフレーム・コンピュータ等を含めて、多くの形式のコンピュータ・システム構成を包含することを認められよう。本発明の各実施形態はまた、通信網を介してリンクされる（結線リンク、無線リンク、又は結線リンク若しくは無線リンクの組み合わせのいずれかによる）ローカル及びリモートの処理装置によってタスクが実行される分散型計算機環境で実施されてもよい。分散型計算機環境では、プログラム・モジュールはローカル及びリモートの両方のメモリ記憶装置に位置していてよい。
【０１４０】
本発明の各実施形態の全体システム又は各部分を具現化する例示的なシステムは、処理ユニット、システム・メモリ、及びシステム・メモリを含む様々なシステム構成要素を処理ユニットに結合するシステム・バスを含むコンピュータの形態にある汎用計算機装置を含み得る。システム・メモリは読み出し専用メモリ（ＲＯＭ）及びランダム・アクセス・メモリ（ＲＡＭ）を含み得る。コンピュータはまた、磁気ハード・ディスクに対する読み書きを行なう磁気ハード・ディスク・ドライブ、取り外し可能な磁気ディスクに対する読み書きを行なう磁気ディスク・ドライブ、及びＣＤ−ＲＯＭ又は他の光学的媒体のような取り外し可能な光ディスクに対する読み書きを行なう光ディスク・ドライブを含み得る。これらのドライブ及び関連するコンピュータ可読の媒体は、コンピュータ実行可能な命令、データ構造、プログラム・モジュール、及びコンピュータの他のデータの不揮発性記憶を提供する。
【０１４１】
実施形態を参照して本発明を説明したが、当業者には、本発明の範囲から逸脱せずに様々な変形を施し、また均等構成を置換し得ることが理解されよう。加えて、本発明の範囲から逸脱せずに、特定の状況又は材料を本発明の教示に合わせて適応構成する多くの改変を施すことができる。従って、本発明は、開示された特定の実施形態に限定されず、特許請求の範囲に属する全ての実施形態を包含するものとする。
【符号の説明】
【０１４２】
１００：適応型の業務中心健康管理サービスを提供するワークフロー
１０５：来診
１１０：クエリ
１１２：刺激
１１４：患者コンテキスト
１１５：クエリ・ドライバ
１２０：データ・ソース
１２５：情報編成エンジン
１３０：バンドル
１３５：要約エンジン
１４０：改訂済みバンドル
１５０：利用者の反応／フィードバック
１６０：知識管理サブシステム
１４５：プレゼンテーション
１６１：ダッシュボード
１６３：オントロジー
１６５：手続き及びガイドライン
１６７：共通データ・モデル
１６９：解析部
２００：適応型ユーザ・インタフェイス
２０５：ログイン及び利用者識別エリア
２１０：患者識別エリア
２１２：警告
２１５：ウィジェット表示エリア
２２０：生命徴候／検査室ウィジェット
２２１：血圧
２２２：血圧指標の型
２２３：尿検査
２２４：血圧指標の値
２２５：体重
２２７：ブドウ糖
２２９：体温
２３０：臨床文書ウィジェット
２３１：文書型
２３２：文書作成者
２３３：文書日付
２３４：文書からの評価
２３５：文書状態
２３６：文書に対する行動
２４０：撮像検査ウィジェット
２４４：画像
２４６：撮像型
２４８：評価
２５０：問題ウィジェット
２５２、２５４：問題
２６０：来診理由ウィジェット
２６２：理由
２６４：アイコン
２７０：薬物ウィジェット
２７２：薬物の型
２７４：薬物の量
２７６：薬物の送達機構
２８０：カーソル
２８５：カーソルの位置
２９２：利用者別ダッシュボード
２９４：患者一覧
２９６：設定／プレファレンス・パネル
３１０：モバイル装置
３２０：グラフィック・ユーザ・インタフェイス
３３０：ナビゲーション装置
３４０：ツール
４００：ユーザ・インタフェイス
４０５：患者の識別
４１０：生命徴候
４１５：アイコン
４１７：尿検査結果
４２０：臨床詳細情報
４２５：陽性の結果
４２７：陰性の結果
４３０：放射線検査
４４０：心臓検査
４５０：文書
４５５：以前の経過メモ
４６０：来診理由
４７０：薬物ウィジェット
４８０：検索欄
５００：ユーザ・インタフェイス・アーキテクチャ
５０１：ユーザ・インタフェイス
５０２：ユーザ・インタフェイス変換エンジン
５０３：クエリ生成／展開エンジン
５０４：刺激
５０５：クエリ生成器
５０６：アクセス機構
５０７：データ・ソース
５０８：クエリ及び収集された文書
５０９：情報編成エンジン
５１０：データ主導型アプリケーション
５１１：エンタープライズ・アプリケーション・インタフェイス
５１２：作業／工程主導型アプリケーション
５１３：特定データ構造向けアプリケーション
５１４：多文書要約システム
５１５：節
５１６：概念
５１７：メタ文書
５１８：メタ文書要約
５１９：コネクタ
５２０：クライアント・フレームワーク
５２１：コンテキスト・マネージャ
５２２：プロダクト
５２３：患者検索
５２４：レジストリ・ナビゲータ
５２５：ビューア
５２６：クライアント・フレームワーク階層
５２７：クライアント・ウェブ・サーバ
５２８：アプリケーション階層
５２９：アプリケーション
５３０：統合階層
５３１：エンタープライズ・サービス・バス（「ＥＳＢ」）
５３２：レジストリ、データ及びサービス集合
５３３：構成情報
５３４：臨床コンテンツ・ゲートウェイ（「ＣＣＧ」）・インタフェイス・エンジン
５３５：相互運用性強化型プラットフォーム・サーバ
５３６：既製インタフェイス
５３７：特化型インタフェイス
５３８：電子メッセージ伝達インタフェイス（「ｅＭＰＩ」）
５３９：地域健康情報機関（「ＲＨＩＯ」）
５４０：サード・パーティのアプリケーション
５４１：事業体間文書共有（「ＸＤＳ」）リポジトリ
５４２：ＸＤＳレジストリ
５４３：顧客情報技術（「ＩＴ」）
５４５：連結性フレームワーク
５５０：クエリ結果の情報バンドル
５５０：文書のバンドル
６００：適応型ユーザ・インタフェイス・システム
６１０：アクティブ・リスナ・エージェント
６２０：ユーザ・インタフェイス
６３０：コンテンツ
６４０：入力
７００：臨床コンテンツとの適応型ユーザ・インタフェイス作用のための方法
８００：保持エリア
８０５：ＥＣＧ表現
８１０：脳ＭＲ画像又は画像系列
８１５：臨床詳細情報
８２０：宛先
８２５：付加的な情報又は詳細
９００：電子メール
９０５：患者情報
９１０：臨床詳細情報
９１５：ＭＲ画像
９２０：患者ＥＣＧデータ
１０００：臨床要素の選択、保持、及び送信を容易にするウィジェット・システム
１０１０：ユーザ・インタフェイス
１０２０：コンテンツ
１０３０：臨床要素送信ユニット
１０４０：受取者
１１００：臨床要素の選択、保持、及び送信を容易にする方法
１２１０：プロセッサ・システム
１２１２：プロセッサ
１２１４：相互接続バス
１２１８：チップセット
１２２０：メモリ制御器
１２２２：入出力（Ｉ／Ｏ）制御器
１２２４：システム・メモリ
１２２５：大容量記憶メモリ
１２２６、１２２８：周辺入出力（Ｉ／Ｏ）装置
１２３０：網インタフェイス
１２３２：Ｉ／Ｏバス
【図９Ｂ】
【背景技術】
【０００１】
病院又は診療所のような健康管理環境は、病院情報システム（ＨＩＳ）、放射線科情報システム（ＲＩＳ）、臨床情報システム（ＣＩＳ）、及び心血管情報システム（ＣＶＩＳ）のような情報システムや、画像保管及び通信システム（ＰＡＣＳ）、図書館情報システム（ＬＩＳ）、及び電子カルテ（ＥＭＲ）のような記憶システムを含む。記憶される情報としては、例えば患者の医療履歴、撮像データ、検査結果、診断情報、管理情報、及び／又は予定情報等がある。これらの情報は、集中型で記憶されてもよいし、複数の位置に分割されていてもよい。医師は、健康管理ワークフローの様々な点において患者情報又は他の情報を入手することを欲する場合がある。例えば、手術時及び／又は手術後に、医療従事者は、医療情報システムに記憶されている患者の解剖学的構造の画像のような患者情報にアクセスすることができる。放射線科医及び／又は他の臨床医は、例えば記憶されている画像及び／又は他の情報を検討することができる。
【０００２】
ＰＡＣＳ及び／又は他のワークステーションを用いて、放射線科医のような臨床医は画像読影のような多様な活動を行なって臨床ワークフローを促進することができる。放射線処置又は心臓医療処置での読影のような解釈は、放射線科医又は心臓医のように患者のディジタル画像を観察する医師の工程である。医師は診断画像の内容に基づいて診断を行ない、電子的に（例えば口述若しくは他の方法を用いて）又は書面で結果を報告する。放射線科医又は心臓医のような医師は典型的には、診断を行なうために他のツールを用いる。他のツールの幾つかの例としては、事前検査及び関連する過去の（履歴）検査及び検査結果、検査室での検査（血液検査等）、アレルギー、病理学検査結果、投薬、注意事項、文書画像、並びに他のツール等が挙げられる。例えば、放射線科医又は心臓医は典型的には、検査結果を解釈するときには検査室情報、電子カルテ、及び健康管理情報のような他のシステムを調べる。
【０００３】
現在のＰＡＣＳ及び／又は他の検討用システムは、全ての利用可能な医療情報を利用者のために画面に提供する。しかしながら、この情報は整理されていない。加えて、現状では、これらのデータ要素の何れが重要で何れが重要でないかを利用者に伝える方法が存在しない。データの単なる拾い読み（ブラウジング）は医師のワークフローの著しい妨げとなり、しばしば所望の末端利用者の成果を挙げることができないため、大きな問題を孕む。
【０００４】
様々な臨床情報システムを通じて多様な臨床データ及び医療文書記録が入手可能であるが、医療の或る点において情報を見出し、整理して、医師及び他の医療従事者に実効的に提示することは現状では困難である。この課題に関連する無数の困難が存在する。現在のシステム及び方法は、単一のデータ・ソースに対して静的な問い合わせ（クエリ）を行ない、これにより一般的には、関連しているかも知れないし関連していないかも知れず、典型的には不完全な情報を返す。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
近年の研究に基づくと、計算機での医師の指示入力の誤りがこの約５年で増大している。２００６年の“The Journal of the American Medical Informatics Association”によれば、コンピュータ入力誤りによる意図しない不都合な結果は、次の九つの範疇に大別される（頻度の降順で）。すなわち、１）臨床医のさらなる業務／新たな業務、２）好ましくないワークフロー問題、３）際限のないシステム要求、４）書面の永続性に関連する問題、５）連絡パターン及びの慣行の厄介な変更、６）負の情動、７）新たな種類の誤りの発生、８）権力構造の予期しない変化、並びに９）技術への過剰依存である。利用し難さ及び不十分なユーザ・インタフェイス設計が、これらの範疇の全てではないにせよ殆どに寄与している。
【課題を解決するための手段】
【０００６】
本発明の幾つかの実施形態の例は、ウィジェット型アプリケーションにおける臨床要素の抽出、保持、及び送信を提供するシステム及び方法を提供する。
【０００７】
幾つかの例は、適応型ユーザ・インタフェイスを介して適応型の業務中心（work-centered）健康管理サービスを提供するシステム及び方法を提供する。臨床データ要素通信システムの一例が、利用者へのグラフィック表示のために複数の臨床情報源から検索される臨床コンテンツを含むユーザ・インタフェイスを含んでいる。ユーザ・インタフェイスは、アプリケーション及び患者データを含む表示されている臨床コンテンツとの利用者相互作用（対話）を容易にする。このシステムの例はまた、臨床コンテンツの保持エリアと、臨床コンテンツを１又は複数の受取者へ送信する送信ユニットとを含んでいる。保持エリアは、ユーザ・インタフェイスの一部として表示されて、利用者によって選択されて当該保持エリアに投入された臨床コンテンツを保持する。臨床要素送信ユニットは、保持エリアに投入された臨床コンテンツを受け取り、臨床コンテンツをパッケージ化して、臨床コンテンツを電子的データ・メッセージとして１又は複数の受取者へ送信する。
【０００８】
また、臨床データ要素通信の方法の一例が、複数の臨床情報源から検索されて利用者に対してグラフィック表示される臨床コンテンツを選択する利用者入力を受け入れるステップであって、臨床コンテンツは臨床アプリケーション及び患者データを含んでいる、受け入れるステップを含んでいる。この方法の例はまた、利用者によって選択されて、ユーザ・インタフェイスの一部として表示される保持エリアに投入された臨床コンテンツを一時的に記憶するステップを含んでいる。この方法の例はさらに、保持エリアから一時的に記憶された臨床コンテンツを含む電子的データ・メッセージを生成するステップを含んでいる。加えて、この方法の例は、電子的データ・メッセージを１又は複数の受取者へ送信するステップを含んでいる。
【０００９】
また、コンピュータ可読の媒体の一例が、実行されるとデータ要素通信システムを具現化するコンピュータでの実行のための一組の命令を含んでいる。この一組の命令によって具現化されるシステムは、利用者へのグラフィック表示のために複数の情報源から検索される電子的データ要素を含むユーザ・インタフェイスを含んでいる。ユーザ・インタフェイスは、表示されている電子的データ要素との利用者相互作用を容易にする。このシステムはまた、ユーザ・インタフェイスの一部として表示される保持エリアを含んでいる。保持エリアは、利用者によって選択されて当該保持エリアに投入された１又は複数の電子的データ要素を保持する。システムはさらに、保持エリアに投入された１又は複数の電子的データ要素を受け取り、１又は複数の電子的データ要素をパッケージ化して、１又は複数の電子的データ要素を電子的データ・メッセージとして１又は複数の受取者へ送信するデータ要素送信ユニットを含んでいる。
【図面の簡単な説明】
【００１０】
【図１】本発明の幾つかの実施形態による適応型の業務中心健康管理サービスを提供するワークフローを示す図である。
【図２】本発明の一実施形態による適応型ユーザ・インタフェイスの一例を示す図である。
【図３】図２に関連して記載されるユーザ・インタフェイスのようなユーザ・インタフェイスを含むモバイル装置の一例を示す図である。
【図４】本発明の一実施形態による周産期診療における適応型の業務中心ユーザ・インタフェイスのユース・ケースの一例を示す図である。
【図５】本発明の幾つかの実施形態によるユーザ・インタフェイス・アーキテクチャを示す図である。
【図６】本発明の一実施形態によるアクティブ・リスニング及び応答能力を含む適応型ユーザ・インタフェイス・システムの一例を示す図である。
【図７】本発明の幾つかの実施形態による適応型の業務中心ユーザ・インタフェイス及び支援アーキテクチャを介した健康管理コンテンツへのアクセスの方法の流れ図である。
【図８】本発明の幾つかの実施形態による１又は複数の臨床要素の選択、選択された要素（１又は複数）の保持、及び選択された臨床要素（１又は複数）の１又は複数の受取者への送信を可能にする保持エリア及びツールの一例を示す図である。
【図９】本発明の幾つかの実施形態による受取者によって受け取られるメッセージであって、図８のツールを介して利用者によって選択された被選択臨床要素に関する展開された詳細を含むメッセージの一例を示す図である。
【図１０】本発明の幾つかの実施形態による１又は複数のアプリケーション又はウィジェットからの１又は複数の臨床要素の選択、保持、及び１又は複数の受取者への送信を容易にするウィジェット・システムの一例を示す図である。
【図１１】本発明の幾つかの実施形態による１又は複数のアプリケーション又はウィジェットからの１又は複数の臨床要素の選択、保持、及び１又は複数の受取者への送信を容易にする方法の流れ図である。
【図１２】本書に記載されるシステム及び方法を具現化するのに用いられ得るプロセッサ・システムの一例のブロック図である。
【発明を実施するための形態】
【００１１】
以上に述べた概要、及び本発明の幾つかの実施形態の以下の詳細な説明は、添付図面と共に読まれるとさらに十分に理解されよう。本発明を説明する目的で、幾つかの実施形態を図面に示す。但し、本発明は添付図面に示されている構成及び手段に限定されないことを理解されたい。
【００１２】
幾つかの実施形態は、複数の事業体（エンタープライズ）システムに跨がる末端利用者による情報へのアクセスを提供する。幾つかの実施形態は、末端利用者が健康管理網を横断してシームレスに医療情報にアクセスし、医療情報を入力し、また検索することを可能にする探索主導型、ロール・ベース、ワークフロー・ベース、及び／又は疾患ベースのインタフェイスを提供する。幾つかの実施形態は、個々の需要に合わせて特化され業務ドメイン（work domain）の変化に応答する業務中心インタフェイスを通じて適応型ユーザ・インタフェイス能力を提供する。幾つかの実施形態は、二つの新規の概念を具現化した適応型の業務中心ユーザ・インタフェイス技術ソフトウェア・アーキテクチャを導入する。第一の概念は、「業務中心」の活動の観点からの業務ドメイン、及び「業務中心」の活動を支援する具現化形態を達成する計算機構を特徴付けるために、オントロジー・モデル生成アプローチを用いるものである。第二の概念は、業務中心の特徴付け、及びエンタープライズ・レベルのアプリケーションへのユーザ・インタフェイスの提示機構において、適応型相互作用を利用者指向型及び自動型の両方で提供するものである。
【００１３】
健康管理情報システムは、利用者が患者診療の時間線にわたって関連情報を見出して活用し得るときに最も実効的になる。適応型ユーザ・インタフェイスは、セマンティック技術を強化して、例えばドメイン概念、利用者のロール（役割）及びタスク（作業）、並びに情報関係をモデル化することができる。セマンティック・モデルによって、アプリケーションが、利用者及びタスクのコンテキスト情報に基づいてさらに実効的に情報を見出し、整理して、利用者に提示することを可能にする。アプリケーションは、マルチ・コンテンツ及びマルチ・メディア情報を表示する情報ウィジェットのライブラリで構成され得る。加えて、この枠組みによって、利用者が、ウィジェットのレイアウトを特化して、基礎となるデータと相互作用することを可能にする。
【００１４】
一例では、新たなレベルの適応型ユーザ・インタフェイス設計が、セマンティック・ウェブ技術を利用することにより達成される。ドメインの概念及び関係はオントロジーの階層として特徴付けられ、上位レベルのオントロジー型構成体に関連付けられて適応型の推論及び拡張性を可能にする。
【００１５】
このように、幾つかの実施形態は、個々の需要に合わせて特化され業務ドメインの変化に応答する業務中心アプリケーションを利用者に提示するために、オントロジーのメタデータについて「推論」し得る制御器の利用を介して適応型ユーザ・インタフェイス能力を提供する。目標とされる情報は、アプリケーション・コンテキスト感受型の態様で「外部」データから送り届けられ得る。
【００１６】
人間−コンピュータ間の相互作用では、ユーザ・インタフェイス・データ、イベント、及び頻度を表示し、記録して、エピソードとして整理することができる。画面でのデータ配置、エピソード頻度、及び含意関係を算出することにより、幾つかの実施形態の例は、特定アプリケーション向けのエピソード連関を自動的に導いて、従ってアプリケーション・インタフェイスが利用者に対し時宜に適った援助を適応的に与えることを可能にすることができる。相互作用追跡、エピソード識別、利用者パターン認識、利用者意図予測、及び利用者プロファイル更新を含めた適応型ユーザ・インタフェイスを設計することに関連する問題を識別することにより、利用者のために動作して幾つかの認識された計画に基づいてアプリケーションと相互作用し得るインタフェイスが生成される。様々な利用者の需要に適応するために、インタフェイスは、例えば利用者プロファイル及び特定疾患向けワークフローを学習することにより援助を個人別に構成することができる。
【００１７】
幾つかの実施形態では、適応型ユーザ・インタフェイス・システムが、例えば検索エンジン、ウェブ・サーバ、アクティブ・リスナ（能動的聴取者）、情報編成（information composition）エンジン、クエリ・エンジン、データ集計器、文書要約器、プロファイル・コンテキスト・マネージャ、並びに臨床及び管理用ダッシュボードを含んでいる。幾つかの実施形態は、特定利用者向け、特定ロール向け、特定疾患向けの態様で一つの患者カルテ記録全体の完全な像を提供する。幾つかの実施形態では、ユーザ・インタフェイスはまた、データの操作像、データの財務像を提供するように構成されることができ、また任意の形式のデータ集計のためのダッシュボードとなり得る。
【００１８】
幾つかの実施形態は、適応型の業務中心ユーザ・インタフェイス技術ソフトウェア・アーキテクチャを提供する。このアーキテクチャは、「業務中心」の活動の観点からの業務ドメイン、及び「業務中心」の活動を支援する具現化形態を達成する計算機構を特徴付けるために、オントロジー・モデル生成アプローチを用いるものである。このアーキテクチャはまた、業務中心の特徴付け、及びエンタープライズ・レベルのアプリケーションへのユーザ・インタフェイスの提示機構において、適応型相互作用を利用者指向型及び自動型の両方で提供する。
【００１９】
業務中心型ソリューションは、業務を達成する設定されたコンテキストに従って利用者相互作用をカスタマイズすることにより、柔軟で適応自在の態様で業務への支援を提供する統合され特化されたシステムを提供することを支援する。業務中心アプローチの下で、目標とされる業務ドメイン全体の理解を発展させる。例えば、業務ドメインの理解を発展させるのに用いられる質問として、業務ドメインが含んでいるものは何か、業務の目標は何か、業務ドメインに誰が参加しているか、及び参加者はローカルなコンテキストが与えられたときに業務ドメインの目標を如何にして達成するか等が挙げられる。この業務ドメインの理解を用いて、参加者の日々の活動を特徴付けし、従って支援することができる。
【００２０】
幾つかの実施形態では、アクティブ・リスナ・エージェントが、コンピュータ装置、及び／又はユーザ・インタフェイスのようなソフトウェア・アプリケーションのフォアグラウンド及び／又はバックグラウンドで動作して、利用者及びプログラムの活動を監視する。例えば、アクティブ・リスナ・エージェントは、ユーザ・インタフェイスのウィジェットに関係する情報を集めることができる。また、アクティブ・リスナ・エージェントは、例えばユーザ・インタフェイス及びユーザ・インタフェイスのコンテンツに関して利用者によって生成される行動（アクション）に関係する情報を集めることができる。
【００２１】
幾つかの実施形態では、アプリケーション（例えばウィジェット）情報及び利用者相互作用に基づいて、アクティブ・リスナ・エージェントは、現在のコンテキストに基づいて利用者にとって重要な情報及び／又は作用内容（functionality）を識別することができる。一実施形態では、ユーザ・インタフェイスに表示されている１又は複数のデータ要素が予め決められた閾値に達したことをアクティブ・リスナ・エージェントが検出した場合には、アクティブ・リスナは、利用者が十分な情報に基づく決定を下すことを可能にするのを補助する付加的な関連情報を含む１又は複数のウィジェットをユーザ・インタフェイスに自動的に配置する。もう一つの実施形態では、アクティブ・リスナ・エージェントは、アプリケーションとの利用者相互作用に反応することにより利用者を補助することができ、また利用者の行動の結果として表示されているユーザ・インタフェイスにウィジェット（１又は複数）の形態にある付加的な情報及び／又は他の情報を表示することにより付加的な見識を提供する。例えば、利用者が何らかのデータ要素を一つのウィジェットからもう一つのウィジェットへドラッグする（例えばマウス装置を用いた該当要素のカーソル選択及び表示されているインタフェイスを横断する移動を介して）と、アクティブ・リスナ・エージェントはこの情報を、表示されているインタフェイスにおいて、データ要素の構成が利用者が結論（例えば患者の診断及び／又は治療に関する）に到達するのを補助するのに有用な異なるレベルの情報を意味するように再配置することができる（例えば大きさ及び／又は位置）。次いで、アクティブ・リスナ・エージェントは、特定のシナリオにおいて有用であり得る既製の関連ウィジェットをインタフェイスに配置することもできるし、且つ／又はユーザ・インタフェイスにおいてデータ・コンテキストに加えて利用者が変更したウィジェットのコンテンツに基づいて、新たなウィジェットを作成することもできる。
【００２２】
予め決められたワークフローに焦点を合わせるよりも寧ろ、アクティブ・リスナは利用者に対し、既知のワークフロー又はプロトコルが存在しないような幾つかの状況において利用者にとって助けとなる付加的な情報を提供する。履歴データ及び／又は他の入力に基づいて、システムは、利用者が情報に基づいた決定を下すのに関連する付加的な情報及び／又は作用内容を利用者に対して表示する。例えばアプリケーション及び／又はインタフェイスのバックグラウンドにおいて、アクティブ・リスナは、表示されているインタフェイスでのデータ要素の活動を監視することができる。これらのデータ要素が何らかの閾値に達すると、アクティブ・リスナは、利用者が情報に基づいた決定を下すのを補助する付加的な情報を、表示されているインタフェイスに配置する。代替的に又は加えて、アクティブ・リスナは、利用者がアプリケーションに変更を加えたときを検出することができる（例えばデータ要素を一つのウィジェットからもう一つのウィジェットにドラッグ＆ドロップする、検索を行なう、及び診断を変更する等による）。利用者相互作用のコンテキストを表示されているユーザ・インタフェイスのコンテンツと組み合わせることにより、例えば利用者に関連情報及び／又は作用内容を提供することができる。
【００２３】
図１は、本発明の幾つかの実施形態による適応型の業務中心健康管理サービスを提供するワークフロー１００を示す。ワークフロー１００は、医師、病院及び診療所等への患者の来診１０５を含む。患者来診１０５から、クエリ（query）１１０が、検査医及び看護師等のような臨床担当者によって発生される。クエリ１１０は、例えば観察される刺激１１２と患者コンテキスト１１４とを含み得る。クエリ１１０はクエリ・ドライバ１１５に渡される。クエリ・ドライバ１１５は、例えば１又は複数のデータ・ソース１２０及び／又は知識管理サブシステム１６０に問い合わせることができる。データ・ソース（１又は複数）１２０は、検査室結果、診断検査（例えばＸ線、磁気共鳴画像及び超音波等）、患者履歴、保険情報、及び支払請求情報等の１又は複数を含み得る。
【００２４】
幾つかの実施形態では、クエリ・ドライバ１１５は、クエリ強化エンジン（「ＱＵＥＥＮ」）を含み、且つ／又はクエリ強化エンジンと通信することができる。情報は、テキスト（例えば報告及び書面）、テーブル（例えばデータベース）、画像（例えばＸ線及び計算機式断層写真法による走査）、及び動画（例えば手術手順）を含めた複数の形式として表わされ得る。さらに、情報はしばしば、様々なシステムに存在して、ヘテロな（異種のものから成る）環境において記憶され且つ／又は計算される。
【００２５】
クエリ強化エンジンは、情報需要（例えば刺激１１２）及びコンテキスト１１４に基づいて各種の情報源１２０から情報を検索するのに用いられ得る。先ず、元のクエリ１１０及びコンテキスト１１４に基づいて、ＱＵＥＥＮは、情報レジストリに照会することにより、要求された情報を検索するのに何れの情報源（１又は複数）１２０が最も適当であるかを決定する。
【００２６】
一旦、情報源候補（１又は複数）１２０が識別されたら、クエリ１１０が発生されて（クエリ強化エンジン１１５によって）、情報源１２０に渡されて検索される。異なるデータ・リポジトリ（repository）（ファイル・システム及びデータベース等）が、当該リポジトリの内部のデータを検索するために異なる機構を利用する。情報源１２０はこれらの検索機構を包含する。
【００２７】
検索結果の精度を高めるために、検索に先立ってクエリを修正すると有利な場合がある。クエリ強化は、結果を改善する付加的な項をクエリに加えることを含み得る。クエリの精緻化は、性能を高めるためにクエリに対して項を除去する又は項を置換することを含み得る。ＱＵＥＥＮ１１５は、初期クエリを用いて情報を要求し、次いで、例えば性能を高めるためにクエリを強化し又は精緻化することができる。
【００２８】
クエリ１１０は、１又は複数のデータ・ソース１２０からのデータと組み合わされて、情報編成エンジン（「ＩＣＥ」）１２５に与えられ、クエリ１１０に応答してデータ・ソース（１又は複数）１２０からのデータをコンパイルし又はバンドルする。ＩＣＥ１２５は、多数の各種データ・ソース１２０から提示（プレゼンテーション）のための情報をバンドルすることができる。
【００２９】
例えば、所与の情報需要について、目下の特定の作業についてセマンティックに意味のある情報のバンドルを形成するために、幾つかの異なる形式の情報が望ましい場合がある。一つのバンドルが１又は複数の形式の情報を含む（例えば患者履歴及び検査室結果）。様々な情報項目を複数の意味単位として整理することを情報編成又はバンドル化と呼ぶ。ＩＣＥ１２５は、データ・ソース（１又は複数）１２０から検索された情報をまとめて、利用者にとって意味のある一つのバンドルとして編成することを担当する。バンドルは、利用者のセマンティックな必要に基づいて編成されることができ、また例えば利用者のプレファレンス（選好）、及び／又はドメインに適した他の知識によって主導され得る。
【００３０】
幾つかの実施形態では、ＩＣＥ１２５は、編成器（コンポーザ）を用いて、データ・ソース（１又は複数）１２０から検索された情報を編成する。編成器は、例えば編成判定論理（「ＣＤＬ」）を用いて情報を編成する。ＣＤＬの幾つかの実例としては、例えば集計、冗長な情報の消去、情報の軽量要約、及び結果の融合等が挙げられる。
【００３１】
例えばアクティブ・リスナ構成要素を含む制御器が、ＱＵＥＥＮ１１５とＩＣＥ１２５との間の相互作用を管理することができる。ＱＵＥＥＮ１１５が情報を検索したら、この情報はＩＣＥ１２５に渡されて編成及びバンドル化を施された後に、アプリケーション又は利用者に送り届けられる。アクティブ・リスナ構成要素は、例えばＱＵＥＥＮ１１５によって検索されてＩＣＥ１２５に渡された情報を監視してこの情報に反応することができる。
【００３２】
編成時に、何らかの情報が欠落している又は不十分であると決定される場合がある。この場合には、ＩＣＥ１２５は、情報が欠落している／不十分であることを制御器に伝えることができる。次いで、制御器は、検索性能を高めるために１又は複数のクエリ１１０を強化し又は精緻化すべきであるとクエリ・エンジン１１５に伝えることができる。クエリ（１又は複数）１１０が再び行なわれて、結果がＩＣＥ１２５に返されて編成及びバンドル化を施された後に、例えば利用者に返される。
【００３３】
次いで、ＩＣＥ１２５は、クエリ１１０からのコンテキスト情報１１４に基づいて、要求した利用者のために編成されて特化された関連情報を含むバンドル１３０を生成する。バンドル１３０は要約エンジン１３５に渡される。要約エンジン１３５は、バンドル１３０のコンテンツについて多文書要約を提供する。要約については、後にあらためて詳述する。
【００３４】
要約エンジン１３５からの要約による注釈付きの改訂済みバンドル１４０を用いて、プレゼンテーション１４５を生成する。プレゼンテーションは、データ・ソース（１又は複数）１２０のメタデータ検索から返されたテキスト、動画及び画像から成るマルチ・メディア・バンドルを含むことができ、このバンドルは、要約エンジン１３５からのコンテキスト要約を含む。利用者は、プレゼンテーション１４５を通じて細部まで深く検討することができる。医師及び／又は看護師のような利用者は、プレゼンテーション１４５からの情報を用いて、患者をさらに詳細に診断し且つ／又は治療することができる。プレゼンテーション１４５情報からの利用者の反応及び／又は他のフィードバック１５０は、後の利用に備えて知識管理サブシステム１６０に戻され得る。幾つかの実施形態では、知識管理サブシステム１６０に対するアクティブ・リスナ構成要素が、例えば利用者の反応／フィードバック１５０に基づいて付加的なコンテンツ及び／又はアプリケーションを更新し且つ／又は提供する。
【００３５】
ここで、知識管理サブシステム１６０についてさらに詳細に説明する。知識管理サブシステム１６０は、クエリ・ドライバ１１５がデータ・ソース（１又は複数）１２０から関連情報を抽出するためのクエリを形成するのを支援する１若しくは複数のツール及び／又は付加的な情報を含んでいる。刺激１１２及びコンテキスト１１４のようなクエリ１１０情報を知識管理サブシステム１６０に入力して、関連ツール及び／又は情報をクエリ・ドライバ１１５に提供することができる。代替的に及び／又は加えて、臨床医の反応及び／又は他のフィードバック１５０をサブシステム１６０にフィードバックして、さらなる情報を与え、且つ／又は知識管理サブシステム１６０からのさらなる結果を改善することができる。
【００３６】
例えば図１に示すように、知識管理サブシステム１６０は、１又は複数のダッシュボード１６１、１又は複数のオントロジー１６３、手続き及びガイドライン１６５、共通データ・モデル１６７、並びに解析部１６９を含んでいる。知識管理サブシステム１６０は、知識及び用語管理基盤構造（Knowledge and Terminology Management Infrastructure、「ＫＴＭＩ」）をワークフロー１００に与えることができる。オントロジー１６３は、一つのドメインの内部での概念集合、及びこれらの概念の間の関係の形式的な表現を詳細に記述する。オントロジー１６３を用いて、ドメインを定義して、当該ドメインの特性を評価することができる。共通データ・モデル１６７は、特定の環境の内部での各種のデータ・エンティティの間の関係を定義し、データ・エンティティが意味を有するようなコンテキストを確立する。共通データ・モデル１６７は、ワークフロー１００において各アプリケーション及び各データ・ソースをカバーするデータ・モデルを与えて、ワークフロー１００の内部でのデータの関係及び意味を定義する。例えば、解析部１６９を用いて、サブシステム１６０は、共通データ・モデル１６７に基づいてダッシュボード（１又は複数）・コンテンツ１６１、オントロジー（１又は複数）１６３、及び手続き／ガイドライン１６５にアクセスして、クエリ・ドライバ１１５に出力を与えることができる。
【００３７】
ここで、要約エンジン１３５の活動についてさらに詳細に説明する。多文書要約は、同じ主題について書かれた多数のテキストからの情報の抽出（例えば多数の患者にわたる疾患）を目的とした自動式手順である。得られる要約報告によって、検査医及び看護師等のような個々の利用者が、多量の文書に含まれる情報を速やかに知悉することを可能にする。このように、要約エンジン１３５は、ＩＣＥ１２５を補完して、例えば参照をし易くするためにコンテンツを要約して註釈することができる。
【００３８】
多文書要約は、未処理データの検討よりも簡潔で包括的な情報報告を作成する。異なる意見をまとめて骨子を作成し、単一の文書の内部で多数の視点から主題を記述する。簡単な要約の目標は、最も関連するソース文書を指示することにより、情報検索を単純化して時間を短縮することにあるが、包括的な多文書要約は要約自体が要求された情報を含むべきであり、従って精緻化が必要とされる場合に元のファイルにアクセスする必要性を限定する。自動要約は、偏りのない結果を与える試みとして、如何なる編集加筆も主観的な人間の介在もなくアルゴリズム的に多数の情報源から抽出される情報を提示する。
【００３９】
しかしながら、多文書要約はしばしば、大きい文書集合の範囲内で扱われるテーマが多様であるため、単一の文書を要約するよりも複雑である。要約技術は、主文書の各テーマを完全性、読み易さ及び簡潔さと組み合わせることを目的とする。例えば、米国標準技術局によって毎年行なわれているDocument Understanding Conferencesを通じて開発された多文書要約の評価規準を用いることができる。
【００４０】
幾つかの実施形態では、要約エンジン１３５は、ソース・テキストを単に短縮するばかりでなく、ソース・テキストの主要な観点を巡って整理された情報を提示して、所与の主題についてのさらに多様な視点を表わす。かかる品質を達成すると、所与の主題の概要にさらに類似した自動式多文書要約を用いることができる。
【００４１】
多文書要約規準は、次の１又は複数を含み得る。すなわち、全テキスト・セクションをナビゲートすることを容易にする主コンテンツの骨子を含めた明確な構造、各セクションの内部のテキストが意味のある段落に分割されていること、一般的な観点から特定テーマの観点への緩やかな移行、及び読み易さ等であり、読み易さに関して述べると、自動式概要作成は、例えばそれぞれの文書（例えばウェブ・ページ）からの書面に無関係な「情報雑音」が存在しないこと、概要に述べられても説明されてもいない主題への懸垂参照（参照先のない参照）が存在しないこと、一つの文章を横断するテキスト分断が存在しないこと、及び意味論的な冗長性が存在しないこと等を呈し得る。
【００４２】
幾つかの実施形態では、要約アプローチは次の三つのステップを含んでいる。すなわち、１）セグメント分割、２）クラスタ生成／分類、及び３）要約生成である。最初のテキストのセグメント分割は、既存の段落境界に基づいて文書を段落に分割する又は「チャンキング（chunking）」することにより行なわれる。例えば副題及び一行段落はマージされ得る。段落境界が存在しない場合には、例えばＮ語毎（例えば２０語毎）に分割することによりチャンキングを実行することができる。
【００４３】
クラスタ生成について述べると、１又は複数の自然言語処理（「ＮＬＰ」）手法を適用して、例えば二つの語集合の間の類似性を測定することができる。例えば、類似した連語（例えばＮグラム）を含む段落を識別し、二つの節（パッセージ）が類似しているか否かを決定する類似度を定義する。例えば、類似度は、余弦関数に似た出力を与えることができる（例えば値が１に近い結果ほど類似性が大きいことを示す）。これらの尺度を用いて、節の対の全てについて節類似性スコアを算出することができる。
【００４４】
幾つかの実施形態では、多くの節が存在するときにはクラスタの全ての組み合わせを検査すると計算コストが高くなる。従って、クラスタ生成は、シード・クラスタ生成及び分類の二段階で行なわれ得る。シード・クラスタ生成では、標的数のクラスタが見出されるまで完全リンク（complete-link）アルゴリズムを用いることができる。例えば、標的数のクラスタはｌｏｇ（文書数）に等しくすることができる。次いで、分類では、最もよくマッチするシード・クラスタを見出すことにより残りの節を分類する。節が類似性を有しない場合には、この節はごみクラスタに配置される。
【００４５】
次いで、要約生成のために、最も特徴的な段落を各々のクラスタから取り出して、「メタ文書」を形成する。次いで、単一文書要約器を用いて、集合全体についての「要約」を作成する。要約は、情報とバンドルされて、バンドル１４０として与えられる。
【００４６】
作動時のワークフロー１００の一例として、患者に手術を行なうに先立って、医師が患者は如何なるアレルギーを有するかを知りたいと想定する。患者のアレルギーについての情報は、様々なシステムにおいて文書リポジトリ、ファイル・システム、及びデータベース１２０の組み合わせを用いて記憶され得る。ＩＣＥ１２５を用いて、患者のアレルギーについての多様な情報を見出し、バンドルして、医師に提示する。幾つかの文書の段落の内部に埋め込まれている情報もあれば、例えばデータベースのテーブルに見出される情報もある。システムのデータベースが公開されたときに（例えば連結性フレームワーク（Connectivity Framework）を通じて）、ＩＣＥ１２５及びＩＣＥ１２５のＱＵＥＥＮエンジンは、データベース１２０に接続して情報について問い合わせることができる。データベースが特定のシステムについては利用可能でないときにも、このシステムのための文書リポジトリを依然として探索することができる。文書要約器１３５を用いて、検索された文書の要約を与えて、検索された文書から関係する節をクラスタ化して、関係する患者情報を得る。情報はバンドル１４０として整理された後に利用者に届けられる。情報は、例えば基礎となるリポジトリから、情報形式、意味性、情報関連性、及び信頼性スコアに基づいて整理され得る。
【００４７】
幾つかの実施形態では、ワークフロー１００は、クエリ生成エンジン１１５を用いて連結性フレームワーク構成要素から関連情報を継続的に探索することにより利用者を支援する。続いて、利用者に対する適当なプレゼンテーションのために情報を変換する情報編成エンジン１２５を通じてこれらの結果を分類してバンドル化する。
【００４８】
幾つかの実施形態では、適応型ユーザ・インタフェイス（「ＵＩ」）設計が、セマンティック・ウェブ技術を利用することにより達成される。例えば、ドメインの概念及び関係をオントロジーの階層として特徴付けて、上位レベルのオントロジー型構成体に関連付けて適応型の推論及び拡張性を可能にする。
【００４９】
コア・オントロジーが、１又は複数の業務中心設計原理から導かれ得る。例えば、実効的なインタフェイスは、特定の形式の問題を解くために設定された業務ドメインに対して利用者が必要とする視点を表わす情報を表示することができる。もう一つの例として、現在の業務コンテキストにおいて利用者にとって最も重要な情報を焦点エリアに表示して、利用者の注意を引くことができる。コンテキストを保存して業務管理を支援するために、表示器の辺縁に参照情報を提供することができる。さらにもう一つの例として、利用者自身の業務オントロジー（例えば用語及び意味）が、インタフェイス表示の情報要素についての一次ソースであるものとする。
【００５０】
このように、幾つかの実施形態は、個々の需要に合わせて特化され業務ドメインの変化に応答する業務中心アプリケーションを利用者に提示するために、オントロジーのメタデータについて「推論」し得る制御器の利用を介して適応型ユーザ・インタフェイス能力を提供する。かかるユーザ・インタフェイス能力は、アプリケーション・コンテキスト感受型の態様で目標とされる情報を送り届けるインタフェイスを提供することにより、連結性フレームワークがアクセスし得る「外部」データを拾い読みすることに関連する問題を回避するのを補助する。
【００５１】
人間−コンピュータ間の相互作用では、ユーザ・インタフェイス・データ、イベント、及び頻度を表示し、記録して、エピソードとして整理することができる。表示画面に配置されるデータ、エピソード頻度、及び含意関係を算出することにより、特定アプリケーション向けエピソード連関を自動的に導いて、アプリケーション・インタフェイスが利用者に対し時宜に適った援助を適応的に与えるのを可能にすることができる。例えば相互作用追跡、エピソード識別、利用者パターン認識、利用者意図予測、及び利用者プロファイル更新を含めた適応型ユーザ・インタフェイスを設計することに関連する問題を識別することにより、インタフェイスは、利用者のために動作して幾つかの認識された計画に基づいてアプリケーションと相互作用することができる。様々な利用者の需要に適応するために、インタフェイスは、例えば利用者プロファイル及び特定疾患向けワークフローを学習することにより援助を個人別に構成することができる。
【００５２】
図２は、本発明の一実施形態による適応型ユーザ・インタフェイス（「ＵＩ」）２００の一例を示す。ＵＩ２００は、ログイン及び利用者識別エリア２０５、患者識別エリア２１０、警告２１２、及びウィジェット表示エリア２１５を含んでいる。利用者識別エリア２０５は、ＵＩ２００にアクセスするために現在ログインしている利用者を識別する。患者識別エリア２１０は、氏名、識別番号、年齢、性別、生年月日、社会保険番号、及び連絡先情報等のような目標患者についての識別情報を提供する。警告２１２は、患者はアレルギーを有しないという指標のように利用者に注意を促すための患者情報を提供し得る。ウィジェット表示エリア２１２は、ＵＩ２００を介して利用され利用者によって配置可能な１又は複数のウィジェットを含む。
【００５３】
例えば、図２に示すように、ウィジェット表示エリア２１２は、ウィジェット２２０、２３０、２４０、２５０、２６０、２８０を含んでいる。ウィジェットは、多様な情報、臨床判定支援、探索能力、及び臨床的作用内容等を提供し得る。例えば図２に示すように、ウィジェット２２０は、生命徴候／検査室ウィジェットである。生命徴候ウィジェット２２０は、患者についての１又は複数の生命徴候及び／又は検査室検査結果の視覚的指標を与える。例えば、指標は、血圧２２１、尿検査２２３、体重２２５、ブドウ糖２２７、及び体温２２９を含み得る。各々の指標が、型及び値を含む。例えば、血圧指標２２１は、型２２２（例えば血圧）及び値２２４（例えば２００／１３０）を含む。各々の指標２２１、２２３、２２５、２２７、２２９が、当該指標から成分情報の重要性を示すための何らかの色及び／又は何らかの大きさを有する。例えば、血圧指標２２１は、ウィジェット２２０において最も寸法が大きい指標であって、利用者に対し、他の結果を凌ぐ血圧測定値２２１の相対的な重要性を視覚的に示している。尿検査２２３は次に重要であり、以下同様である。もう一つの例として、血圧２２１を赤色とし、尿検査２２３を橙色とし、体重２２５を黄色とし、ブドウ糖２２７及び体温２２９の両方を緑色とする。色を用いて、成分値の重篤度又は重要度を示すことができる。例えば、赤色にした血圧２２１は最大の重要性を意味し、橙色にした尿検査２２３は次に重要であり、以下同様である。このように、指標の大きさ及び／又は色を共に及び／又は別個に用いて、利用者に対し、患者の生命徴候及び検査室結果の調査に置かれるべき優先順位の直接的な視覚的指標を与えることができる。幾つかの実施形態では、指標の選択によって、指標についての情報を生成するのに用いられたデータ、結果、及び／又は文書（１若しくは複数）を検索する。
【００５４】
ウィジェット２３０は、面談要約、報告、及び画像解析等のような患者に関係する臨床文書の一覧を提供する。文書情報は、文書型２３１、文書作成者２３２、文書日付２３３、文書からの評価２３４、文書状態２３５、及び文書に対する行動２３６を含み得る。例えば、文書ウィジェット２３０のエントリは、来診要約型２３１であり、アマンダ・ミラー医師の作成者２３２によって２００８年３月１２日の日付２３３に生成され、子癇前症の可能性との診断２３４であって、状態２３５が署名済みであり、行動２３６が検討であり得る。利用者は、文書エントリを選択して、ウィジェット２３０に参照されている実際の文書を検索して表示することができる。
【００５５】
ウィジェット２４０は、利用者による検討のための１又は複数の撮像検査を提供する。撮像検査ウィジェット２４０は、１又は複数の画像２４４を撮像型２４６及び評価２４８と共に含んでいる。例えば、図２に示すように、ウィジェット２４０は、正常と評価された頭部ＣＴ及び正常と評価された胎児超音波画像を含んでいる。
【００５６】
ウィジェット２５０は、患者について識別された１又は複数の問題２５２、２５４の視覚的表現を提供する。生命徴候ウィジェット２２０と同様に、問題指標２５２、２５４は、何らかの色及び／又は何らかの大きさを有して、問題指標からの成分情報の重要性を示すことができる。例えば、高血圧問題指標２４２は赤色にされて他の問題指標２５４よりも大きい。このように、指標の大きさ及び／又は色を共に及び／又は別個に用いて、利用者に対し、患者問題の調査に置かれるべき優先順位の直接的な視覚的指標を与えることができる。幾つかの実施形態では、問題指標の選択によって、指標についての情報を生成するのに用いられたデータ、結果、及び／又は文書（１若しくは複数）を検索する。
【００５７】
ウィジェット２６０は、患者の来診の１又は複数の理由を利用者に提供する。来診理由ウィジェット２６０は、理由２６２と、利用者が付加的な詳細を表示するために理由２６２を展開する又は付加的な詳細を隠すために理由２６２を収縮させることを可能にするアイコン２６４とを含んでいる。理由２６２は、ウィジェット２２０、２５０からの指標と同様に色分けされて、優先順位、重要性、及び重篤性等の視覚的指標を与えることができる。
【００５８】
ウィジェット２７０は、患者に処方された薬物の一覧を提供する。薬物ウィジェット２７０は、薬物の型２７２、当該薬物の量２７４、及び当該薬物の送達機構２７６を含んでいる。幾つかの実施形態では、薬物の選択は、例えば当該薬物についてのさらなる詳細及び関連する指示を展開することができる。
【００５９】
例えば図２に示すように、利用者はカーソル２８０を操作して、ウィジェットを選択して、ウィジェットを位置２８５に配置することができる。このように、利用者は表示のためのウィジェットを選択し、次いで、ＵＩ２００のウィジェット表示エリア２１５での各ウィジェットのレイアウトを構成することができる。代替的に及び／又は加えて、利用者は、ウィジェット表示エリア２１５においてウィジェットを再配置して、ＵＩ２００のレイアウトを修正することができる。例えば、カーソル２８０を用いて、利用者は、ウィジェット表示エリア２１５の何らかの地点２８５に来診理由ウィジェット２６０を配置することができる。
【００６０】
ＵＩ２００はまた、利用者別ダッシュボード２９２、患者一覧２９４、及び設定／プレファレンス・パネル２９６等のような他の臨床作用内容への１又は複数のリンクを提供することができる。
【００６１】
幾つかの実施形態によって、健康管理情報システムが患者診療の時間線を横断して関連情報を見出して活用することを可能にする。例えば、探索主導型ロール・ベースのインタフェイスによって、末端利用者が、健康管理網を横断してシームレスに医療情報にアクセスし、医療情報を入力し、また検索することを可能にする。適応型ユーザ・インタフェイスが、個々の需要に合わせて特化され、例えば業務ドメインの変化に応答する業務中心インタフェイスを通じて諸能力を提供する。セマンティック技術を強化して、ドメイン概念、利用者のロール及びタスク、並びに情報関係をモデル化することができる。セマンティック・モデルによって、アプリケーションが、利用者及びタスクのコンテキスト情報に基づいてさらに実効的に情報を見出し、整理して、利用者に提示することを可能にする。クエリ及び結果生成のための枠組みを形成する構成要素としては、アプリケーションを構築するためのユーザ・インタフェイス・フレームワーク／構成要素、セマンティック情報及びコンテキストに基づくさらに効率のよい検索、集計、及び情報の編成を可能にするサーバ構成要素、並びにヘテロな情報源を分散環境において接続するデータ・アクセス機構等が挙げられる。
【００６２】
Microsoft（商標）ASP.NET、Ajax（商標）、Microsoft（商標）Windows Presentation Foundation、Google（商標）Web Toolkit、Microsoft（商標）Silverlight、Adobe（商標）、及び他を含めた多様なユーザ・インタフェイスのフレームワーク及び技術を用いてアプリケーションを構築することができる。アプリケーションは、例えばマルチ・コンテンツ及びマルチ・メディア情報を表示するための情報ウィジェットのライブラリから構成され得る。加えて、フレームワークによって、利用者が、ウィジェットのレイアウトを特化して、基礎となるデータと相互作用することを可能にする。
【００６３】
健康管理情報は、多様なデータベース及び記憶（ストレージ）技術、並びにデータ型を用いて多数のアプリケーションに分散され得る。これらのアプリケーションを横断して存在するデータへの共通のインタフェイス及びアクセスを提供するために連結性フレームワーク（「ＣＦ」）を提供し、連結性フレームワークは、共通データ・モデル及び共通サービス・モデル（「ＣＤＭ」及び「ＣＳＭ」）、並びにエンタープライズ・サービス・バス（ＥＳＢ）のようなサービス指向型技術を強化してデータへのアクセスを提供する。
【００６４】
図３は、図２に関連して説明したユーザ・インタフェイスのようなユーザ・インタフェイスを含むモバイル装置の例を示す。図３に示すように、モバイル装置３１０が、グラフィック・ユーザ・インタフェイス３２０、ナビゲーション装置３３０、及び例えばインタフェイス３２０のコンテンツとの相互作用のための１又は複数のツール３４０を含み得る。モバイル装置３１０は、携帯電話、携帯情報端末（ＰＤＡ）、ポケット・パーソナル・コンピュータ、及び／又は他の可搬型計算装置を含み得る。モバイル装置３１０は、例えば外部システムとデータを交換するための通信インタフェイスを含んでいる。
【００６５】
モバイル・サービスとウェブ・サービスとの組み合わせを用いて、モバイル装置３１０を介した情報の送達を行なうことができる。モバイル・ウェブ技術を用いると、ポータビリティ、ユビキタスな連結性、及び位置に基づくサービスを加えて、ウェブに存在する情報及びサービスを強化することができる。アプリケーション及び様々な媒体は別個の貯蔵所（silo）に常駐していなくてもよい。代わりに、これらの装置３１０に搭載されているアプリケーションは、例えばウェブ２．０アプリケーション、従来のデスクトップ・アプリケーション、マルチ・メディア動画及び音声、並びにモバイル装置（例えば携帯電話）の各要素を収集することができる。適応型ユーザ・インタフェイス・アーキテクチャを用いて、利用者が、例えば必要なときに必要な場所で重要な臨床情報を作成し又は消費することを可能にするモバイル装置用のウィジェットを設計することができる。
【００６６】
図４は、本発明の一実施形態による周産期診療における適応型の業務中心ユーザ・インタフェイス４００のユース・ケースの一例を示す。図４の例では、３５歳の妊婦パトリシア・スミスが３回目の妊娠の３４週目にある。診療の全過程を通じて、パトリシアは、初期検査室検査、生命徴候、三次元（「３Ｄ」）胎児超音波、及び他の常套検査を含めて典型的な精密検査を受けている。妊娠性糖尿病を除けばパトリシアは正常な妊娠をしており、全ての指標が、出産予定日に健康な男児を出産するであろうことを示す。
【００６７】
しかしながら、３４週目の予約診療時に、パトリシアの担当産婦人科医は、血圧が以前の測定値１４５／９５に比べて高く、血圧に幾分懸念を感じる。アマンダ・ミラー医師は、心電図（「ＥＫＧ」）及び尿検査（「ＵＡ」）を指示する。パトリシアのＥＫＧは正常洞調律を示すが、ＵＡが、子癇前症を示唆する痕跡量のアルブミンを含めて返ってくる。ミラー医師は、血圧及び腎作用を監視するためにパトリシアに次回の予約を今日から１週間後に入れるように求める。
【００６８】
次の週に、パトリシアの血圧は前回の値（１５０／９８）よりも高く、ミラー医師はもう一度尿検査を指示する。ＵＡは再び陽性と返ってくるが、前回と略同じレベルにある。ミラー医師は、念のため血圧が正常なレベルに下がるまで毎週の来診を続けた方がよいと考える。また、ミラー医師はパトリシアに、子癇の一つの警戒徴候は、突然の激しい頭痛であり、頭痛を起こした場合には診療のための直ちに救急病棟に来診するように伝える。
【００６９】
週末に開かれた息子の５歳の誕生日パーティで、パトリシアは激しい頭痛を起こす。夫のトムは、直ちに妻を地域の病院の救急病棟（「ＥＤ」）に連れて行く。ＥＤの職員は、例えば長期時間線カルテを介してパトリシアのカルテの全てを入手し、パトリシアの症例の様相の全てについて情報を得る。パトリシアの血圧（「ＢＰ」）は２００／１３０まで急上昇し、ＥＤの医師は一連の検査すなわちＵＡ、ＥＫＧ、化学検査（Chem panel）、及び頭部ＣＴを指示する。化学検査及び頭部ＣＴは両方とも正常であるが、ミラー医師が危惧した通り、ＵＡはアルブミン・レベルの上昇（２＋）を示す。これらの検査結果及びパトリシアの状態から鑑みて、ＥＤの医師及びミラー医師は、最善の行動の進路は、パトリシアの血圧が治まり次第、帝王切開で分娩を行なうことであると決断する。パトリシアは、高血圧を制御するためのヒドララジン（静注を介して）、及び頭痛のためのタイレノール３を投与されて、手術準備室に搬送される。
【００７０】
帝王切開は成功し、パトリシア及びトムは６ポンド４オンスの健康な男児エヴァンを無事授かる。１週間の入院の後に、パトリシア及びエヴァンは退院する。パトリシア及びエヴァンの両者は１週間後にミラー医師の診察を受ける。パトリシアのアルブミン及び血圧は正常に戻っており、血糖レベルも正常になっている。
【００７１】
ユーザ・インタフェイス４００を用いて、ミラー医師は、患者の識別４０５に基づいてパトリシアの経過、検査室結果、及び生命徴候等を容易に検討し、入力し、修正することができる。ＵＩ４００は、パトリシアの生命徴候４１０を表示し、パトリシアの血圧に懸念があることを大きい赤のアイコン４１５を通じて視覚的に示す。加えて、異常のある尿検査結果４１７が医師に対して視覚的に強調される。尿検査の臨床詳細情報４１０は、陽性４２５又は陰性４２７の結果を示すように主要な結果を強調した状態で容易に検討され得る。ミラー医師は、パトリシアについて指示した放射線検査４３０及び心臓検査４４０を検討することができ、パトリシアの経過を評価するために以前の経過メモ４５５を含めて文書４５０を調べることができる。ミラー医師（及び／又は例えば補助の看護師）はまた、パトリシアの来診の理由４６０を入力して検討することができる。ヒドララジン及びタイレノール３を処方した後に、ミラー医師は、薬物ウィジェット４７０を介して投与量及び送達方法を確認すると共に、帝王切開の後に修正することができる。ミラー医師がさらに疑問を感じ、且つ／又は追加情報を検索したい場合には、検索欄４８０によって検索を行なうことができる。
【００７２】
図５は、本発明の幾つかの実施形態によるユーザ・インタフェイス・アーキテクチャ５００を示す。アーキテクチャ５００は、ユーザ・インタフェイス変換エンジン５０２、クエリ生成／展開エンジン５０３、情報編成エンジン５０９、多文書要約エンジン５１４、及び連結性フレームワーク５４５への１又は複数のコネクタ５１９を含む。アーキテクチャ５００のこれらの構成要素は、コンピュータ又は掌中型装置のような処理装置に設けられたユーザ・インタフェイス５０１を介して利用者によってアクセス可能である。利用者は、例えばユーザ・インタフェイス５０１を介して情報についてのクエリを発行することができる。
【００７３】
クエリ生成／展開エンジン５０３は、刺激５０４、１又は複数のクエリ生成器５０５、並びにクエリ及び収集された文書５０８を生成するために１又は複数のデータ・ソース５０７を探索する１又は複数のアクセス機構５０６を含む。クエリ及び収集された文書５０８は、アプリケーション５１０、５１１、５１２、５１３を含む情報編成エンジン５０９に渡されて、これらのアプリケーションが例えば処理を行なって認知推論を適用し、クエリ及び収集された文書５０８を整理して、例えばセマンティック・ガイドライン、利用者プレファレンス、及びドメイン関連情報の１又は複数に基づいて、要求を出した利用者にとって意味のある１又は複数のユニットにまとめる。編成器を含むツールセットが、集計、冗長な情報の消去、情報の軽量要約、及び結果の融合のような編成判定論理（「ＣＤＬ」）を用いて情報を編成することができる。アプリケーションは、例えば１又は複数のデータ主導型アプリケーション５１０、エンタープライズ・アプリケーション・インタフェイス５１１、作業／工程主導型アプリケーション５１２、及び特定データ構造向けアプリケーション５１３を含み得る。アプリケーション５１０、５１１、５１２、及び／又は５１３は、新たなデータ型、新たなデータ構造、特定ドメイン向け作業／工程、及び新たなアプリケーション・インタフェイス等に関係する１又は複数のひな型を含み得る。クエリ及び収集された文書５０８の編成及び処理によって、利用者クエリに応答して情報のバンドル５５０が生成される。
【００７４】
多文書要約エンジン５１４は、文書のバンドル５５０を受け取って、文書を節５１５に分割する。節５１５は、類似の概念５１６に基づいてクラスタ化される。次いで、メタ文書５１７が概念５１６から形成される。要約５１８がメタ文書５１７から生成される。クエリ結果５５０、メタ文書５１７、及び／又はメタ文書要約５１８は、ユーザ・インタフェイス５０１を介して利用者に与えられ得る。
【００７５】
連結性フレームワーク５４５へのコネクタ５１９を介して、ユーザ・インタフェイス５０１及びユーザ・インタフェイス５０１の各エンジン５０３、５０９、５１４は、例えばインタフェイス５０１を介した利用者クエリに応答して情報を送受することができる。例えば、クエリ・エンジン５０３は、連結性フレームワーク５４５にアクセスして１又は複数のデータ・ソース５０７に問い合わせを行なうことができる。
【００７６】
連結性フレームワーク５４５は、クライアント・フレームワーク５２０を含む。クライアント・フレームワーク５２０は、１又は複数のプロダクト５２２のためのコンテキスト・マネージャ５２１、患者検索５２３、レジストリ・ナビゲータ５２４、及びビューア５２５を含む。このようにして、幾つかの実施形態では、連結性フレームワーク５２０は、ユーザ・インタフェイス５０１を介して、またユーザ・インタフェイス５０１とは別個に、情報を観察して情報にアクセスするのを容易にすることができる。連結性フレームワーク５４５を介して、クエリ・エンジン５０３、及び／又はユーザ・インタフェイス５０１の他の部分が、複数の階層を通じて情報及び／又はサービスにアクセスすることができる。
【００７７】
階層は、例えばクライアント・フレームワーク階層５２６、アプリケーション階層５２８、及び統合階層５３０を含み得る。クライアント・フレームワーク階層５２６は、例えば情報の入出力を容易にする１又は複数のクライアント・ウェブ・サーバ５２７を含む。アプリケーション階層５２８は、ビジネス・アプリケーション、電子カルテ、エンタープライズ・アプリケーション、及び電子健康管理ポータル等のような事業体及び／又は部署利用に関係する１又は複数のアプリケーション５２９を含む。統合階層５３０は、ウェブ・サービス（「ＷＳ」）、Ｘ１２、及び健康管理規格レベル７（「ＨＬ７」）等のような多様なメッセージ形式を用いた既定インタフェイス及び／又は特化型インタフェイスのような１又は複数の既製インタフェイス５３６及び／又はカスタム・インタフェイス５３７を介して顧客情報技術（「ＩＴ」）５４３と通信する相互運用性強化型プラットフォーム・サーバ５３５を含む。相互運用性強化型プラットフォーム５３５は、例えば共通サービス・モデル（ＣＳＭ）を介してアプリケーション階層５２８の１又は複数のアプリケーション５２９と通信することができる。
【００７８】
例えば図５に示すように、相互運用性強化型プラットフォーム５３５は、例えばエンタープライズ・サービス・バス（「ＥＳＢ」）５３１、レジストリ、データ及びサービス集合５３２、構成情報５３３、及び臨床コンテンツ・ゲートウェイ（「ＣＣＧ」）・インタフェイス・エンジン５３４を含む。ＥＳＢ５３１は、例えばJava（商標）ビジネス・インテリジェンス（「ＪＢＩ」）準拠型ＥＳＢであってよい。ＥＳＢ５３１は、Ｘ１２、ＨＬ７、及びＳＯＡＰ（単純オブジェクト・アクセス・プロトコル）等のような特定のプロトコル／データ型を用いて例えばメッセージ及び／又は他のデータを送信するウェブ・サービスにアクセスする１又は複数の端点又は位置を含み得る。ＣＳＭを用いて、ＥＳＢ５３１は、例えばアプリケーション階層５２８のアプリケーション５２９との通信を容易にする。ＥＳＢ５３１を介して、各レジストリの情報、データ及びサービス・リポジトリ５３２の情報を、例えばクエリに応答してアプリケーション階層５３１に与えることができる。構成情報５３３を用いて、権限を有する利用者、個々の利用者及び／又は利用者のグループ／形式の権限のレベル、セキュリティ構成情報、プライバシー設定、並びに監査情報等のような１又は複数のパラメータを指定することができる。ＣＣＧインタフェイス・エンジン５３１は、顧客のＩＴフレームワーク５４３からデータを受け取って、例えばレジストリ５３２、及び／又はアプリケーション階層５３１のアプリケーション５２９にデータを与える。
【００７９】
例えば図５に示すように、顧客ＩＴ５４３は、サード・パーティの電子メッセージ伝達インタフェイス（「ｅＭＰＩ」）５３８のためのサポート、地域健康情報機関（「ＲＨＩＯ」）５３９のためのサポート、１又は複数のサード・パーティのアプリケーション５４０、事業体間文書共有（「ＸＤＳ」）リポジトリ５４１のためのサポート、及びＸＤＳレジストリ５４２のためのサポート等を含む。相互運用プラットフォーム５３５と共に顧客ＩＴ５４３を用いて、ＲＨＩＯゲートウェイ及びサード・パーティのアプリケーション統合を、連結性フレームワーク５４５への１若しくは複数のインタフェイス及び／又はユーザ・インタフェイス５０１のクエリ生成／展開エンジン５０３を介して提供することができる。
【００８０】
顧客ＩＴフレームワーク５４３は、複数の機関に跨がって健康管理情報の記憶、アクセス及び検索自在性を提供するように構成され得る。顧客ＩＴフレームワーク５４３は、地域社会、地方、国家、及び関連健康管理施設群等にサービスを提供し得る。例えば、顧客ＩＴフレームワーク５４３は、ＲＨＩＯ５３９、国民健康情報網（「ＮＨＩＮ」）、及び医療品質向上協会（「ＭＱＩＣ」）等によって具現化され得る。幾つかの実施形態では、顧客ＩＴ５４３は各健康管理情報システムを接続して、安全、持続可能で且つ規格に基づいた態様で各システムを相互運用することを支援する。
【００８１】
幾つかの実施形態では、顧客ＩＴフレームワーク５４３は、例えばＥＭＲ能力及び集団調査型（population-based）臨床品質報告システムを含めて、技術的アーキテクチャ、ウェブ・アプリケーション、データ・リポジトリを提供する。このアーキテクチャは、ＸＤＳレジストリ５４２及びリポジトリ５４１のような文書記憶、クエリ発行、及び連結性のための構成要素を含む。幾つかの実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、例えば医師のための会員制方式のＥＭＲへの選択肢を含み得る。幾つかの実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、患者及び権限を有する医療診療所にとってアクセス可能な患者カルテ・データ及び関連する監査ログを暗号化された形態で記憶するように構成されているデータベース又は他のデータ記憶部として具現化される。一実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、サーバ又はサーバ群として具現化され得る。ＸＤＳレジストリ５４２及びリポジトリ５４１はまた、別個の物理的位置にある他のサーバ又はサーバ群に接続された一つのサーバ又はサーバ群であってよい。ＸＤＳレジストリ５４２及びリポジトリ５４１は、単一の単位、別個の複数の単位、又は別個の形態にある単位の群に相当することができ、ハードウェア及び／又はソフトウェアとして具現化され得る。ＸＤＳレジストリ５４２及びリポジトリ５４１は、複数の情報源から医療情報を受け取ることができる。
【００８２】
例えばＸＤＳ規格を顧客ＩＴフレームワーク５４３において用いると、さらに効率よく一様な情報交換のために文書クエリ発行及び記憶を統合することができる。顧客ＩＴ５４３を用いると、品質報告及び調査は、ＲＨＩＯ５３９及び／若しくは他の環境において、且つ／又はＲＨＩＯ５３９及び／若しくは他の環境と共に、統合され得る。顧客ＩＴ５４３は、例えば他の規格に基づくシステムと統合してかかるシステムに適応し得る単一ベンダの統合型システムを提供することができる。
【００８３】
顧客ＩＴフレームワーク５４３を介して、ＥＭＲ利用者群は、ＸＤＳレジストリ５４２及びリポジトリ５４１にデータをプールすることに合意し得る。次いで、顧客ＩＴフレームワーク５４３は、この群に研究用集計データ、患者診断及び治療の最善の実行、並びに品質向上ツール等へのアクセスを提供することができる。
【００８４】
ＸＤＳは、患者ＥＭＲを形成する臨床文書に対して登録、配信、及びアクセスを複数の健康管理事業体に跨がって提供する。ＸＤＳは、スケーラブルなアーキテクチャを介して患者文書の記憶、索引作成、及びクエリ／検索のためのサポートを提供する。但し、幾つかの実施形態は、多数の連携ドメイン（共通の方針集合及び単一のレジストリを介して互いに医療コンテンツを共有する方針について合意した健康管理事業体（エンタープライズ）システムの群として定義される）を、各々の連携ドメインが別個の連携ドメインとして自律性を保つが他の関係する連携ドメインとハードウェア及びソフトウェアの一方を共有するようにしてサポートする。ＸＤＳレジストリ５４２及びリポジトリ５４１は、各々の連携ドメインに参加する臨床システムを記述するのに用いられる連携ドメイン関係テーブルを保持し得る。一旦、文書への要求が発行されたら、要求発行元は既知であり、この発行元を用いてリポジトリ５４１の何れの文書（１又は複数）が要求した利用者に公開されるかを決定し、このようにして連携ドメインの自律性を保つ。
【００８５】
幾つかの実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、利用履歴を含めた患者カルテについての暗号化された更新トランザクションを記憶する中央データベースに相当する。一実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１はまた、患者カルテを記憶している。ＸＤＳレジストリ５４２及びリポジトリ５４１は、暗号化された情報へのアクセスを記憶して制御する。一実施形態では、カルテに特定的な論理構造を用いずにカルテを記憶することができる。かかる態様では、ＸＤＳレジストリ５４２及びリポジトリ５４１は検索可能でない。例えば、患者のデータを、データのソースにおいて一意の患者所有キーによって暗号化することができる。次いで、データはＸＤＳレジストリ５４２及びリポジトリ５４１にアップロードされる。患者のデータは、例えばコンピュータ・ユニットにダウンロードされて、暗号化キーによってローカルで解読され得る。一実施形態では、アクセス用ソフトウェア、例えば患者によって用いられるソフトウェア及び診療所によって用いられるソフトウェアが、暗号化／解読を行なう。
【００８６】
幾つかの実施形態では、ＸＤＳレジストリ５４２及びリポジトリ５４１は、患者の登録及び診療所の登録を保持する。診療所は、ＸＤＳレジストリ５４２及びリポジトリ５４１に名称、住所、及び他の識別情報によって登録され得る。診療所は、免許に関連付けられる電子的キーを発行されている。診療所はまた、セキュリティ範疇を認められている。セキュリティ範疇は典型的には、診療所の形式に基づく。幾つかの実施形態では、診療所から送られる要求及びデータは、診療所の免許によってディジタル的に署名されて、ＸＤＳレジストリ５４２及びリポジトリ５４１によって権限を与えられる。患者は、患者識別子及びパスワード・ハッシュによってＸＤＳレジストリ５４２及びリポジトリ５４１に登録され得る。患者はまた、氏名、住所、及び他の識別情報によってＸＤＳレジストリ５４２及びリポジトリ５４１に登録されてもよい。典型的には、登録された患者は、一意の患者識別子及び暗号化キーを含むトークンを発行される。トークンは、例えば磁気カード、フォブ・カード（fob card）、又は患者を識別するのに用いられ得る他の何らかの装置であってよい。患者は、自分のトークン、並びに一実施形態では利用者識別子及びパスワードを用いて、ＸＤＳレジストリ５４２及びリポジトリ５４１にアクセスすることができる。
【００８７】
幾つかの実施形態では、ユーザ・インタフェイス・アーキテクチャ５００の設計は、システムの相互作用性に関係する複数の要因によって誘導される。例えば、一つの要因はシステム状態の可視性である。システムは、妥当な時間内に適当なフィードバックを通じて何が進行しているかについて利用者が情報を得られる状態にすることができる。加えて、もう一つの要因は、システムと「現実世界」との間の一致である。システムは、システム指向の用語ではなく、語、句及び概念が利用者にとって馴染みのある利用者の言語を発することができる。例えば、情報は、現実世界の慣行に従って自然で論理的な順序で現われ得る。加えて、一貫性及び標準に関して述べると、利用者は、異なる語、状況、又は行動が同じ物事を意味するか否かを疑問に感じなくても済むものとする。インタフェイス・アーキテクチャは、例えばプラットフォームの慣行に従うことができる。
【００８８】
もう一つの要因例は、利用者の制御及び自由に関するものである。利用者はしばしば、誤ってシステム作用を選択して対話（ダイアログ）を引き延ばさずに望まない状態から去るために分かり易く標識された「非常口」を必要とする。幾つかの実施形態は、例えばシステム・パラメータの構成設定及び情報クエリに関する動作のアンドゥ（取り消し）及びリドゥ（やり直し）をサポートする。
【００８９】
もう一つの要因は誤りの予防である。誤り易い条件を解消してもよいし、システムが誤りの状態を調べて、利用者に確認の選択肢を提示してから救済行動を実行してもよい。加えて、幾つかの実施形態は、利用者が誤りを認識し、診断して、修復するのを補助することができる。エラー・メッセージを分かり易い言語（例えばコードは用いない）で表現し、問題を正確に指摘して、例えば解決策を建設的に示唆することができる。システムをドキュメンテーションなしに用いることができる方がよい場合でも、ヘルプ及びドキュメンテーションを提供することが必要な場合がある。あらゆるかかる情報が、例えば検索し易く、利用者の作業に焦点を合わせ、実行されるべき具体的なステップを列挙して、且つ過度に膨大でないものとすることができる。
【００９０】
利用者相互作用の容易さに関して述べると、システムは、目的、行動、及び選択肢を可視化することにより利用者の記憶の負担を減少させ又は最小にすることができる。利用者は、対話の一つの部分からもう一つの部分まで情報を覚えておかずに済む。システムの利用のための命令は、可視であるか、適当なときに何時でも容易に検索可能であり得る。さらに、初心者にはしばしば見えない加速器によって、熟練利用者のために相互作用をしばしば加速することができ、システムが非熟練利用者及び熟練利用者の両方の要求を満たし得るようにしている。幾つかの実施形態では、利用者は、頻度の高い行動を特別に構成することができる。加えて、表示される対話は、無関係な情報又は滅多に必要とされない情報を含めないように構成され得る。対話のあらゆる余分な情報単位は、関連のある情報単位と競合して、相対的な見易さを低下させる。
【００９１】
幾つかの実施形態は、視覚化方策として、一つの事業体を横断する大きな臨床データ集合にわたる各種のデータ型のためのグラフィック・ユーザ・インタフェイスを提供する。従って、設計要素は、例えば施設構成要素、単一のアクセス探索点、１又は複数の構成要素／ウィジェット、１又は複数のカルテのグリッド／フォーム、予定、臨床データ結果、グラフ、作業一覧、メッセージ発行／共同作業構成要素、マルチ・スケール画像（例えばディープ・ズーム）、１又は複数の外部構成要素、メール、ＲＳＳフィード、外部ウェブに基づく臨床ツール（例えばＷｅｂＭＤ）等を含み得る。サーバ構成要素は、例えば検索エンジン、ウェブ・サーバ、アクティブ・リスナ、情報編成エンジン、クエリ・エンジン、データ集計器、文書要約器、プロファイル・コンテキスト管理、並びに１又は複数のダッシュボード（例えば臨床及び管理用）等を含み得る。
【００９２】
図６は、本発明の一実施形態によるアクティブ・リスニング及び応答能力を含む適応型ユーザ・インタフェイス・システム６００の一例を示す図である。システム６００は、例えばアクティブ・リスナ・エージェント６１０、ユーザ・インタフェイス６２０、コンテンツ６３０、及び入力６４０を含む。システム６００の構成要素は、例えばソフトウェア、ハードウェア、及び／又はファームウェアの様々な別個の及び／又は統合された組み合わせとして具現化され得る。
【００９３】
コンテンツ６３０は、ユーザ・インタフェイス６２０を介して利用者に表示される。コンテンツ６３０は、図２及び図４に関して上述したウィジェットのような１又は複数のウィジェット、アプリケーション、データ表示、及び画像等を含み得る。ユーザ・インタフェイス６２０を介して、利用者は、インタフェイス６２０に表示されるコンテンツ６３０に影響を与える入力６４０を与えることができる。アクティブ・リスナ・エージェント６１０は、表示されたコンテンツ６３０及び利用者入力６４０をユーザ・インタフェイス６２０のバックグラウンドにおいて監視する。コンテンツ６３０に基づく利用者入力６４０に応答して、アクティブ・リスナ・エージェント６１０は、ユーザ・インタフェイス６２０を介して既存のコンテンツ６３０及び入力６４０に関係するさらに他のコンテンツ６３０を与えることができる。アクティブ・リスナ・エージェント６１０は、例えば利用者及び利用者の作業についてのコンテキスト情報に基づいて、情報を見出し、整理して、利用者に提示することができる。
【００９４】
例えば、図２に示すように、ユーザ・インタフェイス２００は、生命徴候ウィジェット２２０及び患者問題ウィジェット２５０のようなコンテンツ６３０を表示する。利用者が患者の来診理由２５０を入力する６４０と、アクティブ・リスナ・エージェント６１０は、患者の現在の薬物が、患者の問題及び来診理由を検討する医師にとって関心があると決定して、付加的なコンテンツ６３０を薬物情報ウィジェット２７０の形態で提供する。
【００９５】
もう一つの例として、図４に移り、ユーザ・インタフェイス４００は、特に生命徴候／検査室ウィジェット４１０、薬物ウィジェット４７０、及び来診理由ウィジェット４６０のようなコンテンツ６３０を表示する。アクティブ・リスナ・エージェント６１０は、コンテンツ６３０及び利用者入力６４０を監視することができる。生命徴候／検査室ウィジェット４１０からの尿検査情報４１７に基づいて、アクティブ・リスナ・エージェント６１０は、利用者が尿検査及び関係する検査室結果に関するさらなる臨床詳細情報４２０に関心を持つ可能性が高いと決定する。このように、例えば臨床検査室詳細パネル４２０をインタフェイス４００を介して提供することができる。
【００９６】
幾つかの実施形態では、ウィジェット／アプリケーションのライブラリ及び患者情報から検索される付加情報６３０を表示することに加え、例えばアクティブ・リスナ・エージェント６１０は既存のコンテンツ６３０及び／又は入力６４０に基づいて新たなコンテンツ６３０を生成することができる。例えば、利用者が薬物ウィジェット又はアプリケーション（図２に示す薬物ウィジェット２７０等）から患者薬物情報をドラッグして、この情報を患者問題ウィジェット又はアプリケーション（図２に示す問題ウィジェット２５０等）まで移動させた場合には、新たなウィジェットを生成して（且つ／又は問題ウィジェットを修正して）、高血圧のような患者問題と、ヒドララジンのような患者によって摂取されている薬物との間の相関を示して、問題に対処することができる。
【００９７】
幾つかの実施形態では、修正された及び／又は新たに作成されたウィジェット及び／又は他のアプリケーションを後の利用に備えて保存することができる。例えば、利用者がウィジェットを保存することもできるし、且つ／又はシステムがウィジェットを自動的に保存することもできる。例えば、ウィジェットを一般的に保存することもできるし、且つ／又は特定の利用者、モード、及びグループ等に関して保存することもできる。
【００９８】
図７は、本発明の幾つかの実施形態による臨床コンテンツとの適応型ユーザ・インタフェイス作用のための方法の流れ図７００を示す。
【００９９】
ブロック７１０では、利用者による検討のためにコンテンツを表示する。例えば、患者に関係する臨床コンテンツを、患者の電子カルテ情報へのアクセスのような利用者要求に応答してユーザ・インタフェイスを介して利用者に表示することができる。
【０１００】
ブロック７２０では、利用者入力を受け入れる。例えば、ユーザ・インタフェイスを介して、利用者は、表示されている情報を修正し、表示されているアプリケーションと相互作用し、情報を追加し、さらなる情報を要求する等を行なうことができる。例えば、利用者入力は、患者についての情報の要求、ウィジェットの起動、及びユーザ・インタフェイスの表示での情報の配置等を含み得る。利用者入力は、刺激及びコンテキストのような患者面談に関する情報を含み得る。利用者入力は、利用者によって直接提供されることもできるし、且つ／又は例えばインタフェイスを介して利用者のために表示されている他のアプリケーション若しくはウィジェットを介して抽出されることもできる。
【０１０１】
ブロック７３０では、コンテンツ及び入力を監視する。例えば、アクティブ・リスナが、ユーザ・インタフェイスを介してコンテンツ及び活動を「聴取」し又は監視して、利用パターン、関心のある主題、並びに表示されているアプリケーション及び／又はコンテンツに対する変更等を識別することができる。
【０１０２】
ブロック７４０では、付加的なコンテンツを提供する。例えば、表示されているコンテンツ及びコンテンツとの利用者相互作用に基づいて、アクティブ・リスナは、利用者にとって有用であると考えられる付加的なコンテンツを提供する。
【０１０３】
ブロック７５０では、コンテンツを修正する。例えば、表示されているコンテンツ（例えばアプリケーション及びデータ）との利用者相互作用に基づいて、コンテンツを修正することができる。例えば、患者データを、インタフェイスを介して利用者によって更新することができる。もう一つの例として、利用者は、一つのアプリケーションからもう一つのアプリケーションへ情報を入力し且つ／又は伝達して、新たなアプリケーション（例えば新たなユーザ・インタフェイス・ウィジェット）を作成し、且つ／又は既存のアプリケーションを修正することができる。
【０１０４】
ブロック７６０では、修正後のコンテンツを利用者に提供する。例えば、更新済み患者データ、新たなアプリケーション、及び修正後アプリケーション等をユーザ・インタフェイスを介して利用者に提供する。例えば、サムネール、リンク、要約、及び／又は他のデータ表現をユーザ・インタフェイスを介して利用者にグラフィック的に提供することができる。サムネール、リンク、及び要約等の選択によって、例えば利用者による検討のためのさらなるレベルの詳細情報、並びに／又はソース文書の検索及び表示を生成することができる。加えて、新たなウィジェットを、監視されているコンテンツ及び／又は行動に基づいてライブラリから選択して表示することができる。代替的に又は加えて、インタフェイスを介した利用者による利用のために既存のウィジェット及び／又は他の情報から新たなウィジェットを作成することができる。修正後の情報は、例えば後の利用に備えて保存され得る。
【０１０５】
方法７００の各ステップの１又は複数は、例えばハードウェア、ファームウェア、及び／又はソフトウェアの一組の命令として、単独で又は組み合わせて具現化され得る。幾つかの例は、メモリ、ハード・ディスク、ＤＶＤ、又はＣＤのようなコンピュータ可読の媒体に常駐して汎用コンピュータ又は他の処理装置において実行される一組の命令として提供され得る。
【０１０６】
幾つかの例は、これらのステップの１又は複数を省いていてもよいし、且つ／又は列挙されている順序とは異なる順序で各ステップを実行してもよい。例えば、幾つかのステップは幾つかの例では実行されない場合がある。さらにもう一つの例として、幾つかのステップを、上で列挙したものとは異なる同時を含めた時間的な順序で実行してもよい。
【０１０７】
このように、幾つかの実施形態は、例えば単一のアクセス点、モダリティ交差型のデータ・アクセス、ＸＤＳ準拠、プッシュ・プル能力、合意型構築、透明性、利用によって強化される知識管理、プラットフォーム交差型（ウェブ及びモバイル等）のアクセス容易性、並びに利用者の情報空間のシステム・レベル像を含めた複数の利点を提供する。
【０１０８】
幾つかの実施形態は、多様な臨床アプリケーションのためのアーキテクチャ及びフレームワークを提供する。このフレームワークは、限定しないがグラフィック・ユーザ・インタフェイス（ＧＵＩ）等を含むフロント・エンド構成要素を含むことができ、また様々な程度までシン（thin）・クライアント・システムであってもシック（thick）・クライアント・システムであってもよく、例えば幾つか又は全てのアプリケーション及び処理が、クライアントのワークステーションにおいて、サーバにおいて、且つ／又は部分的にクライアントのワークステーションにおいて及び部分的にサーバにおいて、実行される。
【０１０９】
本書に記載されるユーザ・インタフェイス・システム及び方法の例は、病院情報システム（「ＨＩＳ」）、放射線情報システム（「ＲＩＳ」）、画像保管及び通信システム（「ＰＡＣＳ」）、心血管情報システム（「ＣＶＩＳ」）、図書館情報システム（「ＬＩＳ」）、事業体臨床情報システム（「ＥＣＩＳ」）、電子カルテ・システム（「ＥＭＲ」）、及び検査室結果／指示システム等のような１又は複数の臨床情報システムと共に用いられ得る。かかるシステムは、例えばソフトウェア、ハードウェア、及び／又はファームウェアとして具現化され得る。幾つかの具現化形態では、これらのシステムの１又は複数は、シン・クライアント及び／又はダウンロード可能なソフトウェアという解決策を介して遠隔で具現化され得る。さらに、１又は複数の構成要素を共に組み合わせ且つ／又は具現化することができる。
【０１１０】
幾つかの実施形態では、アクティブ・リスナ・エージェントが、コンピュータ装置、及び／又はユーザ・インタフェイスのようなソフトウェア・アプリケーションのフォアグラウンド及び／又はバックグラウンドで動作して、利用者及びプログラムの活動を監視する。例えば、アクティブ・リスナ・エージェントは、ユーザ・インタフェイスにおけるウィジェットに関係する情報を集めることができる。また、アクティブ・リスナ・エージェントは、例えばユーザ・インタフェイス及びユーザ・インタフェイスのコンテンツに関して利用者によって生成される行動に関係する情報を集めることができる。
【０１１１】
幾つかの実施形態では、アプリケーション（例えばウィジェット）情報及び利用者相互作用に基づいて、アクティブ・リスナ・エージェントは、現在のコンテキストに基づいて利用者にとって重要な情報及び／又は作用内容を識別することができる。一実施形態では、ユーザ・インタフェイスに表示されている１又は複数のデータ要素が予め決められた閾値に達したことをアクティブ・リスナ・エージェントが検出した場合には、アクティブ・リスナは、利用者が十分な情報に基づく決定を下すことを可能にするのを補助する付加的な関連情報を含む１又は複数のウィジェットをユーザ・インタフェイスに自動的に配置する。もう一つの実施形態では、アクティブ・リスナ・エージェントは、アプリケーションとの利用者相互作用に反応することにより利用者を補助することができ、また利用者の行動の結果として表示されているユーザ・インタフェイスにウィジェット（１又は複数）の形態にある付加的な情報及び／又は他の情報を表示することにより付加的な見識を提供する。例えば、利用者が何らかのデータ要素を一つのウィジェットからもう一つのウィジェットへドラッグする（例えばマウス装置を用いた該当要素のカーソル選択及び表示されているインタフェイスを横断する移動を介して）と、アクティブ・リスナ・エージェントはこの情報を、表示されているインタフェイスにおいて、データ要素の構成が利用者が結論（例えば患者の診断及び／又は治療に関する）に到達するのを補助するのに有用な異なるレベルの情報を意味するように再配置することができる（例えば大きさ及び／又は位置）。次いで、アクティブ・リスナ・エージェントは、特定のシナリオにおいて有用であり得る既製の関連ウィジェットをインタフェイスに配置することもできるし、且つ／又はユーザ・インタフェイスにおいてデータ・コンテキストに加えて利用者が変更したウィジェットのコンテンツに基づいて、新たなウィジェットを作成することもできる。
【０１１２】
予め決められたワークフローに焦点を合わせるよりも寧ろ、アクティブ・リスナは利用者に対し、既知のワークフロー又はプロトコルが存在しないような幾つかの状況において利用者にとって助けとなる付加的な情報を提供する。履歴データ及び／又は他の入力に基づいて、システムは、利用者が情報に基づいた決定を下すのに関連する付加的な情報及び／又は作用内容を利用者に対して表示する。例えばアプリケーション及び／又はインタフェイスのバックグラウンドにおいて、アクティブ・リスナは、表示されているインタフェイスでのデータ要素の活動を監視することができる。これらのデータ要素が何らかの閾値に達すると、アクティブ・リスナは、利用者が情報に基づいた決定を下すのを補助する付加的な情報を、表示されているインタフェイスに配置する。代替的に又は加えて、アクティブ・リスナは、利用者がアプリケーションに変更を加えたときを検出することができる（例えばデータ要素を一つのウィジェットからもう一つのウィジェットにドラッグ＆ドロップする、検索を行なう、及び診断を変更する等による）。利用者相互作用のコンテキストを表示されているユーザ・インタフェイスのコンテンツと組み合わせることにより、例えば利用者に関連情報及び／又は作用内容を提供することができる。
【０１１３】
幾つかの実施形態では、データ要素通信（「ＤＥＣ」）ウィジェット（例えば「ベルクロ」ウィジェット）によって、利用者が、ユーザ・インタフェイスの画面の他の任意のウィジェットから任意の臨床要素（１又は複数）を選択し又は引き出して、選択された臨床要素（１又は複数）をＤＥＣウィジェットの「保持ビン」又は保持エリアに投入することを可能にする。臨床要素は、例えば患者情報、他の臨床詳細情報、及び／又は要約表現の背後に隠されている詳細データの要約表現を表わし得る。臨床要素（１若しくは複数）及び／又は関連情報の選択及び送信は、単独で、且つ／又は例えば上述のアクティブ・リスナ・エージェントのようなアクティブ・リスナ・エージェントと共に実行され得る。例えば、幾つかの実施形態では、アクティブ・リスナ・エージェントは、幾つかの規則、規準、及び観察された利用パターン等に基づいて保持エリア８００を自動的に埋めることができる。
【０１１４】
例えば図８に示すように、ＤＥＣウィジェットの保持エリア８００が、ＥＣＧ表現８０５、脳ＭＲ画像又は画像系列８１０、及び臨床詳細情報８１５等を含んでいる。表現８０５、８１０、８１５等は、例えば基礎となる臨床コンテンツへのグラフィック参照及び／又はリンクを提供する（図１〜図７に関して上に記載されるウィジェットの１又は複数に関して等）。保持ビン又はエリア８００と共に動作するツール又はウィジェットによって、利用者が、保持エリア８００の情報を電子メール及び／又は他の方法で送信する適当な人物（１又は複数）を選択することを可能にする。宛先（１又は複数）８２０を指定して、送ろうとしているデータを記述する付加的な情報又は詳細８２５を与えることができる。利用者は、「メッセージ送信（Send Message）」を選択してメッセージを受取者（１又は複数）に送信することができる。幾つかの実施形態では、保持エリア８００は、メッセージ・エリア８２５を含んでいてもよいし、メッセージ・エリア８２５に含まれていてもよい。
【０１１５】
受取者がメッセージを受け取るときには、電子メール及び／又は他の送信は、送信側利用者が選択した情報、並びに幾つかの実施形態ではウィジェット・オブジェクト８０５、８１０、８１５等によって表わされるメッセージに埋め込まれている詳細情報を含み得る。メッセージを、利用者の電子メール受信ボックスにおいて受け取ることもできるし、データベース・レコードとして追加することもできるし、ユーザ・インタフェイス・ウィジェット等として生成することもできる。メッセージはまた、健康管理情報システム、電子カルテ、電子的指示システム、電子的処理システム、データ記憶部又はアーカイブ等に転送され得る。
【０１１６】
幾つかの実施形態では、グラフィック表現（例えば様々な大きさの色付きの四角形）を詳細データと置き換える。例えば、図９に示すように、受取者に送信される電子メール９００が、図８に示す保持エリア８００からのＥＣＧ表現８０５、脳ＭＲ画像８１０、及び臨床詳細情報８１５に関する展開された詳細を含む。電子メール９００は、患者情報９０５、臨床詳細情報９１０、ＭＲ画像９１５、及び患者ＥＣＧデータ９２０を含んでいる。
【０１１７】
幾つかの実施形態では、メッセージ９００からの情報を、例えば他のアプリケーション又はインタフェイスへ転送することができる。例えば、受取者は、メッセージ９００から内容を抽出して、この内容をユーザ・インタフェイス・ウィジェット、記憶、他の送信、及び／又は他のアプリケーションへ転送して処理させることができる。もう一つの例として、メッセージ９００はウィジェット又はアプリケーションによって受け取られてもよく、ウィジェット又はアプリケーションは内容を受取者のために表示し、且つ／又は／メッセージ９００の内容を処理して、１又は複数のアプリケーション及び／又は記憶に配信する。
【０１１８】
図１０は、本発明の幾つかの実施形態による１又は複数のアプリケーション又はウィジェットからの１又は複数の臨床要素の選択、保持、及び１又は複数の受取者への送信を容易にするウィジェット・システム１０００の一例を示す。システム１０００は、コンテンツ１０２０を含むユーザ・インタフェイス１０１０を含む。コンテンツ１０２０は、アプリケーション／ウィジェット、臨床データ、及び外部システム／情報へのリンク／接続等を含み得る。インタフェイス１０１０はまた、臨床要素送信ユニット１０３０を含み、且つ／又は臨床要素送信ユニット１０３０への接続を有する。臨床要素送信ユニット１０３０は、利用者選択、並びに／又は１若しくは複数の規則及びプレファレンス等を用いた自動選択の何れかを介してコンテンツ１０２０を受け取る。臨床要素送信ユニット１０３０は、単独で、且つ／又は例えば上述のアクティブ・リスナ・エージェントのようなアクティブ・リスナ・エージェントと共に用いられ得る。臨床要素送信ユニット１０３０は選択されたコンテンツ１０２０をパッケージ化して、受取者１０４０へ送信する。選択されたコンテンツ１０２０の送信は、例えば臨床データ要素の表現及び／若しくは基礎となる詳細、並びに／又は他の情報を含み得る。受取者１０４０は、１又は複数の医師（例えば医師のコンピュータ）、アプリケーション／ウィジェット、インタフェイス、及びデータ記憶部等を含み得る。システム１０００の各構成要素は、例えばハードウェア、ソフトウェア、及び／若しくはファームウェアとして、単独で且つ／又は様々な組み合わせで具現化され得る。システム１０００がソフトウェアのみにおいて具現化される範囲まででは、システム１０００の構成要素（例えばユーザ・インタフェイス１０１０、コンテンツ１０２０、臨床要素送信ユニット１０３０、及び／又は受取者１０４０）の１又は複数が、有形の媒体に記憶されている機械可読の命令を含む。また、例えばシステム１０００の構成要素の任意のものが、特定応用向け集積回路（「ＡＳＩＣ」）及び／又は他の論理回路のようなハードウェアによって具現化され得る。
【０１１９】
図１１は、本発明の幾つかの実施形態による１又は複数のアプリケーション又はウィジェットからの１又は複数の臨床要素の選択、保持、及び１又は複数の受取者への送信を容易にする方法１１００の流れ図を示す。
【０１２０】
ブロック１１１０では、利用者が、ユーザ・インタフェイスを介して表示され且つ／又はアクセス可能な要素を選択する。臨床要素は、例えば患者情報、他の臨床詳細情報、及び／又は要約表現の背後に隠されている詳細データの要約表現を表わし得る。例えば、利用者は、ユーザ・インタフェイスの放射線ウィジェットからＭＲ画像系列（例えば図８に示す脳ＭＲ画像８１０）の表現を選択することができる。
【０１２１】
ブロック１１２０では、利用者は、選択された臨床要素をユーザ・インタフェイス画面の保持用又は一時的記憶エリアに投入する。例えば、利用者は、ＭＲ画像系列の表現のような選択された臨床要素を、ＤＥＣウィジェットのようなユーザ・インタフェイスのウィジェットの保持エリアにドラッグ＆ドロップすることができる。
【０１２２】
ブロック１１３０では、利用者は、選択された臨床要素の送信のための１又は複数の受取者を選択する。例えば、ユーザ・インタフェイス・ツール又はウィジェットによって、利用者が保持ビン（例えば図８に示す保持エリア８００）の情報を電子メール及び／又は他の方法で送信する適当な人物（１又は複数）を選択することを可能にする。宛先（１又は複数）を指定して、例えば送ろうとしている臨床要素（１又は複数）及び／又は他の情報を記述する付加的な情報又は詳細を与えることができる。
【０１２３】
ブロック１１４０では、選択された臨床要素を選択された受取者（１又は複数）へ送信する。例えば、利用者は、ユーザ・インタフェイスのウィジェットを介して「メッセージ送信」を選択して、１若しくは複数の選択された臨床要素及び／又は付加的な情報を含むメッセージを所期の受取者（１又は複数）に送信することができる。
【０１２４】
ブロック１１５０では、受取者が、送信された臨床要素を受け取る。受取者がメッセージを受け取るときには、電子メール及び／又は他の送信は、送信側利用者が選択した情報、並びに幾つかの実施形態ではメッセージに埋め込まれている詳細情報（例えば図８に示すウィジェット・オブジェクト８０５、８１０、８１５によって表わされる情報等）を含み得る。幾つかの実施形態では、メッセージにドラッグ＆ドロップされたグラフィック表現（例えば様々な大きさの色付きの四角形）を基礎となる詳細データと置き換えてもよい。例えば、図９に示すように、受取者に送信された電子メール９００は、図８に示す保持エリア８００からのＥＣＧ表現８０５、脳ＭＲ画像８１０、及び臨床詳細情報８１５に関する展開された詳細を含む。電子メール９００は、例えば患者情報９０５、臨床詳細情報９１０、ＭＲ画像９１５、及び患者ＥＣＧデータ９２０を含んでいる。このように、幾つかの実施形態では、臨床要素のグラフィック表現を送信メッセージに含めることにより、表現の基礎となるコンテンツが含められて、情報を観察する権限を有する１又は複数の人物、情報システム、アーカイブ、及び電子カルテ等を含めて１又は複数の受取者に送信される。幾つかの実施形態では、メッセージからの情報を、例えば他のアプリケーション又はインタフェイスに転送することができる。
【０１２５】
方法１１００の１又は複数の構成要素は、例えばハードウェア、ファームウェア、及び／又はソフトウェアの一組の命令として、単独で又は組み合わせて具現化され得る。幾つかの例は、メモリ、ハード・ディスク、ＤＶＤ、又はＣＤのようなコンピュータ可読の媒体に常駐して、汎用コンピュータ又は他の処理装置において実行される一組の命令として提供され得る。
【０１２６】
幾つかの例は、これらのステップの１又は複数を省いていてもよいし、且つ／又は列挙されている順序とは異なる順序で各ステップを実行してもよい。例えば、幾つかのステップは幾つかの例では実行されない場合がある。さらにもう一つの例として、幾つかのステップを、上で列挙したものとは異なる同時を含めた時間的な順序で実行してもよい。
【０１２７】
図１２は、本書に記載されるシステム及び方法を具現化するのに用いられ得るプロセッサ・システム１２１０の一例のブロック図である。図１２に示すように、プロセッサ・システム１２１０はプロセッサ１２１２を含んでおり、プロセッサ１２１２は相互接続バス１２１４に結合されている。プロセッサ１２１２は、例えば任意の適当なプロセッサ、処理ユニット、又はマイクロプロセッサであってよい。図１２には示していないが、システム１２１０はマルチ・プロセッサ・システムであってもよく、従ってプロセッサ１２１２と同等又は類似しており相互接続バス１２１４に結合されて連絡する１又は複数の付加的なプロセッサを含み得る。
【０１２８】
図１２のプロセッサ１２１２は、メモリ制御器１２２０及び入出力（「Ｉ／Ｏ」）制御器１２２２を含むチップセット１２１８に結合されている。周知のように、チップセットは典型的には、Ｉ／Ｏ作用及びメモリ管理作用、並びにチップセット１２１８に結合されている１又は複数のプロセッサによってアクセス可能であり又は用いられる複数の汎用及び／又は特殊目的のレジスタ及びタイマ等を提供する。メモリ制御器１２２０は、プロセッサ１２１２（又は多数のプロセッサが存在する場合には複数のプロセッサ）がシステム・メモリ１２２４及び大容量記憶メモリ１２２５にアクセスすることを可能にする作用を果たす。
【０１２９】
システム・メモリ１２２４は、例えば、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、フラッシュ・メモリ及び読み取り専用メモリ（ＲＯＭ）等のような所望の任意の形式の揮発性及び／又は非揮発性メモリを含み得る。大容量記憶メモリ１２２５は、ハード・ディスク・ドライブ、光学式ドライブ、及びテープ記憶装置等を含めた所望の任意の形式の大容量記憶装置を含み得る。
【０１３０】
Ｉ／Ｏ制御器１２２２は、プロセッサ１２１２が、Ｉ／Ｏバス１２３２を介して周辺入出力（「Ｉ／Ｏ」）装置１２２６及び１２２８、並びに網インタフェイス１２３０と通信することを可能にする作用を果たす。Ｉ／Ｏ装置１２２６及び１２２８は、例えばキーボード、ビデオ・ディスプレイ又はモニタ、及びマウス等のような所望の任意の形式のＩ／Ｏ装置であってよい。網インタフェイス１２３０は、プロセッサ・システム１２１０がもう一つのプロセッサ・システムと通信することを可能にする例えばイーサネット（商標）装置、非同期転送モード（「ＡＴＭ」）装置、８０２．１１装置、ＤＳＬモデム、ケーブル・モデム、及び携帯電話用モデム等であってよい。
【０１３１】
メモリ制御器１２２０及びＩ／Ｏ制御器１２２２は図１２ではチップセット１２１８の内部の別個のブロックとして示されているが、これらのブロックによって果たされる作用は、単一の半導体回路の内部で一体化されていてもよいし、２以上の別個の集積回路を用いて具現化されてもよい。
【０１３２】
このように、幾つかの実施形態は、複数の事業体（エンタープライズ）システムに跨がる末端利用者による情報へのアクセスを提供する。幾つかの実施形態は、末端利用者が健康管理網を横断してシームレスに医療情報にアクセスし、医療情報を入力し、また検索することを可能にする探索主導型、ロール・ベース、ワークフロー・ベース、及び／又は疾患ベースのインタフェイスという技術的効果を提供する。幾つかの実施形態は、個々の需要に合わせて特化され業務ドメインの変化に応答する業務中心インタフェイスを通じて適応型ユーザ・インタフェイス能力を提供する。幾つかの実施形態は、適応型の業務中心ユーザ・インタフェイス技術ソフトウェア・アーキテクチャを導入し、このアーキテクチャは、「業務中心」の活動の観点からの業務ドメイン、及び「業務中心」の活動を支援する具現化形態を達成する計算機構を特徴付けるために、オントロジー・モデル生成アプローチを用いると共に、業務中心の特徴付け、及びエンタープライズ・レベルのアプリケーションへのユーザ・インタフェイスの提示機構において、適応型相互作用を利用者指向型及び自動型の両方で提供する。幾つかの実施形態は、単純化されたグラフィック・ベースの保持エリア及びメッセージ伝達システムを介して臨床コンテンツを権限を有する利用者へ転送するという技術的効果を提供する。幾つかの実施形態は、臨床データのグラフィック指標を、基礎となる臨床データ自体を含むメッセージへ変換して、もう一つのシステムへのメッセージ伝達及び／又は送信を行なう。
【０１３３】
幾つかの実施形態は、セマンティック技術を強化して、例えばドメイン概念、利用者のロール及びタスク、並びに情報関係をモデル化する適応型ユーザ・インタフェイスを提供する。セマンティック・モデルによって、アプリケーションが、利用者及びタスクのコンテキスト情報に基づいてさらに実効的に情報を見出し、整理して、利用者に提示することを可能にする。アプリケーションは、マルチ・コンテンツ及びマルチ・メディア情報を表示するための情報ウィジェットのライブラリから構成され得る。加えて、この枠組みによって、利用者が、ウィジェットのレイアウトを特化して、基礎となるデータと相互作用することを可能にする。
【０１３４】
幾つかの実施形態は、アプリケーションからの１又は複数の臨床要素の抽出、保持、及び受取者への送信を容易にするシステム及び方法を提供する。幾つかの実施形態は、ユーザ・インタフェイスにおける臨床コンテンツのグラフィック表現を電子的メッセージを介して受取者に与えられる詳細な臨床コンテンツへ変換するという技術的効果を提供する。
【０１３５】
幾つかの実施形態は、以上に述べた作用内容を具現化する方法、システム、及び任意の機械可読の媒体におけるコンピュータ・プログラムを思量している。幾つかの実施形態は、既存のコンピュータ・プロセッサを用いて、又はこの目的若しくは他の目的のために組み入れられた特殊目的のコンピュータ・プロセッサによって、又は例えば結線システム及び／若しくはファームウェア・システムによって具現化され得る。
【０１３６】
以上に述べたシステムの構成要素及び／又は方法のステップの１又は複数は、例えばハードウェア、ファームウェア、及び／又はソフトウェアの一組の命令として、単独で又は組み合わせて具現化され得る。幾つかの実施形態は、メモリ、ハード・ディスク、ＤＶＤ、又はＣＤのようなコンピュータ可読の媒体に常駐して、汎用コンピュータ又は他の処理装置において実行される一組の命令として提供され得る。本発明の幾つかの実施形態は、方法ステップの１又は複数を省いていてもよいし、且つ／又は列挙された順序とは異なる順序で各ステップを実行してもよい。例えば、幾つかのステップは本発明の幾つかの実施形態では実行されない場合がある。さらにもう一つの例として、幾つかのステップを、上で列挙したものとは異なる同時を含めた時間的な順序で実行してもよい。
【０１３７】
幾つかの実施形態は、コンピュータ実行可能な命令又はデータ構造を担持し又は記憶したコンピュータ可読の媒体を含んでいる。かかるコンピュータ可読の媒体は、汎用若しくは特殊目的のコンピュータ、又はプロセッサを有する他の機械によってアクセスされ得る任意の利用可能な媒体であってよい。例として述べると、かかるコンピュータ可読の媒体は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ、ＣＤ−ＲＯＭ若しくは他の光学的ディスク記憶装置、磁気ディスク記憶装置若しくは他の磁気記憶装置、又は所望のプログラム・コードをコンピュータ実行可能な命令若しくはデータ構造の形態で担持し若しくは記憶するのに用いることができ、汎用若しくは特殊目的のコンピュータ、又はプロセッサを有する他の機械によってアクセスされ得る他の任意の媒体を含み得る。上述の組み合わせもまたコンピュータ可読の媒体の範囲に含まれる。コンピュータ実行可能な命令は例えば、汎用コンピュータ、特殊目的コンピュータ、又は特殊目的処理機械に、何らかの作用又は作用群を果たさせるような命令及びデータを含んでいる。
【０１３８】
一般的には、コンピュータ実行可能な命令は、特定のタスクを実行し又は特定の抽象的なデータ型を具現化するルーチン、プログラム、オブジェクト、コンポーネント及びデータ構造等を含んでいる。コンピュータ実行可能な命令、関連するデータ構造、及びプログラム・モジュールは、本書に開示された幾つかの方法及びシステムのステップを実行するプログラム・コードの例を表わしている。かかる実行可能な命令の特定の系列又は関連するデータ構造は、かかるステップに記載された作用を具現化する対応する動作の例を表わしている。
【０１３９】
本発明の各実施形態は、プロセッサを有する１又は複数のリモート・コンピュータへの論理的接続を用いて網化された環境で実施され得る。論理的接続は、本書において限定ではなく例示のために提示される構内網（ＬＡＮ）及び広域網（ＷＡＮ）を含み得る。かかる網環境は、オフィス内又は企業内コンピュータ網、イントラネット及びインターネットとして普及しており、広範な異なる通信プロトコルを用いることができる。当業者は、かかる網計算機環境が典型的には、パーソナル・コンピュータ、掌中型装置、マルチ・プロセッサ・システム、マイクロプロセッサ方式又はプログラム可能型の消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、及びメインフレーム・コンピュータ等を含めて、多くの形式のコンピュータ・システム構成を包含することを認められよう。本発明の各実施形態はまた、通信網を介してリンクされる（結線リンク、無線リンク、又は結線リンク若しくは無線リンクの組み合わせのいずれかによる）ローカル及びリモートの処理装置によってタスクが実行される分散型計算機環境で実施されてもよい。分散型計算機環境では、プログラム・モジュールはローカル及びリモートの両方のメモリ記憶装置に位置していてよい。
【０１４０】
本発明の各実施形態の全体システム又は各部分を具現化する例示的なシステムは、処理ユニット、システム・メモリ、及びシステム・メモリを含む様々なシステム構成要素を処理ユニットに結合するシステム・バスを含むコンピュータの形態にある汎用計算機装置を含み得る。システム・メモリは読み出し専用メモリ（ＲＯＭ）及びランダム・アクセス・メモリ（ＲＡＭ）を含み得る。コンピュータはまた、磁気ハード・ディスクに対する読み書きを行なう磁気ハード・ディスク・ドライブ、取り外し可能な磁気ディスクに対する読み書きを行なう磁気ディスク・ドライブ、及びＣＤ−ＲＯＭ又は他の光学的媒体のような取り外し可能な光ディスクに対する読み書きを行なう光ディスク・ドライブを含み得る。これらのドライブ及び関連するコンピュータ可読の媒体は、コンピュータ実行可能な命令、データ構造、プログラム・モジュール、及びコンピュータの他のデータの不揮発性記憶を提供する。
【０１４１】
実施形態を参照して本発明を説明したが、当業者には、本発明の範囲から逸脱せずに様々な変形を施し、また均等構成を置換し得ることが理解されよう。加えて、本発明の範囲から逸脱せずに、特定の状況又は材料を本発明の教示に合わせて適応構成する多くの改変を施すことができる。従って、本発明は、開示された特定の実施形態に限定されず、特許請求の範囲に属する全ての実施形態を包含するものとする。
【符号の説明】
【０１４２】
１００：適応型の業務中心健康管理サービスを提供するワークフロー
１０５：来診
１１０：クエリ
１１２：刺激
１１４：患者コンテキスト
１１５：クエリ・ドライバ
１２０：データ・ソース
１２５：情報編成エンジン
１３０：バンドル
１３５：要約エンジン
１４０：改訂済みバンドル
１５０：利用者の反応／フィードバック
１６０：知識管理サブシステム
１４５：プレゼンテーション
１６１：ダッシュボード
１６３：オントロジー
１６５：手続き及びガイドライン
１６７：共通データ・モデル
１６９：解析部
２００：適応型ユーザ・インタフェイス
２０５：ログイン及び利用者識別エリア
２１０：患者識別エリア
２１２：警告
２１５：ウィジェット表示エリア
２２０：生命徴候／検査室ウィジェット
２２１：血圧
２２２：血圧指標の型
２２３：尿検査
２２４：血圧指標の値
２２５：体重
２２７：ブドウ糖
２２９：体温
２３０：臨床文書ウィジェット
２３１：文書型
２３２：文書作成者
２３３：文書日付
２３４：文書からの評価
２３５：文書状態
２３６：文書に対する行動
２４０：撮像検査ウィジェット
２４４：画像
２４６：撮像型
２４８：評価
２５０：問題ウィジェット
２５２、２５４：問題
２６０：来診理由ウィジェット
２６２：理由
２６４：アイコン
２７０：薬物ウィジェット
２７２：薬物の型
２７４：薬物の量
２７６：薬物の送達機構
２８０：カーソル
２８５：カーソルの位置
２９２：利用者別ダッシュボード
２９４：患者一覧
２９６：設定／プレファレンス・パネル
３１０：モバイル装置
３２０：グラフィック・ユーザ・インタフェイス
３３０：ナビゲーション装置
３４０：ツール
４００：ユーザ・インタフェイス
４０５：患者の識別
４１０：生命徴候
４１５：アイコン
４１７：尿検査結果
４２０：臨床詳細情報
４２５：陽性の結果
４２７：陰性の結果
４３０：放射線検査
４４０：心臓検査
４５０：文書
４５５：以前の経過メモ
４６０：来診理由
４７０：薬物ウィジェット
４８０：検索欄
５００：ユーザ・インタフェイス・アーキテクチャ
５０１：ユーザ・インタフェイス
５０２：ユーザ・インタフェイス変換エンジン
５０３：クエリ生成／展開エンジン
５０４：刺激
５０５：クエリ生成器
５０６：アクセス機構
５０７：データ・ソース
５０８：クエリ及び収集された文書
５０９：情報編成エンジン
５１０：データ主導型アプリケーション
５１１：エンタープライズ・アプリケーション・インタフェイス
５１２：作業／工程主導型アプリケーション
５１３：特定データ構造向けアプリケーション
５１４：多文書要約システム
５１５：節
５１６：概念
５１７：メタ文書
５１８：メタ文書要約
５１９：コネクタ
５２０：クライアント・フレームワーク
５２１：コンテキスト・マネージャ
５２２：プロダクト
５２３：患者検索
５２４：レジストリ・ナビゲータ
５２５：ビューア
５２６：クライアント・フレームワーク階層
５２７：クライアント・ウェブ・サーバ
５２８：アプリケーション階層
５２９：アプリケーション
５３０：統合階層
５３１：エンタープライズ・サービス・バス（「ＥＳＢ」）
５３２：レジストリ、データ及びサービス集合
５３３：構成情報
５３４：臨床コンテンツ・ゲートウェイ（「ＣＣＧ」）・インタフェイス・エンジン
５３５：相互運用性強化型プラットフォーム・サーバ
５３６：既製インタフェイス
５３７：特化型インタフェイス
５３８：電子メッセージ伝達インタフェイス（「ｅＭＰＩ」）
５３９：地域健康情報機関（「ＲＨＩＯ」）
５４０：サード・パーティのアプリケーション
５４１：事業体間文書共有（「ＸＤＳ」）リポジトリ
５４２：ＸＤＳレジストリ
５４３：顧客情報技術（「ＩＴ」）
５４５：連結性フレームワーク
５５０：クエリ結果の情報バンドル
５５０：文書のバンドル
６００：適応型ユーザ・インタフェイス・システム
６１０：アクティブ・リスナ・エージェント
６２０：ユーザ・インタフェイス
６３０：コンテンツ
６４０：入力
７００：臨床コンテンツとの適応型ユーザ・インタフェイス作用のための方法
８００：保持エリア
８０５：ＥＣＧ表現
８１０：脳ＭＲ画像又は画像系列
８１５：臨床詳細情報
８２０：宛先
８２５：付加的な情報又は詳細
９００：電子メール
９０５：患者情報
９１０：臨床詳細情報
９１５：ＭＲ画像
９２０：患者ＥＣＧデータ
１０００：臨床要素の選択、保持、及び送信を容易にするウィジェット・システム
１０１０：ユーザ・インタフェイス
１０２０：コンテンツ
１０３０：臨床要素送信ユニット
１０４０：受取者
１１００：臨床要素の選択、保持、及び送信を容易にする方法
１２１０：プロセッサ・システム
１２１２：プロセッサ
１２１４：相互接続バス
１２１８：チップセット
１２２０：メモリ制御器
１２２２：入出力（Ｉ／Ｏ）制御器
１２２４：システム・メモリ
１２２５：大容量記憶メモリ
１２２６、１２２８：周辺入出力（Ｉ／Ｏ）装置
１２３０：網インタフェイス
１２３２：Ｉ／Ｏバス
【図９Ｂ】
【特許請求の範囲】
【請求項１】
利用者へのグラフィック表示のために複数の臨床情報源から検索される臨床コンテンツを含んでおり、臨床アプリケーション及び患者データを含む前記表示されている臨床コンテンツとの利用者相互作用を容易にするユーザ・インタフェイスと、
該ユーザ・インタフェイスの一部として表示される保持エリアであって、前記利用者により選択されて当該保持エリアに投入された臨床コンテンツを保持する保持エリアと、
該保持エリアに投入された前記臨床コンテンツを受け取り、該臨床コンテンツをパッケージ化して、該臨床コンテンツを電子的データ・メッセージとして１又は複数の受取者へ送信する臨床要素送信ユニットと
を備えた臨床データ要素通信システム。
【請求項２】
ユーザ・インタフェイスと共に動作して利用者及びアプリケーションの活動を監視するアクティブ・リスナ・エージェントであって、臨床コンテンツを選択して、予め決められた規準及び観察された利用パターンの少なくとも一方に基づいて前記保持エリアを埋めることを自動的に行なうアクティブ・リスナ・エージェントをさらに含んでいる請求項１に記載のシステム。
【請求項３】
前記選択される臨床コンテンツは、基礎となる臨床データのグラフィック表現を含んでおり、前記臨床要素送信ユニットは、前記グラフィック表現に対応する前記基礎となる臨床データを含む前記電子的データ・メッセージを生成する、請求項１に記載のシステム。
【請求項４】
前記１又は複数の受取者は、臨床医の電子メール受取者、アプリケーション、及び電子的データ記憶部の少なくとも一つを含んでいる、請求項１に記載のシステム。
【請求項５】
前記臨床コンテンツは、患者生命徴候情報、画像データ、臨床報告、及び臨床指示の少なくとも一つを含んでいる、請求項１に記載のシステム。
【請求項６】
利用者が、前記臨床要素送信ユニットを介して前記選択される臨床コンテンツと共に送信するための電子メッセージを編成することを可能にするメッセージ・エリアをさらに含んでいる請求項１に記載のシステム。
【請求項７】
受取者が、前記電子的データ・メッセージから前記選択される臨床コンテンツを抽出することができる、請求項１に記載のシステム。
【請求項８】
複数の臨床情報源から検索されて利用者にグラフィック表示される臨床コンテンツを選択する利用者入力を受け入れるステップであって、前記表示される臨床コンテンツは臨床アプリケーション及び患者データを含んでいる、受け入れるステップと、
前記利用者により選択されて、前記ユーザ・インタフェイスの一部として表示される保持エリアに投入された臨床コンテンツを一時的に記憶するステップと、
前記保持エリアから前記一時的に記憶された臨床コンテンツを含む電子的データ・メッセージを生成するステップと、
前記電子的データ・メッセージを１又は複数の受取者へ送信するステップと
を備えた臨床データ要素通信の方法。
【請求項９】
前記電子的データ・メッセージを前記１又は複数の受取者の一つにおいて受け取って、該受取者に対して出力するために前記電子的データ・メッセージから前記臨床コンテンツを抽出するステップをさらに含んでいる請求項８に記載の方法。
【請求項１０】
臨床コンテンツを選択して、予め決められた規準及び観察された利用パターンの少なくとも一方に基づいて前記保持エリアを埋めることを自動的に行なうステップをさらに含んでいる請求項８に記載の方法。
【請求項１１】
前記選択される臨床コンテンツは、基礎となる臨床データのグラフィック表現を含んでおり、前記臨床要素送信ユニットは、前記グラフィック表現に対応する前記基礎となる臨床データを含む前記電子的データ・メッセージを生成する、請求項８に記載の方法。
【請求項１２】
前記１又は複数の受取者は、臨床医の電子メール受取者、アプリケーション、及び電子的データ記憶部の少なくとも一つを含んでいる、請求項８に記載のシステム。
【請求項１３】
前記臨床コンテンツは、患者生命徴候情報、画像データ、臨床報告、及び臨床指示の少なくとも一つを含んでいる、請求項８に記載の方法。
【請求項１４】
実行されるとデータ要素通信システムを具現化するコンピュータでの実行のための一組の命令を含むコンピュータ可読の媒体であって、前記システムは、
利用者へのグラフィック表示のために複数の情報源から検索される電子的データ要素を含んでおり、前記表示されている電子的データ要素との利用者相互作用を容易にするユーザ・インタフェイスと、
該ユーザ・インタフェイスの一部として表示される保持エリアであって、前記利用者により選択されて当該保持エリアに投入された１又は複数の電子的データ要素を保持する保持エリアと、
該保持エリアに投入された前記１又は複数の電子的データ要素を受け取り、該１又は複数の電子的データ要素をパッケージ化して、該１又は複数の電子的データ要素を電子的データ・メッセージとして１又は複数の受取者へ送信するデータ要素送信ユニットと
を含んでいる、コンピュータ可読の媒体。
【請求項１５】
ユーザ・インタフェイスと共に動作して利用者及びアプリケーションの活動を監視するアクティブ・リスナ・エージェントであって、１又は複数の電子的データ要素を選択して、予め決められた規準及び観察された利用パターンの少なくとも一方に基づいて前記保持エリアを埋めることを自動的に行なうアクティブ・リスナ・エージェントをさらに含んでいる請求項１４に記載のコンピュータ可読の媒体。
【請求項１６】
前記１又は複数の選択される電子的データ要素は、基礎となるデータのグラフィック表現を含んでおり、前記データ要素送信ユニットは、前記グラフィック表現に対応する前記基礎となるデータを含む前記電子的データ・メッセージを生成する、請求項１４に記載のコンピュータ可読の媒体。
【請求項１７】
前記１又は複数の受取者は、電子メール受取者、アプリケーション、及び電子的データ記憶部の少なくとも一つを含んでいる、請求項１４に記載のコンピュータ可読の媒体。
【請求項１８】
前記１又は複数の電子的データ要素は、患者生命徴候情報、画像データ、臨床報告、及び臨床指示の少なくとも一つを含んでいる、請求項１４に記載のコンピュータ可読の媒体。
【請求項１９】
利用者が、前記臨床要素送信ユニットを介して前記１又は複数の選択される電子的データ要素と共に送信するための電子的メッセージを編成することを可能にするメッセージ・エリアをさらに含んでいる請求項１４に記載のコンピュータ可読の媒体。
【請求項２０】
受取者が、前記電子的データ・メッセージから前記１又は複数の選択される電子的データ要素を抽出することができる、請求項１４に記載のコンピュータ可読の媒体。
【請求項１】
利用者へのグラフィック表示のために複数の臨床情報源から検索される臨床コンテンツを含んでおり、臨床アプリケーション及び患者データを含む前記表示されている臨床コンテンツとの利用者相互作用を容易にするユーザ・インタフェイスと、
該ユーザ・インタフェイスの一部として表示される保持エリアであって、前記利用者により選択されて当該保持エリアに投入された臨床コンテンツを保持する保持エリアと、
該保持エリアに投入された前記臨床コンテンツを受け取り、該臨床コンテンツをパッケージ化して、該臨床コンテンツを電子的データ・メッセージとして１又は複数の受取者へ送信する臨床要素送信ユニットと
を備えた臨床データ要素通信システム。
【請求項２】
ユーザ・インタフェイスと共に動作して利用者及びアプリケーションの活動を監視するアクティブ・リスナ・エージェントであって、臨床コンテンツを選択して、予め決められた規準及び観察された利用パターンの少なくとも一方に基づいて前記保持エリアを埋めることを自動的に行なうアクティブ・リスナ・エージェントをさらに含んでいる請求項１に記載のシステム。
【請求項３】
前記選択される臨床コンテンツは、基礎となる臨床データのグラフィック表現を含んでおり、前記臨床要素送信ユニットは、前記グラフィック表現に対応する前記基礎となる臨床データを含む前記電子的データ・メッセージを生成する、請求項１に記載のシステム。
【請求項４】
前記１又は複数の受取者は、臨床医の電子メール受取者、アプリケーション、及び電子的データ記憶部の少なくとも一つを含んでいる、請求項１に記載のシステム。
【請求項５】
前記臨床コンテンツは、患者生命徴候情報、画像データ、臨床報告、及び臨床指示の少なくとも一つを含んでいる、請求項１に記載のシステム。
【請求項６】
利用者が、前記臨床要素送信ユニットを介して前記選択される臨床コンテンツと共に送信するための電子メッセージを編成することを可能にするメッセージ・エリアをさらに含んでいる請求項１に記載のシステム。
【請求項７】
受取者が、前記電子的データ・メッセージから前記選択される臨床コンテンツを抽出することができる、請求項１に記載のシステム。
【請求項８】
複数の臨床情報源から検索されて利用者にグラフィック表示される臨床コンテンツを選択する利用者入力を受け入れるステップであって、前記表示される臨床コンテンツは臨床アプリケーション及び患者データを含んでいる、受け入れるステップと、
前記利用者により選択されて、前記ユーザ・インタフェイスの一部として表示される保持エリアに投入された臨床コンテンツを一時的に記憶するステップと、
前記保持エリアから前記一時的に記憶された臨床コンテンツを含む電子的データ・メッセージを生成するステップと、
前記電子的データ・メッセージを１又は複数の受取者へ送信するステップと
を備えた臨床データ要素通信の方法。
【請求項９】
前記電子的データ・メッセージを前記１又は複数の受取者の一つにおいて受け取って、該受取者に対して出力するために前記電子的データ・メッセージから前記臨床コンテンツを抽出するステップをさらに含んでいる請求項８に記載の方法。
【請求項１０】
臨床コンテンツを選択して、予め決められた規準及び観察された利用パターンの少なくとも一方に基づいて前記保持エリアを埋めることを自動的に行なうステップをさらに含んでいる請求項８に記載の方法。
【請求項１１】
前記選択される臨床コンテンツは、基礎となる臨床データのグラフィック表現を含んでおり、前記臨床要素送信ユニットは、前記グラフィック表現に対応する前記基礎となる臨床データを含む前記電子的データ・メッセージを生成する、請求項８に記載の方法。
【請求項１２】
前記１又は複数の受取者は、臨床医の電子メール受取者、アプリケーション、及び電子的データ記憶部の少なくとも一つを含んでいる、請求項８に記載のシステム。
【請求項１３】
前記臨床コンテンツは、患者生命徴候情報、画像データ、臨床報告、及び臨床指示の少なくとも一つを含んでいる、請求項８に記載の方法。
【請求項１４】
実行されるとデータ要素通信システムを具現化するコンピュータでの実行のための一組の命令を含むコンピュータ可読の媒体であって、前記システムは、
利用者へのグラフィック表示のために複数の情報源から検索される電子的データ要素を含んでおり、前記表示されている電子的データ要素との利用者相互作用を容易にするユーザ・インタフェイスと、
該ユーザ・インタフェイスの一部として表示される保持エリアであって、前記利用者により選択されて当該保持エリアに投入された１又は複数の電子的データ要素を保持する保持エリアと、
該保持エリアに投入された前記１又は複数の電子的データ要素を受け取り、該１又は複数の電子的データ要素をパッケージ化して、該１又は複数の電子的データ要素を電子的データ・メッセージとして１又は複数の受取者へ送信するデータ要素送信ユニットと
を含んでいる、コンピュータ可読の媒体。
【請求項１５】
ユーザ・インタフェイスと共に動作して利用者及びアプリケーションの活動を監視するアクティブ・リスナ・エージェントであって、１又は複数の電子的データ要素を選択して、予め決められた規準及び観察された利用パターンの少なくとも一方に基づいて前記保持エリアを埋めることを自動的に行なうアクティブ・リスナ・エージェントをさらに含んでいる請求項１４に記載のコンピュータ可読の媒体。
【請求項１６】
前記１又は複数の選択される電子的データ要素は、基礎となるデータのグラフィック表現を含んでおり、前記データ要素送信ユニットは、前記グラフィック表現に対応する前記基礎となるデータを含む前記電子的データ・メッセージを生成する、請求項１４に記載のコンピュータ可読の媒体。
【請求項１７】
前記１又は複数の受取者は、電子メール受取者、アプリケーション、及び電子的データ記憶部の少なくとも一つを含んでいる、請求項１４に記載のコンピュータ可読の媒体。
【請求項１８】
前記１又は複数の電子的データ要素は、患者生命徴候情報、画像データ、臨床報告、及び臨床指示の少なくとも一つを含んでいる、請求項１４に記載のコンピュータ可読の媒体。
【請求項１９】
利用者が、前記臨床要素送信ユニットを介して前記１又は複数の選択される電子的データ要素と共に送信するための電子的メッセージを編成することを可能にするメッセージ・エリアをさらに含んでいる請求項１４に記載のコンピュータ可読の媒体。
【請求項２０】
受取者が、前記電子的データ・メッセージから前記１又は複数の選択される電子的データ要素を抽出することができる、請求項１４に記載のコンピュータ可読の媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２０１２−５１０６７０（Ｐ２０１２−５１０６７０Ａ）
【公表日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願番号】特願２０１１−５３８６４０（Ｐ２０１１−５３８６４０）
【出願日】平成２１年１１月２０日（２００９．１１．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０６５２６２
【国際公開番号】ＷＯ２０１０／０６２８３０
【国際公開日】平成２２年６月３日（２０１０．６．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
【出願人】（３９００４１５４２）ゼネラル・エレクトリック・カンパニイ (6,332)
【Ｆターム（参考）】
【公表日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願日】平成２１年１１月２０日（２００９．１１．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０６５２６２
【国際公開番号】ＷＯ２０１０／０６２８３０
【国際公開日】平成２２年６月３日（２０１０．６．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
【出願人】（３９００４１５４２）ゼネラル・エレクトリック・カンパニイ (6,332)
【Ｆターム（参考）】
[ Back to top ]