(57)【要約】【解決手段】ワークフローをエミュレートするヘルスケアワーカーのためのルールベースの動的コンピュータユーザインタフェースを提供するシステム及び方法を示す。このシステムと方法は、ヘルスケア機関によるユーザインタフェースのカスタマイズを容易にする。ａ）コード開発用の領域（即ち、ビルド）、ｂ）業界で最良のものとして行われているビジネスルールとワークフローを提示する領域（即ち、デフォルト／モデル）、及びｃ）カスタマ固有の適応が存在する領域（即ち、クライアント／エンタープライズ）の内の少なくとも１つを提供するソフトウェアモデルが提供される。ヘルスケア組織によって使用される全ての可能なプロセスを示すビジネスプロセスが、ソフトウェアモデル内に提供される。次に、定義されたビジネスプロセスをシナリオ及び／又はコンテキストによって適応させ、各ユーザに提示される情報とユーザインタフェース画面のフローを実時間で変更する機能が提供される。全ての機能に亘って一貫したルックアンドフィールを有するユーザインタフェースが提供される。【選択図】図３
2005507124.tif 000002
【特許請求の範囲】
【請求項１】
特定のビジネスプロセスを支援するユーザインタフェース表示画像を動的に生成するシステムであって、
ビジネスプロセスに含まれる一連のタスク及びユーザインタフェース表示のための関連するテンプレートフォームを識別する情報ソースと、
前記一連のタスクの内の特定のタスクと、前記特定のタスクと関連付けられたテンプレートフォームとを識別する追跡プロセッサと、
フォーム要件の識別を支援するユーザコンテキスト情報に応じて、前記識別したフォームを適応させるように前記識別したフォームを表すデータを修正する適応プロセッサと、
前記適応されたフォームを表すデータを処理して出力通信に適合したものにする出力プロセッサとを含むシステム。
【請求項２】
前記ユーザコンテキスト情報が、（ａ）ユーザログオン識別情報、（ｂ）表示されたコンテキスト識別項目リスト内の項目のユーザによる選択、及び（ｃ）実行可能アプリケーションを介してのユーザによる事前ナビゲーションパスの内の少なくとも１つから得られる、請求項１に記載のシステム。
【請求項３】
前記ユーザコンテキスト情報が、（ａ）前記ユーザと関連した組織、（ｂ）前記ユーザと関連した組織の部門、（ｃ）患者とヘルスケアエンタープライズとの対話のタイプを含むエンカウンタタイプ、（ｄ）規制環境、（ｅ）カスタマ識別情報、及び（ｆ）コンピュータシステムの内の少なくとも１つを識別する情報を含む、請求項１に記載のシステム。
【請求項４】
前記フォーム適応プロセッサが、前記識別したフォームを表す前記データを修正して、（ａ）前記識別したフォーム内の表示要素を非アクティブ化し、（ｂ）前記識別したフォーム内の表示要素を隠し、（ｃ）前記識別したフォーム内のユーザが選択可能なプロンプト表示要素を追加するうちの少なくとも１つを行う、請求項１に記載のシステム。
【請求項５】
前記適応プロセッサが、また、前記ユーザコンテキスト情報に応じて、前記テンプレートフォームから修正する前記フォームを選択し、
前記選択したフォームが前記特定のタスクを実行する際に使用される、請求項１に記載のシステム。
【請求項６】
前記追跡プロセッサが、前記ビジネスプロセスの進行を監視すると共に前記ビジネスプロセスで実行される現在のタスクと関連したフォームを識別するソフトウェア手順を含み、
前記手順が、対応するタスクと個々に関連付けられた状態機械の状態を割り振ることによって前記ビジネスプロセスの進行を追跡する、請求項１に記載のシステム。
【請求項７】
前記情報ソースが、対応する複数のビジネスプロセスに含まれる複数のタスクシーケンス及びユーザインタフェース表示のための関連したテンプレートフォームを識別し、（ａ）前記ユーザコンテキスト情報、 （ｂ）所定のビジネスプロセス選択情報、及び（ｃ）所定のテンプレートフォーム選択情報の内の少なくとも１つに応じて、前記ビジネスプロセスに含まれる前記タスクシーケンス及び前記関連したテンプレートフォームを識別する、請求項１に記載のシステム。
【請求項８】
前記情報ソースが、ヘルスケア関連ビジネスプロセスに含まれる一連のタスクと、（ａ）患者病院チェックインフォーム、（ｂ）患者チェックアウトフォーム、（ｃ）患者からの支払の回収を支援するフォーム、（ｄ）患者の請求明細フォーム、（ｅ）患者の治療指示と関連したフォーム、 （ｆ）患者の試験結果と関連したフォーム、（ｇ）ヘルスケアワーカーによって実行される患者の治療と関連したタスクのスケジューリングと関連したフォーム、及び（ｈ）患者についての保証人支払い責任と関連したフォームの内の少なくとも１つを含む関連したテンプレートフォームとを識別する、請求項１に記載のシステム。
【請求項９】
ユーザインタフェース表示のための前記関連したテンプレートフォームが、（ａ）補助情報用の共通ヘッダ領域、（ｂ）共通制御バー領域、及び（ｃ）共通ステータスバー領域の内の少なくとも１つを備えた共通情報表示ウィンドウを含む共通ルックアンドフィール表示特性を有する、請求項１に記載のシステム。
【請求項１０】
特定のビジネスプロセスを支援するユーザインタフェース表示画像を動的に生成するシステムであって、
ビジネスプロセスに含まれる一連のタスク及びユーザインタフェース表示のための関連したテンプレートフォームを識別する情報ソースと、
タスク監視プロセッサであって、
前記一連のタスクを通して進行をモニタすると共に、所定のルールに応じて、（ａ）次に実行するタスクを決定する、（ｂ）省略するタスクを決定する、及び（ｃ）現在のタスクから次のタスクへの移行を開始する動作の内の少なくとも１つを行うと共に、
次のタスクと関連したテンプレートフォームを識別するタスク監視プロセッサと、
出力通信のために前記識別したテンプレートフォームを表すデータを処理する出力プロセッサとを含むシステム。
【請求項１１】
前記所定のルールが、タスクの選択及び実行の順序付けを指示するための実行可能な記憶された指示を含む、請求項１０に記載のシステム。
【請求項１２】
前記記憶された命令は、（ａ）表示されたフォームを介して受け取った入力データ、（ｂ）特定のユーザと関連付けられ、前記記憶された命令の動作に影響を及ぼす所定のセティングの内の少なくとも１つに応じて、タスクの実行の選択及び順序付けを指示する、請求項１０に記載のシステム。
【請求項１３】
前記出力プロセッサが、フォーム要件の識別を支援するユーザコンテキスト情報に応じて、前記識別したテンプレートフォームを適応させるように前記識別したテンプレートフォームを表すデータを修正する、請求項１０に記載のシステム。
【請求項１４】
特定のビジネスプロセスを支援するユーザインタフェース表示画像を動的に生成するシステムであって、
ユーザインタフェース表示フォームのソースと、
実行可能な記憶された命令と、前記記憶された命令の動作に影響を与えるための特定のユーザと関連付けられた所定のパラメータであって、前記ユーザインタフェースの動作を特定のユーザの要求に合わせるために選択された所定のパラメータとに応じて、（ａ）ユーザに提示される一連のユーザインタフェース表示フォーム、及び（ｂ）ユーザに提示されるユーザインタフェース表示フォームの内容の内の少なくとも１つを適応させるユーザインタフェースプロセッサと、
出力通信のために前記識別したテンプレートフォームを表すデータを処理する出力プロセッサとを含むシステム。
【請求項１５】
ビジネスプロセスの段階が前記ユーザインタフェース表示フォームと関連付けられており、
前記ユーザインタフェースプロセッサが、前記記憶した命令及び所定のパラメータに応じて前記ビジネスプロセスを適合させる、請求項１４に記載のシステム。
【請求項１６】
前記ユーザインタフェースプロセッサが、（ａ）次に実行される段階を決定すること、（ｂ）省略する段階を決定すること、及び（ｃ）現在の段階から次の段階への移行を開始することの内の少なくとも１つを行うことによって、前記記憶された命令と所定のパラメータに応じて前記ビジネスプロセスを適応させ、
前記所定のパラメータが、（ａ）特定のフォーム表示要素のにおいて特定のユーザに許容された項目値、及び（ｂ）特定のユーザのための特定のフォームで表示された要素を制限する制約との内の少なくとも１つを含む、請求項１４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ユーザインタフェース生成のためのシステム及び方法に関する。より詳細には、本発明は、ヘルスケアプロバイダのためのコンピュータユーザインタフェースの構築に対するソリューションを提供するもので、様々なヘルスケア利害関係者（healthcare stakeholder）の複雑なルールを組み込んで実施し、また、ヘルスケア機関によるカスタマイズを容易にするものである。
【背景技術】
【０００２】
本出願は、２００２年１０月２３日にダグラス・コール（Douglas Cole）らの名前で出願された米国仮特許出願第６０／３４７，９０３号の利益を請求する。
【０００３】
従来のシステムは、「ユーザインタフェースビルダ」（例えば、画面ビルダ、ＧＵＩ（グラフィカルユーザインタフェース）ビルダ、フォームビルダなど）を場合によっては広い範囲に亘って構築することによってユーザインタフェース（ＵＩ）生成の課題を解決しようとしてきた。このシステムによって、ヘルスケア機関は、時には走り書きから、その機関のカスタマイズと外部利害関係者のルールを組み込んだカスタマイズしたユーザインタフェースを構築することができる。ヘルスケア組織のＩＳ（情報システム）のスタッフは、これらのユーザインタフェースビルダを使用して、各ユーザグループ及び／又はビジネスコンテキストごとのカスタマイズしたユーザインタフェースを構築する。
【０００４】
従来のシステムの主な欠点は、カスタマイゼーションとルールをそれぞれ異なるユーザインタフェースに別々に組み込まなければならないことである。同じビジネスルール又はカスタマイゼーションを複数のユーザインタフェース又はビューに組み込まなければならないとき（これはきわめて一般的である）、従来のシステムは、一般に、それぞれ固有のユーザインタフェースに変更を符号化しなければならない。
【０００５】
そのようなタイプのソリューションでは、ヘルスケア機関又は利害関係者のビジネスルールのニーズが変化したときは、広範囲にわたる「１つずつ」の再カスタマイゼーションが必要になる。従って、大規模な統合されたヘルスケアネットワークは、そのように常に変化する要求に対応するために多数のＩＳスタッフを必要とする。要求の変化が速いために、通常、ＩＳスタッフはヘルスケア機関のニーズについていくことができない。
【０００６】
適応がタイムリーに行われないと、利害関係者のルールが遵守されないために、例えば、請求できない売上、返済の減少、保険及び管理されたケア組織からの支払いの遅延によって生じる未収金の増加が生じる。
【発明の概要】
【０００７】
本発明者は、以上のような従来システムの欠点に取り組む必要性を認識している。本発明は、ヘルスケア環境における患者アクセス及び売上サイクル管理のための複雑で重複したルールを調和させる機構を提供する。本発明は、ヘルスケア環境の要件に対処するように設計されているが、同様に、複雑なルール及びプロセスが様々な業界利害関係者によって決定される他の業界にも適用可能である。
【０００８】
詳細には、本発明者は、患者アクセス及び売上サイクル管理ユーザのためのユーザインタフェースは、例えば以下の基準を満たすように設計されていることが望ましいと認識している。
・ユーザがタスクを遂行するのに必要な教育と訓練を最小にするようにユーザフレンドリでかつ直感的であること。
・固有の要件に対応し、またヘルスケア機関が、絶えず変化している環境に対処するようにユーザインタフェースを迅速に適応させることができるように、大きなプログラミング資源なしにヘルスケア機関がカスタマイズできること。
・患者アクセス及び収益サイクル管理において、ヘルスケア機関自体だけでなく他の利害関係者によって確立されたビジネスルール及びプロセスを実施すること。そのような他の利害関係者の例には、ａ）州、連邦、及び他の政府規制機関、ｂ）保険会社、ｃ）高齢者・障害者医療保険制度（Medicare）や低所得者医療扶助制度（Medicaid）、 軍属健康医療計画（Champus）などの州及び連邦医療計画、ｄ）ヘルスプロフェショナル「最良プラクティス」ガイドライン、及びｅ）管理されたケア組織の請求、照会、及び返済ルールを含むがこれらに限定されない。
【０００９】
従って、本発明の１つの利点は、アプリケーション提供者がプリロードできるようにすると共に、ヘルスケアカスタマが各利害関係者によって指定されたルールを個々に定義できるようにし、またヘルスケア機関によって要求される個々のカスタマイズを提供できるようにすることである。これらのルールは、各害関係者ごとに個別に定義される。次に、本発明は、ヘルスケア機関が、ルールを実施又は確認すべき様々なコンテキストを定義することを可能にする。そのようなコンテキストを使用することによって、本発明は、静的ＵＩ生成と動的ＵＩ生成の組合せを使用して、各コンテキストごとに、各プロセスの利害関係者によって指定されたルールを組み入れたユーザインタフェースを構築する。
【００１０】
従って、ルールが修正されたとき、ユーザインタフェース内に動的に生成されたものがすぐに有効になり、静的生成を必要とするものは、ボタンが押された時に単純に再び生成される。そのような機能は、そのような処理ルールに対する最新の更新又は変更を生産システムに迅速に組み込む際にヘルスケア機関に膨大な利益を提供する。即ち、本システムは、各利害関係者のためにルールの定義及びヘルスケアのカスタマイズを行う。本システムは、また、ヘルスケア機関によるルール実施を定義し、動的なルール実行を可能にする。
【００１１】
本発明は、ヘルスケアプロバイダ又はヘルスケア分野に使用可能であるものに限定されず、様々な利害関係者によって決定される複雑なルール及びプロセスを必要とする他の業界に適用可能である。これは、関連する組織（例えば、ヘルスケア機関）自体だけでなく、クライアントアクセス及び収益サイクル管理において他の利害関係者によっても確立されるビジネスルール及びプロセスに基づいてユーザインタフェースを動的に生成することができるシステムである。これは、幅広いプログラミングの経験がなくても、ユーザがインタフェースをカスタマイズできるようにする。また、ユーザインタフェースが、各プロセスの利害関係者によって指定されたルールを適応的に組み入れるため、処理ルールに対する最新の更新又は変更がユーザに提示される。この動的ユーザインタフェースは、ワークフローの効率を最大にし、各エンティティによって定義されたようにヘルスシステムルールを実施する。
【００１２】
従って、本発明の原理による１つの例示的な実施形態は、ワークフローをエミュレートするヘルスケアワーカー用のコンピュータユーザインタフェースを構築し、同時にプログラミングなしにヘルスケアプロバイダによるカスタマイズを容易にする方法である。この方法は、例えば、ビルド（Build）、デフォルト／モデル、及びクライアント／エンタープライズの３層を識別するコンテキスト適応性モデルを確立する。この方法は、これらの３層に、ａ）コード開発領域、ｂ）産業界で最良のものとして実施されているビジネスルール及びフローを表す領域、及びｃ）顧客固有の適応が存在する領域の３つの層で実現する。更に、この方法は、ヘルスケア組織によって使用される可能性のある全てのビジネスプロセスを示すコンテキスト適応性モデルでのビジネスプロセスを定義する。この方法は、以下のタイプの内の１つ又は複数を含むルールシステム要素を使用してビジネスプロセスを適応させる機能を提供する。
・制約（Constraints）
・プロファイルプロパティ
・プロセス移行
・プロセス状態
・ビジネスプロセスオブジェクトのテンプレート
・アクション
・許容値リスト
【００１３】
もう１つの例示的な実施形態では、特定のビジネスプロセスを支援するユーザインタフェース表示画像を動的に生成するシステムを示す。このシステムは、ビジネスプロセスに含まれる一連のタスク及びユーザインタフェース表示のための関連したテンプレートフォームを識別する情報ソースを含む。このシステムは、また、一連のタスクの内の特定のタスクと、特定のタスクと関連したテンプレートフォームとを識別する追跡プロセッサを含む。更に、適応プロセッサは、フォーム要件の識別を支援するユーザコンテキスト情報に応じて、識別したフォームを表すデータを修正して、識別したフォームを適応させる。システムは、更に、適応されたフォームを表すデータを出力通信に適するように処理する出力プロセッサを含む。
【発明を実施するための最良の形態】
【００１４】
本発明は、アプリケーション提供者がプリロードできるようにすると共に、そのヘルスケアカスタマが、それぞれの利害関係者によって指定されるルール並びにヘルスケア機関によって必要とされる個々のカスタマイゼーションを定義できるようにする。本明細書で使用されるルールは、職員によるタスクの選択及び実行の順序付けに影響を及ぼす実行可能な記憶された命令を含む。また、本明細書で使用されるルールは、形式とデータ若しくは形式とデータの関係を使用することによってアクションを提示し、実行し又は調整する方法の規定されたガイド、ルール又はモデルを含むことができる。また、本明細書に使用されるルールは、ヘルスケア要求要素が、ヘルスプラン返済条件、ヘルスプランフォーム要件、返済式、返済制約及び返済計算手法を含む所定の要件に適合していることを判定する手続きを含むことができる。本発明は、ヘルスケア機関が、ルールを実施又は確認しなければならない様々なコンテキストを定義することを可能にする。このモデルは、ビジネスプロセスコンテキスト適応性モデルと呼ばれることがある。本発明は、コンテキストモデルに基づいて、静的ＵＩ生成と動的ＵＩ生成の組み合わせを使用して、各プロセスの利害関係者によって指定されたルールを含む各コンテキストごとのユーザインタフェースを構築する。
【００１５】
ルールが修正されると、ユーザインタフェース内に動的に生成されたルールが即座に有効になり、静的生成を必要とするルールは、単にボタンを押した時に再生成される。この機能は、処理ルールに対する最新の更新又は変更を生産システムに迅速に組み込むことによってヘルスケア機関に大きな利益を提供する。
【００１６】
カスタマが新しいバージョンのソフトウェアを導入したときに、カスタマに対する適応を維持することができる。カスタマに対する適応は、新しいモデルのソフトウェア配信による影響を受けない物理的に別のファイルに維持される。
【００１７】
ユーザに提示される情報は、利害関係者又はシナリオによって変化することがあるが、本発明の原理によるユーザインタフェースのルックアンドフィール（look and feel）は同じままである。図１に、例示的なユーザインタフェースのフレーム又はウィンドウの一般的な構成要素を示す。特定の内容が各カスタマの要求又は内容によって異なる場合でも、本発明によるフレームは表現の一貫性を保証する。図２は、図１に示した汎用ユーザインタフェースの特定の内容の１つの例を示す。
【００１８】
図１に示したように、一般的かつ代表的なユーザインタフェースフレーム１０は、画面１０の上部にあるフレームヘッダ領域１を含む。この領域１には、幾つかの一般的なコントロールがあり、閲覧及び選択のためにそれらのコントロールをいつでも利用できるようにしている。図２は、以下のようなものを含む共通コントロールの幾つかの特定の例を示す。
１）現在ログオンしているユーザを示す識別アイコン２０１と、図２のアイコン２０２「シーメンス・メディカル・ホスピタル」として示したような、重要な識別の一部分である任意のロケーションコンテキスト情報。
２）ロゴアイコン２０３。
３）言語選択アイコン２０４、「情報」２０６、「注記」２０８、「ログオフ」２１０などの様々なアイコンで表された共通機能を備えたボタンバー。
【００１９】
また、図１は、例示的なフレーム１０が、フレーム１０の左側にタスクナビゲーション領域２を含むことを示している。タスクナビゲーション領域２には、様々なタスクタブ１１〜１３があり、例えばマウスなどのユーザインタフェース選択装置によってこれらのタブを選択することにより、ユーザは様々なオープンタスクを切り換えることができる。
【００２０】
図２のＵＩフレーム２０に、タスクタブの特定の例を示す。第１のタブ２３２は、ホームページへの常設リンクであり、図示の実施形態では、これは閉じることができない。タスクナビゲーション領域内の他のタブは、ユーザによって開始される任意のタスクを表し、アプリケーションの組み合せからのものでよい。ホームタブ２３２の下に、タブが開かれた順序で表示されており、アクティブなタブ（白い背景）と非アクティブなタブ（暗い背景）の視覚的違いがある。例えば、図２のアクティブなタブ２３４は、患者Ｓａｎｄｒａ  Ｐｅｒｅｚの「チェックイン」アプリケーションであり、次の非アクティブなタブ２３６は、Ｂａｂｙ  Ｐｅｒｅｚの「チェックアウト」アプリケーションを表す。
【００２１】
図１に示したように、情報領域３が例示的なフレーム１０に組み込まれるであろう。情報領域は、例えば、フレームの左側下部にある。この小さな窓３は、矢印選択アイコン５によって、最小にされるか、画面の途中まで開くか又は完全に開く（タスクタブ領域２を覆う）ように設定することができる。情報領域３は、ヘルプ情報をユーザに提示するもので、このヘルプ情報はコンテクストに応じて、ユーザが異なるアプリケーションに移動すると変化する。また、この領域は、図２に、表示画面２０の要素２０４として示されている。
【００２２】
更に、図１の例示的なフレーム１０は、ワークエリア４も含む。ワークエリア４は、フレーム１０のウェル領域全体を含むが、次のように更に細分割される。
【００２３】
１）ウェルページヘッダ４ａ−この領域は、図１に示したように、患者や他のコンテキスト情報を表す。この領域の具体的な例は、図２の領域２３０に示されており、領域２３０は、例えば、患者名２３１、患者生年月日２３７、患者社会保障番号２３８などの患者情報を含む。
【００２４】
２）ウェルページ領域４ｂ−この領域は、図１に示したように、ユーザが使用しているアプリケーションと関連した機能ページを表す。この領域の具体的な例を図２の領域２４０に示す。図２において、この領域２４０は、例えば、注意メッセージエントリ２４２、患者情報エントリ２４４、エンカウンタ情報エントリ２４６、保険情報２４８、保証人（guarantor）情報２４９などのアプリケーション機能を含む。
【００２５】
３）コントロールバー領域４ｃ−これは、図１に示したように、ＵＩ画面１０の下部にある、ワークフローナビゲーションを制御するための領域である。この領域の具体的な例を、図２の領域２５０に示す。図２において、この領域２５０は、サマリアイコン２５２や患者人口統計アイコン２５４などのユーザが選択できるワークフローナビゲーションボタンを含む。
【００２６】
４）ステータスバー４ｄ−これは、図１の画面１０の下部にあるメッセージ領域である。この領域の具体的な例を、図２の領域２６０に示す。図２において、この領域２６０は、例えば、ログインページ２６２と関連したメッセージ、次世代システム更新２６４と関連したメッセージなど、システムと関連した様々な選択可能でかつ適用可能な電子状況メッセージを含む。
【００２７】
図３は、本発明の原理による特定のビジネスプロセスを支援するユーザインタフェース表示画像を動的に生成する本発明の１つの例示的な実施形態を流れ図の形で示す。システム３１は、コンテキスト層、即ち１）ビルド領域３２、２）デフォルト／モデル領域３３、及び３）クライアント／エンタープライズ領域３４を含む（後で詳しく説明する）。これらのコンテキスト層は、図３のブロック３５に示したように、ビジネスプロセスに含まれる一連のタスク及びそれと関連したユーザインタフェース表示用のテンプレートフォームを識別し制御する情報を提供する。
【００２８】
システムは、更に、一連のタスクの内の特定のタスク及び特定のタスクと関連したテンプレートフォームを識別する追跡プロセッサ又はプロセス３６を含む。追跡プロセッサ／プロセス３６は、ビジネスプロセスの進行を監視し、ビジネスプロセスで実行されている現在のタスクと関連したフォームを識別する手順を含む。
【００２９】
また、システムは、フォーム要件の識別を支援するユーザコンテキスト情報３８に応じて識別フォームを適応させるように識別フォームを表すデータを修正する適応プロセッサ又はプロセス３７を含む。フォーム適応プロセッサ３７は、識別フォームを表すデータを修正して、（ａ）識別フォームの表示要素を非アクティブ化する、（ｂ）識別フォームの表示要素を隠す、（ｃ）識別フォームのユーザ選択可能なプロンプト表示要素を追加する動作の内の少なくとも１つを行う。
【００３０】
ユーザコンテキスト情報は、例えば、（ａ）ユーザログオン識別情報、（ｂ）表示されたコンテキスト識別項目リスト内の項目のユーザによる選択、及び（ｃ）実行可能アプリケーションを介してのユーザ事前ナビゲーションパスの内の少なくとも１つから得られる。更に、ユーザコンテキスト情報は、（ａ）ユーザと関連した組織、（ｂ）ユーザと関連した組織の部門、（ｃ）ヘルスケアエンタープライズと患者の対話のタイプを含むエンカウンタタイプ、（ｄ）規制環境、（ｅ）カスタマ識別情報、及び（ｆ）コンピュータシステムの内の少なくとも１つを識別する情報を含む。
【００３１】
次に、出力プロセッサ又はプロセス３９を使用して、適応されたフォームを表すデータを処理し、出力通信に適したものにする。例えば、図３に示したように、様々な適応されたユーザインタフェース３１０を生成する。
【００３２】
図４は、本発明の別の例示的な実施形態を示す。図４は、ワークフローをエミュレートするヘルスケアワーカー用のルールベースの動的コンピュータユーザインタフェースを構築する方法を流れ図の形で示す。この方法は、ヘルスケア機関によるカスタマイズを容易にする。ステップ４３で、本発明は、ａ）コードの開発領域（即ち、ビルド）、ｂ）業界で最善のものとして行われているビジネスルールとワークフローを表す領域（即ち、デフォルト／モデル）、及びｃ）カスタマ固有の適合が存在する領域（即ち、クライアント／エンタープライズ）の内の少なくとも１つを提供するソフトウェアモデルを確立する。また、ステップ４４で、本発明は、ソフトウェアモデル内に、ヘルスケア組織によって使用される可能性のある全てのプロセスを記述するビジネスプロセスを定義する。次に、ステップ４５で、定義されたビジネスプロセスをシナリオ及び／又はコンテキストによって適応させ、各ユーザに提示される情報及びユーザインタフェース画面のフローを実時間で変化させる機能が提供される。更に、ステップ４６で、提供されたユーザインタフェース画面は、全ての機能で一貫したルックアンドフィールを有する。
【００３３】
コンテキスト層
本発明の原理によれば、コンテキスト適応性フレームワークは、このユーザインタフェースの機能を高める。本発明の原理に従ってコンテキスト層を見る単純な方法は、コンテキスト層がビジネスルール、パラメータ及びビジネスプロセス適応化のグループ化を表すことである。ビジネスオブジェクト又はビジネスプロセスインスタンスは、特定のコンテキスト内で働き、コンテキスト階層の上方にルールを継承することができる。例えば、レジストレーションプロセスは、特定の組織のために動作し、従って、適用されるルールは、その組織又はコンテキストのために定義されるものになる。同時に、そのプロセスと対話するビジネスオブジェクトは、他のコンテキスト内で動作しているであろう。例えば、レジストレーションプロセスが、支払者オブジェクトインスタンスを使用する場合は、プロセスは、自分自身の特定のルールセットを有する「ＰＡブルークロス」のコンテキスト内で動作する。
【００３４】
本システムの物理階層は、論理的に、１）ビルド、２）デフォルト／モデル、及び３）クライアント／エンタープライズの３つのコンテキスト層に分割される。
【００３５】
ビルド領域は、本発明のソフトウェア提供者によって構築されると共に全てのカスタマに送られる基本項目を含む。デフォルト／モデル領域は、ＯＰ（手術）入院、医師オフィス、緊急処置室のような特定のビジネスプロセスのための、業界で最良のものとして行われているビジネスルール及びフローを表すモデルを含む。様々な分析家／専門家を使用してそのような最良実施例のモデルを開発することができる。最後に、クライアント／エンタープライズ領域は、カスタマイズ要件を支援するカスタマ固有のビジネスプロセス及びルールを含む。
【００３６】
ビルド
図５に、ビルド領域の例を示す。図５に示したように、定義されたコンテキスト層は、ヘルスケア組織によって使用される可能性がある全てのビジネスプロセスを示すビジネスプロセスオブジェクトテンプレートを含む。これらは、例えばブロック５０２に示したような許容値リストと、例えば図５のブロック５０４に示したような関係するビジネスオブジェクトに関する制約を含む。これらのビジネスプロセスオブジェクトテンプレートは、図５の例えばブロック５０２のSmsDefTNTAllowableValues.xmlや、ブロック５０４のSmsDefTNTClassconstraints.xmlなどの関連ファイルに入れられる。このビルド層における定義は、クライアントによって修正されることはなく、ソフトウェア提供者だけによって修正される。
【００３７】
デフォルト／モデル（システム）
システムコンテキスト層は、ソフトウェア開発者が定義したコンテキスト層（即ち、ビルド）の下にあり、モデル又はデフォルトシステムコンポーネントが定義される場所である。最初は、この層には１つのモデルシステムコンテキストだけしかないであろう。最終的には、必要に応じて、システムが実施されるそれぞれの国ごとに、若しくはマルチエンティティや長期ケアなどの様々な種類のヘルスケア施設のために、様々なモデルコンテキストが定義される。このフレームワークは、ルールとパラメータを階層の下方に継承する能力を提供する。このように、ＨＰＯ（Health Provider Organization）などのヘルスケアサービス組織は、属している全ての組織に当てはまるルールを定義することができる。また、ルールについてのモデルセッティングをユーザインタフェースにおいて適用できる。デフォルト／モデル（システム）コンテキストレベルには様々なスタータセットが設けられており、クライアントがクライアントコンテキスト層にどれをコピーするかを自由に選択できる。
【００３８】
システムコンテキストレベルでの変更は、システム全体に有効であるが、カスタマは、システムコンテキスト層より下方の異なるクライアント／エンタープライズコンテキスト層において阻止される修正を決定することができる。システムコンテキスト層は、特定タイプのエンタープライズの最良のプラクティスに基づいて複数のモデルをサポートするステージを設定し、プログラミングの変更なしに組織のニーズを満たすようにユーザインタフェース表示を変更する能力を保証する。
【００３９】
図６は、システムコンテキストレベルにおけるスタータセットの例を示す。スタータセット又はテンプレートは、例えばＩＰ入院６０２、医師オフィス６０４、ＯＰ入院６０６、ＥＲ６０８など、図６の影付きのボックスによって示されている。
【００４０】
クライアント/エンタープライズ
クライアント／エンタープライズコンテキスト層は、システムコンテキスト層の下の次階層／下側階層にある。クライアント／エンタープライズコンテキスト層（例えば、図６ののＡＢＣヘルス６１０や他の影付きでないボックスで示された）は、ヘルスシステム全体に共通に適用可能な値リストやルール、制約などのカスタマ指定の適応を含む。これらは、図６に示したように、ＡＢＣヘルス組織６１０の下に、例えばＭｅｒｃｙ診療所ロケーション６１２や連邦医師ロケーション６１４などの様々なテンプレートを含むことができる。
【００４１】
これらのロケーションの各々は、更に、図６に示したＥＲ６１６、ＯＰ診療所６１８、医師オフィス１  ６１９などの他のモデル又はルールを含むことがある。
【００４２】
ルール／ルールシステム要素
コンテキスト適応性フレームワークが定義され、ビジネスプロセスが確立された後で、本発明によるＵＩの固有の機能を働かせるルールシステム要素（ＲＳＥ）又はルールが定義される。これらのルールは、画面シーケンス及び情報の表示を行わせることができる。ルールは、妥当性検査と制約を定義し、あるビジネスプロセスから別のビジネスプロセスへの移行を管理するために使用される。様々な結果に影響を及ぼすようにルールを変更できるフレキシビリティは、異なるヘルスプロバイダの様々な要求に対応する。
【００４３】
コンテキスト層は、ＲＳＥをグループ化する。ビジネスプロセスコンテキスト適応性を有効にするために、識別されたコンテキスト層にあるビジネスルールやビジネスプロセスなどだけが使用される。本発明によるシステムは、マスタファイル内の情報を使用して、ビジネスプロセスが動作しなければならないコンテキストを決定する。ルールは、ビジネスオブジェクトとビジネスプロセスについての妥当性検査と制約を定義するために使用される。例えば、ＲＳＥは、クライアントコンテキスト層内の異なるヘルスプロバイダの様々な要件を促進するためにブロック可能又はブロック不可能なものとしてマークされる。
【００４４】
ルールシステム要素は、例えば、以下のようなタイプに分類することができる。
・制約
・プロファイルプロパティ
・プロセス移行
・プロセス状態
・ビジネスプロセスオブジェクトテンプレート
・アクション
・許容値リスト
【００４５】
ＲＳＥは、ビジネスルール及びプロセスを実施するためにルールシステムエンジン又はプロセッサによって解釈される「メタオブジェクト」である。ＲＳＥは全て、以下のような共通の特性を有している。
・開始日と終了日がある。
・コンテキストを知っており、コンテキスト階層の下方に継承される。
・特定のコンテキスト層より下でブロック不可としてマークされることがある。即ち、ルールは、１つのコンテキスト内で定義され、全ての子（即ち、下位の）コンテキスト内で実施されることがある。
・それが定義するコンテキストによってブロック可とマークされ、任意の親（即ち、高位の）コンテキスト内でブロック不可とマークされていない限り、子コンテキスト内で無効にされることがある。
【００４６】
図７は、ルール又はルールシステム要素の例を図で示す。ＲＳＥの特定の例は、制約である。
【００４７】
制約
制約は、ビジネスプロセスの所定の状態において満たすことが必要とされるルールを実施するために使用される。各制約は、ビジネスプロセスを理解する１つ又は複数の適応可能なルールを表す。制約が満たされた後は、プロセスは、より多くの作業を達成するために、他の状態に自由に移行することができる。制約を使用して、アクションが行われるのを防いだり、プロセス内の別の状態に移行したりすることできる。
【００４８】
制約を使用して、アクション若しくはプロセス内の別の状態への移行を保護することができる。保護として使用されるとき、制約は、この場合も、関係するビジネスオブジェクトメソッドの結果を組み合わせて、アクション又は移行が行われることをビジネスルールが許可すべきかどうかを決定する。これにより、行うべきアクション又は移行を決定するときに、関係するビジネスオブジェクト内で符号化されたビジネスルールを活用することができる。
【００４９】
制約は、妥当性検査基準の主要な表現である。制約は、以下の機能の内の何れかを実行するために、ビジネスオブジェクトに適用される（例えば、後で説明する別のタイプのＲＳＥ、アクションに関連して）。
・ビジネスオブジェクトが有効であることをチェックする。
・１つ又は複数のビジネスオブジェクト特性を他の特性の値に基づいて計算する。
・特性又は特性群についての候補リストを計算する。
・ＵＩコンポーネント用に、ユーザのブラウザにおいて制約の妥当性検査ロジックの一部又は全てを実行するものを構成する。
・ＵＩコンポーネント用に、ビジネスオブジェクトが現在有効でない理由を説明するものを構成する。
【００５０】
また、制約は、状態の目標が達成されているかどうかを判定するためにプロセス状態と関連付けられることがある。状態の目標が全て達成されているとき、プロセスは、その現在の状態において有効であると言われる。
【００５１】
また、制約は、トリガイベントとしてプロセス移行と関連付けられることがある。そのようなタイプの制約は、一般に、プロセスがその現在の状態において有効なときだけ実行される。プロセス移行は、即時とマークされることがあり、これは、「状態で有効」であることが確認される前に評価されることを意味する。トリガイベントの制約が満たされた場合、プロセスは、プロセス移行によって定義されるように次の状態に移る。トリガイベントと関連した１つの制約がある。
【００５２】
また、制約は、クラスに関連付けられることがある。そのような制約は、クラス制約として知られる。クラス制約は、ビジネスオブジェクトの検証メソッドが呼び出されるたびに評価される。クラス制約は、コンテキストの影響を受ける。ビジネスオブジェクトの検証メソッドが呼び出され、コンテキストが提供されない場合は、評価のための制約を収集するために、関係する組織又はエンティティと関連したコンテキストが使用される。
【００５３】
クラス制約もグループ化することができる。コンテキスト内の制約をグループ化することによって、極めて特定のグループの制約を評価することができる。これを使用して、オブジェクトの有効性を確認して、データが全て存在し有効であることを保証することができる。特別な種類のクラス制約の結果、通知が生成される。このクラス制約は、ユーザが取得したいが絶対に必要ではない所望のフィールドを識別するために使用される。必要なデータが入力されない場合、情報が収集されなかったことを示す通知が生成される。次に、そのような通知はワークリストを介して処理される。それぞれの通知のタイプは、得られなかった情報をユーザに入力させる別のビジネスプロセスと関連付けられる。ワークリストから通知を選択すると、ビジネスプロセスが始まる。
【００５４】
例えば、「Create Face Sheet for Check In」と呼ばれるビジネスプロセスは、制約を以下のように使用する。即ち、定義された制約によって、以下のイベントの内の何れかが生じる。
【００５５】
１）このエンカウンタのためのフェースシートが既に生成されている場合は、フェースシートを印刷しない。
２）フェースシートがまだ作成されていない場合は、フェースシートを生成する。
３）エラー状態でこのアクションが行われない場合は、フェースシートを印刷しない。
【００５６】
また、図７に示した例示的な制約は、３つの検査プロセスを含む。最初のプロセスは、ブロック７０１「SmsTntEquaIsMethod」に示されている。このブロック７０１は、２つの関連するパラメータが等しいかどうかを確認する制約を表す。更に、ブロック７０２は、関連するパラメータが存在するかどうかを確認する検査プロセスを表す。また、図７に示した「SmsTntLiner」７０３は、例えば２つのパラメータが等しくない場合に制約ブロック７０３が真であるという点で、ブロック７０１に対して相補的な制約を表す。
【００５７】
プロファイルプロパティ
また、本発明によるユーザインタフェースは、プロファイルプロパティのセッティングに基づいて変化するであろう。それぞれの名前が付いたプロファイルプロパティは、１つの値だけを有し、その値はテキストの文字列である。プロファイルプロパティは、実行のためにキャッシュに入れられ、ユーザが、プロファイルプロパティを容易に操作できるようにフロントエンドが提供される。ユーザインタフェースは、プロファイルのセッティングに基づいて変化するであろう。例えば、「集金」プロファイルが「真」に設定されている場合、ユーザは、チェックインの際に患者から支払いを回収することを要求するプロンプトを受け取る。プロファイルプロパティが「偽」に設定されている場合は、プロンプトは表示されない。
【００５８】
図８に、ＵＩ画面を動的に生成するためにプロファイルプロパティを使用する例を示す。例えば、特定のユーザの支払い回収ワークフローにおいて、「集金」が「真」に設定されている場合は、支払い回収画面８０が表示される。次に、ウィンドウ８０のように、システムのユーザは、チェックアウトの際に患者からの支払いを回収することを要求するユーザ対話プロンプトを受け取る。「集金」プロファイルが「偽」に設定されている場合、ＵＩウィンドウ８０は、自動的に表示されない。このように、本発明によってＵＩが動的に変更される。
【００５９】
図９は、本発明の別の態様を示す。図９のユーザインタフェースウィンドウ９０は、ユーザによる手動選択によってプロファイルプロパティを無効できることを示す。例えば、患者が、チェックアウトの際に支払うべき保証人支払額（guarantor sum）を支払うことを希望する場合は、集金プロファイルが、上で図８と関連して説明したような支払いを自動的に要求するように設定されていない場合でも、システムのユーザは、更に、画面９０の制御バー領域の「支払い回収」ボタン９６をクリックすることによって「支払い回収」画面９０を手動で呼び出すことができる。更に、図９に示したように、ユーザは、サマリ選択アイコン９８によって保証人集計ウィンドウ９２を呼び出し、それにより、支払い額が患者に知らされる。
【００６０】
プロセス状態
プロセス状態は、およそプロセスの１ステップ又は１フェイズに対応する。ビジネスプロセスは、所定のプロセス状態にある。各プロセス状態は、それ自体の制約セットを有することができる。状態自体は特定のコンテキストに関して定義されるので、プロセス状態の制約は、コンテキスト層にアタッチされなくてもよい。所定の状態で有効であるべきビジネスプロセス又はオブジェクトについて真でなければならない条件を示すプロセス状態と関連付けられた制約はゼロ個以上ある。そのような制約は、所定のプロセス状態の目標と見なされることがある。プロセスは、非即時の移行が評価される前の現在の状態で有効でなければならならない。
【００６１】
ビジネスプロセスを定義するとき、開発者は、所定のビジネス機能に可能な全てのステップ又はコンディションを全て作成する。システムは、ビジネスプロセスがどのように進むべきかの説明を維持する。あるビジネスプロセスを別のビジネスプロセス内の状態として使用することができる。例えば、修正したエンカウンタビジネスプロセスを集金などの事業所のビジネスプロセスに組み込むことができる。
【００６２】
ビジネスプロセスの移行
ビジネスプロセスは、あるプロセス状態から別のプロセス状態に遷移する。プロセス移行インスタンスは、同じビジネスプロセス内の２つの状態、即ち「from」状態と「to」状態を接続する。プロセス移行は、システムに、トリガイベントを使用して、いつ特定のプロセス状態に移行するかを指示する。これにより、プロセスが次に流れなければならない場所を制御することが可能になる。例えば、患者が登録されるとき、トリガイベントは、登録される人が、既存の計画されたエンカウンタを有しているかどうかをチェックし確認する。終了状態は、ユーザがその患者についての既存の計画されたエンカウンタを閲覧できる画面を表示する。
【００６３】
所定のプロセス状態からの複数のプロセス移行を定義することによって、プロセスフローのルールを定義することができる。各移行は、プロセスをその次のプロセス状態にするために定義されたルール又はトリガイベントのセットを有する。プロセス移行が評価される時期は、移行が即時としてマークされているか否かと、移行に割り当てられた優先順位に依存する。所定のプロセス状態からのプロセス移行を管理するルールの例は、次の通りである。
・ユーザ入力アクションの結果、コンテキストが変化したとき、その変化は次のプロセス又はクラス制約に現れるか、或は即時又は通常の移行が処理される。その変化は、現在の状態のどの入力アクションが処理されるかに影響を及ぼさない。
・イグジットアクションの結果コンテキストが変化したとき。この変化は、次の即時の移行、プロセス又はクラス制約に現れるか、或は、移行アクションが処理される。この変化は、現在の状態のどのイグジットアクションが処理されるかに影響を及ぼさない。変化は、イグジットアクションが行われる状態で通常の移行の処理に影響を及ぼさない。何故なら、その状態からの移行については、定義によって通常の移行が既に選択されているためである。変化は、任意の後続の状態での通常の移行の処理に影響を及ぼす。
【００６４】
図１０は、ビジネスプロセス「人物確認」のプロセス移行のより多くの例を示す。例えば、図１０の第１列は、即時でないプロセス移行の例を示す。この特定のプロセス移行を引き起すトリガイベントは、１行１列に示したようにエンカウンタが有効にされるときである。このプロセス移行のガード条件（例えば、制約）は、患者エンカウンタが関連するビジネスプロセスに渡されるか否かである。移行タイプは、非即時であるように示されている。何故なら、現在のプロセスがその現在の状態で有効になる（例えば、実行される）までこの移行が実行されないからである。更に、図１０の第４行は、即時移行の例を示す。この移行のためのトリガイベントは、ユーザによって発行される「キャンセル」コマンドである。このケースでは、この移行は、コマンドエントリによって即時実施される。
【００６５】
ビジネスプロセスオブジェクトテンプレート（ＢＰＯＴ）
ビジネスプロセスオブジェクトテンプレートの状態機械は、ビジネスプロセスを構築する１組のステップ又はコンディションを含む。ＢＰＯＴ状態機械のそのようなステップ又はコンディションは、状態と呼ばれる。例えば、人を病院に入院させるビジネスプロセスは、次のように呼ばれる状態を含む。
・患者人口統計を収集する。
・保険を取得する。
・保証人を取得する。
・新しい患者を追加する
【００６６】
ユーザが、特定のビジネス機能を実行するように選択したとき、そのビジネス機能のために定義されたＢＰＯＴの状態機械が実行し始める。実行するＢＰＯＴ状態機械のインスタンスは、ビジネスプロセスと呼ばれる。ビジネスプロセスの目的は、ＢＰＯＴ状態機械の状態に対応するステップを実行するか又はコンディションを解決することである。
【００６７】
ビジネスプロセスが実行し始めるとき、その状態機械は、ＢＰＯＴの開始状態で実行し始める。ＢＰＯＴ状態機械の定義は全て、開始状態を１つだけ指定しなければならない。開始状態は、ビジネスプロセスが処理し始める場合の状態機械の状態を指定する。
【００６８】
一般に、ビジネスプロセスが実行し始めた後、ユーザは、１つ又は複数のフォーム（画面）と対話する。ユーザがフォームとどのように対話するかによって、状態機械がどのように処理されるかが決まる。ＢＰＯＴ状態機械の処理は、ある状態（ビジネスプロセスのステップ又はコンディション）から別の状態（ビジネスプロセスのステップ又はコンディション）に移ることからなる。
【００６９】
終了状態は、状態機械の処理が終了する状態である。開始状態と違い、ＢＰＯＴ定義で任意の数の終了状態を指定することができる。それぞれの終了状態は、特定のビジネスプロセスがどのように終了するかに対応する。可能な終了状態名の例には、チェックイン完了（Check-in Completion）、患者入院完了（Patient Successfully Admitted）、ユーザによる機能の取り消し（User Cancelled Out of Function）、及び不測エラー発生（Unexpected Error Encountered）がある。
【００７０】
ＢＰＯＴを定義するとき、開発者は、状態のスーパーセット、即ち所定のビジネス機能に可能な全てのステップ又はコンディションのセットを定義する。ビジネスプロセスのフォームと対話するユーザ及びビジネスプロセスが実行されるときに存在するコンディションによって、ビジネスプロセスが実行されるときに出会う実際の状態が決定される。ビジネスプロセスの実行は、ＢＰＯＴの開始状態で始まり、ＢＰＯＴにおいて定義された終了状態の１つで終了する状態機械の中のフローからなる。
【００７１】
ＢＰＯＴは、ビジネスプロセスを記述しており、ビジネスプロセスの記述とルールを含む。適応性コンテキストにより、ビジネスプロセスを、プログラミングなしに作成することができる。ビジネスプロセス定義は関連するデータを含み、ビジネスプロセスのインタプリタ／プロセッサがそのデータを使用する。
【００７２】
ＢＰＯＴインスタンスは、プロセスを記述する状態遷移図を有する。ビジネスプロセスがどのように流れるべきかについてのこの説明は、ビジネスプロセスのインスタンスを作成するに必要とされる。ビジネスプロセスの各インスタンスは、取り扱わなければならないビジネスプロセスを記述するＢＰＯＴインスタンスを有している必要がある。
【００７３】
あるＢＰＯＴを別のＢＰＯＴ内の状態として使用することができる。例えば、修正したエンカウンタビジネスプロセスを集金などのビジネスオフィスのビジネスプロセスに組み込むことができる。
【００７４】
ビジネスプロセスオブジェクト（ＢＰＯ）は、１組の関係するビジネスオブジェクトを有するある状態での特定のプロセスである。関係するビジネスオブジェクトは、患者、人物、エンカウンタ又は診断を含む。コンテキスト層は、プロセスを実行している対象の組織に対応するＢＰＯを作成するときに指定しなければならない。ＢＰＯのコンテキスト適応性は、ＢＰＯを実行するユーザと関連付けられた組織又は状況コンテキストを反映する。適応性コンテキストは、ＢＰＯの実行中にどのルールシステム要素が使用可能でどれがブロックされるかを決定する。コンテキストは、ＢＰＯが実行するときに変化し、それにより使用可能かつ／又はブロックされるルールシステム要素が変化する。実行するＢＰＯは、組織又は状況コンテキストがどのように変化するかに基づいて適応される。
【００７５】
一般に、ＢＰＯインスタンスは、ワークステーション（組織内のオフィスにある）のユーザが、ＵＩ操作（gesture）（例えば、チェックインボタンをクリックする）を行った時に作成される。ＢＰＯインスタンスは、適応性フレームワークによって提供されるＢＰＯファクトリ／プロセッサによって作成される。ＢＰＯファクトリ／プロセッサは、ビジネスプロセスにどのＢＰＯテンプレートを使用するべきかを決定するためにビジネスプロセス名を受け入れる。適応性フレームワークによって提供されるＢＰＯの状態機械が実行され、ＢＰＯＴ内で指定された情報を使用して、ＢＰＯインスタンスの処理中に使用する関係するビジネスオブジェクト及びビジネスプロセスの状態及び移行を決定する。
【００７６】
ビジネスオブジェクトは、ソフトウェア提供者によって生成されるコードである。各ビジネスオブジェクトは、何らかのタイプの作業を実行するメソッドを含む。例えば、患者ビジネスオブジェクトは、患者の年齢を得るために患者の氏名などのを返すメソッドを有する。ビジネスプロセスに関連するルールは、ビジネスオブジェクトの挙動及びメソッドを調和させるために使用される。例えば、ルールシステム要素は、患者が自分の保証人になるのに十分な年齢どうかを患者ビジネスオブジェクトを尋ねる。ルールは、患者が、年齢が１８才以上の場合だけ自分の保証人であることができるというものである。関連するビジネスオブジェクトメソッドからの応答によって、患者は、自分の保証人になることを許可される場合と許可されない場合がある。ユーザインタフェースは、ルールシステム要素とビジネスオブジェクト関係者（participant）と間のこの裏側での対話（behind the scenes interaction）に基づいて変化し続ける。
【００７７】
図１１に、「チェックイン」検証ビジネスプロセスのビジネスプロセスオブジェクトテンプレートの状態図の例を示す。
【００７８】
アクション
アクションは、ビジネスオブジェクトについてのメソッドを呼び出してプロセス状態において何らかのタイプの作業を達成するために使用される。例えば、アクションは、文書の印刷又は患者の請求書の作成をトリガするために使用される。
【００７９】
チェックインプロセスの最後の状態として、ユーザがフェースシートを生成したいと仮定する。最初に、関係するオブジェクトの内の１つのオブジェクトについてのメソッドが、フェースシートの作成を支援する必要がある。ビジネスプロセスを「チェックイン用のフェースシートの作成（Create Face Sheet for Check In）」と呼ぶと仮定する。以下の例示的なステップは、定義された制約に依存して、行われる場合と行われない場合がある。
・このエンカウンタのためのフェースシートが既に生成されている場合は真を返す。
・フェースシートがまだ作成されていない場合はフェースシートを生成し真を返す。
・何らかの理由でフェースシートを作成できない場合は偽を返す。
【００８０】
許容値リスト
許容値リストは、実行されているビジネスプロセスによって異なる項目を示す。実行されているビジネスシナリオに対応するために、項目がリストから除外されたり、項目がリストに加えられたりする。これらのルールシステム要素を使用して特定の属性の許容値リストを定義することができる。これらのリストは、以下の例示的な方法でコンテキストによって適応される。
・項目がリストから除外される。
・項目がリストに追加され、その挙動がモデル値にマップされる。
・項目の記載とニーモニックが無効にされる。
・多くの言語をサポートするためにリストが作成される。
【００８１】
一般に、許容値リストは、ユーザインタフェースに表示され、入力されたデータを検証するために使用される。
【００８２】
機能的操作
図６に示した例示的なコンテキスト層の図の更に詳しい説明は、本発明の能力をより詳細に示す助けとなる。前述のように、図６のＡＢＣヘルス６１０は、フレームワークのエンタープライズレベル又はクライアントレベル、並びに本発明の原理によりカスタマのルール及びビジネスプロセスが定義される最も高いレベルを表す。
【００８３】
また、本発明によれば、例えばチェックインプロセスで提示されたユーザインタフェースは、以下に更に説明するように、コンテキスト適応性フレームワークの使用に基づいて変化する。
【００８４】
医師オフィスの制約の例
ルールシステム要素とブロック機構によって、例示的なチェックインプロセスのユーザインタフェースは、医師オフィスが獲得する必要がない特定の要素を除外する。その例には、到着日、到着時刻、エンカウンタソース、及び緊急コードが含まれる。これらの要素は、医師オフィスについてはブロックされるが、例えば同じヘルスシステムの一部である救急ケア施設内での使用ではブロックされない。
病院（入院患者）制約の例
病院の例では、ブロックされる要素はない。病院は、例えば、エンカウンタの理由、ＤＸ記述、入院タイプ、臨床サービスなど（但し、これらに限定されない）の情報の全てを収集することを望むであろう。
病院（緊急）制約の例
緊急ケースの処理を迅速にするために所望のフィールドを省略できるように、ＥＲチェックインプロセスではクラス制約が広範囲に使用される。記入されない場合は、将来の追跡のためにワークリスト上に所望の要素が表示される。これにより、ユーザは、取得できなかったデータ要素の追跡を心配することなく、迅速にチェックインを処理して患者のケアを行うことができる。緊急部門の制約のもう１つの例は、トリアージ（triage）分類の使用である。トリアージ分類は、緊急のために獲得する重要な情報であるが、医師オフィスや入院患者の訪問には適切でない
医師オフィスプロファイルの例
チェックインプロセスにおけるプロファイルに使用例は、集金プロファイル（Collect Money Profile）である。このプロファイルは、チェックインプロセスの際に機関が集金を希望するか否かによって「Ｙｅｓ」又は「Ｎｏ」の値が付けられる。医師オフィスは、共同支払い義務（co-payment due）のお金を収集するように選択することができ、従って、プロファイルが「Ｙｅｓ」に設定される。
病院（入院患者）プロファイルの例
救急ケアのセッティングで使用されるプロファイルの例は、主ロケーション指定要求プロファイル（Require Primary Location Assignment Profile）である。このプロファイルがＹｅｓに設定された場合は、チェックインプロセスを完了するために主ロケーション指定が必要とされる。
病院（緊急）プロファイルの例
「緊急処置室（Emergency Room）」は、「チェックインプロファイルに既存の計画されたエンカウンタの表示を含む（Include Display Of Existing Schduled Encounters At Checkin Profile）」を「偽」に設定するように選択することができる。緊急処置室の訪問は本来計画されないので、計画された訪問の表示は不適切である。
医師オフィス許容値の例
医師オフィスは、許容値リストから特定のサービスをブロックするように選択するであろう。そのようなサービスは、他の施設には適切であるが、医師オフィスには適切でない。医師オフィスについて除外されるサービスの例は、相談（Consult）である。相談は、救急ケアのセッティングでは一般的であるが、医師オフィスには不適切である。コンテキスト適応性フレームワークを使用することにより、ユーザインタフェースは、ワークフローをサポートするのに必要なコンポーネントだけを反映させることができる。
【００８５】
以上の例は、コンテキストのルールが、本発明による適応性フレームワークをどのように利用し、特定のユーザインタフェースのルックアンドフィールをどのように改善できるかを示している。また、これら例は、本発明が、プログラミングなしにオペレーションプロセスをサポートできることを示している。本発明の原理によるユーザインタフェースは、各プロセスの利害関係者によって指定されたルールを組み込むため、処理ルールに対する最新の更新又は変更がユーザに提示される。この動的ユーザインタフェースは、ワークフローの効率を最大にし、各エンティティによって定義されたヘルスシステムのルールを実施する。このソフトウェアの開発者は、殆ど又は全くコーディングなしにカスタマについてのモデルテンプレートを作成し修正することができる。
【００８６】
更に、ルールの定義とヘルスケアのカスタマイズがそれぞれの利害関係者ごとに定義される。また、ルールの実施は、ヘルスケア機関によって定義され、動的に実行される。また、本発明は、広範囲なプログラミング経験なしに各アプリケーションをカスタマイズする機能を提供し、従ってソフトウェアのマルチエンティティの適応を容易にする。
【００８７】
更に、この適応性フレームワークは、システム、カスタマ、規制環境、組織、オフィスなどの多くの個別のエンティティの内の何れかと関連付けられたコンテキストに属しているように指定される。従って、適応性（ルール、プロセス及びワークフロー）が、プログラミングなしに達成される。適応性の要素はデータである。
【００８８】
従って、フレームワークは、ビジネスロジックを、そのロジックの所有者がロジックを使用不能にすることを認める場合に、使用不能にする機構をエンティティに対して提供する。これは、例えば、前に説明したようなブロック処理によって達成される。また、フレームワークは、ビジネスオブジェクトの有効性を確認する適応機構を提供する。ビジネスオブジェクトは、複数のプロセス及び異なるコンテキストにおいて同時に対話することができる。フレームワークは、長期間にわたって行われる可能性のあるビジネスプロセスを記述するための適応機構を提供する。従って、フレームワークは、ワークフローを記述するための適応機構を提供する。
【００８９】
図１２は、本発明の教示による例示的なソフトウェアを処理しユーザインタフェースを生成する例示的なシステムを示す。システム５０は、汎用コンピュータ又は特別に構成されたコンピュータを含むことができる。汎用又は特別に構成されたコンピュータを、本明細書の教示によるプログラムと共に使用することができる。汎用コンピュータの例は、ＭＳ  Ｗｉｎｄｏｗｓ[登録商標]を実行できるＩＢＭ互換パーソナルコンピュータである。専用マシンの例は、医療分野で使用される医学システムである。
【００９０】
例えば図１、図２、図８及び図９に示したような本発明のユーザインタフェースは、図１２示した例示的なシステムを使用して実現することができる。システム５０は、システム５０の他のコンポーネント間で情報を適切な形で通信するために使用される入出力（Ｉ／Ｏ）部５１を含む。入出力部５１は、出力プロセッサ６１を含む。更に、システム５０は、入出力部５１に結合されたプロセッサ部５２と、実行されるコンピュータプログラムやその他の情報を記憶するＲＡＭやＲＯＭなどのメモリ５３とを含む。プロセッサ部５２は、少なくとも１つの追跡プロセッサ６５と適応プロセッサ６６とを含む。この図では、別々の２つのプロセッサ６５及び６６として示したが、当業者は、単一のプロセッサがそれらの両方の機能を実行できることを容易に理解することができる。プロセッサの実際の数は、特定のハードウェアシステムの固有の実施形態により変化する。
【００９１】
システム５０は、例えば、ＣＲＴモニタ、液晶ディスプレイ（ＬＣＤ）などの表示装置６０を含む。システム５０は、更に、例えば、例えば表示装置６０の表示画面６２上のカーソル（図示せず）を選択的に位置決めするマウス、トラックボール、ジョイスティック、その他の装置などのユーザカーソル制御機構５４を含む。一般に、カーソル制御機構５４は、カーソル制御機構５４によってフォーカスされ又はイネーブルされた特定のコマンドを実行するようにコンピュータに指示する信号を生成するためにコンピュータシステムのユーザが使用することができるスイッチ５５などの信号生成手段を含む。システム５０は、また、当該技術分野で周知のようなユーザからのデータ及びコマンドを入力するキーボード５６を含む。
【００９２】
また、図１２に、コンピュータ５０の記憶容量を増やすために入出力回路５１に結合されたハードディスクなどの大容量記憶装置５８が示されている。更に、記憶容量の追加、若しくは別の入出力として、入出力回路５０にＣＤ／ＤＶＤ−ＲＯＭ５７が結合されている。当該技術分野で周知のように、様々な目的のためにコンピュータ５０に追加の装置（図示せず）を結合することができることを理解されよう。
【００９３】
図１２に示したように、表示装置６０は、サブウィンドウ６３が表示される表示画面又はウィンドウ６２を含む。表示画面６２の例は、例えば、図１の表示画面１０、図２の表示画面２０、図８の表示画面８０、又は図９の表示画面９０として示されている。サブウィンドウ６３の例は、例えば、図９のウィンドウ９２として示されている。
【００９４】
本明細書に示し説明した実施形態及び変形は単に例示のためであり、本発明の範囲を逸脱することなく当業者が様々な修正を実施できることを理解されたい。
【図面の簡単な説明】
【００９５】
【図１】本発明による代表的な汎用ユーザインタフェースを示す図である。
【図２】図１に示した汎用ユーザインタフェースの特定の例を示す図である。
【図３】本発明の１つの例示的な実施形態を示す図である。
【図４】本発明の別の例示的な実施形態を示す図である。
【図５】ビルド領域の例を示す図である。
【図６】モデルシステムコンテキストレベル並びにクライアント／エンタープライズレベルにおけるスタータセットの例を示す図である。
【図７】ルールシステム要素の例を示す図である。
【図８】本発明による例示的なユーザインタフェース画面を示す図である。
【図９】別の例示的なユーザインタフェース画面を示す図である。
【図１０】ビジネスプロセス「人物確認」のプロセス移行の例を示す図である。
【図１１】本発明の原理による状態図の例を示す図である。
【図１２】本発明の原理による例示的なシステムを示す図である。
【符号の説明】
【００９６】
３２，３３，３４  タスク
３５  テンプレートフォーム
３６  追跡プロセッサ
３８  ユーザコンテキスト情報
３７  適応プロセッサ
３９  出力プロセッサ
３１０  ユーザインタフェース表示画像
【図１】
2005507124.tif 000003
【図２】
2005507124.tif 000004
【図３】
2005507124.tif 000005
【図４】
2005507124.tif 000006
【図５】
2005507124.tif 000007
【図６】
2005507124.tif 000008
【図７】
2005507124.tif 000009
【図８】
2005507124.tif 000010
【図９】
2005507124.tif 000011
【図１０】
2005507124.tif 000012
【図１１】
2005507124.tif 000013
【図１２】
2005507124.tif 000014
【国際公開パンフレット】
2005507124.tif 000015
2005507124.tif 000016
2005507124.tif 000017
2005507124.tif 000018
2005507124.tif 000019
2005507124.tif 000020
2005507124.tif 000021
2005507124.tif 000022
2005507124.tif 000023
2005507124.tif 000024
2005507124.tif 000025
2005507124.tif 000026
2005507124.tif 000027
2005507124.tif 000028
2005507124.tif 000029
2005507124.tif 000030
2005507124.tif 000031
2005507124.tif 000032
2005507124.tif 000033
2005507124.tif 000034
2005507124.tif 000035
2005507124.tif 000036
2005507124.tif 000037
2005507124.tif 000038
2005507124.tif 000039
2005507124.tif 000040
2005507124.tif 000041
2005507124.tif 000042
2005507124.tif 000043
2005507124.tif 000044
2005507124.tif 000045
2005507124.tif 000046
2005507124.tif 000047
2005507124.tif 000048
2005507124.tif 000049
2005507124.tif 000050
2005507124.tif 000051
2005507124.tif 000052
2005507124.tif 000053
2005507124.tif 000054
2005507124.tif 000055
2005507124.tif 000056
2005507124.tif 000057
2005507124.tif 000058
2005507124.tif 000059
2005507124.tif 000060
2005507124.tif 000061
2005507124.tif 000062
【国際調査報告】
2005507124.tif 000063
2005507124.tif 000064
2005507124.tif 000065